Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Deriving a session key: Ephemeral Keys and RSA-2048 delivery

An Ephemeral Key (EK) is a session key that the token and the cloud each derive independently during an authentication flow; it is never transmitted. Once the flow completes, both sides hold the same 16-byte key, which you can use to encrypt subsequent traffic, derive further keys, or bind a session to the physical device.

Why this matters

Conventional session keys must be generated on one side and sent to the other, so their confidentiality depends entirely on the transport. An EK is computed inside the token's hardware on one side and inside the cloud's HSM on the other, as a by-product of the same challenge-response. There is nothing on the wire to intercept, and the key is inherently tied to the genuine hardware.

The six examples

All live in examples/03-derive-session-key/. Choose along three axes: who initiates, synchronous or polling, and how the cloud's copy of the EK is delivered to your host application.

Script Initiated by Sync? EK delivery to host
token_auth_ek.py Cloud Polls Plain (HTTPS only)
token_auth_ek_rsa2048.py Cloud Polls RSA-2048 wrapped
host_auth_ek.py Device Polls Plain (HTTPS only)
host_auth_ek_rsa2048.py Device Polls RSA-2048 wrapped
host_auth_ek_priority.py Device Immediate Plain (HTTPS only)
host_auth_ek_priority_rsa2048.py Device Immediate RSA-2048 wrapped

Recommended starting points: host_auth_ek_priority.py for the simple case; host_auth_ek_priority_rsa2048.py when the key must not be readable in transit.

What the RSA-2048 variant adds

In the plain variants, the cloud returns its copy of the EK to the host over HTTPS. The _rsa2048 variants add an end-to-end envelope on top:

  1. The host generates a fresh RSA-2048 keypair and sends the public key with the request.
  2. The cloud encrypts the EK (hybrid AES + RSA envelope) before returning it.
  3. The host decrypts locally and verifies the result matches the EK the token derived.

Even a party who could read the HTTPS payload (a terminating proxy, a logging middlebox) never sees the key. These variants require the cryptography package.

Compatibility notes for the RSA path. The envelope format uses SHA-1 in OAEP/MGF1 (an interoperability requirement of the hybrid-crypto-js wire format, not a free choice), and PKCS7 padding is stripped without validation, so malformed input yields silent garbage rather than an error. Understand both before relying on this path in a regulated context. One example, token_auth_ek_rsa2048.py, also contains a harmless dead first decryption pass.

Using the key

At the end of a successful flow your host application and the cloud both hold the same EK, and the flow has simultaneously proven the device genuine. The examples end by comparing the token-derived and cloud-derived keys and reporting a match; replace that final block (YOUR INTEGRATION POINT) with whatever your application needs: an AES session, an HMAC key for message tagging, or input to your own KDF.

Source code: SandGrain CyberRock - Core Functions on GitHub