Skip to main content

Encryption and key management

The Truvity EUDIW Connector manages the cryptographic operations required by the EUDI Wallet ecosystem, handling key lifecycles aligned with the Architecture Reference Framework (ARF) and the High Assurance Interoperability Profile (HAIP).

This page explains how the connector manages signing and encryption keys to ensure security, authenticity, and privacy.

Key types​

The connector uses two distinct key types: one for proving identity (signing) and one for ensuring confidentiality (encryption).

Signing identity key​

The signing identity key (the private key associated with your X.509 access certificate) is a long-lived key that signs authorization requests sent to EUDI Wallets. It identifies your organization as a registered Relying Party.

You are responsible for obtaining your access certificate from a Certificate Authority (CA) or member state registrar and configuring the signing identity key in the connector. For details on certificate types and their roles, see Certificates in EUDI.

Ephemeral encryption key​

The ephemeral encryption key is a single-use key pair generated for each presentation request. The public key is included in the authorization request sent to the wallet, and the wallet uses it to encrypt the presentation response. The connector decrypts the response using the corresponding private key, then permanently deletes both keys.

This per-request approach limits the window of exposure: because each key pair exists only for a single session and is permanently deleted afterward, a compromise of long-term signing keys does not expose past credential presentations. The ephemeral keys used for those sessions no longer exist.

The ARF requires that presentation responses are returned in encrypted format. The connector's ephemeral encryption key mechanism implements this requirement, ensuring that credential data is encrypted end-to-end between the wallet and the connector in addition to transport-layer security.

Encryption flow​

The connector combines transport-layer security with app-level encryption:

  1. Key generation: When you create a presentation request, the connector generates a unique ephemeral encryption key pair.
  2. Key exchange: The ephemeral public key is included in the authorization request sent to the wallet.
  3. Encryption: The EUDI Wallet uses the public key to encrypt the presentation response before sending it back.
  4. Decryption: The connector decrypts the response using the ephemeral private key.
  5. Deletion: After verification completes and the callback is delivered, the ephemeral keys are permanently deleted.

Key lifecycle​

Signing identity key lifecycle​

The signing identity key is long-lived and tied to your organization's X.509 access certificate. You configure it at deployment time and rotate it according to your certificate renewal schedule.

Ephemeral encryption key lifecycle​

Ephemeral encryption keys are strictly internal to the connector. They are not exposed through the management API. The connector generates them when you create a presentation request and deletes them when the session completes or expires. This aligns with the ephemeral data model design principle.

Wallet hardware attestations​

Wallet Units use Wallet Unit Attestations (WUAs) to certify their secure hardware properties to the EUDI Wallet ecosystem. However, Wallet Units do not share WUAs with Relying Parties. As a result, the connector does not receive information about the wallet's secure hardware properties during a presentation exchange.

External keys​

During verification, the connector also validates keys managed by other participants:

  • Issuer keys: The connector verifies credential signatures against issuer public keys and certificate chains.
  • Holder keys: The connector validates key binding proofs to confirm that the wallet holder legitimately possesses the credential. See Device binding for details.

Further reading​

  • The ephemeral data model—how the connector processes credential data in memory and deletes it after callback delivery
  • Device binding—how key binding proves that the entity presenting a credential is its legitimate holder
  • OID4VP protocol—how the OID4VP protocol enables credential verification between wallets and Relying Parties