U-Boot : à la découverte du « démarrage vérifié »

Nous proposons ici de ne présenter qu’une partie de cette séquence de démarrage sécurisé. Pour ce faire, nous parlerons d’une des nombreuses fonctionnalités que propose le projet U-Boot, « Verified Boot », procédé permettant de garantir l’intégrité et la provenance des images chargées par ce dernier (noyau Linux). On parlera ici de mécanisme de signature numérique (fonction de hachage et clé asymétrique).

1. Présentation de la plateforme : SAMA5D27-SOM-EK1

Même si l’étude qui suit est entièrement valide sur la carte de développement utilisée habituellement par l’auteur, la fameuse WaRP7, qui rappelons-le embarque le System On Chip NXP i.MX7, nous utiliserons ici le kit d’évaluation Microchip (anciennement Atmel) de référence SAMA5D27-SOM-EK1 (voir figure 1).

Son nombre important de périphériques (Ethernet, USB, Bus CAN, extension MikroBUS, GPIO, SD/uSD, EEPROM...), ainsi que la présence du System On Module SAMA5D27 embarquant le System On Chip de la famille SAMA5D2 en fait une plateforme très intéressante pour le prototypage rapide et qui plus est industriel (vs Raspberry-Pi/Odroid/...). De plus, cette famille de microprocesseurs intègre des fonctions avancées de sécurité qui nous seront, pour quelques-unes, utiles durant la suite de l’article (Secure Boot, True Random Number Generator, ARM Trust Zone, Tamper Detection (pour se prémunir des attaques physiques au système), chiffrement/déchiffrement à la volée des données en DDR, ...)). Pour les plus curieux, la figure 2 montre le diagramme représentant l’ensemble des fonctionnalités du microprocesseur.

Enfin, de par sa communauté et sa vocation à être utilisé dans un milieu plutôt industriel, cette plateforme possède un excellent support sur les deux « Build Systems » les plus connus dans le milieu de l’embarqué, à savoir Yocto/Openembedded et Buildroot, deux frameworks ayant déjà fait l’objet de divers articles dans les colonnes de GNU/Linux Magazine et Open Silicium. Pour plus d’informations sur ces systèmes de constructions de distribution/firmware, l’auteur ne peut que renvoyer le lecteur vers le très bon article de Pierre Ficheux en [1].

Concernant l’intégration avec le projet Yocto, une couche BSP (Board Support Package) spécifique (meta-atmel) est mise à disposition sur le dépôt GitHub dédié à la communauté Atmel/Microchip, comme le montre la figure 3.

Sur la figure 4, même combat pour le plus français des Build Systems, Buildroot (oui, rappelons ici que Thomas Petazzoni, CTO chez Bootlin est co-mainteneur du projet ! Sans oublier Romain Naour et Yann E. Morin contributeurs majeurs au projet).

2. Parlons un peu sécurité

Sécuriser un système embarqué est dans beaucoup de projets industriels une étape primordiale dans le processus de développement. Protéger les logiciels est quelque chose de tout aussi important que la bonne gestion des mises à jour (Over The Air ou non), et c’est d’ailleurs, dans bien des cas, deux mondes qui se rejoignent. Cette partie sera ainsi l’occasion de rappeler quelques concepts liés à notre étude.

2.1 Quels composants protéger ?

En fait, l’ensemble des éléments est susceptible d’être mis à jour par une intervention externe (via Mender par exemple). Ainsi, on retrouvera les composants d’un système Linux embarqué classique, à savoir :

• le chargeur d’amorçage. Pour notre étude, nous parlerons ici du plus utilisé dans le monde de l’embarqué, U-Boot ;

• on retrouvera l’image noyau ;
• le système de fichiers racine, ainsi que les différentes applications utilisateurs ;
• les différentes données liées à l’utilisateur (logs, fichiers de configuration, base de données…) ;
• enfin, dans certains cas, un applicatif tiers (firmware Cortex M4 pour une utilisation avec un microprocesseur i.MX7, firmware FPGA sur plateforme Xilinx Zynq, et bien d’autres encore).

2.2 Chaîne de confiance ?

