Apple recently announced iOS 10 which includes many security and privacy related changes. This article aims to talk about some of the significant changes since iOS 9.
Network Security
Since HTTP is a plaintext protocol and therefore creates inherent security and privacy concerns when used, Apple has now decided that it is finally time to start treating HTTPS as the de facto web protocol. At WWDC this year, Apple rightly pointed out that simply “enabling” HTTPS does not necessarily mean that you are secure. There are many ways in which HTTPS can be improperly configured resulting in the use of insecure connections.
App Transport Security (ATS) was introduced in iOS 9 as a built in utility for protecting network communications, namely connections which use the NSURLSession and NSURLConnection APIs.
Out of the box, ATS enforces a TLS configuration with the following criteria:
- Apps must connect to servers using the TLS 1.2 protocol
- Apps can only connect to servers which provide strong ciphers.
- Strong ciphers are described as AES128+ and SHA2+
- As of iOS 10, the RC4 stream cipher is now disabled by default. As is the SSLv3 protocol. Apple states that both SHA1 and 3DES will also be deprecated and disallowed soon.
- Apps must connect to servers using Perfect Forward Secrecy (PFS) however Apple has stated that they’ll allow exceptions for this, for now.
Speaking of exceptions, previously the exceptions which were usable in the Info.plist were:
NSAllowsArbitraryLoadsNSExceptionAllowsInsecureHTTPLoadsNSExceptionMinimumTLSVersionNSExceptionRequiresForwardSecrecy(Optional, and defaults toYES)NSThirdPartyExceptionAllowsInsecureHTTPLoadsNSThirdPartyExceptionRequiresForwardSecrecyNSThirdPartyExceptionMinimumTLSVersion
In the Info.plist, these settings can be configured globally, for all connections, or for specific domains only.
An example of global configuration is shown below:
And the corresponding code:
<key>NSAppTransportSecurity</key>
<dict>
<key>NSAllowsArbitraryLoads</key>
<true/>
</dict>
An example of per-domain configuration is shown below:
And the corresponding code:
<key>NSAppTransportSecurity</key>
<dict>
<key>NSExceptionDomains</key>
<dict>
<key>cigital.com</key>
<dict>
<key>NSExceptionMinimumTLSVersion</key>
<string>TLSv1.1</string>
</dict>
<key>hexplo.it</key>
<dict>
<key>NSExceptionRequiresForwardSecrecy</key>
<false/>
</dict>
</dict>
</dict>
2016 Deadline
Important, by the end of 2016, Apple will enforce the use of ATS during App Store approval. It is therefore very important that engineering teams start to roadmap migration to securer HTTPS configurations as soon as possible.
As a developer, you can still configure exceptions in the ATS configuration, but you will be required to provide a justification in the app store review as to why you require the exception.
During the “What’s new in Security WWDC16 session”, Apple stated that one example use case for exceptions might be when you communicate with a 3rd party and don’t have control over their HTTPS configuration. Another example is when an Application communicates dynamically to various internet sites such as within a WebView. A 3rd example of an exception might be because the domain you want to communicate with does not offer Perfect Forward Secrecy.
To make the configuration and approval of exceptions easier and more granular, Apple has introduced new options for developers to use within the Info.plist.
The newly introduced options are as follows:
NSAllowsArbitraryLoadsInWebContent(When a WebKit WebView, a.k.aWKWebViewis in use).NSRequiresCertificateTransparency(Optional, and defaults toNO).
Apple also concedes that whilst Perfect Forward Secrecy is desirable, not everyone supports it. For this reason, they have decided that for now, NSExceptionRequiresForwardSecrecy exceptions will be granted automatically.
Apple also talked about added options for exceptions concerning media streaming via AVFoundation.
Certificate Transparency
In iOS 9 Apple introduced Certificate Transparency and it also got a mention at this years WWDC talking about iOS 10 security changes, re-emphasising that developers can utilise Certificate Transparency inside iOS applications.
Here is Google’s description of what certificate transparency is and solves: >Google’s Certificate Transparency project fixes several structural flaws in the SSL certificate system, which is the main cryptographic system that underlies all HTTPS connections. These flaws weaken the reliability and effectiveness of encrypted Internet connections and can compromise critical TLS/SSL mechanisms, including domain validation, end-to-end encryption, and the chains of trust set up by certificate authorities. If left unchecked, these flaws can facilitate a wide range of security attacks, such as website spoofing, server impersonation, and man-in-the-middle attacks.
Certificate Transparency helps eliminate these flaws by providing an open framework for monitoring and auditing SSL certificates in nearly real time. Specifically, Certificate Transparency makes it possible to detect SSL certificates that have been mistakenly issued by a certificate authority or maliciously acquired from an otherwise unimpeachable certificate authority. It also makes it possible to identify certificate authorities that have gone rogue and are maliciously issuing certificates.
In iOS, the system will verify a received certificate’s signed proofs (SCT) to ensure that the certificate was logged correctly. The system also makes use of OSCP Stapling to staple the SCT to the handshake for delivery.
Currently, like the Chromium project, iOS expects to see at least 2 proofs for a given certificate.
Finally, certificate transparency is built in to App Transport Security and can be enabled by setting NSRequiresCertificateTransparency to YES, within your ATS configuration. Note, you must also use a CA which is part of the Certificate Transparency program.
Cryptography Changes
Changes to SecKey
Apple has added APIs and algorithms for asymmetric cryptographic operations which are now unified across iOS and macOS. These APIs allow you to do operations like encrypt, decrypt, sign and verify. These APIs replace the CDSA/CSSM API set. Additionally, these also replace SecTransforms.
The iOS 10 API diffs for security are shown here: iOS 10 API Diffs.
Cryptographic Hardware Accessories
Apple has now introduced a new framework called CryptoTokenKit (see docs) which adds system support for various cryptographic hardware accessories, such as Smart Cards and USB crypto tokens.
Out of the box, the system now supports these hardware devices, allowing developers to interact with them via the new framework and the Keychain.