FR2812486A1 - Securisation de session avec un moyen de traitement de donnees sous la commande de entites - Google Patents

Securisation de session avec un moyen de traitement de donnees sous la commande de entites Download PDF

Info

Publication number
FR2812486A1
FR2812486A1 FR0010025A FR0010025A FR2812486A1 FR 2812486 A1 FR2812486 A1 FR 2812486A1 FR 0010025 A FR0010025 A FR 0010025A FR 0010025 A FR0010025 A FR 0010025A FR 2812486 A1 FR2812486 A1 FR 2812486A1
Authority
FR
France
Prior art keywords
session
entity
entities
processing means
key
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR0010025A
Other languages
English (en)
Other versions
FR2812486B1 (fr
Inventor
Pierre Girard
Jean Luc Giraud
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Gemplus SA
Original Assignee
Gemplus Card International SA
Gemplus SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gemplus Card International SA, Gemplus SA filed Critical Gemplus Card International SA
Priority to FR0010025A priority Critical patent/FR2812486B1/fr
Priority to EP01956645A priority patent/EP1307997A1/fr
Priority to AU7856901A priority patent/AU7856901A/xx
Priority to US10/343,112 priority patent/US7434049B2/en
Priority to PCT/FR2001/002454 priority patent/WO2002011363A1/fr
Priority to CN01815902.8A priority patent/CN1294721C/zh
Publication of FR2812486A1 publication Critical patent/FR2812486A1/fr
Application granted granted Critical
Publication of FR2812486B1 publication Critical patent/FR2812486B1/fr
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
    • H04L63/0442—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload wherein the sending and receiving network entities apply asymmetric encryption, i.e. different keys for encryption and decryption
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/363—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes with the personal data of a user
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0866—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means by active credit-cards adapted therefor
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/10—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means together with a coded signal, e.g. in the form of personal identification information, like personal identification number [PIN] or biometric data
    • G07F7/1008—Active credit-cards provided with means to personalise their use, e.g. with PIN-introduction/comparison system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0853—Network architectures or network communication protocols for network security for authentication of entities using an additional device, e.g. smartcard, SIM or a different communication terminal
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3271—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response
    • H04L9/3273—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using challenge-response for mutual authentication

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Business, Economics & Management (AREA)
  • Signal Processing (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Accounting & Taxation (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer And Data Communications (AREA)

Abstract

La s ecurisation de l'ex ecution d'une session avec un moyen de traitement de donn ees, tel que carte à puce (CA), sous la commande d'au moins deux entit es, tels que serveurs (EX, EY), consiste à transmettre (X2, Y2) des num eros de session (NSX, NSY) et des cl es de session (KSX, KSY) aux entit es, appliquer (X6, X8; Y6, Y8) le num ero et la cl e de session à un algorithme (ASX, ASY) dans le moyen de traitement et l'entit e respective pour produire un r esultat (REX, REY) et une signature (SGX, SGY), transmettre (X7, Y7) les num eros et les signatures au moyen de traitement, et ex ecuter (F10) la session correspondant aux num eros depuis le moyen de traitement lorsque les signatures sont identiques (X9, Y9) aux r esultats. En variante, l'une des entit es reçoit une d el egation d'une troisième entit e pour autoriser l'ex ecution de la session.

Description

<Desc/Clms Page number 1>
sécurisation de session avec un moyen de traitement de données sous la commande de plusieurs entités
La présente invention concerne d'une manière générale la sécurisation de l'exécution d'une session avec un moyen de traitement de données sous la commande de première et deuxième entités électroniques.
Par exemple, le moyen de traitement de données est une carte à puce multi-applicative dans laquelle certaines ressources doivent être accessibles sous la condition qu'au moins deux entités donnent l'autorisation d'accéder à cette ressource. En effet, il est parfois intéressant de conditionner l'écriture dans un fichier d'une carte à puce ou de manière plus pratique le débit d'un compte dans une carte du type porte-monnaie électronique par l'autorisation de deux entités électroniques, tels que des serveurs de banque et de distributeur.
La présente invention vise précisément à sécuriser le déclenchement d'une session dans le moyen de traitement, telle que carte à puce, sous la commande d'au moins deux entités électroniques.
A cette fin, un procédé pour sécuriser l'exécution d'une session avec un moyen de traitement de données sous la commande d'au moins deux entités électroniques, est caractérisé en ce qu'il comprend les étapes suivantes de : - transmettre des numéros de session et des clés de session depuis le moyen de traitement respectivement aux entités, - appliquer le numéro de session respectif et la clé de session respective à un algorithme de
<Desc/Clms Page number 2>
sécurisation respectif dans le moyen de traitement et l'entité respective pour produire un résultat respectif et une signature respective, - transmettre le numéro de session respectif et la signature respective depuis l'entité respective vers le moyen de traitement, et - exécuter la session depuis le moyen de traitement lorsque les signatures sont respectivement identiques aux résultats.
Afin que le moyen de traitement soit assuré que l'exécution de la session demandée corresponde bien au numéro de session transmis initialement, les résultats respectifs sont écrits en mémoire dans le moyen de traitement respectivement en correspondance aux numéros de session respectifs à transmettre aux entités, et sont lus en correspondance avec les numéros de session respectifs transmis par les entités vers le moyen de traitement avant d'être comparés aux signatures respectives.
En pratique, chacune des entités transmet vers le moyen de traitement des données respectives avec le numéro de session respectif et la signature respective. Les données contiennent une acceptation ou un refus d'exécuter la session. Ainsi, la session est exécutée si, en outre, le moyen de traitement détecte dans chacune des données une acceptation de la session par l'entité respective.
Selon une deuxième réalisation, la session est exécutée à condition que l'une desdites au moins deux entités ait reçu respectivement une délégation d'exécution de session par une troisième entité. Dans cette deuxième réalisation, le procédé comprend les étapes suivantes de :
<Desc/Clms Page number 3>
- transmettre des informations de délégation respectives en faveur de l'une desdites au moins deux entités depuis une troisième entité électronique au moyen de traitement, - transmettre un numéro de session, lequel est identique aux numéros de session respectifs, et une troisième clé de session depuis le moyen de traitement à la troisième entité prédéterminées,.
- retransmettre le numéro de session et la troisième clé de session par la troisième entité vers ladite une entité, et - appliquer non seulement le numéro de session, et la clé de session respective pour ladite une entité mais également la troisième clé de session à l'algorithme de sécurisation respectif dans ladite une entité et le moyen de traitement pour produire la signature respective et le résultat respectif.
Afin que ladite une entité soit certaine que la session dont l'exécution est demandée soit validée par la troisième entité, le numéro de session retransmis par la troisième entité et le numéro de session transmis directement par le moyen de traitement à ladite une entité sont comparés dans ladite une entité, et au moins l'étape d'appliquer dans ladite une entité n'est exécutée que lorsque les numéros de session comparés sont identiques.
La délégation peut être transmise à plus d'une entité. Ainsi, au moins une autre entité desdites au moins deux entités est déléguée de la troisième entité afin que la session ne soit exécutée que lorsque les signatures et les résultats produits en fonction du numéro de session, des clés de session respectives et de la troisième clé sont respectivement identiques.
<Desc/Clms Page number 4>
D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs réalisations préférées de l'invention en référence aux dessins annexés correspondants dans lesquels : - la figure 1 est un bloc-diagramme schématique de plusieurs entités électroniques et d'un moyen de traitement de données de type carte à puce dans un réseau de télécommunication pour la mise en oeuvre du procédé de sécurisation selon l'invention ; - la figure 2 est un algorithme d'étapes du procédé de sécurisation avec le moyen de traitement de données et deux entités électroniques selon une première réalisation de l'invention ; et - la figure 3 est un- algorithme d'étapes du procédé de sécurisation avec le moyen de traitement de données et une troisième entité électronique déléguant aux deux entités précédentes, selon une deuxième réalisation de l'invention.
A la figure 1 est représenté un réseau de télécommunication RT désignant dans leur ensemble tous les types de réseau de télécommunication tel qu'un réseau de radiotéléphonie, le réseau téléphonique commuté, un réseau numérique, à intégration de service RNIS, un réseau à haut débit tel qu'un réseau ATM ou le réseau Internet, un réseau de transmission par paquets, etc. Le réseau RT constitue un moyen de communication entre un moyen de traitement de données CA et diverses entités électroniques dont trois sont représentées EX, EY et EZ.
A titre d'exemple auquel on se référera par la suite, le moyen de traitement de données est un contrôleur, tel que le microcontrôleur d'une carte à
<Desc/Clms Page number 5>
puce CA, dans lequel doit être initié une session qui peut être une tâche à exécuter dans le moyen de traitement de données lui-même ou bien un échange d'unités de données, telles que messages, avec au moins l'une des entités EX, EY et EZ. Ainsi, le moyen de traitement de données peut être non seulement une carte à puce, dite également carte à microcontrôleur, mais également tout autre objet électronique portable, tel qu'assistant ou organiseur électronique, porte-monnaie électronique, jeton, calculette.
Une entité électronique, par exemple l'entité EX ou EY, est un serveur distant de la carte CA, par exemple appartenant à l'éditeur de la carte CA ou en relation avec l'une des applications implémentées dans la carte CA.
En variante, les entités EX et EY sont ellesmêmes des cartes à puce logées dans des lecteurs additionnels inclus dans des serveurs distants de la carte CA afin que deux administrateurs, possesseurs des cartes à puce, autorisent une session par la carte à puce d'un utilisateur.
L'entité EZ peut être un terminal d'accueil TA de la carte à puce CA, tel qu'un terminal bancaire, un terminal point de vente, ou un terminal radiotéléphonique mobile doté d'un lecteur de carte additionnel, ou bien encore un troisième serveur comme cela est prévu dans la deuxième réalisation décrite plus loin.
Selon une première réalisation du procédé de l'invention, l'exécution d'une session avec la carte à puce CA est sécurisée sous la commande de deux entités EX et EY.
<Desc/Clms Page number 6>
Par exemple, la carte à puce CA est une carte avec un compte de points de fidélité éditée par une société distributrice de carburant. Après introduction dans un terminal TA d'une station service, en tant qu'entité EZ, la carte CA n'est autorisée à être débitée que par les deux entités EX et EY afin que le titulaire de la carte reçoive l'article de son choix correspondant à un débit de points. La première entité EX est un serveur de fournisseur d'article qui autorise simplement la carte CA à être débitée après reconnaissance de celle-ci. La deuxième entité EY est un serveur appartenant à la société distributrice du carburant qui vérifie non seulement l'identité de la carte CA mais également le compte de points contenu dans celle-ci avant d'autoriser le débit du compte dans la carte CA. Ainsi, la session consistant ici à débiter le compte de points de fidélité dans la carte CA n'est autorisée qu'après l'identification de la carte par les deux entités EX et EY et l'acceptation du débit par l'entité EY, ou de manière plus globale après l'acceptation de l'exécution de la session "débit de points" par les deux entités EX et EY.
Selon un autre exemple, le possesseur de la carte CA doit obtenir l'autorisation de deux autres possesseurs de cartes à puce, en tant qu'entités EX et EY, par exemple pour accéder à des fichiers prédéterminés dans un réseau Intranet. Les cartes "administratrices" EX et EY sont alors introduites dans les lecteurs de terminaux du réseau afin de transmettre à la carte CA une acceptation ou un refus de la session en fonction de droits d'accès aux fichiers prédéterminés.
<Desc/Clms Page number 7>
Il est supposé préalablement que la carte à puce CA est de préférence pro-active et peut ainsi déclencher elle-même des actions vers le monde extérieur constitué notamment par le réseau de télécommunication RT à travers le terminal d'accueil TA qui est alors transparent à ces actions, bien qu'en variante certaines actions puissent . être déclenchées par le terminal d'accueil TA lui-même. La carte CA par nature a un lien privilégié avec les entités EX et EY et contient en mémoire non volatile EEPROM des adresses de destinataire ADX et ADY des entités EX et EY, telles que leurs numéros téléphoniques d'appel ou leurs adresses IP (Internet Protocol). La mémoire non volatile de la carte CA contient également des clés publiques de chiffrement KPX et KPY respectivement associées aux entités EX et EY.
Le procédé de sécurisation selon la première réalisation montrée à la figure 2 comprend d'abord deux jeux d'étapes X1 à X9 et Yl à Y9 qui sont respectivement associées à des échanges entre la carte CA et la première entité EX d'une part, et la carte CA et la deuxième entité EY d'autre part, puis des étapes finales F9 à F15. Les étapes XI à X9 étant respectivement identiques aux étapes Yl à Y9, le procédé est d'abord décrit en détail seulement pour des échanges entre la carte CA et la première entité EX.
Dès que la carte CA décide d'exécuter une session, par exemple à la suite d'une demande du terminal d'accueil TA, la carte CA initie une authentification de la carte CA par la première entité EX, à l'étape XI. L'authentification est classique et consiste essentiellement à transmettre
<Desc/Clms Page number 8>
un nombre aléatoire par la première entité EX à la carte CA et à comparer dans l'entité EX les résultats de l'application de ce nombre aléatoire et d'une clé d'authentification pré-mémorisée dans la carte CA et l'entité EY, effectuée à la fois dans la carte CA et l'entité EX. Inversement, la carte CA authentifie l'entité EX. Plus complètement en variante, l'authentification est mutuelle, c'est-à-dire l'authentification comprend une authentification de la carte CA par l'entité EX, et une authentification de l'entité EX par la carte CA.
En variante, le procédé de sécurisation ne contient aucune authentification.
Si après authentification optionnelle la carte CA ne reçoit aucun message d'invalidation, la carte CA génère une clé de session KSX qui peut être aléatoire et associe à celle-ci un numéro de session NSX à l'étape X2. Puis après avoir mémorisé la clé KSX et le numéro NSX en correspondance, la carte CA prépare un message à transmettre à l'entité EX, contenant le numéro de session respectif NSX et la clé de session respective KSX qui ont été chiffrés au moyen de la clé de chiffrement publique respective KPX. Le message chiffré MEX ainsi constitué est transmis par la carte CA à l'entité EX à l'étape X3.
Après déchiffrement du message énoncé en fonction d'une clé privée de déchiffrement correspondant à la clé publique de carte KPX à l'étape X4, l'entité EX établit des premières données DX notamment pour marquer son acceptation de la session à exécuter, ou le cas échéant son refus, à l'étape X5. Puis l'entité EX détermine une signature SGX résultant de l'application du numéro de session NSX et de la clé de session KSX reçus à un premier algorithme de sécurisation ASX, à l'étape X6.
<Desc/Clms Page number 9>
L'entité EX construit un message de commande CX qui contient le numéro de session NSX, la signature SGX = ASX (NSX, KSX) et les données DX et qui est transmis à la carte CA à l'étape X7. Le contenu du message de commande CX est de préférence chiffré de manière analogue à celui du message MEX.
Dans la carte CA, après la transmission du message chiffré MEX à l'étape X3, est déterminé également un résultat REX de l'application du numéro de session NSX et de la clé de session KSX au premier algorithme de sécurisation ASX, à l'étape X8. Le résultat REX est écrit en mémoire non volatile dans la carte CA jusqu'à ce qu'il soit lu à l'étape X9, en réponse au message de commande CX. A cette étape X9, la signature SGX reçue par la carte et correspondant au numéro de session NSX est comparée au résultat REX mémorisé dans la carte. Si la signature SGX est différente du résultat REX, la session demandée par le terminal TA avec la carte CA est refusée par celle-ci.
Sinon, lorsque la signature SGX est identique au résultat REX, le procédé passe aux étapes finales dans la mesure où les étapes Yl à Y9 aboutissent également à une étape Y9 selon laquelle une deuxième signature SGY transmise par l'entité EY est identique à un deuxième résultat REY déterminé par la carte CA.
Comme cela apparaît dans la figure 2, les étapes Yl à Y9 sont déduites des étapes précédemment décrites X1 à X9 en remplaçant la lettre X par la lettre Y.
Ainsi, le deuxième résultat REY résulte de l'application dans la carte CA d'un deuxième numéro de session NSY et d'une clé de session KSY qui peut être aléatoire, générés à l'étape Y2 par la carte CA, à un deuxième algorithme de sécurisation ASY. La deuxième signature SGY résulte de l'application dans
<Desc/Clms Page number 10>
la deuxième entité EY à l'étape Y4, du numéro de session NSY et de la clé de session KSY transmis sous forme chiffrée dans un message MEY par la carte CA à l'étape Y3, au deuxième algorithme de sécurisation ASY. La deuxième entité EY transmet à l'étape Y7 également dans un message de commande CY de préférence chiffré, le numéro NSY et la signature SGY ainsi que des deuxièmes données DY traduisant l'acceptation de l'exécution de la session par l'entité EY, ou un refus de celle-ci.
Après une identité de la première signature SGX et du premier résultat REX à l'étape X9 et une identité de la deuxième signature SGY et du deuxième résultat REY à l'étape Y9, la carte CA compare les données DX et DY à l'étape F9. Si l'une ou l'autre des données DX et DY représente un refus, ou bien si l'un NSX ou l'autre NSY des numéros de session retransmis par les entités EX et EY est différent du numéro attribué à l'étape X2 ou Y2, la session demandée n'est pas exécutée. Sinon, les données DX et DY représentent une acceptation de la session correspondant aux numéros reçus NSX et NSY par les entités EX et EY et le procédé est poursuivi par l'exécution de la session à l'étape F10.
Selon d'autres variantes de la première réalisation, le premier numéro de session NSX attribué à l'échange de données entre la première entité EX et la carte CA, et le deuxième numéro de session NSY attribué à l'échange de données entre la carte CA et la deuxième entité EY sont identiques, et les premier et deuxième algorithmes de sécurisation ASX et ASY sont identiques.
Selon une première variante d'étapes finales montrée en traits interrompus courts à la figure 2,
<Desc/Clms Page number 11>
la carte à puce CA transmet des accusés de réception respectifs ACKX et ACKY aux première et deuxième entités EX et EY lorsqu'à la fois la première signature SGX est identique au premier résultat REX et la deuxième signature SGY est identique au deuxième résultat REY, aux étapes X9 et Y9. De préférence, la transmission des premier et deuxième accusés de réception ACKX et ACKY intervient plutôt après l'étape finale F9, lorsque la carte CA a détecté dans les premières et deuxièmes données DX et DY une acceptation de la session par les entités EX et EY. Grâce à ces deux accusés de réception, les entités EX et EY savent chacune que l'autre entité a accepté la session. La session peut être exécutée à l'étape suivante F10 comme illustré à la figure 2, ou en variante précédemment aux transmissions des accusés de réception ACKX et ACKY.
Selon une deuxième variante d'étapes finales, après le constat des identités de signature et de résultat aux étapes X9 et Y9, de préférence après la détection d'une acceptation de la session par les entités EX et EY, la carte CA produit à une étape Fil un mot ACK représentatif de la session à exécuter à une étape F10. A cet égard, la session peut être exécutée à l'étape F10 avant la transmission du mot ACK à l'étape Fil comme illustré à la figure 2, ou en variante après l'étape Fil.
Plus précisément, selon cette deuxième variante, la carte CA produit une première signature de mot SAX résultant de l'application du mot représentatif ACK et de la première clé de session KSX au premier algorithme de sécurisation ASX, et une deuxième signature de mot SAY résultant de l'application du mot représentatif ACK et de la deuxième clé de session KSY au deuxième algorithme de sécurisation
<Desc/Clms Page number 12>
ASY. La carte CA encapsule le mot ACK et les signatures de mot SAX et SAY dans un message AY pour le transmettre à l'une des entités, par exemple la deuxième entité EY, à une étape F12.
La deuxième entité EY vérifie la correspondance entre le mot reçu ACK représentatif de la session et la deuxième signature de mot respective SAY en fonction de la clé de session respective KSY qui avait été reçue et mémorisée dans l'entité EY à l'étape Y4, en appliquant le mot reçu ACK et la clé KSY au deuxième algorithme ASY de manière à produire un résultat qui est comparé à la deuxième signature reçue SAY, à une étape F13. Si cette comparaison est positive, c'est-à-dire si le mot reçu ACK correspond à la signature SAY, la deuxième entité EY transmet un message AX contenant le mot ACK représentatif de la session et l'autre signature, c'est-à-dire la première signature de mot SAX = ASX (ACK ; KSY), à l'autre entité EX à une étape F14. A la réception du message AX, la première entité EX vérifie la correspondance entre le mot représentatif ACK et la première signature de mot reçue SAX en fonction de la clé de session respective KSX qui avait été reçue et mémorisée dans l'entité EX à l'étape X4. Cette vérification consiste à appliquer le mot reçu ACK et la première clé de session KSX au premier algorithme de sécurisation ASX et à comparer le résultat produit par cet algorithme avec la signature reçue SAX à une étape F15.
Si à l'étape F13, l'entité EY constate un défaut de correspondance entre le mot représentatif de cession ACK et la deuxième signature de mot SAY, l'entité EY ignore le résultat de la session exécutée et ne transmet pas le message AX à l'entité EX ou bien transmet un message d'accusé négatif à l'entité
<Desc/Clms Page number 13>
EX ; en variante, l'entité EY procède également à une annulation de la session lorsqu'elle est encore à exécuter dans la carte CA via le terminal TA. De même, lorsque la première entité EX constate un défaut de correspondance entre le mot représentatif de session ACK et la première signature de mot SAX, l'entité EX ignore le résultat de la session exécutée et le signale de préférence à l'entité EX ; en variante, l'entité EX procède également à une annulation de la session dans la carte CA lorsqu'elle est à exécuter.
En variante, les messages d'accusé réception ACKX et ACKY, et/ou les messages AX et AY sont chiffrés.
Bien que la première réalisation ait été décrite avec deux entités EX et EY, l'invention englobe également des réalisations avec plus de deux entités qui chacune doit donner son acceptation à la carte CA selon les étapes X1 à X9, Yl à Y9 pour autoriser l'exécution de la session. En particulier, pour la deuxième variante montrée au bas de la figure 2, l'étape Fil produit autant de signatures de mot SAX, SAY qu'il y a d'entités EX, EY, et chacune de ces entités effectue une étape F13, F15 au cours de laquelle elle vérifie la correspondance entre le mot ACK représentatif de la session et la signature de mot respective SAX, SAY en fonction de la clé de session respective KSX, KSY, et ainsi de suite jusqu'à la dernière entité.
Selon une deuxième réalisation du procédé de sécurisation selon l'invention, une troisième entité électronique EZ intervient. Lorsque la carte CA décide d'exécuter une session prédéterminée, elle
<Desc/Clms Page number 14>
interroge systématiquement la troisième entité EZ qui ne possède pas assez d'information pour décider si elle accepte ou non la session demandée ;l'entité EZ délègue alors cette décision pour une durée prédéterminée aux première et deuxième entités EX et EY en leur transmettant des premières et deuxièmes informations de délégation IDX et IDY respectivement.
Selon une variante complémentaire, si les commandes exécutées dans la session de l'étape F10 nécessitent l'intervention de l'entité EZ et si l'entité EZ ne pourra/voudra pas intervenir dans cet échange interactif, la délégation permet à l'entité EZ de signifier à la carte CA que l'entité EX, EY qui a reçu la délégation a le droit d'agir au nom et pour le compte de l'entité EZ.
Par exemple comme montré à la figure 1, la troisième entité EZ, le délégant, est un serveur d'une banque qui pendant une période de congé annuelle autorise un crédit au possesseur de la carte CA, et par suite fait confiance à un premier serveur EX d'un site commercial connecté au réseau Internet et présentant des produits à acheter et également à un deuxième serveur EY d'un livreur de produits.
Lorsque l'usager, le délégataire, décide, par l'intermédiaire de son propre terminal informatique TA relié au réseau RT et doté d'un lecteur de carte additionnel dans lequel est introduite la carte CA, d'acheter un produit auprès du serveur EX, cette transaction est déclenchée par le serveur de banque EZ qui a vérifié que le compte correspondant à la carte à puce CA a un crédit autorisé et qui fait relayer la transaction par les serveurs EX et EY, les délégués, dans la mesure où ces derniers ont reçu une validation sous la forme d'une clé KSZ fournie par la
<Desc/Clms Page number 15>
carte CA et retransmise par le serveur EZ, comme on le verra ci-après.
Il est supposé dans cette deuxième réalisation que les entités EX et EY ont déjà eu connaissance de la délégation transmise par la troisième entité EZ.
Comme cela apparaît en comparant les figures 2 et 3, la deuxième réalisation du procédé selon l'invention comprend d'abord des étapes Zl à Z7 relatives à des échanges de données entre la troisième entité EZ et la carte à puce CA. De manière analogue à la première réalisation, la carte CA contient en mémoire non volatile les adresses de destinataire ADX, DAY et ADZ des entités EX, EY et EZ ainsi que des clés publiques de chiffrement KPX, KPY et KPZ associées à ces entités.
A la première étape Zl, suite à une demande d'exécution de session par la carte CA transmise à l'entité EZ, l'entité EZ authentifie la carte CA, ou en variante l'entité EZ et la carte CA s'authentifient mutuellement.
En variante, la deuxième réalisation du procédé de sécurisation ne contient aucune authentification.
Après authentification optionnelle, l'entité EZ fournit les premières et deuxièmes informations de délégation IDX et IDY à la carte CA. Chacune des premières et deuxièmes informations de délégation contient par exemple l'adresse ADX, ADY, ou autre identificateur de délégué, de l'entité EX, EY, et le nombre de pouvoirs requis pour exécuter la session, c'est-à-dire le nombre d'entités telles que les entités EX et EY dont l'acceptation est requise pour exécuter la session. Ainsi, à l'étape Z2, la troisième entité EZ transmet les premières et deuxièmes informations de délégation IDX et IDY ainsi que l'adresse de source ADZ de l'entité EZ à la carte
<Desc/Clms Page number 16>
CA sous la forme d'un message qui est signé avec la clé privée de la troisième entité EZ correspondant à la clé publique KPZ, puis chiffré avec la clé publique KPCA de la carte CA. Après déchiffrement, vérification de signature et mémorisation des informations IDX et IDY à l'étape Z3, la carte CA génère un numéro de session NS ainsi que trois. clés de session KSX, KSY et KSZ qui peuvent être aléatoires, et les associe respectivement aux entités EX, EY et EZ en correspondance avec le numéro de session NS, à l'étape Z4. Ces quatre paramètres NS, KSX, KSY et KSZ sont mémorisés dans la carte afin de servir dans les étapes ultérieures.
A l'étape suivante Z5, la carte CA chiffre le numéro de session NS et la troisième clé de session KSZ avec la clé de chiffrement KPZ pour les transmettre dans un message chiffré MEZ à la troisième entité EZ. Après déchiffrement du message MEZ et mémorisation du numéro NS et de la clé de session KSZ à l'étape Z6, l'entité EZ établit deux messages MZX et MZY transmis respectivement vers les entités EX et EY. Le premier message MZX comprend le numéro de session NS et la troisième clé de session KSZ et l'adresse de destination ADX qui sont chiffrés au moyen de la clé publique KPX de la première entité EX. Le deuxième message MZY comprend également le numéro NS, la clé KSZ et l'adresse ADY qui sont chiffrés au moyen de la clé publique KPY de la deuxième entité EY. Les messages MZX et MZY sont respectivement reçus par les entités EX et EY pour y être déchiffrés au moyen de leurs clés privées de chiffrement et y être mémorisés à des étapes suivantes Z8X et Z8Y.
Parallèlement aux étapes Z4 à Z7, la carte CA effectue des étapes X1 à X4 et Yl à Y4, sensiblement
<Desc/Clms Page number 17>
identiques à celles déjà décrites en référence à la figure 2, en réponse aux informations de délégation IDX et IDY reçues à l'étape Z3, de manière à authentifier la carte CA par les entités EX et EY déléguées par l'entité EZ et à transmettre des messages chiffrés MEX[NS, KSX] et MEY[NS, KSY] par la carte CA aux entités EX et EY et à déchiffrer ces messages aux étapes X4 et Y4.
Puis à une étape Z9X, Z9Y dans l'entité EX, EY, le numéro de session NS mémorisé à l'étape Z8X, Z8Y et transmis par la troisième entité EZ est comparé au numéro de session NS et transmis par la carte CA et déchiffré à l'étape X4, Y4, par analogie à la comparaison du numéro de session reçu et mémorisé NSX, NSY à l'étape F9. Si les numéros de session sont différents, l'entité EX refuse la session demandée.
Sinon, les deux numéros de session sont identiques et des données DX, DY représentatives d'une acceptation de la session par l'entité déléguée EX, EY à l'étape X5, Y5 sont établies. Le procédé est poursuivi par des étapes X6Z et X7Z, Y6Z et Y7Z remplaçant respectivement les étapes X6 et X7, Y6 et Y7, et se distinguant de celles-ci par le fait que la signature SGXZ, SGYZ est déterminée en appliquant le numéro de session NS validé à l'étape précédente ,Z9X, Z9Y, la clé de session KSX, KSY reçue et déchiffrée à l'étape X4 et la troisième clé de session KSZ reçue, déchiffrée et mémorisée à l'étape Z8X, Z8Y, à l'algorithme de sécurisation ASX, ASY. Le numéro de session NS, la signature SGXZ, SGYZ et les données DX, DY sont de préférence chiffrés et encapsulés dans un message CXZ, CYZ qui est transmis à la carte CA.
Parallèlement aux étapes X4 à X7Z, Y4 à Y7Z, un résultat REXZ, REYZ est déterminé dans la carte à une étape X8Z, Y8Z remplaçant l'étape X8, Y8, en
<Desc/Clms Page number 18>
appliquant à l'algorithme de sécurisation ASX, ASY le numéro de session NS, la clé KSX, KSY et la troisième clé KSZ.
L'étape suivante X9Z, Y9Z dans la carte CA compare la signature SGXZ, SGYZ au résultat REXZ, REYZ de manière à passer à l'étape finale F9 lorsque les identités SGXZ = REXZ et SGYZ = REYZ. sont vérif iées .
Grâce à la transmission de la troisième clé KSZ par la carte CA à travers la troisième entité EZ et la transmission des clés KSX et KSY par la carte CA directement aux entités EX et EY, la transmission des signatures SGXZ et SGYZ dépendant de ces deux couples de clés avec des données d'acceptation DX et DY à la carte CA assurent que les entités EX et EY ont récupéré la délégation de l'entité EZ et sont autorisées à donner l'ordre d'exécution de la session de numéro NS par délégation.
Selon une troisième réalisation combinant les première et deuxième réalisations, seulement l'une des entités EX et EY, par exemple la première entité EX, est déléguée de la troisième entité EZ. Une session n'est exécutée que lorsque la carte CA a reçu l'acceptation de l'entité EX par délégation de l'entité EZ et l'acceptation de l'entité EY indépendante de l'entité EZ.
Pour la troisième réalisation, la partie gauche de l'algorithme de la figure 3 par rapport à la carte CA, c'est-à-dire les étapes Zl à Z7 en supprimant IDY(ADY), KSY et KPY et les étapes Z8X à X9Z est conservée, et la partie droite de l'algorithme de la figure 3 concernant les relations avec l'entité EY est remplacée par les étapes Yl à Y9 à droite dans la figure 2, afin de comparer finalement la signature
<Desc/Clms Page number 19>
SGXZ au résultat REXZ et la signature SGY au résultat REY à des étapes X9Z et Y9 avant de lire les données reçues DX et DY dans la carte CA à l'étape F9.

Claims (13)

REVENDICATIONS
1 - Procédé pour sécuriser l'exécution d'une session avec un moyen de traitement de données (CA) sous la commande d'au moins deux entités électroniques (EX, EY), caractérisé en ce qu'il comprend les étapes suivantes de : - transmettre (X2, Y2) des numéros de session (NSX, NSY) et des clés de session (KSX, KSY) depuis le moyen de traitement (CA) respectivement aux entités (EX, EY), - appliquer (X6, X8 ; Y6, Y8) le numéro de session respectif (NSX, NSY) et la clé de session respective (KSX, KSY) à un algorithme de sécurisation respectif (ASX, ASY) dans le moyen de traitement (CA) et l'entité respective (EX, EY) pour produire un résultat respectif (REX, REY) et une signature respective (SGX, SGY), - transmettre (X7, Y7) le numéro de session respectif (NSX, NSY) et la signature respective (SGX, SGY) depuis l'entité respective vers le moyen de traitement, et - exécuter (F10) la session correspondant aux numéros de session retransmis (NSX, NSY) depuis le moyen de traitement (CA) lorsque les signatures sont respectivementidentiques (X9, Y9) aux résultats.
2 - Procédé conforme à la revendication 1, selon lequel les résultats respectifs (REX, REY) sont écrits (X2, Y2) en mémoire dans le moyen de traitement (CA) respectivement en correspondance aux numéros de session respectifs (NSX, NSY) à transmettre aux entités (EX, EY), et sont lus (X9, Y9) en correspondance avec les numéros de session respectifs transmis par les entités vers le moyen de
<Desc/Clms Page number 21>
traitement avant d'être comparés aux signatures respectives (SGX, SGY).
3 - Procédé conforme à la revendication 1 ou 2, selon lequel chacune des entités (EX, EY) transmet (X5, X7 ; Y7) vers le moyen de traitement (CA) des données respectives (DX, DY) avec le numéro de session respectif (NSX, NSY) et la signature respective (SGX, SGY), et la session est exécutée si, en outre, le moyen de traitement détecte dans chacune des données une acceptation de la session par l'entité respective.
4 - Procédé conforme à l'une quelconque des revendications 1 à 3, selon lequel, avant d'être transmis depuis le moyen de traitement (CA), le numéro de session respectif (NSX, NSY) et la clé de session respective (KSX, KSY) sont chiffrés (X3, Y3) par un algorithme de chiffrement respectif avec une clé publique respective (KPX, KPY) pour chacune des entités (EX, EY).
5 - Procédé conforme à l'une quelconque des revendications 1 à 4, selon lequel le moyen de traitement (CA) transmet (F9Y, F9Z) des accusés de réception respectif (ACKX, ACKY) aux entités respectives (EX, EY) au moins lorsque les signatures (SGX, SGY) sont respectivement identiques aux résultats (REX, REY).
6 - Procédé conforme à l'une quelconque des revendications 1 à 4, selon lequel le moyen de traitement (CA) produit (F11) un mot (ACK) représentatif de la session lorsque celle-ci doit être exécutée, des signatures de mot respectives
<Desc/Clms Page number 22>
(SAX, SAY) résultant chacune de l'application dudit mot représentatif et de la clé de session respective (KSX, KSY) à l'algorithme de sécurisation respectif (ASX, ASY), pour transmettre (F12) le mot représentatif et les signatures de mot à l'une (EY) des entités afin qu'elle vérifie (F13) la correspondance entre le mot représentatif (ACK) et la signature de mot respective (SAY) en fonction de la clé de session respective (KSY) et, lorsqu'il y a correspondance, transmette (F14) ledit mot représentatif (ACK) et les autres signatures de mot respectives (SAX) à une autre entité (EX), laquelle vérifie (F15) la correspondance entre le mot représentatif (ACK) et la signature de mot respective (SAX) en fonction de la clé de session respective (KSX), et ainsi de suite jusqu'à la dernière entité.
7 - Procédé conforme à l'une quelconque des revendications 1 à 6, comprenant préalablement une authentification (XI, Y1) du moyen de traitement (CA) par les entités (EX, EY) et/ou inversement.
8 - Procédé conforme à l'une quelconque des revendications 1 à 7, comprenant les étapes suivantes de : - transmettre (Z2) des informations de délégation respectives (IDX, IDY) en faveur de l'une desdites au moins deux entités (EX, EY) depuis une troisième entité électronique (EZ) au moyen de traitement (CA), - transmettre (Z4, Z5) un numéro de session (NS), lequel est identique aux numéros de session respectifs (NSX, NSY), et une troisième clé de session (KSZ) depuis le moyen de traitement (CA) à la troisième entité prédéterminées (EZ),
<Desc/Clms Page number 23>
- retransmettre (Z7) le numéro de session (NS) et la troisième clé de session (KSZ) par la troisième entité (EZ) vers ladite une entité (EX), et - appliquer (X6Z) non seulement le numéro de session (NS) et la clé de session respective (KSX) pour ladite une entité (EX) mais également la troisième clé de session (KSZ) à l'algorithme de sécurisation respectif (ASX) dans ladite une entité (EX) et le moyen de traitement (CA) pour produire la signature respective (SGX) et le résultat respectif (REX) .
9 - Procédé conforme à la revendication 8, selon lequel les informations de délégation (IDX, IDY) sont signées avec une clé privée de la troisième entité (EZ), puis chiffrées avec une clé publique (KPCA) du moyen de traitement (CA).
10 - Procédé conforme à la revendication 8 ou 9, selon lequel le numéro de session (NS) retransmis (Z7) par la troisième entité (EZ) et le numéro de session transmis (X2) directement par le moyen de traitement (CA) à ladite une entité (EX) sont comparés (Z9X) dans ladite une entité (EX), et au moins l'étape d'appliquer (X6Z) dans ladite une entité n'est exécutée que lorsque les numéros de session comparés sont identiques.
11 - Procédé conforme à l'une quelconque des revendications 8 à 10, selon lequel avant d'être transmis et retransmis (Z5, Z7), le numéro de session (NS) et la troisième clé de session (KSZ) sont chiffrés avec une troisième clé publique (KPZ) de la troisième entité (EZ), puis avec une clé publique (KPX) de ladite une entité (EX).
<Desc/Clms Page number 24>
12 - Procédé conforme à l'une quelconque des revendications 8 à 11, selon lequel au moins une autre entité (EY) desdites au moins deux entités est déléguée de la troisième entité (EX) afin que la session ne soit exécutée que lorsque les signatures (SGXZ, SGYZ) et les résultats (REXZ, REYZ) produits en fonction du numéro de session (NS), des clés de session respectives (KSX, KSY) et de la troisième clé de session (KSZ) sont respectivement identiques.
13 - Procédé conforme à l'une quelconque des revendications 1 à 12, selon lequel le moyen de traitement (CA) et/ou au moins l'une des entités (EX, EY, EZ) est une carte à puce.
FR0010025A 2000-07-28 2000-07-28 Securisation de session avec un moyen de traitement de donnees sous la commande de entites Expired - Fee Related FR2812486B1 (fr)

Priority Applications (6)

Application Number Priority Date Filing Date Title
FR0010025A FR2812486B1 (fr) 2000-07-28 2000-07-28 Securisation de session avec un moyen de traitement de donnees sous la commande de entites
EP01956645A EP1307997A1 (fr) 2000-07-28 2001-07-26 Securisation de session avec un moyen de traitement de donnees sous la commande de plusieurs entites
AU7856901A AU7856901A (en) 2000-07-28 2001-07-26 Method for making secure a session with data processing means under the control of several entities
US10/343,112 US7434049B2 (en) 2000-07-28 2001-07-26 Method for making secure a session with data processing means under the control of several entities
PCT/FR2001/002454 WO2002011363A1 (fr) 2000-07-28 2001-07-26 Securisation de session avec un moyen de traitement de donnees sous la commande de plusieurs entites
CN01815902.8A CN1294721C (zh) 2000-07-28 2001-07-26 用于使在几个实体的控制下利用数据处理装置的会话安全的方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
FR0010025A FR2812486B1 (fr) 2000-07-28 2000-07-28 Securisation de session avec un moyen de traitement de donnees sous la commande de entites

Publications (2)

Publication Number Publication Date
FR2812486A1 true FR2812486A1 (fr) 2002-02-01
FR2812486B1 FR2812486B1 (fr) 2002-12-27

Family

ID=8853100

Family Applications (1)

Application Number Title Priority Date Filing Date
FR0010025A Expired - Fee Related FR2812486B1 (fr) 2000-07-28 2000-07-28 Securisation de session avec un moyen de traitement de donnees sous la commande de entites

Country Status (6)

Country Link
US (1) US7434049B2 (fr)
EP (1) EP1307997A1 (fr)
CN (1) CN1294721C (fr)
AU (1) AU7856901A (fr)
FR (1) FR2812486B1 (fr)
WO (1) WO2002011363A1 (fr)

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030182559A1 (en) * 2002-03-22 2003-09-25 Ian Curry Secure communication apparatus and method for facilitating recipient and sender activity delegation
JP2004112461A (ja) * 2002-09-19 2004-04-08 Sony Corp データ処理方法、そのプログラムおよびその装置
GB2410660B (en) * 2002-10-14 2005-10-19 Toshiba Res Europ Ltd Methods and systems for flexible delegation
US20110131640A1 (en) * 2008-02-18 2011-06-02 Microelectronica Espanola S.A.U. Secure transfer of data
US9276910B2 (en) * 2013-11-19 2016-03-01 Wayne Fueling Systems Llc Systems and methods for convenient and secure mobile transactions
WO2016064362A1 (fr) * 2014-10-20 2016-04-28 Netaş Telekomüni̇kasyon Anoni̇m Şi̇rketi̇ Procédé de messagerie chiffrée sur les cartes intelligentes

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH09128507A (ja) * 1995-11-02 1997-05-16 Oki Electric Ind Co Ltd 相互認証方法
JP3595109B2 (ja) * 1997-05-28 2004-12-02 日本ユニシス株式会社 認証装置、端末装置、および、それら装置における認証方法、並びに、記憶媒体
US7096494B1 (en) * 1998-05-05 2006-08-22 Chen Jay C Cryptographic system and method for electronic transactions

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
ME L ET AL: "LE COMMERCE ELECTRONIQUE: UN ETAT DE L'ART", ANNALES DES TELECOMMUNICATIONS - ANNALS OF TELECOMMUNICATIONS,CH,PRE SSES POLYTECHNIQUES ET UNIVERSITAIRES ROMANDES, LAUSANNE, vol. 53, no. 9/10, 1 September 1998 (1998-09-01), pages 361 - 376, XP000791619, ISSN: 0003-4347 *
MENEZES , OORSCHOT, VANSTONE: "Handbook of Applied Cryptography", CRC PRESS,US, 1997, BOCA RATON, FL, US, XP002173212, ISBN: 0-8493-8523-7 *

Also Published As

Publication number Publication date
CN1294721C (zh) 2007-01-10
US7434049B2 (en) 2008-10-07
FR2812486B1 (fr) 2002-12-27
AU7856901A (en) 2002-02-13
CN1460343A (zh) 2003-12-03
US20030169884A1 (en) 2003-09-11
EP1307997A1 (fr) 2003-05-07
WO2002011363A1 (fr) 2002-02-07

Similar Documents

Publication Publication Date Title
EP1004101B1 (fr) Terminal et systeme pour la mise en oeuvre de transactions electroniques securisees
EP2455922B1 (fr) Procédé et système de transaction NFC
US20030120660A1 (en) Consumer-centric context-aware switching model
WO1999010848A1 (fr) Dispositif portable electronique pour systeme de communication securisee, et procede d&#39;initialisation de ses parametres
FR2802666A1 (fr) Systeme informatique pour application a acces par accreditation
CN103812649B (zh) 机卡接口的安全访问控制方法与系统、手机终端
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
KR20050013632A (ko) 컴퓨터 기기 아이템간의 상호작용의 범위를 적응변환하는프로토콜
FR2699300A1 (fr) Procédé d&#39;authentification d&#39;un ensemble informatique par un autre ensemble informatique.
WO1997030424A1 (fr) Procede pour faire autoriser par un serveur l&#39;acces a un service a partir de dispositifs portatifs a microcircuits electroniques du type carte a memoire par exemple
FR2812486A1 (fr) Securisation de session avec un moyen de traitement de donnees sous la commande de entites
EP2286567A1 (fr) Authentification de sessions entre des clients mobiles et un serveur
EP1240630A1 (fr) Procede pour authentifier un objet portatif, objet portatif correspondant, et appareil pour mettre en oeuvre le procede
FR2810759A1 (fr) Procede pour effectuer une transaction commerciale en ligne par l&#39;intermediaire d&#39;un reseau de communication et dispositif electronique pour passer des commandes commerciales en ligne
FR2821188A1 (fr) Procede de stockage securise de donnees personnelles et de consultation, carte a puce, terminal et serveur pour la mise en oeuvre du procede
EP1636767A1 (fr) METHODE D&amp;Dacute;ALLOCATION DE RESSOURCES SECURISEES DANS UN MODUE DE SECURITE
WO2022179986A1 (fr) Carte de paiement, procédé d&#39;authentification et utilisation pour un paiement à distance
FR2984648A1 (fr) Dispositif electronique individuel et procede de reponse par un dispositif electronique individuel a une sollicitation
FR3007929A1 (fr) Procede d&#39;authentification d&#39;un utilisateur d&#39;un terminal mobile
Elliott Signing on the digital line
EP3223219A1 (fr) Procédé de transfert de transaction, procédé de transaction et terminal mettant en oeuvre au moins l&#39;un d&#39;eux
CA et al. PROVIDER SERVER
FR3023039A1 (fr) Authentification d&#39;un utilisateur
FR2897735A1 (fr) Procede pour generer un certificat d&#39;authenticite, dispositif personnel de mise en oeuvre du procede et application a l&#39;echange de courriers electroniques certifies

Legal Events

Date Code Title Description
ST Notification of lapse

Effective date: 20100331