WO2014104436A1 - 결제 디바이스에 대한 상호인증 방법 - Google Patents

결제 디바이스에 대한 상호인증 방법 Download PDF

Info

Publication number
WO2014104436A1
WO2014104436A1 PCT/KR2012/011692 KR2012011692W WO2014104436A1 WO 2014104436 A1 WO2014104436 A1 WO 2014104436A1 KR 2012011692 W KR2012011692 W KR 2012011692W WO 2014104436 A1 WO2014104436 A1 WO 2014104436A1
Authority
WO
WIPO (PCT)
Prior art keywords
payment
value
payment device
hash value
payment terminal
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/KR2012/011692
Other languages
English (en)
French (fr)
Inventor
박해철
이정진
김병수
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.)
Hyundai Card Co Ltd
KB Kookmin Card Co Ltd
Shinhan Card Co Ltd
Original Assignee
Hyundai Card Co Ltd
KB Kookmin Card Co Ltd
Shinhan Card Co Ltd
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 Hyundai Card Co Ltd, KB Kookmin Card Co Ltd, Shinhan Card Co Ltd filed Critical Hyundai Card Co Ltd
Priority to CN201280078132.5A priority Critical patent/CN105009154A/zh
Priority to US14/758,459 priority patent/US20150332261A1/en
Priority to EP12890943.9A priority patent/EP2940642A4/en
Priority to JP2015551041A priority patent/JP2016503992A/ja
Publication of WO2014104436A1 publication Critical patent/WO2014104436A1/ko
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

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/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/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/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
    • 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/3823—Payment protocols; Details thereof insuring higher security of transaction combining multiple encryption tools for a transaction
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/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
    • 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
    • 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
    • G06Q20/4015—Transaction verification using location information
    • 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/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • 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/409—Device specific authentication in transaction processing
    • G06Q20/4097—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners
    • G06Q20/40975—Device specific authentication in transaction processing using mutual authentication between devices and transaction partners using encryption therefor
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F7/00—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus
    • G07F7/08—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means
    • G07F7/0866—Mechanisms actuated by objects other than coins to free or to actuate vending, hiring, coin or paper currency dispensing or refunding apparatus by coded identity card or credit card or other personal identification means by active credit-cards adapted therefor
    • 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/0869—Network architectures or network communication protocols for network security for authentication of entities for achieving mutual authentication
    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography

Definitions

  • the present invention relates to a mutual authentication method for a payment device, and more particularly, to a mutual authentication method for a payment device in which the payment device and a payment terminal located in a short distance identify and authenticate a correct payment device.
  • USB Universal Subscriber Identity Module
  • the three major card companies including the Visa card, Master card and Euro pay, define the EMV (Euro / Master / Visa) standard. Therefore, a credit card is issued. Credit card according to the EMV standard cannot be tampered with, and the buyer who purchases the product or service for the credit card payment enters the payment password into the payment terminal and pays the fee. It is said that the security has been greatly improved.
  • Korean Patent Laid-Open Publication No. 10-2007-0093530 proposes a fast contactless payment processing method for inducing payment according to the EMV standard even in a vehicle moving at a high speed using a contactless EMV credit card according to the EMV standard. There is a bar.
  • Korean Patent Laid-Open Publication No. 10-2007-0093530 discloses an EMV type IC card provided in a vehicle and an EMV terminal device provided in a toll gate for processing data in the order of get processing option-read record-generate AC according to a general EMV standard. have.
  • the IC card may output version information, carrier information and AFL data to the EMV terminal device.
  • the AFL data output to the EMV terminal device includes location information in which track 2 information according to the ISO 7813 standard is stored in the EMV card, and when the location information is exposed to the outside, another person may use it to hack the EMV card. Be careful as it may. Description of the AFL data will be described with reference to FIG. 1.
  • 1 is a reference diagram for a transaction processing process between an EMV card and an EMV terminal.
  • the EMV credit card 10 when the EMV credit card 10 approaches or contacts a legitimate EMV credit terminal 20 within a short distance (for example, several centimeters to several tens of centimeters), the EMV credit card 10 includes an IC chip ( The card information provided in 11) may be wirelessly transmitted to the EMV payment terminal 20.
  • the EMV payment terminal 20 transmits a get processing option command for initializing a transaction to the EMV credit card 10.
  • the EMV credit card 10 transmits application version information, mobile carrier information, and AFL (Application File aLlocation) information to the EMV payment terminal 20, wherein the ALF information includes card information. It indicates the address information of the memory and the address information of the memory block.
  • the EMV payment terminal 20 reads track 2 information from the EMV credit card 10 with reference to the AFL information, and sends the track 2 information to a VAN server (not shown) or a credit card company server (not shown) using the read track 2 information. To proceed with the credit settlement.
  • the EMV credit card 10 and the EMV payment terminal 20 performs RF (Radio Frequency) communication
  • the EMV credit card 10 and the non-regular payment terminal 30 located in the RF field have an EMV credit card ( 10, the non-regular payment terminal 30 may acquire track 2 information including application version information, mobile carrier information, and the like through the EMV credit card 10.
  • the irregular payment terminal 30 may acquire card information from the EMV credit card 10 without permission of the card holder, and the acquired card information may be abused.
  • the present applicant can determine whether the EMV credit card 10 and the EMV payment terminal 20 are mutually legitimate transaction targets, and provide a payment device that can exchange card information between the legitimate transaction targets 10 and 20.
  • An object of the present invention is to allow the credit card and the payment terminal to determine whether a mutually legitimate transaction target, so that the payment terminal and the credit card that is a legitimate transaction can exchange card information, thereby hacking by an irregular payment terminal And a mutual authentication method for a payment device that reduces a security threat to information leakage.
  • the above object is performed by a payment terminal for processing a payment of a payment device, generating a first random value and generating a first hash value for the random value, and the payment of the random value. And providing a device, and authenticating the payment device by comparing the second hash value returned from the payment device and the first hash value, wherein the payment terminal comprises: a first hash value and the second hash value; When the match is matched, the payment device is authenticated, and when the payment device is requested to generate the second hash value for the random value, the payment device recognizes the payment terminal as a regular payment terminal and provides the card information to the payment device. It is achieved by mutual authentication method.
  • the above object is performed by a payment terminal processing a payment of a payment device, according to the present invention, generating a first random value and generating a first hash value for the random value, wherein the first random value is generated.
  • Authenticating the payment device by comparing the first hash value with a second hash value returned by the payment device and provided to the payment device, and a second hash value for a second random value provided by the payment device. Is provided by the payment device to be authenticated by the payment device.
  • the present invention when the credit card does not face the correct payment terminal, it is possible to hide the location information where the track 2 information is stored in the credit card, thereby improving the security of the credit card.
  • FIG. 1 illustrates a reference diagram for a process of transmitting an AFL between an EMV card and an EMV terminal.
  • FIGS. 2 and 3 show a conceptual diagram of a mutual authentication method for a payment device according to the present invention.
  • FIG. 4 shows a flowchart of a mutual authentication method for a payment device according to an embodiment of the present invention.
  • FIG. 5 shows a flowchart of a mutual authentication method for a payment device according to another embodiment of the present invention.
  • Figure 6 shows an example of a block diagram of a payment terminal used to carry out the present invention.
  • FIG. 7 illustrates a reference diagram for an example of generating a hash value using a hash algorithm.
  • Track 2 information referred to herein may mean card information according to the ISO 7813 standard.
  • the payment device referred to herein may be a mobile terminal containing an electronic credit card or Universal Subscriber Identity Module (USIM) chip containing track 2 information.
  • USIM Universal Subscriber Identity Module
  • a mobile terminal is described and described with reference to a smart phone and a mobile phone.
  • a device that can be carried in addition to the smartphone and the mobile phone mentioned above and which can replace a credit card with a built-in USIM chip can be referred to as a portable terminal even if not mentioned otherwise.
  • the payment terminal referred to in this specification may mean a device capable of processing transactions by acquiring card information (for example, track 2 information) from an electronic credit card having an integrated circuit (IC) and a portable terminal having a USIM chip.
  • the payment terminal may be capable of transaction processing only with any one of the electronic credit card and the portable terminal, or may be capable of transaction processing with both. It is not limited.
  • EMV which is referred to herein, is an acronym for Euro / Master / Visa, which uses an encrypted IC chip and prevents forgery of the card by requiring a PIN (Personal Identification Number) to be entered through a payment terminal during a credit card transaction.
  • PIN Personal Identification Number
  • the track 2 information referred to herein includes a primary account number (PAN) area, an expiration data (ED) area, a service code (SC) area, and a discrete data (DD) area, and the PAN area is a variable type developed by the present applicant. It may be a PAN.
  • PAN primary account number
  • ED expiration data
  • SC service code
  • DD discrete data
  • the PAN area is a variable type developed by the present applicant. It may be a PAN.
  • a BIN Bank Information Number
  • the card account information excluding the BIN is encrypted so that the card account information is not exposed during a credit card transaction.
  • the hash value referred to herein may mean a hash value generated by a hash algorithm such as Secure Hash Algorithm-1 (SHA-1), SHA-2, or Message-Digest Algorithm 5 (MD-5). Hash algorithms can be used in addition to this.
  • SHA-1 Secure Hash Algorithm-1
  • MD-5 Message-Digest Algorithm 5
  • the payment terminal mentioned in the present specification may perform data communication with a credit card according to the EMV standard. However, the payment terminal mentioned in the present specification maintains data communication when faced with a payment device such as a valid credit card or a portable terminal, and may not maintain data communication when faced with an abnormal payment device. That is, the credit transaction may be interrupted.
  • FIGS. 2 and 3 show a conceptual diagram of a mutual authentication method for a payment device according to the present invention.
  • the payment terminal 100 when the payment device 50 approaches or contacts the payment terminal 100, the payment terminal 100 is located at a short distance (several centimeters to tens of centimeters). 50, the payment device 50 requests the application list, and the payment device 50 transmits the application list to the payment terminal 100.
  • the list of application programs sent from the payment device 50 to the payment terminal 100 may have a single file type, and in an EMV standard credit card, a file such as 1PAY.SYSDDF01 may be transferred from the payment device 50 to the payment terminal ( 100).
  • the application program may mean a payment program used for payment when the payment is made by the payment device 50.
  • the payment terminal 100 drives the payment device 50 with reference to an application program that can be driven by the payment device 50.
  • the payment terminal 100 should select one of a plurality of credit cards (or a plurality of portable terminals), and the command generated by the payment terminal 100 corresponds to a card select command. do.
  • the payment terminal 100 executes a mutual authentication command for verifying the credit card, instead of performing a get processing option command that should proceed after the card select command. To perform.
  • Mutual authentication command is a command for generating an authentication value while the payment device 50 and the payment terminal exchange data with each other, and to determine whether it is a correct transaction target using the generated authentication value, which exists in the EMV standard. I never do that.
  • the payment terminal 100 generates a random value.
  • the random value generated at this time is a random value.
  • the payment device 100 may be any one of random values randomly generated.
  • the payment terminal 100 may generate a random value by using an arbitrary time after the moment when the payment device 50 faces the payment terminal 100.
  • the payment terminal 100 uses a random value as an input value, and generates a hash value by driving a hash algorithm using an encryption key provided in advance.
  • the payment terminal 100 transmits the random value input to the hash algorithm to the payment device 50.
  • the payment device 50 drives a hash algorithm by inputting a random value transmitted from the payment terminal 100, and at this time, by using an encryption key that is embedded therein, for the random value provided by the payment terminal 100. A hash value is generated and the generated hash value is returned to the payment terminal 100.
  • the payment terminal 100 compares the hash value returned by the payment device 50 with the hash value generated in step 2) and determines whether the payment terminal 100 is the same.
  • the payment terminal 100 recognizes as a valid payment device 50 and performs the next command (get processing option command). If so, terminate the credit transaction process without performing the next command (get processing option command).
  • the non-standard payment terminal 30 transmits a get processing command to the payment device 50, payment device 50 Can wait for mutual authentication.
  • the payment device 50 determines that it is not a legitimate transaction target and does not provide track 2 information to the irregular payment terminal 30.
  • the payment terminal 100 initializes an application program of the payment device 50 by performing a get processing option command after a card select command.
  • the encryption key does not mean a separate key for driving the hash algorithm.
  • the encryption key is a fixed value provided on both sides of the payment device 50 and the payment terminal 100, and when the hash algorithm is driven, the encryption key serves as an encryption key by automatically placing it before and after the random value. Is not.
  • the hash algorithm may obtain a hash value by inputting a header, a tailer, and a random value.
  • Header value is "11111111111111111111111111111111111111"
  • Hash algorithm header Random value
  • Taylor) as an input value in the order shown in FIG. 7 in the payment device 50 is a first hash value
  • the first hash value generated in the payment device 50 and the second hash value generated in the payment terminal 100 should have the same value.
  • the payment device 50 and the payment terminal 100 generate a hash value by using the header value and the Taylor value as an encryption key, and the header value in the data transmitted and received between the payment device 50 and the payment terminal 100.
  • the over-taylor value is not exposed, making it difficult for others to recognize it.
  • the header value and the Taylor value are added to the front and the rear of the random value, and are not recognized as encryption keys, so that the first hash value or the second hash value according to the hash algorithm may not be easily inferred by others.
  • the payment terminal 100 moves the payment device 50 located at a short distance (several centimeters to several tens of centimeters).
  • the application device list is requested to the payment device 50, and the IC chip 51 embedded in the payment device 50 is driven by referring to the application program list.
  • the process of selecting one credit card is the same as the description of FIG. 2.
  • the embodiment of FIG. 3 differs from the embodiment of FIG. 2 in that a mutual authentication command is performed after the get processing option command is executed in the payment terminal 100.
  • the payment terminal 100 After the get processing option command is executed, when the payment terminal 100 performs a read record command, the payment device 50 responds to the track 2 information according to the ISO / IEC 7813 standard in response to the payment terminal 100. Will be sent to. Accordingly, before the track 2 information is transmitted from the payment device 50 to the payment terminal 100, the payment terminal 100 first performs a mutual authentication command, thereby making the payment device 50 correct. You can determine if you are doing a credit transaction.
  • the mutual authentication method of FIG. 3 when there is a non-standard payment terminal, for example, a portable payment non-standard payment terminal 30 in the communication coverage, the non-standard payment terminal 30 transmits a get processing command to the payment device 50.
  • the payment device 50 may wait for mutual authentication.
  • the payment device 50 determines that it is not a legitimate transaction target and does not provide card information (eg, track 2 information) to the irregular payment terminal 30. Do not.
  • the mutual authentication method of FIG. 3 performs the same processes of 1) to 6) mentioned in the embodiment of FIG. 2 and performs the same hash value matching according to FIG. 6.
  • the process of 6) described through FIG. 2 may be replaced with the process of 6-1) below.
  • the payment terminal 100 recognizes the payment device 50 as a valid transaction for credit and performs the next command (lead record command). Otherwise, the credit transaction process is terminated without executing the next command (lead record command).
  • the payment terminal 100 executes an application when a PIN (Personal Identification Number) is input from a payment amount and a credit card holder. Perform a command (generate AC).
  • the application execution command is transmitted to the payment device 50, and the payment device 50 returns an encrypted authorization request data (ARQC) to the payment terminal 100 in response to the application execution command.
  • PIN Personal Identification Number
  • ARQC encrypted authorization request data
  • the payment terminal 100 After receiving the encrypted authorization request data (ARQC), the payment terminal 100 generates payment authorization request data including payment information including card information, payment terminal information, and merchant code, and a VAN server (not shown). Through the card company server (not shown) can be sent to query the validity of the credit card. Accordingly, the payment terminal 100 proceeds with the payment approval process according to the EMV standard, and only the legitimate payment device 50 and the payment terminal 100 may proceed with the payment using a mutual approval process that does not exist in the EMV standard. It is.
  • the location of the storage area including the track 2 information and the card information from the payment device 50 to the payment terminal 100 only when the payment device 50 and the payment terminal 100 face each other in close proximity for a credit transaction. Since the information is provided, hacking attempts by outsiders can be blocked in advance.
  • FIG. 4 shows a flowchart of a mutual authentication method for a payment device according to an embodiment of the present invention.
  • the payment terminal 100 when the payment device 50 is close to the payment terminal 100 at a short distance (a few centimeters to several tens of centimeters), the payment terminal 100 When the payment device 50 is recognized and two or more credit cards exist in the communication coverage through a card select command, one credit card may be selected to proceed with the payment process.
  • the payment device 50 may be located within the communication coverage of two or more payment terminals 30 and 100.
  • the payment device 50 that performs communication by using the RF communication may include the irregular payment terminal 30 and the payment terminal ( 100) It may be determined whether the mutual authentication command is transmitted to both sides. Track 2 information is provided only to the payment terminal 100 transmitting the mutual authentication command, and card information transmission can be blocked for the non-regular payment terminal 30 not transmitting the mutual authentication command.
  • the payment terminal 100 may generate a random value and generate a hash value using a hash algorithm with respect to the generated random value.
  • the generated hash value may be temporarily stored by the payment terminal 100, and the generated random value may be transmitted to the payment device 50 to request a hash value for the random value.
  • the payment device 50 and the payment terminal 100 may have the same encryption key, and the same hash value may be calculated by using the hash algorithm by applying the same encryption key by inputting the same random value.
  • the payment device 50 generates a hash value by driving a hash algorithm by inputting a random value provided from the payment terminal 100, and returns the generated hash value to the payment terminal 100.
  • the payment terminal 100 compares the hash value returned from the payment device 50 with the temporarily stored hash value. In the state before the get processing option command is executed, the payment terminal 100 obtains only the application list, the mobile carrier information and the version information of the application from the payment device 50, so that the card information of the payment device 50 is completely intact. It is not acquired.
  • the payment terminal 100 performs mutual authentication with the payment device 50 before acquiring the location information where the track 2 information is located in the IC chip 51 of the payment device 50. It is characteristic that the irregular payment terminal cannot acquire the location information of the track 2 information in the payment device 50.
  • the location information of the track 2 information is not exposed to the payment terminal 100 in the payment device 50. You can do that.
  • FIG. 5 shows a flowchart of a mutual authentication method for a payment device according to another embodiment of the present invention.
  • the payment terminal 100 when the payment device 50 approaches the payment terminal 100 at a short distance (a few centimeters to several tens of centimeters), the payment terminal ( If 100 recognizes the payment device 50 and two or more payment devices exist within the communication coverage through a card select command, one payment device may be selected to proceed with the payment process.
  • the payment device 50 may be located within the communication coverage of two or more payment terminals 30 and 100.
  • the payment device 50 that performs communication by using the RF communication may include the irregular payment terminal 30 and the payment terminal ( 100) It may be determined whether the mutual authentication command is transmitted to both sides.
  • the payment device 50 may provide track 2 information only to the payment terminal 100 that transmits the mutual authentication command, and may block card information transmission for the non-regular payment terminal 30 that does not transmit the mutual authentication command. have.
  • the payment terminal 100 may generate and transmit a random value to the payment device 50, and obtain an encryption value that is encrypted and returned by the payment device 50 with respect to the first random value.
  • the payment terminal 100 generates an encryption value in advance with the first random value provided to the payment device, and compares the encryption value returned from the payment device 50 with the encryption value generated by the payment device 50, and if it is the same, the payment device ( 50) can be authenticated.
  • the payment device 50 and the payment terminal 100 may generate an encryption value by the same hash algorithm.
  • the payment terminal 100 generates a second random value, and generates a hash value for the generated second random value by using a hash algorithm.
  • the generated hash value may be temporarily stored by the payment terminal 100, and the generated random value may be transmitted to the payment device 50 to request a hash value for the random value.
  • the payment device 50 and the payment terminal 100 may have the same encryption key, and the same hash value may be calculated by using the hash algorithm by applying the same encryption key by inputting the same random value.
  • the payment device 50 generates a hash value by driving a hash algorithm by inputting a random value provided from the payment terminal 100, and returns the generated hash value to the payment terminal 100.
  • the payment terminal 100 compares the hash value returned from the payment device 50 with the temporarily stored hash value. In the state before the get processing option command is executed, the payment terminal 100 obtains only the application list, the mobile carrier information and the version information of the application from the payment device 50, so that the payment device 50 You have not fully acquired your card information.
  • the payment device 50 generates a random random value (hereinafter referred to as a second random value), and generates a first hash value by driving a hash algorithm that takes the generated second random value as an input.
  • a second random value a random random value
  • the payment device 50 may provide the second random value to the payment terminal 100 and receive a second hash value using the same hash algorithm from the payment terminal 100. If the payment terminal 100 is a regular payment terminal 100, the payment device 50 is the same as the first hash value generated by the second hash value obtained from the payment terminal 100, through this payment terminal It can be confirmed that 100 is a regular payment terminal.
  • the payment device 50 may receive a get processing option command or a read record command from the payment terminal 100, and may provide card information to the payment terminal 100 when the corresponding command is received.
  • the card information is leaked by the payment device 30 because the card information is provided from the payment device 50 to the payment terminal 100. This has the advantage of being blocked.
  • Figure 6 shows an example of a block diagram of a payment terminal used to carry out the present invention.
  • the payment terminal 100 may include a processor 121, a sign pad 122, a reader unit 123, a communication unit 124, a printing unit 125, a memory 126, and an input unit 127. It can be configured to include.
  • the processor 121 controls the payment terminal 100 as a whole, receives a transaction processing request of the payment device 50 such as a magnetic credit card, an electronic credit card, and a mobile terminal through the reader unit 123, and receives an input unit.
  • the amount information input to 127 and the image of the sign obtained from the sign pad 122 are collected to generate payment information, and the payment information generated through the communication unit 124 is stored in the VAN server 150 or the card company server 100. ) To process transactions.
  • the processor 121 may incorporate a real time clock (RTC) or be connected to the RTC to count the current time.
  • RTC real time clock
  • the processor 121 may have a built-in co-processor or may be connected to a separate co-processor and may drive a program that drives a hash algorithm in conjunction with the co-processor. have.
  • a program for driving the hash algorithm may be provided in the memory 126.
  • the memory 126 may include a volatile memory 126a or a nonvolatile memory 126b.
  • the volatile memory 126a may be configured as a DRAM or an SRAM, and when the processor 121 drives a program for controlling or driving the units 122 to 127, it may be used as a temporary storage space for driving the program. .
  • the nonvolatile memory 126b may include a program for driving a hash algorithm in the processor 121 and an operating system for the payment terminal 100.
  • the printing device 25 prints the payment details of the payment device 50 and outputs a receipt.
  • the communication unit 124 uses a wired or wireless communication to communicate with a VAN server or a card company. Network connection with server.
  • the reader unit 123 may obtain track 2 data from the payment device 50 in contact with or in a non-contact proximity manner.
  • the reader unit 123 contacts the magnetic strip to read the track 2 data and reads track 2 data, and performs the NFC (Near Field Communication) with the mobile terminal and the USIM information and credit card embedded in the mobile terminal.
  • NFC reader unit 123b for acquiring information
  • a contactless IC reader unit 123c for acquiring track 2 data from the electronic credit card by performing data communication with the electronic credit card.
  • the reader unit 123 may include only one of the MS reader unit 123a, the NFC reader unit 123b, and the non-contact IC reader unit 123c, or two or three of them.
  • the present invention allows a payment device to make a payment through a legitimate payment terminal, and a payment terminal to proceed with payment through mutual authentication, and to provide a credit card payment environment and a mobile payment environment of a financial industry such as a credit card company and a bank. Can contribute to activation.

Landscapes

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

Abstract

본 발명은 신용카드가 올바른 결제 단말기와 대면하지 않는 상태에서는 신용카드에서 트랙 2 정보가 저장되는 위치정보를 숨기도록 하며, 이를 통해 신용카드의 보안성을 향상시키는 결제 디바이스에 대한 상호인증 방법을 제안한다. 이를 위해 본 발명은, 결제 디바이스의 결제를 처리하는 결제 단말기에 의해 수행되며, 제1랜덤 값을 생성하고 랜덤 값에 대한 제1 해쉬 값을 생성하는 단계, 랜덤 값을 결제 디바이스로 제공하고, 결제 디바이스에서 리턴하는 제2 해쉬 값과 상기 제1 해쉬 값을 비교하여 결제 디바이스를 인증하는 단계를 포함하며, 결제 단말기는, 제1 해쉬 값과 제2 해쉬 값이 일치할 때, 결제 디바이스를 인증하고, 결제 디바이스는, 랜덤 값에 대한 제2 해쉬 값 생성을 요청받는 경우 결제 단말기를 정규 결제 단말기로 인식하여 카드 정보를 제공할 수 있다.

Description

결제 디바이스에 대한 상호인증 방법
본 발명은 결제 디바이스에 대한 상호인증 방법에 관한 것으로, 더욱 상세하게는, 결제 디바이스와 근거리에 위치하는 결제 단말기가 올바른 결제 디바이스를 확인 및 인증하는 결제 디바이스에 대한 상호인증 방법에 관한 것이다.
신용카드는 현재까지 전 세계적으로 가장 널리 이용되는 지불 수단중 하나로서, 자기 스트립(Magnetic Strip)을 구비하는 자기식 신용카드, 인증을 위한 칩을 내장하는 전자 신용카드를 거쳐 휴대폰이나 스마트폰에 내장되는 USIM(Universal Subscriber Identity Module)의 형태로 신용카드가 구현되고 있다.
신용카드가 현금을 대체하는 지불 수단으로 이용되면서 신용카드에 대한 위조, 변조는 물론 각종 사기 거래가 증가하는 추세에 있다.
신용카드 위조에 의한 범죄는 아시아의 경우 전체 신용카드 거래에서 발생하는 범죄 대비 7.1%(1988년)에서 32.4%(1994년)로 급증하는 추세에 있으며, 위조에 의한 범죄는 날이 갈수록 증가하는 추세에 있다.
신용카드 위조에 따른 문제점에 대해 비자 카드(Visa card), 마스터 카드(Master card) 및 유로페이(Euro pay) 등 3대 메이저 카드사는 EMV(Euro/ Master/ Visa) 규격을 규정하고, EMV 규정에 따라 신용카드를 발급하고 있다. EMV 규격에 따른 신용카드는 위 변조가 불가하며, 신용카드 결제를 위해 상품 또는 용역을 구매하는 구매자가 결제 비밀번호를 결제 단말기에 입력하는 과정을 거쳐 비용을 결제하도록 함으로써, 기존의 자기식 신용카드에 비해 보안성을 대폭 향상시켰다는 평가를 듣고 있다.
이와 같은 EMV 규격은 신용카드 이외에도 여러 결제수단에 적용되고 있다. 일 예로서, 한국 공개특허 10-2007-0093530은 EMV 규격에 따른 비 접촉식의 EMV 신용카드를 이용하여 고속으로 이동하는 차량 내에서도 EMV 규격에 따른 결제를 유도하는 고속 비 접촉식 지불 처리방법을 제안한 바 있다. 한국 공개특허 10-2007-0093530은 EMV 타입으로 차량에 구비되는 IC 카드와 톨게이트에 마련되는 EMV 단말장치가 통상의 EMV 규격에 따라 get processing option - Read Record - generate AC 의 명령 순으로 데이터를 처리하고 있다.
EMV 규격에 따라 결제 단말기나 EMV 단말장치가 EMV 신용카드로 전송하는 명령어들 중 get processing option 명령어가 IC 카드로 송부되면, IC 카드에서는 버전 정보, 이동통신사 정보 및 AFL 데이터를 EMV 단말장치로 출력할 수 있다. 이때, EMV 단말장치로 출력되는 AFL 데이터에는 ISO 7813 규격에 따른 트랙 2 정보가 EMV 카드에 저장되는 위치정보를 구비하는데, 이 위치정보가 외부로 노출되는 경우, 타인이 EMV 카드를 해킹하는데 이용될 수 있으므로 주의가 요망된다. AFL 데이터에 대한 설명은 도 1을 참조하여 설명하도록 한다.
도 1은 EMV 카드와 EMV 단말기 사이의 트랜잭션 처리 과정에 대한 참조도면을 도시한다.
도 1을 참조하면, EMV 신용카드(10)가 정당한 EMV 신용결제 단말기(20)와 근거리(예컨대 수 센티미터 내지 수십 센티미터) 내에 접근하거나 접촉하는 경우, EMV 신용카드(10)는 내장되는 IC 칩(11)에 마련되는 카드 정보를 EMV 결제 단말기(20)로 무선 전송할 수 있다.
이때, EMV 결제 단말기(20)는 거래 초기화를 위한 겟 프로세싱 옵션(get processing option) 명령을 EMV 신용카드(10)로 전송한다. EMV 신용카드(10)는 겟 프로세싱 옵션 명령에 응답하여 어플리케이션의 버전 정보, 이동통신사 정보 및 AFL(Application File aLlocation) 정보를 EMV 결제 단말기(20)로 전송하는데, 이때, ALF 정보는 카드 정보가 포함되는 메모리의 주소 정보나 메모리 블록의 주소 정보를 지시하고 있다.
EMV 결제 단말기(20)는 AFL 정보를 참조하여 EMV 신용카드(10)에서 트랙 2 정보를 독출하고, 독출된 트랙 2 정보를 이용하여 VAN 서버(미도시)나 신용카드사 서버(미도시)로 송부하여 신용 결제를 진행하게 된다.
한편, EMV 신용카드(10)와 EMV 결제 단말기(20)는 RF(Radio Frequency) 통신을 수행하므로, EMV 신용카드(10)와 RF 필드내에 위치하는 비 정규 결제 단말기(30)가 EMV 신용카드(10)와 근접하는 경우 비 정규 결제 단말기(30)가 EMV 신용카드(10)를 통해 어플리케이션 버전 정보, 이동통신사 정보를 비롯하여 트랙 2 정보를 획득할 수도 있다.
현재, 휴대단말기와 연결되어 타 휴대단말기로부터 카드 정보를 획득하는 장치도 출시되어 있다.
이러한 상황에서 비 정규 결제 단말기(30)는 카드 소지자(Card Holder)의 허가없이 EMV 신용카드(10)에서 카드 정보를 획득할 수 있으며, 획득한 카드 정보는 악용될 우려가 있다.
이에 본 출원인은 EMV 신용카드(10)와 EMV 결제 단말기(20)가 상호 정당한 거래 대상인가를 판단할 수 있도록 하며, 정당한 거래 대상끼리(10, 20) 카드 정보를 주고 받을 수 있도록 하는 결제 디바이스에 대한 상호인증 방법을 제안하고자 한다.
본 발명의 목적은 신용카드와 결제 단말기가 상호 정당한 거래 대상인가를 판단할 수 있도록 함으로써, 정당한 거래 대상인 결제 단말기와 신용카드가 카드 정보를 주고 받을 수 있도록 하며, 이를 통해 비 정규 결제 단말기에 의한 해킹 및 정보 유출에 대한 보안 위협을 감소시키는 결제 디바이스에 대한 상호인증 방법을 제공하는데 있다.
상기한 목적은 본 발명에 따라, 결제 디바이스의 결제를 처리하는 결제 단말기에 의해 수행되며, 제1랜덤 값을 생성하고 상기 랜덤 값에 대한 제1 해쉬 값을 생성하는 단계, 상기 랜덤 값을 상기 결제 디바이스로 제공하고, 상기 결제 디바이스에서 리턴하는 제2 해쉬 값과 상기 제1 해쉬 값을 비교하여 상기 결제 디바이스를 인증하는 단계를 포함하며, 상기 결제 단말기는, 제1 해쉬 값과 상기 제2 해쉬 값이 일치할 때, 상기 결제 디바이스를 인증하고, 상기 결제 디바이스는, 상기 랜덤 값에 대한 상기 제2 해쉬 값 생성을 요청받는 경우 상기 결제 단말기를 정규 결제 단말기로 인식하여 카드 정보를 제공하는 결제 디바이스에 대한 상호인증 방법에 의해 달성된다.
상기한 목적은 본 발명에 따라, 결제 디바이스의 결제를 처리하는 결제 단말기에 의해 수행되며, 제1 랜덤 값을 생성하고 상기 랜덤 값에 대한 제1 해쉬 값을 생성하는 단계, 상기 제1 랜덤 값을 상기 결제 디바이스로 제공하고, 상기 결제 디바이스에서 리턴하는 제2 해쉬 값과 상기 제1 해쉬 값을 비교하여 상기 결제 디바이스를 인증하는 단계 및 상기 결제 디바이스가 제공하는 제2 랜덤 값에 대한 제2 해쉬 값을 상기 결제 디바이스로 제공하여 상기 결제 디바이스로부터 인증받는 단계에 의해 달성된다.
본 발명에 따르면, 신용카드가 올바른 결제 단말기와 대면하지 않는 상태에서는 신용카드에서 트랙 2 정보가 저장되는 위치정보를 숨기도록 하며, 이를 통해 신용카드의 보안성을 향상시킬 수 있다.
도 1은 EMV 카드와 EMV 단말기가 AFL을 전송하는 과정에 대한 참조도면을 도시한다.
도 2와 도 3은 본 발명에 따른 결제 디바이스에 대한 상호인증 방법에 대한 개념도를 도시한다.
도 4는 본 발명의 일 실시예에 따른 결제 디바이스에 대한 상호인증 방법의 흐름도를 도시한다.
도 5는 본 발명의 다른 실시예에 따른 결제 디바이스에 대한 상호인증 방법의 흐름도를 도시한다.
도 6은 본 발명을 수행하는데 이용되는 결제 단말기의 블록개념도의 일 예를 도시한다.
도 7은 해쉬 알고리즘을 이용하여 해쉬 값을 생성하는 일 예에 대한 참조도면을 도시한다.
본 명세서에서 언급되는 트랙 2 정보는 ISO 7813 규격에 따른 카드 정보를 의미할 수 있다.
본 명세서에서 언급되는 결제 디바이스는 트랙 2 정보를 포함하는 전자 신용카드 또는 USIM((Universal Subscriber Identity Module) 칩을 내장하는 휴대단말기일 수 있다.
본 명세서에서 휴대단말기는 스마트폰(Smart Phone)과 휴대폰을 중심으로 기술되고 설명된다. 그러나, 언급된 스마트폰 및 휴대폰 이외에도 휴대 가능하고 USIM 칩을 내장하여 신용카드를 대체 가능한 장치라면 별도로 언급하지 않더라도 휴대단말기라 지칭할 수 있다.
본 명세서에서 언급되는 결제 단말기는, IC(Integrated Circuit)를 내장한 전자 신용카드 및 USIM 칩을 내장하는 휴대단말기로부터 카드 정보(예컨대 트랙 2 정보)를 획득하여 트랜잭션 처리가 가능한 기기를 의미할 수 있다. 여기서, 결제 단말기는 전자 신용카드 및 휴대단말기 중에서 어느 하나와만 트랜잭션 처리가 가능할 수도 있고, 둘 모두와 트랜잭션 처리가 가능한 것일 수도 있다. 다만 한정하지는 않는다.
본 명세서에서 언급되는 EMV 는 Euro/ Master/ Visa의 약어로, 암호화된 IC 칩을 이용하며, 신용카드 거래 시, 결제 단말기를 통해 PIN(Personal Identification Number)을 입력하도록 함으로써 카드의 위 변조를 차단하는 규격을 지칭한다.
본 명세서에서 언급되는 트랙 2 정보는 PAN(Primary Account Number) 영역/ ED(Expire Data) 영역/ SC(Service Code) 영역/ DD(Discretionary Data) 영역을 구비하며, PAN 영역은 본 출원인이 개발한 가변형 PAN일 수 있다. 가변형 PAN은 트랙 2 정보에서 BIN(Bank Information Number)은 노출되고, BIN을 제외한 카드 계정정보는 암호화함으로써 신용카드 거래 시, 카드 계정정보가 노출되지 않도록 한다.
본 명세서에서 언급되는 해쉬 값은 SHA-1(Secure Hash Algorithm - 1), SHA-2, MD 5 알고리즘(Message-Digest Algorithm 5)와 같은 해쉬 알고리즘에 의해 생성되는 해쉬 값을 의미할 수 있다. 해쉬 알고리즘은 이 외에도 다양한 것이 이용될 수 있다.
본 명세서에서 언급되는 결제 단말기는 EMV 규격에 따라 신용카드와 데이터 통신을 수행할 수 있다. 그러나, 본 명세서에서 언급되는 결제 단말기는 올바른 신용카드나 휴대단말기와 같은 결제 디바이스와 대면하였을 때, 데이터 통신이 유지되며, 비 정상적인 결제 디바이스와 대면하는 경우에는 데이터 통신이 유지되지 않을 수 있다. 즉 신용거래가 중단될 수 있다.
이하, 도면을 참조하여 본 발명을 상세히 설명하도록 한다.
도 2와 도 3은 본 발명에 따른 결제 디바이스에 대한 상호인증 방법에 대한 개념도를 도시한다.
먼저, 도 2를 참조하면, 결제 디바이스(50)가 결제 단말기(100)에 근접(proximity) 시, 또는 접촉 시, 결제 단말기(100)는 근거리(수 센티미터 내지 수십 센티미터)에 위치하는 결제 디바이스(50)를 감지하고, 결제 디바이스(50)로 응용 프로그램 목록을 요청하며, 결제 디바이스(50)는 응용 프로그램 목록을 결제 단말기(100)로 송부한다. 결제 디바이스(50)에서 결제 단말기(100)로 송부되는 응용 프로그램의 목록은 하나의 파일 형태를 가질 수 있으며, EMV 규격의 신용카드에서는 1PAY.SYSDDF01와 같은 파일을 결제 디바이스(50)에서 결제 단말기(100)로 전송할 수 있다. 여기서, 응용 프로그램은 결제 디바이스(50)로 비용을 결제할 때, 비용 결제에 이용되는 결제 프로그램을 의미할 수 있다.
결제 디바이스(50)에서 결제 단말기(100)로 응용 프로그램 목록이 송부된 후, 결제 단말기(100)는 결제 디바이스(50)에서 구동 가능한 응용 프로그램을 참조하여 결제 디바이스(50)를 구동하는데, 이때, 통신 커버리지 내에 둘 이상의 신용카드가 존재할 수 있다. 이 경우, 결제 단말기(100)는 복수의 신용카드들(또는 복수의 휴대단말기들) 중 하나를 선택하여야 하며, 이때, 결제 단말기(100)에서 발생하는 명령은 카드 선택 명령(card select)에 해당한다.
신용 거래를 위한 신용카드가 선택된 후, 결제 단말기(100)는 카드 선택 명령(card select) 이후에 진행되어야 하는 겟 프로세싱 옵션 명령을 수행하는 대신, 신용카드 검증을 위한 상호인증 명령(mutual authentication)을 수행한다.
상호인증 명령(mutual authentication)은 결제 디바이스(50)와 결제 단말기가 상호 데이터를 교류하면서 인증 값을 생성하고, 생성된 인증 값을 이용하여 올바른 거래 대상인가를 판단하기 위한 명령어로서, EMV 규격에는 존재하지 않는다.
상호인증 명령(mutual authentication )은 아래의 각 호에 따른 순서에 따라 생성되고 운용된다.
- 아래 -
1) 결제 단말기(100)에서 랜덤 값을 생성한다. 이때 생성되는 랜덤 값은
- 결제 디바이스(50)가 결제 단말기(100)에 감지되는 시간에 따라 생성되는 값,
- 결제 디바이스(50)가 결제 단말기(100)에서 감지된 이후, 결제 단말기(100)가 랜덤하게 생성하는 랜덤 값 중 어느 하나일 수 있다. 이 외에도, 결제 디바이스(50)가 결제 단말기(100)와 대면하는 순간 이후의 임의의 시간을 이용하여 결제 단말기(100)가 랜덤 값을 생성할 수도 있다.
2) 결제 단말기(100)는 랜덤 값을 입력 값으로 하며, 기 마련되는 암호화 키를 이용하여 해쉬 알고리즘을 구동하여 해쉬 값을 생성한다.
3) 결제 단말기(100)는 해쉬 알고리즘에 입력한 랜덤 값을 결제 디바이스(50)로 전송한다.
4) 결제 디바이스(50)는 결제 단말기(100)에서 전송된 랜덤 값을 입력으로 하여 해쉬 알고리즘을 구동하며, 이때, 자체 내장되는 암호화 키를 이용하여 결제 단말기(100)가 제공하는 랜덤 값에 대한 해쉬 값을 생성하고, 생성된 해쉬 값을 결제 단말기(100)로 리턴(Return)한다.
5) 결제 단말기(100)는 결제 디바이스(50)에서 리턴한 해쉬 값과 2) 단계에서 생성한 해쉬 값을 비교하여 동일한가를 판단한다.
6) 결제 단말기(100)는 결제 디바이스(50)에서 리턴한 해쉬 값과 자체 생성한 해쉬 값이 동일하면 정당한 결제 디바이스(50)로 인식하여 다음 명령(겟 프로세싱 옵션 명령)을 수행하고, 그렇지 않은 경우, 다음 명령(겟 프로세싱 옵션 명령)을 수행하지 않고 신용 거래 과정을 종료한다.
한편, 통신 커버리지 내에 비정규 결제 단말기, 예컨대 휴대 가능한 형태의 비정규 결제 단말기(30)가 존재하는 경우, 비정규 결제 단말기(30)는 결제 디바이스(50)로 겟 프로세싱 명령을 전송하며, 결제 디바이스(50)는 상호인증 명령(mutual authentication)을 기다릴 수 있다.
만일, 비정규 결제 단말기(30)가 상호인증 명령을 제공하지 않는 경우, 결제 디바이스(50)는 정당한 거래 대상이 아닌 것으로 판단하여 트랙 2 정보를 비정규 결제 단말기(30)로 제공하지 않는다.
상기한 1) 내지 6)의 순서에 따르면, 결제 단말기(100)는 카드 선택 명령(Card Select) 이후, 겟 프로세싱 옵션 명령을 수행하여 결제 디바이스(50)의 응용 프로그램을 초기화한다.
여기서, 암호화 키는 해쉬 알고리즘을 구동하기 위한 별도의 키를 의미하지는 않는다. 암호화 키는 결제 디바이스(50)와 결제 단말기(100) 양측에 마련되는 고정 값으로서 해쉬 알고리즘을 구동할 때, 랜덤 값의 전후에 자동 배치되도록 함으로써 암호화 키의 역할을 하는 것이며, 그 자체가 암호화 키는 아니다.
본 실시예에서 적용되는 해쉬 알고리즘을 통해 해쉬 값이 산출되는 방법은 도 7을 함께 참조하여 설명하도록 한다.
도 7을 함께 참조하면, 해쉬 알고리즘은 헤더(header), 테일러(tailer) 및 랜덤 값을 입력으로 해쉬 값을 구할 수 있다.
도 7에서,
헤더 값은 "11111111111111111111111111111111"
테일러 값은 "22222222222222222222222222222222"
랜덤 값은 "404142434445464748494A4B4C4D4E4F" 라고 가정할 때,
해쉬 알고리즘은 헤더 | 랜덤 값 | 테일러를 입력 값으로 하여 해쉬 값을 생성할 수 있다.
결제 디바이스(50)에서 도 7에 도시된 순서대로 (헤더 값 | 랜덤 값 | 테일러)를 입력 값으로 하여 생성된 해쉬 값이 제1 해쉬 값이라고 가정하고,
결제 단말기(100)에서 (헤더 값 | 랜덤 값 | 테일러)를 입력 값으로 하여 생성된 해쉬 값이 제2 해쉬 값이라고 가정하면,
헤더 값과 테일러 값이 동일한 상태에서 동일한 랜덤 값을 공유했을 때, 결제 디바이스(50)에서 생성되는 제1 해쉬 값과 결제 단말기(100)에서 생성되는 제2 해쉬 값은 동일한 값이 나와야 한다.
즉, 결제 디바이스(50)와 결제 단말기(100)는 헤더 값과 테일러 값을 암호화 키처럼 이용하여 해쉬 값을 생성하는데, 결제 디바이스(50)와 결제 단말기(100) 사이에 송수신되는 데이터에서 헤더 값과 테일러 값은 노출되지 않으므로 타인이 이를 인지하는데 어려움이 따른다. 헤더 값과 테일러 값은 랜덤 값의 전단과 후단에 부가될 뿐, 암호화 키로서 인식되지는 않으므로 해쉬 알고리즘에 따른 제1 해쉬 값이나 제2 해쉬 값이 타인에 의해 쉽게 유추되지 않을 수 있다.
여기서, 도 7을 통해 설명된 해쉬 알고리즘의 암호화 방식은 본 명세서 전반에 걸쳐 동일하게 적용되며 중복되는 설명은 생략하도록 한다.
다음으로, 도 3을 참조하면, 결제 디바이스(50)가 결제 단말기(100)에 근접(proximity) 시, 결제 단말기(100)는 근거리(수 센티미터 내지 수십 센티미터)에 위치하는 결제 디바이스(50)를 감지하고, 결제 디바이스(50)로 응용 프로그램 목록을 요청하고, 응용 프로그램 목록을 참조하여 결제 디바이스(50)에 내장되는 IC 칩(51)을 구동한다. 이후, 카드 선택 명령(card select)을 이용하여 복수의 신용카드가 통신 커버리지 내에 위치하는 경우 하나의 신용카드를 선택하는 과정까지는 전술한 도 2의 설명과 동일하다. 도 3의 실시예는, 결제 단말기(100)에서 겟 프로세싱 옵션 명령을 수행한 이후, 상호인증 명령(mutual authentication)을 수행한다는 점에서 도 2의 실시예와 차별점을 갖는다. 겟 프로세싱 옵션 명령이 수행된 이후, 결제 단말기(100)가 리드 레코드(Read Record) 명령을 수행하면 결제 디바이스(50)는 이에 응답하여 ISO/IEC 7813 규격에 따른 트랙 2 정보를 결제 단말기(100)로 전송하게 된다. 따라서, 결제 디바이스(50)에서 결제 단말기(100)로 트랙 2 정보가 전송되기 전에 결제 단말기(100)가 상호인증 명령(mutual authentication)을 먼저 수행함으로써 결제 디바이스(50)가 올바른 결제 단말기(100)와 신용 거래를 하는지를 판단할 수 있는 것이다.
도 3의 상호인증 방법 또한, 통신 커버리지 내에 비정규 결제 단말기, 예컨대 휴대 가능한 형태의 비정규 결제 단말기(30)가 존재하는 경우, 비정규 결제 단말기(30)는 결제 디바이스(50)로 겟 프로세싱 명령을 전송하며, 결제 디바이스(50)는 상호인증 명령(mutual authentication)을 기다릴 수 있다.
만일, 비정규 결제 단말기(30)가 상호인증 명령을 제공하지 않는 경우, 결제 디바이스(50)는 정당한 거래 대상이 아닌 것으로 판단하여 카드 정보(예컨대 트랙 2 정보)를 비정규 결제 단말기(30)로 제공하지 않는다.
도 3의 상호인증 방법은 도 2의 실시예에서 언급된 1) 내지 6)의 과정을 동일하게 수행하고, 도 6에 의한 해쉬 값 대조를 동일하게 수행한다. 다만, 도 2를 통해 설명된 6)의 과정은 아래의 6-1)의 과정으로 대체될 수 있다.
- 아래 -
6-1) 결제 단말기(100)는 결제 디바이스(50)에서 리턴한 해쉬 값과 자체 생성한 해쉬 값이 동일하면 신용 거래에 정당한 결제 디바이스(50)로 인식하여 다음 명령(리드 레코드 명령)을 수행하고, 그렇지 않은 경우, 다음 명령(리드 레코드 명령)을 수행하지 않고 신용 거래 과정을 종료한다.
도 2와 도 3에 도시되고 설명된 겟 프로세싱 옵션 명령이 수행된 이후에 결제 단말기(100)는 결제 금액 및 신용카드 소지자(Card Holder)로부터 카드 비밀번호(PIN : Personal Identification Number)가 입력되면 어플리케이션 실행명령(generate AC) 명령을 수행한다. 어플리케이션 실행명령은 결제 디바이스(50)로 전송되고, 결제 디바이스(50)는 어플리케이션 실행명령에 응답하여 암호화된 승인요청 데이처(Authorization Request Crytogram : ARQC)를 결제 단말기(100)로 리턴한다.
결제 단말기(100)는 암호화된 승인요청 데이터(ARQC)를 수신 후, 카드 정보, 결제 단말기 정보 및 가맹점 코드를 포함하는 결제 승인 정보를 포함하는 결제 승인 요청 데이터를 생성하며, VAN 서버(미도시)를 통해 카드사 서버(미도시)로 전송하여 신용카드의 유효성 여부를 문의할 수 있다. 이에 따라, 결제 단말기(100)는 EMV 표준에 따른 결제 승인 과정을 진행하며, EMV 표준에는 존재하지 않는 상호승인 과정을 이용하여 정당한 결제 디바이스(50)와 결제 단말기(100)만이 비용 결제를 진행할 수 있는 것이다.
또한, 신용 거래를 위한 정당한 결제 디바이스(50)와 결제 단말기(100)가 근거리로 대면할 때만 결제 디바이스(50)에서 결제 단말기(100)로 트랙 2 정보 및 카드 정보를 포함하는 저장 영역에 대한 위치정보를 제공하므로, 외부인에 의한 해킹 시도가 사전에 차단될 수 있다.
도 4는 본 발명의 일 실시예에 따른 결제 디바이스에 대한 상호인증 방법의 흐름도를 도시한다.
도 4를 참조하면, 실시예에 따른 결제 디바이스에 대한 상호인증 방법은, 결제 디바이스(50)가 결제 단말기(100)와 근거리(수 센티미터 내지 수십 센티미터)로 근접할 때, 결제 단말기(100)가 결제 디바이스(50)를 인지하고 카드 선택 명령(Card Select) 명령을 통해 통신 커버리지 내에 둘 이상의 신용카드가 존재할 경우 하나의 신용카드를 선택하여 결제 프로세스를 진행할 수 있다.
이때, 결제 디바이스(50)는 둘 이상의 결제 단말기(30, 100)의 통신 커버리지 내에 위치할 수 있다. 통신 커버리지 내에 거래 대상인 결제 단말기(100)와 비 정규 결제 단말기(30)가 함께 존재하는 경우, RF 통신을 이용하여 통신을 수행하는 결제 디바이스(50)는 비 정규 결제 단말기(30)와 결제 단말기(100) 양측에 대해 상호인증 명령의 전송 여부를 판단할 수 있다. 상호인증 명령을 전송하는 결제 단말기(100)에 대해서만 트랙 2 정보를 제공하며, 상호인증 명령을 전송하지 않는 비 정규 결제 단말기(30)에 대해서는 카드 정보 전송을 차단할 수 있다.
다음으로, 결제 단말기(100)는 랜덤 값을 생성하고, 생성된 랜덤 값에 대해 해쉬 알고리즘을 이용하여 해쉬 값을 생성할 수 있다.
생성된 해쉬 값은 결제 단말기(100)가 임시 보관하고, 생성된 랜덤 값은 결제 디바이스(50)로 전송되어 랜덤 값에 대한 해쉬 값을 요구할 수 있다.
이때, 결제 디바이스(50)와 결제 단말기(100)는 동일한 암호화 키를 구비할 수 있으며, 동일한 랜덤 값을 입력으로 하여 동일한 암호화 키를 적용하여 해쉬 알고리즘을 이용하면 동일한 해쉬 값이 산출될 수 있다.
결제 디바이스(50)는 결제 단말기(100)에서 제공되는 랜덤 값을 입력으로 하여 해쉬 알고리즘을 구동하여 해쉬 값을 생성하고, 생성된 해쉬 값을 결제 단말기(100)로 리턴한다.
결제 단말기(100)는 결제 디바이스(50)에서 리턴한 해쉬 값과 임시 보관한 해쉬 값을 비교한다. 겟 프로세싱 옵션 명령이 실행되기 이전의 상태에서, 결제 단말기(100)는 결제 디바이스(50)로부터 응용 프로그램 목록, 이동 통신사 정보 및 응용 프로그램의 버전 정보만을 획득하므로 결제 디바이스(50)의 카드 정보를 온전히 획득하지 않은 상태이다.
즉, 실시예는 결제 단말기(100)가, 결제 디바이스(50)의 IC 칩(51)에서 트랙 2 정보가 위치하는 위치정보를 획득하기 이전에 결제 디바이스(50)와 상호인증을 수행한다는 점에서 비 정규적인 결제 단말기가 결제 디바이스(50)에서 트랙 2 정보의 위치정보를 획득하지 못하도록 하는데 그 특징이 있다.
또한, 실시예에 따른 결제 디바이스에 대한 상호인증 방법은 신용카드 소지자(Card Holder)가 신용거래를 취소하는 경우 결제 디바이스(50)에서 트랙 2 정보에 대한 위치정보가 결제 단말기(100)로 노출되지 않도록 할 수 있다.
도 5는 본 발명의 다른 실시예에 따른 결제 디바이스에 대한 상호인증 방법의 흐름도를 도시한다.
도 5를 참조하면, 실시예에 따른 결제 디바이스(50)에 대한 상호인증 방법은, 결제 디바이스(50)가 결제 단말기(100)와 근거리(수 센티미터 내지 수십 센티미터)로 근접할 때, 결제 단말기(100)가 결제 디바이스(50)를 인지하고 카드 선택 명령(Card Select) 명령을 통해 통신 커버리지 내에 둘 이상의 결제 디바이스가 존재할 경우 하나의 결제 디바이스를 선택하여 결제 프로세스를 진행할 수 있다.
이때, 결제 디바이스(50)는 둘 이상의 결제 단말기(30, 100)의 통신 커버리지 내에 위치할 수 있다. 통신 커버리지 내에 거래 대상인 결제 단말기(100)와 비 정규 결제 단말기(30)가 함께 존재하는 경우, RF 통신을 이용하여 통신을 수행하는 결제 디바이스(50)는 비 정규 결제 단말기(30)와 결제 단말기(100) 양측에 대해 상호인증 명령의 전송 여부를 판단할 수 있다. 결제 디바이스(50)는 상호인증 명령을 전송하는 결제 단말기(100)에 대해서만 트랙 2 정보를 제공할 수 있으며, 상호인증 명령을 전송하지 않는 비 정규 결제 단말기(30)에 대해서는 카드 정보 전송을 차단할 수 있다.
다음으로, 결제 단말기(100)는 결제 디바이스(50)로 랜덤 값을 생성하여 전송하고, 제1랜덤 값에 대해 결제 디바이스(50)에서 암호화되어 회신되는 암호화 값을 획득할 수 있다. 이때, 결제 단말기(100)는 결제 디바이스로 제공한 제1랜덤 값으로 미리 암호화 값을 생성해두며, 결제 디바이스(50)에서 회신된 암호화 값과 자체 생성한 암호화 값을 비교하여 동일하면 결제 디바이스(50)를 인증할 수 있다.
이때, 결제 디바이스(50)와 결제 단말기(100)는 동일한 해쉬 알고리즘에 의해 암호화 값을 생성할 수 있다.
다음으로, 결제 단말기(100)는 제2랜덤 값을 생성하고, 생성된 제2랜덤 값에 대해 해쉬 알고리즘을 이용하여 해쉬 값을 생성한다.
생성된 해쉬 값은 결제 단말기(100)가 임시 보관하고, 생성된 랜덤 값은 결제 디바이스(50)로 전송되어 랜덤 값에 대한 해쉬 값을 요구할 수 있다.
이때, 결제 디바이스(50)와 결제 단말기(100)는 동일한 암호화 키를 구비할 수 있으며, 동일한 랜덤 값을 입력으로 하여 동일한 암호화 키를 적용하여 해쉬 알고리즘을 이용하면 동일한 해쉬 값이 산출될 수 있다.
결제 디바이스(50)는 결제 단말기(100)에서 제공되는 랜덤 값을 입력으로 하여 해쉬 알고리즘을 구동하여 해쉬 값을 생성하고, 생성된 해쉬 값을 결제 단말기(100)로 리턴한다.
결제 단말기(100)는 결제 디바이스(50)에서 리턴한 해쉬 값과 임시 보관한 해쉬 값을 비교한다. 겟 프로세싱 옵션(get processing option) 명령이 실행되기 이전의 상태에서, 결제 단말기(100)는 결제 디바이스(50)로부터 응용 프로그램 목록, 이동 통신사 정보 및 응용 프로그램의 버전 정보만을 획득하므로 결제 디바이스(50)의 카드 정보를 온전히 획득하지 않은 상태이다.
다음으로, 결제 디바이스(50)는 임의의 랜덤 값(이하, 제2 랜덤 값이라 한다)을 생성하고, 생성된 제2 랜덤 값을 입력으로 하는 해쉬 알고리즘을 구동하여 제1 해쉬 값을 생성한다.
이후, 결제 디바이스(50)는 제2 랜덤 값을 결제 단말기(100)로 제공하고, 결제 단말기(100)로부터 동일한 해쉬 알고리즘을 이용한 제2 해쉬 값을 수신할 수 있다. 만일 결제 단말기(100)가 정규 결제 단말기(100)인 경우, 결제 디바이스(50)는 결제 단말기(100)로부터 획득한 제2 해쉬 값이 자체 생성한 제1 해쉬 값과 동일하며, 이를 통해 결제 단말기(100)가 정규 결제 단말기임을 확인할 수 있다.
이후, 결제 디바이스(50)는 결제 단말기(100)로부터 겟 프로세싱 옵션 명령 또는 리드 레코드 명령을 수신할 수 있으며, 해당 명령이 수신되면 카드 정보를 결제 단말기(100)로 제공할 수 있다.
본 실시예는, 결제 디바이스(50)와 결제 단말기(100)가 상호 인증을 마치면 결제 디바이스(50)에서 결제 단말기(100)로 카드 정보를 제공하므로 비 정규 결제 단말기(30)에 의한 카드정보 누출이 차단되는 잇점을 갖는다.
도 6은 본 발명을 수행하는데 이용되는 결제 단말기의 블록개념도의 일 예를 도시한다.
도 6을 도시하면, 결제 단말기(100)는 프로세서(121), 사인패드(122), 리더부(123), 통신부(124), 인쇄부(125), 메모리(126) 및 입력부(127)를 포함하여 구성될 수 있다.
프로세서(121)는 결제 단말기(100)를 전반적으로 제어하며, 리더부(123)를 통해 자기식 신용카드, 전자 신용카드 및 휴대단말기와 같은 결제 디바이스(50)의 트랜잭션 처리 요청을 수신하고, 입력부(127)에 입력되는 금액정보 및 사인패드(122)에서 획득된 사인의 이미지를 취합하여 결제 정보를 생성하고, 통신부(124)를 통해 생성된 결제정보를 VAN 서버(150)나 카드사 서버(100)로 제공하여 트랜잭션을 처리할 수 있다.
프로세서(121)는 RTC(Real Time Clock)를 내장하거나, 또는 RTC와 연결되어 현재 시간을 계수할 수 있다.
또한, 프로세서(121)는 코-프로세서(Co-processor)를 내장하거나, 별도의 코-프로세서(Co-processor)와 연결될 수 있으며, 코-프로세서와 연동하여 해쉬 알고리즘을 구동하는 프로그램을 구동할 수도 있다. 해쉬 알고리즘을 구동하는 프로그램은 메모리(126)에 마련될 수 있다.
메모리(126)는 휘발성 메모리(126a) 또는 비 휘발성 메모리(126b)를 포함할 수 있다. 휘발성 메모리(126a)는 DRAM 또는 SRAM으로 구성될 수 있으며, 프로세서(121)가 각 부(122 내지 127)의 제어나 구동을 위한 프로그램을 구동 시, 프로그램 구동을 위한 임시 저장공간으로 이용될 수 있다.
비 휘발성 메모리(126b)는 프로세서(121)에서 해쉬 알고리즘을 구동하는 프로그램 및 결제 단말기(100)를 위한 운영체제(Operating System)를 구비할 수 있다.
인쇄장치(25)는 결제 디바이스(50)가 요청한 트랜잭션 처리 후, 결제 디바이스(50)의 결제 내역을 인쇄하여 영수증을 출력하며, 통신부(124)는 유선 또는 무선 통신을 이용하여 VAN 서버, 또는 카드사 서버와 네트워크 연결할 수 있다.
리더부(123)는 결제 디바이스(50)와 접촉하거나, 또는 비 접촉식으로 근접한 결제 디바이스(50)로부터 트랙 2 데이터를 획득할 수 있다.
바람직하게는, 리더부(123)는 마그네틱 스트립과 접촉하여 트랙 2 데이터를 읽어내는 MS 리더부(123a), 휴대단말기와 NFC(Near Field Communication)을 수행하여 휴대단말기에 내장되는 USIM 정보 및 신용카드 정보를 획득하는 NFC 리더부(123b) 및 전자 신용카드와 데이터 통신을 수행하여 전자 신용카드에서 트랙 2 데이터를 획득하는 비 접촉식 IC 리더부(123c)를 포함할 수 있다. 여기서, 리더부(123)는 MS 리더부(123a), NFC 리더부(123b) 및 비 접촉식 IC 리더부(123c) 중 하나만을 구비하거나, 둘 또는 셋 모두를 구비할 수도 있다.
< 50 : 신용카드 > < 51 : IC 칩 >
< 100 : 결제 단말기 >
본 발명은 결제 디바이스가 정당한 결제 단말기를 통해 결제를 진행하도록 하며, 와 결제 단말기가 상호 인증을 통한 결제를 진행토록 하며, 신용카드 결제환경 및 모바일 결제 환경을 제공하는 신용카드사 및 은행과 같은 금융업의 활성화에 기여할 수 있다.

Claims (14)

  1. 결제 디바이스의 결제를 처리하는 결제 단말기에 의해 수행되며,
    제1랜덤 값을 생성하고 상기 랜덤 값에 대한 제1 해쉬 값을 생성하는 단계;
    상기 랜덤 값을 상기 결제 디바이스로 제공하고, 상기 결제 디바이스에서 리턴하는 제2 해쉬 값과 상기 제1 해쉬 값을 비교하여 상기 결제 디바이스를 인증하는 단계;를 포함하며,
    상기 결제 단말기는, 제1 해쉬 값과 상기 제2 해쉬 값이 일치할 때, 상기 결제 디바이스를 인증하고,
    상기 결제 디바이스는, 상기 랜덤 값에 대한 상기 제2 해쉬 값 생성을 요청받는 경우 상기 결제 단말기를 정규 결제 단말기로 인식하여 카드 정보를 제공하는 것을 특징으로 하는 결제 디바이스에 대한 상호인증 방법.
  2. 제1항에 있어서,
    상기 결제 단말기는,
    상기 제2 해쉬 값이 상기 제1 해쉬 값과 일치할 때,
    상기 결제 디바이스가 카드 정보를 포함하는 저장 영역의 위치정보를 획득하기 위한 겟 프로세싱 옵션(get processing option) 명령을 실행하는 것을 특징으로 하는 결제 디바이스에 대한 상호인증 방법.
  3. 제2항에 있어서,
    상기 결제 단말기는,
    상기 제1 해쉬 값과 상기 제2 해쉬 값이 일치하지 않는 경우, 상기 결제 디바이스에 의한 비용 결제 프로세스를 취소하는 것을 특징으로 하는 결제 디바이스에 대한 상호인증 방법.
  4. 제1항에 있어서,
    상기 결제 단말기는,
    상기 결제 디바이스와 상기 결제 단말기에 대한 인증이 완료되면 상기 결제 디바이스로부터 카드 정보를 독출하기 위한 리드 레코드(Read Record) 명령을 실행하는 것을 특징으로 하는 결제 디바이스에 대한 상호인증 방법.
  5. 제1항에 있어서,
    상기 해쉬 값과 상기 리턴 값은,
    해쉬 알고리즘에 의해 생성되는 해쉬 값인 것을 특징으로 하는 결제 디바이스에 대한 상호인증 방법.
  6. 제1항에 있어서,
    상기 해쉬 값은,
    헥사(hexa) 값인 것을 특징으로 하는 결제 디바이스에 대한 상호인증 방법.
  7. 제1항에 있어서,
    상기 제1 해쉬 값과 상기 제2 해쉬 값은,
    해쉬 알고리즘에 의해 암호화된 상태에서 비교하는 것을 특징으로 하는 결제 디바이스에 대한 상호인증 방법.
  8. 제1항에 있어서,
    상기 랜덤 값은,
    상기 결제 단말기에서 임의로 생성되는 값인 것을 특징으로 하는 결제 디바이스에 대한 상호인증 방법.
  9. 제1항에 있어서,
    상기 제1 해쉬 값 및 상기 제2 해쉬 값은,
    상기 랜덤 값 및 상기 랜덤 값의 전단과 후단에 각각 부가되는 헤더 값과 테일러 값을 입력으로 하여 생성되는 해쉬 값인 것을 특징으로 하는 결제 디바이스에 대한 상호인증 방법.
  10. 제9항에 있어서,
    상기 헤더 값과 상기 테일러 값은,
    상기 랜덤 값에 자동 부여되며, 고정 값(Static Value)인 것을 특징으로 하는 결제 디바이스에 대한 상호인증 방법.
  11. 제10항에 있어서,
    상기 헤더 값과 상기 테일러 값은,
    숫자열인 것을 특징으로 하는 결제 디바이스에 대한 상호인증 방법.
  12. 제1항에 있어서,
    상기 결제 디바이스는,
    상기 결제 단말기가 상호인증을 위해 상기 랜덤 값에 대한 상기 제2 해쉬 값 생성을 요청하지 않는 경우 비정규 결제 단말기로 인식하며, 상기 결제 단말기로 카드 정보를 전송하지 않는 것을 특징으로 하는 결제 디바이스에 대한 상호인증 방법.
  13. 결제 디바이스의 결제를 처리하는 결제 단말기에 의해 수행되며,
    제1 랜덤 값을 생성하고 상기 랜덤 값에 대한 제1 해쉬 값을 생성하는 단계;
    상기 제1 랜덤 값을 상기 결제 디바이스로 제공하고, 상기 결제 디바이스에서 리턴하는 제2 해쉬 값과 상기 제1 해쉬 값을 비교하여 상기 결제 디바이스를 인증하는 단계; 및
    상기 결제 디바이스가 제공하는 제2 랜덤 값에 대한 제2 해쉬 값을 상기 결제 디바이스로 제공하여 상기 결제 디바이스로부터 인증받는 단계;를 포함하는 것을 특징으로 하는 결제 디바이스에 대한 상호인증 방법.
  14. 제13항에 있어서,
    상기 결제 단말기는,
    상기 결제 디바이스로부터 인증된 후, 상기 결제 디바이스로부터 카드 정보를 획득하는 것을 특징으로 하는 결제 디바이스에 대한 상호인증 방법.
