Pages: 1 2 3

Créer une clé RSA

Après avoir vu comment utiliser les clés RSA dans l’authentification, voyons maintenant comment les créer. Sur Asterisk, la façon la plus simple de créer des clés est d’utiliser l’outil livré dans la distribution standard: astgenkey. D’un usage simplifié au maximum cette commande construit les deux parties de la clé et les deux fichiers associés. Etant donné que les clés RSA sont protégées par un mot de passe, il peut être utile de spécifier l’option -n lors de l’appel de astgenkey afin de supprimer ce mot de passe. La sécurité est certes affaiblie car la clé privée peut être utilisée sans ce mot de passe, mais l’Asterisk peut dès lors démarrer sans demander le mot de passe, ce qui rend l’automatisation de son démarrage plus simple. Ci-dessous vous trouverez le résultat de l’exécution de cette commande:

# astgenkey -n

This script generates an RSA private and public key pair
in PEM format for use by Asterisk.  You will be asked to
enter a passcode for your key multiple times.  Please
enter the same code each time.  The resulting files will
need to be moved to /var/lib/asterisk/keys if you want
to use them, and any private keys (.key files) will
need to be initialized at runtime either by running
Asterisk with the '-i' option, or with the 'init keys'
command once Asterisk is running.

Press ENTER to continue or ^C to cancel.

Enter key name: Paris
Generating SSL key 'Paris':
Generating RSA private key, 1024 bit long modulus
.....++++++
.........................................................++++++
e is 65537 (0x10001)
writing RSA key
Key creation successful.
Public key:  Paris.pub
Private key: Paris.key

Comme nous l’avons dit, cette solution est la plus simple, ne nécessite aucune connaissance particulière d’openssl, mais impose une gestion des clés rigoureuse. Il n’est en effet pas possible après coup de savoir à quoi correspond un fichier de clé, seul le nom du fichier pourra servir à cette identification. Ceci reste bien évidemment possible, la gestion d’un parc important de partenaire avec lesquels on souhaite établir des faisceaux IAX pourraient constituer un écueil à cet usage, on préférera alors le passage à la solution proposée ci-après: les certificats.

Le certificat X.509

En plus de contenir les clés privée et publique, un certificat numérique contient bien d’autres informations utiles. Notamment des informations permettant d’identifier le certificat, pourquoi il a été crée, pour qui ou encore sa durée de validité. Ce chapitre traite de la construction manuelle de certificat X.509 ainsi que la manipulation des clés RSA afin de s’en servir dans l’authentification sur notre faisceau IAX. La solution retenue est celle d’openssl, simple et surtout présente sur chaque serveur Linux¹.

Un certificat peut être construit par n’importe quel individu, mais sa validité n’est effective qu’après un processus de signature. Une hiérarchie de signataire peut ainsi être construite afin d’autoriser un principe simple de délégation de pouvoir. Chaque certificat est donc signé par une ou plusieurs autorités qui attestent de sa validité.

On pourrait par exemple imaginer la création d’un groupe d’utilisateurs d’Asterisk qui souhaitent authentifier les appels en provenance des autres membres. L’autorité de certification aura donc pour tâche de signer les certificats de ces utilisateurs, qui pourront ensuite échanger la partie publique de ceux-ci afin de construire leur modèle de validation. Avant de mettre en place votre faisceau avec un nouveau partenaire, vous pourrez ainsi vérifier la signature apposée sur son certificat et supprimer ainsi tout risque d’usurpation d’identité.

Création de la racine de certification

Dans le processus de signature, étant donnée la nature hiérarchique de ce principe, il doit y avoir tout en haut de l’arbre un signataire final. Celui-ci a une identité qui ne peut pas être remise en cause, il s’agit d’une racine de certification que nous allons créer pour notre usage et l’appeler Panoramisk (bonne idée, non ?). Voici comment construire ce certificat racine.

Tout d’abord il nous faut un fichier descriptif du certificat racine, il peut être crée dans n’importe quel répertoire, nous travaillerons pour cette exemple dans “.” et disposerons d’un répertoire certs afin de stocker ce que nous souhaitons garder. La description de notre racine est mise dans le fichier arbitrairement appelé ./certs/root.cnf qui contient:

[ ca ]
default_ca      = CA_default

[ CA_default ]
prompt = no
dir             = .
certs           = $dir
crl_dir         = $dir
database        = $dir/index.txt
unique_subject  = no
new_certs_dir   = $dir/
serial          = $dir/serial
crl             = $dir/crl.pem

certificate     = ./certs/root.cert
private_key     = ./certs/rootenc.key

RANDFILE        = $dir/.rand
x509_extensions = usr_cert
name_opt        = ca_default
cert_opt        = ca_default
default_days    = 365
default_crl_days= 365
default_md  = md5
preserve    = no

[ policy_anything ]
countryName             = optional
stateOrProvinceName     = optional
localityName            = optional
organizationName        = optional
organizationalUnitName  = optional
commonName              = supplied
emailAddress            = optional

[ req ]
default_bits            = 1024
default_keyfile         = privkey.pem
distinguished_name      = req_distinguished_name
attributes              = req_attributes
x509_extensions         = v3_ca
prompt = no

[ req_distinguished_name ]
C                      = FR
ST                     = Rhone-Alpes
L                      = Lyon
O                      = Panoramisk
OU                     = Main
CN                     = Root
emailAddress           = alex@panorammisk.com

[ req_attributes ]
challengePassword      = This is a really good challenge

[ usr_cert ]
nsComment              = "IAX2 Certificate"
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid,issuer:always

[ v3_req ]
basicConstraints = CA:FALSE
keyUsage = nonRepudiation, keyEncipherment

[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = CA:true

[ crl_ext ]
authorityKeyIdentifier=keyid:always,issuer:always

Vous trouverez quelques champs de description, pour le détail il sera nécessaire de se reporter à une documentation d’openssl.

A l’aide de ce fichier de description, nous pouvons créer le certificat avec les commandes suivantes:

openssl req -config ./certs/root.cnf -new -x509 
     -keyout ./certs/rootenc.key 
     -out ./certs/root.cert

Pendant le processus de création, une phrase de sécurité est demandée, elle permettra d’authentifier les demandes de signatures prochaines, il est donc nécessaire de ne pas la perdre et qu’elle dispose d’un minimum de complexité. Nous voilà à la tête du certificat racine de notre groupe d’utilisateurs.

Création d’un certificat noeud

Notre certificat racine est approuvé par tous, c’est le postulat de base. Nous pourrions également le faire valider par une autorité de certification reconnue et publique comme Verisign par exemple, mais tel n’est pas notre propos. Voyons maintenant comment créer un certificat pour un utilisateur (un Asterisk plus exactement) et procéder à sa signature. Notre premier certificat noeud sera pour Paris, nous construisons pour ce faire un fichier descriptif et le mettons dans certs/Paris.cnf:

[ req ]
default_bits            = 1024
default_keyfile         = privkey.pem
distinguished_name      = req_distinguished_name
attributes              = req_attributes
x509_extensions = v3_ca

prompt = no

[ req_distinguished_name ]
C                      = FR
ST                     = RA
L                      = Paris
O                      = Panormaisk
OU                     = Agency
CN                     = Paris Agency
emailAddress           = paris@panoramisk.com

[ req_attributes ]
challengePassword           = One new challenge is required...

[ v3_ca ]
subjectKeyIdentifier=hash
authorityKeyIdentifier=keyid:always,issuer:always
basicConstraints = CA:true

With this file we can create the certificate and sign it, the commands to issue are looking like:

openssl req -config certs/Paris.cnf -new 
   -keyout certs/Paris_enc.key -out newreqParis.pem

Une phrase de protection est également demandée, nous supprimerons celle-ci de la clé privée pour les mêmes raisons qu’exposées dans la création des clés RSA avec astgenkey. Les deux fichiers crées sont une demande de certification ainsi qu’une clé privée. Il nous faut maintenant la signer.

Si ce certificat est le premier crée pour un noeud, openssl nous demande d’initialiser une base de données, voici une façon rapide de faire ceci:

echo "01" > serial
cp /dev/null index.txt

Maintenant, nous pouvons procéder à la signature (après validation des informations contenues dans la requête, le but n’est pas de signer n’importe quoi non plus). Attention, durant le processus de signature, le phrase de sécurité utilisée lors de la création du certificat racine sera demandée et vérifiée.

openssl ca -batch -config certs/root.cnf 
   -policy policy_anything -out certs/Paris.cert 
   -infiles newreqParis.pem

Le certificat ainsi crée, pour Paris, est maintenant signé par notre autorité racine. Nous pouvons vérifier le contenu du certificat avec la commande suivante:

openssl x509 -noout -nameopt multiline -issuer 
   -subject -dates -in certs/Paris.cert
issuer=
    countryName               = FR
    stateOrProvinceName       = Rhone-Alpes
    localityName              = Lyon
    organizationName          = Panoramisk
    organizationalUnitName    = Main
    commonName                = Root
    emailAddress              = alex@panorammisk.com
subject=
    countryName               = FR
    stateOrProvinceName       = RA
    localityName              = Paris
    organizationName          = Panormaisk
    organizationalUnitName    = Agency
    commonName                = Paris Agency
    emailAddress              = paris@panoramisk.com
notBefore=Aug 23 07:31:55 2007 GMT
notAfter=Aug 22 07:31:55 2008 GMT

Mais également valider la signature:

openssl verify -verbose -CAfile certs/root.cert certs/Paris.cert
certs/Paris.cert: OK

Ce processus de création de certificat pour les noeuds doit être répété de façon individuelle, on veillera à bien garder les fichiers de description afin de garder l’historique et une traçabilité sur ces créations et signatures.

Clés RSA pour notre faisceau IAX

Toutes ces actions de création de certificat ne sont pas vaines, nous pouvons maintenant aller vers notre objectif et les utiliser dans le cadre de notre authentification IAX. La clé privée RSA a été créée en même temps que le certificat, ce composant fait effectivement partie intégrante du certificat numérique. Il est maintenant nécessaire de pouvoir en extraire la partie privative mais également la partie publique.

Afin de simplifier le démarrage de notre Asterisk, commençons par supprimer la phrase de sécurité liée à cette clé privée:

openssl rsa -in certs/Paris_enc.key -out certs/Paris.key
Enter pass phrase for certs/Paris_enc.key:
writing RSA key

La clé privée, nommée Paris.key peut désormais être utilisée dans notre Asterisk, il suffit de positionner le fichier dans le répertoire /var/lib/asterisk/keys/

Pour la clé publique qui sera utilisée par l’Asterisk de Londres, nous allons utiliser le certificat. En effet, fournir notre clé publique RSA à Londres ne serait pas d’un grand intérêt par rapport au travail de création du certificat numérique qui contient, je vous le rappelle, des informations importantes notamment la signature de notre autorité de certification racine. Nous allons donc transmettre à Londres le certificat numérique qui pourra ainsi être vérifié.
Au niveau de Londres, on pourra vérifier les informations contenues dans le certificat et après validation extraire la partie publique de la clé grâce à la commande suivante:

openssl x509 -noout -pubkey -in certs/Paris.cert
-----BEGIN PUBLIC KEY-----
MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDI0ZDGRmL/nZqtc7eoPKY9VYtW
9zJiUq2vwp/mKsxIJEmewDEqXYnKp/1eY5x03et+mfeDYtPa10NAFrR06RWMMR7U
pWynMoyuwsfWJmfmO/G5A9m5iGZOvrVyA15LWP/WV+sGhIQ+fPAVLCwB58PH6PyJ
aCZCUZfL57AyF2mLCwIDAQAB
-----END PUBLIC KEY-----

Le résultat de cette commande sera redirigé vers le fichier Paris.pub qui sera positionné dans le répertoire d’Asterisk. Nous utiliserons cette clé pour valider les appels en provenance de Paris. On pourrait régulièrement automatiser la validation du certificat, notamment par rapport à sa date d’expiration et à sa validité (cf notion de CRL) et la création de la clé publique, le système serait ainsi totalement sécurisé par rapport aux appels entrants depuis des partenaires.

Conclusion

Nous avons donc vu ici que l’authentification RSA était une méthode aboutie afin de valider les appels en provenance d’un tiers mais également qu’il était nécessaire de mettre en place une gestion de clé rigoureuse. Cette gestion peut être basée sur les certificats numériques, qui permettent d’associer à la clé RSA des informations administratives permettant sa manipulation.
En fonction de la taille de votre installation et du niveau de sécurité requis, vous pourrez désormais mettre en place une solution d’authentification forte basée sur RSA à l’aide de la commande astgenkey ou d’une solution de type PKI plus complète mais aussi plus complexe à mettre en oeuvre.

1. ou installable rapidement à partir d’un package [↩]

Pages: 1 2 3