Security Question: iOS Keychain

kop48 · September 2010

I posted this to the @1Password twitter, but was redirected to the support forum. Makes sense now that I think about it. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/tongue.gif' class='bbc_emoticon' alt=':P' />

Here goes:

How secure is the iOS (not 1P) keychain if the data gets dumped, or your phone is jailbroken, or booted via a custom kernel?

khad · September 2010

Hey kop48,

Sorry the link I gave you to our [url="http://help.agile.ws/1Password_touch/iOS_security_details.html"]iOS Security Details[/url] documentation was not sufficient. I don't have a full answer just yet, but I want you to know that I see this thread and am pondering a better reply. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />

jpgoldberg · September 2010

[quote name='kop48' timestamp='1285197857' post='11825']

I posted this to the @1Password twitter, but was redirected to the support forum. Makes sense now that I think about it. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/tongue.gif' class='bbc_emoticon' alt=':P' />

Here goes:

How secure is the iOS (not 1P) keychain if the data gets dumped, or your phone is jailbroken, or booted via a custom kernel?

[/quote]

For those just tuning in, the iOS keychain is where apps store various credentials. For example, it is where the Mail app on iOS stores your username and password for logging into mail. Or where a Twitter app will store your Twitter username and password.

1Password does not use the iOS keychain for your 1Password data. But we do use the iOS keychain to store the information needed for automatic Dropbox syncing, including your 1Password for iOS master password, your Dropbox login information and your Mac/PC master password. So iOS keychain security is obviously something that matters to us and to our users.

We do discuss the security of this in the second half of this document:

http://help.agile.ws/1Password_touch/how_secure_is_syncing.html

Apple's iOS keychain security is just terrific. Unfortunately, I haven't been able to find good documentation for it that is publicly available. If you are part of Apple's Developer program, then please watch session 209 from WWDC 2010. I can't do a better job of describing this other than that session.

The only difficulty that I see with the security of the iOS keychain is that it is deceptively simple from the user's perspective. It [i]appears[/i] to be much less secure than it actually is.

Each iOS devices come with a unique hardware based device key. Things encrypted using this cannot be decrypted without access to that device key. This, for the most part, means that decryption can't take place off of the device. If something is encrypted on a particular iPhone, it can't be decrypted "off-line". One important note is that the device key is only enabled if you set a passcode (typically four digits, but in iOS 4 you can make it longer) on your device.

Additionally, each app can be thought of as having its own iOS Keychain. Only the app that put the thing in the keychain is able to access it. Remember, each app is codesigned by Apple and that provides some public key infrastructure that allows the keychain require uncounterfeitable proof that the request is coming from the appropriate app. Even on a jail broken device, the ability to open something in an app's keychain requires a key from the app itself.

This is one of the reasons that apps can't share data on iOS. 1Password can't share data with the Dropbox app, but we have to build in (with support from Dropbox tools) our Dropbox syncing. If you have both 1Password Pro and 1Password iPhone on your iPhone (as I do because I test things with lots of different setups), these cannot share data with each other.

In effect what this means is that only the 1Password app is in a position to get things from its iOS keychain, and the app must be run on the device itself.

1Password on iOS, as you may or may not know, slows down after repeated failed entry of unlock code or master password. If you get your unlock code (iPhone and iPod touch) or master password (all iOS devices) wrong five times in a row, 1Password will make you wait a minute before trying again. After the sixth time, you need to wait 2 minutes, and so on. (Give it a try!)

Are these things breakable? Well anything can have bugs and flaws. There was a bug in the use of the device key in a previous version of iOS, that allowed the device to be browsed "off line". But security updates to iOS 3 quickly patched that bug. But even with that bug there was still the codesigning protections.

Again, the actual keys that are need to decrypt the information in the iOS keychain come from the device keys and the codesigning mechanism. So in principle, jailbreaking, dumping or whatever shouldn't affect that. Though a jailbreak or custom kernel could enable creating a dump, but only if you have given it the pass code for the device. In spring 2010 there was a malicious rootkit floating around that could attack iOS in this way. Again, this would allow getting past the device key (actually just relying on the user to enter the unlock code), but the app codesigning was still an additional layer of protection.