Comme présenté en introduction, lors d’un démarrage sécurisé, chaque logiciel se verra être vérifié pour en assurer l’authenticité, ceci dans un seul et unique but, garantir l’intégrité et empêcher un logiciel non autorisé de fonctionner. Pour ce faire, on utilisera des mécanismes à clés publiques (ou cryptographie asymétrique) et plus particulièrement le mécanisme de signature numérique.

Dans le principe, tout reposera sur ce qu’on appelle la chaîne de confiance (ou chain-of-trust pour les anglophones), le tout premier logiciel vérifiera la signature du second logiciel, le second logiciel vérifiera la signature du troisième et ainsi de suite. Ainsi, si une étape de vérification d’un des éléments de la chaîne échoue, la phase de démarrage se verra être interrompue de façon immédiate → démarrage impossible (violation du système) ! Dans un contexte embarqué, le schéma sera le suivant :

• Le ROM Code (appelé RomBOOT pour notre plateforme), qui est le code intégré dans le silicone de la puce en ROM (Read Only Memory ou mémoire morte), vérifiera la signature du Bootloader de second niveau. À savoir qu’il est le tout premier programme à être exécuté lors de la mise sous tension. Du fait de sa présence en zone mémoire protégée, cela nous apporte la garantie qu’il ne pourra jamais être modifié.
• Le Bootloader de second niveau ou chargeur de programme secondaire (SPL au sens générique) vérifiera la signature du Bootloader de troisième niveau (U-Boot, BareBox, etc.).
• Le Bootloader de troisième niveau vérifiera la signature de l’image noyau (et device-tree) ainsi que l’image du système de fichiers racine. C’est cette étape qui sera présentée durant l’ensemble de l’article.

La figure 6 permet de représenter le processus avec les différentes phases du démarrage.

Dans le cas de notre plateforme, le Bootloader de second niveau fait référence au logiciel at91bootstrap et le Bootloader de troisième niveau, U-Boot. Voici un exemple de la séquence de démarrage de notre plateforme (RomBOOT → At91Bootstrap → U-Boot) :

Autre remarque : durant notre étude, nous n’aborderons pas l’aspect TEE (pour « Trusted Execution Environment ») et des différentes notions liées à l’utilisation d’un environnement sécurisé sur les System On Chip (SoC) offrant cette option (e.g TrustZone pour ARM). Même si en effet dans l’implémentation il faut l’avouer, c’est un environnement qui est chargé et vérifié durant la phase de démarrage. Mais rassurez-vous, cela fera sûrement l’objet d’un prochain article !

2.3 Racine de confiance

Vous l’aurez sans doute remarqué, tout repose sur la vérification et le chargement du tout premier logiciel, l’étape où le Rom Code authentifie le chargeur d’amorçage, car c’est lui qui permettra de garantir la cohérence sur l’ensemble de la chaîne. C’est donc ici que rentre en compte ce qu’on appellera la « Racine de confiance » (ou logiciel de confiance). En effet, de par l’utilisation d’une infrastructure à clés publiques pour la vérification des signatures, il est primordial de disposer d’un moyen de stocker celles-ci et de s’assurer de l’impossibilité d’une quelconque modification externe (changement des clés par un attaquant). Pour garantir cette « Racine de confiance » et implicitement s’assurer de l’authenticité du premier logiciel exécuté, plusieurs moyens sont à disposition :

• stocker le premier logiciel (e.g U-Boot) et la clé publique en lecture seul ;
• utiliser un composant intermédiaire, plus connu sous le nom de TPM (Trusted Platform Module), pour la gestion des clés publiques ;
• injecter les clés publiques (dans certains cas le « hash » (SHA256 par exemple) de celles-ci, car moins coûteux pour le stockage) dans une zone mémoire spécifique de la puce et accessible par le Rom Code pour la vérification de la signature du premier logiciel. C’est ce que l’on retrouve sous la dénomination de mémoire OTP (One-Time Programmable), qui, sans besoin de traduction, signifie qu’une fois les clés installées, il est par la suite impossible de venir les changer.

C’est sur ce dernier mécanisme que de nombreux fondeurs ont basé leur implémentation du « Secure Boot » au sein de leur SoC, pour citer quelques références :

• NXP, avec son implémentation HAB, pour High Assurance Boot ;
• Xilinx ;
• Microchip (voir figure 7) [2] ;
• Samsung, avec un exemple concernant la famille Artik en [3].

L’authentification du premier logiciel est quelque chose de très spécifique en fonction des différents processeurs à disposition (outils pour injecter les clés, algorithmes, etc.). C’est d’ailleurs pour cette raison que nous aborderons uniquement l’aspect lié à U-Boot et à la vérification de l’image noyau (et device-tree). Mais si nous devions résumer l’étape de vérification du premier logiciel, elle serait la suivante :

• le ROM Code charge le premier logiciel depuis un espace sécurisé ;
• celui-ci vérifie que le « hash » de la clé publique contenue dans l’image du Bootloader, correspond au hash » contenu en mémoire OTP ;
• il déchiffre la signature du Bootloader par le biais de la clé publique préalablement vérifiée, afin d’en extraire le « hash » ;
• il finit par comparer le « hash » calculé avec le « hash » extrait, si les deux sont égaux, la source est donc authentifiée, et le logiciel peut être exécuté en toute confiance.

2.4 Private Keys

Très peu abordée jusqu’ici, la clé privée permettant de signer le logiciel est un élément critique et lui aussi un maillon essentiel dans le processus d’un démarrage sécurisé. Il n’est donc pas rare d’avoir à mettre en œuvre différentes solutions pour la gestion des clés privées dans un contexte de production. On pourra citer ici les smartcards, clés USB spécifiques ou encore les HSM (Hardware Security Module) qui sont des modules spécifiques pour ce type d’utilisation. Tous disposant d’une norme permettant les différents accès aux périphériques, la norme PKCS#11.

3. « Das U-Boot »

Après avoir parlé des différentes étapes du processus de démarrage sécurisé, il est maintenant temps d’explorer la partie relative à U-Boot afin d’aborder l’authentification de notre image noyau et du fichier dtb associé.

Nous commencerons par introduire les différents éléments et concepts mis à disposition par le projet, ensuite, il conviendra de récupérer les sources de notre chargeur d’amorçage pour par la suite compiler notre première image. Sur notre lancée, nous ferons la même opération, mais pour notre image noyau. Enfin, nous finirons sur différentes étapes liées à la cryptographie (création de clés, signature, etc.).

3.1 Préambule

L’utilisation du démarrage vérifié requiert l’emploi de diverses « configurations ». La principale repose sur l’utilisation du format FIT image, le successeur du format uImage classique.

3.1.1 FIT image : introduction

Comme nous l’avons présenté depuis le début de cet article, la question de la sécurité et de l’intégrité du logiciel est un élément clé dans le processus de développement. C’est pourquoi le format d’image FIT (pour Flattened Image Tree) a été défini afin de répondre aux différentes exigences liées à la sécurité lors du chargement des différents logiciels par le chargeur d’amorçage.

Contrairement à son prédécesseur, ce format se veut être comme une sorte de container pouvant contenir plusieurs types d’images :

• image Noyau ;
• fichiers device-tree ;
• firmwares ou image FPGA ;
• scripts U-Boot ;
• et bien d’autres encore ! L’ensemble étant défini dans les sources de U-Boot (common/image.c).

Ainsi, une FIT image permet de ne disposer que d’un seul fichier, qui lui-même encapsule un ensemble de binaires. Donc plus besoin de charger plusieurs fichiers ! Plutôt intéressant quand même.

Par définition, l’extension pour une FIT image non compilée sera sous la forme .its pour Image Tree Source.

Concernant le sujet principal qu’est la gestion de l’intégrité, dans ce « nouveau » type d’image il est possible d’y intégrer des fonctions de hachage de type SHA1, SHA2 et MD5, contrairement au format « legacy » (uImage) qui lui ne peut gérer que des sommes de contrôle de type CRC32.

