Securing firmware upgrades

Security is a serious business but more often than not it gets overlooked. Ideally, it should be part of the design from the get go but people are prone to overlook it given the huge number of seemingly more urgent issues to be taken care of. That's why it's a blessing when you get contacted by a security consultant like Marcus Gustafsson out of the blue.

Marcus expressed his concern regarding the security of firmware upgrades and we exchanged a couple of lenghty emails full of geek talk. I originally planned to copy-paste all of them here so that everybody can see the gory details but that'd be a very long post so I'd rather just summarize what really matters.

Given his security-conscious mindset Marcus wanted to have a dedicated physical port to upgrade the firmware. He said that he rather would not want to rely on perfect code but enforce a hardware level security mechanism for firmware upgrade purposes so that no unwanted firmware can be uploaded by malicious applications. Originally, I couldn't see a way of making it happen but he was diligent enough to look into AVR datasheets, found the lock bits and ultimately, we figured out a way.

I ended up defining the following 4 security modes:

In insecure mode after the keyboard received the USB bootloader jump control request it immediately jumps to the bootloader. Malicious applications rejoice!

In confirmation mode after the keyboard received the USB bootloader jump control request it captures key input and waits for the "1q2w3e4r5t" confirmation string in order to jump to the bootloader. In this case malicious applications cannot make the keyboard jump to the bootloader without the user explicitly permitting the operation by typing a word, captured by the keyboard. This mode will be the default.

In secure mode after the keyboard received the USB bootloader jump control request it captures key input and waits for a password that was explicitly set up by the user beforehand. The password is stored in the EEPROM as a cryptographic hash. Not only an explicit user interaction is necessary to enter the bootloader but the user must know the exact password.

In locked mode the lock bits of the microcontrolers are set and as such firmware upgrades through the bootloaders are not possible. A dedicated hardware programmer must be used for setting the lock bits and uploading the new firmwares. Connecting the programmer to the programming header requires the disassembly of the keyboard which means unscrewing 2 screws per keyboard half and taking apart the top and bottom part per keyboard half.

I think the above modes should cover enough ground to satisfy the need of every user from the least security conscious to the most. There are only a handful of keyboards on the market whose firmware is upgradable and out of those keyboards every one implements the insecure mode detailed above. I'm excited that we're the first to address this problem!

Lastly, let me just re-emphasize how much your voice matters. Thanks to Marcus the UHK can be better than any other keyboard security-wise. Have a great idea, a critique or concern? Please let us know! We're doing our best to address every issue.