Introducing Car Keys

Hello and welcome to WWDC.

Hello, I'm Matthias Lerch, and today I'm so excited to talk about the digital version of car keys now available in iOS. With car keys, people can unlock, lock, and start their car using iPhone and Apple Watch.

Keys are stored securely on their personal Apple device, and you can delete them via iCloud.

And because they're digital, it's easy to share keys with friends or manage them remotely.

It can work with different radio technologies. This week we introduce support for NFC. In the future, Ultra Wideband technology will provide even more convenience.

The car key system is designed to work without a network connection.

And after a long day of hiking, people can still get into their car and drive home because the feature works with power reserve.

This session is geared towards automakers interested in supporting digital car keys. To work with this system, your car needs to support owner pairing, transactions and server interfaces.

Owner pairing is the first step and is required to set up a digital car key on iPhone. Owner pairing establishes a privileged and secure association between the owner's iPhone and the car using a short-range radio channel such as NFC. First, the user must prove that they own the car. The requirements here are defined by you, the automaker.

Next, they initiate pairing. The easiest way is to use an automaker app that you provide. For new cars, you can also send a welcome e-mail containing a link to start pairing.

When the car is ready, the user places iPhone onto the car's NFC reader in the dashboard. As a fallback, you should also provide an option to start owner pairing from within the car. In this case, placing iPhone onto the car's NFC reader allows them to manually enter a pairing pass code.

The pairing process runs for a few seconds, then the car key appears in Wallet, ready to use.

Next, transactions. Transactions are the heart of the car key system. Transactions are used to unlock or lock the car and to authorize engine start.

Cars must provide at least one NFC reader in the door handle and one in the dashboard.

Simply place iPhone near the door handle to unlock or lock the door. Of course, the pass will be customized to match your car brand and will look great.

And in the car, place the device on the tray reader in the dashboard to authorize engine start. Transactions are optimized for security and performance to ensure a smooth user experience.

Express Mode lets the feature work without Face ID or a pass code. It's turned on by default, but users who want additional security can turn it off. In this case, user authentication is required for each relevant transaction.

All transactions work fully off-line. You don't need a network connection to drive your car.

And because transaction information is not sent, Apple doesn't know when you use your car.

Some feature, such as key sharing and key management do require a server connection.

Key sharing works with Messages on iPhone.

The car doesn't need to be online when sharing, and private information is encrypted. So when the owner shares a key with family members or friends, Apple doesn't know any of it.

As the automaker, you can provide different access levels for shared keys.

In this example, the car supports two access levels for each key.

"Unlock and Drive" is unrestricted. "Access and Drive Restricted" limits the car speed to 65 miles per hour. Again, it's up to each automaker to define access levels. Users can mange all keys on iPhone. Owners can remove their own key or revoke shared keys, and the car can provide similar functionality too. Keys removed from a device stop working immediately, even if the device is off-line. Family and friends can only manage their own keys.

iCloud lost mode and remote card deletion are fully supported. And device upgrades are simple. When the owner buys a new iPhone, all they have to do is to pair their new device with the car. The key on their old iPhone is removed, shared keys continue to work, and everything is automatically transferred to the new iPhone. Now that we've introduced the feature, let's look under the hood and examine the system architecture, radio technologies, server integration and automaker apps.

Let's start by looking at the system architecture.

The core features, pairing, sharing and revocation are supported natively on iOS. Automaker apps are not required, even when you share your keys with friends.

Cryptographic keys are generated in the Secure Element on the device and are never exported.

All features use standard AES and elliptic-curve algorithms for higher security and easy adoption on any platform.

The system is based on Public Key Infrastructure for off-line use.

And for simple server integration, a Trusted Service Manager is not required.

Let's take a closer look at this new digital car key.

Our goal was to bind keys to the user's device, and not to Apple or the automaker. Therefore, an elliptic-curve key pair is created in the Secure Element on the iPhone.

The private key always stays in the Secure Element. The public key is exported in an X.509 certificate for authenticity verification.

An applet in the Secure Element implements the car key.

The applet stores the key pair and binds it to the car. It implements transactions and manages secure mailboxes which store key attestations and security tokens the prevent a revoked car key from being reactivated. Mailboxes also support immobilizer tokens for compatibility with existing car architectures.

For memory efficiency, all car keys are hosted in a single applet instance.

A typical car key system has some standard components. Of course, we have iPhone and the car. They communicate directly via NFC. iPhone and the car each have associated back-end systems. The back-end systems are connected, and there are times when the automaker app needs to communicate with its server. Let's use owner pairing as an example and see how these components work together.

The automaker server generates a verifier which is provisioned into the car at production or over a telematics link.

A matching pairing password is made available to the owner via an automaker app.

With the pairing password and the verifier, we can create a secure channel for the pairing transaction. We have chosen an elliptic-curve based PAKE protocol with augmented security and low memory requirements on car side. At first, the vehicle sends its identity certificates to the device.

The owner iPhone creates the owner key in the car key applet after successful certificate verification. It then returns the identity certificates of the new key back to the car for acceptance. From now on, car and device are cryptographically linked together.

To register the key, the owner iPhone sends encrypted data to the automaker server and receives a confirmation attestation. Then the Apple server activates the key in the device and loads the pass into Wallet.

To enable the key on car side, the device provides the confirmation attestation to the car over NFC during the owner pairing transactions. If the device was off-line during the owner pairing, the attestation can also be provided later during the first usage of the key.

Once iPhone is paired with the car, transactions occur fully off-line. No information needs to be provided to the servers.

Next, I'd like to walk you through key sharing.

With key sharing, there are two devices: the owner iPhone and friend iPhone. The owner starts by sending an invitation using Messages. The invitation specifies the key configuration, such as the access level and car identity.

The friend iPhone creates a new car key based on the invitation. Then it sends the new key's identity certificate chain back to the owner via the Apple Identity Service, IDS. This is not visible to the user.

The owner device verifies the certificate-- We'll see in a minute how that works-- and issues a signed confirmation attestation. Similar to owner pairing, the confirmation attestation allows the car to accept the friend key.

The owner iPhone sends the attestation back to the friend via IDS. This is also not visible to the user.

If the car is off-line, the friends presents the registered confirmation attestation during their first transaction using their phone with the car. They can now unlock and drive the car.

Note that if the car is online, the attestation can also be transmitted to the car during key registration.

Before we dive into the cryptography of pairing, sharing and transactions, let's review the complete life cycle of a car key.

A car key is created through owner pairing or key sharing. Transactions lock and unlock the car, authorize engine start, and exchange encrypted data with the car.

iCloud Lost Mode temporarily suspends car keys on iPhone or Apple Watch by locking the car key applet on the Secure Element.

The owner can revoke shared car keys from their device or from the car UI.

And, of course, every key holder can delete the car key on their device at any time.

Certificates are the backbone of car key life cycle management, so it's worth having a deeper look to see how they work. Let's start with the car certificate embedded in the car and the owner's key certificate created on iPhone during owner pairing.

The automaker can issue car certificates from a regional or brand-specific CA, which is represented by an optional intermediate certificate. All intermediate certificates should be trusted by a single root certificate for an automaker.

The public key of this root certificate is embedded in the owner key during the owner pairing process. The automaker public key is required for key sharing, as we'll see in a minute.

Each owner key is trusted by an instance CA located on the Secure Element. We create one instance CA per automaker. Note that the subject name of the instance CA links the automaker app to all car keys for this automaker.

The device is registered with the automaker using the instance CA identifier. When the owner signs out of iCloud or erases their device, the instance CA is deleted, and the automaker is no longer able to identify the device. This protects user privacy.

The instance CA is trusted by the Apple root certificate. For each automaker, Apple will provide the root certificate in a trusted way.

The automaker creates the external CA certificate. This certificate contains the Apple root key and is signed by the automaker.

The owner key is now trusted by the automaker root. The car is not required to carry Apple's root certificate. The automaker root certificate is sufficient to verify the authenticity of a car key in a device.

The same certificates allow sharing between secure elements. The owner's iPhone sends an invitation with a template for the friend's device to create a key.

The friend's key is trusted by the friend's instance CA. The external CA connects the device chain of trust to the automaker root.

As you remember, the owner key embeds the automaker root since it was provided by the car at owner pairing.

The owner is now able to verify the authenticity of a friend key. Now let's look into transactions.

Fast and standard transaction are variants of the same flow. The flow is designed to adapt seamlessly to any situation. The standard transaction is used to start the engine. It also creates the keys for the fast transaction.

We recommend to use the fast transaction to unlock a car.

When a friend key is used for the first time, the door handle extends the fast transaction to a standard transaction and adds an exchange command to read the friend key attestation from the mailbox. Let's see how that works in detail.

When a key is used for the first time, the car executes a standard transaction on the door handle reader. For this, the car sends its unique identifier and an ephemeral key to the device. The car identifier is created by you, the automaker, to extract the real car identity, such as the VIN. The device responds with an ephemeral key. For privacy protection, the device does not send an identifier.

To provide information about the new key, the device must authenticate the car first.

The symmetric keys for future fast transactions on the door handle will now be calculated by the device. The device then sends its encrypted key identifier and its signature to the car. At this moment of the standard transaction, the car would normally authenticate the device and start the engine. But as this is the first transaction with an unknown key, the car checks if an attestation package is present in the car key mailbox. If there's no friend attestation, then the user has most likely tapped the device to the wrong car. But if there is a friend key attestation, then it is a new friend key that the car doesn't know yet.

The car will obtain the friend's public key, access level, and the owner signature from the attestation. On successful validation, the car stores all those elements and unlocks the door. Let's summarize the security properties of transactions.

In the fast transaction, the car authenticates the device.

Device tracking is not possible due to the absence of any device identifier.

All exchanged sensitive data are encrypted.

The standard transaction adds mutual authentication between car and device. To protect the device against tracking, device identifiers are sent encrypted only to a known car.

Forward secrecy protects transaction data against future compromise. Now that we've reviewed the system architecture, let's talk about the radio technologies used to communicate between iPhone and the car.

NFC operates with a standard reader in the door handle and inside the car.

In addition, Apple's Enhanced Contactless Protocol, or ECP, enables a truly magical experience. Whether you approach an NFC reader on the car or a payment terminal, we'll automatically use the matching path from Wallet.

ECP works by identifying the reader type and the make of the car before a transaction even starts.

And fast and efficient reader polling enables a good user experience.

In the future, Ultra Wideband technology will enable a truly passive entry system by providing secure ranging.

Simply unlock and start your car while iPhone stays in your bag or pocket. And because the car key system is radio agnostic, everything we covered about key management remains the same.

The specification is currently in draft form and will be available soon.

Okay, let's move on to talk about server integration. Although car keys work off-line, servers are required for remote key management.

First, your automaker server needs to establish a reliable and secure connection to Apple's back end. This needs to be done for each server environment, such as testing and production.

Apple will provide our car key root certificate to you, the automaker, for cross-signing. You send us back your external CA certificate, root certificate, and certificate for privacy encryption and signature verification. One set of certificates is required for each server environment.

We have defined a small set of server interfaces that need to be implemented and tested. They allow you to register a new key, remotely revoke keys, and send important device notifications.

Passes represent your car keys in Wallet, provide logo and background artwork to match your company brand. We supply a template and a portal to make this easy for you. Wallet passes are created automatically, so you don't need to write code here. Finally, your automaker app needs to retrieve the owner pairing password from your back end. If you support deletion of keys in your app, you will need to send the termination request via your server.

Let's talk more about automaker apps.

With automaker apps, you can provide custom features using keys stored in Wallet. Your automaker app is also a great way to start owner pairing. The APIs are available to automakers only and require an app entitlement. For more information, see the PassKit documentation. There are many details we didn't cover today, including communication protocols, hardware features and more.

If you're an automaker and want to learn more, your first step is to enroll in the Car Connectivity Consortium, or CCC, and get the digital key specification. The CCC is a cross-industry organization that deals with phone-to-car technologies including standards for digital keys.

The NFC feature we discussed today corresponds to version 2.0. The upcoming version 3.0 supports Ultra Wideband for passive entry.

The CCC includes 26 automakers, representing even more brands and over 80 suppliers and technology partners. You'll also need details on supporting iPhone and Apple Watch, transaction and system performance goals, and integrating with Apple servers. This will be provided through the Apple MFi program. If you are not already enrolled in the MFi program, go to the "Contact us" form to express your interest in the car key feature. We are really excited about digital keys and letting people leave their physical car keys at home. We look forward to seeing this in your cars soon. Thank you for watching.