Audit trail

This section describes the security precautions at each step of user's interaction from creating an identity to sharing it with 3rd-party services.

The audit trail shows that user's personal data wasn't tampered with by the client and comes from a trusted source. As we do store the PII (personal identifiable information) on the users device we need to safeguard that only the data we have provided is used in proofs.

The trail

1. User creates an identity

User creates an identity by communicating to the identity source and TEE backend. During the process, backend attaches a TEE attestation report to the identity object before sending it to the user, then discards the identity data - user's device can verify that the identity wasn't tampered with, and can trust that the backend actually discarded the identity.

The trust is based on the guarantees described in the Architecture deep dive section.

2. User creates a zero-knowledge proof of their identity

  1. User's device generates public and private inputs for ZK proof, then creates a ZK proof
  2. User's device sends the proof back along with the identity data, which was attested by the backend in step 1

3. The backend verifies the received data

The backend does the following steps:

  1. reads private inputs from the identity data
  2. recreates public inputs
  3. verifies that the attestation report from step 1 wasn't tampered with
  4. verifies the proof using public inputs

4. The backend signs and attests the proof, then sends it back

  1. Public inputs are signed with an ephemeral ECDSA key, public part of the key is attached to the proof
  2. TEE attestation report is created over the public key and proof's validitiy timestamp - SHA256(PublicKey|ValidUntilTimestamp), then the report is attached to the proof
  3. The attested proof is sent back to the user's device
  4. Proof and identity are discarded

5. User receives the proof and can share it with 3rd parties

To have a complete audit trail on where the data came from, the 3rd party (consumer of the identity proof):

  1. Needs to verify the report, which discloses a hash of public key and validity timestamp. Use it to verify the ECDSA signature of proof data and proof expiry. That guarantees that the 3rd party can trust the inputs the user used on their device to create a ZK proof.
  2. Needs to verify the ZK proof. See ZK proof verification section for more information.
  3. If you want to go an extra mile, your consumer can also verify the code running on the backend in TEE by comparing UniqueID in the report with UniqueID you can get from reproducible builds.