1. Introduction
1. Introduction
Note: Le mécanisme décrit dans ce document était précédemment connu sous le nom de "TLS Extractors" mais a été modifié pour éviter un conflit de nom avec l'utilisation du terme "Extractor" dans la communauté cryptographique.
Un certain nombre de protocoles souhaitent exploiter Transport Layer Security (TLS) [RFC5246] ou Datagram TLS (DTLS) [RFC4347] pour effectuer l'établissement de clés, puis utiliser une partie du matériel de clé à leurs propres fins. Un exemple typique est DTLS-SRTP [DTLS-SRTP], un schéma de gestion de clés pour le protocole de transport en temps réel sécurisé (Secure Real-time Transport Protocol, SRTP) qui utilise DTLS pour effectuer un échange de clés et négocier la suite de protection SRTP [RFC3711], puis utilise le master_secret DTLS pour générer les clés SRTP.
Ces applications impliquent la nécessité de pouvoir exporter du matériel de clé (appelé ultérieurement Exported Keying Material ou EKM) de TLS/DTLS vers une application ou un protocole résidant à une couche supérieure, et de convenir de manière sécurisée du contexte de couche supérieure où le matériel de clé sera utilisé. Le mécanisme d'exportation du matériel de clé a les exigences suivantes:
-
Le client et le serveur doivent tous deux pouvoir exporter la même valeur EKM.
-
Les valeurs EKM doivent être indiscernables de données aléatoires pour les attaquants qui ne connaissent pas le master_secret.
-
Il doit être possible d'exporter plusieurs valeurs EKM à partir de la même association TLS/DTLS.
-
Connaître une valeur EKM ne doit révéler aucune information utile sur le master_secret ou sur d'autres valeurs EKM.
Le mécanisme décrit dans ce document est destiné à satisfaire ces exigences. Ce mécanisme est compatible avec toutes les versions de TLS.