#elliptic-curve #subscriber #key #security #prototype #control #provider

scal3

Verify that systems operate under your sole control (prototype, patent pending)

1 unstable release

0.1.0 Feb 27, 2024

#7 in #prototype

CC-BY-NC-4.0

75KB
1K SLoC

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.

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 si = a10 + a11i + a20 + a21i (mod p) where the provider has participant identifier i = 1 and the subscriber has i = 2. During enrollment, the provider has randomly generated a10 and a11 and the subscriber has randomly generated a20 and a21. The other information is shared using the FROST distributed key generation protocol. The resulting joint verifying key equals Vk = [a10 + a20]G.

The SCAL3 user identifier consists of Vk and:

  • s1 + m1 (mod p) where m1 is a key securely derived by the provider from Vk using the HSM, for example using HKDF-Expand(Vk) from RFC 5869 with an HSM key, followed by hash_to_field from RFC 9380;
  • s2 + m2 (mod p) where m2 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 (sb, Vb) and forms a message M that includes Vb, the instruction to authorize, and log metadata. Applying FROST threshold signing, both parties generate secret nonces (di, ei) and together they form a joint signature (c, z) over M. To do so, they compute with domain-separated hash functions #1 and #2:

  • commitment shares (Di, Ei) = (diG, eiG);
  • binding factors ρi = #1(i, M, B) where B represents a list of all commitment shares;
  • commitment R = D1 + [ρ1]E1 + D2 + [ρ2]E2;
  • challenge c = #2(R, Vk, M);
  • signature share zi = di + eiρi + cλisi (mod p) with λ1 = 2 and λ2 = −1;
  • proof z = z1 + z2.

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 sb over the device signature.

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

Dependencies

~5MB
~101K SLoC