WO2020096162A1 - Method and device for secure communication in wireless communication system - Google Patents

Abstract

The present invention relates to a secure communication method performed by a first device. The present invention relates to a method and device for: searching an IoT device which belongs to a network configured by a second device and which is preset to perform secure communication with the second device; checking whether the IoT device supports Anonymous Credential Generation (ACG); if the IoT device supports ACG, performing secure certification for performing the secure communication with the IoT device even when a security-related message has not been received from the second device; and performing the secure communication with the IoT device on the basis of the secure certification.

Description

Method and apparatus for secure communication in wireless communication system

The present invention relates to an Internet of Things (IoT) device and a method performed in connection with an IoT device. Specifically, the present invention relates to secure communication between IoT devices.

With the development of IoT technology, an environment in which various electronic devices in the home are connected to each other through a network to share information has been created.

The Open Interconnect Consortium (OIC) was established to standardize to secure interoperability between IoT devices. Since then, OIC and UPnP (Universal Plug and Play) have been integrated to form the Open Connectivity Foundation (OCF).

The OCF standardization organization is developing technologies for providing IoT services and open platforms, such as communication between IoT devices and cloud use, and linking with other IoT standards (oneM2M, OMA LWM2M, BLE, Zigbee, Z-Wave, GENIVI, etc.) Planning.

An apparatus for providing a service according to the OCF standard includes a server for providing a resource and a client for accessing the resource.

In this environment, methods for efficiently constructing a secure network based on the OCF standard have been proposed.

The technical problem to be achieved by the present invention is to provide a secure communication method for a client entering a network and a device therefor.

The technical problem of the present invention is not limited to the above-described technical problem, and other technical problems can be inferred from the embodiments of the present invention.

The present invention provides a secure communication method and apparatus in a wireless communication system.

As an aspect of the present invention, a secure communication method performed by a first device in a wireless communication system includes: searching for an Internet of Things (IoT) device belonging to a network configured by a second device, the IoT device Is pre-set to perform secure communication with the second device; Checking whether the IoT device supports ACG (Anonymous Credential Generation); If the IoT device supports ACG, performing security authentication to perform secure communication with the IoT device even if there is no security-related message received from the second device; And performing secure communication with the IoT device based on the security authentication. It may be configured to include.

A first device for performing secure communication in a wireless communication system includes: a transceiver; And a processor that controls the transceiver. Including, wherein the processor, Internet of Things (Internet of Things) belonging to the network configured by the second device (Internet of Things; IoT) device is searched, and the IoT device is preset to perform secure communication with the second device, Check whether the IoT device supports ACG (Anonymous Credential Generation), and if the IoT device supports ACG, security authentication to perform secure communication with the IoT device even if there is no security-related message received from the second device And performing secure communication with the IoT device based on the security authentication.

In the above method and device, the IoT device may include an access control list (ACL) resource for indicating a list of resources accessible by the first device.

In the above method and device, the ACL resource may include information on resources accessible by the first device even when the first device is not previously authenticated by the second device.

In the method and apparatus, the security authentication is performed by generating a Pre-Shared Key (PSK) based on one or more of PIN, ID / password and / or QR (Quick Response), and the secure communication is It can be performed based on the generated PSK.

In the method and device, the secure authentication and secure communication may be performed based on a certificate pre-stored in the first device and the IoT device.

The above-described aspects of the present invention are only some of the preferred embodiments of the present invention, and various embodiments in which the technical features of the present invention are reflected are detailed by the person skilled in the art to be described below. It can be derived and understood based on description.

According to an embodiment of the present invention, by providing a new secure communication method for a client newly entering the network, there is an advantage that it is possible to perform secure communication more efficiently without the aid of the device that created the first network.

The technical effects of the present invention are not limited to the above-described technical effects, and other technical effects can be inferred from embodiments of the present invention.

1 is a view showing the connectivity and interoperability of the OCF platform.

2 is a diagram showing the framework structure of the OCF platform.

3 is a diagram for receiving requests and responses between a client, an intermediary, and a server.

4 is a diagram showing a protocol stack that can be supported in the OCF standard.

5 is a diagram showing a wide range of functions that can be supported through OCF.

6 is a diagram illustrating an example of performing a CRUDN operation.

7 is a view showing an example of the operation of the OCF system based on the onboarding tool.

8 is a diagram illustrating an example of a DTLS encryption suite method.

9 to 15 are views illustrating secure communication according to an embodiment of the present invention.

16 shows a flow chart according to an embodiment of the present invention.

17 shows an apparatus according to an embodiment of the present invention.

Hereinafter, preferred embodiments of the present invention will be described in detail with reference to the accompanying drawings. DETAILED DESCRIPTION The following detailed description, together with the accompanying drawings, is intended to describe exemplary embodiments of the present invention, and is not intended to represent the only embodiments in which the present invention may be practiced. The following detailed description includes specific details to provide a thorough understanding of the invention. However, one skilled in the art knows that the present invention may be practiced without these specific details.

In some cases, in order to avoid obscuring the concept of the present invention, well-known structures and devices may be omitted, or block diagrams centered on core functions of each structure and device may be illustrated. In addition, the same components throughout the specification will be described using the same reference numerals.

To clarify the description, the 3GPP-based mobile communication system is mainly described, but the technical spirit of the present invention is not limited thereto. The following technology can be used for various IoT services or platforms, such as oneM2M, OMA LWM2M, BLE, Zigbee, Z-Wave, GENIVI. In addition, specific terms used in the following description are provided to help understanding of the present invention, and the use of these specific terms may be changed to other forms without departing from the technical spirit of the present invention.

OCF Overview

1 is a view showing the connectivity and interoperability of the OCF platform.

OCF defines a common platform that presents basic services and data models that connect and collaborate with various verticals such as health, smart home, and industrial IoT. The OCF platform provides connectivity level, platform level, and connectivity between service layers. In addition, the OCF platform provides full interoperability through user experience (UX).

The OCF standard defines data structures, types, properties, and interfaces for resources. In addition, the OCF standard includes device authentication, security functions, access control to resources in the OCF network, discovery of devices that may be included in the OCF network, and commands for resources (CREATE, RETRIEVE, UPDATE, DELETE, and NOTIFY; CRUDN) ), A message for resources, and a frame for connecting the OCF network and the Internet network (IPv6, etc.).

OCF Framework Architecture

2 is a diagram showing the framework structure of the OCF platform.

The operation and main concepts of the OCF platform will be described with reference to FIG. 2. The conceptually described contents, which will be described below, may be a resource model, a RESTful operation, or an abstraction, and may be a basic characteristic for OCF operations and standards.

The OCF device may support one or more roles of client, server and / or intermediary. The role that the OCF device can support may be a region of a logical entity, and one OCF device may support one or more roles. In the following description, 'device' may refer to a physical device including a logical entity, or may refer to the logical entity itself.

The client device means a device that serves to access a server resource.

The server device means a device that provides resource state information and is capable of performing remote interaction on the resource.

The intermediary device means a device that provides an OCF proxy role. In other words, it is a device that acts as an intermediary for processing request messages for OCF resources hosted by the server device.

In the following description, states, values, and information about resources may be used in the same sense.

The client can request the CRUDN operation for the resource from the server. The server can perform the CRUDN operation requested by the client. Resource designation and operation designation between the client and the server may be performed based on a RESTful resource model. Intermediary can generate another request according to the processing configuration and return a response to the generated request to the OCF server based on the request to process the OCF resource hosted by another OCF server. have.

The resource model corresponds to the actual entity represented by the OCF resource.

The CRUDN operation between the client-server originating from the upper layer (eg OCF client, OCF server), the CoAP (Constrained Application Protocol) request and CoAP response, or XMPP (Extensible Messaging and Presence Protocol) in the lower layer (eg OCF device). Can be passed through.

CRUDN operation occurs between the OCF client and the OCF server. CRUDN operation may be transmitted and received through a signaling message (signaling message, e.g. GET / s / data, {"bulb": "on"}) of CoAP request and CoAP response through protocol mapping. The CRUDN operation may be transmitted and received through Hypertext Transfer Protocol (HTTP) and / or XMPP other than CoAP through protocol mapping.

Alternatively, when a client, an intermediary, and a server are connected as shown in FIG. 3, the request and response between the client and the intermediary may be transmitted and received through HTTP, and the request and response between the intermediary and the server may be transmitted and received through CoAP. .

OCF Protocol Stack

4 shows a protocol stack that can be supported in the OCF standard.

The encoding layer of the protocol stack illustrated in FIG. 4 supports CBOR (Concise binary object representation based on JSON data model) by default. However, JSON (JavaScript Object Notation) and / or XML / EXI (Efficient XML Interchange) may be used by negotiation between the client and the server.

CoAP Discovery is used for discovery of the end point (IETF RFC 7252).

For connection with the L2 layer, IPv6 for IoT devices exists. To secure the security of the transport layer, a datagram transport layer security (DTLS) layer may exist on the user datagram protocol (UDP) layer. In addition, a transport layer security (TLS) layer may exist on the transport control protocol (TCP) layer to secure the security of the transport layer.

OCF Framework Block Diagram

FIG. 5 is a diagram illustrating functions supportable through the OCF at a high level.

The functions supported by the OCF framework are shown in Table 1 below.

[Table 1]

In the lower layer, the functions described through Table 1 may be performed in the L2 connectivity and networking layers. The L2 connectivity layer may use existing wireless communication technologies such as Wi-Fi (wireless fidelity), BT (blootooth) and / or Z-wave.

In the OCF framework, the functions described through Table 1 can be performed.

In the application layer, individual profiles (data models, functions, etc.) for markets are created by OCF. As an example, a smart home data model exists.

CRUDN Operation

CRUDN operation is an operation that can be requested for a resource, and there may be 5 commands as shown in Table 2. When the client sends a command, the server including the resource executes a CRUDN command for the resource.

[Table 2]

6 shows an example of performing a CRUDN operation. First, the client sends a Create request to the server during CRUDN operation. The server that receives the Create command performs Create on the resource. The server that created the resource sends a response to the request received from the client.

Table 3 shows parameters that may be included in the CRUDN message.

[Table 3]

OCF security technology

As described above, in the OCF system, IoT devices and related functions are modeled in the form of devices and resources that computers can understand, and communication is performed through CRUDN Restful operations between devices. Here, the client device starts communication between devices by performing a role of accessing a server resource. The server device provides resource status information according to a command requested by the client device, and performs remote interaction on the resource.

Among the server resources, there are Secure Virtual Resources (SVRs) as a special resource that all OCF devices must have in order to set security functions. In SVRs, only Onboarding Tool (OBT) and service entities with access rights are accessible.

Onboarding is for initial setup for a new IoT device, and is for one or more of ownership transfer, access control setup and / or credential setup. The service entity may include one or more of Device Ownership Transfer Service (DOTS), Access Manager Service (AMS) and / or Certification Management Service (CMS).

For message encryption between IoT devices, DTLS (Datagram Transport Layer Security) may be used in D2D (Device-to-Device) communication of the User Datagram Protocol (UDP) method. Transport layer security (TLS) may be used in D2C (Device-to-Central) communication of the Transmission Control Protocol (TCP) method. Encryption communication may be performed through handshaking based on cipher suites between devices, generation of a session key, and the like.

The IoT device-to-device authentication may be performed based on a credential during DTSL or TLS process. Credentials include asymmetric keys and / or certificates that can be pre-shared keys, symmetric keys, public keys, or private keys. Certificate, eg X.509 certificate).

The access authority for the OCF resource may be set / managed by access control entries (ACEs) and / or access control lists (ACLs).

The SVR may include the following resources.

The / oic / sec / doxm resource is a resource for managing a device ownership transfer method. In the / oic / sec / doxm resource, Device UUID (universally unique identifier) indicating the ID of the device itself, Device Owner UUID indicating the UUID of the unique administrator device (OBT), Ownership Transfer Method, Select indicating the support method for the ownership transfer method , Owned for ownership setting status information may be included as a resource.

/ oic / sec / pstat is a resource for managing provisioning status. The / oic / sec / pstat resource may include a Resource Owner ID indicating a unique administrator ID accessible to the resource and a Current Provisioning Mode indicating whether provisioning status can be set as a resource.

/ oic / sec / cred is a resource for managing credentials. The / oic / sec / cred resource may include a Resource Owner ID indicating the unique management or ID that can access the resource, and Credential for storing credentials required for device authentication in an array form.

/ oic / sec / acl2 is a resource for managing access control lists. The / oic / sec / acl2 resource may include a Resource Owner ID indicating the only management or ID that can access the resource, and an Access Control Entries for storing information required for device access control in an array form.

In addition, / oic / sec / amacl, which is responsible for managing ACL settings, and / oic / sec / roles for defining roles for each device may be included as resources in the SVR. Roles for each device may include an administrator, a user, and a guest.

The basic flow of onboarding related to security setting is as follows.

