Licence CC BY-SA

Le monde de la signature numérique

Du hachis à la place du gribouillis ?

Publié :

Vous avez sûrement déjà apposé à un chèque, un formulaire ou même votre carte d'identité ce gribouillis, tirant pour certains de la calligraphie qu'on appelle "signature".

La signature est un élément très important car elle permet d'assurer qu'une action administrative ou juridique a été réalisée par la personne qui prétend l'avoir réalisée.

Aujourd'hui, cependant, de plus en plus de documents n'ont aucun support physique, les factures elles-mêmes peuvent se contenter d'être un simple document PDF1. Le besoin de s'assurer que la personne émettant cette facture est bien celle qu'elle prétend être reste toujours d'actualité2, mais comment signer un document qui n'est pas couché sur papier ?


  1. À condition d'être acceptée préalablement par l'acheteur, une facture peut être émise par voie électronique et non sur support papier. Elle tient lieu de facture d'origine. vos-droit.fr 

  2. Outre de grandes entreprises qui ont été lestées de plusieurs millions d'euros, des particuliers se voient envoyer des fausses factures

Une question de communication

Comme la question de la signature est fortement liée à celle de la fraude, la question de la sécurité sera centrale. Et lorsque l'on parle de sécurité, il est toujours bon de savoir de quoi l'on parle pour savoir ce qu'on veut sécuriser.

La grande question à se poser sera alors : pourquoi avons-nous besoin d'une signature ?

Il est important de comprendre un concept fondamental dans notre situation : celui d'une communication entre deux entités. Cette communication a été très simplement schématisée par Shannon1 : elle met en relation un émetteur et un récepteur via un canal qui peut être parasité. Nous pourrons ajouter que ce canal peut être écouté par une personne à qui n'est pas destiné le message.

La personne qui reçoit le message s'appelle Ze Zeste, l'émetteur s'appelle Clem, et c'est Cornichon2 qui jouera le rôle du méchant3 :p .

Schéma de Shannon (modifié)

Dans le cadre de ce qui nous intéresse, on distingue trois grandes notions en ce qui concerne le message :

  • L'intégrité : le message que reçoit Ze Zeste doit être celui émis par Clem
  • La confidentialité : le message que reçoit Ze Zeste ne doit être lisible que par lui
  • L'authenticité : Ze Zeste doit être sûr que c'est bien Clem qui a envoyé le message et pas Cornichon qui se prend pour Clem.

La signature en soi ne va s'occuper (la plupart du temps) que de l'intégrité et de l'authenticité du message.

L'article 1316 du code civil4 définit la signature électronique comme l’usage d’un procédé fiable d’identification garantissant son lien avec l’acte auquel elle s’attache.

Revenons quelques secondes à la signature sur un document papier. Dans un monde parfait, chaque signature est unique et donc signer c'est bel et bien s'assurer que le signataire est celui qu'il prétend être.

De plus, par divers procédés, allant du cachet de la Poste (encore une signature tiens :p ), au duplicata envoyé à soi-même, on peut réussir à s'assurer que la signature a été apposée sur un document authentique.

L'analogie ne s'arrête pas là ! Pour apposer votre signature, il faut que le document réserve un espace blanc à cette dernière. Et il ne faut pas avoir une signature trop grosse sous peine d'écrire sur la table.

Pour un document électronique, c'est pareil. Le seul problème pour un document électronique, c'est que plus il est gros et plus il risque d'y avoir des erreurs dans sa transmission. Du coup si la signature prend trop de place, cette fois-ci on augmente le risque que le document reçu soit différent de celui émis5, dommage.

C'est pourquoi, pour créer une signature électronique, les créateurs de logiciels ont décidé de s'inspirer de ce qu'on appelle un algorithme de hachage.


  1. Sa biographie

  2. Pour connaître toute l'histoire

  3. Dans la littérature, vous entendrez surtout parler de Alice (Expéditeur), Bob (Destinataire) et Eve (Homme dans le milieu). 

  4. C'est l'article qui définit les usages légaux de documents électroniques. 

  5. Et ce malgré la mise en place de codes correcteurs

Une histoire de digestion

