Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I look forward to finding out how this plays out. This tack actually seems like it could work. I'm also curious what Apple would do operationally after being forced to hand over that key. What are the implications of rolling those keys and what ability do they have in that regard? What changes would they make to their next gen security systems to address this situation?


I think it would be easy to send each device new firmware encrypted first with Apple's secret key and then with the public part of an asymmetric key that the device owner controls (derived from the master password and the device ID) and have the secure enclave check both keys before accepting an update.

Problem with that is that forgetting your master password would mean "no more updates for you". So, to be a bit safer, Apple should restrict that to updates to the secure enclave.

Also, Apple would have extra work creating a unique upgrade package for each device, and network traffic would increase, as Apple wouldn't be able to use CDN's for distributing those upgrades.

Edit: I'm not sure that would work. The device would still have to send their key to Apple, giving Apple the ability to create the package, and giving law enforcement the opportunity to request the keys.


There is, unfortunately, nothing easy about "the public part of an asymmetric key that the device owner controls."

How does the device owner control it? Apple doesn't want to be responsible for Genius Bar calls from customers who lost that strip of paper with the huge hexadecimal code on it and now can't ever upgrade their phone again.


I think there could be a market for an optional feature like this. If you enable the super-duper crypto, you have to acknowledge in triplicate that you won't come crying to the genius bar because they can't help you. They could offer a way to print out backup keys (and a really slick method of reading the printed keys with the camera because hey it's apple) and make you sign an oath in blood that you understand that's your only hope of decrypting your data.

Edit: honestly, if apple provided such a mechanism, they'd be winning on all fronts. 1) a user is in control of whether or not there are recoverable keys (simply don't print them out or burn them if you did) and how well-protected they are (are they in your bedside table? taped to the top side of a drop ceiling tile? in a safe?). 2) you have a good answer for the government: go find the keys at the guy's house if they exist. 3) it's possible to be really serious about security and use the device in a way that is the same as if the backup keys simply didn't exist.


It doesn't have to be a huge hexadecimal code; it just needs to be as complex as the device's unlock password. After all, that's what the user, through his choice of password, chose as the desired security level. In fact, it just _could_be_ the unlock password.

The secure enclave (https://www.mikeash.com/pyblog/friday-qa-2016-02-19-what-is-...) could generate a public/private key pair, keep the private part for itself, and give up the public part when given the unlock password.

It could even generate a new key every time someone asks for one, and only accept the last one it sent out.

But yes, as I outlined, one problem with this is "no more updates for you".

A way halfway around that could be for the secure enclave to accept unsigned firmware updates, but to first destroy the device's encryption key ("sorry, no more updates for you, unless we are allowed to erase your device first")


Whats the "secure enclave"? What part of the asymmetric key does the owner control? I would like to know more about this.


Relocate their HQ and keep this part of the process (packaging all the components into a single build and blessing it) outside of the US?




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: