Témoignage de Weeve – Un pas de confiance vers la sécurisation de léconomie des machines

(Gaurav Tiwari) (6 mai 2020)

Les données ont été comparées à des matières premières telles que le pétrole ou lor. Dans ce monde connecté, de plus en plus de données de qualité vont renforcer le processus décisionnel intelligent des machines déployées dans une usine ou de divers gadgets déployés dans nos maisons. Mais il y a un grand défi à relever – comment des données de qualité et fiables peuvent-elles être fournies en toute sécurité de manière évolutive et automatisée? Les leaders de lindustrie des périphériques embarqués bas de gamme travaillent darrache-pied pour intégrer les meilleures pratiques de sécurité matérielle et logicielle largement disponibles sur les périphériques haut de gamme à ces microcontrôleurs. Les ressources limitées en microcontrôleurs, et avec autant de systèmes dexploitation et de piles de solutions, conduisent à un paysage complexe et difficile pour la sécurité intégrée.

Nous pouvons classer les scénarios de protection des données comme suit;

  • Données au repos
  • Données en transit
  • Données utilisées

Chez Weeve, nous développons des solutions adaptées à la sécurité des données pour les appareils IoT basés sur des microcontrôleurs.

  • Nous protégeons les données au repos utilisent une solution de stockage fiable. Ces données contiennent des actifs cryptographiques tels que des clés ou certains actifs numériques tels que des pièces virtuelles, etc.
  • Avec données en transit, nous avons développé Weeve MQTTS, une publication-abonnement légère et sécurisée basée sur le protocole MQTT conçu pour les appareils bas de gamme. Il sagit dune alternative à MQTT sur TLS, qui consomme plus de ressources électriques à la périphérie.
  • Pour les données utilisées nous traitons de lintégrité du processus exécuté sur un appareil IoT. Ce processus peut consister à collecter des données utiles à laide de capteurs ou à exécuter une étape de traitement de données ou même à exécuter une logique métier dans le cas dun dispositif actionneur. Détecter et prévenir les vulnérabilités logicielles du processus est la clé ici. Nous développons Weeve Témoignage , une application dattestation de contrôle en temps réel, qui est le sujet de cette série de blogs.

Avant de présenter Weeve Témoignage, voici un petit aperçu technique des problèmes que nous résolvons et des technologies utilisées dans notre solution.

Problèmes de vulnérabilité du programme C

Presque tous les logiciels et micrologiciels embarqués de bas niveau sont développés dans le langage de programmation C. Le manque de vérifications de limites appropriées pour la mémoire allouée prévue est une source de grandes menaces pour la sécurité. En plus du débordement de tampon, le programme C souffre dun débordement dentier, dune vulnérabilité au format de chaîne, décrasements dadresses de retour, etc. Il existe également une nouvelle classe de menaces de sécurité pour un programme C comme return-to-libc , et plus générale programmation orientée retour (ROP) qui sont très efficaces contre les techniques datténuation courantes telles que Prévention de lexécution des données et signature de code. Un examen approprié du code avec des outils de sécurité dapplication statiques et dynamiques peut réduire la gravité de ces vulnérabilités. Il existe dautres techniques dans la chaîne doutils telles que la protection contre lécrasement de la pile, dans le matériel lui-même, comme lensemble de bits NX pour les segments de données, pendant lexécution, comme les randomisations de disposition de lespace dadressage (ASLR). Mais le programme est encore loin dêtre une garantie équitable sans vulnérabilité. Dans le contexte des appareils bas de gamme basés sur un microcontrôleur, la technique datténuation la plus efficace de lASLR nest pas mise en œuvre pour des raisons pratiques pour éviter davoir un chargeur dexécution.

Notre approche pour atténuer les vulnérabilités du programme C

Pour résoudre les problèmes de vulnérabilité du programme C, nous supposons quil y aura toujours des failles de sécurité dans le programme, et donc nous nous risquons à les détecter au moment de lexécution. Nous envisageons lexistence dun processus de garde isolé plus privilégié qui inspecte et témoigne du comportement dun programme C en cours dexécution (le firmware du MCU). Le processus de garde doit être isolé et plus privilégié que le micrologiciel normal car sil fait partie du même processus ou dun niveau de privilège similaire à celui du micrologiciel normal, le pirate informatique pourra également pirater le processus de garde en exploitant la même vulnérabilité dans le micrologiciel normal . Nous envisageons également le besoin dune entité dattestation à distance qui connaît à lavance (à laide de notre outil de profilage) tous les instantanés dexécution valides de lexécution normale du micrologiciel, et témoigne régulièrement de ces instantanés.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *