Environmental data based input validation system and method

Abstract

A method (800) for validating a connection of a device (102, 180) to a host computing device (100), the method intercepting (804), at a monitor application (210), an input signal (402) generated by the device (102, 180) when attaching to the host computing device (100), receiving (808), at the monitor application (210), a measurement signal (408) of an environment parameter (409) measured by a sensor (720) about the device (102, 180), verifying (810) a matching between the input signal (402) and the measurement signal (408) of the measured environment parameter (409), and releasing (814) the input signal (402) to an application (212) running on the host computing device (100) when the matching is valid.

Description

ENVIRONMENTAL DATA BASED INPUT VALIDATION SYSTEM AND METHODCROSS-REFERENCE TO RELATED APPLICATIONS

[0001] This application claims priority to U.S. Provisional Patent Application No. 63 / 651 ,041 , filed on May 23, 2024, entitled “INPUT VALIDATION SYSTEM USING ENVIRONMENTAL DATA,” the disclosure of which is incorporated herein by reference in its entirety.BACKGROUND OF THE INVENTIONTECHNICAL FIELD

[0002] Embodiments of the subject matter disclosed herein generally relate to a computing device and a method for protecting the computing device from a cyberattack, and more particularly, to a method and associated system that prevents an aggressor device to use an existing software protocol, which lacks security features, to pose as a legitimate device.DISCUSSION OF THE BACKGROUND

[0003] With the current explosion of electronic communication between people and the advance of social media, the number of computing devices (e.g., smart phones, tablets, laptops, desktops, etc.) that are used for accessing these technologies have increased. At the same time, the number and type of cyberattacks on these devices have also increased. The type of attack varies from vectorsthat may be downloaded from the Internet, or received as unsolicited emails, to physical devices that need to be physically connected to the computing device.

[0004] One specific type of attack that relies on impersonating a physical device that needs to be connected to a computing device is what is known as a BadllSB. The BadllSB exploits the widely recognized and established Universal Serial Bus (USB) protocol. This protocol simplified the connection between personal computers and peripheral devices.

[0005] The USB specification includes a human interface device (HID) protocol, which standardizes communication between devices (e.g., keyboard, mouse, monitor, camera, speaker, microphone, external hard drive, electronic pen, modem, router, etc.) and personal computers. The term “BadUSB” was introduced when researchers demonstrated how re-engineered USB firmware could facilitate attacks through the device. A BadUSB refers to a USB flash drive, often a USB stick, whose firmware has been re-engineered to identify itself as a HID device. This hack, combined with pre-programming a payload onto the manipulated USB device, allows the execution of an arbitrary code upon connection to a USB port of a computing device. The payload may contain commands enabling the USB device to emulate an HID device, and transmit input to the host computing device, thus facilitating activities like data exfiltration, device control, or data manipulation.

[0006] An effective and easy-to-implement countermeasure is to lock down the USB protocol and avoid the usage of USB ports on the computing device to connect to external devices. However, such a solution hinders convenience and usability as the USB protocol provides a quick and easy way to share files andconnect peripheral devices. Thus, except for work environments where a strict security policy is in place (e.g., military facilities), USB ports are still available for the convenience of users (and hackers).

[0007] Several solutions have been proposed to address the challenges posed by BadUSB. However, all these solutions are subject to a number of drawbacks, such as the high number of false positives, the required specialized hardware, and the intensive use of host resources. Thus, there is a need to find a new solution that overcomes the above limitations, is easily implemented, inexpensive, and prevents malicious attacks while still allowing the USB protocol to be used. In addition, the new solution should also be flexible so that it can be adapted for other protocols, that might be used for connecting a device to the computing device, for example, Bluetooth, Wi-Fi or other wireless protocol.SUMMARY OF THE INVENTION

[0008] According to an embodiment, there is a method for validating a connection of a device to a host computing device, and the method includes intercepting, at a monitor application, an input signal generated by the device when attaching to the host computing device, receiving, at the monitor application, a measurement signal of an environment parameter measured by a sensor about the device, verifying a matching between the input signal and the measurement signal of the measured environment parameter, and releasing the input signal to an application running on the host computing device when the matching is valid.

[0009] According to another embodiment, there is a host computing device for validating a connection to a device, and the host computing device includes a processor hosting a monitor application, which is configured to intercept an input signal generated by the device when attached to the host computing device, and a transceiver configured to receive a measurement signal of an environment parameter measured by a sensor about the device. The processor is further configured to verify a matching between the input signal and the measurement signal of the measured environment parameter, and release the input signal to an application running on the host computing device when the matching is valid.BRIEF DESCRIPTION OF THE DRAWINGS

[0010] For a more complete understanding of the present invention, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:

[0011] FIG. 1 is a schematic diagram of a USB protocol performed by a host computing device and a USB device for identifying the USB device;

[0012] FIG. 2 is a schematic diagram illustrating components, ports, and software modules of a host computing device that communicates with a sensing device for receiving sensing information with regard to one or more devices;

[0013] FIG. 3 is an instance of pseudo-code for a keyboard monitor application hosted by the host computing device;

[0014] FIG. 4 is a component diagram of an input validation service that validates a device according to an embodiment;

[0015] FIG. 5 illustrates a vibration signal recorded by a sensor and transmitted to the monitor application of FIG. 3;

[0016] FIG. 6 is a pseudo-code for a smartphone application that communicates with the monitor application of FIG. 3;

[0017] FIG. 7 is a schematic diagram of a host computing device having plural devices and one or more sensors for measuring an environment parameter of an external device that tries to connect to the host computing device;

[0018] FIG. 8 is a flow chart illustrating steps performed by an input validation module for validating the device that tries to connect to the host computing device;

[0019] FIG. 9 is a schematic diagram of the host computing device being connected to three sensors for measuring corresponding environment parameters of a wired device;

[0020] FIG. 10 is a schematic diagram of the host computing device being connected to four sensors for measuring corresponding environment parameters of a wireless device;

[0021] FIG. 11 A illustrates a possible attack on a wireless monitor and FIG.11B illustrates the use of the sensors of a smartphone for supplying the measured environment parameters;

[0022] FIG. 12 is a schematic diagram of the host computing device being connected to a standalone sensing device that includes sensors for measuring corresponding environment parameters of an external device;

[0023] FIG. 13 is a schematic diagram of the host computing device being connected to a keyboard pad that includes sensors for measuring corresponding environment parameters of an external device;

[0024] FIG. 14 is a schematic diagram of the host computing device being connected to a smartphone having sensors for measuring corresponding environment parameters of a wireless device;

[0025] FIG. 15 is a schematic diagram of the host computing device being connected to a wireless device that hosts plural sensors;

[0026] FIG. 16 is a schematic diagram of the host computing device being connected to a wired device having plural sensors for measuring corresponding environment parameters of the device; and

[0027] FIG. 17A to 17C illustrate signals measured by the sensors, under various conditions, for a device that tries to connect to the host computing device.DETAILED DESCRIPTION OF THE INVENTION

[0028] The following description of the embodiments refers to the accompanying drawings. The same reference numbers in different drawings identify the same or similar elements. The following detailed description does not limit the invention. Instead, the scope of the invention is defined by the appended claims. The following embodiments are discussed, for simplicity, with regard to an aggressor device that uses the USB protocol for attacking the host computing device. However, the embodiments to be discussed next are not limited to the USB protocol, but may be applied to other computer communication protocols, for example, Bluetooth, WiFi, system bus, etc. or other input technologies (e.g., touchscreen).

[0029] Reference throughout the specification to “one embodiment” or “an embodiment” means that a particular feature, structure or characteristic described in connection with an embodiment is included in at least one embodiment of the subject matter disclosed. Thus, the appearance of the phrases “in one embodiment” or “in an embodiment” in various places throughout the specification is not necessarily referring to the same embodiment. Further, the particular features, structures or characteristics may be combined in any suitable manner in one or more embodiments.

[0030] According to an embodiment, a novel, efficient, and effective solution (service) is introduced to counter an aggressor device threat by leveraging information generated in a physical space (environment) surrounding the device. In one embodiment, a method that describes the solution captures a signature orfingerprint (e.g., vibrations from keystrokes if the device is a keyboard, or a temperature if the device is a hard drive, or a sound if the device is a speaker, or an electromagnetic wave with a specific wavelength if the device uses a wireless link to the host computing device, or a specific sound if the device is a printer, or a vibration if the device is a touchless monitor, etc.) and correlates the signature with input signals received from the device to distinguish between legitimate device-generated inputs, and fake inputs, generated in software, by a malicious payload, and thus, blocking the latter.

