FBI demanding Apple build in a backdoor to the IPhone

[Ace Pace]

Why are you all discussing this when the technical details are all given. It's an old model iPhone with no hardware protection. It's password locked with a timeout. What the FBI wants is not an ability to break the encryption, which is impossible. What the FBI is requesting is an ability to brute force the password without wiping the device and without having timeouts.
There is nothing here about breaking encryption or brute forcing encryption keys. It's a locked iPhone.

Right, sorry - the OP itself seemed pretty vague. Specifically, Tim Cook's letter says:

In today’s digital world, the “key” to an encrypted system is a piece of information that unlocks the data, and it is only as secure as the protections around it. Once the information is known, or a way to bypass the code is revealed, the encryption can be defeated by anyone with that knowledge

So here he's clearly referring to public key cryptography, which is completely misleading if all they're talking about here is a password-protected iPhone.

Precisely.

The plot actually thickens, as it seems that Apple had no problem helping the FBI, except they required that it happen without any PR and without a court order. The FBI preferred to aim for precedent and went for a court order.

[Dominus Atheos]

Why are you all discussing this when the technical details are all given. It's an old model iPhone with no hardware protection. It's password locked with a timeout. What the FBI wants is not an ability to break the encryption, which is impossible. What the FBI is requesting is an ability to brute force the password without wiping the device and without having timeouts.
There is nothing here about breaking encryption or brute forcing encryption keys. It's a locked iPhone.

Right, sorry - the OP itself seemed pretty vague. Specifically, Tim Cook's letter says:

In today’s digital world, the “key” to an encrypted system is a piece of information that unlocks the data, and it is only as secure as the protections around it. Once the information is known, or a way to bypass the code is revealed, the encryption can be defeated by anyone with that knowledge

So here he's clearly referring to public key cryptography, which is completely misleading if all they're talking about here is a password-protected iPhone.

There is no public key here, he's clearly talking about the pin number/passcode.

[Channel72]

Tim Cook's statement sounds like he's talking about a public key - why does he even mention encryption or mention a "key" that "unlocks" data here? If anyone said that to me I'd assume they mean something like an RSA key, not just a password. Tim Cook is either intentionally being misleading or his choice of wording is very poor. Anyone with a technical background would read that sentence and assume he's talking about a public/private key pair that decrypts data.

[Darth Holbytlan]

Why are you all discussing this when the technical details are all given. It's an old model iPhone with no hardware protection.

This is inaccurate. The iPhone is a 5c which does have hardware protection in the form of an encryption unit with a burned-in secret UID only it can use for encryption/decryption. All information on the iPhone is protected through a chain of encryption descending from this UID.

It's password locked with a timeout. What the FBI wants is not an ability to break the encryption, which is impossible. What the FBI is requesting is an ability to brute force the password without wiping the device and without having timeouts.
There is nothing here about breaking encryption or brute forcing encryption keys. It's a locked iPhone.

Except that brute forcing the encryption key is exactly what they want to do. The iPhone passcode is used as part of the encryption chain protecting all of the data stored on it, so it is an encryption key. And the FBI wants the ability to try all of the encryption keys (passcodes) to find the one that decrypts these files—that is, brute force the key.

The only reason brute forcing is possible is that most people choose a short 4 or 6 digit passcode, which is amenable to exhaustive testing—assuming that the OS doesn't enforce timeouts and/or wipe its internal security key after too many tries.

That's really the key point, here. Human beings have difficulty creating and remembering passcodes long and random enough to really protect against brute force attack, so keeping data secure requires that the device design help by preventing too much brute force guessing. The FBI asking to undermine that protection here undermines it for all similar devices—or so the argument goes.

As far as newer iPhones go, the difference is that they have Secure Enclave, which means that there is a miniature secured coprocessor and microkernel that are in charge of the encryption services and enforcing the timeouts and secure wipe after bad passcode guesses. That means that undermining the protection requires replacing this microkernel instead of the main iPhone OS. Whether that is actually harder depends on whether they've protected the microkernel from updates when the phone is locked. The main OS is clearly not so protected, since breaking the protection on passcode guessing would otherwise be impossible. Outside of Apple, no one knows for sure if the Secure Enclave microkernel has the same problem. Apple seems to have made statements that it is so vulnerable, though.

This is the best article I have seen so far on the technical side of the issue.

In today’s digital world, the “key” to an encrypted system is a piece of information that unlocks the data, and it is only as secure as the protections around it. Once the information is known, or a way to bypass the code is revealed, the encryption can be defeated by anyone with that knowledge

So here he's clearly referring to public key cryptography, which is completely misleading if all they're talking about here is a password-protected iPhone.

There is no public key here, he's clearly talking about the pin number/passcode.

