Création d'applications distribuées avec .NET

Priya Dhawan
Microsoft Developer Network

S'applique à :
   Microsoft® ASP.NET
   Microsoft® .NET Framework SP1
   Microsoft ® Windows® 2000 Advanced Server SP2
   Microsoft® SQL Server™ 2000 et Édition Entreprise SP2
   Microsoft Application Center Test (ACT)

Résumé : Compare les performances relatives des différentes options de sécurité disponibles en matière d'authentification du client, d'algorithmes de hachage, de techniques de cryptage et de signature numérique.

Sommaire

Introduction
Outils et stratégie de test
Configuration matérielle
Résultats des tests de performances
Conclusion

Introduction

Les choix de conception pour sécuriser un système affectent les performances, la modularité et la facilité d'utilisation de votre système. Ce choix implique généralement un compromis entre la sécurité et les performances ou la simplicité d'emploi. Plus un système est sécurisé, plus les concessions en termes de performances et d'utilisation sont importantes. Lorsque vous concevez votre système sécurisé, vous devez analyser toutes les menaces, les vulnérabilités et les attaques auxquelles il peut être exposé et choisir les techniques de protection à mettre en oeuvre selon la résistance à ces menaces dans un premier temps et selon les performances dans un second temps.

Cet article compare les performances relatives des options de sécurité disponibles en matière d'authentification du client, de hachage des algorithmes, de techniques de cryptage et de signatures numériques. Dans un souci de simplification, nous avons isolé ces différentes catégories de protection et restreint la comparaison des performances aux options disponibles dans chaque catégorie. Il est évident que dans le cadre d'un véritable système sécurisé, la sécurité globale reposera sur la combinaison d'une ou plusieurs de ces catégories de protection.

Outils et stratégie de test

Pour nos tests, nous avons utilisé Microsoft Application Center Test (ACT), conçu pour soumettre les serveurs Web à des tests de contraintes et pour analyser les problèmes de performances et d'adaptabilité que posent les applications Web, notamment les pages ASPX et les composants qu'elles utilisent. Veuillez consulter la documentation ACT pour plus d'informations sur la façon de créer et d'exécuter des tests. Application Center Test peut simuler un grand groupe d'utilisateurs en ouvrant des connexions multiples au serveur et en envoyant rapidement des requêtes HTTP. Il permet également de créer des scénarios de test réalistes consistant à appeler la même méthode avec un jeu aléatoire de valeurs de paramètres. C'est une fonctionnalité intéressante : les utilisateurs ne sont pas censés appeler sans cesse la même méthode avec les mêmes valeurs de paramètres. Autre fonctionnalité majeure : Application Center Test enregistre les résultats des tests qui fournissent les informations les plus importantes sur les performances de l'application Web.

ACT prend en charge l'authentification Basic, Kerberos et Digest. Il ne traite pas automatiquement l'authentification par formulaires ASP.NET. Nous avons modifié de manière explicite le corps de la requête pour simuler une soumission de formulaire côté client.

En outre, le contrôleur de domaine était installé sur un ordinateur distinct. Active Directory contenait 10 000 comptes utilisateur. 10 000 utilisateurs ont été créés pour Application Center Test qui les sélectionnait de manière aléatoire lors de l'exécution d'un test.

Configuration matérielle

Les tableaux suivants font une brève présentation de la configuration du banc d'essai utilisé pour réaliser les tests.

Tableau 1. Configuration de l'ordinateur client

Nombre de clients	Machine/UC	Nombre d'UC	Mémoire	Disque	Logiciels
1	Compaq Proliant 1130 MHz	2	1 Go	16,9 Go	Windows 2000 Advanced Server SP 2 Application Center Test

Tableau 2. Configuration du serveur Web

Nombre de serveurs	Machine/UC	Nombre d'UC	Mémoire	Disque	Logiciels
1	Compaq Proliant 1000 MHz	2	1 Go	16,9 Go	Windows 2000 Advanced Server SP 2 .NET Framework SP1

Tableau 3. Configuration du serveur d'applications

Nombre de serveurs	Machine/UC	Nombre d'UC	Mémoire	Disque	Logiciels
1	Compaq Proliant 1126 MHz	2	1 Go	16,9 Go	Windows 2000 Advanced Server SP 2 .NET Framework SP1

Tableau 4. Configuration du serveur de bases de données

Nombre de serveurs	Machine/UC	Nombre d'UC	Mémoire	Disque	Logiciels
1	Compaq Proliant 700 MHz	4	4 Go	18 Go	Windows 2000 Advanced Server SP 2 SQL Server Édition Entreprise SP 2

Résultats des tests de performances

Le débit et la latence sont les principaux indicateurs de performances. Pour un volume fixe de données renvoyées, le débit est le nombre de requêtes client traitées pendant l'unité de temps spécifiée, généralement la seconde. Comme il est possible d'obtenir un débit maximal avec un temps de réponse inacceptable du point de vue de l'utilisation, nous avons examiné la latence (c'est-à-dire le temps de réponse mesuré à l'aide du rapport émis par ACT) de chaque test réalisé.

Remarque     Les valeurs de performances générées pour le débit et la latence doivent être uniquement considérées comme une base de comparaison des technologies concernées. Elles ne représentent pas des critères de performances absolus.

Authentification du client

Un serveur authentifie un client en acceptant ses informations d'identification et en les validant par rapport à une autorité désignée. Nous nous attacherons particulièrement aux modes d'authentification pris en charge par Microsoft® ASP.NET, qui incluent les modes d'authentification de Microsoft IIS 5.0 et l'authentification par formulaires ASP.NET. Pour davantage de détails, veuillez vous reporter à l'article ASP.NET Web Application Security ( ) du Guide du développeur .NET Framework.

Obtenir la page par défaut

Le test consistait à avoir un seul utilisateur ACT envoyant une seule requête au client. Lorsqu'il demandait la page, l'utilisateur était invité à s'identifier à l'aide d'un nom d'utilisateur et d'un mot de passe. Après avoir authentifié l'utilisateur était authentifié, la page était renvoyée avec une seule chaîne.

Remarque    Ce test ne prévoit pas de scénario dans lequel, après avoir été authentifié à la première requête, l'utilisateur envoie d'autres requêtes en présentant au serveur Web un ticket quelconque pour signifier qu'il a déjà été authentifié.

Figure 1. Modes d'authentification : RPS et temps de réponse

Remarque :

• Anonymous : aucune authentification n'est effectuée.
• Les comptes utilisateur étaient stockés dans Active Directory, installé sur une machine distincte de celle du serveur Web.
• FormsAuth_AD utilise l'authentification par formulaires ASP.NET. Comptes utilisateur dans Active Directory.
• FormsAuth_SQL utilise l'authentification par formulaires ASP.NET. Comptes utilisateur stockés dans SQL Server 2000. Pour des raisons de sécurité, le mot de passe ne doit pas être stocké en clair dans la base de données. Vous devez plutôt générer et stocker un hachage unidirectionnel du mot de passe de l'utilisateur qui sera associé à un salt (chiffre aléatoire généré par cryptage) pour accroître la sécurité et réduire les menaces liées aux attaques visant le dictionnaire. Cette approche est préférable à celle du stockage d'une version cryptée du mot de passe de l'utilisateur dans la mesure où elle évite les problèmes de gestion des clés associés aux techniques de cryptage.

Comme vous pouvez vous y attendre, le mode d'authentification « Anonymous », dans lequel aucune authentification n'est effectuée, présente les meilleures performances. Le serveur Web ne demande pas au client d'envoyer les informations d'identification de l'utilisateur avant de présenter la page Web au client. Ce mode d'authentification convient parfaitement si vous souhaitez que votre site soit mis à la disposition du public.

Dans tous les autres modes d'authentification, le client doit envoyer des messages d'authentification supplémentaires, ce qui nécessite des boucles supplémentaires vers le serveur Web. En authentification Basic, Digest et Kerberos, le flux des en-têtes HTTP est similaire à celui-ci :

Figure 2. Flux d'en-tête d'authentification

Comme l'illustre la figure 1, les modes d'authentification Digest et Kerberos sont très proches l'un de l'autre en termes de performances. Et pourtant, les charges supplémentaires qui leur sont associées sont différentes. Dans le processus d'authentification de Digest, le serveur envoie une stimulation (NONCE) au client et lui demande le nom d'utilisateur et le mot de passe. Le cryptage du NONCE utilisé est un hachage unidirectionnel du mot de passe (incluant les ressources auxquelles le système accède et le nom de domaine Kerberos), qui est ensuite envoyé au serveur sur lequel le client est authentifié. Le mot de passe n'est pas envoyé en texte clair ce qui présente un avantage non négligeable par rapport à l'authentification Basic. Le plus gros défaut de l'authentification Digest, malgré son statut de standard de l'industrie, est que seuls quelques navigateurs et serveurs Web la prennent en charge, ce qui limite son utilisation. Microsoft® Internet Explorer 5.0 est le premier logiciel à l'avoir adoptée, avec IIS 5.0 et versions ultérieures. Cette authentification fonctionne uniquement avec les comptes de domaine Windows 2000 et nécessite que les comptes stockent les mots de passe en texte clair (ce qui n'est pas le cas avec Microsoft® .NET® Server).

Avec Kerberos, le navigateur tente d'utiliser les informations d'identification de l'utilisateur provenant de son ouverture de session de domaine. Si le serveur rejette ces informations d'identification, le client est invité à saisir un nom d'utilisateur et un mot de passe dans une boîte de dialogue. Les informations d'identification sont envoyées directement au serveur TGS (service d'émission de tickets) qui les authentifie et délivre au client un ticket Kerberos. Ce ticket est un certificat temporaire contenant les informations qui identifient l'utilisateur sur le serveur du réseau. Généralement, le client met le ticket en cache de manière à le réutiliser pour les requêtes suivantes adressées au serveur, jusqu'à son expiration.

Comme le montre la figure 1, les authentifications Basic et FormsAuth_SQL ont des performances identiques. Avec Basic, le client envoie les informations d'identification de l'utilisateur au serveur Web, qui fait un aller-retour vers le contrôleur de domaine pour obtenir l'authentification du client. N'oubliez pas que l'authentification Basic est très peu sécurisée car le mot de passe est transféré en texte clair sur le réseau (il s'agit en fait d'un codage en base64 qui peut être aisément décodé). Afin de renforcer la sécurisation Basic, vous pouvez utiliser SSL pour établir une session sécurisée. Cette méthode reste moins sûre que l'utilisation de vrais protocoles d'authentification réseau tels que Kerberos et Digest, qui n'envoient pas les informations confidentielles de l'utilisateur au serveur à distance.

Le flux des en-têtes HTTP de l'authentification par formulaires ASP.NET est similaire à celui-ci :

Figure 3. Flux d'en-tête d'authentification

Notez que l'authentification par formulaires ASP.NET est plus lente que tous les schémas d'authentification de Windows, ce qui s'explique en partie certainement par les redirections qu'elle implique avant l'affichage de la page. Dans le cas de FormsAuth_AD, le système a recours à un programme pour rechercher l'utilisateur dans Active Directory. Si le nom d'utilisateur associé au mot de passe fourni existe dans Active Directory, l'utilisateur est authentifié. De même, dans le cas de FormsAuth_SQL, le système appelle une procédure SQL stockée pour rechercher l'utilisateur dans la base de données. Si la requête aboutit, l'utilisateur est authentifié. Nous n'avons pas stocké les mots de passe en clair dans la base de données mais avons préféré stocker le hachage unidirectionnel du mot de passe de l'utilisateur, associé à un salt. Nous avons utilisé SHA1 pour générer le hachage. De ce fait, en mode FormsAuth_SQL, lorsqu'un utilisateur soumet ses informations d'identification, le système extrait tout d'abord de la base de données le hachage et le salt associés à l'utilisateur. Il génère ensuite le hachage du mot de passe fourni par l'utilisateur et celui du salt qu'il vient d'extraire de la base de données. Si les deux hachages correspondent, l'utilisateur est authentifié. Ce processus consomme des cycles supplémentaires dans la mesure où, lors de l'authentification d'un utilisateur, nous générons un hachage à l'aide d'un algorithme SHA1.

L'authentification par formulaires ASP.NET est aussi peu sécurisée que l'authentification Basic car le mot de passe est envoyé sur le réseau en clair. Il y a tout de même une différence entre ces deux modes : l'authentification par formulaires envoie une seule fois les informations d'identification, puis utilise un ticket crypté alors que l'authentification Basic envoie les informations d'identification à chaque requête. Pour améliorer la sécurisation de l'authentification par formulaires, vous pouvez utiliser SSL pour établir une session sécurisée, mais cela affectera alors les performances. L'utilisation de l'authentification par formulaires sans SSL peut fragiliser le système et ouvrir la voie à une attaque par réémission.

Nous vous conseillons de lire l'article Authentification dans ASP.NET : conseils de sécurité .NET , qui présente les avantages et les inconvénients de ces schémas d'authentification et les environnements pour lesquels ils sont les mieux adaptés.

Techniques de cryptage

Les techniques de cryptage assurent la confidentialité des données personnelles, la détection des falsifications et l'authentification. Elles utilisent pour cela le cryptage des données transmises entre le serveur et le client, en supposant que le secret pré-partagé entre eux n'a pas été exposé. Nous nous concentrerons sur les algorithmes de hachage, comprenant SHA1 et MD5, les algorithmes symétriques, parmi lesquels DES, RC2, 3DES et Rijndael ainsi que sur les algorithmes asymétriques tels que RSA et DSA. Pour davantage de détails, reportez-vous à l'article Cryptography Overview ( ) dans le Guide du développeur .NET Framework.

Algorithmes de hachage

Les algorithmes de hachage mappent un ensemble de données de taille arbitraire vers une petite valeur unique de longueur fixe. Nous allons comparer les algorithmes SHA1 et MD5. Pour davantage de détails , reportez-vous à l'article Cryptography Overview ( ) dans le Guide du développeur .NET Framework.

ComputeHash

La méthode calcule le hachage des données stockées dans un fichier. Nous avons effectué les tests avec des données de 4 Ko, 135 Ko et 1 Mo afin de mesurer l'impact de la taille des données sur les performances.

Figure 4. Algorithmes de hachage (4 Ko) : RPS et temps de réponse

Remarque :

• .NET Framework prend en charge différents algorithmes de hachage, parmi lesquels MD5, SHA1, SHA256, SHA384 et SHA512. La seule différence entre les diverses versions de l'algorithme SHA réside dans la taille du hachage qu'ils produisent. Nous avons choisi de n'inclure que les algorithmes SHA1 et SHA512 dans nos essais.
• Nous avons utilisé System.Security.Cryptography qui fournit différentes versions de SHA1 et MD5.
• Il n'existe qu'une version du MD5 dans System.Security.Cryptography : il s'agit de MD5CryptoServiceProvider, qui enveloppe CAPI.
• SHA256, SHA384 et SHA512 ne sont actuellement pas disponibles dans CryptoAPI. Ces algorithmes sont implémentés directement dans le code géré. Ils ont été ajoutés uniquement pour prendre en charge les exigences de génération des nouvelles clés de AES et non pour fournir des algorithmes plus puissants que SHA1. Nous pensons sincèrement que SHA1 est largement suffisant et adapté au hachage de données.
• Pour SHA1 et SHA512, nous avons utilisé des implémentations gérées, SHA1Managed et SHA512Managed respectivement, disponibles dans System.Security.Cryptography.

Comme l'illustre la figure 4, tous les algorithmes sont similaires en termes de performances, SHA512 étant légèrement en retrait. MD5 produit un hachage de 128 bits. Le processus de calcul dans SHA s'inspire largement de MD5. Il produit un hachage de 160 bits.

Les tailles de hachage plus longues sont plus dures à attaquer avec des méthodes de force brute. SHA512 génère un hachage de 512 bits, SHA1 un hachage de 160 bits et MD5 un hachage de 128 bits. SHA1 est donc moins vulnérable que MD5, en supposant qu'il n'existe par ailleurs pas d'autres faiblesses dans les algorithmes.

Figure 5. Algorithmes de hachage (135 Ko) : RPS et temps de réponse

L'augmentation de la taille des données fait apparaître une différence de performances entre les divers algorithmes. Avec 5 utilisateurs simultanés, MD5 a une vitesse d'exécution supérieure d'environ 33 % à SHA1. Bien qu'il n'existe pas encore de méthode connue pour attaquer MD5, des collisions peuvent théoriquement être exploitées contre cet algorithme.

Les performances de SHA512 se sont dégradées avec l'accroissement des données. Sa vitesse est inférieure d'environ 55 % à celle de SHA1.

Gardez à l'esprit qu'une taille de hachage plus longue garantit une plus grande sécurité, au détriment des performances comme je l'ai mentionné précédemment.

Figure 6. Algorithmes de hachage (1 Mo) : RPS et temps de réponse

La différence de performances entre les algorithmes s'accroît avec l'augmentation de la taille des données.

L'algorithme MD5 a une vitesse supérieure de 43 % à celle de SHA1 avec une charge de cinq utilisateurs simultanés (vitesse supérieure de 20 % pour une charge différente). SHA1 a une vitesse d'exécution de 72 % supérieure à celle de SHA512.

Algorithmes de clé symétrique

La méthode testée crypte tout d'abord les données, puis décrypte les octets cryptés. Nous avons effectué les tests avec des données de 4 Ko, 100 Ko et 500 Ko afin de mesurer l'impact de la taille des données sur les performances.

Figure 7. Algorithmes de clé symétrique (4 Ko) : RPS et temps de réponse

Remarque :

• Nous avons utilisé les wrappers gérés pour DES, 3DES et RC2, disponibles dans System.Security.Cryptography, qui enveloppent les implémentations non gérées disponibles dans CryptoAPI. Il s'agit respectivement des wrappers DESCryptoServiceProvider, TripleDESCryptoServiceProvider et RC2CryptoServiceProvider. Il n'existe qu'une seule implémentation gérée, « pure » de Rijndael dans System.Security.Cryptography, et nous l'avons utilisée dans les tests.
• Tailles de blocs et de clés utilisées par les algorithmes pour crypter et décrypter les données :

  Algorithme	Taille de la clé (Bits)	Taille du bloc (Bits)
  DES	64	64
  3DES	192	64
  RC2	128	64
  Rijndael	256	128

• 3DES, RC2 et Rijndael prennent en charge d'autres longueurs de clé, mais nous avons choisi de crypter et de décrypter des données avec la longueur maximale des clés prise en charge dans chaque algorithme. Comme une clé plus longue nécessite plus d'efforts et plus de temps pour être attaquée, et qu'elle offre de ce fait une meilleure résistance, son utilisation nous permettait de mesurer les performances au moment où l'algorithme présentait une sécurité maximale.
• Les clés plus longues fournissent une meilleure sécurité car elles réduisent les possibilités d'attaques par recherche de clé en augmentant le nombre de combinaisons de clé possibles.
• Des algorithmes de même longueur de clé (128, par exemple) ne fourniront pas forcément le même niveau de sécurité.

Avec peu de données, nous avons constaté que Rijndael, un AES (standard de cryptage avancé), était l'algorithme le plus rapide. Il dispose de longueurs de clés et de blocs variables, qui peuvent être définies à 128, 192 ou 256 bits. En outre, il utilise un nombre variable de cycles pour produire le texte chiffré selon la longueur de la clé et celle du bloc.

DES crypte et décrypte les données en blocs de 64 bits, à l'aide d'une clé 64 bits. Chaque bloc de données est répété 16 fois pour produire le texte chiffré. Bien qu'il soit plus rapide que le 3DES et le RC2, la longueur réduite de sa clé le rend vulnérable aux attaques de force brute. Il devient plus vulnérable et plus facilement « démontable » avec l'utilisation d'ordinateurs toujours plus puissants.

Le triple DES (3DES) a été développé pour améliorer la sécurité de DES en appliquant le cryptage DES trois fois avec trois clés différentes (crypter les données trois fois avec la même clé n'apporterait rien). Il s'agit simplement d'un autre mode de DES, très sûr mais aux performances plus faibles. Pour sa procédure de cryptage, il utilise une clé de 192 bits qui est fragmentée en trois sous-clés de 64 bits. Cette procédure est identique à celle de DES, mais est répétée trois fois, la rendant ainsi plus fiable. Les données sont cryptées à l'aide de la première sous-clé, décryptées à l'aide de la seconde sous-clé, puis cryptées une nouvelle fois à l'aide de la troisième sous-clé.

RC2 s'avère être l'algorithme le plus lent lorsque les données à crypter sont peu volumineuses. Il effectue d'emblée des calculs lourds pour créer une table liée aux clés dont le coût est apparemment élevé pour le cryptage des données de petite taille. RC2 est un chiffrement de bloc symétrique à longueur de clé variable qui offre une alternative à l'algorithme DES.

Figure 8. Algorithmes de clé symétrique (100 Ko) : RPS et temps de réponse

Lorsqu'on augmente la taille des données à crypter et à décrypter, on obtient une image des performances bien différente de celle obtenue au test précédent. DES est l'algorithme le plus rapide, suivi par RC2, dont la vitesse dépasse de 20 % celle de 3DES. Notez que les lourds calculs de RC2 pour créer la table liée aux clés, mentionnés précédemment, sont amortis lorsque l'on utilise des données plus volumineuses. Rijndael est ici l'algorithme le plus lent, avec une vitesse de 25 % inférieure à celle de 3DES. Nous utilisons ici une clé de 256 bits pour le cryptage Rijndael, ce qui le rend plus fiable que toutes les autres méthodes (bien que la presse fasse mention de possibilités d'attaque contre Rijndael, peut-être plus efficaces que l'attaque de force brute), mais en fait aussi la solution la plus lente. De même, nous avons utilisé une clé de 192 bits pour 3DES, plus longue que les clés utilisées pour le cryptage de DES et RC2.

Je souhaite préciser de nouveau que ce n'est pas parce qu'ils utilisent une clé de même longueur que les algorithmes sont aussi résistants. Ils ont chacun des caractéristiques propres et peuvent donc être plus ou moins puissants.

Comme je l'ai dit au début de cet article, il s'agit toujours de trouver un compromis entre sécurité et performances. Vous devez évaluer la valeur de vos données, le coût de déploiement et les conséquences en termes de facilité d'utilisation/performances avant de choisir l'algorithme adapté à la sécurisation de vos données. Si la valeur des données à protéger est élevée, vous devez envisager de réduire les performances pour sécuriser vos données. Dans le cas contraire, vous préférerez sans doute utiliser un algorithme moins sûr.

Figure 9. Algorithmes de clé symétrique (500 Ko) : RPS et temps de réponse

Avec l'accroissement de la taille des données cryptées et décryptées, nous voyons également se dégager la même tendance dans ce test, bien que la différence de performances se soit accrue entre les chiffrements, sauf entre 3DES et Rijndael.

Algorithmes de clé asymétrique

Le cryptage à l'aide d'algorithmes à clés asymétriques est très lent, notamment lorsque les données sont volumineuses. Ils ne sont donc pas utilisés pour le cryptage en bloc pour lequel il convient d'utiliser les algorithmes symétriques. En effet, les algorithmes asymétriques peuvent servir pour l'échange de clé.

Les deux algorithmes asymétriques les plus connus sont RSA et DSA. RSA peut être utilisé à la fois pour le cryptage et pour la génération de signature. En revanche, DSA sert uniquement à la génération de signature. Nous avons comparé les algorithmes RSA et DSA sur leur vitesse de génération de signature numérique ainsi que sur le temps qu'il leur est nécessaire pour vérifier une signature.

Création d'une signature

Figure 10. Création d'une signature (100 Ko) : RPS et temps de réponse

Remarque :

• Nous avons utilisé RSACryptoServiceProvider et DSACryptoServiceProvider proposés dans System.Security.Cryptography, qui sont des wrappers gérés autour des implémentations non gérées de RSA et de DSA, respectivement, fournies par CryptoAPI.
• RSA utilisait une clé de 1024 bits.
• DSA utilisait une clé de 512 bits.

Comme le montre la figure 10, la vitesse de DSA est supérieure d'environ 29 % à celle de RSA lors de la génération d'une signature numérique. Le processus de signature numérique de RSA utilise la clé privée pour crypter uniquement le résumé de message. La méthode cryptée devient la signature numérique.

Bien que similaire à RSA, DSA ne crypte pas les résumés de message à l'aide de la clé privée, et ne le décrypte pas avec la clé publique. DSA utilise en revanche des fonctions mathématiques spécifiques pour générer une signature numérique composée de deux nombres de 160 bits, dérivés du résumé de message et de la clé privée.

Figure 11. Création d'une signature (500 Ko) : RPS et temps de réponse

Avec plus de données, DSA reste plus rapide que RSA.

Vérification de la signature

Figure 12. Vérification de la signature (100 Ko) : RPS et temps de réponse

Les résultats s'inversent lorsqu'il s'agit de vérifier la signature. RSA a une vitesse supérieure d'environ 29 % à celle de DSA. RSA utilise une clé publique pour vérifier la signature. Il génère un nouveau résumé de message à partir des données reçues, décrypte le résumé de message d'origine à l'aide de la clé publique de l'initiateur et compare le résumé décrypté au nouveau résumé généré. Si les deux résumés correspondent, l'intégrité du message est vérifiée. L'identité de l'initiateur est également confirmée, car la clé publique ne peut décrypter que les données qui ont été cryptées avec la clé privée correspondante.

DSA utilise également la clé publique pour vérifier la signature mais le processus de vérification est plus complexe que celui de RSA.

Figure 13. Vérification de la signature (500 Ko) : RPS et temps de réponse

Avec plus de données, la différence de performances entre les deux algorithmes est négligeable.

Conclusion

Comme le démontrent ces tests, les schémas d'authentification, les algorithmes de hachage et les techniques de cryptage impliquent des surcharges variables et présentent donc des caractéristiques de performances très différentes. La taille des données transmises aux algorithmes de hachage ainsi qu'aux techniques de cryptage joue également un grand rôle.

Lorsque vous concevez un système sécurisé, les techniques d'implémentation doivent être choisies en premier lieu en fonction de la résistance aux menaces et ensuite seulement en fonction des performances. Ainsi, une authentification de base sans SSL peut être utilisée pour obtenir de meilleures performances, mais quelle que soit sa vitesse d'exécution, elle ne sera pas adaptée aux systèmes vulnérables aux menaces qu'elle ne permet pas de combattre.

Cet article n'aborde pas les conséquences globales sur les performances d'une protection combinant authentification et confidentialité des données, ce qui correspondrait à la réalité de la sécurité d'un système. Les performances d'un système sécurisé varient en fonction de la combinaison des différents schémas de protection qui sont utilisés.

Dernière mise à jour le mercredi 11 décembre 2002

• Développement Microsoft .NET