There is, however, one category of exception to all of this (actually introduced in iOS 4). Whether this is a feature or a bug has been hotly debated. Before iOS 4 it wasn't really possible to transfer your secure data from one iOS device to another through iTunes backups. This was because things were encrypted with the device key. Apple has now allowed for transferable backups. Those transferable backups are not encrypted with the device key. The issues about this are discussed in the Knowledge Base article Khad linked to.

http://help.agile.ws/1Password_touch/iOS_security_details.html

One really nice thing about iOS (particularly from our perspective) is that AES 128-bit encryption is done in hardware. There is basically no performance hit in performing encryption this way on iOS.

I hope that what I've written makes sense. I'm actually running a bit of a fever at the moment, so please forgive any rambling. But I just love talking about this stuff.

Cheers,

-j

kop48 · September 2010

[quote name='jpgoldberg' timestamp='1285298255' post='11947']

Again, the actual keys that are need to decrypt the information in the iOS keychain come from the device keys and the codesigning mechanism. So in principle, jailbreaking, dumping or whatever shouldn't affect that. Though a jailbreak or custom kernel could enable creating a dump, but only if you have given it the pass code for the device. In spring 2010 there was a malicious rootkit floating around that could attack iOS in this way. Again, this would allow getting past the device key (actually just relying on the user to enter the unlock code), but the app codesigning was still an additional layer of protection.

There is, however, one category of exception to all of this (actually introduced in iOS 4). Whether this is a feature or a bug has been hotly debated. Before iOS 4 it wasn't really possible to transfer your secure data from one iOS device to another through iTunes backups. This was because things were encrypted with the device key. Apple has now allowed for transferable backups. Those transferable backups are not encrypted with the device key. The issues about this are discussed in the Knowledge Base article Khad linked to.

http://help.agile.ws/1Password_touch/iOS_security_details.html

One really nice thing about iOS (particularly from our perspective) is that AES 128-bit encryption is done in hardware. There is basically no performance hit in performing encryption this way on iOS.

I hope that what I've written makes sense. I'm actually running a bit of a fever at the moment, so please forgive any rambling. But I just love talking about this stuff.

Cheers,

-j

[/quote]

Thanks for replying! My concern comes from the videos that came out 1 year ago detailing how easy it was to strip the passcode off a device and boot a custom ROM in order to trick the device into starting to decrypt the filesystem. I guess my question is: has this been fixed, and if not, is the keychain still secure?

jpgoldberg · September 2010

[quote name='kop48' timestamp='1285298938' post='11948']

Thanks for replying! My concern comes from the videos that came out 1 year ago detailing how easy it was to strip the passcode off a device and boot a custom ROM in order to trick the device into starting to decrypt the filesystem.

[/quote]

Good point.

[quote]I guess my question is: has this been fixed, and if not, is the keychain still secure?

[/quote]

The answers are "yes" and "yes". That is, this has been fixed (that is not to say that there may be new or other problems) and yes, that even in these circumstances, I believe that the iOS keychain remains well encrypted.

However, I have not read a detailed analysis of those attacks (yet). So my answer is based more on my theoretical understanding than on knowledge of the specific attack.

Please post links to things discussing these kinds of concerns as you find them. That way we can discuss specific threats as well as the more general theoretical ones. There may be cases where there is a real threat and we should would like to be able to advise users of any precautions that they should take.

Cheers,

-j

kop48 · September 2010

[quote name='jpgoldberg' timestamp='1285339859' post='11968']

The answers are "yes" and "yes". That is, this has been fixed (that is not to say that there may be new or other problems) and yes, that even in these circumstances, I believe that the iOS keychain remains well encrypted.

[/quote]

So, my understanding here is that the entire filesystem is encrypted, and it will only start decrypting when the passcode is supplied. On OS X, only the user's files are encrypted and the OS boots from files stored in the clear. Is this a similar process in iOS? Please feel free to link me to documentation rather than quote it all for me, I'm just having trouble finding out about it. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

brenty · September 2010

[quote name='kop48' timestamp='1285369072' post='11995']

So, my understanding here is that the entire filesystem is encrypted, and it will only start decrypting when the passcode is supplied. On OS X, only the user's files are encrypted and the OS boots from files stored in the clear.[/quote]

Thanks for starting this thread!

