« Les bonnes pratiques pour sécuriser les architectures des systèmes embarqués »

La place de plus en plus importante qu’occupe le numérique dans notre quotidien, notamment via l’utilisation des objets connectés, soulève des problématiques majeures autour de la sécurité. La sécurisation des architectures permet de répondre à ces enjeux dont les effets sont potentiellement sévères, comme l’explique ici Yannick Moya, consultant sécurité chez Akerva, cabinet de conseil et d’expertise en cybersécurité créé en 2013.

Il convient tout d’abord de définir la notion d’architecture. En informatique, l’architecture désigne la structure générale d’un système, et plus précisément la manière dont sont organisés les différents éléments (aussi bien logiciels que physiques) entre eux. Les architectures représentent en quelque sorte les “squelettes” de chaque objet numérique. Véritables fondations, elles sont la base du fonctionnement des ordinateurs, des objets connectés et de tout système informatique.

L’utilisation exponentielle des objets connectés et l’omniprésence de systèmes communicants – aussi bien dans l’industrie que chez les particuliers – impliquent donc de nombreuses problématiques liées à la sécurité. Il est de ce fait impératif de prendre en compte les bonnes pratiques de sécurité des architectures pour assurer la disponibilité des services, l’intégrité des informations, la confidentialité des données et même la protection physique dans certains cas.

Les bonnes pratiques d’architecture sécurisée pour les systèmes embarqués s’appuient sur différentes parties qui sont complémentaires et toutes aussi importantes les unes que les autres. Le but étant de réduire le risque qu’un attaquant puisse s’introduire dans le système pour en prendre le contrôle. Il est ainsi nécessaire d’établir une chaîne de confiance dès la mise sous tension de l’appareil jusqu’à son extinction. Dans le cas d’un système embarqué, tous les niveaux doivent être renforcés, de l’accès physique au système d’exploitation en passant par les opérations de démarrage du système.

Tout d’abord, l’accès physique doit être renforcé. Pour des projets confidentiels ou destinés au grand public, il est par exemple nécessaire de confiner le matériel électronique et informatique dans un espace scellé. Il s’agit, avec cette mesure, d’empêcher un attaquant de pouvoir se brancher physiquement au matériel afin d’en extraire des informations ou d’en prendre le contrôle.

Ensuite, le démarrage correspond à la mise sous tension et au lancement du système, c’est le premier maillon de la chaîne de confiance. Il convient donc de mettre en place des mécanismes permettant de vérifier l’intégrité du secteur d’amorçage mais également du système d’exploitation. Ces mécanismes se basent en général sur des vérifications de signatures numériques, ces dernières permettant de confirmer l’identité de l’auteur du code et de garantir que le code n’a pas été modifié ou corrompu depuis qu’il a été signé. Il existe différents logiciels, tels qu’U-Boot, qui sont utilisés comme secteurs d’amorçage et permettent l’implantation de tels mécanismes de sécurité. Si ce premier maillon de la chaîne de confiance n’est pas correctement mis en œuvre, alors un attaquant pourrait compromettre le secteur d’amorçage afin de démarrer sur un système d’exploitation malveillant.

Enfin, le durcissement du système d’exploitation, véritable socle du système, est lui aussi primordial, et ce afin de limiter au maximum la surface d’attaque et réduire les vulnérabilités. La mise en place d’un certain nombre de points de contrôle (vérification de configuration, suppression de tous les éléments non indispensables au système…) permettra de freiner l’attaquant et ses interactions avec le système. Dans ce cadre, lorsqu’un système Linux embarqué est utilisé, les développeurs peuvent suivre des guides consacrés à la bonne utilisation de systèmes embarqués comme les documents Recommandations de configuration d’un système GNU/Linux ou encore Recommandations de sécurité relatives à un système GNU/Linux, disponibles sur le site de l’ANSSI. A ce niveau on peut noter qu’un attaquant peut profiter d’un manque de configuration de l’architecture pour obtenir un point d’entrée dans un système d’exploitation non durci et non mis à jour.

Quels sont les risques d’une architecture non sécurisée ?

L’application, quant à elle, permet au système de répondre à son rôle fonctionnel. Les exécutables développés par les entreprises doivent ici impérativement suivre des règles de codage strictes. Au-delà, le code source doit faire régulièrement l’objet d’analyses statique et dynamique afin d’éviter l’exploitation d’une vulnérabilité. L’article Développement sécurisé des systèmes embarqués réalisé précédemment par Arkeva permet de mieux appréhender les enjeux de ces procédures. Un code non contrôlé peut également mener à des menaces de type dépassement de mémoire tampon et permettre à un pirate d’exécuter du code malveillant et non prévu initialement.

Une architecture non sécurisée fragilise considérablement un système et devient un danger potentiel pour les utilisateurs. Prenons l’exemple de certaines trottinettes en libre accès que l’on trouve sur les trottoirs de Paris. Une vulnérabilité permettant à un attaquant d’exploiter une faille critique a récemment été détectée. Dans un rayon de 100 mètres autour de la trottinette, l’attaquant devient en mesure de prendre le contrôle de l’appareil et d’interagir sur le système (accélérer, freiner ou bloquer les roues brusquement). Ces deux roues pouvant atteindre 25 km/h, l’exploitation de cette faille s’avère critique pour la sécurité des utilisateurs. Cet exploit a été possible via l’existence d’un seul point d’entrée sur toute l’architecture. La sécurisation des systèmes n’est donc pas à négliger et aucune étape parmi celles évoquées précédemment ne doit y échapper.