docs: tlog tech note

docs/tlog.md

@@ -0,0 +1,105 @@
+# Transparency Logs for SCAL3
+
+**Author:** [Sander Dijkhuis](mailto:[email protected]) ([Cleverbase](https://cleverbase.com/en/)) \
+**License:** [Creative Commons Attribution 4.0 International](https://creativecommons.org/licenses/by/4.0/)
+
+This technical note about Sole Control Assurance Level 3 (SCAL3) explores the relation to the existing Transparency Log (tlog) ecosystem. Ideally this leads to acknowledgement of SCAL3 as a valid tlog use case, and to reuse across tlog specs, code and implementations.
+
+> [!NOTE]
+> While the general introduction [Verify that systems operate under your sole control](README.md) and the [Rust prototype package](src/README.md) include technology under known (pending) patent claims, the current document can be read independently. Instead of the claimed mobile app-friendly mechanisms, such as the mechanism for the [Vidua](https://vidua.nl/english/) wallet, this document provides examples based on [FIDO standards](https://fidoalliance.org/specifications/).
+
+## Verify sole control of HSM-backed keys
+
+Cloud services for digital identity or currency wallets and for end-to-end encryption are often backed by HSMs. Such HSMs can provide non-exportable keys that resist high-potential attacks, while enabling users to recover access even after losing their local hardware.
+
+For remote multi-user control of central HSM services, we can define security requirements along several [sole control assurance levels](https://www.enisa.europa.eu/publications/assessment-of-standards-related-to-eidas):
+
+- SCAL1 systems authenticate users before operating on their HSM-backed keys.
+- SCAL2 systems meet SCAL1 and additionally require specific user instructions that are cryptographically linked to evidence of multi-factor authentication.
+- SCAL3 systems meet SCAL2 and additionally enable public verification of tlogs containing this cryptographic evidence.
+
+The application of tlogs enables continuous monitoring and dispute handling between a HSM-backed service provider and its user community. An independent auditor or judge can rely on SCAL3 tlog data to verify if a particular HSM operation was indeed based on an instruction created by the user in a multi-factor authenticated session.
+
+While SCAL2 could still be implemented using symmetric cryptography, for example comparing a hashed PIN and TOTP within the HSM, SCAL3 requires non-repudiability which implies asymmetric cryptography. This poses several security design challenges:
+
+- After compromise of the user’s authentication device and with access to the tlog data, an attacker must not be able to verify brute-force PIN attempts offline. So the tlog must not provide any information about the PIN.
+- User-specific instruction content or quantitive data must be kept confidential. So public tlog contents must not contain any personal data.
+
+## Prove sole control with SCAL3
+
+One solution is to use a FIDO authenticator with UAF, for example a [YubiKey](https://www.yubico.com/products/yubikey-5-overview/), acting as a [Multi-Factor Cryptographic Device](https://pages.nist.gov/800-63-3/sp800-63b.html#mfcd). To prove sole control:
+
+1. A subscribed user is enrolled using the authenticator.
+2. The user authorizes an instruction, for example by entering a PIN code.
+3. The provided HSM-backed service only executes instructions generated using multi-factor authentication.
+4. The provider keeps a protected tlog with evidence of instructions.
+5. Upon request, the provider proves that a particular operation was authorized.
+
+```mermaid
+flowchart LR
+subgraph Provider
+  direction TB
+  system(HSM-backed<br>service)
+  log[(Protected<br>transparency log)]
+  system -- 3. execution --> system
+  system -- 4. evidence --> log
+end
+subgraph Subscriber
+  direction TB
+  user((User))
+  authenticator[<br>Authenticator<br><br>]
+  user -- 1. control --> authenticator
+end
+Subscriber -- 2. instruction --> Provider
+Provider -- 5. proof --> 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](https://edi.pleio.nl/files/view/dc585f22-ca66-4892-87c5-c7bdb2dd69b4/nlw-solution-architecture-sad-v1.pdf) by [MinBZK](https://github.com/MinBZK).
+
+## Open design issues
+
+- [ ] Next to the protected tlog, should a SCAL3 provider record into a public tlog?
+  - For example to record provider signatures: `ecdsa(sha256(<protected tlog entry>) || sha256(<instruction result>))`.
+- [ ] The current tlog record design is awkward, are there best practices?
+- [ ] Can we improve the terminology to align with existing tlog ecosystems?