Avancé

Table des matières


Avant propos

Avec l’augmentation de l’usage des communications internet depuis les années 2000, c’est posé assez rapidement la question de la confidentialité et l’intégrité des communications. En sécurité informatique, nous avons l’habitude de distinguer trois grands principes de sécurité des données ou communications :

  • disponibilité: la capacité du service à donner accès aux données. Nous n’aborderons pas ce point là dans ce document,
  • confidentialité: la capacité à s’assurer que les données ne sont pas lues par des personnes n’étant pas autorisées à y avoir accès (chiffrement),
  • intégrité: la capacité à s’assurer que les données n’ont pas été altérées (signature).

Il existe deux grandes familles d’algorithmes pour assurer la confidentialité et l’intégrité des communications :

  • les algorithmes symétriques ou le même secret est partagé par les deux parties. Ces algorithmes ont l’avantage d’être simple et demande peu de ressource de calcul. Par contre, ils nécessitent une phase de diffusion du secret qui est particulièrement critique,
  • les algorithmes asymétriques ou deux secrets différents permettent de chiffrer et déchiffrer la communication. Ces algorithmes sont très sûr car, il repose sur le fait qu’une partie du secret n’est jamais divulgée. Néanmoins, ils sont complexes et gourmants en ressources. De plus, il nécessite que chacune des parties possèdent un jeu de clef asymétrique pour chiffrer la totalité d’une communication.

Aujourd’hui, le chiffrement et la signature par clef asymétrique sont très largement utilisés pour répondre aux différents enjeux de confidentialité et d’intégrité.

Attention ! il ne s’agit ici que d’une explication généraliste du fonctionnement

1. Fonctionnement général

Le chiffrement / signature par clef asymétrique repose sur différents algorithmes mathématiques qui permettent d’utiliser une clef pour le chiffrement / vérification de la signature des données et une clef pour le déchiffrement / signature de celle-ci. Dans ce mécanisme, il n’est pas possible de déchiffrer un message avec la clef utilisé pour le chiffrement des données. De la même manière, il n’est pas possible d’utiliser la clef de déchiffrement pour chiffrer un message.

Il suffit donc a chacun de créer un jeu de clef qui permettront, selon les cas, de chiffrer ou déchiffrer les messages.

  • 1 clef dites privée qui ne doit jamais être diffusé à autrui
  • 1 clef dites publique que nous pouvons diffuser publiquement à n’importe qui.

Suivant les différents cas d’usage (confidentialité ou intégrité) nous utiliserons

  • la clef publique pour chiffrer les messages confidentiels qui ne pourront être lus que par la personne possédant la clef privée permettant de déchiffrer le message,
  • la clef privée pour signer les messages qui ne pourront pas être signé par les personnes disposant de la clef publique.

Cela implique que :

  • n’importe qui pourra envoyer un message confidentiel à quelqu’un,
  • n’importe qui pourra vérifier l’intégrité d’un message signé par une personne.

2. Cas simple de communication entre Alice & Bob

Supposons que Bob veuille envoyer un message chiffré à Alice que seul Alice puisse déchiffrer.

sequenceDiagram autonumber actor Bob actor Alice Bob->>Alice: Je souhaiterais te parler, voici ma clef publique bob.pub Alice->>Bob: Voici ma clef publique alice.pub rect rgb(140,148,152) note right of Bob: Communications chiffrées Bob->>Bob: msg.crypt = chiffre(message, alice.pub) Bob-->>Alice: msg.crypt Alice->>Alice: déchiffre(msg.crypt, alice.priv) Alice->>Alice: rep.crypt = chiffre(réponse, bob.pub) Alice-->>Bob: rep.crypt Bob->>Bob: déchiffre(rep.crypt, bob.priv) end

On peut remarquer sur ce diagramme que les seules informations transitant en clair entre Bob & Alice ([1] et [2]) ne sont que des données peu sensibles. Contrairement au cas d’un algorithme de chiffrement symétrique pour lequel une négociation de la clef partagée aurait été nécessaire ou préalable.

3. Cas concret, l’exemple d’https

Si l’exemple simple si dessous répond parfaitement au besoin de confidentialité des communications, il repose sur le fait qu’Alice & Bob possèdent tous deux un jeu de clef asymétrique. Ce n’est pas le cas d’une communication https ou seul le serveur (https://ssi.in2p3.fr par exemple) possède un jeu de clef asymétrique (ici des certificats x509).

Pour réaliser la confidentialité des communications, nous allons donc mixer le chiffrement par clef asymétrique avec le chiffrement par clef symétrique. Prenons l’exemple d’Alice qui, à présent, veut communiquer avec son site bancaire.

Le jeu de clef asymétrique du serveur bancaire va être utilisé pour négocier un secret partagé entre Alice et la Banque. Dans des cas simples, le secret est généré par Alice et envoyé au serveur, mais il existe des protocoles plus complexes (Diffie-Hellman) qui permettent de négocier des secrets partagés sans jamais le transmettre. Dans ce cas, la négociation ressemble à un jeu de qui est-ce? mathématique.

sequenceDiagram autonumber actor Alice participant Banque Alice->>Banque: Bonjour Banque->>Alice: Voici ma clef publique (banque.pub) rect rgb(140, 146, 152) note right of Alice: Négociation secret partagé Alice->>Alice: secret.crypt = chiffre_asymétrique(secret, banque.pub) Alice-->>Banque: secret.crypt Banque->>Banque: déchiffre_asymétrique(secret.crypt, banque.priv) end rect rgb(140, 146, 152) note right of Alice: Communications chiffrées Banque->>Banque: msg.crypt = chiffre_symétrique(message, secret) Banque-->>Alice: msg.crypt Alice->>Alice: déchiffre_symétrique(msg.crypt, secret) Alice->>Alice: crédentiels.crypt = chiffre_symétrique(crédentiels, secret) Alice-->>Banque: crédentiels.crypt Banque->>Banque: déchiffre_symétrique(crédentiels.crypt, secret) end

L’intérêt de combiner les deux approches (chiffrement symétrique et asymétrique) est qu’il n’est nécessaire d’avoir qu’un seul jeu de clef asymétrique pour fonctionner, Alice n’a pas besoin de faire de démarche particulière pour se connecter à sa banque.

4. Mais comment savoir que je me connecte bien à ma banque ?

Jusqu’ici, nous n’avons présenté que le fonctionnement basique du chiffrement des communications, la phase critique en termes de confidentialité est l’envoi de la clef publique du serveur. Si un site malveillant envoie sa propre clef publique, alors Alice communiquera de manière confidentielle avec ce site malveillant.

Pour cela, nous utilisons des tiers de confiance (Autorité de certification, fichier known_hosts,…) . Un tier de confiance est un acteur extérieur aux deux protagonistes qui va certifier que la clef publique envoyée est bien celle du site de référence. Dans le cas du https, le tier de confiance est l’autorité de certification qui signe la clef publique du serveur. Cette signature peut être validée par chacun possédant la clef publique de l’autorité de certification. Les systèmes d’exploitation intègrent directement les clefs publiques des autorités de certification officielles.

En reprenant schématiquement l’exemple précédent, Alice, après avoir reçu la clef publique de la banque, va vérifier cette clef en utilisant la clef publique de l’autorité de certification. Cette clef, contient en plus diverses informations concernant le cas d’usage de celle-ci.

  • le nom du serveur qui va utiliser le jeu de clef
  • la durée de validité de cette signature
sequenceDiagram autonumber participant Autorité actor Alice participant Banque Autorité ->> Alice: Voici ma clef publique (autorité.pub) rect rgb(140, 146, 152) note right of Autorité: Signature de la clef publique Banque ->> Autorité: clef non signé (banque.csr) Autorité ->> Autorité: banque.pub = sign(banque.csr, autorité.priv) Autorité ->> Banque: Voici ta clef publique (banque.pub) end Alice ->> Banque: Bonjour Banque ->> Alice: Voici ma clef publique (banque.pub) Alice ->> Alice: unsign(banque.pub, autorité.pub) Alice -->> Banque: ...