Sécuriser ses communications électroniques [2]

Bonjour à tous !

Un samedi après-midi à occuper à la médiathèque, ça veut dire un nouvel article, non ? 🙂

On continue donc sur la lancée de l’article précédent, sauf que cette fois-ci, on va parler un peu des clés publiques : comment c’est fichu, en quoi c’est plus ou moins fiable, où les stocker/diffuser… avec un peu de détails aussi sur les chaînes de confiance. Allons-y !

 

Une clé publique, c’est quoi ?

Généralement, on utilise le terme « clé publique » pour désigner ce qui est en fait un ensemble « clé publique » + « certificat de clé publique ».

Pour pouvoir utiliser une clé publique en toute sécurité, il faut être en mesure de répondre à deux questions essentielles : « à qui appartient la clé publique que je vais utiliser ? », et « à quoi sert-elle, cette clé ? ».

Vous comprendrez donc facilement qu’il est indispensable que la clé en elle-même soit accompagnée d’informations décrivant à la fois son usage et surtout son propriétaire. C’est un peu une « carte de visite », qui reprendrait le nom du propriétaire, la valeur de la clé et ce pour quoi elle a été créée. C’est le certificat.

 

Caractéristiques principales d’un certificat

Un peu de bon sens !

On va faire ça sous forme de liste, pour que ce soit clair :

  1. le certificat est sous forme électronique et doit pouvoir être manipulé par des ordinateurs, et il est distribué publiquement sur le réseau ;
  2. il est individuel, et donc propre à la personne qui l’a créé (personne physique ou morale, voire équipement informatique, car oui nos machines peuvent disposer de certificats comme les certificats SSL des sites web que vous visitez) ;
  3. les tiers qui seront amenés à l’utiliser doivent pouvoir identifier l’identité à laquelle il se rapporte sans ambiguïté ;
  4. les informations contenues dans le certificat ont été validées par une autorité (ok, dans la réalité, on signe souvent nous-mêmes nos certificats, parce que les autorités de certifications demandent souvent des tarifs exorbitants) ;
  5. le certificat doit contenir la clé publique se rapportant à la clé asymétrique privée (et unique) de l’émetteur ;
  6. il doit être facile d’identifier l’entité qui a pris la responsabilité d’émettre le certificat ;
  7. le certificat doit être infalsifiable, et toute éventuelle modification (on sait jamais) doit être identifiable rapidement par les utilisateurs tiers ;
  8. l’usage pour lequel a été conçue la biclé doit être spécifié (signature, chiffrement…) ;
  9. le certificat doit mentionner sa période de validité (date de début, date de fin) ;
  10. enfin, il doit comporter un numéro d’identification.

Tout ça doit vous paraître ou évident, ou bête, ou les deux… C’est du bon sens, surtout : le raisonnement est identique à celui appliqué à votre passeport : on doit pouvoir vérifier que c’est le vôtre, et il mentionne bien les infos décrites ci-dessus…

 

La preuve par l’exemple

Je vais utiliser ma propre clé PGP pour illustrer les points précédents 😉

J’ai encadré en rouge une partie des infos importantes données par le certificat. Graphiquement, il indique « clé privée » parce qu’elle est présente. Via la console, les mêmes informations sont disponibles, bien que moins « claires », pour l’utilisation par exemple. Ainsi, la clé publique a les attributs S, C et A (pour Sign, signature, Certificate, création de certificat, et Authentication, pour l’authentification), et la clé privée a l’attribut E (pour Encrypt, chiffrer).

Il reste une partie importante à aborder : le fait de rendre le certificat infalsifiable. Dans le cas d’un « vrai » certificat genre votre passeport, on rajoute des tas de trucs, un filigrane par-ci, une puce signée par-là… pas évident pour vous avec votre clé !

Comment ça marche du coup ? On fait appel à une infrastructure de confiance.

 

Les infrastructures de confiance

Plusieurs modèles cohabitent selon le cas. On peut déjà citer les Autorités de Certification, et les chaînes de confiance.

 

L’autorité de certification

C’est une entité reconnue par plusieurs acteurs utilisant un système. Elle (l’autorité de certification) va prendre soin de vérifier l’identité de l’émetteur d’un certificat (comme dans le cas d’un site web utilisant le chiffrement SSL, si si rappelez-vous, le petit cadenas à côté de l’URL :mrgreen: ) afin d’assurer aux tiers (vous par exemple) que le site que vous visitez est bien celui qu’il prétend être, et que ce n’est pas une tentative d’hameçonnage par exemple.

Un exemple de certificat SSL :

Malheureusement, à part de rares autorités de certification gratuites (et pas nécessairement reconnues par les navigateurs, entre autres), cette étape de validation coûte assez cher, et en tous les cas bien trop cher pour un blog comme le mien. Notez que plusieurs « niveaux » de certification existent, reposant sur une vérification d’identité plus ou moins poussée.

C’est pour cela que vous croisez régulièrement des certificats indiqués comme « suspects », pour une raison principale : le certificat est auto-signé, c’est-à-dire que la personne qui l’a généré en a profité pour le signer elle-même, sans passer par une autorité reconnue. Notez bien que cela n’empêche en aucun cas le chiffrement des données, simplement, à vous d’estimer votre niveau de confiance envers le destinataire. Si c’est la plate-forme de messagerie familiale, peu de risque. Par contre, un site marchand avec un certificat non valide… Là, c’est louche.

C’est justement (avouez que c’est bien fait 😀 ) ce principe d’auto-signature qui nous mène au second modèle expliqué ici…

 

La chaîne de confiance

C’est donc l’autre modèle le plus courant. Il est basé comme expliqué plus amont sur une infrastructure de clés publique, sorte de gros annuaire qui met à disposition les clés publiques des utilisateurs.

Quand vous générez une clé : qu’est-ce qui prouve aux autres utilisateurs que c’est bien vous en face ? Prenons un exemple rapide : vous ne connaissez pas mon adresse de courriel, et je génère un nouveau trousseau à mon nom (en plus de celui qui existe déjà), avec une autre adresse e-mail, et pour m’écrire vous avez donc le choix entre les deux clés : laquelle choisir ?

Chacune de ces deux clés sera probablement auto-signée, parce que c’est le minimum. Et ensuite ?

C’est là que la chaîne de confiance entre en jeu.

 

Vos amis, collègues… peuvent utiliser leur propre clé pour signer la vôtre ! Après avoir vérifié votre identité, donc… Cela ajoute de la valeur à votre propre clé : plus elle a été signée, plus elle est fiable.

Le concept de chaîne vient du fait que vous pouvez « hériter » de la confiance de ceux qui signent votre clé. Je m’explique parce que c’est obscur, un peu. Je génère ma clé, que Bob va signer. Vous voyez déjà le hic : je peux générer à la volée 50 clés, et en utiliser 49 pour signer la dernière. C’est nul, mais bon, ça se peut.

Sauf que ces 49 clés ne seront pas signées, elles.

Reprenons. Bob signe ma clé avec la sienne. Et il se trouve que son amie Alice avait déjà signé la clé de Bob : on ajoute un niveau de plus dans la chaîne de confiance. C’est une sorte d’arbre : la clé d’Alice peut elle aussi avoir été signée par d’autres personnes, elles-mêmes en possession de signatures d’autres utilisateurs, et ainsi de suite.

Plus la chaîne est longue, plus la confiance en la clé est forte. C’est pour cela que des « signing party » sont organisées, pour que des gens puissent se rencontrer, vérifier physiquement qui est qui (pièce d’identité, tout ça), puis signer chacun la clé de l’autre.

Concrètement : ma clé publique a été signée par quelques amis, dont les clés ont elles-mêmes été signées par des amis de ces amis, et ainsi de suite. La chaîne commence à être longue, mais attention à la vérification d’identité que vous faites 😉

 

 

On a le droit à l’erreur ?

Errare humanum est, comme disait l’autre. Vouloir sécuriser ses communications électroniques c’est louable, mais on peut se tromper en générant sa clé, en en signant une, ou pour plein de raisons comme la perte/destruction d’une adresse e-mail…

Il est donc possible, lorsque l’on possède un trousseau de clés PGP, de révoquer une clé entière, une sous-clé (une adresse e-mail par exemple), ou même une signature faite sur la clé d’une autre personne.

Ainsi, si vous avez bien observé la capture d’écran de ma clé en console un peu plus haut, vous aurez remarqué qu’une de mes sous-clés correspondant à une adresses e-mail est marquée comme « révoquée » : je l’ai fait lorsque l’adresse en question a été supprimée à mon départ de l’université qui me l’avait mise à disposition. Ainsi, chacun sait que cette adresse ne doit plus être utilisée, et un avertissement peut même apparaître selon le logiciel de messagerie que vous utilisez 😉

 

End of Transmission

Voilà voilà, ce sera tout pour aujourd’hui. Encore une fois, j’ai essayé de faire au plus simple, malgré le fait que certaines notions soient complexes. Amis connaisseurs, excusez donc certaines « maladresses », mais rien ne vous empêche de compléter via les commentaires 😉

J’espère que j’ai pu clarifier votre vision de ce système tentaculaire, et aussi (un peu) vous donner envie de générer votre propre clé pour vous lancer dans l’aventure.

Le prochain article, un poil plus « barbant », reviendra lui sur les aspects juridiques de la chose : reconnaissance des clés, limites au chiffrement, obligations légales (par exemple, si on saisit votre disque dur chiffré dans le cadre d’une enquête, ce que je ne vous souhaite pas !)… Stay tuned!

5 réflexions sur “ Sécuriser ses communications électroniques [2] ”

  • 27 janvier 2014 à 9 h 32 min
    Permalink

    o/

    Bien sympathique ces articles ! Juste une question, qui revient souvent quand on parle de confiance, et de choses comme ça.

    Qui gère les PKI ? Des associations, des universités ? Y a-t-il un moyen de vérifier qu’elles ne mettent pas le bazar là dedans ? Sont-elles pleinement de confiance ?

    Un peu comme la supposée backdoor dans GNU/Linux, « on se demande » sans en avoir la preuve, donc je demande 😀

    En tout cas, merci bien pour ces éclaircissements sur un système trop peu connu du (vrai) « grand public »à ce jour.

    Vivement la suite ! \o/

    Réponse
    • 27 janvier 2014 à 11 h 15 min
      Permalink

      Questions qui méritent effectivement d’être posées, j’y ai répondu dans l’article directement, un petit addendum me semblait plus clair ! Merci du retour :mrgreen:

      Réponse
  • 27 janvier 2014 à 12 h 21 min
    Permalink

    Bonjour !
    Et merci pour cette série d’article, je fais passer le lien parmi mes connaissances non ou peu initiées à la sécurité de ses communications.
    J’attend la suite avec impatience.
    Bonne continuation !

    Réponse
  • 1 février 2014 à 12 h 34 min
    Permalink

    Bonjour !
    Article bien sympathique sur un sujet plus qu’actuel.
    J’ai retrouvé pas mal de trucs glanés à La Cantine, notamment avec une conférence de Benjamin Sonntag (disponible sur confs.fr). A quand la suite ? 🙂

    Bon Week-end !

    Hugo

    Réponse
    • 2 février 2014 à 18 h 28 min
      Permalink

      Hey !
      Merci du retour (ainsi qu’à François !), c’est certes un sujet d’actualité mais c’est aussi un sujet touffu et complexe, pas toujours facile à cerner et encore moins à vulgariser. Si ça convient à quelques-uns, c’est déjà ça de gagné :mrgreen:

      Le prochain « volet » arrive en début de semaine (je préfère pas trop m’engager, mais mardi probablement) et traitera de la partie « grand public » : comment sont stockés les mots de passe des usagers (sessions utilisateurs, sites web, disques durs…), citer quelques outils qu’ils peuvent utiliser au quotidien pour communiquer, et des ressources complémentaires à consulter sur le sujet.

      Et il y en aura un autre après, un peu plus compliqué, sur des exemples concrets d’algorithmes et fonctions de hachage, mais avec évidemment un peu plus de maths dedans… Celui-là, il va me prendre un poil de temps 😛

      Si tu as des remarques/suggestions, n’hésite pas, tout ce qui peut enrichir les articles est bienvenu ! Tu peux même envoyer un mail ou utiliser le form de contact 😉

      Réponse

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *