features

Securing firmware upgrades

Security

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.

Improving mouse navigation

When I created the mouse layer, I was thinking about adding a boost key to increase the pointer movement speed while it's pressed. It'd allow for faster navigation when large distances need to be traveled by the pointer. I also immediately thought of the left Mod key as the ideal candidate for this purpose. Shortly, I dismissed my idea thinking that Mod is a layer switcher key, and as such, it should only serve one purpose not to overcomplicate matters.

Lately, we've been contacted by two of you, independently suggesting to add a feature akin to my original boost concept. I honestly cannot remember the name of the first person, but I can clearly remember the second of you, Christian Léger, who has suggested not only to enable users to increase mouse speed but also to decrease it for finer-grained mouse interactions. At first, I was a little hesitant, but ultimately, I do think that acceleration and deceleration complement each other very nicely and improve usability, so hence here's the updated mouse layer.

improved-mouse-layer

Given the normal, user-configurable speed of the mouse pointer, the accelerated speed can be 2x, and the decelerated speed can be 0.5x of the normal speed, for example, all being user-configurable values.

But there's an important question to be answered: What if both the Mouse and Mod keys are pressed simultaneously? Which layer switcher key should dominate choosing the layer to be used? Easy: let's put the layer switcher keys into a priority list, defaulting to Fn, Mouse, and Mod. I'm not fully confident about the exact order, but in any case, the UHK being a fully configurable keyboard, this priority list will be configurable on a per-keymap level.

Update (2016-07-29): We'll ditch the priority list in favor of a much easier solution: Whichever layer switcher key gets pressed first will be the active one (active layer) until release.

I've also made some other fixes. First of all, I added "button 6", which was missing. Second, I replaced "history prev" with "button 4" and "history next" with "button 5". The original naming of these keys was based on the function of those keys within browsers, but the more generalized naming is clearly better.

We're infinitely grateful for people like Christian who have taken the time to share their thoughts. Believe it or not, even when you ask questions quite often, you make us learn and sometimes reiterate our design. This blog post is the evidence that you can make a change, and we're listening to you. Let's push things further than ever and make the Ultimate Hacking Keyboard a truly remarkable keyboard!

Permament interconnection of the two keyboard halves

We foresee the UHK to be mainly used in a split fashion and expect people to use it merged almost exclusively for transportation purposes.

That being said, despite of our assumptions there may be a number of people who might want use it in a merged state all the time. The magnets that hold the two keyboard halves together are pretty strong but still the halves can come apart occasionally. To address this scenario András, mechanical engineer extraordinaire has come up with a way to permamently interconnect the halves. The beauty of his design is that all it takes is screwing a single screw.

People say that a picture says more than a thousand words and we have not one but four pictures that show you our design.

Permament interconnection of the two keyboard halves

Click to see the album

Being able to rebind Alt+Tab is a big deal

Alt+Tab is one of the most often used keyboard shortcuts. It's used hundreds of times per day to switch between windows quickly. There's just one problem with it. Have you ever wondered how you hold your hand when invoking it?

Hand posture when invoking Alt+Tab

Hand posture when invoking Alt+Tab

I have to bend my left thumb under my hand to reach left Alt. This is not a natural posture and possibly even more awkward than the Vulcan salute.

How about invoking Alt+Tab via a convenience shortcut like Mod+D?

Hand posture when invoking Alt+Tab via Mod+D

Hand posture when invoking Alt+Tab via Mod+D

Now we're talking! No bending fingers or leaving the home row anymore.

We don't even second think about how clumsy the first posture is because we're so used to it, and there aren't alternative shortcuts on regular keyboards. Having used our third generation prototype for about half a year, going back to a regular keyboard that is not configurable this way makes me feel really uncomfortable. This is exactly the kind of thing that doesn't seem like a big deal, but it is.

People invoke Alt+Tab hundreds of times per day which translates to hundred(s) of thousands of times per year. We are here to provide you a more comfortable way to do this and many other things.

Should you have any ideas about (possibly application-specific) custom shortcuts, you'd like to use, please let us know!

Title