[go: up one dir, main page]

WO2020096162A1 - Procédé et dispositif de communication sécurisée dans un système de communication sans fil - Google Patents

Procédé et dispositif de communication sécurisée dans un système de communication sans fil Download PDF

Info

Publication number
WO2020096162A1
WO2020096162A1 PCT/KR2019/008226 KR2019008226W WO2020096162A1 WO 2020096162 A1 WO2020096162 A1 WO 2020096162A1 KR 2019008226 W KR2019008226 W KR 2019008226W WO 2020096162 A1 WO2020096162 A1 WO 2020096162A1
Authority
WO
WIPO (PCT)
Prior art keywords
secure communication
iot
resource
ocf
iot device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/KR2019/008226
Other languages
English (en)
Korean (ko)
Inventor
김동주
김나명
백선희
이병주
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
LG Electronics Inc
Original Assignee
LG Electronics Inc
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by LG Electronics Inc filed Critical LG Electronics Inc
Publication of WO2020096162A1 publication Critical patent/WO2020096162A1/fr
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords

Definitions

  • 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.
  • IoT Internet of Things
  • OIC Open Interconnect Consortium
  • 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.
  • IoT standards oneM2M, OMA LWM2M, BLE, Zigbee, Z-Wave, GENIVI, etc.
  • 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.
  • 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.
  • 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.
  • IoT Internet of Things
  • ACG onymous Credential Generation
  • 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.
  • Internet of Things Internet of Things
  • IoT Internet of Things
  • ACG onymous Credential Generation
  • the IoT device may include an access control list (ACL) resource for indicating a list of resources accessible by the first device.
  • ACL access control list
  • 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.
  • 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.
  • PSK Pre-Shared Key
  • the secure authentication and secure communication may be performed based on a certificate pre-stored in the first device and the IoT device.
  • 1 is a view showing the connectivity and interoperability of the OCF platform.
  • FIG. 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.
  • FIG. 4 is a diagram showing a protocol stack that can be supported in the OCF standard.
  • FIG. 5 is a diagram showing a wide range of functions that can be supported through OCF.
  • FIG. 6 is a diagram illustrating an example of performing a CRUDN operation.
  • FIG. 7 is a view showing an example of the operation of the OCF system based on the onboarding tool.
  • FIG. 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.
  • FIG. 16 shows a flow chart according to an embodiment of the present invention.
  • FIG 17 shows an apparatus according to an embodiment of the present invention.
  • 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.
  • 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.
  • 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.
  • the OCF platform provides full interoperability through user experience (UX).
  • the OCF standard defines data structures, types, properties, and interfaces for resources.
  • 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.).
  • FIG. 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.
  • '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.
  • 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 upper layer eg OCF client, OCF server
  • the CoAP Consstrained Application Protocol
  • CoAP response e.g., XMPP (Extensible Messaging and Presence Protocol) in the lower layer (eg OCF device).
  • XMPP Extensible Messaging and Presence Protocol
  • 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.
  • HTTP Hypertext Transfer Protocol
  • 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. .
  • the encoding layer of the protocol stack illustrated in FIG. 4 supports CBOR (Concise binary object representation based on JSON data model) by default.
  • JSON JavaScript Object Notation
  • XML XML / EXI (Efficient XML Interchange)
  • CBOR Concise binary object representation based on JSON data model
  • JSON JavaScript Object Notation
  • XML / EXI ficient XML Interchange
  • CoAP Discovery is used for discovery of the end point (IETF RFC 7252).
  • IPv6 For connection with the L2 layer, IPv6 for IoT devices exists.
  • a datagram transport layer security (DTLS) layer may exist on the user datagram protocol (UDP) layer.
  • DTLS transport layer security
  • TLS transport control protocol
  • TCP transport control protocol
  • FIG. 5 is a diagram illustrating functions supportable through the OCF at a high level.
  • the L2 connectivity layer may use existing wireless communication technologies such as Wi-Fi (wireless fidelity), BT (blootooth) and / or Z-wave.
  • CRUDN operation is an operation that can be requested for a resource, and there may be 5 commands as shown in Table 2.
  • the server including the resource executes a CRUDN command for the resource.
  • FIG. 6 shows an example of performing a CRUDN operation.
  • 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.
  • 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.
  • 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.
  • SVRs Secure Virtual Resources
  • OCF Onboarding Tool
  • 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).
  • DOS Device Ownership Transfer Service
  • AMS Access Manager Service
  • CMS Certification Management Service
  • DTLS Datagram Transport Layer Security
  • D2D Device-to-Device
  • UDP User Datagram Protocol
  • TLS Transport layer security
  • T2C Device-to-Central
  • 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).
  • ACEs access control entries
  • ACLs access control lists
  • the SVR may include the following resources.
  • the / oic / sec / doxm resource is a resource for managing a device ownership transfer method.
  • Device UUID universalally unique identifier
  • OHT unique administrator device
  • Select indicating the support method for the ownership transfer method , Owned for ownership setting status information
  • the / 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.
  • / oic / sec / amacl which is responsible for managing ACL settings
  • / 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.
  • the new OCF device may be searched by OBT (e.g. DOTS).
  • OBT e.g. DOTS
  • 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).
  • URL Uniform Resource Locator
  • 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.
  • OTM Ownership Transfer Method
  • JW Just Works
  • PIN Personal Information Number
  • certificate 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.
  • 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.
  • the client device and the server 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 onboarding tool is a mobile phone or TV application.
  • the onboarding tool may be one of the devices exemplified in the following device drawings (FIG.).
  • FIG. 7 shows an example of the operation of the OCF system based on the onboarding tool.
  • 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.
  • 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).
  • DTLS or TLS protocols may be used for encrypted communication.
  • the encryption suite may vary depending on the method of transferring ownership.
  • An encryption suite means a combination of encryption protocols.
  • FIG. 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.
  • 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.
  • symmetric key credentials may exist.
  • the CMS of the onboarding tool can inform each of the two OCF devices in advance the credential of the other OCF device.
  • 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.
  • 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.
  • each device may have a secret key and / or a public key.
  • 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.
  • a certificate method may exist as an authentication method.
  • each device holds an OCF-accredited certificate issued by the manufacturer and / or a certificate issued through a CA (Certificate Authoroty).
  • CA Certificate Authoroty
  • access rights to specific resources may be limited for each device.
  • 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.
  • 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.
  • FIG. 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.
  • both the client and the server 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.
  • a certificate may be issued at the time of manufacture of the device.
  • the CMS designated at the time of onboarding by the onboarding tool may dynamically manage the credentials.
  • the AMS designated at the time of onboarding can perform access control related to access authority.
  • CMS and AMS may be implemented as a part of the onboarding tool.
  • 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.
  • 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.
  • 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.
  • FIG. 11 shows a flow chart according to an embodiment of the present invention.
  • 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.
  • / acg anonymous credential generation
  • 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.
  • 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.
  • 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.
  • ACG anonymous credential generation
  • 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 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.
  • PSK formal pre-shared key
  • 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.
  • 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.
  • the access control list (/ acl2) resource is required for the client to access the resources included in the server device. Permissions must be set.
  • access authority may be granted by specifying a client device.
  • access rights may be granted to all devices by setting a value for the access rights of the subject device to a wildcard value.
  • 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.
  • connection type When the wild card is described, the connection type can be classified and access authority can be managed as shown in Table 4.
  • 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.
  • 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.
  • FIGS. 11 to 14 are views showing an embodiment described through FIGS. 11 to 14.
  • a first device including a first onboarding tool may perform onboarding for a light bulb.
  • 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.
  • 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.
  • 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.
  • 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.
  • PSK pre-shared key
  • 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.
  • FIG. 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
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • MIMO multi-input multi-output
  • the terminal or the UE operates as the transmitting device 10 in the uplink and the receiving device 20 in the downlink.
  • 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.
  • UAV Unmanned Aerial Vehicle
  • AI Artificial Intelligence
  • robot AR (Augmented Reality) device
  • VR Virtual Reality
  • 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
  • PDA personal digital assistants
  • PMP portable multimedia player
  • 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.
  • a drone may be a vehicle that does not ride and is flying by radio control signals.
  • the HMD may be a display device worn on the head.
  • HMD can be used to implement VR or AR.
  • the present invention can be applied to various wireless communication systems.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

