Boot & Secure Boot - iot.bzh - Home · 2018-10-30 · Das U-Boot 26 Octobre 2018 34 Histoire de...

Boot &Secure Boot

Conférence UBS26 Octobre 2018

Jonathan AilletEmbedded Software [email protected]

26 Octobre 2018Boot & Secure Boot 2

Présentation de l’intervenant

● Diplômé d’un Master SIAM en 2012● Développeur dans– Les Applications Linux embarquées– Les Drivers Linux– Les Firmwares– Les Bootloaders


IoT.bzh

IoT.bzh team

● Créé en 2015● Développeur principal d'AGL● https://iot.bzh/en/● http://github.com/iotbzh

Workshop in Lorient

LORIENT

vannes

https://iot.bzh/en/

http://github.com/iotbzh


Automotive Grade Linux (AGL)

● Projet hébergé par la Linux Foundation● OS Linux Open Source développé pour

l’intégration dans les voitures connectées● Sécurité intrinsèque● Architecture micro-services : solution

facilement intégrable pour les constructeurs● Code first (implémentation itérative)


Sujets abordés

● Chaîne de Boot● Bootloaders dans l’embarqué● Das U-Boot● Vérification des binaires au boot● Environnement d’Exécution Sécurisé (TEE)● Exemples de failles connues

26 Octobre 2018Chaîne de Boot 6

Boot

● Au démarrage d’un système, le processeur exécute un micro-programme intégré

● Ce micro-programme va à son tour charger et lancer l’exécution d’un autre programme

● Et ce jusqu’à ce que le boot soit terminé (exécution d’un OS, d’un firmware, ...)


Chaîne de boot sur PC


Chaîne de boot sur PC Linux

● Le processeur exécute son micro-programme (BIOS, UEFI)

● Si le système utilise BIOS, il va charger MBR, qui lui va charger GRUB/GRUB2

● Si le système utilise UEFI, il va directement charger GRUB2 (compatible UEFI)

● GRUB/GRUB2 va a son tour chargerle noyau Linux

● Taille de BIOS/UEFI aujourd’hui : plusieurs Mo


Le cas de l’embarqué

● Le Pre-Bootloader (Rom Code) charge un programme placé une adresse spécifique de sa mémoire

● Ici, la mémoire dédiée à l’exécution est de 109 Ko

● C’est peu pour bootloader devant charger un OS

● Il est moins facile de mettre à jour un bootloader stocké dans la mémoire du SoC

ARM 335x SRAM Layout :



Ajout d’un bootloader à la chaîne de boot :

Mise sous tension où Reset

Pre-Bootloader (Rom Code)

Bootloader de premier niveau (EEPROM)

Bootloader de second niveau (eMMC, SD, USB, ...)



Le Pre-Bootloader (Rom Code)– Stocké en ROM ou en EEPROM– Première section de code exécuté par le processeur

au démarrage– Quasiment aucune fonctionnalité si ce n’est de

charger le bootloader● Parfois possible de sélectionner une mode de boot en

utilisant des entrées matérielles (boutons, jumpers, ...)

– Si stocké en EEPROM, mise à jour possible, mais très souvent bloqué une fois industrialisé



Le Bootloader de premier niveau :

– Chargé et exécuté par le Pre-Bootloader (Rom Code)– Minimaliste : contient le minimum requis pour charger le

second bootloader● Pas forcément d’initialisation de la RAM● Chargement des drivers pour l’exécution du second bootloader

– Petite taille (généralement moins de 128 Ko)– Peu de fonctionnalités– N’est pas amené à être mis à jour souvent– Exemples : SPL, xLoader



Remarques sur le Rom Code et sur le bootloader de premier niveau :– Une fois le développement terminé, très peu

d’interventions● Corrections de bugs/failles● Pas d’apport de nouvelles fonctionnalités

– Peu de possibilité d’influer sur l’exécution● Pas d’invite de commande, d’interface graphique ...



Le Bootloader de second niveau :

– Préparer la plateforme à démarrer l’OS– Configurable (script)– Peut fournir

● Invite de commande● Accès réseau● Lecture/Écriture sur les périphériques (eMMC, I2C, ...)● Tests mémoire et matériels● ...

– Plus facile à mettre à jour


Exemple

26 Octobre 2018Bootloaders dans l’embarqué 16

Les Bootloaders de second niveau dans l’embarqué


Rôles d’un bootloader

● Initialisation du CPU et des fréquences d’horloges

● Gestion des interruptions matérielles● Initialisation du pointeur de pile (stack pointer)● Gestion de l’alimentation des périphériques● Configurations des périphériques● Chargement et lancement du binaire suivant

dans la chaîne de boot


Rôles d’un bootloader desecond niveau

● Chargement et lancement d’un OS (i.e. Linux)– Allumage et configuration du matériel spécifique pour le

démarrage de l’OS (RAM, eMMC/SD, ...)– Implémentation de couches matérielles complexes

(i.e. USB)– Chargement

● du noyau● du système de fichier en RAM (RFS/Initramfs)● du fichier de configuration (device tree)

– Exécution de la première instruction de l’OS


Bootloaders répandus

● RedBoot (Dérivé d’eCos, développé par RedHat)

● LK (« Little Kernel », bootloader utilisé dans Android)

● UEFI (Bootloader présent dans les plateformes embarquées Intel)

● Das U-Boot (« Universal Boot loader », originalement pour PowerPC et ARM)


RedBoot

● « RedHat Embedded Debug and Bootstrap »● Support d’architectures PowerPC, ARM● Possibilité de booter vers différents OS (Linux,

eCos, ...) ● Facilité de flasher les composants● Support de script● Shell accessible par liaison série ou par le

réseau


RedBoot

● Débogueur intégré (GDB) et utilisable par la liaison série ou par Ethernet

● Auto-tests au démarrage● Configuration de boot poussée– Différentes configurations de boot automatique

● Défaut● Recovery

– Chargement des binaires depuis● Le réseau● De la mémoire embarquée sur la plateforme (eMMC, SD, ...)


LK (Little Kernel)

● Utilisé principalement dans Android● Support de d’architecture ARM (32 et 64 bits)● Invite de commande● Initialisation matériel poussée (MMU, DMA,

USB, cryptographie, stockage, ...)● Chargement d’un binaire depuis le stockage

de la plateforme● Compatible avec la vérification de signature


LK (Little Kernel)

● Facilité de flasher les composants● Plusieurs modes de boot– Normal– Recovery

● Mode de démarrage rapide● Commandes d’accès matériels (eMMC/SD, I2C,

SPI, mémoires, ...)● Facilement modifiable


UEFI (en ROM !)

● Le même bootloader que sur les PC● Support de d’architectures x86, ARM (peu

utilisé, sauf sur serveur)● Principalement pour les boards Intel● Interfaces standardisées (par rapport au PC)● Invite de commande● Interface graphique


UEFI (en ROM !)

● Possibilité de boot sécurisé● Support d’un grand nombre de matériel● Très différents des autres bootloaders

embarqués (Closed Source)● Chargement d’images depuis– Le réseau– Tout type de stockage (eMMC/SD, USB, HDD, ...)

● Mode de démarrage rapide

26 Octobre 2018Das U-Boot 26

Das U-Boot


Présentation de U-Boot

● Multi-plateformes● Open Source, licence GPLv2● Utilisation des variables d’environnement– Pour configurer les différents composants matériel

(UART, eMMC, Ethernet, ...)– Pour stocker les paramètres utilisables pour la

suite du boot– Pour configurer un démarrage automatique (si non

interrompu)



● Conçu pour être aussi fiable et aussi léger que possible

● Support de nombreuses architectures PowerPC, ARM, x86, ...

● Fournit un support « out-of-the-box » pour un grand nombre de plateformes

● Compiler U-Boot pour une plateforme supportée est facile en utilisant sa chaîne de cross-compilation



● Configurations par xconfig● Intégré par défaut par de nombreux fabricants

de plateformes embarquées– Android– Automotive– Routeurs– La plupart des plateformes ARM



● Structure du code semblable à celle du noyau Linux

● L’interface utilisateur de U-Boot est une invite de commande (similaire à un prompt Linux)

● Possibilité d’écriture et de chargement de scripts

● Outils pour faciliter le débogage● Peut booter différents types d’OS


Fonctionnalités de U-Boot

● Allumage et configuration du matériel spécifique pour le démarrage de l’OS (RAM, eMMC/SD, ...)

● Boot depuis plusieurs périphériques– Peut charger des binaires depuis l’eMMC, la SD,

l’USB, la RAM, ...● Boot réseau– Peut charger un lot de binaires pour un OS (Kernel,

RFS/Initramfs, device tree) depuis un serveur FTP



● Écriture en zone mémoire– Fournit plusieurs commandes permettant l’écriture

dans des zones mémoire spécifiques (i.e. pour mettre à jour un binaire en eMMC, EEPROM, ...)

● Stockage des variables d’environnement dans une mémoire non volatile

● Utilisation de CLI et de Hush Shell pour son invite de commande



● Fournit des commandes pour utilisations avancées (envoi de commandes eMMC,dialogue sur bus I2C, ...)

● Compatible avec la vérification de signature● Ajout de commandes et de fonctionnalités facilité – Open Source– Compilation simple– Déboguer


Histoire de U-Boot

● 1999 : 8xxROM, bootloader créé parMagnus Damm pour PowerPC

● 2000 : mis a disposition sur Sourceforge par Wolfgang Denk sous le nom PPCBoot

● 2002 : PPCBoot intègre le support ARM et devient Das U-Boot (“U” pour “Universal”)

● 2002 : Porté sur x86● 2002-2004 : Portage sur diverses autres plateformes

(MIPS32, MIPS64, NIOS, Coldfire, Microblaze)


U-Boot de nos jours (en 2015)

● Plus de 15 architectures supportées : ARC, ARM (32/64), AVR32, Blackfin, M68K, Microblaze, MIPS (32/64), NDS32, NIOS2, OpenRisc, PowerPC, Sparc, x86, x86-64, ...

● Plus de 1 000 cibles matérielles distinctes● Plus de 1600 contributeurs distincts● Environ 6500 fichiers C et 250 fichiers assembleurs● Environ 1 200 000 lignes C et 30 000 lignes assembleurs● Environ 325 000 lignes de commentaire


Déroulement de l’exécution


Invite de commande


Environnement de U-Boot

● Conservé entre les boots (sauvegardé en mémoire non volatile)

● Jeu de chaînes de caractères : clé=valeur– Timeout de démarrage– Configuration UART

● Structures de contrôles (if, while, until)


Stockage de l’environnement


Exemple d’environnement


Commandes d’environnement

● ‘printenv’ / ‘env print’ :– Affiche l’environnement courant de U-Boot

● ‘setenv’ / ‘env set’– Permet de créer ou écraser une variable

d’environnement● ‘editenv’ / ‘env edit’– Permet de modifier une variable d’environnement

● ‘env delete’

– Supprime une variable de l’environnement


Commandes d’environnement

● ‘saveenv’ / ‘env save’– Sauvegarde de l’environnement courant en mémoire non volatile

● ‘env default’– Restaure l’environnement de U-Boot par celui qui à été défini à la

compilation● ‘env export’– Permet d’exporter l’environnement courant à une adresse

mémoire spécifique● ‘env import’– Permet d’importer l’environnement stocké à une adresse

spécifique (écrase l’environnement courant)


Variables d’environnement

● ‘bootcmd’– Contient la commande qui va être exécutée par

U-Boot lors d’un démarrage automatique● ‘bootargs’– Contient les arguments passés au binaire exécuté

● ‘bootdelay’– Temps (en seconde) avant le boot automatique


Variables d’environnement

● ‘serverip’– Adresse IP du serveur pour les actions réseau

● ‘ipaddr’– Adresse IP locale de la plateforme

● ‘ethaddr’– Adresse MAC de la plateforme

● ‘netmask’– Masque réseau pour communiquer avec le serveur


Commandes disponibles (v2015.04)


Commandes

● ‘version’– Imprime des informations sur la version de U-Boot

● Version : ‘U-Boot 2015.04-dirty (Aug 25 2017 - 10:55:49)’● Chaîne de cross-compilation : ‘aarch64-agl-linux-gcc (GCC)

6.2.0’● Binutils utilisés : ‘GNU ld (GNU Binutils) 2.27.0.20160806’

● ‘booti’– Permet d’exécuter une image Linux arm64

● Les adresses du Kernel et du device tree doivent être précisées

● Utilisation : ‘booti ${kernel_address} - ${dt_address}’


Commandes

● ‘ext4load’ / ‘ext2load’ / ‘fatload’ – Chargement de binaires depuis une partition ‘ext4’ / ‘ext2’ / ‘fat’ vers une

adresse mémoire spécifiée– Peut charger un fichier depuis une partition sur plusieurs types

d’interfaces (USB, eMMC/SD, ...)● ‘tftpboot’– Chargement de binaires depuis le réseau vers une adresse mémoire

spécifiée● ‘dhcp’– Requête DHCP pour obtenir une configuration sur le réseau local

(un serveur DHCP doit être présent)● ‘ping’– Ping une adresse IP sur le réseau


Commandes

● ‘ext4ls’ / ‘ext2ls’ / ‘fatls’– Permet d’explorer un système de fichier ‘ext4’ / ‘ext2’ / ‘fat’

● ‘mmcinfo’ / ‘mmc info’– Informations sur le périphérique MMC sélectionné

● ‘mmc list’– Liste les périphériques MMC disponibles

● ‘usb info’– Information sur les périphériques USB connectés– Le bus USB doit d’abord être démarré (‘usb start’)


Commandes

● ‘crc32’– Calcul d’une somme de contrôle (checksum) sur une

zone mémoire spécifiée● ‘fdt’– Outil de consultation et de modification du fichier

d’arborescence des périphériques (device tree)● ‘md’– Affichage en hexadécimal / ASCII d’une zone

mémoire spécifiée


Pour un boot manuelsur Linux (Rcar M3)

● Paramétrage des arguments de boot● setenv bootargs 'console=ttySC0,115200 ignore_loglevel

vmalloc=384M video=HDMI-A-1:1920x1080-32@60 root=/dev/mmcblk1p1 rw rootfstype=ext4 rootwait rootdelay=2'

● Chargement des binaires en mémoire– Kernel :

● ext4load mmc 0:1 0x48080000 boot/Image– Device Tree

● ext4load mmc 0:1 0x48000000 boot/r8a7796-m3ulcb.dtb● Lancement de Linux

● booti 0x48080000 - 0x48000000


Pour un boot automatiquesur Linux (Rcar M3)

● Paramétrage des arguments de boot● setenv bootargs 'console=ttySC0,115200 ignore_loglevel

vmalloc=384M video=HDMI-A-1:1920x1080-32@60 root=/dev/mmcblk1p1 rw rootfstype=ext4 rootwait rootdelay=2'

● Configuration de la commande exécutée si boot non interrompu

● setenv bootcmd 'ext4load mmc 0:1 0x48080000 boot/Image; ext4load mmc 0:1 0x48000000 boot/r8a7796-m3ulcb.dtb; booti 0x48080000 - 0x48000000'

● Sauvegarde de l’environnement courant● saveenv


