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
si le backup est complet et à l'identique, pourquoi le 2e TPM me laissera-t-il l'accès aux données protégées par PCR si je n'utilise pas exactement la meme config ?
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.
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.
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.
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).
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.
Maintenant que tu sais, toi aussi, qu'il faut décourager l'adoption de TCPA:
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.
C'est un outil d'administration tres complet et tres simple a utiliser. Par contre il ne fonctionne que par lien ODBC donc il faut activer le -i dans le postmaster et autoriser la machine (meme si c'est la meme).
Il ne lui manque qu'un mode qui permettrait de coder des fonctions a l'interieur de l'interface.
Ok je viens de comprendre ce que tu voulais dire la derniere fois.
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)
"yet they will occur in all platforms with the same software environment."
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".
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.
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.
à chaque procédure de prise d'ownership (suite à un reset), il est créeé 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.
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.
J'ai jamais vu de clef assymetrique, c'est le mode de crypto qui est assymetrique.
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).
Je m'entete parceque tu lis les specs de travers. Que ce que tu decris est completement irrealisable en l'etat avec TCPA, que je te l'ai deja demontre 10 fois et que tu continue a poster ton doc dans tous les sens alors qu'il est a peu pres aussi faux que possible.
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.
assymetrique, la plupart des clefs internes sont necessairement en 2048 bits RSA. En ce qui concerne les clefs que tu importe, elles peuvent bien entendu avoir la taille que tu veux.
j'ai bien lu les pages 171 a 177 , et page 171 on peut lire qu'il est impossible de migrer les clés de type non-migratory (ce qui est logique !)
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 ?
l'énorme différence est dans le fait que on ne peut pas falsifier cette clé même si on a le controle total des softs d'un ordinateur et des paquets internet qu'il envoit. Pour pouvoir décrypter rapidement un challenge encrypté avec la clé publique, IL FAUT posséder la clé privé et être donc le proprétaire de l'ordinateur TCPA en question.
C'est vrai que dans l'architecture intel on puvait changer le numero de serie du processeur. Elle est donc la la difference. Et puis un systeme d'authentification qui permet de m'authentifier c'est vraiment degeulasse.
Au risque de me repeter la EK ne sert qu'a creer des certificats. Si quelqu'un m'envoit un paquet crypte selon ma EK (et je vois pas bien comment il ferait ca, mais bon), ma puce ne pourra pas le dechiffrer. La seule facon de se servir de la EK est la suivante.
- 1) je cree un certificat
- 2) j'envoit mon certificat a un organisme de validation
- 3) Cet organisme s'assure par un principe de challenge/reponse que je suis bien le createur de ce certificat.
- 4) Mon certificat est valide, l'organisme le charge pour confirmation.
- 5) J'utilise mon certificat sur le net, si une personne veut verifier son authenticite elle est redirige vers l'organisme qui refait un challenge/reponse pour verifier que c'est bien la machine declaree qui s'en sert.
J'en ai ras le bol de ce certificat, je peux le detruire. Ou en refaire un autre et me servir de celui la, ou ne jamais demander de certificat pour commencer, ou meme dans l'implementation IBM demander a ce que ce la EK ne soit pas activee. (soit parcequ'elle n'est pas presente, soit parceque je la desactive dans le bios.)
j'aimerais bien que tu me dises comment tu fais cette migration, controlée par Windows et donc non disponible si Windows la refuse.
Le philosophie et l'intéret de TCPA est que les clés sont générés dans la puce et n'en sortent jamais ! Les opérations de cryptage se ofnt à l'intérieur de la puce. Où as-tu vu dans les specs que on peut les faire sortir de la puce?
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.
En ce qui concerne la migration des clefs, lors du precedent thread je t'avais deja renvoye vers le lien dans les specs TCPA, mais c'est pas grave on y retourne :
Section 7.2.11,7.2.12,7.2.13 pages 171 a 177 de http://www.trustedcomputing.org/docs/main%20v1_1b.pdf la doc officielle TCPA. Tu remarqueras que ces fonctions sont "mandatory" ie obligatoire a toute implementation TCPA.
Concernant le mode "extend" qui n'est pas nié par IBM, tu as oublié cette phrase: "could also prevent the use of free operating systems because the OS kernel would have to be signed by a entity which is a descendant of the trusted root"
Non je n'ai pas oublie cette phrase. Revoyons la ensemble. Tout d'abord "could" en francais pourrait, a la difference de "can" en francais peut. Si TCPA avait le controle sur le boot (ce qui n'est pas le cas) et si TCPA etait fourni avec des clefs prechargees (ce qui est contraire au specs) et si le hashage du kernel etait previsible (ce qui est faux, meme un PCR qui hashe juste le kernel(la transition entre le mode reel et le mode protege) est dependant de la machine sur lequel il est execute), alors on pourrait vendre des puces TCPA qui empechent le boot si l'OS ne repond pas au critere de hashage du PCR. Bien entendu il faudrait aussi s'assurer que l'utilisateur ne puisse pas acceder du tout a ce PCR pour le modifier/ou en dupliquer les proprietes. Ce qui implique de retirer a l'utilisateur les droits sur le trusted root (il ne serait owner que d'une sous entite) et de lui enlever aussi les droits owner sur le SRK (il ne peut plus modifier/alterer/autoriser l'insertion,la suppression ou la migration de clef). Il faudrait de plus que toutes ces fonction soient codes dans la puce, pour eviter un hack logiciel.
Bref si TCPA etait quelque chose de completement different reposant sur la technologie TPM ca pourrait etre vachement dangereux. Ben oui. Mais c'est pas le cas.
dont tu fais partie sinon tu saurais que des modifications matérielles ou logicielles peuvent entrainer la désactivation de XP ! D'où le lien avec le roots of trust de TCPA et son controle de la configuration matérielle et logicielle.
Au risque de me repeter encore le TRUSTED ROOT est un repertoire. Une zone memoire, un endroit pour mettre des donnees dedans, un file system. Bref un truc completement passif. La seule chose qui le differencie des autres zones memoires de ta machine est la certitude que seul le owner du trusted root peut lire/ecrire/effacer des donnees. C'est exactement comme le /root de ta becanne. Si t'es pas root et si le root ne t'a pas donnes de droits tu peux pas ecrire dedans. ET C'EST TOUT.Il ne controle rien, il ne regarde rien, il ne voit rien, il ne fait rien. C'est une zone memoire.
Je supposerais donc que tu voulais parler du hashage du boot stoque dans un PCR. Et je te dirais une fois de plus que si MS fiche ces clefs la dedans, il suffit de les migrer ailleurs pour que tout baigne. Je n'est meme pas besoin que MS me redonne les clefs, je peux le faire tout seul...
Kha
Pour ceux aui ont suivi le thread TCPA precedent vous savez deja que l'ensemble des argumets avances ici sont au mieux incomplet, au pire le resultat d'une pure speculation, pour les autres :
- *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.
dont le format est techniquement et exhaustivement décrit et livré au domaine public.
Oui, mais ce n'est pas assez fort. Un format peut parfaitemtn etre dans le domaine public, et les algorithmes pour creer/lire un fichier/flux dans ce format etre eux proteges. C'est ce "detail" qui manque a mon sens pour donner a cette license un interet pratique.
En ce qui concerne ma remarque sur le DRM l'idee est la meme. A quoi ca me sert de posseder un fichier (au sens ou je suis le proprietaire), de connaitre son format, d'avoir un outil qui me permet d'ouvrir ce fichier, si je n'ai pas le droit legalement de lire ce fichier avec cet outil.
Cette difficulté n'est certainement pas une excuse valable pour renoncer à la reflexion.
Je ne renonce pas a la reflexion, au contraire je reflechis, et j'exprime ce qui manque a mon avis a cette license pour faire sens. Mon poste precedent n'est pas un rejet, c'est un souhait d'amelioration.
On est tous (ceux qui ont une distribution linux au moins) dans l'illegalite et on risque tous avec cette nouvelle loi un an de taule.
Ben meme sous windows il y a encore tellement de site dont tu peux detruire la base de donnees (ou acceder aux donnees) via ton navigateur et rien de plus (CF kittetoa) que IE et Netscape valent chacun un an de taule aussi.
Je ne suis meme pas sur que l'editeur de texte avec lequel je peux ecrire du javascript/VBscript nuisible (worm et compagnie) ne tombe pas sous le coup de cette loi.
Je crois que tout ce qu'il reste de legal sur mes ordis c'est le player de cd musiquaux (et encore).
Le bon point cependant c'est que si je pirate un ordinateur je suis sur de pas me retrouver seul en prison vu que le possesur de l'ordinateur d'en face est lui aussi un dangereux cyber criminel.
Kha
Il y a quand meme un truc qui me chagrine profondemment dans cette charte, c'est qu'il n'y est dit nul part que l'exploitation du format est autorisee.
Ca sert a quoi d'avoir les specs d'un format de fichier ou de flux si on ne peut pas s'en servir. Par exemple les formats mpeg4 et mp3 sont parfaitement connus et de lus on a meme l'algorithmique d'encodage et de decodage de ces formats. Ce n'est pas pour autant que leur utilisation est autorises. Si OpenMeans ne permet pas d'assurer qu'il est possible de creer une alternative libre sans se retrouver derriere les barreaux, j'ai un peu de mal a voir son interet.
Il faudrait plus de precision que juste Ouvrir systématiquement les formats des documents et données créés par les logiciels.. Qu'entendent-ils par ouvrir ? Rendre les specs publiques, ou autoriser la creation, modification, lecture de ces formats par des logiciels tiers, eventuellement libre ?
De plus cette charte ne parle pas un seul instant de l'utilisation de surcouche de type DRM.
Bref un peu trop flou pour pouvoir etre exploitable en l'etat a mon avis.
Kha
Je pense néanmoins que c'est une mauvaise solution à une bonne question : chaque user doit assumer leur identité, et on doit leur aider avec des solutions appropriérées, mais pas en bidouillant leurs entêtres, sans leur consentement.
La on est completement d'accord. Mais je ne me vois pas aller trouver la plupart de mes utilisateur pour leur demander si ils trouvent que ma politique est la bonne. Mon soucis est juste d'eviter
1) - que certaines adresse email sensibles ne se retrouvent a l'exterieur par erreur (ie sans que la personne sache que son email est sorti de la boite)
2) - Qu'un client qui recoit juste une bonne blague (aha) par email ne possede au passage d'integralite du carnet d'adresse de la boite.(on a eu ca, c'est pas beau a voir apres : vendeurs et commerciaux qui se fichent sur la geule en s'accusant mutuellement de se voler des clients).
Donc plutot que de donner des cours de nettiquette et de responsabilisation vis a vis des systemes informatiques a toute la boite (ce que l'equipe ethique fait tres bien de son cote d'ailleurs) je verrouille. Mais je prie aussi pour avoir des utilisateurs responsables qui ne m'obligeraient pas a recourir a ce genre de manips.
Kha
P.S merci pour les liens, la plateforme de test Postfix se monte lentement.
Faisable, mais pas evident. A moins de creer un agent note (ie un trigger/entree crontab pour ceux qui ne connaissent pas notes) qui va reemettre tous les mails recu et envoyees vers une autre adresse, ca oblige a fair eun paquet de controle. La double distribution n'est pas un probleme. Mais les envois Notes vers Notes (qui ne devraient jamais passer par un serveur SMTP) et la sauvegarde des mails envoyes est assez dure a gerer.
C'est le boulot d'un MDA ça
Pas vraiment, a moins de configurer ton MDA pour qu'il distribue le courrier vers un autre serveur qui va a son tour appeler un autre MDA, il est assez complexe de transformer une conversation talk en mail vers l'exterieur (N.B: oui je sais copier-coller marche). De meme un utilisateur qui possede un portable sera vachement content de pouvoir recevoir ses mails en POP3 quand il se deplace, alors que si il est au bureau il appreciera d'avoir tout dans son IMAP (sans que son compte POP3 ne gonfle et qu'il est a se farcir 2000 mails en download la prochaine fois qu'il est en deplacement). Mais je sais aussi que je me sert tres mal de Procmail. Il y a peut-etre moyen de faire plus simple.
Hein ?
Pour un proxy transparent : oui
Pour manipuler les entêtes (virer les hosts internes par exemple) : oui
Pour les autres, précise ta pensé ;)
Je pensais effectivement a un proxy transparent et a un masquage des etapes internes (ie un mail qui a tourne 2 jours en interne avant d'etre envoye vers l'exterieur). De meme que certaines adresses emails disparaissent de l'entete a moins que ce soit un message direct (ie PDG-> vers Mr X OK, PDG->secretaire-> Mr X apparait comme secretaire -> Mr X). Plus notemment un certain nombre de truc drole avec les headers Notes, quand le mail n'est pas imprimable/copiable.
"canonical" pour le catch-all.
Pour le ML, y'a des produits pour ça.
J'utilise mon catch-all de la facon suivante. Quand je dois (ou un utilisateur dois) s'inscrire sur un site qui exige une adresse email. Je file une adresse du type "nospamlesite@maboite.ext". Donc si mon catch-all recoit du spam, je cree une regle qui ferme la connection pour nospamlesite@maboite.ext juste au moment du to : . Avec Procmail on peut faire ce genre de chose, mais generalement on a deja telecharge le mail, et moi j'aime bien ma bande passante.
Pour les ML j'utilise Majordomo, mais j'aime bien m'en servir avec Sendmail car il ya une foule de facon de l'integrer. Je pense que tout doit etre faisable autrement, mais par exemple quand un doc de 80 Meg passe sur une ML, j'aime bien savoir qu'il ne transitera qu'une seule fois, et etre sur qu'il n'y aura pas x copies pour les x abonnees de la ML.
Ceci etant je vais me pencher sur les solutions alternatives a Sendmail (que j'avoue ne pas connaitre du tout(les solutions alternatives hein, pas de citations morceles de cette phrase)) et voir dans quelles mesures j'y gagne.
il ya vraiment aucune raison d utiliser sendmail , ou alors dans des trucs tres tres particuliers .
Bon ben puisqu'on nage dedans, une serie de petite questions amusantes :
- Comment on fait sous Postfix pour synchroniser une base IMAP avec une base mail NOTES ?
- Est-ce que Postfix permet de gerer en natif des tuyeaux POP2/POP3/IMAP/TALK ?
- Peut-on avec Postfix faire du controle / strip de header a la volee pour le relaying transparent de mails internes vers l'exterieur.
- Est ce qu'il est facile de configurer Postfix pour faire du load balancing ?
- Postfix possede-t-il un mode natif de gestion/processing du catch-all, des mailing listes ?
Je ne connais pas les reponses, si c'est le cas je me pencherais sur cette solution. En attendant je ne sais pas ce que tu entends par "truc tres tres particulier" mais dans la pratique je n'ai jamais vu autre chose que sendmail (et exchange ARRGHH!) etre installe en tant que solution professionelle. C'est peut-etre du a des habitudes antediluviennes, mais je pense que ca repose plus sur le fait que Send mail est un outil d'une flexibilite hallucinante.
Mais tout est dans cette phrase ! Tu as entendu de parler de WIndows XP ? Il oblige à obtenir une nouvelle clé de MS si on change la configuration du PC. MS va pouvoir utiliser TCPA pour faire la meme chose !
Non, deja dit pourquoi :
1) effet immediat - si le boot change, tous les applis cryptees sont inutilisables immediatement, et pas sous 30 jours.
2) sous TCPA le owner peut deplacer les clefs (systeme de migration)
je te propose de relire le titre de cette news: TCPA est à l'intérieur d'un pentium ! qui va pouvoir aller lire pjysiquement à l'intérieur de son pentium ?
Non plus, deja dit aussi : la news dit que le prochain CPU intel supportera les fonctions TCPA. De plus
Burns said that the Prescott would have 13 additional instructions (lien Inquirer 1)
Manque de pot il y a deja treize fonction obligatoires dans TCPA+4 systemes initialisations obligatoires+ une dizaine de fonction de hashage et de cryptage.
Si tu suis le lien inquirer 2 tu verras que les fonctions implementees dans le CPU sont des fonctions FP->int, Videos, et un synchroniseur de processus. Pas du tout TCPA. La puce sera donc HORS du processeur au moins ce coup la.
[^] # Re: Demontage en regle
Posté par Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 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 Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 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 Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 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 Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 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 Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 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: De nouveaux outils PostgreSQL
Posté par Jerome Herman . En réponse à la dépêche De nouveaux outils PostgreSQL. Évalué à 5.
pqAdminII : http://www.pgadmin.org(...) qui est libre et qui de plus a l'avantage de tourner sous Wine.
C'est un outil d'administration tres complet et tres simple a utiliser. Par contre il ne fonctionne que par lien ODBC donc il faut activer le -i dans le postmaster et autoriser la machine (meme si c'est la meme).
Il ne lui manque qu'un mode qui permettrait de coder des fonctions a l'interieur de l'interface.
Kha
[^] # Re: Demontage en regle
Posté par Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 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 Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 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 Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 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 Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 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 Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 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 Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 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 Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 1.
Kha
[^] # Re: Demontage en regle
Posté par Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 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 Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 1.
# Demontage en regle
Posté par Jerome Herman . En réponse à la dépêche vérifications sur TCPA: je refuse d'avoir des puces et des softs TCPA dans mon ordinateur. Évalué à 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: OpenMeans
Posté par Jerome Herman . En réponse à la dépêche OpenMeans. Évalué à 3.
Oui, mais ce n'est pas assez fort. Un format peut parfaitemtn etre dans le domaine public, et les algorithmes pour creer/lire un fichier/flux dans ce format etre eux proteges. C'est ce "detail" qui manque a mon sens pour donner a cette license un interet pratique.
En ce qui concerne ma remarque sur le DRM l'idee est la meme. A quoi ca me sert de posseder un fichier (au sens ou je suis le proprietaire), de connaitre son format, d'avoir un outil qui me permet d'ouvrir ce fichier, si je n'ai pas le droit legalement de lire ce fichier avec cet outil.
Cette difficulté n'est certainement pas une excuse valable pour renoncer à la reflexion.
Je ne renonce pas a la reflexion, au contraire je reflechis, et j'exprime ce qui manque a mon avis a cette license pour faire sens. Mon poste precedent n'est pas un rejet, c'est un souhait d'amelioration.
Kha
[^] # Re: La LEN adoptée par l'assemblée
Posté par Jerome Herman . En réponse à la dépêche La LEN adoptée par l'assemblée. Évalué à 3.
# Re: OpenMeans
Posté par Jerome Herman . En réponse à la dépêche OpenMeans. Évalué à 7.
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par Jerome Herman . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 3.
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par Jerome Herman . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 2.
Faisable, mais pas evident. A moins de creer un agent note (ie un trigger/entree crontab pour ceux qui ne connaissent pas notes) qui va reemettre tous les mails recu et envoyees vers une autre adresse, ca oblige a fair eun paquet de controle. La double distribution n'est pas un probleme. Mais les envois Notes vers Notes (qui ne devraient jamais passer par un serveur SMTP) et la sauvegarde des mails envoyes est assez dure a gerer.
C'est le boulot d'un MDA ça
Pas vraiment, a moins de configurer ton MDA pour qu'il distribue le courrier vers un autre serveur qui va a son tour appeler un autre MDA, il est assez complexe de transformer une conversation talk en mail vers l'exterieur (N.B: oui je sais copier-coller marche). De meme un utilisateur qui possede un portable sera vachement content de pouvoir recevoir ses mails en POP3 quand il se deplace, alors que si il est au bureau il appreciera d'avoir tout dans son IMAP (sans que son compte POP3 ne gonfle et qu'il est a se farcir 2000 mails en download la prochaine fois qu'il est en deplacement). Mais je sais aussi que je me sert tres mal de Procmail. Il y a peut-etre moyen de faire plus simple.
Hein ?
Pour un proxy transparent : oui
Pour manipuler les entêtes (virer les hosts internes par exemple) : oui
Pour les autres, précise ta pensé ;)
Je pensais effectivement a un proxy transparent et a un masquage des etapes internes (ie un mail qui a tourne 2 jours en interne avant d'etre envoye vers l'exterieur). De meme que certaines adresses emails disparaissent de l'entete a moins que ce soit un message direct (ie PDG-> vers Mr X OK, PDG->secretaire-> Mr X apparait comme secretaire -> Mr X). Plus notemment un certain nombre de truc drole avec les headers Notes, quand le mail n'est pas imprimable/copiable.
"canonical" pour le catch-all.
Pour le ML, y'a des produits pour ça.
J'utilise mon catch-all de la facon suivante. Quand je dois (ou un utilisateur dois) s'inscrire sur un site qui exige une adresse email. Je file une adresse du type "nospamlesite@maboite.ext". Donc si mon catch-all recoit du spam, je cree une regle qui ferme la connection pour nospamlesite@maboite.ext juste au moment du to : . Avec Procmail on peut faire ce genre de chose, mais generalement on a deja telecharge le mail, et moi j'aime bien ma bande passante.
Pour les ML j'utilise Majordomo, mais j'aime bien m'en servir avec Sendmail car il ya une foule de facon de l'integrer. Je pense que tout doit etre faisable autrement, mais par exemple quand un doc de 80 Meg passe sur une ML, j'aime bien savoir qu'il ne transitera qu'une seule fois, et etre sur qu'il n'y aura pas x copies pour les x abonnees de la ML.
Ceci etant je vais me pencher sur les solutions alternatives a Sendmail (que j'avoue ne pas connaitre du tout(les solutions alternatives hein, pas de citations morceles de cette phrase)) et voir dans quelles mesures j'y gagne.
Kha
[^] # Re: Faille de sécurité importante dans Sendmail
Posté par Jerome Herman . En réponse à la dépêche Faille de sécurité importante dans Sendmail. Évalué à 4.
Bon ben puisqu'on nage dedans, une serie de petite questions amusantes :
- Comment on fait sous Postfix pour synchroniser une base IMAP avec une base mail NOTES ?
- Est-ce que Postfix permet de gerer en natif des tuyeaux POP2/POP3/IMAP/TALK ?
- Peut-on avec Postfix faire du controle / strip de header a la volee pour le relaying transparent de mails internes vers l'exterieur.
- Est ce qu'il est facile de configurer Postfix pour faire du load balancing ?
- Postfix possede-t-il un mode natif de gestion/processing du catch-all, des mailing listes ?
Je ne connais pas les reponses, si c'est le cas je me pencherais sur cette solution. En attendant je ne sais pas ce que tu entends par "truc tres tres particulier" mais dans la pratique je n'ai jamais vu autre chose que sendmail (et exchange ARRGHH!) etre installe en tant que solution professionelle. C'est peut-etre du a des habitudes antediluviennes, mais je pense que ca repose plus sur le fait que Send mail est un outil d'une flexibilite hallucinante.
Kha
[^] # Re: et sous windows ..
Posté par Jerome Herman . En réponse à la dépêche La consultation du Dr GNU. Évalué à 1.
Kha
[^] # Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Kha
[^] # Re: OS crypté de confiance sur matériel de confiance = DRM anti Linux
Posté par Jerome Herman . En réponse à la dépêche TCPA confirmé pour Prescott. Évalué à 1.
Non, deja dit pourquoi :
1) effet immediat - si le boot change, tous les applis cryptees sont inutilisables immediatement, et pas sous 30 jours.
2) sous TCPA le owner peut deplacer les clefs (systeme de migration)
je te propose de relire le titre de cette news: TCPA est à l'intérieur d'un pentium ! qui va pouvoir aller lire pjysiquement à l'intérieur de son pentium ?
Non plus, deja dit aussi : la news dit que le prochain CPU intel supportera les fonctions TCPA. De plus
Burns said that the Prescott would have 13 additional instructions (lien Inquirer 1)
Manque de pot il y a deja treize fonction obligatoires dans TCPA+4 systemes initialisations obligatoires+ une dizaine de fonction de hashage et de cryptage.
Si tu suis le lien inquirer 2 tu verras que les fonctions implementees dans le CPU sont des fonctions FP->int, Videos, et un synchroniseur de processus. Pas du tout TCPA. La puce sera donc HORS du processeur au moins ce coup la.
Kha