L'acces a ce document impose la lecture de ce (petit) disclaimer :
Ce hackoff est un magazine qui traite de differents sujets sur differents tons (normal on est plusieurs a faire les articles), il ne faut donc pas se formaliser de l'apparence laxiste des propos rencontres ici, cependant la lecture du contenu de ce fichier requiert d'appartenir a un certain type de population.
Pour etre autorise a lire les informations qui suivent, il faut etre boutonneux avec des lunettes, asociable, grunge, buveur de bieres, fumeur de joints, et passer plus de 15 heures par jour devant son ordi. Il faut etre equipe du materiel suivant (au minimum) :
-Un micro-ordinateur avec affichage 256 couleurs et une resolution de 640*xxx
-Deux yeux en etat de fonctionnement (75% suffiront)
-Un interpreteur html a affichage graphique (sorry pour ceux qui ont lynx)
-La capacite de savoir lire le francais d'une facon soutenue
-Le numero de l'horloge parlante de Hong-Kong
Si un de ces elements vient a manquer, ne lisez pas ce document, vous n'y etes pas autorises (et surtout vous n'y arriverez pas)! En accedant a la suite du document, vous reconnaissez appartenir a cette categorie et vous exposez donc a un traitement au biactol autant qu'a des visites frequentes chez votre ophtalmo. Sans parler du delire obsessionel que vous allez vous faire en vous demandant a quoi peut bien servir le numero de telephone de l'horloge parlante de hong-kong.

function Edito()

L'ethique sympathique du nordique boulimique de techniques automatiques nous explique que le fric n'est pas chic et que si on applique a la rethorique un lexique cyclique a des fins idylliques, on provoque un declic et on devient un sadique de l'informatique. C'est la qu'est le hic, donc je prends mon bic et je prouve par la pratique et par mon historique qu'une bonne dose de frolic chaque matin c'est caustique. Sans aucune mnemonique, je fais la nique aux flics et reste categorique : le joystick en quantite astronomique, ca vaut pas un bon stick.

Tobozic

Introduction aux échanges sécurisés sur l'Internet

• 1. PRÉSENTATION D'ENSEMBLE
• 2. PRÉSENTATION DU SCELLEMENT ET CHIFFREMENT
• 2.1. Les technologies de chiffrement
• 2.2. Les technologies de scellement et de signature
• 3. PRÉCONISATIONS EN MATIÈRE DE CHIFFREMENT ET DE SCELLEMENT
• 3.1. Les algorithmes
• 3.2. Synthèse :Tableau récapitulatif des différents algorithmes
• 4. LES CERTIFICATS
• 4.1. Présentation
• 4.2. Le certificat X509
• 5. LES PROTOCOLES DE MISE EN ŒUVRE
• 5.1. SSL
• 5.1.1. Acteur
• 5.1.2. Principes techniques
• 5.1.3. Etablissement des communications avec SSL
• 5.1.4. Comparaison entre SSL V3 et SSL V2
• 5.1.5. Compatibilité V2/V3
• 5.1.6. SSL et les Firewalls
• 5.1.7. Mise en œuvre
• 5.2. LA CERTIFICATION ET SSL
• 5.2.1. Comment obtenir un certificat SSL ?
• 5.2.2. Les différents types de certificats
• 5.4. LE PROTOCOLE S-HTTP (SECURE HYPERTEXT TRANSFER PROTOCOL)
• 5.4.1. Présentation
• 5.4.2. Mécanisme général
• 5.4.3. Considérations générales
• 5.4.4. Le chiffrement des messages
• 5.4.5. L'authentification
• 5.4.6. L'intégrité du message
• 5.4.7. Le mécanisme de récupération du message en clair
• 5.4.8. Comparaison de S-HTTP et de SSL
• 5.4.9. Algorithmes supportés
• 5.4.10. Synthèse
• 5.5. LE PROTOCOLE PCT (MICROSOFT)
• 5.5.1. Présentation
• 5.5.2. Synthèse 32
• 5.6. TLS
• 5.6.1. Présentation
• 5.6.2. Principe de base
• 5.6.3. Synthèse

Aujourd'hui la solution la plus pertinente pour sécuriser les opérations sur Internet est SSL. La plus pertinente parce que la plus simple aussi bien pour l'utilisateur (client) que l'administrateur (serveur), et parce que tous les navigateurs Web récents intègrent, en standard, cette technologie. La plus pertinente car elle permet aussi bien d'authentifier les deux parties (s'assurer que chacun est bien qui il dit être) que de chiffrer les données échangées. La sécurité des échanges au sein des transactions applicatives (essentiellement financières) met en œuvre trois catégories de concepts :

• des technologies de chiffrement / scellement (RSA, DES, RC2, RC4, RC5, MD5, Certificats X509, etc.)
• des protocoles de mise en œuvre de ces technologies (SSL, PCT, TLS, etc.)

Le but de la sécurité des échanges est d'assurer la confidentialité, lorsque cela est nécessaire et légal, ainsi que l'identification et l'authentification des messages échangés. Les travaux sur ces domaines sont extrêmement importants, compte tenu des enjeux représentés par le commerce électronique et il est probable que les retombées de ces travaux concerneront toutes les entreprises dans leur objectif de protection contre les intrusions et le piratage.

• le chiffrement à clés privées (symétrique)
• le chiffrement à clés publiques (asymétrique)

Les technologies de chiffrement à clés privéess permettent le chiffrement / déchiffrement d'un message à l'aide d'une même clé, connue des deux interlocuteurs. Ces techniques algorithmiques sont très connues depuis de nombreuses années. La plus célèbre est l'algorithme DES (1974). Internet utilise fortement les algorithmes RC2, RC4 ou RC5.

Les technologies de chiffrement à clés publiques s'appuient sur un couple de clés (Kpri,Kpub) corrélées. L'une de ces clés est considérée comme publique, l'autre est conservée comme privée. La connaissance de la clé publique est supposée (à juste titre jusqu'ici) ne pas permettre la découverte de la clé privée (corrélation mathématique).

Ces deux clés sont symétriques et l'une d'elle peut être utilisée pour le chiffrement, l'autre pour le déchiffrement. L'usage habituel est bien sûr d'utiliser Kpub du correspondant pour lui envoyer un message chiffré que lui seul (en possession de la clé Kpriv correspondante) peut alors déchiffrer.

L'avantage de cette méthode est à l'évidence sa très grande souplesse quant à l'échange de clés (pas de besoin de canal sûr).

L'inconvénient le plus connu de ces techniques est leur relative lourdeur les rendant peu aptes à être utilisées pour du chiffrement en ligne.

L'algorithme le plus connu est RSA (du nom de ses inventeurs Rivest Shamir et Adleman). Une approche de plus en plus commune consiste à utiliser RSA (ou ses dérivés) pour négocier une clé privée de session qui sera utilisée pour un DES ou RC2 au cours des échanges qui suivent. Cette approche cumule les avantages des deux technologies et en évite les inconvénients

