Live data from Hacker News

A Message to Our Customers

apple.com

631–640 of 1001 posts

Re: A Message to Our Customers

#631

Earlier quoted context omitted.

"From what I understand Tim is doing, and I greatly admire, is trying to avoid a judicial requirement that they be able to do this on demand. The so called "back door" requirement, because he knows, as others do, that such a feature would be used by more than the intended audience, and for more than the intended uses, to the detriment of Apple's users." To be fair - the only reason he's doing it is because it would c…

"To be fair - the only reason he's doing it is because it would cause a significant drop in sales for Apple devices." That's not being fair at all. To say the only reason he is doing it is to protect iPhone sales doesn't speak to Tim's character. Of course he cares about sales, but he also cares about privacy.

You're probably right, but it's great to explain this decision in economic terms. It'll sink through to people who think privacy is only for "good" actors, and those who don't like the government hurting businesses.

Re: A Message to Our Customers

#632

Earlier quoted context omitted.

".. what this means is that even Apple can't break into an iPhone with a secure passphrase (10+ characters) and disabled Touch ID - which is hackable with a bit of effort to get your fingerprint." That is not exactly true. They wrote the OS, they designed the phone, they know where the JTAG connectors are. Cracking the phone apart and putting is logic board up on a debugger would likely enable them to bypass security…

> They wrote the OS, they designed the phone, they know where the JTAG connectors are. Cracking the phone apart and putting is logic board up on a debugger would likely enable them to bypass security. When a passcode is entered, the SoC queries the Secure Enclave with the passcode. If the passcode is correct, the Secure Enclave responds with the decryption key for the flash storage. The best Apple could do is sign a…

The phone involved in the San Bernadino case is a 5C, which does not have Secure Enclave.

Re: A Message to Our Customers

#633

Earlier quoted context omitted.

"locked" is a relative term. Anything encrypted can be broken with enough effort. But that is the semantic difference between leveraging a back door and brutally busting open the front door. I want a device where there is no back door. I hope you can appreciate that difference.

The iPhones with an A7 or later CPU should be secure against this. This whole thing is only an issue because the phone in question is an iPhone 5C, which uses an older CPU without the "secure enclave" system.

Would you expand upon this?

Re: A Message to Our Customers

#634

Earlier quoted context omitted.

"From what I understand Tim is doing, and I greatly admire, is trying to avoid a judicial requirement that they be able to do this on demand. The so called "back door" requirement, because he knows, as others do, that such a feature would be used by more than the intended audience, and for more than the intended uses, to the detriment of Apple's users." To be fair - the only reason he's doing it is because it would c…

"To be fair - the only reason he's doing it is because it would cause a significant drop in sales for Apple devices." That's not being fair at all. To say the only reason he is doing it is to protect iPhone sales doesn't speak to Tim's character. Of course he cares about sales, but he also cares about privacy.

Why would it cause a significant drop? Where would those people go?

Re: A Message to Our Customers

#635

Earlier quoted context omitted.

"locked" is a relative term. Anything encrypted can be broken with enough effort. But that is the semantic difference between leveraging a back door and brutally busting open the front door. I want a device where there is no back door. I hope you can appreciate that difference.

The iPhones with an A7 or later CPU should be secure against this. This whole thing is only an issue because the phone in question is an iPhone 5C, which uses an older CPU without the "secure enclave" system.

If it only applies to older iPhones, why did Cook write, "this software ... would have the potential to unlock any iPhone in someone’s physical possession"? (emphasis mine)

Re: A Message to Our Customers

#636
post #623

I'm clearly in the minority here, but I don't really understand Apple's position here, nor do I understand why everyone is rallying behind them. Apple built hardware which was not particularly secure. The software defaults to a four-digit PIN. They attempt to mitigate this by adding an escalating interval between entries, and by optionally wiping the phone after too many failed tries, but this is not set in stone and…

They address this at the end of the letter. They say it's "an unprecedented use of the All Writs Act of 1789 to justify an expansion of its authority." They go on to talk about what that precedent would mean. It's at the very bottom.

