JP7516133B2 - Payment Device - Google Patents

Description

The present invention relates to a payment device and a key injection program, and in particular to a payment device and a key injection program for card payments.

2. Description of the Related Art Conventionally, there have been various types of payment devices used for performing payment processing using card-shaped recording media (hereinafter simply referred to as "cards").
As an example of such a conventional payment device, Patent Document 1 describes an automated transaction device that processes accepted cards, which are accepted cards. The automated transaction device in Patent Document 1 includes a card information acquisition unit that acquires card information stored in the accepted card, an identification unit that identifies the type of the accepted card from the card information, a type information acquisition unit that acquires type information indicating the type of the card to be accepted, and a processing unit that executes processing on the card information based on the processing information switched by the processing setting unit.

Here, some conventional payment devices (hereinafter referred to as "payment devices") include a card reader that actually reads the card and a pin pad for inputting a PIN number, both of which are connected separately to a higher-level device such as a host PC (Personal Computer).

In such a conventional payment device, device authentication is performed between the upper device and each payment device using a common key cipher. Then, in a state where this device authentication is performed, payment information such as a card number and a personal identification number (PIN) information encrypted using the common key cipher is transmitted from each payment device to the upper device.
The higher-level device that receives this information first decrypts the payment information using this common key encryption, and then re-encrypts and transmits the information to a higher-level server or the like for payment.

JP 2019-109723 A

However, in recent years, due to security and legal requirements, protection of card information has become mandatory, and it has become impossible to perform device authentication using common key encryption between the host device and each payment device. This is because it was considered problematic that the host device contains plaintext card information and PIN, and a common key that can decrypt the encrypted card information and PIN.

The present invention was made in consideration of the above circumstances, and aims to provide a payment device capable of performing device authentication between payment devices, thereby resolving the above-mentioned problems.

The payment device of the present invention is a payment device for card payments, and comprises a relay board connected to a higher-level device, and a payment device for card payments connected to the relay board, wherein the relay board includes an equipment key generation unit that generates an equipment encryption key according to equipment information acquired from the payment device, an equipment key registration unit that registers the equipment encryption key generated by the equipment key generation unit into the payment device, an equipment authentication unit that authenticates the payment device using the equipment encryption key registered into the payment device by the equipment key registration unit, an information acquisition unit that acquires payment information from the payment device authenticated by the equipment authentication unit, and a payment notification unit that encrypts the payment information acquired by the information acquisition unit with a payment key for payment processing and notifies the higher-level device.
By configuring it in this manner, device authentication can be performed between the payment device and the relay board.

The payment device of the present invention is characterized in that the payment equipment includes at least one of a card reader that acquires information about a card as the payment information, and an authentication device that acquires authentication information as the payment information.
With this configuration, payment information is sent and received only between the relay board and the card reader or authentication device, thereby improving security.

In the payment device of the present invention, the device key generation section generates and holds different device encryption keys for the card reader and the authenticated device, using different pieces of device information.
With this configuration, it is possible to provide a device encryption key that is unique to the device.

The payment device of the present invention is characterized by further comprising a payment key acquisition unit that acquires the payment key using an encryption method similar to that specified for distribution of the payment key via a network.
With this configuration, it is possible to inject a payment key even in a place that is not designated as a security area.

According to the present invention, a payment device capable of performing device authentication between payment devices can be provided by generating a device encryption key in a relay board to which a payment device is connected according to device information acquired from the payment device, registering the generated device encryption key in the payment device, and authenticating the device using the registered device encryption key.

1 is a system configuration diagram of a payment system according to an embodiment of the present invention. FIG. 2 is a functional configuration diagram of the settlement device shown in FIG. 1 . FIG. 2 is a functional configuration diagram of the key injection device shown in FIG. 1 . 5 is a flowchart of a device key registration process according to the embodiment of the present invention. 10 is a flowchart of a payment process according to an embodiment of the present invention. 13 is a flowchart of a payment key injection process according to an embodiment of the present invention. 7 is an example of a screen for the payment key injection process shown in FIG. 6.

<Embodiment>
[System configuration of payment system X]
The configuration of a payment system X according to an embodiment of the present invention will be described with reference to Fig. 1. The payment system X includes a payment device 1, a higher-level device 2, a server 3, and a key injection device 5.
In this embodiment, the payment device 1, the higher-level device 2, and the key injection device 5 are connected together via a LAN (Local Area Network) such as a USB (Universal Serial Bus), RS-232C, or Ethernet (registered trademark).
Furthermore, in this embodiment, the higher-level device 2 of the payment system X is connected to a server 3 for performing credit card payments via a dedicated line or a WAN (Wide Area Network) such as the Internet.

The settlement device 1 is controlled by the higher-level device 2, and is a settlement device for card settlement that makes payments (settlements) with credit cards and other types of cards 4.
The configuration of the payment device 1 in this embodiment will be described later.

The higher-level device 2 may be, for example, a personal computer (PC) for payments, a point of sales (POS) terminal, an automated teller machine (ATM), a payment terminal in a hospital or the like, other terminals for settlement (payment), a kiosk terminal, a ticket issuing system for transportation, a point card payment system in a convenience store or the like, a member card issuing system in a retail store, a card issuing and payment system for amusement machines, an entrance and exit management system, etc. (hereinafter referred to simply as "ATM, etc.").

The server 3 is a secure server, general-purpose computer, or the like that provides a service for making credit card payments.
The server 3 may be connected to servers of other banks, card companies, etc. Also, various other information regarding the payment can be obtained from the server 3 and other servers.

The card 4 may be a card-shaped magnetic recording medium such as a rectangular vinyl chloride card having a thickness of about 0.7 to 0.8 mm, an IC card, a non-contact IC card, or the like. In the case of a magnetic recording medium, a magnetic stripe in which a magnetic signal is stored is formed on one side of the card 4. In the case of an IC card, the card 4 may include, for example, a contact, an electromagnetic induction antenna, and an IC chip including a ROM (Read Only Memory) and an MPU (Micro Processing Unit). In the case of a non-contact IC card, a R/W (Read/Write) antenna for short-distance wireless communication is built in. The card 4 may be a recording medium that combines any or all of these. Furthermore, the card 4 may be a PET (polyethylene terephthalate) card having a thickness of about 0.18 to 0.36 mm, a paper card having a predetermined thickness, or the like. In addition, a mobile terminal such as a mobile phone or a smartphone used by a user may also be used as the card 4 for transactions.
In this embodiment, an example will be described in which the card 4 is a magnetic IC card including a magnetic stripe and an IC chip.

The key injection device 5 is a dedicated PC or other terminal that is connected to the payment device 1 when the payment device 1 is manufactured and shipped from the factory, when it is undergoing maintenance, etc. (hereinafter simply referred to as "shipment from the factory, etc."). The key injection device 5 stores the payment key 440, which will be described later, in the relay board 10 of the payment device 1 (hereinafter also referred to as "injecting" the payment key 440). For this reason, when the payment device 1 and the higher-level device 2 are actually connected to perform a payment, the key injection device 5 does not need to be connected.

In addition, in this embodiment, the higher-level device 2 may be connected to a business server for settlement (not shown). This business server is a business server for transportation facilities, hospitals, retail stores, service providers, etc.

Here, a detailed configuration of the payment device 1 in this embodiment will be described.
The settlement device 1 is composed of a relay board 10 connected to a higher-level device 2, and a settlement device for card settlement. In this embodiment, an example is shown in which a card reader 20 and a pin pad 30 are used as the settlement device.

The relay board 10 is a board that is connected to the higher-level device 2, the card reader 20, and the pin pad 30. The relay board 10 includes a dedicated device for performing EMV (Europay, MasterCard, VISA protocol) payments. The relay board 10 acquires payment information related to the card 4 and controls the payment process. The relay board 10 also performs processing to protect card information for security and legal reasons, encrypts the payment information using a payment key 440 (described later), and transmits the information to the higher-level device 2.

The card reader 20 is an example of a device that acquires information about the card 4 as payment information. Specifically, the card reader 20 is a manual or motor-driven card reader/writer device that reads or writes information from the card 4, which is, for example, a magnetic IC card. In the manual type, the user manually inserts the card 4 into the device and pulls out the card 4 from the device to reproduce data recorded on the card 4. In the motor-driven type, the card reader 20 transports and reads/writes the card 4 in response to a command sent via the relay board 10.
In this embodiment, the card reader 20 acquires the card information 432 (FIG. 2) of the card 4 as payment information, and transmits and receives the card information to and from the relay board 10. At this time, device authentication is performed between the card reader 20 and the relay board 10.

The pin pad 30 is an example of an authentication device that acquires authentication information such as a PIN (Personal Identification Number, PIN) or a personal identification number as payment information. In other words, the pin pad 30 is a device that includes a numeric keypad or the like for inputting authentication information when the information on the card 4 is read during payment. Alternatively, in addition to or instead of the pin pad 30, it is also possible to use an authentication device (hereinafter referred to as a "biometric authentication device") that inputs biometric information such as a fingerprint, vein pattern, iris pattern, or a camera for facial authentication.

(Control configuration of payment device 1)
Next, the control configuration of the settlement device 1 will be described with reference to FIG.
The relay board 10 includes a control unit 11 and a memory unit 12 .
The card reader 20 includes a control unit 21 , a memory unit 22 , and a reading unit 23 .
The pin pad 30 comprises a control unit 31, a memory unit 32, an input unit 33, and a display unit .

The control units 11, 21, and 31 are control and calculation means that control the relay board 10, the card reader 20, and the pin pad 30, respectively. The control units 11, 21, and 31 include, for example, a CPU (Central Processing Unit), an MPU (Micro Processing Unit), a DSP (Digital Signal Processor), an ASIC (Application Specific Integrated Circuit), a GPU (Graphics Processing Unit), etc. The control units 11, 21, and 31 may also include an accelerator circuit or the like for high-speed encryption and decryption.

The memories 12, 22, and 32 are recording media that store various setting values, control programs, key information, payment information, temporary data, and the like for the relay board 10, card reader 20, and pin pad 30, respectively. The control programs are firmware and the like for controlling each device and reading and writing to the card 4. These control programs also include an OS (Operating System), various application software (hereinafter simply referred to as "apps"), and middleware that relays between the payment device 1 and the higher-level device 2.

The storage units 12, 22, and 32 include a volatile recording medium such as a RAM, and a non-volatile recording medium such as a ROM.
Among these, the ROM includes recording media such as flash memory, EEPROM, ReRAM, and FeRAM.

The reading unit 23 is a reading means for reading the recorded information of the card 4. In this embodiment, the reading unit 23 includes a magnetic head and an IC contact. In addition, the reading unit 23 may also include a receiving circuit and an antenna for NFC (Near-Field Communications).
The reading unit 23 reads and reproduces the recorded information written on the magnetic stripe of the card 4 as a magnetic signal using a magnetic head. In addition, the reading unit 23 may also be capable of writing recorded information to the magnetic stripe of the card 4. The magnetic signal of the magnetic stripe of the card 4 read by the reading unit 23 is output as an analog signal, and is converted to recorded information of a digital signal by a magnetic information processing circuit (not shown) and output. Here, the reading unit 23 may be an encryption magnetic head incorporating an encryption circuit or MPU that encrypts the recorded information. In the case of IC contacts and NFC, the reading unit 23 is capable of activating the IC chip of the card 4 to communicate and reading and writing the recorded information of the card 4.

