Thoughtful, detailed coverage of the Mac, iPhone, and iPad, plus the best-selling Take Control ebooks.

How to Protect Your iCloud Keychain from the NSA

Send Article to a Friend

Apple has released a massive update to its “iOS Security” white paper for IT professionals. It contains more information on iOS security than Apple has ever shared publicly before, including extensive details on Touch ID, Data Protection, network security, application security, and nearly all security-related features, options, and protective controls.

For the first time, we have extensive details on iCloud security. For security professionals like myself, this is like waking up and finding a pot of gold sitting on my keyboard. Along with some of the most impressive security I’ve ever seen, Apple has provided a way to make it impossible for agencies like the NSA to obtain your iCloud Keychain passwords.

The paper is incredibly dense, even getting to the level of detail of which flavor of particular encryption algorithms are used in which security controls. I will likely be digesting it for months, but one particular section contained an important nugget that explains why the NSA can’t snoop on your iCloud Keychain passwords.

iCloud Keychain Background -- iCloud Keychain includes three key features, specifically, the capability to:

  • Create strong, random passwords for Web sites right from within Safari

  • Sync your keychain (and thus your stored passwords) between different devices

  • Back up that keychain to Apple’s servers

While strong, random passwords are essential for protecting your digital life, if you were to lose them, you’d be locked out of everything. It is thus in Apple’s interest to ensure that these passwords sync consistently, and that they are as protected from loss as is possible, for both you and Apple.

This means Apple needs to keep a backup copy of your keychain. Especially with recent fears of government snooping, trusting the keys to your digital life to a large company is a daunting prospect.

Apple uses different, but related, security methods to protect both keychain syncing and keychain escrow and recovery (backup). In Apple’s words:

Apple designed iCloud Keychain and Keychain Recovery so that a user’s passwords are still protected under the following conditions:

  • A user’s iCloud account is compromised.
  • iCloud is compromised by an external attacker or employee.
  • Third-party access to user accounts.

Secure Sync -- When you sync your keychain, Apple doesn’t actually keep a master copy in iCloud. The first device to enter the circle of trust (like an iPhone) creates a syncing identity using paired public and private keys (called asymmetric cryptography, which is very well understood and widely used). A key pair is generated, the public key is signed by the private key, and then the public key is encrypted by a key derived from your iCloud password. The signed circle of trust is placed in iCloud, but your private key never leaves your device.

At this point, iCloud has the public key from your device, encrypted with your iCloud password, and signed (so no one can fake it or modify it) with the private key on your device, but your keychain itself isn’t in iCloud.

When a new device is approved, the same process happens on that device, and the approved public key is signed and added to the circle of trust on each device and in iCloud (using yet more encryption). This is tied to notifications sent to existing devices in the circle and yet more cryptographic signing (and your iCloud password) to ensure someone can’t cheat the process and register their own device.

When passwords are added or changed, Apple syncs only the individual keychain items to other devices that need the update, one at a time. In other words, 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.

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. Even stealing your iCloud username and password wouldn’t provide an attacker access to your keychain. The attacker would also need a device currently in the circle of trust to approve the new one, and for you to not notice the approval notifications on every other device already in the circle.

Apple could technically subvert the process, for malicious reasons or at the behest of a large government agency, but not easily, not without changing the architecture (the notification and approval piece), and not without incurring serious legal liability now that the details have been published.

Secure Recovery -- Unlike sync, which sends only one keychain item at a time, iCloud Keychain Recovery does back up your entire keychain in iCloud.

Apple created a secure escrow service to handle this complex process in a highly secure way. Your keychain is encrypted with a strong key and stored in iCloud. The strong key needed to decrypt it is then itself encrypted with a new iCloud Security Code and the public key of special encryption hardware known as an HSM (Hardware Security Module). In my work as a security analyst, I write a lot about HSMs, which are tamper-resistant, highly secure hardware devices used by banks, governments, and major corporations to manage encryption and keys.

This gets a little complicated, but the easy way to think about it is that only the HSM can read the key encrypted with the iCloud Security Code, but since it doesn’t store the iCloud Security Code, it can’t read the actual key used to protect the keychain. If the right conditions are met, the HSM (actually a cluster of HSMs in case one breaks) will release the key, which can then be decrypted with the iCloud Security Code. Only then can the key be used to unlock your keychain.

Don’t feel bad if it’s hard to understand. It took me a while to figure this out, despite Apple’s clear documentation and the fact that I earn my living in part by advising HSM vendors.