I don't buy it. The FBI is not trying to dictate how Apple builds their devices. They want Apple to take measures to unlock one device. How do they get from that to "[the government] would have the power to reach into anyone’s device to capture their data"?

Apple seems to be saying that if the FBI can ask Apple to install special software on one person's phone, then they can ask Apple to install special software on everyone's phone. But that's not how it works. The whole idea of requiring a court order is to only do this stuff on a limit scale when there's justification for it. It's like saying that the police shouldn't be able to have a warrant to search a suspect's house, because that means they could search everyone's house.

Re: A Message to Our Customers

#637
Cook wrote that "this software ... would have the potential to unlock any iPhone in someone’s physical possession." (emphasis mine)

Is that true? What if it's locked with a secure 128-bit (e.g. 10-word diceware) passphrase?

Re: A Message to Our Customers

#638

Earlier quoted context omitted.

The iPhones with an A7 or later CPU should be secure against this. This whole thing is only an issue because the phone in question is an iPhone 5C, which uses an older CPU without the "secure enclave" system.

If it only applies to older iPhones, why did Cook write, "this software ... would have the potential to unlock any iPhone in someone’s physical possession"? (emphasis mine)

I don't know. Either Cook is confused or I am. From everything else I've read, it's Cook. If I'm the one who's confused, then Apple really dropped the ball.

Re: A Message to Our Customers

#639
post #579

Earlier quoted context omitted.

They don't even have to do that. They wrote the OS, they have the signing key for OS updates. All they need to do is push an update to the device with a backdoor that allows reading off the unencrypted contents post-boot (possibly with the addition of a judicially compelled fingerprint scan or PIN brute force to get the encryption key out of whatever on-device escrow it's stored in). The only way to secure the device…

This is not really true. The secure enclave is a separate computer. It doesn't get software updates. > possibly with the addition of a judicially compelled fingerprint scan or PIN brute force to get the encryption key out of whatever on-device escrow it's stored in This is the whole problem. The keys are in the SE. You can't brute force the PIN because the SE rate-limits attempts (and that rate limiting cannot be ove…

Is that really true? The enclave's firmware is in ROM and non-upgradeable? I'd always assumed it got a signed blob like everything else does. Obviously it's possible to design a system like that, I just haven't seen it reported anywhere that it actually works like that.

Edit just to be clear: the requirement really is that the firmware be stored in a ROM somewhere, probably on the SoC. That's a lot of die space (code storing a fully crypto engine isn't small) to dedicate to this feature. Almost certainly what they did is put a bootstrap security engine in place that can validate external code loaded from storage. And if they did, that code can be swapped by the owner of the validation keys at will, breaking the security metaphor in question.

Re: A Message to Our Customers

#640

Earlier quoted context omitted.

"To be fair - the only reason he's doing it is because it would cause a significant drop in sales for Apple devices." That's not being fair at all. To say the only reason he is doing it is to protect iPhone sales doesn't speak to Tim's character. Of course he cares about sales, but he also cares about privacy.

Normally people on HN are much more skeptical about airy promises and assertions from corporate executives. I don't see what behavior on Tim Cook's part has indicated he's more to be trusted than anyone else.

"more to be trusted than anyone else"

Cook's responsibility is first and foremost to the stockholders, and secondarily to the customers. Decrypting the iPhone would seriously compromise the security of Apple's products, gravely damage the company's credibility, hurt sales, and drive the stock price down.

No CEO is going to take such a drastic step unless they are a craven, cowardly type who meekly obeys ask-for-the-sky demands from overbearing federal law enforcement types, and Cook surely did not rise to his current position by being a pushover.

That's not to say there won't be some kind of secret deal made behind closed doors, but secrets tend to get out. Apple would not be so foolish, I think. Yahoo? Microsoft? They just handed over the keys to their email to anyone who demanded it -- the Chinese government, the NSA -- but Apple has no history of this type of behavior. Surely Snowden would have revealed it if they had.

Post reply on HN