The primary purpose of the Trusted Platform Module (TPM) is to provide a hardware mechanism for maintaining the integrity of a computer platform.  It is a key element in protecting against stealthy malware such as rootkits and bootkits by providing hardware cryptographic capabilities that support authentication processes for low level elements of the system, including the BIOS, the boot sector and master-boot-record (MBR).  Systems with TPM are capable of meeting NIST guidelines for trusted computing, which include "measurement" of firmware, software and configuration information before they are executed, then encrypted storage of the "measurements" in hardware, and then validation the "measurements" against a predefined expectation.  The TPM is involved in all three of these steps, including the storage of the expected and current measurements.  In addition to providing for "platform integrity," the TPM can be used for key protection for hard disk encryption, and for password authentication support, and therefore, has potential uses for operating systems and application software.

TXT is a computer hardware technology based in the processor and associated chipset that provides key elements for establishing a verifiable description of the system per the methodologies prescribed by the Trusted Computing Group (TCG).  Key elements of TXT include extensions to the instruction set specifically for security operations, Authentication Code Modules (ACM), and features for supporting Launch Control Policies (LCP). 

In summary, TXT and TPM together can be used to establish the "root of trust" and the "chain of trust" by providing hardware based encrypted identifiers for all software components involved in system initialization, and hardware based mechanisms for blocking the execution of software components that do not match approved versions.  In addition, hardware mechanisms are provided for protecting residual secret data from memory snooping and reset attacks, and features are included to support local and remote attestation of the trustworthiness of the system. Of course, usage of TXT and TPM implies system software (BIOS) and operating system involvement, and, indeed, support at both levels is required for the realization of a trusted computing system.

General Micro Systems develops all system BIOS in-house.  Although this approach increases development costs, it provides for superior software quality control and maximum flexibility to meet the unique needs of our customers, such as enhanced password protection, ultra-fast boot, and custom plasma screens.  For consistency across GMS's product lines, American Megatrends, Inc. (AMI) BIOS cores are exclusively used.  Also, the AMI BIOS cores provide key security related capabilities required for GMS products, most notably UEFI 2.3.1 compliance, and support for UEFI Secure Boot, NIST 800-147 BIOS Protection Guidelines, TPM 1.2 and 2.0, Intel V-Pro (including TXT),  Intel VT-d, Intel Ant-Theft Technology, and password protection for BIOS setup and boot.

Other important features of the GMS system BIOS include:

- Storage of system parameters and configuration settings in the BIOS Flash instead of the standard battery-backed CMOS.  This results in systems that can operate fully without the need of battery in a system.

- Hardware write protect (WP) for the BIOS flash. This feature, which includes a write protect signal at the system interconnect, can be used to eliminate inadvertent and unauthorized changes to the system BIOS and system configuration settings.

GMS welcomes custom BIOS needs which, in most cases, are provided for free to OEM customers.

GMS products include functionality to provide for the security of data stored on internal and removable mass storage devices.  These functions include support for software based full-disk encryption, and support for "in-line" hardware based disk encryption, as well as media with internal encryption capability (self-encrypting drive).  Also, GMS products may be configured with mass storage that has hardware based write protection, and with mass storage that has hardware based "secure erase" capability.

The processors used in GMS products include instruction set enhancements for AES FIPS Publication 197 data encryption and decryption. Key lengths of 128, 192, and 256 bits are supported.  The Trusted Platform Module (TPM) included in GMS products can be used in conjunction with the disk encryption mechanism to provide encryption key storage.  Various off-the-shelf software products that provide full-disk and file-system encryption make use of the processor's AES instructions, including BitLocker™, McAfee^® Endpoint Encryption and Symantec™ PGP Whole Disk Encryption.

Some GMS systems include the option for in-line hardware based full-disk encryption.  This approach provides a cryptographic processor between the root system's SATA ports and the mass storage devices.  The cryptographic processor performs AES FIPS 140-2 certified encryption at a key length of 256 bits.  The encryption and decryption are performed at "wire-speed" on the SATA interface, eliminating the processing overhead and performance considerations of software based disk encryption.  This method is also operating system independent and allows for encryption of any mass storage device.  Key token, password and TPM based key management are supported.

All GMS products with 2.5" internal or removable mass storage support self-encrypting drives (SEDs).  SEDs are nominally compliant to the Trusted Computing Group's Opal SSC specification and use AES encryption with 256 bit key length.  Encryption keys are stored internal to the drive, providing a security advantage over software based encryption.  SEDs are readily available in the rotating media market, and are gaining support in the SSD market.

The specific meaning of secure erase in the context of disk drives is an ATA command defined by NIST Special Publication 800-88 (Guidelines for Media Sanitization) for a firmware based process for overwriting a hard drive.  Virtually all hard disk drives and SSDs support, in some fashion, the secure erase ATA command.  Because there may be some circumstances in which execution of the command via software is not possible, GMS offers as an option on some products with internal or removable mass storage, a hardware mechanism for initiating the secure erase operation.  This option allows the secure erase to be initiated when power is applied to the mass storage device, regardless of the operational state of the system - the system does not have to be functional, nor does any software need to be running.  Specialized mass storage media is required for this feature.

GMS also offers, as an option, mass storage with specialized secure erase methods for defense and governmental agency related customers.  These methods include DoD 5220.22-M, NSA 9-12, NSA 130-2, as well as Army, Air Force and Navy secure erase specifications.  Secure erase for these methods is also triggered by ATA commands and, optionally, by a hardware mechanism.  The secure erase, when triggered, cannot be stopped.  If power is disconnected from the drive before the secure erase is complete, the secure erase will resume when power is re-applied. Some of the secure erase methods are destructive, such that the drive is not reusable after the erase is complete.

GMS also offers, as an option on some products with internal or removable mass storage, a hardware mechanism for preventing any data writes to the mass storage device.  This feature, which includes a write protect signal at the system interconnect, can be used to eliminate unauthorized or inadvertent changes to the content of the mass storage device, and is of interest to customers requiring that the operating system be "tamper proof."   Specialized mass storage media is required for this feature.

One possible security risk with computer systems that process confidential information is that unauthorized personnel may attempt to physically open the system in order to access data storage devices, including mass storage, non-volatile memory or even RAM, or to modify the system configuration such that the integrity of the system is compromised.

To prevent tampering such as this from being successful, some GMS products include a tamper sensor.  This sensor, when activated, sends a signal to the internal and removable drives, as well as the Platform Controller Hub (PCH), which can be used to initiate various responses, such as halting operation, turning off power, disabling subsequent initialization, triggering secure erase of the drives, and triggering erasure of the system BIOS.

In a standard virtual machine (VM) environment, all of the root system’s I/O resources, such as USB, Ethernet, serial ports, etc., are effectively organized as a generic pool, and are assigned to a given virtual machine on a “as-needed” basis for a given application.  In the GMS Secure Virtual Machine architecture, the system’s I/O resources are predefined by the hardware topology to be in specific groupings. These groupings are the designated I/O for a set of virtual machines and for the supervisory portion of the system.  The hardware topology of the GMS Secure Virtual Machine is the key to providing the necessary isolation, resulting in dedicated I/O resources at the hardware level for each virtual machine, and a dedicated hardware path to the processor/memory sub-system for every virtual machine.  The GMS Secure Virtual Machine architecture, in conjunction with Intel VT-x and VT-d technologies, which provide for isolation at the memory, DMA, and interrupt levels, along with an appropriate virtual-machine monitor (VMM), provide the highest level of security possible for virtualized operating systems.

General Micro Systems' Secure Virtual Machine architecture uses none of the system's centralized I/O resources for virtual machine I/O, while providing dedicated (un-shared) connections from the system's root complex to the discrete hardware elements designated for each virtual machine's I/O.  This approach addresses security risks by allowing the native I/O device drivers to be resident in the protected virtual machine partitions rather than being emulated by the VMM, and by eliminating any hardware or software coupling between the I/O functions of the virtual machine instances.  Thus, the I/O functions of one virtual machine cannot be monitored or interfered with by software running on another virtual machine or by software running on the VMM itself.  An added benefit of this architecture is the inherent fault tolerance of dedicated I/O resources; damage or malfunction of the hardware elements designated for one virtual machine does not affect the operation of any of the other virtual machines.  For example, a typical embedded computer system has multi-port USB hubs connected to an EHCI USB host controller as part of its central resources.  The assignment of these ports by the VMM may span, or even be shared by, more than one virtual machine.  A failure or error on one of the ports may affect the hub or the host controller in such a way that communications on the other ports are degraded or compromised.  For the GMS Secure Virtual Machine architecture, USB ports assigned to a given virtual machine are provided by host controllers that are dedicated to that specific virtual machine.  While damage, malfunction or error at that host controller will affect the operation of the associated virtual machine, there should be no effect on any of the other virtual machines in the system.

Another important aspect of the GMS Secure Virtual Machine architecture is its inherent support for trusted computing.  In addition to the Trusted Platform Module (TPM) and the TXT capabilities provided by the processor and chipset, VT-x and VT-d are integral elements of a trusted computing system that hosts virtual machine partitions.  VT-d is utilized during both system initialization, and by the VMM during normal operation.  During initialization, VT-d provides for protected memory regions (PMR) from which the "launch environment" itself, as well as elements of the VMM, may operate.  VT-d is used in the creation and management of the trusted partitions for the virtual machine instantiations, protecting the virtual machine partitions and the VMM from each other, and during normal operation, the VMM may use VT-d to define protected regions for use by integrity monitoring functions.

GMS’s multi-domain platform systems are targeted for applications where two different security domains need to co-exist in the same enclosure.  For this situation, the GMS MDP architecture is “share nothing” meaning that all hardware for one domain is physically and electrically separated from all hardware for the other domain.  Multi-domain platforms create an environment where two separate systems are enclosed in the same box, with the only common element being the raw input power. All internal functions, including regulators, processor and memory, and I/O functions are fully isolated from one another, such that the electrical coupling and RFI between the two domains is negligible.  This is achieved via shielding one domain from another and filtering all I/O interconnects.