Limiting amount of connected keyboards

[sagakortesaari]

The problem Currently, it is possible to inject text into SEB via a keystroke injection using a badusb-device. An examinee could utilize this to be able to access e.g. a cheat sheet during the exam. Even if an exam is actively invigilated in an exam hall, it would be very easy to cheat using this approach since all that is required is a small USB device.

Describe the solution you'd like Adding a check that limits the amount of connected keyboards. This could e.g. be configured in the config file, similar to limiting the amount of screens (that exists today). If the amount of connected keyboards exceeds this threshold, refuse to startup SEB. This would also need to be monitored when SEB is up and running, to see that no additional keyboards are connected.

[dbuechel]

Thanks for the feature request, we'll definitely consider it for an upcoming version.

[sagakortesaari]

Just to mention, this is a feature that is relevant to both Windows/MacOS, I forgot to include this in the initial report. Not sure if a separate issue should be created for this in the MacOS SEB repo.

[danschlet]

We will consider this also for macOS. I can nevertheless already predict that such a feature will create additional support issues, because some SEB users will insist on using external keyboards in addition to internal ones or will have some exotic USB implementations. Also, how can you make sure that if one keyboard is allowed in settings, that it's a regular keyboard and not a combined device which has keys but also allows to inject pre-recorded key strokes or records all key strokes? Also I'm not sure if you can always distinguish between keyboards and mice, trackpads or other USB devices with input capabilities. This will require some research before assessing if this will work in practice.

[sagakortesaari]

Thanks for the comment! You raise some fair points about it, potentially creating additional support issues. However, by making such a feature opt-in, institutions can choose whether or not they want to use it depending on how strict they want it to be.

Fair point about how to identify if a keyboard is a 'regular keyboard' or not, indeed it would be very hard to do so.

As for distinguishing between keyboards and mice, it should be possible to do via using something like libusb, which is also available in C# (libusbdotnet). To check if something is a mouse or a keyboard one can simply check if the InterfaceProtocol-field is equal to 1 or 2 (see here). Although I'm not sure if this way is 100% reliable.

[dbuechel]

Thanks for the input. Yes, we'll definitely need to study possible implementations in detail beforehand, under Windows the hardware jungle is literally immeasurable and if we don't have a proper and reliably API, then we won't be able to do anything as we unfortunately don't have the capacity to implement the low-level stuff ourselves.

[strau0106]

I think this is a very pressing issue. A lot the cheating I hear about going on is based on this. Detecting such a device could be done, by monitoring the frequency and the regularity of the inputted keystrokes instead of detecting it via the number of HID devices connected.

No examinee will be typing at 200 WPM with a key every n milliseconds and for a rubber ducky to be a feasible method of cheating, I imagine it has to output a lot of text.

Furthermore, it could be implemented so that only the keyboard SEB was started with is allowed to input with. This wouldn't alleviate the issue of a keyboard and rubber ducky combo however.

This could be an option let to system administrators and not enabled by default?

[dbuechel]

This unfortunately isn't at the top of our to do list at all, we'll be completely occupied with other priorities for at least the next two releases.