This article describes four examples of using cryptographic

techniques in the design of firmware to protect a device

against malicious activity.
Dayman Pang

What you’ll learn:

 How to perform over-the-air (OTA) updates safely.

 Best methods for encrypting communication on a host network.
 Secure key sharing and asymmetric cryptography.
 Implementation of authentication.

Firmware—permanent software programmed into read-only memory that provides

the low-level control for a device's hardware—is a fact of life for every embedded
electronic device.

Equally a fact of life is the possibility that the device finds itself the target of
malicious activity. Principles of cryptography often play an important part in the
protection of a device against attackers when considering the design of its firmware.
This article will discuss four examples of how embedded processing can be made
more secure using cryptographic techniques: performing over-the-air (OTA) updates
safely; encrypted communication on a host network; secure key sharing; and
authentication.

Safe OTA Updates

After development and mass production, OEMs require the ability to update the
firmware within a deployed device to correct bugs and add new product features. The
most practical way to perform such an update, especially when a large number of
devices must be updated, is for each device to download the new firmware over-the-
air, most commonly from a server on the internet.

With communication on the internet, data integrity and authenticity are widespread
concerns. Potential hazards like man-in-the-middle (MITM) attacks make it essential
to verify that a device actually downloads what it thinks it has. If it downloads and
installs what an attacker is passing off as legitimate firmware, then the attacker has
successfully hijacked the device.

Thus, the device must be able to ascertain that the downloaded firmware image is
from a trusted source, and that it’s exactly the one provided by that source and not
altered in any way. One common approach is to use a digital signature. Digital
signing and signature verification are cryptographic algorithms used to verify the
authenticity of data, in this case a firmware image file.

The process, based in asymmetric cryptography, employs a pair of cryptographic

keys—one designated as a public key and the other a private key. The trusted source
uses the private key to sign the legitimate firmware image file and makes the
signature available for download along with the image file. The device downloads
both the image file and the signature, and uses the public key to verify the signature.
If the image file is exactly the one that was signed with the private key, then the
signature will verify successfully. However, if the image file differs from the one
signed with the private key even by one byte, signature verification will fail.

Keeping the technical details brief, the digital signature is generated by computing
a hash (or digest) over the entire image file and encrypting this hash with the private
key. The downloaded signature is verified by decrypting it with the public key and
comparing the result with a hash computed over the entire downloaded image file.
Signature verification is successful if these two items compared are equal.

The public key resides in the device for the purpose of performing such a signature
verification whenever needed. Obviously because any file digitally signed by the
private key would authenticate as being legitimate, the private key must be kept
secure in a safe place so that it doesn't fall into the wrong hands.

We therefore have a means for the device to prove that the firmware image it’s
downloaded is identical to the one from our trusted source and thus safe to install, or
it’s a fake and must certainly not be installed. Without such a mechanism, OTA
updates could be vulnerable to hackers seeking to introduce their own code into the
embedded device (Fig. 1).
1. A safe over-the-air firmware update implemented by digitally signing and verifying
the firmware image.

Encrypted Communication on a Host Network

Just as OTA updates need to be performed securely, so does network communication

in general. This is especially true on a public network like the internet because
accessibility to potential hackers becomes that much greater—either by directly
connecting to the device or eavesdropping on the traffic traveling to and from the
device.

The device and all connecting peers should encrypt their communication with one
another. Plaintext traffic can be easily analyzed by hackers, either to steal sensitive
information or understand how to mimic the communication. By doing the latter, a
hacker could send malicious commands to control the device and the device would
respond to them, believing that they’re coming from a legitimate peer.

The easiest way to implement encryption and decryption between two

communicating nodes is to use an algorithm like AES, which encrypts outbound
traffic and decrypts inbound traffic using the same cryptographic key in both nodes.
AES is an example of a symmetric cipher.

A basic scheme like this has the advantages of simplicity and speed. It’s
straightforward to implement in firmware. Plus, AES is fast and requires relatively
low computing power, making it an attractive option for embedded devices.
However, its main weakness is susceptibility to compromise. Because the same key is
pre-installed to the device and to all legitimate peers—and it doesn’t change—hackers
are afforded more opportunity to compromise it. They have more bearers of the key
to target, and no time limit to discover the key.

One improvement would be to change the key periodically. Then even if a hacker
succeeds in obtaining the key, it will not permit interaction with the device or
decryption of future traffic if it’s expired and a new key has become active.

But when a key change occurs, how can the new key be communicated safely among
all of the peers? Remember, they’re on a public network where eavesdropping is a
major concern. The answer lies once again in introducing techniques associated
with asymmetric cryptography. It will be relevant to mention that asymmetric
algorithms are relatively more complex, and therefore require more computing
power than their symmetric counterparts.

The benefit of using both symmetric and asymmetric algorithms together is that it
enables the implementation to take advantage of each one’s strengths, while at the
same time not being adversely impacted by its limitations. Protection of data traffic
needs to happen continuously. Therefore, it makes sense to encrypt and decrypt
symmetrically to be power-efficient.

The encryption key should be changed periodically because a static key can be
vulnerable, but no symmetric method is available to do it safely. An asymmetric
approach is available; however, it’s not very power-efficient. Fortunately, this would
be an occasional event, and its power-efficiency would not be critical. Consequently,
it’s appropriate to change the key asymmetrically.

The remainder of this article elaborates on the limitation of a system that secures
data traffic only with a symmetric cipher, and on how the key sharing mechanism
would work in an improved design that uses an asymmetric approach. In addition, it
will be demonstrated that an asymmetric algorithm can be used for authentication to
guard against types of attacks wherein a hacker seeks to impersonate the embedded
device or a communicating peer.

But first, a note about using standardized networking protocols…

We’re describing a method by which network communication over an arbitrary
medium can be made more secure with the help of principles based in asymmetric
cryptography. However, please understand that it’s not be recommended to devise
your own secure communication scheme as described here if your medium of
communication already comes with a well-defined and standardized security
infrastructure.

For example, if your device will be talking to peers on a TCP/IP network over Wi-Fi,
then very likely you should be using Transport Layer Security (TLS) to secure it. If
your device will communicate over Bluetooth Low Energy, then LE Secure
Connections could be the best approach, at least at the time of this writing.

Furthermore, commercially available modules for popular media such as these

usually come with stable and tested networking stacks. They allow the designer to
support the standardized protocols while implementing relatively little custom code,
and hence with less chance of introducing bugs. Security is both complex and
important, so you would not want to risk exposing vulnerabilities in your device with
a custom implementation that doesn’t get it exactly right.

If your communication medium doesn’t already offer such standardized networking

and security, though, then protocols could be designed using an approach such as the
one discussed here. For example, any number of sub-GHz radio modules on the
market would need a custom protocol if you were using one of them in your device.
But whether or not your case calls for a custom design, hopefully this article will be
informative and useful for understanding the typical kinds of mechanisms that are
found in asymmetric cryptosystems.

And now, back to the limitation of symmetric ciphers…

Earlier, we mentioned that a symmetric encryption algorithm like AES is ideal for
protecting embedded-device communications because it computes quickly and
requires relatively low computing power. This is particularly important for battery-
powered devices that must be able to run for a long time before needing a recharge or
battery replacement.

We also identified the shortcoming, however, that with a simple method employing
only an algorithm like AES, both communicating nodes use the same unchanging
secret key, which can suggest a possible vulnerability to hackers. If a hacker is able to
discover this secret key, it will then be possible for him/her to decrypt all captured
communications encrypted with it—past, present, and future—as well as interact
maliciously with the compromised node. This would clearly be a serious issue and
potentially disastrous depending on the sensitivity of data transferred between the
device and a legitimate peer, or the ramifications of a hacker being able to interact
with them.

The ability to change the secret key periodically would therefore be very
advantageous. If one key did become compromised, the hacker would be able to
decrypt only the network traffic encrypted with that one key before the next key
became active, as well as interact with the device only until that next key became
active.
But how can the secret key be changed safely over the communication network? It’s
the very network which we suspect the hackers to be eavesdropping on, and which
we’re aiming to protect by encrypting. Transmitting a new key in plaintext over the
network would be problematic, as it would be blatantly visible to the eavesdropping
hacker. Transmitting a new key encrypted with the previous key would be equally
problematic, because it raises the question, "How does the very first key get
transmitted when the two nodes first begin communicating?" Furthermore, the
whole reason for activating a new key is because we suspect that the previous key
may have been compromised.

Secure Key Sharing

This is where principles of asymmetric cryptography can help. The effectiveness of

asymmetric cryptography depends on so-called trapdoor one-way functions. Such
functions compute easily in the forward direction but are extremely difficult to
compute in the inverse direction without some piece of secret information.

RSA encryption, for example, which is widely used to secure internet traffic, operates
with the plaintext message being the input to such a trapdoor function, and the
ciphertext being the output from it. That is, the (forward) encryption is easy, whereas
the (inverse) decryption is extremely difficult if we don't have the private key (the
piece of secret information).

Secure key sharing can be achieved by taking advantage of this property in another
trapdoor one-way function, to perform something called a Diffie-Hellman key
exchange. Each of the two nodes performing such a key exchange inputs its own
private number as well as a common publicly shared number into the trapdoor
function, and publicly transfers its output result to the other node.

This particular trapdoor function has an additional special property: When each
node computes the function a second time, with the output result received from the
other node as input in place of the common publicly shared number, the result of this
second computation for both nodes is the same. This common result is the new secret
key.

The mechanism amounts to secure key sharing because the new secret key itself isn’t
actually shared over the network for an eavesdropper to see (Fig. 2). The two nodes’
private numbers would be needed to derive the new key. The trapdoor function
outputs that are shared over the network are of no use to an eavesdropper for
computing those private numbers, due to the one-way nature of the trapdoor
function (i.e., extreme difficulty to compute in the inverse direction).
2. Secure key sharing by using a trapdoor one-way function to perform a Diffie-
Hellman key exchange.
At any time and with any frequency of our choosing, we have a means for the
embedded device and any peer it needs to communicate with to agree on a new secret
key in a safe way. This new key can subsequently be used for symmetric encryption
and decryption until the key changes again. If any secret key is discovered, then the
amount of transferred data a hacker can hope to decrypt with it will depend on how
frequently this new key agreement mechanism is invoked.

However, it should be noted that this frequency should be chosen carefully. As we

already mentioned, symmetric cryptography operations are less computationally
expensive and power hungry than asymmetric ones. That’s why we chose a
symmetric cipher like AES to perform all encryption and decryption. We should be
mindful of whether adding the mechanism for changing the secret key at our chosen
rate appreciably impacts the embedded device's battery life.

Authentication

Although we now have a method for securely sharing secret keys, this only helps to
protect our embedded device from breaches in which a key used for communication
with a legitimate peer is somehow discovered. We also must address the possibility
that a hacker may impersonate the embedded device to the legitimate peer or vice
versa and seek to obtain its own key!

To do so, the impersonator would carry out a successful key agreement as described
in the preceding section, and then have fully encrypted conversations with the device
or peer without the knowledge that it’s actually conversing with an attacker. Note
that if the hacker impersonates each to the other at the same time, it’s known as a
MITM attack.

If the hacker knows how to participate in the Diffie-Hellman key exchange, then
there’s nothing in the key exchange by itself to prevent the hacker from succeeding.
For that, we need the help of another mechanism from asymmetric cryptography,
known as authentication.

Authentication is actually the same process as digital signature verification, which we

introduced earlier in this article. Recall that an over-the-air firmware update file
should be verified to come unaltered from a trusted source, and that a common
method is for the file provider to apply a digital signature to the file and the
embedded device to verify this signature when downloading the file. This same
verification process is useful in the present scenario, except that now what needs to
be verified is the legitimacy not of a firmware image file, but rather a message in the
Diffie-Hellman key exchange.

A separate RSA key pair should be generated for each embedded device and its
legitimate peer. The device's private key is installed in the device and its public key in
the peer. For safety, this should be done over a trusted communication channel and
not the network that a hacker could access. Typically, it would happen at production
time, or when the device is first deployed in the field. The trusted communication
channel could be, for example, USB to a locally connected laptop computer.
Similarly, the peer's private key is installed in the peer and its public key in the
device, also over a trusted channel.
When the device sends its messages to the peer during the key agreement process, it
signs these messages using its private key. When the peer receives the messages, it
verifies the accompanying signature using the device's public key, thereby
authenticating that the messages were in fact sent by the device. Similarly, the peer
signs its key agreement messages using its private key, and the device authenticates
the peer using the peer's public key. More specifically, digital signing employs a
trapdoor one-way function like the RSA encryption function mentioned
previously (Fig. 3).

3. Asymmetric cipher-based authentication implemented by digitally signing and

verifying a message.

The hacker doesn’t know the private key of either the embedded device or its
legitimate peer. Furthermore, the hacker can’t derive either private key from
signatures captured eavesdropping on the key exchange messages sent between the
two. That’s because, once again, the digital signing trapdoor function is extremely
difficult to compute in the inverse direction. Without either private key, the hacker is
unable to sign its own key exchange messages in a manner that the device or the peer
will find acceptable, and therefore can’t impersonate either one to carry out a
malicious key exchange successfully.

In summary, we can ensure safe over-the-air updates by digitally signing and

verifying the firmware images, and possibly implement a proprietary method for an
embedded device to communicate securely on a network. Though it would not be
advisable actually to implement such a method when a popular and standardized one
is appropriate, nevertheless we hope readers have found the explanation to be of
value.

We pointed out the vulnerability of a scheme based solely on a symmetric cipher. We

then described how such a scheme can be improved by introducing a secure key
sharing feature that uses asymmetric cryptography principles. And finally, we
showed how asymmetric cipher-based authentication can further help to guard
against MITM and other impersonation attacks.