Et qui dit fonction de hachage dit signature. En effet, de par son implémentation, il nous sera très facile d’intégrer le mécanisme de signature numérique avec l’utilisation du format d’image FIT qui nous permettra ainsi de garantir et protéger l’ensemble des éléments nécessaires lors de la phase de démarrage, éléments contenus dans un seul et unique fichier (itb, Image Tree Blob).

Nous découvrirons la syntaxe et son utilisation dans la suite de l’article, il est maintenant temps pour nous d’aller récupérer les sources du projet U-Boot et du noyau Linux !

3.2 Construction et mise en place...

3.2.1 U-Boot

Commençons par récupérer les sources de U-Boot, et pour être plus précis, le fork mis à disposition par la communauté Atmel/Microchip (linux4sam), qui est d’ailleurs le référentiel git utilisé par les deux Build Systems évoqués plus haut (l’auteur utilise Yocto/OE) :

Puis il conviendra de choisir la configuration relative à notre plateforme :

Ce qui aura pour effet de créer le fichier .config à la racine.

Il faudra aussi mettre à jour la variable CROSS_COMPILE, afin que celle-ci pointe vers notre chaîne de compilation croisée :

Enfin, avant de prétendre travailler avec une FIT image, il faudra s’assurer de son support au niveau de notre configuration. Pour ce faire, lançons l’interface ncurses :

Dans Boot images > Support Flattened image tree, il conviendra de sélectionner l’option pour le support du format d’image FIT (voir figure 8).

Il est aussi intéressant de disposer de la commande iminfo qui permet d’afficher les informations concernant l’image chargée en mémoire (header). Pour ce faire, dans Command line interface > Boot commands, il faudra sélectionner celle-ci. Un petit exemple est visible en figure 9.

Nous voilà maintenant avec une configuration nous permettant de démarrer avec une FIT image, mais vous l’aurez sans doute remarqué, sans l’aspect signature à ce niveau-ci de l’article. Nous allons d’abord explorer le fonctionnement de ce format sur notre plateforme.

Avant de lancer la génération de notre image U-Boot, il est aussi nécessaire de compiler l’ensemble des outils essentiels pour la génération/manipulation d’une FIT image :

Il est maintenant temps de lancer la génération :

Et voilà !

3.2.2 Noyau Linux

Maintenant que nous disposons d’un Bootloader prêt à accueillir une FIT image, il nous faut dès à présent être en mesure de disposer des éléments qui seront à charger et vérifier par celui-ci pour être intégré au sein de la FIT image. Pour ce faire, il nous faudra générer image noyau et device-tree blob.

Sans plus attendre, téléchargeons les sources du noyau Linux sur le même référentiel que précédemment, configurons notre construction pour notre plateforme, puis lançons la construction :

3.2.3 FIT image !

Nous voilà fin prêts à construire notre première FIT image à destination de notre cible sama5d27. Tout d’abord, commençons par rapatrier l’image noyau et le device-tree associé à la racine des sources de U-Boot :

Puis, éditons notre image en nous basant sur la syntaxe du device-tree comme évoquée un peu plus tôt. Appelons cette image fitImage.its :

Ceci mérite quelques explications :

• le champ description se suffit à lui-même, il est tout de même important de mettre un descriptif clair ;
• #address-cells = <1>, définit le nombre de cellules <u32> utilisées pour encoder le champ d’adresse dans la propriété load ou entry au sein du nœud enfant ;
• images est le nœud principal (node) qui contient un ensemble de nœuds enfants (child node), qui chacun représente une sous-image, dans notre cas :
  • Le nœud enfant kernel, permet de décrire la configuration du composant sous-image, on retrouvera :
    • un champ description permettant de définir brièvement le composant ;
    • un champ data, qui permet de renseigner le chemin vers le fichier externe à prendre en compte pour le composant en question. Dans notre cas, c’est notre zImage ;
    • un champ type, qui permet d’expliciter le type du composant de la sous-image. Ici, nous faisons référence au kernel. On retrouvera aussi des types comme firmware, ramdisk, script, etc. ;
    • le champ arch pour le nom de l’architecture visée, qui est arm dans notre exemple ;
    • le champ os quant à lui permet de spécifier le nom du système d’exploitation, qui fait logiquement référence à Linux dans notre cas ;
    • un champ compression afin de renseigner si un algorithme doit être appliqué sur les données, ici aucune compression, donc propriété à none. Il est possible de spécifier ici : lzo, bzip2, gzip ;
    • le champ load, spécifie l’adresse en RAM où l’image noyau doit être copiée ;
    • le champ entry, spécifie l’emplacement de l’image noyau en mémoire afin de permettre à U-Boot de démarrer celle-ci ;
    • un nœud enfant hash, permettant de spécifier le type de fonction de hachage ou checksum par le biais de la propriété algo. Dans notre exemple, nous avons positionné 2 nœuds enfants pour avoir une gestion par checksum (crc32) et l’autre pour une gestion par hachage (sha256).
  • Le nœud enfant fdt-1, est quasiment identique au précédent, mais cette fois-ci, la propriété datacontiendra le fichier device-tree et la propriété type fera référence au device-tree (flat_dt) ;
  • Le nœud configuration, qui dans notre cas permettra de définir la ou les configurations. Ici une seule configuration est de rigueur. Il faudra donc définir dans le sous-nœud de la configuration, les éléments qui la composent (kernel et fdt-1).

Ensuite, il ne nous restera qu’à générer notre FIT image à partir du fichier source, le tout grâce à la commande mkimage :

Une fois généré, il nous est possible de vérifier le contenu de l’image en listant les informations par le biais de cette même commande :

Le listing de l’image nous permet de constater que celle-ci contient bien une sous-image « Kernel » (kernel) et une sous-image « device-tree » (fdt-1) et que la configuration utilisée par défaut contient bien ces deux sous-images (Default Configuration: 'conf-1'). Il aurait été ici possible de mettre un deuxième fichier device-tree et ainsi créer une deuxième configuration. Mais ça, vous êtes capable de le faire !

Maintenant que l’ensemble nous donne entière satisfaction, il est temps pour nous d’essayer notre premier démarrage avec ce format d’image. Pour ce faire, il faudra mettre à jour l’image U-Boot (u-boot.bin) et positionner le fichier fitImage sur la première partition (juste à titre d’exemple ici, certains préfèreront positionner celui-ci sous/boot, l’auteur le premier). Une fois l’opération terminée, il suffira de stopper l’autoboot au niveau de notre chargeur d’amorçage afin d’avoir la main sur le shell mis à disposition par ce dernier.

Il nous faudra en premier lieu charger notre image (via la commande load qui est plus générique que fatload ou ext4load pour la gestion des accès au File-System) en spécifiant l’interface, le périphérique, la partition, l’adresse et le fichier à récupérer, ce qui nous donne :

Une fois le fichier chargé, il nous est possible de démarrer nos images à l’adresse mémoire préalablement spécifiée. Ceci s’effectue par le biais de la commande bootm :

Comme nous le constatons sur les traces du shell précédent, le Bootloader charge bien les éléments contenus dans la FIT image (voir « Loading Kernel from FIT … ») tout en vérifiant l’intégrité de ceux-ci, qui dans notre cas n’ont pas été altérés (crc32+ sha256+ OK, le + signifiant la réussite lors de la vérification, à l’inverse, le signe – serait apparu).

Sans paramètre, la commande bootm prendra la configuration par défaut (voir using  conf-1 configuration). Mais dans le cas où l’utilisateur souhaiterait par exemple spécifier les sous-images à charger, la commande deviendrait la suivante :

La forme employée est bootm [<addr>]:<subimg1> - [<addr>]:<subimg2>.

Dans le cas d’une FIT image avec plusieurs configurations, l’exécution d’une configuration spécifique s’effectuerait avec la commande ci-après :

Autre aspect intéressant, il est possible d’extraire une sous-partie de l’image via la commande imxtract, chose très utile pour les images de type firmware. Par exemple, sur un i.MX7, le chargement et le démarrage du cortex M4 se ferait comme suit :

Nous voilà maintenant prêts pour attaquer la partie fatidique de l’article, l’aspect vérification. Pour les plus curieux d’entre vous, la documentation relative au format d’image FIT se trouve sous doc/uImage.FIT/ dans les sources du projet U-Boot.

3.3 Verified (U-)Boot

Dans cette dernière partie de l’article, nous allons mettre en pratique les différentes techniques abordées tout au long de notre étude afin de réaliser notre premier démarrage vérifié. Soyez prêts !

3.3.1 Concept

L’étape de signature et vérification de la FIT image avec U-Boot repose sur les mêmes concepts qu’évoqués en début d’article. Dans notre contexte, les étapes seront :

• Pour la génération de la signature :
  • génération du « hash » ou « empreinte » des images par le biais d’une fonction de hachage, sha1 ou sha256 ;
  • chiffrement du « hash » avec la clé privée afin de générer la signature numérique ;
  • stockage de la signature dans la FIT image (FIT image signée).
• Pour la vérification lors du démarrage :
  • lecture de la FIT image ;
  • récupération de la clé publique ;
  • extraction de la signature depuis la FIT image ;
  • calcul du « hash » de la configuration contenue dans la FIT image ;
  • déchiffrement de la signature par le biais de la clé publique afin d’extraire le « hash » ;
  • si les deux « hashs » sont identiques, alors U-Boot pourra charger les images et ainsi garantir l’authenticité de celles-ci.

3.3.2 Implémentation

Sans plus attendre, mettons à jour notre configuration afin d’y ajouter le support pour la vérification de signature d’une FIT image. Il faudra ainsi dans Boot images > Enable signature verification of FIT uImages, cocher l’option comme le montre la figure 10.

Ce n’est pas tout, il estaussi primordial de rajouter le support de la partie cryptographique RSA nécessaire pour signer et vérifier. Il faut donc activer l’option Library routines > Use RSA Library.

Il est maintenant temps de construire notre FIT image avec la prise en compte de notre nouvelle configuration. Partons d’un nouveau fichier que l’on nommera fitImage_sign.its :

Explications :

• Le nœud images restera quasiment identique à notre première image. Il n’est en effet pas forcément nécessaire de garder plusieurs « hash » ici ;
• Le nœud configuration quant à lui se verra être mis à jour avec :
  • le nœud enfant signature qui contient quelques propriétés essentielles à définir afin de garantir la signature de notre configuration :
  • algo, qui permet de renseigner le type d’algorithme utilisé, ici sha256 et rsa4096 ;
  • key-name-hint, pour spécifier le nom de la clé utilisée pour signer l’image. C’est le nom qu’il faudra donner à notre clé privée ainsi qu’au certificat lors de la génération avec openssl ;
  • sign-images, la liste des images à signer. Dans notre cas, nous spécifions le fichier device-tree ainsi que l’image noyau. Mais nous aurions pu ajouter ici une image de type firmware par exemple.

Maintenant que nous avons notre fichier source prêt à être utilisé. Il va nous falloir disposer de tout le nécessaire afin de réaliser les différentes étapes de signature.

Mettons en place dans un premier temps un endroit afin de stocker le matériel relatif à la cryptographie :

Puis générons notre clé privée de type RSA 4096 bits (ou 3072 selon votre humeur !) nécessaire pour les opérations cryptographiques, clé que nous appellerons ici glmf afin d’être cohérent avec notre fichier its :

Et notre certificat à clé publique de type x.509, ici glmf.crt :

Pour les curieux, l’extraction de la clé publique se fera de la manière suivante :

3.3.3 Gestion de la clé publique

Comme déjà abordé lors du second chapitre, afin de vérifier une image signée par une clé publique lors de la phase de démarrage, il faut que celle-ci (la clé publique) soit dite de confiance.

Pour ce faire, U-Boot a fait le choix d’intégrer la clé publique dans le fichier device-tree de la plateforme (dtb au sens U-Boot et non Linux), qui en temps normal est utilisé pour du « run-time configuration » (versus CONFIG_* dans les fichiers de définition de la carte cible) tout comme le fait le noyau Linux par exemple. L’implémentation du support du device-tree dans U-Boot porte le nom de « Control FDT » (Flattened Device Tree), qu’il faudra sélectionner avec l’option CONFIG_OF_CONTROL. De plus, à l’inverse du noyau Linux où le fichier dtb est un fichier binaire à part entière dans l’étape de chargement (que nous avons ici encapsulé dans notre FIT image), il en est une tout autre histoire pour dtb utilisé par le Bootloader. En effet, lors de l’étape de compilation, celui-ci sera construit séparément, mais ajouté au binaire U-Boot par un simple appel à la commande cat, exemple :

