KR20240107991A - System for authenticating USB devices of mobile devices and method therefor - Google Patents

Abstract

The present invention relates to a USB device authentication system for a mobile device, and more particularly, to a USB device authentication system and method for a mobile device for defending against attacks using a USB malicious device on a mobile device. The USB device authentication system for a mobile device according to the present invention comprises: a judgment unit that judges the type of a USB device based on artificial intelligence; an interface unit that checks whether an interface of the USB device requested to an operating system kernel for each USB device type is activated according to the judgment result; and a control unit that determines the safety of a current connection according to whether the interface is activated, and has the effect of defending against a USB spoofing attack that performs a task different from the appearance of the USB device.

Description

{System for authenticating USB devices of mobile devices and method therefor}

The present invention relates to a USB device authentication system for mobile devices, and more specifically, to a USB device authentication system and method for mobile devices to prevent attacks using USB malicious devices on mobile devices.

Since the invention of USB (Universal Serial Bus), the USB protocol has continued to improve in terms of communication speed and expansion of versatility. In particular, PnP, which allows immediate use of peripheral devices with convenience and usability, is one of the key functions contributing to the popularization and continued development of USB. However, USB has been implemented in a way that blindly trusts an unspecified number of devices and has been abused for host attacks. Various attacks using USB include malware injection, key logging, key injection, eavesdropping, and data leakage. A tool to make this possible has been presented. USB attack methods can be classified into three types as follows.

Exploiting software vulnerabilities: This attack is used as a raw attack that exploits vulnerabilities in the USB device driver and USB Core to attack other kernel components.

Protocol masquerading: Malicious USB devices can behave unexpectedly by the user. For example, it may look like a USB storage device, but it is recognized by the host system as a USB keyboard and injects keystrokes.

Social engineering attackers trick users into connecting malicious USB devices to the host system. Then, the user directly executes the malware delivered from the USB device, or the system's autorun function (autorun.inf) automatically executes the malware.

Social engineering attacks can be implemented in the basic steps (1) and (2). That is, it allows the user to connect a USB device to the host that performs unexpected actions on the host or transmits an attack payload that exploits software vulnerabilities. To defend against this, several measures have been proposed:

Educates users about the risks of social engineering attacks, security settings to prevent abuse of the AutoRun feature, built-in Windows features executables to block unauthorized use, a virus scanner to detect malware on USB devices, and an antivirus to block malware. systems, etc. Additionally, common software security techniques were adopted to prevent attacks from exploiting vulnerabilities in the USB software stack. For example, fuzzing and virtualization-based isolation can each be revisited to find or isolate vulnerable parts of USB software.

Camouflage attacks, which are the main target of this work, are difficult to defend against. For example, Rubber Ducky is a malicious USB device that can disguise itself as a USB storage device and inject keystrokes. It is available for public purchase at a low price, and Script Kid can easily write the script that needs to be written for keystroke injection. These masquerade attacks only behave differently from what the user expected, and since the behavior itself operates based on the standard interface defined in the kernel, it is impossible to use countermeasures such as software fuzzing or virus scanners.

USB authentication solutions using whitelists are widely used to defend against USB protocol spoofing attacks. Port-Blocker first locks the USB port and then only allows devices pre-registered in the whitelist. USB FILTER enables filtering of USB packets sent to the host based on USB device information such as product and manufacturer. Cinch and USBSec performed authentication by encrypting communication between host and device.

On the other hand, Mohammadmoradi et al. We proposed using the top seven USB features to generate a unique identifier for whitelisting. DeviceVeil proposed a method to register and authenticate USB devices to the host system using a hardware PUF (Physically Unclonable Function). These defensive techniques are less practical for the following reasons:

Maintaining a whitelist to manage existing and newly released USB devices requires significant costs. In particular, depending on the solution, a USB device must first be connected to the host to set up whitelist and access control policies.

For encryption and PUF-based authentication, additional hardware must be acquired to enable the encryption function and derive strong identifiers from the hardware.

Device information used for authentication, such as vendor ID (VID) and product ID (PID), can be easily tampered with. This is because the identifier information for the whitelist is provided by the malicious USB device itself. For example, an attacker could manipulate the USB descriptor provided to the host to claim that the device is a specific HID device. When these malicious devices connect to a host, malicious scripts embedded in the device are immediately executed by PnP.

Public patent 10-2019-0103801 (2019.09.05)

The purpose of the present invention is to provide a USB device authentication system and method for mobile devices to prevent attacks using USB malicious devices on mobile devices.

In order to achieve the above object, the present invention includes a determination unit that determines the type of USB device based on artificial intelligence, and a determination unit that determines whether the interface of the USB device requested in the operating system kernel for each USB device type is activated according to the result of the determination unit. It includes an interface unit and a control unit that determines the security of the current connection depending on whether the interface unit is activated.

Meanwhile, in a method using a USB device authentication system of a mobile device, (a) the USB device authentication system determines a type of USB device, (b) the USB device authentication system determines the type of the USB device according to the determination result of (a). It includes the step of checking whether the interface of the USB device requested by the operating system kernel for each USB device type is activated, and (c) the USB device authentication system determining the security of the current connection depending on whether the interface is activated.

According to the present invention, it is possible to prevent an attack (USB spoofing attack) that deceives the user and performs a task different from the appearance of the USB device. For example, it is effective in preventing attacks where USB storage performs keystrokes, such as Rubber Ducky, a known USB attack tool.

