Dans un précédent billet consacré au RPVA, j’avais émis des doutes sur l’interopérabilité de cette appli web payante imposée par la Chancellerie avec les systèmes GNU/Linux. Quelques mois après des échanges avec mon Bâtonnier, et les échanges que ce dernier a lui-même mené avec le CNB, voici les avancées.
Je ne suis pas expert en informatique, le texte peut donc comporter des erreurs. Que mes lecteurs veuillent bien m’en excuser par avance et me corriger au besoin, les commentaires étant les bienvenus.
1. Le packaging
L’ensemble se compose d’un boîtier VPN/routeur/FW (par cabinet) et d’une clé USB de chiffrement (ou de plusieurs, selon le nombre d’avocats se connectant à ebarreau).
2. Le boîtier NAVISTA
Le boîtier NAVISTA (ou « RSA » pour « Routeur Sécurisé Avocat ») a été conçu par la société NAVISTA. Il tourne sous Linux (pas étonnant sur le plan de la sécurité) avec un kernel 2.6.25 [1] permettant un tunnel VPN chiffrés en AES 256 : il est chargé d’encapsuler du chiffrement SSL dans un chiffrement VPN.
Le boîtier se branche par un câble RJ 45 sur le serveur (via un hub ou un switch) et la connexion aux serveurs du ministère se fait par un routage d’adresse web depuis le serveur, car pour que la connexion puisse être certifiée, le boîtier doit impérativement servir de passerelle.
S’agissant de la vérification des connexions, c’est le protocole normal du système de chiffrement avec autorité de certification qui s’applique. Le système travaille en temps réel, puisque c’est l’autorité de certification (Certeurope) qui autorise ou non la connexion en fonction des clés qui sont présentées.
L’un des informaticiens avec qui j’en ai parlé ajoute :
« Il y aussi la possibilité sur la configuration du serveur de ne laisser passer que des clients autorisés pour initier des connexions sécurisés sur le serveur. Je n’entre pas dans les détails car le sujet est trop vaste mais cela permet entre autre d’invalider des clés ou des adresses IP. Certaines surcouches logicielles permettent d’automatiser le travail ; en particulier sur les adresses IP avec fail2ban par exemple. »
À chaque connexion web au site ebarreau, le serveur route la requête vers le boîtier et la connexion se fait. Évidemment, la requête n’est routée que pour les confrères équipés d’un serveur comme moi.
Pour les cabinets n’en étant pas équipés, compte tenu du fait que le boîtier NAVISTA doit servir de passerelle, ils doivent nécessairement le brancher directement à la sortie de leur box internet (qui ne sert éventuellement plus de passerelle).
Dans cette dernière hypothèse, toutes les données internet venant de la box passent par le boîtier, ce qui me semble révéler une faille de sécurité importante puisque pas grand monde ne sait quelles sont les lignes de code qui ont été écrites par la société NAVISTA sur les spécifications du ministère.
D’autres de mes confrères ont fait deux réseaux informatiques câblés, l’un avec le routeur, l’autre sans et je pense que la facture a dû se révéler rapidement disproportionnée. Les prestataires informatiques avec qui j’en avais discuté (en 2009 et 2010) m’avaient indiqué à l’époque que l’intervention distante avec le routeur NAVISTA était compromise, puisqu’ils n’avaient pas pu obtenir les numéros de ports à ouvrir sur le FW pour permettre les interventions. J’ignore aujourd’hui si c’est encore le cas.
Si l’on considère le seul boîtier, rien ne s’oppose donc à son fonctionnement sous les architectures GNU/Linux. Le seul souci reste qu’on ignore ce que contient ce routeur qui autorise donc n’importe qui à rentrer dans son SI de façon tout à fait autorisée… J’attends donc qu’un jour, le dirigeant de la société NAVISTA, Jean VINEGLA, donne des informations vérifiables sur cette question à l’ensemble des confrères. Je n’ai pas trouvé sur le site de NAVISTA le datasheet qu’il m’avait promis en juin 2010, mais peut-être ai-je mal cherché.
Cette demande sur le contenu du boîtier est d’autant plus importante que la société NAVISTA a la possibilité de couper les connexions à distance, comme le raconte Maître Jérôme GAVAUDAN, Bâtonnier de Marseille (cf. l’assignation).
Quoiqu’il en soit, ce système a du plomb dans l’aile, car il semble qu’il soit prévu dès 2012 (l’appel des décisions par les avocats par voie électronique se fera à compter de cette date, en raison de la suppression des Avoués) un RPVA II qui ne comporte ni boîtier, ni clé, mais un simple login et un mot de passe (cf. les commentaires sous l’article en question). Il semble donc urgent d’attendre selon certains confrères !
MAJ 27/07/11 : Un peu de documentation sur le boîtier Navista.
3. La clé USB de chiffrement
C’est là que les choses se compliquent le plus.
La clé USB de chiffrement est en réalité un lecteur de cartes SIM. Elle contient une clé de cryptographie chiffrée pour garantir la sécurité en cas de perte. La sécurité de la connexion dépend donc des algorithmes utilisés et sur ce terrain, je n’ai pas d’informations de la part du CNB qui, de toutes façons, est aux abonnés absents même pour des questions nettement plus basiques. L’ensemble des organismes de certification propose une solution pour les trois grandes architectures GNU/Linux, Mac, et Windows pour implémenter l’algorithme au besoin.
Une fois la clé branchée, le système vous demande votre code PIN (il existerait un code PUK) et la connexion est faite. Simple non ?
Et bien non : la commande lsusb m’informe que la clé USB est le modèle Gemsafe de la société GEMALTO. L’installation sur les achi Linux risque de s’avérer sportive puisque ce matériel n’apparaît plus dans le support officiel de GEMALTO. Il semblerait qu’il ait existé des pilotes Linux, en RPM et Deb, mais uniquement pour architectures i386 (ce qui ne va pas résoudre mon problème puisque mon serveur et mes postes clients sont tous en 64 bits et que l’architecture i386 date de la préhistoire). Pour les clés récentes que propose GEMALTO (ce qui ne semble pas être le cas des clés RPVA), celles-ci sont nativement supportées par Linux avec l’installation de la librairie 32 bits libccid.so.0 ou 64 bits.
La dernière réponse du responsable du service informatique du CNB à mon bâtonnier m’a laissé bien perplexe, je vous la livre :
« S’agissant de la compatibilité avec le système d’exploitation Linux, comme vous le savez c’est le pilote de la clé cryptographique qui détermine la compatibilité avec les systèmes d’exploitation.
Notre prestataire Certeurope dispose de deux version pour Linux : REDHAT 4_03 (i386) et DEBIAN (i386).
Ces pilotes sont disponibles sur demande mais notre prestataire n’assure pas le support sur ces derniers. »
Est-ce à dire que la société Certeurope aurait acheté en masse à la société GEMALTO des clés USB aujourd’hui obsolètes faute de support matériel et qu’elle n’assurerait pas les conséquences de cette erreur en ne fournissant aucun support pour les architectures GNU/Linux, y compris en 64 bits ? C’est pour l’instant la conclusion que je tire de cette correspondance pour le moins obscure.
En l’état, le système étant payant et obligatoire, il appartient au CNB d’assurer son interopérabilité avec les SI des cabinets d’avocats, notamment ceux qui sont comme moi sous GNULinux (et il en existe plusieurs, notamment sous Ubuntu, Gentoo, Mandriva ou encore Mageia).
La réponse est toujours meilleure que celle que m’avait faite le service informatique du CNB en juin 2010 :
« Ebarreau n’est pas supporté sous linux
Seule les OS mac 10.5.X 10.6.X et les Windows 2000/xp/vista/seven sont
supportés »
Il est tout de même effarant de constater que tout cela a déjà coûté plus de deux dizaines de millions d’euros et qu’à ce prix, nous n’avons qu’un système qui « marchouille » et qui est truffé de bogues. Quelques exemples à ce jour :
- pas d’accusé de réception réellement individualisé pour un appel, ce qui fait que si vous faites trois appels dans la foulée, il est difficile de voir quel AR concerne quel appel…
- le taille des pièces jointes, toujours limitée à 4 Mo, soit plus de deux fois moins la capacité de transit des boîtes actuelles de courrier électronique mises en place par les founisseurs (FAI ou webmails tels Google ou autre) ;
- les champs de choix des juridictions pour les appels sont encore problématiques : par exemple, il manquerait notamment pour les ordonnances de référé, un champ pour indiquer que c’est le « président » qui a rendu l’ordonnance, ou un champ relatif au « juge commissaire »…
- on peut se constituer sur un appel, mais le système ne génère pas encore matériellement d’acte de constitution, que les textes imposent pourtant aujourd’hui d’envoyer par acte du palais au confrère adverse.
Les corrections se font, mais visiblement à une vitesse qui sera difficilement compatible avec la date butoir du 1er janvier 2012 à laquelle nos regrettés Avoués disparaîtront définitivement (les avoués sont tenus de faire les appels et les constitutions par voie électronique via le RPVA à compter du 1er septembre 2011).
La suite au prochain épisode.
MAJ 27/07/11 : la clé contient un certificat Classe 3+ et je suis tombé sur cet article (pour les clés Gemsafe).
MAJ du 27/08/11 :
Regardez l’interview de Christiane Féral-Schuhl (à partir de 2 min 50), qui indique que moins de 30 % des avocats du barreau de Paris sont connectés au RPVA (soit environ 6.900 avocats seulement sur les 23.000 qui composent le barreau de Paris). Il est à noter qu’à compter du 1er septembre 2011, les appels et les constitutions devront obligatoirement être faits par voie électronique via RPVA. À l’heure actuelle, les avoués à la Cour font encore ces actes de procédure (pour les matières nécessitant le ministère d’avoué) pour les avocats non équipés. Mais à partir du 1er janvier 2012, les avoués auront définitivement disparu du paysage…. il douteux de penser que tous les avocats seront alors équipés du RPVA !