WO2017014614A1 - Method for operating communication client of iot device, and iot device including communication client - Google Patents

Abstract

An IoT device using a peer-to-peer communication is disclosed. A method for operating a client of the IoT device, which is a method for operating a client of the IoT device using a peer-to-peer communication, comprises the steps of: generating a personal key on the basis of a public key stored in a memory; sending the personal key to a server, and receiving a key-pair generation message for the public key and the personal key from the server; sending, to the server, an identifier generation request including at least one item of unique information; receiving, from the server, an identifier corresponding to the identifier generation request and a security key corresponding to the unique information; sending an authentication request including the identifier and the security key to the server, and receiving an authentication result corresponding the authentication request from the server; in response to the authentication result, shifting to a state in which the client is capable of communication; and sending data to a counterpart client via the server by using a sharing key sent from the server according to a request for pairing with the counterpart client.

Description

A method of operating a communication client of an IOT device and an IOT device including the communication client

The embodiments below relate to a method of operating a communication client of an IoT device and to an IoT device including the communication client.

Recently, the Internet of Things (IoT) has become a hot topic.

Through this IoT, not only home appliances and electronic devices but also healthcare, remote meter reading, smart home, smart car, etc. can be connected to network and share information.

According to this technology evolution to IoT, technology development of IoT is accelerating in various companies or research institutes, but it is not easy to use in real life. This is not only difficult to give a communication function to the entities on which the IoT is based. This is because even if the communication function is given, the standard technology for how to communicate is not defined. Therefore, at present, individual communication companies are preparing IoT services based on their own technologies, but they lack generality.

Embodiments provide an IoT network based on a secure communication platform capable of assigning a communicable identifier without inputting user's personal information. In addition, embodiments provide an IoT device that operates in an IoT network and a client that enables the IoT device to communicate over an IoT network.

The method of operating a client of the IoT device may include: generating a private key based on a public key stored in a memory, using the peer to peer communication method of operating the client of the IoT device; Transmitting the private key to a server and receiving a key-pair generation message for the public key and the private key from the server; Sending an identifier generation request including one or more unique information to the server; Receiving a security key corresponding to an identifier and unique information corresponding to the identifier generation request from the server; And transmitting an authentication request including the identifier and the security key to the server, and receiving an authentication result corresponding to the authentication request from the server. In response to the authentication result, transitioning the client to a communicable state; And transmitting data to the counterpart client through a server using a shared key transmitted from the server according to a paying request with the counterpart client.

An IoT device using peer-to-peer communication includes a communication interface for peer-to-peer communication; Memory stored in the client for performing peer-to-peer communication; And a central processing unit for controlling execution of the client, wherein the client generates a private key based on the public key stored in the memory; Transmitting the private key to a server and receiving a key-pair generation message for the public key and the private key from the server; Sending an identifier generation request including one or more unique information to the server; Receiving a security key corresponding to an identifier and unique information corresponding to the identifier generation request from the server; And transmitting an authentication request including the identifier and the security key to the server, and receiving an authentication result corresponding to the authentication request from the server. In response to the authentication result, transitioning the client to a communicable state; And transmitting data to the counterpart client through a server using a shared key transmitted from the server according to a paying request with the counterpart client.

Embodiments may provide an IoT network based on a secure communication platform capable of assigning a communicable identifier without inputting user's personal information. In addition, embodiments may provide an IoT device that operates in an IoT network and a client that enables the IoT device to communicate via an IoT network. This makes it possible to easily implement IoT networks through wireless communication networks, not carrier-oriented IoT networks.

1 is a flowchart illustrating a client authentication method according to an embodiment.

2 is a flowchart illustrating a method for pairing a client of an IoT device according to an embodiment.

3 is a block diagram illustrating an IoT device according to an embodiment.

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

Various modifications may be made to the embodiments described below. The examples described below are not intended to be limited to the embodiments and should be understood to include all modifications, equivalents, and substitutes for them.

The terminology used herein is for the purpose of describing particular example embodiments only and is not intended to be limiting of examples. Singular expressions include plural expressions unless the context clearly indicates otherwise. In this specification, terms such as "comprise" or "have" are intended to indicate that there is a feature, number, step, action, component, part, or combination thereof described on the specification, and one or more other features. It is to be understood that the present invention does not exclude the possibility of the presence or the addition of numbers, steps, operations, components, components, or a combination thereof.

Unless defined otherwise, all terms used herein, including technical or scientific terms, have the same meaning as commonly understood by one of ordinary skill in the art. Terms such as those defined in the commonly used dictionaries should be construed as having meanings consistent with the meanings in the context of the related art, and are not to be construed in ideal or excessively formal meanings unless expressly defined herein. Do not.

In addition, in the description with reference to the accompanying drawings, the same components regardless of reference numerals will be given the same reference numerals and redundant description thereof will be omitted. In the following description of the embodiment, when it is determined that the detailed description of the related known technology may unnecessarily obscure the gist of the embodiment, the detailed description thereof will be omitted.

< IoT device  Secure Communication Platform (SCP)>

1 is a flowchart illustrating a client authentication method installed in an IoT device according to an embodiment.

Referring to FIG. 1, the client 110 transmits a public key request to a server (111). The server 120 issues a public key in response to the public key request received from the client 110 (121). The size of the public key may be, for example, 64 bytes, ie 512 bits. The server 120 transmits the public key to the client 110 (122). The server 120 and the client 110 may perform unencrypted communication.

The client 110 stores the public key and generates a private key (112). The size of the private key may be 64 bytes, for example. The client 110 transmits the private key to the server 120 (113). The client 110 may encrypt the private key using the public key, and transmit the encrypted private key to the server 120. The server 120 receives a private key from the client 110. Since the server 120 has a public key, the server 120 can decrypt the encrypted private key using the public key.

The server 120 maps the public and private keys to key-pairs (123). The server 120 may store the mapped key-pair in the server 120 (124). The server 120 transmits a key-pair generation message to the client 110 (125). The server 120 may encrypt the key-pair generation message using the private key.

The client 110 confirms the generation of the key-pair using the key-pair generation message. Client 110 stores the key-pair (114). For example, when the generation of the key-pair is confirmed, the client 110 may map the private key and the public key to the key-pair, and store the mapped key-pair in the client 110.

In the example shown in FIG. 1, the key-pair may be stored at the client 110 and the server 120. The storage location of the above-mentioned key-pair is merely an exemplary matter, and the storage location of the key-pair is not limited to the above-described matter. For example, the key-pair may be stored in either client 110 or server 120.

The client 110 transmits an identifier generation request including the unique information to the server 120 (115). The identifier generation request may be encrypted using a private key. The unique information may include, for example, at least one of a device unique key corresponding to a physical device on which the client 110 is installed or an operating system (OS) and a manufacturing key corresponding to communication software executed on the client 110. It may include.

The physical device of the client 110 may include, for example, at least one of a CPU and a micro processor unit (MPU). The device unique key may be obtained from identification information of the CPU or identification information of the MPU. The operating system stored in the client 110 may have unique information to distinguish it from other operating systems. As a result, the client 110 may obtain the device unique key from the unique information of the operating system.

The manufacturing key may include a site key, a manufacturer key, and a product key. The site key corresponds to site information. Site information may, for example, represent information based on site IP addresses. The manufacturer key corresponds to the manufacturer information. The manufacturer information may, for example, represent identification information of the manufacturer who manufactures the communication software. The product key corresponds to version information of the communication software.

The device unique key and the manufacture key may have a predetermined size. For example, the device unique key may be 128 bits in size and the manufacturing key may be 208 bits in size. Similarly, the site key, manufacturer key, and product key may have a predetermined size. For example, the size of the site key may be 80 bits, the size of the manufacturer key may be 64 bits, and the size of the product key may be 64 bits.

The manufacturing key may be configured in the order of the site key, the manufacturer key, and the product key. The order of the site key, the manufacturer key, and the product key is exemplary only, and the order of the site key, the manufacturer key, and the product key is not limited to the above-described matters.

The server 120 generates a security key. In an embodiment, the server 120 may generate a security key corresponding to the unique information of the client 110. For example, when the server 120 receives a device unique key and a manufacturing key from the client 110, the server 120 may generate a security key by modifying the device unique key and the manufacturing key. The server 120 may generate a 256-bit security key based on the 128-bit device unique key and the 208-bit manufacturing key. As will be described later, a security key can be used to encrypt a packet exchanged between a client and another client.

