sÉcuritÉ des objets connectÉs...bouygues immobilier, nestlé, stanhome, avf périmédical, cci,...

SÉCURITÉ DES OBJETS CONNECTÉS

I . T I S O P E N

WWW.SMILE.FR

Edition avril 2019 Page 1 sur 29 © Copyright Smile – Open Source Solutions – Toute reproduction interdite sans autorisation

PREFACE C’est avec intérêt que j’ai lu le livre blanc que Smile ECS consacre à la sécurité des objets connectés, car dans un monde où ces objets seront de plus en plus présents, il est important qu’un des acteurs majeurs de la digitalisation en Europe manifeste avec cet ouvrage sa prise de conscience de l’importance de l’intégration de la cybersécurité dans les objets connectés. La particularité de ce livre blanc réside dans le fait que les auteurs se sont intéressés aux grands oubliés de la sécurisation de l’écosystème des objets connectés ; c’est-à-dire les logiciels embarqués. Dans notre quotidien, nous faisons le constat que les actions de sécurisation s’arrêtent souvent au cloud, car il est coutume de penser que les logiciels embarqués sont moins vulnérables. Ce livre blanc a le mérite de faire comprendre, de manière simple et sans noyer le lecteur dans des explications trop techniques, l’importance de les sécuriser ; car les vulnérabilités d’un objet connecté ne proviennent pas uniquement de la connectivité de celui-ci mais aussi des logiciels qu’on y intègre. Une leçon à retenir, après avoir lu le livre, est la réalisation des actions de cybersécurité dès la phase de conception (ce que nous appelons dans notre jargon « Security by design ») pour que celles-ci soient les plus efficaces possible. Le lecteur, après avoir consulté ce livre blanc aura pris conscience de l’importance de sécuriser l’intégralité de l’écosystème qui constitue un objet connecté et pas uniquement une partie car, la cybersécurité est la clé de voûte de cette révolution digitale. Elle apportera la confiance nécessaire aux utilisateurs des objets connectés afin qu’ils puissent en généraliser les usages et changer notre manière d’approcher le monde. Renato Febbraro Directeur Sécurité IoT & Systèmes Industriels chez AKERVA A propos de Renato Febbraro Après un début de carrière dans comme développeur de logiciels applicatifs et embar-qués, Renato Febbraro devient Chef de Projet au sein d’une société qui produit des camé-ras intelligentes et il est en charge du projet de développement des algorithmes de re-connaissance (faciale, gestes, objets) et de leur intégration sur cible ARM, FPGA et STM32. Ensuite Renato Febbraro rejoint une ESN de région parisienne comme chef de projet sur des projets industriels et devient Responsable de l’offre cybersécurité au sein de cette même ESN. Il rejoint en 2018 AKERVA pour prendre les rênes du département Sécurité IoT & Systèmes Industriels et contribuer à son développement.

A propos d’Akerva Fondé en 2013, Akerva est un cabinet de conseil en cybersécurité et management des risques. Akerva propose des services de conseil en gouvernance SSI, des prestations d'audits et de tests d'intrusion et de sécurité pour l’IoT et les systèmes industriels. Via son Security Lab, les consultants d’Akerva sont en veille constante sur les cybermenaces et disposent d'outils et de matériels innovants pour la réalisation de tests en conditions réalistes sur les objets connectés et les systèmes industriels. Avec son offre SOC - Centre de cyberdéfense, les entreprises peuvent désormais faire face aux menaces informatiques au quotidien grâce à un service de sécurité infogéré. Akerva assure une gestion de la sécurité des Systèmes d'Information optimale et durable. En savoir plus sur Akerva

https://akerva.com/

WWW.SMILE.FR


PREAMBULE

SMILE

Avec une présence dans 7 pays, Smile est le leader européen du digital ouvert, expert du digital et de l’open source (conseil, intégration et infogérance). Près de 1 700 passionnés contribuent chaque année à plusieurs centaines de projets digitaux stratégiques pour les plus grands comptes français et européens sur la base de solutions et concepts les plus innovants. Maîtrisant autant les meilleurs produits, composants et frameworks open source que les enjeux Business, Smile accompagne ses clients à chaque étape de leur transformation digitale à travers quatre offres verticales (Digital/Ebusiness, Business Apps, Infrastructure, Embedded/IoT) et une ligne complète de services intégrés (conseil, agence digitale, formation, développement et intégration, maintenance et infogérance). En 2017, Smile a réalisé un chiffre d’affaires de plus de 84 millions d’euros. La mission de Smile ? Faire de l’open source, le principal vecteur de digitalisation en Europe.

Smile est membre de l’APRIL, l’association pour la promotion et la défense du logiciel libre, du PLOSS – le réseau des entreprises du Logiciel Libre en Ile-de-France et du CNLL – le conseil national du logiciel libre.

Depuis 2000 environ, Smile mène une action active de veille technologique qui lui permet de découvrir les produits les plus prometteurs de l’open source, de les qualifier et de les évaluer, de manière à proposer à ses clients les produits les plus aboutis, les plus robustes et les plus pérennes. Cette démarche a donné lieu à toute une gamme de livres blancs & mini-books couvrant différents domaines d’application. Chacun des ouvrages présente une sélection des meilleures solutions open source dans le domaine considéré, leurs qualités respectives, ainsi que des retours d’expérience opérationnels.

Au fur et à mesure que des solutions open source solides gagnent de nouveaux domaines, Smile sera présent pour proposer à ses clients d’en bénéficier sans risque.

Ces dernières années, Smile a également étendu la gamme des services proposés. Depuis 2005, un département consulting accompagne nos clients, tant dans les phases d’avant-projet, en recherche de solutions, qu’en accompagnement de projet. Depuis 2000, Smile dispose d’un studio graphique, devenu en 2007 Smile Digital – agence interactive, proposant outre la création graphique, une expertise e-marketing, éditoriale, et interfaces riches. Smile dispose aussi d’une agence spécialisée dans la TMA (support et l’exploitation des applications) et d’un centre de formation complet, Open Source School.

Enfin, Smile est implanté à Paris, Lille, Lyon, Grenoble, Nantes, Bordeaux, Marseille, Toulouse et Montpellier. Et présent également en Belgique, en Suisse, au Luxembourg, aux Pays-Bas, en Ukraine ou encore au Maroc.

WWW.SMILE.FR


QUELQUES REFERENCES SMILE est fier d’avoir contribué, au fil des années, aux plus grandes réalisations Web françaises et européennes. Vous trouverez ci-dessous quelques clients nous ayant adressé leur confiance.

Sites Internet

EMI Music, Salon de l’Agriculture, Mazars, Areva, Société Générale, Gîtes de France, Patrice Pichet, Groupama, Eco-Emballage, CFnews, CEA, Prisma Pub, Véolia, NRJ, JCDecaux, 01 Informatique, Spie, PSA, Boiron, Larousse, Dassault Systèmes, Action Contre la Faim, BNP Paribas, Air Pays de Loire, Forum des Images, IFP, BHV, ZeMedical, Gallimard, Cheval Mag, Afssaps, Benetaux, Carrefour, AG2R La Mondiale, Groupe Bayard, Association de la Prévention Routière, Secours Catholique, Canson, Veolia, Bouygues Telecom, CNIL…

Portails, Intranets et Systèmes d’Information

HEC, Bouygues Telecom, Prisma, Veolia, Arjowiggins, INA, Primagaz, Croix Rouge, Eurosport, Invivo, Faceo, Château de Versailles, Eurosport, Ipsos, VSC Technologies, Sanef, Explorimmo, Bureau Veritas, Région Centre, Dassault Systèmes, Fondation d’Auteuil, INRA, Gaz Electricité de Grenoble, Ville de Niort, Ministère de la Culture, PagesJaunes Annonces…

E-Commerce

Krys, La Halle, Gibert Joseph, De Dietrich, Adenclassifieds, Macif, Furet du Nord, Gîtes de France, Camif Collectivité, GPdis, Projectif, ETS, Bain & Spa, Yves Rocher, Bouygues Immobilier, Nestlé, Stanhome, AVF Périmédical, CCI, Pompiers de France, Commissariat à l’Energie Atomique, Snowleader, Darjeeling…

ERP et Décisionnel

Veolia, La Poste, Christian Louboutin, Eveha, Sun’R, Home Ciné Solutions, Pub Audit, Effia, France 24, Publicis, iCasque, Nomadvantage, Gets, Nouvelles Frontières, Anevia, Jus de Fruits de Mooréa, Espace Loggia, Bureau Veritas, Skyrock, Lafarge, Cadremploi, Meilleurmobile.com, Groupe Vinci, IEDOM (Banque de France), Carrefour, Jardiland, Trésorerie Générale du Maroc, Ville de Genève, ESCP, Sofia, Faiveley Transport, INRA, Deloitte, Yves Rocher, ETS, DGAC, Generalitat de Catalunya, Gilbert Joseph, Perouse Médical…

WWW.SMILE.FR


Gestion documentaire

Primagaz, UCFF, Apave, Géoservices, Renault F1 Team, INRIA, CIDJ, SNCD, Ecureuil Gestion, CS informatique, Serimax, Véolia Propreté, NetasQ, Corep, Packetis, Alstom Power Services, Mazars…

Infrastructure et Hébergement

Agence Nationale pour les Chèques Vacances, Pierre Audoin Consultants, Rexel, Motor Presse, OSEO, Sport24, Eco-Emballage, Institut Mutualiste Montsouris, ETS, Ionis, Osmoz, SIDEL, Atel Hotels, Cadremploi, SETRAG, Institut Français du Pétrole, Mutualité Française…

Systèmes industriels et embarqués

Airbus, Groupe THALES, NEXTER, Airbus, Sagemcom, Stago, ST Microeletronics, Intel, Dassault Aviation, RATP, Coyote, Coved / Paprec, Groupe PSA, Sigfox, Softbank Robotics, Schneider, SKF, Hutchinson, Schneider, Canal+, IER (groupe Bolloré), Ingenico, JC Decaux, Michelin, Safran, Irdeto, Visteon, etc.

Consultez nos références, en ligne, à l’adresse : https://www.smile.eu/fr/nos-references

https://www.smile.eu/fr/nos-references

https://www.smile.eu/fr/nos-references

WWW.SMILE.FR


CE LIVRE BLANC

L’internet des objets (IoT) a pris une place prépondérante dans l’industrie ainsi que dans la vie quotidienne. Par exemple, il n’est plus question aujourd’hui de faire l’acquisition d’un véhicule sans qu’il ne soit « connecté » et la qualité du système d’ « infotainment » (IVI pour In Vehicle Infotainment) prend peu à peu le pas sur les caractéristiques mécaniques. Après la généralisation des smartphones (objet connecté par excellence), les sources de données privées se diversifient et les problèmes de sécurité – jadis traités par les administrateurs de serveurs – touchent des équipements informatiques très différents et se généralisent (véhicules, caméras, équipements médicaux, etc.). Si les systèmes d’exploitation des téléphones sont en général armés contre les attaques il n’en est pas de même pour d’autres équipements pour lesquels la prise en compte des contraintes de sécurité laisse souvent à désirer.

Après quelques généralités sur la sécurité (et la « sûreté »), nous décrirons pourquoi le cas des objets connectés est particulier puis nous aborderons les différentes attaques possibles ainsi que les méthodes et bonnes pratiques pour s’en prémunir et ce au niveau matériel, logiciel et méthodologie (tout en se focalisant sur le cas de l’embarqué / IoT).

Rappelons qu’un livre blanc n’est en aucun cas un ouvrage de référence et que le but est de décrire rapidement un certain nombre de faits et méthodes afin d’éveiller l’intérêt du lecteur. Pour chaque fait évoqué, une référence bibliographique sera fournie.

Rappelons également que nous traiterons uniquement la partie correspondant au logiciel embarqué, la partie « cloud » - hébergeant les données - ne sera pas évoquée ici.

Ce livre blanc a été rédigé par Pierre Ficheux, Directeur technique de Smile ECS (Embedded & Connected Systems), avec le concours de Jérémy Rosen, responsable des experts de Smile ECS et de Vincent Dehors, spécialiste des questions de cybersécurité chez Smile ECS.

WWW.SMILE.FR


SOMMAIRE

Préface ............................................................................................................................................................................ 1 Préambule ................................................................................................................................................................... 2

Smile ........................................................................................................................................................................... 2 Quelques références ..................................................................................................................................... 3 Ce livre blanc ....................................................................................................................................................... 5

Généralités .................................................................................................................................................................. 7 IT et OT ................................................................................................................................................................ 7 Sûreté vs sécurité ........................................................................................................................................ 7

L’IoT, un sujet d’actualité .................................................................................................................................. 8 Spécificités et normes de la sécurité IoT .......................................................................................... 10 L’importance du matériel ............................................................................................................................... 14 Choix du système d’exploitation ............................................................................................................. 16

Noyau Linux .................................................................................................................................................. 16 Système de mise à jour ........................................................................................................................ 17 Cas des OS dédiés .................................................................................................................................... 17 Cas du « bare metal » ............................................................................................................................ 17

Bonnes pratiques, règles, technologies .............................................................................................19 Conception et spécifications ............................................................................................................19 Test et intégration continue ..............................................................................................................19 Isolation et virtualisation ...................................................................................................................... 20 TrustZone ....................................................................................................................................................... 22

Approche open source ou propriétaire ? .......................................................................................... 24 Conclusion ................................................................................................................................................................ 26 Bibliographie ...................................................................................................................... 27

WWW.SMILE.FR


GENERALITES

La sécurité est un sujet majeur de l’informatique moderne qui s’est développé au fur et à mesure de la généralisation de l’Internet. Nous verrons cependant que dans le cas qui nous intéresse (embarqué / IoT) les problèmes de sécurité peuvent ne pas être liés à la connectivité mais au simple fait d’utiliser un logiciel embarqué intégré à du matériel. Le spectre de la sécurité informatique est très large, de la stratégie d’entreprise à la sécurité des réseaux sans parler des attaques par débordement de pile et autres « exploits ». Le lecteur intéressé par une approche générale de la sécurité informatique pourra se référer aux nombreuses sources disponibles dont l’excellent ouvrage de Laurent Bloch et Christophe Wolfhugel [1] aux éditions Eyrolles.

IT et OT

Le sujet qui nous intéresse ne concerne cependant pas uniquement la partie IT (InformationTechnology) pour lesquels les risques de sécurité sont principalement liés aux données hébergées. Les systèmes industriels intègrent des équipements matériels (OT pour Operational Technology) qui peuvent également subir des attaques. Les systèmes OT ont évolué vers des firmware - le plus souvent des systèmes d’exploitation standards – dont la complexité multiplie les risques de défaillances et d’attaques. Cependant la mise à jour des systèmes OT – afin de les maintenir à un bon niveau de protection - est bien plus complexe que celle des systèmes IT pour lesquels les procédures sont entérinées et automatisées depuis longtemps. De ce fait le nombre d’attaques et d’incidents impliquant des équipements OT a très fortement augmenté ces dernières années.

Sûreté vs sécurité

La définition des deux termes débute par une forte ambiguïté lors de la traduction anglais/français. En effet, l'anglais « security » désigne tout ce qui a trait aux actes de malveillance, et doit être traduit par le français « sûreté ». Par contre le terme anglais « safety » concerne ce qui a trait aux dommages accidentels, et doit être traduit en français par « sécurité ». Hervé Schauer – grand expert français de la sécurité - préconise cependant de ne pas trop s'attacher à cette distinction linguistique ! Dans les deux cas, cela conduit à des défaillances pouvant entraîner des problèmes graves voire des pertes de vies. De ce fait, la conception des produits (et du logiciel associé) suit des normes très strictes comme la DO-178 dans le cas de l’aéronautique. Les environnements utilisés (outils, langages de programmation, systèmes d’exploitation) sont de ce fait très spécifiques. A titre d’exemple nous pouvons citer l’environnement de développement SCADE [2] ou bien le groupe de travail Polarsys [3] lié à la fondation Eclipse, sans oublier le langage Ada et son dérivé le langage SPARK. Les équipements grand public (téléphone, décodeur TV, système IVI) utilisent des systèmes d’exploitation plus généralistes (comme QNX, GNU/Linux ou Android) et ne sont pas soumis à ces certifications. Ces systèmes sont cependant optimisés (ou « durcis ») afin d’améliorer leur résistance aux défaillances et actes de malveillance en utilisant des couches de sécurité que nous évoquerons plus loin dans le document (citons SELinux et Smack sur des systèmes à base de noyau Linux).

WWW.SMILE.FR


L’IOT, UN SUJET D’ACTUALITE

Le marché des objets connectés est depuis quelques temps la nouvelle marotte des analystes et autres spécialistes du marketing. Les prédictions vont bon train et certains prévoient (ou prévoyaient) une augmentation exponentielle de ce marché. Le cabinet Gartner estime qu’il y avait plus de 8 milliards d’objets connectés en 2017. Le même cabinet estime qu’en 2020 leur nombre devrait être de 20 milliards. D’autres estimations tablent sur 50 milliards voire plus (ce qui laisse une bonne marge d’incertitude). Il y a par contre une forte augmentation de l’utilisation de solutions connectées dans l’industrie ces dernières années. Si l’on peut considérer que l’IoT concerne des équipements grand public, l’IIoT (pour Industrial IoT) regroupe des équipements connectés à un réseau industriel (lui-même souvent relié à Internet via un firewall).

Le fait est que le marché grand public des objets connectés n’a pas vraiment encore tenu ses promesses et que bon nombre de startup réalisant des gadgets connectés (osons la terminologie) sont déjà passées à la trappe [4]. En effet, un marché BtoC directement dédié au consommateur est très difficile à gérer par une entreprise (et d’autant plus une startup). La plupart des consommateurs ont dans leur poche un objet connecté multi usage (le smartphone) qui grâce aux applications disponibles permet de fournir un grand nombre de services sans oublier qu’il consomme le budget technologie d’un grand nombre de foyers (si l’on exclut les technophiles et autres « geeks »). Pour donner un exemple simple, depuis l’apparition de l’application GPS Waze, qui veut encore acquérir un boîtier GPS autonome ? De même, de nombreuses entreprises (startup) se sont lancées dans la création de produits grand public (montres, capteurs divers) sans véritablement rencontrer le succès. Le marché BtoB est beaucoup plus facile à aborder, plus porteur et connaît déjà des applications intéressantes. Nous pouvons citer la société bordelaise eDevice qui dans le même domaine (systèmes médicaux connectés) connaît un beau succès depuis plusieurs années en toute discrétion.

Pour revenir au sujet initial, en dépit de l’intérêt de certains objets qui, passée l’étape du « concours Lépine », peinent à trouver leur place, la protection des données personnelles est certainement un frein à l’adoption de l’IoT par le grand public. Cette crainte est entretenue (souvent à juste titre) par des incidents largement médiatisés comme le fameux « piratage » de la Jeep Cherokee en 2015 [5] ou bien les vulnérabilités de certains pacemakers [6], tous deux présentés aux conférences Black Hat. Nous pouvons également citer l’utilisation frauduleuse de caméras IP (bien peu sécurisées) pour l’attaque DDoS (déni de service) en 2016 à l’encontre de la société française OVH, ciblée par un réseau de près de 150 000 caméras [7].

Ces incidents présentés comme des « exploits » techniques sont à la hauteur médiatique de l’attaque liée au virus NotPetya en juin 2017 qui a eu un impact économique direct beaucoup plus important (250 M€ de dégâts pour un leader industriel français). Ce type de catastrophe n’est cependant pas une fatalité puisqu’il est prouvé que malgré l’attaque WannaCry / Adylkuzz en mai 2017 et les recommandations de l’ANSSI ou des CERT (Computer Emergency Response Team), certains industriels n’avaient toujours pas appliqué les correctifs nécessaires aux versions impactées du système d’exploitation Microsoft Windows. De même, l’étude de l’attaque DDoS liée aux caméras IP a montré que plusieurs marques de caméras (1 250 !) étaient en fait basées sur un modèle générique très faiblement sécurisé utilisant un logiciel embarqué très peu modifié. Les failles de sécurité furent donc reproduites sur toutes les marques vendues, ce qui représente un total de 200 000 caméras potentiellement touchées [8]. D'une manière générale, on peut dire que les

WWW.SMILE.FR


devices connectés sont une cible de choix pour les malwares et botnets dans la mesure où leur nombre rend la recherche de vulnérabilité intéressante pour un attaquant. Le moteur de recherche Shodan [9] permet de visualiser les devices connectés ainsi leurs droits d’accès. On constate que de nombreux équipements – souvent configurables par une interface web - utilisent l’accès par défaut du « admin / admin ». Un article publié dans le numéro 91 du journal MISC [10] évoque le même type de défaillances.

On distingue deux types d'attaques courantes :

• la récupération de données personnelles détenues par l'objet

• l'infection de l'objet en vue de mener des attaques à grande échelle (type DDOS ou pour propager un malware).

La conception d’équipements sécurisés n’est pas non plus hors de portée à partir du moment où l’on adopte une démarche rigoureuse (choix des bons outils, sélection des développeurs et partenaires/experts, suivi des procédures, rédaction de spécifications détaillées, etc.). Il ne faut cependant pas oublier que le nombre d’experts dans le domaine de la sécurité de ce nouveau marché est assez faible. Nous pouvons cependant citer le programme Captronic qui a publié plusieurs guides sur l’IoT, dont un sur la cybersécurité (principalement destiné au PME) [11] . Il faut bien garder à l’esprit que la sécurité parfaite n’existe pas, il s’agit toujours de compromis entre moyens engagés pour la défense et moyens engagés pour l'attaque. On choisit généralement au début de la conception un niveau de sécurité correspondant à l’effort minimum nécessaire pour casser la protection de notre système.

WWW.SMILE.FR


SPECIFICITES ET NORMES DE LA SECURITE IOT

Si l’offre autour de la sécurité d’entreprise est relativement pourvue, il existe finalement assez peu d’experts en sécurité des objets connectés et il y a à cela plusieurs raisons. En premier lieu et comme nous l’avons vu le marché est assez jeune et les contraintes de sécurité des systèmes embarqués sont souvent traitées au niveau de la sûreté de fonctionnement (normes et outils). De plus, si l’on considère des produits grand public, le budget associé à la sécurité est souvent faible (voire inexistant) alors que des normes déterminent la conception des équipements critiques (donc bien plus coûteux). Concernant la sûreté de fonctionnement d’équipements critiques et outre la DO-178 déjà évoquée, nous pouvons citer les normes EN 50128/50129 pour le ferroviaire, IEC 62304 pour le médical, IEC 61508 pour les installations électriques/électrotechniques/électroniques et ISO 26262 pour l’automobile.

Dans le cas de la sécurité de l’(I)IoT nous pouvons citer les normes ISO 27005 et surtout IEC 62443.

• La norme ISO/IEC 27005 [12] fournit les éléments nécessaires à la mise en place d’une gestion des risques liés à la sécurité de l’information (IT)

• La norme IEC 62443 traite la cybersécurité des systèmes industriels (OT). La présentation citée en [13] évoque la cybersécurité comme une « nouvelle branche de la sécurité industrielle ».

La figure suivante présente assez clairement les différents niveaux de prise en compte des contraintes de sûreté et sécurité dans une approche globale de la gestion des risques.

Figure 1. Gestion des risques (schéma de Jean-Pierre Hauet)

La norme IEC 62443 étant la plus utilisée dans notre cas, nous allons la décrire en quelques mots en nous basant sur l’analyse de la cyberattaque contre le réseau électrique Ukrainien en décembre 2015 (connue sous le nom de BlackEnergy) [14] .

Les principaux concepts tels que décrits dans la norme sont les suivants :

WWW.SMILE.FR


• Processes (policies, procedures et guidelines)

• Technology

◦ Foundational requirements (FR)

◦ Zones & conduits

◦ Security levels (SLs)

• Maturity

La partie processes est organisée selon 11 catégories (Security Policy, Organization of Security, Asset Management, etc.). La partie technology utilise 7 Foundational Requests ou FR (Identification, authentication control and access control - AC, Use control – UC, Data Integrity - DI, etc.). Le système global à analyser doit être divisé en zones reliées par des conduits.

Figure 2. IEC 62443, zones et conduits

La norme fournit une liste de critères techniques permettant d’évaluer le niveau de sécurité (SL) sur une échelle de 1 à 4 à laquelle on peut ajouter la valeur 0 (pas de niveau de sécurité constaté !).

1. protection contre une violation usuelle ou de pure coïncidence

2. protection contre une violation intentionnelle simple

3. protection contre une violation intentionnelle sophistiquée (experts)

4. protection contre une violation intentionnelle étendue (parfois étatique)

Le principe de l’analyse est d’estimer pour chaque zone le niveau de sécurité actuel de chaque FR (soit SL-A, achieved) et d’en déduire le niveau nécessaire pour éviter une attaque à un niveau donné (soit SL-T, target). Si nous prenons l’exemple de FR 5

WWW.SMILE.FR


(ci-dessous), l’audit consiste à vérifier chaque SR (Security Requirement) et de déterminer le SL global.

Dans l’exemple ci-dessous (issu du cas BlackEnergy), l’audit a identifié que le point 3 du SR 5.1 « logical and physical isolation of critical network » n’était pas respecté, ce qui fait chuter le niveau de sécurité à SL 3. De même, le point 1 du SR 5.3 « prohibit all personal purpose person to person communication » n’est pas non plus respecté, ce qui fait chuter le niveau de sécurité à SL 2. Globalement, le niveau de la zone étudiée sur FR 5 est donc au niveau SL 2.

Figure 3. Évaluation FR 5 (data flow)

En réalisant la même tâche sur tous les FR, on en déduit un graphe correspondant au SL-A. Dans le cas étudié, l’audit a déterminé que FR 6 était au niveau 1 et les cinq autres FR au niveau 0 (aucun niveau de sécurité). De ce fait, la valeur globale de SL-A est égale à 0, correspondant à la valeur du maillon le plus faible. Le système était donc relativement bien protégé au niveau FR 5/réseau (SL 2) mais très mal protégé pour le reste ce qui indique une absence de prise en compte globale des contraintes de sécurité (but de la norme).

Le SL-T (à atteindre) est donc égal à 2 ce qui est un niveau relativement faible (protection contre une violation intentionnelle simple). La norme permet de définir la liste des contre-mesures à mettre en place sur les FR incriminés.

Figure 4. Graphe SL-A / SL-T

WWW.SMILE.FR


REMARQUE

Le nombre de normes mais également de guides est une difficulté pour l’application d’une politique de sécurité. L’ECS (European Cyber Security Organisation) a publié un document répertoriant les standards et guides [15]. Ce document compte plus de 200 pages et répertorie plus de 100 documents ! Nous pouvons également citer l’ETSI (European Communications Standards Institute) qui a publié un document dédié aux produits IoT [16].

Les compétences requises sont très différentes car les types d’attaques le sont également. L’attaque d’un système informatique de type NotPetya s’effectue le plus souvent via le réseau (Internet) alors qu’il existe d’autres modes d’attaques (et donc de protection) pour les systèmes embarqués classiques (i.e. non critiques), en particulier au niveau du matériel. Dans le cas de ces systèmes il est également important de trouver un niveau de sécurité adéquat (éviter la « sur-spécification ») afin de ne pas rendre le produit inutilisable ou hors de prix. Il n’existe aucune solution inviolable et il convient donc d’adapter les choix (et l’investissement) aux risques encourus et à leurs conséquences.

De plus, il est évident qu’une solution complexe (de type edge computing) connectée à Internet par un protocole IP standard sera plus exposée qu’un capteur isolé connecté à un réseau LPWAN de type Sigfox, LoRa, LTE-M ou NB-IoT.

Enfin, tandis que les machines de type serveur ou PC sont souvent très proches en termes de matériel (x86) et de logiciel (globalement Windows/Linux), les systèmes embarqués sont/ont des architectures disparates (parfois exotiques) et des OS très personnalisés (généralement basés sur des forks) avec des portions de code spécifiques (drivers uniques par exemple). Cette forte hétérogénéité rend la mutualisation de l’effort lié à la sécurité très compliquée.

WWW.SMILE.FR


L’IMPORTANCE DU MATERIEL

L’importance du matériel est prépondérante dans le cas de l’IoT et l’on peut considérer que l’IoT est une extension de l’Internet qui donne accès à des composants matériels (systèmes cyber-physiques et non plus simplement des pages web). Dans le cas du marché grand public, le coût du matériel doit rester abordable afin de garantir la pérennité commerciale du produit. De ce fait on utilise fréquemment des composants standard (COTS) et cette standardisation peut aller du SoC (System On Chip) à la carte complète, sachant que de nombreux produits bon marché existent déjà (citons les Arduino et autres Raspberry Pi). Ces cartes sont en général réservées à des phases de prototypage mais nous avons rencontré quelques exemples enfreignant cette règle. Du fait de cette généricité une faille au niveau matériel pourra impacter une génération entière de SoC, et donc de cartes mères basées sur le SoC. Les exemples les plus célèbres sont bien entendu les vulnérabilités Meltdown et Spectre [17] découvertes début 2018 qui affectent un grand nombre de processeurs du marché (principalement Intel mais également ARM) et donc potentiellement tous les systèmes les utilisant. A contrario les processeurs spécialisés comme les SPARC LEON3/4 (utilisés dans l’industrie spatiale) ne sont pas concernés par ces vulnérabilités [18] mais le prix d’une simple carte d’évaluation les exclut de fait des marchés classiques (prix non disponible en ligne mais pouvant atteindre plusieurs dizaines de milliers d’euros).

Outre les problèmes liés aux composants, une carte mère dédiée peut conduire à des vulnérabilités importantes. A titre d’exemple nous pouvons citer la Freebox V4 dont on pouvait prendre le contrôle à l’aide d’un simple trombone placé sur la carte mère [19]. Cette méthode fut utilisée pour la bonne cause en 2008 afin de prouver juridiquement la présence d’un système GNU/Linux sur l’équipement et donc le non respect par Free de la licence GPL sur les composants iptables et BusyBox [20]. L’existence d’un port de mise au point JTAG peut également être considérée comme une vulnérabilité matérielle puisqu’elle permet d’exécuter le firmware (par exemple un noyau Linux) à l’aide d’un débogueur (l’article en [21] décrit comment configurer l’accès JTAG sur une carte Raspberry Pi, par exemple). Dans la liste des vulnérabilités, nous pouvons également citer la console (sous GNU/Linux et Android, voire d’autres systèmes) qui peut être accessible grâce à un port de mise au point (UART) et pas toujours sécurisée. Dans la même veine il existe des outils comme la carte « bus pirate » [22] (au nom évocateur) permettant d’établir la communication en utilisant plusieurs types de bus (dont SPI, I2C, JTAG). C’est un formidable outil de mise au point mais pouvant devenir un redoutable instrument s’il est placé en de mauvaises mains.

Pour rester dans le domaine du matériel, les possibilités d’attaques de type « canaux auxiliaires » (side channel) sont beaucoup plus importantes lorsque le pirate possède un accès physique à l’objet. Ces types d’attaques sont multiples et consistent à exploiter une grandeur physique pour extraire des informations du flux d’exécution (et en déduire par exemple une clé de cryptographie ou le début d'un traitement particulier). Dans cette catégorie, on retrouve les attaques par analyse de consommation énergétique, d'émission électromagnétique ou sonore ou encore du trafic réseau [23]. Les références [24] et [25] décrivent des techniques permettant d’obtenir des valeurs de clés par analyse du courant consommé et création d’un modèle.

Enfin, il n’est nul besoin d’être un expert de la sécurité pour forcer les protections d’un équipement. Des prestataires spécialisés peuvent se charger de réaliser discrètement cette tâche (considérée comme une prestation classique).

WWW.SMILE.FR


Plus généralement on peut évoquer le côté asymétrique (entre le concepteur / développeur et le pirate) cité dans l’ouvrage de Roderick Chapman et Yannick Moy [26]. Le livre évoque un certain nombre d’asymétries particulièrement criantes dans le cas des systèmes embarqués.

• Capabilities, car le pirate a souvent plus de moyens que celui qui crée le produit (argent, temps, motivation) ;

• Effort, car le développeur doit s’assurer de l’intégrité de l’ensemble du code (i.e. prévoir tous les cas possibles) alors que le pirate peut isoler UNE seule faille et l’exploiter ;

• Knowledge, le nombre de publications et ressources concernant la sécurité est largement inférieur au nombre d’attaques répertoriées ;

• Impact, car dans le cas du logiciel il est très difficile de connaître à l’avance les conséquences de l’exploitation d’une faille.

Concernant le dernier point (impact), et même s’il ne s’agissait pas de l’exploitation d’une faille de sécurité, nous pouvons citer le tristement célèbre accident d’Ariane 5 en 1996, causé par un simple problème de codage d’une variable [27] dans un code source hérité d’un programme plus ancien (utilisé pour Ariane 4).

WWW.SMILE.FR


CHOIX DU SYSTEME D’EXPLOITATION

La plupart des systèmes embarqués concernés par ce document utilisent un système d’exploitation évolué de type GNU/Linux ou Android (voire QNX – fréquemment choisi pour les systèmes IVI - dans la catégorie des systèmes propriétaires).

REMARQUE

Dans le cas des systèmes embarqués et de l’IoT, on utilise rarement des distributions GNU/Linux classiques (Debian, Ubuntu, etc.) au profit d’outils permettant de créer une distribution optimisée selon les besoins du projet (et construite à partir des sources des composants). On parle alors de « build system » comme les outils Buildroot et Yocto [28] que nous évoquerons plusieurs fois dans l’article.

A titre d’exemple, un décodeur TV est un objet connecté et la quasi-totalité de ces équipements utilisent GNU/Linux ou plus récemment Android TV. De nombreuses TV connectées utilisent Tizen (Samsung) ou webOS (LG) qui sont également proches de GNU/Linux. Ces objets peuvent être considérés comme des calculateurs à part entière car ils utilisent une architecture 32 bits, voire le plus souvent 64 bits pour les systèmes les plus récents. Il existe bien entendu des équipements à base de microcontrôleurs (de 8 bits à 32 bits) et ces derniers n’utilisent ni GNU/Linux ni Android mais des systèmes dédiés comme FreeRTOS, Contiki, Zéphyr, ou RIOT sans oublier l’utilisation du « bare metal » (système sans OS). Certains systèmes d’exploitation sont déclinés dans des versions sécurisées comme SafeRTOS, version sûre de FreeRTOS. La page web de SafeRTOS [29] évoque les normes citées précédemment comme DO-178 ou IEC 61508. Ces équipements sont cependant moins exposés que ceux directement connectés à Internet.

Noyau Linux

Les systèmes à base de noyau Linux peuvent disposer d’un niveau correct de sécurité car de nombreuses fonctionnalités sont disponibles dans le noyau. Ces options sont activées dans Android puisqu’il utilise également le noyau Linux. A titre d’exemple nous pouvons citer (liste non exhaustive) ACL, SELinux / Smack et dm-verity. Les deux premiers ont pour but de compléter la gestion des droits sous UNIX (qui reste assez simpliste) par des règles plus évoluées. SELinux (dont un sous-ensemble est utilisé par défaut sur Android) [30] est d’une grande complexité mais garantit également un très bon niveau d’intégrité du système. L’outil Smack [31] a une approche plus simple (S pour simplifed) et il est utilisé dans le framework AGL (Automotive Grade Linux) [32] basé sur Yocto. AGL est un concurrent d’Android Automotive pour la mise en place de systèmes d’IVI. Le dernier composant (dm-verity) [33] se charge de vérifier l’intégrité des blocs du système de fichiers afin d’empêcher le démarrage en cas d’une modification non validée. A cela nous pouvons ajouter la possibilité de chiffrer les partitions du système ce qui permet d’éviter le vol de données personnelles même si le terminal est compromis.

REMARQUE

Il est important de noter que l’utilisation des composants de sécurité (comme SELinux) est obligatoire sur Android tant pour le fonctionnement en production que pour la certification délivrée par Google (CTS, VTS, etc.). Android utilise également le chiffrement des données depuis la version 5. Dans le cas de

WWW.SMILE.FR


GNU/Linux, le système produit (par exemple avec Yocto) doit être configuré pour intégrer ces options. Contrairement à la légende, Android est donc un système d’exploitation disposant d’un haut niveau de sécurité ! Il est d'ailleurs utilisé dans dans équipements sensibles tels que des terminaux bancaires.

Système de mise à jour

La plupart des distributions Linux (et autres OS avancés) utilisent un système de mise à jour basé sur un format de paquets (RPM, DEB, IPK, APK, etc.). Suivant l’OS ce système gère uniquement les applications ajoutées (APK pour Android) ou bien l‘ensemble des composants du système (cas de GNU/Linux et de DEB, RPM, IPK). Dans le cas d’un système de production, on utilisera très rarement ce principe pouvant se révéler être instable en fonctionnement réel et conduire à un « briquage » du système. La plupart des systèmes connectés (gateway, décodeur TV) intègrent une mise à jour globale du système - par une image d’OS signée et chiffrée - en utilisant un principe de « double mémoire flash » garantissant le fonctionnement même en cas d’échec de la mise à jour. L’outil libre SWUpdate [34] est un des composants (open source) permettant de mettre en place un tel système.

REMARQUE

Un objet connecté ne disposant pas d'OTA est nécessairement vulnérable dans le temps. Le système de mise à jour améliore le niveau de sûreté de fonctionnement du système. De plus, des outils comme SWUpdate ou RAUC [35] intègrent des fonctionnalités garantissant l’origine et la validité de la mise à jour. En dehors du système de mise à jour en lui-même, c'est le temps d'application des patchs de sécurité qui est également important. Par exemple, la plupart des téléphones Android (notamment avant Treble) n'ont pas les mises à jour Android dès qu'elles sortent mais doivent attendre, parfois longtemps, que le constructeur répercute la mise à jour.

Cas des OS dédiés

Nous avons évoqué précédemment des systèmes d’exploitation comme FreeRTOS/SafeRTOS, Contiki, Zéphir ou RIOT. Nous pouvons également citer MbedOS, proposé par ARM. Ces systèmes ont pour point commun d’être dédiés à l’IoT et destinés à des microcontrôleurs (MCU, de 8 à 32 bits) et non des CPU (32 ou 64 bits). Ils prennent donc en compte les contraintes d’encombrement et de sécurité nécessaires à la mise en place de capteurs et non d’objets complexes qui seront souvent équipés d’un OS à base de noyau Linux. FreeRTOS existait bien avant l’IoT mais une version adaptée est désormais intégrée à l’offre AWS (Amazon Web Services) [36]. Nous évoquerons également plus loin le cas de l’offre Microsoft.

Cas du « bare metal »

Même si il est de moins en moins fréquent (si l’on met de côté les systèmes critiques), l’utilisation du « bare metal » (absence de système d’exploitation) est encore envisageable. Selon l’étude « IoT developer survey 2018 » [37], environ 20 % des systèmes embarqués n’utilisent pas d’OS (contre 72 % pour Linux). Dans ce cas on notera une très forte importance du choix du langage et des règles de codages. Dans le document [26] les auteurs décrivent comment le choix des langages Ada et SPARK (ainsi que les outils associés développés par AdaCore) permettent de créer et maintenir un logiciel sûr (secure software). De même le respect de standards de règles de codage comme MISRA [38] devient fondamental dans ce cas.

Un exemple à la fois intéressant et ludique est proposé sur le blog d’AdaCore et concerne la sécurisation du firmware d’un drone grand public et bon marché

WWW.SMILE.FR


(CrazyFlie) [39]. L’article est assez édifiant concernant le niveau de qualité que l’on peut trouver sur de tels produits et rejoint l’exemple des caméras évoqué en [8] .

WWW.SMILE.FR


BONNES PRATIQUES, REGLES, TECHNOLOGIES

Dans cette partie nous allons étudier quelques règles et bonnes pratiques permettant la conception et la maintenance de systèmes sécurisés. Suite à cela nous dirons quelques mots sur les techniques d’isolation et de virtualisation. Ces pratiques, règles et technologies sont depuis longtemps utilisées dans les cas des logiciels critiques et nous pouvons citer l’architecture IMA (Integrated Modular Avionics) [40] et le standard ARINC 653 [41]. A la fin de cette partie nous évoquerons quelques autres techniques particulières.

Conception et spécifications

Comme nous l’avons déjà dit plusieurs fois, la création d’un produit sûr et sécurisé est avant tout basée sur la prise en compte des contraintes dès la conception et il ne s’agit pas de « saupoudrer » quelques flocons de sécurité une fois le produit terminé. Après plus de 30 ans de carrière dans le logiciel (dont 18 ans dans la prestation de service) force est de constater que de nombreux projets pêchent par manque de spécifications, procédures et recettes car les cycles des conception des produits grand public sont dramatiquement courts (le redoutable « time to market »). De plus, il y a souvent peu de moyens dans le support bas-niveau et dans les aspects sécurité, ceux-ci étant mis majoritairement dans le fonctionnel (applications métiers, interfaces utilisateur). Bien entendu il n’est pas concevable que la conception d’un décodeur TV suive les mêmes procédures que celle des équipements d’un avion civil, un TGV, ou une automobile mais il faut là aussi trouver un juste milieu, au risque de payer lourdement l’addition lors de la commercialisation qui peut toucher des millions d’utilisateurs.

Pire encore, si nous considérons le cas de GNU/Linux (embarqué), l’évolution de la technologie (qui va de pair avec la baisse du coût du matériel) fait qu’il est aujourd’hui possible de créer un prototype fonctionnel sur la base d’une Raspberry Pi et d’une distribution Raspbian (Debian) à grand renfort de code Python griffonné sur un coin de table (et intégrant N bibliothèques récupérées sur Internet, sans aucune validation). Si la pratique se limite à la création d’un POC (Proof Of Concept) il n’y a pas de problème mais le temporaire peut rapidement devenir du définitif face aux contraintes budgétaires jusqu’au jour ou le code en question (ré-utilisé dans le projet final) montre ses limites.

A contrario on voit apparaître de approches plus formelles pour la conception des systèmes comme le langage SysML (System Modeling Language, extension d’un sous-ensemble d’UML – Unified Modeling Language). SysML-Sec [42] est une extension de SysML permettant de concevoir des systèmes embarqués sécurisés. Un article en [43] décrit la modélisation de l’attaque de la Jeep Cherokee en utilisant le langage SysML-Sec. Comme nous pouvons le constater nous sommes très loin de la caméra chinoise générique conçue à la va-vite et responsable de l’attaque évoquée en [8] mais la future sécurité de l’Internet des objets est peut être à ce prix.

Test et intégration continue

Le test est bien entendu à la base de la validation d’un produit, y compris au niveau de la sécurité/sûreté même si selon Edger Dijkstra ce dernier à ses limites.

« Program testing can be a very effective way to show the presence of bugs, but is hopelessly inadequate for showing their absence »

WWW.SMILE.FR


Le test peut s’effectuer au niveau fonctionnel pour chaque paquet (on parle également de test unitaire même si le terme nous semble être mal choisi de nos jours). Dans le cas d’un système GNU/Linux ou Android, le test fonctionnel correspond à la validation d’une application fournie par un paquet (APK pour Android) ou à une recette Yocto (GNU/Linux). Pour ce faire, Yocto fournit la fonctionnalité Ptest (Package Test) [44] permettant d’intégrer un script de test au paquet installé sur l’image. Yocto permet ensuite de tester tout ou partie des composants installés à l’aide de l’utilitaire ptest-runner. Yocto permet également de valider l’intégralité d’une image de système d’exploitation en utilisant Testimage [45] . Dans ce cas, on pourra dérouler des tests globaux sur l’image installée. Yocto fournit d’ores et déjà un certain nombre de tests (Ping, SSH, Scp, PAM, etc.) mais il est bien entendu possible d’en ajouter y compris dans le domaine de la sécurité. Les scripts de test sont écrits en langage Python.

L’association des approches permet de mettre en place une procédure d’intégration continue (IC ou CI) permettant de vérifier qu’une modification n’entraîne pas l’apparition d’une faille de sécurité (ou bien entendu un défaut de fonctionnement au sens large). De nombreux outils libres existent pour mettre en place une procédure d’IC (citons le célébrissime Jenkins ou le moins bien connu LAVA [46], ce dernier étant plus ou moins dédié aux systèmes embarqués).

REMARQUE

Une telle procédure peut être mise en place sur une cible réelle ou bien en utiliser un émulateur comme QEMU (cible Yocto par défaut). La solution émulée permet de vérifier les points indépendants des contraintes matérielles mais il est toujours possible d’émuler certaines entrées afin d’injecter des données de test. QEMU est à la base d’une solution de validation de systèmes critiques fournie par AdaCore [47].

Isolation et virtualisation

Nous avons évoqué au début de cette partie des technologies comme IMA et ARINC 653 utilisées pour l’aéronautique. Le but initial était de limiter le nombre de calculateurs embarqués (donc le coût, la consommation électrique et la complexité de la connectique) en partageant un même calculateur par plusieurs partitions de niveaux de criticités différents (voir figure ci-après).

Figure 5. Architecture ARINC 653

WWW.SMILE.FR


Initialement réservée aux applications militaires, ce standard a gagné peu à peu du terrain. Il fut utilisé sur l’A380 et des techniques de virtualisation similaires sont désormais disponibles dans l’automobile. Les avantages d’une telle architecture du point de vue de la sécurité (et sûreté) sont évidents, en particulier sur l’isolation de différents OS exécutés (partitions) mais également sur le contrôle de la communication. La société SYSGO commercialise depuis longtemps PikeOS [48], un hyperviseur « bare metal » capable d’héberger une architecture ARINC 653. La société Elektrobit propose un outil similaire (Corbos) [49], dédié aux applications automobiles et conforme à AUTOSAR Adaptive [50], extension du standard AUTOSAR permettant d’exécuter du code POSIX dans un environnement sécurisé de type GNU/Linux (Yocto) .

Dans le monde du logiciel libre des composants comme LXC (intégré à Linux) ou bien Docker permettent d’exécuter une image de système d’exploitation (par exemple Yocto) dans un conteneur au niveau de l’OS Linux hôte (et non plus en « bare metal »). A titre d’exemple, le projet Anbox [51] permet d’exécuter Android dans un conteneur LXC. Un grand groupe industriel français a déjà utilisé cette technique afin d’intégrer des applications Android dans un environnement existant sous GNU/Linux (Debian).

Dans le même ordre d’idée, le micro-noyau libre seL4 [52] est utilisé dans des application d’aéronautique autonome ainsi que sur des projets IoT. Cet outil est de nouveau basé sur l’isolation de composants ayant des niveaux de criticité différents. Une API prend en charge le fonctionnement du micro-noyau et des différents OS hébergés (threads, IPC, signaux, etc.) afin de produire un système hautement sécurisé. L’article en [53] décrit la sécurisation du logiciel utilisé dans un hélicoptère autonome créé sur la base du Boeing AH-6 (ULB – Unnamed Little Bird).

Le logiciel de l’appareil est au départ constitué de deux parties (mission computer et flight computer) reliées par un réseau local.

Figure 6. Architecture initiale ULB

Un tel système peut aisément être attaqué à partir du lien vers la station au sol. Le mission computer peut être infecté et éventuellement transmettre l’infection au « flight computer » via le réseau local. L’utilisation de seL4 permet de faire évoluer le logiciel vers une architecture sécurisée dans laquelle les composants sont séparés. La partie Linux (non sécurisée) communique avec la partie sécurisée par l’API seL4.

WWW.SMILE.FR


Figure 7. Architecture avec seL4

Comme décrit en détail dans l’article en [53], on peut - outre l’isolation - concevoir un système en considérant l’assemblage de composants de haut niveau qui communiquent par des connecteurs dont le code est produit automatiquement. Indépendamment de la conception d’un nouveau logiciel, la notion de seismic security retrofit évoquée dans l’article permet de faire évoluer l’architecture d’un logiciel existant afin de le rendre beaucoup plus résistant aux attaques.

TrustZone

Outre la virtualisation il existe d’autres solutions permettant d’augmenter le niveau de sécurité d’un système, en particulier l’utilisation des Trusted Execution Environment (TEE) comme la TrustZone [54] sur ARM.

La TrustZone est une technique basée sur les propriétés du SoC (System On Chip). Le terme correspond au nom commercial ARM pour « security extension ». Le premier cœur équipé de cette technologie était l’ARM1176JZ (ARMv6Z) en 2003. La TrustZone est désormais présente sur tous les cœurs ARMv7-A, ARMv8-A et ARMv8-M. Nous avons précédemment évoqué les techniques de virtualisation/hyperviseur mais celles-ci nécessitent des extensions au niveau du processeur qui n’étaient pas forcément disponibles à l’époque de la création de la TrustZone. Plus généralement la mise en place de la virtualisation est relativement complexe. Le principe de la TrustZone est similaire à celui de la séparation mode utilisateur / mode protégé largement utilisé dans les OS modernes (user / kernel sous Linux). Grâce à la TrustZone on peut créer des niveaux d’exécution sécurisés au niveau de l’espace utilisateur donc utilisables pour le développement applicatif .

WWW.SMILE.FR


Figure 8. Niveaux d’exécution avec TrustZone

La programmation dans la TrustZone reste cependant assez complexe car on doit passer par l’API Global Platform [55].

WWW.SMILE.FR


APPROCHE OPEN SOURCE OU PROPRIETAIRE ?

L’évolution du logiciel libre dans l’embarqué ces dernières années a été fulgurante, y compris chez les éditeurs historiques des RTOS propriétaires (VxWorks, Lynx Realtime Systems qui fut renommée à une époque LynuxWorks, Mentor Graphics , etc.). Elle le fut encore plus – et bien plus tôt – dans les systèmes d’information puisqu’une grande partie de l’Internet utilise des serveurs sous GNU/Linux (70 % UNIX dont 37 % GNU/Linux). Cependant rien ne dit que cette tendance se reproduira dans l’IoT car les solutions nécessitent des composants à plusieurs niveaux (matériel, logiciel embarqué, cloud). De ce fait des solutions complètes, intégrées et propriétaires sont fréquemment proposées par de gros fournisseurs (citons Samsung et Renesas par exemple) ce qui n’est pas sans rappeler l’approche d’un certain éditeur de logiciels américain actuellement présent dans la partie « cloud ». Microsoft (nommons le) s’intéresse également à la partie embarquée avec Windows 10 IoT [56] mais selon certaines informations assez fiables, ce dernier n’aurait pas un grand avenir et Microsoft se concentrerait sur la solution Microsoft Azure Sphere [57] proposant un système d’exploitation embarqué (Azure Sphere OS) basé sur un noyau Linux (on aura tout vu !). La solution (complète) intègre également du matériel (Azure Sphere certified MCUs) « inspiré des 15 ans de recherche et d’apprentissage autour de la Xbox » (pour citer le lien en [57])

La comparaison entre logiciel libre et propriétaire est « éternelle » (du moins depuis que le logiciel libre existe) et détailler ce sujet sort du contexte de ce document. Nous pouvons citer rapidement quelques éléments généraux pour et contre.

Pour le logiciel libre

• La disponibilité du code source (bien entendu !)

• L’existence des communautés (fondamental)

• L’indépendance par rapport à un éditeur

Pour le logiciel propriétaire :

• Les possibilités de certification (exemple des versions certifiées de VxWorks)

• Le support technique et la documentation

• Souvent, des outils de mise au point plus avancés

Un article paru en juin 2018 [58] prend quant à lui le parti de dénigrer les avantages des solutions open source au profit des éditeurs propriétaires sur différents niveaux dont la sécurité. Les propos exprimés dans le court extrait ci-après sont pour le moins caricaturaux vis à vis de l’open source. Il en est de même pour d’autres parties de l’article (en particulier concernant la licence GPL).

« La sécurité de l’open source représente un véritable défi. Dans l’open source, le code source, par définition ouvert, est librement disponible pour que quiconque puisse l’examiner et, éventuellement, concevoir un moyen de le subvertir. Sa popularité est son principal danger, et, s’il est utilisé dans un produit commercial à succès, la motivation des pirates est accrue, que ce soit pour l’ extorquer ou pour causer une perturbation maximale de type cyberterrorisme »

WWW.SMILE.FR


Le fait est que les récentes attaques précédemment évoquées (WannaCry et NetPetya) ont infecté l’OS propriétaires Windows et non des OS open source comme GNU/Linux ou Android.

Au niveau de la sécurité, il est cependant faux de dire qu’un logiciel libre est forcément mieux armé qu’un logiciel propriétaire (tout comme de dire qu’il est de meilleure qualité). Cependant, si l’on s’appuie sur les communautés du libre (ce qui est fondamental pour avoir une véritable gouvernance open source dans l’entreprise) on peut largement profiter des conseils, des alertes de sécurité et des correctifs. Bien entendu il n’est jamais simple de mettre à jour un noyau Linux en suivant de près les évolutions sachant que la version fournie par le constructeur du SoC ou du module dans le BSP est souvent plus ancienne que la version « mainline » (officielle) du noyau.

REMARQUE

Le BSP (Board Support Package) est la partie dépendante du matériel fournie par le constructeur. Dans le cas d’un OS GNU/Linux il s’agit du noyau (et des pilotes spécifiques) voire du bootloader. La qualité du BSP est un point fondamental pour assurer la qualité d’un produit au niveau fonctionnement, maintenance, sûreté et sécurité. Ce point est à prendre en compte malgré les prix attractifs de certains constructeurs qui compensent par un très faible investissement sur le support logiciel comme l’indique cette discussion sur LinkedIn [59]. L’article à l’origine de la discussion est disponible en [60] . Bien entendu la contrainte de qualité du BSP existe également dans un environnement propriétaire mais le développement étant centralisée (chez l’éditeur) il y a moins de chances de « dispersion » au niveau de la qualité du portage.

La disponibilité des sources est importante dans une approche sécuritaire car elle permet de réaliser un audit complet du logiciel embarqué du produit. De plus, l’approche open source permet de disposer de l’intégralité des outils de développement nécessaires à la production du logiciel embarqué (y compris la distribution hôte) ce qui a une importance fondamentale dans le cas de produits maintenus sur de longues périodes (exemples de l’aéronautique ou de l’automobile). De plus, personne n’est à l’abri de la disparition d’un éditeur de logiciel propriétaire fournissant des outils ou un système d’exploitation. Enfin, en l’absence de chiffrement, un objet connecté avec du code propriétaire est sujet aux techniques de rétro-ingénierie au même titre que si son code était ouvert (bien que l’analyse de binaire soit plus complexe que celle du code source).

WWW.SMILE.FR


CONCLUSION

Comme nous l’avons indiqué au début de ce document, la sécurité informatique est un domaine assez particulier où les prestataires sont assez rares particulièrement dans le domaine naissant de l’IoT. N’oublions pas non plus qu’une solution IoT est constituée de capteurs (ou terminaux) utilisant un logiciel embarqué et d’une partie hébergeant les données. La partie traitement des données sur le « cloud » est un autre domaine de la sécurisation du système global. Cependant elle est est le plus souvent confiée à un prestataire de service comme Microsoft Azure ou Amazon (AWS) qui ont leur propre politique de sécurité. A de rares exceptions près, les prestataires classiques de la sécurité informatique ne traitent pas le cas spécifique du système embarqué même si des exceptions sont visibles après une rapide recherche.

Dans le cas du développement régulier de solutions IoT évolutives (et donc à maintenir), il est évident que la disponibilité dans l’équipe de conception de spécialistes du domaine de la sécurité est une nécessité absolue. Rappelons également qu’une conception sécurisée et sûre nécessite souvent l’utilisation de techniques pouvant paraître trop avancées voire superflues (comme la virtualisation) mais qui augmentent grandement la fiabilité du système pour un coût désormais assez modeste.

WWW.SMILE.FR


BIBLIOGRAPHIE

[1] Bloch / Wolfhugel Sécurité informatique (Eyrolles) https://www.eyrolles.com/Informatique/Livre/securite-informatique-9782212118490

[2] Suite de développement SCADE http://www.esterel-technologies.com/products/scade-suite

[3] Groupe de travail Polarsys https://www.polarsys.org

[4] Pourquoi le marché des objets connectés n’a pas tenu ses promesses https://start.lesechos.fr/entreprendre/actu-startup/pourquoi-le-marche-des-objets-connectes-n-a-pas-tenu-ses-promesses-11398.php

[5] Piratage de la Jeep Cherokee https://www.kaspersky.com/blog/blackhat-jeep-cherokee-hack-explained/9493/

[6] A New Pacemaker Hack Puts Malware Directly on the Device https://www.wired.com/story/pacemaker-hack-malware-black-hat

[7] Attaque DdoS vers OVH https://www.zdnet.fr/actualites/ovh-noye-par-une-attaque-ddos-sans-precedent-39842490.htm

[8] Caméras IP : 1250 modèles vulnérables à des failles de sécurité https://www.zdnet.fr/actualites/cameras-ip-1250-modeles-vulnerables-a-des-failles-de-securite-39849526.htm

[9] Moteur de recherche Shodan https://www.shodan.io/

[10] LES SYSTÈMES DE VIDÉOSURVEILLANCE ET L'IOT : PROTOCOLES ET VULNÉRABILITÉS https://connect.ed-diamond.com/MISC/MISC-091/Les-systemes-de-videosurveillance-et-l-IoT-protocoles-et-vulnerabilites

[11] Comment maîtriser la cybersécurité de vos objets et systèmes connectés https://www.captronic.fr/Sortie-du-guide-Cybersecurite-des-produits-connectes-a-destination-des-PME.html

[12] ISO/IEC 27005 https://www.iso.org/fr/standard/75281.html

[13] IEC 62443 https://www.g-echo.fr/20161005-hauet-kb.pdf

[14] Ukrainian power grids cyberattack https://www.isa-france.org/telechargement/fichiers/Intech_ISA99_2017/Article%20Intech.pdf

[15] Overview of existing Cybersecurity standards and certification schemes v2 () https://ecs-org.eu/documents/publications/5a31129ea8e97.pdf

[16] Cyber Security for Consumer Internet of Things https://www.etsi.org/deliver/etsi_ts/103600_103699/103645/01.01.01_60/ts_103645v010101p.pdf

[17] Vulnérabilités Meltdown et Spectre https://meltdownattack.com/

[18] Statut des processeurs SPARC LEON concernant Meltown/Spectre https://www.gaisler.com/doc/antn/GRLIB-TN-0014.pdf

[19] Pénétration d’une Freebox V4 http://www.f-x.fr/wikini/wakka.php?wiki=PenetrationV4

[20] Assignation de Free en 2008 http://fsffrance.org/news/assignation-free.pdf

[21] Accès JTAG sur Raspberry Pi https://sysprogs.com/VisualKernel/tutorials/raspberry/jtagsetup/

[22] Carte « bus pirate » http://dangerousprototypes.com/docs/Bus_Pirate

[23] Canal caché Internet https://www.icann.org/news/blog/un-canal-cache-d-internet-c-est-quoi

[24] Attaques par canaux cachés (Nadia El Mrabet) http://www.ai.univ-paris8.fr/~elmrabet/Presentation/Cours5_SCA.pdf

[25] Évaluation d’attaques par canaux cachés: template vs machine learning (Romain Poussier) https://www.canal-

WWW.SMILE.FR


u.tv/video/institut_fourier/romain_poussier_evalutation_d_attaques_par_canaux_caches_template_vs_machine_learning.24374

[26] Roderick Chapman / Yannick Moy AdaCore Technologies for cyber security () https://www.adacore.com/uploads/books/pdf/AdaCore-Tech-Cyber-Security-web.pdf

[27] L’erreur informatique la plus coûteuse de l’histoire https://www.supinfo.com/articles/single/235-erreur-informatique-plus-couteuse-histoire

[28] Projet Yocto https://www.yoctoproject.org/

[29] SafeRTOS https://www.freertos.org/FreeRTOS-Plus/Safety_Critical_Certified/SafeRTOS.shtml

[30] Security-Enhanced Linux in Android https://source.android.com/security/selinux

[31] Smack https://www.kernel.org/doc/html/v4.13/admin-guide/LSM/Smack.html

[32] Automotive Grade Linux https://www.automotivelinux.org/

[33] Introduction to dm-verity on Android https://www.kynetics.com/docs/2018/introduction-to-dm-verity-on-android/

[34] SWUpdate https://sbabic.github.io/swupdate/

[35] RAUC https://rauc.io/

[36] Amazon FreeRTOS https://aws.amazon.com/fr/freertos/

[37] IoT developer survey 2018 https://fr.slideshare.net/kartben/iot-developer-survey-2018

[38] Standard MISRA https://www.misra.org.uk/

[39] How to prevent drone crashes using SPARK https://blog.adacore.com/how-to-prevent-drone-crashes-using-spark

[40] A380 Integrated Modular Avionics http://www.artist-embedded.org/docs/Events/2007/IMA/Slides/ARTIST2_IMA_Itier.pdf

[41] ARINC 653 http://retis.sssup.it/~giorgio/slides/cbsd/Biondi3-ARINC.pdf

[42] Langage SysML-Sec http://sysml-sec.telecom-paristech.fr/

[43] Attack Modeling and Verification for ConnectedSystem Security R. Chelouah / N. Nguyen / S. Mili https://www.researchgate.net/publication/326949723_Attack_Modeling_and_Verification_for_Connected_System_Security

[44] Ptest / Yocto https://wiki.yoctoproject.org/wiki/Ptest

[45] Testimage / Yocto https://wiki.yoctoproject.org/wiki/Image_tests

[46] LAVA https://www.linaro.org/engineering/projects/lava/

[47] Open-DO / Couverture http://www.open-do.org/projects/couverture/

[48] PikeOS de SYSGO https://www.sysgo.com/products/pikeos-hypervisor/security-architecture/

[49] Hyperviseur EB Corbos https://www.elektrobit.com/products/ecu/eb-corbos/hypervisor/

[50] AUTOSAR Adaptive https://www.autosar.org/fileadmin/AOC/AOC_2017/Presentations/AOC2017_Venugopal.pdf

[51] Projet Anbox https://anbox.io/

[52] The seL4 Microkernel https://sel4.systems/

[53] Formally Verified Software in the Real World https://cacm.acm.org/magazines/2018/10/231372-formally-verified-software-in-the-real-world

[54] Layered security for you next SoC https://www.arm.com/products/silicon-ip-security

[55] Gloabal Platform https://globalplatform.org/

[56] Windows 10 IoT https://www.microsoft.com/fr-fr/windowsforbusiness/windows-iot

WWW.SMILE.FR


[57] Azure Sphere https://azure.microsoft.com/en-us/blog/introducing-microsoft-azure-sphere-secure-and-power-the-intelligent-edge/

[58] Le top10 des pièges de l'embarqué open source https://www.lembarque.com/le-top-10-des-pieges-des-logiciels-embarques-open-source_007654

[59] Discussion LinkedIn sur Mediatek vs Qualcomm https://www.linkedin.com/feed/update/urn:li:activity:6470632014247706624

[60] MediaTek still has no plans to release source code to the community https://www.xda-developers.com/mediatek-source-code-release-no-plans/

sÉcuritÉ des objets connectÉs...bouygues immobilier, nestlé, stanhome, avf périmédical, cci,...

Documents