Chiffrement asymétrique et échange de clés publiques
Le chiffrement asymétrique repose sur deux clés liées mathématiquement : une clé publique, que l’on peut diffuser, et une clé privée, qui doit rester secrète. Cette séparation permet d’établir une communication protégée sans transmettre préalablement un secret commun.
Imaginons qu’une entreprise envoie des données confidentielles à une nouvelle partenaire. Elle peut chiffrer une petite clé de session avec la clé publique de cette destinataire ; seule la clé privée correspondante permettra de la retrouver.
Les rôles des deux clés se distinguent selon l’usage :
- Clé publique : chiffrement de secrets ou vérification de signatures
- Clé privée : déchiffrement ou création de signatures numériques
- Certificat numérique : association vérifiable entre une identité et une clé publique
La diffusion d’une clé ne suffit toutefois pas à prouver son propriétaire. Sans vérification, un intermédiaire malveillant pourrait substituer sa propre clé à celle du destinataire ; l’authentification est donc essentielle.
Cryptographie à clé publique, RSA et courbes elliptiques
Une fois le principe des deux clés établi, le choix de l’algorithme détermine les performances et les usages possibles. La cryptographie à clé publique englobe notamment RSA et la cryptographie sur courbes elliptiques.
RSA pour le chiffrement et les signatures
RSA s’appuie sur la difficulté pratique de factoriser de grands nombres. Il demeure utile dans certains systèmes existants, mais son coût de calcul le rend inadapté au chiffrement direct de fichiers volumineux.
Pour un fichier de plusieurs mégaoctets, on génère plutôt une clé symétrique aléatoire, puis on chiffre cette petite clé avec une méthode adaptée. Les données, elles, sont chiffrées rapidement avec un algorithme symétrique.
Courbes elliptiques et échange de secrets
La cryptographie sur courbes elliptiques permet d’obtenir des mécanismes de sécurité comparables avec des clés plus courtes que RSA. ECDH et X25519 servent à établir un secret partagé sur un canal public, sans envoyer ce secret tel quel.
Selon le NIST, les mécanismes post-quantiques standardisés en 2024 préparent une évolution des systèmes face aux futurs ordinateurs quantiques. Ils ne remplacent pas automatiquement les mécanismes classiques dans tous les déploiements : les migrations demandent une analyse de compatibilité.
Les usages principaux se distinguent ainsi :
| Mécanisme | Fonction habituelle | Point d’attention |
|---|---|---|
| RSA | Chiffrement de secrets ou signatures | Calculs plus coûteux et clés longues |
| ECDH | Établissement d’un secret partagé | Authentifier les clés échangées |
| X25519 | Échange de clés fondé sur une courbe elliptique | Employer une bibliothèque éprouvée |
| ML-KEM | Encapsulation post-quantique de clés | Prévoir la compatibilité des systèmes |
Chiffrement hybride et sécurité des communications
Comme les algorithmes asymétriques sont peu adaptés aux gros volumes, les systèmes associent généralement les deux familles de chiffrement. Cette approche hybride combine l’échange sécurisé d’une clé avec la rapidité du chiffrement symétrique.
Dans une connexion TLS, les parties établissent un secret de session, puis l’utilisent pour protéger les échanges. Avec ECDHE, les clés temporaires contribuent à la confidentialité persistante : la compromission ultérieure d’une clé durable ne révèle pas automatiquement les anciennes sessions.
Un échange hybride suit généralement ces étapes :
- Générer une clé de session aléatoire
- Établir ou protéger cette clé par un mécanisme asymétrique
- Chiffrer les données avec un algorithme symétrique authentifié
- Vérifier l’authenticité avant d’exploiter les données reçues
Selon le NIST, ML-KEM, publié comme FIPS 203, est un mécanisme d’encapsulation de clés post-quantique. Dans certains projets, une combinaison classique et post-quantique permet d’évaluer une migration sans abandonner immédiatement l’interopérabilité existante.
Infrastructure à clés publiques et certificats numériques
Pour que l’échange fonctionne à grande échelle, les organisations s’appuient sur une infrastructure à clés publiques, souvent appelée ICP ou PKI. Elle comprend des autorités de certification, des règles de vérification et des mécanismes de gestion des certificats numériques.
Un certificat lie une identité à une clé publique selon des informations vérifiables. Le navigateur contrôle notamment la chaîne de confiance et la validité du certificat ; une alerte ne doit pas être ignorée, car elle peut signaler une erreur ou une interception.
Les contrôles utiles dans une ICP comprennent :
- Vérification de l’identité et du nom de domaine
- Contrôle de la période de validité du certificat
- Renouvellement avant expiration
- Révocation en cas de compromission d’une clé
Selon le NIST, ML-DSA et SLH-DSA sont des standards de signatures post-quantiques, respectivement FIPS 204 et FIPS 205. Une signature numérique contribue à vérifier l’origine et l’intégrité d’un document, mais ne chiffre pas son contenu.
Bonnes pratiques pour un échange de clés fiable
Une architecture correcte peut être fragilisée par une implémentation imprudente. Il faut privilégier des bibliothèques cryptographiques reconnues, limiter l’accès aux clés privées et séparer celles-ci des données chiffrées.
La protection des données exige aussi l’authentification, car le chiffrement seul ne garantit pas qu’un message n’a pas été modifié. Les modes AEAD, comme AES-GCM ou ChaCha20-Poly1305, associent confidentialité et vérification d’intégrité.
Les erreurs les plus risquées à prévenir sont :
- Réutilisation d’un nonce avec la même clé en mode GCM
- Chiffrement sans mécanisme d’authentification
- Stockage d’une clé privée dans le même emplacement que les données protégées
- Conception d’algorithmes cryptographiques internes non audités
Dans un service de partage de fichiers, par exemple, la clé de session doit être conservée dans un gestionnaire de secrets, tandis que les accès et les renouvellements font l’objet de contrôles réguliers.
Les choix pratiques peuvent être comparés selon leur rôle :
| Décision | Pratique recommandée | Risque réduit |
|---|---|---|
| Chiffrement des données | Mode AEAD éprouvé | Altération non détectée |
| Gestion des nonces | Unicité garantie pour chaque clé | Fuite de données ou falsification |
| Protection des secrets | Stockage contrôlé et accès limité | Vol ou exposition de clés |
| Choix des outils | Bibliothèques reconnues et maintenues | Erreurs d’implémentation |
Source : National Institute of Standards and Technology, « Module-Lattice-Based Key-Encapsulation Mechanism Standard », FIPS 203, 2024 ; National Institute of Standards and Technology, « Module-Lattice-Based Digital Signature Standard », FIPS 204, 2024 ; National Institute of Standards and Technology, « Stateless Hash-Based Digital Signature Standard », FIPS 205, 2024.