He's talking private key cryptography, where is the pin number/passcode is the key. It's not an either-or situation.

[Dominus Atheos]

...

Maybe we're talking past each other, but the 4 or however any digit pin number is different from the 256-bit AES encryption key. Cook was talking about the pin but Channel72 mistakenly thought Cook was talking about the encryption key.

[Channel72]

He's talking private key cryptography, where is the pin number/passcode is the key. It's not an either-or situation.

That's not a thing. When people say "public key cryptography" they specifically mean asymmetric public/private key pairs, like RSA private keys, where data is encrypted with a public key and decrypted with a private key.

[Terralthra]

That's nice, but Tim Cook didn't say "public key cryptography". You did. You, in fact, quoted him saying just "key".

[Darth Holbytlan]

...

Maybe we're talking past each other, but the 4 or however any digit pin number is different from the 256-bit AES encryption key. Cook was talking about the pin but Channel72 mistakenly thought Cook was talking about the encryption key.

The encryption is implemented by mixing the pin with the device UID in some manner and then using the result with AES, but it is still an encryption key. To be precise, it is the input to the functions eUID[pin](plaintext) and dUID[pin](cyphertext) such that dUID[pin](eUID[pin](plaintext)) = plaintext for all values of plaintext. That fits the definition of an encryption key.

He's talking private key cryptography, where is the pin number/passcode is the key. It's not an either-or situation.

That's not a thing. When people say "public key cryptography" they specifically mean asymmetric public/private key pairs, like RSA private keys, where data is encrypted with a public key and decrypted with a private key.

Yeah it is. It's not the best term because it can be conflated with the private key of a public-private keypair, but I was trying to contrast with your bringing up public key cryptography out of thin air. Read secret key cryptography or symmetric cryptography if you prefer. The point is that, as Terralthra also points out, nothing Tim Cook wrote implies public key cryptography. That came out of your own head.

[Channel72]

Yeah it is. It's not the best term because it can be conflated with the private key of a public-private keypair, but I was trying to contrast with your bringing up public key cryptography out of thin air. Read secret key cryptography or symmetric cryptography if you prefer. The point is that, as Terralthra also points out, nothing Tim Cook wrote implies public key cryptography. That came out of your own head.

Having a single key that encodes/decodes is usually called symmetric cryptography - calling it a "private key" usually implies there is also a public key involved. But regardless, to me Tim Cook's statement is kind of confusing because it implies that the significant thing here is that the FBI is trying to bypass some kind of cryptographic "key" - when in reality all that's going on here is the FBI wants Apple to disable a timeout so they can brute force a password. I think that was Ace Pace's point.

The fact that - as you pointed out - the 4-digit (or whatever) password/pincode is used as an input to encrypt the data is almost not even entirely relevant here* - what's relevant is the FBI just needs to brute force a password to get access to decrypted data. So ultimately the FBI just wants Apple to give them a patched version of iOS that removes the timeout. That's not really a back door in any sense - it's just a one-off patched iOS that the FBI can use.

So Tim Cook's argument is that once such a version exists, this version might fall into the wrong hands and compromise all iPhones everywhere. Well, okay - but you know that other mobile OS that everyone uses - Android - is open source right? (As are many other secure OS's that support encrypted file systems.) So this could already happen with Android phones. Hell, fucking OpenSSL - the library that iOS is probably using to implement all these encryption algorithms - is also open source. Yet we're not all screaming and panicking.

*It's relevant only in the sense that the encryption prevents the FBI from just reading the bytes directly from the iPhone physical storage

[Gaidin]

Yeah it is. It's not the best term because it can be conflated with the private key of a public-private keypair, but I was trying to contrast with your bringing up public key cryptography out of thin air. Read secret key cryptography or symmetric cryptography if you prefer. The point is that, as Terralthra also points out, nothing Tim Cook wrote implies public key cryptography. That came out of your own head.

Having a single key that encodes/decodes is usually called symmetric cryptography - calling it a "private key" usually implies there is also a public key involved. But regardless, to me Tim Cook's statement is kind of confusing because it implies that the significant thing here is that the FBI is trying to bypass some kind of cryptographic "key" - when in reality all that's going on here is the FBI wants Apple to disable a timeout so they can brute force a password. I think that was Ace Pace's point.

The fact that - as you pointed out - the 4-digit (or whatever) password/pincode is used as an input to encrypt the data is almost not even entirely relevant here* - what's relevant is the FBI just needs to brute force a password to get access to decrypted data. So ultimately the FBI just wants Apple to give them a patched version of iOS that removes the timeout. That's not really a back door in any sense - it's just a one-off patched iOS that the FBI can use.

