A method for testing an HMAC implementation for vulnerability to a side-channel attack can include mounting a template attack. The attack can include generating, based on first side-channel leakage information associated with execution of a hash function of the HMAC implementation, a plurality of template tables. Each template table can correspond, respectively, with a subset of bit positions of an internal state of the hash function. The attack can further include generating, based on second side-channel leakage information, a plurality of hypotheses for an internal state of an invocation of the hash function based on a secret key. The method can further include generating, using the hash function, respective hash values generated from each of the plurality of hypotheses and a message. The method can also include comparing each of the respective hash values with a hash value generated using the secret key to determine vulnerability of the HMAC implementation.

In one or more embodiments, a first information handling system may: receive a chained cryptographic hash value determined by a trusted platform module (TPM) of a second information handling system; receive multiple patch identities associated with multiple updated firmware installed on multiple components of the second information handling system; receive an event log associated with output of the TPM as the TPM determined the chained cryptographic hash value; retrieve multiple layered endorsements respectively associated with the multiple patch identities; determine multiple hash values from multiple signatures stored in the multiple layered endorsements; compare the chained cryptographic hash value with the event log; compare multiple event information with the multiple hash values; and determine that the second information handling system has booted into a trusted state based at least on comparing the chained cryptographic hash value with the event log and comparing the multiple event information with the multiple hash values.

Techniques for determining whether a public encryption key is vulnerable as the result of deficiencies in pseudorandom number generation algorithms are provided. In some embodiments, a system may compile a database of cryptographic information received from a plurality of sources, including databases, and network traffic monitoring tools. RSA public keys extracted from the cryptographic information may be stored in an organized database in association with corresponding metadata. The system may construct a product tree from all unique collected RSA keys, and may then construct a remainder tree from the product tree, wherein each output remainder may be determined to be a greatest common divisor of one of the RSA keys against all other unique RSA keys in the database. The system may then use the greatest common divisors to factor one or more of the RSA keys and to determine that the factored keys are vulnerable to being compromised.

A secret key estimation device is provided for determining an estimate of at least one secret key used during a number of executions of a cryptographic function used by at least one cryptographic algorithm. The number of executions of the cryptographic function is at least equal to two. The secret key estimation device comprises an analysis unit for determining a plurality of sets of leakage traces from a side-channel information acquired during the number of executions of the cryptographic function. Each set of leakage traces corresponds to an execution of the cryptographic function and comprising at least one leakage trace. The secret key estimation device further comprises a processing unit configured to determine a statistical distribution of the acquired plurality of sets of leakage traces. The statistical distribution is dependent on a leakage function, the leakage function being represented in a basis of functions by a set of real values. The secret key estimation device is configured to determine the secret key from the statistical distribution of the plurality of sets of leakage traces using an estimation algorithm according to the maximization of a performance metric.

Smart contract code is verified by storing smart contract code, identifying a type system for verifying a determinism of the smart contract code based on a first set of security-level values and a second set of security level values, and verifying the determinism of the smart contract code by taking the first set of security-level values as deterministic values and the second set of security level values as non-deterministic values.

A method of cryptographically secured decentralized testing includes receiving, by a computing device and from a secure test apparatus, an output of a cryptographic function of a secret test result identifier, authenticating the output, and recording, in a data repository, an indication of a test result as a function of the output.

An electronic device such as a hardware security module device comprises a first cryptographic processing circuit configured to receive input data packets and apply thereto a first cryptographic processing to provide output data packets. A second cryptographic processing circuit is provided in the device, configured to receive the output data packets, apply thereto a second cryptographic processing inverse to the first cryptographic processing, and provide comparison data packets as a result of applying the second cryptographic processing to the output data packets received. A comparison processing circuit in the device is configured to compare the input data packets with the comparison data packets, and to produce an error signal as a result of the input data packets being different from the comparison data packets.

Techniques for determining whether a public encryption key is vulnerable as the result of deficiencies in pseudorandom number generation algorithms are provided. In some embodiments, a system may compile a database of cryptographic information received from a plurality of sources, including databases, and network traffic monitoring tools. RSA public keys extracted from the cryptographic information may be stored in an organized database in association with corresponding metadata. The system may construct a product tree from all unique collected RSA keys, and may then construct a remainder tree from the product tree, wherein each output remainder may be determined to be a greatest common divisor of one of the RSA keys against all other unique RSA keys in the database. The system may then use the greatest common divisors to factor one or more of the RSA keys and to determine that the factored keys are vulnerable to being compromised.

Techniques are described for creating and tracking audit trails, including regulatory compliance trails, using a distributed ledger. The techniques include determining, via the first processor, if data is to be provided for use in an audit, and if the data is to be provided then executing an audit trail routing system to route the data into at least one audit trail. The techniques further include storing, via the first processor, the data of the at least one audit trail in a least one block of digital distributed ledger system, and distributing, via the first processor, the at least one block among nodes of the digital distributed ledger system, wherein the digital distributed ledger system is configured to immutably store the data of the at least one audit trail.

Methods and integrated circuit architectures for assuring the protection of intellectual property between third party IP providers, system designers (e.g., SoC designers), fabrication entities, and assembly entities are provided. Novel design flows for the prevention of IP overuse, IP piracy, and IC overproduction are also provided. A comprehensive framework for forward trust between 3PIP vendors, SoC design houses, fabrication entities, and assembly entities can be achieved, and the unwanted modification of IP can be prevented.