Securing UART communication interface in embedded IoT devices
Article By : Harigovind A and Rakshith M B, Infineon Technologies
UART is a no ACK communication protocol that can be read by any device if the baud rate is known, and that calls for robust security measures.
With the increasing number of high-profile data and privacy breaches in the Internet of Things (IoT) systems, businesses and consumers have a greater awareness of the need for security when buying connected products. Providing best-in-class products or services is no longer enough. Devices that fail to provide adequate security will fail to be able to compete with those that provide end-to-end security.
Many protocols implement security within the standard and are a built-in part of any controller. Embedded devices that connect via universal asynchronous receiver-transmitter (UART), however, are not protected. UART is one of the simplest digital communication interfaces between devices. It’s a no ACK communication protocol that can be read by any device if the baud rate is known.
To prevent data from being read or injected into the system, the communication channel needs to be secured by the systems sending and receiving the data. Thus, even if an intruder gains access to the communication channel with the correct baud rate, the channel will be protected.
Symmetric and asymmetric security
Communication channels are often secured using cryptographic algorithms. Broadly speaking, cryptographic algorithms can be classified as symmetric and asymmetric. With symmetric key algorithms, the sender and receiver share a single secret key. The sender encrypts the message using the key and shares the encrypted message with the receiver. The receiver then uses the same key to decrypt the message.
The main security concern with symmetric key algorithms is how to securely exchange the secret key between the sender and receiver. If the key is captured by another entity during the key exchange, then that entity can also decrypt messages sent by the sender. Thus, it’s crucial that the key is shared securely with only the sender and the receiver in symmetric key algorithms.
To enable secure symmetric key exchange, asymmetric key algorithms are used. Asymmetric algorithms use different keys for the encryption and decryption processes. Although these keys are different, they are mathematically related. The symmetric key can be securely exchanged by encrypting it with an asymmetric key and the receiver decrypting it using the related asymmetric key. A disadvantage of asymmetric algorithms is that they involve complex mathematical calculations and tend to be compute-intensive.
For the highest level of security, RSA encryption is used as the asymmetric key algorithm. With RSA, a communicating entity has a public key and a private key. The public key, as the name suggests, is shared publicly and available to anyone. In contrast, the private key is held only by the communicating entity. To send a message to the entity, the sender encrypts the message using the entity’s public key. This encrypted message can only be decrypted by the private key. Since the private key is available only to the intended receiver, this ensures that only the receiver can decrypt the message.
Public and private key encryption
RSA uses exponential computations and the prime factorization of very large numbers, making it highly secure but also compute-intensive. Furthermore, implementing RSA in real-time—to avoid latency in communications—would increase system cost by requiring a higher performance processing engine. Many embedded systems don’t require this level of security. Instead, they can utilize a leaner encryption algorithm like Advanced Encryption Standard (AES), which is more practical and cost-effective because it requires fewer processing resources.
AES is a symmetric cryptographic algorithm, which means both sides of the communications channel share a common secret key. The limitation of AES as mentioned above lies in securely sharing the key between the UART sender and receiver without exposing it to external entities. To address this, RSA can be used to encrypt the AES key and securely exchange it. Since the common key only needs to be shared once, the communication channel can bear the complexity and latency of RSA. In other words, the delay to process the RSA algorithm impacts only the initial key exchange, not every message.
Secure key exchange occurs in several stages (Figure 1). First, the UART receiver generates an RSA key pair and shares its public key with the sender. It doesn’t matter if another entity sees the public key because it will only be used to encrypt messages intended for the UART receiver. The sender then randomly generates an AES key and encrypts it using the receiver’s public key. The receiver decrypts the AES key using the RSA private key.
Figure 1 Secure exchange of AES secret key using RSA public and private keys. Source: Infineon
Since only the receiver has access to the RSA private key, the encrypted AES key can only be decrypted by the receiver. This ensures that the AES key is known only to the sender and the receiver, and any intruder with access to the communications channel cannot derive the key. In addition, all subsequent messages between the sender and receiver are encrypted with the AES key, making these messages inaccessible to any other parties not intended to receive them. This also eliminates the threat of man-in-the-middle (MIM) attacks which involve the modification of messages after they have been sent but before they have been received.
Firmware vs. hardware
Implementing security algorithms in embedded devices using firmware poses many design challenges. Cryptographic algorithms, by their nature, tend to be compute-intensive. They also increase memory footprint, add delay to processing, and introduce substantial complexity to systems. As a result, implementing security in firmware will consume substantial CPU cycles and MCU resources. Moreover, to meet real-time application requirements, a higher performance MCU will be required, raising system cost.
Part of the reason so many MCU resources are used is because MCUs are general-purpose processing units. For this reason, many MCUs integrate hardware designed specifically for cryptographic algorithms. With an integrated cryptographic engine, an MCU can provide real-time encryption and decryption of data in a much smaller footprint and at a lower cost compared to an MCU without hardware-based cryptographic processing capabilities.
The PSoC 6 MCU from Infineon is a case in point. It has a dedicated cryptographic block that provides hardware acceleration of cryptographic functions. The cryptographic block is flexible and can be used to support different cryptographic algorithms to ensure that the data is protected. This enables developers to introduce security to embedded IoT devices using encryption standards such as AES, DES, TDES, and RSA and integrity checks such as secure hash algorithm (SHA) and cyclic redundancy check (CRC). Offloading cryptographic functions from the MCU in this manner makes it possible to cost-effectively introduce security to nearly all embedded applications without needing to employ a more powerful processor.
True random numbers
Securing an embedded system, however, requires more than just encrypting communications. Specifically, the AES key the system generates needs to be random. However, MCUs are deterministic, so the keys generated would be deterministic as well, enabling a hacker to use “brute force” to cycle through the different possible random seeds and potentially derive the AES key. Thus, firmware needs a way to generate true random numbers to ensure the randomness of the AES key, so it cannot be brute-forced.
To do this, the cryptographic block must include a True Random Number Generator (TRNG). In the PSoC 6 cryptographic block, for example, the TRNG has six ring oscillators that provide physical noise sources. The ring oscillators contain temperature-sensitive inverters that introduce jitter in the ring oscillator’s signal. This signal gives the MCU access to a true random number source to ensure the randomness of AES keys it generates.
For instance, to generate a 16-byte key, a random number is generated 16 times and appended to previous numbers. This makes for the possibility of 2^128 keys. It’s more than enough to prevent the “AES” key from being brute-forced or guessed.
Some crypto-attacks focus on analyzing captured communications. With enough resources, any key can eventually be broken. To address this possibility and increase the overall security of the communications channel, the AES key is generated on every reboot. This is a simple but effective measure to increase the security of embedded systems. In short, even if a key is identified by an intruder, the key will likely no longer be in use by the time it can be exploited.
Security with confidence
At this point, it might be tempting to consider the UART interface secure. However, UART is a no ACK communication protocol. This means that the protocol does not have a mechanism to ensure that a message received by the receiver is a) complete as well as b) not corrupted.
A final security stage is required to confirm the integrity of the message. An effective method for achieving this is to use the SHA algorithm to hash the message. Running a message through a cryptographic hash function like SHA produces a hash, an output of fixed length. Because hash functions are irreversible one-way functions, the only way to identify the message that generated a particular hash is to attempt a brute force search of all possible inputs.
Figure 2 A hash function ensures the integrity of communications during secure key exchanges and message transfers. Source: Infineon
Before a message is sent, the hash of the entire message is appended to the message (Figure 2). The message plus hash is then encrypted using the AES key. In this way, the hash can serve as an integrity check. The receiver, after decryption, calculates the hash of the message that it decrypted. The receiver then compares the received hash and the calculated hash. If they are the same, then the message has not been modified. However, if the hashes do not match, this indicates that the integrity of the message has been affected. This could occur because a hacker has tried to modify the message or an error occurred during transmission. In any case, the communication has failed.
Note that the communication channel can further be strengthened for authenticity by signing the message with the private key of the sender. The signed message can be verified using the sender’s public key to verify that only the sender could have sent the message. Put another way, no other party can mimic being the sender since they do not have the private key of the sender, thus ensuring the authenticity of the messages. For more ideas, check out Community Code Examples, which includes many projects from other engineers.
Implementing security has become a necessary consideration in the design of embedded IoT systems. It is crucial for every connected device to be secure and protect user data from being compromised. With cryptographic blocks integrated into MCUs, it has become possible for developers to secure every communications channel, including interfaces such as UART that provide no security themselves.
This article was originally published on EDN.
Harigovind A and Rakshith M B are senior application engineers at Infineon Technologies.