Patent classifications
H04L2209/127
Trusted platform module attestation flow over simple authentication and security layer with multiple symmetric key identification
An existing Simple Authentication and Security Layer (SASL) framework is modified to overcome message size limitations by implementing a control byte that enables segmentation of SASL messages. In implementations in which client computing devices utilize a trusted platform module (TPM) for enhanced security, the client computing device can transmit multiple public keys and other information to a provisioning service during an attestation process. This information can be segmented across multiple messages while leveraging the SASL framework. A control byte may be utilized in each message and define attributes about the respective messages, such as whether a current message is an interim or final message segment. Likewise, the provisioning service can divide a challenge key into multiple segments and include a control byte for each segment. The control byte within segmented messages enables utilization of the TPM public keys and thereby can leverage the heightened security provided by the TPM.
Attestation protocol between a host system and a data processing accelerator
According to one embodiment, a system receives, at a host system a public attestation key (PK_ATT) or a signed PK_ATT from a data processing (DP) accelerator over a bus. The system verifies the PK_ATT using a public root key (PK_RK) associated with the DP accelerator. In response to successfully verifying the PK_ATT, the system transmits a kernel identifier (ID) to the DP accelerator to request attesting a kernel object stored in the DP accelerator. In response to the system receives a kernel digest or a signed kernel digest corresponding to the kernel object from the DP accelerator, verifying the kernel digest using the PK_ATT. The system sends the verification results to the DP accelerator for the DP accelerator to access the kernel object based on the verification results.
Methods and systems for enrolling device identifiers (DEVIDs) on redundant hardware
Methods and systems for implementing DevID enrollment for hardware redundant Trust Platform Modules (TPMs), are described. A system can include hardware redundancy for management modules, and for TPMs that correspond to each management module. Accordingly, a product can have a dual-TPM configuration, where both modules are associated with the same product. Further, a process that particularly considers the presence of dual-TPMs for creating, issuing, and enrolling DevID certificates is described. The process issues and maintains DevID certificates for each TPM by synchronizing dual sessions that correspond to each TPM. Also, the process accounts for duplicate identification data, for example allowing the certificate authority (CA) to sign certificates for dual-TPMs linked to the same chassis number. The process can include performing validation checks, rendezvous points, and locks to ensure that DevID certificates are successfully issued for each of the dual-TPMs, respectively.
Attested end-to-end encryption for transporting sensitive data
Techniques are disclosed for enabling attested end-to-end encryption for transporting sensitive data between devices. In one example, an origination device receives and verifies, in a secure environment, a policy profile that includes an origination key of the origination device and a destination key of a destination device. The origination device generates and seals a data encryption key based on a characteristic of the secure environment. The origination device then encrypts the data encryption key with a public key of the destination device to form an encrypted data encryption key. The origination device then signs the encrypted data encryption key with a private attestation identity key of the origination device. The origination device encrypts the sensitive data with the sealed data encryption key to form encrypted data, and then transmits the signed encrypted data encryption key and the encrypted data to the destination device for subsequent decryption of the encrypted data.
POST-QUANTUM CRYPTOGRAPHY SECURED EXECUTION ENVIRONMENTS FOR EDGE DEVICES
Disclosed are techniques for post-quantum encrypted trusted execution environments on edge devices. An edge computing device includes a trusted execution environment that encompasses at least some SIMD processing units such as Graphics Processing Units (GPUs). A data record, such as machine learning inferences from a machine learning or artificial intelligence model, is generated on the edge computing device within the trusted execution environment and encrypted with post-quantum encryption (such as lattice based encryption) using SIMD processing units in the trusted execution environment. Workloads received for the trusted execution environment, also encrypted with post-quantum encryption, are decrypted using the SIMD processing units in the trusted execution environment.
Implicit attestation for network access
A method and apparatus for use in a trusted network environment together or separately employ an implicit attestation that a requesting computing resource is in a trusted state before access to a network resource is granted. The method includes: verifying that a requesting computing resource is in a trusted state; accessing the private key using the released key authorization value; and creating a digital signature for the requesting device from the accessed private key. The apparatus may implement the method.
Network device authentication
A method for authenticating an origin of a network device. The method includes reading one or more encrypted parameters from a memory of the network device, decoding the one or more encrypted parameters, and determining whether one or more of the decoded parameters match parameters obtained from a trusted platform module (TPM) installed in the network device and/or a read only memory (ROM) of the network device. In response to a mismatch between the decoded parameters and the parameters obtained from the TPM or the ROM, at least one of suspending operation of the device or transmitting a report of an authentication failure across a network on which the device is operating.
SECURE COMPLIANCE PROTOCOLS
In some examples, a secure compliance protocol may include a virtual computing instance (VCI) deployed on a hypervisor and may be provisioned with hardware computing resources. In some examples the VCI may also include a cryptoprocessor to provide cryptoprocessing to securely communicate with a plurality of nodes, and a plurality of agents to generate a plurality of compliance proofs; the VCI may communicate with a server corresponding to a node of the plurality of nodes; and receive a time stamp corresponding to at least one compliance proof based on a metric of a connected device.
Microcode signature security management system based on trustzone technology and method
A microcode signature security management system based on a Trustzone technology comprises the steps of: starting a normal operating system; acquiring the signature-encrypted microcode file and outputting the signature-encrypted microcode file and a switching signal by the normal operating system; receiving the switching signal and starting the monitor mode by the microprocessor to start a secure operating system; receiving the signature-encrypted microcode file, performing signature verification on the signature-encrypted microcode file, loading the file when the signature verification passes, otherwise outputting microcode error information when the signature verification fails by the secure operating system. The security of microcode is ensured on the basis of a secure operating system safety environment to which a system layer is inaccessible. A cryptography tool measure is adopted, so that the security, integrity and correctness of loaded microcode are ensured, and the risk of breaking, modifying and replacing an existing microcode management mechanism is lowered.
Systems and methods for bootstrapping ecosystem certificate issuance
An ecosystem for managing a public key infrastructure (PKI) includes an electronic device having at least one silicon component, an ecosystem manager configured to create at least one PKI keypair, a root certificate, and a bootstrapping certificate, and a device manufacturer configured to integrate into the electronic device the at least one silicon component. The device manufacturer is further configured to integrate into the at least one silicon component a public key of the at least one PKI keypair and the bootstrapping certificate. The ecosystem further includes an ecosystem approved test lab (ATL) configured to test the electronic device having the integrated silicon component, the public key, and the bootstrapping certificate. The ecosystem ATL is further configured to confirm that the bootstrapping certificate complies with predetermined standards of the ecosystem.