Comment la conformité est vérifiée? c'est le bios qui prends le hash du noyau ? comment fait-il ça ? et en quoi n'est-ce pas possible de charger un noyau qui a le même hash ? comme par exemple l'image du noyau qui viens du disque ?
En espérant que ça ne parte pas en troll.
Rapidement voici la façon dont un TPM fonctionne, il prend des hash successifs du démarrage et de l'éxecution de l'OS et en fonction de cela il ouvre des boites à clef.
Quand tu initialise un TPM il créé une première clef et la stocke dans sa mémoire, et il créé aussi une première boite à clef qui sont toujours accessibles depuis le TPM, cette boite à clef est chiffrée avec les hash de la première clef d'initialisation + la clef fabriquant. On a donc une boite à clef chiffrée qui ne peut être ouverte que par ce TPM là. On va l'appeler BC0 (boite à clef 0)
Cette boite à clef ne peut être ouverte que part le hash de la clef d'initialisation + la clef fabriquant, on va appeler ce hash H0
H0 = hash(clef init + clef fab).
On note que la boite à clef 0 peut être ouverte par le hash H0 de la façon suivante : H0 -> [BC0]
Au moment du boot, le TPM prend un hash des parties invariantes du BIOS (de façon à ce qu'un bios mis à jour ne pourrisse pas les boites à clef)
H1 = hash(BIOS + H0).
Si on veut on peut créer une boite à clef 1 telle que H1 -> [BC1]
Ensuite on commence à pouvoir s'amuser, le TPM va enregistrer et stocker tout un tas d'évèvenements à la queue leu leu. Si on décide par exemple de chiffrer le disque de démarage et de mettre la clef dans TPM. On mesurera H0 et H1 (obligatoire), mais aussi des valeurs H2 (ordre de démarrage), H3 (identité du disque de démarrage), H4 (bootloader) et H5 (état du programme de crypto au moment d'insérer le mot de passe).
Avec H2 = hash(boot order + H1), H3 = hash (uuid Disque Dur + H2), H4 = hash( bootloader + H3) et H5 = Hash(empreinte mémoire processus + H4)
On peut alors créer une boite à clef 5 avec H5 -> [BC5]. Et c'est dans cette boite que se trouve la clef de déchiffrement.
TPM est relativement passif, il prend certaines informations tout seul, mais pour la fabrication des hashs (à part les premiers ou le loader/l'os n'ont par encore la main), il faut lui demander explicitement. Charge donc à l'administrateur de demander des hash intelligent et de placer ses boites à clefs de façon à ce que le contenu ne soit pas facilement attaquable. De plus quoi qu'il arrive un hash de sécurité est forcément construit par dessus H1, donc je ne peux pas demander à TPM le hash d'un binaire seul et y associer une boite à clef.
Dans le cas qui nous intéresse, supposons que je veuille protéger une info et ne la rendre lisible que si je suis dans un environnement connu. Je vais prendre un Hn qui sera égal à Hn=hash(processus + hash(environnement + ... + hash(noyeau + hash(bootloader + hash(uuid disque dur + hash( CMOS + H1))))))
Et j'y associerai une boite à clef BCn.
Et là j'ai bien un environnement contrôlé avec un système qui est quand même assez compliqué à contourner.
Bon c'est une vision assez vulgarisée de la méthode, mais grosso-modo ca marche comme çà. Comme les hashs sont réévalués périodiquement, si quelqu'un trifouille le noyau ou le processus, la boite à clef se referme et il n'y a plus moyen d'utiliser les clefs qu'elle contient pour déchiffrer des messages.
En cas de mise à jour de l'environnement, il faut préparer le TPM à migrer/copier les clefs dans une autre boite. Donc dans l'environnement valide on créé une zone de migration (soit vers un autre TPM, soit vers le même TPM) avec un hash spécifique. Puis on récupère les clefs dans la nouvelle boite dans le nouvel environnement. A noter que les clefs ne sont jamais accessibles en clair en théorie (encore que l'on puisse contourner avec des émulateurs de TPM), les clefs accessibles au sein d'un TPM ne peuvent qu'être utilisée pour chiffrer/décoder (on envoie le flux chiffré, on récupère le flux en clair - ou l'inverse), et les clefs au sein d'une zone de migration sont dans un blob lui même chiffrée avec la clef de migration du TPM de destination.
Jusqu'à TPM 1.2 la norme spécifiait que seule la clef constructeur pouvait être préchargée, le reste du TPM devant être vide et non initialisé. Depuis, des NDA long comme le bras sont venus se rajouter pour l'accès aux normes, donc j'ai complètement laissé tombé TPM. Dommage c'était une technologie très inintéressante...
[^] # Re: Sécurité absolue
Posté par Kaane . En réponse à la dépêche Le noyau Linux 3.2 est disponible. Évalué à 6.
Comment la conformité est vérifiée? c'est le bios qui prends le hash du noyau ? comment fait-il ça ? et en quoi n'est-ce pas possible de charger un noyau qui a le même hash ? comme par exemple l'image du noyau qui viens du disque ?
En espérant que ça ne parte pas en troll.
Rapidement voici la façon dont un TPM fonctionne, il prend des hash successifs du démarrage et de l'éxecution de l'OS et en fonction de cela il ouvre des boites à clef.
Quand tu initialise un TPM il créé une première clef et la stocke dans sa mémoire, et il créé aussi une première boite à clef qui sont toujours accessibles depuis le TPM, cette boite à clef est chiffrée avec les hash de la première clef d'initialisation + la clef fabriquant. On a donc une boite à clef chiffrée qui ne peut être ouverte que par ce TPM là. On va l'appeler BC0 (boite à clef 0)
Cette boite à clef ne peut être ouverte que part le hash de la clef d'initialisation + la clef fabriquant, on va appeler ce hash H0
H0 = hash(clef init + clef fab).
On note que la boite à clef 0 peut être ouverte par le hash H0 de la façon suivante : H0 -> [BC0]
Au moment du boot, le TPM prend un hash des parties invariantes du BIOS (de façon à ce qu'un bios mis à jour ne pourrisse pas les boites à clef)
H1 = hash(BIOS + H0).
Si on veut on peut créer une boite à clef 1 telle que H1 -> [BC1]
Ensuite on commence à pouvoir s'amuser, le TPM va enregistrer et stocker tout un tas d'évèvenements à la queue leu leu. Si on décide par exemple de chiffrer le disque de démarage et de mettre la clef dans TPM. On mesurera H0 et H1 (obligatoire), mais aussi des valeurs H2 (ordre de démarrage), H3 (identité du disque de démarrage), H4 (bootloader) et H5 (état du programme de crypto au moment d'insérer le mot de passe).
Avec H2 = hash(boot order + H1), H3 = hash (uuid Disque Dur + H2), H4 = hash( bootloader + H3) et H5 = Hash(empreinte mémoire processus + H4)
On peut alors créer une boite à clef 5 avec H5 -> [BC5]. Et c'est dans cette boite que se trouve la clef de déchiffrement.
TPM est relativement passif, il prend certaines informations tout seul, mais pour la fabrication des hashs (à part les premiers ou le loader/l'os n'ont par encore la main), il faut lui demander explicitement. Charge donc à l'administrateur de demander des hash intelligent et de placer ses boites à clefs de façon à ce que le contenu ne soit pas facilement attaquable. De plus quoi qu'il arrive un hash de sécurité est forcément construit par dessus H1, donc je ne peux pas demander à TPM le hash d'un binaire seul et y associer une boite à clef.
Dans le cas qui nous intéresse, supposons que je veuille protéger une info et ne la rendre lisible que si je suis dans un environnement connu. Je vais prendre un Hn qui sera égal à Hn=hash(processus + hash(environnement + ... + hash(noyeau + hash(bootloader + hash(uuid disque dur + hash( CMOS + H1))))))
Et j'y associerai une boite à clef BCn.
Et là j'ai bien un environnement contrôlé avec un système qui est quand même assez compliqué à contourner.
Bon c'est une vision assez vulgarisée de la méthode, mais grosso-modo ca marche comme çà. Comme les hashs sont réévalués périodiquement, si quelqu'un trifouille le noyau ou le processus, la boite à clef se referme et il n'y a plus moyen d'utiliser les clefs qu'elle contient pour déchiffrer des messages.
En cas de mise à jour de l'environnement, il faut préparer le TPM à migrer/copier les clefs dans une autre boite. Donc dans l'environnement valide on créé une zone de migration (soit vers un autre TPM, soit vers le même TPM) avec un hash spécifique. Puis on récupère les clefs dans la nouvelle boite dans le nouvel environnement. A noter que les clefs ne sont jamais accessibles en clair en théorie (encore que l'on puisse contourner avec des émulateurs de TPM), les clefs accessibles au sein d'un TPM ne peuvent qu'être utilisée pour chiffrer/décoder (on envoie le flux chiffré, on récupère le flux en clair - ou l'inverse), et les clefs au sein d'une zone de migration sont dans un blob lui même chiffrée avec la clef de migration du TPM de destination.
Jusqu'à TPM 1.2 la norme spécifiait que seule la clef constructeur pouvait être préchargée, le reste du TPM devant être vide et non initialisé. Depuis, des NDA long comme le bras sont venus se rajouter pour l'accès aux normes, donc j'ai complètement laissé tombé TPM. Dommage c'était une technologie très inintéressante...