Crate scal3

Sole Control Assurance Level 3

Verify that systems operate under your sole control. SCAL3 provides verifiable sole control assurance levels with tamper-evident logs for multi-factor authentication transparency. This prototype contains example functions and data.

Do not use this code for production. The specification has not been finalized and the security of this prototype code has not been evaluated. The code is available for transparency and to enable public review.

Legal

Patent NL2037022 pending.

Copyright Cleverbase ID B.V. 2024. The code and documentation are licensed under Creative Commons Attribution-NonCommercial 4.0 International.

To discuss other licensing options, contact Cleverbase.

Example application context

A provider manages a central hardware security module (HSM) that performs instructions under sole control of its subscribers. Subscribers use a mobile wallet app to authorize operations using a PIN code.

To achieve SCAL3, the provider manages three assets:

• a public key certificate to link the subscriber to enrolled keys, e.g. applying X.509 (RFC 5280);
• a tamper-evident log to record evidence of authentic instructions, e.g. applying Trillian;
• a PIN attempt counter, e.g. using HSM-synchronized state.

To enroll for a certificate, the subscriber typically uses a protocol such as ACME (RFC 8555). The certificate binds to the subscriber’s subject identifier an (attested) P-256 ECDSA signing key from Secure Enclave, StrongBox, or Android’s hardware-backed Keystore. This is the possession factor for authentication.

During enrollment, the provider also performs generation of a SCAL3 user identifier and pre-authorization of this identifier for certificate issuance. This part of enrollment applies FROST distributed key generation and requires the subscriber to set their PIN.

During authentication, the certified identifier contains all information needed for the original provider and subscriber to determine their secret signing shares. The process applies FROST two-round threshold signing, combined with ECDSA to prove possession of the enrolled device. Successful authentication leads to recorded evidence that can be publicly verified.

By design, the certificate and the evidence provide no information about the PIN. This means that even attackers with access to the device, the certificate and the log cannot bruteforce the PIN, since they would need to verify each attempt using the rate-limited provider service.

Cryptography overview

This prototype uses the P-256 elliptic curve with order p and common base point G for all keys.

To the provider and subscriber, signing shares are assigned of the form s_i = a₁₀ + a₁₁i + a₂₀ + a₂₁i (mod p) where the provider has participant identifier i = 1 and the subscriber has i = 2. During enrollment, the provider has randomly generated a₁₀ and a₁₁ and the subscriber has randomly generated a₂₀ and a₂₁. The other information is shared using the FROST distributed key generation protocol. The resulting joint verifying key equals V_k = [a₁₀ + a₂₀]G.

The SCAL3 user identifier consists of V_k and:

• s₁ + m₁ (mod p) where m₁ is a key securely derived by the provider from V_k using the HSM, for example using HKDF-Expand(V_k) from RFC 5869 with an HSM key, followed by hash_to_field from RFC 9380;
• s₂ + m₂ (mod p) where m₂ is a key securely derived by the subscriber from the PIN, for example using HKDF-Expand(PIN) followed by hash_to_field.

During authentication, the subscriber generates an ephemeral ECDSA binding key pair (s_b, V_b) and forms a message M that includes V_b, the instruction to authorize, and log metadata. Applying FROST threshold signing, both parties generate secret nonces (d_i, e_i) and together they form a joint signature (c, z) over M. To do so, they compute with domain-separated hash functions #₁ and #₂:

• commitment shares (D_i, E_i) = ([d_i]G, [e_i]G);
• binding factors ρ_i = #₁(i, M, B) where B represents a list of all commitment shares;
• commitment R = D₁ + [ρ₁]E₁ + D₂ + [ρ₂]E₂;
• challenge c = #₂(R, V_k, M);
• signature share z_i = d_i + e_iρ_i + cλ_is_i (mod p) with λ₁ = 2 and λ₂ = −1;
• proof z = z₁ + z₂.

All subscriber’s contributions are part of a single “pass the authentication challenge” message that includes:

• a device signature created using the possession factor over c;
• a binding signature created using s_b over the device signature.

This construction makes sure that without simultaneous control over both authentication factors, evidence cannot be forged.

Examples

All provider functions are pure, enabling a mostly stateless server implementation.

Enrollment

Aborting upon failure, the provider and subscriber execute their assigned functions in this order:

1. provider: derive Randomness, provider::vouch, and send a Voucher;
2. subscriber::redeem and send a Redemption;
3. provider::process, derive a Mask, provider::validate, and send Validation;
4. subscriber: derive a Mask, subscriber::enroll, and send an Identifier;
5. provider::authorize.

Authentication

Aborting upon failure:

1. provider: derive Randomness, provider::challenge, and send a Challenge;
2. subscriber: derive a Mask, subscriber::authenticate, create a device signature, subscriber::pass, and send a Pass;
3. provider::prove, and log Evidence.

Auditing

The subscriber or any other party with access can verify the Evidence.

Modules

provider

Central system provider operating under sole control of subscribers.

subscriber

User with a device under full control, subscribing to provider services.

Structs

Payload

Log metadata and instructions.

Constants

MAXIMUM_PAYLOAD_SIZE

The maximum size of a payload.

Functions

pay^⚠

Constructs a Payload from a pointer and a size in bytes.

release^⚠

Releases a Payload from memory.

verify

Verifies Evidence that the identified subscriber passed the Payload.

Type Aliases

Challenge

Authentication challenge data.

Device

Authenticator device verifying key.

Evidence

Evidence that some subscriber passed some payload.

Identifier

Enrolled authenticator data for the subscriber.

Mask

Secret entropy derived from application-provided data using a hardware-backed key.

Pass

Response to a Challenge.

Randomness

Secret entropy derived from execution context data using a hardware-backed key.

Redemption

Attempt to redeem a Voucher to enroll.

Validation

Validation of a Voucher with Redemption.

Voucher

Entitlement to enroll.