The recovery process also requires your phone number, since Apple sends a text message you must reply to as part of the recovery process. You also need your iCloud username and password to request a recovery, and your iCloud Security Code to unlock your keys. That’s three pieces that are required before the keychain is opened. If someone tries to compromise your account but fails a few times, your account locks up and the only way to try again is to call Apple support. After that, 10 failures and the HSM destroys your escrow record, locking your keys away forever.

Just to be safe, Apple destroyed the administrator access cards for the HSMs, and set them to delete all the keys if any unauthorized access is detected. Then, all users are sent a notification to re-enroll before they lose their keys, and re-enrolling moves them to a different HSM cluster.

As I mentioned, part of my day job is advising large businesses and security vendors. I rarely see this level of security, and it’s especially rare to destroy the administrative smart cards required to access the HSM.

How to NSA-proof Keychain Recovery -- Despite all this, there is still the possibility Apple could, at the behest of law enforcement agencies, modify the process or compromise the HSMs and use that to access keychains and all the stored passwords. However, thanks to the destruction of the admin access cards, this could only affect new enrollments.

The reason for the HSMs is that neither a four-digit value for the iCloud Security Code (the default), nor a long user code (a second option), is good enough to generate a cryptographically sound key, because there simply isn’t enough entropy. Apple was worried that someone could guess your iCloud Security Code, and the HSMs and key escrow process defend against that.

Apple thus added a third option to allow your device to generate a cryptographically secure iCloud Security Code. If you select this option when setting up your iCloud Security Code in the process of turning on iCloud Keychain (tap Settings > iCloud > Keychain, turn on iCloud Keychain, and then follow the steps in the screenshot), iCloud Keychain Recovery uses a completely different process to protect your keychain.


When you do this, your device generates a totally random iCloud Security Code that contains so much entropy that you don’t need the HSMs, since it is theoretically impossible to break via brute force using current (and foreseeable) techniques and technology. Select this option and the original random key protecting your keychain is wrapped with a key generated using this random iCloud Security Code, is never sent to Apple, and can’t be intercepted.

Without this random iCloud Security Code (store it in a password management tool like 1Password or LastPass, and make a paper backup — with good handwriting! — and store it securely), there is no way to decrypt your keychain from iCloud, and it is protected even if you-know-who steals a copy.

This entire process is impressive, with options to satisfy even the most paranoid, and it’s reassuring to see Apple putting so much thought and effort into maintaining the security of our data.

There are many more interesting details in the full iOS Security white paper that we hope to share with you in the future.

 

READERS LIKE YOU! Support TidBITS by becoming a member today!
Check out the perks at <http://tidbits.com/member_benefits.html>
Special thanks to Norm Loomer, Simon Pugh, Stu McGregor, and James
Burcsu for their generous support!
 

Comments about How to Protect Your iCloud Keychain from the NSA

there is one weakness is that somebody borrow ur device, and u told the pass code, they go to setting -> safari -> pass code and auto fill -> saved password and click the site, put the pass code. And ur password reveled.
That's a headache when ur friend borrow ur device
Ted Todorov  2014-03-04 04:17
That is what the guest account on OS X is for. Do not, under any circumstance allow someone else to have possession of your device while you are logged in.
Kyle M  2014-03-02 09:23
How do you opt-in to the third option for recovery you describe in the article?
Adam Engst  An apple icon for a TidBITS Staffer 2014-03-03 07:21
It's an option when setting up iCloud Keychain - I've added more explicit directions and a screenshot to the article.
jakimo  2014-03-03 18:31
How then, to go back and set this up AFTER it's already been initialized?
Jeffrey  2014-03-03 20:44
If you already turned on iCloud Keychain, go to Account Details in iCloud Preferences, there is a button for it.
Alas, if you have a Mac, then it's very insecure. The iCloud keychain unlocks with your login password on OS X; you can't set a separate password for it. So all someone needs to do is get access to your Mac, change the login password (we all know that this is very simple), then they'll have full access to everything in the iCloud password. If you don't use a Mac, or don't have it set up on a Mac, then it's probably very secure. But if you do use a Mac, it couldn't be any less secure.
Tom Robinson  2014-03-03 15:28
But you still need your existing password to set a new one, or even look at items in an unlocked keychain…
If you reset the login password without the original that keychain is locked and no longer accessible.
Adrian  2014-03-04 07:19
You can set a different password for your login keychain in the keychain access utility. You can also disable syncing of login and keychain passwords in the keychain access' preferences.
This also happens if you migrate a login keychain to a new machine where you've set another login password. In that case you need the old password to unlock the login keychain since it's still encrypted with it.
Steven Fisher  2014-03-04 09:03
This is the difference between a password and decryption key. A password can be reset. But if it's used as a factor in a decryption key, you can't decrypt the data without the original password.

