Securing UART in IoT Devices: From RSA Key Exchange to AES Encryption

With cryptographic blocks built into modern microcontrollers, developers can now protect every communication channel, even legacy interfaces like UART that traditionally lack built‑in security.

High‑profile data breaches in IoT systems have made it clear that offering a great product is no longer enough—devices must deliver end‑to‑end encryption to stay competitive.

While many protocols embed security natively, UART remains a plain, no‑ACK interface that can be read or tampered with if the baud rate is known. To guard against eavesdropping and injection, the endpoints themselves must encrypt and authenticate the data.

Symmetric and asymmetric security

Cryptographic protection is usually split into two categories: symmetric and asymmetric algorithms. Symmetric keys—shared by sender and receiver—offer fast encryption, but the key must be exchanged securely. Asymmetric key pairs solve this by allowing one side to encrypt a symmetric key with a public key; only the holder of the corresponding private key can decrypt it.

RSA is the most common asymmetric scheme for key exchange, while AES is the workhorse for data encryption due to its efficiency and low resource footprint.

Public and private key encryption

RSA’s mathematical complexity ensures strong security but requires significant computational power, which can be costly in embedded real‑time systems. For most IoT devices, a hybrid approach—RSA to exchange an AES key, then AES for bulk data—provides the best balance of speed and security.

In practice, the receiver generates an RSA key pair and publishes its public key. The sender creates a random AES key, encrypts it with the receiver’s public key, and sends it back. The receiver decrypts the AES key with its private key, and all subsequent messages are encrypted with that key.

Figure 1: Secure exchange of AES key using RSA. (Source: Infineon)

Because only the intended receiver holds the private key, an attacker cannot recover the AES key even if they intercept the channel. All further communication is then protected from eavesdropping and tampering.

Firmware vs. hardware implementation

Implementing cryptographic algorithms purely in firmware is resource‑heavy: it consumes CPU cycles, increases latency, and raises power consumption. Modern MCUs mitigate this with dedicated cryptographic accelerators that offload heavy operations to specialized hardware blocks, drastically reducing footprint and cost.

Infineon’s PSoC 6 MCU exemplifies this approach. Its built‑in cryptographic engine supports AES, DES, TDES, RSA, SHA, and CRC, allowing developers to deploy robust security without a more powerful processor.

True random numbers

Randomness is critical for key generation. Deterministic firmware can produce predictable keys, making brute‑force attacks feasible. A True Random Number Generator (TRNG), such as the six ring oscillators in the PSoC 6, introduces physical noise to generate unpredictable keys.

For a 16‑byte AES key, the TRNG generates 128 random bits—yielding 2^128 possible keys, far beyond brute‑force reach. Additionally, regenerating the key on every reboot limits the exposure window for any compromised key.

Ensuring integrity and authenticity

UART’s lack of ACK means there is no inherent guarantee that a message is complete or uncorrupted. To counter this, a cryptographic hash (SHA) is appended to each message before encryption. The receiver, after decryption, recomputes the hash and verifies it against the received value. A mismatch indicates tampering or transmission error, causing the message to be discarded.

Figure 2: Hash ensures message integrity during secure exchanges. (Source: Infineon)

For additional authenticity, the sender can sign the message with its private key; the receiver verifies the signature using the sender’s public key, guaranteeing that the message originates from the legitimate source.

By integrating RSA, AES, TRNG, and SHA into the MCU’s cryptographic block, developers can secure UART—a traditionally unprotected interface—without compromising performance or cost.

—Harigovind A and Rakshith M B, Senior Application Engineers, Infineon Technologies

>> This article was originally published on our sister site, EDN.