Keyless entry made car theft quieter: a relay that stretches the radio link between a fob and a car can unlock and start many vehicles without touching the key. Phone-based digital keys built on the Car Connectivity Consortium (CCC) Digital Key specification, with Bluetooth Low Energy (BLE) and Ultra Wideband (UWB) ranging, change the picture by binding access to keys in a secure element and to a measured distance rather than signal strength. This guide explains how legacy remote keyless entry (RKE) and passive keyless entry and start (PKES) fail, how CCC digital keys are paired, shared and revoked, why UWB and Bluetooth Channel Sounding matter, and what OEMs, fleet operators and security teams should test, monitor and fix. It goes deeper than the Automotive Cybersecurity Guide and is written for vehicle security engineers, fleet and car-sharing operators, and assessors.
Key takeaways
- Relay attacks defeat cryptography, not break it. Research on passive keyless entry showed physical-layer relays work regardless of the protocol or encryption used, because the car trusts that a reply means the key is close.
- Distance must be measured, not inferred. UWB time-of-flight ranging and Bluetooth Channel Sounding give the vehicle an authenticated distance; signal strength (RSSI) based proximity does not.
- The digital key is a credential lifecycle. Owner pairing, sharing with entitlements, server registration and deletion are identity processes and need the same rigour as any privileged credential.
- The car is still the weakest link. CAN injection attacks bypass the smart key entirely by impersonating the key receiver ECU, so in-vehicle message authentication matters as much as the key.
- Keep the fallbacks honest. NFC card keys, battery-low modes, physical fobs and dealer key programming are legitimate paths that attackers target when the main path is strong.
How keyless entry systems work and fail
Vehicle access has moved through three generations, and most fleets contain all three at once. Each one fails in a different way, so a programme has to know which technology is fitted to which vehicle.
| Generation | How it works | Main attack | Primary defence |
|---|---|---|---|
| Remote keyless entry (RKE) fob | Button press sends a one-way radio code, usually with a rolling counter | Jamming and capture of an unused code, replay of weak or fixed codes | Cryptographic rolling codes with challenge-response, jamming detection, ignoring stale counters |
| Passive keyless entry and start (PKES) fob | Car sends a short-range wake-up and challenge; fob answers if it hears it; proximity inferred from signal reach | Relay attack: two devices extend the link between car and key | Distance bounding (UWB), motion-sensing fobs that sleep when still, user option to disable passive entry |
| Phone digital key (CCC Release 2.0 NFC) | Phone tapped on an NFC reader in the door handle and console; keys held in the phone's secure element | NFC relay over short ranges, theft of an unlocked phone, weak sharing processes | Short NFC range, mutual authentication, device unlock policies for sharing and driving |
| Phone digital key (CCC Release 3.0 and later, BLE plus UWB) | BLE authenticates the key; UWB anchors measure time of flight to locate the phone before unlock or start | Ranging manipulation, downgrade to weaker modes, attacks on the back end and sharing | Secure ranging with session keys, no RSSI fallback, server and lifecycle controls |
The relay problem was demonstrated publicly in a 2011 NDSS paper by Francillon, Danev and Capkun, which tested 10 car models from 8 manufacturers. Their relays operated at the physical layer, so the attack worked whatever modulation, protocol or encryption the system used. Relaying only from car to key was enough, and the real distance between key and car could be large, up to 50 metres in their non-line-of-sight tests. That finding still drives design today: strong authentication alone does not prove presence.
The scale of the problem is visible in policing data. The UK Home Office factsheet for the Crime and Policing Act 2026 cites a Metropolitan Police estimate that electronic devices are used in about 60% of vehicle thefts in London, and Crime Survey for England and Wales data for April 2019 to March 2020 showing a manipulated remote locking signal in 36% of vehicle thefts. The same Act creates offences of possessing, importing, making, adapting or supplying an electronic device for use in vehicle theft, with a maximum of five years' imprisonment, an unlimited fine or both. Check commencement before relying on the offence in a given case.
The CCC Digital Key architecture
The CCC Digital Key specification defines how a phone or wearable stores, authenticates and shares a vehicle key. Release 2.0 used NFC. Release 3.0, finalised in July 2021, added passive keyless access and engine start using UWB with BLE, while keeping NFC for backward compatibility and for a battery-low mode. On 27 October 2026 the CCC download page listed Digital Key Technical Specification V3.1.4 and V4.1.0; check the CCC site for the current version, because releases continue. CCC certification is available only to members, and products that pass testing at an authorised lab may carry the CCC Digital Key mark.
Apple's Platform Security documentation for car keys, which implements the CCC specification, gives one of the few public descriptions of the cryptography. Other phone platforms implement the same specification; use their own documentation for platform details.
- Owner pairing: the owner proves possession of the vehicle, usually with one or two fobs, and starts pairing from the carmaker's app, a link or the vehicle menu. A confidential one-time pairing password feeds a SPAKE2+ exchange on NIST P-256, which sets up a GlobalPlatform SCP03 secure channel between phone and vehicle.
- Key generation: the vehicle asks the phone's secure element to generate an elliptic curve key pair bound to the vehicle identifier and vehicle public key. The phone returns its public key as an X.509 certificate whose chain verifies against the carmaker root public key embedded in the vehicle at production.
- Server registration: where the carmaker or an insurer requires it, the certificate chain goes to the carmaker's key tracking server (KTS), and the vehicle enables the owner key only after the KTS signature verifies.
- Fast and standard transactions: an NFC fast transaction, used only to unlock, uses an AES-128 cryptogram from a secret set up earlier. A standard transaction uses ephemeral ECC keys, ECKA-DH and HKDF (RFC 5869) with signatures from the long-term keys, and is always used to authorise driving.
- UWB session keys: for UWB keys, a BLE secure session agrees a UWB Ranging Secret Key (URSK), which goes to the phone's UWB radio and over a carmaker-specific secure channel to the vehicle's UWB anchors. Apple describes anchors at the four interior corners and optionally the boot, and URSKs with a time to live that can be pre-derived so ranging does not wait on a full transaction.
The important design point for security teams is that the key never exists outside a secure element on the phone or a hardware security module or secure element in the vehicle. The weak points move to the processes around it: who can pair, who can share, how fast a key can be killed, and what the vehicle accepts when the phone is not available.
Distance bounding: UWB and Bluetooth Channel Sounding
Relay attacks work because classic PKES infers proximity from the fact that a reply arrived. Distance bounding measures the round-trip time of a signal that an attacker cannot predict, so a relay adds delay that shows up as extra distance. Two technologies are relevant to digital keys.
| Technology | Standard | How it measures distance | Security points to check |
|---|---|---|---|
| Ultra Wideband | IEEE 802.15.4z-2020 (Enhanced UWB PHYs and ranging; now superseded and folded into later IEEE 802.15.4 revisions) | Time of flight of short UWB pulses between phone and several anchors | Ranging uses a per-session secret (the CCC URSK); confirm the secure ranging mode is used, that keys expire, and that the vehicle rejects implausible ranging results |
| Bluetooth Channel Sounding | Bluetooth Core Specification (the LE 2M 2BT PHY used with Channel Sounding is defined from version 6.0) | Phase-based ranging across up to 72 channels combined with round-trip timing | Channel Sounding has its own security setup; check that randomised tone extension slots, antenna path selection and secure access addresses are enabled, and that phase and timing results are cross-checked |
| RSSI proximity (legacy BLE keys) | None for distance | Received signal strength | Trivially extended by a relay or amplifier; do not use as the sole proximity decision for unlock or start |
Distance bounding is not automatic protection. It only works if the vehicle refuses to act when ranging is unavailable, and if the decision logic uses the secure measurement rather than a faster but weaker signal. A vehicle that silently falls back to RSSI when UWB fails has the same relay exposure as a 2010 fob. Ask suppliers for the exact fallback behaviour, and test it.
Where identity fits: sharing, entitlements and revocation
A digital key is an identity credential for a physical asset, and the sharing model looks like delegated authorisation. Treat it with the same discipline as any machine or delegated credential. See the Device and IoT Identity Guide.
- Delegation: in Apple's CCC implementation, the owner shares an invitation through any channel, the sender authenticates with Face ID, Touch ID or a passcode, and the sender's phone signs the recipient's public key after verifying the recipient's certificate chain. The vehicle checks that signature on first use, plus a KTS attestation where the carmaker requires one.
- Entitlements: shared keys carry an access level (for example unlock only, or drive) and a resharing policy (none, limited or unlimited). The CCC overview also describes limiting access duration and features, such as the passenger door or boot only. Default to the narrowest entitlement and no resharing.
- Revocation: Apple documents that deletion on the keyholder's phone takes effect immediately even offline, while deletion in the vehicle follows carmaker policy, such as anytime, only when online, or only with a fob present. Remote termination goes to the carmaker first and returns a signed termination attestation as proof of deletion. Know which policy your vehicles use, because "only when online" means a vehicle in an underground car park keeps honouring a revoked key.
- Back-end accounts: the carmaker app account, the KTS and the fleet or car-sharing platform become the control plane for physical access. Protect operator and support accounts with phishing-resistant MFA and least privilege. See the Connected Fleet and Telematics Security Guide.
- Privacy: Apple states that accessories that cannot authenticate receive no stable identifier over NFC or Bluetooth, which limits tracking. Check the same property on any key-holding device or aftermarket module you deploy.
Beyond the key: CAN injection and in-vehicle trust
A strong key does not help if the vehicle believes any message saying the key was accepted. In 2023 Ken Tindell of Canis Automotive Labs described thefts of a Toyota RAV4 in which thieves reached the CAN bus through the headlight connector and injected messages impersonating the smart key receiver. The gateway forwarded them to the engine control system, which disabled the immobiliser, and a second message told the door ECU to unlock. The cryptography of the key was never touched.
His proposed fixes are a useful pattern for any OEM: a short-term gateway or immobiliser software change that ignores key messages after unusual bus error patterns, and a long-term move to cryptographic authentication of critical in-vehicle messages backed by hardware keys and per-vehicle key provisioning. In AUTOSAR terms that means SecOC on the messages that report key validation, immobiliser release and door unlock. See the CAN Bus and AUTOSAR SecOC Guide.
Threat to control mapping
| Threat | Where it acts | Controls | How to verify |
|---|---|---|---|
| PKES relay | Radio link between fob and car | UWB or Channel Sounding distance bounding; motion-sensing fobs; option to disable passive entry; no RSSI fallback | Relay test with extended link in a controlled lab; check behaviour with UWB disabled |
| RKE jam and replay | Fob button signal | Challenge-response or strong rolling codes; counter window limits; jamming detection | Replay of captured codes in a shielded test environment |
| CAN injection | Exposed wiring at the vehicle edge | SecOC on key and immobiliser messages; gateway filtering; anomaly detection for bus errors | Inject spoofed key-valid frames on a test vehicle and confirm rejection |
| Unauthorised sharing | Phone and carmaker back end | Device unlock to share; narrow entitlements; no resharing by default; KTS attestation | Attempt reshare from a limited key; audit shared key list |
| Slow revocation | Vehicle and KTS | Policy that allows offline deletion in the vehicle; periodic reconciliation with KTS | Revoke a key and attempt use with the vehicle offline |
| Fallback abuse | NFC card keys, dealer tools, OBD key programming | Restrict key programming to authenticated dealer tools; log every key add; owner notification | Review key-add events against service records |
| Back-end account takeover | Carmaker app, fleet portal | Phishing-resistant MFA, step-up for key actions, rate limits, owner alerts | Account takeover test in staging; alert latency check |
Implementing a digital key programme
The approach differs by role. OEMs and tier-one suppliers own the design, fleet and car-sharing operators own configuration and lifecycle, and enterprise security teams usually own back-end accounts and incident response. The phases below work for all three with different weights.
- Inventory the access technology per vehicle: RKE, PKES, NFC digital key, UWB digital key, aftermarket telematics unlock. Record whether passive entry can be disabled and what the fallback modes are.
- Set the security requirement: unlock and start decisions must rely on authenticated distance (UWB or Channel Sounding) or deliberate user action (NFC tap, button), never RSSI alone. Write this into supplier requirements and your ISO/SAE 21434 cybersecurity goals. See the ISO/SAE 21434 Automotive Cybersecurity Engineering Guide.
- Define lifecycle policy: who may pair an owner key, default entitlements for shared keys, resharing rules, revocation targets and vehicle-side deletion policy. Fleets should map keys to driver identities in the HR or contractor system so leavers lose access.
- Pilot with test vehicles: run relay, replay, fallback and revocation tests in a controlled lab on a small set of vehicles before enabling passive entry for the fleet. Keep passive entry off by default until tests pass.
- Roll out in rings: internal drivers first, then a small customer or driver group, then the fleet. Keep physical keys and the previous access mode available so you can roll back by disabling passive entry or digital key sharing centrally if a flaw appears.
- Connect to monitoring: stream key events (pairing, sharing, deletion, key add by dealer tool, failed ranging) to the vehicle SOC or fleet SIEM. See the Vehicle Security Operations Centre Guide.
Decision guidance
- Legacy PKES fleet: if the vehicle cannot be upgraded, disable passive entry where the owner or fleet can, use motion-sensing fobs, and use physical or signal-blocking storage for spare keys. This is cheaper than replacement and removes most relay risk.
- NFC-only digital key versus UWB: NFC requires a deliberate tap at close range and is a sound choice for fleets that value control over convenience. UWB gives hands-free access with distance bounding but adds back-end and ranging complexity.
- Small operators: rely on the carmaker's platform, focus on account security, entitlements and revocation, and keep a manual key audit monthly.
- Large fleets and car sharing: integrate key issuance with identity governance, automate revocation on contract end, and require suppliers to document fallback behaviour and KTS policy.
Detection and measurement
Most key abuse is only visible in back-end and vehicle logs. Collect these events and keep them long enough to investigate thefts reported days later.
- Key lifecycle events: owner pairing, share invitations, first use of shared keys, entitlement changes, deletions and termination attestations.
- Vehicle access events: unlock and start with key identifier, ranging result or method used (UWB, NFC, fob), and any fallback mode.
- Anomalies: unlock with no subsequent ranging success, starts shortly after a dealer-tool key add, bursts of CAN bus errors before an immobiliser release, and use of a key after its revocation was requested.
- Back-end signals: new device sign-ins to owner accounts, password resets followed by key sharing, and support-desk changes to account email or phone.
Metrics that show the programme works:
- Percentage of the fleet where unlock and start rely on authenticated distance or deliberate action rather than RSSI or classic PKES.
- Median time from revocation request to the key being unusable at the vehicle, including offline vehicles.
- Percentage of shared keys with the minimum entitlement and no resharing.
- Number of key-add events by dealer or service tools not matched to a service record.
- Relay and fallback test pass rate per vehicle model, retested after each software release.
Framework mapping
| Framework | Reference | How it applies to digital keys |
|---|---|---|
| NIST CSF 2.0 | PR.AA-01, PR.AA-03 | Manage key credentials and authenticate devices and users before access |
| NIST CSF 2.0 | PR.DS-02, DE.CM-09 | Protect key transactions in transit; monitor vehicles and back ends for adverse events |
| NIST SP 800-53 Rev. 5 | IA-3, IA-5 | Device identification and authentication; authenticator lifecycle for keys |
| NIST SP 800-53 Rev. 5 | SC-8, SC-12, SC-23 | Transaction integrity, key establishment and session authenticity (ranging sessions) |
| NIST SP 800-53 Rev. 5 | AC-2, AC-3, AU-2, SI-4 | Shared key accounts and entitlements, event logging and monitoring |
| ISO/SAE 21434 | Threat analysis and risk assessment | Relay, injection and lifecycle abuse belong in the TARA for access systems |
Common failure patterns
- Silent RSSI fallback: a UWB-capable vehicle unlocks on BLE signal strength when ranging fails, restoring relay exposure.
- Passive entry left on for legacy fobs: owners and fleets are not told that passive entry can be disabled, or the option is buried in a dealer menu.
- Unauthenticated key-valid messages: the immobiliser trusts a CAN frame from the key receiver ECU, so a device at the headlight connector can start the car.
- Revocation that waits for connectivity: vehicle-side deletion only when online means a stolen or shared phone keeps working in a basement.
- Broad sharing defaults: shared keys default to drive access with resharing allowed, and no one reviews the list.
- Back-end support bypass: a support agent can change the owner account email or add a key without strong verification, making the help desk the easiest theft route.
Practitioner checklist
- Record the access technology, passive entry setting and fallback modes for every vehicle model.
- Require authenticated distance (UWB or Channel Sounding) or deliberate action for unlock and start; ban RSSI-only decisions.
- Test relay, replay, CAN injection and fallback behaviour in a controlled lab before enabling passive entry.
- Authenticate key-valid, immobiliser and unlock messages inside the vehicle with SecOC or equivalent.
- Default shared keys to minimum entitlement, a set duration and no resharing.
- Set a vehicle-side deletion policy that works offline and measure revocation time.
- Protect owner, fleet and support accounts with phishing-resistant MFA and step-up for key actions.
- Log pairing, sharing, deletion, dealer key adds and ranging failures to the vehicle SOC.
- Advise owners of legacy PKES vehicles how to disable passive entry and store spare keys.
Standards and references
- Car Connectivity Consortium: Digital Key
- Apple: Car key security (Apple Platform Security)
- Apple: Car key transactions (Apple Platform Security)
- IEEE: 802.15.4z-2020 Enhanced Ultra Wideband PHYs and Associated Ranging Techniques
- Bluetooth SIG: Channel Sounding Technical Overview
- IACR ePrint: Relay Attacks on Passive Keyless Entry and Start Systems in Modern Cars
- UK Home Office: Crime and Policing Act 2026 serious crime factsheet
- Canis Automotive Labs: CAN Injection, keyless car theft
Related NHI Mgmt Group resources: Automotive Cybersecurity Guide · CAN Bus and AUTOSAR SecOC Guide · Bluetooth, RFID and NFC Security Guide · Connected and Autonomous Vehicle Security Guide