The input unit 33 is an operation input means including, for example, an enclosed touch panel or buttons such as a numeric keypad.

The display unit 34 is a display for displaying the status of a transaction, an input number, etc. The display unit 34 may be, for example, an LED (Light Emitting Diode), a liquid crystal display, an organic EL display, a vacuum fluorescent display, or the like.
The input unit 33 and the display unit 34 may be integrally formed, such as a touch panel display. Alternatively, the pin pad 30 may have only an LED as the display unit 34, or may not have a display unit 34 at all.

In addition to these, the payment device 1 also includes various buttons and dip switches for setting up, and interfaces such as USB and RS-232C for connecting to the higher-level device 2. Furthermore, the payment device 1 may include a printing device that uses a thermal method, a dot impact method, an inkjet method, or the like. This printing device may record information about the payment on recording paper such as a receipt or invoice using an ink ribbon or liquid ink, etc.

In the payment device 1, each payment device may be configured integrally with the relay board 10 or may be separately connected via a cable or the like.

(Functional configuration of payment device 1)
Next, the functional configuration of the payment device 1 will be described with reference to FIG.
The control unit 11 of the relay board 10 includes an apparatus key generation unit 100 , an apparatus key registration unit 110 , an apparatus authentication unit 120 , an information acquisition unit 130 , a payment notification unit 140 , and a payment key acquisition unit 150 .
The storage unit 12 stores device information 401 , a unique key 410 , a device encryption key 422 , a device encryption key 423 , and a payment key 440 .
The control unit 21 of the card reader 20 includes a key payment control unit 200 .
The storage unit 22 stores device information 402 , a unique key 410 , a device encryption key 422 , and card information 432 .
The control unit 31 of the PIN pad 30 includes a key payment control unit 300 .
The storage unit 32 stores device information 403 , a unique key 410 , a device encryption key 423 , and PIN information 433 .

The device key generating unit 100 generates device encryption keys 422, 423 according to device information 402, 403 acquired from the payment device. In this embodiment, the device key generating unit 100 generates different device encryption keys 422, 423 for the card reader 20 and the PIN pad 30, respectively, using different device information 402, 403. The device key generating unit 100 stores the generated device encryption keys 422, 423 in the memory unit 12 in association with the card reader 20 and the PIN pad 30, respectively.

The device key registration unit 110 registers the device encryption keys 422 and 423 generated by the device key generation unit 100 in the payment device. In this embodiment, the device key registration unit 110 stores the device encryption key 422 in the memory unit 22 of the card reader 20 and the device encryption key 423 in the memory unit 32 of the PIN pad 30.

The device authentication unit 120 authenticates the payment device using the device encryption keys 422, 423 registered in the payment device by the device key registration unit 110. In this embodiment, the device authentication unit 120 performs authentication by comparing the device encryption key 422 stored in the memory unit 12 with the device encryption key 422 acquired from the card reader 20. Alternatively, the device authentication unit 120 performs authentication by comparing the device encryption key 423 stored in the memory unit 12 with the device encryption key 423 acquired from the PIN pad 30.

The information acquisition unit 130 acquires payment information from a payment device authenticated by the device authentication unit 120. In this embodiment, the information acquisition unit 130 acquires card information 432 from the card reader 20 and PIN information 433 from the PIN pad 30.

The payment notification unit 140 encrypts the payment information acquired by the information acquisition unit 130 using a payment key 440 for payment processing and notifies the upper device. Furthermore, the payment notification unit 140 can also acquire payment result data, which is the result of the payment, from the server 3 via the upper device 2 and display it on the display unit 34 of the PIN pad 30. In this way, the payment notification unit 140 executes the processing related to the payment.

The payment key acquisition unit 150 acquires the payment key 440 using the same encryption method as that specified for distributing the payment key 440 via the network. In this embodiment, the payment key acquisition unit 150 acquires the payment key 440 encrypted using the TR31 method based on the unique key 410 from the key injection device 5 and stores it in the memory unit 12.

Equipment information 401, 402, and 403 are device-specific information for relay board 10, card reader 20, and pin pad 30, respectively. Device information 401, 402, and 403 may include, for example, model name, device type, serial number, destination, and other information for identifying the device.

The unique key 410 is key information used when exchanging or injecting key information in the payment device 1 at the time of shipment from the factory or at initial settings. The unique key 410 may be set to different key information depending on, for example, the model or destination. In this embodiment, the unique key 410 is used when storing the generated device encryption keys 422 and 423 or when injecting the payment key 440.

The device encryption keys 422 and 423 are key information for device authentication that is set for each payment device. In this embodiment, the device encryption key 422 is key information for a unique common encryption key generated by a hash calculation based on the device information 402 of the card reader 20. Similarly, the device encryption key 423 is key information for a unique common encryption key generated based on the device information 403 of the PIN pad 30.

Card information 432 is an example of payment information in this embodiment. Card information 432 is recorded information of card 4. This recorded information may include, for example, the value of the card number, etc.

PIN information 433 is an example of payment information in this embodiment. PIN information 433 may be, for example, a value such as the pin or personal identification number of card 4 entered by the user. Alternatively, in the case of a biometric authentication device, PIN information 433 may be biometric information or information that has been processed from biometric information.

