Secure firmware upgrades

[mondalaci]

See https://ultimatehackingkeyboard.com/blog/2015/02/26/securing-firmware-upgrades

[rolag]

Does this still apply to the V2? And is there anything someone could do to help complete this issue faster?

[mondalaci]

Yes, it applies to the v2, too. I can't provide you an ETA on this as we're busy with other issues.

[mondalaci]

I don't think it's worth implementing this feature since nobody has requested it, and no security incidents were reported. If we ever implement something like this, there'll be a simple hardcoded policy of keeping certain key(s) pressed for a while. For the time being, I'm closing it.

[Ofenhed]

That's disappointing... maybe I'm the only one (as I'm the Marcus referred to in the blog post), but the lack of security is the one and only reason why I sold my UHK a few years back, even though I absolutely loved using it. I feel that your target audience with an expensive "hacking keyboard" should have an unusually high percentage of security aware people. If you're not hearing about it, is it because it really isn't an issue people care about, or have security aware people just removed UHK from consideration?

[mondalaci]

The lack of upvotes on this issue suggests to me that people don't really care.

What would you consider an acceptable solution? I think requesting the user to hold a key or certain keys is decent. Please note that we have limited bandwidth for this issue.

[Ofenhed]

Yeah, I think pretty much anything that limits programming is enough, as long as it's not normal usage (as malware could then just wait for the opportunity). A single key is a bit weak, in my opinion. How about the 4 corner keys of the main keyboard half (without any other keys)?

I want to point out that I'm just an opinionated third party here, I'm unfortunately no longer affected by this.

[mondalaci]

The 4 corner keys are reasonable. Thanks for your opinion!

[josephvusich]

The lack of upvotes on this issue suggests to me that people don't really care.

Speaking personally, I subscribed to this issue years ago, without upvoting. I would really like to see this feature implemented.

Currently I've mitigated the security concerns by putting the UHK behind a trusted KVM switch that only reports its own virtual HID to the OS. The Agent does not even see the UHK when connected in this manner.

When a firmware upgrade or configuration change is required, I plug the keyboard in directly, bypassing the KVM. This is my workaround for the lack of hardware security on the UHK. I would strongly prefer the convenience of a write-protection feature on the UHK itself, as this would eliminate the need to physically swap connections.

[adrianimboden]

I did not work on the keyboard software myself yet, but I would be interested to help out when you point me to the relevant parts. The security part always comes up after I change the configuration and it bothers me from then on for some weeks until I forget about it.

When detecting a key (or multiple keys) at bootloader stage is easy (e.g. you have a code sample where we do that already in the bootloader), I will happily implement and test it out.

[mondalaci]

Thanks for offering your help, and I don't want to discourage you, but our experience is that helping occasional contributors takes us more time than doing the task ourselves, so we'd rather implement this feature.