WO2021148783A1

WO2021148783A1 - Encryption device

Info

Publication number: WO2021148783A1
Application number: PCT/GB2021/050119
Authority: WO
Inventors: Raymond Paul GORDON; Andrew John Fisher
Original assignee: Secure Design Limited
Priority date: 2020-01-21
Filing date: 2021-01-20
Publication date: 2021-07-29
Also published as: GB202000893D0; GB2592568B; GB2592568A

Abstract

There is disclosed an encryption device (100) comprising: a first interface (104) for connecting to a host device (150); a second interface (106) for connecting to a further said encryption device (200), where the encryption device (100) is configured: to communicate with the further encryption device (200) via the second interface (106) to facilitate the exchange of cryptographic data; to receive content data via the first interface (104) from the host device (150) using a network protocol; and to encrypt or decrypt the content data using said cryptographic data.

Description

ENCRYPTION DEVICE

Field of the Invention

The present invention relates to a processing device and an encryption device.

Background of the invention

Guarding private electronic data is increasingly important. Normally one seeks to secure data whether it is stored locally or in ‘the cloud’. Data should also be protected against interception during transmission to others.

There are numerous solutions on the market that secure data through encryption. Software solutions tend to be complex or suffer from security defects. Passwords that protect encrypted vaults or transfer services may be captured by key loggers. Vaults are also susceptible to malware attacks. On-line (cloud) services are both simple and convenient but require an element of trust from the user. There is a question of how well data is really encrypted and protected, and there may be concerns over whether a backdoor has been built into the service, to enable snooping by privileged parties.

Hardware solutions, which generally take the form of an encrypted external storage device, are more secure. They normally require authentication on the device itself via a PIN, fingerprint sensor or ID card. However, everything is stored on the portable device, which is a problem if it is mislaid or fails. Also, there is no easy way to send individual encrypted files without sending the entire device to someone else.

There is a need for a simpler encryption device that facilitates easy transmission of encrypted files, and which is much less vulnerable to attack than the other solutions. There is also a need for alternative and more effective implementations for interfacing with external hardware.

The present invention aims to solve the problems mentioned above, and to address the identified needs. Summary of the invention

According to a first aspect of the present invention, there is provided an encryption device comprising: a first interface for connecting to a host device; a second interface for connecting to a further said encryption device, wherein the encryption device is configured: to communicate with the further encryption device via the second interface to facilitate the exchange of cryptographic data; to receive content data via the first interface from the host device using a network protocol; and to encrypt or decrypt the content data using said cryptographic data. Typically, the encryption device comprises at least one processor; and computer program code executable by said at least one processor, wherein the computer program code, when executed by said at least one processor, causes the encryption device to perform the specific actions that it has been configured to perform. Different functions of the encryption device may be implemented using separate processor and computer program code modules as necessary for enhanced security.

A network protocol preferably connotes a protocol capable of conveying Ethernet or Internet traffic, such as Internet Protocol (IP) and/or hypertext transfer protocol (HTTP), and the like. In some cases, a network protocol may be any protocol distinct from protocols intended for other purposes, such as mass storage protocols. The term ‘encryption device’ preferably connotes a device using encryption-related algorithms which may perform either or both of encryption and decryption of data (it may for example be a decryption-only device or an encryption-only device).

The encryption device as claimed provides the benefit of flexible operation by virtue of the network protocol being used over the first interface, while maintaining security because no cryptographic data is exchanged with the host device or transmitted anywhere except directly to another encryption device of the same type. The division of functionality between the first and second interfaces means that it is not necessary to ensure as secure a connection via the first interface as is ideally necessary via the second interface, which simplifies operations between the encryption device and host device and can avoid the need for expensive additional authentication and/or encryption components.

Preferably the encryption device is configured such that communication between the encryption device and the further encryption device is enabled when the two devices are brought into physical proximity of each other. This can improve the cryptographic security further, reducing the risk of a ‘man in the middle’ style cryptographic attack. Preferably a physical and/or direct connection is provided between the two devices. That is to say, preferably the two devices are physically contacting each other, at least via their respective interfaces and/or interface adaptors, and preferably no connecting means is provided such as an Ethernet, USB or any other type of cable.

Alternatively, proximity may imply a physically restricted connection (other than physically touching) between the two devices such as optical or electromagnetic line-of-sight, or otherwise being within sufficient range to communicate directly with each other by any appropriate method, such as electromagnetic radiation (including Bluetooth(RTM) and WiFi(RTM) signals), sound waves, magnetic or inductive processes, and so on.

Preferably communication between the devices is enabled only via a deliberate action on the part of the user of each encryption device, for example by plugging one device into the other, or otherwise deliberately bringing the devices into contact with each other, or for example by a deliberate action to perform any other action (such as pressing a button on each device, or similar) to indicate a desire to initiate contact between the two devices. The second interface is preferably operable to connect to the first interface of said further encryption device. Conversely, with the encryption devices being of the same type, it is possible for the encryption device to connect its first interface to the second interface of the further encryption device. This reuse of one of the interfaces for a different purpose reduces the cost of the device.

The connection between the encryption device and the further encryption device preferably establishes a master/slave relationship between the two devices. Typically, the encryption device is the master and the further encryption device is the slave, but the reverse arrangement is of course possible. This is advantageous in that two different encryption devices can be assigned different roles without requiring any physical or electronic input by the user to either device to set their state. It will be appreciated that this principle can be extended beyond merely defining roles in a pairing operation.

Preferably the second interface is a USB interface. This may be a physical USB device interface (that is, the appropriate physical connector) and/or USB data protocol (including but not limited to USB network device protocol and/or USB CDC device protocol). Preferably the first interface is also a USB interface, and preferably of matching type but opposite gender to the second interface. The second interface may alternatively be an MMC/SD interface, and the encryption device may be encapsulated in an SD/MMC style memory card. Other package sizes, shapes and protocols are of course possible.

In a preferred embodiment, the encryption device is configured to process the content data as a stream, such that at least a portion of the content data is encrypted or decrypted and transmitted back to the host device before all the content data is received. The encryption device may impose rate control on the reception of the content data in order to ensure that sufficient time is provided to carry out encryption or decryption. Preferably the encryption or decryption is carried out on separate chunks or segments of the content data, preferably segmented in accordance with known protocols. By streaming the encrypted or decrypted data, the need for storage for the content data (either volatile or non-volatile) can be obviated, though this can be provided if desired or appropriate.

Volatile storage may be provided for other means, for example for other sensitive data such as one-time temporary encryption keys, and as scratch memory for network operations. Preferably the storage is volatile such that removing power from the device (for example by unplugging it from the host device) automatically clears the storage.

The encryption device may be further configured to operate as a virtual network that is accessible by the host device via the first interface. It may for example be further configured to respond to DHCP and DNS requests to facilitate this operation. In a related aspect, the encryption device may further comprise a network initialisation module for causing the encryption device to be associated with at least one IP address. Preferably the module includes means for avoiding or resolving clashes of IP address, for example by selecting or reselecting random IP address values or ranges, or by allowing the user of the encryption device and/or the host device to manually specify an IP address to use. The encryption device may also or alternatively provide some form of display (dynamic or permanent, for example marked on the device) to indicate the network details associated with the encryption device. The encryption device preferably also identifies appropriate domain names, for example relating to the name of the encryption device model or brand (or some combination thereof), and in response provides a web page or application to the host device in response.

In case of difficulty accessing the virtual network on the encryption device, the first interface may be operable in a mass storage device mode which allows the host device to access a virtual filing system via the first interface. This can allow the encryption device to communicate with the host device without the need to allocate viable IP address, and can for example pass configuration information via files transmitted to the virtual mass storage device. This can, for example, resolve any issues with finding a suitable network address (allowing the user of the host device to specify a preferred address in a text or other file transmitted to the virtual filing system, or similar).

The encryption device is preferably further configured to provide a user interface to the user of the host device in the form of a web page served to the host device via the first interface. Preferably this is based on a hypertext transfer protocol (HTTP) standard, and may be based more specifically on GET and POST requests.

The encryption device is preferably configured to provide a web API to the host device via the first interface, so as to allow commands to be sent to the encryption device by the host device, said commands preferably including at least one of: encryption or decryption operations, configuration operations, generation of cryptographic data, deletion of cryptographic data, exchange of cryptographic data, and authentication operations. The web API commands are for example HTTP protocol GET and POST commands, but may be any appropriate protocol or format. The web API commands may for example be provided via JSON or XML protocol/format. Preferably no computer program code is required to be executed on or by the host device outside the normal operation of a web browser (for example running Javascript(RTM) code and the like). It is nevertheless possible to provide additional browser plug-ins or external code to provide substitute or enhanced functionality, but this is not required. Any additional or external code could be automatically loaded or manually discoverable within the virtual network provided by the encryption device, for example.

The aforesaid cryptographic data typically includes an encryption key, such that both the encryption device and further encryption device are able to encrypt and decrypt files using that encryption key.

The encryption device preferably further comprises a key generator for generating a new encryption key for each pairing of encryption device and further encryption device. Thus, the encryption key for each pairing of devices is typically never transmitted outside the encryption devices (only once, between them via a secure connection), greatly improving the cryptographic security of the system. Alternatively, encryption keys can be received from elsewhere or shared via a central repository, or similar, but this is generally not preferred.

The encryption device is preferably configured to operate in one of at least three modes including encryption device, pairing device master, and pairing device slave. It may also be operable in a reprogramming mode, when connected to a reprogramming module as mentioned below. Preferably the operating mode is selected in dependence on what is detected to be connected to the first and second interfaces. For example, if a host device is connected to the first interface and nothing is connected to the second interface, the encryption device will usually operate in the encryption device mode. If a further encryption device is detected as being connected to the second interface, the encryption device will operate in pairing device master mode (or slave mode, alternatively), and if a further encryption device is detected as being connected to the first interface, the encryption device will operate in pairing device slave mode (or master mode, alternatively).

The encryption device may further comprise non-persistent data storage powered by the connection between the encryption device and the host device, wherein removing the encryption device from the host device automatically causes the non-persistent data storage to be erased (either by erasing the files or the encryption key needed to access them, or both). This increases the cryptographic security of the device.

The encryption device may be further configured to receive authentication data, and consequently the encryption device may be configured to validate the authentication data before encrypting or decrypting the content data. A password may be needed to access the decryption facility, for example, or otherwise to access the device. The authentication data is preferably at least one of: a password; pass key; PIN; public key; and cryptographic signature. The authentication data can be received from host device or received from an appropriate input device provided on the encryption device, or otherwise.

The encryption device is preferably configured to pair with the further encryption device when the further encryption device is connected via the second interface. ‘Pairing’ preferably connotes establishing some form of relationship between the devices, preferably a cryptographic relationship, which relationship preferably persists after the devices are disconnected from one another. Pairing can occur whether the encryption device is connected to the host device or otherwise (but may in some cases require power to be supplied by such a connection). Preferably pairing occurs only once, but the pairing can be refreshed or forgotten as appropriate, for example at the direction of a user of either the encrypted device or the further encrypted device.

On pairing, the encryption device is preferably configured to create pairing data representing an association between the encryption device and the further encryption device, and to store said pairing data within the encryption device. Preferably the pairing process causes the further encryption device to do the same. The pairing data typically includes a cryptographic key unique to the combination of encryption device and further encryption device(s), and at least one identifier associated with the further encryption device. The identifier may include a numeric or other machine-understandable identifier allowing the encryption device to identify the paired encryption device and/or a text-based or other human- understandable identifier allowing the user to identify the paired encryption device or the owner or user of said paired encryption device. The human-understandable identifier may be provided by the user of the encryption device via a user interface on the host device, or otherwise, and at the time of pairing or later on.

In pairing, the encryption device is preferably further caused to exchange cryptographic keys with the further encryption device, such that at least one said encryption device is able to decrypt files encrypted by the other said encryption device. This may comprise communicating with the further device using an encrypted protocol.

The encryption device may be further caused to receive a pairing request from a remote encryption device to which it is not physically connected, and to pair with the remote encryption device by exchanging messages with the remote encryption device. This request is preferably received via the interface but could be received by other means, for example using appropriate wireless communication hardware and protocols. The remote device is preferably a further said device but need not be. Preferably the pairing request and any subsequent exchange of data with the remote device is encrypted appropriately, for example using appropriate public keys and private keys held within each device and/or derived from other secret keys. Thus a workable system can be provided for remote pairing, but the system is less cryptographically secure than one involving only physical pairing. However, the encryption device may be further caused to create a new pairing with the remote device on detection of the remote device being attached to the encryption device via a second interface. This can restore the cryptographic security once the devices are brought to the same location.

In one usage case, the encryption device is caused to be paired in a one-to-many fashion with a plurality of other devices, whereby the encryption device is designated as an originator device and the plurality of other devices are designated as group devices. Preferably the plurality of other devices are the same type as the encryption device, and the pairing is preferably automated. Preferably the pairing is configured such that each group device can decrypt files which have been encrypted by the originator device. Typically, the reverse is not true, and the communication is one-way. Optionally the originator cannot decrypt the file once encrypted, requiring a paired device to decrypt thereafter.

In another usage case, the encryption device is caused to be paired in a many-to-many fashion with a plurality of other devices, whereby all of the devices are designated as group devices. In this case, a predetermined set of devices selected from the group devices may be designated as originators, being capable of encrypting files that can be decrypted by all of the group devices. Preferably each of the group devices can decrypt files encrypted by any other group device. Other arrangements, for example including a different arrangement of group and originator devices, are of course possible

The encryption device may further comprise a non-volatile data store including configuration data, and wherein the encryption device is further configured to: detect connection of a reprogramming module; to receive configuration data from the reprogramming module, and to replace any configuration data in the non-volatile data store with the received configuration data. Preferably the reprogramming module is connected via the second interface using a custom (or otherwise) encrypted protocol, with no data exposed externally, but may be connected via the first interface or via a third interface (which is optionally dedicated to the purpose of connecting to reprogramming modules). The cryptographic data preferably comprises security credentials for use by the encryption device so as to provide a cryptographic clone of a different said encryption device.

The reprogramming module can be used for recovery purposes but is not so limited. It can for example be used to provide an initial configuration for a factory issue encryption device. The recovery module is preferably provided with an identifier to assist in recovery operations (or otherwise). In one embodiment, at least one cryptographic key associated with the encryption device is stored in a central repository, and is available for transmission to a recovery module or to the encryption device on demand, for example after providing appropriate authentication. In a more preferred embodiment, at least one cryptographic key in the encrypted device is secret within the encryption device. At least one cryptographic key may be generated within the encryption device, for example using random or pseudo-random number generators, and thus may never exist outside the encryption device at any time, leading to increased security. In addition, the user typically never knows or needs to know any of the cryptographic keys within the encryption device, and thus does not present a security risk as regards the knowledge of the cryptographic key(s) in the encryption device.

The use of the recovery module can reset an existing device if the cryptographic data is corrupted, or can program a new or different encryption device to behave as a clone of a different encryption device (for example one which no longer works). No software is required but helper software on the device host (or elsewhere) or a web page or application served by the encryption device to the host device can assist.

In another aspect, the encryption device may be configured to generate a backup data file for export, said backup data file including configuration data from the encryption device, and to encrypt the backup data file. The backup data file may be copied from the encryption device, for example to the host device, so that it can be backed up as required. Preferably the encryption device is further caused to receive a backup data file from the host device, and to process the backup data file on request so as to restore configuration data in the encryption device. The encryption device may be provided in the form of a USB key drive. The encryption device could be provided internally or otherwise attached more permanently to a host device.

Power is preferably passed on through the second interface to the further encryption device. Accordingly, any failsafe data deletion will occur in both devices if the first device is unplugged. Preferably the communication between the encryption device and further encryption device is via a bi-directional data protocol such as CDC, but an initial communication may be made via a network protocol before it is determined that the encryption device is connected to another device rather than a host device.

The encryption device may include an LED or other visual (or other form of) output for indicating the status of the device, including but not limited to statuses including: connected to host; disconnected from host; processing; processing complete; paired with other device; not yet paired with other device; safe to remove; unsafe to remove; storage full; and so on. The device may include a speaker and emit a sound or provide any other appropriate output to indicate any of these statuses, for example.

In one variant, the encryption device further comprises a file storage module (comprising one or more memory and/or storage units), and wherein the device is further caused, on receiving said at least one file, to store said at least one file in the file storage module, and wherein performing the encryption or decryption operation comprises replacing each file in the data storage with a processed version. Preferably the processed version of each file is stored in a separate location to the original file but need not be. Preferably the encryption device is caused to create a file system structure in the file storage module, preferably either prior to connecting to the host device or in response to connecting to the host device. Preferably the encryption device is also caused to format the file storage module before creating the file system structure. Alternatively, the file storage system may be a permanent or otherwise non volatile storage which is intended to persist (acting as an encrypted storage unit).

If a filing system is provided, the encryption device preferably is configured: to add filing system level encryption to each file, optionally using a first encryption standard, as (or when) it is stored in the file storage module using a filing system encryption key; to remove the filing system level encryption from each file, optionally using the first encryption standard, as it is read out of the file storage module using the filing system encryption key. Optionally performing the (main) encryption or decryption operation (for files which are destined for a less secure environment) comprises using a second encryption standard (algorithm and/or key size) to encrypt or decrypt each file. The second encryption standard may be stronger than the first, at least in terms of at least one of a plurality of metrics such as key size, algorithm type, and so on, but for simplicity it is preferably the same. Either encryption standard is preferably relatively quick to apply and is preferably a symmetric key algorithm such as AES, triple-DES or plain DES, and is preferably efficient enough to be used transparently or on-the-fly while saving the file(s). The second encryption standard in some cases may be a public/private key algorithm such as RSA and PGP. Accordingly, at no point is data stored on the device in an unencrypted form. Preferably the filing system encryption key is stored in non-persistent memory and is deleted in response to the encryption device being removed from the host. Alternatively, or additionally, the encryption device is preferably configured such that files stored in the file storage module are stored in non- persistent memory (also) and are deleted in response to the encryption device being removed from the host.

In one embodiment, the encryption device (employing an appropriate power source) is caused to manually erase sensitive data on detection of a relevant event indicating that a session with the host device has likely ended. That event may include at least one of: the physical removal of the device; the host powering off; a log off or shut down event in the host; an unauthorised attempt to access the device; unusual communications activity; a time-out since the last communication from the host; a time-out since the start of the encryption session; physical tampering with the device; and electronic tampering with the device. Preferably the deletion of any sensitive data will happen automatically, however. The non- persistent memory may be volatile memory, such as RAM, which loses its contents when it loses power, or any other type of storage device in which the contents are erased after a predetermined length of time or after a predetermined event, and so on.

In a further aspect of the invention, there is provided a processing device comprising: an interface for connecting to a host device, wherein the processing device is configured: to switch to a first operating mode on being connected to the host device via the interface; to receive authentication data from the host device via the interface while operating in the first operating mode; and to operate in a second operating mode after validating the authentication data. Thus the integral features of the interface between the processing device and host device can be used to conceal or to restrict additional or alternative functionality, for example to ensure no unauthorised use is made of the device’s capabilities.

Preferably the first operating mode is a mass storage mode, in which the processing device provides a filing system interface to the host device and is operable to at least receive from and optionally transmit data files to the host device. The mass storage mode may be a USB mass storage mode or otherwise, and may use a USB or network protocol, or otherwise.

Preferably the second operating mode is an encryption/decryption mode, but it may take any appropriate form to provide any desired type of processing, for example processing data on demand/on-the-fly.

The processing device may be further configured to validate the authentication data and to reconnect to the host device if the validation is successful. The validation may involve comparing an input pass phrase with a stored pass phrase, or carrying out a hashing operation and/or comparing hashes, or carrying out any appropriate form of authentication with any appropriate form of data (including biometric data, numeric data, machine-readable data, private key cryptography, physical inputs into or on the processing device, and so on).

In another aspect of the invention, there is provided an encryption device comprising: an interface for sending and receiving data between the encryption device and a host device; and a non-volatile storage module, wherein the encryption device is configured: on an initial connection to the host device, to provide the appearance of a mass storage device to the host device; to receive a file containing authentication data from the host device; and on validation of the authentication data in the received file, to present to the host device additional features relating to an encryption/decryption capability. Preferably the authentication data is text within a text file.

The encryption device may be further configured (after validation of the authentication): to receive content data from the host device; to process the content data to perform a cryptographic operation on the data; and to transmit the transformed content data to the host device via the interface. Any appropriate aforesaid feature may be combined where possible and appropriate with this aspect or the preceding aspect (or any other).

In another aspect of the invention there is provided a non-transitory computer readable medium tangibly embodying computer program code which, when executed by one or more computer processors, causes the computer to carry out a method as aforesaid.

Although the embodiments of the invention described herein with reference to the drawings may comprise computer-related methods or apparatus, the invention may also extend to program instructions, particularly program instructions on or in a carrier, adapted for carrying out the processes of the invention or for causing a computer to perform as the computer apparatus of the invention. Programs may be in the form of source code, object code, a code intermediate source, such as in partially compiled form, or any other form suitable for use in the implementation of the processes according to the invention. The carrier may be any entity or device capable of carrying the program instructions. The computer program code as aforesaid may be provided in any other appropriate and tangible form (such as a computer readable signal or encoded onto any general purpose or other computing device or hardware). The computer readable medium may, for example, be a CD, DVD, Blu-ray (RTM) disc, or similar, or a hard disk, solid state disk, integrated circuit, and so on.

Although various aspects and embodiments of the present invention have been described separately above, any of the aspects and features of the present invention can be used in conjunction with any other aspect, embodiment or feature where appropriate. For example apparatus features may where appropriate be interchanged with method features. References to single entities should, where appropriate, be considered generally applicable to multiple entities and vice versa. Unless otherwise stated herein, no feature described herein should be considered to be incompatible with any other, unless such a combination is clearly and inherently incompatible. Accordingly, it should generally be envisaged that each and every separate feature disclosed in the introduction, description and drawings is combinable in any appropriate way with any other unless (as noted above) explicitly or clearly incompatible.

The invention will now be described further, by way of example, with reference to the accompanying drawings, in which:

Figure 1 is a schematic of a first embodiment of an encryption system, including a host device, an encryption device and a further encryption device;

Figure 2 is a schematic of the encryption device of Figure 1 ;

Figure 3 is a schematic of the persistent memory module of the encryption device of Figure 1 ;

Figure 4 is a more detailed schematic of the encryption device of Figure 1, showing typical data flows within the device;

Figure 5 is another schematic of the encryption device of Figure 1, illustrating signal and power connections;

Figure 6 is a more detailed overview of the encryption device of Figure 1;

Figure 7 is a flow chart of the process of securely processing a file using the device of Figure 1;

Figure 8 is a schematic showing a reprogramming module attached to the device of Figure 1 ;

Figure 9 is a flow chart of the process of reprogramming the device of Figure 1 with the reprogramming module of Figure 8;

Figure 10 is a schematic showing components of the device of Figure 1 involved in an encryption mode;

Figure 11 is a schematic showing components of the device of Figure 1 involved in a pairing master mode;

Figure 12 is a schematic showing components of the device of Figure 1 involved in a pairing slave mode;

Figure 13 is an illustration of the device of Figure 1; Figure 14 is an illustration of the reprogramming module of Figure 8;

Figure 15 is an illustration of an alternative connection arrangement of the encryption device and reprogramming module;

Figure 16 is an illustration of a further alternative connection arrangement of the encryption device and reprogramming module;

Figures 17A to 17F are screen shots illustrating the operation of the device of Figure 1;

Figure 18 is a schematic of a network of interconnected host devices and associated encryption devices;

Figure 19 is a flow chart illustrating the operation of a further embodiment relating to a processing device presenting multiple interfaces to a host device; and

Figure 20 is a flow chart illustrating the operation of a further embodiment relating to an encryption device with a concealed encryption/decryption operating mode.

Detailed description of the preferred embodiment(s)

Various embodiments of an encryption/decryption device and a general processing device will now be described.

Figure 1 is a schematic of an encryption device within an encryption system. Components of the system that are additional to the encryption device are shown with dotted outline. The encryption device 100 includes an encryption subsystem 102, a first interface 104 for connecting to a host device 150, and a second interface 106 for connecting to a further encryption device 200 (typically but not necessarily of the same type as the first 100). The host device 150 includes a processor 152, memory 154 and an interface 156. In the preferred embodiment, the interfaces 104, 156 are network interfaces (that is, interfaces capable of communicating network traffic by appropriate means, rather than being particular types of physical connector), and, in particular, they are USB device interfaces with physical and electrical properties defined by the relevant USB standard(s). Other options are possible, including software and/or hardware standards such as Ethernet, Wi-Fi(RTM) and Bluetooth(RTM) (that is, a non physical connection is possible), and so on.

The main requirement for the interface 104 is a bidirectional data transfer capability and (in preferred embodiments) the ability to send and receive network traffic with the device host and (yet more preferably) the ability to supply power to the device. Any physical or software interface may be appropriate if it can fulfil those requirements. The standard USB interface normally meets these requirements. The encryption device 100 may include an additional power supply interface or internal or external power supply (such as a rechargeable or disposable battery of appropriate size), for example where the interface 104/156 is not able or not configured to provide a power supply to the encryption device (or it is chosen not to rely on it).

The following description refers to encryption and decryption operations, to which the presently described hardware and/or software architecture is well suited. The operation of the encryption device is described in more detail below.

Figure 2 is a schematic of the encryption device 100 of Figure 1. In more detail, the encryption device 200 includes a processor 202, one or more persistent memory modules 204 (such as flash memory, hard disk, EPROM, EEPROM and the like), one or more non-persistent memory modules 206 (such as an appropriate variety of RAM, or automatically self-erasing persistent memory), a first interface 208 for connection with a host device, and a second interface 210 for connection with another encryption device.

Figure 3 is a schematic of the persistent memory module of the encryption device of Figure 2. The persistent memory module 300 typically includes computer program code 302 for execution by the processor 202 of Figure 2, device configuration data 304, device encryption data 306, optional (not typically present) file storage 308, pairing and group configuration 310 and the secret encryption keys 312 of paired devices. Other data may be stored in the module 300 as appropriate and necessary.

The encryption data 306 includes a main encryption key that is uniquely associated with the encryption device. In the preferred embodiment, it is generated by the encryption device itself, for example if the encryption device detects on power-up (or other occasion) that a key is not yet present. In this case, the main encryption key, unknown by any other device, is also not known to the manufacturer of the encryption device. The main encryption key is used to encrypt and decrypt the user’s files and to encrypt internal data as needed. It will generally be stored in OTP (One Time programmable memory) within the device.

Accordingly, total cryptographic security is provided (initially at least) outside the encryption device itself. In one example described below with reference to Figure 8, the main encryption key can be ‘backed up’ onto a reprogramming device or similar, to allow an encryption device to be cloned to replicate the original device in the event of loss or technical failure, and so on, but this is entirely optional. If a user never utilises a reprogramming device backup, then if the user initially destroys the encryption device, the user’s own files encrypted with it can never be decrypted (except by brute force methods); in this case, the main encryption key never leaves the encryption device. At the time of destruction, any files shared with ‘paired’ encryption devices (see below) can still be decrypted (only) by the paired device, but the shared files can be rendered unreadable if the paired device is also destroyed or reset, or instructed to forget the pairing. A system can be provided if desired to send a communication to a paired device by any appropriate means to instruct the paired device to forget the pairing. Appropriate authentication may be provided (for example using public/private key methods) and the communication may take place automatically, or decryption of shared fries may be made dependent on checking with a central server for such communications, and so on.

