Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HID-IO interface, authentication thoughts #4

Open
algernon opened this issue Jul 20, 2017 · 0 comments
Open

HID-IO interface, authentication thoughts #4

algernon opened this issue Jul 20, 2017 · 0 comments

Comments

@algernon
Copy link

  • Authentication
    • 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant