ALLPCB
Introduction
High-profile data and privacy breaches in IoT systems have increased awareness of security requirements among companies and consumers when purchasing connected products. Delivering a product or service without sufficient security makes it difficult to compete with devices that provide end-to-end protection.
Many protocols implement security within their standards and include it as part of any controller. However, embedded devices connected via universal asynchronous receiver-transmitters (UART) are often unprotected. UART is one of the simplest digital communication interfaces between devices. It is an unacknowledged protocol, and if the baud rate is known, any device can read the data on the line.
To prevent data from being read or injected into the system, the communication channel between the transmitting and receiving systems must be protected. That way, even if an attacker can access the channel at the correct baud rate, the channel remains protected.
Symmetric and Asymmetric Security
Communication channels are typically protected using cryptographic algorithms. Broadly speaking, cryptographic algorithms fall into symmetric and asymmetric categories. With symmetric-key algorithms, the sender and receiver share a single key. The sender encrypts the message with the key and sends the ciphertext to the receiver, who then decrypts it using the same key.
The main security challenge for symmetric-key algorithms is how to exchange the key securely between sender and receiver. If the key is captured during the exchange, the interceptor can decrypt subsequent messages. Therefore, securely sharing the symmetric key only between the intended parties is essential.
Asymmetric algorithms support secure symmetric-key exchange. Asymmetric schemes use different keys for encryption and decryption, and although they differ, they are mathematically related. A symmetric key can be encrypted using the receiver's public asymmetric key and then decrypted by the receiver's related private key. A drawback of asymmetric algorithms is that they involve complex mathematics and are computationally intensive.
RSA and AES in Combination
RSA is commonly used as an asymmetric algorithm. With RSA, each communication entity has a public key and a private key. The public key is shared openly, while the private key is kept secret by the entity. To send a message to an entity, the sender encrypts the message using the entity's public key; only the corresponding private key can decrypt it. Because the private key is available only to the intended recipient, this ensures that only the recipient can decrypt the message.
RSA uses exponentiation and factorization of very large numbers, making it secure but computationally heavy. Implementing RSA in real time to avoid communication delay requires more powerful processing, increasing system cost. Many embedded systems do not need that level of security and can instead use more compact algorithms such as the Advanced Encryption Standard (AES), which is more practical and cost-effective because it requires fewer processing resources.
AES is a symmetric encryption algorithm, so both parties share a common key. As noted above, the limitation of AES is securely sharing the key between UART sender and receiver without exposing it. To address this, RSA can be used to encrypt the AES key for secure transfer. Because only the public key must be shared, the system only incurs the computational cost of RSA during the initial key exchange, not for each message.
Secure key exchange occurs in several stages. First, the UART receiver generates an RSA key pair and shares its public key with the sender. It is acceptable if other entities see the public key because it only serves to encrypt messages destined for the UART receiver. The sender then randomly generates an AES key and encrypts it with the receiver's public key. The receiver uses its RSA private key to decrypt the AES key.
Since only the receiver has access to the RSA private key, the encrypted AES key can be decrypted only by the receiver. This ensures the AES key is known only to the sender and receiver, and any attacker with access to the communication channel cannot extract it. All subsequent messages between sender and receiver are encrypted with the AES key, preventing any other party from reading them. This approach also mitigates man-in-the-middle attacks, where messages are modified after transmission but before reception.
Firmware vs Hardware
Implementing security algorithms in firmware for embedded devices introduces several design challenges. Cryptographic algorithms tend to be computationally intensive. They increase memory usage, add processing latency, and significantly increase system complexity. As a result, implementing security in firmware consumes substantial CPU cycles and MCU resources, and real-time applications may require higher-performance MCUs, increasing system cost.
Much of this resource use stems from the fact that MCUs are general-purpose processing units. For this reason, many MCUs integrate dedicated hardware designed for cryptographic operations. Compared with MCUs that lack hardware crypto acceleration, devices with integrated cryptographic engines can provide real-time encryption and decryption with lower overhead and cost.
Infineon's PSoC 6 MCU is an example. It includes a dedicated cryptographic block that provides hardware acceleration for encryption functions. The crypto block is flexible and supports various algorithms to protect data. This allows developers to implement AES, DES, TDES, RSA, secure hash algorithms (SHA), and integrity checks such as cyclic redundancy check (CRC) in embedded IoT devices. Offloading cryptographic workloads to the MCU in this way enables cost-effective security for many embedded applications without requiring a more powerful processor.
True Random Numbers
Protecting an embedded system requires more than just encrypted communication. Specifically, AES keys generated by the system must be random. Because MCUs are deterministic, keys generated in firmware can also be deterministic, allowing attackers to brute-force possible seeds and potentially derive AES keys. Therefore, firmware must have a source of true randomness to ensure AES keys are unpredictable and resistant to brute-force attacks.
To achieve this, the crypto block must include a true random number generator (TRNG). For example, in the PSoC 6 crypto block, the TRNG uses six ring oscillators that provide physical noise sources. The ring oscillators include temperature-sensitive inverters that introduce jitter into the oscillator signal. The MCU can access this source of true randomness to ensure generated AES keys are unpredictable.
For instance, to generate a 16-byte key, a random value is generated 16 times and each value is concatenated. This creates 2^128 possible keys, which is sufficient to prevent AES keys from being brute-forced or guessed.
Some cryptographic attacks focus on analyzing captured communications. Given enough resources, any key may eventually be compromised. To mitigate this and increase the overall security of the communication channel, generate a new AES key at each reboot. This simple measure increases embedded system security; even if an attacker recovers a key, the key may no longer be usable by the time it can be exploited.
Message Integrity
It may be tempting to assume the UART interface is secure at this point, but UART is an unacknowledged protocol. It has no built-in mechanism to ensure that the receiver obtains messages that are a) complete and b) unmodified.
Message integrity requires additional measures. An effective method is to hash messages using a secure hash algorithm such as SHA. Running a message through a cryptographic hash function produces a fixed-length digest. Because hash functions are one-way, identifying the original message that generated a specific digest requires a brute-force search of all possible inputs.
