WO2017176051A1

WO2017176051A1 - Method and system for authenticating internet of things device by using mobile device

Info

Publication number: WO2017176051A1
Application number: PCT/KR2017/003740
Authority: WO
Inventors: 우종현; 강봉호; 장형석
Original assignee: (주)이스톰
Priority date: 2016-04-06
Filing date: 2017-04-05
Publication date: 2017-10-12
Also published as: KR20170114990A; KR101801323B1

Abstract

An authentication system is provided, comprising: a device authentication agent, which is installed in an Internet of Things (IoT) device in which a communication module is mounted, for generating first device authentication information for authentication of the IoT device; an authentication server, which is connected to the IoT device via wired or wireless communication, for generating second device authentication information for the authentication of the IoT device; and a mobile agent, which is installed in a user's mobile device and connected to the IoT device and the authentication server through wireless communication, for verifying the IoT device or the authenticity of a message that is determined to be received from the IoT device, on the basis of whether or not the first device authentication information sent from the IoT device matches the second device authentication information sent from the authentication server.

Description

Method and system for authenticating IoT devices using mobile devices

The present invention relates to a method and system for authenticating an Internet of Things (IoT) device using a mobile device.

Recently, a technology that enables payment services to be securely and conveniently performed on a user's smartphone by using a customer's smartphone and IoT devices and cloud services located in the store without using a card in performing a payment at a store. I am in the limelight.

In the existing card transaction, when a customer presents a card at a store (card merchant), the card data is generated using the card reader and the customer's card, and the transaction data is transmitted to the card issuer. If not, it was executed in a way that approves the transaction. This is a closed transaction approval structure in which the card transaction information encrypted with the customer's IC card is generated through the registered store card reader under the premise that the user is the correct card holder, and the information is relayed to the card company through the secure closed network.

In addition, mobile devices such as smartphones and wireless data communication technologies such as NFC (Near-Field Communication) are combined with the EMV network Tokenization specification established by EMV. By converting the number into an actual card number, payments can be made through mobile devices without a credit card.

However, since the card-based transaction induces a card transaction fee to a store (merchant), various services are being developed to replace payment securely at low cost between the person who needs to give money and the recipient.

Nevertheless, the conventional alternative payment technologies are QR code or barcode based payment technology based on the smartphone screen so that they can be used in all customer smartphones regardless of the mobile operating system. The main point is to close the transaction by having the store's Point of Sales (POS) device read the barcode value.

However, barcode-based payment requires complicated code value recognition process between customers and shops according to barcode issuance, and if barcodes from mobile devices are captured by hackers, the barcode is stolen elsewhere within the validity time of issuance. It has a security hole that can be.

Therefore, there is a need for a payment technology that allows a store to perform a convenient and secure payment service using a customer's mobile device in a transaction with a customer. In addition, in a transaction and payment system using IoT devices as a recently adopted technology, a new method for authenticating the authenticity of the IoT device as well as the authenticity of the user is required, thereby enabling more secure mobile transaction and payment. do.

The present invention provides a method for securely and conveniently performing payment services using a mobile device of a customer, an IoT device located in a store, and a cloud service in a store and a customer to perform a product transaction payment without using a card, and secure payment. As a prerequisite for the present invention, an authentication method and a system capable of verifying the authenticity of a payment subject (customer) and the authenticity of a payment object (IoT device as a payment device in a store) are provided.

The present invention is to provide an authentication method and system that can be universally applied in various applications to determine the authenticity of IoT devices using a mobile device and an authentication server.

According to an aspect of the present invention, a device authentication agent is installed in the Internet of Things (IoT) device on which the communication module is mounted, and generates first device authentication information for authentication of the corresponding IoT device; An authentication server connected to the IoT device through wired or wireless communication and generating second device authentication information for authentication of the IoT device; And installed in a user's mobile device and connected to the IoT device and the authentication server through wireless communication, and between the first device authentication information transmitted from the IoT device and the second device authentication information transmitted from the authentication server. An authentication system including a mobile agent for verifying the authenticity of a message determined to be received from the IoT device or the IoT device according to a match is provided.

In an embodiment, the authentication server generates seed information for generating device authentication information, transmits the seed information to the device authentication agent, and uses the seed information and a predetermined algorithm. 2 Create your device credentials,

The device authentication agent may generate the first device authentication information by using the seed information received from the authentication server and the predetermined algorithm.

In an embodiment, the device authentication agent generates seed information for generating device authentication information, transmits the seed information to the authentication server, and uses the seed information and a predetermined algorithm. 1 Create your device credentials,

The authentication server may generate the second device authentication information by using the seed information received from the device authentication agent and the predetermined algorithm.

In an embodiment, the mobile agent generates seed information for generating device authentication information, and transmits the generated seed information to the authentication server.

The authentication server generates the second device authentication information by using the seed information received from the mobile agent and a predetermined algorithm, and transmits the received seed information to the device authentication agent.

The device authentication agent may generate the first device authentication information by using the seed information received from the authentication server and a predetermined algorithm.

In one embodiment, the communication module is a beacon communication module,

The device authentication agent may wirelessly broadcast by inserting identification information usable for identification of the corresponding IoT device and the first device authentication information into a beacon message.

Here, the first device authentication information may be inserted into at least one of a major field and a minor field that follow a data field region into which a UUID, which is a beacon unique value, is inserted in the beacon message.

Here, when the first device authentication information exceeds the size of the data field area to be inserted, the first device authentication information is converted into a value not exceeding the size of the corresponding data field area and inserted into the beacon message. Can be.

In one embodiment, the communication module is a near-field communication (NFC) communication module,

The device authentication agent may transmit the first device authentication information to the mobile agent as the communication session with the mobile agent is activated through an NFC handshake.

In an embodiment, when the first device authentication information and the second device authentication information are generated by a time one time password (OTP) method using time as an operation condition,

The authentication server transmits both current second device authentication information and current second device authentication information previously generated to the mobile agent.

The mobile agent may verify whether the authenticity is determined by determining whether the first device authentication information matches any one of the current and second device authentication information.

In one embodiment, the device authentication agent sends the first device authentication information to the authentication server,

The authentication server may verify the authenticity again according to whether or not the first device authentication information received from the device authentication agent and the second device authentication information generated by the authentication server.

In one embodiment, the mobile agent generates the first user authentication information for user authentication according to a predetermined algorithm, and the user identification information and the first user authentication information available for identification of the user to the authentication server Send,

The authentication server self-generates second user authentication information according to the predetermined algorithm according to the user identification information received from the mobile agent, and receives the received first user authentication information and the self-generated second user authentication. The authenticity of the user may be verified according to whether the information matches, and a verification result regarding the authenticity of the user may be transmitted to the device authentication agent.

In an embodiment, the authentication server may generate first server verification information by using the user authentication information for the user authentication and a predetermined algorithm, and generate the first server verification information and the user authentication information by the device authentication agent. To,

The device authentication agent generates second server verification information by using the user authentication information received from the authentication server and the predetermined algorithm, and the first server verification information and the second server verification information received from the authentication server. Verification of authenticity of the authentication server may be performed according to the agreement between the two servers.

According to another aspect of the present invention, as the authentication application program installed in the user's mobile device and performing a predetermined authentication procedure is driven, seed information for generating authentication information to be used for mutual authentication between devices is generated. And a mobile agent generating first authentication information by using the seed information and a predetermined algorithm; Is installed in the Internet of Things (IoT) device equipped with a communication module, connected to the mobile agent via wireless communication, receiving the seed information from the mobile agent, using the received seed information and the predetermined algorithm A device authentication agent generating second authentication information; And when the seed information and the first authentication information are received from the mobile agent, the mobile device is connected to the mobile agent through wireless communication, and is connected to the IoT device via wired or wireless communication. Generate third authentication information using a specified algorithm, receive the second authentication information from the device authentication agent, match the received first authentication information with the third authentication information, and receive the second authentication information; There is provided an authentication system including an authentication server for double-verifying whether information matches the third authentication information.

