External entropy supply for IoT devices employing a RISC-V Trusted Execution Environment

Cet article présente une solution open-source basée sur un environnement d'exécution de confiance (TEE) RISC-V qui fournit un service d'entropie externe sécurisé et vérifiable pour pallier le manque de sources de hasard aléatoire chez les dispositifs IoT contraints.

L'essentiel

Voici une explication simple et imagée de ce papier de recherche, traduite en français pour un public général.

🌟 Le Problème : Les Petits Robots qui Ont "Faim" de Hasard

Imaginez que vous voulez construire un coffre-fort ultra-sécurisé pour protéger vos secrets. Pour que ce coffre-fort soit vraiment sûr, vous avez besoin d'une clé de sécurité qui est totalement imprévisible. En informatique, on appelle cela de l'entropie (ou du hasard pur).

Le problème, c'est que les petits appareils de l'Internet des Objets (IoT) — comme une caméra de surveillance bon marché, un capteur de température ou un détecteur de fumée intelligent — sont comme des petits robots avec un cerveau très limité.

• Ils n'ont pas assez de "muscles" (puissance de calcul) pour générer ce hasard parfait eux-mêmes.
• Ils n'ont pas assez de "capteurs" pour écouter le bruit de l'univers et en extraire du hasard.

Résultat ? Ils essaient de deviner des clés de sécurité, mais comme ils manquent de "vrai hasard", leurs clés deviennent prévisibles. C'est comme si un cambrioleur pouvait deviner le code de votre coffre-fort simplement parce que vous avez choisi des chiffres trop simples. C'est la famine d'entropie.

---

💡 La Solution : Le "Banquier de Hasard" Sécurisé

Les auteurs de ce papier proposent une solution ingénieuse : au lieu que chaque petit robot essaie de générer son propre hasard (ce qu'il fait mal), ils créent un service centralisé appelé EaaS (Entropy as a Service, ou "Hasard en tant que Service").

Imaginez un banquier de confiance (le serveur) qui possède une réserve infinie de billets de banque uniques et imprévisibles.

1. Le Client (le petit robot) : Il a faim de hasard. Il envoie une demande au banquier : "J'ai besoin de 100 billets imprévisibles pour sécuriser ma maison."
2. Le Banquier (le serveur TEE) : Au lieu de donner n'importe quoi, il va chercher ses propres sources de hasard (du bruit électronique, des oscillateurs, etc.), les mélange, et prépare un paquet de hasard de haute qualité.
3. La Livraison : Il envoie ce paquet au robot, mais il le verrouille dans une boîte inviolable.

---

🛡️ L'Innovation : La "Chambre Forte" (TEE) et le "Juge de Paix" (RISC-V)

Le vrai défi, c'est : Comment le petit robot peut-il être sûr que le banquier ne triche pas ? Et si le banquier est un voleur qui envoie de faux billets ?

C'est là que la technologie RISC-V et la TEE (Environnement d'Exécution de Confiance) entrent en jeu.

• La TEE (La Chambre Forte) : Imaginez que le serveur du banquier possède une chambre forte en verre blindé où il travaille. Personne ne peut voir à l'intérieur, ni même le patron du serveur (l'administrateur) ne peut tricher une fois que la porte est fermée. Tout ce qui sort de cette chambre est garanti comme étant honnête.
• RISC-V (Le Juge de Paix) : C'est le système d'exploitation du serveur. Il agit comme un juge impartial. Avant de donner le hasard, le serveur dit au robot : "Regarde, voici ma preuve (attestation) que j'ai travaillé dans ma chambre forte, que mon matériel est authentique et que je n'ai pas été piraté."

Le robot vérifie cette preuve. Si tout est vert, il accepte le hasard. Si le serveur essaie de tricher, le "juge" RISC-V l'empêche de le faire, et le robot refuse la livraison.

---

🔄 Comment ça marche en pratique ? (L'Analogie du Message Chiffré)

Voici le scénario de la transaction, simplifié :

1. La Demande : Le petit robot dit : "Bonjour Banquier, je suis le robot X. J'ai besoin de 500 bits de hasard. Voici ma signature pour prouver que c'est bien moi."
2. La Réponse du Banquier :
   • Il prend du vrai hasard de ses sources.
   • Il le mélange avec un mot de passe temporaire (une clé symétrique).
   • Il enferme le tout dans une boîte chiffrée avec la clé publique du robot (seul le robot peut l'ouvrir).
   • Il signe la boîte avec sa propre signature numérique (le sceau du banquier) pour prouver qu'elle vient bien de la "chambre forte".
3. La Vérification : Le robot reçoit la boîte. Il vérifie le sceau du banquier (est-ce qu'il vient de la chambre forte ?). Il vérifie l'heure (est-ce que c'est frais ?). Puis il ouvre la boîte avec sa clé privée.
4. Le Résultat : Le robot a maintenant un stock de hasard parfait, généré par un expert, sans avoir besoin de faire le travail lui-même.

---

🚀 Pourquoi c'est important ?

• Économie d'énergie : Les petits robots n'ont plus besoin de faire des calculs lourds pour trouver du hasard. Ils économisent leur batterie.
• Sécurité maximale : Même si le serveur est piraté, la "chambre forte" (TEE) protège le processus de génération de hasard.
• Évolutivité : On peut ajouter d'autres robots comme sources de hasard. Si un robot a un capteur de mouvement très précis, il peut envoyer son "bruit" au banquier pour enrichir la réserve de hasard de tout le groupe.

🏁 En Résumé

Ce papier nous dit : "Ne laissez pas les petits robots essayer de deviner le hasard tout seuls, ils échoueront. Donnez-leur un accès sécurisé à un 'banquier de hasard' qui travaille dans une chambre forte inviolable."

C'est une solution élégante qui utilise l'architecture open-source RISC-V pour créer une infrastructure de confiance, rendant l'Internet des Objets beaucoup plus sûr contre les pirates. Et le meilleur de tout ? Tout le code est gratuit et open-source, comme un plan de construction que n'importe qui peut vérifier et utiliser.

Résumé technique

Voici un résumé technique détaillé de l'article « External entropy supply for IoT devices employing a RISC-V Trusted Execution Environment » en français.

1. Problématique

La génération de clés cryptographiques sécurisées dépend impérativement d'une source d'entropie (aléatoire) de haute qualité. Cependant, les dispositifs de l'Internet des Objets (IoT), souvent contraints en ressources (mémoire, puissance de calcul), peinent à collecter suffisamment d'entropie de manière autonome.

• Conséquences : Le manque d'entropie (« famine d'entropie ») conduit à des sorties cryptographiques prévisibles, compromettant la sécurité des clés et des communications.
• Limites des solutions existantes : Les générateurs de nombres aléatoires matériels (TRNG) intégrés, les sources hybrides ou les capteurs environnementaux peuvent être insuffisants, manipulables par un adversaire, ou trop coûteux en calcul pour les petits dispositifs. Les méthodes d'extraction (whitening) sont souvent trop lourdes pour ces plateformes.

2. Méthodologie

Les auteurs proposent une solution d'Entropie en tant que Service (EaaS) reposant sur une architecture client-serveur sécurisée par un Environnement d'Exécution de Confiance (TEE) basé sur l'architecture processeur RISC-V.

Architecture du système

Le système se compose de trois éléments principaux :

1. Client IoT : Un dispositif contraint qui ne peut pas générer assez d'entropie.
2. Serveur d'Exécution de Confiance (TES) : Un serveur hébergeant un TEE (basé sur le projet SPIRS) qui agit comme source de confiance, sans nécessiter de tiers de confiance (TTP) humain.
3. Sources d'Entropie : Des dispositifs IoT supplémentaires (parmi la flotte) équipés de capteurs ou de TRNG matériels (PUF/RNG) qui fournissent l'entropie brute au serveur.

Protocole EaaS

Le flux de travail sécurisé suit les étapes suivantes :

1. Initialisation : Le client IoT possède une clé privée pré-installée et la clé publique du TES.
2. Demande : Le client envoie une requête HTTP chiffrée (avec la clé publique du TES) contenant sa propre clé publique, la quantité d'entropie demandée ($\Delta S$) et une signature numérique.
3. Traitement dans le TEE :
   • Le TES récupère l'entropie brute des sources ($\Delta S_1, \Delta S_2$).
   • Il combine ces sources pour générer une entropie forte ($S$).
   • Il génère une clé de session symétrique ($sksession$) et un horodatage ($t_2$).
   • Il chiffre la clé symétrique avec la clé publique du client et chiffre le paquet d'entropie avec la clé de session.
   • Il signe le tout avec sa clé privée.
4. Réponse et Vérification : Le client reçoit la réponse, déchiffre la clé de session, récupère l'entropie, vérifie la signature du TES, et s'assure de la fraîcheur de l'entropie ($t_2 > t_1$).

Sécurité et Attestation

• Confiance matérielle : Le TEE (basé sur le projet SPIRS) utilise un Security Monitor (SM) et un Root of Trust (RoT) matériel (incluant un PUF/TRNG, AES, SHA) pour isoler le code de confiance.
• Attestation à distance : Un protocole de défi/réponse permet de vérifier à distance l'intégrité du matériel et du logiciel du serveur, garantissant que l'entropie provient bien d'un environnement non compromis.
• Protection contre les attaques : Le protocole inclut une signature de la requête par le client pour éviter les attaques de type Denial of Service (DoS) ou la modification des paramètres de la requête. Un mécanisme de limitation de débit (throttling) empêche l'épuisement des ressources d'entropie.

3. Contributions Clés

Les auteurs apportent les contributions novatrices suivantes :

1. Développement du SDK SPIRS TEE : Conception et publication d'un kit de développement logiciel (SDK) open-source pour le TEE RISC-V, permettant le développement d'applications de confiance (Trusted Applications - TAs).
2. Implémentation d'un service EaaS : Conception et déploiement d'une application de confiance (TA) fonctionnelle qui fournit un service d'entropie externe sécurisé pour une flotte de dispositifs IoT.
3. Preuve de concept sur RISC-V : Démonstration que l'infrastructure d'entropie de confiance est réalisable et efficace sur des plateformes RISC-V open-source, sans dépendre de matériel propriétaire fermé.

4. Résultats et Mise en œuvre

• Implémentation : La solution a été développée et testée sur un environnement virtualisé QEMU simulant la plateforme matérielle SPIRS (Ubuntu 22.04, RISC-V CVA6).
• Stack technique : Utilisation de la bibliothèque OpenSSL (statique), chiffrement AES-128 (symétrique), signatures RSA-3072 (asymétrique), et protocole NTP pour les horodatages.
• Fonctionnalité : L'application démo a prouvé la capacité du SDK SPIRS à gérer le cycle de vie complet d'une TA, de la compilation au déploiement sécurisé, en passant par l'attestation à distance.
• Limitations actuelles :
  • L'implémentation repose sur une simulation QEMU plutôt que sur du matériel physique SPIRS (bien que la migration soit jugée directe).
  • Le système utilise une seule instance de serveur TES (point de défaillance unique), bien que l'architecture permette une extension vers la haute disponibilité.
  • L'absence actuelle de primitives de cryptographie post-quantique (PQC) dans le RoT matériel, nécessitant une évolution future pour résister aux ordinateurs quantiques.

5. Signification et Impact

Cet article démontre qu'il est possible de résoudre le problème critique de l'entropie dans l'IoT contraint en externalisant la génération de nombres aléatoires vers un serveur sécurisé par TEE.

• Avantages : La solution offre confidentialité, fraîcheur et confiance dans la distribution d'entropie, surpassant les beacons d'aléa publics qui ne garantissent pas la confidentialité.
• Écosystème Open Source : En s'appuyant sur RISC-V et en publiant le code sous licence MIT, les auteurs réduisent les barrières à l'entrée pour la recherche et le développement de solutions de sécurité embarquée.
• Perspectives : Ce travail ouvre la voie à des infrastructures multi-locataires, à l'intégration de sources d'entropie hétérogènes et à l'adoption industrielle de services d'entropie sécurisés pour l'IoT.

En résumé, cette recherche valide l'approche « Entropy as a Service » couplée à un TEE RISC-V comme une solution viable, sécurisée et évolutive pour pallier les limitations des dispositifs IoT modernes.