The attack you describe doesn't exist.
Jason Discount  2014-03-03 16:26
Surely opting out of iCould Keychain Recovery is the best option? Why doesn't anyone seem to be suggesting that for increased security?
Suzanne R Brown  2014-03-03 16:42
I'm not worried about NSA getting my keychain - it's pretty boring. I just wish it actually WORKED with all my devices! I have never get it to work seamlessly and I'm pretty good with my computer.
That's exactly why most companies never bother with all this security - with HSMs, et cetera.

I am sure glad Apple does; it's one of those things where they really did not have to do that but did it anyway because Apple cares about their user's data, even if the users themselves don't.

And and yes I realize there's a profit motive underlying it as well; it builds trust.
Andrew  2014-03-03 17:10
How does the third option (using a cryptographically secure iCloud Security Code) work without the HSM? Is the original random key, encrypted using this random iCloud Security Code, sent to Apple?
In my experience iCloud isn't very reliable and it's next to impossible to troubleshoot since a lot of things are deliberately hidden from the user.

So why should I entrust the most sensitive part of my digital life to iCloud? Plus, after the recent SSL blunder, I have great doubt that Apple really takes security serious. A simple screw-up that went undetected for months? Ha.

Again, no way I'm handing over my digital keys to a service like that.

In my book you aren't trusted, you have to earn trust. And that happens not through your PR department, but through your engineering. Security-wise I've gotten a rather sobering glance of that.
Reading the document, I was already astonished about the lengths Apple went to. Seeing these interprations and background info really opens my eye.

But what is a random super-long key worth, when the NSA asks Apple to put in a hook into IOS to grab the key from the device? Before anything is encrypted?

Sure, they shouldn't. But I'm under the impression that when NSA asks (and points to PATRIOT), then Apple has no way to refuse.

So everything in the IOS document and on here needs to taken with a pinch of (realistic, nowadays) salt....

The NSA can and will read our stuff, no matter how secure Apple designs anything. N'est pas?
Nail on the head. No security is unbreakable, no entity completely trustworthy, and if any governing agency requires companies to have secret backdoors, it's all moot. Throwing all your passwords and private data into the cloud sounds like the setup to a bad joke. Dropbox, Facebook, Google, PATRIOT, PRISM, Trusted Computing, and EFF concerns... privacy in the industry is bonkers. Not saying everyone needs to use darknets, throw public keys on all their websites, and hide in a cave, but keeping everything local is definitely the way to go.
I think you have a type in the third paragraph about syncing:

"...and the approved private key is signed and added to the circle of trust on each device and in iCloud."

Should this be "the approved public key is signed"?
Adam Engst  An apple icon for a TidBITS Staffer 2014-03-04 10:02
Yep, you're right, thanks! Fixed above now.
Great Article. However, I do not have a box to enable "Allow AutoFill even for websites that request passwords not to be saved". Any ideas why?
IIRC you need to set a screensaver password (or password to wake from sleep) for that to become available.
Hmmmm... I have always had it set to immediately require a password after sleep or screen saver begins.
Donald Burr  2014-03-11 13:38
Steve Gibson recently did an analysis of the Apple security document in today's Security Now (listening to it live, it should hit the podcast feed later tonight) According to him, Apple used the weak Elliptic Curve algorithm that was allegedly inserted into the standard by the NIST at the behest of the NSA. Is this true and if so what are the ramifications? Is the entire iCloud Keychain system broken or just some obscure part of it? (sorry, I am by no means a security expert so don't really understand all of this)
Rostislav  2014-04-21 21:27
Well, I've read entire white paper which covers Apple iOS security. In my opinion, Steve Gibson missed one thing. Yes, he's right about usage of probably compromised p-256 curve in ECC. It is used only in iCloud Keychain Sync and white paper says that your keychain is not stored in iCloud(until you use keychain escrow, which use different type of encryption). When the pair of keys is created, the public key is signed by your private key (which never leave your device and thus nobody except you could change it) and then encrypted using potentially corupted ECC by your iCloud Password. In possibility of attacker decrypt it, he gets only your public key(s) which is used for encrypting keychain item in syncing session. But it couldn't be used for decrypting it. You need private key(s) to do so, which is stored only in your device(s). Furthermore last year have showed us that NSA don't need to get our passwords. They've gotten data directly...
Norbert Fabritius  2014-04-29 04:12
My thoughts exactly,

I wrote Steve about this. I think that even if this particular curve could be broken by an attacker, he could inspect the public keys of all devices in that circle, but not add his own device.
Additionally, he might be able to forge requests to be a part of that circle. Those requests would still need to be confirmed by a device that is already part of that circle.

So when it comes to syncing, this is not worse than loosing your iCloud password. And iCloud keychain was designed to resist just that.