Server 120 generates an identifier. The size of the identifier may be 64 bytes, for example. The identifier will be described below.

When there is a request for generating an identifier of the client 110, the server 120 may randomly generate an identifier and assign the identifier to the client 110. The identifier may be any one of n-digit random values n ^ n based on n pieces of distinguishing information. For example, when 64 pieces of distinguishing information of 1 byte, the identifier may be any one of 64 ^ 64 random values having 64 digits. The server 120 may randomly arrange 64 pieces of distinguishing information to generate an identifier. The server 120 may check whether the identifier overlaps with another identifier, and if not, assign the identifier to the client 110. As a result, the identifier may be unique for each client 110. The server may use the identifier to distinguish between the client 110 and another client.

A hash index may be embedded in the identifier. The size of the hash index may be 64 bits, for example. The server 120 may embed the hash index in the identifier using the conversion logic. For example, suppose the size of the identifier is 64 bytes. The server 120 may apply the conversion logic to a specific bit contained in the first byte. When the conversion logic is applied to a specific bit, the specific bit may or may not change to another bit. If the particular bit has a first logic value, the particular bit may be changed to or maintained by the conversion logic by the second logic value. The specific bit may be one, for example. The server can apply the conversion logic to specific bits contained in the remaining bytes. As a result, some of the string of identifiers can be changed, and a hash index can be embedded in the identifier. For example, if the identifier is a string of ABCD, ABCD may be AZDD by the conversion logic, and a hash index may be embedded in AZDD.

The server 120 may access the database using a hash index obtained from the identifier instead of the identifier of the client 110. The server 120 may transmit the query based on the hash index to the database without transmitting the query based on the identifier of the client 110 to the database. The database may compare the hash index and the DB index without comparing the string of the identifier of the client 110 and the string of the plurality of identifiers stored in the database. This may increase the response speed of the database or the speed of searching the database.

The server 120 generates a question for maintaining the UDP session to the client 110. Server 120 may embed a hash index in the query. The server 120 sends the question to the client 110.

When the client 110 receives a question, the client 110 may generate an answer. Here, if the answer corresponds to a question, the UDP session may be maintained, and if the answer does not correspond to the question, then the UDP session is not maintained and is released.

The generated answer contains a hash index. The client 110 may transmit an answer in which the hash index is embedded to the server 120.

The server 120 checks the answer of the client 110. Server 120 may obtain a hash index from the answer. For example, the server 120 may obtain a hash index by performing an XOR operation on the bytes included in the answer. In order to maintain the UDP session, the server 120 may check the identifier of the client 110. Since the server 120 obtains the hash index, the server 120 may access the database in which the identifier is stored using the hash index. The database may transmit an identifier corresponding to the hash index to the server 120. As a result, the server 120 can identify the client 110 through a response to a query based on a hash index, without receiving an identifier from the client 110, thereby identifying the client 110 more quickly. have. As a result, the validation of the UDP session can be confirmed faster, and the UDP session can be maintained. In addition, even if the IP address of the client 110 is changed, the server 120 may quickly identify the client 110 using a hash index. As a result, even in an environment in which IP changes, such as P2P communication, validation of a UDP session can be confirmed, and a UDP session can be maintained.

When the server 120 generates the identifier and the security key (126), the server 120 transmits the identifier and the security key to the client 110 (127). The identifier and security key can be encrypted using a private key.

Client 110 stores the identifier and the security key (116). The client 110 may transmit an authentication request including the identifier and the security key to the server 120 (116). The authentication request can be encrypted using the private key.

The server 120 may check the identifier and the security key received from the client 110. More specifically, the server 120 may check whether the identifier and the security key received from the client 110 are the same as the identifier and the security key generated in step 125.

The server 120 authenticates the client 110 based on the identifier and the security key received from the client 110, and transmits the authentication result to the client 110 (129). The authentication result can be encrypted using the private key.

