Sécurité et gestion des clefs de chiffrement

Rachid Elazouzi

Ressources

Notes de cours

difficile de vérifier qu'un système fait bien ce qu'on lui demande, impossible de vérifier qu'il ne fait pas ce qu'on ne lui demande pas

le but de la sécurité : la confidentialité, l'intégrité et la disponibilité des données

"je peux mettre mes données dans un serveur sécurisé, et le protocole je suis le seul à la connaître : c'est un avantage pour moi, je ne suis pas la cible des attaques"
"ce qui est intéressant pour vous, ce n'est pas de trouver des solutions, c'est de comprendre le risque"

"tous les jours vous utilisez HTTPS, donc vous utilisez des clés publiques et privées"
"on verra à la fin de ce cours comment, sans rien partager, on arrive à sécuriser les communications"

les attaques viennent à 50% de l'extérieur et à 50% de l'intérieur, "il ne faut donc pas se focaliser sur l'extérieur, c'est pour ça que dans les banques ils gardent toutes les traces"

attaques coordonnées

Tsutomu Shimomura (IBM) : comment pirater une machine située sur les locaux et continuellement surveillée ? "le seul moment où il n'y a plus d'activité aux États-Unis c'est à Noël"
Kevin Mitnick : pour réussir l'IP Spoofing, il faut faire du flooding sur l'hôte que la victime cherche à joindre (= machine de confiance) pour le mettre hors service

hameçonnage : obtenir des renseignements personnels dans le but de perpétrer une usurpation d'identité, en faisant croire à la victime qu'elle s'adresse à un tiers de confiance

"tu ne peux pas dire aux gens de faire un mot de passe compliqué, ils ne le feront jamais, les gens cherchent la facilité"
"on pense que la probabilité d'être attaqué est tellement faible qu'on n'a pas envie de se compliquer la vie"

"maintenant vous savez, on peut signer de façon numérique, c'est beaucoup plus efficace qu'à la main"
ex. le passeport contient la clé privée, l'aéroport ne connaît que la clé publique de la préfecture qui a délivré le passeport
-> comment peut-on chiffrer et déchiffrer avec deux clés différentes ?

fonctionnement d'HTTPS :

client -> demande l'accès -> YouTube
client <- voici mon certificat avec ma clé publique, signée par Google CA <- YouTube
client -> je fais confiance à Google, donc je crée une nouvelle clé secrète que je chiffre avec la clé publique de YouTube, et j'envoie celle-ci à YT -> YouTube
client <- nous sommes les deux seules machines sur tout l'internet à connaître cette nouvelle clé secrète <- YouTube

"on pourrait le faire avec des clés privées et publiques, mais ça demande beaucoup plus de puissance de calcul, c'est l'inconvénient du chiffrement asymétrique"

chiffrement asymétrique :

Alice -> message en clair -> Bob
Alice <- message en clair qui contient la clé pub de Bob <- Bob
Alice -> génère une clé secrète avec la clé pub de Bob et l'envoie -> Bob
Bob peut désormais utiliser la clé secrète que lui a partagé Alice

le premier algo de chiffrement asymétrique est élaboré au début des années 70 mais gardé secret sous la pression des services secrets britanniques
opération mathématique facile à effectuer dans un sens, mais très difficile dans l'autre sens (ex. logarithme discret) -> il faut qu'il soit impossible de trouver la clé privée à partir de la clé publique
la clé privée doit être connue uniquement de son propriétaire

mais il faut aussi vérifier l'identité de la personne, puisque n'importe qui peut accéder à la clé publique : il faut donc authentifier la personne avec sa clé publique

Alice -> message chiffré avec la clé privée d'Alice -> Bob
Bob utilise la clé pub d'Alice pour déchiffrer le message = si ça marche, alors le message est bien d'Alice

on peut ensuite utiliser les deux à la fois : confidentialité + authentification

Alice -> message chiffré avec la clé privée d'Alice puis avec la clé pub de Bob -> Bob
Bob déchiffre avec la clé privée de Bob (confidentialité) puis la clé pub d'Alice (authentification)
"si on peut chiffrer avec la publique et déchiffrer avec la privée, on peut parfaitement faire l'inverse"

avantages de l'asymétrique :

on peut échanger les clés publiques librement, sur des canaux non sécurisés
on peut faire des bases de données de clés publiques
on peut s'en servir pour les signatures numériques (authentification)
croissance linéaire : n utilisateurs -> n paires de clés ("avec le seul symétrique, on n'aurait pas d'internet sécurisé")
inconvénients :
temps de calcul important ("et vous savez qu'avec le quantique ça va changer")
sensible à certaines attaques, "on verra ça après"
longueur de clés très grande
"on ne va jamais utiliser l'asymétrique pour faire de la vraie sécurité, ça ne sert que pour sécuriser le canal et mettre en place la sécurité symétrique, c'est-à-dire le chiffrement"

ex. : utiliser l'asymétrique pour sécuriser l'échange de clés de façon symétrique

Alice chiffre un message avec une clé de session Ks -> canal non sécurisé -> Bob reçoit le message qu'il ne peut pas encore déchiffrer
Alice chiffre Ks avec la clé publique de Bob -> canal non sécurisé -> Bob la déchiffre avec sa clé privée et l'utilise pour déchiffrer le message
"tout ça prend une milliseconde"

c'est ce qu'on appelle le cryptosystème hybride => combiner les avantages des deux systèmes

AES est basé sur des concepts du XIXe siècle inventés par Galois, "les mathématiciens ont mis 10 ans à les comprendre"
à l'heure actuelle, AES n'a toujours pas de faille majeure connue

RSA : "ce n'est pas les premiers à avoir trouvé la technique des clés privées et publiques, on a découvert plus tard que d'autres l'avaient trouvé avant mais l'avaient gardée secrète"

𝑝 et 𝑞 sont des nombres premiers
on multiplie les deux valeurs 𝑛 = 𝑝.𝑞
𝜑(𝑛) = (𝑝-1) (𝑞-1)
𝑒 et 𝜑(𝑛) sont premiers entre eux
𝑑 tel que 𝑑.𝑒=1mod𝜑(𝑛)
clé publique : Kp=(𝑒,𝑛)
clé privée: Kp=(𝑑,𝑛)
pour inverser le processus et déduire la clé privée, il faut factoriser le nombre 𝑛 (très difficile)

Diffle-Hellman : "beaucoup plus rapide" mais n'est sûr que si le canal est authentifié (sensible aux attaques MitM)

DNS cache poisoning : "le problème dans l'internet, c'est qu'on accepte toujours la première réponse"

TP : préparation

dans la fenêtre Configuration :

Général/Nom = Serveur
Réseau/Adapter 2 :
- Activer l'interface réseau = 🗹
- Mode d'accès réseau : Réseau interne
- Nom : eth1

dans la machine virtuelle "Serveur" (appuyer sur Entrée si le prompt $ ne s'affiche pas)

vérifier que net-tools est bien installé en lançant ifconfig (à défaut, suivre les instructions données par la commande)
éditer le fichier /etc/network/interfaces (par ex avec sudo nano /etc/network/interfaces) pour régler l'IP d'eth1 sur une adresse statique 192.168.1.1 (voir pdf sur Moodle)

auto eth1
iface eth1 inet static
address 192.168.1.1
netmask 255.255.255.0

pour rappel, dans nano : sauvegarder (Ctrl+O, puis Entrée) et quitter (Ctrl+X)
vérifier si ça marche avec ifconfig -a (le cas échéant, initialiser avec sudo ifup eth1)

dans Virtualbox, cloner la 1ère machine et renommer le clone "PC1"
dans la machine virtuelle "PC1", modifier l'IP d'eth1 en 192.168.1.2
tester la connexion entre les 2 machines virtuelles (à l'aide de ping suivi de l'adresse IP)

TP : exercice 1

si nécessaire, activer ssh sur "Serveur" (sudo systemctl start ssh)
sur "PC1", générer un duo de clés RSA : ssh-keygen -t rsa

appuyer sur Entrée sans renseigner de nom ni de phrase de passe, utiliser les valeurs par défaut (de cette manière, les clés seront crées dans le bon dossier ~/.ssh)
copier les clés sur "Serveur" avec ssh-copy-id stud@192.168.1.1
tester la connexion de "PC1" à "Serveur" : ssh stud@192.168.1.1 => en principe, aucun mot de passe ne doit être demandé

créer un nouveau duo de clés, cette-fois ci en renseignant une phrase de passe mais toujours sans nom
répéter les autres étapes à l'identique
[TODO : ssh-agent]

"donc on a fait un serveur, créer les adresses IP à la rigueur ce n'est pas important, quelqu'un l'aura fait pour vous, donc imaginez que notre réseau est déjà prêt"
"on ne va donc pas faire une évaluation sur la configuration de Virtualbox, moi je configurerai le serveur moi-même"
"la seule chose que vous devez comprendre, c'est comment obtenir l'information, donc ifconfig"
"tout le but de ce cours, c'est d'utiliser ssh pour ne plus avoir à saisir de mot de passe"

TP 2 : exercice 1

Mot de passe : le fichier passwd est stocké dans /etc et non dans /etc/passwd
idem pour shadow

Signatures :

pour "créer une paire de clés", ne pas utiliser ssh-keygen mais la commande openssl donnée dans le pdf sur le Moodle : openssl genrsa -out nomDeLaCle 2048