Car key security in iOS

Owner pairing

The owner must prove possession of the vehicle (the method is dependent on the automaker, often they have to bring one or two key fobs) and can start the pairing process in the automaker’s app, by 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 to create an Global Platform SCP03 secure channel to transfer data between the device and the vehicle. When using the app or the email link, the password is automatically transferred to the iPhone, where it needs to be entered manually when pairing is started from the vehicle.

In the owner pairing process, the vehicle sends a request through the SCP03 channel instructing the device’s Secure Element to generate an Elliptic Curve Cryptography (ECC) key pair. The vehicle identifier and the vehicle public key are then securely bound to this key pair. The device public key (device.PK) is sent back to the vehicle in an X.509 certificate format together with a certificate chain that’s verifiable with the automaker root certificate public key (root.PK), which is embedded in the vehicle at production. This allows for verification and acceptance of the device public key as the owner key.

The owner key in the device Secure Element also securely binds the automaker root.PK, which is provided by the vehicle through the SCP03 channel, to the device.PK for key sharing.

If required for insurance purposes, each owner’s key needs to be registered with the automaker’s server. The device sends its device.PK certificate chain to the key tracking server (KTS) which sends back a signature to confirm the registration. The device provides the signature to the vehicle at the end of the owner pairing process or at the next standard transaction with the vehicle (see below), and the vehicle enables the owner key if the KTS signature has been successfully verified. The KTS signature keys are proprietary to the automaker.

Key sharing

The sender’s iPhone can share keys to eligible devices by sending an invitation URL to the recipient through any communication channel for example email, iMessage, WhatsApp, WeChat or AirDrop. The URL directs the receiver to a privacy-protected mailbox on a relay server which is implemented based on an IETF specification. The privacy encryption key is sent as a fragment in the sharing URL.

During this process, the sender’s iPhone requests a user authentication (Face ID, Touch ID, or passcode entry) and a secure user intent described in Uses for Optic ID, Face ID, and Touch ID. The sender authorization is stored temporarily in the Secure Element for consumption later when the recipient device returns the signing request.

For added security, to activate the shared key, the sender may require recipient to use one of the available activation options supported by their automaker or passcode entered on recipient device.

Upon acceptance of the invitation, the recipient’s device retrieves key creation data from the relay server mailbox and creates a digital key according to the CCC Digital Key Specification. As a part of key creation process, the key is signed by the sender. The recipient device sends the key creation certificate chain back using the relay server to the sender’s iPhone. The sender’s iPhone then uses the root.PK embedded in the Secure Element to verify that the recipient key was created using the expected certificate chain. If successful, the sender’s iPhone signs the ECC-public key of the recipient device and sends the signature back to the recipient using the relay server. The signature is authorized by consuming the sender authorization previously stored in the Secure Element.

The key entitlements and the sender signature are provided to the vehicle during the first use of the shared key on the vehicle (see Standard transactions). Entitlements describe the following:

• Access level: For example, unlock or drive.

• Resharing policy: For example, no resharing, limited resharing, or unlimited resharing (in terms of sharing chain length).

Some automakers require each shared key to be registered with the automaker’s server. If required, the recipient device sends its device.PK certificate chain to the automaker’s KTS which returns a signature to confirm the registration. The recipient device presents that signature to the vehicle in the first transaction with the vehicle (see Standard transactions). The vehicle validates the signature and—if the KTS signature has been successfully verified—enables the shared key. These signature keys are proprietary to the automaker.

Key deletion

Keys can be deleted the following ways:

• On the keyholder device

• From the owner’s device

• From a sharer device with the proper authorizations

• While inside the vehicle

Deletions on the keyholder iPhone are effective immediately, even if the keyholder is using the key or if the device isn’t connected to the internet.

Deletion of keys in the vehicle might be possible, at discretion of the automaker policy:

• Anytime

• Only when the vehicle is online

• Only when a key fob is present (to avoid being stranded without key)

In each case, the deletion on keyholder device or vehicle is reported to the KTS on the automaker side, which registers issued keys to a vehicle for insurance purposes.

The owner and eligible users can request a deletion using a remote termination request signed by the requester’s private key (device.SK) by selecting the users in the shared keyholder accounts list on the back of their car key pass in Apple Wallet. 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 (as listed above). Only when the key is removed from the vehicle will the automaker server send a signed 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.

Privacy

The automaker’s KTS doesn’t store the device ID, SEID, or Apple Account. 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 initiates an Erase All Contents and Settings.

The CCC standard also mandates that the KTS information is kept confidential on the automaker side and is only used in case of insurance or other eligible requests.

Key registration data (key identifier, vehicle identifier, vehicle public key, device public key certificate chain, key entitlements) that’s sent by the device to the KTS is encrypted against a KTS privacy encryption public key. Apple servers transmitting the key registration data from the device to the automaker server aren’t able to decrypt this data. Apple doesn’t know who the owner shared keys for their vehicle with.

Any other accessory to iPhone or Apple Watch which isn’t able to authenticate to the device is unable to receive a stable identifier through a standard or fast transaction over NFC or Bluetooth. If the device doesn’t recognize the vehicle identifier (for example, attempting by mistake to access a vehicle that looks similar to the keyholder’s vehicle) then the applet in the Secure Element uses a substitute key that generates random values instead of meaningful keys or cryptograms.

The initial Bluetooth connection is protected by the use of temporary keys that are provided when sharing the car key or by the automaker in the response to the key tracking request.