La présente invention concerne un procédé de communication sécurisée effectué au moyen d'un premier dispositif. La présente invention concerne un procédé et un dispositif servant à : rechercher un dispositif IdO qui appartient à un réseau configuré par un second dispositif et qui est préétabli pour effectuer une communication sécurisée avec le second dispositif ; vérifier si le dispositif IdO prend en charge la génération de justificatif d'identité anonyme (ACG) ; effectuer, si le dispositif IdO prend en charge l'ACG, une certification sécurisée pour effectuer la communication sécurisée avec le dispositif IoD même lorsqu'un message lié à la sécurité n'a pas été reçu en provenance du second dispositif ; et effectuer la communication sécurisée avec le dispositif IdO sur la base de la certification sécurisée.
PCT/KR2019/008226 2018-11-08 2019-07-04 Procédé et dispositif de communication sécurisée dans un système de communication sans fil Ceased WO2020096162A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2018-0136894 2018-11-08
KR20180136894 2018-11-08

Publications (1)

Publication Number Publication Date
WO2020096162A1 true WO2020096162A1 (fr) 2020-05-14

Family

ID=70611372

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2019/008226 Ceased WO2020096162A1 (fr) 2018-11-08 2019-07-04 Procédé et dispositif de communication sécurisée dans un système de communication sans fil

