diff --git a/README.md b/README.md index 653fe78..2a632cf 100644 --- a/README.md +++ b/README.md @@ -47,67 +47,10 @@ If anyone suspects compromise or corruption, they can easily investigate and mak This empowers users with cryptographic proof. -## Two ways to achieve SCAL3 +## Three ways to achieve SCAL3 -1. Using the [SECDSA](https://eprint.iacr.org/2021/910) [technology](https://www.cs.ru.nl/E.Verheul/presentations/SECDSA%20Assissted%20Wallet%200.31.pdf). This technology is based on algorithms that were invented in 2021 and patented by Eric Verheul. Users verify evidence by applying homomorphic encryption. -2. The method presented below. With this SCAL3 solution, users verify evidence using open standard ECDSA and ECSDSA signature verification. +1. Using the [SCAL3 with UAF](docs/schemes/uaf.md) scheme. This involves using a dedicated multi-factor cryptographic device, such as a FIDO security key supporting UAF. +2. Using the [SECDSA](https://eprint.iacr.org/2021/910) [technology](https://www.cs.ru.nl/E.Verheul/presentations/SECDSA%20Assissted%20Wallet%200.31.pdf). This technology is based on algorithms that were invented in 2021 and patented by Eric Verheul. Users verify evidence by applying homomorphic encryption. +3. Using the [SCAL3 with Thresholds](docs/schemes/thresholds.md) scheme. With this patent pending solution, users verify evidence using open standard ECDSA and ECSDSA signature verification. -In 2023, [Cleverbase](https://cleverbase.com/en/) experimented with both solutions. In 2024, the [Vidua](https://vidua.nl/english/) identity wallet is rolling out solution 2 to its users. By enabling verification using open standards, this method makes it easy for users to verify the tamper-evident logs. - -## How it works - -> [!NOTE] -> Patent NL2037022 pending. For inquiries, [contact Cleverbase](mailto:sander.dijkhuis@cleverbase.com). - -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](https://dl.acm.org/doi/10.1145/359168.359176) 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](https://www.sogis.eu/uk/supporting_doc_en.html). - -## 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](https://eprint.iacr.org/2020/852) two-round threshold signing. - -``` - || || || || -``` - -- `message`: ` || || ` -- `user_sig`: `ecsdsa()` represented as `c || z` -- `checksum`: `sha256()` -- `device_sig`: `ecdsa( || )` created with `device_sk` -- `binding_sig`: `ecdsa()` 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`. -7. Subscriber creates the device signature `device_sig`. -8. Subscriber creates the binding signature `binding_sig`. -9. Subscriber destroys `binding_sk`. -10. Subscriber responds to Provider with the results. -11. Provider validates the input and verifies the signatures. -12. Provider signs in FROST, completing the second FROST round. -13. Provider aggregates the `user_sig` in FROST. -14. Provider writes the record to the tamper-evident log. +In 2023, [Cleverbase](https://cleverbase.com/en/) experimented with all three solutions. In 2024, the [Vidua](https://vidua.nl/english/) identity wallet is rolling out solution 3 to its users. By enabling verification using open standards, this method makes it easy for users to verify the tamper-evident logs. diff --git a/docs/schemes/thresholds.md b/docs/schemes/thresholds.md new file mode 100644 index 0000000..869bffb --- /dev/null +++ b/docs/schemes/thresholds.md @@ -0,0 +1,66 @@ +# SCAL3 with Thresholds + +**Author:** [Sander Dijkhuis](mailto:sander.dijkhuis@cleverbase.com) ([Cleverbase](https://cleverbase.com/en/)) \ +**License:** [Creative Commons Attribution-NonCommercial 4.0 International](https://creativecommons.org/licenses/by-nc/4.0/) + +This document introduces the SCAL3 with Thresholds scheme, a scheme to meet the [SCAL3 requirements](../../README.md) 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](mailto:sander.dijkhuis@cleverbase.com). + +For a prototype with more in-depth documentation, see the [scal3 crate docs](https://docs.rs/scal3/latest/scal3/). + +## 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](https://dl.acm.org/doi/10.1145/359168.359176) 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](https://www.sogis.eu/uk/supporting_doc_en.html). + +## 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](https://eprint.iacr.org/2020/852) two-round threshold signing. + +``` + || || || || +``` + +- `message`: ` || || ` +- `user_sig`: `ecsdsa()` represented as `c || z` +- `checksum`: `sha256()` +- `device_sig`: `ecdsa( || )` created with `device_sk` +- `binding_sig`: `ecdsa()` 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`. +7. Subscriber creates the device signature `device_sig`. +8. Subscriber creates the binding signature `binding_sig`. +9. Subscriber destroys `binding_sk`. +10. Subscriber responds to Provider with the results. +11. Provider validates the input and verifies the signatures. +12. Provider signs in FROST, completing the second FROST round. +13. Provider aggregates the `user_sig` in FROST. +14. Provider writes the record to the tamper-evident log. diff --git a/docs/schemes/uaf.md b/docs/schemes/uaf.md new file mode 100644 index 0000000..554f3ad --- /dev/null +++ b/docs/schemes/uaf.md @@ -0,0 +1,56 @@ +# SCAL3 with UAF + +**Author:** [Sander Dijkhuis](mailto:sander.dijkhuis@cleverbase.com) ([Cleverbase](https://cleverbase.com/en/)) \ +**License:** [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/) + +This document introduces the SCAL3 with UAF scheme, a scheme to meet the [SCAL3 requirements](../../README.md) based on the [FIDO Universal Authentication Framework](https://fidoalliance.org/specifications-overview/). With this solution, subscribers can deploy a FIDO UAF authenticator, such as a [YubiKey](https://en.wikipedia.org/wiki/YubiKey), as a [Multi-Factor Cryptographic Device](https://pages.nist.gov/800-63-3/sp800-63b.html#mfcd). + +To map terminology from the [SCAL3 introduction](../../README.md): + +- **device**: a UAF 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`: 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( || sha256())` as per CTAP2 + - `client_data`: ` || || || ` +- `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](https://edi.pleio.nl/files/view/dc585f22-ca66-4892-87c5-c7bdb2dd69b4/nlw-solution-architecture-sad-v1.pdf) by [MinBZK](https://github.com/MinBZK).