Security-enhanced computer systems and methods

In general, the invention provides a computer architecture designed for enhanced data security. In embodiments, the architecture comprises two sub-systems, each with their own processing units and memories, and a defined set of interfaces that interconnect the two sub-systems and the external world. One sub-system is designed to provide a familiar environment for running computer applications. The other sub-system is designed to provide a secure bridge between the first sub-system and users via input and output devices.

FIELD OF THE INVENTION

The present invention relates generally to computers, and in particular to computers used in corporations and government organizations where information security is of elevated importance.

BACKGROUND OF THE INVENTION

Traditionally, personal and corporate data security functions are implemented in the form of add-on software modules on top of a hardware architecture essentially identical to consumer-grade personal computers, which are designed for affordability. Sometimes security-specific add-on hardware modules are also implemented, e.g. for the purpose of authenticating the user more securely (e.g. smart cards, biometrics). But even in these cases the bulk of the security functionality is implemented traditionally as add-on software components that are sometimes integrated into the operating system but mostly reside in memory and are executed just like any other software application.

A significant problem with this traditional approach is that when the security functionality is implemented in software, it may be compromised in a number of different ways. In the normal course of operating a computer, the user occasionally adds or modifies some software components—this is the ability to add and replace software components that gives the general purpose computing architecture its flexibility and usability in a wide variety of tasks and assignment. It is this same ability to modify or add software modules that opens a window of opportunity for an attacker to compromise the security of the computer system.

When a new software component is introduced, there is a risk that it includes a functionality intended for effecting an attack, or that it includes a programming error that could be exploited externally to facilitate an attack. Also, because the security software is distributed and installed similarly to application software, it is also vulnerable to the same risks.

In a traditional general-purpose computer the entire random-access memory (RAM) is organized in a single large uniform bank that can be physically accessed by processor, or by all processors if the system contains a plurality of processors. The uniformity of memory access provides the most flexibility in the usage of RAM, which is one of the critical resources in the computer, and leads to the most optimal utilization of RAM by the operating system and application software. While effective for cost efficiency, the uniform RAM architecture also means that programs running concurrently can access each other's memory regions, or the memory occupied by the operating system or its components. As such, this feature of the uniform RAM architecture has been the most used vehicle of compromising a computer's security.

Modern computer systems also employ a mechanism called “virtual memory”, where a hardware component embedded in the processor called a memory management unit (“MMU”) performs a function of memory address translation. The addition of virtual memory allows the RAM to be partitioned into sections, each section dedicated to a certain software component or a group thereof. Virtual memory also prevents inadvertent access to the memory that belongs to a different software component or the operating system. The virtual memory mechanism has proven quite effective to prevent erroneous software behavior from impacting the stability of the system as a whole, but it was not intended to prevent malicious sabotage, and in every operating system there is a documented mechanism to circumvent the protections furnished by the MMU meant for diagnostic purposes. These mechanism are often exploited to compromise the security of the computer and the data contained therein.

In one conventional approach to achieve an elevated level of security, some portion of the security mechanism is implemented in a separate and dedicated hardware module, which is designed with additional tamper-resistant features and thereby adds a difficulty level to the potential intruder. Perhaps one of the earliest non-classified examples of hardware-enhanced computer security features was the IBM HSM (Hardware Security Module), which was a small stand-alone computer with its own memory and storage subsystem which was built into a rugged enclosure designed similarly to an office safe. The Personal Identification Numbers of bank cards were stored in the HSM such that even the bank employees did not have access to these codes in clear-text form. When a automated teller machine needed to verify the identify of a card holder, a cryptographic challenge-response sequence was initiated such that the PIN was never transmitted verbatim over the communication links, and the HSM performed the verification process securely.

The smart-card approach user-authentication mechanism of the global standard cellular phone system (based on GSM) has a similar mechanism, except that the hardware security module is miniaturized to the size of a finger nail, and each user is furnished with such a device. The SIM card construction makes it difficult to disassemble without damaging the embedded memory chip.

Another conventional approach is the Truster Platform Module that is built into some of the personal computers presently manufactured. The TPM is somewhat similar to a SIM card in that it is a small memory chip that has restricted access, and contains some security-related identification information and some encryption keys. The pivotal idea of the TPM is to prevent an attacker from modifying this identification information to falsely identify the computer or its user and thus circumvent the security mechanisms present elsewhere in the system. Its down side however is that the keys and numbers contained in the TPM are just one part of the protection, while the rest of the parts are implemented traditionally in the operating system and application software components. Thus the TPM does provide an additional layer of protection, making it impossible to modified some key security-related information token by an unauthorized user. However, the TPM leaves significant vulnerabilities in the other parts of the system software and its communications that can be exploited for a successful attack.

Accordingly, a need remains for improved approaches to computer system security.

SUMMARY OF THE INVENTION

The present invention relates to a computer architecture designed for enhanced data security. In embodiments, the architecture comprises two sub-systems, each with their own processing units and memories, and a clearly defined set of interfaces that interconnect the two sub-systems and the external world.

According to certain aspects, one of the two subsystems is built around a popular processor architecture, such as the x86 which runs the majority of today's personal computers, and is designated as the application-processor subsystem. This processor architecture is chosen for the wide variety of application software and operating systems that are available for it, and aims to maximize the flexibility of the user to install application software of their choice. Unlike a conventional personal computer that is also designed around the x86 architecture, this application-processor has all its peripheral connections routed to the other subsystem instead of to the actual external or internal peripherals. Accordingly, while the software that could run on the x86 is virtually unrestricted, external access to this software or its data is strictly controlled by a dedicated system-processor sub-system which enforces the protections necessary to keep these applications and their data safe.

According to certain additional aspects, the other sub-system, designated as the system-processor, is essentially an embedded system. It runs an embedded software system furnished along with the processor, and can not be modified by the end-user of the computer under any circumstances, and should be instead referred to as firmware. Being an embedded system, the specifics of the processor architecture of the system-processor module are of no consequence, as neither the end-user nor any third party developer is allowed to write or modify any of its software components. The system-processor essentially serves as a “bridge” between the inherently insecure application software environment running on its own hardware subsystem and the external world. In embodiments, the system-processor has two ports for each type of peripheral connection, one connected to an actual peripheral and the other to the application-processor sub-system. The firmware along with the system-processor hardware emulates each type of peripheral device for the benefit of the application-processor subsystem, while enforcing a set of rules and mechanisms appropriate for each of the supported types of peripherals, and necessary to maintain the highest level of protection for the application software and its data at all times. All the internal and external peripherals are connected to the system-processor and are used by the peripheral emulation firmware functionality.

In accordance with these and other aspects, a computer system according to embodiments of the invention includes a first subsystem including a first processor configured to run applications; a second subsystem including a second separate processor configured to run security firmware; and peripherals connected to the second subsystem, wherein access to the peripherals by the applications is controlled by the security firmware running on the second processor which emulates corresponding peripheral connections of the first subsystem.

In further accordance with these and other aspects, a method of securing a computer system according to embodiments of the invention includes configuring a first subsystem of the computer system including a first processor to run applications; configuring a second subsystem of the computer system including a second separate processor to run security firmware; connecting peripherals to the second subsystem; and controlling access to the peripherals by the applications using the security firmware running on the second processor which emulates corresponding peripheral connections of the first subsystem.

In additional furtherance of these and other aspects, a system according to embodiments of the invention includes a stand-alone computer system including: a first subsystem including a first processor configured to run applications, and a second subsystem including a second separate processor configured to run security firmware; and a secure intranet hosted by an organization that controls the stand-alone computer system, wherein access to the secure intranet by the applications is controlled by the security firmware running on the second processor which emulates a corresponding physical network connection of the first subsystem.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

The present invention will now be described in detail with reference to the drawings, which are provided as illustrative examples of the invention so as to enable those skilled in the art to practice the invention. Notably, the figures and examples below are not meant to limit the scope of the present invention to a single embodiment, but other embodiments are possible by way of interchange of some or all of the described or illustrated elements. Moreover, where certain elements of the present invention can be partially or fully implemented using known components, only those portions of such known components that are necessary for an understanding of the present invention will be described, and detailed descriptions of other portions of such known components will be omitted so as not to obscure the invention. Embodiments described as being implemented in software should not be limited thereto, but can include embodiments implemented in hardware, or combinations of software and hardware, and vice-versa, as will be apparent to those skilled in the art, unless otherwise specified herein. In the present specification, an embodiment showing a singular component should not be considered limiting; rather, the invention is intended to encompass other embodiments including a plurality of the same component, and vice-versa, unless explicitly stated otherwise herein. Moreover, applicants do not intend for any term in the specification or claims to be ascribed an uncommon or special meaning unless explicitly set forth as such. Further, the present invention encompasses present and future known equivalents to the known components referred to herein by way of illustration.

In general, the invention provides a computer architecture designed for enhanced data security. In embodiments, the architecture comprises two sub-systems, each with their own processing units and memories, and a defined set of interfaces that interconnect the two sub-systems and the external world. One sub-system is designed to provide a familiar environment for running computer applications. The other sub-system is designed to provide a secure bridge between the first sub-system and users via input and output devices.

FIG. 1is a block diagram illustrating an example system architecture100according to aspects of the invention.

As shown inFIG. 1, one of the two subsystems is preferably built around a popular microprocessor architecture, such as the x86 which runs the majority of today's personal computers, which is designated as the application-processor subsystem102. This architecture is chosen for the wide variety of application software and operating systems that are available for it, and aims to maximize the flexibility of the user to install application software of their choice. Unlike a conventional personal computer that is also designed around the x86 architecture, this application-processor has all its peripheral connections routed to the other subsystem instead of to actual external or internal peripherals. So while the software that could run on the x86 is virtually unrestricted, external access to this software or its data is strictly controlled by a dedicated system-processor sub-system which enforces the protections necessary to keep these applications and their data safe.

This other sub-system, system-processor104, is preferably an embedded system. As such, it runs a designated software system furnished together with the processor, and can not be modified by the end-user of the computer under any circumstances, and should be instead referred to as firmware. Being an embedded system, the specifics of the processor architecture of the system-processor module are of no consequence, as neither the end-user nor any third party developer is permitted to write or modify any of its software components. The system-processor104essentially serves as a “bridge” between the inherently insecure application software environment running on its own hardware subsystem102and the external world.

Peripherals106typically include any type of device that provides an interface between the functionalities of system100and a computer user. Such devices can include output devices such as displays, speakers, printers, etc. and input devices such as keyboards, mice, touchpads, touchscreens, etc. The number and type of peripherals106can depend on the particular form factor of a device that houses application processor102and104. For example, in embodiments of the invention where the form factor is that of a conventional desktop computer, the peripherals106can include a display, a keyboard and a mouse, which are externally attached. Where the form factor is that of a conventional notebook computer, the peripherals106can include an integrated display, keyboard and touchpad. Where the form factor is that of a tablet computer or smart phone, the peripherals106can include an integrated display/touchscreen. It should be noted that peripherals106between different types of form factors for system100are not necessarily mutually exclusive, nor are they constant over time. For example, many conventional touchpad computer systems may be operated with optional separate keyboards and mice (e.g. connected through USB or Bluetooth). Likewise, many conventional desktop computer systems may be operated with optional touchscreens or voice-command devices.

In some embodiments, system100is designed to appear as a normal computer system, with the additional security features of system processor102embedded therein and not readily apparent to the casual observer. For example, system100can appear as a normal laptop computer with a conventional folding display and built-in keyboard, speakers and pointing device. In other possible embodiments, system processor102and application processor104are housed separately, either together with, or further separately from certain of peripherals106. However, it should be noted that for additional security aspects, processor sub-systems102and104are preferably integrated as much as possible, within the same enclosure and even on the same circuit board, and perhaps even as two separate processor cores on the same ASIC, SOC or FPGA. For example, the present inventors recognize that any type of exposed interconnections between these subsystems may potentially be exploited by an attacker. Accordingly, such interconnections are preferably made as difficult to access as possible (e.g. within the same integrated circuit and/or circuit board). As for the peripheral106connections to the system processor104, these can be either integral or separate according to the particular form factor of system100.

It should be noted that it is not necessary for all peripherals of any given system100to have access controlled by system processor104. Typically, however, at least the most useful or important peripherals of the system100are controlled, such as all input devices such as keyboards and mice, as well as most useful output devices such as displays. In this regard, the present inventors recognize that such peripherals typically include those input/output devices through which a particular implementation of application processor102is able to interface with a human operator or with other computers (e.g. via a network or other communications link) to control or access its operations and/or data. As such, all peripherals106that substantively expose the data and operations of application processor102to the external world are preferably routed through the system processor104. Accordingly, the term “peripheral” should be construed as encompassing both an actual peripheral and a connection (e.g. port) that connects a processor to a peripheral. The system processor104thus preferably intercepts communications between peripherals106and processor102at the most secure physical point in these communications. In other words, the application processor102does not have any important peripherals connected to it or its operating environment directly or through connections that are exposed or accessible externally; rather these connections are routed through or controlled by the system processor104.

It should be further noted that, perhaps depending on the type, peripherals106can be internal or external to a device that commonly houses application processor102and system processor104. One preferred embodiment of a system100that will be described in more detail below, but which should not be considered limiting, is that of a device in the form factor of a desktop or notebook computer. In such an embodiment, peripherals106include an attached display, keyboard and pointing device (e.g. touchpad and/or stick mouse), and internal speakers and wireless modem (e.g. 802.11a/b/g/n). Peripherals106in such an embodiment can further include any input or output external device that is attached via a corresponding jack on the system100, including conventional jacks or interfaces such as USB, RJ-45, Firewire, eSATA, VGA, HDMI, DVI, DisplayPort and MiniDisplayPort. Those skilled in the art will recognize how to implement the invention with fewer or additional types of interfaces and/or peripherals106after being taught by the present examples.

The system-processor104typically has two connections for each type of peripheral connection, one to an actual peripheral106and the other to the application-processor sub-system102. As will be described in more detail below, the firmware provided with the system-processor104hardware emulates each type of peripheral device106that is actually connected to system processor104for the benefit of the application-processor subsystem102. The firmware further preferably enforces a set of rules and mechanisms that are both appropriate for each of the supported types of peripherals, and necessary to maintain the highest level of protection for the application software and its data at all times. In embodiments, all the internal and external peripherals106are connected to the system-processor104and are used by the peripheral emulation firmware functionality.

Although not shown in detail inFIG. 1, it should be noted that application processor102and system controller104can further include memories, memory and I/O addressing space, operating system software, application software, graphics processors, sound processors and processor buses. For example, where the form factor of system100is a desktop or notebook computer, system100can include conventional personal computer components such as a PCI bus, RAM and ROM memory storing an operating system such as Windows 7, and associated BIOS software and application software such as Windows Office. System100can further include such conventional personal computer components such as a XGA graphics processor (e.g. Intel x86, AMD integrated graphics or external processors such as those provided by nVidia), a 5.1 audio processor, USB inputs and outputs, Ethernet interfaces, serial/parallel interfaces, etc. To the extent the control of such components by system processor104and their interoperation with application processor102is an aspect of the invention, these details will be provided below. However, further additional implementation details of application processor102will be omitted for sake of clarity of the invention. Moreover, those skilled in the art will appreciate various alternative embodiments of processor102for other types of form factors such as pad computers and smart phones after being taught by these examples.

Example embodiments of system-processor sub-system104will now be described in terms of examples of the peripheral types that it emulates and supports, plus a variety of auxiliary functions aimed to support system-level operational logic and security.

In example embodiments such as that illustrated in connection withFIG. 2, the system100, system processor204is coupled to application processor202, as well as to keyboard206, video mux208and firmware214. Application processor202can correspond to application processor102as described above. System processor204can be implemented by any conventional, proprietary or future processor such as an x86 processor, custom ASIC or SOC, ARM processor, etc. Firmware214is preferably implemented in ROM (e.g. Flash) that is dedicated to system processor204and includes all operating system and application software needed to control system processor204and the functionality thereof as described herein and below. Those skilled in the art will recognize that the language and structure of the software comprising firmware214can depend on the type of processor used to implement processor204and/or the operating system used. Those skilled in the art will further understand how to implement software and firmware implementing the functionality of processor204, perhaps together with conventional operating systems and applications, after being taught by the foregoing descriptions. It should be further noted that system processor204can include additional functions and/or components not shown such as processor buses, RAM/application memory, graphics processor functionality, input/output ports, etc.

As shown, video multiplexor208includes at least two inputs216,218and one output220. The output220of the video multiplexor is connected to the computer display210. One of the inputs218of the video multiplexor208is connected to a video-graphic module internal to the system-processor sub-system204, which is used to communicate operational and security related information and interaction with the end-user, as well as for the purpose of any application that is embedded in the system-processor204firmware. The other input216of the video multiplexor208is connected to the output of the video-graphic module of the application processor sub-system202, so that the graphics generated by applications are directed to the multiplexor208, and through the multiplexor conditionally to the display monitor210under the control of system processor204and control signal222. In embodiments, the multiplexor208scales the resolution and adjusts the frame rate of the video inputs such that they are appropriate for the display mode desired and the actual resolution and frame rate of the display monitor210. Depending on the operational and security mode of the system as determined by system processor204, the application graphics output216may be entirely blocked from the display, displayed as a small window on the monitor210, or passed through to the full size of the display monitor210. The graphics218of the system-processor204itself can also be conditionally routed to the monitor210in a variety of ways dependent on the operational and security mode of operation.

In embodiments, during initial system start-up and authentication, video mux208, under control of system processor204via signal222, causes the entire display210to be dedicated to the system-processor204graphics. System processor204further controls keyboard206(and perhaps other input devices such as touchpads, etc.), and the interactions needed to properly authenticate the user, and inform him of the progress and results of this process via display210. In embodiments, video outputs of the application-processor202are not allowed to be viewed until the authentication has been successful, although the operating system and application software may have been active previously on the application-processor202. Once the authentication has successfully completed and the system processor204declares a normal operational mode, it will cause video mux208via signal222to allow the application graphics from input216to take up the entire screen.

In embodiments, system-processor204graphics will not be visible most of the time after successful authentication, except when system-level information needs to be conveyed, or a specific key-combination has been pressed that require interaction with the system-processor204. At such times, video mux208can cause the system-processor204graphics to be displayed as an overlay over the application graphics. Under special conditions, for example when the user has been authenticated but the application-processor202is being activated or restarted, or when an application embedded in the system-processor204firmware runs, video mux208can cause the application graphics video216to be displayed as a small window on the screen210, so the user can monitor its progress while interacting with the system-processor204.

Multiplexer208is controlled by signal222from system processor204. It can use any conventional, proprietary or future techniques for mixing video and graphics from multiple sources such as chroma-key, overlay, windowing, etc. As such, the implementation details of208depend on the particular multiplexing technique used, and so further details thereof will be omitted here for clarity of the invention. In embodiments, where application processor202includes a standard XGA graphics controller, the standard XGA interface is used to implement interface216. It should be further noted that multiplexer208can use additional video security functionality described in co-pending application Ser. No. 13/241,073, the contents of which are incorporated herein by reference in their entirety.

Authentication can include any conventional, proprietary or future technique, and those skilled in the art will recognize many possible alternatives. In one non-limiting example, system processor204can prompt a user to enter/supply credentials such as username, password, secure key, biometrics (e.g. fingerprint). These credentials can be compared to locally stored credentials, or system processor204can forward them to a remote authentication server for comparison. Still further, locally-stored credentials can be time-limited and refreshed or revoked from an external source as needed.

Similar to the provision of application processor graphics216to display210via mux208, system processor204prevents access of processor202to keyboard206and other peripherals until authentication succeeds. As will be explained in more detail below, after successful authentication, processor204permits emulated access by processor202to keyboard206and other peripherals via bus224, as controlled by emulation functionality provided by firmware214.

Example approaches to securing the data networking function of a computer system100according to aspects of the invention will now be described. In embodiments, system100is a standalone computer that is purchased by a corporation for use by a specific employee. As illustrated inFIG. 3, in these and other embodiments, the corporation preferably further owns/maintains a private network320(e.g. an Intranet) interconnected to a public access data network322(e.g. the Internet). The private network320is preferably secure and sufficiently protected from all relevant threats by a collection of conventional devices such as firewalls, intrusion detection and other forensic and architecture-level protection mechanisms. It is thus an aspect of such embodiments of the present invention to take full advantage of these pre-existing protection measures and benefit from their centralized procurement and management.

In embodiments such as that illustrated inFIG. 3, there are at least two physical networking interfaces on the system-processor sub-system204. One of these network interfaces, which is typically a Gigabit Ethernet port304, is connected to a similar port302on the application-processor sub-system202in a “back to back” configuration, and is the only physical networking connection available to the application-processor202. Therefore, all traffic originating at an application on processor202will be intercepted by the system-processor204, and any packet directed at the application must first pass through the system-processor204.

The other of the one or more physical networking interfaces306on the system-processor204is typically another Gigabit Ethernet. Other types could include wireless network interface modules such as Wi-Fi. Either or both of these interfaces can connect to an available physical network, which can be detected automatically. The network management function330of the system processor (preferably implemented in firmware214) then determines if the network detected can be identified and authenticated. For example, network management function330can verify whether the detected network is Intranet320of the designated corporation that purchased this computer. For example, network management function330can store a range of addresses used within the corporation and can compare the address of the detected network to this range. Network management function330can further attempt a connection to one of a list of known servers, retrieve the server cryptographic certificate and verify the certificate against a locally stored certificate database. If authentication passes, and the directly connected network is deemed safe, the system-processor204thereafter forwards all packets between the first networking interface302/304and the active external interface306.

Should the authentication process not succeed, or in some cases when an elevated protection level is desired such that the process is entirely bypassed, the available network is deemed insecure, and a virtual private network (“VPN”) connection, (a.k.a. VPN Tunnel308) will be established between a VPN client332on the system-processor204(preferably implemented in firmware214) and a VPN server334on a designated VPN Gateway310on the corporate Intranet320. Once the VPN Tunnel308is established, all traffic to and from the first interface304connected to the application-processor202will pass through the VPN Tunnel308exclusively, so that the application software and its operating system will behave as if the computer was connected locally to the corporate secure network320(e.g. Intranet), even when the computer is connected to any other public or private network308while moved about by the employee that uses it. A preferred embodiment utilizes the Ethernet over IP protocol312/314(where EoIP312is preferably implemented in firmware214) to encapsulate raw Ethernet traffic to and from the application-processor202onto the VPN tunnel308via VPN client332. At the server334end, the VPN Gateway310, after decrypting and verifying the packets, will send them on to the corporate Intranet320. A person competent in the art would appreciate that a VPN Tunnel308provides for the encryption of transmitted data packets and verification of the authenticity of these packets using cryptographic signatures. Thus when data packets containing confidential information are exchanged between the application software running on the application-processor202within the computer and the corporate data servers, such data is protected from eavesdropping or en-route data modification while in transit on a public access network322link.

In embodiments, applications that are embedded in firmware214of the system-processor204have access to the same VPN tunnel308, as well as directly to the locally available network322. So if an embedded application is to transmit any sensitive information, it ought to run its traffic via the VPN Tunnel308. Nevertheless, in certain example embedded applications such as a video-conferencing agent, controller204could allow the user to select a secure connection going through the VPN Tunnel308to the corporate network, and from there onward through potentially via another VPN Tunnel, and display an indicator that the connection is secure. Additionally or alternatively, when (for example, for performance reasons) the secure connection is not desired, the controller204could allow the user to establish a video-conferencing connection by directly accessing the locally available network322, and indicate to the user that the connection is not secure, and the user should avoid discussing any sensitive information.

Other applications embedded in firmware214of the system-processor204may include applications for backing-up and synchronizing the virtual disk image (described in more detail below), and would thus communicate to a corporate storage server via the same VPN Tunnel308described above.

