Car key transactions
Car key can use various types of transactions.
Fast transactions
The fast transaction is used only to unlock the vehicle over NFC.
The iPhone generates an AES-128 cryptogram based on a secret previously generated on both sides during a standard transaction. This cryptogram allows the vehicle to quickly authenticate the device in performance sensitive scenarios as only symmetric cryptography is used and only one transfer between the NFC reader and the processing Electronic Control Unit (ECU) is required. If the vehicle requires read or write access to either the private mailbox, the confidential mailbox, or both (each car key in the Secure Element has its pair of mailboxes), a Global Platform SCP03 secure channel between the vehicle and the device is established by deriving session keys from a secret previously shared during a standard transaction and a new ephemeral key pair. The ability of the vehicle to establish the secure channel authenticates the vehicle to the iPhone. If the vehicle stores keys for multiple devices it must use a “try and error” method with a “most used first” scheme to find the right symmetric key as the device doesn’t give out a trackable identifier in the fast transaction where the vehicle isn’t authenticated by the device.
If no symmetric keys have been established for the transacting device, the vehicle uses the ephemeral vehicle public key (vehicle.PK) to continue with a standard transaction (see Standard transactions below.
Standard transactions
The standard transaction is used to unlock the vehicle over NFC if no symmetric keys for a fast transaction are established through a prior standard transaction or when a newly shared key transacts with the vehicle for the first time (first friend key transaction, FFT). It’s always used to authorize driving.
The vehicle initiates a secure channel between the vehicle and an iPhone by generating ephemeral ECC key pairs on the reader and the iPhone side. Using a ECKA-DH key agreement method, a shared secret can be derived on both sides and used for generation of a shared symmetric key for the fast transaction using Diffie-Hellman, a HKDF key derivation function (RFC 5869), and signatures from the long-term key established during pairing.
The ephemeral public key generated on the vehicle side is signed with the reader’s long-term private key, which results in an authentication of the vehicle by the iPhone. From the iPhone perspective, this protocol is designed to prevent privacy-sensitive data from being revealed to an adversary intercepting the communication or impersonating a vehicle.
The iPhone uses the established, nonauthenticated secure channel to encrypt its public key identifier along with the signature computed on a reader’s data-derived challenge and some additional app-specific data. This verification of the iPhone signature by the vehicle allows the reader to authenticate the device.
The NFC standard transaction is also used for the first approach (FFT) of a newly shared key to the vehicle, as the vehicle doesn’t yet know the new device.PK). When the user approaches the door handle, the vehicle starts a fast transaction but wouldn’t be able to verify the cryptogram. It then continues with a standard transaction (the reader command for the fast transaction, AUTH0, is also the first command for the standard transaction), creates a GP SCP03 secure channel and reads the private mailbox content that should contain an attestation of the new device.PK, signed by the sharer (sharer.PK or owner.PK are already known to the vehicle) and signed by the KTS using automaker proprietary cryptography. After verification of the signatures the vehicle accepts the device.PK as a new key.
BLE/UWB standard transactions
For vehicles using a ultra-wideband-enabled (UWB) key, a Bluetooth LE session is established between the vehicle and the iPhone. Similar to the NFC transaction, a shared secret is derived on both sides and used for the establishment of a secure session. This session is used to subsequently derive and agree a UWB Ranging Secret Key (URSK). The URSK is provided to UWB radios in the user’s device and, in a vehicle OEM-proprietary secure channel, to UWB anchors.
Note: Anchors are generally placed on the four corners of a vehicle, inside, and optionally in the trunk of the vehicle to enable accurate and authenticated localization of the user’s device to a specific position near to or inside the vehicle. The vehicle then uses the device position to make decisions about allowing unlocking or starting of the vehicle.
URSKs have a predefined expiration time (time-to-live, or TTL). To avoid interruption of ranging when a TTL expires, URSKs can be prederived in the device Secure Element and the vehicle hardware security module (HSM)/Secure Element while secure ranging isn’t active but Bluetooth is connected. This avoids the need for a standard transaction to derive a new URSK in a time-critical situation. The prederived URSK can be transferred very quickly to the UWB radios of car and device to avoid interrupting the UWB ranging.