The Digital Access Dilemma: Auditing Bluetooth, UWB, and Smartphone Key Tokenization Infrastructure

The physical key fob is one of the most mature pieces of consumer security hardware ever deployed at scale. It is a sealed, single-purpose radio transmitter with a coin cell that lasts for years, a firmware image that almost never changes and a behaviour that is, for practical purposes, deterministic: press the button and the doors respond within a fraction of a second. The smartphone digital key replaces that dedicated device with a general-purpose computer running a multi-tasking operating system, hundreds of third-party applications, an aggressive power-management policy and a battery that is depleted every day by design. The promise is real. A phone is always carried, it can be shared remotely with a family member or a fleet driver, and it can hold a cryptographically strong credential protected by dedicated hardware. The cost is an increase in the number of software layers between the driver and the door handle, and each layer is a potential source of delay or failure. This article audits that trade-off from an engineering perspective, and calls it the digital access dilemma: a system that is more capable and more secure in the abstract can still be less dependable at the kerbside.

The analysis is written for connected-car software specifiers, automotive security directors and clean-tech fleet mobility managers. It first separates the wireless physics of Bluetooth Low Energy (BLE) signal-strength estimation from Ultra-Wideband (UWB) time-of-flight ranging, since the difference determines whether relay attacks are feasible. It then examines the mobile operating system constraints that govern whether a background task can respond at the moment of approach. It traces the cryptographic path defined by the Car Connectivity Consortium (CCC) Digital Key specification, from the phone's secure element to the vehicle. It then profiles what happens when the phone has no power, and closes with a comparative matrix and a set of specification and fleet policy recommendations. Where numerical values are given, they are representative engineering ranges, and individual implementations will vary by vehicle, handset and software version.

Access architectures compared: fob, phone and card

Three broad access topologies are in use. The first is the conventional fob, which communicates with the vehicle over a dedicated radio link. Remote keyless entry typically uses a sub-GHz channel, commonly in the 315 MHz or 433 MHz bands in many markets, with a rolling-code or challenge-response protocol. Passive keyless entry and start (PKES) adds a low-frequency (LF) wake-up field, at around 125 kHz, generated by antennas in the doors and cabin. The vehicle emits a short-range LF challenge, the fob wakes and replies over the ultra-high frequency (UHF) channel, and the system infers proximity from the fact that the fob was able to receive the LF signal at all. More recent fobs add UWB to measure distance directly.

The second topology is the phone-as-a-key (PaaK) architecture. The phone communicates over BLE for discovery and data exchange and, in the most capable implementations, over UWB for secure ranging. Near-field communication (NFC) provides a short-range tap-to-unlock path. The credential is not a physical object but a cryptographic key pair provisioned into the phone's secure hardware, and the user experience is managed by an operating system and a wallet or manufacturer application. The third topology, a card-format key, uses NFC alone and is often supplied as a backup for the electronic key. Each has different behaviour with respect to range, dependability, security and power, and the sections that follow characterise those differences rather than ranking the technologies in the abstract.

Wireless access protocols and ranging physics

BLE and the limits of signal-strength estimation

BLE operates in the 2.4 GHz band using 40 channels, three of which are used for advertising. Its design goals are low power and low cost, not precise spatial measurement. The simplest way to estimate distance over BLE is to measure the received signal strength indication (RSSI), the power of the received signal, and compare it with a reference value, using a path-loss model in which received power falls with the logarithm of distance. In free space, the received power falls by approximately 6 dB each time the distance doubles. In practice, the relationship is badly distorted. The human body absorbs 2.4 GHz energy substantially, so a phone in a trouser pocket on the side of the body facing away from the vehicle may read many decibels lower than the same phone held in the hand. Walls, parked vehicles and metal surfaces produce multipath reflections that cause constructive and destructive interference, so that the signal strength can vary by 10 dB or more over a few centimetres. Antenna orientation, handset model and case material add further variation.

As a result, an RSSI-based distance estimate has an uncertainty of metres, not centimetres, and the mapping between measured power and distance is unstable. A system that unlocks when the RSSI exceeds a threshold will unlock at an inconsistent range, which produces both the frustrating failure to unlock at the door and the inadvertent unlock when the owner is some distance away. More importantly for security, RSSI measures only the amplitude of the signal received, and amplitude can be manipulated. An attacker with a pair of radio relays can capture the vehicle's challenge, forward it over a wireless or wired link to a second device held near the genuine key, and relay the response back. Because the legitimate key and vehicle are exchanging authentic, correctly signed messages, cryptography alone does not detect the attack. The only information that distinguishes a key a few centimetres away from one 100 metres away is a measurement of distance, and a measurement based on signal strength can be spoofed by simply amplifying the relayed signal until it looks sufficiently strong.

UWB impulse radio and time-of-flight ranging

UWB uses a fundamentally different approach. Instead of continuously modulating a narrow carrier, an impulse-radio UWB transmitter sends extremely short pulses, on the order of a nanosecond or less in duration, spread across a bandwidth of at least 500 MHz. The IEEE 802.15.4z standard, which added enhancements for secure ranging to the earlier 802.15.4a high-rate pulse specification, defines the physical layer used in automotive and consumer deployments, with channels commonly at 6.5 GHz (channel 5) and 8 GHz (channel 9). The wide bandwidth gives the signal very fine time resolution, because the temporal sharpness of a pulse is inversely proportional to its bandwidth. A receiver can therefore determine when the leading edge of a pulse arrived with a precision of a fraction of a nanosecond.

Time-of-flight (ToF) ranging converts that timing into distance. Radio waves travel at approximately 0.3 metres per nanosecond, so one nanosecond of propagation delay corresponds to roughly 30 centimetres of distance. Resolving distance to the centimetre level therefore demands timing precision of tens of picoseconds, which UWB hardware achieves through its wide bandwidth and precise timestamping of the received pulse. Because two devices do not share a synchronised clock, practical systems use two-way ranging. The initiator sends a poll message and records its transmission time. The responder receives it, waits for a known reply delay, and sends a response, and the initiator records the arrival time. The time of flight is derived from the round-trip time minus the responder's reply delay, divided by two. Double-sided two-way ranging adds a third message to cancel out the effect of clock drift between the devices. Typical measured accuracy in line-of-sight conditions is of the order of 10 centimetres, and it degrades when the signal is obstructed or when the leading edge is hard to distinguish from reflections.

The security advantage is physical. A relay attack adds delay: the signal must be received, processed, transmitted across the relay link and retransmitted, all of which takes time. Because radio signals cannot travel faster than the speed of light, no relay can make the measured time of flight shorter than the true distance would allow, and any relay that adds even a few nanoseconds shows up as additional apparent distance. An attacker who tries to advance the signal, by guessing its content and transmitting early, runs into a second feature of the standard. The 802.15.4z High Rate Pulse mode includes a Scrambled Timestamp Sequence (STS), a cryptographically generated pseudo-random pulse sequence derived from a shared secret, which the receiver checks to verify that the ranging signal came from the legitimate counterpart. Because the sequence is unpredictable and changes with every exchange, an attacker cannot forge it in advance, which closes the early-detect and late-commit attacks that affected earlier impulse-radio ranging. Measuring time in nanoseconds with authenticated pulses is what changes distance bounding from a heuristic into a physical guarantee.

Angle of arrival and the spatial model

Distance alone does not determine whether a driver is entering the vehicle or merely walking past it. Many vehicles use multiple UWB anchors, typically three or more, distributed around the body, so that the system can compute a position by trilateration, and some UWB devices also estimate the angle of arrival from the phase difference between two or more antennas. The combined data allows the vehicle to distinguish a phone at the driver's door from one in the boot or inside the cabin, and to apply different behaviours: unlock only when the owner approaches and is within about a metre or two of a door, permit starting only when the phone is inside, or lock the vehicle as the owner walks away. This spatial awareness is also the basis for features such as hands-free boot opening and approach lighting. The same capability explains why UWB is not simply a replacement for BLE. BLE is used for discovery, the initial link and low-bandwidth data, while UWB is activated for ranging when the system needs a secure position estimate.

