Après avoir cotoyé Maître Cuif dans le monde du logiciel libre, voilà quelques années il nous a contacté pour finaliser le passage à l’Open Source dans son cabinet. Si la gestion du partage de fichiers, d’agendas, de contacts, la sécurisation des données n’ont pas posé de problème particulier, en revanche la mise à disposition d’un poste de travail 100% Open Source fut une autre paire de manches et notamment la connexion au cloud avocat (e-barreau labellisé RPVA) au moyen d’une clé sécurisé et la signature électronique d’actes (eacte) utilisant cette même clé.

Acte 1 : Premier support pour l’utilisation de la clé RPVA

Le travail a été réalisé sur Ubuntu 14 il y a quelques années. Gemalto fournissait alors un driver, libclassicclient, sous forme de paquet deb. Mais l’installation est loin d’être triviale et nécessite l’installation de dépendances dont les versions sont ante-diluviennes :

libssl0.9.8_0.9.8o-7ubuntu3.2_amd64.deb

Utilisée en 2016/2017, cette version d’openssl, composant essentiel pour la plupart des briques de sécurité sous Linux, est réputée bourrée de failles de sécurité. Cette version majeure a été releasée pour la première fois en 2005 et la dernière version a été proposée fin 2015.

L’installation de libclassicclient nécessitait donc l’installation en parallèle de 2 versions de cette librairie openssl, l’une supportée officiellement et l’autre non.

Ont donc été produits de la documentation sur le mode d’installation et un package logiciel pour pouvoir reproduire une installation à l’identique sur tous les postes.

Quelques liens sur des procédures écrites pour Ubuntu :

• Avocats sur Ubuntu
• Article de Descartes Avocats

Acte 2 : Nouvelle clé, nouveau driver

Au bout de quelques temps, le travail est à recommencer. Les clés ont été changées, ainsi que le driver. La nouvelle clé, encore utilisée aujourd’hui, est une Gemalto IDGO800.

Première mauvaise surprise : la clé doit être activée, il est nécessaire également de fixer le code pin associé. Les outils sont fournis par Gemalto… mais ne fonctionnent pas sous Linux. Il faut donc trouver un PC équipé de Windows pour procéder à cette étape.

Les drivers mis à disposition pour Linux sont fournis sous forme de paquets deb et rpm : libidprimepkcs11_1.2.3_amd64. Là encore l’installation n’est pas triviale car elle nécessite des versions anciennes de certaines dépendances non mises à disposition dans les distributions :

libboost-system1.54.0
libboost-filesystem1.54.0
libboost-serialization1.54.0
libboost-thread1.54.0
libwxbase3.0
libwxgtk3.0

Non seulement ces versions sont anciennes, non supportées et sujettes à des failles de sécurité, mais elles peuvent également être sources d’instabilités du fait de l’installation en parallèle de 2 versions différentes.

Au même moment, le logiciel eacte entre en vigueur et est amené à être généralisé pour la production d’actes authentifiés. Almerys propose un package à installer qui doit permettre la signature électronique à partir des certificats contenus sur la clé RPVA. Il s’agit de eBeeAccessFoundation développé par Almerys. Et là les surpises continuent. Le support est assuré pour debian, Ubuntu et Fedora. SUSE est explicitement indiquée comme non supportée ce qui peut paraitre surprenant au vu de la liste précédente.

Première galère, les versions de packages proposées. Le nom d’un paquet logiciel est censé proposer les éléments suivants : nom du logiciel, version upstream et release pour la distribution. Ici il n’en est rien :

InstallG2SeBeeAccessFoundationLinux-amd64.rpm

Impossible de savoir à priori si on dispose de la dernière version. Il faut donc en explorer les métadonnées pour le savoir :

rpm -qpi InstallG2SeBeeAccessFoundationLinux-amd64.rpm

La documentation associée n’est pas versionnée donc impossible de savoir s’il y a eu des améliorations. Sa mise à jour est également très partielle puisque des pans entiers sont connus pour être caduques mais encore présents… Après pas mal d’efforts, le service est installé mais non fonctionnel, impossible d’accéder aux certificats contenus dans la clé Gemalto. Egalement le service démarré à l’ouverture de la session utilisateur démarre autant de fois qu’une session est initialisée… Les connexions ssh sur la machine finissent par flooder totalement la session… Pas de lock.

Nous partons donc à la recherche d’une éventuelle mise à jour qui corrigerait ce dysfonctionnement et là nous découvrons une gestion des dépôts logiciels illisible.

Non seulement les paquets logiciels ne sont pas versionnés mais le dépot ne fait aucune mention de ces dites versions. Impossible de savoir si une mise à jour est disponible, de quand date mon paquet ?….

Acte 3 : On ne baisse pas les bras, un poste avocat fonctionnel sur SUSE Leap 15

Nous nous sommes fixé un objectif et nous allons l’atteindre. Après un certain nombre d’heures de tests et debugs, nous finissons par obtenir un poste complètement fonctionnel sous SUSE Leap 15. Voici le détail de la mise en place.

Stack PKCS#11 pour SUSE Leap 15

1 – Import des certificats nécessaires dans le navigateur

Là encore la liste des certificats n’est pas claire à priori et nous découvrons grâce à cet article que 2 certificats supplémentaires sont nécessaires : 

• http://www.certeurope.fr/reference/certeurope_root_ca_3.cer
• https://www.certeurope.fr/reference/CertEurope_eID_Root.cer
• http://www.certeurope.fr/reference/certeurope_advanced_v4.cer
• https://www.certeurope.fr/reference/CertEurope_eID_User.cer

 2 – Installation des paquets de dépendances

Il s’agit d’installer l’ensemble de la stack PKCS#11 de SUSE :

zypper in opensc pcsc-lite pcsc-tools pcsc-ccid

3 – Autoriser l’utilisateur à accéder aux informations de la clé

Par défaut sur SUSE Leap 15, l’utilisateur n’est pas autorisé à utiliser la commande pcsc_scan par exemple. Comme nous sommes sous interface graphique, nous devons donc utiliser polkit pour définir des autorisations le concernant. On crée donc un fichier de règle :

# cat /etc/polkit-1/rules.d/100-pcsc-eacte.rules

polkit.addRule(function(action, subject) {
if (action.id == “org.debian.pcsc-lite.access_pcsc” &&
subject.user == “frederic” ) {
return polkit.Result.YES;
}
});

polkit.addRule(function(action, subject) {
if (action.id == “org.debian.pcsc-lite.access_card” &&
action.lookup(“reader”) == ‘Gemalto USB Shell Token V2 (B21D5FA8) 00 00‘ &&
subject.user == “frederic” ) {
return polkit.Result.YES;
}
});

Il suffit d’utiliser le squelette proposé ci-dessus et mettre à jour le nom de l’utilisateur et la référence de la clé à retrouver la sortie de la commande pcsc_scan.

4 – Installation des drivers de la clé

On en profite pour installer les tout derniers drivers (dont il n’est fait mention nul part aux premiers concernés) qui ont l’énorme avantage de ne nécessiter aucune dépendance exotique. Ne boudons pas notre plaisir !

zypper in SafenetAuthenticationClient-10.7.77-1.x86_64.rpm

Il suffit alors de charger le driver dans les périphériques de sécurité de Firefox (/usr/lib64/libIDPrimePKCS11.so). Une fois le périphérique chargé, il se suffit de se connecter avec le code pin requis. Surprise malgré tout, le driver n’est fourni que sous forme de RPM. Pour une installation sous Ubuntu ou debian, il faudra utiliser alien pour recréer le paquet adéquat.

Les drivers de la clé Gemalto sont à jour mais le paquet comporte des erreurs sur les fichiers desktop, fichiers utilisés pour intégrer les applications dans les menus et servant à lancer les dites applications :

/usr/share/eToken/shortcuts/SACMonitor.desktop 
/usr/share/eToken/shortcuts/SACTools.desktop

Pour vérifier le détail de ces erreurs, rien de plus simple, desktop-file-validate nous permet de les investiguer

desktop-file-validate /usr/share/applications/SACTools.desktop
/usr/share/applications/SACTools.desktop: error: file contains at least one line ending with a carriage return, while lines should only be separated by a line feed character. First such line is: "[Desktop Entry]"
/usr/share/applications/SACTools.desktop: warning: key "Encoding" in group "Desktop Entry" is deprecated
/usr/share/applications/SACTools.desktop: error: value "SafeNet-Authentication-Client" for key "Categories" in group "Desktop Entry" contains an unregistered value "SafeNet-Authentication-Client"; values extending the format should start with "X-"
/usr/share/applications/SACTools.desktop: hint: value "SafeNet-Authentication-Client" for key "Categories" in group "Desktop Entry" does not contain a registered main category; application might only show up in a "catch-all" section of the application menu
/usr/share/applications/SACTools.desktop: warning: value "SafeNet Authentication Client Tools" for key "Comment" in group "Desktop Entry" looks redundant with value "SafeNet Authentication Client Tools" of key "Name"

Essentiellement 2 erreurs :

• la spécification des catégories qui permet de positionner automatiquement à l’installation l’application dans le menu.
• la présence de caractères de fin de ligne générés sur Windows non interprétable directement sous Linux

Pour supprimer ces caractères nous utilisons dos2unix de manière à ne plus être pénalisés par cette erreur :

dos2unix /usr/share/eToken/shortcuts/SACMonitor.desktop 

Notre clé RPVA est maintenant complètement opérationnelle sans trop de problème.

5 – Installation de eBeeAccessFoundation

Avant de démarrer nos pérégrinations, il est indispensable d’activer le mode debug du service sans lequel nous n’aurions pu trouver tous les éléments ci-dessous : 

$ cat ~/.eaf/eaf.options
--debug

La dernière version proposée pour une distribution RPM est ancienne et largement plus que pour les distributions debian like. Nous allons donc utiliser alien pour regénérer la toute dernière version pour RPM

alien InstallG2SeBeeAccessFoundationLinux-amd64.rpm

Avantage de ce passage par alien, nous obtenons un paquet correctement nommé incluant la version : ebeeaccessfoundation-1.1.0-2.x86_64.rpm. Hourra ! Paquet que nous installons.

zypper in ebeeaccessfoundation-1.1.0-2.x86_64.rpm

Inconvénient de ce package, parce qu’il a été conçu pour une autre distribution, la gestion des dépendances est défectueuse et il faut installer en plus une version beaucoup plus ancienne de la librairie libp11 (couche de simplification de la gestion PKCS11) : libp11-2-0.2.8-26.1.x86_64.rpm.

Les galères ne s’arrêtent pas là dans la gestion des dépendances. Il manque également à l’appel certutil, utilitaire de gestion des certificats mais aussi libnotify-tool et libnotify qui permettent la gestion des notifications sur le bureau. On installe donc tout ça.

zypper in libnotify4 libnotify-tools libp11-2 mozilla-nss-certs 

Terminé ? Eh non ! On n’a traité que les dépendances de paquets logiciels. Il nous manque encore quelques détails qui ont mis un peu de piquant dans nos tests. eBeeAccessFoundation propose un fichier json explicitant les dépendances requises : on retrouve la libp11-2 et la clé Gemalto IDGO

{ 
        "originsAllowed": [ 
...
                "e-aa.avocat.fr:443", 
...
        ], 
        "ports": { 
                "http": 5000, 
                "https": 5443, 
                "range": 100 
        }, 
        "useCleyris": false, 
        "debug": true, 
        "libs": { 
                "middleware": { 
...
                        "gemalto-idgo": "/usr/lib/pkcs11/libidprimepkcs11.so", 
...
                }, 
                "ssl": "libssl", 
                "opensc": "libp11.so.2" 
        }

Le service d’Almerys recherche explicitement la librairie /usr/lib/pkcs11/libidprimepkcs11.so. Or l’installation du package Gemalto fournit  /usr/lib/pkcs11/libIDPrimePKCS11.so… Eh oui, on apprend très tôt que les systèles de fichiers sous Linux sont sensibles à la casse. Donc en l’état impossible de communiquer avec la clé. On ajoute donc un lien symbolique : 

ln -s /usr/lib/pkcs11/libIDPrimePKCS11.so /usr/lib/pkcs11/libidprimepkcs11.so

C’est presque terminé ! Il nous manque un dernier lien. Eh oui la dépendance sur la librairie libssl n’existe pas… Il faut donc là aussi créer un lien :

ln -s /usr/lib64/libssl.so.1.0.0 /usr/lib64/libssl.so

Le service est maintenant complètement fonctionnel concernant les 2 objectifs que nous nous étions fixé.

Et maintenant ?

Les objectifs que nous nous étions fixés sont atteints. Il est possible de se connecter facilement à e-barreau avec la clé RPVA et procéder à des signatures électroniques certifiées.

Restent quand même pas mal d’interrogations sur la maintenance et le support proposés sur ce type de périphériques de sécurité : mises à jour aléatoires, mise à disposition compliquée, intégration plus que contestable, pas d’information directe sur ces mises à jour… Nous travaillons à fournir un paquet pour Almerys fonctionnel qui ne nécessite pas toutes les étapes suivies ci-dessus.

La suite au prochain numéro !