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)
Aller plus loin
- Téléchargement (13 clics)
- Nouveautés (4 clics)
- Cogito (4 clics)
- PWC dans le noyau (17 clics)
- Mail de Linus Torvalds (12 clics)
- La dépêche de LWN.net (5 clics)
# 3 mois et demi, pas 5 mois :)
Posté par Brice Goglin . Évalué à 10.
[^] # Re: 3 mois et demi, pas 5 mois :)
Posté par Jérôme Pinot (site web personnel) . Évalué à 10.
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 . Évalué à 4.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 6.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: 3 mois et demi, pas 5 mois :)
Posté par Ellendhel (site web personnel) . Évalué à 8.
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 . Évalué à 0.
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é . Évalué à -1.
--
Jedaï
# Toujours pas de reiser4 !
Posté par Frédérick Diot . Évalué à 8.
Le reiser4 est toujours pas intégré !
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 10.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Toujours pas de reiser4 !
Posté par Frédérick Diot . Évalué à 1.
Je chercherai plutot à l'integrer dans ma gentoo.
[^] # Re: Toujours pas de reiser4 !
Posté par TazForEver . Évalué à 2.
[^] # Re: Toujours pas de reiser4 !
Posté par Ludovic F (site web personnel) . Évalué à 2.
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 . Évalué à 6.
Reiser4 est dedans.
[^] # Re: Toujours pas de reiser4 !
Posté par Julien MOROT (site web personnel) . Évalué à 5.
http://gentoo-wiki.com/TIP_Reiser4_Enabled_Live_CD(...)
[^] # Re: Toujours pas de reiser4 !
Posté par Jérôme Pinot (site web personnel) . Évalué à 10.
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 !
Posté par Anonyme . Évalué à 1.
[^] # Re: Toujours pas de reiser4 !
Posté par Pierre Jarillon (site web personnel) . Évalué à 1.
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 spongurex . Évalué à 4.
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 . Évalué à 4.
http://fr.wikipedia.org/wiki/ReiserFS(...)
http://linuxfr.org/2004/08/24/17094.html(...)
[^] # Re: Toujours pas de reiser4 !
Posté par Pierre Jarillon (site web personnel) . Évalué à 2.
[^] # Re: Toujours pas de reiser4 !
Posté par Brice Goglin . Évalué à 2.
Il y a Reiser4.
http://lkml.org/lkml/2005/6/21/98/index.html(...)
[^] # Re: Toujours pas de reiser4 !
Posté par Alan_T . Évalué à 2.
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 ...
Posté par roger21 . Évalué à 6.
> - 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 . Évalué à 10.
> 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 (site web personnel) . Évalué à 3.
[^] # Re: et oui les TPM ...
Posté par MsK` . Évalué à 7.
[^] # TPM, TCPA, TCG, "remote attestation"
Posté par free2.org . Évalué à 9.
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 . Évalué à 10.
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 . Évalué à 4.
Ç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 . Évalué à 4.
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 . Évalué à 6.
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 . Évalué à 10.
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...
[^] # "remote attestation" avouée par TCG et aussi par IBM, refuser = gagner
Posté par free2.org . Évalué à 3.
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 . Évalué à 6.
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.
[^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par free2.org . Évalué à -1.
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 . Évalué à 3.
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 . Évalué à 3.
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 . Évalué à 1.
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 . Évalué à 4.
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 . Évalué à 2.
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 . Évalué à 3.
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 . Évalué à -1.
Du délire total :)
[^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par Jerome Herman . Évalué à 4.
[^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par free2.org . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 3.
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 . Évalué à 2.
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 . É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 !
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 . Évalué à 3.
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 . Évalué à 3.
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 . Évalué à 2.
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 . Évalué à 2.
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 . Évalué à 2.
[^] # Re: Il était temps !
Posté par free2.org . Évalué à 1.
[^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn
Posté par boubou (site web personnel) . Évalué à 2.
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 . Évalué à 5.
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 Antoine . Évalué à 3.
Heu ? Tu as un lien ?
[^] # Re: et oui les TPM ...
Posté par Barnabé . Évalué à 1.
[^] # Re: et oui les TPM ...
Posté par M . Évalué à 5.
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . Évalué à 3.
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 . Évalué à 5.
Quand tu pars tu recup ta cle usb et pouf plus de problème. Et pas d'ouverture possible a un palldium quelconque.
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . Évalué à 4.
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 (site web personnel) . Évalué à 4.
>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 . Évalué à 7.
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.
[^] # Re: et oui les TPM ...
Posté par briaeros007 . É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 ?
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.
[^] # Re: et oui les TPM ...
Posté par Beretta_Vexee . É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 ).
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.
[^] # Re: et oui les TPM ...
Posté par briaeros007 . Évalué à 3.
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.
[^] # Re: et oui les TPM ...
Posté par pshunter . Évalué à 4.
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 . Évalué à 6.
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 .
[^] # Re: et oui les TPM ...
Posté par Antoine . Évalué à 3.
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 . Évalué à 2.
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 :)
[^] # Re: et oui les TPM ...
Posté par Beretta_Vexee . Évalué à 4.
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.
[^] # Re: et oui les TPM ...
Posté par briaeros007 . Évalué à 0.
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 en clair. Et boum tu t'es fait avoir.
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.
Et qu'est ce qui interdis a tcpa de gerer les cles de palladium ?
[^] # Re: et oui les TPM ...
Posté par Matthieu Moy (site web personnel) . Évalué à 5.
C'est clair. Le but de TCPA, c'est de repousser au niveau de hardware les possibilités d'attaques. Si tu peux attaquer physiquement la machine au point de sniffer ce qu'il se passe sur le bus, alors aucun système actuel ne peut te protéger vraiment.
Par contre, être protégé des attaques logiciel (qui incluent toutes les attaques distantes, entre autres) et des attaques matérielles les plus triviales (démonter le disque dur pour le monter sur un autre PC, booter sur une disquette, ...), c'est déjà pas mal.
L'exemple typique: Au boulot, j'ai une machine sur laquelle je ne suis pas root. Elle contient un certain nombre d'infos que je ne suis pas censé lire (clé privée SSH de la machine par exemple) ou modifier (/etc/sudoers). Aujourd'hui, si je veux le faire, je démonte le disque dur, je le monte sur une machine sur laquelle je suis root, et pas de problème. Avec un système de crypto classique, il faut une passphrase, donc une intervention de l'admin à chaque reboot. Bonjour la panique après une coupure de courrant par exemple.
[^] # TCPA n'est pas une solution magique pour des OS non secure
Posté par free2.org . Évalué à 3.
Et tu y accedes comment à tes données ? Par tes logiciels non ? C'est un énorme mensonge que de laisser croire que TCPA va protéger des failles de ton OS ou de tes logiciels. Meme les algorithmes de crypto et le générateur aléatoire de TCPA sont sujets à caution.
Comme je l'ai déja mentionné ici, des OS démontrés fiables à base de micronoyaux (comme EROS ou COYOTOS) sont bien plsu importants que d'avoir une puce dans laquelle on croit en croisant les doigts.
[^] # Re: et oui les TPM ...
Posté par free2.org . Évalué à 2.
Non, les données seront accéder par un OS et par des logiciels. Et s'ils contiennent des failles, ces données seront accessible à un tiers, que tu ais TCPA ou non.
[^] # Re: et oui les TPM ...
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
Oui, mais par un OS signé et par des logiciels signés (dans le cas que je cite, ça voudrait dire à priori signé par mon labo). Les clés privés contenues dans la puce ne sortent pas de la puce, donc, l'OS et les applies peuvent utiliser ces clés, mais pas les transmettre.
Par contre, là ou tu as raison, c'est que si il y a une faille dans les logiciels signés en question, on peut faire certains types d'attaques à distance. Dans tous les cas, c'est mieux d'avoir un OS fiable et sécurisé ;-).
[^] # Re: et oui les TPM ...
Posté par free2.org . Évalué à 2.
C'est en effet le véritable fondement de la sécurité et TCPA n'y changera rien.
Par contre as-tu pensé aux conséquences pour le grand public de la généralisation de puces qui permettent d'identifier "en toute confiance" le hardware et le software qu'il y a sur chaque ordinateur ?
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . Évalué à 2.
Ca serait une catastrophe.
C'ets pour çà que j'aime beaucoup la puce TCPA, parcequ'elle ne permet en aucun cas de faire ce genre de choses. Elle eprmet totu au plus de vérifier que l'on a bien à faire à une config identique à la config précédente. Et encore, dans la mesure ou l'admin de la puce joue le jeu.
[^] # Re: et oui les TPM ... le contraire
Posté par free2.org . Évalué à 2.
[^] # Re: et oui les TPM ... le contraire
Posté par Jerome Herman . Évalué à 2.
Pas un seul instant.
Le Hash ne sort pas des puces.
Si il sortait, il ne serait pas exploitable car dépendant de la plateforme au sens strict du terme (ie deux PC du même modèle, de la même année n'ont pas les mêmes hashs (testé avec migration de disque dur dont le numéro de série a été forcé sur des x31, ca marche pas))
Si il sortait et qu'il était exploitable, les clefs déposées dans la zone signée seraient déplaçables et donc exploitable à postériori (on aurait besoin d'un système propre pour obtenir les clefs) et après on fait ce que l'on veut)
Si le hash sortait, qu'il soit exploitable et que l'on ne puisse pas bouger les clefs il faudrait encore que le matériel environant (disque dur, carte son, écran etc) intégre aussi un TPM pour pouvoir dialoguer avec celui de la carte mère et se bloquer le cas échéant en cas de non conformité.
On a carrèment de la marge entre maintenant et la zone rouge.
[^] # Re: et oui les TPM ... le contraire
Posté par free2.org . Évalué à 2.
[^] # Re: et oui les TPM ... le contraire
Posté par Jerome Herman . Évalué à 2.
[^] # Re: et oui les TPM ... le contraire
Posté par free2.org . Évalué à 2.
Tu parles vraiment mal l'anglais !
"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."
Cela veut dire que les metrics sont envoyés au remote challenger qui décide en fonction de ces metrics.
La encore c'est clair pour tous sauf pour ceux qui préfèrent rester aveugle.
[^] # Re: et oui les TPM ... le contraire
Posté par Jerome Herman . Évalué à 3.
PERDU !
Bien essayé note, mais c'est pas ca du tout.
Reporting the metrics veut dire que lors d'une première authentification tu donne l'ensemble des metrics prise en compte par une identification.
Comment ca marche ?
a) Tu créé une identité qui possède un PCR (par exemple tu dis que tu prend le bios, le disque dur, le boot OS, et le lancement de l'appli TOTO)
b) Tu donne à un profl les droits sur cette identité
c) Tu te connectes au provider
d) Lors du remote authentification tu choisis ton identité
e) La puce TCPA renvoit les metrics utilisés par l'idendité (genre bonjour cette identité a été créé avec des metrics sur le bios, le disque dur, le boot OS, et le lancement de l'appli TOTO), en voici la clef publique.
f) Le provider décide si les metrics lui convienne, et si c'est le cas identifie ta macine à l'aide de la clef publique transmise, sinon il t'envoie bouler.
La encore c'est clair pour tous sauf pour ceux qui préfèrent rester aveugle.
Lire la doc aide....
[^] # Re: et oui les TPM ... le contraire
Posté par free2.org . Évalué à 2.
Par conséquent la remote attestation permettra bel et bien de savoir quel OS on utilise vraiment pour communiquer avec le remote provider afin que celui -ci puisse refuser de nous envoyer des fichiers si celle-ci ne lui plait pas (OS sans DRM strict)
[^] # Re: et oui les TPM ... le contraire
Posté par Jerome Herman . Évalué à 1.
Les metrics sont toujours disponibles, ce sont les measurements qui changent. La seule différence sera de voir si l'identité ou la zone protégée est accessible ou non.
On en revient toujours au problème de l'OS... Il est impossible de deviner l'OS. La seule chose que va savoir le provider est que
a) le TPM a certifié l'identité
b) l'identité certifié est basée sur les mesures de l'OS
Et c'est fini. Il ne saura rien de plus.
[^] # Re: et oui les TPM ... le contraire
Posté par free2.org . Évalué à 1.
unless a trusted operating system and application were in use
[^] # Re: et oui les TPM ... le contraire
Posté par free2.org . Évalué à 2.
[^] # Re: et oui les TPM ... le contraire
Posté par Larry Cow . Évalué à 3.
Si je prétends être un ordinateur (sans plus de précision), le moyen le plus évident de m'authentifier est de me donner un gros calcul à faire en un temps limité.
Si je prétends être un utilisateur (correspondant à un login donne), le plus courant est de vérifier que j'ai bien connaissance du mot de passe associé.
L'authentification en elle-même délivre le moins d'information possible pour réussir à obtenir une certitude.
[^] # Re: et oui les TPM ... le contraire
Posté par free2.org . Évalué à 3.
Il n'y a donc pas d'ambiguité.
[^] # Re: et oui les TPM ... le contraire
Posté par Jerome Herman . Évalué à 2.
L'attestation agent prend ces hashs et s'en sert pour créer une signature.
Les metrics sont le règles utilisés pour assurer les measurements. Ils désignent aussi bien les méthodes utilisés pour obtenir ces measurements que les ségments mesurés.
Bref quand le système fait un "report" des "metrics", c'es ce qui est mesuré et les méthodes de mesure qui sont renvoyés...
[^] # Re: et oui les TPM ... le contraire
Posté par free2.org . Évalué à 2.
[^] # Re: et oui les TPM ... le contraire
Posté par Barnabé . Évalué à 4.
[^] # Re: et oui les TPM ... le contraire
Posté par Psychofox (Mastodon) . Évalué à 7.
http://www.olivierclerc.com/dossiers/dossiers.php?id_dossier=20(...)
[^] # Re: et oui les TPM ... le contraire
Posté par Barnabé . Évalué à 2.
Merci, je ne connaissais pas.
[^] # Re: et oui les TPM ...
Posté par Matthieu Moy (site web personnel) . Évalué à 6.
C'est le véritable fondement de la sécurité absolue. Mais en sécurité informatique, limiter les dégats en cas de faille, c'est aussi très important. Par exemple, les histoire de pile non executable, le chroot, la "randomization" du pointeur de pile, ce sont tous des trucs qui ne servent à rien dans un monde parfait, pourtant, ils intéressent bien du monde ...
> Par contre as-tu pensé aux conséquences pour le grand public
Je suis le premier à râler contre les applications potentielles au niveau du DRM par exemple. Mais c'est un autre débat. Le fait qu'il y ai des applications qui ne te plaisent pas justifie le fait que tu rejette cette techno, mais pas que tu prétende qu'il n'y a pas d'applications intéressantes si c'est faux. (pour un particulier, je ne vois effectivement pas un intérêt énorme. Pour une entreprise qui veut se protéger des attaques par l'intérieur, l'intérêt me parait difficilement contestable)
Tu prends un decaideur pressé, tu lui dit "TCPA, c'est dangereux et ça sert à rien". Le mec est convaincu. Bon, cool, me dira-tu. Seulement, le même decideur pressé, le jour ou quelqu'un lui montre un intérêt pratique, il se dit que tu l'a bien eu, et rejette en bloc toute ton argumentation. Bref, je ne pense pas que le militantisme par le mensonge soit une bonne stratégie. (quand ce sont les "méchants" qui le font, on appelle ça du FUD ...)
[^] # conséquences graves passent avant le reste
Posté par free2.org . Évalué à 3.
Mais il faut classer les conséquences de la généralisation de TCPA par ordre d'importance.
Et la conséquence la plus importante est clairement la possibilité d'obliger le grand public à utiliser des OS DRM et du matériel DRM pour pouvoir se connecter. Dans un pays comme la France.
Je ne parle même pas des conséquences dans une dictature comme la Chine.
Ici ou là-bas, les conséquences de TCPA sont tellement graves pour la liberté de faire ce qu'on veut avec son ordinateur, que le reste devient très secondaire.
[^] # Re: conséquences graves passent avant le reste
Posté par Jerome Herman . Évalué à 3.
C'est typiquement ce que l'on apelle du FUD.
Comme les hash TPM sont imprévisibles (aléas vrai), la seule façon de faire du DRM via TPM c'est de
a) retirer les droits admin sur la puce à l'utilisateur final
b) à l'installation de la machine, faire générer à la puce TCPA toutes les signatures de PCR "interressante" (ie considérée comme valide pour le fournisseur) et les stoquer quelquepart.
c) Prier pour qu'il n'y ait jamais besoin de remplacer un disque, une carte graphique ou de mettre à jour le bios ou le système d'exploitation sinon la seule solution est de faire revenir la machine en usine et de faire recertifier toutes les configs valides.
IBM considère que du simple point de vue du stockage des données par utilisateur c'est une abération.
Maintenant libre à toi de penser que les "méchants" sont pret à sacrifier des To entiers de stockage par utilisateur. Mais ca tient de la conviction religieuse et pas du raisonnement logique.
[^] # Re: conséquences graves passent avant le reste
Posté par erik_lallemand . Évalué à 3.
Le meilleur moyen de ne pas être victime d'un "méchant", c'est d'être paranoïaque. Après tout, lorsque les chinois se sont fait livrer des Boeing, ils ont trouvé plein de micro cachés. Et lorsque des chercheurs en crypto d'une université se sont fait livrer des PC, ils ont aussi trouvé plein de mouchards dans leurs bécanes.
...pour ceux qui ont quelque chose de grande valeur à protéger, il est important d'avoir une démarche sécuritaire/parano.
...pour le grand public, il est important de mesurer aujourd'hui une liberté qui peut sembler impalpable au 1er abord. Le piratage, c'est mal (bouh... :-) ), mais il n'est pas normal d'empêcher une libre communication sans limites (DRM et compagnie...).
[^] # Re: conséquences graves passent avant le reste
Posté par Jerome Herman . Évalué à 3.
Vend ton PC alors. Si tu penses sincèrement que les gros, ou même seulement Microsoft (qui est super pote avec IBM c'est connu) vont taguer toutes les propriétés de ton PC pour ouvoir te suivre tu es foutu.
Il y a un moment il faut savoir se donner une limite raisonable ou alors on sombre dans la folie.
Non Microsoft ne va pas passer 3 mois/homme de travail à relever toutes les mesures possible et imaginable de ma TPM pour stoquer ca sur plusieurs To de données.
Non mon vendeur de PC ne va pas accepté de devoir réenvoyer mon PC en usine pour reréengistrement de l'ensemble des données à chaque fois qu'il me prend l'envie de flasher un firmware ou de mettre à jour un driver.
Non Microsoft ne va pas payer de sa poche le retour en usine de 400 millions de PCs à chaque mise à jour de sécurité du windows média player.
Les chances de me faire enlever par des Antariens sont nettement plus élevées. La manip est techniquement possible, mas également complètement absurde. On aurai déjà rien qu'en terme de marketing beaucoup de mal à vendre ce genre de technos...
[^] # Re: conséquences graves passent avant le reste
Posté par briaeros007 . Évalué à 1.
Oui la nsa a pu faire pression sur ces contructeurs pour cela aussi.
Oui la parano c'est aussi voir quand les gens ne jouent pas forcement avec les memes règles de jeux que nous...
[^] # Re: conséquences graves passent avant le reste
Posté par pasBill pasGates . Évalué à 7.
Bref, si t'as envie d'etre parano fais le completement: si ils sont si vicieux que ca, tu es deja entube jusqu'a a la moelle, pas besoin d'avoir tcpa pour ca.
[^] # Re: conséquences graves passent avant le reste
Posté par briaeros007 . Évalué à 2.
qu'il ait des fonctions non documente pe ; et je rapellerais le numero de serie des p3 comme quoi c'est pas tout jeune; mais une backdoor ???
Moi on me dis tcpa saisbonmangezen saisparfaityapasplusecure et toutlemondeestgentildansleplusparfaitdesmondes.
Desole mais non je ne suis pas tout a fait d'accord.
Et en executant que du code qui est a peu pres sur ; (utilisant que les fonction documentes vu que gcc ne connais que celles la) j'ai nettement moins de risques d'activer une quelconque fonction non documente sur un processeur...
Encore une fois l'avantage du ll sur le proprio :-D
[^] # Re: conséquences graves passent avant le reste
Posté par Matthieu Moy (site web personnel) . Évalué à 2.
[^] # Re: conséquences graves passent avant le reste
Posté par briaeros007 . Évalué à 2.
Il faut donc qu'il integer tous les codes possibles generer par chaque compilo pour que ca marche.
Ou qu'il essaie une version spécifique et le simple fait de changer de version bloquera la backdoor.
Sans compter le fait que l'on risque d'avoir cette suite d'instruction dans quelquechose qui n'as rien a voir ; et donc generer une erreur que l'on peut remonter.
Ca ressemble plus a un trick hardware qui vise un couple machine/os particulier ca.
Oui certes en theorie rien n'est impossible; de meme que le cpu peut stocker tout ce qui passe dans ses bus (en theorie) et tout donner a l'envoie d'une fonction non documenter (un pin non connecte normalmeent par exemple) . Ca c'est pour la theorie ; pour la pratique heu ...
Tandis qu'avoir un opcode non spécifie dans les doc pour tcpa ; et que cet opcode delivre les cles qu'il a, me semble theoriquement et techniquement largement plus possible et plus interessant.
[^] # Re: conséquences graves passent avant le reste
Posté par erik_lallemand . Évalué à 5.
Tu ne sembles pas avoir saisi le sens de ce que je voulais dire. Je vais donc faire une version "simples" (avec un "s"... Désolé, je m'offusque quand on me prend pour un con). Face à une situation inconnue où l'on a une chance de se faire entuber, le plus prudent, c'est d'être... ...prudent! D'un point de vue plus pragmatique, la sécurité n'est pas une qualité mais une mesure (citation de Chris Shiflett). On peut considérer qu'une "chose" (fichier crypté, les joyaux de la couronne, la déclaration d'indépendance des USA) est sécurisée lorsque les moyens à mettre en oeuvre pour compromettre la sécurité sont démesurés par rapport à la valeur de la "chose". (NdM: d'où le fait que les êtres humains seront de plus en plus les maillons faibles de la chaine de sécurité, à mesure que les technologies rendront plus difficiles les solutions techniques de compromission de la sécurité).
Contrairement à ce que tu sembles croire, mais j'ai peut-être mal interprété tes propos, je n'envisage pas l'espionnage des foyers par un Microsoft qui serait érigé en Big Brother... mais je te propose quelques pistes de réflexion:
- espionnage de grandes entreprises (le programme d'espionnage Echelon a entre autres permis aux USA de piquer un marché brésilien à EDF et un marché saoudien à Airbus)
- les lobbies du divertissement (cinema et musique) pourraient faire pression pour autoriser à tracer les activités de pirates suspectés.
Enfin, je te renvoie à mon post précédent. Il faut encourager une démarche de réflexion sur la sécurité et sur la liberté. C'est mieux d'aller au devant d'une situation inconnue que d'attendre que la situation en question s'impose à nous, possiblement de manière désagréable (cf. projet de loi Fillon sur l'ecole, brevets logiciels en Europe...). Sinon, on peut être de gentils moutons un peu idiots et dire "Lotus Notes, c'est génial. Les fonctions de cryptographie vont sécuriser tous nos emails".
[^] # Re: conséquences graves passent avant le reste
Posté par fredoh . Évalué à 2.
juste une question, le chiffrement utilisé par lotus notes est il mauvais ?
[^] # Re: conséquences graves passent avant le reste
Posté par erik_lallemand . Évalué à 5.
"lotus notes" backdoor nsa
...en gros, tu apprendras qu'il y a quelques années Lotus Notes intégrait dans sa clé de cryptage une partie fixe de 24 bits connue de la NSA, et une partie variable de 40 bits, connue de l'utilisateur uniquement. Le challenge de casser un mail crypté par Lotus Notes était donc ramené à casser une clé de 40 bits, autrement dit, de la cryptographie faible. Cette simplification du boulot n'était bien sur valable que pour nos "amis" américains, qui du coup, pouvaient plus facilement lire le courrier du reste du monde.
Si ce genre de choses t'étonne, ca ne devrait pas. Un autre exemple de procédé "à l'américaine" (info datée du 11 mai 2005): http://www.clubic.com/actualite-19031-le-gouvernement-americain-1er(...)
La liberté est morte. Vive la liberté :o/
[^] # Re: et oui les TPM ...
Posté par M . Évalué à 4.
Tant qu'on est pas obliger de l'utiliser (et meme dans ce cas tant qu'on peut utiliser un simulateur software), je ne vois pas de probleme a ce type de puce...
[^] # Re: et oui les TPM ...
Posté par briaeros007 . Évalué à 2.
Et supposons qu'avec la merdouille de sha1 je decide de passer a whirlpool je fais comment je change de pc?
Et ps le coup du "pc non secure" La desole si ton pc est pas de conrfiance (on peut sniffer les bus etc...) par la meme ta puce n'est pas de confiance (qui te dis que la nsa ne l'a pas change ?).
Si tu estime que ton os est pas de confiance. Certe il a pas acces a ta cle privee; mais il a acces a tous les documents que tu souhaite crypter/signer donc tu m'excuse la sécu aussi est nulle.
Tant qu'on est pas obliger de l'utiliser (et meme dans ce cas tant qu'on peut utiliser un simulateur software),
Donc toi tu trouve NORMAL que l'on soit un moment obliger d'utiliser palladium ? Desole mais on a pas du tout la meme conception de la liberté informatique.
Enfin bizarrement j'ai largement plus confiance en un noyau linux , du one time pad , un bon generateur d'aleas. qu'en une puce tpm
[^] # Re: et oui les TPM ...
Posté par Beretta_Vexee . Évalué à 3.
Le sniffage du bus est relativement difficile sans modification du Bios, c'est d'ailleur pour cela que la puce TPM peut vérifier l'intégriter du Bios et de toute a séquence de boot, si c'est une condition d'acces a certainnes clés.
La sécurité absolue n'existe pas, c'est évident, mais TPM offre un gain énorme en matiére de sécurité des clés c'est indéniable, a ce jour aucun systéme ( même les cartes a puces ) ne peuvent offrire une telle sécurité.
TPM, n'est pas palladium, et personne ne t'oblige a l'utiliser ou a faire quoi que ce soit avec. Si tu ne souhaite pas utiliser les fonctions TPM de ta machine tu peux même les bloqué si cela t'amuse ( c'est tous a fait prévue ).
Tu parle d'un bon générateur d'aléas ? Tu sais que la puce TPM peut servir de générateur d'aléa cryptographique, donc bien plus sur que celui de linux ? Donc rien ne t'empéche d'utiliser TPM pour renforcer ton one time pad, sans utiliser les autres fonctions de TPM ( même si c'est un peut béte ).
[^] # Re: et oui les TPM ...
Posté par briaeros007 . Évalué à -4.
Oki c'est bon ta puce est naze .
Le sniffage du bus est relativement difficile sans modification du Bios,
On parle pas forcémenet de sniffagesoftware mais d'une possibilite de sniffage hard .
c'est d'ailleur pour cela que la puce TPM peut vérifier l'intégriter du Bios et de toute a séquence de boot, si c'est une condition d'acces a certainnes clés.
et qu'est ce qui empeche de faire un système qui fasse quelquechose de semblable a du "hotswap" . tu boot sur un système sur jusqu'au point ou le tcpa ne regarde plus; et tu la swap sur le système non sur.
La sécurité absolue n'existe pas, c'est évident, mais TPM offre un gain énorme en matiére de sécurité des clés c'est indéniable, a ce jour aucun systéme ( même les cartes a puces ) ne peuvent offrire une telle sécurité.
Marrant parce que moi j'en ai trouve aucun plus a cette soi disante "revolution".
Et bizarrement je crois pas que c'est ce qu'utilise les militaires ...
TPM, n'est pas palladium, et personne ne t'oblige a l'utiliser ou a faire quoi que ce soit avec. Si tu ne souhaite pas utiliser les fonctions TPM de ta machine tu peux même les bloqué si cela t'amuse ( c'est tous a fait prévue ).
De meme que word est pas obligatoire; mais que le .doc est obligatoire pour envoyer les cvs a certaines boites . Une fois que tu auras ton net de confiance qui ne parlera qu'entre personne equipe de tpm tu feras quoi ?
Tu parle d'un bon générateur d'aléas ? Tu sais que la puce TPM peut servir de générateur d'aléa cryptographique, donc bien plus sur que celui de linux ?
J'avoue que la j'ai du mal a voir le "donc" . Si il suffisait de dire quelquechose pour qu'elle soit vrai...
Donc rien ne t'empéche d'utiliser TPM pour renforcer ton one time pad, sans utiliser les autres fonctions de TPM ( même si c'est un peut béte ).
oui tres ; si je veux utiliser un generateur d'aleas je prend un truc que je sais comment il marche. Et generer du pseudo aleas une fois que tu as une graine de + de 80 bits c'est assez facile en fait; si c'est ce qu'ils font ; alors la sécu restera celle de la graine dans le tcpa. rien de superbe quoi.
[^] # Re: et oui les TPM ...
Posté par Beretta_Vexee . Évalué à 6.
Oki c'est bon ta puce est naze .
Hum quel analyse, je crois que je vais la transmettre a mes amis qui en sont a leurs deuxiéme mémoire de recherche sur la recherche de collision sur MD5 et SHA-1. Tu peux nous expliquer comment tu as pour calculer casser du SHA-1 ? Méthode de V. Klima, Wang & Al ? Pré-contrainte, calcul de collision par bloc, ou génération de pré-image ?
Plus sérieusement tu connais quoi que ce soit aux recherche de collision d'une fonction de hash ? Qu'est ce qui te permet de dire que SHA-1 ou SHA-256 ne sont plus sur pour un usage cryptographique ? Parce que la communauté est très mitigé au sujet de a conséquence des dernières attaques, donc tes jugements a l'emporte piéce tu peux te les garder.
Le sniffage du bus est relativement difficile sans modification du Bios,
On parle pas forcémenet de sniffagesoftware mais d'une possibilite de sniffage hard .
La dernières fois que j'ai vue un sniffage hardware c'était sur un bus de 8bit a 4Mhz, et le montage n'était pas spécialement peut ou discret. Donc oui il est possible de sniffer le bus d'un PC moderne, maintenant si Jean Bond et une équipe de technicien sont venue bidouiller ton PC pendant ton sommeil, on désouder la moitié de ta carte mère, underclocker le tous a une vitesse ridicule histoire de pourvoir sniffer quelque chose sans que vous vous en aperceviez, ou plus simplement que le Mossad est venue vous kidnapper vous et votre PC, oui TCPA n'y peut rien, mais avouez que c'est une situation un peut particulière.
et qu'est ce qui empeche de faire un système qui fasse quelquechose de semblable a du "hotswap" . tu boot sur un système sur jusqu'au point ou le tcpa ne regarde plus; et tu la swap sur le système non sur.
Heu comment dire... Tu sais qu'on parle d'un PC avec fonction cryptographique la, pas d'une playstation ? Je me vois mal t'expliquer un concepte que je maitrise mal comme la transitionnal trust mais je peut t'assurer que ce type de manip n'est pas possible ( de plus on retombe dans la situation du dessus ou le Massid est venue ressouder une puce sur ta carte mére.
Marrant parce que moi j'en ai trouve aucun plus a cette soi disante "revolution".
Et bizarrement je crois pas que c'est ce qu'utilise les militaires ...
Tu en tire quel conclusion ? que les militaires sont des crétins in compétant en matière de sécurité ? Tu semble avoir une très haute estime de toi même, au fait d'ou tu connais les systèmes de protections ou de cryptage militaires ? Parce que personnellement tes sources m'interesses.
De meme que word est pas obligatoire; mais que le .doc est obligatoire pour envoyer les cvs a certaines boites . Une fois que tu auras ton net de confiance qui ne parlera qu'entre personne equipe de tpm tu feras quoi ?
Paralléle trollesque
J'avoue que la j'ai du mal a voir le "donc" . Si il suffisait de dire quelquechose pour qu'elle soit vrai...
C'est a peut prés la seul chose sur la quel nous soyons d'accrod, vous disez vous même beaucoup de chose fausses ou infondés.
oui tres ; si je veux utiliser un generateur d'aleas je prend un truc que je sais comment il marche. Et generer du pseudo aleas une fois que tu as une graine de + de 80 bits c'est assez facile en fait; si c'est ce qu'ils font ; alors la sécu restera celle de la graine dans le tcpa. rien de superbe quoi.
Vue votre niveau ( croire qu'un générateur d'aléa crypto carte qui seul valent une fortune , se base sur une simple graine ), si vous vous limitez aux mécanisme que vous comprenez je vous conseil les dés, les joueurs de jeux de rôle on fait beaucoup dans ce domaine vous en trouverez de toutes les tailles et couleurs dans de nombreuses configurations ( 4,6,8,10,12,20,30 faces pour se limiter aux polyèdre régulier ).
[^] # Re: et oui les TPM ...
Posté par briaeros007 . Évalué à -3.
ou ais je parler de sha-256 ?
C'est pas en balancant des mots que vous pensez prouver a quiconque que "vous savez de quoi vous parlez" .
Il y a eu une proof of concept sur sha-1 ca me suffit !
J'essaie pas de prouver que j'ai la plus grosse moi...
La dernières fois que j'ai vue un sniffage hardware c'était sur un bus de 8bit a 4Mhz, et le montage n'était pas spécialement peut ou discret. Donc oui il est possible de sniffer le bus d'un PC moderne, maintenant si Jean Bond et une équipe de technicien sont venue bidouiller ton PC pendant ton sommeil, on désouder la moitié de ta carte mère, underclocker le tous a une vitesse ridicule histoire de pourvoir sniffer quelque chose sans que vous vous en aperceviez, ou plus simplement que le Mossad est venue vous kidnapper vous et votre PC, oui TCPA n'y peut rien, mais avouez que c'est une situation un peut particulière.
On est bien d'accord . Donc tcpa n'apporte rien de plus que les système actuels merci. Parce que c'est bien ce que vous disiez que tcpa etait plus mieux car transitait pas en memoire toussa. Et comme avec une politique de secu suffisante (tripwire et consors) on pouvais tres bien arriver a la meme sécurite que tcpa : un os sur.
Tu en tire quel conclusion ? que les militaires sont des crétins in compétant en matière de sécurité ? Tu semble avoir une très haute estime de toi même, au fait d'ou tu connais les systèmes de protections ou de cryptage militaires ? Parce que personnellement tes sources m'interesses.
Non j'en tire comme conclusions; comme les militaires utilisent PAS des portables avec tcpa pour la communication avec leurs sous marin (pour la bonne et simple raison que quand ils etaient lancé ca n'existait pas), il doit exister quelquechose d'au moins aussi sur. (pour la petite histoire il utilisent de tete du one time pad pour la communication avec les snle).
VOUS etes le seul a les traiter de "cretins" je n'ai jamais tenu de pareils propos; et ce n'etait absolument pas le sens de ma phrase. Etes vous sur de l'avoir bien lu?
Heu comment dire... Tu sais qu'on parle d'un PC avec fonction cryptographique la, pas d'une playstation ? Je me vois mal t'expliquer un concepte que je maitrise mal comme la transitionnal trust mais je peut t'assurer que ce type de manip n'est pas possible ( de plus on retombe dans la situation du dessus ou le Massid est venue ressouder une puce sur ta carte mére.
Donc vous etes en train de me dire que quelqu'un qui vous pique votre portable; il peut pas s'amuser a dessouder la puce tcpa pour essayer de recuperer le mdp etc ?
vous pouvez "m'assurer" tout ce que vous voulez... Je suis desole mais votre assurance ne me satisfait pas du tout, Avez vous le datasheet des puces pour pouvoir etre aussi sur que c'est pas possible? Parce que si il est possible de changer le mot de passe , il peut etre peut etre possible de le changer sans avoir a rentrer le précedent. Est ce que des montages en bootant sur quelquechose qu'il estime comme etant sur (le pc qu'il reconnais bien ) et qu'ensuite il se met sur "son" pc pour utiliser son système je vois pas vraiment ou est le problème ( a part le montage technique mais de bons mux rapides devrais pouvoir aider).
Paralléle trollesque
Tellement trollesque qu'il suffit de regarder les offres d'emploi pour voir que c'est vrai. Je ne lancait pas le troll word mais bel et bien le problème de "une fois que la majorite l'utilise on fais comment pour acceder a cette majorite" .
vous disez vous même beaucoup de chose fausses ou infondés.
Comme ?
Le one time pad est prouve inconditionnellement sur?
Sha1 a une proof of concept?
Le lecteur de carte a puce a 30 euros chez selectronic?
Vue votre niveau ( croire qu'un générateur d'aléa crypto carte qui seul valent une fortune , se base sur une simple graine ),
Ou est ce que j'ai dis des generateurs d'aleas qui valent une fortune?
J'ai dis des generateurs pseudo-aléatoires.
Vu votre niveau ou vous savez meme pas differenciez aléatoires et pseudo aléatoires , vous etes vraiment mal place pour me dire quoi que ce soit.
si vous vous limitez aux mécanisme que vous comprenez je vous conseil les dés, les joueurs de jeux de rôle on fait beaucoup dans ce domaine vous en trouverez de toutes les tailles et couleurs dans de nombreuses configurations ( 4,6,8,10,12,20,30 faces pour se limiter aux polyèdre régulier ).
Le sarcasme apres avoir confondus aléas et pseudos aléas n'est pas vraiment la chose la plus intelligente a faire...
Bref etes vous tellement a court d'arguments que vous partez en attaques ad hominem ?
[^] # Re: et oui les TPM ...
Posté par tgl . Évalué à 4.
Il faut relativiser, il n'y a pas encore d'attaque franchement utile sur SHA-1 : ce que sauraient faire Wang et compagnie, c'est générer une collision parfaitement quelconque, mais il ne savent pas pour autant viser un hash particulier. Pas moyen pour l'instant donc de trouver, par exemple, un password imitant (par son empreinte SHA-1) celui d'un autre utilisateur, où encore de forger un programme avec backdoor pour qu'il ait la même empreinte que l'original. Bref, SHA-1 a encore quelques beaux jours devant lui, et on aura probablement changé plusieurs fois nos Thinkpad d'ici à ce qu'il soit utilement compromis.
[^] # Re: et oui les TPM ...
Posté par Beretta_Vexee . Évalué à 3.
http://smertrios.atr.free.fr/crypto/(...)
Même en suivant la méthode décrite par Wang, il semble que ce soit beaucoup plus complexe que prévue ne serais que de produire des collisions au hasard. Alors trouver des collisions sur un password simple ( calculer une pré-image ), ce n'est absolument pas d'actualité qui plus ait quand la plus part des systéme de signature et de password utilise des canaries pour complexifier encore la chose.
Donc MD5 a encore quelques beaux jours devant lui, c'est encore plus vrais pour SHA-1 ( les techniques de précontrainte sont similaires que ce soit pour MD5 ou SHA-1, c'est juste un peut plus simple pour MD5 ).
[^] # Re: et oui les TPM ...
Posté par briaeros007 . Évalué à 2.
Mais il existent d'autres fonctions de hashage qui ne presente pas ce problème. pourquoi ne pas changer alors?
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . Évalué à 4.
Pour faire uen réponse claire : par ce que ca ne sert à rien. On a trouvé un cas hyper particulier dans lequel il ets possible de générer "raisonablement" facilement deux fichiers ayant la même signature.
Ce n'est pas l prmeière fois que celà se produit. il y avait par exemple dans le tout premier aogorithme RSA une faille qui faisait que pour certains nombe premiers "spécifiques" il était possible de retrouver les deux facteurs d'un produit de nombre premiers en un temps raisonablement court (complexité n² au lieu de de coplexité exponentielle).
A-t-on abandonné le système immédiatement pour autant ? Non. On a juste ajouter une fonction pour éviter ces cas particuliers.
Pour en revenir à SHA-1, il eut se passer deux choses : soit le cas décrit est un truc vraiment très particulier innutilisable ailleurs. A ce moment la il existe une "faille" dans SHA-1 qui permet à un utilisatur de générer deux fichiers ayant le même hash. Utilisabilité en usurpation : 0.
Soit il existe une propriété algénrique non connue qui vient d'être mise en exemple par un cas spécifique sur SHA-1, et alors si elle est généralisée et démontrée rien ne dit qu'elle n'impactera que SHA-1. On est même plutôt tenté de penser que c'est l'ensemble des calculs de hash qui va être impacté (Si c'ets une propriété algébrique globale, il y a peu de chance que MD5, par exemple, ne soit pas impacté aussi).
Bref soit c'est inutilisable, soit il y a de bonnes chances que ca impacte tout le monde. Les raisons de rejeter SHA-1 sont donc réduite.
[^] # Re: et oui les TPM ... taille données / taille des clés, ratio crucial
Posté par free2.org . Évalué à 2.
Il est deja démontré que la crypto la plus fiable (la seule qui est non cassable) est la crypto qui utilise des clés au moins aussi grandes que la taille des données qui seront à traiter (one time pad). Et tout cryptanaliste sait bien à quel point le ratio tailles des données / taille des clés est un ratio important.
Il est clair que ces puces implémentant des algorithmes déjà bien attaqués dans du hardware, en + d'éventuelles backdoors que nous pourront pas y déceler, sont mal adaptées à l'évolution rapide de la crypto.
[^] # Re: et oui les TPM ... taille données / taille des clés, ratio crucial
Posté par briaeros007 . Évalué à 2.
Tu dis qu'il y avait une faille dans rsa, et qu'est ce qu'ils ont fait ? ils ont rajoute une fonction spécifique pour eviter que ce cas ce produise . En faisant ca ils ont corrige le problème.
Maintenant dans le cas de sha-1 as ton modifie la fonction pour eviter que la demonstration de la chinoise (me souviens plus de son nom desole) ne soit plus valide? non. Donc on n'est pas dans le meme cas.
Donc ca sert au cas ou un exploit et trouvé ; alors on ne sera pas sensible.
Tu as un noyau linux qui a un proof of concept d'un remote exploit. Tu as un nouveau noyau qui utilise un tout autre code et qui n'as plus ce proof of concept . tu utilise quoi ? l'ancien sous pretexte qu'on a pas encore trouvé l'exploit? ou le nouveau sous pretexte qu'on est jamais assez prudent?
[^] # Re: et oui les TPM ... taille données / taille des clés, ratio crucial
Posté par Jerome Herman . Évalué à 5.
Si c'est un truc qui a une chance sur dix milliards de marcher, ou qui nécessite des conditions de réalisation monstrueuses (genre réussir à placer une interruption illégale dans un appel système que je ne controlle pas) je ne mets pas à jour.
Pourquoi ? Parceque j'ai déjà des maillons beaucoup plus faibles dans ma chaine de sécurité. Pas la peine de surblinder uen étape si els étapes environnantes ne sont pas au même niveau.
[^] # Re: et oui les TPM ... taille données / taille des clés, ratio crucial
Posté par free2.org . Évalué à 2.
1. utiliser un OS simple et démontré fiable avec de la crypto démontrée incassble
2. avoir un OS plus complexe et non démontré, composé de "maillons" ayant chacun des faiblesses, en essayant de faire en sorte que chaque maillon soit corrigé rapidement quand un exploit sort.
http://en.wikipedia.org/wiki/Computer_security(...)
J'ai bien plus confiance dans l'approche numéro 1 qu'en l'approche numéro 2.
TCPA n'est qu'un maillon faible de plus dont on ne pourra même pas vérifier l'absence d'erreurs ou de backdoors.
[^] # Re: et oui les TPM ...
Posté par Beretta_Vexee . Évalué à 4.
Je ne balance pas des mots, je me suis simplement intéressé au sujet, et j'ai lue les doc fournit a chacun des attaques sur MD5 et SHA-1.
Il y a eu une proof of concept sur sha-1 ca me suffit !
Proof of concept de quoi ? du fait que l'on pouvait calculer en un temps réduit une collision sur deux bloque plus ou moins tiré au hasard. Cela ne remet pas en cause l'utilisation de SHA-1 pour le moment, les prévisions les plus paranoïaques préconise le passage a SHA-256 a partir de 2010.
J'essaie pas de prouver que j'ai la plus grosse moi...
J'ai jamais pretendut avoir une grosse voiture tous les linuxfriens qui me connaisse savent que j' ai une toute petite twingo ;-)
On est bien d'accord . Donc tcpa n'apporte rien de plus que les système actuels merci. Parce que c'est bien ce que vous disiez que tcpa etait plus mieux car transitait pas en memoire toussa. Et comme avec une politique de secu suffisante (tripwire et consors) on pouvais tres bien arriver a la meme sécurite que tcpa : un os sur.
Tripewire se fait roulé dans la farine par le première rootkit sous forme de module kernel venue, et ce depuis des annés ( 2-3 tous au moins ). TCPA ne prétend pas rendre l'OS sur, il prétend simplement protéger les jeux de clés du vole suite a une intrusion, et ça pour le moment je ne connais aucun systéme qui puisse le faire en software.
Non j'en tire comme conclusions; comme les militaires utilisent PAS des portables avec tcpa pour la communication avec leurs sous marin (pour la bonne et simple raison que quand ils etaient lancé ca n'existait pas), il doit exister quelquechose d'au moins aussi sur. (pour la petite histoire il utilisent de tete du one time pad pour la communication avec les snle).
VOUS etes le seul a les traiter de "cretins" je n'ai jamais tenu de pareils propos; et ce n'etait absolument pas le sens de ma phrase. Etes vous sur de l'avoir bien lu?
masque jetable + offuscation + divers joyeusetés au niveau des fréquences et une vitesse de transmission ridiculement faible. Mais ils ont l'énorme avantage d'être dans un sous-marin cad qu'il y a très peut de chance pour qu'on vienne leur voler leurs masques jetables ( on retrouve notre coffre fort). Dans un environnement comme un PC utiliser la technique du masque jetable ( one time pad), c'est bien beau mais cela ne fait que déplacer le problème, au lieu de protéger une clé on doit protéger un masque qui est plus encombrant et peut pratique si l'on ne connait pas a l'avance le volume de donner a crypter.
La technique du masque jetable est en effet infaillible, mais a une condition essentielle, il faut un canal sûr pour échanger les masques avant l'utilisation ( dans le cas de notre sous-marin, ce sont les valises plombés ) dans le cas d'un PC, votre clée USB, votre disque ou autre ne peuvent pas faire office de canal sûr. Le systéme du masque jetable n'est pas résistant aux intrusion, alors que c'est le principal intéret de TCPA.
Donc vous etes en train de me dire que quelqu'un qui vous pique votre portable; il peut pas s'amuser a dessouder la puce tcpa pour essayer de recuperer le mdp etc ?
Si il a accés a une salle blanche, et aux infrastructure nécessaire pour lire l'intérieur d'une mémoire composant sans l'altérer, c'est que vous avez la NSA ou une multinationnal sur le dos.
Parce que si il est possible de changer le mot de passe , il peut etre peut etre possible de le changer sans avoir a rentrer le précedent.
A ce moment autant ne pas mettre de mot de passe, je pense que les concepteurs n'était pas totalement incompétent.
Est ce que des montages en bootant sur quelquechose qu'il estime comme etant sur (le pc qu'il reconnais bien ) et qu'ensuite il se met sur "son" pc pour utiliser son système je vois pas vraiment ou est le problème ( a part le montage technique mais de bons mux rapides devrais pouvoir aider).
Le problème c'est que si vous bouger n'importe quel composant de la chaine de confiance vous perdez le transitionnel trust donc la confiance, donc interchanger le Bios, la puce ou l'OS ne fonctionnera pas. Maintenant cela relève toujours de l'attaque physique, en cas d'attaque physique aucun système n'est sur. Donc discréditer le système sur la base d'une attaque physique complexe ne prouve pas grand chose au final.
Tellement trollesque qu'il suffit de regarder les offres d'emploi pour voir que c'est vrai. Je ne lancait pas le troll word mais bel et bien le problème de "une fois que la majorite l'utilise on fais comment pour acceder a cette majorite" .
On y accéde pas, si on suis votre raisonnement on se demande d'ailler se que vous faite avec un OS libre ce qui vous coupe de la très large majorités des formats, application et utilisateurs windows.
De plus comme vous le faitez judicieusement remarqué cette scission n'a absolument pas besoin de puce pour exister, les incompatibilités s'en charge déjà, et les DRM vont renforcer cet état de fait.
Donc dire que TCPA sera la cause de cette scission n'est pas pertinent et reléve du troll.
Le one time pad est prouve inconditionnellement sur?
La technique du masque jetable n'est sûr que si toutes les conditions d'application sont réunis ( canal sécurisé, un masque aussi long que le message, etc etc ...), ce qui n'est pas le cas sur un PC classique. Et qui de plus est relativement inadaptés ( Comment je vais transmettre mon masque a tous mes correspondant, comment j'évalue la taille de mes messages, etc etc ..)
Sha1 a une proof of concept?
Ce proof of concept n'entame pas pour le moment l'utilisation de SHA-1 dans le contexte actuel ( par exemple pass + canarie, signature, le seul domaine touché pour le moment ce sont les documents programmable http://www.cits.rub.de/MD5Collisions/(...) )
Le lecteur de carte a puce a 30 euros chez selectronic?
Le lecteurs seul sans rien pour l'utiliser surment, maintenant si tu compte faire quoi que ce soit avec au mieux tu t'en tire pour 100¤. http://www.smartcardsupply.com/Content/Hardware/AC-KIT.htm(...)
Ou est ce que j'ai dis des generateurs d'aleas qui valent une fortune?
Bas TCPA en intégre un a moindre prit pourquoi se priver.
J'ai dis des generateurs pseudo-aléatoires.
Vu votre niveau ou vous savez meme pas differenciez aléatoires et pseudo aléatoires , vous etes vraiment mal place pour me dire quoi que ce soit.
Hors le masque jetable dont vous semblez fan n'est pas une technique sur avec un masque pseudo-aléatoire, mais bon passons.
Bref etes vous tellement a court d'arguments que vous partez en attaques ad hominem ?
Quoi déjà ? Non, en général je deviens franchement de mauvaise fois quand je tombe a court d'argument.
[^] # Re: et oui les TPM ...
Posté par briaeros007 . Évalué à 1.
Si tu as ta bd + tes binaires de tripwire sur des supports en lecture seule (comme c'est preconise) j'ai un peu de mal a le croire car le module il doit bien etre quelque part ; et par consequent tu vas le reperer. D'autant si tu compile un noyau sans le support des modules (j'avais lu quelque part quo'n pouvait quand meme forcé mais aucune confirmation a ce sujet).
TCPA ne prétend pas rendre l'OS sur, il prétend simplement protéger les jeux de clés du vole suite a une intrusion, et ça pour le moment je ne connais aucun systéme qui puisse le faire en software.
Mais si tu as une intrusion ; il a donc acces a tous tes documents. Tu as protégé tes cles ; c'est bien tu ne sera pas oblige d'en regenerer de nouvelles ; mais a part ca...
pour le one time pad je suis d'accord qu'il n'est pas adapte pour les communications inter ordi; toutefois pour une cles usb qui ne sera lisble que sur l'ordinateur qui a la cles du one time pad ; les conditions sont reunis ; si on suppose au depart que l'os est "sur" .
Bien entendu si l'os est pas sur on peut partir sur n'importe quoi derriere (y compris tcpa); le message ne sera jamais sécurise.
Ce proof of concept n'entame pas pour le moment l'utilisation de SHA-1 dans le contexte actuel
Mais il existe :-D
Comme disais dans apple seed : "si tu as le moindre doute, alors fais comme si c'etait un piège et redouble de prudence".
Quel est l'utilité de continuer sur quelquechose dont on sais qu'il y a une possibilite , certes faibles, mais qui est la , qu'une methode de recherche d'exploits existes. La nsa est le premier employeur de matheux aux mondes; si il y a une possibilité il ont les cerveaux disponibles pour la trouver; et ne vous attendez pas a ce qu'il la publie.
pour les cartes a puce j'ai vu des programmateurs de carte a puce avec logiciel (pour uploader le code) pour windows a 35 euros . Ensuite j'avoue que j'ai jamais developpe pour mais si la programmation suis certaines normes des outils de developpements libres doivent exister non ?
Hors le masque jetable dont vous semblez fan n'est pas une technique sur avec un masque pseudo-aléatoire, mais bon passons.
Je parlais de pseudo aleas car vous disiez que palladium avait un generateur d'aleas. Par contre aucune indication sur le comment il genere son aleas.Si ce n'etait que du pseudo aleas alors la on peut faire presque aussi bien (toujours le problème de la graine) en soft ;). Et comme je le vois mal mesure le nombre de rayons cosmiques ou faire des mesures physiques semblables ;)
Bas TCPA en intégre un a moindre prit pourquoi se priver.
Parce que avoir un truc qui fait tous en meme temps c'est la meilleure facon de tout faire mal :-D
si les veritables generateurs d'aleas prennent bien plus de place qu'une simple puce; c'est qu'il y a sans doute une raison non?
Ah moins que maintenant ils prennent juste une puce mais j'en ai pas vu beaucoup comme ca.
[^] # Re: et oui les TPM ...
Posté par Beretta_Vexee . Évalué à 3.
Un systéme complet sans un espace accessible en écriture, sans support module, etc etc ... ce n'est pas très courant. La faille qui permettait de charger des modules sur un kernel dépourvue du support existé sur les kernel 2.4 de mémoire, elle a été corrigé depuis. De plus tripwire ne vérifie que les fichiers qu'on lui a demander de vérifier, il est très rare qu'il scan tous une partition.
Mais si tu as une intrusion ; il a donc acces a tous tes documents. Tu as protégé tes cles ; c'est bien tu ne sera pas oblige d'en regenerer de nouvelles ; mais a part ca...
Ne serais ce que cela a son importance par exemple dans le cas de certificat de signature numérique. Mais en plus il y a de forte chance pourqu'il ne te vole que tes documents codés.
Bien entendu si l'os est pas sur on peut partir sur n'importe quoi derriere (y compris tcpa); le message ne sera jamais sécurise.
Ce n'est pas parce qu'il y a intrusion que l'intrus est forcement root, donc oui si l'intrus est root, rien ne pourra l'empécher d'attendre le bon moment pour dumper la mémoire au moment opportun ou autre. Si il ne l'ait pas TCPA risque d'être un rempart assez solide.
Quel est l'utilité de continuer sur quelquechose dont on sais qu'il y a une possibilite , certes faibles, mais qui est la , qu'une methode de recherche d'exploits existes. La nsa est le premier employeur de matheux aux mondes; si il y a une possibilité il ont les cerveaux disponibles pour la trouver; et ne vous attendez pas a ce qu'il la publie.
Si la NSA est dans la liste des tes ennemies, je crois que tu as d'autre problème plus urgent. Soyons réaliste aucun geek isolé ne peut lutter face a des agences de renseignement militaire, au pire si ils veulent vraiment savoir ce que contient ton disque dur ils viendront te rendre visite.
La NSA comme de nombreuses agence internationnals dans le monde font de la veille technologique, si ils avaient trouvé une faille il ne la publierait peut être pas, mais il laisserait filtrer ou ferait des recommandations a leurs concitoyens de ne plus utiliser SHA-1. La sécurité informatique et le cryptage ne se cantonne plus aux simple interet gouvernementaux a l'heure ou l'activité des ces services touche de plus en plus a l'intelligence économique. La NSA avait fait des recommandation pour renforcer DES, la NSA est plus ou moins a l'origine de l'appel d'offre pour SHA-1 et AES, ... La situation est loin d'être alarmante, MD4 est totalement abandonné pourtant générer une préimage est toujours horriblement long sur une machine actuelle. On déconseille MD5 en faveur de SHA-1 alors qu'il n'est toujours pas possible de générer dans un temps raisonnable des préimage MD5.
pour les cartes a puce j'ai vu des programmateurs de carte a puce avec logiciel (pour uploader le code) pour windows a 35 euros . Ensuite j'avoue que j'ai jamais developpe pour mais si la programmation suis certaines normes des outils de developpements libres doivent exister non ?
En fait le support pour le libre de tous ce qui est lecteur de carte et lecteur d'empreinte est vraiment a la traine. C'est un secteur ou il y a d'innombrable standards que ce soit de lecteurs, de carte, d'interface, d'API et autre. Le but non avoué de toute la profession étant de ne pas vendre des lecteurs ou des cartes, mes des « solutions d'identification » et autre. Personnellement j'ai un lecteur d'empreinte que je n'ai jamais put utiliser a cause de cela, il ne communique que via un protocole spéciale non documenté.
Donc soit vous passez par un professionnel qui vous vend une solution, soit vous investicez dans un kit de dev.
Je parlais de pseudo aleas car vous disiez que palladium avait un generateur d'aleas. Par contre aucune indication sur le comment il genere son aleas.Si ce n'etait que du pseudo aleas alors la on peut faire presque aussi bien (toujours le problème de la graine) en soft ;). Et comme je le vois mal mesure le nombre de rayons cosmiques ou faire des mesures physiques semblables ;)
Un je ne parle pas de Palladium, bien malin celui qui pourra parler en détail de palladium/NGSCS/trucbidule, je dis simplement que la puce TPM intégre un générateur d'aléa cryto, donc un vrais générateur d'aléa pas un pseudo apres comment ils font, je n'en sais rien. Il y a une vrais guerre des brevets et des technologie dans ce domaine, la plus part des techniques utilise des probabilités physique, émission d'un photon et est ce qu'il passe ou pas un filtre polarisé ou un filtre spéciale, trajet d'un électron, etc etc ... donc la mesure des rayons cosmique n'est pas plus irréaliste que cela.
Parce que avoir un truc qui fait tous en meme temps c'est la meilleure facon de tout faire mal :-D
si les veritables generateurs d'aleas prennent bien plus de place qu'une simple puce; c'est qu'il y a sans doute une raison non?
Les dernière générations prennent la forme de simple puce, mais a ce que j'ai comprit ils font intervenir des méthode de fabrications exotiques, ce qui explique leurs couts ( petite série plus cout de fabrication ). Si demain ( ou hier ) Intel décide d'intégrer ces méthodes de fabrication a ses usines le prix chuterais énormément.
[^] # Re: et oui les TPM ...
Posté par Romain (site web personnel) . Évalué à 2.
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . Évalué à 2.
a) le générateur d'aléas - on ne sai pas comment il marche et IBM n'était pastrès causant à ce sujet.
b) la clefs d'authentification TPM qui permet à un système TPM de prouver à un autre système TPM qu'il est bien un système valide. La raison pour laquelle cette clef n'est pas connue est probablement parcequ'il s'agit d'une clef privée ou équivalent plus ou moins complexe. les clefsprivées ont la sale (ou la bonne) habtde de ne pas être conne de tous.
A part çà le reste est très simple. Il y a une couche crypto interne (pour controller l'intégrité de la puce et sécurisé le contenu des coffres), une couche crypto externe pour générer les clefs et une couche de dialogue utilisateur. Bref c'est à peu de chose pret un serveur PKI on die avec une authentification masquée.
[^] # Re: et oui les TPM ...
Posté par briaeros007 . Évalué à 2.
Quand quelqu'un me dis qu'une puce est "tres simple" bizarrement j'ai peur.
Je me doute bien que les ingénieurs de chez ibm ne sont pas completements des quilles et savent suivre des normes. Mais entre suivre des normes et les implementer sur une couche hardware sans faire d'erreur il y a une certaine distance quand meme.
Attention je ne jette pas la pierre aux ingénieurs ;) Je dis juste que concevoir une puce de A à Z n'est pas quelquechose d'aise. De plus on ne sait pas les choix de conceptions qui ont été fait pour cette puce (en tout cas moi je les connais pas :-D ).
[^] # Re: et oui les TPM ...
Posté par briaeros007 . Évalué à 2.
J'ai jamais dit que le système complet etait pas en lecture ecriture; j'ai dis que la bd de tripwire ; et les binaires sont eux au minimum en lecture seuls. Ensuite il est preferable d'avoir la partition système ou seul l'admin peut le mettre ne rw de tel sorte a ne pas avoir de possibilite de modifie le système une fois en prod . (exemple il se met en rw que pour les mises a jours de secu ; repasse en r ; lance tripwire pour verifier les modifs. Update une nouvelle base tripwire sur le nouveau système et la stocker sur un cdr)
Ensuite les utilisateurs peuvent avoir leurs espaces ou ils ecrivent ce qu'ils veulent. mais le système a moins de chance d'etre vraiment compromis.
Ce n'est pas parce qu'il y a intrusion que l'intrus est forcement root, donc oui si l'intrus est root, rien ne pourra l'empécher d'attendre le bon moment pour dumper la mémoire au moment opportun ou autre. Si il ne l'ait pas TCPA risque d'être un rempart assez solide.
Ben si il ne l'est pas : est ce que la gestion des droits au niveau du fs est suffisante pour assurer la sécurité ?
Parce que si il n'est pas root /utilisateur priviliégie :
Soit il est sur ton login et donc dans ce cas quoi que tu fasse tu te fais avoir.
Soit il est sur un autre utilisateur et dans ce cas il faudrais qu'il casse soit les droits du fs, soit tcpa.
Effectivement il peut vouloir partir avec le dd mais rien n'interdis d'utiliser un cryptoloop avec une cles sur usb et la il va avoir beaucoup de mal a recupérer les informations; idem si tu stocke toutes tes donnes sensibles sur la cle.
Mais en plus il y a de forte chance pourqu'il ne te vole que tes documents codés.
Mais si ils sont si importants ; pourquoi ne pas les stocker autre part que sur l'ordi , avec une cle qui elle est encore sur un autre support (une cle usb par exemple).
Ca fait un cd/dvd pour les documents sensibles (avec differents moyens de protections contre le vol) et les cles qui sont sur le support de la cles usb. Le système reste sur contre l'intrusion si l'os est sur.
Ps si les documents sont si important que ca la perte des cles importe peu par rapport a la perte des documents donc un dispositif qui expose l'ordinateur a de tres fortes temperature si le système est volé reste possible (grenade au phosphore toussa...)
Soyons réaliste aucun geek isolé ne peut lutter face a des agences de renseignement militaire, au pire si ils veulent vraiment savoir ce que contient ton disque dur ils viendront te rendre visite. Ce ne sont pas des surhommes non plus ;)
Et je ne suis pas sur que la nsa ait sa section "action" :)
Plus serieusement : si on veux assurer la sécurite il est normal de prendre "l'adversaire" le plus puissant non?
la plus part des techniques utilise des probabilités physique, émission d'un photon et est ce qu'il passe ou pas un filtre polarisé ou un filtre spéciale, trajet d'un électron, etc etc ... donc la mesure des rayons cosmique n'est pas plus irréaliste que cela.
Je sais tres bien qu'elle est pas irrealiste vu qu'elle a été utilisé :-P
Mais est ce que dans le tpm il y a de tels recepteurs / systèmes ? Vu qu'on ne sait pas comment c'est fait ; par defaut je ne fais pas confiance.
Les dernière générations prennent la forme de simple puce, mais a ce que j'ai comprit ils font intervenir des méthode de fabrications exotiques, ce qui explique leurs couts ( petite série plus cout de fabrication ). Si demain ( ou hier ) Intel décide d'intégrer ces méthodes de fabrication a ses usines le prix chuterais énormément.
Je te crois n'etant pas un expert (loin de la) dans le domaine ;).
Pour essayer de terminer un peu le troll : je concois tout a fait l'utilité de tpm ; mais je pense qu'on peut attendre cette meme utilite sans avoir a utiliser une "boite noire" qu'est le tpm ; en utilisant plus ou moins des astuces ;) . L'avantage de ne pas utilise de "boite noire" est de na pas favorise le developpement de pareilles boites sur toutes les cm pour etre finalement un jour bloque par elles. Les problèmes d'interoperabilité ne date pas d'hier , et etre dependant d'uen boite noire est , de mon point de vue une mauvaise chose. De plus la sécurite par l'obfuscation est rarement une bonne chose (rien ne dis que leurs implemnetation est correcte ou encore que leurs aleas l'est vraiment ou ...)
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . Évalué à 2.
La seule façon de bloquer un système via la puce TCPA serait d'avoir dans la puce des clefs extérieures préchargées qui serviaient à autre chose que d'authentifier la puce auprès d'une autre puce. Ce cas est formellement interdit par la norme TCPA. De plus il faudrait aussi que l'utilisateur principal de la machine ne soit pas admin (ce qui est aberrant, il ne pourrait alors plus se servir de la puce) o que les clefs soient accessibles de l'extérieur mais non déplaçable/migrable, ce qui est également interdit par la norme. Pour finir il faudrait également que le matériel soit capable de tirer partie de ces informations, ce qui implique d'avoir un système TPM non seulement sur la carte mère, mais aussi sur les parties que l'on veut bloquer (doncTPM sur disque dur/carte son/lecteur vidéo etc.) Bref on aura encore une chance de voir venir si c'est l'orientation que prennent les choses.
De plus la sécurite par l'obfuscation est rarement une bonne chose
Houlà, c'est pas uen boite noire au sens "on sait pas trop ce qu se passe dedans", c'est uen boite noire au sens "bonne chance pour récupérer la clef les gars". Suite au troll avec Free2org je sais exactement ce qui se passe dans ma puce TPM - vu que je n'utilise pas et que j'ai désactivé les fonctions non parfaitement doccumentés (ie identification puce à puce et identification ditsitante certifiée par tiers)
[^] # Re: et oui les TPM ...
Posté par briaeros007 . Évalué à 2.
Houlà, c'est pas uen boite noire au sens "on sait pas trop ce qu se passe dedans", c'est uen boite noire au sens "bonne chance pour récupérer la clef les gars"
Pas convaincu : les carte "pirates" pour les bouquets satellites sont casses en 6 mois a peu pres. pourtant ils donnent pas leurs hdl ni leurs cles.
il y a quelques mois ti avait une puce qui servait a l'authentification des voitures. La aussi securite par obfuscation. Paf casse.
Tu dis que tu sais exactement ce qui se passe; donc tu as eu le hdl et tu sais le lire?
C'est comme pour windows : il y a des fonctions documentes. C'est pas pour autant que tu peux dire ce qui se passe dans le noyau.
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . Évalué à 2.
Le truc par défaut c'est :
En admin : Créer une signature de boot, créer une identité, créer un profil. Lier l'identité avec la signature de boot et accorder les droits en lecture écriture au profil.
Avec le Profil : Déclarer un tiers de confiance, valider l'identité auprès du tiers et sauvegarder la clef d'authenticité dans le profil.
Ca n'ets pas exactement "trivial". Comme la clef ne peut pas être préchargée (interdit par la norme TCPA) à une exception près : identité puce sans signature de boot (laquelle est désactivée par défaut et non chargé par IBM) ca fait quand même du boulot entre le "par défaut" et le truc hautement intrusif.
Pas convaincu : les carte "pirates" pour les bouquets satellites sont casses en 6 mois a peu pres. pourtant ils donnent pas leurs hdl ni leurs cles.
il y a quelques mois ti avait une puce qui servait a l'authentification des voitures. La aussi securite par obfuscation. Paf casse.
Les deux cas que tu donnes appartienent à un paradigme complètement différent, celui ou l'on cherche à garder un secret vis à vis de l'utilisateur final. Sous TCPA il n'y a pas besoin d'utiliser de la force brute, toutes les clefs sont utilisables par l'utilisateur en 10 secondes via migration de zone. Ici on ne cherche pas à protéger le contenu de l'utilisateur, mais du reste du monde.
Typiquemetn dans le cas de technos DRM on cherche à masquer la clef privée le plus possible, mais on est obligé de la donner quand même (sinon l'utilisateur ne peut pas lire le support). TCPA ne cherche absolument pas à faire celà. Toutes les clefs sont toujours accessibles/migrables et donc utilisables dans toutes les situations. Aucun rapport donc avec ce que tu cites.
Tu dis que tu sais exactement ce qui se passe; donc tu as eu le hdl et tu sais le lire?
J'ai eu entre les mains le doc qui permet à un constructeur de fabriquer sa propre puce TCPA dans les normes. Je peux donc dire que je connais le fonctionnement de l'ensemble de la puce à deux exceptions pret (vu que je n'ai pas voulu signer de NDA).
[^] # Re: et oui les TPM ...
Posté par briaeros007 . Évalué à 2.
Tu as oublié "actuellement" ...
si les tpm se généralise; je suis vraiment pas sur que les choix par defaut vont rester identiques. Je suis peut etre parano ; mais quand on fait de la sécu (ce que je ne fais pas vraiment) il parait qu'il faut l'etre :-D
Toutes les clefs sont toujours accessibles/migrables et donc utilisables dans toutes les situations. Aucun rapport donc avec ce que tu cites.
Donc tu es en train de me dire que n'importe qui peut avoir acces aux cles?
tu essaie de protéger tes cles des personnes qui ne doivent pas en avoir acces (exemple vol de portable, intrusions...). tout comme les cles sur une carte a puce de bouquet televisuelle ou les concurrents ne doivent pas y avoir acces. Je vois pas vraiment la difference...
J'ai eu entre les mains le doc qui permet à un constructeur de fabriquer sa propre puce TCPA dans les normes. Je peux donc dire que je connais le fonctionnement de l'ensemble de la puce à deux exceptions pret (vu que je n'ai pas voulu signer de NDA).
entre la norme initiale et ce qui est implementer il peut y avoir quelques differences notables (entre autre possibilite de mode "super utilisateur" sur la puce etc...). Tant que tu n'as pas vu le hdl (donc le "code" de la puce) tu ne peux pas savoir. C'est exactement le meme probblème avec un logiciel propriétaire : il peut respecter une norme mais faire aussi de la retention d'information , si tu as pas le code source impossible de vérifier non?
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . Évalué à 2.
Le jour ou le TCG se referme, et sort de nouvelles puces sans en publier les specs et sans permettre à des fondeurs nouveau de créer leurs propres puces, je pars en courant.
Donc tu es en train de me dire que n'importe qui peut avoir acces aux cles?
Personne ne peut avoir accès au clefs, mais l'admin du TCPA peut déplacer/copier/migrer n'importe quelle clef.
Tant que tu n'as pas vu le hdl (donc le "code" de la puce) tu ne peux pas savoir.
Non tant que je n'ai pas fondu la puce moi même (et je veux dire avec mes petites mains dans mon garage) je ne peux pas savoir. Dans tous les autres cas je suis obligé de faire confiance à quelqu'un. Chacn met la limite ou il veut. Etant incapable de fonder les puces ou d'analyser une puce après fonderie je considère le HDL comme m'étant inutile. Rien ne me permettra jamais de vérifier que le papier que l'on m'a doné correspond à la puce que j'ai sous les yeux. Donc j'accorde ma confiance au niveau des specs.
Rien ne me prouve non plus qu'il n'y ait pas un traceur/pisteur dans mon CPU. Tant pis j'aime trop l'informatique pour m'arreter.
[^] # Re: et oui les TPM ...
Posté par briaeros007 . Évalué à 2.
Et tu accord ta confiance seulement au niveau des specs pour un logiciel?
Moi si on me donnela norme pkcs et qu'on me dis "si si ce logiciel l'implemente de facon parfaite" bizarrement je ne le crois pas sur parole. Pourquoi serait ce different pour les puces ? parce que tu ne peut pas verifier ?
Et ensuite tu dis "je fais de la sécu" ??? Sije ne peut pas verifier j'utilise pas (enfin dans le principe je parle).
Rien ne me prouve non plus qu'il n'y ait pas un traceur/pisteur dans mon CPU.
Si tu n'utilise que les fonction documentes ; et que tu utilise un analyseur de spectre et un champmetre si tu peut eviter un quelconque traceur/pisteur.
mais l'admin du TCPA peut déplacer/copier/migrer n'importe quelle clef. Ce qui repose la question du simulateur de puce qui recupere les puces par ce biais.
Le jour ou le TCG se referme, et sort de nouvelles puces sans en publier les specs et sans permettre à des fondeurs nouveau de créer leurs propres puces, je pars en courant.
Parce que tu crois que ca va se faire brutalement? Il vont commencer a referemer une fonction mettons. Tu va dire c'est pas grave je vais plus l'utiliser; bien entendu tu vas oublier de pas l'utilsier uen fois sur deux.
Puis ils vont refermer une autre fonction , tu vas dire c'est pas grave ca fait pas beaucoup de difference par rapport a la version précédente....
C'est comme retirer un grain d'avoine un cheval ca lui fait rien.
Lui en retirer deux non plus.
Mais a la fin ton cheval finis par mourir...
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . Évalué à 2.
Non je fais tout moi même à la mimine dans mon garage. Y compris a ma modeste mesur eun audit du code des progs sensibles. Pour les puce je ne peux rien faire au delà de l'HDL. Donc je ne peux pas valider l'HDL.
Si tu n'utilise que les fonction documentes ; et que tu utilise un analyseur de spectre et un champmetre si tu peut eviter un quelconque traceur/pisteur.
Les fonctions doccumentés, par exemple en archi x86, sont très différentes du bytcode sous jacent. Que fait le bytecode ? Mystère.
Je peux bosser dans une cage de faraday à l'écart de toute connection réseau. Je pense déjà faire partie des rares personnes à avoir des antennes alu autour de mes écrans pour éviter de me faire espionner mes écrans par rayonnement. Aller plus loin serait déraisonable et relèverait du cas clinique (encore que je ne suis pas complètement sur d'être hors du dit cas)
Parce que tu crois que ca va se faire brutalement? Il vont commencer a referemer une fonction mettons. Tu va dire c'est pas grave je vais plus l'utiliser; bien entendu tu vas oublier de pas l'utilsier uen fois sur deux.
Si ils changent les specs dans uen direction qui ne me plait pas je me casse. La limite de ce que je suis prèt à accepter est très claire dans ma tête. Au delà c'est niet. Si il y a faille je serais le premier à hurler. A l'heure actuelle je considère la puce TCPA beaucoup moins dangereuse que la puce de ma carte réseau. Donc je la garde. C'est aussi simple que celà.
[^] # Re: et oui les TPM ...
Posté par briaeros007 . Évalué à 2.
donc tu est en train de me dire que si tu de-assemble un programme tu
ne vas pas retrouver les codes asm donnes dans les references? Bizarres j'ai quelques mal a te croire...
Si ils changent les specs dans uen direction qui ne me plait pas je me casse. La limite de ce que je suis prèt à accepter est très claire dans ma tête.
Toujours plus facile a dire qu'a faire...
A l'heure actuelle je considère la puce TCPA beaucoup moins dangereuse que la puce de ma carte réseau. Donc je la garde. C'est aussi simple que celà.
A l'heure actuelle les puces reseau , dans leurs documentation tout du moins , ne permettent pas de stocker des cles cryptographique, de faire des operation de cryptographie forte ou du "remote attestation".
Et puis si tu es aussi parano que tu le dis pourquoi tu prend pas un fpga et tu utilise pas opencores.org ?
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . Évalué à 2.
ne vas pas retrouver les codes asm donnes dans les references? Bizarres j'ai quelques mal a te croire...
Le code asm n'est pas le code executé par le processeur. Il est d'abord converti en bytecode. Lequel bytecode est très différent du code langage machine correspondant à l'asm. Déjà il est en risc....
A l'heure actuelle les puces reseau , dans leurs documentation tout du moins , ne permettent pas de stocker des cles cryptographique, de faire des operation de cryptographie forte ou du "remote attestation".
Ben voilà, dans la doc tout va bien, impossible de savoir ce qu'il y a après a moins de pouvoir fondre ou analyser les puces. On peut mettre des fonctions de pistage, d'espionnage de prise de main à distance etc. dans n'importe quelle puce. Celle qui aura le plus de facilité à propager l'information c'est la puce de la carte réseau sortante de mon routeur/firewall. Ma puce TCPA aura beaucoup plus de mal à me "trahir" sans que je la vois.
[^] # Re: et oui les TPM ...
Posté par briaeros007 . Évalué à 3.
Donc il est en "risc" meme sur un p2 ?
On peut mettre des fonctions de pistage, d'espionnage de prise de main à distance
prise en main de ta carte reseau ? cool et ca servira a quoi? attaque style mitm? avec une gestion des cles nada..
Espionnage de ta carte reseau ? cool et ca servira a quoi?un sniffer sur le cable peut fair la meme chose..
Il y a largement moins de problèmes dans les donnees conserver dans les puces de la carte reseau; et largement plus de constructeurs differents que celles de tcpa pour que le risque de backdoor et leurs consequences eventuelles dans tcpa soit plus important que dans le cas d'un puce reseau.
Sans compter que tu peux posséder un fpga qui fera le boulot carte reseau pour toi et tu sauras ce qu'il y a dedans car tu as le hdl que tu as charge ...
Ma puce TCPA aura beaucoup plus de mal à me "trahir" sans que je la vois.
on a jamais dit "te trahir" . Ca pourrais etre un mode super utilisateur comme certaines puces motorola avait. Donc quelqu'un qui a ton pc (cas du vol du portable) pourrais recuperer tes cles et toi considererait qu'elle serait encore en sécurite. Par la meme il pourra lire tous les messages crypter sur ton dd.
Maintenant si il peut mettre ta puce de carte reseau en mode superutilisateur ; a la rigueur il a le dernier Mo que tu as up/dl mais a part ca ...
[^] # Re: et oui les TPM ...
Posté par Jerome Herman . Évalué à 4.
Pour aller plus loin que Beretta je dirais ceci : il est trivial de démontrer que tripwie ne sera jamais secure.
Tripwire n'est pas un OS complet, donc pour se lancer, s'initialiser et effectuer ses différentes opérations il est obligé (comme tout le monde) de lancer des appels systèmes et de "faire confiance" à la réponse. tant que tripwire ne sera pas le coeur du kernel (ie le premier truc chargé) il ne pourra pas s'assurer que le système amont n'a pas été corrompu. Il sera obligé de "croire" le système quand celui-ci lui renverra les infos concernant un repertoire précis ou un démon en train de tourner. Entre autre tripwire est incapable de se certifer lui même indépendamment du système. La puce TCPA le peut.
[^] # Re: et oui les TPM ... intégrité au boot sans tcpa
Posté par free2.org . Évalué à 2.
[^] # Re: et oui les TPM ... intégrité au boot sans tcpa
Posté par Jerome Herman . Évalué à 2.
Il peut avoir été compromis à priori, avant le gravage. Et tripwire est toujours obligé de lui faire confiance.
[^] # Re: et oui les TPM ... intégrité au boot sans tcpa
Posté par briaeros007 . Évalué à 2.
Il te faut un maillon de confiance si tu veut sortir du truc du "comment verifier le truc qui verifie le truc qui verifie le truc qui ...
Bref la ca fait plus penser a de la mauvaise foi qu'a autre chose. (parce que dans ce cas l'os que test tcpa peut etre aussi compromis au tout debut et donc tcpa il te sert a rien ou ...)
Tu disais un moment que f.free2.org (ou un pseudo comme ca) regarder la situation comme il voulait la voir. Ben la tu fais exactement la meme chose; excepte que tu as aucun argument contrairement a lui.
[^] # Re: et oui les TPM ... intégrité au boot sans tcpa
Posté par free2.org . Évalué à 2.
Sa mauvaise foi est de plus en plus évidente.
[^] # Re: et oui les TPM ... intégrité au boot sans tcpa
Posté par Jerome Herman . Évalué à 2.
Tout à fait. Mais TCPA est indépendant de l'OS et incapable d'interagir avec lui autrement que par un canal bein spécifique par le biais de challenge response. Donc même avec une puce compromise, il faudrait encore que la personne désireuse de piquer mes clefs réussisse à usurper l'identité d'un challenger que j'ai envie de contacter.
Alors que si mon OS ou si tripewire sont compromis ils peuvent aller d'eux même sur le ternet faire leur raport e ouvrir ma machine en grand.
La différence n'est pas ennorme, mais c'est quand même un bon cran de plus en faveur de TCPA.
[^] # Re: et oui les TPM ... intégrité au boot sans tcpa
Posté par briaeros007 . Évalué à 2.
et donc par la meme ouvrir en grand tes documents que tu veux proteger par chiffrement.
[^] # Re: et oui les TPM ... intégrité au boot sans tcpa
Posté par Jerome Herman . Évalué à 2.
Un TCPA compromis ne peut pas compromettre l'OS, un OS compromis ne peut pas compromettre TCPA.
Il y a un mieux. Pas forcément un grand mieux, mais un mieux.
[^] # Re: et oui les TPM ... intégrité au boot sans tcpa
Posté par free2.org . Évalué à 2.
C'est ridicule. Il y a des failles dans les OS, tu es au courant ?
Pas besoin de rebooter pour exploiter la grand majorité des failles ! Donc TCPA ne sert à rien du tout dans cette grande majorité des failles. Point.
[^] # Re: et oui les TPM ... intégrité au boot sans tcpa
Posté par Jerome Herman . Évalué à 2.
Pas besoin de rebooter non plus pour que TCPA choppe des changements dans les measurements. Si tu corromps mon kernel je vais m'en rendre compte quasi-instantanément. Et en plus les coffres à clefs se refermeront immédiatement.
[^] # Re: et oui les TPM ... intégrité au boot sans tcpa
Posté par free2.org . Évalué à 2.
Pas besoin de rebooter non plus pour que TCPA choppe des changements dans les measurements.
Ca devient vraiment surréaliste. Maintenant le moindre bug dans un OS est détecté par TCPA...
[^] # Re: et oui les TPM ... intégrité au boot sans tcpa
Posté par Jerome Herman . Évalué à 4.
Lit-le.
On y apprend pleins de choses sur comment créer des listes de mesures entretenues dynamiquement. Comment vérifier qu'elles n'ont pas été corompus. Comment se réassurer qu'un système déjà vérifier est toujours non compromis, quasiment en temps réel.
C'est passionant. C'est ce module et cette architecture que j'ai monté dans mes x31, ca permet de savoir à la demande si tu as eu un inode, un programme ou quoi que ce soit d'autre de modifié.
Maintenant TCPA ne comprend pas les "bugs", mais si ca modifie un truc que tu lui as demandé de surveiller il te le dira.
C'est très puissant.
Ceci étant ce troll ne m'interresse plus, j'ai même commencé à devenir agressif avec des personnes qui ne le méritaient pas, donc à mon sens le débat est clos.
Je te laisse libre de croire que l'on peut grace à un hash envoyé par une puce TCPA deviner l'OS et en profiter pour bloquer l'ordinateur. Je pense que tu n'es pas là pour un débat mais pour affirmer ton point de vue le plus violament possible.
Ca ne m'interresse pas.
Cordialement.
[^] # Re: et oui les TPM ... intégrité au boot sans tcpa
Posté par free2.org . Évalué à 2.
Quand aux hashs envoyés à distance, c'est bien ce que disent les papiers officiels que j'ai cité ci-dessus.
Et ce qui ne t'intéresse pas, en fait, c'est les conséquences du remote attestation pour le grand public. C'est de l'irresponsabilité.
[^] # Re: et oui les TPM ...
Posté par Guillaume Knispel . Évalué à 5.
Et les chiffrages XBox cassés en sniffant le bus de données du P3 par des étudiants, ca n'existe pas ?
[^] # Re: et oui les TPM ...
Posté par boubou (site web personnel) . Évalué à 2.
Humpf, il me semble que RSA est très vulnérable aux attaques à texte choisi, donc quel est l'intérêt de cacher la clé dans la puce si je peux la récupérer par une attaque simple ? En d'autres termes, comme je ne connais pas bien TPM, quels sont les mécanismes prévus pour empêcher ce genre d'attaque ?
[^] # Re: et oui les TPM ...
Posté par briaeros007 . Évalué à 2.
[^] # Re: et oui les TPM ...
Posté par farib . Évalué à 4.
[^] # Re: et oui les TPM ...
Posté par Beretta_Vexee . Évalué à 3.
http://www.miscmag.com/articles/index.php3?page=911(...)
Les deux gros projets qui utilise TCPA sous linux, les FAQ explique assez bien ce que fait TCPA et ce qu'il ne fait pas:
Enforcer linux
http://enforcer.sourceforge.net/(...)
TrouSerS
http://trousers.sourceforge.net/(...)
[^] # Re: et oui les TPM ... OS fiable avant tout
Posté par free2.org . Évalué à 2.
C'est pour cela que j'ajoute ces liens vers des OS libres démontrés fiables:
http://www.eros-os.org/(...)
http://coyotos.org/(...)
On peut y ajouter les OS à base de micronoyau comme Hurd qui sont bien plus facile à auditer que les monolithes et dont certains services sont complètements indépendants les uns des autres (userspace).
[^] # Re: et oui les TPM ... OS fiable avant tout
Posté par Beretta_Vexee . Évalué à 2.
Mais ces systéme dépasse largement le cadre du simple marketing, la pile non exécutable qui permet d'éviter l'exploitation de la plus part des buffer overflow est un gain de sécurité notable, TCPA s'inscrit dans le même domaine, il ne prétend pas renforcer l'ensemble de la sécurité du systéme mais renforce la sécurité de la gestion des clés, ce qui est un plus par un protection universel.
Sur un Desktop actuel ou l'OS représente finalement qu'une petite partie des applications qui tourne, je pense qu'il est illusoire d'espérer avoir un systéme fiable et sécurité a 100%, car si la faille ne vient pas de l'OS elle viendra de l'utilisateur ou des logiciels.
[^] # Re: et oui les TPM ... OS fiable avant tout
Posté par free2.org . Évalué à 1.
Je ne vois vraiment pas du tout le rapport.
La seule vraie nouveauté de TCPA est le remote attestation.
[^] # Re: et oui les TPM ... OS fiable avant tout
Posté par Jerome Herman . Évalué à 1.
Et l'analyse métrique du système
Et l'unlock automatique de clef fontion du boot et des interactions utilisateurs
Et le coffre hardware dont les clefs ne sortent jamais en clair
Et l'idépendance du système d'exploitation
Et la migration automatique clef/droit/zone d'un PC à un atre sans compromission possible sauf altération physique de haute volée.
Mais sinon rien. Une paille en somme.
[^] # Re: et oui les TPM ... OS fiable avant tout, remote attestion grave
Posté par free2.org . Évalué à 4.
etc.
Impossible de réaliser le remote attestation de la plate-forme complete (matériel et logiciels) sans ces fonctions.
Tout dans TCPA tend vers le remote attestation.
Le remote attestation aura des répercusions très graves sur nos libertés et est bien plus important que toute les bidouilles qu'on pourrait faire par ailleurs avec TCPA alors que d'autres techniques permettent aussi d'améliorer la sécurité d'un ordi mais sans permettre le remote attestation.
Seul un refus de toutes les puces qui permettent le remote attestation nous permettra d'éviter d'être obligé d'avoir un OS drm non modifiable et des matériels drm, pour pouvoir se connecter. Voila ce qui est important.
[^] # Re: et oui les TPM ... OS fiable avant tout, remote attestion grave
Posté par Jerome Herman . Évalué à 3.
Sur un doccument de 300 pages, il y a 10 pages sur la remote attestation. Il n'existe pour l'instant aucun tiers de confiance utilisable globalement (ie un équivalent verisign pour les certificats), aucun fournisseurs qui demende la présence de TPM pour l'accès à certains service (et je dis juste demande, pas exige), la fonctionnalité est désactivée par défaut et le vendor ID est laissé à blanc.
On sent bien là qu'il s'agit de LA priorité d'IBM quand il s'agit de la puce TCPA.
Le remote attestation aura des répercusions très graves sur nos libertés
C'est clair, un vendeur pourrait vérifier, via agrément d'un tiers de confiance, que la machine distante est bien celle qu'il connait dans uen config qu'il connait. C'est presque aussi intrusif qu'un cookie et presque aussi dangeureux que l'installation d'un certificat local pour l'accès à un service.
alors que d'autres techniques permettent aussi d'améliorer la sécurité d'un ordi mais sans permettre le remote attestation.
C'ets sur au sein d'un parc de PCs il existe pleins de techniques aussi simple et aussi fiable pour vérifier de façon fiable la non compromission des machines clientes par un serveur. On peut citer par exemple..... je sais plus, mais il y en a plein en tout cas. Trop même.
Seul un refus de toutes les puces qui permettent le remote attestation nous permettra d'éviter d'être obligé d'avoir un OS drm non modifiable et des matériels drm, pour pouvoir se connecter.
C'est clair aussi. On rejette violamment une puce qui ne permet en aucun cas de faire la moindre incursion dans DRM et au final on aura jamais de matos drm dans nos PCs. C'est magique, faut pas chercher à comprendre.
On crache très fort sur TCPA et on fera disparaitre les firmwares lockés sur les lecteur DVD.
[^] # OS fiable avant tout, remote attestion grave, docs clairs
Posté par free2.org . Évalué à 2.
"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."
C'est clair et net !
[^] # Re: OS fiable avant tout, remote attestion grave, docs clairs
Posté par Jerome Herman . Évalué à 2.
De quoi que c'est un système d'authentification/certification et non un système d'identification ? Ca fait longtemps que c'est clair et net.
Que c'est un système challenge-response et ou le fournisseur de contenu joue le rôle de challenger, et non pas un envoi en masse de données ? Ca fait longtemps que c'est clair aussi.
ce qui est clair aussi c'est que tu lis la doc de façon tellement en diagonale à la recherche de la phrase qui sortie du contexte et coupée savament permettra d'augmenter ton FUD que tu oublies le principal.
Lors d'un metric report
a) les hash sortent-ils de la machine ?
b) les hashs sont-ils liés spécifiquemtn à un matériel ou globalement à une gamme de matériel
c) est-il possible de faire la relation hash vers matériel + logiciel
d) Par trustworthy faut-il comprendre "conforme à une norme DRM définie ailleurs au gout du client" ou "conforme à un système TPM valide" ?
Prend le temsp de lire la doc et de répondre à ces questions simples.
[^] # Re: OS fiable avant tout, remote attestion grave, docs clairs
Posté par free2.org . Évalué à 1.
Au début je croyais que tu ne comprenais pas bien l'anglais ou que tu te cachais les yeux pour ne pas voir une vérité qui te dérange. Maintenant cela tourne à la mauvaise foi pure et simple.
[^] # Re: OS fiable avant tout, remote attestion grave, docs clairs
Posté par free2.org . Évalué à 2.
# +
Posté par M . Évalué à 6.
Chez moi y a que l'adresse de la pile qui change.
Le tas qui sert pour les allocations dynamique ne change pas :
int p;
int main() {
int stack;
printf("%p %p %p\n",&stack, &p, malloc(1));
}
retourne
0xbfd28bd4 0x804963c 0x804a008
0xbf9dec34 0x804963c 0x804a008
0xbff82c04 0x804963c 0x804a008
[...]
[^] # Re: +
Posté par Brice Goglin . Évalué à 6.
[^] # Re: +
Posté par M . Évalué à 2.
Au fait le tas ou l'espace data sont il excecutable ?
J'ai essayer un truc rapide en C et quand j'essaye d'executer du code copie dans le tas, j'ai un SIGTRAP et dans l'espace data j'ai un SIGSEGV.
[^] # Re: +
Posté par tgl . Évalué à 2.
Yep, déso, j'ai un peu over-résumé vu que je voulais pas en mettre toute une tartine non plus. J'ai parlé d'allocation en général parceque ça concerne en plus des piles les mmap pour des libs dynamiques, mais effectivement du coup on comprend "toutes les types d'allocation" :/
> Au fait le tas ou l'espace data sont il excecutable ?
Non justement, c'est pour ça qu'il n'y a pas besoin de ce type de protection préventive là. (Enfin, j'suis loin d'être un gourou du C et du système, donc toute {con,in}firmation sera la bienvenue.)
[^] # Re: +
Posté par Antoine . Évalué à 4.
Non justement, c'est pour ça qu'il n'y a pas besoin de ce type de protection préventive là.
Les sections data ne sont pas exécutables, mais si elles peuvent contenir des pointeurs vers du code exécutable (pointeurs de fonction). Si tu arrives à exploiter une faille pour modifier un de ces pointeurs, tu peux modifier frauduleusement le comportement du programme.
[^] # Re: +
Posté par tgl . Évalué à 2.
> tu peux modifier frauduleusement le comportement du programme.
Ouais, mais est-ce que justement ça n'est pas aussi là que la randomization du mmap intervient ? J'imagine que, typiquement, ce que voudrait l'attaquant c'est pointer une fonction système bien connue qui lui ouvrirait des portes, mais là a priori il ne sait plus vraiment où elle est, non ?
[^] # Re: +
Posté par Brice Goglin . Évalué à 2.
J'avais cru comprendre que n'importe quelle page accessible en lecture etait executable sur x86 (avant que NX-bit soit ajouté recemment) ?
# USB ?
Posté par _Hitek_ (site web personnel) . Évalué à 2.
Là, avec le 2.6.12, ça réutilise le module usb_storage, et j'ai de nouveau /dev/sda1 /dev/sdb1 etc...
Alors, j'ai loupé une option de compile pour utiliser le nouveau driver ub à la place de l'ancien usb_storage, ou bien on en revient à ce dernier ?
Ou alors j'ai rien compris :) et de plus amples explications seraient les bienvenues.
[^] # Re: USB ?
Posté par Brice Goglin . Évalué à 2.
Les options de config n'ont pas l'air d'avoir changé, c'est toujours
CONFIG_USB_STORAGE pour usb-storage et CONFIG_BLK_DEV_UB pour ub.
Lesquelles as-tu dans tes .config de 2.6.10 et .12 ?
[^] # Re: USB ?
Posté par un_brice (site web personnel) . Évalué à 6.
Je ne suis pas sur que l'utiliser, surtout pour des raisons esthétiques, soit une bonne idée.
[^] # Re: USB ?
Posté par M . Évalué à 4.
Pour les autres configs usb_storage est conseillé...
# marre de configurer votre noyau ?
Posté par TazForEver . Évalué à 10.
make randconfig
[^] # Re: marre de configurer votre noyau ?
Posté par Victor STINNER (site web personnel) . Évalué à -10.
[^] # Re: marre de configurer votre noyau ?
Posté par Fabimaru (site web personnel) . Évalué à 4.
# Et la taille des stacks ?
Posté par Benjamin François (site web personnel) . Évalué à 2.
Ça a disparu ? Quelle est la taille par défaut dans ce cas ? Merci !
[^] # Re: Et la taille des stacks ?
Posté par tgl . Évalué à 5.
(astuce : retrouvé dans "make menuconfig" en tapant "/ 4k entrée")
[^] # Re: Et la taille des stacks ?
Posté par Benjamin François (site web personnel) . Évalué à 2.
# Jamais de vacances !
Posté par Jérôme Pinot (site web personnel) . Évalué à 5.
[21:16:23 Sun Jun 19 (tty/2) #26]
ngc891@comet:~/Coding/kernel-cg$ echo "scale=3;`cg-diff -r v2.6.12:master|wc -c`/(2^20)"|bc
2.567
Deja plus de 2,5Mo de patch ont ete applique sur le 2.6.12 !
# DVB ?
Posté par 桃白白 . Évalué à 1.
Est-ce que DVB veut dire tele numerique ?
Est-ce que ca veut dire que j'ai espoir de faire fonctionner ma carte DVB-T sur Linux ?
[^] # Re: DVB ?
Posté par Croconux . Évalué à 2.
Ca veut dire Digital Video Broadcast. Plus d'info sur le site du consortium www.dvb.org . Il existe plusieurs standards (pour la diffusion par satellite, hertienne, etc). Le T de DVB-T c'est pour terrestrial.
Est-ce que ca veut dire que j'ai espoir de faire fonctionner ma carte DVB-T sur Linux ?
Ca dépend. Qu'est ce que c'est comme carte ?
[^] # Re: DVB ?
Posté par 桃白白 . Évalué à 1.
Ma carte c'est une carte PCMCIA Moditel de Technisat. Et aux dernieres nouvelles, ca marche pas.
# ACPI ASUS M6000 ?
Posté par rsystem . Évalué à 0.
quelqu'un aurait-il un portable asus m6000 ?
si oui , avez vous reussi a regler le problème de l'ACPI pour la batterie.
à part ça le 2.6.12 marche nickel chrome ;=)
belle reussite
# Mal à la tête
Posté par igor38 . Évalué à 10.
Ah non, la sortie du nouveau noyau linux... Ok...
>=====> []
[^] # Re: Mal à la tête
Posté par M . Évalué à 9.
C'est l'effet trollosteque linuxfr...
M'enfin ils arriveront peut etre a se mettre d'accord et en tout cas certains passage s sont bien marrant...
[^] # Re: Mal à la tête
Posté par kra . Évalué à 1.
ils vont continuer a se balancer les memes arguments pendant encore une bonne cinquantaine de post, pis une fois qu'ils auront marre de repeter la meme chose en boucle et en gras, bah ils se tairont.
et on saura dans 10 ans, une fois qu'on aura un peu plus de visibilite qui aura raison (et la, yen aura un pour contacter l'autre et lui faire : "HA-HA!!" a la nelson muntz)
# Patches
Posté par Pierre . Évalué à 2.
[^] # Re: Patches
Posté par _Hitek_ (site web personnel) . Évalué à 5.
# mettez à jour votre udev !
Posté par oliv . Évalué à 7.
de l'annonce de udev 058:
"Note, if you are running a kernel newer than 2.6.12-rc4 (including the -mm releases) and you have any custom udev rules, you MUST upgrade to the latest version to allow udev to work properly. This change happened because of a previously-unrealized reliance in libsysfs on the presence of a useless sysfs file that has recently been removed. Hopefully the libsysfs people will be releasing a new version shortly with this change in it for those packages who rely on it."
La discussion sur la LKML:
http://marc.theaimsgroup.com/?t=111909808900001&r=2&w=2(...)
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.