WO2017021687A1

WO2017021687A1 - Security device for securely connecting peripheral bus devices

Info

Publication number: WO2017021687A1
Application number: PCT/GB2016/052217
Authority: WO
Inventors: Peter Burgers; Richard Jonathan Petrie
Original assignee: Displaylink (Uk) Limited
Priority date: 2015-08-04
Filing date: 2016-07-21
Publication date: 2017-02-09
Also published as: GB2541000A; GB2541000B; GB201513811D0

Abstract

A security device is disclosed for securely connecting peripheral bus devices, wherein peripheral bus devices are host and/or client devices arranged to communicate via a peripheral bus. The security device comprises connection means for connecting to one or more peripheral bus devices; and authentication means configured, in response to connection of a first peripheral bus device to the security device, to authenticate the first peripheral bus device to determine whether access by the first peripheral bus device is permitted. The device further includes communication means for enabling communication between the first peripheral bus device and one or more further peripheral bus devices in response to successful authentication of the first peripheral bus device.

Description

SECURITY DEVICE FOR SECURELY CONNECTING PERIPHERAL BUS DEVICES

Background

As computing devices become more ubiquitous, it is becoming increasingly common for users to wish to connect various peripherals to them. This can lead to issues of security, as it is possible for malicious software to be contained on a peripheral which may then damage or compromise either a computing device or other devices on the network to which that computing device is connected. It is therefore desirable to provide a method of authentication and security where devices are being connected to one another and to a network.

It is also desirable, especially in a large enterprise setting such as an office block, for different areas to have different levels of privilege such that equipment can be verified, as opposed to only the user being identified and granted access as occurs in conventional systems. The enterprise setting is an example of circumstances under which it is also useful for access to be centrally managed, such that all access to connected devices and networks can be controlled by an IT manager. This is currently very difficult in conventional systems. The present invention aims to solve or at least mitigate some or all of these problems.

Summary of the Invention

In a first aspect of the invention there is provided a security device for securely connecting peripheral bus devices, wherein peripheral bus devices are (or include) devices (host and/or client devices) arranged to communicate via a peripheral bus, the security device comprising: connection means for connecting to one or more peripheral bus devices; authentication means configured, in response to connection of a first peripheral bus device to the security device, to authenticate the first peripheral bus device to determine whether access by the first peripheral bus device is permitted; and communication means for enabling communication between the first peripheral bus device and one or more further peripheral bus devices (connected to the security device) in response to successful authentication of the first peripheral bus device. For example, the first peripheral bus device may be a client device (e.g. a peripheral such as a hard disk, USB memory stick or other storage device, or a keyboard, mouse or display or other input/output or human-computer interface device, a printer, or the like). The further peripheral bus device with which the first device wishes to communicate may be a host device (e.g. a personal computer to which the peripheral is to be connected). In this way, the security device can act as an intermediary to authenticate the connected devices, and only allow previously authorised devices to access the peripheral bus. The device may be embodied in a standalone device or may be integrated into another device (e.g. as an add-on card). Further aspects of the invention are set out in the independent claims. Certain preferred features are set out in the dependent claims. Method and computer program product aspects corresponding to each of the defined device aspects may also be provided.

Embodiments of the invention provide a security device, also referred to herein as a "network control unit", which acts as an authentication proxy, handling all connections to devices and networks, including the internet. The network control unit authenticates each individual link to each peripheral and any host device such as a PC, smartphone, tablet computer, or other computing device. Furthermore, the network control unit indicates to any requestor, such as a network server, that all devices connected to the network control unit are bona fide and have been authenticated. This allows free communication through the network control unit as if all components were in a secure room, as unauthorised devices cannot connect to the network control unit. No further authentication is necessary once a device of any sort has been authenticated by the network control unit.

Despite the name, the network control unit may in fact not connect to a network as conventionally understood but instead create a local network comprising itself and devices connected directly to itself. It will still operate in the same way with regard to authentication of those devices.

This is especially beneficial where there is concern about the connection of peripherals which may contain malicious software, as the network control unit is able to ensure that computing devices and networks connected to it cannot communicate with any unauthorised peripheral or vice versa.

