Articles précédents : Articles
- [1] Première sortie de Nuface, interface Web d'administration de pare-feu
- [68] La gendarmerie inventorie son parc et reverse ses contributions !
- [25] Des nouvelles de MusicBrainz
- [81] Mandriva annonce l'acquisition des principaux actifs de Lycoris
- [34] Un émetteur TNT avec un simple PC : c'est possible !
- [19] Sortie de la version 0.7 de la solution ERP Neogia
- [13] Version 1.2 de openESub, le jeu (online) 100% libre sur les sous-marins
- [0] Dossier sur la conférence de sécurité CanSecWest 2005 (Vancouver@Canada) - Secuobs.com
- [4] La forge de l'administration
- [6] Cassandra, nouveau visualiseur libre de données scientifiques 3D
Liens connexes
- Téléchargement (1119 hits)
- Nouveautés (1222 hits)
- Cogito (672 hits)
- PWC dans le noyau (1469 hits)
- Mail de Linus Torvalds (1387 hits)
- La dépêche de LWN.net (475 hits)
Dépêche modérée par
Dépêche éditée par
Le système de développement a légèrement évolué ces derniers mois, avec notamment l'apparition d'une branche 2.6.11.x destinée à proposer des corrections de bogues ou de sécurité urgentes sans modifier le cycle de développement du 2.6.12. Ce nouveau modèle semble avoir connu un assez grand succès, puisque 11 sous-versions sont sorties, qui ont permis de corriger rapidement des failles de sécurité (.9-.11) ou des bogues importants (.8 et le SMP, par exemple). D'autre part, le passage à un logiciel libre (git) pour la gestion des sources semble s'être fait sans trop de soucis. Tout un chacun peut accéder facilement aux sources du noyau en développement en utilisant Cogito, ou bien les parcourir via une interface web.
Il y a eu beaucoup de modifications et de corrections de bogues pour ce nouveau noyau, notamment pour les plate-formes ARM, PPC, s390 et les architectures 64 bits, l'USB et la gestion des processeurs à fréquence variable (cpufreq). On notera aussi des améliorations dans UML, beaucoup de travail sur les drivers réseaux (TG3 surtout), sur DVB, le hotplug, le SerialATA, ainsi qu'un gros travail sur la documentation.
Le décompresseur du pilote pour les webcams Philips PWC a effectivement dû être retiré des sources. Les webcams Philips sont donc supportés mais de manière limitée en résolution.
NdM : la dépêche Linux Weekly News liste aussi plusieurs autres changements importants :
- l'ajout d'un pilote pour les controversées puces de sécurité TPM (présentes entre autres dans les Thinkpad d'IBM)
- le support du multipath dans le device mapper pour mieux gérer les E/S des gros serveurs de stockage
- l'introduction d'aléas dans le choix des espaces d'adresses mémoire lors des allocations, pour rendre plus difficile les attaques par buffer-overflow
- l'introduction d'une nouvelle limite de ressource (rlimit) pour accorder à certains utilisateurs le droit d'affecter des priorité "nice" négatives à leurs processus (utile par exemple pour les applications audios nécessitant de faible latences)
![[en]](../../../images/en.png)
Téléchargement (1119 hits)-
Nouveautés (1222 hits)
-
Cogito (672 hits)
![[fr]](../../../images/fr.png)
PWC dans le noyau (1469 hits)-
Mail de Linus Torvalds (1387 hits)
-
La dépêche de LWN.net (475 hits)
> Lire la dépêche (200 commentaires, moyenne: 3,1).
3 mois et demi, pas 5 mois :)
-
[^]Re: 3 mois et demi, pas 5 mois :)
Posté par Jérôme Pinot (page perso, ) le 18/06/2005 à 13:59. (lien). Évalué à 10.Tu as raison, je me suis gourassionne dans les dates. Quelle idee aussi ils ont ces americains d'ecrire mm/jj/aaa plutot que jj/mm/aaa ?
Enfin, cela faisait quand meme longtemps qu'on l'attendait celui-la, il y a eu une belle chasse aux bugs sur la fin. Il y a encore eu des modifs de l'API, ca va encore etre la joie dans les chaumieres (voir http://linuxfr.org/~JaguarWan/18563.html(...) ).
Je m'en vais de ce pas me flageller avec des ronces fraiches.-
[^]Re: 3 mois et demi, pas 5 mois :)
Posté par igor38 () le 18/06/2005 à 16:20. (lien). Évalué à 4.Fais gaffe, c'est peut-être déposé par Mel Gibson ça :D
-
[^]Re: 3 mois et demi, pas 5 mois :)
Posté par ginkyo (page perso, ) le 19/06/2005 à 16:05. (lien). Évalué à 6.Perdu ! :)
C'est plutôt le style des cathares
(doctrine condamnée par l'Église catholique, qui imaginait un Dieu du bien qui avait créé des esprits et un dieu du mal qui avait créé le monde. L’homme lui-même se trouvait donc divisé entre un esprit créé par le bon Dieu et un corps créé par le dieu du mal, ce corps devenant donc une prison pour l’esprit dont il fallait se libérer par un ascétisme inhumain.)--
« Si quis scienter in tantum a vino abstineret ut naturam multum gravaret a culpa immunis non esset. »Saint Thomas d'Aquin, Somme théologique, II-II, 150, 1 ad 1.
-
-
[^]Re: 3 mois et demi, pas 5 mois :)
Posté par Ellendhel () le 18/06/2005 à 17:36. (lien). Évalué à 8.Quelle idee aussi ils ont ces americains d'ecrire mm/jj/aaa plutot que jj/mm/aaa ?
C'est vrai qu'avec trois chiffres pour indiquer l'année ça n'aide pas non plus...-
[^]Re: 3 mois et demi, pas 5 mois :)
Posté par Tony Flow () le 19/06/2005 à 15:05. (lien). Évalué à 0.C'est vrai qu'avec trois chiffres pour indiquer l'année ça n'aide pas non plus...
Bah oui comme en Perl voyons non !?...
(où on obtient le nombre d'années depuis 1900)
--->[]-
[+] [^]Re: 3 mois et demi, pas 5 mois :)
Posté par Chaddaï Fouché () le 21/06/2005 à 16:37. (lien). Évalué à -1.Comme c'est le cas des 3/4 des langages (avec des nuances selon les API, comme dans Perl d'ailleurs) je ne vois pas pourquoi tu cites Perl en particulier sinon pour lancer un gros Troll... Je ne tomberais pas dans ton piège, non, non, d'ailleurs Perl c'est dix fois mieux que Python et Ruby, 30 fois plus rapide et 100 fois plus lisible !!!! ;-)
--
Jedaï
-
-
-
Toujours pas de reiser4 !
ET zut !
Le reiser4 est toujours pas intégré !
-
[^]Re: Toujours pas de reiser4 !
Posté par L (page perso, ) le 18/06/2005 à 14:26. (lien). Évalué à 10.Si tu as du temps et une partition libre, tu peux regarder du côté de la distribution MiniSlack [1] dont la dernière version 1.1 [2] inclut en standard le système de fichier ReiserFS 4 [3].
[1] http://www.minislack.org(...)
[2] http://www.minislack.org/article.php?story=20050610194346329(...)
[3] http://www.namesys.com/v4/v4.html(...)-
[^]Re: Toujours pas de reiser4 !
Posté par Frédérick Diot (page perso, ) le 18/06/2005 à 14:29. (lien). Évalué à 1.C'est sympas.
Je chercherai plutot à l'integrer dans ma gentoo.-
[^]Re: Toujours pas de reiser4 !
-
[^]Re: Toujours pas de reiser4 !
Posté par Ludovic F (Jabber id, page perso, ) le 19/06/2005 à 08:52. (lien). Évalué à 2.* sys-kernel/mm-sources [ Masked ]
Latest version available: 2.6.12_rc6-r1
Latest version installed: [ Not Installed ]
Size of downloaded files: 44,304 kB
Homepage: http://www.kernel.org/(...) http://www.gentoo.org/(...)
Description: Andrew Morton's kernel, mostly fixes for 2.6 vanilla, some vm stuff too
License: GPL-2-
[^]Re: Toujours pas de reiser4 !
Posté par Brice Goglin () le 20/06/2005 à 07:04. (lien). Évalué à 6.2.6.12-mm1 vient de sortir à l'instant.
Reiser4 est dedans.
-
-
-
[^]Re: Toujours pas de reiser4 !
Posté par jaune (page perso, ) le 19/06/2005 à 11:07. (lien). Évalué à 5.Alors tu utilises le live cd qui gère reiser4 pour l'installer :
http://gentoo-wiki.com/TIP_Reiser4_Enabled_Live_CD(...)
-
-
-
[^]Re: Toujours pas de reiser4 !
Posté par Jérôme Pinot (page perso, ) le 18/06/2005 à 15:58. (lien). Évalué à 10.L'enorme delai que prend l'integration de ReiserFS 4 dans le noyau officiel vient du fait que le code est tres intrusif. Bref, c'est plus qu'un module, comme le dit Rik van Riel :
The reiser 4 system call sys_reiserfs seems to need an additional patch, which is craftily hidden inside reiser4-only.patch. That patch creates fs/reiser4/linux-5_reiser4_syscall.patch, which I can only assume reiser 4 users should apply...
Kind of ugly.
Looking further, the horrors only increase. It looks like sys_reiser4() is an interface to load programs into the kernel, with reiserfs4 containing an interpreter.
I'll leave aside the issues of having a scripting language inside the kernel, since I'm sure other people will comment on it. However, I am absolutely flabbergasted that Hans Reiser is using a syscall here, instead of a filesystem interface.
Furthermore, why do the parsing in the kernel, instead of compiling the human-readable strings in userspace and loading something easy to use into the kernel, like the selinux subsystem does?
Since this code is bound to be horribly controversial, it may be an idea to remove this from the reiserfs4 core patch. That way the battles over the filesystem, and its interactions with the rest of the kernel can be fought first, without having the whole reiserfs4 filesystem strand in the quicksand of "why do we need an interpreted language with completely new filesystem semantics in the kernel?
Il faut que le developpement de ReiserFS change un peu de direction pour qu'il soit integre au kernel.-
[^]Re: Toujours pas de reiser4 !
-
-
[^]Re: Toujours pas de reiser4 !
Posté par Pierre Jarillon (page perso, ) le 19/06/2005 à 23:31. (lien). Évalué à 1.Reiserfs n'a pas été tout de suite intégré au grand désespoir de Hans Reiser.
C'est ce qu'il m'avait dit aux RMLL 2000 (les premières !).
Il avait dû attendre le noyau suivant car les mainteneurs du noyau craignaient beaucoup l'introduction de ce FS très nouveau. Si ils prennent les mêmes précautions qu'il y a 5 ans, il faudra attendre le noyau 2.8 pour mettre reiser4 en production.
On ne peut pas reprocher la prudence du "kernel team" mais il me tarde quand même de pouvoir utiliser reiser4 qui est vraiment une nouveauté aussi magnifique que révolutionnaire.-
[^]Re: Toujours pas de reiser4 !
Posté par Romain LE DISEZ () le 20/06/2005 à 08:58. (lien). Évalué à 4.Qu'en est il des possibles incompatibilités avec les outils GNU en l'état actuel ?
J'avais entendu dire que les programmes utilisant la libc pour vérifier si une URI* pointe sur un fichier ne pouvais plus fonctionner (puisque un fichier est un dossier dans reiser4).
Ce problème est il toujours d'actualité ?
* URI : est ce le bon terme ?
-
[^]Re: Toujours pas de reiser4 !
Posté par fredoh () le 20/06/2005 à 09:51. (lien). Évalué à 4.Pour ceux qui ne se rappellent plus ou qui ne savent pas ce qu'est ReiserFS :
http://fr.wikipedia.org/wiki/ReiserFS(...)
http://linuxfr.org/2004/08/24/17094.html(...)-
[^]Re: Toujours pas de reiser4 !
Posté par Pierre Jarillon (page perso, ) le 22/06/2005 à 00:27. (lien). Évalué à 2.Pour avoir des informations encore plus pertinentes, on peut aller à la source : http://www.namesys.com/(...)
-
-
-
[^]Re: Toujours pas de reiser4 !
Posté par Brice Goglin () le 21/06/2005 à 09:41. (lien). Évalué à 2.Andrew Morton vient de publier la liste des trucs actuellement dans -mm qu'il veut merger dans 2.6.13.
Il y a Reiser4.
http://lkml.org/lkml/2005/6/21/98/index.html(...)
-
[^]Re: Toujours pas de reiser4 !
Posté par Alan_T () le 21/06/2005 à 10:54. (lien). Évalué à 2.Pour le 2.6.13
Subject: -mm -> 2.6.13 merge status
From: Andrew Morton
...
reiser4
Merge it, I guess.
The patches still contain all the reiser4-specific namespace
enhancements, only it is disabled, so it is effectively dead code. Maybe
we should ask that it actually be removed?
...
et oui les TPM ...
> NdM : la dépêche Linux Weekly News liste aussi plusieurs autres changements importants :
> - l'ajout d'un pilote pour les controversées puces de sécurité TPM (présentes entre autres dans les Thinkpad d'IBM)
... parlons en des TPM (enfin vous parceque moi j'y comprends pas grand chose)
a quoi ca va servir (ou sert deja puisque'il y avait deja un patch pour le 2.6.11) ?
quel sont les risque d'integrer le support de ca dans notre noyau libre a nous ?
(vous avez 4 heures)
-
[^]Re: et oui les TPM ...
Posté par tgl () le 18/06/2005 à 15:40. (lien). Évalué à 10.> a quoi ca va servir (ou sert deja puisque'il y avait deja un patch
> pour le 2.6.11) ?
Pour l'instant, à ma connaissance ça sert pas à peu prêt à rien. Mais y'a une API en développement qui devrait permettre d'en faire quelquechose si les distribs décident d'aller dans ce sens et que des softs qui font/utilisent de la crypto décident de s'y mettre aussi :
http://trousers.sourceforge.net/faq.html(...)
À voir quoi...
Tu peux aussi jetter un oeil sur ce journal à propos d'un patch pour Grub (rejeté) qui implémentait le boot sécurisé façon TCG :
http://linuxfr.org/~albancrequy/18368.html(...)
Y'a une discussion dans le genre de celle que tu proposes, avec en gros deux tendances : les plutôt pour qui se disent que c'est une techno qui peut s'avérer utile pour remplacer certains des mécanismes de sécu actuels, et les carrement contre qui se disent que le véritable objectif est l'autentification distante à des fins de contrôle DRM, et que donc il faut rejeter cette techno en bloc. (J'espère avoir résumé à peu près objectivement le troll...)-
[^]Re: et oui les TPM ...
Posté par Jérôme Pinot (page perso, ) le 18/06/2005 à 16:14. (lien). Évalué à 3.Ca a l'air de ressembler a TCPA, c'est le retour de Palladium/NGSCB ?
-
[^]Re: et oui les TPM ...
Posté par MsK` () le 18/06/2005 à 20:06. (lien). Évalué à 7.C'est complètement ca, j'ai mon T43p tout neuf à côté de moi et la puce est désactivée de base, je me suis retrouvé dans le windows avec un fichier TCPACHIP à la racine avec écrit que la puce est désactivée blabla.
--
\_o<~~~~-
[^]TPM, TCPA, TCG, "remote attestation"
Posté par free2.org (page perso, ) le 18/06/2005 à 20:59. (lien). Évalué à 9.Oui TCPA, TCG, TPM, trusted computing group
C'est bien la meme chose. (toutes ces marques sont déposées par TCG).
Le principal problème est que ces puces permettent l'identification à distance des logiciels et matériels utilisés (remote attestation).
Si leur usage se répand, des fournisseurs d'accès et de contenus exigeront qu'on active notre TPM pour s'assurer que le matériel et les logiciels que nous utilisons contiennent un DRM qui leur convient.
Une petite recherche sur le web avec tcg "remote attestation" vous en dira +-
[^]Re: TPM, TCPA, TCG, "remote attestation"
Posté par Jerome Herman () le 18/06/2005 à 21:10. (lien). Évalué à 10.Le principal problème est que ces puces permettent l'identification à distance des logiciels et matériels utilisés (remote attestation).
Non, le principal problème C'est que les gens croient celà.
Si tu as activé la fonction et si tu as fait signé ta puce (ou que le constructeur l'a fait pour toi, mais IBM et le seul constructeur et il ne l'a jamais fait) et si tu te connecte à un service particulier et si tu as déclaré un third party de confiance ALORS le service particulier pourra apprendre du third party de ocnfiance si oui ou non tu as une puce TCPA couplée à un système TPM valide.
Rien d'autre.
Il lui sera totalement impossible de savoir si tu es sous windows ou linux ou BSD, si tu as des logiciels pirates ou si tu as du contenu illicite.
Il poura juste vérifie si tu as un système TPM valide.-
[^]Re: TPM, TCPA, TCG, "remote attestation"
Posté par TazForEver () le 18/06/2005 à 21:36. (lien). Évalué à 4.et tu crois vraiment que c'est prévu comme ça ?
Ça serait pas plutôt une close dans le CLUF "vous acceptez la société comme tiers de confiance" "vous ne pouvez pas demander réparation pour préjudice pour plus de 5E par an" couplée avec des fonctions systèmes pour savoir si la machine à la dite puce et ainsi l'identifiée.
Ouf, j'ai pas Windows !-
[^]Re: TPM, TCPA, TCG, "remote attestation"
Posté par Jerome Herman () le 18/06/2005 à 22:10. (lien). Évalué à 4."vous acceptez la société comme tiers de confiance"
Comme su le grand ternet. Perso je ne fais pas de paiement sur un site web qui n'a pas un certifica valide. je ne vais pas non plus sur les sites certifiés par Verisign en qui je n'ai aucne confiance (et en plsu généralmeent je me fend d'un email pour dire au vendeur pourquoi je n'ai pas finaliser mon achat.)
couplée avec des fonctions systèmes pour savoir si la machine à la dite puce et ainsi l'identifiée.
La seule fonction accessible depuis système de TCPA/TPM c'est challenge-response. IE on teste a) que l'on a bien à faire à une puce TCPA (éventuellement à distance mais surtut en local) et b) on lui envoit un message et elle renvoit le truc déchiffré. C'est tout ce qu'elle fait.
A noter que les clefs "challengeable" sont copiable d'une zone de la puce vers d'autres zones de la puce mais aussi vers d'autres puces TCPA (la manoeuvre est complexe, mais tout à fait réalisable même sous linux).-
[^]Re: TPM, TCPA, TCG, "remote attestation" avouée par TCG et aussi par IBM
Posté par free2.org (page perso, ) le 18/06/2005 à 23:18. (lien). Évalué à 6.Même TCG admet officiellement la "remote attestation":
remote attestation
capability to ensure that the user is employing a configuration that the provider
insists upon, even when there is no security reason for such a choice
http://66.102.9.104/search?q=cache:https://www.trustedcomputinggrou(...)
Idem pour IBM:
these mechanisms interact to
enable remote attestation
http://66.102.9.104/search?q=cache:hMRNHAVJ3BwJ:byte.csc.lsu.edu/~d(...)-
[^]Re: TPM, TCPA, TCG, "remote attestation" avouée par TCG et aussi par IBM
Posté par Beretta_Vexee () le 19/06/2005 à 13:08. (lien). Évalué à 10.Parce que le "remote attestation" est une fonction rendue possible par TCG, et qu'elle est demandé par divers systéme. Maintenant comme SSL ou autre systéme de certificat et d'authentification mutuel, personne ne t'oblige a l'utiliser.
Si tu n'accepte pas le "remote attestation" ( ce qui est aussi mon cas ) tu n'installe pas de systéme qui implémente une telle fonction, le remote attestation se base sur TPM, mais TPM ne fournit pas de base un systéme de "remote attestation".
TPM peut servir a énormément de chose différente de l'attestation, mais bon je praiche dans le dessert j'en suis bien conscient. TPM est un jeu de fonction cryptographique très puissant, après chacun peut construire ce qu'il veut avec, que ce soit en bien ou en mal tous comem n'importe quel autre technologie.
Nous dire que si l'on supporte TPM, on va automatiquement être sous le contrôle de fournisseurs de contenue des corporation et autre par contre c'est un mensonge, TPM n'est pas un DRM, TPM est documenté et existe déjà dans pas mal de machine depuis un bout de temps. Si vous vous inquietez vraiment de la remote attestation du tracage des machine et de votre topologie reseau faudrait peut étre plus se pencher sur le futur Pentium D qui intégre DTCP-IP en natif, qui lui est un DRM qui fait tous cela, et la technologie LaGrande ( anciennement Palladium, et NGSCS ) qui est le systéme de MS, non documenté et dont les répercutions sont totalement inconnue.
Mais bon c'est tellement plus facile de taper sans connaître sur quelque qui en court de support par le libre, qui peut augmenter la sécurité que de pointer les vrais problèmes...--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]"remote attestation" avouée par TCG et aussi par IBM, refuser = gagner
Posté par free2.org (page perso, ) le 19/06/2005 à 14:35. (lien). Évalué à 3.1. Le remote attestation n'est pas possible sans une puce de type TCG.
2. Toutes les autres fonctions TCG ne sont pas nouvelles et sont possibles autrement (les coprocesseurs de crypto existent depuis longtemps, de meme les supports avec mode read-only pour booter dessus en sécurité).
De 1. et 2. je déduis que, en matière de business, l'avantage concurentiel de TCG est de loin le remote attestation.
Il va y a voir une pression économique très forte de la part des fournisseurs de contenus pour imposer aux utilisateurs TCG.
La façon efficace de lutter contre cela est de refuser d'avoir ces puces. C'est en effet sous la pression des consommateurs qui le refusaient que le numéro d'identification des pentium 3 a été abandonné.-
[^]Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par Beretta_Vexee () le 19/06/2005 à 15:07. (lien). Évalué à 6.Question béte pourquoi vous ne luttez pas contre le pentium D et DTCP-IP et LaGrande avec autent de vigueur qu'avec TCPA ?
C'est systéme ne sont ils pas pourtant plus dangereux et non supporté par le libre ?
Je reste perplexe quand a vos motivations, comme je l'avais indiqués le remote attestation est en effet un fonction demandés par les industriels, qui est rendue possible par TCPA, mais rien n'implique que le support de TCPA dans un systéme ou un environnement libre inclue forcement une fonction de remote attestation. Je crois avoir lui ici même que certaines puce comme celle d'IBM ne permettait pas a l'heure actuel la remote attestation ( a vérifier ).
Je suis tous a fait d'accord sur le fait que le remote attestation dans certaines situation somme toutes rares peut poser problème et que cette fonction n'est pas essentiel quand a la sécurité, mais je ne comprend pas pourquoi vous voulez absolument rejeter toutes les avancés de TPM en bloque, cela plusieurs fois que nous avons des échanges sur ce points sans que vous ayez fournit un début de réponse.--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[+] [^]Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par free2.org (page perso, ) le 19/06/2005 à 15:56. (lien). Évalué à -1.mais je ne comprend pas pourquoi vous voulez absolument rejeter toutes les avancés de TPM en bloque, cela plusieurs fois que nous avons des échanges sur ce points sans que vous ayez fournit un début de réponse.
Si tu n'a pas compris ma comparaison avec le ID du pentium 3 qui a été abandonné suite à boycott. Tu ne comprendras jamais en effet.-
[^]"remote attestation" TCG et refus de toutes les puces similaires
Posté par free2.org (page perso, ) le 20/06/2005 à 06:43. (lien). Évalué à 3.J'ajoute que l'article dont on parle concerne uniquement TCPA dans Linux, pour la bonne raison que TCPA a introduit la remote attestation bien avant les autres puces DRM (et des brevets ont certainement été déposés par les membres de TCG, dont Intel et IBM). C'est pour cette raison que certains logiciels libres ( mais certains le refusent comme les logiciels du projet GNU) dont Linux intègrent déjà un support pour TCPA.
Impossible d'avoir une remote attestation sans stocker dans une puce "de confiance" les hashs des composants matériels et logiciels d'un PC, ce qui est la base de TCPA.
J'ai expliqué ici à tous le remote attestation de TCPA et pourquoi il faut le refuser dans les PC du grand public. Suivons l'exemple de l'équipe du GNU bootloader GRUB qui refuse d'intégrer un patch avec le support TCPA pour que leurs utilisateurs prennent conscience quelles seront les conséquences d'une popularisation des puces remote attestation.
Evidemment toutes les puces DRM sont susceptibles de poser une menace similaire et il vaut mieux toutes les refuser. Et tous ceux qui veulent nous parler en détails des dangers de ces autres puces seront, je pense, ici les bienvenus.
-
-
-
[^]Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par Jerome Herman () le 19/06/2005 à 22:23. (lien). Évalué à 3.1. Le remote attestation n'est pas possible sans une puce de type TCG.
C'est sur on a jamais vu un système identifier un autre système à distance sur la foi d'une clef ou d'un mot de passe. C'est tout nouveau ca vient de sortir. Par exemple les licences MS ne sont pas du tout validées à distance et locké par PC. Du tout.
2. Toutes les autres fonctions TCG ne sont pas nouvelles et sont possibles autrement (les coprocesseurs de crypto existent depuis longtemps, de meme les supports avec mode read-only pour booter dessus en sécurité).
Bien sur aussi, on a depusi longtemps uen boite noire qui fait coffre à clef que l'on peut remplir à volonté et dont les clefs sont inextractibles en clair. Ca existe depuis super longtemps et TPM n'apporte rien.
La façon efficace de lutter contre cela est de refuser d'avoir ces puces
Je te rassure, c'est déjà fait. TPM est en voie de mort rapide. Les normes v2 n'ont jamais vu le jour et les systèmes parallèles ont appris à se faire discret pour rentrer sur nos systèmes en douce. On ne peut que féliciter les gens qui par leur boycott ont tué dans l'oeuf une techno fiable, utile et ouverte, laissant ainsi la porte grande ouverte aux bios plombés, au matos adaptatif et au options de sécurités imposés par les grands groupes et dont les specs sont bien cachés.
Je ne vais pas reprendre ce troll vec toi. Mais au moins essaye d'éviter le FUD par pitié.-
[^]Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par free2.org (page perso, ) le 19/06/2005 à 23:19. (lien). Évalué à 1.essaye d'éviter le FUD par pitié.
C'est surtout toi qui en fait:
C'est sur on a jamais vu un système identifier un autre système à distance sur la foi d'une clef ou d'un mot de passe.
Le remote attestatiàon de TCPA n'a rien à voir avec cela.
Il s'agit d'enboyer, signés par la puce TPM, les hashs des composants matériels et logiciels d'un ordinateur.
C'est autrement plus intrusif !
Relis bien le document de TCG que j'ai cité ci-dessus où ils reconnaissent que cette remote attestation est un fait.
Dommage que tu sois en retard sur eux sur ce FUD.-
[^]Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par Jerome Herman () le 19/06/2005 à 23:39. (lien). Évalué à 4.Il s'agit d'enboyer, signés par la puce TPM, les hashs des composants matériels et logiciels d'un ordinateur.
C'est autrement plus intrusif !
GNNNIIII ?????
Le remote attestation permet en passant par un tiers de vérifier que la clef que tu as fait créer par le tiers et qui a été transmise depuis le TPM du tiers jusque dans ton TPM est bien présent et de certifier cette information auprès d'un autre tiers.
C'est exactement l'équivalent des certicats "classiques" sauf que celà se joue entre TPM.
Pour finir il n'y a que deux choses qui peuvent sortir du TPM : soit un message décodé (par exemple suite à un challenge response, ou dans le cadre normal de l'utilisation du TPM pour déchiffrer un message); soit une clef migrable a condition que ce soit vers un autre TPM et seulement via une connection sécurisé.
Relis bien le document de TCG que j'ai cité ci-dessus où ils reconnaissent que cette remote attestation est un fait.
On va pas reprendre le troll ici. Je t'ai déjà démontré, il y a un an que
a) La config sur laquelle un tiers insiste même si il n'y a pas de raison sécuritaire à un tel choix est une config précédamment rencontrée. En d'autres termes le tiers client peut s'assurer via le tiers de confiance que tu as bien toujours la même config que celle créée précédamment. il ne peut en aucun cas en déduire ton OS, tes disques durs, ta carte graphique ou quoi que ce soit d'autre.
b)Toutes les clefs accessibles de l'extérieur sont migrables. En d'autres termes tu peux parfaitement déplacer la clef de ton tiers client d'une zone à une autre. dans ce cas tu nepourras plus être validée par remote attestation, mais tu pourras toujours lire l'ensemble des doccuments qui ont étés cryptés avec cette clef (ce qui limite vachement l'utilisation dans le cadre du DRM). Si tu veux continuer à faire de la remote attestation, tu peux aussi simplement copier la clef. La copie dans la zone certifiée sera toujours valide aux yeux du tiers client, la copie dans une zone plus laxiste sera utilisable comme bon te semble.
Au final cette technique n'est utile que pour un admin qui veut vérifier que ses machines n'ont pas étés compromises avant de les admettre sur le réseau (par exemple). A part çà...-
[^]Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par free2.org (page perso, ) le 19/06/2005 à 23:58. (lien). Évalué à 2.Désolé mais les documents TCG et IBM que je viens de citer et qui sont en lignes, ainsi que les documents d'intel que j'ai lu il y a 2 ans et dont j'avais commuiqué l'uRL sur linuxfr et à toi sont très clairs:
le remote attestation de la plateforme est bien la communication des hashs des composants de cette plateforme, ce qui dans les définitions TCPA a toujours correspondu au matériels et aux logiciels de cette plateforme.-
[^]Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par Jerome Herman () le 20/06/2005 à 10:39. (lien). Évalué à 3.le remote attestation de la plateforme est bien la communication des hashs des composants de cette plateforme
Donc pour toi la puce envoie directement les hashs brut de fonderie au tiers de confiance (ou alors directement au tiers client )?
Si tu prend tes propres docs (en version PDF de préférence, les schémas sont illisibles sur la version HTML) Notamment celui ci : http://byte.csc.lsu.edu/~durresi/7502/reading/rc23064.pdf(...) à la page 8 figure 2 section "remote attestation"
on y voit clairement que les mesures métriques effectuées par les agents ne sortent jamais de la puce. Le service d'attestation recoit une demande sous forme de challenge et renvoit une response. C'est un cas très classique de preuve par déchiffrage de message dans le cadre d'une certification.
De toute façon, même si les hashs sortaient ils seraient inutilisables. tout d'abord parceque les hashs sont différents (très) sur chaque plateforme, et ensuite parcequ'ils varient d'un boot à l'autre (et oui une carte graphique à 50°c n'aura pas le même hash que la même carte graphique à 20°c). C'ets pas un jeu complexe d'échange entre le TPM et les agents de mesures que le matériel est certifié. (Un peu comem pour les empreintes digitales, le TPM cherche des "points de correspondance" quand il en a suffisament il valide, si ca ne marche pas il rejette).
Bref l'interet de faire sortir les hashs de la puce TCPA est rigoureusement nul.
P.S : j'ai beau chercher je ne vois nulle part mention de l'idée de faire sortir les hash de la puce.-
[+] [^]Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par free2.org (page perso, ) le 20/06/2005 à 11:11. (lien). Évalué à -1.et oui une carte graphique à 50°c n'aura pas le même hash que la même carte graphique à 20°c
Du délire total :)-
[^]Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par Jerome Herman () le 20/06/2005 à 11:28. (lien). Évalué à 4.Reprend la doc (la grosse, celel qui fait 300 pages) si tu l'as encore et fait une recherche sur "control points" et "aging materials". On y explique pourquoi un disque dur qui commence à rendre l'âme (tourne moins vite, certains clusters en erreur) ou une barrette mémoire veillisante (ECC qui tourne sur certaines zones, temps de latence en augmentation) vont être repérés par la puce TCPA mais en vont pas pour autant causer le verrouillage de la puce.
-
[^]Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par free2.org (page perso, ) le 20/06/2005 à 11:34. (lien). Évalué à 2.Ces histoires ridicules ont vraiment bien peu d'importance par rapport notamment à aux identifications de l'OS et des processeurs , qui elles ne dépendront surement pas de l'age du HDD ou du capitaine :) Et ce afin de s'assurer que l'OS et le proc ont bien le DRM que le provider requiert.
D'ailleurs puisque on parle des docs d'origine, moi j'avais réupéré ça, sur l'ancien site TCPA (aujourd'hui offline) et toi aussi je le sais puisque je t'en avais communiqué l'URL:
"a provider
will need to know that the remote platform is trustworthy" "The TCPA
system reports the metrics and lets the challenger make the final decision regarding the
trustworthiness of the remote platform." http://www.trustedcomputing.org/docs/Credible_Interoperability_0207(...)
-
-
-
[^]Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par free2.org (page perso, ) le 20/06/2005 à 11:25. (lien). Évalué à 2.http://66.102.9.104/search?q=cache:https://www.trustedcomputinggrou(...)
TCG features could potentially enable a situation in which users are essentially
“forced” to use the TCG mechanism in order to have access to a set of services. This could result from “bundling” — where a single large provider of services could use the combination of its role as a major provider with the TCG remote attestation
capability to ensure that the user is employing a configuration that the provider
insists upon, even when there is no security reason for such a choice. Another
situation that can arise is where a significant portion of the providers of a particular
service could use their market clout (the fact that they constitute a majority of
providers of that particular type of service) to essentially force the use of TPM
Alors je t'explique: another cela veut dire une autre situation.
Par remote attestation ils n'entendent donc simplement pas le fait de forcer quelqu'un à montrer qu'il a TPM mais bien de forcer quelqu'un à montrer les hash de sa configuration.
Ces hashs sont d'ailleurs aussi évoqués par ce white paper d'IBM, pourtant destiné à faire la promotion de TCPA:
http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf(...)-
[^]"remote attestation" avouée clairement par why_tcpa d'IBM
Posté par free2.org (page perso, ) le 20/06/2005 à 11:50. (lien). Évalué à 2.JE corrige c'est dans ce document IBM pro TCPA:
http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf(...)
The TCPA chip is not particularly suited to DRM. While it does have the ability to
report signed PCR information, and this information could be used to prevent play
unless a trusted operating system and application were in use, this type of scheme
be a nightmare for content providers to manage. Any change to the BIOS, the oper
system, or the application would change the reported values. How could content
providers recognize which reported PCR values were good, given the myriad platfo
operating system versions, and frequent software patches?
L'excuse donnée par ce document de 2002 fait aujourd'hui sourire:
oui mais c'est dur car il faudrait stocker les hashs des BIOS des OS dans une grosse base de donnée.
Ce dernier argument n'est pas sérieux avec la puissance actuelle des clusters de PC bon marchés. (cf les clusters de Google).-
[^]Re: "remote attestation" avouée clairement par why_tcpa d'IBM
Posté par Jerome Herman () le 20/06/2005 à 12:25. (lien). Évalué à 2.While it does have the ability to
report signed PCR information
Avant d ecommencer, j'attire juste ton attentio que la puce TCPA ne renvoit pas les hash mais créé des reports signés en dfonction du PCR. On est donc bien dans le cadre challenge/response. Ouf.
L'excuse donnée par ce document de 2002 fait aujourd'hui sourire:
oui mais c'est dur car il faudrait stocker les hashs des BIOS des OS dans une grosse base de donnée.
C'est clair, ca fait sourire, on voit tout à fait uen base de données contenir les quelques huit milliards de config bios d'uen machine, l'infinité des partionnements valides et se mettre à jour au fur et à mesure des mises à jour windows ou du lecteur de contenu. Ca fait quoi 2-3 To par utilisateurs grand maximum. Une paille quoi.
Tout ca pour quoi ? Empécher un utilisateur d'accéder à un contenu distant, tout en sachant que si il y accède une fois après authentification il pourra faire ce qu'il veut de la clef et la déplacer si besoin est dans une zone moins restrictive ? Ca vaut le coup.
Je ne comprend vraiment pas pouquoi l'ensemble des magnats de la vidéos et du son ne se sont pas jetés sur cette magnifique opportunité.
Même google ne donne que 2go par utilisateur, c'est environ le millième de ce qui serait nécessaire.-
[^]Re: "remote attestation" avouée clairement par why_tcpa d'IBM
Posté par free2.org (page perso, ) le 20/06/2005 à 13:49. (lien). Évalué à 2.signed PCR information, and this information could be used to prevent play
unless a trusted operating system and application were in use,
Tu nies l'évidence, c'est pathétique.-
[^]Re: "remote attestation" avouée clairement par why_tcpa d'IBM
Posté par Jerome Herman () le 20/06/2005 à 15:20. (lien). Évalué à 2.Tu nies l'évidence, c'est pathétique.
Moins pathétique que de modifier le sens à son avantage.
Comment a ton avis le matériel et le logiciel deviennent-ils "trusted" ? Surtout vu que la puce ne peut pas contenir de clefs préchargés autre que la vendor key qui ne peut authentifier que la puce elle-mêrme ?
Sans manipulation préalable de l'utilisateur c'est impossible. On a donc pas un système "out of the box." Ensuite le fournisseur a-t-il moyen de s'assurer de quelque façon que ce soit que la clef reste dans la zone dans laquelle il l'a mise ? Non...-
[^]Re: "remote attestation" avouée clairement par why_tcpa d'IBM
Posté par free2.org (page perso, ) le 20/06/2005 à 17:32. (lien). Évalué à 3.Je crois que tu es vraiment aveuglé. Il n'a y a rien à ajouter que de répéter l'avoeu d'IBM, cofondateur de TCPA/TCG et fabriquant de puces TCPA:
could be used to prevent play unless a trusted operating system and application were in use
C'est clair pour tous ceux qui le lisent, sauf pour ceux qui préfèrent ne pas comprendre.-
[^]Re: "remote attestation" avouée clairement par why_tcpa d'IBM
Posté par Jerome Herman () le 20/06/2005 à 20:00. (lien). Évalué à 2.could be used to prevent play unless a trusted operating system and application were in use
Ca peut être utilisé pour empecher la lecture a moins qu'un OS et une application de confiance ne soient utilisés.
J'ai prétendu le contraire ? Je dis juste que ca n'a rien a voir avec DRM. Tu te connectes à un site ou un service et pour afficher le contenu tu dois prouver que tu utilises bien l'OS et l'appli qui sont connus de ce service (Par exemple le même que celui qui a été utilisé pour payer par carte bleue l'abonement au site).
Et je ne vois vraiment pas le rapport avec DRM, qui consiste à prévenir la copie ou la diffusion de fichiers existant en local sur la machine du client.
Ok je ne pourrais pas lire le contenu si je ne suis pas authentifié. Et alors ? Ca m'empêche de booter ? Ca 'empêche de ripper mes CDs ? Ca m'oblige à utiliser windows ? Non
La seule chose que ca m'oblige à faire c'est à revenir sur le site de la même façon que celle que j'ai utilisé au moment ou j'ai été authentifié.-
[^]Il était temps !
Posté par free2.org (page perso, ) le 20/06/2005 à 20:07. (lien). Évalué à 3.Tu te connectes à un site ou un service et pour afficher le contenu tu dois prouver que tu utilises bien l'OS et l'appli qui sont connus de ce service
Ah enfin, tu admets que TCPA fait bien cela. Je te signales que tu as bien du poster + de 10 messages dans ce thread pour dire le contraire !
Et je ne vois vraiment pas le rapport avec DRM,
Cherche bien... D'autant plus que cela a déja été évoqué dans ce thread aussi: l'OS qu'on t'oblige à utiliser sera évidemment un OS qui va t'empecher de faire ce que tu veux avec ce contenu. Ce qui est la définition exacte de Digital Rights Management.-
[^]Re: Il était temps !
Posté par Jerome Herman () le 20/06/2005 à 20:55. (lien). Évalué à 3.Ah enfin, tu admets que TCPA fait bien cela. Je te signales que tu as bien du poster + de 10 messages dans ce thread pour dire le contraire !
Mais je n'ai JAMAIS dit le contraire. J'ai même dit dès le départ que c'était identique au fonctionement des certificats. Tu n'as pas ton certificat tu ne rentre pas.
D'autant plus que cela a déja été évoqué dans ce thread aussi: l'OS qu'on t'oblige à utiliser sera évidemment un OS qui va t'empecher de faire ce que tu veux avec ce contenu. Ce qui est la définition exacte de Digital Rights Management.
Mais le provider NE PEUT PAS savoir quel OS j'ai. A moins d'être physiquement présent sur ma machne et de faire les manips avec moi.
La seule chose qu'il puisse savoir c'est si j'ai le MEME os que celui utilisé une fois précédente.-
[^]Re: Il était temps !
Posté par free2.org (page perso, ) le 21/06/2005 à 02:03. (lien). Évalué à 3.Mais le provider NE PEUT PAS savoir quel OS j'ai.
Bon apprends l'anglais et relis les documents que j'ai cité dans ce thread, dont
"The TCPA
system reports the metrics and lets the challenger make the final decision regarding the
trustworthiness of the remote platform."
Dans les metrics il y a le hash exact de l'OS. Dans le cas d'un OS drm non modifié, ce sera toujours le meme hash.
-
[^]Re: Il était temps !
Posté par free2.org (page perso, ) le 21/06/2005 à 02:12. (lien). Évalué à 2.Mais le provider NE PEUT PAS savoir quel OS j'ai.
Désolé mais le hash d'un OS drm non modifié est le meme tout le temps.-
[^]Re: Il était temps !
Posté par Jerome Herman () le 21/06/2005 à 08:23. (lien). Évalué à 2.Désolé mais le hash d'un OS drm non modifié est le meme tout le temps.
Sauf que
a) Le hash ne sors jamais de la puce
b) Chaque TPM est différent et chaque lot de measuring agent est différent.
Le hash est le même au sein d'une même puce, mais il va être complètement différent de celui de la puce d'à coté. Comment faire de la remote attestation si toutes les puces confrontées au même environnement renvoient les mêmes infos ?
Et au passage pour le post du dessus, metrics ca veut oujours dire "méthodes de mesures" et non pas mesures.-
[^]Re: Il était temps !
Posté par free2.org (page perso, ) le 21/06/2005 à 09:46. (lien). Évalué à 2.Tu es incroyable ! Le hash fait partie des metrics et est donc envoyé !
-
[^]Re: Il était temps !
Posté par free2.org (page perso, ) le 21/06/2005 à 13:31. (lien). Évalué à 1.Pour être précis, on sera dans une situation où le provider pourra exiger que l'utilisateur lui fournisse un PCR signé établi avec exactement le metric du bootloader d'un OS DRM.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
[^]Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par boubou (page perso, ) le 21/06/2005 à 19:14. (lien). Évalué à 2.Par exemple les licences MS ne sont pas du tout validées à distance et locké par PC. Du tout.
Euh, oui, mais c'est fait par du soft, contrairement au TPM qui est implémenté en hard et qui devait (à l'origine) être supporté par une puce "incrackable", c'est-à-dire resistant aux investigations matérielles. Ca fait quand même une différence non négligeable, non ?
-
-
-
-
-
-
-
-
-
-
[^]Re: et oui les TPM ...
Posté par Jerome Herman () le 18/06/2005 à 20:52. (lien). Évalué à 5.Ca a l'air de ressembler a TCPA
C'est TCPA
c'est le retour de Palladium/NGSCB ?
Rien a voir. Palladiu vise à pouvoir certifié le matériel et le logiciel de façon globale (ie que telle appli et tel matériel sont bien conformes à ce qui est annoncé), TCPA/TPM n'a pas d'autre but que de certifier la cohérence d el'ordi par rapport à lui même. (et maintenant qu'IBM laisse tomber sa division x86 ca ne dervait pas changer).
A titre d'exemple, pour ce que l'on sait de palladium (c'est à dire pas grand chose) il devrait être capable de detecter un disque dur "splitté", c'est à dire un réseau de disque dur en mirroring hardware,d'un disque dur standard. Ceci dans le but d'éviter qu'un fichier DRM copié depuis internet ne se trouve dupliqué n fois suite à un seul paiement.
TPM d'un autre coté ne possède pas d'information de ce type, il signe quand on le lui demande et garde le résultat en interne (il est impossible de faire sortir une signature hardware/software de TPM). Aussi semblable soient-ils, deux disques durs lui apparaitront comme différent, il est donc impossible de certifier "globalement" un ensemble de périphériques.
-
-
-
[^]Re: et oui les TPM ...
Posté par Matthieu C () le 18/06/2005 à 16:46. (lien). Évalué à 5.Au passage il existe un emulateur pour ceux qui ne possede pas la puce : http://developer.berlios.de/projects/tpm-emulator/(...)
-
[^]Re: et oui les TPM ...
Posté par Jerome Herman () le 18/06/2005 à 20:42. (lien). Évalué à 3.a quoi ca va servir
Personellement je m'en sers déjà et depuis un bon moment, les TPM sont un coffre à clef qui permet de mettre toutes les clef privées dans une boite noire accessible seulement si un certains nombre de conditions sont remplies.
Les condition peuvent être soit un boot particulier (si quelqu'un boote depuis un autre disque dur, depuis une clef USB ou depuis une disquette le coffre ne souvre pas), soit simplement une identification connaissance (par mot de passe saisi par l'uilisateur par exemple).
Ca fait un petit moment que sur mon laptop IBM mes clefs sont dans la boite noire.
Il est bon de rapeler qu'en l'état actuel des choses il est impossible d'utiliser TPM pour empecher de booter un OS ou pour s'assurer qu'un OS certifié "globalement" (c'est à dire que la signature n'a pas été faite sur votre portable) est le seul bootable.-
[^]Re: et oui les TPM ...
Posté par briaeros007 () le 18/06/2005 à 21:35. (lien). Évalué à 5.enfin une cle usb peut aussi contenir toutes tes cles prives . C'est rapide et c'est sur. en plus c'est mobile si tu as un autre ordi de confiance.
Quand tu pars tu recup ta cle usb et pouf plus de problème. Et pas d'ouverture possible a un palldium quelconque.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: et oui les TPM ...
Posté par Jerome Herman () le 18/06/2005 à 22:19. (lien). Évalué à 4.Si je met toutes mes clefs privées sur ma clef USB, j'ai pas interet à la perdre ma clef (ou à me la faire piquer). Si je mets toutes mes clefs dans une puce TCPA sur mon portable, le mec qui m pique mon portable sera bien avancé. Il luis era impossible de sortir les clefs de la zone sans le mot de passe admin de la puce (et même comme çà il pourra juste les transférer sur une autre puce et sera incapable de les lire en clair).
Il n'y a déjà pas d'ouverture possible à Palladium avec les versions actuelles de TPM. C'est inutilisable pour la certification de matériel (toutes les puces et tous les matériels génèrent des hash différents non recoupables - c'est même le but premer de la puce). C'est inutilisable pour l'authentification croisée (chaque "client" TCPA se retrouve dans sa zone personelle avec un identifiant de zone qui change à chaque fois) . C'est Inutilisable pour le DRM (toutes les clefs challengeables sont copiables/migrables/déplaceable - Dieu merci).
Bref pour faire du controle à distance et de la certification globale avec çà bonjour.-
[^]Re: et oui les TPM ...
Posté par Romain (page perso, ) le 18/06/2005 à 23:00. (lien). Évalué à 4.>Si je met toutes mes clefs privées sur ma clef USB, j'ai pas interet à la
>perdre ma clef (ou à me la faire piquer). Si je mets toutes mes clefs
>dans une puce TCPA sur mon portable, le mec qui m pique mon
>portable sera bien avancé.
Rien n'empèche de mettre un mdp global sur la clef usb via un loopfs (ou autre) de plus tu peux choisir l'algo, la longeur de clef etc...
>Il luis era impossible de sortir les clefs de
>la zone sans le mot de passe admin de la puce (et même comme çà il
>pourra juste les transférer sur une autre puce et sera incapable de >les lire en clair).
Alors là ca reste à voir le nombre de gadgets révolutionnaires bourrés de backdoors et bugs divers ne montrent aucune confiance.
Franchement ca pue, ca fais "mettez tous vous passwords là dans la boiboite comme ca on a même plus besoin de les chercher"...-
[^]Re: et oui les TPM ...
Posté par Beretta_Vexee () le 19/06/2005 à 13:14. (lien). Évalué à 7.Avec loopfs, tes Clées et ton systéme crypto devront être décoder en mémoire a un moment ou un autre pour être utiliser. TPM est plus similaire a une carte a puce, la gestion des clés et autre ne sorte jamais de la puce c'est la toute la force du systéme, les clés ne sont jamais accessible a quelque moment que ce soit, elles sont gérées, générés et utilisés dans la puce et jamais par le processeur centrale dans de la RAM, et quand elles sont transférés c'est uniquement d'une puce TCPA a une autre puce TCPA de maniére coder.
En gros avec TCPA tu fait l'économie d'un lecteur de carte ( 100¤ ) et d'une smart card avec des fonction de module de sécurité ( 15¤ la carte ), soit 115¤ d'économie rien qu'en utilisant une techno déjà présente dans ton portable.--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]Re: et oui les TPM ...
Posté par briaeros007 () le 19/06/2005 à 13:59. (lien). Évalué à 3.j'avais compris que le truc de crypto c'etait "que dans la puce" mais tu ne repond pas du tout a ce que j'ai dis :
C'est pas parce que c'est que dans une puce que c'est plus sécurise : quid des fonctions de hashages qui ont des collisions maintenant ?
Alors tu me dis que ca sort pas de la puce. Mais comme dis précédement ca me fait une belle jambe que ca sorte pas de la puce ; sachant que les documents a chiffrer il faudra bien les amener a la puce. Et vu que tu as si peu confiance en ton pc ; on peut tres bien sniffer le bus de données !
Et de toute facon vu que tu dis qu'il y a une possibilite de sniffer; alors dans ce cas il y a aussi une possibilité que la puce ait une backdoor ou autre !
Maintenant supposons qu'elles sont transferer de manière "coder" entre deux puces tcpa. Qu'est ce qui empeche d'avoir une puce "tcpa" virtuelle; Les fonctions etant bijectives oh tiens ca alors j'ai la clé en clair ; je me suis pourtant juste fait passer pour une autre puce...
donc dans tous les cas aucun interet particulier avec cette "superbe" puce tpm, si ce n'est d'offrir qu'une illusion de sécu que l'on a bien plus par les systèmes decris au dessus.
Ensuite un lecteur de carte a puce 100 euros ? on doit pas avoir les meme fournisseurs
perso sur un catalogue de selectronic de 2004 j'en trouve a 30 euros ...
soit 35 euros de pseudo economie car une carte a puce est quand meme sacrément plus mobile qu'un portable ...
Je rappelle que la sécurite maximale d'un système ets toujours la sécurite maximale du plus FAIBLE maillon !
Donc si tu estime que l'os est le plus faible maillon ; que ce soit dans une carte a puce , une puce ou autre ; sachant que tu utilise l'os ; tu auras toujours la meme sécu.--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: et oui les TPM ...
Posté par Beretta_Vexee () le 19/06/2005 à 14:33. (lien). Évalué à 3.C'est pas parce que c'est que dans une puce que c'est plus sécurise : quid des fonctions de hashages qui ont des collisions maintenant ?
Je ne vois pas le rapport avec les fonctions de hashages, les fonctions de hashages ont toujours eux des collision ( c'est quand le calcule pour trouver ces collisions devient possible en un temps raisonnable que cela devient un problème ).
Si les clés sont cantonnés dans la puce, les risque de vole de clé sont presque nul, c'est la que ce trouve le gain de sécurité, maintenant si tu n'as pas confiance dans les fabricants de la puce en effet je ne vois pas ce qui pourrait te conviancre et te conseillerait de jeter au plus vite ta carte bleue, ton téléphone portable et autre.
Alors tu me dis que ca sort pas de la puce. Mais comme dis précédement ca me fait une belle jambe que ca sorte pas de la puce ; sachant que les documents a chiffrer il faudra bien les amener a la puce. Et vu que tu as si peu confiance en ton pc ; on peut tres bien sniffer le bus de données !
Le systéme n'est pas une protection absolue, la protection absolue n'existe pas, de plus TCPA ne s'occupe pas spécialement de la protection des donnés une fois décrypté. TCPA se focalise sur la protections des clés et dans ce domaine c'est un gain incontestable en matière de sécurité. De plus si tu utilise toutes les fonctions de vérification d'intégrités de TCPA, cela limite fortement les chances pour qu'on sniffe ton document a un endroit ou un autre de la chaine ( bien que des attaque physique comme le sniffing du bus reste possible ).
Et de toute facon vu que tu dis qu'il y a une possibilite de sniffer; alors dans ce cas il y a aussi une possibilité que la puce ait une backdoor ou autre !
On peut avori le même raisonnement avec tous les systémes, qui te dit que ton processeur actuel n'intégre pas une backdoor ? La protéction absolue n'existe pas, mais est ce pour autant que l'on doit abandonner tous les systèmes de protection pour autant ? Doit on dire non a un système plus robuste sous le prétexte qu'il n'est pas « la protection absolue et universel ? ». En effet TCPA ne peut rien contre les personnes qui lisent par dessus ton épole ou si un pirate a sortie un train de cable de ton PC pour sniffer directement le bus donné... dans les autres situation TCPA renforce la sécurité de tes clés et donc de tes donnés.
Maintenant supposons qu'elles sont transferer de manière "coder" entre deux puces tcpa. Qu'est ce qui empeche d'avoir une puce "tcpa" virtuelle; Les fonctions etant bijectives oh tiens ca alors j'ai la clé en clair ; je me suis pourtant juste fait passer pour une autre puce...
Parce que les puces TCPA contiennent une certificat numérique, comme lors d'une connections SSL, les deux puces vont vérifiés qu'elles ont bien affaire a une puce TCPA avant de négocier et d'établir le canal crypté pour le transfére des clés. Donc pour que ta puce virtuelle ( emulateur ) fonctionne il faut d'abord que tu réussice a récupérer le certificat d'une puce TCPA existante. Vue que ce certificat est dans la puce et le mécanisme de signature et d'identification sont costaux je te souhaite bonne chance.
La encore comme pour verisign ou tous autre CA, certificat ou autre, la compromission est possible, mais fort improbable.
donc dans tous les cas aucun interet particulier avec cette "superbe" puce tpm, si ce n'est d'offrir qu'une illusion de sécu que l'on a bien plus par les systèmes decris au dessus.
Je ne sais pas qui s'illusionne en stockant ses clés ou son pad lock en claire ou avec plus ou moin de cryptage sur un disque dur.
Ensuite un lecteur de carte a puce 100 euros ? on doit pas avoir les meme fournisseurs
perso sur un catalogue de selectronic de 2004 j'en trouve a 30 euros ...
soit 35 euros de pseudo economie car une carte a puce est quand meme sacrément plus mobile qu'un portable ...
On parle bien de carte a puce cryptographique la ? Parce qu'a 30¤ j'achéte de suite. Plus sérieusement une carte a puce en mesure de faire du RSA et de la signature cela coute au minimum de 15-20¤ la carte et je sais de quoi je parle. Pour 30¤ le mieux que tu puisse trouver c'est un lecteur d'empreinte digital sans pad lock, ou un lecteur de carte d'identification ( carte incapable de gérer des certificats genres X.509 ou des clés RSA ).
Je rappelle que la sécurite maximale d'un système ets toujours la sécurite maximale du plus FAIBLE maillon !
Donc si tu estime que l'os est le plus faible maillon ; que ce soit dans une carte a puce , une puce ou autre ; sachant que tu utilise l'os ; tu auras toujours la meme sécu.
Bof en cas de compromission, tu te fera voler ton keyring et le hackeur pourra travailler a le decoder bien tranquillement chez lui, avec TCPA il ne pourra pas te voler ton keyring, c'est déjà un plus important.
Aprs bien évidement tu vas me dire qu'il est passé root, et qu'il va dumper la mémoire ( et transférer le bon Go du dump furtivement ) au bon moment et partir a la chasse de ton document dans le dump etc etc ... Personnellement je trouve ce sénario moins probable que le vole de clé, de plus il serait tout autant imaginable avec un solution sans TCPA.
Donc oui encore une fois TCPA n'est pas la protection ultime, mais il offre un gain énorme dans le domaine de la protection des clés.--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]Re: et oui les TPM ...
Posté par briaeros007 () le 19/06/2005 à 14:49. (lien). Évalué à 3.Je ne vois pas le rapport avec les fonctions de hashages, les fonctions de hashages ont toujours eux des collision ( c'est quand le calcule pour trouver ces collisions devient possible en un temps raisonnable que cela devient un problème ).
Normes de sécu : 2^80. on considère donc que si on ne peut pas trouver de collisions en moins de 2^80 calculs alors elle n'a pas de collisions (on ne peut pas les trouver). Je reconnais que c'est un abus de langage mais a part ca...
Si les clés sont cantonnés dans la puce, les risque de vole de clé sont presque nul, c'est la que ce trouve le gain de sécurité, maintenant si tu n'as pas confiance dans les fabricants de la puce en effet je ne vois pas ce qui pourrait te conviancre et te conseillerait de jeter au plus vite ta carte bleue, ton téléphone portable et autre.
1°) j'ai pas de telephones portables.
2°) la cb est sur un système spécifique ; et n'est pas "ma cle privéé" mais une clé privé que me fournis la banque. Si il y a une merde de sécu avec leurs système je suis assure.
On peut avoir le même raisonnement avec tous les systémes, qui te dit que ton processeur actuel n'intégre pas une backdoor ?
Un backdoor dans un processeur? faut qu'on m'explique la.
La protéction absolue n'existe pas, mais est ce pour autant que l'on doit abandonner tous les systèmes de protection pour autant ? Doit on dire non a un système plus robuste sous le prétexte qu'il n'est pas « la protection absolue et universel ? ».
C'est toi qui dis que c'est le plus robuste. Je ne suis pas d'accord avec ca, et comme faisait remarquer quelqu'un ; les puces d'aide à la crypto ca existait avant le tcpa; donc non ce n'est certainement pas le plus robuste. Une petite aide : est ce que dans les snle ils utilisent des portables equipes de tcpa?
En effet TCPA ne peut rien contre les personnes qui lisent par dessus ton épole ou si un pirate a sortie un train de cable de ton PC pour sniffer directement le bus donné... dans les autres situation TCPA renforce la sécurité de tes clés et donc de tes donnés.
Dans les autres situations ? Ah oui lesquelles? On peut faire des sniffer qui envoie les données d'un point de vue radio par exemple ; hop tu le remarque pas a moins de tout demonter etc...
Non franchement je vois pas ce qu'apporte tcpa en plus par rapport a un système assez sur :
cles usb pour stocker le truc.
A la rigueur tripwire sur un cdr si tu veut verifier ton os .
et voila aussi sur que tcpa sans avoir tout les rsiques que cela cause.
Donc oui encore une fois TCPA n'est pas la protection ultime, mais il offre un gain énorme dans le domaine de la protection des clés. c'est pas en lerepetant plus de fois qu eca va devenir vrai.
Je susi tout a fait d'accord avec une aide a la crypto etc... Mais qu'ils nous fournisse le hdl de leurs puces , le code utilisé et que l'on puisse choisir le CA.--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
[^]Re: et oui les TPM ...
Posté par pshunter () le 20/06/2005 à 12:13. (lien). Évalué à 4.Si deux puces ont besoin d'un certificat tiers pour établir un canal sécurisé pour transférer des clés, est-ce que ça veut dire qu'elles contiennent des clés privées qui appartiennent à une autre personne que le propriétaire de ladite puce ? Dans ce cas je trouve ça assez dérangeant. De toute façon, je trouve inacceptable qu'on ne puisse pas récupérer ses propres clés privées en clair.
De plus, beaucoup de gens qui sont favorables à cette technologie semblent indiquer que le niveau de sécurité sera globalement plus élevé. Cela implique que la populace aura une plus grande confiance dans le système et que donc les dégâts seront plus grands en cas de faille ou de mauvaise utilisation. Il faut aussi prendre cela en compte dans l'acceptation de cette technologie. Parfois, trouver que c'est trop sûr peut être un argument valide...
En ce qui concerne les cartes à puce, beaucoup de gens se font des illusions sur la sécurité que ça apporte. En fait, le niveau de sécurité supplémentaire apportée par l'utilisation d'une carte à puce cryptographique n'est pas très élevé par rapport à une disquette contenant la clé privée, car dans les deux cas le système doit être utilisé sur une machine dont vous avez le contrôle. Sinon, un attaquant peut très bien
a) dans le cas de la disquette récupérer la clé et le mot de passe pour la décrypter
b) pour la carte à puce le code PIN/mot de passe et faire signer n'importe quoi à la carte tant qu'elle est dans le lecteur.
Dans tous les cas, puisque vous devez avoir le contrôle de la machine, vous pouvez aussi stocker la clé dessus. Les attaques se limitent alors au vol de
a) la disquette et l'attaquant doit casser le cryptage
b) l'ordinateur, même attaque mais plus difficile d'emporter une machine ou son disque dur
c) la carte à puce et là une analyse électronique s'impose.
Dans tous les cas il est plus efficace de torturer le possesseur ;)
-
-
-
-
-
[^]Re: et oui les TPM ...
Posté par briaeros007 () le 19/06/2005 à 08:30. (lien). Évalué à 6.pour continuer sur le post de Romain
As tu une ne serait ce qu'une preuve partielle de sécu avec ta pupuce?
Serait t'il possible de tester les mots de passes en brute force ?
Le mot de passe que tu lui a passe est ce toi qui la choisis ? si oui il y a une possibilite de le modifier , est ce que cette possibilité est suffisament protéger niveau hardware ?...
Je suis desole mais si tu veux vraiment faire mumuse tu te fais du one time pad sur ta cles usb. Et comme ca elle est lisible que depuis ton ordi . (Le one time pad; si la cle est vraiment aléatoire est juge comme inconditionnellement sur).
Personnellement j'ai plus confiance en un truc ouvert qu'on sait comment ca marche plutot qu'a une boite noire. D'ailleurs a peu pres toutes les boites noires en crypto se se font decrypter. La non obfuscation c'est un principe .
et même comme çà il pourra juste les transférer sur une autre puce et sera incapable de les lire en clair
Il y a forcémenet un moment ou elles sont en clairs . rien ne l'ui empeche d'avoir une puce qui se fait passer pour uen puce tcpa et qui est en réalité juste une grosse bd qui les stockent en clair...
Pour le fait que ce ne soit pas "utilisable" pour palladium ou autre, je suis desole mais c'est toi qui le dis, tant qu'on ne sait pas ce qu'il y a reelement dans la boite , je ne leur ferait pas confiance .--
Subete ga wakatta toki…watashi ga anta wo korosu.-
[^]Re: et oui les TPM ...
Posté par Antoine () le 19/06/2005 à 13:27. (lien). Évalué à 3.Je suis desole mais si tu veux vraiment faire mumuse tu te fais du one time pad sur ta cles usb. Et comme ca elle est lisible que depuis ton ordi . (Le one time pad; si la cle est vraiment aléatoire est juge comme inconditionnellement sur).
Pardon mais la clé du one-time pad (masque jetable), qui doit être de la même longueur que les données chiffrées, tu la stockes où ? Sur une autre clé USB ?
:)-
[^]Re: et oui les TPM ...
Posté par briaeros007 () le 19/06/2005 à 14:04. (lien). Évalué à 2.sur ton pc .
Sachant que tu stocke a des endroits differents la clés usb et le pc , qu'ils ne sont ensembles que quand tu t'en sers ; et que tu regenere un masque a chaque fois ....
Il faut que la personne ait a la fois ton pc et ta cle usb pour pouvoir s'en servir ; ou qu'il arrive a te subtiliser les deux avant que tu t'ens serve...
Maintenant si tu n'as pas un minimum de confiance dans ton pc ; alors la tu ne devrais pas avoir confiance non plus confiance dans ta puce tcpa :)--
Subete ga wakatta toki…watashi ga anta wo korosu.
-
-
[^]Re: et oui les TPM ...
Posté par Beretta_Vexee () le 19/06/2005 à 13:39. (lien). Évalué à 4.A tu une preuve partielle de la sécurité de ta carte bleu ?
Tu ne peux essayer de brutalforcer une une clé coder que si tu as la clé a disposition, hors avec TCPA la clé est bien cachés dans sa puce, et vue que la durée entre deux essais infructueux est protégés le brutal force est inéfficasse face a ce systéme.
Le mot de passe administrateur de la puce est défini par le propriétaire, il est tous a fait possible de le modifier. C'est d'ailler de mon point de vue le seul point faible du systéme, ce type d'opération devrait n'être entreprise par l'utilisateur qu'a partir d'un systéme de confiance ( boot a partir d'un CD ), pour être sur que son systéme n'est pas logger. Il y a bien évidament une protection hardware de disponible mais c'est cette dernières qui faire peure a beaucoup, c'est celle basé sur le transitonnal trust, CAD, la séquence de boot dont l'intégrité est vérifié par la puce. En gros tu par exemple défini dans ta puce que le mot de passe admin ne pouvait être modifié que si, la machine avait bien le même BIOS, le même bootloader et booté sur le même kernel afin d'être sur qu'il n'y a personne pour écouter le pass admin entre la prise de ton clavier de ta carte mère et la puce. Cette fonction n'est pas obligatoir et comme je l'ai dit plus haut on peut très bien le configurer pour un CD-ROM ( je pense même que c'est la solution la plus simple dans le cas d'un OS open source de geek, qui par définition fluctue pas mal ).
Donc pour résumé, tu peux changer le passe, des protections existe mais ne sont pas obligatoire, configurer la puce pour que le passe ne puisse étre changer que dans le cas d'un boot a partir d'un CD prévue pour semble étre une bonne solution. ( Dans tous les cas il faut bien évidement l'ancien mot de passe admin pour pouvoir modifier le dernier. )
Le problème du One time pad est identique a celui du crytpo loopback, les clés se baladeront en mémoire a un moment ou un autre, alors que TCPA est prévue pour que même un espion coder dans le Bios ne puisse pas les interceptés. TCPA est un systéme beaucoup plus résistant ( apres il est evident qu'un telle niveau de sécurité n'est pas nécessaire pour tous le monde, mais il ne faut pas oublier que TCPA a été consut avant tous pour les professionnel ).
Ce n'est pas une boite noire ou de l'ofuscation, c'est un module de sécurité comparable a toutes les cartes a puces, que ce soit pour de carte de payement, de téléphone, TV satélite ou autre. TCPA a même l'énorme aventage d'étre standardisé documenté et implémentable librement.
Il y a forcémenet un moment ou elles sont en clairs . rien ne l'ui empeche d'avoir une puce qui se fait passer pour uen puce tcpa et qui est en réalité juste une grosse bd qui les stockent en clair...
Tu pense sérieusement que deux puces spécialisé dans la cryptographie ne sont pas fichue d'établir un canal crypté avec authentification forte pour transférer les clés ? C'est d'alleur la grosse limitation des emulateurs TCPA, comme ils ne peuvent pas prouver qu'ils sont de réel puce TCPA ils ne peuvent pas récupérer les clés d'une puce TCPA.
Pour le fait que ce ne soit pas "utilisable" pour palladium ou autre, je suis desole mais c'est toi qui le dis, tant qu'on ne sait pas ce qu'il y a reelement dans la boite , je ne leur ferait pas confiance .
Palladium repose sur la technologie LaGrande, qui est fondamentalement différente de TCPA, LaGrande est un systéme de cryptage a la volé de la RAM, afint d'établir des canaux sécurisé au saint même de la machine, l'un des utilisation de telles canaux c'est le DRM ( plus de contenue en claire dans la ram, ou même vers la carte son ). Alors que TCPA ne s'occupe que de la protection des clés, et de la vérification de l'intégrité du systéme.--
Il relève de la responsabilité du lecteur de contrôler, par tous moyens, l'adéquation du message à ses besoins et de s'assurer qu'il ne causera pas de dommages aux personnes et aux biens.-
[^]Re: et oui les TPM ...
Posté par briaeros007 () le 19/06/2005 à 14:18. (lien). Évalué à 0.la carte bleu ? HAHAHAHAHAHAHA y en a qui ne correspondent pas aux normes de sécu actuelles. Meme pas besoin de preuves de sécu ...
Tu ne peux essayer de brutalforcer une une clé coder que si tu as la clé a disposition, hors avec TCPA la clé est bien cachés dans sa puce, et vue que la durée entre deux essais infructueux est protégés le brutal force est inéfficasse face a ce systéme.
Et la suite du post sur la possibilité de changer le mdp :
Eh oh on parle pas de moyens d'amateurs mais de pros ; cad avec engenerie inverse des puces toussa .... Donc les sois disantes protections laisse moi rire on va lui donner les infos qu'il veut ; il va nous autorise a lancer le bios pendant qu'on en lance un autre...
Le problème du One time pad est identique a celui du crytpo loopback, les clés se baladeront en mémoire a un moment ou un autre, alors que TCPA est prévue pour que même un espion coder dans le Bios ne puisse pas les interceptés.
Ton espion si il est code dans le bios; il les verra pas se balader les cles... c'est si il y a un sniffer sur les bus qu'il le verra :
le bios initialise le matos ; puis passe la main au mbr.
TCPA est un systéme beaucoup plus résistant ( apres il est evident qu'un telle niveau de sécurité n'est pas nécessaire pour tous le monde, mais il ne faut pas oublier que TCPA a été consut avant tous pour les professionnel ).
Ah oui comme dis au dessus : si j'arrive a modifier ton pc pour installer un sniffer des bus de donnés ; style que je vais me gener pour changer ta puce tcpa ....
Si j'arrive a installer un sniffer; j'aurais acces a TOUS tes documents donc je vais te faire croire que tu vas a ta puce tcpa alors qu'en réalité tu iras sur un simulateur de puce et donc que j'aurais la main mise sur le système.
Tu pense sérieusement que deux puces spécialisé dans la cryptographie ne sont pas fichue d'établir un canal crypté avec authentification forte pour transférer les clés ? C'est d'alleur la grosse limitation des emulateurs TCPA, comme ils ne peuvent pas prouver qu'ils sont de réel puce TCPA ils ne peuvent pas récupérer les clés d'une puce TCPA.
Le canal de cryptage auqu'un problème. Sauf que moi je me place APRES la communication :
Alice envoie a Bob la cle crypter de tel sorte que charlie puisse pas la recevoir. Ca on est tous d'accord ils sont capables de le faire.
Et maintenant qu'elle authentification peut te prouver que Bob n'est pas compromis ? Une athentification rsa ou semblable? Dans ce cas il faut voir quelle est le CA qui distribue les cles publiques. Et comme la CA est une entreprise privée qui fait les puces ; rien ne lui interdis de publier une cles publique et d'avoir une puce speciale avec la cle privee qui correpond et et cette puce stocke toutes les donnes trasnmises
-
-
-
-
-
Cette discussion est archivée, il n'est plus possible de laisser des commentaires.
Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.