AKADATA Identity Envelope

AIE is AKADATA’s explicit identity and encrypted transport design: no cookies, no PHP sessions, no query-string routing, and ECDH-P256 form encryption before submitted data leaves the browser.

What AIE is

AIE means AKADATA Identity Envelope. It is a layered design for sites that need explicit identity, encrypted application payloads, or both, without ambient cookie state.

The public AKADATA site uses the encrypted form-transport layer. Account-enabled sites can additionally use signed and encrypted bearer tokens, short-lived guest identity, origin binding, rotation, and server-side revoke.

Each site adopts only the layers it needs. The security boundaries remain clear and inspectable.

How an encrypted form travels

The browser requests a short-lived challenge bound to the clean form action.
The browser generates a fresh ephemeral ECDH P-256 keypair.
The browser combines its private key with the server public key to derive a shared AES-256 key.
The form values, action, and one-time challenge are encrypted with AES-GCM. Only the client public key, IV, and ciphertext are submitted.
The server derives the same shared key, authenticates and decrypts the envelope, then atomically consumes the challenge before normal validation begins.

What is protected here

Every public POST form on this site uses AIE transport: contact enquiries, networking readiness checklists, and Test Lab assessments.

Plaintext POST attempts are rejected. Challenges expire after three minutes, are bound to one form action, and can be consumed only once.

Search is a non-sensitive GET operation. It does not carry personal form content and is not placed inside the POST encryption path.

Application encryption and TLS

AIE does not replace HTTPS. TLS still authenticates the site and protects the full network connection.

AIE adds a separate application envelope. Raw form fields are turned into ciphertext in the consumer’s browser and are not posted as ordinary form values. The receiving application decrypts them only inside the intended server process.

This is defence in depth, not a claim that browser compromise, malicious extensions, or an already-compromised server can be solved by cryptography alone.

Public and private key boundaries

The server public JWK is deliberately sent to the browser. A public key is not a secret.

The matching P-256 private key is created on the server, stored outside the public document root, restricted to the application account, and never included in HTML, JavaScript, logs, examples, or public repositories.

Browser keypairs are ephemeral. A fresh client keypair and AES-GCM IV are generated for each submission.

No ambient browser state

AIE avoids cookies and PHP sessions. Identity, where required, is presented explicitly as a bearer envelope rather than silently attached by the browser.

Public routes remain stable clean paths. Query strings are not used to choose pages or carry identity.

Short-lived challenge records are operational replay controls, not browser sessions. They contain an action and expiry, carry no submitted form values, and are deleted when consumed.

Reusable browser pattern

This abbreviated example shows the standard Web Crypto operations. A production implementation must also validate the challenge, bind the action, encode the envelope, handle failure without plaintext fallback, and use HTTPS.

const ephemeral = await crypto.subtle.generateKey(
  { name: "ECDH", namedCurve: "P-256" },
  true,
  ["deriveKey"]
);
const serverPublic = await crypto.subtle.importKey(
  "jwk", publicJwk,
  { name: "ECDH", namedCurve: "P-256" },
  false, []
);
const aesKey = await crypto.subtle.deriveKey(
  { name: "ECDH", public: serverPublic },
  ephemeral.privateKey,
  { name: "AES-GCM", length: 256 },
  false, ["encrypt"]
);
const iv = crypto.getRandomValues(new Uint8Array(12));
const ciphertext = await crypto.subtle.encrypt(
  { name: "AES-GCM", iv }, aesKey,
  new TextEncoder().encode(JSON.stringify(payload))
);

Reusable PHP pattern

The server derives the same 32-byte shared secret. Deployed paths, keys, challenges, and secret values are intentionally absent from this example.

// Private key path is server-only and never placed under the web root.
$privateKey = openssl_pkey_get_private($privatePem);
$clientKey = openssl_pkey_get_public($clientEphemeralPem);
$sharedKey = openssl_pkey_derive($clientKey, $privateKey);

$plaintext = openssl_decrypt(
    $ciphertext,
    'aes-256-gcm',
    $sharedKey,
    OPENSSL_RAW_DATA,
    $iv,
    $authenticationTag
);

// Validate and atomically consume the action-bound challenge before use.

Security should not depend on hiding how a sound protocol works. We are happy to share the architecture, algorithms, envelope shape, and implementation lessons so others can build safer public forms.

What remains private is the deployed key material and live operational data. Publishing a private key would not demonstrate openness; it would destroy the boundary the design is intended to protect.

AIE is an AKADATA design used across our sites. AZ2 is the current account-enabled reference implementation, while this public site demonstrates the standalone encrypted form-transport layer.