So Tim Cook's argument is that once such a version exists, this version might fall into the wrong hands and compromise all iPhones everywhere. Well, okay - but you know that other mobile OS that everyone uses - Android - is open source right? (As are many other secure OS's that support encrypted file systems.) So this could already happen with Android phones. Hell, fucking OpenSSL - the library that iOS is probably using to implement all these encryption algorithms - is also open source. Yet we're not all screaming and panicking.

*It's relevant only in the sense that the encryption prevents the FBI from just reading the bytes directly from the iPhone physical storage

Except it doesn't really matter what Apple did before they adopted their new privacy standards. Congress pretty much told the FBI to screw off, they're not updating CALEA. FBI is sort of playing a gamble here by somewhat going to the courts and well..half-bypassing the law. We're not really learning much new until we see Apple's legal retort in a few days.

[Darth Holbytlan]

Having a single key that encodes/decodes is usually called symmetric cryptography - calling it a "private key" usually implies there is also a public key involved.

I don't think we are disagreeing on this point. You are clear on my intent.

But regardless, to me Tim Cook's statement is kind of confusing because it implies that the significant thing here is that the FBI is trying to bypass some kind of cryptographic "key" - when in reality all that's going on here is the FBI wants Apple to disable a timeout so they can brute force a password. I think that was Ace Pace's point.

In context, what Tim Cook's statement meant was that the FBI wants Apple to disable protections on the key that prevent the FBI from brute-forcing it. Which is perfectly accurate even without accounting for the fact that he was writing for laypersons. My main objection is to the claim that he was being deceptive here.

The fact that - as you pointed out - the 4-digit (or whatever) password/pincode is used as an input to encrypt the data is almost not even entirely relevant here* - what's relevant is the FBI just needs to brute force a password to get access to decrypted data. So ultimately the FBI just wants Apple to give them a patched version of iOS that removes the timeout. That's not really a back door in any sense - it's just a one-off patched iOS that the FBI can use.

*It's relevant only in the sense that the encryption prevents the FBI from just reading the bytes directly from the iPhone physical storage

That is most definitely a back door, since it removes critical security protections from the device that could not otherwise be removed. If Apple supplies them their modified OS, the FBI could keep it to apply to other iPhones without further assistance from Apple. If that copy leaked out, anyone who got a hold of it could use it to crack any iPhone.

Well, technically they could only use it on any iPhone 5c and maybe any non-Secure Enclave iPhone—I doubt that it could be used directly on a 5s or 6* because it wouldn't have the bypass in Secure Enclave microkernel form. But that's not a big difference since if the FBI can force Apple to do this for one phone, they will certainly force them to do it for later models in the near future.

So Tim Cook's argument is that once such a version exists, this version might fall into the wrong hands and compromise all iPhones everywhere. Well, okay - but you know that other mobile OS that everyone uses - Android - is open source right? (As are many other secure OS's that support encrypted file systems.) So this could already happen with Android phones.

To put it bluntly, the security design of Android phones isn't as good as for iPhones. That it is Open Source is not really relevant. The FBI could certainly hire someone outside of Apple that could build a hacked version of iOS with their changes. The problem is that they wouldn't be able to get this version cryptographically signed by Apple. Without that, the iPhone won't let them install it without wiping the phone, which would defeat the purpose. Android phones don't have that protection.

What this means is that if an iPhone and an Android phone both fall into the hands of reasonably competent criminals, they will probably be able to crack the Android phone and extract all of its secrets quickly, but won't be able to do that with the iPhone. (Assuming you have a good pin and especially if you have the 10 guess limit turned on.)

I think the fear here is that the legal requirement to create breakable versions of the OS would effectively ensure that it would be impossible to make any of these phones secure against criminal attack in the way that the iPhone currently is. The idea is that, as these cracked OSes got into the hands of various law enforcement agencies around the world, it would inevitably leak and become usable by criminals as well.

There's also the legal fear that the FBI could use this to directly require future phones (and security updates to current phones) to permanently install weaknesses that let them get into them—or never remove such weaknesses that are already there.

Hell, fucking OpenSSL - the library that iOS is probably using to implement all these encryption algorithms - is also open source. Yet we're not all screaming and panicking.

No, because who wrote the code or how it is distributed isn't the issue. Getting the phone to run it is.

[Terralthra]

Never has it been more clear that someone is arguing about encryption while not knowing all that much about it. Why does Android or the OpenSSL library being open source somehow magically make it easy to get a locked phone unlocked? Yes, you could easily write a version of Android that doesn't have unlock timeouts and brute force protection, but your version isn't running on my phone, and you're not going to install it on my phone which you can't unlock. The only way you can get it installed is to go into the fastboot mode and unlock the bootloader so that you can install your custom attack OS from a computer, but surprise, unlocking the bootloader wipes the phone's /data/ folders for exactly that reason.

