Apple rarely offers anyone a glimpse inside its walled-off security garden. The last time it did was in the spring of 2012 when it released a detailed paper on the security of its iOS operating system for iPhones and iPads. The company also presented a much-anticipated if not anticlimactic presentation at the Black Hat Briefings that summer summarizing the high points of the paper.
Now, scant days after the revelation that a stunningly simple coding mistake led to emergency updates for iOS and OS X in order to close a cavernous SSL certificate-validation vulnerability, Apple has released an updated iOS security guide.
The 33-page document explains in a helpful degree of detail the inner workings of iOS system security, encryption and data protection capabilities, network security, device controls, application security and security around its Internet services such as iCloud, iCloud Keychain, iMessage and more.
The application security and Internet services sections are new additions to the paper. The services, in particular, are key hubs for iOS users’ data, not only as it’s shared via messaging applications and services, but at rest in storage services such as iCloud.
Rich Mogull, founder of consultancy Securosis, wrote in an analysis of the paper that this is the first time Apple has shared any level of noteworthy detail on iCloud and said the mechanisms deployed by Apple would make it difficult for intelligence agencies to intercept data such as iCloud Keychain passwords. Keychain allows users to sync passwords between devices running iOS and computers running OS X.
Apple said in the paper that iCloud Keychain and Keychain Recovery services are designed so that passwords are protected regardless if an account has been compromised, whether iCloud is compromised, or third parties have access to user accounts.
The paper describes an elaborate encryption scheme used by iCloud Keychain involving asymmetric cryptography in which the private key signs the public key, yet never leaves the user’s device.
“Each keychain item is sent only to each device that needs it, the item is encrypted so only that device can read it, and only one item at a time passes through iCloud,” Mogull wrote. “To read it, an attacker would need to compromise both the key of the receiving device and your iCloud password. Or re-architect the entire process without the user knowing. Even a malicious Apple employee would need to compromise the fundamental architecture of iCloud in multiple locations to access your keychain items surreptitiously.”
Apple also uses a secure infrastructure for keychain escrow allowing only authorized users and devices to recover a keychain. The escrow records are protected by clusters of hardware security modules, Apple said. Again, another complex series of events, protect the escrow record and ultimately keychain recovery.
The timing of the paper keeps the security of Apple devices in the news a bit longer. Apple’s release on iOS 7.06 late on the afternoon of Friday Feb. 21 corrected a coding mistake that removed SSL certificate checks from iOS—and later it was revealed to affect OS X as well. Attackers who successfully had pulled off a man-in-the-middle attack on the victim’s wireless network could intercept and read communication in clear text because of the goto fail bug as it has come to be known.
In an analysis of the vulnerability, Google expert Adam Langley said a server could send a valid certificate chain to the client and not have to sign the handshake. Langley summarized:
“This signature verification is checking the signature in a ServerKeyExchange message. This is used in DHE and ECDHE ciphersuites to communicate the ephemeral key for the connection. The server is saying ‘here’s the ephemeral key and here’s a signature, from my certificate, so you know that it’s from me’,” Langley wrote in his analysis. “Now, if the link between the ephemeral key and the certificate chain is broken, then everything falls apart. It’s possible to send a correct certificate chain to the client, but sign the handshake with the wrong private key, or not sign it at all! There’s no proof that the server possesses the private key matching the public key in its certificate.”
