WO2016034812A1 - Sécurisation de clés de cryptage pour transaction sur un dispositif dépourvu de module sécurisé - Google Patents

Sécurisation de clés de cryptage pour transaction sur un dispositif dépourvu de module sécurisé Download PDF

Info

Publication number
WO2016034812A1
WO2016034812A1 PCT/FR2015/052316 FR2015052316W WO2016034812A1 WO 2016034812 A1 WO2016034812 A1 WO 2016034812A1 FR 2015052316 W FR2015052316 W FR 2015052316W WO 2016034812 A1 WO2016034812 A1 WO 2016034812A1
Authority
WO
WIPO (PCT)
Prior art keywords
encryption key
mobile device
key
personal data
cryptogram
Prior art date
Application number
PCT/FR2015/052316
Other languages
English (en)
Inventor
Eric LASSOUAOUI
Francis LIMOUSY
Original Assignee
Oberthur Technologies
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 Oberthur Technologies filed Critical Oberthur Technologies
Publication of WO2016034812A1 publication Critical patent/WO2016034812A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/325—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices using wireless networks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4012—Verifying personal identification numbers [PIN]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/062—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key distribution, e.g. centrally by trusted party
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network
    • H04L63/068—Network architectures or network communication protocols for network security for supporting key management in a packet data network using time-dependent keys, e.g. periodically changing keys
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/04—Key management, e.g. using generic bootstrapping architecture [GBA]
    • H04W12/041—Key generation or derivation
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
    • H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload

Definitions

  • the present invention generally relates to the field of cryptography, and more particularly that of securing encryption keys, used for example during transactions.
  • the present invention aims in particular a method and a cryptographic processing device implementing an increased security of an encryption key.
  • Such payment applications such as applications compliant with the international EMV security standard (Europay, Mastercard, Visa), are conventionally provided in highly secure smart cards. These smart cards are introduced in a reader or "payment terminal” or POS (for "Point Of Sale") for the purpose of carrying out the financial transaction.
  • the chips may be provided with wireless communication means allowing the financial transaction without insertion into a reader.
  • they can also be embedded by a user terminal, such as a telephone, operating as a smart card reader for the transaction.
  • chips also called secure element (SE for “Secure Element” or hardware security element (HSE for “Hardware Security Element”
  • SE Secure Element
  • HSE hardware security element
  • HSE Hard Security Element
  • Such secure elements are not always available. Furthermore, for cost reasons, it may also be desirable not to have to distribute such chips to a large number of users. It may also be desirable to limit the dependence of the transactions on the physical ownership of such chips, so that these transactions turn out to be more flexible for the users.
  • the invention therefore relates to a cryptographic processing method, comprising, on a mobile device, mobile phone type, unsecure smart card, etc., a step of obtaining an encryption key, an encryption step of a message, for example a financial transaction message, using the encryption key obtained to obtain a cryptogram and a step of sending the cryptogram, which includes for example the information relating to the transaction, to a remote server of transaction.
  • the present invention aims to solve all or part of the disadvantages noted in the techniques of the prior art.
  • said encryption key has a limited lifetime, for example for a transaction or a communication session, thus implying a frequent renewal of this encryption key.
  • Such a key is thus akin to a "session key" for its ephemeral lifetime.
  • the step of obtaining the encryption key by the mobile device includes the following steps, when a previous encryption key obtained by the mobile device is out-of-date (i.e. the key has expired):
  • a secure remote server receives, from a secure remote server, a new encrypted encryption key, enter personal data on an input interface connected to the mobile device, for example via an interface of a payment terminal or via the keypad of a mobile phone forming or hosting the mobile device,
  • the personal data is only temporary on the mobile device.
  • the method according to the invention makes it possible to secure the access and the storage of the generated transaction keys even though the device mobile has no security mechanisms. Indeed, the keys generated because of their peremptions are held by a secure remote server.
  • the present invention makes it possible to reduce the risks of failure of a transaction by avoiding the calculation of the cryptogram by the secure remote server and exchanges of information between the mobile device and this server for the purposes of this calculation. while maintaining a high level of security.
  • the latency of at least 200 milliseconds mentioned in the aforementioned publication is greatly reduced.
  • the invention also relates to a mobile device, such as a mobile phone, an unsecured smart card, etc., comprising a module for obtaining an encryption key, a cryptographic module configured to encrypt a message, for example a message financial transaction, using the encryption key obtained to obtain a cryptogram and a communication module configured to send the cryptogram, which includes for example the information relating to the transaction, to a remote server transaction.
  • a mobile device such as a mobile phone, an unsecured smart card, etc.
  • a module for obtaining an encryption key a cryptographic module configured to encrypt a message, for example a message financial transaction, using the encryption key obtained to obtain a cryptogram
  • a communication module configured to send the cryptogram, which includes for example the information relating to the transaction, to a remote server transaction.
  • said encryption key has a limited lifetime.
  • the module for obtaining the encryption key is configured to, when a previous encryption key obtained by the mobile device is out of date:
  • a secure remote server receives, from a secure remote server, a new encrypted encryption key, obtain personal data entered by a user on an input interface connected to the mobile device, for example via an interface of a payment terminal or via the keypad; a mobile phone forming or hosting the mobile device,
  • the invention also relates to a computer program product comprising instructions adapted to the implementation of each of the steps of the method described above when said program is executed on a computer.
  • the mobile device and the computer program product according to the invention have advantages similar to those previously described in connection with the method.
  • the cryptographic processing method may be part of a communication method, an example of which is described in detail later.
  • the mobile device is part of a system as described below.
  • the personal data is a PIN code entered by a user. This configuration makes it possible to preserve the conventional interaction of the user without requiring the entry of new data for the purposes of the invention.
  • a decryption key for decrypting the encrypted encryption key is formed from the personal data entered and data common to the mobile device and the remote secure server. This configuration improves the security of the encryption key provided, encrypted by the remote secure server.
  • the method comprises transmitting the new encryption key from the secure remote server to the remote transaction server. This disposition allows the latter server to be able to validate the cryptogram received from the mobile device.
  • said encryption key is selected from a linked list or series of keys generated from a root key and a one-way function applied to the previously generated key, that is, that is, the generation of keys is recursive. Said selection is furthermore performed in the reverse order of key generation, meaning that the last key generated is used first, and the first key generated last. This allows a secure renewal of the keys.
  • the cryptogram comprises information relating to a computer transaction, for example relating to a financial transaction, such as an amount.
  • a computer transaction such as a reservation, purchase, or payment, includes the implementation of an atomic, consistent, isolated, and durable sequence of operations that pass a transaction database from one state to another. A, prior to the transaction, to a state B posterior thereto.
  • the encryption key is renewed after a fixed number of cryptogram generations, that is to say after a fixed number of transactions using this key, for example at each new computer transaction. This provision makes it possible to guarantee a regular renewal of the encryption keys.
  • the decryption of the encryption key received implements a symmetric key cryptographic algorithm.
  • This arrangement allows rapid processing of both the encryption of this key by the remote server and the decryption thereof by the mobile device.
  • the latency introduced by the treatments according to the invention is minimized.
  • FIG 1 schematically shows an infrastructure in which embodiments of the present invention are implemented
  • FIG 2 illustrates an example of hardware architecture for the equipment shown in Figure 1;
  • FIGS. 3a, 3b and 3c illustrate, in the form of flow charts, general process steps for an implementation of the invention, respectively at the level of the mobile device, the authentication server and the remote secure server of FIG. 1;
  • FIG. 4 illustrates the message exchanges between the equipment of FIG. 1 during an implementation of the invention. DETAILED DESCRIPTION OF THE INVENTION
  • FIG 1 illustrates an example of an infrastructure in which the present invention can be implemented. This infrastructure may be similar to that described in the aforementioned publication US 2013 / 054,474.
  • the infrastructure 1 comprises a mobile device 10, a point of sale POS 12 officiating as reader of the mobile device 10, one or more communication networks 14, a user authentication server 16, a transaction server 17 and a server 18.
  • a single mobile device 10 is shown, a plurality of mobile devices 10 owned by a plurality of respective users is widely contemplated to concomitantly or non-concurrently one or more transactions requiring the implementation of the invention.
  • the mobile device 10 can be any type of user equipment with a memory and processing means, CPU type, for storing and executing an application requiring a secure cryptographic service. This is for example a payment application requiring the use of a key to encrypt or encrypt the information relating to the financial transaction.
  • the mobile device may be a mobile phone, an unsecured chip card processing module.
  • the mobile device 1 0 comprises in particular wireless communication means in accordance with ISO / IEC 14443, in order to communicate with the reader 12.
  • the mobile device can implement the NFC protocol.
  • contact communication means ISO / IEC 7816 or wired (USB) can be envisaged.
  • the mobile device 10 may also comprise means of communication with the authentication server 16 via a communication network 14, such as a wide area network such as the mobile telephone network or the Internet network.
  • a communication network 14 such as a wide area network such as the mobile telephone network or the Internet network.
  • FIG. 2 represents an example of a hardware architecture for an equipment such as the mobile device 1 0.
  • the equipment comprises a communication bus 2 to which are connected:
  • non-volatile memories 22 for example ROM (for Read Only Memory), EEPROM (for Electrically Erasable Read Only Memory) or Flash, storing for example the payment application;
  • a communication interface 26 adapted to transmit and receive data, for example via a telecommunications network or a read / write interface.
  • the equipment may comprise an input / output I / O interface (for Input / Output), for example a screen, a keyboard, a mouse or other pointing device such as a touch screen or a remote control; this I / O interface allows a user to interact with the system during the implementation of the method via a graphical interface, in particular to enter a PIN code as described below.
  • I / O interface for Input / Output
  • a user allows a user to interact with the system during the implementation of the method via a graphical interface, in particular to enter a PIN code as described below.
  • RAM 24 includes registers adapted to the recording of variables and parameters created and modified during the execution of a computer program comprising instructions for implementing steps of a method according to the invention when of its implementation.
  • the instruction codes of the program stored in non-volatile memory are loaded into RAM memory for execution by the CPU processing unit.
  • the communication bus allows communication and interoperability between the different elements shown in FIG. 2.
  • the representation of the bus is not limiting and, in particular, the processing unit is able to communicate instructions to any element of the bus. equipment represented, directly or through another element of it.
  • POS POS 12 can be any type of conventional payment terminal, equipped with a reader capable of communicating with mobile device 10.
  • the reading can be of the RFID type or according to ISO / IEC 14443 or even with contact.
  • POS POS 12 also has means of communication on the network 14 to communicate with the transaction server 17 (which may be common with the authentication server 16).
  • the transaction server 17 is conventional. Of course, a plurality of servers may be provided to perform all the functions exposed thereafter.
  • the payment terminal 12 may have the hardware architecture shown in Figure 2, further equipped with a reader as described above.
  • the authentication and transaction server 16 is connected to the communication network 14 for the purpose of establishing a secure connection with the mobile device 10 for carrying out a transaction.
  • the server 16 has a connection, either directly or via a wide area network such as the network 14 to the remote secure server 18 to obtain an updated encryption key as explained below.
  • the secure server 18 may be a web server hosted in the authentication server 1 6.
  • the server 16 may be in accordance with the hardware architecture shown in FIG.
  • the remote secure server 1 8 comprises for example a secure module SE storing a linked list of encryption keys for the mobile device 10.
  • the remote secure server 18 is implemented in such a secure module SE, for example a server in a smart card.
  • the smart card can be installed in the server 16 and communicate by APDU units according to the ISO 7816 protocol. In the rest of the description, reference will be made mainly to a "secure module" 18.
  • the remote secure module 1 8 stores in memory a master key MK for each transaction application (for example payment) implemented by a mobile device 10.
  • the master key MK is used as the starting point of a process generating a list of transaction keys or "session keys" used by the mobile devices 10 to encrypt the transaction information in cryptogram. This generation is also known as diversification or derivation of keys.
  • the generation of the key series is performed using a one-way function f applied recursively to MK and then to each generated key SK n :
  • n 1024.
  • the keys are provided to the mobile device 10 in reverse order of the linked list, i.e. in the order n, n-1, n-2 , 2, 1.
  • n, n-1, n-2 , 2, 1 the keys are provided to the mobile device 10 in reverse order of the linked list, i.e. in the order n, n-1, n-2 , 2, 1.
  • the master key MK is never transmitted and can be reused to produce a new linked list, for example by using another one-way function (having for example a different parameterization).
  • SK can be obtained directly by a function f (SK, i).
  • each encryption key thus generated has a limited life span from the moment it is put into circulation, that is to say when it is made available by the customer. remote secure module.
  • the encryption key that is in use is called "current key”.
  • the limited lifetime can be defined by a renewal frequency of the current key. For example, every Sunday at midnight the current key SK j becomes obsolete and is replaced by the new current key SK j . ! .
  • this limited lifetime can be defined with respect to a number of transactions using the current key.
  • This mechanism of regular regeneration of the current encryption key used for the transactions makes it possible to reduce the risks associated with the compromise of the encryption key.
  • the fact that the current encryption key is transmitted to the mobile device makes it possible for the cryptogram for the transaction to be calculated by the mobile device directly from this encryption key now held locally.
  • the invention provides that the remote secure module communicates the new encryption key in encrypted form using a key formed from a personal data provided by the user.
  • the remote secure module 18 also comprises cryptographic means for encrypting data, and in particular for encrypting the keys SK, using a symmetric key cryptographic algorithm, for example the triple DES algorithm (3DES ): enc3des (SK K SYM ) where enc3des is the Triple DES based encryption function.
  • a symmetric key cryptographic algorithm for example the triple DES algorithm (3DES ): enc3des (SK K SYM ) where enc3des is the Triple DES based encryption function.
  • the symmetric key K SYM used can be generated on the fly from the personal data of the user, when a new key SK, must be communicated.
  • the personal data of the user is saved in memory of the remote secure module to be used in the formation of the symmetric key.
  • This personal data can be entered by the user during a registration procedure or installation of the payment application, allowing for example to associate this personal data to the master key MK corresponding to the installed application.
  • the keys SK are all encrypted in advance and stored as such in the secure module.
  • the personal data of the user is preferably information that the user knows well, such as a PIN code.
  • a PIN code can be the same PIN code as used in an authentication procedure with the server 16.
  • it may be a password, or an extended password ("passphrase" according to the English terminology).
  • the symmetric key is the personal data of the user.
  • the symmetric key is separate from the personal data but calculated from it, possibly only from it, for example from a hash function SHA-256 (PIN).
  • the symmetric key is formed from the personal data of the user and data common to the mobile device and the module. secure remote 18, for example a unique identification number of the payment application considered.
  • the symmetric key can result from a cryptographic calculation on these two data at least, for example AES (common data, PIN) where the common data is used as a key to encrypt the personal data (vice versa).
  • AES common data, PIN
  • a hash function can be applied to the concatenation ("
  • the symmetric key is of greater length and therefore offers a more robust encryption.
  • FIG. 3 illustrates, in the form of flowcharts, general steps of methods at the level of the mobile device (FIG. 3a), the authentication server (FIG. 3b) and the remote secure server (FIG. 3c) for an implementation of FIG. the invention. These steps are described below using an exemplary sequence timing diagram shown in FIG. 4.
  • step 302 the mobile device 1 0 is waiting for a transaction request by the user, for example the launch of a payment application by the user or alternatively an indication by the user a transaction wish within this application.
  • All the following steps of the mobile device 10 may be implemented by the transaction application itself, including the above payment application.
  • the user is prompted to enter an authentication code (PIN or password) in step 304 allowing the mobile device 10 to perform, if the code entered is good, a authentication procedure (step 306) with the server 16.
  • the authentication procedure can implement a "challenge / response" type exchange (stimulation / response) widely known.
  • connection with the authentication server 16 can be initiated by the user before receiving a transaction request (for example before executing the payment application).
  • the authentication can be conducted when the mobile device 10 is started by the user (for example his mobile phone).
  • the authentication code may be the PIN code requested at the start of the mobile terminal 1 0.
  • the authentication server 16 is waiting for an authentication request (test 340).
  • test 340 When such a request is received, it processes the request in a conventional manner (step 342), for example by implementing a "challenge / response" type procedure with the issuer of the request.
  • This processing of step 342 leads to the delivery of an OK message in the event of successful authentication or a NOK message in the event of authentication failure.
  • the authentication server 16 checks whether the current encryption key SK, for the mobile device 10 is valid or outdated (or obsolete) based on obsolescence rules (test 346).
  • the obsolescence of the key SK may result from a duration expired since the issue of this key, an expiration date or a number of transactions already made using this key as described above. for the lifetime of the keys.
  • the authentication server has in memory a table storing a state of the current key or common keys associated with each mobile device 1 0.
  • the authentication server 16 is able to recover, from this memory, the current key or keys.
  • the mobile device 10 may indicate in its authentication request (step 306) the application implemented, so as to allow the server 16 to identify the encryption key associated with the desired transaction.
  • the server 1 6 If the SK key is not obsolete, the server 1 6 returns to step 340 waiting for a new authentication request.
  • the authentication server 16 requests the secure module 18 to obtain a new transaction key. It may be a call to a function of the secure module hosted on the secure module 18. This is the step 348 at the end of which the server 16 obtains this new key, in encrypted form EK i + 1 as described below. It is represented by the arrows 406 (request for a new key), 408 (encoding of the key) and 410 (receipt of the key) in FIG.
  • the secure module of the secure module 18 has been configured during an initialization step 360 in which a linked list of encryption keys ⁇ SK SK 2 , SK n ⁇ has been generated from a master key MK, and this for each application requiring an encryption key and for each mobile device 10.
  • step 362 the variable / designating the next key to be communicated is initialized to n, where n is the number of keys generated from MK.
  • the secure module 18 is thus waiting for a key renewal request (test 364) when the request sent by the server 16 in step 348 is received.
  • the symmetric key is based on a personal data of the user of the PIN code or password type.
  • step 372 is executed to decrement the variable j.
  • the variable y is worth i-1 where / ' is the index of the current key.
  • the method makes it possible to successively select the keys SK from the linked list, in the reverse order of their generation.
  • step 372 the secure module 18 resumes waiting for a key renewal request (step 364).
  • the server 1 6 upon receipt of the encrypted key EK j , that is to say the encrypted version of the new current key SK, the server 1 6 forwards it to the mobile device 10 at step 350 (FIG. arrow 412 in FIG. 4), before waiting for a new authentication request (step 340).
  • test 308 it is checked whether three PIN code tests have been carried out (test 320) in which case a protection action is performed (step 322, for example a deactivation, temporary or permanent, of the mobile device). If there are still trials, the process returns to step 304.
  • the mobile device 10 can receive, from the secure module 18 via the server 1 6, a new encrypted encryption key EK, if the current key is out of date. This is the optional step 310.
  • step 312 the user enters a personal data, typically a code
  • PIN or password on an input interface connected to the mobile device 10, for example the keyboard of a mobile terminal. This step is represented by the arrow 414 of FIG.
  • the payment application may display a window for entering such data in order to authorize or validate the payment.
  • This step 312 is optional in the case where the personal data needed here is the PIN code or password already entered in step 304, in which case the personal data entered can be reused for the decryption of EK. In addition, it is not performed if no encrypted key EK, is decrypted. This is for example the case when the encrypted key EK has been decrypted during a previous iteration and the mobile device 1 0 stores the current key SK, still valid in its decrypted form.
  • the key thus obtained SK can be stored in nonvolatile memory of the mobile device, in which case the encrypted key EK can be deleted.
  • step 314 is optional for the new iterations of the process when the key is not renewed.
  • only the key EK is a backup in the mobile device 10 and is decrypted only during a transaction (and the decrypted value SK is therefore deleted at the end of the transaction - end of the steps 318 and 428 described herein. -Dessous).
  • step 316 the personal data, PIN code or password entered to decrypt the key EK, is deleted from any memory of the mobile device 1 0. This is the arrow 418 in FIG. 4.
  • step E318 consists in carrying out the transaction desired by the user, for example a payment.
  • this payment type transaction consists for example of an action (arrow 420) during which the user presents his mobile device 10 to the POS payment terminal 12 in order to carry out the payment transaction, which step triggers an EMV-compliant exchange of messages between these two entities (arrow 422, arrow 426, and arrow 432 ending the transaction) and a transaction server 1 7 (arrows 428 and 430).
  • the mobile device uses said decrypted encryption key SK, to encrypt transaction information and obtain a cryptogram (arrow 424) to communicate to the transaction server 17 possibly via the POS 12.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • General Business, Economics & Management (AREA)
  • Computer Security & Cryptography (AREA)
  • Strategic Management (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Signal Processing (AREA)
  • Finance (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Computer Hardware Design (AREA)
  • Mobile Radio Communication Systems (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)

Abstract

L'invention concerne la sécurisation de clés de cryptage utilisées lors de transactions lorsque le dispositif utilisateur est dépourvu de module sécurisé. Sur le dispositif, sont réalisés des étapes d'encryptage d'un message avec une clé de cryptage et d'envoi du cryptogramme obtenu à un serveur distant de transaction. La clé de cryptage a une durée de vie limitée. Lorsque la clé de cryptage courante est périmée, le dispositif reçoit, d'un serveur distant sécurisé équipé d'un module sécurisé, une nouvelle clé de cryptage encryptée (310); reçoit une donnée personnelle saisie par un utilisateur sur une interface de saisie (312); décrypte la nouvelle clé de cryptage à l'aide de la donnée personnelle saisie (314); et supprime la donnée personnelle de ses mémoires (316) avant d'utiliser ladite nouvelle clé de cryptage pour obtenir le cryptogramme à envoyer au serveur distant de transaction.

Description

SECURISATION DE CLES DE CRYPTAGE POUR TRANSACTION SUR UN DISPOSITIF
DEPOURVU DE MODULE SECURISE
DOMAINE DE L'INVENTION
La présente invention concerne de façon générale le domaine de la cryptographie, et plus particulièrement celui de la sécurisation de clés de cryptage, utilisées par exemple lors de transactions. La présente invention vise notamment un procédé et un dispositif de traitement cryptographique mettant en oeuvre une sécurisation accrue d'une clé de cryptage.
CONTEXTE DE L'INVENTION
Dans le domaine des communications numériques, il existe un grand nombre d'applications qui font appel à des services cryptographiques sécurisés. C'est par exemple le cas des transactions informatiques telles que les transactions financières mises en oeuvre par des applications de paiement.
De telles applications de paiement, comme par exemple les applications conformes au standard international de sécurité EMV (Europay, Mastercard, Visa), sont classiquement prévues dans des cartes à puce fortement sécurisées. Ces cartes à puce sont introduites dans un lecteur ou « terminal de paiement » ou POS (pour « Point Of Sale ») aux fins de procéder à la transaction financière. En variante, les puces peuvent être munies de moyens de communication sans fil permettant la transaction financière sans insertion dans un lecteur. Enfin, elles peuvent également être embarquées par un terminal utilisateur, tel un téléphone, opérant comme lecteur de la carte à puce pour la transaction.
Ces puces, également dénommés élément sécurisé (SE pour « Secure Elément ») ou élément de sécurité matériel (HSE pour « Hardware Security Elément »), sont particulièrement bien adaptées à la protection des clés cryptographiques. La majorité des mesures de sécurité visant à protéger ces clés est mise en oeuvre au niveau matériel de la carte.
De tels éléments sécurisés ne sont pas toujours disponibles. Par ailleurs, pour des raisons de coût, il peut également être souhaitable de ne pas avoir à diffuser de telles puces à un nombre important d'utilisateurs. Il peut aussi être souhaitable de limiter la dépendance des transactions à la détention physique de telles puces, afin que ces transactions se révèlent être plus souples pour les utilisateurs.
Ainsi, il est apparu un intérêt à prévoir des applications de transaction reposant sur des services cryptographiques au sein même de plateformes matérielles dépourvues de mesures sécuritaires, et par conséquent de tels éléments sécurisés.
Dans la publication US 2003/054,474, une application de paiement est mise en oeuvre dans un dispositif mobile utilisateur sans toutefois détenir la clé cryptographique nécessaire à la réalisation d'une transaction de paiement. Cette clé est détenue par un élément sécurisé distant auquel un serveur d'authentification et de transaction accède. En pratique, cet élément sécurisé distant utilise la clé cryptographique qu'il détient afin de calculer un cryptogramme attendu pour une transaction donnée et le communique au dispositif mobile. Ainsi ce dernier peut transmettre le cryptogramme au terminal de paiement de sorte que la transaction de paiement soit autorisée.
Toutefois ce mode de fonctionnement repose sur un appel de procédure à distance pour récupérer le cryptogramme attendu, qui peut s'avérer particulièrement coûteux en temps. Dans la publication susvisée en lien avec les figures 15 et 16, une latence de 200 millisecondes est évoquée, ce qui semble toutefois constituer une estimation optimise. Or une latence de cet ordre de grandeur ou plus longue peut s'avérer préjudiciable à la réalisation de transactions car, pour des raisons de sécurité, celles-ci sont généralement configurées pour s'interrompre en cas d'attente trop longue.
RESUME DE L'INVENTION
L'invention concerne donc un procédé de traitement cryptographique, comprenant, sur un dispositif mobile, type téléphone mobile, carte à puce non sécurisée, etc., une étape d'obtention d'une clé de cryptage, une étape d'encryptage d'un message, par exemple un message de transaction financière, à l'aide de la clé de cryptage obtenue pour obtenir un cryptogramme et une étape d'envoi du cryptogramme, qui inclut par exemple les informations relatives à la transaction, à un serveur distant de transaction.
La présente invention vise à résoudre tout ou partie des inconvénients relevés dans les techniques de l'art antérieur.
A cet effet, selon l'invention, ladite clé de cryptage a une durée de vie limitée, par exemple pour une transaction ou une session de communication, impliquant de la sorte un renouvellement fréquent de cette clé de cryptage. Une telle clé s'apparente ainsi à une « clé de session » pour sa durée de vie éphémère.
En outre, l'étape d'obtention de la clé de cryptage par le dispositif mobile inclut les étapes suivantes, lorsqu'une précédente clé de cryptage obtenue par le dispositif mobile est périmée (c'est-à-dire que la durée de vie de la clé a expiré) :
recevoir, d'un serveur distant sécurisé, une nouvelle clé de cryptage encryptée, saisir une donnée personnelle sur une interface de saisie connectée au dispositif mobile, par exemple via une interface d'un terminal de paiement ou via le clavier d'un téléphone mobile formant ou hébergeant le dispositif mobile,
décrypter la nouvelle clé de cryptage reçue à l'aide de la donnée personnelle saisie, et supprimer la donnée personnelle saisie du dispositif mobile avant d'utiliser ladite nouvelle clé de cryptage décryptée pour encrypter le message et obtenir le cryptogramme. Ainsi la donnée personnelle n'est que temporaire sur le dispositif mobile.
Comme dans la publication susmentionnée, le procédé selon l'invention permet de sécuriser l'accès et le stockage des clés de transaction générées alors même que le dispositif mobile est dépourvu de mécanismes de sécurité. En effet, les clés générées à raison de leurs péremptions sont détenues par un serveur distant sécurisé.
En outre, la présente invention permet de réduire les risques d'échec d'une transaction en s'affranchissant du calcul du cryptogramme par le serveur distant sécurisé et des échanges d'informations entre le dispositif mobile et ce serveur aux fins de ce calcul, tout en conservant un fort niveau de sécurité. Ainsi, la latence d'au moins 200 millisecondes évoquée dans la publication susvisée est largement réduite.
Cette situation avantageuse et sécurisée est rendue possible par l'invention grâce à la transmission de la nouvelle clé de cryptage à utiliser et à sa protection par des données personnelles temporaires, c'est-à-dire récupérées uniquement pour accéder à cette clé de cryptage. En effet, l'utilisation de ces données personnelles temporaires assure une sécurité forte de la clé de cryptage transmise car elles ne sont pas stockées à demeure sur le dispositif mobile.
Corrélativement, l'invention concerne également un dispositif mobile, type téléphone mobile, carte à puce non sécurisée, etc., comprenant un module d'obtention d'une clé de cryptage, un module cryptographique configuré pour encrypter un message, par exemple un message de transaction financière, à l'aide de la clé de cryptage obtenue afin d'obtenir un cryptogramme et un module de communication configuré pour envoyer le cryptogramme, qui inclut par exemple les informations relatives à la transaction, à un serveur distant de transaction.
Selon l'invention, ladite clé de cryptage a une durée de vie limitée.
Selon l'invention toujours, le module d'obtention de la clé de cryptage est configuré pour, lorsqu'une précédente clé de cryptage obtenue par le dispositif mobile est périmée :
recevoir, d'un serveur distant sécurisé, une nouvelle clé de cryptage encryptée, obtenir une donnée personnelle saisie par un utilisateur sur une interface de saisie connectée au dispositif mobile, par exemple via une interface d'un terminal de paiement ou via le clavier d'un téléphone mobile formant ou hébergeant le dispositif mobile,
décrypter la nouvelle clé de cryptage reçue à l'aide de la donnée personnelle saisie, et supprimer la donnée personnelle saisie du dispositif mobile avant d'utiliser ladite nouvelle clé de cryptage décryptée pour encrypter le message et obtenir le cryptogramme.
L'invention a également pour objet un produit programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé décrit précédemment lorsque ledit programme est exécuté sur un ordinateur.
Le dispositif mobile et le produit programme d'ordinateur selon l'invention présentent des avantages similaires à ceux exposés précédemment en lien avec le procédé.
D'autres caractéristiques du procédé et du dispositif mobile selon des modes de réalisation sont décrites dans les revendications dépendantes, et résumées ci-après en termes de procédés. Le procédé de traitement cryptographique peut constituer une partie d'un procédé de communication dont un exemple est décrit en détail par la suite. De même le dispositif mobile fait partie d'un système comme décrit pas la suite.
Selon des modes de réalisation, la donnée personnelle est un code PIN saisi par un utilisateur. Cette configuration permet de conserver l'interaction classique de l'utilisateur, sans nécessiter la saisie de nouvelles données aux fins de l'invention.
Selon d'autres modes de réalisation, une clé de décryptage pour décrypter la clé de cryptage encryptée est formée à partir de la donnée personnelle saisie et d'une donnée commune au dispositif mobile et au serveur sécurisé distant. Cette configuration améliore la sécurité de la clé de cryptage fournie, de façon encryptée par le serveur sécurisé distant.
Selon d'autres modes de réalisation, le procédé comprend la transmission de la nouvelle clé de cryptage depuis le serveur distant sécurisé vers le serveur distant de transaction. Cette disposition permet à ce dernier serveur de pouvoir valider le cryptogramme reçu du dispositif mobile.
Selon d'autres modes de réalisation,, ladite clé de cryptage est sélectionnée parmi une liste chaînée ou série de clés générées à partir d'une clé racine et d'une fonction à sens unique appliquée à la clé précédemment générée, c'est-à-dire que la génération des clés est récursive. Ladite sélection est en outre réalisée selon l'ordre inverse de génération des clés, signifiant que la dernière clé générée est utilisée en premier, et la première clé générée en dernier. Cela permet un renouvellement sécurisé des clés.
Selon encore d'autres modes de réalisation, le cryptogramme comprend des informations relatives à une transaction informatique, par exemple relatives à une transaction financière, telles qu'un montant. Une transaction informatique, telle qu'une réservation, un achat ou un paiement, consiste notamment en la mise en oeuvre d'une suite atomique, cohérente, isolée et durable d'opérations qui font passer une base de données des transactions d'un état A, antérieur à la transaction, à un état B postérieur à celle-ci.
Selon encore d'autres modes de réalisation, la clé de cryptage est renouvelée après un nombre fixé de générations de cryptogramme, c'est-à-dire après un nombre fixé de transactions utilisant cette clé, par exemple à chaque nouvelle transaction informatique. Cette disposition permet de garantir un renouvellement régulier des clés de cryptage.
Selon encore d'autres modes de réalisation, le décryptage de la clé de cryptage reçue met en oeuvre un algorithme cryptographique à clé symétrique. Cette disposition permet un traitement rapide à la fois du cryptage de cette clé par le serveur distant et du décryptage de celle-ci par le dispositif mobile. Ainsi la latence introduite par les traitements selon l'invention est minimisée. BREVE DESCRIPTION DES FIGURES
D'autres avantages, buts et caractéristiques particulières de la présente invention ressortiront de la description qui va suivre faite, dans un but explicatif et nullement limitatif, en regard des dessins annexés, dans lesquels :
la figure 1 représente schématiquement une infrastructure dans laquelle des modes de réalisation de la présente invention sont mis en oeuvre ;
la figure 2 illustre un exemple d'architecture matérielle pour les équipements représentés sur la figure 1 ;
les figures 3a, 3b et 3c illustrent, sous forme d'ordinogrammes, des étapes générales de procédés pour une mise en oeuvre de l'invention, respectivement au niveau du dispositif mobile, du serveur d'authentification et du serveur sécurisé distant de la figure 1 ; et
la figure 4 illustre les échanges de messages entre les équipements de la figure 1 lors d'une mise en oeuvre de l'invention. DESCRIPTION DETAILLEE DE L'INVENTION
La figure 1 illustre un exemple d'infrastructure dans laquelle la présente invention peut être mise en oeuvre. Cette infrastructure peut être similaire à celle décrite dans la publication US 2013/054,474 susmentionnée.
L'infrastructure 1 comporte un dispositif mobile 10, un point de vente POS 12 officiant comme lecteur du dispositif mobile 10, un ou plusieurs réseaux de communication 14, un serveur d'authentification d'utilisateur 16, un serveur de transaction 17 et un serveur sécurisé distant 18. Bien qu'un seul dispositif mobile 10 soit représenté, une pluralité de dispositifs mobiles 1 0 détenus par une pluralité d'utilisateurs respectifs est largement envisagée pour réaliser de façon concomitante ou non une ou plusieurs transactions nécessitant la mise en oeuvre de l'invention.
Le dispositif mobile 10 peut être tout type d'équipement utilisateur doté d'une mémoire et de moyens de traitement, type CPU, pour mémoriser et exécuter une application requérant un service cryptographique sécurisé. Il s'agit par exemple d'une application de paiement nécessitant l'utilisation d'une clé pour chiffrer ou encrypter les informations relatives à la transaction financière.
A titre d'exemple, le dispositif mobile peut être un téléphone portable, un module de traitement type carte à puce non sécurisée.
Le dispositif mobile 1 0 comporte notamment des moyens de communication sans fil conforme à la norme ISO/IEC 14443, afin de communiquer avec le lecteur 12. A cette fin, le dispositif mobile peut mettre en oeuvre le protocole NFC. En variante, des moyens de communication par contact type ISO/IEC 7816 ou filaire (USB) peuvent être envisagés.
Le dispositif mobile 10 peut également comprendre des moyens de communication avec le serveur d'authentification 16 par l'intermédiaire d'un réseau de communication 14, type réseau étendu tel que le réseau de téléphonie mobile ou le réseau Internet. La figure 2 représente un exemple d'architecture matérielle pour un équipement tel le dispositif mobile 1 0.
L'équipement comprend un bus de communication 2 auquel sont reliées :
- une unité de traitement 20 -ou microprocesseur- notée CPU (pour Central Processing Unit) ;
- une ou plusieurs mémoires non volatile 22 par exemple ROM (pour Read Only Memory), EEPROM (pour de Electrically Erasable Read Only Memory) ou encore Flash, stockant par exemple l'application de paiement;
- une mémoire vive 24 ou mémoire cache ou mémoire volatile par exemple RAM (pour Random Access Memory) ; et
- une interface de communication 26 adaptée à transmettre et à recevoir des données, par exemple via un réseau de télécommunications ou une interface de lecture/écriture.
Optionnellement, l'équipement peut comprendre une interface d'entrées/sorties I/O (pour Input/Output), par exemple un écran, un clavier, une souris ou un autre dispositif de pointage tel qu'un écran tactile ou une télécommande ; cette interface I/O permet à un utilisateur d'interagir avec le système au cours de la mise en oeuvre du procédé via une interface graphique, notamment de saisir un code PIN comme décrit par la suite.
La mémoire vive 24 comprend des registres adaptés à l'enregistrement des variables et paramètres créés et modifiés au cours de l'exécution d'un programme informatique comprenant des instructions pour la mise en oeuvre d'étapes d'un procédé selon l'invention lors de sa mise en oeuvre. Les codes d'instructions du programme stocké en mémoire non-volatile sont chargés en mémoire RAM en vue d'être exécutés par l'unité de traitement CPU.
Le bus de communication permet la communication et l'interopérabilité entre les différents éléments représentés sur la figure 2. La représentation du bus n'est pas limitative et, notamment, l'unité de traitement est susceptible de communiquer des instructions à tout élément de l'équipement représenté, directement ou par l'intermédiaire d'un autre élément de celui-ci.
De retour à la figure 1 , le point de vente POS 12 peut être tout type de terminal de paiement classique, doté d'un lecteur apte à communiquer avec le dispositif mobile 10.
La lecture peut être de type RFID ou selon la norme ISO/IEC 14443, voire avec contact.
Le point de vente POS 12 est également doté de moyens de communication sur le réseau 14 afin de communiquer avec le serveur de transaction 17 (qui peut être commun avec le serveur d'authentification 16). Le serveur de transaction 17 est classique. Bien entendu, une pluralité de serveurs peut être prévue pour réaliser l'ensemble des fonctions exposées par la suite.
Le terminal de paiement 12 peut avoir l'architecture matérielle représentée sur la figure 2, équipée en outre d'un lecteur comme exposé ci-dessus. Le serveur d'authentification et de transaction 1 6 est relié au réseau de communication 14 aux fins d'établir une connexion sécurisée avec le dispositif mobile 10 pour la réalisation d'une transaction. En outre, le serveur 16 dispose d'une connexion, soit directe, soit via un réseau étendu tel le réseau 14, au serveur sécurisé distant 18 afin d'obtenir une clé de cryptage à jour comme expliqué par la suite. A titre d'exemple de connexion directe, le serveur sécurisé 18 peut être un serveur web hébergé dans le serveur d'authentification 1 6.
Le serveur 16 peut être conforme à l'architecture matérielle représentée sur la figure
2.
Le serveur sécurisé distant 1 8 comprend par exemple un module sécurisé SE stockant une liste chaînée de clés de cryptage pour le dispositif mobile 10. En variante, le serveur sécurisé distant 18 est mis en oeuvre dans un tel module sécurisé SE, par exemple un serveur dans une carte à puce. Dans cette variante, la carte à puce peut être installée dans le serveur 16 et communiquer par des unités APDU selon le protocole ISO 7816. Dans la suite de la description on fera référence principalement à un « module sécurisé » 18.
En particulier, le module sécurisé distant 1 8 stocke en mémoire une clé maître MK pour chaque application de transaction (par exemple de paiement) mise en oeuvre par un dispositif mobile 10. La clé maître MK est utilisée comme point de départ d'un processus de génération d'une liste de clés de transaction ou « clés de session », utilisées par les dispositifs mobiles 10 pour crypter les informations de transaction en cryptogramme. Cette génération est également connue sous l'appellation de diversification ou dérivation de clés.
La génération de la série de clés est effectuée à l'aide d'une fonction f à sens unique appliquée récursivement à MK puis à chaque clé SKn générée :
SK, = f(MK)
Figure imgf000009_0001
Le nombre n d'itérations est prédéfini, par exemple n=1024.
Ainsi la liste de clés de cryptage obtenue est chaînée {SK^ SK2, SKn}.
En raison de la nature de la fonction f, les clés sont mises à disposition du dispositif mobile 10 dans l'ordre inverse de la liste chaînée, c'est-à-dire dans l'ordre n, n-1 , n-2, 2, 1 . Ainsi, si une clé SK, est volée, elle ne peut être utile qu'à la détermination des clés d'indice supérieur, c'est-à-dire des clés déjà répudiées.
La clé maître MK n'est jamais transmise et peut être réutilisée pour produire une nouvelle liste chaînée, par exemple en utilisant une autre fonction à sens unique (ayant par exemple un paramétrage différent).
Dans une variante évitant de stocker la liste chaînée, SK, peut être obtenue directement par une fonction f(SK, i).
Afin de garantir une forte sécurité des transactions, chaque clé de cryptage ainsi générée a une durée de vie limitée dans le temps à compter de sa mise en circulation, c'est-à- dire dès lors qu'elle est mise à disposition par le module sécurisé distant. La clé de cryptage qui est en cours d'utilisation est dite « clé courante ». A titre d'exemple, la durée de vie limitée peut être définie par une fréquence de renouvellement de la clé courante. Par exemple, chaque dimanche à minuit la clé courante SKj devient obsolète et est remplacée par la nouvelle clé courante SKj.! .
Dans un autre exemple, cette durée de vie limitée peut être définie au regard d'un nombre de transactions utilisant la clé courante. Par exemple, la clé de cryptage peut être renouvelée toutes les /( transactions. A titre d'exemple, k=10.
Ce mécanisme de regénération régulière de la clé courante de cryptage utilisée pour les transactions permet de réduire les risques associés à la compromission de la clé de cryptage. En outre, le fait que la clé de cryptage courante soit transmise au dispositif mobile rend possible que le cryptogramme pour la transaction soit calculé par le dispositif mobile directement à partir de cette clé de cryptage désormais détenue localement.
Afin de protéger la clé de cryptage courante, l'invention prévoit que le module sécurisé distant communique la nouvelle clé de cryptage sous forme encryptée à l'aide d'une clé formée à partir d'une donnée personnelle fournie par l'utilisateur.
Ainsi, le module sécurisé distant 18 comporte également des moyens cryptographiques permettant d'encrypter des données, et notamment d'encrypter les clés SK, à l'aide d'un algorithme cryptographique à clé symétrique, par exemple l'algorithme triple DES (3DES) : enc3des(SK KSYM) où enc3des est la fonction d'encryptage basée sur le Triple DES.
La clé symétrique KSYM utilisée peut être générée à la volée à partir de la donnée personnelle de l'utilisateur, lorsqu'une nouvelle clé SK, doit être communiquée. La donnée personnelle de l'utilisateur est sauvegardée en mémoire du module sécurisée distant pour être utilisée dans la formation de la clé symétrique. Cette donnée personnelle peut être saisie par l'utilisateur lors d'une procédure d'inscription ou d'installation de l'application de paiement, permettant par exemple d'associer cette donnée personnelle à la clé maître MK correspondant à l'application installée.
En variante, les clés SK, sont toutes encryptées à l'avance et stockées comme telles dans le module sécurisé.
La donnée personnelle de l'utilisateur est préférentiellement une information que l'utilisateur connaît bien, telle qu'un code PIN. En particulier, il peut s'agir du même code PIN que celui utilisé dans une procédure d'authentification auprès du serveur 16.
En variante, il peut s'agir d'un mot de passe, ou d'un mot de passe étendu (« passphrase » selon la terminologie anglo-saxonne).
Dans un mode de réalisation, la clé symétrique est la donnée personnelle de l'utilisateur. En variante, la clé symétrique est distincte de la donnée personnelle mais calculée à partir de celle-ci, éventuellement uniquement à partir de celle-ci, par exemple à partir d'une fonction de hachage SHA-256(PIN).
Dans un autre mode de réalisation, la clé symétrique est formée à partir de la donnée personnelle de l'utilisateur et d'une donnée commune au dispositif mobile et au module sécurisé distant 18, par exemple un numéro unique d'identification de l'application de paiement considérée.
Par exemple, la clé symétrique peut résulter d'un calcul cryptographique sur ces deux données au moins, par exemple AES (donnée commune, PIN) où les données communes sont utilisées comme clé pour crypter la donnée personnelle (vice et versa).
Dans une variante, on peut appliquer une fonction de hachage sur la concaténation (« | ») de ces deux données : SHA-256(donnée commune|donnée personnelle).
Dans ces modes de réalisation utilisant la donnée commune, la clé symétrique est d'une plus grande longueur et donc offre un encryptage plus robuste.
La figure 3 illustre, sous forme d'ordinogrammes, des étapes générales de procédés au niveau du dispositif mobile (figure 3a), du serveur d'authentification (figure 3b) et du serveur sécurisé distant (figure 3c) pour une mise en oeuvre de l'invention. Ces étapes sont décrites ci-dessous à l'aide d'un exemple de diagramme temporel de séquence représenté sur la figure 4.
A l'étape 302, le dispositif mobile 1 0 est en attente d'une demande de transaction par l'utilisateur, par exemple du lancement d'une application de paiement par l'utilisateur ou en variante d'une indication par l'utilisateur d'un souhait de transaction au sein de cette application.
L'ensemble des étapes qui suivent du dispositif mobile 10 peuvent être mises en oeuvre par l'application de transaction elle-même, notamment l'application de paiement susvisée.
Lorsqu'une telle demande est reçue, l'utilisateur est invité à saisie un code d'authentification (code PIN ou mot de passe) lors de l'étape 304 permettant au dispositif mobile 10 de réaliser, si le code saisi est bon, une procédure d'authentification (étape 306) auprès du serveur 16. La procédure d'authentification peut mettre en oeuvre un échange de type « challenge/response » (stimulation/réponse) largement connu.
A noter que cette connexion avec le serveur d'authentification 16 peut être initiée par l'utilisateur avant de recevoir une demande de transaction (par exemple avant d'exécuter l'application de paiement).
Par exemple, l'authentification peut être menée lors du démarrage du dispositif mobile 10 par l'utilisateur (par exemple son téléphone mobile). Dans ce cas, le code d'authentification peut être le code PIN demandé au démarrage du terminal mobile 1 0.
En référence à la figure 3b, le serveur d'authentification 16 est en attente d'une demande d'authentification (test 340). Lorsqu'une telle demande est reçue, il traite la demande de façon classique (étape 342), par exemple en mettant en oeuvre une procédure de type « challenge/response » avec l'émetteur de la demande. Ce traitement de l'étape 342 conduit à rémission d'un message OK en cas d'authentification réussie ou d'un message NOK en cas d'échec d'authentification.
Ces étapes d'authentification sont schématiquement représentées par les flèches 402 et 404 sur la figure 4. En cas d'échec d'authentification (test 344), le serveur 16 se remet en attente d'une nouvelle demande d'authentification (étape 340).
En cas d'authentification réussie (test 344), le serveur d'authentification 16 vérifie si la clé de cryptage courante SK, pour le dispositif mobile 10 est valide ou périmée (ou obsolète) en se basant sur des règles d'obsolescence (test 346). L'obsolescence de la clé SK, peut résulter d'une durée expirée depuis l'émission de cette clé, d'une date d'expiration ou encore d'un nombre de transactions déjà réalisées à l'aide de cette clé comme décrit précédemment pour la durée de vie des clés.
A noter que le serveur d'authentification dispose en mémoire d'une table mémorisant un état de la clé courante ou des clés courantes associées à chaque dispositif mobile 1 0. Ainsi à l'aide de la procédure d'authentification identifiant le dispositif mobile, le serveur d'authentification 16 est capable de récupérer, de cette mémoire, la ou les clés courantes. Si nécessaire, le dispositif mobile 10 peut indiquer dans sa demande d'authentification (étape 306) l'application mise en oeuvre, de sorte à permettre au serveur 16 d'identifier la clé de cryptage associée à la transaction souhaitée.
Si la clé SK, n'est pas obsolète, le serveur 1 6 retourne à l'étape 340 en attente d'une nouvelle demande d'authentification.
Si la clé SK, s'avère être périmée (ou si aucune clé n'a encore été communiquée), le serveur d'authentification 16 sollicite le module sécurisé 18 pour l'obtention d'une nouvelle clé de transaction. Il peut s'agir d'un appel à une fonction du module sécurisé hébergé sur le module sécurisé 18. C'est l'étape 348 à l'issue de laquelle le serveur 16 obtient cette nouvelle clé, sous forme encryptée EKi+1 , comme décrit ci-après. Elle est représentée par les flèches 406 (demande d'une nouvelle clé), 408 (encodage de la clé) et 410 (réception de la clé) sur la figure 4.
En référence à la figure 3c, le module sécurisé du module sécurisé 18 a été configuré lors d'une étape d'initialisation 360 au cours de laquelle une liste chaînée de clés de cryptage {SK SK2, SKn} a été générée à partir d'une clé maître MK, et ce pour chaque application nécessitant une clé de cryptage et pour chaque dispositif mobile 10.
A l'étape 362, la variable / désignant la prochaine clé à communiquer est initialisée à n, n étant le nombre de clés générées à partir de MK.
Le module sécurisé 18 est ainsi en attente d'une demande de renouvellement de clé (test 364) lorsque la demande émise par le serveur 16 à l'étape 348 est reçue.
Le module sécurisé 18 traite ainsi cette demande par une étape 366 où il récupère SKj, puis une étape 368 où il encrypte SKj à l'aide de la clé symétrique KSYM évoquée plus haut (étape illustrée par la flèche 408 sur la figure 4 : EKj = enc(SKj, KSYM)), puis une étape 370 où il retourne la clé encryptée correspondante EKj au serveur 16 et transmet la clé SK correspondante au(x) serveur(s) de transaction 17 (éventuellement dans une forme encryptée convenue avec ce serveur 17). Dans l'exemple des figures 3, la clé symétrique est basée sur une donnée personnelle de l'utilisateur de type code PIN ou mot de passe. Puis l'étape 372 est exécutée pour décrémenter la variable j. Grâce à cette étape 372, la variable y vaut i-1 où /' est l'indice de la clé courante.
De plus en partant de j=n et en décrémentant j à chaque renouvellement de clé, le procédé permet de sélectionner successivement les clés SK de la liste chaînée, dans l'ordre inverse de leur génération.
Suite à l'étape 372, le module sécurisé 18 se remet en attente d'une demande de renouvellement de clé (étape 364).
De retour à la figure 3b, à réception de la clé encryptée EKj, c'est-à-dire la version encryptée de la nouvelle clé courante SK,, le serveur 1 6 la transmet au dispositif mobile 10 à l'étape 350 (flèche 412 sur la figure 4), avant de se remettre en attente d'une nouvelle demande d'authentification (étape 340).
De retour à la figure 3a relative au dispositif mobile 10, en cas d'échec d'authentification (test 308), il est vérifié si trois essais de code PIN ont été effectués (test 320) auquel cas une action de protection est réalisée (étape 322, par exemple une désactivation, temporaire ou définitive, du dispositif mobile). S'il reste des essais, le processus retourne à l'étape 304.
En cas d'authentification réussie, le dispositif mobile 10 peut recevoir, du module sécurisé 18 via le serveur 1 6, une nouvelle clé de cryptage encryptée EK, si la clé courante est périmée. Il s'agit de l'étape optionnelle 310.
Puis à l'étape 312, l'utilisateur saisit une donnée personnelle, typiquement un code
PIN ou mot de passe, sur une interface de saisie connectée au dispositif mobile 10, par exemple le clavier d'un terminal mobile. Cette étape est représentée par la flèche 414 de la figure 4.
Par exemple, l'application de paiement peut afficher une fenêtre de saisie d'une telle donnée afin d'autoriser ou valider le paiement.
Cette étape 312 est optionnelle dans le cas où la donnée personnelle nécessaire ici est le code PIN ou mot de passe déjà saisi à l'étape 304, auquel cas la donnée personnelle saisie peut être réutilisée pour le décryptage de EK,. En outre, elle n'est pas réalisée si aucune clé encryptée EK, n'est à décrypter. C'est par exemple le cas lorsque que la clé encryptée EK, a été décryptée lors d'une itération précédente et que le dispositif mobile 1 0 stocke la clé courante SK, toujours valide dans sa forme décryptée.
Puis à l'étape 314 (flèche 416 sur la figure 4), la clé de cryptage encryptée EK, est décryptée à l'aide de la donnée personnelle saisie, ici le code PIN ou mot de passe, pour obtenir la clé de cryptage courante SK, : SK, = dec(EK,, KSYM)- En effet la donnée personnelle saisie permet de former la clé symétrique KSYM nécessaire à ce décryptage.
A noter que la clé ainsi obtenue SK, peut être stockée en mémoire non volatile du dispositif mobile, auquel cas la clé encryptée EK, peut être supprimée. Dans ce cas et si la clé SK, peut être réutilisée pour des transactions ultérieures, l'étape 314 s'avère optionnelle pour les nouvelles itérations du procédé lorsque la clé n'est pas renouvelée. Dans une variante sécuritaire, seule la clé EK, est sauvegarde dans le dispositif mobile 10 et est décryptée uniquement lors d'une transaction (et la valeur décryptée SK est donc effacée à la fin de la transaction - fin des étapes 318 et 428 décrites ci-dessous).
A l'étape 316, la donnée personnelle, code PIN ou mot de passe, saisie pour décrypter la clé EK, est supprimée de toute mémoire du dispositif mobile 1 0. Il s'agit de la flèche 418 sur la figure 4.
Puis uniquement après cette suppression (qui peut être largement décorrélée dans le temps), l'étape E318 consiste à effectuer la transaction souhaitée par l'utilisateur, par exemple un paiement.
Sur la figure 4, cette transaction de type paiement se compose par exemple d'une action (flèche 420) au cours de laquelle l'utilisateur présente son dispositif mobile 10 au terminal de paiement POS 12 afin d'effectuer la transaction de paiement, laquelle étape déclenche une échange de messages conformes à EMV entre ces deux entités (flèche 422, flèche 426, et flèche 432 terminant la transaction) et un serveur de transaction 1 7 (flèches 428 et 430). Pour la réalisation de la transaction, le dispositif mobile utilise ladite clé de cryptage décryptée SK, pour encrypter des informations de transaction et obtenir un cryptogramme (flèche 424) à communiquer au serveur de transaction 17 éventuellement via le POS 12.
Les exemples qui précèdent ne sont que des modes de réalisation de l'invention qui ne s'y limite pas.

Claims

REVENDICATIONS
1. Procédé de traitement cryptographique, comprenant, sur un dispositif mobile, une étape d'obtention d'une clé de cryptage, une étape d'encryptage d'un message à l'aide de la clé de cryptage obtenue pour obtenir un cryptogramme et une étape d'envoi du cryptogramme à un serveur distant de transaction,
caractérisé en ce que ladite clé de cryptage a une durée de vie limitée ; et l'étape d'obtention de la clé de cryptage par le dispositif mobile inclut les étapes suivantes, lorsqu'une précédente clé de cryptage obtenue par le dispositif mobile est périmée :
recevoir, d'un serveur distant sécurisé, une nouvelle clé de cryptage encryptée, saisir une donnée personnelle sur une interface de saisie connectée au dispositif mobile,
décrypter la nouvelle clé de cryptage reçue à l'aide de la donnée personnelle saisie, et
supprimer la donnée personnelle saisie du dispositif mobile avant d'utiliser ladite nouvelle clé de cryptage décryptée pour encrypter le message et obtenir le cryptogramme.
2. Procédé selon la revendication 1 , dans lequel la donnée personnelle est un code PIN saisi par un utilisateur.
3. Procédé selon la revendication 1 ou 2, dans lequel une clé de décryptage pour décrypter la clé de cryptage encryptée est formée à partir de la donnée personnelle saisie et d'une donnée commune au dispositif mobile et au serveur sécurisé distant.
4. Procédé selon l'une des revendications précédentes, comprenant la transmission de la nouvelle clé de cryptage depuis le serveur distant sécurisé vers le serveur distant de transaction.
5. Procédé selon l'une des revendications précédentes, dans lequel ladite clé de cryptage est sélectionnée parmi une série de clés générées à partir d'une clé racine et d'une fonction à sens unique appliquée à la clé précédemment générée, ladite sélection étant réalisée selon l'ordre inverse de génération des clés.
6. Procédé selon l'une des revendications précédentes, dans lequel le cryptogramme comprend des informations relatives à une transaction informatique.
7. Procédé selon l'une des revendications précédentes, dans lequel la clé de cryptage est renouvelée après un nombre fixé de générations de cryptogramme.
8. Procédé selon l'une des revendications précédentes, dans lequel le décryptage de la clé de cryptage reçue met en oeuvre un algorithme cryptographique à clé symétrique.
9. Dispositif mobile comprenant un module d'obtention d'une clé de cryptage, un module cryptographique configuré pour encrypter un message à l'aide de la clé de cryptage obtenue afin d'obtenir un cryptogramme et un module de communication configuré pour envoyer le cryptogramme à un serveur distant de transaction. caractérisé en ce que ladite clé de cryptage a une durée de vie limitée ; et en ce que le module d'obtention de la clé de cryptage mobile est configuré pour, lorsqu'une précédente clé de cryptage obtenue par le dispositif mobile est périmée :
recevoir, d'un serveur distant sécurisé, une nouvelle clé de cryptage encryptée, obtenir une donnée personnelle saisie par un utilisateur sur une interface de saisie connectée au dispositif mobile,
décrypter la nouvelle clé de cryptage à l'aide de la donnée personnelle saisie, et supprimer la donnée personnelle du dispositif mobile avant d'utiliser ladite nouvelle clé de cryptage décryptée pour encrypter le message et obtenir le cryptogramme.
10. Produit programme d'ordinateur comprenant des instructions adaptées à la mise en oeuvre de chacune des étapes du procédé selon l'une quelconque des revendications 1 à 8 lorsque ledit programme est exécuté sur un ordinateur.
PCT/FR2015/052316 2014-09-02 2015-09-01 Sécurisation de clés de cryptage pour transaction sur un dispositif dépourvu de module sécurisé WO2016034812A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1458191A FR3025341B1 (fr) 2014-09-02 2014-09-02 Securisation de cles de cryptage pour transaction sur un dispositif depourvu de module securise
FR1458191 2014-09-02

Publications (1)

Publication Number Publication Date
WO2016034812A1 true WO2016034812A1 (fr) 2016-03-10

Family

ID=52007057

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2015/052316 WO2016034812A1 (fr) 2014-09-02 2015-09-01 Sécurisation de clés de cryptage pour transaction sur un dispositif dépourvu de module sécurisé

Country Status (2)

Country Link
FR (1) FR3025341B1 (fr)
WO (1) WO2016034812A1 (fr)

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20020133707A1 (en) * 2000-11-29 2002-09-19 Applied Microsystems Corporation Method and system for secure distribution of subscription-based game software
US20030054474A1 (en) 1998-06-22 2003-03-20 Genentech, Inc. Secreted and transmembrane polypeptides and nucleic acids encoding the same
WO2003098868A1 (fr) * 2002-05-17 2003-11-27 Nokia Corporation Procede et systeme utilises dans un reseau de communication de donnees sans fil numerique pour assurer un cryptage des donnees et serveur correspondant
WO2007138486A2 (fr) * 2006-01-31 2007-12-06 Cidway Technologies, Ltd. Système et procédé destinés à renforcer le degré de restriction lors d'accès à des applications logicielles
WO2012136986A1 (fr) * 2011-04-05 2012-10-11 Visa Europe Limited Système de paiement
US20130054474A1 (en) 2011-08-30 2013-02-28 C. Douglas Yeager Systems and methods for authorizing a transaction with an unexpected cryptogram

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030054474A1 (en) 1998-06-22 2003-03-20 Genentech, Inc. Secreted and transmembrane polypeptides and nucleic acids encoding the same
US20020133707A1 (en) * 2000-11-29 2002-09-19 Applied Microsystems Corporation Method and system for secure distribution of subscription-based game software
WO2003098868A1 (fr) * 2002-05-17 2003-11-27 Nokia Corporation Procede et systeme utilises dans un reseau de communication de donnees sans fil numerique pour assurer un cryptage des donnees et serveur correspondant
WO2007138486A2 (fr) * 2006-01-31 2007-12-06 Cidway Technologies, Ltd. Système et procédé destinés à renforcer le degré de restriction lors d'accès à des applications logicielles
WO2012136986A1 (fr) * 2011-04-05 2012-10-11 Visa Europe Limited Système de paiement
US20130054474A1 (en) 2011-08-30 2013-02-28 C. Douglas Yeager Systems and methods for authorizing a transaction with an unexpected cryptogram

Also Published As

Publication number Publication date
FR3025341A1 (fr) 2016-03-04
FR3025341B1 (fr) 2016-12-30

Similar Documents

Publication Publication Date Title
EP3221815B1 (fr) Procédé de sécurisation d'un jeton de paiement.
EP3238474B1 (fr) Procédé de sécurisation de transactions sans contact
EP1549011A1 (fr) Procédé et système de communication entre un terminal et au moins un équipment communicant
FR2822002A1 (fr) Authentification cryptographique par modules ephemeres
FR2919974A1 (fr) Systeme d'information et procede d'identification par un serveur d'application d'un utilisateur
FR3011653A1 (fr) Procedes et dispositifs de masquage et demasquage
EP3238200A1 (fr) Entité électronique sécurisée, appareil électronique et procédé de vérification de l'intégrité de données mémorisées dans une telle entité électronique sécurisée
EP0606792A1 (fr) Procédé d'authentification d'un ensemble informatique par un autre ensemble informatique
WO2020064890A1 (fr) Procede de traitement d'une transaction, dispositif, systeme et programme correspondant
EP3991381B1 (fr) Procédé et système de génération de clés de chiffrement pour données de transaction ou de connexion
WO2016207715A1 (fr) Gestion securisee de jetons électroniques dans un telephone mobile.
FR3002670A1 (fr) Procede et systeme de traitement cryptographique utilisant une donnee sensible
EP2614491A1 (fr) Procede simplifie de personnalisation de carte a puce et dispositif associe
EP2306668A1 (fr) Système et procédé de transaction sécurisée en ligne
WO2016034812A1 (fr) Sécurisation de clés de cryptage pour transaction sur un dispositif dépourvu de module sécurisé
EP3743871A1 (fr) Système sécurisé de transactions entre terminaux
FR2985148A1 (fr) Methode d'appairage d'equipements electroniques
EP1262860B1 (fr) Système et procédé d'authentification d'un utilisateur
EP2372945A1 (fr) Procédé de transmission sécurisée de données entre un terminal numérique et une plateforme de services interactifs
EP3570238B1 (fr) Procédé de réalisation d'une transaction, terminal, serveur et programme d'ordinateur correspondant
EP2409474A1 (fr) Procédé de production de données de sécurisation, dispositif et programme d'ordinateur correspondant
EP2084679A1 (fr) Entite electronique portable et procede de blocage, a distance, d'une fonctionnalite d'une telle entite electronique portable
EP3340096B1 (fr) Procédé de configuration d'un programme cryptographique destiné à être exécuté par un terminal
WO2021099199A1 (fr) Procede et systeme pour le provisionnement ou remplacement securise d'un secret dans au moins un dispositif de communication portable.
EP3029878B1 (fr) Procédé de transmission de secret à durée de vie limitée pour réaliser une transaction entre un terminal mobile et un équipement

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15767216

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15767216

Country of ref document: EP

Kind code of ref document: A1