Benchmark, performances et analyse

La carte EAP-TLS a été développée en utilisant deux cartes JavaCard. Les caractères physiques et cryptographiques de ces deux cartes sont illustrés dans le tableau suivant. Les deux cartes incluent des co-processeurs cryptographiques capables d’achever le calcul de l’algorithme RSA en moins de 500 ms.

Deux tests sont effectués afin d’évaluer les performances (système d’exploitation et protocole d’authentification) de notre implémentation. Ces performances dépendent de plusieurs paramètres ; notamment la capacité du processeur, la taille du mémoire, les opérations cryptographiques invoquées par le protocole d’authentification et le temps de transfert des données entre les entités.

Carte CPU RAM octets ROM Koctets E2PROM Koctets Max. Clock MaxData Rate RSA Co- processeur RNG A 8 bits 2304 96 32 10 MHz 424 kbit/s 1088 bits oui B 8 bits 4096 96 34 8 MHz 1000 kbit/s 4032 bits non

Tableau 5.3. Caractéristiques du microcontrôleurs.

Puisque les deux cartes supportent un co-processeur RSA, nous avons remarqué que le temps d’exécution de RSA varie entre 100 et 500 ms. Durant sa phase Handshake, la méthode EAP- TLS effectue les opération RSA trois fois (vérification de la signature du CA et du client, et un chiffrement avec la clé publique du serveur). Dans notre test, ces opérations consomment approximativement une seconde.

EAP-TLS utilise les fonctions de hachage MD5 et SHA1. Dans notre implémentation, ces fonctions sont appliquées sur des blocs de 64 octets. Par conséquent, le temps de calcul des ces fonctions dépend de la taille du bloc utilisé. Les cartes utilisées dans cette implémentation ne possèdent pas de co-processeurs MD5 ou SHA-1. Elles sont donc développées dans les librairies cryptographiques et exécutées par le CPU de la carte. Les résultats de nos tests montrent que les temps d’exécution moyens d’un dual condensâtes (MD5 et SHA1) est respectivement (pour la carte A et B) :

• 155 et 120 ms pour des blocs de taille courte (128 octets), • 2350 et 1100 ms pour des blocs de taille longue (6 kilo octets).

Durant sa phase Handshake, EAP-TLS applique trois fois le dual Hash sur de blocs de taille longue. Le temps d’exécution de ces trois opérations est estimé à 14.1 secondes pour la carte A et à 6.6 secondes pour la carte B.

Puisque l’API JavaCard ne donne pas les moyens natifs d’implémenter toutes les opérations cryptographiques du EAP-TLS, les fonctions cryptographiques suivantes sont ajoutées :

• La procédure HMAC : elle peut être utilisée avec MD5 et SHA1. HMAC-MD5 et HMAC- SHA1 sont appliquées sur une clé de taille moins de 64 octets (dans le contexte de TLS) et sur un message de taille moins de 128 octets. Dans ces conditions, HMAC utilise les deux fonctions de hachage et l’opération de l’addition. Nos tests montrent que le temps d’exécution de la procédure HMAC est de 2 secondes pour la carte A et d’une seconde pour la carte B. • La fonction PRF utilisée pour calculer, entre autres, le master secret et les clés de chiffrement

de la session TLS. Cette fonction utilise HMAC-MD5 et HMAC-SHA1 dans son calcul. Afin d’avoir une sortie dont la taille est égale à 80 octets, cette fonction appelle HMAC-MD5 dix fois et HMAC-SHA1 huit fois (nous utilisons ici une clé de 32 octets et un bloc de taille moins de 128 octets). Par conséquent, le temps d’exécution est approximativement 40 secondes pour la carte A et 20 secondes pour la carte B. Comme EAP-TLS utilise la fonction PRF cinq fois durant sa phase Handshake, le temps d’exécution est donc 200 secondes pour A et 100 secondes pour B.

• La procédure de RC4 : cette méthode est coûteuse en temps d’exécution puisqu’elle traite un tableau (array) de 256 octets stockés sur le E2PROM. Le temps de chiffrement/déchiffrement de 32 octets est 21 pour la carte A et 12.5 secondes pour B. Cette procédure est appelée deux fois durant la phase Handshake, ce qui nécessite 42 secondes pour A et 23 pour B.

5.5.4.1 Les performances générales