First, when the power of the new OCF device is turned on (power-on), the new OCF device may be searched by OBT (e.g. DOTS). In order for DOTS to search for devices that are not yet owned (un-owned), CoAP messages can be transmitted in a multicast manner to the same IP subnet (internet protocol sub-net) by a specific URL (Uniform Resource Locator). . For example, Retrieve / oic / res as an OCF resource, ff02 :: 158 as an IPv6 multicast address, and port5683 as a port for message transmission may be used. A device that has received a CoAP message that does not have ownership in the DOTS sends a response including information on how to transfer ownership. The ownership transfer method may include one or more of an Ownership Transfer Method (OTM), Just Works (JW), Personal Information Number (PIN), and / or certificate method. The JW method means a method of not performing separate authentication at the time of initial connection at the time of OBT and new device.

Transfer of ownership may mean transferring authority related to the IoT device from the manufacturer of the IoT device to the purchaser of the IoT device. DOTS selects one of the OTM methods currently supported by new devices without ownership. (D) DLS handshaking is performed between the DOTS and the device without ownership, and then transfer of ownership is performed. Transfer of ownership may include setting a specific OBT (or DOTS) as the manager of the new device. DOTS may provide the ID of the AMS / CMS for credential and / or access setup to be used later on the device without ownership.

In addition, provisioning may be performed to provide a credential that requires an authorized CMS and an access policy that requires an authorized AMS to a new device.

When the client device and the server device have credentials that can be verified with each other and have access to each other, the client device and the server device can communicate with each other.

An example of an onboarding tool is a mobile phone or TV application. Alternatively, the onboarding tool may be one of the devices exemplified in the following device drawings (FIG.).

7 shows an example of the operation of the OCF system based on the onboarding tool.

In the fire detector and automatic door of Fig. 7, a specific mobile phone having a device ID of 0x0001 is set as a device (onboarding tool) having administrator authority. The device ID may be stored in / oic / sec / doxm, / oic / sec / cred /, / oic / sec / acl2 resources.

If one of the fire detectors or automatic doors is a new OCF device, OBT needs to set the security function of the new OCF device to communicate with the existing OCF device. If a specific mobile phone with a device ID of 0x0001 operates as an onboarding tool, only the specific mobile phone can set security management functions (e.g. ownership / credential / access).

With the exception of device discovery in OCF, packet-level encryption and decryption is used for all communications. DTLS or TLS protocols may be used for encrypted communication. However, the encryption suite may vary depending on the method of transferring ownership. An encryption suite means a combination of encryption protocols.

8 shows an example of a DTLS encryption suite method that can be used when the ownership transfer method of a new device is a Just works method. When the new device follows the Just works method, the onboarding tool and the new device can perform encrypted communication between devices by transmitting and receiving the messages shown in FIG. 8.

On-boarding tools and OCF devices can authenticate each other by one of just works, PIN, and certificate. The onboarding tool may set authentication methods and credentials between OCF devices so that the OCF devices that have been authenticated with themselves can perform authentication and communication with each other.

As an authentication method, symmetric key credentials may exist. When there are two OCF devices that need to communicate with each other, the CMS of the onboarding tool can inform each of the two OCF devices in advance the credential of the other OCF device. When DTLS handshaking is performed between two OCF devices, the server device first delivers the credentials set from the onboarding tool to the client device through the ServerKeyExchange message. The client device may authenticate whether the received credential is a credential included in the list of credentials that it has. In addition, the client device may perform authentication whether the subject ID connected with the received credential is the same as the server device ID. If necessary, the server device may perform verification on the client's credential.

Also, asymmetric key credentials may exist as an authentication method. In the manufacturing stage of the IoT device, each device may have a secret key and / or a public key. Alternatively, each device may include a pair of a secret key and a public key. The public key may be pre-distributed to devices in the network to which the onboarding tool belongs through the onboarding tool. Each OCF device transmits data signed with its own secret key when DTLS handshaking is performed. Authentication between the OCF devices can be performed by the OCF devices receiving the secret key decrypting the message through the public key.

Also, a certificate method may exist as an authentication method. In the manufacturing stage of IoT devices, each device holds an OCF-accredited certificate issued by the manufacturer and / or a certificate issued through a CA (Certificate Authoroty). When each OCF device exchanges certificates when DTLS handshaking is performed, authentication between OCF devices can be performed.

