La première fonctionnalité est une politique de sécurité dont la mise en oeuvre est décidée par le titulaire de l’accès. Ce que demande ici HADOPI est ni plus ni moins un controle d’accès discretionnaire (DAC). De plus, rien d’orginial pour une politique de sécurité, elle doit être souple et avoir une granualité fine. Le logiciel se base sur cette politique pour observer (sans enregistrer) les flux et prendre la décision de bloquer ou non ces flux. Ce système est clairement un système de filtrage des flux orienté politique  orienté réseau. Il est demandé qu’il soit aussi bien orienté l’utilisation de listes (blanches, noires, grises) que de l’analyse du traffic (tres orienté analyse de flux et même plus loin DPI).

Ensuite, le logiciel doit être capable d’analyser la configuration du postes, des logiciels, du reseau de manière statique. On peut donc imaginer qu’il va vérifier que vous avez bien défini une clef sécurisé WEP (oui oui WEP c’est sécurisé d’après HADOPI…). Mais là où ca devient fort c’est quand il demande une analyse dynamique des logiciels en fonctionnement soit une analyse dynamique du système ou de l’application. C’est bien beau ça mais tout d’abord pour quoi faire (ça on le fera plus tard) et ils connaissent la difficulté d’avoir un tel dispositif fonctionnant sur un système réel ? Je suis bien placé pour en parler, la mise en place de contrôle d’accès dynamique sur un système pour protéger contre les flux illégaux, c’est le sujet de ma thèse.

Après on a le droit à la killer feature qui va bien avec le DAC, c’est à dire si le logiciel détecte quelque chose d’illégal, il l’annonce à l’utilisateur.

Finalement, de manière générale, la dernière fonctionnalité est la mise en place d’un système de journalisation contenant une version en clair et une version sécurisé qui contient ce qu’a fait le logiciel de sécurisation mais aussi ce qu’il a détecté et ce que l’utilisateur a décidé de faire. Bien sur, le journal sécurisé doit etre confidentielle, authenthique et infalsifiable. En gros, seul HADOPI et l’utilisateur sont senser pouvoir le lire. D’un point de vue sécurité, la fonctionnalité doit donc garantir l’intégrité, la confidentialité et la non répudiation.

Après ca devient fort quand ils demandent que le logiciel puisse lutter contre l’usurpation, le contournement ou l’altération. Mais aussi que toute la structure du logiciel lui meme soit sécurisé .Ensuite, on a le droit au fonctionnalité classique de mise à jour, de faible impact des performances, de désinstallation. On notera que le logiciel peut être fait (ou peut tourner) sur des logiciels libres, c’est gentil de leur part non ? Mais bon vu qu’il faut qu’en même faire plaisir au gros éditeurs, HADOPI précise que le logiciel peut être ajouté dans des suites de sécurité. Quand on voit l’efficacité de ces suites comme les antivirus, ça fait peur…

Comme il a déjà été, le logiciel peut être installé aussi bien sur le PC (ou console ou téléphone, etc) que sur la passerelle, c’est à dire la box en ce moment en France. Mais comme la box est très fermée, peu puissante et renouvellé rarement cette fois n’est que exploratoire. Dans le cadre des grands entreprises, des sondes DPI peuvent également être proposé.

La politique de sécurité doit être générique et universelle. Le logiciel doit être capable d’analyser sans trop de coût un traffic allant jusqu’à 100Mb/s. La modification des listes est possible par l’utilisateur mais ces modifications sont journalisées. Clairement le coeur du système est  l’analyse dynamique des flux réseaux qui sent tres fort le DPI. Mais pour autant, il n’analyse pas le contenu des flux car pour le moment d’après e document ce n’est pas possible d’analyser les attributs de données pour détecter si le flux contient un DRM ou si il est un fichier légal. Ce passage est l’un des meilleurs car il fait directement allusion à un des brevets déposé par Pr. Riguidel qui est justement la personne responsable de ce document. Ils ont même penser aux flux chiffrés en disant que même si ce n’est pas possible de faire une analyse de ces protocoles, une analyse statistique est toujours possible.

