identity.org.au

Your data and privacy

Trusted processing: the lock and the key

Your evidence is only ever processed inside hardware-sealed vaults that no person can open — and you don't have to take that on faith, because the vault proves what it is before any data enters.

One verification, start to finish

Follow one verification through the system. Your data is locked on your device, travels sealed, is opened only inside a vault whose key is forged in the hardware itself, and is destroyed once the answer exists. Only the answer leaves.

1 · On your device Documents + biometrics Sealed before it moves Your keys never leave this phone Held in secure hardware Cannot be exported IN TRANSIT Unreadable to every network, carrier and server it crosses 2 · The trusted processing unit A hardware-sealed vault — AMD SEV-SNP · Intel SGX · AWS Nitro The attestation gate: the chain verifies the vault's exact measurement before any data enters The key is forged inside Derived from the hardware itself, sealed to this vault — it never exists anywhere outside it Verification runs Document checks, face match, liveness — scored in isolation Source scans stay local The vault keeps nothing: your documents and biometrics are destroyed when scoring ends No window · no console · no operator door Hardware isolation keeps operators outside Result only 3 · The chain Score + tier Pass / fail results Never documents, never biometrics Operators Providers The foundation OUTSIDE THE VAULT NO OPERATOR ACCESS PATH Operators, providers and foundation staff remain outside the processing environment. The hardware boundary has no administrative entry point. Original scans stay on your device · only approved derived data may leave encrypted · results, not document images, are recorded
The journey of one verification: sealed on your device, opaque in transit, admitted through the attestation gate, processed and destroyed inside the vault — only the result reaches the chain.

What a trusted processing unit is

A trusted processing unit is a vault built out of the computer's own hardware. The technical names are trusted execution environments and confidential virtual machines — AMD SEV-SNP, Intel SGX and AWS Nitro are the three the system supports. Inside one, the processor itself encrypts the memory, so even the machine's owner, looking at their own hardware, sees only ciphertext.

Ordinary servers have doors: an administrator account, a debug console, a memory dump. A trusted processing unit is designed with no doors at all — no operator login, no console, no way to read the memory from outside. That is not a policy that someone promises to follow; it is how the silicon works.

Two circular steel vault doors in a strongroom, one standing open.
The processing unit borrows the idea from the processor itself: a boundary with no door for the operator.

The gate: attestation, checked on-chain

Before your encrypted evidence is released to a vault, the vault must prove what it is. It produces an attestation — a signed statement from the hardware manufacturer's own certificate chain that says, in effect: "I am genuine sealed hardware, and I am running exactly this code, with this fingerprint."

The VirtEngine chain verifies that attestation on-chain, in its x/enclave module, checking the signature and comparing the code's measurement — a cryptographic fingerprint of every byte the vault will run — against the approved record. If a single byte of the code were different, the fingerprint would not match and no data would be released to it. Because the check is on-chain, it is public: anyone can confirm which enclave measurements the network accepts.

What attestation does and does not prove

Attestation proves the vault is genuine hardware running exactly the approved code — nothing more. The rest of the protection comes from what that approved code does: verify, report a result, destroy the evidence. Both halves are open source, so both halves can be checked.

The key: forged inside the vault

The key that decrypts your evidence never exists outside the vault. It is derived inside the hardware, from the hardware — the processor's own secrets — and sealed so it can only ever be used by that exact vault running that exact code (hardware key derivation with vTPM sealing, in the technical terms).

This is why "no one can open it" is a design fact rather than a promise: there is no key to hand over. Not to an operator with root access, not to the provider hosting the machine, not to the foundation that stewards the project, not in response to a demand. A key that never leaves the silicon cannot be copied, stolen, or surrendered.

What happens to your data, stage by stage

Original document images stay on the user's device. The local client derives approved verification data; only a minimum encrypted payload may enter VEID processing.

  1. Stage 1 Captured On your phone: document scan, selfie, liveness.
  2. Stage 2 Original stays local The document image never leaves your device. OCR and checks run locally.
  3. Stage 3 Derived data, if approved Only minimum user-approved fields may leave, encrypted for VEID processing.
  4. Stage 4 Transient data cleared Temporary processing data is cleared under the scope lifecycle; source images remain local.
  5. Stage 5 Selective result The network records the verification result and required encrypted references, never source images.
For each stage of the data lifecycle: where it happens, who can access the data, and what remains afterwards
Stage Where it happens Who can access your data What remains afterwards
1 · Capture Your phone Only you Nothing has left your device yet
2 · Encryption Your phone Only you and your local wallet client Original document image stays local; no scan is transmitted
3 · Attested processing VEID processing, only for approved derived data As stated in the relevant scope and trusted-processing design Only the approved derived fields/features are submitted; never the source scan
4 · Destruction Transient VEID processing data According to the approved scope lifecycle Transient processing data is cleared under that lifecycle; source document images never entered the network
5 · Result The VirtEngine chain Services you consent to, per request Verification result and required encrypted references — never source document images

How and when data is discarded

Destruction is a commitment in the published Biometric Data Addendum, with actual figures rather than adjectives:

  • On your device: original document images remain local and are never uploaded. Local OCR and document checks produce only the derived data you review.
  • Approved derived data: if you submit a scope, its notice states what encrypted derived data is sent, who processes it, and the applicable lifecycle. It never includes the original document image.
  • On deletion request: requests apply to data the network actually received. Original document images remain on your device and are controlled there.
  • Encrypted network data: deletion and key-destruction limits are explained in the relevant scope notice, including any immutable on-chain records.
  • Withdraw at any time by emailing dpo@virtengine.com.

Who can see what

For each category of identity data, whether you, services, providers, the foundation or operators can see it
Data You Service you use Providers Foundation Operators
Raw documents Yes — on your device Never Never Never Never
Biometric data Yes — on your device Never Never Never Never
Encryption keys Held in your phone's hardware Never Never Never Never — the vault's key never leaves the silicon
Score and tier Yes — in full Only with your consent, per request Tier only, as an approved client Public results only Public results only

"Never" for raw documents is architectural: the source image remains on your device and is not transmitted. The scope notice describes any derived data that is separately approved.

Verification you can check

Every claim on this page maps to something inspectable. The enclave runtime and the attestation verifier are in the open-source repository (pkg/enclave_runtime); the on-chain verification lives in the x/enclave module; the destruction and retention commitments are in the versioned Biometric Data Addendum. The protocol documentation covers the attestation formats in engineering detail.

The honest limits

No security design is beyond all conceivable failure, and we do not claim this one is. What we claim — checkably — is the design: attestation verified before data moves, keys sealed in hardware, no operator access path, and destruction commitments with dates attached. Designed so that no one — not operators, not providers, not the foundation — can open the processing environment.

Keep reading

Policy Privacy Everything that exists, where it lives, who can read it, and the full retention table. Guide How it works The whole pipeline in plain language — on-device capture, network verification, consent. The service Wallet security The wallet's security model: on-device processing, key handling, real deletion. Help How your biometrics are protected The four promises that never change, and the retention schedule in numbers.