• Identité et Sécurité : Qui es-tu ?
• Identité et Sécurité : Signature Numérique

Mise en relation

Il manque dans tout ce système un détail. Comment le traiteur, qui n’a pour l’instant communiqué avec moi que par internet, peut-il savoir que je suis bien Victor Nicollet, habitant à l’adresse que je lui ai indiquée ? Il se pourrait tout à fait qu’un individu malveillant se fasse passer pour moi en associant mon nom à sa clé publique sur le site du traiteur. Ce dernier aurait donc en sa possession un contrat signé par une clé publique qui porte mon nom, alors que cette clé publique ne m’appartient pas !

Le plus simple (mais pas forcément le plus facile) est de fournir les identifiants de connexion en personne. Le traiteur peut me demander de passer à son siège pour que je lui donne ma clé publique. De la même façon, une banque peut envoyer par la poste un code d’accès au site à mon adresse, le Ministère de l’Economie, des Finances et de l’Industrie me demandera un identifiant qui se trouve uniquement sur mes avis d’imposition, et une école ou une entreprise me donnera les identifiants de mon compte informatique lors de ma première journée sur les lieux. Ces stratégies supposent donc que de se voir en personne (éventuellement, en regardant sa carte d’identité) permettent de s’assurer que celui qui reçoit les identifiants ou donne sa clé publique est bien celui qu’on veut voir.

On fait donc appel à un tiers de confiance qui a déjà identifié l’utilisateur et peut attester de son identité. C’est le principe même de la carte d’identité : celle-ci est juste la confirmation par un tiers de confiance (l’Etat) que l’identité de l’utilisateur correspond bien à son aspect physique (donné par la photo sur la carte) et à sa possession même de la carte. Comment transposer cela à l’informatique ?

Une manière de faire (qui existe depuis si longtemps qu’on la juge naturelle) est que le tiers de confiance donne un courrier électronique à l’utilisateur avec une adresse comportant son nom de domaine. Ainsi, pour l’adresse victor.nicollet@tangane.com, l’entreprise Tangane reconnaît que le propriétaire de cette adresse est l’individu Victor Nicollet qui travaille pour elle. Si vous faites confiance à Tangane, vous pouvez être certains que les courriers envoyés à cette adresse seront lus par moi, et pas par un individu qui se ferait passer pour moi. Par contraste, les mails envoyés à victor.nicollet@paradis-des-hackers.com seront probablement lus par la mauvaise personne.

Attention toutefois à ne pas en tirer de mauvaises conclusions : un courrier électronique qui vient de victor.nicollet@tangane.com n’a aucune raison d’avoir été écrit par moi ! Comme dans le monde réel, un individu peut indiquer sur l’enveloppe l’adresse d’expédition de son choix. Si un courrier électronique est d’une très grande importance, on peut vérifier son authenticité en demandant une confirmation (la demande de confirmation ne pouvant être lue que par le véritable propriétaire de l’adresse).

Ce type de vérification reste cependant peu pratique dans certaines situations. Par exemple :

Lorsque je visite pour la première fois le site de ma banque, en HTTPS, comment savoir que la clé publique qu’il me donne pour prouver son identité est bien la vraie, et non celle d’un individu malveillant qui se fait passer pour ma banque ?

Je télécharge en ligne un contrat d’assurance ou d’emprunt, je le signe, et je le renvoie par courrier électronique. Comment l’assurance ou la banque peut-elle vérifier que je suis bien celui que je prétends être, surtout si je n’ai pas de courrier électronique chez un fournisseur de confiance ?

La solution est d’utiliser ce qu’on appelle des réseaux de confiance. Pour prouver que ma clé publique est bien celle de Victor Nicollet, il me suffit de demander à une entité de confiance de signer un document numérique affirmant cela. Pour peu que l’entité de confiance soit reconnue (un pays, une institution internationale) mon interlocuteur, ainsi qu’un éventuel juge, acceptera cette signature comme la preuve que la clé publique m’appartient. Un contrat de la forme « je, soussigné Z, affirme que la clé publique X appartient à la personne Y » est appelé certificat, et les entités reconnues pour pouvoir signer un certificat sont appelées autorités de certification. Il suffit de se rendre auprès d’elles pour obtenir un certificat à son nom. Par exemple: http://www.verisign.fr/

