If you were ever wondering what bootloader encryption, signing, and locking actually meant, this post is for you.

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.

Crypt(ograph)ic terms

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 again, only with the public (and visa-versa). The most popular algorithm 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 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.

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

  • Juancho

    You say "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, 2, and Milestone."

    However I have a Milestone and as many others I'm running Cyanogen Mod 7. In fact CM7 exists as many others because you can install it on Milestone because it has also being hacked.

    • http://www.AndroidPolice.com Artem Russakovskii

      Blame me for that, I added the Milestone without Ivo's knowledge, as I wasn't aware its bootloader got hacked around. It's still not officially supported by CM, probably due to all the additional hacking that is involved. All fixed up now.

  • achillea

    The Verizon Xperia Play Does Not have an unlockable bootloader. The Verizon Xperia Play currently CAN NOT be rooted. Maybe other versions can, but not the Verizon version. But noone is even talking about this.

    • http://www.AndroidPolice.com Artem Russakovskii

      Indeed, no Verizon phones currently have unlockable bootloaders, as just re-confirmed by http://twitter.com/#!/VZWSupport/status/74072016147324928, but we already knew that Sony Ericsson's unlocked bootloader deal was about a special breed of new-age devices - SIM-unlocked.

      Full requirements are here and aren't really a surprise. Unfortunate? Sure. Surprise, especially considering you're talking about Verizon Wireless? Not really.

      • EC

        VZW Support:
        @andrewwalberg I have confirmed we allow phones w/ unlocked bootloaders to be activated on our network. Sorry for the misinformation.


        • Coldman

          Looks like they've backpedaled shortly after that first tweet, and this is probably related to upcoming changes HTC is pushing on them.

  • BennyInc

    One issue I see: You say "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."

    This is slightly incorrect, as the two are generated together, and neither can be figured out from the other one. Until you determine which should be the public and which should be the private key, both are "equal" in that regard.

    • http://www.AndroidPolice.com Artem Russakovskii

      That's not true - you can re-generate a public key from the private key. See here for an example.

    • Ivo

      Actually that can depend on the specific public key algorithm used. What you say is technically true for RSA, but false for DSA.
      However keys practically are stored in such a way as that you can still generate the public key from the private with RSA.
      People should read over the wikipedia article if they want to find out more about it.

  • jbonics

    My droid 2 sucks period.

    • http://www.AndroidPolice.com Artem Russakovskii

      Gross, dude.

    • Coldman

      Ah, the power of proper punctuation.

  • http://www.xda-developers.com/ orb3000

    Great article :)

  • http://www.chainfire.eu/ Chainfire

    Custom software does not excuse the manufacturer from giving warranty on hardware, IMHO. From reading, it appears you disagree with me. I'm sorry, but flashing a custom ROM does NOT physically break my screen, no matter what you say. Yes, HTC repair once tried to convince me this was the case.

    Further I disagree that unlocking should be hard. All you do with that is making things needlessly difficult, which will only frustrate the user who wants to unlock, and lead to a lot of BS and nonsense in root-app and device support threads. Combining threads, emails, and PM, I get about 100 questions PER DAY about how to unlock (S-OFF) HTC's, etc. And I don't even have any HTC devices that are locked that way! I doubt I'm the only root-apps developer with this problem. You are just moving the problem to somebody else by making things difficult.

    How about I propose all rooting and unlocking questions in the world should be redirected to Ivo @ AndroidPolice ? Props for the OEM that integrates that message in their boot-up screen.

    While something like "fastboot oem unlock" is easy enough, it should not be any more difficult than that to do a full unlock (though I do agree one should not be able to replace actual bootloaders - that way, with modern devices, it is virtually impossible to actually hard-brick a device), and preferably easier:

    I would prefer that if you try to flash an unsigned kernel or something of the likes, that the phone would simply pop up a warning screen giving you the details that this is dangerous and will void your (software) warranty, with the user having to confirm. For extra credit, maybe it could be protected with a code you need to enter, that comes as a sticker in the box. This way, the corporate world can still stop their minions from messing with company devices, as they simply wont give said minion the needed code. (There are a lot of variations on this that could work well, IMHO)

    Either way, if it is done in such a way that it is pretty much impossible to hard-brick your device (Samsung does this well), I find the premise of making it (needlessly) difficult quite frankly ridiculous. It's a bit security through obscurity, which is never a good thing. It doesn't do anybody any good, it only serves to waste people's time and thus money. And the more difficult you make it, the easier the non-technical will be stuck in odd places, and all the problems, questions, and fallout that creates. No matter how difficult you make it, the non-technical will still try to get it done, and a number of them WILL ignore all warnings, guides, readmes, etc anyway, and the WILL find new and novel ways to f the process up.

    All IMHO of course, but then again, I believe root should be a standard feature and unlockable bootloaders shouldn't be an option, they should be the law.

    • Ivo

      Chainfire, it is possible for me to root my Desire HD, install SetCPU on it together with a suitable kernel, and overclock it until I damage the CPU. Or I can install CyanogenMod, and turn on the flash LED until it burns out. Should I be able to get a warranty for these sorts of actions, because software cannot break hardware?

      Intel have already designed modifications in their desktop CPUs around these sorts of considerations (i.e the cpu itself can detect when it has been overclocked), but the smartphone hardware scene is still very much in its teenage years, if not infancy. While companies currently aren't able to completely rule out every way of abusing a warranty claim with an open-access phone, I would not blame them one bit for enforcing a compromise at this stage.

      I never said that unlocking should be a 'hard' process. I don't consider that a non-technical user would ever have cause to use fastboot, for instance. I think you have read too much into what I have said.

      • http://www.chainfire.eu/ Chainfire

        Being able to overclock the CPU until it dies and burn out the flash are both hardware issues by itself. Even if you blame the software for that (which some would say is reasonable) there are still failures that you would have to work really hard at to blame the software for. And those need to still fall under warranty, period. Like, for example, a cracked screen. Throwing it all out is IMHO a much worse choice than keeping it all in, and though I can certainly understand why the OEMs would do so, it is still wrong.

  • Jos Nobody

    Problem of "custom ROM vs. manufacturer ROM" could be solved by bootloader with dual-boot option.

    I don't see a reason why not to have 2 systems on one machine.

    • MrBlack

      You would need room in internal read-only memory for both system partitions, and potentially for two separate user-data partitions. Keep in mind that manufacturer's ROMs are often quite large compared to those from the dev community; the stock ROM on my phone comes in around 300 MB, whereas something like CyanogenMod is around 90 MB. Plenty of people are already complaining of lack of internal space (hence the big push for apps2SD).

      We may get there eventually, but as of right now, the fairly limited internal storage space on a phone makes it hard to do.

    • Lemming Humper w/beans

      people are stupid, where a person is smart. if its going to cause more tech support or defective reasons they will keep it for lemmings of the world.

      lemmings like jelly beans.

  • Ahmad Nadeem

    I really needed this knowledge.........Thanks Man!!!!!

  • Jim

    Nailed it w/

    "They don’t want custom software being put on that gives the device extra functionality or lifetime"

  • Bobby Sweethearts

    Why not just just sell a dev version of said phones at a slightly higher price, because I am willing to bet that any dev would be will to pay the higher price for a phone that is vanilla android and has an unlockable bootloader that you could obtain the keys through a dev console once you register your dev phone, and the slightly higher price would cover the extra for the 1 or 2 year OEM warranty. Oh wait they already do this it's called the Google Nexus one and S... I think every OEM should have a Nexus phone! Or a dev/engineering model of there phone.

    • Ivo

      This is roughly what Sony Ericsson are doing. If you buy one of their new phones sim-unlocked, you'll be able to unlock the bootloader. But if you buy it simlocked to a carrier, you can't.

      • Bobby Sweethearts

        Well I am on Verizon and have been for a while and have had the Moto Droid A855 since it first came out, I am trying to wait for an LTE nexus to come to VZW but the longer and longer I wait the less likely it seems : / I just want a vanilla android device with an unlockable boot loader and something that is LTE Dual Core with a physical keyboard, why is this so hard to produce? Oyy VZW your making me want to jump ship and go to Sprint for the Nexus S 4g, but it has no SD card and no notification LED : /

  • Seth Daniel

    This is a great post. Having majored in Computer science and taken some networking courses I knew most of these terms and the general idea, but not exactly what was going on. For both me and for a completely uneducated reader this post is very useful and informative. Another great post from Android Police. Keep it up guys.

  • wpfn

    Kudos for a well written informative article!

  • Justin

    Great article! I have to agree that it should be as hard but not harder to unlock than a google experience device. ie: fastboot oem unlock. This keeps there from being any possibility of it happening on accident but still makes it really easy for those who are sure they want to do it.

  • day

    Seems that vendors protecting from own customers. Instead of give ability to customers unlock bootloader (may be with captcha, for security reasons) and lock it back (for security reasons again), after firmware uploaded.

  • Bennysaurus

    Hi Ivo, very well written article. This sentence is slightly incorrect though:

    "If you encrypt with the private key, you cannot decrypt with the private key again, only with the public (and visa-versa)."

    Public/private key encryption is one-way. The public key encrypts and the only key that can decrypt is the private one. The private key however can *sign* data, and that can be verified with the public key.

    • Ivo

      No benny, that is just the customary way to handle keys. When you say, "The private key however can *sign* data", do you realise that signing often involves using the private key to encrypt data (specifcally, a message hash)? There is no law saying it cannot be used to encrypt other data as well.

      The actual details of what can and can't be, (and separately) and what actually is and isn't done with private and public keys also depends highly on the specific algorithm being used in the crypto scheme. In some, there is a real difference between which key *has* to be the private and which is the public. In others, the choice is arbitrary.

  • http://a4tg.com jon

    why can't developers change the public key that is stored on the phone in the case of locked bootloaders?

  • http://www.notriddle.com/ Michael

    Jon: it's stored in unmodifiable memory.

  • levi

    Ive got a problem with my android (samsung gt-i9000) i got it around a year ago and rooted it a day after i got it, i flashed a darky kernel to it then a darkyrom i changed the battery icon then it decided to brick the phone, so i flashed the stock kernel and rom back onto the phone using oden, now everytime i go to flash any custom kernel or rom it bricks itself only a soft brick though. the kernel worked before i changed the icon now no kernel will work? please help as im getting rather pissed at my phone

  • bajivarma

    or what about the motorola way of official bootloade unlock support where you request for the key to unlock bootloader at the cost of you warranty