Le problème est qu'une puce TPM n'est pas équipée ni conçue pour négocier une session SSL, et que de ce fait, même si elle peut être utilisée pour faire des opérations de cryptage intervenant dans le SSL, elle n'est pas capable de gérer tout le protocole.
Je ne te suis pas là. Quelle importance qu'elle gère tout le protocole si elle s'occupe des calculs crypto?
Mettre les clefs de cryptage SSL dans la puce et seulement dans la puce est donc une énormité. Au final, même si on met la clef dans la puce, elle sera aussi présente en ram, ce qui la rendra toujours vulnérable à certaines attaques.
Alors là je ne vois pas du tout pourquoi.
En SSL, soit le client n'a pas de certificat et seul le serveur en a un, soit les deux parties possèdent un certificat et il faut en plus protéger la clé privée du client associée à son certificat (qui lui est bien évidemment publique). Mais la puce est sensée savoir le faire.
Dans les deux cas SSL permet de se mettre d'accord sur une clé de session qu'on aimerait bien protéger (puis jeter). J'ignore comment, dans les faits, une puce TPM gère ça, mais je ne vois pas de raison forçant à avoir la clé générée en RAM. Tout ce qu'on a à fournir à la puce c'est le certificat et l'aléa envoyé par le serveur. La puce peut sans doute même se charger de générer l'aléa du client à destination du serveur.
Pour moi la clé ne se retrouve donc jamais en clair en RAM. Si c'est le cas j'aimerai que tu m'expliques plus précisemment comment.
Par contre les données à chiffrer le sont forcément à un moment ou un autre: si on a accès à la RAM pourquoi se fatiguer à aller chercher une clé de chiffrement alors qu'il suffit de lire les données en clair?
[^] # Re: TCPA
Posté par ndesmoul . En réponse à la dépêche Une faille majeure de la cryptographie courante. Évalué à 2.
Je ne te suis pas là. Quelle importance qu'elle gère tout le protocole si elle s'occupe des calculs crypto?
Mettre les clefs de cryptage SSL dans la puce et seulement dans la puce est donc une énormité. Au final, même si on met la clef dans la puce, elle sera aussi présente en ram, ce qui la rendra toujours vulnérable à certaines attaques.
Alors là je ne vois pas du tout pourquoi.
En SSL, soit le client n'a pas de certificat et seul le serveur en a un, soit les deux parties possèdent un certificat et il faut en plus protéger la clé privée du client associée à son certificat (qui lui est bien évidemment publique). Mais la puce est sensée savoir le faire.
Dans les deux cas SSL permet de se mettre d'accord sur une clé de session qu'on aimerait bien protéger (puis jeter). J'ignore comment, dans les faits, une puce TPM gère ça, mais je ne vois pas de raison forçant à avoir la clé générée en RAM. Tout ce qu'on a à fournir à la puce c'est le certificat et l'aléa envoyé par le serveur. La puce peut sans doute même se charger de générer l'aléa du client à destination du serveur.
Pour moi la clé ne se retrouve donc jamais en clair en RAM. Si c'est le cas j'aimerai que tu m'expliques plus précisemment comment.
Par contre les données à chiffrer le sont forcément à un moment ou un autre: si on a accès à la RAM pourquoi se fatiguer à aller chercher une clé de chiffrement alors qu'il suffit de lire les données en clair?