Il existe une sorte particulière de certificat, appelé un certificat auto-signé : la personne Y affirme elle-même être la propriétaire de la clé publique X. Il n’interdit donc pas à un individu malveillant d’associer sa clé publique à un autre nom, mais il lui interdit en revanche d’associer son nom à ma clé publique. Certains logiciels, dont Adobe Reader, peuvent générer des certificats auto-signés.

• Identité et Sécurité : Qui es-tu ?
• Identité et Sécurité : Mise en relation

Signature Numérique

Même avec un système à clé publique normal, il reste un problème : celui de la preuve. Prenons un exemple imaginaire.

Un jour, un grand traiteur sur le site duquel j’ai un compte sonne à ma porte pour me livrer dix mille euros de petits fours. Je réponds ne jamais avoir commandé cela. Les petits fours étant périssables, le manque à gagner pour le traiteur peut le motiver à aller devant un tribunal. Comment le juge pourra-t-il déterminer si je suis le menteur (j’ai commandé les petits fours, soit pour nuire au traiteur, soit pour une occasion qui n’a plus lieu et pour laquelle je ne veux donc pas payer) ou si le traiteur est en faute (une erreur informatique dans son logiciel de commande, une erreur de saisie, ou même une volonté de me nuire) ?

Ce que le traiteur peut prouver, c’est que je me suis à un moment donné connecté à son site à l’aide de ma clé privée (et encore, il faudrait pour cela que la vérification de mon identité indique le site auquel je me connecte, sans quoi le traiteur aurait pu espionner et recopier ma connexion à un autre site). Mais même si je me suis connecté au site, ai-je réellement passé la commande comme il le prétend ? Cela, le système d’identification le plus avancé au monde ne pourrait le faire.
Dans le monde réel, lorsque deux personnes se mettent d’accord sur un contrat (surtout si c’est un contrat de dix mille euros) ils signent le document contractuel. On a donc développé en informatique un moyen de signer des contrats : la signature numérique.

Pour cela, il faut inverser le principe du système à clé publique. Lorsque je veux signer un contrat, je le crypte à l’aide de ma clé privée : n’importe qui peut alors le décrypter à l’aide de ma clé publique. Pour faciliter la lecture par un tiers, je joins le contrat crypté et ma clé publique au contrat original. Les autres signataires font de même, et l’on obtient à la fin un contrat original portant avec lui une clé publique et une signature pour chaque signataire.

Pour vérifier les signatures, il suffit d’utiliser les clés publiques pour décrypter les signatures et s’assurer qu’il s’agit bien du bon contrat. Cela prouve deux choses : d’abord, la signature appartient bien au propriétaire de la clé publique (car seul lui dispose de la clé privée permettant de crypter un contrat pour qu’il soit décryptable par la clé publique), et la signature s’applique bien au document auquel elle est associée (puisque décrypter la signature indique quel était le contrat qui a été signé).

Il suffit donc au traiteur de m’envoyer, lorsque je veux passer une commande, le contrat au format PDF (contenant date de commande, date de livraison, prix et liste des petits fours). Je signe le contrat à l’aide de ma clé privée, par exemple à l’aide de ma version gratuite d’Adobe Reader, et je le lui renvoie. Le traiteur vérifie alors que la signature est correcte, ce qui lui permettra de faire valoir auprès d’un tribunal que j’ai effectivement signé ce contrat et que je dois donc mettre la main à la poche. En ce qui me concerne, je suis tranquille : ne disposant pas de ma clé privée, le traiteur ne pourra ni volontairement ni involontairement imiter ma signature et donc signer à ma place un contrat.

• Identité et Sécurité : Signature Numérique
• Identité et Sécurité : Mise en Relation

Concepts fondamentaux en informatique, l’identité et la sécurité sont liées. Un pirate ne peut pas prendre le contrôle d’un ordinateur que personne ne peut contrôler, par définition. Mais s’il existe une personne capable de contrôler l’ordinateur, alors le pirate pourra se faire passer pour elle. Chaque fois que l’on entend parler d’une faille de sécurité, il y a une donc question d’identité sous-jacente : exploiter une faille de sécurité, c’est pour l’attaquant tromper le système afin d’assumer l’identité d’une cible disposant de droits supérieurs, et d’agir en tant que tel pour en bénéficier. L’auteur d’un virus se fait passer pour l’utilisateur de l’ordinateur afin d’installer des programmes nuisibles, le hacker se fait passer pour un administrateur pour accéder à des informations confidentielles ou prendre le contrôle d’un serveur, les phishers se font passer pour une autorité légitime pour obtenir des utilisateurs des informations critiques, les spammeurs se font passer pour des auteurs humains pour que leurs courriers arrivent dans les boîtes aux lettres.