The settlement key 440 is key information of an encryption key with high security for transmitting the settlement information of the card. The settlement key 440 may be, for example, an encryption key (DUKPT encryption key) that complies with the provisions for transmitting the settlement information of the card in the Delivered Unique Key Per Transaction (DUKPT) protocol.
In this embodiment, an example will be described in which the payment key 440 is injected by the key injection device 5 at the time of shipment from a factory, etc. The payment key 440 may be obtained from a payment key server (not shown) or the like by encryption using the TR31 method, etc.

Here, the control unit 11 of the relay base station functions as a device key generation unit 100, a device key registration unit 110, a device authentication unit 120, an information acquisition unit 130, a payment notification unit 140, and a payment key acquisition unit 150 by executing a control program including firmware, etc. stored in the memory unit 12.
The control unit 21 of the card reader 20 functions as a key payment control unit 200 by executing a control program including firmware and the like stored in the memory unit 22 .
The control unit 31 of the PIN pad 30 functions as a key payment control unit 300 by executing a control program including firmware and the like stored in the memory unit 32 .

(Control Configuration of Key Injection Device 5)
Next, the control configuration of the key injection device 5 will be described with reference to Fig. 3. In Fig. 3, the same reference numerals as in Fig. 2 indicate similar functional configurations, and therefore the description thereof will be omitted.

The key injection device 5 includes a control unit 51 and a memory unit 52.

The control unit 51 is a control and calculation means that controls the entire key injection device 5. The control unit 51 includes, for example, a CPU, an MPU, a DSP, an ASIC, a GPU, etc. The control unit 51 may also include an accelerator circuit for quickly encoding and decoding encryption codes.

The storage unit 52 is a recording medium that stores various setting values, control programs, key data, payment information, temporary data, etc. The control programs include the OS, device drivers for the payment device 1, middleware, and the key injection program 460 described later.

The storage unit 52 includes a volatile recording medium such as a RAM, and a non-volatile recording medium such as a ROM. Of these, ROM includes, for example, a flash memory, an EEPROM, a ReRAM, an FeRAM, and other recording media.

(Functional configuration of the key injection device 5)
Next, the functional configuration of the key injection device 5 will be described.
The control unit 51 includes a payment key transmission unit 500 and a log recording unit 510 .
The memory unit 52 includes a payment key 440 , a unique key 410 , log information 450 , and a key injection program 460 .

The payment key transmission unit 500 acquires device information 401 of the relay board 10, which is a payment device, encrypts the payment key 440 associated with the device information 401 using a specified encryption method, and transmits the encrypted payment key 440 to the payment device. This specified encryption method uses an encryption method similar to that specified for distributing the payment key 440 via a network, which is appropriate from the viewpoints of security and law. In this embodiment, an example in which the TR31 method is used as the encryption method will be described.

The log recording unit 510 records the transmitted payment key 440 and the corresponding device information 401 as a log in the log information 450. This log is referenced when the payment key 440 is injected.

In this embodiment, the settlement key 440 is, for example, a group of DUKPT keys provided by a key providing server (not shown) installed by the DUKPT operating company based on the unique key 410 for each destination. This group of keys may be, for example, an Initial PIN Encryption Key (IPEK) file provided in a format such as a CSV (comma-separated, tab-separated) file, which is mainly a text file.

Log information 450 is log (history) information recorded by log recording unit 510. In this embodiment, log information 450 is set, for example, corresponding to the CSV file of payment key 440 described above.

The key injection program 460 is an application installed on the OS for injecting key data into the payment device 1.

Here, the control unit 51 of the key injection device 5 functions as a payment key transmission unit 500 and a log recording unit 510 by executing a control program including the key injection program 460 stored in the memory unit 52.

The data stored in the storage units 12, 22, 32, and 52 may be variable depending on the processing state, procedure, and the like.
In addition, some or all of the functional units can be configured in hardware using programmable logic such as a field-programmable gate array (FPGA).

Below, we will first explain each process, starting with the device key registration process that is executed when the payment device 1 is powered on or when it is initially started up after initialization, and then the payment process that is executed when actually making a payment. After that, we will also explain the payment key injection process that is executed only when the device is shipped from the factory, etc.

[Device key registration process]
First, the device key registration process according to the embodiment of the present invention will be described with reference to FIG.
In the process of this embodiment, device encryption keys 422, 423 are generated according to device information 402, 403 acquired from the payment devices, the card reader 20 and the PIN pad 30. The generated device encryption keys 422, 423 are then registered in the card reader 20 and the PIN pad 30, respectively, and confirmed.
In the device key registration process of this embodiment, the control units 11, 21, and 31 mainly execute control programs (not shown) stored in the storage units 12, 22, and 32, respectively, in cooperation with the respective units, using hardware resources.
The device key registration process will be described in detail below for each step with reference to the flowchart in FIG.

(Step S101)
First, the device key generating unit 100 of the relay board 10 performs device information request processing.
When initial settings are required, such as when the payment device 1 is connected to the higher-level device 2 and started up for the first time, the higher-level device 2 sends a command to the relay board 10 to generate and register a common encryption key.
The device key generating section 100 of the relay board 10 receives this, checks the connection of the card reader 20 and the pin pad 30, and transmits a command to each device to instruct them to transmit device information 402, 403.

(Step S201)
Next, the key payment control unit 200 of the card reader 20 or the key payment control unit 300 of the PIN pad 30 performs device information transmission processing.
The key payment control unit 200 of the card reader 20 transmits the device information 402 to the relay board 10 .
The key payment control unit 300 of the pin pad 30 transmits the device information 403 to the relay board 10 .