Avec ce type de processus, et de par le fait que notre Bootloader est lui-même vérifié par le logiciel précédent, nous pouvons ainsi faire confiance à notre clé publique.

À nous de jouer ! Nous allons dans un premier temps récupérer le fichier dtb de notre plateforme, fichier que nous avons compilé durant la première étape. Ainsi, nous le renommerons pubkey.dtb afin de le différencier durant notre étude, car c’est celui-ci qui contiendra notre clé publique pour la vérification de notre FIT image :

Puis, ayant rajouté le support pour la gestion de la signature, il nous faut maintenant compiler à nouveau les différents outils afin de pouvoir travailler avec notre nouvelle configuration :

Nous avons maintenant la commande mkimage à jour pour réaliser notre étape de signature. Respirez un grand coup et lancez la commande suivante :

Facile, non ?

Si on s’attarde un peu sur les différentes options et leurs paramètres :

• -f, pour spécifier le fichier source en entrée ;
• -K, permet de spécifier le fichier device-tree compilé afin d’y insérer notre clé publique. Nécessaire pour l’étape de vérification sur cible ;
• -k, pour renseigner le chemin contenant la clé privée (glmf.key) et le certificat contenant la clé publique (glmf.crt) pour la vérification ;
• -r, pour spécifier la propriété « required ». Ainsi, il sera donc impossible de démarrer tout logiciel n’ayant pas été vérifié avec cette clé. Dans notre cas, cela signifie que nous forçons la vérification de notre configuration avec notre clé glmf.

Pour de plus amples informations sur les différentes options de la commande mkimage, il sera conseillé de se référer à l’aide de celle-ci :

Pour les (plus) curieux qui se demandent à quel endroit est stockée la signature au sein de note FIT image, mkimage a placé celle-ci au sein du nœud enfant signature dans la propriété value, contenu qu’il est facile de récupérer par la commande suivante :

Il est aussi possible de convertir notre fichier dtb en dts afin de porter attention au nœud signature contenant notre clé publique :

En voici le résultat :

Nous voyons en effet qu’il existe maintenant l’ensemble de la définition relative à notre clé publique (child node key-glmf). On retrouvera par exemple le champ required précédemment configuré ou encore le champ rsa,num-bits qui spécifie le nombre de bits utilisés pour la clé RSA, ici 0x1000 pour 4096 en décimal. Pour de plus amples informations sur les différentes propriétés, la documentation est disponible en [4].

Afin de valider notre précédente opération, nul besoin pour l’instant de mettre à jour FIT image et binaire U-Boot. En effet, il est d’ores et déjà possible de vérifier notre image par le biais de l’utilitaire fit_check_sign que nous venons de compiler. Pour ce faire, nous allons passer en argument notre FIT image accompagnée du fichier dtb contenant la clé publique (pubkey.dtb) :

Comme vous pouvez le constater, la commande nous sort le résultat suivant : sha256,rsa4096:glmf+. Ceci signifie que pour la vérification, une clé de type RSA 4096 bits de nom glmf avec une fonction de hachage de type sha256 a été utilisée. Le + nous informe de la bonne réussite de l’opération (comme vu plus haut dans l’article). À l’inverse, le signe – aurait été présent. Nous pouvons faire le test en modifiant la signature de notre FIT image :

Et relançons l’étape de vérification :

Nous observons bien un problème lors de la vérification de la signature de notre configuration (sha256,rsa4096:glmf-). Jusqu’ici tout va bien ...

L’ensemble de la chaîne étant maintenant validé et fonctionnel (signature + vérification), nous pouvons générer à nouveau notre binaire u-boot.bin. Notez tout de même qu’il faudra être vigilant et utiliser un argument à la commande make afin de spécifier le fichier dtb spécifique à utiliser (notre fameux fichier pubkey.dtb) et non celui généré en premier lieu par U-Boot. Sinon, la clé publique ne serait donc pas contenue dans notre binaire final. Afin de réaliser cette opération, l’argument EXT_DTB devra être utilisé lors de l’exécution de la commande :

Grâce à l’option permettant d’activer le mode verbeux, il nous est possible de constater les différentes étapes relatives à l’ajout de notre fichier dtb contenant la clé publique au sein du binaire u-boot.bin. Ainsi, nous disposons de tout le nécessaire afin de prétendre réaliser un démarrage vérifié via notre bootloader !

3.3.4 Test sur cible

Vous l’aurez compris, il est temps de mettre à jour notre fichier u-boot.bin ainsi que notre fichier fitImage sur la première partition de notre SD Card (l’utilisation du support SD n’est utile que pour les phases de tests soulignons-le, car il n’y a rien d’industriel à utiliser un tel support !).

Comme nous l’avons fait lors du premier test, il nous faudra ici aussi charger le fichier fitImage afin de commencer nos différentes étapes de vérification :

Puis comme lors de notre premier démarrage, lançons l’exécution :

Sans surprise, nous constatons que l’étape de vérification pour notre configuration (Kernel et device-tree) s’est effectuée sans problème pour notre nouveau test sur cible. Il serait maintenant judicieux d’améliorer notre process en intégrant à notre FIT une sous-image RAMDisk.

À titre d’exemple, voici la même séquence de démarrage sur la WaRP7 avec RAMDisk :

3.3.5 Pour résumer

Afin de récapituler un peu l’ensemble des éléments liés à la mise en place du démarrage vérifié avec U-Boot, voici en figure 11 un diagramme permettant de rappeler les différentes étapes.

Autre point : lors de la création de nos différentes FIT images, nous avons sur chaque partie de l’étude, élaboré celles-ci de façon manuelle ce qui, dans certains contextes (industriel pour n’en citer qu’un), peut s’avérer comme une tâche assez lourde et difficilement maintenable suivant les configurations. Mais c’est sans compter sur l’aide du projet Yocto ! En effet, il est possible via celui-ci de générer automatiquement durant la phase de construction, une FIT image, moyennant une configuration assez simple (fichiers*.conf) :

Il est également possible de gérer les aspects signature de la FIT image depuis le build system :

Conclusion

Dans cet article, nous avons pu naviguer dans les différentes étapes d’un démarrage vérifié, en partant du ROM code jusqu’au chargement de l’image noyau par le chargeur d’amorçage, mais sans aller jusqu’à l’étape de vérification du système de fichiers racine via des mécanismes comme dm-verity (pourtant un sujet tout aussi intéressant à explorer).

Tout ceci nous a permis de mettre en place sur une plateforme de type industrielle, un bout du processus du démarrage vérifié avec U-Boot [5]. Mécanisme qui est de plus en plus utilisé sur les périphériques grands publics (e.g smartphones, Chromebook, etc.).

Enfin, comme déjà évoqué un peu plus tôt, il serait à présent intéressant de continuer notre étude sur la partie TrustZone en explorant l’implémentation open source OP-TEE. La suite au prochain épisode…

Références

[1] P. FICHEUX, « Buildroot Vs Yocto Vs le reste du monde », Open Silicium n°20, octobre 2016 : https://connect.ed-diamond.com/Open-Silicium/OS-020/Buildroot-vs-Yocto-vs-le-reste-du-monde

[2] Secure Boot sur Sama5 : http://ww1.microchip.com/downloads/en/AppNotes/SAMA5D2-Linux-Secure-Boot-Application-Note-00002748A.pdf

[3] Secure Boot sur Artik : https://developer.artik.io/documentation/advanced-concepts/secure-os/secure-boot.html

[4] Documentation signature U-Boot : http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/signature.txt

[5] Documentation « verified boot » U-Boot : http://git.denx.de/?p=u-boot.git;a=blob;f=doc/uImage.FIT/verified-boot.txt