Hadopi : l’impossible logiciel de sécurisation…

6

Le logiciel de sécurisation (ou logiciel espion) voulu par la Hadopi et décrit dans un cahier des charges précis, serait tout simplement impossible à mettre au point, selon certains observateurs.

Des incohérences d’ordre technique viendraient-elles remettre en cause l’arrivée future de logiciels de sécurisation certifiés compatibles avec les exigences de la Hadopi ? C’est en tout cas ce que laisse entendre Romain Vimont, aka ®om, sur son blog.

C’est le principe du double journal (l’un étant enregistré en clair, l’autre de manière chiffrée pour être théoriquement infalsifiable) qui pose problème. Si le journal chiffré est généré intégralement en local, la clé de chiffrement ne peut être privée puisqu’elle doit être intégrée au logiciel… ce qui permettrait à l’utilisateur de modifier ses rapports comme il le souhaite.

En recourant à un tiers de confiance, qui disposerait alors de la clé privée, ce n’est pas beaucoup mieux. On peut imaginer qu’un logiciel serait conçu dans l’optique de générer des faux rapports, lavant l’utilisateur de tout soupçon : ceux-ci seraient alors transmis, puis chiffrés par le tiers de confiance, sans que celui-ci n’ait le moyen de vérifier leur authenticité. « Il suffit de modifier les sources du logiciel qui écrit le journal « sécurisé » pour qu’il n’écrive que ce que l’on décide », résume le blogueur.

Rappelons enfin que le cahier des charges prévoit que les logiciels de sécurisation puissent être réalisés à partir de logiciels libres. Il sera donc d’autant plus facile, pour les développeurs, d’analyser leur fonctionnement et de le modifier de façon à générer des rapports ne reflétant en rien l’activité réseau réelle de l’internaute…

Un logiciel permettant de générer des rapports totalement chiffrés et infalsifiables, comme le stipule le rapport de la Hadopi, semble donc bel et bien impossible à mettre en œuvre. ®om prend ainsi le pari que les premiers softs « falsificateurs » ne tarderont pas à voir le jour, sitôt les logiciels officiels disponibles…

Source : ®om’s blog

Partager

A propos de l'auteur

[Responsable de la rédaction] Sévit également sur Café Gaming et Point de vue social.

6 commentaires

  1. Sauf que pour chiffrer, la clé publique suffit. La clé privée sert à déchiffrer. C'est pour signer qu'il faut une la privée. La clé publique servant à vérifier la signature par le destinataire. Mais ca ne remet pas en cause le fait que l'utilisateur doit effectivement pouvoir signer/chiffrer ses propres logs si il choppe la clé dans le logiciel.

  2. On revient toujours au meme point: dès que l'on est sur la machine finale, nous ne pouvons pas avoir confiance... On parle ici de log, nous pouvons aussi parler de la musique en streaming (comme Deezer) qui sont facilement enregistrable sur la machine finale. Idem pour les film en streaming. Le bon niveau d'écoute serai chez les FAI, et encore, avec des VPN on masquerait tout. Au final, il n'y a pas bcp de solution viable. A si, une, autoriser seulement, les IP francaise a accéder a des IP francaise et uniquement francaise... Et encore, il faudrait interdire les disques dur externe aux frontières et tout et tout.... Oui, donc impossible, c bien ca!!

  3. Salokyn a écrit :
    Sauf que pour chiffrer, la clé publique suffit. La clé privée sert à déchiffrer. C'est pour signer qu'il faut une la privée. La clé publique servant à vérifier la signature par le destinataire. Mais ca ne remet pas en cause le fait que l'utilisateur doit effectivement pouvoir signer/chiffrer ses propres logs si il choppe la clé dans le logiciel.
    c'est vrai qu'on on chiffre un document à destination d'une personne en particulier avec la clé public du destinataire et sa propre clé privée.(principe du chiffrage a double clés) Je suis d'accord avec toi, chiffrer uniquement avec une clé publique revient a ne pas permettre de savoir qui a chiffrer le document et donc permettre a tous de chiffrer un document car la clé publique est comme elle l'indique publique. donc, dans le cas présent, ceci ne prouve en rien la véracité des logs.

  4. Salokyn a écrit :
    Sauf que pour chiffrer, la clé publique suffit. La clé privée sert à déchiffrer. C'est pour signer qu'il faut une la privée. La clé publique servant à vérifier la signature par le destinataire. Mais ca ne remet pas en cause le fait que l'utilisateur doit effectivement pouvoir signer/chiffrer ses propres logs si il choppe la clé dans le logiciel.
    "il n'y a qu'à" déployer une PKI, et filer un certificat (l'HADOPI s'érigeant en tiers de confiance, et donc responsable de l'AC) à chaque box, la doter d'une carte à puce pour sécuriser sa clé privée, et ainsi toute la sécurité est assurée de bout en bout. bref, pour les curieux, cherchez "PKI" dans Wikipedia, vous comprendrez ce que je veux dire... c'est techniquement faisable, mais à quel prix... (et je parle pas que du prix en euros) et surtout, pour quoi faire ? ce système, à ce stade, ce serait pire que Big Brother !

  5. Concernant le chiffrement, il faut plutôt voir une paire de clés. L'une des clés peut déchiffrer ce qu'a chiffré l'autre. Ensuite, on en décrète une privée et l'autre publique pour bien voir qu'il ne faut bien évidemment pas diffuser les deux clés. Mais rien ne m'empêche de garder pour moi les deux clés .... ou de diffuser les deux. Ensuite, signer n'est en fait que chiffrer un hash du fichier. Dans le cas de Hadopi, tout cela est stupide puisqu'il me suffit d'ouvrir une deuxième ligne Orange, d'y mettre un modem du commerce (non français), de faire transiter mes données P2P par là et c'est mort. Bref, à quoi bon dépenser l'argent du contribuable dans de telles idées, dont tout le monde sait, dès à présent, qu'elles finiront à la poubelle ?

  6. Réagir sur le forum