CMK Authentication Ceremony | Cyber Immunity Whitepaper

Overview

This document specifies the end-to-end CMK Authentication Ceremony - the orchestrated flow that interleaves PRISM password verification (Protocol: PRISM) and the Double-Blind Threshold Signature Scheme (Protocol: Double-Blind TSS) into exactly two sequential API calls between the browser Secure Web Enclave (SWE) and the ORK swarm, followed by token delivery to TideCloak. Both API calls carry data for both sub-protocols in the same messages.

The ceremony produces a standard OIDC-compatible token, signed via a vendor-unlinkable threshold blind signature, with DPoP session binding - all without any party holding the password, the signing key, or the ability to forge tokens.

Loading diagram...

Preconditions

User-side: Username and password. Optionally, a remember-me flag or stored authentication token.

Per-ORK stored state: PRISM share

s_i

, CMK share

x_i

, PRISM verifier

v_i

, public key

\mathit{gCMK}

, ORK key material (

\mathit{aesKey}_i

\mathit{mSecORK}_i

\mathit{mgORK}_i

). Established during registration (Protocol: Account Creation / KeyGen).

TideCloak (Vendor's IAM) state:

\mathit{gVVK}

\mathit{gVRK}

+ signature, signed settings (registration policy, return URL), session identifier.

Phase 0: Setup and SWE Initialization

Step 0.1 - SWE Download and Verification

The browser downloads the Secure Web Enclave from the vendor's designated Home-ORK but can be served by any network node. Correctness does not depend on which node serves it - the user may rehome at any time. The SWE package is SRI-verifiable; expected hashes are published by Tide and community sources.

Step 0.2 - Vendor Trust Establishment

The SWE receives from TideCloak redirect:

\mathit{gVVK}

\mathit{gVRK}

+ its signature, signed settings, and session identifier. It verifies all signatures against

\mathit{gVVK}

The SWE implicitly trusts any

\mathit{gVVK}

without a PKI chain: the user identity derived (

\mathit{gVVK} \cdot x

) is inherently bound to the vendor that paid via the voucher system. A malicious party supplying a different

\mathit{gVVK}'

would produce identities bound to itself, not to the target vendor. The return URL signature ensures no attacker can redirect results using an honest vendor's key.

Step 0.3 - Session Key Generation

The SWE generates two ephemeral key pairs as non-extractable via the WebCrypto API (extractable: false):

Network session key pair $(u, U)$ - ECDH with ORK swarm and cache indexing. Private key $u$ cannot be exported or read by any JavaScript context.
Vendor session key pair $(k, K)$ - embedded in the authentication token. Approves of any DPoP keys from client. Plays no role in ORK communication.

Step 0.4 - User Input and Derivation

The user enters username and password, optionally setting remember-me. The SWE computes:

\mathit{uid} \leftarrow H(\text{username}), \quad Y \leftarrow \textsf{H2P}(password), \quad j \overset{\$}{\gets}

ℤ

_\ell, \quad X \leftarrow Y \cdot j

Step 0.5 - Swarm Roster and Voucher Acquisition

The SWE queries the home-ORK for:

\mathit{gCMK}

, all

n

ORK URLs, identifiers

\mathit{id}_i

, and public keys

\mathit{mgORK}_i

for the designated

\mathit{uid}

. It then acquires one-time vouchers from the Settlement Layer, which also returns auxiliary values

Y_{\text{tag}}

q_{\text{Pub}}

u_{\text{DeObf}}

for identity recovery.

Phase 1+2: Convert (Round-Trip 1)

The Convert call carries data for both sub-protocols simultaneously: the PRISM decentralized authentication and the double-blind signature protocols. A single API call from the SWE to all

n

CMK ORKs.

Loading diagram...

Throttling: If

\mathit{uid}

or source IP address has exceeded the rate limit, the ORK rejects immediately. This enforces network-level rate limiting against brute-force attempts.

Key healing: If the SWE-provided digest (

\mathit{mDigest}

) differs from the ORK's local copy, the ORK initiates key healing before proceeding - ensuring the swarm operates on consistent state.

Convergence wait: The SWE waits up to 1 second for all

n

responses, or up to 5 seconds for the first

t

(14) responses, then records participants in

\mathit{ORKsBitwise}

with count

I

Client-Side Processing (Between Round-Trips)

All cryptographic work between the two API calls is performed entirely client-side by the SWE. No network communication occurs.

PRISM processing (Algorithm references from Protocol: PRISM):

Threshold reconstruction: interpolate $\{X'_i\}$ → $Y \cdot s$ (PRISM Algorithm 1)
Verifier derivation: compute each individual ORK verifier $v'_i$ for all $n$ ORKs (PRISM Algorithm 2)
Challenge decryption: peel three encryption layers, recover $\mathit{selfRequest}_i$ for each responding ORK
Session timing: median of ORK timestamps; expiry from minimum $\mathit{ext}_i$ values

BlindSig processing (Algorithm references from Protocol: Double-Blind TSS):

Decrypt identity shares: $\mathit{userPRISM}_i \leftarrow \textsf{AES\_DEC}_{v'_i}(\mathit{enc}(\mathit{userPRISM}_i))$ - Coupling to successful PRISM verification
Identity recovery: interpolate $\mathit{userPRISM}_i$ , apply voucher deobfuscation → $\mathit{gUserCMK}$ (Double-Blind TSS Algorithm 1)
Credential derivation: $\mathit{CMKmul}$ , $\mathit{VUID}$ , $\mathit{gCMKAuth}$ from $\mathit{gUserCMK}$
Nonce aggregation: $\mathit{gCMKR} \leftarrow \sum R_i$
Token message construction: $m \leftarrow \{\mathit{VUID}, \text{``auth''}, \mathit{expiry}, K, \mathit{sessionId}, \mathit{DPoPApproval}\}$
Blind message preparation: $\textsf{genBlindMessage}$ → $\mathit{blurH}$ , $j_4$ (Double-Blind TSS Algorithm 2)

Phase 1+2: Authenticate (Round-Trip 2)

The Authenticate call again carries data for both sub-protocols. Sent to the

I

ORKs that participated in Convert.

Loading diagram...

The ORK performs PRISM verification first PRISM Algorithm 5. Only if authentication succeeds does it compute the partial blind signature (Double-Blind TSS Algorithm 3). This gating ensures no blind signatures are produced for unauthenticated users.

Convergence wait: The SWE waits up to 5 seconds for all

I

responses. If any ORK that participated in Convert fails to respond to Authenticate, the nonce commitment is broken and the ceremony must restart (see Failure Recovery below).

Phase 3: Token Delivery and OIDC Authorization

Signature Assembly

The SWE decrypts all partial signatures, aggregates, and unblinds:

S_i \leftarrow \textsf{AES\_DEC}_{\textsf{DH}(\mathit{mgORK}_i, u)}(\mathit{encSig}_i) \quad \forall\, i \in S

\mathit{blindS} \leftarrow \sum S_i, \quad S \leftarrow \mathit{blindS} \cdot j_4^{-1}, \quad R \leftarrow \mathit{gCMKR} \cdot j_4^{-1}

The SWE verifies the assembled signature locally:

G \cdot S \stackrel{?}{=} R + H(R, \mathit{gCMKAuth}, m) \cdot \mathit{gCMKAuth}

Encrypt for Vendor

\mathit{VendorEncryptedData} \leftarrow \textsf{ENC}_{\mathit{gVRK}}(\mathit{VUID}, \mathit{gCMKAuth}, (R, S), m)

Remember-Me Storage (Optional)

If remember-me was set, the SWE stores session context in browser local storage: username, network session key reference, persona,

\mathit{gCMK}

, ORK metadata,

\mathit{ORKsBitwise}

\mathit{selfRequest}_i

, and the computed expiry.

Session binding guarantee: The network session private key

u

is non-extractable from the WebCrypto keystore and is referenced inside each self-sealed capsule (the ORK verifies the ECDH shared secret derived from

U

). A stolen

\mathit{selfRequest}_i

cannot be used without the ability to perform ECDH operations with

u

- which cannot be exported via any JavaScript API.

Redirect to IAM

The browser redirects to TideCloak (the Vendor's IAM) with

\mathit{VendorEncryptedData}

and the session identifier.

Authorization Processing

TideCloak decrypts using the vendor's ephemeral private key

\mathit{VRK}

, verifies the double-blind signature against

\mathit{gCMKAuth}

, and generates a standard OIDC authorization code.

OIDC Code Exchange and VVK JWT Signing

The vendor application exchanges the authorization code (PKCE) for a JWT access token. The JWT is signed via a separate distributed signing ceremony across the vendor's VVK ORK swarm - ensuring no single party holds the vendor's token-signing key. The VVK ORKs independently verify the double-blind signature and all JWT claims before signing. Session integrity is enforced via DPoP binding to the non-extractable session keys. The VVK Temper-Proof Authorization flow is specified in a separate article.

Stored Authentication Variant (Remember-Me)

When a stored authentication token exists and has not expired, the ceremony can skip password entry entirely.

Loading diagram...

The stored

\mathit{selfRequest}_i

values serve as pre-authenticated tokens - the ORK can decrypt the self-sealed capsule because it encrypted it with its own symmetric key. The ECDH shared secret derived from the stored session key

U

validates that the request originates from the same browser context. The PRISM password-conversion step is entirely skipped; authentication rests on the stored capsules and their non-extractable session key binding.

The stored token expires based on the minimum

\mathit{ext}_i

window set during the original ceremony (1-3 hours for remember-me). After expiry, the full password ceremony is required.

Failure Recovery

ORK drops between Convert and Authenticate. If any ORK that participated in Convert fails to respond to Authenticate, the nonce commitment set is inconsistent (

\mathit{ORKsBitwise}

no longer matches). The SWE must restart with a new Convert call. If within the session expiry window and the PRISM product has already been computed, the SWE can use the stored authentication variant - skipping password re-entry.

Fewer than

t

ORKs respond to Convert. The ceremony cannot proceed. The SWE retries after a timeout. Persistent failure indicates network degradation beyond the fault tolerance threshold.

PRISM verification fails (wrong password). The ORK increments its per-

\mathit{uid}

throttle counter and returns failure. After repeated failures, the

\mathit{uid}

is throttled network-wide. The SWE cannot distinguish a wrong password from a corrupted response.

Local signature verification fails. The assembled signature

(R, S)

does not verify against

\mathit{gCMKAuth}

. This indicates either a malicious ORK contributed an incorrect partial signature, or the participation set changed between rounds. The SWE restarts the ceremony.

Notation Reference

This ceremony composes primitives from two sub-protocols. Notation defined in:

Protocol: PRISM - $Y$ , $s_i$ , $j_1$ , $X$ , $v_i$ , $\mathit{encRequest}_i$ , $\mathit{selfRequest}_i$
Protocol: Double-Blind TSS - $x_i$ , $\mathit{CMKmul}$ , $\mathit{gCMKAuth}$ , $\mathit{VUID}$ , $j_4$ , $\mathit{blurH}$ , $R_i$ , $S_i$

Additional ceremony-level notation:

Symbol	Description
$(u, U)$	Network session key pair (non-extractable via WebCrypto). Used for ECDH with ORKs and DPoP.
$(k, K)$	Vendor session key pair (non-extractable via WebCrypto). Embedded in token for DPoP.
$\mathit{gVVK}$	Vendor's long-term public key
$\mathit{gVRK}$	Vendor's ephemeral payment/session public key (rotated per payment cycle, signed by $\mathit{gVVK}$ )
$\mathit{VendorEncryptedData}$	Token payload encrypted under $\mathit{gVRK}$ for delivery to TideCloak
$\mathit{ORKsBitwise}$	Bitwise array indicating which ORKs participated in Convert
$\textsf{AES\_DEC}_{a}(B)$	AES256 decryption of message $B$ with key $a$
$\textsf{ENC}_{A}(B)$	X25519-based El-Gamal encryption of message $B$ with public key $A$
PKCE	Proof Key for Code Exchange - standard OIDC mechanism (RFC7636) for binding authorization codes to a client-generated secret

Actors and Trust Assumptions

Actor	Role	Trust Assumption
Secure Web Enclave	Browser-side cryptographic agent. Orchestrates both sub-protocols, assembles final token. SRI-verifiable, rehomeable.	Potentially adversarial. See malicious SWE analysis in Protocol: Double-Blind TSS.
Home ORK	Serves swarm roster (public metadata only).	No elevated trust. Compromised home ORK can return stale roster but cannot influence ceremony.
CMK ORK Swarm (20 nodes)	Hold PRISM shares and CMK shares. Execute both sub-protocols.	Up to 13 may be malicious. Each operated independently.
TideCloak	Keycloak-based IAM. Initiates redirect, verifies signed token, issues OIDC codes.	Holds $\mathit{gVVK}$ (public), signed settings, ephemeral keys. Never possesses VVK private key.
VVK ORK Swarm	Signs JWTs via separate threshold ceremony.	Separate trust domain from CMK ORKs.
Settlement Layer	Funds operations via one-time vouchers. Returns auxiliary values for identity recovery.	See Article 8: The Settlement Layer.

Layer Traversal

Layer	How the Ceremony Engages It
Legitimacy	Voucher validates each Convert call. ECDH between $U$ and $\mathit{mgORK}_i$ qualifies the channel and binds the session.
Authority	Each ORK retrieves its Shamir shares ( $s_i$ , $x_i$ ) - undifferentiated key material, agnostic to purpose.
Agency	PRISM evaluation and partial blind signature are the purpose-specific MPC operations.
Settlement	Voucher funds participation, binds operation to paying vendor, provides auxiliary deobfuscation values, ensures cross-vendor isolation.

Security Properties

Properties inherited from sub-protocols are referenced, not restated. This table covers ceremony-level properties only.

Property	Mechanism	Assumption
Two round-trips suffice	PRISM and CMK data multiplexed in same Convert/Authenticate calls	Protocol design
Sub-protocol coupling	CMK identity shares encrypted under PRISM verifier $v_i$ ; blind signing gated on PRISM verification	Correct ORK implementation
DPoP session binding	Both $(u, U)$ and $(k, K)$ generated as `extractable: false` via WebCrypto; $K$ embedded in token $m$	WebCrypto API integrity
Non-extractable session keys	$u$ cannot be exported; ECDH with $u$ required for ORK communication and remember-me replay	WebCrypto API integrity (software-level)
Remember-me security	Stored $\mathit{selfRequest}_i$ bound to non-extractable $u$ ; time-limited by $\mathit{ext}_i$ ; ORK cache destroyed on use	WebCrypto + ORK cache discipline
Vendor trust without PKI	SWE trusts any $\mathit{gVVK}$ because identity is bound to vendor via voucher; forged $\mathit{gVVK}'$ creates identities bound to itself	Settlement Layer integrity
Transport-independent security	All properties independent of TLS; distributed ceremony provides equivalent guarantees	Cryptographic construction
Vendor key protection	JWT signed via separate VVK ORK swarm; vendor never possesses signing key	Separate threshold assumption
Anonymity via vouchers	No single party correlates vendor + user + ORK identity simultaneously	Settlement Layer construction
User sovereignty	SWE SRI-verifiable and rehomeable to any node	User verifies SRI from independent sources

For PRISM-specific properties (offline attack resistance, mutual password proof, replay resistance), see Protocol: PRISM. For signature-specific properties (double-blind construction, vendor unlinkability, malicious SWE containment, domain separation), see Protocol: Double-Blind TSS.

Call Summary

Call	Direction	PRISM Component	CMK Component
Convert	SWE → all $n$ ORKs	Send: $\mathit{uid}$ , $X$ , $U$ , voucher. Receive: $X'_i$ , $\mathit{encRequest}_i$	Receive: $R_i$ , $\textsf{AES\_ENC}_{v_i}(\mathit{userPRISM}_i)$
Authenticate	SWE → $I$ participating ORKs	Send: $\mathit{selfRequest}_i$ . ORK verifies.	Send: $\mathit{blurH}$ , $\mathit{ORKsBitwise}$ . Receive: $\mathit{encSig}_i$

Between calls, the SWE performs all interpolation, deobfuscation, verifier derivation, challenge decryption, identity recovery, credential derivation, and blind message preparation client-side.

References

Hall, J. L., Hertzog, Y., et al. (2023). Manifesting Unobtainable Secrets: Threshold Elliptic Curve Key Generation using Nested Shamir Secret Sharing. arXi\v
.00915. Presented at AustMS 2021.
Wang, F., Hertzog, Y., et al. (2023). Towards Zero Trust Authentication in Critical Industrial Infrastructures with PRISM. ACNS 2023 Workshops, LNCS 13907. Springer, Cham.
RFC 9449 - OAuth 2.0 Demonstrating Proof of Possession (DPoP). IETF, 2023.
RFC 9497 - Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups. IETF, 2023.
RFC 7636 - Proof Key for Code Exchange by OAuth Public Clients. IETF, 2015.
Tide Developer Documentation: docs.tidecloak.com