Pour aller plus loin...

Durée0h30

Un peu de sécurité

Introduction

Dans le contexte de notre projet de Smart Grid, on pourrait imaginer différents scénarios d’attaques de sécurité potentiels. Même si l’on ne va pas implénter de mécanismes de sécurité pour rester simple (il y a déjà pas mal de choses à coder comme ça), on peut quand même essayer d’y réfléchir.

En informatique, on s’intéresse généralement aux propriété de sécurité suivantes:

Confidentialité: l’information n’est accessibles qu’aux personnes autorisées,
Authenticité: la personne est bien celle qu’elle prétend être,
Intégrité: l’information n’a pas été modifiée,
Disponibilité: le système est bien accessible aux moments prévus,
Non-répudiation: une personne ne peut nier être l’auteur d’une information,
Traçabilité: on peut savoir de manière sûre qui a eu accès à quoi.

Dans le cas de communication réseau, on peut assez facilement déployer du chiffrement TLS. TLS va apporter une réponse à certaines de ces propriétés de sécurité. Des certificats (basés sur du chiffrement asymétrique) permettent d’authentifier les participants. Puis, la création dynamique d’une clef symétrique partagée (algorithme Diffie-Hellman) permet de chiffrer les communications.

L’outil ncat utilisé précédemment sait faire du TLS pour chiffrer des connexions TCP (ainsi que sa variante DTLS dédiée à l’UDP). Il suffit d’invoquer les bonnes options sur la ligne de commande. Reportez-vous à sa documentation. (Pour diverses raisons historiques, ces options s’appellent “ssl”, du nom de la toute première version de TLS avant d’être standardisée.)

Mais pour cela il “suffit juste” de lui fournir des certificats… 😜

Génération de certificats

Principe

Un des grands problèmes pour mettre en place de la sécurité informatique, c’est la question de la distribution des clefs.
(Oui bon, les questions mathématiques liées à la conception d’algorithmes cryptographiques sont également pointues… mais concentrons-nous sur la question des clefs.)

Si vous ne connaissez pas de manière sûre votre interlocuteur, peut-être connaissez-vous tous les deux une tierce personne en laquelle vous faites toute confiance et qui vous connait tous les deux. Cette personne peut certifier à chacun que l’autre est bien ce qu’il prétend être. (Tant que vous lui faites confiance à lui.) C’est le principe du tiers de confiance. (Pensez aux cartes d’identité délivrées par l’état.)

Ce tiers de confiance peut être centralisé. C’est le cas le plus simple. Il y a une autorité de certification unique.
Ce tiers de confiance peut être multiple. C’est-à-dire que l’on fait confiance à plusieurs autorités distinctes. C’est le cas précédent, mais qui se répète. (Pensez aux passeports délivrés par différents pays reconnus.)

TLS fonctionne un peu sur ce principe, avec en plus la possibilité de déléguer. Votre ordinateur a été pré-installé avec un certain nombre de certificats racine, probablement pas loin de 150 autorités de certification, auxquelles vous faites confiance, possiblement sans trop le savoir. (Mais d’autres y ont pensé pour vous…)
Ce tiers de confiance peut être non pas unique, mais distribué. Je fais confiance à quelqu’un qui connait quelqu’un qui connait… et qui connaît mon interlocuteur. On parle alors, non pas d’une autorité de certification, mais d’une chaîne de certification, sans autorité centrale, en pair à pair. Le système PGP fonctionne ainsi.

Recette de cuisine

Ici il nous faut:
- Une autorité de certification.
  Nous allons créer notre propre autorité de certification auto-signée.
  Pour quelques euros et quelques procédures administratives, on aurait pu solliciter une autorité déjà établie, mais on va rester simple pour cet exercice.
- Un certificat pour le serveur.
  Son certificat sera signé par notre autorité de certifications pour que les clients puissent le reconnaître comme tel.
  Réciproquement, le serveur sera configuré pour reconnaître notre autorité de certification, et par voie de conséquence accepter l’authenticité des clients.
