Authenticator App: Device-Bound Passwordless Login | Cyber Immunity Whitepaper

Overview

This document specifies the Authenticator App protocol - a device-bound, passwordless authentication flow that eliminates the browser as a credential surface. In standard PRISM authentication (Protocol: CMK Authentication), the user enters a password into the Secure Web Enclave (SWE). If the browser is compromised, the password could be captured before blinding. The Authenticator App removes this vector: the user authenticates via biometrics on a mobile device, the App executes threshold authentication against the CMK ORK swarm using a hardware-protected Device Key (DVK), and the resulting blind signature is relayed to the SWE through a transient Home ORK channel.

The App and the SWE cross-verify each other: the App checks Browser Key (BRK) signatures and the return URL TLD before proceeding; the SWE verifies the blind signature cryptographically. ORK responses use three-layer onion encryption, ensuring neither the Home ORK relay nor the browser can read the internal state.

The Authenticator App is a user-facing mobile application for identity verification. It must not be confused with Asgard, which is the backend Dealer Library for server-side cryptographic operations - a separate component.

Loading diagram...

Preconditions

On the Authenticator App

Artifact	Description
DVK ( $a$ )	Device private key, protected by biometrics/secure element
$A = \mathcal{G} \cdot a$	Device public key
`knownGBRK[]`	List of recognized Browser Key public keys (device memory)

On the CMK ORKs (per ORK $i$ )

Artifact	Description
$\text{AppAuthKey}_i$	$\textsf{SHA256}(\text{mSecORK}_i \cdot A)$ - per-ORK device verification value
$\text{CMK}_i$	ORK $i$ 's shard of the user's CMK
$\text{gCMK}$	$\mathcal{G} \cdot \text{CMK}$ - user's CMK public key
$\text{mSecORK}_i$ , $\text{mgORK}_i$	ORK long-term private/public keys
$\text{mAesORK}_i$	ORK symmetric key (derived from ORK seed)

On TideCloak

Artifact	Description
VUID	$\textsf{SHA512}(\text{gUserCMK}).\text{last32bytes}$
gCMKAuth	$\text{gCMK} \cdot \text{CMKmul}$
gVVK, gVRK	Vendor public keys; gVRK signed by VVK
SignedSettings	VVK-signed vendor configuration

Setup Phase: Device Key Registration

One-time operation during account creation, password migration, or account recovery. For new Tide users, the App creates a fresh DVK and registers a new CMK identity (no password is ever set). For existing password-based users, the App verifies the user's password one final time, creates and stores the DVK, pairs the device with the existing CMK, and disables password authentication.

Loading diagram...

Each ORK validates the proof of possession, stores

A

alongside the user's CMK shard, and computes

\text{AppAuthKey}_i = \textsf{DH}(\text{mSecORK}_i, A)

. After setup, each ORK can verify the device key without any ORK knowing

a

- the verification is DH-based, using each ORK's own private key with the device's public key.

Phases 1-3: Initialization, Channel, and Cross-Verification

Loading diagram...

Phase 1 - Non-obvious aspects

The sessKeyProof creates a chain: BRK → VendorSessionKey → session identity → User auth. The sigAppReq proves the request came from the BRK holder where the user signed in. Together they prevent session hijack: a MITM cannot swap session keys without breaking the signature chain.

If no BRK exists in localStorage (new browser, cleared cache), the SWE generates one. This triggers an "unfamiliar browser" warning in Phase 3.

Phase 3 - BRK cross-verification

The four checks form an anti-phishing defense. A phishing page cannot extract the legitimate BRK from another origin's localStorage - it must generate a new one. The App detects the unfamiliar key and exposes the fraudulent TLD. Over time, the App accumulates a list of trusted browser keys (the user's work laptop, home desktop), forming a decentralized device registry without any central authority.

After biometric confirmation unlocks the DVK, the App computes

\sigma_a = \textsf{Sign}_{BRK}(S, \tau)

- a device-key signature over the session context.

Phase 4: Threshold Authentication from App

Loading diagram...

Onion encryption (3 layers - per ORK $i$ )

Each ORK wraps its PreSign response in three encryption layers:

text

