Abstract: The various embodiments described below are directed to providing authenticated and confidential messaging from software executing on a host (e.g. a secure software application or security kernel) to and from I/O devices operating on a USB bus. The embodiments can protect against attacks that are levied by software executing on a host computer. In some embodiments, a secure functional component or module is provided and can use encryption techniques to provide protection against observation and manipulation of USB data. In other embodiments, USB data can be protected through techniques that do not utilized (or are not required to utilize) encryption techniques. In accordance with these embodiments, USB devices can be designated as “secure” and, hence, data sent over the USB to and from such designated devices can be provided into protected memory. Memory indirection techniques can be utilized to ensure that data to and from secure devices is protected.

Abstract: The various embodiments described below are directed to providing authenticated and confidential messaging from software executing on a host (e.g. a secure software application or security kernel) to and from I/O devices operating on a USB bus. The embodiments can protect against attacks that are levied by software executing on a host computer. In some embodiments, a secure functional component or module is provided and can use encryption techniques to provide protection against observation and manipulation of USB data. In other embodiments, USB data can be protected through techniques that do not utilized (or are not required to utilize) encryption techniques. In accordance with these embodiments, USB devices can be designated as “secure” and, hence, data sent over the USB to and from such designated devices can be provided into protected memory. Memory indirection techniques can be utilized to ensure that data to and from secure devices is protected.

Abstract: The various embodiments described below are directed to providing authenticated and confidential messaging from software executing on a host (e.g. a secure software application or security kernel) to and from I/O devices operating on a USB bus. The embodiments can protect against attacks that are levied by software executing on a host computer. In some embodiments, a secure functional component or module is provided and can use encryption techniques to provide protection against observation and manipulation of USB data. In other embodiments, USB data can be protected through techniques that do not utilized (or are not required to utilize) encryption techniques. In accordance with these embodiments, USB devices can be designated as “secure” and, hence, data sent over the USB to and from such designated devices can be provided into protected memory. Memory indirection techniques can be utilized to ensure that data to and from secure devices is protected.

Abstract: Techniques are disclosed to provide security for graphical user interface elements being displayed in a system having a host operating system and a high assurance operating system. Graphical user interface elements associated with the high-assurance operating system may be prevented from being obscured and from any partial transparency. Additionally, a piece of secret information may be stored and displayed by graphical user interface elements associated with the high-assurance operating system. Coordinating certain elements of the graphical user interface elements associated with the high assurance operating system also helps to identify legitimate elements associated with the high assurance operating system. Public title information may be furnished to a host operating system windowing system to identify a window owned by a process running on a high-assurance operating system. Private title information associated with the same window may be used in the high assurance operating system.

Abstract: A memory controller prevents CPUs and other I/O bus masters from accessing memory during a code (for example, trusted core) initialization process. The memory controller resets CPUs in the computer and allows a CPU to begin accessing memory at a particular location (identified to the CPU by the memory controller). Once an initialization process has been executed by that CPU, the code is operational and any other CPUs are allowed to access memory (after being reset), as are any other bus masters (subject to any controls imposed by the initiated code).

Abstract: The various embodiments described below are directed to providing authenticated and confidential messaging from software executing on a host (e.g. a secure software application or security kernel) to and from I/O devices operating on a USB bus. The embodiments can protect against attacks that are levied by software executing on a host computer. In some embodiments, a secure functional component or module is provided and can use encryption techniques to provide protection against observation and manipulation of USB data. In other embodiments, USB data can be protected through techniques that do not utilized (or are not required to utilize) encryption techniques. In accordance with these embodiments, USB devices can be designated as “secure” and, hence, data sent over the USB to and from such designated devices can be provided into protected memory. Memory indirection techniques can be utilized to ensure that data to and from secure devices is protected.

Abstract: A memory controller prevents CPUs and other I/O bus masters from accessing memory during a code (for example, trusted core) initialization process. The memory controller resets CPUs in the computer and allows a CPU to begin accessing memory at a particular location (identified to the CPU by the memory controller). Once an initialization process has been executed by that CPU, the code is operational and any other CPUs are allowed to access memory (after being reset), as are any other bus masters (subject to any controls imposed by the initiated code).

Abstract: Techniques are disclosed to provide security for user output and input in which a first, host operating system is used along with a second, high assurance operating system (nexus), where the first system provides at least some of the infrastructure for the second system. A trusted UI engine has a trusted input manager and a trusted output manager. The trusted input manager controls access to trusted input, distributing decrypted input to the host operating system where appropriate, or to the appropriate process running in the nexus. The trusted output manager manages output to the display, and allows trusted agents in the nexus to output data for display without needing to be aware of output-device-dependent details.

Abstract: The various embodiments described below are directed to providing authenticated and confidential messaging from software executing on a host (e.g. a secure software application or security kernel) to and from I/O devices operating on a USB bus. The embodiments can protect against attacks that are levied by software executing on a host computer. In some embodiments, a secure functional component or module is provided and can use encryption techniques to provide protection against observation and manipulation of USB data. In other embodiments, USB data can be protected through techniques that do not utilized (or are not required to utilize) encryption techniques. In accordance with these embodiments, USB devices can be designated as “secure” and, hence, data sent over the USB to and from such designated devices can be provided into protected memory. Memory indirection techniques can be utilized to ensure that data to and from secure devices is protected.

Abstract: Efficient power management of a system with virtual machines is disclosed. In particular, such efficient power management may enable coordination of system-wide power changes with virtual machines. Additionally, such efficient power management may enable coherent power changes in a system with a virtual machine monitor. Furthermore, such efficient power management may enable dynamic control and communication of power state changes.

Abstract: An operating system is described that is capable of ascertaining whether it is executing in a virtual machine environment and is further capable of modifying its behavior to operate more efficiently and provide optimal behavior in a virtual machine environment. An operating system is enlightened so that it is aware of VMMs or hypervisors, taking on behavior that is optimal to that environment. The VMM or hypervisor informs the operating system of the optimal behavior, and vice versa.

Abstract: Access to an authentication image may be protected so that only authenticated processes have access to the image. The image can be displayed to authenticate a User Interface (UI) to a computer user. The image indicates the UI can be trusted. If the image is not displayed, it may be that an application UI is “spoofed” to trick a user into providing sensitive information. Additionally, a large variety of different images can be used as authentication images, so spoofing one image be recognized by most users. A set of original images may be provided, along with image modification processes which can generate a large number of variations. Techniques for authenticating UIs in a virtual machine context are provided. A secure attention sequence is also provided, which allows users to test whether processes running on a computer are authenticated.

Abstract: Described is a system and method whereby processes may have multiple memory maps associated therewith to provide curtained memory and overcome other memory-related problems. Multiple maps are used to restrict memory access of existing code such as drivers, without changing that code, and without changing existing microprocessors. A thread of a process is associated with one memory map at a time, which by mapping to different memory locations, provides memory isolation without requiring a process switch. Memory isolation may be combined with controlled, closed memory map switching performed only by trusted code, to ensure that some protected memory is inaccessible to all but the trusted code (curtained memory). For example, the threads of the process may ordinarily run at one privilege level with a restricted map, with map switching is only allowed at a higher privilege level.

Abstract: A data storage resource is identifiable by physical addresses, and optionally by a virtual address. A policy defines which resources are accessible and which resources are not accessible. A request to access a resource is allowed if access to the resource is permitted by the policy, and if carrying out the access will not cause virtual addresses to be assigned to resources to which the policy disallows access. Since resources to which access is disallowed do not have virtual addresses, certain types of access requests that identify a resource by a virtual address can be allowed without consulting the policy.

Abstract: A data storage resource is identifiable by physical addresses, and optionally by a virtual address. A policy defines which resources are accessible and which resources are not accessible. A request to access a resource is allowed if access to the resource is permitted by the policy, and if carrying out the access will not cause virtual addresses to be assigned to resources to which the policy disallows access. Since resources to which access is disallowed do not have virtual addresses, certain types of access requests that identify a resource by a virtual address can be allowed without consulting the policy.

Abstract: A security device watches over the secure functionality in a computer system. This “watcher” security device may be integrated within the computer system or may be separate from it. The security device queries the secure functionality to determine whether the state of the secure functionality is acceptable. If no satisfactory state exists, or if no response is received, then a signal is transmitted. The signal may be auditory (a buzzer) or visual (a flashing light) in order to signal to any user that the secure functionality has been compromised. Optionally, human input devices may be disabled, or a monitoring service notified, in conjunction with or in lieu of the signal. If the secure functionality includes a secret shared between the secure functionality and the user, then the security device may signal the secret. For example, where the secret is visual, the security device may display the secret.

Abstract: A mechanism for protected operating system boot that prevents rogue components from being loaded with the operating system, and thus prevents divulgence of the system key under inappropriate circumstances. After a portion of the machine startup procedure has occurred, the operating system loader is run, the loader is validated, and a correct machine state is either verified to exist and/or created. Once the loader has been verified to be a legitimate loader, and the machine state under which it is running is verified to be correct, the loader's future behavior is known to protect against the loading of rogue components that could cause divulgence of the system key. With the loader's behavior being known to be safe for the system key, the validator may unseal the system key and provides it to the loader.

Abstract: A file locker manages the storage and use of protected data for software objects. A protected environment maintains the cryptographic and isolative infrastructure to support sealing of data items for use by a trusted agent. The file locker uses the protected environment's sealing functionality to seal data items for the file locker's exclusive access. The file locker seals, to itself, files received from software objects, and provides those files upon request, and upon sufficient proof of the requestor's trustworthiness, authenticity, and/or identity. The file locker may be used to extend the protected environment's sealing functionality to legacy applications, without the legacy applications having to implement agents that can run in the protected environment and access the sealing functionality directly.

Abstract: Special purpose heaps are created to store different classes of data to which different rules apply. A library of functions is provided which is designed to respect the different classes of rules that apply to the different heaps, by storing data only on a heap that is designated for use with the proper class of data, and by resisting the performance of actions on data in a heap that is inconsistent with the rules that apply to the heap. The use of plural heaps in this manner discourages programmer error in which an operation is performed on data that is inconsistent with the data, since the programmer would explicitly have to copy data from one heap to the other in order to perform the action. In one example, one heap is designated for the storage of secret data, and another heap is designated for general-purpose (non-secret) data.

Abstract: A memory controller prevents CPUs and other I/O bus masters from accessing memory during a code (for example, trusted core) initialization process. The memory controller resets CPUs in the computer and allows a CPU to begin accessing memory at a particular location (identified to the CPU by the memory controller). Once an initialization process has been executed by that CPU, the code is operational and any other CPUs are allowed to access memory (after being reset), as are any other bus masters (subject to any controls imposed by the initiated code).