Live data from Hacker News

A Message to Our Customers

apple.com

331–340 of 1001 posts

Re: A Message to Our Customers

#331

So the FBI is asking Apple to build a tool that will unlock security measures of an existing iPhone, like the one in the San Bernadino shooting, and allow it to be read. The problem with this is that no such tool should be possible to build. It should not be a matter of yes or no; it should be simply impossible for Apple to build such a tool without the private key of the user, which Apple does not have. If it is pos…

It's not possible now. The FBI is asking Apple to change iOS so it will be possible in the future.

The FBI is asking that it be built now and then loaded onto the already recovered phone.

> Specifically, the FBI wants us to make a new version of the iPhone operating system, circumventing several important security features, and install it on an iPhone recovered during the investigation.

Re: A Message to Our Customers

#332
post #295

While we believe the FBI’s intentions are good, it would be wrong for the government to force us to build a backdoor into our products. And ultimately, we fear that this demand would undermine the very freedoms and liberty our government is meant to protect. Tim Cook Kudos to this guy for standing up to an idea. Now on practical notes, this is about security, providing a digitally secure platform to both users and pr…

The court order says Apple should make the software only work on the specific phone in question. Nobody could modify the software to work on other phones any more than they could make the changes to iOS themselves.

Apple is misrepresenting the situation and perhaps it's because they're afraid that in the future the government will come knocking again, but I think it hurts them to not be completely above-board about this.

Re: A Message to Our Customers

#333
post #314
post #308

Earlier quoted context omitted.

I don't understand your comment. The iPhone in question is protected with an unknown passcode. Auto erase is enabled, so brute-forcing the passcode will erase the data. However, a new OS version without auto erase and that accepts passcode input from USB would allow the FBI to try all combinations. How is Apple at fault because most any passcode scheme can be cracked via brute-forcing all comginations?

> However, a new OS version without auto erase and that accepts passcode input from USB would allow the FBI to try all combinations. It shouldn't be possible to just add a new OS onto the phone without the restrictions in place, without knowing the passcode first.

While I agree, this is not what OP's comment was about. He makes it sound like Apple is forced to write a decryption tool that exploits existing backdoors into the encrypted content.

Highly ironically, the current "Error 53" hullabaloo is exactly about what happens once security it tightened to the extreme.

Re: A Message to Our Customers

#334
post #163
post #2

Huge props to Apple - here's hoping against hope that Google, Facebook, and Amazon get behind this. One thing I was wondering is how Apple is even able to create a backdoor. It is explained toward the end: "The government would have us remove security features and add new capabilities to the operating system, allowing a passcode to be input electronically. This would make it easier to unlock an iPhone by “brute force…

I don't see how this "reassuring"; to me it's rather very confusing (as mentioned in many other comments). If Apple could in fact write a software backdoor, doesn't it mean that the backdoor exists, at least potentially? And how can one be sure that Apple is the only company able to build that door? At the very least, couldn't the right Apple engineer be either bribed or forced (by terrorists or the government) to bu…

It's not a backdoor, it's a frontdoor. In cryptography, there's no way to make repeated attempts more computationally expensive. The lockout just an extra feature Apple put on, that Apple could easily remove. If we're going to have 4- and 6- digit PINs, there is no way to stop a dedicated attacker frome brute-forcing it. None.

Re: A Message to Our Customers

#335
There needs to be a distinction between state security and "retail" security. State security agencies have the legal framework to compel Apple to do anything and not even talk about it. What I call "retail" security is any act by any legal enforcement agency in the country. Their requests are bound to be in large numbers and for all kinds of things. On top of that, these requests, apparently, are not yet covered by a legal framework. Hence the need to force upon an old law to try and make Apple comply.

What's at stake for Apple is not only their principles but also one of their marketing pillar: "you, the user, can trust us with your data/privacy." By asking Apple to give that up, and quietly, you actually are asking them to undermine their business model. Shareholders will not appreciate that if they wouldn't have a chance to hear about it first. The Apple brand would lose from its value and it would reflect in the AAPL share price.

My point is that the whole thing needs to have legal backup. And Apple is asking for this exact thing: give me a law to use. And not something from the 1700's.

Re: A Message to Our Customers

#336

Earlier quoted context omitted.

If in pursuit of an active investigation (i.e. the devices are still in active use), a police agency could invoke the All Writs act of 1789, and have Apple be instructed to introduce security vulnerabilities, with the next regular upgrade of iOS, such that after the phone is upgraded, it can be captured by the FBI, or whatever police force is involved, and the data recovered. A large percentage (and presumably the th…

But this request was made specifically for the phone in the San Bernardino case. In which the owner is dead and the phone is locked. This implies it is possible for Apple themselves to apply an iOS update to a locked phone in order to disable the erase-on-repeated-failure feature.

This is my question, too. Can iOS updates be applied to a locked phone? Seems like it should be a simple yes/no answer (and I thought the answer was 'no') but I can't find any clarity here or elsewhere.

Re: A Message to Our Customers

#337

Earlier quoted context omitted.

This limitation must be built into security hardware used by iPhone so software couldn't do anything about it. I was under impression that it's how iOS security model works. If it's not and in fact this check implemented in iOS itself, it's much weaker protection and it's really looks like an intended backdoor from Apple.

It sounds like it is built into hardware with newer iPhones containing the secure enclave, but not for an older phone like the iPhone 5C.

I'm really interested to know more about this. Does TouchId secure enclave really enforce the password attempt limits?

Re: A Message to Our Customers

#338
post #289
post #2

Huge props to Apple - here's hoping against hope that Google, Facebook, and Amazon get behind this. One thing I was wondering is how Apple is even able to create a backdoor. It is explained toward the end: "The government would have us remove security features and add new capabilities to the operating system, allowing a passcode to be input electronically. This would make it easier to unlock an iPhone by “brute force…

Does Apple do an amazing job protecting their users' privacy? Yes! But frankly in this case I find the FBI makes more sense than Apple. Apple says: All that information needs to be protected from hackers and criminals who want to access it, steal it, and use it without our knowledge or permission As I understand, Apple complains about the introduction of this new threat model: 1. criminal steals someone's iPhone, 2.…

[deleted]

Re: A Message to Our Customers

#339
What happened that now the companies can talk about these gov requests? The most nefast thing in these gov orders about terrorism is that the companies were forbidden to discuss it publicly.

Re: A Message to Our Customers

#340
post #219

Earlier quoted context omitted.

It sounds like it'd be trivial to nop out the timer on repeated passcode attempts. Which makes sense... Leaving any short passcode trivially crackable.

Yes but like where would you nop? You can't statically analyse the code because the image is encrypted at rest (and potentially partially in ram also?)

The code which decrypts the system (and is responsible for wiping the drive on repeated failures) is definitely not encrypted. How would it be able to take the input in order to decrypt the drive.
Post reply on HN