My iOS app has to handle storing private keys for the user. Normally I would just use Keychain Services for this as I would a password, but it would be great if I could sync the keys between the user's devices.

Apple's iCloud documentation says not to use iCloud for passwords, but is it safe to use for private keys? Apparently, iCloud data is encrypted in transit and on the server.

Are there any security risks in syncing private keys over the iCloud key-value store?

3 Answers 3


I'd scrap the direct syncing option and simply allow the user to export their private key to a location of their choice, e.g. iCloud, DropBox, internal storage, etc., in an encrypted format.

On export I'd do something like this:

  • Ask the user for a password to use. Don't impose any restrictions on them - it's their job to use a good password!
  • Use a strong key-derivation algorithm such as PBKDF2 to generate a storage key. Use a decent number of rounds.
  • Prefix the private key blob in memory with four known bytes (a magic number), e.g. 'NATG', to form your plaintext.
  • Encrypt the plaintext with AES-128 or a similar block cipher, in CBC mode, using the storage key and a randomly generated IV.
  • Export the ciphertext and IV into a file.

On import:

  • Extract the ciphertext and IV from the file.
  • Ask the user for the password and generate the same key using PBKDF2.
  • Decrypt the ciphertext using the IV and key.
  • Check that the first four bytes of plaintext match your known bytes. If not, it's the wrong password. If so, we're in the money!
  • Remove the first four bytes and you've got the private key!

This allows users to quickly and easily sync private keys via the communications service they want, whether it be iCloud or DropBox or even email, with a reasonable level of security. If their account gets broken into, the attacker still has to crack their password. If they've used a decent one, PBKDF2 should do a decent job of making their cracking attempt infeasible.

  • Great explanation and suggestion, thank you! Out of curiosity, could this also be applied to something like an OAuth token?
    – Nathan G.
    Mar 17, 2013 at 22:11
  • Sure. But at that point it's probably easier to just get them to type the OAuth token in on each side ;)
    – Polynomial
    Mar 17, 2013 at 22:57

Private keys are in essence the same as passwords. In order to be an effective security device, they need to be kept secret. So no, if it documentation says that it shouldn't be for passwords, it stands to reason that it isn't safe enough to be used for private keys either.


In contrast to Polynomial's suggestion, I don't like exporting to DropBox or Email, since most end users use 3rd party applications that have access to the entire datastore using linked apps.

DropBox in particular makes it too easy for an app to gain full access to the entire storage (keys and everything).

enter image description here

I am presently leaning towards iCloud, where no other application has the ability to read the data I save in private storage. It took me a minute to understand this technology, where each iOS application gets its own container.

A per-application container consists of

  • One public database they can read/write to
  • One private database per iCloud user

Generally speaking there is only one container per application, meaning that each iOS application is isolated from each other.

In addition, the developer can't directly read the contents of a user's iCloud database. This is a feature that DropBox OAuth, and other commodity storage doesn't have.

(not to mention, it's almost free)

enter image description here

That being said, I would still encrypt as Polynomial suggests, no matter where it goes.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .