• [^] # Re: et oui les TPM ...

    Posté par . En réponse à la dépêche Sortie de Linux 2.6.12. Évalué à 4.

    A tu une preuve partielle de la sécurité de ta carte bleu ?

    Tu ne peux essayer de brutalforcer une une clé coder que si tu as la clé a disposition, hors avec TCPA la clé est bien cachés dans sa puce, et vue que la durée entre deux essais infructueux est protégés le brutal force est inéfficasse face a ce systéme.

    Le mot de passe administrateur de la puce est défini par le propriétaire, il est tous a fait possible de le modifier. C'est d'ailler de mon point de vue le seul point faible du systéme, ce type d'opération devrait n'être entreprise par l'utilisateur qu'a partir d'un systéme de confiance ( boot a partir d'un CD ), pour être sur que son systéme n'est pas logger. Il y a bien évidament une protection hardware de disponible mais c'est cette dernières qui faire peure a beaucoup, c'est celle basé sur le transitonnal trust, CAD, la séquence de boot dont l'intégrité est vérifié par la puce. En gros tu par exemple défini dans ta puce que le mot de passe admin ne pouvait être modifié que si, la machine avait bien le même BIOS, le même bootloader et booté sur le même kernel afin d'être sur qu'il n'y a personne pour écouter le pass admin entre la prise de ton clavier de ta carte mère et la puce. Cette fonction n'est pas obligatoir et comme je l'ai dit plus haut on peut très bien le configurer pour un CD-ROM ( je pense même que c'est la solution la plus simple dans le cas d'un OS open source de geek, qui par définition fluctue pas mal ).

    Donc pour résumé, tu peux changer le passe, des protections existe mais ne sont pas obligatoire, configurer la puce pour que le passe ne puisse étre changer que dans le cas d'un boot a partir d'un CD prévue pour semble étre une bonne solution. ( Dans tous les cas il faut bien évidement l'ancien mot de passe admin pour pouvoir modifier le dernier. )

    Le problème du One time pad est identique a celui du crytpo loopback, les clés se baladeront en mémoire a un moment ou un autre, alors que TCPA est prévue pour que même un espion coder dans le Bios ne puisse pas les interceptés. TCPA est un systéme beaucoup plus résistant ( apres il est evident qu'un telle niveau de sécurité n'est pas nécessaire pour tous le monde, mais il ne faut pas oublier que TCPA a été consut avant tous pour les professionnel ).

    Ce n'est pas une boite noire ou de l'ofuscation, c'est un module de sécurité comparable a toutes les cartes a puces, que ce soit pour de carte de payement, de téléphone, TV satélite ou autre. TCPA a même l'énorme aventage d'étre standardisé documenté et implémentable librement.

    Il y a forcémenet un moment ou elles sont en clairs . rien ne l'ui empeche d'avoir une puce qui se fait passer pour uen puce tcpa et qui est en réalité juste une grosse bd qui les stockent en clair...

    Tu pense sérieusement que deux puces spécialisé dans la cryptographie ne sont pas fichue d'établir un canal crypté avec authentification forte pour transférer les clés ? C'est d'alleur la grosse limitation des emulateurs TCPA, comme ils ne peuvent pas prouver qu'ils sont de réel puce TCPA ils ne peuvent pas récupérer les clés d'une puce TCPA.

    Pour le fait que ce ne soit pas "utilisable" pour palladium ou autre, je suis desole mais c'est toi qui le dis, tant qu'on ne sait pas ce qu'il y a reelement dans la boite , je ne leur ferait pas confiance .

    Palladium repose sur la technologie LaGrande, qui est fondamentalement différente de TCPA, LaGrande est un systéme de cryptage a la volé de la RAM, afint d'établir des canaux sécurisé au saint même de la machine, l'un des utilisation de telles canaux c'est le DRM ( plus de contenue en claire dans la ram, ou même vers la carte son ). Alors que TCPA ne s'occupe que de la protection des clés, et de la vérification de l'intégrité du systéme.