Design for Manufacturing: Cryptographic Techniques for Safer Firmware
This article appeared in ElectronicDesign and has been published here with permission.
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, so that bugs can be corrected, and new product features added. The most practical way to perform such an update, especially when a large number of devices need to 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 is a widespread concern. Potential hazards like man-in-the-middle attacks make it essential to verify that a device has actually downloaded 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.
So, the device must be able to ascertain that the downloaded firmware image is from a trusted source, and that it is exactly the one provided by that source, not altered in any way. One common approach is to use a digital signature. Digital signing and signature verification are cryptographic algorithms used for verifying the authenticity of data, in this case a firmware image file.
The process is based in asymmetric cryptography, and 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 which was signed with the private key, then the signature will verify successfully. If, however, 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 has downloaded is identically the one from our trusted source and therefore safe to install, or is 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.
Figure 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 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.
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 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.