Journal Prise en compte de la vie privée dans les protocoles réseaux

Posté par (page perso) . Licence CC by-sa
24
25
juil.
2013

Aujourd'hui, surtout en plein scandale PRISM, la vie privée est un sujet important et pris au sérieux. Mais, historiquement, la plupart des protocoles de la famille TCP/IP, à la base de l'Internet, ont été conçus sans tenir compte des questions de vie privée et certains de ces protocoles sont donc excessivement iniscrets. L'IETF tente de changer la tendance et d'améliorer les choses pour les futurs protocoles.

C'est ce que propose le tout nouveau RFC 6973 "Privacy Considerations for Internet Protocols". Plein d’intéressants exemples et discussions, je crois que c'est une bonne lecture pour les ingénieurs et étudiants en réseaux informatiques.

Le RFC : http://www.rfc-editor.org/rfc/rfc6973.txt

Mon résumé en français : http://www.bortzmeyer.org/6973.html

  • # "Code is law"

    Posté par . Évalué à 3.

    C'est intéressant de rapprocher cette expression

    « bof, c'est de la politique, ça ne nous concerne pas, et d'ailleurs la technique est neutre »

    A celle de Lawrence Lessig : "Code is law".

    "La première sécurité est la liberté"

  • # protocoles

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

    Pour moi, les protocoles, c'est une chose importante, soit. Mais dans le cadre de PRISM, leur securisation n'a aucune importance ou presque puisque la NSA est branchée directement chez le fournisseur du service.
    Le vrai probleme avec PRISM est : quelles garanties sur nos données pouvons nous avoir des services online ? Quelles garanties pouvons nous avoir d'un service online hebergé aux USA ?
    Et meme si le service online garantit un cryptage des données (comme Dropbox ou Apple iCloud par exemple), comment pouvons nous être sur que c'est bien le cas ET que nous sommes vraiment les seuls a accéder a nos données ? Que peut mettre en place un service online pour nous donner la possibilité de verifier ? Quels sont les criteres qui me permettrait d'etre sur que je suis le seul a acceder a mes données ?

    Ensuite effectivement, il y a la problematique des protocoles mais je pense que meme si c'est loin d'etre parfait, il y a deja pas mal de matiere sur le sujet.

    • [^] # Re: protocoles

      Posté par . Évalué à 1.

      A coté de prism, il semble y avoir un paquet de connexions sur les points d’interconnexion ou sur les câbles sous-marins. PRISM n'est pas le seul problème.

      Concernant le cryptage dans le cloud, il suffit que la clef ne soit jamais dans les mains du fournisseur, et donc de crypter soi-même.

      "La première sécurité est la liberté"

      • [^] # Re: protocoles

        Posté par (page perso) . Évalué à 1. Dernière modification le 25/07/13 à 10:35.

        Ouais mais il me semble que tu parles juste d'un bete stockage sur disque comme un Dropbox par exemple. Effectivement, dans ce cas, c'est tout a fait possible de gerer soi meme le cryptage mais comment faire dans le cadre de services comme facebook, flickr, etc qui sont un peu plus qu'un bete stockage ?

        Ou alors il faudrait pondre des protocoles applicatifs qui garantissent la securité des données jusqu'au niveau du stockage (en base) ainsi le fournisseur du service pourrait mettre en place un service mais seulement en manipulant des données securisées auxquelles il n'a aucun acces.
        Mais je ne sais pas si y'a des travaux de genre qui existent ni meme ca pourrait etre techniquement envisageable…

        • [^] # Re: protocoles

          Posté par . Évalué à 0.

          A moins d'avancé majeurs des les fonctions de manipulations de donnés crypté, c'est la loi qui fera le ménage.

          Il faut le consentement des personnes pour revendre leur données, c'est le minimum. L'Europe est en pleine discussion actuellement sur le sujet.

          "La première sécurité est la liberté"

        • [^] # Ayant-droits ?!

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

          En gros, tu viens de comprendre le style de problématique des ayants-droits, pour la musique par exemple…

          C'est ça que je trouve amusant (quoique), sur ce sujet, au final. On a le même problème qu'eux : Garantir que l'on fait ce qu'on veux bien avec nos données. Même (surtout) si elle sont dans la nature…

          • [^] # Re: Ayant-droits ?!

            Posté par . Évalué à 1.

            Cela n'a rien avoir. Les ayants droit ont vendu leur support. Nous n'avons rien vendu du tout.

            "La première sécurité est la liberté"

            • [^] # Re: Ayant-droits ?!

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

              Je ne vois pas en quoi la vente ou non intervient dans la question. Ou alors tu parle du fait que, comme t'as payé la musique, tu ne veux pas de limite dessus. Je suis d'accord sur ce point. D'ailleurs, dans la remarque, je pensait plus à la musique piratée qu'à la musique achetée.
              A partir de là, on glisse vers le débat "Es-ce une bonne idée de pouvoir contrôler des données diffusées après diffusion ?". Ça dépends : Pour les photos personnelles tu va dire oui, pour la musique achetée, non, pour un code source libre, non. La maison de disque qui voit de la musique copiée, le gros éditeur de logiciel qui rachète la start-up, ne sont pas forcement du même avis. Et si en plus il faut faire le distinguo entre la musique acquise légalement ou pas…
              J'ai bien peur, qu'en dehors du problème technique, on a un problème philosophique qui pointe le bon de son nez.

      • [^] # Re: protocoles

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

        Le "il suffit" est trop court. Il faut aussi être sûr du logiciel, donc, au minimum, logiciel libre, sinon, aucune sécurité.

        • [^] # Re: protocoles

          Posté par . Évalué à -7.

          et il vaut mieux être sûr du matériel…

          Idéalement, des machines dites de confiance - du point de vue de l'utilisateur (!) - sont constituées de matériel libre :

          • spécifications sous licence libre, auditées ;
          • fabriquées sous surveillance (par ex. par un industriel acceptant une mise sous surveillance - largement automatisable - de la production, financement par souscription) ;
          • distribuées sous surveillance (avec un contrôle explicite pendant la livraison, jusqu’à un point de diffusion qui peut avoir vocation à éliminer le lien informationnel entre l’objet matériel et celui qui en prend possession, pour éviter une malveillance ciblée).

          Ceci pour rappeler que le seul code libre ne suffit pas, in fine, à garantir que les instructions exécutées par le matériel soient conformes au code logiciel, car une malveillance au niveau matériel peut ouvrir des portes dérobées (intrusion invisible d’un tiers par le réseau), voire permettre l’exécution de code invisible même pour le système d’exploitation libre…

          Pour les débutants, pour comprendre rapidement le potentiel de malveillance au niveau matériel : on peut considérer le concept de la virtualisation de système d’exploitation, appliqué au niveau de la "logique cablée" (logique figée dans le processeur) : un processeur malveillant - non conforme aux spécifications publiques - pourrait comporter un mode de fonctionnement où il présente un contexte normalisé pour le système d’exploitation, en ayant virtualisé ce contexte, c’est à dire en exécutant - en secret - un système d’exploitation hôte qui a tout pouvoir d’observation et d’intervention sur les systèmes invités. Il y a d’autres façon plus basiques d’opérer une malveillance au niveau matériel (comme lire la mémoire RAM depuis une carte réseau malveillante, via le bus de données (mode "DMA" (direct memory access)). J'avais publié un journal, fin 2010, titré "code malveillant / vérification des trames émises sur le port Ethernet".

          Pour info, le texte ci-dessus est grosso-modo une reformulation de mon point de vue, déjà exprimé ici.

          J'ai proposé des prémices de réflexion sur un matériel libre répondant à des critères de certification à la fin de ce journal (à la fin du journal, repris très succinctement dans quelques commentaires).

          Je travaille sur différentes alternatives de reprise du contrôle communautaire sur du matériel libre certifié - notamment par des discussions avec des physiciens -, je compte en faire un journal bientôt.

          • [^] # Re: protocoles

            Posté par . Évalué à -10. Dernière modification le 27/07/13 à 10:56.

            Note de -6 et pourtant… Ce que j'exprime ci-dessus est pertinent.

            Je vous invite à voir cette petite conférence en français, de Frédéric Jouvin (aka Stman) : « Free, Secure & Open Microprocessor Project » - Présentation d'un projet visant à la création collaborative d'un micro-processeur libre, gratuit, évolutif, et surtout ultra sécurisé (PMMU d'un nouveau genre) et orienté cryptographie, sur FPGA, avec son compilateur GCC modifié associé.

            A ce stade, j'observe les données suivantes :

            Date de création : samedi, 22 juin 2013, 16:41
            Nombre de vues : 116
            Licence : CC BY NC SA

            Vous remarquerez le faible nombre de vues. Je dis que ça gagnerait à être écouté.

            Frédéric Jouvin propose la voie du FPGA, c'est une des voies possibles. Sans maitrise de la fabrication du FPGA et de sa livraison, la malveillance peut s'établir au sein des circuits et dans la substitution pendant la livraison… Pour avoir un peu réfléchi à la question, je considère qu'une malveillance matérielle dans un FPGA est théoriquement concevable mais bien plus difficile à mettre en oeuvre que dans un microP traditionnel (et sans doute plus limitée dans la capacité de contrôle), puisque l'architecture des portes logiques programmable du FPGA est par définition modifiable. La malveillance peut prendre place dans un équivalent fonctionnel d'un routeur malveillant (en entrée/sortie du FPGA), ou plus profondément dans le FPGA : à chaque porte logique peuvent être associées des cellules mémoires non documentées et une logique cablée, permettant de lire l'état du FPGA, d'assurer des traitements automatisés pour modifier son comportement…

            La possibilité de malveillance ainsi décrite se modélise assez facilement en blocs fonctionnels.

            Il faut considérer que la pertinence d'une action malveillante est fonction de l'intelligence déployée à partir du jeu de données recueilli. Cette intelligence, inscrite dans un logiciel ou une logique cablée, peut soit être embarquée dans le circuit cible, soit être mise en oeuvre à distance, nécessitant une communication (débit ? latence ?).

            Edit : la note du présent commentaire commence à -5, du fait du "karma" (au sens linuxfr) accumulé sur quelques posts précédents ainsi que ce journal.

            • [^] # Re: protocoles

              Posté par . Évalué à -10.

              pour discréditer l'opération de discrédit qui se poursuit (à travers un "moinssage" ciblé, quasi systématique), je vais rappeler cette donnée, qui n'est pas sans intérêt pour mesurer la pertinence de mes propos : je suis électronicien de formation.

            • [^] # Re: protocoles

              Posté par . Évalué à -10.

              à chaque porte logique peuvent être associées des cellules mémoires non documentées et une logique cablée, permettant de lire l'état du FPGA, d'assurer des traitements automatisés pour modifier son comportement

              Je précise ainsi : lire l'état du FPGA d'une part et assurer des traitements automatisés pour modifier son comportement d'autre part, dans cette perspective, sont le fait d'un fonctionnement malveillant et masqué, à l'insu du code légitime (le code qui a initialisé la configuration du FPGA ainsi que le code s'exécutant sur le FPGA initialisé).

    • [^] # Re: protocoles

      Posté par . Évalué à 2.

      Dans PRISM, il y a également la question de la surveillance de masse. Est-il bon qu'une entité puisse pratiquer un espionnage massif d'internet, même uniquement sur les données publique ?

      Là on touche aux questions fondamentales du contrôle d'internet, de sa décentralisation.

    • [^] # Re: protocoles

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

      Oui, j'ai peut-être eu tort de mentionner PRISM, c'était pour attirer l'attention mais, en effet, techniquement, c'est un problème différent.

      Par contre, c'est tout à fait faux de dire qu'il y a déjà "pas mal de matière sur le sujet [les protocoles]" ou alors il faut citer des références. Pour le DNS, par exemple, je n'ai jamais rien vu.

      Enfin, "cryptage" n'est pas le bon mot http://www.bortzmeyer.org/cryptage-n-existe-pas.html

      • [^] # Re: protocoles

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

        Les "grands" protocoles comme HTTP, FTP, SMTP, POP, XMMP, etc ont leur declinaison securisée par du SSL/TLS. Je crois savoir que DNSSEC existe mais je ne sais presque rien a son sujet ni meme si il est deployé a large echelle.
        De meme, d'apres ce que je sais, IPv6 dispose de fonctionnalités de securisation tres avancees…

        • [^] # Re: protocoles

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

          Et en quoi est-ce que TLS va protéger la vie privée ? Il y aura la requête DNS, les adresses IP utilisées et même (cf. mon article, qui notait ce point du RFC) le fait que cette machine s'était déjà connectée… Bref, TLS ne protège que le contenu, ce qui est déjà pas mal mais n'est pas le sujet du RFC, qui se focalise sur les méta-données, bien plus dures à protéger.

          DNSSEC garantit l'authenticité des requêtes, mais ne fait rien pour la confidentialité.

          Quant à IPv6, non, il a pile la même sécurité qu'IPv4 http://www.bortzmeyer.org/ipv6-securite.html

          • [^] # Re: protocoles

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

            oui oui j'ai bien compris. C'est pour ca que je dis "meme si c'est loin d'etre parfait, il y a deja pas mal de matiere sur le sujet".

            Pour IPv6, je croyais qu'une déclinaison d'IPsec était intégrée au protocole. Visiblement, je me trompe. Et idem, ca ne resout pas le probleme soulevé par la RFC en question ni le problème de la "collaboration" des services avec les agences indiscrètes.

            Après, j'ai du mal a imaginer comment pouvoir proteger les informations de destination au moins. Meme sur un courrier le plus sensible au monde, il faut bien indiquer en clair le destinataire…

            • [^] # Re: protocoles

              Posté par . Évalué à 2.

              Pour IPv6, je croyais qu'une déclinaison d'IPsec était intégrée au protocole. Visiblement, je me trompe.

              Je crois que ça a été le cas puis après c'est devenu optionnel, pas vraiment surprenant: les agences de sécurité du monde entier n'aime pas le chiffrage par défaut: ça rend leur travail plus compliqué.

              Après, j'ai du mal a imaginer comment pouvoir proteger les informations de destination au moins. Meme sur un courrier le plus sensible au monde, il faut bien indiquer en clair le destinataire…

              Non, tu peux "cacher" le message dans un fichier a large diffusion (stéganographie) mais bon
              1) il reste le problème de l'échange des clefs
              2) ce n'est pas efficace 1) il faut que ton message représente un petit pourcentage du fichier autrement ça va se voir.
              3) ce n'est pas efficace 2) on voit mal des millions d'utilisateurs utiliser ce mécanisme comme ça se passe pour l'email.

  • # Protocole indiscret ?

    Posté par . Évalué à 4.

    J'ai un peu de mal à saisir le concept de "protocole indiscret" :

    • Oui, le serveur de destination peut être compromis.
    • Oui, quelqu'un peut écouter sur un élément de réseau intermédiaire.
    • Par contre, dire qu'un protocole est un élément à risque car il « contient » nos données, je trouve ça un peu gros, car c'est quand même son rôle. Ou encore que les paquets contiennent des informations concernant la provenance/destination des données : pour envoyer un paquet d'un point A à un point B, le protocole aura forcément besoin de savoir comment joindre B. Idem si tu écris une lettre, il faut à un moment ou un autre mettre l'adresse du destinataire. Ou alors tu choisis de ne pas dépendre du protocole LaPoste et délivres ta lettre toi même, mais là encore, il suffit de te suivre pour obtenir l'adresse de ton destinataire.

    Sinon, quand je lis :

    Pour déjouer sérieusement la surveillance, il faudrait des protocoles avec des tailles de paquets variables, n'ayant pas de chaîne de bits prévisibles à un endroit fixe dans le paquet, etc.

    et :

    Les protocoles devraient être conçues de façon à ne transmettre que les données strictement nécessaires à l'accomplissemnt de la tâche.

    je me dis que cela va devenir compliqué…

    • [^] # Re: Protocole indiscret ?

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

      Un exemple est fourni par IP lui-même. Le mode non-connecté fait qu'il faut mettre l'adresse IP source dans chaque paquet (il faut bien que les réponses et les avis de non-remise soient transmis). Donc, le destinataire connait l'adresse IP source. Ce n'était pas obligatoire. X.25 avait un autre système où le réseau établissait la connexion et où le destinataire ne connaissait pas forcément le numéro de l'appelant (merci à Rémi Desprès pour ses explications à ce sujet).

      Mon but n'est pas de dire qu'il faut revenir à X.25 :-) simplement de montrer qu'il y a eu des choix, qu'ils n'étaient pas obligatoires (« une autre technique est possible ») et que ces choix ont des conséquences pour la vie privée. C'est le thème principal de ce RFC : un protocole n'est pas purement technique.

      Autre exemple, le DNS : le résolveur transmet au serveur faisant autorité la totalité de la requête, pas juste le domaine pour lequel le dit serveur fait autorité. Le serveur de la racine sait ainsi qu'on regarde linuxfr.org. Il y a des bonnes raisons pour cela (le problème est en effet complexe, ici, la bonne raison, c'est le fait que le résolveur ne connaisse pas les "zone cuts") mais d'autres protocols faisaient différemment.

      • [^] # Re: Protocole indiscret ?

        Posté par . Évalué à 2.

        Oui, mais si j'ai bien compris, comme de toute façon on ne peut pas faire confiance au réseau qui peut être écouté, quand bien on peut avoir un protocole avec lequel le destinataire ne connait pas l'adresse de l'appelant, un mec bien placé qui écoute la communication peut avoir l'info qu'il faut. Alors certes, le problème n'est peut-être pas forcément le même, l'info n'est pas récupérée par la même personne (destinataire vs. écoutant), mais au final ça change rien au problème de respect de la vie privée…

        • [^] # Re: Protocole indiscret ?

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

          Sauf si tu chiffre. Dans le cas d'HTTPS par exemple, l'écoutant ne sait rien de la conversation mais le destinataire, oui.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: Protocole indiscret ?

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

            Mais si, l'écoutant sait des choses, même avec TLS, comme le fait qu'il y a une communication, combien d'octets sont échangés et même (avec la reprise de session) si ce client était déjà passé.

            Le RFC se focalise sur la discrétion des protocoles. La question de la protection du contenu est déjà bien connue, celle des protocoles semble avoir été pas mal négligée.

            • [^] # Re: Protocole indiscret ?

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

              Mais si, l'écoutant sait des choses, même avec TLS, comme le fait qu'il y a une communication, combien d'octets sont échangés et même (avec la reprise de session) si ce client était déjà passé.

              Évidemment, ce que je voulais dire, c'est qu'il y a moyen de protéger le message de l'écoutant (mais pas les métadata).

              « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

    • [^] # Re: Protocole indiscret ?

      Posté par . Évalué à -7.

      les paquets contiennent des informations concernant la provenance/destination des données : pour envoyer un paquet d'un point A à un point B, le protocole aura forcément besoin de savoir comment joindre B.

      Avec RetroShare tu obtiens des fonctions de masquage des expéditeurs et destinataires pour les intermédiaires techniques, dans certains cas d'usage du logiciel. J'ai présenté Retroshare et OneSwarm vite fait ici : « RETROSHARE (disponible sous Win/Linux/MacOS) permet d'obtenir un réseau de type a-centré (dit F2F pour "Friend to Friend") où la sécurité est basée sur un échange de clés GPG. Avec lui, on peut tchater, échanger des fichiers, il y a même un système de forum et un système de mail. » (… + des liens cités)

      En fouillant sur le wiki de Korben, je tire ces infos :

      • Au paragraphe "Sécurité" :

      « Le transfert de fichier est anonyme, et assorti de mesures permettant de masquer la profondeur réelle des tunnels utilises pour un transfert donne, avec un biais indépendant de la route choisie. »

      • Au paragraphe "Caractéristiques techniques" :

      « transfert de fichier multi-hop et multi-sources avec swarming (les transferts partiels sont eux mêmes des sources potentielles). Les transferts étant anonymes au delà des amis directs. »

      • Au paragraphe "Fonctionnalités" :

      « Anonymat : la source des données ignore qui en est le destinataire réel tandis que le destinataire des données ignore qui en est la source réelle. »

      • [^] # Re: Protocole indiscret ?

        Posté par . Évalué à -9. Dernière modification le 27/07/13 à 14:22.

        J'ai oublié de glisser un paragraphe introductif, dans mon propos : RetroShare n'est pas un protocole, mais cette application illustre la possibilité d'implémenter des formes d'anonymat dans la communication.

        L'objet de mon commentaire était de souligner qu'il est ainsi possible de ramener ces fonctions au niveau du protocole.

        Dans le domaine de l'identification des utilisateurs et de la localisation des machines fournissant un/des service(s), c'est un peu la démarche proposée dans le journal "Présentation d'idée : PGPID" où il est question de s'inspirer de Retroshare pour généraliser les deux principes pré-cités dans une couche normalisée et utilisable par un ensemble de service, soit un concept assez proche du protocole.

        note : ce commentaire commence à -5…

    • [^] # Re: Protocole indiscret ?

      Posté par . Évalué à 2.

      Ou encore que les paquets contiennent des informations concernant la provenance/destination des données : pour envoyer un paquet d'un point A à un point B, le protocole aura forcément besoin de savoir comment joindre B. Idem si tu écris une lettre, il faut à un moment ou un autre mettre l'adresse du destinataire.

      Un contre-exemple justement à propos du courriel a déjà été présenté ici-même.

      Par contre, il illustre qu’envoyer quelque chose à un destinataire sans indiquer comment le joindre (et sans serveur centralisé) est plus compliqué…

      Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

      • [^] # Re: Protocole indiscret ?

        Posté par . Évalué à 2. Dernière modification le 25/07/13 à 13:13.

        Si mes souvenirs sont bons, Bitmessage c'est : « on broadcast (à un groupe), et décode celui qui peut » ?

        En effet, c'est une solution pour certains points évoqués.

        Cependant, en mettant de coté l'aspect chiffrement sur lequel repose Bitmessage, si la solution au respect de la vie privée est le broadcast, il y a pour moi comme un problème conceptuel…

        • [^] # Oui, mais que faire ?

          Posté par . Évalué à 5.

          D’un autre côté, il n’y a pas 36 possibilités.

          – Tu communiques directement avec le destinataire. Ton FAI, donc Thalès (bientôt) et les barbouzes du gouvernement (déjà) sont au courant de votre relation.

          – Tu utilises un service centralisé. L’opérateur du service, donc les barbouzes US (typiquement, pour un service situé aux États-Unis) sont au courant (voire les entreprises US si le renseignement a un intérêt commercial).

          – Tu l’envoies « dans la nature ». Il est beaucoup plus difficile de déterminer qui est le destinataire prévu, mais quant au contenu, tu ne peux qu’espérer que ton chiffrement tienne (au moins jusqu’à ce que le contenu n’ait plus d’intérêt)…

          – Tu utilises une infrastructure d’anonymisation non triviale, comme Tor. Problème : Tormail ne répond pas aujourd’hui. Problème supplémentaire : certains opérateurs Tor peuvent ne pas être bien intentionnés (pirates, barbouzes), donc là encore, tu as intérêt en ce qui concerne le contenu à ce que ton chiffrement tienne…

          Évidemment, si l’on considère la situation actuelle, protéger le contenu des regards indiscrets serait déjà un grand pas (même sans cacher les relations).

          Théorie du pot-au-feu : « Tout milieu où existe une notion de hauteur (notamment les milieux économique, politique, professionnels) se comporte comme un pot-au-feu : les mauvaises graisses remontent. »

  • # Je pige pas là..

    Posté par . Évalué à -4.

    Depuis quand c'est aux protocoles et non pas aux applications de faire attention aux données qui transitent ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.