iOS Security Guide changes for iOS 10 from March 2017

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