I was under the impression that OS X and iOS both have an unencrypted filesystem by default. On OS X, you can use FileVault to encrypt your home folder, but beyond that there isn't native support for encryption at the filesystem level. Of course, you can use encrypted disk images or 3rd party tools such as Knox and TrueCrypt to secure any or all of your data. Similarly, on iOS you can choose to enable the passcode lock, which I was lead to believe encrypts user data (mail, contacts, etc.) but not the whole filesystem.

So, in iOS each app has its own keychain, but this is where I'm unclear: is an individual app's data encrypted in a way that only allows that app access to it, or is it just permissions based? For example, in OS X I cannot simply access another user's data without permission, but thats just sort of a hoop to jump through if the data itself is unencrypted; OS X is merely wagging its finger and scolding me: 'Naughty, naughty.'

Perhaps given the limited nature of iOS and the locked-down, proprietary hardware, enforcing app quarantine is easy (contrasted with the open x86 platform and home-brewed hardware of all sorts.) In that case, encrypting the backup may protect against compromise of the system due to restoring from a modified backup, while a passcode lock prevents gaining access to the data on the device itself.

However, while I haven't been able to find a great deal of solid info on iOS security, I did find this [url="http://www.wired.com/gadgetlab/2009/07/iphone-encryption/"]article from Wired[/url]. It's over a year old, so hopefully these issues have been addressed. I really need to do some more digging...after I get some rest.

Actually, you guys probably already covered all of this; I just need to finish reading it all.

kop48 · September 2010

[quote name='brenty (toromei)' timestamp='1285393195' post='12012']

Thanks for starting this thread!

I was under the impression that OS X and iOS both have an unencrypted filesystem by default. On OS X, you can use FileVault to encrypt your home folder, but beyond that there isn't native support for encryption at the filesystem level. Of course, you can use encrypted disk images or 3rd party tools such as Knox and TrueCrypt to secure any or all of your data. Similarly, on iOS you can choose to enable the passcode lock, which I was lead to believe encrypts user data (mail, contacts, etc.) but not the whole filesystem.

So, in iOS each app has its own keychain, but this is where I'm unclear: is an individual app's data encrypted in a way that only allows that app access to it, or is it just permissions based? For example, in OS X I cannot simply access another user's data without permission, but thats just sort of a hoop to jump through if the data itself is unencrypted; OS X is merely wagging its finger and scolding me: 'Naughty, naughty.'

[/quote]

The keychain is encrypted, not just permissions-based locks.

What I'm concerned about is my personal data being easily accessible if someone has physical access to the device.

brenty · September 2010

[quote name='kop48' timestamp='1285497671' post='12048']

The keychain is encrypted, not just permissions-based locks.

What I'm concerned about is my personal data being easily accessible if someone has physical access to the device.

[/quote]

Aye. After doing some more reading, it sounds like in order to get access to everything in the filesystem you would need root privileges. And in order to accomplish that, you would need to jailbreak the device. Of course, if your device is locked with a passcode, it is inaccessible without it. I would say that precludes easy access. Even if you have a rogue app that wants to give your data away, aside from some limited hooks into Contacts, Mail, and similar services, it only has access to its own sandboxed segment of the filesystem. Pretty cool.

I'm glad I took the time to brush up on some of this. Apparently, the option to use complex passwords (more than just a simple, 4 digit pin) was added in iOS4, and I missed it. It looks like the takeaway is: protect your data by using only trusted apps, and protect your phone by locking and limiting physical access. I guess someone could rip out the NAND and try to decrypt the data. Too bad you need MobileMe to do a remote wipe. Then again, if they remove the SIM, that wouldn't work anyway.

jpgoldberg · September 2010

[quote name='brenty (toromei)' timestamp='1285574840' post='12085']

Aye. After doing some more reading, it sounds like in order to get access to everything in the filesystem you would need root privileges.[/quote]

Thanks for your research Brenty.

As kop48 pointed out root is still only getting you access to the encrypted data in most cases. It is not able to decrypt that data. iOS is [i]not[/i] like OS X. In iOS, most data is also encrypted as well as just protected by Unix file permissions. So getting root privileges doesn't really get you very far for most data.

[quote]Even if you have a rogue app that wants to give your data away, aside from some limited hooks into Contacts, Mail, and similar services, it only has access to its own sandboxed segment of the filesystem. Pretty cool.[/quote]