(Step S102)
Next, the device key generating section 100 of the relay board 10 performs device key generation processing.
The device key generation unit 100 performs a hash operation on the device information 402, 403 to generate device encryption keys 422, 423 which are unique common encryption keys corresponding to the device information 402, 403. Specifically, the device key generation unit 100 can calculate the device information 402, 403 using various hash functions that generate irregular, fixed-length bit strings from the bit strings of the device information 402, 403. The device key generation unit 100 stores the calculated device information 402, 403 in the storage unit 12.

(Step S103)
Next, the device key registration section 110 performs device key registration processing.
The device key registration section 110 encrypts the device encryption keys 422, 423 that have been generated and stored in the storage section 12 with the unique key 410, and transmits them to the card reader 20 and the pin pad 30, respectively, for registration.
At this time, device key registration section 110 also generates a random number for confirming the key registration, encodes this random number with unique key 410, and transmits it to card reader 20 and PIN pad 30, respectively.

(Step S202)
Next, the key payment control unit 200 of the card reader 20 or the key payment control unit 300 of the PIN pad 30 performs an equipment key storage process.
The key payment control unit 200 of the card reader 20 acquires the device encryption key 422 and registers it by storing it in the memory unit 22. At this time, the key payment control unit 200 also acquires a random number and temporarily stores it in the memory unit 22.
The key payment control unit 300 of the PIN pad 30 similarly obtains the device encryption key 423 and registers it by storing it in the memory unit 32. At this time, the key payment control unit 300 also obtains a random number and temporarily stores it in the memory unit 32.

(Step S203)
Next, the key payment control unit 200 of the card reader 20 or the key payment control unit 300 of the PIN pad 30 performs a random number encoding process.
The key payment control unit 200 of the card reader 20 encodes the acquired random number using the device encryption key 422 and transmits it to the relay board 10 .
The key payment control unit 300 of the pin pad 30 similarly encodes the acquired random number using the device encryption key 423 and transmits it to the relay board 10 .

(Step S104)
Next, the device key registration unit 110 of the relay board 10 performs a random number verification process.
Device key registration unit 110 decrypts the random numbers sent from card reader 20 and PIN pad 30 with device encryption keys 422 and 423, respectively, and confirms that they are the same as the generated random numbers. This confirmation makes it possible to confirm that device encryption keys 422 and 423 have been registered, and that the connected payment device is not an unauthorized one.
This completes the device key registration process according to the embodiment of the present invention.

[Payment Processing]
Next, the settlement process according to the embodiment of the present invention will be described with reference to FIG.
In the payment process of this embodiment, the payment device 1 authenticates the payment devices, the card reader 20 and the PIN pad 30, using device encryption keys 422, 423 registered in the payment devices. Then, card information 432 and PIN information 433 are obtained from the authenticated card reader 20 and PIN pad 30. Then, the card information 432 and PIN information 433 are encrypted using a payment key 440 and notified to the higher-level device 2, which then performs the payment process.
In the payment process of this embodiment, in the payment device 1, the control units 11, 21, and 31 execute a control program (not shown) stored in the storage units 12, 22, and 32 by using hardware resources in cooperation with each unit. In the higher-level device 2 and the server 3, the control units also execute a control program stored in the storage units by using hardware resources in cooperation with each unit.
The payment process of this embodiment will be explained below step by step with reference to the flowchart of FIG.

(Step S111)
First, the equipment authentication unit 120 performs equipment authentication processing.
After the settlement is started, the higher-level device 2 transmits a device authentication command.
The device authentication unit 120 of the relay board 10 that receives this generates, for example, a random number and instructs the card reader 20 and the pin pad 30 to encrypt this random number using a hash function or the like using the registered device encryption keys 422, 423, respectively, and then transmit it.
In response to this, the card reader 20 and the pin pad 30 encrypt the random numbers with the device encryption keys 422 and 423, respectively, and transmit the encrypted random numbers.

Device authentication unit 120 calculates values by encrypting the generated random numbers using device encryption keys 422, 423 stored in memory unit 12 with a hash function or the like. Device authentication unit 120 then compares these values with values encrypted with device encryption keys 422, 423 acquired from card reader 20 and PIN pad 30, respectively. That is, device authentication unit 120 compares whether device encryption keys 422, 423 registered in the payment device and pairs of values actually acquired from the payment device are the same. If the pairs of values are the same, device authentication unit 120 determines that authentication is successful. On the other hand, if the values of any of the pairs are not the same, the payment device is not normal, so it is determined that a fraudulent act such as tampering has occurred, and authentication is determined to have failed.
This device authentication process only needs to be performed once at startup to check whether the correct card reader 20 and pin pad 30 are connected, and does not need to be performed every time a payment is made.

(Step S112)
Next, the device authentication unit 120 judges whether the authentication is successful. If the authentication is successful for all the payment devices, the device authentication unit 120 judges Yes. In this embodiment, the device authentication unit 120 judges Yes if the authentication is successful for both the card reader 20 and the PIN pad 30. In other cases, the device authentication unit 120 judges No.
If the answer is Yes, the device authentication unit 120 transmits information to the higher-level device 2 indicating that the authentication was successful and that a normal payment device is connected, and then the payment start process proceeds to step S211 described below. After this process, the device authentication unit 120 advances the process to step S113, as described below.
If the answer is No, the equipment authentication unit 120 transmits an error to the higher-level device 2 and ends the payment process. After that, it may be possible to disable payments using the payment device 1 until a predetermined maintenance is performed.

(Step S211)
If the authentication is successful, the higher-level device 2 performs a payment start process.
The higher-level device 2 causes the display unit 34 of the PIN pad 30 to display an instruction to insert a credit card and input PIN information 433 .
Then, the higher-level device 2 transmits a command to acquire the card information 432 and the PIN information 433 of the credit card to the settlement device 1. As a result, the higher-level device 2 waits for the reading of the credit card and the input of the PIN.

(Step S113)
Here, the information acquisition unit 130 of the payment device 1 performs information acquisition processing.
The information acquisition unit 130, which receives a command from the higher-level device 2, acquires payment information from the authenticated payment device.
Specifically, the card reader 20 is set to a state of waiting for reading of a credit card. When the card 4 is inserted, the information acquisition unit 130 acquires the card information 432 read by the reading unit 23 as payment information.
Furthermore, the PIN pad 30 waits for input of PIN information 433. The information acquisition unit 130 acquires the PIN information 433 inputted by the input unit 33 as payment information.

(Step S114)
Next, the payment notification unit 140 of the payment device 1 performs a payment notification process.
The payment notification unit 140 encrypts the payment information using a payment key 440 and notifies the higher-level device 2 of the encrypted information.
Specifically, the payment notifying unit 140 encrypts the card information 432 acquired from the card reader 20 and the PIN information 433 acquired from the PIN pad 30 using one of the payment keys 440, and transmits the encrypted data to the higher-level device 2. That is, the payment device 1 encrypts the temporarily stored payment information, for example, using DUKPT, and communicates it.
The host device 2 receives this encrypted data and transfers it to the server 3 as is.

(Step S311)
Next, the server 3 performs a payment execution process.
The server 3 obtains the encrypted payment information (encrypted data) obtained by the payment device 1 via the higher-level device 2 and performs payment. At this time, due to security and legal requirements, the higher-level device 2 cannot hold or pass the plaintext card information or the ciphertext card information holding a key that can be decrypted by the higher-level device 2. Conversely, as described above, the DUKPT-encrypted card information may be passed because it cannot be decrypted by the higher-level device 2, and payment can be made in compliance with security and legal requirements.
The server 3 returns the result of this payment to the higher-level device 2 as payment result data.

(Step S212)
Next, the higher-level device 2 performs a result notification process.
When the upper level device 2 and the settlement device 1 acquire the settlement result data, they display the settlement result on the display unit 34 of the pin pad 30, and cause a printer or the like to print a receipt or invoice, etc. This completes the card settlement.
This completes the payment process according to the embodiment of the present invention.

[Payment key injection process]
Next, the key injection process according to the embodiment of the present invention will be described with reference to FIG. 6 and FIG.
As described above, in the key injection process of this embodiment, at the time of shipment from the factory or the like, the key injection device acquires either device information 402, 403 of the payment device, encrypts payment key 440 associated with either device information 402, 403 in the TR31 system, and transmits the encrypted payment key 440 to the payment device. The payment device then acquires and registers payment key 440 in the TR31 system. The key injection device then records the transmitted payment key 440 and the corresponding device information 402, 403 in log information 450.
In this embodiment, the device key registration process is mainly carried out by the control unit 11 of the payment device 1 and the control unit 51 of the key injection device 5, which execute control programs (not shown) stored in the memory unit 12 and the memory unit 52 in cooperation with each unit and using hardware resources.
The payment key injection process of this embodiment will be described below step by step with reference to the flowchart of FIG.

(Step S521)
First, the payment key transmission unit 500 of the key injection device 5 performs device information request processing.
7, when the payment device 1 is shipped from the factory, an operator such as a manufacturing staff member or a maintenance staff member starts the key transmission program. In this embodiment, the key injection program 460 does not have to be started in a special security room or the like.
Here, when the worker presses button B1 in FIG. 7, the IPEK file of the payment key 440 stored in the memory unit 52 or the like can be selected.
When the worker presses the button B2 in FIG. 7, the payment key transmitting unit 500 transmits a command to the connected payment device 1 to instruct it to transmit the device information 401.

(Step S121)
Next, the payment key acquisition unit 150 of the relay board 10 of the payment device 1 performs device information transmission processing.
When the relay board 10 receives a command from the key injection device 5 , it transmits device information 401 .

(Step S522)
Next, the payment key transmission unit 500 of the key injection device 5 performs a payment key transmission process.
The payment key transmission unit 500 acquires the device information 401 of the payment device 1. As a result, in this embodiment, the payment key transmission unit 500 selects the payment key 440 based on the unique key 410 associated with the device information 401 from the key group of the IPEK file.
At this time, the payment key transmitting unit 500 checks the log information 450 to determine whether or not the payment key 440 corresponding to this device information 401 has already been transmitted. Specifically, the payment key transmitting unit 500 selects an unused key if the device information 401 is not recorded in the log information 450. If there is a key recorded in the log information 450 that has already been transmitted, the payment key transmitting unit 500 selects that key again.

When the payment key 440 to be transmitted is selected, the button B3 in Fig. 7 becomes selectable. When the worker then presses the button B1 in Fig. 7, the payment key 440 is transmitted.
Specifically, the payment key transmission unit 500 encrypts the TR 31 using the same encryption method as that specified in the DUKPT for distribution of the payment key 440 via a network as Remote Key Loading. In this embodiment, the payment key transmission unit 500 encrypts the TR 31 using, for example, the same unique key 410 stored in the storage unit 12 or the like of the payment device 1. Then, the payment key transmission unit 500 transmits the encrypted payment key 440 to the payment device.

