ios 9 security guide changes

With iOS 9, developers can require that Touch ID API operations don’t fall back to an application password or the device passcode. Along with the ability to retrieve a representation of the state of enrolled fingers, this allows Touch ID to be used as a second factor in security sensitive apps.




Every time a file on the data partition is created, Data Protection creates a new 256-bit key (the “per-file” key) and gives it to the hardware AES engine, which uses the key to encrypt the file as it is written to flash memory using AES CBC mode. (On devices with an A8 processor, AES-XTS is used.)

All wrapped file key handling occurs
in the Secure Enclave; the file key is never directly exposed to the application processor. At boot, the Secure Enclave negotiates an ephemeral key with the AES engine. When the Secure Enclave unwraps a file’s keys, they are rewrapped with the ephemeral key and sent back to the application processor.



On devices with an A7 or later A-series processor, the delays are enforced by the Secure Enclave. If the device is restarted during a timed delay, the delay is still enforced, with the timer starting over for the current period

Delays between passcode attempts
Attempts Delay Enforced 1-4 none
5 1 minute
6 5 minutes
7-8 15 minutes
9 1 hour



In the case of an OTA software update, the user is prompted for his or her passcode when initiating the update. This is used to securely create a One-time Unlock Token, which unlocks the system keybag after the update. This token cannot be generated without entering the user’s passcode, and any previously generated token is invalidated if the user’s passcode changed.
One-time Unlock Tokens are either for attended or unattended installation of a software update. They are encrypted with a key derived from the current value of a monotonic counter in the Secure Enclave, the UUID of the keybag, and the Secure Enclave’s UID.
Incrementing the One-time Unlock Token counter in the SEP invalidates any existing token. The counter is incremented when a token is used, after the first unlock of a restarted device, when a software update is canceled (by the user or by the system), or when the policy timer for a token has expired.
The One-time Unlock Token for attended software updates expires after 20 minutes. This token is exported from the Secure Enclave and is written to effaceable storage. A policy timer increments the counter if the device has not rebooted within 20 minutes.
For unattended software updates, which is set when the user chooses “Install Later” when notified of the update, the application processor can keep the One-time Unlock Token alive in the Secure Enclave for up to 8 hours. After that time, a policy timer increments the counter.



Apple has already begun pursuit of iOS certification under the Common Criteria Certification (CCC) program. The first two certifications currently active are against the Mobile Device Fundamental Protection Profile v2.0 (MDFPP2) and the VPN IPSecPP1.4 Client Protection Profile (VPNIPSecPP1.4). Apple has taken an active role within the International Technical Community (ITC) in developing currently unavailable Protection Profiles (PPs) focused on evaluating key mobile security technology. Apple continues to evaluate and pursue certifications against new and updated version of the PPs available today.
Commercial Solutions for Classified (CSfC)
Where applicable, Apple has also submitted the iOS platform and various services for inclusion in the Commercial Solutions for Classified (CSfC) Program Components List. Specifically, iOS for Mobile Platform and the IKEv2 client for the IPSec VPN Client
(IKEv2 Always-On VPN only). As Apple platforms and services undergo Common Criteria Certifications, they will be submitted for inclusion under CSfC Program Component
List as well.
Security Configuration Guides
Apple has collaborated with governments worldwide to develop guides that give instructions and recommendations for maintaining a more secure environment, also known as “device hardening.” These guides provide defined and vetted information about how to configure and utilize features in iOS for enhanced protection.



