iOS Security Guide changes for iOS 10 from March 2017

gistfile1.txt

These are additions or notable revisions in the iOS Security Guide
Document Revision History  Summary Updated for iOS 10
• System Security
• Data protection classes
• Security Certifications and programs
• HomeKit, ReplayKit, SiriKit
• Apple Watch
• Wi-Fi,VPN
• Single Sign-on
• Apple Pay, Paying with Apple Pay on the web
• Credit, debit, and prepaid card provisioning • Safari
Suggestions
• For more information about the security contents of iOS 10 see:
https://support.apple.com/HT207143



The Secure Enclave is a coprocessor fabricated in the Apple A7 or later A-series
processor.
=> The Secure Enclave is a coprocessor fabricated in the Apple S2,
Apple A7, and later A-series processors.

Except on the Apple A7, the Secure Enclave’s memory is also authenticated with
the ephemeral key.

 Generate and use ECC keys inside Secure Enclave. These keys can be protected by
Touch ID. Operations with these keys are always done inside Secure Enclave after
Secure Enclave authorizes the use. Apps can access these keys using Keychain
through SecKey. SecKeys are just references to the Secure Enclave keys and the
keys never leave Secure Enclave. Touch ID can also be configured to approve
purchases from the iTunes Store, the   App Store, and the iBooks Store, so users
don’t have to enter an Apple ID password. When they choose to authorize a
purchase, authentication tokens are exchanged between the device and the store.
The token and cryptographic nonce are held in the Secure Enclave. The nonce is
signed with a Secure Enclave key shared by all devices   and the iTunes Store.
With iOS 10, Touch ID protected Secure Enclave ECC keys are used to authorize a
purchase by signing the store request.

.  On A9 or later A-series processors, the flash storage subsystem is on an
isolated bus that is only granted access to memory containing user data via the
DMA crypto engine.


The keybag is protected with the password set in iTunes, run through 10,000
iterations of PBKDF2.  => The keybag is protected with the password set in
iTunes, run through 10 million iterations of PBKDF2.

 ApplehasreceivedISO27001certificationfortheInformationSecurityManagementSystemf
 ortheinfrastructure,development,andoperationssupportingtheproductsandservices:A
 ppleSchoolManager,iCloud,iMessage,FaceTime,ManagedAppleIDs,andiTunesU,inaccorda
 ncewiththeStatementofApplicabilityv1.0,datedFebruary26,2016.Apple’scompliancewi
 ththeISOstandardwascertifiedbytheBritishStandardsInstitution.Toviewthiscertific
 ate,gotohttps://www.bsigroup.com/en-GB/our-services/certification/certificate-
 and-client-directory/search-
 results/?searchkey=company=apple&licencenumber=IS+649475.


 The process to provision Apple TV for use with HomeKit is performed
automatically when the user signs in to iCloud. The iCloud account needs to have
two-factor authentication enabled. Apple TV and the owner’s device exchange
temporary Ed25519 public keys over iCloud. When the owner’s device and Apple TV
are on the same local network, the temporary keys are used to secure a
connection over the local network using Station-to- Station protocol and per-
session keys. This process uses authentication and encryption that is the same
as that used between an iOS device and a HomeKit accessory. Over this secure
local connection, the owner’s device transfers the user’s Ed25519 public-private
key pairs to Apple TV. These keys are then used to secure the communication
between Apple TV and the HomeKit accessories and also between Apple TV and other
iOS devices that are part of the HomeKit home.

 AudiosenttoSirimaydenotespecificaccessoriesorcommands,butsuchSiridataisnotassoc
 iatedwithotherApplefeaturessuchasHomeKit.Formoreinformation,referto“Siri”intheI
 nternetServicessectionofthispaper.

