KR102107190B1 - Method and system for authenticatiing user and internet of things device using authentication beacon - Google Patents

Abstract

A device authentication agent installed on an Internet of Things (IoT) device on which a communication module is mounted, and obtaining device authentication information for authentication of the IoT device; A mobile agent installed on a user's mobile device, obtaining user authentication information for authentication of the user, and generating an authentication request message including device authentication information and the user authentication information received from the device authentication agent; And when the authentication request message is received from the mobile agent, the authentication device for verification corresponding to the device authentication information and the user authentication information included in the authentication request message is generated to check whether the IoT devices and An authentication system including an authentication server that determines whether the user is authentic is provided.

Description

METHOD AND SYSTEM FOR AUTHENTICATIING USER AND INTERNET OF THINGS DEVICE USING AUTHENTICATION BEACON}

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

Recently, a technology that enables a customer to securely and conveniently make payment services on a user's smartphone by using a customer's smartphone and an IoT device and cloud service located in the store without using a card to perform payment in the store. It is in the limelight.

When a customer presents a card at a store (card merchant), the existing card transaction generates transaction data using the card reader and the customer's card, sends the transaction data to the card issuer, and then the card information or transaction details are abnormal. In the absence of this, it was executed in a way to approve 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 a secure closed network.

Also, as 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, mobile operators such as Apple Pay and Samsung Pay are temporarily issued cards on mobile. By converting the number to an actual card number, it is possible to perform payment through a mobile device without a credit card.

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

Nevertheless, conventional alternative payment technologies are QR code or barcode based payment technology based on the smartphone screen so that they can be used on all customer smartphones regardless of the mobile operating system. The main method is to make a transaction by reading the corresponding barcode value from the point-of-sale (POS) device of the store.

However, barcode-based payment requires a complicated code value recognition process between the customer and the store according to the issuance of the barcode, and if the barcode issued from the mobile device is captured by a hacker, the barcode is stolen elsewhere within the effective time of issuance. It has potential security holes.

Therefore, there is a need for a payment technology that enables 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 that utilizes IoT devices as a recently adopted technology, a new method is required that can authenticate the authenticity of the user as well as the authenticity of the IoT device, enabling more secure mobile transactions and payments. do.

In addition, recently, in addition to mobile payment, there are situations in which various services related to IoT devices (for example, door control, attendance confirmation, etc.) require user authentication and authentication of the corresponding IoT device. New authentication methods and systems are required.

The present invention is to provide an authentication method and system that can be universally applied in various application service fields to determine whether an IoT device is authentic and whether a user is authentic using an authentication beacon.

According to an aspect of the present invention, a device authentication agent installed on an Internet of Things (IoT) device on which a communication module is mounted, and obtaining device authentication information for authentication of the IoT device; A mobile agent installed on a user's mobile device, obtaining user authentication information for authenticating the user, and generating an authentication request message including device authentication information and the user authentication information received from the device authentication agent; And when the authentication request message is received from the mobile agent, the authentication device for verification corresponding to the device authentication information and the user authentication information included in the authentication request message is generated to check whether the IoT devices and An authentication system including an authentication server that determines whether the user is authentic is provided.

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

The device authentication agent may wirelessly broadcast device identification information available for identification of the corresponding IoT device and the device authentication information in a beacon message.

In one embodiment, the device authentication information may be inserted in at least one of a major field and a minor field followed by a data field area in which a UUID, a beacon unique value, is inserted in the beacon message.

At this time, when the device authentication information exceeds the size of the field area to be inserted, the device authentication information may be converted into a value that does not exceed the size of the field area to be inserted and inserted into the beacon message.

In one embodiment, the mobile agent,

When an app user is authenticated according to the driving of an app running a specific application service, and the device identification information and the device authentication information are received through the beacon message, at least the device authentication information is displayed in the authentication request message. It includes but may further include at least one of the user authentication information, the user identification information, the device identification information to be transmitted to the authentication server.

In one embodiment, the mobile agent,

The authentication request message may be transmitted to the authentication server only when it is determined that the distance between the IoT device and the mobile device is within a predetermined distance based on the reception strength or sensitivity of the beacon message.

In one embodiment, the mobile agent,

The user token obtained when the app user authentication is completed may be used as the user authentication information, or a newly generated user authentication value may be used as the user authentication information upon receipt of the device authentication information.

In one embodiment, the mobile agent,

An execution command selected by the app user in relation to an application service executed through the app may be included in the authentication request message and transmitted to the authentication server.

In one embodiment, the authentication server,