┌─────────────────────────────────────────────────────────┐
│  OUTER: ENC_AppAuthᵢ(...)                               │
│  AppAuthᵢ = mgORKᵢ.DH(DVK) - only the App can peel      │
│                                                         │
│  ┌───────────────────────────────────────────────────┐  │
│  │  MIDDLE: ENC_prkECDHᵢ(...)                        │  │
│  │  prkECDHᵢ = NetworkSessionKey.pub.DH(mSecORKᵢ)    │  │
│  │  Transit protection - bound to this session       │  │
│  │                                                   │  │
│  │  ┌─────────────────────────────────────────────┐  │  │
│  │  │ INNER: ENC_mAesORKᵢ(AuthRequest)            │  │  │
│  │  │ ORK's own symmetric key - self-verification │  │  │
│  │  └─────────────────────────────────────────────┘  │  │
│  └───────────────────────────────────────────────────┘  │
│                                                         │
│  timestampᵢ, extᵢ, userPRISMᵢ (alongside middle layer)  │
└─────────────────────────────────────────────────────────┘

The outer layer guarantees only the App (holding DVK) can access ORK responses. The middle layer binds to the NetworkSessionKey (transport protection). The inner layer is self-sealed - only the originating ORK can later decrypt it during the Authenticate phase (challenge solution proof).

Non-obvious aspects

Two-phase signing (PreSign → Authenticate): The separation with nonce commitment (ORK caches gCMKRᵢ indexed by gSessKeyPub) mitigates Wagner birthday attacks on the blind signature scheme. The ORK destroys the cache entry on use, preventing replay.

PRISM interpolation derivation chain: The App Lagrange-interpolates the userPRISMᵢ partials to derive userPRISM, applies voucher-derived deobfuscation (qPub, uDeObf) to recover gUserCMK, then derives CMKmul, VUID, and gCMKAuth. This follows the same CMK authentication pattern specified in Protocol: CMK Authentication.

Authenticate wait timing: The Authenticate call waits 5 seconds for the same

I

ORKs that responded to PreSign (not a fresh threshold), since the cached nonce entries exist only on those nodes.

Phases 5-6: Delivery and Completion

The App encrypts all session artifacts (VUID, blind signature

S

, gRmul, AuthToken, ORK routing data, prkRequest_i values) under gSessKeyPub and relays the SWEEncryptedData through the Home-ORK channel with the negotiated ID. The Home-ORK cannot read the payload.

The App updates its BRK list: if the BRK was new, it is added to knownGBRK[] (evicting the oldest if at capacity); if already known, moved to the top of the LRU cache.

The Secure Web Enclave (SWE) decrypts with sessKey, recovers selfRequestᵢ values by peeling the middle layer (DH(mgORKᵢ, SessKey)), and constructs
VendorEncryptedData

= ENC_{gVRK}(VUID, S, gRmul, AuthToken)

.
The SWE redirects to TideCloak with VendorEncryptedData.

localStorage: The SWE stores the BRK (always, after App authentication). Session metadata (username, sessKey, ORK addresses, expiry) is stored only if rememberMe is set. TideCloak proceeds with the standard VVK JWT signing flow (Article 5, Protocol: VVK JWT Signing).

Algorithms

Algorithm 2: Onion Encryption (per ORK , PreSign response)

Input:

\text{AuthRequest}

\text{mAesORK}_i

\text{prkECDH}_i

\text{AppAuth}_i

\tau_i

\text{ext}_i

\text{userPRISM}_i

Output:

\text{encRequest}_i

(three-layer encrypted payload)

$\text{selfRequest} \leftarrow \textsf{AES256\_ENC}_{\text{mAesORK}_i}(\text{AuthRequest})$
$\text{prkRequest}_i \leftarrow \textsf{AES256\_ENC}_{\text{prkECDH}_i}(\text{selfRequest})$
$\text{encRequest}_i \leftarrow \textsf{AES256\_ENC}_{\text{AppAuth}_i}(\text{prkRequest}_i \;\|\; \tau_i \;\|\; \text{ext}_i \;\|\; \text{userPRISM}_i)$
return $\text{encRequest}_i$

Where:

$\text{prkECDH}_i = \textsf{DH}(\text{gNetworkSessionKey},\; \text{mSecORK}_i)$
$\text{AppAuth}_i = \textsf{DH}(\text{mgORK}_i,\; \text{DVK})$
$\text{AuthRequest} = \{\text{userID},\; \text{purpose}=\text{``auth''},\; \text{expiry}=\tau_i + \text{ext}_i,\; \text{clientKey}=\text{gNetworkSessionKey}\}$

Algorithm 3: Blind Signature Assembly (App-side)

Input:

\{\text{encSig}_i\}_{i \in \mathcal{V}}

\{\text{AppAuth}_i\}_{i \in \mathcal{V}}

, blinding factor

r_4

\text{gCMKAuth}

\text{gRmul}

\text{AuthToken}

Output: Verified signature

S

\bot

for each $i \in \mathcal{V}$ : $S_i \leftarrow \textsf{AES\_DEC}_{\text{AppAuth}_i}(\text{encSig}_i)$
$\text{blindS} \leftarrow \sum_{i \in \mathcal{V}} S_i$
$S \leftarrow \textsf{unblindSignature}(\text{blindS},\; r_4)$
$\text{isValid} \leftarrow \textsf{verifySig}_{gCMKAuth}(S,\; \text{gRmul},\; \text{AuthToken})$
if $\lnot\text{isValid}$ : return $\bot$
return $S$

