EP4652758A1 - 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

Info

Publication number
EP4652758A1
EP4652758A1 EP23837661.0A EP23837661A EP4652758A1 EP 4652758 A1 EP4652758 A1 EP 4652758A1 EP 23837661 A EP23837661 A EP 23837661A EP 4652758 A1 EP4652758 A1 EP 4652758A1
Authority
EP
European Patent Office
Prior art keywords
terminal
key
trmu
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
EP23837661.0A
Other languages
German (de)
English (en)
Inventor
Jean-Philippe Wary
Antoine DUMANOIS
Rémi NEDELEC
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
Publication of EP4652758A1 publication Critical patent/EP4652758A1/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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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 OR CALCULATING; 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

Definitions

  • the present invention lies in the field of providing data in a telecommunications network and more precisely in that of providing signed data.
  • the European Union has established an elDAS (Electronic IDentification Authentication and trust Services) regulation on electronic identification and trust services for electronic transactions.
  • elDAS Electronic IDentification Authentication and trust Services
  • Certain provisions of this regulation for example, impose a level of security which can only be obtained with mobile terminals containing certified hardware security elements, for example a SIM card (Subscriber Identity Module) or TEE card (Trusted Execution). Environment) certified up to a level resistant to an AVA_VAN.5 level evaluation system as defined by “Common Criteria for Information Technology Security Evaluation - Part 3: Security assurance components. (CCMB-2017-04-003)”.
  • a solution proposed, for example to provide personal identification data with such a level of security, is to use external secure elements, for example a sovereign identity card with a biometric module and an NFC chip (in English Near Field Communication), and place this card on the back of the mobile terminal to carry out a transaction.
  • external secure elements for example a sovereign identity card with a biometric module and an NFC chip (in English Near Field Communication), and place this card on the back of the mobile terminal to carry out a transaction.
  • the invention relates to a data signing method implemented by a server and comprising steps of:
  • the invention relates to a data signature server comprising:
  • - a module for receiving a signature request for at least one piece of data sent by a terminal via a network
  • a secure element configured to obtain a signature of said at least one piece of data using a private key associated with the terminal
  • the invention relates to a method for providing signed data implemented by a terminal and comprising steps of:
  • the invention relates to a terminal comprising:
  • - a module for sending a signature request for at least one piece of data to a server via a network
  • the invention also relates to a system for providing signed data comprising at least one terminal and at least one server as mentioned above.
  • the invention proposes a solution in which data intended to be transmitted to a third party by a terminal as part of a transaction, are previously signed by a server with a secure element complying with the security level required for this transaction.
  • this secure element is an HSM component (in English Hardware Security Module), namely an electronic module offering a security service consisting in particular of generating, storing and protecting cryptographic keys.
  • This component can be a PCI (Peripheral Component Interconnect) plug-in electronic card on a computer or an external SCSI/IP (Small Computer System Interface/Internet Protocol) box for example.
  • PCI Peripheral Component Interconnect
  • SCSI/IP Small Computer System Interface/Internet Protocol
  • the HSM component complies with the AVA.VAN5 security level for the protection of the user's signature keys.
  • the signature obtained by this secure element is encrypted by an entanglement of several keys including at least one key for reauthentication of the terminal with the network.
  • the re-authentication key used is the current key and the server does not specifically trigger re-authentication of the terminal to force regeneration of the key.
  • the server forces reauthentication of the terminal to regenerate the reauthentication key just before calculating the signature.
  • the server forces the reauthentication of the terminal to regenerate the reauthentication key after a relatively short delay, for example thirty seconds after sending the signature.
  • the re-authentication key is obtained by a method of re-authentication of a SIM card of the terminal with the home mobile network and triggered by said server.
  • This embodiment also makes it possible to ensure that only the user and the terminal coupled with this SIM card will be able to access the signed data to share it with the third party.
  • the server triggers a reauthentication of the terminal with the network to regenerate the reauthentication key after sending the encrypted signature to the terminal, for example thirty seconds after this sending.
  • this re-authentication method is an EAP-AKA (Extensible Authentication Protocol- Authentication and Key Agreement) type method.
  • This embodiment is particularly advantageous because the EAP-AKA mechanism ensures that the re-authentication key (CK, IK) known in itself to those skilled in the art, then shared by the terminal and the server, has been regenerated substantially at the time of signing (just before or just after) and that it will only be valid for a short period.
  • the server can even possibly re-trigger a new re-authentication of the terminal with the network, giving it a predetermined time to complete its transaction, for example one minute, so as to overwrite the re-authentication key used by the server to encrypt the signature and by the terminal to decrypt the signature.
  • the signature comprises:
  • This other encryption function for example, implements an RSA type mechanism (in English Rivest-Shamir-Adleman).
  • timestamp data offers an additional level of security since it allows the third party to verify the time at which the signature it receives has been calculated by the server. If receipt of the signature by the third party is too late compared to this calculation time, he can then reject the transaction.
  • This so-called anti-replay mechanism is known to those skilled in the art and can be achieved by several other techniques, such as for example replacing or supplementing this timestamp with a transaction serial number coupled or not to data. random.
  • the transport key is calculated from a key calculated using a derivation function shared between the terminal and the server and a personal service code of a terminal user.
  • This embodiment also makes it possible to ensure that only the user of the terminal will be able to access the signed data to share it with the third party.
  • the transport key is calculated from a key calculated using a derivation function shared between the terminal and the server and a key from a security application. a secure electronic wallet of the terminal.
  • the calculation and composition of the plurality of these different session keys makes it possible to ensure that these three elements are present at the user terminal and that the latter is able to reconstruct the transport key.
  • This intertwining of factors of possession (SIM card, electronic wallet application) and knowledge (service code), combined with the lifespan of ephemeral elements (reauthentication key, timestamp data) makes it possible to drastically reduce the surface area of attack the proposed solution.
  • This embodiment also makes it possible to ensure that only the user and the terminal who use this specific electronic wallet application will be able to access the signed data to share it with the third party.
  • At least one of these keys can be replaced or supplemented by another key accessible either by the terminal or by the user of the terminal, as long as this new key, or a diversification of this key, is known to the server.
  • the different stages of the data signing method or of the signed data supply method are determined by computer program instructions or are implemented by a silicon chip which comprises transistors adapted to constitute logic gates of non-programmable hardwired logic.
  • the invention also relates to a computer program on an information medium, this program being capable of being implemented in a controller computer, this program comprising instructions adapted to the implementation of the steps of a data signing method or a method of providing signed data as described above.
  • This program may use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code, such as in a partially compiled form, or in any other desirable shape.
  • the invention also relates to an information medium readable by a computer, and comprising instructions for a computer program as mentioned above.
  • the information carrier can be any entity or device capable of storing the program.
  • the medium may include a storage means, such as a ROM, a non-volatile memory of the flash type or even a magnetic recording means, for example a hard disk.
  • the information carrier may be a transmissible medium such as an electrical or optical signal, which may be carried via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can in particular be downloaded onto an Internet-type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in executing the method in question.
  • One of the advantages of the invention is that the use of a server connected to the user's home mobile network allows said server to benefit from all the behavior analysis and anti-fraud services of said operators. mobile. Brief description of the designs:
  • Figure 1 schematically represents a signed data supply system conforming to a particular embodiment of the invention
  • Figure 2 illustrates an example of a schematic representation of a terminal conforming to a particular embodiment of the invention
  • Figure 3 illustrates an example of a schematic representation of a server conforming to a particular embodiment of the invention
  • Figure 4 illustrates an example of a user enrollment phase with a digital identity provider
  • Figure 5 illustrates an example of an enrollment phase of an application of the terminal of the figure with the server of Figure 3;
  • Figure 6 represents in flowchart form the main steps of a method of providing signed data and of a method of signing data conforming to a particular embodiment of the invention
  • Figure 7 represents the hardware architecture of a terminal conforming to a particular embodiment of the invention.
  • Figure 8 represents the hardware architecture of a server conforming to a particular embodiment of the invention.
  • Figure 1 schematically represents a signed data supply system conforming to a particular embodiment of the invention.
  • This system allows a user U to send, using their TRMu terminal, signed data to a 3RDP third party.
  • This data is, for example, personal data provided by a digital identity provider FIN.
  • the terminal TRMu is in this example a mobile terminal TRMu attached to a mobile network by a home network NET.
  • Figure 2 schematically represents the terminal TRMu of a user U in one embodiment of the invention.
  • Figure 3 schematically represents the SRV server in one embodiment of the invention.
  • the user's TRMu terminal comprises a TCOM communication module on the mobile network and a SIMu SIM card, the user U being able to authenticate with the SIMu card using a PIN code (in English PIN code) as is known. , Personal Identification Number) PIN c u.
  • PIN code in English PIN code
  • PIN c u Personal Identification Number
  • the SRV server includes a SCOM communication module and a secure element constituted here by an HSM component.
  • the TRMu terminal includes a secure element SE.
  • a secure element is a separate chip that contains a secure processor, tamper-proof storage, and runtime memory. This processor, different from the host processor of the TRMu terminal, allows signed transactions to be carried out.
  • the TRMu terminal includes a secure electronic wallet application ID_ W associated with an application key Kw.
  • This key Kw can for example be stored in a register of the ID_W application or in the secure element SE of the mobile terminal TRMu.
  • the SRV server comprises a cryptographic module MCRY comprising a first encryption function chiffi and four key derivation functions fctA, fctB, fctc and fctr hereinafter called respectively first, second, third and fourth functions key derivation. These functions are shared with the ID_W application.
  • the HSM component comprises a timestamping module MH, a hash function H and a second encryption function ch iffi.
  • the hash function H and the second encryption function chiff2 are shared with the third party 3RDP.
  • the method of providing signed data comprises a first enrollment phase, to enroll the user U with a digital entity provider FIN.
  • This first enrollment phase is illustrated in Figure 4 in a particular embodiment of the invention.
  • the digital entity provider FIN produces and provides (step RIO) to the user U, a pair consisting of a public key K PUB u and an associated private key K ⁇ u.
  • This pair of keys can be used in asymmetric cryptography mechanisms known to those skilled in the art implementing, for example, RSA type and elliptic curve algorithms.
  • this pair of keys is stored in the secure element SE of the terminal TRMu. Alternatively, it can be stored in a memory register of the ID_W application.
  • the digital identity provider FIN provides the user (step R20) with data capable of being shared by the user with at least one 3RDP third party.
  • these data are ATTu attributes linked to the identity of the user U, for example his name N, his first name PN, his date of birth DN and his address ADD and are recorded in application memory registers ID_W as shown in Figure 2.
  • Figure 5 illustrates a second enrollment phase making it possible to enroll the ID_W application with the SRV server in a particular embodiment of the invention.
  • the application ID_W provides (step R30) to the SRV server a profile Pu of the user U including the key application Kw, its private key K SEC u obtained from the digital identity provider FIN and a personal service code PIN s u.
  • the SRV server upon receipt of the profile Pu of the user U the SRV server generates the key pair (private key K ⁇ u, public key private key K PUB u) within the HSM and returns the generated public key to the FIN digital identity provider and the ID_W application.
  • the key pair of the user U then being stored encrypted locally at the SRV server, the SRV server knowing at any time to restore the key context and the profile Pu of the user U to process any future signature request from the user via their ID_W application.
  • this personal service code PIN s u is different from the personal code PIN c u of the SIMu SIM card.
  • the personal service code subsequently used during the secure data provision process is either this personal service code provided by the user or a service code derived from this personal service code.
  • This personal service code represents a phase of conscious acceptance, via an active approach, by the user of the transaction carried out.
  • this personal service code PIN s u can be stored, directly or in a diverse manner depending on the state of the art, in the secure element SE of the mobile terminal TRMu or directly in the associated memory to the ID_W application as shown in Figure 2.
  • the SRV server stores the profile Pu of the user U in a database BD as illustrated in Figure 4.
  • Figure 6 represents in flowchart form the main steps of the signed data supply process and the data signing process implemented when the user U wishes to share an ATTu attribute, for example his ADD address with a third party 3RDP.
  • the user U uses an HMI interface of his application ID_W to select an ATTu attribute and a 3RDP third party to whom he wishes to provide this attribute.
  • the ATTu attribute must be signed with the private key K SEC u allocated to the user U by the identity provider FIN and kept secret by the HSM component of the SRV server.
  • the application ID_W of the user U sends an RS signature request to the SRV server to ask it to sign this ATTu attribute.
  • the ATT attribute to be signed is not sent “in the clear” to the SRV server, but sent encrypted with a key specific to the HSM component and unknown to the SRV server.
  • the SRV server then transfers this encrypted attribute to be signed to the HSM which can then find the plain value of the attribute.
  • the SRV server downloads into the HSM component, the profile Pu of the user U stored in the database BD.
  • This profile Pu includes in particular the private key K SEC u allocated to the user U by the identity provider.
  • the SRV server asks the HSM component to sign the ATTu attribute of the user U with the private key K SEC u allocated to the user U.
  • the HSM component determines a timestamp data Horo(t), of the current instant t, calculates, using the hash function H, a hash Hu of the concatenated set (ATTu attribute , timestamp Horo(t)) and encrypts this hash Hu with the private key K SEC u allocated to the user U using the second encryption function chifTi.
  • the HSM component responds to the signature request (step E40) by sending back to the SRV server a SIG signature comprising the timestamp data Horo(t), the attribute ATTu and the result (Hu) * Hu hash encryption.
  • the SRV server forces a re-authentication of the TRMu terminal of the user U at the level of the home mobile network NET.
  • this forced re-authentication step E70 comprises the following steps E71 to E74.
  • the SRV server sends to the mobile network NET a request from the EAP-AKA family, or one of its extensions, for reauthentication of the SIMu SIM card of the user U.
  • EAP-AKA Authentication and Key Agreement
  • UMTS and CDMA2000 3rd generation mobile telephone networks
  • RFC 4187 multiple variants exist depending on the generation of the mobile network targeted and the capabilities of the terminals.
  • EAP protocol family is a network communication protocol embedding multiple authentication methods, which can be used on point-to-point links (RFC 22841), wired networks and wireless networks (RFC 37482, RFC 52473) such as Wi-Fi networks.
  • the home network NET sends, during a step E72, a challenge DF to the terminal TRMu to which the SIM card SIMu responds with a response RP (step E73) after having locally generated a key ⁇ CK, IK ⁇ known to those skilled in the art.
  • re-authentication key CKIK either a key ⁇ CK, IK ⁇ OR one of its derivations or any secret element intrinsic to the EAP-AKA exchange and shared at least between which SIMu SIM card NET home network and potentially the TRMu terminal.
  • the mobile network NET checks the response RP and if the SIMu SIM card is reauthenticated, it sends back to the SRV server a CROK response and the reauthentication key CKIK.
  • a result of this E70 re-authentication procedure is to make available to the SRV server the CKIK re-authentication key available after the re-authentication procedure at the SIMu SIM card of the terminal.
  • the SRV server calculates a derived key CKIK* from the re-authentication key CKIK using the first key derivation function fctA shared with the application ID_W of the TRMu terminal.
  • the SRV server calculates a key KPIN derived from the personal service code PIN s u of the user U obtained during the enrollment phase (step R30) using the second key derivation function fctB shared with the ID_W application of the TRMu terminal.
  • the SRV server calculates a key KAPP derived from the application key Kw obtained during the enrollment phase (step R30) using the third derivation function of fctc key shared with the TRMu terminal ID_W application.
  • the SRV server calculates a transport key KT from:
  • step E100 the KAPP key derived from the application key Kw in step E100; using the fourth key derivation function fctr shared with the TRMu terminal ID_W application.
  • the SRV server calculates the transport key KT from:
  • step E90 the key KPIN derived from the personal service code PIN s u in step E90; and using the fourth key derivation function fctr shared with the TRMu terminal ID_W application.
  • the SRV server calculates the transport key KT from:
  • the SRV server encrypts the SIG signature received from the HSM component in step E60 with the first encryption function encrypted using the transport key KT.
  • the SRV server sends this encrypted signature SIG* to the ID_W application during a step E130 in response to the RS signature request received in step E20.
  • the application ID_W uses the first encryption function chiffi to decrypt the encrypted signature SIG* received in step E130 using the transport key KT and obtains the signature SIG comprising the timestamp data horo(t), the ATTu attribute of the user and the result (Hu)* of the encryption of the hash H of this information with the private key K SEC u allocated to the user U.
  • this decryption could be carried out by a decryption module of the TRMu terminal independent of the ID_W application.
  • the application ID_W sends to the third party 3RDP a message M comprising the SIG signature and a complement C comprising the public key K PUB u allocated to the user U by the FIN identity provider.
  • the SIG signature includes in this example the timestamp Horo(t), the attribute ATTu, a hash (Hu)* of this data encrypted with the private key K ⁇ u allocated to the user U by the provider
  • the FIN identity is kept secret by the HSM component.
  • the third party 3RDP is thus autonomous in verifying the SIG signature thanks to receiving the user's public key and its knowledge of the hash function H and the second encryption function chifTi.
  • FIG. 7 represents the hardware architecture of a TRMu terminal conforming to a particular embodiment of the invention.
  • This terminal includes:
  • processing unit or processor 701, or CPU intended to load instructions into memory, to execute them, to perform operations
  • the storage memory 703 is arranged to store a PGF software module for providing signed data which includes code instructions for implementing the steps of the method for providing signed data as described above.
  • FIG. 8 represents the hardware architecture of an SRV server conforming to a particular embodiment of the invention.
  • This server includes:
  • processor 801 intended to load instructions into memory, to execute them, to perform operations
  • the storage memory 803 is arranged to store a PGS signature software module which includes code instructions for implementing the steps of the signature process as described above.
  • the signed data are attributes linked to the identity of the user.
  • signed data can be a combination of attributes.
  • the invention can be used to provide a cryptographic derivation of this attribute, for example using a zero-knowledge proof algorithm.

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)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • Signal Processing (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Finance (AREA)
  • Bioethics (AREA)
  • Health & Medical Sciences (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Hardware Design (AREA)
  • Software Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Storage Device Security (AREA)
  • Mobile Radio Communication Systems (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 (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).

Description

Description
Procédés de signature de données, de fourniture de données signées, terminal et serveur associés
Technique antérieure
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 elDAS (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 Interface/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 régé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 tous les services d'analyse de comportement et de lutte contre la fraude desdits opérateurs mobiles. Brève description des dessins :
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 figure 1 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 figure 2 illustre un exemple de représentation schématique d'un terminal conforme à un mode particulier de réalisation de l'invention ;
La figure 3 illustre un exemple de représentation schématique d'un serveur conforme à un mode particulier de réalisation de l'invention ;
La figure 4 illustre un exemple d'une phase d'enrôlement d'un utilisateur auprès d'un fournisseur d'identité numérique ;
La figure 5 illustre un exemple d'une phase d'enrôlement d'une application du terminal de la figure auprès du serveur de la figure 3 ;
La figure 6 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 figure 7 représente l'architecture matérielle d'un terminal conforme à un mode particulier de réalisation de l'invention ;
La figure 8 représente l'architecture matérielle d'un serveur conforme à un mode particulier de réalisation de l'invention.
Description des modes de réalisation
La figure 1 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 TRMu des 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 TRMu est dans cet exemple un terminal mobile TRMu rattaché à un réseau mobile par un réseau de rattachement NET.
La figure 2 représente schématiquement le terminal TRMu d'un utilisateur U dans un mode de réalisation de l'invention.
La figure 3 représente schématiquement le serveur SRV dans un mode de réalisation de l'invention.
Le terminal TRMu de 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 SIMu en utilisant comme de façon connue un code PIN (en anglais PIN code, Personal Identification Number) PINcu.
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 TRMu comporte 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 TRMu comporte une application de portefeuille électronique sécurisé ID_ W associée à une clé d'application Kw. Cette clé Kw peut 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 chiffi et quatre fonctions fctA, fctB, fctc et fctr de 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 ch iffi.
Dans le mode de réalisation décrit ici, la fonction de hachage H et la deuxième fonction de chiffrement chiff2 sont 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 figure 4 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 RIO) à l'utilisateur U, un couple constitué par une clé publique KPUBu et une clé privée associée K^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 ATTu lié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 figure 2.
La figure 5 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 Pu de l'utilisateur U comportant la clé d'application Kw, sa clé privée KSECu obtenue du fournisseur d'identité numérique FIN et un code de service personnel PINsu.
Dans un autre mode de réalisation, à réception du profil Pu de l'utilisateur U le serveur SRV fait générer le bi clé (clé privée K^u , clé publique clé privée KPUBu) 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 Pu de 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 ( KSECu ) 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 PINsu est différent du code personnel PINcu de 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é PINsu est 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 PINsu peut ê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 TRMu ou directement dans la mémoire associée à l'application ID_W comme illustré sur la figure 2.
Dans le mode de réalisation décrit ici, le serveur SRV mémorise le profil Pu de l'utilisateur U dans une base de données BD comme illustré sur la figure 4.
La figure 6 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 ATTu et un tiers 3RDP à qui il souhaite fournir cet attribut.
Conformément à l'invention, l'attribut ATTu doit être signé avec la clé privée KSECu alloué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 Pu de l'utilisateur U mémorisé dans la base de données BD. Ce profil Pu comporte notamment la clé privée KSECu alloué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 ATTu de l'utilisateur U avec la clé privée KSECu alloué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é Hu de l'ensemble concaténé (attribut ATTu, horodatage Horo(t)) et chiffre ce haché Hu avec la clé privée KSECu allouée à l'utilisateur U en utilisant la deuxième fonction de chiffrement chifTi.
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 ATTu et le résultat (Hu)* du chiffrement du haché Hu.
Au cours d'une étape E70, le serveur SRV force une réauthentification du terminal TRMu de 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 SIMu de 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 TRMu auquel la carte SIM SIMu ré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 SIMu le 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 SIMu est 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 SIMu du 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é fctA partagé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é KPIN dérivée du code de service personnel PINsu de l'utilisateur U obtenu pendant la phase d'enrôlement (étape R30) en utilisant la deuxième fonction de dérivation de clé fctB partagé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é KAPP dérivée de la clé d'application Kw obtenue pendant la phase d'enrôlement (étape R30) en utilisant la troisième fonction de dérivation de clé fctc partagé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é KPIN dérivée du code de service personnel PINsu à l'étape E90 ; et
- de la clé KAPP dérivée de la clé d'application Kw à l'étape E100 ; en utilisant la quatrième fonction de dérivation de clé fctr partagée avec l'application ID_W du terminal TRMu.
Dans une première variante, au cours d'e l'étape E110, le serveur SRV calcule la clé de transport KT à partir :
- de la clé CKIK* dérivée de la clé de réauthentification CKIK à l'étape E80 ; et
- de la clé KPIN dérivée du code de service personnel PINsu à l'étape E90 ; et en utilisant la quatrième fonction de dérivation de clé fctr partagée avec l'application ID_W du terminal TRMu.
Dans une deuxième variante, au cours de l'étape E110, le serveur SRV calcule la clé de transport KT à partir :
- de la clé CKIK* dérivée de la clé de réauthentification CKIK à l'étape E80 ; et
- de la clé KAPP dérivée de la clé d'application Kw à l'étape E100 ; en utilisant la quatrième fonction de dérivation de clé fctr partagé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 chiffi en 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 Kw mémorisée par exemple dans l'élément sécurisé SE du terminal TRMu et retrouve la clé KAPP en utilisant la troisième fonction de dérivation fctc ; - demande à l'utilisateur de saisir son code de service personnel PINsu et retrouve la clé KPIN en utilisant la deuxième fonction de dérivation fctB ; et
- calcule la clé de transport KT à partir de CKIK*, KPIN et KAPP en utilisant la quatrième fonction de dérivation de clé fctr partagée avec le serveur SRV.
Au cours d'une étape E150, l'application ID_W utilise la première fonction de chiffrement chiffi pour déchiffrer la signature chiffrée SIG* reçue à l'étape E130 en utilisant la clé de transport KT et obtient la signature SIG comportant la donnée d'horodatage horo(t), l'attribut ATTu de l'utilisateur et le résultat (Hu)* du chiffrement du haché H de ces informations avec la clé privée KSECu allouée à l'utilisateur U. En variante, ce déchiffrement pourrait être effectué par un module de déchiffrement du terminal TRMu indé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 KPUBu alloué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 K^u alloué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 chifTi.
La figure 7 représente l'architecture matérielle d'un terminal TRMu conforme à 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 figure 8 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

REVENDICATIONS
[Revendication 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 (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 (chiffi) partagée avec le terminal (TRMu) et en utilisant une clé de transport (KT) calculée (El 10) à 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).
[Revendication 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 (chiffi) 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 (KSECu) 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 (KPUBu) associée à ladite clé privée (K^u).
[Revendication 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 (chifl ) en utilisant ladite clé privée (KSECu), 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) .
[Revendication 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).
[Revendication 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.
[Revendication 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.
[Revendication 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 (fcts) partagée entre le terminal (TRMu) et le serveur (SRV) et un code de service personnel (PINsu) d'un utilisateur (U) du terminal (TRMu).
[Revendication 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).
[Revendication 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 (KSECu) 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 (chiffi) 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).
[Revendication 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 (chiffi) 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 (KSECu) 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 (KPUBu) associée à ladite clé privée (KSECu).
[Revendication 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.
[Revendication 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).
[Revendication 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).
[Revendication 14] Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur (PGS, PGF) selon la revendication 12 ou 13.
EP23837661.0A 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 Pending EP4652758A1 (fr)

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
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

Publications (1)

Publication Number Publication Date
EP4652758A1 true EP4652758A1 (fr) 2025-11-26

Family

ID=87280540

Family Applications (1)

Application Number Title Priority Date Filing Date
EP23837661.0A Pending EP4652758A1 (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

Country Status (4)

Country Link
EP (1) EP4652758A1 (fr)
CN (1) CN120500871A (fr)
FR (1) FR3145074A1 (fr)
WO (1) WO2024153437A1 (fr)

Family Cites Families (3)

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

Also Published As

Publication number Publication date
CN120500871A (zh) 2025-08-15
WO2024153437A1 (fr) 2024-07-25
FR3145074A1 (fr) 2024-07-19

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
EP3446436B1 (fr) Procédé d'obtention par un terminal mobile d'un jeton de sécurité
WO2006021661A2 (fr) Procede d'authentification securisee pour la mise en œuvre de services sur un reseau de transmission de donnees
EP4268109B1 (fr) Procédé et dispositif de contrôle de l'accès à un service utilisant une chaîne de blocs
EP1400056B1 (fr) Procede d'authentification cryptographique
WO2015059389A1 (fr) Procede d'execution d'une transaction entre un premier terminal et un deuxieme terminal
WO2003107587A1 (fr) Procede et dispositif d’interface pour echanger de maniere protegee des donnees de contenu en ligne
EP3673633B1 (fr) Procédé d'authentification d'un utilisateur auprès d'un serveur d'authentification
FR3116133A1 (fr) Procédé de délégation d’accès à une chaîne de blocs
EP4652758A1 (fr) Procédés de signature de données, de fourniture de données signées, terminal et serveur associés
FR2975518A1 (fr) Procede de securisation d'une architecture d'authentification, dispositifs materiels et logiciels correspondants
EP1400090B1 (fr) Procede et dispositif de securisation des communications dans un reseau informatique
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
EP3729720A1 (fr) Procédé cryptographique de signature de groupe
FR3141021A1 (fr) Procédé de mise en œuvre d’un service d’une chaîne de services et dispositif électronique associé
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
WO1998010563A2 (fr) Instrument de securisation d'echanges de donnees
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
WO2025119852A1 (fr) Procédé génération d'un jeton d'authentification d'un terminal utilisateur auprès d'un réseau cœur reposant sur l'utilisation d'une chaine de blocs et procédé d'authentification du terminal utilisateur correspondant
FR3128089A1 (fr) Procédé et dispositif de sélection d’une station de base
WO2023062095A1 (fr) Procédé et dispositif de transfert d'une communication d'une station de base à une autre
FR3141020A1 (fr) Procédé de mise en œuvre d’un service d’une chaîne de services et dispositif électronique associé
FR3043232A1 (fr) Procede de verification d'identite lors d'une virtualisation
WO2021165625A1 (fr) Procede de calcul d'une cle de session, procede de recuperation d'une telle cle de session

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20250721

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC ME MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: EXAMINATION IS IN PROGRESS