- Crypt(ograph)ic terms
- Symmetric encryption
- Asymmetric/public key encryption
- Cryptographic hash
- Digital signature
- So why lock a bootloader?
- What does a bootloader do with digital signatures?
- What are bootloaders doing at the moment?
- So... what do 'we' want?
- If there are any manufacturers perchance reading this blog, here is my personal opinion on what a perfect bootloader functionality might look like
- Comments (33)
My name is Ivo, and recently I posted this write-up on Reddit (check out the Android subreddit while you’re there!). The post gained quite a bit of traction, and to spread the word further, I'm now posting it here at Android Police. I hope it helps out those of you who are confused.
It’s necessary, if you want to talk about these issues, to get some cryptic terms out of the way, so we actually know what we’re talking about! If you want to find out more about these topics, just click on through to their respective Wikipedia articles.
This is the typical, familiar, scramble-your-data algorithm. You use one secret key, together with your data (called plaintext), and input them to the function. It spits out random-looking output (ciphertext). You put your ciphertext back into it with the same key, and you get your original data back again. With this, either exactly the same function does encryption and decryption, or one function does encryption and a similar, but different one does decryption. The most popular algorithm is called AES.
This is slightly different from the above. This time, you have two keys. One is called the public one, and it is figured out from the private one. The private key cannot be figured out from the public key. They only work in a pair as well: If you do encryption with one, you can only decrypt with the other. This is why it is special. If you encrypt with the private key, you cannot decrypt with the private key again, only with the public (and visa-versa). The most popular algorithm is RSA.
This is a one-way function. You can input as much data as you want into it, and it will come out with a fixed number of digits (usually in hex). The digits that come out do so in a very random, and mostly normalized way. A good property of a hash function is that changing 1 bit in your input, should have a 50% chance of changing every bit in the hash's output. This means hashes are fairly unique to any particular data, and can detect even the slightest changes in it by comparing two hash outputs together. The most popular hash function is SHA, the most well known is MD5.
This uses the last two above terms. You have a message, and you want to sign it. When they verify the signature, a receiving party can tell two things:
A) That the message came from you, and
B) That the message has come exactly as you intended it.
How? First, you make a private/public key pair, and publish your public key everywhere a while beforehand. People remember the public key and know that you made it. When you want to send a message, first you hash that message. The hash will let anyone know if someone has tampered with the message during sending. Then you encrypt the hash with your private key (you have now signed your message). You send off the encrypted hash with your message. To verify your message, the receiving party remembers the public key you sent out earlier. They use this to decrypt the hash, and then check this hash with one generated from hashing the message themselves. If they get a match, then they now know the two facts stated previously.
So why lock a bootloader?
A bootloader lets you change all the software on your phone. By locking it, you are prevented from doing so. Why do manufacturers do this? Well, they try to never say directly, but you can guess the reasons:
They don't want customers accidentally uploading faulty software to their phone, bricking it, and coming crying back
They want to give as little attack surface as possible to hackers looking to meddle with the phone, for whatever security reasons
At the request of various third parties, such as carriers
They don't want custom software being put on that gives the device extra functionality or lifetime
Disclaimer: I never said these reasons were going to make sense in your, the customer's, mind.
What does a bootloader do with digital signatures?
It uses them to check any update that passes through it. The phone keeps a read-only copy of the manufacturer's public key internally. The manufacturer then signs an update they want to give the phone. When the phone receives the update, it verifies the signature to check that the update came from the manufacturer, and only then lets it change the phone.
This means that the the manufacturer gets the best of both worlds: It stops customers from uploading unsigned changes to the phone, while allowing through only changes that the manufacturer has approved and signed. From a QA perspective, this is great! It also means that you, the customer, know that you are only getting official updates. No-one can hack an update onto your phone, or tamper with the manufacturer's before it gets to you. This means that signing is not necessarily a bad thing! If you just want to make sure you get official updates, signing is for you.
What are bootloaders doing at the moment?
Motorola and HTC especially have been using signed bootloaders that are permanently locked. This means that only the company is able to send updates to the phone, and there is no way for the Android modding community to do so unless they find a way around these measures.
Thanks to awesome android hackers around the place, exploits have been found along the way to allow many of these phones to be ‘set free’ from signature-checking. But some have remained to this day locked to their standard software, such as HTC’s Sensation and Incredible S, and Motorola’s Droid X and Droid 2.
Fortunately, in recent news, it seems HTC plans to reverse their current trend and release new phones with ‘unlocked’ bootloaders, and Sony Ericsson has said its new (sim-unlocked) Xperia line of phones is also very moddable. Samsung seems to already be onboard with this line of thought, with its Galaxy S II easily unlockable if you so wish.
So... what do 'we' want?
We, being the community of Android users who love to modify their phone, basically want bootloaders to follow the model that Google employs in its phones.
You can choose, by typing a command in an adb shell, whether you want your phones bootloader to be locked or unlocked. In its locked state, it will check signatures and make sure everything is official. Great for your average customer, who just wants peace of mind. In its unlocked state, it allows any custom modification, like CyanogenMod, to pass through.
When we refer to a locked bootloader, we mean one that is in its locked state, and usually also that the manufacturer didn't give us any option to unlock it. So when people say they've loaded an engineering version of a bootloader, it usually means they've found a way to load a bootloader made in the development of the phone, which didn't check for signatures (unlocked by default).
So we don't want unlocked bootloaders, or non-signing ones; that could be bad for the average customer. We want unlockable bootloaders. Cyanogen agrees! Note, the unlocking process shouldn't be something a normal person would be able to get to, or automatable. It should be a choice that a technical user can make.
If there are any manufacturers perchance reading this blog, here is my personal opinion on what a perfect bootloader functionality might look like
It should not be replaceable, or only replaceable by a signed manufacturer update. The rest of the phone should be.
It should have a locked state, where any updates to the phone are checked first (through signatures) to see that they're by the manufacturer
It should have an unlocked state, which allows any update to the software of the phone
These states should be switchable by a technical method
The bootloader should be able to tell what software is on the phone. It outputs a string, say, which includes a nonce and a signed answer to this question. The manufacturer can ask the customer to give them this answer from their phone. If the answer matches up with the signature of an official version of their software, then they can give support and/or warranty to the customer, because they know the software is in a certain state. If it does not match, they know custom software is on and they don't have to provide warranty and support.
Well that’s about all folks. I hope those of you reading here are now a little more in the know about this issue, and now know what to demand of your favorite phone manufacturer!
Image credit: Norebbo