In addition, access rights to specific resources may be limited for each device. As illustrated in FIG. 9, when there is a device having a device ID of 0x0001, the device may check the on / off state of the light bulb, but may not have the authority to command the light on or off. Referring to FIG. 8, if a device having a device ID of 0x0001 sends a Retrieve message to a light bulb to check whether the light bulb is on, the light bulb sends a response message to the Retrieve message to indicate that the light bulb is on and the device ID is 0x0001. You can tell the device. If the device with device ID 0x0001 does not have permission to update the resource of the light bulb, even if the device with device ID 0x0001 sends an Update message, the bulb confirms that the device does not have Update permission, and then requests without updating the resource. You can send a response to rejection.

When a network is configured in an existing OCF system, only one onboarding tool can be allowed in one network. Only one DOTS, AMS and CMS can be allowed on a network. However, when an IoT network is constructed, there are cases where multiple onboarding tools will coexist. In the existing OCF system, since one onboarding tool is premised on one network, devices set by the different onboarding tools cannot communicate with each other.

10 shows security settings by a plurality of onboarding tools. Mutual authentication between client A and server A may have been performed by onboarding tool A, and client B may have been authenticated by onboarding tool B. Since the client B and the server A have been authenticated by different onboarding tools, communication between devices is impossible.

In order for the client and the server to perform secure communication, both the client and the server must have credentials to enable mutual authentication. Credentials can be pre-shared symmetric keys, asymmetric keys and / or certificates, as described above. In addition, in order for the client and the server to perform secure communication, the client must be granted access authority so that the client can access the server's resources.

Credentials can be self-generated by in-device applications. Alternatively, a certificate may be issued at the time of manufacture of the device. Alternatively, the CMS designated at the time of onboarding by the onboarding tool may dynamically manage the credentials.

In addition, the AMS designated at the time of onboarding can perform access control related to access authority.

Also, CMS and AMS may be implemented as a part of the onboarding tool. As described above, the onboarding tool may be implemented in the form of an application of a smartphone and / or TV.

New IoT devices that are not secured through the onboarding tool may not be able to communicate with existing IoT devices. Also, a client application accompanying an onboarding tool function may be difficult to onboard by other onboarding tools. A smartphone including a client application accompanying the function of an onboarding tool may be difficult to enter an OCF network configured by another onboarding tool through the corresponding client.

The OCF network is configured by a specific onboarding tool, so that credentials and access control settings can be completed for IoT devices. Subsequently, the onboarding tool that configures the OCF network may be out of range of the network. If the onboarding tool that constituted the original OCF network does not exist in the OCF network, there is no way to allow a new client to enter the OCF network.

In order to solve this problem, the present specification proposes a method in which a new client device can directly generate a credential by authenticating the device directly without the intervention of a device having ownership of the OCF network. Credential generation by a new client may be possible only when a device having ownership of the OCF network has previously allowed credential generation by a new client.

11 shows a flow chart according to an embodiment of the present invention.

Referring to FIG. 11, when an application including an on-boarding tool is executed on a specific device, the on-boarding tool can search in a multicast manner whether a device owned by another on-boarding tool exists. If a device is already owned by another onboarding tool, check whether the user wants to use the device.

If the user wants to use a device that is already owned, operations related to the contents shown in FIGS. 12 to 14 may be performed.

Referring to FIG. 12, when a user wants to use a device that is already owned, / acg (anonymous credential generation) may be defined as a new resource related to security on the server device. The / acg resource may be released on an un-secure channel (e.g. CoAP). The / acg resource may serve to determine the authentication method supported by the server device. The / acg resource can be used as an interface to start DTSL handshaking.

The onboarding tool (hereinafter referred to as the second onboarding tool) that wants to enter the preconfigured OCF network is a / acg resource for controlling the device owned by the onboarding tool (hereinafter referred to as the first onboarding tool) that configures the first OCF network. Can be used. The second onboarding tool may generate a credential with the previously owned device by the first onboarding tool through the / acg resource. The credential generation between the first onboarding tool and the previously owned device may be performed without opening the first onboarding tool.

Referring to FIG. 12, first, onboarding is performed on the server A by the first onboarding tool OBT A, so that the first onboarding tool can take ownership of the server A. In order to use the server A belonging to the network configured by the first onboarding tool, the second onboarding tool (OBT B) checks the ownership status of the server A. If server A is owned by another onboarding tool, the second onboarding tool checks whether server A supports anonymous credential generation (ACG). If server A supports ACG, the second onboarding tool may request credential generation from server A.

The DTLS handshaking and credential generation process performed according to the credential generation request of the second onboarding tool may follow the embodiment shown in FIG. 13 or FIG. 14.

