Attested Secure Keys

The brief

EU Digital Identity (EUDI) wallets — and most serious fintech and identity apps — have a hard requirement: the private key that binds a credential to its holder must live inside the device’s secure hardware, must be non-exportable, and the backend must be able to prove the key was actually born in hardware before it trusts anything signed with it.

This library began as the key layer for an EUDI-wallet proof-of-concept, then generalised so any app needing hardware-backed keys can reuse it. Its protocol companion — issuance, holding and selective presentation of credentials — lives in SD-JWT VC + OpenID4VC.

The gap it fills

As of mid-2026 no package on pub.dev exposed key attestation. The obvious candidate, flutter_secure_storage, solves a different problem: it encrypts data. A private key parked there is still a software key — it round-trips through your app’s memory every time you use it, so it can be lifted from a compromised process, and there is no way to prove to a server where it came from.

The fix is to never let the key exist in app memory at all. The OS-certified secure element generates it, holds it, and uses it — and the device manufacturer signs a certificate vouching that it did. This plugin wraps both platforms’ native APIs behind one small, honest Dart surface.

How it talks to the secure hardware

It’s a federated Flutter plugin. Your app depends only on the Dart facade; calls travel through a typed Pigeon channel (no stringly-typed maps) into first-party native code, which speaks directly to the hardware-backed keystore. Crucially, the boundary is one-way: the private key is created below the line and never crosses back up.

Proving the key was born in hardware

This is the whole point of the library. A key’s hardware origin is vouched for by the device manufacturer — Google’s Hardware Attestation Root on Android, Apple’s App Attest Root on iOS — not by the app and not by the library. The plugin generates the key in certified hardware and surfaces the manufacturer’s signed proof; your backend makes the trust decision.

End to end

Put together, a single server nonce ties the whole flow together: it’s bound into the key at generation, echoed back in the attestation (so a replay can’t be reused), and the same key later signs proofs-of-possession the server validates against the public key it bound at enrolment.

What it does

A facade modeled on the ergonomics of flutter_secure_storage, with eight methods:

final keys = AttestedSecureKeys();

// 1 · Mint a non-exportable P-256 key in the strongest hardware
//     available, binding the server's nonce into the attestation.
final key = await keys.generateKey(
  alias: 'wallet.holderKey',
  minSecurityLevel: KeySecurityLevel.trustedEnvironment,
  userAuth: const UserAuthPolicy.perUseBiometric(),
  attestationChallenge: nonceFromServer,
);

// 2 · Hand the public key + manufacturer-signed proof to your backend.
final attestation =
    await keys.attest(alias: key.alias, serverNonce: nonceFromServer);
await api.registerWalletKey(jwk: key.publicJwk, attestation: attestation);

// 3 · Later: sign a proof-of-possession. The biometric prompt fires
//     automatically for an auth-gated key.
final sig = await keys.sign(alias: key.alias, payload: utf8.encode(jwt));
final jws = '$jwt.${sig.jose}';

Design decisions & honest trade-offs

Status

Published to pub.dev as 0.1.0-dev.1 while the API soaks toward a stable 0.1.0. Both platforms are device-verified — Android (StrongBox / TEE attestation) on real hardware via Firebase Test Lab, and iOS (Secure Enclave + App Attest) on a physical iPhone, with the exported Android attestation decoded end-to-end to a genuine Google root. It’s the key layer of a working EUDI wallet. Open source under Apache-2.0.