De nos jours, il est essentiel de garantir la sécurité des appareils intégrés. Comme le souligne cnx-software, la majorité des nouveaux dispositifs contiennent des données sensibles que nous souhaitons protéger contre toute divulgation sur Internet. Il est également crucial d’éviter que ces équipements ne soient exploités au sein de botnets.
Explication des 2 types de données à protéger dans un système intégré
Lorsque nous évoquons la sécurité des systèmes intégrés, il est primordial de déterminer ce qui doit être protégé. Il est difficile de standardiser un modèle de menaces pour tous les dispositifs intégrés, mais quelques exigences communes se dégagent.
En général, les systèmes contiennent principalement deux types de données : d’une part, les binaires et les bibliothèques fixes du système d’exploitation, et d’autre part, des données utilisateur dynamiques, qui sont modifiées lors de l’exécution.
Concernant le système d’exploitation, il est essentiel de préserver l’intégrité de l’image d’usine afin de parer à toute tentative d’attaques par la chaîne d’approvisionnement et à des démarrages de logiciels non autorisés. À cet égard, nous ne considérerons pas les binaires du système comme des informations sensibles. Cependant, la configuration dynamique et les données utilisateur le sont. Ces données, générées uniquement pendant l’utilisation, ne sont ni flasquées à l’usine ni remplacées lors des mises à jour. Leur protection est fondamentale afin qu’elles ne puissent pas être consultées à partir d’appareils compromis.
Bien évidemment, d’autres options et scénarios peuvent également être pertinents selon votre appareil spécifique, mais ces considérations fournissent une base solide pour démarrer.
Gestion efficace des partitions de votre système grâce à Linux
Une stratégie de mise en œuvre s’impose alors. Le système Linux permet une configuration de fichiers très flexible. Pour un dispositif embarqué classique, il se concentre généralement sur les répertoires /etc, /var et /home, qui devront être accessibles en écriture, tandis que le reste peut rester figé.
Nous avons la possibilité de rendre le système de fichiers root (/) immuable et de monter les autres répertoires en mode écriture. Toutefois, gérer plusieurs exceptions devient complexe. Une alternative plus simple est de rendre / écrivable et de le restaurer en mode lecture seule pour /usr, où tous les fichiers systèmes se trouvent. En choisissant cette méthode, nous simplifions la gestion des partitions. Cette approche réduit également les exigences variées des deux partitions en permettant à l’une de nécessiter des contrôles d’intégrité et l’autre un cryptage.
La création des clés de chiffrement devient moins compliquée et davantage sécurisée en générant celles-ci au premier démarrage. Ainsi, il est beaucoup plus pratique d’intégrer le chiffrement dans le déploiement à partir d’une image d’usine unique. Sinon, on risque une réincrustation maladroite des partitions. Une fois de plus, cette méthode facilite la réinitialisation de l’appareil, car il suffit de supprimer les partitions cryptées et de recréer les clés.
Il peut intriguer de se demander comment éviter l’absence d’un système de fichiers au démarrage. Linux requiert effectivement cette fonctionnalité pour accéder à l’espace utilisateur, ce qui nous pousse à utiliser un système de fichiers minimal, connu sous le nom d’initrd.
Assurer la sécurité du système d’exploitation embarqué
En prenant en compte un système de fichiers immuable, les vérifications d’intégrité se font plus simples. Nous pouvons protéger l’ensemble de la partition en utilisant DM-Verity, qui crée une arborescence de hachage des blocs du système de fichiers, menant à une seule valeur de hachage root. Cette dernière permet de vérifier l’intégrité de l’ensemble de l’arborescence.
Il demeure essentiel de signer ce hash root pour attester qu’il provient de notre processus de construction fiable. Cela introduit une certaine complexité, mais une méthode consiste à intégrer le hachage dans la ligne de commande du noyau via usrhash=. Ceci nécessitera l’assemblage préalable de la partition /usr avant d’injecter l’option usrhash dans la commande du noyau. Autrement, cela implique un lien direct avec la partition de démarrage.
Il existe des solutions alternatives afin de stocker le hachage et sa signature de manière distincte. Divers moyens ont émergé récemment, avec la formation d’un groupe dédié à l’établissement de normes. Ce groupe UAPI a ainsi mis en place des standards pour la découverte automatisée du hash root et sa signature, éliminant la complexité de la configuration de DM-Verity. L’outil systemd-repart prend en charge cette automatisation.
Focus sur l’outil Systemd-repart
L’outil systemd-repart facilite le repartitionnement d’un disque selon des fichiers de configuration simples. Cette application aide à faire correspondre la configuration de partitions, rendant le processus simple, mais efficace, et même à créer des images disques à partir de zéro.
Cette configuration pourrait ressembler à ceci :
Avec cette configuration, il est possible d’exécuter :
Il gérera automatiquement la configuration, tandis que systemd-gpt-auto-generator s’assurera des montages appropriés.
Avec celle-ci, nous obtiendrons notre /usr gravé dans l’image d’usine, suivie d’une utilisation de systemd-repart sur l’appareil pour compléter les éléments restants.
Mise en place d’un système de protection pour les données du dispositif intégré
Passons à la première partition dynamique. Il est impératif de protéger les données contre le vol. Cela implique nécessairement une forme de cryptage.
Un moyen simple serait d’exiger un Pincode de la part des utilisateurs, mais cela s’avère peu pratique pour les appareils sans interface. Une solution plus adéquate consiste à utiliser des mécanismes sécurisés qui ne libèrent des clés que lorsqu’un état vérifié est atteint. Bien que de nombreux fournisseurs de composants fournissent ces mécanismes, la mise en œuvre sécurisée est souvent complexe.
Heureusement, nous avons maintenant une norme moderne à suivre: les modules de plateforme de confiance (TPM). Bien qu’il puisse sembler qu’ils nécessitent un matériel spécifique, ils fonctionnent plutôt sous forme d’API, qui peuvent être intégrées à des solutions logicielles exécutées dans des environnements dédiés sur le processeur principal. Là où nous pouvons contrôler le type de firmware, les TPM via le micrologiciel peuvent s’avérer une solution fiable sans matériel dédié.
Le détail de la norme TPM 2.0 n’est pas abordé ici, mais sa pertinence réside dans sa capacité à lier les clés à des états système spécifiques. Il garantit ainsi que ces clés ne sont accessibles que lorsque la chaîne de démarrage a été vérifiée avec succès. Les TPM et UEFI fonctionnent en synergie, et leur intégration à Linux est gérée par le groupe UAPI, qui établit le fonctionnement des registres pour un démarrage sécurisé.
Nous ne traiterons ici que le registre «PCR # 7», qui accumule l’état affectant le démarrage sécurisé. Cette méthode permet de garantir que les clés et les signatures validées apportent une sécurité supplémentaire lors de l’accès aux données sensibles, tant que rien ne peut interagir avec le TPM post-démarrage sécurisé.
Pour réaliser cela, rien de plus simple : utilisez systemd-repart !
systemd-repart synchronisera automatiquement la partition cryptée, garantissant son association avec le TPM et générant un système de fichiers approprié. Ce dernier possédera le bon UUID pour être détecté par un INITRD basé sur Systemd.
Assembons ensemble nos algorithmes de sécurité
Ensemble, configurons MKOSI pour construire l’image d’usine, en bénéficiant de son intégration avec l’outillage SystemD, ce qui évite de reconstruire à partir de zéro.
Nous mettrons en place une configuration simple pour élaborer notre image personnalisée basée sur les packages Fedora :
Ensuite, nous pouvons déposer notre configuration de partition dans mkosi.repart/ qui définira la structure de partition de l’image. Celle que nous avons vue dans la section précédente sera adéquate.
Enfin, la configuration d’exécution pourra être placée dans mkosi.extra pour être incorporée à l’image :
Nous pouvons construire et démarrer le système avec les configurations adéquates.
Conclusion
Ce blog démontre que sécuriser les systèmes Linux intégrés n’est pas une tâche insurmontable. Aujourd’hui, il est possible de sélectionner des composants sur étagère offrant une sécurité bien supérieure aux déploiements actuels.
En effet, il reste essentiel d’analyse les exigences spécifiques au système. Cet article propose une base solide pour le développement de systèmes de fichiers root sécurisés et chiffrés, tout en minimisant la complexité. Cependant, il est vital de mentionner que cet article n’aborde pas tous les aspects de la sécurité des systèmes intégrés. Pour une sécurité avancée, un travail supplémentaire sera nécessaire pour garantir une protection optimale contre les menaces, comme la protection contre le démarrage avec des noyaux obsolètes.
Cette démonstration simple avec mkosi peut aussi être appliquée à des images construites avec Yocto. N’oubliez pas, la sécurité est une priorité ne négligez jamais vos systèmes!
-
Clé USB pour système d'exploitation Linux MX Linux - Installation et récupération de démarrage - Rapide et fiable - Toutes les données cryptées et sécurisées -
Linux Tails OS avec stockage persistant pour accès Internet anonyme sans censure – Clé USB bootable Live – Sécurisez votre vie privée (32 Go)