Patent Description:
Network-connected computers are difficult to keep secure. There are several reasons for this. For example, modern computers rely on their operating systems to keep the data within the computer safe. These operating systems are very complex pieces of software containing millions of lines of code. Such a large volume of code may have unintentional security leaks or extensions that intentionally break the security mechanisms. Alternatively, simpler, systemspecific operating systems may not have the sophistication necessary to prevent or inhibit malicious attacks.

As another example, many computer users do not have the training, experience, or time to set up and maintain a secure computer properly. Accordingly, even if a computer is well secured when it is set up, the way it is used may make it less secure. Users may use a work computer for non-work-related activities, such as browsing the web, playing games, reading email, using social media, and the like that expose the computer and its data to security breaches. Even worse, users may disable security features in order to make it easier to access these activities.

Another security issue is the use of poor procedures to grant a remote computer access to a secure network. Typical techniques such as username and password combinations are not very secure. The password may be transferred to the user via an unsecure method like email, or the user may be tricked into giving the password to a third party by a misleading message or phishing scam.

Accordingly, it is an object of the present invention to obviate or mitigate at least some of the above-mentioned disadvantages.

<CIT> describes a portable computer purportedly providing high level of security which comprises of two completely logically and electrically isolated computer modules within one tamper resistant enclosure.

A computer is described that has two distinct hardware domains. A general-purpose domain is provided for a general-purpose host computer. A secure domain is provided for secure computing. The hardware in the secure domain is secure by design and does not depend on the security of the underlying operating system and software applications, or the skill of the operator and network administrators.

Thus, in accordance with an aspect of an embodiment, there is provided a secure computer according to claim <NUM>. The security module may further comprise: key storage for storing at least one network encryption key; network identification (ID) storage for storing a network identifier; and a network encryption module configured to encrypt data communicated from the secure domain to the general-purpose domain and decrypt data communicated from the general-purpose domain to the secure domain using the at least one network encryption key.

In an embodiment, the key storage further stores at least one data encryption key. The security module further comprises a storage encryption module configured to encrypt data communicated from the secure domain to the general-purpose domain and decrypt data communicated from the general-purpose domain to the secure domain using the at least one network encryption key. The at least one network encryption key is used to encrypt and decrypt data communicated with the at least one networking device. The at least one storage encryption key is used to encrypt and decrypt data communicated with the non-volatile storage system. In accordance with another aspect, there is provided a security module according to claim <NUM>.

Embodiments of the inventions will be described by way of example only with reference to the following drawings in which:.

For convenience, like numerals refer to like structures in the drawings. Referring to <FIG>, an example of a secure computer in accordance with an embodiment of the invention is illustrated generally by numeral <NUM>. The secure computer system <NUM> comprises two distinct hardware domains. Specifically, a general-purpose domain <NUM> is provided for general-purpose computing. A secure domain <NUM> is provided for secure computing.

The two-domain system allows the computer to work in a way that people typically use a computer. That is, the general-purpose domain <NUM> provides users with an opportunity to perform non-secure operations, such as web browsing, games, movies, social media, and the like. The secure domain <NUM> facilitates operations that require access to secure information and private networks. The secure domain <NUM> is isolated from public networks by hardware interfaces, as will be described. The general-purpose domain <NUM> and the secure domain <NUM> do not share data. Thus, the likelihood of the non-secure operations performed by the general-purpose domain <NUM> affecting the secure domain <NUM> is greatly inhibited.

The secure domain <NUM> includes a power control module <NUM>, a secure processor <NUM>, and secure volatile memory <NUM>. The power control module <NUM> allows the secure domain <NUM> to be powered down. Powering down may reduce power consumption by the secure computer <NUM> when the secure domain <NUM> is not being used. Powering down also clears the secure volatile memory <NUM> when the secure domain <NUM> is not in use.

The general-purpose domain <NUM> includes a host processor <NUM>, host memory <NUM>, a non-volatile storage system <NUM>, and one or more networking devices <NUM>. The non-volatile storage system <NUM> includes storage devices such as a hard disk drive, a solid-state drive, or the like. The one or more networking devices include WiFi, Ethernet, Bluetooth, cellular technologies, and the like.