The client 110 may transition to a state in which it can communicate with other clients according to the authentication result. The server may authenticate other clients, and other clients may transition to a communicable state. As a result, a list of other clients may be displayed in the communication software running on the client 110. The client 110 and another client may enter an operation mode capable of peer-to-peer communication or direct communication. When the client 110 communicates PPI with another client, the client 110 may encrypt the packet by using the security key, and transmit the encrypted packet to the other client.

<Secure Communication Platform ( SCP Between clients Pairing >

2 is a flowchart illustrating a method for pairing a client of an IoT device according to an embodiment.

2, the client 210 transmits an authentication request to the server 220.

The server 220 authenticates the client 210 (221). The server 220 may authenticate the client 210 by the authentication method described above. The authentication result is encrypted using the private key. The server 220 transmits the authentication result to the client 210 (222).

The client 210 decrypts the authentication result using the private key. If the client 210 is authenticated, the client 210 transitions to a communicable state (212). The client 210 may transition to a peer-to-peer communication state.

The client 210 generates a paying request with the client 230 to the server 220 (213), and transmits a pairing request to the server 220 (214).

The server 220 generates a connection unique key between the clients 210 and 230 (223).

The server 220 transmits a wakeup signal to the client 230 that the client 210 requests paying (224).

The client 230 transitions to the communicable state in response to the wakeup signal transmitted from the server 220 (231). The client 230 is previously given a security key and an identifier for P2P communication in the secure communication platform according to the method shown in FIG. 1.

The client 230 transmits an authentication request to the server 220 (232).

The server 220 authenticates the client 230 (225), and transmits the authentication result to the client 230 (226).

The server 220 transmits the shared key to the client 210 (227).

The server 220 transmits the shared key to the client 230 (228).

The client 210 stores the shared key transmitted from the server 220 (214), and transmits data to be transmitted to the client 230 to the server 220 (215). The data may be encrypted with a shared key.

The client 230 stores the shared key transmitted from the server 220 (233), and receives the data transmitted by the client 210 from the server 220 (229).

Client 230 interprets the data (234). The client 230 may decrypt the data with a shared key.

Although FIG. 2 illustrates an example of data transmission from the client 210 to the client 230, data transmission from the client 230 to the client 210 may be performed in the same manner. 210 may be an IoT sensor, and the client 230 may be a collector that collects sensing data collected by the IoT sensor, hereinafter with reference to FIG. Explain.

Network based IoT Device  Communication>

According to an embodiment, network-based IoT devices operate in the secure communication platform described with reference to FIGS. 1 and 2.

3 is a diagram illustrating a structure of an IoT device according to an embodiment. The IoT device may include the following component parts, and a client for enabling peer-to-peer communication in a secure communication platform may be installed in the memory of the IoT device. The IoT Davias may further include a sensor unit (not shown) that senses various physical quantities such as temperature / light / pressure / humidity.

Referring to FIG. 3, an IoT device 300 according to an embodiment includes a power supply unit 301, a memory 302, a central processing unit 303, and a communication interface 304.

The power supply unit 301 may be a battery-type power supply, and may be a power storage unit including a capacitance capable of storing power for driving an IoT device for up to 5 seconds.

The memory 302 encrypts and stores a ROM or RAM in which a client for peer-to-peer communication described with reference to FIGS. 1 and 2 and a unique key of the IoT device or data of the IoT device, or stores a public key / private key. May include an EEPROM. Communication software included in the client may perform the following operations.

(1) Receive a public key corresponding to the public key request from the server through a communication interface and generate a private key.

(2) The communication software transmits the private key to the server via the communication interface, and receives a key-pair generation message for the public key and the private key from the server through the communication interface.

(3) The communication software sends an identifier generation request including one or more unique information of the client to the server through the communication interface.

(4) The communication software receives from the server via the communication interface an identifier corresponding to the identifier generation request and a security key corresponding to the unique information.

(5) The communication software sends an authentication request including the identifier and the security key to the server via the communication interface.

(6) The communication software receives an authentication result corresponding to the authentication request from the server through the communication interface.

(7) The communication software controls the client to make the client transition to a state in which the client can communicate with other clients according to the authentication result. As a result, the client may enter an operation mode in which P2P communication or direct communication is possible with other clients authenticated by the server.

 Multiple IoT devices authenticated on a secure communication platform in the above manner may be paired with other IoT devices in the manner shown in FIG. 2, and may transmit and receive data with each other.

The central processing unit 303 controls the execution and operation of the client as well as the firmware and other software of the IoT device recorded in the memory 302.

The communication interface 304 enables the IoT device 300 to communicate peer-to-peer on a secure communication platform. The communication interface 304 may include an interface for a wireless wide area network (WWAN) or a wireless local area network (WLAN). WWANs are code division multiple access (CDMA) networks, time division multiple access (TDMA) networks, frequency division multiple access (FDMA) networks, orthogonal frequency division multiple access (OFDMA) networks, and / or single-carrier frequency division (SC-FDMA). Multiple Access) network or any combination thereof. The WLAN may comprise an IEEE 802.11x network. In addition, the communication interface 304 may include Bluetooth, Radio Frequency Identification (RFID), Infrared Data Association (IrDA), Ultra-Wideband (UWB), ZigBee, Near Field Communication (NFC), or Z-wave. And the like.

If the IoT device 300 further includes a sensor unit, the IoT device 300 may be paired with a collector (not shown) that is responsible for collecting sensing data, and connected to a collector through P2P communication described with reference to FIGS. 1 and 2. The sensing data can be transmitted. In this case, the collector may be implemented to transmit driving power to the power supply unit 301 of the IoT device 300.

IoT device 300 operating in a secure communication platform according to another embodiment may operate as follows.

(1) The IoT device 300 may have been granted the public key described with reference to FIG. 1 but may not store the private key. The public key may be previously given in the manufacturing process of the IoT device 300.

(2) After the initial connection with the secure communication platform or collector, the private key may be granted by exchanging the private key with the server or collector of the secure communication platform. The granted private key may be stored in an One Time Programmable (OTP) region of the EEPROM included in the memory 302 of the IoT device 300.

(3) After exchanging the private key with the server or collector of the secure communication platform, all data in the IoT device 300 may be encrypted and stored with the public key and / or the private key. This encryption process can improve the integrity and security of the data.

(4) When a sensor is included in the IoT device 300, the IoT device 300 may be powered by a passive RFID method from the collector by using RF while continuously communicating with the collector. The IoT device 300 may store the sensing data sensed by the sensor in an EEPROM of the memory 302. When the IoT device 300 receives a sensing data request from the collector, the IoT device 300 may encrypt the sensing data stored in the EEPROM with a private key, and then encrypt it with the public key, and transmit the sensing data to the collector together with the RFID unique key value. The collector may first decrypt the sensed data encrypted with the public key, and secondly decrypt the sensed data by finding a private key with an RFID unique key value. The collector may store sensing data for each RFID unique key value in a storage means.

(5) The collector periodically transmits the encrypted sensing data to the secure communication platform using the public and private keys received from the secure communication platform. The user must register the collector by connecting to the secure communication platform. When the collector is registered on the secure communication platform, the server of the secure communication platform issues an RFID unique key value to the collector. The user can browse the sensing data transmitted from the collector by using the RFID unique key value issued to the collector.

(6) For the security of the sensed data, an encryption scheme such as SSL 3.0 / TLS 1.0+ or AES128 / AES256 can be used.

The apparatus described above may be implemented as a hardware component, a software component, and / or a combination of hardware components and software components. For example, the devices and components described in the embodiments are, for example, processors, controllers, arithmetic logic units (ALUs), digital signal processors, microcomputers, field programmable gate arrays (FPGAs). Can be implemented using one or more general purpose or special purpose computers, such as a programmable logic unit (PLU), a microprocessor, or any other device capable of executing and responding to instructions. The processing device may execute an operating system (OS) and one or more software applications running on the operating system. The processing device may also access, store, manipulate, process, and generate data in response to the execution of the software. For convenience of explanation, one processing device may be described as being used, but one of ordinary skill in the art will appreciate that the processing device includes a plurality of processing elements and / or a plurality of types of processing elements. It can be seen that it may include. For example, the processing device may include a plurality of processors or one processor and one controller. In addition, other processing configurations are possible, such as parallel processors.

The software may include a computer program, code, instructions, or a combination of one or more of the above, and configure the processing device to operate as desired, or process it independently or collectively. You can command the device. Software and / or data may be any type of machine, component, physical device, virtual equipment, computer storage medium or device in order to be interpreted by or to provide instructions or data to the processing device. Or may be permanently or temporarily embodied in a signal wave to be transmitted. The software may be distributed over networked computer systems so that they may be stored or executed in a distributed manner. Software and data may be stored on one or more computer readable recording media.

The method according to the embodiment may be embodied in the form of program instructions that can be executed by various computer means and recorded in a computer readable medium. The computer readable medium may include program instructions, data files, data structures, etc. alone or in combination. The program instructions recorded on the media may be those specially designed and constructed for the purposes of the embodiments, or they may be of the kind well-known and available to those having skill in the computer software arts. Examples of computer-readable recording media include magnetic media such as hard disks, floppy disks, and magnetic tape, optical media such as CD-ROMs, DVDs, and magnetic disks, such as floppy disks. Magneto-optical media, and hardware devices specifically configured to store and execute program instructions, such as ROM, RAM, flash memory, and the like. Examples of program instructions include not only machine code generated by a compiler, but also high-level language code that can be executed by a computer using an interpreter or the like. The hardware device described above may be configured to operate as one or more software modules to perform the operations of the embodiments, and vice versa.

Although the embodiments have been described by the limited embodiments and the drawings as described above, various modifications and variations are possible to those skilled in the art from the above description. For example, the described techniques may be performed in a different order than the described method, and / or components of the described systems, structures, devices, circuits, etc. may be combined or combined in a different form than the described method, or other components. Or even if replaced or substituted by equivalents, an appropriate result can be achieved.

Therefore, other implementations, other embodiments, and equivalents to the claims are within the scope of the following claims.

Claims (11)

In the method of operation of the client of the IoT device using peer-to-peer communication, Generating a private key based on the public key stored in the memory; Transmitting the private key to a server and receiving a key-pair generation message for the public key and the private key from the server; Sending an identifier generation request including one or more unique information to the server; Receiving a security key corresponding to an identifier and unique information corresponding to the identifier generation request from the server; And Transmitting an authentication request including the identifier and the security key to the server, and receiving an authentication result corresponding to the authentication request from the server; In response to the authentication result, transitioning the client to a communicable state; And Transmitting data to the counterpart client through the server using a shared key transmitted from the server according to a paying request with the counterpart client; Including, Method of operation of the client of the IoT device. The method of claim 1, The at least one unique information is, A device-specific key of the IoT device and a manufacturing key corresponding to communication software running on the client, Method of operation of the client of the IoT device. The method of claim 1, The private key is stored in a predetermined area of the memory, Method of operation of the client of the IoT device. The method of claim 1, The IoT device includes a sensor unit, The counterpart client is a collector; Method of operation of the client of the IoT device. The method of claim 1, The data is encrypted with the shared key, Method of operation of the client of the IoT device. The method of claim 4, wherein The IoT device is powered from the collector. Method of operation of the client of the IoT device. In an IoT device using peer-to-peer communication, A communication interface for peer-to-peer communication; Memory stored in the client for performing peer-to-peer communication; And Central processing unit for controlling the execution of the client Including, The client, Generating a private key based on the public key stored in the memory; Transmitting the private key to a server and receiving a key-pair generation message for the public key and the private key from the server; Sending an identifier generation request including one or more unique information to the server; Receiving a security key corresponding to an identifier and unique information corresponding to the identifier generation request from the server; And Transmitting an authentication request including the identifier and the security key to the server, and receiving an authentication result corresponding to the authentication request from the server; In response to the authentication result, transitioning the client to a communicable state; And Transmitting data to the counterpart client through the server using a shared key transmitted from the server according to a paying request with the counterpart client; To do, IoT device. The method of claim 7, wherein The private key is stored in a predetermined area of the memory, IoT device. The method of claim 7, wherein The IoT device includes a sensor unit, The counterpart client is a collector; IoT device. The method of claim 7, wherein The data is encrypted with the shared key, IoT device. The method of claim 9, Power supply More, The power supply unit receives power from the collector. IoT device.

Images