Figure 1 shows the use model of the USB Eye overview.
Figure 2 is a diagram to explain the connection between USB Eye and USB device.
Figure 3 shows a polling-based system design.
Figure 4 illustrates the analysis of USB device connection time.
Figure 5 is a block diagram showing the configuration of a USB device authentication system for a mobile device according to an embodiment of the present invention.
Figure 6 is a schematic flowchart showing a USB device authentication method for a mobile device according to an embodiment of the present invention.

Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. However, the present invention is not limited or limited by the exemplary embodiments. The same reference numerals in each drawing indicate members that perform substantially the same function.

The purpose and effect of the present invention can be naturally understood or become clearer through the following description, and the purpose and effect of the present invention are not limited to the following description. Additionally, in describing the present invention, if it is determined that a detailed description of known techniques related to the present invention may unnecessarily obscure the gist of the present invention, the detailed description will be omitted.

The USB device authentication system for mobile devices according to an embodiment of the present invention is a system for USB device authentication to prevent attacks using USB malicious devices on mobile devices.

Security on Universal Serial Bus (USB) is a lower priority than convenience. For example, USB device connections are trusted blindly to enable Plug and Play (PnP). However, improper authentication of the device can lead to attacks, especially impersonating USB devices. To solve this problem, a whitelist-based USB device authentication method was proposed. However, it lacks practicality in that maintaining a list of legitimate devices requires significant effort and cost. It also highlights the limitations of these approaches, as potentially malicious devices can easily bypass them because they provide the information needed for authentication.

To alleviate this problem, we propose USB Eye, a CNN (Convolutional Neural Network)-enabled USB device, as an authentication solution. In particular, it detects impersonated USB devices by verifying the legitimacy of the defined USB interface based on the device type inferred by the CNN. For example, if a device is classified as USB storage but defines a keyboard interface, USB Eye determines that the USB device currently connected to the host is malicious.

In this example, we demonstrated the feasibility of our approach by implementing an Android application that performs image classification and a USB filter in the Linux kernel that blocks malicious USB device connections. Security analysis using Rubber Duck shows that USB Eye successfully detects and blocks protocol spoofing attacks.

In this embodiment, we propose a solution called USB Eye that can defend against USB protocol masquerade attacks without maintaining a whitelist, verifying firmware, or introducing additional hardware. It can detect and block malicious and unexpected interfaces on USB devices connected to mobile devices. To achieve this, USB Eye infers the type of USB device through CNN (Convolutional Neural Network). It then determines the security of the current connection to the device by checking the device's requested interface against the interfaces allowed in the security policy for each device type.

If the device is determined to be non-malicious, USB Eye loads the corresponding drivers for all interfaces. If unsafe, USB Eye cancels all interface bindings. For robust user-centric verification, USB Eye provides a strict mode that always pops up all interfaces whenever a new USB device is connected to the host.

In strict mode, a list of interfaces is displayed so that the user can selectively activate parts of the interface. If the device is determined to be insecure, a security warning will pop up with all interface information.

In this example, USB Eye was implemented on a Juno board equipped with a Cortex-A53 core. Android and Linux kernel versions are 9.0.0 release 33 and 4.14.59, respectively.

USB Eye consists of an Android application running a CNN to infer the USB type, patches to the HID and USB Core to determine USB HID events and the interface of a USB device, and an Android service to help the application communicate with the patched USB core. do.

The security of USB Eye was evaluated using Rubber Ducky. USB Eye successfully thwarts Masquerade attacks by exposing Rubber Ducky's hidden keyboard interface. In performance analysis, the experimental results indicate that our security system incurs an acceptable performance overhead of 101% for USB device connection and 2% for USB event processing. In summary, this embodiment makes the following contributions.

We propose USB Eye, a solution that effectively blocks USB protocol spoofing, which is difficult to apply in real environments without a whitelist or additional hardware.

Neural networks for inferring USB device types are utilized to automate security decisions about device connections, minimizing the downside of frequent security alerts.

Although USB Eye's PoC was implemented and evaluated on the Juno ARM reference board running Android, the basic design is architecture and OS agnostic. Therefore, it will also expand to server and PC environments.

The USB Device Descriptor is explained as follows.

A USB device contains a single device descriptor and sub-descriptors such as configuration, interface, and endpoint. In particular, the configuration defines the combination of interfaces that are the logical functions of the USB device. If a user configures a USB headset with only a speaker and button interface that provides interfaces for a microphone, buttons, and speaker, the microphone will be disabled on that headset. When a USB device is connected to a host device system, the USB core binds each interface in the configuration to the appropriate device driver.

In particular, each driver handles the functionality of a USB device. The interface descriptor, which contains information such as BInterfaceClass, BInterfaceSubClass, and BInterfaceProtocol, is referenced along with the idVendor and idProduct of the device descriptor to determine which driver to bind.

Linux USB system and USB device registration are explained as follows.

On Linux systems, the USB Core performs USB subsystem initialization, USB bus creation and registration, USB data structure allocation and management, descriptor management, USB connection, and driver binding to enable USB devices on the Linux host system. USB Core manages all USB devices through the Hub concept. USB devices are managed and used logically connected to the system's hub whenever they are physically connected.

Specifically, when a USB device is connected, the hub handles connection events on the hub port by registering the USB device on the bus and creating a USB object for the new device. USB Core obtains interface information by querying connected USB devices. Then, USB Core performs a series of processes to bind the interface of the USB device to each driver so that it can perform the functions defined for the USB device.

Let's explain Android Services.

Android services are daemons that provide important APIs required for application development according to user service requirements. These services are classified into JAVA services and native services implemented in C or C++. The Native Development Kit (NDK) is a set of tools that help developers develop C and C++ code on Android, and the Java Native Interface (JNI) is an interface that facilitates communication between JAVA and native binaries. Android provides an NDK and JNI to help developers easily develop basic services such as system calls and hardware controls that are difficult to handle in Java.

Attacks Against USB are explained as follows.

Attack vectors using USB devices are described in detail here.