- Des certificats pour chacun des clients.
  Les clients seront configurés pour reconnaître notre autorité de certification, et par voie de conséquence accepter l’authenticité du serveur.
  Réciproquement, eux-mêmes auront un certificat signé par notre autorité de certification pour certifier leur identité auprès du serveur. Notez que ce cas de figure est plutôt rare dans le cas du web, où, même en HTTPS, les navigateurs des utilisateurs ne présentent généralement pas de certificat d’identité au serveur…
Outillage

Installez OpenSSL
- Windows
  winget install openssl
- Linux
  sudo apt-get install openssl
- Mac
  brew install openssl
Vocabulaire & acronymes
- CA: Certificat Authority
- KEY: Private key
- CSR: Certificat Signing Request
- CRT: Certificat
Standards
- RSA: l’algorithme de chiffrement que nous allons utiliser ici
- X509: le format des certificats que nous allons utiliser ici
- PEM: un format courant pour enregistrer des clefs et des certificats

Autorité de certification

Parmi les divers tutos en ligne, on va s’inspirer du tutoriel de Zephilou. (Notez que le logiciel OpenVPN, qui utilise aussi TLS, propose une série de scripts “easy RSA” qui automatisent tout cela. Mais on va éviter d’installer un autre truc, et c’est plus pédagogique de le faire étape par étape.)

Avant toute chose, préparez-vous un répertoire de travail pour cette séance.

Créez la clef de notre authorité de certification racine (contient la clef publique et la clef privée):

openssl genpkey -algorithm RSA -out CA-ROOT.key

Vous pouvez voir ce qu’il y a dedans (c’est un fichier texte où les données sont encodées en base64), ou demander à le décoder: openssl rsa -noout -text -in CA-ROOT.key

Pour en extraire la clef publique: openssl rsa -in CA-ROOT.key -pubout -out CA-ROOT.pub
Pour voir ce qu’il y a dans cette clef publique: openssl rsa -noout -text -pubin -in CA-ROOT.pub
Mais on n’a pas besoin de garder ce fichier “CA-ROOT.pub”, vous pouvez l’effacer.
Générez votre propre certificat auto-signé:

openssl req -x509 -key CA-ROOT.key -out CA-ROOT.crt

Répondez aux quelques questions sur votre organisation. Racontez ce que vous voulez, mais rappelez-vous-en pour la suite.
```
You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Bretagne
Locality Name (eg, city) []:Brest
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Smart Grid Corp.
Organizational Unit Name (eg, section) []:UE Info S6
Common Name (e.g. server FQDN or YOUR name) []:ca.smart-grid.org
Email Address []:ca-support@smart-grid.org
```
Pour voir ce qu’il y a dans notre fichier: openssl x509 -in CA-ROOT.crt -noout -text

Auto-signé: En fait, on a fait deux choses en même temps. D’une part, on a émis une requête de certification en notre nom, et d’autre part, on a demandé à l’autorité (qui est nous-même) de la signer de son nom et ainsi certifier que c’est bien nous. Une autorité de certification racine va nécessairement signer son certificat elle-même, puisqu’il n’y a rien au dessus.

En toute rigueur, il conviendrait d’ajouter le certificat racine de notre nouvelle autorité de certification avec les autres pré-installés sur l’ordinateur. Mais on va s’en abstenir pour cet exercice.

Certificat serveur

Créez la clef d’authentification du serveur, comme précédement:

openssl genpkey -algorithm RSA -out server.key

Le serveur génère sa requête de certification:

openssl req -new -key server.key -out server.csr

Répondez aux quelques questions sur votre organisation. Là encore, racontez ce que vous voulez, mais soyez cohérent avec ce que peut attendre de vous votre autorité de certification car elle va vérifier.