The secure domain <NUM> and the general-purpose domain <NUM> communicate with each other via a removable security module <NUM>. Peripheral devices <NUM> connect to the security module <NUM>, which controls the flow of peripheral information. In an embodiment, the peripheral devices <NUM> communicate with a peripheral hub <NUM>. The peripheral hub <NUM> is in communication with the security module <NUM>. Other devices that may be connected to the security module <NUM> include a video monitor <NUM> and an external authentication device <NUM>.

The secure domain <NUM> and general-purpose domain <NUM> operate independently of each other, and each have their own operating system. While the operating systems provide some level of security for both sides, the security module <NUM> is designed to provide the secure domain <NUM> with protection that is difficult, if not impossible, to be overridden by a software program, including the operating system, or misuse by the user of the secure computer <NUM>.

Referring to <FIG> the security module <NUM> is illustrated in greater detail. The security module <NUM> includes a context controller <NUM>, a video switch <NUM>, a secure peripheral device <NUM> interface, a host peripheral device interface <NUM>, a peripheral device filter <NUM>, key storage <NUM>, network identification (ID) storage <NUM>, password storage <NUM>, a storage encryption module <NUM>, a network encryption module <NUM>, and an authentication device interface <NUM>.

The context controller <NUM> controls the state of the security module <NUM>. The context controller <NUM> is accessible from the secure domain <NUM> via the secure peripheral device <NUM> and from the general-purpose domain <NUM> via the host peripheral device <NUM>. The context controller <NUM> can set the security module <NUM> into one of five states. Referring to <FIG>, a state diagram for the context controller is illustrated generally by numeral <NUM>. In a first state <NUM>, the secure domain <NUM> is powered down and locked. In a second state <NUM>, the secure domain <NUM> is powered up but locked and in reset. In a third state <NUM>, the secure domain <NUM> is powered up and running but inactive and locked. In a fourth state <NUM>, the secure domain <NUM> powered up and unlocked but inactive. In a fifth state <NUM>, the secure domain <NUM> is powered up, unlocked and active. The context controller <NUM> receives requests to change the state from both the secure domain <NUM> via the secure peripheral device <NUM> and from the general-purpose domain <NUM> via the host peripheral device <NUM>. In order to transition from a locked state (any of the first to third states <NUM> to <NUM>) to an unlocked state (either the fourth state <NUM> or the fifth state <NUM>), authentication will be required. The authentication will be described in detail later in the description. The context controller <NUM> also configures the secure peripheral device interface <NUM> and the peripheral device filter <NUM>, as will be described later.

The context controller <NUM> also sets the state of the video switch <NUM> to determine which domain has control of the monitor. When the secure domain <NUM> is active, the video switch <NUM> routes a video signal from the secure domain <NUM> to the monitor. Otherwise, the video switch <NUM> routes a video signal from the general-purpose domain <NUM> to the monitor.

The secure peripheral device <NUM> provides outside interface paths with the secure domain <NUM>. In an embodiment, the secure peripheral device interface <NUM> is a composite device with several interface components, including a context controller interface 206a, a storage device interface 206b, a network device interface 206c, a keyboard interface 206d, a pointer interface 206e, an audio device interface 206f, and a video device interface <NUM>. Accordingly, the only devices that the secure domain <NUM> will have access to are the context controller <NUM>, a storage device, a network device, a keyboard, a pointer, an audio device, and a video device.

The host peripheral device interface <NUM> provides an interface between the secure domain <NUM> and the general-purpose domain <NUM>. Similar to the secure peripheral device interface <NUM>, the host peripheral device interface <NUM> is a composite device with several interface components, including a context controller interface 208a, a secure storage interface 208b, and a secure network interface 208c. A first device driver USB1 on the general-purpose domain <NUM> is coupled with the host peripheral device interface <NUM> to provide the necessary support for storage and networking, as will be described.

The context controller <NUM> further sets the state of the peripheral device filter <NUM> to determine to which domain to send signals coming from the external peripheral devices <NUM>. When the secure domain <NUM> is not active, the peripheral device filter <NUM> does not do anything to the signals passing through it. That is, signals coming from the peripheral hub <NUM> are passed directly a second peripheral driver USB2 on the general-purpose domain <NUM>. When the secure domain <NUM> is active, the peripheral device filter <NUM> blocks keyboard, pointer, microphone, and videos signals from going to the general-purpose domain <NUM> and reroutes the data to the interface components 208a to 208f presented by the secure peripheral device interface <NUM>. The peripheral device filter <NUM> also combines output sound from both the general-purpose domain <NUM> and the secure domain <NUM> to a sound output endpoint, if it exists.

The key storage <NUM> stores security keys for the secure computer <NUM>. In the present embodiment, there are two security keys: a network security key; and a storage security key. As will be described, the key storage <NUM> is configured to receive the two security keys via an application program interface (API). However, the API cannot read the keys from the key storage <NUM>. In one example, the key storage <NUM> comprises a non-volatile programmable memory structure that can only be written to once. In another example, the key storage <NUM> comprises a volatile memory structure and a battery, which is used to hold the information.

The network ID storage <NUM> stores a network ID represented by a serial number. In an example, the serial number is a <NUM>-bit serial number. The network ID storage <NUM> is also programmed by the API. The network ID storage <NUM> may be a dedicated memory, or it can be a memory that is shared with other components of the security module <NUM>. Unlike the key storage <NUM>, the network ID can be read from the network ID storage <NUM> via the context controller <NUM>.

The password storage <NUM> stores authentication type, password length, and password for the authentication module. The password storage <NUM> comprises a non-volatile programmable memory structure which may or may not be re-writable. Alternatively, the password storage <NUM> comprises a volatile memory structure and a battery used to hold the information. The password storage <NUM> can be a standalone memory or it can be one a memory shared by other components of the security module <NUM>.

The storage encryption module <NUM> facilitates communication of secure storage data between the secure domain <NUM> and the general-purpose domain <NUM>. This allows the secure domain <NUM> to use the non-volatile storage system <NUM>. Storage data packets pass between the secure peripheral device interface <NUM> and the host peripheral device interface <NUM> via the storage encryption module <NUM>. This ensures that all outgoing storage data packets are encrypted, and all incoming storage data packets are decrypted and checked before being passed on. The keys for encryption and decryption are supplied by the key storage <NUM> via internal signals on the chip that cannot be probed. The storage encryption module <NUM> will only operate when enabled by the context controller <NUM>. Accordingly, when the storage encryption module <NUM> is disabled, the secure domain <NUM> is isolated from the non-volatile storage system <NUM>.

Similarly, the network encryption module <NUM> facilitates communication of secure network data between the secure domain <NUM> and the general-purpose domain <NUM>. This allows the secure domain <NUM> to communicate with remote computers. Network data packets pass between the secure peripheral device interface <NUM> and the host peripheral device interface <NUM> via the network encryption module <NUM>. This ensures that all outgoing network data packets are encrypted, and all incoming network data packets are decrypted and checked before being passed on. The keys for encryption and decryption are supplied by the key storage <NUM> via internal signals on the chip that cannot be probed. The network encryption module <NUM> will only operate when enabled by the context controller <NUM>. Accordingly, when the network encryption module <NUM> is disabled, the secure domain <NUM> is isolated from remote computers.

The context controller <NUM> is configured to inhibit a malicious change of context state by the host. Accordingly, the context controller <NUM> limits access to the unlocked security states. In an embodiment, four different types of authentication utilized, so the password storage <NUM> only needs a <NUM>-bit authentication type field to represent all four authentication types. As an example, the storage used for the password length is <NUM> bits and for password the itself is <NUM> bytes. The password is programmed into the password storage <NUM> via the context controller <NUM> and the secure peripheral device interface <NUM> and cannot be read back. If the password storage <NUM> is re-writable, the password can only be changed to a new password with a command to the context controller <NUM> that includes the current password.

A first authentication type, or secure system type, is represented by "<NUM>" in the authentication type field. The secure system type may be used when the secure computer <NUM> is physically located in a secure location, such as behind firewalls in a secure room. Alternatively, the secure system type can be used when the secure operating system of the secure computer <NUM> provides adequate authentication. When the authentication type field is set to the secure system type the context controller <NUM> will enable a change to the secure state when requested, without any additional hardware authentication.

A second authentication type, or a password protected type, is represented by "<NUM>" in the authentication type field. The password protected type may be used when the secure computer <NUM> is physically located outside of a secure location. When the authentication type field is set to the password protected type, upon receipt of a request to change to the secure state, the context controller <NUM> will configure the peripheral device filter <NUM> to pass all keyboard input to the context controller <NUM> and block the keyboard input from the general-purpose domain <NUM>. The context controller <NUM> will only complete the change to the secure state if it receives an input password at the keyboard that matches the password in the password storage <NUM>.

A third authentication type, or an external device protected type, is represented by "<NUM>" in the authentication type field. Similar to the password protected type, the external device protected type may be used when the secure computer <NUM> is physically located outside of a secure location. When the authentication type field is set to the external device protected type, upon receipt of a request to change to the secure state, the context controller <NUM> will request authentication from an external authentication device via the authentication device interface <NUM>. In an embodiment, the authentication device interface is a serial peripheral interface (SPI). The external authentication device may include a biometric scanner or other advanced authentication scheme as desired. The external authentication device is configured to communicate the password to the context controller <NUM> using the SPI <NUM> upon authentication of the user. The context controller <NUM> will only complete the change to the secure state if it receives an input password via the SPI <NUM> that matches the password in the password storage <NUM>.

A fourth authentication type, or set password type, is represented by "<NUM>" in the authentication type field. The set password type indicates that the password has not yet been programmed, and authentication will always return true. Accordingly, this will prompt drivers on the secure system to request the user set the password. Once the password is set, the authentication type field is set to the password protected type and is represented by "<NUM>", "<NUM>", or "<NUM>" in the authentication type field.

Referring to <FIG>, the network encryption module <NUM> is illustrated in greater detail. The network encryption module <NUM> includes a header extractor <NUM>, a checksum generator <NUM>, network data encryption unit <NUM>, a network data decryption unit <NUM>, and a checksum tester <NUM>. When the secure domain <NUM> wants to send a data packet to a remote location, it sends the data packet to the network device interface 206c on the secure peripheral device interface <NUM>, which communicates the data packet to the network encryption module <NUM>. The header extractor <NUM> extracts the header from the data packet. The checksum generator generates a checksum. The checksum is created using a hashing algorithm. In the present embodiment, the MD5 message-digest algorithm is used and the checksum is a <NUM>-bit MD5 message digest of the payload. The network data encryption unit <NUM> encrypts both the checksum and the payload. In the present embodiment, a <NUM>-bit AES encryption algorithm provides the encryption using the network security key from the key storage <NUM>. When disabled by the context controller <NUM>, the header extractor <NUM>, network encryption unit <NUM>, and the network decryption unit <NUM> will not forward any data.

The encrypted data and a copy of the unencrypted header are sent to the secure network interface 208c on the host peripheral device interface <NUM>. The host peripheral device interface <NUM> communicates the packet to the peripheral driver USB1 running on the general-purpose domain <NUM>. When the peripheral driver USB1 receives the network packet, it examines the header to determine which destination machine in its table is to receive the packet. As will be described, the secure domain <NUM> is constrained to communicate only with a small number of machines on the public network that contain matched security modules <NUM> that can be used to decode the IP packets. The peripheral driver USB1 then sends a User Datagram Protocol (UDP) packet to the destination machine with the network ID and the encrypted packet as its payload.

The peripheral driver USB1 keeps an open UDP port for receiving secure packets from other devices. In an embodiment, secure packets are identified based on the port at which they are received. When a secure packet is received, it is passed on to the network encryption module <NUM> via the network interface 208c on the host peripheral device interface <NUM>. The network encryption module <NUM> receives the packet and the network data decryption unit <NUM> decrypts the packet using the network security key from the key storage <NUM>. The checksum tester <NUM> regenerates the MD5 message digest from the payload and compares it to the checksum in the decrypted message. Since the checksum is based on the unencrypted data, only another computer with a matching network security key will be able to generate a checksum that matches the MD5 digest after decryption. If the MD5 message digest and the checksum match, then the packet is verified. Once the packet is verified, it is communicated to the secure domain <NUM> via the network device interface 206c on the secure peripheral device interface <NUM>. If the MD5 message digest and the checksum do not match, then the packet is discarded.

Referring to <FIG>, the storage encryption module <NUM> is illustrated in greater detail. The storage encryption module <NUM> comprises a protocol analyzer <NUM>, a storage encryption unit <NUM>, and a storage decryption unit <NUM>. The storage device interface 206b on the secure peripheral device interface <NUM> presents a standard peripheral mass storage class device to the secure domain <NUM>. When the secure processor <NUM> wants to access storage, it sends commands to the storage device interface 206b, which in turns communicates the commands to the storage encryption module <NUM>. The commands are processed by the protocol analyzer <NUM>, where they are decoded to determine whether encryption is required. If the command contains storage data, then the data is encrypted by the storage encryption unit <NUM>. Specifically, the storage encryption unit <NUM> uses the storage security key from the key storage <NUM> for encryption. In an embodiment, the data is encrypted using an AES-<NUM> encryption algorithm. Encrypted data is passed to the secure storage interface 208b of the host peripheral device interface <NUM>. Other messages such as command block wrappers are not encrypted as they do not contain user data. Such messages are passed to the secure storage interface 208b in plain text. As noted above, the storage encryption module <NUM> will only operate when enabled by the context controller <NUM>. Accordingly, when the storage encryption module <NUM> is disabled, the storage encryption unit <NUM> and storage decryption unit <NUM> modules will not forward any data.