An important peripheral for present-day computers is the disk drive, and so example methods of controlling access to this peripheral according to the invention will now be described in connection withFIG. 4. As shown inFIG. 4, the trend is to replace magnetic media-based rotating disks with Flash memory-based Solid State drives410. As is known, the drive is typically where a conventional computer maintains all of its software and important portions of its data. When a computer is powered-up, small low-level firmware running from read-only or Flash memory, usually called “BIOS” for “Basic Input/Output System, will initialize the memory and disk drive and will proceed to load operating system software from the disk drive to the main memory, a process called “boot-strapping” or “booting”. Once the operating system has commenced execution, it continuously accesses the disk drive to read application software and software libraries, device drivers and configuration files.

When an operating system implements any security-related mechanisms, the keys and passwords used in these protection elements are also stored on the same disk. Any software application that needs to operate in a stand-alone environment, when networking is unavailable, will need to store all of its data as well as executable code and configuration data on the disk drive. For these and other reasons, the disk drive is in need of protection from various potential threats, most notable of which is the potential of theft of the disk drive itself or along with the entire computer, and a subsequent extraction of the data it contains. It is increasingly common for present computers to encrypt the data stored on its disk drive, where the entire content of the disk is encrypted with a single key. This makes the data vulnerable in case this single key is compromised, and at the same time it creates a new potential problem: if the computer user forgets or loses access to the encryption key, neither the corporation nor the employee assigned this computer will be able to retrieve any data on the disk any longer.

One aspect of the computer architecture disclosed herein lies in the way that the disk drive is implemented. In embodiments such as that illustrated in connection withFIG. 4, the application-processor202that runs the application software and the operating system is not required to implement any security protection measures, and does not have direct access to the actual disk drive410of the computer. Instead, the mass-storage peripheral connection of the application-processor202, typically a Serial-ATA (or “SATA”) Host controller404, is connected to a compatible interface on the system-processor204, namely a Serial-ATA Target interface406. This interface406responds to standard ATA commands issued by the application-processor202, and together with the system-level firmware214, provides the application processor202an emulated disk drive414. The process of emulating a disk drive implemented by firmware214can be similar to the techniques deployed in virtualized environments—the emulated disk drive414is actually a collection of files stored in a specific format on an actual disk drive410. The system-processor204hence will have a second mass-storage interface408which connects it to a real disk drive (e.g. a magnetic or other media HDD), or more preferably a Solid State Disk Drive (“SSD”)410. Such a SSD (e.g. implemented by Flash memory or other non-volatile memory technologies such as ferroelectric RAM and phase-change RAM) offers improved performance over magnetic drives, and will essentially mask any performance degradation that the emulation process and the encryption described below may impose.

In the illustrated example architecture, the firmware214of the system-processor204maintains a map of one or more emulated disk drives414as a collection of files and a main index file, which in turn are stored over a file system in a specific format on a real disk drive410. There are several reasons that the emulated disk drive414should span multiple files. First, rarely is a disk drive utilized in its entirety, and hence there is no need to allocate any storage space on the real disk drive for the storage space that is unused. Thus, separating the provisioned space of the emulated drive414onto a collection of files allows a sparse handing of its address space, and the omission of actual storage for areas that are not being used. Second, at certain times there is a need to maintain a consistent image416of an emulated drive that corresponds to its content at a certain point in time, which is known as a check-point, and all subsequently modified data will then be written to new and separate files on the real drive, so that even while the emulated disk414is continuously used, its contents at the time of the check-point remain available. There are a variety of reasons why check-pointing is required, one of which is the ability to backup or synchronize the contents of the disk on a central corporate data storage vault, and prevent loss of data in the event the computer is lost or damaged. The check-pointing and backup functionality are implemented by the firmware214of the system-processor204, and are thus independent of the operating system or application software of processor202. Moreover, as the system-processor204consumes significantly less power than the application-processor202, if the computer is not being actively used but needs to perform a periodic backup process, there is no need to apply power to the application-processor202, as the computer is fully capable of communicating with the corporate backup servers and securely transmit the newest areas of the emulated disk414to the server independently.

The data of the emulated disk414is preferably encrypted when stored on the real disk drive. To avoid confusion, the data blocks exchanged between the application-processor202and system-processor204are not encrypted, and are transmitted in clear-text. This data is then encrypted by process412(e.g. using AES256) before being written to the real solid-state disk drive410. The encryption key used for the encryption of emulated disk data is preferably at no time present in the memory space of the application-processor202, and thus any attack aimed at this encryption key by means of implanting malicious software onto the computer is rendered ineffective. Even inside the system-processor204, the emulated-disk414encryption key should never be stored in the main memory, but instead a separate memory space intended for encryption keys should be used to store these keys during normal operation. The specially protected key-storage memory is preferably also made with non-volatile memory technology so that these keys never need to be stored on the real solid-state disk drive410either, and are instead held inside the one of the chips making up the system-processor204.

For an additional improvement of the emulated disk protection level, since the emulated disk414data is stored in a plurality of files, it is desirable to designate a specific encryption key to each of these files, so that if the real drive does get stolen, the amount of time that will be needed to compromise the entire disk will be multiplied. During normal operation, all the encryption keys used by any of the files representing the emulated disk are preferably present in the system-processor204designated security-module memory.

During the backup process, the firmware214will decrypt the emulated disk data414, compress it and re-encrypt it for transmission using the VPN Tunnel encryption protocol and keys mentioned above. In this way, there is never a need to transmit the emulated disk encryption keys over the network or store them on the corporate server, thus minimizing the risk of compromising the data of all corporate computers in the event one of these servers is compromised. If however a computer gets lost or damaged, the data stored in its emulated disk414is securely maintained on one of the corporate servers, and a new computer can be quickly provisioned to the same user and restored to full operation by copying the emulated disk image416to the new computer.

In order to minimize the impact of disk emulation on the performance of the application-processor202and its software, the system-processor204should be able to perform several mass-storage commands concurrently. This can be implemented using the Native Command Queuing feature of the Serial-ATA command set. Hence there could be several storage-related activities happening all at once: a storage command is received by the SATA-Target hardware406into the memory; a number of data blocks in memory are being encrypted or decrypted by block412; and another storage command is being executed on the SATA-Host interface408that connects to the real drive, all at the same time, so there may be at least three storage operations processed by the system-processor204at the same time. This will effectively mask the delay that is inevitable in the added complexity of handling these commands while emulating a disk drive414, as long as the application-processor202and the operating system it is running is capable of issuing additional storage commands before receiving a response to the first one.

The peripherals that do not belong to the above described groups, and optionally some that do, are commonly interfaced using the Universal Serial Bus (USB). Example methods of providing secure access to these peripherals according to aspects of the invention will now be described in connection withFIG. 5. Such peripherals can include keyboards, mice, printers, wireless modems, card readers, external disk drives and a variety of application-specific I/O devices. As is known, the peripherals that can be connected via USB belong to a number of categories, each possibly with its unique implication on security of the computer system. Some USB peripherals can be considered reasonably safe, while others have become very popular in recent years for staging sophisticated theft of digital information and electronic sabotage. It is thus preferable to subject the USB peripheral connection as a whole to an additional layer of protection, slightly like the network protecting firewall, which will impose a set of policies512that select which peripherals are allowed, which are banned, and which can be used in a limited or controlled manner. For example, some companies might ban the use of external USB Mass-storage devices (such as Flash drives). Others may choose to allow their use but as long as these were issued by the same company, or that every file read from or written to a Flash drive is sent to the corporate security team for inspection for possible embedded malware, or for audit purposes.

In light of the above considerations, the system-processor204in embodiments of the invention illustrated inFIG. 5preferably includes two USB ports, one acting as an augmented target504, and the other a normal USB Host502. The Host port502is used to connect to actual USB peripherals506, some of which may be internal to the computer; for example, a video-conferencing camera, audio speakers and microphone, a keyboard and a touchpad, and several standardized USB ports used to connect external peripherals.

The USB Target port504connects directly “back-to-back” with the standard USB port508present on the application-processor sub-system202, and contains appropriate hardware resources complemented by specifically designed firmware214to emulate a plurality of USB peripherals. Regular USB Target controllers include enough resources to implement only a single target device, which would not suffice in this case. For the purpose of the computer architecture disclosed herein, the USB Target port504preferably implements more hardware resources and logic, and is capable of emulating514multiple (e.g. at least 8) independent USB peripherals, each with its own device address. These are enumerated by the application-processor202operating system USB software stack, as if there were in reality several independent USB devices connected to the application-processor202via a USB Hub. Since some of the actual devices that will be depended upon for providing the functionality of the emulated USB devices514might be of a lower speed than the maximum speed of the USB interface508on the application-processor202, the USB Target port504will also benefit the overall system performance if it implements the logic required for USB Hubs. In other words, the resources required for the augmented USB Target port504correspond to the resources of a USB Hub510as well as several independent USB Target devices506.

The firmware214of system-processor204complements the hardware functionality and maps each of the emulated USB peripherals514to one of the real USB devices506connected to its USB Host port502, but does so in a way that is consistent with a set of security policies512. These policies512are stored locally by firmware214and can be retrieved from the corporate server from time to time automatically, without user intervention. These policies512may allow the mapping and transparent bridging of a certain class of devices that are considered essentially harmless. Still, even the most harmless of USB devices (e.g. external mice) must be checked for the validity of their USB data structures, so that any vulnerabilities that may exist in the application operating system USB stack that could be exploited with a maliciously-crafted USB packet are protected against by engine512.

