Nicolas BROISIN

Ingénieur Communications Unifiées

Etude : Infrastructure PKI



Infrastructure à clés publiques



Auteur : Nicolas BROISIN

Qu’est-ce que c’est et à quoi ça sert ?



 Une PKI (Public Key Infrastructure) ou ICG (Infrastructure à Clés Publiques), est une infrastructure réseau dont le but est de sécuriser les échanges entre les différents éléments d'un réseau.

Permet une sécurisation des échanges élevée



 De nombreux protocoles de sécurités sollicitent la PKI notamment pour mettre en place :

  • Du VPN SSL

  • De l’authentification 802.1x pour le WIFI

  • Du HTTPS pour protéger le trafic HTTP avec SSL

  • De l’authentification forte

  • Du chiffrement de disque et de fichier

  • De la signature numérique S/MIME


Lors d'une négociation SSL, il faut s'assurer de l'identité de la personne avec qui on communique (risque d’une attaque de type « Man In the Middle »).
Comment être sûr que le serveur auquel vous parlez est bien celui qu'il prétend être ?
C'est là qu'interviennent les certificats. Il contient la clé publique de l'entité et des informations associées à cette entité.
Ils sont là pour permettre l’identification des accès aux systèmes d’information de l’entreprise, aux  sites internet, intranet. Parade au phishing, sécurisant les accès et les opérations sensibles pour les populations nomades, le certificat permet d’éviter les usurpations d’identité.
Voici le fonctionnement d’une authentification SSL mutuelle lors de la création d’une connexion sécurisée entre un client et un serveur avec certificats (utilisateur et serveur).
 

 
Cette technique permet d’avoir un canal de communication sécurisé (chiffré) entre deux machines (un client et un serveur) après une étape d'authentification.
Les échanges définis par le protocole SSL se déroulent en deux phases:

Première phase : authentification du serveur (en rouge)

1)      requête d'un client, le serveur envoie son certificat au client et lui liste les algorithmes cryptographiques, qu'il souhaite négocier.

2)      Le client vérifie la validité du certificat en interrogeant la liste de révocation des certificats (CLR)

3)      le client génère ensuite une empreinte chiffré avec la clé publique du serveur puis transmis à ce dernier.

4)      Les données échangées par la suite entre le client et le serveur sont chiffrées et authentifiées à l'aide de clés dérivées de celle-ci.

 

2) Deuxième phase : authentification (optionnelle) du client (en vert)

1)      Le serveur (et seulement lui) peut demander au client de s'authentifier en lui demandant tout d'abord son certificat.

2)      Le client réplique en envoyant ce certificat puis en signant un message avec sa clé privée (ce message contient des informations sur la session et le contenu de tous les échanges précédents).
Utiliser une authentification bidirectionnelle (mutuelle) permet d’assurer l’intégrité, la confidentialité et grâce à la 2eme phase, la non répudiation, permettant de garantir qu'une transaction ne peut être niée par aucune des 2 parties (client ou serveur).


Répond à une obligation juridique



La loi française 78-17, article 34, fait peser sur le responsable du traitement de données à caractère personnel, l’obligation d’assurer la sécurité et la confidentialité de ses données afin de garantir la vie privée des personnes concernées. Des condamnations ont déjà été prononcées pour « délit de manquement à l’obligation de préserver la sécurité des données à caractère personnel ».

Autrement dit, que ce soit pour transmettre des informations ou formulaires sur un site web (certificat serveur), ou transmettre des documents ou pièces jointes par email (certificat email), ne pas sécuriser la communication est une vraie prise de risque, pour l'informaticien comme pour les données !
 

Prérequis d’une infrastructure PKI




Le certificat électronique