The blind signature construction follows the double-blind threshold scheme specified in Protocol: CMK Authentication. The $\textsf{unblindSignature}$ operation removes $r_4$ (the SWE's blinding factor from $\textsf{genBlindMessage}$ ).

Notation Reference

Symbol	Description
$\mathcal{G}$	Generator point on the elliptic curve
DVK / $a$	Device private key (biometric-protected)
$A = \mathcal{G} \cdot a$	Device public key
BRK / $d$	Browser Key (persistent, localStorage)
$D = \mathcal{G} \cdot d$	Browser Key public point
$\sigma_d$	BRK signature: $\textsf{Sign}_d(S, \tau)$ (MATH); `BRK.sign(appReq)` (LLD)
$\sigma_a$	Device signature: $\textsf{Sign}_a(S, \tau)$
`knownGBRK[]`	App's list of recognized BRK public keys
NetworkSessionKey / $s$	Ephemeral ORK communication key
$S = \mathcal{G} \cdot s$	NetworkSessionKey public point (= `gSessKeyPub`)
VendorSessionKey	Ephemeral key for BRK proof signing and App cross-verification
`sessKeyProof`	$\textsf{VendorSessionKey.sign}(\text{BRK.pub})$
$\text{AppAuth}_i$	$\textsf{SHA256}(\text{mSecORK}_i \cdot A)$ - per-ORK device verification
$\text{prkECDH}_i$	$\textsf{DH}(S, \text{mSecORK}_i)$ - transit ECDH key
$\text{userPRISM}_i$	$\text{Ytag} \cdot \text{CMK}_i$ - partial PRISM contribution
$S_i$ / $S$	Partial / final unblinded authentication signature
gCMKAuth	$\text{gCMK} \cdot \text{CMKmul}$ - user's authentication verifier
VUID	$\textsf{SHA512}(\text{gUserCMK}).\text{last32bytes}$
SWEEncryptedData	Session artifacts encrypted under $\text{gSessKeyPub}$
VendorEncryptedData	Auth artifacts encrypted under $\text{gVRK}$

Actors

Actor	Description	Trust Assumption
User	Initiates login via browser, confirms via mobile biometrics.	Physically possesses registered device and passes biometric.
Secure Web Enclave (SWE)	Browser JS module. Generates session keys + BRK, opens relay channel, renders QR, receives blind signature.	Operates as untrusted dealer. App cross-verifies via BRK signatures and TLD.
Authenticator App	Mobile application. Holds DVK, maintains knownGBRK (encrypted at rest with DVK), enforces biometric gating, executes threshold auth.	Trusted with biometrics (device OS security). DVK protected by secure element.
Home ORK	Relay node facilitating the QR-mediated channel.	Untrusted relay. Forwards encrypted messages; cannot decrypt (lacks session keys).
CMK ORKs	20 nodes holding CMK shards. Validate device identity, produce partial blind signatures.	Standard threshold trust ( $\leq 13$ may collude). Each validates independently.
TideCloak	Issues vouchers; receives VendorEncryptedData after completion.	Trustless agent. Cannot observe credentials or blind signature in cleartext.

Layer Traversal

Layer	How the 2FA Protocol Engages It
Legitimacy	BRK cross-verification establishes browser identity. Biometric gating establishes user presence. VVK-signed settings verification establishes vendor authenticity.
Authority	CMK ORKs hold user key shards. DVK-derived AppAuthKey enables per-ORK device verification without exposing the private key.
Agency	Primary layer. The App executes threshold authentication (partial blind signatures from CMK ORKs). Forseti governs ORK participation via voucher validation.
Settlement	Voucher acquisition from TideCloak. Each ORK validates voucher with "signin" action before participating. See Article 8: The Settlement Layer.

Security Properties

Property	Mechanism	Assumption
Credential-free browser	Password/biometric never enters the browser. SWE receives only the blind signature.	-
Device key binding	DVK protected by secure element + biometrics. Per-ORK AppAuthKey verification ( $\textsf{SHA256}(\text{mSecORK}_i \cdot A)$ ) confirms device without exposing $a$ .	Mobile OS secure element integrity
BRK cross-verification	Unfamiliar BRKs trigger user warning. Known BRKs provide device memory (decentralized device registry).	-
Anti-phishing	TLD extraction + BRK recognition. Phishing pages generate new BRKs (cannot extract from legitimate origin's localStorage) and expose fraudulent TLDs.	Browser same-origin policy
Onion encryption (3 layers)	Outer: AppAuth (device binding). Middle: prkECDH (transit). Inner: mAesORK (self-verification). Home ORK relay and SWE cannot read internal state.	ECDH and AES security
Transient channel	Home ORK channel is session-scoped. No persistent state after use.	-
Threshold resilience	14 of 20 CMK ORKs must participate. Standard threshold assumptions.	$\leq 13$ compromised nodes
Two-phase signing	PreSign → Authenticate with nonce commitment (`Committed=TRUE`). Mitigates Wagner birthday attacks. Cache destroyed on use (replay prevention).	DLP hardness
Biometric gating	DVK access requires biometric confirmation. Two factors: device possession + biometric.	Device biometric sensor integrity
Cross-verification (mutual)	App verifies SWE (BRK chain, VVK settings, TLD). SWE verifies App (blind signature against gCMKAuth). ORKs verify both (AppAuthKey, Forseti).	-

Call Summary

Call	Direction	Purpose
Initiate channel	SWE → Home ORK	Establish transient relay tunnel
QR code	SWE → User screen	Encode HomeORK URI + channel ID
getDetails	App → Home ORK → SWE	Retrieve session context, BRK signatures, TLD for cross-verification
PreSign/DeviceAuth	App → all $n$ CMK ORKs	Initiate threshold auth. ORKs validate device + return onion-encrypted state
Authenticate	App → $I$ CMK ORKs	Submit blinded challenge. ORKs return partial blind signatures
Relay	App → Home ORK → SWE	Deliver SWEEncryptedData (blind signature + routing data)
Redirect302	SWE → TideCloak	Forward VendorEncryptedData to complete OIDC flow

References

Hall, J. L., Hertzog, Y., et al. (2023). Manifesting Unobtainable Secrets: Threshold Elliptic Curve Key Generation using Nested Shamir Secret Sharing. arXiv:2309.00915. Presented at AustMS 2021.
Tide Developer Documentation: docs.tidecloak.com

Overview

Preconditions

On the Authenticator App

On the CMK ORKs (per ORK ii)

On TideCloak

Setup Phase: Device Key Registration

Phases 1-3: Initialization, Channel, and Cross-Verification

Phase 1 - Non-obvious aspects

Phase 3 - BRK cross-verification

Phase 4: Threshold Authentication from App

Onion encryption (3 layers - per ORK ii)

Non-obvious aspects

Phases 5-6: Delivery and Completion

Algorithms

Notation Reference

Actors

Layer Traversal

Security Properties

Call Summary

References

On the CMK ORKs (per ORK $i$ )

Onion encryption (3 layers - per ORK $i$ )