SiriKit  Siri utilizes the iOS Extension mechanism to communicate with third-
party apps. Although Siri has access to iOS contacts and the device’s current
location, Siri checks the permission to access iOS-protected user data of the
app containing the Extension to see if the app has access before providing that
information to it. Siri passes only the relevant fragment of the original user
query text to the extension. For example, if the app doesn’t have access to iOS
contacts, Siri won’t resolve a relationship in a user request such as “Pay my
mother $10 using PaymentApp.” In this case, the Extension’s app would only see
“mother” through the raw utterance fragment being passed to it. However, if the
app does have iOS contacts access, it would receive the iOS Contact information
for the user’s mother. If a contact were referred to in the body of a message
—for example,“Tell my mother on MessageApp that my brother is awesome”—Siri
wouldn’t resolve “my brother” regardless of the app’s TCCs. Content presented by
the app may be sent to the server to allow Siri to understand vocabulary a user
may use in the app. Siri allows at runtime for the SiriKit enabled app to
provide a set of custom words specific to application instance. These custom
words are tied to the random identifier discussed in the Siri section, and have
the same lifetime.


ReplayKit ReplayKit is a framework that allows developers to add recording and
live broadcasting capabilities to their apps. In addition, it allows users to
annotate their recordings and broadcasts using the device’s front-facing camera
and microphone. Movie recording There are several layers of security built into
recording a movie:
• Permissions dialog: Before recording starts, ReplayKit
presents a user consent   alert requesting that the user acknowledge their
intent to record the screen, the microphone, and the front-facing camera. This
alert is presented once per app process, and will be re-presented if the app is
left in the background for longer than   8 minutes.
• Screen and audio capture:
Screen and audio capture occurs out of the app’s process in ReplayKit’s daemon
replayd. This ensures the recorded content is never accessible to the app
process.
• Movie creation and storage: The movie file is written to a directory
that’s only accessible to ReplayKit’s subsystems and is never accessible to any
apps. This prevents recordings being used by third parties without the user’s
consent.
• End-user preview and sharing: The user has the ability to preview and
share the movie with UI vended by ReplayKit. The UI is presented out-of-process
via the iOS Extension infrastructure and has access to the generated movie file.
Broadcasting
• Screen and audio capture: The screen and audio capture mechanism
during broadcasting is identical to movie recording and occurs in replayd.
• Broadcast extensions: For third-party services to participate in ReplayKit
broadcasting, they’re required to create two new extensions that are configured
with the com.apple.broadcast-services endpoint: – A UI extension that allows the
user to set up their broadcast. – An upload extension that handles uploading
video and audio data to the service’s back-end servers. The architecture ensures
that hosting apps have no privileges to the broadcasted video and audio
contents–only ReplayKit and the third-party broadcast extensions have access.
•Broadcast picker: To select which broadcast service to use, ReplayKit provides a
view controller (similar to UIActivityViewController) that the developer can
present in their app. The view controller is implemented using the
UIRemoteViewController SPI and is an extension that lives within the ReplayKit
framework. It is out-of-process from the hosting app.
• Upload extension: The upload extension that third-party broadcast 
services implement to handle video
and audio content during broadcasting can choose to receive content in two ways:
– Small encoded MP4 clips. – Raw unencoded sample buffers.
• MP4 clip handling:
During this mode of handling, the small encoded MP4 clips are generated by
replayd and stored in a private location only accessible to ReplayKit’s
subsystems. Once a movie clip is generated, replayd will pass the location of
the movie clip to the third-party upload extension via the NSExtension request
SPI (XPC based). replayd also generates a one-time sandbox token that’s also
passed to the upload extension, which grants the extension access to the
particular movie clip during the extension request.
• Sample buffer handling:
During this mode of handling, video and audio data is serialized and passed to
the third-party upload extension in real time through a direct XPC connection.
Video data is encoded by extracting the IOSurface object from the video sample
buffer, encoding it securely as an XPC object, sending over via XPC to the
third-party extension, and decoding securely back into an IOSurface object.


Notes can be shared with others. The note data is stored encrypted, and CloudKit
manages the process by which participants can encrypt/decrypt each other’s data.


The RC4 symmetric cipher suite is deprecated in iOS 10 and macOS Sierra. By
default, TLS clients or servers implemented with SecureTransport APIs don’t have
RC4 cipher   suites enabled, and are unable to connect when RC4 is the only
cipher suite available. To be more secure, services or apps that require RC4
should be upgraded to use modern, secure cipher suites.


