Tout d'abord, un point de terminologie: ce que vous décrivez est un cryptage symétrique , et une clé partagée entre les participants est généralement connue sous le nom de clé secrète; «Clé privée» signifie généralement la partie d'une clé dans la cryptographie à clé publique que seul un participant connaît.
Il existe deux façons de diffuser une clé secrète: elle peut être transportée d'une manière physiquement sécurisée, ou elle peut être transportée à l'aide d'une autre forme de cryptage, généralement la cryptographie à clé publique.
Il existe des moyens d'échanger une clé secrète qui ne nécessitent pas de canal de communication secret. Le plus populaire est le protocole d'échange de clés Diffie-Hellman. Le principe de Diffie-Hellman est que chaque participant génère sa propre paire de clés, et il existe une opération mathématique qui construit un grand nombre à partir d'une clé publique et d'une clé privée. Cette opération mathématique a une propriété très intéressante: le grand nombre peut être construit à partir de la clé privée d'Alice et de la clé publique de Bob, ou à partir de la clé privée de Bob et de la clé publique d'Alice; vous obtenez le même numéro de toute façon. Alice et Bob échangent donc leurs clés publiques, et les deux parties connaissent le grand nombre, qui peut ensuite être utilisé comme clé secrète. Un espion peut découvrir les deux clés publiques, mais il est impossible¹ de trouver le grand nombre à partir des seules clés publiques.
L'échange de clés Diffie-Hellman permet à deux parties d'échanger un secret, peu importe qui écoute. Cependant, il n'authentifie pas Alice auprès de Bob ou vice versa. Par conséquent, il se prête à une attaque de l'homme du milieu : Mallory effectue l'échange de clés avec Alice (qui croit qu'elle parle à Bob) et séparément avec Bob (qui croit qu'il parle à Alice), et obtient ainsi la décision ou à moins connaître le secret.
Lorsque l'attaquant peut intercepter et injecter des messages, davantage de cryptographie est nécessaire pour que les participants s'authentifient mutuellement. (Un attaquant passif signifie effectivement que le protocole de transport sous-jacent fournit une authentification.) Le moyen le plus simple est que chaque participant connaisse déjà la clé publique de l'autre. Si Alice connaît la clé publique de Bob:
- Alice peut authentifier Bob en lui envoyant un défi: une valeur aléatoire (un nonce ) chiffrée avec la clé publique de Bob. Si Bob peut décrypter cette valeur et la renvoyer, Alice sait qu'elle parle vraiment à Bob.
- Bob peut s'authentifier auprès d'Alice en lui envoyant un message signé avec sa clé publique. Alice vérifie la signature pour vérifier qu'elle parle vraiment à Bob.
Il existe de nombreuses variantes qui utilisent l'une de ces méthodes (ou encore une autre variante) dans une direction et la même ou une méthode différente dans l'autre direction, ou qui s'authentifient dans une seule direction. Par exemple, SSL / TLS (la couche de cryptographie pour les protocoles plusieurs-s tels que HTTPS, SMTPS, IMAPS, etc.) peut utiliser plusieurs combinaisons de chiffrement différentes et authentifie généralement le serveur auprès du client mais peut également authentifier le client en option. Diffie-Hellman est lent et encombrant pour cette application; l'algorithme le plus répandu avec la distribution de clé publique est RSA .
Bien sûr, Alice et Bob peuvent ne pas se connaître la clé publique de l'autre. Ils s'appuient donc plutôt sur une chaîne de confiance: Bob envoie à Alice sa clé publique, à côté d'une déclaration signée d'un tiers qui affirme que cette clé est vraiment la clé publique de Bob. Cette déclaration signée est appelée un certificat et la troisième partie est une autorité de certification . Le tiers peut être connu de Bob, ou son identité peut être confirmée par un quatrième, et ainsi de suite. Finalement, cette chaîne de confiance (… se porte garant de Dominique se porte garant de Charlie qui se porte garant de Bob) doit atteindre une partie de Ron à laquelle Bob fait déjà confiance, ce qui signifie que Bob a la clé publique de Ron et fait confiance à Ron pour ne signer que des certificats valides.
Il existe des protocoles qui ne reposent pas sur la cryptographie à clé publique. En particulier, le protocole Kerberos est utilisé à la fois sur les réseaux basés sur Unix et sur Windows pour établir des connexions entre un client et un serveur. Kerberos utilise un serveur d'authentification central appelé centre de distribution de clés (KDC). Le KDC doit avoir le mot de passe de l'utilisateur stocké dans une base de données et le client invite normalement l'utilisateur pour le mot de passe. Pour éviter d'exposer le mot de passe, le protocole n'utilise pas directement le mot de passe, mais un hachage cryptographique ou plus généralement une fonction de dérivation de clé appliquée au mot de passe.
Avec ce secret partagé, le client et le KDC établissent un canal sécurisé et le KDC envoie au client un «ticket». Le ticket contient une clé de session (c'est-à-dire une clé secrète nouvellement générée), ainsi qu'une copie de la clé chiffrée avec une autre clé symétrique partagée entre le KDC et le serveur que le client souhaite contacter. Le client transmet ensuite cette copie chiffrée au serveur. Le serveur déchiffre ce message pour obtenir la clé de session et génère un nonce qu'il chiffre avec la clé de session et renvoie au client. Le client initie ensuite un canal sécurisé avec le serveur, chiffré avec la clé de session, et commence par montrer qu'il pourrait déchiffrer le nonce: cela authentifie le client auprès du serveur. Un établissement de session Kerberos est une variante du protocole Needham-Schroeder .
¹ En ce sens que les cryptographes ont fait de gros efforts, mais la meilleure façon qu'ils ont trouvée de le faire requiert une puissance de calcul inatteignable.