La figure suivante montre la répartition du temps de calcul durant la phase Handshake de EAP- TLS. La carte A achève cette phase en 266 secondes alors que l’exécution par la carte B nécessite 151 secondes. Le temps de transfert des messages EAP-TLS entre la carte et le terminal est 4.5 secondes pour la carte A et 12 secondes pour la carte B.

2% 2%

Autres

Transfert des données 5% Dual Hash 16% RC4 75% PRF

Figure 5.15. Répartition du temps de calcul cryptographiques pour A et B

Il est clair que la plupart du temps d’exécution est pris par les fonctions PRF et du hachage. Ce temps peut énormément se réduire avec l’utilisation du co-processeur cryptographique effectuant les fonctions du hachage. En effet, une opération HMAC-MD5 avec une clé de 64 octets s’exécute en 0,004 ms sur un PC Intel à 1200 MHz et 389 Méga octets de RAM, alors qu’une signature RSA avec une clé de 1024 bits prend approximativement 5,7 ms et 0,3 ms pour la vérification.

5.5.4.1.1 Optimisation software

Nous avons montré que la fonction PRF est le goulot d’étranglement dans les mesures de performances EAP-TLS. Nous avons trouvé aussi que le temps exigé par le traitement de quelques messages EAP-TLS par la carte à puce dépasse la valeur de temporisation (30 secondes) spécifié par [802.1XAD]. Cette valeur de temporisation correspond au temps pour avoir la réponse à un paquet 802.1X envoyé par le serveur. A cet effet et pour éviter de renvoyer plusieurs fois les paquets 802.1X, nous proposons d’améliorer la performance de EAP-TLS afin d’être fonctionnel avec des équipements comme la carte à puce.

Nous avons cité que l’utilisation de co-processeurs MD5 et SHA-1 peut améliorer énormément la performance de la carte à puce EAP-TLS. Cependant, une implémentation attentive peut améliorer aussi cette performance, cela en profitant des deux caractéristiques du langage JavaCard. En effet, ce langage supporte deux types d’objets : persistant et temporaire. Le première est associé aux opérations extrêmement lentes en écriture et elle utilise la mémoire non volatile (E2PROM, Flash, etc.) alors que le deuxième type d’objets est associé aux opérations vites. Ce deuxième type utilise la mémoire volatile (RAM).

Dans notre implémentation améliorée, nous proposons d’utiliser des tableaux de type temporaire avec les classes du TLS. Cela nous amène à réduire le temps d’exécution d’un facteur trois en utilisant la carte à puce B. Avec cette implémentation, le temps de traitement de n’importe quel message EAP-TLS est toujours plus petit que 30 secondes. Le temps de traitement des messages EAP-TLS est fournit dans le tableau suivant :

Opération Temps de traitement

(en seconde) transfert du message ServerHello vers la carte 10.0

traitement du message ServerHello 24.0 transfert de la réponse de la carte (ClientHello) 2.5

traitement du message Finished du serveur 8.5

Tableau 5.4. Le temps maximal du traitement des messages EAP-TLS Le nouveau benchmark peut se résumer par la figure suivante :

PRF 15s-33% RC4 5s-12% Autres 3s-6% Transfert des données

12s-28%

Dual Hash 9s-21%

Figure 5.16. L'amélioration du temps de traitement de la carte EAP-TLS

5.6 Conclusion

Dans ce chapitre, nous avons présenté l’implémentation de EAP-TLS sur la carte à puce et nous avons étudié et analysé sa performance, ses avantages et inconvénients dans le contexte des réseaux sans fil.

Nous avons spécifié Double-TLS, un protocole de sécurité de bout en bout assurant plusieurs services indispensables aux réseaux mobiles comme l’anonymat. Nous avons proposé également deux solutions d’authentification basées sur la clé partagée avec TLS. L’utilisation de la clé partagée avec TLS est supportée actuellement par l’IETF et le 3GPP. Cette utilisation nous permet d’établir une session sécurisée avec une authentification mutuelle. Malheureusement, l’utilisation de la clé pré partagée n’assure pas tous les services ; notamment la protection contre les attaques actives, la protection à long terme de données et l’anonymat. Dans le chapitre suivant, nous proposons une solution intégrant le chiffrement symétrique et asymétrique afin de découvrir les différents services manquant dans les solutions existantes.

Partie IV : Une méthode d’authentification intégrant les