Bases et applications de la cryptographie

Avec TLS, quelle méthode d'échange de clés procure la propriété selon laquelle les communications enregistrées auparavant ne peuvent pas être déchiffrées même si la clé privée du certificat du serveur fuit plus tard (confidentialité persistante) ?

  1. AUn échange de clés comme ECDHE, qui utilise des valeurs jetables créées pour chaque connexion
  2. BUne méthode dans laquelle le client chiffre le matériel de clé qu'il a créé avec la clé publique RSA du certificat du serveur et l'envoie
  3. CUne méthode dans laquelle le serveur et le client continuent d'utiliser pour toutes les connexions la même clé symétrique convenue à l'avance
Afficher la réponse et l'explication

Réponse : A. Un échange de clés comme ECDHE, qui utilise des valeurs jetables créées pour chaque connexion

Le E final d'ECDHE signifie ephemeral (éphémère, jetable) : une nouvelle valeur secrète est utilisée pour l'échange de clés de chaque connexion, puis jetée. La clé privée du certificat ne sert qu'à signer ; même si elle fuit plus tard, les secrets partagés des connexions passées ne peuvent pas être calculés. À l'inverse, avec la méthode qui envoie le matériel de clé chiffré avec la clé publique RSA du serveur, le trafic enregistré et une clé privée ayant fuité plus tard permettent de déchiffrer toutes les communications passées. TLS 1.3 a supprimé cette méthode, et l'échange de clés repose désormais sur (EC)DHE, avec confidentialité persistante (sauf lorsqu'une connexion est reprise uniquement avec une clé pré-partagée).

S'entraîner sur ce thème Retour au thème

Autres questions sur Bases et applications de la cryptographie

  1. Dans les signatures numériques ECDSA, un nombre aléatoire secret k est utilisé pour chaque signature. Quelle affirmation sur la manière de traiter k est correcte ?
  2. Quelle affirmation sur la chaîne de certificats, lorsqu'un navigateur valide le certificat d'un serveur web, est correcte ?
  3. Lors de la validation d'un certificat TLS, le client vérifie non seulement la chaîne de signatures et la période de validité, mais aussi que le nom d'hôte auquel il se connecte figure dans le SAN (subject alternative name) du certificat. Pourquoi cette vérification est-elle indispensable ?
  4. Quelle description du mécanisme de Certificate Transparency (CT) est correcte ?
  5. Quelle affirmation décrit correctement un changement de TLS 1.3 (RFC 8446) par rapport à TLS 1.2 ?