Anonymous devices, including onboarding tools, can generate credentials with server devices. Anonymous devices may need to verify credential creation privileges using a supported authentication method before generating credentials with server devices. Supported authentication methods may include PIN, ID / password, QR (Quick Response) and / or certificate methods.

The authentication by PIN, ID / password and / or QR, as shown in FIG. 13, when the corresponding PIN, ID / password and / or QR is input in the second onboarding tool application, authenticates it in the DTLS handshake process Can be done through

A formal pre-shared key (PSK) credential is created between the two devices through the DTLS handshake result and information including the IDs of each device. Authentication for communication between devices may be performed through the generated PSK.

Alternatively, the device and the server device including the onboarding tool may include a certificate that can be used for mutual authentication. The certificate may be a specific device manufacturer's own certificate or an OCF-accredited certificate. When a certificate capable of mutual authentication is included in the second onboarding tool and the server A as shown in FIG. 14, when DTLS handshaking, separate key (eg PSK) generation is unnecessary, and the included certificate communicates between devices. It can be used for authentication.

Even if the credential is generated between the onboarding tool included in the anonymous device and the server and the devices are authenticated, the access control list (/ acl2) resource is required for the client to access the resources included in the server device. Permissions must be set.

For a subject device to be accessed, access authority may be granted by specifying a client device. Alternatively, access rights may be granted to all devices by setting a value for the access rights of the subject device to a wildcard value.

If the first onboarding tool does not communicate with a new client located on the same device as the second onboarding tool, the new client cannot be authenticated by the first onboarding tool. The first onboarding tool cannot set the authority for the new client on the server device. Wildcard values can be used to allow new clients to communicate with the server device without authenticating to the individual client by the first onboarding tool.

When the wild card is described, the connection type can be classified and access authority can be managed as shown in Table 4.

[Table 4]

Through the proposed embodiments, communication of a server device previously owned by the new client device first onboarding tool may be performed without the intervention of the first onboarding tool that has performed the initial security setting. In addition, a credential may be generated for a new client device and a server device previously owned by the first onboarding tool to perform authentication with each other without intervention of the first onboarding tool.

15 is a view showing an embodiment described through FIGS. 11 to 14.

Referring to FIG. 15, first, a first device (Phone A) including a first onboarding tool may perform onboarding for a light bulb. In addition, the first device may set the value of the access control list resource (/ acl2) as a wildcard value, so that anonymous devices can generate a light bulb and a credential.

The second device (Phone B) including the second onboarding tool may search for a light bulb included in the OCF network configured by the first device. The second device, which searches for devices owned by the first device, checks whether the bulb supports ACG, and if so, selects an authentication method. As described above, the authentication method may include authentication based on PIN, ID / password, QR and / or certificate. The second device performs bulb and DTLS handshake and device authentication based on the selected authentication method, and generates and confirms credentials. Once the credential is created and confirmed, encrypted communication between the second device and the light bulb is possible.

If the user does not want to use a device previously owned by another onboarding tool, or if a device previously owned by another onboarding tool does not exist, the second onboarding tool is owned by another onboarding tool Devices that are not detected through a multicast method. If a device that is not already owned is found, the second onboarding tool may perform an onboarding procedure with the device to construct a new OCF network.

16 is a flowchart of a signal reception method according to embodiments of the present invention.

Referring to FIG. 16, an embodiment of the present invention may be performed by a specific communication device (first device). The method performed by the first device includes the steps of searching for an IoT device belonging to the network configured by the second device (S1601), checking whether the searched IoT device supports ACG (S1603), and detecting the ACG of the IoT device. If supported, the step of performing security authentication with the discovered IoT device without receiving a security-related message from the second device constituting the network (S1605), and performing secure communication with the IoT device on which security authentication has been performed (S1607). Can be configured. The IoT device may be preset to perform secure communication with a second device envisioning a network.

The IoT device may include an ACL resource for indicating a list of resources accessible by the first device. The ACL resource may include information about the resource accessible to the first device (even if the first device has not been previously authenticated by the second device).

Security authentication between the first device and the IoT device may be performed by generating a pre-shared key (PSK) based on at least one of a PIN, ID / password, and / or QR (Quick Response). Secure communication may be performed based on the generated PSK.

Alternatively, security authentication between the first device and the IoT device may be performed based on certificates respectively stored in the first device and the IoT device. Secure communication may be performed based on security authentication performed using certificates stored in the first device and the IoT device, respectively.

