6. Security Considerations (Considérations relatives à la sécurité)
6. Security Considerations (Considérations relatives à la sécurité)
La transmission de clés publiques brutes, telle que décrite dans ce document, offre des avantages en réduisant la surcharge de transmission radio, car les clés publiques brutes sont naturellement plus petites qu'un certificat entier. Il y a aussi des avantages du point de vue de la taille du code pour l'analyse et le traitement de ces clés. Les procédures cryptographiques pour associer la clé publique à la possession d'une clé privée suivent également les procédures standard.
Cependant, le principal défi de sécurité est de savoir comment associer la clé publique à une entité spécifique. Sans une liaison sécurisée entre l'identifiant et la clé, le protocole sera vulnérable aux attaques de l'homme du milieu (man-in-the-middle). Ce document suppose qu'une telle liaison peut être effectuée hors bande, et nous listons quelques exemples dans la Section 1. DANE [RFC6698] offre une telle approche. Afin de remédier à ces vulnérabilités, les spécifications qui utilisent l'extension doivent spécifier comment l'identifiant et la clé publique sont liés. En plus de garantir que la liaison est effectuée hors bande, une implémentation doit également vérifier l'état de cette liaison.
Si les clés publiques sont obtenues à l'aide de DANE, ces clés publiques sont authentifiées via DNSSEC. L'utilisation de clés préconfigurées est une autre méthode hors bande pour authentifier les clés publiques brutes. Bien que les clés préconfigurées ne conviennent pas à un environnement de commerce électronique générique basé sur le Web, ces clés constituent une approche raisonnable pour de nombreux déploiements d'objets intelligents où il existe une relation étroite entre le logiciel exécuté sur l'appareil et le point de terminaison de communication côté serveur. Quel que soit le mécanisme choisi pour la validation de la clé publique hors bande, une évaluation de l'approche la plus appropriée doit être effectuée avant le début d'un déploiement pour garantir la sécurité du système.
Un attaquant pourrait essayer d'influencer l'échange de handshake pour que les parties sélectionnent des types de certificats différents de ceux qu'elles choisiraient normalement.
Pour cette attaque, un attaquant doit modifier activement un ou plusieurs messages de handshake. Si cela se produit, le client et le serveur calculeront des valeurs différentes pour les hachages de message de handshake. En conséquence, les parties n'accepteront pas les messages Finished de l'autre. Sans le master_secret, l'attaquant ne peut pas réparer les messages Finished, donc l'attaque sera découverte.