Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 

Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Sécurisation des architectures des systèmes embarqués

avril 2019 par Yannick Security Consultant, Akerva

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 potentiellement sévères.

Qu’est-ce qu’une architecture sécurisée ?

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 donc 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 - implique 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
La sécurisation complète d’une architecture comprend 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 :
• L’accès physique : le système est composé de matériel électronique et informatique ;
• Le démarrage : permet de faire fonctionner l’intégralité du système ;
• Le système d’exploitation : permet de gérer l’utilisation des ressources ;
• L’application : permet au système de répondre à son rôle fonctionnel.

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.

Le démarrage correspond à la mise sous tension et le 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 sur des vérifications de signatures numériques, ces dernières permettent 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 que « U-Boot », qui sont utilisés comme secteur d’amorçage et permettent l’implémentation de tels mécanismes de sécurité.
Si ce premier maillon de la chaîne de confiance n’est pas correctement implémenté, un attaquant pourrait compromettre le secteur d’amorçage afin de démarrer sur un système d’exploitation malveillant.
Le durcissement du système d’exploitation, véritable socle du système, est primordial, et ce afin de limiter au maximum la surface d’attaque et réduire les vulnérabilités.

La mise en application d’un certain nombre de points de contrôle (des vérifications de configuration, la suppression de tous les éléments non indispensables au système…) permettra de freiner l’attaquant et ses interactions avec le système.

Lorsqu’un linux embarqué est utilisé, les acteurs mettant en place l’environnement peuvent suivre des guides consacrés à la bonne utilisation de systèmes embarqués comme « 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.

Notez 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 durcit et non mis à jour.

L’application, elle, permet au système de répondre à son rôle fonctionnel. Les exécutables développés par les entreprises doivent impérativement suivre des règles de codage strictes.

De plus, le code source doit faire régulièrement l’objet d’analyse 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 notre équipe permet de bien comprendre 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.

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

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 25km/h, l’exploitation de cette faille s’avère critique pour la sécurité des utilisateurs.
Cet « exploit » est possible par 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.


Voir les articles précédents

    

Voir les articles suivants