Overview

Increasingly consumer and industrial appliances are evolving to be IoT connected devices with embedded software and a footprint in the cloud. This makes them susceptible to hacking by criminals, insiders, and others; and counterfeiting by unscrupulous manufacturers. Faced with these risks, appliance and IoT manufacturers are using cryptographic keys to:

•  Integrate digital certificates that uniquely identify them as the manufacturer;
• Secure device boot code (“secure boot”) to only load software from an authenticated source. 

Unfortunately, the evolving sophistication of attackers has resulted in numerous incidents of stolen and compromised keys resulting in:

• Counterfeit devices that appear authentic;
• Devices being turned into bots for large scale DDoS attacks;
• Collection of important user data by unauthorized and often nefarious players;
• Corruption or interference with appliance functionality.

 These and other attacks can have a significant detrimental effect on appliance makers and their customers, tarnishing brand reputation and impacting the bottom line.

Vulnerability of cryptographic keys used to create certificates and sign code is a major issue for embedded code DevOps teams; and code developers / build managers in smaller organizations. When keys are compromised, both digital certificate and boot code operations are no longer secure. Often an organizations private keys are at risk due to:

• Keys stored on servers in the clear with only password protection (key loggers and other tools can be used to defeat the password);
• Keys stored in a manner where they can be misplaced or lost;
• Encrypted keys and related information stored on servers that when compromised can lead to decrypting the key;
• Use of private keys in server/software crypto operations that expose the unencrypted keys during these operations;
• Weak keys (easy to break)
• Singular control of private keys such that an irresponsible or disgruntled employee can perform or prevent sensitive crypto operations.

Cryptographic key best practices dictate that a “clear text” private key should never be exposed; and if transferred, it must be encrypted. This means that key creation, storage and use should take place in a secure environment, and use should be restricted to authorized personnel, or a quorum of authorized personnel.

These best practices can be achieved by introducing a highly secure and reliable Hardware Security Module (HSM), like the Engage BlackVault HSM into the key management process. An HSM is a specialized hardware device where keys are generated, stored, and used in a secure cryptographic boundary.

Unlike traditional HSMs, the BlackVault HSM incorporates a touch screen color display for ease of use and provides an integrated smart card reader, and secure Ethernet / USB ports. It’s also much more effective than software only solutions due to physical and logical barriers to attack, including deleting keys if tamper is detected. The BlackVault HSM, unlike USB and smart card tokens, provides multi-factor and Quorum authentication and supports network attached environments. It’s long battery life also allows for easy transport and offline storage in a secure room or safe.

The BlackVault HSM performs all cryptographic operations inside of a silicon-based FIPS Level 3 tamper reactive boundary, and private keys are never exposed. In addition, if there is an environmental, electrical, or physical breach; the cryptographic keys will be deleted (“zeroized”). Prior to back up, private keys are encrypted and the cryptographic material can be distributed across multiple smart cards for additional security.

The BlackVault HSM key generation and code signing capabilities are augmented with a powerful cryptographic engine that generates all the required RSA key types and sizes, a variety of hash algorithms (SHA2, SHA1, MD5/MD2, etc.) as well as elliptical cryptography. Hardware generated entropy ensures truly random numbers are used in cryptographic operations such as key generation.

The BlackVault HSM can also prevent code from being signed without approval from designated members of the DevOps team (QA, development, product management, etc.). Using the Quorum feature, each signatory is assigned a smart card and PIN. The code can’t be released (signed) until all required signatories are authenticated by inserting their smart card into the BlackVault HSM and entering their corresponding pin (multi-factor authentication).

The signing functionality of the BlackVault HSM not only allows for the signing of whole executables, but also is capable of signing hashes of any file type. Allowing multiple teams using different development environments, a singular solution for signing. 

Integrating the BlackVault HSM with embedded code signing is straight forward. Simply use the included tools that come with the HSM to create and manage keys. Once the key has been created the BlackVault can be used for cryptographic operations such as code signing. It’s also easy to transfer existing keys and certificates to the BlackVault. 

Using the BlackVault to protect embedded systems from counterfeiting and hacking ensures:

• Private signing keys are secured with best practices FIPS Level 3 certified technology;
• Crypto operations with the Private Key are performed in a FIPS Level 3 silicon cryptographic boundary;
• Code signing and other sensitive operations require “M of N” quorum approval;
• Keys can be securely backed up on multiple smart cards or a BlackVault clone;
• The risk of key theft or loss is removed;
• HSM authentication can’t be compromised from intermediary software or devices due to the BlackVault’s integrated multi-factor single trust path authentication.