J'ajoute un autre message pour apporter quelques compléments
PerJean a écrit : ↑12 janv. 2023 20:11
À la place de Glenic, je retenterai l'installation en désactivant le secure boot.
Pas convaincu que le risque soit important sans cela, mais bon !
Je comprends tout à fait ton interrogation PerJean et aux débuts d'UEFI / Secure Boot (SB) en 2012/2013 j'enrageais moi aussi contre Microsoft et ce mécanisme de sécurité qui à l'époque rendait l'installation de Linux très très difficile pour ne pas dire impossible sur certains constructeurs qui ne jouaient pas le jeu. Mais la donne a changée et l'implémentation s'est améliorée. Aujourd'hui, toutes les distributions sérieuses le supportent nativement que ce soit Debian, Ubuntu, Fedora (et donc leurs dérivés). Tu pourras d'ailleurs voir que Debian tient un discours positif sur SB dans sa documentation :
https://wiki.debian.org/SecureBoot#What ... oot_NOT.3F
Linus Torvalds lui-même, autrefois vent debout contre le SB a changé de position et accepté l'introduction de protections supplémentaires dans le noyau qui nécessitent SB comme "lockdown" :
https://www.lemondeinformatique.fr/actu ... 76603.html
Maintenant sur le "risque" c'est difficile de répondre car dans un cas d'utilisation personnelle avec des utilisateurs avertis comme vous l'êtes avec Glenic, on peut effectivement estimer que le risque est moins important que sur des systèmes professionnels exposés ou avec une grande hétérogénéité d'utilisateurs. Le SB permet de se protéger d'une attaque sur la chaîne de démarrage. Le SB n'autorisera le démarrage que des OS qu'il considère comme "certifié" pour lui. Ça va même plus loin car il n'autorisera pas un OS dont l'intégrité a été compromise à démarrer
Exemples (non exhaustifs) :
- Ton Linux Mint bien installé avec Secure Boot est compromis en cours d'utilisation, le pirate cherche à rendre persistantes les modifications pour garder le contrôle et bien au prochain reboot, Secure Boot interdira le démarrage des modules infectés car ils ne sont pas signés correctement. Il empêche donc une menace de rester persistante. Avec lockdown que j'évoquais au-dessus on peut même empêcher cette attaque en live (sans SB c'est impossible).
- Tu oublies ta machine quelque part, tu te dis "c'est bon je suis protégé car ma partition est chiffrée", oui mais si on peut démarrer n'importe quel OS modifié, si on peut modifier ton grub, si on peut lancer un firmware EFI non signé/autorisé on peut faire une attaque cold boot et tenter de casser le chiffrement LUKS. SB va limiter ce risque fortement.
C'est la raison pour laquelle, je recommanderai toujours d'installer les distributions avec SB activé d'autant que maintenant c'est très bien supporté. Sauf vraies difficultés de fonctionnement, la balance bénéfices/problèmes penche clairement en faveur du SB à mon sens.
Glenic1 a écrit : ↑16 janv. 2023 20:19
Traduction en français : "le changement suivant de configuration est requis sur le TPM (Trusted Platform Modul) de cet ordinateur : effacer le TPM.
Un seul choix est possible : accepter en pressant la touche F1.
Il semble que le TPM soit le module qui garantit la fiabilité de l'OS qui va être lancé sur l'ordi (que ce soit Windows ou une autre, s'il est qualifié correct par Microsoft et par HP) ??? S'agirait-il du mécanisme qui actionne le Secure Boot ?? Le TPM a-t-il un rapport avec l'UEFI ? Mystère !
Aucune autre touche que F 1 n'est active. Donc, en avant pour F 1 et la remise à zéro du TPM !
Le TPM est une puce de sécurité embarquée sur ta carte mère (voire dans le processeur lui-même) qui a vocation à gérer de façon sécurisée le stockage des "secrets" (mots de passe, clés de chiffrement, empreintes etc). En gros, elle facilite la mise en oeuvre de mesures de sécurité pour l'utilisateur, car elle lui permet de ne jamais connaître les véritables clés de chiffrement ou de déchiffrement. Elle permet en revanche une dérivation via un secret connu par l'utilisateur (mot de passe de session, empreinte digitale) etc. Ainsi en de hors de la machine, chaque élément secret va pouvoir sa propre clé de chiffrement très longue. Le TPM assurera le chiffrement et le déchiffrement à la volée.
Par exemple sur smartphone, depuis Android 10, on a un chiffrement de niveau fichier (chaque fichier à sa propre clé) et c'est donc le TPM qui assure à la volée chiffrement/déchiffrement. Quand tu tapes ton code de verrouillage ou que tu mets ton empreinte (selon ce que tu as mis). Le TPM reçoit l'ordre de libérer la clé de chiffrement qui va bien. Mais si quelqu'un vole ton téléphone et démonte physiquement le stockage, il devra pour déchiffrer les fichiers essayer de casser une clé super longue. Chaque fichier ayant sa propre clé stockée dans le TPM, c'est pas loin d'être mission impossible.
Exactement la même chose sur PC avec le chiffrement du disque dur. Pas encore sous Linux, mais avec Bitlocker sous Windows, l'utilisateur connaît uniquement son mdp de session ou son empreinte digitale, mais pas la clé réelle de déchiffrement du disque dur. Sur une machine avec Secure Boot activé, il sera donc quasiment impossible d'accéder aux données sans l'accord du propriétaire légitime (sauf à ce qu'il ait un mdp ridicule). Extraire le disque dur n'aidera pas non plus...
Il y a de multiples usages du TPM, mais voilà les grands principes. Le lien avec Secure Boot et UEFI c'est que les puces TPM en version 2.0 permettent de stocker les clés de sécurité de Secure Boot. Ce qui permet donc d'assurer une protection sans faille dès le boot. Et donc oui, TPM 2.0 sans UEFI c'est impossible. C'est ce que Microsoft impose désormais pour Windows 11 et je trouve ça plutôt bien personnellement.
Quand tu as vidé le TPM, tu l'as donc vidé de toutes les informations de sécurité qu'ils contenaient de l'ancien utilisateur (clés, empreintes etc.). Cela te permet d'installer sereinement un nouvel OS et de stocker tes secrets à toi dans ce fameux TPM.
Tu l'auras compris, une puce TPM performante permet d'avoir un niveau de sécurité plus élevé sans dégrader les performances ni l'ergonomie pour l'utilisateur. Si le processeur central devait assurer le chiffrement/déchiffrement à la volée en + de faire tourner le système, ça serait très lent. De la même façon, si l'utilisateur devait taper la vraie clé de chiffrement pour déverrouiller chaque élément chiffré, le système serait inutilisable.
J'ai essayé de vulgariser le plus possible mais c'est pas simple
Dis-moi, si quelque chose est incompréhensible.