Retrouvez cet article dans : Linux Magazine 88

Nous venons de voir dans le précédent article comment installer lecteur et middleware afin de pouvoir tirer parti des smartcards sous GNU/Linux. Voyons, à présent, tous les avantages que cela nous apporte.Comme dit précédemment, il existe plusieurs types de smartcards. Bien que la manière de dialoguer avec elles soit en grande partie commune, il n’en va pas de même pour leur contenu. En effet, la carte SIM de votre téléphone mobile est une smartcard, tout comme votre carte bancaire, votre carte Vitale et peut-être même la carte d’abonnement à votre vidéoclub (ça existe encore les vidéoclubs ?). Les cartes qui nous intéressent dans cet article orienté " utilisation " sont celles permettant d’accueillir une structure PKCS#15. L’eToken PRO 64k d’Aladdin, la Cryptoflex 32k d’Axalto ou le CryptoIdentity d’Eutron en sont quelques exemples. Nous utiliserons les outils mis à disposition par le projet OpenSC. Il faut donc que la carte utilisée soit l’une de celles spécifiées sur la page officielle du projet (www.opensc-project.org). A partir d’ici, je considère que votre installation PS/SC Lite et/ou OpenCT/OpenSC est configurée et fonctionnelle.

Rappel à propos de d’SSL/TLS

Le protocole SSL (Secure Socket Layer) est un protocole développé à l’origine par Netscape. La première version n’a jamais été éditée. Seul SSL v2 a été publiquement diffusé en 1994. La version utilisée actuellement est la 3. Le développement de SSL est maintenant à la charge de l’IETF (Internet Engineering Task Force) et en particulier du groupe TLS (Transport Layer Security). TLS est maintenant une norme. TLS v1.0, datant de 1999, présente simplement quelques améliorations par rapport à SSL v3. Voilà pour ce qui est de l’historique. SSL/TLS se place entre TCP/UDP et la couche application et permet de sécuriser (authentifier les intervenants et chiffrer la communication) des protocoles non sûrs et donc circulant en clair (HTTP, FTP, POP3, etc.). SSL/TLS se divise grossièrement en deux. D’une part, nous avons l’élément Record chargé de chiffrer les communications avec un algorithme symétrique et de contrôler d’intégrité des données (via une fonction de hachage cryptographique HMAC).

D’autres part, nous avons l’élément Handshake chargé de l’authentification des intervenants et de la négociation de la clef de session. L’authentification, et c’est là que nous rejoignons PKCS#15 et les smartcards, peut être faite via des certificats au format X.509. L’implémentation en Logiciel libre la plus connue de SSL/TLS est OpenSSL. Prenant la forme de bibliothèques partagées et d’utilitaires, OpenSSL est également la base de bon nombre de projets dérivés importants comme OpenSSH (le secure Shell) ou mod_ssl (module HTTPS pour Apache). Le modèle d’authentification utilisé par SSL/TLS va à l’opposé de celui de PGP/GPG. Il ne s’agit pas ici de construire un réseau de confiance où l’on compte sur l’avis de chaque utilisateur pour s’assurer de l’identité de chacun. SSL/TLS repose sur le concept d’autorité de certification, autorité toute puissante s’assurant de l’authenticité des intervenants et se portant garante de leur identité. A l’instar du réseau de confiance cher à PGP/GPG, le principe d’authentification SSL/TLS utilise un algorithme de chiffrement asymétrique. Rappelons-en brièvement le principe. Une clef dite " publique " est connue de tous et permet de chiffrer. La clef sœur, dite " privée ", sera la seule à permettre de déchiffrer les cryptogrammes ainsi générés. Le principe de signature consiste à créer un condensé d’un message et de le chiffrer avec sa clef privée. L’authenticité du message est vérifiée en comparant le condensé du message reçu avec le condensé l’accompagnant, préalablement déchiffré à l’aide de la clef publique. Si les deux condensés sont identiques, le message est authentique et son intégrité est garantie. Le mécanisme de signatures électroniques peut également s’appliquer aux clefs elles-mêmes. Pour affirmer l’authenticité d’une clef publique, il suffit de la signer. A la différence de PGP/GPG, ce ne sont pas les utilisateurs eux-mêmes qui signent les clef publiques, mais une autorité de certification (AC ou CA en anglais). Une clef publique signée par une autorité de certification et accompagnée d’un certain nombre de métadonnées est appelée " un certificat " (Cert). Cette même clef dans sa version non signée est une demande de certificat (CR pour Certificate Request ou req). Le certificat de l’autorité de certification est auto-signé. Le schéma ci-contre résume le fonctionnement :

• 1. L’utilisateur souhaitant disposer d’un certificat (clef publique + métadonnées) et d’une clef privée correspondante génère une demande de certificat dans un format acceptable par l’autorité de certification (AC).

• 2. La demande de certificat est transmise à l’autorité de certification qui s’assure de la correspondance entre la demande et le demandeur. C’est le point central du mécanisme. L’AC est tenu de faire ce travail, car elle se porte garante. Elle certifie que le certificat correspond bien à une personne ou un serveur. Cette vérification faite et toutes les dispositions prises, elle signe la demande et la transforme en véritable certificat. Notez qu’il arrive souvent que l’AC génère elle-même la paire de clefs (privée/publique) et la demande de certificat. Personnellement, je ne vois pas d’un très bon Å“il le fait que quelqu’un d’autre que moi ait eu accès à ma clef privée, quand bien même ce serait un tiers de confiance.
• 3. La clef publique de l’AC est disponible pour tous. Elle est présente dans son certificat auto-signé et est libre d’accès. Chacun peut donc très facilement vérifier le certificat d’une personne ou d’un serveur en vérifiant la signature de l’AC. Certaines AC sont si importantes (ou du moins possèdent suffisamment de pouvoir) qu’elles trouvent leur certificat dans la configuration de la plupart des navigateurs Web. Ainsi, l’utilisateur n’a pas de message à l’écran lui demandant s’il fait confiance au sérieux de telle ou telle AC.

• 4. Si l’on souhaite envoyer un message chiffré au propriétaire du certificat, on peut utiliser sa clef publique. Elle est sûre, puisque nous avons la garantie qu’elle appartient bien au destinataire. L’AC se porte garante de la correspondance.
• 5. Le propriétaire du certificat, possédant la clef privée, sera le seul à pouvoir déchiffrer le message et le lire.

Autre point important, certaines AC sont si massives qu’elles sont obligées de déléguer une partie de leurs responsabilités. Ainsi, elles peuvent " franchiser " d’autres AC. On parle alors d’AC racine pour celle qui supervise l’ensemble. Celle-ci délivre des certificats d’un type particulier permettant de signer des demandes pour les utilisateurs. En obtenant un certificat d’une AC, vous ne pouvez pas, vous-même, signer une demande de certificat, à moins, bien sûr, que l’AC racine fasse de vous une AC.

Initialisation de la carte

Comme précisé plus haut, je pars du principe que tout fonctionne, que vous utilisiez OpenSC sur PC/SC ou par-dessus OpenCT. Dans le cas présent, le matériel de démonstration est un eToken PRO 64 k confié temporairement à nos soins par le fabricant. Une smartcard ou un token tels que supportés par les outils OpenSC doivent être en mesure de contenir des données. Cet espace mémoire de la puce doit être initialisé avec une arborescence spécifique pour répondre au standard PKCS#15. Notez que le support logiciel de certains fabricants (dont Aladdin) n’est pas compatible PKCS#15. Il n’y aura donc aucune compatibilité possible entre les deux supports logiciels. Pour assurer une compatibilité d’un OS à l’autre, soit vous utilisez le support propriétaire du fabricant sous Linux s’il existe, soit vous utilisez OpenSC ou une autre implémentation compatible PKCS#15 sous Windows ou Mac OS.

% pkcs15-init -ECT
New Security Officer PIN (Optional - press return for no PIN).
Please enter Security Officer PIN:

Les trois options servent respectivement :

• à effacer le contenu de la mémoire de la carte ;
• à créer une arborescence PKCS#15 dans cette mémoire ;
• à forcer l’utilisation de la clef de transport de la carte. Cette clef spécifique est connue par les outils OpenSC, en fonction de la carte en présence. Elle permet d’effacer la carte et de réinitialiser le SO-PIN (voir ci-après). L’option T permet de forcer l’utilisation de cette clef lorsqu’elle est nécessaire, et ce, même si le pilote ou le lecteur pense l’avoir en cache.

Qui dit " smartcard et token ", dit " code PIN " (Personal Identity/Identification Number). Ne cherchez pas, c’est exactement la même chose que ce qui protège la carte SIM de votre mobile (qui est d’ailleurs une smartcard). La différence tient dans le fait que le code PIN d’un eToken, d’une Cryptoflex ou d’une OpenPGP Card peut être non numérique et faire bien plus de 4 caractères. Le Security Officer PIN (ou SO-PIN) qui vous est demandé est optionnel. L’officier de sécurité dont il est question est une personne habilitée à ajouter et supprimer des couples certificat/clef privée de la smartcard, mais pas à les utiliser. La première étape, à présent que la carte est effacée et formatée, est d’ajouter un minimum de sécurité et donc de définir immédiatement un code PIN :

% pkcs15-init -PT -a 1 -l denis -v
Connecting to card in reader Aladdin eToken PRO 64k...
Using card driver Siemens CardOS.
Found OpenSC Card
About to store PIN.
New User PIN.
Please enter User PIN: ****
Please type again to verify: ****
Unblock Code for New User PIN (Optional - press return for no PIN).
Please enter User unblocking PIN (PUK): ****
Please type again to verify: ****

L’option P permet de créer un nouveau code PIN. -a permet de préciser l’ID du code PIN à créer et -l un label pour cet ID. Classiquement, -v rend l’outil plus bavard. Comme nous sommes des gens consciencieux, nous vérifions que l’objet a bien été créé sur la carte :

 % pkcs15-tool --list-pins
PIN [denis]
  Com. Flags: 0x3
  ID        : 01
  Flags     : [0x32], local, initialized, needs-padding
  Length    : min_len:4, max_len:8, stored_len:8
  Pad char  : 0x00
  Reference : 1
  Type      : ascii-numeric
  Path      : 3f005015

Attention ! Certaines cartes ou tokens arrivent avec un code PIN ou un PUK prédéfini. Lisez la documentation de votre produit ! Dans bien des cas, trois codes PIN erronés entraînent un blocage du code. Il faut alors utiliser le code PUK pour débloquer et créer un nouveau code PIN. Trois tentatives d’utilisation du code PUK menant à un échec bloquent définitivement la quasi-totalité des cartes. Pour débloquer un code PIN, il faut utiliser pkcs15-tool -u et suivre les indications.

Installation des clefs et certificats

Pour que la smartcard soit utile, il faut qu’elle contienne une ou plusieurs clefs privées et un ou plusieurs certificats correspondants. Deux solutions existent pour créer la base de travail : la paire privée/publique de clef.

Génération par la smartcard

La première solution consiste à utiliser les fonctionnalités de génération de clef de la smartcard. Le principal avantage est de générer une clef privée sans qu’à aucun moment celle-ci ne transite par l’ordinateur. Une clef générée de la sorte est habituellement marquée comme non exportable. Le revers de la médaille est que la destruction de la carte, délibérée ou non, forcera la révocation des certificats, puisque la clef privée est définitivement perdue. Pour ce faire, nous utilisons l’option -G ou --generate-key suivie du type de clef demandée. Pour l’heure, seule la valeur RSA est possible. On associe cette paire de clefs à l’ID du PIN nouvellement créé :

% pkcs15-init -G RSA -a 1 -v -u sign,decrypt --split-key
Connecting to card in reader Aladdin eToken PRO 64k...
Using card driver Siemens CardOS.
Found OpenSC Card
About to generate key.
User PIN required.
Please enter User PIN: ****

Notez l’utilisation de l’option --split-key. Ceci répond à une fonctionnalité souvent intégrée aux smartcards qui prévoit une sécurité renforcée en n’autorisant pas une même clef privée à être utilisée pour le chiffrement et la signature. Dans ce cas et grâce à cette option, la clef privée sera présente deux fois sur la carte avec un label d’utilisation différent et un numéro d’objet unique. Le label d’utilisation est spécifié avec l’option -u. Les arguments utilisés ici sont des alias, vous pouvez en apprendre davantage en utilisant la commande pkcs15-init -u help. La commande pkcs15-tool permet de lister les clefs publiques et privées présentes dans la carte :

 % pkcs15-tool --list-keys
Private RSA Key [Private Key]
  Com. Flags  : 3
  Usage       : [0x22], decrypt, unwrap
  Access Flags: [0x1D], sensitive,
      alwaysSensitive, neverExtract, local
  ModLength   : 1024
  Key ref     : 16
  Native      : yes
  Path        : 3f005015
  Auth ID     : 01
  ID          : 45
Private RSA Key [Private Key]
  Com. Flags  : 3
  Usage       : [0x20C], sign, signRecover,
      nonRepudiation
  Access Flags: [0x1D], sensitive,
      alwaysSensitive, neverExtract, local
  ModLength   : 1024
  Key ref     : 17
  Native      : yes
  Path        : 3f005015
  Auth ID     : 01
  ID          : 45
% pkcs15-tool  --list-public-keys
Public RSA Key [Public Key]
  Com. Flags  : 2
  Usage       : [0x4], sign
  Access Flags: [0x0]
  ModLength   : 1024
  Key ref     : 0
  Native      : no
  Path        : 3f0050153048
  Auth ID     :
  ID          : 45

Certaines options permettent de définir des comportements spécifiques. C’est le cas, par exemple, de l’option --extractable permettant de spécifier que la privée peut être extraite de la smartcard. --insecure porte bien son nom, car elle retire l’obligation de spécifier le code PIN protégeant la clef. Ceci peut s’avérer utile, par exemple, avec OpenSSH non patché (voir plus loin) ou encore le module mod_ssl pour Apache (le code PIN est demandé au démarrage du serveur dans le cas contraire). L’étape suivante consiste à créer un certificat intégrant la clef publique. Les outils OpenSC ne permettent pas de la faire directement. Il faut utiliser la commande openssl et un module spécifique permettant à la commande de dialoguer avec la smartcard. Ce module est un Engine OpenSSL, sorte de greffon chargeable dynamiquement permettant d’ajouter des fonctionnalités cryptographiques supplémentaires à la commande. Le module en question ici est une implémentation du standard PKCS#11. Ce standard est à la communication avec smartcard ce que PS/SC est à l’accès aux lecteurs, une API unifiée et normalisée de communication. Avec une distribution Debian, ce module peut être installé via le paquet libengine-pkcs11-openssl. Notez qu’un module libopensc-openssl semble remplir le même office, mais n’est compatible qu’avec la version 0.9.6 de la bibliothèque OpenSC (c’est ce qu’annonce le système de paquet Debian qui tentera de désinstaller libopensc2 et opensc lors de l’installation). Tout se fait dans openssl. Tout d’abord, on charge le module (pensez à vous assurer de la validité des chemins) :

% openssl
OpenSSL> engine dynamic -pre \
  SO_PATH:/usr/lib/engines/engine_pkcs11.so \
  -pre ID:pkcs11 -pre LIST_ADD:1 -pre LOAD \
  -pre MODULE_PATH:opensc-pkcs11.so
(dynamic) Dynamic engine loading support
[Success]: SO_PATH:/usr/lib/engines/engine_pkcs11.so
[Success]: ID:pkcs11
[Success]: LIST_ADD:1
[Success]: LOAD
[Success]: MODULE_PATH:opensc-pkcs11.so
Loaded: (pkcs11) pkcs11 engine

On peut ensuite accéder à la clef privée de la smartcard et générer un certificat auto-signé :

OpenSSL> req -engine pkcs11 -new -key id_45 \
  -keyform engine -out cert.pem -text -x509
engine "pkcs11" set.
PKCS#11 token PIN: ****
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Alsace
Locality Name (eg, city) []:Colmar
Organization Name (eg, company) [Internet Widgits Pty Ltd]:GLMF
Organizational Unit Name (eg, section) []:.
Common Name (eg, YOUR name) []:Denis Bodor
Email Address []:lefinnois@lefinnois.net

Nous obtenons le fichier cert.pem. On peut également générer une demande de certificat plutôt qu’un certificat auto-signé en n’utilisant pas l’option -x509. On nous demande alors des informations complémentaires :

Please enter the following ‘extra’ attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Il suffira ensuite de faire signer notre demande par l’autorité de certification qui nous retournera ensuite notre certificat. La dernière étape consiste à charger le certificat dans la smartcard :

% pkcs15-init -X cert.pem -v -a 1
Connecting to card in reader Aladdin eToken PRO 64k...
Using card driver Siemens CardOS.
Found OpenSC Card
About to store certificate.
User PIN required.
Please enter User PIN: ****

Encore une fois, on s’assure que la manipulation a réussi :

% pkcs15-tool -c
X.509 Certificate [Certificate]
  Flags    : 2
  Authority: no
  Path     : 3f0050153149
  ID       : 45

Génération externe

L’autre solution consiste à générer une paire de clef sur l’ordinateur et à importer la clef publique et la clef privée sur la smartcard. La sécurité de la clef privée peut être en péril. Introduction d’un rootkit ou compromission du système avant la génération de la clef, analyse des disques après leur vol, Tempest... les risques existent. Contrebalançant les risques, la génération des deux clefs permet la mise en réserve sécurisée d’une copie afin de pallier d’éventuels problèmes matériels. Pour procéder de la sorte, cela revient d’abord à utiliser la commande openssl de manière tout à fait classique. On commence donc par générer très simplement la paire de clef et le certificat auto-signé. Là encore, il est tout à fait possible de ne créer qu’une demande de certificat qu’on fera signer par l’AC :

% openssl req -newkey rsa:2048 -keyout moi.key -out moi.crt -text -x509
Generating a 2048 bit RSA private key
...............+++
......................+++
writing new private key to ‘moi.key’
Enter PEM pass phrase:******
Verifying - Enter PEM pass phrase:*******
-----
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter ‘.’, the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Alsace
Locality Name (eg, city) []:Colmar
Organization Name (eg, company) [Internet Widgits Pty Ltd]:GLMF
Organizational Unit Name (eg, section) []:.
Common Name (eg, YOUR name) []:Denis Bodor
Email Address []:lefinnois@lefinnois.net

Remarquez que nous spécifions ici une clef RSA de 2048 bits. Celle-ci sera parfaitement gérée par un eToken PRO 64 k, mais pas nécessairement par la smartcard que vous aurez choisie. Pensez à vérifier la documentation et utiliser, au besoin, une clef de 1024 bits. Suite à l’utilisation de cette commande, nous disposons d’un fichier contenant la clef privée (moi.key) et le certificat contenant la clef publique associée (moi.crt). Il ne nous reste plus qu’à charger les deux dans la carte :

% pkcs15-init -S moi.key -a 1 -u sign,decrypt --split-key
Please enter passphrase to unlock secret key: ******
User PIN required.
Please enter User PIN: ****
% pkcs15-init -X moi.crt -v -a 1
Connecting to card in reader Aladdin eToken PRO 64k...
Using card driver Siemens CardOS.
Found OpenSC Card
About to store certificate.
User PIN required.
Please enter User PIN: ****

Remarquez que la phrase de passe protégeant la clef privée est demandée juste avant le code PIN ouvrant l’accès à la smartcard. Le fichier moi.key DOIT être mis en sécurité. Vous pouvez le stocker sur une clef USB ou tout simplement l’imprimer avant de le supprimer de la machine en utilisant un outil comme wipe.

Utilisation

Enfin, tout est prêt pour passer à l’utilisation directe de votre smartcard. Comme vous allez le voir, le support n’est pas toujours complet dans toutes les applications, mais il existe toujours des solutions.

OpenSSH

C’est sans doute là la première application qui vient à l’esprit, pouvoir se connecter à distance sur une machine et pouvoir avoir toujours sur soi la clef privée prouvant son identité. Bien entendu, ceci impose d’avoir un lecteur de carte et un middleware configuré et fonctionnel. Le support des smartcards n’est pas complet dans la version officielle d’OpenSSH. Il existe un moyen de contourner le problème et également plusieurs patchs apportant des corrections ou des fonctionnalités supplémentaires. Lisez cette partie de l’article entièrement avant d’expérimenter. La version d’OpenSSH telle que livrée par Debian n’est pas compilée avec le support des smartcards. Profitons-en pour signaler que Debian est en pleine transition au niveau d’SSH et remplace peu à peu toutes les dépendances avec le paquet ssh vers les paquets openssh-client et/ou openssh-server. Il vous faudra donc, dans un premier temps, de toute façon recompiler un client OpenSSH afin d’activer une option de compilation spécifique (essayez à tout hasard l’option -I 0, si le message no support for smartcards s’affiche, la suite des opérations est évidente). Voici la procédure pour une distribution Debian ou compatible. Par défaut, et officiellement, OpenSSH est compatible avec le middleware OpenSC. Commençons donc par installer le nécessaire pour reconstruire un paquet binaire openssh-client avec (en root) :

% apt-get build-dep openssh-client
% apt-get install libopensc2-dev libopenct1-dev

Nous récupérons ensuite les sources avec :

 % apt-get source openssh-client

Dans le répertoire nouvellement créé, éditez debian/rules, puis cherchez l’entrée build-deb-stamp (la syntaxe du fichier est celle d’un Makefile). Parmi les options déjà passées au script configure, ajoutez simplement --with-opensc. Enregistrez les modifications, quittez l’éditeur (Vim sans doute) et lancez la construction des paquets binaires :

% dpkg-buildpackage -b -rfakeroot

Faites-vous une chicorée pendant la compilation (c’est optionnel), puis installez le nouveau paquet (en root) :

% cd ..
% dpkg -i openssh-client_4.3p2-3_i386.deb

Enfin, pour procéder au premier test localement, récupérez la clef publique de la smartcard au format SSH et ajoutez-la au fichier d’autorisation :

% pkcs15-tool --read-ssh-key 45 | \
  grep ssh-rsa >> ~/.ssh/authorized_keys

45 est ici l’ID de la clef qui apparaît lorsqu’on liste les clefs publiques avec pkcs15-tool --list-public-keys. Enchaînez immédiatement avec le premier essai :

% ssh -I 0 localhost
card-cardos.c:225:cardos_check_sw:
  required access right not granted
card-cardos.c:746:do_compute_signature:
  returning with: Security status not satisfied
sec.c:53:sc_compute_signature: returning with:
  Security status not satisfied
pkcs15-sec.c:331:sc_pkcs15_compute_signature:
  sc_compute_signature() failed:
  Security status not satisfied
sc_pkcs15_compute_signature() failed:
  Security status not satisfied
ssh_rsa_sign: RSA_sign failed:
  error:00000000:lib(0):func(0):reason(0)
Password:

Boum ! Le client SSH vient de rencontrer une erreur et se rabat sur l’authentification par mot de passe. Jetez furieusement la tasse de chicorée à travers la pièce, puis lisez la suite (je vous avais bien dit de tout lire avant). Le problème vient du code PIN qui protège votre clef privée sur la smartcard. Le client SSH ne vous l’a pas demandé et la carte lui refuse l’accès, d’où les différents messages qui deviennent parfaitement clairs. Un patch, certes un peu barbare, a plusieurs fois été proposé aux développeurs, mais le problème est toujours là. La solution consiste donc à appliquer nous-même ce patch. Celui-ci est présent dans les sources des outils OpenSC. Récupérez-les avec apt-get source opensc. Retournez ensuite dans le répertoire des sources du paquet d’OpenSSH et appliquez le patch...

% patch -p1 < \
 ../opensc-0.11.1/src/openssh/ask-for-pin.diff
patching file scard.c
patching file scard.h
patching file scard-opensc.c
patching file ssh.c
Hunk #1 succeeded at 1187 (offset -29 lines).

...et reconstruisez à nouveau le paquet binaire (vous avez droit à une seconde chicorée). Cette fois, plus de problème :

% ssh -I 0 localhost
Enter PIN for Private Key: ****
No mail.
Last login: Sat Aug 26 17:36:08 2006 from :0.0

Note La clef privée ne sort jamais de la smartcard. Le code PIN est demandé non pas pour obtenir directement la clef, mais pour l’utiliser. C’est la smartcard qui procèdera elle-même aux opérations de chiffrement, déchiffrement, signatures, répondra aux challenges, etc. Un autre patch est disponible reposant, quant à lui, non pas sur OpenSC, mais sur l’API générique PKCS#11. Ce patch, disponible sur http://alon.barlev.googlepages.com/openssh-pkcs11 s’appliquera sur les sources d’OpenSSH comme le précédent. Il ne sera pas nécessaire de modifier le fichier rules Debian, par défaut l’option de compilation sera activée. Vous devrez également récupérer, sur la page du nouveau patch, un script permettant à l’agent SSH de demander le code PIN. Vous aurez le choix entre des scripts pour Gnome, KDE, .NET et la console. Une fois la nouvelle version binaire du client SSH installée et le script copié, procédez comme suit : Démarrez l’agent SSH dans une console en utilisant l’option de debogage -d :

% ssh-agent -d
SSH_AUTH_SOCK=/tmp/ssh-xJtJT29063/agent.29063;
export SSH_AUTH_SOCK;
echo Agent pid 29063;

Dans une autre console, déclarez les variables d’environnement copiées de la sortie fournie par ssh-agent :

% SSH_AUTH_SOCK=/tmp/ssh-xJtJT29063/agent.29063;
% export SSH_AUTH_SOCK;

Enfin, configurez l’agent avec ssh-add :

% ssh-add --pkcs11-ask-pin \
  /usr/local/bin/openssh-console-dialogs.sh
Success
% ssh-add --pkcs11-add-provider \
  --pkcs11-provider /usr/lib/opensc-pkcs11.so
Provider /usr/lib/opensc-pkcs11.so added successfully
% ssh-add --pkcs11-add-id --pkcs11-slot-type id \
  --pkcs11-slot 0 --pkcs11-id-type id \
  --pkcs11-id 45
Identity added successfully

La première commande spécifie le script à utiliser. La seconde charge le pilote PKCS#11 (ici, celui d’OpenSC). Enfin, la dernière commande ajoute une nouvelle identité en utilisant l’emplacement 0 (le token n’en a qu’un, comme beaucoup de lecteurs) et l’identifiant 45 (l’ID de la clef). Les commandes vous permettant respectivement de connaître l’emplacement (slot) et l’identifiant à utiliser sont :

% ssh-add --pkcs11-show-slots \
  --pkcs11-provider /usr/lib/opensc-pkcs11.so
% ssh-add --pkcs11-show-objects \
  --pkcs11-provider /usr/lib/opensc-pkcs11.so
  --pkcs11-slot 0

Ceci fait, vous pourrez utiliser la commande ssh comme à l’habitude. Le code PIN sera demandé sur la console où a été lancé ssh-agent :

debug1: type 11
debug1: type 13
OpenSSH: Please enter PIN for token
  ‘OpenSC Card (denis)’: (cancel) ****

Ce n’est certes pas très élégant, mais ça fonctionne. Les scripts permettant une demande graphique du code PIN n’ont pas été testés dans le cadre de cet article. Il est assez surprenant de constater que la commande ssh elle-même n’est pas affectée par le patch et c’est bien dommage. Bien que l’agent SSH soit utilisé par un nombre non négligeable d’utilisateurs, c’est bien souvent en ligne de commande que les connexions SSH sont établies (c’est un shell après tout) et le script destiné à la console manque d’ergonomie par rapport au minuscule premier patch évoqué. A vous, à présent, de choisir la solution qui vous semble la plus intéressante. Notez enfin que vous pouvez également générer les clefs sur la smartcard (voir plus haut) avec l’option --insecure. Dans ce cas précis, comme le code PIN n’est plus nécessaire pour utiliser la clef privée, aucun patch n’est nécessaire et l’option de compilation --with-opensc suffit.

Apache et Firefox

Lorsqu’on parle de SSL et de certificats, c’est bien souvent en relation avec la mise en œuvre d’un serveur Web et du protocole HTTPS (HTTP over SSL). Ceci permet de chiffrer la communication et de s’assurer de l’identité du serveur. Moins connu, cela permet également au serveur Web de s’assurer de l’identité du client qui présentera un certificat conforme. Bien entendu, dans le cas présent, celui-ci sera présent sur la smartcard et non sur la machine cliente. La première étape de cette double mise en œuvre consiste à installer un serveur Apache 2 supportant SSL. Pour expérimentation, nous commençons donc par créer une autorité de certification. Il est également possible de reposer sur une autorité externe. Générons donc, tout d’abord, un certificat et une clef privée pour l’AC :

% openssl req -x509 -newkey rsa:1024 \
-days 3650 -keyout ca.pem -out ca.crt

Nous obtenons ainsi les fichiers ca.pem et ca.crt qui sont respectivement la clef privée de l’AC et son certificat auto-signé. On s’attache ensuite à créer une clef privée et une demande de certificat pour notre serveur Web :

% openssl req -newkey rsa:1024 -days 3650 \
-keyout serveur.pem -out serveur.req

Attention ! Le CN (Common Name) doit être le FQDN (Full Qualified Domain Name) du serveur Web. L’étape suivante, comme vous vous en doutez est la signature de la demande de certificat par l’AC :

% openssl x509 -req -in serveur.req \
-out serveur.crt -sha1 -CA ca.crt \
-CAkey ca.pem -CAcreateserial -days 3650

Nous obtenons ainsi un fichier serveur.crt qui est le véritable certificat du serveur Web. Nous copions ensuite les fichiers nécessaires dans un emplacement accessible par le serveur Web :

% sudo cp serveur.crt serveur.pem \
ca.crt /etc/apache2/ssl

Tout est prêt pour la configuration du serveur. Commencez donc par activer mod_ssl. Notez que dans la distribution Debian, le module n’est pas disponible sous la forme d’un paquet indépendant, mais directement intégré dans le paquet apache2-common. Il n’en va peut-être pas de même avec votre distribution GNU/Linux :

% cd /etc/apache2/mods-enabled
ln -s ../mods-available/ssl.load ssl.load
ln -s ../mods-available/ssl.conf ssl.conf

Ajoutez ensuite Listen 443 dans ports.conf afin que le serveur soit à l’écoute du port traditionnellement associé au protocole HTTPS. Enfin, mais c’est à adapter en fonction de votre infrastructure Web, créez un nouveau fichier sites-available/ssl (le nom importe peu). Ce fichier contiendra :

NameVirtualHost *:443
<VirtualHost *:443>
<IfModule mod_ssl.c>
  SSLEngine on
  SSLCACertificateFile   /etc/apache2/ssl/ca.crt
  SSLCertificateFile     /etc/apache2/ssl/serveur.crt
  SSLCertificateKeyFile  /etc/apache2/ssl/serveur.pem
</IfModule>
DocumentRoot /var/www/ssl
<Directory />
  Options Indexes FollowSymLinks MultiViews
  AllowOverride None
  Order allow,deny
  allow from all
</Directory>
ErrorLog /var/log/apache2/SSLerror.log
LogLevel warn
CustomLog /var/log/apache2/SSLaccess.log combined
ServerSignature On
</VirtualHost>

Bien entendu, ce n’est ici qu’un exemple. Les directives importantes sont :

• SSLEngine on permettant d’activer le moteur SSL pour cet hôte virtuel associé au port 443 ;
• SSLCACertificateFile qui désigne le fichier contenant le certificat de l’AC ;
• SSLCertificateFile qui précise le certificat du serveur ;
• SSLCertificateKeyFile qui renseigne sur le fichier contenant la clef privée sÅ“ur du certificat.

Il ne vous reste plus qu’à démarrer ou redémarrer le serveur Apache : La phrase de passe qui vous est demandée est celle protégeant le fichier de clef privée. Elle vous sera demandée à chaque démarrage d’Apache, ceci incluant le boot de la machine.

# /etc/init.d/apache2 start
Starting apache 2.0 web server...Apache/2.0.55 mod_ssl/2.0.55 (Pass Phrase Dialog)
Some of your private key files are encrypted for security reasons.
In order to read them you have to provide us with the pass phrases.
Server raven.lefinnois.net:443 (RSA)
Enter pass phrase: *******
Ok: Pass Phrase Dialog successful.

Cette état de fait peut être problématique, car la demande est bloquante et nécessitera une intervention à chaque redémarrage du serveur (et sur la plupart des systèmes à chaque rotation de log). On sait parfaitement que l’uptime d’un serveur GNU/Linux (ou BSD*) peut se compter en années, mais il est important de prendre cela en considération sur un serveur en production. Il existe plusieurs solutions pour éviter cela, mais aucune n’est applicable sans retirer une part de la sécurité offerte par cette demande systématique. La configuration, jusqu’ici, est celle classiquement utilisée pour créer un serveur HTTPS. Vous pouvez d’ores et déjà vous connecter au serveur Apache et vérifier le bon fonctionnement de l’ensemble. Un message d’avertissement vous signale que l’autorité de certification est inconnue et que le certificat serveur n’est peut-être pas de confiance. Vous pouvez régler le problème, tout simplement en important le certificat de l’AC dans le navigateur. Dans le cas de Firefox, vous pouvez importer le certificat au format PEM (tel que produit par défaut par openssl) via les préférences du navigateur.

Penchons-nous maintenant sur le côté client. Encore une fois, générons une demande de certificat et sa clef privée :

% openssl req -newkey rsa:1024 -days 3650 \
-keyout client.pem -out client.req

Empressons-nous ensuite de charger la clef privée dans la smartcard comme nous l’avons déjà fait précédemment :

% pkcs15-init -S client.pem -a 1 \
-u sign,decrypt --split-key

L’autorité de certification (nous-même pour les essais) signe ensuite la demande :

% openssl x509 -req -in client.req \
-out client.crt -sha1 -CA ca.crt \
-CAkey ca.pem -CAcreateserial -days 3650

Enfin, chargeons le certificat signé dans la smartcard :

% pkcs15-init -X client.crt -v -a 1

Notre smartcard est maintenant prête. Dernière opération pour le client et son navigateur, renseigner Firefox sur la façon d’accéder aux informations. Il nous suffit d’utiliser le pilote PKCS#11 fourni par OpenSC tout comme nous l’avons fait pour openssl précédemment. C’est dans les préférences que nous trouverons un bouton " Périphériques de sécurité ". Là également, nous pouvons décider si Firefox décidera seul du certificat à utiliser ou s’il nous demandera notre avis à chaque fois.

Après avoir cliqué sur le bouton, on remarquera qu’il existe déjà un certain nombre de modules chargés. Ce sont les modules internes de Firefox permettant d’utiliser un certificat stocké localement et non sur une smartcard.

Pour prendre en charge le middleware et donc l’accès à la smartcard, il nous suffira de charger la bibliothèque partagée opensc-pkcs11.so qui n’est autre que notre pilote PKCS#11.

Dès chargement, on voit immédiatement apparaître les informations concernant notre eToken utilisé pour les essais.

Notez que Firefox a tout d’abord refusé de chargé le module pour une raison qui m’échappe, puis, subitement, après avoir quitté et relancé l’application, tout s’est déroulé normalement. Ce comportement étrange n’a pas pu être reproduit par la suite. A ce stade, notre navigateur est prêt et nous changeons alors la configuration du serveur. Il nous suffit d’ajouter une simple directive pour demander un certificat signé de notre AC de la part du client et accepter ou non la connexion en fonction de sa vérification :

SSLVerifyClient   require

Dès que le navigateur tentera de se connecter au serveur, la demande de certificat sera faite et Firefox tentera d’accéder à la smartcard. De ce fait, une boîte de dialogue nous demandera le code PIN :

Si nous avons demandé une sélection manuelle du certificat, Firefox nous présentera une nouvelle fenêtre :

Dès le choix validé, nous obtenons la page Web souhaitée. Client et serveur sont sûrs de leur identité respective et la communication sera chiffrée avec une clef de session partagée négociée. Cette partie de l’article est destinée à détailler l’utilisation d’une smartcard, et non celle d’une gestion complète de certificats. J’ai donc pris quelques raccourcis afin d’éviter de décrire la mise en œuvre d’une gestion complète. Si vous souhaitez gérer un grand nombre de certificats, leur signature et leur révocation, il vous faudra configurer OpenSSL via /etc/ssl/openssl.conf et mettre en place une arborescence spécifique. Vous serez alors à même de simplifier les opérations et de disposer d’une véritable gestion structurée.

Conclusion

Nous avons vu dans cet article que l’utilisation de périphériques d’authentification sûrs, de type token ou smartcard peut apporter un vrai plus dans la gestion des certificats et dans l’application d’une politique de sécurité. Pour une grosse infrastructure, ajouter un élément PS/SC ou OpenSC/PKCS#15 dans une architecture SSO (Single Sign On) apporte une vraie simplicité de gestion. En parallèle, l’utilisation, plus modeste, d’un Token peut être très intéressant pour sécuriser l’accès shell distant ou une zone spécifique d’un site Web (webmail, wiki, etc.). Seul problème dans ce cas, il faut que le poste utilisé dispose d’un middleware configuré (un liveCD est une bonne solution de secours).