A Message to Our Customers • Hacker News Board

Re: A Message to Our Customers

#651

Post by AceJohnny2 » Wed, Feb 17, 2016, 5:55 PM UTC

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…

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

No, they can't. A quick update to recent hardware practices: modern SoCs like Apple's have something called "Secure Enclave Processor" that's on-die. This is the first thing to start when the chip is powered up, the thing that loads a cryptographically-signed bootloader, and the thing that gates a lot of IO with the outside world (like the NAND).

Hardware encryption on consumer hardware has existed for over a decade (look up Intel's TPM), and while it hasn't obviously taken hold on the more open Intel world, locked-down hardware platforms like Apple's top-to-bottom design has had much more liberty in implementing secure computing.

Furthermore, all debug/probing features can be disabled by fuses at the factory. The manufacturer can test the chip with those features on, and once verified, blow those fuses. No-one's JTAG-debugging that chip, not even Apple.

That said, Apple's focus on security and privacy ramped up in recent years. You want more secure, get more recent hardware. The downside, of course, is that if even Apple can't hack the software... neither can you.

Re: A Message to Our Customers

#652

Post by zabuni » Wed, Feb 17, 2016, 5:55 PM UTC

d_theorist wrote: post #619

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

The device in question does not have a secure enclave. It's a 5c.

Re: A Message to Our Customers

#653

Post by dntrkv » Wed, Feb 17, 2016, 5:55 PM UTC

d_theorist wrote: post #619

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

Fingerprint scan really isn't enough though since after a restart, iPhones require the password to be entered.

Re: A Message to Our Customers

#654

Post by sloanesturz » Wed, Feb 17, 2016, 5:55 PM UTC

bumbledraven wrote: post #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?

I believe you are correct. Cook probably meant that it would unlock any iPhone with the standard 4 or 6 number passcode.

Re: A Message to Our Customers

#655

Post by ubernostrum » Wed, Feb 17, 2016, 5:55 PM UTC

bumbledraven wrote: post #635

mikeash wrote: post #553

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)

Because it's likely that it wouldn't end with "unlock this 5C" -- it would eventually extend to the government forcing Apple to either stop providing the additional security features in its newer models, or find ways to ship something that looks kinda like the security feature but isn't really.

Drawing the line in the sand at "the government can't force us to hack this guy's phone this time" thus ends up being "can't force us to provide features to hack anyone else's phone down the line".

Re: A Message to Our Customers

#656

Post by xenadu02 » Wed, Feb 17, 2016, 5:57 PM UTC

0942v8653 wrote: post #374

germanier wrote: post #366

Earlier quoted context omitted.

Not if the check and wiping is done in hardware as claimed by Apple for newer devices than the one in question here.

Meh. Then the attacker can simply replace the hardware. Remember, our attacker model is Apple; non-cryptographic security measures mean very little to a company with such complete knowledge of the hardware and software involved.

Nope. On newer devices the key is derived from a random key fused into the SE during manufacturing, a key fused into the ARM CPU, and a key randomly generated on-device during setup (derived from accelerometer, gyro, and altitude data) and stored in the SE. The SE's JTAG interface is disabled in production firmware and it won't accept new firmware without the passcode.

You can't swap the SE or CPU around, nor can you run the attempts on a different device.

Re: A Message to Our Customers

#657

Post by ThinkBeat » Wed, Feb 17, 2016, 5:57 PM UTC

If I were a betting man I would put good money on the bet that a bypass exists and is well known to the government.

What parts of the government is a different matter.

This is a perfect setup. Get all the bad guys to run out and buy iPhones (good for Apple) believing that they are safe from the US surveillance machine.

Then the appropriate agency can slurp up whatever it wants.

Re: A Message to Our Customers

#658

Post by dclowd9901 » Wed, Feb 17, 2016, 5:59 PM UTC

greenpizza13 wrote: post #592

stevehawk wrote: post #572

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.

It's definitely one of those rare times doing the right thing is also the most profitable thing.

Re: A Message to Our Customers

#659

Post by ubernostrum » Wed, Feb 17, 2016, 6:02 PM UTC

vbezhenar wrote: post #239

This is very disappointing letter for me. It means that Apple can indeed build a backdoor into existing phones, they just don't want to do it (or so they speak). I was under impression that Apple employs security hardware which protects keys and makes impossible to penetrate that defense. If it's not the case, iOS security is not as good as it could be.

On their newer models, yes, there are hardware-based protections.

The guy in this case didn't have the newest model iPhone; he has an older 5C which is at least theoretically vulnerable to Apple being forced to push a bad software update to it.

It's hard not to see the effects of these things showing up in the way they design each successive generation of iPhones; each time, they add something which gives them more ways to say "nope, technically impossible to do what that court just ordered us to do".

Re: A Message to Our Customers

#660

Post by kec » Wed, Feb 17, 2016, 6:02 PM UTC

em3rgent0rdr wrote: post #205

threatofrain wrote: post #175

Earlier quoted context omitted.

I'm afraid I'm too skeptical to get the same assurances as you. Apple accuses the FBI of playing language games with the term "backdoor", but I think Apple has done the same. The fact that they can push weak OS updates to a locked phone is the backdoor . This means that they can already comply with the court order, and they likely will. This letter covers them from PR damage.

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).