> The Federal government isn't asking Apple to create a backdoor. Their asking apple to use the backdoor that already exists.

Basically. Unfortunately, most of the reporting is focused on the payload Apple is being asked to create and doesn't draw enough attention to that "existing backdoor" that will allow such a payload to be successfully installed.

Eliminating that "existing backdoor" should be a priority. I see some, here, expressing the thought that Apple might be working on that. I think Apple needs to be pressed, hard, on that very subject.

Supposedly, the backdoor has already been fixed by the Secure Enclave, which was included in newer models of the iPhone.

Supposedly, and also supposedly the Secure Enclave doesn't defend against this, depending on who you ask and how they're speculating. I've yet to see anything authoritative on this from someone in a position to know for sure.

The good news is that if you have a good password, not just a simple numeric passcode, you should be safe against this sort of thing regardless, unless the authorities can coerce or trick you into revealing your password.

Apple is reframing it this way to the media but not technically untrue.

Is this the same key that Apple uses to publish updates to iOS?

It's sloppy to call a vulnerability a backdoor. Yes, Apple failed to fully secure the 5c and may even possibly have failed to fully secure the 6s against this attack. So it is vulnerable to this attack, but the backdoor doesn't currently exist.

Also, I would expect if it is technically possible, that Apple will be pushing an iOS update which closes this particular vulnerability going forward. Obviously not an update the FBI will be installing on this particular phone!

I believe their intent is to make iOS secure even against an adversary that has physical possession of the phone and even against an adversary with the ability to sign custom builds.

In cryptography and computer security, a vulnerability (a backdoor) exists whether or not an exploit exists.

>vulnerability (a backdoor)

This is at best imprecise. The HN privacy advocates have taken to calling all vulnerabilities backdoors on the (not insane) belief that manufacturers are out to get them, but there is a distinction.

Backdoors are a special case of vulnerabilities inserted intentionally by an attacker into ostensibly secure designs to allow the attacker back in once the device has left his control. For example, if Apple configured iPhones to accept two PINs, one set by the user and the other set by Apple at manufacturing time, we could say the iPhone is backdoored. If some engineer went rouge and marked his own code signing key as trusted, that's a backdoor.

When you say something is a backdoor, you assign blame for its actively malicious and undisclosed insertion. Either the organization is evil or someone subverted the organization, and this person must be caught and punished.

Most vulnerabilities happen because their creators didn't know better, or found mitigation to be not worth the cost. Apple is a little bit extraordinary in considering "itself, under legal coercion" under its threat model at all.

You might disguise a backdoor as an ordinary accidental vulnerability, and this is a reasonable assertion to throw around when someone who should have known better, whose peers were doing better chose an insecure design. i.e. Juniper switching their design to use known-broken cryptography.

The signs here certainly point to a vulnerability that ought to be mitigated (and possibly has been under the Secure Element system), but not a deliberate flaw in iOS's design. Vulnerability, not backdoor.

Apple intentionally created a platform where they hold almost absolute control over devices.

They can install new software, inject code into auto-updated applications, MITM SSL by hooking local device APIs, MITM iMessage by using their CA to sign new certificates. Their control over end-user devices is astonishingly complete.

They can do all of this without no external validation (except when jailbreaks are found), as the platform itself prevents 3rd parties from decrypting Apple's OS updates, viewing the operation of the device, introspecting Apple's code, or introspecting the encrypted application code shipped on the device.

They've intentionally done this, and justified this massive set of backdoors under the ridiculous assumption that they can defend device owners against all possible compromises of Apple's trust position, both from within (such as changing business management) and without (governments, espionage, and compromise), not just now, but many decades to come, all without any checks or balances.

How is this not the very definition of backdoor?

Suppose the manufacturer exerted no control over the device. No code signing, no sandboxing, no security hardware, etc. Then anyone, not just the manufacturer, would be able to replace the PIN verification routine.

If the manufacturer's ability to sign code is a backdoor, then so is absence of code signing.

You're assigning them the moral failure to perfectly secure the iPhone only because they have tried to secure it at all. It's subject to strictly fewer attackers; in my book, that's a good thing.

> If the manufacturer's ability to sign code is a backdoor, then so is absence of code signing.

