Design for Manufacturing: Cryptographic Techniques for Safer Firmware

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 is that much greater, either by directly connecting to the device or by eavesdropping on the traffic travelling 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 to 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 are 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 is straightforward to implement in firmware. It 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 doesn’t change, hackers are afforded more opportunity to compromise it—they have more bearers of the key to target, and no time limit for discovering 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 has 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 are 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 advantages 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, but is not very power-efficient. Fortunately, this would be an occasional event, and its power-efficiency would not be critical. Therefore, it is appropriate to change the key asymmetrically.

In the remainder of this article, we will elaborate 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 makes use of an asymmetric approach. Additionally, it will be demonstrated that an asymmetric algorithm can be used for authentication, to guard against a type 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 are describing here 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 would 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 WiFi, then very likely you should be using TLS to secure this. If your device will be communicating 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 which 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 does not get it exactly right.

If, however, your communication medium does not already offer such standardized networking and security, then protocols could be designed using an approach such as the one we are discussing. There are, for example, any number of sub-GHz radio modules on the market which would need some kind of 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 in the article, we mentioned that a symmetric encryption algorithm like AES is ideal for protecting the communication of an embedded device, because it computes quickly, and requires relatively low computing power. This is especially important for battery powered devices which 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. 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 get compromised, the hacker would be able to decrypt only the network traffic encrypted with that one key before the next key became active, and would be able to 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 is the very network which we suspect the hackers to be eavesdropping on, and which we are 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?” And also, because our whole reason for activating a new key is because we suspect that the previous key may have been compromised.

This is where principles of asymmetric cryptography can help. The effectiveness of asymmetric cryptography depends on so-called trapdoor one-way functions. Such a function is one which computes easily in the forward direction, but is 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 that 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 is not actually shared over the network for an eavesdropper to see. The two nodes' private numbers would be needed to derive the new key, but the trapdoor function outputs which 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).

Figure 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, therefore, 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 then be used for symmetric encryption and decryption until the key changes again. If any one 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, which is why we chose a symmetric cipher like AES for performing all the 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.

Although we now have a method for sharing secret keys securely, this helps to protect our embedded device only from breaches in which a key used for communication with a legitimate peer is somehow discovered. It remains for us to address the possibility that a hacker may actually 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 would be able to carry on fully encrypted conversations with the device or peer, without its knowledge that it is actually conversing with an attacker. Note that if the hacker impersonates each to the other at the same time, it is known as a man-in-the-middle attack.

If the hacker knows how to participate in the Diffie-Hellman key exchange, then there is 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 for 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 of a message in the Diffie-Hellman key exchange.

A separate RSA key pair should be generated for each of the 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 which a hacker may have access to. Typically, this 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. In a similar fashion, 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 similar to the RSA encryption one mentioned previously.

Figure 3: Asymmetric cipher-based authentication implemented by digitally signing and verifying a message.

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

In summary, this has been a discussion of how we can ensure safe over-the-air updates by digitally signing and verifying the firmware images, and how we might implement a proprietary method for an embedded device to communicate securely on a network. While it would not be advisable actually to implement such a method in the case where a popular and standardized one is appropriate, nevertheless we hope that the reader has found the explanation to be of value. We pointed out the vulnerability of a scheme that is based solely on a symmetric cipher. We then described how such a scheme can be improved upon 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 man-in-the-middle and other impersonation attacks.