Summary of the current situation by @TTT

Apple released an open letter to the public outlining their reasons for not complying with the FBI's demands to modify the iPhone's security mechanism.

Here's a summary:

The FBI has an iPhone in their possession which they would like to access data from. The phone is locked and fully encrypted. After failing to get into the phone, the FBI asked Apple to unlock the phone. Apple said since the phone is encrypted, they can't get into it either. The FBI asked Apple to modify the iPhone OS to enable brute force password attempts electronically. (Currently the passwords can only be entered in via the manual interface, and is limited to 10 attempts.) Apple refused. They believe it would be too dangerous to make that change because in the wrong hands it would undermine the security of all iPhone users, even if they only used the software in this instance.

My question is, if the cracking takes seven minutes, why not just release the update, wait ten or so minutes (coordinate with the FBI on this) and then release another update rolling back the change.

  • and why to do that? You want a backdoor in your phone? – Jakuje Feb 21 '16 at 0:32
  • @Jakuje No, that's the most secure way. Backdoor for ten minutes, then the backdoor is gone. NSA can't reuse it, FBI can't reuse it, hackers can't reuse it, etc. – noɥʇʎԀʎzɐɹƆ Feb 21 '16 at 0:36
  • 14
    Because the legal precedent has now been set: The Government can bully tech companies into getting whatever they want. – Seth Feb 21 '16 at 1:04
  • 7
    @Seth is correct - the problem is not a technical one for Apple, it's a legal precedent that is being created. – schroeder Feb 21 '16 at 1:38
  • How do you know the cracking would only take seven minutes? Do we know the passcode is just a 4 digit numerical code? – TTT Feb 21 '16 at 15:38

The whole story is weird. Since the iPhone in question does not have a tamper-resistant device, the FBI should be able to open the case, read the whole Flash chip, and then run the exhaustive search themselves without even running the phone's firmware. Updates from Apple should have no effect at all.

(Edit: in fact it is a bit more complex; see below.)

