iPhone encryption and your passcode
I've been following this at work a bit and Bruce Schneier recently linked to it on his blog. This post is mostly my own notes about how the passcode on my phone protects some of my data and how well it does that. But I've tried to write it up so it's reasonably consumable.
ElcomSoft has a suite of tools for performing forensic analysis on devices running iOS 4 and they've recently revealed some improvements, especially in the area of key recovery. Some encrypted files on the device, like email messages, require that they have the user's passcode. ElcomSoft has some technical details on how the encryption works, but a brief overview is probably helpful here.
The iOS device has some encryption keys stored internally that are not written off the device, even for syncing or backups. There are keys derived from the unique device key embedded in the hardware. There is a key derived from the user's passcode and the unique device key. There are escrow keys derived from escrow pairing records and the unique device key. These are used for device syncing with trusted computers so that the user's passcode isn't needed every time files are accessed via iTunes. Finally, there are erasable keys kept in common storage. These are part of the keychain that stores application secrets like account details, usernames, and passwords. Developers can control whether these are stored with backups or only kept on the device when developing their apps.
Using the escrow keys and the unique device keys, it's possible to obtain access to some files without knowing the passcode. However, full access still requires the passcode in order to decrypt everything.
Their approach allows brute-forcing the passcode, but they access this via some direct interface, bypassing the API that would trigger a device wipe. This also means the delays inserted by the front panel don't apply and the only limitation is the speed of the device. They claim to be able to break a 4 digit passcode in 40 minutes maximum, 20 minutes on average. That's 250 tries a minute. Just over 4 tries a second. Some anecdotal evidence from users of the passcode breaking tool suggests that, at least for non-law enforcement versions of the product, they will stop processing after some period of time, but this is obviously a configurable setting in the code if nowhere else. For the rest of this discussion, I'll assume they can keep guessing as long as their software, the device, and the universe itself keep functioning.
If you stick to a 4 character code, but make it lower case alphanumeric (36 characters), then there are 1,679,616 possibilities. Maximum time to crack this is 6,718 minutes (or just over 4.5 days). The average time to crack would be just over 2 days.
If you choose a 4 character code, lower case alphanumeric with symbols (no mixed case due to usability), then complexity is based on which punctuation this adds to the set. On the iPhone, this is -/:;()$&@".,?!' if you don't go to the next screen of keys. That's 15 additional symbols, not the full 32 you'd get with a US keyboard. This is a total of 51 possible characters or a namespace of 6,765,201. Maximum time to crack this is 27,060 minutes (or almost 19 days, less than 3 weeks). That means over a week on average. A nice increase over 2 days, but not enough to feel comfortable with.
Let's suppose you're completely paranoid. The iPhone supports 35 punctuation marks (or mine does). Our total character set is now 97. If we use an 8 character passcode, our namespace is 7,837,433,594,376,961. We can crack this in 31,349,734,377,508 minutes or 59,645,613 years. About 30 million years on average. That's more like it. But I'd be happy with a middle ground.
I'm assuming this attack gets better as iPhone hardware gets faster -- the limiting factor is how many attempts it will let you make. So suppose I'd like it to take them at least a year on current hardware. There are 525,600 minutes in a 365-day year. This is 131,400,000 guesses:
Most of my reason for going to this level of detail isn't that I'm looking to defeat law enforcement efforts to scan my phone. Rather, my assumption is that ElcomSoft's approach is dependent on design flaws and vulnerabilities in iOS's current device protection. This means I expect that people who are not law enforcement to be able to exploit the same flaws and vulnerabilities.
Today, this would only be the result of a targeted attack. The techniques require detailed inside knowledge of the iOS architecture and at least physical possession of the device. If I forget my phone somewhere or it gets stolen, I'm probably not at any risk of someone using these techniques. Frankly, if you have the device set to wipe after 10 tries, a 4 digit passcode is more than enough (just don't pick sequential or repeating digits, like 1234 or 1111).
In another year or two years, though, ElcomSoft's tools may have been stolen, leaked, or duplicated. When that happens, the risk goes up that someone taking my phone may know how to get the data out or may know someone who does. I think there's still some question whether the device itself is more valuable than the data on it, but some basic protection (a 5 character code isn't that bad) seems cheap to me.
ElcomSoft has a suite of tools for performing forensic analysis on devices running iOS 4 and they've recently revealed some improvements, especially in the area of key recovery. Some encrypted files on the device, like email messages, require that they have the user's passcode. ElcomSoft has some technical details on how the encryption works, but a brief overview is probably helpful here.
The iOS device has some encryption keys stored internally that are not written off the device, even for syncing or backups. There are keys derived from the unique device key embedded in the hardware. There is a key derived from the user's passcode and the unique device key. There are escrow keys derived from escrow pairing records and the unique device key. These are used for device syncing with trusted computers so that the user's passcode isn't needed every time files are accessed via iTunes. Finally, there are erasable keys kept in common storage. These are part of the keychain that stores application secrets like account details, usernames, and passwords. Developers can control whether these are stored with backups or only kept on the device when developing their apps.
Using the escrow keys and the unique device keys, it's possible to obtain access to some files without knowing the passcode. However, full access still requires the passcode in order to decrypt everything.
Their approach allows brute-forcing the passcode, but they access this via some direct interface, bypassing the API that would trigger a device wipe. This also means the delays inserted by the front panel don't apply and the only limitation is the speed of the device. They claim to be able to break a 4 digit passcode in 40 minutes maximum, 20 minutes on average. That's 250 tries a minute. Just over 4 tries a second. Some anecdotal evidence from users of the passcode breaking tool suggests that, at least for non-law enforcement versions of the product, they will stop processing after some period of time, but this is obviously a configurable setting in the code if nowhere else. For the rest of this discussion, I'll assume they can keep guessing as long as their software, the device, and the universe itself keep functioning.
If you stick to a 4 character code, but make it lower case alphanumeric (36 characters), then there are 1,679,616 possibilities. Maximum time to crack this is 6,718 minutes (or just over 4.5 days). The average time to crack would be just over 2 days.
If you choose a 4 character code, lower case alphanumeric with symbols (no mixed case due to usability), then complexity is based on which punctuation this adds to the set. On the iPhone, this is -/:;()$&@".,?!' if you don't go to the next screen of keys. That's 15 additional symbols, not the full 32 you'd get with a US keyboard. This is a total of 51 possible characters or a namespace of 6,765,201. Maximum time to crack this is 27,060 minutes (or almost 19 days, less than 3 weeks). That means over a week on average. A nice increase over 2 days, but not enough to feel comfortable with.
Let's suppose you're completely paranoid. The iPhone supports 35 punctuation marks (or mine does). Our total character set is now 97. If we use an 8 character passcode, our namespace is 7,837,433,594,376,961. We can crack this in 31,349,734,377,508 minutes or 59,645,613 years. About 30 million years on average. That's more like it. But I'd be happy with a middle ground.
I'm assuming this attack gets better as iPhone hardware gets faster -- the limiting factor is how many attempts it will let you make. So suppose I'd like it to take them at least a year on current hardware. There are 525,600 minutes in a 365-day year. This is 131,400,000 guesses:
- a 9 digit code (10x stronger than we need),
- a 6 character alphanumeric, lower case code (20x stronger than we need),
- a 5 character alphanumeric, lower case code with limited punctuation (ie. our 51 character set above -- about 3x stronger than we need), or
- a 5 character code using the full set (about 80x stronger than we need).
Most of my reason for going to this level of detail isn't that I'm looking to defeat law enforcement efforts to scan my phone. Rather, my assumption is that ElcomSoft's approach is dependent on design flaws and vulnerabilities in iOS's current device protection. This means I expect that people who are not law enforcement to be able to exploit the same flaws and vulnerabilities.
Today, this would only be the result of a targeted attack. The techniques require detailed inside knowledge of the iOS architecture and at least physical possession of the device. If I forget my phone somewhere or it gets stolen, I'm probably not at any risk of someone using these techniques. Frankly, if you have the device set to wipe after 10 tries, a 4 digit passcode is more than enough (just don't pick sequential or repeating digits, like 1234 or 1111).
In another year or two years, though, ElcomSoft's tools may have been stolen, leaked, or duplicated. When that happens, the risk goes up that someone taking my phone may know how to get the data out or may know someone who does. I think there's still some question whether the device itself is more valuable than the data on it, but some basic protection (a 5 character code isn't that bad) seems cheap to me.