The FBI want Apple to essentially not be legally permitted to write software that can't be backdoored. The problem is that there's no backdoor that only the FBI can use. Any government can compel Apple to hand over the same hack once it's written. Force someone to write an exploit for OpenSSL and deploy it? That exploit won't stay with one party. Sooner or later, someone you don't want using the backdoor will use it, and now online commerce is gone, because OpenSSL is what essentially everyone uses to protect credit card numbers, passwords, and PINs in online transactions.

The EFF maintains, and I agree, that the FBI is trying to set a precedent in the most appealing case they could find, not because anything on this iPhone is likely to be meaningful. The idea that this is the first iPhone 5C that the FBI has tried to access is ridiculous on its face. They instructed the county of San Bernardino to reset the password on the user's iCloud backup, disabling any chance of enabling autobackup (the easiest way of getting everything on the phone without guessing the password). It's the shooter's work phone, while the shooters destroyed their personal phone, making it extremely unlikely that there's anything evidentiary on this one. The FBI wants the precedent set that it's software companies' jobs to write broken software, by legal compulsion.

[Gaidin]

The FBI want Apple to essentially not be legally permitted to write software that can't be backdoored. The problem is that there's no backdoor that only the FBI can use. Any government can compel Apple to hand over the same hack once it's written. Force someone to write an exploit for OpenSSL and deploy it? That exploit won't stay with one party. Sooner or later, someone you don't want using the backdoor will use it, and now online commerce is gone, because OpenSSL is what essentially everyone uses to protect credit card numbers, passwords, and PINs in online transactions.

I may be missing something, but if Apple writes something like this for this reason could they even legally hand it over to another country? Our import-export laws being what they are?

[Grumman]

I may be missing something, but if Apple writes something like this for this reason could they even legally hand it over to another country? Our import-export laws being what they are?

It would be an odd reversal if Apple was legally allowed to export a secure OS but not an insecure OS.

[Gaidin]

I may be missing something, but if Apple writes something like this for this reason could they even legally hand it over to another country? Our import-export laws being what they are?

It would be an odd reversal if Apple was legally allowed to export a secure OS but not an insecure OS.

"We're making what is functionally a firmware update to remove securities for you...to aid law enforcement. And punch a hole in items that many law enforcement agencies in America use." Are you telling me it wouldn't?

[Darth Holbytlan]

Yes, you could easily write a version of Android that doesn't have unlock timeouts and brute force protection, but your version isn't running on my phone, and you're not going to install it on my phone which you can't unlock. The only way you can get it installed is to go into the fastboot mode and unlock the bootloader so that you can install your custom attack OS from a computer, but surprise, unlocking the bootloader wipes the phone's /data/ folders for exactly that reason.

The information I've been seeing is that this protection can be bypassed with physical access to Android hardware, but I'm finding it quite difficult to confirm. Some of the problem is that Android has many different hardware manufacturers and they have some flexibility in how they implement protection on the bootloader. I remembered a reference in the article I linked that some hacker group was able to crack Android phones and jailbroken iPhones but not normal iPhones, but it was actually in a comment and wasn't sourced.

So far I don't see any evidence of an equivalent to the UID that is used in the iPhone. Without that, even when encrypted, the data can be extracted from the device and brute forced on more powerful computers, meaning that the Android security with an encrypted disk is dependent only on the quality of the passphrase chosen.

[Terralthra]

On any Android device with a bootloader that has a lock/unlock switch coded into it, flipping that switch in fastboot will wipe the user data partition. Period. If the bootloader is locked and doesn't have an unlock built in, and in the bootloader is exploited in some fashion to put a custom bootloader and OS on it, then the security of the wipe mechanism can no longer be guaranteed, obviously.

If you physically extract the storage from an Android phone, you can attempt to brute force the encryption, but the passphrase is salted with SHA256 and hashed with a device-specific (generated on boot) 128-bit AES key. It's non-trivial.

[Channel72]

Never has it been more clear that someone is arguing about encryption while not knowing all that much about it.

LOL. You better hope I know something about it, considering how often I make use of OpenSSL/GnuTLS in various open source projects I contribute to - some of which you are likely running right now if you use Linux.

Why does Android or the OpenSSL library being open source somehow magically make it easy to get a locked phone unlocked? Yes, you could easily write a version of Android that doesn't have unlock timeouts and brute force protection, but your version isn't running on my phone, and you're not going to install it on my phone which you can't unlock. The only way you can get it installed is to go into the fastboot mode and unlock the bootloader so that you can install your custom attack OS from a computer, but surprise, unlocking the bootloader wipes the phone's /data/ folders for exactly that reason.

