Skip to content

Latest commit

 

History

History
56 lines (38 loc) · 3.32 KB

ctap2.md

File metadata and controls

56 lines (38 loc) · 3.32 KB
Raw

SCAL3 with CTAP2

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

This document introduces the SCAL3 with CTAP2 scheme, a scheme to meet the SCAL3 requirements based on the FIDO Client to Authenticator Protocol version 2 (CTAP2). With this solution, subscribers can deploy a FIDO CTAP2 authenticator with PIN protection, such as a YubiKey, as a Multi-Factor Cryptographic Device.

To map terminology from the SCAL3 introduction:

  • device: a CTAP2 authenticator
  • subscriber: user interacting with the device using a CTAP2 client, enrolling with a local authentication mechanism such as PIN verification
  • tamper-evident log: a transparency log or tlog
  • central system: typically is a HSM-backed service for managing encryption and/or signing keys for the subscriber

Technical details

Log record format

Each tlog record is based on an authenticator assertion based on client data. This specification assumes that the authenticator signs using an ECDSA key pair that was attested to the provider during enrollment.

<number> || <timestamp> || <nonce> || <authenticator> || <signature> || <instruction>
  • number: log sequence number, maintained between subscriber and provider (4 bytes, see below)
  • timestamp: timestamp generated by the provider (8 bytes)
  • nonce: random challenge number to be used once, generated by the provider (8 bytes)
  • authenticator: authenticator data as per CTAP2
  • signature: authenticator assertion ecdsa(<authenticator> || sha256(<client_data>)) as per CTAP2
    • client_data: <key> || <timestamp> || <nonce> || <instruction>
  • instruction: HSM-backed key management instruction, generated by the subscriber

Log sequence number

The 4-byte log sequence number is a big-endian encoded strictly increasing number starting at 0 upon enrollment of a subscriber.

Using these numbers, the subscriber and provider can verify integrity of the protected tlog.

Optionally, the numbers may be encrypted in such a way that the subscriber can share records without disclosing the amount of previously recorded instructions.

Authentication protocol

  1. Provider determines key and timestamp.
  2. Provider generates nonce.
  3. Provider shares key, timestamp and nonce with Subscriber in a challenge.
  4. Subscriber determines instruction and client_data.
  5. Subscriber creates authenticator and signature using their authenticator.
  6. Subscriber responds to Provider with the results.
  7. Provider validates the input and verifies the signatures.
  8. Provider writes the record to the protected tlog.

After successful authentication and subsequent authorization, Provider executes instruction and returns the result.

Acknowledgements

The usage of a log sequence number shared between the subscriber and provider is inspired by the NL Wallet Solution Architecture v1.0.3 draft by MinBZK.