Other USB devices may be banned by engine512based on their class and sub-class. Some USB devices may be allowed based on the manufacturer and model codes or even more specifically based on their serial numbers, so that for example USB Flash drives can be generally banned, while very specific Flash drives that have a built-in security shield and are furnished by the corporation would be allowed.

In some cases permitted devices will be emulated514with certain specific action. For example, the computer keyboard is a USB device, and should be generally allowed, except that certain key combinations should be intercepted by the system-processor204and not forwarded to the application-processor202, and used to request certain system-level functions to be invoked. Another example is when an allowed USB Flash drive is required by the policy512to retain an audit trail. In such a case the commands to read and write data to and from the USB Flash drive would be forwarded across the system-processor's two USB ports502,504, but these commands along with the accompanying data would be recorded in a special file on the local drive, and subsequently submitted to the corporate server via the VPN Tunnel for storage and subsequent audit.

With the USB Target port504augmented with the logic on a USB hub510, namely the support of split-transaction, the bridging can be done transparently. Split-transaction support allows the system-processor204to handle any command from the application-processor202USB stack by forwarding that same request (if permitted) to the actual real USB device506, and then return the response when it is ready. Without using split-transaction support, it would be necessary for the firmware to prepare the response to any anticipated USB command ahead of time, and store it in the appropriate USB Target device end-point buffer, which will not always allow for sufficient transparency in the bridging between the real and emulated USB device.

In addition to the above, there will sometimes need to be a number of connections between the two sub-systems202and204, including those that are needed for purely operational purposes and that have no influence on the application software and operating system. One such connection would be the ability of the system-processor subsystem204to control the power supply of the application-processor sub-system202, and emulate a standard computer power supply. Another connection can control and monitor the “BIOS” low-level operational software on the application-processor202, which is preferably done via a low-speed serial port. This would allow operational supervisory functions to be embedded with the firmware214of the system-processor204, and allow remote configuration by, and reporting of the operating system bootstrap process to, the corporate server farm.

An example process of providing secure access to a computer system100according to embodiments of the invention will now be described in connection withFIG. 6.

As shown inFIG. 6, processing begins during initial system start-up S602, for example, when a system power on/reset button is pressed. Initially, as shown in step S604, firmware214operating in system processor204assumes total control of the system100and blocks access of application processor202to all system peripherals. For example, system processor204blocks access to a keyboard206and similar input devices such as mice. In other words, even though such peripherals are attached to the system100, signals from them are provided only to system processor204, and these signals are not relayed to application processor202. Similarly, system processor204causes the video mux208to block any video outputs from application processor202to be shown on display210. Meanwhile, the system processor204can cause the video mux208to display a startup screen that is output by system processor204.

As shown in step S606, the system processor204can allow the application processor202to boot. In other embodiments, this step does not occur until after a user has been authenticated. In either event, during startup of application processor202, system processor204can control access of the application processor202to the disk drive410(e.g. to allow the processor202to load an operating system such as Windows 7), and provide an emulated keyboard and display connection for the BIOS/operating system for application processor202, even though such inputs and outputs are actually blocked by system processor204.

In a next step S608, system processor204exclusively controls keyboard206(and perhaps other input devices such as touchpads, etc.), and the interactions needed to properly authenticate the user, and inform him of the progress and results of this process via display210. As set forth above, authentication can include any conventional, proprietary or future technique, and those skilled in the art will recognize many possible alternatives. In one non-limiting example, system processor204can prompt a user to enter/supply credentials such as username, password, secure key, biometrics (e.g. fingerprint). These credentials can be compared to locally stored credentials, or system processor204can forward them to a remote authentication server for comparison.

If authentication is determined in step S610to be unsuccessful, an error screen is displayed in step S612, and all further inputs from the user on any attached peripherals will be ignored.

Otherwise, if it is determined in step S610that authentication is successful, the system processor204declares a normal operational mode in step S614, and causes video mux208to allow the application processor202graphics to take up the entire screen. Similarly, after successful authentication, processor204permits emulated access by processor202to keyboard206and other peripherals via bus224as provided by emulation functionality programmed in firmware214. It should be noted that the “authenticated” state need not be perpetual. For example, in the event of inactivity or partial shutdown of the system, the system can lock up and return to an unauthenticated state. In this case, application processor202, though perhaps still running, is blocked by processor204from accessing any peripherals, except perhaps to certain storage and networks that are needed to maintain the system in an operating state. At this point, the system processor204can display a logon screen and interact with a user to re-authenticate.

As another example, even while the system is in an “authenticated” state, the system processor204can periodically request attention of the operator by displaying a message or graphic in “overlay” mode on display210, and enable interaction between the operator and system processor204by entering a pre-defined key combination on the keyboard, which will can cause a menu to popup under control of system processor204firmware. Such interaction can be used to adjust network settings, perform maintenance functions or invoke any other functionality built into the system processor204firmware, such as secure voice or video communications.