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
Aller plus loin
- Article sur Zdnet (7 clics)
- FAQ TCPA/Palladium (7 clics)
- DLFP : « Premier BIOS TCPA/Palladium » (5 clics)
# Re: TCPA/Palladium continuent d'avancer
Posté par Fabien Jakimowicz . Évalué à 10.
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 . Évalué à 10.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Dais Starry . Évalué à -5.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Fabimaru (site web personnel) . Évalué à -4.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par ouah (site web personnel) . Évalué à -3.
# Re: TCPA/Palladium continuent d'avancer
Posté par Alex . Évalué à 8.
yavait pas un projet freeBIOS qui éxistait ?
[^] #
Posté par Francois Revol (site web personnel) . Évalué à 10.
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
Posté par Loustic (site web personnel) . Évalué à 10.
Je sens que l'on va se faire avoir, lentement mais surement...
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par jeff110 . Évalué à 2.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par rouby (site web personnel) . Évalué à 5.
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 dinomasque . Évalué à 2.
Mauvais OS (qui fait des saloperies dans ton dos), changer d'OS !
BeOS le faisait il y a 20 ans !
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Pierre . Évalué à 3.
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 . Évalué à 7.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 2.
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 . Évalué à 3.
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 (site web personnel) . Évalué à 3.
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 . Évalué à 1.
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 . Évalué à 0.
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 (site web personnel) . Évalué à 1.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
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 . Évalué à 4.
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 . Évalué à 10.
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 . Évalué à 3.
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
Posté par Darckense (site web personnel) . Évalué à 1.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par ashram4 . Évalué à 1.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par ashram4 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
"La première sécurité est la liberté"
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Bruce Le Nain (site web personnel) . Évalué à 1.
Comme quoi, il n'y a pas que des pro-win à EADS
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
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 . Évalué à 2.
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 (site web personnel) . Évalué à 2.
>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 dinomasque . Évalué à 2.
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 :(
BeOS le faisait il y a 20 ans !
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par sedget (site web personnel) . Évalué à 9.
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 ナイコ (site web personnel) . Évalué à 3.
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` . Évalué à 1.
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 ... )
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Fulgrim . Évalué à 1.
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 (site web personnel) . Évalué à 1.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par stinger750 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 G. (site web personnel) . Évalué à -1.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 0.
faut faire un peu attention à pas tout amalgamer, ça fait pas très sérieux...
# Re: TCPA/Palladium continuent d'avancer
Posté par Piksou . Évalué à 4.
http://www.microsoft.com/resources/ngscb/default.mspx(...)
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par ナイコ (site web personnel) . Évalué à 1.
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 (site web personnel) . Évalué à 8.
# Re: TCPA/Palladium continuent d'avancer
Posté par Beretta_Vexee . Évalué à 10.
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.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Jerome Herman . Évalué à -1.
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 . Évalué à 1.
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 (site web personnel) . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 1.
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
* 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 . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 1.
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 . Évalué à 2.
[^] # Re: limitations de TCG par rapport aux softs libres
Posté par Jerome Herman . Évalué à 1.
Kha
[^] # Re: limitations de TCG par rapport aux softs libres
Posté par free2.org . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 1.
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).
[^] # Re: PREUVE IRREFUTABLE: document Intel entièrement consacré à l'identification à distance via TCG !
Posté par free2.org . Évalué à 1.
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 . Évalué à 1.
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.)
[^] # attestation que ma platform = mon PC+monOS est non modifié
Posté par free2.org . Évalué à 3.
"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 . Évalué à 3.
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 . Évalué à 2.
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 . Évalué à 2.
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 . É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ù ?
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 . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 0.
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.
[^] # les dangers de la chain of trust expliqués
Posté par free2.org . Évalué à 1.
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 . Évalué à 0.
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.
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org . Évalué à 1.
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 . Évalué à 1.
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 . Évalué à 1.
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 detectable par la puce si ils sont ajoutes apres le boot, la seule solution possible pour eviter uen copie par ce genre de periphs avec TCPA et de demander a ce que le bus correspondant soit desactive.
Kha
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org . Évalué à 2.
De toutes façons les périphériques USB non encore pris en compte permettront uniquement de copier des fichiers audio/video...
Or ce qui m'inquiète, ce n'est pas la possibilité (qu'on aura toujours en analogique de toutes façons) de copier des musiques ou des vidéos, c'est surtout la possibilité d'identifier un OS pour interdire à des OS alternatifs d'accéder à certains contenus ou certains programmes (cf les serveurs d'identification de Office 2003)
On a une vraie menace pour notre liberté de continuer à utiliser des OS que l'on peut controler et modifier soi-même !
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par Jerome Herman . Évalué à 1.
si les périphériques USB (aujourd'hui majoritaires) ne sont pas encore pris en compte par TCG, cela ne fait que simplifier la base de données des checksums des OS et matériels qui permettront d'identifier ta plateforme
Certes, peut etre meme que comme ca on arrivera a trouver assez de molecules dans l'univers pour stocker toutes les possibilites. Par contre ca ne servira a rien vu que comme les periphs seront rajouter apres rien ne garantie l'integrite de la protection.
De toutes façons les périphériques USB non encore pris en compte permettront uniquement de copier des fichiers audio/video...
Ah bon ? tu peux m'expliquer ce qui va m'empecher de sortir un doccument different ? Si le systeme est persuades d'etre en mode full DRM alors qu'il ne l'est pas qu'est ce qui m'empeche de copier un fichier dans une zone qu'il considere comme legale ? Dans le pire des cas je epux toujours sortir mon doccument comme un compose audio ou video.
c'est surtout la possibilité d'identifier un OS pour interdire à des OS alternatifs d'accéder à certains contenus ou certains programmes
Soit rassure, TCPA ne permet absolument pas de faire ca (a moins bien sur que la personne qui a installe ton serveur d'identification soit egalement ton fabriquant et ton fournisseur de contenu et ton certificateur). Je te renvois encore une fois a mon post plus haut.
Kha
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org . Évalué à 1.
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 . Évalué à 0.
Ca ne sert a rien de discuter avec une personne qui ne sait pas de quoi elle parle du tout et qui repette plusieurs fois exactement le meme argument. Tu trouvera la reposne a cette affirmation grotesque un peu plus haut.
Doccument toi sur le processus de boot sans TCPA, notamment les phases d'initialisation du boot loader, la relache des interrupts par le bios et le passage en mode protege.
Desole
Kha
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par free2.org . Évalué à 2.
je te trouves bien prétentieux !
Je pense avoir de très bonnes connaissances en informatique (DEA avec mention très bien), mais en effet je n'ai certainement pas autant de connaissances que le grand universitaire Ross Anderson qui étudie depuis longtemps la crypto et le libre, et TCG depuis plusieurs années (TCG est le nom officiel de TCPA depuis + d'un an, il faudrait peut-être que tu remettes à jour certaines connaissances !).
voici la dernière version (aout 2003 !) de ses arguments sur TCG:
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html(...)
[^] # PREUVE IRREFUTABLE VENANT DE INTEL
Posté par free2.org . Évalué à 1.
http://www.intel.com/idf/us/spr2003/presentations/S03USSFCS69_OS.pd(...)
[^] # Re: prouvez moi que TCPA/TCG ne sert pas à identifier et blinder un OS DRM !
Posté par Jerome Herman . Évalué à 1.
Je ne remet pas un seul instant en question tes connaissances en informatiques, pas plus que je ne remet en question celles de M Anderson. Mais je pense simplement que sur ce point particulier il y a des chose que vous n'avez pas comprises, ce sont des points techniques surement completement disjoints de ce que vos domaines de connaissances respectifs.
Par exemple pour le hashage du boot. Tu me certifie que l'on peut identifier l'os en fonction du hashage de l'init du boot loader. Ce n'est pas possible pour les raisons suivantes :
1) Le boot loader n'est pas forcement l'OS loader, dans le cas de linux, BSD et Windows bases sur technologie NT ce n'est pas le cas. Le Boot loader et l'OS loader sont disjoint. Mais pire parfois l'init du boot loader et le boot loader lui meme sont differents. Dans le ca sle plus complexe le bios charge et execute l'init du boot loader qui a son tour charge et execute le boot loader qui donne le choix entre plusieurs OS.
2) L'init du boot loader change suivant la taille du disque, la partition sur laquelle se trouve le boot ou l'OS loader, le fait qu'il y ait ou non des secteurs defectueux, et bien sur la taille et la methode de mise en place du boot loader (ou de l'os loader). On peut donc considere a peu de chose pres qu'il y a autant d'init de boot loader qu'il y a d'installation differentes. Il est donc possible a la puce TCPA de reperer quasiment a coup sur une variation dans la sequence de boot initiale du systeme, par contre dans le cas d'un dual boot windows/linux elle sera incapable de savoir quel a ete ton choix car quand lilo s'execute toute la phase hashage et analyse de l'init du boot loader est deja termine : la preuve le boot loader s'est execute. A ce moment la tous les hashages de la puce TCPA sont deja finis et le coffre a clef est deja ouvert ou ferme.
Ce qui vaut pour linux vaut aussi pour windows. TCPA est incapable de voir si tu es en train de booter un windows dont rundll32.exe et kernel32.dll ont ete tweake pour faire apparaitre des informations de debug. Ces deux fichiers rentrent dans le processus de boot beaucoup trop tard pour pouvoir etre anayses. Bien sur a plus forte raison cela est valable pour tous les softs qui ne font pas partie du processus de boot.
Pour pouvoir faire du DRM il faudrait que la puce puisse surveiller trois crans plus loin a savoir le boot loader lui meme (si different de l'init) devrait aussi etre verifie et valide, bien sur l'OS loader devrait egalement subir le meme sort et la memoire devrait etre certifie avant le passage en mode protege. En fait seule la derniere etape est essentielle, on se moque bien de comment on arrive au moment ou on est sur que c'est un OS certifie qui va etre initialise, du moment que c'est bien ce qui se produit. Or TCPA est incapable de faire cela.
La phrase 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. The BIOS MUST not hash any data areas. Le traduit bien. le bios ne DOIT PAS faire un hash des zones datas, donc sur un systeme moderne ce n'est pa sl'OS loader qui va etre hashe mais le boot loader ou l'init du boot loader. La plupart des systemes d'exploitations ne tenant pas sur le MBR on est bien dans la zone DATA, et on peut donc les falsifier a tire larigo apres coup. Ceci est innacceptable pour faire du DRM.
Pour finir parlons de ton doccument Intel. Tu a l'air de penser que le registar et le repositary sont deux entites controllees par un consortium mondial et non pas betement deux serveurs montes par un admin lambda pour sa boite.
Il est evident que pour pouvoir authentifier une machine (via TPM ou non) il faut lui demander une premiere fois de generer une clef publique (la en l'occurence basee sur x composants du PCR) quand on est sur de la machine que l'on a en face de soi, et ensuite pour les authentifications ulterieures necessite un jeu de challenge reponse face a cette clef.
Quoi de plus normal que d'avoir une zone qui garde les clefs et une autre (eventuellement la meme ) qui est capable de faire l'association clef/machine.
Ces bases de donnes de hashage que tu brandis comme la preuve ultime ne sont que les donnees collectes a la main sur un reseau par un admin tout ce qu'il y a de plus standard. Mais il va de soit qu'avant de pouvoir consulter cette base le dit admin a du la creer, et il aura bien du mal a s'en servir pour authentifier une machine exterieure au reseau.
La seule chose qui puisse permettre une authentification a posteriori est le code fabriquant. Et encore il permet de certifier qu'il y a bien une puce TPM dans la machine et point barre.
TCG est le nom du groupe, TCPA etait le nom du systeme mais il n'est plus guere utilise a cause de la mauvaise pub, TPM est le nom de la puce.
Kha
[^] # chain of trust !
Posté par free2.org . Évalué à 1.
TCG ajoute dans le PCR un hash du bios écrit spécialement pour tcg, qui ajoute ensuite dans le PCR un hash du premier exécutable de boot écrit spécialement pour TCG (l'exécutable uniquement, pas ses données, cela est précisé dans les docs "chain of trust" officiels), qui ajoute un hash du 2e exécutable écrit spécialement pour TCG, qui ajoute... etc. jusqu'à ce que l'OS compatible TCG ait pris les choses en main
hashing is employed to extend trust from the BIOS to other areas of the platform
tout ceci est amplement confirmé par le document Intel du printemps 2003 que j'ai cité ci-dessus, dicument qui précise que chaque hash qui compose le PCR (ciomponent) est obtensible séparément et avec une signature assurant un tiers qu'il n'a pas été truqué par l'utilisateur (on voit bien que l'unique fonction de TCG par rapport à des softs libres équivalents est de se méfier de l'utilisateur pour faire plaisir à un tiers !)
bref, TCG n'apporte aux utilsiateurs d'OS libres qu'une seule chose: pourvoir se faire identifier à distance par des tiers comme n'étant pas utilisateurs d'un OS DRM non modifiable !
(et en + un OS DRM pourra facilement stocker des stockée des données non acessibles aux autres OS, autres OS qui devront par ailleurs booter sur CD car l'utilisation d'un lilo/grub entrainerait une rupture de la chain of trust)
REFUSONS TOUS les softs et hards TCG avant qu'il ne soit trop tard !
cf http://www.intel.com/idf/us/spr2003/presentations/S03USSFCS69_OS.pd(...)
où il est précisé qu'il faut créer un système mondial ("eco-system") de tous les hashs de tous les composants certifiés TCG (soft et hard) d'un ordinateur !
[^] # Re: chain of trust !
Posté par Jerome Herman . Évalué à 1.
Ta definition est amusante, quel domage qu'elle soit fausse. Pour ton information voici comment marche la chaine of trust :
Les clefs abritee par la puce TPM (TCG etant le nom du groupe une fois de plus) sont enfermes dans des boites gigognes. Pour que TPM accepte de libere une clef il faut qu'un certains nombre de conditions soient verifiees par les hashs PCR.
Ces conditions peuvent etre nulles (clef accessible a tous) ou demander que l'utilisateur soit le bon, ou demander que l'utilisateur, le bios, les periphs PCI, et le MBR soit les bons. Cette liste de conditions a remplir forment la chaine of trust. A savoir que tu peux faire confiance a la puce qui fait confiance au bios qui fait confiance au MBR.
Il n'y a pas d'executables ecrits "specialement" pour le systeme TCPA. Le bios doit bien sur pouvoir repondre aux demandes de la puce (sans quoi toutes les coffres qui contiennent des clefs necessitant un PCR dependant du bios restent fermees) mais ca s'arrette la. Une fois de plus la puce TPM ne peut pas et ne doit pas hasher les zones de donnees. Les seules informations qu'elle aura sur le disque seront sur le MBR. Ensuite uen fois les informations sur le MBR recoltee elle aura fini son hashage des composants. L'ensemble du PCR sera fixe et tout ce qui arrive apres ne la concerne pas. Meme si le boot loader etait certifie par un tiers et pouvait identifier l'OS il ne pourrait pas stocker l'information dans la puce (qui n'a pas d'emplacement PCR pour stoquer cette information), mais en plus ca n'est pas le cas.
tout ceci est amplement confirmé par le document Intel du printemps 2003 que j'ai cité ci-dessus, dicument qui précise que chaque hash qui compose le PCR (ciomponent) est obtensible séparément et avec une signature assurant un tiers qu'il n'a pas été truqué par l'utilisateur (on voit bien que l'unique fonction de TCG par rapport à des softs libres équivalents est de se méfier de l'utilisateur pour faire plaisir à un tiers !)
Oui c'est l'idee meme de la crypto non ? Chercher a verifier que la personne avec qui je dialogue est bien qui elle pretend etre. Pour finir les hashs ne sont pas obtensible separement, par contre tu peux faire une chaine of trust de longueur 1 qui ne hash qu'un seul peripherique. Par exemple tu creer une boite a clef tout utilisateur sur le PCR qui a hashe le periph PCI1 et tu demandes a TPM de te creer une clef privee dans cette boite.Ensuite tu demande la clef publique et tu la stoque dans ton repositary. Derriere si tu veux savoir si le periph PCI1 est bien identique a celui que tu connais et auquel tu fais confiance tu vas chercher la clef publique dans ton repositary et par un challenge reponse tu verifie que la clef privee et bien dans le TPM avec qui tu dialogue et qu'elle est disponible (ie que la chaine of trust de PCI1 est respectee).
Mais comme la clef privee cree par le TPM n'a aucun rapport avec le composants sur PC1 impossible de faire marche arriere et de deduire le composant de la clef privee. A plus forte raison de la clef publique.
Les parties hashages du PCR (checksums ) sont en zone dite interne de la puce. Impossible donc de les faire sortir ou de les migrer.
bref, TCG n'apporte aux utilsiateurs d'OS libres qu'une seule chose: pourvoir se faire identifier à distance par des tiers comme n'étant pas utilisateurs d'un OS DRM non modifiable !
Ben en tant qu'heureux possesseur d'une puce TPM et utilisateur de logiciel libre je te dis bien fort non. Ca apporte pleins de choses. Et comme en plus l'identification d'un OS DRM par TPM est inpossible a moins bien sur qu'il ne tienne integralement sur le MBR (bonne chance) et qu'une clef d'identification ai ete prechargee dans le PCR assiocie a cette sequence de boot (ce qui est interdit par la norme).
(et en + un OS DRM pourra facilement stocker des stockée des données non acessibles aux autres OS, autres OS qui devront par ailleurs booter sur CD car l'utilisation d'un lilo/grub entrainerait une rupture de la chain of trust)
Toutes les donnees accessibles ou challengables par l'exterieur sont migrables (et heureusement d'ailleurs pour des raisons de maintenance). L'admin de la puce peut donc sortir n'importe quelle clef de n'importe quel coffre et la placer dans un autre, par exemple celui daont la chaine of trust passe par lilo/grub ou le boot sur le cd de la knoppix.
REFUSONS TOUS les softs et hards TCG avant qu'il ne soit trop tard !
Oui si vous voyez un soft TCG refusez le ! Il n'existe pas, le vendeur est en train de vous arnaquer, la puce TPM ne peut pas hasher les zones de donnees.
où il est précisé qu'il faut créer un système mondial ("eco-system") de tous les hashs de tous les composants certifiés TCG (soft et hard) d'un ordinateur !
Comme quoi on peut avoir un DEA avec mention tres bien et ne pas savoir ce qu'est un ecco-systeme.
Kha
[^] # Re: chain of trust !
Posté par free2.org . Évalué à 1.
https://linuxfr.org/comments/281198.html(...)
toutes les fonctions de TCG sont faisables en mieux avec des softs libres sauf une:
l'identification infalsifiable de ma plateforme (matériel et OS) à distance vis à vis d'un tiers
je refuse donc TCG !
[^] # Re: chain of trust !
Posté par Jerome Herman . Évalué à 1.
La chaine of trust ne peut etre poursuivi que logiciellement, vu que la puce ne peut pas stoquer ces informations la. On retombe donc sur une banale securite logicielle. Oui c'est faisable, non c'est pas incassable. De plus toutes les clefs accessibles par l'exterieur de la puce TPM sont migrables. Bonne chance donc pour avoir une assurance quelconque.
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)
Bien sur qu'ils peuvent faire ca mais ils seront oblige de le faire en logiciel, la puce TPM n'apportera rien.
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
La presence (ou l'absence) d'un hash particulier dans une puce TPM est impossibel a dectecter. Tout ce que l'on peut faire c'est de challenger une clef qui se trouve normalement protege dans une zone dependante de ce hash. Mais si l'admin migre la clef tout se barre. Le challenger aura acces a la clef mais il n'aura aucun moyen de savoir si elle depend encore d'un hash PCR ou non.
voir le document Intel spring2003 pour les modalités
Tu gagne 1$ a chaque fois que tu cites ce doc c'est pas possible. Relit le tu verras qu'il parle d'une methode au sein d'une entreprise avec un admin qui remplit le repository lui meme pour l'usage exclusif de sa boite. Pas de plan mondial de recuperation de tous les hash de tous les PCR de la planete (ce qui tombe bien parcequ'ils ne sont pas recuperable de toute facon...)
Kha
[^] # démonstration logique de la nocivité de la "chain of trust" de TCG
Posté par free2.org . Évalué à 1.
donc un tiers peut savoir si mon bios est connu et non modifié et si mon logiciel L est connu et non modifié (et si ce logiciel L est connu pour être signé par MS pour garantir qu'il provient bien de MS, alors le tiers peut aussi le savoir)
jusque là on est d'accord ? très bien (I)
maintenant je vais définir la formule F suivante:
"soit A un logiciel dont on sait qu'il est signé par MS avant d'être lancé, si ce logiciel vérifie que le logiciel B auquel il donne la main est signé par MS (sinon il plante ou reboot) alors on sait que le logiciel B est signé par MS avant d'être lancé"
la formule F est évidemment vraie, tu en conviendras.(II)
maintenant je ne fais qu'appliquer la formule F:
si L est un logiciel conçu pour s'assurer que le logiciel L2 auquel il donne ensuite la main est signé par MS (sinon il reboote la machine), même conception pour L2, et ainsi de suite pour L3, L4 jusqu'à ce que le noyau et les processus root du système aient la main
de (I) et (II) je déduis:
un tiers qui recoit le hash de L signé par ma puce TCG peut avoir la certitude que j'utilises un OS signé par MS avant d'être booté
PS en ce qui concerne le doc de Intel il faut que tu me dises où il est précisé que les mécanismes évoquées ne sont pas utilsables par internet ! (et où il est précisé que cela concerne seulement un usage interne !)
[^] # Re: démonstration logique de la nocivité de la "chain of trust" de TCG
Posté par Jerome Herman . Évalué à 1.
- La puce TPM ne contient pas de systeme de reconaissance de signatures externes, elle ne peut que reconnaitre son propre travail. MS ne peut donc pas "signer" un programme de boot, la puce peut seulement reconnaitre une sequence qu'elle a deja "vu" avant.
- La puce n'exporte pas les hashs elle peut juste mettre une clef prive dans uen boite associe a un PCR. La seule chose qui sortira de la puce est la clef publique associee.
- Les clefs privees sont migrables d'une zone a l'autre par l'admin puce, une clefs lie a un PCR peut odnc etre deplacee vers une zone ouverte a tous.
- La puce hash le premier executable charge par le bios, or celui-ci varie suivant le support, le format du disque, ses partition etc. Il est donc impossible de creer ce programme a priori et de le signer. Il ne peut etre genere qu'a posteriori.
jusque là on est d'accord ? très bien (I)
Meme pas en reve
de (I) et (II) je déduis:
un tiers qui recoit le hash de L signé par ma puce TCG peut avoir la certitude que j'utilises un OS signé par MS avant d'être booté
Quel dommage qu'un tiers ne puisse pas recevoir le hash et que les programmes ne soient pas certifiables a priori mais doivent certifie a posteriori par l'utilisateur (de toute facon la norme TCPA interdit de precharger des clefs donc le probleme est regle).
PS en ce qui concerne le doc de Intel il faut que tu me dises où il est précisé que les mécanismes évoquées ne sont pas utilsables par internet ! (et où il est précisé que cela concerne seulement un usage interne !)
Ils sont bien entendu utilisable sur internet, ce n'est pas cela que je remet en cause, c'est le cote base de donnees unifiee. La puce TPM permet de faire deux choses au niveau des identifications
1) assurer via un registar (interne ou externe) que tu possede bien un TPM.
2) garantir via un repository (interne ou externe) que tu as toujours acces aux clefs qu'il t'a fait generer.
Identifier le materiel sous jaccent au hashage est tout simplement impossible
1) parceque les informations du hashage ne sortent jamais de la puce (elles ne sont pas migrables non plus)
2) parceque les clefs privees genere par TPM et stoquees dans un PCR sont independantes du PCR, et donc les clefs publiques (seules a sortir du TPM hors methode de migration) aussi.
3) parceque TPM ayant pour but d'identifier precisement une machine par rapport a une autre meme du meme modele possede des systemes de mesures extremenent pointus qui vont probablement faire correspondre des hashages differents a des produits d'apparence rigoureusement identique pour l'homme.
4) Meme si le hashage etait identique pour deux composants configures de la meme facon sur deux machines avec deux TPMs differents et que le hashage etait visible il faudrait une base de donnees monstrueuse pour le gerer. Exemple pour l'init du boot qui te plait tant, il existe
(Modeles disque dur)x(Formatages bas niveau possibles sur le disque dur)x(Geometries physiques possible compte tenu du formatage bas niveau)x(partitionnements possibles)x(position de l'OS loader sur le disque)x(type du boot loader)x(configuration du boot loader)x(type de l'OS loader) possibilites (et je pense que j'en oublie).
Kha
[^] # Re: démonstration logique de la nocivité de la "chain of trust" de TCG
Posté par free2.org . Évalué à 1.
je n'ai jamais dit ça et ma démonstration ne repose absolument pas sur cela, relis-là
La puce n'exporte pas les hashs elle peut juste mettre une clef prive dans uen boite associe a un PCR. La seule chose qui sortira de la puce est la clef publique associee.
ce n'est pas du tout ce qu'il ressort du document Intel déjà cité !
- La puce hash le premier executable charge par le bios, or celui-ci varie suivant le support, le format du disque, ses partition etc. Il est donc impossible de creer ce programme a priori et de le signer. Il ne peut etre genere qu'a posteriori.
et qu'est-ce qui empeche un bios spécialement conçu pour TCG (c'est quand meme ce dont parle la news ici) de s'assurer que ce premier exécutable est généré par un programme signé par MS puis de signer (ou mémoriser le hash) de ce premier exécutable après sa génération ? rien
mais de toutes façons tout ceci est probablement inutile car il faudra que tu m'expliques où tu as vu que le premier programme ne peut pas ajouter au PCR le hash du 2e programme et ainsi de suite
- Les clefs privees sont migrables d'une zone a l'autre par l'admin puce, une clefs lie a un PCR peut odnc etre deplacee vers une zone ouverte a tous.
pas une fois que le bios a donne la main (en stockant son hash) au premier programe:
si ce prmeier programme et les suivants ne permettent pas à l'utilisateur de modifier ce hash il sera infalsifiable même par l'utilisateur
le (I), le (II) et l'existence possible d'une base de hash de chaque élément sont clairement démontrés !
[^] # Re: démonstration logique de la nocivité de la "chain of trust" de TCG
Posté par Jerome Herman . Évalué à 1.
Ce n'est pas comme ca que je comprend le doccument Intel, qui parle de certifier un hash mais pas de le stocker, par contre la norme TCPA est tres claire a ce sujet les hashs sont impossibles a faire sortir de la puce.
et qu'est-ce qui empeche un bios spécialement conçu pour TCG (c'est quand meme ce dont parle la news ici) de s'assurer que ce premier exécutable est généré par un programme signé par MS puis de signer (ou mémoriser le hash) de ce premier exécutable après sa génération ? rien
C'est bien pour ca que je suis en rogne figure-toi il y aura un bios phenix qui supportera le Secure Computing (propriete exclusive de MS), aucun rapport avec le Trusted Computing (IBM, INTEL, AMD et MS). Le confusion entre les deux (entretenu par MS il faut bien le dire) m'ennerve.
Le bios peut s'assurer que le loader est conforme a une signature a condition d'avoir une clef. Cette clef devant etre protege contre la copie pour etre efficace. A partir du moment ou il y a une clef protege dans le bios MS n'a plus besoin de la puce TPM, le boulot est deja fait.
mais de toutes façons tout ceci est probablement inutile car il faudra que tu m'expliques où tu as vu que le premier programme ne peut pas ajouter au PCR le hash du 2e programme et ainsi de suite
La norme TCPA indique clairement que la zone de donnee ne doit pas renter en compte dans le hashage, si le bios le fait quand meme il viole la norme. De plus il faut que le bios soit capable de lire le disque. Une fois de plus on en revient a un bios special qui est capable de faire la lecture du contenu du disque pour verification. Il n'a deja plus besoin de la puce TPM a ce moment la.
pas une fois que le bios a donne la main (en stockant son hash) au premier programe: si ce prmeier programme et les suivants ne permettent pas à l'utilisateur de modifier ce hash il sera infalsifiable même par l'utilisateur
Si je me logue en admin TPM et que je boot sur un autre disque rien ne m'empeche de sortir la clef. Une fois de plus il faudrait que le bios (la puce TPM ne peut pas empecher un boot) m'empeche de booter une solution alternative. Si il est capable de faire ca il n'a plus besoin de TPM non plus.
le (I), le (II) et l'existence possible d'une base de hash de chaque élément sont clairement démontrés !
Toujours pas non, et apres il te reste encore a demontrer que c'est possible de le mettre en place ( cf 3 de mon post precedent) et que c'est utilisable (cf 4 ) ....
Bonne chance
Kha
[^] # Re: démonstration logique de la nocivité de la "chain of trust" de TCG
Posté par free2.org . Évalué à 1.
la norme dont tu parles c'est des documents vieux de plusieurs années faute d'avoir les documents actuels sous NDA
par contre Intel a accès à tous les documents actuels et les slides de son pDF sont clairs: le hash d'un composant est signable et envoyable à un challenger !
Le bios peut s'assurer que le loader est conforme a une signature a condition d'avoir une clef
fournir le hash d'un bootloader est largement suffisant pour savoir de quel bootloader il s'agit !
en ce qui ocncerne le mbr: pourquoi ne serait--il pas en 2 parties: partie exécutables et partie données qui prend en compte les spécificités du disques
Si il faut malgré tout un 2e type de MBR pour certains cas particuliers , leur hash sera répertoriable aussi
enfin il ne sera pas forcément interdit de booter sur autre chose que le HDD, mais l'OS bootera dans un mode spécial et alors tu ne pourras plus montrer patte blanche aux fournisseurs de contenus DRM (en l'occurence un hash connu pour le MBR)
encore plus drole: la génération et/ou la signature de certains programmes du boot peut très bien venir de MS lui même lors de la procédure interactive (par internet) d'activation de windows
La norme TCPA indique clairement que la zone de donnee ne doit pas renter en compte dans le hashage,
je n'ai jamais parlé d'une zonne de donnée mais bien du hash d'un exécutable !
la norme TCPA précise exactement au même endroit que tout exécutable lancé par le bios doit être hashé et ce hash stocké dans PCR, sans hasher les zones de données qui sont suceptibles de contenir des octets variables (et qui feraient varier le hash le rendant difficile à reconnaitre)
Secure Computing
tu crois que Intel n'a pas envie de faire de la concurence au Secure Computing ? si, et lagrande/TrustedComputing semble tout indiqué pour cela
Si je me logue en admin TPM et que je boot sur un autre disque rien ne m'empeche de sortir la clef.
quelle clé ?
moi je ne parle pas dans ce cas de clé mais de hashes non modifiables stockés dans le PCR lors du boot d'un OS MS
ces hashes sont amplement suffisants à identifier le MBR et s'assurer que c'est un MBR MS
PS je trouves que tu as nettement + d'idées quand il s'agit de t'attaquer au Secure Computing que à TCG !
Je ne comprends pas, penses-tu sincèrement qu'on puisse démontrer que des specs aussi énormes (et non entièrement divulguées) que TCG sont toujours inattaquables du point de vue des défenseurs de la liberté ?
Dès qu'un système est très complexe il devient impossible de démontrer qu'il n'a pas de failles et il n'est donc pas inutile d'en chercher comme je le fais. Je pense avoir trouvé d'ailleurs , et je pense plutot que cette "faille" d'attestation est voulue vu l'argent qui est en jeu dans ces histoires de DRM !
[^] # Re: démonstration logique de la nocivité de la "chain of trust" de TCG
Posté par Jerome Herman . Évalué à 0.
par contre Intel a accès à tous les documents actuels et les slides de son pDF sont clairs: le hash d'un composant est signable et envoyable à un challenger !
Deja je ne troube pas cela si clair, ensuite le PDF vise manifestement un plubic de neophyte et ne porte pas la marque d'un serieux technologique irreprochable. Je veux bien conceder qu'il y ait eu des modifications de faite en vue de la preparation de la norme TCPA2 et je n'ai pas acces aux doccuments sous NDA. Mais cela m'etonnerais beaucoup quand meme et s'eloignerais vraiment de l'esorit de la norme TCPA1. Pour finir le doccument d'Intel ne parle jamais d'envoyer une signature du Hash a un challenger, si un element doit posseder une telle information c'est le repositary qui va s'y coller. Un challenger n'a rien a faire d'un hash signe, lequel est inutile pour un challenge. Seul une clef publique certifiee par une tierce authorite l'interresse, et c'est le role du repositary de la lui fournir.
fournir le hash d'un bootloader est largement suffisant pour savoir de quel bootloader il s'agit !
Non le hash du boot loader ne donne aucune information utilisable sur le boot loader lui meme. Cela a revient a deviner le contenu d'un doccument a partir d'un MD5. Pire je me suis livree a une petite experience avec mon X31. J'ai fait un backup du disque via drive image et je l'ai restore. Plus moyen d'acceder aux clefs dont la dispo depend du PCR du bootloader (et uniquement de cela). Je ne sais pas ce qui a change (en theorie rien) mais le TPM s'est rendu compte de la modif. Bref le meme bootloader avec la meme config ne recoit pas le meme checksum lors du hashage apres une reinstall.
J'imagine que pour faire un hashage constant il faudrait que la puce puisse ignorer certains params mineurs. Par contre pour faire un hashage constant de machine a machine d'un autre modele il faudrait que la puce soit capable de mettre de cote tout un tas de parametres pour ne garder que l'essentiel du boot loader, ie elle soit capable de faire abstraction du type de disque, de sa taille, de sa geometrie, du partionnement etc. car se sont des informations variables de config a config et qui sont necessaires pour que le BIOS puisse passer la main a un autre systeme.
en ce qui ocncerne le mbr: pourquoi ne serait--il pas en 2 parties: partie exécutables et partie données qui prend en compte les spécificités du disques
Si il faut malgré tout un 2e type de MBR pour certains cas particuliers , leur hash sera répertoriable aussi
Cela demanderait une modification en profondeur du systeme de boot et donc a la fois du bios, des cartes meres et des disques durs. A l'heure actuelle le bios ne fait que charger le premier bootloader qui lui passe sous la main avant de l'executer. Et la puce TCPA ne fait que prendre une photo du bios avec le bootloader charge.
enfin il ne sera pas forcément interdit de booter sur autre chose que le HDD, mais l'OS bootera dans un mode spécial et alors tu ne pourras plus montrer patte blanche aux fournisseurs de contenus DRM (en l'occurence un hash connu pour le MBR)
Cela n'est valable que si le hash signe est en fait une clef publique challengeable (et donc techniquement pas juste un hash signe). Si c'est juste un hash signe rien ne m'empeche de l'envoyer aussi apres avoir faire un TCP dump sur une transaction legale. Si c'est une clef publique Normalement je dois pouvoir la migrer vers une autre zone (d'apres mon vetuste doccument). Et de totue facon la relation checksum => bootloader est loin d'etre triviale.
encore plus drole: la génération et/ou la signature de certains programmes du boot peut très bien venir de MS lui même lors de la procédure interactive (par internet) d'activation de windows
Pour etre valable cette procedure implique que Microsoft sait deja que le boot que je viens d'effectuer (et par extension le PCR) est valable. Ce qui lui est impossible vu que c'est precisement cette information qu'il essaye de certifier.
je n'ai jamais parlé d'une zonne de donnée mais bien du hash d'un exécutable !
Nous sommes bien d'accord, mais dans les architectures que je connais le seul executable chargeable par le bios est l'init du bootloader, lequel est beaucoup trop versatile pour que l'on puisse pretendre le reconnaitre apres un hashage. A moins de lui appliquer un traitement tres particulier coder en dur dans la puce je ne vois pas comment on peut faire la relation checksum->bootloader.
tu crois que Intel n'a pas envie de faire de la concurence au Secure Computing ? si, et lagrande/TrustedComputing semble tout indiqué pour cela
Je ne dis pas que ca ne sera jamais le cas, Intel a deja prouve qu'ils etaient tres interresse par des systemes d'identification unique et de profiling. Je dis juste que pour l'instant, dans la mesure de mes connaissances TCPA n'est pas utilisable pour faire de l'identification DRM, et ceci ni au niveau materiel, ni au niveau logiciel.
quelle clé ? moi je ne parle pas dans ce cas de clé mais de hashes non modifiables stockés dans le PCR lors du boot d'un OS MS
ces hashes sont amplement suffisants à identifier le MBR et s'assurer que c'est un MBR MS
CF plus haut dans ce posts pour mes arguments. La norme dit que c'est interdit et la relation hashage->bootloader est non triviale.
Je ne comprends pas, penses-tu sincèrement qu'on puisse démontrer que des specs aussi énormes (et non entièrement divulguées) que TCG sont toujours inattaquables du point de vue des défenseurs de la liberté ?
Non mais premierement ce que j'ai vu et lu (une bonne trentaine de fois) m'a clairemet rassure. Deuxiement : il faut toujours laisse le benefice du doute, TCPA se defend farouchement de pouvoir etre utilise en DRM et il apporte un reel confort en securite. Troisiemement si on passe notre temps a crier au lopu on prend le risque de se retrouver sans personnes pour nous ecouter au moment ou on aura vraiment un probleme.
La faille que tu penses avoir trouvee (et non la recherche n'est pas inutile, j'ai moi meme passe des heures avec le graph fonctionnel de TCPA sous les yeux) ne me parait pas credible. Je ne pense pas que celle-ci existe pour les raisons evoques ci dessus.
Kha
[^] # Re: démonstration logique de la nocivité de la "chain of trust" de TCG
Posté par free2.org . Évalué à 1.
je me suis mal exprimé, il était tard (il faut dire que quand il s'agit de TCG tu ne cherches absolument pas à comprendre ce que je cherche à dire, tu préfère jouer sur mes mots)
je voulais dire: fournir le hash d'un bootloader est largement suffisant pour qu'un tiers sache si il connait deja ce bootloader (ie le tiers en a deja fait un hash ou on le lui a donné !)
A l'heure actuelle le bios ne fait que charger le premier bootloader qui lui passe sous la main avant de l'executer
non car tous les bios sont paramétrables pour choisir quel périphérique sera utilisé pour booter
et j'ai déjà répindu qu'en cas de mbr non connu, tu pourras toujours booter un OS mais tu ne pourras plus montrer patte blanche (hash du mbr connu) aux fournisseurs de contenus
Cela n'est valable que si le hash signe est en fait une clef publique challengeable
n'importe quoi
je répète la phrase ci-dessus qui est évidente:
fournir le hash d'un bootloader est largement suffisant pour qu'un tiers sache si il connait deja ce bootloader (ie le tiers en a deja fait un hash ou on le lui a donné !)
La norme dit que c'est interdit et la relation hashage->bootloader est non triviale.
non pour la norme, cf document intel , et relis ma phrase répétée ci-dessus pour le hash (le document intel est d'ailleurs entrièrement basé autour de bases de données contenant des hashes à reconnaitre, tu refuses de voir ce qui ne t'arrange pas !)
bref ta "défense" de TCG est clairement démolie par le document intel spring2003 qui parle du début à la fin d'identifier de manière non falsifiable une plateforme à distance grace à TCG qui fournit un hash pour chaque composant !
[^] # Re: démonstration logique de la nocivité de la "chain of trust" de TCG
Posté par Jerome Herman . Évalué à 0.
je voulais dire: fournir le hash d'un bootloader est largement suffisant pour qu'un tiers sache si il connait deja ce bootloader (ie le tiers en a deja fait un hash ou on le lui a donné !)
Non tu t'es tres bien exprime. Prenons un autre exemple. Suposons que je connaisse parfaitement un format de facture numerique (c'est a dire un formulaire vierge). Ce format contient le nom de la societe emmetrice de la facture, son adresse, son numero de telephone et son kbis.
Ce format est connu de moi, je l'ai sous la main, je peux en faire tous les hashs que je veux.
Maintenant si la societe qui utilise ce format remplit une facture, en y mettant le nom du destinataire, le detail des prestations qu'elle a fournis, le montant hors taxe, les taxes, eventuellement un rabais et la somme due avec le delai de paiement. Serais-je capabale avec un MD5 du formulaire remplit dans une main et mon formulaire vierge dans l'autre de savoir si ce MD5 correspond bien a une facture faite avec le formulaire que je connais ?
Surement pas, a moins qu'avant le hashage un masque est cache les infos variables pour ne laisser que les informations statiques. Je ne crois pas a l'existence de ce masque qui laisserait trop de place pour les bidouilleurs dans le cas de TPM, c'est tout.
non car tous les bios sont paramétrables pour choisir quel périphérique sera utilisé pour booter
Oui tu peux changer l'ordre des bootloader qui vont lui passer sous la main, mais des qu'il en trouvera un il s'arretera la et n'ira pas regarder si les periphs suivants en contienne un autre (tu parlais de jouer sur les mots tout a l'heure ?)
hash du mbr connu
Une grosse partie de mon argumentation vient du fait qu'un hash de MBR ne peut pas etre connu a l'avance (ce qui est d'ailleurs plutot rassurant).
fournir le hash d'un bootloader est largement suffisant pour qu'un tiers sache si il connait deja ce bootloader (ie le tiers en a deja fait un hash ou on le lui a donné !)
Et je maintiens que le nombre de parties variables dans un mbr ou dans un bootloader rendent cela impossible
bref ta "défense" de TCG est clairement démolie par le document intel spring2003 qui parle du début à la fin d'identifier de manière non falsifiable une plateforme à distance grace à TCG qui fournit un hash pour chaque composant !
Bon ca va etre long et sur les deux colonnes qui restent suite aux reponses en chaine ca va pas etre drole, mais allons-y
page 1-4 sans interet pour la discusion c'est l'intro
page 5 accent mis sur le fait que le hard ne doit pas mentir
cela requiert :
-des mesures fiables
-un stockage protege de ces mesures
-la capacite a prouver que l'on peut faire ces mesures
Deja la ca coince, il est marque en toute lettre que pour que la puce soit fiable il faut que les mesures (et donc le hash) soit protegees.
page 6
-Clef d'attestation
2048 bit, cree par le TPM en interne , partie privee de la clef non migrable
-Certification
Obtenue aupres d'un registar, le credential n'a pas besoin de contenir la moindre information identificatrice.
Ouch reprobleme dans ton optique, les certificats emis par les registars ne contiennent pas d'infos identificatrices, on commence a etre loin du hashage unique qui circule sur l'internet
page 7
Explication de la creation d'une certif au pres d'un registar, on remarquera l'absence de toute tarce de hashage
page 8
Explication du fonctionnement du systeme de mesure (le hashage), la mesure est stoquee dans le SML, le PCR associe est cree et signe
page 9
Un challenger veut verifier si le PCR associe a un composant est accessible, il effectue donc une demande aupres de l'autre puce pour reccuperer le certificat, le PCR signe et le SML
page 10
le challenger authetifie les composant en chaine, le registar -> AIK -> PCR -> SML.
On remarquera que rien ne permet au challenger de verifier (et donc potentiellement de decoder) le SML, ce qui est normal vu que l'AIK lui certifie deja que les infos SML sont fiables, mais ce qui pose un leger probleme dans le cadre de ta theorie d'identification des hashages....
page 11
on sait maintenant que le composant 1 est present et certifie, reste a savoir si il est fiable
page 12
Comment faire ? soit par une base de donees completement definie, soit par l'intervention d'un admin qui connait ce composant. Cette connaissance s'apelle le repository.
page 13
Le systeme necessite que la tramission de la fiabilite, ou non, du composant soit egalement fiable.
page 14
Tout ce que l'on met dans le repository : le hardware, les politiques internes, les alertes, les softs etc.
page 15
Necessite d'ajouter dans repository des composants venant de plusieurs horizon. On notera aussi qu'il est necessaire de traiter les doccuments pour les rendre comprehensible une fois qu'ils sont dans le repository, et non pas avant ce qui traduit bien l'impossibilite d'anticipation.
page16
plan global de ce qui a ete vu plus haut
page 17
Rappel de ce que l'on possede comme systeme en tenant compte de ce qu'il y a plus haut.
Un systeme de mesure
un rapport sur le PCR
Une validation des certificats
Une validations des mesures (et non pas un rapport sur les mesures...)
Et une duree de vie de certifs.
page 18
Rappel de ce dont on a besoin
-Une com entre le repository et le registar
-Une com entre le challenger et le repository appuye par une police de validite de la plateforme
-Une com du challenger vers le repositary (?? pour l'envoi d'input cette fois ?)
-Un format pour le repositary (unifie etant sous entendu)
-Un outil pour traduire les inputs et les mettre au format repositary.
page 19
On a tout ca marche regardez ! (c'est vraiment pas une pres pour les techos)
page 20
Ben en fait non ca marche pas, il nous manque le format du repositary et des coms entre le repositary et le registar d'un cote et les coms entre le repositary et les challenger de l'autre. Bref pour l'instant tout ce qu'on vient de vous montrer n'existe pas, mais vous pouvez nous aider a le creer ! (ca ajoute encore un peu de credit a la pres...)
page 21
Bilan,
On peut certifie la fiabilite d'un composant
On peut attester de la presence d'un composant sur une plateforme via le challenger
L'ecco-systeme peut fournir des informations sur la fiabilite d'une plateforme
Bon en fait tout ca c'est au futur parcequ'on vient de commencer et que les normes sont pas fixees. D'ailleurs vous pouvez nous aider ?
page 22
C'est une bonne opportunite, viendez nombreux (on vous aime)
page 23
Merci d'etre viendu (remplissez le papier qu'on vous a donner en entrant merci)
page 24
Sauvegarde (si c'est un jet de sauvegarde comme dans AD&D ils l'ont foire)
page 25 & 26
On s'en fout.
Je veux eventuellement admettre que certains de mes arguments soient un peu leger mais de la a se faire demolir par CA !
En plus pas de trace de hash signe qui circule et qui est verifie ....
pouf pouf
Kha
[^] # Re: démonstration logique de la nocivité de la "chain of trust" de TCG
Posté par free2.org . Évalué à 1.
une grosse partie de ton argumentation est donc fausse
Car concevoir un ou plusieurs exécutables MBR hashables qui se contentent de stocker les paramètres du HDD dans une zone de données n'a rien d'impossible
En plus pas de trace de hash signe qui circule et qui est verifie ...
c'est limpidement faux et je pense de + en + que tu y mets beaucoup de mauvaise volonté:
page 9 il est expliqué que le challenger va obtenir la mesure du component1 (mesure qui est définie page 8 comme étant le hash du component1)
je crois que ces pages 8 et 9 du document intel printemps 2003 suffisent à prouver que la seule utilité de TCG est l'identification à distance des composants de ma plate-forme (OS + matériel, car c'est la seule définition de TCG) par un tiers !
[^] # Re: démonstration logique de la nocivité de la "chain of trust" de TCG
Posté par Jerome Herman . Évalué à 1.
Actuellement si. Pour pouvoir etre reconnu comme bootable par le bios et pour pouvoir reconnaitre le disque dur (et donc par la suite le lire) l'init du boot loader depend de la config de ce fameux disque. Donc meme si tu stoques des infos sur le disque a cote impossible de les lire si ton init de bootloader n'est pas correct. Impossible de "casser" le boot loader en un init indenpendant du DD et une zone de donnees. Un boot loader qui ne ferait rien d'autre que d'aparaitre comme init de boot loader au yeux du bios avant d'afficher le message "coucou" qu'il lirait sur une zone du mbr apres avoir ete jumpe par le bios serait deja tres dependant du type de disque dur.
page 9 il est expliqué que le challenger va obtenir la mesure du component1 (mesure qui est définie page 8 comme étant le hash du component1)
OOUUUIII je l'attendais celle la, et en plus j'ai volontairement laisse planner la confusion pour voir si tu allais mordre, ca n'a pas loupe. J'imagine que tu fait allusion a la fleche qui part du SML de la plateforme pour aller vers le SML du challenger non ?
Si c'est le cas jette un coup d'oeuil sur ce qu'est le SML et tu comprendras que tu peux dormir sur tes deux oreilles....
Kha
[^] # soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . Évalué à 1.
J'imagine que tu fait allusion a la fleche
je n'ais fait aucune allusion
je maintiens qu'il est marqué en toutes lettres page 9 que le challenger va obtenir la mesure du component1
et page 8 il est marqué en toutes lettres que la mesure du component1 est un hash sha1
ces 2 pages suffisent amplement à montrer ce qu'est vraiment TCG/TCPA
PS: vu ta mauvaise volonté à lire ce qui est marqué en toutes lettres dans le document Intel, j'aimerais que tu sois franc maintenant sur l'indépendance de ton opinion: peux tu nous dire si tu as eu l'occasion de travailler sur TCPA dans le cadre de ton travail ?
[^] # mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . Évalué à 1.
il n'y a absolument rien qui empeche de mettre toutes les données à la fin de ces octets
et de fait, un recherche sur google avec mbr "first sector" bytes retourne plusieurs documents qui détaillent des mbr dont les données sont stockées à la fin de ces octets !
une fois de + tu dis ce qui t'arrange, pas la vérité !!!
au fait, contrairement à ce que tu avais plusieurs fois affirmé avec véhémence, un autre document de Intel (membre fondateur de TCG)explique bien que la norme TCPA exige des BIOS spéciaux (évidemment puisque le BIOS va effectuer des opérations de hash destinées à être stockées dans le PCR)
http://www.intel.com/update/departments/initech/it11001.pdf(...)
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par Jerome Herman . Évalué à 1.
On est d'accord
il n'y a absolument rien qui empeche de mettre toutes les données à la fin de ces octets
du tout
et de fait, un recherche sur google avec mbr "first sector" bytes retourne plusieurs documents qui détaillent des mbr dont les données sont stockées à la fin de ces octets !
Tout a fait
une fois de + tu dis ce qui t'arrange, pas la vérité !!!
Ben en l'occurence la ta verite m'arrange vachement (au fait c'etait aussi la mienne, mais je t'en laisse la paternite si tu y tiens)
Regarde :
Si le bios lit tout le premier secteur, et si les donnees sont sur ce premier secteur, et si il est obligatoire de hasher le contenu du bios avant de faire le jump vers l'execution de l'init du boot loader => les donnees vont se faire hasher avec la partie non donnees.
Tant que le bios n'est pas capable de s'arreter en cours de chemin lors de la partie lecture du premier secteur (ie tant qu'il n'est pas capable de lire seulement l'exe et de bloquer les donnees), les donnees se feront hasher.
au fait, contrairement à ce que tu avais plusieurs fois affirmé avec véhémence
Ce que j'ai affirme avec vehemence, et que d'ailleurs je maintiens, et que pour que ta theorie se verifie il faudrait un bios qui se comporte vis a vis du disque dur, ou un disque dur qui se comporte vis a vis du bios de facon differente de ce qui existe aujourd'hui. Je le maintiens.
Bien sur que le bios doit etre capable de recevoir et de transmettre des informations a la puce TPM, mais son fonctionnement du point de vue de la machine hors TPM n'a pas bouge d'un iota. Et rien ne laisse penser que ce sera le cas.
Kha
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . Évalué à 1.
n'importe quoi, c'est évidemment le bios qui va choisir la zone du mbr qu'il va hasher, rien ne l'oblige à hasher les données !
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . Évalué à 1.
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par Jerome Herman . Évalué à 1.
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . Évalué à 1.
mais tu a clairement eu tort tout à l'heure de dire qu'on ne peut pas stocker la totalité des données modifiables en fin de mbr, et de ne laisser dans la partie exécutable que des données constantes qui ne feront donc pas varier le hash !
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par Jerome Herman . Évalué à 1.
Mais bien sur que l'on peut, je n'ai jamais dit le contraire. Les boot loader windows9x et dos le font d'ailleurs. Je dit juste que le bios n'est pas capable de faire le distingo sur le MBR entre les donnees et l'executable, et qu'il faudrait severement le modifier pourqu'il devienne capable de le faire !
Le bios ne comprend pas ce qu'il lit sur le MBR, seul le CPU le peut. Il peut reconnaitre a certains critere si il s'agit d'un boot loader ou non et c'est tout, de la meme facon qu'acrobat reader te jette pour tout fichier qui ne commence pas par %PDF, le bios ignore les BR qui ne commencent pas par une certaine sequence. Si il recupere cette sequence par contre il charge l'integralite du BR en memoire et il fait faire un jump au CPU sur ce segment. Peut lui importe que ce soit effectivement un BR ou une coincidence malheureuse. On peut parfaitement par exemple faire une disquette de donnees pures qui plantera un PC en boucle, et ce sans le faire expres.
Kha
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . Évalué à 1.
j'ai deja répondu à cela ci-dessous:
https://linuxfr.org/comments/281799.html(...)
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par Jerome Herman . Évalué à 1.
Le MBR d'un disque dur n'est pas une zone de donnees.
Kha
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . Évalué à 1.
mais je suis sûr maintenant que tu fais exprès de ne pas comprendre ce qui suit et qu'on a discuté des milliers de fois:
page 24 PC
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. The BIOS MUST not hash any data areas.
donc le BIOS doit hasher la zone exécutable du MBR et pas la zone de données !
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par Jerome Herman . Évalué à 1.
Je me demande qui fait expres de ne pas comprendre
On peut utiliser une partie du MBR comme une zone de donnees, apres tout c'est un secteur du disque comme les autres. On peut meme utiliser tout le MBR comme une zone de donnees. Mais ca ne change rien au fait que le bios ne considerera jamais un MBR commencant avec une siganture de boot comme une zone de donnees.
Si tu decide de couper ton mbr en deux et de mettre l'executable au debut et les donnees a la fin, tu n'as AUCUN moyen de dire au bios ou se trouve la coupure. Le bios n'a AUCUN moyen de la trouver par lui-meme, et quand au disque dur IL NE SAIT MEME PAS CE QU'EST UN MBR.
Ta zone de donnees sur le MBR est arbitraire, c'est le programmeur du bootloader qui a decide de la mettre la. Mais le MBR n'a pas de facon normee deux zones predefinies. Le bios ne peut donc pas faire le distingo entre ces deux zones PARCEQU'ELLES N'EXISTENT PAS. Il n'y a qu'une seule zone physique, qui n'est pas uen zone de donnees en regard du bios.
Si tu cree avec ton editeur de texte favori un texte dont les dix premeieres lignes sont du code C, et la suite un poeme de Ronsard IL S'EN FOUT. Par ce qu'il ne sait pas ce qu'est le C, il ne sait pas qui est Ronsard ou ce qu'est un poeme. Pour le bios c'est pareil, il ne sait pas ce qu'est un executable, il ne sait
pas comment ca marche ni pourquoi ca marche. Tout ce qu'il sait c'est que si il rencontre un motif sur la premiere tete du premier cylindre du premier secteur il doit charger TOUT le premier secteur en memoire. Et si un programmeur decide d'utiliser tout ou partie du mbr COMME une zone de donnees, ca n'en fait pas une zone une zone de donnees pour le bios.
Voila
Kha
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . Évalué à 1.
faux et d'ailleurs j'en ai deja parlé tout à l'heure. tu as de nombreuses possibilités dont:
1. avoir un BIOS (car TCPA onlige à modifier les BIOS !) qui reconnait une convention de type une séquence d'octet de meme valeurs
2. stocker dans le mbr toujours au meme endroit la taille de l'exécutable
3. c'est même possible sans convention: il suffit de commencer systématiquement la zone de données des mbr par la table des partitions, et je te mets au défi de prouver qu'on ne peut pas faire un algorithme pour trouver (dans la très grande majorité des cas) où commence la table des partitions dans les mbr actuels (dont la zone de donnée commence effectivement par la table)
enfin je te rappelles que tu n'as pas le choix: si tu veux respecter la norme TCG, tu dois hasher l'exécutable et ne hasher que l'exécutable
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par Jerome Herman . Évalué à 0.
2) Une fois de plus il faut en plus faire un bios capable d'interpreter cette info.
3) Un secteur fait 512 Octets en physique, la dessus les 446 premiers octets sont pour l'init du bootloader, les 64 octects suivants pour la table et les 2 derniers octets pour la signature. Si tu met des donnees autres que la table des partitions au dela du 446 octets ton disque sera considere par le bios comme non formate (la signature ne sera plus valable)
Les informations telles que la localisation du noyeau ou du progamme a charger ainsi que sa taille sont forcement sur le 446 premiers octets, a moins une fois d eplus de modifier en profondeur le comportement du disque dur et/ou du bios.
enfin je te rappelles que tu n'as pas le choix: si tu veux respecter la norme TCG, tu dois hasher l'exécutable et ne hasher que l'exécutable
Faux, a l'heure actuelle la norme (que tu cites a tort et a travers) exige que l'on ne hashe pas les zones de donnees. Le MBR n'est pas une zone de donnees et il n'est fait nulle part mention de hasher exclusivement l'executable. Si tu modifie ton MBR au niveau pure donnees (par exemple en changeant ton kernel mais en gardant la meme version de lilo) le hashage change (et heureusement). Preuve qu'a l'heure actuelle les donnees du MBR sont prises en compte dans le hashage. Un comportement different serait tres grave, car il validerait le bootstrap sur des donnees tres incompletes.
Kha
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . Évalué à 1.
une fois de + tu fais exprès d'oublier que la norme TCG oblige à faire un BIOS qui répond à un cahier des charges précis dans lequel il est clairement que dit qu'on doit hasher la partie exécutable du mbr et pas sa partie données:
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.
il est impossible de continuer à discuter avec quelqu'un qui refuse de lire la phrase ci-dessus issue des specs officielles TCPA !
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par Jerome Herman . Évalué à 0.
CF doccument TCG_PC_Specification 1.0
Page 25 section 6.2.1 (le doccument interdit la copie)
dispo ici http: //www.trustedcomputing.org/home
Maintenant j'aimerais vraiment deux choses :
1) si tu veux continuer cette discussion envoit moi un mail a kha at free point fr parceque la ca commence vraiment a faire tache.
2) Perd cette habitude de moinsser les posts que tu ne comprend pas ca fait tache aussi
3) Quand je demonte un de tes arguments avec trois preuves il te faut demolir les 3 preuves pour pouvoir affirmer "donc j'ai raison"
4) Je pense que ca va te demander un effort mental monstrueux mais une fois dans tes reponses par des principes suivant
- Je ne fais pas uen course a l'ego, je me fous d'avoir raison, en fait si tu pouvais me prouver que j'ai tort ca m'arrangerait. Je ne sais pas si j'ai raison de dire que TCPA est inofensif il y a peut-etre un danger que je ne vois pas, mais je suis sur que tes arguments eux ne tiennent pas la route.
- Je fais tout pour essayer de comprendre ce que tu dis et pour y repondre en restant le plus objectif possible, j'utilise parfois le cynisme et la raillerie dans mes posts mais jamais la mauvaise foi.
-Je ne bosse pas pour TCG, ou un membre de TCG, ou un pour un mec qui bosse avec un type dont la soeur du cousin a des actions chez un membre de TCG.
Kha
[^] # données mbr sur le 2e secteur !
Posté par free2.org . Évalué à 1.
en tant que connaisseur (car je le présume) de l'open-source tu ne me contrediras certainement pas si je dis qu'il est évident que un logiciel open-source modifiable est de loin préférable en terme de sécurité à un logiciel (ou des fonctions logiques dans le cas d'une puce) closed-source, et encore + si le binaire closed-source est bien caché à l'intérieur d'une puce (sécurité != obscurité).
Donc je m'étonnes grandement quand tu affirmes que tu ne vois pas où est le danger de TCG, alors que closed source rime avec bugs cachés, chevaux de troyes et mises à jour de sécurité tardives (très tardives dans le cas de fonctions logiques en dur dans une puce)
il faut hasher l'ensemble des 512 octets du rpemier secteur d'un disque
dans ce cas c'est parfait car les specs PC de TCG sans NDA obligent clairement à stocker le hash d'un exécutable mbr provenant du 1er secteur du disque et rien n'empeche cet exécutable mbr de stocker ses données variables sur le 2e secteur (ou toute autre endroit à sa convenance !)
Et rien n'empeche MS d'écrire un tel MBR !
Donc rien n'empeche TCG d'être un outil de discrimination DRM aux mains de MS !
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par Jerome Herman . Évalué à 1.
Relit ta propre citation, le bios charge TOUT le premier secteur. De toute facon si le bios ne charge pas les donnees, il va avoir du mal a les loger en memoire pour l'execution de l'init du boot loader. Et donc le jump risque d'etre compromis.
Kha
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . Évalué à 1.
en quoi le fait de charger TOUT le premier secteur obligerait à hasher aussi la zone de données située après l'exécutable ? (alors que le bon sens et la norme consistent à ne hasher que la partie exécutable !)
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par Jerome Herman . Évalué à 1.
Donc soit le bios est capable de faire le distingo entre la partie executable et la partie donnee sur le MBR (et la bravo parceque c'est de l'octet brut) pour ne hasher que la zone executable. Soit il hashe aussi les donnees. Aujourd'hui le bios hashe aussi les donnees.
Kha
[^] # Re: mbr: octets organisables comme on veut puisque tout le premier secteur est chargé en mémoire !
Posté par free2.org . Évalué à 1.
et tu le sais très bien car on en a parlé de nombreuses fois !
page 24 PC
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. The BIOS MUST not hash any data areas.
le début des données à ne pas hasher peut être indiqué de plusieurs façons (suite d'octet ayant des valeurs précises, longueur du code ou des données stocké à une position précise, etc.,)
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par Jerome Herman . Évalué à 0.
J'y revient avec ton deuxieme posts en dessous
je maintiens qu'il est marqué en toutes lettres page 9 que le challenger va obtenir la mesure du component1
Alors a part le dessin il est marque en toute lettre
Le challenger demande un extrait du PCR qui contient les mesures du composant1
Le challenger recoit de la plateforme le SML la certif AIK et la valeur du PCR signee par l'AIK
Juste pour savoir elles ont ou les mesures ?
-Le certificat AIK est une clef publique generee a la demande du registar pour prouver la presence d'une puce TPM sur la plateforme, il est independant du materiel autre que la dite puce. La clef privee est generee par la puce et ne sort pas.
- Le SML est le log des hashages materiel, sa presence certifie que le PCR envoye correspond bien au composant demande en on pas a un autre composant. Il est egalement independant du materiel et notamment de la nature du composant.
-Le PCR signe par l'AIK est non seulement crypte par l'AIK, mais il est egalement independant du materiel. Il correspond au "numero" de la boite qui contient le hashage du materiel ainsi que les clefs eventuelleemnt placee la.
Seul le "contenu" du PCR est dependant du materiel, mais lui il n'apparait nul part.
Je m'interresse a TCPA en tant qu'utilisateur nous n'avons ni moi, ni aucune des boites pour lesquelles j'ai travaille, ni la boite pour laquelle je travaille le moindre interet financier ou contractuel envers les technologies TCPA
Kha
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . Évalué à 1.
page 9 il est clairement dit que la PCR value obtenue contient la mesure (définie page 8, à savoir le hash shA1)
il est bien précisé que la value PCR envoyées est signée et non cryptée !
PS au fait as-tu travaillé avec la boite aaee (2a2e) ou un de ses partenaires ?
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par Jerome Herman . Évalué à 1.
il est dit : "quote of PCR that contains component1 measurement" ce qui veut dire l'extrait du PCR qui contient la mesure du composant1.
Traduction simpliste "bonjour, c'est quoi le morceau de PCR qui est lie a la mesure du composant1 ?"
Reponse attendue "C'est le 42".
Rien a voir avec la transmission du contenu du PCR et surtout de la mesure du composant1.
Il est dit aussi : "PCR value signed by AIK" ce qui veut dire que la valeur du PCR est signe par le AIK.
La question est de savoir si le challenger recoit juste la signature ou la valeur du PCR + la signature. Pour moi il ne recoit que la signature. Mais meme si il recevait la valeur + la signature ca ne serait pas grave, parcequ'il recoit la valeur du PCR et non son contenu. Il recoit donc le nom de la boite a clef, mais ne sait rien sur les clefs a l'interieur....
Kha
Ah fait pour 2A2E, pourquoi ? Ils ont laisse tomber les vaeugles et se lancent dans le DRM ?
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . Évalué à 1.
la partie du PCR contenant le hash sera donc signée et donnée au challenger
tu dis des trucs faux quand ça t'arranges, c'est désespérant et fatiguant !
PS d'une manière générale travailles-tu avec des sociétés qui font de l'embarqué ? (et qui en général aiment les puces permettent de s'assurer à distance que l'utilisateur n'a pas modifié sans autorisation un matériel embarqué)
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par Jerome Herman . Évalué à 0.
La question est donc de savoir si la puce renvoit la valeur du PCR (le nom de la boite) ou le contenu du PCR (le contenu de la boite)
Et la reponse est
Challenger recieves from platform
- SML, AIK cred and PCR value signed by AIK
Kha
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par Jerome Herman . Évalué à 1.
Depuis je n'ai pas rebosse dans l'embarque, amis sur une plateforme embarque il est TRES facile de savoir a distance si il y a eu des modifs ou non (pour peu que le systeme possede une connection a distance), et ce sans passer par TCPA ou DRM. Tu met une puce de hash, tu lui demande un hash d'une section de programme que tu connais et c'est fini.
Kha
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . Évalué à 1.
"une puce de hash"
comment s'assurer que le fonctionnement de cette puce n'est pas contourné par l'utilisateur ?
comme montré ci-dessus par les specs et le domcument Intel, TCG a trouvé une solution incontournable par l'utilisateur !
à moins de casser la crypto employée ou qu'il y ait des failles dans les specs ou dans l'implantation (car comme j'ai expliqué à Beretta, il n'y a aucune raison pour qu'une puce contienne moins de failles que un micro-noyau opensource, je refuse de faire confiance à une puce opaque dont je ne peux controler qu'elle n'a pas de backdoor)
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par Jerome Herman . Évalué à 1.
Alors tu fabrique un module avec une prom (qui contient le numero de serie de l'appareil et eventuellement des codes de verif), une puce de hashage (qui supporte plusieurs systeme c'est mieux) et deux nappes pour le plugger sur ta carte.
Tu prend un polymere quelconque (un gros truc qui tache et qui peut pas s'enlever a l'acetone sans demolir les composants)
Tu prend ton montage et tu le noies dans le polymere (a l'execpetion des nappes bien sur)
Tu mets ce montage en serie sur ton bus (cpu+memoire < -> module< -> interface).
Et voila tu as pour 3 francs par modules (le prix que ca va te couter en volume) un systeme quasi incassable.
Tu peux compliquer ton modules si tu as besoin de plus de fiabilite, mais honettement tu es tranquile pour un moment.
Kha
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . Évalué à 1.
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par Jerome Herman . Évalué à 1.
1) tu connais par avance le systeme et ses tolerances, tu n'as donc pas besoin de systeme de mesure.
2) tu veux juste verifier si une information que tu possedes est vraie sur une plateforme, tu n'as donc pas besoin de systeme de cryptage pour comuniquer.
Les deux fonctions "cheres" de TCPA te sont donc parfaitement inutile. Pourquoi alors investir de l'argent dans un systeme complexe qui ne te sert a rien, alors que tu peux faire un systeme et peu couteux qui a toutes les caracs dont tu as besoin ?
Kha
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . Évalué à 1.
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par Jerome Herman . Évalué à 0.
Par contre c'est clair que si le systeme est deja integre, autant s'en servir, mais le but de ma demo est de montrer que les fabriquants de materiel integre n'en n'ont pas besoin.
Kha
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . Évalué à 1.
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . Évalué à 1.
quelle mauvaise foi !!!
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par Jerome Herman . Évalué à 0.
Oups desole, c'est encore un piege de mes tres vieilles et antiques docs dans lesquels il est fait mention sans arret du PCR value (adresse du segment PCR ou commence la boite a clef) et du PCR content (contenu de la boite).
Mais bon pour que les fans de Niklaus Wirth ne hurlent pas a l'infamie (ben oui tout le monde sait tres bien que l'on accede aux elements par valeur ou par adresse). Seulement tout le monde sait aussi qu'il y a un piege : les zones memoires ! Ben oui la valeur d'une zone memoire c'est justement son adresse, et les pointeurs sont la pour en attester. Hors le PCR (et ses segments) sont des zones memoires...
Kha
[^] # Re: soyons francs, le document intel spring2003 est une preuve formelle pages 9 et 8 !
Posté par free2.org . Évalué à 1.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Romain Guy . Évalué à 1.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Beretta_Vexee . Évalué à 4.
NGSCB, on peut en parler en parler mais pour le moment personne n'en sait plus que ce que MS veut bien nous en dire. La seul chose qui semble sur c'est qu'il ne destine pas cette technologie aux serveurs, ni aux diffuseurs ( media, logiciel et autre ) car ils ont d'autres plans dans ce domaine. NGSCB devrait étre une sorte de plateforme unifié de service cryptographique, aussi bien pour l'isolement et les espaces de confience que pour le cryptage des communications et des documents, et le tous de maniére transparente aux utilisateurs.
Les exemples d'utilisations de cryptographie transparent sont trés interessents, mais les mechanismes mit en oeuvre sont quand a eux terrifiant ( identifiant unique, tracage de toutes les operations sur un fichier, confience relative, abus de position, outil monopolistique, etc etc ...).
Pour donner des exemples grossiés:
TCPA c'est vous demandez a votre banquier suisse, de s'occuper de stocker dans le secret le plus totale vos clée PGP, tous ce que vous avez a faire c'est vous arenger avec votre banquier qui se trouve dans votre PC.
Avec NGSCB, c'est plus simple, le fabricant de votre processeur et MS, s'occupe de tous pour vous, vous n'avez méme pas a savoir que de telle mechanisme existe, tous ce que vous avez a faire c'est achetez le materiel avec le logo et remplir le formulaire d'enregistrement, et apres selectionner la liste des destinataire et les restrictions,de date de PC ou autre que vous voulez lors de la sauvegarde de vos fichier Words.
Vous n'utiliez pas Word, IE et compagnie tempie pour vous, l'interoperabilité n'exite plus, et la non-interoperabilité est protegé par crypto.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par vga1523 . Évalué à 1.
donc tcpa n'empêche pas l'utilisation de linux....
et puis, c ibm qui à inventé tcpa (voir misc N° jesépluskoi), or ibm à beaucoup investi dans linux donc pas d'inquétude !
le kernel 2.4.21 et suivants sont livrés avec des fonctions de criptage, peut-on dire que c'est du tcpa logiciel ??
(je suis pas expert en la matière, pardonnez si c'est une question bête....)
[^] # TCPA/TCG n'empeche pas linux mais peut le marginaliser
Posté par free2.org . Évalué à 1.
car ces specs permettent aux éditeurs d'identifier avec certitude l'OS utilisé, ils peuvent donc refuser d'envoyer des documents (contenus/programmes) à des OS non DRM ou à des OS DRM modifiables (ce qui est est le cas d'un linux incluant un module TCPA/TCG)
rappelons aussi l'existence pour office 2003 d'un serveur de droits DRM qui autorise au coup par coup un client à visualiser un document office crypté. Si ce serveur refuse de communiquer avec autre chose que des OS DRM certifiés MS et non modifiés, les OS alternatifs seront encore + marginalisés
[^] # Re: TCPA/TCG n'empeche pas linux mais peut le marginaliser
Posté par Jerome Herman . Évalué à 1.
Il est quand meme bon de se rapeller que dans le trusted computing le moteur c'est IBM, et qu'il a investit des miliards dans Linux.
Pour ce qui est de l'identification DRM je te renvoi a ce post
https://linuxfr.org/comments/280544.html(...)
Kha
[^] # identification de l'OS : les preuves
Posté par free2.org . Évalué à 1.
lire ma conclusion tout en bas
www.trustedcomputing.org/docs/14_industry_1.pdf
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.
---------------------------------------------
1.2.5 Initial Program Loader (IPL)
Start of informative comment:
This is the code that executes during the Post-Boot state. The purpose of this code is to load the
Post-Boot environment.
End of informative comment
page 9 du pdf PC
-------------------------
www.trustedcomputing.org/docs/TCPA_PCSpecificSpecification_v100.pdf
Entities to be Measured:
· Each IPL that is attempted and executed.
page 20 du pdf
---------------------------
2.1.2 Transferring Control
Prior to transferring control an executing entity MUST measure the entity to which it will transfer
control.
pdf PC
------------
page 24 PC
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. The BIOS MUST not hash any data areas.
---------------------------------------------------
tout cela sert à stocker un checksum de l'OS loader qui pourra ensuite être signé par la la puce TCG et envoyé à un tiers pour qu'il soit sûr de l'OS qu'on utilise actuellement (j'ai deja donné l'algo exact utilisé tout à l'heure dans des réponses à cet article)
[^] # PREUVE IRREFUTABLE QUE TCG=identification à distance VENANT DE INTEL !
Posté par free2.org . Évalué à 1.
https://linuxfr.org/comments/280780.html(...)
[^] # Re: TCPA/TCG n'empeche pas linux mais peut le marginaliser
Posté par Cédric Blancher . Évalué à 1.
[^] # Re: TCPA/TCG n'empeche pas linux mais peut le marginaliser
Posté par free2.org . Évalué à 1.
https://linuxfr.org/comments/280994.html(...)
[^] # Re: TCPA/TCG n'empeche pas linux mais peut le marginaliser
Posté par Cédric Blancher . Évalué à 1.
[^] # Re: TCPA/TCG n'empeche pas linux mais peut le marginaliser
Posté par free2.org . Évalué à 1.
pas une puce TCG qui contient une clé privée unique dont elle se sert pour signer les informations qu'elle certifie
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par sobek . Évalué à 1.
Crypto elle-même protégée par le DMCA...
Implacable :-(
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Colin Leroy (site web personnel) . Évalué à 1.
[^] # EUCD
Posté par free2.org . Évalué à 1.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par cornofulgur . Évalué à 1.
C'est bien la dernière des choses que j'ai envie de voir dans mon pc.
dans mon pc, ya déjà suffisamment de trucs zarbis et incompréhensibles comme ca.
des binaires, des devices, des passwords, des sources, des docs, des users, des logs
ET je ne peux pas tout gérer. Donc le banquier merci non, il restera hors de mon pc.
La bonne solution pour vendre du tcpa, ce serait qu'on puisse aller à sa banque acheter une magnnnnnifique fritz chip - qui ne sert à rien à part pour votre banquier - et qu'on puisse se la plugger au bon endroit, éventuellement se la déplugger et aussi changer de banque. Comme ca, c'est sain, ca me va.
Mais j'ai l'impression que le marché de la pupuce fritz chip du Grand Cartel de la Confiance n'est pas partie dans cette approche marketting. C'est plutot le marketting OGM vers lequel se tourne le cartel. ferme les yeux et avale.
Pourtant on avait l'exemple des cartes bleues. La pupuce à Moreno nous flique un peu beaucoup mais elle marche bien et on a la CNIL en cas de dérapage.
> TCPA peut considerablement renforcer la securité
faux. Les caméras de surveillance peuvent considerablement renforcer la securité. Tiens, la preuve :
http://www.notbored.org/change.html(...)
> remplacer /etc/shadow
fausse bonne idée. Un mot de passe qu'on confie à une machine DOIT être généré aléatoirement. Mais un mot de passe qu'on confie à un être humain DOIT être choisi, géré et protégé par cet être humain. On lui fait confiance, on prend un risque, on se surveille.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par dinomasque . Évalué à 1.
Tes gros paragraphes sont intolérables à lire :(
BeOS le faisait il y a 20 ans !
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Pipo2 . Évalué à 1.
# Ne soyons pas médisant
Posté par imr . Évalué à -1.
Dorénavant, un pc équipé du bios phoenix et de windows met moins de 2s à booter en bsod.
C'est un progrés! Avant il fallait d'abord lancer quelques applis! Que de temps gagné! Et n'oublions pas la tête des développeurs de virus, désormais inactifs (à part les virus qui ciblent les bios)!
Where do you wan
# Re: TCPA/Palladium continuent d'avancer
Posté par Jerome Herman . Évalué à 7.
TCPA permet exclusivement a un utilisateur de mettre des clefs et des informations dans la puce. C'est l'utilisateur qui possede les droits sur la machine qui choisit ce qui est securise par la puce ou non, et c'est aussi lui qui choisi dans quelles conditions cela ce fait. Une personne qui a les dorits sur la puce peut faire ressortir de la puce n'importequelle clef qui y est rentre (ie qui n'a pas ete generee par la puce elle meme). TCPA est donc tres difficielment utilisable a des fins restrictive telle que le controle de license, l'invalidation de doccument ou de programmes et bien sur le DRM
A l'inverse Ex-Palladium ne laisse aucun choix a l'utilisateur. Il divise l'ordinateur en deux zones completements disjointes (tout du moins c'est le but). D'un cote les programmes certifies tourant sur du materiel certifie de l'autre les programmes inconnus et le materiel douteux. De plus le systemes se reserve le droit d'invalider les programmes ou les doccuments au bout d'un certain temps si la license n'a pas ete renouvelle aupres d'un serveur de confiance (ideal pour le DRM). Ce dernierpoint etant d'ailleurs a rapprocher de la derniere declaration du chef de la securite de MS qui annonce un systeme de mise a jour et d'installation automatqiue des updates de securite.
Pour l'instant meme apres avoir epluche les docs TCPA deux cents fois je ne vois pas ce qu'il y a de mal dans cette puce (et je suis un parano de premiere). Par contre je me mefie comme de la peste de la solution Microsoft.
On verra la suite
Kha
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par fleny68 . Évalué à 1.
http://www.scs.unr.edu/~raife/rants/tcpa/xbox-tcpa.html(...)
Et l'exemple de la Xbox donne je pense une bonne idée de ce que MS entend faire de ce genre de technologie.
En bref, TCPA ou NGSCB peu importe, je préfère qu'il n'y en ait pas dans ma machine, parce que je préfère contrôler celle-ci par des logiciels que je choisis d'installer moi-même.
L'avis du préposé suisse relaté ici http://www.transfert.net/a9065(...) me semblait intéressant. Mais bon apparemment reprend l'analyse de Ross Anderson...
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Cédric Blancher . Évalué à 3.
TCPA, d'après le dernier draft que j'ai lu, est entièrement contrôlable par l'utilisateur qui peut, même si ce dernier a été fourni avec des jeux de clés pré-installées, le réinitialiser si besoin est. En outre, un module est disponible chez Intel pour Linux sous GPL pour accéder à ses fonctionnalités. Plutôt transparent je trouve.
Ce qui m'amène au distingo suivant. NGSCB (ou Palladium) est une fonctionnalité propre à Windows qui s'appuie sur un chipset qui pourrait être TCPA, mais n'est pas franchement parti pour, vu que le contrôle complet par l'utilisateur ne semble pas être du goût de Microsoft. TCPA est un chipset proposant à l'utilisateur, et ce quel que soit son OS, des fonctions cryptographiques et un espace de stockage sécurisé. En gros, ça me fait beaucoup penser à un token crypto intégré à la carte mère. alors maintenant, oui, ces fonctions peuvent être mises à profit pour nombres d'applications aux buts plus ou moins obscurs, mais est-ce pour autant une raison pour lui jeter la pierre ? C'est d'ailleurs ce type de procès que condamnent les adeptes du P2P : ne pas condamner le moyen, mais l'utilisation qui en est faite...
Personnellement, je trouve cela assez séduisant de disposer sur mon PC d'un chipset comme TCPA, dans la mesure où je peux complètement contrôler les fonctionnalités de ce dernier (ce qui est le cas pour le moment). La deuxième partie de la phrase est _très_ important. Si demain TCPA doit être livré avec une clé inamovible qui impose un contrôle sur tout ce qui va être fait avec, je gueule.
Alors évidemment, on peut se perdre en conjectures, faire des procès d'intention et voir le diable partout, mais en l'espèce, TCPA résoud plus de problèmes qu'il n'en pose. D'ailleurs, je me m'interroge sur la légalité de la vente d'un PC qui serait configuré pour ne pouvoir booter qu'un seul OS, fait sur lequel l'utilisateur ne pourrait avoir aucun pouvoir. Si ce n'est pas de la vente liée, je ne m'y connais pas ;)
[^] # seule originalité de TCPA/TCG: données accessibles uniquement à certains OS
Posté par free2.org . Évalué à 2.
toutes les fonctions de TCPA sont faisables en libre sauf une: l'identification infalsifiable à distance de l'OS utilisé, et le stockage par cet OS de données qui ne seront pas accessibles à d'autres OS du même utilisateur (tout cela grace à un checksum de l'OS loader que la norme TCG oblige à effectuer et à stocker dans les puces TCG; puces qui peuvent refuser à un OS d'utiliser des clés privées générées par d'autres OS)
j'ai déjà ci-dessus donné une version (condensée mais claire et efficace) de l'algo utilisé pour identifier à distance l'OS utilisé:
https://linuxfr.org/comments/280399.html(...)
et j'ai déjà publié sur linuxfr un article qui reprend les principaux dangers (présents et futurs) de TCPA/TCG:
http://free2.org/tcpa/(...)
je rappelle que Ross Anderson est un grand universitaire spécialiste de la sécurité et défenseur du libre, et que ayant lu et relu les specs de TCG/TCPA il explique clairement que TCG est bel est bien un support hardware idéal pour des softs de type palladium !
pour prévenir ce scénario, je refuse dès aujourd'hui d'utiliser des softs et matériels compatibles TCPA/TCG !
[^] # Re: seule originalité de TCPA/TCG: données accessibles uniquement à certains OS
Posté par Annah C. Hue (site web personnel) . Évalué à 2.
Quand je lis dans Misc un article qui vante les mérites de ce beau truc qui est si beau que les spécs sont sous NDA, l'impression devient très désagréable.
Quand personne n'arrive à nous donner les avantages de ce système par rapport à une implémentation logicielle, je commence à être convaincu de l'inutilité de ce machin pour les utilisateurs.
Oh bien sûr là je n'ai aucun argument technique, mais bon je dis juste mon sentiment subjectif, et je ne demande qu'à être convaincu des bienfaits du TCPA pour l'humanité.
[^] # Re: seule originalité de TCPA/TCG: données accessibles uniquement à certains OS
Posté par Cédric Blancher . Évalué à 0.
Il doit y avoir autant de différence qu'entre le stockage de clés privées dans un token crypto ou dans une clé USB avec des protections logicielles autour. Est-ce que les token crypto apportent quelquechose ? Je pense que oui, mais c'est un avis personnel, même si les fonctionnalités offertes sont réalisables logiciellement.
Ma vision de TCPA est plutôt neutre. Je le vois comme un élément fournissant des fonctionnalités de sécurité qu'on peut utiliser ou non. Ce qui ne me plait pas dans le discours qui traine, c'est la diabolisation de cet outil sous prétexte qu'il _pourrait_ servir à des fins qu'on sait être mauvaises, qui d'ailleurs (pour celles qui ont été avancées pour le moment) sont tout à fait réalisables sans cette puce, à l'aide de moyens logiciels.
En gros le discours, c'est que TCPA n'est pas une mauvaise chose en tant que telle, mais que oui, elle pourra avoir des applications mauvaises (exactement comme la crypto en a), dont l'exemple le plus flagrant est Palladium. Mais personne ne t'oblige à utiliser Palladium. Tu peux rester avec du logiciel libre qui, éventuellement, pourra exploiter la puce TCPA à des fins que tu définiras.
[^] # Re: seule originalité de TCPA/TCG: données accessibles uniquement à certains OS
Posté par free2.org . Évalué à 1.
https://linuxfr.org/comments/280994.html(...)
[^] # Re: seule originalité de TCPA/TCG: données accessibles uniquement à certains OS
Posté par Cédric Blancher . Évalué à 1.
Ceci suppose que tu utilises une plateforme de type Palladium qui utilise clairement les fonctionnalités de TCPA à ces fins et qui place ce type de droits sur les éléments qu'il stocke. Tu es encore maître de ton matos et tu n'es pas obliger d'y utiliser des OS de ce genre. Non ?
Pour ce qui est de l'identification à distance, cela suppose que l'OS transmette les informations au tiers, puisque la plateforme TCPA elle-même ne peut pas le faire. Hors, je ne vois pas ce qui empêche un OS de réaliser les mêmes opérations sans TCPA. Pour ce qui est des données inaccessibles aux autres OS, il en va de même, mais géré en logiciel avec de la crypto.
En fait, j'ai presque envie de te retourner la question : qu'est-ce que TCPA permet de faire qu'on ne pourrait pas déjà faire actuellement pour limiter l'interopérabilité ?
[^] # Re: seule originalité de TCPA/TCG: données accessibles uniquement à certains OS
Posté par free2.org . Évalué à 1.
dans la situation actuelle, quand un fournisseur de contenus communique avec l'OS d'un particulier, il n'a aucun moyen de savoir avec certitude que cet OS enforce le DRM et n'a pas été modifié par l'utilsiateur pour faciliter un contournement de DRM.
avec du matos TCG et des OS TCG, le fournisseur aura la garantie que l'OS booté est bien un OS DRM non modifié, car la puce TCG stocke au moment du boot un hash du premier programme booté par le bios TCG, premier programme (et progarammes suivants) qui vont eux-meme ajouter dans la puce TCG des hash des différents composants de l'OS.
à la demande du fournisseur ces hash seront ensuite fournis et signés par la puce TCG comme étant authentiques
[^] # Re: seule originalité de TCPA/TCG: données accessibles uniquement à certains OS
Posté par Cédric Blancher . Évalué à 1.
Imposer les DRM, c'est jouable logiciellement, mais ça demande de sortir une artillerie particulièrement lourde en terme d'outils de crypto. Le fait que la puce puisse lui facilité la tâche ne change rien à cet état de fait.
[^] # Re: seule originalité de TCPA/TCG: données accessibles uniquement à certains OS
Posté par free2.org . Évalué à 1.
un module logiciel est facilement modifiable/falsifiable/émulable lorsque tu communiques à distance avec avec un tiers
pas une puce TCG qui contient une clé privée unique cachée dans ses circuits et dont elle se sert pour signer les informations qu'elle certifie
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par beb . Évalué à 1.
Attends, il y a un truc qu je ne comprend pas (sur ce sujet, il y a toujours un truc que je ne comprend pas :(). J'ai cru comprendre que ce qui importait en matière de sécurité c'est le maillon le plus faible de la chaîne. Donc, si un utilisateur possède des droits sur la machine, la puce ne sert plus à rien. Si l'utlisateur en question peut se faire voler ses identifiants (login, mdp) et donc ses droits d'accès à la puce, je vois pas la différence entre stocker les clefs de crypto dans une puce TCPA ou sur tout autre support auquel l'utilisateur a accès.
Qu'est-ce que j'ai raté ?
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Jerome Herman . Évalué à 2.
L'utilisateur etant le maillon le plus faible de la chaine c'est a lui qu'il faut fournir des outils pour renforcer ce maillon
Il y a un excellent exemple au sujet des mots de passe plus haut je vais le reprendre.
Si un utilisateur a un mot de passe "faible" il se fera casser en quelques minutes (via une attaque par dictionnaire sur le fichier de mot de passe par exemple). Par contre si le mot de passe est crypte dans la puce alors pas moyen de faire une attaque sur le fichier de mot de passe (qui n'existe plus). Et la puce ne reagit que par challenge/response donc le mot de passe ne sort plus (sauf intervention de l'admin de la puce).
Derniere chose imagine un key logger qui tourne, tu recupere le mot de passe d'un mec a distance, tu essayes de te connecter a distance et tu rentres le mot de passe. Et paf ca ne marche pas, la puce refuse de laisser sortir cette identifiant la pour une session ouverte a distance par un ordinateur non connu.
C'est ce genre de choses que TCPA permet de faire, c'est vrai rien de plus et rien de moins que ce que l'on peut faire avec des logiciels libres si ce n'est le cote coffre-fort de donnees auquel aucun acces brut n'est possible (sauf a l'admin de la puce.).
N.B : Par acces brut j'entend un acces au fichier dans sa forme cryptee ou un acces raw au device qui contient les donnees cryptees.
Kha
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par beb . Évalué à 1.
Je suis pas expert en crakage de mot de passes :), mais le principe il me semble c'est d'essayer plein de mots de passe, les hasher avec l'algo adéquat et comparer avec ce qu'il y a dans /etc/shadow. Dans le cas où ce fichier est dans la puce, au lieu de comparer directement avec le fichier, tu vas interroger la puce qui va te dire oui ou non ? jusqu'a ce qu'elle te dise oui. C'est peut-être plus lent, mais pas tellement plus sûr non ?
Derniere chose imagine un key logger qui tourne, tu recupere le mot de passe d'un mec a distance, tu essayes de te connecter a distance et tu rentres le mot de passe. Et paf ca ne marche pas
Comme si tu configurais ton firewall / sshd pour n'accepter que certains couples IP / login pour les accès extérieurs ?
Je crois que j'arrive pas bien à voir si il y a un progrès qualitatif en sécurité avec TCPA, où si c'est juste une manière de regrouper toute la crypto que tu peux avoir sur ton système dans un seul composant.
Merci pour tes explications en tout cas.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par free2.org . Évalué à 2.
C'est avec ces clés RSA que seront crypté sur le disque dur les données "protégées" par RSA
Je préfère de loin utiliser des algos + récents dispos sous forme de softs libres pour crypter des donénes sur mon disque dur !
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Cédric Blancher . Évalué à 1.
Euh, RSA est un algorithme à clé publique et AES un algorithme à clé secrète. J'ai du mal à voir comment tu arrives à comparer raisonnablement les deux, en particulier si tu veux générer des signatures avec AES...
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Annah C. Hue (site web personnel) . Évalué à 2.
Mais bon on pinaille on pinaille, et tu ne réponds pas à la question essentielle qui est : le chiffrement hardware s'appuie sur des algos fixés, alors qu'en implémentation logicielle on peut changer d'algo rapidos si jamais y'a un mec qui trouve comment casser le RSA (par exemple) vite fait.
Alors, quel est l'avantage de l'implémentation hardware ? Pour l'instant je ne vois que des désavantages, et j'ai l'impression que ceux qui encensent le TCPA manquent fortement d'esprit critique. On dirait qu'ils ont tout à gagner avec ce machin, vu comment il est défendu becs et ongles. Quand on me force à acheter un truc qui est inutile pour moi et que j'ai pas le choix, je me méfie, c'est la façon de penser "sécurité", ce qui est inutile ne doit pas être installé. Je suis très étonné de voir comment réagissent certaines personnes qui m'ont pourtant l'air compétentes en matière de sécurité mais qui n'arrivent pas à comprendre cette façon de penser à propos du TCPA.
# Re: TCPA/Palladium continuent d'avancer
Posté par Simon Huet . Évalué à 5.
Allez, noël approche, profitez en pour l'offrir.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Rémi Hérilier . Évalué à 1.
Tu pourrais donner l'auteur et l'éditeur s'il te plait, histoire que le père Noël ne se plante pas ;)
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Matthieu Weber . Évalué à 2.
Cela dit. il serait bien d'arrêter de brandir ce livre à toutes les sauces dès qu'on parle de TCPA/Palladium/Microsoft en mentionnant la surveillance constante (« Big Brother is watching you »). La surveillance n'est qu'un outil parmi d'autres au service du pouvoir dans ce livre, ce n'est pas le coeur du livre.
[SPOILER]
1984 décrit surtout une société où les gens se sont fait laver le cerveau à un point tel qu'ils croient tout ce que le Parti leur dit (exemple le plus frappant : il étaient en guerre avec A, leur ennemi de toujours, et alliés avec B. Un jour, ils a été annoncé que la guerre avec B, leur ennemi de toujours continuait, et qu'ils étaient alliés à A. Un tel renversement de situation, sans la moindre explication, n'a gêné personne (sauf le héros, c'est pour ça qu'il se fait laver le cerveau en profondeur à la fin, avant d'être exécuté), tout le monde avale les balivernes du gouvernement sans broncher et sans se poser de questions.
Le fameux « Big brother is watching you », qui illustre que tout le monde se fait surveiller en permanence, que la délation de parents par leurs enfants est une chose commune et que le fait de penser en dehors de la ligne du parti est un crime, n'est pas la chose la plus importante dans ce livre. Le plus important, à mon avis, c'est que les gens n'ont plus aucun sens critique, et c'est ce qui fait la force du Parti au pouvoir. Tout le reste n'est qu'une liste d'outils qui renforcent le pouvoir du Parti sur la population.
En fait la population est divisée en 3 : le bas peuple, qu'on maintient dans l'ignorance, et qui s'en fout, la classe moyenne (i.e. les membres normaux du Parti) qui se fait laver le cerveau, et la classe dirigeante (i.e. les membres importants du Parti) qui sont les instigateurs de ce qui se passe, et qui veulent acquérir le pouvoir.... pour avoir le pouvoir. Seule la classe moyenne est sous le contrôle permanent du Parti, puisque que ce sont eux qui ont la possibilité de renverser la classe dirigeante pour devenir classe dirigeante à la place de la classe dirigeante. Le bas peuple, ce sont de moutons, ils ne présentent pas de risque s'ils ne sont pas dirigés par la classe moyenne (ceci est la théorie d'Orwell, expliquée vers la fin du livre).
# Re: TCPA/Palladium continuent d'avancer
Posté par Jasi Kiban . Évalué à 1.
C'est cool LinuxFr a une super-bonne visibilité, on dirait !
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Pierre Jarillon (site web personnel) . Évalué à 0.
Google Actualités : http://news.google.fr/(...)
Il y avait AFP, Havas, Reuters... maintenant il faudra y ajouter linuxfr !
# Re: TCPA/Palladium continuent d'avancer
Posté par deftones_chris . Évalué à 3.
Et puis la définition du TCPA/Palladium (qui d'ailleurs sont différents) est comique également. Heureusement que d'autres posts ont rectifié (même si cela leur coûte en xp).
Pas étonnant que la communauté passe quelques fois pour des fanatiques attardés.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par free2.org . Évalué à 1.
de +, si on sait lire entre lignes au lieu de jouer sur les mots, tout le monde peut comprendre le sens de cette news et les dangers encourus par nos libertés
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par deftones_chris . Évalué à -1.
Car tout cela peut permettre de te ficher, de te suivre, de connaître tes habitudes de consommations, de savoir où tu étais à certains moments de la journée etc. Cela aussi est un danger pour nos libertés. Appliques tu ton discours jusqu'au bout ?
De plus, si seulement monsieur Free2Org peut partir dans ses délires paranoiaques dans les posts, fallait m'en informer avant.
A force de lire entre des lignes des choses fausses ou bien non prouvées cela équivaut à faire ses propres vérités et cela est un réel un danger par nos libertés. Heureusement que tu n'es pas homme de loi, tu serais du genre à comdamner des personnes avant même leur procès.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par free2.org . Évalué à 1.
c'est pas ce que tu fais avec moi là ? en fait c'est pire, tu me mets dans la bouche des mots que je n'ai jamais dit !
# Re: TCPA/Palladium continuent d'avancer
Posté par clos . Évalué à 1.
[^] # faq TCPA/Palladium v 1.1 de aout 2003
Posté par free2.org . Évalué à 1.
voici le document original v 1.1 en anglais de Ross Anderson et mis à jour en aout 2003 ( notamment pour TCG)
http://www.cl.cam.ac.uk/~rja14/tcpa-faq.html(...)
# ça ne marchera jamais...
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 0.
Exemple: http://fr.news.yahoo.com/031007/35/3fk3j.html(...)
C'est plutôt le phénomène de psychose et l'avalanche de buzzwords qui est à craindre...
Autre question: est-ce que les autres plateformes matérielles vont être victimes du même 'virus' ? Les nouveaux Mac G5 ?
[^] # Re: ça ne marchera jamais...
Posté par deftones_chris . Évalué à 1.
Actuellement, Apple surfe sur la vague OpenSource et ils auront du mal à expliquer un systeme empêchant l'installation de Linux sur leurs machines. Même si dans les faits, ils l'ont trouvé: leurs dernières machine ont des cartes graphiques avec des drivers non dispo :-(
Par contre, concernant le DRM, il faut ouvrir les yeux et ne pas oublier qu'il devrait être intégré au kernel. Du moins, Linus en parle.
[^] # Re: ça ne marchera jamais...
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 2.
Il y a bien evidemment du code (appelé OpenBoot, il me semble) qui prend le controle de la machine avant le chargement de l'OS. Donc le contexte est quasiment identique. Et l'attitude d'Apple vis-a-vis de ces technologies "de capture" dépendra quand même fortement de la demande du marché.
cartes graphiques avec des drivers non dispo
Ce n'est pas spécifique au monde de la pomme. Hélas, ça semble être une tendance de plus en plus importante dans le monde des cartes graphiques.
intégré au kernel
Mon dieu, mais Théo ne va jamais laisser passer ça, j'espère. Déja qu'il veut débarrasser le système de toutes ses Gnuseries...
[^] # Re: ça ne marchera jamais...
Posté par deftones_chris . Évalué à 1.
clair qu'avec des divers proprios déjà compilés, seuls les possesseurs de x86 s'en sortent pas trop mal. Toutes les autres architectures ne doivent pas être déclarés comme "rentables".
# Re: TCPA/Palladium continuent d'avancer
Posté par sparky . Évalué à 1.
En bref, il _pourrait_ être possible de ne pas démarrer d'OS autre que MS même en désactivant la fonctionnalité.
Malheureusement, il faudra attendre et voir, mais cette fonction pourrait arranger certains : plus de prob. de ventes liées: seule l'operating system fourni avec le PC lui permettrait de fonctionner; obligation d'utiliser MS; à terme mort de l'OSS ou en tout cas, freins
pour son adoption...
Plus inquiétant : Phoenix a annoncé le 3 septembre un accord pour intégrer dans son Bios la technologie DRM dOrbid Corporation, qui permettrait aux fournisseurs de contenu didentifier les PC et les périphériques autorisés à lire certains fichiers en particulier, ce qui rendrait plus efficace le contrôle du contenu distribué, des échanges de fichiers et des copies de logiciel dun ordinateur à lautre.
La société a indiqué que la technologie dOrbid est complémentaire à la NGSCB de Microsoft et quelle permettrait aux fabricants de PC dintégrer la gestion numérique des droits directement au niveau du matériel, même si loption serait toujours proposée aux utilisateurs de lactiver ou de la désactiver. Je crois qu'à terme l'option d'activer ou non, ne sera simplement plus proposée
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
Ils n'en ont rien a foutre que tu l'actives ou pas.
Tu l'active, tu as de logiciels signés, tu peux lire les fichiers protégés par DRM.
Tu la désactive, tu ne peux plus accéder à ces fichiers. Point.
[^] # Re: TCPA/Palladium continuent d'avancer
Posté par fleny68 . Évalué à 2.
Dans la xbox le but est d'interdire d'utiliser la machine autrement qu'avec l'os qui va bien. Ce n'est pas désactivable. ce n'est pas TCPA? mais ça l'utilise, non?
# Re: TCPA/Palladium continuent d'avancer
Posté par getz1 . Évalué à 1.
A moins que mon info ne soit fausse, il ne faut pas oublier que la societé M$ utilise un système UNIX pour son site web, alors dans ce cas comment vont t'ils faire pour bloquer tous les systèmes en provenance du monde libre!
On ne scie pas la branche sur laquelle l'on est assis!
Il ne faut pas non plus oublier tous les systèmes de calcul de types CRAY où autre et qui sont basés sur un système plus fiable
que Win$
Je pense qu'il ne faut pas dramatiser, et que le monde libre va continuer d'exister!
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.