Mechanism¶
Moving beyond traditional static secret methods, Relock employs a sophisticated, purely cryptographic approach to continuous passive authentication. It operates through a seamless, background validation process, verifying the legitimacy of every client-server interaction. At its core, Relock’s mechanism is built upon two primary components: advanced session verification and continuous verification.
Advanced session verification¶
Relock strengthens standard session establishment and verification processes, ensuring robust client identification and secure session management.
A core principle of Relock’s secret management is the interdependence of the server and client, achieved by splitting a shared secret between them. Specifically, the client holds the encrypted version of the shared secret, while the server holds the corresponding decryption key. This distribution of knowledge enhances security by ensuring neither party alone possesses the entire secret.
The client stores cryptographic keys using a combination of localStorage, sessionStorage, and HTTP-only cookies. These storage mechanisms ensure that the stored cryptographic keys are origin-bound, making them inaccessible across different origins or domains. Within a session, on each request, the client must attach the cookie with the encrypted shared secret (along with other required legitimacy proofs).
Established clients¶
At the beginning of each session, the client initiates the process by sending its encrypted shared secret to the server. This action proves the client’s continued possession of its part of the shared secret and identifies the specific client to the server. The client then cryptographically signs this request. Upon receipt, the server uses the client-sent part of the shared secret to reconstruct it, thus verifying the client’s legitimacy. Once the client is verified, the server updates the shared secret, encrypts it, and sends the newly encrypted shared secret to the client. The server stores only the decryption key for this updated shared secret, never the shared secret itself in plaintext or encrypted form. This distributed knowledge of the shared secret between the server and the client inherently provides a significantly higher level of security compared to the traditional session management.
New clients¶
When a new client seeks to establish a session, it sends an “empty” request (i.e., a request without the cookie containing an encrypted shared secret) to the server. This initial interaction establishes the client’s public signature. The server then generates a new shared secret along with an encryption key. This new shared secret is encrypted with the newly generated encryption key and sent to the client, while its corresponding decryption key is stored on the server. As with established clients, the server does not retain the shared secret itself, either in plaintext or encrypted form.
Continuous verification¶
Following session establishment and the client’s proof of its legitimacy via possession of its portion of the divided shared secret, Relock implements a continuous verification mechanism. For every client request within a session, the client’s legitimacy is verified using a challenge-response protocol.
The Relock JavaScript library running in the client browser enables the client to generate ephemeral keys. Concurrently, within each webpage sent in response to the client, the server embeds a unique, random nonce. Upon receiving the webpage, the client uses the nonce to generate a new ephemeral key, which is then used to generate a cryptographic proof of ephemeral key generation. This proof, along with a digital signature generated using the client’s private key, is then sent back to the server. It demonstrates the successful generation of the ephemeral key and its correct association with the nonce from the received webpage.
The client undergoes three-fold verification by the server, which checks the presence and correctness of three pieces of evidence sent by the client:
The server-set, session-specific shared secret,
The proof of ephemeral key generation, and
The client’s digital signature.
This challenge-response mechanism, powered by dynamic ephemeral keys and proofs, ensures ongoing trust and security at the request level. The server-side key rotation occurs immediately prior to validating the client-sent proof, ensuring any authentication attempt triggers a secure re-evaluation of key validity.