Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A Message to Our Customers

apple.com

Post reply on HN
Print view View original

721–730 of 1001 posts

Re: A Message to Our Customers

#721

Post by erikpukinskis »

ChuckMcM wrote: post #549
epaga wrote: 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…

".. 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…

The Air Force and the FBI are different organizations wth different missions. I suppose they are both under the executive branch.

Re: A Message to Our Customers

#722

Post by cmurf »

kec wrote: post #660
em3rgent0rdr wrote: post #205

Earlier quoted context omitted.

Freedom from forced update is one of Stallman's motivations for free software. Just one terrorist attack + PR letter to customer + forced update away from loosing encryption on your phone.

On the other hand, if iOS were open source / the iPhone was able to run unsigned code there would be nothing stopping the FBI from just doing what they've asked apple to do themselves (assuming it's actually technically possible).

Open source doesn't preclude securing the boot chain. TianoCore implements UEFI Secure Boot, and it's BSD licensed. I think the bigger issue is the (unreasonably) low trust in things like secure elements and TPMs in open source, but that needs to change, and is rapidly off topic.

More on topic is whether Apple or even Google get out from under this if their on disk encryption mechanism is open source. If everyone owns e.g. LUKS (in a sense no one company owns/controls it) then can any one company be burdened by a court to effectively break everyone else's software by being told to create a backdoor?

Re: A Message to Our Customers

#723

Post by HoochTHX »

This is the FBI going after a Parallel Construction path. They already have all the information from the NSA bag o'tricks, but none of those can be used in court. But an unlocked phone unlocks the legal obstacles.

Re: A Message to Our Customers

#724

Post by skewart »

epaga wrote: 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…

"...and disabled Touch ID - which is hackable with a bit of effort to get your fingerprint."

As long as we're on the topic of encryption, phones, and law enforcement it's worth keeping in mind that in the US at least courts can compel you to unlock your phone with Touch ID, even though they can't compel you to give them a password. Communicating a password is considered speech, so self-incriminating speech is protected by the fifth amendment. Physically holding your finger to a device is not considered speech and so it's not protected.

I think this is an interesting, and perhaps underappreciated, aspect of a shift from passwords to biometrics for verifying identity. It would shift the power dynamic between civilians and government a bit - here in the US at least.

Of course, hopefully no one is in a situation where they need to protect themselves against over-reaching or unjust government officials any time soon.

http://www.engadget.com/2014/10/31/court-rules-touch-id-is-n...

Re: A Message to Our Customers

#725

Post by teacurran »

Why is there very little talk about the First Amendment in this whole discussion? They are asking to write custom software.

The supreme court has ruled in separate cases that: 1. that software is speech 2. that a person (corporations are people according to them) cannot be compelled to speak

It would seem to me that the FBI could perhaps subpoena technical documentation from Apple but it should be required to hire their own developers to write this software.

Re: A Message to Our Customers

#726

Post by orthecreedence »

mikeash wrote: post #636
imh wrote: post #623

Earlier quoted context omitted.

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 e…

I disagree. This is all about setting precedents. Once one of the dominoes falls, it's much easier for the others to start falling as well.

Apple is saying the FBI is using this law to expand their power to mandate a backdoor in all devices. If this is successful, then the FBI can mandate that all secure hardware/software companies backdoor their products.

Do we roll over and let the FBI do this because "oh, this is just one case, it's fine" or do we set a boundary? If a child does something wrong, you scold them immediately. You don't wait for them to do it the 10th time. By then it's too late.

Re: A Message to Our Customers

#727

Post by aetherson »

rsync wrote: post #540
coderjames wrote: post #403

Earlier quoted context omitted.

I'm not sure you can draw the conclusion that Apple can push OS updates to a locked phone. What Tim Cook wrote is that > "install it on an iPhone recovered during the investigation." > "the potential to unlock any iPhone in someone’s physical possession." So the FBI has the physical phone already. They can deliver to Apple who can disassemble it and either use a JTAG/Flash programmer on an internal connector to manua…

"I'm not sure you can draw the conclusion that Apple can push OS updates to a locked phone." The iphone contains a sim card. A sim card is a complete, general purpose computer with its own CPU and RAM and the ability to run arbitrary java programs that can be uploaded, without your knowledge by your carrier. You are owned . Deeply, profoundly, in ways that you have no way to manage/mitigate. The real question, for me…

One possible answer to your "real question":

I want to disclaim that this is pure speculation. I have no insider knowledge or indeed any particular familiarity with the institutions in question.

The FBI may want this authority and this precedent and think that this is a good chance to get it. They may say, "Well, the San Bernadino case is a high-profile case that may sway people, including judges, who would otherwise be less inclined to back our request. Who knows when the next nationally-publicized case will be in which the likely perpetrator carries an iPhone?" They may also believe that the current political climate is good for their case.

And they probably also believe that there's no harm in trying. If the courts rule against them, they haven't lost anything. If the courts rule for them, they get a brand new tool.

Re: A Message to Our Customers

#728

Post by philip1209 »

Their iMessage encryption is fascinating. It basically makes it impossible to retroactively decrypt iMessages. With a court order, they can start MITMing conversations, but unless they intentionally generate a MITM keypair they are cryptographically locked out of the conversation.

http://techcrunch.com/2014/02/27/apple-explains-exactly-how-... (Link to Apple's paper is in the article)

(Yes, Apple could add this key for everybody at the beginning, but if their intention is security then it is a brilliant system.)

Re: A Message to Our Customers

#729

Post by andromeduck »

ajross wrote: post #709
hannibalhorn wrote: post #703

Earlier quoted context omitted.

According to a former apple engineer that worked on this stuff, the enclave's firmware is indeed a signed blob: https://twitter.com/JohnHedge/status/699882614212075520 The key thing would be for it to lose all stored keys on update when the current passphase has not been provided, and it sounds like that may not currently be the case. Maybe in this case, Apple could comply, but a simple tweak would make it impossible…

But "on update" isn't really the issue. If the code can be swapped underneath it, how does it know an "update" took place? Again you're in the situation where all of that process would have to be managed by hardware , when what is really happening is that the enclave is a computer running signed software that can be replaced.

Having the hardware require both the signature to pass as well as a valid PIN/fingerprint can't be that difficult.

Die space is cheap nowadays, especially stuff that doesn't need to be on all the time because of the death of Dennard scaling.

Re: A Message to Our Customers

#730

Post by hannibalhorn »

ajross wrote: post #709
hannibalhorn wrote: post #703

Earlier quoted context omitted.

According to a former apple engineer that worked on this stuff, the enclave's firmware is indeed a signed blob: https://twitter.com/JohnHedge/status/699882614212075520 The key thing would be for it to lose all stored keys on update when the current passphase has not been provided, and it sounds like that may not currently be the case. Maybe in this case, Apple could comply, but a simple tweak would make it impossible…

But "on update" isn't really the issue. If the code can be swapped underneath it, how does it know an "update" took place? Again you're in the situation where all of that process would have to be managed by hardware , when what is really happening is that the enclave is a computer running signed software that can be replaced.

Sure, but the signed firmware could be written to delete any stored keys when it accepts an update and the phone's passphrase has not been provided. That's assuming that it manages it's own update process, has the firmware securely stored within it's own die, etc. It's entirely possible ... but only Apple really knows.

I would not actually be shocked if they originally did wipe out stored info on firmware update, but had some issues with people updating their phone and losing everything, so they ifdef'd that particular bit out in the name of usability.

Post reply on HN