When the authentication request message is received, the authentication information for verification corresponding to the device authentication information and the user authentication information is generated, and both the authentication information for verification and the device authentication information and the user authentication information match. In this case, a command message for processing to execute the execution command included in the authentication request message may be generated.

In one embodiment, the authentication server,

When the user authentication through the authentication information for verification is completed, it is possible to determine whether an authority corresponding to the execution command is granted to the corresponding authenticated user, and determine whether to generate the command message according to the authority verification result.

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

1 is a diagram of one embodiment for explaining an authentication method and system capable of simultaneously authenticating a user and an IoT device using an IoT device having a beacon message transmission function and a mobile application installed on the mobile device.

The present invention can be applied to various transformations and can have various embodiments, and specific embodiments will be illustrated in the drawings and described in detail in the detailed description. However, this is not intended to limit the present invention to specific embodiments, and should be understood to include all conversions, equivalents, and substitutes included in the spirit and scope of the present invention.

In describing the present invention, when it is determined that a detailed description of related known technologies may unnecessarily obscure the subject matter of the present invention, the detailed description will be omitted. In addition, the numbers (for example, first, second, etc.) used in the description process of the present specification are only identification symbols for distinguishing one component from other components.

Further, in the specification, when one component is referred to as "connected" or "connected" with another component, the one component may be directly connected to the other component, or may be directly connected, but in particular, It should be understood that, as long as there is no objection to the contrary, it may or may be connected via another component in the middle.

In addition, throughout the specification, when a part “includes” a certain component, it means that the component may further include other components, not to exclude other components, unless otherwise stated. In addition, terms such as “part” and “module” described in the specification mean a unit that processes at least one function or operation, which means that it can be implemented by one or more 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 mainly described with reference to a mobile payment or a mobile commerce case. In order to discriminate, it is first clarified that it can be applied universally in various application service fields.

For example, assuming that the present invention is applied to a mobile payment or commerce case, in this specification and drawings, the 'IoT device 100' is installed in a store, and a customer's mobile device (for example, a smart phone) It may be a device that performs various operations (eg, transaction approval request, etc.) related to mobile payment or transaction through communication with. Here, the IoT device 100 may be a separate independent device that communicates with a point-of-sale (POS) terminal in the store, or may be implemented as a device that replaces the POS terminal or is integrated with the POS terminal. In addition, the IoT device 100 may be installed with hardware or / and software that enables a beacon function to be implemented. From the above point of view, assuming that the present invention is applied to a mobile payment or commerce case, the 'mobile app 200' in each specification and each drawing is installed on a mobile device, such as a customer's smartphone, to be described later. An application program that performs a series of operations (ie, in the present invention, it is referred to as a mobile agent) can be indicated. In addition, in this specification, for convenience of description, the IoT device 100 itself will be described as performing a role given in the drawing, but in reality, a software program or hardware module that performs a corresponding role (in the present invention, this is referred to as a device authentication agent) ) Is installed or mounted on an IoT device, and it is of course possible to perform a role according to each embodiment of the present invention.