[0031] The inventors evaluated the USB based solution (called in this document No BadUSB (NoBU) service) across various environments and keyboard types, demonstrating NoBU’s promising capabilities. One version of the NoBU service achieved an accuracy of 99.92%, scoring 99.83% on precision and a recall of 100% in identifying malicious keystrokes; hence, the service does not accept false negatives. The inventors further enhanced the detection methodology, moving in one embodiment from continuous input validation to seamless keyboard enrollment, still leveraging the concepts introduced by the NoBU service. The new method (eNoBU) achieves an accuracy of 100%, while improving the user experience and further reducing the system overhead.

[0032] Prior to discussing the details of the NoBU and eNoBU services, a few details about the current solutions for the BadUSB threat are discussed. Since its introduction, the BadUSB attack has evolved in various forms, exploiting both hardware and software channels. The common approach focuses on microcontroller re-programming or driver re-programming to enable keystroke injections. Otherapproaches propose USB flash drives that cause physical harm, such as destroying motherboard BUSes by electrically overloading data pins.

[0033] Given the impact of this topic, numerous researchers have contributed valuable studies proposing countermeasures against this type of attack. The main focus in this field is on the identification and authentication of USB flash drives. These studies propose solutions to fingerprint devices by leveraging unique characteristics to implement allow list-based filtering solutions.

[0034] An effective fingerprint generation method has been proposed in [1], This group has devised an approach named MAGNETO, to uniquely fingerprint USB flash drives by analyzing the electromagnetic field generated during boot operations. Following the same principle, the group in [2] introduced Time-Print, a time-based fingerprinting approach. This method relies on analyzing the time series resulting from read-and-write operations on various locations of the USB device.

[0035] Taking another approach, the fingerprinting solution proposed by the group in [3] centers on utilizing details provided by the USB flash drive itself. They constructed a model to identify USB flash drives based on device-specific information (Serial Number, VendorlD, ProductID, etc.).

[0036] A most recent study about USB flash drive identification was proposed by [4]. Their solution operates at the physical layer of the USB protocol stack, using an oscilloscope to measure the power consumption and detect anomalies suggesting malicious activities. The core methodology involves an Autoencoder model for feature extraction, paired with a convolutional neural network - long shortterm memory (CNN-LSTM) model for identifying and detecting anomalies in USBperipherals. However, as the authors noted, the solution would fail if the malicious device used the USB protocol without showing significant power consumption anomalies.

[0037] In scenarios where the traditional methods of USB flash drive identification are deemed insufficient, several studies have explored the integration of human intervention during real-time execution to address the issue. When a HID is connected, the host computing device loads the necessary driver(s) to facilitate the interaction with the peripheral device. However, this reactive approach may need to be revised to prevent BadUSB attacks once the device is connected. Building on this premise, USBCheckln, an approach and accompanying hardware component introduced by [5], seeks to intercept USB flash drive connections. The hardware component is built with an upstream and a downstream port to filter the USB connection. Upon plugging in a device, USBCheckln prompts the user to complete a challenge on an external display. Successful completion of the challenge prompts the USBCheckln to authorize the USB bus’s downstream (peripheral device side) connection to the upstream (host PC side).

[0038] Other researchers introduced an Operating System (OS)-integrated approach to identify BadUSB attacks. The method proposed by [6], named GoodUSB, introduces a modified layer in the Linux USB subsystem to protect against malicious USB flash drives using a policy-based honeypot mechanism. It is a semi-automatic protection mechanism that requires little input from a human.However, the user has to confirm the USB flash drive identity using a dedicated userinterface. The group showed that GoodllSB can protect against malicious devices but introduces a 5.2% overhead to the USB flash drive enumeration process.

[0039] While these solutions prove effective, they frequently require human intervention to authorize device access, which can disrupt the user experience. Furthermore, a significant limitation arises once a device receives approval. The authorized HID device gains unrestricted interaction privileges with the host computing device. This approach may inadvertently introduce vulnerabilities, significantly when attacks are delayed in time and the re-programmed drive is hidden within devices posing as keyboards. Some other studies focus on device behavior analysis to decide whether or not to accept the USB flash drive. For example, the group in [7] aimed to analyze the keyboard keystrokes’ temporal features to detect different behaviors in the user’s typing style. However, this approach performs well only with known payloads and users.

[0040] Even if the BadUSB is a decade old research topic, with quite a number of interesting approaches, a definitive solution has yet to be found. The following embodiments introduce a new approach (the NoBU service) that uses a technique for analyzing and blocking the attack based on the expected physical characteristics generated by a legitimate device (e.g., user-keyboard interaction, vibration, heat, sound, or light generated by the device). Unlike most of the abovediscussed approaches, the NoBU service is a fully automated method. Hence, the user can easily install and run the security service even if the user is not a cybersecurity expert. Moreover, the proposed approach does not need any training session to adapt to the user behavior; it is a plug-and-play approach. Finally, theresults from the tests performed by the inventors on the implemented service show that the user of the computing device hosting the device does not even perceive the introduced overhead in the input processing.

[0041] For a better understanding of the novel approach, the following embodiments use a USB device as the aggressor device, and the USB device is programmed to pose as a keyboard, i.e. , to generate keycodes associated with an input to the keyboard to attack the host computing device. However, the embodiments discussed herein are also applicable to other devices, e.g., mouse, monitor, speaker, microphone, camera, hard drive, printer, scanner, cameras, router etc. as long as these devices can be associated with a specific signature (fingerprint) that can be detected with one or more sensors. For example, while the embodiments discussed next detect the keycodes associated with pressing various keys on a keyboard and compare them with physical vibrations generated by the keyboard, the same principles may be applied when a camera sends pictures to the host computing devices and a sensor determines that a large amount of data is transferred to the host, or when the printer communicates with the host and a sensor determines that the printer is generating a characteristic printer noise as the printer is printing actual files, etc.

[0042] The USB protocol changed the way peripheral devices interact with computers by enabling multiple device connections and seamless plug-and-play connectivity. By its original definition, the USB BUS consists of four main pins: GND for ground, VCC for 5V power, and D+ and D- for BUS state encoding. The core of the plug-and-play functionality of the USB protocol is the device identification andclassification process, also known as enumeration. This protocol includes seven steps, schematically illustrated in FIG. 1. The host computing device 100 and the USB device 180 (device) perform first a device detection step 130, followed by an identity speed step 132, obtain the device descriptor step 134, reset the device and assign an address in step 136, obtain configuration descriptors in step 138, and obtain interface descriptors in step 140. In step 142, the host computing device 100 loads the necessary drivers for communicating with the USB device 180.

[0043] The OS of the host computing device 100 uses this protocol to identify the new USB device 180. During the enumeration procedure, several messages are exchanged with no security in place, between the OS of the host computing device 100 and the connected USB device 180. The goal is for the host computing device 100 to identify the specific characteristics of the USB device, ranging from communication speed to its name, type, and capabilities. This information, included in the USB device descriptor, is accepted by the host computing device 100 without any verification. This phenomenon, also known as the USB protocol trust-by-default policy, results in the host’s USB controller accepting the plugged device 180, with the self-declared set of features, without scrutinizing its validity or trustworthiness.

[0044] This lack of control enables BadUSB attacks, which impersonate trusted peripherals, e.g., keyboards (but possibly many other devices), to inject malicious input signals. In fact, when a device is recognized by the host as an HID, the HID device may transmit input or interpret output (LEDs, Caps Lock, and Num Lock statuses), according to the HID standard. More specifically, when a new device is plugged in, it undergoes enumeration and is registered in a specific directory of thehost computing device 100, typically found in the " / dev / bus / usb" location on Linuxbased Operating Systems. This registration process is managed by the USB HID driver. The Linux kernel’s input subsystem handles input events, creating new event files to manage keyboard inputs, commonly situated in " / dev / input / eventX", where ’X’ is a unique and incremental identifier.

[0045] Each device is treated as a character device, generating a stream of characters in its designated input event file upon any input event. The keyboard driver then translates this character stream into a keycode, which is subsequently mapped to a specific character or action based on the keyboard layout. Then, the input is organized into a stream accessible to applications of the host requesting keyboard input. Once an application reads from this input stream, the buffer is consumed and unavailable to other applications.

