Comment sécuriser les communications UART dans les appareils IoT

Avec les blocs cryptographiques intégrés dans les MCU, c'est devenu possible pour les développeurs pour sécuriser tous les canaux de communication, y compris les interfaces telles que UART qui n'offrent aucune sécurité en elles-mêmes.

Avec le nombre croissant de violations de données et de confidentialité très médiatisées dans les systèmes de l'Internet des objets (IoT), les entreprises et les consommateurs sont de plus en plus conscients du besoin de sécurité lors de l'achat de produits connectés. Fournir des produits ou des services de premier ordre ne suffit plus. Les appareils qui n'offrent pas une sécurité adéquate ne seront pas en mesure de rivaliser avec ceux qui offrent une sécurité de bout en bout.

De nombreux protocoles implémentent la sécurité dans la norme et font partie intégrante de tout contrôleur. Cependant, les appareils intégrés qui se connectent via un récepteur-émetteur asynchrone universel (UART) ne sont pas protégés. UART est l'une des interfaces de communication numérique les plus simples entre les appareils. C'est un protocole de communication sans ACK qui peut être lu par n'importe quel appareil si le débit en bauds est connu.

Pour empêcher la lecture ou l'injection de données dans le système, le canal de communication doit être sécurisé par les systèmes qui envoient et reçoivent les données. Ainsi, même si un intrus accède au canal de communication avec le débit en bauds correct, le canal sera protégé.

Sécurité symétrique et asymétrique

Les canaux de communication sont souvent sécurisés à l'aide d'algorithmes cryptographiques. D'une manière générale, les algorithmes cryptographiques peuvent être classés comme symétriques et asymétriques. Avec les algorithmes à clé symétrique, l'expéditeur et le destinataire partagent une seule clé secrète. L'expéditeur crypte le message à l'aide de la clé et partage le message crypté avec le destinataire. Le destinataire utilise ensuite la même clé pour déchiffrer le message.

Le principal problème de sécurité avec les algorithmes à clé symétrique est de savoir comment échanger en toute sécurité la clé secrète entre l'expéditeur et le destinataire. Si la clé est capturée par une autre entité pendant l'échange de clés, cette entité peut également déchiffrer les messages envoyés par l'expéditeur. Ainsi, il est crucial que la clé soit partagée en toute sécurité avec uniquement l'expéditeur et le destinataire dans des algorithmes à clé symétrique.

Pour permettre un échange de clé symétrique sécurisé, des algorithmes de clé asymétrique sont utilisés. Les algorithmes asymétriques utilisent des clés différentes pour les processus de chiffrement et de déchiffrement. Bien que ces clés soient différentes, elles sont mathématiquement liées. La clé symétrique peut être échangée de manière sécurisée en la cryptant avec une clé asymétrique et le récepteur la décryptant à l'aide de la clé asymétrique associée. Un inconvénient des algorithmes asymétriques est qu'ils impliquent des calculs mathématiques complexes et ont tendance à être gourmands en calculs.

Pour le plus haut niveau de sécurité, le cryptage RSA est utilisé comme algorithme de clé asymétrique. Avec RSA, une entité communicante possède une clé publique et une clé privée. La clé publique, comme son nom l'indique, est partagée publiquement et accessible à tous. En revanche, la clé privée n'est détenue que par l'entité communicante. Pour envoyer un message à l'entité, l'expéditeur crypte le message à l'aide de la clé publique de l'entité. Ce message chiffré ne peut être déchiffré que par la clé privée. Étant donné que la clé privée n'est disponible que pour le destinataire prévu, cela garantit que seul le destinataire peut déchiffrer le message.

Cryptage à clé publique et privée

RSA utilise des calculs exponentiels et la factorisation en nombres premiers de très grands nombres, ce qui le rend hautement sécurisé mais aussi gourmand en calcul. De plus, la mise en œuvre de RSA en temps réel, pour éviter la latence dans les communications, augmenterait le coût du système en exigeant un moteur de traitement plus performant. De nombreux systèmes embarqués ne nécessitent pas ce niveau de sécurité. Au lieu de cela, ils peuvent utiliser un algorithme de cryptage plus léger comme Advanced Encryption Standard (AES), qui est plus pratique et plus rentable car il nécessite moins de ressources de traitement.

AES est un algorithme cryptographique symétrique, ce qui signifie que les deux côtés du canal de communication partagent une clé secrète commune. La limitation de l'AES mentionnée ci-dessus réside dans le partage sécurisé de la clé entre l'expéditeur et le récepteur UART sans l'exposer à des entités externes. Pour résoudre ce problème, RSA peut être utilisé pour chiffrer la clé AES et l'échanger en toute sécurité. Étant donné que la clé commune ne doit être partagée qu'une seule fois, le canal de communication peut supporter la complexité et la latence de RSA. En d'autres termes, le délai de traitement de l'algorithme RSA n'affecte que l'échange de clés initial, pas tous les messages.

L'échange sécurisé de clés se déroule en plusieurs étapes (Figure 1). Tout d'abord, le récepteur UART génère une paire de clés RSA et partage sa clé publique avec l'expéditeur. Peu importe si une autre entité voit la clé publique car elle ne sera utilisée que pour crypter les messages destinés au récepteur UART. L'expéditeur génère ensuite de manière aléatoire une clé AES et la crypte à l'aide de la clé publique du destinataire. Le récepteur déchiffre la clé AES à l'aide de la clé privée RSA.

Figure 1 :Échange sécurisé de la clé secrète AES à l'aide des clés publiques et privées RSA. (Source :Infineon)

Étant donné que seul le destinataire a accès à la clé privée RSA, la clé AES chiffrée ne peut être déchiffrée que par le destinataire. Cela garantit que la clé AES n'est connue que de l'expéditeur et du destinataire, et que tout intrus ayant accès au canal de communication ne peut pas dériver la clé. De plus, tous les messages ultérieurs entre l'expéditeur et le destinataire sont cryptés avec la clé AES, rendant ces messages inaccessibles à toute autre partie non destinée à les recevoir. Cela élimine également la menace d'attaques de l'homme du milieu (MIM) qui impliquent la modification des messages après leur envoi mais avant leur réception.

Firmware vs matériel

La mise en œuvre d'algorithmes de sécurité dans des appareils embarqués à l'aide de micrologiciels pose de nombreux défis de conception. Les algorithmes cryptographiques, de par leur nature, ont tendance à être gourmands en calculs. Ils augmentent également l'empreinte mémoire, allongent le délai de traitement et introduisent une complexité substantielle aux systèmes. En conséquence, la mise en œuvre de la sécurité dans le micrologiciel consommera des cycles CPU et des ressources MCU substantiels. De plus, pour répondre aux exigences des applications en temps réel, un MCU plus performant sera nécessaire, ce qui augmentera le coût du système.

Une partie de la raison pour laquelle tant de ressources MCU sont utilisées est que les MCU sont des unités de traitement à usage général. Pour cette raison, de nombreux MCU intègrent du matériel conçu spécifiquement pour les algorithmes cryptographiques. Avec un moteur cryptographique intégré, un MCU peut fournir un chiffrement et un déchiffrement en temps réel des données dans un encombrement beaucoup plus réduit et à un coût inférieur par rapport à un MCU sans capacités de traitement cryptographiques matérielles.

Le MCU PSoC 6 d'Infineon en est un exemple. Il dispose d'un bloc cryptographique dédié qui fournit une accélération matérielle des fonctions cryptographiques. Le bloc cryptographique est flexible et peut être utilisé pour prendre en charge différents algorithmes cryptographiques afin de garantir la protection des données. Cela permet aux développeurs d'introduire la sécurité dans les appareils IoT intégrés à l'aide de normes de cryptage telles que AES, DES, TDES et RSA et de contrôles d'intégrité tels que l'algorithme de hachage sécurisé ( SHA) et le contrôle de redondance cyclique (CRC). Le déchargement des fonctions cryptographiques du MCU de cette manière permet d'introduire de manière rentable la sécurité dans presque toutes les applications embarquées sans avoir besoin d'utiliser un processeur plus puissant.

Vrais nombres aléatoires

Cependant, la sécurisation d'un système embarqué nécessite plus que le simple cryptage des communications. Plus précisément, la clé AES générée par le système doit être aléatoire. Cependant, les MCU sont déterministes, de sorte que les clés générées le seraient également, permettant à un pirate informatique d'utiliser la « force brute » pour parcourir les différentes graines aléatoires possibles et potentiellement dériver la clé AES. Ainsi, le micrologiciel a besoin d'un moyen de générer de vrais nombres aléatoires pour garantir le caractère aléatoire de la clé AES, afin qu'il ne puisse pas être forcé par force brute.

Pour ce faire, le bloc cryptographique doit inclure un True Random Number Generator (TRNG). Dans le bloc cryptographique PSoC 6, par exemple, le TRNG dispose de six oscillateurs en anneau qui fournissent des sources de bruit physiques. Les oscillateurs en anneau contiennent des inverseurs sensibles à la température qui introduisent une gigue dans le signal de l'oscillateur en anneau. Ce signal donne au MCU accès à une véritable source de nombres aléatoires pour garantir le caractère aléatoire des clés AES qu'il génère.

Par exemple, pour générer une clé de 16 octets, un nombre aléatoire est généré 16 fois et ajouté aux nombres précédents. Cela donne la possibilité de 2^128 clés. C'est plus que suffisant pour empêcher que la clé "AES" ne soit forcée ou devinée.

Certaines crypto-attaques se concentrent sur l'analyse des communications capturées. Avec suffisamment de ressources, n'importe quelle clé peut éventuellement être cassée. Pour répondre à cette possibilité et augmenter la sécurité globale du canal de communication, la clé AES est générée à chaque redémarrage. Il s'agit d'une mesure simple mais efficace pour augmenter la sécurité des systèmes embarqués. En bref, même si une clé est identifiée par un intrus, la clé ne sera probablement plus utilisée au moment où elle pourra être exploitée.

Sécurité en toute confiance

À ce stade, il peut être tentant de considérer l'interface UART comme sécurisée. Cependant, UART est un protocole de communication sans ACK. Cela signifie que le protocole n'a pas de mécanisme pour s'assurer qu'un message reçu par le récepteur est a) complet et b) non corrompu.

Une dernière étape de sécurité est nécessaire pour confirmer l'intégrité du message. Une méthode efficace pour y parvenir consiste à utiliser l'algorithme SHA pour hacher le message. L'exécution d'un message via une fonction de hachage cryptographique comme SHA produit un hachage, une sortie de longueur fixe. Étant donné que les fonctions de hachage sont des fonctions unidirectionnelles irréversibles, la seule façon d'identifier le message qui a généré un hachage particulier est de tenter une recherche par force brute de toutes les entrées possibles.

Figure 2 :Une fonction de hachage assure l'intégrité des communications lors des échanges de clés sécurisés et des transferts de messages. (Source :Infineon)

Avant qu'un message ne soit envoyé, le hachage de l'intégralité du message est ajouté au message (Figure 2). Le message et le hachage sont ensuite chiffrés à l'aide de la clé AES. De cette façon, le hachage peut servir de contrôle d'intégrité. Le récepteur, après décryptage, calcule le hachage du message qu'il a décrypté. Le récepteur compare ensuite le hachage reçu et le hachage calculé. S'ils sont identiques, le message n'a pas été modifié. Cependant, si les hachages ne correspondent pas, cela indique que l'intégrité du message a été affectée. Cela peut se produire parce qu'un pirate a tenté de modifier le message ou qu'une erreur s'est produite lors de la transmission. Dans tous les cas, la communication a échoué.

Notez que le canal de communication peut encore être renforcé pour l'authenticité en signant le message avec la clé privée de l'expéditeur. Le message signé peut être vérifié à l'aide de la clé publique de l'expéditeur pour vérifier que seul l'expéditeur a pu envoyer le message. En d'autres termes, aucune autre partie ne peut imiter l'expéditeur puisqu'elle ne possède pas la clé privée de l'expéditeur, garantissant ainsi l'authenticité des messages. Pour plus d'idées, consultez les exemples de code communautaire, qui incluent de nombreux projets d'autres ingénieurs.

La mise en œuvre de la sécurité est devenue une considération nécessaire dans la conception de systèmes IoT embarqués. Il est crucial que chaque appareil connecté soit sécurisé et protège les données des utilisateurs contre la compromission. Avec des blocs cryptographiques intégrés dans les MCU, il est devenu possible pour les développeurs de sécuriser tous les canaux de communication, y compris les interfaces telles que UART qui n'offrent aucune sécurité elles-mêmes.

—Harigovind A et Rakshith M B sont des ingénieurs d'application seniors chez Infineon Technologies.

>> Cet article a été initialement publié sur notre site frère, EDN .