Judge Tells Apple To Help FBI Access San Bernardino Shooters' iPhone (engadget.com)

An anonymous reader writes: After a couple shot 14 people in San Bernardino, CA before being killed themselves on December 2nd, the authorities recovered a locked iPhone. Since then, the FBI has complained it is unable to break the device's encryption, in a case that it has implied supports its desire for tech companies to make sure it can always have a way in. Today the Associated Press reports that a US magistrate judge has directed Apple to help the FBI find a way in. According to NBC News, the model in question is an iPhone 5c, but Apple has said that at least as of iOS 8 it does not have a way to bypass the passcode on a locked phone.

Comments

Huh?

[Lunix Nutcase]

There's no word on exactly which model of iPhone was recovered

Huh? The article clearly states a model:

According to NBC News, the model in question is an iPhone 5c

Re:Huh?

[adamstew]

You mistake an iPhone's unlock code with the iPhone's encryption key. the iPhones do typically use a 4-6 digit pin as an unlock code. The user also has the ability to create a full alphanumeric password for the unlock code as well. However, that is simply the code that's used to unlock the actual full encryption key that is stored within dedicated crypto hardware. Apple uses a dedicated chip to store and process the encryption. They call this the Secure Enclave. The secure enclave stores a full 256-bit AES encryption key.

Within the secure enclave itself, you have the device's Unique ID (UID) . The only place this information is stored is within the secure enclave. It can't be queried or accessed from any other part of the device or OS. Within the phone's processor you also have the device's Group ID (GID). Both of these numbers combine to create 1/2 of the encryption key. These are numbers that are burned into the silicon, aren't accessible outside of the chips themselves, and aren't recorded anywhere once they are burned into the silicon. Apple doesn't keep records of these numbers. Since these two different pieces of hardware combine together to make 1/2 of the encryption key, you can't separate the secure enclave from it's paired processor.

The second half of the encryption key is generated using a random number generator chip. It creates entropy using the various sensors on the iPhone itself during boot (microphone, accelerometer, camera, etc.) This part of the key is stored within the Secure Enclave as well, where it resides and doesn't leave. This storage is tamper resistant and can't be accessed outside of the encryption system. Even if the UID and GID components of the encryption key are compromised on Apple's end, it still wouldn't be possible to decrypt an iPhone since that's only 1/2 of the key.

The secure enclave is part of an overall hardware based encryption system that completely encrypts all of the user storage. It will only decrypt content if provided with the unlock code. The unlock code itself is entangled with the device's UDID so that all attempts to decrypt the storage must be done on the device itself. You must have all 3 pieces present: The specific secure enclave, the specific processor of the iphone, and the flash memory that you are trying to decrypt. Basically, you can't pull the device apart to attack an individual piece of the encryption or get around parts of the encryption storage process. You can't run the decryption or brute forcing of the unlock code in an emulator. It requires that the actual hardware components are present and can only be done on the specific device itself.

The secure enclave also has hardware enforced time-delays and key-destruction. You can set the phone to wipe the encryption key (and all the data contained on the phone) after 10 failed attempts. If you have the data-wipe turned on, then the secure enclave will nuke the key that it stores after 10 failed attempts, effectively erasing all the data on the device. Whether the device-wipe feature is turned on or not, the secure enclave still has a hardware-enforced delay between attempts at entering the code: Attempts 1-4 have no delay, Attempt 5 has a delay of 1 minute. Attempt 6 has a delay of 5 minutes. Attempts 7 and 8 have a delay of 15 minutes. And attempts 9 or more have a delay of 1 hour. This delay is enforced by the secure enclave and can not be bypassed, even if you completely replace the operating system of the phone itself. If you have a 6-digit pin code, it will take, on average, nearly 6 years to brute-force the code. 4-digit pin will take almost a year. if you have an alpha-numeric password the amount of time required could extend beyond the heat-death of the universe. Key destruction is turned on by default.

Even if you pull the flash storage out of the device, image it, and attempt to get around key destruction that way it won't be successful. The key isn't stored in the flash itself, it's only stored within the secure enclave itself which you can't remove the stora

Re:Huh?

[whipslash]

Haha well... have you seen any APK spam lately?

Re:Huh?

[wickerprints]

That isn't correct, according to the white paper:

"The backup set is stored in the user’s iCloud account and consists of a copy of the user’s files, and the iCloud Backup keybag. The iCloud Backup keybag is protected by a random key, which is also stored with the backup set. (The user’s iCloud password is not utilized for encryption so that changing the iCloud password won’t invalidate existing backups.)

While the user’s keychain database is backed up to iCloud, it remains protected by a UID-tangled key. This allows the keychain to be restored only to the same device from which it originated, and it means no one else, including Apple, can read the user’s keychain items.

On restore, the backed-up files, iCloud Backup keybag, and the key for the keybag are retrieved from the user’s iCloud account. The iCloud Backup keybag is decrypted using its key, then the per-file keys in the keybag are used to decrypt the files in the backup set, which are written as new files to the file system, thus re-encrypting them as per their Data Protection class."

The relevant sections begin at page 38, in which the paper discusses iCloud, Apple ID, and general Internet Services security. Your misunderstanding stems from the mistaken belief that you can just "restore" the iCloud backup of your phone to a new device. But to do this, you need access to the user's Apple ID password. If two-step verification is turned on, Apple definitely has no way to circumvent this.

Re:Try all combinations

[Falconhell]

They can be set so 10 failed tries wipes the phone. They can also set larger passwords than 4 digits.

Re: What if Apple cannot access the info?

[Anonymous Coward]

And since we have judges who do not understand encryption or technology whatsoever, the judge will simply find Apple didn't do enough to decrypt the phone.

Re:4 Digit Pin?

[Anonymous Coward]

No problem. 0000. Nope. 0001. Nope. 0002. Nope...

0009. Too many invalid password attempts. Full disk encryption key has been erased. Initiating factory reset of device...

Re:I can see it now...

[hawguy]

2. That really shouldn't be that difficult for the company that manufactured the thing.

Would you expect a safe manufacturer to be able to easily crack open a random safe they manufactured? If so, why? If not, why do you think encryption for a mobile device should be any different?

The company that installed our safe said they could open it when we asked what would happen if we lost the combination. They said "No problem, we'll just bring in a cutting torch and grinder and a few hours later we'll have it open. You'll need to sign a waiver first absolving us of any damage to the room."

Comment removed

[account_deleted]

Comment removed based on user account deletion

Re:I can see it now...

[zugmeister]

This is exactly what they want to do... The problem is the phone will wipe itself after 10 failed attempts, so the gov't wants Apple to write them software to bypass the wipe and continue the brute force attack. I'm the only person I've ever met who has more than a 4 digit code to unlock my phone, and I don't even have anything to hide!

Re:I can see it now...

[zugmeister]

Hardware key storage should wipe itself after so many failed attempts.

/sigh, RTFA... This is exactly what happens after 10 bad entries. So the gov't wants Apple to write them software to let them bypass the wipe and continue brute forcing the unlock code.

Re:I can see it now...

[meerling]

I've done tech support for certain security products, and your probably right on the money there. You'd be amazed how many people are absolutely positive that you have a 'secret' backdoor to get past your security program. You wouldn't believe some of the arguments I've been subjected too over that. People just believe hollywood too much over reason. Any security program that has a backdoor access is NOT SECURE ! If the users neglected to make their emergency unlock disk, or lost it, they were totally screwed. Time to nuke & pave.
As it happens, I don't support or have an iphone, so I have no idea what apple does, but I find it very plausible that there is absolutely nothing they can do, especially if they got pissed at their treatment early and removed any method they previously had to unlock it, even if it was for the cops when they have a proper warrant for the information. In which case, don't forget your key or it's toast.

Re:read the Ex Parte DOJ filing for the correct st

[wickerprints]

After reading Apple's iOS Security Guide white paper, it is doubtful that Apple can write any kind of software to load onto the device to permit any of those options. This is because once the device is locked, it will not install any updates to the operating system. The boot firmware is already installed and automatically runs when the device is turned on. Updating the operating system requires the device password. These functions are cryptographically secured. See the section "Keybags," subsection "Escrow Keybag" in the paper. The auto-erase and time delay features are enforced by the Secure Enclave in hardware, and cannot be circumvented.

Re:I can see it now...

[TechyImmigrant]

> it should be possible to pop the NAND device

This is not a reliable thing. You can desolder a BGA, but the odds of breaking the device in the process are pretty good. Maybe if you are the police you find the risk of destroying the potential evidence unacceptable, even if you cannot get at the evidence any other way because crypto and physical security done well works.

This is why Touch ID is a problem

[nbritton]

If the iPhone 5c had Touch ID this wouldn't be a problem, they could just use the persons finger to unlock the device. This illustrates why Touch ID is a bad idea if you care about your privacy. Since we only have ten fingers and the auto erase doesn't activate until after 10 failed attempts, the only thing needed to get into a Touch ID phone is a court order. The Fifth Amendment protection against self incrimination only applies to the contents of your mind, it's established precedent that it doesn't apply to your body (i.g. blood, DNA, finger prints, etc.) or property.

Re:This is why Touch ID is a problem

[khchung]

Since we only have ten fingers and the auto erase doesn't activate until after 10 failed attempts, the only thing needed to get into a Touch ID phone is a court order.

Spoken like someone who had never used Touch ID on an iPhone. Why am I not surprised?

Did you notice that most people's fingers are larger than the iPhone home button? When you register a finger for Touch ID, since your finger is bigger than the button, you have to choose where to put your finger during registration. Say, if you registered using the part closer to the tip of your finger, Touch ID would fail to recognize your finger if you used the side or base part of your finger.

The criminal could easily make the Touch ID fail to recognize the registered finger(s) by putting his finger on differently than when he registered, and can cause 10 failed attempts easily.

Re:I can see it now...

[v1]

They don't need to go that far. They just need to update the iPhone's operating system with an insecure version. The iPhone will update itself with whatever software Apple tells it to.

I support the full line of Apple prodcuts at work so I have a slightly better understanding of how this process works.

Unlike firmware updates on many devices, and older Apple iOS devies, the new ones require the firmware to be "signed", each time it is installed. This means the device will roll up its own salt, and will send a request to Apple's Firmware Signing Server. This server uses the salt and the checksum on the fimware to generate a verifiable cryptographic signature, using public key tech. iTunes sends this signature back to the phone during the restore. If it's invalid, the phone's hardware will refuse to install it. (iTunes normally will prevent it sooner, but this is assuming you have hacked iTunes, no easy task)

Around 1-2 weeks after Apple releases a new iOS, they stop signing the old one. This prevents you from downgrading your phone's firmware. It doesn't matter if you've already downloaded and kept a copy of it. Apple won't sign it with the new salt the phone is going to generate during the installation process. So users cannot hack the firmware OR install an older version to take advantage of a patched bug.

BUT... Apple has the secret part of the key for signing. They can roll their own custom firmware, sign it, and using a well-known public process, select the firmware and upload it. Their key servers will sign it, and the device will accept it. If Apple really wanted to fullly cooperate, it would be trivial to do. The new "security enclave" prevents them from simply ignoring the pin or displaying it on the screen, but it's possible that one or more of their requests could be accomodated. It really depends on how the SE is designed. If it's designed well, and I think we can assume it is, (they're not morons, and they have a functionally unlimited budget for such a minor thing) we should assume the SE does rate limiting in hardware. (usually via MANY hashes to dig down to the key) which is not bypassable unless you can rip the data from the hardware and feet it into a supercomputer. The USB/BT code entry is probably doable since its outside the scope of the SE. The master key should be stored inside the SE so software can't get around that.

End game: to give them what they want will require physical hacking of the SE, to recover the encrypted key and the internal salt the SE has generated for it, and feeding that data into an emulator for the SE (or a physically redesigned/hacked SE) that can work the passcode. The hardware on the phone itself right now CANNOT be used to recover the passcode. The FBI doesn't want to break the chip trying to recover the data. They have the techniques but (A) there's a good chance they break it and they get just one try, and (B) this will go a lot faster with Apple cooperating on bypassing the SE. (they can probably still DO it, they may even have the process already developed, but it will probably be faster with Apple's cooperation)

That leads us to another point... what if they already can access the data, or have accessed the data, and this is just a show? It's been said that the best form of deception is making your opponent believe you have fallen for his deception. Right now the terrorists are keeping a close eye on this case, trying to decide whether it's a "good idea" to use the iphone. If Apple gives them the finger, (and I hope they do) and the FBI shrugs and goes away moping, and suddenly has a breakthrough a few months from now from a "classified source", well, guess what. And that, sir, is where all my chips are placed.

Remember, this is one case. You have to think BIG. You have to think long term. This is neither of those things. The FBI either already has this data, or will have it before th