Arduino Leonardo Gets A Lockable Bootloader

Security is something that’s far too often overlooked in embedded devices. One of the main risks is that if the device doesn’t verify the authenticity of incoming firmware updates. [Walter Schreppers] was working on a USB password storage device, so security was paramount. Thus, it was necessary to develop a secure bootloader.

[Walter]’s device was based upon the Arduino Leonardo. Starting with the Caterina bootloader, modifications were made to enable the device to be locked and unlocked for programming. This can be done in a variety of ways, depending on how things are setup. Unlocking can be by using a secret serial string, an onboard jumper, and [Walter] even suspects a SHA1 challenge/response could be used if you were so inclined.

It’s never too soon to start thinking about security in your projects. After all, we must stave off the cyberpunk future in which leather-clad youths flick all your lights on and off before burning your house down in the night by overclocking the water heater. Naturally, we’ve got a primer to get you going in the right direction. Happy hacking!

16 thoughts on “Arduino Leonardo Gets A Lockable Bootloader

  1. Note well the requirement that HMAC comparisons be timing independent. It’s surprisingly difficult to get right, and depending on the specifics of your challenge/response scheme have a reasonable likelihood of compromising it.

      1. Hobgoblin does have a point. If the way of uploading new hex files is done with a proprietary chip or some proprietary closed source protocol in a binary blob added to your chips flash, you have no way of knowing if it doesn’t have a backdoor that allows to dump the flash or eeprom contents that might contain info you want to protect. The anykey bootloader in current state is simple enough to view all sources in a couple of hours and see that indeed everything is blocked from going in or out with the current modifications. We jump back to the main application at 0x0000 even before the usb stack is initialised for the bootloader to receive/send data. So it’s quite impossible for it to leak anything over USB when we don’t want it to.

    1. Never? Not for any reason, never? Hyperbole aside, I am not crazy that the Teensy 3 and above relies on a secondary microcontroller that isn’t open; but it is still more than a little useful in that state

  2. I made a lockable bootloader for arduino around 2014, it’s part of the source code for the final key. The hack is super simple, if the eeprom of the chip contains a lock code, the bootloader won’t run, if the lock code is removed, a physical button must be pressed for several seconds before the bootloader starts. This gives the user control of when the device flashed and protects against the device being compromised when inserted into untrusted computers.

      1. The anykey bootloader also adds a feature to unlock once by resetting the eeprom to lock position and then continue. That way a power yank would still keep the bootloader locked. And yes it was a similar idea, so I just starred your repo because it would have saved us some time if we knew about it before ;). Hope we can get to do full U2F with some more backers on our AnyKey kickstarter that would be nice ( We also plan on making the u2f and sha1-mac firmwares open source using open source libraries to do the heavy lifting : and

  3. I suspect that this would be brutally nontrival to do correctly(and almost certainly require a crypto-locked and/or implemented correctly the first time, in hardware, and unflashable ‘piggiback’ device); but I’d love to see an integrity mechanism based on visibility:

    It would certainly be a nerd feature; but if there were a way to read out/display the SHA1 and signature(if any) of what’s flashed onto a chip you would have a way of seeing if something is amiss without tying the hardware to the vendor’s signing key forever.

    Of course, if you implemented the readout/display on the device running the code malicious code could just lie to you, which is why some sort of piggiback system would probably be needed; but it would be very nice if it could be made to work.

    1. There are mechanisms to do this, but they are as you say seriously nontrivial. They work by verifiable erasure– essentially, overwriting all the memory of the system that can be and then forcing the device under test to answer hard-to-forge queries about it. If the device doesn’t have more memory than you think, then if it answers correctly every time it must be in the state you think it is.

  4. The AnyKey bootloader provides a way to fully lock your device from any read or writes (together with setting lock bits like LB1 & LB2 even external programming or reading with spi or jtag can be disabled). The way you allow unlocking is indeed up to the user’s application/sketch and the requirements. Having said that there’s plenty of libraries for AVR to get some kind of challenge response done right like micro ECC and

    The FinalKey did have a similar idea indeed! If we knew that a week ago it could have saved us some time ;) The anykey bootloader also has an added feature to only allow bootloader to load once and immediately lock again inside the bootloader. That way it’s perfect for upgrades after the challenge response you can jump into the bootloader that immediately sets the eeprom back to a locked position and continues to allow programming once. Even if power is lost during programming the loader would be locked again and a handshake would be needed again to unlock it. This is a necessary added ingredient to be secure : otherwise the user would be able to unlock the device and yank the power and have an open bootloader to indeed flash a custom image to do tricky things.

    Our kickstarter is just 8 more hours and with some extra backers we’re able to tackle SHA1, SHA256 and maybe U2F as well :

  5. Yes the final key did have a similar concept (I just looked it up and starred you on github ;) )! If we knew that before, it would have saved us some time making our own from scratch ;). Anyway the anykey bootloader also adds a custom lock code specifically for upgrading securely. The bootloader reads this and immediately sets it to the lock position again and then continues to allow programming once. That way if power is lost during programming its already back in the locked position and a secure handshake is needed again to unlock it once more. That’s a necessary added ingredient to being able to upgrade firmware and never stay in an unlocked position whereby indeed someone could upload a ‘copy sketch’. Doing hmac1 or sha256 yourself is also doable with some open source libraries like these : and

    Hope we get some needed extra backers to implement more features. Our AnyKey kickstarter is just 8 more hours, more support means more development time and features for everyone ;)

  6. We’re not using arduino ide at all in our AnyKey project. But as part of our bootloader work we needed to be able to upgrade the application code over usb. We saved time by re-using the caterina bootloader for atmega32u4 instead of writing a bootloader from scratch. And as a result that was released as open source. This is great because now it can now also be used in the arduino ide and by other people and projects.

    Like said: it’s entirely up to the users code how to lock/unlock. A simple serial message is ok for the isp sketch example. A button press or jumper might be ok for another project. However we’re going to go with a sha1 or sha256 challenge response to unlock it…

  7. Ha, I knew I recognized the hardware and case for this device. :)

    I purchased the exact same hardware, metal case and branding for $7 back in 2017.
    It also came preloaded with the arduino bootloader and sketches loaded to act as a HID.

    Don’t want to promote a direct link but searching ebay for `BadUsb Beetle Bad USB ATMEGA32U4` for the same device. If you wanna follow along at home.

    I’d love to get my hands on the Anykey to run some tests.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.