The CCC Digital Key Authentication Flow, Step by Step
Owner pairing, key sharing, and the cryptographic handshake that has to succeed before UWB ranging ever begins
The previous post in this series established that UWB ranging in CCC Digital Key can't happen without BLE — BLE authenticates the key before UWB ever gets invoked. This post goes into that authentication stage in detail: what "owner pairing" actually involves, how the cryptographic handshake works, and how key sharing extends the same trust model to friend devices.
This is the layer that everything else in CCC Digital Key sits on top of. Ranging precision, AoA, STS — none of it matters if the authentication step it depends on isn't sound.
Two Distinct Flows: Owner Pairing and Authentication
It's worth separating two things that are related but not the same:
Owner pairing happens once, when a vehicle owner first sets up their phone as a Digital Key. This is the process that establishes the phone as the trusted "owner device" for a specific vehicle, and it's what makes everything after it possible.
Authentication happens every single time the phone and vehicle interact afterward — every door unlock, every engine start. This is a much lighter, faster process that relies on the trust established during owner pairing, rather than re-establishing it from scratch.
Confusing these two is a common source of misunderstanding when people first encounter the spec: owner pairing is the expensive, one-time setup; authentication is the cheap, repeated verification that happens dozens of times a day.
Owner Pairing: Establishing the Root of Trust
Per CCC's own specification, the owner pairing flow is operated jointly by two components on the phone side: the Digital Key Framework and the DK Applet. The Framework uses APDU commands (the standard command format for smart card / secure element communication) to manage the Digital Key's configuration, while the actual security-critical operations happen inside the Applet, which lives in the Secure Element.
This split matters conceptually: the Framework is the orchestration layer, but it never touches key material directly. The Secure Element is described in CCC's spec as the root of trust — the starting point that every subsequent security guarantee in the system depends on. If the Secure Element's isolation is sound, the keys inside it can't be extracted or forged regardless of what happens to the rest of the phone's software stack.
The pairing process itself begins over BLE, using an out-of-band (OOB) pairing procedure. In practice, this looks like:
The vehicle begins broadcasting a BLE advertisement using a CCC-specific UUID that identifies it as CCC Digital Key-capable — this is how a phone recognizes that a nearby vehicle supports the protocol at all, rather than treating it as an arbitrary BLE device.
The phone detects this advertisement and initiates a connection.
Out-of-band pairing data is exchanged — this is what makes the pairing "out of band" rather than relying solely on standard BLE pairing, adding a layer of verification that the devices being paired are the ones the user actually intends.
Once this connection-layer pairing succeeds, the actual cryptographic key exchange for the Digital Key itself begins — and this is where things get more specific.
The Cryptographic Handshake
CCC's own Digital Key Applet Protection Profile — the security specification evaluated under Common Criteria and published through the Common Criteria Portal — describes the core mechanism plainly: the vehicle generates an ephemeral public key and signs it using the vehicle's permanent private key (vehicle_SK). This signature is what allows the device to authenticate the vehicle.
This single mechanism is worth unpacking, because it does two things at once:
It authenticates the vehicle to the device. Because the signature is generated with the vehicle's long-term private key — not a temporary one — the device can verify it against the vehicle's known public key (established during owner pairing) and be confident it's talking to the genuine paired vehicle, not an impostor.
It protects against man-in-the-middle attacks without leaking privacy-sensitive data. Per the Protection Profile, this signing approach guarantees that no privacy-sensitive data can be leaked through a MITM attack, and it further allows the device to transmit data back to the vehicle without risk of leakage to an intercepting third party.
CCC's specification also defines a lighter-weight variant of this exchange for a specific case: when user authentication is disabled, the device's own signature is not sent back to the vehicle at all — a deliberate reduction in the exchange for scenarios where the full mutual-authentication step isn't required.
The broader pattern here — ephemeral keys exchanged per session, authenticated using permanent key material held only in the Secure Element — is the same architectural principle that CCC's Protection Profile describes for the Secure Element as the system's "root of trust." Two implementation variants are permitted for how this root of trust is structured inside the Secure Element: one based on CASD (Controlling Authority Security Domain), and one based on a security domain associated directly with the DK Applet. Either is acceptable, as long as it's implemented according to the specification.
Key Sharing: Extending Trust to Friend Devices
Owner pairing establishes trust between one phone and one vehicle. Key sharing extends that trust to additional "friend" devices — without those devices ever needing to physically visit the vehicle or go through the same OOB pairing process.
Per CCC's own published use case description, the mechanism works as follows: the CCC Digital Key framework establishes a secure communications channel between the owner device and the friend device, through which the owner device signs (approves) the friend device's digital key — its public key — and the necessary signatures (approvals) are obtained from the vehicle OEM server. To ensure the shared key is usable only by the intended recipient, the owner may optionally provide a sharing password or PIN, communicated through a separate channel from the sharing link itself (for example, the link sent by SMS, and the PIN communicated by voice or a different message).
One property of this system is worth calling out specifically, because it reflects deliberate security design:
Friend devices generally cannot re-share the key onward. A friend device sharing access with a second friend isn't part of the standard model established in earlier Digital Key releases — CCC's Digital Key 4.0 introduces multi-level delegation as a specific new capability precisely because this wasn't possible before, as covered in the earlier post on the release evolution.
CCC's own materials also note that this sharing capability is what underpins fleet, ridesharing, and rental use cases — a single owner-established trust relationship with the vehicle OEM server extends outward to any number of friend devices, each individually signed and approved, rather than each friend device needing its own independent relationship with the vehicle.
Why This Flow Matters Beyond Compliance
Ephemeral key handling is where implementation bugs hide. The security properties of this exchange depend entirely on ephemeral keys actually being ephemeral — generated fresh per session, never reused, and properly destroyed afterward. An implementation that accidentally caches or reuses an ephemeral key pair across sessions silently undermines the MITM protection the Protection Profile describes, without necessarily failing any functional test that only checks "does the unlock work."
The Secure Element's root-of-trust implementation choice has real consequences. CCC's Protection Profile permits two structurally different approaches (CASD-based or DK Applet-associated security domain), and the choice affects how key material is isolated and managed within the Secure Element. This is exactly the kind of architectural decision that gets made early in a certification program and is expensive to revisit later.
Owner pairing failure modes deserve as much design attention as the happy path. Because owner pairing is a one-time, higher-stakes operation than routine authentication, the user experience and error handling around pairing failures — mismatched pairing passwords, interrupted connections, timeout handling — has an outsized impact on how the overall system is perceived, even though it's a small fraction of total system usage.
Key Takeaways
Owner pairing (one-time, expensive) and authentication (repeated, lightweight) are distinct flows that build on each other — pairing establishes the root of trust; authentication verifies it on every interaction.
The core handshake is a mutual-authentication exchange using ephemeral key pairs and permanent-key signatures — both parties must cryptographically prove their identity before the session is trusted.
Ephemeral keys serve both security and privacy purposes — they enable session-specific key derivation while preventing long-term tracking of a device via its permanent identity.
Key sharing extends trust without requiring friend devices to physically pair — using a sharing link and an attestation credential, validated through the same underlying handshake structure.
What's Next
The next post steps outside CCC's own specification to look at how it relates to another standards body covered earlier in this series: CCC vs FiRa — how the two UWB standards relate, examining where CCC's Digital Key spec and the FiRa Consortium's UWB profiles overlap, differ, and depend on each other.