They are classified into three types: software vulnerabilities, protocol impersonation, and social engineering.

Exploiting software vulnerabilities. An attacker could exploit a host's USB device driver vulnerability by using a malicious USB device that delivers an attack payload. Device drivers typically have the same privileges as the OS, so a successful attack against a device driver can compromise the entire system.

Protocol camouflage. It performs malicious actions by hiding unexpected HID interfaces. BadUSB and Rubber Ducky, which allow changing the firmware of USB storage devices, are examples of tools that perform Masquerade attacks. Users recognize it as a normal USB storage device, but an unexpected interface is defined. It can act maliciously once connected to a host by performing HID functions with a mouse and keyboard. Because these hidden HID interfaces operate using standard USB protocols, their operation is considered legal on the host system.

Social engineering attacks. Autorun.inf can be exploited, which can be used in the AutoRun feature to automatically perform certain tasks when removable media is connected to a host.

Users can also make USB devices run malicious software. To carry out both attacks described above, a malicious USB must be physically connected to the victim's host device.

As a prelude to both attacks, attackers can exploit social engineering techniques to trick users into connecting a USB device to a host device. Social engineering attacks exploit trust between people to achieve their goals.

The explanation of Darknet is as follows.

Darknet is an open source neural network framework written in C and CUDA. Users can configure model training by writing a cfg file that defines variables such as placement of input images, segmentation, width and height, and network architecture. You can also use data files to organize training data.

As a result of training, a weight-file defining the trained model is created. In addition to the CNN adopted here, there are various tools using RNN (Recurrent Neural Network) and GAN (Generative Adversarial Network). Additionally, due to its lightweight size, the framework was hosted in a trusted execution environment (TEE) to enhance model security on edge devices.

The threat model of the USB device authentication system for mobile devices according to this embodiment is described as follows.

Attackers can perform social engineering attacks to trick users into connecting malicious USB devices. Malicious devices refer to tools such as BadUSB and Rubber Ducky that carry out Masquerade attacks. So the malicious tool triggers an unexpected operation, but from the kernel's perspective the operation is still normal because it is performed according to the standard USB protocol. By exploiting this, attackers attempt to exfiltrate sensitive data from mobile devices or perform additional malicious actions, such as downloading malware. However, this embodiment assumes that the attacker cannot physically obtain the victim's device.

This means that attackers cannot perform signal injection attacks on the USB bus that require physical access to the device, such as signal eavesdropping or power analysis. Additionally, executing malicious binaries (scripts) directly on a malicious USB device and exploiting vulnerabilities in the host USB software stack are not considered here.

Figure 1 shows the usage model of the USB Eye overview.

The USAGE MODEL according to this embodiment is described as follows.

In this embodiment, the initialization method of the proposed system will first be described. We will then explain the procedure for using USB devices under the supervision of USB Eye from the user's perspective.

Initialization step. A neural network model (Darknet's weight-file) is trained using images of four types of USB devices - mass storage, keyboard, mouse, and headset - and infers the type of USB device distributed to the user from a remote server when USB Eye is present.

installation. It is also updated asynchronously when helper_app runs. Assume that the current security administrator has created the model. However, federated learning can be adopted to train privacy preserving models.

Runtime phase. Once USB Eye is deployed and activated, the system according to this embodiment must follow the USB connection procedure as shown in Figure 1. The system according to this embodiment first executes helper_app and proceeds to the next step.

(1) Take a photo of the USB device to be connected.

(2) Darknet starts in the background. Classifies photos to infer USB device type.

(3) Check the USB type classified by Darknet in the text box in step 2 and connect the USB device to the host. Afterwards, if the USB device is determined to be non-malicious against the security policy, users can use it immediately.

USB devices are blocked if they are insecure (defining a spoofed interface that the user does not recognize).

Taking misclassification into account, USB Eye provides two operating modes: basic and strict, which can be switched by configuring helper_app. In default mode, USB Eye operates with automatic connect and disconnect as previously mentioned. However, in strict mode, USB Eye unconditionally pops up USB interface information, allowing the user to recognize all interfaces defined on the USB device and selectively activate the desired interface.

Despite the possibility of misclassification by neural networks, it is still advantageous to use it because it alleviates the disadvantage of frequent pop-up windows. In particular, frequent pop-ups can cause fatigue and lead users to sometimes ignore conversations. For example, users who are annoyed by pop-up windows may ignore the warning and click the "Connect All" button, or they may become accustomed to pop-up windows and click the "Connect All" button inadvertently.

The system design according to this embodiment is described as follows. Here we will explain the details of USB Eye, including how USB devices are connected and how security policies are defined and referenced to verify USB devices.

An overview of the USB Eye according to this embodiment is described as follows.

In this embodiment, we propose a security system called USB Eye that defends against Masquerade attacks that can be easily performed by BadUSB and Rubber Ducky.

As explained previously, the functionality of a USB device is expressed as an interface in the USB protocol, and in order to handle that functionality, the device driver must be properly bound to the interface. In particular, for an impersonation attack to perform its malicious operations, each driver must bind to an interface defined for protocol impersonation. Therefore, the most appropriate instance to block Masquerade attacks and detect unexpected interfaces is right before binding the driver.

USB Eye according to this embodiment checks the current connection and detects malicious interfaces according to the USB device type determined by the CNN. Verification is accomplished by setting and enforcing the security policy defined by the administrator with the minimum general interface suitable for a specific device. Depending on the verification results and the selected mode, USB Eye automatically connects or rejects connected devices (default mode) or informs the user of all interface information so that the user can connect only the desired interface (strict mode).

Additionally, if a USB device is not secure in strict mode, a warning is included in a pop-up along with the interface. By selectively activating the interface, you can block some functions of privacy-sensitive USB IO devices (microphone, cam, etc.) at the kernel level, preventing malicious software from abusing the bound interface. Users can choose between the benefits of fewer pop-up windows in default mode or the benefits of optional connection interfaces in strict mode.

Figure 2 is a diagram to explain the connection between USB Eye and USB device. As shown in Figure 2, it is performed as follows. (1) The USB device authentication system of the mobile device according to this embodiment infers and updates the type of the USB device. (2) Next, the USB device is connected to the mobile device's USB device authentication system. (3) Next, the USB device authentication system of the mobile device updates the device information. (4) Next, the USB device authentication system of the mobile device runs the Android service. (5) Next, the mobile device's USB device authentication system requests and receives information about the device and the inferred type. (6) Next, the mobile device's USB device authentication system verifies the USB device. (7) Next, the mobile device's USB device authentication system creates and displays a warning dialog box. At this time, if the basic mode is selected, skip to (9). (8) Next, the USB device authentication system of the mobile device receives a response from the user through external input. (9) Next, the USB device authentication system of the mobile device updates the connection information. (10) Next, the mobile device's USB device authentication system binds the driver to the selected interface.

The key components of USB Eye in the USB device authentication system for mobile devices according to this embodiment are described as follows.

USBEye consists of the following components:

?? The USBEye driver, a common Linux device driver, shares the USB device data structure, such as the interface, with USB Core.

?? In default mode, the Android service verifies the safety of the current connection and sends connection options (e.g. Connect All or Refuse All) to the selected USBEye driver. In strict mode, the Android service encodes USB interface information and presents it to the user through an AlertDialog.

The USB connection option selected by the user is transmitted to the USBEye driver.

?? helper_app classifies the type of USB device and transmits the results to the USBEye driver.

?? Using NDK, native services (C or C++) can be processed in JAVA. Portions of Android services and helper_app are implemented in the NDK to support basic operations such as communicating with the OS kernel. In particular, data sharing between the USB Eye driver and helpe_app is performed using the NDK service.

USB interface verification is explained as follows.

During USB Eye's verification process, as the user proceeds through steps 1 and 2 of helper_app, USB Eye passes the USB type inferred from Darknet to the USB Eye driver. If the user skips this, the USB connection cannot proceed. When the user proceeds to step 3 and the USB device is connected to the host device's USB hub, USB Eye updates USB device information such as the interface from the USB Core to the USB Eye driver. Then run the activity manager (am) command to run the Android service. The Android service obtains the type and USB device information inferred from the USB Eye driver through native (NDK) functions. The Android service verifies the safety of the connection with the USB device by comparing the interface expected to be defined on the device depending on the type with the actually defined interface of the USB device. If both pieces of information match, the USB device defines only legitimate interfaces, no spoofed interfaces, and the Android service determines that the device is safe to connect and updates the connection information to "Connect any interface." Conversely, a mismatch indicates that the USB device contains a spoofed interface. The Android service determines that the device is insecure and updates the connection information to 'deny all interfaces'.

If you select Strict mode, the Android service creates an AlertDialog with device information instead of directly updating the connection information and shows all interfaces defined on the device to the user through the AlertDialog. If the Android service determines that the device is unsafe, the AlertDialog includes a warning. Users can check the safety of the connected USB device by checking the warning message and selecting the interface to connect to by responding to the AlertDialog. The Android service then updates the USBEye driver with connection options, such as connect all interfaces, reject all interfaces, or connect only the interface selected by the user, and reads the options from the USB Core. Finally, USB Core handles the current connection according to your options.

By default, malicious devices are automatically blocked by USB Eye, so users can be aware that their device has some malicious features defined. In strict mode, the user can decide whether to trust the device based on the information displayed in the AlertDialog, such as the USB device's interface and alerts.

Additionally, when users select strict mode and enable selective connectivity, users can safely use only selected USB device features. For example, assuming a user wants to turn off the video cam's camera feature when using a video conferencing application, a video conferencing application compromised by an attacker could intentionally turn on the camera or request sensitive data from the video cam.

In this case, when the user selects strict mode and selects the desired interface, unselected interfaces will not be bound to the driver, preventing compromised applications from abusing the device's functionality. In this embodiment, since the OS is trusted in the attack model, kernel exploits that allow malicious applications to elevate privileges are not considered.

The effects of AI introduction are explained as follows.

As previously explained for USB interface verification, automatic connection or rejection in default mode can reduce the frequency of pop-up windows. In strict mode, device information is always popped up for user response. The connection rules can be summarized as follows.

R1. If you select Basic mode and the USB device's interface matches the expected interface defined in the security policy, the device will be automatically connected by USBEye without displaying a pop-up window.

R2. If Basic Mode is selected and the USB device's interface does not match the expected interface, USBEye will automatically reject all connections without displaying a pop-up window.

R3. If strict mode is selected and the USB device's interface matches the expected interface, USBEye displays a pop-up window with information for all interfaces.

R4. If strict mode is selected and the USB device's interface does not match the expected interface, USBEye displays a pop-up window with a warning message and a list of interfaces.

R1 ensures that USB devices cannot perform malicious operations outside of a secure, defined interface. For example, helper_app classifies the device type as a mass storage device, and the interface set of the device expected by the security policy is also a mass storage device type (bInterfaceClass: 0x8). If devices define the same inferred interface, they may not perform unexpected actions such as inserting keystrokes and illegally recording other than data storage. Therefore, USBEye connects USB devices without user interaction. For R2s where the interface does not match the type, the USB device may perform unexpected behavior. As a result, USBEye determines that the device is potentially malicious and blocks its connection to the host.

R1 and R2 do not require user intervention to connect a USB device, thus relieving the user of the burden of frequent pop-ups.

R3 considers situations where the type of USB device matches the expected interface in strict mode. For example, an administrator configures a security policy that requires USB headsets to define four interfaces. This includes one interface for the control device, represented by bInterfaceClass: 0x1 (Audio) and bInterface-Subclass: 0x1 (Control Device), two interfaces for streaming inputs, and bInterface-Subclass: 0x1 (Audio) and bInterfaceSubclass: 0x2 (Streaming). There is a final HID interface to control the output and the volume presented by bInterface-Class: 0x3 (HID), bInterfaceSubclass: 0x0 (None) and bInterfaceProtocol: 0x0 (None). The last interface is an exception where HID events must be validated at runtime after the corresponding device driver has been bound. This will be discussed further in HID event verification. Because the interfaces defined by the USB device meet the security policy, USB Eye considers the current connection to be secure, but continues to display a pop-up with a list of all interfaces so that the user can selectively enable parts of the interfaces. In R4, USB devices are suspected of carrying out Masquerade attacks, so a warning message has been added to the pop-up to warn users to choose their interfaces carefully.

In summary, unlike R1 and R2, R3 and R4 always require user intervention for USB connection. Frequent pop-ups reduce the effectiveness of the security system. However, there are still benefits to selectively activating interfaces, so we continue to consider this option. In PoC, the user switches between basic mode and strict mode through helper_app before connecting the device.

HID event verification is explained as follows.

In addition to specific device drivers provided by device manufacturers, generic device drivers bundled with the OS are also used for HID event processing. In particular, USB HID interfaces that do not provide enough information in the usb_match_id function to match the appropriate device driver are processed by binding the HID generic driver.

HID generic drivers are commonly used to comprehensively handle events from generic HID devices such as keyboards, mice, and touchpads. Input events generated from the HID interface to which the HID generic driver is bound are delivered to the input device driver through an input core called the HID core. The input device driver parses and determines the type of input event received from the HID device. The event is then finally passed to the event driver and processed accordingly.

Among the interfaces to which the HID generic driver must bind, some do not specify the type of HID device [bInterfaceClass: 0x3(HID), bInterfaceSubclass: 0x0(None), and bInterfaceProtocol: 0x0(None)]. In particular, the HID function used by the interface is not specified when the driver is enumerated. Therefore, after binding the HID generic driver to this interface, you need to check what kind of HID events occur within the driver. For example, for a USB headset, you can define interfaces 0x3, 0x0, 0x0 for audio button control (volume up, volume down, microphone mute). Since the HID generic driver handles all HID events such as keyboard and mouse, you should consider whether this interface is being used for malicious purposes. Therefore, USB Eye added verification logic to the HID core to check HID events after binding. Unsafe events are blocked depending on the type of USB device, and an example confirmation rule is as follows.

?? USB audio device types, such as USB headsets and USB speakers, reject all keyboard events except four events: volume up, volume down, mute, and microphone on/off.

?? Non-USB keyboard device types except USB audio will reject all keyboard events.

?? All device types other than a USB mouse will reject all mouse events.

?? Rejects all HID touchpad device events.

For stability, this verification method implements a 'deny all, allow some' policy to allow only necessary events. Based on the first and second rules, all malicious keyboard events (keystrokes) except essential keyboard event codes (scan codes) can be blocked. The third and fourth rules can block malicious mouse and touchpad events. These rule sets are examples and administrators can set their own rules appropriate for their organization and IT infrastructure. (For example, administrators configure security policies to allow the mouse's own interface and the keyboard interface.)

The implementation of a USB device authentication system for a mobile device according to an embodiment of the present invention will be described as follows.

USBEye was implemented on the ARM Juno r2 development board with Cortex-A72 and A53 CPUs and 8GB DDR3 RAM memory. As a software platform, Android (9.0.0) and Linux kernel (4.14.59) were run.

Kernel components of the USB device authentication system for mobile devices according to this embodiment will be described.

Registering a USB device in Linux. When the system boots, the USB core initializes the components associated with the USB subsystem and creates the USB bus. In Linux, a hub logically manages all connected USB devices. Whenever a new device connects to the host, hub events are processed by a kthread that creates and deletes data structures for each connected device. As part of connection event processing, the device_add function is called multiple times, each registering a new USB device and binding the appropriate driver to the interface. In particular, after registration, the core communicates with the device to obtain information such as VID, PID, and interface. Finally, call device_add of set_configuration to bind the device driver to the interface. This entire procedure is called USB enumeration.

Kernel patch. If USB Eye is determined to be malicious, it displays the interface information of the currently connected USB device. In the Linux kernel, when enumerating USB, device registration and information are obtained before the device_add function for interface binding is called in the set_configuration function of the USB core. Therefore, update the USB core source (linux/drivers/usb/core/message.c) to deliver interface information to helper_app and receive user responses.

In particular, the call_usermodeheloper API adopted to start the NDK binary targeting running Android services is inserted before the for loop that enumerates all interfaces to bind the appropriate device driver. Logic is added to the loop to reflect the user's decision to (de)activate individual interfaces. In addition to the USB core, the HID core has been strengthened for fine-grained control of HID events. Illegal HID events are blocked by checking the event code in the hid_input_field function of hid-core.

USB eye driver. In addition to the kernel patch, we implemented the USBEye kernel driver to help the USB core communicate with user-level components (such as helper_app, Darknet, and Android services).

It is a simple character device driver that provides read, write, and ioctl handlers for sharing data between user and kernel. Several data structures have been developed for data sharing, such as providing flags for the inferred USB type, the requested USB interface, the user's interface, and the decision to enable synchronization.

The user components are explained as follows.

Android service. The service requires system permissions to overlay UI components such as AlertDialog on the current display. When building the Android framework, you grant system permissions to Android services by building them as privileged applications.

Native Development Kit (NDK). In this embodiment, the NDK was used to perform the basic functions of the Android service and helper_app that cannot be directly supported by Java code. NDK provides basic services through JNI as part of Android services and applications. Darknet was ported as a native service that can be called from Android applications using the NDK.

Let's explain polling-based design.

You could consider a polling-based design, using an Android system service that runs periodically in the background to handle events that connect new USB devices. The service is also responsible for UI management and communication with users. Unlike current designs, this approach does not require starting a new process (i.e. am service) simultaneously with USB port events, which causes the highest overhead observed in the performance evaluation.

Additionally, these event-triggered process creations are exempted, eliminating the need to change the USB core. However, considering power consumption, polling-based approaches may not be suitable for mobile device environments. Additionally, as seen in the performance evaluation, the polling-based design generated additional CPU usage and load compared to the proposed design.

Evaluation in the USB device authentication system for mobile devices according to this embodiment is described as follows.

This will be explained in relation to the Model and Dataset of Darknet.

In the cfg file, we set up a neural network architecture with batch 16, learning delay 0.1, and 7 convolutional layers and 3 max-pooling layers. The convolution layer is structured as follows. Activation is leakey, size is [3, 1, 3, 1, 3, 1, 1], filter is [16, 8, 32, 16, 64, 32, 10]. It also configures a connection layer with linear activation and four outputs to classify USB devices into one of four types. We use a dataset with 3K images for training, with approximately 700 images each for four types of USB devices: USB keyboard, USB mouse, USB mass storage device, and USB headset.

Figure 3 shows a polling-based system design. Each component of USB Eye works as follows: (1) The USB device authentication system of the mobile device according to this embodiment infers and updates the type of the USB device (hereinafter performed by the USB device authentication system of the mobile device). (2) The USB device is connected. (3) Update device information. (4) Request and receive information about the device and expected type. (5) Check the USB device. (6) Create and display a warning dialog box. If basic mode is selected, skip to (8). (7) Receive a response from the user. (8) Update connection information. (9) Bind the driver to the selected interface.

The security analysis is explained as follows.

The USB device authentication system for mobile devices according to this embodiment evaluated the security of USB Eye using Rubber Ducky. The security policies set for four types of USB devices for performance evaluation are as follows.

(Table 1)

Table 1 shows an example of a security policy that defines the allowed interfaces for each device.

The security policy consists of values corresponding to the standard USB protocol descriptor, bInterfaceClass, bInterface-SubClass, and bInterfaceProtocol, which can be referenced to distinguish an interface from other interfaces. An asterisk in Table 1 indicates that all subtypes are allowed (wildcard). The security policy for each type of device allows only the minimum required interfaces.

Additionally, this policy allows interface:HID_None_None for all types of USB devices. As mentioned earlier in the AI introduction effect, this type of interface must be confirmed after binding the corresponding device driver. Any interface not defined in the security policy is considered malicious. For example, USBEye inferred the type of Rubber Ducky as a USB storage device, but the interface requested by the device is a keyboard. Therefore, the interface requested by Rubber Ducky violates the policy. Therefore, the device is malicious.

As a result, depending on the mode selected, USBEye either refuses to connect to Rubber Ducky or pops up a dialog box forwarding all interfaces with a warning message. Users can check for suspicious interfaces and block them.

(Table 2)

Table 2 shows common USB devices used in security analysis.

We also tested the verification of HID events handled by the HID generic driver. Rubber Ducky can bind to the desired driver by manipulating the VID and PID through firmware modification. As seen in the USB device descriptor, VID and PID are important information that determines which driver to bind. To emulate a malicious headset that injects keystrokes using an interface bound to the HID generic driver, we change the VID and PID of the Rubber Ducky firmware so that the interface binds to the generic driver.

Additionally, in this embodiment, the type (i.e., storage space) inferred from Darknet is ignored and the USB type is forcibly set to headset. As a result, the HID core's verification code successfully detected the attack. Keystroke events from USB headsets were blocked.

Experiments were also performed on non-malicious USB devices in Table 2. The device connected seamlessly to the host in native mode because it only defined common interfaces that satisfied the security policy. In strict mode, we confirmed that all interfaces were displayed normally in pop-up windows by comparing them with the lsusb results. The audio control interface defines some sub-functions (i.e. wTerminalType), such as microphone, that can be abused by malicious USB devices even if they have USB Eye. We describe this attack surface in more detail below.

The performance evaluation of the USB device authentication system for mobile devices according to this embodiment will be described as follows.

USB device connection. Opening a pop-up window incurs overhead due to running the NDK binary, running the Android service, and creating and displaying the pop-up message. Measures the elapsed time from the time the USB device is plugged in until the connection is complete. If the user response time fluctuates and it is difficult to measure the value reliably, it is not included in the measurement time. Figure 4 illustrates the analysis of USB device connection time. The x-axis describes each connection procedure. The y-axis represents the average waiting time of 100 runs of USBEye. The time to run the Android service by calling the 'am startservice' command accounted for most of the overhead (Figure 4). Although an overhead close to 100% was observed, it does not significantly reduce usability because it only occurs once when a USB device is plugged in.

In Figure 4, USB connection overhead. Each number on the x-axis represents: (1) The USB device authentication system of the mobile device according to this embodiment initializes variables. (2) Update device information with USBEye driver. (3) Call call_usermodehelper to run the NDK for Android service execution. (4) Start the Android service by calling the Activity Manager (am) command. (5) Obtain information from the USB Eye driver. (6) Check the USB device. (7) Check the selected mode. (8) Create and display a warning dialog box. (9) Send connection information. (10) Connection information is received from the USBEye driver. (11) Terminate the Android service process. (12) Driver binding for the selected interface. (13) Initialize variables.

(Table 3)

Table 3 shows USB device connection overhead.

(Table 4)

Table 4 shows USB device runtime overhead.

USB HID device. Events generated by interfaces bound to the HID generic driver are verified and processed in USBEye (Section 5.5). The time taken from HID event creation to event processing was measured. Table 4 describes the 1000x average latency of keyboard input and mouse input events for baseline and USBEye. The overhead was reasonably small. Up to 2% overhead was observed when handling mouse click events.

(Table 5)

Table 5 shows CPU usage as a percentage (%) of non-idle CPU time. CPU load is measured with the Linux uptime utility.

(Table 6)

Table 6 shows Darknet training time. As a result of training, a weight file defining parameters for classifying USB devices is created.

CPU usage and load. We averaged 10 hours of CPU usage (time running tasks on that CPU) and CPU load (how many processes are using the CPU or are in a queue ready to use the CPU) for both the proposed design and polling-based. was measured for. Design (polling-based design). CPU usage represents the percentage of non-idle CPU time. To measure CPU load, we used the Linux Uptime utility, which calculates average load at 1-, 5-, and 15-minute intervals.

Here, the idle time ratio is measured as follows: (idle*100) / (user + nice + system + idle + iowait + irq + softirq + steal + guest + guest_nice), each item is searched in the /proc/stat file.

In particular, loads measured at 15-minute intervals were used. In this example, we observed that the polling-based design causes an overhead of 3% and 6% in CPU usage and load, respectively, compared to USB Eye, as shown in Table 5. This is because the polling-based design runs an additional background service to periodically check for USB connectivity.

The Darknet Model Training Time is explained as follows.

USBEye's current design requires an administrator to train a CNN model and distribute a quantification file containing the trained model to each user. However, individual users can also perform training. Additionally, federated learning can be adopted to manage models on individual mobile devices, taking into account each user's privacy. Therefore, we measured the training time for Darknet on both desktop and mobile devices. USB device types were trained using a desktop equipped with an Intel Core i7-9700kf CPU and 16GB DDR4 RAM memory.

For training on mobile devices, the Juno board described above was used. In both cases, GPU was not used for training by setting GPU=0 in Darknet's Makefile. The results are shown in Table 6. The training time is 178 seconds on the desktop, but 1184 seconds (6.7x) on the Juno board. This example measures the initial training time, where training a model directly on an edge device is extremely rare except in extreme scenarios such as network outage. Even if federated learning is adopted, the edge device adjusts the model parameters and the initial model is still distributed by the central server (manager).

Discussing the USB device authentication system for mobile devices according to an embodiment of the present invention, it is an extension for the desktop environment. This embodiment is expected to allow USBEye to be easily expanded to PC and desktop environments with minimal engineering effort.

For example, you could implement a user daemon to manage pop-up windows instead of an Android service. Additionally, a user application that takes pictures of a USB device and runs a neural network to classify the images could be implemented similarly to the helper_app.

Additionally, if the target host runs a Linux OS, the kernel components can be adopted without further changes.

Accuracy of filtering interface. Administrators should set security policies in the most conservative manner. Unfortunately, this can result in interfaces being blocked even if the manufacturer legally defines the interface. Misclassifying device images can result in legitimate interfaces being blocked. When dealing with new devices that look different from typical USB devices, the accuracy of classification may decrease. For example, USB devices can be reduced in size to increase portability, or some devices can have unique shapes for ergonomic design.

Additionally, some devices have different interfaces, usually built into a specific type of device (e.g., a USB smart controller with mouse, keyboard, and touchpad interfaces).

Regardless of the reason for blocking the interface, USB Eye's current design can handle these troublesome events by putting USB Eye into strict mode, which allows the user to selectively enable the interface. Increasing the accuracy of AI models is an orthogonal problem, and the efficiency of USBEye is expected to increase through the adoption of high-accuracy AI models and intensive training.

Privacy. In addition to the accuracy of neural networks, privacy issues in AI systems are also inherited by USBEye. For example, to improve USBEye's image classification accuracy, users must send images of new devices to the administrator. Although this is not potentially malicious or malicious, it can create privacy issues that expose each user's device to curious administrators. To solve this problem, you can consider adopting federated learning to manage model accuracy while protecting user privacy.

Machine learning for user authentication. Although physical attacks are excluded from the attack model, some physical access-based USB attacks can still be disrupted by hardening USBEye. For example, you could assume that an attacker temporarily has brief physical access to the host device. This is enough time for a malicious USB device to be connected without notifying the owner of the host device. To defeat this attack, a neural network can be trained to distinguish the owner of the host device from others. Exploring how to integrate AI-based user authentication into USBEye is set aside for future work.

Granular monitoring. Currently USBEye is limited to performing coarse filtering of interfaces. Therefore, an attacker abusing a sub-function of the legitimate interface can bypass USBEye without disguising the USB protocol. For example, the microphone defined in the audio control interface could be covertly activated by a compromised USB headset without the user's intention.

Granular monitoring that can distinguish the origin of device events between users and compromised devices is expected to solve the problem. You can also explore efficient ways to harden device drivers provided by various manufacturers to enable monitoring.

The USB protocol blindly trusts the device, allowing peripherals to be used immediately without any additional setup by the user. This has resulted in software vulnerability attacks that exploit vulnerabilities in the USB core or USB driver, impersonation attacks that perform malicious actions through hidden interfaces, and social engineering attacks that exploit human trust to connect malicious USB devices. To prevent such attacks, various defense techniques are being researched in academia along with the development of various hardware or software tools, but they require additional hardware and cost, making them less practical.

It also relies on whitelists, which are easy to bypass by manipulating USB device firmware, but difficult to maintain with new USB devices constantly appearing. The closest thing to USBEye is GoodUSB, which pops up a list of interfaces for USB devices and allows users to selectively enable interfaces instead of maintaining a whitelist. In contrast, USBEye employs neural networks for image classification to automate security verification and decision-making for USB device connections. By doing so, it minimizes the side effects of frequent security alerts.

or security training to recognize the risks of social engineering attacks, Windows security settings to prevent abuse of the AutoRun feature, Applocker to prevent unauthorized software execution, virus scanners, and malware hidden inside USB devices to mitigate social engineering attacks. It is proposed to detect . USB driver fuzzing and USB driver isolation techniques were explored to prevent attacks exploiting software vulnerabilities. These defenses complement USBEye to defend against more complex USB attacks that combine multiple attack techniques from the various attack categories previously mentioned.

Figure 5 is a block diagram showing the configuration of a USB device authentication system for a mobile device according to an embodiment of the present invention. As shown in FIG. 5, the USB device authentication system 10 of the mobile device includes a determination unit 110, an interface unit 120, and a control unit 130.

The determination unit 110 determines the type of USB device based on artificial intelligence. This judgment unit judges the appearance of the USB device based on artificial intelligence.

The interface unit 120 determines whether the interface of the USB device requested by the operating system kernel for each USB device type is activated according to the result of the determination unit.

The interface unit 120 controls allowable USB device operations based on the determined device type. For example, in the case of USB storage, keyboard input/output operations cannot be performed.

This interface unit further includes a selection module 121 for selecting an artificial intelligence-based or user-based policy setting method according to the security level required for each USB device type.

The control unit 130 is configured to determine the safety of the current connection depending on whether the interface of the interface unit 120 is activated.

If the control unit 130 according to this embodiment determines that the device is not malicious, it loads drivers corresponding to all interfaces. Additionally, the control unit runs strict mode, which pops up all interfaces whenever a USB device is connected to the host. At this time, in strict mode, an interface list is displayed so that the user can selectively activate part of the interface.

According to the present invention, it is possible to prevent USB spoofing attacks, which are attacks that deceive users into performing tasks different from the appearance of the USB device. It can defend against attacks where USB storage performs keystrokes, such as Rubber Ducky, a known USB attack tool.

According to this embodiment, whether to activate the interface of the USB device requested in the operating system kernel is controlled based on the result of determining the USB device type (type) based on artificial intelligence. Additionally, it may further include a function to select an artificial intelligence-based or user-based policy setting method depending on the required security level.

Figure 6 is a schematic flowchart showing a USB device authentication method for a mobile device according to an embodiment of the present invention. As shown in Figure 6, in the method using the USB device authentication system of the mobile device, the USB device authentication system of the mobile device determines the type of USB device based on artificial intelligence (S2).

Next, the USB device authentication system of the mobile device checks whether the requested interface of the USB device is activated in the operating system kernel for each USB device type according to the judgment result of (S2) (S4).

In this step S4, the USB device authentication system of the mobile device may further include a step of selecting an artificial intelligence-based or user-based policy setting method according to the security level required for each USB device type through the interface unit.

Next, the USB device authentication system of the mobile device determines the security of the current connection (S6) depending on whether the interface at (S4) is activated.

In step S6, the control unit of the USB device authentication system of the mobile device loads drivers corresponding to all interfaces if it is determined that the device is not malicious. It also enables strict mode, which pops up all interfaces whenever a USB device is connected to the host, and displays a list of interfaces in strict mode so that the user can selectively activate some of the interfaces.

The USB device authentication system for mobile devices according to this embodiment designed USBEye to detect impersonation attacks by checking whether the connected USB device defines an unexpected interface. In particular, the interfaces defined on the USB device are checked against the list of allowed interfaces for the currently connected device defined in the security policy. The type of USB device, which is the key to get the list from the policy, is inferred by a CNN, which is implemented using Darknet and runs as an Android NDK service.

The security evaluation showed that USBEye can detect and block malicious USB devices (e.g. Rubber Ducky) that perform masquerading attacks by generating malicious keyboard events. In the performance evaluation, we observed an overhead of 101% when connecting USB devices and 2% when operating HID devices. In the future, federated learning can be introduced to classify privacy USB types. We also explore AI-assisted authentication methods that distinguish device owners from other owners. This prevents malicious USB devices from bypassing USBEye by potential attackers who may gain short-term physical access to the victim's device.

Claims (6)

A judgment unit that determines the type of USB device,
an interface unit that checks whether the interface of the USB device requested by the operating system kernel for each USB device type is activated according to the result of the determination unit;
A USB device authentication system for a mobile device, comprising a control unit that determines the safety of the current connection depending on whether the interface is activated. According to paragraph 1,
The interface unit further includes a selection module for selecting an artificial intelligence-based or user-based policy setting method according to the security level required for each USB device type. According to paragraph 1,
A USB device authentication system for a mobile device, wherein the control unit loads drivers corresponding to all interfaces when it is determined that the device is not malicious. According to paragraph 1,
The control unit is a USB device authentication system for a mobile device, wherein the control unit executes a strict mode that pops up all interfaces whenever the USB device is connected to the host. According to paragraph 4,
The USB device authentication system for a mobile device, wherein the control unit displays a list of interfaces so that a user can selectively activate part of the interface in the strict mode. In a method using the USB device authentication system of a mobile device,
(a) the USB device authentication system determining the type of USB device,
(b) the USB device authentication system confirming whether the interface of the USB device requested in the operating system kernel for each USB device type is activated according to the determination result in (a); and
(c) a USB device authentication method for a mobile device, comprising the step of the USB device authentication system determining the security of the current connection depending on whether the interface is activated.