Techniques for secure public exposure of digital data include extracting first digital data comprising one or more batches, each batch comprising a plurality of no more than a number T of packets, each packet containing a plurality of a number n of bits. A random binary matrix A consisting of T rows and n columns is generated. For a first batch, a first random n-bit temporary key is generated. For a packet in the first batch, a first packet vector key is generated based on random non-overlapping pairs of bit positions for both the temporary key and for a first packet-corresponding row of matrix A. An encrypted packet is generated for the packet based on the packet and the first packet vector key. The encrypted packet is exposed publicly.

A secure programming system and method for provisioning and programming a target payload into a programmable device mounted in a programmer. The programmable device can be authenticated before programming to verify the device is a valid device produced by a silicon vendor. The authentication process can include a challenge-response validation. The target payload can be programmed into the programmable device and linked with an authorized manufacturer. The programmable device can be verified after programming the target payload by verifying the silicon vendor and the authorized manufacturer. The secure programming system can provision different content into different programmable devices simultaneously to create multiple final device types in a single pass.

Aspects related to the secure transfer and use of secret material are described. In one embodiment, an encrypted secret key and encrypted revocation data are imported into a trusted execution environment and decrypted with private provider and vendor keys. In this manner, a provider of cryptographic processes is not exposed to the secret key or revocation data of a customer, as the secret key and revocation data are decrypted and stored within the trusted execution environment but not accessed in an unencrypted form. In turn, the provider can receive various instructions to perform cryptographic operations on behalf of the customer. Based on the outcome of a revocation check using the revocation data, the instructions can be performed by the trusted execution environment.

A system and method for opportunistic cryptographic key management includes generating a security capability assessment on a first electronic device based on security capabilities of the device, selecting a key management mode based on the security capability assessment, generating a cryptographic key based on the key management mode, and storing the cryptographic key based on the key management mode.

A device includes a reset resistant store and a trusted key service. The reset resistant store maintains data across various different device reset or data invalidation operations. The trusted key service maintains, for each of one or more operating systems that run on the device from a boot configuration, an encrypted key associated with the boot configuration. The device also has a master key that is specific to the device. Each of the keys associated with a boot configuration is encrypted using the master key. When booting the device, the boot configuration being run on the device is identified, and the key associated with that boot configuration is obtained (e.g., from the reset resistant store or the encrypted key vault). The master key is used to decrypt the obtained key, and the obtained key is used to decrypt secrets associated with the operating system run from the boot configuration.

According to some embodiments, an overall chain-of-trust may be established for an industrial control system. Secure hardware may be provided, including a hardware security module coupled to or integrated with a processor of the industrial control system to provide a hardware root-of-trust. Similarly, secure firmware associated with a secure boot mechanism such that the processor executes a trusted operating system, wherein the secure boot mechanism includes one or more of a measured boot, a trusted boot, and a protected boot. Objects may be accessed via secure data storage, and data may be exchanged via secure communications in accordance with information stored in the hardware security model.

Use of cryptographic key-store hardware security modules is optimized in a system having a first scarce high-security key storage device and a second more plentiful low-security key storage device comprising securing a cryptographic key to the higher security level by initially storing the key in the first storage device, then responsive to an event, evaluating the stored key against one or more rules, and subsequent to the evaluation, reclassifying the stored key for relocation, encrypting the reclassified key using a key-encryption key; relocating the reclassified key into the second, lower-security storage device, and storing the key-encryption key in the first storage device.

A method and system for deterring attacks at potential breach points between servers and an account and login server for creating and subsequent verification of accounts. Various cryptographic primitives are used to manipulate passwords to generate verifiers. The verifiers are used with external hardware security modules (HSMs) to eliminate HSMs and intermediate steps between the HSM and login servers as potential breach points.

Provided is a process that establishes user identities within a decentralized data store, like a blockchain. A user's mobile device may establish credential values within a trusted execution environment of the mobile device. Representations of those credentials may be generated on the mobile device and transmitted for storage in association with an identity of the user established on the blockchain. Similarly, one or more key-pairs may be generated or otherwise used by the mobile device for signatures and signature verification. Private keys may remain resident on the device (or known and input by the user) while corresponding public keys may be stored in associated with the user identity on the blockchain. A private key is used to sign representations of credentials and other values as a proof of knowledge of the private key and credential values for authentication of the user to the user identity on the blockchain.

A diamond asset comprising one or more diamonds and an encryption chip is used to asset-back a cryptographic token that can be used to conduct transactions. The cryptographic token is written to a blockchain using a smart contract that is configured to enable a transaction associated with the token in response to two or more of: a signature by the encryption chip, a signature by the owner of the diamond asset, and a validation of a visual layout of the diamond asset.