IBM dit que c'est pour des problèmes de vie privée qu'ils ont pris la décision que l'accès à cette clé puisse être désactivée dans les puces IBM actuelles. Cette décision interne d'IBM est la confirmation que la norme TCPA n'oblige pas à fournir la possibilité de désactiver cette clé (désactivation qui n'est faisable que si les softs et documents DRM dont on a besoin n'obligent pas à utiliser cette clé)
* conséquences : cette clé unique est pire qu'un simple numéro unique (retiré par Intel de ses processeurs, après des appels au boycott), car elle ne peut pas être contrefaite (elle est identifiable car elle seule peut décoder des messages cryptées avec sa clé publique associée). Un jour ou l'autre, l'utilisation de cette clé sera exigée par les softs DRM (donc fermer l'accès à cette clé impliquera de ne pas pouvoir utiliser ces softs pour encoder/décoder) pour que seul un ordinateur précis puisse accéder à un fichier protégé par DRM, pour un temps précis en fonction de ce qu'a payé l'utilisateur de l'ordinateur, et des techniques de watermarking pourront être utilisées par ce soft DRM pour savoir si ce PC a fait une copie en utilisant des techniques analogiques et l'a envoyé à d'autres PCs.
*info 2: il est possible pour un OS d'utiliser TCPA pour crypter certains documents et interdire aux autres OS d'accéder à ces documents
«if an attempt is made to boot an alternative system (...) the unseal will fail, thus protecting the data» bas de la page 4 de ce PDF.
* conséquences: tous les utilisateurs de dual-boot (par exemple Linux et Windows sur le même ordinateur) pourront bientot être confrontés à des fichiers (documents ou programmes) encryptés sous Windows et inutilisables sous Linux: les documents ne seront donc pas ouvrables par openoffice, et les programmes ne seront donc pas exécutables par wine.
Notons que sous Linux et Windows il est déjà possible de protéger par une passphrase certains documents ou certaines partitions. La différence est que cette passphrase est stockée dans le cerveau de l'utilisateur qui peut donc l'utiliser avec l'OS de son choix, pas dans une puce TCPA qui refusera à un OS alternatif de l'utiliser.
Notons aussi que des outils libres comme tripwire permettent de s'assurer en bootant à partir d'une disquette ou d'un CD-rom qu'un OS n'a pas été modifié par un virus ou par un cracker (pas besoin de TCPA pour cela donc)
enfin des outils libres de sécurité comme LinuxSecurityModule, systrace, fireflier, permettent de s'assurer que certains fichier du système ne pourront pas être accédés par des programmes qui communiquent avec internet (limitant par là meme les dégats que peuvent causer un virus ou un cracker)
*info 3: impossibilité de contrôler le code qui est dans les puces TCPA
contrairement aux softs libres de sécurité comme LSM/tripwire/fireflier/systrace, il est très difficile, voir impossible, d'aller controler le code qui sera stocké dans les puces TCPA .
Il est même prévu dans la spec officielle de cacher au maximum le fonctionnement d'éléments comme le générateur aléatoire (qui est pourtant la base de la sécurité de tout cryptage).
«Intermediate results from the RNG are not available to any user. When the data is for internal use by the TPM (e.g., asymmetric key generation) the data is held in a shielded location and is not accessible to any user.» en haut de la page 13 de ce PDF.
* conséquences: sécurité et obscurité ne font pas bon ménage. Des chevaux de Troie ou des failles pourraient être introduites dans ces puces sans que les utilisateurs le sachent. Les algorithmes de sécurité et de cryptages évoluent au fur et à mesure que de nouvelles failles sont trouvées: il n'est pas prévu dans les specs de pouvoir changer ces algorithmes si une nouvelle faille est trouvée. Aucun des algorithmes de cryptage utilisés dans les specs TCPA n'a été démontré comme étant incassable (par une preuve mathématique). La taille fixe de leur clé est incompatible avec l'évolution rapide des matériels et des techniques pour casser la crypto.
Bref, mieux vaut utiliser des logiciels libres de crypto évolutifs que des logiciels obscurs non évolutifs cachés dans une puce.
*info 4: TCPA inclut un mode "extend" qui permet de s'assurer que seul un OS signé pourra être booté avec ce mode «the OS kernel would have to be signed»
paragraphe 4 du document critique d'un des créateurs de TCPA (voir ici)
document commenté par IBM comme étant très raisonable "most reasonnable" et sans nier l'existence du mode "extend" au bas de la page 4 de ce PDF
*conséquences du mode "extend": tous les OS libres (noyaux + programmes systèmes) que l'on peut recompiler en totalité ou en parti ne seront plus utilisables avec TCPA après recompilation.
Voir plus utilisables du tout, même sous forme de binaires, si aucune version récente de l'OS n'est signée pour TCPA.
*info 5: les specs n'interdisent pas l'ajout de fonctionalités supplémentaires par chaque constructeur dans leur puces de sécurité: «it can be integrated into some existing component or components» voir la page 11 de URL permanente)
Aller plus loin
- site officiel TCPA (3 clics)
- nouveaux liens de la FAQ TCPA (1 clic)
- URL permanente «vérifications sur tcpa» (1 clic)
# "Encrypter"
Posté par Vanhu . Évalué à -7.
Le terme francais est "chiffrer", et ca me paraitrait plus "pro" (ou au moins plus propre, plus sérieux) de remplacer ca .......
# Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par TSelek . Évalué à 10.
Pour la clé racine, ça ressemble pas à une clé de fab permettant une personnalisation mais à une clé qui vous dépossede : ce n'est pas votre clé ! vous n'avez plus de contrôle sur votre PC ! vous payez un truc que vous croyez être votre PC et qu'on détourne en fait comme plateforme DRM, vous payez vos chaines !
Bref, si vous avez besoin de crypto, achetez un lecteur PINPad et des cartes à puces !
En plus si c'est sécuritaire comme du EAL4, le code doit être dispo à l'évaluateur dans le sens où à partir d'EAL4 le code est sensé résister à des divulgations, donc que des hackers puissent le lire ne doit plus être un danger, donc selon les CC à partir de 4 on devrait pouvoir faire le forcing sur l'accès au code sans que ça casse les CC... or là on cache tout... vous en concluez...
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par N/A . Évalué à 10.
Pourrais tu expliquer plus en détail ce dont tu parles ?
ex: "EAL4", les "CC", le "gun", "clé de fab", "lecteur PINPad", etc.
Ou à défaut, peux-tu nous indiquer un site qui documenterait tout cela ?
Merci ;-)
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par TSelek . Évalué à 9.
un gun c'est un générateur de nombres aléatoires, basé sur une source analogique de bruit blanc.
une clé de fabriquation c'est une clé insérée lors de la fabriquation d'un chip lors des permiers tests usine et que seul le fabriquant connait, mais elle sera desactivée plus tard par la pose d'un verrou lors de la personnalisation du chip et remplacée par une clé générée en interne ou descendue par un canal sécurisé. le principe de base c'est une clé par phase de vie, avec un proprio par phase de vie. dans le cas du TCPA on dirait que ça marche pas comme ça du tout, autrement dit la clé reste propriété du fournisseur ce qui est inacceptable.
un PINPad c'est un lecteur de cartes à puce avec écran clavier histoire de ne pas taper le PIN sur un PC (imaginez un B.O....)
un site ? nan, dommage, c'est tout éparpillé...
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par imr . Évalué à 8.
que le code inclus n'est pas censé résister à la divulgation, donc qu'il n'est pas aussi bon que ça, donc que des problémes de sécurité vont survenir, donc qu'on ne pourra pas intervenir sur le code défaillant pour y remédier, donc qu'on va régresser sur le plan de la sécurité, donc que c'est de la bouse ????
J'ai bon, m'sieur?
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par shbrol . Évalué à 9.
Il va y avoir regression du point de vue securité, mais par contre du point de vue business, c'est un gros progrès. En langage commercial, cela donnera:
"Voici TCPA-2.0, encore plus performant et sécurisé que la version précédente! TCPA-2.0 est optimisé pour l'architecture Zogtel Brolium-6".
Et il te faudra traduire: la version 1.0 était vérolée a mort, voici un truc qui fonctionne a peu pres. Mais vous êtes obligés de changer toute votre machine Brolium-5.
La société qui a inventé le procédé pour le software s'étant fait un pognon monstre, y a pas de raison qu'on applique pas la recette au hardware...
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par tuiu pol . Évalué à 2.
"ok, avant on etait pas totalement secure, notre but était de sortir le produit pour le public. Mais maintenant on est complétement orienté sécurité cette version 2.0 est vraiment une petite merveille, nous avons beaucoup appris des erreurs du passé ..etc". A incrémenter de version en version comme pour le discours depuis win 95 ..
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par TSelek . Évalué à 5.
Le paradoxe c'est qu'il y a un gros push marketing sur les EAL4, qui sont un niveau où la menace que le code soit connu par n'importe qui est considérée comme possible et donc devant être absolument contrée, surtout par la crypto dans les faits. Donc une logique plus proche du logiciel libre que proprio...
Si c'est EAL4 ils devraient pouvoir mettre le code au grand jour sans avoir à trembler, en plus coté proprio ils sont sensés être protégés par leurs brevets. Or ils ne le font pas. Ca protège pas les brevets ? C'est pas du vrai EAL4 ? :)
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Beretta_Vexee . Évalué à 1.
Pour la solution du PINPad, ou des lecteurs de smartcard, je veux bien ce serait une solution qui consillerit tout le monde, mais le probleme est que les lecteur standar ne sont pas securisé car il ne gere pas le padding, et ceux qui sont fiable sont proprio.
De plus la plus part de ces systeme coutes aussi chers qu'un processeur actuel ( 400E ), alors que tout l'interet de TCPA c'est que ce soit un standar sur le papier et dans les faits ( on a pas besoin d'un autre Betamax, qui bien que superieur n'a pas trouver son filon du fait de produit trop chers et peut courant ).
Bref, si vous avez besoin de crypto, achetez un lecteur PINPad et des cartes à puces !
Si on s'interesse qu'a ce qui font déjà usage du cryptage alors ca n'a plus d'interet.
En plus si c'est sécuritaire comme du EAL4, le code doit être dispo à l'évaluateur dans le sens où à partir d'EAL4 le code est sensé résister à des divulgations, donc que des hackers puissent le lire ne doit plus être un danger, donc selon les CC à partir de 4 on devrait pouvoir faire le forcing sur l'accès au code sans que ça casse les CC... or là on cache tout... vous en concluez...
Troll ... ta smartcard et ton pinpad c'est pour sa puissance des calcul que tu l'utilise ? non, c'est pour proteger tes clées de plus les algo son standar connue et publique RSA SHA AES on etait bien plus etudiés et attaqué que EAL4.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par TSelek . Évalué à 1.
Plus sérieusement :
tu peux m'expliquer ton histoire de padding ? j'ai pourtant bossé sur des tas de lecteurs et pourtant je ne comprend pas...
400 Euros ? tu achetes des modeles plaqués or ou quoi ? même aux banques on les vendait 3 fois moins chers...
l'interêt de TCPA ? courcircuiter les cartes à puce de conception française.
ensuite je crois que sur les clés tu te trompes, elles ne sortent __JAMAIS__ de la carte donc c'est bien sur la puissance de calcul de la carte qui est utilisée, et des cartes on en trouve en 8/16/32 bits avec ou sans accelerateurs cryptos. Quand aux algos, euh une carte c'est un CPU avec ROM/EEPROM donc on code l'algo qu'on veut...
plus etudiés et attaqué que EAL4 euh, ça veut rien dire ça, à part que tu n'ais rien compris aux CC (/o\ pas taper). EAL/CC c'est pas un algo, c'est une méthodologie et une librairie de critères sécuritaires...
YOU are a troll !
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Jean Roc Morreale . Évalué à 0.
et après on voit des critiques de /. et de ses échanges mais non j'insiste que sur ce point la france ne joue pas de son particularisme culturel et présente une similitude certaine ^^
'fin bon c'est avec ce type de super thread que j'en arrive à voir mes jeankevin-like m'expliquer que tcpa est le nouveau système anti piratage qui sera intégré à longhorn.... :/
"courcircuiter les cartes à puce de conception française"
malheureusement ce secteur se court-circuite déjà tout seul (gemplus) alors c'est peut-être pas l'argument contre tcpa le plus aboutit :p
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par TSelek . Évalué à 1.
Pour le reste de ton post, je t'y renvoie.
# Liens du site
Posté par Samuel Pajilewski . Évalué à -9.
JE suis sous Mozilla et NS 7, serait ce une erreur de ma part ou le site n'est pas compatible Mozilla ?
[^] # Re: Liens du site
Posté par fleny68 . Évalué à -3.
# Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Yannick . Évalué à 8.
Mais _en-soi_ cette technologie ne peut-elle pas être utile ?
En parcourrant l'article de LinuxMag sur les réseau sans fils, je me demandais s'il était possible d'utiliser TCPA pour améliorer la sécurité de ces réseaux en autorisant la connexion qu'aux machine identifiées par leur "numéro" TCPA. Est-ce que cette méthode serait infalsifiable ?
Ces réflexion m'ont amené à me poser la question : Est-ce qu'une machine virtuelle de type Boch pourrait "emuler" le TCPA ?
Maintenant, il est vrai que dans de mauvaises main, le TCPA peut engendrer de gros problèmes. Je pense aux DRM mais surtout aux truc du genre "votre patron vous envoie un courriel pour vous demander de faire quelque chose d'illégal, courriel qui s'autodétruira dans 15 seconde."
Néanmoins, ces problèmes dépendent de la onfiance que l'on a dans les concepteurs des logiciels que l'on utilise. Personnellement, je n'ai pas de problèmes de ce côté là. ;-)
Par contre, tu soulèves un problème important à mes yeux et auquel je n'avais pas pensé. Quid de la protection par une clef à longeur fixée au regard de l'évolution des techniques de décryptage ?
Yannick
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Vanhu . Évalué à 10.
Oui, mais on a pas besoin de TCPA pour ca: il "suffirait" de mettre en place sa propre PKi, et de stocker les certificats / cles privées (protégées par mots de passes, bien sur) sur les machines clientes. Après tout, de ce point de vue, TCPA n'est qu'une "variante", qui propose un avantage (stockage de la cle privee en Hard) et un inconvénient (on a aucun controle sur la cle privee (il en existe peut etre une copie ailleurs) ni sur l'autorité de certification (elle pourrait nous révoquer !) ....).
Après ca, tu concevrais un mechanisme d'authentification forte a partir de ces certificats (que tu confrontes à ton autorité de certification, plus eventuellement d'autres validations sur les champs du certificat) pour authentifier tes postes.
En extrapolant encore, on peut imaginer que ton méchanisme d'authentification permette aussi de négocier des paramètres (une clé de session, voire pourquoi pas carrément un algo de chiffrement, d'authentification, etc....), dont tu te servirais pour chiffrer/authentifier tous les paquets que tu emmets/recois avec ton correspondant....
Hein ? quoi ? ca existe déjà ????
Ah ouais, c'est IPSec.......
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Jak . Évalué à 7.
Et ainsi, tu contrôles entièrement ton système d'information, ce qu'a priori on ne peut pas faire aussi bien avec TCPA. Et, finalement, c'est le plus important.
[^] # Controle du système d'information
Posté par Vanhu . Évalué à 6.
Et présenté comme ca, ca peut paraitre potentiellement intéressant.
Le problème est justement que, en fait, on subit l'implémentation, et pire encore, on subit le certificat "principal" (on me fournit MA clé privée..... mais comment puis-je etre sur qu'il n'en a pas été fait une copie avant ??????).
[^] # Re: Controle du système d'information
Posté par TSelek . Évalué à 10.
De nos jours ces clés doivent être générées sur commande de leur propriétaire ! Le matos sait le faire ! On a cablé tout les trucs sur les nombres premiers et cribles associés. Ne vous faites jamais refiler des clés, générez les vous même !
Le matos sait le faire, exigez d'avoir accès à cette fonction de base qu'est la génération de clés ! C'est la __RACINE__ du problème...
[^] # Re: Controle du système d'information
Posté par tene . Évalué à 4.
"Both [integrity protection and trusted storage] use trusted root certificates as this basis [of their
security guarantees.]" This is a misunderstanding of the TCPA specification. There is no
requirement for certificates at all, to use any TCPA chip function. There doesnt even exist such a
root authority for TCPA in general, or for IBMs currently shipping chips. You can generate
private keys, use them to sign, and decrypt, and seal/unseal data under PCRs, all without any
certificates. The only time a certificate is needed is if you want to be able to prove to a third party
that you have an approved TCPA chip. Most applications do not have this need, and this
certification is not currently supported with IBMs chips. If you want to do an application that
needs such a certificate, the TCPA has an endorsement key that can be used to get a suitable
certificate. The only way this can work is if someone, like the manufacturer, has recorded a given
TCPA chips public endorsement key, and can use this knowledge to certify identity keys from
the given TCPA chip. This is not required, and software access to the endorsement key can be
disabled. There is certainly a privacy aspect of access to the endorsement key, as it uniquely
identifies the platform, and the TCPA specification goes to great lengths to allow for anonymous
certification. The best defense for privacy conscious users is simply to turn off the endorsement
key."
[^] # Re: Controle du système d'information
Posté par TSelek . Évalué à 3.
Bon, sur ta remarque :
1/ certificats <> clés privées, donc ta citation m'avance guère (certifs -> clés publiques)
2/ TCPA c'est une norme, donc les implémentations ont encore de la marge en termes de fonctionnalités...
3/ root authority <> fab authority (à la rigueur vaudrait peut-être mieux une root authority...)
4/ The only time a certificate is needed is if you want to be able to prove to a third party that you have an approved TCPA chip. Most applications do not have this need oui mais pour combien de temps ? Parce qu'aujourd'hui, de telles applicattions ne courrent pas les rues, mais demain avec Palladium ?
ça peut-être un bon système en soi, qu'il ne soit pas perverti j'ai du mal à le concevoir...
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Yannick . Évalué à 10.
Dans TCPA, je voyais l'avantage d'avoir une clef "en dur" que l'on ne pouvait pas dérober (à moins de piquer mon ordinateur !).
Je trouve que dire que la clef a peut-être été copié avant qu'on me vende l'ordinateur frise le mode parano ; par contre, le problème de la révocation me semble très important :
- le concepteur de la puce pourrait révoquer ma clef : c'est encore un peu proche du mode parano mais beaucoup moins (surtout par les temps qui courrent :-( )
- on me vole mon ordinateur : je vais comment pour révoquer ma clef privée (pas parano du tout !).
Je présume que le système prévu est que l'on pourra faire opposition sur un ordinateur comme on fait opposition sur une carte bleue.
Finalement, ce qui serait pas mal, ce serait un TCPA où on peut mettre sa propre clef GnuPG !
Yannick
PS :
- Allô, comment faut-il faire pour faire opposition sur un ordinateur TCPA ?
- Il faut nous envoyer le formulaire d'opposition, signé avec votre identifiant TCPA pour que l'on soit sûr qu'il vient de vous.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Vanhu . Évalué à 2.
Euh... on me paye pour etre parano :-)
Et une clé PRIVEE, bah ca doit etre privé !!!
Mais apparemment, d'apres un autre post la au dessus, c'est encore moins simple qu'il n'y parait.....
Finalement, ce qui serait pas mal, ce serait un TCPA où on peut mettre sa propre clef GnuPG
Euh, ouais, enfin le concept de PGP/GPG est encore un peu différent, y'a pas de notion de "root of trust", seulement de confiance mutuelle......
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par TSelek . Évalué à 3.
et oui la parano c'est un métier, d'ailleurs moi je ne code même plus... que de la parano. mais bon quand on sait ce que les autres ne savent pas ou croient impossible, ça change les perspectives.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Vanhu . Évalué à 4.
Mhhh .... tu dis ca pour essayer de gagner ma confiance ? :-)
la parano c'est un métier
Entièrement d'accord: les "paranos amateurs" se laissent guider par leur parano.
Les "paranos pros" sont paranos, certes, mais sont aussi des pros....
La différence ?
Le second ne se laisse pas dominer par sa parano......
mais bon quand on sait ce que les autres ne savent pas ou croient impossible, ça change les perspectives.
Oui.
Et c'est d'ailleurs pour ca que j'essaie de faire de "l'éducation" quand je peux, par des explications parfois, mais le plus souvent par des démos simples (le sniff des mails entrant/sortant, c'est tout bete, mais comment c'est efficace :-).
A quand un site de "vulgarisation" de la parano, qui montre clairement, avec explications à l'appui, sans sombrer dans la "mauvaise parano", pourquoi il faut quand meme etre un peu parano ?????
Je suis volontaire pour co-animer ce paranofr.org :-)
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par TSelek . Évalué à 2.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Jak . Évalué à 10.
Ben, comme le fait remarquer Tselek, ce que nous vantent les défenseurs du TCPA, du point de vue technique, ce sont des choses que l'on peut déjà faire en se dotant du matériel adéquat, cette technologie n'apporte donc rien, à part le fait que ce n'est plus toi qui maîtrise totalement ton système de sécurité (tu ne peux pas choisir ton OS, ni même forcément ton matériel : tu dois faire confiance à quelqu'un d'autre).
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par XHTML/CSS inside (site web personnel) . Évalué à 2.
C'est toujours pareil, Einstein ne pensait pas forcément à ce qui se passerait quand il a imaginé la puissance du nucléaire, le gars qui a inventé le couteau ne pensait pas forcément à toutes les utilisations de cet outil...
Maintenant, je me pose une question : qu'est-ce qui me prouve irréfutablement qu'ils ne vont pas utiliser ça contre ma vie privée ?
Pour l'instant, je n'ai pas l'impression que cette technologie est complètement innocente => d'où mon refus.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par tene . Évalué à 0.
Tu nous fais de la parano là? ;-)
C'est impossible, et ce pour tous, par exemple, ton IP est sauvegardée quand tu postes un commentaire ici, prouve moi de façon irréfutable qu'elle ne va pas être utilisée d'une façon ou d'une autre pour atteindre le but ultime du complot mondial contre ma personne?...
Tout peut-être utilisé contre ta "vie privée" (faudrait encore définir la limite entre vie privée et le reste, mais bon)...
Pour l'instant, je n'ai pas l'impression que cette technologie est complètement innocente => d'où mon refus.
En suivant le même raisonnement, ne postes plus ici, déconnecte toi du net, etc... ;-)
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par gege . Évalué à 3.
??? C'est vrai ?
Si oui, l'adresse IP est considérée comme information personnelle, et est donc régie par la loi informatique, fichiers et liberté. Donc déclaration obligatoire à la CNIL, et surtout information de l'utilisateur (je la vois nulle part cette information) ! Donc si c'est effectivement le cas, linuxfr est dans l'illégalité !
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par cmotsch . Évalué à 3.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par scylla . Évalué à 4.
Si si au moment où tu as posté, sous le bouton "Envoyer" :
Votre adresse IP sera sauvegardée, elle ne sera pas affichée sur le site, mais elle nous permet de pouvoir prévenir tout abus.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Tonton Th (Mastodon) . Évalué à 1.
??? C'est vrai ? Si oui, l'adresse IP est considérée comme information personnelle,
Ben ça fait longtemps qu'on sait que les IP sont logguées sur dalfp, et personnellement, ça ne me gene pas. Je n'ai rien à cacher
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Benoît Sibaud (site web personnel) . Évalué à 1.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par TSelek . Évalué à 2.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par XHTML/CSS inside (site web personnel) . Évalué à 1.
C'est impossible, et ce pour tous, par exemple, ton IP est sauvegardée quand tu postes un commentaire ici, prouve moi de façon irréfutable qu'elle ne va pas être utilisée d'une façon ou d'une autre pour atteindre le but ultime du complot mondial contre ma personne?...
Entre sauvegarder mon ip juste pour éviter qq abus (bien que la déclaration à la cnil soit obligatoire), et réellement s'immiscer dans ma vie privée, il y a quand même de la marge non ?
J'ai l'impression qu'avec cette tech, il n'y aura plus de diférence entre la personne honnête et celui qui pirate à tout va.
En gros c'est "on scanne votre hd pour vérifier qu'il n'y a pas de logiciels illicites mais on n'a pas dit que l'on n'allait pas chercher autre chose tant qu'on y est..."
(c'est une impression personnelle)
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Jean Roc Morreale . Évalué à 2.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par modr12 . Évalué à 2.
tssss Einstein savait la preuve est la lettre adréssé a Roosevelt
http://occawlonline.pearsoned.com/bookbind/pubbooks/nash5e_awl/medi(...)
il a regrétté cette lettre plus tard
# Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Benjamin (site web personnel) . Évalué à 3.
Continue comme ça à surveiller la bête.
# Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par gosseyn . Évalué à 7.
http://www.notcpa.org/(...)
# Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Christophe Morvan (site web personnel) . Évalué à 3.
http://morvan.nerim.net/tcpa(...)
Naturellement je suis à la disposition de l'auteur toute modification.
# Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Quzqo . Évalué à 3.
cette clé unique est pire qu'un simple numéro unique (retiré par Intel de ses processeurs, après des appels au boycott), car elle ne peut pas être contrefaite
Un peu à l'image des adresses MAC, identifiant de manière unique un hôte sur le réseau : je ne trouve pas cela plus choquant que ça... Est-ce pour se réserver l'anonymat <=> immunité ?
Un jour ou l'autre, l'utilisation de cette clé sera exigée par les softs DRM ...
Il ne s'agit ici que de l'emploi, via l'OS, qui peut/pourrait en être fait pas d'une capacité intrinsèque de la puce... En outre, la possibilité offerte de restreindre l'accès au seul "propriétaire" (i.e ordinateur) peut être souhaité par ce dernier : à voir donc comme une fonctionnalité offerte (?)
INFO 2 :
être confrontés à des fichiers (documents ou programmes) encryptés sous Windows et inutilisables sous Linux...
Là encore il s'agit de l'utilisation qui pourrait en être faite, rien de plus... En outre, il arrive un moment où il faut choisir : si on passe son temps à "taper" sur Windows, il est difficillement défendable de dual-boot"er" sur cet OS...
Enfin, à supposer que ce cauchemard se réalise, ne pouvoir relire/modifier un document qu'exclusivement sur l'ordinateur et l'OS d'origine, c'est tout simplement la mort de la communication au moyen de l'outil informatique : soyons réalistes...
NDLR : personnellement, je suis un des utilisateurs de dual-boot
Notons aussi que des outils libres comme tripwire permettent de s'assurer en bootant à partir d'une disquette ou d'un CD-rom qu'un OS n'a pas été modifié par un virus ou par un cracker ...
Je doute que l'utilisation de tels logiciels soit effective pour des données personnelles.
INFO 3 :
impossibilité de contrôler le code qui est dans les puces TCPA
D'accord sur le fond, mais :
Des chevaux de Troie ou des failles pourraient être introduites dans ces puces sans que les utilisateurs le sachent.
...pas plus qu'avec des exploits potentiellement non connues et/ou non publiées par l'éditeur d'un logiciel (surtout propriétaires car, ici, le problème est de cet ordre propriétaire/libre).
Quant à il n'est pas prévu dans les specs de pouvoir changer ces algorithmes si une nouvelle faille est trouvée
Je ne pense pas que cela soit dans l'intérêt du constructeur. Si l'un ne l'autorise pas, d'autres proposeront la mise à jour de la puce. (ou peut-être suis-je naïf ?)
Aucun des algorithmes de cryptage utilisés dans les specs TCPA n'a été démontré comme étant incassable (par une preuve mathématique)...
Existe-t-il un algorithme incassable ? j'en doute...
INFO 4 :
TCPA inclut un mode "extend" qui permet de s'assurer que seul un OS signé pourra être booté
Sur ce point, il est vrai que l'aveu implicite est pathétique et constitue une négation de nos droits élémentaires. De plus, cette fonctionnalité est déjà remplie par le BIOS / Firmware / Hardware sur les solutions actuelles.
INFO 5 :
Pas compris les * conséquences : OS non signés / extend abandonné / ...
INFO 6 :
roots of trust ce qui est somme toute la pierre angulaire de cette technologie : est-ce surprenant ?
Quant à l'activation framework de Windows XP, même si ce procédé est gênant pour une majorité de non-détenteurs de licences Windows mais utilisateurs tout de même, ce n'est jamais qu'un moyen pour l'éditeur de faire respecter son droits. Que l'on soit d'accord ou pas ne change rien sur le fond : l'éditeur (en l'occurence Windows) est dans son droit, l'utilisateur sans license non.
Bref, au moins pour toutes les raisons ci-dessus, je refuse fortement d'avoir des puces ou des softs TCPA ...
Au moins il existe des plate-formes alternatives et pour le numéro unique, un conseil, débranche ta carte réseau.
En résumé, je trouve cet article intéressant sur bien des points mais l'aspect critique est trop souvent ignoré au profit de certains amalgames qui ne servent aucunement le sujet.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Christophe Morvan (site web personnel) . Évalué à 3.
En ce qui concerne ce point, ça n'a rien à voir, dans la mesure où le numéro de la carte réseau peut être altéré de façon logiciel. Ce qui ne doit pas être le cas pour TCPA.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Quzqo . Évalué à 1.
Tout à fait d'accord... lorsque je parlais de débrancher sa carte réseau, il s'agissait de s'isoler du reste du monde : cela aurait tout aussi bien pu être un modem ou une antenne wifi...
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 7.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Quzqo . Évalué à 0.
1. Ce droit n'est pas implicitement nié ici, pas plus que ton droit à accéder / rectifier les informations collectées.
2. Accessoirement, ce fichage existe déjà. Le fait que ce soit "limité" à ton banquier, ton médecin ou ton revendeur de voitures est-il plus sécurisant ?
Je ne vois de ta part, ici, qu'un procès d'intention à l'égard des éditeurs de logiciels...
la plupart des constructeurs adhèrent à tcpa
Dans l'absolu, la plupart des utilisateurs (informatique personnelle) préfèrent/se voient imposer Windows... Est-ce pour cela qu'il n'existe pas d'alternative ? Sur cet argument donc... nous avons aussi le choix.
Rien à voir entre libre et propriétaire
Tu détournes mon propos : il s'agissait juste d'associer opacité de la puce avec celle du code des logiciels propriétaires et de l'opposer au libre.
Bon je vais pas passer mon temps à répondre au reste c trop GROS
C'est tout à fait selon ce shéma que l'on favorise l'échange de point de vues... Ton avis est-il tellement clairvoyant et implicite qu'il te dispense d'argumentaire ?
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
2. Accessoirement, ce fichage existe déjà. Le fait que ce soit "limité" à ton banquier, ton médecin ou ton revendeur de voitures est-il plus sécurisant ?
Je ne vois de ta part, ici, qu'un procès d'intention à l'égard des éditeurs de logiciels...
Tu te fou de qui ? Les medecins ont un code qui leur interdit de divulgué une quelconques informations sous peine d'être interdit d'exercer. Ton banquier a une interdiction formelle de vendre leur fichiers de données perso. Ton vendeur de voiture essait d'avoir un maximum d'info mais il n'a pas le droit de faire n'importe quoi.
Les gens ont le droit de se protéger, mais avec un identifiant généralisé comme une endorsement key tu ne pourras plus seulement effacer le cookie.
Ton propos ressemble a du gros FUD : "regarder on vous nique par ailleurs pourquoi pas par ce coté là aussi"
"La première sécurité est la liberté"
[^] # (haussement d'épaules)
Posté par Quzqo . Évalué à 1.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Point...
Posté par Quzqo . Évalué à 0.
Si avoir un minimum d'ouverture d'esprit (quitte à se faire parfois l'avocat du diable) ne revient à tes yeux qu'à entretenir des UF's alors oui, définitivement, nous ne parlons pas la même langue... ce que reflète en substance ton argumentaire.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Nim . Évalué à 2.
> Existe-t-il un algorithme incassable ? j'en doute...
A l'heure actuelle, ca existe avec une longueur de clé égale à celle des données.
(super pratique :))
-1 HS / au sujet
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par free2.org . Évalué à 1.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Moby-Dik . Évalué à 1.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par free2.org . Évalué à 1.
quand à garder secrète la clé privée, c'est le problème de TOUS les algorithmes de cryptage. Une passphrase peut aider. Un coffre-fort dans lequel tu mets le Cd quand tu ne t'en sert pas aussi.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Moby-Dik . Évalué à 1.
Si tu utilises une passphrase pour chiffrer ton masque jetable parce que tu ne sais pas stocker celui-ci de façon sûre, c'est l'algo de chiffrement utilisé en conjonction avec la passphrase qui deviendra le maillon faible (sauf si la passphrase est trop courte bien sûr). Donc autant abandonner directement le masque jetable et partager plutôt la passphrase avec ton correspondant.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par free2.org . Évalué à 1.
c'est mieux que une passphrase seule
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Moby-Dik . Évalué à 1.
# Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Kibos . Évalué à 6.
Il faut savoir qu'une part très importante du CA de Micro$oft et dans une moindre mesure des fabricants de matériel concerne les PME. Comment imaginez-vous qu'une PME puisse se passer de pouvoir compiler un programme et de l'exécuter ?
Un exemple : je peux très bien réaliser un encodeur MP3 en VisualBasic sous excel (ça me ferait mal mais c'est possible). Va-t-il falloir une licence pour lancer des scripts VisualBasic sous excel ? Quelle PME pourra se passer de lancer des scripts sous excel (ou tout autre type de programme "maison") ?
Vu le coût de la licence permettant de lancer ses propres programmes, je ne pense pas que l'on puisse trouver ne serait-ce qu'une seule PME qui pourrait se le permettre. Ils auront beau faire toute la pub qu'ils voudront, quant une boite aura acheté un ordinateur à base de TCPA et qu'elle verra qu'elle ne peut pas travailler dessus, elle le fera savoir et elle n'en achètera pas d'autres.
[^] # TCPA n'est pas Palladium ...
Posté par b0z0 . Évalué à 1.
En tout cas, ça fait plaisir de voir que quelqu'un a réellement lu les spés TCPA avant d'en parler, ça nous change un peu :-) Pour ce qui est de Palladium, sans rentrer dans le détail, il y a pas mal de différences de fond avec TCPA et le système est entièrement distinct. Il semblerait d'ailleurs que Microsoft prépare un whitepaper à ce sujet, affaire à suivre. D'autre part, il se pourrait bien qu'il y ait un article à ce sujet dans un prochain numéro de MISC ...
[^] # Re: TCPA n'est pas Palladium ...
Posté par free2.org . Évalué à 1.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par tene . Évalué à 2.
En fait euh... si qq avait un truc un tout petit peu officiel, expliquant clairement que TCPA vise à controller tous ce qui s'exécute sur la machine? parce que dans beaucoup de thread, certains partent de ce point de vue, et je n'ai jamais rien lu à ce sujet...
Tous ce que je vois pour l'instant, page 4 de http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf(...) , c'est des trucs du genre: "There is no such thing as TCPA certification of code; this is pure invention." et page 7:
"TCPA does not:
- control execution
- block execution based on signatures, or revocation lists, or approved lists"
Et enfin, je me demande pratiquement comment, si c'était quand même le cas, controller l'exécution et même maintenir une liste d'approbation et de réfutation, quelle taille ça prendrait?
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par b0z0 . Évalué à 1.
Pour ce qui est de maintenir la liste d'approbation/réfutation, d'après les spés, tout n'est pas stocké dans le TPM (le Trusted Platform Module, plus ou moins la racine de confiance du système) : une partie peut être stockée à l'extérieur, bien entendu chiffrée, et accessible uniquement par le TPM. Cela résoud les problèmes de place.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Je comprends l'utiliter de vérifier une partition de boot (en mettant sois même le hash du boot dans le TCPA) mais je comprends beaucoup moins l'interret de vérifier les périphériques PCI par exemple.
"La première sécurité est la liberté"
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Matthieu Moy (site web personnel) . Évalué à 1.
En ce qui concerne les architectures de DRM actuelles de Microsoft, un dispositif de control de l'execution des programmes existe deja.
Voir la news "Devinez qui viens fouiller chez vous ce soir" en premiere page de linuxfr.
Palladium sera visiblement une generalisation de ce concept.
Maintenant, sur les differences entre TCPA et Palladium, j'aimerais y voir plus clair.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par TSelek . Évalué à 2.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
TCPA est une périphérique de plus qui a accès au bus du processeurs pour faire ses mesures.
Palladium inclue un ring -1 controlé par un soft de MS, le nucleus (?), une sorte de micronoyau qui peut caché des pages de mémoires mêmes à l'OS qui est en dessous. C'est encore plus bas niveau et intrusif que TCPA. Cela pourrait aussi tourné sous linux.
Le but est de faire une protection mémoire même contre les OS. Et pas seulement pour les programmes entre eux.
"La première sécurité est la liberté"
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par b0z0 . Évalué à 2.
Donc non, ce n'est pas plus bas que TCPA, mais ça inclut une couche hard de même niveau que celle de TCPA - et, à terme, compatible.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par TSelek . Évalué à 1.
J'ai du raté une étape... :)
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Nicolas Boulay (site web personnel) . Évalué à 1.
Disons que ce n'est pas parceque c'est du soft bas niveau que c'est de l'OS.
TCPA est une puce à "coté" du système, une puce de carte à puce qui peut aussi espionner ce bus et décider de se désactiver si cela ne va pas.
Palladium rajoute une couche logicielle et notament pour la MMU qui rajoute un niveau de gestion inaccescible pour les OS. Mais ce code sera intégré au bios des cartes, je pense. Ce code controle le système en entier, et surtout permet de le partitionner de manière forte. (j'imagine un virus à l'interrieur ! Aucun antivirus n'y pourra rien... même pas un debuggeur...)
"La première sécurité est la liberté"
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par b0z0 . Évalué à 1.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par b0z0 . Évalué à 1.
Certes, à la base, TCPA fournit essentiellement des spécifications matérielles, ainsi que des lignes directrices pour l'implémentation sur diverses architectures (ils ont au moins sorties celles pour les PC). A partir de là, en effet, libre aux développeurs d'OS d'utiliser ces fonctions à leur guise. Pour l'instant, ça se présente surtout sous forme d'une puce que les fabricants de cartes mères peuvent inclure sur leurs produits.
Palladium, quant à lui, inclut une définition des couches logicielles comme des couches matérielles, même si l'accent est plus sur le logiciel. La couche matérielle de Palladium, elle, se présentera de la même façon que celle de TCPA, mais en diffère pour l'instant, essentiellement parce que la version 1.1 de TCPA ne satisfaisait pas Microsoft au niveau des fonctionnalités apportées. D'après ce qu'ils disent, en revanche, la version 1.2 de TCPA (non encore disponible) devrait pouvoir être utilisée comme couche matérielle avec Palladium. En d'autres termes, les deux projets, qui avaient pas mal divergé, sont en train de converger plus ou moins à nouveau.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par TSelek . Évalué à 1.
mdr, pourquoi tu cries Faux! si c'est pour te tirer sur le pied juste après ?
je te relis :
1/ TCPA -> puce, hardware
2/ Palladium -> couches, dont la PHY converge vers TCPA (ou l'inverse)
j'en déduis que si MS a spécifié une couche matérielle dans Palladium c'est pour faire le forcing envers TCPA, et que de toutes façons les gens du hard feront le hard, donc du TCPA, et les gens du soft feront le soft, donc Palladium...
Pour moi, en terme de couches, le hard reste en dessous du soft... CQFD.
Autrement dit, je ne crois pas comme toi qu'Intel, ni même personne d'autre dans ce milieu, est prêt à obéir les yeux fermés à MS.
De plus, si on a bien TCPA = couche basse de Palladium, donc MS, je vois mal IBM dans le coup...
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par b0z0 . Évalué à 0.
Ensuite, je n'ai jamais dit qu'Intel, ou AMD (ou Transmeta :-) obéirait les yeux fermés à MS. Par contre, si MS veut faire insérer des SSC (la partie matérielle de Palladium) sur les cartes mères dans des PC, je pense qu'ils ont facilement les moyens d'inonder le marché de cartes mères modifées.
Ah, un dernier truc ... tu vois mal IBM dans le coup? Tu sais que Microsoft et IBM sont deux des membres fondateurs du TCPA?
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par TSelek . Évalué à 1.
j'ai toujours du mal à croire qu'IBM est prêt à aider MS à conforter son monopole.
de plus TCPA ou SSC ne peuvent qu'être dans le chipset ou le CPU, pas le choix, donc là c'est Intel/Via/SiS/etc. Pas MS.
question de bon sens.
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par b0z0 . Évalué à 1.
Pour les parties matérielles, pour TCPA, ça se présente (pour l'instant) sous forme de puces séparées que les fabricants de cartes mères peuvent intégrer, comme Atmel avec son TPM AT97SC3201 (http://www.atmel.com/atmel/acrobat/2015s.pdf(...) ).
Sinon, quand je dis que je pense que Microsoft peut imposer ça, c'est aussi une question de bon sens. S'ils ont réussi à forcer l'achat de Windows avec tous les PC neufs, je pense qu'ils ont les moyens de pousser les fabricants de cartes mères à intégrer un SSC pour Palladium. D'autant plus qu'il semble (indépendamment des problèmes de respect de la vie privée) qu'il y ait des gains de sécurité potentiels intéressants. Combien de fabricants refuseront d'ajouter des fonctionnalités nouvelles, d'après toi? Ceux qui refuseront prendront le risque de se retrouver largués par la concurrence ...
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par TSelek . Évalué à 1.
# Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Geo Vah . Évalué à 2.
est-ce qu'une machine non TCPA aura accès a des données destinés à des machines TCPA voir accéder à un réseaux TCPA ?
Car si on doit tous se racheter des machines TCPA parce que Windows version TCPA sort et investi 80% du marché avec les consommateurs lambda (bah oui comme d'hab, le mec qui va au carrefour du quoi acheter un PC il se moque totalement de la technologie....) pour pouvoir communiquer (j'entends par la tous simplement echanger des fichiers entre nous...)
Reste à avoir des machines non TCPA, peut etre que la solution viendra de VIA qui dans sa derniere puce C3 n'a pas intégré cette technologie avec un petit linux non TCPA dessus.... Ainsi ici le libre est la seule alternative à un OS TCPA (qui de MacOS d'ailleurs ?)
[^] # Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par gourgou . Évalué à 3.
Car si on doit tous se racheter des machines TCPA parce que Windows version TCPA sort et investi 80% du marché avec les consommateurs lambda
Effectivement, là, on aurait un souci. Cela dit, pour que le réseau tombe sous la coupe de TCPA, pour qu'on n'y ait plus accès avec nos chers OS libres, il ne suffirait pas que les autres extrémités (les lambda) se fassent avoir. Il faudrait aussi que la majeure partie des intermédiaires fasse la migration. Et là, je demande : est-il vraisemblable d'imaginer que tous les FAI acceptent, sans plus y réfléchir, de mettre leurs routeurs sous le contrôle plein et entier d'un petit regroupement de déjà-très grosses boîtes ? (Parce que c'est gentil de tapper tout le temps sur les mêmes, mais MS n'est forcément pas tout seul dans l'affaire...)
(Allez, pour se marrer, en vitesse : j'ai eu sous les yeux un argumentaire assez récents pour ".NET" (comprendre windows 2003, basiquement, à ce qu'il paraît), et je suis MdR à chaque fois (parce qu'ils insistent) que je tombe sur : "possibilité de faire un cluster, jusqu'à huit machines !"...)
# Ma carte mère vient de griller...
Posté par Tonton Th (Mastodon) . Évalué à 9.
[^] # Re: Ma carte mère vient de griller...
Posté par gourgou . Évalué à 2.
"Please, feel free to buy online our brand new "WinWhatever to Win_Next-Generation_Secure_Computing_Base SP1.exe" !
<veryverysmall>Et en l'appliquant, on récupère aussi tout le contenu de votre disque... pour analyses ultérieures, quoi. C'est même pour ça qu'on vous le met pas sur un CD...</veryverysmall>"
[^] # Re: Ma carte mère vient de griller...
Posté par cornofulgur . Évalué à 8.
* conséquences : il faut envisager des sauvegardes et des procédures de remplacement.
* méthodes :
- Indiquez le Coût et le Temps Moyen Entre Pannes pour
. une clef usb externe :
. une pupuce tcpa onboard :
. une pupuce tcpa inside the processeur :
- Quelle est la procédure préventive à suivre permettant de faire face à une éventuelle panne
. d'une clef usb externe :
. d'une pupuce tcpa onboard :
. d'une pupuce tcpa inside the processeur :
- J'ai une panne matérielle. Quelle est la procédure à suivre dans le cas
. d'une clef usb externe :
. d'une pupuce tcpa onboard :
. d'une pupuce tcpa inside the processeur :
- Je crains une panne imminente et je souhaite changer de materiel. Quelle est la procédure à suivre dans le cas
. d'une clef usb externe :
. d'une pupuce tcpa onboard :
. d'une pupuce tcpa inside the processeur :
[^] # Re: Ma carte mère vient de griller...
Posté par tene . Évalué à 1.
[^] # Re: Ma carte mère vient de griller...
Posté par iug . Évalué à 4.
<Pas content>
Je me permet une critique de l'article. Dans la guerre de l'information que nous menons contre MS et autres, il me semble qu'on devrait bien faire attention aux arguments qu'on utilise. Si, dans une argumentation on donne n arguments et que parmis eux il y en a des foireux, même si les autres démontrent qu'on a raison, l'adversaire va se focaliser sur les arguments foireux pour gagner la bataille. Je pense que l'argument du cheval de troie... est foireux. Les deux arguments de l'impossibilité de choisir ses softs, et de perte de ses données en cas de panne sont bien meilleurs. Le dernier est en plus valable pour les utilisateurs de Windows. L'argument de la non utilisation est lui-même peu intéressant : la plupart des gens s'en foutent car ça ne change rien à leur vie (je parle là de beaucoup d'utilisateurs de Windows).
On devrait se focaliser sur l'argument de perte des données en cas de Panne.
[^] # Re: Ma carte mère vient de griller...
Posté par cornofulgur . Évalué à 1.
L'argument du cheval de Troie par contre n'est pas foireux.
You can generate private keys, use them to sign, and decrypt, and seal/unseal data under PCRs, all without any certificates.
On aurait tendance à penser que "You" désigne l'utilisateur. Mais en fait c'est n'importe quel programme local et éventuellement distant qui va pouvoir demander à accéder à ces fonctions tcpa. Le programme est obligé de demander l'autorisation à root, certes. Mais cette demande n'est pas fair play. On entends ca: s'il te plait root, donne moi les droits d'avoir mon identité, de crypter, de te cacher des choses.
Le processus n'explique pas pourquoi il demande ca. Quand un soft demande d'acceder à une carte son ou au réseau, root peut se douter de quelque chose, prendre ces précautions. Dans le cas de tcpa, c'est impossible.
Ca ressemble bougrement à "je suis un DOCument, clique moi".
# PPC970
Posté par Jean-Marc Leroy . Évalué à 0.
Une raison de plus d'attendre le nouveau processeur PPC970 d'IBM.
A moins bien entendu que ces braves merdes n'en fassent également partie...
[^] # Re: PPC970
Posté par Jean Roc Morreale . Évalué à 2.
# Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Xavier Teyssier (site web personnel) . Évalué à 2.
Ben moi, ce que je voudrais bien savoir, c'est :
- Comment, dans l'OS, se concretise la signature
- et surtout : QUI signe les OS ?
# Demontage en regle
Posté par Jerome Herman . Évalué à 2.
- *info 1: au moment de la fabrication il est inséré une clé privée asymétrique unique dans chaque puce TCPA
"the endorsement key" "uniquely identifies the platform" au bas de la page 4 de http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf(...)
IBM dit que c'est pour des problèmes de vie privée qu'ils ont pris la décision que l'accès à cette clé peut être désactivé dans les puces IBM actuelles. Cette décision interne d'IBM est la confirmation que la norme TCPA n'oblige pas à fournir la possibilité de désactiver cette clé (désactivation qui n'est faisable que si les softs et documents DRM dont on a besoin n'obligent pas à utiliser cette clé)
*conséquences de cette info: cette clé unique est pire qu'un simple numéro unique (retiré par Intel de ses processeurs, après des appels au boycott), car elle ne peut pas etre contrefaite (elle est authentifiable car elle seule peut décoder des messages cryptées avec sa clé publique associée). Un jour ou l'autre, l'utilisation de cette clé sera exigée par les softs DRM (donc fermer l'accès à cette clé impliquera de ne pas pouvoir utiliser ces softs pour encoder/décoder) pour que seul un ordinateur précis puisse accéder à un fichier protégé par DRM, pour un temps précis en fonction de ce qu'a payé l'utilisateur de l'ordinateur, et des techniques de watermarking pourront être utilisées par ce soft DRM pour savoir si ce PC a fait une copie en utilisant des techniques analogiques et l'a envoyé à d'autres PCs.
Outre le fait que la EK ne soit pas du tout obligatoire, je pense qu'il est bon de rapeler comment cette clef est cree et utilisee :
Le constructeur de la puce ou le constructeur de la carte creent une clef de cryptage. Il est bon de noter que cette clef n'est pas utilisable.
Si on le souhaite on peut demander a un organisme tiers de creer un certificat base sur cette clef(NB l'organisme ne recoit pas la clef mais valide le certificat par un principe de challenge, il ne connait jamais la clef d'endossement). Une fois cree c'est le certificat qui est exploitable. On peut sur une meme puce cree autant de certificats differents que l'on veut. Bien entendu cryptographie oblige il est impossible d'associer une certificat avec la clef d'endossement. On peut ensuite se servir du certificat ainsi cree pour s'authentifier aupres de site. Etre identifie a partir du certificat (qui est la seule info qui a le droit de transiter) implique que la personne qui a cree la puce et la personne qui a valide le certificat sont une seule et meme entite. De plus pour pouvoir vous pister il faut aussi que ce soit la personne chez qui vous utilisez le certificat. Bien que ce risque ne soit pas nul, il est de tres loin inferieur a celui des numeros de serie chez Intel. Ce n'est donc pas pire, c'est nettement mieux. Il est bon de rappeler que la norme TCPA interdit aux producteurs de puces d'etre des organismes certificateurs.
*info 2: il est possible pour un OS d'utiliser TCPA pour crypter certains documents et interdire aux autres OS d'accéder à ces documents
"if an attempt is made to boot an alternative system" "the unseal will fail, thus protecting the data" bas de la page 4 de http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf(...)
*conséquences: tous les utilisateurs de dual-boot (par exemple Linux et Windows sur le meme ordinateur) pourront bientot etre confrontés à des fichiers (documents ou programmes) encryptés sous Windows et inutilisables sous Linux: les documents ne seront donc pas ouvrables par openoffice, et les programmes ne seront donc pas exécutables par wine.
Notons que sous Linux et Windows il est deja possible de protéger par une passphrase certains documents ou certaines partitions. La différence est que cette passphrase est stockée dans le cerveau de l'utilisateur qui peut donc l'utiliser avec l'OS de son choix, pas dans une puce TCPA qui refusera à un OS alternatif de l'utiliser.
Notons aussi que des outils libres comme tripwire permettent de s'assurer en bootant à partir d'une disquette ou d'un CD-rom qu'un OS n'a pas été modifié par un virus ou par un cracker (pas besoin de TCPA pour cela donc)
enfin des outils libres de sécurité comme LinuxSecurityModule, systrace, fireflier, permettent de s'assurer que certains fichier du système ne pourront aps être accédés par des programmes qui communiquent avec internet (limitant par là meme les dégats que peuvent causer un virus ou un cracker)
Je passe sur la derniere partie (oui il est possible de faire en logiciel tout ce que fait TCPA en hardware) pour me focaliser sur le systeme d'encription de boot.
La puce TCPA possede un systeme qui lui permet de hasher un boot et de stoquer des clefs dans ce hashage. Si le boot n'est pas rigoureusement identique, le hashage change et les clefs sont impossibles a recuperer.
Si j'encrypte mes doccuments sur un hashage de boot et que je boot differement mes doccuments cryptes ne sont plus disponibles. Effectivemnt si je boot sous linux je n'ai plus acces a mes doccuments . C'est aussi le cas si j'upgrade mon bios, si je patch mon os ou si je change ma carte graphique. Ce systeme est extrememnt limitatif. Tout changement dans la phase de boot entrainne un lock de mes fichiers. Je vous laisse imaginer les problemes que cela creerait si jamais la sauvegarde par defaut etait basee sur ce systeme. De plus il faut ajouter que si mon ordi a les droits pour creer une clef (ie si windows peut forcer l'enregistrement en crypte de mes fichiers en fonction du hashage du boot), alors il a aussi les droits de deplacer ces clefs via un systeme de migration. Donc meme si il y a encryptage sans que je le sache de mon fichier, je peut toujours sortir la clef du coffre depuis windows et la mettre a un endroit ou elle sera accessible depuis linux. La migration et le bind d'une clef ne sont pas des operations faciles, mais c'est tout a fait possible.
*info 3: impossibilité de controler le code qui est dans les puces TCPA
contrairement aux softs libres de sécurité comme LSM/tripwire/fireflier/systrace, il est très difficile, voir impossible, d'aller controler le code qui sera stocké dans les puces TCPA .
Il est meme prévu dans la spec officielle de cacher au maximum le fonctionnement d'éléments comme le générateur aléatoire (qui est pourtant la base de la sécurité de tout cryptage)
"Intermediate results from the RNG are not available to any user. When the data is for internal use by the TPM (e.g., asymmetric key generation) the data is held in a shielded location and is not accessible to any user. " en haut de la page 13 de http://www.trustedcomputing.org/docs/TCPA_TPM_PP_1_9_7.pdf(...)
*conséquences: sécurité et obscurité ne font pas bon ménage. Des chevaux de Troie ou des failles pourraient etre introduites dans ces puces sans que les utilisateurs le sachent. Les algorithmes de sécurité et de cryptages évoluent au fur et à mesrure que de nouvelles failles sont trouvées: il n'est pas prévu dans les specs de pouvoir changer ces algorithmes si une nouvelle faille est trouvée. Aucun des algorithmes de cryptage utilisés dans les specs TCPA n'a été démontré comme étant incassable (par une preuve mathématique). La taille fixe de leur clé est incompatible avec l'évolution rapide des matériels et des techniques pour casser la crypto.
Bref, mieux vaut utiliser des logiciels libres de crypto évolutifs que des logiciels obscurs non évolutifs cachés dans une puce.
IL est effectivement impossible d'acceder aux etapes intermediaires de la generation de nombre aleatoire. Mais je ne vois pas comment on peut introduir eun cheval de troie dans une puce qui n'est justement pas reprogrammable, a moins bien sur que ce ne soit le constructeur lui meme qui l'y place. Autant je comprend le soucis qu'il peu y a voir a vouloir etre sur de la force de la clef, autant on ne possede a l'heure actuelle le code d'aucun composant de nos PC. Il pourrait deja y avoir des chevaux de Troie dans une foule des puces qui compose nos ordis. Pourquoi les mettre dans la puce TCPA ? De plus les specs ne font pas mention de quoi que ce soit dans ce genre. Pure speculation donc.
En ce qui concerne la force des clefs, il s'agit de clefs 2048 bits. Il est vrai que si le genrateur aleatoire est de mauvaise qualite, on entamme de beaucoup la force de cette clef, mais ca laisse encore pas mal de marge par rapport a des clefs 256bits.
*info 4: TCPA inclut un mode "extend" qui permet de s'assurer que seul un OS signé pourra être booté avec ce mode
"the OS kernel would have to be signed"
paragraphe 4 du document critique d'un des créateurs de TCPA http://www.cs.umd.edu/~waa/TCPA/TCPA-goodnbad.html(...)
document commenté par IBM comme étant très raisonable "most reasonnable" et sans nier l'existence du mode "extend" au bas de la page 4 de http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf(...)
*conséquences du mode "extend": tous les OS libres (noyaux + programmes systèmes) que l'on peut recompiler en totalité ou en partie ne seront plus utilisables avec TCPA après recompilation.
Voir plus utilisables du tout, même sous forme de binaires, si aucune version récente de l'OS n'est signée pour TCPA.
Alors la n'importe quoi !! Bien que les morceaux cites soient exacts, le sens est completement deforme. Premierement "Most reasonable" ne veut pas dire tres raisonnable mais le plus raisonable dans ce contexte. Le rebutal d'IBM s'attaque a plusieurs doccuments, la plupart ecrits par des web redacteurs mal informes, et un ecrit par un scientifique. Celui ecrit par le scientifique souleve des problemes tres justes qui pourraient se poser dans l'avenir, meme si actuellement la norme TCPA ne pose pas probleme.
En ce qui concerne le mode extend, le principe est le meme que le hashage de boot vu plus haut. Lorsque l'on place la puce en mode extend elle hashe l'integralite du boot(au lieu de juste des morceaux choisis). L'OS est alors "signe"=il est reconnu par le hashage integral du boot (oui ce n'est pas une boite exterieure qui signe l'OS, c'est la puce TCPA elle meme qui le fait lors de la demande de hashage en mode extend). Il est bon de preciser que
-1) TCPA ne peut pas empecher une machine de booter (cf tcpa rebutal) meme si l'OS n'est pas "signe" il bootera quand meme, le coffre a clef lui sera ferme, un point c'est tout.
-2)Il est impossible de signer un OS autrement que sur la machine meme. Le systeme de hashage de TCPA est extrement sensible au changement et a moins de posseder un ordinateur rigoureusement identique on ne peut pas creer de clef de hashage "transmissible" a une autre machine.
-3)En mode extend (ie on hashe tout ce qui nous passe sous la main au boot) le moindre changement entrainne la fermeture du coffre a clef. Donc on se retrouve avec le bon vieux problemes "tout ce qui est crypte est perdu" au moindre changement de bios/periph/OS. Pas top du tout.
*info 5: les specs n'interdisent pas l'ajout de fonctionalités supplémentaires par chaque constructeur dans leur puces de sécurité:
"it can be integrated into some existing component or components"
page 11 de http://www.trustedcomputing.org/docs/main%20v1_1b.pdf(...)
*conséquences: un PC à la norme TCPA ne sera donc pas une garantie que seules les fonctionalités de la norme TCPA sont dans ses puces de sécurité (ou dans son CPU)
ce PC pourra notamment interdire l'accès aux fonctions TCPA aux OS non signés (meme si le mode extend est abandonné dans les specs)
voir interdire le boot de tout OS non signé
N'importe quoi bis. Le fait de dire que l'on peut integrer la puce TCPA a un autre composant (ie la placer dans le CPU ou dans l'horloge), ne veut absoluemnt pas dire que l'on puisse
1-) devier en quoi que ce soit de la norme TCPA
2-) Ajouter des fonctions de controle dans la puce
3-) Permettre a la puisse d'interagir avec le processus de boot.
La puce TCPA regarde ce qui se passe sur un bus et dialogue via un port serie vec l'utilisateur ou l'OS. Mais elle ne peut pas interagir avec le bus qu'elle surveille. De plus il est toujours impossible a une societe exterieure de signer un OS pour qu'il soit compatible avec l'ensemble des puces. Parceque
1-) Il faut que le coffre a puce soit vide lors de la fabrication
2-) Compte tenu de la versatilite des systemes aujourd'hui, la seule facon de creer une clef de hashage de boot est de la creer sur l'ordinateur meme, ou sur une copie conforme. On ne peut pas creer un logiciel (quel qu'il soit) qui soit de base certifie TCPA, signe pour le boot. C'est techniquement impossible.
*info 6: Microsoft est le seul non fabricant de CPU à être membre fondateur de TCPA
cf "background" de http://www.trustedcomputing.org/tcpaasp4/index.asp(...)
et les specs TCPA commencent par une notion de "roots of trust" très similaire à l'activation framework de Windows XP
page 12 de http://www.trustedcomputing.org/docs/main%20v1_1b.pdf(...)
*conséquence: cette information est à rapprocher des condamnations anti-trust définitives dont MS vient de faire l'objet. Cela prouve que Palladium n'est pas la seule technologie de contrôle soutenue activement par MS. Palladium peut s'appuyer sur TCPA qui intègre déjà des notions de l'activation framework de XP.
L'argument qui tue : c'est mal parcequ'il y a Microsoft dedans. Deja Microsoft est dans tout c'est sa politique, mettre du windows dans le moindre fer a repasser d'ici 2010.
alors le trusted root (et non pas les roots of trust) est commun a l'ensemble des systemes de stockage de clefs privees, ou d'information confidentielles. C'est simplement le nom donne a une zone memoire, un repertoire, un fichier, un flux etc.. dont on connait tous les processus capables d'interagir. En d'autre termes un pertoire a la racine en chmod 7000 peut etre considere comme un trusted root.
Pour ceux qui ne savent pas ce qu'est l'activation framework de XP il s'agit de recuperer par telephone ou par connection internet une clef qui va debloquer votre windows. Sans cette clef XP refuse de fonctionner passe un delai de 30 jours (je crois). Peut on repliquer ce comportement avec TCPA ? Non !
Le but de l'activation framework d'XP est de verifier que vous vous etes enregistree vis a vis de Microsoft. C'est un principe tout bete de challenge/reponse. TCPA est capable d'etre challengee, mais pas d'initier un challenge. Elle est donc completement inutile dans ce systeme. Elle ne peut pas appeler Microsoft.
sécurité et obscurité ne font pas bon ménage
Information et obscurantisme non plus.
Kha
Lire les specs c'est bien, comprendre les specs c'est mieux.
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 2.
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 1.
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 1.
Pas vraiment impossible (N.B tout l'argumentaire est base sur la section 7 du doc d'IBM):
Migratory data may be copied to an arbitrary number of platforms, using the migration commands
provided. Non-migratory data may be moved to another platform only with the cooperation of a third party
(the manufacturer of the platform, or his representative), using the maintenance commands provided.
Mais ce n'est pas obligatoire. L'option de maintenance n'est pas forcement implementee et de plus elle peut etre detruite sur une puce qui la possede (TPM_KillMaintenanceFeature). cependant ne jubile pas trop vite voici la suite :
It must not be possible for the Owner of a key, even with the cooperation of the Owner of the TPM to migrate a non-migratable key from one platform to another. Since a key may be wrapped outside the TPM, it is necessary that non-migratable keys always be generated inside the TPM. It must not be possible for the Owner of a non-migratable asymmetric key, even with cooperation of the Owner of the TPM, to decrypt the contents of an encrypted bundle encrypted with that non-migratable asymmetric key.
Donc voila le possesseur de la clef ne peut pas migrer la clef meme avec l'aide du possesseur du TPM, les seules clefs non migrables doivent etre des clefs generes en interne, et il ne doit pas etre possible de decrypter des infos encryptes avec ce type de clef assymetrique. En d'autres termes ces clefs ne sont utilisables que par le TPM lui meme. Impossible de faire un mode challenge/reponse pour tester leur presence. Pour ceux qui se demandent a quoi peut bien servir une clef qui est prisonniere a l'interieur d'une puce, qui ne peut pas en sortir et qui ne peut meme pas interagir avec l'exterieur ? Et bien elle sert a la puce pour chiffrer les donnees qui se trouvent a l'interieur de la puce. En d'autres termes je peux crypter avec une clef non migrable une zone memoire de ma puce. Par contre toutes les clefs qui doivent interagir avec l'exterieur (ie tout ce qui n'est pas strictement a l'interieur de la puce) doivent etre migrables.
je crois que tu confonds "roots of trust" et TRUSTED ROOT ...
Non pas vrament, disons juste que l'un des deux designe une fonctionalite de TCPA alors que l'autre n'est qu'une facon de parler. C'est a dire literallement des bases de confiances. C'est du pur conceptuel ca recouvre les fonctions que TCPA se doit d'apporter. A savoir une fiabilite au niveau des mesures et une fiabilite au niveau du stockage.
à propos de "extend" j'aime bien la notion de software certifié par son fournisseur (shipper):
Je supose que tu parle de ca :
The TPM_Extend event is in response to loading a firmware or
software component for which a VE certificate was available. *Event
points to the VE certificate that shipped with the platform firmware or software (or discovered by other means). Size indicates the length of this structure. ExtendValue is the digest of the firmware, software or other code loaded. Certificates are much too large to put into the log in the Pre-OS environment. Validation of Certificates is unlikely in the Pre-OS environment. The event MUST point to a TCPA_EVENT_CERT structure.
Il s'agit donc de certificats qui ont ete envoyes (shipped) avec le fimware et le software de la plateforme (ou qui ont ete decouvert par d'autres moyen). Cela veut-il dire que MS va bientot sortir avec son nouvel OS le pack VE certificate-sinon-ca-marche-pas ? Non ca veut juste dire que le mec qui a monte mon PC (et eventuellement installe mon PC) peu eventuellement creer au passage des certificats. Ce ne sont pas des certificats generiques, mais des certificats crees au cas par cas sur les machines. Ces certificats, comme tout certificats PCR servent juste a s'assure que la sequence de boot n'a pas changee.
apprend a citer en entier, ca me ferait gagner pas mal de temps.
Note, however, that a disabled TPM never disables the extend capability. This is necessary in order to ensure that the PCR values in a TPM are always up-to-date.
Faisons un raisonement par l'absurde en supposant que l'on puisse eteindre le "extend" : si cette capacite est mise a off alors que je suis dans un PCR x, que je reboote et que une fois l'OS charge je reactive le TPM, vu qu'il n'y a pas eu de nouveau hashage au boot (vu que la capacite etait desactivee) je me retrouve donc avec mon derneir PCR enregistre dans ma puce meme si entre la desactivation et la reactivation du TPM j'ai completement change ma machine. Le PCR ne servirait donc plus a rien vu qu'il suffirait de deux manips pour faire croire a la puce qu'elle est dans un PCR alors que c'est faux. Par contre j'ai un peu de mal a voir en quoi ca te pose un probleme ?
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
and loading random data for the MigrationAuthorizationData.
page 164
Dans tous tes commentaires tu sembles supposer que le "owner" du TPM est forcément le possesseur de la mcahine, alors que les specs n'interdisent pas à un OS comme Windows d'être ce owner. D'ailleurs si les applications DRM de Win exigent que Win soit owner, on devra laisser owner à Win pour pouvoir utiliser ces applications.
Pour roots of trust je te conseille de relire le début du PDF des specs...
Pourquoi t'entêtes-tu alors que le site officiel TCPA possede des documents affirmant haut et fort que le but est bien de permettre à un fournisseur de contenu distant d'identifier les logiciels de ta machine afin de choisir s'il décide de faire confiance ou non à ton OS (grace aux checksums de l'OS par TCPA créés lors du boot):
For example, before making content available to a remote user, it is likely that a provider
will need to know that the remote platform is trustworthy. The provider's platform (the
"challenger") queries the remote platform. During system boot, the challenged platform
creates a series of cryptographic digests (integrity metrics) that represent the method
used to build the software environment in the challenged platform. These digests are
statistically unique indications of the platform environment, yet they will occur in all
platforms with the same software environment.
When it receives the query from the challenger, the remote platform responds by digitally
signing and then sending the integrity metrics. The digital signature prevents tampering
Page 2
and allows the challenger to verify the signature. If the signature is verified, the
challenger can then determine whether the identity metrics are trustworthy. If so, the
challenger, in this case the service provider, can then deliver the content. The TCPA
system reports the metrics and lets the challenger make the final decision regarding the
trustworthiness of the remote platform. Based upon the reported integrity metrics, the
challenger can determine if the platform is configured in a trusted state.
http://www.google.fr/search?q=cache:YDeLgyHUXDoC:www.trustedcomputi(...)
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 0.
The creator of the key can prevent migration by the User by wrapping it with a non-migratable storage key and loading random data for the MigrationAuthorizationData.
Je ne vois pas ce que ca a faire avec le fait que
1) seules les clefs generes par le TPM peuvent etre passees en non migrables
2) Une fois qu'une clef est non migrable elle ne peut plus etre utilisee que par la puce.
Le mecansime que tu decris est ce qui se passe quand le createur de la clef donne des droits a un utilisateur sur une clef sans pour autant lui donner la clef en elle meme.
Grosso modo je cree un repertoire, je pose ma clef dedans, je donne les droits sur ma clef a un utilisateur et je crypte mon repertoire avec une clef non migrable.
Cependant toutes les entites parentes de ce repertoire ont les droits sur ce repertoire et peuvent migrer ma clef si ca les amuse et si le possesseur du TPM donne son feu vert.
Dans tous tes commentaires tu sembles supposer que le "owner" du TPM est forcément le possesseur de la mcahine, alors que les specs n'interdisent pas à un OS comme Windows d'être ce owner. D'ailleurs si les applications DRM de Win exigent que Win soit owner, on devra laisser owner à Win pour pouvoir utiliser ces applications.
N'importe quoi en folie ! Bien que la puce TCPA soit relativement evoluee, si windows a les droits en owner sur le TPM ou sur le SRK alors je les ai aussi. On dialogue avec le TPM via un port serie pour se loguer en tant que owner TPM ou SRK il faut connaitre le mot de passe. Alors de deux choses l'une : soit tous les TPM et tous les SRK de toutes les puces TCPA ont le meme mot de passe (et la bravo pour la securite) soit les puces sont initialises avec des mots de passe different et windows ne peut pas le deviner (2048 bits a casser ca prend du temps). Et donc le brave windows pour pouvoir utiliser les fonctions TCPA il est oblige de me demander le mot de passe. Et la le plus beau c'est qu'il n'a aucun moyen de savoir si je lui donne les bons. Il n'y a pas de verification possible. Il est assez facile de savoir si on est vraiment le TPM owner ou pas, mais il est impossible de savoir si on a acces au SRK ou a un sous repertoire, donc ton programme qui exige le ownership il va avoir du mal. A noter en plus que toutes ces protections (dans le cas ou on ne met pas exactement le meme mot de passe sur toutes les puces) doivent se faire en logiciel, comme la securite d'un systeme est egale a la securite du plus faible de ses maillons, on a une securite de niveau logiciel et donc TCPA n'aide pas.
Pourquoi t'entêtes-tu alors que le site officiel TCPA possede des documents affirmant haut et fort que le but est bien de permettre à un fournisseur de contenu distant d'identifier les logiciels de ta machine afin de choisir s'il décide de faire confiance ou non à ton OS (grace aux checksums de l'OS par TCPA créés lors du boot):
C'est bien mon petit, maintenant apprend l'anglais et relit ta citation . C'est bon tu vois le probleme ? Non ? Bon je t'aide :
These digests are statistically unique indications of the platform environment, yet they will occur in all platforms with the same software environment.
Based upon the reported integrity metrics, the challenger can determine if the platform is configured in a trusted state.
Ca ne permet pas d'identifier le software, ca permet juste de verifier que le systeme est bien celui que l'on connait et a qui on fait confiance. Mais il est impossible de savoir ce que c'est. C'est le principe du MD5, avec tu peux savoir que le fichier que tu as telecharge a cote contient bien les bonnes donnees. Mais tu ne peut pas telecharger juste le MD5 et en deduire le fichier original. De la meme facon impossible d'utiliser un DIR ou un PCR pour identtifier un logiciel.
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
un nouveau token qui à lui seul suffit à s'identifier comme owner !
Si Win contient un soft de prise d'ownership, il peut s'emparer une fois la prise terminée de ce token ,et il pourra comme tu le dis si bien s'assurer qu'il est le owner.
page 3 de
http://www.trustedcomputing.org/docs/TCPA_security_policy_v0_45.pdf(...)
The TPM ownership token provides proof of TPM ownership. The creation of the token
occurs when the owner completes the ownership protocol. The value is stored in a shielded
location inside of the TPM. The administrator provides this token to access administrator
functionality, including system configuration.
page 6
applications authorized to perform the Administrator role have knowledge of the TPM
authentication token.
Maintenant relis ta citation de ma citation. Tu vois le problème ?
Bon je t'aide:
yet they [the same digests] will occur in all platforms with the same software environment.
Cela veut dire que le digest de l'OS booté qui est stocké dans TCPA sera toujours les meme chez toutes les personnes qui utilisent le meme OS. Cela suffit largement à identifier ton OS à l'aide d'un challenge encrypté par ta puce TCPA !
sinon, KHA c'est un pseudonyme pour IBM ? :)
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 1.
Si Win contient un soft de prise d'ownership, il peut s'emparer une fois la prise terminée de ce token ,et il pourra comme tu le dis si bien s'assurer qu'il est le owner.
Seul tout petit probleme dans ton raisonement : On ne peut faire un reset que si il y a preuve de presence physique. Cette preuve ne peut etre assuree qu'avant le chargement de l'OS. Pas evident pour Windows de prendre le ownership avant meme de s'etre lance non ?
Hence the method of enabling or disabling the process of taking ownership is a local command, and no remote option is provided. (In a PC, these local controls could be made available during the POST, for example.) (section 2.6.1)
De plus si il existait un moyen logiciel de prendre le controle d'une puce TCPA (ie TPM+SRK), ca serait assez mauvais non ?
Pour finir le owner du TPM n'a aucun pouvoir, il peut authoriser ou interdire des operations, mais il ne peut pas les executer. Pour pouvoir faire quoi que ce soit avec une puce TPM il faut etre owner d'une entite (ie d'un sous repertoire) ou du SRK (ie la racine). Et c'est a ce niveau la que tu n'as pas de moyen de verif. Tu ne peux pas savoir si tu es a la racine ou dans un reprtoire en dessous.
La section 10.17.1 explique aussi comment recuperer le ownership complet en prouvant qu'il y a presence physique. Donc basiquement comment recuperer l'acces a l'ensemble des infos contenues dans le TPM. (toujours avant le boot de l'OS).
applications authorized to perform the Administrator role have knowledge of the TPM authentication token.
Tout a fait logique, vu que le owner du TPM est le seul a pouvoir autoriser pas mal d'operations. Mais ce n'est pas pour autant que cet appli va pouvoir me voler le ownership de TPM...
yet they [the same digests] will occur in all platforms with the same software environment.
Ourch flagrant delit de traffic d'informations et de falsification de preuves :
La citation exacte est :
These digests are statistically unique indications of the platform environment, yet they will occur in all platforms with the same software environment.
donc "they" ne designe pas "the ??same?? digests" mais "the digests [that] are statistically unique indications of the platform environment" . Sans commentaire hein ?
sinon, KHA c'est un pseudonyme pour IBM ? :)
Ca serait plus facile dans ce cas la c'est ca. C'est clair que si je bossais chez IBM tous les arguments que j'avance seraient faux...C'est sur qu'un mec qui defend TCPA ca ne peut pas etre un mec qui croit en ce produit, ca doit juste etre un commercial quelconque pret a vendre son ame pour que TCPA se repande ...
Ben non, je bosse pas chez IBM, je ne bosse meme pas avec IBM, et a dire la verite je ne suis meme pas fan de TCPA. Seulement le truc qui m'ennui dans ce que tu dis c'est que c'est bourre de fautes d'anneries et d'imprecisions. Je comprend ton desir de defendre le libre, mais ca ne veut pas dire que j'approuve ta methode. Le papier que tu brandis sur ton site est faux, et n'importe qui peut le demolir en 30 secondes. C'est un vrai probleme, meme un papier parfaitement intelligent qui contient une ou deux anneries est discredite. Alors un papier qui ne contient que ca (anneries=erreurs imprecisions et speculations) sert plus la cause adverse qu'autre chose.
Ca fait un petit moment que je suis sur TCPA et que je pese le pour et le contre. Pour l'instant je ne suis toujours pas vraiment convaincu. Le nombre de choses que ca peut apporter est ennorme, mais le nombre de facon qu'il y a d'interagir avec la puce est trop grand. Pour l'instant je n'ai pas vu de failles dans le systeme, ni de facon de retourner un TPM contre son possesseur, mais faire un graph de tous les etats possibles prendrait un temps monstrueux donc je ne suis pas sur qu'il n'y est pas un moyen. Et je continue de chercher. Mais pour l'instant TCPA me parait innoffensif pour l'utilisateur.
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
je maintiens fermement que la phrase:
"yet they will occur in all platforms with the same software environment."
signifie que les palteformes ayant le meme OS auront le meme digest
Sinon peux-tu me dire pourquoi les gens de TCPA se sont donnés la peine de rédiger cette phrase dans ce document ?
Moi je peux te le dire: pour les rédacteurs de ce document, l'identification sans faille de l'OS est un argument de vente de TCPA à toutes les sociétés avides de DRM, et elles sont nombreuses !
Comme tu le suggère fort justement, il est quasiment impossible d'imaginer toutes les utilisations possible de TCPA, d'autant plus que la spec 1.2 n'est toujours pas accessible au public, meme si les ajouts qui ont filtrés sont très liés au DRM (vérification de la date/heure par la puce, compteurs infasilfiables, ...).
Pour ma part j'explique sur ma page qu'il est facile d'utiliser une puce permettant d'identifier un OS, pour s'assurer qu'un OS contient bien la notion de trusted sandbox chère à palladium.
PS: tu oublies systématiquement de traduire le mot "same", il te pose un problème ?
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 0.
signifie que les palteformes ayant le meme OS auront le meme digest
Et non signifie que toutes les plateformes qui font tourner ce logiciel auront un digest pour ce logiciel. Et c'est tout. On peut lire sur le morceau de phrase que tu refuse de citer que ce diggest est dependant de la plateforme.
Sinon peux-tu me dire pourquoi les gens de TCPA se sont donnés la peine de rédiger cette phrase dans ce document ?
pour leur demontrer que l'on peut non seulement authentifier le hardware mais aussi le software qui tourne dessus (donc que l'on est dans une configuration connue et consideree comme fiable)
PS: tu oublies systématiquement de traduire le mot "same", il te pose un problème ?
Ben vu que je n'ai pas du tout traduit ce paragraphe dans aucun de mes posts precedents on ne peut pas vraiment parler d'omission. mais bon puisque que tu le demande voici la traduction de ton extrait de phrase
"mais ils se produiront sur toutes les plateformes qui feront tourner le meme environement logiciel".
Alors bien entendu on se demande ce qui peut bien se produire vu qu'on a qu'un morceau de phrase denue de sens. Donc on fait une citation complete :
"Ces rapports sont des indications statistiquement uniques du systeme de la plateforme, mais ils se produiront sur toutes les plateformes qui feront tourner le meme environement logiciel".
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
Mais quel est l'intéret de cette phrase pour un fournisseur de contenu distant avec qui je communique ? (c'est le contexte du document que j'ai cité)
Aucun, sauf si cela lui permet de s'assurer que mon OS est bien compatible DRM !
Dans tous tes commentaires précédents tu supposes aussi que le BIOS est du coté de l'utilisateur, pas du coté de Windows. Le bios pourrait notamment intercepter le token Owner et le refiler à Windows, si l'OS est bien signé avec une clé privée correspondant à celle publique qui est stockée dans le bios.
Enfin tu as suggéré qu'il y a des "bonnes" applications de TCPA: lesquelles ne sont pas faisables avec des solutions software pures comme les softs libres dont je parle dans mon article ?
[^] # Re: Demontage en regle
Posté par thoran . Évalué à 2.
Tu veux dire si windows bloque LOGICIELLEMENT l'acces a certaines fonctions TCPA. Ben comme tout le monde, j'attend le crack ou je le develloppe moi meme. Si windows a des droits, c'est que la puce a des droits. Si windows m'interdit d'ecrire sur le port de la puce parceque je ne suis pas une appli securisee, parce que ca ne lui plait pas, ou parcequ'il veut proteger des donnees, il est oblige de faire ca logiciellement. Donc il est oblige de proteger TCPA avec autre chose. Et la de deux choses l'une
1) soit sa protection logicielle est sans faille, je ne peut pas acceder a la puce. Mais a ce moment la pourquoi ne pas utiliser cette protection directement et se passer de la puce TCPA ?
2) soit sa protection est nulle, elle se fait casser et TCPA ne sert a rien. Une fois que je peux ecrire sur la puce j'ai exactement les memes droits que l'OS et les programmes.
Cette alternative est bancale. Cela rejoint un autre echange qu'on a eu dans une autre news, lorsque je voulais prouver qu'on peut implementer la partie soft de palladium, a l'aide de la spec TCPA actuelle.
Je detaille. Tu consideres inutile que windows bloque de facon logicielle des fonctions TCPA. Si le noyau windows a des trous de securites, c'est effectivement domage pour eux car on peut les utiliser pour acceder aux fonctions TCPA que windows veut nous cacher (Et c'est pour ca que palladium ne peut pas se satisfaire de la spec TCPA, en l'etat)
Mais si le noyau windows n'a pas de trou de securite, il garantit que certaines fonctions TCPA (et donc certaines cles) sont inaccessibles de l'exterieur.
Alors que si windows n'utilise pas TCPA --- et meme s'il est parfait ---, je peux toujours l'executer dans un emulateur (genre bloch) et sniffer tout ce qu'il fait. Il n'a aucun moyen de me cacher des cles (meme si l'effort pour executer windows pas a pas est monstrueux)
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 1.
Donc si je reprend Microsoft me file une clef via une appli proprietaire(ie je ne vois jamais la clef) et la place dans un PCR (pour eviter que j'ai acces a cette clef depuis une autre sequence de boot). De plus il me bloque les fonctions TPM qui me permettrait de deplacer ou de copier cette clef ailleurs. Et pour finir l'OS est construit de telle facon que je ne puisse pas ecrire un driver TPM qui contourne ce probleme.
Je pense que j'ai du resumer ce que tu voulais dire non ?
En theorie il est quand meme possible de recuperer cette clef avec la fonction TPM_Backup depuis un autre OS. Je possederais donc une copie utilisable par un autre TPM, par contre je ne pourrais pas faire un UNSEAL des donnees depuis mon propre TPM, je serais oblige de passer par un autre TPM (ie dans ce cas il me faut deux machines avec TCPA, une avec les infos en scelle dans le PCR depuis laquelle je fait mon BACKUP et l'autre qui va recevoir les infos mais qui va pouvoir les decrypter hors du PCR).
De plus la mise en place de ce systeme implique de couper l'ensemble des droits de l'utilisateur sur sa propre puce, ca se voit. Ca pose plus la question de savoir si il faut boycotter Windows ou TCPA. C'est plus une question du driver et de l'usage qui est fait de ce driver. Il est clair que windows ne peut pas initialiser une puce TCPA et a donc besoin de l'accord de l'utilisateur pour le faire, ce qui aurait tendance a donner plus de pouvoir a l'utilisateur qu'a l'applicatif(ie windows a beson de l'utilisateur pour se servir de TCPA). Peut-on imaginer un systeme ou windows m'enleve les droits Owner ? non difficilement, mais il peut c'est vrai m'empecher logiciellement de m'en servir a ma guise.
On a effectivement a faire ici a un vrai probleme, bien que ce ne soit que de la speculation on peut imaginer un driver TCPA aux ordres de l'OS et non de l'utilisateur, et ca ce serait extremement dangereux. Il est donc important de s'assurer que l'OS ne retire pas de droits ou ne bloque pas de droits a l'utilisateur.(Et ca c'es hors des specs de la puce, donc techniquement pas moyen de verifier si c'est autorise ou non)
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
La réponse à ta question est simple: aujourdh'ui il est bien plus facile de boycotter TCPA (toutes les "bonnes" fonctions de TCPA ont leur équivalent en software pur) que de boycotter Windows (ce qui implique de nombreux logiciels et documents utilisables que sous Windows.
Maintenant que tu sais, toi aussi, qu'il faut décourager l'adoption de TCPA:
BIENVENUE AU CLUB :)
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 1.
BIENVENUE AU CLUB :)
Je suis pas encore vraiment convaincu. Mais je susi en train de faire des simulations avec une idee que je n'avais pas encore exploree et je dois reconnaitre que ca me fait un peu peur.
La suite au prochain episode.
Par contre independamment de ma position vis a vis de TCPA je maintien que tes arguments (et le papier qui les ennonce) ne sont pas valables et assez facilements demontables.
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
PS: tu peux nous faire part de ton idée, on peut t'aider avec plaisir !
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 1.
C'est justement ca qui m'ennuit, je ne sais pas si c'est possible, mais je ne pense pas que tu connaisses de methodes qui permette d'utiliser TCPA pour faire du DRM. N'oublie pas que
-Toute clef qui est migrable peut etre recupere independament du fait qu'elle appartienne a un TPM ou pas
-Toute clef qui interagit avec l'exterieur est miggrable.
Pas evident du faire du DRM avec ca, le risque que des petits malins sortent les clefs et les duplique sur d'autres TPM (voir meme les revellent en clair) est trop grand.
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
- les clés de cryptage seront différentes sur chaque machine: les rendre publique ne servira à rien
- tout le monde n'aura pas 2 TPM pour faire des manipes
- les connexions permanentes à Internet couplées avec le mécansime d'idnetification d'OS à distance suffisent à ce que les clés de crypto ne soient pas stockées du tout dans ton ordinateur: elles sont envoyées à chaque fois par internet par le fournisseur de contenu (elles-meme cryptées par des clés jetables)
- un BIOS vicieux pourrait faire ceci: détection d' un OS loader encrypté de MS. Décryptage à la volé de cet OS loader qui contient de clés de cryptage seules connues de MS. Utilistion de ces clés en conjonction avec les informations de boot TCPA garantissant que le premier OS booté est bien un OS MS, pour crypter des fichiers en ayant la certitude qu'ils ne seront pas lisibles par un autre OS.
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 1.
Par rendre publique je voulais dire deplacer dans une entite independante du PCR.
tout le monde n'aura pas 2 TPM pour faire des manipes
Ben en fait si a peu de chose pres. Pour que ce genre d'operation serve a quelque chose il faut que tout les ordis soient equipes. Donc on risque de voir fleurir des PC avec TCPA partout.
les connexions permanentes à Internet couplées avec le mécansime d'identification d'OS à distance suffisent à ce que les clés de crypto ne soient pas stockées du tout dans ton ordinateur:
Et vu que TCPA est un coffre a clef et qu'il ne permet pas d'identifier un OS, en quoi est il mele a tout ca ?
un BIOS vicieux pourrait faire ceci: détection d' un OS loader encrypté de MS. Décryptage à la volé de cet OS loader qui contient de clés de cryptage seules connues de MS. Utilistion de ces clés en conjonction avec les informations de boot TCPA garantissant que le premier OS booté est bien un OS MS, pour crypter des fichiers en ayant la certitude qu'ils ne seront pas lisibles par un autre OS. Il est deja capable d'identifier un OS Loader, de le decrypter tout seul. Je suppose que ton OS Loader n'est pas sur le MBR mais sur la partition ammorcee (Donc techniquement on est deja apres loin du POST), le decrypter a ce moment la assure au bios que l'OS qui va etre boote est bien Windows. Dans le cas ou ton OS loader est sur le MBR alors on ne peut booter que Windows (le fait de faire du multiboot changerait surement la signature de l'OS Loader).
Donc un bios qui sait faire tout ca, il n'a pas besoin de TCPA pour bloquer des infos aux autres OS eventuellement installes sur la machine.
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
tiens au fait il y a une faille (une de +) dans ton histoire de BACKUP:
pourquoi utiliser 2 TPM si il est vrai que le blob de backup est crypté par une clé que l'on fournit ? Pas besoin de 2e TPM pour décrypter des algos standards comme RSA.
Je crois plutot que la clé DOIT etre authentifiable comme provenant d'un autre TPM.
Seul cet autre TPM pourra utiliser le blob de backup. Et il aura tout loisir de bloquer l'accès aux clés en utilisant le meme PCR. Tou ça n'étant possible que si le BIOS coopère avec luitilsiateur, alors que les spesc TCPA prévoient plutot que le BIOS coopère avec les applications DRM !
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
2e question pour Thoran: peux-tu me rappeler quelle est ta vision de l'utilisation de TCPA par un Palladium soft ? Je propose justement une solution soft simple sur ma page web remise à jour: http://free2.org/tcpa/(...)
(merci de me signaler d'autres erreurs sur cette nouvelle version de ma page)
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
Sous un autre OS je ne peux pas accéder directement à ces clés car le PCR est différent.
Reste le probleme de l'accès indirect via des fonctions de déplacement des clés: dans nos discussions KHA a soutenu très fort, contre moi, que il était possible de déplacer toutes les clés (et donc toutes les clés protégées par un PCR sous un autre OS). Voulez-vous bien me confirmer que c'était une erreur et que les clés protégées par un PCR ne sont pas déplacables sous un autre OS (à moins d'utiliser la manipe BACKUP de Kha, dont je ne comprends pas pourquoi le 2e TPM me donnerait à l'accès au données protégées par PCR sous un autre OS).
Pour la 2e question, je viens de lire Thoran dire que le noyau Win ne doit pas contenir de bug: en utilisant des techniques de micro-noyau (Hurd/Mach) ou de virtualiseur (virtualPC, plex86, UserModeLinux) il est possible de booter un OS très simple (et donc moins sujet à des bugs critiques) qui ne sert qu'à exécuter d'autres OS compartimentés et donc protégés les uns des autres (sandboxs)
[^] # Re: Demontage en regle
Posté par thoran . Évalué à 2.
Ce schema suppose deux choses, en fait:
1) Que Microsoft puisse etre sur que windows est integre et ne s'execute pas dans un emulateur genre "bloch" (au moment de la phase d'activation). J'avoue que je ne comprends pas encore bien si cela est possible. Mais a defaut de comprendre la spec TCPA a la lettre, l'esprit dit (section 2.2 page 2) qu'une entite peut decider si une plateforme est dans un etat acceptable, ou pas. D'un autre cote, Kha dit que le "peer" ne peut pas voir la config, mais seulement un hash de la config. Il faut trancher cette question.
2) Que le noyau (ou micro-noyeau) n'aie pas de failles. Je ne regarde pas bugtraq mais juste la debian-security mailing list. Jusqu'a present, je n'ai jamais vu passer de mise a jour noyau pour cause de trou de securite, meme si je pense qu'il doit y en avoir. 99% des mises a jour concernent des programmes userland. J'en deduis qu'il n'est pas si difficile que ca d'avoir un noyau a peu pres sur. Tout ce qu'il faut, c'est empecher aux programmes userland de passer en ring 0 (il y a un appel systeme pour ca). A part XFree86 (et encore), je crois que personne n'a besoin de ce truc. Donc, ce deuxieme point me parait assez facile a garantir.
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
je crois que les digests enregistrés dans la puce TCPA au moment du boot sont fait pour ça: à tout moment on peut avoir la signature de l'OS qui a été booté directement par le BIOS: c'est donc forcément lui l'OS master de la machine. Si sa signature correspond à une signature connue de Win, alors c'est Win l'OS master de la machine, et il ne s'exécute pas d'un virtualiseur.
D'un autre cote, Kha dit que le "peer" ne peut pas voir la config, mais seulement un hash de la config. Il faut trancher cette question.
D'après ce que j'ai compris le hash de la config est détaillé:
il y a un hash pour le matériel, un hash pour le BIOS, et un hash pour l'OS
en comparant le hash de l'OS avec les hash des versions officielles de Win, on peut savoir si l'OS booté par le BIOS est bien Win.
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 2.
Seul petit probleme, ca sous entend que ton windows va booter de la meme facon sur toutes les plateformes. Ce qui est faux (heureusement).
Meme si chaque OS a une facon caracteristique de booter, il est oblige de s'adapter a la plateforme sur laquelle il se trouve. Le boot du meme OS sur une plateforme VIA/ATHLON va etre tres different du boot sur une plateforme INTEL/PIV. Bien qu'au final les fonctionnalites soient les memes, les puces ne vont pas reagir pareil et les informations sur les bus vont varier. D'apres les specs TCPA, on considere que tout ce qui se passe apres le POST du bios est du fait de l'OS, ca laisse ennormement de chose a mesurer. C'est pour ca aussi que les mesures sont statistiquements dependante de la plateforme.
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 0.
et voila, DRM !
[^] # Re: Demontage en regle
Posté par Moby-Dik . Évalué à -1.
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
paske là j'ai envie de te dire: je crois que tu ne comprends pas ce que je dis !
je dis que dans TCPA, après le boot, il y a la possibilité d'obtenir plusieurs signatures (digest) dont celle du programme auquel le BIOS a donné la main en premier au moment du boot. Cette signature , dans le cas d'un petit OS loader dont je parle, ne changera pas et ne dépendera pas de la config matérielle. D'où la possibilité d'identifier facilement un OS loader agréé par MS.
Tu avais compris ça ?
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 1.
1) ton OS Loader aussi basique soit-il devra quand meme initialiser le disque, recuperer les interrupts du bios, initialiser la memoire et eventuellement passer en mode reel. Toutes ces operations sont des operations dependante du hardware.
2) Si comme il est suggere par la doc, on considere que l'OS prend la main apres le POST, alors les evenements de type amorcage du MBR sont des evenements attribues a l'OS.
3) Windows va quand meme devoir rerecuperer les interrupts du bios glannees par l'OS loader et initialiser les periph en fonction de ses drivers, et en ce qui concerne les periphs systemes (la clock, le gestionnaire d'interrupts, les bridges (Ok ponts ) etc...) cela ne sera pas considere comme des evenements PCI ou ISA, donc non attribuables a autre chose dans le hashage qu'a l'OS
kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
Le BIOS a la possibilité de stocker dans le TPM des informations concernant l'OS loader à qui il donnera la main. Mais le contenu de ces informations est laissé à la discrétion du BIOS ! Donc le BIOS peut tout a fait faire un digest RSA du petit excutable que constutue l'OS loader. Si l'OS loader de MS est bien fait, il aura toujours la meme signature quelque soit la version de l'OS MS qu'il boote ensuite.
D'où la possibilité ensuite pour un fournisseur de contenu distant de savoir si on utiliser Windows ou non.
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 1.
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
par conséquent c'est al norme TCPA qui va obliger les BIOS à devenir des outils de DRM !
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 1.
Ca ca m'interresse comme info, tu as les sources STP ? Je vois assez mal comment le bios pourrait faire un digest de l'OS loader (ni meme savoir quand il a a faire a un OS Loader) et la norme EFI des nouveau bios INTEL risque de ne carrement pas aider.
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
http://www.google.fr/search?q=cache:www.trustedcomputing.org/docs/1(...)
Cryptographic
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
-------------------------
http://www.trustedcomputing.org/docs/TCPA_PCSpecificSpecification_v(...)
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.
---------------------------------------------------
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 1.
En fait c'est lie au fonctionnement des fonctions TPM_SEAL et TPM_UNSEAL. Lorsque tu veut faire rentrer des donnees ou des clefs dans un PCR il n'y a pas de cryptage de ces donnees vis a vis du PCR. C'est juste que si tu essaye de sortir les donnees d'un PCR qui ne correspond pas a ton DIR(PCR=sauvegarde, DIR=etat actuel) via un TPM_UNSEAL le TPM refusera. Par contre si ta clef est migrable, tu peux en demander la migration depuis n'importe quel environement.
Il y a deux facon de migrer une clef : par un rewrap (ie deplacer la clef dans une entite parente), ou par un backup(un blob de donnees contenant la clef sort du TPM).
Le prob du rewrap c'ets que c'est un move.On peut s'en servir pour sortir la clef du PCR et la mettre dans une zone publique, avant de refaire une copie dans le PCR(on peut mettre des clef dans n'importe quel PCR, meme si il ne correspond pas a la sequence de boot actuelle).
Seul ennui si on fait ca c'est que windows peut se rendre compte en lisant le "secret" du sceau que l'OS qui a mis la clef dans le PCR n'est pas un OS connu, et donc peut de fait invalider la clef.
C'est pour ca qu'on ets oblige de se frapper une migration complete qui elle fait une copie de la clef ou des donnees, et laisse les donnees actuelles en place. Ce genre de migration ne devant d'apres les specs n'etre possible qu'entre deux TPM, il faut donc un autre TPM....
Voila pour les explications de pourquoi il faut un deuxieme TPM au cas ou windows bloque les fonctions d'acces TCPA.
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 1.
Ce n'est ni un backup complet, ni un backup a l'identique, c'est un backup des donnees et/ou des clefs. Une fois que j'ai le blob de migration je peux le mettre en faire ce que je veux. Le systeme de backup fait sortir la clef du TPM (et donc du PCR). Mais rien ne m'oblige a reintegrer cette clef dans un PCR. Je peux la remttre en public si ca me chante.
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
en tout cas faire un backup des clés protégées par PCR suppose des droits complets sur la puce, ce qui pourrait ne pas être si évident si le BIOS en empêche le possesseur de la machine (seul le BIOS possede les tokens d'authentification et ne les donne pas à l'utilisateur)
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 1.
Si bien sur le contenu du blob est crypte, mais avec une clef publique fournie par l'exterieur. Si il etait crypte avec une clef du TPM ca serait pas evident de migrer la clef...
en tout cas faire un backup des clés protégées par PCR suppose des droits complets sur la puce
Droit owner sur le TPM et droit sur une entite parente de la clef, cela ne correspond pas du tout a des droits complets, mais effectivement il faut pas mal de droits.
seul le BIOS possede les tokens d'authentification et ne les donne pas à l'utilisateur
La ca suppose quand meme que le bios possede un systeme d'identification de l'OS qu'il est en train de booter, donc techniquement il implemente deja sans TCPA un systeme equivalent a la certification d'OS. En d'autres termes le probleme existe deja sans TCPA. Un bios capable de refuser de relacher certaines ressources a la vue d'un OS est evidemment un des cauchemars du libre. Mais une fois d eplus dans cet environement la on ne peut pas accuser TCPA, c'est le bios qu'il faut flinguer.
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
la différence est que une fois booté, l'OS certifié pourra utiliser TCPA pour s'assurer de la signature du BIOS, pour s'assurer de la signature de l'OS loder, etc...
Les fournisseurs de contenu distants pourront faire de meme !
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 1.
Oui mais si le bios est deja capable de planquer des clefs ou des tokens a un OS, il n'a plus besoin de TCPA pour fiare du DRM, il peut le faire tout seul. C'est clair que si on un systeme qui est deja pret pour le DRM, on peut en plus mettre du TCPA dedans, mais de la a dire que TCPA aide le DRM il y a un gouffre.
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 0.
Par contre le fait qu'il y ait du TCPA ou non sur un ordi ne change rien a ce qu'il faut ajouter au bios pour le transformer en outil DRM.
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
Cryptographic
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
-------------------------
http://www.trustedcomputing.org/docs/TCPA_PCSpecificSpecification_v(...)
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.
---------------------------------------------------
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 1.
[^] # Re: Demontage en regle
Posté par Moby-Dik . Évalué à 2.
J'ai un doute... Tes clés sur 2048 bits, c'est des clés de crypto symétrique ou asymétrique ?
[^] # Re: Demontage en regle
Posté par TSelek . Évalué à 2.
comparer 256 à 2048, oui je pense comme toi : on compare pas du DES avec du RSA !
mais stocker des clés dans du hash... encore un truc de contrebande !
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 1.
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 0.
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 0.
Pour ce qui est de l'algo RSA par exemple, oui je vois souvent du RSA 256bits (tous les jours meme). C'est vrai que c'est faible comme cryptage, on est en train de changer ca.
Mais ne confond pas la force d'un cryptage(en bits) avec la longueurs des clefs(en bits aussi, je sais c'est traitre).
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 0.
tu n'as pas bien compris comment est habituellement implémenté la crypto à clé (dite crypto asymétrique):
un couple de clé publique /clé privé est généré (et ces clés ont depuis des années dans les logiciels libres des tailles en bit d'au moins 1024)
ensuite ce couple de clé sert à encoder une clé privée asymétrique dont la taille varie dans les logiciels libres de 128 à 256 bits
donc ton argument qui consisterait à comparer les tailles des clés symetriques des logiciels libres avec les tailles des clés asymétriques de TCPA est très faux.
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 0.
ensuite ce couple de clé sert à encoder une clé privée symétrique dont la taille varie dans les logiciels libres de 128 à 256 bits
[^] # Re: Demontage en regle
Posté par Jerome Herman . Évalué à 0.
TCPA est en RSA 2048 bits ie la clef privee a une longueur de 2048 bits.
Comme ca ca devient clair ? C'est bien ce que j'ai dit, j'ai compare du 256 bits avec 2048 bits et c'est bien ca.
Kha
[^] # Re: Demontage en regle
Posté par free2.org . Évalué à 0.
[^] # crypto faible et espionnage
Posté par Moby-Dik . Évalué à 1.
I revealed that the UK patent office has been ordered by GCHQ to
use only 256 bit RSA in securing its communications with the European
patent office im Munich and with other national offices in Europe, and
pointed out that this would enable the NSA to get details of British
patents for its economic intelligence clients at the time they were filed
rather than three years later when they were published.
http://www.chiark.greenend.org.uk/pipermail/ukcrypto/1997-September(...)
(coîncidence amusante : l'auteur du post était Ross Anderson, créateur de la FAQ TCPA)
Donc, déposez des brevets logiciels en Grande-Bretagne, cela protègera l'innovation vis-à-vis de vos concurrents européens, mais pas des USA ;-) Décidément, on se demande ce que les Anglais font dans l'Union Européenne...
[^] # Re: crypto faible et espionnage
Posté par TSelek . Évalué à 1.
1988 : 320 bits, déjà trop faible selon les matheux...
1997 : 256 bits, mwawawawa la NSA !
bravo les naïfs...
[^] # Re: crypto faible et espionnage
Posté par free2.org . Évalué à 0.
Ce que j'explique maintenant sur la nouvelle version de ma page http://free2.org/tcpa/(...)
[^] # Re: Ross Anderson: un grand chercheur aus service du Libre
Posté par free2.org . Évalué à 1.
# Re: vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur
Posté par Nicolas BENOIT (site web personnel) . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.