The network control unit preferably holds an internal list (hereinafter called a white list) of the devices permitted to connect to it and thus to other devices and the network. This is preferable because it allows access to be controlled on a per-unit basis, which is especially beneficial in an enterprise environment where it may be desirable to segment an office and allow different levels of access in different areas. In addition, this will minimise network traffic which might otherwise become excessive in a large network where every peripheral was authenticated upon connection. Alternatively, the white list may be stored on a central server known as an authentication server and accessed via the network. This is beneficial as it will ensure uniformity and allow for changes in one place to be reflected across the network. In either case, however, it should be possible for the white list to be managed and changed as appropriate by an administrator. The network control unit may also check the encryption capabilities of devices during authentication as well as responding to such checks from suitably-arranged devices. If appropriate, the network control unit then ensures that all data passing along connections on which encryption is enabled is encrypted as appropriate. This may mean:

• 'Bridging', by which encrypted data is received from one encrypted connection and immediately transmitted on down a second identically encrypted connection or unencrypted data is received from one unencrypted connection and immediately transmitted down a second unencrypted connection;

• 'Repeating', by which encrypted data is received from one encrypted connection and the network control unit then decrypts it, re-encrypts it, possibly with a new encryption, and sends it down another encrypted connection;

• 'Decrypting', by which encrypted data is received from an encrypted connection, decrypted, and immediately transmitted down an unencrypted connection; or

• 'Encrypting', by which unencrypted data is received from an unencrypted connection, encrypted, and immediately transmitted down an encrypted connection.

Whereas authentication ensures that all devices connected to the network control unit are bona fide by checking credentials provided by the devices and may be used to generate a key for encryption, encryption protects the data carried by each connection.

Connections between the network control device and any computing device, peripheral, or network may be wired or wireless, and may be over a network, including the internet.

Brief Description of the Drawings

Figure 1 is an example of the system as a whole, showing a network control unit connected to devices and a network.

Figure 2 shows a second example, in which the white list is contained on the network rather than the network control unit. Figure 3 shows an example schematic of a network control unit which supports encryption.

Figure 4 shows an example schematic of a network control unit which does not support encryption.

5 Figure 5 shows the process of connection and authentication between a network control unit and a device.

Figure 6 shows the additional process followed where encryption may be used.

Figure 7 shows the process followed in processing a packet of data where encryption may be used. l o Detailed Description of the Drawings

Figure 1 shows an example of the system, comprising a network control unit (NCU) [14] connected to a computing device [11], a collection of peripheral devices [12], and a network [13]. The peripherals [12] are shown as a unit for clarity, but will all be connected separately to the NCU [14] and each one will have been separately authenticated upon connection. The 15 computing device [11] and the peripherals [12] are collectively known as peripheral bus devices, or simply devices. The NCU [14] acts as an intermediary on a peripheral bus (in a preferred embodiment a Universal Serial Bus, USB) and is able to exchange data in both directions with all devices [11, 12] and also with the network [13].

The NCU [14] also contains a white list [15] and a list of connected devices [16]. In this 0 example, the white list [15] also contains classifications for each device, which may act as privilege levels. For example, devices with classification T may be able to access the network [13] while devices with classification '2' are only able to access other devices connected to the same NCU [14]. Privilege types or levels may also be applied with respect to, for example, bandwidth limits, encryption requirements, and other limitations or 5 requirements for quality of use and security. The white list [15] and its contents may be amended by an IT or network administrator or controller (e.g. remotely via network [13]).

The list of connected devices [16] allows confirmation, for example across the network [13], of the devices [11, 12] that have been authenticated by that NCU [14]. These devices [11, 12] are guaranteed to be bona fide and safe for use. In this example, device 1A2B may 30 be the computing device [11], device XYZ may be the display device, device 11235 may be the mouse and device 81321 may be the keyboard. As can be seen, all devices [11, 12] connected to the NCU [14] must be authenticated and placed in this list [16] before they can be used. The list of connected devices [16] may also be extended to contain other information about the devices [11, 12], such as time and date of connection, type, classification, etc.