Spot on! Even on a rooted/jailbroken device, a rogue app can't decrypt the data files of another app. And of course, 1Password uses its own encryption of your data in addition to what is built into iOS.

[quote]

I'm glad I took the time to brush up on some of this. Apparently, the option to use complex passwords (more than just a simple, 4 digit pin) was added in iOS4, and I missed it.[/quote]

For those not aware of this, go to [i]Settings > General > Passcode Lock[/i] and turn off "Simple Passcode". It's interesting that Apple has framed this as simple (4-digit) passcodes as being something that is specifically turned "on." Although the simple passcodes remain the default, they are expressing things in such a way as to make it not the default conceptually.

[quote]It looks like the takeaway is: protect your data by using only trusted apps, and protect your phone by locking and limiting physical access. I guess someone could rip out the NAND and try to decrypt the data.[/quote]

I haven't yet had to opportunity to hunt down the research on the feasibility of this. But look at it this way. If a thief has your phone and has a choice between destroying the phone in an uncertain attempt to get your data or just wiping your phone so that they can resell it, which is more likely?

[quote]Too bad you need MobileMe to do a remote wipe. Then again, if they remove the SIM, that wouldn't work anyway.

[/quote]

That is, indeed, a pity. I personally do use MobileMe, but I'm not relying on it to help protect me from a reasonably clever thief. But 1Password's encryption along with the iOS data security model do make me fully confident to have my 1Password data on my phone.

Again, thanks all for this discussion.

Cheers,

-j

Yossi Rozolyo · February 2011

There is an article which talks about replacing the keychains while in dfu mode using quickpwn - http://dl.packetstormsecurity.net/cellular_telephony/apple/iphone-defeat.pdf so if you says that the files are encrypted, this method can't work... And according to what you are saying, the keychain-2.db file that I can see through iFile, is filled in with iFile passwords?

khad · February 2011

Welcome to the forums, Yossi! Thanks for sharing that document. We will take a thorough look at it.

jpgoldberg · February 2011

[quote name='Yossi Rozolyo' timestamp='1296755952' post='19994']

There is an article which talks about replacing the keychains while in dfu mode using quickpwn - http://dl.packetstormsecurity.net/cellular_telephony/apple/iphone-defeat.pdf so if you says that the files are encrypted, this method can't work... And according to what you are saying, the keychain-2.db file that I can see through iFile, is filled in with iFile passwords?

[/quote]

Hi Yossi,

Thanks for that link. It describes an attack against iPhones running iOS 2.2. I can't be certain that a similar attack wouldn't work against iOS 3.2, but it most certainly would not work against iOS 4. The difference is how iOS makes use of the device encryption key.

You are correct that not everything on iOS is encrypted. It is not an encrypted file system in the sense that we might think of file system encryption on a desktop computer. Instead each apps gets to choose what files it uses are to be encrypted. (This is independent of the encryption which 1Password provides within our data file).

When an app creates a file it can say one of three things (well actually six).

[list=1]

[*] Don't bother encrypting this file

[*] Encrypt the file, but have its key available as soon as the device is unlocked.

[*] Only decrypt the file when I (this app) says so.

[/list]

The same three things are true of things stored within an iOS keychain. In practice, option 1 is almost never used.

Now I said there were actually six options instead of three. For each one of those, the app can say that the data should not be included in encrypted (transferable) backups. 1Password, for example, does not allow the data it stores in the iOS keychain (the credentials and passwords needed for automating Dropbox syncing) to be included in transferable backups. The down side of this is that if you wish to transfer all of your settings from one iPhone to another you will have to manually re-enter those passwords. The up side is that this eliminates a particular line of attack against the encrypted backups.

It should be noted that all backups are encrypted. Normal backups are encrypted using, among other things, the unique hardware device key. So those backups can only be decrypted on the device. But the "password protected" backups don't use the device key. This allows the data to be installed on another device. That is, the normal backup is actually better encrypted than the "password protected" backup.

Overall, though, I agree that with jailbreaking we should expect that it will be possible for the bad guys to get past the unlock code for the device. But I do not see anything what would allow access to any of the data that 1Password stores on your iOS device.

Thanks again for paying attention to these things. And also welcome to the forums.

Cheers,

-j

