BYOiD/PROTOCOL

PRISM: Threshold Oblivious Pseudorandom Authentication

Formal specification of the PRISM TOPRF construction: distributed password verification that eliminates credential storage and renders offline brute-force attacks inapplicable.

20 min read

Overview

PRISM is a Threshold Oblivious Pseudorandom Function (TOPRF) that replaces stored password hashes with a distributed, zero-knowledge, live computation. The password verification function cannot be constructed without real-time interaction with a threshold of independently operated nodes - eliminating the entire attack class of offline brute-force against exfiltrated credential stores.
The construction extends the OPRF primitive formalized in RFC 9497 into a threshold setting across the ORK network. The formal analysis is published in "Towards Zero Trust Authentication in Critical Industrial Infrastructures with PRISM" (Springer, CIMSS2023).
PRISM operates as one of two parallel sub-protocols within the CMK Authentication Ceremony (Protocol: CMK Authentication). Both share the same two API round-trips. This document specifies PRISM in isolation; the ceremony orchestration is described separately.
Loading diagram...

Preconditions

Established during user registration (Protocol: Account Creation / KeyGen).
Per-ORK stored state:
  • sis_i - Shamir shard of joint PRISM secret ss. Reconstruction requires tt shards; individual shards reveal nothing about the password.
  • vi=H(mSecORKi(GH(Ys)))v_i = H(\mathit{mSecORK}_i \cdot (G \cdot H(Y \cdot s))) - PRISM verifier, derived from both the ORK's private key and the correct password-PRISM product. Unique per ORK. Rotates on password change. One compromised verifier is useless without the distributed PRISM product.
  • aesKeyi\mathit{aesKey}_i - ORK's symmetric key (for self-sealing challenges).
  • mSecORKi\mathit{mSecORK}_i, mgORKi\mathit{mgORK}_i - ORK's long-term key pair.
ORK isolation property: ORKs store no metadata about which vendors a user is associated with or how many. The PRISM shards carry no semantic information about their purpose.

Actors & Trust Assumptions

ActorRoleTrust Assumption
Secure Web EnclaveUser's browser-side cryptographic agent. Generates jj, sends obfuscated password, performs interpolation and challenge decryption.Potentially adversarial. An adversary using a malicious SWE learns meaningless YsY \cdot s (wrong PRISM product) but not ss or any individual sis_i. Cannot offline attack passwords remotely. Honest user using a malicious SWE can get password phished - SRI is the mitigation for that.
CMK ORK Swarm (20 nodes)Each applies its shard sis_i to the obfuscated input. Constructs and verifies challenges.Malicious ORK learns XX (obfuscated password point) but not Y. Can't offline attack YY. Up to 13 may be safely malicious/colluding. Each operated independently.
Settlement LayerFunds each ORK call via one-time voucher.Provides auxiliary deobfuscation values (YtagY_{\text{tag}}, qPubq_{\text{Pub}}, uDeObfu_{\text{DeObf}}).

Protocol Flow

Convert: SWE → All nn ORKs

Loading diagram...
The ORK learns nothing about YY - it applies sis_i to the already-obfuscated point XX. The result Xi=YjsiX'_i = Y \cdot j \cdot s_i is doubly obscured by jj (SWE) and sis_i (this ORK).
The challenge has three nested encryption layers, each serving a distinct security function:
text
┌──────────────────────────────────────────────────────────┐
│  OUTER: AES under v_i (PRISM verifier)                   │
│  Only the correct password holder can strip this layer   │
│                                                          │
│  ┌────────────────────────────────────────────────────┐  │
│  │  MIDDLE: AES under DH(mSecORK_i, U)                │  │
│  │  Binds to this browser session                     │  │
│  │                                                    │  │
│  │  ┌──────────────────────────────────────────────┐  │  │
│  │  │  INNER: AES under aesKey_i                   │  │  │
│  │  │  Self-sealed - only this ORK can reopen      │  │  │
│  │  │                                              │  │  │
│  │  │  uid, purpose, t_i, ext_i, U                 │  │  │
│  │  └──────────────────────────────────────────────┘  │  │
│  └────────────────────────────────────────────────────┘  │
│                                                          │
│  t_i, ext_i (timing metadata)                            │
└──────────────────────────────────────────────────────────┘
The expiry window exti\mathit{ext}_i is randomized per-ORK: 1-3 hours if remember-me is set, 30-90 seconds otherwise.

SWE Processing: Threshold Reconstruction

The SWE waits up to 1 second for all nn or 5 seconds for the first tt responses, recording participating ORKs in a bitwise array.
The SWE learns YsY \cdot s but not any individual sis_i. No ORK learned YY. The obfuscator jj is cleanly removed. If the password was wrong, the derived value is incorrect and all subsequent steps fail.

SWE Processing: Verifier Derivation and Challenge Decryption

By ECDH commutativity: DH(mgORKi,GH(Ys))=mSecORKi(GH(Ys))\textsf{DH}(\mathit{mgORK}_i, G \cdot H(Y \cdot s)) = \mathit{mSecORK}_i \cdot (G \cdot H(Y \cdot s)), so vi=viv'_i = v_i when the password is correct. If the password was wrong, viviv'_i \neq v_i, the outer-layer decryption produces garbage, and all subsequent layers fail. The SWE cannot distinguish a wrong password from a corrupted response.
The inner layer (self-sealed under aesKeyi\mathit{aesKey}_i) remains opaque to the SWE - only the originating ORK can open it.

Authenticate: SWE → II Participating ORKs

Loading diagram...
Each ORK retrieves and destroys its cache entry indexed by UU, then decrypts the self-sealed capsule and verifies uid, session binding, and expiry. A wrong password means the SWE could never have correctly decrypted layers to recover the authentic selfRequesti\mathit{selfRequest}_i, so the ORK's verification fails.

Algorithms

Notation Reference

SymbolDescription
GGGenerator point on Curve25519
AbA \cdot bScalar-point multiplication (point AA, scalar bb)
H()H(\cdot)SHA-256 unless stated otherwise
H2P()\textsf{H2P}(\cdot)Hash-to-point via Elligator 2 on Curve25519
DH(a,B)\textsf{DH}(a, B)Diffie-Hellman: BaB \cdot a
AES_ENC(a,b)\textsf{AES\_ENC}(a, b)AES256 encryption of b with key aa (IV is omitted for simplicity)
AES_DEC(a,b)\textsf{AES\_DEC}(a, b)AES256 decryption of b with key aa
wwUser's password
YYPassword-derived curve point: YH2P(H(w))Y \leftarrow \textsf{H2P}(H(w))
uid\mathit{uid}User identifier: H(username)H(\text{username})
ss, sis_iJoint PRISM secret , ORK ii's PRISM shard
jjRandom obfuscator scalar (SWE-generated)
XXObfuscated password point: YjY \cdot j
mSecORKi\mathit{mSecORK}_iORK ii's long-term private key
mgORKi\mathit{mgORK}_iORK ii's long-term public key: GmSecORKiG \cdot \mathit{mSecORK}_i
aesKeyi\mathit{aesKey}_iORK ii's symmetric key
viv_iPer-ORK PRISM verifier: H(mSecORKi(GH(Ys)))H(\mathit{mSecORK}_i \cdot (G \cdot H(Y \cdot s)))
UU, uuNetwork session public/private key (non-extractable via WebCrypto)
nnTotal ORKs in swarm (currently 20)
ttThreshold (currently 14)
IINumber of responding ORKs (tInt \le I \le n)
LiL_iLagrange coefficient for ORK ii

Layer Traversal

LayerHow PRISM Engages It
LegitimacyVoucher validates each Convert call. ECDH between UU and mgORKi\mathit{mgORK}_i qualifies the channel.
AuthorityEach ORK retrieves its PRISM shard sis_i - undifferentiated key material, agnostic to purpose.
AgencyThe TOPRF evaluation (XsiX \cdot s_i) and challenge construction are the purpose-specific operations.
SettlementVoucher funds participation. Returns auxiliary values (YtagY_{\text{tag}}, qPubq_{\text{Pub}}, uDeObfu_{\text{DeObf}}) used by the parallel CMK sub-protocol.

Security Properties

PropertyMechanismAssumption
Password never leaves browserYY obfuscated by jj before transmission; ORKs see only X=YjX = Y \cdot jObfuscator cryptographically random
No party learns the passwordPRISM: ORKs apply sis_i to obfuscated point; SWE reconstructs YsY \cdot s but not individual sis_i; ORKs never see YYThreshold (<t< t compromised). PRISM security
H2PH2P prevents SWE offline attackSWE reconstructs YsY \cdot s but because H2P(password)G?\textsf{H2P(password)} \gets G \cdot ? and the SWE doesn't know ss, offline attack can't be performedDLP security
Per-ORK verifiers prevent offline attackEach viv_i bound to ORK ii's private key; rotates on password change; one compromised ORK yields one verifier useless without the PRISM productDLP hardness on Curve25519. Threshold assumption
Offline brute-force inapplicableVerification function is emergent property of live threshold interaction; cannot be replicated offline; each guess requires network round-trip to t\ge t nodesNetwork rate limiting. Threshold assumption
Wrong password indistinguishableOuter-layer decryption fails silently; SWE cannot determine which layer failedAES ciphertext indistinguishability
Replay resistanceCache entry indexed by UU destroyed on use; challenge triple-encrypted and time-boundedORK correctly destroys entries
Session bindingMiddle layer encrypted under DH(mSecORKi,U)\textsf{DH}(\mathit{mSecORK}_i, U); uu is non-extractable via WebCryptoWebCrypto API integrity
Mutual password proofSWE proves knowledge by decrypting challenges; ORKs confirm by verifying self-sealed capsuleChallenge construction integrity
14-of-20 fault toleranceAny tt ORKs suffice for PRISM reconstruction-
13-of-20 security toleranceUp to ntn - t ORKs may be actively maliciousThreshold assumption

Call Summary

CallDirectionPayload (PRISM component)State Change
ConvertSWE → all nn ORKsSend: uid\mathit{uid}, XX, UU, voucher. Receive: XiX'_i, encRequesti\mathit{encRequest}_iORK creates cache entry indexed by UU
AuthenticateSWE → II participating ORKsSend: selfRequesti\mathit{selfRequest}_i. Receive: ack or failORK destroys cache entry
Between calls, the SWE performs all interpolation, verifier derivation, and challenge decryption client-side.

References

  • 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 9497 - Oblivious Pseudorandom Functions (OPRFs) Using Prime-Order Groups. IETF, 2023.
  • Tide Developer Documentation: docs.tidecloak.com
Related Protocol Articles: