[saurik]

> Apple is being asked to create a firmware version without brute force rate-limiting.

This is a one line of code change for Apple and would take them a few minutes. FWIW, there are people in the iOS jailbreaking community who could do this without the source code rather quickly. I'll even go so far as to say that we actually already have all the tools for this lying around for the iPhone 4, and with only minimal changes made by even less qualified engineers they would probably work on the iPhone 5C.

> With a sufficiently complex passphrase, the FBI is still SOL.

Most people use the 4- or 6- digit PIN number. One presumes that in this case the user did so (and you can tell, as the UI is different depending on the kind of passphrase used), or the FBI wouldn't be quite so excited to bother here. It takes mere minutes to crack a 4- digit PIN code on the iPhone 4.

> The fact that only Apple is in a position to sign firmware that could do this is a positive thing in this context. The only alternatives are no firmware signing at all (so everyone could run this attack), no updates at all, or enforcing the rate-limiting in a HSM (which is what they're doing on the latest generation iPhones).

You have conveniently removed "allow the user to lock everyone out from firmware updates except themselves" from the list of possible options :/. While I am perfectly happy with the idea that some people might want to allow Apple to update the firmware on their device, I would much rather no one be able to do that unless they go through me, and as I own the hardware and it is my data that is on the line, I should have the right to make that decision. Apple is selling locks, claiming them to be secure, while not only sitting on a master key but now claiming that it isn't really a master key, which is not just disingenuous but outright dishonest at this point.

[pfg]

I think there are a lot of conflating issues in this discussion.

Firmware signing and how updates are delivered are one thing. I would argue that having only one possible adversary is preferable to everyone being able to create firmware that runs on your device. If there's a practical and secure approach that would allow users to install only firmware updates they approve of, I'd be all for that[1]. In the end - please correct me if I'm wrong - this would require a user-generated key or passphrase of some sort, and then we're back at a brute-force problem and the question of how secure is that passphrase and how are rate-limits enforced.

The iPhone's disc encryption, however, does not rely on this so-called master key. That's why I think calling this a backdoor isn't a fair assessment. It's entirely reliant on the complexity of your passphrase. The iPhone's security architecture, including the firmware signing and in newer versions the secure enclave, make attacks against this significantly harder (or next to impossible, if the secure enclave firmware is actually read-only ... something that definitely needs to be clarified). Compare this to your typical desktop full-disk encryption, where you usually have no countermeasures whatsoever against this kind of thing.

[1]: Speaking as a developer. I'm not qualified to answer this for sure, but my gut feeling is that such a feature in the hands of typical end-users might actually be a bad thing for security.

[saurik]

> Speaking as a developer. I'm not qualified to answer this for sure, but my gut feeling is that such a feature in the hands of typical end-users might actually be a bad thing for security.

I think users should be allowed to make the security tradeoffs they consider relevant. Many people leave a key to the door of their house somewhere outside but nearby, yet I don't think the people who build locks should decide that that is never acceptable and decide to play parent and come up with a solution to this problem: I would prefer people to be informed about the tradeoffs they are making, but they should be allowed to do what they want. Meanwhile, this enables the people who want more security than "I trust Apple, all of Apple's employees, Apple's security from hostile third parties, and the government under which Apple does business" to go "above and beyond".

> That's why I think calling this a backdoor isn't a fair assessment.

I am using this term because Apple is using this term: they said "They [the FBI] have asked us [Apple] to build a backdoor to the iPhone." when what the result would be would still require brute forcing a passcode to get the data in question. They make it sound extremely hard, but in fact it is really easy for them to do this: it is a single line of code changed; what makes it possible for them to do this is not that they haven't bothered to build it, it is that they are moral enough to not want to do it, and they are the only people with the key... but the key, fundamentally, is equivalent to the power the FBI wants. The FBI could "build" this backdoor for themselves if Apple handed them that key.

[studentrob]

> I don't think the people who build locks should decide that that is never acceptable and decide to play parent and come up with a solution to this problem: I would prefer people to be informed about the tradeoffs they are making, but they should be allowed to do what they want.

Shouldn't Apple be allowed to do as it wants?

> what is fundamentally different is only that people realize the government might be able to force Apple to use their key.

The public already knows from the ongoing debate that the current iPhone is unlockable by Apple. What difference does it make if the key does not exist yet, as Apple says, or if it does, as you say? Everyone knows the power is in Apple's hands. We'll all demand better iPhone security as a result of this discussion.

> this enables the people who want more security ... to go "above and beyond".

I understand you are asking Apple for a specific feature that gives more security. Regardless of the existence of this particular case, you would still be trying to raise awareness and gather support for pushing Apple to implement that feature. Is that fair to say? I support you in that effort. I also think this discussion ought to be held separately, perhaps after the case, so that we can focus on not giving the DOJ any means to handcuff the tech companies. The results of this case will have a dramatic impact on all tech, and if you truly care about privacy and security, you will support Apple's stance.

Let's table the debate about how Apple needs to improve its phone security and allow users to update firmware, and focus on matters at stake: whether or not the DOJ should be able to compel Apple to hand over the key. Whether or not that key has been created is irrelevant to the fact that if the DOJ wins this case, it is one step closer to mandating that Apple make all their phones unlockable.

[acqq]

> I'll even go so far as to say that we actually already have all the tools for this lying around for the iPhone 4, and with only minimal changes made by even less qualified engineers they would probably work on the iPhone 5C.

Then there's even less reason to use All Writs to make Apple do it, unless it's to make the precedent to force the device makers to backdoor their products.

Just do it, for all of us, make that tool for 5C. But don't support FBI using this case to make "All Writs able to change products" precedent.

[saurik]

You seem to still fundamentally misunderstand the situation, as you seem to be challenging me to build the tool today and get Apple off the hook, as if that was all that mattered.

I can build the tool. What I can't do is sign the result. The only thing any of us are missing is the 4096-bit RSA encryption key used to sign the firmware. The way we load this tool onto the iPhone 4 is using a vulnerability in their bootloader that lets us bypass the signature check. There is only 512 bytes of data at question here, not some insurmountable amount of work.

[acqq]

> he only thing any of us are missing is the 4096-bit RSA encryption key used to sign the firmware.

Ah, so Apple's encryption does actually work.

That's the essence of the good encryption: everything is known, except the key. You are not supposed to have it. FBI, hopefully, isn't supposed to have it too. That's why we have laws. Checks and balances and stuff. Laws made for specific cases, not "we can do anything."

[saurik]

If this were a normal door lock that someone possessed the master key to, the FBI would have just requested access to the master key temporarily. The FBI is not operating outside the law here: they have a court order. While in some ways it would be more horrific, I'd almost rather see them ask the more analogous question "we would like a copy of your master key" to see how Apple responds, as they'd no longer be able to pretend like it would take them a lot of time to build what the FBI wants: the FBI would just be asking for literally 512 bytes of data that Apple has that stands between them and their goal.

[acqq]

It's not just what FBI orders, it's the unprecedented legal basis for the order, All Writs which simply states that they can order whatever they want. ("Why?" "Just because!")

Which is very bad if it is accepted this time.

[rrego]

You're really missing the point. Yes the only relevant code that is going to be run on that device will code signed by Apple. I don't think FBI will have direct access to this "key".

The FBI wants Apple to create "malicious" code/update/software version that would allow for multiple decryption attempts among other things. Apple CAN comply with these requests, probably easily. However, by doing so they will destroy trust in Apple signed code and set a precedent.

It doesn't matter WHO has the key because Apple will be acting in proxy.

[acqq]

I don't think you are responding to my post? At least I can't see which part of my post you comment, that is, what I am missing.

The issue here is if All Writs is a good legal basis for the precedent of "change your product."

[rrego]

Ah. I'm conflating multiple threads. I was referring to this https://news.ycombinator.com/item?id=11157666

I agree with you about All Writs, I don't see any precedent for "change your product". Thanks for pointing my mistake out.

[studentrob]

It sounds like you could really make use of that key