Sortie de Linux 2.6.12

Posté par (page perso) . Modéré par Mouns.
1
18
juin
2005
Noyau
Près de 3 mois et demi de travail auront été nécessaire aux développeurs du libre pour nous proposer une nouvelle version stable de Linux.

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)
  • # 3 mois et demi, pas 5 mois :)

    Posté par . Évalué à 10.

    2.6.11 est sorti le 2 mars.
    • [^] # Re: 3 mois et demi, pas 5 mois :)

      Posté par (page perso) . Évalué à 10.

      Tu as raison, je me suis gourassionne dans les dates. Quelle idee aussi ils ont ces americains d'ecrire mm/jj/aaa plutot que jj/mm/aaa ?

      Enfin, cela faisait quand meme longtemps qu'on l'attendait celui-la, il y a eu une belle chasse aux bugs sur la fin. Il y a encore eu des modifs de l'API, ca va encore etre la joie dans les chaumieres (voir http://linuxfr.org/~JaguarWan/18563.html(...) ).

      Je m'en vais de ce pas me flageller avec des ronces fraiches.
      • [^] # Re: 3 mois et demi, pas 5 mois :)

        Posté par . Évalué à 4.

        Fais gaffe, c'est peut-être déposé par Mel Gibson ça :D
      • [^] # Re: 3 mois et demi, pas 5 mois :)

        Posté par (page perso) . Évalué à 8.

        Quelle idee aussi ils ont ces americains d'ecrire mm/jj/aaa plutot que jj/mm/aaa ?

        C'est vrai qu'avec trois chiffres pour indiquer l'année ça n'aide pas non plus...
        • [^] # Re: 3 mois et demi, pas 5 mois :)

          Posté par . Évalué à 0.

          C'est vrai qu'avec trois chiffres pour indiquer l'année ça n'aide pas non plus...

          Bah oui comme en Perl voyons non !?...
          (où on obtient le nombre d'années depuis 1900)
          --->[]
          • [^] # Re: 3 mois et demi, pas 5 mois :)

            Posté par . Évalué à -1.

            Comme c'est le cas des 3/4 des langages (avec des nuances selon les API, comme dans Perl d'ailleurs) je ne vois pas pourquoi tu cites Perl en particulier sinon pour lancer un gros Troll... Je ne tomberais pas dans ton piège, non, non, d'ailleurs Perl c'est dix fois mieux que Python et Ruby, 30 fois plus rapide et 100 fois plus lisible !!!! ;-)

            --
            Jedaï
  • # Toujours pas de reiser4 !

    Posté par (page perso) . Évalué à 8.

    ET zut !

    Le reiser4 est toujours pas intégré !
    • [^] # Re: Toujours pas de reiser4 !

      Posté par . Évalué à 10.

      Si tu as du temps et une partition libre, tu peux regarder du côté de la distribution MiniSlack [1] dont la dernière version 1.1 [2] inclut en standard le système de fichier ReiserFS 4 [3].

      [1] http://www.minislack.org(...)
      [2] http://www.minislack.org/article.php?story=20050610194346329(...)
      [3] http://www.namesys.com/v4/v4.html(...)

      « Je vous présente les moines Shaolin : ils recherchent la Tranquillité de l'Esprit et la Paix de l'Âme à travers le Meurtre à Main Nue »

    • [^] # Re: Toujours pas de reiser4 !

      Posté par (page perso) . Évalué à 10.

      L'enorme delai que prend l'integration de ReiserFS 4 dans le noyau officiel vient du fait que le code est tres intrusif. Bref, c'est plus qu'un module, comme le dit Rik van Riel :

      The reiser 4 system call sys_reiserfs seems to need an additional patch, which is craftily hidden inside reiser4-only.patch. That patch creates fs/reiser4/linux-5_reiser4_syscall.patch, which I can only assume reiser 4 users should apply...

      Kind of ugly.

      Looking further, the horrors only increase. It looks like sys_reiser4() is an interface to load programs into the kernel, with reiserfs4 containing an interpreter.

      I'll leave aside the issues of having a scripting language inside the kernel, since I'm sure other people will comment on it. However, I am absolutely flabbergasted that Hans Reiser is using a syscall here, instead of a filesystem interface.

      Furthermore, why do the parsing in the kernel, instead of compiling the human-readable strings in userspace and loading something easy to use into the kernel, like the selinux subsystem does?

      Since this code is bound to be horribly controversial, it may be an idea to remove this from the reiserfs4 core patch. That way the battles over the filesystem, and its interactions with the rest of the kernel can be fought first, without having the whole reiserfs4 filesystem strand in the quicksand of "why do we need an interpreted language with completely new filesystem semantics in the kernel?


      Il faut que le developpement de ReiserFS change un peu de direction pour qu'il soit integre au kernel.
    • [^] # Re: Toujours pas de reiser4 !

      Posté par (page perso) . Évalué à 1.

      Reiserfs n'a pas été tout de suite intégré au grand désespoir de Hans Reiser.
      C'est ce qu'il m'avait dit aux RMLL 2000 (les premières !).
      Il avait dû attendre le noyau suivant car les mainteneurs du noyau craignaient beaucoup l'introduction de ce FS très nouveau. Si ils prennent les mêmes précautions qu'il y a 5 ans, il faudra attendre le noyau 2.8 pour mettre reiser4 en production.

      On ne peut pas reprocher la prudence du "kernel team" mais il me tarde quand même de pouvoir utiliser reiser4 qui est vraiment une nouveauté aussi magnifique que révolutionnaire.
    • [^] # Re: Toujours pas de reiser4 !

      Posté par . Évalué à 2.

      Andrew Morton vient de publier la liste des trucs actuellement dans -mm qu'il veut merger dans 2.6.13.
      Il y a Reiser4.

      http://lkml.org/lkml/2005/6/21/98/index.html(...)
    • [^] # Re: Toujours pas de reiser4 !

      Posté par . Évalué à 2.

      Pour le 2.6.13

      Subject: -mm -> 2.6.13 merge status
      From: Andrew Morton

      ...
      reiser4

      Merge it, I guess.

      The patches still contain all the reiser4-specific namespace
      enhancements, only it is disabled, so it is effectively dead code. Maybe
      we should ask that it actually be removed?
      ...
  • # et oui les TPM ...

    Posté par . Évalué à 6.

    > NdM : la dépêche Linux Weekly News liste aussi plusieurs autres changements importants :
    > - l'ajout d'un pilote pour les controversées puces de sécurité TPM (présentes entre autres dans les Thinkpad d'IBM)

    ... parlons en des TPM (enfin vous parceque moi j'y comprends pas grand chose)

    a quoi ca va servir (ou sert deja puisque'il y avait deja un patch pour le 2.6.11) ?

    quel sont les risque d'integrer le support de ca dans notre noyau libre a nous ?

    (vous avez 4 heures)
    • [^] # Re: et oui les TPM ...

      Posté par . Évalué à 10.

      > a quoi ca va servir (ou sert deja puisque'il y avait deja un patch
      > pour le 2.6.11) ?

      Pour l'instant, à ma connaissance ça sert pas à peu prêt à rien. Mais y'a une API en développement qui devrait permettre d'en faire quelquechose si les distribs décident d'aller dans ce sens et que des softs qui font/utilisent de la crypto décident de s'y mettre aussi :
      http://trousers.sourceforge.net/faq.html(...)
      À voir quoi...

      Tu peux aussi jetter un oeil sur ce journal à propos d'un patch pour Grub (rejeté) qui implémentait le boot sécurisé façon TCG :
      http://linuxfr.org/~albancrequy/18368.html(...)
      Y'a une discussion dans le genre de celle que tu proposes, avec en gros deux tendances : les plutôt pour qui se disent que c'est une techno qui peut s'avérer utile pour remplacer certains des mécanismes de sécu actuels, et les carrement contre qui se disent que le véritable objectif est l'autentification distante à des fins de contrôle DRM, et que donc il faut rejeter cette techno en bloc. (J'espère avoir résumé à peu près objectivement le troll...)
      • [^] # Re: et oui les TPM ...

        Posté par (page perso) . Évalué à 3.

        Ca a l'air de ressembler a TCPA, c'est le retour de Palladium/NGSCB ?
        • [^] # Re: et oui les TPM ...

          Posté par . Évalué à 7.

          C'est complètement ca, j'ai mon T43p tout neuf à côté de moi et la puce est désactivée de base, je me suis retrouvé dans le windows avec un fichier TCPACHIP à la racine avec écrit que la puce est désactivée blabla.
          • [^] # TPM, TCPA, TCG, "remote attestation"

            Posté par (page perso) . Évalué à 9.

            Oui TCPA, TCG, TPM, trusted computing group
            C'est bien la meme chose. (toutes ces marques sont déposées par TCG).

            Le principal problème est que ces puces permettent l'identification à distance des logiciels et matériels utilisés (remote attestation).

            Si leur usage se répand, des fournisseurs d'accès et de contenus exigeront qu'on active notre TPM pour s'assurer que le matériel et les logiciels que nous utilisons contiennent un DRM qui leur convient.

            Une petite recherche sur le web avec tcg "remote attestation" vous en dira +
            • [^] # Re: TPM, TCPA, TCG, "remote attestation"

              Posté par . Évalué à 10.

              Le principal problème est que ces puces permettent l'identification à distance des logiciels et matériels utilisés (remote attestation).

              Non, le principal problème C'est que les gens croient celà.
              Si tu as activé la fonction et si tu as fait signé ta puce (ou que le constructeur l'a fait pour toi, mais IBM et le seul constructeur et il ne l'a jamais fait) et si tu te connecte à un service particulier et si tu as déclaré un third party de confiance ALORS le service particulier pourra apprendre du third party de ocnfiance si oui ou non tu as une puce TCPA couplée à un système TPM valide.

              Rien d'autre.

              Il lui sera totalement impossible de savoir si tu es sous windows ou linux ou BSD, si tu as des logiciels pirates ou si tu as du contenu illicite.
              Il poura juste vérifie si tu as un système TPM valide.
              • [^] # Re: TPM, TCPA, TCG, "remote attestation"

                Posté par . Évalué à 4.

                et tu crois vraiment que c'est prévu comme ça ?
                Ça serait pas plutôt une close dans le CLUF "vous acceptez la société comme tiers de confiance" "vous ne pouvez pas demander réparation pour préjudice pour plus de 5E par an" couplée avec des fonctions systèmes pour savoir si la machine à la dite puce et ainsi l'identifiée.

                Ouf, j'ai pas Windows !
                • [^] # Re: TPM, TCPA, TCG, "remote attestation"

                  Posté par . Évalué à 4.

                  "vous acceptez la société comme tiers de confiance"

                  Comme su le grand ternet. Perso je ne fais pas de paiement sur un site web qui n'a pas un certifica valide. je ne vais pas non plus sur les sites certifiés par Verisign en qui je n'ai aucne confiance (et en plsu généralmeent je me fend d'un email pour dire au vendeur pourquoi je n'ai pas finaliser mon achat.)

                  couplée avec des fonctions systèmes pour savoir si la machine à la dite puce et ainsi l'identifiée.

                  La seule fonction accessible depuis système de TCPA/TPM c'est challenge-response. IE on teste a) que l'on a bien à faire à une puce TCPA (éventuellement à distance mais surtut en local) et b) on lui envoit un message et elle renvoit le truc déchiffré. C'est tout ce qu'elle fait.
                  A noter que les clefs "challengeable" sont copiable d'une zone de la puce vers d'autres zones de la puce mais aussi vers d'autres puces TCPA (la manoeuvre est complexe, mais tout à fait réalisable même sous linux).
                  • [^] # Re: TPM, TCPA, TCG, "remote attestation" avouée par TCG et aussi par IBM

                    Posté par (page perso) . Évalué à 6.

                    Même TCG admet officiellement la "remote attestation":
                    remote attestation
                    capability to ensure that the user is employing a configuration that the provider
                    insists upon, even when there is no security reason for such a choice

                    http://66.102.9.104/search?q=cache:https://www.trustedcomputinggrou(...)

                    Idem pour IBM:
                    these mechanisms interact to
                    enable remote attestation
                    http://66.102.9.104/search?q=cache:hMRNHAVJ3BwJ:byte.csc.lsu.edu/~d(...)
                    • [^] # Re: TPM, TCPA, TCG, "remote attestation" avouée par TCG et aussi par IBM

                      Posté par . Évalué à 10.

                      Parce que le "remote attestation" est une fonction rendue possible par TCG, et qu'elle est demandé par divers systéme. Maintenant comme SSL ou autre systéme de certificat et d'authentification mutuel, personne ne t'oblige a l'utiliser.
                      Si tu n'accepte pas le "remote attestation" ( ce qui est aussi mon cas ) tu n'installe pas de systéme qui implémente une telle fonction, le remote attestation se base sur TPM, mais TPM ne fournit pas de base un systéme de "remote attestation".

                      TPM peut servir a énormément de chose différente de l'attestation, mais bon je praiche dans le dessert j'en suis bien conscient. TPM est un jeu de fonction cryptographique très puissant, après chacun peut construire ce qu'il veut avec, que ce soit en bien ou en mal tous comem n'importe quel autre technologie.

                      Nous dire que si l'on supporte TPM, on va automatiquement être sous le contrôle de fournisseurs de contenue des corporation et autre par contre c'est un mensonge, TPM n'est pas un DRM, TPM est documenté et existe déjà dans pas mal de machine depuis un bout de temps. Si vous vous inquietez vraiment de la remote attestation du tracage des machine et de votre topologie reseau faudrait peut étre plus se pencher sur le futur Pentium D qui intégre DTCP-IP en natif, qui lui est un DRM qui fait tous cela, et la technologie LaGrande ( anciennement Palladium, et NGSCS ) qui est le systéme de MS, non documenté et dont les répercutions sont totalement inconnue.

                      Mais bon c'est tellement plus facile de taper sans connaître sur quelque qui en court de support par le libre, qui peut augmenter la sécurité que de pointer les vrais problèmes...
                      • [^] # "remote attestation" avouée par TCG et aussi par IBM, refuser = gagner

                        Posté par (page perso) . Évalué à 3.

                        1. Le remote attestation n'est pas possible sans une puce de type TCG.
                        2. Toutes les autres fonctions TCG ne sont pas nouvelles et sont possibles autrement (les coprocesseurs de crypto existent depuis longtemps, de meme les supports avec mode read-only pour booter dessus en sécurité).

                        De 1. et 2. je déduis que, en matière de business, l'avantage concurentiel de TCG est de loin le remote attestation.

                        Il va y a voir une pression économique très forte de la part des fournisseurs de contenus pour imposer aux utilisateurs TCG.

                        La façon efficace de lutter contre cela est de refuser d'avoir ces puces. C'est en effet sous la pression des consommateurs qui le refusaient que le numéro d'identification des pentium 3 a été abandonné.
                        • [^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn

                          Posté par . Évalué à 6.

                          Question béte pourquoi vous ne luttez pas contre le pentium D et DTCP-IP et LaGrande avec autent de vigueur qu'avec TCPA ?
                          C'est systéme ne sont ils pas pourtant plus dangereux et non supporté par le libre ?

                          Je reste perplexe quand a vos motivations, comme je l'avais indiqués le remote attestation est en effet un fonction demandés par les industriels, qui est rendue possible par TCPA, mais rien n'implique que le support de TCPA dans un systéme ou un environnement libre inclue forcement une fonction de remote attestation. Je crois avoir lui ici même que certaines puce comme celle d'IBM ne permettait pas a l'heure actuel la remote attestation ( a vérifier ).

                          Je suis tous a fait d'accord sur le fait que le remote attestation dans certaines situation somme toutes rares peut poser problème et que cette fonction n'est pas essentiel quand a la sécurité, mais je ne comprend pas pourquoi vous voulez absolument rejeter toutes les avancés de TPM en bloque, cela plusieurs fois que nous avons des échanges sur ce points sans que vous ayez fournit un début de réponse.
                          • [^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn

                            Posté par (page perso) . Évalué à -1.

                            mais je ne comprend pas pourquoi vous voulez absolument rejeter toutes les avancés de TPM en bloque, cela plusieurs fois que nous avons des échanges sur ce points sans que vous ayez fournit un début de réponse.
                            Si tu n'a pas compris ma comparaison avec le ID du pentium 3 qui a été abandonné suite à boycott. Tu ne comprendras jamais en effet.
                            • [^] # "remote attestation" TCG et refus de toutes les puces similaires

                              Posté par (page perso) . Évalué à 3.

                              J'ajoute que l'article dont on parle concerne uniquement TCPA dans Linux, pour la bonne raison que TCPA a introduit la remote attestation bien avant les autres puces DRM (et des brevets ont certainement été déposés par les membres de TCG, dont Intel et IBM). C'est pour cette raison que certains logiciels libres ( mais certains le refusent comme les logiciels du projet GNU) dont Linux intègrent déjà un support pour TCPA.
                              Impossible d'avoir une remote attestation sans stocker dans une puce "de confiance" les hashs des composants matériels et logiciels d'un PC, ce qui est la base de TCPA.

                              J'ai expliqué ici à tous le remote attestation de TCPA et pourquoi il faut le refuser dans les PC du grand public. Suivons l'exemple de l'équipe du GNU bootloader GRUB qui refuse d'intégrer un patch avec le support TCPA pour que leurs utilisateurs prennent conscience quelles seront les conséquences d'une popularisation des puces remote attestation.

                              Evidemment toutes les puces DRM sont susceptibles de poser une menace similaire et il vaut mieux toutes les refuser. Et tous ceux qui veulent nous parler en détails des dangers de ces autres puces seront, je pense, ici les bienvenus.
                        • [^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn

                          Posté par . Évalué à 3.

                          1. Le remote attestation n'est pas possible sans une puce de type TCG.

                          C'est sur on a jamais vu un système identifier un autre système à distance sur la foi d'une clef ou d'un mot de passe. C'est tout nouveau ca vient de sortir. Par exemple les licences MS ne sont pas du tout validées à distance et locké par PC. Du tout.

                          2. Toutes les autres fonctions TCG ne sont pas nouvelles et sont possibles autrement (les coprocesseurs de crypto existent depuis longtemps, de meme les supports avec mode read-only pour booter dessus en sécurité).

                          Bien sur aussi, on a depusi longtemps uen boite noire qui fait coffre à clef que l'on peut remplir à volonté et dont les clefs sont inextractibles en clair. Ca existe depuis super longtemps et TPM n'apporte rien.

                          La façon efficace de lutter contre cela est de refuser d'avoir ces puces

                          Je te rassure, c'est déjà fait. TPM est en voie de mort rapide. Les normes v2 n'ont jamais vu le jour et les systèmes parallèles ont appris à se faire discret pour rentrer sur nos systèmes en douce. On ne peut que féliciter les gens qui par leur boycott ont tué dans l'oeuf une techno fiable, utile et ouverte, laissant ainsi la porte grande ouverte aux bios plombés, au matos adaptatif et au options de sécurités imposés par les grands groupes et dont les specs sont bien cachés.

                          Je ne vais pas reprendre ce troll vec toi. Mais au moins essaye d'éviter le FUD par pitié.
                          • [^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn

                            Posté par (page perso) . Évalué à 1.

                            essaye d'éviter le FUD par pitié.
                            C'est surtout toi qui en fait:
                            C'est sur on a jamais vu un système identifier un autre système à distance sur la foi d'une clef ou d'un mot de passe.
                            Le remote attestatiàon de TCPA n'a rien à voir avec cela.
                            Il s'agit d'enboyer, signés par la puce TPM, les hashs des composants matériels et logiciels d'un ordinateur.
                            C'est autrement plus intrusif !

                            Relis bien le document de TCG que j'ai cité ci-dessus où ils reconnaissent que cette remote attestation est un fait.
                            Dommage que tu sois en retard sur eux sur ce FUD.
                            • [^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn

                              Posté par . Évalué à 4.

                              Il s'agit d'enboyer, signés par la puce TPM, les hashs des composants matériels et logiciels d'un ordinateur.
                              C'est autrement plus intrusif !


                              GNNNIIII ?????

                              Le remote attestation permet en passant par un tiers de vérifier que la clef que tu as fait créer par le tiers et qui a été transmise depuis le TPM du tiers jusque dans ton TPM est bien présent et de certifier cette information auprès d'un autre tiers.
                              C'est exactement l'équivalent des certicats "classiques" sauf que celà se joue entre TPM.

                              Pour finir il n'y a que deux choses qui peuvent sortir du TPM : soit un message décodé (par exemple suite à un challenge response, ou dans le cadre normal de l'utilisation du TPM pour déchiffrer un message); soit une clef migrable a condition que ce soit vers un autre TPM et seulement via une connection sécurisé.

                              Relis bien le document de TCG que j'ai cité ci-dessus où ils reconnaissent que cette remote attestation est un fait.

                              On va pas reprendre le troll ici. Je t'ai déjà démontré, il y a un an que

                              a) La config sur laquelle un tiers insiste même si il n'y a pas de raison sécuritaire à un tel choix est une config précédamment rencontrée. En d'autres termes le tiers client peut s'assurer via le tiers de confiance que tu as bien toujours la même config que celle créée précédamment. il ne peut en aucun cas en déduire ton OS, tes disques durs, ta carte graphique ou quoi que ce soit d'autre.

                              b)Toutes les clefs accessibles de l'extérieur sont migrables. En d'autres termes tu peux parfaitement déplacer la clef de ton tiers client d'une zone à une autre. dans ce cas tu nepourras plus être validée par remote attestation, mais tu pourras toujours lire l'ensemble des doccuments qui ont étés cryptés avec cette clef (ce qui limite vachement l'utilisation dans le cadre du DRM). Si tu veux continuer à faire de la remote attestation, tu peux aussi simplement copier la clef. La copie dans la zone certifiée sera toujours valide aux yeux du tiers client, la copie dans une zone plus laxiste sera utilisable comme bon te semble.

                              Au final cette technique n'est utile que pour un admin qui veut vérifier que ses machines n'ont pas étés compromises avant de les admettre sur le réseau (par exemple). A part çà...
                              • [^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn

                                Posté par (page perso) . Évalué à 2.

                                Désolé mais les documents TCG et IBM que je viens de citer et qui sont en lignes, ainsi que les documents d'intel que j'ai lu il y a 2 ans et dont j'avais commuiqué l'uRL sur linuxfr et à toi sont très clairs:
                                le remote attestation de la plateforme est bien la communication des hashs des composants de cette plateforme, ce qui dans les définitions TCPA a toujours correspondu au matériels et aux logiciels de cette plateforme.
                                • [^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn

                                  Posté par . Évalué à 3.

                                  le remote attestation de la plateforme est bien la communication des hashs des composants de cette plateforme

                                  Donc pour toi la puce envoie directement les hashs brut de fonderie au tiers de confiance (ou alors directement au tiers client )?

                                  Si tu prend tes propres docs (en version PDF de préférence, les schémas sont illisibles sur la version HTML) Notamment celui ci : http://byte.csc.lsu.edu/~durresi/7502/reading/rc23064.pdf(...) à la page 8 figure 2 section "remote attestation"
                                  on y voit clairement que les mesures métriques effectuées par les agents ne sortent jamais de la puce. Le service d'attestation recoit une demande sous forme de challenge et renvoit une response. C'est un cas très classique de preuve par déchiffrage de message dans le cadre d'une certification.

                                  De toute façon, même si les hashs sortaient ils seraient inutilisables. tout d'abord parceque les hashs sont différents (très) sur chaque plateforme, et ensuite parcequ'ils varient d'un boot à l'autre (et oui une carte graphique à 50°c n'aura pas le même hash que la même carte graphique à 20°c). C'ets pas un jeu complexe d'échange entre le TPM et les agents de mesures que le matériel est certifié. (Un peu comem pour les empreintes digitales, le TPM cherche des "points de correspondance" quand il en a suffisament il valide, si ca ne marche pas il rejette).

                                  Bref l'interet de faire sortir les hashs de la puce TCPA est rigoureusement nul.

                                  P.S : j'ai beau chercher je ne vois nulle part mention de l'idée de faire sortir les hash de la puce.
                                  • [^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn

                                    Posté par (page perso) . Évalué à -1.

                                    et oui une carte graphique à 50°c n'aura pas le même hash que la même carte graphique à 20°c
                                    Du délire total :)
                                    • [^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn

                                      Posté par . Évalué à 4.

                                      Reprend la doc (la grosse, celel qui fait 300 pages) si tu l'as encore et fait une recherche sur "control points" et "aging materials". On y explique pourquoi un disque dur qui commence à rendre l'âme (tourne moins vite, certains clusters en erreur) ou une barrette mémoire veillisante (ECC qui tourne sur certaines zones, temps de latence en augmentation) vont être repérés par la puce TCPA mais en vont pas pour autant causer le verrouillage de la puce.
                                      • [^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn

                                        Posté par (page perso) . Évalué à 2.

                                        Ces histoires ridicules ont vraiment bien peu d'importance par rapport notamment à aux identifications de l'OS et des processeurs , qui elles ne dépendront surement pas de l'age du HDD ou du capitaine :) Et ce afin de s'assurer que l'OS et le proc ont bien le DRM que le provider requiert.
                                        D'ailleurs puisque on parle des docs d'origine, moi j'avais réupéré ça, sur l'ancien site TCPA (aujourd'hui offline) et toi aussi je le sais puisque je t'en avais communiqué l'URL:
                                        "a provider
                                        will need to know that the remote platform is trustworthy" "The TCPA
                                        system reports the metrics and lets the challenger make the final decision regarding the
                                        trustworthiness of the remote platform." http://www.trustedcomputing.org/docs/Credible_Interoperability_0207(...)
                                  • [^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn

                                    Posté par (page perso) . Évalué à 2.

                                    http://66.102.9.104/search?q=cache:https://www.trustedcomputinggrou(...)
                                    TCG features could potentially enable a situation in which users are essentially
                                    “forced” to use the TCG mechanism in order to have access to a set of services. This could result from “bundling” — where a single large provider of services could use the combination of its role as a major provider with the TCG remote attestation
                                    capability to ensure that the user is employing a configuration that the provider
                                    insists upon, even when there is no security reason for such a choice. Another
                                    situation that can arise is where a significant portion of the providers of a particular
                                    service could use their market clout (the fact that they constitute a majority of
                                    providers of that particular type of service) to essentially force the use of TPM


                                    Alors je t'explique: another cela veut dire une autre situation.
                                    Par remote attestation ils n'entendent donc simplement pas le fait de forcer quelqu'un à montrer qu'il a TPM mais bien de forcer quelqu'un à montrer les hash de sa configuration.

                                    Ces hashs sont d'ailleurs aussi évoqués par ce white paper d'IBM, pourtant destiné à faire la promotion de TCPA:
                                    http://www.research.ibm.com/gsal/tcpa/tcpa_rebuttal.pdf(...)
                                    • [^] # "remote attestation" avouée clairement par why_tcpa d'IBM

                                      Posté par (page perso) . Évalué à 2.

                                      JE corrige c'est dans ce document IBM pro TCPA:
                                      http://www.research.ibm.com/gsal/tcpa/why_tcpa.pdf(...)
                                      The TCPA chip is not particularly suited to DRM. While it does have the ability to
                                      report signed PCR information, and this information could be used to prevent play
                                      unless a trusted operating system and application were in use, this type of scheme
                                      be a nightmare for content providers to manage. Any change to the BIOS, the oper
                                      system, or the application would change the reported values. How could content
                                      providers recognize which reported PCR values were good, given the myriad platfo
                                      operating system versions, and frequent software patches?


                                      L'excuse donnée par ce document de 2002 fait aujourd'hui sourire:
                                      oui mais c'est dur car il faudrait stocker les hashs des BIOS des OS dans une grosse base de donnée.
                                      Ce dernier argument n'est pas sérieux avec la puissance actuelle des clusters de PC bon marchés. (cf les clusters de Google).
                                      • [^] # Re: "remote attestation" avouée clairement par why_tcpa d'IBM

                                        Posté par . Évalué à 2.

                                        While it does have the ability to
                                        report signed PCR information


                                        Avant d ecommencer, j'attire juste ton attentio que la puce TCPA ne renvoit pas les hash mais créé des reports signés en dfonction du PCR. On est donc bien dans le cadre challenge/response. Ouf.

                                        L'excuse donnée par ce document de 2002 fait aujourd'hui sourire:
                                        oui mais c'est dur car il faudrait stocker les hashs des BIOS des OS dans une grosse base de donnée.


                                        C'est clair, ca fait sourire, on voit tout à fait uen base de données contenir les quelques huit milliards de config bios d'uen machine, l'infinité des partionnements valides et se mettre à jour au fur et à mesure des mises à jour windows ou du lecteur de contenu. Ca fait quoi 2-3 To par utilisateurs grand maximum. Une paille quoi.

                                        Tout ca pour quoi ? Empécher un utilisateur d'accéder à un contenu distant, tout en sachant que si il y accède une fois après authentification il pourra faire ce qu'il veut de la clef et la déplacer si besoin est dans une zone moins restrictive ? Ca vaut le coup.
                                        Je ne comprend vraiment pas pouquoi l'ensemble des magnats de la vidéos et du son ne se sont pas jetés sur cette magnifique opportunité.

                                        Même google ne donne que 2go par utilisateur, c'est environ le millième de ce qui serait nécessaire.
                                        • [^] # Re: "remote attestation" avouée clairement par why_tcpa d'IBM

                                          Posté par (page perso) . Évalué à 2.

                                          signed PCR information, and this information could be used to prevent play
                                          unless a trusted operating system and application were in use,

                                          Tu nies l'évidence, c'est pathétique.
                                          • [^] # Re: "remote attestation" avouée clairement par why_tcpa d'IBM

                                            Posté par . Évalué à 2.

                                            Tu nies l'évidence, c'est pathétique.

                                            Moins pathétique que de modifier le sens à son avantage.
                                            Comment a ton avis le matériel et le logiciel deviennent-ils "trusted" ? Surtout vu que la puce ne peut pas contenir de clefs préchargés autre que la vendor key qui ne peut authentifier que la puce elle-mêrme ?

                                            Sans manipulation préalable de l'utilisateur c'est impossible. On a donc pas un système "out of the box." Ensuite le fournisseur a-t-il moyen de s'assurer de quelque façon que ce soit que la clef reste dans la zone dans laquelle il l'a mise ? Non...
                                            • [^] # Re: "remote attestation" avouée clairement par why_tcpa d'IBM

                                              Posté par (page perso) . Évalué à 3.

                                              Je crois que tu es vraiment aveuglé. Il n'a y a rien à ajouter que de répéter l'avoeu d'IBM, cofondateur de TCPA/TCG et fabriquant de puces TCPA:
                                              could be used to prevent play unless a trusted operating system and application were in use
                                              C'est clair pour tous ceux qui le lisent, sauf pour ceux qui préfèrent ne pas comprendre.
                                              • [^] # Re: "remote attestation" avouée clairement par why_tcpa d'IBM

                                                Posté par . Évalué à 2.

                                                could be used to prevent play unless a trusted operating system and application were in use

                                                Ca peut être utilisé pour empecher la lecture a moins qu'un OS et une application de confiance ne soient utilisés.

                                                J'ai prétendu le contraire ? Je dis juste que ca n'a rien a voir avec DRM. Tu te connectes à un site ou un service et pour afficher le contenu tu dois prouver que tu utilises bien l'OS et l'appli qui sont connus de ce service (Par exemple le même que celui qui a été utilisé pour payer par carte bleue l'abonement au site).

                                                Et je ne vois vraiment pas le rapport avec DRM, qui consiste à prévenir la copie ou la diffusion de fichiers existant en local sur la machine du client.

                                                Ok je ne pourrais pas lire le contenu si je ne suis pas authentifié. Et alors ? Ca m'empêche de booter ? Ca 'empêche de ripper mes CDs ? Ca m'oblige à utiliser windows ? Non
                                                La seule chose que ca m'oblige à faire c'est à revenir sur le site de la même façon que celle que j'ai utilisé au moment ou j'ai été authentifié.
                                                • [^] # Il était temps !

                                                  Posté par (page perso) . Évalué à 3.

                                                  Tu te connectes à un site ou un service et pour afficher le contenu tu dois prouver que tu utilises bien l'OS et l'appli qui sont connus de ce service
                                                  Ah enfin, tu admets que TCPA fait bien cela. Je te signales que tu as bien du poster + de 10 messages dans ce thread pour dire le contraire !

                                                  Et je ne vois vraiment pas le rapport avec DRM,
                                                  Cherche bien... D'autant plus que cela a déja été évoqué dans ce thread aussi: l'OS qu'on t'oblige à utiliser sera évidemment un OS qui va t'empecher de faire ce que tu veux avec ce contenu. Ce qui est la définition exacte de Digital Rights Management.
                                                  • [^] # Re: Il était temps !

                                                    Posté par . Évalué à 3.

                                                    Ah enfin, tu admets que TCPA fait bien cela. Je te signales que tu as bien du poster + de 10 messages dans ce thread pour dire le contraire !


                                                    Mais je n'ai JAMAIS dit le contraire. J'ai même dit dès le départ que c'était identique au fonctionement des certificats. Tu n'as pas ton certificat tu ne rentre pas.

                                                    D'autant plus que cela a déja été évoqué dans ce thread aussi: l'OS qu'on t'oblige à utiliser sera évidemment un OS qui va t'empecher de faire ce que tu veux avec ce contenu. Ce qui est la définition exacte de Digital Rights Management.

                                                    Mais le provider NE PEUT PAS savoir quel OS j'ai. A moins d'être physiquement présent sur ma machne et de faire les manips avec moi.
                                                    La seule chose qu'il puisse savoir c'est si j'ai le MEME os que celui utilisé une fois précédente.
                                                    • [^] # Re: Il était temps !

                                                      Posté par (page perso) . Évalué à 3.

                                                      Mais le provider NE PEUT PAS savoir quel OS j'ai.
                                                      Bon apprends l'anglais et relis les documents que j'ai cité dans ce thread, dont
                                                      "The TCPA
                                                      system reports the metrics and lets the challenger make the final decision regarding the
                                                      trustworthiness of the remote platform."
                                                      Dans les metrics il y a le hash exact de l'OS. Dans le cas d'un OS drm non modifié, ce sera toujours le meme hash.
                                                    • [^] # Re: Il était temps !

                                                      Posté par (page perso) . Évalué à 2.

                                                      Mais le provider NE PEUT PAS savoir quel OS j'ai.
                                                      Désolé mais le hash d'un OS drm non modifié est le meme tout le temps.
                                                      • [^] # Re: Il était temps !

                                                        Posté par . Évalué à 2.

                                                        Désolé mais le hash d'un OS drm non modifié est le meme tout le temps.

                                                        Sauf que
                                                        a) Le hash ne sors jamais de la puce
                                                        b) Chaque TPM est différent et chaque lot de measuring agent est différent.

                                                        Le hash est le même au sein d'une même puce, mais il va être complètement différent de celui de la puce d'à coté. Comment faire de la remote attestation si toutes les puces confrontées au même environnement renvoient les mêmes infos ?

                                                        Et au passage pour le post du dessus, metrics ca veut oujours dire "méthodes de mesures" et non pas mesures.
                                                        • [^] # Re: Il était temps !

                                                          Posté par (page perso) . Évalué à 2.

                                                          Tu es incroyable ! Le hash fait partie des metrics et est donc envoyé !
                                                          • [^] # Re: Il était temps !

                                                            Posté par (page perso) . Évalué à 1.

                                                            Pour être précis, on sera dans une situation où le provider pourra exiger que l'utilisateur lui fournisse un PCR signé établi avec exactement le metric du bootloader d'un OS DRM.
                          • [^] # Re: "remote attestation" avouée par TCG et aussi par IBM, refuser = gagn

                            Posté par (page perso) . Évalué à 2.

                            Par exemple les licences MS ne sont pas du tout validées à distance et locké par PC. Du tout.

                            Euh, oui, mais c'est fait par du soft, contrairement au TPM qui est implémenté en hard et qui devait (à l'origine) être supporté par une puce "incrackable", c'est-à-dire resistant aux investigations matérielles. Ca fait quand même une différence non négligeable, non ?
        • [^] # Re: et oui les TPM ...

          Posté par . Évalué à 5.

          Ca a l'air de ressembler a TCPA

          C'est TCPA

          c'est le retour de Palladium/NGSCB ?

          Rien a voir. Palladiu vise à pouvoir certifié le matériel et le logiciel de façon globale (ie que telle appli et tel matériel sont bien conformes à ce qui est annoncé), TCPA/TPM n'a pas d'autre but que de certifier la cohérence d el'ordi par rapport à lui même. (et maintenant qu'IBM laisse tomber sa division x86 ca ne dervait pas changer).
          A titre d'exemple, pour ce que l'on sait de palladium (c'est à dire pas grand chose) il devrait être capable de detecter un disque dur "splitté", c'est à dire un réseau de disque dur en mirroring hardware,d'un disque dur standard. Ceci dans le but d'éviter qu'un fichier DRM copié depuis internet ne se trouve dupliqué n fois suite à un seul paiement.
          TPM d'un autre coté ne possède pas d'information de ce type, il signe quand on le lui demande et garde le résultat en interne (il est impossible de faire sortir une signature hardware/software de TPM). Aussi semblable soient-ils, deux disques durs lui apparaitront comme différent, il est donc impossible de certifier "globalement" un ensemble de périphériques.
    • [^] # Re: et oui les TPM ...

      Posté par . Évalué à 5.

      Au passage il existe un emulateur pour ceux qui ne possede pas la puce : http://developer.berlios.de/projects/tpm-emulator/(...)
    • [^] # Re: et oui les TPM ...

      Posté par . Évalué à 3.

      a quoi ca va servir

      Personellement je m'en sers déjà et depuis un bon moment, les TPM sont un coffre à clef qui permet de mettre toutes les clef privées dans une boite noire accessible seulement si un certains nombre de conditions sont remplies.
      Les condition peuvent être soit un boot particulier (si quelqu'un boote depuis un autre disque dur, depuis une clef USB ou depuis une disquette le coffre ne souvre pas), soit simplement une identification connaissance (par mot de passe saisi par l'uilisateur par exemple).

      Ca fait un petit moment que sur mon laptop IBM mes clefs sont dans la boite noire.

      Il est bon de rapeler qu'en l'état actuel des choses il est impossible d'utiliser TPM pour empecher de booter un OS ou pour s'assurer qu'un OS certifié "globalement" (c'est à dire que la signature n'a pas été faite sur votre portable) est le seul bootable.
      • [^] # Re: et oui les TPM ...

        Posté par . Évalué à 5.

        enfin une cle usb peut aussi contenir toutes tes cles prives . C'est rapide et c'est sur. en plus c'est mobile si tu as un autre ordi de confiance.
        Quand tu pars tu recup ta cle usb et pouf plus de problème. Et pas d'ouverture possible a un palldium quelconque.
        • [^] # Re: et oui les TPM ...

          Posté par . Évalué à 4.

          Si je met toutes mes clefs privées sur ma clef USB, j'ai pas interet à la perdre ma clef (ou à me la faire piquer). Si je mets toutes mes clefs dans une puce TCPA sur mon portable, le mec qui m pique mon portable sera bien avancé. Il luis era impossible de sortir les clefs de la zone sans le mot de passe admin de la puce (et même comme çà il pourra juste les transférer sur une autre puce et sera incapable de les lire en clair).

          Il n'y a déjà pas d'ouverture possible à Palladium avec les versions actuelles de TPM. C'est inutilisable pour la certification de matériel (toutes les puces et tous les matériels génèrent des hash différents non recoupables - c'est même le but premer de la puce). C'est inutilisable pour l'authentification croisée (chaque "client" TCPA se retrouve dans sa zone personelle avec un identifiant de zone qui change à chaque fois) . C'est Inutilisable pour le DRM (toutes les clefs challengeables sont copiables/migrables/déplaceable - Dieu merci).

          Bref pour faire du controle à distance et de la certification globale avec çà bonjour.
          • [^] # Re: et oui les TPM ...

            Posté par (page perso) . Évalué à 4.

            >Si je met toutes mes clefs privées sur ma clef USB, j'ai pas interet à la
            >perdre ma clef (ou à me la faire piquer). Si je mets toutes mes clefs
            >dans une puce TCPA sur mon portable, le mec qui m pique mon
            >portable sera bien avancé.

            Rien n'empèche de mettre un mdp global sur la clef usb via un loopfs (ou autre) de plus tu peux choisir l'algo, la longeur de clef etc...

            >Il luis era impossible de sortir les clefs de
            >la zone sans le mot de passe admin de la puce (et même comme çà il
            >pourra juste les transférer sur une autre puce et sera incapable de >les lire en clair).

            Alors là ca reste à voir le nombre de gadgets révolutionnaires bourrés de backdoors et bugs divers ne montrent aucune confiance.

            Franchement ca pue, ca fais "mettez tous vous passwords là dans la boiboite comme ca on a même plus besoin de les chercher"...
            • [^] # Re: et oui les TPM ...

              Posté par . Évalué à 7.

              Avec loopfs, tes Clées et ton systéme crypto devront être décoder en mémoire a un moment ou un autre pour être utiliser. TPM est plus similaire a une carte a puce, la gestion des clés et autre ne sorte jamais de la puce c'est la toute la force du systéme, les clés ne sont jamais accessible a quelque moment que ce soit, elles sont gérées, générés et utilisés dans la puce et jamais par le processeur centrale dans de la RAM, et quand elles sont transférés c'est uniquement d'une puce TCPA a une autre puce TCPA de maniére coder.

              En gros avec TCPA tu fait l'économie d'un lecteur de carte ( 100¤ ) et d'une smart card avec des fonction de module de sécurité ( 15¤ la carte ), soit 115¤ d'économie rien qu'en utilisant une techno déjà présente dans ton portable.
              • [^] # Re: et oui les TPM ...

                Posté par . Évalué à 3.

                j'avais compris que le truc de crypto c'etait "que dans la puce" mais tu ne repond pas du tout a ce que j'ai dis :
                C'est pas parce que c'est que dans une puce que c'est plus sécurise : quid des fonctions de hashages qui ont des collisions maintenant ?

                Alors tu me dis que ca sort pas de la puce. Mais comme dis précédement ca me fait une belle jambe que ca sorte pas de la puce ; sachant que les documents a chiffrer il faudra bien les amener a la puce. Et vu que tu as si peu confiance en ton pc ; on peut tres bien sniffer le bus de données !
                Et de toute facon vu que tu dis qu'il y a une possibilite de sniffer; alors dans ce cas il y a aussi une possibilité que la puce ait une backdoor ou autre !

                Maintenant supposons qu'elles sont transferer de manière "coder" entre deux puces tcpa. Qu'est ce qui empeche d'avoir une puce "tcpa" virtuelle; Les fonctions etant bijectives oh tiens ca alors j'ai la clé en clair ; je me suis pourtant juste fait passer pour une autre puce...

                donc dans tous les cas aucun interet particulier avec cette "superbe" puce tpm, si ce n'est d'offrir qu'une illusion de sécu que l'on a bien plus par les systèmes decris au dessus.


                Ensuite un lecteur de carte a puce 100 euros ? on doit pas avoir les meme fournisseurs
                perso sur un catalogue de selectronic de 2004 j'en trouve a 30 euros ...
                soit 35 euros de pseudo economie car une carte a puce est quand meme sacrément plus mobile qu'un portable ...


                Je rappelle que la sécurite maximale d'un système ets toujours la sécurite maximale du plus FAIBLE maillon !
                Donc si tu estime que l'os est le plus faible maillon ; que ce soit dans une carte a puce , une puce ou autre ; sachant que tu utilise l'os ; tu auras toujours la meme sécu.
                • [^] # Re: et oui les TPM ...

                  Posté par . Évalué à 3.

                  C'est pas parce que c'est que dans une puce que c'est plus sécurise : quid des fonctions de hashages qui ont des collisions maintenant ?

                  Je ne vois pas le rapport avec les fonctions de hashages, les fonctions de hashages ont toujours eux des collision ( c'est quand le calcule pour trouver ces collisions devient possible en un temps raisonnable que cela devient un problème ).

                  Si les clés sont cantonnés dans la puce, les risque de vole de clé sont presque nul, c'est la que ce trouve le gain de sécurité, maintenant si tu n'as pas confiance dans les fabricants de la puce en effet je ne vois pas ce qui pourrait te conviancre et te conseillerait de jeter au plus vite ta carte bleue, ton téléphone portable et autre.

                  Alors tu me dis que ca sort pas de la puce. Mais comme dis précédement ca me fait une belle jambe que ca sorte pas de la puce ; sachant que les documents a chiffrer il faudra bien les amener a la puce. Et vu que tu as si peu confiance en ton pc ; on peut tres bien sniffer le bus de données !

                  Le systéme n'est pas une protection absolue, la protection absolue n'existe pas, de plus TCPA ne s'occupe pas spécialement de la protection des donnés une fois décrypté. TCPA se focalise sur la protections des clés et dans ce domaine c'est un gain incontestable en matière de sécurité. De plus si tu utilise toutes les fonctions de vérification d'intégrités de TCPA, cela limite fortement les chances pour qu'on sniffe ton document a un endroit ou un autre de la chaine ( bien que des attaque physique comme le sniffing du bus reste possible ).

                  Et de toute facon vu que tu dis qu'il y a une possibilite de sniffer; alors dans ce cas il y a aussi une possibilité que la puce ait une backdoor ou autre !

                  On peut avori le même raisonnement avec tous les systémes, qui te dit que ton processeur actuel n'intégre pas une backdoor ? La protéction absolue n'existe pas, mais est ce pour autant que l'on doit abandonner tous les systèmes de protection pour autant ? Doit on dire non a un système plus robuste sous le prétexte qu'il n'est pas « la protection absolue et universel ? ». En effet TCPA ne peut rien contre les personnes qui lisent par dessus ton épole ou si un pirate a sortie un train de cable de ton PC pour sniffer directement le bus donné... dans les autres situation TCPA renforce la sécurité de tes clés et donc de tes donnés.

                  Maintenant supposons qu'elles sont transferer de manière "coder" entre deux puces tcpa. Qu'est ce qui empeche d'avoir une puce "tcpa" virtuelle; Les fonctions etant bijectives oh tiens ca alors j'ai la clé en clair ; je me suis pourtant juste fait passer pour une autre puce...

                  Parce que les puces TCPA contiennent une certificat numérique, comme lors d'une connections SSL, les deux puces vont vérifiés qu'elles ont bien affaire a une puce TCPA avant de négocier et d'établir le canal crypté pour le transfére des clés. Donc pour que ta puce virtuelle ( emulateur ) fonctionne il faut d'abord que tu réussice a récupérer le certificat d'une puce TCPA existante. Vue que ce certificat est dans la puce et le mécanisme de signature et d'identification sont costaux je te souhaite bonne chance.

                  La encore comme pour verisign ou tous autre CA, certificat ou autre, la compromission est possible, mais fort improbable.

                  donc dans tous les cas aucun interet particulier avec cette "superbe" puce tpm, si ce n'est d'offrir qu'une illusion de sécu que l'on a bien plus par les systèmes decris au dessus.

                  Je ne sais pas qui s'illusionne en stockant ses clés ou son pad lock en claire ou avec plus ou moin de cryptage sur un disque dur.

                  Ensuite un lecteur de carte a puce 100 euros ? on doit pas avoir les meme fournisseurs
                  perso sur un catalogue de selectronic de 2004 j'en trouve a 30 euros ...
                  soit 35 euros de pseudo economie car une carte a puce est quand meme sacrément plus mobile qu'un portable ...


                  On parle bien de carte a puce cryptographique la ? Parce qu'a 30¤ j'achéte de suite. Plus sérieusement une carte a puce en mesure de faire du RSA et de la signature cela coute au minimum de 15-20¤ la carte et je sais de quoi je parle. Pour 30¤ le mieux que tu puisse trouver c'est un lecteur d'empreinte digital sans pad lock, ou un lecteur de carte d'identification ( carte incapable de gérer des certificats genres X.509 ou des clés RSA ).

                  Je rappelle que la sécurite maximale d'un système ets toujours la sécurite maximale du plus FAIBLE maillon !
                  Donc si tu estime que l'os est le plus faible maillon ; que ce soit dans une carte a puce , une puce ou autre ; sachant que tu utilise l'os ; tu auras toujours la meme sécu.


                  Bof en cas de compromission, tu te fera voler ton keyring et le hackeur pourra travailler a le decoder bien tranquillement chez lui, avec TCPA il ne pourra pas te voler ton keyring, c'est déjà un plus important.

                  Aprs bien évidement tu vas me dire qu'il est passé root, et qu'il va dumper la mémoire ( et transférer le bon Go du dump furtivement ) au bon moment et partir a la chasse de ton document dans le dump etc etc ... Personnellement je trouve ce sénario moins probable que le vole de clé, de plus il serait tout autant imaginable avec un solution sans TCPA.

                  Donc oui encore une fois TCPA n'est pas la protection ultime, mais il offre un gain énorme dans le domaine de la protection des clés.
                  • [^] # Re: et oui les TPM ...

                    Posté par . Évalué à 3.

                    Je ne vois pas le rapport avec les fonctions de hashages, les fonctions de hashages ont toujours eux des collision ( c'est quand le calcule pour trouver ces collisions devient possible en un temps raisonnable que cela devient un problème ).

                    Normes de sécu : 2^80. on considère donc que si on ne peut pas trouver de collisions en moins de 2^80 calculs alors elle n'a pas de collisions (on ne peut pas les trouver). Je reconnais que c'est un abus de langage mais a part ca...

                    Si les clés sont cantonnés dans la puce, les risque de vole de clé sont presque nul, c'est la que ce trouve le gain de sécurité, maintenant si tu n'as pas confiance dans les fabricants de la puce en effet je ne vois pas ce qui pourrait te conviancre et te conseillerait de jeter au plus vite ta carte bleue, ton téléphone portable et autre.
                    1°) j'ai pas de telephones portables.
                    2°) la cb est sur un système spécifique ; et n'est pas "ma cle privéé" mais une clé privé que me fournis la banque. Si il y a une merde de sécu avec leurs système je suis assure.

                    On peut avoir le même raisonnement avec tous les systémes, qui te dit que ton processeur actuel n'intégre pas une backdoor ?
                    Un backdoor dans un processeur? faut qu'on m'explique la.

                    La protéction absolue n'existe pas, mais est ce pour autant que l'on doit abandonner tous les systèmes de protection pour autant ? Doit on dire non a un système plus robuste sous le prétexte qu'il n'est pas « la protection absolue et universel ? ».
                    C'est toi qui dis que c'est le plus robuste. Je ne suis pas d'accord avec ca, et comme faisait remarquer quelqu'un ; les puces d'aide à la crypto ca existait avant le tcpa; donc non ce n'est certainement pas le plus robuste. Une petite aide : est ce que dans les snle ils utilisent des portables equipes de tcpa?


                    En effet TCPA ne peut rien contre les personnes qui lisent par dessus ton épole ou si un pirate a sortie un train de cable de ton PC pour sniffer directement le bus donné... dans les autres situation TCPA renforce la sécurité de tes clés et donc de tes donnés.
                    Dans les autres situations ? Ah oui lesquelles? On peut faire des sniffer qui envoie les données d'un point de vue radio par exemple ; hop tu le remarque pas a moins de tout demonter etc...
                    Non franchement je vois pas ce qu'apporte tcpa en plus par rapport a un système assez sur :
                    cles usb pour stocker le truc.
                    A la rigueur tripwire sur un cdr si tu veut verifier ton os .
                    et voila aussi sur que tcpa sans avoir tout les rsiques que cela cause.


                    Donc oui encore une fois TCPA n'est pas la protection ultime, mais il offre un gain énorme dans le domaine de la protection des clés. c'est pas en lerepetant plus de fois qu eca va devenir vrai.

                    Je susi tout a fait d'accord avec une aide a la crypto etc... Mais qu'ils nous fournisse le hdl de leurs puces , le code utilisé et que l'on puisse choisir le CA.
                  • [^] # Re: et oui les TPM ...

                    Posté par . Évalué à 4.

                    Si deux puces ont besoin d'un certificat tiers pour établir un canal sécurisé pour transférer des clés, est-ce que ça veut dire qu'elles contiennent des clés privées qui appartiennent à une autre personne que le propriétaire de ladite puce ? Dans ce cas je trouve ça assez dérangeant. De toute façon, je trouve inacceptable qu'on ne puisse pas récupérer ses propres clés privées en clair.

                    De plus, beaucoup de gens qui sont favorables à cette technologie semblent indiquer que le niveau de sécurité sera globalement plus élevé. Cela implique que la populace aura une plus grande confiance dans le système et que donc les dégâts seront plus grands en cas de faille ou de mauvaise utilisation. Il faut aussi prendre cela en compte dans l'acceptation de cette technologie. Parfois, trouver que c'est trop sûr peut être un argument valide...

                    En ce qui concerne les cartes à puce, beaucoup de gens se font des illusions sur la sécurité que ça apporte. En fait, le niveau de sécurité supplémentaire apportée par l'utilisation d'une carte à puce cryptographique n'est pas très élevé par rapport à une disquette contenant la clé privée, car dans les deux cas le système doit être utilisé sur une machine dont vous avez le contrôle. Sinon, un attaquant peut très bien
                    a) dans le cas de la disquette récupérer la clé et le mot de passe pour la décrypter
                    b) pour la carte à puce le code PIN/mot de passe et faire signer n'importe quoi à la carte tant qu'elle est dans le lecteur.

                    Dans tous les cas, puisque vous devez avoir le contrôle de la machine, vous pouvez aussi stocker la clé dessus. Les attaques se limitent alors au vol de
                    a) la disquette et l'attaquant doit casser le cryptage
                    b) l'ordinateur, même attaque mais plus difficile d'emporter une machine ou son disque dur
                    c) la carte à puce et là une analyse électronique s'impose.

                    Dans tous les cas il est plus efficace de torturer le possesseur ;)
          • [^] # Re: et oui les TPM ...

            Posté par . Évalué à 6.

            pour continuer sur le post de Romain
            As tu une ne serait ce qu'une preuve partielle de sécu avec ta pupuce?
            Serait t'il possible de tester les mots de passes en brute force ?
            Le mot de passe que tu lui a passe est ce toi qui la choisis ? si oui il y a une possibilite de le modifier , est ce que cette possibilité est suffisament protéger niveau hardware ?...

            Je suis desole mais si tu veux vraiment faire mumuse tu te fais du one time pad sur ta cles usb. Et comme ca elle est lisible que depuis ton ordi . (Le one time pad; si la cle est vraiment aléatoire est juge comme inconditionnellement sur).
            Personnellement j'ai plus confiance en un truc ouvert qu'on sait comment ca marche plutot qu'a une boite noire. D'ailleurs a peu pres toutes les boites noires en crypto se se font decrypter. La non obfuscation c'est un principe .

            et même comme çà il pourra juste les transférer sur une autre puce et sera incapable de les lire en clair
            Il y a forcémenet un moment ou elles sont en clairs . rien ne l'ui empeche d'avoir une puce qui se fait passer pour uen puce tcpa et qui est en réalité juste une grosse bd qui les stockent en clair...


            Pour le fait que ce ne soit pas "utilisable" pour palladium ou autre, je suis desole mais c'est toi qui le dis, tant qu'on ne sait pas ce qu'il y a reelement dans la boite , je ne leur ferait pas confiance .
            • [^] # Re: et oui les TPM ...

              Posté par . Évalué à 3.

              Je suis desole mais si tu veux vraiment faire mumuse tu te fais du one time pad sur ta cles usb. Et comme ca elle est lisible que depuis ton ordi . (Le one time pad; si la cle est vraiment aléatoire est juge comme inconditionnellement sur).

              Pardon mais la clé du one-time pad (masque jetable), qui doit être de la même longueur que les données chiffrées, tu la stockes où ? Sur une autre clé USB ?
              :)
              • [^] # Re: et oui les TPM ...

                Posté par . Évalué à 2.

                sur ton pc .
                Sachant que tu stocke a des endroits differents la clés usb et le pc , qu'ils ne sont ensembles que quand tu t'en sers ; et que tu regenere un masque a chaque fois ....
                Il faut que la personne ait a la fois ton pc et ta cle usb pour pouvoir s'en servir ; ou qu'il arrive a te subtiliser les deux avant que tu t'ens serve...

                Maintenant si tu n'as pas un minimum de confiance dans ton pc ; alors la tu ne devrais pas avoir confiance non plus confiance dans ta puce tcpa :)
            • [^] # Re: et oui les TPM ...

              Posté par . Évalué à 4.

              A tu une preuve partielle de la sécurité de ta carte bleu ?

              Tu ne peux essayer de brutalforcer une une clé coder que si tu as la clé a disposition, hors avec TCPA la clé est bien cachés dans sa puce, et vue que la durée entre deux essais infructueux est protégés le brutal force est inéfficasse face a ce systéme.

              Le mot de passe administrateur de la puce est défini par le propriétaire, il est tous a fait possible de le modifier. C'est d'ailler de mon point de vue le seul point faible du systéme, ce type d'opération devrait n'être entreprise par l'utilisateur qu'a partir d'un systéme de confiance ( boot a partir d'un CD ), pour être sur que son systéme n'est pas logger. Il y a bien évidament une protection hardware de disponible mais c'est cette dernières qui faire peure a beaucoup, c'est celle basé sur le transitonnal trust, CAD, la séquence de boot dont l'intégrité est vérifié par la puce. En gros tu par exemple défini dans ta puce que le mot de passe admin ne pouvait être modifié que si, la machine avait bien le même BIOS, le même bootloader et booté sur le même kernel afin d'être sur qu'il n'y a personne pour écouter le pass admin entre la prise de ton clavier de ta carte mère et la puce. Cette fonction n'est pas obligatoir et comme je l'ai dit plus haut on peut très bien le configurer pour un CD-ROM ( je pense même que c'est la solution la plus simple dans le cas d'un OS open source de geek, qui par définition fluctue pas mal ).

              Donc pour résumé, tu peux changer le passe, des protections existe mais ne sont pas obligatoire, configurer la puce pour que le passe ne puisse étre changer que dans le cas d'un boot a partir d'un CD prévue pour semble étre une bonne solution. ( Dans tous les cas il faut bien évidement l'ancien mot de passe admin pour pouvoir modifier le dernier. )

              Le problème du One time pad est identique a celui du crytpo loopback, les clés se baladeront en mémoire a un moment ou un autre, alors que TCPA est prévue pour que même un espion coder dans le Bios ne puisse pas les interceptés. TCPA est un systéme beaucoup plus résistant ( apres il est evident qu'un telle niveau de sécurité n'est pas nécessaire pour tous le monde, mais il ne faut pas oublier que TCPA a été consut avant tous pour les professionnel ).

              Ce n'est pas une boite noire ou de l'ofuscation, c'est un module de sécurité comparable a toutes les cartes a puces, que ce soit pour de carte de payement, de téléphone, TV satélite ou autre. TCPA a même l'énorme aventage d'étre standardisé documenté et implémentable librement.

              Il y a forcémenet un moment ou elles sont en clairs . rien ne l'ui empeche d'avoir une puce qui se fait passer pour uen puce tcpa et qui est en réalité juste une grosse bd qui les stockent en clair...

              Tu pense sérieusement que deux puces spécialisé dans la cryptographie ne sont pas fichue d'établir un canal crypté avec authentification forte pour transférer les clés ? C'est d'alleur la grosse limitation des emulateurs TCPA, comme ils ne peuvent pas prouver qu'ils sont de réel puce TCPA ils ne peuvent pas récupérer les clés d'une puce TCPA.

              Pour le fait que ce ne soit pas "utilisable" pour palladium ou autre, je suis desole mais c'est toi qui le dis, tant qu'on ne sait pas ce qu'il y a reelement dans la boite , je ne leur ferait pas confiance .

              Palladium repose sur la technologie LaGrande, qui est fondamentalement différente de TCPA, LaGrande est un systéme de cryptage a la volé de la RAM, afint d'établir des canaux sécurisé au saint même de la machine, l'un des utilisation de telles canaux c'est le DRM ( plus de contenue en claire dans la ram, ou même vers la carte son ). Alors que TCPA ne s'occupe que de la protection des clés, et de la vérification de l'intégrité du systéme.
              • [^] # Re: et oui les TPM ...

                Posté par . Évalué à 0.

                la carte bleu ? HAHAHAHAHAHAHA y en a qui ne correspondent pas aux normes de sécu actuelles. Meme pas besoin de preuves de sécu ...

                Tu ne peux essayer de brutalforcer une une clé coder que si tu as la clé a disposition, hors avec TCPA la clé est bien cachés dans sa puce, et vue que la durée entre deux essais infructueux est protégés le brutal force est inéfficasse face a ce systéme.
                Et la suite du post sur la possibilité de changer le mdp :

                Eh oh on parle pas de moyens d'amateurs mais de pros ; cad avec engenerie inverse des puces toussa .... Donc les sois disantes protections laisse moi rire on va lui donner les infos qu'il veut ; il va nous autorise a lancer le bios pendant qu'on en lance un autre...


                Le problème du One time pad est identique a celui du crytpo loopback, les clés se baladeront en mémoire a un moment ou un autre, alors que TCPA est prévue pour que même un espion coder dans le Bios ne puisse pas les interceptés.

                Ton espion si il est code dans le bios; il les verra pas se balader les cles... c'est si il y a un sniffer sur les bus qu'il le verra :
                le bios initialise le matos ; puis passe la main au mbr.


                TCPA est un systéme beaucoup plus résistant ( apres il est evident qu'un telle niveau de sécurité n'est pas nécessaire pour tous le monde, mais il ne faut pas oublier que TCPA a été consut avant tous pour les professionnel ).
                Ah oui comme dis au dessus : si j'arrive a modifier ton pc pour installer un sniffer des bus de donnés ; style que je vais me gener pour changer ta puce tcpa ....
                Si j'arrive a installer un sniffer; j'aurais acces a TOUS tes documents donc je vais te faire croire que tu vas a ta puce tcpa alors qu'en réalité tu iras sur un simulateur de puce et donc que j'aurais la main mise sur le système.


                Tu pense sérieusement que deux puces spécialisé dans la cryptographie ne sont pas fichue d'établir un canal crypté avec authentification forte pour transférer les clés ? C'est d'alleur la grosse limitation des emulateurs TCPA, comme ils ne peuvent pas prouver qu'ils sont de réel puce TCPA ils ne peuvent pas récupérer les clés d'une puce TCPA.
                Le canal de cryptage auqu'un problème. Sauf que moi je me place APRES la communication :
                Alice envoie a Bob la cle crypter de tel sorte que charlie puisse pas la recevoir. Ca on est tous d'accord ils sont capables de le faire.
                Et maintenant qu'elle authentification peut te prouver que Bob n'est pas compromis ? Une athentification rsa ou semblable? Dans ce cas il faut voir quelle est le CA qui distribue les cles publiques. Et comme la CA est une entreprise privée qui fait les puces ; rien ne lui interdis de publier une cles publique et d'avoir une puce speciale avec la cle privee qui correpond et et cette puce stocke toutes les donnes trasnmises 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 (page perso) . Évalué à 5.

                  > si j'arrive a modifier ton pc pour installer un sniffer des bus de donnés

                  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 (page perso) . Évalué à 3.

                    Par contre, être protégé des attaques logiciel
                    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 (page perso) . Évalué à 2.

                    C'est clair. Le but de TCPA, c'est de repousser au niveau de hardware les possibilités d'attaques.
                    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 (page perso) . Évalué à 2.

                      > Non, les données seront accéder par un OS et par des logiciels.

                      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 (page perso) . Évalué à 2.

                        Dans tous les cas, c'est mieux d'avoir un OS fiable et sécurisé
                        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 . Évalué à 2.

                          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 ?

                          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 (page perso) . Évalué à 2.

                            Les nombreux documents dont j'ai donné les URL ci-dessus disent clairement le contraire de ta vision angélique.
                            • [^] # Re: et oui les TPM ... le contraire

                              Posté par . Évalué à 2.

                              Non.
                              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 (page perso) . Évalué à 2.

                                C'est ta parole contre celle de TCG et IBM qui admettent clairement dans les documents que j'ai cité que on peut identifier à distance la plateforme en utilisant les metrics (c'est à dire les hash) des matériels et des logiciels.
                                • [^] # Re: et oui les TPM ... le contraire

                                  Posté par . Évalué à 2.

                                  On peut authentifier la plateforme en utilisant le système d'authentification via challenge response lequel s'appuie sur les metrics. Un challenge signé PCR, c'est comme une clef GPG. Si je te donnes ma clef tu vas avoir du mal a savoir quelle taille je fais. C'est ici la même chose !
                                  • [^] # Re: et oui les TPM ... le contraire

                                    Posté par (page perso) . Évalué à 2.

                                    via challenge response lequel s'appuie sur les metrics
                                    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 . Évalué à 3.

                                      Cela veut dire que les metrics sont envoyés au remote challenger qui décide en fonction de ces metrics.

                                      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 (page perso) . Évalué à 2.

                                        La encore tu fais exprès d'oublier que pour accéder aux informations issues d'une configuration (OS, etc), il faut booter dans cette configuration.
                                        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 . Évalué à 1.

                                          La encore tu fais exprès d'oublier que pour accéder aux informations issues d'une configuration (OS, etc), il faut booter dans cette configuration.

                                          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 (page perso) . Évalué à 1.

                                            "ll est impossible de deviner l'OS"
                                            unless a trusted operating system and application were in use
                                            • [^] # Re: et oui les TPM ... le contraire

                                              Posté par (page perso) . Évalué à 2.

                                              J'ajoute que cette phrase officielle a une explication simple: il suffit à un provider d'exiger que l'utilisateur distant utilise comme metric uniquement un bootloader précis, non modifié, qui lui se chargera de vérifier que l'OS est bien un OS précis avec DRM et non modifié. Le hash sera donc toujours le meme.
                                • [^] # Re: et oui les TPM ... le contraire

                                  Posté par . Évalué à 3.

                                  J'ai l'impression que tu fais un gros amalgame entre identification (qui je suis) et authentification (la preuve que je suis bien ce que je prétends être).

                                  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 (page perso) . Évalué à 3.

                                    Et en ce qui concerne TCPA, les metrics ce sont les hash des matériels et logiciels utilisés sur l'ordinateur.
                                    Il n'y a donc pas d'ambiguité.
                                    • [^] # Re: et oui les TPM ... le contraire

                                      Posté par . Évalué à 2.

                                      En ce qui concerne TCPA les hash s'apellent les hashs, la partie de TCPA qui fait les hashs s'apelle les measurement agents et les measurements sont ensuite validées par le TPM puis transmis à la demande de l'attestation service sous forme de hash.
                                      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 . Évalué à 4.

                                On a carrèment de la marge entre maintenant et la zone rouge.
                                Peut-être sommes nous loin de la zone rouge, mais nous faisons un pas vers elle. Je pense que c'est maintenant qu'il faut refuser d'aller dans le sens de la sécurité au détriment de la liberté, car ce sera beaucoup plus difficile lorsque ces technologies seront répandues dans les foyers.
                        • [^] # Re: et oui les TPM ...

                          Posté par (page perso) . Évalué à 6.

                          > C'est en effet le véritable fondement de la sécurité et TCPA n'y changera rien.

                          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 (page perso) . Évalué à 3.

                            Quand on s'exprime dans un forum on peut faire des maladresses. Si j'en ai fait, mea culpa.

                            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 . Évalué à 3.

                              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.

                              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 (page perso) . Évalué à 3.

                                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
                                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 . Évalué à 3.

                                  Le meilleur moyen de ne pas être victime d'un "méchant", c'est d'être paranoïaque.

                                  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 . Évalué à 1.

                                    oui le consortium tcpa a pu s'etre mis d'un commun accord pour introduire des backdoors (euh pardon ; fonction non documentes) dans les puces .
                                    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 . Évalué à 7.

                                      Si ca se trouve la nsa a fait pression sur Intel, 3Com, ... pour qu'ils mettent une backdoor dans leurs cartes reseau, processeurs,... existantes et deja vendues par millions

                                      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 . Évalué à 2.

                                        faut vraiment qu'on m'explique comment on peut faire un backdoor sur un processeur...
                                        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 (page perso) . Évalué à 2.

                                          Des backdoors, il peut y en avoir à tous les niveaux entre le mec qui écrit un programme et ce qui est vraiment executé. Ça peut être le programme lui même, le compilo, l'éditeur de lien, le chargeur dynamique, l'OS, ou le matériel. Une backdoor dans un CPU, c'est certainement très difficile à implémenter, mais absolument pas impossible au moins en théorie. Un CPU qui reconnait une certaine suite d'instructions (genre, le code qui sert a demander login+password) et qui execute autre chose à la place (genre, sauter la vérification du mot de passe si le login est gbush) par exemple.
                                          • [^] # Re: conséquences graves passent avant le reste

                                            Posté par . Évalué à 2.

                                            reussir a connaitre une certaine suite d'instruction pour recup le login et mdp ?
                                            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 (page perso) . Évalué à 5.

                                    Le meilleur moyen de ne pas être victime d'un "méchant", c'est d'être paranoïaque.
                                    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.


                                    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 . Évalué à 2.

                                      "Lotus Notes, c'est génial. Les fonctions de cryptographie vont sécuriser tous nos emails"

                                      juste une question, le chiffrement utilisé par lotus notes est il mauvais ?
                                      • [^] # Re: conséquences graves passent avant le reste

                                        Posté par (page perso) . Évalué à 5.

                                        Sur Google, tu peux taper les choses suivantes:
                                        "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 . Évalué à 4.

          Sauf que ta clef circule sur le bus usb, est presente en memoire et passe a travers un certains nombre de soft, il est donc plus facile de la sniffer que dans le puce TPM où ta clef privé y reste et ou les calculs cryptographiques y sont fait...

          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 . Évalué à 2.

            donc ta puce tpm implémente toutes les methodes de cryptages , de signature et d'authentification connu a ce jours? vachement balaise dis moi !
            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 . Évalué à 3.

              Non de base seule le RSA ( 2048, 4096bit ), AES ( 256bit ), SHA-1 et le HMAC sont imposés en standard, d'autre peuvent être ajouté ( ECC par exemple, taille de clé plus large, etc etc ). Ce qui couvre déjà un bon nombre de situation.

              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 . Évalué à -4.

                SHA-1
                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 . Évalué à 6.

                  SHA-1
                  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 . Évalué à -3.

                    qu'est ce qui te permet de dire que SHA-1 ou SHA-256 ne sont plus sur pour un usage cryptographique ?
                    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 . Évalué à 4.

                      > Il y a eu une proof of concept sur sha-1 ca me suffit !

                      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 . Évalué à 3.

                        Le mémoire de projet d'un ami sur la méthode de Wange et Klima sur MD5:
                        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 . Évalué à 2.

                          je suis tout a fait d'accord qu'il y a encore rien d'"urgent" avec sha1 et qu'il a encore de beaux jours devant lui.
                          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 . Évalué à 4.

                            Mais il existent d'autres fonctions de hashage qui ne presente pas ce problème. pourquoi ne pas changer alors?

                            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 (page perso) . Évalué à 2.

                              Chaque années de nouvelles failles sont trouvées dans les algo de crypto ce qui doit nous inciter à la prudence. En utilisant des clés et des hashs ayant la taille maximale que l'on puisse traiter avec un temps raisonable. Inutile d'attendre d'avoir une grosse faille pour augmenter ces tailles.

                              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 . Évalué à 2.

                                @Jerome Herman
                                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 . Évalué à 5.

                                  Ca dépend de ton proof of concept.
                                  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 (page perso) . Évalué à 2.

                                    Je pense que la version anglaise de wikipedia résume bien les 2 approches possibles en matière de sécurité:
                                    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 . Évalué à 4.

                      C'est pas en balancant des mots que vous pensez prouver a quiconque que "vous savez de quoi vous parlez" .

                      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 . Évalué à 1.

                        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 ).

                        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 . Évalué à 3.

                          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).

                          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 (page perso) . Évalué à 2.

                            Le gros problème avec cette puce c'est qu'on se saura jamais véritablement ce qu'il y a dedans et ce qu'elle fait vraiment, donc comme dirait mr koff « c'est de la merde !! » :)
                            • [^] # Re: et oui les TPM ...

                              Posté par . Évalué à 2.

                              Dans cette puce il y a deux choses que l'on ne connait pas :
                              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 . Évalué à 2.

                                A part çà le reste est très simple.
                                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 . Évalué à 2.

                            Un systéme complet sans un espace accessible en écriture, sans support module, etc etc ... ce n'est pas très courant.
                            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 . Évalué à 2.

                              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.

                              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 . Évalué à 2.

                                Ben si tu as la majorite des gens qui laisse les trucs en "defaut" comme c'est le cas pour windows. Qu'ensuite s'établis un reseau dis "de confiance" ou les puce tcpa s'identifie entre elles pour rentrer dans ce reseau. Si ce réseau atteint une taille critique (ce qui est faisable vu le nombre d'utilisateurs qui laisse tout a "defaut"), ben si tcpa te bloquera , indirectement mais il te bloquera.

                                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 . Évalué à 2.

                                  Ben si tu as la majorite des gens qui laisse les trucs en "defaut" comme c'est le cas pour windows.

                                  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 . Évalué à 2.

                                    Le truc par défaut c'est :
                                    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 . Évalué à 2.

                                      si les tpm se généralise; je suis vraiment pas sur que les choix par defaut vont rester identiques.

                                      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 . Évalué à 2.

                                        Donc j'accorde ma confiance au niveau des specs.
                                        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 . Évalué à 2.

                                          Et tu accord ta confiance seulement au niveau des specs pour un logiciel?

                                          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 . Évalué à 2.

                                            Les fonctions doccumentés, par exemple en archi x86, sont très différentes du bytcode sous jacent. Que fait le bytecode ? Mystère.
                                            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 . É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...


                                              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 . Évalué à 3.

                                                dire qu'un processeur est un risc d'accord; dire que du code est du risc j'ai comme un problème.
                                                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 . Évalué à 4.

                          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 ;

                          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 (page perso) . Évalué à 2.

                            N'importe quoi. Tu es de mauvaise foi car on a déja parlé ensemble de booter sur un medium read-only sur lequel est tripwire qui va vérifier l'intégrité de l'OS avant de le booter. C'est faisable maintenant, facilement et sans puce TCPA.
                            • [^] # Re: et oui les TPM ... intégrité au boot sans tcpa

                              Posté par . Évalué à 2.

                              Et que l'OS soit read-only l'empêche d'être compromis ?
                              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 . Évalué à 2.

                                dans ce cas tcpa peut etre compromis avant d'aller a la fonderie.
                                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 (page perso) . Évalué à 2.

                                  D'autant plus que TCPA ne sert à rien sans OS et que par conséquent il faut avoir confiance dans TCPA et et dans l'OS.
                                  Sa mauvaise foi est de plus en plus évidente.
                                • [^] # Re: et oui les TPM ... intégrité au boot sans tcpa

                                  Posté par . Évalué à 2.

                                  dans ce cas tcpa peut etre compromis avant d'aller a la fonderie.

                                  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 . Évalué à 2.

                                    si la puce est compromise ; tcpa peut donc laisser passer un os compromis comme etant "sur" non?
                                    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 . Évalué à 2.

                                      Pour faire court. Un tripewire compromis peut compromettre l'OS, un OS compromis peut compromettre tripewire.
                                      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 (page perso) . Évalué à 2.

                                        un OS compromis ne peut pas compromettre TCPA.
                                        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 . Évalué à 2.

                                          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.

                                          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 (page perso) . É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 . Évalué à 4.

                                              Le paiper dont tu donnes le lien. http://66.102.9.104/search?q=cache:hMRNHAVJ3BwJ:byte.csc.lsu.edu/~d(...)
                                              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 (page perso) . Évalué à 2.

                                                Bref TCPA a inventé une IA très puissante capable de détecter tous les failles d'un OS. Bravo !

                                                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 . Évalué à 5.

                    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.

                    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 (page perso) . Évalué à 2.

                RSA

                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 . Évalué à 4.

        Ca a l'air intéressant. T'as un peu de howtos/doc la dessus ?
        • [^] # Re: et oui les TPM ...

          Posté par . Évalué à 3.

          Différence entre TCPA et Palladium, tenant et aboutissant des deux technologie:

          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 (page perso) . Évalué à 2.

            Le truc important en matière de haute sécurité est d'avoir un OS fiable, le reste (y compris TCG/TCPA/TPM) c'est souvent du marketing quand ce n'est pas pire.

            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 . Évalué à 2.

              Je suis bien d'accord sur le fait qu'un systéme fiable ( et non pas seulement l'OS ) constitue l'essentiel, rien ne sert de crypter ses communications avec des clés énormes si son systéme est une vrais passoire.
              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 (page perso) . Évalué à 1.

                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
                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 . Évalué à 1.

                  La seule vraie nouveauté de TCPA est le remote attestation.
                  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 (page perso) . Évalué à 4.

                    Et l'analyse métrique du système
                    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 . Évalué à 3.

                      Tout dans TCPA tend vers le remote attestation.

                      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 (page perso) . Évalué à 2.

                        Encore une fois les nombreux documents que j'ai cité, et que tu n'as pas pu contesté, disent clairement le contraire.

                        "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 . Évalué à 2.

                          C'est clair et net !

                          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 (page perso) . Évalué à 1.

                            "The TCPA system reports the metrics and lets the challenger make the final decision regarding the trustworthiness of the remote platform."
                            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 (page perso) . Évalué à 2.

                              Le raisonement est pourtant simple: le provider va exiger que les metrics se réduisent exacetemnt au bootloader d'un OS DRM. Ce PCR sera toujours le meme si le bootloader n'a pas été modifié par l'utilisateur. Et ce bootloader se chargera lui de vérifier l'intégrité de l'OS DRM avant de le booter.
  • # +

    Posté par . Évalué à 6.

    - 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
    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 . Évalué à 6.

      Ca a l'air normal, d'apres http://lwn.net/Articles/121845/(...)
      • [^] # Re: +

        Posté par . Évalué à 2.

        oui, je m'en suis rendu compte. C'est la description dans la depeche qui m'a induit en erreur.

        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 . Évalué à 2.

          > C'est la description dans la depeche qui m'a induit en erreur.

          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 . Évalué à 4.

            > 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à.


            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 . Évalué à 2.

              > Si tu arrives à exploiter une faille pour modifier un de ces pointeurs,
              > 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 . Évalué à 2.

              Comment ca se passe avec les processeurs qui ne sont pas NX-bit ?
              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 (page perso) . Évalué à 2.

    Avant, avec le kernel 2.6.10 j'avais mes périphériques sous la forme /dev/uba1 /dev/ubb1 etc... ça utilisait le module ub

    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 . Évalué à 2.

      Tu as fait make oldconfig pour passer du 2.6.10 au 2.6.12 ?
      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 (page perso) . Évalué à 6.

      Ce driver s'appelle très précisement "Low Performance USB Block driver" et est décrit comme ne supportant pas tous les périphériques.
      Je ne suis pas sur que l'utiliser, surtout pour des raisons esthétiques, soit une bonne idée.
      • [^] # Re: USB ?

        Posté par . Évalué à 4.

        oui, il sert surtout pour les systemes embarques qui ne veullent pas activer le support du scsi.

        Pour les autres configs usb_storage est conseillé...
  • # marre de configurer votre noyau ?

    Posté par . Évalué à 10.

    Vous en avez marre de configurer votre noyau ? Vous n'y arrivez pas ? le noyau de votre distribution ne vous plait pas ? une seule solution

    make randconfig
  • # Et la taille des stacks ?

    Posté par (page perso) . Évalué à 2.

    J'ai pense que j'ai raté un épisode, mais dans le 2.6.11.9 (le dernier que j'avais) je pouvais encore choisir entre des stacks de 4K ou 8K, et dans le menuconfig du 2.6.12 je n'ai pas trouvé où ça se configurait.

    Ça a disparu ? Quelle est la taille par défaut dans ce cas ? Merci !
    • [^] # Re: Et la taille des stacks ?

      Posté par . Évalué à 5.

      C'est planqué dans "Kernel Hacking", en activant "Kernel debugging". Je suppose que par défaut c'est donc 8K, vu que l'option c'est "CONFIG_4KSTACKS" et qu'elle est désactivée.

      (astuce : retrouvé dans "make menuconfig" en tapant "/ 4k entrée")
  • # Jamais de vacances !

    Posté par (page perso) . Évalué à 5.

    C'est deja parti pour le 2.6.13 :


    [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 (page perso) . Évalué à 1.

    réseaux (TG3 surtout), sur DVB, le hotplug,

    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 . Évalué à 2.

      Est-ce que DVB veut dire tele numerique ?

      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 (page perso) . Évalué à 1.

        Donc ca veut bien dire tele numerique. Je voulais etre sur de savoir si c'etait le meme DVB.

        Ma carte c'est une carte PCMCIA Moditel de Technisat. Et aux dernieres nouvelles, ca marche pas.
  • # ACPI ASUS M6000 ?

    Posté par . Évalué à 0.

    bonjour,

    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 . Évalué à 10.

    Wow... c'était quoi le sujet de l'article au début ? TCPA is DRM or not ?

    Ah non, la sortie du nouveau noyau linux... Ok...
    >=====> []
    • [^] # Re: Mal à la tête

      Posté par . Évalué à 9.

      ouai surtout que 3 ou 4 personnes doivent totaliser plus d'une 100ème de commentaires.
      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 . Évalué à 1.

        t'es ouf toi.
        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 . Évalué à 2.

    C'est moi ou y a pas de patches pour passer du 2.6.11.12 au 2.6.12 ?
    • [^] # Re: Patches

      Posté par (page perso) . Évalué à 5.

      Seulement pour passer du 2.6.11 au 2.6.12 ... oui, c'est pas terrible... un effet pervers de la nouvelle numérotation.
  • # mettez à jour votre udev !

    Posté par . Évalué à 7.

    Il y a pas mal d'utilisateurs de Slackware 10 qui ont rapporté sur la LKML qu'ils ne peuvent pas booter avec ce noyau. Celà vient du fait qu'à partir du 2.6.12-rc4, il faut utiliser une version récente de udev (058+):

    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 à ceux qui les ont postés. Nous n'en sommes pas responsables.