Certains auront peut-être détecté un jeu de mots dans ce titre, pour la simple et bonne raison que les anglophones ont tendance à appeler le résultat d'un algorithme de hachage un digest (ou hash).

L'idée de ces algorithmes est au départ de générer une structure de données qui certes peut prendre un peu d'espace en mémoire, mais qui aura des temps d'accès constants1. La représentation la plus simple de cette structure appelée table de hachage (ou HashTable) est le tableau avec un titre à chaque colonne.

Le principe de cette table, c'est de faire un tableau plein de vide, où les données ne seront pas très nombreuses. Mais elles seront placées d'une manière "spéciale". En fait pour ranger ces données, plutôt que de demander la case n°42 par exemple, vous allez demander la case "clémentine". Et le mot clémentine va être passé dans un algorithme de hachage qui va le transformer en un nombre qui représente le numéro de la case recherché. Du coup pour chercher la case "clémentine", seul le temps pris par l'algorithme de hachage compte.

bucket_table

Bucket Table (sur wikipédia, CC-BY-SA)

Je ne vais pas m'étendre sur les HashTable, mais on peut déjà remarquer quelques problèmes dans les algorithmes qui permettent de les construire.

Le nombre possible de mots est immense. Par exemple, en ne prenant que les 26 lettres minuscules de l'alphabet latin, il existe $26^{10} = 1,411670957\times10^{14}$ mots de 10 lettres (comme "clementine"), si votre algorithme ne donne un résultat que sur 32 bits, il n'y a que $ 2^{32} = 4 \times 10^9$ digests différents. Cela met en évidence une chose : il peut y avoir deux mots qui ont le même hash. Pire, leur simplicité fait que ces doublons (appelés collision) sont prévisibles ! Cela signifie deux choses si je connais le hash je peux créer une fausse signature qui a le même hash. Ce qui n'est pas l'effet recherché.

C'est pourquoi on a créé des algorithmes de hashage dits cryptographiques. Ils utilisent des calculs plus complexes qui rendent leur falsification presque impossible.