[Deleted User] · February 2011

[quote name='jpgoldberg' timestamp='1296844501' post='20054']

It should be noted that all backups are encrypted. Normal backups are encrypted using, among other things, the unique hardware device key. So those backups can only be decrypted on the device. But the "password protected" backups don't use the device key. This allows the data to be installed on another device. That is, the normal backup is actually better encrypted than the "password protected" backup.[/quote]

Does that mean a password protected backup will allow more thorough data migration from one device to another?

khad · February 2011

[quote]Does that mean a password protected backup will allow more thorough data migration from one device to another?[/quote]

Not in the case of 1Password (or other apps which exclude their keychain data from such a backup). As Jeff mentioned:

[quote][1Password] does not allow the data it stores in the iOS keychain (the credentials and passwords needed for automating Dropbox syncing) to be included in transferable backups. The down side of this is that if you wish to transfer all of your settings from one iPhone to another you will have to manually re-enter those passwords. The up side is that this eliminates a particular line of attack against the encrypted backups.[/quote]

[Deleted User] · February 2011

It's still unclear what advantages there would be, if any, to having a password protected backup of my iPod touch instead of a non-pw protected one when migrating to an iPhone 3GS. But I'll figure out that and other issues once I've reached the point of actually doing the migration. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

khad · February 2011

I hate to do it to you, sjk, but I think a reread of the link I first posted at the beginning of this thread might be helpful. <img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/skype_smile.png' class='bbc_emoticon' alt=':-)' />

[url="http://help.agile.ws/1Password_touch/iOS_security_details.html"]iOS Security Details[/url]

I have to admit that it can be very confusing. Even [url="http://support.apple.com/kb/ht1766"]Apple's own documentation on the subject[/url] is cryptic. (No pun intended.)

For me, this is also exacerbated by the fact that I have not migrated from an iOS 4 device yet. My only personal experience with iOS 4 migration has been migrating from iOS 3 to iOS 4.

[Deleted User] · February 2011

Thanks for helping narrow my focus of research about this… why hate doing that? And, in my defense, I'd only noticed/read this topic starting with Jeff's latest reply and didn't feel like backtracking.

<img src='http://forum.agile.ws/public/style_emoticons/<#EMO_DIR#>/smile.gif' class='bbc_emoticon' alt=':)' />

Yossi Rozolyo · February 2011

I understand that not all of the file are encrypted by the device key, but still if someone, let's say saurik(Jay Freeman - the creator of cydia, winterboard and a lot more apps for a jailbroken device) will want to have all password of a jailbroken device, he can make a -1 level rootkit or even a custom kernel and steal the keychains file and we know that if he has a rootkit or a custom kernel, he will gain access to the device key or even he can hook the unlock function and gain access to all the keychain-2.db passwords. This kind of virus won't be difficult to create if the creator is a guy that usually makes apps for cydia because he knows the system and the only thing he has to do is to open the file com.apple.springboard in IDAPro and extract the device key calculations.

I think that you need to encrypt the 1Password's passwords in a separate file with a different algorithm that would take the hacker hours to brute-force the encryption. This kind of encryption is good because:

1. The hacker won't ever think of uploading the 1Password's passwords in addition to the keychains file. He will just upload the keychains-2.db files and the device key.

2. Even if the hacker uploads the 1Password's passwords file, he won't spend hours on brute-forcing the passwords.

I hope you understood what I said, and since I don't speak English very well, just ignore my errors.

jpgoldberg · February 2011

Yossi, I think I see what you are getting at.

The most careful analysis of iPhone vulnerabilities that I am aware of (by Cedric Halbronn and Jean Sigwald) says that a rooted iPhone set up with a malicious operating system would not be able to get at data stored initially in iOS 4 by applications in the iOS keychain unless either

(1) The device had no lock on it, OR

(2) The application allows the data to be read universally (for example, Contacts fall into that category)

However, for iOS 3, a jailbreak of the phone could get at application iOS data.

Of course once a device or computer has been rooted, if the user enters the relevant unlock codes then the data would be available to an attacker. So if your phone is rooted maliciously without you knowing about it and you continue to use it than your data is vulnerable. Of course this is true of any system.

I hope this helps.

Cheers,

-j

Luftwaffle · February 2011

