iCloud Keychain allows users to securely sync their passwords between iOS devices
and Mac computers without exposing that information to Apple. In addition to strong
privacy and security, other goals that heavily inﬂuenced the design and architecture of
iCloud Keychain were ease of use and the ability to recover a keychain. iCloud Keychain
consists of two services: keychain syncing and keychain recovery.
Apple designed iCloud Keychain and keychain recovery so that a user’s passwords are
still protected under the following conditions:
A user’s iCloud account is compromised.
iCloud is compromised by an external attacker or employee.
• Third-party access to user accounts.
When a user enables iCloud Keychain for the ﬁrst time, the device establishes a circle
of trust and creates a syncing identity for itself. A syncing identity consists of a private
key and a public key. The public key of the syncing identity is put in the circle, and the
circle is signed twice: ﬁrst by the private key of the syncing identity, then again with an
asymmetric elliptical key (using P256) derived from the user’s iCloud account password.
Also stored with the circle are the parameters (random salt and iterations) used to create
the key that is based on the user’s iCloud password.
The signed syncing circle is placed in the user’s iCloud key value storage area. It cannot
be read without knowing the user’s iCloud password, and cannot be modiﬁed validly
without having the private key of the syncing identity of its member.
When the user turns on iCloud Keychain on another device, the new device notices in
iCloud that the user has a previously established syncing circle that it is not a member
of. The device creates its syncing identity key pair, then creates an application ticket to
request membership in the circle. The ticket consists of the device’s public key of its
syncing identity, and the user is asked to authenticate with their iCloud password. The
elliptical key generation parameters are retrieved from iCloud and generate a key that
is used to sign the application ticket. Finally, the application ticket is placed in iCloud.
When the ﬁrst device sees that an application ticket has arrived, it displays a notice
for the user to acknowledge that a new device is asking to join the syncing circle. The
user enters their iCloud password, and the application ticket is veriﬁed as signed by a
matching private key. This establishes that the person who generated the request to
join the circle entered the user’s iCloud password at the time the request was made.
Upon the user’s approval to add the new device to the circle, the ﬁrst device adds the
public key of the new member to the syncing circle, signs it again with both its syncing
identity and the key derived from the user’s iCloud password. The new syncing circle is
placed in iCloud, where it is similarly signed by the new member of the circle.
There are now two members of the signing circle, and each member has the public
key of its peer. They now begin to exchange individual keychain items via iCloud key
value storage. If both circle members have the same item, the one with the most
recent modiﬁcation date will be synced. Items are skipped if the other member has
the item and the modiﬁcation dates are identical. Each item that is synced is encrypted
speciﬁcally for the device it is being sent to. It cannot be decrypted by other devices
or Apple. Additionally, the encrypted item is ephemeral in iCloud; it’s overwritten with
each new item that’s synced.
This process is repeated as new devices join the syncing circle. For example, when a
third device joins, the conﬁrmation appears on both of the other user’s devices. The
iOS Security—White Paper | May 2016
Safari integration with iCloud Keychain
Safari can automatically generate
cryptographically strong random strings
for website passwords, which are stored
in Keychain and synced to your other
devices. Keychain items are transferred
from device to device, traveling through
Apple servers, but are encrypted in such
a way that Apple and other devices
cannot read their contents.
user can approve the new member from either of those devices. As new peers are
added, each peer syncs with the new one to ensure that all members have the same
However, the entire keychain is not synced. Some items are device-speciﬁc, such
as VPN identities, and shouldn’t leave the device. Only items with the attribute
kSecAttrSynchronizable are synced. Apple has set this attribute for Safari
user data (including user names, passwords, and credit card numbers), as well as
Wi-Fi passwords and HomeKit encryption keys.
Additionally, by default, keychain items added by third-party apps do not sync.
Developers must set the kSecAttrSynchronizable when adding items to
Keychain recovery provides a way for users to optionally escrow their keychain with
Apple, without allowing Apple to read the passwords and other data it contains. Even
if the user has only a single device, keychain recovery provides a safety net against
data loss. This is particularly important when Safari is used to generate random, strong
passwords for web accounts, as the only record of those passwords is in the keychain.
A cornerstone of keychain recovery is secondary authentication and a secure escrow
service, created by Apple speciﬁcally to support this feature. The user’s keychain is
encrypted using a strong passcode, and the escrow service will provide a copy of the
keychain only if a strict set of conditions are met.
When iCloud Keychain is turned on, the user is asked to create an iCloud Security Code.
This code is required to recover an escrowed keychain. By default, the user is asked to
provide a simple four-digit value for the security code. However, users can also specify
their own, longer code, or let their devices create a cryptographically random code that
they can record and keep on their own.
Next, the iOS device exports a copy of the user’s keychain, encrypts it wrapped with
keys in an asymmetric keybag, and places it in the user’s iCloud key value storage area.
The keybag is wrapped with the user’s iCloud Security Code and the public key of
the HSM (hardware security module) cluster that will store the escrow record. This
becomes the user’s iCloud Escrow Record.
If the user decided to accept a cryptographically random security code, instead of
specifying their own or using a four-digit value, no escrow record is necessary. Instead,
the iCloud Security Code is used to wrap the random key directly.
In addition to establishing a security code, users must register a phone number. This
is used to provide a secondary level of authentication during keychain recovery. The
user will receive an SMS that must be replied to in order for the recovery to proceed.
iCloud provides a secure infrastructure for keychain escrow that ensures only authorized
users and devices can perform a recovery. Topographically positioned behind iCloud
are clusters of hardware security modules (HSM). These clusters guard the escrow
records. Each has a key that is used to encrypt the escrow records under their watch,
as described previously.
iOS Security—White Paper | May 2016
To recover a keychain, users must authenticate with their iCloud account and password
and respond to an SMS sent to their registered phone number. Once this is done, users
must enter their iCloud Security Code. The HSM cluster veriﬁes that a user knows their
iCloud Security Code using Secure Remote Password protocol (SRP); the code itself
is not sent to Apple. Each member of the cluster independently veriﬁes that the user
has not exceeded the maximum number of attempts that are allowed to retrieve their
record, as discussed below. If a majority agree, the cluster unwraps the escrow record
and sends it to the user’s device.
Next, the device uses the iCloud Security Code to unwrap the random key used to
encrypt the user’s keychain. With that key, the keychain—retrieved from iCloud key value
storage—is decrypted and restored onto the device. Only 10 attempts to authenticate
and retrieve an escrow record are allowed. After several failed attempts, the record is
locked and the user must call Apple Support to be granted more attempts. After the
10th failed attempt, the HSM cluster destroys the escrow record and the keychain is lost
forever. This provides protection against a brute-force attempt to retrieve the record, at
the expense of sacrificing the keychain data in response.
These policies are coded in the HSM ﬁrmware. The administrative access cards that
permit the ﬁrmware to be changed have been destroyed. Any attempt to alter the
ﬁrmware or access the private key will cause the HSM cluster to delete the private key.
Should this occur, the owners of all keychains protected by the cluster will receive a
message informing them that their escrow record has been lost. They can then choose
By simply talking naturally, users can enlist Siri to send messages, schedule meetings,
place phone calls, and more. Siri uses speech recognition, text-to-speech, and a client-
server model to respond to a broad range of requests. The tasks that Siri supports
have been designed to ensure that only the absolute minimal amount of personal
information is utilized and that it is fully protected.
When Siri is turned on, the device creates random identiﬁers for use with the voice
recognition and Siri servers. These identiﬁers are used only within Siri and are utilized
to improve the service. If Siri is subsequently turned oﬀ, the device will generate a new
random identiﬁer to be used if Siri is turned back on.
In order to facilitate Siri’s features, some of the user’s information from the device is
sent to the server. This includes information about the music library (song titles, artists,
and playlists), the names of Reminders lists, and names and relationships that are
deﬁned in Contacts. All communication with the server is over HTTPS.
When a Siri session is initiated, the user’s ﬁrst and last name (from Contacts), along with
a rough geographic location, is sent to the server. This is so Siri can respond with the
name or answer questions that only need an approximate location, such as those
about the weather.
If a more precise location is necessary, for example, to determine the location of nearby
movie theaters, the server asks the device to provide a more exact location. This is an
example of how, by default, information is sent to the server only when it’s strictly
necessary to process the user’s request. In any event, session information is discarded
after 10 minutes of inactivity.
iOS Security—White Paper | May 2016
When Siri is used from Apple Watch, the watch creates its own random unique identifier,
as described above. However, instead of sending the user’s information again, its requests
also send the Siri identifier of the paired iPhone to provide a reference to that information.
The recording of the user’s spoken words is sent to Apple’s voice recognition server.
If the task involves dictation only, the recognized text is sent back to the device.
Otherwise, Siri analyzes the text and, if necessary, combines it with information from the
profile associated with the device. For example, if the request is “send a message to my
mom,” the relationships and names that were uploaded from Contacts are utilized. The
command for the identified action is then sent back to the device to be carried out.
Many Siri functions are accomplished by the device under the direction of the server.
For example, if the user asks Siri to read an incoming message, the server simply tells
the device to speak the contents of its unread messages. The contents and sender of
the message are not sent to the server.
User voice recordings are saved for a six-month period so that the recognition system
can utilize them to better understand the user’s voice. After six months, another copy is
saved, without its identiﬁer, for use by Apple in improving and developing Siri for up to
two years. Additionally, some recordings that reference music, sports teams and players,
and businesses or points of interest are similarly saved for purposes of improving Siri.
Siri can also be invoked hands-free via voice activation. The voice trigger detection is
performed locally on the device. In this mode, Siri is activated only when the incoming
audio pattern sufficiently matches the acoustics of the specified trigger phrase. When the
trigger is detected, the corresponding audio including the subsequent Siri command is
sent to Apple’s voice recognition server for further processing, which follows the same
rules as other user voice recordings made through Siri.
takes advantage of technologies like iCloud, Bluetooth, and Wi-Fi to enable
users to continue an activity from one device to another, make and receive phone calls,
send and receive text messages, and share a cellular Internet connection.
With Handoﬀ, when a user’s Mac and iOS device are near each other, the user can
automatically pass whatever they’re working on from one device to the other. Handoﬀ
lets the user switch devices and instantly continue working.
When a user signs in to iCloud on a second Handoﬀ capable device, the two devices
establish a Bluetooth Low Energy 4.0 pairing out-of-band using the Apple Push
Notiﬁcation service (APNs). The individual messages are encrypted in a similar fashion
to iMessage. Once the devices are paired, each will generate a symmetric 256-bit
AES key that gets stored in the device’s keychain. This key is used to encrypt and
authenticate the Bluetooth Low Energy advertisements that communicate the device’s
current activity to other iCloud paired devices using AES-256 in GCM mode, with replay
protection measures. The ﬁrst time a device receives an advertisement from a new
key, it will establish a Bluetooth Low Energy connection to the originating device and
perform an advertisement encryption key exchange. This connection is secured using
standard Bluetooth Low Energy 4.0 encryption as well as encryption of the individual
messages, which is similar to how iMessage is encrypted. In some situations, these
messages will go via the Apple Push Notification service instead of Bluetooth Low Energy.
The activity payload is protected and transferred in the same way as an iMessage.
iOS Security—White Paper | May 2016
Handoﬀ between native apps and websites
Handoﬀ allows an iOS native app to resume webpages in domains legitimately
controlled by the app developer. It also allows the native app user activity to be
resumed in a web browser.
To prevent native apps from claiming to resume websites not controlled by the
developer, the app must demonstrate legitimate control over the web domains it
wants to resume. Control over a website domain is established via the mechanism
used for shared web credentials. For details, refer to “Access to Safari saved passwords”
in the Encryption and Data Protection section. The system must validate an app’s
domain name control before the app is permitted to accept user activity Handoﬀ.
The source of a webpage Handoﬀ can be any browser that has adopted the Handoﬀ
APIs. When the user views a webpage, the system advertises the domain name of the
webpage in the encrypted Handoﬀ advertisement bytes. Only the user’s other devices
can decrypt the advertisement bytes (as previously described in the section above).
On a receiving device, the system detects that an installed native app accepts Handoﬀ
from the advertised domain name and displays that native app icon as the Handoﬀ
option. When launched, the native app receives the full URL and the title of the
webpage. No other information is passed from the browser to the native app.
In the opposite direction, a native app may specify a fallback URL when a Handoﬀ-
receiving device does not have the same native app installed. In this case, the system
displays the user’s default browser as the Handoﬀ app option (if that browser has
adopted Handoﬀ APIs). When Handoﬀ is requested, the browser will be launched and
given the fallback URL provided by the source app. There is no requirement that the
fallback URL be limited to domain names controlled by the native app developer.
Handoﬀ of larger data
In addition to the basic feature of Handoﬀ, some apps may elect to use APIs that
support sending larger amounts of data over Apple-created peer-to-peer Wi-Fi
technology (in a similar fashion to AirDrop). For example, the Mail app uses these
APIs to support Handoﬀ of a mail draft, which may include large attachments.
When an app uses this facility, the exchange between the two devices starts oﬀ just
as in Handoﬀ (see previous sections). However, after receiving the initial payload using
Bluetooth Low Energy, the receiving device initiates a new connection over Wi-Fi. This
connection is encrypted (TLS), which exchanges their iCloud identity certiﬁcates. The
identity in the certiﬁcates is veriﬁed against the user’s identity. Further payload data is
sent over this encrypted connection until the transfer is complete.
iPhone Cellular Call Relay
When your Mac, iPad, or iPod is on the same Wi-Fi network as your iPhone, it can
make and receive phone calls using your iPhone cellular connection. Conﬁguration
requires your devices to be signed in to both iCloud and FaceTime using the same
Apple ID account.
When an incoming call arrives, all conﬁgured devices will be notiﬁed via the Apple
Push Notiﬁcation service (APNs), with each notiﬁcation using the same end-to-end
encryption as iMessage uses. Devices that are on the same network will present the
incoming call notiﬁcation UI. Upon answering the call, the audio will be seamlessly
transmitted from your iPhone using a secure peer-to-peer connection between the
iOS Security—White Paper | May 2016
When a call is answered on one device, ringing of nearby iCloud-paired devices is
terminated by brieﬂy advertising via Bluetooth Low Energy 4.0. The advertising bytes
are encrypted using the same method as Handoﬀ advertisements.
Outgoing calls will also be relayed to iPhone via the Apple Push Notiﬁcation service,
and audio will be similarly transmitted over the secure peer-to-peer link between devices.
Users can disable phone call relay on a device by turning oﬀ iPhone Cellular Calls in
iPhone Text Message Forwarding
Text Message Forwarding automatically sends SMS text messages received on iPhone
to a user’s enrolled iPad, iPod touch, or Mac. Each device must be signed in to the
iMessage service using the same Apple ID account. When SMS Message Forwarding
is turned on, enrollment is veriﬁed on each device by entering a random six-digit
numeric code generated by iPhone.
Once devices are linked, iPhone encrypts and forwards incoming SMS text messages to
each device, utilizing the methods described in the iMessage section of this document.
Replies are sent back to iPhone using the same method, then iPhone sends the reply
as a text message using the carrier’s SMS transmission mechanism. Text Message
Forwarding can be turned on or oﬀ in Messages settings.
iOS devices that support Instant Hotspot use Bluetooth Low Energy to discover and
communicate to devices that have signed in to the same iCloud account. Compatible
Mac computers running OS X Yosemite and later use the same technology to discover
and communicate with Instant Hotspot iOS devices.
When a user enters Wi-Fi Settings on the iOS device, the device emits a Bluetooth Low
Energy signal containing an identiﬁer that all devices signed in to the same iCloud
account agree upon. The identiﬁer is generated from a DSID (Destination Signaling
Identiﬁer) tied to the iCloud account, and rotated periodically. When other devices
signed in to the same iCloud account are in close proximity and support personal
hotspot, they detect the signal and respond, indicating availability.
When a user chooses a device available for personal hotspot, a request to turn on
Personal Hotspot is sent to that device. The request is sent across a link that is encrypted
using standard Bluetooth Low Energy encryption, and the request is encrypted in a
fashion similar to iMessage encryption. The device then responds across the same
Bluetooth Low Energy link using the same per-message encryption with personal
hotspot connection information.
Safari search and Spotlight search include search suggestions from the Internet, apps,
iTunes, App Store, movie showtimes, locations nearby, and more.
To make suggestions more relevant to users, user context and search feedback with
search query requests are sent to Apple. Context sent with search requests provides
Apple with: i) the device’s approximate location; ii) the device type (e.g., Mac, iPhone,
iPad, or iPod); iii) the client app, which is either Spotlight or Safari; iv) the device’s
default language and region settings; v) the three most recently used apps on the
device; and vi) an anonymous session ID. All communication with the server is
encrypted via HTTPS.
iOS Security—White Paper | May 2016
Documents you may be interested
Documents you may be interested