Les messages protocolaires de KEM-TLS

Le protocole KEM-TLS est une extension du TLS et est soumis comme un Internet Draft à l’IETF [Bad1]. Il utilise la même notion utilisée par TLS pour la représentation et la structuration de messages. Dans un premier temps, nous expliquons la structuration des messages KEM-TLS, nous analysons ensuite ses avantages par rapports aux méthodes d’authentification existantes. 6.3.1.1 La structure du message ClientHello

Lorsqu’un client KEM-TLS veut ouvrir une session sécurisée avec un serveur KEM-TLS, il doit indiquer dans son message ClientHello qu’il supporte ce protocole. Deux solutions sont possibles pour cette action :

• soit le client envoie une liste de cipher_suites spécifiée pour l’utilisation de PSK avec TLS ; par exemple TLS_DHE_PSK_WITH_RC4_128_SHA. Dans ce cas, le client informe implicitement le serveur qu’il supporte l’authentification à clé partagée et qu’il peut échanger les clés en utilisant l’algorithme de Diffie-Hellman.

• soit le client ajoute une extension à son message ClientHello en utilisant le standard TLS Extensions [TLS-Extension]. Lorsque cette extension est envoyée, elle peut transporter une ou plusieurs méthodes d’échange de clés en mode PSK supportées par le client. Nous définissons la structuration de cette extension (en XDR) comme suit :

struct { PSKMethod psk_methods_list<0..2^16-1>; } PSKKeyExchangeMethod; struct { MethodType method_type; Select (method_type) { case rsa_psk : RSAPSK

case diffie_hellman_psk : DHPSK } method;

} PSKMethod;

enum { rsa_psk(0), diffie_hellmen_psk(1), (255) } MethodType;

Le paramètre PSKKeyExchangeMethod fournit une liste de méthodes d’échanges de clés supportées par le client. Ici, deux méthodes sont supportées : RSA avec PSK et DH avec PSK. 6.3.1.2 La structure du message ServerKeyExchange

Lorsque le serveur reçoit le message ClientHello, il répond par son message ServerHello comme il est décrit dans le premier chapitre. Le serveur envoie ensuite son message ServerKeyExchange. Le but de ce message est de transporter la clé publique du serveur afin de permettre au client d’échanger le premaster secret.

Le message ServerKeyExchange peut se présenter comme suit :

struct { select (KeyExchangeAlgorithm) { case diffie_hellman: ServerDHParams params; Signature signed_params; case rsa: ServerRSAParams params; Signature signed_params;

case rsa_psk: /*NEW/

ServerRSAParamsPSK params;

Signature signed_params; /*optional/ case diffie_hellman_psk: /*NEW/

ServerDHParamsPSK params;

Signature signed_params;/*optional/

};

} ServerKeyExchange;

Les lignes en italic sont celles ajoutées par notre protocole au message standard. Dans le cas où le serveur aurait choisi la méthode RSA avec PSK (rsa_psk), il envoie son ServerKeyExchange qui contient sa clé publique RSA. Le serveur de TLS standard doit envoyer soit une clé publique d’un certificat, soit une clé publique signée par un certificat (dans le cas où le certificat ne sert qu’à signer). Afin de garder l’interopérabilité, nous avons gardé cette option de signature de la clé publique, mais nous rappelons que c’est une option avec KEM-TLS.

6.3.1.3 La structure du message ClientKeyExchange

A la réception du ServerKeyExchange, le client génère la clé premaster secret comme elle est définie dans TLS en fonction de la méthode choisie. Le client chiffre ensuite ce secret et l’envoie via le message ClientKeyExchange. Les lignes en italic ou en gras sont ajoutées au message standard.

struct {

select (KeyEchangeAlgorithm){

case rsa: EncryptedPremasterSecret;

case diffie_hellman: ClientDiffieHellmanPublic;

case rsa_psk: EncryptPremasterSecretPSK; /*NEW/

or case rsa_psk: /*NEW/

opaque psk_identity<0..2^16-1>; EncryptedPremasterSecret;

case diffie_hellman_psk: ClientDiffieHellmanPublicPSK; /*NEW/

or case diffie_hellman_psk: /*NEW/

opaque psk_identity<0..2^16-1>; ClientDiffieHellmanPublic;

} exchange_key; } ClientKeyExchange;

Puisque la clé pré partagée est identifiée par un identificateur, le client doit envoyer cet identificateur afin d’aider le serveur à retrouver la clé correspondante dans sa base de données de clés. A cet effet, deux méthodes sont possibles afin de permettre au client d’envoyer cet identificateur au serveur :

• La première méthode consiste à envoyer l’identificateur psk_identity de la clé en clair (ligne en gras). Cette méthode est utilisée si la protection d’identité n’est pas recommandée par le client et/ou par le serveur.

• La deuxième méthode est utilisée lorsque nous voulons protéger l’identificateur de la clé pré partagée. Bien que cette étape ne soit pas possible qu’avec RSA, elle est possible avec Diffie- Hellman en utilisant un mécanisme supplémentaire comme la gestion pseudonyme (définie plus tard dans ce chapitre). Avec la méthode rsa_psk, la premaster secret est structurée comme suit: struct { ProtocolVersion client_version; opaque random[30]; opaque psk_identity<1..2^16-1>; opaque77 pad[16-psk_identity.length]; } PremasterSecret;

struct { public-key-encrypted PremasterSecret pre_master_secret; } EncryptedPremasterSecretPSK;

Avec cette structuration, l’identificateur de la clé est concaténé avec une valeur aléatoire et un

padding, construisant ensemble la premaster secret qui sera chiffrée avant d’être envoyée au

serveur.

77 _{Sachant que la taille du premaster secret est 48 octets, un padding est ajouté en cas où la taille de l’identificateur}

de la clé serait moins que 16 octets. Dans TLS, pas de conditions sur la taille du premaster secret, mais nous conservons sa taille suggérée dans [TLS] (48 octets). Ce padding aide le serveur à récupérer à la fois la valeur aléatoire et l’identité de la clé pré-partagée

6.3.1.4 Calcul des clés de session et l’établissement de la phase d’authentification

La premaster secret est déchiffrée par le serveur afin de récupérer l’identificateur de la clé pré partagée et de calculer la clé master_secret. Comme le serveur et le client n’utilisent pas de certificats pour l’authentification, cette dernière est établie en utilisant la clé pré partagée dans le calcul de clés. Nous proposons donc d’introduire la valeur du PSK dans le calcul de la fonction PRF. La clé master_secret est alors calculée en remplaçant la premaster secret par premaster

secret XOR PSK comme il est montré dans la formule suivante : master_secret = PRF(pre_master_secret XOR PSK, "master_secret",

ClientHello.random + ServerHello.random)[0..47];

Si nous supposons qu’un intrus a envoyé sa clé publique à la place de celle du serveur, cet intrus sera obligé aussi de savoir la valeur de la clé PSK. Il n’y a donc que les entités qui ont la valeur PSK qui puissent calculer le master_secret.

Après la dérivation de la clé master_secret, le client et le serveur calculent la clé key_block de la même façon que celle définie par TLS. Une fois cette phase de dérivation de clés terminée, le client et le serveur peuvent échanger leurs messages Finished. Comme il est décrit dans TLS, ces messages représentent une preuve que le client et le serveur ont dérivé les mêmes clés (de chiffrement, de MAC, etc.). Dans notre KEM-TLS, les Finished représentent un service additionnel : les deux entités ont pris connaissance de la clé PSK. Autrement dit, personne ne peut calculer un Finished valide sans avoir le vrai PSK. D’où l’authentification mutuelle par le

Finished.