Device Binding: Tying EUDI Wallet Credentials to Your Device

Device binding is the cryptographic mechanism that ties a verifiable credential to a specific physical device by linking it to a private key stored in tamper-resistant hardware. In the EUDI Wallet, every credential is bound to a key pair generated in the device's Trusted Execution Environment (TEE) or Secure Element (SE), ensuring that the credential can only be presented by the device that legitimately holds it. This prevents credential cloning, copying, and relay attacks -- even if an attacker obtains a copy of the credential data, they cannot present it without access to the bound private key locked inside the original device's secure hardware.

Device binding operates through a three-phase process spanning credential issuance, storage, and presentation:

Phase 1 -- Key generation during issuance: When the wallet requests a credential via the OpenID4VCI protocol, it first generates a fresh asymmetric key pair inside the device secure element. The private key never leaves the secure hardware. The wallet includes the public key in the credential request, along with a proof-of-possession demonstrating control of the private key (typically by signing a nonce from the issuer).

Phase 2 -- Credential binding by the issuer: The issuer verifies the proof-of-possession and embeds the wallet's public key into the credential structure. For SD-JWT credentials, this is the "cnf" (confirmation) claim containing the public key or its thumbprint. For ISO mdoc credentials, the public key is included in the Mobile Security Object (MSO) as the deviceKey. The issuer then signs the entire credential, cryptographically sealing the binding between the credential content and the device public key.

Phase 3 -- Proof of possession during presentation: When the wallet presents the credential to a verifier via OpenID4VP, it creates a device signature (also called a presentation proof) by signing the verifier's challenge nonce with the bound private key. The verifier validates two signatures: the issuer's signature on the credential (proving authenticity and integrity) and the device signature on the presentation (proving the presenter controls the bound key). Both must validate for the credential to be accepted.

The security of device binding depends entirely on the security of the key storage. The EUDI Wallet supports two hardware-based key storage mechanisms:

• •Trusted Execution Environment (TEE): A TEE (like ARM TrustZone or Intel SGX) provides an isolated execution environment within the main processor. Keys stored in the TEE are protected from the regular operating system and applications, even if the device is rooted or infected with malware. Most modern smartphones have TEE capabilities. The Android Keystore and iOS Secure Enclave both use TEE hardware.
• •Secure Element (SE): A SE is a dedicated tamper-resistant chip (like those in SIM cards or embedded SE chips such as the Google Titan M or Apple T2). SEs provide stronger physical protection than TEEs -- they resist power analysis, electromagnetic probing, and physical decapping attacks. For high-assurance credentials like the PID, the EUDI framework may require SE-level key storage.

The EUDI Wallet certification framework defines which key storage level is required for different credential assurance levels. Person Identification Data (PID) at the "high" assurance level requires the strongest available hardware protection, while lower-assurance attestations may accept TEE-level storage. Wallet providers must demonstrate through certification that their key storage meets the required level.

• •Credential cloning: Without device binding, an attacker who intercepts or copies a credential could present it from their own device. Device binding makes the credential useless without the private key locked in the original device hardware.
• •Credential sharing: Users cannot simply share their credentials with others by sending the credential data. The receiving person would not have the bound private key and could not create valid presentation proofs.
• •Relay attacks: In a relay attack, an attacker intercepts the communication between wallet and verifier and relays it to a distant device. Device binding combined with session-specific challenges and proximity verification (NFC range limitations) makes relay attacks detectable and preventable.
• •Server-side credential theft: Even if a wallet backup server is compromised, attackers gain only encrypted credential data without the private keys. The credentials are useless without the hardware-bound keys on the user's device.