Just reading this [url="http://www.sit.fraunhofer.de/en/presse/Lost_iPhone.jsp"]press release[/url] from the Fraunhofer Institute (the guys that invented MP3). Here someone demonstrates how to gain access to the keychain content without prior knowledge of the device password (iOS 4). It takes less than six minutes. So if an iPhone is lost or stolen, all data on it is compromised.

Question I have is how can I prevent 1Password to store my master password in Apples iOS keychain? I don't use dropbox or any other automated function at all. The main reason I bought 1Password was to be independent from Apple's keychain and I recall earlier advertisement where Agile specifically mentions that they (you) are not using Apples encryption but your own scheme instead. But if the master password is stored in Apple's keychain, then even the best encryption scheme for 1Password would be pretty useless.

The same is valid for the Mac as well, where I store my most sensitive data in 1Password in the hope that it cannot be compromised if someone gains access to that machine.

Any comments would be greatly appreciated.

Fooligan · February 2011

[quote name='jpgoldberg' timestamp='1285298255' post='11947']

1Password does not use the iOS keychain for your 1Password data. But we do use the iOS keychain to store the information needed for automatic Dropbox syncing, including your 1Password for iOS master password, your Dropbox login information and your Mac/PC master password. So iOS keychain security is obviously something that matters to us and to our users.

[/quote]

I recently read [url="http://goo.gl/e1Uqi"]this on Macworld[/url] (mentioned above as well). This weakness in conjunction with what -J mentioned a while ago about how 1Password uses the iPhone keychain seems like there is some vulnerability. I am not that concerned since the attacker would have to be educated on this technique and at the same time desire to maliciously attack a specific person's phone. For the average 1P user, the probability is minimal since the value for the attacker is in the hardware and not the data on the phone.

But, this does seem to present a 1P risk. Just a thought.

jpgoldberg · February 2011

Hi Luftwaffle and Fooligan,

Thanks raising this. Before I get into the gory details let me give the short answer:

When we look at the actual research paper instead of press reports (which contain serious errors) we find that your 1Password data, including information stored by 1Password in the iOS keychain, remains protected. The crucial thing to keep in mind, which the press reports neglect, is that only [i]some[/i] keychain can be exposed this way. The protection class that 1Password uses to store keychain data is [i]not[/i] vulnerable to this attack.

The gory details follow.

[quote name='Luftwaffle' timestamp='1297348666' post='20357']

Just reading this [url="http://www.sit.fraunhofer.de/en/presse/Lost_iPhone.jsp"]press release[/url] from the Fraunhofer Institute (the guys that invented MP3). Here someone demonstrates how to gain access to the keychain content without prior knowledge of the device password (iOS 4). It takes less than six minutes.[/quote]

I have just read through and studied their [url="http://www.sit.fraunhofer.de/en/Images/sc_iPhone%20Passwords_tcm502-80443.pdf"]full paper (PDF)[/url] which does demonstrate how quick and easy it is for an attacker to get at [i]some[/i] passwords stored in the iOS keychain. Their paper is a great summery of what is already known theoretically as well as describing how easy it is to get at some secret data.

[quote]So if an iPhone is lost or stolen, all data on it is compromised.[/quote]

That isn't quite true. If an iPhone is captured only [i]some[/i] of the data on it would be available to an attacker, but not all. Quoting from page 6 of their paper:

[quote]

Secrets within other protection classes, such as passwords for websites, could

not be revealed in our lost device scenario. In our proof of concept implementation, these secrets — marked "protected" in Table 1 — were available to the

script only after entering the passcode to unlock the device, which by assumption should not be possible for an attacker.[/quote]

The material that 1Password stores in an iOS keychain very much belongs to these "other protection classes." We use the most restrictive protection class that iOS has to offer.

The keychain material that is available though this attack is stuff that the phone needs when it is on, but locked. That is mostly networking passwords (such as WiFi passwords, VPN passwords, MobileMe tokens) are available. When an application stores something in an iOS keychain, there are 3 X 2 different settings that can be used to describe its protection class:

[list=1]

[*] kSecAttrAccessibleAlways

[*] kSecAttrAccessibleAfterFirstUnlock

[*] kSecAttrAccessibleWhenUnlocked

[/list]

and

[list=A]

[*] kSecAttrAccessibleAlwaysThisDeviceOnly

[*] kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly

[*] kSecAttrAccessibleWhenUnlockedThisDeviceOnly

[/list]

You can read more about what these mean in Apple's [url="http://developer.apple.com/library/ios/#DOCUMENTATION/Security/Reference/keychainservices/Reference/reference.html"]Keychain Services Reference[/url]

The kinds of things that can be gotten to via the jail breaking technique are those secured with 1 and A above. When 1Password stores material in the iOS keychain, it uses C from the above. This protects data data from the kinds of attacks described in this thread. The use of "...ThisDeviceOnly" prevents any attacks based on device backups used to migrate data from one iOS device to another.

[quote]

Question I have is how can I prevent 1Password to store my master password in Apples iOS keychain? I don't use dropbox or any other automated function at all.

[/quote]

I hope that I reassured you that what 1Password stores in the iOS keychain remains protected despite reports of various sorts of attacks. However, if you wish to just sync manually then after syncing with Dropbox, go to Settings > Sync > Dropbox > Account and tap "Reset."

[quote]

The main reason I bought 1Password was to be independent from Apple's keychain and I recall earlier advertisement where Agile specifically mentions that they (you) are not using Apples encryption but your own scheme instead. But if the master password is stored in Apple's keychain, then even the best encryption scheme for 1Password would be pretty useless.[/quote]

This remains true if you do not wish to have automatic syncing of your 1Password data. For automatic syncing, 1Password will need access to various credentials. By using the "Reset" mechanism I described, you can sync manually. Each time you sync, you will need to enter your Dropbox password and your master password for the data stored on Dropbox.

[quote]

The same is valid for the Mac as well, where I store my most sensitive data in 1Password in the hope that it cannot be compromised if someone gains access to that machine.[/quote]

From the very beginning, we designed our data format to protect you against sophisticated attacks in case your machine was stolen. You can read more about the kinds of security our data format provides here:

http://help.agile.ws/1Password3/cloud_storage_security.html

[quote name='Fooligan']

I recently read this on Macworld (mentioned above as well). This weakness in conjunction with what -J mentioned a while ago about how 1Password uses the iPhone keychain seems like there is some vulnerability.

[/quote]

I hope that I have clarified above that this does not represent a vulnerability to any of your 1Password data.

[quote]

I am not that concerned since the attacker would have to be educated on this technique and at the same time desire to maliciously attack a specific person's phone. For the average 1P user, the probability is minimal since the value for the attacker is in the hardware and not the data on the phone.[/quote]

You are correct that the vast majority of thieves will wipe the devices quickly instead of trying to launch a sophisticated attack. But we work to protect your data against the most sophisticated attacks. We need to realize that what takes skill and knowledge today can always be implemented in a kit that a trained monkey could use.

So although I agree with you that it is unlikely that anyone would even try to get at your 1Password data on a stolen phone, we do need to protect you against sophisticated attacks, not just casual ones.

I hope that you will see that in our design, we have worked to anticipate such attacks.

Again, thank you all for giving even more of an excuse to boast about what we do to protect your data.

Cheers,

-j

Fooligan · February 2011

-J,

Thanks for the in depth explanation. I now have very high confidence in 1P security knowing that. I was confident before having that information, but wasn't sure on the "gory details". Especially if you compare it against not using 1P! That is a bad situation no matter how you look at it.

jpgoldberg · February 2011

I've taken some of what I described above and put it into a blog post here:

http://blog.agile.ws/lost-iphone-safe-passwords/

[quote name='Fooligan' timestamp='1297365969' post='20372']

I now have very high confidence in 1P security knowing that. I was confident before having that information, but wasn't sure on the "gory details". [/quote]

Everyone who knows me learns that I love discussing the gory details of security. Typically at far greater length than most people want to know. But on days like today, I can freely indulge this passion.

[quote]

Especially if you compare it against not using 1P! That is a bad situation no matter how you look at it.

[/quote]

The concern as I see it is that MobileMe and Exchange passwords can get exposed though these kinds of attacks (even though your 1Password data are safe). Once someone can log into your primary email account, they can go through password reset procedures at most sites. So if your iPhone is stolen, change your MobileMe or Exchange passwords right away.

Cheers,

-j

Security Question: iOS Keychain

Comments