Hacker News Reader

Comment by mindslight | Hacker News Reader

And it most definitely is! From the privacy perspective, Apple was foolish to contest the order since this phone is vulnerable to Apple - a storage unit owner unlocks the unit for the police, what legal basis does Apple actually have to resist? Our values are driven by visions of ideal systems that can only be unlocked by their owner, but that is not what Apple has created!

Unfortunately, Apple is peeing in the pool for all of us that actually care about digital freedom. This case will set a terrible precedent, and prime government to preemptively address hypothetical devices that are secure.

View on HN

Storage unit owner has keys with which s/he can unlock the unit. Police does not ask storage unit owner to demolish his building at his own expense to get access to the unit if owner does not have keys.

Apple already "unlocked storage unit" to police where they had keys by providing police iCloud backups. Now police is asking Apple to "demolish the building".

Yes, police don't ask the storage unit owner to break open the door - they just do it. In this case they're even asking first and willing to reimburse Apple, which is nice for a change.

If you think anything more than one phone's security is being "demolished", then you've been mislead by Apple into thinking their devices have security properties that they don't actually have. If their reputation takes it a hit, it will be due to their negligent design and marketing, not from the inevitably resulting correction. Security does not suffer politics.

If the FBI could break into the phone without asking, they would have.

This analogy is garbage. No building is being destroyed. The FBI is asking for a key to this one unit, and the fact that Apple even has the ability to make the key should be evidence that the system isn't as secure as you think.

Inside the storage unit is yet another invincible locked container, but the FBI is betting on the key being easy to guess.

This is more like the FBI asking the storage unit owner to turn off the security system that he installed that incinerates the contents of the storage unit when someone tries to pick the lock, but only on the unit that the FBI has a warrant to search. The storage unit owner then responds that although he could put an off switch on that particular unit, it's an outrage and sets a horrible precedent that the police should ever ask him to turn off his security incinerator.

Um, what? If they didn't take a stand all their claims would be worthless. Their new phones are vulnerable as well, though I would not be surprised for upcoming products to make more use of private keys. (It's a tradeoff between usability and security.)

Their claims are worthless. In order to be secure against USG, Apple needed to eliminate the privilege of their own signing key, at least when the phone is locked. A vulnerability to Apple is a vulnerability to every country where Apple has a physical presence.

It's hard, but you actually have to throw the ring into Mount Doom. You can't just put in your pocket and promise to never use it.

Good allegory at the end!

Their claims are not worthless. Let's imagine that they plan on eliminating that privilege when the phone is locked. If the FBI establishes that it can force code to be written using the all writs act now, then it will also be able to prevent them from throwing away the key.

There's a difference between writing code to open one specific device on a legitimate investigation, and restricting what type of security Apple can implement on all devices sold.

But you're right, it's a similar activity. Which is why the ideal move this iteration would have been to nicely go along and avoid setting a precedent until Apple was actually shipping a secure phone.

The precedent is the use of the all writs act for this broader purpose. If it is not challenged now, then it will be established that Apple can be forced to create code to the design of the FBI. This is why it must be resisted now.

All Writs is a red herring. Sure the right to not be forced to take on certain paid projects is important, but that isn't the main principle which Apple is defending.

Even if Apple prevails, then the FBI subpoenas technical documentation and the signing key, and gets an independent party to write the code. The signing key would be another legal battle (and at least Apple is well funded unlike Lavabit), but that ultimately comes down to Apple having the only key to a container for which there is a warrant. Do you see this ever being decided in favor of the key holder's non-involvement, especially in such an unsympathetic case?

That key is a key which unlocks every single iPhone. There would be an extremely strong case that revealing that key would be a threat to national security. I think you'd find the case would be harder than you think.

That's precisely why all writs is not a red herring. If all writs is not limited at this stage, it will be used for exactly what you are most afraid of.

What I'm most worried about is a prohibition on software which implements government-unbreakable encryption, and after that, a prohibition on selling consumer devices with government-unbreakable encryption. This has nothing to do with All Writs, since 1. it wouldn't be forcing anyone to write backdoored software and 2. wouldn't involve a specific ongoing court case.

