![](\"https://upload.wikimedia.org/wikipedia/commons/thumb/d/da/Internet2.jpg/440px-Internet2.jpg\")
Source:https://upload.wikimedia.org/wikipedia/commons/thumb/d/da/Internet2.jpg/440px-Internet2.jpg
Mettre le résultat ici (code et figure).
Avec les acquis du programme de première [NSI 1'°, chap. 26, 28 et 29], nous pouvons comprendre exactement ce qu'il se passe lorsque l'on navigue
vers un site web, par exemple « https://www.sciencesappliquees.com/ ».
- L'URL du site est décodée par le navigateur.
- Ce dernier isole le protocole (HTTP), le nom de domaine (www.sciencesappliquees.com) et le chemin vers la ressource (ici /, la « racine » du site).
- Le navigateur effectue une résolution de nom pour déterminer l'adresse IP correspondant au nom de domaine (209.245.128.109).
- Le navigateur peut alors établir une connexion TCP vers l'adresse IP du serveur web, sur le port 80.
- Une fois la connexion établie, client et serveur échangent des données en utilisant le protocole HTTP.
![](\"https://sciencesappliquees.com/images/nsi/secu2.jpg\")
On se souvient aussi que les communications sur Internet utilisent un ensemble de protocoles, organisés en couches:
- Couche matérielle avec des protocoles tels que Ethernet ou 802.11 n.
- Couche Internet, avec le protocole IP permettant de définir des routes, c'est-à-dire l'ensemble des machines du réseau traversées pour atteindre la machine de destination.
- Couche de transport avec les protocoles UDP ou TCP, qui s'occupent en particulier de garantir l'intégrité des données transmises (garanties minimales pour UDP ou très fortes pour TCP).
- Couche d'application dans laquelle se trouvent les protocoles de haut niveau : HTTP, IMAP, etc.
Ce processus à été très peu modifié depuis la conception de TCP/IP à la fin des années 1970.
Chaque protocole (SMTP, FTP, puis HTTP au
milieu des années 1990), s'est inséré dans ce cadre au niveau de la couche
d'application.
Cependant, avec la démocratisation d'Internet, du Web et la diversification des usages, des problèmes sont apparus.
En effet, comme on le sait, les données transmises par le protocole de la couche d'application sont découpés en paquets TCP, eux-mêmes encapsulés dans des paquets IP.
![](\"https://sciencesappliquees.com/images/nsi/trame.jpg\")
![](\"https://sciencesappliquees.com/images/nsi/secu1.jpg\")
Ces paquets IP sont envoyés par la source au prochain routeur de son sous-réseau.
Ce routeur retransmet ensuite le paquet au routeur suivant et ainsi de suite jusqu'à l'arrivée à destination.
Chaque routeur peut donc inspecter les paquets pour en connaître le contenu.
Cette situation n'est clairement pas idéale.
En effet, si l'on utilise un site web pour effectuer des transactions bancaires, renseigner des informations personnelles (impôts, arrêt maladie, etc.), ou simplement exprimer son opinion, on souhaite que le contenu des messages envoyés ne soit connu que de deux entités:
la source et la destination.
Ce simple constat nous permet de mettre en avant trois aspects liés à la sécurisation des communications:
- Comment chiffrer le contenu des communications, afin qu'elles ne soient lisible que par la source et la destination?
- Comment garantir que le serveur auquel on se connecte est bien celui de la personne et ou de l'entité auquel on pense se connecter?
- Comment garantir les deux propriétés ci-dessus en réutilisant l'infrastructure d'Internet, à savoir les communications TCP/IP?
Mettre le résultat ici (code et figure).
Une première technique lorsque l'on souhaite chiffrer un message est d'utiliser une méthode de chiffrement symétrique.
Formellement, une telle méthode est donnée par deux fonctions :
c(m,k) est la fonction de chiffrement. Elle prend en arguments un message en clair m (une chaîne de caractères par exemple) et une clé de chiffrement k (qui peut être une chaîne de caractères, un nombre, etc.).
Elle produit en sortie une chaîne de caractères chiffrée s.
d(s,k) est la fonction de déchiffrement. Elle prend en arguments un message chiffré s et une clé de déchiffrement k et renvoie le message en clair m.
Le terme symétrique vient du fait que la même clé est utilisée pour chiffrer et déchiffrer le message.
Un exemple simple de méthode de chiffrement symétrique est le chiffrement par décalage, encore appelé codage de César (de l'empereur romain Jules César qui utilisait cette technique pour ses correspondances militaires).
La méthode consiste à choisir un entier n et à décaler chaque lettre du message initial de n lettres dans l'alphabet (en recommençant à « A » si le décalage fait dépasser « Z »).
Ici, l'entier n constitue la clé de chiffrement.
Par exemple, en utilisant un décalage de 5 lettres, le message
L INFORMATIQUE C EST SUPER
devient
Q NSKTWRFYNVZJ H JXY XZUJW
La fonction de déchiffrement consiste à prendre un message chiffré et à décaler chaque lettre de n positions vers l'arrière.
Une méthode de chiffrement un peu moins naïve est le chiffrement par XOR (ou ou exclusif).
Nous l'avons vu en première sur la séquence sur les portes logiques:
![](\"https://sciencesappliquees.com/images/pl2/portexore\") | ![](\"https://sciencesappliquees.com/images/pl2/portexora\") |
| Symbole européen | Symbole américain |
Cett porte logique XOR a pour table de vérité (compléter):
| P | Q | R |
| 0 | 0 | |
| 0 | 1 | |
| 1 | 0 | |
| 1 | 1 |
Celle-ci repose sur l'utilisation de l'opérateur binaire ou exclusif noté ⊕.
Étant donné un message m (par exemple
« L'INFORMATIQUE C'EST SUPER ») et une clé de chiffrement k (par exemple
« NSI »), on recopie plusieurs fois la clé de façon à obtenir une chaîne de la
même longueur que le message:
L'INFORMATIQUE C'EST SUPER
NSINSINSINSINSINSINSINSINS
Chaque caractère du message et de la clé augmentée est ensuite converti en
nombre (par exemple en son code Unicode (utf-8):
76 39 73 78 70 79 82 77 65 84 73 81 85 69 32 67 39 69 83 84 32 83 85 80 69 82
78 83 73 78 83 73 78 83 73 78 83 73 78 83 73 78 83 13 78 83 73 78 83 73 78 83
On effectue ensuite l'opération entre chaque nombre du message et de la clé.
Nous la détaillons ci-dessous entre les nombres 84 (lettre « T »} et 78 (lettre « N ») :
0 1 0 1 0 1 0 0 84
⊕ 0 1 0 0 1 1 1 0 78
0 0 0 1 1 0 1 0 26
On rappelle que l'opération ⊕ entre deux bits renvoie 0 si les deux bits sont égaux et 1 s'ils sont différents.
Le message chiffré sera donc:
2 116 0 0 21 6 28 30 8 26 26 24 27 22 106 13 116 12 29 7 105 29 6 25 11 1
Une propriété intéressante de l'opérateur ⊕ est qu'il est réversible:
si A⊕B = C, alors A⊕C = B et B⊕C = A.
Ce n'est pas le cas des opérateurs logiques et (and) et ou bits à bits.
On peut facilement contrôler que 84⊕78 = 26, mais aussi que 84 @ 26 = 78 et 78 ⊕ 26 = 84.
Par conséquent, le message chiffré ci-dessus peut être déchiffré en réexécutant
l'opération ⊕ nombre à nombre avec les entiers formant la clé étendue
« NSINSINSINSINSINSINSINSINS ».
De plus, l'opérateur ⊕ est l'une des
opérations de base implémentée par le matériel dans l'unité arithmétique et
logique du microprocesseur.
Ces caractéristiques font que l'opérateur ⊕ est une brique de base couramment utilisée dans les algorithmes de chiffrement modernes (même si, utilisé naïvement comme nous l'avons fait ci-dessus, il n'apporte pas une grande sécurité).
Attention cependant:
si la méthode de chiffrement est connue, alors une clé trop courte (comme celle choisie ici) peut compromettre la sécurité de la communication.
Parmi les algorithmes de chiffrement symétriques les plus utilisés, on peut citer AES (pour l'anglais Advanced Encryption Standard, standard de
chiffrement avancé) et ChaCha20.
Bien que très complexes, ces deux algorithmes reposent sur des principes similaires au chiffrement XOR décrit plus
haut:
- une clé initiale est étendue (mais pas aussi naïvement qu'en la répétant);
- la clé et le message sont mélangés (en utilisant entre autres des opérations ⊕), de façon réversible.
En plus d'être sûrs (il est excessivement difficile, sans connaître la clé, de décrypter un message), ils sont très efficaces et permettent de chiffrer de longs messages en temps réel.
Par exemple, ils permettent de chiffrer les données contenues dans un fichier avant de les écrire sur un disque dur, où
de chiffrer des communications audio ou vidéo en temps réel sans impact perceptible sur les performances du système.
Mettre le résultat ici.
"}],[{"text":"Application:
L'INFORMATIQUE C'EST SUPER
NSINSINSINSINSINSINSINSINS
Réaliser le codage en XOR de la lettre F du mot informatique.
Mettre le résultat ici (code et figure).
Termes liés à la représentation de l'information
Coder : représenter de l'information par un ensemble de signes prédéfinis. On utilise parfois le verbe encoder.
Décoder : interpréter un ensemble de signes pour extraire l'information qu'ils représentent.
Chiffrer : rendre une suite de symboles incompréhensible au moyen d'une clé de chiffrement.
Déchiffrer/décrypter : retrouver la suite de symboles originale à partir du message chiffré.
On utilise le terme déchiffrer lorsque l'on utilise une clé de déchiffrement pour récupérer le texte initial et le
terme décrypter lorsque l'on arrive à déterminer le message original sans utiliser la clé.
Coder et décoder s'utilisent lorsqu'il n'y à pas de secret, Par exemple, on parle de « codage en complément à deux » des entiers. C'est juste une façon de représenter les entiers positifs ou négatifs par une suite de bits.
N'importe qui peut décoder la suite de bits pour déterminer l'entier.
Le terme « coder » (qui est un anglicisme, to code) est aussi utilisé de façon informelle comme synonyme de « programmer » comme dans la phrase
« j'ai codé cette application ».
L'anglicisme « crypter » est à proscrire;
on utilisera « chiffrer ».
Mettre le résultat ici (code et figure).
Cryptanalyse
La cryptanalyse est un ensemble de techniques utilisées pour décrypter un texte, c'est-à-dire retrouver le texte en clair à partir du texte chiffré sans posséder la clé de déchifirement.
Une telle tentative de décryptage s'appelle une attaque sur le texte chiffré.
Il existe diverses techniques, très complexes.
Par exemple, si on dispose d'un programme permettant de chiffrer un texte en utilisant une clé, on peut essayer de chiffrer plusieurs messages choisis, en faisant varier les messages et la clé pour voir comment le résultat chiffré se
comporte.
Les attaques statistiques, quant à elles, tentent de déterminer le contenu du message en collectant des statistiques (fréquences, nombre ou densité de certaines suites d'octets) dans le message chiffré.
Une autre technique, si on dispose de la fonction de déchiffrement mais pas de la
clé, consiste à exécuter une attaque par force brute, en énumérant et en essayant toutes les clés possibles.
Si la clé de chiffrement est trop courte, alors ce type d'attaque basique à de fortes chances de réussir.
Les attaques par canal auxiliaire tentent de déterminer des informations sur l'algorithme de chiffrement, la clé ou le message en mesurant des phénomènes indirectement liés au processus de chiffrement.
Par exemple, en mesurant précisément la température de certaines zones du microprocesseur pendant le chiffrement, certains attaquants réussissent à déterminer quelle partie de l'unité arithmétique et logique est utilisée et donc quelles opérations sont utilisées et avec quelle fréquence (multiplications, ou exclusif, additions, etc.).
En mesurant les temps de chiffrement pour un fichier de taille fixe, un attaquant peut parfois déterminer la taille de la clé initiale, avant qu'elle ne soit étendue.
En combinant ces techniques, d'autres informations plus importantes encore peuvent être déterminées, comme le nombre de bits à « 1 » dans la clé.
À l'inverse, le rôle des concepteurs de méthodes de chiffrement est de les rendre résistantes à de telles attaques.
Mettre le résultat ici (code et figure).
Malgré les nombreux avantages du chiffrement symétrique, ce dernier possède un défaut important.
En effet, si deux personnes veulent établir un canal de communication sûr en utilisant une méthode de chiffrement symétrique, les deux personnes doivent d'abord se mettre d'accord sur la clé à
utiliser (et évidemment sur l'algorithme lui-même).
Or, les deux participants sont justement dans la situation où il ne peuvent pas encore communiquer de façon sûre.
Ils vont donc avoir un problème pour se mettre d'accord sur la clé:
- soit ils échangent la clé par un moyen de communication non sûr (par e-mail, par courrier, etc.) mais dans ce cas, un attaquant pourrait alors s'emparer de la clé et compromettre la sûreté des futures communications chiffrées avec cette clé;
- soit ils échangent la clé par un moyen « non pratique », par exemple en stockant une clé générée sur un support de stockage et en se rencontrant physiquement pour se donner la clé de chiffrement.
Pour résoudre ce problème, diverses techniques ont été développées dès les
années 1970, d'abord de manière privée, en particulier par les services secrets
britanniques et américains, puis dans la recherche académique publique.
Ces techniques reposent sur la cryptographie asymétrique encore appelée cryptographie à clé publique.
Nous présentons ici trois méthodes de cryptographie à clé publique, par ordre chronologique de leur découverte.
Nous nous limitons à une description de haut niveau sont hors programme.
Mettre le résultat ici (code et figure).
Puzzles de Merkle
Les puzzles de Merkle sont l'un des premiers exemples de méthode cryptographique à clé publique.
Ils ont été proposés en 1974 par le cryptologue américain Ralphe C. Merkle (1952-).
Alice et Basile souhaitent se mettre d'accord sur une clé secrète, c'est-à-dire une clé de chiffrement pour un algorithme symétrique.
Ils n'ont à leur disposition qu'un canal de communication non sûr qui peut être espionné à tout moment par Ève (diminutif de l'anglais eavesdropper, l'oreille indiscrète ou l'espion).
Alice et Basile procèdent en trois étapes.
Étape 1 : Alice génère un très grand nombre N (par exemple 100 000) de
messages de la forme:
identifiant : i, clé : k
où i et k sont générés aléatoirement.
Par exemple, Alice génère un fichier de
100 000 lignes contenant:
...
identifiant : 129878, clé : abAZda9h!snasjda
identifiant : 821012, clé : sladl)i32#QSdsal
identifiant : 321091, clé : 9Sakns281a154031
...
Étape 2 : Alice va ensuite chiffrer chaque ligne avec un algorithme de chiffrement symétrique et une clé de faible longueur différente pour chaque
ligne.
Le but est que chaque ligne soit susceptible d'être décryptée avec une attaque par force brute, par exemple en 10 secondes de calcul.
Pour l'exemple, nous utilisons la méthode par ou exclusif de la section précédente
avec des clés formées de quatre lettres majuscules.
On obtient un fichier:
...
40 62 324353 51 35 44 32 52 49 101 128 122 116 119 120 105 114 125 109 122 88 41 130 243 101 127...
56 3249 59 37 45 50 60 48 42 32 117 107 100 108 103 96 116 101 103 125 100 5557 146237116111...
35 385447 62 4353 40 434439 97 112 98 96 115 123 114 106 112 102 98 4845 137235115128...
...
Étape 3 : Alice envoie le fichier contenant les lignes chiffrées à Basile.
Naturellement, Eve peut intercepter ce fichier car il est envoyé par un canal non sécurisé.
Basile choisit au hasard une ligne du fichier, par exemple
56 32 49 59 37 45 50 60 48 42 32 117 107 100 108 103 96 116 101 103 125 1005557 146 237 116111...
Il énumère toutes les clés possibles de petite taille pour trouver celle qui correspond.
Il arrive à déchiffrer la ligne
identifiant : 821012, clé : sladlj132#QSdsal
grâce à la clé « QDTU ».
Basile renvoie alors à Alice le message en clair « 821012 ».
Eve peut aussi intercepter ce message mais ne peut a priori rien en faire.
Étape 4 : sur réception du message de Basile, Alice regarde dans son fichier
en clair la ligne contenant « identifiant : 821012 ».
Ils peuvent tous les deux utiliser maintenant la clé « s1adl1j132#QSdsal » pour communiquer.
Le point crucial ici est qu'Eve ne peut pas deviner quelle ligne a été choisie par Basile.
Elle n'a donc pas d'autre choix que d'essayer d'attaquer en force brute les 100000 lignes du fichier, et tester chacune de ces lignes déchiffrées pour tenter de décoder la communication entre Basile et Alice.
Si forcer une ligne prend une seconde, alors Eve mettra au pire 1000 000 secondes et en moyenne 500 000 secondes pour trouver la bonne clé (soit un peu moins 6 jours).
Pendant ces six jours, Alice et Basile disposent d'un canal sûr, qu'ils peuvent utiliser pour échanger des informations.
Cette technique a été l'une des premières proposées et repose sur l'asymétrie suivante:
choisir et attaquer une ligne est une opération réaliste pour Basile, mais déchiffrer toutes les lignes est coûteux pour Eve.
Ici, si découvrir une ligne coûte M secondes et qu'il y a N lignes, le coût moyen pour Eve est de (MxN)/2 secondes.
Bien que novatrice pour l'époque, cette technique n'apporte pas de nos jours des garanties suffisantes.
Mais elle a été une source d'inspiration directe pour la seconde méthode que nous présentons, le protocole d'échange de clés Diffie-Hellman.
Mettre le résultat ici (code et figure).
Méthode de Diffie-Hellman
Le protocole d'échange de clés de Diffie-Hellman est une autre méthode permettant à deux participants de convenir d'une clé symétrique partagée en utilisant un canal de communication non sûr.
Ce protocole a été proposé en 1976 par Bailey W. Diffie (1944—) et Martin Hellman (1945-), deux eryptologues américains.
Il repose sur certaines fonctions mathématiques dont nous décrivons ici les caractéristiques sans rentrer dans les détails.
Supposons que nous possédions une fonction mathématique M (pour « mélange ») prenant en arguments deux entiers et possédant les propriétés suivantes:
- La fonction M est connue (on connaît sa formule où l'algorithme qui permet de la calculer).
- Si on connaît M(x,y) et x alors il est « difficile » de retrouver y. Par difficile, on souhaite que la seule façon dont on dispose pour trouver un y tel que M(x,y) ait une valeur donnée est d'essayer tous les entiers y possibles.
- Pour tous entiers x, y et z, on a M(M(x,y),z) = M(M(x,z),y).
Une analogie couramment utilisée est celle des pots de peintures.
Supposons que l'on ait à notre disposition un très grand nombre de couleurs de peintures différentes.
Les entiers x, y et z correspondent à trois couleurs différentes, par exemple :
x est un certain jaune bien particulier,
y un bleu
et z un rouge.
La fonction M prend 10cl (centilitre) de deux couleurs et les mélange (pour obtenir 20cl de peinture).
Notre fonction M possède bien les trois propriétés ci-dessus.
Nous connaissons M et tout un chacun (muni d'un verre doseur) peut la reproduire (propriété 1}.
Étant données deux couleurs (par exemple
jaune et bleu), si on les mélange on obtient 20 cl d'un vert bien particulier.
Il semble a priori impossible, en ayant à notre disposition le vert et la référence
exacte du jaune, de deviner quel bleu a été utilisé, car pour de la peinture il n'existe pas d'opération de «soustraction» qui permettrait de retirer le jaune du vert (propriété 2).
Enfin, si on mélange d'abord Je jaune et le bleu, puis le rouge on obtient au final 30 cl d'un certain marron.
On obtient 30 el du même marron si on mélange d'abord le jaune et le rouge, puis qu'on ajoute le bleu (propriété 3).
Une remarque importante est que, même si on dispose d'un mélange vert (jaune et bleu) et orange (jaune et rouge), alors
si on réunit ces deux mélange on btiendra 40 cl d'un marron différent (car la proportion de jaune est plus importante).
La figure ci-dessous décrit le protocole en utilisant l'analogie des couleurs.
![](\"https://sciencesappliquees.com/images/nsi/protocolechiffre.svg\")
Figure 1 — Le protocole d'échange de clés de Diffie-Hellman.
Les étapes permettant le partage de clés sont les suivantes:
Étape 1: Alice et Basile se mettent avant tout d'accord sur une couleur de base commune. Cette couleur est considérée comme « publique ». En cffet, Alice et Basile doivent pour l'instant communiquer via un canal non sécurisé.
On doit donc faire l'hypothèse qu'un attaquant peut avoir connaissance du contenu des communications.
Étape 2: Alice et Basile choisissent ensuite chacun une couleur qu'ils gardent secrète. Une fois cette couleur choisie, ils la mélangent à la couleur publique pour obtenir chacun un mélange dont il est impossible d'extraire la couleur secrète.
Étape 3: Ils peuvent ensuite chacun s'envoyer leur mélange respectif. Ici, un attaquant pourrait connaître les mélanges, mais grâce aux propriétés de la fonction de mélange M, il ne peut pas découvrir la couleur secrète.
Étape 4: Alice et Basile ajoutent au mélange reçu leur couleur secrète, Ils disposent donc tous les deux d'un mélange des trois couleurs dans les bonnes proportions.
Ils peuvent utiliser ce mélange comme clé.
Le protocole d'échange de clés de Diffie-Hellman résout de façon élégante le problème d'échange de clé posé par l'utilisation d'un algorithme de chiffrement symétrique.
L'utilisation de ce protocole laisse toutefois une dernière faiblesse:
il ne permet pas l'authentification des participants,
i.e., Alice n'a pas la garantie que la personne avec qui elle communique de façon sûre est bien Basile.
La troisième méthode de crypographie asymétrique que nous présentons, RSA, permet de résoudre ce problème.
Mettre le résultat ici (code et figure).
Le système RSA
Le système RSA est un système de chiffrement asymétrique basé sur des paires de clés publiques et privées.
Son nom est formé des initiales de ces trois inventeurs : Ron Rivest (1947), cryptologue américain, Adi Shamir (1952-), cryptologue israélien, et Len Adleman (1945--), cryptologue américain.
Tout comme le protocole de Difie-Hellman, ce système repose sur des théorèmes mathématiques complexes, dont le détail va au-delà du programme de terminale.
Ce système se prête également moins bien à des analogies simples, telle que celle des couleurs.
Nous n'en détaillons donc que les grands principes et nous nous concentrons sur son utilisation pour l'authentification des participants à une communication en réseau.
Nous abordons dans un premier temps la partie chiffrement.
Le système RSA consiste en la mise en place d'une paire de clé publique et privée pour chaque participant.
Nous notons KpubAlice, la clé publique d'Alice et KprivAlice sa clé privée.
La notation K__Alice(m) signifie, «chiffrer m avec la clé K (publique ou privée) d'Alice ».
La manière exacte de créer ces clés est complexe.
La seule chose à retenir est que les deux clés sont liées.
Étant donné un message m, on à:
Kpub_Alice ( Kpriv_Alice(m)) = Kpriv_Alice ( Kpub_Alice(m)) = m
ce qui signifie que si on chiffre le message m d'abord avec la clé privée puis
qu'on chiffre le résultat avec la clé publique, ou dans l'autre ordre, on obtient le message initial.
En d'autres termes, l'une des deux clés permet de défaire le chiffrement effectué par l'autre clé.
Les propriétés mathématiques mises en jeux font aussi qu'il est
- impossible, en connaissant Kpub_Alice, de deviner Kpriv_Alice;
- impossible, en connaissant uniquement Kpub_Alice(m) ou Kpriv_Alice(m), de deviner m.
Une fois ces propriétés établies, si Basile souhaite envoyer un message secret
à Alice, les deux procèdent comme suit:
- Alice diffuse sa clé publique Kpub_Alice. Par exemple, elle la met sur sa page web, elle l'envoie par e-mail, etc. Cette clé peut être connue de tous. La clé privée est gardée secrète par Alice.
- Basile chiffre son message m en effectuant Kpub_Alice(m) et l'envoie à Alice.
- Alice applique sa clé privée au message chiffré KprivAlice(KpubAlice(m)) et obtient ainsi le message en clair.
Comme on le voit, le système RSA permet de chiffrer des messages sans s'être mis d'accord sur une clé de chiffrement symétrique commune.
Ce système possède cependant un inconvénient de taille:
le chiffrement et le déchiffrement nécessitent des calculs très coûteux.
Cette complexité fait qu'il n'est pas possible d'utiliser RSA pour chiffrer directement des gros volumes de données ou des flux de communication (par exemple une visioconférence avec envoi de vidéo et de son).
Ce problème peut être réglé en remarquant qu'on peut utiliser RSA dans le même but que le protocole d'échange de clé de Difñc-Hellman.
Si Basile veut échanger des gros volumes de données de façon sûre avec Alice, il peut d'abord choisir une clé pour un algorithme de chiffrement symétrique.
Une telle clé est un fichier de quelques milliers d'octets. Il peut ensuite envoyer cette clé à Alice, de manière sûre, en utilisant RSA.
Une fois la clé symétrique reçue, un algorithme de chiffrement symétrique efficace (tel que ChaCha20 ou AES) peut être utilisé.
Un autre avantage de RSA, qui a fait sa popularité, est la possibilité de l'utiliser comme système d'authentification.
Mettre le résultat ici (code et figure).
Attaque de l'homme du milieu
Comme nous l'avons vu, le chiffrement des communications permet de se protéger contre l'espionnage des communications, c'est-à-dire l'observation passive par un tiers des messages envoyés entre deux participants.
Considérons maintenant le scénario suivant.
Supposons qu'Alice soit cliente de l'établissement bancaire BasileBanque.
Les communications entre Alice et BasileBanque étant confidentielles, elles doivent évidemment être chiffrécs, mais cela n'est pas suffisant.
Marion (la malveillante) peut procéder à l'attaque suivante.
Elle envoie un e-mail au format HTML à Alice, lui demandant de se connecter d'urgence sur le site de sa banque.
Le contenu d'un tel e-mail pourrait être:
<htmi>
<body>
Veuillez vous connecter d'urgence au site
<a href=\"http://marion.com\">BasileBanque.com</a>.
</body>
</htnl>
Lancer le programme et ce dernier s'affichera à droite.
Si Alice n'est pas méfiante, et que Marion utilise en plus d'autres techniques (comme de reproduire exactement la page d'accueil dn site BasileBanque. com), alors elle ne se rendra pas compte qu'elle est connectée au mauvais site.
Marion pourra donc recevoir tous les messages envoyés par Âlice.
Elle pourra aussi les retransmettre au véritable site BasileBanque.com, en se faisant passer pour Alice.
Marion sera donc dans une position d'intermédiaire entre Alice et Basile.
Elle pourra retransmettre passivement les requêtes d'Alice à BasileBanque, ou les modifier avant de les retransmettre (par exemple changer le montant ct le destinataire d'un virement bancaire), ce que l'on peut illustrer par le schéma suivant:
![](\"https://sciencesappliquees.com/images/nsi/reseauhttps.png\")
Ici, le chiffrement n'est d'aucune aide.
En effet, même si Alice établit un canal sûr entre elle et Marion, et que Marion en établit un entre elle-même et BasileBanque, l'attaque peut quand même avoir lieu.
On appelle cela une attaque de l'homme du milieu (ou man in the midle attack en anglais, souvent abrégé en MITM).
La faille fondamentale permettant cette attaque est l'absence d'authentification.
Ici, le serveur de Marion, qui imite le comportement du serveur de BasileBanque, n'a pas eu à prouver qu'il était bien une machine appartement à BasileBanque.
Nous allons maintenant voir comment le système RSA peut être utilisé pour authentifier les communications.
Mettre le résultat ici (code et figure).
Certificats et tiers de confiance
Comme on l'a vu, afin de sécuriser entièrement les communications entre deux participants, il faut non seulement les chiffrer, mais aussi que chaque participant puisse s'assurer de l'identité de son correspondant.
Avant de rentrer dans les détails de l'authentification des communications en réseau, nous allons faire une analogie avec l'authentification des personnes en France.
L'État délivre aux citoyens français (qui font les démarches) une carte nationale d'identité.
Si un bureau de poste souhaite authentifier une personne pour lui permettre de retirer un colis, elle peut vérifier la carte d'identité de la personne.
La carte d'identité n'est qu'un bout de carton plastifié et ne permet donc pas à elle seule de prouver l'identité d'une personne.
Le système fonctionne parce que le bureau de poste fait confiance à l'État qui a fait les vérifications nécessaires pour s'assurer de l'identité de la personne avant de lui délivrer la carte.
Les communications en réseau sur Internet sont authentifiées de la même façon.
L'entité qui veut prouver son identité présente un certificat.
Ce dernier doit être délivré par une autre entité. en laauelle les deux participants ont confiance, que l'on appelle un tiers de confiance.
Si Alice, qui souhaite correspondre avec BasileBanque, veut s'assurer que c'est bien Basile qui est le propriétaire du site, elle devra lui demander un certificat.
Ce dernier sera délivré par un tiers de confiance, Théo (le tiers de confiance).
Évidemment, dans le cadre de communications en réseau, le certificat doit être lui aussi numérique.
Ces certificats numériques sont créés à partir des clés RSA publiques et privées des participants.
Étape 1 : Basic va voir Théo. Théo vérifie que Basile est bien le propriétaire du site BasileBanque.com.
Il peut par exemple constater que Basile
peut administrer le site, rajouter des pages, ou qu'il peut présenter des documents légaux (preuve d'achat du nom de domaine par exemple).
Une fois ces vérifications faites, Théo utilise sa clé privée KpubBasile pour chiffrer la clé publique de Basile:
s = KprivThéo(KpubBasile)
Un tel fichier s s'appelle un certificat.
Dans ce cas particulier, on dit que Théo signe la clé publique de KpubBasile avec sa clé privée.
Étape 2 : Alice veut se connecter à BasileBanque.com. Lors de la connexion, le site lui fournit la clé publique de Basile, KpubBasile ainsi que le certificat s.
Étape 3 : Alice récupère alors la clé publique de Théo, en qui elle a confiance.
Elle calcule
KpubThéo(s) = KpubThéo(KprivThéo(KpubBasile))) = KpubBasile
Alice peut alors comparer la clé publique que Basile lui à fournie et celle résultant du déchiffrement de la signature.
Si les deux sont les mêmes, Alice a la garantie que Basile est bien passé voir Théo et que ce dernier a bien fait toutes les vérifications nécessaires.
Étape 4 : Alice ayant authentifié BasileBanque.com comme étant bien le site détenu par Basile, elle peut initier avec lui une communication sécurisée, par exemple en utilisant la clé publique pour chiffrer une clé symétrique ou en utilisant Diffie-Hellman pour se mettre d'accord sur une clé.
Mettre le résultat ici (code et figure).
Nous sommes maintenant équipés pour expliquer le fonctionnement du protocole HTTPS (Hyper Text Transfer Protocole Secure, protocole de transfert de documents hypertexte sécurisé).
Bien que ce dernier repose sur les concepts cryptographiques que nous avons présentés, d'autres considérations
ont été prises en compte lors de sa conception:
- compatibilité avec HTTP: le but n'est pas de recréer un nouveau protocole, mais juste de rendre HTTP plus sûr;
- modularité et compatibilité future: les systèmes cryptographiques présentés reposent sur le fait que certaines opérations demandent tellement de temps de calcul à l'attaquant qu'elles sont incassables en pratique. Cependant, les capacités de calculs des ordinateurs augmentant avec les progrès technologiques, il faut pouvoir changer la difficulté des problèmes à résoudre (par exemple augmenter la taille des clés ou changer les algorithmes de chiffrement) sans remettre en cause tout le protocole;
- performances : un site web populaire devra effectuer plusieurs milliers d'opérations de chiffrement et déchiffrement par seconde. Comme on l'a vu, les méthodes symétriques sont peu coûteuses mais demandent de pouvoir échanger une clé de façon sûre.
Les méthodes asymétriques sont sûres mais très coûteuses en temps de calcul, il faut donc limiter l'usage de ces dernières au strict minimum.
Mettre le résultat ici (code et figure).
Autorités de certifications et format X.509
Une autorité de certification (ou AC) est une entité habilitée à délivrer des certificats.
Une AC est un tiers de confiance. Parmi les différentes AC on retrouve:
- des entreprises spécialisées;
- des associations à but non lucratif (comme l'initiative Let's Encrypt, libre et gratuite);
- des états.
Comme nous l'avons vu, le rôle des tiers de confiance est d'attester, au moyen d'un certificat numérique, qu'une entité (entreprise, personne, etc.) est bien qui elle prétend être.
Les autorités de certifications forment un «club» très fermé.
En effet, les systèmes d'exploitation et les navigateurs web, en particulier, possèdent les clés publiques des AC sous forme de fichiers.
Elles sont en nombre relativement restreint.
Par exemple, au début 2020, la fondation
Mozilla, qui produit le navigateur web Firefox, reconnaît environ un peu plus d'une centaine d'autorités de certification.
Chacune d'elles répond à des critères très stricts, vérifiés par des audits réguliers dont les résultats sont publics.
Les société Microsoft, Apple et Google (qui développent des systèmes d'exploitation et des navigateurs) ont elles aussi leurs critères (qui ne sont pas forcément les mêmes que ceux de la fondation Mozilla) pour accepter les autorités de certification.
Les systèmes d'exploitation et les navigateurs web possèdent une copie de chacune de leurs clés publiques.
Les AC émettent des certificats. Ces derniers fonctionnent sur le principe expliqué précédemment, avec quelques considérations techniques supplémentaires.
Le format standard de certificat est le format X.509. Ce dernier est un format de fichier binaire, contenant entre autres:
- l'identifiant de l'AC qui signe le certificat;
- l'identifiant de l'entité certifiée;
- la date de validité du certificat;
- la clé publique de l'entité certifiée;
- l'algorithme utilisé pour la signature du certificat;
- la signature du certificat par l'AC.
Sous Unix, la commande openssl permet d'obtenir des informations sur un certificat.
Par exemple, pour voir le certificat du site sciencesappliquees.com, il faut aller sur le vps 217.182.207.90 à l'aide du logiciel Putty et lancer les commandes suivantes:
- Pour télécharger le certificat
$ openssl s_client -connect sciencesappliquees.com:443 | tee logfile
- Pour afficher son contenu
$ openssl x509 -inform PEM -in logfile -text -out certdata
Ici, le paramètre x509 indique que l'on travaille avec un certificat au format X.509, le paramètre -in permet de donner le fichier de certificat, ici logfile et le paramètre -text indique que l'on souhaite afficher le contenu du certificat de façon lisible.
Copier la sortie de la commande ci-dessous:
Certificate de sciencesappliquees.com:
Mettre le résultat ici (code et figure).
L'AC ayant produit ce certificat est « Let's Encrypt ». Le certificat n'est
valide que sur la période du 4 mai au 2 août 2020, et devra être renouvelé après.
Le site certifié est sciencesappliquees.com.
La clé publique du site, c'est-à-dire celle qui sera utilisée par le navigateur web pour chiffrer la communication initiale, fait 2048 bits, et est donnée par les deux champs Modulus et Exponent.
Enfin, l'algorithme de signature est sha256WithRSAEncryption.
Cet algrithme est une variation de la signature RSA que nous avons présentée dans la section précédente.
Ici, plutôt que de signer (i.e., de chiffrer) toutes la clés publiques du site, PAC a d'abord calculé une somme de contrôle avec l'algorithme de hachage SHA256.
Ce dernier produit un entier de 256 bits en « mélangeant » les différents octets du certificat (tous les champs présentés, exceptés Signature Algorithm: et la signature).
Ce certificat (incluant le nom de l'entité, les dates de validité et la clé publique) est ensuite signé (i.e., chiffré) avec la clé privée de l'autorité « Let's Encrypt ».
Lorsque le client, Alice, souhaite vérifier que le site
https://sciencesappliquees.com est authentifié, il lui suffit de retirer les deux derniers champs du certificat, de calculer la somme de contrôle avec l'algorithme SHA256, et de la chiffrer avec la clé publique de l'autorité « Let's Encrypt ».
Cette dernière étant une autorité reconnue, les navigateurs web possèdent
une copie de sa clé publique, afin de procéder aux vérifications.
Avant d'illustrer comment les certificats sont utilisés dans le cadre du protocole HTTPS, nous terminons notre présentation des autorités de certifications en citant les niveaux de certifications. En effet, il existe trois niveaux de certification possibles:
DV (pour l'anglais domain validated, soit validation du domaine), c'est le niveau le plus basique. l'AC a juste vérifié que la personne qui a demandé le certificat est bien la personne qui contrôle le nom de domaine certifié. Ce contrôle peut être fait à distance, en demandant à l'administrateur de déposer à un certaine URL un fichier généré par l'AC (par exemple
https://sciencesappliquees.com/fichier).
OV (pour l'anglais organisation validated, validation de l'organisation), est le niveau intermédiaire. Des vérifications sont faites sur l'existence légale de la personne morale ou physique correspondant à l'entité certifiée.
L'AC effectue des vérifications manuelles auprès de l'entité (généralement une entreprise) qui demande la certification. Par exemple, l'AC passe un appel téléphonique au siège social de l'entreprise pour s'assurer de son existence, en plus des vérifications faites au niveau DV.
EV (pour l'anglais extended validated, soit validation étendue), est le niveau le plus haut de certification. L'AC vérifie les documents légaux fournis
par l'entreprise à certifier et recoupe ces vérifications avec les registres
publics (registres des entreprises par exemple), en plus des vérifications
faites au niveau OV.
Détails du protocole HTTPS
Le protocole HTTPS qui permet d'établir des communications sécurisées entre un client et un serveur web est en fait simplement le protocole HTTP, auquel une couche de cryptographie a été ajoutée.
En effet, HTTPS est simplement la réunion de deux protocoles existants, HTTP, pour l'interaction avec le serveur web et TLS (Transport Layer Security, sécurité
de la couche de transport).
Rappelons-nous le fonctionnement du protocole HTTP. Lorsqu'un client (par exemple un navigateur web) souhaite afficher la page https://www.sciencesappliquees.com/index.php, il initialise une connexion TCP vers l'adresse IP de la machine www.sciencesappliquees.com sur le port 80.
Une fois la connexion établie, le navigateur envoie une requête HTTP, c'est-à-dire une suite d'octets de la forme GET /index.html HTTP/1.1 Host: www.sciencesappliquees.com
Le protocole TLS ajoute simplement une phase permettant l'authentification du serveur et la mise en place sécurisée d'une clé de chiffrement symétrique, appelée clé de session.
Une fois cette clé déterminée et connue du client et du serveur, le client et le serveur échangent des requêtes et réponses HTTP (la requête GET précédente), mais ces dernières seront chiffrées avant l'envoi et déchiffrées lors de la réception.
L'authentification empêche l'exécution d'attaques de l'homme du milieu, et le chiffrement empêche les routeurs et autres machines intermédiaires de lire le contenu des messages.
La figure 2 décrit la phase de mise en place, appelée « poignée de main TLS » (TLS handshake en anglais).
Cette phase initiale n'étant pas compatible avec le protocole HTTP, un port différent à été choisi pour le protocole HTTPS, à savoir le port 448.
Les étapes de cette poignée de main reprennent chacun des points développés tout au cours de la séquence.
Étape 1 : Le client envoi un message initial (nommé « Hello ») ainsi que des options. En particulier, le client indique les différents algorithmes cryptographiques qu'il peut utiliser, ainsi que d'autres paramètres techniques.
Étape 2 : Le serveur envoie sa réponse, contenant entre autres le certificat X.509 contenant sa clé publique, signée par une autorité de certification.
Étape 3 : Le client vérifie le certificat au moyen de la clé publique de l'AC (qu'il doit posséder). Il procède aussi à d'autres vérifications (comme le fait que le certificat est toujours valide).
Étape 4 : Le client et le serveur conviennent d'une clé de session pour un algorithme symétrique. Ils peuvent soit choisir de chiffrer une clé choisie par le client avec la clé publique du serveur, soit utiliser le protocole d'échange de clé de Diffie-Hellman pour convenir d'une cié de session partagée.``\n
Étape 5 : Le serveur est authentifié par le client, et les deux ont convenu d'une clé de session. Ils peuvent donc échanger de manière sûre des messages du protocole HTTP en les chiffrant.
Tous ces aspects sont observables en inspectant l'icône de « cadenas » se trouvant dans la barre d'adresse des navigateurs web.
![](\"https://sciencesappliquees.com/images/nsi/httpsrequest.jpg\")
Figure 2 — Mise en place d'une connexion HTTPS.
Dans cette figure, on peut voir entre autres détails que la connexion utilise les options
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Serveur
Par exemple, pour le navigateur Firefox, connecté au site https://www.sciencesappliquees.com, on
peut afficher les propriétés de la connexion, comme indiqué à la figure 3.
![](\"https://sciencesappliquees.com/images/nsi/cadenashttps.png\")
Figure 3 — Les propriétés d'une connexion HTTPS.
ce qui signifie qu'elle utilise le protocole TLS (plutôt que son prédécesseur SSL, moins sûr).
Le sigle ECDHE, pour Elliptic Curve Diffie-Hellman Ephemeral, indique que la clé de session est échangée par le protocole de Diffie-Hcliman dans sa variante utilisant les courbes elliptiques comme problème mathématique sous-jacent.
L'authentification est assurée par RSA.
Le chiffrement symétrique est quant à lui assuré par l'algorithme AES128.
********
Certains problèmes peuvent survenir lors de la poignée de main TLS.
Le plus courant est l'utilisation par le serveur d'un certificat non signé ou signé par une entité inconnue.
Un navigateur indique alors un message similaire à celui de la figure 4.
********
La présence de ce message indique que la
communication est chiffrée, mais pas authentifiée.
Le serveur web peut alors appartenir à un utilisateur malveillant effectuant une attaque de l'homme du milieu.
En pratique, ce phénomène se produit aussi lorsque le certificat n'est plus valide, par exemple si l'administrateur du site n'a pas renouvelé son certificat à temps.
En cas d'absence de chiffrement (utilisation du protocole HTTP simple), le navigateur affiche généralement un cadenas rouge ou barré et déconseille la saisie de mot de passe ou autre information.
Figure 4 - Connexion non sûre.
Mettre le résultat ici (code et figure).
La sécurisation des communications sur Internet repose sur l'utilisation de la cryptographie.
Les algorithmes de chiffrement symétrique utilisent la même clé pour chiffrer et déchiffrer des messages.
Certains, comme AES ou ChaCha20, sont considérés comme sûrs et sont efficaces.
Ils supposent cependant que les participants puissent échanger la clé symétrique de façon sûre.
Cela peut être fait en utilisant des techniques à clé publique, comme le protocole d'échange de clé de Diffie-Hellman.
Les algorithmes de chiffrement asymétrique, tels que RSA, reposent sur une paire de clés publique et privée et ne nécessitent pas l'échange d'un secret partagé.
Le système RSA permet en outre d'authentifier les participants, en utilisant un tiers de confiance.
Le protocole HTTPS utilise le protocole TLS pour ajouter au protocole HTTP une phase d'authentification et d'échange de clé de chiffrement.
Il utilise pour cela des certificats envoyés par le serveur web et signés par des autorités de certification.
Une fois le serveur authentifié par le client, ce dernier peut utiliser RSA où Diffie-Hellman pour convenir d'une clé de chiffrement symétrique avec le serveur et entamer une communication chiffrée.
Mettre le résultat ici (code et figure).
Pour chacun des sigles ou noms suivants, le décrire en une phrase sans donner la signification du sigle.
- TLS
- RSA
- Diffe-Hellman
- X.509
- ChaCha20
- HTTPS
- AES
- SSH
Mettre le résultat ici (code et figure).
- TLS est un protocole de communication assurant l’authentification et le chiffrement des messages.
- RSA est un svstème cryrtographiaue à clé publique.
- Diffie-Hellman est un protocole à clé publique, permettant l’échange d’une clé secrète entre deux participants.
- X.509 est un format de fichier permettant de représenter des certificats signés par une autorité de certification.
- ChaCha20 est un algorithme de chiffrement symétrique.
- HTTPS est une version chiffrée et authentifiée du protocole HTTP.
- AES est un algorithme de chiffrement symétrique.
- SSH est à la fois un programme informatique et un protocole de communication sécurisé. Le protocole de connexion impose un échange de clés de chiffrement (RSA) en début de connexion.
Écrire en Python une fonction chiffre_xor(msg, cle) qui prend en arguments deux chaînes d'octets (type bytes) et qui renvoie le chiffrement XOR du message avec la clé, sous forme d'une chaîne d'octets.
On rappelle que l'on peut créer une chaîne d'octets en utilisant le constructeur bytes et en lui donnant en argument une liste d'entiers, chacun compris entre 0 et 255.
Indication : On rappelle que pour un chiffrement XOR, la clé doit être «étendue» de façon à avoir la même taille que le message. Cependant, il n'est pas nécessaire de créer une chaîne intermédiaire contenant des copies répétées de la clé.
On pourra en effet faire une utilisation judicieuse de l'opérateur «%».
L'opérateur XOR en python est «^».
","title":"Exercice","tagtitle":"h1"},{"edit":"Mettre le résultat ici (code et figure).
def chiffre_xor (msg, cle):
res = [msg[i] ^ cle[i%len(cle)] for i in range(len(msg))]
return bytes(res)
m = \"L'INFORMATIQUE C'EST SUPER\".encode()
c = \"NSI\".encode()
s = chiffre_xor(m,c)
print(\"msg chiffré:\",s)
print(\"msg déchiffré:\",chiffre_xor(s,c))
Autre manière:
def chiffre_xor2(msg, cle):
j = 0
res=[]
for c in msg:
res.append(c ^ cle[j])
j+=1
if j==len(cle):
j=0
return bytes(res)
Comme expliqué dans le cours, un chiffrement XOR simple n'apporte pas une grande sécurité.
On va montrer qu'en connaissant quelques informations on peut facilement retrouver la clé si cette dernière est trop courte.
Soit la chaîne d'octets chiffrée:
b'\\x0e6/+y;.< x-(7,,\\x9b\\xf0z48z:646<z*\\x9a\\xf3(64+<{'
On sait que les 4 derniers caractères du message en clair sont \"nse!\".
On sait aussi que la clé fait exactement 3 caractères et que ce sont des lettres majuscules sans accent.
Écrire un programme Python, utilisant la fonction chiffre_xor de l'exercice précédent, qui essaye toutes les combinaisons de clé jusqu'à trouver la bonne.
Mesurer le temps d'exécution.
On pourra utiliser la fonction time.time() du module time pour connaître l'heure courante, en nombre de secondes depuis une date de référence non spécifiée.
age 504 D
Mettre le résultat ici (code et figure).
import time
secret = b'\\x19\\x1fz\\x17\\x1f\\t\\t\\x1b\\x1d\\x1fz\\t\\x1f\\x19\\x08\\x1f\\x0ez\\x1f\\t\\x0ez\\x13\\x14\\x1e\\x1f\\x19\\x12\\x13\\x1c\\x1c\\x08\\x1b\\x18\\x16\\x1f{'
def forceBrute():
cA = ord('A')
cZ1 = ord('Z') +1
for c1 in range(cA, cZ1):
for c2 in range(cA, cZ1):
for c3 in range(cA, cZ1):
cle = bytes([c1, c2, c3])
test = chiffre_xor(secret, cle)
if test.endswith(b\"BLE!\"):
return (cle,test)
t1 = time.time()
res = forceBrute()
t2 = time.time()
if res is None:
print (\"Je n’ai pas trouvé la clé\")
else:
print (\"Clé:\", res[0])
print(\"Message décrypté:\", res[1])
print (\"Temps de calcul:\", t2 - t1, \"secondes\")
Sur une machine relativement récente, énumérer de cette façon toutes les clés entre AAA, AAB, ..., ZZZ prend moins d’une seconde (0,13seconde).
Donc, il faut faire attention aux clés qui sont trop courte.
On se place dans le contexte de la figure 2.
Figure 2 — Mise en place d'une connexion HTTPS.
Le client est un navigateur web classique (par exemple Chrome).
Le serveur web est configuré sur une machine dont le nom de domaine est www.monsite.fr.
Dans chacune des situations suivantes, dire quelle étape de la poignée de main TLS échoue.
Les questions sont indépendantes.
- Le serveur web n'est pas configuré pour supporter le protocole HTTPS et ne sert des pages qu'en HTTP.
- Le fichier contenant le certificat côté serveur est périmé.
- L'utilisateur du navigateur pointe ce dernier vers l(URL http://www.monsite.fr:448.
- L'administrateur du serveur a créé une paire de clé publique et privée, a signé le certificat que le serveur envoie aux clients et effacé les clés.
- Le navigateur commence à afficher la page de garde du site. Le câble connectant le serveur au réseau est coupé.
Mettre le résultat ici (code et figure).
- L'étape 1 échoue immédiatement, le navigateur ne trouve aucun serveur en écoute sur le port 443, la connexion TCP ne peut pas se mettre en place.
- L'étape 3 échoue, le client ne procède pas à la validation du certificat.
- L'étape 2 échoue car le client navigue vers le port HTTPS en HTTP, il n’envoie pas les bons paquets et le serveur ne peut donc pas répondre ou répond un message d'erreur.
- L'étape 3 échoue et le navigateur affiche un message similaire à celui de la figure 4.
En effet, le navigateur ne pourra pas trouver une clé publique d’AC lui permettant de vérifier la signature. - Si la page de garde du site s’affiche, c’est que la requête HTTP récupérant la page a reçu une réponse du serveur. On est après l'étape 5, la connexion TCP est interrompue (car tous les paquets sont perdus).
Aller sur le vps 217.190.207.90 et utiliser les commanded openssl pour déterminer les informations sur le site sciencesappliquees.com.
Donner en particulier sa date d'expiration et le nom de l'AC qui l'a signé.
Mettre le résultat ici (code et figure).
Les commandes openss1 qui permettent d'afficher les information souhaitées sont:
$ openssl s_client -connect sciencesappliquees.com:443 | tee logfile
$ openssl x509 -inform PEM -in logfile -text -out certdata
On rappelle qu'un socket est un objet représentant une connexion TCP vers un hôte et un port donné.
En Python, un client se connectant en TCP à un serveur peut s'écrire comme suit:
import socket
hote = 'www.nsi-terminale.fr'
#Prend en argument un couple nom et port
s = s.create_connection((hote, 80))
Sur un tel objet s, on peut utiliser une méthode s ,read(n) où n est un entier strictement positif.
La méthode renvoie une chaîne d'octets (type bytes) dont 13 taille peut être inférieure ou égale à n.
Une taille de 0 indique que le serveur à fini sa réponse.
La méthode s.write(b) où b est une chaîne
d'octets envoie la chaîne au serveur.
On peut automatiquement rajouter une couche TLS à un programme utilisant une socket en utilisant le module Python ssl.
import socket
import ssl
hote = 'www.nsi-terminale.fr?
ctx = ssl.create default _context()
#Prend en argument un couple nom et port
s = s.create_connection((hote, 443))
ss = ctx.wrap_socket(s, server_hostname=hote)
#On réutilise ss comme une socket ici.
Dans le code ci-dessus, l'objet ss est une socket, peut s'utiliser comme une socket, qui chiffrera automatiquement les messages envoyés et déchiffrera
les messages lus.
En plus des méthodes .read() et .write(), l'objet ss possède une méthode .getpeercert() qui renvoie un dictionnaire décrivant le certificat.
Compléter le code ci-dessus pour qu'il récupère la page de garde du site web https://www.nsi-terminale.fr.
Une fois ce code écrit et testé, changer le paramètre server_hostname pour qu'il indique un hôte différent de celui stocké dans la variable hote.
Expliquez le message d'erreur.
Mettre le résultat ici (code et figure).
import socket
import ssl
hostname = ’www.nsi-terminale.fr?
ctx = ssl.create default _context()
s = socket.create_connection((hostname, 443))
ss = ctx.wrap_socket(s, server_hostname=hote)
print (ss.version())
print(ss.getpeercert())
ss.write(\"GET / HTTP/1.1\\nHost: www.nsi-terminale.fr\\n\\n\" \\
.encode())
buff = ss.read(200)
while len (buff) > 0:
print (buff.decode(’UTF-8?))
buff = ss.read(200)
ss.close()
Si on remplace le paramètre server_hostname, par exemple avec le nom
kernel.org (adresse du site hébergeant le noyau Linux), on obtient
certificate verify failed: Hostname mismatch, certificate
is not valid for ’kernel.org’
qui indique que le certificat récupéré lors de la poignée de main TLS (celui du
site wuw.nsi-terminale.fr) ne correspond pas au site kernel.org (échec
à l'étape 3 de la poignée de main TLS).
On considère le cas d'un site Internet https://www.monsite.fr.
Ce dernier a été mal configuré et le fichier privkey.pem, contenant la clé privée correspondant à la clé publique contenue dans le certificat, est téléchargeable.
Le site choisi d'utiliser RSA pour l'échange de clé de session (et non pas Diffie-Hellman).
Indiquer ce que peut faire un utilisateur
malveillant en possession de cette clé privée.
Mettre le résultat ici (code et figure).
L'utilisateur possédant la clé privée peut tenter d’intercepter les paquets quand un client effectue la poignée de main TLS.
Lorsque le client envoie la clé de session chiffrée avec la clé publique du
serveur, le client peut déchiffrer le message, récupérer la clé de session et
déchiffrer ainsi les messages suivants.
Nous avons la citation suivante:
\"Comme la Hongrie, le monde informatique a une langue qui lui est propre. Mais il y a une différence. Si vous restez assez longtemps avec des Hongrois, vous finirez bien par comprendre de quoi ils parlent.\"
De la Chroniques déjantées d’internet - Dave Barry.
Faire de même pour le déchiffrage.
Mettre le résultat ici (code et figure).
Nous avons la citation suivante:
\"Cookie : Anciennement petit gâteau sucré, qu’on acceptait avec plaisir. Aujourd’hui : petit fichier informatique drôlement salé, qu’il faut refuser avec véhémence.\"
De Luc Fayard / Dictionnaire impertinent des branchés - Luc Fayard
Ecrire un programme Python qui la chiffre en RSA (Cryptographie asymétrique) avec une clé de chiffrement de 2048 Bytes.
Faire de même pour le déchiffrage.
Mettre le résultat ici (code et figure).