According to an embodiment of the present invention, when a store and a customer make a payment without using a card, all mobile devices supporting NFC or Beacon are secured by using the customer's mobile device, an IoT device located in the store, and a cloud service. And there is an effect that a convenient payment service can be made. In addition, according to an embodiment of the present invention, an authentication method and system that can verify both the authenticity of the payment subject (customer), the authenticity of the payment object (IoT device as a payment device in the store) as a prerequisite for secure payment. can do.

According to an embodiment of the present invention, it is possible to provide an authentication method and system that can be universally applied in various application fields to determine the authenticity of an IoT device using a mobile device and an authentication server.

1 is a diagram of a first embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having a beacon message sending function is installed in a store.

2 is a diagram of a second embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having a beacon message sending function is installed in a store.

3 is a diagram of a third embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having a beacon message sending function is installed in a store;

4 is a diagram of a fourth embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having a beacon message sending function is installed in a store.

FIG. 5 is a diagram of a fifth embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having a beacon message sending function is installed in a store. FIG.

FIG. 6 is a diagram of a sixth embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having a beacon message sending function is installed in a store; FIG.

FIG. 7 is a diagram of a first embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having an NFC function is installed in a store; FIG.

FIG. 8 is a diagram of a second embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having an NFC function is installed in a store; FIG.

FIG. 9 is a diagram of a third embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having an NFC function is installed in a store; FIG.

10 is a diagram of a fourth embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having an NFC function is installed in a store;

FIG. 11 is a diagram of a fifth embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having an NFC function is installed in a store; FIG.

12 is a diagram of a sixth embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having an NFC function is installed in a store;

FIG. 13 is a diagram of a first embodiment for explaining a method and a system for issuing a meal ticket in a mobile payment system when an IoT device is installed in a store; FIG.

FIG. 14 is a diagram of a second embodiment for explaining a method and a system for issuing a meal ticket in a mobile payment system when an IoT device is installed in a store; FIG.

FIG. 15 is a diagram of a third embodiment for explaining a method and a system for issuing a meal ticket in a mobile payment system when an IoT device is installed in a store; FIG.

FIG. 16 is a diagram of a seventh embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having a beacon message sending function is installed in a store; FIG.

As the invention allows for various changes and numerous embodiments, particular embodiments will be illustrated in the drawings and described in detail in the written description. However, this is not intended to limit the present invention to specific embodiments, it should be understood to include all transformations, equivalents, and substitutes included in the spirit and scope of the present invention.

In describing the present invention, when it is determined that the detailed description of the related known technology may unnecessarily obscure the subject matter of the present invention, the detailed description thereof will be omitted. In addition, numerals (eg, first, second, etc.) used in the description process of the present specification are merely identification symbols for distinguishing one component from another component.

In addition, throughout the specification, when one component is referred to as "connected" or "connected" with another component, the one component may be directly connected or directly connected to the other component, but in particular It is to be understood that, unless there is an opposite substrate, it may be connected or connected via another component in the middle.

In addition, throughout the specification, when a part is said to "include" a certain component, it means that it may further include other components, without excluding the other components unless otherwise stated. In addition, the terms "unit", "module", and the like described in the specification mean a unit that processes at least one function or operation, which means that it may be implemented by one or more pieces of hardware or software or a combination of hardware and software. . In addition, Push ID, which is usually expressed by mobile app developers, means Push Token, and push message service means a message service provided for each app in a mobile operating system such as Google or Apple.

In the present specification, each embodiment of the present invention will be described based on a mobile payment or a mobile commerce case, but an authentication method and system to be described below with reference to each drawing determines the authenticity of various IoT devices using a mobile device and an authentication server. To this end, it is first clarified that it can be applied universally in various applications.

However, assuming that the present invention is applied to a mobile payment or a commerce case, in the present specification and in each drawing, the 'IoT device 100' is installed in a store, and the customer's mobile device (for example, a smartphone) The device may be a device that performs various operations (eg, a transaction approval request) related to a mobile payment or a transaction through communication with the mobile station. Here, the IoT device 100 may be a separate independent device that communicates with a Point of Sales (POS) terminal in a store, or may be implemented as a device that is integrated with a POS terminal or replaces a POS terminal. In this case, the IoT device 100 may be installed with hardware or / and software for enabling a beacon function or a near-field communication (NFC) function. In view of the above, assuming that the present invention is applied to a mobile payment or a commerce case, in the present specification and each drawing, the 'user app 200' is installed on a mobile device such as a smart phone owned by a customer, which will be described later. It can point to an application program that performs a series of actions (ie, termed mobile agent in the present invention). In addition, in the present specification, for convenience of description, the IoT device 100 itself will be described as performing a role in each drawing, but in reality, a software program or a hardware module performing the corresponding role (in the present invention, this is called a device authentication agent). ) May be installed or mounted in the IoT device, and thus may play a role according to each embodiment of the present invention.

In addition, in the present specification, the authentication of the IoT device, as well as authentication of the authenticity of the IoT device itself, as well as verifying whether the message that is determined to be received from the IoT device is a forgery message by a device ID or the like being stolen by a hacker or the like. First of all, make sure that the concept is comprehensive.

In addition, the identification numbers (i.e., S100, S102, S104, etc.) for each step in the flowcharts of FIGS. 1 to 15 to be described below are merely for explaining each step and do not define a procedural order. . Of course, each step may be executed in parallel or concurrently, regardless of whether the identification number is subsequent, unless logically one step can be executed after one step has been executed. In some cases, it is obvious that the steps may be executed in a different order than the preceding and subsequent identification numbers. As long as the key technical features of the present invention can be fully reflected, the order of each step may also be variously modified. However, hereinafter, for convenience and convenience of description, each step will be described in the order shown in the drawings.

Hereinafter, each embodiment of the present invention will be described in detail with reference to the accompanying drawings.

Referring to FIG. 1, a system including an IoT device 100 located in a store, a user app 200 installed on a mobile device of a customer, and an authentication server 300 is disclosed. At this time, the IoT device 100 and the user app 200, the user app 200 and the authentication server 300 is connected through wireless communication, the IoT device 100 and the authentication server 300 is wired or It can be connected via wireless communication. In this case, it is assumed that the IoT device 100 has a beacon message sending function (also in FIGS. 2 to 6).

Hereinafter, the authentication flowchart of FIG. 1 is demonstrated. 1 illustrates a process of authenticating an IoT device located in a store as a premise for mobile payment.

The authentication server 300 generates the device authentication OTP Seed as seed information for authentication of the IoT device [see S100 of FIG. 1], and transmits the generated Seed to the IoT device 100 while the IoT device 100 Request to generate a device authentication OTP (see S102 in FIG. 1). In addition, the authentication server 300 itself generates the device authentication OTP using the generated Seed (see S104 in FIG. 1). In response to the device authentication OTP generation request as described above, the IoT device 100 generates the device authentication OTP based on the received Seed (see S106 of FIG. 1).

