Brevet FR2720209A1 — publié le 19951124

PROCEDE DE REALISATION D'UNE TRANSACTION ELECTRONIQUE SECURISEE DESCRIPTION Domaine technique La présente invention a pour objet un procédé de réalisation d'une transaction électronique sécurisée. L'invention porte plus spécialement sur des transactions électroniques établies entre deux entités, au cours desquelles des données sont échangées de façon à assurer leur authenticité (terme qui, dans la suite, couvrira les notions d'intégrité, c'est-à-dire de non- altération, et de non-duplication). L'invention peut trouver une application dans le payement électronique, par exemple par carte à microprocesseur. Etat de la technique antérieure Dans les transactions électroniques, l'authenticité des données échangées est habituellement garantie par une signature électronique de ces données. Le terme "signature électronique" doit être entendu ici au sens large: cette signature peut être obtenue à l'aide de mécanismes cryptographiques divers, à savoir des mécanismes de chiffrement, ou d'authentification, ou de signature au sens propre du terme. Elle peut être calculée à l'aide d'un algorithme symétrique (auquel cas la clé secrète de signature est, d'une façon ou d'une autre, partagée par les entités impliquées dans la transaction) ou à l'aide d'un algorithme asymétrique (auquel cas la clé secrète de signature n'est connue que de l'entité signataire). Chaque entité dispose donc de moyens pour produire une signature électronique, ces moyens se décomposant traditionnellement en un algorithme de production et une clé secrète, en ce sens qu'elle n'est connue que de cette entité ou des deux entités impliquées dans la transaction (selon les modes de réalisation). De façon globale, on désignera par fA la fonction qui, à partir de données D, fournit une signature électronique fA(D) de ces données par l'entité A. De même, fB(D) désignera la signature électronique des données D par l'entité B. Afin que la signature de chaque entité puisse être vérifiée par l'autre, il faut également supposer que les entités A et B disposent de moyens cryptographiques qui leur permettent de vérifier les signatures produites par l'autre entité. Ces moyens se décomposent traditionnellement en un algorithme de vérification et une clé secrète partagée par les deux entités ou bien une clé publique liée à l'entité signataire (selon les modes de réalisation). Une transaction électronique sécurisée typique se déroule alors en trois opérations ou échanges: i) l'entité B envoie à l'entité A des données D1 (et éventuellement une signature Sl de tout ou partie de ces données). ii) l'entité A envoie à l'entité B des données D2 et calcule une signature S2 portant sur tout ou partie des données D1, D2. iii) l'entité B envoie à l'entité A des données D3 et calcule une signature S3 portant sur tout ou partie des données D1, D2, D3. A chaque échange, l'entité réceptrice vérifie la signature qu'elle reçoit. Dans certains cas, la transaction ne contient qu'une partie de ces échanges. Dans d'autres, elle contient des échanges supplémentaires. Les données D1, D2, D3 peuvent contenir des informations de nature très variable. En particulier, outre les identités des entités impliquées (qu'on notera par la suite Ai et Bi) et les informations caractéristiques de la transaction, ces données peuvent contenir des paramètres variant avec le temps. Le rôle de ces paramètres est de lutter contre les rejeux, c'est-à-dire contre les attaques consistant à épier une transaction légitime entre deux entités, puis à entamer une transaction illégitime avec l'une de ces entités en réutilisant tout ou partie des données et des signatures épiées lors de la transaction légitime. Lorsque les données à signer sont nombreuses, la durée de la transaction peut se trouver exagérément allongée, surtout lorsque les entités impliquées, ou même seulement l'une d'entre elles, dispose(nt) de moyens de calculs rudimentaires (par exemple lorsqu'il s'agit de cartes à microcircuit). La présente invention a justement pour but de remédier à cet inconvénient. Exposé de l'invention A cette fin, l'invention propose un procédé qui réduit le nombre des calculs à effectuer. L'invention part de cette observation qu'il y a souvent une grande quantité de données communes entre celles qui doivent être signées par l'entité A au deuxième échange, et celles qui doivent être signées par l'entité B au troisième échange. Dans ces conditions, l'invention propose, lors du troisième échange, au lieu de signer l'ensemble des données dont il faut protéger l'authenticité, de faire signer à l'entité B tout ou partie de la signature S2 que l'entité A a déjà produite lors du deuxième échange, ainsi que les données "restantes", c'est-à-dire celles que l'entité A n'a pas déjà signées au deuxième échange mais que l'entité B doit signer. Ainsi, au lieu de calculer S3=fB(D) o D est l'ensemble des données D1, D2, D3, l'entité B a seulement besoin de calculer S3=fB(S'2,Dr) o S'2 désigne tout ou partie de la signature S2 et Dr désigne les données restantes. Le calcul nécessaire à la vérification se réduit dans la même proportion. Un cas particulier est celui o il n'y a pas de données restantes, auquel cas S3=fB(S'2). Ainsi, le calcul de la signature S3 peut-il se trouver très réduit, ainsi que la durée totale de la transaction. Par ailleurs, le procédé de l'invention permet de résoudre le problème qui se pose (uniquement avec les algorithmes symétriques) lorsque les entités A et B utilisent la même clé pour calculer leurs signatures et qu'elles ont à signer les mêmes données. Dans ce cas, S3 serait identique à S2 si l'invention n'était pas utilisée, et serait donc sans valeur (il suffirait à une fausse entité -B de répéter la signature qu'elle a reçue de l'entité A). En utilisant l'invention, ce problème se trouve ipso facto résolu. De plus, il se peut que l'utilisation même du procédé de l'invention, ait pour effet de réduire le nombre de données que l'entité A doit envoyer et éventuellement signer. Par exemple, si, dans les données envoyées (et éventuellement signées) par l'entité A, se trouve un nombre aléatoire, alors la partie S'2 de la signature S2 peut, dans l'invention, jouer ce rôle de nombre aléatoire et cela évite à l'entité A de l'envoyer et (éventuellement) de le signer. De façon précise, la présente invention a donc pour objet un procédé de réalisation d'une transaction électronique sécurisée entre une entité A et une entité B, ce procédé comprenant une opération pendant laquelle l'entité A calcule une signature (S2), l'entité B vérifiant cette signature et une opération pendant laquelle l'entité B calcule une signature (S3) l'entité A vérifiant cette signature, ce procédé étant caractérisé par le fait que l'entité B calcule une signature (S3) portant notamment sur une partie au moins de la signature (S2) précédemment calculée par l'entité A. Selon un mode de mise en oeuvre, le procédé comprend les trois opérations suivantes, la première étant optionnelle: i) l'entité B envoie à l'entité A des premières données (D1), ii) l'entité A envoie à l'entité B des deuxièmes données (D2) et calcule une signature(S2) portant sur au moins une partie des premières et deuxièmes données (D1, D2), l'entité B vérifiant cette signature, iii) l'entité B envoie à l'entité A des troisièmes données D3 et calcule une signature (S3), l'entité A vérifiant cette signature (S3) calculée par l'entité B. Dans ce cas, le procédé de l'invention est caractérisé par le fait que la signature (S3) calculée par l'entité B lors de la troisième opération (iii) porte sur une partie au moins (S'2) de la signature (S2) calculée par l'entité A lors de la deuxième opération (ii) et sur la partie des données que l'entité B doit signer lors de la troisième opération (iii) que l'entité A n'a pas déjà signées lors de la deuxième opération (ii). Exposé détaillé de modes de réalisation A titre d'exemple, on va décrire trois transactions qui tirent bénéfice de la présente invention, avec un nombre de calculs réduit, sans que soit abaissé le niveau de sécurité. Le premier exemple est celui d'un protocole d'authentification d'entité issu de la norme ISO/IEC 9798-4 (actuellement au stade d'avant- projet) intitulée "Entity authentification using a cryptographic check- function"). Cette norme décrit des protocoles d'authentification à base d'un algorithme symétrique de signature. Il s'agit du protocole décrit dans le paragraphe 5.2.2, dont l'objet est de réaliser une authentification mutuelle entre A et B (qui partagent une clé secrète KAB) en trois échanges ainsi décrits: i) l'entité B envoie à l'entité A un nombre RB et des données intitulées Textl. ii) L'entité A envoie à l'entité B des données, constituées d'un nombre RA et de données intitulées Text3, ainsi que la signature des données constituées de RA, RB de l'identité Bi de B et de données intitulées Text2. En d'autres termes, on a: S2=fA(RA, RB, Bi, Text2) o fA est calculée avec la clé secrète KAB partagée par les entités A et B. La signature S2 est vérifiée par l'entité B à l'aide de cette même clé. iii) L'entité B envoie à l'entité A des données intitulées Text5 ainsi que la signature des données constituées de RB, de RA et de données Text4. En d'autres termes on a: S3=fB(RB, RA, Text4) o fB est également calculée avec la clé secrète partagée par les entités A et B (dans ce cas particulier: fB=fA). La signature S3 est vérifiée par l'entité A à l'aide cette même clé. Si l'on remplace S3 par S'3=fB(S2, Text'4) o Text'4 désigne les données de Text4 qui ne sont pas déjà incluses dans Text2, alors le temps de production de la signature se trouve réduit et le temps de vérification également. Si, par exemple fB est calculée à partir de l'algorithme de chiffrement DES dans le mode décrit dans la norme ISO 9797 (mode apparenté au mode CBC de l'algorithme DES) avec une longueur de signature égale à 64 bits et si l'on suppose, pour fixer les idées, que le temps d'exécution d'un DES est de 50 ms, et que les nombres aléatoires ont une longueur de 64 bits, alors l'invention permet d'économiser 2.50 ms=100 ms au minimum sur le temps total de la transaction et, plus généralement 2(t+1).50 ms o t est le nombre de blocs de 64 bits, le dernier éventuellement incomplet, contenus dans les données communes à Text2 et Text4. Si Text2=Text4, alors Text'4 est vide et l'on a économisé 2(t+1).50 ms o t est le nombre de blocs de 64 bits de Text2. De plus, si l'on fait jouer à S2 le rôle de RA, alors les données envoyées à l'étape (ii) peuvent se réduire à Text3 et S2=fA(RB, Bi, Text2), ce qui permet d'économiser la transmission de RA (64 bits) et deux exécutions DES supplémentaires (100 ms) pour le calcul de S2 et pour la vérification. Les nombres RA et RB peuvent être des nombres aléatoires tirés par les entités A et B ou des nombres incrémentés chaque fois que l'entité correspondante participe à un échange avec l'autre. Le deuxième exemple est celui d'un échange de monnaie électronique entre une entité A habilitée à être créditée et une entité B habilitée à être débitée. Cet échange est supposé utiliser un algorithme symétrique. Un tel échange est décrit par un projet de norme du CEN, et est analogue au protocole précédent, à ceci près que le paramètre variant avec le temps n'est pas un nombre aléatoire mais le contenu d'un compteur détenu par chacune des entités, et incrémenté à chaque fois que cette entité participe à un échange de monnaie électronique. Avec les notations de la norme 9798-2, cet échange est tel que Text2 est peu différent de Text4, chacun de ces champs contenant les deux valeurs des compteurs définis ci- dessus. Dans un échange typique, on a t=2, et l'on a alors économisé 2.(2+1).50 ms=0,3 s, ce qui est important quand on sait qu'un échange de monnaie électronique ne devrait pas durer plus d'une seconde. On résout également le problème mentionné plus haut, qui se pose dès lors que les entités A et B ont les mêmes données à signer et qu'elles utilisent la même clé pour calculer cette signature. Le troisième exemple est celui d'un protocole d'authentification d'entité issu de la norme ISO/IEC 9798-3 intitulée "Entity authentification using a public key algorithm". Cette norme décrit des protocoles d'authentification à base d'un algorithme asymétrique de signature. Il s'agit du protocole décrit dans le paragraphe 5.2.2 dont l'objet est de réaliser une authentification mutuelle entre A et B en trois échanges ainsi décrits: i) l'entité B envoie à l'entité A un nombre RB et des données intitulées Textl. ii) L'entité A envoie à l'entité B des données constituées d'un nombre RA, de l'identité Bi de B et de données intitulées Text3, ainsi que la signature des données RA, RB, Bi et de données intitulées Text2. En d'autres termes, on a: S2=fA(RA, RB, Bi, Text2) o fA est calculée avec la clé secrète de signature de A. La signature S2 est vérifiée par B avec la clé publique correspondante. iii) L'entité B envoie à l'entité A des données constituées de RB, RA, de l'identité Ai de A et de données intitulées Text5, ainsi que la signature des données RB, RA, A et de données intitulées Text4. En d'autres termes, on a: S3=fB(RB, RA, Ai, Text4) o fB est calculée avec la clé secrète de signature de B. La signature S3 est vérifiée par A avec la clé publique correspondante. Là encore RA et RB peuvent être des nombres aléatoires ou incrémentés. Si l'on remplace S3 par S'3=fB(S'2, Ai, Text'4), O S'2 désigne une partie de S2 de même longueur que RA ou RB et o Text'4 désigne les données de Text4 qui ne sont pas déjà incluses dans Text2, alors le temps de production de la signature se trouve réduit et le temps de vérification également. Si, par exemple, fA et fB sont calculées en condensant préalablement les données à signer avec une fonction de hachage telle que celle décrite dans la norme 10118-2 (en option "double longueur" et avec DES) et si l'on suppose, pour fixer les idées, que le temps d'exécution d'un DES est de 50 ms et que les nombres aléatoires ont une longueur de 64 bits, alors l'invention permet d'économiser 2.2.50 ms=200 ms minimum et, plus généralement, 4(t+1).50 ms o t est le nombre de blocs de 64 bits, le dernier éventuellement incomplet contenu dans les données communes à Text2 et Text4. Si Text2=Text4, alors Text'4 est vide et l'on a économisé 4(t+1).50 ms o t est le nombre de blocs de 64 bits de Text2. De plus, si l'on fait jouer à S'2 le rôle de RA, alors les données envoyées à l'étape (ii) peuvent se réduire à RB, B, Text3 et S2=fA(RB, B, Text2), ce qui permet d'économiser la transmission de RA (64 bits) et quatre exécutions supplémentaires de DES (200 ms), pour le calcul de S2 et pour sa vérification. l1 REVENDICATIONS 1. Procédé de réalisation d'une transaction électronique sécurisée entre une entité A et une entité B, ce procédé comprenant une opération pendant laquelle l'entité A calcule une signature (S2), l'entité B vérifiant cette signature et une opération pendant laquelle l'entité B calcule une signature (S3) l'entité A vérifiant cette signature, ce procédé étant caractérisé par le fait que l'entité B calcule une signature (S3) portant notamment sur une partie au moins de la signature (S2) précédemment calculée par l'entité A. 2. Procédé selon la revendication 1 comprenant les opérations suivantes, la première étant optionnelle: i) l'entité B envoie à l'entité A des premières données (D1), ii) l'entité A envoie à l'entité B des deuxièmes données (D2) et calcule une signature(S2) portant sur au moins une partie des premières et deuxièmes données (Dl, D2), l'entité B vérifiant cette signature, iii) l'entité B envoie à l'entité A des troisièmes données D3 et calcule une signature (S3), l'entité A vérifiant cette signature calculée par l'entité B, ce procédé étant caractérisé par le fait que la signature (S3) calculée par l'entité B lors de la troisième opération (iii) porte sur une partie au moins (S'2) de la signature (S2) calculée par l'entité A lors de la deuxième opération (ii) et sur la partie des données que l'entité B doit signer lors de la troisième opération (iii) que l'entité A n'a pas déjà signées lors de la deuxième opération (ii). 3. Procédé selon la revendication 2, dans lequel l'entité A et l'entité B partagent une même clé secrète (KAB) permettant à chaque entité de calculer les signatures, ce procédé étant caractérisé par le fait qu'il comprend les trois opérations suivantes: i) l'entité B envoie à l'entité A des premières données (D1) constituées par un nombre RB et des données intitulées Textl, ii) l'entité A envoie à l'entité B des deuxièmes données (D2) constituées d'un nombre RA et de données intitulées Text3, l'entité A calcule à l'aide de la clé secrète (KAB) une signature (S2) portant sur les données RA et RB, sur l'identité Bi de l'entité B et des données Text2, l'entité B vérifiant cette signature à l'aide de la même clé (KAB), iii) l'entité B envoie à l'entité A des troisièmes données (D3) constituées par des données intitulées Text5 et calcule, à l'aide de la clé (KAB), une signature (S3) portant sur la partie non commune (Text'4) entre les données que l'entité B doit signer et les données Text2 qui ont déjà été signées par l'entité A, l'entité A vérifiant cette signature à l'aide de la clé secrète (KAB). 4. Procédé selon la revendication 3, caractérisé par le fait que les nombres RA et RB envoyés respectivement par les entités A et B sont des nombres aléatoires tirés respectivement par les entités A et B. 5. Procédé selon la revendication 3, caractérisé par le fait que les nombres RA et RB envoyés respectivement par les entités A et B sont des nombres qui sont incrémentés respectivement par l'entité A et par l'entité B chaque fois que l'entité correspondante participe à un échange avec l'autre. 6. Procédé selon la revendication 3, dans lequel l'entité A est pourvue d'une première clé secrète de signature (fA) à laquelle correspond une première clé publique, et l'entité B est pourvue d'une seconde clé secrète de signature (fB) à laquelle correspond une seconde clé publique, ce procédé étant caractérisé par le fait qu'il comprend les trois opérations suivantes: i) l'entité B envoie à l'entité A des données (D1) constituées par un nombre RB et par des données intitulées Textl, ii) l'entité A envoie à l'entité B des données (D2) constituées par un nombre RA, par ledit nombre RB envoyé par l'entité B, par l'identité Bi de l'entité B, et par des données intitulées Text3 et calcule en utilisant la première clé secrète (fA) une signature portant sur RA, RB, Bi, et des données intitulées Text2, l'entité B vérifiant cette signature à l'aide de la première clé publique, iii) l'entité B envoie à l'entité A des troisièmes données (D3) constituées par les nombres RB et RA, par l'identité Ai de l'entité A et par des données de texte intitulées Text5, et calcule, à l'aide de la seconde clé secrète (fB) la signature (S3) d'une partie de la signature (S2) calculée par l'entité A lors de l'opération précédente (ii), de l'identité Ai de l'entité A et de la partie non commune entre les données Text2 et des données Text4 que l'entité B doit signer, l'entité A vérifiant cette signature à l'aide de la seconde clé publique. 7. Procédé selon la revendication 6, caractérisé par le fait que les nombres RA et RB sont des nombres aléatoires tirés respectivement par les entités A et B. 8. Procédé selon la revendic ation 6, caractérisé par le fait que les nombres RA et RB sont des nombres incrémentés respectivement par l'entité A et par l'entité B, chaque fois que l'entité correspondante participe à un échange avec l'autre. 9. Procédé selon l'une quelconque des revendications 2 à 8, caractérisé par le fait que l'entité B ne devant signer lors de la troisième opération (iii) que des données qui ont déjà été signées par A dans la deuxième opération (ii), la signature (S3) calculée par l'entité B ne porte que sur une partie au moins de la signature (S2) produite par l'entité A au cours de la deuxième opération (ii). 10. Procédé selon l'une quelconque des revendications 2 à 9, caractérisé par le fait que dans la première opération (i) l'entité B calcule une signature (S1) portant sur une partie au moins des premières données (Dl), et envoye cette signature à l'entité A, celle-ci vérifiant la signature (Sl). 11. Procédé selon l'une quelconque des revendications 2 à 10, caractérisé par le fait que, dans les données envoyées par l'entité A se trouve un nombre aléatoire, et que la partie (S'2) de la signature (S2) joue le rôle de ce nombre aléatoire, l'entité A n'envoyant pas ce nombre aléatoire.