Presentation Flow Overview
Device authentication proves that the presenter controls the private key corresponding to the deviceKey in the MSO. This prevents credential theft.
Device Engagement
Initiated via QR code or NFC. Contains device's ephemeral key and connection info.
Session Keys
ECDH + HKDF derive symmetric keys for AES-GCM encrypted communication.
Session Transcript
Hash of session parameters. Signed by device key to prove freshness.
Device Signature
COSE_Sign1 over transcript using device key from MSO. Proves holder control.
Device Engagement
The presentation starts with Device Engagement - a CBOR structure typically encoded in a QR code or transmitted via NFC tap.
DeviceEngagement = {
0: "1.0", // version
1: { // security
1: 1, // cipher suite (1 = P-256 + AES-GCM)
2: { // device ephemeral key (COSE_Key)
1: 2, // kty: EC
-1: 1, // crv: P-256
-2: h'...x...', // x coordinate
-3: h'...y...' // y coordinate
}
},
2: [ // device retrieval methods
[ // BLE
2, // type: BLE
1, // version
{ // options
0: true, // peripheral server mode
1: h'...', // UUID
10: h'...' // BLE device address
}
]
],
3: {...} // server retrieval methods (optional)
}Transport Options
QR Code
Visual scan, then BLE/WiFi
NFC
Tap to start, data via NFC/BLE
WiFi Aware
Direct device-to-device
Session Encryption
After device engagement, both parties derive symmetric session keys using ECDH key agreement and HKDF key derivation.
Key Derivation Process
- 1. Device and reader exchange ephemeral ECDH public keys
- 2. Both compute shared secret: ECDH(myPrivate, theirPublic)
- 3. Apply HKDF with session transcript hash as salt
- 4. Derive two 256-bit keys: SKDevice (for device→reader) and SKReader (for reader→device)
- 5. Use AES-256-GCM with incrementing message counters
SessionTranscript = [
DeviceEngagementBytes, // tag(24) CBOR bytes
EReaderKeyBytes, // tag(24) reader ephemeral public key
Handover // varies by transport (NFC, BLE, QR)
]
// For QR code initiated:
Handover = null
// For NFC tap:
Handover = [
h'..nfc-handover-select..',
h'..nfc-handover-request..'
]Device Auth Signature
The holder's device signs the DeviceAuthentication structure using the private key corresponding to the deviceKey in the MSO.
// DeviceAuthentication structure (what device signs)
DeviceAuthentication = [
"DeviceAuthentication", // context string
SessionTranscript, // includes DeviceEngagement + ReaderEngagement
docType, // "org.iso.18013.5.1.mDL"
DeviceNameSpacesBytes // CBOR bytes of disclosed namespaces
]
// deviceAuth in DeviceResponse
"deviceAuth": {
// Option 1: ECDSA signature
"deviceSignature": COSE_Sign1([
h'..protected..', // {1: -7} for ES256
{}, // unprotected
null, // detached payload
h'..signature..' // ECDSA signature
])
// Option 2: MAC (if reader has shared key)
// "deviceMac": COSE_Mac0(...)
}What's Signed
- Context string ("DeviceAuthentication")
- SessionTranscript (device + reader keys)
- Document type being presented
- Disclosed namespace data
Why It Matters
- Proves device key possession
- Binds response to this session
- Prevents replay attacks
- Links disclosed data to signature
Complete Verification
The reader must verify both the issuer's signature (MSO) and the device's signature to fully validate a presentation.
1 Decrypt DeviceResponse
Use SKDevice to decrypt the AES-GCM encrypted response
2 Verify Issuer Signature
Verify issuerAuth COSE_Sign1 signature and X.509 certificate chain to trusted IACA
3 Verify MSO Validity
Check validFrom/validUntil, docType matches expected
4 Verify Value Digests
Hash each IssuerSignedItem and match against MSO valueDigests
5 Verify Device Signature
Verify deviceAuth signature using deviceKey from MSO
6 Reconstruct Session Transcript
Verify the signature was made over the correct DeviceAuthentication with this session's transcript
Security Considerations
Device authentication security depends on proper key management and session handling.