WO2016180821A1 - Method, device and server for signing document using a banking transaction key - Google Patents

Method, device and server for signing document using a banking transaction key Download PDF

Info

Publication number
WO2016180821A1
WO2016180821A1 PCT/EP2016/060429 EP2016060429W WO2016180821A1 WO 2016180821 A1 WO2016180821 A1 WO 2016180821A1 EP 2016060429 W EP2016060429 W EP 2016060429W WO 2016180821 A1 WO2016180821 A1 WO 2016180821A1
Authority
WO
WIPO (PCT)
Prior art keywords
data
signed
cryptogram
server
relating
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2016/060429
Other languages
French (fr)
Inventor
Pierre Brousseau
Didier Hugot
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Thales DIS France SA
Original Assignee
Gemalto SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Gemalto SA filed Critical Gemalto SA
Publication of WO2016180821A1 publication Critical patent/WO2016180821A1/en
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/60—Protecting data
    • G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3227—Aspects of commerce using mobile devices [M-devices] using secure elements embedded in M-devices
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3229—Use of the SIM of a M-device as secure element
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3821—Electronic credentials
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3827—Use of message hashing
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/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
    • 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/061—Network architectures or network communication protocols for network security for supporting key management in a packet data network for key exchange, e.g. in peer-to-peer networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0876—Network architectures or network communication protocols for network security for authentication of entities based on the identity of the terminal or configuration, e.g. MAC address, hardware or software configuration or device fingerprint
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/34—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using cards, e.g. integrated circuit [IC] cards or magnetic cards
    • G06Q20/341—Active cards, i.e. cards including their own processing means, e.g. including an IC or chip
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash

Definitions

  • the invention relates generally to a method for signing data.
  • the invention also pertains to a device for signing data.
  • the device may be a (user) terminal, an embedded chip or a smart card, as a Secure Element (or SE).
  • SE Secure Element
  • the invention is notably applicable to a mobile radio-communication field wherein the device is a mobile terminal or a chip that may be embedded, such as an embedded Universal Integrated Circuit Card (or eUICC) within a host device, or removable from a host device, as a chip included within a smart card termed Subscriber Identity Module (or SIM) type card or the like, as an SE.
  • eUICC embedded Universal Integrated Circuit Card
  • SIM Subscriber Identity Module
  • an SE is a smart object or device that includes a chip that protects, as a tamper resistant component, physically access to stored data and is intended to communicate, preferably in a secure manner, data with the outside world, like e.g. a mobile (tele)phone, as an SE host device.
  • SIM Subscriber Identity Module
  • SE Subscriber Identity Module
  • the SIM card sends the SIM public key, through a mobile phone, Over The Air (or OTA), to a server.
  • the server is thus enabled to verify whether data signed by the SIM card is or is not valid by using the received SIM card public key.
  • the invention proposes a solution for satisfying the just herein above specified need by providing a method for signing data.
  • the method comprises the following steps.
  • a device generates a first cryptogram by using a predetermined payment transaction key, a predetermined algorithm and data relating to data to be signed, as an input to the algorithm.
  • the data to be signed is different from payment transaction data.
  • the device sends, without going through any payment transaction channel, to a first server a first message including a request for validating a signature relating to the data to be signed accompanied with the first cryptogram and the data relating to the data to be signed.
  • the first or a second server generates a second cryptogram by using the predetermined payment transaction key, the predetermined algorithm and the data relating to the data to be signed, as an input to the algorithm.
  • the first or the second server compares the second cryptogram to the first cryptogram. If the second cryptogram does or does not match the first cryptogram, then the first or the second server does or does not validate a signature relating to the data to be signed respectively.
  • the principle of the invention consists in that a device uses a predefined payment transaction key that is dedicated to a payment transaction application, a predetermined algorithm and data relating to data to be signed in order to compute a corresponding signature.
  • the device sends, besides the data relating to the data to be signed, the signature, via a non-payment transaction channel, to a server.
  • a cryptogram is computed using the received data relating to the data to be signed, the payment transaction key and the algorithm.
  • a (or the) server validates the signature only if the received signature and the cryptogram computed at the server side matches.
  • the data to be signed may be of any type.
  • the data to be signed includes binary data, data relating to a document(s), data relating to message(s) and/or any other kind of data the origin of which has to be known to its addressee.
  • the payment transaction application may also be of any type, like e.g. an Europay Mastercard Visa (or EMV) application or the like.
  • Such an invention solution leverages on an existing Cloud-Based Payment (or CBP) type infrastructure, so as to add a digital signature service.
  • CBP Cloud-Based Payment
  • the invention solution re-uses the existing CBP type infrastructure, the invention solution is simpler, quicker and cheaper to implement than deploying an addon PKI type infrastructure in the cloud and at the device and client side.
  • the data relating to the data to be signed may be the data to be signed or any data resulting from a predetermined algorithm, such as e.g. a hash algorithm, the data to be signed being an input to the algorithm.
  • a predetermined algorithm such as e.g. a hash algorithm
  • the non-payment transaction channel is distinct from a payment transaction channel that is used for sending data relating to a payment transaction and that passes through a merchant access point, like e.g. a terminal or a server.
  • the non-payment transaction channel may use notably an OTA type channel to address the cloud.
  • the invention method may be automatically implemented.
  • a user of the device that implements the invention method is not involved to sign data except if her or his approval is explicitly requested from the device.
  • the invention method is therefore convenient for the user.
  • the invention is a device for signing data.
  • the device is configured to generate a first cryptogram by using a predetermined payment transaction key, a predetermined algorithm and data relating to data to be signed, as an input to the algorithm, the data to be signed being different from payment transaction data.
  • the device is also configured to send, without going through any payment transaction channel, to a first server a first message including a request for validating a signature relating to the data to be signed accompanied with the first cryptogram and the data relating to the data to be signed.
  • the device may be a terminal, a user terminal, an embedded chip or a smart card, as an SE.
  • the SE chip may be fixed to or removable from the device.
  • the invention does not impose any constraint as to a kind of the SE type.
  • a removable SE it may be a SIM type card, a Secure Removable Module (or SRM), a smart dongle of the USB (acronym for "Universal Serial Bus") type, a (micro-) Secure Digital (or SD) type card or a Multi-Media type Card (or MMC) or any format card to be coupled or connected to a chip host device.
  • SIM SIM type card
  • SRM Secure Removable Module
  • smart dongle of the USB (acronym for "Universal Serial Bus") type a (micro-) Secure Digital (or SD) type card or a Multi-Media type Card (or MMC) or any format card to be coupled or connected to a chip host device.
  • USB acronym for "Universal Serial Bus”
  • SD Secure Digital
  • MMC Multi-Media type Card
  • the chip host device may be constituted by any electronic device comprising data processing means, data storing means and one or several Input/Output (or I/O) communication interfaces, like e.g. a user terminal or a terminal.
  • I/O Input/Output
  • the invention is a first server for signing data.
  • the first server is configured to receive, without going through any payment transaction channel, a first message including a request for validating a signature relating to data to be signed accompanied with a first cryptogram and data relating to data to be signed.
  • the first server is configured to generate or let generate a second cryptogram by using a predetermined payment transaction key, a predetermined algorithm and the data relating to the data to be signed, as an input to the algorithm.
  • the first server is configured to compare or let compare the second cryptogram to the first cryptogram.
  • the first server is configured to validate or not a signature relating to the data to be signed if the second cryptogram does or does not match the first cryptogram respectively.
  • FIG. 1 is a simplified diagram of a mobile terminal equipment comprising a phone and a chip being arranged to sign data by using a payment transaction key and a predetermined algorithm and to send a resulting signature, via OTA, to a server that verifies or lets verify whether the signature is or is not valid, according to the invention;
  • FIG. 2 represents a simplified scheme for generating a cryptogram by using the payment transaction key, the algorithm that are resident on the chip, and data relating to the data to be signed, according to the invention, at a client side and at a server side;
  • FIG. 3 illustrates a simplified example of a flow of messages exchanged between notably a terminal user, the phone, the chip and the server(s) of figure 1 , so that the chip calculates the cryptogram by using the scheme of figure 2 and sends the cryptogram, as a signature, along with the data relating to the data to be signed, in order to validate (or not) the signature at the server side.
  • the chip may also incorporate at least part of the host terminal component(s), like e.g. a baseband processor, an application processor and/or other electronic component(s).
  • the host terminal component(s) like e.g. a baseband processor, an application processor and/or other electronic component(s).
  • the chip may be a Trusted Execution Environment (or TEE), as a secure area of a terminal processor and a secured runtime environment.
  • TEE Trusted Execution Environment
  • the SE may nevertheless have different form factors.
  • the chip may be carried by a medium, such as a smart card or a dongle, like e.g. a USB type dongle.
  • a medium such as a smart card or a dongle, like e.g. a USB type dongle.
  • the invention method for signing data is implemented by a device, as a standalone entity, at a client side.
  • the device like e.g. a mobile terminal, does not cooperate with any SE, so as to generate and issue a digital signature.
  • the device is adapted to carry out the functions that are described infra and that are carried out by the SE and the terminal .
  • Figure 1 shows schematically a Terminal Equipment (or TE) 10, a mobile network 16, a first remote server 18 and a second remote server 1 10.
  • Terminal Equipment or TE
  • the TE 10 includes a chip 12 and a mobile phone 14, as a (user) terminal and a chip host device.
  • the chip 12, the mobile phone 14, the mobile network 16, the first remote server 18 and the second remote server 1 10 are termed infra the SE 12, the phone 14, the network 16, the first server 18 and the second server 1 10 respectively.
  • a TE user 1 1 benefits from a subscription to access the network 16.
  • the TE 10 is under a radio coverage of the network 16.
  • the (user) terminal, the terminal or a machine in a Machine to Machine (or M2M) context as a terminal may be either fixed (i.e. not mobile) or mobile.
  • the (user) terminal may be a Personal Digital Assistant (or PDA), a vehicle, a set- top box, a tablet computer, a desktop computer, a laptop computer, a video player, an audio player, a portable Television (or TV), a media-player, a game console, a netbook, an electronic mobile equipment or a device accessory (like e.g. glasses, a watch or a jewel).
  • the user terminal or the terminal may be any other computer device including means for processing data, comprising (or being connected to) wireless communication means for exchanging data with outside, and comprising (or being connected to) means for storing data.
  • wireless communication means denotes notably that the communication means communicates via one or several Long Range (or LR) Radio-Frequency (or RF) links.
  • LR Long Range
  • RF Radio-Frequency
  • the LR RF may be fixed at several hundreds of MHz, for instance, around 850, 900, 1800, 1900 and/or 2100 MHz.
  • the phone 14 is preferably used for accessing one or several mobile radio- communication networks, namely at least the network 16.
  • the mobile radio-communication networks may be constituted by a Global System for Mobile Communications (or GSM), a General Packet Radio Service (or GPRS), a Universal Mobile Telecommunications System (or UMTS), an EDGE (acronym for "Enhanced Data Rates for GSM Evolution"), a Code Division Multiple Access (or CDMA) and/or a Long Term Evolution (or LTE) type network(s).
  • GSM Global System for Mobile Communications
  • GPRS General Packet Radio Service
  • UMTS Universal Mobile Telecommunications System
  • EDGE acronym for "Enhanced Data Rates for GSM Evolution"
  • CDMA Code Division Multiple Access
  • LTE Long Term Evolution
  • Such a cellular communication network set is not exhaustive but only for exemplifying purposes.
  • the phone 14 is connected, through a bi-directional link 13, to the SE 12.
  • the SE 12 is under control of a phone 14 (micro)processor (not represented).
  • the SE 12 is preferably associated with or tied to a network authentication server (not represented).
  • the network authentication server is included within (or connected to) the network 16.
  • the SE 12 belongs to a user, as a subscriber to a wireless service(s).
  • the SE 12 includes a (micro)processor(s) 122, as data processing means, a memory(ies) 124, as data storing means, and one or several I/O interfaces 126 that are internally all connected, through an internal bidirectional data bus 1 23, to each other.
  • the I/O interface(s) 126 allow(s) communicating data from the internal SE 12 components to the chip exterior and conversely.
  • the memory 124 stores an Operating System (or OS).
  • OS Operating System
  • the memory 124 stores preferably one or several SIM type applications.
  • the SIM type application(s) includes, among others, a SIM application for a GSM type network, a Universal Subscriber Identity Module (or USIM) application for a UMTS type network, a CDMA Subscriber Identity Module (or CSIM) application and/or an Internet protocol Multimedia Subsystem (or IMS) SIM (or ISIM) application.
  • a SIM application for a GSM type network a Universal Subscriber Identity Module (or USIM) application for a UMTS type network
  • CSIM CDMA Subscriber Identity Module
  • IMS Internet protocol Multimedia Subsystem
  • the SIM type application(s) allow(s) the phone 14 to identify and authenticate to at least one mobile network 16.
  • the memory 124 stores, preferably in a secure manner, one or several sets of data relating, each, to a subscription, as a wireless service(s).
  • the subscription data sets there is a subscription data set relating to the network 16.
  • the subscription data set is identified by an IMSI, as a subscription identifier.
  • the subscription data set relates to a Mobile Network Operator (or MNO) or a
  • MVNO Mobile Virtual Network Operator
  • Each set of data relating to one subscription includes:
  • an IMSI as a subscriber and a (service) subscription identifier for accessing a mobile network
  • a key Ki as a network authentication key, allowing to authenticate the subscriber to the concerned mobile network
  • one or several security keys like e.g. a key(s) for ciphering/deciphering data, as secret data; and/or
  • one or several credentials like e.g. a user name and/or an IDentifier (or ID) of the subscriber, as data relating to the user.
  • the subscription data set comprises an identifier IMSI relating to the subscription and preferably an associated key Ki, as a network authentication key, for authenticating the subscriber to the network 16.
  • the memory 124 may store data relating to a Uniform Resource Identifier (or URI), a Uniform Resource Locator (or URL) and/or an Internet Protocol (or IP) address of an external entity to be addressed, like e.g. a server 18 accessible within or through the network 16.
  • a Uniform Resource Identifier or URI
  • URL Uniform Resource Locator
  • IP Internet Protocol
  • the processor 122 processes, controls and communicates internally data with all the other components incorporated within the SE 12 and, through the I/O interface(s) 126, with the chip exterior.
  • the processor 122 executes or runs several applications, like e.g. a payment transaction application and an invention data signing application.
  • the memory 124 stores the payment transaction application, like e.g. an EMV type application.
  • the payment transaction application allows performing a payment transaction.
  • the SE 12 generates a payment transaction cryptogram, like e.g. an Authorization ReQuest Cryptogram (or ARQC), by using a predetermined payment transaction key, a predetermined payment transaction algorithm, card data, like e.g. a Primary Account Number (or PAN) identifying a concerned (card) issuing bank user, and payment transaction data, like e.g. a transaction amount, data currency, that is retrieved from a Point Of Sale (or POS) terminal .
  • the payment transaction cryptogram allows authorizing (or not) and securing the concerned payment transaction.
  • a server like e.g. a Token Service Provider (or TSP) in a CBP based solution, that is accessed over a payment transaction channel, verifies that the payment transaction cryptogram that is issued from the SE 12 is valid.
  • the payment transaction channel may pass through a merchant terminal and/or a server, a (payment transaction) acquirer (bank) infrastructure and a (payment transaction) issuer (bank) infrastructure.
  • the memory 124 stores the payment transaction key and possibly other payment transaction keys.
  • the (or each) payment transaction key may be restricted in use, like e.g. in time or a certain count of use, or permanent.
  • the payment transaction key may be a so-termed limited use key or single use key.
  • the (or each) payment transaction key may be encrypted with a Personal Identity Number (or PIN) or other user authentication data, like e.g . a fingerprint(s), an iris print(s) and/or a voice print(s), to be entered or submitted by the SE 12 user.
  • PIN Personal Identity Number
  • the user authentication data to be used as a reference user authentication data is only stored at a server side (and not at the SE/phone side).
  • the memory 124 stores the predetermined payment transaction algorithm, like e.g. a 3 Data Encryption Standard (or DES).
  • the memory 124 stores the invention data signing application.
  • the data signing application allows signing data to be signed, like e.g. a contract or any other data different from payment transaction data, as data relating to a non-payment transaction.
  • the data to be signed may originate from any source, like e.g. the phone user, the phone 14, an external server, another terminal that is connected to the SE 12 and/or the phone 14.
  • the SE 12 To perform such a (digital) signature, as further described in relation with the figure 2, the SE 12 generates a cryptogram, as a non-payment transaction signature, by using a predetermined payment transaction key, the predetermined payment transaction algorithm, like e.g. the 3 DES, and data relating to the data to be signed.
  • a predetermined payment transaction key like e.g. the 3 DES
  • Such a non-payment transaction cryptogram allows verifying that the considered signature that is issued from the SE 12 is valid.
  • the data signing application is preferably able to request from the SE user an approval or a disapproval for signing data to be signed accompanied with the data to be signed.
  • the user may enter or submit a PIN and/or other user authentication data, like e.g. biometric data, such as a fingerprint(s), an iris print(s) and/or a voice print(s).
  • the user authentication data allows preferably generating a non-payment transaction signature. For instance, to generate a nonpayment transaction signature, the SE 12 uses the user authentication data to decipher a ciphered payment transaction key.
  • Corresponding reference user authentication data is preferably stored only at the server side.
  • An appropriate server like e.g. the second server 1 10, uses the reference user authentication data, so as to generate a non-payment transaction cryptogram.
  • the concerned server uses the user authentication data to decipher a ciphered payment transaction key (accessible from the concerned server).
  • the non-payment transaction cryptogram is to be compared to a non-payment transaction signature to be received from a client device, so as to know whether the non-payment transaction signature is or is not valid.
  • the processor 122 is preferably able to initiate an action(s), in order to interact directly with the outside world, in an independent manner of the phone 14.
  • a capacity of interaction at the initiative of the SE 12 is also known as being a proactive capacity in which the SE 12 plays a role of a master while the SE host device plays a role of a slave.
  • the SE 12 is able to use SIM ToolKit (or STK) type commands, as proactive commands.
  • the SE 12 is thus able to send, at its own initiative, either through (to any device, like e.g. the server 16 connected to the phone 14) or to the phone 14, a message by using a proactive command, like e.g. a "SEND SHORT MESSAGE".
  • Such a proactive command allows sending, through the phone 14, to the first server 18 a message including a request for validating a (digital) signature relating to the data to be signed accompanied with the (non-payment transaction) cryptogram and the data relating to the data to be signed through a mobile network connection that is(are) provided by the SE host device.
  • a Short Message Service (or SMS) type message (or the like) that conveys the signature (to be verified) does not pass through any payment transaction channel.
  • the processor 122 executes, in a preferred manner, one or several security functions.
  • the security functions include preferably a local (off-line) user authentication process to be used prior to continuing to access the SE 12, notably at a boot, i.e. a power on, of the SE 12.
  • a PIN or biometric data as reference user authentication data, that is stored, preferably in a secure manner, within the memory 124.
  • biometric data it may include one or several fingerprints, one or several iris prints and/or one or several voiceprints relating to one or several authorized users.
  • the security functions include preferably a data ciphering/deciphering function that allows ciphering/deciphering data prior to its sending/after its receiving respectively, so as to secure a data transmission with an SE interlocutor, like e.g. the first server 18.
  • the SE 12 is fixedly coupled or connected to the phone 14, as an SE host device.
  • the phone 14 comprises the SE 12 that is removable from the phone 14.
  • the phone I/O interfaces include one or several I/O interfaces for exchanging data with the SE 12.
  • the phone I/O interface with the SE 12 may be an International Organization for Standardization (or ISO) 7816 interface, as a contact interface, when the SE 12 is inserted, in a removable manner, within the phone 14.
  • ISO International Organization for Standardization
  • the phone I/O interface with the SE 12 is connected to or includes a contact-less interface.
  • the phone 14 is connected to or includes means for communicating data while using preferably a Short Range (or SR) RF link.
  • the SR RF link may be related to any technology that allows the phone 14 to exchange data, through a so-termed contact-less link with the SE 12.
  • the SR RF may be fixed at 13,56 MHz and related to a Near Field Communication (or NFC) type technology, as a contact-less technology.
  • the phone 14 includes data processing means, such as one (micro)processor (not represented), data storing means (not represented), as a phone memory, and one or several I/O interfaces that are linked all together through a control and data bus (not represented).
  • data processing means such as one (micro)processor (not represented), data storing means (not represented), as a phone memory, and one or several I/O interfaces that are linked all together through a control and data bus (not represented).
  • the phone 14 plays, in a preferential manner, a role of a modulator-demodulator (or modem), so as to exchange data in a wireless manner.
  • a modulator-demodulator or modem
  • the phone 14 carries out the following operations:
  • the phone memory may comprise one or several memories including one or several volatile memories and one or several non-volatile memories.
  • the phone memory may be constituted by one or several EEPROMs (acronym for "Electrically Erasable Programmable Read-Only Memory”), one or several ROMs (acronym for "Read Only Memory”), one or several Flash memories, and/or any other memories of different types, like one or several RAMs (acronym for "Random Access Memory”).
  • EEPROMs electrically Erasable Programmable Read-Only Memory
  • ROMs acronym for "Read Only Memory”
  • Flash memories and/or any other memories of different types, like one or several RAMs (acronym for "Random Access Memory”).
  • the phone memory stores e.g an International Mobile Equipment Identity (or IMEI), as a phone 14 identifier, and/or an email address, as an identifier(s) relating to the phone 14.
  • IMEI International Mobile Equipment Identity
  • the phone memory stores e.g an International Mobile Equipment Identity (or IMEI), as a phone 14 identifier, and/or an email address, as an identifier(s) relating to the phone 14.
  • IMEI International Mobile Equipment Identity
  • the phone memory may store, at least in a temporary manner, a configuration parameter(s) to be used for addressing the first server 18.
  • a configuration parameter(s) may be provided by the SE 12.
  • the configuration parameter(s) allow(s) configuring an access, through a connected mobile network(s) 16, to the first server 18 (comprised in the cloud).
  • the phone memory stores an OS and one or several applications.
  • the phone 14 includes preferably a display screen 142 and a keyboard 144, as Man Machine Interface (or MMI).
  • MMI Man Machine Interface
  • the phone 14 is equipped with a touch sensitive display screen, as a virtual keyboard.
  • the phone MM I allows preferably presenting data to be signed to the phone user
  • the phone MMI allows the phone user 1 1 to interact with the phone 14.
  • the SE 12 may thus get a user approval or disapproval for signing the data to be signed.
  • the phone 14 is connected, over a wireless link 15, to the mobile network 16.
  • the network 16 is connected, over a wire or wireless link 17, to the first server 18.
  • the first server 18 is hosted by a computer with data processing means and data storing means.
  • the first server 18 may be connected, over a wire or wireless link 19, to the second server 1 10.
  • the first server 18 may carry out each function carried out by the second server 1 10 that is described infra.
  • the first server 18 accesses a database stored in a memory (not represented) that is present within or connected to the first server 18.
  • the database may include a first correspondence table.
  • the first correspondence table includes, for at least one identifier, like e.g. a PAN, an IMSI, an IMEI and/or a Mobile Station International Subscriber Directory Number (or MSISDN), an identifier(s), such as e.g. a URI and/or a URL, relating to a second server 1 10 to be addressed.
  • identifier like e.g. a PAN, an IMSI, an IMEI and/or a Mobile Station International Subscriber Directory Number (or MSISDN), an identifier(s), such as e.g. a URI and/or a URL, relating to a second server 1 10 to be addressed.
  • the first server 18 may be able to send to a client (device), like e.g. the SE 12, (or its user) a document and/or any other data to be signed.
  • a client like e.g. the SE 12, (or its user) a document and/or any other data to be signed.
  • the database may include a second correspondence table.
  • the second correspondence table includes, for at least one identifier relating to data to be signed, the data to be signed.
  • the first server 18 may thus be able to send to a client (device), like e.g. the SE 12, (or its user) a document, as data to be signed, and an identifier(s) relating to the data to be signed, as a reference to the data to be signed. If the first server 18 receives from the client device (or another device) a message including the reference to the data to be signed, then the first server 18 gets or retrieves, by using the second correspondence table, corresponding data to be signed.
  • a client like e.g. the SE 12, (or its user) a document
  • an identifier(s) relating to the data to be signed as a reference to the data to be signed.
  • the first server 18 is thus able to request the client to sign joined data (to be signed).
  • the first server 18 is able to receive, without passing through any payment transaction channel, i.e. through the network 16, from a client device a message including a request for validating a signature relating to data (to be signed) accompanied with a cryptogram and data relating to the data to be signed.
  • the signature validation request message may include the reference to the data to be signed.
  • the first server 18 may verify whether the data relating to the data to be signed is or is not valid, i.e. received data has a predetermined length value or any other predetermined data format, and authorize continuing a data processing only if the data relating to the data to be signed is valid.
  • the first server 18 may verify whether the data to be signed is or is not valid by using preferably a reference to the data to be signed to be sent to and received from a client device, i.e. e.g. a signature validation request message has been received before an expiring date and/or time, and authorize continuing a data processing only if the data to be signed is valid.
  • a reference to the data to be signed to be sent to and received from a client device i.e. e.g. a signature validation request message has been received before an expiring date and/or time
  • the second server 1 like e.g. a TSP, that manages a bank account relating to the phone user 1 1 , as a (bank) issuer, is hosted by a computer with data processing means and data storing means.
  • the second server 1 10 may generate a cryptogram to be matched by a signature to be received from the server 18.
  • the second server 1 10 may be used for generating a cryptogram by using the predetermined payment transaction key, the predetermined algorithm and data relating to the data to be signed and to be received through the first server 18, when applicable.
  • the second server 1 10 uses preferably a reference PIN and/or reference user authentication data, like e.g. biometric data, to decipher a previously ciphered payment transaction key by the second server 1 10 or another server.
  • the second server 1 10 may be used for comparing the cryptogram (that is generated by itself or another server) to a signature that is issued from the concerned client device, like e.g. the SE 12.
  • a result of such a comparison between the generated cryptogram and a received signature is either successful, i.e. the cryptogram matches the signature, or unsuccessful, i.e. the cryptogram is distinct from the signature.
  • Figure 2 is an exemplary embodiment of a way 20 to generate a non-payment transaction cryptogram, as a digital signature, both at the client side and at the server side.
  • data 21 to be signed may be an input to a first algorithm 22, like e.g. a hash type function allowing to reduce a length value of the data to be signed, like e.g. a length value of the resulting data hash value is 32 digits, as data relating to the data to be signed.
  • a first algorithm 22 like e.g. a hash type function allowing to reduce a length value of the data to be signed, like e.g. a length value of the resulting data hash value is 32 digits, as data relating to the data to be signed.
  • the hash type function may be e.g. a SHA-256 or a MD 5 type function or the like.
  • a hash relating to the data to be signed, as the result or output 23 of the first algorithm, or the data to be signed itself, as data relating to the data to be signed is an input 23 to a payment transaction algorithm and a non-payment transaction algorithm, as a second algorithm 24 and a signature algorithm.
  • the data relating to the data to be signed fills in one or several data fields, like e.g. card data and/or terminal data, which are used by the payment transaction algorithm 24, like e.g. a 3 DES, as a non-payment transaction algorithm and a data signature algorithm 24.
  • the payment transaction algorithm 24 like e.g. a 3 DES, as a non-payment transaction algorithm and a data signature algorithm 24.
  • a payment transaction key 25 is preferably an input to a third algorithm 26, like e.g. a XOR type function, as a ciphering function by using a (user) PIN 27 and/or other user authentication data.
  • a third algorithm 26 like e.g. a XOR type function, as a ciphering function by using a (user) PIN 27 and/or other user authentication data.
  • a session key, as the result or output 28 of the third algorithm 26, is an input 28 to the second algorithm 24.
  • a result or output 210 of the second algorithm 24 is a non-payment transaction cryptogram, as a data signature.
  • Figure 3 depicts an exemplary embodiment of a message flow 30 that involves the SE 12, the phone 14, the first server 18 and the second server 1 10.
  • the client device is the SE 12.
  • the first server 18 relays information between the client device and the second server 1 10 that is dedicated to a cryptogram generation and comparison.
  • the invention is still applicable if the data signature process is triggered by the phone user 1 1 , the SE 12 or any other device connected to the SE 12.
  • the first server 18 sends to the SE 12, as a client device, a message 31 including a request for signing a document, as data to be signed, the document and preferably an identifier relating to the document.
  • the SE 12 sends to the phone 14 a message 32, such as e.g. a proactive command "Display TEXT" along with the document to be displayed to the user 1 1 and preferably a message for requesting a phone user approval or disapproval, such as "do you approve to sign the displayed document?", for signing the document.
  • the phone 14 then sends to the display screen 142 (or another connected display screen) a message 33 including the document (to be signed) and the user approval request message.
  • the phone user 1 1 gives (or not) her/his approval for signing the document by using the phone MMI, like e.g. by depressing a button(s) "Yes” or "No". To give her/his approval, the user 1 1 may enter, through the phone MMI or the like, a PIN, as user authentication data.
  • the user 1 1 sends, via the phone MMI, to the phone 14 a message 34 including a user approval request response.
  • the phone 14 then sends to the SE 12 a message 36 including the user approval request response.
  • the SE 12 analyses and interprets the received message 36 and, if the user 1 1 gives her/his approval possibly by entering user authentication data, then the SE 12 generates 38 a first cryptogram by using a predetermined payment transaction key, a predetermined algorithm 24 (as explained in relation with figure 2) and a hash value relating to the document, as data relating to the data to be signed. Otherwise, i.e. if the user 1 1 does not give her/his approval, the SE 12 does not authorize generating 38 any cryptogram and the data signature process is terminated. Alternately, instead of a document hash value, the document data (itself) is used for generating the first cryptogram.
  • the SE 12 sends, without going through any payment transaction channel, i.e. directly through the network 16, to the first server 18 a message 39 including a request for validating a signature relating to the document accompanied with the first cryptogram, the hash value relating to the document or the document (itself), as the data relating to the data to be signed, and possibly the document identifier (when received from the first server 18 or another entity).
  • the first server 18 then sends, after a possible successful verification(s) of the document validity and/or a document hash value validity (not represented) by getting the document based on the document identifier, to the second server 1 10 a message 310 including a request for authorizing a payment transaction accompanied with the first cryptogram and the data relating to the data to be signed.
  • the data relating to the data to be signed i.e. the hash value relating to the document or the document data, may be included within one or several data fields that are used for transmitting data relating to card data and/or data relating to terminal data in a corresponding payment transaction authorization request message.
  • the second server 1 10 As soon as the second server 1 10 has received the last message 310, the second server 1 10 generates 312 a second cryptogram by using a predetermined payment transaction key, a predetermined algorithm 24 (as explained in relation with figure 2) and the data relating to the data to be signed, namely the hash value relating to the document or the document data.
  • the second server 1 10 compares 314 the second cryptogram to the first cryptogram, as a payment transaction signature.
  • the second server 1 10 sends to the first server 18 a message 316 including a payment transaction refusal, as a request 310 response.
  • the first server 18 analyses and interprets the last message 316.
  • the first server 18 does not validate 318 a resulting digital (and nonpayment transaction) signature.
  • the second server 1 10 sends to the first server 18 a message 320 including a payment transaction authorization, as a request 310 response.
  • the first server 18 analyses and interprets the last message 320.
  • the first server 18 validates 322 a resulting digital (and nonpayment transaction) signature.
  • the digital signature is thus validated by one and the same payment transaction key and one and the same payment transaction algorithm at the client and server sides.
  • the invention solution is compatible notably with the existing CBP type infrastructure.
  • Such an invention data signature method allows re-using an existing CBP type infrastructure reducing thus a technical complexity and corresponding costs to offer a data signature service.
  • the invention solution does not need to involve a phone user, except for submitting user authentication data, when applicable.

Landscapes

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

Abstract

The invention relates to a method (30) for signing data. According to the invention, the method comprises the following steps. A device (12) generates (38) a first cryptogram by using a predetermined payment transaction key, a predetermined algorithm and data relating to data to be signed, as an input to the algorithm. The data to be signed is different from payment transaction data. The device sends, without going through any payment transaction channel, to a first server (18) a first message (39) including a request for validating a signature relating to the data to be signed accompanied with the first cryptogram and the data relating to the data to be signed. The first or a second server generates (312) a second cryptogram by using the predetermined payment transaction key, the predetermined algorithm and the data relating to the data to be signed, as an input to the algorithm. The first or the second server compares (314) the second cryptogram to the first cryptogram. If the second cryptogram does or does not match the first cryptogram, then the first or the second server does (322) or does not (318) validate a signature relating to the data to be signed respectively. The invention also relates to corresponding device (12) and server(s) (18) (and 110).

Description

METHOD, DEVICE AND SERVER FOR SIGNING DOCUMENT USING A BANKING
TRANSACTION KEY
Field of the invention: The invention relates generally to a method for signing data.
Furthermore, the invention also pertains to a device for signing data.
The device may be a (user) terminal, an embedded chip or a smart card, as a Secure Element (or SE).
The invention is notably applicable to a mobile radio-communication field wherein the device is a mobile terminal or a chip that may be embedded, such as an embedded Universal Integrated Circuit Card (or eUICC) within a host device, or removable from a host device, as a chip included within a smart card termed Subscriber Identity Module (or SIM) type card or the like, as an SE.
Within the present description, an SE is a smart object or device that includes a chip that protects, as a tamper resistant component, physically access to stored data and is intended to communicate, preferably in a secure manner, data with the outside world, like e.g. a mobile (tele)phone, as an SE host device.
Finally, the invention pertains to a first server for signing data as well. State of the art:
As known per se, a Subscriber Identity Module (or SIM) card, as an SE, generates a private key and a corresponding public key. The SIM card sends the SIM public key, through a mobile phone, Over The Air (or OTA), to a server. The server is thus enabled to verify whether data signed by the SIM card is or is not valid by using the received SIM card public key.
However, such a Public Key Infrastructure (or PKI) - based solution implies to deploy an additional infrastructure in the "cloud" which is complex and expensive to implement.
Thus, there is a need to provide a solution that allows offering a digital signature service without needing to deploy any additional infrastructure. Summary of the invention:
The invention proposes a solution for satisfying the just herein above specified need by providing a method for signing data.
According to the invention, the method comprises the following steps. A device generates a first cryptogram by using a predetermined payment transaction key, a predetermined algorithm and data relating to data to be signed, as an input to the algorithm. The data to be signed is different from payment transaction data. The device sends, without going through any payment transaction channel, to a first server a first message including a request for validating a signature relating to the data to be signed accompanied with the first cryptogram and the data relating to the data to be signed. The first or a second server generates a second cryptogram by using the predetermined payment transaction key, the predetermined algorithm and the data relating to the data to be signed, as an input to the algorithm. The first or the second server compares the second cryptogram to the first cryptogram. If the second cryptogram does or does not match the first cryptogram, then the first or the second server does or does not validate a signature relating to the data to be signed respectively.
The principle of the invention consists in that a device uses a predefined payment transaction key that is dedicated to a payment transaction application, a predetermined algorithm and data relating to data to be signed in order to compute a corresponding signature. The device sends, besides the data relating to the data to be signed, the signature, via a non-payment transaction channel, to a server. Then, at the server side, a cryptogram is computed using the received data relating to the data to be signed, the payment transaction key and the algorithm. A (or the) server validates the signature only if the received signature and the cryptogram computed at the server side matches.
It is to be noted that the data to be signed may be of any type. For instance, the data to be signed includes binary data, data relating to a document(s), data relating to message(s) and/or any other kind of data the origin of which has to be known to its addressee.
It is noteworthy that the payment transaction application may also be of any type, like e.g. an Europay Mastercard Visa (or EMV) application or the like.
Such an invention solution leverages on an existing Cloud-Based Payment (or CBP) type infrastructure, so as to add a digital signature service. Thus, since the invention solution re-uses the existing CBP type infrastructure, the invention solution is simpler, quicker and cheaper to implement than deploying an addon PKI type infrastructure in the cloud and at the device and client side.
It is further to be noted that the data relating to the data to be signed may be the data to be signed or any data resulting from a predetermined algorithm, such as e.g. a hash algorithm, the data to be signed being an input to the algorithm.
The non-payment transaction channel is distinct from a payment transaction channel that is used for sending data relating to a payment transaction and that passes through a merchant access point, like e.g. a terminal or a server. The non-payment transaction channel may use notably an OTA type channel to address the cloud.
The invention method may be automatically implemented.
Thus, a user of the device that implements the invention method is not involved to sign data except if her or his approval is explicitly requested from the device.
The invention method is therefore convenient for the user.
According to a further aspect, the invention is a device for signing data.
According to the invention, the device is configured to generate a first cryptogram by using a predetermined payment transaction key, a predetermined algorithm and data relating to data to be signed, as an input to the algorithm, the data to be signed being different from payment transaction data. The device is also configured to send, without going through any payment transaction channel, to a first server a first message including a request for validating a signature relating to the data to be signed accompanied with the first cryptogram and the data relating to the data to be signed.
The device may be a terminal, a user terminal, an embedded chip or a smart card, as an SE.
The SE chip may be fixed to or removable from the device.
The invention does not impose any constraint as to a kind of the SE type.
As a removable SE, it may be a SIM type card, a Secure Removable Module (or SRM), a smart dongle of the USB (acronym for "Universal Serial Bus") type, a (micro-) Secure Digital (or SD) type card or a Multi-Media type Card (or MMC) or any format card to be coupled or connected to a chip host device.
As to the chip host device, it may be constituted by any electronic device comprising data processing means, data storing means and one or several Input/Output (or I/O) communication interfaces, like e.g. a user terminal or a terminal.
According to a further aspect, the invention is a first server for signing data. According to the invention, the first server is configured to receive, without going through any payment transaction channel, a first message including a request for validating a signature relating to data to be signed accompanied with a first cryptogram and data relating to data to be signed. The first server is configured to generate or let generate a second cryptogram by using a predetermined payment transaction key, a predetermined algorithm and the data relating to the data to be signed, as an input to the algorithm. The first server is configured to compare or let compare the second cryptogram to the first cryptogram. The first server is configured to validate or not a signature relating to the data to be signed if the second cryptogram does or does not match the first cryptogram respectively.
Brief description of the drawings:
Additional features and advantages of the invention will be more clearly understandable after reading a detailed description of one preferred embodiment of the invention, given as one indicative and non-limitative example, in conjunction with the following drawings:
- Figure 1 is a simplified diagram of a mobile terminal equipment comprising a phone and a chip being arranged to sign data by using a payment transaction key and a predetermined algorithm and to send a resulting signature, via OTA, to a server that verifies or lets verify whether the signature is or is not valid, according to the invention;
- Figure 2 represents a simplified scheme for generating a cryptogram by using the payment transaction key, the algorithm that are resident on the chip, and data relating to the data to be signed, according to the invention, at a client side and at a server side; and
- Figure 3 illustrates a simplified example of a flow of messages exchanged between notably a terminal user, the phone, the chip and the server(s) of figure 1 , so that the chip calculates the cryptogram by using the scheme of figure 2 and sends the cryptogram, as a signature, along with the data relating to the data to be signed, in order to validate (or not) the signature at the server side.
Detailed description: Herein under is considered an embodiment in which the invention method for signing data is implemented notably by a chip, like e.g. an eUICC, as an SE incorporated within a mobile terminal and a chip soldered, possibly in a removable manner, on a Printed Circuit Board (or PCB) of the terminal, at a client side.
The chip may also incorporate at least part of the host terminal component(s), like e.g. a baseband processor, an application processor and/or other electronic component(s).
Alternately, instead of an eUICC, the chip may be a Trusted Execution Environment (or TEE), as a secure area of a terminal processor and a secured runtime environment.
The SE may nevertheless have different form factors.
Instead of being embedded within its host device, the chip may be carried by a medium, such as a smart card or a dongle, like e.g. a USB type dongle.
According to another embodiment (not represented), the invention method for signing data is implemented by a device, as a standalone entity, at a client side. In other words, the device, like e.g. a mobile terminal, does not cooperate with any SE, so as to generate and issue a digital signature. According to such an embodiment (not represented), the device is adapted to carry out the functions that are described infra and that are carried out by the SE and the terminal .
Naturally, the herein below described embodiment is only for exemplifying purposes and is not considered to reduce the scope of the invention.
Figure 1 shows schematically a Terminal Equipment (or TE) 10, a mobile network 16, a first remote server 18 and a second remote server 1 10.
The TE 10 includes a chip 12 and a mobile phone 14, as a (user) terminal and a chip host device.
For sake of simplicity, the chip 12, the mobile phone 14, the mobile network 16, the first remote server 18 and the second remote server 1 10 are termed infra the SE 12, the phone 14, the network 16, the first server 18 and the second server 1 10 respectively.
A TE user 1 1 benefits from a subscription to access the network 16.
The TE 10 is under a radio coverage of the network 16.
The (user) terminal, the terminal or a machine in a Machine to Machine (or M2M) context as a terminal may be either fixed (i.e. not mobile) or mobile. The (user) terminal may be a Personal Digital Assistant (or PDA), a vehicle, a set- top box, a tablet computer, a desktop computer, a laptop computer, a video player, an audio player, a portable Television (or TV), a media-player, a game console, a netbook, an electronic mobile equipment or a device accessory (like e.g. glasses, a watch or a jewel).
Instead of a phone, the user terminal or the terminal may be any other computer device including means for processing data, comprising (or being connected to) wireless communication means for exchanging data with outside, and comprising (or being connected to) means for storing data.
Within the present description, the adjective "wireless" used within the expression
"wireless communication means" denotes notably that the communication means communicates via one or several Long Range (or LR) Radio-Frequency (or RF) links.
The LR RF may be fixed at several hundreds of MHz, for instance, around 850, 900, 1800, 1900 and/or 2100 MHz.
The phone 14 is preferably used for accessing one or several mobile radio- communication networks, namely at least the network 16.
The mobile radio-communication networks, as cellular communication networks, may be constituted by a Global System for Mobile Communications (or GSM), a General Packet Radio Service (or GPRS), a Universal Mobile Telecommunications System (or UMTS), an EDGE (acronym for "Enhanced Data Rates for GSM Evolution"), a Code Division Multiple Access (or CDMA) and/or a Long Term Evolution (or LTE) type network(s).
Such a cellular communication network set is not exhaustive but only for exemplifying purposes.
The phone 14 is connected, through a bi-directional link 13, to the SE 12.
The SE 12 is under control of a phone 14 (micro)processor (not represented).
The SE 12 is preferably associated with or tied to a network authentication server (not represented). The network authentication server is included within (or connected to) the network 16.
The SE 12 belongs to a user, as a subscriber to a wireless service(s).
The SE 12 includes a (micro)processor(s) 122, as data processing means, a memory(ies) 124, as data storing means, and one or several I/O interfaces 126 that are internally all connected, through an internal bidirectional data bus 1 23, to each other. The I/O interface(s) 126 allow(s) communicating data from the internal SE 12 components to the chip exterior and conversely.
The memory 124 stores an Operating System (or OS).
The memory 124 stores preferably one or several SIM type applications.
The SIM type application(s) includes, among others, a SIM application for a GSM type network, a Universal Subscriber Identity Module (or USIM) application for a UMTS type network, a CDMA Subscriber Identity Module (or CSIM) application and/or an Internet protocol Multimedia Subsystem (or IMS) SIM (or ISIM) application.
The SIM type application(s) allow(s) the phone 14 to identify and authenticate to at least one mobile network 16.
The memory 124 stores, preferably in a secure manner, one or several sets of data relating, each, to a subscription, as a wireless service(s). Among the subscription data sets, there is a subscription data set relating to the network 16.
The subscription data set is identified by an IMSI, as a subscription identifier.
The subscription data set relates to a Mobile Network Operator (or MNO) or a
Mobile Virtual Network Operator (or MVNO), as a network 16 operator.
Each set of data relating to one subscription includes:
- an IMSI, as a subscriber and a (service) subscription identifier for accessing a mobile network;
- a key Ki, as a network authentication key, allowing to authenticate the subscriber to the concerned mobile network;
- Milenage (or the like), as a network authentication algorithm, allowing to authenticate the subscriber to the concerned mobile network;
- a file system including one or several Elementary Files (or EF);
- one or several security keys, like e.g. a key(s) for ciphering/deciphering data, as secret data; and/or
- one or several credentials, like e.g. a user name and/or an IDentifier (or ID) of the subscriber, as data relating to the user.
The subscription data set comprises an identifier IMSI relating to the subscription and preferably an associated key Ki, as a network authentication key, for authenticating the subscriber to the network 16.
The memory 124 may store data relating to a Uniform Resource Identifier (or URI), a Uniform Resource Locator (or URL) and/or an Internet Protocol (or IP) address of an external entity to be addressed, like e.g. a server 18 accessible within or through the network 16.
The processor 122 processes, controls and communicates internally data with all the other components incorporated within the SE 12 and, through the I/O interface(s) 126, with the chip exterior.
The processor 122 executes or runs several applications, like e.g. a payment transaction application and an invention data signing application.
Among the supported applications, the memory 124 stores the payment transaction application, like e.g. an EMV type application. The payment transaction application allows performing a payment transaction. To perform a payment transaction, the SE 12 generates a payment transaction cryptogram, like e.g. an Authorization ReQuest Cryptogram (or ARQC), by using a predetermined payment transaction key, a predetermined payment transaction algorithm, card data, like e.g. a Primary Account Number (or PAN) identifying a concerned (card) issuing bank user, and payment transaction data, like e.g. a transaction amount, data currency, that is retrieved from a Point Of Sale (or POS) terminal . The payment transaction cryptogram allows authorizing (or not) and securing the concerned payment transaction. As known per se, to authorize the payment transaction, a server, like e.g. a Token Service Provider (or TSP) in a CBP based solution, that is accessed over a payment transaction channel, verifies that the payment transaction cryptogram that is issued from the SE 12 is valid. The payment transaction channel may pass through a merchant terminal and/or a server, a (payment transaction) acquirer (bank) infrastructure and a (payment transaction) issuer (bank) infrastructure.
The memory 124 stores the payment transaction key and possibly other payment transaction keys. The (or each) payment transaction key may be restricted in use, like e.g. in time or a certain count of use, or permanent. The payment transaction key may be a so-termed limited use key or single use key. The (or each) payment transaction key may be encrypted with a Personal Identity Number (or PIN) or other user authentication data, like e.g . a fingerprint(s), an iris print(s) and/or a voice print(s), to be entered or submitted by the SE 12 user. The user authentication data to be used as a reference user authentication data is only stored at a server side (and not at the SE/phone side).
The memory 124 stores the predetermined payment transaction algorithm, like e.g. a 3 Data Encryption Standard (or DES). The memory 124 stores the invention data signing application. The data signing application allows signing data to be signed, like e.g. a contract or any other data different from payment transaction data, as data relating to a non-payment transaction. The data to be signed may originate from any source, like e.g. the phone user, the phone 14, an external server, another terminal that is connected to the SE 12 and/or the phone 14.
To perform such a (digital) signature, as further described in relation with the figure 2, the SE 12 generates a cryptogram, as a non-payment transaction signature, by using a predetermined payment transaction key, the predetermined payment transaction algorithm, like e.g. the 3 DES, and data relating to the data to be signed.
Such a non-payment transaction cryptogram allows verifying that the considered signature that is issued from the SE 12 is valid.
The data signing application is preferably able to request from the SE user an approval or a disapproval for signing data to be signed accompanied with the data to be signed. To perform such a user request, the user may enter or submit a PIN and/or other user authentication data, like e.g. biometric data, such as a fingerprint(s), an iris print(s) and/or a voice print(s). The user authentication data allows preferably generating a non-payment transaction signature. For instance, to generate a nonpayment transaction signature, the SE 12 uses the user authentication data to decipher a ciphered payment transaction key.
Corresponding reference user authentication data is preferably stored only at the server side. An appropriate server, like e.g. the second server 1 10, uses the reference user authentication data, so as to generate a non-payment transaction cryptogram. For instance, to generate a non-payment transaction cryptogram, the concerned server uses the user authentication data to decipher a ciphered payment transaction key (accessible from the concerned server). The non-payment transaction cryptogram is to be compared to a non-payment transaction signature to be received from a client device, so as to know whether the non-payment transaction signature is or is not valid.
The processor 122 is preferably able to initiate an action(s), in order to interact directly with the outside world, in an independent manner of the phone 14. Such a capacity of interaction at the initiative of the SE 12 is also known as being a proactive capacity in which the SE 12 plays a role of a master while the SE host device plays a role of a slave. According to one preferred embodiment, the SE 12 is able to use SIM ToolKit (or STK) type commands, as proactive commands. The SE 12 is thus able to send, at its own initiative, either through (to any device, like e.g. the server 16 connected to the phone 14) or to the phone 14, a message by using a proactive command, like e.g. a "SEND SHORT MESSAGE". Such a proactive command allows sending, through the phone 14, to the first server 18 a message including a request for validating a (digital) signature relating to the data to be signed accompanied with the (non-payment transaction) cryptogram and the data relating to the data to be signed through a mobile network connection that is(are) provided by the SE host device. Such a Short Message Service (or SMS) type message (or the like) that conveys the signature (to be verified) does not pass through any payment transaction channel.
The processor 122 executes, in a preferred manner, one or several security functions.
The security functions include preferably a local (off-line) user authentication process to be used prior to continuing to access the SE 12, notably at a boot, i.e. a power on, of the SE 12. To authenticate the user, the user has to provide a PIN or biometric data, as reference user authentication data, that is stored, preferably in a secure manner, within the memory 124. As biometric data, it may include one or several fingerprints, one or several iris prints and/or one or several voiceprints relating to one or several authorized users.
The security functions include preferably a data ciphering/deciphering function that allows ciphering/deciphering data prior to its sending/after its receiving respectively, so as to secure a data transmission with an SE interlocutor, like e.g. the first server 18.
The SE 12 is fixedly coupled or connected to the phone 14, as an SE host device. Alternately, the phone 14 comprises the SE 12 that is removable from the phone 14.
The phone I/O interfaces include one or several I/O interfaces for exchanging data with the SE 12.
The phone I/O interface with the SE 12 may be an International Organization for Standardization (or ISO) 7816 interface, as a contact interface, when the SE 12 is inserted, in a removable manner, within the phone 14.
Alternately, instead of a contact interface, the phone I/O interface with the SE 12 is connected to or includes a contact-less interface. The phone 14 is connected to or includes means for communicating data while using preferably a Short Range (or SR) RF link. The SR RF link may be related to any technology that allows the phone 14 to exchange data, through a so-termed contact-less link with the SE 12. The SR RF may be fixed at 13,56 MHz and related to a Near Field Communication (or NFC) type technology, as a contact-less technology.
The phone 14 includes data processing means, such as one (micro)processor (not represented), data storing means (not represented), as a phone memory, and one or several I/O interfaces that are linked all together through a control and data bus (not represented).
The phone 14 plays, in a preferential manner, a role of a modulator-demodulator (or modem), so as to exchange data in a wireless manner.
The phone 14 carries out the following operations:
- a modulation of an analogical carrier signal to encode digital information to be transmitted, over an antenna 140, to one (or several) network(s) 16, and
- a demodulation of a received analogical carrier signal to decode the encoded digital information that is received, over the antenna 140, from one (or several) network(s) 16.
The phone memory may comprise one or several memories including one or several volatile memories and one or several non-volatile memories.
The phone memory may be constituted by one or several EEPROMs (acronym for "Electrically Erasable Programmable Read-Only Memory"), one or several ROMs (acronym for "Read Only Memory"), one or several Flash memories, and/or any other memories of different types, like one or several RAMs (acronym for "Random Access Memory").
The phone memory stores e.g an International Mobile Equipment Identity (or IMEI), as a phone 14 identifier, and/or an email address, as an identifier(s) relating to the phone 14.
The phone memory may store, at least in a temporary manner, a configuration parameter(s) to be used for addressing the first server 18. Such a configuration parameter(s) may be provided by the SE 12. The configuration parameter(s) allow(s) configuring an access, through a connected mobile network(s) 16, to the first server 18 (comprised in the cloud).
The phone memory stores an OS and one or several applications.
The phone 14 includes preferably a display screen 142 and a keyboard 144, as Man Machine Interface (or MMI).
Alternatively, instead of a physical keyboard separated from the display screen, the phone 14 is equipped with a touch sensitive display screen, as a virtual keyboard. The phone MM I allows preferably presenting data to be signed to the phone user
1 1 .
The phone MMI allows the phone user 1 1 to interact with the phone 14. The SE 12 may thus get a user approval or disapproval for signing the data to be signed.
The phone 14 is connected, over a wireless link 15, to the mobile network 16.
The network 16 is connected, over a wire or wireless link 17, to the first server 18.
The first server 18 is hosted by a computer with data processing means and data storing means.
The first server 18 may be connected, over a wire or wireless link 19, to the second server 1 10.
Instead of exchanging with the second server 1 10, the first server 18 may carry out each function carried out by the second server 1 10 that is described infra.
The first server 18 accesses a database stored in a memory (not represented) that is present within or connected to the first server 18.
The database may include a first correspondence table. The first correspondence table includes, for at least one identifier, like e.g. a PAN, an IMSI, an IMEI and/or a Mobile Station International Subscriber Directory Number (or MSISDN), an identifier(s), such as e.g. a URI and/or a URL, relating to a second server 1 10 to be addressed.
The first server 18 may be able to send to a client (device), like e.g. the SE 12, (or its user) a document and/or any other data to be signed.
The database may include a second correspondence table. The second correspondence table includes, for at least one identifier relating to data to be signed, the data to be signed. The first server 18 may thus be able to send to a client (device), like e.g. the SE 12, (or its user) a document, as data to be signed, and an identifier(s) relating to the data to be signed, as a reference to the data to be signed. If the first server 18 receives from the client device (or another device) a message including the reference to the data to be signed, then the first server 18 gets or retrieves, by using the second correspondence table, corresponding data to be signed.
The first server 18 is thus able to request the client to sign joined data (to be signed).
The first server 18 is able to receive, without passing through any payment transaction channel, i.e. through the network 16, from a client device a message including a request for validating a signature relating to data (to be signed) accompanied with a cryptogram and data relating to the data to be signed. The signature validation request message may include the reference to the data to be signed.
The first server 18 may verify whether the data relating to the data to be signed is or is not valid, i.e. received data has a predetermined length value or any other predetermined data format, and authorize continuing a data processing only if the data relating to the data to be signed is valid.
Alternately or additionally, the first server 18 may verify whether the data to be signed is or is not valid by using preferably a reference to the data to be signed to be sent to and received from a client device, i.e. e.g. a signature validation request message has been received before an expiring date and/or time, and authorize continuing a data processing only if the data to be signed is valid.
The second server 1 10, like e.g. a TSP, that manages a bank account relating to the phone user 1 1 , as a (bank) issuer, is hosted by a computer with data processing means and data storing means.
The second server 1 10 may generate a cryptogram to be matched by a signature to be received from the server 18.
The second server 1 10 may be used for generating a cryptogram by using the predetermined payment transaction key, the predetermined algorithm and data relating to the data to be signed and to be received through the first server 18, when applicable. The second server 1 10, as a cryptogram generation server, shares with each client device, among which there is the SE 12, notably the payment transaction key and the algorithm to be used for generating a payment transaction cryptogram. To generate the cryptogram, the second server 1 10 uses preferably a reference PIN and/or reference user authentication data, like e.g. biometric data, to decipher a previously ciphered payment transaction key by the second server 1 10 or another server.
The second server 1 10 may be used for comparing the cryptogram (that is generated by itself or another server) to a signature that is issued from the concerned client device, like e.g. the SE 12.
A result of such a comparison between the generated cryptogram and a received signature is either successful, i.e. the cryptogram matches the signature, or unsuccessful, i.e. the cryptogram is distinct from the signature.
Figure 2 is an exemplary embodiment of a way 20 to generate a non-payment transaction cryptogram, as a digital signature, both at the client side and at the server side. Optionally, data 21 to be signed may be an input to a first algorithm 22, like e.g. a hash type function allowing to reduce a length value of the data to be signed, like e.g. a length value of the resulting data hash value is 32 digits, as data relating to the data to be signed.
The hash type function may be e.g. a SHA-256 or a MD 5 type function or the like.
A hash relating to the data to be signed, as the result or output 23 of the first algorithm, or the data to be signed itself, as data relating to the data to be signed is an input 23 to a payment transaction algorithm and a non-payment transaction algorithm, as a second algorithm 24 and a signature algorithm.
Alternately or additionally, the data relating to the data to be signed fills in one or several data fields, like e.g. card data and/or terminal data, which are used by the payment transaction algorithm 24, like e.g. a 3 DES, as a non-payment transaction algorithm and a data signature algorithm 24.
A payment transaction key 25 is preferably an input to a third algorithm 26, like e.g. a XOR type function, as a ciphering function by using a (user) PIN 27 and/or other user authentication data.
A session key, as the result or output 28 of the third algorithm 26, is an input 28 to the second algorithm 24.
A result or output 210 of the second algorithm 24 is a non-payment transaction cryptogram, as a data signature.
Figure 3 depicts an exemplary embodiment of a message flow 30 that involves the SE 12, the phone 14, the first server 18 and the second server 1 10.
In the explained example, it is assumed that the client device is the SE 12.
It is further assumed that, besides a possible data validation, the first server 18 relays information between the client device and the second server 1 10 that is dedicated to a cryptogram generation and comparison.
It is assumed that the phone 14 is currently under a coverage of the network 16 and a data signature process is triggered by the first server 18.
However, the invention is still applicable if the data signature process is triggered by the phone user 1 1 , the SE 12 or any other device connected to the SE 12.
The first server 18 sends to the SE 12, as a client device, a message 31 including a request for signing a document, as data to be signed, the document and preferably an identifier relating to the document. Optionally, the SE 12 sends to the phone 14 a message 32, such as e.g. a proactive command "Display TEXT" along with the document to be displayed to the user 1 1 and preferably a message for requesting a phone user approval or disapproval, such as "do you approve to sign the displayed document?", for signing the document. The phone 14 then sends to the display screen 142 (or another connected display screen) a message 33 including the document (to be signed) and the user approval request message. The phone user 1 1 gives (or not) her/his approval for signing the document by using the phone MMI, like e.g. by depressing a button(s) "Yes" or "No". To give her/his approval, the user 1 1 may enter, through the phone MMI or the like, a PIN, as user authentication data. The user 1 1 sends, via the phone MMI, to the phone 14 a message 34 including a user approval request response. The phone 14 then sends to the SE 12 a message 36 including the user approval request response.
The SE 12 analyses and interprets the received message 36 and, if the user 1 1 gives her/his approval possibly by entering user authentication data, then the SE 12 generates 38 a first cryptogram by using a predetermined payment transaction key, a predetermined algorithm 24 (as explained in relation with figure 2) and a hash value relating to the document, as data relating to the data to be signed. Otherwise, i.e. if the user 1 1 does not give her/his approval, the SE 12 does not authorize generating 38 any cryptogram and the data signature process is terminated. Alternately, instead of a document hash value, the document data (itself) is used for generating the first cryptogram.
Then, the SE 12 sends, without going through any payment transaction channel, i.e. directly through the network 16, to the first server 18 a message 39 including a request for validating a signature relating to the document accompanied with the first cryptogram, the hash value relating to the document or the document (itself), as the data relating to the data to be signed, and possibly the document identifier (when received from the first server 18 or another entity).
The first server 18 then sends, after a possible successful verification(s) of the document validity and/or a document hash value validity (not represented) by getting the document based on the document identifier, to the second server 1 10 a message 310 including a request for authorizing a payment transaction accompanied with the first cryptogram and the data relating to the data to be signed. The data relating to the data to be signed, i.e. the hash value relating to the document or the document data, may be included within one or several data fields that are used for transmitting data relating to card data and/or data relating to terminal data in a corresponding payment transaction authorization request message.
As soon as the second server 1 10 has received the last message 310, the second server 1 10 generates 312 a second cryptogram by using a predetermined payment transaction key, a predetermined algorithm 24 (as explained in relation with figure 2) and the data relating to the data to be signed, namely the hash value relating to the document or the document data.
Once the second cryptogram is generated, the second server 1 10 compares 314 the second cryptogram to the first cryptogram, as a payment transaction signature.
If the second cryptogram does not match the first cryptogram, then the second server 1 10 sends to the first server 18 a message 316 including a payment transaction refusal, as a request 310 response. The first server 18 analyses and interprets the last message 316. The first server 18 does not validate 318 a resulting digital (and nonpayment transaction) signature.
Otherwise, i.e. if the second cryptogram matches the first cryptogram, the second server 1 10 sends to the first server 18 a message 320 including a payment transaction authorization, as a request 310 response. The first server 18 analyses and interprets the last message 320. The first server 18 validates 322 a resulting digital (and nonpayment transaction) signature.
The digital signature is thus validated by one and the same payment transaction key and one and the same payment transaction algorithm at the client and server sides.
The invention solution is compatible notably with the existing CBP type infrastructure.
Such an invention data signature method allows re-using an existing CBP type infrastructure reducing thus a technical complexity and corresponding costs to offer a data signature service.
The invention solution does not need to involve a phone user, except for submitting user authentication data, when applicable.
The embodiment that has just been described is not intended to limit the scope of the concerned invention. Other embodiments may be given. As another embodiment example, instead of two servers 18 and 1 10 that are involved, only one server allows validating (or not) a signature issued by a client device.

Claims

1 . A method (30) for signing data,
wherein the method comprises the following steps:
- a device (12) generates (38) a first cryptogram by using a predetermined payment transaction key, a predetermined algorithm and data relating to data to be signed, as an input to the algorithm, the data to be signed being different from payment transaction data;
- the device sends, without going through any payment transaction channel, to a first server (18) a first message (39) including a request for validating a signature relating to the data to be signed accompanied with the first cryptogram and the data relating to the data to be signed;
- the first or a second server generates (312) a second cryptogram by using the predetermined payment transaction key, the predetermined algorithm and the data relating to the data to be signed, as an input to the algorithm;
- the first or the second server compares (314) the second cryptogram to the first cryptogram;
- if the second cryptogram does or does not match the first cryptogram, then the first or the second server does (322) or does not (318) validate a signature relating to the data to be signed respectively.
2. Method according to claim 1 , wherein, prior to generating a first cryptogram, the device requests (33) from a device user an approval or a disapproval for signing data to be signed accompanied with the data to be signed and, only if the device user approves a signature of the data to be signed, the device generates the first cryptogram.
3. Method according to claim 1 , wherein, prior to generating a first cryptogram, the device requests (33) from a device user an approval or a disapproval for signing data to be signed accompanied with the data to be signed and the device user approves a signature of the data to be signed by entering user authentication data (34), the user authentication data being used to generate the first cryptogram, reference user authentication data being used to generate the second cryptogram.
4. Method according to claim 3, wherein the user authentication data is used to decipher a ciphered payment transaction key at the device side and the reference authentication data is used to decipher a ciphered payment transaction key at the server side.
5. Method according to any of claims 1 to 4, wherein the data relating to the data to be signed includes a hash relating to the data to be signed or the data to be signed.
6. Method according to any of claims 1 to 5, wherein the data relating to the data to be signed is included within at least one data field that is used for transmitting at least one element of the following group:
- data relating to card data;
- data relating to terminal data.
7. Method according to any of claims 1 to 6, wherein, prior to generating a second cryptogram, the method further includes:
- the first server verifies whether the data to be signed is or is not valid, the first server authorizes continuing a data processing only if the data to be signed is valid; and/or
- the first server verifies whether the data relating to the data to be signed is or is not valid, the first server authorizes continuing a data processing only if the data relating to the data to be signed is valid.
8. Method according to any of claims 1 to 7, wherein, prior to generating a first cryptogram, the first server or another entity sends to the device at least the data to be signed.
9. A device (12) for signing data,
wherein the device is configured to:
- generate (38) a first cryptogram by using a predetermined payment transaction key, a predetermined algorithm and data relating to data to be signed, as an input to the algorithm, the data to be signed being different from payment transaction data;
- send, without going through any payment transaction channel, to a first server (18) a first message (39) including a request for validating a signature relating to the data to be signed accompanied with the first cryptogram and the data relating to the data to be signed.
10. A first server (18) for signing data,
wherein the first server is configured to:
- receive, without going through any payment transaction channel, a first message (39) including a request for validating a signature relating to data to be signed accompanied with a first cryptogram and data relating to data to be signed;
- generate (312) or let generate a second cryptogram by using a predetermined payment transaction key, a predetermined algorithm and the data relating to the data to be signed, as an input to the algorithm;
- compare (314) or let compare the second cryptogram to the first cryptogram;
- validate (322) or not (318) a signature relating to the data to be signed if the second cryptogram does or does not match the first cryptogram respectively.
PCT/EP2016/060429 2015-05-11 2016-05-10 Method, device and server for signing document using a banking transaction key Ceased WO2016180821A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14/708,855 2015-05-11
US14/708,855 US20160335627A1 (en) 2015-05-11 2015-05-11 Method, device and a server for signing data

Publications (1)

Publication Number Publication Date
WO2016180821A1 true WO2016180821A1 (en) 2016-11-17

Family

ID=55963361

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2016/060429 Ceased WO2016180821A1 (en) 2015-05-11 2016-05-10 Method, device and server for signing document using a banking transaction key

Country Status (2)

Country Link
US (1) US20160335627A1 (en)
WO (1) WO2016180821A1 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN107256387A (en) * 2017-05-23 2017-10-17 崔俊新 Fingerprint verification method, system and computer-readable recording medium
CN108322907A (en) * 2017-01-17 2018-07-24 中国移动通信有限公司研究院 One kind opening chucking method and terminal
WO2022159345A1 (en) * 2021-01-19 2022-07-28 Visa International Service Association Mobile user authentication system and method

Families Citing this family (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10437829B2 (en) * 2016-05-09 2019-10-08 Level 3 Communications, Llc Monitoring network traffic to determine similar content
CN107274183B (en) * 2017-03-21 2020-05-22 中国银联股份有限公司 Transaction verification method and system
US11651358B2 (en) * 2017-07-25 2023-05-16 Mastercard International Incorporated Method and system for transaction processing with complete cryptographic auditability
KR102661263B1 (en) * 2018-01-26 2024-04-29 삼성전자 주식회사 Method for receiving merchant information and electronic device using the same
CN108320158B (en) * 2018-04-11 2024-12-13 郑鸿 A wearable payment device
CN109560933B (en) * 2018-10-12 2022-04-08 蚂蚁蓉信(成都)网络科技有限公司 Authentication method and system based on digital certificate, storage medium and electronic equipment
DE102022117558A1 (en) 2022-07-14 2024-01-25 Audi Aktiengesellschaft Method for digitally signing a digital document in a motor vehicle and motor vehicle and system

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999033222A1 (en) * 1997-12-23 1999-07-01 Arcot Systems, Inc. Method and apparatus for secure cryptographic key storage, certification and use
DE102007006658A1 (en) * 2007-02-10 2008-08-14 Walter Keller Interlinking of bank-and telecommunication networks has one or more mobile networks connected by interfaces directly or indirectly to national and international electronic clearing devices of credit economy bank-clearing-systems

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO1999033222A1 (en) * 1997-12-23 1999-07-01 Arcot Systems, Inc. Method and apparatus for secure cryptographic key storage, certification and use
DE102007006658A1 (en) * 2007-02-10 2008-08-14 Walter Keller Interlinking of bank-and telecommunication networks has one or more mobile networks connected by interfaces directly or indirectly to national and international electronic clearing devices of credit economy bank-clearing-systems

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
BOYD D J ED - JAIN P P ET AL: "Single sign-on to the web with an EMV card", COLLABORATIVE TECHNOLOGIES AND SYSTEMS, 2008. CTS 2008. INTERNATIONAL SYMPOSIUM ON, IEEE, PISCATAWAY, NJ, USA, 19 May 2008 (2008-05-19), pages 112 - 120, XP031273411, ISBN: 978-1-4244-2248-7 *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN108322907A (en) * 2017-01-17 2018-07-24 中国移动通信有限公司研究院 One kind opening chucking method and terminal
CN108322907B (en) * 2017-01-17 2021-03-09 中国移动通信有限公司研究院 Card opening method and terminal
CN107256387A (en) * 2017-05-23 2017-10-17 崔俊新 Fingerprint verification method, system and computer-readable recording medium
WO2022159345A1 (en) * 2021-01-19 2022-07-28 Visa International Service Association Mobile user authentication system and method

Also Published As

Publication number Publication date
US20160335627A1 (en) 2016-11-17

Similar Documents

Publication Publication Date Title
AU2020202106B2 (en) Method, device, server and system for authenticating a user
US20160335627A1 (en) Method, device and a server for signing data
EP3210359B1 (en) Method for accessing a service, corresponding first device, second device and system
US20170032369A1 (en) Method, device and first server for authorizing a transaction
US20180018665A1 (en) Method and device for accessing a service
EP3113098A1 (en) Method, device and back-end system for authorizing a transaction
KR20100136329A (en) Method and system for payment of mobile phone through multi-authentication network type OTP authentication generated through index exchange and recording medium therefor
EP2592589A1 (en) Method and sytem for providing temporary banking card data
KR101625219B1 (en) Method for Providing Network type OTP of Multiple Code Creation Mode by using Users Medium
KR20170088797A (en) Method for Operating Seed Combination Mode OTP by using Biometrics
KR101875791B1 (en) Method for Certificating Medium based on Biometrics
KR20160121791A (en) Method for Providing Network type OTP by Seed Combination Mode
KR101663697B1 (en) A method of providing otopy using user medium
KR101669245B1 (en) Method for Providing Service by using Installed Program at Handheld Phone
KR20150090005A (en) Method for Providing Network type OTP by using Biometrics
KR101645555B1 (en) A Method for Providing a Network-based Opti with Dual Code Generation Method Using User Medium
EP3067848A1 (en) Method and first and second server for transferring voucher data
KR20170058346A (en) Method for Authenticating Payment by Code Combination
KR20160113524A (en) Method for Authenticating Payment by Code Combination
KR20170088320A (en) Method for Operating Multiple Code Creation Mode OTP by using Contactless Medium
KR20160121792A (en) Method for Operating Multiple Code Creation Mode OTP by using Contactless Medium
KR20160004249A (en) Method for Operating Multiple Code Creation Mode OTP by using Contactless Medium
KR20180043781A (en) Method for Providing Service based on Medium Authentication
KR20150141178A (en) Method for Authenticating Payment by Code Combination
KR20170088796A (en) Method for Providing Network type OTP of Multiple Code Creation Mode by using Biometrics

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

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

Country of ref document: EP

Kind code of ref document: A1