As is explained in greater detail below, the encryption data 306 may also include a user-specified password or other pass key of any appropriate form (such as finger or voice prints, number combination, other button sequence, and so on) which may be required to operate the device and/or to decrypt any data using the main encryption key (or otherwise). The term ‘encryption data’ in this context may as appropriate comprise authentication data. All of the stored cryptographic data may be further encrypted, for example using the user-specified password or other pass key. By this means, anyone able to compromise the persistent memory 300 of the device would be unable to obtain any secret keys in the clear.

Each element of the memory 300 may be provided in any combination (for example as separate memory units). Certain elements of the memory 300 (such as the computer program code 302 and secret device encryption data 306) may be stored in read-only memory portions of the device so as to minimise the risk of electrical tampering.

Part or all of the memory module 300 of Figure 3 may be provided with an additional (for example hard coded) cryptographic interface, only allowing read and/or write operations if appropriate authentication is provided at appropriate moments (for example on power-on and/or connection to a host device) and/or intervals, for example using a public/private cryptography scheme to allow secure authentication even if the authentication messages are intercepted. Such a system could be provided between any two parts of the device architecture, where appropriate. In the preferred embodiment, at least part of the memory modules (for example the computer program code) and processor are provided in a secure package which is destroyed when an attempt is made to open it, preventing electronic intrusion. The processor and program memory may be provided as an integral microcontroller, for example.

In one embodiment (not shown) a non-persistent memory module is provided for the purpose of file storage. The non-persistent memory module in this case includes a file system encryption key, which is used to perform a file system level encryption on fries sent to the encryption device. The file system encryption key is generated randomly by any appropriate method each time the encryption device is powered up, and then stored in the memory. Other data, including other encryption keys and/or authentication-related data, or working data, temporary data, and so on, may also be stored in the non- persistent memory as required and appropriate. In any event, non-persistent memory is provided for the purpose of scratch RAM and the like that is needed during the normal operation of the virtual network and virtual web server, described below. Typically, this memory is not cryptographically sensitive, and no special precautions are needed, but the memory may also in some cases be used by the cryptographic engine, so it may be desired to provide appropriate protection, also as described below.

The different types of non-persistent memory mentioned above are non-persistent insofar as the removal of the encryption device and/or removal of power from the encryption device cause the data held in the memory module (and in particular the fde system encryption key, if used) to be wiped automatically. This avoids the risk of any user data in the device being compromised while the encryption device is stored between uses, and so on; files may be stored on the device while it is turned off, but without the file system encryption key they are effectively impossible to decrypt. Other events may trigger the wiping of the memory as appropriate, for example on detection of a physical or electrical intrusion into the encryption device. The file system level encryption scheme (if used) typically uses the same encryption algorithm as the main file encryption/decryption (but with a different key) for simplicity and reliability, but for reasons of performance or to save power, a less robust scheme than the main encryption/decryption scheme can be used in order to provide file system level encryption.

Figure 4 is a more detailed schematic of the encryption device of Figure 1, showing typical data flows within the device. The encryption device 400 includes a network-compatible interface 402 (such as a USB device interface), providing a virtual web server 404 which responds to appropriate requests via the interface 402. The encryption subsystem of the encryption device provides an encryption module 406 and decryption module 408 (provided in any appropriate form, such as separate hardware or software units, or in a single unit by operation of the computer program code executing on the processor) operating under the instruction of the virtual web server 404. Static web content 410, such as CSS style sheets, JavaScript applications and HTML pages, is also provided for use by the virtual web server. The encryption device also includes a processor 412 and associated computer program code and other operational data (not shown). The host device (not shown) provides content data for processing 420 and received processed versions of the data 422 in return. Commands 424 are also provided to the encryption device 400 in appropriate forms, typically in the form of GET and POST commands in the HTTP or HTTPS protocols.

Files 420 for processing are sent to the device 400 via the interface 402 using GET and POST commands (typically). To the external device it appears as if the files are being uploaded to a remote website. Within the device 400, however, the files are redirected through the encryption module 406, which encrypts the stream of data as it passes through. In the preferred embodiment, files are processed as a stream, whereby a download is started for a file as soon as it is received, and the file is processed in chunks. Thus no storage is used or required for files as they are received, so no sensitive content data is typically stored on the encryption device. In a variant of the preferred embodiment, the encryption device includes long-term storage and content data is deliberately stored on the encryption device (for example in the form of an encrypted hard disk or SDD which has the present encryption device embedded within it, or otherwise).

Figure 5 is another schematic of the encryption system of Figure 1, illustrating signal and power connections. The encryption device 500 includes the (first) interface 502, non-persistent memory 504 as described above (typically just scratch RAM, but in some cases containing sensitive content or cryptographic data), an encryption/decryption module 506 (which is typically embodied in a processor and associated memory), and (very) optionally file storage 508 as described above. The host device 550 includes an interface 552 as described above, which is connected to the encryption device 500 via a wired link 580. The wired link 580 is preferably not (or minimally) susceptible to electronic or physical intrusion and preferably does not produce a large amount of electromagnetic radiation. Accordingly, data passing via the link 580 is relatively safe from interception, making it an appropriate conduit for passing unencrypted data between the host device 500 and encryption device (such as files being sent for encryption, and files being received after decryption). The link 580 includes a power connection 582, supplying power to the attached device 500, and a (relatively safe from snooping) data connection 584. Internally, the encryption device 500 forwards on power to the non-persistent memory 504 and (optionally) forwards data to the file storage 508 via internal power 512 and data 514 conduits respectively, which (as described above) may pass through one or more intermediate devices and modules (such as the encrypt/decrypt module). In the preferred embodiment, the non-persistent memory 504 loses all data as soon as it loses power.

The advantage of the system shown in Figure 5 is that any removal of the encryption device 500 or any removal of the link 580 will automatically cause all data in the non-persistent memory 504 to be erased. In this configuration, no active steps need to be taken by the encryption device 500 or host device 550 to achieve this. Though the files in the (optional) file storage 508 may be retained after losing power, the lack of the file system encryption key 516 renders them effectively useless. However, in variants of the preferred embodiment, the files are also deleted (either manually, or by virtue of being stored in non- persistent memory also, as described in more detail later).

In variants, the non-persistent memory 504 may not automatically erase all data on power loss (that is, it could be persistent memory of some sort with an appropriate controller attached to provide the non- persistent behaviour). In this case the memory 504 may be configured to wipe all data on detection of a power loss or other appropriate event; in these variants typically some other form of power supply is required (such as a capacitor, rechargeable battery, or similar device powered by the power line 512 to store a small amount of charge to allow a short period of operation after power loss). Since the non- persistent memory need store only a single encryption key (typically 256 bits), this provides the advantage that only a small amount of charge/memory access is needed to complete the deletion, regardless of how many files are stored and how big the persistent storage is. As noted above, the non- persistent memory can be controlled to wipe the data in response to other events, such as detecting physical or electrical intrusion.

Notwithstanding the automatic erasure of user data mentioned above, at least one secret key is required to be stored on the device for encrypting and decrypting the user data. Accordingly, appropriate physical security should be provided for the encryption device (whether in use or not) to prevent it being used for unauthorised decryptions (although it is possible to provide more additional security to protect it more completely, for example decrypting it using a user-supplied passcode or similar which is not stored on the device). On the other hand, since encryption and decryption operations are typically only carried out when the encryption device is electronically disconnected from the host device, the device is less susceptible to electronic attack.

Figure 6 is a more detailed overview of the encryption device of Figure 1. The device includes a USB physical device interface 602, corresponding to the abovementioned first interface, as well as a USB physical host interface 604, corresponding to the abovementioned second interface, and a display 606. At a more conceptual (software or hardware module) level, the device also includes a USB network device stack 608 and USB CDC device stack 610 operative on the USB interface 602. Static web content 612 is provided as mentioned above, as is a virtual web server 614, and a virtual DHCP server 616 and virtual DNS server 618. The DHCP and DNS server allow the registration of the web server of the encryption device at an appropriate network location visible to the host device, and the discovery of the web server by name from the host device, respectively. User metadata and configuration data 620 is provided (typically in non-volatile storage as mentioned above), as well as an encryption engine 622 and encryption key management module 624. An encryption key store 626 is also provided, typically in non volatile storage, which may be the same as for module 620, but typically as a separate, highly secure store. A USB host stack 628 is provided to access the USB physical host interface 604 mentioned above. Also provided is control software 630 executing on appropriate hardware (typically one or more processors and associated program memory), and a key generation module 632 for creating new keys for new pairings between encryption devices. Uastly, volatile memory is provided in appropriate locations and forms in order to allow the basic operation of the software and hardware units mentioned above. Some scratch RAM is required for providing buffers, stacks, and other entities needed to run the virtual web server, DHCP and DNS servers.

While it is possible to use the device without any additional user interfaces or control schemes, it may in some cases be desired to provide ‘helper’ applications which can automate, simplify or conceal any or all of the operations mentioned above using standard (or otherwise) programming features in standard operating systems including, but not limited to, Uinux (and other UNIX(RTM) variations), Windows(RTM) and Apple(RTM) operating systems. Such applications (or other software components) can for example provide a user interface to provide configuration options for the encryption/processing device. The helper app may be provided elsewhere than on the host device (on a mobile phone, for example). Typically, however, the encryption device is controlled using only standard web browser features provided by the virtual web browser mentioned above. Typically advanced functionality is provided using Javascript applications. More advanced functionality can be provided via dedicated browser plug-ins, or standalone applications as mentioned above, but equally a more simple and universal control system can be provided using only static html pages and the like.

In a variant of either main embodiment, password protection and/or file system level encryption may be provided partly or wholly on the host device (or providing a duplicate system to that described above relating to the encryption/processing device, for example under the control of the browser application or helper app.

The configuration data and/or pairing structure (or any other persistent data) in the encryption device may be backed up as appropriate. Backup data is typically generated on request using the browser application. The backup data may even include cryptographic data. In that case (or otherwise), in order to avoid cryptographic compromise, the backup data is preferably encrypted using a main encryption key or similar. Accordingly, if the encryption/processing device fails, it can be fully restored by a combination of the main encryption key and the backup file, and the backup file can be stored as part of a normal backup process without the need for additional data security.

Figure 7 is a flow chart of the process of securely processing a file using the device of Figure 1. This flow chart essentially summarises the processes described above. In step S700, cryptographic data (including a cryptographic key) is received from a further encryption device via the aforementioned second interface (typically a USB host interface). In step S702, a command to encrypt or decrypt a file is received from the host device via the first interface (network interface). In step S704, a file (or files) is received from the host device via the same interface. Steps S702 and S704 are typically combined in a single http POST command. In step S706, the file (or files) is encrypted or decrypted using the cryptographic data received in step S700, and in step S708 the processed file(s) is transmitted to the host device via the network interface It will be appreciated that all of these steps may, where appropriate: be omitted, be provided independently, be provided in a different order or be supplemented by additional steps (as mentioned above or otherwise). Steps and features described as relating to encryption-specific devices may where appropriate also relate to more general processing devices, and vice versa.

Figure 8 is a schematic showing a reprogramming module attached to the device of Figure 1 or Figure 9. The processing (encryption) device 800 includes a communication interface 802, persistent memory 804 and processor 806. The reprogramming module includes a communication interface 852, processor 854 and configuration data store 856.

In the present embodiment, the communication interface is the second (USB host) interface, allowing the reprogramming module to be plugged into the encryption device while the encryption device is plugged into a host device. This obviates the need for either the encryption device or reprogramming module to have an internal power supply. Alternatives are discussed below. A separate power supply or power adaptor can of course be used.

When the reprogramming module 850 is connected to the processing device 800, the module 850 communicates 830 with the processor by any appropriate means and transmits at least a portion of the configuration data 856. The processor 806 is then caused to update the persistent memory 804 with configuration data 832 received from the reprogramming module. Validation and authentication (for example using public/private keys) is typically carried out. In the case of encryption devices, the reprogramming module transmits at least the main encryption key so as to create a clone of the original device it was associated with, although other or further configuration data may be transmitted as part of the process. Thus, if an original encryption device is lost, destroyed or non-functioning, a replacement encryption device can be created using the reprogramming module. In the preferred embodiment, the reprogramming module deletes part of all of the stored configuration data (and especially any encryption keys) so that further clones cannot be created without (if possible) explicitly reprogramming the key into the reprogramming module from the new clone (requiring the explicit confirmation of, and at the sole initiative of, the user).

In the present embodiment (such as via configuration files or control signals) the USB Communications Device Class (CDC) protocol is used to communicate between the reprogramming module 850 and the processing (encryption) device 800, but other protocols are possible, such as a mass storage protocol, TCP/IP, and so on. In terms of physical interface, the USB device interface is used for convenience, but any appropriate interface could be used, such as a serial port, Firewire connector, Ethernet connector, and so on. Wireless connections are also possible, via Wi-Fi, Bluetooth, and so on, but are not preferred, since they do not have many of the advantages already mentioned of the physical USB connection. Other protocols may be used, such as JTAG, SCSI, and so on, which have both physical and non-physical aspects. These protocols may equally be used for other processes and connections mentioned above. Communications between the device 800 and the reprogramming module 850 are encrypted, whether by virtue of the connection/communication protocols chosen, or using an extra layer of encryption by any appropriate means. This can avoid ‘man in the middle’ attacks.

Because of the potential to create unwanted decryption devices, preferably the reprogramming module is treated with the same degree of security as the encryption device itself (and preferably kept in a separate location). Though this imposes a need for physical security, it provides a means to reactivate an encryption device with an original key without having to involve any third parties or the manufacturer of either device (neither of which have access to, let alone store, any secret keys), which provides a key reset mechanism with overall considerable cryptographic security. The user and/or manufacturer can alternatively either destroy, not program with a key, or simply not produce a reprogramming module. This provides the greatest cryptographic security (only one key exists inside the encryption device initially) but if the original encryption device fails, the fries which it encrypted become forever unreadable.

In the preferred embodiment, the manufacturer provides both the encryption device and reprogramming module to a user, with both having a unique and synchronised main encryption key (amongst others), but the manufacturer does not store the key. This provides the greatest efficiency and simplicity for the manufacturer, but in a variant of the preferred embodiment, the main encryption key is generated by the encryption device at an appropriate point if it is detected that no such key yet exists. For example, at first power-on, if the encryption device detects no key present, then the key is generated and stored in the secure persistent memory within the encryption device. In one variant, that key can be transferred to a reprogramming module for later use by any appropriate means and at any appropriate time, for example via an intermediate host device and/or network connection.

In another variant, the main encryption key is generated at first power-on or similar, and is not ever transmitted outside the encryption device. By way of exception, if there is a reprogramming module connected to the encryption device at the time of key generation, then the key will be securely transferred to the reprogramming module, which can then be removed and stored for later use. Further variations are of course possible, balancing cryptographic security with ease of use. In this case, there may exist means (such as a configuration file or reset button) to cause a ‘factory reset’ of the encryption device so as to make it lose any existing main encryption key. Thus a user can be assured that none of the manufacturer or a previous user or owner of the device has any access to the main encryption key, for increased cryptographic security.

Figure 9 is a flow chart of the process of reprogramming the device of Figure 1 with the reprogramming module of Figure 8. The encryption device connects (S900) to the reprogramming device via a communication interface. In the present embodiment, a female USB interface provided on the encryption device receives a male USB interface provided on the reprogramming device, but other arrangements are possible, for example via an intermediary device which may effect any appropriate combination of male to female adaptors and/or supply power. In the present embodiment, the encryption device is simultaneously plugged into a host device or USB power source, but power may be supplied in or through either the encryption device or reprogramming module via any other appropriate means. Configuration fries are received (S902) from the reprogramming module via the communication interface. Then, as is customary, a disconnection request is received (S904), the module disconnects (S906), and then the configuration fries are processed (S908) and the configuration data in the processing/encryption device is updated (S910). The CDC protocol is typically used to communicate between the encryption device and the reprogramming device. Variants may use the mass storage device protocol, at least to initiate communications, but the CDC protocol is preferred because it is designed for two-way general data communication and is more flexible than the mass storage protocol.

The active modules and data flows in the encryption mode (described in more detail below) are shown in Figure 10. The USB physical device interface 1002, USB network device stack 1008, static web content 1012, virtual web server 1014, user metadata and configuration data 1020, encryption engine 1022, encryption key management module 1024, encryption keys 1026 and volatile/scratch memory 1034 are shown as before.

The active modules and data flows in the pairing master mode (described in more detail below) are shown in Figure 11. The USB physical host interface 1104, display 1106, user metadata and configuration data 1120, encryption keys 1126, USB host stack 1128, control software 1130, key generation module 1132 and volatile memory store 1134 are shown as before.

The active modules and data flows in the pairing slave mode (described in more detail below) are shown in Figure 12. The USB physical device interface 1202, display 1206, USB CDC device stack 1210, user metadata and configuration data store 1220, encryption keys 1226, control software 1230, and volatile/scratch memory 1234 are shown as before.

Figure 13 is an illustration of the device of Figure 1. The device 1300 is provided in the form of a ‘USB stick’ mass storage drive. It includes a main body portion 1302 enclosing the electronics and storage systems described above, a male USB connector 1304 for insertion into a USB port in a host device or USB hub attached thereto, and a female USB port 1306 for receiving another such device 1300 (for pairing, see below), or a reprogramming module (see below). Other arrangements of ports or package types are possible, and other features can be incorporated within the body portion 1302, such as security features (such as fingerprint scanners, other biometric inputs, or security keypad or buttons, and so on), status and/or progress indicators (such as UEDs, loudspeaker, and so on).

In an alternative embodiment, the device is provided in the form of an SD/MMC or other memory card. Or package types, sizes and protocols are of course possible.

Figure 14 is an illustration of the reprogramming module of Figure 12. The module 1400 includes a main body portion 1402 enclosing the electronics and storage systems mentioned above, and a male USB connector 1404 for connecting to an encryption device 1400 mentioned above. Other arrangements are possible, including different packaging types, shapes and sizes, and different port arrangements. A female USB port could be provided instead of the male USB connector, for example, which means that an additional power supply is needed to allow the reprogramming. This can either be by means of an additional male USB connector (for the sole purpose of obtaining power) or another power means such as internal (battery) or external (mains transformer) power supply. In the latter case, the extra inconvenience is offset by increased cryptographic security, as neither the encryption device nor the reprogramming module are physically or electronically connected to any other computing device.

Figure 15 is an illustration of an alternative connection arrangement of the encryption device and reprogramming module. The encryption device 1500 and reprogramming module 1550 interconnect via sockets 1574, 1576 in an intermediary device 1570. In this case, the encryption device may or may not have a second USB interface for pairing. The same intermediary device 1570 can be used also to pair two keys together without the need for a second interface on each. Either the intermediary device 1570 connects via a separate connector (not shown) to a host device as before, or only serves to provide power to the attached devices, for example using an internal power source (such as a battery) or via appropriate connection to external power. The intermediary device may alternatively have male connectors and the encryption device may be provided only with a single female USB connector, and so on.

Figure 16 is an illustration of a further alternative connection arrangement of the encryption device and reprogramming module. Previously the reprogramming module has used the same interface as is used for pairing and/or connecting to a host device, but in this variant, the encryption device 1600 is provided with the two USB sockets 1602, 1604 as before (one still being optional) and also an additional interface 1606 of a different type, to which a connector 1652 on the reprogramming module 1650 connects. As before, male may be switched with female as appropriate. In all cases, a separate wire/lead or other appropriate intermediary equipment may be used to connect the devices (whether for pairing or reprogramming) rather than relying on direct connections, though direct connections are of course preferred for reasons of cryptographic security.

The operation of the encryption device embodiment, and in particular the management of the encryption device from the host device perspective, and the use of a pairing process to allow the transmission of encrypted data to additional users and devices, will now be described in more detail in a more specific embodiment. It will be appreciated that any or all of the foregoing features may be added to or substituted for any other features of this specific embodiment, with any degree of generality. It is envisaged that all features described herein may be provided independently of each other and in any appropriate combination, providing that they are not technically incompatible. A discussion of two or more features in combination is not intended to imply that they are necessarily technically related or must be provided in that (or any other) combination.

In summary, hardware encryption devices are proposed that must be paired in order to transfer encrypted data between them. These devices can encrypt files for secure transmission to one or more recipient, or for general storage in the cloud. No data is stored on the devices. Custom software is not required to use them. The device features include: • The devices look and act much like USB memory sticks.

• Encryption/decryption of fdes is performed by a 'drag & drop' process within a web browser.

• Passwords are not required but can be used to further restrict device access.

• No fde data persists on the devices. Any data persistence required for device management is encrypted.

• No software is required on the user’s computer, besides standard web browser applications (which typically do not require any additional software to run). However, the USB hardware device performs the actual encryption and all key management.

• Multiple devices are initially paired by literal physical connection (highly secure): they are plugged together and communicate via an encrypted protocol.

• Where physical pairing is impractical, devices can be (initially) paired via a secure web service. This original pairing may then later be updated (peer-to-peer) to establish a relationship entirely independent of the web service.

• Multiple devices may be paired in multi-way associations (one-to-many or many-to-many) to facilitate secure transfer between groups.

• Devices may not be directly cloned.

• A separate 'recovery module' is provided with each device, which may, optionally, be initialised and then retained in a safe place in order to create a clone of the original device in the event of loss or failure.

As described above, the product is comprised of two components:

(1) The Encryption Device resembles a USB memory stick. This device performs all encryption/decryption and management operations in highly secure hardware, without requiring any drivers or other OS software. This device presents a “Virtual” network to the computer and provides a “Virtual” Webserver to serve a user application to a normal web browser. The web application is used to encrypt and decrypt files and also to manage contacts and groups. The Webserver server also provides a web-API for this application to use to encrypt files and manage contact info etc.

The Encryption Device does not persistently store any files. Any data required for device operation are encrypted, with cryptographic keys being stored in a highly-secure manner. At the rear of the device is a USB socket into which a second Encryption Device may be plugged for pairing via an encrypted protocol. The socket is also used to attach the supplied Recovery Module. An LED on the device provides a visual indication of its status.

(2) The Recovery Module (reprogramming module): in the event of loss or failure of the Encryption Device, the Recovery Module facilitates the generation of a clone device, such that previously encrypted files may later be accessed and device pairing restored. A highly secure matched recovery module is supplied with each encryption device. The module cannot be connected directly to, or read by, a computer as the protocol is encrypted. It is only intended for temporary connection to a replacement Encryption Device to create a clone by restoring the highly sensitive security credentials.

When connected to the original Encryption Device, the recovery module will take on the name of the encryption device to aid subsequent identification. In addition, a unique ID number is printed on each module. The Recovery Module must be stored separately in a secure location if a disaster recovery option is required; but some users may choose not to use the module.

Whilst the primary purpose of the encryption device is to facilitate secure data transfer between paired devices, the device may be used in a standalone fashion - to secure files prior to external storage (such as a cloud service). When used in this manner, it is imperative (for most users) that the Recovery Module is configured and securely retained, to guard against the possibility of being unable to decrypt files should the device be damaged or lost.

Each device and associated Recovery Module have a matched, highly-secure internal ID. In addition, each Encryption Device has a unique factory default name, which appears when it's plugged in to a computer. This name would ordinarily be changed to something more recognisable (just like any other drive).

Moving on, the encryption mode (with reference to Figure 10, mentioned above) is the main usage mode of the device and is entered simply by plugging the device into a computer. In this mode, the USB device will enumerate as a USB network device. Note, however, that in reality it is not connecting the device to a network, but the device is itself a “virtual network” running restricted services. This could be seen as analogous to the network connection to a virtual machine running web services. However, in this case the connection is physical (USB) it is just the services that are virtual.

On seeing a new network interface, the computer will usually issue a DHCP request, which will be responded to by the virtual DHCP server. A “special” address will be sent back to the computer. This address will be chosen from one of the IPv4 Private Address spaces (or similar from IPv6), that is from:

• 10.0. 0.0/8

• 172.16. 0.0/12

• 192.168. 0.0/16

The address is special in that it must not be the same as one on any existing LAN the main computer is already connected to. In some cases a mechanism is required to initially configure the device. The normal method is to generate a random IP address within the address spaces mentioned above. A new IP address is generated each time the device is plugged in. As an alternative method, the user can specify an IP address or IP address range to use, either via the host device or by entering it directly into the encryption device. In one variant, pressing a button or similar input device on the device when it is plugged in makes the device revert to a mass storage mode, where instead of presenting a virtual network, the device presents a virtual mass storage device. The user can then manually configure the device using text files and the like. Other schemes are of course possible. In the event of difficulty finding or configuring the device, the device can display its current address or any other relevant status information to the user via an embedded display of an appropriate type. Other standardized network location service may also be used.

Once the address is served the internal web server will also adopt an address in the same network segment. The device will also listen out for DNS queries on this interface and will reply to any that specify a “known special” domain ( E.g. encloak.me ) with the address of the Webserver.

At this point it is normally possible to enter the above domain into the computers web browser and be connected to the devices Virtual Web Server. When the user does this, the Webserver serves the encryption application webpages. These constitute all the usual components of a webpage, such as HTML, CSS, JavaScript, images, and so on.

When the user enters the domain into their browser, the user will be presented with a standard login page which will appear just as if the website had originated from any other website.

This application typically has all the same functionality as any other web site. However, there is a very important distinction is that the application and all data flows are only to and from the device.

In addition, the device provides a specialist encryption web API. This API allows:

• The application to select user encryption keys and to upload files to be encrypted with a selected key.

• The application to manage user meta-data associated with a given key. E.g. friendly name, tags, membership of groups, notes on the user etc.

• Notice that very importantly there is no API to set or read an encryption key. This happens in a totally unrelated way described elsewhere.

• After selecting a key and uploading a file the API provides a mechanism to download an encrypted version of this file. In a preferred embodiment, a download is started automatically as soon as a file starts uploading, allowing a streaming encryption or decryption that does not require local file storage on the encryption device. Besides providing greater security, this can remove any upper limit on the size of file that can be processed.

• Other API calls allow the usual web app management, such as user credential management password changes, and so on. As described above there is no API to create users and set encryption keys. The relationships between devices (users) are created by physically plugging two devices together and providing power as described later. When this is done the devices adopt different roles than above so differing blocks are active in the device, one becomes the master and one the slave.

In terms of pairing flow, with reference to Figures 11 and 12 mentioned above, data transfer over USB is used to update encryption keys and associated user data using an encrypted protocol.

The “Master” device will generate a random key for the pairing between the two devices. This key and the master device identity are shared using an encrypted protocol with the “Slave” device. The Slave in turn will respond with its identity. Both devices now can update their user store and encryption keys with information for this pairing. Once this has happened a message is displayed to indicate to the user that the pair may be unplugged.

Next time the user connects the device to a computer the new relationship will be visible in the web-app.

The usage of the web browser application will now be described, firstly with reference to encryption and decryption:

The user must first plug the USB encryption device into their computer. The user then points a web browser at the “Virtual web server” either by entering the IP address from the display or using the DNS name as described previously (e.g. http://encloak.me). The web browser will then show the Encloak application. If the user has previously set a password the user will see a login box and must enter the password before the application will open.

Unpaired Usage: whilst the primary purpose is to facilitate secure data transfer between paired devices, the device may be used in a standalone fashion - to secure files prior to external storage (such as a cloud service).

Figure 17A is a screenshot illustrating the unpaired encryption process.

To encrypt files for personal use (i.e. that can only be decrypted by this device) the user simply drags the files onto the encrypt icon in the “My Encloak” section. The file will upload and an automatic download of the encrypted file with a ‘.sd’ will be triggered.

The encrypted file(s) may then be copied or sent anywhere the user wants, safe in the knowledge that they may only be decrypted by the original device. In order to decrypt the file, it is simply dragged onto the decrypt icon in the sidebar. This will trigger an automatic download of the decrypted file. The encryption and decryption process is similar for pairs or groups of devices; each have their own encrypt icon in the relevant section.

Physical Pairing: To establish physical pairings between two devices the following process is followed:

1. Plug the device you wish to pair with (slave) into the back of the (master) device.

2. Plug the piggybacked pair into the computer, or a USB power supply

3. The progress of pairing is indicated on the device displays (or LEDs)

4. Unplug and separate the newly paired devices.

Each device may be paired (one-to-one) with multiple devices with a unique pairing record is created for each pairing. Numeric suffixes will automatically be added to avoid name clashes where required.

Once paired the paring will appear in the “Encloak Pairs” section. Files can be encrypted to send to this paired device by dragging them on to the encrypt icon. Files received from the paired device can be decrypted simply by dragging them onto the decrypt icon in the sidebar this will trigger an automatic download of the decrypted file.

Figure 17B is a screenshot illustrating the paired encryption process.

Grouping: grouping enables data to be sent securely between a selected set of Encryption Devices.

One-to-Many groups allow the group creator to encrypt a file that only a specified group of people (recipient members) can decode. This is a one-way communication.

Many-to-Many groups allow file(s) to be encoded by selected members - known as Originators’ - and be decrypted by all members. This is a two-way communication for privileged members.

Each Encryption Device may belong to multiple groups. The Encryption Device that created the group administers each individual group membership, and only the administration device needs to know who the members are.

In order to create a group, the administration device must have been paired with all group members’ devices. Pairing between other group members is not a pre-requisite.

The administrator should use the following process to establish and manage a group:

1. Pairings should be established with all proposed members’ Encryption Devices.

2. Within the ‘Groups’ section of the application “new group” can be selected and pairs may be added to the group. Figure 17C is a screenshot illustrating the group creation process. 3. Once all members have been added click “Create Group”. By default, a many-to-many grouping is created (all members will be able to decrypt and encrypt fdes for the group). An extra checkbox in the create group page can be added to choose the one-to-many option (all members will be able to decrypt files encrypted on the administration device but not encrypt files for the group).

4. The new group will be created and added to the list of groups. Figure 17D is a screenshot illustrating the completion of the group creation process.

5. The named group will contain a unique drop zone to encrypt files for transfer to other group members.

6. Groups may be deleted using the “delete group” button. All members of the defunct group can continue decrypt historic data; however, there would be no admin for the group from this point on.

Inviting members into the group: once the group has been created the creator can use the “download invite” button to obtain the invite file. This file needs to be sent to all group members. It is encrypted in such a way that only the members added to the group by the creator can decode the invite, no other Encloak devices or other software can decode it. It is therefore safe to send over email or similar.

On receiving an invite file, it is simply dragged onto the “decrypt file” drop-zone in the side bar, as with any other encrypted file. This action will then create an appropriately named group in the “groups” section of the application.

Figure 17E is a screenshot illustrating the group invite process.

It should be noted that group “members” have fewer options than the creator and cannot add members nor see who is in the group. (It is possible to add a checkbox to the “create page” to allow members to see the list of users if desired - but still not to manage adding members)

The following process should be used by group members to decode group files: files received from group members can be decrypted simply by dragging them onto the decrypt icon in the sidebar, this will trigger an automatic download of the decrypted file.

Backup and Recovery

For many users, loss or failure of the Encryption Device could lead to an undesirable situation where files cannot be decrypted. To address this, backup and recovery procedures enable an Encryption Device to be restored or cloned. These procedures are optional, because for other users it might be imperative that no recovery path exists.

The backup and restore section of the application allows users to download a backup of the current state of the device. The encrypted backup file contains all current pairing and group details together with device settings etc. It is encrypted with the devices unique security credentials and can thus only ever be restored to this device. The backup file should regularly be copied from the device and backed up elsewhere. In general it should not be kept in the same location as the Recovery Module.

To restore a backup the user simply drags it to the “restore backup” drop zone in the “backup & restore” section of the application.

Figure 17F is a screenshot illustrating the backup and restore process.

The backup and restore process can return the user to a given point in time. If, however, the original device is lost or damaged the backup cannot be restored as it is unique to the device it was created for. To address this problem the ‘Recovery Device’ is used.

Each Encryption Device creates unique security credentials (ID) the first time it is plugged in. These are stored in secure memory that cannot be accessed by the PC. Each device is supplied complete with a Recovery Module (as described above). This module is unique to the device it was supplied with and can be configured to hold the security credentials from the device it is supplied with. It must then be stored in a separate, secured location (or discarded, before use, if recovery is never desired).

If an Encryption device is lost or damaged then the first stage in recovery is to create a clone: that is, a device having the same set of credentials and name. This is a simple process:

1. Take another Encryption Device (it does not have to be new) and connect the original Recovery Module to it.

2. Plug it in to a computer (or any USB power source).

3. The Encryption Device will now sense that an alternative Recovery Module is attached and commence to clone itself from it. The LED will be lit when the process is complete.

4. Remove the Recovery Module from the device and connect the device to a computer. It should appear as a blank clone of the original device with the correct name. If the name does not match then this is an indication that a clone has been made from the wrong Recovery Module, and the process needs to be repeated.

5. The replacement Recovery Module may now be discarded (or possibly kept if it pertains to an older device that may need to be recovered at some point).

6. Records should be updated to associate the serial number of the original Recovery Module with the cloned Encryption Device and this module securely stored once more. Alternatively, they may wish to use the new recovery device to backup this newly restored key - thus keeping serial numbers in sync.

It should be noted that the cloning procedure will not recover any of the pairings and groups - this is done by restoring a backup as described above. It should also be noted that the recovery device is only writable by the encryption device it was shipped with. It can then be applied to any device new or old to create the clone. This is important because the user is assured that no one else has the ability to create clones without possession of the recovery device.

A password may be set in order to prevent the device being used by someone else, if, for example, it were lost. This is done in the “Settings” section of the application. On a device with a password set the application will not start until the password has been entered.

Whilst physical pairing provides ultimate security, there may be circumstances where this is not practical. In these cases, a secure method of remotely pairing Encryption Devices is provided. A secure web service can enable users to establish a temporary remote pairing between devices based upon some shared secret that has been communicated via a separate channel (say, a telephone call). Following this initial pairing, the users could then securely send each other replacement keys (generated by their devices as if physically connected) to pair permanently. By this method, the web service provider would have no knowledge of the actual keys used between remotely paired devices, or any means to decrypt data by a backdoor. Whilst the web service concept could be extended to directly manage multiple remote devices, this opens up the possibility of new attack vectors on security, so scrutiny is required.

There may be some options which the user wishes to set. For example, a device could be configured such that it cannot decrypt files it has encrypted: leaving a file which can only be decrypted by the other device in the pairing. These options can be set in the “settings” section of the application.

It is possible for a user to rename groups and pairs to make them easier to manage. The device keeps track of this ‘friendly’ name and is aware of whom the folder is actually paired with.

Figure 18 is a schematic of a network of interconnected host devices and associated encryption devices, illustrating one of several possible structures of paired devices. Host device 1800 and the associated encryption device 1802 are for example originators of a group message. The message is transmitted via an insecure network 1810 (such as the Internet) to host devices 1820, 1830 and their associated encryption devices 1822, 1832. The devices 1822, 1832 have been physically paired or temporarily paired over the network 1810, and are able to decrypt messages which were encrypted using the main encryption key of the encryption device 1802.

Two further embodiments will now be described, relating to a processing and/or encryption device with a concealed and/or restricted operating mode. A device is provided in a conventional or relatively convention form, such as device 1500 of Figure 15, which resembles an ordinary USB ‘stick’ drive. The device has the same physical components as the devices described above, except that (typically) the second interface is not provided. Therefore the device resembles the device of Figure 2 without block 210. The normal variant of the device uses the USB mass storage device, but can also use network protocols as described in detail above. Other communications and interface protocols may be used, as appropriate and technically possible. In use, the device plugs into a host device as described above, and presents a mass storage interface, such that to the host device and/or user it again resembles a USB ‘stick’ drive, allowing a user to move fries to and from a storage volume. The storage is preferably persistent and implemented using any appropriate method as used in actual USB ‘stick’ drives, SSD drives and the like. However, when the user provides appropriate authentication, the device switches to a concealed or alternative operating mode, in which additional or alternative functionality may be accessed. This can include encryption and/or decryption operations, but could relate to other types of processing, and/or may simply involve providing access to additional or alternative storage areas. Appropriate filing system level encryption may be provided as described above.

Figure 19 is a flow chart illustrating the operation of this embodiment relating to a processing device presenting multiple interfaces to a host device. In step SI 900, the device detects a connection with a host device (for example by physically plugging in the device or the host device, or electronically via any appropriate communications protocol, such as a USB (re)connection request). In step S1902 (and subsequently), a first (or conventional) interface (such as a USB mass storage interface) is provided to the host device. The device, correspondingly, operates in a first operating mode after the initial connection (or reconnection) is made. In step SI 904 the device receives authentication from the host device via the first interface (or otherwise) in any appropriate form. On validation of the authentication, in step SI 906 the device presents a second (alternative and/or new) interface to the host device. In this way, the device operates now in a second operating mode. At any point, the device can be disconnected (either physically or electronically) and will revert to the first interface/operating mode subsequently until re-authenticated. It will be appreciated that the authentication data may originate in the host device, or may originate elsewhere, for example via an Internet connection or via a secure or insecure link in the vicinity of the host device and/or processing device.

Figure 20 is a flow chart illustrating the operation of a further embodiment relating to an encryption device with a concealed encryption/decryption operating mode. In this more specific embodiment, in step S2000, the device receives a connection request from the host device via an interface (such as a USB interface or otherwise, as discussed elsewhere). In step S2002, the device connects to the host device via the interface in a conventional (or first) operating mode. The device may perform any appropriate processing in this convention (or first) operating mode, such as receiving and transmitting fries from a storage area, or processing received data on-the-fly for any appropriate purpose. In step S2004, the device receives authentication data from the host device via the interface. In step S2006, after validation of the authentication, the device reconnects to the host device via the interface (or otherwise) in an encryption/decryption mode, in which additional functionality (e.g. encryption/decryption processing) is provided to the host device relative to the first/convention operating mode. Thus, in step S2008, the device receives content data from the host device via the interface, and in step S2010, the device performs an encryption/decryption operation on the content data, as described above in any appropriate way. In step S2012, the device transmits the encrypted/decrypted content data to the host device via the interface (or otherwise).

More specifically, the interface is a USB interface, and the first operating mode is a USB mass storage mode. The authentication data is provided in the form of a text password in a text file (such as a .txt file on Windows systems), and must match a text password that has previously been submitted via any appropriate configuration method as described above. On validation of the password, the device causes a USB reconnection. On reconnection, the file system view is refreshed, and the device makes available either additional files and folders (as described above for carrying out the encryption/decryption steps) or any appropriate other features permitting additional functionality, and in particular allowing encryption/decryption operations to be carried out. In one variant, the file system presented to the host device does not change (or does not change significantly) but encryption/decryption feature are enabled having previously been disabled.

Thus, additional security by obfuscation may be provided, as the encryption (or processing) device appears not only physically but also electronically to be a conventional USB (or other) storage device.

In the foregoing embodiments, the encryption keys are symmetric, and the encryption methods may include (but are not limited to) DES, triple-DES, AES, and other symmetric encryption methods. Any appropriately long key length can be used to ensure ongoing cryptographic security. Methods such as PGP and other public/private key systems can be used for authentication or encryption purposes, either within the encryption devices, between the devices and attached host devices (for example in communication with a helper app on the host device), or between the encryption devices and remote devices, such as other encryption devices. Public/private key schemes can also be used in place of the symmetric key encryption schemes if appropriate or desired, though this would not be expected to result directly in better performance or security (since the key is never shared unencrypted over unsecured links).

It will be appreciated that further modifications may be made to the invention, where appropriate, within the spirit and scope of the claims.

Claims

1. An encryption device comprising: a first interface for connecting to a host device; a second interface for connecting to a further said encryption device, wherein the encryption device is configured: to communicate with the further encryption device via the second interface to facilitate the exchange of cryptographic data; to receive content data via the first interface from the host device using a network protocol; and to encrypt or decrypt the content data using said cryptographic data.

2. An encryption device according to Claim 1, wherein the encryption device is configured such that communication between the encryption device and the further encryption device is enabled when the two devices are brought into physical proximity of each other.

3. An encryption device according to Claim 1 or 2, wherein the second interface is operable to connect to the first interface of said further encryption device.

4. An encryption device according to any preceding claim, wherein the connection between the encryption device and the further encryption device establishes a master/slave relationship between the two devices.

5. An encryption device according to any preceding claim, wherein the second interface is a USB interface.

6. An encryption device according to any preceding claim, wherein the encryption device is configured to process the content data as a stream, such that at least a portion of the content data is encrypted or decrypted and transmitted back to the host device before all of the content data is received.

7. An encryption device according to any preceding claim, further configured to operate as a virtual network that is accessible by the host device via the first interface.

8. An encryption device according to Claim 7, further comprising a network initialisation module for causing the encryption device to be associated with at least one IP address.

9. An encryption device according to Claim 8, wherein the first interface is operable in a mass storage device mode which allows the host device to access a virtual filing system via the first interface.

10. An encryption device according to any one of Claims 7 to 9, further configured to provide a user interface to the user of the host device in the form of a web page served to the host device via the first interface.

11. An encryption device according to any one of Claims 7 to 10, wherein the encryption device is configured to provide a web API to the host device via the first interface, so as to allow commands to be sent to the encryption device by the host device, said commands preferably including at least one of: encryption or decryption operations, configuration operations, generation of cryptographic data, deletion of cryptographic data, exchange of cryptographic data, and authentication operations.

12. An encryption device according to any preceding claim, wherein said cryptographic data includes an encryption key, such that both the encryption device and further encryption device are able to encrypt and decrypt files using said encryption key.

13. An encryption device according to Claim 12, further comprising a key generator for generating a new encryption key for each pairing of encryption device and further encryption device.

14. An encryption device according to any preceding claim, configured to operate in one of at least three modes including encryption device, pairing device master, and pairing device slave.

15. An encryption device according to Claim 14, wherein the operating mode is selected in dependence on what is detected to be connected to the first and second interfaces.

16. An encryption device according to any preceding claim, further comprising non-persistent data storage powered by the connection between the encryption device and the host device, wherein removing the encryption device from the host device automatically causes the non-persistent data storage to be erased.

17. An encryption device according to any preceding claim, further configured to receive authentication data, wherein the encryption device is configured to validate the authentication data before encrypting or decrypting the content data.

18. An encryption device according to Claim 17, wherein the authentication data is at least one of: a password; pass key; PIN; public key; and cryptographic signature.

19. An encryption device according to any preceding claim, wherein the encryption device is configured to pair with the further encryption device when the further encryption device is connected via the second interface.

20. An encryption device according to Claim 19, further configured to create pairing data representing an association between the encryption device and the further encryption device, and to store said pairing data within the encryption device.

21. An encryption device according to Claim 19 or 20, further caused to receive a pairing request from a remote encryption device to which it is not physically connected, and to pair with the remote encryption device by exchanging messages with the remote encryption device.

22. An encryption device according to Claim 21, further caused to create a new pairing with the remote device on detection of the remote device being attached to the encryption device via a second interface.

23. An encryption device according to any one of Claims 19 to 22, wherein the encryption device is caused to be paired in a one-to-many fashion with a plurality of other encryption devices, whereby the encryption device is designated as an originator device and the plurality of other devices are designated as group devices.

24. An encryption device according to any one of Claims 19 to 22, wherein the encryption device is caused to be paired in a many-to-many fashion with a plurality of other devices, whereby all of the devices are designated as group devices.

25. An encryption device according to Claim 24, wherein a predetermined set of devices selected from the group devices are designated as originators, being capable of encrypting files that can be decrypted by all of the group devices.

26. An encryption device according to any preceding claim, further comprising a non-volatile data store including configuration data, and wherein the encryption device is further configured to: detect connection of a reprogramming module; to receive configuration data from the reprogramming module, and to replace any configuration data in the non-volatile data store with the received configuration data.

27. An encryption device according to any preceding claim, wherein the encryption device is configured to generate a backup data file for export, said backup data file including configuration data from the encryption device, and to encrypt the backup data file.

28. A processing device comprising: an interface for connecting to a host device, wherein the processing device is configured: to switch to a first operating mode on being connected to the host device via the interface; to receive authentication data from the host device via the interface while operating in the first operating mode; and to operate in a second operating mode after validating the authentication data.

29. A processing device according to Claim 28, wherein the first operating mode is a mass storage mode.

30. A processing device according to Claim 28 or 29, wherein the second operating mode is an encryption/decryption mode.

31. A processing device according to any one of Claims 28 to 30, wherein the processing device is further configured to validate the authentication data and to reconnect to the host device if the validation is successful.

32. An encryption device comprising: an interface for sending and receiving data between the encryption device and a host device; and a non-volatile storage module, wherein the encryption device is configured: on an initial connection to the host device, to provide the appearance of a mass storage device to the host device; to receive a file containing authentication data from the host device; and on validation of the authentication data in the received file, to present to the host device additional features relating to an encryption/decryption capability.

33. An encryption device according to Claim 32, wherein the authentication data is text within a text file.

34. An encryption device according to Claim 32 or 33, wherein the encryption device is further configured: to receive content data from the host device; to process the content data to perform a cryptographic operation on the data; and to transmit the transformed content data to the host device via the interface.