Mobile operating system constraints and background execution

The structural mismatch between a key and a general-purpose operating system

A key fob is a device that does one thing and is always ready to do it. A phone is designed to do hundreds of things, and the operating system assumes that most of them need not run most of the time. Both iOS and Android therefore manage background execution aggressively to conserve battery and memory. Applications that are not in the foreground are suspended, their processes can be terminated without notice if memory is required elsewhere, and their ability to use the radio, schedule work or wake the processor is limited. This design is sensible for a consumer device, but it conflicts with the requirement of a vehicle key: the vehicle expects the phone to answer a connection request within a few hundred milliseconds of the driver arriving, and the driver expects the doors to unlock before they reach the handle.

The severity of this friction depends on how the digital key is implemented. Where the key is integrated into the operating system, as in the wallet frameworks used by the major platforms, the credential and the radio handshake are handled by system services with privileged status, and the experience is much more dependable. Where the key depends on a manufacturer's own application running in the background, as is common for older implementations and for many fleet and car-sharing systems, the application is subject to the same constraints as any other third-party app, and failures are more frequent.

iOS and Android memory and power policies

On iOS, a third-party application that moves to the background is suspended within a short period unless it holds a specific background mode. Apps may declare the bluetooth-central or bluetooth-peripheral background capabilities, which allow the system to wake them in response to Bluetooth events, but the system retains control over timing and may defer or coalesce events. If the user force-quits the application from the app switcher, the system generally does not relaunch it for background Bluetooth events until the user opens it again, which silently disables the digital key. Low Power Mode further reduces background activity, throttles scanning and can delay delivery of events.

Android presents a more fragmented picture. The platform uses Doze mode, which defers background work when the device is stationary and unplugged, App Standby buckets, which restrict apps according to how recently they were used, and foreground service requirements for long-running Bluetooth tasks. In addition, many handset manufacturers layer their own aggressive battery optimisation on top of the platform's policies, terminating background processes that the platform itself would permit. The result is that the same application can behave very differently across devices, and a key that is dependable on one handset can fail intermittently on another. For fleet operators who allow drivers to use their own handsets, this variability becomes a support burden that is difficult to predict or test comprehensively.

How a frozen background task becomes a failed entry

The failure sequence is usually a timeout, not a crash. The vehicle detects the phone's BLE advertisement, or, in a connection-oriented design, attempts to reconnect to a previously paired phone. The phone's radio hardware may be capable of responding, but the controlling application or system service may have been suspended or may be waiting for the processor to wake. If the response arrives late, the vehicle's authentication handshake times out, and the doors remain locked. The driver, standing at the vehicle, retries by opening the application, which brings it to the foreground, and the handshake then succeeds a few seconds later. This delay of three to ten seconds, repeated occasionally, is often more damaging to user confidence than an outright failure, because it appears random and is hard to reproduce.

Ranging handshakes add further complexity. UWB sessions must be negotiated over BLE and then initiated by the phone's UWB subsystem, which draws considerably more power than BLE and is therefore activated only when required. If the BLE connection is slow to establish because of the operating system's scheduling, the UWB session starts late, and the vehicle may apply its distance threshold to a phone that is still in the process of ranging. The vehicle may then fall back to a less capable, lower-confidence authentication mode, which in turn changes the features that are available. Software specifiers should therefore treat the timing budget of the full approach sequence, from first advertisement to authenticated unlock, as a measurable service-level objective, and test it across handset models, operating system versions, battery states and user power settings.

CCC cryptographic tokenisation and secure element architecture

The Digital Key framework

The Car Connectivity Consortium's Digital Key specification defines a standardised, interoperable framework by which a smartphone or other device can act as a vehicle key. The aim of standardisation is to allow a single credential format and exchange protocol to work across vehicle manufacturers and handset platforms, so that a phone from one vendor can be provisioned for a vehicle from another. Release 3 of the specification adds support for BLE with UWB secure ranging, and defines both the low-level exchange between phone and vehicle and the higher-level lifecycle of the key, including creation, sharing, suspension and revocation. The summary below describes the general architecture, and exact message formats and implementation details are defined in the specification and in manufacturer implementations.