You are about to be asked to enter information that will be incorporated
into your certificate request.
What you are about to enter is what is called a Distinguished Name or a DN.
There are quite a few fields but you can leave some blank
For some fields there will be a default value,
If you enter '.', the field will be left blank.
-----
Country Name (2 letter code) [AU]:FR
State or Province Name (full name) [Some-State]:Bretagne
Locality Name (eg, city) []:Conquet
Organization Name (eg, company) [Internet Widgits Pty Ltd]:Smart Grid Corp.
Organizational Unit Name (eg, section) []:UE Info S6
Common Name (e.g. server FQDN or YOUR name) []:server.smart-grid.org
Email Address []:server-support@smart-grid.org

Please enter the following 'extra' attributes
to be sent with your certificate request
A challenge password []:
An optional company name []:

Notez que vous pouvez chiffrer votre fichier de requête avec un mot de passe. Mais il faudra le communiquer par un moyen ou un autre à votre autorité de certification pour qu’elle puisse ouvrir votre fichier de requête.

Pour voir ce qu’il y a dans notre fichier: openssl req -in server.csr -noout -text

Le serveur transmet son fichier de requête de certification à l’autorité de certification.

Bon, là, c’est facile, c’est dans le même répertoire sur la même machine. Mais dans le cas général, il faut un moyen quelconque (email, formulaire web, pigeon voyageur…)
L’autorité de certification vérifie la requête (signature et informations diverses sur l’organisation):

openssl req -text -noout -verify -in server.csr
Et, si tout va bien (après contôle des papiers d’identité), l’autorité de certification, dans son coin, signe cette demande de certification:

openssl x509 -CA CA-ROOT.crt -CAkey CA-ROOT.key -days 365 -CAcreateserial -out server.crt -req -in server.csr

Regardez ce qu’il y a dans ce certificat: openssl x509 -in server.crt -noout -text
Remarquez qu’il y a un “Issuer”, c-à-d. notre autorité de certification.

Vous pouvez supprimer la demande de certification “server.csr”.

Un nouveau fichier a été créé: “CA-ROOT.srl” C’est pour noter les numéros de série successifs des certificats que l’autorité génère. Il a été initialisé à une valeur quelconque.
L’autorité transmet le certificat au serveur par un moyen sécurisé.

Bon, encore une fois, c’est facile, c’est dans le même répertoire sur la même machine.

Certificats clients

Créez la clef d’authentification du client-1, comme précédement:

openssl genpkey -algorithm RSA -out client1.key
Générez la requête de certification:

openssl req -new -key client1.key -out client1.csr
Signez cette requête:

openssl x509 -CA CA-ROOT.crt -CAkey CA-ROOT.key -days 365 -CAserial CA-ROOT.srl -out client1.crt -req -in client1.csr
Suivant vos envies, faites de même pour les clients 2, 3 …

Communication sécurisée

Maintenant que l’on a nos certificats (ouf!), on va pouvoir communiquer.

Côté serveur

ncat -l -4 5050 -k --ssl-trustfile CA-ROOT.crt --ssl-cert server.crt --ssl-key server.key
Côté client 1

ncat -4 localhost 5050 --ssl-trustfile CA-ROOT.crt --ssl-cert client1.crt --ssl-key client1.key --ssl-servername server.smart-grid.org

Tapez quelques mots dans la console. Youpi !

En cas d’échec, demandez à ncat d’être plus verbeux avec l’option “-vvvv”, et lisez avec attention les messages d’erreur.
Entre les deux: Wireshark, sur l’interface loopback.

Observez l’échange de paquets: le contenu est chiffré.

Regardez le protocole TLS: Wireshark peut analyser les premiers échanges et afficher quelques informations techniques pour la négociation du protocole de chiffrement.
Note: La documentation de ncat propose un exemple plus simple: pas d’autorité de certification, un certificat serveur auto-signé, pas de certificat client. Bilan: pas de garantie sur l’identité des correspondants, mais au moins le chiffrement de la communication.

Variante

Essayez-en UDP, et voyez la mise en place du protocole de chiffrement DTLS.