Et tout le travail des experts en sécurité et des équipes de développement, c’est de s’assurer que l’interlocuteur d’un programme est bien la personne voulue.

Qui es-tu ?

La première question qu’on se pose, lorsqu’on doit mettre en place un système sûr, c’est comment reconnaître les personnes. Le premier principe de la reconnaissance, c’est de pouvoir déterminer si deux visiteurs (par exemple, à quelques jours d’intervalle) sont ou non la même personne.

Par exemple, un visiteur s’inscrit sur un site internet et effectue quelques opérations. Une semaine plus tard, il revient sur le même site et veut continuer son activité. Le site doit donc pouvoir déterminer que le visiteur d’il y a une semaine et le même que le visiteur d’aujourd’hui.

Le moyen le plus simple d’effectuer cela est le nom d’utilisateur. Le visiteur en a choisi (ou reçu) un lors de sa première visite, et il lui suffit de le taper à nouveau pour que le site le reconnaisse. Ce système est souvent utilisé sur internet, dans des formes plus ou moins déguisées :

• Certains sites où l’information stockée n’est pas essentielle. Par exemple, pour identifier ses visiteurs, le site BrowserShots utilise l’URL qu’ils ont demandé à examiner comme nom d’utilisateur. Deux utilisateurs qui demanderont la même URL seront donc considérés comme un seul et même individu.
• De nombreux outils de blog, comme Wordpress, utilisent une adresse mail secrète pour permettre aux gens de poster par mail. Ainsi, un utilisateur qui connaît l’adresse mail utilisée par le blog peut poster sur le blog directement. Cette adresse sert donc de nom d’utilisateur, permettant d’identifier les auteurs qui ont le droit de poster.
• La majorité des sites non sécurisés utilisent pour reconnaître les utilisateurs des cookies. Un cookie contient un numéro de session qui sert de nom d’utilisateur. Comme il est compliqué à retenir, c’est l’explorateur qui se charge de le retenir et de le renvoyer au site à chaque page visitée. Mais si un attaquant volait le cookie d’un autre utilisateur, il pourrait se faire passer pour celui-ci.
• Un code de carte bancaire est un nom d’utilisateur, puisqu’il permet d’identifier avec précision le propriétaire de la carte bancaire en question.

Il y a malheureusement plusieurs problèmes lorsqu’on se sert d’un nom d’utilisateur pour identifier les visiteurs.

• Les noms d’utilisateur sont stockés par le système. Une attaque sur le système qui parviendrait à obtenir cette liste de noms permettrait à l’attaquant de se faire passer pour n’importe quel utilisateur‒c’est la raison pour laquelle on évite de stocker les numéros de carte bleue sur les sites de vente en ligne, par exemple.
• Un nom d’utilisateur doit être unique (deux utilisateurs doivent avoir des noms différents). Si l’utilisateur a le choix de son nom, il peut découvrir qu’une autre personne porte le même nom et se faire passer pour elle. S’il n’a pas le choix de son nom, alors le nom qui lui est donné sera probablement difficile à retenir et sera donc probablement noté quelque part (le vol de cookies est un exemple typique de ce phénomène).
• Si la personne choisit son nom, ce sera souvent facile à deviner pour un attaquant à partir de ses informations publiques (nom, prénom, pseudonymes usuels, adresses électroniques). Si certaines cartes bancaires contiennent une partie de leur numéro au dos, c’est pour éviter qu’une photo de la face ne suffise à révéler l’identifiant complet.

Pour pallier à ces problèmes, on utilise souvent des mots de passe. Ceux-ci viennent compléter le nom d’utilisateur pour le rendre plus difficile à deviner, et sont par définition secrets et aléatoires pour qu’on ne puisse pas les déduire d’un nom, prénom ou pseudonyme. L’immense majorité des systèmes que l’on trouve sur les bureaux et sur internet utilisent une méthode combinant un nom d’utilisateur (unique, plus ou moins public, sert à identifier l’utilisateur) avec un mot de passe (quelconque, secret, sert à vérifier l’identité).

Une amélioration notable, qui permet de ne pas stocker les mots de passe sur le système, est l’utilisation des fonctions de hachage : ce sont des algorithmes qui transforment un mot de passe en un texte aléatoire. Retrouver le mot de passe à partir du texte aléatoire est proche de l’impossible, mais un mot de passe donné est
toujours transformé en un même texte aléatoire, et deux mots de passe différents donnent deux textes aléatoires différents, ce qui permet de s’assurer que le mot de passe fourni par l’utilisateur est le bon sans avoir à le stocker !

Pour autant, cette solution n’est pas parfaite :

• Certains systèmes persistent à enregistrer les mots de passe en clair. En effet, c’est la seule manière de pouvoir renvoyer le mot de passe à l’utilisateur si celui-ci le perd. Cependant, cela signifie que si le système est attaqué, les mots de passe des utilisateurs peuvent être découverts.
• Les mots de passe créent l’illusion que, puisqu’ils sont secrets, ils ne peuvent pas être devinés. Or, un mot de passe qui existe dans le dictionnaire ou peut être facilement deviné à partir d’informations publiques n’apporte pas une vraie sécurité. Encore pire, la tendance à utiliser le même mot de passe sur tous les sites fait qu’une faille de sécurité sur un site permet d’obtenir un mot de passe pour tous les autres.
• Il faut, pour s’identifier, envoyer le mot de passe au système. Un attaquant qui surveille le canal de communication peut donc en extraire le mot de passe et l’utiliser. De même, le phishing consistant à envoyer un courriel demandant le mot de passe d’un utilisateur permet de l’obtenir à faible coût.

Résoudre ces problèmes se fait à l’aide d’un système cryptographique à clé publique. Dans un tel système, les informations critiques ne quittent jamais l’ordinateur de l’utilisateur, ce qui fait qu’elles ne peuvent être ni interceptées, ni données par erreur, ni volées sur le serveur.

Le principe de ce système est simple : chaque utilisateur dispose d’une clé publique, distribuée à tout le monde sans crainte, qui permet de crypter du texte, et d’une clé privée, conservée précieusement dans le secret de l’ordinateur, qui permet de décrypter ce texte. On peut voir la clé publique comme un cadenas (n’importe qui peut prendre une copie du cadenas et verrouiller une boîte contenant un message), et la clé privée comme la clé du cadenas (seul l’utilisateur peut ouvrir une boîte et lire le message).

Pour vérifier qu’un utilisateur est bien le propriétaire d’une clé publique, on crypte un message aléatoire avec cette clé publique et on envoie le message crypté à l’utilisateur. L’utilisateur, s’il possède la clé privée, décrypte le message aléatoire d’origine. S’il ne possède pas la clé privée, il ne peut que deviner le message aléatoire, ce qui est proche de l’impossible. Donc, si le système voit revenir le message aléatoire qu’il avait choisi, il peut être certain que l’utilisateur qu’il a en face de lui est bien le propriétaire de la clé publique.

Lors de son inscription, l’utilisateur fournit au système sa clé publique, qui lui sert alors de nom d’utilisateur. Lors de chacune de ses visites, il affirmera être le propriétaire de cette clé et le système le vérifiera suivant le principe ci-dessus.

Malheureusement, ce système n’est pas facile à utiliser. Bien sûr, les explorateurs web sont déjà capables de travailler avec ce type de cryptographie pour s’assurer de l’identité d’un site‒pour toute adresse qui commence par HTTPS, l’explorateur vérifie que le serveur possède bien la clé privée correspondant à l’adresse. Ainsi, aucun attaquant ne pourra se faire passer pour le site HTTPS de votre banque sans que votre explorateur ne vous avertisse (il peut toutefois utiliser une adresse HTTP, donc non sécurisée, et espérer que vous ne vous en rendez pas compte).

Mais l’identification en sens inverse, donc s’identifier auprès d’un système avec sa paire de clés publique/privée, reste du domaine des geeks (qui l’utilisent par exemple pour faire du SSH) et apparaît très peu dans la vie courante. Utiliser des mots de passe, malgré un relatif manque de sécurité, restent rois. Toutefois, des initiatives comme celle du Ministère des Finances et de l’Economie en France, ou de la carte d’identité électronique en Belgique, commencent à rendre ce principe plus accessible.