TPM2
Chiffrement du disque dur et déchiffrement avec la puce TPM version 2
Système et matériels / Autres matériels et périphériques
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
1) Je veux chiffrer mon disque dur, ne pas donner la clefs de chiffrement, ni la taper au démarrage.
C'est l'utilité de TPM. Je l'ai découverte avec [1].
2) Problème : le document est vieux, et s'applique aux puces TPM 1.2, là je suis à TPM2.
TPM2 n'est officiellement pas pris en charge par aucune distribution linux. Après quelques renseignements, il n'y a pas 1 mais (au moins) 5 outils en développement.
Il n'y a pas 1, mais des méthodes, architecture de chiffrement du disque dur.
3) fonctionnement en gros :
La puce à plusieurs registres, des dynamiques et des statiques.
Dans les dynamiques, au démarrage, il calcule une empreinte de l'ordinateur. Tant que la configuration ne change pas, le résultat du calcule reste identique. Si on change l'entrée du Bios comme init=/bin/bash pour démarrer en tant que root, le calcule n'est plus le même.
On utilise ce calcule comme clef pour "sceller" un fichier, qui lui même contient la clef pour déchiffrer les partitions du disque dur.
4) L'état actuel :
fdisk -l
Code TEXT :
Disque /dev/sda : 447,1 GiB, 480103981056 octets, 937703088 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Type d'étiquette de disque : gpt Identifiant de disque : 7F4D4D90-DB50-4A5D-BC8E-593041AA70F8 Périphérique Début Fin Secteurs Taille Type /dev/sda1 2048 1050623 1048576 512M Système EFI /dev/sda2 1050624 937703054 936652431 446,6G Système de fichiers Linux Disque /dev/mapper/crypt_sda2 : 446,6 GiB, 479563947520 octets, 936648335 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Disque /dev/mapper/vg--mga-lv_root : 50 GiB, 53687091200 octets, 104857600 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Disque /dev/mapper/vg--mga-lv_swap : 4 GiB, 4294967296 octets, 8388608 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets Disque /dev/mapper/vg--mga-lv_home : 392,6 GiB, 421577883648 octets, 823394304 secteurs Unités : secteur de 1 × 512 = 512 octets Taille de secteur (logique / physique) : 512 octets / 512 octets taille d'E/S (minimale / optimale) : 512 octets / 512 octets
5)étant novice, je suis (encore) perdu. Pas de documentation en français, plein de méthode...
6)Liens pêle-mêle
http://2010.rmll.info/IMG/pdf/06_denis_article-2.pdf
https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2/issues/23
https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2
https://github.com/vchatterji/tpm2-luks
https://github.com/rqou/tpm2-luks
https://github.com/latchset/clevis
https://github.com/AndreasFuchsSIT/cryptsetup-tpm-incubator
https://framabin.org/p/?74f5a997e2e1a0b1#aOjE3JZC06v7IjdUfoapRW8paWDdUXatlEjzrRywzgM=
Et j'en ai perdu trois autres, dont deux méthodes.
Prochain poste, quand j'aurai trouvé la méthode qui est prévu pour mon cas.
Édité par Jybz Le 11/10/2018 à 08h08
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
Et déjà les questions tombent...
Est-ce normal d'avoir le GRUB sur la racine au lieu de la partition EFI ?
Dans l'installateur de mageia, j'ai fait "partitionnement personnalisé" et j'ai monté la partition EFI sur /boot.
Maintenant je regarde dans la fstab, et j'ai une drôle de surprise ! (Merci Papoteur)
Citation :
[jybz@localhost ~]$ cat /etc/fstab
/dev/vg-mga/lv_root / ext4 defaults 1 1
# Entry for /dev/sda1 :
UUID=F5D7-E637 /boot/EFI vfat defaults,umask=000 0 0
/dev/vg-mga/lv_home /home ext4 defaults 1 2
none /proc proc defaults 0 0
/dev/vg-mga/lv_swap swap swap defaults 0 0
/dev/vg-mga/lv_root / ext4 defaults 1 1
# Entry for /dev/sda1 :
UUID=F5D7-E637 /boot/EFI vfat defaults,umask=000 0 0
/dev/vg-mga/lv_home /home ext4 defaults 1 2
none /proc proc defaults 0 0
/dev/vg-mga/lv_swap swap swap defaults 0 0
1) J'ai raté quelque chose et recommence l'installation ?
2) Je soumets un rapport de bug ?
Édité par Jybz Le 11/10/2018 à 08h05
lebarhon Membre non connecté
-
- Voir le profil du membre lebarhon
- Inscrit le : 09/10/2010
- Groupes :
-
Équipe Mageia
-
Membre d'Honneur
Jybz :
Est-ce normal d'avoir le GRUB sur la racine au lieu de la partition EFI ?
Est-ce normal d'avoir le GRUB sur la racine au lieu de la partition EFI ?
Je ne vais pas t'aider sur le chiffrement, mais concernant Grub2, il est installé dans /boot et l'ESP (EFI System Partition) est monté dans /boot/EFI, donc il n'est pas contradictoire que Grub2 soit à la fois dans /boot et (en petite partie) dans l'ESP.
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
Pour une installation "normale" c'est pas un soucis. Mais là je crois que j'ai besoin de grub dans sda1 (non chiffré).
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
https://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/
Je dois effectivement taper mon mot de passe pour déverrouiller la partition chiffrée deux fois :
Citation :
Bonus: Login once
You’ve probably noticed that there remains the minor annoyance of having to decrypt your drive twice: once for GRUB and once for the kernel. Evidently, when GRUB passes control to the kernel, the encrypted drive is dismounted.
You’ve probably noticed that there remains the minor annoyance of having to decrypt your drive twice: once for GRUB and once for the kernel. Evidently, when GRUB passes control to the kernel, the encrypted drive is dismounted.
Traduction :
Citation :
Bonus: Login une seule fois
Vous l'avez probablement remarqué qu'il reste le léger dérangement de déchiffrer le disque deux fois : une fois pour GRUB et une seconde fois pour le noyau. Évidemment, quand GRUB passe le contrôle au noyau, la partition chiffrée est démontée.
Vous l'avez probablement remarqué qu'il reste le léger dérangement de déchiffrer le disque deux fois : une fois pour GRUB et une seconde fois pour le noyau. Évidemment, quand GRUB passe le contrôle au noyau, la partition chiffrée est démontée.
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
Citation :
Attention. Depuis déjà avant 2017 une partition EFI créée sur une autre unité est utilisable, et… utile.
Si on a configuré l'ordinateur pour qu'il démarre en priorité sur cette seconde unité bootable, disque ou clé USB, et que celle-ci comporte une partition EFI l'ordinateur ira bien y chercher le programme de démarrage \EFI\boot\bootx64.efi et le lancer s'il s'y en trouve un. Celui-ci pourra être le grubx64.efi (ou le shimx64.efi en Secure Boot) linux installé sous ce nom.
À ce moment on n'est encore ni sous Ubuntu, ni sous Windows ni un autre linux.
Si c'est bien le grubx64.efi (…
celui-ci va aller lire dans la même partition EFI de notre seconde unité le petit fichier \EFI\ubuntu\grub.cfg. Son contenu permet de pointer vers la partition Ubuntu de notre seconde unité pour y lire le gros fichier /boot/grub/grub.cfg et continuer le processus de démarrage. Ce fichier représente le menu, et peut être différent d'un homonyme installé sur le premier disque.
En cas de multiboots on peut ainsi avoir des menus différents suivant que l'on démarre depuis le premier disque ou depuis une unité USB.
La partition EFI de la seconde unité est donc bien utilisable, même si en 2018 on devait encore la remplir manuellement avec les répertoires \EFI\Boot et \EFI\ubuntu lors de l'installation.
Mais curieusement après le démarrage c'est la partition EFI du premier disque qui est effectivement montée, ce qui à ce stade ne sert plus à autre chose que de préparer une éventuelle mise à jour du chargeur grub.
Ce qui a pour conséquence le problème suivant: lors d'une mise à jour de la seconde unité le grub l'est sur la mauvaise (le premier disque).
En outre le fichier \EFI\ubuntu\grub.cfg du premier disque se fait couramment écraser et renvoie lors d'un boot ultérieur à tort vers /boot/grub/grub.cfg de la seconde unité, on n'a plus le bon menu sur la première.
Et si la seconde unité a été retirée on ne démarre plus.
Ceci élève cette anomalie au rang de bug.
La cause en est que l'installeur met d'office dans le fichier /etc/fstab du système qu'il installe une ligne visant à monter la partition EFI de la première unité.
Pour régler ce problème on doit y remplacer l'UUID présent par celui de la partition EFI de la seconde unité.
On le trouve facilement par la commande blkid dans un terminal.
Contrairement à l'installeur, qui seul privilégie le premier disque, le grub linux est pleinement apte à exploiter indifféremment la partition EFI de toute unité sur laquelle on démarre.
Si on a configuré l'ordinateur pour qu'il démarre en priorité sur cette seconde unité bootable, disque ou clé USB, et que celle-ci comporte une partition EFI l'ordinateur ira bien y chercher le programme de démarrage \EFI\boot\bootx64.efi et le lancer s'il s'y en trouve un. Celui-ci pourra être le grubx64.efi (ou le shimx64.efi en Secure Boot) linux installé sous ce nom.
À ce moment on n'est encore ni sous Ubuntu, ni sous Windows ni un autre linux.
Si c'est bien le grubx64.efi (…
celui-ci va aller lire dans la même partition EFI de notre seconde unité le petit fichier \EFI\ubuntu\grub.cfg. Son contenu permet de pointer vers la partition Ubuntu de notre seconde unité pour y lire le gros fichier /boot/grub/grub.cfg et continuer le processus de démarrage. Ce fichier représente le menu, et peut être différent d'un homonyme installé sur le premier disque.En cas de multiboots on peut ainsi avoir des menus différents suivant que l'on démarre depuis le premier disque ou depuis une unité USB.
La partition EFI de la seconde unité est donc bien utilisable, même si en 2018 on devait encore la remplir manuellement avec les répertoires \EFI\Boot et \EFI\ubuntu lors de l'installation.
Mais curieusement après le démarrage c'est la partition EFI du premier disque qui est effectivement montée, ce qui à ce stade ne sert plus à autre chose que de préparer une éventuelle mise à jour du chargeur grub.
Ce qui a pour conséquence le problème suivant: lors d'une mise à jour de la seconde unité le grub l'est sur la mauvaise (le premier disque).
En outre le fichier \EFI\ubuntu\grub.cfg du premier disque se fait couramment écraser et renvoie lors d'un boot ultérieur à tort vers /boot/grub/grub.cfg de la seconde unité, on n'a plus le bon menu sur la première.
Et si la seconde unité a été retirée on ne démarre plus.
Ceci élève cette anomalie au rang de bug.
La cause en est que l'installeur met d'office dans le fichier /etc/fstab du système qu'il installe une ligne visant à monter la partition EFI de la première unité.
Pour régler ce problème on doit y remplacer l'UUID présent par celui de la partition EFI de la seconde unité.
On le trouve facilement par la commande blkid dans un terminal.
Contrairement à l'installeur, qui seul privilégie le premier disque, le grub linux est pleinement apte à exploiter indifféremment la partition EFI de toute unité sur laquelle on démarre.
source : https://doc.ubuntu-fr.org/uefi
Du coup, j'ai la question, est-ce que /boot/EFI/EFI/Mageia/grubx64.efi peut lire directement un fichier de configuration /boot/EFI/EFI/Mageia/grub.cfg ? Si oui, il pourra surement lire d'autre fichiers et déchiffrer une clef.
Édité par Jybz Le 11/10/2018 à 11h36
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
https://wiki.archlinux.org/index.php/Dm-crypt/Encrypting_an_entire_system
Toujours, le wiki d'archlinux est conséquent !
Je crois que vers là fin, ça correspond le mieux à la configuration actuelle.
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
Apparemment la partition sda1 ESP est bien monté sur /boot/EFI
Du coup GRUB est bien dans /boot dans la partition racine qui est dans une LVM chiffré dans sda2 .
J'hésite entre reformater le disque dur (car la partition EFI, pour respecter les spec FAT32 doit être au moins de 512Mo). Je n'ai pas de place entre la LVM et la partition ESP pour y insérer une partition /boot .
Soit je tente l'impossible, en ajoutant les fonctions de déchiffrage au premier stade du bootloader grub, mais pas sûr d'y arriver...
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
1) les pilotes
2) les outils
Si je cerne bien, il y a deux TSS (TPM2.0 Software Stack) (Ou PLT Pile Logicielle TPM, ou PLM Pile Logicielle du Module de la Plateforme de Confiance) :
-IBM
-Intel
Intel :
https://software.intel.com/en-us/blogs/2018/08/29/tpm2-software-stack-open-source
git:
TSS : https://github.com/tpm2-software/tpm2-tss
outils : https://github.com/tpm2-software/tpm2-tools
IBM :
https://sourceforge.net/projects/ibmtpm20tss/
git:
TSS : https://sourceforge.net/p/ibmtpm20tss/tss/ci/master/tree/
Ouais il ne se foulent pas chez ibm...
Autre lecture intéressante : https://www.96boards.org/blog/getting-started-with-the-secure96-tpm/
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
[jeudi 11 octobre 2018] [10:56:46 CEST] <Jybz> Jordan_U: Thank you, I found where grub was install, as you said, in the LVM. So if I get it, /boot/EFI/[...].efi is the first stage of the bootloader, and starts the second stage in the encrypted root partition.
[...]
[vendredi 12 octobre 2018] [18:46:50 CEST] <Jordan_U> Jybz: Yes, you could think of it like that. (With distros that use secure boot, as opposed to what upstream grub-install does, all needed modules are baked into the grubx64.efi in the ESP, so no grub code is loaded from /boot/, though the kernel images still are).
Merci !
Alors vu mon niveau, voici ce qui se profile :
Reformater le disque dur pour avoir :
ESP 550Mo
/Boot 550m
LVM
/
SWAP
/home
Je vais surement prendre la TSS de IBM car il a de bon commentaire,
et appliquer la méthode décrite pour TPM1.2 de Kevin DENIS en prenant juste les outils TPM2 à la place de TPM1.2.
Jybz Membre non connecté
-
- Voir le profil du membre Jybz
- Inscrit le : 10/10/2018
- Groupes :
-
Administrateur
-
Forgeron
réinstallé avec un nouveau partitionnement
Code TEXT :
| SDA1 | SDA2 | LVM | | /EFI | /boot | vg-mga-home | vg-mga-root | vg-mga-swap | | /EFI | /boot | /home | / | SWAP |
J'ai eu des soucis pour repartitionner, et l'installateur à planté. En fait, je ne sais pas comment, j'avais mis la swap en ext4 par inadvertance, et c'est passé jusqu'à une erreur de montage avant l'installation à proprement dit. C'est en recommençant le partitionnement que j'ai remarqué l'erreur et tout c'est bien passé. Il n'y a pas eu de message explicite pour m'indiquer l'erreur.
J'ai oublié quelques choses (l'un était dans les mauvais marque page, et l'autre juste absent de mes recherche, enfin, pas loin non plus, mais abs).
Évènement FOSDEM 2018 sur TPM :
https://archive.fosdem.org/2018/schedule/event/tpm/
désignant l'outil d'IBM comme meilleur
Les outils pour TSS d'IBM :
https://sourceforge.net/projects/ibmswtpm2/
J'ai un peur, si je comprends bien, la communication IPC (Inter-process communication) entre les outils fonctionne via la pile TCP/IP. Je ne suis pas sûr que se soit le meilleur choix pour une utilisation depuis le bootloader (grub).
à voir...
Édité par Jybz Le 16/10/2018 à 11h41
Répondre
Vous n'êtes pas autorisé à écrire dans cette catégorie