If revealing Apple's key for the iPhone's backdoor is a national security threat, then Apple can avoid this by simply using the key to open the one specific door a court asks (that's how the argument would go).

So why do you think Apple is adopting the strategy that they have chosen? Your line of reasoning is quite straightforward. Do you think nobody there has considered it?

Companies have an extremely hard time opening up platforms and removing their special privileges. The market friction caused by their closedness is what makes them money, and Apple is no exception.

Plus, they ultimately don't care whether proper crypto is outlawed or not. Sure they'll lobby for it not to be. But if they end up losing they'll just modify their products and still be the least-surveilling company - they're not particularly worried about Free software eating their market share.

Hold on - what has any of this got to do with openness? How is that in any way part of the argument?

Also, I believe you just called Tim Cook a flat out liar, since he has repeatedly, publicly talked about his and the companies beliefs about crypto.

An open design for a trusted computing platform would not contain an arbitrary fixed signing key. It would instead allow modifying the trust root subject to some time delay or proof of work. It would be thoroughly documented, giving the manufacturer no special insight into the use or working that any other developer did not have access to. It would thus not be specifically vulnerable to attacks by Apple, and by extension, USG.

Apple believes that proper crypto can be used to provide the best security for their users, and Tim Cook may personally believe that crypto provides the best rights to individuals. But corporations operate in terms of what is legal. If proper crypto were made illegal, that just shifts the playing field for everyone. Apple would still exist and try to provide the best security they legally could - they don't have a mortal stake in this fight.

So basically it has nothing to do with what we're talking about. You just think a completely hypothetical system which has never existed, let alone been subjected to any kind of attack, would be a better alternative, and so you think that what Apple is doing is in error.

It has everything to do with what we're talking about. We can analyze the security properties of systems in advance. It's called engineering.

This attack isn't some discovered flaw, but an explicit property of their system design. There are widely-used systems that hold up to the attack in question. For example, Linux's LUKS/dmcrypt does not have this vulnerability.

Apple wishes to use lower entropy passcodes, necessitating the use of trusted hardware. Few have gone down this road, so I've detailed properties of a hypothetical design that could be free of manufacturer backdoors.

Apple needs to either stop marketing their devices as secure against nation state attackers that can compel Apple, or actually build trusted hardware that's secure from manufacturer as I'm describing. Cryptography is not a "best effort" endeavor.

Accepting your first paragraph as true, even though it is debatable - nobody has even done that with the kind of system you are proposing. Until they do, you are arguing favor of an imaginary system over a real one. It should be obvious that this is not an approach to security.

You had asked what the current situation has to do with open/closed, and I detailed an open alternative. You're now arguing against my explanation as if it affects the main point. I didn't need to describe a better way in order to analyze the failings of Apple's system. If you aren't interested in an example of how open trusted hardware could function, then just ignore it and judge the system on its own merit.

The fundamental flaw remains that Apple utilizes closed-design trusted hardware based on a manufacturer backdoor. This type of system is insecure against the manufacturer (and by extension USG), and marketing it as secure against such is willfully negligent.

As I said they have never marketed anything in the way that you claim.

If you want to persist in that assertion, you should easily be able to point to the marketing you are refering to.

Just to be clear:

1. Apple does not market their devices as secure against nation state attackers.

2. You have not detailed any alternative that is.

> Apple does not market their devices as secure against nation state attackers.

Then what exactly is this court case for?

> You have not detailed any alternative that is

As I had just said, Linux's LUKS/dmcrypt. The authors simply do not have the power to unlock other peoples' volumes.

Some other properties are traded off, but since you are unwilling to discuss system models ("completely hypothetical"), then I don't see the point of detailing the landscape. A system can have a vulnerability without needing a nearly-identical system without the vulnerability for comparison.

LUKS/dmcrypt is a small component that cannot provide anywhere near the necessary features to substitute for the iOS security system.

You don't it to be nearly identical, but if it can't do the job, then it is an invalid comparison.

> If you want to persist in that assertion, you should easily be able to point to the marketing you are refering to

This case right here! We've got, by most anybody's standards, a legitimate search warrant. There's no judicial overreach with regards to scope; process is the only thing they're arguing in the legal realm. The FBI could adjust their request for technical documentation on the KDF, create their own hardware, and the forced creation aspect would disappear.

The only reason Apple didn't quietly unlock the phone was because the FBI publicized the request (against Apple's wishes), and Apple wanted to avoid the inevitable press field day undermining their reality distortion field of "privacy".

> LUKS/dmcrypt is a small component that cannot provide anywhere near the necessary features to substitute for the iOS security system.

LOL. And yet a default Debian install would be locked for eternity (barring implementation flaws, which are not under discussion here for either system).

You can't have it both ways - arguing the properties provided by each system differ, while simultaneously refusing to discuss security models. You're attempting to narrow the domain to a single point, so that no objective comparisons can be made.

The sheer ridiculousness of this statement leads me to believe I'm talking to an Apple partisan rather than someone who earnestly analyzes security, so I don't see the point of continuing this discussion.

Once again, you call Tim Cook a liar.

A default Debian install is nowhere near to being able to replace iOS as a practical smartphone OS for 1 billion users.

This is an indisputable fact. What is ridiculous is that you seem to be claiming otherwise.

We are talking about the real world where objective comparisons can very much be made. I'm trying to discus real software - not fantasy extrapolations.

For the record, if an open, secure, and practical alternative existed I'd much prefer it to what Apple has produced, and I have been hoping for such a solution since the iphone was introduced.

It seems a lot more like you're the one with an agenda to push.

Yeah, I'm with you on this. Apple really does have to help, and they're reluctant purely because they know they made a vulnerable device. Helping would make them look bad because it would bring to light that they have the ability to help.

It sounds like they could have made a device that even a firmware update couldn't break, but they didn't. I really don't see how they can refuse. Your analogy is good.

> It sounds like they could have made a device that even a firmware update couldn't break, but they didn't. I really don't see how they can refuse. Your analogy is good.

This is nearly impossible because the development lifecycle and end-user usability almost necessitates there be software or firmware updates that would be authenticated (to either fix dev bugs or help users).

The solution is to only allow firmware updates when the device is already unlocked.

To avoid bricks, a full device reset puts the security chip into an unlocked state after erasing the encryption keys.

Reply on news.ycombinator.com