Le document explique bien que le logiciel sera pas capable de faire la différence entre un téléchargement P2P d’un ISO Linux et celui d’un film sous copyright. Il doit détecter les piles protocolaires. Par exemple, tout streaming en dehors des sites reconnus comme sur, pourrait être considerer comme illégale. De manière pratique, on peut supposer que le téléchargement HTTP soit interdit sur des sites comme megaupload. Une des autres détections proposée est la détection de VPN chiffré vers des sites problèmatiques, qui a dit IPRedator ?

Le problème de ce logiciel est qu’il doit tourner sur un système controlé par l’utilisateur mais pour autant rester intégre. On a ici un problème non résoluble. En effet, pour fonctionner le logiciel doit faire confiance au système. Hors le système est controler par l’utilisateur et par conséquence ce dernier peut en modifier le comportement. Le logiciel ne pourra donc pas rester intégre. Et encore, même si l’utilisateur n’attaque pas l’intégrité du logiciel, tout virus tournant sur la machine pourra attaquer le dit logiciel. Le coeur du logiciel est d’avoir un journal infalsifiable ce qui est impossible à part en utilisant un TPM et encore j’en doute dans le cadre d’un système controlé à 100% par l’utilisateur.

Ma conclusion est que la mise en place d’un logiciel permettant de faire de l’analyse réseau sur une ligne à haut débit est tout simplement impossible d’un point de vue sécurité informatique car il mélange des concepts qui sont fondamentallement incompatibles. En effet, pour garantir le fonctionnement du logiciel et du journal, il faut faire confiance au système sous jaceant c’est à dire le système d’exploitation. Ce n’est pas possible de faire confiance à un utilisateur. L’utilisateur ayant un controle total du système d’exploitation, le système n’est donc pas de confiance et le logiciel ne peut donc pas fonctionner en restant sécurisé. On pourrait imaginer que l’utilisateur arrive à modifier les alertes à inscrire dans le journal avant qu’elle soit écrite dans ce dernier et donc éviter une détection. Aucun système ne peut protéger un logiciel sur un système d’exploitation non sur sans ajouter une couche plus basse qui est elle meme sécurisé. Par exemple, des logiciels comme Overshadow permettent une telle chose mais en faisant confiance à l’hyperviseur qui controle le système d’exploitation. Ce n’est pas une possibilité ici puisque l’hyperviseur serait également sous le control de l’utilisateur. La seule solution serait d’avoir un système d’exploitation renforcée ne permettant pas à l’utilisateur de fonctionner comme il le souhaite. Un tel système implémentant un control d’accès mandataire et resistant aux utilisateurs est tout à fait possible comme nous l’avons démontré lors du défi de sécurité de l’ANR en proposant un OS qui ne fait pas confiance à l’utilisateur et reste intégre. Mais cela va à l’encontre de la demande de politique discretionnaire car un tel système requiere un politique mandataire. Je ne parle meme pas des problèmes de performances pour l’analyse en temps réel du traffic réseau mais aussi de la protection du système d’exploitation.

Pour finir,  si on fait confiance à des sociétés d’antivirus pour ce logiciel, ca va être un belle blague… De tout façon vu les demandes et les possibilités, il est tout simplement impossible de concevoir un tel système. Tout tentative sera forcement attaquable et le pire c’est qu’au lieu de sécuriser l’utilisateur, il y a de grandes chances que ce logiciel ouvre de nouveau vecteur d’attaque comme nous l’avons vu dans le logiciel GreenDam.

A titre personnel et de recherche, je suis pressé de voir ces logiciels car même en ayant une tres bonne connaissance de l’état de l’art universitaire et industrielles de la sécurité système, je ne vois aucune solution possible qui soit réaliste ! Attendons nous donc à bien rigoler !

De plus, pour pousser les lecteurs à cliquer sur un lien, les attaquants écrivent dans un bon français (pour une fois ce n’est pas une traduction automatique) que vous êtes adminissible pour recevoir un crédit d’impôts de 180€ environ (178.8€). Et il vous demande de remplir un formulaire pour avoir le droit à cette aide.

Bien entendu, le mail ne provient pas de la DGFIP mais est un SPAM. Le lient en lui même n’est pas forcément très malin car il méne vers un site finissant en .mx (mexique) ce qui n’est pas très crédible. L’utilisateur lambda sera surement induit en erreur car le header de la page est impots.gouv.fr et quand vous cliquez sur le lien, vous êtes rediriger vers une page dont l’URL contient http://www.impots.gouv.fr/portal/dgi/public/particuliers-Remboursement ce qui semble être une URL légitime.

Le premier site en .mx semble être un site légitime en espagnole. De plus, ils n’utilisent pas un top domaine tu type foobar.mx mais foobar.com.mx ce qui permet de ne pas avoir d’entrer DNS permettant de remonter à eux. Ce site est de toute façon utilisée comme passerelle car vous êtes tout de suite rediriger vers un second sans DNS mais via une addresse IP. Le premier site pourrait donc être juste un site légitime infecté par un malware. Ce site en .com.mx est hébergée sur un serveur dédié aux USA chez abac.net

Le faux site des impôts se trouve sur un second site avec une URL cachée du style http://xxx.xxx.xxx.xxx/.site/fr/?http://www.impots.gouv.fr/portal/dgi/public/particuliers-Remboursement. Cette addresse IP semble statique et est localisé à Rio de Janerio au Brésil dans une société qui fournit des ADSL et autres solutions Internet. On peut donc supposer que ce serveur est également un serveur compromis. En regardant de plus pres, on tombe sur un serveur qui semble légitime et dédié aux sites professionnelles. En cherchant un peu, cette plage d’addresse semble utiliser pour des sites pornographiques surement garni de malwares.

De plus, les liens sur la page contrefait ne marche pas ou sont redirigé vers le vrai site des impots ce qui augmente la confusion. En regardant le code HTML de la page, on se rend compte que les responsables de cette campagne de SPAM sont surement espagnole (ou de langue espagnole) ou tout du moins qu’ils ont utilisé un utilitaire créé par une personne de langue espagnole.

Ensuite une fois le formulaire remplit l’addresse change vers http://xxx.xxx.xxx.xxx/.site/fr/D.htm?http://www.impots.gouv.fr/portal/dgi/public/particuliers-Remboursement qui semble tjs légitime. Finalement, le site principal sur l’addresse IP semble être légitime en étant un vendeur de solutions informatique mais ne l’est surement pas.

Bref une campagne de SPAM plutôt bien monter et très bien cibler avec une localisation réflechie ce qui semble être une première en France mais surement pas la dernière.

Ce papier présente une nouvelle architecture pour les systèmes d’exploitation. Tout d’abord, malgré la présence de nombreuses personnes de Microsoft Research, le système d’exploitation qui en résulte, n’est pas du tout un Windows mais un bien un nouveau système d’exploitation. Ce système n’a pas pour but d’être utilisable mais il présente une nouvelle architecture. C’est un OS d’expérimentation uniquement qui n’ira surement pas plus loin que le prototype. Néammoins, il est possible que certains principes soient ensuite utilisé dans des systèmes fonctionnels.

Le principe de cet OS est de pouvoir passer outre le problème actuel que les OS rencontrent de plus en plus: la synchronisation des coeurs dans les systèmes massivement multicoeur et l’hétérogénité du fonctionnement hardware des processeurs multi-coeurs. Par hétérogénité hardware, les auteurs veulent parler du fonctionnement différents des multicoeurs proposées par les acteurs du marché (Sun, Intel, AMD). En effet, chacun utilise un fonctionnement différent sur les communication inter-coeurs avec des controleurs de mémoire à différents niveaux.

Les OS actuelles permettant la prise en charge de coeur multiples fonctionnent en utilisant une mémoire partagée pour l’échange d’informations mais également le stockage des données. En introduisant leur architecture multikernel, les auteurs proposent une communication explicite (contrairement à celle implicite via le partage de mémoire) en utilisant un système de message. Cela leur permet d’éviter que la mémoire partagée deviennent un goulot d’étranglement. Les études récentes montrent qu’au delà de 80 coeurs, le partage de la mémoire devient critique. Le système par message doit permettre de passer outre ce problème. Il se base sur un système de type RPC et a une complexité qui est linéaire mais également largement inférieur à celle du système par mémoire partagée. Dans le cas du multikernel, chaque coeur et chaque noyau se retrouve avec un espace de mémoire dédiée et partage donc les informations par un système de message proche de celui de RPC et très compacte (64bit).

Le principe de leur architecture est un système distribué communiquant avec des messages et sans partage de mémoire. Le partage de lock ne fonctionne plus par une structure unique de donnée se situant dans la mémoire partagée mais par un lock répliqué autant de fois que de nombre de coeurs accédant à la donnée et synchroniser via des échanges de messages. Le système de message est au final relativement proche de celui des micronoyaux et tout particulièrement celui de L4.

Pour conclure, c’est un nouveau model très intéressant et qui propose une nouvelle solution pour mieux prendre en compte les machines multicoeurs. D’un point de vue de la sécurité, toutes les communications entre coeurs étant explicites, cela devrait pouvoir faciliter le travail pour détecter des fluxs d’informations illicites. En se basant sur des principes de micronoyau, on peut espérer que la sécurité amenée par ce modèle pourra également améliorer la sécurité du multikernel. C’est bien un OS à surveiller si son développement continue contrairement à la plupart des projets de recherche qui ne sont rarement développé très longtemps.

La Suéde a décidé d’aller plus loin en interdisant aux registrars (i.e. les organismes fournissant les noms de domaine) fournissant les .SE qu’ils ne peuvent pas vendre de noms de domaine contenant le mot “banque” sauf si c’est une banque officielle. Bien sur, il y a des raisons légitimes de vouloir le mot “banque” dans son nom de domaine même si on est pas une banque. Par exemple, une association de clients d’une banque ou autre.

Mais, il ne faut pas oublier que la vaste majorité des utilisations de mot banque dans un nom de domaine quand la société derrière n’est pas une banque est pour des utilisations frauduleuses et particulièrement du fishing. Est-ce que cela aura une incidence sur le phishing ? Il y a peu de chances puisque ce n’est qu’une législation local. Appliquer à un niveau international, cela pourrait peut être ralentir le phishing même si j’ai de fort doute dessus. En effet, il suffirait de prendre un nom de domaine comme oftheamerica.com puis de créer le sous domaine bank.oftheamerica.com pour passer outre la législation qui prend en compte uniquement les noms de domaines et pas les sous domaines de ces derniers.

Inspiré par Techdirt

On peut dire que Gazelle est la réponse de Microsoft à plusieurs technologies de Google qui sont rassemblée dans Google Chrome (et Google Native Code). Le but dans les deux cas n’est plus de voir le navigateur comme un gros programme d’affichage de pages mais comme un OS dédié à la navigation. Dans ce cas, le navigateur est séparé en plusieurs processus qui sont controlés par un noyau.

Le noyau comme le noyau d’un OS se charge de la communication entre les différents composants et processus mais aussi gére l’interface avec les ressources systèmes. En compartimentant les différents pages vu simultanéement i.e. avec un processus par tab, si une page plante ou est corrompu, le problème sera limité à une page et pas la totalité de celle actuellement affichée.

Cette méthode a été rendu grand public par Chrome mais d’autres browsers expérimentaux comme OP ou Tahoma proposaient déjà des structures similaires.

La différence entre Gazelle et Chrome est au niveau de la finesse de séparation entre les différents domaines Internet. Le but est toujours d’éviter au maximum que des données d’un site soit lu par un autre et la séparation jusqu’au rendu de la page est essentielle. La même chose doit être appliquée pour les plugins qui sont de plus en plus source de problèmes.

Pour conclure, Gazelle est un très beau principe qui  promet une meilleur sécurité au niveau du navigateur. Des inconnues restent comme le principe de sandboxing pour éviter qu’un processus corrompu perturbe le système ou la gestion des plugins mais leur idée est très intéressante.  Avec la montée des applications web et des données de plus en plus sensibles qu’elles traitent la sécurité du navigateur est un point essentiel et l’un des plus attaqués actuellement. Il est probable que de telles architectures tentent à se démocratiser dans les années à venir pour ce genre de logiciel.

Leur système permet tout d’abord de générer automatiquement un modèle du malware ou de la famille de malware. Ce modèle se base sur des informations très compléte du comportement du malware. Contrairement à la détection par signature, où souvent seulement un hash du malware est utilisée pour la détection ou de la détection par séquence d’appels systèmes où cette dernière doit être respecté pour que la détection fonctionne, le modèle conserve l’intégralité des informations relatives au comportement du malware et pas uniquement une partie. D’après les auteurs, cela permet d’éviter les risques de non détection quand les malwares utilisent l’obfucation ou le polymorphisme. Ils ont ensuite développer un scanneur qui permet de faire correspondre un modèle à un programme inconnu. Pour cela, il se base sur la dépendance entre des appels systèmes.

L’une des nécessités que se sont imposée les auteurs dès le début, c’est que leur système ne devait pas incorporer de connaissances au début mais plutôt les développer au fur et à mesure. En effet, il devient tellement simple de générer des nouveaux malwares que toute connaissance preliminaire est caduc très rapidement. Bien entendu, les auteurs ne peuvent qu’admettre que dans ce cas, il faut qu’un malware soit analysé au moins une fois pour que son modèle soit généré et détecté par la suite. Il faut donc que le malware soit détecté par un tier, puis analyser par le système de génération de modèle pour pouvoir servir à la détection. Les auteurs précisent que ce n’est pas nécessaire pour chaque malware et chaque déclinaison de celui-ci grâce à leur modèle qui permet d’avoir des informations précises.

Afin d’améliorer leur système, leur analyse se base sur l’analyse d’un sous ensemble qualifié d’intéressant de syscall qui pourraient réellement aider à la détection de malware. Une fois les syscall collectés, ils les utilisent pour créer un graphe orienté qui va lié deux noeuds i.e. deux syscalls si les données générées par le premier sont utilisées en entrée par le second.

Leur système fonctionne plutôt bien quand il s’agit de détecter des malwares et des variantes de ces derniers qu’il a déjà analysé. D’après les tests fournis par les auteurs, le taux de détection est de 90% avec un taux nul de faux positif. Mais dès qu’il s’agit d’analyser des variantes inconnus le taux de détection chute à seulement 25%. Leur système se basant sur des modifications du système pour pouvoir monitorer, analyser et bloquer des programmes au niveau noyau, un driver ainsi qu’un certain nombre de programme ont été développé. L’overhead est relativement faible 10% pour ce qui est du CPU mais il monte rapidement pour les entrées/sorties et 40% pour des tâches complexes comme une compilation.

Pour conclure, leur système est intéressant car il permet effectivement une bonne détection de comportement des malwares en se basant sur l’observation des liens entre syscalls. La méthode permet donc d’éviter les problèmes d’obfuscation, de polymorphisme mais aussi de changement d’ordre des syscalls. Par contre, leur méthode ne détecte que péniblement les variantes d’un malware déjà connu et ne détecte pas à l’avance des inconnus. Le système est donc en effet une progression par rapport aux systèmes existants mais a encore de grave lacune pour qu’ils soient utilisables.

La proposition des auteurs (R. Paleari, L. Martignoni, G. F. Roglia et D. Bruschi) du papier “A fistful of red-pills: How to automatically generate procedures to detect CPU emulators” publié à USENIX Security 2009 est de lancer une série d’instructions dans l’environement virtualisé et les mêmes dans un environement normal. En analysant la différence, ils sont capable de générer automatiquement des outils de détection de la virtualisation (i.e. les fameux redpill). Ils ont réussi à générer automatiquement près de 21 000 redpils pour QEMU et 3000 pour BOCHS.

La découverte automatique d’instructions n’ayant pas les même retour entre un CPU réel et un CPU virtualisé est fait en se basant sur le programme EmuFuzzer.

Well, this is my goodbye header for milw0rm. I wish I had the time I did in the past to post exploits, I just don’t . For the past 3 months I have actually done a pretty crappy job of getting peoples work out fast enough to be proud of, 0 to 72 hours (taking off weekends) isn’t fair to the authors on this site. I appreciate and thank everyone for their support in the past.
Be safe, /str0ke

Edit : milw0rm est de retour en ligne (voir ce twitter)

Les développeurs de Google Chrome ont voulu prendre en compte des aspects de sécurité dès le début pour éviter d’ajouter des couches bancales par la suite. Pour cela, ils ont mise en place une architecture de sécurité relativement élaborée permettant de limiter l’impact des nombreux problèmes de sécurité que peut recontrer un browser lors de ses passages sur des pages web malicieuses. La description de cette architecture est disponible sur le site de chronium (la version libre de Google Chrome). Une partie se base sur des autres travaux de recherche de Google dont j’avais parler ici.

Afin d’améliorer la sécurité de leur browser, ils se basent sur trois régles:

• Limiter la sévérité des vulnérabilités dû aux moteurs de rendu du browser en les plaçant dans une sandbox.
• Limiter le nombre de failles non corrigées et de vieilles versions en facilitant les mises à jours.
• Limiter la fréquence d’expositions aux attaques en annonçant aux utilisateurs quand ils vont visiter un site connu comme malicieux.

Limiter la sévérité des vulnérabilités

Comme je l’expliquai dans l’introduction, Google Chrome utilise une sandbox pour limiter les effets dû à des bugs dans le moteur de rendu (qui est souvent une des manières pour corrompre le browser et l’OS derrière). Cette architecture est décrite en détail dans le billet précédent et est visible dans la figure suivant.

La structure est comme on peut le voir très modulaire. Au final, on se retrouve avec des choses relativement proche des hyperviseurs et/ou des micro-noyaux. Toutes les données sensibles sont stockée par la partie sûre et les rendus sont fait par la partie non sûre. Cette fonctionnalité de sandboxing permet que même si un malware arrive à tourner via une faille dans le moteur de rendu. Son effet sera limité à la sandbox et il ne pourra pas installer un malware ou intéragir en quelques manières que ce soit avec le système.

Ils appliquent également plusieurs méthodes permettant de rendre l’exploitation de vulnérabilités plus dures comme la gestion sûr des erreurs, la non executabilité de la mémoire ou l’allocation de manière aléatoire des plages mémoire.

Chaque origine i.e. site web tourne dans sa propre sandbox. Dans certains cas, plusieurs sites webs peuvent tourner dans le même si il y a des intéractions entre eux. Une sandbox par site web serait mieux mais il faudrait pouvoir gérer les intéractions entre les sandbox. Même si cela est possible suivant des concepts de recherches comme OP et Gazelle, cela est difficile à implémenter de manière efficace.

Reduire la fenêtre de temps des vulnérabilités

Le but est de laisser des failles connues le moins longtemps possible disponible. Pour cela, il faut mettre en place une architecture de mise à jour très efficace. Pour Chrome, dès qu’un bug est détectée, il est corrigée. Puis le patch est testé via les outils de tests automatique de WebKit (le moteur de rendu de Chrome) mais aussi sur 1 millions de pages web de manière automatique.

Les patchs sont ensuite installés automatiquement sur les machines faisant tourner Chrome sans aucune intervention de l’utilisateur ce qui permet une réactivité très bonne sur la correction de failles i.e. voir la figure ci-dessous.

Réduire le nombre de fois que le browser est exposé à des failles

Le but de cette fonctionnalité est relativement simple: prévenir les utilisateurs avant qu’ils aillent visiter un site potentiellement malicieux. Pour cela, Google travaille avec StopBadware.org pour maintenir une base de données à jour de ces sites.

Conclusion

A part la première fonctionnalitée qui est une intéressante d’un point de vue de recherche en sécurité comme je l’avais exprimé dans le précédent billet (même si loin d’être parfaite), les autres sont plus du bon sens. Mais additionner les unes aux autres, elles permettent effectivement d’augmenter le niveau de sécurité du browser.

Bien entendu, il reste de nombreux points à traiter comme la gestion des plug-ins tel que Flash mais on voit que le niveau de sécurité global augmente en appliquant la régle du moins de priviléges possible données à une application.

Références:

Browser Security by C. Reis (Google), A. Barth (UC Berkeley), C. Pizano (Google) – ACM Queue

• L’europe et la license graduée
• Première analyse d’HADOPI
• Disfonctionnement du système de détection du partage P2P
• Annonce de la riposte graduée
• La CNIL accepte une dérive liberticide
• Le piratage pour le fun et le profit
• Avant projet de loi Olivienne (futur HADOPI)
• Les majors demandent un accès total aux données des fournisseurs d’accès

Le but de ce billet est de montrer que techniquement HADOPI reléve d’une
méconnaissance totale du fonctionnement d’Internet et de l’informatique
et des réseaux en général. Je ne me considére pas comme un expert dans
le domaine de limitation des accès sur Internet. Par contre, j’ai un
double diplôme ingénieur et master recherche en sécurité informatique et
je prépare actuellement une thèse en securité système. De plus, je donne
des cours en sécurité informatique en IUT. Je pense avoir un minimum de
connaissance pour donner une vision réaliste de la situation qu’amènera
cette loi. Voici donc pourquoi cette loi ne sera qu’une de plus à mettre
au cimetière juste après son vote sans aucune possibilité d’application.

Il y a plusieurs hypotheses sur l’application de HADOPI. Partons du but
ultime de HADOPI: supprimer le téléchargement de fichiers sous copyright
sur Internet et particulièrement le partage par réseau pair à pair. Le
protocol P2P (pair à pair) qui est spécialement visé est le torrent.
Alors comment “contrôler” torrent ?

En effet, il n’est pas possible de “simplement” d’interdire le P2P car
il sert pour de nombreux autres usages que le téléchargement de fichiers
sous copyright. Il faut donc pouvoir détecter le téléchargement et le
partage de fichiers clairement fixés. Pour cela, je commencerai par le
niveau le plus général jusqu’au niveau le plus précis.

Tout d’abord, il serait possible pour les majors de surveiller les
serveur torrent (tracker) qui permettent aux utilisateurs de se
connecter les uns les autres pour partager un fichier. Mais, il existe
des dizaines de millers de ces trackers et beaucoup sont privés voir
très privés. De plus, il faudrait que pour chaque téléchargement, les
personnes controlant les transferts soient capable de fournir des
preuves irréfutables que l’utilisateur (i.e. l’adresse internet IP) a
bien téléchargé. Cela est possible et déjà fait dans d’autres pays à
grande échelle comme les USA. Mais cette solution marche mal avec
beaucoup de faux positifs (des personnes ayant été poursuivi mais
n’ayant pas télécharger) et elle est de plus en plus abandonnée par les
personnes l’utilisant (les majors du disques et la RIAA).

Alors, pourquoi, comme le proposent les majors du disques et du cinéma,
ne pas mettre en place des logiciels de contrôles chez les fournisseurs
d’accès internet (FAI) ? Mettons que les FAI sont d’accord pour les
installer. Le logiciel va pouvoir contrôler tout ce qui se passe sur le
réseau. Mais est-il possible pour autant de détecter le téléchargement
de fichiers sous copyright. Pour cela, il faut plusieurs prérequis: une
empreinte de chaque fichier qui ne doivent pas être partager et pouvoir
connaitre l’ensemble de ces fichiers. Premièrement, avoir une empreinte
de fichier est tout à fait possible et très utiliser pour détecter de la
modification de fichiers pendant les transfert (avec les checksums: MD5,
SHA). Connaitre tous les fichiers qui contiennent du contenu sous
copyright est nettement plus compliqué. En effet, il faut savoir que
pour un même film il peut y avoir plusieurs centaines de fichiers
totalement différent le contenant suivant comment et par qui ils ont été
copiés. Il faudrait donc connaitre l’intégralité de ces fichiers ce qui
risquent d’être particulièrement compliquer, voir impossible. De plus,
le protocol torrent contrairement à d’autres protocoles P2P (comme
KaZaa) ne transmet pas les fichiers en une seule fois mais en petite
pièces qui peuvent venir de plusieurs personnes. Donc savoir qu’une
personne télécharge un fichier il faut savoir reconstruire ce fichier et
vérifier que c’est un fichier sous copyright. Cela est compliqué et à un
fort cout en terme de ressources informatique. En plus, il faudrait le
faire pour tout les transferts sous torrent, cela même si le fichier
n’est pas sous copyright. A ce moment, cela devient totalement
infaisable sans des couts totalement prohibitifs.

Rapprochons nous de l’utilisateur: installons un logiciel de
vérification au niveau de la “box” de l’utilisateur. Ce logiciel ne
pourrait pas faire plus qu’un logiciel installé chez un fournisseur et
devrons donc être puissante ce qui n’est pas le cas. Finalement,
installer un logiciel sur l’ordinateur de chaque internaute pour qu’il
puisse prouver qu’il a bien pas télécharger. Ce logiciel devra donc être
capable de le faire. C’est cette voie que semble avoir choisi le
gouvernement avec HADOPI. Imaginons que ce logiciel soit une sorte
d’antivirus, il pourrait faire deux choses. D’abord vérifier que tous
les fichiers entrant sur l’ordinateur ne sont pas un fichier sous
copyright. Pour cela, il se retrouverai avec les mêmes problèmes que
ceux posées aux FAI et à une installation sur une “box”. Sinon, il
pourrait vérifier chaque fichier sur le disque dur des internautes et
vérifier que ce fichier ne fait pas parti d’une liste de fichiers
interdits. Cela est tout à fait possible même si demanderait une très
lourde infrastructure (je ne parle pas des implications de vie privée).

L’interdiction d’accès a certains sites (PirateBay pour ne citer que
lui) n’est dans la réalité pas possible car il sera toujours possible
par des voies plus ou moins détournées d’y accéder. Les accès de site
interdit depuis la chine est faisable hors ils ont une infrastructure de
contrôle de l’Internet qui est inégalable. Il reste une proposition:
obliger l’utilisation du P2P avec un logiciel spécial qui contrôle tout
ça: le logiciel serait contrefer et modifier en quelques heures pour ne
plus fonctionner.

Mais revenons en arrière progressivement pour montrer que même si les
logiciels ne fonctionneraient que difficilement à tous les niveaux
malgré cela il serait simple de les contourner. En effet, un logiciel
spécial serait modifier pour ne plus envoyer d’alarmes de piratage à
HADOPI, cela est relativement simple particulièrement pour une
communauté qui a des capacités de modification de logiciels de très haut
niveau (piratage rapide de n’importe quelles nouvelles protections
coutant des centaines de millers d’euro en quelques jours).

Mais, alors pour le logiciel sur l’ordinateur, il faut savoir que sur
Internet, l’ensemble de votre réseau personnel ne contient qu’une unique
identité. Si vous disposez de plusieurs ordinateurs branchés sur votre
box en WiFi ou filaire, ils auront tous la même adresse IP sur Internet.
Il serait donc simple d’acheter un ordinateur où on installe le logiciel
spécialisé pour le contrôle et télécharger sans aucun problème des
fichiers sous copyright sans être détecter. Le logiciel ne contrôlant
qu’un ordinateur et cela suffirait pour prouver son innocence. On
pourrait même utiliser des technologies de virtulisation permettant de
faire tourner plusieurs ordinateurs sur un seul physique et donc n’avoir
rien à acheter.

Pour finir, au niveau des FAI, des boxs et autres, il est tout à fait
possible de se cacher totalement en chiffrant les données sans qu’elles
puissent être lues par une autre personne que le destinataire. Cela est
déjà mise en place pour torrent et pourrait s’amplifier très simplement.
De plus, il est tout à fait possible de louer un serveur ou une partie
de serveur permettant de cacher son identité (i.e. son IP) sur Internet.
Le prix de tel service a chuté en quelques mois et on trouve des
solutions à quelques euros (5) maintenant. Dans ce cas, l’adresse
pourrait se trouver à l’étranger et donc ne s’appliquerait plus à la loi
française.

Finalement, même si le torrent est stoppé, un protocole contournant tous
les failles de torrent serait mise en place qui serait de plus en plus
totalement indétectable (l’exemple de la course à l’armement dans le
monde des malwares et virus est clair). Il faut également savoir que de
nombreuses personnes téléchargent par d’autres voies (FTP,
téléchargement HTTP avec rapidshare ou autres, newsgroups, etc). On voit
donc que peu importe le système il ne fonctionnera pas. Et que même si
le système fonctionnerai, il serait rapidement contourner et cela avec
des manières très simple utilisable pour tout le monde (même madame
michu !). On rangera donc HADOPI avec la DAVDSI dans les lois inutiles
et inaplicable.