Digital key and phone-as-key

Walking up to a car with a phone in your pocket and having the door unlock is a genuinely good feature. It is also a security problem with unusually severe consequences, and the architecture is shaped almost entirely by that.

The problem being solved#

A physical key fob works by proximity: it is either near the car or it is not. Replacing it with a phone means proving two things:

1. This phone holds a genuine key for this vehicle.
2. The phone is physically near the car, not being relayed from a distance.

How proximity is actually established#

Where Android sits: outside#

What Android does do#

Android owns the management experience, which is substantial:

• Showing which keys exist and which devices hold them
• Starting the pairing flow for a new device
• Sharing a key with a family member, with an expiry
• Revoking a key when a phone is lost or a car is sold
• Showing recent access history

// A vendor interface to the security module. Note what is absent:
// there is no unlock() here, because Android does not unlock anything.
interface IDigitalKeyManager {
    List<KeyRecord> listKeys()
    PairingSession beginPairing(DeviceType type)
    void revokeKey(String keyId)
    void shareKey(String keyId, ShareConstraints constraints)
}

Sharing is where the interesting requirements are#

Sharing a key sounds simple and is not:

Time-bounded. A key lent to a valet should expire in two hours.

Capability-bounded. A key that can unlock and drive is different from one that can only unlock the boot for a delivery.

Revocable while offline. This is the hard one. If the vehicle has no network connection for two weeks and a shared key is revoked, the revocation must still take effect. That usually means keys carry an expiry the vehicle can evaluate locally, rather than relying on the vehicle asking a server.

The failure case that must always work#

Privacy#

Key usage is a movement log. Every unlock is a record of someone arriving somewhere at a time.

The rules from the telemetry and location topics apply directly:

• Retain access history for a bounded period, and say what it is.
• Do not correlate key usage with location unless there is a specific consent for a specific purpose.
• On a shared vehicle, be careful whose history is visible to whom. A family member's arrival times are their data, not the owner's.

What to check in a design#

• Does Android have any path to authorise an unlock? It should not.
• Is the key in secure hardware on both ends?
• Does proximity rely on ranging, or only on signal strength?
• Do shared keys expire locally, without needing a network?
• Is there a non-phone fallback?
• Is access history bounded and scoped to the right user?

Next#

The other way a phone reaches into the car.