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!
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.
This is a good reason to NEVER use the Teensy….. Teensy requires a binary blob and would exclude you from experimenting with security.
Has there been any work done on an open source bootloader for Teensy?
In the place of developing your own binary blob and preventing people to change the firmware in the products you develop ?
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.
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
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.
Thaf wouldnt protect against uploading a firmware that reads back the passwords.. encryption with sanity check tk verify it is trusted is necessary here.
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 (https://www.kickstarter.com/projects/715415099/anykey-the-usb-password-key). We also plan on making the u2f and sha1-mac firmwares open source using open source libraries to do the heavy lifting : https://github.com/cantora/avr-crypto-lib and https://github.com/kmackay/micro-ecc
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.
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.
A challenge response with sha256 is pretty secure and pretty easy to do. If your device only unlocks the bootloader only after a succesfull challenge response you wouldn’t be able to write your altered firmware to readout the eeprom. Using an external programmer only allows flashing an alternate firmware by doing an erase first (because of lockbits LB1 and Lb2 set and can only be cleared with an external programmer by doing a full erase). So when you erase to write the new firmware you also erased the stored secrets in eeprom: so that’s one possible route I see that’s pretty secure and most likely the one we’ll use as we didn’t reach our target of 10k to do more work… Ofcourse nothing is perfect. I know about re-setting fuses by de-capping a chip. But if we get/take it to this level, you can also do similar things to any other hardware/chip based security device. Here’s the nintendo wii being owned ;) : https://www.bunniestudios.com/blog/?p=227
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 https://github.com/kmackay/micro-ecc and https://github.com/cantora/avr-crypto-lib.
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 : https://www.kickstarter.com/projects/715415099/anykey-the-usb-password-key/description
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 : https://github.com/cantora/avr-crypto-lib and https://github.com/kmackay/micro-ecc.
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 ;)
Non sequitur. If you are doing critical stuff and need to securely lock down the boot and run-time, why are you using ‘arduino’?
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…
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.
Yes or you could just buy any atmega32 chip or any arduino clone and then you just need to write firmware + software for it so that it’s user friendly and secure and make it work on all OS’s and have multiple keymaps ( not just qwerty ) working.
You’ll need a usb protocol to change the passwords and something to lock/unlock the bootloader and develop a secure bootloader + flash it to that device before distributing it. Also you’ll need to set the proper lockbits for each device before shipping. So when all this work is done. You’re allowed to ask some extra for the efforts right?
Also the AnyKey looks indeed similar on pictures but we did make some changes to the pcb’s compared to the badusb beetle you mention here. For one yours is probably not fitting properly in the usb ports because the pcb is too thick. (just one of the things we improved with AnyKey on hardware level because yes we did start out with that similar hardware for our first proto types). But the remark is still valid even if you find the exact same hardware for less on some site xyz: it wouldn’t mean the software and firmware is suddenly also free.
It’s like taking any security dongle, opening it up and saying: hey look it consists of some resistors and a chip xyz that only costs x dollars so that device should cost x dollars. Basically forgetting that the firmware on the chip that’s been developed for it and the software communicating with it (the gui and usb protocol to communicate between the two) is the most time consuming and also costs the most money to create (either in your time to create it or paying other developers to create it…).
Taking it even further. It’s like saying: hey an empty DVD costs 2$ so why should I pay 20$ for any game or movie that’s on the same hardware (being a DVD disk). I can just buy an empty one and copy that movie from my buddy onto it ;)
Yes or you could just buy any atmega32 chip or any arduino clone and then you just need to write firmware + software for it so that it’s user friendly and secure and make it work on all OS’s and have multiple keymaps ( not just qwerty ) working.
You’ll need a usb protocol to change the passwords and something to lock/unlock the bootloader and develop a secure bootloader + flash it to that device before distributing it. Also you’ll need to set the proper lockbits for each device before shipping. So when all this work is done. You’re allowed to ask some extra for the efforts right?
Also the AnyKey looks indeed similar on pictures but we did make some changes to the pcb’s compared to the badusb beetle you mention here. For one yours is probably not fitting properly in the usb ports because the pcb is too thick. (just one of the things we improved with AnyKey on hardware level because. Yes, we did start out with that similar hardware for our first proto types). But the remark is still valid even if you find the exact same hardware and pcb for less on some site xyz: it wouldn’t mean the software and firmware is suddenly also free would it?
It’s like taking any security dongle, opening it up and saying: hey look it consists of some resistors and a chip xyz that only costs x dollars so that device should cost x dollars. Basically forgetting that the firmware on the chip that’s been developed for it and the software communicating with it (the gui and usb protocol to communicate between the two) is the most time consuming and also costs the most money to create (either in your time to create it or paying other developers to create it…).
Taking it even further. It’s like saying: hey an empty DVD costs 2$ so why should I pay 20$ for any game or movie that’s on the same hardware (being a DVD disk) ;).