Skip to content

UHK threat analysis#1590

Draft
benedekkupper wants to merge 1 commit into
masterfrom
threat-analysis
Draft

UHK threat analysis#1590
benedekkupper wants to merge 1 commit into
masterfrom
threat-analysis

Conversation

@benedekkupper

Copy link
Copy Markdown
Contributor

This is a PR to discuss about the device security through a threat analysis. This document shall be thorough, all conceivable threats should be listed. A lot of threats require physical access to the device, which aren't that relevant, once an attacker has physical access, they could as well replace the keyboard with a replica, or add a badUSB cable to it, etc. Let's perform the discussion as inline review of the document.

In my opinion, the change that would deliver the most added security is a password requirement (entered and processed on the keyboard, not sent to host) for FW update and for configuration R/W.

Signed-off-by: Benedek Kupper <kupper.benedek@gmail.com>
@benedekkupper
benedekkupper marked this pull request as draft July 2, 2026 21:45
@benedekkupper
benedekkupper requested a review from kareltucek July 2, 2026 21:46
@mondalaci

Copy link
Copy Markdown
Member

From a usability standpoint, I'd keep firmware updates and configuration reads/writes as they are by default.

However, we could add toggleable secure modes for firmware upgrades and dangerous USB commands, including configuration writes. I think separate security modes for various categories would make sense, but they feel overkill for configuration reads. A devMode-like mechanism could be used in $onInit to toggle these secure modes, and they should temporarily reset to their defaults when the UHK receives a hardware reset for recovery purposes, if a custom password is used instead of a firmware-hardcoded input.

The behavior of the secure modes is non-trivial, as not a single but usually multiple commands need to be executed, and subsequent commands should not be permitted. We'll need a mechanism to allow for this scenario.

The UHK is developer-friendly, so non-signed firmwares must be allowed.

@kareltucek

kareltucek commented Jul 14, 2026

Copy link
Copy Markdown
Collaborator

Security wise, it seems reasonable to me to require a secure default setting. A simple action that however requires user's deliberate acknowledgement. I think along the lines of the 4 corner keys as was discussed in some of the tickets.

Then there can be a macro command to disable security.

@mondalaci

Copy link
Copy Markdown
Member

That may work. Please elaborate on the specifics when you have time. This is not a priority issue. The end of your last comment seems cut off.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants