You need identity wallets and trust services to participate securely in online society. Whether you are booking a holiday, signing a contract, or providing financial services. Underlying central systems mitigate risks of identity theft, fraud, and data loss. But you need assurance that these systems process user data only under their sole control. With SCAL3, Vidua empowers its users with this assurance made available on scale.

Depending on the risks, wallet and trust service providers leverage central systems with a sole control assurance level (SCAL):

• SCAL1 systems authenticate users before operating on their data.
• SCAL2 systems also operate only on instructions linked to multiple authentication factors.
• SCAL3 systems also enable users to verify tamper-evident logs proving sole control.

Adoption of mobile wallets is accelerating with the “eIDAS 2.0” European Digital Identity framework. But the phones in use today are not equipped for security at scale. Users will therefore rely on central systems for cryptography, for example hardware security modules (HSMs). With the increasing reach and impact of such technology, only the transparency of SCAL3 puts users truly in control.

1. A subscribed user is enrolled using a device they control.
2. The user authorizes an instruction, for example by entering a PIN code.
3. The provided system only executes instructions generated using multi-factor authentication.
4. The provider keeps a tamper-evident log with evidence of instructions.
5. Upon request, the provider proves that a particular operation was authorized.

flowchart LR
subgraph Provider
	direction TB
	system(Central system)
	log[(Tamper-evident log)]
	system -- 3. execution --> system
	system -- 4. evidence --> log
end
subgraph Subscriber
	direction TB
	user((User))
	device[<br>Device<br><br>]
	user -- 1. control --> device
end
Subscriber -- 2. instruction --> Provider
Provider -- 5. proof --> Subscriber

Publishing open source code is not enough. To verify if the system does what its provider claims, you need to check its actual behaviour.

Providers with SCAL3 enable users to verify that their systems only operated upon sole control. Under normal circumstances, the provider can prove that each operation has an instruction that was generated by an authentic subscriber.

If anyone suspects compromise or corruption, they can easily investigate and make their case. All evidence of instructions is available in a tamper-evident log.

This empowers users with cryptographic proof.

1. Using the SECDSA technology. 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.

In 2023, Cleverbase experimented with both solutions. In 2024, the Vidua 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.

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.

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

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.