iCloud remote access for HomeKit accessories
HomeKit accessories can connect directly with iCloud to enable iOS devices to control the accessory when Bluetooth or Wi-Fi communication isn’t available.
iCloud Remote access has been carefully designed so that accessories can be controlled and send notifications without revealing to Apple what the accessories are, or what commands and notifications are being sent. HomeKit does not send information about the home over iCloud Remote access.
When a user sends a command using iCloud remote access, the accessory and iOS device are mutually authenticated and data is encrypted using the same procedure described for local connections. The contents of the communications are encrypted and not visible to Apple. The addressing through iCloud is based on the iCloud identi- fiers registered during the setup process.
Accessories that support iCloud remote access are provisioned during the accessory’s setup process. The provisioning process begins with the user signing in to iCloud. Next, the iOS device asks the accessory to sign a challenge using the Apple Authentication Coprocessor that is built into all Built for HomeKit accessories. The accessory also generates prime256v1 elliptic curve keys, and the public key is sent to the iOS device along with the signed challenge and the X.509 certificate of the authentication coprocessor. These are used to request a certificate for the accessory from the iCloud provisioning server. The certificate is stored by the accessory, but it does not contain any identifying information about the accessory, other than it has been granted access to HomeKit iCloud remote access. The iOS device that is conducting the provision-
ing alsosends a bag to the accessory, which contains the URLs and other information needed to connect to the iCloud remote access server. This information is not specific to any user or accessory.
iOS Security—White Paper | September 2015 23
Each accessory registers a list of allowed users with the iCloud remote access server. These users have been granted the ability to control the accessory by the person who added the accessory to the home. Users are granted an identifier by the iCloud server and can be mapped to an iCloud account for the purpose of delivering notification messages and responses from the accessories. Similarly, accessories have iCloud-issued identifiers, but these identifiers are opaque and don’t reveal any information about the accessory itself.
When an accessory connects to the HomeKit iCloud remote access server, it presents its certificate and a pass. The pass is obtained from a different iCloud server and it is not unique for each accessory. When an accessory requests a pass, it includes its manufacturer, model, and firmware version in its request. No user-identifying or home-identifying information is sent in this request. The connection to the pass server is not authenticated, in order to help protect privacy.
Accessories connect to the iCloud remote access server using HTTP/2, secured using TLS 1.2 with AES-128-GCM and SHA-256. The accessory keeps its connection to the iCloud remote access server open so that it can receive incoming messages and send responses and outgoing notifications to iOS devices.




App Transport Security
App Transport Security provides default connection requirements so that apps adhere to best practices for secure connections when using NSURLConnection, CFURL, or NSURLSession APIs.
Servers must support a minimum of TLS 1.2, forward secrecy, and certificates must be valid and signed using SHA-256 or better with a minimum of a 2048-bit RSA key or 256-bit elliptic curve key.
Network connections that don’t meet these requirements will fail, unless the app overrides App Transport Security. Invalid certificates always result in a hard failure and no connection. App Transport Security is automatically applied to apps that are compiled for iOS 9.



VPN
Secure network services like virtual private networking typically require minimal setup and configuration to work with iOS devices. iOS devices work with VPN servers that support the following protocols and authentication methods:
• IKEv2/IPSec with authentication by shared secret, RSA Certificates, ECDSA Certificates, EAP-MSCHAPv2, or EAP-TLS.
• Pulse Secure, Cisco, Aruba Networks, SonicWALL, Check Point, Palo Alto Networks, Open VPN, AirWatch, MobileIron, NetMotion Wireless, and F5 Networks SSL-VPN using the appropriate client app from the App Store.
• Cisco IPSec with user authentication by Password, RSA SecurID or CRYPTOCard, and machine authentication by shared secret and certificates.
• L2TP/IPSec with user authentication by MS-CHAPV2 Password, RSA SecurID or CRYPTOCard, and machine authentication by shared secret.
• PPTP with user authentication by MS-CHAPV2 Password and RSA SecurID or CRYPTOCard is supported, but not recommended.




Rewards cards
As of iOS 9, Apple Pay supports the Value Added Service (VAS) protocol for transmitting merchant rewards cards to compatible NFC terminals. The VAS protocol can be implemented on merchant terminals and uses NFC to communicate with supported Apple devices. The VAS protocol works over a short distance and is used to provide complementary services, such as transmission of rewards card information, as part of an Apple Pay transaction.
The NFC terminal initiates receiving the card information by sending a request for a card. If the user has a card with the store’s identifier, the user is asked to authorize its use. If the merchant supports encryption, the card information, a timestamp, and a single-use random ECDH P-256 key is used with the merchant’s public key to derive an encryption key for the card data, which is sent to the terminal. If the merchant does not support encryption, the user is asked to re-present the device to the terminal before the rewards card information is sent.



Spotlight also includes mechanisms for making local, on-device content searchable:
• The CoreSpotlight API, which allows Apple and third-party apps to pass indexable content to Spotlight.
• The NSUserActivity API, which allows Apple and third-party apps to pass information to Spotlight regarding app pages visited by the user.
Spotlight maintains an on-device index of the information it receives using these two methods, so that results from this data can be shown in response to a user’s search, or automatically when Spotlight is launched. There is also an on-device federated search API, only available to Apple-provided apps, which allows Spotlight to pass user search queries to apps for processing, and receive their results.



iOS pairing model
iOS uses a pairing model to control access to a device from a host computer.
Pairing establishes a trust relationship between the device and its connected host, signified by public key exchange. iOS uses this sign of trust to enable additional func- tionality with the connected host, such as data synchronization. In iOS 9, services that require pairing cannot be started until after the device has been unlocked by the user.

In IOS 9, if a pairing record has not been used for more than six months, it expires.