Keywords

1 Introduction

The Universal Serial Bus (USB) is an industry standard proposed in the mid-1990s that provides ubiquitous plug-and-play connectivity for computer peripherals. Although it makes the use of computer peripherals more convenient, it brings many security issues. USB-related attacks have been transformed from the traditional use of USB storages as carriers for the spread of Trojan viruses to exploiting the vulnerability of the USB protocol, which lacks authentication mechanisms. Traditional USB antivirus software is not effective against such attack type.

Considering that the information declared by the USB device is not reliable and adding an authentication mechanism requires to modify the USB communication process, USB communication filtering is an excellent approach to limit the behaviours of USB devices to access the host. However, there is currently no flexible, formalised, and extensible USB filtering policy, which makes current USB filtering lacks versatility. Additionally, the vast majority of those filters target USB Request Block (URB) packets and are implemented at the operating system (OS) level [9], leaving a part of the OS and the firmware of USB host controllers [2] unprotected.

In this paper, we not only explore the differences between filtering USB communication at the OS level (URB) and filtering directly at the USB packet transmission level, but also formalise the universal USB devices filtering policies and propose a simulation framework to evaluate them for the early research stage. The remainder of this paper is organized as follows: Sect. 2 presents the USB security issues and the motivation for proposing universal, formalized USB filtering policies and simulating the filtering on USB packet; Sect. 3 proposes the definition and the formalization of USB packet filtering policies; Sect. 4 shows the architecture of the USB packet filtering simulation framework, explains the filtering process and analyses the result of experimentation; and finally Sect. 5 concludes the paper and outlines the future work.

2 Background and Motivation

2.1 USB Security Issues

USB has been developed and improved for more than 20 years since its introduction. In the beginning, attackers used USB devices as carriers of attacks. However, in recent years, more and more attackers have focused their attacks on the USB protocol itself which lacks an effective authentication mechanism. There exists no uniform unalterable identifier for a USB device and the host passively believes the information declared by USB devices. An attacker can exploit this vulnerability by using some specialised hardware, such as Rubber Ducky, or by reprogramming the USB firmware [7] to deceive the trust of the host and gain control over the host. Since the attack occurs on the firmware of the USB device where we cannot detect, it becomes one of the USB-related attack types which are the most difficult to defend currently.

Besides, the earlier versions of USB protocol specification, such as USB specification version 2.0, use the broadcast mode to send USB packet from the host to USB devices. Under normal circumstances, when there is a broadcast packet from the host, only the destination USB device will respond, and other USB devices will discard the packet. However, this communication feature is exploited by attackers to conduct eavesdropping attacks.

2.2 Motivation of Proposing Universal Formalized Flexible USB Filtering Policies

Although the kind of USB attacks has continued to increase, fortunately more defence mechanisms against USB attacks have been proposed in recent years, such as USB communication filtering [4, 5, 10].

USB communication filtering is a USB defence mechanism that implements USB access control through the verification of the USB device information and restriction of the functions or behaviours of the USB device. At present, there is no research proposition for a universal formalised extended USB communication filtering policy which can promote the development of USB communication filtering research.

Considering the USB communication filtering policies from the top-view can involve less implementing technology making the policies more versatile. Besides, formalising filtering policies not only makes them easier to understand and express but also more conducive to improve their interactivity and reusability. This can save a lot of time and labour costs for practical applications. What’s more, with the development of USB communication technology, USB has gradually replaced the traditional COM and PS/2 communication methods between personal computers and peripherals. Different kinds of USB devices have different functions and behaviours, which causes the varied of functional limitations and behaviour filterings. In order to adapt to this diversity, USB communication filtering policies must be flexible.

2.3 Motivation of Filtering USB Packets

USB communication filtering can be applied to different layers of the USB communication system. Figure 1 illustrates USB architecture. A Universal Serial Bus (USB) client driver cannot communicate with its device directly. Instead, the client driver creates requests and submits them to the USB driver stack for processing. Within each I/O request, the client driver provides a variable-length data structure called a USB Request Block (URB) [6], and sends it to the USB host controller driver via the USB core. Finally, a URB packet will be processed to USB packets which is the smallest logical transfer units of USB communication and be sent to the USB device. When a USB device sends information to a host, the process is the opposite of the above. When packets arrive at the host, the USB host controller will only extract the payloads of the packets to generate a URB packet according to the request information type.

Fig. 1.
figure 1

USB architecture

Full size image
Fig. 2.
figure 2

Filtering module

Full size image

Although both USB packet filtering and URB filtering can filter the USB communication, there are still many differences between them. These differences are mainly reflected in three aspects: the difficulty of implementation, the universality and the scope of protection. The implementation of USB packet filtering can be independent of the host and USB devices. URB filtering requires different implementations depending on the type and version of the system, which makes it less universal than USB packet filtering. Although implementing USB packet filtering requires some specific hardware, it can filter USB packets sent by USB devices before they reach the host. URB filtering filters URBs generated by the USB host controller after processing USB packets. It may let the original harmful information entering the OS system and cause a potential threat. That is the reason for applying our filtering policies on USB packet.

3 Filtering Policy Definition

3.1 Filtering Requirement

The approach proposed in this paper uses USB packet filtering to achieve a more flexible lock mechanism for USB communication. Authenticating USB devices (based on manufacturer ID and product ID) and verifying their declared functionalities is the first step. It cannot ultimately defend against USB attacks, such as badUSB. Further filtering of the functionalities of the USB device is necessary.

According to the USB protocol [11], USB communication can be divided into two steps: enumeration process and functional communication. In the enumeration process, the host requests the basic information of the USB device and assigns the address to it. When the enumeration process is completed, the functions of the USB device can be used, which is also called functional communication. The context covers both of them as shown in Fig. 2. According to the actual situations, the following four kinds of USB packet filtering policies are proposed:

  • Type 1: Filtering policies solely based on time. Such policies allow or disallow USB communications by the current time. If the access condition disallows USB communications, every USB packets are simply dropped without any processing. For example, such policies can be used to disallow USB connections outside of office hours.

  • Type 2: Filtering policies based on time and device class. Such policies allow or disallow the use of specific USB device types by the current time and device class. In addition to the current time, the packets exchanged during the enumeration phase must be parsed in order to decide if the connection of this specific device class is allowed or not. Once a decision has been taken for a device, later USB packets from or to this device can be dropped without any further processing.

  • Type 3: Filtering policies based on device authentication. Such policies authenticate devices by different information provided during the enumeration phase (such as product ID and vendor ID). After the enumeration phase, packets coming from unauthenticated devices are dropped. Now more and more enterprises are aware of the importance of USB security. They require employees to use unified USB devices which are purchased by the enterprise. This policy can be used to achieve a similar effect. Furthermore, automatic mechanisms enforcing such policies are more reliable than the employee’s consciousness.

  • Type 4: Filtering policies based on device functionalities. Such policies map USB packets to device functionalities and drop every packet related to a functionality that is not authorised. As explained earlier, a USB device can have multiple interfaces, which means it can have multiple functions. However, sometimes we do not need all of them. In this case, the functions can be selected by the policy, and reduce potential risks.

3.2 Filtering Policy Formulation

Those policies are formalised below in order to clarify them and make them easier to understand. Each USB device has many properties, such as vendor ID, product ID, device class, and so on. The same type of USB device may have different usage restrictions according to different properties. Whereas Attribute-Based Access Control (ABAC) [3], based on attributes which can be about anything and anyone, takes more broad parameters into account. It is the most suitable model thanks to its flexibility and relatively fine-grained feature.

ABAC can define permissions based on any security-relevant characteristics, known as attributes [12]. For our filtering policies, we are concerned with three types of attributes:

  • Subject Attribute. A subject is an entity that can apply an action to an object. Each subject has some attributes that define the identity and characteristics of the subject. In our case, a subject is a USB device and its associated attributes can be the information which is stored in the descriptors, such as Vendor ID, Product ID, USB class code and so on.

  • Action Attribute. In this paper, action refers to a function of the USB device. One of the action attributes should be the endpoint which can identify one of the functions of the USB device as well as the transfer type and direction. Because the endpoint information is in the firmware of USB device, it is hard to get it before the enumeration process. We will use a dynamic table to express this endpoint attribute and complete the dynamic table during the enumeration process.

  • Context Attribute. Context attributes refer to the operational, technical, and even situation when access occurs. For USB packet filtering policies, we only consider time as context. The context attributes can be a date, week or time.

Filtering policy rules can be formalized by ABAC model as follows:

  1. 1.

    S, A and C are respectively the sets of subjects, actions and contexts.

  2. 2.

    \(S_{att_i}\) (\(1 \leqslant i \leqslant I\)), \(A_{att_j}\) (\(1 \leqslant j \leqslant J\)) and \(C_{att_k}\) (\(1 \leqslant k \leqslant K\)) are respectively the pre-defined subjects attributes, actions attributes and contexts attributes where I, J and K are respectively the number of pre-defined subjects attributes, actions attributes and contexts attributes.

  3. 3.

    Function notation is used to assign the value for individual attributes. Different types of attribute values, atomic elements in USB packet filtering policies can be divided into two types: categorical element and numerical element. For categorical element, the operator “=” is used for the string type attribute value. For numerical element, the operators “=”, “<”, “>”, “\(\leqslant \)”, “\(\geqslant \)” are used for the integer, real, date/time data types attribute values. The combination operators such as “\(\bigwedge \)”, “\(\bigvee \)” and “\(\lnot \)”, can be used when an attribute has many values. For example, vender ID = “Logitech” and (\(9:00 \leqslant Time \leqslant 12:00\)) \(\bigvee \) (\(14:00 \leqslant Time \leqslant 18:00\)).

  4. 4.

    ATTR(s), ATTR(a), ATTR(c) are respectively the set of attributes which belong to the subject (s), action (a), context (c) in one filter policy. If all the pre-defined attributes of subjects expressed as \(\left\{ S_{att_1}, S_{att_2}, \ldots , S_{att_I}\right\} \), then \(ATTR (s) \subseteq \left\{ S_{att_1},\right. \) \(\left. S_{att_2}, \ldots , S_{att_I}\right\} \). ATTR(a) and ATTR(c) have the same relationship as ATTR(s).

  5. 5.

    In the filtering policy form, a policy that decides on whether permitting a USB device s can access the host with an action a in a particular context c, is a function of s, a, and c’s attributes:

    Policy: is\(\_\)permitted (s, a, c) \(\leftarrow \) f (\(ATTR (s )\), \(ATTR (a )\), \(ATTR (c )\))

    If the result of the function which evaluates all the attributes of s, a, and c is true, then the USB device is permitted to access the host with the action a; otherwise the access will be denied.

4 Simulation Framework

4.1 Architecture

As far as we know, no software can directly capture USB packets without the help of specific hardware. In addition, the known USB packet capture hardware does not support modifying the content of USB packets. Therefore, how to simulate different USB communication cases to test the proposed packet filtering policies in the early stages of the research is an important issue. For this, a low-cost USB communication simulation framework is implemented.

Fig. 3.
figure 3

Simulation framework architecture

Full size image

Ellisys USB Explorer [1] is a USB protocol analyser hardware which can monitor and capture real USB communication packets. We use the structure of its export format in the simulation framework. A simple USB communication amounts to thousands of USB packets. Using Ellisys USB Explorer can get real USB packets more efficiently and export them in files. We can build different test cases easier by modifying the packet contents in the files. According to the user requirements, filtering policies are created by using the EXtensible Access Control Markup Language (XACML) [8] standard, which is a standard of declarative fine-grained, ABAC policy language.

Figure 3 shows the architecture of the simulation framework. The parser is in charge of analysing the USB packets file and classifying the packets according to their source (from host or device). The multi-threaded features of the Java language is used to simulate the communication between the host and USB devices. The filter module is responsible for parsing and enforcing the filtering rules. The module can be improved or updated according to the filtering policies.

4.2 Filtering Process

Figure 2 illustrates the most important components of the filtering module. Policy Administration Point (PAP) is responsible for parsing the file storing the filtering policies. According to the attributes in the policies, the PAP sends a request to the Policy Information Point (PIP) to get the real attribute value which will be used during the filtering process. For instance, the vendor id attribute value in the policy is “Kingston” which is the brand name known by the user. However, in the real USB communication, the USB device only sends the code (0x0951) of the brand instead of the name. We can get this information from the USB Implementers Forum (USB-IF) website. After getting the values from the PIP, the policy will be sent to the Policy Enforcement and Decision Point (PEP&PDP) to be enforced for filtering the USB packets. It is noteworthy that in general we do not know the internal structure of the USB device before the filtering. In other words, when setting up a filtering policy, we only know which functionality of the USB device should be limited, but we do not know what kind of value should be filtered. This kind of information can be collected from the enumeration process which occurs before starting the functional communication stage during the USB communication. This is the most significant difference from the traditional packet filtering firewall. This is a dynamic acquisition process which is shown by the imaginary line from the PEP&PDP to PAP.

The upstream filtering process is shown in Fig. 4. When an upstream (from a USB device to a host) USB packet arrives, it will be filtered by the rules of Type 1 filtering policy. If there are no rules or the result of matching the rules is permitted, it goes to the communication stage. In the enumeration process, the data of a USB packet will be extracted. This process contains many USB protocol information and technical skills. The specific process will be shown together with the upstream and downstream filtering algorithms in our low-cost simulation framework for USB packet filtering the technical report. After matching rules of Type 2 policy, the filter will forward or drop the packet according to the matching result. If the packet is in the functional communication, the rules of Type 3 and Type 4 will be matched in sequence as shown in Fig. 4.

Fig. 4.
figure 4

Upstream filtering process

Full size image

As we described in USB security issues, host broadcast downstream USB packets may be at risk of eavesdropping. To reduce this kind of risk, the downstream USB packet filtering is involved in the filtering process. In the downstream USB packet filtering, the packets from the host are filtered according to the destination. If the destination is one of the downstream USB devices of the filter, the packet will be forwarded, otherwise it will be dropped, as illustrated in Fig. 5. No additional filtering policy is required in this process.

Fig. 5.
figure 5

Downstream filtering process

Full size image

4.3 Experimental Result

We implement and deploy the USB communication simulation framework using Java on Eclipse platform with JDK 1.8 installed on the computer with Windows 10 64-bit OS, Intel Core i5-7200u cup and 8G memory.

In order to compare the efficiency of various filtering policies and the impact of increased filtering rules on filtering time, we simulate the change in filter processing time with linearly increasing filter rules for each type of filtering policies mentioned in Sect. 3.1. Different from traditional network packet-filter firewalls, the protected object of USB packet filtering is a personal computer rather than a private network area. The number of rules required for USB packet filtering is much less than the number of rules for network packet filtering. Therefore, for each type of filtering policies, we increment each group of filter rules by 5 until 25. Since the time for filtering a single packet is too short to be measured accurately, we use the Ellisys hardware to capture the packets in a period of USB communication with a USB device as the basis of the experiment. In our experiment, we choose the first 10000 packets of the communication between the host and the USB device, which contain the enumeration process and functional communication, as the object to filter. The experimental result is presented in Table 1.

Table 1. Process time for each type of filtering policy
Full size table

The table shows the filtering process time (millisecond) of each type of filtering policies by a different number of rules. For each type of filtering policy, we can find that as the number of filtering rules increases, the process time of filtering also increases linearly. When there are fewer filtering rules, the filtering efficiency will be higher and the USB communication delay will be less.

After longitudinal comparison, the Type 1 filtering policy has the highest cost of time for filtering processing under the same conditions, because it needs to filter every packet from a USB device. Although high processing time means more communication delay, it can completely prevent USB devices from accessing hosts during unauthorised periods, thereby maximising host security. Type  2 filtering policy requires the least time because it only happens during the enumeration process. In each enumeration process, the attributes in the Type 2 policy only need to be verified once. Type 3 and Type 4 filtering policies occur during the functional communication of USB communication. Each time a USB device sends functional data to a host, they will be executed. This is the reason why their filtering process time is close.

Through the experimental results, the efficiency of different types of filtering policy can be observed. It can help technicians to optimise filtering rules better: use more efficient filtering rules to achieve the same filtering effect.

5 Conclusion and Future Work

In this paper, we introduced the attacks that exploit the vulnerabilities of USB and presented the advantages of USB packet filtering compared to URB filtering. We then proposed the universal formalised flexible USB packet filtering policies which leave good scalability for future filtering of contents of USB functional communication packet, and a low-cost USB communication simulation framework for their early stage of conception and evaluation. The USB packet filtering approach can make up for the deficiencies of traditional anti-virus software, and give the operating system more comprehensive protection. The USB communication data can be verified before they enter the operating system to expand the scope of protection and minimise the risk of being attacked. Our simulation framework offers a handy, easy-operation means to evaluate the concept of filtering policies.

In the future, we will continue our research work in three areas. First, we will continue to improve our simulation to adapt to more complex USB communication. Besides, we will design USB packet filtering policies to filter the contents of the USB packet in the functional communication stage of different USB devices. Last but not least, after improving and evaluating the USB packet filtering policies, implementation in real communication environment will be necessary. We will try to implement our filtering on special hardware such as the Raspberry Pi.