Telling machines apart from the KVM side

Claim. A KVM can notice that the machine behind it has changed, and can rule machines out. On its own it cannot reliably name one machine out of many. A picture hash fails at this; the layout of the text on the screen does better. These are first measurements on two machines with two different KVMs, not an accuracy figure.

Method. A Mini PC running Ubuntu, watched through a GL.iNet Comet, and a Raspberry Pi running Ubuntu, watched through a Sipeed NanoKVM. Twelve samples were taken from each, a few seconds apart, using only what the KVM itself reports and one picture: the video mode, whether the machine accepted the KVM's USB keyboard, the keyboard LED state, and the screen. Nothing was sent to either machine. 255 stored pictures from a third machine were added as distractors. Half of each machine's samples were stored, and the other half were then identified.

What the KVMs report.

• The Comet reports the video mode with its refresh rate (1920x1080 at 60 Hz), whether the machine accepted its keyboard, and the keyboard LEDs.
• The NanoKVM reports the resolution (1920x1080) but no refresh rate. It reports keyboard LEDs only after the machine has sent one, and it cannot say whether the machine accepted the keyboard.
• Both machines output 1920x1080. That fact alone does not separate them.

Result.

• Stable at rest. In all 12 samples of each machine the mode, keyboard state and LED state never changed, and the picture hash was identical. Across a reboot: not tested.
• A picture hash does not identify a machine. The nearest picture of a different machine was only 1 to 2 bits away on a 64-bit hash, where 10 bits counts as the same screen. Text consoles look alike.
• The layout of the text does. For each row of text the signature keeps its height and where it ends, and reads no characters. Between the two live machines the similarity was 0.0, where 1.0 is identical. The closest picture of any other machine reached 0.33 at most. Within one machine it stayed at 0.67 or above.
• Identification on the held-out samples: the Mini PC was named correctly 6 times of 6. The Raspberry Pi was leaned toward correctly 6 times of 6 but not named, because its KVM reports little and a short login screen is thin evidence. There was no wrong answer.

What the USB link gives.

• The target answers a Caps Lock press with an LED report that the KVM can read. The round trip, including the KVM's own polling, took a median of 109 ms on the Comet (101 to 111) and 78.5 ms on the NanoKVM (76 to 82), 10 of 10 times each. It shows the machine answers. It does not name the machine.
• From the machine's own side, the operating system records the KVM as a composite USB device: both negotiated 480 Mbps, and each sits on a different kind of controller. Those facts describe the machine's USB hardware and are very useful when repairing it. A KVM cannot see them, so they are kept in the machine's baseline.

Prior work. Identifying a host from its USB behaviour has been studied. Bates, Leonard, Pruse, Lowd and Butler (NDSS 2014) collected data on over 250 machines using a device that plays the part of the USB peripheral. They reported upwards of 90% accuracy for the operating system, manufacturer and model within tenths of a second, 100% for detecting a hypervisor, and 70% of a field of 30 identical machines uniquely identified over longer observation. Coverage was incomplete: for a set of identical iMacs it was 44%, and the authors say the approach did not yet have enough coverage for general deployment. Their method uses the timing of the host's USB requests, which the software on these KVMs does not expose. Keyboard-firmware and Rubber Ducky projects use a simpler form of the same idea to guess the operating system. We found no published measurement on an IP-KVM.

Sample size. Two machines, two KVMs, 12 samples each, 10 LED round trips each, plus 255 pictures of a third machine. Search results can miss prior work; this list is not a survey.

Not tested. Stability across a reboot. Different screen states of one machine (login, shell, firmware setup). Machines with a graphical desktop. Machines with identical hostnames and banners. The gadget state the KVM's USB controller keeps (whether the host is asleep, off, or configured), which needs a shell on the KVM. A controlled change to what the machine sees (a different display description, a USB reconnect). Any other KVM.

Limits.

• The held-out samples are the same screen seconds later. This does not show identification across states.
• The weights the matcher uses are set by hand and checked on these data. They are not calibrated probabilities.
• The text layout needs text on the screen.
• The strongest identity that needs no login and no screen is the machine's ssh host keys, which a scan reads without authenticating. That is a network check, not a KVM one, and it says who is at an address, not which machine a KVM is plugged into.