Sécurité Infrastructures à clefs publiques, mise en pratique sous deux environnements: OpenSSL et Microsoft 2012 R2 – Work In Progress

24 août 2013 – 20:59

Cet article va s’efforcer de rendre les concepts liés à la création d’une infrastructure à clefs publiques (ou Public Key Infrastructure PKI) « home made » plus clairs. En effet, tant sur le plan professionnel que personnel j’ai eu à me pencher sur ces notions afin de les appliquer dans des cadres bien spécifiques et opposés.

Comme je n’aime pas appliquer des recettes sans les comprendre, je me suis penché sur la problématique en remontant de how-to en RFC, mais je pense maintenant en connaître les principes.

Tout d’abord avant de s’attaquer au cœur du problème, il est bon de revenir sur les notions de base du chiffrement. Je n’aborderais pas le détail calculatoire des différents algorithmes.

En préface à ces recherches que j’ai mené sur les PKI, il ne faut pas oublié, pourquoi celles-ci ont été créées; pour des besoins de:

  • Confidentialité,
  • Intégrité,
  • Authentification,
  • Non-répudiation.

Pour les puristes, je vais citer les critères CIA (Confidentialité, Intégrité et Disponibilité) qui sont la pierre angulaire de la sécurité. En France on retrouve souvent aussi l’acronyme DICP (Disponibilité, Intégrité, Confidentialité et Preuve).

Le chiffrement

Dans cette partie nous allons aborder trois notions, les algorithmes symétriques de chiffrement, les algorithmes asymétriques et les fonctions de hachage.

Les algorithmes symétriques

Les algorithmes symétriques, ou à clef secrète possèdent les caractéristiques suivantes:

  • Les opérations de chiffrement et de déchiffrement sont identiques, la clef de chiffrement est commune,
  • Ces opérations sont rapides,
  • La problématique qui leur est inhérente est la distribution de la clef.

Le chiffrement se déroule de manière assez simple; l’expéditeur et le destinataire connaissent tous deux la clef de chiffrement ainsi que l’algorithme de chiffrement. L’expéditeur chiffre au moyen de la clef secrète son message, l’envoie au destinataire qui peut le déchiffrer au moyen de cette même clef secrète.

On peut alors en déduire les deux limites de ce mode de chiffrement:

  • La distribution de cette clef secrète,
  • La non imputabilité du message, la clef étant commune aux personnes concernés.

Néanmoins cette méthode de chiffrement est très rapide et peut facilement être traitée de manière hardware, grâce à un ASIC dédié ou un jeu d’instructions spécifique sur le processeur.

On peut appliquer ces algorithmes sur les données de deux manières:

  • En chiffrement continue, (comme le RC4)
  • Ou en chiffrement par blocs (comme le DES, 3DES ou AES).

Il existe plusieurs mode de chiffrement par blocs, certains plus forts que d’autres. Parmi ces modes on peut citer le CBC, le CFB ou encore le ECB.

Les algorithmes asymétriques

Aussi appelés algorithmes à clef publique, ceux-ci viennent palier la problématique d’échange des clefs des algorithmes symétriques en créant un canal sûr d’échange.

Cette méthode de chiffrement peut être employée pour échanger des données de manière sécurisée, mais aussi pour permettre l’authenticité de données.

En effet dans le premier cas de figure, l’émetteur chiffre son message à l’aide de la clef publique du destinataire. Le destinataire peut alors déchiffrer ce message à l’aide de sa clef privée.

Dans le second cas de figure, l’émetteur chiffre ses données à l’aide de sa clef privée, le destinataire, peut alors vérifier l’authenticité des données en les déchiffrant à l’aide de la clef publique de l’émetteur.

Fort de ces modes de fonctionnement, la méthode de chiffrement la plus répandu est la méthode dite hybride. L’émetteur envoi au destinataire une clef de session chiffrée avec la clef publique du destinataire; puis le reste des échanges est effectuer en chiffrement symétrique avec cette clef de chiffrement. C’est un peu rapide comme explication mais si on s’en réfère à la RFC 5246 sur le TLS, c’est bien ce qu’il se passe durant le Handshake TLS.

Parmi les algorithmes de chiffrement asymétriques on peut citer les RSA ou les ECC.

On retrouve les clefs RSA principalement sous deux formats:

  • Le format binaire: qui est en fait l’encodage de la structure ASN.1 en suivant la syntaxe de transfert distinctive DER,
  • Le format ASCII: qui est l’objet binaire précédent encodé au format PEM (RFC 1421-1424).

Parallèlement à cela, il est important de noter que selon un certain nombre de sources (voir bibliographie plus bas) les clefs RSA d’une taille inférieure à 2048 bits devrait être attaquables sous peu. Il est donc nécessaire d’utiliser des tailles de 2048 ou 4096 ou alors de passer aux courbes elliptiques (ECC).Si vous souhaitez connaître l’équivalence de taille entre des clefs de type RSA et de type ECC pour conserver un niveau de sécurité, je vous conseille l’introduction de la RFC 4492.

La problématique du chiffrement asymétrique est de s’assurer que la clef publique appartient bien au destinataire voulu. C’est pour cela qu’une des solutions possible est de placer sa confiance en un tiers qui sera en charge de l’attribution des clefs.

Fonctions de hachage

Les fonctions de hachage sont des algorithmes permettant l’obtention d’une empreinte de taille fixe à partir d’un message de taille arbitraire. Ce hachage, aussi appelé condensat, doit posséder certains critères de sécurités que sont:

  • fonction unidirectionnelle,
  • impossibilité de connaitre le message d’origine à partir de son empreinte,
  • faibles collisions,
  • impossibilité de prévoir le condensat de deux messages combinés.

Parmi les fonctions de hachage, on peut citer les MD5 ou encore SHA-1 qui sont aujourd’hui réputés faible voir même craqués pour le MD5. Ces algorithmes ne devraient plus être utilisés au bénéfice des algorithmes SHA-2 (224, 256, 384 ou encore 512).

On retrouve souvent ce type d’algorithme pour le stockage de mot de passe notamment mais aussi pour les signatures numériques, le scellement des données ou encore l’horodatage. Pour les mots de passe, souvent on ajoute un grain de sel à ces derniers afin de renforcer encore la sécurité.

Cette technique consiste à l’ajout d’une partie variable au mot de passe avant de le hacher pour le stocker. Lors des phases d’authentification on peut aussi retrouver des doubles grains de sel.

Et Diffie-Hellman dans tout ça ?

Le protocole Diffie-Hellman est un protocole permettant un certain nombre de parties de se mettre d’accord sur un nombre, une clef de chiffrement commune sans connaissance préalable. Cette méthode est souvent employée afin de définir des clefs de chiffrement symétriques.

Les infrastructures à clefs publiques

Pour paraphraser la RFC 5280, le but d’une infrastructure à clefs publiques Internet est de permettre des fonctions d’identification automatisée, d’authentification, de contrôle d’accès et d’autorisation de manière déterministe. Ces services sont rendus possibles par des attributs du certificat comme les données auxiliaires tels que les données de politique ou les contraintes de chemin de certification.

Les utilisateurs d’une PKI sont des personnes ou processus qui utilise des clients logiciels et qui sont les propriétaires identifiés par les certificats. L’usage des certificats inclue la lecture ou l’écriture de messages électroniques, des clients www, des serveurs www, et le gestionnaire de clef pour les passerelles IPSec.

Les composants d’une infrastructure à clefs publiques sont les suivants:

  • Entité finale: utilisateur ou système final utilisateur des certificats de la PKI et qui en est le sujet,
  • AC: Autorité de certification (CA en anglais),
  • AE: Autorité d’enregistrement (RA en anglais), c’est un système optionnel auquel l’AC délègue certaines fonctions de gestion,
  • L’émetteur de la liste de révocation des certificats: c’est un système optionnel auquel l’AC délègue la publication de la liste de révocation des certificats (CRL en anglais),
  • L’autorité de dépôt (Repository en anglais): est un système ou une collection de systèmes qui stocke les certificats numériques ainsi que les listes de révocation (CRL).

