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. It implements the protocol from the technical report “Authentication and sole control at a high level of assurance on widespread smartphones with threshold signatures” in Cryptology ePrint Archive, Paper 2025/267.

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 Keymaster, 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 subscriber has randomly generated joint secret key s = s₁s₂ and computed a_ij as a trusted dealer. The resulting joint verifying key equals V_k = [a₁₀ + a₂₀]G.

The SCAL3 user identifier consists of V_k and:

• s₁ encrypted for the provider;
• s₂ + m₂ (mod p) where m₂ is a key securely derived by the subscriber from the PIN, for example using PRF(k, PIN) with a local hardware-backed key k, followed by hash_to_field from RFC 9380.

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_iG, e_iG);
• 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.