C&ESAR 2016 - J2

IOT.BZH – sécurité des véhicules intelligents

contributeur sur Automotive Grade Linux pour l’industrie automobile, notament toyota. 100% de l’automobile japonaise tourne sous AGL, ainsi que Ford et JLR. AGL à été développé à la base pour les smart-tv et les IoT. Bon, une voiture, c’est 100k loc, plein de SoC et des réseaux (et quelqu’un à été assez con pour tout interconnecter au net…). Le monde de l’automobile est indigent en sécurité informatique. Bon se faire hacker, c’est galère, parce-que les mises à jour se font au garage, et ça coûte cher. Cependant, la sécurité ça coûte cher, ça fait chier les utilisateurs et ça ralenti le time to market. Du coup les utilisateurs comme les marketeux viennent résister à la mise en place de la sécurité. Globalement, la sécurité doit être intégrée dès le départ dans la conception.

Du coup, coté cahier des charges, un trusted-boot en moins de 2s, une mécanique de signature des applications (et faut tout signer hein) et de mise à jour sécurisée. La re-initialisation usine est aussi essentiel pour s’assurer de pouvoir remettre en état le véhicule. Sur les SoC ARM, il y a un mécanisme de sécurité nommé la Trusted-Zone permettant d’isoler le code de certains périphériques.
L’architecture choisie est basée sur des micro-services qui sont virtualisé et sandboxés et qui causent entre eux à coup de REST / D-Bus / WebSocket. (tout cà pour gérer l’affichage et l’entertainment en temps-réel mou.). La gestion de la Trusted-Zone est faite avec linaro.

CEA Leti – sécuring the iot jungle

Le frein principal à la sécurisation de l’IoT, c’est le manque de standard, l’hétérogénéité des plateformes et la gestion d’un legacy sur un marché très concurrentiel, sans compter la spéculation sur la valeur des donnés collectés au travers de ces objets. L’IoT peut être abordé au travers de ses applications (les smart-*). Quand on compare smart-grid et smart health par exemple, la résilience et la sécurité publique se dégagent rapidement, mais l’aspect AAA (acountability, auditability & assurance) est souvent oublié. De plus la crypto conçue pour nos systèmes IT n’est pas adapté aux contraintes de puissance et d’économie d’énergie des IoT, et encore moins aux déploiements massifs. De plus, un capter IoT à une durée de vie potentiellement très longue. Avis partagé avec la présentation précédente: la sécurité doit être pensée dès la conception du système. La crypto doit être intégrée au hardware des SoC pour gérer les problèmes de puissance et d’autonomie avec des primitives adaptés. Des travaux sont en cours pour venir standardiser un système de mise à jour sécurisé pour les IoT. Pour l’orateur, la Trust-Zone ARM est un bidouillage de sécurité et pose la question de la durée de vie de ces processeurs face aux besoins de sécurité. Peut-on penser de nouveaux processeurs adaptés à ces besoins. Ex: RISC-V. Pour le problème de la gestion des clef, l’Identity Based Encryption offre des pistes de réponses. Pour la sécurité des données, le chiffrement homomorphe est une piste (bonjour la consommation elec…)

CoESSI – IoT issues, challenges & directions

Les constructeurs ne sont pas sensibilisés à la sécurité, en plus ça leur rapporte rien, et ils n’ont pas d’experts en sécurité en interne. Cependant les solutions IoT serons freinés au niveau des ventes s’ils ne sont pas sûrs (on peut rêver). Retour sur l’architecture IoT classique: des capteurs, un réseau basse consommation sans fil, une gateway qui fait le lien avec l’internet et un service cloud. Du coup ça fait une grosse surface d’attaque. Ex: la nissan leaf. (je vous passe les autres exemples et demo: shodan, le port série actif sur le routeur etc…). Les utilisateurs n’ont pas de moyen d’identifier que l’IoT est sûr ou pas, et qu’ils soient prêt à payer pour avec un device sécurisé « by design ».

Telecom-Bretagne & Texas Instrument – Les protocoles de sécurité pour l’IoT au sein de l’IETF

L’IETF à 30 ans, n’a pas de membres officiels, et le process de développement de ses standards est ouvert et transparent. les groupes de travail bossent sur des domaines précis à standardiser. L’objectif c’est d’obtenir des protocoles standards, ouverts et interopérables. 6LowPAN par exemple amène IPv6 aux objets connectés à forte contrainte énergétique. RPL (prononcez ripple avec l’accent) sert de protocole de routage, CoAp de protocole applicatif; Tout ceci étant fait pour tenir dans de tout petit paquets pour rentrer dans les protocoles de liaison entre le capteur et les hub. L’IETF se concentre sur les devices extrèmement contraints en cpu, mémoire et énergie dit de classe 1. Les véhicules et autres smartwatch sont de classe 2 et ont suffisamment de patate pour gérer des protocoles classiques. Pour les donnés, le CBOR remplace le JSON pour que les données soient les plus compactes et lisible sans machine à état ou parser complexe. L’IETF ne propose pas de solution complète pour le moment, mais un ensemble de briques de bases déjà utilisables. le groupe de travail LWIG à sorti une adaptation d’IPSec aux contraintes IoT. Pour la couche transport, DTLS apporte l’équivalent de TLS avec les cyphersuite qui vont bien. (bon panorama des solutions disponibles pour l’IoT.). Coté sécurité des données échangés, il est possible de signer les messages CBOR avec COSE. OSCoap apporte une sécurité de bout en bout qui permet aux gateway de modifier la couche transport sans casser la sécurité des donnés transportés. OSCoAp offre un bon compromis taille/sécurité avec une complexité faible et des capacités de multicast. (bon on oublie pas que c’est pour des capteurs, des trucs tout petit sans puissance de calcul, il faut aussi que la gateway et la solution cloud fassent leur taff coté sécurisation des échanges). L’orateur présente ensuite ACE et son déroulement. OSCoap et ACE sont encore peu diffusé, mais l’orateur est confiant quand à son adoption.

Orange – Sécurité LoRaWan

(petite minute publicitaire de rigueur et on passe au sujet) LoRaWan est un protocole radio longue portée basse consommation, de faible puissance et bas débit d’une porté de 3 à 5 km sur la bande passante ISM 868Mhz. LoRaWan est une couche physique propriétaire (comme SigFox) dont la norme est publié gratuitement, les membres du consortium recevant les updates de la norme 6 mois avant publication. Le network server s’occupe de dédupliquer les messages broadcasté sur le réseau.

La sécurité de LoRaWan est basé sur de l’AES 128 et repose sur 3 clefs: une clef maitre de l’objet, une clef de session réseau et une clef de session applicative. Les clefs sont hardcodés dans l’objet à sa fabrication. Il n’y à pas de protection de bout en bout de l’intégrité des messages (faut utiliser OSCoAp du coup?) et la notion de session n’est pas très claire dans la norme (confusion = failles potentielles). Les fabricants d’objets connectés ne traitent pas la génération des clefs au sérieux et utilisent des clefs prédictibles ou faibles.

Coté audit hardware, on est sur un système embarqué assez classique avec un micro-contrôleur, un module radio LoRa, une mémoire externe, etc… Du coup l’audit lui aussi se fait de façon assez classique: recherche de ports de debug JTAG, liaisons série etc… l’objectif étant de compromettre les clefs crypto sur lesquelles repose la sécurité de la flotte d’objets connecté produite. L’orateur décrit en suite sa méthodologie d’audit au multimètre pour retrouver le JTAG d’un MSP430 et extraire le firmware. Une fois le firmware dumpé, on connecte l’objet sur LoRaWan et on re-dump la mémoire de l’objet pour y retrouver les clefs crypto. Les passerelles LoRa ne sont pas elles aussi exemptes de failles physiques. Coté couches radio, le hacking progresse à coup de radiologicielle. Orange n’est pas en reste avec sa gateway LoRaWan malicieuse développé pour auditer les solutions LoRaWan.

Prove & Run

Preuve de sécurité formelle pour les hyperviseurs et cie. Les 3 pilliers des architecture de sécurité logicielle sont: L’utilisation d’éléments sûrs, un environement d’exécution de confiance et un hyperviseur. L’orateur reviens sur le hacking de la jeep (ptfv 😉 ). l’orateur présente succintement un kernel prouvé nommé ProvenCore pour fournir un socle solide et s’exécutant dans la TrustZone Arm. (une présentation commerciale qui aurais pu être plus riche techniquement)

Méthodes formelles pour la validation d’un module d’allocation mémoire pour l’IoT.

Les méthodes formelles permettent d’éviter pas mal de défauts dans l’ingénierie logicielle, mais ça reste très coûteux et assez complexe. On élimine ainsi les ratés dans les vérifications introduites par les développeurs. Très utilisé dans l’avionique ou le ferroviaire, les méthodes formelles restent peu employés dans le monde de l’IoT. L’orateur présente l’application de ces méthodes à l’allocateur mémoire memb de l’OS open-source Contiki. L’analyse s’est faite à l’aide de Frama-C. Le test est un premier step, mais la vérification déductive elle permet de découvrir les bugs qui ne sont pas levés par les tests. Frama-C se base sur des annotations type pré et post-conditions à la Eiffel.

Automated & remote security fuzz testing tool for iot devices

Dans le contexte de l’évaluation de la sécurité d’un IoT, quels sont les outils à dérouler pour établir le niveau de sécurité d’un produit vis à vis d’un profil d’attaquant donné. Bon coté réseau c’est très très riche (le darwinisme n’est pas encore passé par là). Les fonctions de sécurités sont assez variables en fonction de l’environement de déploiement de l’IoT. A chaque étape de la conception et du developpement sont associé diverses techniques de la conception associée à du model checking à l’analyse du code source vérifié par data-tainting en terminant par du fuzzing sur le produit final. Dans la « fuzzosphère » (ndlr: verbatim des slides) c’est pas les outils qui manquent: AFL, Fusil, Peach, Codenomicon, Sulley, etc…. Mention spéciale à AFL. Bon AFL sur l’embarqué c’est pas top tel quel à cause des difficultés d’instrumentation etc.., du coup il a fallu innover. On retrouve les composant classique d’un fuzzer: génération des données du protocole, jeu de la communication, monitoring de la cible et mutation des paquets/trames/donnés. Coté boucle de fuzzing on retrouve les classique suivis d’exécution, gestion des sessions de fuzz, gestion des crash etc… L’orateur à procédé au fuzzing 6LowPan de contiki.

CentraleSupelec- Hit the keyjack

Dans les IoT, la couche réseau sans fil est un des points d’attaque. Les étudiants ont donc étudié la sécurité des claviers sans-fils. Les keyloggers prennent diverses formes. En logiciel (on les trouve parfois sur github) ils enregistrent toutes les frappes clavier. Il existe aussi des keyloggers matériels ou encore là rubber-ducky qui permettent d’injecter des frappes claviers. Coté claviers sans-fils, @samykamkar à créé une preuve de concept permettant d’écouter les frappes clavier de certains produits sans fils.  Inspiré par la rubber-ducky et keysweeper, les étudiant ont conçu keyjack pour la récupération des frappes clavier et l’injection de frappes. C’est pas le tout d’enregistrer les frappes, il faut aussi les traiter pour en extraire de l’information pertinente. Une fois le clavier compromis, on peut faire exécuter des commandes pour télécharger et exécuter n’importe quoi. Dans le cad ou il y aurais plusieurs périphériques sans-fil vulnérabiles autour de Keyjack, il est possible de filtrer à partir du 1er octet du paquet pour distinguer les claviers des souris.

LHS Inria – IoT & Physical Attacks

Pour rajouter de la sécurité, crypto & codes pin pevent être des idées naturelles. Le problème c’est que votre système de sécurité est implémenté et fonctionne dans un objet physique qui peut laisser fuir de l’information à votre insu. C’est ce qu’on appelle les attaques par canaux cachés. Si un attaquant arrive à faire le lien entre la fuite d’information et la cryptographie sous-jacente est fait, il est envisageable d’en déduire des secrets. Autre technique: l’injection de faute, ou l’on viens perturber le calcul crypto par une surcharge electrique. La encore l’objectif est de faire cracher ses secrets crypto à l’objet. L’orateur à donc mis en pratique une attaque par injection de fautes electro-magnétiques permettant la récupération d’un code pin sur un micro-contrôleur standard. Coté défense, on peut blinder la puce, faire du masquage du secret, utiliser des codes détecteurs d’erreur etc… mais toute protection en faute augmente le signal disponible pour l’attaque par canaux cachés, et inversement. La contre-mesure est connue mais n’a jamais été publiée dans le monde académique. Le polymorphisme peut aussi aider à brouiller les pistes contre les attaques par template. En conclusion, pour la protection contre ces attaques, le soft c’est bien, le hard c’est mieux.