TLS sur microcontrôleur : empreinte, poignée de main et gestion des certificats

Mettre TLS dans un objet connecté ne pose pas de problème cryptographique : les algorithmes sont les mêmes que sur un serveur. Les problèmes sont l'empreinte mémoire, le temps de la poignée de main sur un cœur à 80 mégahertz, et surtout ce qui se passe quand un certificat expire sur dix mille appareils déjà installés.

L'empreinte, poste par poste

Une pile TLS complète ne se réduit pas à une bibliothèque. Il faut compter quatre postes.

Le poste qui surprend est le dernier. TLS impose un tampon capable de contenir un enregistrement complet, soit jusqu'à 16 kilooctets. Sur un microcontrôleur à 64 kilooctets de RAM, une seule connexion peut consommer un quart de la mémoire. L'extension max_fragment_length, ou record_size_limit en TLS 1.3, ramène cela à 512 ou 1 024 octets, à condition que le serveur en face l'accepte. C'est le premier réglage à faire, avant toute autre optimisation.

Réduire vraiment l'empreinte

Une seule suite cryptographique. Compiler la pile avec une seule suite retire tout le reste. TLS_AES_128_GCM_SHA256 avec ECDHE et des certificats ECDSA P-256 est un choix solide et compact.

Bannir RSA. Une clé RSA 2048 bits coûte plus de flash, plus de RAM et bien plus de temps de calcul qu'une clé ECDSA P-256 pour une sécurité équivalente. La différence sur la poignée de main est d'un facteur cinq à dix sur un Cortex-M.

TLS 1.3 plutôt que 1.2. Moins d'allers-retours, moins de suites à gérer, et la suppression des modes obsolètes réduit à la fois le code et la surface d'attaque.

Un seul certificat racine. Embarquer un magasin de racines publiques est une erreur fréquente : cela coûte des dizaines de kilooctets et élargit la confiance à des centaines d'autorités dont vous n'avez pas besoin. Un appareil qui parle à votre serveur n'a besoin que de votre autorité.

Le coût de la poignée de main

C'est la partie que l'on sous-estime le plus. Ordres de grandeur sur un Cortex-M4 à 80 mégahertz, sans accélération matérielle :

Les valeurs chiffrées de cette section sont des ordres de grandeur observés, pas des spécifications. Elles dépendent du silicium, du compilateur et de la configuration. Mesurez les vôtres avant de dimensionner un produit sur ces bases.

Une poignée de main complète prend donc typiquement une demi-seconde à deux secondes. Sur un appareil sur pile qui se réveille pour envoyer une mesure, ce coût domine largement celui de la transmission, et il se paie en autonomie.

Deux leviers changent l'échelle. L'accélérateur matériel présent sur beaucoup de microcontrôleurs récents divise ces temps par cinq à cinquante ; encore faut-il que la pile TLS soit configurée pour l'utiliser, ce qui n'est jamais automatique. Et la reprise de session, avec les tickets de TLS 1.3, supprime la cryptographie asymétrique des connexions suivantes : quelques millisecondes au lieu de plusieurs centaines.

Pour un objet qui se connecte périodiquement au même serveur, la reprise de session est le premier levier d'autonomie, avant même le choix du modem.

La validation de chaîne, là où les implémentations trichent

Une poignée de main réussie ne prouve rien si la validation est incomplète. Quatre contrôles sont obligatoires, et il est fréquent d'en trouver un ou deux désactivés en production.

La chaîne de signature doit remonter jusqu'à une racine de confiance. La période de validité doit être respectée, ce qui suppose une horloge correcte. Le nom de l'hôte doit correspondre au champ approprié du certificat, faute de quoi n'importe quel certificat valide est accepté. Et la révocation doit être vérifiée.

Le contrôle de la date pose un vrai problème embarqué : sans horloge sauvegardée, un appareil qui démarre croit être en 1970 et rejette tout certificat, ou pire, l'accepte si la vérification a été désactivée pour cette raison. La solution correcte est de synchroniser l'heure avant la première connexion TLS, par un canal dont la sécurité ne dépend pas de TLS, puis de refuser de fonctionner tant que l'heure n'est pas plausible.

La révocation, elle, est rarement praticable en embarqué : les listes sont trop volumineuses et OCSP ajoute une dépendance réseau. L'alternative est l'agrafage OCSP, où le serveur fournit lui-même la preuve de non-révocation, ce qui ne coûte rien au client.

Le renouvellement, le vrai piège

Un certificat expire. C'est certain, et c'est ce qui met des parcs entiers hors service.

Trois décisions à prendre avant la production. La durée de vie du certificat client, qui doit être cohérente avec la durée de vie du produit : un certificat de deux ans sur un appareil qui en vivra dix impose un mécanisme de renouvellement fonctionnel. Le renouvellement automatique, qui doit être testé, y compris son échec. Et l'expiration de votre autorité de certification : si elle expire, tout le parc tombe le même jour.

La pratique la plus sûre consiste à embarquer une autorité racine à très longue durée de vie, vingt à trente ans, à ne l'utiliser que pour signer des autorités intermédiaires, et à renouveler les certificats appareils par un protocole automatisé.

Références

• IETF, RFC 8446, TLS 1.3, reprise de session et tickets
• IETF, RFC 8449, Record Size Limit, remplaçant de max_fragment_length
• IETF, RFC 6066, extensions TLS dont max_fragment_length
• IETF, RFC 6960 et RFC 6961, OCSP et agrafage
• wolfSSL manual, options de compilation et accélération matérielle

Pour aller plus loin

Ces arbitrages deviennent concrets quand on a mesuré une poignée de main sur cible, activé un accélérateur matériel et constaté le gain, puis simulé l'expiration d'un certificat pour voir ce que fait vraiment l'appareil. C'est ce que couvrent nos formations wolfSSL pour la sécurité embarquée.