The secure storage interface 208b communicates the received storage commands to the first peripheral driver USB1. The first peripheral driver USB1 is configured to open a file on the non-volatile storage system <NUM> that will act as a virtual disk for the secure domain <NUM>. The first peripheral driver USB1 receives commands from the secure storage interface 208b and performs the corresponding disk action on the virtual disk. Even though the user data is stored in the general-purpose domain <NUM>, all user data is encrypted. Thus, the host processor <NUM> will not be able to access any user data from the secure domain <NUM>.

Data read from the virtual disk passes from the first peripheral driver USB1 to the secure storage interface 208b and then to the storage encryption module <NUM>. The read data is processed by the protocol analyzer <NUM> to determine if the read data includes user data. If the read data does include user data, the user data is decrypted by the storage decryption unit <NUM>. Specifically, the storage decryption unit <NUM> uses the storage security key from the key storage <NUM> for decryption. In an embodiment, the data is decrypted using an AES-<NUM> encryption algorithm. Decrypted data is passed to the storage interface 206b of the secure peripheral device interface <NUM>. Other messages such as commands are not decrypted as they do not contain user data. Such messages are passed to the storage interface 206b in plain text.

Unlike network packet communication, there is no hardware checking the read data. If the read data were not written by the storage encryption module, they will come back scrambled and the secure processor <NUM> will likely be able to detect a corrupted file system. As will be described, since only the security module <NUM> has access to the storage encryption key, any data written to the secure disk file must come through the secure domain <NUM>.

Referring to <FIG>, the peripheral device filter <NUM> is illustrated in greater detail. The peripheral device filter <NUM> comprises a peripheral device input filter <NUM>, a peripheral device output filter <NUM>, and a peripheral protocol analyzer <NUM>. All of the peripheral devices plugged into the system are connected to the peripheral hub <NUM> and controlled from the general-purpose domain <NUM>. That is, the general-purpose domain <NUM> enumerates the peripheral devices and runs the peripheral bus signaling. After enumerating a peripheral device such as a keyboard, pointing device, audio, or video, for example, the general-purpose domain <NUM> configures the peripheral filter <NUM> to look for data for these devices on particular device/endpoint combinations.

When the secure state is inactive, the peripheral protocol analyzer <NUM> is inactive and the general-purpose domain has control of the peripherals and monitor output. Accordingly, the peripheral device input filter <NUM> and the peripheral device output filter <NUM> do nothing but pass-through peripheral device data. In contrast, when the secure state is active, then the peripheral protocol analyzer <NUM> is active and the data to and from the peripheral devices <NUM> is filtered by the peripheral device input filter <NUM> and the peripheral device output filter <NUM>. Specifically, the peripheral protocol analyzer <NUM> is configured to monitor for the device/endpoint packets from or to devices used by the secure domain <NUM>.

Thus, in an embodiment in which the secure domain <NUM> has access to a keyboard, a pointer, a video device, and one or more audio devices, the peripheral protocol analyzer <NUM> is configured with the device and endpoint information for each of the keyboard, pointer, video device, and audio device. The audio device may be an input audio, for example a microphone, or an output audio device, for example a speaker. For data input from the peripheral device <NUM>, the protocol analyzer configures the peripheral device input filter <NUM> accordingly. When data is received from the peripheral device, it is filtered by the peripheral device input filter <NUM> and routed to a corresponding one of the interface components of the secure peripheral device interface <NUM>. Null data is routed to the second peripheral port USB2 so that the general-purpose domain <NUM> does not interpret the missing data as an error with the peripheral device <NUM>. For data output to the peripheral device <NUM>, the protocol analyzer configures the peripheral device output filter <NUM> accordingly. When data is sent to the peripheral device <NUM>, it is filtered by the peripheral device output filter <NUM> and only data from a corresponding one of the interface components of the secure peripheral device interface <NUM> is sent to the device.

For example, consider a keyboard that sends keystrokes from device <NUM>, endpoint <NUM>. The peripheral protocol analyzer <NUM> detects when the general-purpose domain requests data from device <NUM>, endpoint <NUM> and set a "Keyboard EP" flag for the input peripheral filter <NUM>. When the data from the keyboard is received at the peripheral filter <NUM>, the input peripheral input filter <NUM> reroutes the data to the keyboard interface 206d of the secure peripheral device interface <NUM>. Since it is not desirable to communicate copies of this data to the general-purpose domain <NUM>, the input peripheral filter <NUM> replaces data received from the keyboard with null information that does not contain any data. This null information satisfies the request for data from the general-purpose domain <NUM>, without jeopardizing the security of the secure domain <NUM>. Similar procedures are run for the pointer, video, and audio input packets.

As noted throughout the specification, the security module <NUM> includes the storage encryption key and the network encryption key. To facilitate communication between different computers with a secure network, the security module <NUM> of each computer within the secure network is configured with the same network encryption key and the same network ID. Thus, data encrypted and transmitted from one computer within the secure network can be received and properly decrypted at another computer within the secure network.

Referring to <FIG>, an example of a secure network is illustrated by numeral <NUM>. The network includes a local network <NUM>, a plurality of remote computers <NUM>, and a communication network <NUM>. The local network <NUM> includes a local working space 602a and a local secure space 602b. The local working space 602a includes a plurality of local computers <NUM> and a firewall <NUM>. The local secure space 602b includes a plurality of secure servers <NUM> and a secure firewall <NUM>. The secure servers <NUM> and the secure firewall <NUM> are coupled via a secure local area network <NUM>. The local computers <NUM> may include local secure computers 608a, as described herein, and standard, state of the art computers 608b. Similarly, the remote computers <NUM> may include remote secure computers 604a, as described herein, and standard, state of the art computers (not shown).

Within the local working space 602a, the local computers <NUM> are coupled via a local area network <NUM>. For ease of explanation, each of the local secure computers 608a belongs to the same secure network, so each includes a security module <NUM> configured with the same network encryption key and the same network ID. Thus, data communicated from a secure domain <NUM> one of the local secure computers 608a can be received and properly decrypted by the secure domain of another one of the local secure computers 608a. Similarly, data communicated from the secure domain of one of the local secure computers 608a can be received and properly decrypted by the secure domain of one of the remote secure computers 604a. Yet further, the secure firewall <NUM> includes a security module <NUM> for each corresponding secure network. Thus, the secure domain of each of the local secure computers 608a and the remote secure computers 604a can also communicate with the secure servers <NUM> via the secure firewall <NUM>. In contrast, the standard local computers 608b and the standard remote computers will not be able to communicate with the secure domain <NUM> of any of the local or remote secure computers. Further, the standard local computers 608b and the standard remote computers will not be able to communicate with the secure servers <NUM>. Yet further, any external computer that manages to gain access through the firewall <NUM> will not be able to access to any data in the local secure space 602b or on the secure domains <NUM> of the secure computers 608a and 604a.

Referring to <FIG>, the secure firewall <NUM> is illustrated in greater detail. The secure firewall <NUM> comprises a network router <NUM>, a plurality of security modules 156a to 156n, and a secure router <NUM>. The network router <NUM> may be implemented in software on a general-purpose computer and couples the secure firewall <NUM> with the local area network and the communication network. The network router <NUM> is also coupled to the plurality of security modules 156a to 156n. The secure router <NUM> couples the secure firewall <NUM> with the secure local area network <NUM>. When the network router <NUM> receives UDP packets that are to be forwarded to the local secure space 602b, it recovers the network ID from the packet and forwards the packet to a corresponding of the corresponding security modules 156a to 156n, if it exists. The selected security module <NUM> decrypts the packet and confirms the checksum. If the checksum is confirmed, it is communicated from the secure router <NUM> to the local secure space 602b.

To communicate a packet from the local secure space 602b to one of secure computers 608a or 604a, the local secure server <NUM> sends a packet to the secure router <NUM>. The packet includes the address of the selected secure computer. The secure router <NUM> maintains a table correlating the address of the secure computers with their network ID. The security module <NUM> that has a network ID that matches the network ID of the selected secure computer is identified. The packet is communicated to the identified security module <NUM>, which encrypts the packet and forwards the encrypted packet to the network router <NUM>. The network router checks the address and builds a UDP packet for the secure device with the network number and encrypted packet.

The Basic Input/Output System (BIOS) of the secure domain <NUM> will initially perform a network boot from a machine in the secure space 602b before installing the operating system, applications, and data files required to run the secure domain <NUM>. Only files fetched from the secure space 602b will be able to be installed in the secure domain <NUM>. The only drivers required for the secure domain are for those devices provide by the secure peripheral device interface <NUM> of the security module <NUM>. Other drives for the external peripheral devices <NUM> will be installed on the general-purpose domain <NUM>.

Referring to <FIG>, a programming device used to program the security module <NUM> is illustrated generally by numeral <NUM>. The programming device <NUM> is made as simple as possible to minimize the chance of security holes. The programming device <NUM> comprises a programming unit <NUM>, a plurality of security module interfaces <NUM>, an entropy source <NUM>, and an activation switch <NUM>. The programming unit <NUM> is coupled with each of the plurality of security module interfaces <NUM>, the entropy source <NUM>, and the activation switch <NUM>. The entropy source <NUM> can be any device that generates unbiased random numbers that cannot be duplicated, such as a thermal noise source from a resistor, for example. Each of the plurality of security module interfaces <NUM> comprises a serial peripheral interface (SPI) for coupling to a security module <NUM>. Each of the plurality of security module interfaces <NUM> also includes a red and green light emitting diode (LED). The programming unit <NUM> comprises a small microcontroller with a programming application and no permanent storage. The activation switch <NUM> is coupled with the programming unit <NUM> to initiate the programming application.

When security modules <NUM> are plugged into the security module interfaces <NUM>, they are interrogated by the programming unit <NUM> to determine if they have been programmed. Although the application programming interface of the security module <NUM> will never reveal the value of the storage security key or the network security key, it will indicate whether the keys have been programmed. If the programming unit <NUM> determines that the security module <NUM> is available and not already programmed with keys, it will light the red LED of the associated security module interface <NUM>. When the desired number of security modules <NUM> have been plugged in and verified, the programming unit <NUM> is ready to program the security modules <NUM>. In response to a user pressing the activation switch <NUM>, the programming unit <NUM> generates the network security key, the network ID, and a plurality of storage security keys. The network security key and the network ID will be common to all of the security modules 156a to 156n. The storage security key will be unique to each of the security modules 156a to 156n. The storage security key, the network security key and the network ID are sent to each security module <NUM> a total of five times. The application programming interface on the program module <NUM> reviews the storage security key, the network security key and the network ID to make sure that all five received versions are the same. If they are the same, the application program interface programs the storage security key, the network security key and the network ID before sending an acknowledgement to the programming unit <NUM>. The programming unit <NUM> will then switch the LED from red to green to indicate success. If the storage security key, the network security key and the network ID are not the same, then an acknowledgement is not sent. If the acknowledgement is not received within a predefine time period, the programming unit <NUM> will retry to program the security modules <NUM>. Once all the security modules 156a to 156n are programmed, the programming unit <NUM> erases its memory and gets set for the next programming cycle. At this point the only copies of the storage security key, the network security key and the network ID are stored inside the security modules. The storage security key and the network security key cannot be read out.

The above described computer system that provides a general-purpose domain for general-purpose host computer functionality and a secure domain for secure computing. The hardware in the secure domain is secure by design and does not depend on the security of the underlying operating system and software applications, or the skill of the operator and network administrators.

It will be apparent to those skilled in the art that various modifications and variations can be made to the disclosed secure computer without departing from the scope of the disclosure. Other embodiments of the secure computer will be apparent to those skilled in the art from consideration of the specification and implementation of the secure computer in a secure network disclosed herein. For example, although the secure computer is disclosed as switching control of the monitor between the secure domain <NUM> and the general-purpose domain <NUM>, in an alternative embodiment, a secure window and a general-purpose window are presented on the monitor. When the secure window is active, the secure domain <NUM> is active. When the general-purpose window is active, the secure domain <NUM> is inactive.

As another example, although the secure computer is described as using symmetric key cryptography, public-key cryptography can also be used. In such a case, both public encryption keys and private decryption keys are programmed in the key storage <NUM>. However, to enhance security, the public key need not actually be made available to the public.

