Overview

Privasys Wallet is a 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.

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.

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 currently in beta with early testers. It will be available on the App Store and Google Play in the coming weeks.

The application is open source under the AGPL-3.0 licence.