Security bods disclose lock bypass bug in iOS

I'm sure the encryption is plenty strong enough

I don't know about iOS specifically, but generally the first unlock after booting decrypts the disk encryption keys and loads them into memory where they stay until the device is shutdown again. Google "data at rest" vs "data in use".

Read the iOS security doc

It is 60 pages long but it is pretty easy to search for what you are looking for to find the details on this.

There are multiple encryption keys at use inside the iPhone, not just a single one. Everything in the device is encrypted by the device key, but as you say an operational phone needs access to a lot of data while running so the key for that is available to it even when locked. More sensitive information is encrypted a second time at the file level, if it has a protection class higher than "protection none". Those keys are inaccessible to the phone while locked.

Things like contacts and photos are protected by that iOS "protection none" data class, meaning there is not a second level of encryption. The reason for that is rather obvious - i.e. you receive text messages while the phone is locked, it needs to be able to correlate the phone number of an SMS message to a name if you have it configured the show the recipient's name. Likewise that means messages are in protection 'none' since it can be configured to show the message itself, and allow you to reply. Photos similarly need to be unprotected to support the option of allowing quick access to the camera from the lock screen.

There are probably more secure ways of doing this. If they kept all those things in an encrypted file class they could increase security and make such lock screen blunders a thing of the past. To wit, use a separate DB with just the number -> name mapping to support the option of showing who a text is from to allow keeping contacts in a protected file class. Use a separate DB of "messages received since phone was locked" that they could integrate into the proper message store when the phone is unlocked, then they could keep that main message store in a protected file class. Keep a separate DB of "photos taken since phone was locked", and they could similarly keep the main photos store in a protected file class.

I imagine they'll be taking a closer look at moving more things into a protected class to tighten the protections not only around lock screen issues like this, but also because the FBI case seems to have them riled up to redouble their efforts to make the iPhone as secure as possible.

"If there's a bypass that will grant access to data without entering the passcode, then the encryption isn't as strong as it's claimed to be, is it?"

There's a difference between the strength of encryption - algorithms & key lengths - and the effectiveness of its deployment.

The more directly a system is aimed at consumers the more likely it is that deployment will be tailored to the convenience of the user rather than the inconvenience of the attacker.

Re: Every patch contains a list of bugs that are exploitable on a unpatched device.

That's the problem with disclosing the security content in an update. If you say "fixed a security bug" then you don't have any way of knowing if OS version x.y fixes the security hole you heard reprted last week. If you say "fixed security hole that allowed access to contacts from the lock screen if you have Twitter configured" that may provide enough information to let someone figure out how to exploit it.

You're screwed either way to some extent, so you have to choose your path. I think Apple prefers to err on the side of disclosure of fixed bugs, and rely on people installing updates in a timely manner. The problem is, blunders like the issues that affected some iOS 9.3 updates make people gun shy of installing patches quickly. I just don't understand how things like that aren't caught in beta, obviously the developers who do the bulk of the beta testing aren't using devices in the same way as end users.

If I was Apple I'd institute two changes. One, I'd release the security content details for a new OS a week after its release, rather than the day of its release. Two, I'd have a new OS roll out in stages. Users could change a setting to request 'early access' to new OS versions. If you configured that setting you'd have to install the new OS in a timely manner or you'd be dropped from the 'early access' group. That would be rolled out in stages, say 0.01% of all users on day one, 0.1% on day two, the remainder of the early access group on day four and everyone else on day six. If problems were found that were somehow missed by the beta stage, they'd be caught by the early access volunteers, hopefully quickly before very many were affected. The seven day waiting period for security content would allow everyone not in the early access group 48 hours to install it on day 6 or 7 before the security content was made public, possibly providing clues on exploiting bugs in older versions.

Re: Uses Siri?

Yes, it's still a bit of a list. Kill Siri, change the ad ID every so often and kill the frequent location tracker. Not because I don't like the idea of it, but because I don't feel I have control over what has access to it.

Re: Blast from the past

You used to be able to do something very similar in OS X too, and get yourself a handy root shell.

Re: Apparently it is fixed

Not panicky, but bloody irritated as something like that just shouldn't be in need of fixing in the first place. Okay, shit happens and there will always be bugs, but this is like locking the front door and leaving the key under a flimsy doormat. In a bad neighbourhood.

Re: Apparently it is fixed

Should they even be able to do that in a secure design?

What happens if you put it in airplane mode?

Re: Apparently it is fixed

Yes, don't panic, after all every interaction with your device is sent and processed somewhere else...

Re: Apparently it is fixed

"Apple are saying that the problem has been fixed"

You cannot be Sirious.

Re: Server Side fix

It needed siri so a connection was needed