In this case, the authentication server 300 and the IoT device 100 may share a generation condition, a generation method, or an algorithm of a device authentication OTP common in advance. In general, OTP generation methods include a time OTP method and a challenge & response method. Here, the time OTP method is a method of generating the OTP using the generation time as an operation condition. Accordingly, the OTP may be generated as an encrypted value according to a specific hash function by multiplying the determined specific OTP generation key by the generation time which is an operation condition. The challenge and response method is a method of generating an OTP using the number of attempts as an operation condition. Accordingly, the OTP may be generated as an encrypted value according to a specific hash function by multiplying the determined specific OTP generation key by the number of attempts, which is an operation condition. Therefore, according to the time OTP method, a new OTP value is generated whenever the valid time (for example, 60 seconds) of the corresponding OTP value elapses. On the other hand, in the challenge and response method, if the number of attempts is the same, the same OTP value will be maintained regardless of time.

In this case, the authentication server 300 and the IoT device 100 may share some of the key values for generating the OTP in advance. For example, when generating a device authentication OTP, the ID (ie IoT ID) of the corresponding IoT device or the key value of the IoT device may be shared in advance. Accordingly, the authentication server 300 may determine key values (for example, random numbers that are variable values, etc.) except for key values shared with each other, and / or operation conditions (for example, when a challenge and response method is used, an attempt value ( Challenge value)) may be transmitted to the IoT device 100 as a Seed.

For the same reason as described above, the device authentication OTP generated in S104 of FIG. 1 and S106 of FIG. 1 will be the same value.

Accordingly, the IoT device 100 wirelessly transmits (broadcasts) the beacon ID and the device authentication OTP generated in S106 of FIG. 1 to the beacon message (see S110 in FIG. 1). At this time, the beacon ID is information for identifying the IoT device that transmits the beacon signal, device authentication OTP is information for use in determining the authenticity of the IoT device.

Typically, depending on how the beacon works, the beacon will be enabled to read the major and minor field values of the beacons of that UUID only if a UUID value that matches the UUID value of the beacon is present in the beacon message ( For iOS), it works by filtering and using only your own UUID out of all beacon UUIDs coming in on the beacon frequency (Android OS). In addition, beacons typically select one or more unique UUID values for identifying services provided according to the beacons, and use them as service unique values, and use major / minor fields as building names or designated locations. However, in this case, if you read the beacons with a beacon scanner and generate beacons that generate the same beacons as if they are in the field and read them through the mobile app, even if the user has not visited the beacons There is a problem that you can manipulate as you have visited. Because beacons use open frequencies, scanning them on a typical mobile device can retrieve their values. Therefore, in order to use beacons in more sophisticated areas, such as financial transactions, verifying the location of visits, or identifying visited equipment (vehicles, robots, etc.), it must be possible to prove that the beacon frequencies have not been manipulated by the secondary provider.

In order to solve this problem, in an embodiment of the present invention, when it is recommended to use one or 20 beacon UUID values of the same service, UUID is used as a service unique identifier, and a major field is used as an equipment identifier ( That is, a Beacon ID) and a minor field may be configured as an authentication value (that is, device authentication OTP).

In this case, the beacon message has a different length of data field available for each beacon method (for example, iBeacon, Eddystone, etc.). In general, unlike the NFC, since the information that can be transmitted is limited, the device authentication value is inserted into the beacon message. The following method may be used as the method. In the following description, a case in which a major field 2 bytes and a minor field 2 bytes are configured on a beacon message will be described.

Depending on the system configuration, if there is one device in one service, the entire 4 bytes of major and minor behind one UUID may be used as the device authentication value. After one service UUID, a major field of 2 bytes can be used as a device identification value, and a minor field of 2 bytes can be used as a device authentication value.

In this case, if the entire 4 bytes are composed of Hexa string, the device authentication value can be expressed as 65,536. If only 2 bytes of the minor field are used to insert the device authentication value, the 2 bytes are expressed as a bit. The authentication value of the device can be expressed as 65,536, which is the 16th approval of 2. In some cases, when the generated device authentication value exceeds 65,536, the device authentication value may be converted to a value that does not exceed 65,536, or when the device authentication value is generated, an authentication value of 65,536 or less may be processed. have. In this case, if more than 65,000 beacons are used according to the service configuration, the number of beacons can be increased by additionally setting up to 20 UUID values.

The beacon signal transmitted from S110 of FIG. 1 may be low power driven, and the signal strength may be adjusted to be effectively detected by another device only within a specific position range. Hereinafter, it is assumed that the beacon signal transmitted from S110 of FIG. 1 is adjusted to have a signal strength so that the beacon signal is effectively detected only in a store where the corresponding IoT device is installed.

Accordingly, when a user (customer) entering the store drives the user app 200 installed in the mobile device possessed by him (see S112 of FIG. 1), the beacons transmitted by the IoT device 100 at the corresponding time point. A signal can be received (see S114 in FIG. 1). Although FIG. 1 illustrates a case in which the customer directly runs the app, the app may be automatically driven as the app enters a predetermined position range and receives a beacon signal.

When the beacon signal transmitted by the IoT device 100 is received, the user app 200 requests to transmit the device authentication OTP to the authentication server 300 for the purpose of determining the authenticity of the corresponding IoT device [Fig. 1]. See S116]. Accordingly, the authentication server 300 may transmit the device authentication OTP previously created to the user app 200 (see S118 of FIG. 1).

In this case, if the device authentication OTP generated above is a value generated by the time OTP method, the device authentication OTP value received by the user app 200 according to S110 of FIG. 1 and the user app 200 according to S118 of FIG. 1. The received device authentication OTP value may be different. Valid when the reception time of the device authentication OTP value in the user app 200 according to S110 of FIG. 1 and the reception time of the device authentication OTP value in the user app 200 according to S118 of FIG. This is because the OTP value of the electricity of varying time and the OTP value of the current period may be received. Therefore, in consideration of the above case, the authentication server 300 is a user of both the device authentication OTP (that is, electric OTP) and the currently generated device authentication OTP (that is, current OTP) created in the previous point in S118 of FIG. You can also send to the app (200).

Accordingly, the user app 200 receives the device authentication OTP value contained in the beacon message received from the IoT device 100 through S110 of FIG. 1 and the device authentication OTP value received from the authentication server 300 through S118 of FIG. 1. By checking whether there is a match between the two, it is possible to verify whether the IoT device 100 that sent the beacon message is a true device that performs a transaction in the store (that is, whether the IoT device is authentic or forged) [FIG. 1. S120].

2 is a diagram of a second embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having a beacon message sending function is installed in a store. Hereinafter, the authentication flowchart of FIG. 2 is demonstrated. 2 also illustrates a process of authenticating an IoT device located in a store as a premise for mobile payment. In the description process of FIG. 2, in the case of steps having the same concept as in FIG. 1, the description overlapping with the description above will be omitted.

In FIG. 1, if the seed information of the device authentication OTP is generated by the authentication server 300 and transmitted to the IoT device 100, in FIG. 2, device authentication for determining the authenticity of the IoT device 100 is performed. There is a key difference in that the seed information of the OTP is generated by the IoT device 100 itself.

That is, the IoT device 100 generates a seed for generating an initial device authentication OTP (see S200 of FIG. 2), transmits the generated seed to the authentication server 300, and requests to generate a device authentication OTP. (Refer to S202 of FIG. 2). At this time, the IoT device 100 generates a device authentication OTP by using the generated Seed (see S204 of FIG. 2), and the authentication server 300 also generates a device authentication OTP using the received Seed [FIG. 2. See S206].

Accordingly, the IoT device 100 wirelessly sends (broadcasts) the beacon ID and the device authentication OTP generated in S204 of FIG. 2 to the beacon message (see S210 of FIG. 2). In this case, the beacon ID is information for identifying an IoT device that transmits a beacon signal, and the device authentication OTP is information for use in determining the authenticity of the IoT device. In addition, the method of inserting the device authentication OTP into the data field of the beacon message may be the same as described above. In addition, it is also assumed that the beacon signal transmitted from S210 of FIG. 2 is adjusted so that the signal strength is effectively detected only in the store where the corresponding IoT device is installed.

Accordingly, when a user (customer) entering the store is driving a user app 200 installed in the mobile device possessed by him (see S212 of FIG. 2), the IoT device 100 transmits a beacon at that time. A signal can be received (see S214 of FIG. 2).

When the beacon signal transmitted by the IoT device 100 is received, the user app 200 requests to transmit the device authentication OTP to the authentication server 300 for the purpose of determining the authenticity of the corresponding IoT device (FIG. 2). S216]. Accordingly, the authentication server 300 may transmit the device authentication OTP previously created to the user app 200 (see S218 of FIG. 2). As described above, in this case, if the device authentication OTP is a value generated by the time OTP method, the authentication server 300 is the device authentication OTP (that is, electric OTP) and the currently generated device created at a previous time in S218 of FIG. The authentication OTP (that is, the current OTP) can all be sent to the user app 200.

Accordingly, the user app 200 receives the device authentication OTP value included in the beacon message received from the IoT device 100 through S210 of FIG. 2 and the device authentication OTP value received from the authentication server 300 through S218 of FIG. 2. By checking whether there is a match, it is possible to verify the authenticity or forgery of the IoT device 100 that transmitted the beacon message through this (see S220 of FIG. 2).

3 is a diagram of a third embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having a beacon message sending function is installed in a store. Hereinafter, the authentication flowchart of FIG. 3 is demonstrated. 3 also illustrates a process of authenticating an IoT device located in a store as a premise for mobile payment. In the description process of FIG. 3, in the case of steps having the same concept as in the description of the preceding drawings, the overlapping description will be omitted.

In FIG. 1, the seed information of the device authentication OTP is generated by the authentication server 300 and transmitted to the IoT device 100. In FIG. 2, device authentication for determining the authenticity of the IoT device 100 is performed. If the seed information of the OTP was generated by the IoT device 100 itself, in the case of FIG. 3, the seed information for generating the device authentication OTP is generated and delivered by the user app 200 or the first device in the user app 200. There is a key difference from FIG. 1 and FIG. 2 in that it is a method of requesting generation of an authentication OTP.

For example, as a user entering the store runs a user app 200 installed on a mobile device possessed by him (see S300 of FIG. 3), the user app 200 generates a device authentication OTP Seed [FIG. S302 of FIG. 3], and transmits the generated Seed to the authentication server 300, and requests to generate a device authentication OTP (see S304 of FIG. 3). Of course, according to the system design method, the above process may be executed while the user app 200 is automatically driven at the same time as the beacon signal continuously broadcast by the IoT device 100 is received.

When the Seed is received from the user app 200, the authentication server 300 transmits the Seed to the IoT device 100 [see S306 of FIG. 3], and generates a device authentication OTP using the Seed [FIG. 3. S308 of the present disclosure), the generated device authentication OTP may be transmitted to the user app 200 (see S310 of FIG. 3). In addition, the IoT device 100 may generate a device authentication OTP using the received seed. Here, as described above, the authentication server 300 and the IoT device 100 may share a method of generating device authentication OTP with each other in advance.

The IoT device 100 wirelessly transmits (broadcasts) the beacon ID and the device authentication OTP generated in S312 of FIG. 3 to the beacon message (see S314 in FIG. 3). Accordingly, the user app 200 compares the match between the device authentication OTP received in S310 of FIG. 3 and the device authentication OTP received in S314 of FIG. 3, thereby checking whether the IoT device 100 that transmitted the beacon message is authentic. Or it can be verified whether the forgery (see S316 of Figure 3).

In the above, the case where the user app 200 transmits the Seed to generate the device authentication OTP to the authentication server 300 and the authentication server 300 transmits the Seed back to the IoT device 100 are described. Of course, it can exist in other variations of. For example, the user app 200 may use only the device authentication OTP generation request as the authentication server 300 through step S304 of FIG. 3 without separately generating a seed. In this case, the authentication server 300 may transmit to the IoT device 100 through the step S306 of FIG. 3 using the Seed as a key value or an operation condition used when the device generates the device authentication OTP. As an example, when the authentication server 300 generates the device authentication OTP in a challenge and response method, the authentication server 300 may transmit a challenge value, which is an operation condition, to the IoT device 100 as a seed.

4 is a diagram of a fourth embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having a beacon message transmission function is installed in a store.

Here, FIG. 4 is an authentication flowchart in which the authentication server 300 verifies the user side after verifying the IoT device 100 on the user side (that is, the user app 200). Accordingly, steps S100 to S120 of FIG. 4 are the same as described above with reference to FIG. 1. When the process of verifying the IoT device at the user side according to the steps S100 to S120 of FIG. 4 is completed, the process of verifying the user side is performed by the authentication server according to the steps S122 to S218 of FIG. 4.

When the IoT device verification is completed, the user app 200 generates an authentication value for user authentication (that is, a value for proving that the user is a true user, in this example, a user OTP) (see S122 of FIG. 4), The user authentication information is transmitted to the authentication server 300 (see S124 of FIG. 4). In this case, as the user authentication information, identification information (user ID in this example) and user OTP capable of identifying the user may be transmitted to the authentication server 300. Here, the user identification information may be used in addition to the user ID in this example, the mobile device identification value, mobile device phone number, USIM value, app ID, and the like.

Accordingly, the authentication server 300 identifies the user who has transmitted the user OTP, generates a user OTP according to a pre-shared OTP generation method and / or operation condition, and generates the user OTP by itself and the received user. By comparing the agreement between the OTPs, the authenticity or forgery of the user side is verified (see S126 of FIG. 4). Thereafter, the authentication server 300 may transmit the user authentication result according to S126 of FIG. 4 to the IoT device 100 (see S128 of FIG. 4).

5 is a diagram of a fifth embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having a beacon message sending function is installed in a store.

Here, FIG. 5 illustrates the IoT device authentication process according to steps S107 and S109 of FIG. 5 in the authentication flowchart of FIG. 4 described above. That is, according to the foregoing FIGS. 1 and 4, the authentication of the IoT device is performed by the user side (that is, the user app 200), but in FIG. 5, the authentication of the IoT device is performed in parallel in the authentication server 300. As a result, more reliable IoT device authentication is possible. That is, in step S106 of FIG. 5, the device authentication OTP generated by the IoT device 100 is also transmitted to the authentication server 300 [see S107 of FIG. 5], and accordingly, the authentication server 300 performs step S104 of FIG. 5. By comparing the match between the device authentication OTP generated by itself and the device authentication OTP received from the IoT device 100, it is possible to re-verify the authenticity or forgery of the IoT device.

6 is a diagram of a sixth embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having a beacon message sending function is installed in a store.

Here, S100 to S126 of FIG. 6 are based on the same procedure as in FIG. 5. In addition, in FIG. 6, in addition to the authentication process of the IoT device and the authentication process of the user side, there is a technical feature in that authentication of the authentication server 300 is also performed. Authentication of the authentication server 300 may be performed through S130, S132, S134 of FIG.

That is, when authentication of the IoT device (parallel authentication at the user side and the authentication server side) and the user side authentication are completed through S100 to S126 of FIG. 6, the authentication server 300 is itself a true authentication server (that is, forgery and alteration). An authentication value (in this example, the server verification OTP) for proving that the authentication server is not an authorized server may be generated (see S130 of FIG. 6). At this time, the server authentication value may be generated by various methods, but in this example, the server verification OTP is generated using the IoT key value and the user OTP shared with the IoT devices.

Thereafter, the authentication server 300 may request server verification while transmitting the generated server verification OTP and the user OTP to the IoT device 100 (see S132 of FIG. 6). In this case, the IoT device 100 generates a server verification OTP using its IoT key value and the received user OTP, and whether the server verification OTP generated from the self verification and the server verification OTP received from the authentication server 300 match. By comparing this, it is possible to verify the authenticity of the authentication server 300 communicating with itself (see S134 of FIG. 6).

FIG. 16 is a diagram of a seventh embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having a beacon message sending function is installed in a store.

Referring to FIG. 16, the IoT device 100 generates a seed of the device authentication OTP (see S1000 of FIG. 16), and generates a device authentication OTP based on this (see S1002 of FIG. 16). The IoT device 100 broadcasts the beacon ID and the generated device authentication OTP in a beacon message (see S1004 of FIG. 16).

When the broadcast beacon signal is received according to the driving of the user app 200 (see S1006 and S1008 of FIG. 16), the user app 200 may request verification of the device authentication OTP to the authentication server 300 [ S1010 of FIG. 16].

In this case, the authentication server 300 generates the device authentication OTP in the same manner as the device authentication OTP is generated in the IoT device 100, and authenticates the device authentication OTP generated by the device and the device received from the user app 200. By comparing the agreement between the OTPs, it is possible to verify the authenticity of the IoT device broadcasting the beacon message (see S1014 of FIG. 16). At this time, the authentication result may be transmitted to the user app 200 (see S1016 of FIG. 16). Accordingly, the user app 200 may check the authenticity of the IoT device.

In generating the device authentication OTP through step S1014 of FIG. 16, the authentication server 300 may use the Seed received from the IoT device 100 according to step S1012 of FIG. 16. For example, when the challenge and response method is used as the device authentication OTP generation method, a challenge value, which is an operation condition, may be transmitted to the authentication server 300 through step S1012 of FIG. 16. Of course, other Seed values may be transmitted.

However, in some cases, step S1012 of FIG. 16 may be omitted. For example, if the beacon ID transmitted through S1004 of FIG. 16 is used as the seed of the device authentication OTP, and the device authentication OTP is generated by the time OTP method, step S1012 of FIG. 16 may be omitted. In addition, the transmission of the device authentication OTP Seed to the authentication server 300 according to S1012 of FIG. 16 may be performed at any point in time after the step S1000 of FIG. 16 is executed.

In the above, based on the case of FIG. 1, further introduction of the authentication process of the user side of FIG. 4, introduction of additional authentication of the IoT device through the authentication server of FIG. 5, and further introduction of the authentication process of the authentication server of FIG. Explained. Although not clearly illustrated through the drawings, the technical contents of FIGS. 4, 5, and 6 may be introduced in the same or similar manner to the case of FIG. 2, 3, or 16.

In the above, with reference to FIGS. 1 to 6 and 16, an authentication method and system assuming a case where an IoT device having a beacon signal transmission function is installed in a store has been described. Hereinafter, FIGS. 7 to 12 have an NFC function. An authentication method and system assuming a case where an IoT device is installed in a store will be described.

7 is a diagram of a first embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having an NFC function is installed in a store.

Here, FIG. 7 relates to an authentication method and system that may correspond to the embodiment of FIG. 1 described above, and illustrates an embodiment in which the IoT device 100 has an NFC function. To this end, the IoT device 100 according to the present embodiment may be equipped with an NFC module and software for driving the same in order to have an NFC function (hereinafter, FIGS. 8 to 12 are also the same).

Referring to FIG. 7, similar to the embodiment of FIG. 1, an OTP Seed for device authentication of the IoT device 100 is generated in the authentication server 300 and transmitted to the IoT device 100. Hereinafter, the authentication flow according to FIG. 7 will be described. In the description process of FIG. 7, the description of the same technical features as in the description of FIG. 1 will be omitted.

First, the authentication server 300 generates the device authentication OTP Seed (see S400 of FIG. 7), and requests generation of the device authentication OTP while transmitting the generated Seed to the IoT device 100 (S402 of FIG. 7). In addition, the authentication server 300 itself generates the device authentication OTP using the Seed (see S404 of FIG. 7), and the IoT device 100 also generates the device authentication OTP using the received Seed.

Subsequently, when the user app 200 is driven [see S410 of FIG. 7], and performs an NFC tap on the IoT device 100 using the mobile device possessed by the user [see S412 of FIG. 7], the user A communication session via an NFC handshake may be established between the mobile device and the IoT device 100 (see S414 in FIG. 7).

In this case, as the user directly or the user app 200 automatically selects the device authentication OTP request (see S416 of FIG. 7), the user app 200 is a device as the IoT device 100 and the authentication server 300, respectively. It may request to send an authentication OTP (see S418 and S422 of FIG. 7). In response to this, when the device authentication OTP is transmitted from the IoT device 100 and the authentication server 300 (see S420 and S424 of FIG. 7), the user app 200 receives the device authentication OTP received from the IoT device 100. And authenticity of the IoT device 100 can be determined (verified) by comparing the agreement between the device authentication OTP received from the authentication server 300 (see S526 of FIG. 7).

8 is a diagram of a second embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having an NFC function is installed in a store.

Here, FIG. 8 relates to an authentication method and system that may correspond to the above-described embodiment of FIG. 2, and illustrates an embodiment when the IoT device 100 has an NFC function. Referring to FIG. 8, similar to the embodiment of FIG. 2, the OTP Seed for device authentication of the IoT device 100 is generated by the IoT device 100 and transmitted to the authentication server 300. Hereinafter, the authentication flow according to FIG. 8 will be described. In the description process of FIG. 8, the description of the same technical features as in the description of FIG. 2 will be omitted.

The IoT device 100 generates a device authentication OTP Seed and generates the device authentication OTP using the device authentication OTP Seed (see S500 and S504 of FIG. 8). At this time, the generated Seed is transmitted to the authentication server 300 (see S502 of FIG. 8), and the authentication server 300 generates the device authentication OTP using the received Seed (see S506 of FIG. 8).

Subsequently, driving of the user app 200 [see S510 of FIG. 8], NFC tap [see S512 of FIG. 8], NFC handshake [see S514 of FIG. 8], selection of the device authentication OTP request [see S516 of FIG. 8]. ], The user app 200 may request to transmit the device authentication OTP to the IoT device 100 and the authentication server 300, respectively (see S518 and S522 of FIG. 8). In response to this, when the device authentication OTP is transmitted from the IoT device 100 and the authentication server 300 (see S520 and S524 of FIG. 8), the user app 200 receives the device authentication OTP received from the IoT device 100. And authenticity of the IoT device 100 can be determined (verified) by comparing the agreement between the device authentication OTP received from the authentication server 300 (see S526 of FIG. 8).

In the present specification, in the case in which the IoT device 100 is equipped with the NFC function, although not separately illustrated in the drawings corresponding to the above-described embodiment, the method similar to the technical method described in FIG. 3 may be applied. Of course.

FIG. 9 is a diagram of a third embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having an NFC function is installed in a store.

Here, FIG. 9 relates to an authentication method and system that may correspond to the embodiment of FIG. 4 described above, and illustrates an embodiment in which the IoT device 100 has an NFC function. Referring to FIG. 9, similar to the embodiment of FIG. 4, authentication of the user side is also performed after the device authentication process for the IoT device 100. Hereinafter, the authentication flow according to FIG. 9 will be described. In the description process of FIG. 9, the description of the same technical features as in the description of FIG. 4 will be omitted.

