Outils pour utilisateurs

Outils du site


sysadmin:securite:ca:chiffrement

Notions élémentaires sur le chiffrement (PGP, SSH, SSL, TLS, …)

Chiffrement

Pour chiffrer (on dit aussi coder ou crypter1)), on peut utiliser deux méthodes :

  • l'une dite « symétrique », qui utilise une seule clef de chiffrement (mot de passe par exemple) ; cette méthode permet de chiffrer très rapidement de grandes quantités de données mais présente un inconvénient majeur : l'échange des clefs nécessite un canal sûr.
  • l'autre dite « asymétrique », qui utilise des clefs constituées de deux parties : une partie privée que le propriétaire garde secrète et l'autre publique ; la partie publique permet de chiffrer tandis que la partie privée permet de déchiffrer (mais on peut inverser les deux clefs, comme on le verra pour la signature).

Le chiffrement à clefs privées

Le principe repose sur des fonctions mathématiques difficilement réversibles :

  on chiffre un message avec la clef ;
  on déchiffre à l'aide de la même clef.

On utilise une fonction et sa réciproque mais une seule et même clef.

Le chiffrement à clefs publiques

Le principe repose sur des fonctions mathématiques à sens unique :

  on chiffre un message avec une clef publique ;
  le message chiffré est déchiffré à l'aide de la clef privée ;

on retrouve alors le texte clair initial.

On peut inverser l'ordre des clefs et l'on retrouve aussi le texte clair. Cette possibilité permet de signer des documents :

  l'émetteur chiffre le document avec sa clef privée ;
  pour vérifier l'authenticité du document on déchiffre avec la clef publique de l'auteur ;

on vérifie ainsi que seul le propriétaire de la clef privée a pu chiffrer le document. Le couple formé de la clef privée et de la clef publique est unique, à une clef publique correspond une unique clef privée et réciproquement.

Ici, on utilise une unique fonction mathématique mais deux clefs.

Les certificats

Certificats X.509

Un certificat X.509 est un petit fichier qui contient (entre autres) :

  • l'identification de son propriétaire ;
  • la durée de validité du certificat ;
  • la clef publique du propriétaire ;
  • diverses informations sur l'autorité de certification émettrice.

Il est signé par une autorité de certification. Ce certificat est l'équivalent numérique d'une pièce d'identité. Son propriétaire peut ainsi prouver qui il est (étend entendu que chaque certificat est protégé par un mot de passe).

Confiance et autorité de certification

Une autorité de certification est un tiers de confiance qui émet des certificats et permet à tout moment d'en vérifier la validité. Pour cela, elle signe les certificats qu'elle émet. Elle dispose pour cela d'un certificat particulier : son propre certificat (qui est parfois auto-signé) : son certificat racine.

Le certificat racine d'une autorité de certification permet de vérifier la validité de tous les certificats émis par cette autorité (en vérifiant signature et date de validité).

L'intérêt dans le contexte des échanges sur Internet : SSL

  • Avant de taper un login et un mot de passe, vous vous posez une question légitime : est-ce le vrai serveur ? (typiquement lors d'achat ou de gestion de comptes en ligne par exemple),
  • lorsque votre mot de passe transite enfin, vous vous posez une autre question légitime : les données sont-elles confidentielles ?

Le protocole SSL (on parle aussi de TLS) résout ces deux problèmes d'un seul coup : il utilise pour cela des certificats X.509. Ainsi, lors de l'établissement d'une connexion SSL le serveur présente son certificat ; le client doit vérifier ce certificat avant d'accepter ou non la communication ; ensuite, il utilise la clef contenu dans le certificat pour négocier avec le serveur une clef de chiffrement symétrique (qui change à chaque session) pour chiffrer les données.

Enfin, en délivrant des certificats aux utilisateurs, le serveur peut lui aussi être en mesure de vérifier que le client est bien celui qu'il prétend être.

Par défaut, les navigateurs Web disposent des certificats d'un certain nombre d'autorités de certification. Les internautes font donc confiance aux sites dont les certificats ont été signés par ces dernières (le plus souvent sans le savoir).

Ainsi, lorsque l'utilisateur accède à des sites sécurisés et que le certificat de ceux-ci sont signés par une autorité connue du logiciel, les communications sont transparentes. Dans le cas contraire, certains logiciels se plaignent bruyamment (voir Certificats : messages d'alertes de sécurité ?).

C'est à l'utilisateur d'installer d'autres certificats pour approuver de nouvelles autorités de certification (voir Installation de certificats (certificats racines et de serveurs) pour un guide pas à pas).

Le protocole SSL a été prévu pour s'intercaler facilement avec les protocoles existants. Ainsi, HTTP est le principal protocole du Web, celui qui permet l'échange de documents hypertextes comme la page que vous êtes en train de lire. Sa version sécurisée par SSL s'appelle HTTPS et on le vérifie dans les adresses :

(bien lire l'adresse avant de suivre l'un des liens ; le second lien vous posera peut-être des problèmes si votre navigateur ne connaît pas notre autorité de certification… mais vous savez maintenant quoi faire ;-)).

De la même manière, les protocoles de consultation du courrier POP3 et IMAP se sécurisent à l'aide de SSL et les versions sécurisées sont appelées POPS et IMAPS ; pour l'envoi de courrier, SMTP devient SMTPS. Pour l'échange de fichiers, FTP s'étend en FTPS. De plus, les certificats X.509 n'interviennent pas que pour SSL ; pour signer et / ou chiffrer le courrier électronique, S/MIME utilise des certificats ; pour sécuriser les communications entre des sous-réseaux, IPsec utilise aussi des certificats X.509…

Signature électronique

Les clefs cryptographiques asymétriques permettent de signer un fichier. Les certificats permettent donc de signer les emails. Et vu ce qui précède, si on peut vérifier la signature (cryptographique) d'un message électronique, on est assuré que :

  • l'expéditeur est bien qui il prétend être,
  • le message n'a pas été altéré depuis sa signature.

On s'assure ainsi que le contenu n'a pas été modifié depuis l'envoi par l'expéditeur et que l'identité de l'expéditeur n'a pas été usurpée par un tiers.

Dans le modèle que l'on vient de présenter, une pièce jointe embarque la signature des messages électroniques (de type S/MIME i. e. application/x-pkcs7-signature nommée smime.p7s).

PGP et GnuPG

Depuis quelques années seulement, une personne physique peut disposer gratuitement d'un certificat (voir par exemple CAcert). Dès lors, la seule alternative a longtemps été le logiciel PGP (Pretty Good Privacy ou « plutôt bonne intimité ») ou son concurrent libre GnuPG. Les deux logiciels sont compatibles et savent lire le même format de fichiers (clefs, messages chiffrés, messages signés), normalisé et nommé OpenPGP.

La gestion des clefs (certificats) change ici sensiblement : chacun a son réseau de confiance (Web of Trust) et gère ses clefs et les clefs publiques de ses contacts. Il n'y a plus de notion de tiers de confiance2), il n'y a plus besoin d'une infrastructure souvent coûteuse et l'utilisateur est indépendant.

Ces deux logiciels sont essentiellement utilisés pour signer et/ou chiffrer des courriers électroniques mais servent aussi au chiffrement de fichiers (stockés sur un disque dur par exemple). Dans le cadre de la messagerie électronique, les garanties que confèrent chiffrement et signature avec ces logiciels et ces techniques sont les mêmes qu'avec des certificats :

  • garantie que le message n'a pu être signé que par le propriétaire de la clef,
  • garantie que le message ne peut être lu que par le propriétaire de la clef (s'il est chiffré) ou altéré durant le transfert (s'il est signé).
Évidemment, ces garanties ne tiennent que sous réserve que les clefs ne sont pas compromises. Il faut donc gérer ces dernières avec grand soin ; en particulier on ne les stocke jamais sur des supports amovibles (clefs USB) sauf mesures particulières (chiffrement de la clef) et on protège ses clefs par des phrases secrètes fortes (longues).

Voir aussi la page OpenPGP.

Quelle est la sécurité réelle ?

Sur le plan théorique, en l'état actuel des connaissances en Théorie des nombres et en Cryptologie, ces algorithmes sont considérés comme sûrs.

Sur le plan pratique, la qualité des logiciels est fondamentale. Par exemple, il y a plusieurs mois il y a eu un très sérieux bug sur plusieurs systèmes GNU/Linux dû à une variable mal initialisée. Si le logiciel utilisé présente une faille, la sécurité des données est compromise.

D'autre part, la gestion des clefs est souvent l'angle d'attaque le plus facile (phrases secrètes faibles par exemple).

1)
Horrible anglicisme !
2)
ou plutôt chacun assure lui-même ce service
sysadmin/securite/ca/chiffrement.txt · Dernière modification: 2014/06/24 18:02 (modification externe)