Démonstration d’un boot Linuxsur une carte Renesas RCar M3

26 Octobre 2018Vérifications des binaires au boot 55

Vérifications des binaires au boot(« image signature »)


Pourquoi

● Vérifier l’intégrité des mises à jour appliquées● Empêcher l’exécution de binaires

malveillants/modifiés


Rappel sur lacryptographie asymétrique

● Utilisation de deux clés– Publique– Privé

● Permet de chiffrer un message(seul le destinataire pourra le lire)– Chiffrement du message (clé publique)– Déchiffrement du message (clé privée)

● Permet de vérifier l’identité de l’expéditeur d’un message– Signature du message (clé privée)– Vérification du message (clé publique)


Cryptographie asymétrique pour signer un message

● Validation de l’identité de l’expéditeur du message

● Signature du message incluse

● Dépend du contenu du message– Sinon, très facilement

contournable● Contenu du message lisible– Peu d’importance


Introduction

● Signature des binaires à la compilation● Vérification des binaires à l’exécution● Utilisation d’algorithme utilisant un jeu de clé

privée/public pour la signature du binaire● Tous les bootloaders doivent vérifier le binaire qu’ils vont

lancer– Permet d’établir une chaîne de confiance sur toute la chaîne de

boot● Utilisation d’un espace mémoire fusible (fuse) sur la

plateforme pour stocker la clé publique


Signature du binaire

● La clé privée n’est connue que du fabriquant(et ne doit jamais fuiter, ni être perdue)


Vérification du binaire

● La clé publique peut être lue par tous● Stockée dans une mémoire qui ne peut être écrite

qu’une seule fois (en lecture seule après cette écriture)


Application


Que faire quand lavérification échoue

● La procédure doit être définie– Recovery boot ?– Arrêt de boot ?

26 Octobre 2018Environnement d’Exécution Sécurisé (TEE) 64

Environnement d’Exécution Sécurisé(Trusted Exection Environment)


Introduction

● Objectifs– Ajout d’un environnement sécurisé en cas de

brèche dans la sécurisation l’OS – Accès mémoires/périphériques exclusifs à cet

environnement d’exécution● Implémentations– ARM : TrustZone– Intel : Trusted Execution Technology


« Normal World » vs.« Secure World »

● Deux contextes d’exécution● Intégré au Soc● Peut servir à protéger un espace mémoire (i.e. le bootloader de

premier niveau)


TEE en parallèle avec un OS

● Possible sur architecture mono-cœur– Utilisation d’un hyperviseur

sécurisé● Mémoire partagée– Partage d’informations– Applications présentes

dans les deux mondes


OP-TEE

● Open-source Portable TEE (ARM)– Implémenté par ST-Microelectronics en 2007 puis

repris par Linaro– Fournit un lot d’API pour l’exécution d’applications dans

la « TrustZone » (au standard « Global Platform API »)● Fonctionnalités– Zone mémoire (stockage) sécurisée– Isolation Logicielle– Intégrité des périphériques


OP-TEE

● Exemple d’API fournies par OP-TEE– Stockage sécurisé pour les données et les clés– Opérations de chiffrement– Vérification de temps écoulé

● Mode de lancement– Seul (lancement sous certaines conditions) – En parallèle avec un OS

● Applications– DRM– Paiements– ...


OP-TEE

● Caractéristiques– Besoin de 256 Ko de RAM et de 320 Ko de ROM– Mécanisme d’Application de confiance– Protection des attaques par dépassement mémoires

(« stack canaries protection »)● Applications sécurisées– Applications de confiance signées et identifiées – Vérifications de l’intégrité des applications avant

l’exécution


OP-TEE


OP-TEE

● Démarrage seul ou en parallèle

26 Octobre 2018Exemples de failles connues 73

Exemples de failles connues


Généralités

● Consiste à briser la chaîne de boot prévue● Besoin d’un accès physique à la plateforme