Conversely, assuming that there was a technical impossibility in the description above (which would amount to claim that the FBI's level of incompetence is at least as large as their budget), and that an Apple firmware would solve the case, then it would be easy for Apple to make a firmware version that does the exhaustive search as the FBI wants, but only after having checked that the hardware serial number exactly matches some expected value, i.e. the exact phone from the San Bernardino case. Such a firmware would comply with the exact demand from the FBI without compromising the privacy of anybody else.

That the FBI claims to have tried decrypting the phone for one month and failed, is weird. That Apple refuses to help with the decryption with a firmware update limited to a single phone, is equally weird. What the whole thing seems to be is a political struggle about the right to privacy and the legality of non-judicial eavesdropping by law enforcement. The San Bernardino case is merely a pretext that is used to elicit reflex support from non-technical electorate. Apple found it expedient to play the role of the White Knight, from which they cannot now back away without alienating their consumer base.

Edit: the security system in an iPhone is a tower of elements, described (succinctly) in this document. An iPhone 5C runs on an Apple A6 chip, which the 5S and later models use an A7. The A6 has an onboard tamper-resistant device called the "UID"; the A7 has a second one called the "Secure Enclave". Since the iPhone in the San Bernardino case is a 5C, I won't talk any more of the Secure Enclave.

The UID contains an internal key that is unique to the device (let's call it Ku), and is unknown to anybody else, including Apple (whether the UID generates it itself, or it is generated externally and then injected in the UID on the processing chain, is unknown; I'll assume here that if reality matches the latter case, then Apple really did not keep the key). The UID never let that key out, but it can do an AES-based computation that uses that key.

The iPhone data is encrypted with AES, using a 256-bit key (Kd) that is derived from the combination of the user PIN and the UID key. Though Apple does not exactly detail that combination, it says it involves key wrapping, which is another name for encrypting a key with another key. We also know that a user can change his PIN, and it would be impractical to change the actual data encryption key Kd in that case, because it would involve reading, decrypting, re-encrypting and rewriting the gigabytes of user data. Thus, a plausible mechanism is the following:

  • The key Kd has been generated once.
  • When the phone is off, what is stored (in Flash, out of the UID) is an encryption of Kd by another key Kz.
  • Kz is itself the encrypting (wrapping) of the user PIN by Ku.

Thus, the unlocking entails obtaining the user PIN, submitting it to the UID, who returns Kz by encrypting the PIN with Ku. With Kz, the phone's firmware then recovers and decrypts Kd, and configures the crypto engine to use that key for all accesses to the user data.

While the actual scheme may differ in its details, the general outline must match that description. The salient point are that, although the tamper-resistant device (the UID) must be involved with each PIN try, it does not actually verify the PIN. The UID has no idea whether the PIN was correct or not. The wrong PIN counter, the delay on error, and the automatic deletion, are handled externally, by the firmware. This must be so because otherwise there would be no sense in Apple allowing the break to be performed with a firmware update.

Of course, one can imagine a kind of extended UID that would enforce the PIN verification and lock-out strategy, and could do so by running its own firmware that would be updatable by Apple. Such a device would really make Apple's help crucial. However, such a device would then be called a "Secure Enclave" because that's exactly what it is, and if it was added in the A7 CPU, it is precisely because it was lacking in the A6 and that absence was a vulnerability.

So what does it mean for a brute-force attack ? This implies that the UID must be invoked for each user PIN try. However, that's the UID -- not the phone's firmware. If you open the iPhone case, then the A6 CPU sub-packaging, the device UID can be accessed by connecting to it directly. It will involve some precision laser-based drilling and an electronic microscope to see what you are doing, so it certainly is not easy -- let's say it will cost a few thousands of dollars because that's the same kind of thing that is done (routinely !) by people who clone and resell satellite-TV access smart cards. Once connected, an external system can submit all possible user PIN for the UID to encrypt them all and provide the corresponding Kz keys (in my terminology above). Then the rest is done offline with a PC and a copy of the Flash storage. At no point is the phone's firmware invoked.

What the FBI currently asks for is an automatization of the process. They don't want to do precision drilling with lasers. They want to be able to plug something in the iPhone port without having to even open the case, so that the brute-forcing is done by the iPhone's CPU itself and the whole process can be done smoothly.

Thus, it is really not about the San Bernardino case. The FBI does not want a one-shot intervention from Apple; what they ask for is a tool that will be usable repeatedly on many phones. Apple is right in claiming that what the FBI asks for exceeds the specific case that serves as emotional pretext.

On the other hand, Apple could produce a firmware update that does as the FBI asks for, but only on the specific iPhone (identified through, for instance, the CPU serial number). And that firmware update would be specific to the 5C, and would not work on later models. There is no inevitability in Apple's producing a new firmware leading to a generic cracking tool for all phones of all models. But even if Apple complies with the a firmware that is specific to a single iPhone, the legal precedent will have been established, and Apple would find it hard to refuse other requests, from the FBI or from other countries where Apple has business interests (i.e. all of them).

A system which would ensure protection against user PIN cracking would need a tamper-resistant device that not only enforces the PIN failure counter and key erasure, but that device should also run a firmware that is not upgradable. The Secure Enclave has its own firmware, but it can be upgraded (firmware upgrades are signed by Apple, the Secure Enclave hardware verifies the signature). Even on an iPhone 6, Apple retains the ability to unlock arbitrary phones.

  • 4
    Yep, it's sounding an awful lot like this is two issues: the FBI is deliberately being dishonest in order to push an agenda, and because they want the tools to decrypt the tamper-resistant iOS devices. – Mark Buffalo Feb 21 '16 at 4:14
  • 1
    The device doesn't have a secure enclave, but it does have a secure device ID that can't be read, and you can't run the brute-forcing process without the device ID, which is why the only way to do it is to run it on the actual phone. – Mike Scott Feb 21 '16 at 14:42
  • 1
    @MikeScott: I have expanded my answer about the iPhone security model. With an iPhone 5C, the cracking must involve the phone, but not necessarily the phone's CPU or firmware (and, in particular, not necessarily a new firmware from Apple). – Thomas Pornin Feb 21 '16 at 17:04
  • The FBI doesn't really need authorization, they have search warrant. – noɥʇʎԀʎzɐɹƆ Feb 21 '16 at 17:30
  • Great edit! FBI is just lazy, and Apple doesn't want a legal precedent, and later phones have secure enclave anyways. – noɥʇʎԀʎzɐɹƆ Feb 22 '16 at 22:48

Please refer to Thomas Pornin's answer. Apparently, they don't even need Apple's help for this. In my opinion, they're trying to create a legal precedent.

My question is, if the cracking takes seven minutes, why not just release the update, wait ten or so minutes (coordinate with the FBI on this) and then release another update rolling back the change.

Of course, Apple can do this if they want to. If we look at this from a different perspective, and assume that the FBI needs Apple's help in order to decrypt this phone, we might find a lot of problems with the request:

The FBI won't likely let Apple do the cracking by themselves

Even if they do, the FBI will need to have full access to the device because of forensic guidelines and regulations which must be defended in court. Because of this, the FBI isn't likely to allow Apple to do the cracking themselves... even if they did, the device would have to be in the hands of the FBI at some point.

Because of data integrity requirements when it comes to US law, they can't simply "roll back" the operating system changes. Everything has to be intact or it could be disputed easily in court when they find anyone connected to those terrorists, and attempt to charge them.

In fact, Apple seems to be terrified of creating such a thing:

"...something we consider too dangerous to create. They have asked us to build a backdoor to the iPhone."

If Tim Cook doesn't even trust his own company to keep something like this secret, why on earth would he trust the government, which has a proven track record in failing in this area?

I feel that the White House's willingness to compromise is deception

Refer to this article:

The Obama administration told a magistrate judge Friday it would be willing to allow Apple to retain possession of and later destroy specialized software it was ordered to create to help federal authorities hack into the encrypted iPhone belong to Syed Rizwan Farook.

"Apple may maintain custody of the software, destroy it after its purpose under the order has been served, refuse to disseminate it outside of Apple and make clear to the world that it does not apply to other devices or users without lawful court orders,"

This seems like a red-herring. Who cares if an Apple engineer is there to provide assistance? Once it's in the hands of the feds, it will probably be copied quickly, reverse-engineered, and possibly provided to law enforcement for use in decrypting anyone's iPhone for any reason. The police are already able to copy phone data during traffic stops.

We don't know the details of how this is going to work, but once the device is unlocked, they may image the entire device, which would include the hacked operating system.

Although the judge instructed Apple to create the software for the FBI, she said it could be loaded onto the phone at an Apple facility.

Here's where it gets weirder: how are they going to use specialized brute-forcing hardware at an Apple facility? Are they going to bring in a massive, portable GPU farm? With all that equipment, if the the FBI is copying the contents (including the operating system), then it could be easy for this to be overlooked by Apple.

Who cares if Apple destroys it in the end if it's already been copied? Ask yourself this question: if you were in the intelligence business, would you turn down the opportunity to make copies? I sure as heck wouldn't, and I doubt any federal agency is going to turn down such a incredibly valuable intelligence-gathering tool. It's very possible the changes will be copied and reverse-engineered.

This could eventually create a huge privacy risk for everyone

Here's why this is bad: if the past is any indication, the US government is one of the worst keepers of secrets in the world. There are a plethora of leaks involving OPM, FBI, DHS, NSA, Pentagon, the Director of the CIA, contractors, etc. In some cases, sixteen year old basement dwellers have pwned their so-called defenses.

The US government often relies on dinosaur cyber-infrastructure and, of course, security through obscurity. If the government decides to create a copy, then security through obscurity will not protect this secret operating system for long. It's simply far too valuable.

If the government can't stop a bunch of teenage hackers, how can we trust them to keep something like this out of the hands of the bad guys who are infinitely more capable and subtle? You might be asking yourself how is this relevant... Well, once it's out there, someone is going to steal it, and all iPhone users will be at risk. It'll probably end up on various trackers eventually.

Could this be part of the government's war against encryption?

At the end of the day, it seems to me like they're trying to create a legal precedent to get the uneducated masses to rally against encryption so they can drum up support for anti encryption laws. They seem to be using the guise of terrorism to scare people into being afraid of the Big Bad Encryption Boogeyman, and legally allow all sorts of backdoors, most of which will be exploited and end up causing a far greater national security and privacy risk in the long run.

Apple's Side of the Story

It looks as though, as of February 25th, 2016, Apple used many of the points I've mentioned in this answer, and more, to defend themselves in court. You can read the full document here.

  • 1
    This answer complements well Thomas Pornin's answer. And I think you're right that the FBI is using this case to bring up support for anti encryption, and now even more so with the public opinion too. Terrorism makes people very emotional (and rightfully so), and when people get emotional they make decisions or choices based on these emotions rather than rationality. The FBI knows that and is trying to capitalize on this. Who would have thought the world's biggest public corporation would be the one defending the citizens right-to-privacy stance here... something's messed up. – djule5 Feb 23 '16 at 23:01
  • I feel that apple created a backdoor and they don't want to share it with the FBI. if they really cared about user privacy there would be no backdoor at all. – emory Feb 24 '16 at 2:25
  • @emory Why would they do that? It doesn't make sense to me. – Mark Buffalo Feb 24 '16 at 2:45
  • 1
    @MarkBuffalo if Apple cared about user privacy, then Apple would have explained to the judge why they are unable to comply with the FBI's request for technical reasons and they would have gotten out of the court order. That they did not suggest to me that there is no technical reason Apple could not comply with the FBI's request. If you have an Apple device and I want your data bad enough, I can simply kidnap key Apple employee dependents, until they give me the backdoor. – emory Feb 24 '16 at 11:15
  • @emory: part of the reason why iPhone 6 now features a Secure Enclave is specifically because this attack is possible. If Apple created the backdoor deliberately, then there would be no reason for it to upgrade the UID system with a Secure Enclave system. – Lie Ryan Feb 29 '16 at 13:25

The main logic board on an iPhone 5c has many connectors for devices like the camera, charging/data port, etc. to do direct memory access. Through these ports you should be able download the memory from the physical phone. They already know what data was on the phone from a backup weeks before the attacks. If you know what the encrypted data is, you know what the decrypted result is and you know the encryption formula is, then simple math would get you the key. Once you have the key, you can decrypt all the data. The main point to this is having the physical phone. No back doors required. Everyone has a secure phone as long as they maintain possession of it. A good hardware engineer and a software engineer should be able to crack the data within a day. It is like a book code (the most secure encryption method) but you know what the book is.

  • 2
    "If you know what the encrypted data is, you know what the decrypted result is and you know the encryption formula is, then simple math would get you the key." Err, nah, not if the crypto is known plaintext secure. Most currently used algorithms are even chosen plaintext secure, so you'd still have to brute force to get the key. – timuzhti Mar 15 '16 at 3:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.