Microsoft Technology Licensing, LLC

Felix Stefan Domke

Ling Tony Chen

Bradley Joseph Litterell

Ankur Choudhary

Ryan James Fairfax

Kenneth D Ray

Kambiz Rahimi

Jay Scott Fuller

Kevin Thomas Weston, Jr

Dylan Keith Garrett

Edmund Bernard Nightingale

Michael G Love

George Thomas Letey

Jaeyeon Jung

Avdhesh Chhodavdia

Kenneth M McGrail

A TPM is implemented in an SOC for thwarting PIN state replay attacks. Programmable fuses are used as a counter and an on-die RAM stores a blown-fuse count and a TPM state that includes a PIN-failure count and a fuse count. TPM initialization includes incrementing the TPM state PIN-failure count if the blown-fuse count is greater than the TPM state fuse count. Once a PIN is received, if the TPM state PIN-failure count satisfies a PIN failure policy and the PIN is correct, the TPM state PIN-failure count is cleared, and if the PIN is incorrect, a fuse is blown and the blown-fuse count is incremented. If the fuse blow fails, TPM activity is halted. If the fuse blow succeeds, the TPM state PIN-failure count is incremented and the TPM state fuse count is set equal to the blown-fuse count. The TPM state is saved to off-die non-volatile memory.

Fuse based replay protection with conservative fuse usage

A TPM with programmable fuses in an SOC includes an on-die RAM storing a blown-fuse count and a TPM state read from off-die NV memory. During initialization, if the blown-fuse count is greater than a TPM state fuse count, a TPM state PIN-attempt-failure count is incremented, thereby thwarting a replay attack. If a PIN satisfies a PIN failure policy, and if a TPM state previously-passed-PIN indicator is set to true, a fuse is blown and the blown-fuse count incremented depending on the PIN being incorrect, but if the TPM state previously-passed-PIN indicator is set to false, a fuse is blown and the blown-fuse count incremented independent of whether the PIN is correct or incorrect. The TPM state fuse count is set equal to the blown-fuse count. If a counter cleared before processing the PIN remains cleared during the next initialization, a fuse voltage cut is detected and a penalty imposed.

Fuse based replay protection with dynamic fuse usage and countermeasures for fuse voltage cut attacks

A TPM with programmable fuses in an SOC includes an on-die RAM storing a blown-fuse count and a TPM state including a PIN-attempt-failure count and a fuse count, read from off-die NV memory. During initialization, if the blown-fuse count is greater than TPM state fuse count, TPM state PIN-attempt-failure count is incremented, thereby thwarting a replay attack. A PIN is received for access, and if the TPM state PIN-attempt-failure count satisfies a policy, a fuse is blown and the blown-fuse count incremented. If the fuse blow fails, TPM activity is halted. If the fuse blow succeeds and the PIN is correct, the TPM state PIN-attempt-failure count is cleared, but if the PIN is incorrect the TPM state PIN-attempt-failure count is incremented. TPM state fuse count is set equal to the blown-fuse count, and the TPM state is saved to off-die NV memory.

Fuse based replay protection with aggressive fuse usage and countermeasures for fuse voltage cut attacks

The disclosed technology is generally directed to embedded device updates. In one example of the technology, a request for a nonce from a device is received. The nonce is sent in response to the request. An authentication request that includes the nonce, a set of measurements associated with the device, and a cryptographic signature generated from a private key associated with the device is received. The device is validated based on the authentication request. In response to successful validation of the device, a short-term certificate is generated for the device.

Dynamic certificate management as part of a distributed authentication system

The disclosed technology is generally directed to the authentication of software. In one example of the technology, a private attestation key is stored in hardware. In some examples, during a sequential boot process a hash is calculated, in an order in which the software stages are sequentially booted, of each software stage of a plurality of software stages. The hashes of each software stage of the plurality may be cryptographically appended to an accumulation register. The accumulation register may be used to attest to validity of the software stages. The plurality of software stages may include a first bootloader, a runtime for a first core of a multi-core processor, and a runtime for a first execution environment for a second core of the multi-core processor.

Remote attestation for multi-core processor

Specific images of an OS are built using only the driver bindings that are necessary to link the OS to the particular hardware of a client device. A device tree of the client device is analyzed to identify the hardware components. Databases of different hardware source code for various hardware drivers are maintained and used to craft the driver bindings and instances for the hardware of the client device. The device tree is also analyzed to identify compatibility strings of the various hardware on the client device. The hardware source code is searched for these compatibility strings to see if a driver exists in the databases of hardware source code. Specific driver bindings and driver instances with the actual variable names and configuration parameters of the identified hardware drivers are then generated and included in an image of the OS that may be installed on the client device.

Link-time driver polymorphism for embedded systems

A method for secure key exchange. The method comprises receiving a request to certify a key from a communication partner at an interface between an access and tamper resistant circuit block and exposed circuitry. Within the access and tamper resistant circuit block, a first random private key is generated. A corresponding public key of the first random private key is derived, and a cryptographic digest of the public key and attributes associated with the first random private key is generated. The generated cryptographic digest is signed using a second random private key that has been designated for signing by one or more associated attributes. The public key and the signature are then sent to the communication partner via the interface.

Secure key exchange using key-associated attributes

Disclosed is a cryptographic key management system implemented in access and tamper resistant circuitry. The circuitry includes processing circuitry to perform cryptographic processing based cryptographic keys. Cryptographic key registers include key portions and attribute portions. An interface receives commands from exposed circuitry that controls the processing circuitry to perform cryptographic processing based on the keys and associated attributes. The attributes indicate what operations may be performed on, or using, the associated keys. of the associated keys. The attributes indicate intended uses of the keys.

Secure crypto system attributes

The disclosed technology is generally directed to protection against unauthorized code. In one example of the technology, a read request to a restricted region of memory is detected. The read request is associated with a first processor. In response to detecting the read request to the restricted region of memory, a data value that causes an exception in response to execution by the first processor is provided.

Growing community of inventors

Luebeck, Germany

Felix Stefan Domke