• [^] # Re: Sécurité absolue

    Posté par . En réponse à la dépêche Le noyau Linux 3.2 est disponible. Évalué à 10.

    Voilà en gros comment ça peut se paser :

    • un éditeur logiciel génère une paire de clés privée/publique

    • la clé privée, il la garde pour lui, et jamais elle ne sort (en théorie) : priv-L et pub-L (L: logiciel)

    • un fabricant de carte mères :

      • génère sa propre paire de clés : priv-M et pub-M (M: matériel) avec les mêmes contraintes
      • met la clé pub-M en ROM dans un chip de sécurité
      • signe la clé pub-L avec sa clé priv-L
      • met la clé pub-L en ROM (ou en flash) dans le chip de sécurité
      • signe un tout petit bout de code avec sa clé priv-M
      • mets ce petit bout de code en ROM dans le chip de sécurité

    Comme le code du chip de sécurité est en ROM il n'est pas modifiable, donc il n'est pas physiquement attaquable (ce qui ne veut pas dire qu'il n'y a pas de faille logicielle, mais c'est une autre histoire).

    Une clé publique est valide si et seulement si sa chaîne de confiance permet de remonter à une clé en ROM :
    - soit la clé est en ROM
    - soit la chaîne de signature permet de remonter à une clé en ROM

    Dans ce cas, il est possible d'ajouter des clés publique en flash, tant qu'on possède une clé privée dont la clé publique est en ROM.

    Une fois que le chip de sécurité a établi la chaîne de confiance des clés publiques présentes, il peut vérifier que la signature du BIOS est validée par une de ces clés publiques.

    Si la signature du BIOS est OK, alors, il est exécuté. Charge au BIOS alors de vérifier de la même manière le code qu'il voudra ensuite exécuter :

    • des modules UEFI ( c'est à la mode ! )
    • un bootloader
    • autre chose...

    Une fois que le BIOS a décidé quel code charger, que ce code est à son tour signé par une clé de confiance, alors le BIOS peut l'exécuter.

    Et ainsi de suite :

    • le bootloader vérfie le kernel
    • le kernel vérifie /sbin/init
    • /sbin/init vérifie /etc/inittab

    Un autre scénario peut être :

    • le bootloader vérifie le kernel et le système de fichiers

    Le but dans tout ça, c'est bien de garantir que jamais du code ne puisse être exécuter sans que sa signature ne soit validée par une clé de confiance.

    Tout repose sur trois choses :

    1. les clés privées priv-M et priv-L ne fuient jamais
    2. les clés privées priv-M et/ou priv-L ne servent jamais à signer un malware (par exemple pour un État)
    3. tout code exécuté en chaîne n'exécute jamais du code non valide.

    Maintenant, si tu as moyen de faire signer ta clé publique par priv-M ou toute autre clé dont la chaîne de confiance remonte à priv-M, alors tu pourras entrer ta clé publique dans le chip de sécurité, et seulement là tu pourras exécuter ton propre code.

    Ou alors, si tu arrive à faire signer un GRUB par une clé priv-M ou priv-L, et que ce GRUB ne fait pas de vérification, alors tu pourras charger le noyau que tu veux.

    Mais il faut bien voir qu'à aucun moment, à partir du code initial en ROM, jusqu'à l'exécution du booloader, la chaîne de confiance n'est brisée. Et c'est ce qui posera problème pour le UEFI secure boot voulu par Krosoft :

    1. il n y aura probablement pas moyens de mettre notre propre bootloader non signé, donc impossible charger notre propre noyau non signé, etc...
    2. il ne sera probablement pas possible de charger notre propre clé dans le chip de sécurité, donc impossible d'exécuter notre propre bootloader signé avec notre clé, etc...

    Hop,
    Moi.