INFO 1 : cette clé unique est pire qu'un simple numéro unique (retiré par Intel de ses processeurs, après des appels au boycott), car elle ne peut pas être contrefaite
Un peu à l'image des adresses MAC, identifiant de manière unique un hôte sur le réseau : je ne trouve pas cela plus choquant que ça... Est-ce pour se réserver l'anonymat <=> immunité ? Un jour ou l'autre, l'utilisation de cette clé sera exigée par les softs DRM ...
Il ne s'agit ici que de l'emploi, via l'OS, qui peut/pourrait en être fait pas d'une capacité intrinsèque de la puce... En outre, la possibilité offerte de restreindre l'accès au seul "propriétaire" (i.e ordinateur) peut être souhaité par ce dernier : à voir donc comme une fonctionnalité offerte (?)
INFO 2 : être confrontés à des fichiers (documents ou programmes) encryptés sous Windows et inutilisables sous Linux...
Là encore il s'agit de l'utilisation qui pourrait en être faite, rien de plus... En outre, il arrive un moment où il faut choisir : si on passe son temps à "taper" sur Windows, il est difficillement défendable de dual-boot"er" sur cet OS...
Enfin, à supposer que ce cauchemard se réalise, ne pouvoir relire/modifier un document qu'exclusivement sur l'ordinateur et l'OS d'origine, c'est tout simplement la mort de la communication au moyen de l'outil informatique : soyons réalistes...
NDLR : personnellement, je suis un des utilisateurs de dual-boot
Notons aussi que des outils libres comme tripwire permettent de s'assurer en bootant à partir d'une disquette ou d'un CD-rom qu'un OS n'a pas été modifié par un virus ou par un cracker ...
Je doute que l'utilisation de tels logiciels soit effective pour des données personnelles.
INFO 3 : impossibilité de contrôler le code qui est dans les puces TCPA
D'accord sur le fond, mais : Des chevaux de Troie ou des failles pourraient être introduites dans ces puces sans que les utilisateurs le sachent.
...pas plus qu'avec des exploits potentiellement non connues et/ou non publiées par l'éditeur d'un logiciel (surtout propriétaires car, ici, le problème est de cet ordre propriétaire/libre).
Quant à il n'est pas prévu dans les specs de pouvoir changer ces algorithmes si une nouvelle faille est trouvée
Je ne pense pas que cela soit dans l'intérêt du constructeur. Si l'un ne l'autorise pas, d'autres proposeront la mise à jour de la puce. (ou peut-être suis-je naïf ?)
Aucun des algorithmes de cryptage utilisés dans les specs TCPA n'a été démontré comme étant incassable (par une preuve mathématique)...
Existe-t-il un algorithme incassable ? j'en doute...
INFO 4 : TCPA inclut un mode "extend" qui permet de s'assurer que seul un OS signé pourra être booté
Sur ce point, il est vrai que l'aveu implicite est pathétique et constitue une négation de nos droits élémentaires. De plus, cette fonctionnalité est déjà remplie par le BIOS / Firmware / Hardware sur les solutions actuelles.
INFO 5 :
Pas compris les * conséquences : OS non signés / extend abandonné / ...
INFO 6 : roots of trust ce qui est somme toute la pierre angulaire de cette technologie : est-ce surprenant ?
Quant à l'activation framework de Windows XP, même si ce procédé est gênant pour une majorité de non-détenteurs de licences Windows mais utilisateurs tout de même, ce n'est jamais qu'un moyen pour l'éditeur de faire respecter son droits. Que l'on soit d'accord ou pas ne change rien sur le fond : l'éditeur (en l'occurence Windows) est dans son droit, l'utilisateur sans licensenon.
Bref, au moins pour toutes les raisons ci-dessus, je refuse fortement d'avoir des puces ou des softs TCPA ...
Au moins il existe des plate-formes alternatives et pour le numéro unique, un conseil, débranche ta carte réseau.
En résumé, je trouve cet article intéressant sur bien des points mais l'aspect critique est trop souvent ignoré au profit de certains amalgames qui ne servent aucunement le sujet.
# Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Quzqo . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 3.
cette clé unique est pire qu'un simple numéro unique (retiré par Intel de ses processeurs, après des appels au boycott), car elle ne peut pas être contrefaite
Un peu à l'image des adresses MAC, identifiant de manière unique un hôte sur le réseau : je ne trouve pas cela plus choquant que ça... Est-ce pour se réserver l'anonymat <=> immunité ?
Un jour ou l'autre, l'utilisation de cette clé sera exigée par les softs DRM ...
Il ne s'agit ici que de l'emploi, via l'OS, qui peut/pourrait en être fait pas d'une capacité intrinsèque de la puce... En outre, la possibilité offerte de restreindre l'accès au seul "propriétaire" (i.e ordinateur) peut être souhaité par ce dernier : à voir donc comme une fonctionnalité offerte (?)
INFO 2 :
être confrontés à des fichiers (documents ou programmes) encryptés sous Windows et inutilisables sous Linux...
Là encore il s'agit de l'utilisation qui pourrait en être faite, rien de plus... En outre, il arrive un moment où il faut choisir : si on passe son temps à "taper" sur Windows, il est difficillement défendable de dual-boot"er" sur cet OS...
Enfin, à supposer que ce cauchemard se réalise, ne pouvoir relire/modifier un document qu'exclusivement sur l'ordinateur et l'OS d'origine, c'est tout simplement la mort de la communication au moyen de l'outil informatique : soyons réalistes...
NDLR : personnellement, je suis un des utilisateurs de dual-boot
Notons aussi que des outils libres comme tripwire permettent de s'assurer en bootant à partir d'une disquette ou d'un CD-rom qu'un OS n'a pas été modifié par un virus ou par un cracker ...
Je doute que l'utilisation de tels logiciels soit effective pour des données personnelles.
INFO 3 :
impossibilité de contrôler le code qui est dans les puces TCPA
D'accord sur le fond, mais :
Des chevaux de Troie ou des failles pourraient être introduites dans ces puces sans que les utilisateurs le sachent.
...pas plus qu'avec des exploits potentiellement non connues et/ou non publiées par l'éditeur d'un logiciel (surtout propriétaires car, ici, le problème est de cet ordre propriétaire/libre).
Quant à il n'est pas prévu dans les specs de pouvoir changer ces algorithmes si une nouvelle faille est trouvée
Je ne pense pas que cela soit dans l'intérêt du constructeur. Si l'un ne l'autorise pas, d'autres proposeront la mise à jour de la puce. (ou peut-être suis-je naïf ?)
Aucun des algorithmes de cryptage utilisés dans les specs TCPA n'a été démontré comme étant incassable (par une preuve mathématique)...
Existe-t-il un algorithme incassable ? j'en doute...
INFO 4 :
TCPA inclut un mode "extend" qui permet de s'assurer que seul un OS signé pourra être booté
Sur ce point, il est vrai que l'aveu implicite est pathétique et constitue une négation de nos droits élémentaires. De plus, cette fonctionnalité est déjà remplie par le BIOS / Firmware / Hardware sur les solutions actuelles.
INFO 5 :
Pas compris les * conséquences : OS non signés / extend abandonné / ...
INFO 6 :
roots of trust ce qui est somme toute la pierre angulaire de cette technologie : est-ce surprenant ?
Quant à l'activation framework de Windows XP, même si ce procédé est gênant pour une majorité de non-détenteurs de licences Windows mais utilisateurs tout de même, ce n'est jamais qu'un moyen pour l'éditeur de faire respecter son droits. Que l'on soit d'accord ou pas ne change rien sur le fond : l'éditeur (en l'occurence Windows) est dans son droit, l'utilisateur sans license non.
Bref, au moins pour toutes les raisons ci-dessus, je refuse fortement d'avoir des puces ou des softs TCPA ...
Au moins il existe des plate-formes alternatives et pour le numéro unique, un conseil, débranche ta carte réseau.
En résumé, je trouve cet article intéressant sur bien des points mais l'aspect critique est trop souvent ignoré au profit de certains amalgames qui ne servent aucunement le sujet.