Parfois, je cherche un sujet sur lequel écrire et je me rends compte qu'il y en a un que je suppose avoir couvert, mais, en cherchant, je découvre que je ne l'ai pas fait. L'un de ces sujets est le démarrage mesuré et le démarrage sécurisé, parfois appelés à tort "démarrage sécurisé". Il existe des procédures spécifiques qui utilisent ces termes avec des majuscules (par exemple, Secure Boot), dont je vais essayer d'éviter de parler dans cet article. Je m'intéresse plus aux processus génériques - et à une chute potentielle majeure - qu'à essayer d'entrer dans les tenants et les aboutissants des détails. Ce qui suit est un extrait (fortement édité) de mon prochain livre sur la confiance dans l'informatique et le cloud pour Wiley.
Plus de ressources Linux
- Aide-mémoire des commandes Linux
- Aide-mémoire des commandes Linux avancées
- Cours en ligne gratuit :Présentation technique de RHEL
- Aide-mémoire sur le réseau Linux
- Aide-mémoire SELinux
- Aide-mémoire sur les commandes courantes de Linux
- Que sont les conteneurs Linux ?
- Nos derniers articles Linux
Afin de comprendre ce que le démarrage mesuré et le démarrage de confiance visent à atteindre, examinez la pile de virtualisation Linux :les composants que vous exécutez si vous souhaitez utiliser des machines virtuelles (VM) sur une machine Linux. Cette description est sans doute trop simplifiée, mais (comme je l'ai noté ci-dessus), je ne suis pas intéressé par les détails mais par ce que j'essaie de réaliser. Je vais me concentrer sur les quatre couches inférieures (à un niveau d'abstraction assez simple) :CPU/moteur de gestion; BIOS/EFI ; micrologiciel ; et hyperviseur, mais je considérerai également une couche juste au-dessus du CPU/moteur de gestion, qui interpose un Trusted Platform Module (TPM) et quelques instructions sur la façon d'effectuer l'un des deux processus (démarrage mesuré et démarrage de confiance ). Une fois que le système commence à démarrer, le TPM est déclenché et commence son travail. Des racines de confiance alternatives, telles que des modules de sécurité matériels (HSM), peuvent également être utilisées, mais j'utiliserai des TPM, l'exemple le plus courant dans ce contexte, dans mon exemple.
Dans les deux cas (démarrage sécurisé et démarrage mesuré), le flux de base commence par le TPM effectuant une mesure de la couche BIOS/EFI. Cette mesure consiste à vérifier les instructions binaires à exécuter par cette couche et à créer un hachage cryptographique de l'image binaire. Le hachage produit est ensuite stocké dans l'un des nombreux "emplacements" de registre de configuration de plate-forme (PCR) du TPM. Ceux-ci peuvent être considérés comme des morceaux de mémoire qui peuvent être lus ultérieurement - soit par le TPM pour ses besoins, soit par des entités externes au TPM - mais qui ne peuvent pas être modifiés une fois qu'ils ont été écrits. Ces éléments de mémoire sont protégés en intégrité dès leur écriture initiale. Cela garantit qu'une fois qu'une valeur est écrite dans un PCR par le TPM, elle peut être considérée comme constante pendant toute la durée de vie du système jusqu'à la mise hors tension ou le redémarrage.
Après avoir mesuré la couche BIOS/EFI, la couche suivante (firmware) est mesurée. Dans ce cas, le hachage résultant est combiné avec le hachage précédent (qui était stocké dans le slot PCR), puis également stocké dans un slot PCR. Le processus se poursuit jusqu'à ce que toutes les couches impliquées dans le processus aient été mesurées et que les résultats des hachages aient été stockés. Il existe des processus (parfois assez complexes) pour configurer les valeurs TPM d'origine (j'ai sauté certaines des étapes les plus élémentaires du processus pour plus de simplicité) et pour autoriser (espérons-le, des modifications autorisées) des couches pour la mise à niveau ou la sécurité correctif , par exemple. Ce processus de "démarrage mesuré" permet aux entités d'interroger le TPM une fois le processus terminé et de vérifier si les valeurs dans les slots PCR correspondent aux valeurs attendues, pré-calculées avec des versions "connues" des différentes couches, c'est-à-dire , des versions pré-vérifiées dont la provenance et l'intégrité ont déjà été établies.
Divers protocoles existent pour permettre aux parties externes au système pour vérifier les valeurs (par exemple, via une connexion réseau) que le TPM atteste être correctes :le processus de réception et de vérification de ces valeurs à partir d'un système externe est appelé "attestation à distance".
Ce processus (démarrage mesuré) vous permet de savoir si les fondements de votre système (les couches les plus basses) sont ce que vous pensez qu'ils sont. Mais que se passe-t-il si ce n'est pas le cas ? Le démarrage mesuré (sans surprise, étant donné son nom) mesure mais n'effectue aucune autre action.
L'alternative, "démarrage de confiance", va encore plus loin. Lorsqu'un processus de démarrage sécurisé est exécuté, le processus mesure non seulement chaque valeur, mais effectue également une vérification par rapport à une bonne valeur connue (et attendue !) en même temps. Si la vérification échoue, le processus s'arrêtera et le démarrage du système échouera. Cela peut sembler une approche plutôt extrême pour adopter un système, mais parfois c'est absolument la bonne. Lorsque le système considéré peut avoir été compromis (ce qui est une déduction probable que vous pouvez faire à partir de l'échec d'un processus de démarrage de confiance), il est préférable qu'il ne soit pas disponible du tout que de fonctionner sur la base d'attentes erronées.
C'est très bien si je suis le propriétaire du système mesuré, que j'ai vérifié tous les différents composants mesurés (et les mesures) et que je suis heureux que ce qui est démarré corresponde à ce que je veux. Mais que se passe-t-il si j'utilise un système sur le cloud, par exemple, ou tout système détenu et géré par quelqu'un d'autre ? Dans ce cas, je fais confiance au fournisseur de cloud (ou au propriétaire/gestionnaire) pour deux choses :
- Effectuer toutes les mesures correctement et me communiquer les résultats corrects
- Construire quelque chose en qui je devrais avoir confiance en premier lieu
C'est le problème de la nomenclature « trusted boot » et, pire encore, « secure boot ». Les deux impliquent qu'une propriété absolue et objective d'un système a été établie - il est "fiable" ou "sécurisé" - alors que ce n'est manifestement pas le cas. Évidemment, il serait injuste de s'attendre à ce que les concepteurs de tels processus les nomment d'après les états d'échec - "démarrage non sécurisé" ou "démarrage non sécurisé" - mais, à moins que je puisse être très certain que je fais confiance au propriétaire du système pour faire l'étape deux entièrement correctement (et dans mon meilleur intérêt en tant qu'utilisateur du système, plutôt que le leur en tant que propriétaire), alors je ne peux pas faire d'affirmations plus fortes.
Il y a une énorme tentation de prendre un système qui est passé par un processus de démarrage de confiance et de le qualifier de "système de confiance" quand le meilleur L'affirmation que vous pouvez faire est que les couches particulières mesurées dans le processus de démarrage mesuré et/ou approuvé ont été affirmées comme étant celles que le processus s'attend à être présentes. Un tel processus ne dit rien du tout sur l'aptitude des couches à fournir des assurances de comportement ni sur l'exactitude (ou l'aptitude à fournir des assurances de comportement) de toutes les couches suivantes au-dessus de celles-ci.
Il est important de noter que les concepteurs de TPM savent très bien ce qui est affirmé et que les affirmations sur la confiance doivent être faites avec soin et parcimonie. Malheureusement, la complexité des systèmes, le faible niveau général de compréhension de la confiance et les complexités du contexte et de la confiance transitive font qu'il est très facile pour les concepteurs et les implémenteurs de systèmes de faire la mauvaise chose et de supposer que tout système qui a réussi à effectuer une processus de démarrage de confiance peut être considéré comme "de confiance". Il est également extrêmement important de se rappeler que les TPM, en tant que racines matérielles de confiance, offrent l'un des meilleurs mécanismes disponibles pour établir une chaîne de confiance dans les systèmes que vous pouvez concevoir ou mettre en œuvre, et je prévois d'écrire un article à leur sujet prochainement.
- Bien que cela s'avère être beaucoup plus difficile à faire que vous ne le pensez !
Cet article a été initialement publié sur Alice, Eve et Bob et est réimprimé avec la permission de l'auteur.