As another example, if it is assumed that the present invention is applied to a door control case, in this specification and drawings, the 'IoT device 100' is installed in the door, and the door is opened and closed (or accessed through communication with a customer's mobile device). It may be a device that performs various operations related to (recording). At this time, the IoT device 100 may be the access control terminal itself, but it may be a separate independent device from the access control terminal, or may be implemented as a device that replaces the access control terminal or is integrated with the access control terminal.

In the present specification, the authentication of the IoT device is not only the authentication of the authenticity of the IoT device itself, but also verifying whether the message determined to be received from the IoT device is a forged message by stealing the device ID or the like by a hacker or the like. It is first clarified that the concept encompasses far. In this specification, the concept of user authentication is not different from the above.

In addition, it is clear that the identification numbers (that is, S100, S102, S104, etc.) for each step in the flowchart of FIG. 1 to be described below are only for separately explaining each step, and do not define a procedural order. It goes without saying that each step may be executed in parallel or concurrently regardless of the precedence of the identification number, unless the other step can be executed logically after one step is executed. It is obvious that in some cases, each step may be performed in a different order from the sequencing of the identification number. This is because various modifications may also be made to the order of each step to the extent that the core technical features of the present invention can be sufficiently reflected. However, hereinafter, for the concentration and convenience of description, each step will be described in the order shown in the drawings.

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

1 is a diagram of an embodiment for describing an authentication method and system capable of simultaneously authenticating a user and an IoT device using an IoT device having a beacon message transmission function and a mobile application installed on the mobile device.

Referring to FIG. 1, a system including an IoT device 100, a mobile app 200 installed on a mobile device possessed by a user, and an authentication server 300 is disclosed. At this time, between the IoT device 100 and the mobile app 200, the mobile 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 basically has a beacon message transmission function. Hereinafter, the authentication flowchart of FIG. 1 will be described.

In an embodiment of the present invention, the IoT device 100 transmits the device identification value, the service identification value, and the device authentication value to the beacon message through the beacon message (see S100 in FIG. 1). Here, the service identification value is a unique value that enables identification of a specific application service that can be serviced by the IoT device 100, and the device identification value can identify the IoT device 100 that actually provides the service. It is a unique value to enable, and the device authentication value refers to a value that enables the IoT device 100 providing a corresponding service to be a true service device that has not been forged.

In an embodiment of the present invention, the following method may be used as a method of inserting a device identification value and a device authentication value in a beacon message.

Normally, depending on how the beacon is operated, the beacon's major and minor field values can be read only when a UUID value matching the beacon's UUID value is carried in the beacon message ( For iOS), it works by filtering and using only its own UUID among all beacon UUIDs coming into the beacon frequency (for Android OS). Also, beacons typically use one or more unique UUID values to identify services provided according to the beacon and use them as service specific values, and major / minor fields have been used as building names or designated locations. However, if you use it like this, if you read the beacon value with the beacon scanner and create a beacon that generates the same beacon value as if you are in the field and read it through the mobile app, even if the user has not visited the beacon location, it will be in that location. There is a problem that can be manipulated like a visit. This is because the beacon uses the published frequency, so if you scan it on a typical mobile device, you can retrieve the value. Therefore, in order to use beacons in more sophisticated areas, such as financial transactions, verifying the location of visits, or checking visited equipment (vehicles, robots, etc.), it must be possible to prove that the beacon frequency has not been manipulated by a secondary provider.

To this end, in an embodiment of the present invention, when it is recommended to use one or 20 beacon UUID values of the same service, for example, UUID is used as a service-specific identification value, but a major field is used for device identification. The value (i.e., Beacon ID) and the minor field may be configured and used as authentication values (e.g., device authentication OTP, etc.).

At this time, the beacon message has different lengths of data fields available for each beacon method (eg, iBeacon, Eddystone, etc.), but in general, unlike NFC, information that can be transmitted is limited, so device authentication values are inserted into the beacon message. The following method may be used as a method. In the following description, it is assumed that a major field is composed of 2 bytes and a minor field is 2 bytes on the beacon message.

Depending on the system configuration, if there is one device for one service, all of the major and minor 4 bytes after one UUID may be used as the device authentication value, but if multiple devices must be authenticated for the same service After one service UUID, a major field 2 bytes can be used as a device identification value and a minor field 2 bytes can be used as a device authentication value.

In this case, if all 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, when the 2 bytes are expressed as Bit The device authentication value can be expressed by 2, 16 approval 65,536. In some cases, when the generated device authentication value exceeds 65,536, the device authentication value may be converted to a value not exceeding 65,536, or may be processed to generate an authentication value of 65,536 or less when generating the device authentication value. have. In this case, it is of course also possible to increase the number of beacons by additionally setting the UUID value up to 20 when there are more than 65,000 beacons used depending on the service configuration.

In addition, in the embodiment of the present invention, the device authentication value may be an encrypted fixed value (eg, a fixed key) for authentication of the device, but a variable value (for example, change according to time or a specific condition) OTP (one time password, etc.) may be generated.

When using OTP among variable values as the device authentication value, the authentication server 300 and the IoT device 100 may share a common device authentication OTP generation condition, generation method, or algorithm. In general, the OTP generation method includes a time OTP method and a challenge & response method. Here, the time OTP method is a method of generating an OTP using a generation time as a calculation condition. Accordingly, the OTP may be generated as a value obtained by multiplying the determined specific OTP generation key by the generation time, which is an operation condition, according to a specific hash function. In addition, 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 a value obtained by multiplying the determined specific OTP generation key multiplied by the number of attempts, which is an operation condition, according to a specific hash function. 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 has elapsed. On the other hand, according to the challenge and response method, if the number of attempts is the same, the same OTP value will be maintained regardless of time. The accompanying drawings in this specification show a case where time OTP (see T_OTP in FIG. 1) is used as the device authentication value.

In addition, at this time, the authentication server 300 and the IoT device 100 may pre-share some of the key values or seed values for generating the device authentication OTP with each other. For example, when generating a device authentication OTP, a specific key value or a seed value may be previously shared with each other corresponding to the ID of the IoT device (ie, Things_ID of FIG. 1). For the above-described reasons, the device authentication value generated by the authentication server 300 according to S112 of FIG. 1 (hereinafter referred to as a device authentication value for verification) is the device authentication value generated by the IoT device 100. It will be the same value.

In addition, in the embodiment of the present invention, the beacon message transmitted by the IoT device 100 may be transmitted while being limited to a predetermined transmission strength. Accordingly, the beacon message can be received from the mobile device only when the distance between the IoT device 100 and the mobile device on which the mobile app 200 is installed is within a certain distance (for example, a radius of 1M). Distance restrictions (hereinafter referred to as receiving distance restrictions) may be applied. In addition, in the case of the present invention, the distance between the IoT device and the mobile device must be within the mutual beacon frequency range to allow the corresponding authentication operation to operate. Limit). The distance limitation on the authentication operation may be implemented as follows in an actual implementation structure. For example, the proximity of the distance between the IoT device and the mobile device within 3 cm may be confirmed by measuring the reception strength or sensitivity of the beacon message received from the mobile device. Accordingly, according to an embodiment of the present invention, when the reception strength or sensitivity of a beacon message received from a mobile device comes into a predetermined range (or when the reception strength and sensitivity are maximized to meet a predetermined criterion) Only finally can the delivery of the authentication request message according to S110 of FIG. 1 to the authentication server 300 be made.