In that universe, you can run any encryption software of you're choosing, and verify the software written by others.

Nobody has more privileges over the device that exceed those of the device's owners.

> You're assigning them the moral failure to perfectly secure the iPhone only because they have tried to secure it at all.

Legally and ethically, it doesn't matter.

Legally, cryptography is protected expression, and you can use cryptography to encrypt whatever you like -- including information that would otherwise be subject to a lawful search under the fourth amendment.

However, the fourth amendment doesn't have a crypto "participation award" clause; if you left a backdoor in place, the government can compel you to use it.

Ethically, if they chose to leave themselves this backdoor (and all the others), the system is weak. If it's not the FBI today, it's the NSA with a NSL tomorrow, or foreign espionage, or a disgruntled employee, or new corporate management.

Indeed I can run the encryption software of my choosing, and so can the FBI to bypass its rate limiting, in which case it's exactly as weak as the iPhone.

With physical access I can replace any security software you have in place. The hardware needs to enforce its integrity.

As if your everyday person is capable of verifying or validating or even making these decisions if left to them.

I work in tech and I wouldn't feel comfortable making all those decisions.

iMessage is definitely "backdoor-friendly" due to how the CA server works. In past court cases (e.g. [1]) Apple has said they do not have the capability to wiretap iMessage and they have refused to create it, and the government has backed off. Maybe in part because in those cases there were active iCloud backups which provided messages in near-enough-to-realtime that the government wasn't in a good position to force Apple to hand over access to the backdoor. Or maybe because the targets of those particular investigations weren't unsympathetic enough. This case is the one the government has been "waiting for" to push the envelope and see if they can force Apple to provide a backdoor against their will.

[1] - http://www.nytimes.com/2015/09/08/us/politics/apple-and-othe...

Your reply does nothing to justify why "backdoor" and "vulnerability" should be considered synonyms. What you say is true of "vulnerability", I've never heard someone call a buffer overflow vulnerability a "backdoor".

A vulnerability is a backdoor if it's placed there intentionally.

That's what Apple has done.

A window is a vulnerability into my house, but it is not designed for passage in the same way that a backdoor is. There is a subtle difference between a backdoor and a vulnerability that is worth respecting, in my opinion.

The key analogy starts to break down at some point. The "master key" as you put it is that Apple has the engineers, experience, and digital key that enables them to create a second key for any IPhone manufactured pre secure enclave. The argument here is that once Apple creates that second key the effort required to steal it is significantly lowered. You can't steal something that doesn't exist yet.

It's more analogous to forcing everyone to use a shorter password composed of only numerical digits because it makes brute forcing easier.

The mere existence of this new less secure IOS makes Apple even more of a target. The slightest chance that it could leak would render more than the hundreds of iPhones the FBI want's to unlock completely insecure.

> The argument here is that once Apple creates that second key the effort required to steal it is significantly lowered. You can't steal something that doesn't exist yet.

The key exists. If someone were to steal it, they could sign any version of iOS they want.

I think the resources required to successfully steal Apple's private key for signing updates, which is presumably locked down very robustly, is an order of magnitude greater than the resources required to modify iOS to remove the erase and timeout features. The latter is very difficult especially without the source code, but it's hard for me to believe that it's harder than stealing Apple's key.

Just having the key doesn't automatically make it easier for you to create the new IOS. That task is significantly easier for Apple to do than for you to do. Much of security is raising level of effort for an exploit to a high enough level that it's not worth the investment required to create it.

If Apple creates the new IOS for you though and all you have to do is get your hands on it then the investment required just got smaller. Any reduction in the investment required for an exploit should be very carefully evaluated. Saying things like "This can't possibly be used by someone else." is either disingenuous or signifies that you don't adequately understand the issues, or you are lying to yourself. Whichever one of those that it is. It's in Apple's and frankly my best interest that someone highlight the truth of the situation.

[EDIT]: The below is more hyperbolic than I intended after a second reading. I'm leaving it since I already hit submit but I wanted to apologize for going there. :-(

This is like saying

    Look... We'll create a nuclear bomb but it's okay we're
   the only ones who will have it and nobody else is going
   to be able to get one. 

Maybe you can guarantee that no one else get's enough information from you to build one. However once you've built one the chance that someone could get the information from someone involved in your project to accelerate their creation of a nuclear bomb just increased by a non-trivial amount. And the potential risks are really high. Pretending otherwise would be foolish.

My claim is that the resources required to steal Apple's keys are significantly higher than the resources required to modify iOS in the way required. Since an successful exploit requires both modified iOS and the keys, if I am correct then creating the modified version does not significantly decrease the resources required to exploit.

When I claim it can't be used by anyone else, I mean without Apple's signing keys. There are no shortage of jailbreak developers that would be happy to work for whoever pays them, and could build tweaks in to iOS with the signing keys.

For the government to make the necessary modified version of iOS, they need to have or acquire a team of skilled engineers that either already have detailed knowledge of iOS and the devices it runs on, or a way for their team to learn that knowledge. This would probably be somewhat expensive in both money and time.

To acquire Apple's keys, the government only needs someone who can replace the device key and re-sign a new iOS package, and a sympathetic judge that will sign a subpoena, warrant, or national security letter. This is practically free and shouldn't take more than a day or two (warrants are sometimes granted near-realtime).

I don't understand why would think taking Apple's keys (which wouldn't require "stealing") somehow requires more resources? A warrant or nsl is much cheaper than a team of developers.

You make this sound hard: there are tons of qualified people who could do this in less than a week, including myself. We already have all of these tools just sitting around from the iPhone 4, and some of us have emulators for more recent devices: the only thing we don't have is Apple's key.

I was talking about getting someone to steal it.

I doubt that it's as easy as you think it is to get a NSL.

Tom Cross[0] in this tweet[1] was the first person I saw with the distinction in calling the FBI request an exploit rather than backdoor. This Vectra Networks blog post[2] explains this distinction in better technical detail.

[0] https://en.wikipedia.org/wiki/Tom_Cross_%28computer_security... [1] https://twitter.com/_decius_/status/699932604737417216 [2] http://blog.vectranetworks.com/blog/apple-vs-the-fbi-some-po...

Actually that's irrelevant because the government can always coerce companies or individuals to introduce backdoors if there aren't any. Software developers have the arrogance to think that technology can solve political issues.

> Actually that's irrelevant because the government can always coerce companies or individuals to introduce backdoors if there aren't any.

The FBI is trying to do just that and Apple is fighting it. That is why this case is so important.

Except they're not. If the FBI was trying to force Apple to keep this avenue of attack open in all future versions of iOS then I would be 100% behind Apple, but that's not what's going on. The FBI is asking Apple to exploit an already existing vulnerability.

Do you not think this is where it is headed? The FBI has been complaining about device security for awhile. They finally have a 'terror' case to use in order to try and swing public opinion. To think that the FBI only wants a single phone (we have found out later they have many) unlocked, and only wants it to work until Apple closes the security hole is naive.

The difference in this case is that a backdoor can be introduced after the fact. That is, it is possible to load a new version of iOS onto this locked phone with the backdoor in place. Ideally, one should not be able to update a locked phone in such a way as to introduce a backdoor to allow for brute force passcode attempts.

First of all this isn't about brute forcing passcode attempts, it is about bypassing the passcode altogether. If the phone is open and can be made to automatically download and install a software upgrade, then this is possible, even if the storage is encrypted. Also, given that Apple is the phone maker, they can of course be coerced to produce phones with this capability, whether they want it or not.

There is is no "ideally" ;-)

Not that I agree with backdoors, but Congress should be able to. The courts shouldn't.

Are you supportive of the government's position in this?

There is clearly a vulnerability on top of which a backdoor could be built. But equating the two seems to be interpreting things in favor of the government.

Are you saying the Government has no legitimate interest in the contents of a suspect's or deceased's mobile phone?

I believe that police forces have an interest in using whatever resources are legally available to them to pursue their inquiries, and as such, the FBI is acting according to its mission.

My position is that the government as a whole - including the legislative, executive, and Supreme Court, have a duty to national security and civil liberties that would be severely compromised if the FBI prevails here.

I agree with the ex director of the NSA, that strong encryption and secure devices are good for national security, and protect us against cyberterrorism, and that this is far more important than this individual case, and so the FBI should not be allowed to prevail.