Cryptographic Implementations: Hardware vs. Software

This article is part of the Communication Series:  The Cryptography Handbook

Members can download this article in PDF format.

Modern cryptographic algorithms can be implemented using dedicated cryptographic hardware or software running on general-purpose hardware. For various reasons, dedicated cryptographic hardware provides a better solution for most applications. The table below lists reasons why hardware-based cryptographic solutions are more desirable.

Secure Boot and Secure Download—What Are They and Why Are They Important?

Among the everyday IoT devices that use embedded hardware are:

• Home devices: Wi-Fi cameras, IoT thermostats, and smoke detectors
• Medical devices
• Wearables, fitness trackers, or smart watches
• Industrial machines such as robotic arms in factories

Almost all of these devices (Fig. 1) contain boot firmware or downloadable data that access the internet, which puts them at risk. Boot firmware is essentially saved in nonvolatile memory inside the device. It’s the brains of the device. This software is updated from time to time to correct and enhance certain features. This can be anything from a new intruder detection algorithm for a Wi-Fi camera or the angle of an industrial robot arm for better positioning of a weld.

This article covers all of the necessary steps needed to securely boot and upload new firmware in a connected device.

Why Protect IoT Device Firmware or Data?

IoT devices must be trustworthy, which means the device firmware and critical data must be verified to be genuine. In a perfect world, boot firmware and configuration data would be locked down at the factory, but customers have come to expect firmware updates and reconfiguration to be available over the internet. And that’s the problem—malicious actors can use these network interfaces as a conduit for malware.

If someone gains control of an IoT device, they may take control of the device for malicious purposes. For this reason, any code that purports to come from an authorized source must be authenticated before it’s allowed to be used.

An attacker may deliver malware to an IoT device by various means (Fig. 2):

• If the attacker can gain physical access to the device, then malware may be introduced via a physical connection (such as USB, Ethernet, etc.).
• Operating systems often exhibit vulnerabilities that are closed as they’re discovered by means of a patch. If an attacker can access an unpatched system, they may be able to introduce malware.
• Frequently, IoT devices will contact update servers to determine if updated firmware or configuration data is available. An attacker may intercept the DNS request and redirect the IoT device to a malicious source that hosts the malware or corrupt configuration data.
• The authentic website may be misconfigured in such a way to allow an attacker to take control of the website and replace authentic firmware with one that contains the attacker’s malware.

We can prevent infiltration and protect against malware injection by using secure boot and secure download. Thus, the IoT device can trust the updates being received from the command/control center.

Protecting from malware injection with secure boot/download means the IoT device can trust the updates received from the command/control center.

Note that if a command/control center wants to fully trust the IoT device, there’s an additional step that involves authenticating the IoT device’s data. How do we go about protecting these devices by using secure boot and secure download?

Authentication and Integrity of the Firmware

Authentication and integrity can provide a way to:

• Ensure that the targeted embedded device runs only authorized firmware or configuration data.
• Confirm that the data is trusted and not subsequently modified.
• Allow cryptography to be used to prove that data is both authentic and has integrity.
• Utilize cryptographic digital signatures, like a seal or manual signature at the bottom of a letter.

With authentication and integrity, the firmware and configuration data are loaded during the manufacturing phase and all subsequent updates are digitally signed. This way, the digital signature enables trust during the device’s entire lifetime. These features of digital signature are paramount to providing security:

• The digital signature used must be computed by a cryptographic algorithm.
• To bring the highest level of security, the algorithms need to be public and well-proven.

For our secure solution, we’ll examine asymmetric cryptographic algorithms, specifically the FIBS 186 ECDSA.

Asymmetric Cryptography Applied to Secure Boot/Download

Asymmetric cryptography uses a public/private key pair for algorithm computations (Fig. 3):

• The start of any key-pair generation includes selecting a random number to be used as the private key.
• The random number is input into the key generator and the computation begins outputting a public key.
• The public key is made public (it can be distributed freely to all without any security risk).
• However, the private key is critical information that must be kept confidential.

The fundamental principles of secure download in asymmetric cryptography are:

• The firmware developer uses the private key for signing.
• An embedded device (or an IoT device) uses the public key for verification.

So why use asymmetric key cryptography?

• The advantage is that no private key is stored on the embedded device.
• When using asymmetric cryptography, there’s no way an attacker can retrieve the private key.
• Lastly, the algorithm chosen (i.e., ECDSA) makes it mathematically infeasible to derive the private key from the public key.

First, let's look at an example of what must occur at an R&D facility that utilizes asymmetric key cryptography.

R & D Facility

• We start with complete firmware.
• The firmware must be put through a SHA-256 multi-block hash computation.
• The private key and hash are input into the ECDSA signing algorithm. The output is a unique signature that could have only been signed by a private key.
• Combine our firmware with the signature and send it out upon request for field usage.

Figure 4 illustrates these points in greater detail. Now let’s look at field usage.

Field Usage

• The embedded device receives the firmware and signature.
• The firmware will go through a SHA-256 multi-block hash computation.
• Our embedded device will already contain the public key created during the key generation at the R&D facility.
• The signature and the other ingredients will then be used as input for the ECDSA verify.
• The result from the ECDSA verify will determine if the firmware can be used by the embedded device.
• If the result is a PASS, then the embedded device accepts the firmware that has both authenticity and integrity.
• If the result is a FAIL, then the firmware is rejected.

The following video explains how firmware can be securely downloaded to a remote system:

Secure Boot and Secure Download Using DS28C36

A number of embedded devices don’t have a secure microcontroller with the computational capacity to perform the required calculations to verify the authenticity and integrity of downloaded firmware or data. One cost-effective hardware-based IC solution is the DS28C36 DeepCover secure authenticator (Fig. 5).

Steps for secure boot and secure download:

1. As previously discussed, a system public-private key pair for the secure boot or secure download function is established at the R&D facility. The system private key of this pair is used to sign firmware or data that ultimately is verified by the DS28C36 embedded in the end system. This system private key never leaves the controlled development environment. The system public key of this pair is installed in the DS28C36 in a key register location that has an "authority key" attribute, which is a configurable setting in the DS28C36.
2. The system private key is used to compute the digital signature of the firmware or data.
3. The DS28C36 with the preprogrammed system public key is located on the interface to the host processor.
4. When firmware is required to be run by the processor, it’s first retrieved by the processor boot manager and delivered to the DS28C36 in sequential 64-byte blocks to compute a SHA-256 hash.
5. After the DS28C36 completes the SHA-256 hash computation, the processor delivers the ECDSA signature of the firmware or data that was computed in the development environment and appended to the file.
6. After the DS28C36 receives the ECDSA signature, the processor sends commands to use the preinstalled system public key to perform a signature verification.
7. If the DS28C36 verifies the signature, a pass result parameter byte and a GPIO pin set to logic 0 is delivered to the processor. The status of this pin and parameter byte result acts as a go/no-go result to the processor to run the now known trusted firmware or data update.
8. In addition, if the command/control center would like to trust the DS28C36, an extra ECDSA signature engine is optionally available.

In summary, we have shown a proven security solution for secure boot or secure download using the DS28C36 that addresses threats to IoT devices. This secure authenticator IC offloads the heavy computational math involved to prove both authenticity and integrity of firmware or data updates.

For more information about Maxim’s secure boot and secure download solutions, check out:

• DS28C36 I²C Interface DeepCover Secure Authenticator
• DS28E36 1-Wire Interface DeepCover Secure Authenticator

Go to the Security Lab tool to execute this sequence example or use Maxim’s other additional hardware labs.

Bidirectional Authentication for IP Protection

Bidirectional (or mutual) authentication is an important part of secure communication. Both parties of communication should be certain that their counterpart can be trusted. This can be accomplished by proving possession of private information. This information can be shared between the parties, or kept completely private, as long as there’s the ability to prove possession.

Symmetric authentication systems require information to be shared among all participants in a communication. This information is usually called a "secret.” A secret is a piece of information not generally known; it’s known only to those who need it. The secret is used in concert with a symmetric authentication algorithm such as SHA, along with other data shared between participants. The ability to generate a matching signature on both sides of communication proves possession of the secret.

Asymmetric authentication systems (like ECDSA) employ hidden information that’s not shared between parties (known as a “private key”), but is used to produce information that can be known to the public (known as a “public key”). Proper use of the public key proves possession of the private key because the private key is needed to unlock a message locked by the public key and vice versa.

Slave Authentication

To authenticate a slave device in a master-slave configuration, a piece of random data (also known as a “challenge”) is sent to a slave. Along with any shared data between the devices, the challenge is run through a signing operation with a secret or private key to produce a “response” signature. The response signature can be verified by the master because the master is in possession of the shared secret, or a public key that corresponds to the slave’s private key. The general flow of this process is shown in Figure 6.

Authentication generally depends on algorithms that produce signatures proving possession of a participant’s hidden information but make it difficult to discover the information itself. These are known as one-way functions. SHA and ECDSA are examples of such algorithms.

Master Authentication

To prove all parties can be trusted, the master must also need to prove authenticity to the slave. An example of this process is shown in the form of an authenticated write (Fig. 7).

In Figure 7, the master is writing new data into a slave device. However, to complete the write, the slave must verify authenticity of the information by requiring the master to produce a signature based on that information, as well as the master’s hidden data (secret or private key). By using either a shared secret or the public key corresponding to the master’s private key, the slave can verify that the signature is authentic.

The use of one-way functions may allow any eavesdroppers to see all data being transmitted, but it prevents them from determining the hidden information that produced the signatures associated with the data. Without this hidden information, eavesdroppers can’t become impersonators.

This two-way authentication model can easily be used to make sure that intellectual property (IP) stored in a device will be well-protected from counterfeiters.

TRNG Output and Typical Use

Maxim’s ChipDNA secure authenticators have a built-in true random number generator (TRNG) (Fig. 8). This is used by the device for internal purposes. But they also have a command that sends out the TRNG output if the user requests it. At this time, the maximum length of the TRNG output length is 64 bytes. This hardware NIST-compliant random number source can be used for cryptographic needs such as “challenge (nonce)” generation by a host processor.

NIST/FIPS Specifications

Three different specifications are related to TRNGs:

• NIST SP 800-90A
• NIST SP 800-90B
• NIST SP 800-90C

For more details, visit the NIST website.

The next article in the series will cover the threats faced by crypto systems the types of countermeasures that are available, as well as how to plan for threats.

Read more from the Communication Series: The Cryptography Handbook

Zia A. Sardar and Stewart Merkel are Principal Members of Technical Staff, and Aaron Arellano is a Member of the Technical Staff, at  Maxim Integrated.