Sécurité

Sécurisation du courrier électronique grâce aux certificats numériques

Matt Clapham and Blake Hutchinson

Vue d'ensemble:

• Création d'une identité vérifiable
• Mise à jour du statut de certificat
• Obtention et échange de certificats
• Dépannage de votre système de S/MIME

Depuis des milliers d'années, les humains utilisent diverses méthodes pour masquer les informations en transit, valider les expéditeurs et authentifier les messages. À mesure que la civilisation a évolué, une méthode pour effectuer ces trois tâches a été développée et devient largement utilisée. Les signatures numériques S/MIME

constituent un système permettant d'envoyer du courrier électronique en toute sécurité à l'aide du chiffrement et des signatures numériques.

Les technologies de chiffrement actuelles (masquage) appartiennent à deux types principaux : Les algorithmes à clé symétrique (secrète), comme DES (Data Encryption Standard) ou AES (Advanced Encryption Standard) (les CA) et les algorithmes à clé asymétrique (publique/privée) comme RSA ou ECC (Elliptical Curve Cryptography). Les outils modernes de validation de l'expéditeur sont des fonctions mathématiques unilatérales appelées hachages qui effectuent des signatures uniques. Deux méthodes de hachage utilisées couramment sont Message Digest algorithm 5 (MD5) et Secure Hash Algorithm (SHA). Les ordinateurs peuvent utiliser celles-ci pour générer un hachage ou un numéro unique qui correspond au texte source individuel (hachage des textes sources identiques à la même valeur). Ces outils simples sont exploités et combinés pour générer un système d'infrastructure de clé publique (PKI).

Une identité vérifiable

Ressources sur l'Autorité de certification

• Utilisation d'une Autorité de certification pour la fonctionnalité EFS (Encrypting File Service)
• Les serveurs de l'Autorité de certification ne peuvent pas être renommés ou supprimés du réseau
• Comment supprimer une Autorité de certification approuvée à partir des ordinateurs du domaine
• Comment faire pour désactiver une autorité de certification d'entreprise Windows et supprimer tous les objets associés de Windows Server 2003 et Windows 2000 Server
• Comment déplacer une autorité de certification vers un nouveau serveur s'exécutant sur un contrôleur de domaine

Les identités d'un système PKI sont gérées à l'aide de certificats numériques, qui ne sont pas différentes du passeport que portent la plupart des gens lorsqu'ils traversent une frontière internationale. Le standard de passeport du monde du certificat numérique est le format X. 509, et il est largement utilisé pour la signature et le chiffrement dans les technologies comme S/MIME, Internet Protocol Security (IPsec), Secure Shell (SSH), la sécurité de réseau sans fil, les réseaux privés virtuels (VPN) et même les communications sécurisées des serveurs (comme les sites Web SSL).

Les certificats sont basés sur la cryptographie asymétrique et les hachages. Pour créer un certificat, le demandeur (l'entité souhaitant une clé signée par une autorité plus élevée) génère une clé privée. La clé est verrouillée de sorte que son authenticité ne constitue jamais une difficulté. En même temps que la clé privée, une clé publique correspondante est également générée. Comme son nom l'indique, la portion publique de cette paire n'est pas secrète et est distribuée gratuitement, quoique toujours d'une façon qui garantit son authenticité.

Cette paire de clés permet deux opérations fondamentales. Tout d'abord, n'importe qui peut utiliser la clé publique pour chiffrer quelque chose que seule la clé privée peut déchiffrer. En second lieu, la clé publique peut être utilisée pour déchiffrer un élément chiffré avec la clé privée. C'est important pour vérifier une signature que seule une clé privée aurait pu créer.

La requête à l'autorité de certification inclut des détails comme l'identité de la personne ou de l'ordinateur à laquelle la clé est destinée, le type et la force de l'algorithme et la portion publique de la paire de clés. L'autorité de certification (CA) reçoit et valide les informations de la requête et, utilisant un algorithme de hachage, crée un identificateur unique correspondant aux informations.

À l'aide de sa clé privée, l'autorité de certification chiffre le hachage des informations et les rassemble dans un format standard (comme X.509), en créant un certificat qui correspond à la requête originale. Le certificat X.509 contiendra une liste de déclarations y compris l'identité du certificat (le sujet), une période de validité, la clé publique et les opérations pour lesquelles le certificat peut être utilisé. Le certificat est alors renvoyé au demandeur. Il s'agit d'un jeton qui déclare, en effet, « moi, l'autorité de certification, je me porte garante de cette clé publique et de la portion privée correspondante, pour toutes les utilisations décrites dans ce document ».

Pour les autorités de certification racine (ceux qui sont au plus haut niveau de la chaîne de confiance), les certificats sont autosignés. La plupart des autorités de certification racine acceptables sont préinstallées dans le système d'exploitation de base ou l'application mais peuvent être mis à jour ou modifiés via la configuration de packages ou d'entreprise. Entre l'autorité de certification racine et un nœud terminal (qui décrit généralement une personne ou un système individuel), il peut y avoir une ou plusieurs autorités de certification intermédiaires.

La chaîne comprend tous les nœuds et tous les certificats précédents intégrés à ceux-ci, signés par l'autorité de certification à ce niveau. Un tiers essayant de valider le certificat peut vérifier le hachage calculé localement et le comparer à celui qui est déchiffré à partir du certificat utilisant la clé publique correspondante pour cette autorité de certification ou cet individu particulier. C'est une chaîne de confiance entièrement validée de la feuille à la racine, en supposant, bien sûr, que la racine soit approuvée.

Mise à jour du statut de certificat

Chaque autorité de certification correcte dispose d'un moyen de distribuer une liste de certificats qui ne sont plus fiables. Cette liste de révocation de certificats (CRL) décrit quels éléments publiés ont été annulés de façon spécifique par l'autorité de certification. Pour plus de commodité, l'emplacement du CRL est généralement une propriété du certificat de l'autorité de certification.

Les autorités de certification émettent régulièrement des CRL sur deux bases : un programme (peut-être toutes les deux semaines) ou un événement (une occurrence qui indique qu'un certificat émis n'est plus fiable). Une autorité de certification signera ses CRL émis lorsqu'il les publie. Lorsqu'un système de réception évalue la validité d'une chaîne, il tente généralement d'acquérir le CRL pour chaque CA émettrice de la chaîne (via les informations intégrées dans les certificats eux-mêmes ou via le mécanisme de distribution fiable prédéfini). Si une CRL est indisponible, le client peut avoir recours à une copie récente, mise en cache avec succès si elle n'est pas plus ancienne que la période de mise à jour de CRL spécifiée. Si cela ne marche pas, cependant, les systèmes client afficheront généralement une erreur indiquant que le certificat paraît valide mais l'état de révocation ne peut pas être déterminé.

De nombreuses applications prennent beaucoup plus de temps pour charger un certificat s'ils sont incapables de valider la chaîne ou la CRL pour chaque nœud de la chaîne. Selon ce que le certificat protégeait, l'utilisateur peut ne pas vouloir lui faire confiance. Un point de distribution de CRL régulièrement mis à jour largement disponible est absolument nécessaire pour chaque CA, surtout pour ces racines publiques.

Les racines sont la base de la chaîne de certificats et le chaînage est la base de toutes les hiérarchies de certificats. La plupart des systèmes ou applications client supposeront seulement qu'un certificat de nœud terminal est valide s'il est relié à une racine de confiance. Cela pourrait être une CA d'entreprise, possédée et utilisée par cette entreprise particulière ou cela pourrait être une CA racine publique (comme VeriSign).

Pour les CA racine publiques, il existe des attentes d'expertise opérationnelle significative pour que l'intégrité soit assurée. Les entreprises doivent parvenir au même niveau pour leurs opérations internes, comme l'intégrité d'une CA racine dans ce contexte est tout aussi importante. Pour une protection optimale, les CA racine doivent être conservées hors ligne et utilisées uniquement pour émettre les certificats et mettre à jour les CRL. Pour plus d'informations sur les méthodes opérationnelles recommandées des autorités de certification, consultez les articles énumérés dans l'encadré « Ressources sur l'Autorité de certification ».

Un aspect important à prendre en compte est la récupération des clés. Pour faciliter les investigations et assurer que les données ne sont pas irrémédiablement verrouillées par un utilisateur, l'entreprise doit effectuer des copies de sauvegarde de toutes les clés émises par les utilisateurs. De plus, ces copies de sauvegarde doivent être enregistrées dans un référentiel sécurisé. De cette façon, si une clé d'utilisateur disparaît, par exemple lorsqu'une carte à puce est oubliée dans un taxi, tout contenu protégé par la clé est toujours accessible.

Enfin, dans tout bon système cryptographique, on trouve le concept de gestion de cycle de vie. À mesure que les ordinateurs deviennent plus rapides, les algorithmes deviennent plus faibles. Tout bon système de chiffrement doit pouvoir se renouveler et passer progressivement à de nouveaux algorithmes et tailles de clé. Les autorités de certification doivent être mises à jour de manière appropriée lorsque les faiblesses cryptographiques sont identifiées et que certaines fonctions sont introduites ou supprimées progressivement.

Implémentation de S/MIME

On distingue plusieurs étapes pour le démarrage, la composition, l'envoi et la réception du courrier électronique signé ou chiffré à l'aide de S/MIME. Nous aborderons les détails, les problèmes et les solutions potentielles à mesure que nous avançons dans un scénario S/MIME typique : deux utilisateurs s'envoyant l'un à l'autre un message signé et/ou chiffré à partir de deux forêts Active Directory® différentes et de chaînes d'autorité de certificat différentes (c'est-à-dire, à partir d'entités fonctionnellement séparées, dans la même entreprise ou pas) utilisant Microsoft® Office Outlook® 2007.

Nous supposerons que l'infrastructure nécessaire est déjà en place pour permettre les opérations que nous décrirons. Dans notre cas, nous utilisons un serveur de certificat d'entreprise intégré à Active Directory.

Obtention des certificats

La première tâche consiste à obtenir les certificats appropriés. Pour ce faire, vous ouvrez le Gestionnaire de certificats de la console MMC (certmgr.msc), cliquez avec le bouton droit sur le dossier Personnel, sélectionnez Toutes les tâches dans la liste contextuelle, puis sélectionnez Request New (Demander nouveau) dans la liste.

Cela permet de lancer l'Assistant d'inscription du certificat, comme illustré à la figure 1. Par défaut, plusieurs options orientées entreprise seront affichées, mais le plus important est le certificat utilisateur. Il sera utilisé pour activer plus tard les processus de signature et de chiffrement. Le certificat doit pouvoir être utilisé pour :

Figure 1** Demander un certificat **(Cliquez sur l'image pour l'agrandir)

• Les signatures numériques (en créant un message avec un cachet d'authenticité de son créateur)
• Chiffrement de la clé (en protégeant une clé avec une autre clé pour les technologies comme le système de fichier EFS)
• Courrier sécurisé (messagerie chiffrée qui ne peut être lue que par le destinataire prévu en possession de la clé privée correspondante)

Pour envoyer le message électronique S/MIME signé, la propriété de chiffrement de clés n'est pas nécessaire. Cependant, pour envoyer ou recevoir le courrier chiffré, cette propriété est requise, bien que la propriété de signature ne le soit pas. Par défaut, les modèles dans les services de certificats de Windows® activent ces trois propriétés. Si l'utilisateur n'est pas autorisé à demander de nouveaux certificats, aucun certificat ne sera affiché lorsque l'Assistant démarre. Si aucune autorité de certification d'entreprise n'est disponible, l'utilisateur verra s'afficher une « erreur d'inscription » indiquant que le domaine ou l'autorité de certification n'a pas pu être contactée. Pour cette description, nous supposerons qu'un seul certificat autorise la signature et le chiffrement.

Échange de certificats

La façon la plus facile pour deux utilisateurs de commencer à envoyer du courrier chiffré est simplement de s'envoyer l'un à l'autre des messages signés. Après avoir composé un message, l'utilisateur clique sur le bouton Signer. (Quelquefois le bouton est masqué par défaut dans Outlook jusqu'à ce qu'il soit utilisé pour la première fois. Vous pouvez le trouver en cliquant sur le paramètre Options pour les nouveaux messages, en cliquant sur le bouton « Paramètres de Sécurité... », puis activez la case à cocher « Ajouter une signature numérique à ce message ». Le bouton de signature (une petite enveloppe jaune avec un ruban rouge portant l'inscription Signer) ajoute une signature numérique au message pour établir l'authenticité de sa source.

En appuyant sur le bouton Envoyer, l'utilisateur peut être invité à fournir des jetons supplémentaires de possession de clé, par exemple en insérant une carte à puce ou en entrant un code confidentiel. Cela dépend des méthodes particulières de protection de clé en place dans l'entreprise.

L'utilisateur recevant le message signé S/MIME devra afficher et cliquer avec le bouton droit sur le nom de l'expéditeur (après De :) et sélectionner « Ajouter aux contacts Outlook » dans le menu contextuel, qui ajoute une nouvelle entrée de contact ou met à jour une entrée existante. Le certificat est alors associé à cette entrée de contact particulière. Notez que dans un environnement commun d'Active Directory (deux utilisateurs dans la même forêt ou la même entreprise), la distribution des certificats utilisateur publics est effectuée automatiquement via les attributs dans l'objet Active Directory de l'utilisateur.

Une autre façon d'échanger les certificats est pour chaque utilisateur d'envoyer ses certificats S/MIME en tant que pièce jointe. Pour ce faire, les deux partis devront exporter leurs certificats vers un fichier CER. Les utilisateurs devront afficher le certificat et suivre le processus d'exportation que nous aborderons bientôt, en faisant attention de ne pas exporter la clé privée en même temps, comme illustré à la figure 2.

Figure 2** Lors de l'échange des certificats, n'exportez pas la clé privée **(Cliquez sur l'image pour l'agrandir)

Ensuite chaque destinataire crée manuellement une entrée de contact dans Outlook et ajoute le certificat à l'entrée de l'expéditeur. Une fois que les deux utilisateurs ont échangé des certificats, ils pourront échanger entre eux du courrier chiffré.

Dépannage

Quelquefois le destinataire a des difficultés à ouvrir le message chiffré. Les trois sources les plus probables de problèmes que nous avons vus dans cette zone sont des CA racine non fiables, des CA intermédiaires qui ne peuvent pas être validées et des CRL non disponibles.

Une CA racine non fiable affiche généralement dans Outlook comme message d'erreur associé à la signature : « Des problèmes sont liés à la signature. Cliquez sur le bouton Signature pour plus de détails.) Pour résoudre le problème, ouvrez le certificat dans Outlook et cliquez sur le bouton « Afficher une autorité de certification. » dans le menu contextuel. Regardez le message dans l'onglet Général de la boîte de dialogue des propriétés de certificat. S'il indique que le certificat de la CA racine n'est pas fiable et doit être installé, allez à l'onglet Détails. Cliquez sur le bouton « Copier dans un fichier... » et suivez l'Assistant, en acceptant toutes les valeurs par défaut et en fournissant un nom de fichier et de dossier lorsque vous y êtes invité.

Ouvrez maintenant une nouvelle console MMC (Microsoft Management Console) en tant qu'administrateur de machine. Accédez à Fichier|Ajouter/Supprimer un composant logiciel enfichable (Ctrl+M), sélectionnez Certificats et ajoutez-le pour le compte d'ordinateur, en choisissant l'ordinateur local lorsque vous y êtes invité. Développez ensuite le nœud Certificats dans l'arborescence à gauche, faites de même pour les autorités de certificat racine de confiance. Cliquez avec le bouton droit et sélectionnez Toutes les tâches|Importer dans le menu contextuel. Importez le fichier de certificat exporté mentionné précédemment vers les autorités de certificat racine de confiance puis cliquez sur Terminer. L'utilisateur concerné doit ensuite redémarrer Outlook.

Ces instructions doivent être utilisées uniquement pour ajouter une CA racine dont vous savez qu'elle est fiable. Toutes les racines ne sont pas égales. Examinez soigneusement qui possède et utilise la CA racine avant d'utiliser cette méthode pour ajouter une racine au magasin pour tout le système. Si votre entreprise contrôle la liste des racines de confiance via la stratégie de groupe, la configuration sera définie sur les systèmes client. Dans ce cas, les instructions peuvent ne pas fonctionner. Si c'est le cas, vous pouvez avoir besoin d'explorer des alternatives telles que les sites Web ou les serveurs sécurisés pour échanger des données, si le courrier électronique ne bénéficie pas d'un environnement transparent et protégé.

Le deuxième problème que nous avons vu ci-dessus, les CA intermédiaires ne peuvent pas être validées, survient généralement dans deux situations : un client essayant de valider le certificat est incapable d'obtenir l'emplacement de l'Accès aux informations de l'Autorité (AIA) défini dans le certificat, ou le client dispose d'une version certificat de la CA intermédiaire qui ne correspond pas au document émis par la CA (le client dispose souvent d'une version antérieure). Ces conditions semblent très similaires dans l'interface utilisateur d'Outlook. Nous l'avons vu seulement dans une circonstance bien particulière lorsqu'une CA intermédiaire dans la chaîne expire et est réémise avant que les autres certificats subordonnés émis aient expiré.

Fondamentalement, ce problème survient lorsque la chaîne comprend des vides. Certains certificats parent peuvent ne pas être détaillés ou intégrés de manière appropriée dans le nœud terminal, ce qui complique la situation.

Pour résoudre ce problème, l'expéditeur devra ouvrir un nouveau message et cliquer sur les Options pour les nouveaux messages, sur le bouton Paramètres de Sécurité, puis sur le bouton Modifier les paramètres. Cliquez maintenant sur le bouton Choisir pour le certificat de signature, puis sur le bouton Afficher le certificat dans le menu contextuel. Accédez à l'onglet de Chemin d'accès de certification, sélectionnez l'émetteur du nœud terminal (un niveau plus haut dans la chaîne) et cliquez sur le bouton Afficher le certificat. Cliquez sur l'onglet Détails, sur le bouton Copier dans un fichier..., puis terminez l'Assistant d'exportation, en sélectionnant PKCS #7 (.P7B). Assurez-vous que l'option « Inclure tous les certificats dans le chemin d'accès de certification » est activée, comme illustré à la figure 3. Enfin, envoyez le fichier de chaîne exporté au destinataire souhaité.

Figure 3** Résolution des vides dans une chaîne de certificats **(Cliquez sur l'image pour l'agrandir)

Après avoir obtenu la chaîne de certificats exportée, le destinataire devra ouvrir et importer la chaîne tout comme nous avons importé une racine précédemment. La seule différence est que le dossier de stockage choisi doit être celui des Autorités de certification intermédiaires. Si le message s'ouvre et que le certificat est affiché comme valide dans Outlook, les choses fonctionnent correctement.

Quant au troisième problème, les CRL non disponibles, ce problème est relativement facile à corriger. La réponse initiale d'Outlook paraîtra très similaire au problème précédent. Cependant, l'erreur s'affichera même si les CA de signature racine ou intermédiaires sont fiables. Pour chaque niveau de la chaîne de certificats au-dessus de la feuille, ouvrez les propriétés de certificat, puis l'onglet de détails et regardez le champ appelé « Points de distribution de la liste de révocation de certificats ».

Pour chaque point de distribution CRL énuméré (surtout ceux qui sont accessibles sur Internet), vérifiez que l'URL du fichier CRL peut être ouverte. Comme chaque niveau est validé, montez d'un niveau dans la chaîne. Si aucune CRL ne peut être acquise, c'est probablement la source du problème. Pour résoudre le problème, vous devez vérifier que votre stratégie de réseau locale ne bloque pas votre accès. Sinon, essayez de contacter l'entreprise qui possède l'autorité de certification ou attendez que le point de distribution CRL de celle-ci revienne à l'état opérationnel.

Certificats de distribution

La distribution est le plus facile. Le message signé est transmis à un serveur de messagerie, qui l'envoie ensuite d'un emplacement à un autre via une méthode éprouvée, SMTP. Le problème que nous avons vu avec le courrier signé ou chiffré en transit est que certains systèmes de courrier refusent ou arrêtent des messages signés ou chiffrés qui passent par eux. La solution est de travailler avec le responsable informatique du système pour obtenir les types de message autorisés. Bien sûr, vous pouvez avoir à assumer le fait que certains types de message sont bloqués. La partie qui reçoit peut avoir une bonne raison pour ne pas autoriser de messages chiffrés dans un environnement d'exploitation particulier.

Réponses de chiffrement

Pour créer une réponse chiffrée (en supposant que le processus de démarrage décrit ci-dessus est déjà terminé), l'expéditeur doit créer seulement un message puis cliquer sur le bouton Chiffrer (la petite enveloppe jaune avec le cadenas bleu portant l'inscription Chiffrer) dans la fenêtre de composition du message. Si ce bouton est indisponible, suivez la procédure d'envoi d'un message signé, sauf à la dernière étape et activez la case à cocher « Crypter le contenu des messages et des pièces jointes ».

La signature S/MIME n'est pas nécessaire pour envoyer un message chiffré à un destinataire, mais les deux fonctionnent certainement bien ensemble, puisque la signature permet au lecteur de valider l'expéditeur (la fonction de chiffrement ne demande rien à l'expéditeur). Le processus de chiffrement essaiera de chiffrer le message avec les clés publiques connues de tous destinataires. Si le système est incapable de trouver des certificats pour certains destinataires souhaités, ils seront marqués dans un menu contextuel qui offre d'envoyer le message non chiffré, comme illustré à la figure 4.

Figure 4** Vous pouvez décider d'envoyer un message non chiffré si vous rencontrez un problème avec un certificat **(Cliquez sur l'image pour l'agrandir)

Par défaut, la signature et le chiffrement doivent fonctionner avec les autres systèmes client configurés de manière similaire, mais parfois la messagerie interversion chiffrée ou signée peut présenter des problèmes si le hachage ou l'algorithme de chiffrement ne sont pas pris en charge à un niveau inférieur. Nous avons rencontré ce problème en envoyant un message électronique signé (utilisant SHA-512 comme algorithme de hachage) à un utilisateur exécutant Windows XP SP2. Comme le système de réception ne prenait pas en charge le hachage, l'utilisateur ne pouvait pas valider la signature ou lire le message. Cependant, il est peu probable que des utilisateurs rencontrent beaucoup de problèmes à ce stade sauf si les valeurs par défaut d'Outlook sont modifiées.

En recevant le message, le destinataire souhaité doit pouvoir l'ouvrir, étant donné que la clé privée associée au certificat public est disponible. Encore une fois, l'utilisateur peut être invité à fournir un jeton supplémentaire pour prouver la possession de la clé privée, en fonction de la manière dont elle a été déployée. Les autres utilisateurs qui ont effectué un processus de démarrage similaire peuvent bénéficier de communications similaires, signées et chiffrées avec l'expéditeur. Si un utilisateur modifie sa clé privée à un certain moment (peut-être en raison d'un ordinateur perdu), il devra redemander des certificats et redistribuer un fichier de message ou de certificat signé à d'autres personnes qui souhaitent échanger le courrier chiffré.

Conclusion

Le fonctionnement de la messagerie S/MIME signée et chiffrée entre deux utilisateurs appartenant à deux entreprises ou annuaires différents n'est généralement pas beaucoup plus compliqué que ce dont nous venons de parler. La signature est très pratique lorsqu'elle est utilisée correctement, car elle ajoute de l'authenticité au message. Pour les informations sensibles, le chiffrement fournit un niveau supplémentaire de confidentialité pour les données en transit. Combinés, les deux éléments permettent l'authenticité de la source et la confidentialité des données. Avec le processus que nous avons décrit ici, la plupart des utilisateurs profiteront sans difficulté de ces fonctionnalités.

Matt Clapham, CISSP, est ingénieur sécurité dans le service informatique de Microsoft. Pendant la journée, il effectue des évaluations de sécurité sur les applications métier et la nuit il joue avec la technologie, les jeux, la musique électronique ou la sécurité. Il parle de temps en temps à la communauté informatique dédiée à la sécurité Puget Sound. Vous pouvez le contacter à matt.clapham@microsoft.com.

Blake Hutchinson est analyste support dans le groupe Business Online Services Group (BOSG) chez Microsoft. Son rôle inclut le support d'exploitation et l'évaluation d'outils métier créés à usage interne pour les clients d'entreprise de BOSG. Blake apprécie la photographie, le ski et les jeux électroniques. Vous pouvez le contacter à blakeh@microsoft.com.

© 2008 Microsoft Corporation and CMP Media, LLC. Tous droits réservés. Toute reproduction, totale ou partielle, est interdite sans autorisation préalable..