Privasys Wallet

Privasys Wallet is the mobile application for iOS and Android that combines FIDO2 authentication with remote attestation verification. It turns your phone into a hardware-backed authenticator that verifies the server's identity before signing any challenge, and it is the verification anchor behind every Privasys ID flow — sign-in, manager approvals on Enclave Vaults, and the sealed-session bindings that bring attested transport to browsers.

The problem

Standard authentication is one-directional. You prove who you are to the server, but the server does not prove anything to you. You trust that the service behind the URL is what it claims to be, that the TLS certificate was issued to the right entity, and that the code running on the other end has not been tampered with.

For ordinary websites, this is usually acceptable. For services that process sensitive data inside hardware enclaves, it is not. The entire value proposition of Confidential Computing is that the infrastructure cannot access your data. If you cannot verify that the service is genuinely running inside secure hardware before you authenticate, the guarantee is meaningless.

The approach

Privasys Wallet establishes two-way trust between your device and the enclave:

1. Server verification (RA-TLS). Before any authentication takes place, the wallet inspects the server's TLS certificate for embedded attestation evidence. It verifies the hardware quote, confirms the code measurement (MRENCLAVE or RTMR), and checks the configuration Merkle root. If verification fails, the wallet refuses to proceed.

2. User authentication (FIDO2). Once the server is verified, the wallet performs a standard FIDO2/WebAuthn ceremony. The private key is generated and stored in the device's secure hardware (Secure Enclave on iOS, StrongBox or TEE on Android). The key never leaves the hardware — only signatures are returned.

The result is a connection where both sides have cryptographic proof of the other's identity. The enclave proves it is genuine hardware running the expected code. The user proves they control the registered credential. No passwords, no shared secrets, no blind trust.

Key capabilities

Hardware-bound credentials

All FIDO2 private keys are stored in the device's secure hardware:

• iOS: Apple Secure Enclave via SecKeyCreateRandomKey with kSecAttrTokenIDSecureEnclave. Keys are P-256 ECDSA, hardware-bound, and require biometric authentication for signing.
• Android: StrongBox Keymaster (or TEE fallback) via KeyPairGenerator with setIsStrongBoxBacked(true). Same guarantees: keys never leave the hardware.

The key material is non-exportable. It cannot be read by the operating system, the application, or any other process. Only the secure hardware can produce signatures, and only after biometric verification.

RA-TLS attestation verification

The wallet includes a native RA-TLS verification library that:

• Extracts attestation quotes from X.509 certificate extensions using the Privasys OID arc (1.3.6.1.4.1.65230).
• Verifies Intel SGX and Intel TDX quotes against the respective vendor attestation infrastructure.
• Validates the configuration Merkle root to confirm the enclave's full configuration (CA, loaded modules, trust anchors).
• Re-derives the ReportData from the certificate's public key to confirm the cryptographic binding between the attestation and the TLS session.

Verification happens automatically when the user scans a connection QR code or taps a deep link. The attestation summary is displayed before the user is prompted to authenticate.

Trusted app registry

The wallet maintains a local, encrypted registry of previously verified enclave applications. Each entry records:

• The relying party ID and origin.
• The TEE type (SGX or TDX).
• The code measurement and configuration root from the last successful verification.
• The registered FIDO2 credential ID.

On subsequent connections, the wallet compares the current attestation against the stored measurements. If anything has changed — a code update, a configuration change, a different hardware instance — the wallet flags it and shows what changed before the user decides whether to proceed.

End-to-end encrypted notifications

Push notifications from cloud enclaves are encrypted with AES-256-GCM before they leave the enclave. Decryption happens on the device inside a Notification Service Extension that has access to the shared encryption key but runs in a separate process from the main app.

The notification payload (title, body, metadata) is never visible to Apple Push Notification service, Google Firebase Cloud Messaging, or any intermediary.

One wallet on several phones

The same wallet can run on up to five phones. Each phone holds its own keys in its own secure hardware, and all of them sign in as the user, receive their notifications and open their data; a change to the user's details on one reaches the others through a relay that keeps nothing, sealed under a key only those phones hold.

A phone is added from one the user already has: the new phone shows a QR code, the existing phone scans it and, after a biometric check, sends the wallet sealed to the new phone's key, and both phones show the same six digits so the user can see nothing came between them. No recovery phrase is involved. Settings shows a Devices section once there is more than one phone, from which any phone can remove another at any time; a removed phone loses its passkeys, its notifications and the keys that prove the user's identities.

The wallet's secrets stay on the phone they were made on (WHEN_UNLOCKED_THIS_DEVICE_ONLY on iOS, excluded from Android backups): a platform transfer or a backup restore does not carry them, because it could not carry the passkeys held in the old phone's secure hardware either.

Recovery and backup

The user keeps the way back, because the platform cannot read their data and so cannot return it. Any one of these is enough:

• The recovery phrase. 24 words made on the phone. It unseals the wallet's data root and identity seed, kept at the IdP as ciphertext only the phrase opens. On a new phone, every identity comes back at once and every other phone is removed from all of them; the new phone then makes the next phrase.
• Another phone with the wallet: remove the lost one from Devices.
• Guardians: people the user trusts, added by QR code or an invitation link, who approve a recovery from their own wallet.

Each identity the wallet presents to a service is derived from the seed, so it comes back after a recovery, and proves itself with its own recovery key, so no request names more than one identity. The user's details travel separately, in an encrypted backup file carried by the phone's own backup (iCloud Backup, Android app backup), which the user can also save anywhere, keep in their Privasys Drive, restore from a file, or export readable after a biometric check. The design is in Identity Provider.

Authentication flow

A typical FIDO2 registration and authentication flow works as follows:

Registration (first connection)

1. The user scans a QR code or taps a deep link from an enclave-backed service.
2. The wallet connects to the enclave over HTTPS and inspects the RA-TLS certificate.
3. The wallet verifies the hardware attestation quote and displays a summary of the enclave's identity.
4. The user reviews the attestation and approves the connection.
5. The wallet generates a new P-256 key pair in the device's secure hardware.
6. A FIDO2 registration ceremony exchanges the public key with the enclave.
7. The credential is stored locally alongside the enclave's attestation measurements.

Authentication (subsequent connections)

1. The enclave sends an authentication request (via deep link or push notification).
2. The wallet connects and re-verifies the RA-TLS certificate.
3. If the attestation matches the stored measurements, the wallet prompts for biometric confirmation.
4. The device's secure hardware signs the FIDO2 challenge.
5. The signed assertion is sent to the enclave, completing the authentication.

If the attestation has changed since registration, the wallet shows the differences and asks the user to re-verify before authenticating.

Availability

Privasys Wallet is available on the Apple Store (iOS) and Google Play (Android).

The application is open source under the AGPL-3.0 licence as part of the Privasys identity-platform repository.

Granting apps a resource

The wallet is also where a user approves a confidential app's request for something they own, such as a folder in their Drive. The app names what it asks for; the wallet fetches the request from the attested app itself, so the key being authorised is learned inside an attested channel and never from a notification; the user approves on the device; and the wallet carries the approval to the resource service, which mints a grant bound to the app's key. A refusal is delivered too, so an app stops asking. The flow, what a grant is bound to, and what the user sees afterwards are described in Apps and the wallet.