cours crypto
This commit is contained in:
Francois Lesueur
parent
92f973ad7c
commit
db522a0e1e
120
cours-crypto.md
120
cours-crypto.md
@ -1,54 +1,102 @@
|
||||
# Cours Cryptographie (2h)
|
||||
CM Cryptographie et sécurité des communications - Notes de cours
|
||||
================================================================
|
||||
|
||||
À la rencontre d'Alice, Bob et Ernest
|
||||
=====================================
|
||||
|
||||
Comment permettre à Alice et Bob de communiquer de manière *sûre* sur un canal *non sûr* ? Notion centrale en sécurité/crypto : le **modèle d'attaque**.
|
||||
|
||||
* Alice et Bob veulent communiquer, Ernest écoute (attaque passive) ou altère (attaque active) les échanges
|
||||
* Le medium non sûr :
|
||||
* Un messager qui peut se faire capturer
|
||||
* Un réseau de câbles téléphoniques
|
||||
* Internet (routage multi-saut multi-acteurs, écoute possible sur la route + par des attaquants qui arriveraient à dévier)
|
||||
* Exemples de positions *MitM - Man in the Middle* :
|
||||
* La DSI de l'UBS sur eduroam
|
||||
* Orange sur les livebox
|
||||
* Lumen sur du transatlantique
|
||||
* Autre transitaire fournissant le service au serveur visé
|
||||
* Attaquant sur le réseau local (attention aux LP Cyber qui jouent par là...)
|
||||
* ...
|
||||
* L'objectif de la crypto : communiquer de manière *sûre* sur un medium *non sûr*
|
||||
* Aujourd'hui, (très) peu de services réseau sans crypto
|
||||
|
||||
|
||||
Mode d'emploi
|
||||
=============
|
||||
Communiquer de manière sûre ?
|
||||
=============================
|
||||
|
||||
Déroulement du cours en "autonomie encadrée" :
|
||||
|
||||
* Vous avez un travail en autonomie décrit dans la suite de ce document. Ce document vous oriente vers des références externes (à lire, évidemment) et tisse les liens entre ces lectures.
|
||||
* Durant tout ce travail, je suis disponible autant pour des éclaircissements que des approfondissements.
|
||||
* Je vous encourage, évidemment, à échanger aussi en petits groupes via le canal de votre choix
|
||||
* Les durées sont données à titre indicatif et seront très variables en fonction de vos questions.
|
||||
|
||||
Ce que nous allons voir :
|
||||
|
||||
* Le fonctionnement de la crypto, les classes de crypto, les clés, ... comme outil de base
|
||||
* Les infrastructures à clés publiques pour lier la crypto à des identités
|
||||
* Le protocole TLS comme empaquetage de cet ensemble
|
||||
1. **Confidentialité** : chiffrement
|
||||
2. **Intégrité** : signature/scellement
|
||||
3. **Authentification** : preuve de possession de matériel crypto
|
||||
4. **Non-répudiation** : signature
|
||||
|
||||
|
||||
Bases de la crypto (1h)
|
||||
==================
|
||||
La cryptographie moderne
|
||||
========================
|
||||
|
||||
Vous devez lire le cours de [Ghislaine Labouret](https://web.archive.org/web/20170516210655/http://www.hsc.fr/ressources/cours/crypto/crypto.pdf) <!-- http://www.hsc.fr/ressources/cours/crypto/crypto.pdf https://doc.lagout.org/security/Cryptographie%20.%20Algorithmes%20.%20Steganographie/HSC%20-%20Introduction%20a%20la%20cryptographie.pdf --> (jusqu'à la page 27/32). Vous y verrez les notions de cryptographie symétrique (ex AES), asymétrique (ex RSA), hash, chiffrement, signature ainsi que le problème de la distribution des clés. Ce cours est intéressant car bien construit mais assez ancien (2001). Les notions, principes et difficultés n'ont pas changé depuis, les algorithmes et tailles de clés si : cela vous donne une idée de l'évolution à attendre pendant les 10 prochaines années (hors découverte majeure).
|
||||
La cryptographie asymétrique :
|
||||
|
||||
Côté découvertes, on commence par exemple à s'intéresser à la [cryptographie post-quantique](https://fr.wikipedia.org/wiki/Cryptographie_post-quantique) (contentez-vous de lire l'introduction de l'article) : cette cryptographie post-quantique s'exécute sur des ordinateurs traditionnels mais a l'avantage d'être résistante aux attaques des ordinateurs traditionnels et quantiques (à ne pas confondre avec la crypto quantique, donc, qui s'exécuterait sur un ordinateur quantique). Dans votre carrière, vous devriez probablement voir la systématisation de cette cryptographie post-quantique.
|
||||
* Chaque acteur a une paire de clés publique/privée reliées mathématiquement
|
||||
* Chiffrer = utiliser la clé publique de l'interlocuteur, déchiffrer = utiliser sa propre clé privée (tout le monde peut nous parler, nous seuls pouvons comprendre)
|
||||
* Signer = utiliser sa propre clé privée, vérifier = utiliser la clé publique de l'interlocuteur (nous seuls pouvons signer, tout le monde peut vérifier)
|
||||
* Exemples : RSA, ECDSA
|
||||
|
||||
À vous de chercher quels sont les algorithmes souhaitables aujourd'hui. Pour les tailles de clés, consultez le site [Key Length](http://www.keylength.com/) qui est très pratique.
|
||||
La cryptographie symétrique :
|
||||
|
||||
<!--
|
||||
La suite du travail est de découvrir le fonctionnement de RSA (sans entrer, pour l'instant, dans les fondements mathématiques), par exemple sur [Wikipedia](https://fr.wikipedia.org/wiki/Chiffrement_RSA). Prêtez une attention particulière à la génération des clés, aux mécanismes de chiffrement et déchiffrement.
|
||||
-->
|
||||
* Chaque paire d'acteurs a une clé secrète
|
||||
* Cette clé secrète est utiliser pour chiffrer/déchiffrer et sceller/vérifier
|
||||
* Exemple : AES, HMAC
|
||||
|
||||
Enfin, le programme [Bullrun](https://fr.wikipedia.org/wiki/Bullrun) donne un bon aperçu des forces et faiblesses de la cryptographie moderne : la partie mathématique est plutôt sûre, les attaques se concentrent sur l'usage (standardisation), le déploiement, l'implémentation, etc.
|
||||
Le hachage :
|
||||
|
||||
* Empreinte de taille fixe à sens unique (non inversible)
|
||||
* Hachage crypto doit être robuste aux attaques (collision, pré-images)
|
||||
* Exemples SHA-256, SHA3-512
|
||||
|
||||
Quelle taille de clé ? [KeyLength](https://www.keylength.com/)
|
||||
|
||||
|
||||
Infrastructures à clés publiques (PKI) (1h)
|
||||
=======================================
|
||||
La mise en œuvre
|
||||
================
|
||||
|
||||
Le rôle d'une PKI est de lier une clé publique à une identité (typiquement, à une chaîne de caractères intelligible comme une URL `www.acme.org` ou une adresse mail `brice@acme.org`). L'obtention de clés publiques est un service orthogonal au service de sécurité rendu par la cryptographie (ie, un même service, le mail chiffré et signé par exemple, peut-être rendu avec une approche type CA avec S/MIME ou une approche toile de confiance avec PGP).
|
||||
L'obtention des clés : les PKI - Public Key Infrastructure
|
||||
----------------------------------------------------------
|
||||
|
||||
Vous devez lire la [page anglaise de Wikipedia](https://en.wikipedia.org/wiki/Public_key_infrastructure) sur ce sujet, qui présente différentes formes de PKI (autorités de certifications, toile de confiance, SPKI, blockchain). Attention, la page française n'est pas assez détaillée.<!-- très différente et présente une vision réduites à l'approche CA, c'est uniquement la page anglaise qui fait référence pour ce cours. -->
|
||||
|
||||
Vous devez détailler chacune des différentes formes, avec une attention particulière pour les [CA](https://en.wikipedia.org/wiki/Certificate_authority) et le [Web of trust](https://en.wikipedia.org/wiki/Web_of_trust). La PKI DANE/TLSA est très bien décrite et positionnée dans cet [article](http://www.bortzmeyer.org/6698.html). Vous devez enfin lire les [Criticisms](https://en.wikipedia.org/wiki/Public_key_infrastructure#Criticism) de la page principale (et les détails de PKI security issues with X.509, Breach of Comodo CA, Breach of Diginotar).
|
||||
|
||||
> Pour comprendre DANE/TLSA qui repose sur DNSSEC, vous devrez peut-être vous rafraichir la mémoire sur le fonctionnement et les différents acteurs du système DNS (typiquement, notions de _registry_, _registrar_, gestion d'une zone et mécanisme de résolution récursif). Ces points ont normalement déjà été vus en TC mais vous pouvez par exemple lire [Sebsauvage](http://sebsauvage.net/comprendre/dns/) jusque "Dans ce cas, ils sont à la fois registry et registrar.", [Bortzmeyer](http://www.bortzmeyer.org/files/cours-dns-cnam-PRINT.pdf) sections "Le protocole DNS" et "Gouvernance" et/ou d'autres ressources équivalentes.
|
||||
* La difficulté majeure côté usage : obtenir la bonne clé. Comment l'obtenir de manière sûre quand le medium est non sûr ?
|
||||
* Le risque : parler chiffré mais pas avec le bon interlocuteur (ie, avec Ernest)
|
||||
* Les PKI sont des moyens d'associer des clés publiques (donc pour crypto asymétrique) à des identifiants (nom de personne, nom DNS, ...)
|
||||
* Quelques modèles :
|
||||
* Centralisé CA (autorités de certification) / PKIX
|
||||
* Distribué PGP
|
||||
* DANE/TLSA dans DNSSEC
|
||||
* Diffus style keybase.io
|
||||
* L'échange direct / uniquement en out-of-band (donc pas vraiment de PKI)
|
||||
* La mise en contact
|
||||
|
||||
|
||||
TLS (15 minutes)
|
||||
===
|
||||
La négociation : les protocoles cryptographiques
|
||||
------------------------------------------------
|
||||
|
||||
Dans le TP, nous allons manipuler une CA pour faire du HTTPS (HTTP sur TLS). TLS permet l'authentification mutuelle, une bonne explication [ici](https://tls.ulfheim.net/)
|
||||
* Pour communiquer, il faut un standard : un protocole
|
||||
* Quelques protocoles cryptographiques : TLS, SSH, S/MIME, PGP, ...
|
||||
* Généralement pour la mise en place d'une communication en crypto hybride :
|
||||
* Échange de clés symétriques en crypto asymétrique
|
||||
* Puis communication *payload* en crypto symétrique
|
||||
* Exemple des suites cryptographiques TLS ("ECDHE-RSA-AES128-GCM-SHA256")
|
||||
|
||||
|
||||
|
||||
Exemple : le modèle HTTPS
|
||||
-------------------------
|
||||
|
||||
* Objectif : un tunnel chiffré entre le client (navigateur) et le serveur
|
||||
* Pour cela il nous faut :
|
||||
* Un protocole : TLS
|
||||
* La (bonne) clé publique du serveur : Certificat
|
||||
* Un certificat = (clé publique, nom) signé par un tiers. Ici :
|
||||
* clé publique = celle du serveur, il a la clé privée qui va avec
|
||||
* nom = nom d'hôte DNS (par exemple www.univ-ubs.fr)
|
||||
* tiers = une autorité de certification (par exemple Let's Encrypt)
|
||||
* => On a bien une association entre un nom et une clé, ici certifiée par un tiers
|
||||
* Le client doit valider la signature de la CA, et ainsi vérifier l'association (clé publique, nom) :
|
||||
* Il lui faut donc vérifier avec la clé publique de la CA
|
||||
* Les clés publiques des CA reconnues par les clients sont pré-installées dans les navigateurs, pas de magie, il faut une *ancre de confiance* dans le logiciel
|
||||
|
||||
Loading…
Reference in New Issue
Block a user