Thoughts? (not really settled on doing it this way, but some sort of authentication is needed for more sensitive operations)
Request a run-time key from the HID-IO daemon
hid-io --userspace-key
hid-io --secure-key # Requires root priviledges
Should use some sort of TLS for traffic
Key would be used to establish the tunnel
I think that to allow the more privileged access/control levels, it would make sense to require confirmation via the device, to make sure that the user has physical access on top of the required keys. This could be done by sending an "Authentication Request" packet to the keyboard, and waiting for the response. The keyboard would default to NAK, but wait a few seconds before sending a reply. In this time, the user would have the ability to press a macro key that would flip the reply to an ACK.
The downside of this is that it may not be feasible to do this for every packet sent down the wire, so the token should be cached for a while, but with an expiration. Perhaps that should be configurable too, somewhere... the device could include the expiration timeout in its payload, for example.
Mind you, this assumes that the device is never accessed directly. If one has root on the host, chances are high that a malicious attacker could just talk directly to the device. So for authentication to be really useful, and not just an extra layer of obscurity, it would need a part of it to be on the device. And that opens up a whole lot of issues... (such as how the heck would one do that on an Atmega32u4?).
TL;DR: As far as I see, authentication is not all that useful, unless the device is cooperating. Encrypting the plugin<->daemon communication is useful, though, but that may not require authentication at all.
I think that to allow the more privileged access/control levels, it would make sense to require confirmation via the device, to make sure that the user has physical access on top of the required keys. This could be done by sending an "Authentication Request" packet to the keyboard, and waiting for the response. The keyboard would default to
NAK, but wait a few seconds before sending a reply. In this time, the user would have the ability to press a macro key that would flip the reply to anACK.The downside of this is that it may not be feasible to do this for every packet sent down the wire, so the token should be cached for a while, but with an expiration. Perhaps that should be configurable too, somewhere... the device could include the expiration timeout in its payload, for example.
Mind you, this assumes that the device is never accessed directly. If one has root on the host, chances are high that a malicious attacker could just talk directly to the device. So for authentication to be really useful, and not just an extra layer of obscurity, it would need a part of it to be on the device. And that opens up a whole lot of issues... (such as how the heck would one do that on an Atmega32u4?).
TL;DR: As far as I see, authentication is not all that useful, unless the device is cooperating. Encrypting the plugin<->daemon communication is useful, though, but that may not require authentication at all.