Appelé aussi certificat numérique, ce sont des fichiers électroniques fonctionnant comme les mots de passe permettant de vérifier l'identité d'un utilisateur ou d'un ordinateur.
Ils sont utilisés pour créer le canal chiffré SSL utilisé pour les communications clientes.
Un certificat est un relevé numérique émis par une autorité de certification (CA) qui authentifie l'identité du détenteur du certificat et permet aux parties de communiquer de manière sécurisée grâce au chiffrement.
Le certificat contient une clé publique qu'il attache à l'identité de la personne, de l'ordinateur ou du service contenant la clé privée correspondante.
Les clés publiques et privées permettent au client et au serveur de chiffrer les données avant de les transmettre.
Pour que le certificat soit valide, il ne doit pas avoir été révoqué ni être arrivé à expiration.
La structure des certificats est normalisée par le standard X.509 de l'UIT (plus exactement X.509v3), qui définit de nombreuses informations d’identifications contenues dans le certificat :la version de X.509, le numéro de série du certificat, l'algorithme de chiffrement utilisé pour signer le certificat, le nom de l'autorité de certification de distribution, la date de début de validité du certificat, la date de fin de validité du certificat, l’objet de l'utilisation de la clé publique, la clé publique du propriétaire du certificat, la signature de l'émetteur du certificat.
C’est un standard c’est pourquoi le certificat X.509 est multiplateforme, il est valable aussi bien sur les postes clients Windows que sur les postes clients Linux du client Archimède. L’intérêt est qu’une autorité de certification Linux ou Windows pourra distribuer un certificat client valable que ce soit pour des clients Windows et Linux.
Le client Archimède est une PME de 820 collaborateurs en forte croissance qui souhaite avoir une distribution, un renouvellement et une révocation des certificats machines et utilisateurs qui soient la plus simple à réaliser c'est-à-dire de façon automatique.
Plusieurs types de certificats sont à dispositions : L’utilisation de certificats auto signés qui ne peuvent pas être déployés de façon automatique, ce qui est problématique concernant les besoins du client. L’utilisation de certificats tiers approuvés qui est la gestion des certificats par une société externe (PKI externe) mais qui comporte un coût trop important dans notre cas. Et le choix le plus judicieux demandé par le client : l’utilisation de certificats d’infrastructure à clés publiques (IGC ou PKI interne) qui permettent le déploiement, le renouvellement et la révocation des certificats de façon automatique par stratégie de groupe.
 

Présentation des composants de la PKI



L’autorité de certification racine (AC ou Certificate Autority CA)


L’autorité de certification racine représente le plus haut niveau de la hiérarchie d’autorité de certification et dans le cas où son certificat serait détourné de son utilisation, toute la PKI est à remettre en cause.
Pour des raisons de sécurité, l’autorité de certification racine doit être mise hors connexion. En effet, si l’autorité de certification racine est en ligne, elle est accessible par le réseau et peut donc être soumise à de nombreuses techniques d’attaque à distance.
La sécurité physique de cette autorité de certification doit être d’un niveau maximal. Il est recommandée d’installer l’autorité racine sur une machine virtuelle et de l’exporter sur un disque dure externe  après chaque utilisation et de l’enfermer ensuite dans un coffre où seul quelques personnes de l’administration du SI en a les accès.
Cette autorité n’est pas nécessairement Windows. On l’a vu le standard des certificats, X 509 permet l’interopérabilité des OS pour la CA. C’est une autorité qui a un certificat auto-signé.

L’autorité de certification de distribution  


L’autorité de certification de distribution est une autorité de certification soumise à une autorité racine qui l’a certifié.
Son principal rôle est de générer un certificat pour l'utilisateur. Le certificat contiendra des informations personnelles sur l'utilisateur mais surtout sa clef publique et la date de validité.
L'autorité de certification signera ce certificat avec sa clef privée. On parle de chaîne de confiance dans une PKI car il s'agit de faire confiance à cette autorité de certification qui sera lui-même certifié par une autorité supérieure et ainsi de suite.
L'autorité de certification aura aussi le rôle de mettre à jour la liste des certificats qu'il a signé afin de connaître les dates de validité de ses certificats.
En effet, pour vérifier si un certificat est valide, il faudra demander à l'autorité de certification qu'il l'a généré si le certificat en question est toujours valide ou s'il a été révoqué.

Un Annuaire


La PKI a besoin de l’annuaire de l’entreprise. Il joue le rôle de dépôt de certificat. Les seules contraintes de l'annuaire sont qu'il doit accepter le protocole X.509 pour le stockage des certificats révoqués et le protocole LDAP.
Son rôle est comme dit précédemment de stocker les certificats révoqués et par la même occasion, les certificats en cours de validité afin d'avoir un accès rapide à ces certificats. De plus, l'annuaire peut stocker les clefs privées des utilisateurs. Sachant que les certificats sont largement distribués, l'annuaire est une solution pour les mettre à disposition.

Le site web de publication


Il faut un site web hébergé sur un serveur du domaine pour la publication automatique des CRL depuis l’autorité de distribution. La publication des listes de révocation (Certificate Revocation List CRL) à l’extérieur du système informatique de l’entreprise permet l’usage de certificats à l’extérieur de l’entreprise Ce site web permet aux utilisateurs internes et nomades d’accéder à la liste de révocation. Les utilisateurs interne peuvent aussi utiliser l’annuaire pour vérifier la valider du certificat.

Le cycle de vie des certificats



Suivant les types de certificats, les recommandations de durée de vie d’un certificat ne sont pas les mêmes. Le renouvellement du certificat de l’autorité de certification racine est à faire tous les 16 ans. Ensuite le certificat de l’autorité de certification de distribution est valable 8 ans et celui des utilisateurs / ordinateurs est à renouveler en générale chaque année.
Par ailleurs, un certificat peut être révoqué avant la fin d’expiration de celui-ci.
Les raisons de révocation d’un certificat peuvent être de nature différente : la clef secrète est potentiellement compromise ; le client n'est plus certifié par la CA ; il y a un changement de CA ; la CA est potentiellement compromise.
C'est-à-dire, à chaque fois qu'on ne souhaite plus garantir que la clé soit utilisée.
Une liste de révocation de certificats (CRL) est un fichier, créé et signé par une autorité de certification. La liste de révocation (ou CRL) est une liste complète de certificats révoqués qu'on télécharge. Elle doit être téléchargée par le client, puis sert à comparer ensuite le certificat à vérifier avec cette liste afin de savoir si le certificat n'a pas été révoqué.
Dans le cadre des révocations de certificat, il subsiste un problème. La révocation est traditionnellement effectuée par le client de la PKI.
Si les demandes ne sont pas synchronisées, alors un certificat révoqué pourra être considéré comme valide.
Une grande confiance est ainsi accordée au client pour ce traitement critique. Par exemple, la non-automatisation de la récupération des CRL des navigateurs web pose un problème quant à la mise à jour des informations. Il sera imposé au client d’utiliser pour l’ensemble de son parc le navigateur internet explorer en version 9 afin d’avoir l’automatisation du télécharger des certificats à chaque publication.
 


Solution Linux avec OpenCA



 

  •              Système d’exploitation employé : CentOS 6.3

  •              Serveur d’autorité de certification :   OpenCA

  •              Annuaire de l’entreprise : OpenLDAP


 
Cette solution est gratuite mais sa mise en place est longue et fastidieuse. Donc le coût n’est pas à l’acquisition de la solution mais au déploiement et à la configuration. La solution est basée sur OpenLDAP or la plupart des postes clients du parc informatique sont sous Windows ce qui n’est pas très judicieux car la gestion des groupes et des utilisateurs est plus aisée avec l’annuaire Windows Active Directory. Le déploiement des certificats et la révocation de façon automatique n’est pas prise en charge par la solution et doit se faire à l’aide de scripts. L’utilisation d’une telle solution n’est pas faite pour une architecture comme celle du client Archimède.  
 

Solution Windows avec AD-CS



 

  •              Système d’exploitation employé : Windows 2012 server Standard

  •              Serveur d’autorité de certification : Autorité de certification (AD-CS)

  •              Annuaire de l’entreprise : Annuaire Active Directory (AD-DS)

  •              Intégration des clients Linux dans le domaine : Centrify DirectControl


La solution proposée par Windows est un rôle de base à installer sur Windows Server AD-CS pour Active Directory Certificates Services. Le fait qu’il soit directement lié à l’annuaire Active Directory permet notamment de pouvoir automatiser par GPO l’installation des certificats ainsi que le téléchargement des CRL par le navigateur Windows Internet Explorer.
Pour ce qui est des postes clients Linux, il est possible d’appliquer les GPO de l’AD en intégrant les clients Linux dans l’AD grâce à la solution Centrify Direct Control. Cette solution est onéreuse mais elle permet d’automatiser l’installation des certificats sur les cliens Linux et permet aussi la possibilité à tout utilisateurs du domaine de se connecter aussi bien sur les clients Windows que Linux.

Choix de mise en œuvre d’une PKI interne



 Rappel du cahier des charges


Les éléments d’infrastructure suivants ont été demandés :

  • Installation d’une PKI composé d’une autorité racine et une autorité secondaire

  • Possibilité de signer des autorités autres que celles basées sur Windows c'est-à-dire prise en charge des 188 postes fixe Linux.

  • Renouvellement et liste de révocation des certificats machines et utilisateurs réalisé de façon automatique pour les utilisateurs interne et nomade (en télétravail).

  • Mise en place d’un site web sécurisé, identification de l’utilisateur d’un site web et authentification de l’utilisateur en interne ou en nomade pour les postes intégrés au domaine.

  • Utilisation de certificats ordinateur pour l’utilisation de certificat Wifi 802.11i

  • Isolation de l’autorité racine entre deux usages par exportation de la machine virtuelle et mise au coffre.


 

Proposition d’une architecture PKI à 2 niveaux


 

Nous allons procéder au déploiement d’une infrastructure PKI à deux niveaux c'est-à-dire avec deux serveurs de certification.
Le premier serveur sera la racine de notre infrastructure : il va s'auto-certifier. On parle de racine puisque les certificats sont gérés sous forme d'arbre. L'autorité racine est complètement indépendante du réseau et du domaine. L’autorité sera éteinte et placée en sécurité pour éviter tout vol de sa clé privée. Nous proposons de la placer au siège du client à Orsay.
La deuxième autorité de certification est intégrée au domaine. Cela va lui permettre de publier des certificats dans l’annuaire Active Directory. Pour des raisons de sécurité, il est conseillé de placer l'autorité de certification sur un serveur indépendant. Bien qu'il soit possible d'installer l'autorité sur un contrôleur de domaine, ce n'est pas conseillé.  Il publiera la liste de révocation des certificats (CLR) au niveau de l’annuaire Active Directory pour les clients interne mais aussi sur le serveur Web de publication pour que les utilisateurs nomades de l’entreprise (en télétravail par exemple) puissent télécharger la liste de révocation des certificats afin de passer la phase de validation du certificat pour initialiser une connexion sécurisée avec les différentes entités de l’entreprise.
L’annuaire Active directory maître sera sur le site d’Orsay et répliqué en lecture seule sur les 4 autres sites du client. Cela permet d’éviter de surcharger les liens WAN lorsque les clients souhaitent récupérer leur certificat ou télécharger la liste de révocation des certificats. En effet, l’ensemble des certificats et liste de révocation sont transférés sur chaque site grâce à la réplication de l’AD d’Orsay.
L’avantage d’une telle solution est de ne pas déployer une autorité de certification de distribution sur chaque site ce qui est une économie pour le client.
La solution Centrify DirectControl nécessite l’installation de DirectManage qui est à installer sur un serveur web et qui permet de déployer les agents centrify sur chaque client Linux afin de les ajouter à l’annuaire Active Directory. Il sera installé sur le même serveur que l’Annuaire de Bayonne pour un gain dans l’achat des licences.

Les évolutions possibles



 
L’infrastructure proposée permettra aussi toute évolution au sujet de l’authentification forte concernant l’authentification avec cartes à puces.
En effet, cela permet notamment une souplesse d’utilisation, elles peuvent être utilisées partout, sur plusieurs machines, ou encore avec des applications multiples. Mais surtout cela permet de disposer d’un badge d’entreprise unique, à la fois pour entrer physiquement dans l’entreprise que pour entrer virtuellement dans l’entreprise sur sa session utilisateur du domaine de l’entreprise. Il y a une solution Microsoft qui s’appelle FIM pour Forefront Identity Manager qui permet de gérer les comptes utilisateurs, les accès, les authentifications par mot de passe et certificat (cartes à puce) et les stratégies de compte dans des environnements hétérogènes, dont Windows.
Par ailleurs, ce serait un coût supplémentaire pour le client Archimède car le prix des boîtiers adaptateur par postes clients en plus des cartes à puces par salarié est élevé. Et les licences à acheter concernant la mise en place de la solution FIM sont nombreuses et chères.
 
Ce n’est pas nécessaire pour les besoins actuelles du client mais si l’on souhaite poussée l’architecture PKI à une authentification forte avec carte à puce.

Caractéristique technique de la PKI interne choisie



 
Elle se compose des éléments suivants :

  • Une autorité racine offline sur Windows Server 2012 Standard en mode groupe de travail sur une machine virtuelle (VM). Cette VM sera importée à chaque utilisation puis exporté après chaque utilisation sur un disque dure externe enfermé dans un coffre.

  • Une autorité de distribution sur Windows Server 2012 Standard sur une machine virtuelle membre du domaine. Elle distribuera des certificats à l’AD et publiera la liste de révocation sur le serveur web de publication.

  • Un serveur Web qui permettra de publication de la liste de révocation des certificats pour les clients externe qui pourront la télécharger afin d’effectuer la phase de validation du statut de certificat à vérifier (révoqué, périmé etc..).

  • Un serveur DirectManage qui permet de déployer les agents Centrify sur les postes clients.


 

Coût de l’infrastructure proposée



 
Cette architecture est basée sur de la virtualisation Hyper-V afin de permettre une réduction des coûts d’acquisition de plusieurs serveurs physiques.
De plus, le choix d’utiliser une solution Windows server 2012 Standard est une question surtout de coût. En effet, Choisir Windows 2012 server standard c’est de s’assurer d’avoir les mêmes caractéristiques qu’un Windows server 2008 R2 entreprise avec l’ensemble des innovations liés au possibilité de migration dans le Cloud.
De plus, avec la licence de Windows 2012 server il est possible de  virtualiser 2 machines virtuel (VM) C'est-à-dire que l’on réduit le coût d’achat de 2 serveurs physique avec la version 2012 standard ! Au niveau du prix la licence Windows server 2012 Standard est à 700€ chez notre revendeur Inmac, alors que la version 2008 R2  Entreprise est à 2000€.

Sur Orsay, il nous faudra 3 licences serveur car la 4eme concerne l’autorité de certification racine qui est considéré comme Offline ce qui nous permet d’éviter d’acheter une licence. Puis nous avons sur chaque site le besoin d’une licence.
Nous avons aussi le prix des licences clientes, les CALs pour Client Access Licence. Ce qui correspond au nombre d’utilisateurs du domaine qui demande l’ouverture d’une session avec l’annuaire AD-DS. Ce nombre est différent en fonction des sites du client. Les clients Linux sont compris dedans en plus de prix de la solution Centrify. Notre revendeur Inmac propose des packs de 5 licences CAL à 100€.
Concernant le serveur physique, il est recommandé pour Orsay d’acheter un serveur Intel Xeon X5650 qui est dédié aux professionnels avec 6 cœurs cadencé à 2.66GHz. Il faut compter 900€ pour le processeur lui-même. Dans le tableau il vous sera donné un prix indicatif.
Concernant la partie tarifaire et pour l'intégration de 188 poste de travails Linux dans AD il faut compter (prix publiques en € HT) :
 - 1 licence Direct Manage : 1000 €
- 19 packs de 10 licences pour Workstation :  690 X 19 = 13110 €
- Maintenance 1 an (obligatoire la première année avec accès au support technique et MAJ du logiciel) : 2822 €
Soit donc un total de 16932 € HT (90 € par poste).

Tableau récapitulatif des coûts de l’architecture proposée :




 
 

Tags : PKI, Cours
Ecrit le 09/01/2013 à 23h07 dans la catégorie "Mes cours en informatique".

Ajouter un Commentaire

Prénom : E-mail (visible que par l'admin) :
Message :

Recopiez : 374 :


Les commentaires


Commentaire posté par Mahmoud le 3/06/2013 à 15h03
Chapeau Bas l'artiste, avec notre emploi du temps tu trouve le temps de tenir à jour un site web qui plus est très bien fait. A la prochaine et d'ici la pas de connerie. ++


Commentaire posté par landry le 10/07/2014 à 16h53
jai envi de realiser une PKI dans laquelle il ya deux clients et un serveur de messsagerie les clients doivent pouvoir s'envoyer des messages chiffrés sous un environnement windows server 2003


Commentaire posté par Nicolas le 11/07/2014 à 0h20
Bonjour Landry,

Concernant ton besoin je te propose de regarder la technologie S/MIME.

Concernant la théorie je te propose ce lien qui explique clairement avec schéma les notions à appréhender :
http://technet.microsoft.com/library/aa995740(v=exchg.65).aspx

Et pour la partie pratique, voici un lien qui explique step by step la configuration de la PKI et de la configuration de Microsoft Exchange pour activer la fonctionnalité S/MIME

http://msdn.microsoft.com/en-us/library/dn643699.aspx

Bonne continuation !