PCT/KR2012/011692 2012-12-27 2012-12-28 결제 디바이스에 대한 상호인증 방법 Ceased WO2014104436A1 (ko)

Priority Applications (4)

Application Number Priority Date Filing Date Title
CN201280078132.5A CN105009154A (zh) 2012-12-27 2012-12-28 用于支付装置的相互认证的方法
US14/758,459 US20150332261A1 (en) 2012-12-27 2012-12-28 Method for mutual authentication for payment device
EP12890943.9A EP2940642A4 (en) 2012-12-27 2012-12-28 METHOD OF MUTUAL AUTHENTICATION FOR PAYMENT DEVICES
JP2015551041A JP2016503992A (ja) 2012-12-27 2012-12-28 決済デバイスに対する相互認証方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR1020120154442A KR101330867B1 (ko) 2012-12-27 2012-12-27 결제 디바이스에 대한 상호인증 방법
KR10-2012-0154442 2012-12-27

Publications (1)

Publication Number Publication Date
WO2014104436A1 true WO2014104436A1 (ko) 2014-07-03

Family

ID=49858026

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2012/011692 Ceased WO2014104436A1 (ko) 2012-12-27 2012-12-28 결제 디바이스에 대한 상호인증 방법

Country Status (6)

Country Link
US (1) US20150332261A1 (ko)
EP (1) EP2940642A4 (ko)
JP (1) JP2016503992A (ko)
KR (1) KR101330867B1 (ko)
CN (1) CN105009154A (ko)
WO (1) WO2014104436A1 (ko)

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
FR3037424A1 (fr) * 2015-06-15 2016-12-16 Ingenico Group Procede de detection d'un terminal frauduleux par un cryptogramme, dispositif et programme correspondants
US10127539B2 (en) 2015-09-30 2018-11-13 Bank Of America Corporation System for tokenization and token selection associated with wearable device transactions
US10153056B2 (en) 2016-05-09 2018-12-11 Bank Of America Corporation System for a geographic location based sharing request network
US10360560B2 (en) 2015-09-01 2019-07-23 Bank Of America Corporation System for authenticating a wearable device for transaction queuing
US10438201B2 (en) 2015-09-09 2019-10-08 Bank Of America Corporation System for generating a transaction specific tokenization for a wearable device
US10542000B2 (en) 2014-10-17 2020-01-21 Alibaba Group Holding Limited Systems and methods for interaction among terminal devices and servers
US10817862B2 (en) 2015-09-01 2020-10-27 Bank Of America Corporation System for authenticating a mobile device for comprehensive access to a facility

