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.

A while back, Marcus expressed his concern regarding the security of the UHK firmware upgrades, and we exchanged a couple of lengthy 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 update 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. Rather than having to rely on perfect code to protect your security, a hardware level security mechanism is a much better bet. Originally, I couldn’t see a way of making it happen, but Marcus was diligent enough to look into AVR datasheets, find the lock bits, and ultimately, we figured out a way.

We ended up coming up with the following 4 user-selectable security modes:

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

• In confirmation mode, after the keyboard receives 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 receives 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 is an explicit user interaction necessary to enter the bootloader, but the user must know the exact password.

• In locked mode, the lock bits of the microcontrollers 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 new firmware. 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 for each keyboard half.

I think the above mode selections 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 potential issue.

If you haven’t pledged yet, we still have some UHKs available at the Early Bird price - so now’s the time to order your keyboard!

If you have any questions, please ask us!

We will keep you posted about twice a week with demos, tear-downs, statistics, and other interesting material, so stay tuned!

Laci, lead developer of the Ultimate Hacking Keyboard