2.2 Les technologies de scellement et de signature

Le scellement et la signature consistent à adjoindre à un message une chaîne complémentaire calculée à partir du message et appuyée sur l'usage d'une clé de chiffrement. Cette technique a pour objectif de garantir qu'un tiers non impliqué n'a pu ni fabriquer le message (concept de signature garantissant l'authenticité), ni l'altérer (concept d'intégrité).

La technique utilisée est en général très simple :

• fabrication d'un résumé du message (" digest "), en général fondé sur une mécanique de type MD5 (Message Digest 5);
• chiffrement du résumé MD5 par la clé privée de l'émetteur de ce résumé; le récepteur (quel qu'il soit) peut alors recalculer le résumé (MD5), déchiffrer le sceau avec la clé publique de l'émetteur et effectuer la comparaison;
• une comparaison réussie garantie intégrité et authenticité du message (puisque la fabrication du sceau nécessite la connaissance de la clé privée de l'émetteur). Cette approche est classiquement utilisée dans la signature électronique apposée par les tiers de confiance sur les certificats X509 que nous abordons plus loin.

• les pare-feu proposent une identification / authentification initiale du correspondant et laissent ensuite se dérouler les échanges de manière naturelle, sans intervention autre que les contrôles normaux d'un sas applicatif; un attaquant, inséré en coupure de flux depuis le début peut laisser se dérouler la phase d'identification / authentification initiale et altérer ensuite le flux!
• l'identification / authentification par signature électronique se fait à chaque message et ne laisse pas la place à un attaquant, même en coupure; il s'agit d'une technique très forte dont l'avenir est certain.

Le but de ce paragraphe est de présenter les standards et les recommandations de mise en œuvre.

3.1. Les algorithmes

Le DES (Data Encryption Standard)

Le DES est certainement l'un des algorithmes à clé privée les plus utilisés, son origine remonte à 1974, il est d'origine IBM, mais a souffert d'une implication de la NSA (National Security Agency) qui fît naître une polémique quant à une backdoor éventuelle. Techniquement, le DES travaille sur des blocs de texte clair de 64 bits qu'il divise en 2 fois 32 bits, qui sont ensuite permutés et substitués selon un mécanisme identique (ronde) 16 fois de suite. Chaque bloc de texte clair ressort après son traitement en un bloc de longueur équivalente chiffré. Le DES utilise une clé de chiffrement de 64 bits, dont en réalité seulement 56 sont effectifs, les autres étant des bits de parité. Tout nombre de 56 bits peut donc être utilisé, a chaque itération du processus, les bits de la clé sont décalés. Le déchiffrement du texte suit exactement la même logique en inversant simplement l'ordre d'utilisation des clés.

La sécurité du DES :

Malgré de nombreux démentis, émanant de la NSA et des créateurs du DES, des doutes subsistent quant à sa robustesse (faiblesse de certaines clés, constitution ésotérique des tables-S, nombre de rondes insuffisant). Pour autant les cryptanalyses différentielles, linéaires ou encore à clés corrélées n'ont pas démontré de faiblesse notoire, l'attaque par force brute restant la plus efficace. Le coût d'une machine destinée à casser le DES par attaque exhaustive était estimé en 1987 à moins 10 Millions de $, La rumeur dit que la NSA peut casser un DES en 15 minutes maximum avec une machine estimée à 50 000$. .(ce qui au passage montre que les estimations faites 10 ans plus tôt étaient surévaluées).

Pendant longtemps, vu que la NSA (l'agence de sécurité nationale amércaines, encore plus secrete que la CIA) était intervenue dans la conception de l'algorithme, on a pensait qu'il pouvait présenter un trou de sécurité, notamment dans les huit tables de substitution qui n'ont jamais était justifiées ni par IBM ni par la NSA. Si un tel trou de sécurité avait existé, il aurait permis à la NSA de décrypter aisement tous les messages codés par le DES sans que personne ne le sache.
Après de nombreuses analyses par des spécialistes, une telle éventualité n'a jamais pu être démontré. En revanche, on considère aujourd'hui qu'une clef de 56 bits résiste difficilement à une attaque systèmatique. Un défi dans ce sens est d'ailleurs proposé depuis trois ans par la société RSA Data Security : le message crypté avec le DES a ainsi était dechiffré cette année en 22 heures et 15 mn par un réseau de 100 000 PC associé à une machine spéciale mise au point l'an dernier par l'EFF (Electronic Frontier Foundation, association américaine de defense des droits civils dans la societe de l'information); pour ce faire, 245 millions de clefs se voyaient testées chaque seconde.

Afin d'améliorer la sécurité du DES, plusieurs variantes ont été mises au point, la plus repandue est le DES triple, qui consiste à chiffrer le message clair avec une première clef, puis à appliquer l'algorithme à ce premier texte crypté en mode dechiffrement avec une deuxième clef et enfin à chiffrer à nouveau le résultat avec la première clef. Cette méthode permet de simuler une clef de 112 bits. La solution actuellement envisagée consiste à définir un nouvelle algorithme, dénommé AES (Advanced Encryption Standard) et s'appuyant sur des clefs de 128 bits.
A titre d'exemple le Firewall M>WALL de Matranet ou Firewall-1 de checkpoint utilise dans son VPN un triple DES. Le triple DES est certainement hors d'atteinte aujourd'hui d'une attaque exhaustive.

Le DES reste un algorithme suffisant pour garantir la confidentialité des mots de passe dans le cadre d'une exploitation informatique (UNIX, MVS, NT), mais que la sécurité des échanges en environnement ouvert et non sûr, ne doit pas reposer uniquement sur lui. C'est d'ailleurs dans ce sens qu'il faut interpréter l'annonce périodique et à chaque fois repoussée de son remplacement (il est en effet massivement mis en œuvre).

IDEA

IDEA est un algorithme récent qui date de 1990. Il manipule des blocs de données de 64 bits et utilise une clé de chiffrement de 128 bits. Le même algorithme est utilisé pour les déchiffrements. Chaque bloc est divisé en 4 blocs de 16 bits qui sont additionnés, multipliés, combinés par des ou exclusifs, entre eux et avec 6 sous blocs de 16 bits dérivés de la clé de chiffrement. Ces opérations sont effectuées 8 fois. IDEA n'a pas été encore cryptanalysé , cet algorithme est actuellement hors de portée des processeurs du marché.

RC2 - RC4 - RC5

Tous trois sont d'origine RSA Data Security Inc, ils utilisent des clés privées de tailles variables. Ces algorithmes sont privés et leur spécifications n'ont jamais été publiées. RC2 a été vendu comme l'un des remplaçants du DES, il utilise des blocs de 64 bits, RC4 est un algorithme de chiffrement continu , tous trois sont prétendus plus rapides que les DES, et n'ont à ce jour pas été cassés. RC5 est un algorithme de chiffrement par blocs avec de nombreux paramètres : taille des blocs, taille de la clé, et nombre de rondes. Des études ont semble-t-il montré que RC5 est sûr après 6 rondes, néanmoins RSADSI recommande d'en utiliser au moins 12. Netscape (v3.0 minimum) utilise 2 ces algorithmes pour des communications sur des sites sécurisés (https), en plus de l'algorithme RSA à clés publiques

RSA

Le RSA est le cryptage à clé publique le plus connu, pour le chiffrement et l'authentification. Trois mathématicien du noms de Ron Rivest, Adi Shamir et Len Adleman ont décidé de réinventer totalement le principe du chiffrement dans les années 70. Le résultat sera la publication du RSA en 1977. Dans son principe ce n'est plus à l'expéditeur mais au destinataire qu'il incombe de créer la clé de cryptage. Il en crée à présent deux : une qu'il conserve et ne dois pas être divulguée (clé privée) et une clé publique qu'il pourrait distribuer
C'est le plus simple algorithme à clé publique à taille variable. La grande partie des cryptosystèmes à clé publique sont basées sur le RSA.

La puissance du cryptage RSA est basée sur la difficulté de factoriser un grand entier. Dans son fonctionnement l'operation retenu pour le RSA s'apelle modulo. Celui ci désigne le reste de la division euclidienne d'un entier par un autre. L'idée se résume à crypter un message en effectuant l'opération avec l'un des deux facteurs de ce produit (clé publique) et de le decrypter en accomplissant l'opération inverse, à l'aide de l'autre facteur (clé privée). Pour que cette condition puisse fonctionner, il y a une condition fondamentale, il faut choisir des nombre entier très élévée. Il n'existe aucun formule pour factoriser un nombre entier La seule possibilité de decryptage est d'essayer la formule avec tous les entiers.

le calcul d'une puissance modulo N est à la portée de tout ordinateur, ou même d'une calculatrice de poche programmable. Pour le moment, la sécurité du cryptage RSA repose sur la puissance des ordinateurs et sur les connaissances en arithmétique. Tout progrès dans un domaine comme dans l'autre peut obliger à allonger la clef. Il apparaît en effet aujourd'hui indispensable de crypter avec une largeur de clé d'au moins 256 bits. Pour plus de sécurité, 512 bits sont recommandés Il faut ainsi près de deux cent ans pour découvrir la valeur de 2 facteurs premiers d'un nombre écrit avec 2^128.

DH

DSS

MD2-MD4-MD5

MD5 est une fonction de hachage à sens unique conçue par Ron Rivest (Le R de RSA). MD signifie Message Digest, et 5 et la version de l'algorithme. Il produit des empreintes 128 bits, en manipulant le texte d'entrée par blocs de 512 bits. Il utilise autant de blocs de 512 bits qu'il y en a dans le texte à traiter. Si le texte n'est pas multiple de 512 bits, MD5 complète avec une chaîne bien définie. Chaque bloc subit 4 rondes, chaque ronde étant fonction des rondes précédentes sur les blocs précédents.

MD5 n'est basé sur aucune hypothèse, telle la difficulté de la factorisation, mais semble très résistant à la cryptanalyse. Bert Den Boer et Antoon Bosselaers ont démontré une faiblesse d'une des fonctions internes de la ronde de l'algorithme, avec des collisions de fonctions de compressions (collision signifie que 2 résultats d'entrée différents, donne un même résultat de sortie). Cela ne compromet en rien la sécurité pratique de MD5 en entier.

SHA

Le meilleur algorithme de hachage est le SHA " Secure Hash Algorithme " pour le standard appelé SHS " Secure Hash Standart ", élaboré par la NSA. Il est censé être utilisé à chaque fois qu'un algorithme sûr de hachage est requis pour des applications fédérales, notamment avec DSS. " Digital Signature Standart ". SHA est calqué sur le donctionnement de MD-4, avec une empreinte 160 bits, donc 1 chance sur 2^160 = 1.5*10^48 d'avoir une collision. Le SHA (Secure Hash Algorithm) est issu de l'Institut national des standards et de la technologie américain ainsi que de l'agence nationale de sécurité (NSA). Ce standard prend des fichiers de tailles variables en entrée, et en produit une empreinte de 160 bits (plus long que MD5), pour cela il utilise 5 variables initialisées, il prend ensuite dans la boucle principale des blocs de 512 bits en continu. La boucle principale comprend 4 rondes (ie une substitution suivie d'une permutation) de 20 opérations chacune. SHA ressemble à MD4 et MD5, il se distingue par une ronde supplémentaire, un mélange de bits amélioré Ainsi qu'un meilleur effet d'avalanche (chaque étape utilise en cascade le résultat de l'étape précedente). Il n'y a pas d'attaque cryptographique connue contre SHA, et il semble plus robuste que ses pairs (empreinte de 160 bits).

Le code d'authentification de CAM (MAC)

Le code d'authentification de messages est en fait un algorithme de hachage qui utilise en plus une clé privée nécessaire à la vérification de l'empreinte, cette clé étant elle même utilisée dans la génération du digest. Par exemple le RIPE-MAC utilise le DES, le RIPE-MAC3 utilisant quant à lui le triple DES. Les deux algorithmes composent des blocs de 64 bits. Une fonction de compression est alors utilisée pour haché ces différents blocs en un seul bloc de 64 bits( au moyen d'une clé) privée. Le bloc obtenu est enfin chiffré par une autre clé dérivé de lé clé privée de compression.

3.2. Synthèse : Tableau récapitulatif des différents algorithmes

Algorithme	Clé	Longueur de la clé	Principale utilisation
DES	Privée	56 bits (plus 8 de parité)	Confidentialité
3DES	Privée	56 bits	Confidentialité
RC2	Privée	De 1 à 1024 bits	Confidentialité
RC4	Privée	40 bits	Confidentialité
RC5	Privée	40 bits	Confidentialité
IDEA	Privée	128 bits	Confidentialité
RSA	Publique	1024 bits (voire 2048)	Authentification (signature) Echanges des clés
DH	Publique	?	Echange des clés
DSS	Publique	512 à 1024	Authentification (signature)
MD2	Publique	sans objet	Intégrité (hachage)
MD5	Publique	sans objet	Intégrité (hachage) - 128 bits
SHA	Publique	sans objet	Intégrité (hachage)- 160 bits
MAC	Publique	sans objet	Intégrité (hachage et codage)

4. LES CERTIFICATS

4.1. Présentation

Toutes les technologies décrites ci dessus sont au point et très séduisantes. Elles se fondent toutes lourdement sur les technologies à clés publiques :

• usage de RSA pour négocier des clés de chiffrement RC2 dites " de session ";
• usage de RSA pour sceller les messages (intégrité / authenticité)

L'idée actuellement poursuivie consiste à permettre à chacun de fournir sa clé publique à son correspondant au sein du message lui-même ou au travers de sites publiques non particulièrement sécurisés !. Cependant, cette méthode ne garantit plus réellement l'intégrité ni la signature puisqu'un tiers malveillant, intervenant sur le message, peut parfaitement fournir sa propre clé publique.

Les travaux en cours conduisent donc à fournir une clé publique certifiée : il s'agit en fait de constituer un message composé de l'identité de l'émetteur et de sa clé publique, le tout signé (MD5 + chiffrement RSA) par un organisme tiers dont la clé publique est censée être connue du destinataire. Bien sûr, ceci ne fait que repousser le problème, puisqu'il faut alors connaître la clé publique de l'organisme certifieur. En fait, le problème est considérablement réduit car un très grand nombre de clés publiques peuvent être certifiées par le même organisme.

Cette technique peut d'ailleurs être prolongée : l'organisme certifieur peut éventuellement fournir lui-même sa clé publique au travers d'un certificat scellé par un organisme certifieur " supérieur ". Il est ainsi possible d'envisager des chaînes de certificats.

A l'heure actuelle, les browsers (navigateurs) du marché sont livrés avec la connaissance intégrée des clés publiques d'une dizaine d'organismes certifieurs.

Cette architecture de certificats est très importante dans le cadre des travaux sur le commerce électronique et appelle de nombreuses réflexions et développements :

• il est important de savoir la confiance que l'on accorde à un certifieur (aujourd'hui, par exemple, les certificats VERISIGN CLASS 1 ne garantissent que l'existence de l'adresse Email fournie lors de la souscription du certificat);
• il est important de pouvoir invalider un certificat (ou plus généralement un organisme certifieur) dans un browser;
• il est envisageable de gérer au sein de son entreprise un générateur de certificats, voire une hiérarchie de générateurs de certificats, que l'on attribue à des interlocuteurs admissibles et que l'on utilisera dans les échanges applicatifs;
• une question très importante et mal résolue actuellement consiste à savoir comment les certificats sont manipulés par les postes de travail; l'idée généralement admise est que les clés privéess et les certificats associés sont stockés par les browsers et accessibles éventuellement au travers de mots de passe locaux; ce stockage est effectué lors d'une procédure combinée de fabrication du couple de clés et de fourniture de la clé publique au site certifieur; deux problèmes lourds se posent alors :
  • la gestion de postes de travail multi utilisateurs
  • la gestion d'utilisateurs multi postes de travail

Aucun mécanisme satisfaisant n'existe pour traiter ces problèmes, mais deux voies semblent crédibles :

• . une technique locale de stockage des informations personnelles sur un poste de travail combinée à une technique de représentation " en transit " sécurisée de ces données (approche " wallet " et protocole " PCX " de Microsoft)
• . technique de stockage externe sur carte à microprocesseur

4.2. Le certificat X509

L'ISO et l'ITU (International Télécommunications Union) ont standardisé un format pour le transfert sécurisé des clés publiques ; le Standard X.509 (ISO 9498-8). Le standard X.509 permet de fournir des clés publiques sécurisées en certifiant l'association clé publique - propriétaire de la clé.

Cette certification sera faite par une tierce partie : le " Certification Authority " (CA), qui signe le certificat. Les propriétés d'un certificat X509 sont essentiellement les suivantes :

• Tout utilisateur disposant d'un accès à la clé publique du CA peut retrouver la clé publique qui a été certifiée.
• Aucune entité autre que le CA, ne peut modifier le certificat sans que cela soit détectable (un certificat est de base infalsifiable).

Fort de ce constat (in falsification), les certificats peuvent être publiés/édités dans un annuaire, par exemple de type X500, sans nécessiter de protection particulière.

4.2.1. Contenu du certificat X.509

Le certificat X.509 est une chaîne d'octets codés en ASN.1 contenant :

• Numéro de version (1988, 1993 ou 1993 avec extensions),
• Numéro de série du certificat (identificateur unique),
• Période de validité,
• Nom de l'utilisateur,
• Informations sur la clé publique (identificateur et type d'algorithme utilisé),
• Extensions (ex : nom X.400, ...),
• Nom X.500 du de l'émetteur du certificat (CA),
• Signature du CA.

Toutes les autres clés publiques sont stockées dans le Directory X.500 en tant que certificats X.509.

Chaque application qui requiert un certificat doit vérifier la signature sur le certificat en utilisant la clé publique du CA avant d'utiliser la clé.

5. LES PROTOCOLES DE MISE EN ŒUVRE

Les protocoles de mise en œuvre sont essentiellement chargés, au-dessus de liaisons point à point mettant en relation deux interlocuteurs pour :

• négocier les échanges de certificats (optionnels) de l'un, l'autre ou les deux interlocuteurs ;
• négocier la fabrication et la mise en œuvre d'une éventuelle clé privée de session ;
• négocier et mettre en œuvre les algorithmes de chiffrement / scellement retenus.

5.1.1. Acteur

Le protocole SSL (Secure Sockets Layer), dont les spécifications sont publiées sur Internet et par l'IETF, est d'origine Netscape. Il est adopté par les principaux producteurs de logiciels et de matériels, les institutions financières et les autorités de certification. SSL est installé dans environ 75 % des logiciels de navigation Internet. SSL est un standard reconnu dont l'usage est fortement conseillé dans le cadre d'applications WEB Intranet ou Internet.

5.1.2. Principes techniques

Le protocole SSL sécurise les communications entre une application cliente et une application serveur. Il s'appuie sur la couche TCP. L'avantage de SSL réside dans son indépendance vis à vis des applications de plus haut niveau : FTP, HTTP, Telnet ...

Les objectifs du protocole SSL (SSL Protocol v3.0) par ordre de priorité sont :

• La sécurité du chiffrement,
• L'interopérabilité,
• L'extensibilité à d'autres méthodes de chiffrement (qu'il est possible d'intégrer).

Il utilise les quatre propriétés de base suivantes :

• La connexion est privée. Le chiffrement est fait après la connexion initiale de définition de la clé privée client et d'authentification du serveur. Un algorithme de chiffrement symétrique (DES, RC4, etc.) permet de chiffrer les données.
• L'identification peut être faite par un algorithme de chiffrement asymétrique (RSA, DSS, etc.), c'est-à-dire par la clé publique. SSL authentifie toujours le serveur et peut dans la version V3 du protocole authentifier le client de la communication.
• SSL assure l'intégrité des données grâce à un champ spécial, appelé champ MAC (Message Authentification Code). Ce champ fait partie intégrante de la structure des données SSL.. Des fonctions robustes de hash-coding (SH1, MD5, etc.) sont utilisées pour calculer le code d'authentification des messages.
• Les certificats respectent la syntaxe X509.

Le protocole SSL permet d'établir un tunnel, rendu privé grâce à des mécanismes de chiffrement.

SSL intègre une optimisation de la mémoire cache, en particulier pour les opérations sur les clés publiques, ce qui réduit le nombre de connexions et augmente la rapidité dans les opérations de chiffrement. L'établissement d'une connexion passe par trois étapes :

• Une étape de reconnaissance mutuelle où le client et le serveur échangent des informations relatives aux numéros de versions, aux algorithmes de chiffrement symétrique suivie par l'obtention du certificat du serveur.
• Une étape de création d'une nouvelle clé symétrique pour le chiffrement des communications.
• Une étape de chiffrement des communications.

Relation entre SSL, TCP/IP et la couche applicative

5.1.3. Etablissement des communications avec SSL

SSL est un protocole fonctionnant en full-duplex, qui repose sur 2 niveaux :

• Le niveau le plus bas, nommé " SSL Record Protocol " est situé au dessus du protocole TCP.
• Le " SSL Handshake Protocol " permet la négociation des algorithmes et des clés de chiffrement entre le client et le serveur.

Le mécanisme d'établissement d'une connexion sécurisée dans le cas où le client n'a jamais communiqué avec le serveur et où l'authentification du client n'est pas requise est le suivant :

• Le client envoie au serveur un message " CLIENT-HELLO " (en clair) qui comporte la version SSL utilisée, les algorithmes supportés, les méthodes de compression, un aléa client, un identificateur de session.
• Le serveur renvoie au client un message " SERVER-HELLO "( en clair), après avoir vérifié les données contenues dans le " CLIENT-HELLO " , contenant le certificat du serveur et les algorithmes de chiffrement choisis (les plus forts), un aléa, un identificateur de session, et un Serveur_hello_done en clair.
• Si le résultat de ces premiers contacts demande la génération d'une nouvelle clé, le serveur n'ayant pas gardé en cache une précédente connexion, le client crée une nouvelle clé en fonction du contenu du message " SERVER-HELLO " et envoie un message " CLIENT-MASTER-KEY " au serveur contenant la nouvelle clé chiffrée avec la clé publique du serveur, le tout sur une longueur de 48 octets. De cette nouvelle clé découlera deux clés (lecture/écriture) pour le serveur et deux clés pour le client (lecture/écriture). La clé de lecture du client est aussi la clé d'écriture du serveur et vis et versa.
• Le serveur renvoie un message au client " SERVER VERIFY ". A partir de cette étape, le serveur est considéré comme authentifié (seul le serveur ayant fourni la clé publique a pu déchiffrer la clé générée par le client).

" Handshake " du protocole SSL dans le cas où l'authentification du client n'est pas demandée.

L'établissement d'une session SSL nécessite un nombre de communications significatif, et deux calculs RSA 512 bits au niveau du client (vérification du certificat serveur, et chiffrement de la clé maître). Sur une même session il est possible d'établir plusieurs connexions, puisqu il y a établissement d'une connexion pour chaque URL sécurisée demandée par le client. Dans ce cas la valeur de l'identificateur de session sera instanciée (non nulle contrairement à l'initialisation) et mémorisée dans un cache serveur de manière paramétrable. Dans l'option où l'authentification du client est requise, les échanges entre le client et le serveur continuent jusqu'à l'obtention du certificat du client.

Si le client et le serveur ont déjà établi une session, le client a gardé un identifiant de session. Le client le communique au serveur lors du premier message, le " CLIENT-HELLO ". Si le serveur a également conservé une trace de la communication avec ce client, les clés de lecture-écriture des deux parties sont générées à partir du souvenir de la clé symétrique échangée lors de la dernière connexion. Dans ce cas les deux extrémités calculent un nouveau jeu de secrets pour la nouvelle connexion à partir de la clé maître de la session et des aléas échangés pour la connexion. Cette cinématique est plus rapide puisqu'elle ne nécessite aucun calcul RSA.

Les mécanismes de chiffrement et de signature mis en œuvre pour protéger la phase de transfert de données utilisent un jeu de six secrets, calculés à partir de la clé maître de la session. Ce calcul de diversification de la clé maître est réalisé à l'établissement de chaque connexion de la session SSL.

SSL		Fonction
client_write_MAC	->	Calcul d'intégrité coté client
serveur_write_MAC	->	Calcul d'intégrité coté serveur
client_write_key	->	Clé de chiffrement pour le client
serveur_write_key	->	Clé de chiffrement pour le serveur
serveur_write_vecteur	->	Valeur d'initialisation pour le chiffrement, coté serveur
client_write_vecteur	->	Valeur d'initialisation pour le chiffrement, coté client

Ces six valeurs sont calculées à partir de la clé maître et des deux aléas échangés lors de la phase initiale, et sont valables uniquement pour la connexion en cours.

Lorsque HTTP est utilisé au dessus de SSL, l'ensemble est désigné sous le terme de HTTPs, à ne pas confondre avec S-HTTP développé par IET (Integration Enterprise Technologies).

Le chiffrement des données s'effectue à l'issue des négociations (qui sont elles même chiffrées). Les algorithmes qui peuvent être utilisés (dans la version 3 de SSL) sont :

• RC2,
• RC4,
• IDEA,
• DES,
• 3DES.

• MD5,
• RSA,
• SHA,
• MAC.

• RSA,
• DH,
• DSS,
• FORTEZZA.

Les avantages de SSL V3 portent sur les points suivants :

• Amélioration de la sécurité du protocole : impossibilité d'attaque en coupure en injectant notamment des hello messages forçant les clients et le serveur à travailler en 40 bits . SSL V3 corrige ce problème en signant le dernier message de challenge avec une hash value des précédents messages de challenges.
• SSL V2 utilise une faible construction de l'algorithme MAC, ce problème est corrigé en V3.
• SSL V2 effectue du padding dans les blocs de scellement MAC et ne signe pas le champ indiquant la longueur de remplissage, laissant ainsi la possibilité à un attaquant de supprimer des octets à partir de la fin des messages. Ce problème est corrigé en V3.
• Avec SSL V3 les empreintes des messages (MACs) utilisent en input des clés d'une longueur réelle de 128 bits, même en version export, au lieu de 40 bits en SSL V2 .
• En V3 le protocole de challenge peut être relancé en milieu de session (en V2 il n'est effectué qu'à l'initialisation). De la même manière, le serveur peut demander à changer les algorithmes et les clés utilisés.
• SSL V3 utilise un protocole généralisé d'échanges de clé, il supporte Diffie-Hellman et Fortezza et des certificats non-RSA.
• SSL 3.0 autorise la compression et la décompression.
• Comme nous l'avons déjà évoqué, le serveur peut demander l'identification du client. Cette fonctionnalité importante nécessite une certification du client par l'organisme qui gère le serveur, tout autre type de certification par des tiers de confiance non impliqués n'a pas d'intérêt.

• Un serveur SSL V3 reconnaît un client SSL V2.
• Un client V3 peut générer un client Hello de type V2.
• Un serveur V2 forcera un client V3 à dialoguer après le Hello en SSL V2.
• Un serveur V3 forcera par défaut un client V3 à dialoguer en V3 et non pas en V2, à moins que le " Handshake " soit forcé à se dérouler en V2.

SSL a été conçu pour sécuriser les échanges entre un client et un serveur au travers d'un réseau non sûr. En autre, son but est d'éviter les " man-in-the-middle attacks " ou attaque en coupure par intervention d'un intrus au milieu des échanges sécurisés (attaque en coupure de flux). Ainsi, dans une architecture mettant en jeu un bastion, il est impossible de relayer applicativement (proxy) les flux dans le but de les traiter par un garde-barrière. SSL considère en effet un proxy comme un intrus dans les échanges. La seule solution est d'utiliser la fonctionnalité de filtrage de paquet (contextuel) au niveau du firewall, en réservant un port autorisé pour les services de type SSL+HTTP ou SSL+NNTP (respectivement 443 et 563 ). L'idée étant d'autoriser sans restriction (et si possible uniquement) l'établissement de communication sur ces ports. Le risque résiduel dans ce type d'approche réside dans le fait qu'un pirate peut construire une attaque en utilisant des ports reconnus par le firewall, sans utiliser SSL, et sans que celui-ci s'en rende compte.

A titre d'information, le tableau ci-dessous reprend les différentes applications possibles de SSL.

PROTOCOLE	N° DE PORT
HTTPS	443/TCP
SSMTP	465/TCP 563/TCP
SNEWS	563/TCP
SSL-LDAP	636/TCP
SPOP3	995/TCP

5.1.7. Mise en œuvre

Le système SSL (Secure Sockets Layer) est présent dans Netscape 2, 3 et 4 ou Internet Explorer 2, 3 et 4. Il permet d'authentifier les connexions entre un client et un serveur, ainsi que d'en chiffrer les échanges. Une clé de session est générée par le poste client, qui la crypte avec la clé publique du serveur et l'envoie. La "session" de communication Client/Serveur qui suit est alors cryptée avec la clé de session. Ainsi, il se crée un canal sécurisé entre le client et le serveur où sont échangés des messages HTTP par exemple, intrinsèquement protégés. Il est ainsi possible d'accéder au répertoire sécurisé avec Internet Explorer 3.0 et Netscape 3.0. Une option permet d'activer ou de désactiver la prise en compte des sites sécurisés :

• Dans le navigateur Internet Explorer 3.0, l'option se trouve dans le menu View/Options/Advanced puis "cryptography settings".
• Dans Netscape 3.0, l'option se trouve dans le menu Options/Security Preference puis General.

5.2. La certification et SSL

Un certificat est un document électronique qui atteste qu'une clé publique est bien liée à une organisation ou personne. Il permet la vérification de la propriété d'une clé publique pour prévenir la contrefaçon de clés publiques. Un certificat contient généralement une clé publique, un nom ainsi que d'autres champs pour identifier le propriétaire, une date d'expiration, un numéro de série, le nom de l'organisation qui contresigne le certificat et la signature elle-même. Le format des certificats est défini par la norme X509.

Le certificat est donc une attestation que les informations qu'il contient sont exactes. Pour cela, le certificat doit être généré par un tiers de confiance, c'est-à-dire un organisme indépendant qui contrôle la véracité de ces informations. Le CA (Certifying Authority, autrement dit l'organisme certificateur) donne la crédibilité au certificat ; les utilisateurs du certificat en vérifieront la signature et auront confiance en ce certificat si eux même ont confiance en le CA.

Il existe typiquement deux types de certificats utilisés avec SSL :

• Pour serveur,
• Pour client.

5.2.1. Comment obtenir un certificat SSL ?

Certificat pour serveur

Procédure d'obtention d'un certificat pour un serveur:

Avant de chercher à obtenir un certificat pour un serveur, diverses vérifications sont nécessaires. Tout d'abord vérifiez que vous avez un serveur Web qui supporte SSL.

Après avoir installé votre serveur Web SSL, vous devrez utiliser une fonction de ce serveur pour générer une demande de certificat (CSR, Certificate Signing Request). Recherchez la section détaillant cette opération dans l'aide de votre logiciel.

Lors de la demande de certificat vous allez générer une clé privée. Dès que cette clé est générée, faites en une copie de sauvegarde et protégez là très sérieusement. Si cette clé tombe entre de mauvaises main votre sécurité est en danger et il faudra révoquer votre clé publique.

Lors de la génération de CSR, un certain nombre de champs vous seront proposés pour y saisir les informations. Attention, le champ "Common Name" (si présenté par votre logiciel) doit contenir l'adresse FQDN de votre serveur Web (par exemple, www.entreprise.com ou secure.entreprise.com); Les adresses IP sont refusées.

Une fois la demande de certificat générée, il ne nous reste plus qu'à choisir le CA (tiers certificateur). Si votre serveur doit être acceptable par n'importe quel utilisateur d'Internet vous devez choisir un CA reconnu mondialement. Si votre serveur est destiné à un intranet, alors vous pouvez soit générer votre certificat en le signant vous-même, soit devenir votre propre CA.

Certificat pour client

Un certificat client est un certificat qui identifie l'utilisateur d'un navigateur Web, et qui a vocation à identifier avec certitude un unique individu. Ce certificat est basé sur une clef publique/privée qui est stockée par le navigateur (à l'avenir, cette clef sera probablement sur carte à puce). De la même façon qu'un certificat pour serveur n'a pas de sens tant qu'il n'est pas authentifié par un tiers, le certificat client à besoin d'être signé.

5.2.2. Les différents types de certificats

On peut différencier deux types de certificats suivant leurs signatures: les certificats signés par un serveur ou un organisme local (par exemple l'entreprise qui exploite un serveur SSL) et les certificats signés par un tiers certificateur reconnu de tous.

5.4. LE PROTOCOLE S-HTTP (SECURE HYPERTEXT TRANSFER PROTOCOL)

5.4.1. Présentation

HTTP est le protocole utilisé pour le transfert de documents HTML entre les clients et les serveurs Web. Ce protocole ne propose pas de sécurité. S-HTTP est une version sécurisée du protocole HTTP. S-HTTP a été développé et distribué gratuitement par le NCSA (National Center of Supercomputer Application). Cette extension de l'actuel HTTP est disponible sur le papier depuis juillet 1995 et est en cours de standardisation par l'IETF.

Les caractéristiques de S-HTTP sont :

• L'assurance d'une confidentialité grâce au chiffrement des documents ;
• L'authentification du serveur comme du client ;
• L'assurance de l'intégrité du message avec un champ MAC (Message Authenticity Check) ;
• L'assurance de la non-répudiation du message, c'est-à-dire que l'utilisateur ne pourra pas nier l'existence d'une transaction.

Le client HTTP se connecte sur la " Home Page " d'un serveur HTTP. Sur cette " Home page ", des liens hypertextes possèdent des tags indiquant une méthode cryptographique à utiliser pour le lien en question. Le client qui clique sur ce lien hypertexte compare ses options de chiffrement avec celles spécifiées dans le lien. S'il n'y a pas de concordance, la requête vers ce lien n'est pas transmise au serveur. Dans le cas contraire la requête est transmise au serveur. Le client ajoute ses options de chiffrement dans cette requête. Le serveur reçoit la requête et vérifie les options de chiffrements du client et envoie le document au client.

5.4.3. Considérations générales

Le serveur doit posséder une paire de clés asymétriques et un certificat délivrés par une autorité de certification. Pour distribuer sa clé publique au client, le serveur utilise le certificat. Le certificat est composé de la clé publique du serveur, du nom du serveur, du numéro de série du certificat et de la date d'expiration du certificat. Ces informations sont chiffrées avec la clé privée de l'autorité de certification de manière à pouvoir être déchiffrées par le client avec la clé publique de l'autorité de certification. Le client doit également posséder une paire de clés asymétriques et un certificat. Il est possible d'envoyer aux clients le certificat du serveur en l'incluant dans une page HTML.

5.4.4. Le chiffrement des messages

S-HTTP peut utiliser deux mécanismes pour l'échange de clés de chiffrement. Le premier utilise la clé publique du destinataire pour chiffrer une clé symétrique (DES, IDEA), le second permet l'utilisation de clés externes à S-HTTP via une ligne d'en-tête de S-HTTP. S-HTTP peut ainsi encapsuler des messages chiffrés avec PKCS-7, PEM ou encore Kerberos. Le choix de la ou des méthodes de chiffrement utilisées, se fait par une négociation entre le client et le serveur selon les algorithmes supportés. Si le client ne possède pas de clé publique, une transaction par affectation directe d'une clé symétrique peut tout de même s'établir, ce qui permet l'établissement d'une transaction même si le client ne possède pas de clé publique.

Il existe en effet une option négociation qui permet aux clients et aux serveurs de se mettre d'accord sur les modes transactionnels, à savoir :

• les messages sont signés ou non (utilisation de RSA, DSA ou PGP-algorithme de chiffrement issu du domaine public),
• Les messages sont chiffrés ou non (DES, RC2, RC4, IDEA).

• une en-tête est ajouté aux messages HTTP
• cet en-tête et le message sont chiffrés et/ou signés
• l'ensemble est ensuite encapsulé dans un message S-HTTP

5.4.5. L'authentification

Pour assurer l'authentification de l'expéditeur, S-HTTP requiert un certificat délivré par une autorité de certification.

5.4.6. L'intégrité du message

Pour assurer l'intégrité d'un document S-HTTP utilise un mécanisme de signature électronique. Une fonction de " Hash Code " est passée sur le document pour générer un code MAC (Message Authentification Code). Ce code est fonction du texte du document et de la date pour prévenir les attaques en " play-back ", attaques où un message copié par un pirate est rejoué tel quel. Toujours pour prévenir les attaques en play-back, un mécanisme appelé " Nonce " permet de s'assurer de l'identité de l'autre partie à n'importe quel moment de la transaction. L'une des parties envoie un " Nonce ", une valeur donnée, à l'autre partie qui la chiffre et la renvoie à l'expéditeur. Si la réponse n'est pas chiffrée avec la clé sécrète, l'expéditeur refuse la connexion.

5.4.7. Le mécanisme de récupération du message en clair

Le destinataire du message S-HTTP doit lire les en-têtes du message S-HTTP pour reconnaître l'algorithme de chiffrement utilisé sur le message.

5.4.8. Comparaison de S-HTTP et de SSL

Les buts poursuivis sont les mêmes, ont notera principalement que SSL fonctionne entre la couche TCP/IP et la couche application alors que S-HTTP assure la sécurité du protocole applicatif HTTP.

5.4.9. Algorithmes supportés

Le chiffrement des messages peut être réalisé par :

• DES
• 3DES
• IDEA
• RC2
• CDMF

• RSA
• DSS

Kerberos

• RSA

• MD2
• MD5
• MAC

Avantages

• La sécurisation des messages HTTP

• Le caractère spécifique aux services HTTP.
• Son positionnement par rapport à SSL qui fournie le même service et qui freinera son déploiement (voire l'empêchera).

5.5. LE PROTOCOLE PCT (MICROSOFT)

5.5.1. Présentation

Le standard PCT (Private Communication Technology) est né début novembre 1995 au sein d'un comité de réflexion regroupant des noms connus sur le marché des couches IP : Netmanage, Cylink, Spyglass, Openmarket, Novell, Compuserve et Microsoft. Il est étudié par l'IETF et correspond au RFC 1750.

PCT est la technologie proposée par Microsoft pour assurer la sécurité des communications privées. PCT est très proche de SSL. La version 1 de PCT corrige un certain nombre de faiblesses de SSL, notamment dans l'efficacité des techniques d'authentification. PCT sépare les techniques de chiffrement des techniques d'authentification, ce qui permet aux applications d'utiliser des clés de plus de 40 bits pour l'authentification. En conséquence, PCTRef (nom du logiciel qui implémente PCT) n'est disponible que sur le territoire américain et au Canada.

Ce protocole se situe entre la couche transport et la couche applicative. De ce fait, ceci le rend transparent pour les applications Internet. Techniquement, il est complètement comparable à SSL (positionnement, objectifs, architecture, etc.). La résistance attendue de PCT au piratage est annoncée comme allant au-delà de celle de SSL. PCT permet aux applications d'utiliser une méthode d'authentification avec un algorithme supérieur à 40 bits.

5.5.2. Synthèse

En pratique, il faut considérer que SSL et PCT ne sont que des sous-produits de la gigantesque guerre entre Netscape (leader SSL) et Microsoft (leader PCT). il est clair que le marché actuel est SSL.

Complément d'informations sur PCTRef http://pct.microsoft.com/pct/pctref1.html
Spécifications de PCT http://pct.microsoft.com/pct/pct.htm

L'inconvénient majeur est semble-t-il l'abandon quasi officiel de Microsoft sur ce projet, actuellement seul Netmanage implémente PCT. Dans l'état actuel, ce produit ne peut être retenu comme standard.

5.6. TLS

5.6.1. Présentation

TLS, " Transport Layer Security " n'est pas encore implémenté aujourd'hui. Il est complètement identique en positionnement, architecture et objectifs à SSL et PCT. Son existence, étudiée par l'IETF et les groupes de travail sécurité associés, semble essentiellement destinée à créer une convergence " neutre " entre SSL et PCT. Il pourrait à ce titre être la solution finale en matière de protocole de négociation et de mise en œuvre des algorithmes de sécurité entre deux correspondants.

Il est toutefois important de noter que les spécifications de TLS sont strictement identiques (à quelques exceptions près) aux spécifications de SSL V3 (à tel point que le draft remis à l'IETF (en décembre 1996) a été réalisé par Netscape et qu'il reprend pratiquement mot pour mot le document SSL).

5.6.2. Principe de base

Les principes techniques de TLS sont strictement identiques aux principes techniques de SSL V3. Les objectifs sont les mêmes ; il existe deux niveaux de protocole (TLS Record Protocol et TLS Handshake Protocol) ; les numéros de port pour HTTP, SMTP et NNTP sont identiques. 3 nouveaux numéros de port ont cependant été rajoutés :
636 pour l'utilisation de TLS avec LDAP (light directory access protocol ; ssl-ldap) Avertissement : " ssl-ldap " n'est pas une erreur de notre part, cette notation est celle du draft remis à l'IETF.
990 pour l'utilisation de TLS avec TFP (ftps)
995 pour l'utilisation de TLS avec POP (spop3)
La gestion des clés avec KERBEROS est possible avec TLS (ce qui n'est pas le cas avec SSL).

5.6.3. Synthèse

Avantages

• La convergence entre SSL et PCT
• La sécurisation des principaux protocoles utilisés sur Internet
• Le support de Kerberos

• Le manque d'implémentation

  Sources :

  [www.rsa.com| http://www.hrnet.fr/~matthieu/crypto/432.htm| Sniffdoz (pour plus d'infos)]

Retour au source
De base un hub émet les paquets reçus par un expediteur quelconque à l'ensemble des utilisateurs connectés à ce hub (principe du broadcast). Avec un switch, chaque paquet émis n'est attribué qu'au destinataire désiré. Dans ce cas, la selection dans la distribution des paquets se fait au niveau de l'adresse MAC (niveau 2 de l'OSI). Un switch assure un canal de communication exclusif et non paratagé entre deux machines qui s'échangent des données.

Dans le principe sur un switch chaque connexion (prise) est liée à une adresse MAC, l'allocation prise/adresse MAC se fait soit de facon dynamique, ce système est géré par le switch, soit en statique, ou l'administrateur écrit en dur dans le switch les correspondances.

L'attaque du train postal
Il existe une faille dans la gestion dynamique de l'allocation prise/MAC. Un programme va nous permettre de la mettre en évidence en detournant un canal de communication, ceci nous permettra de recevoir des paquets qui ne nous étaient pas destinés. Ceux qui ont eu l'idée d'installer Linux sur leur machine, vont pouvoir la découvrir en utilisant le programme HUNT de Pavel Krautz.

Comment ça marche ?
Tout d'abord, Hunt va demander au switch de ne plus associer telle prise avec telle adresse MAC, et inserer la notre sur la prise voulue. Il va ensuite forcer le switch à router les paquets à destination de notre adresse MAC. Nous allons tous simplement dérouter les paquets... Prenant la place de la victime.

Evidemment un telle attaque demande de connaitre les adresses MAC des personnes connectées au switch (si vous connaissez l'IP une petit commande ARP va nous permettre de découvrir son adresse MAC)

La seule sécurité possible reste le cryptage de l'information (PKI, RSA, blabla...)

Vous pourrez télécharger Hunt1.3, sur le site de Pavel Krautz

Lexique :

Hub : boitier qui concentre un ensemble d'ordinateur, il effectue la concentration et la retransmission des messages qu'il recoit d'un emetteur vers l'ensemble des destinataires connectés au hub.

Switch : boitier qui concentre un ensemble d'ordinateur, effectue la concentration et la retransmission des messages qu'il recoit d'un emetteur vers un destinataire précis. (selection par l'adresse MAC)

Sniffdoz

L'évolution d'une nouvelle culture globale d'échanges et de gestion de réseau d'information électronique a signifié que des compagnies sont confrontées à une plus grande probabilité d'être une victime de fraude, sniff d'email, vol de données aussi bien que la corruption involontaire des fichiers par les employés non autorisés. l'infrastructure de clé publique (PKI) est la combinaison de logiciels, de technologies de chiffrement, et de services qui permettent à des entreprises de protéger leurs transmissions et transactions sur l'Internet.

Principe :

Une clé publique est une valeur fournie a une autorité indiquée comme clé dite sure (RSA, DES..), combinée avec une clé privée dérivée de la clé publique, et qui peut être employée pertinemment pour chiffrer et déchiffrer des messages et des signatures digitales.

Dans la cryptographie, une clé est une valeur variable qui est appliquée en utilisant un algorithme a une chaîne de caractères ou à un bloc de texte non codé pour produire le texte chiffré. La longueur de la clé détermine généralement la difficulté à déchiffrer le texte dans un message donné.

Le chiffrement est la conversion des données dans une forme, appelée un chiffre (cipher), qui ne peut pas être facilement compris par les personnes non autorisées. Le déchiffrage est le processus de convertir des données chiffrées de nouveau dans sa forme initiale, ainsi il peut être compris.

Une signature digitale (a ne pas confondre avec un certificat digital) est une signature électronique écrite, qui peut être employée par quelqu'un pour authentifier l'identité de l'expéditeur d'un message ou du signataire d'un document. Il peut également être employe pour s'assurer que le contenu initial du message ou du document qui ont été donnés est inchangé. Les avantages supplémentaires à l'utilisation d'une signature digitale sont qu'elle sont facilement transportables, ne peuvent pas être facilement niées, ne peuvent pas être imitées par quelqu'un d'autre, et peuvent être automatiquement horodatées.

L'utilisation des clés publiques et privées combinées est connue en tant que cryptographie asymétrique. Le système pour l'usage des clés publiques s'appelle une infrastructure à clé publique (PKI).

Fonctionnement:

Chaque utilisateur d'un cryptosysteme de clé publique possède une paire relative de clés.

Un texte par exemple encodé avec une clé peut seulement être décodé par lui. Chaque utilisateur garde une clé secrete principale et édite l'autre.

Ainsi d'autres peuvent utiliser la clé publique de l'utilisateur pour envoyer les messages que seul l'utilisateur peut lire, ou l'utilisateur " signe " son message avec sa clé privée d'authentification - les autres peuvent appliquer la clé publique de l'utilisateur pour vérifier que le message est venu de l'utilisateur.

L'infrastructure de clé Publique (PKI) est la combinaison du logiciel, des technologies de chiffrement, et des services qui permettent à des entreprises de protéger la sécurité de leurs transmissions et transactions sur l'Internet.

Les PKIs intègrent les certificats digitaux (CA), la cryptographie à clé publique, et les certificat d'autorités , dans l'ensemble de l'architecture de l'entreprise et sécurise le réseau. Le PKI d'une entreprise typique adresse à l'ensemble de l'établissement des certificats digitaux à différents utilisateurs et serveurs; avec logiciel d'inscription d'utilisateur; intégration avec les répertoires de corporation de certificat; outils pour contrôler, remplacer, et retirer des certificats; et services et support relatifs.

Sniffdoz