[0046] The NoBU method aims to address the BadUSB threat by leveraging the expected physical phenomenon triggered by keystrokes (i.e., vibrations).Pressing a key on a keyboard generates a subtle vibration that can be detected by consumer-grade sensors (e.g., accelerometer sensors), which are now commonly found even in budget smartphones or other home devices. A vibration signal is primarily characterized by three factors: displacement, that is, the magnitude of the signal, indicating the strength of the vibration impact; velocity, which is measured as the change in displacement over time; and acceleration, which is proportional to the displacement and the square of the frequency and measures the acceleration of the displacement. In this embodiment, the NoBU method focuses primarily on thedisplacement factor, as the method aims to capture the desk’s surface deformation indicative of a keystroke.

[0047] Before explaining the details of the NoBll method, an adversary model is introduced for modeling the circumstances under which the aggressor device attaches to the host computing device and tries to control it by exploiting the BadllSB vulnerability under specific circumstances. The model assumes that the attacker is capable of physically connecting, either directly or indirectly, its rogue USB flash drive to the host computing device. For attacks that might use a wireless protocol for connection, the model assumes that the host computing system establishes a wireless connection with the aggressor device. Physically attaching the aggressor USB device to the host may be achieved in several ways, such as dropping the USB device in common areas (e.g., cafeterias, recreational spaces, etc.), so that unwitting users grab it and plug it to their computers or replacing the victim’s USB device with an identical one containing the malicious firmware. Furthermore, this USB device is programmed to act as a legitimate device (e.g., keyboard), enabling it to inject information (e.g., keystrokes) into the host computing device.

[0048] An aim of the attacker is to inject commands (e.g., keystrokes, but other data may be possible depending on the type of the legitimate device that is impersonated) to upload a payload onto the host computing device and execute an arbitrary code. The attacker can program the aggressor device (e.g., USB device) to mimic legitimate information (e.g., keyboards) corresponding to the legitimate device, and inject malicious inputs into the host computing device. In addition, the adversarycan delay the attack by programming the rogue device (e.g., USB device) to start malicious actions only after a specified time has elapsed following its connection to the host computing device.

[0049] One goal of the NoBU method is to discriminate input signals between genuine outputs generated by an actual HID device (e.g., coming from a legitimate keyboard after user-generated keystrokes), and fake outputs generated by the aggressor device, i.e. , coming from a malicious device impersonating a keyboard. The NoBU service architecture, which is schematically illustrated in FIG. 2, includes a monitor application 210 and a sensing application 220. The monitor application 210 may be implemented in software, for example, in the OS 150 of the host computing device 100. The OS 150 may also host an input device interrupt 212, which is configured to receive the signals from the outside devices 102. The monitor application 210 analyses and validates input signals received via the device interrupt 212, from the aggressor device 180 and from the legitimate devices 102. FIG. 2 shows the host computing device 100 also including at least a processor 104, a memory 106 for hosting various software programs, a transceiver 108 for wireless communication, and a USB port 112 for wired communication. In one embodiment, the transceiver 108 may be a wired transceiver.

[0050] The sensing application 220 may run on a sensing device 230, which is not associated with the aggressor device 180. The sensing device may be a standalone device. In one embodiment, the sensing device 230 is a smartphone that is configured to collect data (e.g., vibration signals for a keyboard or a mouse, a temperature for a hard drive, an electromagnetic wave for a wireless device, soundfor a speaker, a distance to the device, etc.) and report the collected data to the sensing application 220, which communicates the data to the monitor application 210. While FIG. 2 shows that there is a wireless communication 110 between the host computing device 100 and the sensing device 230, it is also possible that the sensing device is wired to the host computing device, as discussed later with regard to the figures. The sensing device 230 may be implemented as a non-smartphone device, for example, as a standalone collection of sensors. In one embodiment, the sensing device may be implemented in the host computing device 100, a device of the host computing device, or spread over the host computing device and one or more devices. These possibilities are illustrated and discussed later.

[0051] Based on the architecture illustrated in FIG. 2, an attack scenario performed by the aggressor device 180, which impersonates a legitimate device, is now discussed. Assume that the user of the host computing device 100 has found the aggressor device 180 and has physically attached it to the USB port 112 as schematically illustrated in FIG. 2. When the legitimate device 102 is a keyboard, a legitimate keystroke is sent to the host computing device. The keystroke generates a physical vibration 103, which is captured by the sensing device 220, as the sensing device 220 has vibration sensors (e.g., accelerometers). The sensing application 220 at the sensing device 230 process the vibrations, e.g., assign a time stamp, digitize the signals, and then the sensing device 230 transmits (using the wireless link 110) the signals to the monitor application 210 of the host computing device 100. The monitor application also receives from the device interrupt 212, signals corresponding to the actual keystrokes pressed on the keyboard 102. Thus, themonitor application 210 may compare, within a given time window, whether the vibration signals 103 received from the sensing application 220 are aligned in time (within the window) with the signals received from the device interrupt 212. If the answer is yes, the monitor application determines that the device 102 is a legitimate device and allows signals from this device to be provided to various user applications 214 (e.g., word processor, email, web browser, etc.) hosted by the host 100.

[0052] In contrast, when the aggressor device 180 sends signals to the device interrupt 212, as these signals are generated in software by the malicious software loaded onto the aggressor device 180, there is no physical vibration of the aggressor device 180. Thus, for this type of attack, the sensor device 230 senses no vibrations, and the sensing application 220 provides no feedback to the monitor application 210, for the time window when the device interrupt 212 provided the fake signals of the aggressor device 180. This means that the monitor application 210 has no signals from the sensing application 220, corresponding to the vibration of the aggressor device 180, to compare with the fake signals generated by the aggressor device 180. For this scenario, the monitor application 210 is configured to report an attack from the aggressor device 180, and thus, the host computing device 100 denies communication with the aggressor device 180 and informs the user that an attack has occurred and the aggressor device 180 is the aggressor.

[0053] A more detailed implementation of the above scenarios is now discussed with regard to the figures. Using a high-level language, the NoBU’s monitor application 210 may be implemented as illustrated in FIG. 3, as a pseudocode. The monitor application 210 analyzes the signals received from thesensing application 220 and the input device interrupt 212. In the initial phase, see row 2 in FIG. 3, the monitor application involves the host computing device 100 for implementing a buffering of all keyboard inputs and denying other applications in the OS from accessing the input stream (i.e., the stream coming from the device, be it aggressor or legitimate). This preemptive action extends to potential new devices (BadllSB) identified as keyboards that may be connected after NoBU’s startup, as the system diligently monitors the presence of new devices. The NoBll service implements a keyboard locks strategy (when the device is a keyboard) by intercepting keycodes sent over the BUS and buffering them before allowing the destination application to receive the keycodes.

[0054] As shown in FIG. 4, the keyboard X 102, where X is an identifier of a generic keyboard, sends a keycode 402 (also called “input signal”) on the BUS 404. The NoBU service 410 includes the monitor application 210 and intercepts an input event 406, corresponding to the keycode or input signal 402. The input event 406 is registered in the device entry located in the / dev / input location of the Linux filesystem. The NoBU service 410 stores (buffers) the input event 406 into a buffer 412 until the monitor application 210 validates the input event. The monitor application 210 may also receive a measured signal 408 associated with an environment parameter 409 (e.g., vibration, sound, electromagnetic wave, image, capacitance, impedance, etc.), where the signal 408 is measured by sensors managed by the sensing application 220, and the environment parameter 409 is associated with the external device (102 or 180). Calculations performed by the NoBU service 410 may be partially implemented into a web server 414. The webserver 414, which is configured to connect to the Internet, may be hosted by the host computing device 100, or in the cloud. If the input event 406 is validated, i.e., it matches a corresponding input (measured signal 408) from the sensing application 220, the input event 406 is forwarded to the user input file 420 (typically located in the / dev / uinput or / dev / input / uinput), which is the file from where the various applications 214 hosted by the host computing device 100 read the keyboard inputs. Calculations associated with the validation process may take place in the monitor application 210, in the web server 414, or in both.