Ces entités sont celles que l’on retrouve définie dans la RFC 5280 de l’IETF. En complément de celles-ci nous pouvons citer l’autorité de séquestre (Key Escrow):

  • L’autorité de séquestre: Cette entité a pour rôle de stocker de manière sécurisée les certificats numériques afin de pouvoir fournir aux autorités compétentes la capacité de déchiffrer les données pour un utilisateur ou un système de la PKI (ou ICP en français).

Les autorités de certification sont responsables de l’indication des statuts de révocation des certificats qu’elles émettent. Les informations relatives au statut de révocation peuvent être fournis en utilisant le protocole OCSP, les listes de révocations (CRL), ou tout autre mécanisme. En général, lorsque l’information de statut de révocation est fournis par le biais de CRL, l’autorité de certification est aussi l’émettrice de la liste de révocation.

La limite de ces listes de révocation est leur longueur. En effet plus une PKI va vivre, plus ces CRL seront longues et donc le temps de traitement aussi. Pour pallier à cette limite, le mécanisme OCSP a été créé sur un modèle requête-réponse.

Les certificats X.509 v3

Les certificats sont des structures certifiées comprenant:

  • Le nom de l’entité,
  • La clef publique de l’entité,
  • La durée de validité,
  • Le nom de l’autorité de certification,

Les utilisateurs d’une clef publique doivent être certain que la personne ou le système la présentant (et possédant la clef privée) est bien la bonne. Cette validation peut être faite par l’utilisation des clefs publiques des certificats. En effet la liaison entre le certificat et le système ou la personne est faite par l’autorité de confiance qui signe numériquement chaque certificat émis. L’autorité de certification peut créer cette relation de confiance grâce à des moyens techniques et administratifs. Un certificat possède une durée de vie limitée indiqué dans son contenu signé. La signature et la durée de vie des certificats pouvant être valider par des clients x.509 (ayant un catalogue de certificats d’AC de confiance), ces derniers peuvent être distribués par des moyens de communication non fiables.

 Hiérarchie des infrastructures à clefs publiques

La PKI est une infrastructure théoriquement hiérarchique:

  • Au sommet on y retrouve l’autorité de certification racine composée d’un certificat auto-signé et extensible pour les certifications croisées,
  • Ensuite, il y a une ou plusieurs autorité de certification intermédiaires, signées par l’autorité racine, et pouvant être habilitées à délivrer des certificats aux entités terminales,
  • Enfin les entités terminales.

Il peut y avoir plusieurs niveaux de certifications intermédiaires, celles-ci doivent simplement être hiérarchiquement signées.

 Implémentation d’une PKI avec OpenSSL

Dans les prochains exemples, j’utiliserais la version 0.9.8x.

Implémentation d’une PKI avec Microsoft Windows 2012 R2

Dans les prochains exemple, j’utiliserais la version 2012 R2 de Windows Server pour tous les rôles (AD et PKI).

 

Bibliographie

 https://datatracker.ietf.org/wg/pkix/
https://datatracker.ietf.org/doc/rfc5280/
https://datatracker.ietf.org/doc/rfc2585/
https://datatracker.ietf.org/doc/rfc3494/
https://datatracker.ietf.org/doc/rfc4210/
https://datatracker.ietf.org/doc/rfc3647/
https://datatracker.ietf.org/doc/rfc6960/
http://artisan.karma-lab.net/creer-sa-propre-mini-pki
http://pki-tutorial.readthedocs.org/en/latest/
http://www.homeworks.it/Html/OpenSSL_PKI_Articolo_Eng.html

Tags: , , , , ,

Sorry, comments for this entry are closed at this time.