Le TPM gére le démarrage d'un PC, utiliser une carte à puce sur un raspberry pi n'en fait pas un TPM.
Je ne parle pas de cartes à puces, mais bien de TPM. Leurs gestion est d'ailleurs intégré à U-Boot pour rpi.
Ce qui gère le démarrage d'un PC n'est pas la TPM mais l'UEFI (ou équivalent sur ARM). C'est lui qui détecte le matériel, présente des interfaces standards à l'OS, amorce le bootloader, etc.
Un PC et un programme ne sont pas du tout déterministes.
Si, juste si, c'est le principe même d'un ordinateur et d'un programme non quantique.
La vitesse d’exécution s'ajuste selon la température et la charge, ces petits changements entrainent aussi des modifications d'utilisation des caches ce qui augmentent encore les différences. A voir si ces métriques sont encore utilisés, mais il était surtout question de hash et de signature.
Déterministe ne veut pas dire qui a strictement la même exécution tout le temps, mais qu'avec les mêmes conditions initiales, l'exécution doit être identique à chaque fois.
Les variations liées aux facteurs environnementaux tel que la température et l'humidité sont inclus dans les marges de tolérances prévus par les UEFI/TPM. Tout autre facteur environnemental, tel que des températures extrêmement froides ou de fortes perturbations électromagnétiques ne sont pas des variations environnemental standard, en dehors d'ecosystèmes très spécifiques et contrôlés par ailleurs. Le fait que ces environnements puissent faire passer les UEFI/TPM en dehors des marges prévus est justement souhaités, car en dehors d'environnements spécifiques, ils indiquent un facteur extérieur humain visant à altérer le boot du système.
A l'origine, la root key du TPM ne devait pas être sous le contrôle de l'utilisateur.
Nous ne sommes pas "à l'origine", mais en 2024. A l'origine la cryptographie a été créée à des fins militaires, et ne devait pas être rendue disponible au grand public. Pourtant actuelle, tout le monde utilise de la cryptographie, doit-on en conclure par cela que tout le monde fait parti de l'armée d'une façon ou d'une autre ?
La spécification TPM proposait de vérifier toutes la chaines d’exécution et pas seulement le boot.
Sur des systèmes à fort besoins de sécurités, c'est franchement pas déconnant. Sur du matériel généraliste, d'aucun a dû s'apercevoir que c'était se tirer une balle dans le pied.
Quoiqu'il en soit ce n'est pas le cas à l'heure actuelle. Nous ne sommes pas en 2005, l'informatique a très largement évolué depuis, qu'on le veuille ou non. Rester sur des possibilités de 2005 qui ne se sont pas réalisées (grâce à l'incroyable travail de l'EFF entre autre) presque 20 ans plus tard, c'est assez dommage. Très franchement, à la lecture de son article sur PixieFail, j'ai dû mal à croire que Cory Doctorow ait un bagage technique important.
Encore une fois, le fait d'avoir trouvé cette attaque sur les UEFI, attaque sans strictement aucun rapport avec les TPM, ne démontre strictement en rien que cette attaque n'existe pas sur les BIOS. BIOS qui, encore une fois, ont exactement le même genre d'accès au matériel que les UEFI. Et actuellement, il est probable d'avoir exactement la même attaque de possible sur Coreboot qui est sous développement libre.
Donc encore une fois, utiliser PixieFail pour taper sur les TPM, c'est comme parler de la culture du riz en Asie pour justifier que sa plante grasse sur son balcon en France ne pousse pas bien.
Par contre, si quelqu'un a une alternative à l'utilisation de TPM et Secure Boot pour résoudre le problème de "l'evil maid attack", n'hésitez pas à en faire une publication, ca peut valoir de l'or.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.
[^] # Re: Un journal très orienté
Posté par Astaoth . En réponse au journal De la supériorité des choix éthiques — une brève histoire de TPM, UEFI, et failles incontrôlables. Évalué à 5. Dernière modification le 19 janvier 2024 à 18:31.
Je ne parle pas de cartes à puces, mais bien de TPM. Leurs gestion est d'ailleurs intégré à U-Boot pour rpi.
Ce qui gère le démarrage d'un PC n'est pas la TPM mais l'UEFI (ou équivalent sur ARM). C'est lui qui détecte le matériel, présente des interfaces standards à l'OS, amorce le bootloader, etc.
Si, juste si, c'est le principe même d'un ordinateur et d'un programme non quantique.
Déterministe ne veut pas dire qui a strictement la même exécution tout le temps, mais qu'avec les mêmes conditions initiales, l'exécution doit être identique à chaque fois.
Les variations liées aux facteurs environnementaux tel que la température et l'humidité sont inclus dans les marges de tolérances prévus par les UEFI/TPM. Tout autre facteur environnemental, tel que des températures extrêmement froides ou de fortes perturbations électromagnétiques ne sont pas des variations environnemental standard, en dehors d'ecosystèmes très spécifiques et contrôlés par ailleurs. Le fait que ces environnements puissent faire passer les UEFI/TPM en dehors des marges prévus est justement souhaités, car en dehors d'environnements spécifiques, ils indiquent un facteur extérieur humain visant à altérer le boot du système.
Nous ne sommes pas "à l'origine", mais en 2024. A l'origine la cryptographie a été créée à des fins militaires, et ne devait pas être rendue disponible au grand public. Pourtant actuelle, tout le monde utilise de la cryptographie, doit-on en conclure par cela que tout le monde fait parti de l'armée d'une façon ou d'une autre ?
Sur des systèmes à fort besoins de sécurités, c'est franchement pas déconnant. Sur du matériel généraliste, d'aucun a dû s'apercevoir que c'était se tirer une balle dans le pied.
Quoiqu'il en soit ce n'est pas le cas à l'heure actuelle. Nous ne sommes pas en 2005, l'informatique a très largement évolué depuis, qu'on le veuille ou non. Rester sur des possibilités de 2005 qui ne se sont pas réalisées (grâce à l'incroyable travail de l'EFF entre autre) presque 20 ans plus tard, c'est assez dommage. Très franchement, à la lecture de son article sur PixieFail, j'ai dû mal à croire que Cory Doctorow ait un bagage technique important.
Encore une fois, le fait d'avoir trouvé cette attaque sur les UEFI, attaque sans strictement aucun rapport avec les TPM, ne démontre strictement en rien que cette attaque n'existe pas sur les BIOS. BIOS qui, encore une fois, ont exactement le même genre d'accès au matériel que les UEFI. Et actuellement, il est probable d'avoir exactement la même attaque de possible sur Coreboot qui est sous développement libre.
Donc encore une fois, utiliser PixieFail pour taper sur les TPM, c'est comme parler de la culture du riz en Asie pour justifier que sa plante grasse sur son balcon en France ne pousse pas bien.
Par contre, si quelqu'un a une alternative à l'utilisation de TPM et Secure Boot pour résoudre le problème de "l'evil maid attack", n'hésitez pas à en faire une publication, ca peut valoir de l'or.
Emacs le fait depuis 30 ans, et sans pubs ni télémétrie.