Key pair generation and the secure element

The core security principle is that the secret credential never leaves protected hardware. The phone includes a secure element (SE), a tamper-resistant chip with its own processor, memory and cryptographic engines, or an equivalent isolated secure enclave. When a digital key is created, the SE generates an asymmetric key pair, typically on an elliptic curve such as NIST P-256. The private key is created inside the SE and is non-exportable: it can be used to sign data, but the key material cannot be read out by the operating system, by applications or by an attacker who has compromised the main processor. The corresponding public key is exported for registration with the vehicle. The same principle applies on the vehicle side, where the vehicle holds its own key pair and the public keys of the authorised devices within a secure component.

Provisioning, pairing and the signed token

Provisioning begins with the vehicle owner, who authenticates to the manufacturer's backend through an account. The backend, acting with the vehicle's identity and the phone vendor's cloud services, authorises the creation of the key and arranges the exchange of public keys and related metadata between the phone and the vehicle. For the first pairing, a secure channel is typically established, often with the owner physically present and using NFC or a similar short-range method to bootstrap trust, so that a remote attacker cannot insert a rogue key. The result is that the vehicle stores the phone's public key together with permissions, such as whether the key may unlock, start, or share, and any restrictions on time or features. Sharing a key with another person involves the owner's device or the manufacturer backend issuing a signed authorisation that allows a second device to generate its own key pair and register it with the vehicle under limited permissions.

At the time of use, authentication follows a challenge-response sequence. After establishing a BLE connection and, where required, an encrypted session derived from a key exchange, the vehicle and the phone perform mutual authentication. The vehicle sends a fresh random challenge, the phone's SE signs the challenge, together with session data, using its private key, and the vehicle verifies the signature against the stored public key. Because the challenge is random and used once, a recorded response cannot be replayed. Fast transactions use a session or ephemeral key derived during an earlier exchange, so that a subsequent connection can be authenticated quickly without repeating the full public-key protocol, a design feature that reduces latency at the door. When UWB ranging is involved, the exchange also generates the keying material for the secure timestamp sequence mentioned earlier, so that the physical-layer distance measurement is cryptographically bound to the authenticated session. The signed token authorises the action, and the ranging proves the proximity.

Where the vehicle-side trust anchor sits

On the vehicle, the logic that verifies keys and authorises actions must be isolated from less trusted systems. Depending on the vehicle architecture, this function may reside in the body control module, a dedicated access controller or a gateway that also supports telematics, and it commonly relies on a hardware security module or secure element for key storage and cryptographic operations. The telematics control unit (TCU) plays a distinct role as the vehicle's connection to the manufacturer's cloud, through which remote key creation, sharing and revocation commands are delivered. The security of the whole system therefore depends on the integrity of the pathway from the manufacturer backend through the TCU to the access controller, as well as on the radio exchange at the door. Specifiers should assess how securely these components are segregated, whether commands arriving through the TCU are authenticated end-to-end, and how revocation is propagated if the vehicle is offline.

Residual risks in the tokenisation model

Strong cryptography does not remove every risk. The most credible attacks against well-implemented systems target the surrounding processes: account takeover at the manufacturer backend, social engineering of the provisioning flow, and weaknesses in the protocol implementation, as opposed to the underlying primitives. A stolen phone with an unlocked screen, or a device whose biometric protection is weak, may retain an active key. In some implementations, express modes allow transactions without user authentication, trading security for convenience, and operators may choose to restrict this. Fleet managers should maintain procedures for rapid key revocation, require device-level authentication and keep records of which devices hold active keys for which vehicles.

End-of-life and zero-power fallback

What happens when the phone is dead