(Step S122)
Next, the payment key acquisition unit 150 of the relay board 10 performs a payment key 440 acquisition process.
In this embodiment, the payment key acquisition unit 150 acquires the payment key 440 encrypted by the TR31 method. Then, the payment key acquisition unit 150 decrypts this with the unique key 410 and stores it in the storage unit 12. After that, the payment key acquisition unit 150 returns a message to the key injection device 5 indicating that the storage has been completed.
In addition, since the unique key 410 is different for each destination, even if the payment key 440 of the payment device 1 of a different destination is mistakenly acquired, the payment key 440 cannot be decrypted and an error occurs. This makes it possible to prevent erroneous injection into the payment device 1.

(Step S523)
Next, the log recording unit 510 of the key injection device 5 performs a log recording process.
When the log recording unit 510 receives a response from the payment device 1 indicating that the payment key 440 has been stored, the log recording unit 510 records the payment key 440 sent by the key injection device 5 and the corresponding device information 401 as a log in the log information 450.
In this embodiment, the payment key transmission unit 500 sets the values of “used” and “used device information 401” in the row or column corresponding to the transmitted key of the IPEK file as the log information 450. At this time, the ID of the worker who injected the payment key 440, the injection time, the injection location, etc. may also be recorded.
This completes the payment key injection process according to the embodiment of the present invention.

[Major Effects of the Present Embodiment]
With the above configuration, the following effects can be obtained.
In the past, in the technology described in Patent Document 1, common key encryption was used between the host device and the card reader to perform device authentication. Then, the host device acquired the card information encrypted with the common key encryption and the input PIN information to perform payment.
However, due to the revision of the Installment Sales Law, protection of card information is now mandatory when making payments with magnetic IC cards. This means that it is no longer permitted for the host device to hold or pass card information or input PIN information without encrypting it. In other words, the host device can no longer hold the key to decrypt card information or PIN information.
For this reason, in the conventional technology, the host device is unable to perform device authentication between the host device and the card reader.

In contrast, the payment device 1 of the present invention is a payment device for card payment, and includes a relay board 10 connected to a higher-level device, and a payment device for card payment connected to the relay board 10. The relay board 10 is characterized by including a device key generation unit 100 that generates device encryption keys 422, 423 corresponding to either device information 402, 403 acquired from the payment device, a device key registration unit 110 that registers the device encryption keys 422, 423 generated by the device key generation unit 100 in the payment device, a device authentication unit 120 that authenticates the payment device using the device encryption keys 422, 423 registered in the payment device by the device key registration unit 110, an information acquisition unit 130 that acquires payment information from the payment device authenticated by the device authentication unit 120, and a payment notification unit 140 that encrypts the payment information acquired by the information acquisition unit 130 using a payment key 440 for payment processing and notifies the higher-level device.

With this configuration, it becomes possible to perform device authentication between each payment device and the relay board 10 using device unique device encryption keys 422, 423 generated by hash calculation from device information 402, 403 such as serial numbers acquired from the card reader 20 and PIN pad 30 as device encryption keys 422, 423. This makes it possible to provide a payment device 1 that meets security and legal requirements such as the amendment of the Installment Sales Act.

Furthermore, as described above, there is no longer a need to perform device authentication between each card reader 20 and pin pad 30 and the higher-level device 2, and the higher-level device only needs to generate and register device encryption keys 422, 423 to the relay board 10, or send a command to perform device authentication. This means that when developing or running an application for the higher-level device 2, it is no longer necessary to understand encryption specifications, implement encryption algorithms, manage keys, etc., and development and maintenance costs can be reduced.

The payment device 1 of the present invention is characterized in that the payment equipment is an authentication device that includes either a card reader 20 that acquires information about a card as payment information, or a pin pad 30 that acquires authentication information as payment information, etc.
With this configuration, the payment information such as card information 432 and PIN information 433 are transmitted and received only between relay board 10, card reader 20, and PIN pad 30. Furthermore, all payment information to be protected by card information 432 is encrypted with payment key 440 and notified to the higher-level device. This enhances security and satisfies legal requirements.

In addition, if a malicious person replaces the card reader 20 or PIN pad 30 and performs a payment process without registering a common encryption key, an error message can be displayed indicating that the device encryption keys 422 and 423 have not been registered. This makes it possible to detect malicious devices such as skimming devices.

The payment device 1 of the present invention is characterized in that the device key generating section 100 generates and holds different device encryption keys 422, 423 for the card reader 20 and the PIN pad 30, using different device information 402, 403, respectively.
With this configuration, it is possible to provide device-unique device encryption keys 422, 423 corresponding to each payment device. This allows authentication of each payment device individually. Furthermore, it is possible to handle cases where multiple payment devices are attached to or removed from the relay board 10, changing the configuration, thereby improving convenience for users and administrators. Furthermore, even in the event of skimming or the like, it is possible to determine which payment device has a problem, thereby improving security.

Conventionally, card readers 20 that handle payments using EMV credit cards with IC cards have used the DUKPT encryption method. To initialize a terminal using this DUKPT encryption method, it is necessary to inject a different DUKPT encryption key for each terminal. However, the DUKPT encryption key (payment key 440) generated by the operating company must be transported by some means and injected in a secure area within a factory that is strictly set up to prevent the key from leaking, which is time-consuming.

In contrast, the payment device 1 of the present invention is characterized in that it further includes a payment key acquisition unit 150 that acquires the payment key 440 using an encryption method similar to that specified for distributing the payment key 440 via the network.
With this configuration, it becomes possible to inject the payment key 440 into the payment device 1 using the TR31 encryption method used for distributing DUKPT encryption keys over a network. Therefore, key injection can be performed even in places that are not designated as security areas. This makes it possible to reduce the manufacturing costs and labor of the payment device 1.

The key injection program 460 of the present invention is a key injection program executed by a payment device 1 for card payments and a key injection device 5 connected to the payment device, and is characterized in that the key injection device 5 acquires device information 401 of a relay board 10 or the like connected to the payment device 1, transmits a payment key 440 corresponding to the device information 401 to the payment device 1 using an encryption method similar to that specified for distributing the payment key 440 via a network, acquires the payment key 440 using the encryption method by the payment device 1, and records the transmitted payment key 440 and the corresponding device information 401 as a log by the key injection device 5.
This configuration allows key injection to be performed even in places that are not designated as security areas. Furthermore, it makes it possible to manage the history (log) of key injection, which prevents erroneous injection of encryption keys due to carelessness on the part of operators, etc.

Other Embodiments
In the above embodiment, an example has been described in which a hash calculation is used to generate device encryption keys 422 and 423 that are unique to each device.
However, the device encryption keys 422 and 423 may be generated by encryption using a key that is arbitrarily generated from the device information 402 and 403. The encryption method used in this case may be any common key encryption method such as Triple DES, AES, TR-31, etc.
With this configuration, it is possible to prepare device encryption keys 422 and 423 of a more secure common key encryption.

In the above embodiment, an example has been described in which common key cryptography (symmetric key) is used as the device encryption keys 422 and 423 .
However, it is also possible to use a key of an asymmetric algorithm for authentication between the settlement device and the relay board 10. That is, it is also possible to generate a key pair or the like in advance in the relay board 10 using asymmetric key cryptography such as RSA, and to transmit the public key to the card reader 20 or the PIN pad 30 for registration.
With this configuration, for example, it is not necessary for both the relay board 10 and the settlement device to hold a device-unique key, which can further improve security.

In the above embodiment, an example has been described in which the payment key 440 is encrypted and injected in the key injection device 5 .
However, it is also possible to configure the system to read a file of a DUKPT encryption key that has already been encrypted using the TR31 method and transmit a selected payment key 440. In other words, the previously encrypted payment key 440 may be directly injected into the payment device 1.
In the above embodiment, the log information 450 is set in the IPEK file field.
However, the log information 450 may be a separate file.
Furthermore, in the above embodiment, an example has been described in which a DUKPT encryption key is used as the payment key 440, but key information of another encryption method may also be used.
Such a configuration makes it possible to accommodate a flexible device configuration.

In the above embodiment, an example has been described in which a different set of settlement keys 440 is used for each destination.
However, it is also possible to set a key check value (KCV) in the IPEK file, or to set check items according to differences in revisions or firmware. In this case, the payment key 440 may be injected at the user's choice without acquiring the device information 401 of the relay board 10.
Furthermore, it is possible to print or attach information for setting the payment key 440 or firmware to a serial number or two-dimensional barcode on the relay board 10, and read this with the key injection device 5 to inject the payment key 440.
Such a configuration makes it possible to accommodate a flexible configuration.

In the above embodiment, the pin pad 30 including the display unit 34 has been described.
However, it is also possible to use a pin pad that has an input unit 33 such as a numeric keypad but does not have a display unit 34. In this case, the above-mentioned display on the display unit 34 may be displayed as a display screen of the higher-level device 2. For example, when a numeric keypad is pressed, information on the pressed key is notified to the higher-level device 2, and "*" or the like is displayed on the display screen of the higher-level device 2, making it possible to confirm the number of digits to be input.

In the above embodiment, an example has been described in which the key injection device 5 injects the payment key 440 into the payment device 1 including the card reader 20 .
However, it is also possible to perform similar settings other than the payment key 440. For example, firmware settings, communication parameter settings, and the like can be performed as injection of other setting information for the purpose of concealing the performance of the device.

It goes without saying that the configurations and operations of the above-described embodiments are merely examples and can be modified as appropriate without departing from the spirit and scope of the present invention.

1 Payment device 2 Upper device 3 Server 4 Card 5 Key injection device 10 Relay board 11, 21, 31, 51 Control unit 12, 22, 32, 52 Memory unit 20 Card reader 23 Reading unit 30 PIN pad 33 Input unit 34 Display unit 100 Device key generation unit 110 Device key registration unit 120 Device authentication unit 130 Information acquisition unit 140 Payment notification unit 150 Payment key acquisition unit 200, 300 Key payment control unit 401, 402, 403 Device information 410 Unique key 422, 423 Device encryption key 432 Card information 433 PIN information 440 Payment key 450 Log information 460 Key injection program 500 Payment key transmission unit 510 Log recording unit 600 Screen examples B1, B2, B3 Button X Payment system

Claims (4)

A payment device for card payment,
A relay board connected to a higher-level device;
a payment device for card payment, connected to the relay board;
The relay substrate is
a device key generation unit that generates a device encryption key according to device information acquired from the payment device;
a device key registration unit that registers the device encryption key generated by the device key generation unit in the payment device;
a device authentication unit that authenticates the payment device using the device encryption key registered in the payment device by the device key registration unit;
an information acquisition unit that acquires payment information from the payment device authenticated by the device authentication unit;
a payment notification unit that encrypts the payment information acquired by the information acquisition unit with a payment key for payment processing and notifies the higher-level device of the encrypted information. The payment device includes:
The payment device according to claim 1 , further comprising at least one of a card reader that acquires information related to a card as the payment information, and an authentication device that acquires authentication information as the payment information. The device key generation unit
3. The payment device according to claim 2, wherein different device encryption keys are generated and stored for the card reader and the authentication device, using different device information. The payment device according to claim 1 , further comprising a payment key acquisition unit configured to acquire the payment key using an encryption method similar to that specified for distribution of the payment key via a network.

Images