Sécuriser l'UART dans les appareils IoT : de l'échange de clés RSA au chiffrement AES

Avec des blocs cryptographiques intégrés dans les microcontrôleurs modernes, les développeurs peuvent désormais protéger chaque canal de communication, même les interfaces héritées comme l'UART qui manquent traditionnellement de sécurité intégrée.

Les violations de données très médiatisées dans les systèmes IoT ont montré qu'offrir un excellent produit ne suffit plus — les appareils doivent fournir un chiffrement de bout en bout pour rester compétitifs.

Bien que de nombreux protocoles intègrent la sécurité nativement, l'UART reste une interface simple, sans ACK, qui peut être lue ou altérée si le débit en bauds est connu. Pour se protéger contre l'écoute et l'injection, les terminaux eux-mêmes doivent chiffrer et authentifier les données.

Sécurité symétrique et asymétrique

La protection cryptographique est généralement divisée en deux catégories : algorithmes symétriques et asymétriques. Les clés symétriques — partagées par l'expéditeur et le récepteur — offrent un chiffrement rapide, mais la clé doit être échangée de manière sécurisée. Les paires de clés asymétriques résolvent ce problème en permettant à une partie de chiffrer une clé symétrique avec une clé publique ; seul le détenteur de la clé privée correspondante peut la déchiffrer.

RSA est le schéma asymétrique le plus courant pour l'échange de clés, tandis qu'AES est le cheval de bataille pour le chiffrement des données en raison de son efficacité et de son faible encombrement en ressources.

Chiffrement par clé publique et privée

La complexité mathématique de RSA assure une sécurité forte mais nécessite une puissance de calcul significative, ce qui peut être coûteux dans les systèmes embarqués en temps réel. Pour la plupart des appareils IoT, une approche hybride — RSA pour échanger une clé AES, puis AES pour les données en vrac — offre le meilleur équilibre entre vitesse et sécurité.

En pratique, le récepteur génère une paire de clés RSA et publie sa clé publique. L'expéditeur crée une clé AES aléatoire, la chiffre avec la clé publique du récepteur et la renvoie. Le récepteur déchiffre la clé AES avec sa clé privée, et tous les messages subséquents sont chiffrés avec cette clé.

Figure 1 : Échange sécurisé de la clé AES utilisant RSA. (Source : Infineon)

Puisque seul le récepteur prévu détient la clé privée, un attaquant ne peut pas récupérer la clé AES même s'il intercepte le canal. Toute communication ultérieure est alors protégée contre l'écoute et la falsification.

Implémentation firmware vs matériel

Implémenter des algorithmes cryptographiques purement en firmware est gourmand en ressources : il consomme des cycles CPU, augmente la latence et élève la consommation d'énergie. Les MCU modernes atténuent cela avec des accélérateurs cryptographiques dédiés qui délestent les opérations lourdes vers des blocs matériels spécialisés, réduisant drastiquement l'encombrement et le coût.

Le MCU PSoC 6 d'Infineon illustre cette approche. Son moteur cryptographique intégré prend en charge AES, DES, TDES, RSA, SHA et CRC, permettant aux développeurs de déployer une sécurité robuste sans processeur plus puissant.

Vrais nombres aléatoires

L'aléatoire est critique pour la génération de clés. Un firmware déterministe peut produire des clés prévisibles, rendant les attaques par force brute faisables. Un générateur de nombres aléatoires vrai (TRNG), comme les six oscillateurs en anneau du PSoC 6, introduit du bruit physique pour générer des clés imprévisibles.

Pour une clé AES de 16 octets, le TRNG génère 128 bits aléatoires — produisant 2^128 clés possibles, bien au-delà de la portée de la force brute. De plus, la régénération de la clé à chaque redémarrage limite la fenêtre d'exposition pour toute clé compromise.

Garantir l'intégrité et l'authenticité

L'absence d'ACK de l'UART signifie qu'il n'y a aucune garantie inhérente qu'un message est complet ou non corrompu. Pour contrer cela, un hachage cryptographique (SHA) est ajouté à chaque message avant le chiffrement. Le récepteur, après déchiffrement, recalcule le hachage et le vérifie par rapport à la valeur reçue. Une discordance indique une falsification ou une erreur de transmission, entraînant le rejet du message.

Figure 2 : Le hachage assure l'intégrité du message pendant les échanges sécurisés. (Source : Infineon)

Pour une authenticité supplémentaire, l'expéditeur peut signer le message avec sa clé privée ; le récepteur vérifie la signature en utilisant la clé publique de l'expéditeur, garantissant que le message provient de la source légitime.

En intégrant RSA, AES, TRNG et SHA dans le bloc cryptographique du MCU, les développeurs peuvent sécuriser l'UART — une interface traditionnellement non protégée — sans compromettre les performances ni le coût.

— Harigovind A et Rakshith M B, Ingénieurs d'applications seniors, Infineon Technologies

>> Cet article a été initialement publié sur notre site sœur, EDN.