As described above, when the user drives the mobile app 200 installed on the mobile device owned by the user (see S102 in FIG. 1), the IoT device 100 may receive the beacon message sent at that time. . In FIG. 1, a case in which the customer directly drives the app is illustrated, but the app enters within a predetermined distance range (in this case, the predetermined distance range may be a distance corresponding to the above-described reception distance limit) and the app receives the beacon message. Of course, it may be implemented to be automatically driven.

According to an embodiment of the present invention, when the mobile app 200 is driven, the mobile app 200 may perform user authentication for a user of the app (see S104 in FIG. 1). When the user authentication of the mobile app 200 is completed, the authenticated user can select various commands or / and options through an application screen available for service in a relationship with the IoT device 100 (see S106 in FIG. 1). . For example, if the service is related to mobile payment, it may be a selection of a product to be paid (corresponding to the above option) and a payment request (corresponding to the above command). (Corresponds to). However, of course, there may be cases in which a separate command or option selection by a user is unnecessary depending on a service. However, commands and options may be automatically selected according to service properties provided by the mobile app 200 regardless of whether the user selects the command or option depending on the type of application and / or service properties, and at least one of the commands and options It may be unnecessary.

As described above, when the beacon message is received from the IoT device 100 (that is, when the device identification value and the device authentication value are received), the mobile app 200 identifies the identification value for the app user, the user authentication value, The received device identification value, the received device authentication value, and the command or / and option information are transmitted to the authentication server 300 (see S108 and S110 in FIG. 1).

In the case of FIG. 1, a user ID (see User_ID in FIG. 1) is illustrated as an app user identification value, and a user token (see User_Token in FIG. 1) or a user OTP (see User_OTP in FIG. 1) is illustrated as a user authentication value. have. However, various values other than the user identification value and the user authentication value may be used. As an example, as a user identification value, a mobile device identification value, a mobile device phone number, a USIM value, an app ID, etc. can be used in addition to the user ID in this example. In addition, the user token illustrated in FIG. 1 may be used to cover both the user identification value and the user authentication value, and in this case, only the user token value may be included in the authentication request message in step S110 of FIG. 1. However, in this specification, for convenience and concentration of description, as shown in FIG. 1, the user token obtained in the process of authenticating an app according to step S104 of FIG. 1 is used as a user authentication value, but user identification The value is also included separately in the authentication request message, and the description will be mainly focused on the case transmitted to the authentication server 300.

When the authentication request message is delivered to the authentication server 300 as described above, the authentication server 300 verifies the authentication value corresponding to each identification value based on the device identification value and the user identification value inserted in the authentication request message. (In other words, a device authentication value for verification and a user authentication value for verification) are generated. The authentication server 300 may perform authentication value verification by checking whether the generated verification value matches the received device authentication value and the user authentication value (refer to S112 in FIG. 1), and accordingly, the IoT device and the user You can determine the authenticity of the.

