Chiffrement asymétrique
Introduction
Après avoir exploré le chiffrement symétrique et ses défis, notamment la gestion des clés, découvrons une approche révolutionnaire : le chiffrement asymétrique (ou cryptographie à clé publique).
Le chiffrement asymétrique a été inventé dans les années 1970. Il a profondément transformé la cryptographie et a permis le développement de nombreuses applications que nous utilisons aujourd'hui, comme le commerce en ligne sécurisé (HTTPS) et les signatures numériques.
Dans cette section, nous allons découvrir :
- Le principe fondamental du chiffrement asymétrique.
- Ses avantages (et ses quelques inconvénients) par rapport au chiffrement symétrique.
- Les algorithmes de chiffrement asymétrique les plus courants (RSA, ECC).
- Le protocole d'échange de clés Diffie-Hellman.
- Les certificats numériques et les infrastructures à clé publique (PKI).
Accrochez-vous, car nous allons plonger dans des concepts un peu plus abstraits, mais ô combien importants pour la sécurité informatique moderne !
Commençons par le principe de base du chiffrement asymétrique.
Principes et algorithmes (RSA, ECC)
Le chiffrement asymétrique, contrairement au chiffrement symétrique, utilise deux clés distinctes : une clé publique et une clé privée. C'est ce qui fait toute sa force et sa particularité.
Principe de base
-
Paire de clés : Chaque utilisateur (ou chaque entité) génère une paire de clés :
- Clé publique : Cette clé peut être diffusée publiquement, à tout le monde. Elle sert à chiffrer les messages destinés à l'utilisateur.
- Clé privée : Cette clé doit rester strictement secrète. Elle sert à déchiffrer les messages chiffrés avec la clé publique correspondante.
-
Chiffrement : Si Alice veut envoyer un message confidentiel à Bob, elle utilise la clé publique de Bob pour chiffrer le message.
-
Transmission : Alice envoie le message chiffré à Bob (via un canal potentiellement non sécurisé).
-
Déchiffrement : Bob utilise sa clé privée pour déchiffrer le message et retrouver le texte clair.
Il est impossible de retrouver la clé privée à partir de la clé publique (c'est sur ce principe mathématique que repose la sécurité du chiffrement asymétrique).
Avantages du chiffrement asymétrique
- Résout le problème de la distribution des clés dans le chiffrement symétrique : Plus besoin d'échanger une clé secrète au préalable. Il suffit de connaître la clé publique du destinataire.
- Scalabilité : Chaque utilisateur n'a besoin que d'une seule paire de clés, quel que soit le nombre de ses correspondants.
- Authentification et signature numérique : Le chiffrement asymétrique permet de mettre en œuvre des mécanismes d'authentification et de signature numérique (nous y reviendrons).
Inconvénients du chiffrement asymétrique
- Lenteur : Les algorithmes de chiffrement asymétrique sont beaucoup plus lents que les algorithmes symétriques. C'est pourquoi on ne les utilise généralement pas pour chiffrer de grandes quantités de données.
- Complexité : Les concepts mathématiques sous-jacents sont plus complexes que ceux du chiffrement symétrique.
Algorithmes de chiffrement asymétrique courants
RSA (Rivest-Shamir-Adleman)
- Inventeurs : Ron Rivest, Adi Shamir et Leonard Adleman (1977).
- Principe : Repose sur la difficulté de factoriser de grands nombres premiers (c'est-à-dire de trouver les nombres premiers qui, multipliés entre eux, donnent le nombre initial).
- Utilisations :
- Chiffrement (mais surtout pour échanger des clés symétriques).
- Signature numérique.
- Échange de clés (par exemple, dans le protocole TLS/SSL).
- Sécurité : RSA est considéré comme sûr si l'on utilise des clés suffisamment longues (au moins 2048 bits, voire 4096 bits aujourd'hui).
Explications génération des clés RSA
1. Génération des clés :
-
Choisir deux grands nombres premiers et :
- C'est l'étape cruciale pour la sécurité de RSA. et doivent être très grands (typiquement, des centaines de chiffres) et choisis aléatoirement. En pratique, on utilise des générateurs de nombres premiers cryptographiquement sûrs.
- Exemple (très simplifié, avec de petits nombres !) :
p = 61
q = 53
-
Calculer ( est le module) :
- est la taille du module RSA (en bits). C'est un nombre public, qui fait partie à la fois de la clé publique et de la clé privée.
- Exemple :
-
Calculer ( est l'indicatrice d'Euler) :
- représente le nombre d'entiers inférieurs à et premiers avec (c'est-à-dire, qui n'ont pas de diviseur commun avec autre que 1).
- Comme et sont premiers, on a la formule simplifiée : .
- Exemple :
-
Choisir un entier (l'exposant de chiffrement) tel que et :
- est un nombre public, qui fait partie de la clé publique.
- La condition signifie que et doivent être premiers entre eux (leur plus grand commun diviseur doit être 1).
- On choisit souvent , car c'est un nombre premier qui a de bonnes propriétés pour le chiffrement (il est facile à calculer avec). Mais d'autres valeurs sont possibles.
- Exemple :
e = 17 // On vérifie que 1 < 17 < 3120 et que pgcd(17, 3120) = 1
-
Calculer l'entier (l'exposant de déchiffrement) tel que :
- est la clé privée. Il doit être gardé secret.
- est l'inverse modulaire de modulo . Cela signifie que le reste de la division de par est égal à 1.
- On calcule en utilisant l'algorithme d'Euclide étendu.
- Exemple (algorithme d'Euclide étendu simplifié) :
Pour trouver l'inverse modulaire de 17 modulo 3120, on cherche tel que . On peut utiliser l'algorithme d'Euclide étendu, ou, dans ce cas simple, essayer quelques valeurs :
d = 2753 // On vérifie que (17 * 2753) % 3120 = 1
2. Clé publique et clé privée :
-
Clé publique :
- Dans notre exemple :
-
Clé privée :
- Dans notre exemple :
3. Chiffrement :
-
Pour chiffrer un message (représenté par un entier inférieur à ), on calcule :
- est le texte chiffré.
-
Exemple :
- Supposons que le message à chiffrer soit .
- On calcule :
- Le texte chiffré est 2790.
4. Déchiffrement :
-
Pour déchiffrer un message chiffré , on calcule :
-
Exemple :
- Pour déchiffrer , on calcule :
- On retrouve bien le message original, 65.
Il faut garder la clé privée secrète.
Il est important de noter que cet exemple utilise de très petits nombres pour illustrer le principe. En réalité, , et doivent être des nombres de plusieurs centaines de chiffres (typiquement 2048 bits ou 4096 bits pour ) pour que RSA soit sûr. Avec de si petits nombres, l'exemple ci-dessus pourrait être facilement cassé par force brute.
De plus l'exemple ne montre pas comment trouver les nombres premiers, ce qui est un point critique.
Exemple (Python)
from cryptography.hazmat.primitives.asymmetric import rsa
from cryptography.hazmat.primitives import hashes
from cryptography.hazmat.primitives.asymmetric import padding
# 1. Génération de la Paire de Clés RSA
# -------------------------------------
private_key = rsa.generate_private_key(
public_exponent=65537, # Exposant public standard et sûr.
key_size=2048 # Taille de la clé en bits. 2048 est un minimum recommandé de nos jours.
)
# `private_key` contient la clé privée, qui doit être gardée *absolument secrète*.
# La clé privée est un objet complexe qui contient les paramètres nécessaires pour le déchiffrement et la signature.
public_key = private_key.public_key()
# Dérive la clé publique à partir de la clé privée. La clé publique peut être partagée sans risque.
# Elle sert à chiffrer les messages ou à vérifier les signatures.
# 2. Message à Chiffrer
# ---------------------
message = b"Ceci est un message secret."
# Le message est, comme pour le chiffrement symétrique, une chaîne d'octets (bytes).
# 3. Chiffrement RSA avec OAEP (Padding Optimal)
# -----------------------------------------------
ciphertext = public_key.encrypt(
message,
padding.OAEP( # OAEP est un schéma de padding *essentiel* pour la sécurité de RSA.
mgf=padding.MGF1(algorithm=hashes.SHA256()), # Fonction de génération de masque (MGF) basée sur SHA-256.
algorithm=hashes.SHA256(), # Fonction de hachage utilisée dans OAEP (SHA-256 recommandée).
label=None # Label optionnel (pas utilisé ici).
)
)
print(f"Texte chiffré : {ciphertext.hex()}")
# `public_key.encrypt()` chiffre le message en utilisant la clé publique et le padding OAEP.
# OAEP (Optimal Asymmetric Encryption Padding) est un schéma de padding qui ajoute de l'aléatoire
# et une structure au message avant le chiffrement RSA. C'est *crucial* pour éviter plusieurs attaques
# contre le "RSA brut" (sans padding). Ne *jamais* utiliser RSA sans padding comme OAEP ou PSS (pour la signature).
# MGF1 est une fonction de génération de masque standard.
# 4. Déchiffrement RSA avec OAEP
# ------------------------------
plaintext = private_key.decrypt(
ciphertext,
padding.OAEP( # *Même* paramètres OAEP que pour le chiffrement.
mgf=padding.MGF1(algorithm=hashes.SHA256()),
algorithm=hashes.SHA256(),
label=None
)
)
print(f"Texte déchiffré : {plaintext}")
# `private_key.decrypt()` déchiffre le message en utilisant la clé privée et le *même* schéma de padding OAEP.
# 5. Vérification
# ---------------
assert plaintext == message
# Vérifie que le message déchiffré est identique au message original. C'est une bonne pratique.
Dans cet exemple :
- On utilise la bibliothèque
cryptography
pour générer une paire de clés RSA, chiffrer et déchiffrer un message. - On utilise le mode de padding OAEP (Optimal Asymmetric Encryption Padding), qui est recommandé pour la sécurité.
- On utilise SHA-256 comme fonction de hachage.
ECC (Elliptic Curve Cryptography)
- Principe : Repose sur la difficulté du problème du logarithme discret sur les courbes elliptiques (un problème mathématique réputé difficile).
- Avantage : À niveau de sécurité équivalent, les clés ECC sont beaucoup plus courtes que les clés RSA. Cela se traduit par de meilleures performances (chiffrement et déchiffrement plus rapides, moins de consommation d'énergie, etc.).
- Utilisations :
- Chiffrement.
- Signature numérique.
- Échange de clés (ECDH, Elliptic Curve Diffie-Hellman).
- Sécurité : ECC est considéré comme sûr, mais il existe des débats sur la sécurité de certaines courbes elliptiques, notamment celles proposées par le NIST (National Institute of Standards and Technology).
ECC est de plus en plus utilisé, notamment dans les appareils mobiles et les objets connectés, où les ressources (puissance de calcul, mémoire, batterie) sont limitées.
Utilisation combinée du chiffrement symétrique et asymétrique
Dans la pratique, on combine souvent le chiffrement symétrique et asymétrique pour tirer parti de leurs avantages respectifs :
- Chiffrement hybride :
- On utilise le chiffrement asymétrique pour échanger une clé symétrique (appelée clé de session).
- On utilise ensuite le chiffrement symétrique (avec la clé de session) pour chiffrer les données elles-mêmes.
-
Avantages :
- Rapidité : Le chiffrement symétrique est rapide, ce qui permet de chiffrer de grandes quantités de données.
- Sécurité : Le chiffrement asymétrique permet d'échanger la clé de session de manière sécurisée.
- Simplicité de gestion des clés : Chaque utilisateur n'a besoin que d'une paire de clés asymétriques.
-
Exemple : C'est le principe utilisé par le protocole TLS/SSL (utilisé pour HTTPS).
Le chiffrement hybride est la méthode la plus couramment utilisée pour sécuriser les communications sur Internet.
Échange de clés (Diffie-Hellman)
L'échange de clés Diffie-Hellman (DH) est un protocole cryptographique qui permet à deux parties de se mettre d'accord sur une clé secrète commune, sans jamais échanger cette clé directement, et ce, même sur un canal de communication non sécurisé. C'est une brique essentielle de la cryptographie moderne.
L'échange de clés Diffie-Hellman a été inventé en 1976 par Whitfield Diffie et Martin Hellman. Il a été l'une des premières applications concrètes de la cryptographie à clé publique (même si, techniquement, DH n'est pas un algorithme de chiffrement, mais un protocole d'échange de clés).
Principe de base
L'échange de clés Diffie-Hellman repose sur la difficulté du problème du logarithme discret dans un groupe fini. Sans entrer dans les détails mathématiques, voici le principe :
-
Paramètres publics : Alice et Bob se mettent d'accord sur des paramètres publics : un grand nombre premier et un générateur (un nombre entier dont les puissances successives modulo génèrent tous les nombres entre 1 et ). Ces paramètres ne sont pas secrets.
-
Secrets privés :
- Alice choisit un nombre aléatoire secret .
- Bob choisit un nombre aléatoire secret .
-
Calcul des valeurs publiques :
- Alice calcule et envoie à Bob.
- Bob calcule et envoie à Alice.
-
Calcul du secret partagé :
- Alice calcule .
- Bob calcule .
Alice et Bob obtiennent le même secret partagé , car :
- Utilisation du secret partagé : Alice et Bob peuvent maintenant utiliser le secret partagé comme clé pour un algorithme de chiffrement symétrique (par exemple, AES).
Sécurité de Diffie-Hellman
La sécurité de Diffie-Hellman repose sur la difficulté du problème du logarithme discret :
-
Problème du logarithme discret : Étant donné , et , il est très difficile (computationnellement infaisable) de trouver si est suffisamment grand.
-
Attaquant (Eve) : Un attaquant qui intercepte les valeurs publiques et ne peut pas calculer le secret partagé , car il ne connaît ni ni .
Diffie-Hellman est vulnérable à l'attaque de l'homme du milieu (MitM) si les valeurs publiques et ne sont pas authentifiées. Un attaquant peut se faire passer pour Alice auprès de Bob et pour Bob auprès d'Alice, et établir un secret partagé différent avec chacun d'eux. C'est pourquoi Diffie-Hellman est souvent utilisé en combinaison avec des signatures numériques ou des certificats pour authentifier les parties.
Variantes de Diffie-Hellman
- Diffie-Hellman sur les courbes elliptiques (ECDH) : Une variante de Diffie-Hellman qui utilise les courbes elliptiques au lieu des nombres premiers. ECDH offre une meilleure sécurité pour une taille de clé donnée, ce qui le rend plus efficace.
Exemple (Python)
from cryptography.hazmat.primitives.asymmetric import dh
# --- 1. Initialisation des Paramètres Diffie-Hellman ---
# -------------------------------------------------------
parameters = dh.generate_parameters(generator=2, key_size=2048)
# On génère les paramètres Diffie-Hellman (DH) qui seront utilisés par Alice et Bob.
# - `generator=2`: Le générateur (g) est un petit entier (souvent 2 ou 5). Il fait partie des paramètres publics.
# - `key_size=2048`: La taille de la clé en bits (2048 bits est une taille recommandée pour une bonne sécurité).
# Ces paramètres définissent le groupe mathématique dans lequel l'échange de clés aura lieu.
# Ils sont *publics* et peuvent être partagés sans compromettre la sécurité.
# --- 2. Génération des Clés Privées ---
# -------------------------------------
private_key_alice = parameters.generate_private_key()
private_key_bob = parameters.generate_private_key()
# Alice et Bob génèrent chacun leur clé *privée*.
# Ces clés sont des nombres aléatoires et doivent être gardées *absolument secrètes*.
# Elles sont la base de la sécurité de l'échange Diffie-Hellman.
# --- 3. Calcul des Clés Publiques ---
# -----------------------------------
public_key_alice = private_key_alice.public_key()
public_key_bob = private_key_bob.public_key()
# Alice et Bob calculent leurs clés *publiques* à partir de leurs clés privées
# et des paramètres DH. Les clés publiques sont dérivées des clés privées.
# La propriété fondamentale de DH est qu'il est facile de calculer la clé publique
# à partir de la clé privée, mais *très difficile* (computationnellement infaisable)
# de calculer la clé privée à partir de la clé publique.
# --- 4. Échange de Clés Publiques (Simulé) ---
# -------------------------------------------
# Dans un échange DH réel, Alice enverrait sa clé publique à Bob, et Bob enverrait sa clé publique à Alice.
# Cet échange peut se faire sur un canal *non sécurisé* (par exemple, Internet), car les clés publiques
# ne révèlent pas les clés privées. Ici, on simule cet échange.
# --- 5. Calcul du Secret Partagé ---
# -----------------------------------
shared_key_alice = private_key_alice.exchange(public_key_bob)
# Alice calcule le secret partagé en utilisant sa clé *privée* et la clé *publique* de Bob.
# C'est là que la "magie" de Diffie-Hellman opère.
shared_key_bob = private_key_bob.exchange(public_key_alice)
# Bob calcule le secret partagé en utilisant sa clé *privée* et la clé *publique* d'Alice.
# Grâce aux propriétés mathématiques de l'échange Diffie-Hellman, Alice et Bob
# obtiennent le *même* secret partagé, même s'ils n'ont jamais échangé directement leurs clés privées.
# --- 6. Vérification de l'Intégrité ---
# --------------------------------------
assert shared_key_alice == shared_key_bob
# On vérifie que le secret partagé calculé par Alice est *identique* à celui calculé par Bob.
Diffie-Hellman est un protocole fondamental pour l'établissement de clés secrètes sur des canaux non sécurisés. Il est utilisé dans de nombreux protocoles de sécurité, comme TLS/SSL, SSH, IPsec, etc.
Certificats numériques et PKI
Les certificats numériques et les infrastructures à clé publique (PKI) jouent un rôle central dans la sécurisation des communications sur Internet et dans l'établissement de la confiance en ligne. Ils permettent de vérifier l'identité des sites web, des serveurs, des logiciels et des individus, et d'échanger des informations de manière sécurisée.
Certificats numériques
Un certificat numérique est un document électronique qui atteste de l'identité d'une entité (un site web, un serveur, une personne, une organisation, etc.) et qui lie cette identité à sa clé publique. On peut le comparer à une carte d'identité numérique.
-
Contenu d'un certificat :
- Clé publique du titulaire du certificat.
- Informations sur le titulaire (nom, organisation, adresse email, etc.).
- Période de validité du certificat.
- Identifiant de l'algorithme de signature utilisé.
- Signature numérique de l'autorité de certification (AC) qui a émis le certificat.
-
Utilisations :
- Authentification des sites web (HTTPS) : Lorsqu'un utilisateur se connecte à un site web sécurisé (HTTPS), le serveur présente un certificat numérique. Le navigateur de l'utilisateur vérifie la validité du certificat (en vérifiant la signature de l'AC, la période de validité, etc.) et s'assure ainsi qu'il communique bien avec le site légitime, et non avec un imposteur.
- Chiffrement des communications (HTTPS, TLS/SSL) : Le certificat numérique permet d'établir une connexion chiffrée entre le navigateur de l'utilisateur et le serveur web.
- Signature de logiciels : Les éditeurs de logiciels peuvent signer numériquement leurs logiciels avec un certificat, ce qui permet aux utilisateurs de vérifier l'authenticité et l'intégrité du logiciel.
- Signature d'emails : Les utilisateurs peuvent signer numériquement leurs emails avec un certificat, ce qui permet aux destinataires de vérifier l'identité de l'expéditeur et de s'assurer que l'email n'a pas été modifié.
- Authentification forte : Les certificats numériques peuvent être utilisés pour l'authentification forte (par exemple, pour se connecter à un réseau privé virtuel ou à un système d'information).
Autorités de certification (AC)
Une autorité de certification (AC) est une organisation de confiance qui délivre et gère les certificats numériques. Elle joue le rôle de tiers de confiance.
-
Rôle de l'AC :
- Vérifier l'identité des demandeurs de certificats.
- Émettre les certificats (signer numériquement la clé publique du demandeur).
- Gérer le cycle de vie des certificats (création, renouvellement, révocation).
- Publier des listes de certificats révoqués (CRL).
-
Exemples d'AC : Let's Encrypt, Sectigo, DigiCert, GlobalSign, etc.
-
Hiérarchie des AC : Les AC sont organisées de manière hiérarchique. Il existe des AC racines (root CAs), dont les certificats sont intégrés dans les navigateurs web et les systèmes d'exploitation. Ces AC racines peuvent déléguer leur pouvoir de signature à des AC intermédiaires, qui à leur tour peuvent émettre des certificats pour les utilisateurs finaux.
Infrastructures à clé publique (PKI)
Une infrastructure à clé publique (PKI) est un ensemble de composants (matériels, logiciels, politiques, procédures) qui permettent de gérer les clés publiques et les certificats numériques, et d'assurer la confiance dans les échanges électroniques.
-
Composants d'une PKI :
- Autorités de certification (AC).
- Autorités d'enregistrement (AR) : Des entités qui vérifient l'identité des demandeurs de certificats avant de soumettre la demande à l'AC.
- Certificats numériques.
- Listes de certificats révoqués (CRL).
- Politiques de certification : Des documents qui définissent les règles et les procédures pour la gestion des certificats (vérification de l'identité, durée de validité, etc.).
- Logiciels et matériels : Des outils pour générer des clés, demander des certificats, vérifier la validité des certificats, etc.
-
Fonctionnement (simplifié) :
- Demande de certificat : Une entité (par exemple, un serveur web) génère une paire de clés (publique et privée) et envoie une demande de certificat à une AC (ou à une AR). La demande contient la clé publique et des informations sur l'identité de l'entité.
- Vérification de l'identité : L'AC (ou l'AR) vérifie l'identité du demandeur (par exemple, en vérifiant son nom de domaine, ses documents d'identité, etc.).
- Émission du certificat : Si l'identité est vérifiée, l'AC émet un certificat numérique, qui contient la clé publique du demandeur et la signature numérique de l'AC.
- Utilisation du certificat : L'entité peut maintenant utiliser son certificat pour prouver son identité et établir des communications sécurisées.
- Vérification du certificat : Lorsqu'une autre entité (par exemple, un navigateur web) reçoit un certificat, elle vérifie sa validité en :
- Vérifiant la signature de l'AC (en utilisant la clé publique de l'AC, qui est généralement préinstallée dans le navigateur ou le système d'exploitation).
- Vérifiant la période de validité du certificat.
- Vérifiant si le certificat n'a pas été révoqué (en consultant une liste de certificats révoqués ou en utilisant le protocole OCSP (Online Certificate Status Protocol)).
Les certificats numériques et les PKI sont des éléments essentiels de la sécurité sur Internet. Ils permettent d'établir la confiance entre des parties qui ne se connaissent pas et de sécuriser les échanges d'informations.