The first device may additionally perform one or more of the proposed operations through FIGS. 1 to 15 in addition to the operations illustrated through FIG. 16.

Device configuration

17 is a block diagram showing the components of a transmitting device 10 and a receiving device 20 for performing embodiments of the present invention. The transmitting device 10 and the receiving device 20 are transmitter / receivers 13 and 23 capable of transmitting or receiving wireless signals carrying information and / or data, signals, messages, and the like, and related to communication in the wireless communication system. Memory 12, 22 for storing various information, the transmitter / receiver (13, 23) and memory (12, 22), such as components operatively connected to control the component to control the device described above And processors 11, 21 configured to control the memory 12, 22 and / or transmitter / receiver 13, 23, respectively, to perform at least one of the embodiments of the present invention.

The memories 12 and 22 may store programs for processing and control of the processors 11 and 21, and temporarily store input / output information. Memory 12, 22 can be utilized as a buffer. Processors 11 and 21 typically control the overall operation of various modules in the transmitting or receiving device. In particular, the processors 11 and 21 can perform various control functions for carrying out the present invention. The processors 11 and 21 may also be called controllers, microcontrollers, microprocessors, microcomputers, and the like. The processors 11 and 21 may be implemented by hardware or firmware, software, or a combination thereof. When implementing the present invention using hardware, application specific integrated circuits (ASICs) or digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), FPGAs ( field programmable gate arrays) may be provided in the processors 11 and 21. On the other hand, when the present invention is implemented using firmware or software, firmware or software may be configured to include a module, procedure, or function that performs functions or operations of the present invention, and configured to perform the present invention. The firmware or software may be provided in the processors 11 and 21 or stored in the memories 12 and 22 to be driven by the processors 11 and 21.

The processor 11 of the transmission device 10 is scheduled from the processor 11 or a scheduler connected to the processor 11 and predetermined encoding and modulation for signals and / or data to be transmitted to the outside. And transmits it to the transmitter / receiver 13. For example, the processor 11 converts data streams to be transmitted into K layers through demultiplexing, channel encoding, scrambling, and modulation. The coded data stream is also referred to as a codeword, and is equivalent to a transport block, which is a data block provided by the MAC layer. One transport block (TB) is encoded as one codeword, and each codeword is transmitted to a receiving device in the form of one or more layers. For frequency upconversion, the transmitter / receiver 13 may include an oscillator. The transmitter / receiver 13 may include Nt transmit antennas (Nt is a positive integer greater than 1).

The signal processing process of the receiving device 20 is composed of the inverse of the signal processing process of the transmitting device 10. Under the control of the processor 21, the transmitter / receiver 23 of the receiving device 20 receives the radio signal transmitted by the transmitting device 10. The transmitter / receiver 23 may include Nr receive antennas, and the transmitter / receiver 23 frequency down-converts each signal received through the receive antenna to restore a baseband signal. do. The transmitter / receiver 23 may include an oscillator for frequency downconversion. The processor 21 may perform decoding and demodulation of the radio signal received through the reception antenna to restore data originally intended to be transmitted by the transmission device 10.

The transmitter / receiver 13, 23 has one or more antennas. The antenna transmits a signal processed by the transmitter / receiver 13 and 23 to the outside or receives a radio signal from the outside, according to an embodiment of the present invention under the control of the processors 11 and 21. (13, 23). The antenna is also called an antenna port. Each antenna may correspond to one physical antenna or may be configured by a combination of more than one physical antenna element. The signal transmitted from each antenna can no longer be resolved by the receiving device 20. The reference signal (RS) transmitted corresponding to the corresponding antenna defines the antenna viewed from the viewpoint of the receiving device 20, and whether the channel is a single radio channel from one physical antenna or includes the antenna Regardless of whether it is a composite channel from a plurality of physical antenna elements, the receiver 20 enables channel estimation for the antenna. That is, the antenna is defined such that a channel carrying a symbol on the antenna can be derived from the channel carrying another symbol on the same antenna. In the case of a transmitter / receiver that supports a multi-input multi-output (MIMO) function that transmits and receives data using a plurality of antennas, two or more antennas may be connected.

In the embodiments of the present invention, the terminal or the UE operates as the transmitting device 10 in the uplink and the receiving device 20 in the downlink. In embodiments of the present invention, the base station or eNB operates as the receiving device 20 in the uplink and as the transmitting device 10 in the downlink.

