Selon la FEVAD, le chiffre du e-commerce en France a dépassé les 130 milliards d’euros en 2021 avec plus de 2 milliards de transactions réalisées. Toutes ces transactions sont rendues possibles aujourd’hui par l’utilisation du protocole https. Ce protocole assure la sécurité des communications entre le navigateur du client et le serveur Web du e-commerçant. Mais comment est assurée cette sécurité ? Lorsqu’un internaute saisit son numéro de carte bancaire sur un site de e-commerce via le protocole https, comment est protégée l’information en transit ?
[A] Par un chiffrement asymétrique avec la clé publique du serveur
[B] Par un chiffrement asymétrique avec la clé privée de l’internaute
[C] Par un chiffrement symétrique avec une clé de session dérivée d’un secret échangé via un mécanisme de cryptographie asymétrique
[D] Par un chiffrement symétrique avec une clé de session dérivée de la clé publique du serveur
Comme vous le savez (ou devriez savoir…), le chiffrement asymétrique est très consommateur de ressources CPU. C’est pour cette raison qu’il n’est quasiment jamais utilisé pour assurer la confidentialité des données. On s’en servira essentiellement pour effectuer des opérations de signature numérique mais également pour protéger ou pour échanger des clés de chiffrement. Et c’est bien ce que nous allons faire avec le protocole TLS. TLS étant le protocole de sécurité sous-jacent utilisé par https.
Pour faire fonctionner un site e-commerce avec des communications sécurisées via https, on doit paramétrer (au niveau du serveur) une liste de suites cryptographiques. Une suite cryptographique (cipher suite) a une structure syntaxique qui, selon la librairie cryptographique utilisée, ressemble à quelque chose comme ça : ECDHE_RSA_WITH_AES_256_GCM_SHA384
Cette suite cryptographique indique que l’on va utiliser 2 algorithmes asymétriques. Le premier pour l’échange de clés (Key exchange) sera l’algorithme de Diffie-Hellman basé sur les courbes elliptiques (ECDHE). Le second pour l’authentification du serveur sera algorithme RSA. Ensuite les données seront chiffrées en symétrique et la « cipher suite » indique que l’on utilisera pour cela l’algorithme AES avec une longueur de clé de 256 bits.
La bonne réponse est donc la proposition [C]
Comment trouver la bonne réponse sans être expert de TLS ?
Et bien par un raisonnement logique en connaissant simplement quelques notions fondamentales de cryptographie.
Je sais que la cryptographie asymétrique est très consommatrice de ressources CPU. Par conséquent un serveur Web chiffrera toutes les données (comme les pages HTML) en symétrique. De même le navigateur enverra les données de l’utilisateur (mots de passe, numéro de CB,…) chiffrées en symétrique. Je peux donc éliminer les propositions [A] et [B].
Je lis ensuite la proposition [C] et je me dis « m…, j’ai rien compris !». Pas de panique. Je lis la proposition [D]. Les données peuvent-elles être chiffrées en symétrique avec une clé de session dérivée de la clé publique du serveur ? Si on dérive une clé secrète à partir d’une clé publique, on fabrique un secret de Polichinelle puisque tout le monde pourra en faire autant ! Cela ne peut pas être la solution pour sécuriser les communications. J’élimine donc la proposition [D] et je sélectionne la bonne réponse [C]. CQFD, on passe à la question suivante !
Questions et réponses rédigées par VERISAFE selon le programme officiel du CISSP actuellement en vigueur
© VERISAFE – Utilisation ou reproduction (même partielle) strictement interdite sans l’accord écrit de VERISAFE
