Articles précédents : Articles
- [60] APRIL, AFUL, et FSF France s'expriment sur le vote européen sur la brevetabilité des logiciels
- [34] Linux sur EuroNews
- [37] Les Ig Nobels 2003 sont arrivés !
- [4] Le Blender Clan : site communautaire francophone
- [78] ICANN vs. Verisign ?
- [3] Les trophées des Casablanca Linux Days
- [19] L'administration du Massachusetts passe sous Linux.
- [20] Xen : un VMWare-like libre?
- [36] Vers une convergence de la syntaxe Wiki ?
- [55] Brevets logiciels : la commission JURI devra maintenant se défendre
Liens connexes
- Article sur Zdnet (3304 hits)
- FAQ TCPA/Palladium (5112 hits)
- DLFP : « Premier BIOS TCPA/Palladium » (4843 hits)
Dépêche modérée par
Articles : TCPA/Palladium continuent d'avancer
Posté par Quetzalcoatl (). Modéré le 06 octobre 2003.
Ceci est un nouveau pas vers l'arrivé massive des technologies NGSCB (ex Palladium) et TCPA dans nos foyer.
Rappelons que TCPA/Palladium permettra, entre autres, aux grosses entreprises (Microsoft en tête) de contrôler les données que vous avez sur votre PC.
NdM : C'est American Megatrends qui était le premier à s'être illustré avec son BIOS TCPA
![[en]](../../../images/en.png)
Article sur Zdnet (3304 hits)![[fr]](../../../images/fr.png)
FAQ TCPA/Palladium (5112 hits)-
DLFP : « Premier BIOS TCPA/Palladium » (4843 hits)
> Lire la dépêche (193 commentaires, moyenne: 1,7).
Re: TCPA/Palladium continuent d'avancer
Selon Phoenix, la fonction serait desactivable par le constructeur. Mais on n'en sait pas plus, genre si meme desactivee la puce ne fournit pas des informations sur le systeme (sans toutefois bloquer des processus)
A coup sur, si on en parle aux personnes non sensibilisees au probleme, on aura droit au traditionnel 't parano !!!'
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Dais Starry () le 06/10/2003 à 21:17. (lien). Évalué à 10.Tu sais, il faut d'abord se prendre un grand coup de poing dans la face pour se rendre compte que çà fait VRAIMENT mal .. là il faudra bien que des co**eries vraiment graves arrivent avant que les gens se réveillent et agissent .. alors qu'il serait tellement mieux de PRÉVENIR ces problèmes ..
--
*~*~* Buddhism Power *~*~*-
[+] [^]Re: TCPA/Palladium continuent d'avancer
Posté par Dais Starry () le 06/10/2003 à 22:49. (lien). Évalué à -5.o_O Pourquoi on me moinsse ? Je pense pas avoir dit de stupidité, que je sache ..
--
*~*~* Buddhism Power *~*~*-
[+] [^]Re: TCPA/Palladium continuent d'avancer
Posté par Tennis Prono (page perso, ) le 07/10/2003 à 07:12. (lien). Évalué à -4.Il faut dire des choses *vraiment* consensuelles
--
Pas de bureau 3d libre sans drivers libres!
-
-
Re: TCPA/Palladium continuent d'avancer
il nous reste plus que award comme bios non pollué ?
yavait pas un projet freeBIOS qui éxistait ?
-
[^]
Posté par Francois Revol (page perso, ) le 06/10/2003 à 20:48. (lien). Évalué à 11.y a OpenBIOS:
http://www.gnu.org/directory/Software_development/Programs_for_smal(...)
Mais aussi LinuxBIOS, qui se base carément sur nunux:
http://www.linuxbios.org/(...)
Re: TCPA/Palladium continuent d'avancer
Je vais reprendre ce que j'ai déjà dit ailleurs.
[fiction]
"Ne vous en faites pas ! Ces cartes mères sont équipé d'une puce, mais on peut la désactiver" - vrai
Et quelques temps plus tard, quand le stock de PC a été renouvellé et que tout le monde dispose de la puce en question dans son PC, on voit sortir une série de logiciel "qui nécéssite l'activation des capacités DMCA de la carte mère"
Et là, la majorité des utilisateur endormis auront oublié les arguments qu'ils scandaient quelques mois plus tôt, la puce est devenu familière et innoffensive ("elle est la depuis des mois, et on a pas eu de problèmes")
Je sens que l'on va se faire avoir, lentement mais surement...
-
[^]Re: TCPA/Palladium continuent d'avancer
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par rouby () le 06/10/2003 à 21:47. (lien). Évalué à 5.Ca sera peut-être encore plus expéditif.
SI la désactivation de la puce se fait par le BIOS, rien de plus facile pour l'OS de la réactiver à la volée sans en avertir l'utilisateur....-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Aurélien Girard () le 07/10/2003 à 07:23. (lien). Évalué à 2.Ou est le problème ?
Mauvais OS (qui fait des saloperies dans ton dos), changer d'OS !-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Pierre () le 07/10/2003 à 08:13. (lien). Évalué à 3.Oui, le changer....!
Mais par quoi!
Si Windaube est le seul qui puisse s'installer sur ta bécane, t'es fichu !-
[^]identification OS par tcpa/tcg
Posté par free2.org (page perso, ) le 07/10/2003 à 09:30. (lien). Évalué à 7.La discrimination anti-linux sera peut-être encore plus subtile:
les fournisseurs de contenus (et peut-être certains FAI) et les serveurs d'autorisation MS (ceux qui délivrent le droit de décrypter les documents encryptés Office 2003) refuseront de t'envoyer des documents si ton OS n'est pas un OS certifié DRM et sans modification.
Tcg/tcpa et certains bios permettent en effet d'enregistrer au moment du boot un checksum de l'OS qui est booté sur ton ordi (l'OS loader pour être précis), puis de l'envoyer accompagné d'une signature prouvant que c'est bien le bios ou tcg/tcpa qui a envoyé ce checksum à la demande du fournisseur de contenu.
Même système pour connaitre exactement les matériels qui composent ton ordinateur (la plupart des fabriquants ont annoncé des matériels compatibles tcpa/tcg)
Impossible alors de mentir à un fournisseur de contenu sur l'OS et le matériel qu'on utilise !
Un grand nombre de documents et de services ne seront plus accessibles aux utilisateurs de Linux, avec les conséquences qu'on imagine pour cet OS. Et les utilisateurs de Windows se retrouveront avec des documents visibles une seule fois par un PC précis (ayant un matériel certifié TCG qui interdit toute copie numérique sans perte) et qui expirent en quelques heures...
Afin de prévenir ce scénario, je refuse donc dès aujourd'hui d'utiliser des softs ou matériels compatibles tcg/tcpa !-
[^]Re: identification OS par tcpa/tcg
Posté par yaya (page perso, ) le 07/10/2003 à 10:59. (lien). Évalué à 1.juste une petite remarque :
tant que les périphériques de connection à internet ne sont pas controlé par TCPA, on peut toujours émuler de manière logicielle une apparence de windows sur internet.
Bien entendu c'est limite légal...
Et ça va demander un bon coup de reverse engeenering.
Mais bon, l'informatique alternative a déjà accompli des prouesses autrement plus spectaculaires...-
[^]Re: identification OS par tcpa/tcg
Posté par Toufou (page perso, ) le 07/10/2003 à 11:35. (lien). Évalué à 2.tant que les périphériques de connection à internet ne sont pas controlé par TCPA
Moi c'est ça qui me fait peur, plus encore que les gestionnaires de contenu qui imposent du TCPA. Si les FAI imposent du TCPA, il va falloir trouver d'autres moyens de communication que le net actuel.
-
[^]algo identification OS par tcpa/tcg même sans modem spécial !
Posté par free2.org (page perso, ) le 07/10/2003 à 11:40. (lien). Évalué à 3.tant que les périphériques de connection à internet ne sont pas controlé par TCPA, on peut toujours émuler de manière logicielle une apparence de windows sur internet.
non car voici l'algorithme utilisé par un fournisseur de contenus TCPA/TCG:
- le fournisseur génère, mémorise puis envoit un nombre aléatoire au client
- le client demande à la puce TCG de signer (avec une clé privée spécifique à TCG non accessible en dehors de la puce TCG) le checksum du boot OS loader et le nombre aléatoire envoyé par le fournisseur
- le client envoit au fournisseur ces données signées officiellement par la clé TCG
- le fournisseur utilise une clé publique TCG pour s'assurer que c'est bien la puce TCG qui a signé ces données
c'est à mon avis inviolable à moins de connaitre la clé privée ou de casser l'algo d'encryption assymétrique utilisé (bref c'est pas pour tout de suite)
-
[^]Re: identification OS par tcpa/tcg
Posté par Matthieu Moy (page perso, ) le 07/10/2003 à 11:49. (lien). Évalué à 3.> on peut toujours émuler de manière logicielle une apparence de windows sur internet.
Tu oublies que TCPA/NGSCB sont basés sur de la crypto.
Exemple de protocol :
A: Bonjour, qui est tu ?
B: Je suis B.
A: Quel système d'exploitation est-tu ?
B: Je suis windows.
A: Ah oui, et bien renvoies-moi la chaine "qKSnseRmnsdrJSERH" signée avec la clé secrête.
B: Euuhhhh, ...
Autre exemple de protocole :
A: Bonjour, qui est tu ?
B: Je suis B.
A: Quel système d'exploitation est-tu ?
B: Je suis windows.
A: Parfait. Voici le fichier demandé, sous forme crypté. Utilise la clé secrête contenue dans ta puce TCPA pour le décrypter :
KDJAfdFkjerSALSekrjslekrj
KSErjel;sDFasdSEKrleksanNER
[ ... ]
B: Merci, :'-(
-
[^]Re: identification OS par tcpa/tcg
Posté par Bernard Hugueney () le 09/10/2003 à 10:42. (lien). Évalué à 1.Et la crypto ça sert à quoi ?
Tu fais du reverse engineering pour trouver des clés privées ?
Faut arrêter de croire qu'on peut toujours contourner une protection technique par un moyen technique. Dans la "course aux armements" en crypto, l'avantage (heureusement !) est au chiffrement.
S'il y a une clé privée dans un chip accessible seulement par un bios certifié : game over :-(
-
-
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par ASpirit () le 07/10/2003 à 09:41. (lien). Évalué à 0.Euh... si ya que Fenêtres qui tourne sur ma machine... je laisse tomber la machine ! On passera tous sur des MAC et on sera heureux !
Oui bon si les MAC ont les mêmes problèmes faudra attendre les nouvelles structures libre... (et tant pis si c'est cher et pas puissant, au moins ce sera libre !).
<pseudo-connerie>
Yavait un utilisateur qui avait posté un lien vers une console qu'on pouvait construire soi-même... c'est donc faisable (ça peut servir de mini calculateur. Ainsi si on en met plein plein plein plein les uns à coté des autres, on aura une machine qui tient la route !
</pseudo-connerie>-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Bruce Le Nain (Jabber id, page perso, ) le 19/04/2004 à 15:45. (lien). Évalué à 1.IBM n'a pas libéré la méthode de construction de ses procs ?
-
-
-
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Matthieu Moy (page perso, ) le 07/10/2003 à 11:49. (lien). Évalué à 2.Encore une fois, TCPA/Palladium ne sont que des fonctionalités en plus. Le fait qu'ils soient activés pour toi n'enlève rien à ta machine (enfin, il sera probablement possible à terme de n'autoriser l'installation que des applications signées, comme on peut déjà le faire pour les .rpm et les .deb, mais ça, ça restera toujours une option.).
C'est comme le fait d'avoir un MSIE sur ta machine, ça ne t'enlève rien et ça te permet toujours d'utiliser Mozilla. Le problème, c'est quand les autres ont MSIE et que les fournisseurs de contenu (ici, les webmasters) développent des choses uniquement compatible avec un outil différent du tien.
Ici, c'est pire, puisque non seulement les LL ne pourront plus accéder au contenu, mais en plus, il sera impossible de créer un logiciel qui y accède (Alors qu'il est possible de développer un navigateur MSIE compatible).
J'en ai rien à fouttre d'avoir une puce TCPA activée sur ma machine. Ce qui me pose problème, c'est que ca devienne indispensable.
-
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par iamkdo () le 06/10/2003 à 23:55. (lien). Évalué à 4.Je ne comprend pas ...
Si des logiciels sortent éxigeant l'activation de leur truc, ce ne peut pas ètre un logiciel GPL , et çà n'a peu de chances de concerner Linux par exemple me trompe-je ?
Donc ce serait plutot une bonne nouvelle pour nous puisque cela pourrait amener des utilisateurs vers le monde libre non ?
Moralité vive TCPA/Pallamachin.
Rappel : plus un système se complexifie plus la faille inhérente à cette complexité est destructive.
Que du bon je vous dit!-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Jerome Herman () le 07/10/2003 à 00:19. (lien). Évalué à 16.Meme si en theorie tu n'as pas tort, en pratique ca risque de s'averer devastateur (pour le cote Palladium).
Je m'explique : dans un monde dans lequel 1) le marche serait dans un etat sain (ie liberte totale de choix entre plusieurs produits et connaissances de l'ensembe des produits) 2) les acheteurs auraient conscience des risques lies a la divulgation d'information personelle ta theorie deviendrait realite.
Malheureusement avec une ennorme partie du marche deja acquise a Microsoft et des gens persuades que l'on ne peut craindre d'etre fiche que si l'on a quelque chose a se repprocher ca ne marche pas du tout. Le consomateur aura le sentiment de "perdre" quelque chose. Par exemple si les technologies DRM ou la lecture de certains types de doccuments deviennent impossibles sous une alternative alors le consomateur sera frustre.
De plus comme on est en situation de monopole les fournisseurs de service payant necessitant l'utilisation de technologie DRM ne verront pas l'interet de faire d'effort. Il suffit de voir a quel point il est dur de faire changer une page web pour qu'elle devienne lisible par tous les navigatuers lorsque l'on est une minorite. Et encore dans ce cas la on a la norme de notre cote, la mise en place d'une nouvelle page est souvent triviale (rendre un site lisible ne requiert que rarement plus de 1semaine/h) et le service propose par le site reste identique.
Dernier point dans le cas du secure computing (a ne pas confondre avec le trusted de TCPA) on se retrouve dans ce qui s'apelle un trust horizontal. Microsoft controllant la norme (et donc le materiel qui respecte ou non la norme) les logiciels permettant de creer les doccuments de confiance, les logiciels pour les distribuer et les logiciels pour les visualiser. Ce type de trust est le plus dangereux (beaucoup plus qu'un monopole fut-il planetaire) et la loi americaine vise plus particulierement ce genre de situation.
Bref non c'est pas que du bon.
Kha-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par ashram4 () le 07/10/2003 à 05:23. (lien). Évalué à 3.Malheureusement avec une ennorme partie du marche deja acquise a Microsoft et des gens persuades que l'on ne peut craindre d'etre fiche que si l'on a quelque chose a se repprocher ca ne marche pas du tout. Le consomateur aura le sentiment de "perdre" quelque chose. Par exemple si les technologies DRM ou la lecture de certains types de doccuments deviennent impossibles sous une alternative alors le consomateur sera frustre.
je plussoie vigoureusement cette constatation. Le pire c'est que je cotoie tous les jours quelques jeunes ingénieurs qui ne voit pas de problème à être fiché puisque qu'ils n'ont rien à se reprocher (j'excuse l'un d'entre eux il est issue d'une famille de gendarme forcément il est "différent"). Pourtant on travail pour la défense dans une division "guerre electronique" il devrait comprendre que l'information ce n'est pas anodin.-
[^]Re: TCPA/Palladium continuent d'avancer
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par ashram4 () le 07/10/2003 à 18:26. (lien). Évalué à 1.Non EADS S&DE. Par contre la DGA semble le plus gros client du département. On ne bosse pas sur de la crypto (seul la DGA est habilité à le faire) mais sur de l'interception de signaux. Pour le reste je suis stagiaire non habilité donc je ne sais pas.
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Pierre Jarillon (page perso, ) le 07/10/2003 à 22:43. (lien). Évalué à 1.Tiens, je connais bien l'endroit où tu travailles. Il y avait quelques irréductibles partisans de Linux au milieu d'une foule de partisans de Windows. Est-ce que ça bouge maintenant ?
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par ashram4 () le 08/10/2003 à 06:21. (lien). Évalué à 1.Du Linux chez EADS System & Defence Electronics (anciennement Matra System & Information)?
J'ai bien vu une machine sous Linux à l'étage mais jamais personne de l'utilise. Sinon dans les répertoires réseau Windows je suis tombé sur un repertoire Linux avec des programmes qui date de 2001. Le logiciel phare de l'entreprise le SIR tourne sous MS Windows et les éventuelles applications issues de mon projet s'interfaceront avec MS Windows. Donc non je ne vois pas de Linux par chez moi, les gens qui m'entourent ne connaissent pas Linux ("oui mais avec Linux tu ne peux rien faire").
Sinon il y a plusieurs sites pour S&DE ce n'est pas évident que tu connaisses celui où je travail : Vélizy.-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Nicolas Boulay () le 08/10/2003 à 20:56. (lien). Évalué à 1.Tient moi, je bosse à EADS Astrium. Il n'avait rien sous Linux mais rien à prioris contre. Après 1 et demi, 2 ans de lobbying, on vient d'avoir 2 serveurs de calculs qui remplacent des sun, ses machines sont 4 fois plus rapides que nos sun actuelles.
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Bruce Le Nain (Jabber id, page perso, ) le 19/04/2004 à 15:52. (lien). Évalué à 1.Tu connais pas Serge Jadot à Vélizy ? Il est aussi à Matra sysde. Je suis son fils... ;) Et ne dis pas qu'il connait ou n'aime pas Linux, ça fait depuis 97 qu'on n'a que ça à la maison.
Comme quoi, il n'y a pas que des pro-win à EADS
-
-
-
-
-
-
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Matthieu Moy (page perso, ) le 07/10/2003 à 06:26. (lien). Évalué à 5.Ca peut être un logiciel GPL, mais si tu le modifie, il ne marche plus.
Tu pourras rester sous Linux, tu pourras continuer à utiliser des applications non TCPA/Palladium, mais le seul Hic, c'est que tu ne pourras plus accéder au contenu protégé.
Si tu as déjà eu des problèmes pour lire des CD ou DVD protégés sous Linux, et si tu as été tenter de dual-booter (voire migrer) avec un windows pour cette raison, dis-toi juste qu'avec TCPA/Palladium, ça sera pire.
Aujourd'hui, il y a des gens qui ne viennent pas sous Linux parce que "C'est pas bien compatible pour le web" (comprendre : Les sites écrits avec les pieds pour MSIE ne passent pas tous sous Mozilla), "Ca n'est pas pratique pour envoyer des fichiers du traitement de texte" (Comprendre: Il peut arriver d'avoir des problèmes pour lire du word).
Demain, ça sera "Oui, mais sous Linux, on peut pas lire des DVD, on peut pas télécharger des fichiers sur Internet" (Comprendre : Les logiciels libres n'ont pas été signés et n'ont pas accès aux clés crypto qui permettent de les lire.)
T'inquiètes, leur truc est bien pensé, et c'est bien parti pour écraser completement le LL.-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par _alex () le 07/10/2003 à 07:25. (lien). Évalué à 2.Dite si je me trompe :
Lorsqu'on est en TCPA/Palladium, on ne peut récupérer des info uniquement d'un serveur TCPA/Palladium ?
Si c'est le cas, comment vont faire toute les boites qui utilise Linux pour X raison ?
Il va falloir acheter Linux certifié par un organisme ?
(je me doute qu' "ils" ont une astuces mais je ne vois pas la comme ça)-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Matthieu Moy (page perso, ) le 07/10/2003 à 11:48. (lien). Évalué à 2.> Dite si je me trompe :
>Lorsqu'on est en TCPA/Palladium, on ne peut récupérer des info uniquement d'un serveur TCPA/Palladium ?
Ca n'est pas tout à fait ça. Enfin, ça sera peut-être possible, mais très certainement marginal.
Par contre, une information protégée par du DRM construit au dessus de TCPA/NGSCB n'est lisible que par une application signée.
Si on n'a pas besoin d'accéder à des information protégées par DRM, pas de problème.
-
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Aurélien Girard () le 07/10/2003 à 07:30. (lien). Évalué à 2.Peut être pas écrasé mais certainement marginalisé.
Si tous les grands fournisseurs de contenus (CD, DVD, etc.) et de contenants (PC, OS, etc) s'allient pour creer un monde fermé, il restera toujours la possibilité d'utiliser des plateformes complètement libres.
Mais ces plateformes seront totalement séparées du monde "DRM" par un nouveau mur infranchissable (légalement) : les lois qui interdisent l'interopérabilité (DMCA, EUCD, etc.).
L'informatique libre a un avenir certain dans les ecteurs professionnels, mais pour le multimédia et les loisirs ça m'a l'air presque foutu :(
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par sedget (page perso, ) le 07/10/2003 à 09:23. (lien). Évalué à 9.Demain, ça sera "Oui, mais sous Linux, on peut pas lire des DVD, on peut pas télécharger des fichiers sur Internet" (Comprendre : Les logiciels libres n'ont pas été signés et n'ont pas accès aux clés crypto qui permettent de les lire.)
Moi aussi j'ai longtemps pensé comme ceci, maintenant j'ai une vision un poil différente, a savoir que pour lire les dvd, pour jouer et écouter de la zik avec le futur tcpa/micro$ il va falloir tout acheter.
Hors je ne pense pas que les utilisateurs actuel de micro$ achètent beaucoup de softs qu'ils utilisent. c'est un élement de base de micro$ l'utilisation de logiciel piratés. c'est d'ailleurs ce qui a permis l'explosion de l'utilisation de ce fameux système.
si dans deux ans on peut plus jouer a doom 8 pour pas un rond ca va gueler dans les chaumières. ce qu'il nous faut espérer c'est que comme déja dit sur DLFP, ce système soit trés sécurisé et inviolable, que tout le monde soit vraiment obligé de payer. la ca sera vraiment bonnard pour nous :o)
car en fait quand je discute avec des utilisateurs m$ , il disent que pour eux les soft sont gratuits, même quand on tente de leur expliquer que gratuit!=piraté/piratable. combien de gens utilisent photoshop à la place de gimp, cuteftp à la place de filezilla... on a beau leur dire que "c'est mal" que justement il existe des alternatives avec des soft aussi puissants, libres et gratuits, ben ils s'en foutent car les autres sont aussi gratuits pour eux.
Mais effectivement comme dit plus haut quand on parle de ce projet a des simples utilisateurs d'un PC qui se moquent de savoir comment fonctionne un ordi (etc ..) ben ca les faits rire, j'ai souvent eu la remarque ouaip bigbrother on connais ca fait 20 ans kon en parle ....
certains commence a s'en rendre compte, mais linux à aussi un gros défaut. c'est celui d'avoir été médiatisé comme un système fait par et pour des fous de l'info. C'est a mon avis contre cette légende qu'il faut se battre... montrer à nos amis collègues que c'est possible-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par nayco (page perso, ) le 07/10/2003 à 10:47. (lien). Évalué à 3.Je suis parfaitement d'accord avec ce post... Malheureusement, je ne sais pas plussoyer, certainement je n'ai pas assez d'XPs ;-)
En effet, dans ma démarcher "évangéliste" auprès de mes proches, je me heurte au fait que "Linux n'apporte rien, Windows aussi est gratuit, et en plus Linux c'est pour les informaticiens, et pis on peu pas faire tout comme sous Windows, et pis y'a pas de jeux, pis on peu pas faire du Word, pis........"
Allez donc leur expliquer que :
- Windows n'est pas gratuit, et que l'utiliser c'est s'enfermer
- Installer une distrib genre Mdk (Pas de troll svp) c'est aussi simple que d'installer Windows (Ceusses qui se sont galèré à installer un winmodem sous Win9X à l'époque vont me comprendre, et j'en passe), c'est donc un système à large audience, tout le monde peut y trouver son compte gratuitement
- Sous Linux, on peut surfer sur le web, éditer des documents, faire de l'instant messenging, de la visio, du jeu en réseau (Bon, ok, a part Ennemy Territory, c'est peu evident), lire ses mails, organiser son emploi du temps, etc..., etc... ("Oui mais pour toi c'est facile, t'es informaticien")
- Des jeux, il y en a, mais je suis d'accord, c'est pas encore suffisant, malgré les initiatives de certains comme IdSoftware, je me fais toujours rire au nez quand je montre Gtali ou Ksirtet ("Ouais, l'autre, il est sous Win3.1 !!!")
- Notez bien le "Faire du Word" : NON, monsieur, on ne fait pas du Word, on utilise un traitement de texte, c'est pas pareil !!!!
- ...
Il faut encore et toujours plus communiquer sur le sérieux des Logiciels Libre, car on traine une réputation....
On devrait y arriver à terme, il n'y a pas de raison : Depuis 12 ans que je m'intéresse (Et que je fais, maintenant) à l'informatique, j'entends, je lis partout "MS c'est merdique, monopole, bugs, marche pas, perdu document, gnagnagna, etc..." Et malgré tout, les gens continuent à utiliser les logiciels MS. Si un tel sado-masochisme est possible, alors le Libre ne devrait pas avoir à rentrer dans les moeurs, même avec des défauts, non ?-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par MsK` () le 07/10/2003 à 11:31. (lien). Évalué à 1.Sous linux : Quake 3, neverwinter nights, Enemy Territory, Counter-Strike ( deja testé et sa passe mais bon un poil foireux, faudrait tester en lan ), etc... ( avec wine on peut aller loin :)
Par contre, en ce qui concerne gimp est aussi puissant que photoshop j'insiste pour dire un jour peut-etre mais pour l'instant on est quand meme loin ... ( www.73lab.com est la preuve que c'est puissant gimp, mais pour le web, faire de l'impression avec gimp bonjour ... )--
\_o<~~~~-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Fulgrim () le 07/10/2003 à 15:48. (lien). Évalué à 1.Wine, c'est pas une solution pour un non informaticien si je peux me permettre. Ses jeux tourneront moins bien, grosse galère souvent à l'installation
Gimp est à mon avis largement assez puissant pour n'importe quel utilisateur "du dimanche", sérieusement, vous connaissez beaucoup de monde qui utilise toutes les fonctions de photoshop ? Moi les seuls que je connais potentiellement, sont des pros et ont acheté leur licence-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Matthieu Moy (page perso, ) le 07/10/2003 à 20:46. (lien). Évalué à 1.L'utilisateur du dimanche, il est bien incapable d'aller chercher dans les méandres des menus de Gimp :-(
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Pierre Jarillon (page perso, ) le 07/10/2003 à 22:48. (lien). Évalué à 1.Combien de personnes savent utiliser script-Fu ? C'est pourtant très puissant !
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par stinger750 () le 06/11/2003 à 15:40. (lien). Évalué à 1.Kler !!!
j'ai mieux pigé comment fabriquer des effets avec un soft de traitement d'image qu depuis que j'utilise ZE Gimp, depuis j'ai fait exit m$ et son Winchôse ( ou windaube comme on veut ), et je suis passé sur Debian ! Na !
En fait il suffit de s'interesser a ce qu'on utilise pour en decouvrir les faces pas si cachée que cela ...
Vive Tux, qu'il est bon de se laisser glisser sur Sa banquise !
-
-
-
-
-
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Matthieu Moy (page perso, ) le 07/10/2003 à 11:48. (lien). Évalué à 1.> pour lire les dvd, pour jouer et écouter de la zik avec le futur tcpa/micro$ il va falloir tout acheter.
Ca n'est pas seulement ça. C'est surtout qu'il va falloir acheter les logiciels pour les lire.
Regarde les CD audio protégés contre la copie. Bon, si l'auteur veut protéger son CD, c'est son problème, mais le mien, c'est que son CD n'est en théorie lisible que par Windows Media Player 9. Ça, c'est intolérable.
Idem pour les DVD cryptés. Penser qu'il a fallu qu'un mec aille en tôle pour qu'on puisse lire des DVD sous Linux, ...
Voir mon commentaire ici pour les détails :
http://linuxfr.org/comments/194547.html(...)-
[+] [^]Re: TCPA/Palladium continuent d'avancer
Posté par Raphaël Gertz (page perso, ) le 08/10/2003 à 04:28. (lien). Évalué à -1.La meilleure solution pour que l'on sorte de cette impasse est que Bill et sa femme meure avant la sortie de ce projet qui veut la mort du LL et que leur boite les suive dans leur tombe de très près...
C'est certe méchant mais sa serait la meilleure solution...
Je tient a dire que les passage a une mandrake est facile, mais que la configuration avancée nécessite de solide connaissance en info (par exemple pour mettre les drivers nvidia(si on ne possède pas la version dvd), virer les services inutiles au démarage, etc...)
Sinon l'utilisation de winex (version payante... :-( ) est extrèmement simple, mais il faut déboursser 15 euros minimum pour avoir acces au rpm... pour que seulement certains jeux marchent... )
Le problème du windows gratuit est que M$ joue la dessus, il sait que des millier de personnes(particuliers) ne payent pas depuis des lustre leur version de windows si ce n'est lors de la "taxe" M$ des OEM...
Si il n'ont plus fait de grande chasse aux pirates comme avec 98/98SE/Me pour 2000pro/XP c'est qu'il pensaient bien que c'étais penne perdue et que palladium sonnerais le glas des versions pirates et de linux au passage qui commence a devenir un sérieux concurent pour eux
cf : les diverses mandrake/Slackware orientées "grand public" de cette année, je ne met pas debian dedan car elle a un sérieux retard (bien plus que sérieux) dans la convivialité de l'installation, de l'utilisation et de la maintenance...
-
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Jeremy Monnet (page perso, ) le 31/05/2004 à 17:20. (lien). Évalué à 1.car en fait quand je discute avec des utilisateurs m$ , il disent que pour eux les soft sont gratuits, même quand on tente de leur expliquer que gratuit!=piraté/piratable. combien de gens utilisent photoshop à la place de gimp, cuteftp à la place de filezilla... on a beau leur dire que "c'est mal" que justement il existe des alternatives avec des soft aussi puissants, libres et gratuits, ben ils s'en foutent car les autres sont aussi gratuits pour eux.
Tout a fait ! J'ai meme un collègue qui a fait une jolie etiquette "Windows XP Open Source" pour coller sur son cd "piraté, winter edition de la mort qui tue". Ceci dit, ce qui l'interesse c'est avant tout de pouvoir faire ce qu'il veut .... Vu qu'il n'avait pas de client ftp, je lui ai installé filezilla justement, et il en est très content (gimp aussi d'ailleurs, et c'était plus rapide que D/L sur emule un photoshop .....
Ensuite quand je lui parle de TCPA et autres .... "oui, mais ca fait des années qu'on parle de cracké des choses, ca se crackera aussi". Il ne veux pas comprendre que ce ne sera pas que du logiciel ....
Bref, meme si c'est critique, ne perdons pas espoir !
-
-
-
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Colin Leroy (page perso, ) le 07/10/2003 à 13:21. (lien). Évalué à 0."capacités DMCA"... TCPA, DMCA, RIAA aussi tant qu'on y est ?
faut faire un peu attention à pas tout amalgamer, ça fait pas très sérieux...
Re: TCPA/Palladium continuent d'avancer
NGSCB est le nouveau nom du coté MS de l'affaire, de l'ancien Palladium et non de TCPA
http://www.microsoft.com/resources/ngscb/default.mspx(...)
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par nayco (page perso, ) le 06/10/2003 à 21:42. (lien). Évalué à 1.Ben quand j'ai vu ça, j'ai fortement eu une impression de manque...
Maintenant, je vais en paix, c'est corrigé : http://nayco.free.fr/palladium_roadB.jpg(...)
=> On pourra remarque que L'image d'origine sur le site de MS (http://www.microsoft.com/resources/ngscb/images/palladium_roadB.jpg(...)) contient le mot "palladium".... L'info a du mal à passer ?
-
[^]Re: TCPA/Palladium continuent d'avancer
Posté par Pierre Jarillon (page perso, ) le 06/10/2003 à 22:07. (lien). Évalué à 8.NGSCB : Cinq consonnes, c'est difficile à prononcer et à s'en souvenir, c'est pour qu'on n'en parle pas ?
Re: TCPA/Palladium continuent d'avancer
Sans vouloir relancer le troll:
Cette news, entretien la confusion:
TCPA/TPM: c'est un de type cofrefort cryptographique, principalement developpé apr IBM et qui existe depuis plusieurs année, avec des specification claire et ouverte, dans le cadre d'un vrais standar.
Palladium/NGSCB: C'est la prochaine generation de systeme de securité, de Microsoft qui n'existe pas est qui sera peut étre en oeuvre dans Longhorn, la prochaine version de windows. A premiére vue ca permet, l'etablissement de monopole, et facilite, le tracage des fichiers avec un systeme de droit trés evolués/restrictif, et cela cible principalement les utilisateurs, pas les fournisseurs de media .
Le Phoenix Bios: C'est un bios qui incorpore les fonctions de DRM déjà presente dans les lecteurs Flash et autres baladeurs WMA, c'est a dire que c'est une puce qui gére les DRM, Windows Media, systeme qui existe aussi depuis quelque temps, cela n'a que trés peut de chose a voir avec TCPA, ou NGSCB. Elle sert principalement a isoler un media vers des materiel et des interfaces "Sur", comprendre un Windows Media Audio ne poura étre lue que sur une carte son, certifié qui certifie que l'on ne puisse pas intercepter les donnés en claire, avent leurs sortie analogique, ou qui reproduit le watermaking ou autre. C'est un technologie qui s'addresse principalement aux fournisseurs de media contrairement a NGSCB.
La FAQ, TCPA/Palladium, est un tissue de connerie comme je l'ai déjà demontré plusieurs fois, et comme ce fut redemontré dans MISC, et oui même Ross Anderson peut dire de grosse connerie, et ce n'est pas avoir la pretention de lui étre superieur dans son domaine que de le remarquer.
Voila, j'ai déjà perdut pas mal d'XP ici avec cette histoire et je suis prés a en perdre encore, si il le faut. Dire n'importe quoi n'est surment pas le bon moyen de lutter contre les abus.
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.
-
[+] [^]Re: TCPA/Palladium continuent d'avancer
Posté par Jerome Herman () le 06/10/2003 à 21:34. (lien). Évalué à -1.Je te soutiens dans ce combat pour eviter l'amalgame. J'ai aussi perdu temps et XPs (que j'ai regagne dans le meme thread donc pas de rpobleme) avec cette confusion.
Par contre
1) tu m'as grille
2) Felicitation pour ta nouvelle orthographe.
Kha-
[^]prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org (page perso, ) le 07/10/2003 à 12:22. (lien). Évalué à 1.alors dites-moi où la faille quand je prouve que la seule fonction de TCPA/TCG qui n'est pas aujourd'hui faisable avec du matériel standard et des softs libres est l'identification à distance du matériel (modèles et numéros de série uniques) et de l'OS et le stockage par cet OS de données qui ne seront pas lisibles par les autres OS de la même machine !
https://linuxfr.org/comments/280430.html(...)
je refuse dès aujourd'hui les softs et matériels TCPA/TCG-
[^]Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par Matthieu Moy (page perso, ) le 07/10/2003 à 14:06. (lien). Évalué à 1.Je peux te donner au moins une autre possiblité.
Tu veux empêcher à tes utilisateurs d'accéder à /etc/shadow.
Tu fais un chmod approprié. OK. Mais là, l'utilisateur, il met le CD de knoppix dans le grille-pain et il reboot. un "mount" et un "cat" plus loin, il a le contenu du fichier. Ensuite, il repart chez lui, et il fait une attaque Brut-force sur ce fichier. Comme la moitié des utilisateurs ont mis le nom de leur copine ou leur date de naissance comme mdp, tu peux facilement t'introduire sur leur compte.
Avec TCPA, tu peux stoquer ce fichier avec une crytpographie forte. Même en rebootant sur une knoppix, et même si tout le monde a mis un mot de passe facile à casser en brut force, il te faudra casser une clé crypto ...
Tiens, sur le même principe, on doit pouvoir faire un gestionnaire de mot de passe sécurisé pour Mozilla. Un truc qui n'accepte de restituer les mots de passe qu'à un mozilla non modifié depuis le moment ou tu les a enregistré.
TCPA/Palladium ont pleins de conséquences néfastes, mais il ne faut pas croire qu'ils ne servent à rien non plus.-
[^]Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org (page perso, ) le 07/10/2003 à 14:48. (lien). Évalué à 1.non car il est possible de faire la meme chose (protéger l'accès à certains fichiers même si un cambrioleur a un accès physique au disque dur) en protégeant ces fichiers/dossiers/partitions par une passphrase qui est demandée lors du boot !
rien n'empeche de crypter /etc ou /etc/passwd de la sorte, voir même le disque ou la partition sur laquelle ils se trouvent !-
[^]meilleure sécurité avec softs de cryptage libres évolutifs qu'avec hardware et specs fixés une fois pour toutes
Posté par free2.org (page perso, ) le 07/10/2003 à 14:56. (lien). Évalué à 1.J'ajoute que si une passphrase est trop petite à ton gout, tu peux en + utiliser d'énormes clés (bien plus grosses que celles de taille fixe qui sont dans la spec tcpa) stockées sur disquette/cdrom/cléUSB, et avec l'algo de cryptage de ton choix (plutot que celui qui est fixé une fois pour toutes dans les specs TCG, ce qui fait qu'il sera peut-être obsolète trop vite pour continuer à protéger des données ultra confidentielles)
-
[^]Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par Matthieu Moy (page perso, ) le 07/10/2003 à 15:05. (lien). Évalué à 1.Deux solutions dans ce cas là :
* Tu n'as pas la passphrase et tu ne peux pas booter
* Tu as la passphrase et tu peux rebooter sur un autre OS.-
[^]Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org (page perso, ) le 07/10/2003 à 15:26. (lien). Évalué à 1.pour être + précis: tu peux avoir sans TCG, et uniquement si tu le désires, des données protégées qui seront accessibles à plusieurs OS, à condition que tu fournisses la passphrase (et/ou une clé sur USB/floppy/cdrom) à chacun de ces OS lors du boot
Alors que TCG prévoit que les données qu'ils protègent (par exemples des fichiers/progarmmes protégés par DRM ou par Office2003 security server) ne seront pas accessibles à des OS différents de celui qui a stocké ces données.
Ni d'ailleurs sur d'autres matériels si ton ordinateur tombe en panne et que tu veux lire les données de ton disque dir sur un autre PC.
Combiné à l'identification à distance de l'OS par TCG, on a une vraie menace pour notre liberté de continuer à utiliser des OS et des matériels que l'on peut controler et modifier !
-
-
-
[^]Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par beb () le 07/10/2003 à 15:35. (lien). Évalué à 1.Avec TCPA, tu peux stoquer ce fichier avec une crytpographie forte. Même en rebootant sur une knoppix, et même si tout le monde a mis un mot de passe facile à casser en brut force, il te faudra casser une clé crypto ...
Je commence à entrevoir la lumière :) Mais (tu me dis si je suis chiant hein :), comment la puce sait qu'elle ne doit pas donner accès aux informations qu'elle contient quand la machine tourne sous Knoppix ? (En supposant que ta knoppix a un noyau qui lui permette d'interagir avec la puce bien sur). C'est que la puce est capable de reconnaître l'OS avec lequel les données ont été rentrées ? dans le cas d'un dual-boot par exemple ça se passe comment ?-
[^]limitations de TCG par rapport aux softs libres
Posté par free2.org (page perso, ) le 07/10/2003 à 16:03. (lien). Évalué à 2.lors du boot de l'OS 1, la puce ou le bios stocke un checksum de l'OS loader
l'OS1 peut alors demander à la puce TCG de générer des clés privées (non dévoilées) associés à des clés publiques (dévoilées) qui ne seront utilisables pour décrypter que si l'OS qui le demande avait lors du boot la même signature que l'OS 1
tout autre OS ne peut donc pas y accéder, ce qui est inquiétant pour les OS alternatifs !
Alors que aujourd'hui, avec des softs libres et sans matos TCG, il est tout à fait possible d'utiliser des algos de crypto mieux considérés + fiables que le RSA de TCG (AES ou des algos symmétriques car pour cet usage précis on a pas besoin de crypto assymétrique) et des clés de taille supérieure ( limitation de taille de l'ordre de 1024 bits dans TCG) pour interdire à quelqu'un de booter sur ta machine et d'accéder à tes données s'il n'a pas ta clé (cela lui interdit aussi d'accéder aux données s'il emporte ton disque dur)-
[^]Re: limitations de TCG par rapport aux softs libres
Posté par Jerome Herman () le 07/10/2003 à 16:50. (lien). Évalué à 2.lors du boot de l'OS 1, la puce ou le bios stocke un checksum de l'OS loader
presque le checksum de l'init de l'OS loader. Bien sur si c'est lilo en multiboot il est bien avance.
tout autre OS ne peut donc pas y accéder, ce qui est inquiétant pour les OS alternatifs !
Pas du tout, ces clefs sont de toute facon migrables vers une autre zone par l'admin de la puce. Si tu as besoin de sortir une clef d'une zone de boot tu peux declencher sa migration soit vers une autre zone de boot soit vers une zone non lie a une sequence de boot. C'est un peu fastidieux mais ca se fait tres bien.
Alors que aujourd'hui, avec des softs libres et sans matos TCG, il est tout à fait possible d'utiliser des algos de crypto mieux considérés + fiables que le RSA de TCG (AES ou des algos symmétriques car pour cet usage précis on a pas besoin de crypto assymétrique) et des clés de taille supérieure ( limitation de taille de l'ordre de 1024 bits dans TCG) pour interdire à quelqu'un de booter sur ta machine et d'accéder à tes données s'il n'a pas ta clé (cela lui interdit aussi d'accéder aux données s'il emporte ton disque dur)
Si il est deja possible de faire meiux et plus fiable de facon logicielle je ne vois pas ce que tu reproches a TCPA. Si ca n'apporte vraiment qu'une protection inferieure a ce qu'il est deja possible de faire logiciellement alors pourquoi es-tu aussi remonte ?
Kha-
[^]Re: limitations de TCG par rapport aux softs libres
Posté par free2.org (page perso, ) le 07/10/2003 à 17:13. (lien). Évalué à 1.Si ca n'apporte vraiment qu'une protection inferieure a ce qu'il est deja possible de faire logiciellement alors pourquoi es-tu aussi remonte ?
justement, il y a anguille sous roche ! explique-moi, en dehors du stockage infalsifiable y compris par moi d'un hash de l'OS loader au moment du boot, ce qu'apporte TCG ?
comme l'a fait remarqué un autre lecteur, tous les avantages au niveau sécurité de cette technologie sont faisables et en mieux par des softs libres !
il n'y a qu'une chose qui est la spécificité de TCG cette identification de l'OS par une puce tierce que je ne peux pas falsifier (alors que je peux identifier l'OS au moment du boot avec tripwire et mon matos actuel !)
si ce n'est pas pour identifier l'OS par un tiers, explique moi à quoi sert TCG alors ?-
[^]Re: limitations de TCG par rapport aux softs libres
Posté par free2.org (page perso, ) le 07/10/2003 à 17:15. (lien). Évalué à 2.ah j'oubliais par rapport à lilo que tu cites: le boot laoder de lilo n'a évidemment pas la meme signature que celui d'un windows non modifié !
-
[^]Re: limitations de TCG par rapport aux softs libres
Posté par Jerome Herman () le 07/10/2003 à 18:11. (lien). Évalué à 1.Et l'os loader NT si je lui rajoute une ligne pour qu'il charge OpenBSD il change de signature aussi ? De toute facon uen fois de plus deux PC identiques n'auront pas le meme Hashage du boot.
Kha-
[^]Re: limitations de TCG par rapport aux softs libres
Posté par free2.org (page perso, ) le 07/10/2003 à 19:01. (lien). Évalué à 1.Sois un peu logique: mais alors que fait TCG que ne peuvent faire des softs libres actuellement ?
pourquoi accepterais-je une puce co-conçue par MS (qui fait partie des fondateurs de TCPA) dans mon ordi si elle ne me sert à rien (il me semble logique que MS compte s'en servir eux ! sinon ils n'auraient pas fondé TCPA)-
[^]chain of trust TCG
Posté par free2.org (page perso, ) le 07/10/2003 à 19:29. (lien). Évalué à 1.en fait je crois que tu n'as pas compris la notion de chain of trust:
TCG hashe le BIOS, qui hashe le premier boot loader (bootloader spécialement écrit pour TCG, c'est ça que tu n'as pas compris je pense) et qui hashe le programme suivant du boot et ainsi de suite jusqu'à l'OS, de façon à pouvoir prouver, hashes à l'appui, que l'OS booté est bien un Windows TCG
hashing is employed to extend trust
from the BIOS to other areas of the
platform, in the following simplified
sequence:
1. The PC is turned-on.
2. The TCPA-compliant "BIOS Boot
Block" and TPM have a "conversa-
tion."This attests that the BIOS can
be trusted.
3. BIOS queries to ensure that user is
authorized to use the platform.
4. The BIOS then has a "conversa-
tion" with the operating system
(OS) loader and the TPM. This
attests that the OS loader can be
trusted.-
[^]PREUVE IRREFUTABLE: document Intel entièrement consacré à l'identification à distance via TCG !
Posté par free2.org (page perso, ) le 07/10/2003 à 22:28. (lien). Évalué à 1.OK j'ajoute que je viens de trouver un document du printemps 2003 d'Intel (membre de TCG) qui explique clairement que chaque composant (component) de l'ordinateur dont un hash est stocké dans le PCR peutr faire l'objet d'une demande d'identification lors de laquelle le hash stocké dans le PCR est communiqué et signé pour qu'il soit infalsifiable
http://www.intel.com/idf/us/spr2003/presentations/S03USSFCS69_OS.pd(...)
ce document parle aussi de consituer une base de donnée de tous les hashs de tous les composants
la preuve est faite: la seule fonction originale de TCG est l'identification à distance par un tiers de chacun des composants (hard et soft) de mon ordinateur
Voilà pourquoi je refuse dès aujourd'hui d'utiliser des softs et du hardware compatibles TCG !-
[^]Re: PREUVE IRREFUTABLE: document Intel entièrement consacré à l'identification à distance via TCG !
Posté par Cédric Blancher (page perso, ) le 08/10/2003 à 09:00. (lien). Évalué à 1.ce document parle aussi de consituer une base de donnée de tous les hashs de tous les composants
Base locale, je n'ai pas vu un slide qui parle d'accès à ses informations par un tiers via le réseau.
la preuve est faite: la seule fonction originale de TCG est l'identification à distance par un tiers de chacun des composants (hard et soft) de mon ordinateur
Rien vu de tout ça dans cette présentation. Tu peux préciser les numéros des slides qu'on aille directement à l'essentiel (que j'ai sûrement dû louper).--
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help m-
[^]Re: PREUVE IRREFUTABLE: document Intel entièrement consacré à l'identification à distance via TCG !
Posté par free2.org (page perso, ) le 08/10/2003 à 09:49. (lien). Évalué à 1.Base locale
non fait un find sur "eco-system" dans le pdf
identification à distance par un tiers de chacun des composants
fait un find sur "component"-
[^]Re: PREUVE IRREFUTABLE: document Intel entièrement consacré à l'identification à distance via TCG !
Posté par Cédric Blancher (page perso, ) le 08/10/2003 à 14:08. (lien). Évalué à 1.base locale
non fait un find sur "eco-system" dans le pdf
Ben justement, quand je regarde l'éco-système, je vois les composants du système TCPA qui sont tous locaux :
. repository, alimenté par des éléments externe
. registrar
. challenger
. TPM
Bref, un ensemble de fonctions implémentées localement qui doivent prendre une décision lorsqu'elle reçoivent des "events". Je n'ai pas vu de flux en sortie.
identification à distance par un tiers de chacun des composants
fait un find sur "component"
Pas vu de "à distance" (remote, remotly, etc.)--
http://sid.rstack.org/
PGP KeyID: 157E98EE FingerPrint: FA62226DA9E72FA8AECAA240008B480E157E98EE
>> Hi! I'm your friendly neighbourhood signature virus.
>> Copy me to your signature file and help m-
[^]attestation que ma platform = mon PC+monOS est non modifié
Posté par free2.org (page perso, ) le 08/10/2003 à 15:58. (lien). Évalué à 3.je crois que tu n'as pas vu que tout le document consiste à pouvoir "attester" (attestation) des composants d'une plate-forme.
"Platform", dans tous les documents TCG, désigne l'ensemble d'un ordinateur, OS + hardware dont le hard tcg, , tu peux consulter sans NDA d'anciennes versions de ces docs sur le site officiel TCG
on voit notamment page 7 que le registrar est externe à la plateforme
page 9 que le challenger (celui qui veut connaitre les composants de la palteforme) est externe à la plateforme
les protocoles cryptographiques utilisés (notamment par signature) font que toutes ces opérations peuvent être faites de manière fiables par internet
page 12 il est précisé que la base de données des hash est destinée au challenger (le fournisseur de services) et non au possesseur de la plateforme (moi)
page 26 on vient bien que le registrar et le challenger sont bien des entités distinctes entre elles et distinctes de la plateforme
évidemment si je me place dans la peau d'un fournisseur de services DRM, je serais particulièrement content de cet état de fait qui me permet de savoir sans falsification possible quel est l'OS et le matériel du client auquel j'envoie un contenu.
par contre pour un usage interne à une entreprise, je peux tout à fait utiliser des logiciels libres pour obtenir une fiabilité supérieure aux algos de cryptage non extensibles utilisés par TCG !
-
-
-
-
-
-
-
-
-
-
-
-
-
-
[^]Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par Jerome Herman () le 07/10/2003 à 14:39. (lien). Évalué à 3.Bon alors je vais te reexpliquer une derniere fois comment fonctionne l'identification a distance de TCPA et pourquoi ca serait une TRES mauvaise idee de pouvoir le faire soit-meme. Par contre tu verras on peut parfaitement le faire en libre.
La puce TCPA contient un emplacement special qui n'est considere ni comme une zone d'archivage privee ni comme une zone d'archivage publique. C'est une zone ID de laquelle la clef ne peut sortir que dans des circonstances extraordinaires (il faut faire venir le constructeur de la machine).
Cette zone contient optionellement (pour l'instant : jamais) une clef fabriquant OU une clef fournisseur. Cette clef et techniquement irrecuperable et elle est la meme sur toute une gamme de produit. Cette zone contient aussi un nombre genere aleatoirement et sauvegarde.
Pour obtenir un certificat d'identification il te faut d'abord une demande de hashage pour savoir ce que tu vas faire rentrer dans ton identifiant (cela peut-etre seulement la clef+le nombre aleatoire mais tu peux aussi rajouter ta carte video, ton bios, ta carte son etc.. )
Le systeme fonctionne comme suit : tu te connecte a un fournisseur de certificat et tu lui envoit la clee publique de ton hashage. Celui-ci se connecte alors a ton fournisseur de contenu et lui renvoit alors une clef publique certifiant que tu as bien une puce TCPA. Ton fournisseur de contenu fait ensuite une demande une demande de clef symetrique pour lui et toi et le certicateur vous fourni a tous les deux cette clef symetrique. Ton fournisseur de contenu et toi dialoguez ensuite en utilisant cette clef.
Cela est extrememnt securise et tres respectueux de la vie privee. Neamoins etudions le pire cas possible.
Pour que ton fournisseur puisse reellement t'identifie et savoir de quel materiel tu te sert il faut d'abord qu'il te demande un hashage ID pur (ie ta clef ID constructeur+nombre aleatoire). Pour pouvoir casser cette clef et connaitre le contenu du nombre aleatoire il faut qu'il possede ta clef constructeur (et donc qu'il soit le fabriquant de ta machine ou alors severement de meche avec lui). De plus le nombre aleatoire etant par essence aleatoire il ne faut pas qu'il se trompe de clef non plus, sinon il reccuperera un nombre d'apparence correcte mais faux. Il faut donc aussi qu'il soit celui qui t'ai fourni ton appareil et qu'il est pris soin de noter ta clef auparavent.
Finalement pour recevoir ta clef lors de la demande d'identification il faut finalement que ce soit egalement lui qui fasse office de certificateur (sans quoi il ne recevra que la clef symetrique certifie pour le dialogue).
Donc oui si ton constructeur est ton fournisseur et est aussi ton certificateur alors il eput recuperer la partie aleatoir de ton identifiant unique par recoupements.
Bon, comme le pire peut toujours arriver admettons que ce soit le cas. Cette personne peut desormais identifie ta puce (et rien de plus) par demande d'un hashage ID pur.
Mais si elle veut faire jouer DRM ce qui l'interesse c'est de savoir quel tpe d'OS tu utilises, quel type de materiel tu utilise etc.
Pour identifier ta carte son par exemple voici la methode.
1) recuperer le nombre aleatoire de l'ID par la methode ci dessus
2) demander une serie de hashages ID+nombre aleatoire+periph PCIx (avec x entre 0 et 6)
3) Creer une PC a l'identique du tien en mettant en place le meme ID constructeur et le meme nombre aleatoire que dans ta propre puce (il peut le faire vu qu'il est aussi ton constructeur dans ce scenario super catastrophe).
4) Pour toutes les cartes sons compatibles DRM creer un hashage ID+NA+PCIy (avec y = position de la carte son)
5) Pour toutes les cartes son non DRM creer un hashage ID+NA+PCIz (avec z position de la carte son)
6) Verifier que dans la serie de hashage demandes a l'utilisateur en 2) si il y a bien un hashage identique a 4) et aucun hashage identique a 5).
7) Se rejouir en se disant qu'il ne reste plus qu'a verifier les autres periphs
Dans le pire scenario possible, en donnant acces a tout un tas d'autres informations a ton fournisseur de contenu ca reste quand meme vraiment penible de faire du DRM non ? (Bien sur au moindre flashage de bios d'un des periphs le hashage change aussi).
Par contre comme tu peux le constater il y a intervention d'une tierce partie qui sert de certificateur, ce qui a soi seul justifie que les algorithmes de verif ne soient pas disperses dans la nature. Mais rien n'interdit de voir un jour un serveur de certification etre mis en place par un organisme du libre.
Kha-
[^]Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org (page perso, ) le 07/10/2003 à 15:15. (lien). Évalué à 2.déjà c'est bien, par rapport à nos longues discussions précédentes, que tu reconnaisses implicitement que la seule fonctionalité de TCG non faisable par des softs libres est l'identification à distance de mon OS et de mon matériel par un tiers qui ne fait pas forcément partie de mes amis...
il y a cependant 2 points qui me genent dans ton raisonment:
1. tu considères que la puce TCG ne peut pas fournir et signer "séparément" le checksum du bootLoader, celuis du bios, et les numéros d'identification TCG des modèles des matériels. pourquoi ? apparemment tu considères, sans raison apparente, que seul un checksum signé de l'ensemble de ces checksums est obtensible (ce qui est déjà très grave )
2. en admettant que tu as raison au 1., qu'est-ce qui empeche de faire un programme assez simple qui calcule tous les checksums possibles étant donné qu'il y aura toujours un nombre forcément non illimité d'OS TCG, bios TCG et matériels compatibles TCG ?
Il n'y a pas forcément besoin, contrairement à ce que tu suggère, d'avoir sous la main tous ces softs et matériels, seul les checksums qui leur sont caractéristiques sont suffisants pour ensuite calculer le checksum de l'ensemble de ces checksums !-
[^]Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par Jerome Herman () le 07/10/2003 à 15:55. (lien). É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-
[^]Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org (page perso, ) le 07/10/2003 à 17:00. (lien). Évalué à 1.Il fournit une clef publique basee sur le checksum dans une certaine mesure.
c'est carrément incompréhensible ce que tu dis là, et la clé privée associée à cette clé publique elle sort d'où ?
or la puce TCPA a ete construite pour rendre ce genre de chose tres difficile.
ah bon ? et pourquoi ?
TCPA est totalement incapables de faire le checksum d'un ou plusieurs softs.
mesonge !
les specs TCPA prévoient que tout logiciel (que ce soit le BIOS ou un soft lancé par le bios) doit être hashé !
voici un extrait des documents TCPA que je cite plus bas dans une autre réponse:
In general, any
code that is loaded and jumped to from the BIOS must be hashed and extended into PCR[4] prior to
turning control of the system over to that code.-
[^]Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par Jerome Herman () le 07/10/2003 à 18:31. (lien). Évalué à 1.c'est carrément incompréhensible ce que tu dis là, et la clé privée associée à cette clé publique elle sort d'où ?
Ben non hashage plus+nombre aleatoire + algo -> clef privee (qui ne sort pas de la puce TCPA sauf migration declenchee physiquement a la main par l'admin)
clef privee + aleatoire + algo -> clef publique (la seule qui sort).
C'est tout a fait classique le "dans uen certaine mesure" ne sert qu'a dire qu'il n'y a rien de trivial a repasser de la clef publique au checksum
ah bon ? et pourquoi ?
Parceque si il etait facile de faire un emulateur de puce TCPA sur un PC sans puce, alors la puce TCPA n'aurait strictement aucun interet (et meme s'en servir serait dangereux).
Ca c'est pour la raison logique.
Emuler uen puce via un logiciel est souvent long, la plupart des processeurs et des puces sont emules avec des facteurs de 100 voir de 1000 en ralentissement. De plus le comportement d'un emulateur n'est jamais rigoureusement identique surtout en ce qui concerne par exemple la generation de nombres pseudo-aleatoires, et comme c'est une des capacites primordiales de la puce...
In general, any code that is loaded and jumped to from the BIOS must be hashed and extended into PCR[4] prior to turning control of the system over to that code.
Ouais ! alors voila comment ca marche :
Le bios il s'initialise et au bout d'un moment il se sent seul, alors ils regarde a des endroits bien definis des fois qu'il y aurait pas un petit bout de code qui lui permette de repasser le bebe a quelqu'un d'autre.
Ce bout de code est charge par le bios, il donne le tout debut de l'init de la phase de boot de l'OS. A savoir 1) la position du loader 2) son point d'execution. Tres efficace pour savoir si on a touche au disque dur depuis la derniere fois, totalement inutile si on veut connaitre l'OS qui va etre lance. Je peux parfaitement reprendre exactement l'init boot loader de Windows2003 et le faire pointer sur un autre boot loader. Comme je ne suis pas encore passe en mode protege c'est la fete. Au moment du passage en mode protege le Bios est OUT, le Bios ne peut qu'ouvrir la porte au mode protege, de la il suffit que la premiere instruction quand le bios a tourne le dos soit "fausse alerte, on boot comme ca finalement" pour que la puce TCPA n'y voit que du feu au niveau de l'OS (par contre elle pourra se rendre compte qu'il y a eu des changement sur le disque).
Kha-
[^]Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org (page perso, ) le 07/10/2003 à 18:54. (lien). Évalué à 1.c'est carrément absurde, à écouter ton explication du hashage du boot (qui n'explique aps du tout pourquoi les specs de TCG olbligent à le hasher), on a l'impression que TCG ne sert à rien puisqu'il ne garantit même pas que l'OS n'a pas été modifié entre 2 utilisations d'une clé privée protégée par TCG !
même sans cela il faudrait être idiot pour accepter d'avoir une puce concue par MS (et d'autres) dans son ordinateur qui n'apporte rien de + pour l'utilisateur que ce que peuvent faire déjà des logiciels libres évolutifs !
Emuler uen puce via un logiciel est souvent long,
pour le problème qui nous intéresse (générations des checksums spécifiques à un OS précis) il s'agit surtout de respecter les specs TCG en matière de checksum, pas besoin d'émuler une puce hardware ni même toutes les specs TCG pour celà !-
[^]Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par Beretta_Vexee () le 08/10/2003 à 15:47. (lien). Évalué à 0.Tu n'as rien compris a la chaine de confience.
Si tu active TCPA/TPM, alors sa fonction de base pour ammorcer la chaine de confience c'est de verifier l'ammorcage du systeme, soit le Bios et ses composants tiers, puis le bootloader apres si la chaine doit se poursuivre c'est au bootloader et a l'OS de la continuer pas a TCPA.
Apres si l'OS est modifié entre 2 utilisations et qu'une chaine de confience fais intervenir la confience en l'OS, cette chaine sera rompue et les clées liées par un moyen ou un autre a cette chaine ne seront plus accessible point barre. Le but de TCPA, c'est d'étre la racine des chaines de confience pour que par exemple l'OS puisse a son tour offrir des services similaire, pas de proteger l'OS contre le modification ou d'interdire quoi que ce soit d'étre executé, ce n'est pas le but de TCPA, TCPA n'a de pouvoir que sur son petit coffre fort, qui ne s'ouvre que quand les conditions que tu lui a donner sont remplies.
MS, n'a jamais participer activement a TCPA/TPM, MS fait partie de centaine de consortium de groupe de forum de conception de norme, pour assurer ses arriéres ou pour pomper des idées, par exemple OpenGL, MS n'a vraiment rien a voir dans l'affaire TCPA/TPM !
Les specifications de TCPA etant trés complete il serait surment possible avec beaucoup d'effort d'emuler, une puce TCPA, pour Boch par exemple, mais cette clée aurait un certifica constructeur fantesiste, et serait donc d'aucune utilité si tu souhaite dejouer les systeme mit en oeuvre sur TCPA, et m'ait cela pourrait étre interessant pour la mise au point et le teste de module de crypto d'un OS, quoi que j'ai des doutes, coder un equivalent a TCPA ne doit pas étre trés simple.--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]les dangers de la chain of trust expliqués
Posté par free2.org (page perso, ) le 08/10/2003 à 16:21. (lien). Évalué à 1.sa fonction de base pour ammorcer la chaine de confience c'est de verifier l'ammorcage du systeme, soit le Bios et ses composants tiers, puis le bootloader apres si la chaine doit se poursuivre c'est au bootloader et a l'OS de la continuer pas a TCPA.
j'ai jamais dit le contraire, je dis juste que la chain of trust, si elle est poursuivie par le bootloader et l'OS va permetter de s'assurer à distance de quel OS on utilise:
si MS fait un bootloader qui n'accepte de booter qu'un windows signé par MS (le bootlaoder vérifie avec une clé publique de MS que les exécutables sont signés par la clé privée de MS)
la présence du hash de ce bootloader dans les infos PCR signées par TCG sera la preuve infalsifiable (à cause de la signature du TPM) qu'on a un windows signé par MS
voir le document Intel spring2003 pour les modalités
-
-
-
-
[^]Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par Beretta_Vexee () le 08/10/2003 à 15:34. (lien). Évalué à 0.c'est carrément incompréhensible ce que tu dis là, et la clé privée associée à cette clé publique elle sort d'où ?
La clée privée est generé en interne, en méme temps que la clée publique et ne sort pas de la puce c'est justement la l'interet d'une telle puce.
Trouve moi un mechanisme qui garentie qu'une clée est inaccessible en soft ? tu peux chercher longtemps cela n'existe pas, il est toujours possible de dumper la mémoire de shunter les composants et autres, ici la clée privée est crée dans la puce et n'en sort pas, et elle est inacessible en general ( a moin demande contraire lors de sa creation ).
or la puce TCPA a ete construite pour rendre ce genre de chose tres difficile.
ah bon ? et pourquoi ?
Parce qu'elle integre des mechanisme de chalange, avec la Root of Trust, qui empeche le remplacement de la puce, que ce soit pas un emulation ou une autre puce physique, et c'est la seul utilisé de ce qui est a tor assimilé a un identifiant unique.
les specs TCPA prévoient que tout logiciel (que ce soit le BIOS ou un soft lancé par le bios) doit être hashé !
Uniquement lors de la phase d'amorcage du Bios, avent le chargement du bootloader, et c'est normal si le systeme doit assuré l'integrité du Bios et des ses composants méme tiers, surtous quand l'on voit les bios étre de plus en plus complexe et flexible.
Apres dans un environement trés dynamique comme celui d'un OS moderne, tu va bien t'amuser pour hasher une application quelqu'on sans l'aide de l'OS.--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org (page perso, ) le 08/10/2003 à 17:46. (lien). Évalué à 1.Trouve moi un mechanisme qui garentie qu'une clée est inaccessible en soft ?
si tu as un OS très sécurisé (micronoyau à la Hurd ou bien encore les softs SElinux/systrace/LSM/UML/plex86 pour Linux) il sera très difficile d'accéder à une clé protégée (on peut par exemple interdire à tout le monde, y compris root, d'y accéder directement)
si tu es parano tu peux aussi faire que cette clé n'est utilisée qu'une seule fois au début du boot pour décrypter une partition très sensible (qui peut elle meme contenir des clés de cryptage secondaires) puis effacée de la mémoire avant de lancer effectivement le boot du système (dont tu auras aussi controlé l'intégrité des fichiers essentiels grace à tripwire)
tout ceci est très facile avec un CD-R de boot, une disquette read-only, une clé USB que tu retire avant de booter définitivement l'OS, etc.
par contre si ton OS est une passoire, et que on peut facilement accéder ou modifier (temporairement) les composants de base du système après le boot, alors même si un intrus ne peux pas accéder directement à la clé stockée par TCG, l'intrus peux quand même l'utiliser, y compris à l'insu du propriétaire du système et pendant une longue période (plusieurs mois ou années)
de + comme le système de cryptage de TCG est fixé une fois pour toutes (et n'est pas vraiment ce qui se fait de mieux en matière de crypto) l'intrus, s'il est puissant ou bien informé, peux aussi casser les clés de taille fixe que ce système emploie
encore une fois le seul intéret de TCG est bien pour un tiers de s'assurer ("attestation") du matériel et de l'OS que j'utilise-
[^]sécurité par l'obscurité d'une puce illusoire et dangereuse
Posté par free2.org (page perso, ) le 09/10/2003 à 10:27. (lien). Évalué à 1.J'ajoutes que il est très difficile, voir impossible, de prouver qu'une puce ne contient pas de bug (cf les bugs de nombreuses puces déjà sorties dont les Pentiums d'Intel, le noyau Linux essaye d'ailleurs d'identifier lors du boot les bugs connus des puces qu'utilise ton ordinateur pour les contourner)
Il me sera d'ailleurs très dur de vérifier que la puce TCG de mon ordinateur ne contient pas des fonctions spéciales non documentées (backdoors) qui pourraient compromettre les clés privées que j'y stocke !
Par conséquent un micro-noyau comme hurd (ou celui de RTlinux dont chaque ligne de source a été soigneusement étudiées pour s'assurer de l'absence de bug qui pourrait fausser les temsp de réponse) peut s'avérer aussi sûr qu'une puce TCG. Et même + car il pourra facilement être controlé par tous et être mis à jour en cas de nouvelle faille.
On en revient au débat sécurité par obscurité ou sécurité par examen et amélioration du code source
J'ai choisi mon camp: c'est celui de l'open source
-
-
-
-
-
-
[^]Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par Jerome Herman () le 07/10/2003 à 15:19. (lien). Évalué à 1.Je me reand compte que j'ai oublie de preciser deux choses :
1) Avec chaque nouveau hashage il faut un reboot, la puce TCPA ne faisant des hashages que lors du boot.
2) les peripheriques branchees a chaud ne sont donc pas detectables par TCPA, une carte son USB ou PCMCIA, un periph video FireWire ne sont donc pas det
-
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.