Adresse IP : l'Hadopi envisage un "risque d'emballement accidentel"

Et celui volontaire ? 105
Marc Rees
Le cahier des charges techniques a été dévoilé aujourd’hui dans les colonnes de Numérama. Ce document, qui n’est pas exactement la convention entre FAI et Hadopi mais plutôt son volet technique, orchestre l’interconnexion des données entre ces acteurs.

 

Le texte date de mai 2010 et il spécifie qu’il « pourra évoluer notamment pour tenir compte des modifications et compléments du cadre règlementaire applicable ». On ne connait pas à ce jour l’état de la version actuelle, toujours objet de négociations notamment financières. Le document est par ailleurs daté puisqu’il prévoyait une mise en production le 22 juin, soit juste après la fête de la musique. Les données présentes offrent néanmoins un précieux aperçu de cette usine à avertissements.

Deux chapitres rythment ces relations :
  • L’identification des abonnés (flux Hadopi-FAI-Hadopi qui transforme une IP en nom)
  • L’envoi des recommandations. (flux Hadopi-FAI-Abonné qui impose le relai du mail)
L’IP identifiée : Hadopi->FAI->Hadopi

On apprend au fil du cahier des charges que la demande d’identification sera constituée d’un fichier PDF intégrant une série de mentions « administratives et réglementaires ». Chaque fichier CSV sera numéroté, daté etc. Le nombre de demandes d’identification sera aussi renseigné dans ce "pack".
Risque d'emballement accidentel
Dans le projet il est dit que « pour permettre de détecter un emballement accidentel du système et d’en prévenir les conséquences, ce nombre sera borné à 50 000. Cette mesure vient en complément des mesures prises dans le système de l’Hadopi pour assurer l’intégrité du flux. Le nombre pourra être modifié ultérieurement si nécessaire. » 50 000, le chiffre n’est pas innocent puisque le monde du cinéma et celui de la musique avaient (à l’époque) prévu d’envoyer 25 000 IP/jour chacun.

Cette petite mention montre bien qu’Hadopi compte pousser vers le haut la volumétrie des demandes d’identification. Le nombre d’informations sur chaque dossier comprend trois pages dans le cahier des charges. Hadopi va se retrouver ainsi à la tête d’une jolie masse d’informations sur chaque internaute soupçonné via les cadrans de TMG de mal sécuriser leur accès Internet.
Les motifs justifiant un échec d'identification
Au fil de l’eau on apprend que les FAI devront indiquer dans un « champ MOTIF » la raison pour laquelle l’identification a échoué. Des accidents pouvant toujours arriver même dans une chaîne toute automatisée. « Les valeurs possibles pour le champ motif sont « ip inconnue » si l’adresse IP fournie ne correspondait pas à une adresse de l’opérateur au moment des faits, « pas de connexion » si aucune connexion n’était active sur l’adresse demandée au moment des faits » donne en exemples le document.
Les bornes d'accès Wifi
Celui-ci considère que l’identification de l’abonné aura encore échoué en cas de données « multiples ». Le cas décrit est le suivant : « si l’identification remonte plusieurs abonnés au moment des faits (exemple d’IP multiple tel que les bornes WIFI publiques) ». Est-ce à dire que les bornes d’accès wifi seront par défaut exclues d’Hadopi ?

La procédure s’arrêtera tout autant en cas de « plage d’IP non identifiable, dans le cas où le contrôle de la plage d’IP indique par exemple une IP de MVNO » ou s’il subsiste un doute sur l’identification « exemple du changement de l’IP au milieu de la seconde »…
Des informations douteuses, mais verrouillées
Quoique douteuses, les informations seront verrouillées : « le standard S/MIME et les certificats au format X.509 seront utilisés pour gérer l’authentification et la "confidentialité des messages. Le chiffrement des contenus sera réalisé selon l’algorithme AES avec des clés de 128 bits. Les certificats seront générés aléatoirement par les outils de messagerie. Conformément au format S/MIME, la clé de chiffrement du contenu sera transmise dans le message, chiffrée par un processus asymétrique par l’algorithme RSA ».

Dans les relations d’Hadopi avec les opérateurs, il est encore spécifié que « chaque FAI recevra au plus un fichier par jour ouvré » laissant entendre une masse parfois importante de données à traiter après une série jour férié-week-end.

Le mail envoyé : HADOPI->FAI->Abonné

Pour la partie concernant le relai des emails, il est dit prévu que « chaque FAI mette en place un serveur SMTP permettant l’envoi des emails de recommandation à l’attention de ses abonnés. Il communiquera l’adresse (d’identification et d’authentification) du serveur à l’HADOPI ainsi que sa configuration ».

Ce nœud de connexion fondamental « se comportera comme un proxy SMTP en mode authentifié (TLS) permettant d’adresser l’ensemble des serveurs SMTP ainsi mis en place. Chaque email de recommandation sera émis, à l’attention de l’adresse email fournie lors de la phase d’identification, sur le serveur SMTP du FAI ayant réalisé cette identification. Il est demandé que l’échange se fasse en mode sécurisé, via un mode TLS, et que l’authentification SMTP se fasse par certificat. » C’est justement cette plate-forme que Free avait refuser d’ouvrir lundi 4 octobre, contrairement aux autres opérateurs qui avaient choisi d’ouvrir les vannes.
Ne pas se préoccuper de la réception des emails
Dans ce dispositif, la Hadopi envisage bien des problèmes de bouchon, mais ne s’en préoccupe pas plus. Elle ne se préoccupe pas de savoir si l’abonné a bien eu le mail. Le texte de loi ne se préoccupe que de l’envoi de l’avertissement, pas de sa réception. : « Il n’est pas demandé de confirmation de l’envoi des emails aux abonnés : les acquittements seront uniquement gérés au niveau technique par les mécanismes classiques du protocole SMTP. Les envois se font au fil de l’eau, sans planification particulière, ce qui n’exclut pas des phénomènes de pic. Lors d’un échec d’envoi lié à une erreur protocolaire reçu d’un serveur distant, les messages de retour sont à supprimer directement ».

« Les contrôles mis en place sur les réseaux des FAI ne devront pas perturber les envois des mails des agents de l’HADOPI (exemple : provenant des adresses mails en xxxx@hadopi.fr, envoyés à partir de serveurs utilisés par l’HADOPI). L’adresse exacte d’envoi (expéditeur) sera communiquée ultérieurement. Il peut s’agir d’un sous-domaine de hadopi.fr, ou d’un autre nom de domaine appartenant à l’Hadopi ». Le protocole ici que les « mails de recommandations envoyés par les serveurs SMTP installés chez les FAI doivent pouvoir transiter sur les réseaux des FAI et être délivrés dans les BAL sous leur contrôle sans être bloqués (ou considérés comme du SPAM) », ce qui serait du plus mauvais effet, il est vrai...