The most distinctive failure mode of a phone key is total battery depletion. A key fob with a failing coin cell typically gives warning, since range diminishes gradually, and it can usually be bypassed by holding the fob against a designated spot in the cabin, where the vehicle's immobiliser reads a passive transponder. A phone with a flat battery is entirely inert, and the vehicle cannot detect its presence by any radio means. The user is locked out of both the vehicle and, potentially, the means of calling for help. In response, the specifications and vehicle designs provide fallbacks, and their capabilities and limitations should be understood before a fleet relies on a phone key as its sole credential.

Some handsets support a power-reserve function that allows limited transactions, including some NFC and digital key uses, for a few hours after the device has otherwise shut down due to low battery. This depends on the model, the operating system version and the key provisioning, and it cannot be assumed to be available. When it is available, it relies on the NFC controller and secure element drawing a small amount of energy from the residual battery capacity or from the field itself. Handsets without such a feature offer no fallback at all, and for those the only recourse is a backup credential.

Passive NFC coupling and the B-pillar antenna

NFC operates at 13.56 MHz through inductive coupling between two loop antennas, in the manner of a transformer with a very loose coupling coefficient. The reader, in this case the vehicle, generates an alternating magnetic field, and a passive tag or card in the field harvests enough energy from it to power its chip and respond by modulating the load on the field. The usable range is only a few centimetres, since the magnetic field strength of a small loop falls rapidly with distance, roughly as the cube of the distance in the near field, and the coupling depends on the alignment and relative size of the two antennas. Vehicles typically place the NFC reader antenna in a defined location, commonly at or near the door handle or the B-pillar, and a second reader in the cabin, often in the centre console, for start authorisation.

The physical constraints of this arrangement are substantial. The user must know where the reader is and must place the phone's NFC antenna, which is in a position that differs between handsets, within a few centimetres of it, at the right orientation. Metallic phone cases, wallet cards behind the phone or battery-pack accessories can shield or detune the antenna and prevent coupling. The reader's field strength and the chassis metalwork also influence the coupling, and an antenna on a painted metal or composite pillar may behave differently in rain, cold or after damage. Because this is a passive path, authentication in a card-based mode may rely on a credential stored on a card with no battery, and in handset-based reserve modes the key must be stored in the secure element accessible when the main processor is off. The cryptographic strength is retained, but the interaction is deliberately slower and more deliberate, and it is not a hands-free experience.

Behavioural effects and fleet vulnerability vectors

The availability of fallbacks changes how drivers behave. Users who experience a single lockout often start carrying a physical card or fob, or they refuse to rely on the phone at all. Others stop adopting low-power modes on their handset for fear of a dead battery, or carry chargers. In fleet settings, the effects are more significant. A shared vehicle whose key relies on a driver's personal phone depends on the driver's discipline in keeping the phone charged, and a depleted battery can strand a vehicle and a delivery schedule together. Fleet managers should consider the cost of a lockout in terms of lost operating time, and compare it with the reliability of a dedicated fob stored in a secure key cabinet.

The fallbacks also change the threat model. A physical backup card or fob is itself a credential that can be lost, copied or stolen, and it may be stored in the vehicle's glovebox or a key safe, reintroducing a physical theft vector that the digital key was intended to reduce. Sharing a key remotely creates additional paths: a compromised manufacturer account or a poorly managed fleet portal can grant access to an attacker who never touches the vehicle. The fleet's vulnerability surface therefore shifts from the loss of physical objects to the compromise of accounts, devices and backend systems. Security directors should consider that this shift reduces some risks, such as relay theft against fobs, while introducing others, such as large-scale credential abuse through administrative compromise. Both types of risk are manageable, but they require different controls.

Comparative matrix: access topologies, ranging and fallback

The matrix below consolidates the engineering contrasts discussed above. Values are representative and are intended to characterise the categories. Actual performance varies with vehicle implementation, handset model, operating system version and environmental conditions, and the characterisation of relay vulnerability reflects the physical-layer capability and not a guarantee about any given vehicle.