The transmitting device and / or the receiving device may perform a combination of at least one or more embodiments of the embodiments of the present invention described above.

The transmitting device and / or receiving terminal 10, 20 is a base station, a network node, a transmitting terminal, a receiving terminal, a wireless device, a wireless communication device, a vehicle, a vehicle equipped with an autonomous driving function, and a drone (Unmanned Aerial Vehicle, UAV) , AI (Artificial Intelligence) module, robot, AR (Augmented Reality) device, VR (Virtual Reality) device or other devices.

For example, the terminal is a mobile phone, a smart phone, a laptop computer, a terminal for digital broadcasting, a personal digital assistants (PDA), a portable multimedia player (PMP), navigation, a slate PC, a tablet It may include a PC (tablet PC), ultrabook (ultrabook), wearable device (wearable device, for example, a watch-type terminal (smartwatch), glass-type terminal (smart glass), HMD (head mounted display), and the like. . For example, a drone may be a vehicle that does not ride and is flying by radio control signals. For example, the HMD may be a display device worn on the head. For example, HMD can be used to implement VR or AR.

The embodiments described above are those in which the components and features of the present invention are combined in a predetermined form. Each component or feature should be considered optional unless stated otherwise. Each component or feature may be implemented in a form that is not combined with other components or features. It is also possible to configure embodiments of the present invention by combining some components and / or features. The order of the operations described in the embodiments of the present invention can be changed. Some configurations or features of one embodiment may be included in other embodiments, or may be replaced with corresponding configurations or features of other embodiments. It is obvious that the claims may not be explicitly included in the claims, and the embodiments may be combined or included as new claims by amendment after filing.

It will be apparent to those skilled in the art that the present invention may be embodied in other specific forms without departing from the spirit and essential features of the present invention. Accordingly, the above detailed description should not be construed as limiting in all respects, but should be considered illustrative. The scope of the invention should be determined by rational interpretation of the appended claims, and all changes within the equivalent scope of the invention are included in the scope of the invention.

As described above, the present invention can be applied to various wireless communication systems.

Claims (10)

1. A secure communication method performed by a first device in a wireless communication system, the method comprising:

   Searching for an Internet of Things (IoT) device belonging to a network configured by a second device, wherein the IoT device is preset to perform secure communication with the second device;

   Checking whether the IoT device supports ACG (Anonymous Credential Generation);

   If the IoT device supports ACG, performing security authentication to perform secure communication with the IoT device even if there is no security-related message received from the second device; And

   Performing secure communication with the IoT device based on the security authentication; Containing,

   Secure communication method.
2. According to claim 1,

   The IoT device includes an access control list (ACL) resource for indicating a list of resources accessible by the first device,

   Secure communication method.
3. According to claim 2,

   The ACL resource includes information on a resource accessible by the first device even when the first device is not previously authenticated by the second device.

   Secure communication method.
4. According to claim 1,

   The security authentication is performed by generating a pre-shared key (PSK) based on one or more of PIN, ID / password and / or QR (Quick Response),

   The secure communication is performed based on the generated PSK,

   Secure communication method.
5. According to claim 1,

   The secure authentication and secure communication is performed based on a certificate pre-stored in the first device and the IoT device,

   Secure communication method.
6. A first device for performing secure communication in a wireless communication system,

   Transceiver; And

   A processor that controls the transceiver; It includes,

   The processor,

   Search for an Internet of Things (IoT) device belonging to a network configured by a second device, and the IoT device is preset to perform secure communication with the second device,

   Check whether the IoT device supports ACG (Anonymous Credential Generation),

   When the IoT device supports ACG, security authentication is performed to perform secure communication with the IoT device even if there is no security-related message received from the second device.

   Configured to perform secure communication with the IoT device based on the security authentication,

   First device.
7. The method of claim 6,

   The IoT device includes an access control list (ACL) resource for indicating a list of resources accessible by the first device,

   First device.
8. The method of claim 6,

   The ACL resource includes information on a resource accessible by the first device even when the first device is not previously authenticated by the second device.

   First device.
9. The method of claim 6,

   The security authentication is performed by generating a PSK (Pre-Shared Key) based on at least one of a PIN (Personal Information Number), an ID / password, and / or a QR (Quick Response),

   The secure communication is performed based on the generated PSK,

   First device.
10. The method of claim 6,

    The secure authentication and secure communication is performed based on a certificate pre-stored in the first device and the IoT device,

    First device.

Images