Les certificats sur Mac

Avec l’importance qu’Apple accorde de plus en plus à la sécurité, l’utilisation de certificats numériques s’impose chaque jour davantage du coté des serveurs. Mais qu’est-ce au juste qu’un certificat ?

Les principes de base de la sécurité des échanges numériques

La sécurité des échanges suppose notamment de s’assurer qu’un message soit authentique (il faut être certain de savoir qui l’a envoyé), confidentiel (il ne peut être lu que par les personnes autorisées) et intègre (il faut être certain qu’il n’a pas été modifié). Sur ce dernier point, on utilise habituellement la technique du hashage, qui permet d’associer à un message une empreinte unique, calculable et vérifiable. L’authenticité, elle, sera assurée par une signature numérique. La confidentialité enfin, sera assurée par les techniques de chiffrement.

Le chiffrement est un procédé permettant de rendre un message ou un document illisible en l’absence d’une clé, dite clé de chiffrement. On différencie le chiffrement symétrique (on utilise la même clé pour chiffrer et déchiffrer) du chiffrement asymétrique (les clés sont différentes).

L’un des premiers algorithme de chiffrement symétrique est le Data Encryption Standard (DES), standardisé en 1976, qui utilisait une clé de chiffrement de 56 bits. Le DES a été remplacé en 2000 par l’Advanced Encryption Standard (AES), utilisant une clé de 128 bits.

On utilise souvent les personnages d’Alice et Bob pour illustrer les échanges en cryptographie. Le chiffrement symétrique est une technique assez simple : si Alice veut envoyer un message à Bob, elle doit utiliser une clé secrète, qui rendra le message illisible. Cette même clé servira à Bob pour déchiffrer le message :

Bien entendu,se pose alors la question de la confidentialité de la clé : si celle-ci transite par un moyen non sécurisé et qu’elle peut être utilisée par un tiers, la confidentialité de l’échange est compromise.

C’est là qu’intervient la notion de chiffrement asymétrique, qui utilise deux clés : la clé publique et la clé privée. Alors que la clé publique permettra simplement de le chiffrer le message, seule la clé privée permettra de déchiffrer :

L’algorithme de chiffrement asymétrique le plus répandu à ce jour est le RSA, du nom des trois inventeurs qui en sont à l’origine : Ronald Rivest, Adi Shamir et Leonard Adleman.

L’exemple de plus parlant de chiffrement asymétrique est le protocole HTTPS, utilisé notamment sur les sites e-commerce. Le protocole HTTP, qui permet d’accéder à un site web, ne propose aucun chiffrement. Si un individu mal intentionné – appelons-le Oscar – trouve le moyen de détourner le message de Bob contenant par exemple le nom et le mot de passe d’accès au site concerné, il pourra le lire sans problème :

Avec l’utilisation du protocole HTTPS, les données sont chiffrées , et seul le serveur contenant la clé privée pourra le déchiffrer :

L’utilisation du protocole HTTPS est généralement indiquée dans le navigateur par un cadenas, et l’URL commence toujours par https://.

Bien entendu, la sécurité du système repose sur la validité de la clé publique ; imaginons que vous pensiez être sur le site Web de votre banque mais que  vous consultiez en réalité un clone parfait de celui-ci, même avec une connexion HTTPS, le serveur pirate pourra alors déchiffrer les messages que vous lui envoyez, puisque vous lui faites confiance.

C’est là qu’interviennent les tiers de confiance, représentées par les Autorités de certification sur le présent sujet. Il s’agit de sociétés habilitées à émettre des signatures électroniques reconnues  : VeriSign, GlobalSign, Certinomis, DigiCert, etc. Sur Mac, Apple accorde sa confiance à un certain nombre d’autorités de certification, sur une période définie. On peut en retrouver la liste avec l’utilitaire Trousseau d’accès (Keychain Access), dans le dossier /Applications/Utilitaires :

Le plus simple serait de comparer le certificat à une pièce d’identité : celle-ci prouve votre existence vis-à-vis de l’administration, généralement via une photo, une date de naissance et surtout la reconnaissance d’une autorité administrative, qui est ici l’autorité de certification. Sur une carte d’identité, l’autorité administrative (la préfecture) est indiquée au verso :