Les plus connus sont md5 et sha1 (qui sont de moins en moins utilisés aujourd'hui pour les applications de sécurité). En effet, grâce à la puissance grandissante des ordinateurs et à la baisse des prix du stockage, des tables qui rassemblent un nombre important de digest avec les mots qui les ont générés ont été créées. De ce fait en les utilisant, on peut réussir à générer une collision2.

Aujourd'hui, on utilise les algorithmes de type sha2 qui rassemblent des algorithmes tels que sha256 et sha512. Ces Secured Hash Algorithms sont validés par la NSA et plusieurs grandes organisations qui travaillent sur la sécurité. Leur principe est open source et leur implémentation dans les langages habituels aussi. Vous pouvez par exemple trouver leur description sur wikipédia.

Afin de prévoir le jour où ces algorithmes seront aussi cassés, la famille sha3 qui se base sur le principe d'une fonction éponge a été créée.


  1. Lorsqu'on crée des algorithmes qui manipulent des données on a tendance à les mettre dans des gros tableaux. Seulement pour trouver quelque chose dans un tableau, il faut le parcourir et si la donnée est à la fin, il faut parcourir toutes les cases. Avec une HashTable on trouve tout dans un temps qui ne dépend pas de la taille de la table. 

  2. Sans compter que des faiblesses au sein même de l'algorithme ont été trouvées qui démontrent qu'un calcul distribué des collisions est efficace. 

Assurer l'intégrité du document et de l'acte

Si je vous ai parlé des algorithmes de hachage cryptographiques, c'est avant tout car ils ont des propriétés intéressantes dans le cas de la signature de document.

En effet, le mieux pour s'assurer qu'un document est intègre c'est-à-dire qu'il n'a pas été modifié, même très légèrement, c'est qu'au moindre petit changement dans le document, le changement dans la signature doit être important.

Notons aussi qu'il faut que les algorithmes demandent une certaine quantité de ressources afin de s'assurer qu'une attaque par force brute1 ne sera pas utilisée pour découvrir des collisions.

Ces algorithmes sont très connus des gestionnaires de paquets. Ces derniers créent un hash du fichier avant son envoi. Puis une fois l'envoi terminé, ils vous communiquent le hash. Il vous suffit alors de calculer le hash et de vérifier qu'ils sont identiques2.

Pour le cas de notre document que nous allons signer, il ne faut pas oublier la notion "d'acte" qui est inscrite dans le temps. C'est le 4 mai 2015 à 14h42 que j'ai envoyé mon document, pas hier, pas demain. Si je veux que mon document soit une preuve irréfutable, il faut donc que l'heure de la signature y soit intégrée. L'horodatage se fait souvent grâce au timestamp unix, c'est à dire le nombre de secondes depuis le premier janvier 1970.


  1. Tester en masse des mots pour qu'ils donnent une collision. Cette technique peut se révéler viable grâce au paradoxe des anniversaires.  

  2. Les antivirus utilisent aussi cette technique pour détecter un virus. Néanmoins, pour éviter la propriété qui fait changer le hash au moindre changement, ils utilisent un fuzzy hash algorithm (en) 

Tout en assurant l'authenticité.

Le principal but d'une signature, c'est de dire que c'est bien la personne qui a signé qui a envoyé le document. Pour cela, il va falloir s'inspirer de ce qu'il se fait en cryptographie.

Il serait trop long de faire un exposé des principaux algorithmes qui permettent la signature électronique. J'ai pris le parti de vous en présenter un qui se base sur un mot de passe connu de l'expéditeur et du destinataire.

Cet algorithme s'appelle HMAC pour Hash based Message Authentication Code. Il s'exprime par la formule :

$$ HMAC = H((M_{ot de passe} \oplus o_{pad}) | H((M_{ot de passe} \oplus i_{pad})|M_{essage}) $$

En effet, comme l'acronyme nous l'indique, la fonction nommée H dans notre formule fait référence à un algorithme de hachage. On peut donc utiliser les outils déjà vus.

En pseudo-code, cela donnerait :

1
2
3
4
5
6
7
message = "Mon épée est vôtre / Mon arc est vôtre / Et ma hache MAC."
opad = 0x5c * X
ipad = 0x36 * X
mot_de_passe = string_vers_un_nombre_de_X_bits("Clem vaincra Cornichon")
i_pad_mdp = mot_de_passe XOR ipad
o_pad_mdp = mot_de_passe XOR opad
hmac = sha1(o_pad_mdp + sha(i_pad_mdp + message))

Le HMAC n'est pas forcément l'algorithme le plus sécurisé à cause du fait que la "clé privée" doit être connue des deux participants. On préférera utiliser des algorithmes qui se basent sur RSA pour signer un document puis faire certifier par une autorité de confiance que la clef publique n'est pas atteinte.

Le HMAC est une solution très simple qui permet d'éviter ce surcoût tout en s'assurant que votre document est intègre. Et imaginer une situation dans laquelle la clef est connue de vous et de votre destinataire n'est pas si compliqué.

Imaginez un service qui vend des "signatures numériques dans le cloud". Son intérêt sera que vous ayez un compte chez lui, ainsi que votre destinataire. Il stocke alors des versions hachées de vos clefs privées à chacun et lorsque vous signez un document, lui il peut attester que vous êtes celui que vous prétendez être.

Notons enfin que dans la plupart des cas, HMAC possède une faiblesse : comme le mot de passe est connu des deux côtés, ZeZeste peut prétendre que ce n'est pas lui qui a signé le message mais Clem, on dit que HMAC est répudiable.

Dans le sens inverse, si Clem n'était pas une personne aussi sympa on pourrait penser que parfois elle signe des documents à la place des gens, on dit qu'elle leur impute ces documents. Il est bien évidemment souhaitable qu'une signature ne soit pas imputable.

Le mot de la fin

Si le concept de signature numérique, qui pourtant peut permettre d'améliorer votre confiance en les mails, factures, ou toute communication que vous recevez est en expansion, son utilisation n'est pas encore très connue du grand public. En effet, les outils à dispositions manquent soit de facilité d'accès (gpg/pgp par exemple) ou demandent un coût financier très élevé (certificat). Surtout, la défiance est d'autant plus forte que si le fait de signer un papier est quelque chose d'observable (ne prend-on pas en photo les mariés qui signent le registre d'état civil ?) la signature numérique se passe dans une boîte noire. Il faut donc en plus faire confiance aux logiciels et l'actualité nous a plus d'une fois montré les cas de failles volontaires ou non dans ces derniers.

Sources


26 commentaires

Dans la littérature, vous entendrez surtout parler de Alice (Expéditeur), Bob (Destinataire) et Charles (Homme dans le milieu).

Je n'a jamais vu Charles utilisé dans ce genre de chose. Dans le cas d'un attaquant qui ne fait qu'écouter j'ai toujours vu Eve. Et Wikipedia semble d'accord. Est-ce une version purement français différente de ce que l'on trouve habituellement ?

Le principal but d'une signature, c'est de dire que c'est bien la personne qui a signé qui a envoyé le document. Pour cela, il va falloir s'inspirer de ce qu'il se fait en cryptographie.

Personnellement, dans le cadre d'un échange numérique, j'ai du mal à parler de personne, mais plutôt d'identité. Je m'explique. En ce monde numérique, nous avons tou-te-s plusieurs identités, plus ou moins étanches les unes aux autres. Il me semble donc plus appropriés de dire que de telles signatures garantissent l'identité, non au sens de l'identité civile mais bien en tant qu'identificateur assez générale (le méchant Cornichon est l'une de mes identités) de l'expéditeur d'un message.