As yet another example, secure computers in a first secure network can use the secure space 602b to communicate with secure computers in a second secure network. In an embodiment, the secure computers in the first network can transmit data, along with a request to relay that data, to one of the secure servers <NUM> using the network encryption key associated with the first secure network. The secure firewall <NUM> decrypts the message and the request and forward them to the appropriate secure server <NUM>. The secure server <NUM> interprets the request and verifies that the requesting computer has permission to communicate with secure computers in the second secure network. If the user is verified, the secure server <NUM> communicates the data to the secure firewall <NUM> to relay to the secure computer in the second secure network. The secure firewall <NUM> uses the network encryption key associated with the second secure network to encrypt the data. The encrypted data is then relayed to the destination secure computer.

As yet another example, the secure computer may need to pass through a plurality of nested firewalls to reach a highly secure destination. For example, a first layer firewall would be accessible by any member of an organization. A second layer firewall would follow the first layer firewall and would be accessible only to a limited number of people within the organization. A third layer firewall would follow the second layer firewall and would be accessible only to a few of the limited number of people within the organization. To reach the inner, more secure layers, the secure computer requires multiple security modules <NUM>. For example, to reach the most secure, third layer firewall, the secure domain <NUM> first uses a security module associated with the third layer firewall to encrypt the data. The secure computer then uses a security module associated with the second layer firewall to encrypt the previously encrypted data. Finally, the secure computer then uses a security module associated with the third layer firewall to encrypt the twice previously encrypted data. The triple encrypted data is then passed to the general-purpose domain <NUM> to be communicated through the network. Once received at the destination, the nested packet works its way through each of the three firewall layers, with each firewall layer removing one of the nested encryption layers until the original, clear data is communicated on the innermost domain. As will be appreciated, data destined for a middle domain need not pass the third layer firewall. Thus, such data only needs to be encrypted twice to pass the first two layers. Similarly, data destined for an outer domain need not pass the second layer firewall or the third layer firewall. Thus, such data only needs to be encrypted one to pass the first layer firewall.

As will be appreciated, at present, the standard for the peripheral devices <NUM> is Universal Serial Bus (USB). However, other known peripheral bus protocols, such as Inter-Integrated Circuit (I2C), Serial Peripheral Interface (SPI), and other, proprietary, peripheral bus protocols may also be used.

The term computer, as used herein, is intended to have it well-known, broad definition. That is, a machine that can be instructed to carry out sequences of arithmetic or logical operations automatically via programming. As will be appreciated by a person skilled in the art, this definition encompasses personal computing devices such as desktop computers, laptop or notebook computers, smartphones, tablets, and the like. This definition also encompasses smart devices such as security cameras, remote locks, sensors, control systems, and the like, as well as embedded computers.

Claim 1:
A secure computer comprising:
a general-purpose domain (<NUM>) configured to provide general-purpose computing, the general-purpose domain (<NUM>) comprising: a host processor (<NUM>), a non-volatile storage system (<NUM>), and at least one networking device (<NUM>);
a secure domain (<NUM>) configured to provide secure computing, the secure domain (<NUM>) comprising: a secure processor (<NUM>); and
a security module (<NUM>) communicatively coupled to and between the general-purpose domain (<NUM>) and the secure domain (<NUM>) using a peripheral bus protocol, the security module (<NUM>) comprising:
a storage encryption module (<NUM>) configured to facilitate secure storage data transmission between the general-purpose domain (<NUM>) and the secure domain (<NUM>) via the peripheral bus protocol, thereby providing the secure domain (<NUM>) with secure access to the non-volatile storage system (<NUM>) of the general-purpose domain (<NUM>), wherein the storage encryption module (<NUM>) is configured to decrypt all incoming storage data packets and encrypt all outgoing storage data packets that are passed between the general-purpose domain (<NUM>) and the secure domain (<NUM>) and that are communicated with the non-volatile storage system (<NUM>);
a network encryption module (<NUM>) configured to facilitate secure network data transmission between the general-purpose domain (<NUM>) and the secure domain (<NUM>) with secure access to the at least one networking device (<NUM>) of the general-purpose domain (<NUM>), wherein the network encryption module (<NUM>) is configured to decrypt all incoming network data packets and encrypt all outgoing network data packets that are passed between the general-purpose domain (<NUM>) and the secure domain (<NUM>) and that are communicated with the at least one networking device (<NUM>); and
a context controller (<NUM>) configured to enable and disable the storage encryption module (<NUM>) and to enable and disable the network encryption module (<NUM>).