Skip to content

Latest commit

 

History

History
66 lines (47 loc) · 3.44 KB

thresholds.md

File metadata and controls

66 lines (47 loc) · 3.44 KB
Raw

SCAL3 with Thresholds

Author: Sander Dijkhuis (Cleverbase)
License: Creative Commons Attribution-NonCommercial 4.0 International

This document introduces the SCAL3 with Thresholds scheme, a scheme to meet the SCAL3 requirements based on threshold signing between the subscriber and the provider. With this solution, users verify evidence using open standard ECDSA and ECSDSA signature verification.

Note

Patent NL2037022 pending. For inquiries, contact Cleverbase.

For a prototype with more in-depth documentation, see the scal3 crate docs.

How it works

Upon enrolment, the central system provider issues a certificate with two authentication factors:

  • 🔑 Something you have: an ECDSA key bound to a device.
  • 💭 Something you know or are: a PIN code or biometry-protected data.

The second factor is protected using Shamir’s secret sharing technique. The certificate enables verification by protecting:

  • 🫱 A secret share encrypted using the second authentication factor.
  • 🫲 A secret share encrypted with a user-specific key only known to the provider.
  • 🤝 A verification key enabling ECSDSA signature verification using both secret shares.

Subscribers generate instructions and providers prove them using an innovative method combining:

  • Multi-party computation of signatures proving the second factor
  • Digital signatures proving possession of the enrolled device
  • Digital signatures binding the two authentication factors

Using the certificate, anyone can verify a proof of multi-factor authentication using open standards from the SOG-IS Agreed Cryptographic Mechanisms v1.3.

Technical details

Tamper-evident log record format

Each tamper-evident log record is based on an ephemeral ECDSA key pair (binding_sk, binding_vk) generated on the user’s device. It contains an ECSDSA signature proving the second authentication factor using FROST two-round threshold signing.

<message> || <user_sig> || <checksum> || <device_sig> || <binding_sig>
  • message: <binding_vk> || <log metadata> || <instruction>
  • user_sig: ecsdsa(<message>) represented as c || z
  • checksum: sha256(<user signature share>)
  • device_sig: ecdsa(<c> || <checksum>) created with device_sk
  • binding_sig: ecdsa(<device_sig>) created with binding_sk

Authentication protocol

  1. Provider commits in FROST.
  2. Provider shares its commitments with Subscriber in a challenge.
  3. Subscriber commits in FROST, completing the first FROST round.
  4. Subscriber generates (binding_sk, binding_vk).
  5. Subscriber forms the message to sign.
  6. Subscriber signs in FROST to create c and user signature share.
  7. Subscriber computes the hash digest checksum.
  8. Subscriber creates the device signature device_sig.
  9. Subscriber creates the binding signature binding_sig.
  10. Subscriber destroys binding_sk.
  11. Subscriber responds to Provider with the results.
  12. Provider validates the input and verifies the signatures.
  13. Provider signs in FROST, completing the second FROST round.
  14. Provider aggregates the user_sig in FROST.
  15. Provider writes the record to the tamper-evident log.