Uh... yeah, that's the point. Apple creating a patched iOS that bypasses security measures also doesn't magically make it running on my phone. Is my point really that unclear to you?

The FBI want Apple to essentially not be legally permitted to write software that can't be backdoored. The problem is that there's no backdoor that only the FBI can use. Any government can compel Apple to hand over the same hack once it's written. Force someone to write an exploit for OpenSSL and deploy it? That exploit won't stay with one party. Sooner or later, someone you don't want using the backdoor will use it, and now online commerce is gone, because OpenSSL is what essentially everyone uses to protect credit card numbers, passwords, and PINs in online transactions.

The EFF maintains, and I agree, that the FBI is trying to set a precedent in the most appealing case they could find, not because anything on this iPhone is likely to be meaningful. The idea that this is the first iPhone 5C that the FBI has tried to access is ridiculous on its face. They instructed the county of San Bernardino to reset the password on the user's iCloud backup, disabling any chance of enabling autobackup (the easiest way of getting everything on the phone without guessing the password). It's the shooter's work phone, while the shooters destroyed their personal phone, making it extremely unlikely that there's anything evidentiary on this one. The FBI wants the precedent set that it's software companies' jobs to write broken software, by legal compulsion.

Well, if what you say here is correct, then my understanding of exactly what the FBI wants is off here - from reading Tim Cook's statement:

Specifically, the FBI wants us to make a new version of the iPhone operating system, circumventing several important security features, and install it on an iPhone recovered during the investigation.

I'm a native English speaker, and my impression here is that the FBI just wants Apple to create a one-off version of iOS that disables the timeout - not necessarily force Apple to integrate backdoors into future version of iOS that will run on everyone's phone.

[Channel72]

To put it bluntly, the security design of Android phones isn't as good as for iPhones. That it is Open Source is not really relevant. The FBI could certainly hire someone outside of Apple that could build a hacked version of iOS with their changes. The problem is that they wouldn't be able to get this version cryptographically signed by Apple. Without that, the iPhone won't let them install it without wiping the phone, which would defeat the purpose. Android phones don't have that protection.

Fair enough, but my point is that anybody could already create a hacked version of Android with disabled security features - and Android market share is much larger than iOS globally. Yet nobody is panicking really, because most people trust the manufacturers and distributors to not install such versions on their phones when they go to their local T-Mobile/Verizon store at the mall. So I think Tim Cook's fears are a bit overstated here - unless I'm misunderstanding exactly what the FBI wants to do here.

[Ralin]

not necessarily force Apple to integrate backdoors into future version of iOS that will run on everyone's phone.

I'm not a computer person, but I think it's pretty clear from what other people are saying that they consider that a probable issue stemming from the precedent, as opposed to the immediate reasons why letting the FBI do this is a bad idea?

[Tribble]

I'm a native English speaker, and my impression here is that the FBI just wants Apple to create a one-off version of iOS that disables the timeout - not necessarily force Apple to integrate backdoors into future version of iOS that will run on everyone's phone.

And that's the problem. Which is more likely? The FBI asking Apple to do it "just this once" and never ever asking Apple to do anything of the sort ever again? Or that the FBI and other law enforcement agencies will use this as a precedent and demand it and similar things from phone companies every time they seize a phone? I don't know how many phones are seized in the US every year, but I imagine there's quite a lot. Certainly in the tens of thousands, if not more.

If this turns into a precedent which law enforcement agencies can use, phone companies with have to develop one-off software for every phone that they are ordered to open (which would be pretty expensive), develop software that can open up all of their phones, or design their phones in such a way so that law enforcement agencies can access them without needing the phone companies' help.

[Darth Holbytlan]

On any Android device with a bootloader that has a lock/unlock switch coded into it, flipping that switch in fastboot will wipe the user data partition. Period. If the bootloader is locked and doesn't have an unlock built in, and in the bootloader is exploited in some fashion to put a custom bootloader and OS on it, then the security of the wipe mechanism can no longer be guaranteed, obviously.

The lock/unlock switch is irrelevant since obviously any hack isn't going to use it to bypass the bootloader. The question is what physical protections exist to ensure that the bootloader can't be replaced if someone physically opens up the device.

If you physically extract the storage from an Android phone, you can attempt to brute force the encryption, but the passphrase is salted with SHA256 and hashed with a device-specific (generated on boot) 128-bit AES key. It's non-trivial.

As far as the encryption goes, salt only prevents precomputed dictionary attacks; it won't protect a weak passcode against brute forcing—and let's face it, even with passcode complexity rules, most passcodes aren't going to be that secure. The hashing of the passcode key with a device-specific key is optional in the Android spec, and it is only protective if the device-specific key itself can't be extracted from the device. Unfortunately, the TEE spec that should protect that device-specific key considers physical security to be outside of its spec, and even ignoring that I couldn't find anything that explained how the device-specific key would be protected or even that it was protected. That is a bit different than the iPhone's UID which is documented as completely isolated inside the hardware encryption engine.

Honestly, it's certainly possible that some Android devices are more secure than I believe, but what I've read of the Android security specs recently doesn't encourage me. It's not a terrible design, but there is a lot of vagueness in comparison to what Apple provides.

Uh... yeah, that's the point. Apple creating a patched iOS that bypasses security measures also doesn't magically make it running on my phone. Is my point really that unclear to you?

Since both Terralthra and I read your statement as saying the exact opposite... Yes, that point was unclear.

I'm a native English speaker, and my impression here is that the FBI just wants Apple to create a one-off version of iOS that disables the timeout - not necessarily force Apple to integrate backdoors into future version of iOS that will run on everyone's phone.

Fair enough, but my point is that anybody could already create a hacked version of Android with disabled security features - and Android market share is much larger than iOS globally. Yet nobody is panicking really, because most people trust the manufacturers and distributors to not install such versions on their phones when they go to their local T-Mobile/Verizon store at the mall. So I think Tim Cook's fears are a bit overstated here - unless I'm misunderstanding exactly what the FBI wants to do here.

It's not just about this one phone, but the implications of what happens, both technically and legally, if the FBI gets its way.

In order for the modified OS to be useful to the FBI, it needs the special signature that lets them install it on the captured iPhone without unlocking it. Anyone getting a hold of this copy could use it to compromise an iPhone in their possession (or perhaps even one nearby before stealing it). The very existence of the modified OS with signature threatens all iPhone users, which it can't do if Apple never creates it.

As far as Android users go: 1. Tim Cook is naturally concerned with iPhone users more than them. 2. The legal precedents after Android users as well—if the FBI can do this once, it will certainly do it many more times. 3. The legal precedents might be extendable in a way to prevent companies from improving the security on these devices further.

NB: I haven't read the legal documents, so I really have no idea if these legal fears are justified. On the technical side, a lot of this comes down to how likely a leak of the modified OS is. The FBI has no incentive to leak it, but I don't know that they have any incentives to prevent a leak, either.

[Jaepheth]

I found this to be a rather enlightening article:

Encryption isn’t at stake, the FBI knows Apple already has the desired key
The FBI knows it can't bypass the encryption; it just wants to try more than 10 PINs.

by Peter Bright - Feb 18, 2016 4:45pm CST

Apple's encryption battle

Activists plan rally on Tuesday at dozens of Apple Stores worldwide
How the FBI could use acid and lasers to access data stored on seized iPhone
Apple CEO Tim Cook: Complying with court order is “too dangerous to do”
If FBI busts into seized iPhone, it could get non-iCloud data, like Telegram chats
Apple: We tried to help FBI terror probe, but someone changed iCloud password

Apple has been served with a court order at the FBI's request, demanding that it assist the government agency with unlocking an iPhone 5C that was used by Syed Rizwan Farook. Farook and his wife, Tashfeen Malik, killed 14 and injured 24 in an attack in San Bernardino, California on December 2, 2015.

In response, Apple CEO Tim Cook said that the FBI was demanding the equivalent of a backdoor and that complying with the FBI's demand would undermine the security of all iPhones.

Whether you call it a "backdoor" or not, it's important to recognize that the ordered changes to the iPhone operating system would not circumvent the core of the iPhone's encryption. The court isn't asking Apple to defeat the encryption in any way. Nor does the court require Apple to create a vulnerability that would jeopardize the security of any other phone. Rather, it's asking Apple to do the one thing that Apple alone can do: use the iPhone's built-in method of installing firmware written by Apple.

The FBI wants to search the iPhone 5C and has been granted permission to do so by the device's owner, the San Bernardino County Department of Public Health (Farook's employer). To perform this search, the FBI needs the device's PIN. Without it, the government has no way of decrypting the iPhone's storage and hence no way of examining any data stored on the device.

The encryption used by the iPhone to protect its storage is a multi-tiered system. At its core are two keys, one embedded in the hardware and the second derived from the PIN. The hardware key is used to generate a file system key that is in turn used to encrypt the file system metadata. That metadata includes an encryption key for each individual file. That per-file key is encrypted using (indirectly) an encryption key that is derived from a combination of the hardware key and the PIN key. As such, without the PIN key, it's impossible to decrypt those per-file keys and hence impossible to decrypt files stored on the iPhone.