Ça apporte d'ailleurs plusieurs problématiques, notament le fait qu'une identité ne soit pas unique contrairement à la notion de personne. Ce qui permet d'introduire la nécéssité d'une authorité de certification pour celles et ceux qui aiment la centralisation, ou des mécanismes comme la signature des clefs PGP/GPG.

+3 -0
Staff

Je n'a jamais vu Charles utilisé dans ce genre de chose. Dans le cas d'un attaquant qui ne fait qu'écouter j'ai toujours vu Eve. Et Wikipedia semble d'accord. Est-ce une version purement français différente de ce que l'on trouve habituellement ?

Possible, les livres de crypto que j'ai lu étaient d'édition française. je mets ça à jour dans l'article.

+0 -0
Staff

Deuchnord est le seul et unique responsable. :-°

Après, évidemment, merci à artragis pour cet article. Gageons que l'actualité incitera le grand public à penser à signer numériquement les mails, etc. Notamment, pour toute communication un peu sensible (comme un échange mail entre un avocat et son client) où l'usage n'est pas spécialement très répandu (déjà que des boulettes surviennent, du genre envoyer au mauvais destinataire des documents importants (j'ai reçu quelques fois des mails de ce type)). Maintenant, il faudrait des solutions efficaces et simples à mettre en place.

Édité

Staff

Maintenant, il faudrait des solutions efficaces et simples à mettre en place.

plus qu'à mettre en place, elles doivent être simples à utiliser.

Aujourd'hui pas mal de gens utilisent les webmails plutôt que les outlook ou thunderbird et dans le cas de outlook c'est encore pire puisque les extensions installées sont décidées par l'entreprise.

Bref, aujourd'hui, il faudrait réussir à faire un truc compatible gmail, orange, sfr, yahoo, live plus des extensions thunderbird (bien que le logiciel n'évolue plus beaucoup) et avoir l'assiette suffisamment stable pour que des entreprises fassent confiance.

Le système de réseau de confiance pgp/gpg (gpg est la version libre de pgp pour faire simple) est puissant mais aucun logiciel ne les intègre de manière ergonomique. Faut quand même se dire que le fait que chaque personne doive définir un niveau de confiance en chacun puis ensuite signer la signature de l'autre pour réuploader ça dans un réseau public etc. c'est juste la merde.

Restent les certificats. Et là à part l'EFF (Electonic Frontier Foundation) qui a pour but de fournir un certificat SSL à tout le monde (mais du coup on sait pas si on peut leur faire confiance…) il faut payer, cher, et parfois il faut toucher à des problèmes de sysadmin pour gérer la durée de validité du certificat en plus de celle de la signature.

Bref, aujourd'hui on est vraiment dans la merde du point de vue de la "simplicité d'utilisation".

+0 -0

Gageons que l'actualité incitera le grand public à penser à signer numériquement les mails, etc.

Arius

Étrangement, je ne suis pas d'accord. Signer numériquement ces échanges, c'est un geste fort, où l'on prouve que l'on a bien écrit tel ou tel chose et où on ne peut plus dire le contraire. Sans pour autant masquer le contenue du message qui passe toujours en clair.

Dans le climat actuel, au contraire, j'inciterais les gens à chiffrer mais à ne surtout pas signer ses messages, encore plus lorsque c'est dans des conversations militantes ou subversives. Un mécanisme assez sympa pour chiffrer une conversation et pouvoir nier l'avoir écrit en cas de problème serait quelque chose comme OTR, ce qu'on utilise en général pour chiffrer de la messagerie instannée.

OTR présente plusieurs avantages, dont une facilités d'utilisation déconcertante puisque l'on échange des clefs en début de conversation à l'aide du forward secrecy. Il faut bien voir néanmoins que ça ne garantie pas les mêmes choses qu'une signature GPG.

Mais dans le climat actuel, garder une porte de sortie, et ne pas prouver systématiquement son identité, tout en masquant les messages, me semble une bonne chose.

+1 -0
Staff

Pourtant, tu as pas mal d'exemples où cette signature est utile (je n'irais pas jusqu'à dire "nécessaire"). Après, c'est à chacun de voir, au cas par cas, s'il faut signer ou chiffrer. La signature a de l'importance dans le cas d'échange où de toute façon ton identité est connue (envers un notaire, un huissier, une institution ou un avocat par exemple) et où la validité a une certaine importance.

C'est bien pour ça que je n'ai pas cité la partie où tu parlais d'un avocat, mais bien du grand publique en général, qui j'espère va s'indigner et communiquer de manière subversive !

+0 -0

Quelques petits commentaires…

  • Par rapport aux noms conventionnels: Eve est bien le standard anglophone pour une tierce personne qui se contente d'intercepter les messages; dans le cas d'un attaquant actif (cas qui nous intéresse ici, car l'attaquant cherche à falsifier des signatures), on rencontre souvent Oscar (opponent) ou Mallory (malicious).

pour créer une signature électronique, les créateurs de logiciels ont décidé de s'inspirer de ce qu'on appelle un algorithme de hachage.

  • Les créateurs de logiciels sont bien gentils, mais la notion de signature électronique est apparue dans la communauté cryptographique universitaire à la fin des années 70 (voir ici). Et puis ça utilise comme brique élémentaire, plutôt que s'inspire de, un algorithme de hachage, non ? D'ailleurs, je trouve l'explication des tables de hachages peu pertinente dans le cadre de cet article: il s'agit bien d'une autre application des fonctions de hachage, mais leur utilisation en signature électronique n'a que peu à voir avec ce qui en est fait là.

  • Problème dans les exposants en $\LaTeX$

  • Aucune version de SHA-2 n'est prévue en 128 bits par la spécification officielle (il s'agirait plutôt de SHA-1, ou alors d'un SHA-2 tronqué: à éviter !)

  • Il serait intéressant de développer l'aspect « insécure » du HMAC en tant que signature: elle est falsifiable (par ZeZeste) et répudiable (puisque justement Clem peut toujours affirmer que c'est l'autre qui a émis une signature qu'il souhaite répudier), donc ne permet pas d'associer le message à une identité comme voulu (chose que fait effectivement la « vraie » signature électronique).

Édité

+0 -0
Staff

Merci pour ce commentaire spngegab.

Pour l'aspect insecure de HMAC, en effet je suis obligé de faire mon mea culpa de ne pas avoir parlé de la non répudiabilité et de la non imputabilité. J'ai choisi au départ de parler du triptique authenticité/confidentialité/intégrité et je me suis laissé coincer dedans comme un bleu, désolé.

Pour sha128, petite confusion de ma part.

Pour le latex, la correction a été lancée hier soir et validée cette nuit théoriquement.

Encore merci pour ta lecture attentive :)

+0 -0

Merci pour cet article.

En fait je dois dire que cet article m'a plus embrouillé qu'autre chose (j'ai l'impression de savoir approximativement comment ça fonctionne mais de ne pas comprendre des parties de l'article).

Avant, dans ma tête ça fonctionnait comme suit.

Une fonction de signature (il doit y en avoir une par identité) est une fonction telle que le propriétaire est le seul à pouvoir la calculer et que tout le monde (ou par exemple uniquement le destinataire) peut vérifier qu'un message a une signature donnée.

Par exemple, supposons que l'on dispose des deux choses suivantes.

  • Un procédé de chiffrement tel que je suis le seul à pouvoir chiffrer et mon destinataire peut déchiffrer.
  • Une fonction de hachage pour compacter le message de manière « unique » (un message modifié ne doit pas avoir le même hash). Mais ici, on s'en fiche de la propriété que le message n'est pas calculable à partir du hash.

Pour calculer la signature d'un message, je hache mon message puis je chiffre le hash.

Du coup :

  • la signature n'est pas trop grosse,
  • il n'est pas possible de modifier le message sous peine de devoir modifier la signature correspondante,
  • je suis le seul à pouvoir apposer ma signature et
  • mon destinataire peut vérifier que la signature correspond bien au message en déchiffrant la signature et en comparant avec le hash du message.

Concernant l'article, je n'ai plus rien compris avec la phrase suivante.

Cela signifie deux choses si je connais le hash je peux créer une fausse signature qui a le même hash.

Je m'embrouille dans les hypothèses de ce que pourrait vouloir dire la phrase… Dans quel contexte est-on ?

Et à quoi sert le fait que la signature doit varier beaucoup si on fait un peu varier le message ? C'est à cause des parasites ? Le message n'est-il pas de toute façon invalidé s'il ne correspond pas à la signature ?

Édité

+0 -0

L'article est intéressant, domage pour la non-répudiation, c'est un gros point.

à quoi sert le fait que la signature doit varier beaucoup si on fait un peu varier le message ? C'est à cause des parasites ? Le message n'est-il pas de toute façon invalidé s'il ne correspond pas à la signature ?

Idéophage

Le risque, si ça change juste un peu, c'est que deux modifications sur le document annulent les modifications du hash, du coup la signature est valide pour un document modifié (et le signataire ne peut pas nier avoir signé à cause de la non-répudiation de la signature :p ).

Édité par Xia

Xia, peluche olympienne |Python en s'amusant | Random xkcd

+0 -0

Ah, oui, merci Xia pour cette explication. C'est le « beaucoup » que je ne comprenais pas. En fait c'est une conséquence du fait qu'il y a plus de hashs proches que de hashs éloignés d'un hash donné. Ainsi, si on répartit de manière aléatoire, les hashs éloignés vont être plus touchés.

Un autre truc que je ne comprends pas dans l'article.

Il stocke alors des versions hachées de vos clefs privées à chacun et lorsque vous signez un document, lui il peut attester que vous êtes celui que vous prétendez être.

(Toujours avec HMAC, hein.) Pourquoi les versions hachées ? Il faut bien que le service puisse calculer les signatures pour pouvoir les vérifier, non ? À moins que l'on ne donne au service, à chaque message signé, notre clef ainsi que la signature et que le service vérifie que la clef est bonne avec le hash puis vérifie la signature avec la clef ?

Et je ne comprends toujours pas l'autre truc.

Édité

+0 -0
Staff

(Toujours avec HMAC, hein.) Pourquoi les versions hachées ? Il faut bien que le service puisse calculer les signatures pour pouvoir les vérifier, non ? À moins que l'on ne donne au service, à chaque message signé, notre clef ainsi que la signature et que le service vérifie que la clef est bonne avec le hash puis vérifie la signature avec la clef ?

Parce qu'une directive de base en sécurité c'est de ne jamais stocker une version en claire d'un mot de passe. Lorsqu'on est avec RSA, ce n'est pas l'autorité de confiance qui stocke ta clef privée, c'est toi. La situation que je propose décrit le moment où c'est le service qui possède tout, pas l'utilisateur. Comme on est dans un chiffrement symétrique, il faut que le service s'assure que c'est bien la personne qui veut signer qui signe. Ainsi, cette personne déclanche la procédure de signature en entrant son mdp qui est comparé au hash stocké et si c'est bon, on fait le HMAC.

Comme je l'ai dit, cette solution n'est pas parfaite, c'est juste un moyen de montrer au gens que les choses ne sont pas "magiques" et surtout que malgré la "boîte noire" que sont les logiciels, les outils utilisés sont vérifiables par tout le monde.

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte