• [^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !

    Posté par . En réponse à la dépêche TCPA/Palladium continuent d'avancer. Évalué à 2.

    C'est justement parceque les gens qui peuvent se servir de ce type de systeme ne sont pas forcement mes amis que je suis content que celui-ci soit surveille et controlle. J''ai du mal a te suivre la. En plus si il y a bien un truc que TCPA ne peut pas faire c'est bien d'identifier un OS, il peut identifier la sequence d'initialisation du boot loader, ce qui est genial parceque celle ci depend du type de disque (IDE, SCSI, Firewire, disquette, cdrom) du systeme de fichier, de la taille du disque et du modele du lecteur. La base de donnees qu'il faudrait a partir du checksums pour reconnaitre l'OS sur le point de booter est absolument monstrueuse. Quand a ce checksum cf plus bas

    1 TCPA ne fourni jamais les checksums ! Il fournit une clef publique basee sur le checksum dans une certaine mesure. Impossible donc a moins d'avoir une connaissance parfaite du contenu de la puce de retrouver le checksum. Sauf dans le cas hyper particulier de l'identifiant on se retrouvera a chaque fois avec un facteur aleatoire qui viendra mettre le bazar. Seul la generation en parallele de clefs privees rigoureusement identiques permet de casser ce facteur aleatoire et d'avoir acces aux donnees decryptes. De plus meme les clefs basees sur un hashage d'authentification seront toutes impactes par l'ensemble ID fabriquant/Nombre Aleatoire dans le cas de demandes de checksums authentifies. Et donc pour obtenir le checksum il faut avant tout posseder les deux autres infos et je dit bien posseder car la puce ne les laissera sortir que si il y a une operation physique effectuee par le fabriquant sur la puce elle-meme. En ce qui concerne laisser sortir une info seule de la puce c'est absurde, tous les hashages sont identiques d'une puce a l'autre mais les clefs publiques et les clefs privees qui en resultent (et qui sont les seules a sortir de la puce "facilement") sont impactes par un facteur aleatoire. Si ce facteur est regenere a chaque fois (ce qui est le cas pour toutes les operation sauf authentification certifie par une tierce personne) il est impossible de casser la clef publique (a moins de pouvoir aller lire le facteur aleatoire sur la puce ou d'avoir beaucoup de temps a perdre).
    Deux hashages successifs des memes parametres de la meme sequence de boot donneront deux clefs privees differents.

    2. Eh bien premierement le fait que ce soit techniquement une architecture fermee qui ne fonctionne que par challenge-response. Il faudrait donc que l'emulateur logiciel soit capable d'emuler parfaitement le comportement d'une puce TCPA pour pouvoir donner des reponses coherentes aux differents challenges, or la puce TCPA a ete construite pour rendre ce genre de chose tres difficile. Deuxiemement uen fois de plus on obtient pas le checksum mais une clef publique. Impossible donc de juste recuperer un a un tous les checksums possibles et de faire des melanges. On peut eventuellement essayer de s'amuser a generer toutes les clefs privees possibles liees a un checksum donnees et puis les essayer une a une sur la clef publique renvoye par l'utilisateur, apres tout il n'y en a que quelques millions. A mon sens recreer une puce TCPA avec le meme coupe ID Fournisseur/NA est quand meme beaucoup plus rapide.

    Pour finir je ne vois pas ce que les softs viennent faire la dedans. TCPA est totalement incapables de faire le checksum d'un ou plusieurs softs.


    Kha