Abstract: In a cloud computing environment, a production server virtualization stack is minimized to present fewer security vulnerabilities to malicious software running within a guest virtual machine. The minimal virtualization stack includes support for those virtual devices necessary for the operation of a guest operating system, with the code base of those virtual devices further reduced. Further, a dedicated, isolated boot server provides functionality to securely boot a guest operating system. The boot server is isolated through use of an attestation protocol, by which the boot server presents a secret to a network switch to attest that the boot server is operating in a clean mode. The attestation protocol may further employ a secure co-processor to seal the secret, so that it is only accessible when the boot server is operating in the clean mode.

Abstract: Digital content is released to a rendering application for forwarding by such rendering application to an ultimate destination by way of a path therebetween. The path is defined by at least one module, and the digital content is initially in an encrypted form. An authentication of at least a portion of the path is performed to determine whether each defining module thereof is to be trusted to appropriately handle the digital content passing therethrough. The encrypted digital content is decrypted if in fact each such defining module is to be trusted, and the decrypted digital content is forwarded to the rendering application for further forwarding to the ultimate destination by way of the authenticated path.

Abstract: The various methods and systems described herein are directed to supplying a secure channel for software executing on a host computer. The methods and systems address and provide solutions for an attack model in which rogue software executing on the host computer attempts to inappropriately obtain or otherwise manipulate data. Some embodiments can provide pixel data that can be kept confidential (in that untrusted software applications cannot read the data off of the display screen). In addition, other embodiments can preserve the integrity of the pixel data by detecting whether the pixel data has been inappropriately manipulated. Various embodiments are based on a decryption engine that is located on a video card very late in the video processing chain such that programmatic access to decrypted pixel data is denied.

Abstract: A single application can be executed across multiple execution environments in an efficient manner if at least a relevant portion of the virtual memory assigned to the application was equally accessible by each of the multiple execution environments. A request by a process in one execution environment can, thereby, be directed to an operating system, or other core software, in another execution environment and can be made by a shadow of the requesting process in the same manner as the original request was made by the requesting process itself. Because of the memory invariance between the execution environments, the results of the request will be equally accessible to the original requesting process even though the underlying software that responded to the request may be executing in a different execution environment. A similar thread invariance can be maintained to provide for accurate translation of requests between execution environments.

Abstract: In accordance with certain aspects, data is received from a calling program. Ciphertext that includes the data is generated, using public key encryption, in a manner that allows the data to be obtained from the ciphertext only if one or more conditions are satisfied. In accordance with another aspect, a bit string is received from a calling program. Data in the bit string is decrypted using public key decryption and returned to the calling program only if one or more conditions included in the bit string are satisfied.

Abstract: Systems and methods provide multiple partitions hosted on an isolation technology such as a hypervisor where at least one of the partitions, a local secure service partition (LSSP), provides security services to other partitions. The service partitions (LSSPs) host those high assurance services that require strict security isolation, where the service can be shared across partitions and accessed even when the user is not connected to a network. The LSSP also can certify the results of any computation using a key signed by a TPM attestation identity key (AIK), or other key held securely by the hypervisor or a service partition. The LSSPs may be configured to provide trusted audit logs, trusted security scans, trusted cryptographic services, trusted compilation and testing, trusted logon services, and the like.

Abstract: Systems and methods provide multiple partitions hosted on an isolation technology such as a hypervisor where at least one of the partitions, a local secure service partition (LSSP), provides security services to other partitions. The service partitions (LSSPs) host those high assurance services that require strict security isolation, where the service can be shared across partitions and accessed even when the user is not connected to a network. The LSSP also can certify the results of any computation using a key signed by a TPM attestation identity key (AIK), or other key held securely by the hypervisor or a service partition. The LSSPs may be configured to provide trusted audit logs, trusted security scans, trusted cryptographic services, trusted compilation and testing, trusted logon services, and the like.

Abstract: In accordance with certain aspects, data is received from a calling program. Ciphertext that includes the data is generated, using public key encryption, in a manner that allows the data to be obtained from the ciphertext only if one or more conditions are satisfied. In accordance with another aspect, a bit string is received from a calling program. Data in the bit string is decrypted using public key decryption and returned to the calling program only if one or more conditions included in the bit string are satisfied.

Abstract: In accordance with certain aspects, data is received and a digital signature is generated and output. The digital signature can be a digital signature of the data and one or more conditions that are to be satisfied in order for the data to be revealed, or a digital signature over data generated using a private key associated with a bound key that is bound to one or more processors.

Abstract: In accordance with certain aspects, bound key operations on ciphertext and/or data are implemented. A bound key operation can receive both data to be signed and a bound key blob that is bound to one or more processors, recover a private key from the bound key blob, and generate a digital signature over the data using the private key. A bound key operation can alternatively receive both ciphertext and a bound key or bound key structure bound to one or more processors, recover or reconstruct a private key based on the bound key or bound key structure, and use the private key to generate plaintext corresponding to the ciphertext.

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: In a cloud computing environment, a production server virtualization stack is minimized to present fewer security vulnerabilities to malicious software running within a guest virtual machine. The minimal virtualization stack includes support for those virtual devices necessary for the operation of a guest operating system, with the code base of those virtual devices further reduced. Further, a dedicated, isolated boot server provides functionality to securely boot a guest operating system. The boot server is isolated through use of an attestation protocol, by which the boot server presents a secret to a network switch to attest that the boot server is operating in a clean mode. The attestation protocol may further employ a secure co-processor to seal the secret, so that it is only accessible when the boot server is operating in the clean mode.

Abstract: A device, such as a smartcard, may be externally-connected to a host platform and may be used to enhance or extend security services provided by the host platform's Trusted Platform Module (TPM). The device and the platform exchange keys in order to facilitate reliable identification of the platform by the device and vice versa, and to support cryptographic tunneling. A proxy component on the host device tunnels information between the platform and the device, and also provides the device with access to the TPM's services such as sealing and attestation. The device can provide secure services to the platform, and may condition provision of these services on conditions such as confirming the platform's identity through the exchanged keys, or platform state measurements reported by the TPM.

Abstract: Disclosed is a trusted language runtime (TLR) architecture that provides abstractions for developing a runtime for executing trusted applications or portions thereof securely on a mobile device (e.g., a smartphone). TLR offers at least two abstractions to mobile developers: a trustbox and a trustlet. The trustbox is a runtime environment that offers code and data integrity, and confidentiality. Code and data running inside a trustbox cannot be read or modified by any code running outside the trustbox. A trustlet is the code portion of an application that runs inside a trustbox. With TLR, programmers can write applications in .NET and specify which parts of the application handle sensitive data, and thus, run inside the trustbox. With the TLR, the developer places these parts in a trustlet class, and the TLR provides all support needed to run the parts in the trustbox.

Abstract: A hypervisor provides a snapshot protocol that generates a verifiable snapshot of a target machine. The verifiable snapshot includes a snapshot and a signed quote. In one implementation, a challenger requests a snapshot of the target machine. In response to the snapshot request, the hypervisor initiates Copy-on-Write (CoW) protection for the target machine. The hypervisor snapshots and hashes each of the memory pages and the virtual central processing unit (CPU) of the target machine. The hypervisor generates a composite hash by merging all individual memory page hashes and the CPU state hash. The hypervisor requests a quote including integrity indicators of all trusted components and the composite hash. The quote uses a cryptographic signature from a trusted platform module, which ensures that any compromise of the integrity of the snapshot is detectable. The snapshot and signed quote are returned to the challenger for verification.

Abstract: The various methods and systems described herein are directed to supplying a secure channel for software executing on a host computer. The methods and systems address and provide solutions for an attack model in which rogue software executing on the host computer attempts to inappropriately obtain or otherwise manipulate data. Some embodiments can provide pixel data that can be kept confidential (in that untrusted software applications cannot read the data off of the display screen). In addition, other embodiments can preserve the integrity of the pixel data by detecting whether the pixel data has been inappropriately manipulated. Various embodiments are based on a decryption engine that is located on a video card very late in the video processing chain such that programmatic access to decrypted pixel data is denied.

Abstract: The various methods and systems described herein are directed to supplying a secure channel for software executing on a host computer. The methods and systems address and provide solutions for an attack model in which rogue software executing on the host computer attempts to inappropriately obtain or otherwise manipulate data. Some embodiments can provide pixel data that can be kept confidential (in that untrusted software applications cannot read the data off of the display screen). In addition, other embodiments can preserve the integrity of the pixel data by detecting whether the pixel data has been inappropriately manipulated. Various embodiments are based on a decryption engine that is located on a video card very late in the video processing chain such that programmatic access to decrypted pixel data is denied.

Abstract: Technology is described for protection of virtual machines executing on a host device having host processors and host memory. The system can include a hypervisor configured to enable the virtual machines to execute concurrently on the host device. An emancipated partition can be provided with a communication channel to the hypervisor. A primary partition can be configured to interface with the emancipated partition through the communication channel via the hypervisor. In addition, an emancipated memory space and virtual register state for the emancipated partition can be protected from direct access by the primary partition.

Abstract: A secure processor is operable in normal and preferred modes, and includes a security kernel instantiated when the processor enters into preferred mode and a security key accessible by the security kernel during preferred mode. The security kernel employs the accessed security key to authenticate a secure application, and allows the processor to be trusted to keep hidden a secret of the application. To instantiate the application, the processor enters preferred mode where the security key is accessible, and instantiates and runs the security kernel. The security kernel accesses the security key and applies same to decrypt a key for the application, stores the decrypted key in a location where the application will expect same, and instantiates the application. The processor then enters the normal mode, where the security key is not accessible.

Abstract: A single application can be executed across multiple execution environments in an efficient manner if at least a relevant portion of the virtual memory assigned to the application was equally accessible by each of the multiple execution environments. A request by a process in one execution environment can, thereby, be directed to an operating system, or other core software, in another execution environment and can be made by a shadow of the requesting process in the same manner as the original request was made by the requesting process itself. Because of the memory invariance between the execution environments, the results of the request will be equally accessible to the original requesting process even though the underlying software that responded to the request may be executing in a different execution environment. A similar thread invariance can be maintained to provide for accurate translation of requests between execution environments.