In a preferred embodiment, the computing device [11] is a USB host device, e.g. a personal computer, and the devices [12] are USB peripheral devices, with devices [11, 12] connected to the NCU [14] via USB connections. However, any appropriate peripheral bus or other connection technology may be substituted (including wired or wireless solutions, e.g. Thunderbolt, IEEE1394, Wi-Fi/Wi-Fi Direct, Bluetooth etc.). The NCU may also support multiple connection technologies at the same time. Figure 2 shows a second example embodiment of the system in which the white list [27] is contained on a central authentication server [25] on the network [23]. In this example, there are no privilege or priority levels connected to devices (though this feature could additionally be provided) and the white list [27] serves only as a list of devices that are permitted to connect to all NCUs on the network [13] - in Figure 2 only one such NCU [24] is shown, but in practice there are likely to be many, especially in a large enterprise network. A single white list may be provided for all NCUs, or separate white lists may be maintained for different NCUs as needed.

As in Figure 1, the NCU [24] is connected to a computing device [21] and a collection of peripherals [22], which are once again shown as a single unit for clarity. It is also connected to the network [23], to which the authentication server [25] is also connected. The NCU [24] is able to exchange data in both directions with all connected devices [21, 22], and also with the network [23], and the authentication server [25] is able to both send and receive data to and from the network [23].

As in Figure 1, the NCU [24] contains a list of connected devices [26], being the same devices as shown in Figure 1. In this example, however, additional information is attached to each device. In this example the NCU [24] is capable of encryption and may wish to form encrypted connections with devices [21, 22] (note the encryption functionality could also be provided in the Figure 1 embodiment). The list of connected devices [26] therefore shows which devices [21, 22] are also capable of encryption (indicated by a T where they are capable of encryption and a '0' where they are not) and the encryption keys required to communicate with those devices [21, 22]. For example, in Figure 2 the computing device [21] is capable of encryption with key Ά', the display device is capable of encryption with key 'B' and the mouse and keyboard are not capable of encryption. These capabilities are determined as part of the handshaking carried out during authentication.

Figure 3 shows a detail of an example NCU [31] which can be used with either of the above embodiments. As shown in Figures 1 and 2, the NCU [31] is externally connected to a computing device [32], a collection of peripherals [33], and a network [34]. The connections to the computing device [32] and the peripherals [33] are, in this embodiment, handled by a USB hub [34] which includes an upstream port [35] which is connected to the computing device [32] (acting as a USB host device) and a collection of downstream ports [36] which are connected to the peripherals [33] (acting as USB client devices). In the same way as the peripherals [33] are shown as a single unit, the downstream ports [36] are here shown as a single port for clarity. The NCU [31] is connected to the network [34] via a network port [37], which in this example is an Ethernet port. As previously mentioned, any of these connections may be wired or wireless. Connections carrying data that is passing between devices [32, 33, 34] connected to the NCU [31], including the network, are shown as solid arrows; connections carrying authentication data and signals are shown as dotted arrows.

The hub [34] is connected to an authentication engine [39], which has access to the white list [311], which is stored in memory. In this example, the white list [311] is internal to the NCU [31]; in an example such as that shown in Figure 2 where the white list [27] is stored on an authentication server [25] on the network [23], the NCU's [31] authentication engine [39] may be connected directly to the network port [37]. It may also be part of the hub [34]. The authentication engine [39] further has access to the list of connected devices [312] so that it is able to update it when authentication is complete.

In this example, the hub [34] also contains an encryption decision engine [38], which is arranged to determine whether data is encrypted and, if so, which of bridging, repeating, encrypting, and decrypting, as described above, are necessary. It is also connected to the network port [37] and acts as a conduit between the USB ports [35, 36] and the network port [37] and the encryption engine [310], which actually performs encryption and decryption as necessary. If the encryption decision engine [38] determines that the data can be bridged, it is able to pass the data straight to the destination port [35, 36, 37] without passing it through the encryption engine [310].

The encryption decision engine [38] and the encryption engine [310] both have access to the list of connected devices [312], which in this example includes a flag indicating whether the NCU's [31] connection to each device [32, 33] is encrypted (T for yes, '0' for no) and the encryption key for that connection. The encryption decision engine [38] is then able to use this information to determine the correct action for data coming from and going to each connection. Although encryption information is here shown stored in the list of connected devices [312], it may be stored elsewhere, such as in a separate area of memory, in which case the encryption decision engine [38] will be connected to and access this memory as appropriate.

Figure 3 shows an example of an NCU [31] which can handle encryption. Where this is not the case, the encryption decision engine [38] and encryption engine [310] will be omitted and there will be no encryption data in the list of connected devices [312] or anywhere else; an example of this case is shown in Figure 4.

Similarly to Figure 3, the NCU [41] shown in Figure 4 is externally connected to a computing device and a collection of peripherals [collectively 42], and a network [43]. In this example embodiment, there are not distinct upstream [35] and downstream [36] ports as there were in the example shown in Figure 3, although the hubs [34, 44] shown in the two NCUs [31, 41] are not specific to those embodiments; the version using upstream and downstream ports could be used in a case where there was no encryption capability and the version using device ports could be used in a case where there is encryption capability. Since the ports of the hub are identical, the computing and peripheral devices are shown as a single unit [42] connected to a single port [45], although there will, of course, be several ports, each connected to a device.

Also as shown in Figure 3, the NCU [41] contains an authentication engine [47] which is connected to the hub [44], the connection being shown with a dotted arrow because it carries authentication data and signalling. The authentication engine [47] has access to the white list [48], which, as in Figure 3, is contained in memory on the NCU [41], although it could also be stored on the network [43] as shown in Figure 2. The authentication engine [47] further has access to the list of connected devices [49] and is able to update this upon authentication of a device [42].

The list of connected devices [49] is accessible via the network port [46] as this will make it possible for other network devices and interested parties such as an IT manager to check the devices connected to the NCU [41]. This will be especially useful as the white list [48] is stored locally and therefore it might be possible for a user or malicious software to amend it. Furthermore, access to information as to which devices are connected to an NCU will make it easier to perform inventory and locate any device which is acting in a problematic manner, for example by monopolising network bandwidth.

Finally, the network port [46] and the device ports [45] are connected to one another in order to pass data between the network [43] and the devices [42]. Since there is no encryption involvement in this example, there is no encryption decision engine [38] acting as an intermediary.

Figure 5 shows the process of authentication and connection of a device to an NCU [41] such as that shown in Figure 4, which does not have encryption capabilities (or where encryption is not being used).

At Step S51, the device [42] attempts to connect. This attempt may be wired, for example by the user plugging in a cable, or wireless, for example by polling over Wi-Fi or Bluetooth. At this stage a preliminary connection referred to herein as association is formed which allows signalling but no actual data transfer. It serves as a signal to the NCU [41] that there is a device [42] present which is attempting to connect and to the device [42] that there is an NCU [41] present to which it may be able to connect.

At Step S52, the authentication engine [47] contained in the NCU [41] requests appropriate authentication data. This may comprise details as to the identity of the device [42], for example its model, manufacturer, supplier, user, operating system, type (for example, laptop or smartphone), or a unique identifier such as a serial number, this being the example used in the diagrams. Alternatively, the authentication data may require a form of user input such as a password, fingerprint scan, retinal scan, series of gestures, or any similar user authentication method. Additionally, any two or more of such authentication methods may be combined, such that, for example, the NCU [41] may request a device's serial number and also a password input by the user. There may also be different levels of authentication required depending on the type of device. For example, a computing device such as a laptop may have to identify its supplier and also supply a password from the user, while a mouse connected to the same NCU [41] only has to identify its supplier.

At Step S53, the device [42] supplies the requested authentication data. This is received by the hub [44] and passed to the authentication engine [47] which then checks the white list [48] at Step S54 by comparing the authentication data with every entry until it finds a match or reaches the end of the white list [48]. If multiple instances of authentication data are required, these may all be compared individually with multiple instances of stored authentication data, or they may be combined into a single piece of data which is then compared with similarly-generated stored data.

Where the white list is stored on the network [43], it may also contain lists of which NCUs [41] are permitted to connect to specific devices [42] and this will also be checked at this stage. This will be useful for sectioning a large office or limiting access from a home office, such that a device [42] which can be connected to an NCU [41] in one department or within the main office cannot be connected to an NCU [41] elsewhere. If the white list [48] is stored on the NCU [41], as here, it will not be necessary to specify permitted NCUs [41] as the white list [48] can be different per NCU [41].

If there is a match between the supplied authentication data and an entry in the white list [48], the device [42] is allowed to connect and the process follows the branch labelled A: the device [42] connects fully to the NCU [41] at Step S5A1 and all the ports [45, 46] are able to exchange data at Step S5A2. No further authentication will be necessary as the network [43] and all other connected devices [42] are aware that the device has been authenticated and is therefore bona fide and permitted to connect and communicate freely. This is more convenient for the user as it means that no further steps such as password entry will be required to authenticate the device and access data and other devices.

If there is no match, the process follows the branch labelled B and the device [42] is rejected at Step S5B1. This means that it is not allowed to connect to the NCU [41] and the association connection is broken. It is therefore not able to communicate with the network [43] or any other connected device [42].

Figure 6 shows the additional process followed in an NCU [31] such as that shown in Figure 3 where encryption is possible. This part of the process will occur between Steps S54 and S5A1, after it has been determined that the device [32, 33] attempting to connect is present in the white list [311] and therefore authentication is possible.

At Step S61, the NCU [31] and the device [32, 33] exchange encryption capabilities. In an embodiment where the NCU [31] and the device [32, 33] are connecting via the USB protocol, this may require the NCU [31] to temporarily take the role of a host, as if the device [32, 33] were a peripheral connecting to a computing device, regardless of the actual nature of the device [32, 33]. The authentication engine [39] within the NCU [31] will then be able to read the endpoint descriptor associated with the device [32, 33], which will indicate whether the device [32, 33] supports data encryption. The NCU [31] will also signal to the device [32, 33] whether or not it supports data encryption.

An NCU [31] which does not support data encryption may also be used in a process such as this where the device [32, 33] initiates a request to use encryption; at this stage it will always signal that it does not support data encryption and the process will continue accordingly.

If both the NCU [31] and the device [32, 33] support data encryption, the process will follow the branch labelled A and encryption will be enabled on that connection. This does not affect other connections, which will be encrypted or not as appropriate. The NCU [31] and device [32, 33] will then connect and exchange data as hereinbefore described. In the NCU [31] shown in Figure 3, the authentication engine [39] will also query the device [32, 33] for its encryption key and will enter this together with a flag indicating that the connection is encrypted into the list of connected devices [312], as shown in the first two lines of the list of connected devices [312] shown in Figure 3. If only one of the NCU [31] and the device [32, 33] supports data encryption, the process follows the branch labelled B. Encryption will not be possible, but there may be a protocol in place whereby the connection will fail if encryption cannot be used. Accordingly, at Step S6B1, the device which supports encryption determines whether the connection should continue. If, for example, the NCU [31] supports encryption and is part of a secure environment in which all data must be encrypted, if a device [32, 33] which does not support encryption attempts to connect the authentication engine [39] may reject it at this stage even though it appears in the white list [311] and is therefore permitted to connect under most circumstances. This allows for further sectioning of a network such that it may be possible for some areas to require encryption while some do not and they all share a centrally- administered white list such as that shown in Figure 2. Under these circumstances authentication will fail as previously described at Step S5B1.

Similarly, the device may contain data that is only permitted to be sent in an encrypted form. It may therefore automatically end authentication upon receiving a signal from the NCU [31] that it does not support encryption. The authentication stage will therefore fail as described at Step S5B1. If, on the other hand, the NCU [31] or device [32, 33] that supports encryption does not require it, it may have a protocol whereby it is still able to connect on an unencrypted basis. Under these circumstances, authentication will proceed as normal, and the authentication engine [39] will enter an indication in the list of connected devices [312] that the connection is not encrypted. This is useful as it will ensure that connections are encrypted where possible on a connection-by-connection basis, which allows improved efficiency and security as connections can be tailored to circumstances.

If neither the NCU [31] nor the device [32, 33] supports encryption, the connection will proceed as previously described at Step S5A1 and the device [32, 33] will connect to the NCU [31] with an unencrypted connection.

Figure 7 shows the process followed when a packet of data is received by the NCU [31] shown in Figure 3, which supports encryption.

At Step S71, the data is received from one of the devices [32, 33] or the network [34], which for this purpose is treated as a connected device. All these devices are connected, so they have been authenticated and the data is guaranteed to be bona fide and from a known endpoint. It is therefore passed to the encryption decision engine [38].

At Step S72, the encryption decision engine [38] checks whether the packet is encrypted. It might do this by, for example, reading the packet transport header or a similar flag within the packet. Alternately, it might check the list of connected devices [312] or another similar list as previously mentioned and see if the source device is connected via an encrypted connection. If the packet is not encrypted, the process follows the branch labelled A, otherwise it follows the branch labelled B.

At Step S7A1, the packet has been determined not to be encrypted and the encryption decision engine [38] determines the destination device, most likely but not necessarily from the packet transport header. It will then determine whether the connection to the destination device is encrypted, in this example by checking the list of connected devices [312]. If so, the packet will need to be sent in an encrypted form and the process will follow the branch labelled C: an Encryption case as previously defined. If not, the packet can simply be transmitted to the destination device at Step S73 : a Bridging case. If the packet requires encryption, it is passed to the encryption engine [310] at Step S7C1. The encryption engine [310] will then retrieve the encryption key required by the destination device, in this example from the list of connected devices [312], and encrypt the data appropriately prior to transmitting it to the destination device at Step S73.

In the case where the packet was originally encrypted, the process will instead move to Step S7B 1, where, once again, the encryption decision engine [38] will check the entry in the list of connected devices [312] for the destination device. In this case, however, it will also retrieve the key expected by the destination device, if appropriate. It will then compare this with the key used by the source device, which it may be able to determine from the data or may also fetch from the list of connected devices [312], since the source device will also appear in this list. There are then three possibilities: the first is that the destination device requires the same encryption as the source device: a further Bridging case. In this case, the encryption decision engine [38] will transmit the data on to the destination device at Step S73.

The second possibility is that the destination device requires a different encryption to that used by the source device: a Repeating case. Under these circumstances the process will follow the branch labelled D. The third possibility is that the destination device does not require encryption: a Decryption case. The process will then follow the branch labelled E.

In a Repeating case, the branch labelled D, the encryption decision engine [38] will then pass the data to the encryption engine [310], which will decrypt it as appropriate at Step S7D1. It will then immediately re-encrypt it using the destination device's encryption key at Step S7D2, prior to transmitting it to the destination device at Step S73.

In the Decryption case, the branch labelled E, the encryption decision engine [38] will again pass the data to the encryption engine [310], which will simply decrypt it at Step S7E1 prior to transmitting it to the destination device at S73.

This system allows the encryption engine [310] to be used only when necessary, avoiding unnecessary processing with the accompanying delay and power use while still maintaining appropriate encryption and data security. As is the case for authentication, encryption is handled by the network control unit and there is therefore a single point of contact between all devices and all other devices, including the network. This improves both security and convenience. Embodiments of the invention may include any of the following features. A NCU may itself be authenticated with another device (e.g. a central control device or a further NCU in a chained configuration). The NCU can represent a single composite or compound device from the perspective of devices higher in the chain. A single authentication operation may be performed for the entire composite device. Certificates may be chained if desired. The NCU may be able to disable itself if authentication fails, or may be disabled by an external device/controller.

In a USB embodiment, authentication is preferably performed once per USB device in the USB hierarchy. If authentication fails, the entire USB device may be disabled (depending on host/device policy). Authentication preferably operates at the USB device boundary (e.g. USB hosts/peripherals connect directly to the NCU where authentication occurs). Each USB device in the compound is preferably authenticated individually. Each device may disable itself if authentication fails; also the NCU or an external controller may selectively disable individual devices in the compound.

Encryption may be enabled on a per endpoint basis. In a USB embodiment, the authentication may follow the steps of 1. Device Connect; 2. Set Address; 3. Host reads some/all device descriptors (as required); 4. Authentication (as previously described); 5. Encryption enabled (as previously described); 6. Host re-reads descriptors (encrypted); 7. Set Configuration of the connection. The NCU & device can thus exchange encryption capability during authentication (e.g. in the descriptors) and the NCU can report per-endpoint encryption support in its Endpoint Descriptors.

Although particular embodiments have been described in detail above, it will be appreciated that various changes, modifications and improvements can be made by a person skilled in the art without departing from the scope of the present invention as defined in the claims. For example, hardware aspects may be implemented as software where appropriate and vice versa, and engines/modules which are described as separate may be combined into single engines/modules and vice versa. Functionality of the engines or other modules may be embodied in one or more hardware processing device(s) e.g. processors and/or in one or more software modules, or in any appropriate combination of hardware devices and software modules. Furthermore, software instructions to implement the described methods may be provided on a computer readable medium.

Claims

1. A security device for securely connecting peripheral bus devices, wherein peripheral bus devices are host and/or client devices arranged to communicate via a peripheral bus, the security device comprising: connection means for connecting to one or more peripheral bus devices; authentication means configured, in response to connection of a first peripheral bus device to the security device, to authenticate the first peripheral bus device to determine whether access by the first peripheral bus device is permitted; and communication means for enabling communication between the first peripheral bus device and one or more further peripheral bus devices in response to successful

authentication of the first peripheral bus device.

2. A security device according to claim 1, further comprising a memory storing authentication information for at least one peripheral bus device; the authentication means being configured to perform the authentication using the locally stored authentication information.

3. A security device according to claim 1, wherein the authentication means is configured to perform authentication by transmitting authentication information received from the peripheral bus device to an authentication server over the network for comparison to authentication information stored at the authentication server, and receiving an authentication response from the authentication server.

4. A security device according to claim 2 or 3 wherein the stored authentication information identifies one or more peripheral bus devices for which access is to be permitted, the authentication information preferably including a list of permitted devices.

5. A security device according to claim 4, wherein the authentication information specifies for permitted devices one or more of: a device identifier, optionally including a serial number, device manufacturer and/or model information, device operating system information, and device user information.

6. A security device according to any of claims 2 to 5, the authentication means configured to receive authentication information, optionally including a device identifier, from the first peripheral bus device upon connection, and compare the received

authentication information to the stored authentication information.

7. A security device according to any of the preceding claims, wherein the security device is arranged to be connectable to an external network, optionally wherein the communication means is arranged to enable communication with the external network in dependence on successful authentication.

8. A security device according to any of the preceding claims, comprising means for allowing access to and/or modification of locally stored authentication information specifying peripheral bus devices which may connect to the security device, preferably from an external device and/or via the external network.

9. A security device according to any of the preceding claims, wherein the security device is adapted to store a connection list storing device information identifying connected peripheral bus devices, and to add the first peripheral bus device to the connection list responsive to successful authentication.

10. A security device according to claim 9, comprising means for enabling access to the connection list from an external device, preferably via an external network to which the security device can be connected.

11. A security device according to any of the preceding clams, wherein stored

authentication information for a peripheral bus device further specifies one or more access permissions or restrictions, the security device configured to permit access by the first peripheral bus device in accordance with the access permissions or restrictions, optionally wherein the access permissions or restrictions specify one or more of: whether access to other peripheral bus devices locally connected to the security device is permitted; whether access to an external network is permitted; a bandwidth limit for communication by the first peripheral bus device; and an encryption requirement for communication with the peripheral bus device.

12. A security device according to any of the preceding claims, wherein the

communication means is arranged to process encrypted communications sent to or received from peripheral bus devices, the communication means preferably including means for encrypting and/or decrypting data received from or sent to a connected peripheral bus device.

13. A security device according to claim 12, configured to perform encryption and/or decryption for each connected peripheral bus device in dependence on encryption settings configured for the respective device.

14. A security device according to claim 12 or 13, wherein the communication means is arranged, in response to a communication received from a first connected peripheral bus device, to determine a destination device for the communication, and to decrypt and/or encrypt the communication in dependence on the destination device and optionally in dependence on an encryption state of the received communication.

15. A security device according to claim 14, wherein the communication means is configured to access connection information for the destination device, the connection information indicating an encryption requirement for the destination device, and perform cryptographic processing in dependence on the encryption requirement.

16. A security device according to claim 15, wherein the communication means is configured to: compare the encryption requirement with an encryption state of the received communication; transmit the communication without modifying its encryption state if the encryption requirement matches the determined encryption state; performing decryption and/or encryption of the communication if the encryption requirement differs from the determined encryption state.

17. A security device according to claim 16, comprising, if the encryption requirement differs from the determined encryption state: if the received communication is encrypted, decrypting the communication; and encrypting or re-encrypting the communication in accordance with the encryption requirement if the encryption requirement specifies that encryption is required.

18. A security device according to any of claims 14 to 17, wherein the encryption requirement indicates whether or not encryption is required and/or an encryption key to be used; and/or wherein the determined encryption state indicates whether or not the communication is encrypted and/or an encryption key used to encrypt the communication.

19. A security device according to any of claims 14 to 18, wherein the encryption state is determined from one or both of: the received communication, and connection information stored at the device for the source device of the communication.

20. A security device according to any of the preceding claims, comprising configuration means arranged, in response to connection of the first peripheral bus device to the security device, to store encryption information for the first peripheral bus device, the encryption information indicating whether encrypted communication is supported and/or required by the first peripheral bus device.

21. A security device according to claim 20, the configuration means adapted to receive connection information from the first peripheral bus device upon connection, the connection information including the encryption information.

22. A security device according to claim 20 or 21, comprising one or more of: means for configuring the connection as an encrypted connection in response to determining that the security device and the first peripheral bus device both support encryption; means for, in response to determining that only one of the security device and the first peripheral bus device support encryption, either configuring the connection as an unencrypted connection or rejecting the connection, preferably in dependence on a requirement indicated by the device that supports encryption; and means for, in response to determining that neither the security device nor the first peripheral bus device support encryption, configuring the connection as an unencrypted connection.

23. A security device according to any of claims 20 to 22, arranged to store the encryption information in a connection list following successful authentication of the first peripheral bus device.

24. A security device according to any of the preceding claims, wherein the connection means is arranged for connection of peripheral bus devices to the security device by way of one or more wired or wireless connections.

25. A security device according to any of the preceding claims, wherein the connection means comprises one or more Universal Serial Bus (USB) ports for connection of peripheral bus devices, the ports preferably comprising: at least one USB host port for connecting to USB host device(s); and at least one USB peripheral port for connecting to USB peripheral device(s).

26. A security device according to any of the preceding claims, wherein the

communication means is configured not to allow communication between the first peripheral bus device and other connected devices in response to failure of the authentication.

27. A security device according to any of the preceding claims, wherein the first peripheral bus device is a further security device as set out in any of the preceding claims.

28. A security device for securing connections between a computer device connected to the security device and one or more peripheral devices, the security device comprising: means for connecting to one or more peripheral devices; authentication means configured, in response to connection of a peripheral device to the security device, to authenticate the peripheral device to determine whether access by the peripheral device is permitted; and means for enabling communication between the peripheral device and the computer device in response to successful authentication of the peripheral device.

29. A security device comprising: network connection means for connecting to an external network; device connection means for connecting to one or more local devices; authentication means configured, in response to connection of a first local device to the security device, to authenticate the first local device using authentication information stored locally at the security device, to determine whether access by the local device is permitted; and communication means configured, in dependence on the outcome of the

authentication, to allow or prevent communication between the first local device and one or both of: one or more other devices connected locally to the security device, and the external network.

30. A security device according to claim 29, comprising a memory adapted to store the authentication information, the authentication means adapted to receive device authentication information from the first local device, the device authentication information preferably including a device identifier; and to compare the device authentication information to the stored authentication information.

31. A security device according claim 29 or 30, adapted to store connection information identifying one or more locally connected devices which have been successfully

authenticated and are able to communicate via the security device.

32. A security device according to any of claims 29 to 31, comprising means for enabling access to and optionally modification of locally stored authentication information and/or connection information, preferably by an external device and/or via the external network.

33. A security device as set out in any of claims 28 to 32, further comprising the further features of a security device as set out in any of claims 2 to 27.

34. A system comprising at least two security devices as set out in any of the preceding claims, the security devices connected to each other, wherein a first one of the security devices is configured to authenticate the second one of the security devices.

35. A method of securely connecting peripheral bus devices to a security device, wherein peripheral bus devices are host and/or client devices arranged to communicate via a peripheral bus, the method comprising: in response to connection of a first peripheral bus device to the security device, authenticating the first peripheral bus device to determine whether access by the first peripheral bus device is permitted; and enabling communication between the first peripheral bus device and one or more further peripheral bus devices in response to successful authentication of the first peripheral bus device.

36. A computer readable medium comprising software code for performing a method as set out in claim 35 or any other method as set out herein, or for carrying out functionality of a security device as set out in any of claims 1 to 33 when run on the security device.