By default, App Transport Security limits cipher selection to   include only
suites that provide forward secrecy, specifically ECDHE_ECDSA_AES and
ECDHE_RSA_AES in GCM or CBC mode. Apps are able to disable the forward secrecy
requirement per-domain, in which case RSA_AES is added to the set of available
ciphers.


• PPTP is supported, but not recommended. => PPTP is supported in iOS 9.3 or
• earlier, but not recommended.

Besides protection for data, iOS extends WPA2 level protection to unicast and
multicast management frames through Protected Management Frame service referred
in 802.11w. PMF support is available on iPhone 6s and iPad Air 2 and later.

iOS uses randomized Media Access Control (MAC) address when conducting Wi-Fi
scans while it isn’t associated with a Wi-Fi network. These scans could be
performed in order to find and connect a preferred Wi-Fi network or to assist
Location Services for apps that use Geofences, such as location-based reminders
or fixing a location in Apple Maps. Note that Wi-Fi scans which happen while
trying to connect to a preferred Wi-Fi Network aren’t randomized.


On iPhone 6S and later, the hidden property of a known Wi-Fi network is known
and updated automatically. If the Service Set Identifier (SSID) of a Wi-Fi
network is broadcasted, the iOS device won’t send a probe with the SSID included
in the request. This prevents the device from broadcasting the network name of
non-hidden networks.


Single Sign-on Certificate-based authentication (PKINIT) is also supported.


On Apple Watch, the device must be unlocked with passcode and the side button
must be double-clicked for a payment to be made.



Paying with Apple Pay on the web Apple Pay can be used to make payments on
websites.In iOS 10, Apple Pay transactions can be made on the web on iPhone and
iPad. Also, in macOS Sierra, Apple Pay transactions can start on a Mac and be
completed on an Apple Pay enabled iPhone or Apple Watch using the same iCloud
account. Apple Pay on the web requires all participating websites to register
with Apple. The Apple servers perform domain name validation and issue a TLS
client certificate. Websites supporting Apple Pay are required to serve their
content over HTTPS. For each payment transaction, websites need to obtain a
secure and unique merchant session with an Apple server using the Apple-issued
TLS client certificate. Merchant session data is signed by Apple. Once a
merchant session signature is verified, a website may query whether the user has
an Apple Pay capable device and whether they have a credit, debit, or prepaid
card activated on the device. No other details are shared. If the user doesn’t
want to share this information, they can disable Apple Pay queries in Safari
privacy settings on both macOS and iOS. Once a merchant session is validated,
all security and privacy measures are the same as when a user pays within an
app. In the case of Mac to iPhone or Apple Watch handoff, Apple Pay uses the
end-to-end encrypted IDS protocol to transmit payment related information
between the user’s Mac and the authorizing device. IDS uses the user’s device
keys to perform encryption so no other device can decrypt this information, and
the keys aren’t available to Apple. Device discovery for Apple Pay handoff
contains the type and unique identifier of the user’s credit cards along with
some metadata. The device-specific account number of the user’s card isn’t
shared and it continues to remain stored securely on the user’s iPhone or Apple
Watch. Apple also securely transfers the user’s recently used contact, shipping,
and billing addresses over iCloud Keychain.  Once the user authorizes payment
using Touch ID or their passcode on iPhone or double-clicks the side button on
Apple Watch, a payment token uniquely encrypted to each website’s merchant
certificate is securely transmitted from the user’s iPhone or Apple Watch to
their Mac and then delivered to the merchant’s website. Only devices in
proximity to each other may request and complete payment. Proximity is
determined through Bluetooth Low Energy advertisements.


How iMessage sends and receives messages