Country Status (1)

Country Link
WO (1) WO2020096162A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024168935A1 (fr) * 2023-02-19 2024-08-22 北京小米移动软件有限公司 Procédé de vérification de message et appareil associé

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060057345A (ko) * 2004-11-23 2006-05-26 삼성전자주식회사 홈 네트워크 장치 간의 보안 연결을 위한 시스템 및 방법
KR20100040694A (ko) * 2008-10-10 2010-04-20 삼성전자주식회사 홈 네트워크에서 제어 포인트 장치가 피제어 장치의 보안을 설정하기 위한 시스템 및 방법
KR101737345B1 (ko) * 2016-10-27 2017-05-18 아주대학교산학협력단 클라우드 기반의 IoT 시스템에서 IoT 디바이스를 인증하기 위한 방법 및 장치
KR20170088193A (ko) * 2016-01-22 2017-08-01 한국전자통신연구원 자율적 IoT 환경에서의 사물 기반 소셜 네트워크 서비스 및 저널리즘 활동을 위한 시스템

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20060057345A (ko) * 2004-11-23 2006-05-26 삼성전자주식회사 홈 네트워크 장치 간의 보안 연결을 위한 시스템 및 방법
KR20100040694A (ko) * 2008-10-10 2010-04-20 삼성전자주식회사 홈 네트워크에서 제어 포인트 장치가 피제어 장치의 보안을 설정하기 위한 시스템 및 방법
KR20170088193A (ko) * 2016-01-22 2017-08-01 한국전자통신연구원 자율적 IoT 환경에서의 사물 기반 소셜 네트워크 서비스 및 저널리즘 활동을 위한 시스템
KR101737345B1 (ko) * 2016-10-27 2017-05-18 아주대학교산학협력단 클라우드 기반의 IoT 시스템에서 IoT 디바이스를 인증하기 위한 방법 및 장치

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
NI, JIANBING ET AL.: "Efficient and Secure Service-Oriented Authentication Supporting Network Slicing for 5G-Enabled IoT", IEEE JOURNAL ON SELECTED AREAS IN COMMUNICATIONS, vol. 36, no. 3, 12 March 2018 (2018-03-12), pages 644 - 657 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2024168935A1 (fr) * 2023-02-19 2024-08-22 北京小米移动软件有限公司 Procédé de vérification de message et appareil associé

Similar Documents

Publication Publication Date Title
US9049184B2 (en) System and method for provisioning a unique device credentials
US11272361B2 (en) Zero-touch onboarding in a network
KR102227177B1 (ko) 제어기와 액세서리 사이의 통신을 위한 균일한 통신 프로토콜
CN107534651B (zh) 用于传送会话标识符的方法及设备
US8724515B2 (en) Configuring a secure network
JP5080852B2 (ja) パーソナルドメインコントローラ
EP2677788A1 (fr) Méthode et système pour l'aggrégation de données pour des tâches communes à plusieurs appareils
WO2015126124A1 (fr) Procédé et dispositif pour transmettre et recevoir des informations d'authentification dans un système de communication sans fil
WO2015074424A1 (fr) Système et procédé de contrôle d'accès mutuel de dispositifs intelligents
WO2019194665A1 (fr) Procédé et dispositif pour exécuter un embarquement
US9344417B2 (en) Authentication method and system
WO2010041915A2 (fr) Système et procédé pour le paramétrage de sécurité pour un dispositif contrôlé par un point de contrôle dans un réseau domestique
CN107404485A (zh) 一种自验证云连接方法及其系统
WO2023249320A1 (fr) Procédé, dispositif et système de communication de dds
EP2958291B1 (fr) Procédé et système d'authentification d'équipement de réseau
CN115362747B (zh) 一种终端设备的验证方法及装置
CN110741614B (zh) 数据通信系统和方法
EP4320821A1 (fr) Procédé et système d'auto-intégration de dispositifs ido
WO2021249512A1 (fr) Procédé de communication sécurisée, appareil associé, et système
WO2023054935A1 (fr) Procédé et système d'auto-intégration de dispositifs ido
WO2020096162A1 (fr) Procédé et dispositif de communication sécurisée dans un système de communication sans fil
US20240406724A1 (en) Brokered service discovery and connection management
WO2022114369A1 (fr) Dispositif électronique conçu pour exécuter un protocole d'échange bidirectionnel de clés sur la base d'une position et procédé de fonctionnement dudit dispositif
WO2020096161A1 (fr) Procédé et appareil destinés à la communication sécurisée dans un système de communication sans fil
WO2015196350A1 (fr) Procédé, système et terminal d'accès à un réseau sans fil

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19881166

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19881166

Country of ref document: EP

Kind code of ref document: A1