FR3145074A1 - Procédés de signature de données, de fourniture de données signées, terminal et serveur associés - Google Patents

Procédés de signature de données, de fourniture de données signées, terminal et serveur associés Download PDF

Info

Publication number
FR3145074A1
FR3145074A1 FR2300436A FR2300436A FR3145074A1 FR 3145074 A1 FR3145074 A1 FR 3145074A1 FR 2300436 A FR2300436 A FR 2300436A FR 2300436 A FR2300436 A FR 2300436A FR 3145074 A1 FR3145074 A1 FR 3145074A1
Authority
FR
France
Prior art keywords
terminal
key
trm
signature
data
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.)
Pending
Application number
FR2300436A
Other languages
English (en)
Inventor
Jean-Philippe Wary
Rémi NEDELEC
Antoine Dumanois
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.)
Orange SA
Original Assignee
Orange 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 Orange SA filed Critical Orange SA
Priority to FR2300436A priority Critical patent/FR3145074A1/fr
Priority to PCT/EP2023/087477 priority patent/WO2024153437A1/fr
Publication of FR3145074A1 publication Critical patent/FR3145074A1/fr
Pending legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10—Integrity
    • H04W12/106—Packet or message integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G06F21/645—Protecting data integrity, e.g. using checksums, certificates or signatures using a third party
    • 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • 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/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3229—Use of the SIM of a M-device as secure element
    • 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/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • 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/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0861—Generation of secret information including derivation or calculation of cryptographic keys or passwords
    • H04L9/0877—Generation of secret information including derivation or calculation of cryptographic keys or passwords using additional device, e.g. trusted platform module [TPM], smartcard, USB or hardware security module [HSM]
    • 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/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • 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/3297—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 time stamps, e.g. generation of time stamps
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication
    • H04W12/069—Authentication using certificates or pre-shared keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/40—Security arrangements using identity modules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/60—Context-dependent security
    • H04W12/61—Time-dependent

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Health & Medical Sciences (AREA)
  • Bioethics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)

Abstract

Ce procédé de signature de données (ATTU) est mis en œuvre par un serveur (SRV). Il comporte des étapes de :- réception (E20) d’une requête (RS) de signature d’au moins une donnée (ATTU) envoyée par un terminal (TRMU) via un réseau (NET) ;- obtention (E60), par un élément sécurisé du serveur, d’une signature (SIG) de ladite au moins une donnée (ATTU) en utilisant une clé privée (KSECU) associée au terminal (TRMU), ladite signature (SIG) étant destinée à être vérifiée par un tiers (3RDP) connaissant une clé publique (KPUBU) associée à ladite clé privée (KSECU) ;- obtention (E74) d’une clé de réauthentification (CKIK) du terminal (TRMU) auprès du réseau (NET) ;- chiffrement (E120) de la signature (SIG) avec une fonction de chiffrement (chiff1) partagée avec le terminal (TRMU) et en utilisant une clé de transport (KT) calculée (E110) à partir de la clé de réauthentification (CKIK) et d’au moins une autre clé (KPIN, KAPP) d’authentification du terminal (TRMU) ou d’un utilisateur (U) du terminal (TRMU) ; et- envoi (E130) de la signature chiffrée (SIG*) au terminal (TRMU). Fig. 6

Description

Procédés de signature de données, de fourniture de données signées, terminal et serveur associés
La présente invention se situe dans le domaine de la fourniture de données dans un réseau de télécommunications et plus précisément dans celui de la fourniture de données signées.
Aujourd’hui, un très grand nombre de transactions électroniques sont effectuées en utilisant un terminal mobile et ces transactions doivent être sécurisées.
Par exemple, l’Union Européenne a établi un règlement eIDAS (en anglais Electronic IDentification Authentication and trust Services) sur l'identification électronique et les services de confiance pour les transactions électroniques.
Certaines dispositions de ce règlement par exemple imposent un niveau de sécurisation qui ne peut être obtenu qu’avec des terminaux mobiles comportant des éléments de sécurité matériels certifiés, par exemple une carte SIM (en anglais Subscriber Identity Module) ou TEE (en anglais Trusted Execution Environment) certifiée jusqu’à un niveau résistant à un système d’évaluation de niveau AVA_VAN.5 tel que défini par « Common Criteria for Information Technology Security Evaluation - Part 3: Security assurance components. (CCMB-2017-04-003 ) ».
Malheureusement, dans l’état actuel, la plupart des terminaux mobiles déployés ne comportent pas de tels composants.
Une solution proposée, par exemple pour fournir des données d’identification personnelles avec un tel niveau de sécurité, est d’utiliser des éléments sécurisés externes, par exemple une carte d’identité régalienne avec un module biométrique et une puce NFC (en anglais Near Field Communication), et de plaquer cette carte au dos du terminal mobile pour effectuer une transaction.
Il a été déterminé que cette solution n’était pas satisfaisante pour les utilisateurs.
Objet et résumé de l’invention
Selon un premier aspect, l’invention concerne un procédé de signature de données mis en œuvre par un serveur et comportant des étapes de :
- réception d’une requête de signature d’au moins une donnée envoyée par un terminal via un réseau ;
- obtention, par un élément sécurisé du serveur, d’une signature de ladite au moins une donnée en utilisant une clé privée associée au terminal, ladite signature étant destinée à être vérifiée par un tiers connaissant une clé publique associée à ladite clé privée ;
- obtention d’une clé de réauthentification du terminal auprès du réseau ;
- chiffrement de la signature avec une fonction de chiffrement partagée avec le terminal et en utilisant une clé de transport calculée à partir de la clé de réauthentification et d’au moins une autre clé d’authentification du terminal ou d’un utilisateur du terminal ; et
- envoi de la signature chiffrée au terminal.
Corrélativement, l’invention concerne un serveur de signature de données comportant :
- un module de réception d’une requête de signature d’au moins une donnée envoyée par un terminal via un réseau ;
- un élément sécurisé configuré pour obtenir une signature de ladite au moins une donnée en utilisant une clé privée associée au terminal ;
- un module d’obtention d’une clé de réauthentification du terminal auprès du réseau ;
- un module de chiffrement de la signature avec une fonction de chiffrement partagée avec le terminal et en utilisant une clé de transport calculée à partir de la clé de réauthentification et d’au moins une autre clé d’authentification du terminal ou d’un utilisateur du terminal ; et
- un module d’envoi de la signature chiffrée au terminal.
Selon un deuxième aspect, l’invention concerne un procédé de fourniture de données signées mis en œuvre par un terminal et comportant des étapes de :
- envoi d’une requête de signature d’au moins une donnée à un serveur via un réseau ;
- obtention d’une clé de réauthentification du terminal auprès du réseau ;
- réception d’une signature chiffrée;
- déchiffrement de la signature chiffrée avec une fonction de chiffrement partagée avec le serveur et en utilisant une clé de transport calculée à partir de la clé de réauthentification et d’au moins une autre clé d’authentification du terminal ou d’un utilisateur du terminal pour obtenir une signature de ladite donnée calculée en utilisant une clé privée associée au terminal ; et
- envoi de la signature à un tiers configuré pour vérifier la validité de la signature avec une clé publique associée à ladite clé privée, ce tiers pouvant être un fournisseur de service requérant ladite donnée signée.
Corrélativement, l’invention concerne un terminal comportant :
- un module d’envoi d’une requête de signature d’au moins une donnée à un serveur via un réseau ;
- un module d’obtention d’une clé de réauthentification du terminal auprès du réseau ;
- un module de réception d’une signature chiffrée;
- un module de déchiffrement de la signature chiffrée avec une fonction de chiffrement partagée avec le terminal et en utilisant une clé de transport calculée à partir de la clé de réauthentification et d’au moins une autre clé d’authentification du terminal ou d’un utilisateur du terminal pour obtenir une signature de ladite donnée calculée en utilisant une clé privée associée au terminal ; et
- un module d’envoi de la signature à un tiers configuré pour vérifier la validité de la signature avec une clé publique associée à ladite clé privée.
L’invention vise également un système de fourniture de données signées comportant au moins un terminal et au moins un serveur tels que mentionnés ci-dessus.
Ainsi, et d’une façon générale, l’invention propose une solution dans laquelle des données destinées à être transmises à un tiers par un terminal dans le cadre d’une transaction, sont préalablement signées par un serveur disposant d’un élément sécurisé conforme au niveau de sécurité requis pour cette transaction.
Dans un mode particulier de réalisation, cet élément sécurisé est un composant HSM (en anglais Hardware Security Module), à savoir un module électronique offrant un service de sécurité consistant notamment à générer, stocker et protéger des clefs cryptographiques. Ce composant peut être une carte électronique enfichable PCI (en anglais Peripheral Component Interconnect) sur un ordinateur ou un boîtier externe SCSI/IP (en anglais Small Computer System lnterface/Internet Protocol) par exemple.
Dans un mode particulier de réalisation de l’invention, le composant HSM est conforme au niveau de sécurité AVA.VAN5 pour la protection des clefs de signature de l’utilisateur.
Conformément à l’invention, la signature obtenue par cet élément sécurisé est chiffrée par une intrication de plusieurs clés dont au moins une clé de réauthentification du terminal auprès du réseau.
Dans un mode de réalisation du procédé de signature ou du procédé de fourniture, la clé de réauthentification utilisée est la clé courante et le serveur ne déclenche pas spécifiquement une réauthentification du terminal pour forcer la regénération de la clé.
Dans un mode de réalisation, le serveur force la réauthentification du terminal pour regénérer la clé de réauthentification juste avant de calculer la signature.
Dans un mode de réalisation, le serveur force la réauthentification du terminal pour regénérer la clé de réauthentification après un délai relativement court, par exemple trente secondes après l’envoi de la signature.
Dans un mode de réalisation du procédé de signature ou du procédé de fourniture, la clé de réauthentification est obtenue par une méthode de réauthentification d’une carte SIM du terminal auprès du réseau mobile de rattachement et déclenchée par ledit serveur.
Ce mode de réalisation permet en outre de s’assurer en outre que seul l’utilisateur et le terminal couplé avec cette carte SIM pourra accéder à la donnée signée pour la partager avec le tiers.
Dans un mode de réalisation, le serveur déclenche une réauthentification du terminal auprès du réseau pour régénérer la clé de réauthentification après l’envoi de la signature chiffrée au terminal, par exemple trente secondes après cet envoi.
Dans un mode particulier de réalisation, cette méthode de réauthentification est une méthode de type EAP-AKA (en anglais Extensible Authentication Protocol- Authentication and Key Agreement).
Ce mode de réalisation est particulièrement avantageux car le mécanisme EAP-AKA permet de s’assurer que la clef de réauthentification (CK, IK) connue en soi de l’homme du métier, partagée alors par le terminal et le serveur a été régénérée sensiblement au moment de la signature (juste avant ou juste après) et qu’elle ne sera valable que pendant une courte période. Le serveur peut même éventuellement redéclencher une nouvelle réauthentification du terminal auprès du réseau, en lui laissant un temps prédéterminé pour terminer sa transaction, par exemple une minute, de sorte à écraser la clé de réauthentification utilisée par le serveur pour chiffrer la signature et par le terminal pour déchiffrer la signature.
En tout état de cause, on rappelle que les règles de configuration des réseaux mobiles établies par la GSMA dans le cadre des accords d’itinérance roaming inter opérateurs imposent une réauthentification systématique des usagers à minima tous les dix événements réseau (changement de cellule, réception d’appel, émission d’appel, nouvelle connexion data, changement de zone radio, ré-attachement au réseau après une coupure radio, réception / émission de message SMS / MMS…).
Ainsi, le piratage de la solution proposée par l’invention n’est possible que pendant une durée de vie de cette clé de réauthentification relativement courte voire très courte après la fin de la transaction.
Pour rappel lors d’une évaluation sécurité de niveau HIGH, suivant la réglementation eiDAS Européenne, les laboratoires d’évaluation ont 3 mois pour procéder aux attaques ; l’invention rend le système d’attaque plus compliqué car elle doit être réalisée en pratique au plus tard dans les minutes qui suivent la transaction.
Dans un mode de réalisation du procédé de signature ou du procédé de fourniture, la signature comporte :
- une donnée d’horodatage d’un instant de calcul de ladite signature;
- un haché d’une concaténation de la donnée à signer et de ladite donnée d’horodatage ; et
- une donnée obtenue en chiffrant ledit haché avec une autre fonction de chiffrement en utilisant ladite clé privée, une fonction utilisée pour calculer ledit haché et l’autre fonction de chiffrement étant partagées entre ledit serveur et ledit tiers.
Cette autre fonction de chiffrement met par exemple en œuvre un mécanisme de type RSA (en anglais Rivest–Shamir–Adleman).
Dans ce mode de réalisation décrit ici, l’utilisation d’une donnée d’horodatage (et /ou éventuellement d’un autre mécanisme d’anti-rejeu) offre un niveau de sécurité supplémentaire puisqu’il permet au tiers de vérifier l’instant auquel que la signature qu’il reçoit a été calculée par le serveur. Si la réception de la signature par le tiers est trop tardive par rapport à cet instant de calcul il peut alors rejeter la transaction. Ce mécanisme dit d’anti rejeu est connu de l’homme de l’art et peut être réalisé par plusieurs autres techniques, comme par exemple un remplacement ou un complément de cet horodatage avec un numéro de série de transaction couplé ou non à une donnée aléatoire.
Dans un mode de réalisation du procédé de signature ou du procédé de fourniture, la clé de transport est calculée à partir d’une clé calculée en utilisant une fonction de dérivation partagée entre le terminal et le serveur et un code de service personnel d’un utilisateur du terminal.
Ce mode de réalisation permet en outre de s’assurer que seul l’utilisateur du terminal pourra accéder à la donnée signée pour la partager avec le tiers.
Dans un mode de réalisation du procédé de signature ou du procédé de fourniture, la clé de transport est calculée à partir d’une clé calculée en utilisant une fonction de dérivation partagée entre le terminal et le serveur et une clé d’une application d’un portefeuille électronique sécurisé du terminal.
Le calcul et la composition de la pluralité de ces différentes clés de session (clé de réauthentification, code de service personnel, clé d’application) permet de s’assurer que ces trois éléments sont présents au niveau du terminal utilisateur et que ce dernier est en mesure de reconstruire la clé de transport. Cette intrication de facteurs de possession (carte SIM, application de portefeuille électronique) et de connaissance (code de service), combinée avec la durée de vie des éléments éphémères (clé de réauthentification, donnée d’horodatage) permet de réduire drastiquement la surface d’attaque de la solution proposée.
Ce mode de réalisation permet en outre de s’assurer en outre que seul l’utilisateur et le terminal qui utilisent cette application déterminée de portefeuille électronique pourra accéder à la donnée signée pour la partager avec le tiers.
Au moins une de ces clés peut être remplacée ou complétée par une autre clé accessible soit par le terminal soit par l’utilisateur du terminal, dès lors que cette nouvelle clé, ou une diversification de cette clé, est connue du serveur.
Dans un mode particulier de réalisation, les différentes étapes du procédé de signature de données ou du procédé de fourniture de données signées sont déterminées par des instructions de programmes d'ordinateurs ou sont implémentées par une puce en silicium qui comprend des transistors adaptés pour constituer des portes logiques d'une logique câblée non programmable.
En conséquence, l'invention vise aussi un programme d'ordinateur sur un support d'informations, ce programme étant susceptible d'être mis en œuvre dans un ordinateur contrôleur, ce programme comportant des instructions adaptées à la mise en œuvre des étapes d'un procédé de signature de données ou d’un procédé de fourniture de données signées tel que décrit ci-dessus.
Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable.
L'invention vise aussi un support d'informations lisible par un ordinateur, et comportant des instructions d'un programme d'ordinateur tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, une mémoire non volatile de type flash ou encore un moyen d'enregistrement magnétique, par exemple un disque dur. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question.
Un des avantages de l’invention, est que l’utilisation d’un serveur connecté au réseau mobile de rattachement de l’utilisateur, permet audit serveur de bénéficier de toutes les services d’analyse de comportement et de lutte contre la fraude desdits opérateurs mobiles.
D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent des exemples de réalisation dépourvus de tout caractère limitatif. Sur les figures :
La représente schématiquement un système de fourniture de données signées conforme à un mode particulier de réalisation de l’invention ;
La illustre un exemple de représentation schématique d’un terminal conforme à un mode particulier de réalisation de l’invention ;
La illustre un exemple de représentation schématique d’un serveur conforme à un mode particulier de réalisation de l’invention ;
La illustre un exemple d’une phase d’enrôlement d’un utilisateur auprès d’un fournisseur d’identité numérique ;
La illustre un exemple d’une phase d’enrôlement d’une application du terminal de la figure auprès du serveur de la ;
La représente sous forme d’ordinogramme les principales étapes d’un procédé de fourniture de données signées et d’un procédé de signature de données conformes à un mode particulier de réalisation de l’invention ;
La représente l’architecture matérielle d’un terminal conforme à un mode particulier de réalisation de l’invention ;
La représente l’architecture matérielle d’un serveur conforme à un mode particulier de réalisation de l’invention ;
La représente schématiquement un système de fourniture de données signées conforme à un mode particulier de réalisation de l’invention.
Ce système permet à un utilisateur U d’envoyer, en utilisant son terminal TRMUdes données signées à un tiers 3RDP. Ces données sont par exemples des données personnelles fournies par un fournisseur d’identité numérique FIN. Le terminal TRMUest dans cet exemple un terminal mobile TRMUrattaché à un réseau mobile par un réseau de rattachement NET.
La représente schématiquement le terminal TRMUd’un utilisateur U dans un mode de réalisation de l’invention.
La représente schématiquement le serveur SRV dans un mode de réalisation de l’invention.
Le terminal TRMUde l’utilisateur comporte un module de communication TCOM sur le réseau mobile et une carte SIM SIMU, l’utilisateur U pouvant s’authentifier auprès de la carte SIMUen utilisant comme de façon connue un code PIN (en anglais PIN code, Personal Identification Number) PINC U.
Le serveur SRV comporte un module de communication SCOM et un élément sécurisé constitué ici par un composant HSM.
Dans le mode de réalisation décrit ici, le terminal TRMUcomporte un élément sécurisé SE. Un élément sécurisé est une puce séparée qui contient un processeur sécurisé, un stockage inviolable et une mémoire d'exécution. Ce processeur, différent du processeur hôte du terminal TRMU, permet d’effectuer des transactions signées.
Dans le mode de réalisation décrit ici, le terminal TRMUcomporte une application de portefeuille électronique sécurisé ID_ W associée à une clé d’application KW. Cette clé KWpeut par exemple être stockée dans un registre de l’application ID_W ou dans l’élément sécurisé SE du terminal mobile TRMU.
Dans le mode de réalisation décrit ici, le serveur SRV comporte un module cryptographique MCRY comportant une première fonction de chiffrement chiff1et quatre fonctions fctA, fctB, fctCet fctTde dérivation de clé ci-après appelées respectivement première, deuxième, troisième et quatrième fonctions de dérivation de clé. Ces fonctions sont partagées avec l’application ID_W.
Dans le mode de réalisation décrit ici, le composant HSM comporte un module MH d’horodatage, une fonction de hachage H et une deuxième fonction de chiffrement chiff2.
Dans le mode de réalisation décrit ici, la fonction de hachage H et la deuxième fonction de chiffrement chiff2sont partagées avec le tiers 3RDP.
Dans le mode de réalisation décrit, le procédé de fourniture de données signées comporte une première phase d’enrôlement, pour enrôler l’utilisateur U auprès d’un fournisseur d’entité numérique FIN.
Cette première phase d’enrôlement est illustrée à la dans un mode particulier de réalisation de l’invention. Dans ce mode de réalisation, le fournisseur d’entité numérique FIN produit et fournit (étape R10) à l’utilisateur U, un couple constitué par une clé publique KPUB Uet une clé privée associée KSEC U. Ce couple de clés peut être utilisé dans des mécanismes de cryptographie asymétrique connus de l’homme du métier mettant en œuvre par exemple des algorithmes de type RSA et de courbe elliptique.
Dans le mode de réalisation décrit ici, ce couple de clés est stocké dans l’élément sécurisé SE du terminal TRMU. En variante, il peut être mémorisé dans un registre de mémoire de l’application ID_W.
Dans le mode de réalisation décrit ici, on suppose que le fournisseur d’identité numérique FIN fournit à l’utilisateur (étape R20) des données susceptibles d’être partagées par l’utilisateur avec au moins un tiers 3RDP. Dans l’exemple de réalisation décrit ici, ces données sont des attributs ATTUliés à l’identité de l’utilisateur U, par exemple son nom N, son prénom PN, sa date de naissance DN et son adresse ADD et sont enregistrés dans des registres de mémoire de l’application ID_W comme illustré sur la .
La illustre une deuxième phase d’enrôlement permettant d’enrôler l’application ID_W auprès du serveur SRV dans un mode particulier de réalisation de l’invention.
Dans le mode de réalisation de cette deuxième phase d’enrôlement décrit ici, on suppose que l’application ID_W fournit (étape R30) au serveur SRV un profil PUde l’utilisateur U comportant la clé d’application KW,sa clé privée KSEC Uobtenue du fournisseur d’identité numérique FIN et un code de service personnel PINS U.
Dans un autre mode de réalisation, à réception du profil PUde l’utilisateur U le serveur SRV fait générer le bi clé (clé privée KSEC U, clé publique clé privée KPUB U) au sein du HSM et renvoie la clé publique générée au fournisseur d’identité numérique FIN et à l’application ID_W. Le bi clé de l’utilisateur U étant alors stockée chiffrée localement au serveur SRV, le serveur SRV sachant à tout moment faire restaurer le contexte de clé et le profil PUde l’utilisateur U pour traiter toute future demande de signature de la part de l’utilisateur via son application ID_W. Dans cet autre mode de réalisation,- la génération du bi clé au sein du HSM permet d’accéder à d’autres services de cryptographie plus évolués, connues de l’homme de l’art et en particulier la possibilité pour une clé privée ( KSEC U) déjà allouée à l’utilisateur U de générer des clés publiques différentes pour de multiples fournisseur d’identité numérique FINkDans le mode de réalisation décrit ici, ce code de service personnel PINS Uest différent du code personnel PINC Ude la carte SIM SIMU. Le code de service personnel utilisé ultérieurement au cours du procédé de fourniture de données sécurisé, toujours noté PINS Uest soit ce code de service personnel fourni par l’utilisateur soit un code de service dérivé à partir de ce code de service personnel. Ce code de service personnel représente une phase d’acceptation consciente, via une démarche active, par l’utilisateur de la transaction réalisée.
Dans le mode de réalisation décrit ici, ce code de service personnel PINS Upeut être stocké, directement ou de façon diversifiée suivant l’état de l’art, dans l’élément sécurisé SE du terminal mobile TRMUou directement dans la mémoire associée à l’application ID_W comme illustré sur la .
Dans le mode de réalisation décrit ici, le serveur SRV mémorise le profil PUde l’utilisateur U dans une base de données BD comme illustré sur la .
La représente sous forme d’ordinogramme les principales étapes du procédé de fourniture de données signées et du procédé de signature de données mises en œuvre lorsque l’utilisateur U souhaite partager un attribut ATTU, par exemple son adresse ADD avec un tiers 3RDP.
Au cours d’une étape E10, l’utilisateur U utilise une interface IHM de son application ID_W pour sélectionner un attribut ATTUet un tiers 3RDP à qui il souhaite fournir cet attribut.
Conformément à l’invention, l’attribut ATTUdoit être signé avec la clé privée KSEC Uallouée à l’utilisateur U par le fournisseur d’identité FIN et gardée secrète par le composant HSM du serveur SRV.
Au cours d’une étape E20, l’application ID_W de l’utilisateur U envoie une requête de signature RS au serveur SRV pour lui demander de signer cet attribut ATTU.
Dans un mode de réalisation particulier de l’étape E20, l’attribut ATT à signer n’est pas envoyé « en clair » vers le serveur SRV, mais émis chiffré avec une clef spécifique du composant HSM et inconnue du serveur SRV. Le serveur SRV transfère alors cet attribut chiffré à signer vers le HSM qui pourra alors retrouver la valeur en clair de l’attribut.
Au cours d’une étape E30, le serveur SRV télécharge dans le composant HSM, le profil PUde l’utilisateur U mémorisé dans la base de données BD. Ce profil PUcomporte notamment la clé privée KSEC Uallouée à l’utilisateur U par le fournisseur d’identité.
Au cours d’une étape E40, le serveur SRV demande au composant HSM de signer l’attribut ATTUde l’utilisateur U avec la clé privée KSEC Uallouée à l’utilisateur U.
Au cours d’une étape E50, le composant HSM détermine une donnée d’horodatage Horo(t), de l’instant courant t, calcule, en utilisant la fonction de hachage H, un haché HUde l’ensemble concaténé (attribut ATTU, horodatage Horo(t)) et chiffre ce haché HUavec la clé privée KSEC Uallouée à l’utilisateur U en utilisant la deuxième fonction de chiffrement chiff2.
On note (HU)*le résultat de ce chiffrement du haché HU.
Au cours d’une étape E60, le composant HSM répond à la demande de signature (étape E40) en renvoyant au serveur SRV une signature SIG comportant la donnée d’horodatage Horo(t), l’attribut ATTUet le résultat (HU)*du chiffrement du haché HU.
Au cours d’une étape E70, le serveur SRV force une réauthentification du terminal TRMUde l’utilisateur U au niveau du réseau mobile NET de rattachement.
Dans un mode particulier de réalisation, cette étape E70 de réauthentification forcée comporte les étapes E71 à E74 suivantes.
Au cours d’une étape E71, le serveur SRV envoie au réseau mobile NET une requête de la famille EAP-AKA, ou une de ses extensions, de réauthentification de la carte SIM SIMUde l’utilisateur U.
On rappelle que la méthode EAP-AKA (Authentication and Key Agreement) est une méthode EAP pour les clients des réseaux de téléphonie mobile de 3e génération (UMTS et CDMA2000). Elle est décrite dans la RFC 4187 et de multiples variantes existent en fonction de la génération du réseau mobile visée et des capacités des terminaux. Pour rappel également, la famille de protocole dite EAP est un protocole de communication réseau embarquant de multiples méthodes d'authentification, pouvant être utilisé sur les liaisons point à point (RFC 22841), les réseaux filaires et les réseaux sans fil (RFC 37482, RFC 52473) tels que les réseaux Wi-Fi.
A cet effet, le réseau de rattachement NET envoie, au cours d’une étape E72, un défi DF au terminal TRMUauquel la carte SIM SIMUrépond par une réponse RP (étape E73) après avoir généré localement une clé {CK, IK} connue de l’homme du métier. Dans la suite de la description on appellera « clé de réauthentification CKIK » soit a clé {CK, IK} ou une de ses dérivations ou tout élément secret intrinsèque à l’échange EAP-AKA et partagé à minima entre quel la carte SIM SIMUle réseau de rattachement NET et potentiellement le terminal TRMU.
Au cours d’une étape E74, le réseau mobile NET vérifie la réponse RP et si la carte SIM SIMUest ré authentifiée, il renvoie au serveur SRV une réponse CROK et la clé de réauthentification CKIK.
Un résultat de cette procédure de réauthentification E70 est de mettre à disposition du serveur SRV la clé de réauthentification CKIK disponible après la procédure de réauthentification au niveau de la carte SIM SIMUdu terminal.
Dans le mode de réalisation décrit ici, au cours d’une étape E80, le serveur SRV calcule une clé dérivée CKIK* à partir de la clé de réauthentification CKIK en utilisant la première fonction de dérivation de clé fctApartagée avec l’application ID_W du terminal TRMU.
Dans le mode de réalisation décrit ici, au cours d’une étape E90, le serveur SRV calcule une clé KPINdérivée du code de service personnel PINS Ude l’utilisateur U obtenu pendant la phase d’enrôlement (étape R30) en utilisant la deuxième fonction de dérivation de clé fctBpartagée avec l’application ID_W du terminal TRMU.
Dans le mode de réalisation décrit ici, au cours d’une étape E100, le serveur SRV calcule une clé KAPPdérivée de la clé d’application KWobtenue pendant la phase d’enrôlement (étape R30) en utilisant la troisième fonction de dérivation de clé fctCpartagée avec l’application ID_W du terminal TRMU.
Dans le mode de réalisation décrit ici, au cours d’une étape E110, le serveur SRV calcule une clé de transport KTà partir :
- de la clé CKIK* dérivée de la clé de réauthentification CKIK à l’étape E80 ;
- de la clé KPINdérivée du code de service personnel PINS Uà l’étape E90 ; et
- de la clé KAPPdérivée de la clé d’application KWà l’étape E100 ;
en utilisant la quatrième fonction de dérivation de clé fctTpartagée avec l’application ID_W du terminal TRMU.
Au cours d’une étape E120, le serveur SRV chiffre la signature SIG reçue du composant HSM à l’étape E60 avec la première fonction de chiffrement chiff1en utilisant la clé de transport KT.
Le serveur SRV envoie cette signature chiffrée SIG* à l’application ID_W au cours d’une étape E130 en réponse à requête de signature RS reçue à l’étape E20.
Au cours d’une étape E140, l’application ID_W :
- obtient la CKIK mémorisée dans la carte SIM SIMUà l’issue de l’étape de réauthentification forcée E70 et retrouve la clé CKIK* en utilisant la première fonction de dérivation fctA;
- obtient la clé d’application KWmémorisée par exemple dans l’élément sécurisé SE du terminal TRMUet retrouve la clé KAPPen utilisant la troisième fonction de dérivation fctC;
- demande à l’utilisateur de saisir son code de service personnel PINS Uet retrouve la clé KPINen utilisant la deuxième fonction de dérivation fctB; et
- calcule la clé de transport KTà partir de CKIK*, KPINet KAPPen utilisant la quatrième fonction de dérivation de clé fctTpartagée avec le serveur SRV.
Au cours d’une étape E150, l’application ID_W utilise la première fonction de chiffrement chiff1pour déchiffrer la signature chiffrée SIG*reçue à l’étape E130 en utilisant la clé de transport KTet obtient la signature SIG comportant la donnée d’horodatage horo(t), l’attribut ATTUde l’utilisateur et le résultat (HU)*du chiffrement du haché H de ces informations avec la clé privée KSEC Uallouée à l’utilisateur U. En variante, ce déchiffrement pourrait être effectué par un module de déchiffrement du terminal TRMUindépendant de l’application ID_W.
Dans le mode de réalisation décrit ici, au cours d’une étape E160, l’application ID_W envoie au tiers 3RDP un message M comportant la signature SIG et un complément C comprenant la clé publique KPUB Uallouée à l’utilisateur U par le fournisseur d’identité FIN. On rappelle que la signature SIG comporte dans cet exemple l’horodatage Horo(t), l’attribut ATTU, un hash (HU)*de ces données chiffré avec la clé privée KSEC Uallouée à l’utilisateur U par le fournisseur d’identité FIN et gardée secrète par le composant HSM.
Dans ce mode de réalisation, le tiers 3RDP est ainsi autonome dans la vérification de la signature SIG grâce à la réception de la clé publique de l’utilisateur et à sa connaissance de la fonction de hachage H et de la deuxième fonction de chiffrement chiff2.
La représente l’architecture matérielle d’un terminal TRMUconforme à un mode particulier de réalisation de l’invention. Ce terminal comporte :
- une unité de traitement ou processeur 701, ou CPU, destinée à charger des instructions en mémoire, à les exécuter, à effectuer des opérations ;
- un ensemble de mémoires, dont une mémoire volatile 702, ou RAM utilisée pour exécuter des instructions de code, stocker des variables, etc., et une mémoire de stockage 703 de type EEPROM. En particulier, la mémoire de stockage 703 est agencée pour mémoriser un module logiciel PGF de fourniture de données signées qui comprend des instructions de code pour mettre en œuvre les étapes du procédé de fourniture de données signées tel que décrit précédemment.
La représente l’architecture matérielle d’un serveur SRV conforme à un mode particulier de réalisation de l’invention. Ce serveur comporte :
- une unité de traitement ou processeur 801, ou CPU, destinée à charger des instructions en mémoire, à les exécuter, à effectuer des opérations ;
- un ensemble de mémoires, dont une mémoire volatile 802, ou RAM utilisée pour exécuter des instructions de code, stocker des variables, etc., et une mémoire de stockage 803 de type EEPROM. En particulier, la mémoire de stockage 803 est agencée pour mémoriser un module logiciel PGS de signature qui comprend des instructions de code pour mettre en œuvre les étapes du procédé de signature tel que décrit précédemment.
Dans le mode de réalisation décrit précédemment, les données signées sont des attributs liés à l’identité de l’utilisateur.
Mais des données de tout type peuvent être signées par l’invention.
En particulier, les données signées peuvent être une combinaison d’attributs.
Par ailleurs, au lieu de fournir un attribut en tant que tel, l’invention peut être utilisée pour fournir une dérivation cryptographique de cet attribut, par exemple en utilisant un algorithme à preuve de connaissance nulle.

