![]() Personally this is the option I use, since my keychain data is backed up elsewhere, so I don't mind if I loose access to iCloud Keychain. The device will put up an alert asking for permission before sharing the key. With this option whenever you setup a new device it will need to be able to establish a peer-to-peer connection to one of your other existing devices over the internet, and they will share the AES key that way. They say this means your data will not be uploaded to the cloud but what it really means is the AES key will never be uploaded to the cloud. You also have the option of not providing a passcode or pin. Presumably they use pbkdf2 - that's what they use everywhere else. I don't think there have been any official statements how the key is derived. They can't be doing any fancy hardware key derivation so I think a 4 digit pin is definitely a bad idea. However the aes key for the data is only stored on the server if you provide a 4 digit pin or password to "lock" your iCloud Keychain. With all three choices, your encrypted keychain data is stored on apple's server. The description of these options does not perfectly match what it seems to actually do, they've simplified it to the point of being misleading. ICloud also uses aes but there are a couple of options for how the key is stored. This second keychain also isn't synced via iCloud, I manually copy the file around. Personally I have two keychains, my login keychain uses the login password (which is average strength) and I have a second keychain with a much stronger/painful to type password for more sensitive data. You can also manually change it to be a different/stronger password. On OS X the keychain just runs a key derivation function (probably pbkdf2 with an appropriate number of rounds) on the user's login password. I'm not sure how touch id works, I suspect your passcode/password is encrypted using a key that is stored in the A7's "secure enclave" which is just a marketing term for ARM's equivalent of intel's trusted platform module, although arm's implementation is much newer (the A7 is the first chip to implement it AFAIK) and looks to be more robust than intel's technology. Maybe do a full shutdown if you're worried someone might have physical access to your phone (perhaps someone can edit this section if they know more about it than I do?). I haven't looked into it properly but I'm a bit concerned there might be some access to the aes key even when the phone is locked. Features like bluetooth low energy and push notifications make me a bit nervous as to how strong this is, since clearly a lot can be done while the phone is locked. When the screen is off (and after whatever delay you have set in settings) the aes key for keychain (and other things) is supposed to be deleted from RAM, forcing the pbkdf2 chipset to be used again to access the key. The pbkdf2 chipset is also deliberately slow to try and increase the strength of a four digit passcode, but it's still not really good enough and I would suggest using a password instead of a passcode if you really want to be safe. This ensures it is impossible to access the aes key except by providing the passcode to the actual iOS device that holds the keychain. My understanding is the aes key is derived by running the user's passcode or password or through a custom pbkdf2 hardware chipset, that salts the password with a bit of ROM that's unique to every device and only the pbkdf2 chipset can read it. IOS stores keychain data using aes, the question is how is the key generated? They will go for the weakest one, so you need to get all four right depending how sensitive your keychain contents are. I'm going to break it down into parts, because there are four different storage mechanisms for keychain, providing four attack options to any hacker.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |