.. Relock Cloud Deployment documentation master file, created by sphinx-quickstart on Wed Aug 20 11:05:55 2025. You can adapt this file completely to your liking, but it should at least contain the root `toctree` directive. .. _relock-tesseract: .. rst-class:: break_before Technical Overview ================== The State of Play ~~~~~~~~~~~~~~~~~ At the root of the authentication problem is the fact that usernames are often easy to guess or discover, and people are generally very bad at using strong passwords. People also tend to re-use the same weak passwords across many different sites. Cybercriminals, armed with a victim’s username and password, will often attempt credential stuffing attacks, logging into many different sites using the same username/password combination. To prove that users are valid, authentication systems generally rely on at least one of three authentication factors: - Something you know (*e.g. a username and password*) - Something you have (*e.g. a second device, possession factor/MFA*) - Something you are (*e.g. fingerprint or face recognition*) In the presence of increasingly sophisticated phishing methods, using only one authentication factor, such as a username/password, is highly problematic. Many defenders have responded by implementing MFA, which includes an additional factor, such as an SMS message or push notification, as an extra step to confirm a user’s identity when logging in. By including an additional factor in the authentication process, compromised usernames and passwords become much less valuable to cybercriminals. However, cybercriminals are creative, and they have devised clever ways to bypass authentication models that rely on commonly used **bearer credentials**. .. rst-class:: break_before Bearer Session Model ~~~~~~~~~~~~~~~~~~~~ Today, the vast majority of web services rely on the *Bearer model*: whoever possesses the right secret value is accepted, regardless of how it was obtained or where it is used. This applies to both the login stage and the in-session requests. **Login stage** Passwords, SMS OTPs, and even authenticator app codes (TOTP or push) are bearer secrets. Whoever enters the correct value, or presses *approve*, is treated as the user. Attackers can phish these secrets in real time, relay them through a reverse proxy (Adversary-in-the-Middle, AiTM), or trick users into approving push requests (push fatigue). .. image:: _static/login_flow.svg :width: 500px :alt: Login diagram :align: center **Session stage** After login, servers issue session cookies or bearer tokens. Possession of this cookie/token alone is enough to act as the authenticated user until the token expires. If stolen through phishing, malware, or man-in-the-middle attacks, the attacker can bypass all login protections — including MFA — because the server cannot distinguish a legitimate origin of a bearer token. .. image:: _static/session_flow.svg :width: 500px :alt: Session diagram :align: center **Why is it dangerous** Bearer authentication secures only the initial login event. Once an attacker steals a bearer secret (whether a password, MFA code, or session token), they can fully bypass protections and impersonate the user. This makes bearer tokens and cookies one of the biggest targets in modern account-takeover attacks. .. rst-class:: break_before Continuous Cryptographic Trust ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In the bearer authentication model, an adversary does not need the user’s credentials to sign in — the user effectively hands over an authenticated, ready-to-use bearer artifact. Relock replaces these reusable artifacts with a *per-request cryptographic proof* of the origin-bound relationship between client and server. Instead of “whoever has the token can act as the user,” every request must carry a fresh **Signed cryptographic One-Time Token (SOTT)**. .. image:: _static/relock_model.svg :width: 500px :alt: Relock model :align: center Bearer authentication trusts possession of a secret value; Relock trusts the origin-bound, continuous *cryptographic synchronization* between the client and the server. The SOTT token is derived from secret material that never leaves the client device or its origin. If the derived token payload matches the server-side secret, and the cryptographic signature is valid, the single request is granted. .. image:: _static/rekeying.svg :width: 500px :alt: Rekeying :align: center Each time a SOTT token is verified, the server may trigger a key rotation. This ensures the secret material cannot be reused outside the legitimate origin or without the server’s knowledge. In simple terms: even if someone gains access to the secret, attempting to use it will immediately expose the attack. There cannot be any third-party actor between the client and the server (or multiple versions of the synchronization key). This feature provides continuous *visibility as well as observability*. During a session, any attempt to reuse the secret material triggers a key collision and immediate session termination, making session hijacking an extremely difficult task for an adversary. .. rst-class:: break_before Cryptographic Design ~~~~~~~~~~~~~~~~~~~~ Behind the scenes, Relock combines public-key cryptography (PKI) with symmetric key material. Trust is bound along four axes: **device**, **server**, **origin**, and **time** (rotation cadence). The core of this system is a symmetric key — **Relock Tesseract** — that powers the derivation of per-request tokens. The Tesseract is not just random bytes of entropy. It is a symmetric key wrapped in a mechanism of *interdependent encryption*. Neither the client nor the server ever holds the raw value directly: - *Server-side:* the secret is encrypted with a random key that exists only on the client-side. - *Client-side:* the secret is encrypted with a random key that exists only on the server-side. - *Binding:* the client-side encryption is bound to the browser’s fingerprint and an extra randomization key delivered from the server. - *In-memory only:* both client and server access the raw secret material only in device memory; it is never stored in unencrypted form. Both client and server also hold Ed25519 key pairs for the control plane. Each side signs messages with its private key and verifies them with the other side’s pinned public key. This provides mutual authentication and message integrity, independent of the Tesseract-derived SOTTs. On the client side, the Ed25519 signature key material is additionally randomized in storage, ensuring that it cannot be directly extracted or reused outside the legitimate browser environment. This design ensures that neither side can reconstruct or use the Tesseract in isolation. Only when the legitimate browser and the Relock gateway are synchronized can the material be unlocked to derive a fresh **Signed One-Time Token (SOTT)**. Immediately after use, the Tesseract rotates, ensuring that no reusable artifact exists for attackers. .. rst-class:: break_before Continuous Access Evaluation (CAEP) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Relock does not just align with CAEP principles — it can act as a **CAEP transmitter**. Whenever in-session events occur (e.g., secret material reuse, rotation, mismatch, or session termination), Relock can emit continuous evaluation signals to relying parties or upstream identity providers. This means Relock provides both: - **Enforcement:** Every request is cryptographically validated; invalid or replayed tokens are blocked in real time. - **Event transmission:** In-session state changes are published as CAEP events, allowing downstream systems to immediately react (e.g., revoke access tokens, flag the account, trigger reauthentication). By serving as a CAEP transmitter, Relock integrates naturally into Zero Trust ecosystems. It ensures not only that untrusted requests are blocked locally, but also that other connected services are informed of the compromise without delay. Relock System Properties ~~~~~~~~~~~~~~~~~~~~~~~~ - **Device & origin binding:** Proofs are valid only from the enrolled browser sandbox and origin that negotiated the Tesseract. - **Server interdependence:** The gateway holds the authoritative version; any mismatch or reuse attempt fails verification. - **High-frequency rotation:** Keys rotate at session start and on a policy-defined cadence (e.g., per request or at fixed intervals). - **Ephemeral tokens:** SOTTs exist only in memory and are single-use, with replay prevention enforced by the gateway by default. - **Visibility signals:** Any unauthorized reuse or version drift immediately triggers server-side detection, rejection, and event signal. - **In-memory only:** Both client and server access the raw Tesseract material only in device memory; it is never stored in unencrypted form. - **CAEP transmitter:** In-session events (reuse, mismatch, termination) can be emitted as Continuous Access Evaluation Protocol (CAEP) signals to inform upstream identity systems or relying parties. .. rst-class:: break_before .. include:: characteristic.rst .. rst-class:: break_before Client-Side Secret Storage ~~~~~~~~~~~~~~~~~~~~~~~~~~ By default, browsers do not store authentication data as unencrypted files. They rely on the operating system’s ACL permissions and secure storage (e.g. Keychain on macOS, DPAPI on Windows, Keystore on Android), combined with origin-based process sandboxing. This means data access is restricted to the browser process itself. In addition, the client-side sotrage is browser-fingerprint bound and incorporates in-memory-only, server-side stored randomization nonces. Even if storage is extracted, it does not guarantee successful use on another device or environment. Extraction of this secret material are far less effective, as an attacker would need to mimic the original device enviroment and still connect to the Relock authentication gateway for the material to be accepted (expose the use). Security Assurance Under Fatal Compromise ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ It is natural to assume that hardware tokens or platform passkeys provide stronger assurance than a browser-bound mechanism such as Relock. In reality, the **security model converges** when we consider a device that has fallen into a fatal state of compromise (root- or kernel-level malware). - **Passkeys** The private key is sealed in a secure enclave or TPM and cannot be exported. However, once the user provides a biometric or PIN gesture, malware with OS control can still invoke the enclave APIs to sign arbitrary challenges on the user’s behalf. - **Hardware tokens** The key material never leaves the USB/NFC token. Yet after the user touches the key, malware can relay signing requests through the normal OS interfaces. The token cannot distinguish a legitimate browser call from a malicious one. - **Relock (Tesseract)** The secret material is bound to the browser sandbox, OS keychain, and server interdependence. During use it must be decrypted in memory, so root-level malware could also access it. Like passkeys or hardware keys, Relock cannot guarantee secrecy on a fully owned device. In a device compromise scenario, all three technologies can be abused in real time. Passkeys and hardware tokens excel at keeping their keys non-extractable, but malware can still use them once unlocked. Relock’s assurance is similar in that regard—but it differs in what happens next: **Relock never produces a long-lived artifact**. Each proof is one-time-use and replay-protected, so compromise is *self-limiting and detectable*, whereas sessions established with passkeys or hardware tokens can still be hijacked and replayed invisibly. .. rst-class:: break_before .. include:: comparison.rst .. include:: compliance.rst .. rst-class:: break_before .. include:: privacy Technical Summary ~~~~~~~~~~~~~~~~~ Relock closes the major gaps of the bearer model — cookie or token replay and adversary-in-the-middle (AiTM) attacks — while providing real-time signals of misuse. The remaining residual risk is concentrated in the areas that no crypto scheme can fully eliminate: same-origin code execution (XSS) and full endpoint compromise. When paired with strict XSS hygiene, a strong origin/TLS posture, and careful server-side binding of SOTTs to intent, Relock delivers a level of **assurance comparable to passkeys or hardware keys** — with the added benefit of continuous protection not only within a single session, but across the entire server–client relationship lifetime.