[shuckles]

I’m not sure I appreciate the value of literally bringing your own keys. My device generating them on my behalf as part of a setup process seems sufficient. You’d use openssl or something and defer to software to actually do keygen no matter what.

[rkagerer]

I agree it seems sort of academic at first blush, but I'm going to venture a guess it's the idea that you own them, instead of Apple.

So you can eg. keep a backup on your own (secure) infrastructure. Transfer them when switching devices or even mirror on two different ones*. Extract your own secret enclave contents. Improve confidence they were generated securely. And depending on implementation, perhaps reduce the ease with which Apple might "accidentally" vacuum the keys up as a result of an update / order.

*Not sure how much these two make sense in the iOS ecosystem. I know on the Android side I'd absolutely love to maintain a "hot standby" phone that is an exact duplicate of my daily driver, so if I drop it in the ocean I can be up and running again in a heartbeat with zero friction (without need to restore backups, reliance on nerfed backup API's outside the ones Google uses, having to re-setup 2FA, etc. and without ever touching Google's creepy-feeling cloud).

[kbolino]

You would need to have a completely trusted software and hardware stack to actually own the keys. And that is already hard enough to get on a PC where ownership still means something, it is not going to happen on most mobile devices. To whatever extent you trust any of the stack already, the Secure Enclave is a better bet than BYOK. The real risk, as you imply, is if Apple is able to compromise the security coprocessor with an OTA firmware update, but they can definitely already push a regular OS update that exfiltrates any key you type in.

[codedokode]

Just make an airgapped Linux device on a DYI FPGA CPU. This part is not that difficult comparing to persuading commercial vendors let you use your own cloud and your own encryption/backup mechanisms.

[rkagerer]

Yeah... unfortunately it ought to be the other way around. They should have a hard time pursuading us to trust them enough to use theirs.

If your phone company asked you to give them the key to your house, in perpetuity, how would you feel about that? (Particularly if they insisted you sign a 15 page Terms of Use first that disclaims all their liability if anything goes missing).

[grahamj]

It depends what kind of backdoor the UK is asking for but "encryption backdoor" sounds like cryptographic compromise. I don't know if that's what it means but either way the only way to be sure your keys are secure is to generate them yourself.

[kbolino]

BYOK does not provide any additional security over the Secure Enclave (and similar security coprocessors). In fact, unless the Secure Enclave were to directly accept your input and bypass the OS, BYOK is worse because the software can just upload your key to a server as soon as you type it in. Whereas, a key generated on the Secure Enclave stays there, because there exists no operation to export it.

[grahamj]

I don't believe it's the SE itself that encrypts user data so it must already be the case that the key is generated outside the SE, sent to it for storage, and is retrieved if the user is authenticated.

So the difference between Apple generating the key on device and storing it in the SE and the user generating it and storing it in the SE is that the user can use a known-secure key generation algo. If Apple generates the key you can't be sure it's cryptographically secure and doesn't have a backdoor.

[shuckles]

The SE’s AES engine line encrypts and decrypts data to flash, and the SEP is responsible for generating all keys.

At this point, the people who claim they can’t trust Apple’s key generation should also distrust Intel or AMD or any other vendor’s key generation as well. Might as well generate keys by hand.