5 ms·

No need. The only thing apple must do is change the ios key management. 1. Once you buy the phone you (via itunes) create a RSA key pair. Put one of those in t

No need. The only thing apple must do is change the ios key management. 1. Once you buy the phone you (via itunes) create a RSA key pair. Put one of those in the phone. That key is set and bootloader uses it to verify loaded updates. 2. ios updates come to you signed by apple, you must resign them with your itunes and then they could be loaded. So you obtain the ability to sign your own software on your own device. In that case no amount of Apple assistance can help FBI until they obtain your private key.

zdkl 11y ago
assuming you trust the updates in the first place
btreecat 11y ago
Which for most users will end up stored in "My Documents/Downloads/my_apple_key.pem" and with out a password.
- shimon 11y ago
  Sure but at least the security of the system is proportional to the strength of your password.
- pquerna 11y ago
  Aassuming this was real, Apple would store the private key in Keychain[1]. Keychain is encrypted with your login password generally, and can have an ACL to only allow iTunes.app as an allowed application without further user prompting. [1] - https://developer.apple.com/library/mac/documentation/Security/Conceptual/keychainServConcepts/02concepts/concepts.html#//apple_ref/doc/uid/TP30000897-CH204-TP9 https://developer.apple.com/library/mac/documentation/Securi...
ikeboy 11y ago
You lose your key, now you can't upgrade the phone. Nobody can, so the phone goes down in value. Perhaps the ability to completely restore shouldn't require your own signature.
- DamnYuppie 11y ago
  For those who truly want to ensure they data is "safe" I am sure that would be a small price to pay.
  - ikeboy 11y ago
    It should be optional, opt-in, and require voiding the warranty then.
- mjevans 11y ago
  If you've lost that key you can't get in anyway. That's what a factory reset (which would not include the old decryption key) update is for. That scenario, updating with removal of the previous configuration, is pretty much baked in for both the case you mentioned and the reselling/refurbishing the device circumstances.
  - ikeboy 11y ago
    It's very difficult to bootstrap something like that and also make it updatable. If the key can be changed, then some software X can update it, and that software itself must verify the key. You have X updating Y and Y being ultimately responsible for updating X. Not so simple. Given that nothing like that is out there as far as I know, you'd need a more specified model to prove it's even possible. It's not obvious from the proposal above.
    - codys 11y ago
      This really isn't difficult to do: - loader A stores a (PubKey,NextLoader) and has the ability to blank (via actual blanking or deletion of an encryption key) the entire device. - loader A provides a new-key(PubKey,NextLoader) method which blanks the remainder of the device. - Loader A also provides a update-loader(NextLoader) method that doesn't, but also doesn't update the PubKey. Before accepting the new NextLoader, it verifies it against the stored pub key. Could also allow things like updating the PubKey if the update is signed by the previous PubKey Spec presumes only access is via the loader A api, PubKey would really need to be stored somewhere safe (HSM, TPM, etc) to discourage direct hardware access. Probably also could use the PubKey to encrypt the NextLoader. New phones ship either: - without a pubkey or next-loader, and require initial provisioning to do anything (fairly inconvenient) - ship with a flag set that prevents updating the loader, ie: requires updating the key (less secure, probably need to specify further how this occurs to avoid the security hazard from un-updated phones from being too great).
api 11y ago
That would require Apple to give up total control of the software ecosystem, which they're not willing to do. iOS is their kingdom. This is another factor in play here. Apple could make devices "yours" and therefore un-hackable in this way, but to do that they'd have to surrender their own master key. Apple wants to keep their master key but not hand it over to the feds since they want a market reputation as the Swiss Bank of device vendors, so they have to go to the mat on this. If they lose either they lose the security/privacy crown or they lose the app store walled garden. There are IMHO two reasons for Apple's platform fascism. The more self-interested one is that they want app store profits. The second more user-focused one is that they really want to keep iOS from turning into the shitware and malware disaster that Windows has become. On one hand Apple's walled garden keeps out certain forms of innovation and lets them dictate the terms, but on the other hand it lets them exclude trash like Superfish or Comodo's "security" junk.

zdkl 11y ago

assuming you trust the updates in the first place

btreecat 11y ago

Which for most users will end up stored in "My Documents/Downloads/my_apple_key.pem" and with out a password.

shimon 11y ago
Sure but at least the security of the system is proportional to the strength of your password.
pquerna 11y ago
Aassuming this was real, Apple would store the private key in Keychain[1]. Keychain is encrypted with your login password generally, and can have an ACL to only allow iTunes.app as an allowed application without further user prompting. [1] - https://developer.apple.com/library/mac/documentation/Security/Conceptual/keychainServConcepts/02concepts/concepts.html#//apple_ref/doc/uid/TP30000897-CH204-TP9 https://developer.apple.com/library/mac/documentation/Securi...

ikeboy 11y ago

You lose your key, now you can't upgrade the phone. Nobody can, so the phone goes down in value. Perhaps the ability to completely restore shouldn't require your own signature.

DamnYuppie 11y ago
For those who truly want to ensure they data is "safe" I am sure that would be a small price to pay.
- ikeboy 11y ago
  It should be optional, opt-in, and require voiding the warranty then.
mjevans 11y ago
If you've lost that key you can't get in anyway. That's what a factory reset (which would not include the old decryption key) update is for. That scenario, updating with removal of the previous configuration, is pretty much baked in for both the case you mentioned and the reselling/refurbishing the device circumstances.
- ikeboy 11y ago
  It's very difficult to bootstrap something like that and also make it updatable. If the key can be changed, then some software X can update it, and that software itself must verify the key. You have X updating Y and Y being ultimately responsible for updating X. Not so simple. Given that nothing like that is out there as far as I know, you'd need a more specified model to prove it's even possible. It's not obvious from the proposal above.
  - codys 11y ago
    This really isn't difficult to do: - loader A stores a (PubKey,NextLoader) and has the ability to blank (via actual blanking or deletion of an encryption key) the entire device. - loader A provides a new-key(PubKey,NextLoader) method which blanks the remainder of the device. - Loader A also provides a update-loader(NextLoader) method that doesn't, but also doesn't update the PubKey. Before accepting the new NextLoader, it verifies it against the stored pub key. Could also allow things like updating the PubKey if the update is signed by the previous PubKey Spec presumes only access is via the loader A api, PubKey would really need to be stored somewhere safe (HSM, TPM, etc) to discourage direct hardware access. Probably also could use the PubKey to encrypt the NextLoader. New phones ship either: - without a pubkey or next-loader, and require initial provisioning to do anything (fairly inconvenient) - ship with a flag set that prevents updating the loader, ie: requires updating the key (less secure, probably need to specify further how this occurs to avoid the security hazard from un-updated phones from being too great).

api 11y ago

That would require Apple to give up total control of the software ecosystem, which they're not willing to do. iOS is their kingdom. This is another factor in play here. Apple could make devices "yours" and therefore un-hackable in this way, but to do that they'd have to surrender their own master key. Apple wants to keep their master key but not hand it over to the feds since they want a market reputation as the Swiss Bank of device vendors, so they have to go to the mat on this. If they lose either they lose the security/privacy crown or they lose the app store walled garden. There are IMHO two reasons for Apple's platform fascism. The more self-interested one is that they want app store profits. The second more user-focused one is that they really want to keep iOS from turning into the shitware and malware disaster that Windows has become. On one hand Apple's walled garden keeps out certain forms of innovation and lets them dictate the terms, but on the other hand it lets them exclude trash like Superfish or Comodo's "security" junk.