Self-signing custom Android ROMs

[mjg59]

The security model on the Google Nexus devices is pretty straightforward. The OS is (nominally) secure and prevents anything from accessing the raw MTD devices. The bootloader will only allow the user to write to partitions if it's unlocked. The recovery image will only permit you to install images that are signed with a trusted key. In combination, these facts mean that it's impossible for an attacker to modify the OS image without unlocking the bootloader[1], and unlocking the bootloader wipes all your data. You'll probably notice that.

The problem comes when you want to run something other than the stock Google images. Step number one for basically all of these is "Unlock your bootloader", which is fair enough. Step number two is "Install a new recovery image", which is also reasonable in that the key database is stored in the recovery image and so there's no way to update it without doing so. Except, unfortunately, basically every third party Android image is either unsigned or is signed with the (publicly available) Android test keys, so this new recovery image will flash anything. Feel free to relock your bootloader - the recovery image will still happily overwrite your OS.

This is unfortunate. Even if you've encrypted your phone, anyone with physical access can simply reboot into recovery and reflash /system with something that'll stash your encryption key and mail your data to the NSA. Surely there's a better way of doing this?

Thankfully, there is. Kind of. It's annoying and involves a bunch of manual processes and you'll need to re-sign every update yourself. But it is possible to configure Nexus devices in such a way that you retain the same level of security you had when you were using the Google keys without losing the freedom to run whatever you want. Here's how.

Note: This is not straightforward. If you're not an experienced developer, you shouldn't attempt this. I'm documenting this so people can create more user-friendly approaches.

First: Unlock your bootloader. /data will be wiped.
Second: Get a copy of the stock recovery.img for your device. You can get it from the factory images available here
Third: Grab mkbootimg from here and build it. Run unpackbootimg against recovery.img.
Fourth: Generate some keys. Get this script and run it.
Fifth: zcat recovery.img-ramdisk.gz | cpio -id to extract your recovery image ramdisk. Do this in an otherwise empty directory.
Sixth: Get DumpPublicKey.java from here and run it against the .x509.pem file generated in step 4. Replace /res/keys from the recover image ramdisk with the output. Include the "v2" bit at the beginning.
Seventh: Repack the ramdisk image (find . | cpio -o -H newc | gzip > ../recovery.img-ramdisk.gz) and rebuild recovery.img with mkbootimg.
Eighth: Write the new recovery image to your device
Ninth: Get signapk from here and build it. Run it against the ROM you want to sign, using the keys you generated earlier. Make sure you use the -w option to sign the whole zip rather than signing individual files.
Tenth: Relock your bootloader
Eleventh: Boot into recovery mode and sideload your newly signed image.

At this point you'll want to set a reasonable security policy on the image (eg, if it grants root access, ensure that it requires a PIN or something), but otherwise you're set - the recovery image can't be overwritten without unlocking the bootloader and wiping all your data, and the recovery image will only write images that are signed with your key. For obvious reasons, keep the key safe.

This, well. It's obviously an excessively convoluted workflow. A *lot* of it could be avoided by providing a standardised mechanism for key management. One approach would be to add a new fastboot command for modifying the key database, and only permit this to be run when the bootloader is unlocked. The workflow would then be something like

• Unlock bootloader
• Generate keys
• Install new key
• Lock bootloader
• Sign image
• Install image

which seems more straightforward. Long term, individual projects could do the signing themselves and distribute their public keys, resulting in the install process becoming as easy as

• Unlock bootloader
• Install ROM key
• Lock bootloader
• Install ROM

which is actually easier than the current requirement to install an entirely new recovery image.

I'd actually previously criticised Google on the grounds that using custom keys wasn't possible on Android devices. I was wrong. It is, it's just that (as far as I can tell) nobody's actually documented it before. It's important that users not be forced into treating security and freedom as mutually exclusive, and it's great that Google have made that possible.

[1] This model fails if it's possible to gain root on the device. Thankfully this would never hold on what's that over there is that a distraction?

Comments

[mjg59]

The problem there tends to be that the various custom recovery images get maintained separately from the custom ROM images, and so you'd end up having to get the recovery image maintainers to include some set of public keys but not all of them because that'd kind of defeat the point.

The model I was thinking of was something along the lines of having an additional (small) mtd partition in the system image which would ship empty. If it's empty, stock recovery would use the built-in keys. If it's populated, stock recovery would ignore /res/keys and pull them from the partition instead.

Hmm. Does fastboot inherently know about partition names, or does the bootloader parse the mtd metadata? If the latter, this seems easy enough to prototype...

[(Anonymous)]

Yeah, a keys partition (or a general boot/recovery metadata partition) would be useful for this sort of thing. I regret that we didn't define any standards for that (standardizing on the fastboot protocol and general boot/recovery mechanism worked very well).

In recent years, Nexus devices have been using GPT (which conveniently allow named partitions), but different OEM bootloaders take different approaches to managing this (including forcibly overwriting the partition table if it doesn't match what's expected...)

Being more prescriptive about bootloader behaviour is on my "what to do next time" list.

- brian

[(Anonymous)]

Custom recovery images could also just use the bottom X KB of the recovery partition to store user/distro keys. The bootimg header lets the bootloader know where to find the kernel and ramdisk (and I think DT these days), and the rest of the partition is ignored by the bootloader. You'd likely lose installed keys if you reflashed recovery with the bootloader, but that's probably a reasonable behaviour. Recovery could, of course, ensure that they survive self-updates.

If the major popular custom distros made a point of publishing their public keys, the major custom recovery developers could also choose to include them (possibly with UI to enable/disable, etc).

- brian