Distribution de clés

La technique d’authentification de clé secrète n’explique pas comment le client et le serveur obtiennent la clé secrète clé de session à utiliser dans les sessions entre elles. S’ils sont des gens, ils pourraient se rencontrer en secret et s’entendre sur la clé. Toutefois, si le client est un programme s’exécutant sur une station de travail et que le serveur est un service s’exécutant sur un serveur réseau, cette méthode ne fonctionnera pas.

Un client souhaite communiquer avec de nombreux serveurs et a besoin de clés différentes pour chacun d’eux. Un serveur communique avec de nombreux clients et a besoin de clés différentes pour chacun d’entre eux, ainsi. Si chaque client a besoin d’une clé différente pour chaque serveur et que chaque serveur a besoin d’une clé différente pour chaque client, la distribution de clé devient un problème. En outre, la nécessité de stocker et de protéger de nombreuses clés sur de nombreux ordinateurs crée un énorme risque de sécurité.

Le nom du protocole Kerberos suggère sa solution au problème de distribution de clé. Kerberos (ou Cerberus) était une figure de la mythologie grecque classique , un chien à trois têtes féroce qui a gardé vivre intrus de pénétrer dans le monde des Sous-mondes. Comme la garde mythique, le protocole Kerberos a trois têtes : un client, un serveur et un tiers de confiance pour les médiatiser entre eux. L’intermédiaire approuvé dans ce protocole est le centre de distribution de clés (KDC).

Le KDC est un service s’exécutant sur un serveur physiquement sécurisé. Il gère une base de données avec des informations de compte pour tous les principaux de sécurité dans son domaine. Un domaine est l’équivalent Kerberos d’un domaine dans Windows.

En plus d’autres informations sur chaque principal de sécurité, le KDC stocke une clé de chiffrement connue uniquement pour le principal et le KDC. Il s’agit de la clé principale utilisée dans les échanges entre chaque principal de sécurité et le KDC. Dans la plupart des implémentations du protocole Kerberos, cette clé principale est dérivée à l’aide d’une fonction de hachage à partir du mot de passe d’un principal de sécurité.

Lorsqu’un client souhaite créer une connexion sécurisée avec un serveur, le client commence par envoyer une demande au KDC, et non au serveur qu’il souhaite atteindre. Le KDC crée et envoie au client une clé de session unique pour le client et un serveur à utiliser pour s’authentifier mutuellement. Le KDC a accès à la clé principale du client et à la clé principale du serveur. Le KDC chiffre la copie du serveur de la clé de session à l’aide de la clé principale du serveur et la copie du client à l’aide de la clé principale du client.

Le KDC pourrait remplir son rôle d’intermédiaire approuvé en envoyant la clé de session directement à chacun des principaux de sécurité impliqués, mais dans la pratique, cette procédure ne fonctionnera pas, pour plusieurs raisons. Au lieu de cela, le KDC envoie les deux clés de session chiffrées au client. La clé de session du serveur est incluse dans un ticket de session .