The user’s outgoing message is individually encrypted for each of the receiver’s
devices. The public RSA encryption keys of the receiving devices are retrieved
from  IDS. For each receiving device, the sending device generates a random
128-bit key  and encrypts the message with it using AES in CTR mode. 
=>  The
user’s outgoing message is individually encrypted for each of the receiver’s
devices. The public RSA encryption keys of the receiving devices are retrieved
from   IDS. For each receiving device, the sending device generates a random
88-bit value and uses it as an HMAC-SHA256 key to construct a 40-bit value
derived from the sender and receiver public key and the plaintext. The
concatenation of the 88-bit and 40-bit values makes a 128-bit key, which
encrypts the message with it using AES in CTR mode. The 40-bit value is used by
the receiver side to verify the integrity of the decrypted plaintext.

Here’s what iCloud backs up:
• Records for purchased music, movies, TV shows,
apps, and books. A user’s iCloud backup includes information about purchased
content present on the user’s iOS device, but not the purchased content itself.
When the user restores from an iCloud backup, their purchased content is
automatically downloaded from the iTunes Store, App Store, or iBooks Store. Some
types of content aren’t downloaded automatically in all countries, and previous
purchases may be unavailable if they have been refunded or are no longer
available in the store. Full purchase history is associated with a user’s Apple
ID. • Photos and videos on a user’s iOS devices. Note that if a user turns on
iCloud Photo Library on their iOS device (iOS 8.1 or later) or Mac (OS X
v10.10.3 or later), their photos and videos are already stored in iCloud, so
they aren’t included in the user’s iCloud backup.

A small sub-set of recordings, transcripts and associated data without
identifiers may continue to be used by Apple for ongoing improvement and quality
assurance of Siri beyond two years.

Universal Clipboard Universal Clipboard leverages Handoff to securely transfer
the content of your clipboard across devices so you can copy on one device and
paste on another. Content is protected the same way as other Handoff data and
shared by default with Universal Clipboard, unless the app developer chooses to
disallow sharing. Apps have access to clipboard data regardless of whether the
user has pasted the clipboard into the app. With Universal Clipboard, this data
access extends to apps running on your other devices (as established by your
iCloud sign in). Auto Unlock Mac computers that support Auto Unlock use
Bluetooth Low Energy and peer-to-peer Wi-Fi to securely allow the user’s Apple
Watch to unlock the Mac. Each capable Mac and Apple Watch associated with an
iCloud account must use two-factor authorization ( TFA).
When enabling an Apple Watch to unlock a Mac, a secure
link using Auto Unlock Identities is established. The Mac creates a random one-
time use unlock secret and transmits it to the Apple Watch over the link. The
secret is stored on Apple Watch and can only be accessed when Apple Watch is
unlocked (see Data Protection classes). Neither the master entropy nor the new
secret is the user’s password. During an unlock operation, the Mac uses
Bluetooth Low Energy to create a connection to the Apple Watch. A secure link is
then established between the two devices using the shared keys used when it was
first enabled. The Mac and Apple Watch then use peer-to-peer Wi-Fi and a secure
key derived from the secure link to determine the distance between the two
devices. If the devices are within range, the secure link is then used to
transfer the pre-shared secret to unlock the Mac. After successful unlock, the
Mac replaces the current unlock secret with a new one-time use unlock secret and
transmits the new unlock secret to the Apple Watch over the link.


Apple Security Bounty Apple rewards researchers who share critical issues with
Apple. In order to be eligible for an Apple Security Bounty, researchers are
required to provide a clear report and working proof of concept. The
vulnerability must affect the latest shipping iOS and where relevant the latest
hardware. The exact payment amount will be determined after review by Apple. The
criteria includes novelty, likelihood of exposure, and degree of user
interaction required. Once the issues are properly shared, Apple makes it a
priority to resolve confirmed issues as quickly as possible. Where appropriate,
Apple will provide public recognition, unless otherwise requested. Category
Secure boot firmware components Extraction of confidential material protected by
the Secure Enclave Execution of arbitrary code with kernel privileges
Unauthorized access to iCloud account data on Apple servers Access from a
sandboxed process to user data outside of that sandbox Maximum payment (USD)
$200,000 $100,000 $50,000 $50,000 $25,000