Methods for signing data and providing signed data, and associated terminal and server
Patent Information
- Application Number
- EP2023837661
- Authority / Receiving Office
- EP · EP
- Patent Type
- Applications
- Current Assignee / Owner
- Priority Date
- 2023-01-17
- Filing Date
- 2023-12-21
- Publication Date
- 2025-11-26
AI Technical Summary
Current mobile terminals lack certified hardware security elements, such as SIM cards or TEE cards resistant to AVA_VAN.5 level evaluation, making secure electronic transactions challenging, and external secure elements like sovereign identity cards with biometric modules and NFC chips are not satisfactory to users.
A method and system where a server with a secure element, like an HSM, signs data using a terminal's private key, encrypts the signature with a transport key calculated from re-authentication and user authentication keys, and sends it to the terminal for decryption and verification by a third party, ensuring high security levels by using ephemeral keys and anti-replay mechanisms.
This solution provides secure data signing and transmission, reducing the attack window by using short-lived re-authentication keys and ensuring only the user and terminal can access the signed data, thus enhancing transaction security and compliance with high security standards like European eiDAS regulations.
Smart Images
Figure EP2023087477_25072024_PF_FP_ABST
Abstract
Description
[0001] Description
[0002] Data signing processes, provision of signed data, associated terminal and server
[0003] Prior art
[0004] The present invention lies in the field of providing data in a telecommunications network and more specifically in that of providing signed data.
[0005] Today, a very large number of electronic transactions are carried out using a mobile terminal and these transactions must be secure.
[0006] For example, the European Union has established an elDAS regulation (Electronic IDentification Authentication and trust Services) on electronic identification and trust services for electronic transactions.
[0007] Certain provisions of this regulation, for example, impose a level of security that can only be obtained with mobile terminals containing certified hardware security elements, for example a SIM card (Subscriber Identity Module) or TEE (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)".
[0008] Unfortunately, in the current state, most deployed mobile terminals do not include such components.
[0009] One proposed solution, 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 (Near Field Communication) chip, and to place this card on the back of the mobile terminal to carry out a transaction.
[0010] It was determined that this solution was not satisfactory for users.
[0011] Subject matter and summary of the invention
[0012] According to a first aspect, the invention relates to a method for signing data implemented by a server and comprising steps of:
[0013] - receipt of a request to sign at least one piece of data sent by a terminal via a network;
[0014] - obtaining, by a secure element of the server, a signature of said at least one piece of data using a private key associated with the terminal, said signature being intended to be verified by a third party knowing a public key associated with said private key;
[0015] - obtaining a terminal re-authentication key from the network;
[0016] - encrypting the signature with an encryption function shared with the terminal and using a transport key calculated from the re-authentication key and at least one other authentication key of the terminal or a user of the terminal; and - sending the encrypted signature to the terminal.
[0017] Correlatively, the invention relates to a data signature server comprising:
[0018] - a module for receiving a signature request for at least one piece of data sent by a terminal via a network;
[0019] - a secure element configured to obtain a signature of said at least one piece of data using a private key associated with the terminal;
[0020] - a module for obtaining a re-authentication key for the terminal from the network;
[0021] - a signature encryption module with an encryption function shared with the terminal and using a transport key calculated from the re-authentication key and at least one other authentication key of the terminal or of a user of the terminal; and
[0022] - a module for sending the encrypted signature to the terminal.
[0023] According to a second aspect, the invention relates to a method for providing signed data implemented by a terminal and comprising steps of:
[0024] - sending a request to sign at least one piece of data to a server via a network;
[0025] - obtaining a terminal re-authentication key from the network;
[0026] - receipt of an encrypted signature;
[0027] - decryption of the encrypted signature with an encryption function shared with the server and using a transport key calculated from the re-authentication key and at least one other authentication key of the terminal or of a user of the terminal to obtain a signature of said data calculated using a private key associated with the terminal; and
[0028] - sending the signature to a third party configured to verify the validity of the signature with a public key associated with said private key, this third party being able to be a service provider requesting said signed data.
[0029] Correlatively, the invention relates to a terminal comprising:
[0030] - a module for sending a signature request for at least one piece of data to a server via a network
[0031] - a module for obtaining a re-authentication key for the terminal from the network;
[0032] - a module for receiving an encrypted signature;
[0033] - a module for decrypting the encrypted signature with an encryption function shared with the terminal and using a transport key calculated from the re-authentication key and at least one other authentication key of the terminal or of a user of the terminal to obtain a signature of said data calculated using a private key associated with the terminal; and
[0034] - a module for sending the signature to a third party configured to verify the validity of the signature with a public key associated with said private key.
[0035] The invention also relates to a system for providing signed data comprising at least one terminal and at least one server as mentioned above.
[0036] Thus, and in general, 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 having a secure element conforming to the security level required for this transaction.
[0037] In a particular embodiment, this secure element is an HSM (Hardware Security Module) component, 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.
[0038] In a particular embodiment of the invention, the HSM component complies with the AVA.VAN5 security level for the protection of the user's signature keys.
[0039] In accordance with the invention, the signature obtained by this secure element is encrypted by an entanglement of several keys including at least one key for re-authenticating the terminal with the network.
[0040] In one embodiment of the signing method or the provisioning method, the reauthentication key used is the current key and the server does not specifically trigger a reauthentication of the terminal to force the regeneration of the key.
[0041] In one embodiment, the server forces re-authentication of the terminal to regenerate the re-authentication key just before calculating the signature.
[0042] In one embodiment, the server forces re-authentication of the terminal to regenerate the re-authentication key after a relatively short delay, for example thirty seconds after sending the signature.
[0043] In one embodiment of the signature method or the provision method, the re-authentication key is obtained by a method of re-authenticating a SIM card of the terminal with the attached mobile network and triggered by said server.
[0044] This embodiment also ensures 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.
[0045] In one embodiment, the server triggers a re-authentication of the terminal with the network to regenerate the re-authentication key after sending the encrypted signature to the terminal, for example thirty seconds after this sending.
[0046] In a particular embodiment, this re-authentication method is an EAP-AKA (Extensible Authentication Protocol-Authentication and Key Agreement) type method.
[0047] This embodiment is particularly advantageous because the EAP-AKA mechanism makes it possible to ensure that the reauthentication key (CK, IK) known per se 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 reauthentication of the terminal with the network, allowing it a predetermined time to complete its transaction, for example one minute, so as to overwrite the reauthentication key used by the server to encrypt the signature and by the terminal to decrypt the signature.In any case, it should be remembered that the rules for configuring mobile networks established by the GSMA within the framework of inter-operator roaming agreements require systematic re-authentication of users at least every ten network events (change of cell, call reception, call transmission, new data connection, change of radio zone, re-attachment to the network after a radio outage, reception / transmission of SMS / MMS messages, etc.).
[0048] Thus, hacking of the solution proposed by the invention is only possible during a relatively short or even very short lifetime of this re-authentication key after the end of the transaction.
[0049] As a reminder, during a HIGH level security assessment, according to European eiDAS regulations, the assessment laboratories have 3 months to carry out the attacks; the invention makes the attack system more complicated because it must be carried out in practice at the latest within minutes of the transaction.
[0050] In one embodiment of the signing method or the providing method, the signature comprises:
[0051] - a timestamp data of a moment of calculation of said signature;
[0052] - a hash of a concatenation of the data to be signed and said timestamp data; and
[0053] - data obtained by encrypting said hash with another encryption function using said private key, one function used to calculate said hash and the other encryption function being shared between said server and said third party.
[0054] This other encryption function, for example, implements an RSA (Rivest-Shamir-Adleman) type mechanism.
[0055] In this embodiment described here, the use of a timestamp data (and / or possibly another anti-replay mechanism) offers an additional level of security since it allows the third party to verify the time at which the signature it receives was calculated by the server. If the reception of the signature by the third party is too late in relation to this calculation time, it 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 a replacement or a supplement of this timestamp with a transaction serial number coupled or not with random data.
[0056] In one embodiment of the signing method or the providing method, 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 user of the terminal.
[0057] This embodiment also ensures that only the user of the terminal will be able to access the signed data to share it with the third party.
[0058] In one embodiment of the signature method or the provision method, the transport key is calculated from a key calculated using a derivation function shared between the terminal and the server and a key of an application of a secure electronic wallet of the terminal. The calculation and composition of the plurality of these different session keys (reauthentication key, personal service code, application key) 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 interweaving of possession factors (SIM card, electronic wallet application) and knowledge (service code), combined with the lifetime of the ephemeral elements (reauthentication key, timestamp data) makes it possible to drastically reduce the attack surface of the proposed solution.
[0059] This embodiment further ensures that only the user and terminal using this specific electronic wallet application will be able to access the signed data to share it with the third party.
[0060] 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 soon as this new key, or a diversification of this key, is known to the server.
[0061] In a particular embodiment, the various steps of the data signing method or the method of providing signed data are determined by computer program instructions or are implemented by a silicon chip which comprises transistors adapted to constitute logic gates of non-programmable hard-wired logic.
[0062] Consequently, 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.
[0063] This program may use any programming language, and may be in the form of source code, object code, or code intermediate between source code and object code, such as in a partially compiled form, or in any other desirable form.
[0064] The invention also relates to a computer-readable information medium, and comprising instructions of a computer program as mentioned above. The information medium may be any entity or device capable of storing the program. For example, the medium may comprise 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. Furthermore, the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means. The program according to the invention may in particular be downloaded from a network such as the Internet. Alternatively, the information medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method in question.
[0065] 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 mobile operators. Brief description of the drawings:
[0066] Other characteristics and advantages of the present invention will emerge from the description given below, with reference to the appended drawings which illustrate exemplary embodiments thereof which are not in any limiting nature. In the figures:
[0067] Figure 1 schematically represents a system for providing signed data in accordance with a particular embodiment of the invention;
[0068] Figure 2 illustrates an example of a schematic representation of a terminal conforming to a particular embodiment of the invention;
[0069] Figure 3 illustrates an example of a schematic representation of a server according to a particular embodiment of the invention;
[0070] Figure 4 illustrates an example of a user enrollment phase with a digital identity provider;
[0071] Figure 5 illustrates an example of a phase of enrollment of an application of the terminal of the figure with the server of figure 3;
[0072] Figure 6 represents in flowchart form the main steps of a method for providing signed data and of a method for signing data in accordance with a particular embodiment of the invention;
[0073] Figure 7 represents the hardware architecture of a terminal conforming to a particular embodiment of the invention;
[0074] Figure 8 represents the hardware architecture of a server conforming to a particular embodiment of the invention.
[0075] Description of the embodiments
[0076] Figure 1 schematically represents a system for providing signed data in accordance with a particular embodiment of the invention.
[0077] This system allows a U user to send signed data to a third party 3RDP using their TRMu terminal. This data is, for example, personal data provided by a FIN digital identity provider. In this example, the TRMu terminal is a TRMu mobile terminal connected to a mobile network by a NET home network.
[0078] Figure 2 schematically represents the TRMu terminal of a user U in one embodiment of the invention.
[0079] Figure 3 schematically represents the SRV server in one embodiment of the invention.
[0080] The user's TRMu terminal includes a TCOM communication module on the mobile network and a SIMu SIM card, the user U being able to authenticate himself with the SIMu card using a PIN code (Personal Identification Number) PIN in a known manner. c u.
[0081] The SRV server comprises a SCOM communication module and a secure element constituted here by an HSM component. In the embodiment described here, the TRMu terminal comprises a secure element SE. A secure element is a separate chip which contains a secure processor, tamper-evident storage and execution memory. This processor, different from the host processor of the TRMu terminal, allows signed transactions to be carried out.
[0082] In the embodiment described here, the TRMu terminal comprises 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 application ID_W or in the secure element SE of the TRMu mobile terminal.
[0083] In the embodiment described here, 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 key derivation functions. These functions are shared with the ID_W application.
[0084] In the embodiment described here, the HSM component comprises a timestamp module MH, a hash function H and a second encryption function ch iffi.
[0085] In the embodiment described here, the hash function H and the second encryption function chiff2 are shared with the third party 3RDP.
[0086] In the described embodiment, the method for providing signed data comprises a first enrollment phase, for enrolling the user U with a digital entity provider FIN.
[0087] This first enrollment phase is illustrated in Figure 4 in a particular embodiment of the invention. In this embodiment, 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 and elliptic curve type algorithms.
[0088] In the embodiment described here, 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 application ID_W.
[0089] In the embodiment described here, it is assumed that the digital identity provider FIN provides the user (step R20) with data that may be shared by the user with at least one third party 3RDP. In the exemplary embodiment described here, this data is 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 is recorded in memory registers of the application ID_W as illustrated in FIG. 2.
[0090] 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.
[0091] In the embodiment of this second enrollment phase described here, it is assumed that the application ID_W provides (step R30) to the server SRV a profile Pu of the user U comprising the application key Kw, his private key K SEC u obtained from the digital identity provider FIN and a personal service code PIN s u.
[0092] In another embodiment, 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 PUBu) within the HSM and returns the generated public key to the digital identity provider FIN and to the ID_W application. The key pair of the user U is then stored encrypted locally on the SRV server, the SRV server knowing at any time how to restore the key context and the profile Pu of the user U to process any future signature request from the user via his ID_W application. In this other embodiment, - the generation of the key pair within the HSM allows access to other more advanced cryptography services, known to those skilled in the art and in particular the possibility for a private key ( K SEC u) already allocated to user U to generate different public keys for multiple digital identity providers FINkIn the embodiment described herein, this personal service code PIN s u is different from the personal PIN code cu of the SIMu SIM card. The personal service code used later during the secure data provision process, always noted PIN s u 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.
[0093] In the embodiment described herein, this personal service code PIN s u can be stored, directly or in a diversified manner depending on the state of the art, in the secure element SE of the mobile terminal TRMu or directly in the memory associated with the ID_W application as illustrated in figure 2.
[0094] In the embodiment described here, the SRV server stores the profile Pu of the user U in a database BD as illustrated in Figure 4.
[0095] Figure 6 represents in flowchart form the main steps of the signed data provision 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.
[0096] During a step E10, the user U uses an IHM interface of his ID_W application to select an ATTu attribute and a third party 3RDP to whom he wishes to provide this attribute.
[0097] According to the invention, the ATTu attribute must be signed with the private key K SEC u allocated to user U by the FIN identity provider and kept secret by the HSM component of the SRV server.
[0098] During a step E20, the ID_W application of user U sends an RS signature request to the SRV server to ask it to sign this ATTu attribute.
[0099] In a particular embodiment of step E20, the ATT attribute to be signed is not sent "in 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 retrieve the clear value of the attribute. During a step E30, 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 user U by the identity provider.
[0100] During a step E40, 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 user U.
[0101] During a step E50, 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 (attribute ATTu, timestamp Horo(t)) and encrypts this hash Hu with the private key K SEC u allocated to user U using the second encryption function chifTi.
[0102] We note (Hu)* the result of this encryption of the hash Hu.
[0103] During a step E60, the HSM component responds to the signature request (step E40) by returning to the SRV server a SIG signature comprising the timestamp data Horo(t), the attribute ATTu and the result (Hu)* of the encryption of the hash Hu.
[0104] During a step E70, the SRV server forces a re-authentication of the TRMu terminal of the user U at the level of the attached mobile network NET.
[0105] In a particular embodiment, this forced re-authentication step E70 comprises the following steps E71 to E74.
[0106] During a step E71, the SRV server sends to the mobile network NET a request from the EAP-AKA family, or one of its extensions, for re-authentication of the SIMu SIM card of the user U.
[0107] It is recalled that the EAP-AKA (Authentication and Key Agreement) method is an EAP method for clients of 3rd generation mobile telephone networks (UMTS and CDMA2000). It is described in RFC 4187 and multiple variants exist depending on the generation of the targeted mobile network and the capabilities of the terminals. As a reminder, the EAP protocol family is a network communication protocol incorporating 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.
[0108] For this purpose, 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. In the remainder of the description, the term "reauthentication key CKIK" will be either the key {CK, IK} OR one of its derivations or any secret element intrinsic to the EAP-AKA exchange and shared at least between the SIM card SIMu, the home network NET and potentially the terminal TRMu.
[0109] During a step E74, the mobile network NET checks the RP response and if the SIMu SIM card is re-authenticated, it returns to the SRV server a CROK response and the re-authentication key CKIK.
[0110] A result of this reauthentication procedure E70 is to make available to the SRV server the reauthentication key CKIK available after the reauthentication procedure at the SIMu SIM card of the terminal. In the embodiment described here, during a step E80, the SRV server calculates a derived key CKIK* from the reauthentication key CKIK using the first key derivation function fctA shared with the ID_W application of the TRMu terminal.
[0111] In the embodiment described here, during a step E90, the SRV server calculates a KPIN key derived from the personal service code PIN s u of 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.
[0112] In the embodiment described here, during a step E100, the server SRV calculates a key KAPP derived from the application key Kw obtained during the enrollment phase (step R30) using the third key derivation function fctc shared with the application ID_W of the terminal TRMu.
[0113] In the embodiment described here, during a step E110, the SRV server calculates a transport key KT from:
[0114] - the CKIK* key derived from the CKIK re-authentication key in step E80;
[0115] - the KPIN key derived from the personal service PIN code s u at step E90; and
[0116] - the KAPP key derived from the application key Kw in step E100; using the fourth key derivation function fctr shared with the ID_W application of the TRMu terminal.
[0117] In a first variant, during step E110, the SRV server calculates the transport key KT from:
[0118] - the CKIK* key derived from the CKIK re-authentication key in step E80; and
[0119] - the KPIN key derived from the personal service PIN code s u in step E90; and using the fourth key derivation function fctr shared with the ID_W application of the TRMu terminal.
[0120] In a second variant, during step E110, the SRV server calculates the transport key KT from:
[0121] - the CKIK* key derived from the CKIK re-authentication key in step E80; and
[0122] - the KAPP key derived from the application key Kw in step E100; using the fourth key derivation function fctr shared with the ID_W application of the TRMU terminal.
[0123] During a step E120, the SRV server encrypts the SIG signature received from the HSM component in step E60 with the first encryption function using the transport key KT.
[0124] 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.
[0125] During a step E140, the application ID_W:
[0126] - obtains the CKIK stored in the SIMu SIM card at the end of the forced re-authentication step E70 and finds the CKIK* key using the first derivation function fctA;
[0127] - obtains the Kw application key stored for example in the SE secure element of the TRMu terminal and retrieves the KAPP key using the third derivation function fctc; - asks the user to enter his personal service code PIN su and finds the KPIN key using the second derivation function fctB; and
[0128] - calculates the transport key KT from CKIK*, KPIN and KAPP using the fourth key derivation function fctr shared with the SRV server.
[0129] During a step E150, 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 attribute ATTu 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 user U. Alternatively, this decryption could be performed by a decryption module of the TRMu terminal independent of the ID_W application.
[0130] In the embodiment described here, during a step E160, the application ID_W sends to the third party 3RDP a message M comprising the signature SIG and a complement C comprising the public key K PUB u allocated to user U by the identity provider FIN. We recall that the SIG signature in this example includes the timestamp Horo(t), the attribute ATTu, a hash (Hu)* of this data encrypted with the private key K^u allocated to user U by the identity provider FIN and kept secret by the HSM component.
[0131] In this embodiment, the third party 3RDP is thus autonomous in verifying the SIG signature thanks to the reception of the user's public key and its knowledge of the hash function H and the second encryption function chifTi.
[0132] Figure 7 represents the hardware architecture of a TRMu terminal according to a particular embodiment of the invention. This terminal comprises:
[0133] - a processing unit or processor 701, or CPU, intended to load instructions into memory, to execute them, to carry out operations;
[0134] - a set of memories, including a volatile memory 702, or RAM used to execute code instructions, store variables, etc., and a storage memory 703 of EEPROM type. In particular, the storage memory 703 is arranged to store a PGF software module for providing signed data which comprises code instructions for implementing the steps of the method for providing signed data as described previously.
[0135] Figure 8 represents the hardware architecture of an SRV server according to a particular embodiment of the invention. This server comprises:
[0136] - a processing unit or processor 801, or CPU, intended to load instructions into memory, to execute them, to carry out operations;
[0137] - a set of memories, including a volatile memory 802, or RAM used to execute code instructions, store variables, etc., and a storage memory 803 of EEPROM type. In particular, the storage memory 803 is arranged to store a PGS signature software module which comprises code instructions for implementing the steps of the signature method as described previously. In the embodiment described previously, the signed data are attributes linked to the identity of the user.
[0138] But data of any type can be signed by the invention.
[0139] In particular, the signed data may be a combination of attributes. Furthermore, instead of providing an attribute as such, the invention may be used to provide a cryptographic derivation of that attribute, for example using a zero-knowledge proof algorithm.
Claims
CLAIMS
1. Data signature method (ATTu) implemented by a server (SRV) and comprising steps of: - reception (E20) of a request (RS) for signature of at least one data item (ATTu) sent by a terminal (TRMu) via a network (NET); - obtaining (E60), by a secure element (HSM) of the server, a signature (SIG) of said at least one data item (ATTu) using a private key (K SEC u) associated with the terminal (TRMu), said signature (SIG) being intended to be verified by a third party (3RDP) knowing a public key (K PUB u) associated with said private key (K SEC u); - obtaining (E74) a re-authentication key (CKIK) from the terminal (TRMu) to the network (NET); - encryption (E120) of the signature (SIG) with an encryption function (chiffi) shared with the terminal (TRMu) and using a transport key (KT) calculated (El 10) from the reauthentication key (CKIK) and at least one other key (KPIN, KAPP) for authentication of the terminal (TRMu) or of a user (U) of the terminal (TRMu); and - sending (E130) of the encrypted signature (SIG*) to the terminal (TRMu).
2. Method for providing signed data implemented by a terminal (TRMu) and comprising steps of: - sending (E20) a request (RS) to sign at least one piece of data (ATTu) to a server (SRV) via a network (NET); - obtaining (E73) a re-authentication key (CKIK) from the terminal (TRMu) to the network (NET); - receipt (E130) of an encrypted signature (SIG*); - decryption of the encrypted signature (SIG*) with an encryption function (chiffi) shared with the server (SRV) and using a transport key (KT) calculated (E140) from the reauthentication key (CKIK) and at least one other key (KPIN, KAPP) for authentication of the terminal (TRMu) or of a user (U) of the terminal (TRMu) to obtain a signature (SIG) of said data (ATTu) calculated using a private key (K SEC u) associated with the terminal (TRMu); and - sending (E160) the signature (SIG) to a third party (3RDP) configured to verify the validity of the signature with a public key (K PUB u) associated with said private key (K^u).
3. Method according to claim 1 or 2, characterized in that said signature (SIG) comprises: - a timestamp data (Horo(t)) of a time (t) of calculation (E60) of said signature; - a hash (Hu) of a concatenation of said data to be signed (ATTu) and said timestamp data (Horo(t)); and - a data ((Hu)*) obtained by encrypting said hash (Hu) with another encryption function (chifl) using said private key (K SEC u), a function (H) used to calculate said hash and the other encryption function (chiff2) being shared between said server (SRV) and said third party (3RDP).
4. Method according to any one of claims 1 to 3, characterized in that said reauthentication key (CKIK) is obtained (E73, E74) by a method of reauthenticating a SIM card (SIMu) of the terminal (TRMu) triggered by said server (SRV).
5. Method according to any one of claims 1 and 3 to 4, characterized in that the server (SRV) triggers a re-authentication of the terminal (TRMu) with the network (NET) to regenerate the re-authentication key (CKIK) after sending the encrypted signature (SIG*) to the terminal (TRMu), for example thirty seconds after said sending.
6. The method of claim 4 or 5, wherein said reauthentication method is an EAP-AKA type method.
7. Method according to any one of claims 1 to 6, characterized in that said transport key (KT) is calculated (E110, E140) from a key (KPIN) calculated (E90, E140) using a derivation function (fcts) shared between the terminal (TRMu) and the server (SRV) and a personal service code (PIN s u) of a user (U) of the terminal (TRMu).
8. Method according to any one of claims 1 to 7, characterized in that said transport key (KT) is calculated (E110, E140) from a key (KAPP) calculated (E100, E140) using a derivation function (fctc) shared between the terminal (TRMu) and the server (SRV) and a key (Kw) of an application (ID_W) of a secure electronic wallet (ID_ W) of the terminal (TRMu).
9. Data signature server (SRV) (ATTu) comprising: - a module (SCOM) for receiving a request (RS) for signing at least one piece of data (ATTu) sent by a terminal (TRMu) via a network (NET); - a secure element (HSM) configured to obtain a signature (SIG) of said at least one data item (ATTu) using a private key (K SEC u) associated with the terminal (TRMu); - a module (SCOM) for obtaining a re-authentication key (CKIK) from the terminal (TRMu) to the network (NET); - a module (MCRY) for encrypting the signature (SIG) with an encryption function (chiffi) shared with the terminal (TRMu) and using a transport key (KT) calculated from the re-authentication key (CKIK) and at least one other key (KPIN, KAPP) for authenticating the terminal (TRMu) or a user of the terminal (TRMu); and - a module (SCOM) for sending the encrypted signature (SIG*) to the terminal (TRMu).
10. Terminal (TRMu) comprising: - a module (TCOM) for sending a request (RS) for signing at least one piece of data (ATTu) to a server (SRV) via a network (NET); - a module (SIMu) for obtaining a re-authentication key (CKIK) from the terminal (TRMu) to the network (NET); - a module (TCOM) for receiving an encrypted signature (SIG*); - a module (ID_W) for decrypting the encrypted signature (SIG*) with an encryption function (chiffi) shared with the terminal (TRMu) and using a transport key (KT) calculated from the re-authentication key (CKIK) and at least one other key (KPIN, KAPP) for authenticating the terminal (TRMu) or a user of the terminal (TRMu) to obtain a signature (SIG) of said data (ATTu) calculated using a private key (K SEC u) associated with the terminal (TRMu); and - a module (TCOM) for sending (E160) the signature (SIG) to a third party (3RDP) configured to verify the validity of the signature with a public key (K PUB u) associated with said private key (K SEC u).
11. System for providing signed data comprising: - at least one terminal (TRMu) according to claim 10; and - at least one server (SRV) according to claim 9.
12. Computer program (PGS) comprising instructions for executing the steps of a data signing method according to any one of claims 1 or 3 to 8 when said program is executed by a computer (SRV).
13. Computer program (PGF) comprising instructions for carrying out the steps of a method for providing signed data according to any one of the claims 2 to 8 when said program is executed by a computer (TRMu).
14. Computer-readable recording medium on which a computer program (PGS, PGF) according to claim 12 or 13 is recorded.