S400 to S426 of FIG. 9 correspond to the device authentication process of the IoT device 100, which is the same as in FIG. 7 described above. When the device authentication for the IoT device 100 is completed through the above process, the user app 200 generates an authentication value (user OTP in this example) for authentication of the user side [see S428 of FIG. 9], and User authentication information may be transmitted to the authentication server 300 (see S430 of FIG. 9).

Accordingly, the authentication server 300 generates the authentication value for authentication of the user side in the same manner as the user app 200 generated the corresponding authentication value, and from the user authentication value and the user app generated by the user app 200 It is possible to authenticate the authenticity of the user side by comparing the match between the received user authentication value (see S432 in Fig. 9). The authentication result may be transmitted to the IoT device 100 (see S434 of FIG. 9).

FIG. 10 is a diagram of a fourth embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having an NFC function is installed in a store.

Here, FIG. 10 relates to an authentication method and system that may correspond to the embodiment of FIG. 5 described above, and illustrates an embodiment in which the IoT device 100 has an NFC function. Referring to FIG. 10, all processes except for steps S407 and S409 of FIG. 10 are the same as in FIG. 9. However, similar to the embodiment of FIG. 5, the device authentication process for the IoT device 100 is performed in the user app 200 and also in the authentication server 300. Here, S407 and S409 of FIG. 10 are steps related to cases in which device authentication for the IoT device 100 is performed by the authentication server 300.

FIG. 11 is a diagram of a fifth embodiment for explaining an authentication method and system in a mobile payment system when an IoT device having an NFC function is installed in a store.

Here, FIG. 11 relates to an authentication method and system that may correspond to the embodiment of FIG. 6 described above, and illustrates an embodiment in which the IoT device 100 has an NFC function. Referring to FIG. 11, similar to the embodiment of FIG. 6, after the device authentication process and the user authentication process for the IoT device 100 are completed, the authentication for the authentication server is also performed. Hereinafter, the authentication flow according to FIG. 11 will be described.

S400 to S432 of FIG. 11 are the same as those of FIG. 10 described above as a description of the device authentication process of the IoT device 100. When the device authentication and user authentication for the IoT device 100 is completed through the above process, a server authentication process is performed. The server authentication process is based on S436, S438, and S440 of FIG. 11, which is essentially the same as described with reference to FIG. 6.

12 is a diagram of a sixth embodiment for describing an authentication method and system in a mobile payment system when an IoT device having an NFC function is installed in a store. Here, the sixth embodiment is a flowchart of a method in which the authentication server 300 authenticates a user. Hereinafter, this will be described in detail.

When the user app 200 is driven [see S600 of FIG. 12], the user app 200 generates a user OTP Seed and generates a user authentication value (user OTP in this example) using the generated Seed [FIG. 12. S602 of. Subsequently, when the NFC tap [see S604 of FIG. 12] and the NFC handshake [see S606 of FIG. 12] are made, the user app 200 transmits a corresponding seed to the IoT device 100 [see S608 of FIG. 12]. In addition, the user OTP and user identification information (user ID in this example) generated by the authentication server 300 may be transmitted (see S610 of FIG. 12).

Accordingly, the authentication server 300 itself generates a user OTP in the same manner as the user app 200 generated the OTP, and whether the user OTP generated from the user app 200 matches with the user OTP received from the user app 200. By comparing, the user OTP can be primary verified (see S612 of FIG. 12).

In addition, as the Seed is received, the IoT device 100 generates a user OTP by itself in the same manner as the user app 200 generates the OTP using the Seed [see S614 of FIG. 12], and generates the Seed. The user OTP is transmitted to the authentication server 300 (see S616 of FIG. 12).

Accordingly, the authentication server 300 may secondly verify the user OTP by comparing the user OTP generated between the self-generated user OTP and the user OTP received from the IoT device 100 (see S618 of FIG. 12).

Through the above-described process, the authentication server 300 can authenticate the user side and the IoT device at the same time. That is, the authenticity of the user side may be authenticated through the first verification process of the user OTP described above, and the authenticity of the IoT device may be authenticated through the second verification process of the user OTP described above. The second verification process of the user OTP is a process in which the authentication server 300 verifies the user OTP generated by the IoT device 100 by using the Seed received from the user app 200, accordingly, the IoT device 100. The authenticity of this can also be verified indirectly.

In the above, after the NFC tap and the NFC handshake is made, the user OTP is shown and described as being transmitted to the authentication server 300, but this is not necessarily the same. In other words, the transmission of the user OTP to the authentication server may be performed at any point in time after the OTP is generated according to S602 of FIG. 12.

FIG. 13 is a diagram of a first embodiment for explaining a method and a system for issuing a meal ticket in a mobile payment system when an IoT device is installed in a store.

The meal ticket issuing system of FIG. 13 may include an IoT device 100 having a beacon signal transmission function, a user app 200 installed on a user's mobile device, an authentication server 300, and a meal ticket management server 400. . In this case, the user app 200 may be connected to the IoT device 100 and the meal ticket management server 400 through wireless communication, the meal ticket management server 400 is wired with the IoT device 100 and the authentication server 300 Alternatively, the communication may be connected via wireless communication.

Referring to FIG. 13, the IoT device 100 generates a device authentication OTP (see IoT OTP of FIG. 13, hereinafter, FIG. 14 and FIG. 15) to prove the authenticity of the device itself (FIG. 13). S700], the beacon ID and the generated device authentication OTP can be loaded in a beacon message to be broadcast to the outside (see S702 in FIG. 13).

As the user app 200 is driven [see S704 of FIG. 13], the user app 200 can receive a beacon signal [see S706 of FIG. 13], thereby proving the authenticity of the user or the app. Create a user OTP (see S708 of FIG. 13).

Thereafter, the user app 200 requests meal ticket information to the meal ticket management server 400 (see S710 of FIG. 13). In this case, the user app 200 receives user identification information (user ID in this example), self-generated user OTP, and IoT device information (ie, Beacon ID, IoT OTP) received through a meal ticket information request process. Together with the meal ticket management server 400 can be transmitted.

The food stamp management server 400 receiving the food stamp information request requests verification of the user and the corresponding IoT device to the authentication server 300 (see S712 of FIG. 13). To this end, the meal ticket management server 400 transmits the information (that is, user ID, user OTP, Beacon ID, IoT OTP) received from the user app 200 to the authentication server 300 through step S712 of FIG. 13. Can be.

Accordingly, the authentication server 300 identifies the user and the corresponding IoT device according to the received user ID and the beacon ID, and generates a shared OTP in advance (that is, the user app 200 and the IoT device 100 previously). In the same manner as in each method for generating an OTP in the) it is possible to create a user OTP and IoT OTP itself. The authentication server 300 may verify the authenticity of the user and the IoT device by comparing the user OTP and IoT OTP generated by the self and the match between the user OTP and IoT OTP received from the meal ticket management server 400 [ S714 in FIG. 13], and the verification result is transmitted to the meal ticket management server 400 (see S716 in FIG. 13).

When the received verification result is the authentication success, the food stamp management server 400 transmits the merchant information and the food stamp related information (in this example, food stamp ID, food stamp information, token value) provided by the merchant to the user app 200. (See S718 of FIG. 13). Here, the token value may be used as Seed information in the generation of the meal ticket OTP in the future.

When the affiliate store information and the meal ticket related information are received, the user app 200 may display the meal ticket information on the app screen based on the received information (see S720 of FIG. 13). When the user selects a meal ticket on the screen of the user app 200 [see S722 of FIG. 13], and taps the IoT device 100 [see S724 of FIG. 13], the user app 200 receives the meal ticket OTP. Is generated (see S726 of FIG. 13). At this time, since the IoT 100 device operates in a beacon manner, the event will be normally processed when the tap to the IoT device is made within a specified effective distance between the user's mobile device and the IoT device. In this case, the meal ticket OTP may use all or part of the information received through S718 of FIG. 7. In addition, the food stamp OTP may be generated as a transaction-linked OTP. In this case, transaction-related information such as the number of meal tickets and the amount may be further utilized as a seed of the OTP generation.

Thereafter, the user app 200 requests the use of a meal ticket to the meal ticket management server 400 (see S728 of FIG. 13). In the meal ticket use request process, a user ID, a meal ticket ID, a meal ticket OTP, and the like may be transmitted to the meal ticket management server 400.

When the meal ticket use request is received, the meal ticket management server 400 requests the meal ticket verification to the authentication server 300 (see S730 of FIG. 13). During the meal ticket verification request, information such as a meal ticket ID and a meal ticket OTP may be transmitted to the authentication server 300.

Accordingly, the authentication server 300 generates the meal ticket OTP based on the received information such as the meal ticket ID. The authentication server 300 compares whether or not the meal ticket OTP generated from the meal ticket OTP received from the meal ticket management server 400 matches with each other, and thus is received from the meal ticket management server 400 (that is, generated by the user app 200). ) Authenticity (or validity) of the food stamp OTP is verified (see S732 of FIG. 13). The verification result of the meal ticket OTP is transmitted to the meal ticket management server 400 (see S734 of FIG. 13).

If the food stamp OTP verification result is the verification success, the food stamp management server 400 updates the food stamp usage history [see S736 of FIG. 13], and sends the food stamp use result to the IoT device 100 [see S738 of FIG. 13]. The meal ticket usage history may be transmitted to the user app 200 (see S742 of FIG. 13). In this case, the IoT device 100 may output a success signal indicating that the use of the meal ticket is successful in a visual or / or audio manner (see S740 of FIG. 13).

In FIG. 13 described above, processes S700 to S714 are procedures for device authentication and user authentication. Therefore, processes S700 to S714 of FIG. 13 may be replaced with the procedures of FIGS. 1 to 12 and 16 described above. In addition, although S700 to S714 processes of FIG. 13 are implemented to simultaneously perform device authentication and user authentication, the device authentication process is replaced with the device authentication process according to FIGS. 1 to 12 and 16, and the user authentication process is a food stamp OTP. Of course, it may be modified to be performed together during the verification process. This is the same in the case of FIGS. 14 and 15 which will be described later.

FIG. 14 is a diagram of a second embodiment for explaining a method and a system for issuing a meal ticket in a mobile payment system when an IoT device is installed in a store. The meal ticket issuing system of FIG. 14 may include an IoT device 100 having a beacon signal transmission function, a user app 200 installed on a user's mobile device, an authentication server 300, and a meal ticket management server 400. . In the description process of FIG. 14, descriptions of contents that may overlap with those of FIG. 13 will be omitted.

Referring to FIG. 14, the IoT device 100 generates a device authentication OTP (see IoT OTP in FIG. 14) for verifying the authenticity of the device itself (see S800 in FIG. 14), and a beacon ID and the generated device. The authentication OTP may be carried in the beacon message and broadcasted to the outside (see S802 of FIG. 14).

As the user app 200 is driven [see S804 of FIG. 14], the user app 200 can receive a beacon signal [see S806 of FIG. 14], thereby proving the authenticity of the user or the app. Create a user OTP (see S808 in FIG. 14).

In addition, at this time, the user app 200 may generate a kind of serial number information (represented by the UUID in this example) for checking the number of attempts to use a meal ticket by the user (see S809 of FIG. 14). Beacon signals are broadcast, so that the information can be hijacked by hackers, and if user OTPs are also hijacked by hackers, there is also the possibility that a meal ticket can be used by a hacker within the valid time of the OTP. . Therefore, in the embodiment of Figure 14 is to prevent this problem by generating additional information that can confirm the number of attempts to use a meal ticket.

Thereafter, the user app 200 requests meal ticket information to the meal ticket management server 400 (see S810 of FIG. 14). In this case, the user app 200 may transmit a user ID, a self-generated user OTP, a beacon ID, an IoT OTP, and a self-generated UUID value together with the meal ticket management server 400 through a request for a meal ticket information.

The meal ticket management server 400 receiving the meal ticket information request verifies the UUID value of the number of attempts to use the meal ticket of the user (see S812 of FIG. 14), and stores the corresponding UUID value (see S814 of FIG. 14). At this time, the storage of the UUID value may be stored only during the valid time of the user OTP. In addition, the meal ticket management server 400 requests verification of the corresponding user and the corresponding IoT device to the authentication server 300 (see S816 of FIG. 14). To this end, the meal ticket management server 400 transmits the information (that is, user ID, user OTP, Beacon ID, IoT OTP) received from the user app 200 to the authentication server 300 through step S816 of FIG. 14. Can be.

Accordingly, the authentication server 300 identifies the user and the corresponding IoT device according to the received user ID and the beacon ID, and generates a shared OTP in advance (that is, the user app 200 and the IoT device 100 previously). In the same manner as in each method for generating an OTP in the) it is possible to create a user OTP and IoT OTP itself. The authentication server 300 may verify the authenticity of the user and the IoT device by comparing the user OTP and IoT OTP generated by the self and the match between the user OTP and IoT OTP received from the meal ticket management server 400 [ Referring to S818 of FIG. 14], the verification result is transmitted to the meal ticket management server 400 (see S820 of FIG. 14).

When the received verification result is the authentication success, the food stamp management server 400 transmits the merchant information and the food stamp related information (in this example, food stamp ID, food stamp information, token value) provided by the merchant to the user app 200. (See S822 of FIG. 14).

When affiliated store information and meal ticket related information are received, the user app 200 may display the meal ticket information on the app screen based on the received information (see S824 of FIG. 14). The user selects a meal ticket on the screen of the user app 200 (see S826 of FIG. 14), and taps the IoT device 100 (see S828 of FIG. 14). At this time, since the IoT 100 device operates in a beacon manner, the event will be normally processed when the tap to the IoT device is made within a specified effective distance between the user's mobile device and the IoT device.

Thereafter, the user app 200 requests the use of a meal ticket to the meal ticket management server 400 (see S830 of FIG. 14). During the meal ticket use request, information such as a user ID, a meal ticket ID, a token value, and the like may be transmitted to the meal ticket management server 400.

When the meal ticket use request is received, the meal ticket management server 400 verifies the received token value [see S832 of FIG. 14], and if the verification is successful, updates the meal ticket usage history [see S834 of FIG. 14], and uses the meal ticket. The result may be transmitted to the IoT device 100 [see S836 of FIG. 14], and the meal ticket usage history may be transmitted to the user app 200 (see S840 of FIG. 14). In this case, the IoT device 100 may output a success signal indicating that the use of the meal ticket is successful in a visual or / and audio manner (see S838 of FIG. 14).

Although FIG. 14 illustrates a method in which a token value received through S822 in the process of requesting a meal ticket through S830 is transmitted to the meal ticket management server 400 as it is, a meal ticket OTP is generated and transmitted as shown in FIG. 7. Of course, a verification method may be used. In addition, in FIG. 14, the token value verification is performed by the food stamp management server 400 through S832, but this may also be replaced by a method of verifying the food stamp OTP in the authentication server 300 as shown in FIG.

FIG. 15 is a diagram of a third embodiment for explaining a method and a system for issuing a meal ticket in a mobile payment system when an IoT device is installed in a store.

