XADM : Comment Secure Sockets Layer Works

Cet article fournit une vue d'ensemble du fonctionnement de SSL (Secure Sockets LAYER).

Introduction à la clé de chiffrement

Cryptographie de clé publique RSA (Rivest-Shamir-Adleman) est largement utilisé pour l'authentification et chiffrement dans le secteur de l'ordinateur. Netscape a licence RSA clé cryptographie publique de RSA Data Security Inc. à utiliser dans ses produits spécialement pour l'authentification.

Chiffrement à clé publique est une technique qui utilise une paire de clés asymétriques pour chiffrement et le déchiffrement. Chaque paire de clés est constituée d'une clé publique et une clé privée. La clé publique est créée distribué public lorsqu'elle est il à largement. La clé privée est distribuée jamais ; il est toujours tenue secrète.

Données sont chiffrées avec la clé publique peuvent seulement être déchiffrées avec la clé privée. À l'inverse, les données qui chiffrées avec la clé privée peuvent être déchiffrées uniquement avec la clé publique. Cette asymétrie est la propriété qui rend la cryptographie de clé publique tellement utiles.

L'utilisation de cryptographie de clé publique pour l'authentification

L'authentification est le processus de vérification d'identité afin qu'une entité peut être sûr de l'identité d'une autre entité. Dans les exemples suivants, utilisateur A et B utilisateur utiliser cryptographie de clé publique pour vérifier identité l'utilisateur B. La notation suivante indique qu'un élément a été chiffrées ou déchiffrées utilisant le chiffrement clé où something est une description de l'élément qui a été chiffrée ou déchiffrée et la key est la clé qui sert à chiffrer ou déchiffrer celui-ci.

Dans l'exemple suivant, un utilisateur veut pour authentifier l'utilisateur b. utilisateur B a une paire de clés, un public et privé un. L'utilisateur B divulgue la clé publique à utilisateur A (cela est abordée dans la section « tendant absence public clés » de cet article). L'utilisateur A génère un message aléatoire et l'envoie utilisateur B comme suit : L'utilisateur B utilise la clé privée pour chiffrer le message aléatoire et renvoie la version chiffrée à l'utilisateur a : Utilisateur reçoit ce message et déchiffre en utilisant la clé publique qui utilisateur B publié précédemment. Utilisateur compare le message déchiffré avec le message qui A initialement envoyé aux utilisateur B. Si les messages correspond à utilisateur, utilisateur A sait qu'ultérieure provient le message utilisateur B, car un imposteur vraisemblablement ne serait pas connaissez clé privée de l'utilisateur B et, s'être Impossible de chiffrer correctement le message aléatoire à envoyer à l'utilisateur a.

Considérations supplémentaires

Sauf si vous savez exactement ce que vous chiffrez, il est jamais judicieux de chiffrer un élément avec votre clé privée et l'envoyer à quelqu'un d'autre. C'est parce que vous pouvez être conservés responsable de la valeur chiffrée (N'oubliez pas, seul vous pouvez effectuer le chiffrement, car vous suffit de la clé privée).

Pour cette raison, dans cet exemple, au lieu de le chiffrement le message d'origine de cet utilisateur A envoyé, utilisateur B crée un résumé de message et chiffre ce résumé de message. Un résumé de message est dérivé le message d'origine aléatoire et possède les propriétés utiles suivantes :

• Le condensé est difficile à inverser. Une personne qui tente d'emprunter l'identité utilisateur B ne peut pas déterminer le message d'origine dans le résumé.
• Un impersonator a des difficultés à trouver un message différent qui calcule la même valeur de résumé.

L'utilisateur B est protégé par à l'aide d'un résumé. L'utilisateur B calcule le résumé du message aléatoire cet utilisateur A envoyé et crypte ensuite le résultat. L'utilisateur B envoie le condensé chiffré au utilisateur a utilisateur A peut calculer le même condensé et authentifier l'utilisateur B en déchiffrement du message de l'utilisateur B et en comparant les valeurs.

D'origine des données pour l'authentification

La méthode décrite dans la section « Considérations supplémentaires » de cet article est appelée une signature numérique. Cette technique nécessite qu'utilisateur B signer un message qui utilisateur A généré ; cela est presque dangereux pour l'utilisateur B le chiffrement d'une valeur aléatoire provenant de l'utilisateur a. Par conséquent, ce protocole d'authentification exemple nécessite une étape plus être sécurisé ; utilisateur B doit provenir certaines (ou toutes) de données comme suit : Lorsque de l'utilisateur B utilise ce protocole, utilisateur B connaît le message est envoyé à un utilisateur et donc utilisateur B peut en toute sécurité signer le message. L'utilisateur B envoie tout d'abord, la version non chiffrée du message " utilisateur A, c'est l'utilisateur B, », puis utilisateur B envoie la version chiffrée digested. L'utilisateur A peut facilement vérifier qu'utilisateur B est utilisateur B, et utilisateur B ne doit pas se connecter tout ce qui ne proviennent pas par utilisateur b.

Tendant absence clés publiques

Comment peut un utilisateur donner une clé publique de manière sécurisée ? Celui-ci est un protocole d'authentification exemple pour l'utilisateur b : Si ce protocole est utilisé, tout le monde peut emprunter l'identité utilisateur b. Tout un imposteur est nécessaire une clé publique et privée. Un imposteur peut se situent à l'utilisateur A et emprunter l'identité utilisateur B en fournissant la clé publique du imposteur au lieu de clé publique de l'utilisateur B. Puis le imposteur » prouve » que la imposteur est utilisateur B en chiffrant quelque chose en utilisant clé privée le imposteur et utilisateur A ne peut pas indiquer que le imposteur n'est pas utilisateur b.

Pour résoudre ce problème, la communauté des normes a inventé un objet appelé un certificat. Un certificat contient les informations suivantes :

• Nom de l'émetteur du certificat.
• L'entité pour laquelle le certificat est émis (également connu sous le nom subject).
• La clé publique du sujet.
• Des horodatages.

Le certificat est signé avec la clé privée de l'émetteur du certificat. Tout le monde sait la clé publique de l'émetteur du certificat (c'est-à-dire, l'émetteur du certificat aussi possède un certificat). Les certificats sont une méthode standard pour lier une clé publique à un nom.

S'il est technologie de certificat est utilisé, tout le monde peut examiner l'utilisateur B certificat pour voir si le certificat a été contrefait. Si utilisateur B conserve une étroite contrôle de la clé privée et utilisateur B obtient en fait le certificat, la technologie de certificat est sécurisée. Voici le protocole modifié à l'aide de cette technique : Lorsque utilisateur A reçoit l'utilisateur B premier message, un utilisateur peut examiner le certificat, vérifier la signature (comme dans l'exemple précédent, en utilisant un résumé et le décryptage de clé publique) et vérifiez l'objet (c'est-à-dire, le nom de l'utilisateur B) et constatez qu'elle est en effet utilisateur b. utilisateur A peut alors confiance que la clé publique est clé publique de l'utilisateur B, puis peut demander preuve d'identité de l'utilisateur B.

L'utilisateur B effectue le même processus comme indiqué dans l'exemple précédent, en créant un résumé de message et ensuite répondre à l'utilisateur A avec une version signée du résumé. L'utilisateur A peut vérifier l'utilisateur B résumé de message en utilisant la clé publique du certificat et en vérifiant le résultat.

Une personne souhaiterez interférer avec les communications sécurisées (dans cet exemple, C utilisateur) peut créer le scénario suivant pour essayer de le faire : Toutefois, C de l'utilisateur ne peut pas satisfaire utilisateur A dans le message final. Utilisateur C n'a pas clé privée l'utilisateur B, pour l'utilisateur C ne peut pas construire un message indiquant que l'utilisateur A pensez provient d'un utilisateur b.

Échanger un secret

Une fois l'utilisateur A a authentifié l'utilisateur B, utilisateur A peut envoyer utilisateur B un message seulement l'utilisateur B pouvez décoder comme suit où la uniquement pour déterminer le secret consiste en déchiffrant le message ci-dessus avec clé privée de l'utilisateur B. Échanger un secret est un autre moyen puissant utiliser cryptographie de clé publique. Même si la communication entre un utilisateur et utilisateur B est respectée, personne ne mais l'utilisateur B peut déterminer les informations secret.

Cette technique renforce la sécurité Internet en utilisant le secret comme une autre touche, mais dans ce cas il est une clé pour un algorithme de chiffrement symétrique, tels que des (Data Encryption Standard), RC4 ou IDÉE. Utilisateur connaît le secret car l'utilisateur A généré le secret avant de l'envoyer à l'utilisateur b. utilisateur B connaît le secret car utilisateur B a la clé privée et peut décrypter utilisateur du message. Parce que les utilisateurs A et utilisateur B connaissez le secret, ils peuvent les démarrer un algorithme de chiffrement symétrique et ensuite envoyer des messages chiffrés avec l'algorithme de cryptage symétrique. Celui-ci est un protocole révisé qui utilise cette technique : La méthode qui sert à calculer secret_key est le protocole qui est défini, mais secret_key peuvent être simplement une copie du secret.

Interférences de sécurité

Même si toutes les techniques précédentes sont utilisées, une personne qui souhaite interférer avec les communications sécurisées (utilisateur C) pourrez le faire. Bien que l'utilisateur C ne peut pas détecter le secret utilisateur A et B utilisateur ont échangé, utilisateur C peut interférer avec leur conversation par re-arranging ou garbling les informations secret. Par exemple, si C utilisateur se trouve entre l'utilisateur A et B utilisateur, utilisateur C peut transmettre la plupart des informations avant et arrière inchangées, mais garble certains messages (c'est facile pour C utilisateur pour le faire car C de l'utilisateur connaît le protocole de cet utilisateur A et l'utilisateur B utilisez pour communiquer) : Utilisateur C transfère les données sans modification jusqu'à ce que l'utilisateur A et B utilisateur partagent un secret. Puis C utilisateur garbles message l'utilisateur B à l'utilisateur a. Utilisateur A approuve utilisateur B, c'est le cas utilisateur A peut à ce stade, pensez que le message brouillé et essayez d'agir sur elle. Notez que C de l'utilisateur ne connaît pas le secret ; tous les utilisateurs C faire est endommager les données sont chiffrées avec la clé secrète. Selon le protocole utilisateur C ne peut pas produire un message valide, mais C de l'utilisateur peut obtenir chance et générer un message valide.

Pour éviter ce type de dommages, utilisateur A et B utilisateur peuvent introduire un code de l'authentification de message dans leur protocole. Un code de l'authentification de message est un élément de données qui sont calculées en utilisant une données secrètes et certains transmises. L'algorithme digest décrit ci-dessus a uniquement les propriétés droite pour la création d'une fonction code message Authentification pouvez défendre contre les utilisateurs C: Parce qu'utilisateur C ne connaissez pas le secret, utilisateur C ne peut pas calculer la valeur correcte pour le résumé. Même si l'utilisateur C garbles aléatoire des messages, les chances de succès sont petit si une grande quantité de résumé des données. Par exemple, en utilisant MD5 (un bon chiffrement digest algorithme inventé par RSA), utilisateur A et B utilisateur peuvent envoyer des valeurs de code d'authentification message 128 bits avec leurs messages. Les chances de deviner le code de l'authentification de message approprié utilisateur sont environ 1 en 18,446,744,073,709,551,616. Pour des raisons pratiques, C de l'utilisateur ne peuvent pas deviner le code de l'authentification de message approprié.

Voici le protocole exemple révisé à nouveau pour utiliser cette technique : Utilisateur C peut essayer de garble messages, mais les calculs de code message Authentification révéler que les messages ne proviennent pas d'utilisateur b. utilisateur A ou utilisateur B peut découvrir la valeur de code message incorrect d'authentification et arrêter la communication. Utilisateur C peut emprunter plus l'identité utilisateur b.