There are some minor nuances over where and how the hardware key is stored and where the different encryption operations are performed. There are variations between different iPhone models, but the broad design is true of all iPhone models running iOS 9.

It's important to note here that the cryptography aspect is robust. The FBI is not asking for, and Apple almost surely could not provide, any kind of bypass or backdoor for the cryptographic parts of the system. There is no "master key" that can decrypt the files or otherwise break the dependence on the PIN key. The cryptography appears to be secure.

In practice, encryption isn't usually defeated by cryptographic attacks anyway. Instead, it's defeated by attacking something around the encryption: taking advantage of humans' preference for picking bad passwords, tricking people into entering their passwords and then stealing them, that kind of thing. Accordingly, the FBI is asking for Apple's assistance with the scheme's weak spot—not the encryption itself but Apple-coded limits to the PIN input system.

PINs, especially four-digit PINs, are highly susceptible to brute-force attacks. With four digits and hence only 10,000 possible combinations, it's straightforward to simply try every number in sequence until you hit the right one. To combat this, the iPhone uses three specific techniques.

The first is that the iPhone imposes delays between PIN attempts. While the first four attempts can be entered back-to-back, the iPhone will force you to wait one minute before the fifth attempt, five minutes before the sixth, 15 minutes before the seventh and eighth, and a full hour before the ninth.

The second technique is that the iPhone can be configured to wipe the device after ten failed PIN attempts. When this option is turned on, the phone will discard its file system key after 10 bad PINs, rendering all the file system metadata (including the per-file keys) permanently inaccessible.

The third and final technique is that the computation used to derive the PIN key from the PIN itself is slow, taking approximately 80 milliseconds.

It's the first two of these mechanisms that the FBI is asking for assistance with. While the 80 millisecond delay is in some sense unavoidable (a faster system might be able to perform the key derivation more quickly, but it's not as if the iPhone hardware is readily upgradeable), both the escalating long delays and device-wiping functionality are arbitrary software decisions. The FBI is asking for Apple to create a custom iPhone firmware that removes the escalating delays and omits the device wipe. As a bonus, the FBI is also asking for a way to enter PINs other than typing them in one after the other on the touchscreen. Thus, the FBI wants Apple to make a special version of iOS that is amenable to brute-force attacks on its PIN.

As long as the phone uses a PIN, this would ultimately let the FBI unlock it. If it's locked with a secure password, unlocking the phone may well prove intractable even with the special firmware.

Such a firmware would not seem to be generally useful for attacking other iPhones, though. The FBI's request is that the special firmware be tied to the specific device. Every iPhone contains a multitude of unique identifiers that are baked into its hardware (the serial number, the cellular radio IMEI, and the Wi-Fi and Bluetooth MAC), and the court order explicitly states that the custom firmware must be tied to the San Bernardino phone's unique identifier, such that it can only run on that specific phone.

Assuming that this can be done (and done robustly), it means that even if the custom firmware were given to nation-states or even published on the Internet, it would not serve as a general-purpose way of performing brute-force PIN attacks. It would be useless on any device other than the San Bernardino device. To make such leakage less likely, the court order does allow for the possibility that the custom firmware might be used only at an Apple location, with the FBI having remote access to the passcode recovery system.

Such an approach is consistent with the way Apple already performs lock screen bypasses on devices running old versions of iOS; law enforcement sends the device to Apple, Apple does the data extraction using tools the company has explicitly created to perform the extraction, and law enforcement receives a FireWire or USB drive with the data. Apple's custom tools never leave Cupertino.

Hypothetically, if the special firmware were to leak, what exactly would prevent people from making it work with a different unique identifier—or even with any unique identifier. This concern strikes at the very heart of the matter, and it's why Apple is involved at all.

The FBI does not really need Apple to write a custom firmware that lets you brute force the iPhone PIN without risk of wiping the device or suffering lengthy timeouts. It's much easier for Apple to write this code, of course, because Apple knows all about the iPhone, but there's no doubt that the FBI could pay some enterprising reverse engineers and hackers to develop the software itself. The problem for the FBI is not so much the development of the software; it is getting that software to run on the iPhone.

The iPhone requires that its firmware have a digital signature that authentically demonstrates that the firmware was developed by Apple and has not been subsequently modified. The FBI does not have (and is not asking for) access to Apple's signing key. It is instead asking for Apple to use its signing key to sign the custom firmware so that the iPhone will accept it and run it. It is this signature requirement that means the FBI cannot create the software itself.

It's this same requirement that also means that iPhone users would be safe even if the special firmware leaked. Changing the embedded unique identifier within the special firmware would break the signature and thus cause targeted iPhones to reject the firmware. This is why complying with the court demand would not jeopardize the security of any other phones. The cryptographic safeguards don't allow it.

The security of these digital signatures is being taken for granted by the FBI; once again, the cryptography underpinning the system is sound, and the government is not asking for it to be bypassed or backdoored or otherwise attacked.

The FBI's request does, however, put into sharp relief the parts that aren't sound. The PIN lockouts and device wiping measures are all "just software." They're not dependent on any particular mathematical feature of the algorithms, they're not proven by years of analysis of the underlying mathematics. And as "just software," Apple has every ability to override them.

One could imagine ways in which iPhones were made a little more resilient against this kind of thing, but they're not straightforward. The court order suggests the use of the iPhone's "DFU" mode. This is an extremely low-level mode designed for last-ditch recovery of the device. In this mode, the screen is not even activated or enabled; the phone has to be connected to a computer via USB to transfer a new firmware image. One could imagine ways in which even this mode could be PIN protected, perhaps even making it destroy the file system key if a correct PIN is not available, but this is tricky. One of the points of DFU mode is its simplicity. It does one thing as a fail-safe emergency measure. Making it more complex would jeopardize its ability to serve its fundamental purpose.

Overall, the FBI's request could be seen as a testament to just how good encryption is. The FBI can't attack the iPhone's encryption directly, and it can't bypass the firmware signature mechanism. There's no existing backdoor to the crypto.

But what the iPhone does have is software lockouts, and the security of those lockouts is entirely up to Apple. Apple's signing key gives the company wide power over the software-level protections built in to iOS. The FBI knows this, and that is why it's demanding the company's assistance.

So they can tie the custom OS to just that phone and anyone who tries to generalize it for other phones should lose the digital signature in the process.

I read someone else make an intriguing argument that since there's no law stating that the OS must have a backdoor and Apple hasn't been convicted of a crime, then the court forcing Apple to develop a custom OS would run afoul of the 13th Amendment as involuntary servitude.

[Channel72]

Uh... yeah, that's the point. Apple creating a patched iOS that bypasses security measures also doesn't magically make it running on my phone. Is my point really that unclear to you?

Since both Terralthra and I read your statement as saying the exact opposite... Yes, that point was unclear.

Okay - fair enough. I brought up Android precisely because anybody can already create a version of Android that bypasses security. So it's not like this is really any kind of serious threat, since these hacked versions of Android aren't going to be distributed by vendors - and it's the same with iOS.

It's not just about this one phone, but the implications of what happens, both technically and legally, if the FBI gets its way.

In order for the modified OS to be useful to the FBI, it needs the special signature that lets them install it on the captured iPhone without unlocking it. Anyone getting a hold of this copy could use it to compromise an iPhone in their possession (or perhaps even one nearby before stealing it). The very existence of the modified OS with signature threatens all iPhone users, which it can't do if Apple never creates it.

Yes - and this is already a problem for like 80% of smart phone users in the world - since you can already do this with Android. So my point is simply, why is everyone so worried about this?

As far as Android users go: 1. Tim Cook is naturally concerned with iPhone users more than them. 2. The legal precedents after Android users as well—if the FBI can do this once, it will certainly do it many more times. 3. The legal precedents might be extendable in a way to prevent companies from improving the security on these devices further.

NB: I haven't read the legal documents, so I really have no idea if these legal fears are justified. On the technical side, a lot of this comes down to how likely a leak of the modified OS is. The FBI has no incentive to leak it, but I don't know that they have any incentives to prevent a leak, either.

Of course Tim Cook is more concerned with iOS. But really that's the point - Tim Cook's letter words this like it would be some kind of insane security threat. Non-technical people are going to read it and be like "OMG if Apple caves then it opens the floodgates for the FBI to hack everything!" But the reality is that the most popular mobile OS in the world (Android) is already quite hackable. Anybody can do it. A first year comp-sci student could probably do it after taking a crash course in C/C++. So Tim Cook's statements just comes off as alarmist to me - and my assumption is that Tim Cook is just taking this opportunity to make Apple look like some kind of underdog who is standing up for our freedomz.

[Tribble]

Yes - and this is already a problem for like 80% of smart phone users in the world - since you can already do this with Android. So my point is simply, why is everyone so worried about this?

As I've said multiple times before, it's the legal precedent that's the problem, since it would potentially allow the FBI and other law enforcement agencies to get court orders demanding that cellphone companies assist with every phone that they seize. I guarantee they are not going to stop with this particular phone. As I mentioned earlier, If this turns into a precedent which law enforcement agencies can use, phone companies may have to develop one-off software for every phone that they are ordered to assist with (which could easily number in the thousands, if not more), develop software that can open up all of their phones (in order to save costs), or design their phones in such a way so that law enforcement agencies can access them without needing the phone companies' help.