Sécurité : Une faille majeure de la cryptographie courante
Posté par chaica (). Modéré le 20 novembre 2006.
Dans une note confidentielle, le chercheur met en avant qu'il a réussi à récupérer une clé de chiffrement de 512 bits en quelques millisecondes.
Il s'agit d'un véritable bouleversement dans le milieu de la cryptographie. En effet la parade habituelle consiste à allonger la longueur de la clé de chiffrement. La technique découverte par Jean-Pierre Seifert consiste à analyser le comportement du processeur lui-même afin de déduire statistiquement la clé de chiffrement.
La seule parade pour l'instant consisterait à désactiver le processus de prédiction du processeur mais selon le chercheur "Une telle mesure ralentirait par quatre le microprocesseur (...)".
Les résultats des travaux de Jean-Pierre Seifert sont attendus lors de la prochaine conférence RSA, début 2007
NdM : Cette attaque implique la présence d'un logiciel espion sur la machine effectuant les opérations cryptographiques et dans ce cas il existe souvent d'autres moyens pour obtenir la clé.
De plus, cette attaque ne marchera pas si les opérations cryptographiques sont effectuées sur un matériel distinct du processeur, par exemple un token cryptographique. L'impact est donc surtout pour le grand public et en particulier les échanges sur internet sécurisés par SSL.
![[fr]](../images/fr.png)
L'article du Monde (1878 hits)![[en]](../images/en.png)
L'abstract de l'article scientifique (720 hits)-
L'article scientifique au format pdf (992 hits)
> Lire la dépêche (106 commentaires, moyenne: 3,1).
Vous avez demandé le commentaire #776696.
Run by 
Cette page a été générée par Templeet en 0.1198s (dont 0.0118 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
TCPA
n'est pour le moment qu'une puce proposant des promitives pour la cryptographie et encore complètement inoffensive commence a se répandre dans les ordinateurs grand public. Je pense que ce pourrait être une solution même si je sais que certains voient rouge dés qu'on prononce ce mot.
En effet, je suppose que la puce propose de générer une clef de manière plus sécurisée, sinon, je ne vois pas bien son interêt.
La Roue du Temps
[^]Re: TCPA
Allez, je me joue la parano ...
Et puis comme j'y pige rien à ce principe de prédiction ... (Bin, oui, si on fait une prédiction, il faut bien vérifier si elle est juste, donc tout de même faire le calcul, donc je ne vois pas en quoi ca accélèrerait les choses ...)
Bref, est-ce que ca ne serait pas un fake alarmant, Intel, fait le timide au début ... et d'un seul coup, ils nous sortent pas solution miracle : TCPA !
Les gens qui ont eu peur de cette faille annoncée à grands coup médiatique se rue sur les étiquettes TCPA sans plus réfléchir à leur vie privée ...
Moi, j'attend un "proof of concept" avant de sonner l'alarme ...
PS: une explication sur la prédiction serait aussi la bienvenue
[^]Re: TCPA
C'est toujours embêtant de trouver une faille de sécurité mais à mon avis pas dramatique. Ce qui me m'étonne le plus est le bruit que fait cette nouvelle.
Je ne serais effectivement pas étonné du tout que cette annonce ait été exploitée pour justifier TCPA et le verrouillage des PC.
C'est justement ce que l'on peut lire dans le document toujours d'actualité "FAQ TCPA/PALLADIUM/TC/TCG/LAGRANDE/NGSCB/LONGHORN" http://www.lebars.org/sec/tcpa-faq.fr.html
[^]Re: TCPA
Tout à fait d'accord sur le fait que l'on semble assister à une sorte de compagne médiatique savamment dosée en deux temps... à moins que ce ne soit mon côté paranoïaque qui resurgisse ? :-/
Dans une premier temps, on nous distille quelques annonces sulfureuses. Tiens, en voici une autre du même acabit ici: http://www.securityfocus.com/brief/360 (en anglais), et dont la conclusion est identique: vive TCPA, c'est pour bientôt, rassurez-vous.
Et justement, dans un second temps (miracle!), nous apprendrons que la solution à tous nos maux d'ordre sécuritaire est déjà prête ! Eh oui, une bonne partie des cartes mères possède une implémentation, un verrouillage matériel fonctionnel.
Donc, dans la série "Y'a plus qu'à...", on n'attend plus que l'activation.
Il faut sans doute qu'un terroriste numérique nous fasse sauter une centrale énergétique quelque part pour que...
...euh, pardon. Mon esprit s'égare dans la science-fiction, là.
<mode humour noir>
Bref, en 2007, votez TCPA. Ch'est ben bon, mangez-en, etc...
</mode humour noir>
Après le logiciel libre, le matériel libre arrivera-t-il à temps, lui ?
[^]Re: TCPA
Ça me rappelle ce que m'expliquait mon médecin à propos du "mongering" de l'industrie pharmaceutique: on invente une nouvelle maladie par exagération ou assimilation de symptômes connus, et juste après, miracle, sort la molécule qui peut soigner la nouvelle maladie.
Quand on parle tant de traçabilité, on serait en droit d'exiger celle de l'information: d'où vient cette info? Le journaliste a-til enquêté tout seul? Ou a-t-il été contacté par une agence de relations presse? Dans ce cas, qui la payait?
[^]Re: TCPA
Le matériel libre existe déjà: il s'agit de l'OpenSparc de Sun. Je suis très étonné qu'aucun fondeur chinois ne l'ait encore produite, ni qu'aucun programme européen n'ait été lancé pour la produire et assurer l'indépendance technologique du continent...
[^]Re: TCPA
Les fondeur/designer européens existent. Il y en a même des (bon d'accord un) français (bon d'accord franco-italien): STMicroelectronics.
[^]Re: TCPA
Pour faire simple...
Quand tu exécutes une instruction, il faut d'abord la lire (chargement dans le pipeline d'instructions), décoder l'instruction et les éventuels arguments qui peuvent se trouver dans la mémoire centrale, dans un cache ou dans des registres puis exécuter... Tout ça se fait en plusieurs étapes dont le nombre varie en fonction de l'architecture du processeur. Quand une instruction en est à la phase d'exécution, la prochaine est en cours de décodage, la suivante encore en train d'être chargée dans le pipeline, etc.
Seulement quand tu as un branchement conditionnel (if), il faut pouvoir déterminer quelle est l'instruction suivante à exécuter : celle du branchement "if true" ou celle du branchement "if false". La prédiction essaie de déterminer quelle sera celle que l'on va effectivement exécuter. Et si la prédiction a bon, tout se passe bien, on continue le flux d'instructions du pipeline. Sinon, il faut vider le pipeline car on y a chargé des instructions du mauvais branchement qui n'a pas à être exécuté. Il faut repartir avec un pipeline vide et on perd plusieurs étapes avant d'avoir à nouveau une instruction décodée prête à être exécutée.
--
http://www.tessier-net.org
[^]Re: TCPA
Et donc la question qui vient apres est :
en quoi est-ce que cela permet de gagner du temps ?
Comment est faite cette prédiction ? Si je veux gagner du temps, il faudrait que cette prédiction ait une probabilité assez importante pour ne pas avoir a dépiler le pipeline et recommencer les etapes de l'instruction suivante effectivement lancée.
[^]Re: TCPA
On va prendre un exemple concret : pendant un temps les processeurs Intel (je sais pas si çà vaut pour AMD ni si çà a pas changé depuis) considéraient que le if { foo } avait 80% de chances de s'exécuter par rapport au else { bar }, et commençaient à charger le code de cette partie avant même d'avoir pu évaluer le test conditionnel.
Si la prédiction était juste, on gagne du temps : le processeur a chargé le code pendant qu'il calculait la condtion. Par contre si elle était fausse, il faut vidanger le code chargé pour rien, puis charger le bon code : pendant ce temps il ne peut rien faire d'autre, et perd donc du temps.
A une échelle humaine c'est difficilement quantifiable vu que çà se joue sur des millièmes de secondes (si c'est pas moins), par contre pour le processeur c'est énorme. Depuis les processeurs ont des instructions de prefetch, mais il me semble qu'elles ne concernent que les données, pas les branchements conditionnels (ex: je vais avoir besoin des données à telle adresse, assure toi qu'elles soient dans le cache pendant que tu calcules autre chose stp merci)
Certains processeurs (chers) ne s'encombraient pas de tant de finesse : pendant le calcul de la condition ils chargeaient les deux blocs possibles, exécutant ensuite celui qui s'était avéré bon (qui a dit brutal ?) ;)
[^]Re: TCPA
Sur un pentium 4, l'architecture pipeline contient plus de trente niveaux. Cela signifie que la sortie effective du processeur à environ 30 instructions de retard par rapport à la lecture du code exécutable. Si tu as besoin des résultats d'une comparaison pour faire un branchement conditionnel, ça signifie que tu vas attendre le résultat pendant 30 cycles d'horloge avant de sauter à la bonne adresse ... je te laisse juge pour la performance d'une boucle for ...
Une solution peut consister à essayer de prédire les dits branchements, de façon à ce que le cpu précharge les instructions qui correspondent alors au saut prédit.
Il existe plein de méthode plus ou moins sophistiquées, mais pour donner un exemple simple, on peut dire par exemple qu'on prédit que le saut pris sera en arrière (c'est simplissime, mais pas idiot !)
Bien sûr il existe des méthodes bien plus sophistiquées que je n'ai pas le temps de détailler ici.
Pour info, la qualité prédiction des branchements de cpu est vraiment cruciale pour des cpu comme le pentium 4 (avec beaucoup d'étages pipelines), car à chaque fois que le prédicteur se vautre, il faut vider le pipe et recharger tout avec le bon code exécutable !
Cela explique en partie pourquoi les cpu d'amd sont bien plus performants que les cpu intel (a fréquence égale) pour des applications difficiles à prédire (ie : jeux, compilation ...), alors que les cpu d'intel vont plutot roxer sur des trucs monotones (compression de données ...)
tu pourra trouver des éléments de compréhension ici :
http://www.onversity.net/cgi-bin/progarti/art_aff.cgi?Eudo=b(...)
Soutenez le logiciel libre, en adhérant dès maintenant à l'April
[+] [^]Re: TCPA
Dans les premières versions de prédiction Intel avait fait simple,
c'etait simplement une analyse statistique de ce qu'il se passait sur le CPU.
L'analyse du code executé implique donc une optimisation du CPU.
Simple ... mais pas si efficace que ca puisque dans mes souvenirs ( ca commence à dater) seul 15% des branchements predictifs étaient valides.
Fox
[^]Re: TCPA
Je n'ai pas de source sous la main, mais je suis sûr que le simple exemple que j'ai cité dépasse les 65% de prédictions valides ...
Cependant, tes souvenirs ne sont peut être pas erronés : intel a toujours été meilleur en marketing qu'en architecture de prédiction de branchement ! (cf prescott et les autres ...)
Soutenez le logiciel libre, en adhérant dès maintenant à l'April
[^]Re: TCPA
15% ça parait vraiment petit.
Si on prend les branchements classiques (jump if equal, jump if above, etc), on n'a que 2 possibilités : suivre le branchement ou pas.
Donc une prédiction mauvaise ne devrait pas faire moins de 50%... Me trompe-je ?
[^]Re: TCPA
Pour les 50 %, tu a tout a fait raison ! Ne sous-estime quand même pas les compétences d'intel : ils sont capables de faire 15 % !
Soutenez le logiciel libre, en adhérant dès maintenant à l'April
[^]Re: TCPA
Un exemple de code ou les "if" vont aller statistiquement sur "faux".
Les codes d'exceptions d'un pilote.
Par exemple, à la lecture d'un bloc de disque, "statistiquement" tu n'as aucune erreur (Il faut l'espérer en tout cas).
donc tu as une liste de cas d'erreurs du type :
if(hardwareFailure1){
interrompre et retourner une erreur
}
faire(xxx)
if(hardwareFailure2){
interrompre et retourner une erreur
}
faire(yyy)
.....
Le processeur peut optimiser en estimant que "statistiquement" l'assertion est fausse.
[^]Re: TCPA
De toute façon, les prédicteurs de branchement sont utiles dans le cadres de boucles répétées, pas du tout pour une assertion isolée, car sinon ça ferait graver beaucoup de transistors pour ne pas gagner grand chose ...
De plus, vus les techniques utilisées actuellement, les prédicteurs de branchement ont une certaine "inertie" qui les rends peut utiles pour des tests de type assertion, ou plus particulièrement, des exécutions qui ont beaucoup d'entropie (ex : jeux, normalement tu ne passe pas ton temps a appuyer toujours sur la même touche (même à quake !)).
Si on prend par exemple une "simple" prédiction à bi-modale, ont peut considérer que les 2-3 premiers passages en boucles seront prédit faux, mais ca n'empêche pas d'avoir des performances de plus de 90% en moyenne.
Soutenez le logiciel libre, en adhérant dès maintenant à l'April
[^]Re: TCPA
J'en doute fortement. Sinon, ils auraient carrément retiré le mécanisme de prédiction de branchement et auraient choisi toujours le saut arrière ou toujours le saut du branchement vrai... avec une probabilité plus proche de 50%
A 15% de branchements bien prédits, ils auraient aussi de très bons résultats en faisant le contraire de leurs prédictions ! :-)
--
http://www.tessier-net.org
[^]Re: TCPA
Si on me donne leur mécanisme de branchement qui fonctionne dans 15% des cas, je vous en fais un pas cher qui voit juste dans 85% des cas.
Pour cela, appelons oracle1 le prédicteur de branchement et supposons qu'il retourne une valeur booléenne pour dire s'il faut brancher ou pas.
oracle2(x)=return(not(oracle1(x)).
Le coup du 15%, c'est sans doute de l'amélioration. Au lieu d'avoir du 50/50, on a du 65/35 et c'est tout de suite moins ridicule.
[^]Re: TCPA
Pour les references, si vraiment le sujet vous interesse, je vous recommande le bouquin d'Hennessy et Patterson : "Computer Architecture: A Quantitative Approach". Excellent bouquin sur l'architecture des ordinateurs modernes.
[^]Re: TCPA
Pour comprendre les méthodes de prédiction de branchement :
http://en.wikipedia.org/wiki/Branch_prediction
Soutenez le logiciel libre, en adhérant dès maintenant à l'April
[+] [^]Re: TCPA
Dans les premières versions de prédiction Intel avait fait simple,
c'etait simplement une analyse statistique de ce qu'il se passait sur le CPU.
L'analyse du code executé implique donc une optimisation du CPU.
Simple ... mais pas si efficace que ca puisque dans mes souvenirs ( ca commence à dater) seul 15% des branchements predictifs étaient valides.
Fox
[^]Re: TCPA
Une fois ta clef générée par le TPM, il faut tout de même qu'elle soit consultable par les logiciels de crypto... et une fois qu'elle est en ram, le risque est exactement pareil que sans TPM...
Le TPM ne sauve pas pour ce genre de situation. Le problème n'est pas la génération de la clef mais bien sa présence en ram.
[^]Re: TCPA
Hmmm, c'est sur que la clé censée rester secrète sorte de la TPM ?
[^]Re: TCPA
Hmmm, c'est sur que la clé censée rester secrète sorte de la TPM ?
Non. Les failles se situent plutot dans la puce (sécurité par l'obscurité) et dans les logiciels qui utilisent cette puce, y compris l'OS (puisqu'ils ont le droit d'utiliser la puce pour décrypter, un mauvais bug dans ces logiciels peut permettre à un cracker de décrypter ce qu'il veut).
[^]Re: TCPA
Euh, non. L'intérêt de la puce TPM c'est qu'elle fait elle-même tous les calculs cryptographiques (enfin ceux qui font intervenir les clés stockées dans la puce).
Les clés ne sortent pas du composant. On peut voir cette puce comme une carte à puce intégrée au PC. Le logiciel crypto s'interface avec la puce TPM en lui disant de chiffrer/déchiffrer/signer, ...
Avec une puce TPM les clés cryptographiques ne sont jamais en RAM!
Cela n'en fait pas un système inviolable pour autant. Si tu as un accès physique à la puce, des attaques similaires à celles existantes dans le domaine des cartes à puce sont envisageables. Attaques qui ont parfois des contremesures d'ailleurs... Mais de telles attaques sont tout de même plus complexes à mettre en oeuvre...
Donc un logiciel espion ou l'attaque présente ne fonctionnent pas ici.
Par contre si la puce sert à déchiffrer un message, il est évident que le dit message va se retrouver en clair en RAM.
[^]Re: TCPA
La puce TPM fait les calculs cryptographiques, mais seulement ceux nécessaires au TCPA.
Faudrait te renseigner sur la manière de gérer les clefs dans le TPM, les clefs qui sont accessibles et celles qui ne le sont pas.
Dans le cas ou les clefs ne seraient pas accessibles aux applications, elles n'auraient de toutes façons aucun intéret à moins que la puce n'intègre tous les protocoles de crypto nécessaires aux opérations (et le SSL/TLS est plutôt spécialisé et complexe) et soit capable de faire du traitement de flux avec une vitesse suffisante.
Par contre, il existe de vrais accélérateurs SST/TLS hardware, qui eux ont une utilité réelle pour les serveurs.
[^]Re: TCPA
Je ne voit pas pourquoi la puce TPL serait limitée au TCPA. Normalement l'utilisateur peut décider de générer ses propres clés conservées dans la puce TPM qui joue le rôle de coffre fort. Après un logiciel de messagerie peut très bien s'interfacer avec la puce comme il le ferait avec un banal carte à puce.
D'autre part une clé est dédiée à un algo donné. Par exemple une clé RSA est faite pour l'algo RSA pas pour du DSA. Normalement il faut même spécifier si la clé est prévue pour faire du chiffrement ou de la signature.
Si tu veux utiliser un algo exotique inconnu de la puce TPM, cela signifie juste que tu ne pourras pas stocker la clé correspondante sur la puce et que se sera au logiciel de faire tout le boulot. En gros si la clé que tu veux utiliser est dans la puce, elle fait le boulot, sinon c'est ton application.
Pour moi une puce TPM n'a d'intérêt que côté client et n'a pas pour but d'accélerer les calculs cryptos. Pour cela il existe d'autres solutions comme celles que tu cites, dédiées aux serveurs.
[^]Re: TCPA
Les clés asymétriques sont rarement utilisées directement pour le chiffrement/déchiffrement.
C'est trop consommateur de ressources CPU.
Elles servent uniquement à chiffrer/déchiffrer une clé 'symétrique' (générée aléatoirement lors du chiffrement).
C'est le même principe, en gros, pour un fichier ou une connexion ssl.
Les algorythmes symétrique sont beaucoup plus performants, et on peut facilement ajouters des clés de destinataires sans démultiplier la taille du message.
J'imagine, c'est une supposition, que la puce connait un certains nombres de fonctions crypto symétriques 'classiques'.
C'est tout à fait faisable en hard.
Du temp où on utillisait encore le DES, ça se faisait déjà.
Les avantages de la crypto asymétrique sans les inconvénients....
[^]Re: TCPA
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.
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.
Au final, de toutes façons, ce bug est plutôt improbable, à part chez les gens qui installent n'importe-quoi sur leurs machines ou les serveurs web partagés où un webmaster peu scrupuleux essayerait d'espionner le voisin.
[^]Re: TCPA
Concept interessant... Cela pourra-t-il être utilisé sur les serveurs web mutualisés ?
[^]Re: TCPA
vu que cela requiert un logiciel tournant localement pour faire l'attaque sur la prédiction de branche, c'est à peu près le seul cas de figure où je vois un vrai risque. Ce n'est pas une attaque pouvant être lancée à distance.
[^]Re: TCPA
Avec les informations dont on dispose pour le moment (et sans avoir lu l'article scientifique) c'est difficile d'évaluer réellement le risque.
Si il n'est pas nécessaire d'être root, alors non seulement les serveurs mutualisés, mais aussi tout serveur vulnérable à une exécution arbitraire (et c'est le cas de beaucoup de serveurs web, les sites en php vulnérables à ce type de faille sont légion) sont potentiellement vulnérables.
L'autre risque, à vue de nez, c'est tout ce qui repose sur l'authentification par certificat client. Ca augure de méthodes de vol de clef de certificat (et puisque la clef est déduite, pas de phrase de passe qui tienne) qui feront froid dans le dos à tous les admins qui gèrent des accès vpn de nomades par cette méthode. Inciter quelqu'un souvent non informaticien à installer tel ou tel logiciel avec un spyware en prime n'est pas très difficile et passera souvent inaperçu...
Bon, après, comme le dit NDM, côté serveur il y a souvent d'autres moyens pour obtenir la clef quand on a la main sur une machine... Une fois qu'il y a une exécution arbitraire, le tout est de trouver une faille locale pour avoir le root, et c'est généralement une question de patience avant tout ;)
Clément Hermann (nodens)
- "L'air pur ? c'est pas en RL, ça ? c'est pas hors charte ?"
Jean in L'Histoire des Pingouins, http://tnemeth.free.fr/fmbl/linuxsf/
GPG : pgp.mit.edu - 0xEBD1399D
[^]Re: TCPA
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
Soit elle gère la connexion du début à la fin et aucune clef ne passe en clair dans la ram, soit elle ne la gère pas, et il y a forcément un moment où le software prend le relais pour réalimenter les différentes fonctions de la puce tpm afin de l'utiliser dans le processus de cryptage.
Si la puce ne gère pas la session complètement, il y aura forcément un moment où il faudra, par exemple, récupérer le résultat d'une fonction de la puce , le traiter en soft, et le réinjecter dans une autre fonction, ce qui implique un passage par la ram.
Idem, je ne vois pas comment cette puce pourrait gérer ça, et je ne trouve aucune littérature sur le sujet. Je ne vois donc pas comment prétendre qu'elle le fait.
Le point positif, si le tpm supporte l'algorithme symétrique utilisé lors d'une session, c'est qu'effectivement les attaques de timing ne pourront être utilisées pour faire des statistiques sur la prédiction de branche du cpu puisque les opérations se dérouleront sur un autre cpu, c-à-d la puce tpm. Mais les clefs transitant à l'occasion en ram (sauf preuve du contraire), il y aura toujours d'autres attaques possibles si la machine est déjà compromise au point de faire tourner un outil permettant de faire l'attaque sur la prédiction de branche.
Enfin, qui dit qu'on ne va pas trouver des exploits sur les puces TPM, et si cela se produit, comment y remédier?
[^]Re: TCPA
Je ne suis pas vraiment convaincus par tes arguments concernants une session SSL. Autoriser qu'une clé secrète se retrouve en RAM serait tellement stupide que je vois mal les constructeurs commettre une telle bourde.
Mais de toute façon je ne suis guère convaincu par les TPM en eux même, sauf éventuellement pour authentifier une machine. Si on se place au niveau de l'utilisateur un objet personnel comme une carte à puce (ou un dongle) est beaucoup plus appropriée. (Et certaines cartes à puce savent faire du SSL de manière adéquate).
[^]Re: TCPA
hmm je ne sais pas comment marche une puce tpm, mais à prioris ca doit être comme une cryptobox ou nimporte quel autre hsm. Bref le periph ne connait que les operations crytpo de base et les applis (type openssl) une api specifique pour utiliser la clef, sans jamais y accéder. Pkcs11( http://www.rsasecurity.com/rsalabs/node.asp?id=2133 ) sert typiquement à ça, gère les opérations de crypto de base, et pour tout ce qui est plus évolué, openssl et l'engine pkcs11 s'occupe de faire de lien entre la clée et tes opérations (typiquement une session ssl ou autre); celle ci ne se trouve donc jamais en ram
[^]Re: TCPA "remote atetstation" et obscurité
En effet, je suppose que la puce propose de générer une clef de manière plus sécurisée, sinon, je ne vois pas bien son interêt.
Le "remote attestation" est sa seule nouveauté en effet. Des fonctions de cryptographie intégrées au proc ou à la carte mère existent depuis longtemps, cf VIA.
Pour ce qui est de la sécurité , les générateurs de nombres aléatoires hardware sont potentiellemnt meilleurs que /dev/random.
Le problèmes de tous ces trucs en hardware c'est la sécurité par l'obscurité (faut avoir confiance pour croire qu'il n'y a ni bug ni backdoor dedans) et l'absence de mise à jour pour tenir compte des exploits et des progrès en cryptanalyse.
[^]Re: TCPA "remote atetstation" et obscurité
Le truc aussi, c'est que ces systèmes n'implémentent pas tous les algorithmes.
Des outils comme le PadLock de VIA accélèrent certaines fonctionnalités, mais les clefs passent en ram et une partie des traitements doit être effectuée par le cpu.
Par contre, question accélération, le padlock accompagné d'un "bête" VIA eden à 1ghz écrase par un facteur ~16 un P4 2,4ghz pour l'AES-256.
[^]Re: TCPA
Ca marche de la même manière pour une puce : suivant les fonctions activées dans la puce de cryptage, la consommation de courant ne sera pas la même.
Par ailleurs, il faudra toujours entrer le mot de passe (par exemple au clavier), il y a donc des failles de sécurité beaucoup plus accessibles aux pirates que de faire de la cryptanalyse.
Pour moi, ce n'est pas une menace qui mérite que les citoyens abandonnent leur liberté pour TPA-Palladium.
-- Front de Libération des Sources --
Pour stopper les trolls, citons les sources !