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