(entrées matérielles, UART, ...)● Peut nécessiter une modification de matériel

(connecteurs, pistes coupées, ...)● Besoin d’un binaire (bootloader, OS) compilé

pour la plateforme● Risque de briquer la plateforme● Limite de la légalité (pertes de garanties, ...)


Accès au bootloader

● Ajout de l’accès à la liaison série de la plateforme● Accès à U-Boot à travers la liaison série– Paramètres de la liaison série (115200 bauds, 8N1, ...)


Accès au bootloader

● Utilité– Changer l’OS par défaut de la plateforme

● OS compilé pour la plateforme● Adresse de stockage de l’OS● i.e. changement de l’OS d’un routeur pour ajouter des

fonctionnalités

– Débriquer une plateforme● Corrections– Ne pas rediriger l’invite de commande de U-Boot sur la

liaison série– Utiliser la signature des binaires dans la chaîne de boot


Boot d’une clé USB (sur PC)

● Interruption du démarrage pour sélectionner le boot sur une clé USB– Par défaut, non protégé

● Lancement d’un autre OS


Boot d’une clé USB (sur PC)

● Utilité– Accès au contenu du disque dur du PC (y compris fichiers

administrateurs Windows) – Possibilité de changer le mot de passe « user » / « root »

d’un système Linux déjà présent– Réparation du système

● Correction– Ajout d’un mot de passe pour l’accès au BIOS/UEFI

(possiblement contournable)– Chiffrer son disque dur (empêche l’accès aux données)


Binaires non signés au bootsur Nintendo Switch

● Utilise une faille connue du Nvidia Tegra X1

● Passage de la console en mode RCM (Reliability-Centered Maintenance)– Mise à la masse d’une pin du

processeur– Combinaison de touches appuyées

● Requête USB spécifique permet une copie mémoire non autorisée (faille dans le ROM Code)– Exécution d’un binaire sans aucune

vérification


Binaires non signés au bootsur Nintendo Switch

● Utilité– Lecture de zones mémoires

protégées – Lancement d’un OS Linux– Altération de l’OS de la

plateforme– Désactivation des sécurités

● Correction– Nécessite une nouvelle

révision matérielle ...


Merci de votre attention

https://iot.bzh/en/


Sources

● U-Boot :– http://www2.thu.edu.tw/~emtools/Embedded%20T

ool%20Chain/Middleware/bootloader.pdf– https://www.meetup.com/fr-FR/Toulouse-Embedde

d-Linux-Android-Meetup/events/226469204/– https://fr.slideshare.net/GlobalLogicUkraine/introdu

ction-to-modern-uboot● Hack Nintendo Switch :– https://arstechnica.com/gaming/2018/04/the-unpat

chable-exploit-that-makes-every-current-nintendo-switch-hackable/

http://www2.thu.edu.tw/~emtools/Embedded%20Tool%20Chain/Middleware/bootloader.pdf

http://www2.thu.edu.tw/~emtools/Embedded%20Tool%20Chain/Middleware/bootloader.pdf

https://www.meetup.com/fr-FR/Toulouse-Embedded-Linux-Android-Meetup/events/226469204/

https://www.meetup.com/fr-FR/Toulouse-Embedded-Linux-Android-Meetup/events/226469204/

https://fr.slideshare.net/GlobalLogicUkraine/introduction-to-modern-uboot

https://fr.slideshare.net/GlobalLogicUkraine/introduction-to-modern-uboot

https://arstechnica.com/gaming/2018/04/the-unpatchable-exploit-that-makes-every-current-nintendo-switch-hackable/



Boot & Secure Boot - iot.bzh - Home · 2018-10-30 · Das U-Boot 26 Octobre 2018 34 Histoire de...

Documents

Transcript of Boot & Secure Boot - iot.bzh - Home · 2018-10-30 · Das U-Boot 26 Octobre 2018 34 Histoire de...