Firstly, let's get some cryptic terms out of the way.
Symmetric encryption: 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.
Asymmetric/public key encryption: 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,
only with the public (and visa-versa). The most popular is RSA.
Cryptographic hash: 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 fairly random digits. These digits come out in a fairly random, and mostly normalised 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 ouputs together. The most popular is SHA, the most well known is MD5.
Digital signature: 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 companies 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 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
signing is not necessarily a bad thing! If you just want to make sure you get official updates, signing is for you.
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 might be bad for the average customer.
[TL;DR:] We want unlockable bootloaders. 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.
Edit:
What I think the ideal bootloader's functionality should be:
- 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 there you go. Everything you want to know about this bootloader business.
Quelle
