Hacker News Reader

Comment by venomsnake | Hacker News Reader

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.

View on HN

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.

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.

For those who truly want to ensure they data is "safe" I am sure that would be a small price to pay.

It should be optional, opt-in, and require voiding the warranty then.

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.

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.

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).

>loader A provides a new-key(PubKey,NextLoader) method which blanks the remainder of the device.

Assuming this updates the loader, that means anyone with physical access for five minutes can permanently brick the phone, without opening it.

Are we sure we want that?

Also, how can loader A modify itself?

> Assuming this updates the loader

It doesn't. The model I presented presumes that it is unchangeable.

> anyone with physical access for five minutes can permanently brick the phone, without opening it

Pick one:

- you can always get your phone working, even if you forget your key & only you can apply updates to any software on the phone. Anyone can replace the loader (but this wipes all other data).

- you can always get your phone working, even if you forget your key & only a third party can provide new versions of the loader.

- if you forget your key, your phone is permanently bricked.

> Also, how can loader A modify itself?

It can't.

In general though, it's fairly straight forward to have code copy itself into ram & run from there while overwriting it's source. The problem is that opens the potential to brick the phone (just like any method that allows updating the loader).

To avoid bricking in all cases, one _must_ assume that there is some un-replaceable software (or hardware mechanism to start software).

I'm coming around to believing it's possible.

Now I'm wondering whether you can place malicious RAM in the phone that changes instructions on the fly. Is that feasible?

Lots of things become possible once one is willing to decap ICs to get at the internals.

I'd expect security consious parts (ie: all of the theoretical "loader A") would need to run in SRAM (ie: ram that is in the same IC and thus harder to get at than external DRAM chips) or some other mechanism.

At that point, it becomes a question of physical hardening within the ICs. Some manufacturers have done things like put metal layers over fuses (to prevent them from being changed), I'd imagine the same could be done (at some cost) for a larger area of the chip. I'd imagine HSMs (hardware security modules) and TPMs (though these aren't as good) probably implement some of that. There also exist some chips targeted towards security purposes (not aware of any processors off hand) that could be used .

Wouldn't the regular ram also need hardening? If I can modify the ram, I can change the OS that's loaded to ram. Does this hardening slow it down?

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

Sure but at least the security of the system is proportional to the strength of your password.

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/Securi...

assuming you trust the updates in the first place

Reply on news.ycombinator.com