Lennart Poettering a publié une proposition de modernisation du processus de démarrage des distributions Linux, visant à résoudre les problèmes existants et à simplifier l'organisation d'un démarrage vérifié, confirmant l'authenticité du noyau et de l'environnement système de base. Les modifications nécessaires à l'application de la nouvelle architecture sont déjà intégrées dans la base de code de systemd et concernent des composants tels que systemd-stub, systemd-measure, systemd-cryptenroll, systemd-cryptsetup, systemd-pcrphase et systemd-creds.
Les changements proposés se résument à la création d'une image unique et universelle UKI (Unified Kernel Image), combinant l'image du noyau Linux, un gestionnaire de démarrage pour le noyau à partir de l'UEFI (UEFI boot stub) et un environnement système en mémoire initrd, utilisé pour l'initialisation initiale avant le montage du système de fichiers racine. Au lieu de l'image de disque RAM initrd, l'UKI peut inclure l'ensemble du système, permettant de créer des environnements système entièrement vérifiés, démarrant en mémoire. L'image UKI est présentée sous la forme d'un fichier exécutable au format PE, qui peut être chargé non seulement par des chargeurs traditionnels, mais également appelé directement depuis le firmware UEFI.
La possibilité d'appel depuis l'UEFI permet d'utiliser la vérification d'intégrité et d'authenticité par signature numérique, englobant non seulement le noyau mais aussi le contenu de l'initrd. Par ailleurs, le support de l'appel depuis des chargeurs traditionnels permet de conserver des fonctionnalités telles que la fourniture de plusieurs versions du noyau et le retour automatique au noyau fonctionnel en cas de problèmes avec le nouveau noyau après l'application d'une mise à jour.
Actuellement, la majorité des distributions Linux utilisent dans leur processus d'initialisation une chaîne : « firmware → shim de Microsoft vérifié par signature numérique → chargeur GRUB vérifié par signature numérique de la distribution → noyau Linux vérifié par signature numérique de la distribution → environnement initrd non vérifié → système de fichiers racine ». L'absence de vérification de l'initrd dans les distributions traditionnelles pose des problèmes de sécurité, car cet environnement est notamment utilisé pour extraire les clés nécessaires à déchiffrer le système de fichiers racine.
La vérification de l'image initrd n'est pas prise en charge car ce fichier est généré sur le système local de l'utilisateur et ne peut pas être signé numériquement par la distribution, ce qui complique considérablement l'organisation de la vérification lors de l'utilisation du mode SecureBoot (pour signer initrd, l'utilisateur doit générer ses propres clés et les charger dans le firmware UEFI). De plus, l'organisation actuelle de démarrage ne permet pas d'utiliser les informations provenant des registres PCR TPM (Platform Configuration Register) pour contrôler l'intégrité des composants de l'espace utilisateur, en dehors de shim, grub et du noyau. Parmi les problèmes existants, on mentionne également la complexité de la mise à jour du chargeur de démarrage et l'absence de possibilité de restreindre l'accès aux clés dans le TPM pour les anciennes versions des systèmes d'exploitation, devenues obsolètes après l'installation de la mise à jour.
Les principaux objectifs de l'implémentation de la nouvelle architecture de démarrage :
- Fournir un processus de démarrage entièrement vérifié, couvrant toutes les étapes depuis le firmware jusqu'à l'espace utilisateur, et confirmant l'authenticité et l'intégrité des composants chargés.
- Liaison des ressources contrôlées aux registres PCR TPM avec séparation par propriétaires.
- Possibilité de pré-calcul des valeurs PCR sur la base de celles utilisées lors du démarrage du noyau, de l'initrd, de la configuration et de l'identifiant local du système.
- Protection contre les attaques de retour en arrière, liées au retour à une version vulnérable précédente du système.
- Simplification et renforcement de la fiabilité des mises à jour.
- Support des mises à jour du système d'exploitation ne nécessitant pas de réappliquer ou de préparer localement les ressources protégées par le TPM.
- Prêt du système pour la réalisation d'une attestation à distance pour confirmer la conformité du système d'exploitation et des configurations chargées.
- Possibilité d'attacher des données sensibles à certaines étapes de démarrage, par exemple, l'extraction des clés de chiffrement pour le système de fichiers racine depuis le TPM.
- Fournir un processus de déverrouillage sécurisé, automatique et fonctionnant sans intervention de l'utilisateur pour déchiffrer le disque contenant la partition racine.
- Utilisation de puces prenant en charge la spécification TPM 2.0, avec possibilité de revenir à des systèmes sans TPM.
Source : opennet.ru
