hen 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
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 ans