Reverse-Engineering iCloud Keychain

Spy briefcase

You might wonder: “How safe is iCloud Keychain? Can Apple access my passwords? Will Apple give my passwords to the Government?” Or even you might think: “It’s impossible for Apple not to know my passwords yet let all my other devices use them to login to other sites”.

If the latter is what you think, please let me prove you wrong. It is possible to store your passwords, let your devices use those passwords, and yet have no knowledge whatsoever on what your passwords really are. This article shows you how it could be done.

First Setup Phase

This is when you first agree to use iCloud Keychain and then setting up your first Mac or iOS device to use it.

  1. The device (an OS X computer or iOS device)  asks for a PIN from you. Let’s call this device D1
  2. D1 generates a random number (a salt), appends it to the PIN, hash it then save the hash with the salt value. Let’s call the hash P and salt value S, so that P = H(PIN,S). Note that the PIN itself is not persisted anywhere.
  3. D1 generates a master key M then encrypts it using the hashed PIN.
  4. D1 uses the hash P as password (key) to encrypt your master key M.
  5. D1 uses master key M to encrypt all your passwords in your device’s keychain.
  6. D1 generates a Public/Private key pair (an asymmetric key) for identifying itself and for others to send private data to it. Let’s call this asymmetric key A1.
  7. D1 sends your encrypted master key, your encrypted user ID and passwords (your Keychain entries), and its public key to iCloud.
 At this point iCloud will have:
  • Your device’s public key, A1-pub.
  • Your master key that’s encrypted using your PIN’s hash value: E(M,P)
  • Your keychain entries that are encrypted with the master password: E( {(user-id,password),…}, M)
As you can see for yourself, there is no way to see your keychain entries without having the value of P. Even though Apple is forced to submit your passwords, they can only provide the encrypted version of your data.

Subsequent Authorization Phase

Now let’s say you want to access your Keychain from a second device. The trick is, how to get this second device access to the master key without having the broker (i.e. iCloud) to see that key in the clear. If iCloud never sees this master key, then it cannot be liable for leaking it to third parties. 

  1. The second device asks for your PIN. Let’s call this device D2
  2. D2 generates a Public/Private asymmetric key pair for itself, let’s call this A2.
  3. D2 asks iCloud for authorization to your Keychain on the cloud and sends its public key along with the request. 
  4. Seeing the D2’s request, iCloud responds with the public keys of all known authorized devices – the first device’s public key A1-pub will be in this set of keys.
  5. D2 encrypts the entered PIN number using the public keys that it receives, one of those keys will be A1-pub and sends them over to iCloud.
  6. Then iCloud notifies each authorized devices to authorize D2. Each device will get its own encrypted PIN message that D2 generates.
  7. Since D1 is an already-authorized devices, it then sees this notification and prompts the user to confirm this authorization request.
  8. Should the user confirm, D1 decrypts the received PIN using its private key A1-priv, appends the salt value S and then hash it to generate hash value P’. The hash value P’ is then compared with the original hash value P and see if they are equal.
  9. If P’ equals to P then the PIN entered in D2 is valid. D1 then notifies iCloud to authorize D2.
  10. D1 encrypts salt value S using D2’s public key A2-pub and sends it to iCloud, which then gets passed over to D2.
  11. D2 then decrypts the salt value S and use it to re-generate the hash key P. Just like previously, P and S is saved by D2 locally in a secure location.
  12. D2 then asks for the encrypted master key E(M,P) from iCloud and then decrypts the master key M.
  13. D2 can then decrypts any of your iCloud Keychain entries using M.
During the entire transaction, iCloud only sees these additional information:
  • Your second device’s public key A2-pub
  • An asymmetrically-encrypted version of the PIN code you entered on the second device: F(PIN,A1-pub)
  • An asymmetrically-encrypted version of the salt value that the first device generates: F(S,A2-pub)

Keep in mind that when asymmetric encryption is used, the encryption key is different than the decryption key. The public key half can be exposed to the public and be used to encrypt messages but not decrypt them. Only the private key half can be used to decrypt the data.

Changing PIN

If you ever changed your iCloud Keychain’s PIN then the device that you use to do it can simply re-generate the hash value P, encrypts it using your all of your other devices’ respective public keys and sends those over to iCloud for distribution. Still iCloud won’t be able to see your PIN nor its hash value since it doesn’t keep any private keys – only your other devices can decrypt them. Then these other devices will receive the new S and P and can use it to authorize additional devices.

Trust Levels

For these to work, the communication needs to be secured and both the devices and iCloud need to know that the other party is “for real” – in other words ensure that there is no man-in-the-middle attack.

  • The device knows it’s really talking to iCloud from a valid SSL certificate.
  • iCloud knows that it’s talking to a genuine user’s device from an Apple ID login/password combination.

Conclusions

As you can see for yourself, the broker (in this case iCloud) won’t be able to see your private data. Hence if some very powerful government asks for it, they can only get the encrypted version of that data and folks at Apple can say they don’t have the keys to decrypt those. However if this powerful government is able to brute-force the encryption, then it’s another story altogether.

One nice effect of this design is that all encryption/decryption is done by the user’s devices. This increases security, for sure. But it also reduces iCloud’s CPU load – since most of the heavy duty encryption work are done not by the central server. It somewhat helps scalability – multiply a few seconds of CPU usage to encrypt/decrypt those keys with the number of Mac/iOS users and those operations can become a real burden to the servers.  

Honestly, I’m an outsider and don’t really know how iCloud really works. However this shows how iCloud Keychain and competing solutions like 1Password could work. Which hopefully at least as strong as what I’ve outlined here – if not stronger. All in all you can use this design as a guide should you need to implement something similar yourself – how to safeguard your user’s sensitive information and simultaneously give access to those data without you yourself know what they really are and consequentially be liable for it.

Until next time. Stay secured.



Avoid App Review rules by distributing outside the Mac App Store!


Get my FREE cheat sheets to help you distribute real macOS applications directly to power users.

* indicates required

When you subscribe you’ll also get programming tips, business advices, and career rants from the trenches about twice a month. I respect your e-mail privacy.

Avoid Delays and Rejections when Submitting Your App to The Store!


Follow my FREE cheat sheets to design, develop, or even amend your app to deserve its virtual shelf space in the App Store.

* indicates required

When you subscribe you’ll also get programming tips, business advices, and career rants from the trenches about twice a month. I respect your e-mail privacy.

4 thoughts on “Reverse-Engineering iCloud Keychain

  1. One more question.

    Apparently apple lets you recover the keychain if you lost all your devices using the PIN.
    How can you explain this if the S (salt value) is not uploaded into icloud?

  2. Why the first device should create the Master Key (M)?. Why can´t, instead, use the hash PIN (P) as a Master Key?

Leave a Reply to Sasmito AdibowoCancel reply