As a result of determining the authenticity as described above, when it is determined that the IoT device and the user are true subjects that have not been tampered with, the authentication server 300 inserts a command message including an execution command or / and an option inserted into the authentication request message. By passing it to the fulfilling subject or control subject of the service (see S116 and S118 in FIG. 1), the corresponding command can be fulfilled (see S120 in FIG. 1).

In the case of S120 of FIG. 1, the case in which the execution entity of the corresponding command is the IoT device 100 itself is illustrated, but the execution entity of the corresponding command may be different depending on the case. For example, in the door opening / closing service, the actual implementation subject may exist even when the door opening / closing terminal (not shown) and the IoT device are separately installed. In this case, the authentication server 300 transmits the corresponding command message instead of the IoT device. Can be delivered to the door opening and closing terminal. Also, in some cases, a command message may be transmitted to a management server (not shown) that controls the door opening / closing terminal. Similarly, when the command requested from the user through the mobile app 200 is to pay for the product purchase amount to the product seller, the authentication server 300 sends an electronic payment server (not shown) from the user's account. You may be able to send a command message to transfer product purchases to the seller's account.

At this time, the subject who has received the command may receive the authentication value for authentication of the authentication server together with the command to confirm whether the sender of the command message is a valid authentication server, and may execute the command after verifying it.

In addition, according to an embodiment of the present invention, when user authentication is completed through the authentication information for verification, after first checking whether an authority corresponding to the execution command is granted to the authenticated user, the authority verification result Depending on whether or not to generate the command message may be determined (see S114 in FIG. 1).

The authentication method according to the above-described embodiment of the present invention can be implemented as a computer-readable code on a computer-readable recording medium. The computer-readable recording medium includes any kind of recording medium storing data that can be read 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, and an optical data storage device. In addition, the computer-readable recording medium may be distributed over computer systems connected by a computer communication network, and stored and executed as code readable in a distributed manner.

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

Claims (10)

As an authentication system,
A device authentication agent installed on an Internet of Things (IoT) device on which a communication module is mounted, and obtaining device authentication information for authentication of the IoT device;
A mobile agent installed on a user's mobile device, obtaining user authentication information for authentication of the user, and generating an authentication request message including device authentication information and the user authentication information received from the device authentication agent; And
When the authentication request message is received from the mobile agent, the authentication information for verification corresponding to the device authentication information and the user authentication information included in the authentication request message is generated, and the IoT devices and the Includes; authentication server to determine whether the user is authentic,
The authentication server and the IoT device share a part of a key value or a seed value for generating the device authentication information in advance with each other, so that the device authentication value generated by the authentication server is device authentication generated by the IoT device Configured equal to the value,
The communication module is a beacon communication module,
The device authentication agent wirelessly broadcasts device identification information usable for identification of the IoT device and the device authentication information by inserting it into a beacon message,
The device authentication information is inserted into a major field and a minor field following a data field area in which a UUID, a beacon unique value, is inserted in the beacon message,
The major field is used as an equipment identification value, and the minor field is an authentication system used as a device authentication value.
delete delete According to claim 1,
When the device authentication information exceeds the size of the field area to be inserted, the device authentication information is converted into a value that does not exceed the size of the field area to be inserted and inserted into the beacon message.
According to claim 1,
The mobile agent,
Depending on the driving of the app running a specific application service, authentication is performed for the user of the app,
When the device identification information and the device authentication information are received through the beacon message, the authentication request message includes at least the device authentication information, but further includes at least one of the user authentication information and the device identification information to perform the authentication. Authentication system, which is sent to the server.
The method of claim 5,
The mobile agent,
An authentication system that transmits the authentication request message to the authentication server only when it is determined that the distance between the IoT device and the mobile device is within a predetermined distance based on the reception strength or sensitivity of the beacon message.
The method of claim 5,
The mobile agent,
An authentication system that uses a user token obtained when the app user authentication is completed as the user authentication information, or uses a newly generated user authentication value as the user authentication information upon receipt of the device authentication information.
The method of claim 5,
The mobile agent,
An authentication system that includes, in the authentication request message, an execution command selected by the app user in connection with an application service executed through the app and transmits it to the authentication server.
The method of claim 8,
The authentication server,
When the authentication request message is received, the authentication information for verification corresponding to the device authentication information and the user authentication information is generated, and both the authentication information for verification and the device authentication information and the user authentication information match. And generating a command message for processing so that the execution command included in the authentication request message can be executed.
The method of claim 9,
The authentication server,
When the user authentication through the authentication information for verification is completed, an authentication is performed to determine whether an authorized user is authorized to the execution command and to determine whether to generate the command message according to the result of the authorization check. system.

Images