The meal ticket issuing system of FIG. 15 may include an IoT device 100 having an NFC function, a user app 200 installed on a user's mobile device, an authentication server 300, and a meal ticket management server 400. In the description process of FIG. 15, descriptions of contents overlapping with those of FIGS. 13 and 14 will be omitted.

Referring to FIG. 15, a step of generating an IoT OTP according to S900, an app driving step according to S902, a tap step of an IoT device according to S906, a selection step of using a meal ticket according to S910, a generation of a user OTP according to S912, and a meal ticket OTP Generation step, verification request step of user and IoT device according to S918, verification step of user and IoT device according to S920, transmission of verification result according to S922, update of meal ticket usage history according to S924, meal ticket use result according to S926 The transmission signal, the success signal output step according to S928, is essentially the same as in the above-described embodiment of FIG. 13 or FIG.

However, since NFC (Near-Field Communication) technology enables bidirectional communication between devices through the NFC handshake operation of S908, the food stamp-related information may be directly transmitted from the IoT device 100 to the user app 200. Therefore, the food stamp related information may be directly transmitted from the IoT device 100 to be displayed through the screen of the user app 200, and thus the user may select a food stamp. For example, step S904 of FIG. 15 illustrates a case of inputting a meal ticket price in a meal ticket selection process.

In addition, by utilizing the two-way communication through the NFC technology, it is possible to proceed with the meal ticket use request directly from the user app 200 to the IoT device (100). Referring to S912 of FIG. 15, the user app 200 may confirm that the user ID, the user OTP, the meal ticket price, the meal ticket OTP, etc. are requested to use the meal ticket while transmitting to the IoT device 100. Here, the meal ticket price is not necessarily transmitted separately, of course, may be used only as Seed information for generating a meal ticket OTP.

According to the embodiment of the present invention, the IoT device 100 that receives the meal ticket use request transmits the meal ticket use request to the meal ticket management server 400 (see S916 of FIG. 15). In this case, the IoT device 100 may transmit information for device authentication (refer to IoT device ID and IoT OTP in the case of S916 of FIG. 15) to the meal ticket management server 400. Accordingly, the meal ticket management server 400 may simultaneously request user authentication, device authentication, and meal ticket authentication to the authentication server 300 (see S918 of FIG. 15), and the authentication server 300 performs authentication on this. 15, the authentication result may be transmitted to the meal ticket management server 400.

The authentication method for a mobile payment system according to the embodiment of the present invention described above may be embodied as computer readable codes on a computer readable recording medium. Computer-readable recording media include all kinds of recording media having data stored thereon that can be decrypted by a computer system. For example, there may be a read only memory (ROM), a random access memory (RAM), a magnetic tape, a magnetic disk, a flash memory, an optical data storage device, and the like. The computer readable recording medium can also be distributed over computer systems connected over a computer network, stored and executed as readable code in a distributed fashion.

Although the above has been described with reference to embodiments of the present invention, those skilled in the art may variously modify the present invention without departing from the spirit and scope of the present invention as set forth in the claims below. And can be changed easily.

Claims

As an authentication system,

A device authentication agent installed in an Internet of Things (IoT) device on which the communication module is mounted and generating first device authentication information for authentication of the corresponding IoT device;

An authentication server connected to the IoT device through wired or wireless communication and generating second device authentication information for authentication of the IoT device; And

Installed in the user's mobile device, connected via wireless communication with the IoT device and the authentication server, the match between the first device authentication information sent from the IoT device and the second device authentication information sent from the authentication server A mobile agent that verifies the authenticity of the message determined to be received from the IoT device or the IoT device depending on whether

Authentication system comprising a.
The method of claim 1,

The authentication server generates seed information for generating device authentication information, transmits the seed information to the device authentication agent, and transmits the second device authentication information using the seed information and a predetermined algorithm. Create,

And the device authentication agent generates the first device authentication information by using the seed information received from the authentication server and the predetermined algorithm.
The method of claim 1,

The device authentication agent generates seed information for generating device authentication information, transmits the seed information to the authentication server, and transmits the first device authentication information using the seed information and a predetermined algorithm. Create,

And the authentication server generates the second device authentication information by using the seed information received from the device authentication agent and the predetermined algorithm.
The method of claim 1,

The mobile agent generates seed information for generating device authentication information, and transmits the generated seed information to the authentication server.

The authentication server generates the second device authentication information by using the seed information received from the mobile agent and a predetermined algorithm, and transmits the received seed information to the device authentication agent.

And the device authentication agent generates the first device authentication information by using the seed information received from the authentication server and a predetermined algorithm.
The method of claim 1,

The communication module is a beacon communication module,

The device authentication agent is wireless broadcasting by inserting identification information usable for identification of the IoT device and the first device authentication information into a beacon message.
The method of claim 5,

And the first device authentication information is inserted into at least one of a major field and a minor field following a data field region into which a UUID, which is a beacon unique value, is inserted in the beacon message.
The method of claim 6,

When the first device authentication information exceeds the size of the data field area to be inserted, the first device authentication information is converted into a value not exceeding the size of the corresponding data field area and inserted into the beacon message. system.
The method of claim 1,

The communication module is a near-field communication (NFC) communication module,

And the device authentication agent transmits the first device authentication information to the mobile agent as a communication session with the mobile agent is activated through an NFC handshake.
The method of claim 1,

When the first device authentication information and the second device authentication information is generated by a time OTP (One Time Password) method using time as an operation condition,

The authentication server transmits both current second device authentication information and current second device authentication information previously generated to the mobile agent.

And the mobile agent verifies whether the authenticity is true by determining whether the first device authentication information matches any one of the current and second device authentication information.
The method of claim 1,

The device authentication agent sends the first device authentication information to the authentication server,

And the authentication server verifies the authenticity again according to whether or not the first device authentication information received from the device authentication agent matches the second device authentication information generated by the device.
The method of claim 1,

The mobile agent generates the first user authentication information for user authentication according to a predetermined algorithm, and transmits the user identification information and the first user authentication information available for identification of the user to the authentication server,

The authentication server self-generates second user authentication information according to the predetermined algorithm according to the user identification information received from the mobile agent, and receives the received first user authentication information and the self-generated second user authentication. Verifying the authenticity of the user according to whether the information matches, and transmitting a verification result regarding the authenticity of the user to the device authentication agent.
The method of claim 11,

The authentication server generates first server verification information by using user authentication information for the user authentication and a predetermined algorithm, and transmits the first server verification information and the user authentication information to the device authentication agent.

The device authentication agent generates second server verification information by using the user authentication information received from the authentication server and the predetermined algorithm, and the first server verification information and the second server verification information received from the authentication server. And verifying the authenticity of the authentication server according to whether or not there is a match.
As an authentication system,

As the authentication application program installed in the user's mobile device and performing a predetermined authentication procedure is driven, seed information for generating authentication information to be used for mutual authentication between devices is generated, and the seed information and the predetermined information are generated. A mobile agent generating first authentication information using an algorithm;

Is installed in the Internet of Things (IoT) device equipped with a communication module, connected to the mobile agent via wireless communication, receiving the seed information from the mobile agent, using the received seed information and the predetermined algorithm A device authentication agent generating second authentication information; And

The seed information and the pre-specified information when the seed information and the first authentication information are received from the mobile agent, and the mobile device is connected to the mobile device through a wired or wireless communication. Generate third authentication information by using an algorithm, receive the second authentication information from the device authentication agent, match the received first authentication information with the third authentication information, and receive the received second authentication information Authentication server for double checking whether the third authentication information matches with the third authentication information

Authentication system comprising a.