Plus précisément, pour obtenir ce certificat (pièce d’identité), nous nous sommes adressé à une autorité d’enregistrement (la mairie) qui a validé notre identité et demandé à l’autorité de certification (la préfecture) de produire le document certifié. Ce sont ces entités, associés à un système de révocation (CRL ou Certificate Révocation List) qui formeront l’Infrastructure de Gestion de Clé (ou PKI – Public Key Infrastructure).

Lorsque votre navigateur accède à un site via le protocole HTTPS, il vérifie la validité du certificat proposé en comparant sa signature à celle de l’autorité de certification présente dans le trousseau d’accès. Si elle n’est pas conforme, ou si l’autorité n’est pas présente dans le trousseau racine, le navigateur vous alertera et vous conseillera de ne pas continuer votre navigation. Il est à noter que certains navigateurs, comme Firefox, utilisent leur propre liste d’autorités de certification.

Il est à noter que l’assistant de certification du Mac (que l’on peut appeler via le Trousseau d’Accès) nous permet de créer nous-même une autorité de certification autonome. Cependant, cette opération n’aurait de sens que pour approuver des certificats émis par vos propres serveurs à vos propres postes clients, en utilisant par exemple le protocole SCEP (Simple Certificate Enrollment Protocol).

La norme la plus répandue pour la spécification des certificats est la X.509, qui précise les données suivantes :

• La version du certificat ;
• son numéro de série ;
• l’identifiant de son algorithme de signature ;
• le DN (Distinguished Name) de l’autorité de certification ;
• sa date d’expiration ;
• le DN de l’utilisateur ;
• les informations relatives à la clé publique ;
• l’identifiant unique du signataire et du détenteur du certificat ;
• ses extensions ;
• la signature de ces informations par l’autorité de certification.

Utilisation des certificats

On peut donc créer des certificats pour répondre à différents besoins (signature, chiffrement, authentification, etc). Par exemple, assurer une authentification Web comme vu ci-dessus ou accéder à un serveur d’annuaire avec un certificat TLS (Transport Layer Security, auparavant nommé SSL – Secure Sockets Layer), protéger les communications entre ordinateurs sur un réseau avec un certificat VPN (Virtual Private Network), ou encore signer et chiffrer le courrier électronique avec un certificat S/MIME (Secure Multi-Purpose Internet Mail Extensions). On peut également utiliser des certificats de signature de code pour valider le code source d’une application.

Il est par exemple très simple de créer un certificat SSL, dans le Trousseau d’accès, avec l’assistant de certification de Mac OS X  :

En l’absence d’autorité de certification, il est possible de créer une racine auto-signée ; bien entendu, un message vous alertera sur la viabilité de celui-ci :

Le certificat apparaitra alors dans votre trousseau session, et vous pourrez y vérifier l’existence de la clé privée :

Imaginons maintenant que vous souhaitiez viabiliser l’identité d’un serveur sur Mac OS X, par exemple pour accéder au serveur Web en HTTPS ; il vous faudra alors un certificat approuvé par une autorité de certification reconnue. Cette opération s’effectue en plusieurs étapes :

• Créer un certificat auto-signé ;
• créer la demande de certificat auprès de l’autorité : c’est le CSR (Certificate Signing Request) ;
• envoyer la CSR à l’autorité de certification ;
• remplacer le certificat auto-signé par le certificat valide ;
• utiliser le Trousseau d’Accès pour importer le certificat valide, dans le cas d’un certificat signé par une autorité intermédiaire ;
• configurer le serveur pour exploiter le certificat.

La création d’une CSR est relativement simple avec l’assistant de certification de Mac OS X :

Il suffit ensuite d’envoyer le fichier généré (au format .certSigning) à l’autorité de certification. Celui-ci vous renverra ensuite le fichier (généralement au format .cer) qui vous permettra de remplacer le certificat auto-signé.

Signalons au passage qu’Apple propose un service spécifique, le Apple Push Notification Service (APNs) permettant à un tiers (éditeur, société de services…) d’envoyer des messages ou des commandes à n’importe quel appareil iOS. Ce service utilise une technologie push via une connexion IP constamment ouverte pour transmettre des notifications depuis les serveurs du tiers vers les appareils Apple.

N’hésitez pas à nous contacter pour toute information sur les certificats ou la sécurisation de vos serveurs.

M. Saliou