15/11/2025 –, A002
Garantir la protection de données et leur authenticité est incontournable dans n'importe quel contexte open-source et/ou industriel. Le noyau Linux propose des fonctionnalités de vérification d'intégrité notamment par blocs (device-mapper) comme dm-verity mais cela impose d'avoir le système de fichiers bloqué en lecture seule. Comment utiliser ce mécanisme dans un environnement Linux demandant des accès en lecture/écriture ?
Confrontés à cette difficulté dans le cadre d'un projet industriel - le but étant de vérifier et d'authentifier la configuration d'applicatif Linux critique - nous nous sommes penchés sur la possibilité de faire cette opération au niveau du système de fichiers. Disponible sur ext4, f2fs et bientôt XFS, la fonctionnalité fs-verity du noyau Linux vérifie l'intégrité d'un ou plusieurs fichiers sans que l'ensemble des fichiers du système de fichiers ne soit concerné. Pour chaque fichier, fs-verity utilise un arbre de hachage appelé Merkle tree.
Il est important de noter que fs-verity ne protège en rien contre l'usurpation d'un fichier (suppression et remplacement par un fichier différent). Assurer l'authenticité des fichiers devient donc nécessaire, ce qui est possible avec l'ajout de signatures pour chaque fichier verity.
Nous avons utilisé la solution opensource softHSMv2 pour démontrer la faisabilité de l'interfaçage entre fs-verity et un Hardware Security Module afin de pouvoir signer l'empreinte de la racine du Merkle tree pour chaque fichier avec des clés RSA provenant du HSM via PKCS#11. Cette solution est facilement reproductible et donc parfaite pour des besoins de développement, car elle ne nécessite pas de matériel dédié (softHSM est une implémentation logicielle d’un HSM). Attention, le support des jetons (tokens) PKCS#11 est uniquement disponible depuis fs-verity-utils v1.5 (librairie userspace utilisée).
La seconde partie de cette présentation expliquera comment un environnement logiciel de confiance comme OP-TEE (Open Portable Trusted Execution Environment) peut être utilisé pour fournir les mêmes fonctionnalités qu'un HSM, ici en utilisant l'ARM TrustZone et une Trusted Application (TA) PKCS#11. Enfin, il existe aussi des composants matériels comme YubiHSM, Nitrokey HSMv2 ou Pico HSM qui peuvent être intégrés à moindre coût dans un projet industriel ou open-source.
Ingénieur Systèmes Embarqués (breton !) chez IoT.bzh. Intéressé par le développement Linux embarqué (boot, drivers...) avec des environnements sous contraintes de sécurité, de temps réel (image minimale, RTOS...) et à faible consommation d'énergie.