Families Citing this family (11)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB201105765D0 (en) 2011-04-05 2011-05-18 Visa Europe Ltd Payment system
CA2931093A1 (en) * 2013-12-19 2015-06-25 Visa International Service Association Cloud-based transactions methods and systems
US9922322B2 (en) 2013-12-19 2018-03-20 Visa International Service Association Cloud-based transactions with magnetic secure transmission
US12469021B2 (en) 2014-02-18 2025-11-11 Visa International Service Association Limited-use keys and cryptograms
WO2015179637A1 (en) 2014-05-21 2015-11-26 Visa International Service Association Offline authentication
US9775029B2 (en) 2014-08-22 2017-09-26 Visa International Service Association Embedding cloud-based functionalities in a communication device
CN108028758B (zh) 2015-08-31 2021-06-25 三星电子株式会社 在通信系统中下载简档的方法和装置
CN105827656B (zh) * 2016-05-30 2019-08-02 宇龙计算机通信科技(深圳)有限公司 基于nfc支付的身份认证方法及装置
BR112018076196A2 (pt) 2016-07-11 2019-03-26 Visa International Service Association método, e, dispositivos de comunicação portátil e de acesso.
US11775657B2 (en) * 2020-10-15 2023-10-03 Microsoft Technology Licensing, Llc Systems and methods for enhancing security of device-internal encryption with externally generated entropy
GB2611806A (en) * 2021-10-15 2023-04-19 Mastercard International Inc Chip authentication

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20070093530A (ko) 2006-03-14 2007-09-19 최명렬 고속 비접촉식 지불 처리 방법 및 시스템과 이를 위한기록매체
KR20100024605A (ko) * 2008-08-26 2010-03-08 충남대학교산학협력단 Ｒｓａ기반 패스워드 인증을 통한 세션키 분배방법
JP2011258070A (ja) * 2010-06-10 2011-12-22 Sony Corp 通信装置、通信方法、及び、通信システム
KR101148543B1 (ko) * 2007-10-09 2012-05-23 알카텔-루센트 유에스에이 인코포레이티드 통신 인증 방법 및 네트워크 수립 방법
KR20120121199A (ko) * 2011-04-26 2012-11-05 허용회 해시를 이용한 가상카드 운영 방법 및 시스템