The matrix shows that the security and the dependability of an access system do not move together. The CCC UWB key is the strongest of the phone-based options against relay theft, because the physical layer enforces distance, but it retains the highest dependence on a general-purpose operating system that the fleet does not control. The dedicated fob is weaker in some respects, especially the legacy variants, but its dependency chain is short and its behaviour is predictable. The UWB-enabled fob combines the advantages of both and is, in engineering terms, the benchmark against which the phone key should be measured.

Specification and fleet policy recommendations

The audit leads to practical recommendations for each of the audiences addressed. They are intended as a starting point for specification and policy, and they should be validated against the particular vehicles and handsets in service.

• Require UWB secure ranging for any keyless entry that permits start. Where a vehicle supports it, enforce UWB distance bounding for unlock and start authorisation, and avoid configurations that fall back silently to RSSI-based decisions. Treat the fallback behaviour as a security-critical design parameter.
• Prefer system-integrated credentials over background applications. A key managed by the operating system's wallet framework is subject to fewer background-execution failures than a standalone app. Where a manufacturer app is unavoidable, document the required battery and background settings for each supported handset.
• Define and measure an access time budget. Set a service-level objective for the time from approach to authenticated unlock, and test it across handset models, operating system versions, battery levels and power-saving modes. Track field failure rates and treat intermittent delays as defects.
• Mandate a zero-power fallback. Do not rely on a phone key as the only credential. Issue a backup NFC card or retain a physical fob under controlled custody, and verify that drivers know the location of the vehicle's NFC reader and the handset's antenna position.
• Control the credential lifecycle. Maintain a register of devices holding active keys, enforce device-level authentication, restrict express modes where the risk justifies it, and rehearse rapid revocation for lost devices or departing drivers.
• Secure the backend and telematics path. Because remote sharing and revocation traverse the manufacturer cloud and the telematics control unit, assess the authentication of those commands, the segregation of the access controller and the behaviour of the vehicle when offline.
• Segment by use case. Use phone keys where their benefits, such as remote sharing and convenience, are greatest and where a lockout is cheap, and retain dedicated fobs for vehicles with strict availability requirements, such as emergency, delivery or high-utilisation fleets.

Where the evidence is thin

Several uncertainties limit confident generalisation. Public, independent, large-sample data on real-world phone key failure rates are limited, and most of the evidence is anecdotal or derived from manufacturer statements. The behaviour of operating system power policies changes with every major release, so conclusions drawn about a particular handset and software version may not hold after an update. The proportion of vehicles that actually enforce UWB ranging, as opposed to supporting it as an optional feature, is not consistently documented. And while the relay attack against legacy fobs has been repeatedly demonstrated, the practical exploitation of well-implemented UWB systems has not been established in the public record, which is consistent with the physical argument but is not proof of invulnerability. Procurement teams should request test data and implementation details from manufacturers, and should conduct their own pilot trials before committing a fleet to a single access method.

Conclusion: security gains, dependability costs

The smartphone digital key has closed much of the security gap that once separated it from the dedicated fob. UWB impulse-radio ranging replaces a spoofable signal-strength estimate with an authenticated nanosecond-level measurement of distance, secure elements keep private keys beyond the reach of the operating system, and the CCC framework standardises provisioning, sharing and revocation across vendors. In cryptographic and physical-layer terms, the best phone keys are at least as strong as a conventional fob and considerably stronger than legacy passive entry systems.

The remaining weakness is not cryptographic but operational. A phone is a general-purpose device whose operating system freely suspends background processes, whose battery is routinely drained and whose software changes on a schedule that the vehicle owner does not control. Those properties introduce latency, intermittency and a hard failure mode when the battery is exhausted, and the NFC fallback, while physically sound, is slow, position-sensitive and dependent on handset support. For connected-car software specifiers, security directors and fleet mobility managers, the sound approach is to treat the phone key as a high-capability convenience and sharing layer, to demand secure ranging and a tested fallback, and to retain a deterministic, dedicated credential wherever the cost of a failed entry is high. The question is not whether the phone can be a secure key, but whether it can be a dependable one, and the evidence indicates that it can be both only when the surrounding system is engineered and managed accordingly.