Claims (14)

  1. Procédé de signature de données (ATTU) mis en œuvre par un serveur (SRV) et comportant des étapes de :
    - réception (E20) d’une requête (RS) de signature d’au moins une donnée (ATTU) envoyée par un terminal (TRMU) via un réseau (NET) ;
    - obtention (E60), par un élément sécurisé (HSM) du serveur, d’une signature (SIG) de ladite au moins une donnée (ATTU) en utilisant une clé privée (KSEC U) associée au terminal (TRMU), ladite signature (SIG) étant destinée à être vérifiée par un tiers (3RDP) connaissant une clé publique (KPUB U) associée à ladite clé privée (KSEC U) ;
    - obtention (E74) d’une clé de réauthentification (CKIK) du terminal (TRMU) auprès du réseau (NET) ;
    - chiffrement (E120) de la signature (SIG) avec une fonction de chiffrement (chiff1) partagée avec le terminal (TRMU) et en utilisant une clé de transport (KT) calculée (E110) à partir de la clé de réauthentification (CKIK) et d’au moins une autre clé (KPIN, KAPP) d’authentification du terminal (TRMU) ou d’un utilisateur (U) du terminal (TRMU) ; et
    - envoi (E130) de la signature chiffrée (SIG*) au terminal (TRMU).
  2. Procédé de fourniture de données signées mis en œuvre par un terminal (TRMU) et comportant des étapes de :
    - envoi (E20) d’une requête (RS) de signature d’au moins une donnée (ATTU) à un serveur (SRV) via un réseau (NET) ;
    - obtention (E73) d’une clé de réauthentification (CKIK) du terminal (TRMU) auprès du réseau (NET) ;
    - réception (E130) d’une signature chiffrée (SIG*);
    - déchiffrement de la signature chiffrée (SIG*) avec une fonction de chiffrement (chiff1) partagée avec le serveur (SRV) et en utilisant une clé de transport (KT) calculée (E140) à partir de la clé de réauthentification (CKIK) et d’au moins une autre clé (KPIN, KAPP) d’authentification du terminal (TRMU) ou d’un utilisateur (U) du terminal (TRMU) pour obtenir une signature (SIG) de ladite donnée (ATTU) calculée en utilisant une clé privée (KSEC U) associée au terminal (TRMU) ; et
    - envoi (E160) de la signature (SIG) à un tiers (3RDP) configuré pour vérifier la validité de la signature avec une clé publique (KPUB U) associée à ladite clé privée (KSEC U).
  3. Procédé selon la revendication 1 ou 2, caractérisé en ce que ladite signature (SIG) comporte :
    - une donnée d’horodatage (Horo(t)) d’un instant (t) de calcul (E60) de ladite signature ;
    - un haché (HU) d’une concaténation de ladite donnée à signer (ATTU) et de ladite donnée d’horodatage (Horo(t)) ; et
    - une donnée ((HU)*) obtenue en chiffrant ledit haché (HU) avec une autre fonction de chiffrement (chiff2) en utilisant ladite clé privée (KSEC U), une fonction (H) utilisée pour calculer ledit haché et l’autre fonction de chiffrement (chiff2) étant partagées entre ledit serveur (SRV) et ledit tiers (3RDP) .
  4. Procédé selon l’une quelconque des revendications 1 à 3, caractérisé en ce que ladite clé de réauthentification (CKIK) est obtenue (E73, E74) par une méthode de réauthentification d’une carte SIM (SIMU) du terminal (TRMU) déclenchée par ledit serveur (SRV).
  5. Procédé selon l’une quelconque des revendications 1 et 3 à 4, caractérisé en ce que le serveur (SRV) déclenche une réauthentification du terminal (TRMU) auprès du réseau (NET) pour régénérer la clé de réauthentification (CKIK) après l’envoi de la signature chiffrée (SIG*) au terminal (TRMU), par exemple trente secondes après ledit envoi.
  6. Procédé selon la revendication 4 ou 5, dans lequel ladite méthode de réauthentification est une méthode de type EAP-AKA.
  7. Procédé selon l’une quelconque des revendications 1 à 6, caractérisé en ce que ladite clé de transport (KT) est calculée (E110, E140) à partir d’une clé (KPIN) calculée (E90, E140) en utilisant une fonction de dérivation (fctB) partagée entre le terminal (TRMU) et le serveur (SRV) et un code de service personnel (PINS U) d’un utilisateur (U) du terminal (TRMU).
  8. Procédé selon l’une quelconque des revendications 1 à 7, caractérisé en ce que ladite clé de transport (KT) est calculée (E110, E140) à partir d’une clé (KAPP) calculée (E100, E140) en utilisant une fonction de dérivation (fctC) partagée entre le terminal (TRMU) et le serveur (SRV) et une clé (KW) d’une application (ID_W) d’un portefeuille électronique sécurisé (ID_ W) du terminal (TRMU).
  9. Serveur (SRV) de signature de données (ATTU) comportant :
    - un module (SCOM) de réception d’une requête (RS) de signature d’au moins une donnée (ATTU) envoyée par un terminal (TRMU) via un réseau (NET) ;
    - un élément sécurisé (HSM) configuré pour obtenir une signature (SIG) de ladite au moins une donnée (ATTU) en utilisant une clé privée (KSEC U) associée au terminal (TRMU) ;
    - un module (SCOM) d’obtention d’une clé de réauthentification (CKIK) du terminal (TRMU) auprès du réseau (NET) ;
    - un module (MCRY) de chiffrement de la signature (SIG) avec une fonction de chiffrement (chiff1) partagée avec le terminal (TRMU) et en utilisant une clé de transport (KT) calculée à partir de la clé de réauthentification (CKIK) et d’au moins une autre clé (KPIN, KAPP) d’authentification du terminal (TRMU) ou d’un utilisateur du terminal (TRMU) ; et
    - un module (SCOM) d’envoi de la signature chiffrée (SIG*) au terminal (TRMU).
  10. Terminal (TRMU) comportant :
    - un module (TCOM) d’envoi d’une requête (RS) de signature d’au moins une donnée (ATTU) à un serveur (SRV) via un réseau (NET) ;
    - un module (SIMU) d’obtention d’une clé de réauthentification (CKIK) du terminal (TRMU) auprès du réseau (NET) ;
    - un module (TCOM) de réception d’une signature chiffrée (SIG*) ;
    - un module (ID_W) de déchiffrement de la signature chiffrée (SIG*) avec une fonction de chiffrement (chiff1) partagée avec le terminal (TRMU) et en utilisant une clé de transport (KT) calculée à partir de la clé de réauthentification (CKIK) et d’au moins une autre clé (KPIN, KAPP) d’authentification du terminal (TRMU) ou d’un utilisateur du terminal (TRMU) pour obtenir une signature (SIG) de ladite donnée (ATTU) calculée en utilisant une clé privée (KSEC U) associée au terminal (TRMU) ; et
    - un module (TCOM) d’envoi (E160) de la signature (SIG) à un tiers (3RDP) configuré pour vérifier la validité de la signature avec une clé publique (KPUB U) associée à ladite clé privée (KSEC U).
  11. Système de fourniture de données signées comportant :
    - au moins un terminal (TRMU) selon la revendication 10 ; et
    - au moins un serveur (SRV) selon la revendication 9.
  12. Programme d’ordinateur (PGS) comportant des instructions pour l’exécution des étapes d’un procédé de signature de données selon l’une quelconque des revendications 1 ou 3 à 8 lorsque ledit programme est exécuté par un ordinateur (SRV).
  13. Programme d’ordinateur (PGF) comportant des instructions pour l’exécution des étapes d’un procédé de fourniture de données signées selon l’une quelconque des revendications 2 à 8 lorsque ledit programme est exécuté par un ordinateur (TRMU).
  14. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur (PGS, PGF) selon la revendication 12 ou 13.
FR2300436A 2023-01-17 2023-01-17 Procédés de signature de données, de fourniture de données signées, terminal et serveur associés Pending FR3145074A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR2300436A FR3145074A1 (fr) 2023-01-17 2023-01-17 Procédés de signature de données, de fourniture de données signées, terminal et serveur associés
PCT/EP2023/087477 WO2024153437A1 (fr) 2023-01-17 2023-12-21 Procédés de signature de données, de fourniture de données signées, terminal et serveur associés

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2300436A FR3145074A1 (fr) 2023-01-17 2023-01-17 Procédés de signature de données, de fourniture de données signées, terminal et serveur associés
FR2300436 2023-01-17

Publications (1)

Publication Number Publication Date
FR3145074A1 true FR3145074A1 (fr) 2024-07-19

Family

ID=87280540

Family Applications (1)

Application Number Title Priority Date Filing Date
FR2300436A Pending FR3145074A1 (fr) 2023-01-17 2023-01-17 Procédés de signature de données, de fourniture de données signées, terminal et serveur associés

Country Status (2)

Country Link
FR (1) FR3145074A1 (fr)
WO (1) WO2024153437A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101863953B1 (ko) * 2016-06-16 2018-06-29 주식회사 티모넷 전자 서명 서비스 시스템 및 방법
US10771256B2 (en) * 2015-04-30 2020-09-08 Bundesdruckerei Gmbh Method for generating an electronic signature
JP2021040278A (ja) * 2019-09-05 2021-03-11 ジーエムオーグローバルサイン ピーティーイー リミテッド 鍵管理システム、署名装置、鍵管理方法及びプログラム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10771256B2 (en) * 2015-04-30 2020-09-08 Bundesdruckerei Gmbh Method for generating an electronic signature
KR101863953B1 (ko) * 2016-06-16 2018-06-29 주식회사 티모넷 전자 서명 서비스 시스템 및 방법
JP2021040278A (ja) * 2019-09-05 2021-03-11 ジーエムオーグローバルサイン ピーティーイー リミテッド 鍵管理システム、署名装置、鍵管理方法及びプログラム

Also Published As

Publication number Publication date
WO2024153437A1 (fr) 2024-07-25

Similar Documents

Publication Publication Date Title
EP1427231B1 (fr) Procédé d'établissement et de gestion d'un modèle de confiance entre une carte à puce et un terminal radio
EP1022922B1 (fr) Procédé d'authentification, avec établissement d'un canal sécurise, entre un abonné et un fournisseur de services accessible via un opérateur de télécommunications
EP3152860B1 (fr) Procédé d'authentification d'une première entité électronique par une seconde entité électronique et entité électronique mettant en oeuvre un tel procédé
EP2484084B1 (fr) Procédé et dispositifs de communications securisées contre les attaques par innondation et denis de service (dos) dans un réseau de télécommunications
WO2006021661A2 (fr) Procede d'authentification securisee pour la mise en œuvre de services sur un reseau de transmission de donnees
FR3050348A1 (fr) Procede d'obtention par un terminal mobile d'un jeton de securite
EP1958371A2 (fr) Recouvrement de cles de dechiffrement perimees
EP1400056B1 (fr) Procede d'authentification cryptographique
WO2015059389A1 (fr) Procede d'execution d'une transaction entre un premier terminal et un deuxieme terminal
EP3965361B1 (fr) Echange de données entre un client et un dispositif distant, par exemple un module sécurisé
EP1514377A1 (fr) Procede et dispositif d'interface pour echanger de maniere protegee des donnees de contenu en ligne
WO2022137192A1 (fr) Procédé et dispositif de contrôle de l'accès à un service utilisant une chaîne de blocs
EP3758322A1 (fr) Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion
WO2019228853A1 (fr) Methode d'etablissement de cles pour le controle d'acces a un service ou une ressource
FR3145074A1 (fr) Procédés de signature de données, de fourniture de données signées, terminal et serveur associés
FR3028369A1 (fr) Procede et systeme de gestion d'identites d'utilisateurs destine a etre mis en oeuvre lors d'une communication entre deux navigateurs web
EP1400090B1 (fr) Procede et dispositif de securisation des communications dans un reseau informatique
EP3673633B1 (fr) Procédé d'authentification d'un utilisateur auprès d'un serveur d'authentification
WO2021074527A1 (fr) Procede de gestion d'une base de donnees de cles publiques, procede d'authentification de cles publiques, et dispositifs serveur et client mettant en oeuvre ces procedes
EP3785403A1 (fr) Procédé d'élaboration de données d'utilisation de relais utilisés au cours d'une communication entre deux appareils, de recherche desdites données, et appareils associés
WO2023062095A1 (fr) Procédé et dispositif de transfert d'une communication d'une station de base à une autre
FR2975518A1 (fr) Procede de securisation d'une architecture d'authentification, dispositifs materiels et logiciels correspondants
EP0923829A2 (fr) Instrument de securisation d'echanges de donnees
FR3128089A1 (fr) Procédé et dispositif de sélection d’une station de base
FR3141021A1 (fr) Procédé de mise en œuvre d’un service d’une chaîne de services et dispositif électronique associé

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20240719