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

671–680 of 1001 posts

Re: A Message to Our Customers

#671

Post by d_theorist »

ajross wrote: post #639
d_theorist wrote: post #619

Earlier quoted context omitted.

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…

I'm not claiming it is in ROM or that it is not upgradeable if you are Apple and have physical access to the device. I'm not sure on that point. What I think must be the case is that Apple can't remotely upgrade the SE firmware as part of its iOS update mechanism. Although, to be perfectly honest, I have not seen this explicitly documented.

Re: A Message to Our Customers

#672

Post by wicket »

A phone without a backdoor would be illegal in the UK once the Snooper's Charter comes in to full effect. I'm very interested to see how the UK government will react to Apple's stance.

Re: A Message to Our Customers

#673

Post by d_theorist »

zabuni wrote: post #652
d_theorist wrote: post #619

Earlier quoted context omitted.

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.

But it's more interesting to think about the case where the phone does have a secure enclave.

Re: A Message to Our Customers

#674

Post by AYBABTME »

While I think protecting user data is important, I don't understand what the fuss is about. Anyone could (given technical knowledge + tools) take apart a phone, pull the encrypted data out of storage, and then brute force the encryption on a large machine.

The FBI doesn't need the modified iOS code, and that Apple write/not-write it doesn't change anything in the end, since someone else could just as well write the software with some reverse engineering.

[edit: if you downvote because I'm wrong, please explain because I'd love to know why]

Re: A Message to Our Customers

#675

Post by eridius »

ajross wrote: post #579
ChuckMcM wrote: post #549

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

How can they simply "push an update"? I've never seen iOS auto-update without first prompting the user, which I'm assuming is a very intentional limitation.

Re: A Message to Our Customers

#676

Post by cjbprime »

skybrian wrote: post #667
AceJohnny2 wrote: post #651

Earlier quoted context omitted.

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

"Computationally-signed bootloader" - but does Apple have the private key? If so, why can't they create another bootloader?

As I understand it, if the code running in the "secure enclave" (containing the private keys) is ever upgraded, the hardware side intentionally deletes the private keys as part of the upgrade, whether the upgraded code would want it to or not.

Re: A Message to Our Customers

#677

Post by facetube »

nly wrote: post #504
facetube wrote: post #468

Earlier quoted context omitted.

And it'd seem to open the floodgates for certificate authorities to be compromised as well. What's to stop the FBI from compelling a CA to create a special MITM certificate for a criminal investigation of a Yahoo user?

What makes you think the FBI, or a certain assisting agency, don't already have CAs in their pocket? They only need one. The 'rogue CA' threat that encouraged the development of HPKP covers this scenario. Hell, DNS TLSA records (which are a part of the now dead DANE concept) let you pin to any combination of PKI CA, public key, or certificate. One day we'll regret not deploying this stuff.

I don't doubt that they do, but having the rogue CA threat established as a legal precedent that can be used effortlessly by the police scares me a lot more.

Re: A Message to Our Customers

#678

Post by LeoNatan25 »

jwr wrote: post #583

The important lesson here is that it is time to design the next phones in a way that makes it impossible to either install a software update without unlocking the device or implement auto-erase functionality in hardware. That way for future phones at least, the issue would become moot: there would be no way for Apple to build and/or install a custom software image that allows brute-force password cracking.

Already there with 5S and above.

Re: A Message to Our Customers

#679

Post by [deleted] »

skybrian wrote: post #667
AceJohnny2 wrote: post #651

Earlier quoted context omitted.

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

"Computationally-signed bootloader" - but does Apple have the private key? If so, why can't they create another bootloader?

[deleted]

Re: A Message to Our Customers

#680

Post by jobead »

ParadoxOryx wrote: post #359
mmcconnell1618 wrote: post #345

Earlier quoted context omitted.

Why doesn't the FBI simply clone the current device, make brute force attempts and then clone again if locked out? Yes, lots of work but also doesn't force Apple to participate.

The iPhone uses AES encryption which would prevent cloning the flash storage [1]. There was an informative discussion of this over on AppleInsider - http://forums.appleinsider.com/discussion/191851 [1] http://www.darthnull.org/2014/10/06/ios-encryption

from that discussion, super informative details on how secure enclave is actually implemented:

http://forums.appleinsider.com/discussion/comment/2832533/#C...

Post reply on HN