CALMELS BENOIT (FR)
CANARD SEBASTIEN (FR)
PICQUENOT DAVID (FR)
SAIF AHMAD (FR)
SIBERT HERVE (FR)
CALMELS BENOIT (FR)
CANARD SEBASTIEN (FR)
PICQUENOT DAVID (FR)
SAIF AHMAD (FR)
WO2001046920A1 | 2001-06-28 | |||
WO2002097736A1 | 2002-12-05 |
US6467685B1 | 2002-10-22 | |||
EP0833285A2 | 1998-04-01 |
Notons que dans la suite de n jetons se trouvent en fait n+1 éléments : ceci est dû au fait que divulguer W0 ne prouve rien sur la connaissance de la suite, puisqu'il ne permet de calculer aucun autre jeton de la suite que lui-même. Dans les utilisations usuelles des suites de jetons, l'élément W0 sert de point de départ dans l'utilisation de la suite, afin d'enregistrer ou d'identifier celle-ci.
Lorsque des jetons d'une suite de jetons (w0, Wi Wn) ont été divulgués, alors, en notant w,- le jeton de plus haut indice déjà divulgué, on peut calculer uniquement les jetons (w0, Wi, ..., wj) de la suite. Si un nouveau jeton de cette suite est divulgué, on donne une valeur à ce jeton, qui est proportionnelle au nombre de jetons de la suite qu'on peut déduire facilement et qui sont autres que W0, Wi,... et w,-. Par exemple, si le jeton w,+i est divulgué, il ne permet de déduire aucun jeton non déjà connu autre que lui-même. On attribue donc à la divulgation de ce jeton une valeur, qu'on appelle une unité. Si c'est le jeton Wi+2 qui est divulgué, les nouveaux jetons de la suite qu'on peut déduire sont lui- même et le jeton w,+i. On attribue donc une valeur de 2 unités à la divulgation de W/+2 si seuls Wo, w-i,...et w,- étaient connus. Si un jeton Wj est divulgué, avec y ≤ /, alors cette divulgation n'a aucune valeur, car le jeton était déjà connu. La valeur des nouveaux jetons vient du fait qu'on peut vérifier que ces jetons sont corrects en les corrélant aux jetons déjà connus. Par conséquent, la divulgation d'un jeton d'une suite dont on ne connaît aucun autre jeton n'a pas de valeur. C'est pour cette raison que la divulgation de W0 n'a pas de valeur, comme nous l'avons dit.
Il est aussi possible de considérer que chaque jeton représente une unité de compte. Ainsi, si le jeton w,- a déjà été divulgué / dépensé, la divulgation du jeton Wj+i correspond à la dépense d'une unité de compte puisque cette divulgation permet de déduire un jeton supplémentaire. Et, pour reprendre l'exemple ci-dessus, la divulgation du jeton Wi+2 correspond à la dépense de deux unités de compte puisqu'il est alors possible de déduire deux jetons supplémentaires. Les suites de jetons ayant les propriétés indiquées ci-dessus peuvent être construites de différentes façons. Un mode de réalisation privilégié est le suivant. Puisqu'il est facile de calculer tout jeton d'indice précédant l'indice d'un jeton donné, il faut commencer par calculer le jeton Wn, puis générer consécutivement les jetons wn-i W0. Pour cela, le jeton Wn est un nombre aléatoire qui doit être cryptographiquement sûr, c'est-à-dire qu'il faut que la probabilité de réussite de la recherche exhaustive soit quasi nulle. Pour créer les n autres éléments wn-i,...,wo de la suite de jetons on utilise une fonction de hachage. Une fonction de hachage h possède les propriétés suivantes : - h opère sur un message M de longueur arbitraire, - le résultat /7(M) possède une longueur /fixe, - étant donné M, il est facile de calculer /7(M), - étant donné M, il est difficile de trouver un autre message M0 tel que /7(M) = /7(M0) Parmi les fonctions de hachage, nous pouvons citer MD5 ("Message Digest 5") ou SHA-1 ("Secure Hash Algorithm"). SHA-1 produit une sortie de 160 bits appelée message abrégé. La fonction de hachage appliquée au nombre aléatoire Wn permet d'obtenir un résultat wn.i (c'est-à-dire un nouveau jeton) auquel on applique à nouveau la fonction de hachage pour obtenir un jeton Wn-2 et ainsi de suite pour obtenir les n éléments wn.1:... ,w0 : h(wn) = wn-i, ..., In(W1) - W0 La suite de jetons est donc (wn, wn-i, wn.2, ..., Wi, W0). Du fait des propriétés des fonctions de hachage, les propriétés des suites de jetons telles que définies plus haut sont vérifiées. Dans le mode de réalisation décrit, seuls le TCGC, le TCP et le SCP manipulent des jetons. Dans un mode de réalisation préféré, le procédé se déroule en 2 phases principales, figure 1. Chacune de ces phases est elle-même divisée en plusieurs étapes. Phase 1 : la phase 1 est exécutée une seule fois par suite de jetons créée : elle correspond à la création et à l'enregistrement de la suite de jetons. Elle comporte au moins les 5 étapes suivantes : - étape 1.1 : le TCGC crée une suite de n jetons (wn, ...,Wi,w0). Il crée un message m contenant Wo et n. Il obtient éventuellement une signature S du message m, qui peut être soit sa propre signature, soit la signature de m par une entité tierce qui l'autorise à créer un compte de n jetons auprès du SCP. Cette signature peut être, par exemple, une signature de type Schnorr, une signature RSA, ou une signature partiellement aveugle. - étape 1.2 : le TCGC envoie des données, dont le message m et la signature S éventuelle, au SCP, en utilisant un canal de communication (par exemple le réseau internet). - étape 1.3 : si le SCP reçoit une signature, il associe la signature à l'entité qui a signé (ce peut être le client dans le cas d'une signature habituelle, ou bien une entité qui certifie l'authentification). Après d'éventuelles vérifications (par exemple, des vérifications liées au débit du Client de la somme de n unités), le SCP conserve en mémoire au moins une partie du message m, qui lui permet de suivre et d'effectuer les modifications du compte du Client : par exemple, le jeton Wo peut lui servir à identifier le compte du Client. - étape 1.4 : le TCGC envoie, à l'aide d'un protocole de communication (par exemple, Bluetooth, IrDA, NFC, WiFi), des données comprenant le jeton Wn et le nombre n au TCP. Il est important de noter que cette étape doit prévoir les mesures de sécurité nécessaires pour qu'un tiers ne puisse pas avoir accès à Wn puisque l'efficacité du procédé dépend du maintien au secret de cette valeur Wn. - étape 1.5 : le TCP stocke tout ou partie des données reçues du TCGC afin de pouvoir effectuer les actes de paiement ultérieurs, qui font l'objet de la phase 2. Dans le cas où le TCGC et le TCP sont une seule et même entité, les étapes 1.4 et 1.5 n'ont pas lieu. Phase 2 : la phase 2 décrit le déroulement de l'acte de paiement faisant intervenir le TCP, le BBS et le SCP. Cette phase est répétée à chaque acte de paiement. Elle comporte au moins les 7 étapes suivantes : - étape 2.1 : cette étape consiste en l'acquisition par le TCP des données nécessaires pour effectuer l'acte de paiement. Cette acquisition peut se faire de plusieurs manières : par exemple, le TCP peut envoyer une requête au BBS contenant des informations sur le bien ou le service désiré, ou bien le Client lui-même peut avoir accès à des informations disponibles directement sur le BBS (par exemple, par une interface écran-clavier sur le BBS). Cette étape comprend l'initialisation d'une communication entre le TCP et le BBS à l'aide d'un protocole de communication qui peut-être sans fil (par exemple, Bluetooth, IrDA, NFC, WiFi), et elle s'achève par l'envoi du BBS au TCP, par exemple sur le même canal de communication, des modalités du paiement (par exemple un identifiant du BBS, un identifiant de transaction, le montant du paiement à effectuer...). Au moins un envoi du BBS vers le TCP est effectué à cette étape, qui peut aussi comprendre plusieurs échanges entre le TCP et le BBS, - étape 2.2 : le TCP calcule le jeton nécessaire au paiement du bien ou du service, en fonction des modalités de paiement reçues à l'étape 1.4, et de l'unité (valeur d'un jeton) : si le montant est de k unités, alors le TCP calcule le jeton Wj+k, où W/ est le dernier jeton envoyé au SCP par le TCP (lors du premier acte de paiement, ce jeton est W0), - étape 2.3 : le TCP envoie (par exemple, par GSM) une requête au SCP contenant le jeton de paiement Wj+k ainsi que d'autres informations, par exemple l'identifiant du BBS, le montant, la nature du bien ou du service, le jeton W0... , - étape 2.4 : le SCP vérifie la validité du jeton reçu, par exemple en vérifiant, la relation Wj est le dernier jeton reçu correspondant à la transaction précédente, - étape 2.5 : le SCP renvoie (par exemple, par GSM) une autorisation de la transaction, qui peut être signée, par exemple à l'aide du mécanisme cryptographique de signature à clé publique, au BBS, - étape 2.6 : le BBS vérifie l'autorisation reçue du SCP (par exemple, grâce au mécanisme de signature à clé publique), - étape 2.7 : le BBS délivre le bien ou le service demandé. Dans le cas où seul le TCP peut établir un canal de communication directe (par exemple, par GSM) avec le SCP, l'étape 2.5 est divisée en 2 étapes 2.5.1 et 2.5.2 : - étape 2.5.1 : le SCP renvoie (par exemple, par GSM) une autorisation de la transaction, qui peut être signée, par exemple à l'aide du mécanisme cryptographique de signature à clé publique, au TCP, - étape 2.5.2 : le TCP transmet l'autorisation au BBS à l'aide d'un protocole de communication qui peut être sans fil (par exemple, Bluetooth, IrDA, NFC, WiFi), et la phase 2 comporte ainsi au moins les étapes 2.1 , 2.2, 2.3, 2.4, 2.5.1, 2.5.2, 2.6 et 2.7. Ayant décrit l'architecture et les différentes étapes d'un mode de réalisation générique, deux modes de réalisation détaillés, dont la différence essentielle réside dans l'utilisation de protocoles de communication différents entre le TCP et le BBS, vont maintenant être décrits. DESCRIPTION DETAILLEE DU MODE DE REALISATION 1 Le premier mode de réalisation, figure 3, est caractérisé par l'utilisation des protocoles suivant entre les entités :
Les entités considérées dans ce mode de réalisation peuvent être : - TCGC : un ordinateur muni d'une interface Bluetooth et d'un accès internet, - SCP : un serveur relié à l'intemet, au réseau GSM - TCP : un téléphone mobile possédant une interface Bluetooth et une interface IrDA ou NFC, GSM - BBS : une borne de paiement de parcmètre possédant une interface IrDA ou NFC (la même que pour le téléphone mobile). Les étapes détaillées sont les suivantes : Phase 1 : - étape 1.1 : le TCGC crée une suite de n jetons (wn, ...,Wi,wo). Pour initialiser la suite, c'est-à-dire calculer Wn, il fait appel à une action du Client (entrée d'une suite de caractères sur un clavier, ou mouvement d'une souris). Les jetons wn.i,..., W0 sont calculés comme indiqué précédemment à l'aide d'une fonction de hachage, par exemple SHA-1. Le TCGC crée le message m=(w0, n). Le TCGC demande à une entité tierce (par exemple, une banque) de signer le message m à l'aide d'une clé privée de signature de cette entité. Le protocole de signature employé est de type Schnorr. On note S la signature de m. - étape 1.2 : le TCGC envoie Reg=(\d, m, S), où Id est l'identité de l'entité qui a signé m, au SCP. La transmission se fait par une liaison sécurisée via internet (par exemple, en utilisant le protocole Secure HTTP). Le TCGC conserve (Id, m, S) en mémoire, - étape 1.3 : le SCP reçoit Reg=(\ά, m, S). Il récupère, grâce à la connaissance de Id, la clé publique de signature de l'entité tierce, et vérifie la validité de S à l'aide de cette clé. Le SCP conserve (wo, n, W0, n, S). Ce quintuplet va lui servir à mémoriser le compte du client. Les deux premiers éléments (w0 et n), ainsi que le dernier (S) du quintuplet restent fixes et vont servir pour identifier le compte du Client, tandis que le troisième et le quatrième, initialisés à W0 et n, seront modifiés suivant le dernier jeton divulgué et la valeur des jetons restants, pour donner l'état courant du compte du Client, - étape 1.4 : le TCGC envoie, via le protocole de communication Bluetooth, le message m'=(wnι n) au TCP, - étape 1.5 : le TCP conserve le couple (wn, n). Phase 2 : Dans cette phase, on suppose que le SCP a conservé un quintuplet (W0, n, w, p, S) et que le TCP a conservé un couple (wn, q). C'est le cas en fin de Phase 1 avec w≈Wo, p=n et q≈n. q représente donc le nombre d'unités de compte disponibles. - étape 2.1.1 : le Client muni du terminal mobile (TCP) désire acheter un bien au BBS. On prend l'exemple de l'achat d'un ticket de stationnement à un parcmètre. Le TCP envoie au BBS un message durée), où ldappii est un identifiant de l'application de paiement utilisée (par exemple, une application de paiement de parcmètre), en utilisant le protocole de communication IrDA (infrarouge), - étape 2.1.2 : le BBS calcule le montant nécessaire au paiement suivant les données du message infoReq. Il attribue un identifiant de transaction Idtransaction à la transaction initialisée avec le TCP. Cet identifiant est obtenu par le BBS en incrémentant le dernier identifiant de transaction qu'il a attribué. Il renvoie au TCP le message lnfoResp=(ldappij, IdBBS, Idtransaction, montant), où IdBBS est un identifiant qui permet au SCP de reconnaître le BBS, par le protocole de communication IrDA. Le BBS conserve InfoResp en mémoire pour identifier la transaction, - étape 2.2 : le TCP rappelle le couple (wn, q) qu'il a conservé en mémoire. Il calcule le nombre k d'unités correspondant au montant contenu dans InfoResp. Si k est strictement plus grand que q, alors Ia transaction est interrompue, car le Client ne possède plus assez de jetons pour payer. Sinon, il calcule w'=hn'q'k(wn) et w=hk(w'), où w=hn'q (wn) est le jeton dévoilé \ors de Ja transaction précédente. - étape 2.3 : le TCP envoie le message Idtransaction, montant, w, q, w', k) au SCP par message SMS sur le réseau GSM, et remplace dans sa mémoire le couple (wn, q) par (wn, q-k), - étape 2.4 : grâce à la donnée de w et q contenus dans PayReq, le SCP retrouve le quintuplet (wo, n, w, q, S). Il vérifie que k correspond au montant contenu dans PayReq et que k est inférieur ou égal à q. Le SCP calcule hk(w') et compare le résultat avec w. S'il y a égalité, le SCP valide le paiement et remplace dans sa mémoire le quintuplet (Wo, n, w, q, S) par le quintuplet (W0, n, w', q-k, S), - étape 2.5.1 : le SCP crée le message auth≈{\dBBs, Idtransaction, montant), et calcule la signature A de auth avec la clé privée de signature du SCP dans un protocole de signature à clé publique de type Schnorr. Il envoie par SMS sur le réseau GSM l'autorisation de transaction PayAuth≈(auth, A) au TCP, - étape 2.5.2 : le TCP transmet PayAuth au BBS par le protocole de communication IrDA, - étape 2.6 : le BBS s'assure que l'identifiant Idées est le sien, puis il vérifie la validité de la signature A à partir de la clé publique du SCP, - étape 2.7 : le BBS délivre le bien demandé correspondant au montant (dans l'exemple du ticket de stationnement, il calcule la durée correspondant au montant indiqué dans PayAuth) et conserve les données de transaction. Il marque la transaction InfoResp comme effectuée. DESCRIPTION DETAILLEE DU MODE DE REALISATION 2 Le second mode de réalisation, figure 4, est caractérisé par l'utilisation des protocoles suivant entre les entités :
Les entités considérées dans ce mode de réalisation peuvent être : - TCGC : un ordinateur muni d'une interface Bluetooth et d'un accès internet, - SCP : un serveur relié à l'internet, - TCP : un téléphone mobile possédant une interface Bluetooth, - BBS : une borne de paiement de parcmètre possédant une interface Bluetooth. Les étapes détaillées sont les suivantes : Phase 1 : - étape 1.1 : le TCGC crée une suite de n jetons (wn,...,wi,wo). Pour initialiser la suite, c'est-à-dire calculer Wn, il fait appel à une action du Client (entrée d'une suite de caractères sur un clavier, ou mouvement d'une souris). Les jetons wn.i, ..., W0 sont calculés, comme indiqué précédemment, à l'aide d'une fonction de hachage, par exemple SHA-1. Le TCGC crée le message m=(w0, n). Le TCGC demande à une entité tierce (par exemple, une banque) de signer le message m à l'aide d'une clé privée de signature de cette entité. Le protocole de signature employé est une signature partiellement aveugle. On note S la signature de m, - étape 1.2 : le TCGC envoie Reg=(ld, m, S), où Id est l'identité de l'entité qui a signé m, au SCP. La transmission se fait par une liaison sécurisée via internet (par exemple, en utilisant le protocole Secure HTTP). Le TCGC conserve (Id, m, S) en mémoire, - étape 1.3 : le SCP reçoit Reg=(ld, m, S). Il récupère, grâce à la connaissance de Id, la clé publique de signature de l'entité tierce, et vérifie la validité de S à l'aide de cette clé. Le SCP conserve (w0, n, W0, n, S). Ce quintuplet va lui servir à mémoriser le compte du client. Les deux premiers éléments (w0 et n), ainsi que le dernier (S) du quintuplet restent fixes et vont servir pour identifier le compte du Client, tandis que le troisième et le quatrième, initialisés à W0 et n, seront modifiés suivant le dernier jeton divulgué et la valeur des jetons restants, pour donner l'état courant du compte du Client, - étape 1.4 : le TCGC envoie, via le protocole de communication Bluetooth, le message m'=(wn, n) au TCP, - étape 1.5 : le TCP conserve le couple {wn, n). Phase 2 : Dans cette phase, on suppose que le SCP a conservé un quintuplet (W0, n, w, p, S) et que le TCP a conservé un couple {wn, q). C'est le cas en fin de Phase 1 avec w=w0, p=n et q=n. - étape 2.1.1 : le Client muni du terminal mobile (TCP) désire acheter un bien au BBS (on peut prendre comme exemple l'achat d'un ticket de stationnement à un parcmètre). Le TCP envoie au BBS un message lnfoReq=(\dappw, durée, c), où ldappii est un identifiant de l'application de paiement utilisée (par exemple, une application de paiement de parcmètre), et c un nombre pseudo-aléatoire calculé par le TCP. La transmission se fait par Bluetooth, - étape 2.1.2 : le BBS calcule le montant nécessaire au paiement suivant les données du message InfoReq. Il attribue un identifiant de transaction Idtransaction à la transaction initialisée avec le TCP. Cet identifiant est obtenu par le BBS en incrémentant le dernier identifiant de transaction qu'il a attribué. Le BBS signe c à l'aide de sa clé secrète dans un protocole de signature à clé publique de type Schnorr. La signature obtenue est notée T, - étape 2.1.3 : le BBS renvoie au TCP le message IdβBs, Idtransaction, montant, c, T), où Idées est un identifiant qui permet au SCP de reconnaître Ie BBS, par le protocole de communication Bluetooth. Le BBS conserve InfoResp en mémoire pour identifier la transaction, - étape 2.2 : le TCP rappelle le couple (wn, q) qu'il a conservé en mémoire. Il calcule le nombre k d'unités correspondant au montant contenu dans InfoResp. Si k est strictement plus grand que q, alors la transaction est interrompue, car le Client ne possède plus assez de jetons pour payer. Sinon, il calcule w'≈lf^fwn) et w=hk(w'), - étape 2.3 : le TCP envoie le message Pay/?eq=(ldBBs, Idtransaction, montant, w, q, w', k, c, T) au SCP par message SMS sur le réseau GSM, et remplace dans sa mémoire le couple (wn, q) par (wn> q-k), - étape 2.4 : le SCP vérifie la validité de T à partir de c et de la clé publique de la borne qu'il connaît grâce à Id6Bs- Grâce à la donnée de w et q contenus dans PayReq, le SCP retrouve le quintuplet {wo, n, w, q, S). Il vérifie que k correspond au montant contenu dans PayReq et que k est inférieur ou égal à q. Le SCP calcule hk(w') et compare le résultat avec w. S'il y a égalité, le SCP valide le paiement et remplace dans sa mémoire le quintuplet (Wo, n, w, q, S) par le quintuplet (w0, n, w', q-k, S), étape 2.5.1 : le SCP crée le message auth=(\άBBs, Idtransaction, montant, c, T), et calcule la signature A de auth avec la clé privée de signature du SCP dans un protocole de signature à clé publique de type Schnorr. Il envoie par SMS sur le réseau GSM l'autorisation de transaction PayAuth=(auth, A) au TCP, - étape 2.5.2 : le TCP transmet PayAuth au BBS par le protocole de communication IrDA, - étape 2.6 : le BBS s'assure que l'identifiant ldBBs est le sien, puis il vérifie la validité de la signature A à partir de la clé publique du SCP, - étape 2.7 : le BBS délivre le bien demandé correspondant au montant (dans l'exemple du ticket de stationnement, il calcule la durée correspondant au montant indiqué dans PayAuth) et conserve les données de transaction. Il marque la transaction InfoResp comme effectuée. Ainsi, le système de paiement à distance permet l'utilisation de terminaux ayant une capacité de calcul limitée, puisque la fonction utilisée pour le calcul des jetons est une fonction arithmétiquement simple et bien connue. De plus, si un paiement n'a jamais eu lieu, le serveur SCP n'est pas en mesure de connaître les jetons correspondants et donc le client garde la maîtrise de ses actes de paiements. Mais, réciproquement, le client ne peut pas réfuter un paiement ayant effectivement eu lieu. En effet, le SCP connaissant les jetons correspondants, cette connaissance est un moyen de preuve que le terminal a bien exécuté une transaction.