3 ms·

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

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.

hamburglar 11y ago
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.
Someone 11y ago
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-the-secure-enclave.html 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")

hamburglar 11y ago

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.

Someone 11y ago

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-the-secure-enclave.html 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")