Family Cites Families (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001148744A (ja) * 1999-09-07 2001-05-29 Nippon Telegr & Teleph Corp <Ntt> 位置情報サービスシステム、位置情報サービスシステムにおける位置情報利用方法、及び、発信端末
KR100933387B1 (ko) * 2000-04-24 2009-12-22 비자 인터내셔날 써비스 어쏘시에이션 온라인 지불인 인증 서비스
US20020038287A1 (en) * 2000-08-30 2002-03-28 Jean-Marc Villaret EMV card-based identification, authentication, and access control for remote access
JP2002312741A (ja) * 2001-04-10 2002-10-25 Ntt Data Corp Ｉｃカード及びプログラム
MXPA04008973A (es) * 2002-03-19 2005-02-17 Mastercard International Inc Metodo y sistema para llevar a cabo una transaccion utilizando un dispositivo de proximidad.
FR2893797A1 (fr) * 2005-11-23 2007-05-25 Proton World Internatinal Nv Personnalisation d'une carte bancaire pour d'autres applications
JP4868947B2 (ja) * 2006-06-05 2012-02-01 株式会社日立製作所 生体認証装置と生体認証システム及びｉｃカード並びに生体認証方法
JP2007328481A (ja) * 2006-06-07 2007-12-20 Dainippon Printing Co Ltd Ｉｃカード、ｉｃカードのプログラム、端末装置、プログラム及びｉｃカードシステム
US8892887B2 (en) 2006-10-10 2014-11-18 Qualcomm Incorporated Method and apparatus for mutual authentication
JP2009276916A (ja) * 2008-05-13 2009-11-26 Sony Corp 通信装置、通信方法、リーダライタ及び通信システム
JP5644194B2 (ja) * 2010-06-10 2014-12-24 株式会社リコー 情報保護装置及び情報保護プログラム
GB201105765D0 (en) * 2011-04-05 2011-05-18 Visa Europe Ltd Payment system

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20070093530A (ko) 2006-03-14 2007-09-19 최명렬 고속 비접촉식 지불 처리 방법 및 시스템과 이를 위한기록매체
KR101148543B1 (ko) * 2007-10-09 2012-05-23 알카텔-루센트 유에스에이 인코포레이티드 통신 인증 방법 및 네트워크 수립 방법
KR20100024605A (ko) * 2008-08-26 2010-03-08 충남대학교산학협력단 Ｒｓａ기반 패스워드 인증을 통한 세션키 분배방법
JP2011258070A (ja) * 2010-06-10 2011-12-22 Sony Corp 通信装置、通信方法、及び、通信システム
KR20120121199A (ko) * 2011-04-26 2012-11-05 허용회 해시를 이용한 가상카드 운영 방법 및 시스템

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2940642A4

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10542000B2 (en) 2014-10-17 2020-01-21 Alibaba Group Holding Limited Systems and methods for interaction among terminal devices and servers
US11012440B2 (en) 2014-10-17 2021-05-18 Advanced New Technologies Co., Ltd. Systems and methods for interaction among terminal devices and servers
US11496473B2 (en) 2014-10-17 2022-11-08 Advanced New Technologies Co., Ltd. Systems and methods for interaction among terminal devices and servers
US11665160B2 (en) 2014-10-17 2023-05-30 Advanced New Technologies Co., Ltd. Systems and methods for interaction among terminal devices and servers
FR3037424A1 (fr) * 2015-06-15 2016-12-16 Ingenico Group Procede de detection d'un terminal frauduleux par un cryptogramme, dispositif et programme correspondants
EP3107023A1 (fr) * 2015-06-15 2016-12-21 Ingenico Group Procédé, dispositif et programme d'authentification sans fil d'un terminal de payment
US10360560B2 (en) 2015-09-01 2019-07-23 Bank Of America Corporation System for authenticating a wearable device for transaction queuing
US10817862B2 (en) 2015-09-01 2020-10-27 Bank Of America Corporation System for authenticating a mobile device for comprehensive access to a facility
US10438201B2 (en) 2015-09-09 2019-10-08 Bank Of America Corporation System for generating a transaction specific tokenization for a wearable device
US10127539B2 (en) 2015-09-30 2018-11-13 Bank Of America Corporation System for tokenization and token selection associated with wearable device transactions
US10153056B2 (en) 2016-05-09 2018-12-11 Bank Of America Corporation System for a geographic location based sharing request network
US10629300B2 (en) 2016-05-09 2020-04-21 Bank Of America Corporation Geographic selection system based on resource allocation and distribution

Also Published As

Publication number Publication date
US20150332261A1 (en) 2015-11-19
JP2016503992A (ja) 2016-02-08
EP2940642A4 (en) 2016-08-17
CN105009154A (zh) 2015-10-28
EP2940642A1 (en) 2015-11-04
KR101330867B1 (ko) 2013-11-18

Similar Documents

Publication Publication Date Title
KR101330867B1 (ko) 결제 디바이스에 대한 상호인증 방법
JP7345509B2 (ja) 安全な読み取り専用の認証のためのシステム及び方法
AU2023203952B2 (en) Steganographic image encoding of biometric template information on a card
US12218953B2 (en) Binding cryptogram with protocol characteristics
US20100163618A1 (en) Transaction method with e-payment card and e-payment card
JP2021528746A5 (ko)
CN116233836B (zh) 用于中继攻击检测的方法和系统
KR20090086979A (ko) 프록시 인증 방법 및 장치
TWI872305B (zh) 用於公鑰/私鑰驗證之裝置、系統及方法
JP2015525386A (ja) 支払い装置、支払いシステムおよび支払い方法
KR20200022194A (ko) 사용자가 소지한 금융 카드 기반 본인 인증 시스템 및 방법
KR20200103615A (ko) 사용자가 소지한 금융 카드 기반 본인 인증 시스템 및 방법
WO2024182284A1 (en) Reader and encryption device binding with computer
CN102301384A (zh) 用于信用卡的安全措施
WO2021054854A1 (ru) Создание и использование доверенного цифрового образа документа
JP2016212484A (ja) Ｉｃ情報媒体サービス処理システム

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

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2015551041

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 14758459

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2012890943

Country of ref document: EP