[0055] After this, the host computing device 100 remains in a state of readiness, waiting for the connection of a compatible sensing device 230 (row 3 in FIG. 3) that serves as a physical sensor to detect keystroke vibrations. Once the sensing device 230 is connected, the host computing device 100 prompts a message (row 4) informing the user that he / she is protected from BadllSB attacks. The NoBll service 410 iterates in a loop until the sensing device 230 is disconnected (rows 5-8 in FIG. 3). While connected, the NoBll service 410 reads the sensing device 230’s vibration stream 500 (see FIG. 5) and then analyzes it. The analysis of the vibration signals 500 includes the identification of peaks 502 (row 10 in FIG. 3), which are used to identify the presence of a candidate keystroke. If a keycode 402 is received by the NoBll service (row 11 in FIG. 3), then the NoBll service synchronizes the timeline of the vibration signal 500 with the received input event 406, as both signals are timestamped. For this embodiment, the NoBll service may select a time window of a certain length, e.g., in the ms to s range and checks whether the keystroke associated with the input event 406 is time aligned (i.e., withinthe same time window) with the identified peak 502 (rows 11-19 in FIG. 3). In one embodiment, the raw signal 500 may be normalized, which results in normalized signal 504 in FIG. 5. Still with regard to FIG. 5, the peak 502 may be selected to be the peak of the raw signal 500 or the normalized signal 504. FIG. 5 further shows a time offset 506 and only one peak (the highest peak) in the time offset 506 is considered to be associated with one keystroke. This choice prevents the background noise or secondary vibrations from appearing as a keystroke. The offset is also used to not accept any other peak to filter out keystrokes that have an interarrival time that is too short when compared to the average human keystroke behavior. In this regard, it was shown in the art, after collecting about 136 million keystrokes, that the average Inter- Keystroke Interval (I KI), that is, the time elapsed between pressing two keystrokes, is about 238.66 ms. Thus, in this embodiment, the offset time 506 was selected to be the average I KI and this offset time is applied by the host computing device around peaks to filter out faster inputs.

[0056] If the NoBll service 410 validates that the two signals (from the device 102 and from the sensing device 230) are within the same time window, the service 410 concludes that the device 102 is a legitimate device and then the service 410 forwards the input event 406 to the destination application 214. If the service 410 concludes that the device 102 is an aggressor device, it blocks the input event and shows a warning to the user.

[0057] The sensing device 230 in this embodiment may be a smartphone. As today almost all smartphones are equipped with an accelerometer sensor, independent of the brand and model, this choice of the sensing device is accessibleto most users and remarkably simple to implement for securing environments. The vibration detection relies on the variation in g-force, which can be determined by normalizing the measured acceleration across the smartphone’s lateral, longitudinal, and vertical axes. In this regard, FIG. 5 shows that the raw g-force signal 500 exhibits values greater and lower than 1 g-force, which is the gravitational force in the absence of external forces. This variation derives from the inherent characteristics of undulated material deformation caused by vibration, which makes peak analysis difficult. Hence, the raw signal 500 requires a normalization process for a precise peak analysis, creating a new signal stream 504 with all values referenced to 1 g-force as a common baseline.

[0058] FIG. 6 illustrates, as a pseudocode, how a smartphone 230 connects (see line 2) to the monitor application 210 and sends (line 3) updates on the perceived vibration signals 409. An example of the vibration signal data stream 500 sent to the monitor application 210 is shown in FIG. 5. In one embodiment, the inventors implemented the monitor application 210 using Python and used Android Studio Iguana to build the smartphone vibration sensing application 220. The monitor application 210 is configured to filter incoming inputs and decide whether to accept or discard the received keycode. This may be achieved using the evdev library, which leverages Linux’s file mutual exclusion mechanism. All connected devices, such as keyboards, are managed by the Linux input subsystem, with their inputs encoded in files named "eventX," where X represents the device index. The evdev library enables the NoBU service 410 to block the new USB keyboard’s input file, preventing other applications from accessing the keyboard events. The NoBUservice 410 then compares the input with the vibration data received from the smartphone and decides whether to discard or forward the event to the requesting application via the uinput (User Input) file.

[0059] In one embodiment, the monitor application 210, in order to guarantee a faster filtering process, starts one thread for each keyboard filtering activity. The filtering process requires the service to run with root privileges to lock the event file of the keyboards in order to prevent malicious input from reaching the target application. Moreover, the service keeps polling the udev Linux device manager to find newly connected keyboards and lock them.

[0060] Next, the NoBU service 410 needs to receive the vibration data from the smartphone. For this purpose, the NoBU service exposes a socket waiting for a connection over HTTP (HyperText Transfer Protocol). For this embodiment, the inventors used the Socket. IO library for python3 to manage the socket exposure and data exchange, creating a bidirectional communication channel between the monitor and sensing applications. In the Socket.lO paradigm, the communication is eventbased, meaning that both the client and the monitor application 210 can emit a message containing data that the receiver can later catch and analyze. Depending on the network router specifics and network load, based on the tests performed during the implementation, the Socket.lO communication mechanism can guarantee a high transmission rate, ranging from 200 to 400 messages per second. This transmission rate is high enough considering the average I KI as previously discussed.

[0061] Once the sensing application 220 registers on the Socket. IO port, it allows the user to perform three operations: (i) calibration; (ii) start a service; and (iii) stop a service. The calibration action sends a message to the monitor application 210 requesting a new calibration. This action is necessary to set the average vibration values in a new environment. The calibration phase may last for about 5 seconds and transmits the g-force values detected by the sensing application while the nearby bodies produce no movements. At the end of the calibration phase, the monitor application 210 stores three values: a base level, calculated as the average of all sent values; an upper bound, which is the maximum registered force value, and the lower bound, which is the minimum registered g-force.

[0062] The start service option allows the user to activate the service. When the service is active, the sensing smartphone 230 starts streaming the captured g- force values to the monitor application 210, which builds a time series of g-force values to detect peaks 502 and decide whether to accept a keystroke. The selection of good peak candidates is given by the strength of the signal, considering also the previously calculated calibration data. In one embodiment, a peak is selected if all of the following statements are true:(1) The monitored keyboard recently sent a keycode;(2) Given t as the time, Ltlas the lower time offset, Ut2as the upper time offset, f (%) as the function describing the vibration value streaming and Pvas the peak time, then:Vt: Ltl< t < Ut2, f(Pv) > f(t ,(3) Given Bieveias the calibration computed base level and respectively Maxvand Minvas the maximum and minimum registered values during the calibration phase, then:

[0063] The stop service option is configured to stop the service and release the filtering action on all of the attached keyboards. Once the service stops, the streaming of g-force values will stop as well.

[0064] The sensing application 220 is configured to detect the g-force value and send it to the monitor application 210 as soon as possible. The smartphone’s built-in sensors have been used to precisely detect the g-force variation in this embodiment. However, as previously discussed, other sensing devices may be used instead of the smartphone. Due to the Android SDK, access to the accelerometer sensor is managed by the SensorManager Java class, which gives easy and accurate details about the accelerometer axis values. In order to achieve the highest possible temporal resolution, the sensing application 210 requests updates to the Android SensorManager using the SensorManager.SENSOR_DELAY_FASTEST setting. This parameter instructs the operating system to deliver sensor events at the maximum frequency supported by the hardware and software configuration.Considering that the testbed was a Samsung Galaxy S22, the sampling rates range from 200 to 400 Hz. The actual frequency depends on several factors, including the device’s chipset, the number of background processes, and power management constraints. In one implementation, the inventors noticed that the sampling frequencywas also affected by the Wi-Fi transmission rate, reducing the sampling rate at a frequency of 150 Hz.

[0065] In one embodiment, the NoBll service 410 includes a logging mechanism to keep track of what happens during the service execution. When the service performs any relevant action, it saves a log description containing the details in a log file with the relevant log level (DEBUG, INFO, WARNING, and ERROR). When the NoBU service 410 blocks a suspect keystroke, it not only generates and displays a warning message for the user, but it also saves the details about which device and keycode it has blocked during this input event in the logging file.

[0066] The NoBU service 410 may be applied not only to keyboard, as illustrated in FIG. 4, but to other devices as now discussed with regard to FIG. 7. This figure shows a set of devices 102, 704, 706 connected to the host computing device 100 through a communication channel 712, which may be wired (e.g., USB port 112 in FIG. 4) or wireless (e.g., Bluetooth link). The set of devices includes, but is not limited to, a keyboard 102 and a mouse 704 connected to the host computing device 100 through USB ports 112, and a touchscreen panel 706 connected directly to the I / O bus of the host computing device 100. A set of sensors 720 (or a single sensor) may be deployed outside the host 100, inside the host, or both inside and outside the host, to sense different environmental parameters 409 associated with the devices, such as sounds, vibrations, electromagnetic spectrum, electrical impedance, etc. An input validation module 710 (for example, the monitor application 210 or the NoBU service 410) is installed on the OS of the host 100 to validate input signals using environmental parameters 409 measured by one or more of thesensors 720. The input validation module 710 checks the consistency of any input received from the device against the corresponding environmental data collected by the sensor(s) 720. FIG. 7 also shows the aggressor device 180 (also called aggressor device) represented as the rubber ducky, a hacking icon.

[0067] For example, for the case that the device is a keyboard 102, and the sensor 720 is a microphone and / or a vibration sensor, a method for determining whether the keyboard 102 is a legitimate device is illustrated in FIG. 8. The method 800 shows that initially the input validation module 710 is in the idle status 802. When a device 102 is attached to the host 100, an interrupt occurs, and the input validation module 710 intercepts 804 the input signal 408 before reaching a user application 214. The input validation module 710 analyzes 806 the input signal 402 to assess its nature, e.g., keystroke, mouse click, swipe on touchscreen, etc. Then, the input validation module 710 receives and checks 808 the measured signal 408, corresponding to the environmental parameter (recorded by the sensors 720 of the sensing device 230, and provided by the sensing application 220) and verifies 810 the consistency of the expected physical parameter associated with that device.

[0068] The verifying step 810 may be implemented in various ways. If an input signal 402 is associated with a keycode and the measured physical parameter (measured signal 408) is sound generated by the keycode, at a minimum, a time location of these two events within a same time window is required for a match. In a different embodiment, the keycode may be previously tested to determine its vibration signature and the measured physical parameter needs to match the vibration signature of that keycode (which is stored in the host 100). For otherdevices, other signatures are used. For example, if a wireless mouse is attached to the host 100, the wireless mouse uses a certain wave frequency or range of frequencies for communicating with the host 100 and the measured physical parameter are the wave frequencies. For the matching step, the measured wave frequency range needs to be emitted within a time window when the input signal 402 is generated (e.g., received).

[0069] However, if the input signal is determined to be suspicious 816, the input validation module 710 activates one or more corrective measures 818, which may include, but are not limited to: activate 820A an event log, block 820B the input signal, block 820C the device, notify 820D the user, etc. after which the input validation module returns to the idle status 802. While the method 800 has been discussed with regard to the sound associated with a keyboard or a printer, the method may also be used with a vibration sensor 720, that measures a vibration determined by the pressing of the keyboard, or the vibration generated by the printer when printing a document. Those skilled in the art would understand that for other devices, other characteristic parameters may be measured. For example, in one embodiment, it is possible to use an electrical impedance sensor 720 (e.g., capacitor) that measures a change in the electrical impedance associated with the device. The capability of the input validation module 710 to distinguish between a legitimate device and an aggressor device relies on the fact that the aggressor device, while impersonating the software features of a legitimate device, cannot impersonate the physical features of the legitimate device, i.e., no physicalphenomena will be sensed from the aggressor device when input signals from the aggressor device are generated.

[0070] FIG. 9 illustrates an embodiment in which the one or more sensors 720 are complemented by a proximity sensor 722 (e.g., a photodetector, infrared sensor, etc.) for determining a location of the device that tries to connect to the host computing device 100 or a location of the user hand while trying to reach the device. For this embodiment, there are two sensors 720, a microphone 720-1 and a vibration sensor 720-2. For this case, the input validation module 710 receives two measured external parameters for the device 102 or aggressor device 180 that tries to connect to the host 100, a sound from the microphone 720-1 and a vibration from the vibration sensor 720-2. For this scenario, step 808 of the method 800 may be modified to analyze two distinct physical (environmental) parameters (sound and vibration) and step 810 may be modified to match both physical parameters to the device. If one of the two physical parameters is not a match, then the method 800 determines 816 that the device is an aggressive device. However, in one embodiment, the step 810 may be modified to find as legitimate 812 the device if at least one of the two measured physical parameters matches the expected device.

[0071] The proximity sensor 722 is used in this embodiment to determine whether an object (e.g., human hand, human finger or another human part) is close to the expected device. In other words, if the expected device is a keyboard but there is no human interaction with the keyboard, step 810 may determine that the expected keyboard is in fact an aggressor device 180 as there is no interaction between that device and the human. In this scenario, the physical phenomenaexpected with the legitimate use of a keyboard or mouse may be a variation in the electric impedance in the proximity of the keyboard produced by the users’ fingers pressing a key. Note that the input from the proximity sensor 722 may be used together with the inputs from the other sensors 720 or instead of their input.

[0072] FIG. 10 presents a scenario in which the host computing device 100 has two devices, the keyboard 102 and a mouse 704, both wirelessly connected to the host 100. The system 1000 is equipped with (at least) four sensors: a microphone 720-1 capable of recording sounds, a vibration sensor 720-2 capable of measuring the amount and frequency of vibrations, a spectrum analyzer 1010 configured to measure wave frequencies, and a proximity sensor 722 capable of detecting the presence of an object, such as human hands / fingers, in close proximity to the protected devices.

[0073] In this scenario, the physical parameter (phenomena) expected from a legitimate use of a keyboard and mouse may be a sound and a vibration on the desk produced by pressing a keyboard / mouse key, and a variation in the electric impedance in the close proximity of the keyboard produced by the users’ fingers pressing the key. In addition, the electromagnetic field used by the keyboard and mouse to wireless connect to the host 100 may be sensed with the spectral analyzer 1010 to verify that there is indeed an actual wireless transmission between the device, 102 or 704, and the host 100. Thus, step 810 in method 800 needs to check four conditions for this scenario, sound, vibration, wavelength for wireless connection, and human body proximity. However, one skilled in the art would understand that step 810 may be modified to match at least two of these fourparameters, or at least three of these four parameters in order to determine the presence of a legitimate device(s). In one embodiment, it is enough to check the matching of only one parameter of the four parameters. The spectrum analyzer sensor 1010 may be used with any other wireless devices for determining that there is indeed a wireless signal incoming from the wireless device.

[0074] Another scenario is illustrated in FIG. 11 A. In this scenario, the host computing device 100 is equipped, among other peripherals, with a touchscreen monitor 706. For this setup, one or more vibration sensors 720-2, capable of measuring the amount and frequency of monitor vibrations, is directly attached to the monitor’s frame. For this scenario, the adversary uses a laser 1102 to emulate a legitimate user touch on the monitor 706 and activates the touchscreen panel without authorization. The expected physical parameter (phenomenon) for a legitimate use of a touchscreen is a vibration of the monitor 706, which is caused by the user’s pressure exerted on the monitor. Thus, in step 810, as the input validation module 710 does not receive a measured vibration of the monitor, as the laser 1102 does not generate such vibration, the input validation module determines 816 that the monitored device is an aggressor device and applies one of the outputs 820A to 820D. Alternatively or in addition, the vibration sensor 720-2 may be used to sense the physical presence of the human hand in close proximity to the touchscreen 706.

[0075] A variation of the disclosed solution for the scenario shown in FIG. 11 A is illustrated in FIG. 11 B, where the host 100 and the sensing device 230 is a same device, e.g., a smartphone. For this scenario, the host 100 already includes the microphone 720-1 , vibration sensor 720-2, and the spectrum analyzer 1010. Thesmartphone leverages these integrated sensors to match in step 810 events in the ambient physical domain with input signals coming from the touchscreen panel 1120 of the smartphone 100.

[0076] Method 800 discussed above is highly flexible and can be implemented with various sensors for various devices. Four possible implementations are discussed next but those skilled in the art would understand that many other implementations may be designed based on the method 800 and the teachings in this document. In the following implementation, the solution to an aggressor device includes a software part (that follows method 800 and has essentially the configuration shown in FIG. 4) and a hardware part (that includes one or more of the sensors 720 and / or 722 discussed above). The software component (e.g., the input validation module 710) is installed on the host computing device 100 to be protected, The hardware part differs from one scenario to another.

[0077] FIG. 12 shows a first configuration 1200 that uses at least a microphone 720-1 , a vibration sensor 720-2, and a spectrum analyzer 1010. All these sensors (and possibly others) are deployed on a dedicated hardware module 1202. The hardware module 1200 may be a Raspberry Pi, another integrated circuit, a pod (e.g., Amazon or Apple pod), etc. The hardware module is installed near the protected devices, such as the mouse 704 and keyboard 102.

[0078] FIG. 13 illustrates a similar system 1300, but the sensors are integrated on a device, e.g., a desk mat 1302 which is configured to be placed under the keyboard / mouse. The proximity sensor 722 may be integrated into the mat 1302 to sense the presence of human hands close to the protected devices. The proximitysensor 722 may be implemented in different ways, for example, embedding a conductive material inside the desk mat and measuring the electrical impedance with a capacitive sensor to capture its variations when the user’s fingers approach the keyboard / mouse to press a key. Other possible implementations include photoresistors, infrared sensors, etc.

[0079] FIG. 14 illustrates another system 1400 in which all the required sensors, such as a microphone 720-1 , vibration sensor 720-2, spectrum analyzer 1010, and possibly others, are deployed on a smartphone 1402. The user of the host 100 needs to place the smartphone 1402 close to the protected devices, such as a mouse 704 and keyboard 102.

[0080] FIG. 15 illustrates yet another implementation scenario of a system 1500 in which all the sensors 720, such as the microphone 720-1, vibration sensor 720-2, spectrum analyzer 722, a temperature sensor 720-3, proximity sensor 722, and possibly others, are integrated inside the device itself, such as the keyboard 102. A specialized implementation 1600 is illustrated in FIG. 16, in which multiple sensors 720, 722, 1010 are deployed at different locations over the external device 102. The input validation module 710 is installed in the host 100 and is configured to receive feedback from the physical domain, from different locations for the same event (e.g., pressing a keyboard, printing noise, etc.). This information is used by the input validation module 710 to compute a direction / location of the source of the physical parameter / event, in order to assess the consistency with the input received. In other words, based on the various information provided by the sensors 720 and 722, the input validation module 710 may determine that a printer noise or akeyboard noise is coming from a certain direction, and that direction needs to correspond to the direction associated with the location of the device relative to the sensors. The direction of the device may be determined with another sensor 720, for example a camera 720-4 that is currently present in most of the laptops and desktops. Thus, for these scenarios, the camera 720-4 may be located directly on the host computing device 100, as schematically illustrated in FIG. 16.

[0081] The inventors have tested the input validation module 710 when configured for the keyboard detection (i.e. , NoBll service 410) as now discussed. To demonstrate the flexibility of the NoBll service 410 and minimize the complexity of its setup, the inventors chose to implement the sensing device 230 as a smartphone 1402, similar to the scenario shown in FIG. 14. This choice allows the NoBll service to be distributed to the general public as a ready-to-use software, with no dedicated hardware required. However, the general architecture of the NoBll service may be implemented in many different ways depending on several factors, such as the deployment environment, end users’ needs, and other functional requirements. In particular, the sensing device can be either integrated with the host 100 or be a stand-alone device (e.g., a home pod). In the integrated configuration, the sensing application 220 (software component) runs directly on the sensing device 230, with the sensor(s) 720 connected via USB or in a wireless manner. In the stand-alone configuration, both the software and the sensors are deployed on a device, such as a smartphone 1402 or on an integrated circuit board, such as Arduino or Raspberry Pi.

[0082] An instance of the possible applications of the NoBll service was tested with commercial hardware, e.g., the host computing device 100 is a DELL XPS 15 9530 laptop equipped with an Intel Core i9-13900H processor, 32GB of RAM, and a 2TB SSD. An RTX 4070 GPU handles graphics processing with 12GB of dedicated memory. The host has a built-in membrane keyboard that is used during the experimental assessment. The OS is Ubuntu 22.04.4 LTS (also known as Jammy Jellyfish). This system hosts the NoBU’s monitor application 210.

[0083] Complementing the computer is the smartphone 1402, which is responsible for capturing the physical signals generated by typing (i.e. vibrations). For this test, the smartphone 1402 was a Samsung S22 (model SM-S901E / DS) running Android 14 OS with kernel version 5.10.168. Peripheral connections were managed through a USB Type-C HUB adapter that provides multiple ports, including three USB Type-A ports, one USB Type-C port, card readers, and an ethernet port. All ports adhere to high-speed standards, implementing version 3.0 of the USB protocol. The system was tested against two different external keyboards: one mechanical keyboard — a Cooler Master CK550 mechanical keyboard and one ultrathin membrane keyboard — an Apple Magic Keyboard. The Apple Magic Keyboard was selected because of its extremely thin design, which could attenuate vibration propagation.

[0084] For the adversary device 180, plural hacking tools were considered. These tools include the O.MG Elite Cable USB Type-A to USB Type-C, an O.MG Elite Plug, and a USB Rubber Ducky. Each tool possesses distinct capabilities tailored for executing malicious actions, and all of them support the Duckyscript™programming language. In addition, they feature internal storage for storing payloads, facilitating the initiation of various types of attacks. The O.MG devices provide more features than the RubberDucky; upon connection to a computer, they establish a Wi-Fi hotspot, enabling attackers to send payloads through a custom webpage at runtime. Contrarily, the USB Rubber Ducky requires pre-programming with payloads, with execution occurring upon USB device boot.

[0085] The assessment of the NoBU service followed a certain protocol that included the following steps. The protocol’s entry point involves activating the NoBU service. Then, once the monitoring service is started, a 2-minute timer is triggered. Each test session records four keystroke analysis sessions, distributed in a 30- second window each. The keystroke session can be a regular or an attack one. A regular session is characterized by the user writing a mock text in a notepad application. Otherwise, if an attack session is selected, the BadUSB is plugged into the computer, and an attack is performed. During this phase, the NoBU service analyzes each keystroke and chooses whether or not to block the input. The result collection (e.g., true positive, false negative, false positive, and true negative) is performed by the NoBU service (the monitor service), during the experiments. The protocol iterates five times in each environment to collect a statistically meaningful amount of data. Hence, if an environmental change is made, the protocol computes metrics (Accuracy, Precision, and Recall) for the previous environment. Otherwise, the protocol repeats in the same environment without modification, starting a new testing session before the computation of overall metrics.

[0086] Recognizing that different materials from which an office desk is composed of may influence the propagation of vibrations in unique ways, the inventors have chosen to examine two distinct materials: plywood and glass. Hence, the inventors chose two desks for the tests, one for each material. Furthermore, assuming that the keyboard type could also influence the results and accuracy of the NoBll service, each experiment was conducted using the laptop built-in, mechanical, and membrane keyboards, with a different run for each one. The experiments were conducted in a real-world working environment located within the university, e.g., a 150-square-meter open-space office with 24 workstations. Each experiment was performed on a desk located approximately at the center of the room, with noise and vibrations coming from any direction, during peak working hours.

[0087] On the selected desk, a standard office workspace arrangement was replicated, where the laptop is typically positioned centrally on the desk and the smartphone rests on the desk surface. Moreover, to replicate a common real-world workspace configuration, the laptop was placed at a fixed distance of 30 centimeters from the nearest desk edge, while the smartphone was placed at variable distances from the keyboard side. Assuming that the smartphone positioning with respect to the keyboard could impact the performance of the NoBll service, the inventors designed eight different testing scenarios to evaluate the system. In particular, the smartphone was placed on the desk at a distance of 8 / 16 / 24 / 32 cm from the keyboard and with a varying rotation angle of 0 / 45 / 90 / 180 degrees. Furthermore, the workspace was empty of external objects not needed for the test.

[0088] The tests were run on three BadllSB 180 variants: (1) the RubberDucky, which is a USB stick masquerading as a HID device, (2) the O.MG cable, which is a USB cable that provides power and data flow but that can also inject keystrokes identifying itself as a keyboard, and (3) the O.MG plug, which is a small USB stick masquerading as a HID device.

[0089] These BadUSB were programmed using PayloadStudio 4, which is the official high-level programming platform created explicitly for BadUSB devices. All the generated payloads, which were uploaded on the attack devices 180 for attacking the host 100, were designed using the Ubuntu OS. The attack payload includes the following steps: (1) opening a terminal using the shortcut Ctrl+Alt+T; (2) changing the working directory to the "tmp" directory using the "cd" command; (3) downloading a GIF file from the Internet; and (4) opening the GIF image using the "eog" command to start the default image reader. This attack payload is a straightforward attack script used to test the input validity module 710. The attack payload aimed to demonstrate that the type of attack device employed is not relevant, as the detection mechanism focuses on analyzing physical attributes derived from the attack device (keystrokes in these experiments), which cannot be mimicked through software functionalities.

[0090] The presented methodology focuses on analyzing the (possible) physical evidence of keystrokes resulting from the vibration signal. In this regard, FIG. 17A shows a signal 1700 recorded by the sensing device 230 when a user is not pressing keys on the keyboard. For this scenario, due to the lack of vibration signals, the NoBU service 410 denies any input from the keyboard. As shown in FIG.17B, a clear peak 1702 in the graph is associated with a legitimate keystroke. This means that when a key is physically pressed, the associated vibration propagates and generates the peak 1702. Even if the peak is weak, the NoBll service 410 can detect the peak and identify the presence of a human-produced keystroke. Finally, assuming that the vibration signal 1704 is extremely noisy, as shown in FIG. 17C, due to a possible jamming attack performed by the adversary or any other persistent external vibration noise, the scenario is dominated by chaos. For this scenario, the NoBll service 410 cannot detect a single peak considering the human average I KI and therefore, it does not further process the input signal.

[0091] To evaluate the above discussed methodology, the inventors executed the experimental protocol (also discussed above) five times for each considered surface (glass and wood), using three different keyboards: built-in membrane, Apple magic Keyboard, and mechanical keyboard, for a total of 30 iterations. During the tests, the smartphone was placed on the desk, at a distance of 16 cm from the keyboard, and parallel to it. This setup was designed as representative of a typical working environment. The results (not shown) of each experimental execution, also reporting the average results for each considered surface, were uniquely identified with a test ID in the format of (desk material)_(keyboard type)_(test iteration). The results analysis demonstrates a very weak, but still noticeable difference between glass-made and plywood-made desks in the sensed vibration. Moreover, analyzing MinG and MaxG, which are respectively the minimum and maximum registered g- force values, it can be concluded that the strength of the vibration signal depends on the keyboard topology, construction, and design. Considering the average results, itcan be observed that NoBll service is highly effective, regardless of the surface and keyboard used.

[0092] To assess the impact of the distance and orientation of the smartphone 1402 with respect to the keyboard 102, additional tests were performed in different configurations, i.e. , the smartphone was placed at different distances from the keyboard and in different orientations. Based on the experimental results, it can be concluded that the distance and the orientation of the smartphone do not impact on the efficacy of the NoBll service in detecting malware-emulated keystrokes.

[0093] The experimental sessions involved a total of 97,729 human-produced keystrokes and 82,546 malicious keystrokes, collected through 240 experimental sessions for 480 minutes of keystroke activity. The keystrokes classification statistics (not shown) indicate that the NoBll service never misclassified a malicious input. In fact, the results show 0 false negatives on each run, i.e., the attacker device did not inject a single character during the tests, certifying the high level of security provided by the input validation module 710. In the worst-case scenario, the NoBll service scored an accuracy of 98.92%, a precision of 97.73%, and a recall of 100%. The best score reached an accuracy of 100%, a precision of 100%, and a recall of 100%. Overall, the results show an average accuracy of 99.92%, a precision of 99.83%, and a recall of 100%. Considering that the variance of these metrics is close to 0, it confirms that in the majority of the tests the NoBll service showed the same or very similar (excellent) performance.

[0094] It is worth noticing that, since the NoBll service’s detection strategy relies on the identification of vibration signal peaks that are not synchronized with theincoming input, this solution has the valuable feature of being agnostic with respect to the user’s typing style, as well as the average I KI. Regarding system performance, the results show that the computational overhead of the NoBll service does not affect user experience. The average delay between the user keystroke and the input received by the application is 5.08 ms, which is the necessary time window to detect the keystroke peak and distinguish a fake input from a real one. To further minimize the delay, in one embodiment, the input validation module 710 may be modified to test the input signals from the device for a certain amount of time, and then to conclude that the device is legitimate and give up further monitoring. In another embodiment, the input validation module 710 may be configured to have an ON period for validating a given device, then an OFF period in which no validation for the given device is performed, followed by again an ON period and so on.

[0095] In addition, the inventors evaluated the impact of the NoBll service on the battery of the smartphone when acting as a sensing device. To perform this analysis, the Android Studio built-in tool called "Profiler" was used, which allows to register the performance statistics of the running application. The power consumption of the application was registered, leaving the screen always turned on and without the power save option enabled. The collected results show that, on average, the application itself, with all the children threads, has an average power consumption of 280 pAh. Therefore, the impact of the NoBll service on the battery of the smartphone 1402 (a Samsung S22 with a battery capacity of 3,700 mAh) was found to be negligible. Overall, during the experimental tests, the NoBll service misclassified a total of 146 genuine keystrokes as false positives, which isapproximately 0.15% of all human-produced keystrokes. Several factors could contribute to this kind of misclassification, reflecting the complex nature of real-world scenarios. First, environmental factors, such as nearby vibrations unrelated to keystrokes, might introduce noise into the system. This noise, when overlapping with keystroke vibrations, may prevent the NoBll service from recognizing genuine inputs, generating false positives. In addition, unintentional user actions, such as individuals accidentally pressing two keystrokes simultaneously, might generate additional false positives.

[0096] Although false positives may be tolerable in specific contexts, they generally impact on the user’s experience. To mitigate this issue and enhance the usability of the NoBll service, the inventors devised an alternative strategy based on keyboard enrollment. In one embodiment, when an alleged keyboard is recognized as such since it has produced a set of input signals for which the corresponding vibrations have been recorded and temporally matched, the NoBll service considers such a keyboard as a legitimate one and no longer validates its input. Thus, in this embodiment the NoBll service is used to possibly flag a keyboard as “trusted,” based on a certain number of input signals (or based the input signals received during a validation time period, for example, the first 10 minutes that the keyboard becomes active, but other time periods may be used) and thereafter accept its inputs without further validation and monitoring. This approach ensures an optimal balance between security and user convenience, enhancing the overall effectiveness and efficiency of our solution.

[0097] This variation of the NoBll service is called enhanced NoBll (eNoBll). The eNoBll includes an additional step (relative to method 800) of first deciding whether a new keyboard is a "trusted" device by synchronizing some of the received keycodes with the peaks of the measured signals and processing them as described in method 800. Then, each validated input is stored in a buffer of length A, which represents the number of genuine inputs required to trust a device. In order to decide the value A, the inventors considered that during the tests, it was found that the basic implementation of the NoBll service successfully blocked a BadllSB on the first received malicious character. Translating these results in the eNoBll service, a keyboard may be considered as “trusted” after validating a few characters. In one embodiment, A is 20. However, a different number may be selected for this parameter. This parameter ensures that a malicious device will not pass the NoBll service due to some environmental noise generating a peak during the first injected input. Decreasing the value of the parameter A may eventually reduce the security of the system, as the chance of authenticating malicious devices increases.

[0098] Once the buffer reaches a size equal to A, the eNoBll service either identifies the keyboard as a trusted device in the current active user session and accepts any input from this device, bypassing the validation routines, or will reject the device, triggering a warning.

[0099] In one embodiment, the eNoBll service does not permanently store the “trusted” status of a keyboard (or other external device). This measure is implemented to mitigate the risk of a potential threat scenario where an attacker plugs a BadllSB device into the target computing device, using a device namehaving the name of a previously authenticated keyboard, thereby executing a spoofing attack following a computing device reboot. Consequently, the eNoBll service must re-authenticate any legitimate device after each computing device boot or user log-out.

[0100] To evaluate the eNoBll service, a new experimental campaign was performed, by running the same experiments used to evaluate the NoBll service. This new experiment campaign tested the enrollment process of the eNoBll service, stopping the user input when the enrollment phase is complete, i.e. , using only the first 20 keystrokes, or when a genuine input is misclassified as malicious, i.e., false positive. After 125 test sessions, all concluded with the successful enrollment of the keyboard, the eNoBll service demonstrated an accuracy improvement. Specifically, the eNoBll service achieves 100% accuracy, greatly improved the user experience by completely eliminating false positives and sensibly decreased the system overhead by removing runtime checks.

[0101] It is worth mentioning that the eNoBll service does not require any challenge-response during the authentication of a new device (e.g., keyboard) like in the traditional methods. The eNoBll service works in the background, analyzing the received inputs while the user utilizes the keyboard for normal tasks. Moreover, the results of the experiments show that the average delay introduced in each I KI by analyzing each keystroke decreased from 5.08 ms to 0.26 ms.

[0102] In one embodiment, to allow communication between the monitor application 210 and the sensing application 220, the NoBll service opens an HTTP socket in the host computing device 100, which might increase the attack risk.However, the security concerns may be mitigated by encrypting the communication channel to avoid any privacy leakage, and managing the authentication with robust protocols to avoid any unauthorized usage of the NoBll architecture.

[0103] It is noted that the NoBll service has been designed to thwart current BadllSB. However, adversaries may design more sophisticated attacks, involving the capability to generate vibrations near the sensing device. Although complex, this attack is still feasible under specific assumptions, such as the ability to perfectly synchronize produced vibrations with injected fake inputs. In this case, the attack may bypass the NoBll service protections or perform a denial-of-service (DoS) attack against a legitimate keyboard. In response to this advanced scenario, an enhancement of the proposed service may involve the deployment of additional accelerometers around the legitimate keyboard. This may enable the triangulation of the received signals, thereby enabling the detection of the precise point of origin of the keystroke and effectively excluding vibrations coming from different directions.

[0104] The term “about” is used in this application to mean a variation of up to 20% of the parameter characterized by this term.

[0105] It will be understood that, although the terms first, second, etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another. For example, a first object or step could be termed a second object or step, and, similarly, a second object or step could be termed a first object or step, without departing from the scope of the present disclosure. The first object or step, and thesecond object or step, are both, objects or steps, respectively, but they are not to be considered the same object or step.

[0106] The terminology used in the description herein is for the purpose of describing particular embodiments and is not intended to be limiting. As used in this description and the appended claims, the singular forms "a," "an" and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that the term "and / or" as used herein refers to and encompasses any possible combinations of one or more of the associated listed items. It will be further understood that the terms "includes," "including," "comprises" and / or "comprising," when used in this specification, specify the presence of stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. Further, as used herein, the term "if" may be construed to mean "when" or "upon" or "in response to determining" or "in response to detecting," depending on the context.

[0107] The disclosed embodiments provide a method to be implemented in a host computing device for distinguishing between a legitimate device and an aggressor device. It should be understood that this description is not intended to limit the invention. On the contrary, the embodiments are intended to cover alternatives, modifications and equivalents, which are included in the spirit and scope of the invention as defined by the appended claims. Further, in the detailed description of the embodiments, numerous specific details are set forth in order to provide a comprehensive understanding of the claimed invention. However, one skilled in theart would understand that various embodiments may be practiced without such specific details.

[0108] Although the features and elements of the present embodiments are described in the embodiments in particular combinations, each feature or element can be used alone without the other features and elements of the embodiments or in various combinations with or without other features and elements disclosed herein.

[0109] This written description uses examples of the subject matter disclosed to enable any person skilled in the art to practice the same, including making and using any devices or systems and performing any incorporated methods. The patentable scope of the subject matter is defined by the claims, and may include other examples that occur to those skilled in the art. Such other examples are intended to be within the scope of the claims.The entire content of all the publications listed herein is incorporated by reference in this patent application.[1] Omar Adel Ibrahim, Savio Sciancalepore, Gabriele Oligeri, and Roberto Di Pietro. 2020. Magneto: Fingerprinting usb flash drives via unintentional magnetic emis- sions. ACM Transactions on Embedded Computing Systems (TECS) 20, 1 (2020), 1-26.[2] Patrick Cronin, Xing Gao, Haining Wang, and Chase Cotton. 2022. Time-print: Authenticating USB flash drives with novel timing fingerprints. In 2022 IEEE Symposium on Security and Privacy (SP). IEEE, 1002-1017.[3] Hessam Mohammadmoradi and Omprakash Gnawali. 2018. Making whitelistingbased defense work against badusb. In Proceedings of the 2nd International Conference on Smart Digital Environment. 127-134.[4] Koffi Anderson Koffi, Christos Smiliotopoulos, Constantinos Kolias, and Georgios Kambourakis. 2024. To (US)Be or Not to (US)Be: Discovering Malicious USB Peripherals through Neural Network-Driven Power Analysis. Electronics 13, 11 (2024). doi.org / 10.3390 / electronics13112117.[5] Federico Griscioli, Maurizio Pizzonia, and Marco Sacchetti. 2016. USBCheckln: Preventing BadUSB attacks by forcing human-device interaction. In 2016 14thAnnual Conference on Privacy, Security and Trust (PST). IEEE, 493-496.[6] Dave Jing Tian, Adam Bates, and Kevin Butler. 2015. Defending against malicious USB firmware with GoodUSB. In Proceedings of the 31st Annual Computer Security Applications Conference. 261-270.[7] Sebastian Neuner, Artemios G Voyiatzis, Spiros Fotopoulos, Collin Mulliner, and Edgar R Weippl. 2018. Usblock: Blocking usb-based keypress injection attacks. In Data and Applications Security and Privacy XXXII: 32nd Annual I PIP WG 11.3 Conference, DBSec 2018, Bergamo, Italy, July 16-18, 2018, Proceedings 32. Springer, 278-295.[8] Korean Patent Application KR 102019006623.[9] US Patent Application Publication 20220019549A1.

[0010] US Patent Application Publication 20200356665A1.

[0011] US Patent Application Publication 11568044B2.

Claims

WHAT IS CLAIMED IS:1 . A method (800) for validating a connection of a device (102, 180) to a host computing device (100), the method (800) comprising: intercepting (804), at a monitor application (210), an input signal (402) generated by the device (102, 180) when attaching to the host computing device (100); receiving (808), at the monitor application (210), a measurement signal (408) of an environment parameter (409) measured by a sensor (720) about the device (102, 180); verifying (810) a matching between the input signal (402) and the measurement signal (408) of the measured environment parameter (409); and releasing (814) the input signal (402) to an application (212) running on the host computing device (100) when the matching is valid.

2. The method of Claim 1 , wherein the step of intercepting comprises: precluding the input signal to be processed by the application.

3. The method of Claim 1 , wherein the step of intercepting comprises: locking the input signal at a local buffer.

4. The method of Claim 1, wherein the environment parameter is one of a sound, vibration, electromagnetic wave frequency, capacitance, electro / magnetic impedance, image, and temperature.

5. The method of Claim 1, wherein the step of receiving comprises: receiving from a smartphone the measurement signal.

6. The method of Claim 1, wherein the step of receiving comprises: receiving from a standalone device the measurement signal, wherein the standalone device is independent of the host computing device.

7. The method of Claim 1, wherein the step of receiving comprises: receiving in a wireless manner the measurement signal.

8. The method of Claim 1, wherein the sensor includes at least one of a vibration sensor, sound sensor, camera, temperature sensor, a spectrum analyzer, and a proximity sensor.

9. The method of Claim 1, wherein the step of verifying comprises: determining whether a time stamp of the input signal and a time of a peak of the measurement signal are within a given time window.

10. The method of Claim 1, wherein the step of intercepting comprises: applying one of a universal serial bus (USB), system bus, Wi-Fi, touchscreen, or Bluetooth protocol for connecting the device to the host computing device.

11. A host computing device (100) for validating a connection to a device (102, 180), the computing device (100) comprising: a processor (104) hosting a monitor application (210), which is configured to intercept (804) an input signal (402) generated by the device (102, 180) when attached to the host computing device (100); and a transceiver (108) configured to receive (808) a measurement signal (408) of an environment parameter (409) measured by a sensor (720) about the device (102, 180), wherein the processor (104) is further configured to: verify (810) a matching between the input signal (402) and the measurement signal (408) of the measured environment parameter (409); and release (814) the input signal (402) to an application (212) running on the host computing device (100) when the matching is valid.

12. The host computing device of Claim 11, wherein the processor is further configured to preclude the input signal to be accessed by the application.

13. The host computing device of Claim 11, wherein the processor is further configured to lock the input signal at a local buffer.

14. The host computing device of Claim 11, wherein the environment parameter is one of a sound, vibration, electromagnetic wave frequency, capacitance, electric / magnetic impedance, image, and temperature.

15. The host computing device of Claim 11, wherein the processor is further configured to receive the measurement signal from a smartphone.

16. The host computing device of Claim 11, wherein the processor is further configured to receive the measurement signal from a standalone device, wherein the standalone device is independent of the host computing device.

17. The host computing device of Claim 11, wherein the transceiver is configured to receive in a wireless manner the measurement signal.

18. The host computing device of Claim 11 , wherein the sensor includes at least one of a vibration sensor, sound sensor, camera, temperature sensor, a spectrum analyzer, and a proximity sensor.

19. The host computing device of Claim 11, wherein the processor is configured to determine whether a time stamp of the input signal and a time of a peak of the measurement signal are within a given time window.

20. The host computing device of Claim 11, wherein the processor is further configured to apply one of a universal serial bus (USB), Wi-Fi, or Bluetooth protocols for connecting the device to the host computing device.

Images