![](https://help.apple.com/assets/6537FB06A074DBB5E802EA07/6537FB31280588A5490B6E1D/en_AU/52d714626638d3391623c853be0c593b.png)
Car key security in iOS
Developers can support secure keyless ways to access a vehicle in a supported iPhone and paired Apple Watch.
Owner pairing
The owner must prove possession of the vehicle (the method is dependent on the automaker) and can start the pairing process in the automaker’s app using an email link received from the automaker or from the vehicle menu. In all cases, the owner must present a confidential one-time pairing password to the iPhone, which is used to generate a secure pairing channel using the SPAKE2+ protocol with the NIST P-256 curve. When using the app or the email link, the password is automatically transferred to the iPhone, where it must be entered manually when pairing is started from the vehicle.
Key sharing
The owner’s paired iPhone can share keys to eligible family members’ and friends’ iPhone devices (and their paired Apple Watch devices) by sending a device-specific invitation using iMessage and the Apple Identity Service (IDS). All sharing commands are exchanged using the end-to-end encrypted IDS feature. The owner’s paired iPhone keeps the IDS channel from changing during the sharing process to protect against invitation forwarding.
Upon acceptance of the invitation, the family member’s or friend’s iPhone creates a digital key and sends the key creation certificate chain back to the owner’s paired iPhone to verify that the key was created on an authentic Apple device. The owner’s paired iPhone signs the ECC-public key of the other family member’s or friend’s iPhone and sends the signature back to the family member’s or friend’s iPhone. The signing operation in the owner device requires user authentication (Face ID, Touch ID or passcode entry) and a secure user intent described in Uses for Face ID and Touch ID. The authorisation is requested when sending the invitation and is stored in the secure element for consumption when the friend device sends back the signing request. The key entitlements are provided to the vehicle either online by the vehicle OEM server or during the first use of the shared key on the vehicle.
Key deletion
Keys can be deleted on the keyholder device from the owner device and in the vehicle. Deletions on the keyholder iPhone are effective immediately, even if the keyholder is using the key. Therefore, a strong warning is shown before the deletion. Deletion of keys in the vehicle may be possible anytime or only be possible when the vehicle is online.
In both cases, the deletion on keyholder device or vehicle is reported to a key inventory server (KIS) on the automaker side, which registers issued keys for a vehicle for insurance purposes.
The owner can request a deletion from the back of the owner pass. The request is first sent to the automaker for key removal in the vehicle. The conditions for removing the key from the vehicle are defined by the automaker. Only when the key is removed in the vehicle will the automaker server send a remote termination request to the keyholder device.
When a key is terminated in a device, the applet that manages the digital car keys creates a cryptographically signed termination attestation, which is used as proof of deletion by the automaker and used to remove the key from the KIS.
NFC standard transactions
For vehicles using an NFC key, a secure channel between the reader and an iPhone is initiated by generating ephemeral key pairs on the reader and the iPhone side. Using a key agreement method, a shared secret can be derived on both sides and used for generation of a shared symmetric key using Diffie-Hellman, a key derivation function 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 reader 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.
Finally, the iPhone uses the established 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 reader allows the reader to authenticate the device.
Fast transactions
The iPhone generates a cryptogram based on a secret previously shared during a standard transaction. This cryptogram allows the vehicle to quickly authenticate the device in performance sensitive scenarios. Optionally, a 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.
BLE/UWB standard transactions
For vehicles using a 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 on the vehicle to enable accurate localisation 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 TTL. To avoid interruption of ranging when a TTL expires, URSKs can be pre-derived in the device SE and the vehicle HSM/SE while secure ranging isn’t active but BLE 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.
Privacy
The automaker’s key inventory server (KIS) doesn’t store the device ID, SEID or Apple ID. It stores only a mutable identifier — the instance CA identifier. This identifier isn’t bound to any private data in the device or by the server and it’s deleted when the user wipes their device completely (using Erase All Contents and Settings).