CN113678421B

CN113678421B - Security domain configuration, discovery and joining methods and devices, and electronic equipment

Info

Publication number: CN113678421B
Application number: CN202080025258.0A
Authority: CN
Inventors: 茹昭; 吕小强; 张军
Original assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Current assignee: Guangdong Oppo Mobile Telecommunications Corp Ltd
Priority date: 2020-01-19
Filing date: 2020-01-19
Publication date: 2023-06-09
Anticipated expiration: 2040-01-19
Also published as: WO2021142849A1; CN113678421A

Abstract

The embodiment of the application relates to a security domain configuration and discovery method and device and electronic equipment. In the embodiment of the application, by adding the security domain resource in the internet of things device to configure and manage the security domain to which the device belongs, a solution for configuring the security domain of the internet of things existing in the network is provided. When the security domain information is discoverable, the resource discovery process can be simplified by mapping the attribute values to the discovery resources of the device, so that other devices can conveniently discover and acquire the security domain information in the network. In addition, when a plurality of security domains exist in the network, different security domains can be distinguished by the discovered security domain information.

Description

Security domain configuration, discovery and joining methods and devices, and electronic equipment

Technical Field

The present application relates to the field of communications, and in particular, to a method for configuring, discovering and joining a security domain, and an electronic device.

Background

The internet of things (Internet of things, abbreviated as 'IoT'), namely 'everything connected internet', is an extended and expanded network based on the internet, and a huge network formed by combining various information sensing devices with the internet is used for realizing interconnection and intercommunication of people, machines and objects at any time and any place. However, due to the attribute of 'everything interconnection' of the internet of things, the hardware, software and data in the system of the internet of things are extremely easy to be destroyed, changed and leaked due to accidental or malicious reasons. With the rapid development of the internet of things technology, the internet of things security is also becoming more important.

A security domain network is a specific internet of things network, where the security domain network has an independent security protocol (or security mechanism), and the devices of the internet of things in the security domain network may interconnect, interwork, discover each other, and transmit instructions to each other. Devices outside the secure domain network, because of being limited by the security protocol in the secure domain network, cannot access other internet of things devices within the secure domain network. The security domain network may be a sub-network of a local area network, which may have at least one security domain network provided therein by an access point device, which may have independent security protocols, respectively.

In the existing scheme, when the client device enters the local area network, multiple device interactions are needed, and the security domain of the Internet of things existing in the network cannot be found conveniently and rapidly. In addition, in the case where a plurality of security domains exist in the same network, it is difficult to distinguish between the security domains.

Disclosure of Invention

The embodiment of the application provides a configuration, discovery and joining method of a security domain and electronic equipment, and provides a solution for configuring the security domain of the Internet of things existing in a network, which can simplify the discovery process of resources, so that client equipment can conveniently discover and acquire the security domain information in the network.

In a first aspect, a method for configuring a security domain is provided, including: acquiring security domain information; and performing security domain configuration according to the acquired security domain information. Wherein the security domain information includes at least: a security domain identifier, a security domain name, and security domain discoverability.

In a second aspect, a method for discovering a security domain is provided, including:

obtaining discovery resources of internet of things (IoT) devices in a network;

acquiring a security domain identifier from the discovery resource;

determining and storing a security domain corresponding to the security domain identifier in the network;

wherein the IoT device has configured security domain information comprising at least: a security domain identifier, a security domain name, and security domain discoverability.

In a third aspect, a method for discovering a security domain is provided, which is executed by an internet of things device configured with security domain information by the method for configuring a security domain in the foregoing first aspect, and includes: responding to a received request message for executing resource discovery, and feeding back the discovery resource; responding to a received request message for obtaining a security domain name corresponding to a security domain identifier, and feeding back the security domain name; wherein the security domain information includes at least: a security domain identifier, a security domain name, and security domain discoverability; the security domain identifier is included in the discovery resource when an attribute value of the security domain discoverability characterizes discoverability.

In a fourth aspect, there is provided a method of joining a security domain, comprising:

requesting a user to select a security domain to be added; wherein the security domain for selection by the user is a security domain discovered by the method of the second aspect;

and starting an instance of the security domain according to the security domain selected by a user.

In a fifth aspect, there is provided a security domain configuration apparatus, including:

the acquisition module is used for acquiring the security domain information;

the configuration module is used for carrying out security domain configuration according to the acquired security domain information;

wherein the security domain information includes at least: a security domain identifier, a security domain name, and security domain discoverability.

In a sixth aspect, there is provided a security domain discovery apparatus, including:

the system comprises a first acquisition module, a second acquisition module and a third acquisition module, wherein the first acquisition module is used for acquiring discovery resources of internet of things (IoT) equipment in a network;

a second obtaining module, configured to obtain a security domain identifier from the discovery resource;

a determining module, configured to determine a security domain corresponding to the security domain identifier in the network;

A seventh aspect provides a security domain discovery apparatus, configured with security domain information by the security domain configuration apparatus described in the fifth aspect, including:

the first feedback module is used for responding to the received request message for executing resource discovery and feeding back the discovery resource;

the second feedback module is used for responding to the received request message for obtaining the security domain name corresponding to the security domain identifier and feeding back the security domain name;

wherein the security domain information includes at least: a security domain identifier, a security domain name, and security domain discoverability; the security domain identifier is included in the discovery resource when an attribute value of the security domain discoverability characterizes discoverability.

In an eighth aspect, there is provided a joining apparatus for a security domain, comprising:

the request module is used for requesting a user to select a security domain to be added; wherein the security domain for selection by the user is a security domain discovered by the apparatus of the sixth aspect;

and the starting module is used for starting the instance of the security domain according to the security domain selected by the user.

A ninth aspect provides an electronic device for performing the method of the first aspect or implementations thereof. In particular, the electronic device comprises functional modules for performing the method of the first aspect or implementations thereof described above.

In a tenth aspect, an electronic device is provided that includes a processor and a memory. The memory is used for storing a computer program, and the processor is used for calling and running the computer program stored in the memory and executing the method in any one of the first aspect to the fourth aspect or each implementation manner thereof.

An eleventh aspect provides a chip for implementing the method in any one of the first to third aspects or each implementation thereof. Specifically, the chip includes: a processor for calling and running a computer program from a memory, causing a device on which the chip is mounted to perform the method as in any one of the first to fourth aspects or implementations thereof described above.

In a twelfth aspect, a computer-readable storage medium is provided for storing a computer program that causes a computer to perform the method of any one of the above-described first to fourth aspects or implementations thereof.

In a thirteenth aspect, there is provided a computer program product comprising computer program instructions for causing a computer to perform the method of any one of the above first to fourth aspects or implementations thereof.

In a fourteenth aspect, there is provided a computer program which, when run on a computer, causes the computer to perform the method of any one of the above-described first to fourth aspects or implementations thereof.

Through the technical scheme, the security domain of the Internet of things existing in the network can be configured, and the resource discovery process can be simplified, so that the client device can conveniently discover and acquire the security domain information in the network.

Drawings

Fig. 1 is a schematic diagram of the internet of things applied in the embodiment of the present application.

Fig. 2 is a schematic diagram of a protocol architecture of an internet of things device according to an embodiment of the present application.

Fig. 3 is a schematic flow chart of a method of configuring a security domain according to one specific embodiment of the present application.

Fig. 4 is a schematic flow chart of a method of configuring a security domain according to another specific embodiment of the present application.

Fig. 5 is a schematic flow chart of a method of configuring a security domain according to yet another specific embodiment of the present application.

Fig. 6 is a schematic flow chart of a method of configuring a security domain according to yet another specific embodiment of the present application.

Fig. 7 is a schematic flow chart of a method of configuring a security domain according to yet another specific embodiment of the present application.

Fig. 8 is a schematic flow chart diagram of a method of discovery of a security domain according to a specific embodiment of the present application.

Fig. 9 is a schematic flow chart of a method of discovery of a security domain according to another specific embodiment of the application.

Fig. 10 is a schematic flow chart of a method of joining security domains according to one specific embodiment of the present application.

Fig. 11 is a schematic flow chart of a method of discovery of a security domain according to another specific embodiment of the application.

Fig. 12 is a schematic view of an interaction scenario among IoT devices according to an embodiment of the present application.

Fig. 13 is another interaction scenario diagram among IoT devices according to an embodiment of the present application.

Fig. 14 is yet another interaction scenario diagram among IoT devices according to an embodiment of the present application.

Fig. 15 is yet another interaction scenario diagram among IoT devices according to an embodiment of the present application.

Fig. 16 is a schematic block diagram of a configuration device of a security domain according to one specific embodiment of the present application.

Fig. 17 is a schematic block diagram of a discovery apparatus of a security domain according to a specific embodiment of the application.

Fig. 18 is a schematic block diagram of a discovery apparatus of a security domain according to yet another specific embodiment of the application.

Figure 19 is a schematic block diagram of a joining device of a security domain, according to one specific embodiment of the present application.

Fig. 20 is a schematic block diagram of an electronic device provided in an embodiment of the present application.

Fig. 21 is a schematic block diagram of a chip provided in an embodiment of the present application.

Detailed Description

The following description of the technical solutions in the embodiments of the present application will be made with reference to the drawings in the embodiments of the present application, and it is apparent that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are within the scope of the present disclosure.

Referring to fig. 1, fig. 1 illustrates an example internet of things in block diagram form. The internet of things may be a point-to-point network. An electronic device running an instance of the internet of things protocol may join the internet of things, and such an electronic device may be referred to as an internet of things device (hereinafter "IoT device").

IoT devices follow the internet of things device core protocol. Fig. 2 illustrates an example IoT device core protocol architecture, e.g., RESTful architecture (representational state transfer (REST) for short, representational State Transfer) describes an architecture-style network system, referring to a set of architecture constraints and principles, and an application or design that satisfies these constraints and principles is RESTful.

In the protocol architecture shown in fig. 2, the service layer defines a service framework for devices, unifying the canonical IoT device model. Specifically, information such as the physical equipment of the internet of things, functional services provided by the equipment, the state of the equipment and the like is expressed through resources. The device providing the resource is a server and the device accessing the resource is a client. The client and the server are logical functional entities. One device may be a client or a server, or one device may be both a client and a server. For example, a device (e.g., a light bulb) that implements some of the most basic functions may only be a server, and may be provided to clients for querying and controlling, without itself having control or the need to query other devices.

The business interaction between the client and the server is implemented by performing RESTful operations on the resource, such as Create, read, update, delete, and Notify (these operation methods are collectively referred to as "CRUDN operations"). The client is the initiator of the RESTful operation and the server is the responder of the RESTful operation. The client sends a resource operation request to the server, and the request is used for operating the resource on the server. The server executes the resource operation and returns a response to the client, wherein the response carries the content and description information of the resource.

In the protocol architecture shown in fig. 2, the description of resources is a resource model layer, each resource corresponds to a specific uniform resource identifier (Uniform Resource Identifier, abbreviated as "URI"), which can be accessed by accessing the URI of the resource, and in addition, each resource has a corresponding interface supporting Restful operations. The transmission protocol layer is used for transmitting the content and the description information of the resources, and the resource operation is mapped into a specific transmission protocol, so that the Restful operation of each resource is converted into entity information to be transmitted between devices, and a means is provided for interconnection and interworking between the devices.

In the protocol architecture shown in fig. 2, resource operations may be carried using, for example, the constrained application (Constrained Application Protocol, simply "CoAP") protocol. Each CRUDN operation is mapped into a request/response message of the CoAP protocol, and the client device can operate the resources of the server through four methods of acquisition (GET), new creation (POST), update (PUT) and Deletion (DELETE) in the CoAP protocol, so that the conversion of the resource state is realized. The bearer protocol used in the present application is not limited to CoAP protocol, but may also be other protocols, such as the mainstream bearer protocols of message queue telemetry transport (Message Queuing Telemetry Transport, abbreviated as "MQTT") protocol and hypertext transport protocol (Hyper Text Transfer Protocol, abbreviated as "HTTP"), which are not illustrated herein.

The IoT devices may be connected to each other using suitable communication techniques, which may include wired and wireless communication techniques. Such communication follows a protocol associated with the internet of things. In the protocol architecture shown in fig. 2, the connectivity layer may support a variety of different lower-level networks such as WiFi, ethernet, wireless mesh (Thread), bluetooth (blue) and zigbee. However, the present application should not be limited by the examples herein, and other communication protocols related to the internet of things should also fall within the protection scope of the present application.

At least some IoT devices may have an activation Tool (or "OBT") disposed thereon. The OBT is one role in the security protocol and is a tool for configuring the IoT devices in the security domain network in which the security protocol is set. The OBT may run on at least one IoT device in the secure domain network, and the IoT device provided with the OBT may be referred to as an OBT device (e.g., as shown in FIG. 1). The OBT device may be used to configure itself, as well as other IoT devices in the secure domain network in which it resides. The IoT devices configured by the OBT device may form a secure domain network. In a secure domain network, there may be only one master OBT and there may be multiple slave OBTs.

One or more logical devices (devices) may be included in each IoT Device, each logical Device may have multiple Device instances (Device instances), only one Device instance in each logical Device is in an active (active) state, and other Device instances in the logical Device are in an inactive (inactive) state. The device instance in the active state enables the logical device of the device instance in the active state to be discovered, configured and accessed by the logical devices of other IoT devices in the secure domain network, whereas the logical device of the device instance in the inactive state cannot be discovered, configured and accessed by the logical devices of other IoT devices in the secure domain network.

The logic device may be established according to the use requirement of the security domain, and in this embodiment, one function of the IoT device (a composite multifunctional device or a single functional device) may be one logic device, which may be understood as a functional entity of software controlling the IoT device, and one IoT device may have at least one functional entity thereon.

Each logical device may have a variety of states, such as a factory state, a configuration state, and an operational state. Wherein the factory state refers to a state in which a logical device in the newly purchased IoT device is located after power-up. The configuration state refers to a state in which an IoT device can configure a logical device in the IoT device using an OBT tool of a secure domain network before entering the secure domain network, and the configuration state may be a factory state. The working state refers to a state of a logic device in the IoT device after the logic device is configured by an OBT of the secure domain network, and the IoT device configured by the OBT device can enter the secure domain network and interconnect and interwork with the IoT device in the secure domain network. The logical device in an operating state may receive a service instruction to change a function setting corresponding to the logical device, e.g., the IoT device is an air conditioner, the air conditioner may correspond to a plurality of logical devices, each logical device may correspond to a function of the air conditioner, and the logical device corresponding to a temperature may receive a temperature instruction to change the temperature setting. The logic device in the configuration state is configured to wait to be configured by the OBT tool to enter an operational state. The logic device in the working state may restore the configuration state by resetting (reset), when the logic device in the configuration state is in the active state, it may be discovered by the OBT device and may be configured by the OBT device, whereas when the logic device in the configuration state is in the inactive state, it may not be discovered by the OBT device and may not be configured by the OBT device.

Fig. 1 exemplarily shows 4 IoT devices, alternatively, the internet of things 100 may include multiple IoT devices, which is not limited in this embodiment of the present application.

It should be understood that the terms "system" and "network" are used interchangeably herein. The term "and/or" is herein merely an association relationship describing an associated object, meaning that there may be three relationships, e.g., a and/or B, may represent: a exists alone, A and B exist together, and B exists alone. In addition, the character "/" herein generally indicates that the front and rear associated objects are an "or" relationship.

Based on the related technology, how to configure the security domain of the internet of things existing in the network so as to simplify the resource discovery process, so that the client device can conveniently discover and obtain the security domain information in the network is a problem to be solved at present.

Therefore, the embodiment of the application provides a configuration, discovery and joining method of a security domain.

In the embodiment provided by the application, a security domain (SecDomain) resource is added to the logic device to configure and manage the security domain to which the logic device belongs. After the logic device is activated (onboard), the OBT may configure security domain information for the logic device by configuring secDomain resources. When the security domain information is discoverable, other logical devices may conveniently discover the security domain of the logical device by mapping attribute values to a discovery resource (simply "res resource") of the logical device. When there are multiple security domains in the network, the different security domains can be distinguished by the discovered security domain information.

Table 1 below shows the characteristics of secDomain resources, mainly including uniform resource identifiers, resource type headers, resource type identifiers, interfaces, and descriptions. Wherein the URI is used for identifying and addressing the secDomain resource. The resource type header is used to describe the function of the resource. The resource type identifier is used to distinguish resource types. Interfaces (interfaces) indicate the mechanism by which a resource is expressed and obtained, different interfaces corresponding to different expressions of the resource and corresponding mechanisms of operation, such as the baseline (baseline) type given in table 1. The functions for explaining the resources are described.

TABLE 1

Illustratively, the attribute definition of the secDomain resource is shown in table 2. The attributes are used to describe information about the resource, including metadata for the resource. The attribute appears as a < attribute name > = < attribute value > key-value pair. For example, the "security domain identifier" attribute has an attribute name "sdid" and an attribute value "e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9", and the attribute is expressed as "sdid=e61 c3e6b-9c54-4b81-8ce5-f9039c1d04d9". The format of the attributes is determined by the encoding scheme, for example, in JSON the attributes are expressed as "attribute names": the value (e.g., "sdid": e61c3e6b-9c54-4b81-8ce5-f9039c1d04d 9).

TABLE 2

In addition, the value type defines the value that the attribute value may take. The value type may be a type of simple data such as a string (string), a boolean value (boolean), etc. The value type may also be a complex data type defined by an architecture (schema). The value type may define attribute value rules that the attribute value may use in the attribute value, the attribute value rules may define a range of values, maximum/minimum values, formulas, enumerated value ranges, patterns, conditional values, and even dependencies on attribute values of other attributes, and the rules may be used to validate the attribute value. As shown in table 2, the value type of the security domain identifier and the security domain name are each "string", and the value type of the security domain discoverability is "bootean", for example.

The access mode specifies whether the attribute can be read, written, or readable and writable. For example, "R" represents readable, "W" represents writable, and "RW" represents readable and writable. "W" writeable does not automatically indicate that the attribute must be readable. Illustratively, the security domain identifier, the security domain name, and the access pattern of security domain discoverability are all "RWs".

Readability description information of the attributes, describing the roles and uses of the attributes. For example, the description of the security domain identifier indicates: the security domain identifier is a universally unique identifier of the security domain, accessible through multicast (multicast). The description of the security domain discoverability shows that: whether the security domain is discoverable; when the attribute value of the security domain discoverability is TRUE (TRUE), the security domain discoverability; and when the attribute value of the security domain discoverability is FALSE (FALSE), the security domain is not discoverable.

The secDomain resources shown in table 2 have 3 attributes, alternatively, the secDomain resources may include more than 3 attributes, or fewer than 3 attributes (e.g., including only one of a security domain identifier and a security domain name and security domain discoverability), which is not limited in this embodiment of the present application.

Fig. 3 is a schematic flowchart of a configuration method of a security domain according to an embodiment of the present application. The method may be performed by an OBT device. By performing the method shown in fig. 3, the security domain configuration of the OBT device itself may be accomplished.

As shown in fig. 3, the configuration method of the security domain includes:

step S310, acquiring security domain information;

step S320, safety domain configuration is carried out according to the acquired safety domain information.

As described above, a logical device needs to be activated before it can operate in a network or interact with other logical devices. The first step in activating a logical device is to configure device ownership. A legitimate user establishes device ownership using an owner transfer method (Owner Transfer Method, abbreviated as "OTM") via an activation tool (OBT). After ownership is established, the OBT is used for device configuration, and finally the logic device can normally operate and interact with other logic devices.

After the OBT device is self-activated, the OBT may obtain security domain information, such as a security domain identifier, a security domain name, and security domain discoverability, upon/after configuring device ownership. Alternatively, the security domain information may be set by a user, or may be set by loading preconfigured information.

For the security domain identifier, a random number may be automatically generated by the OBT as the security domain identifier for security. For example, the OBT may generate a random number from its own authentication (Certificate Authority, simply "CA") root certificate and use the random number as the security domain identifier.

For example, the user may be requested to set a security domain identifier, a security domain name, and security domain discoverability. For example, an input box may be presented for a user to enter a security domain identifier and/or a security domain name. For another example, a check box may be presented for the user to select security domain discoverability. However, the application should not be limited by examples herein, and any existing manner of man-machine interaction may be used for the user to set the security domain name and the security domain discoverability.

After obtaining the security domain name and the security domain discoverability set by the user, the secDomain resource of the OBT device may be configured in the following form:

{

“sdid”＝e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9，

“sdn”＝my home，

“discoverable”＝true

}

When the attribute discover value is TRUE, the security domain identifier attribute value may be mapped into the secdomainnuid of the res resource of the OBT device. For example, the representation of the security domain identifier in the res resource may be:

″secdomainuuid″：″e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9″

fig. 4 is a schematic flowchart of a configuration method of a security domain provided in an embodiment of the present application. The method may be performed by an OBT device. By performing the method shown in fig. 4, the OBT device may configure the security domain of other IoT devices.

As shown in fig. 4, the configuration method of the security domain includes:

step S410, obtaining security domain information;

step S420, the security domain information is set in the device to be configured by sending an instruction carrying the security domain information to the device to be configured.

After the OBT device completes its own configuration, the OBT discovers the device to be configured (hereinafter referred to as "device to be configured") in the network, and the device to be configured returns a supported owner transfer method to the OBT, and the OBT establishes communication connection with the device to be configured according to the owner transfer method. Optionally, a secure communication connection is established between the OBT device and the device to be configured. This procedure is similar to the procedure of activating and establishing a communication connection in the prior art and is not described in detail here.

After the communication connection is established, the security domain information is set in the device to be configured by sending an instruction carrying the security domain information to the device to be configured. Specifically, the OBT acquires self-configured security domain information from the secDomain resource, and sends an instruction to the device to be configured. For example, as described above, the OBT is used as a client, the device to be configured is used as a server, and the OBT initiates Update operation. An Update request message (i.e., the "instruction" described above) is sent by the OBT to the device to be configured to Update the secDomain resource information on the device to be configured.

For example, the instructions may be in the form of:

this instruction sets uuid (e 61c3e6b-9c54-4b81-8ce5-f9039c1d04d 9), name (my home) and discoverability (discoverability) of the security domain into the device to be configured. For convenience of explanation and explanation below, this instruction will be referred to as a "first instruction", and a device to be configured with the first instruction will be referred to as a "first device".

For another example, the instructions may also be in the form of:

this instruction sets uuid (e 61c3e6b-9c54-4b81-8ce5-f9039c1d04d 9), name (my home) and discoverability (non-discoverable) of the security domain into the device to be configured. For convenience of explanation and explanation below, this instruction will be referred to as a "second instruction", and a device to be configured using the second instruction will be referred to as a "second device".

In addition to setting the security domain information into the device to be configured, the OBT configures attributes of other resources of the device to be configured, such as/oic/sec/doxm resources (for configuring supported OTM mode, selected OTM mode, supported credential type, identifying whether device owner, device ID, device owner ID, and resource owner ID, etc.),/oic/sec/cred resources (for configuring selected credentials (including credentials to establish a secure connection with CMS, credentials to establish a local area network secure connection with other devices), owner ID of the resources, etc.), etc. These resource allocation procedures may employ existing allocation procedures and are not described in detail herein.

After the configuration of all resources is completed (the device that completes the configuration of the resources may be simply referred to as a "configured device"), the OBT changes the state of the device to be configured to an operational state. OBT is the owner of the network, and Client (Client) equipment and Server (Server) equipment in the network can be configured to be interconnected and intercommunicated. After configuration, the OBT is the owner (owner) of the device being configured.

Fig. 5 is a schematic flowchart of a configuration method of a security domain provided in an embodiment of the present application. The method can be executed by the device to be configured, and is executed in cooperation with the configuration method of the security domain shown in fig. 4 to complete the configuration of the security domain of the device to be configured.

The configuration method of the security domain shown in fig. 5 includes:

step S510, receiving an instruction carrying security domain information;

step S520, according to the security domain information in the instruction, the security domain configuration is performed.

As described above, after the device to be configured is discovered by the OBT, a owner transfer handshake is performed to establish a communication connection with the OBT. After the communication connection is established, an instruction carrying security domain information sent by the OBT via the communication connection is received.

Specifically, as described above, the device to be configured receives the UPDATE request message (i.e., the "instruction" described above) as the server side. After receiving the UPDATE request, the device to be configured verifies whether the OBT sending the request has the right to UPDATE the relevant resource. If so, the device to be configured UPDATEs the information of the secDomain resource according to the attribute value which needs to be updated by the secDomain resource included in the UPDATE request message. That is, after receiving an instruction from an OBT, security domain configuration is performed according to security domain information in the instruction.

For example, for the first instruction, the device to be configured maps the sdid attribute to the res resource according to the attribute value of the discoverable being true. The representation of sdid in res resource may be:

″secdomainuuid″：″e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9″

In contrast, for the second instruction described above, since the attribute value of the discoverable is false, the device to be configured will not map the sdid attribute to the res resource. That is, the security domain of the device to be configured that received the second instruction may not be found by other devices.

After receiving the UPDATE request, the device to be configured also caches the identifier of the UPDATE request in the UPDATE request for use in the UPDATE response. An UPDATE response message is sent by the device to be configured to the OBT. The UPDATE response contains at least the cached identifier of the UPDATE request and the updated secDomain resource representation.

The configuration methods of the security domains shown in fig. 4 and 5 are performed in conjunction with each other, so that the OBT and the device to be configured may form a security domain network. It should be noted that in the above example, the OBT and the device to be configured have the same security domain identifier and security domain name, and therefore, the OBT and the device to be configured are in the same security domain network.

Fig. 6 is a schematic flowchart of a configuration method of a security domain according to an embodiment of the present application. The method may be performed by a master OBT device. In this case, a master OBT device in the secure domain network may perform a secure domain configuration for slave OBT devices similar to the secure domain configuration method shown in FIG. 4.

The configuration method of the security domain as shown in fig. 6 includes:

step 610, obtaining security domain information;

in step 620, the security domain information is set in the slave OBT device by sending an instruction carrying the security domain information to the slave OBT device.

After the main OBT device is self-activated, when/after the ownership of the device is configured, the main OBT also creates different roles in various security domain networks, and the different roles have different rights. For example, there are various user roles such as administrator (admin), family member (family), guest (guest), and the like. For another example, an administrator (admin) has the right to configure and manage other IoT devices in the same secure domain network, while a family member (family) has the right to control other IoT devices in the same secure domain network. In practice, and not by way of example herein, a user may create different roles and set different permissions for the different roles as desired.

After the master OBT discovers the slave OBT, the slave OBT can be configured and the rights of other IoT devices can be given to the slave OBT so that the devices configured by the slave OBT can also access the security domain network. It is noted that the process of the master OBT giving the slave OBT the authority to configure and manage other IoT devices may be implemented by any process that may implement the secondary function in the prior art, which is not described in detail herein.

The master OBT device may set the security domain information into the slave OBT device by sending an instruction carrying the security domain information to the slave OBT device. Similar to the configuration method of the security domain shown in fig. 4, the master OBT device obtains security domain information configured by itself from the secDomain resource, and sends an instruction to the slave OBT device. At this time, the master OBT device is a client, and the slave OBT device is a server. The request and response procedures between the master and slave OBT devices are consistent with the existing CRUDN operation procedures, and are not described in detail herein.

Fig. 7 is a schematic flowchart of a configuration method of a security domain provided in an embodiment of the present application. The method may be performed by the slave OBT device in conjunction with the configuration method of the security domain shown in FIG. 6 to complete the configuration of the security domain of the slave OBT device. In addition, the slave OBT may perform a secure domain configuration for other devices to be configured similar to the secure domain configuration method shown in FIG. 4.

As shown in fig. 7, the configuration method of the security domain includes:

step 710, receiving an instruction carrying security domain information;

step 720, performing security domain configuration according to the security domain information in the instruction;

step 730, obtaining security domain information;

And 740, setting the security domain information into the device to be configured by sending an instruction carrying the security domain information to the device to be configured.

Steps

710 and 720 are similar to

steps

510 and 520, respectively, of the configuration method of the security domain shown in fig. 5, and steps 730 and 740 are similar to

steps

410 and 420, respectively, of the configuration method of the security domain shown in fig. 4, and are not repeated here.

After the security domain configuration is completed by the slave OBT device, the secDomain resource of the slave OBT device may be configured as the same secDomain resource as the master OBT device. For example, it has the following form:

{

“sdid”＝e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9，

“sdn”＝my home，

“discoverable”＝true

}

the configuration methods of the security domains shown in fig. 6 and 7 are performed in conjunction with each other, so that the master and slave OBT devices may form a security domain network. In addition, the master and slave OBT devices may respectively configure other IoT devices using the configuration method of the security domain shown in FIG. 4, so that other IoT devices may also access the security domain network. It should be noted that, in the above example, the master on-board device sends the security domain information to the slave on-board device, and the slave on-board device also configures itself and other IoT devices according to the security domain information, so that the master on-board device and other IoT devices configured by the master on-board device have the same security domain identifier and security domain name. That is, the master OBT device and its configured other IoT devices, and the slave OBT device and its configured other IoT devices are in the same security domain network. In this case, for example, the secDomain resource from the OBT device and its configured IoT device (hereinafter referred to as "third device") may be configured in the form of, for example:

{

“sdid”＝e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9，

“sdn”＝my home，

“discoverable”＝true

}

And when the security domain configuration is carried out, mapping the sdid attribute to the res resource from the OBT equipment according to the attribute value of the discomposable in the security domain information as true. For example, the representation of sdid in res resources from the OBT device may be:

″secdomainuuid″：″e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9″

the attribute value of the discomposable in the security domain information is false, and the security domain of the slave OBT device cannot be found by other devices.

In practice, more than one OBT device may be present in the same network, e.g., OBT1 and OBT2 are present. The OBT1 and the OBT2 may generate random numbers according to their own authentication root certificates, respectively, and use the random numbers as security domain identifiers, and the user may set the security domain names of the OBT1 and the OBT2 to be the same or different. In this case, since the authentication root certificate of the OBT1 and the authentication root certificate of the OBT2 are different, the security domain identifier of the OBT1 and the security domain identifier of the OBT2 are different. That is, the IoT device (including the slave and the device to be configured) of the OBT1 and its configuration have the same security domain identifier and security domain name, forming a first security domain network, and the IoT device (including the slave and the device to be configured) of the OBT2 and its configuration have the same security domain identifier and security domain name, forming a second security domain network. Whether the first secure domain network and the second secure domain network have the same secure domain name or not, the first secure domain network and the second secure domain network are independent secure domain networks because the first secure domain network and the second secure domain network have different secure domain identifiers.

For example, the secDomain resource of the IoT device (hereinafter "fourth device") of the OBT1 and its configuration may be configured in the following form, for example:

{

“sdid”＝e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9，

“sdn”＝my home，

“discoverable”＝true

}

the secDomain resources of the IoT 2 and its configured IoT devices (hereinafter "fifth devices") may be configured, for example, in the form of:

{

“sdid”＝61c74915-6491-12d2-7934-1da81f1ce27d，

“sdn”＝my room，

“discoverable”＝true

}

the secDomain resources of the IoT 2 and its configured IoT devices (hereinafter "sixth devices") may be configured, for example, in the form of:

{

“sdid”＝61c74915-6491-12d2-7934-1da81f1ce27d，

“sdn”＝my home，

“discoverable”＝true

}

when the security domain configuration is carried out, the OBT2 maps the sdid attribute to the res resource according to the attribute value of the discomposable in the security domain information as true. For example, the representation of the sdid of the OBT2 in the res resource may be:

″secdomainuuid″：″61c74915-6491-12d2-7934-1da81f1ce27d″

the expression "61c74915-6491-12d2-7934-1da81f1ce27d" in the above representation is different from the security domain identifier "e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9" of the obs 1 in the previous example, and thus the obs 1 and the obs 2 form separate security domain networks, respectively.

The internet of things device in the network configures the security domain information by executing part or all of the security domain configuration methods in fig. 3 to 7, and forms at least one security domain network. At this time, if a new IoT device (hereinafter referred to as a "discovery device") enters the network, it is desired to discover a security domain network already existing in the network, the discovery method of the security domain provided in the embodiments of the present application may be performed.

Fig. 8 is a schematic flow chart of a method for discovering a security domain according to an embodiment of the present application. The method may be performed by a discovery device.

As shown in fig. 8, the discovery method of the security domain includes acquiring discovery resources of IoT devices in the network in step S810.

In this step, acquiring discovery resources of IoT devices in the network may employ any existing execution resource discovery process. For example, a request message for performing resource discovery is sent to other IoT devices in the network, and then discovery resources fed back by the other IoT devices are received.

In particular, the discovery device, as a client, may send broadcast/multicast messages to other IoT devices in the network to perform resource discovery. For example, the broadcast/multicast message may be a RETRIEVE request message to request a secDomain resource representation on the server. The broadcast/multicast message may be of the form:

RETRIEVE/oic/resif＝oic.if.baseline

after receiving the RETRIEVE request, other IoT devices in the network act as servers to verify whether the client sending the request has permission to acquire the required resources and whether the relevant attributes of the resources are readable. And if so, the server side sends a RETRIEVE response message carrying the res resource to the discovery device.

The discovery method of the security domain of the present embodiment includes acquiring a security domain identifier from a discovery resource in step S820.

Then, the discovery device receives a RETRIEVE response message carrying the res resource, and acquires the security domain identifier from the res resource in the RETRIEVE response message. For example, "e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9" may be obtained from the first device in the foregoing example. Since the security domain of the second device in the previous example cannot be discovered, the discovery device cannot obtain the security domain identifier of the second device from the res resource of the second device. For another example, "e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9" may be obtained from the fourth device in the foregoing example, and "61c74915-6491-12d2-7934-1da81f1ce27d" may be transmitted from the fifth device to the discovery device.

After the discovery device obtains the security domain identifier, it may determine a security domain corresponding to the security domain identifier in the network in step 830. After determining the security domains present in the network, the security domains may be saved for later use or displayed for viewing by a user.

For example, if the security domain identifier is obtained from only one IoT device, this security domain may be saved directly or displayed for the user to choose whether to join. Alternatively, the security domain identifiers may be compared when the security domain identifiers are obtained from at least two IoT devices. When the security domain identifiers are the same, it is determined that a security domain exists in the network. When the security domain identifiers are different, it is determined that a plurality of security domains exist in the network. How many security domains exist with how many different security domain identifiers. Further, the security domain identifier may be used to represent a security domain present in the network, and the security domain identifier may be displayed for the user to view or select a security domain to join.

Fig. 9 is a schematic flowchart of a method for discovering a security domain according to an embodiment of the present application. The method may be performed by a discovery device. In order to facilitate the user to view the security domain existing in the network, the corresponding security domain name may be further obtained according to the security domain identifier.

As shown in fig. 9, the discovery method of the security domain includes:

step S910, obtaining discovery resources of IoT devices in a network;

step S920, obtaining a security domain identifier from the discovery resource;

step S930, determining the security domain existing in the network according to the security domain identifier;

step S940, according to the security domain identifier, obtaining a security domain name corresponding to the security domain identifier from the IoT device;

step S950 represents the security domains existing in the network according to the security domain identifiers and the corresponding security domain names.

The steps 910 to 930 are identical to the steps 810 to 830 of the security domain discovery method shown in fig. 8, respectively, and are not described herein.

After the discovery device obtains the security domain identifier, a security domain name corresponding to the security domain identifier may also be obtained from the IoT device according to the obtained security domain identifier. Specifically, a request message to obtain a security domain name corresponding to the security domain identifier may be sent to other IoT devices. For example, the discovery device sends a RETRIEVE request message to the first device to request a security domain name in a secDomain resource on the first device. At this time, the RETRIEVE request message may be of the form:

RETRIEVE /oic/sec/secDomain

After receiving the RETRIEVE request, the first device sends a RETRIEVE response message carrying the own security domain name to the discovery device. For example, "myhome" is sent to the discovery device. Accordingly, the discovery device also receives security domain names fed back by other IoT devices.

In this embodiment, after the secure domain name corresponding to the secure domain identifier is obtained, the secure domain name may be used to represent the secure domain existing in the network. Because, as described above, the security domain name is generally set by the user and is relatively easily identified by the user, representing the security domain existing in the network with the security domain name may facilitate the user's view or selection of the security domain to be joined. In particular, when it is determined that a security domain exists in the network, the security domain may be represented by a security domain name. When multiple security domains exist in the determination network and the multiple security domains have different security domain names, the multiple security domains may be represented by respective security domain names. When a plurality of security domains exist in the determination network and the plurality of security domains have the same security domain name, the plurality of security domains are represented by a security domain identifier and a corresponding security domain name.

The following description will be made taking, as an example, the first to sixth devices involved in the foregoing examples of the secure domain configuration method:

when there is only one set of security domain identifiers and their corresponding security domain names, the security domain names may be presented directly to the user. As described above, only the first device sends "my home" to the discovery device, and the "my home" may be presented directly to the user.

When two groups of security domain identifiers and corresponding security domain names exist, comparing whether the security domain identifiers and the security domain names are identical. When the security domain identifier and the security domain name are identical, respectively, the security domain name may be presented directly to the user. For example, the first device and the third device described above may send "e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9" and the corresponding "my home" to the discovery device, respectively. Since the security domain identifier and the security domain name are identical, respectively, the security domain name ("my home") may be presented directly to the user, although there are two sets of security domain identifiers and their corresponding security domain names.

When the security domain identifier and the security domain name are different, it is determined that two security domain networks exist, and the different security domain identifiers and the corresponding security domain names thereof can be presented to the user.

For example, the fourth device transmits "e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9" and the corresponding "my home" to the discovery device, and the fifth device transmits "61c74915-6491-12d2-7934-1da81f1ce27d" and the corresponding "my room" to the discovery device. Since the security domain identifier and the security domain name are different, the comparison result (including "e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9" and corresponding "my home", 61c74915-6491-12d2-7934-1da81f1ce27d "and corresponding" my room ") is presented to the user. In another example, the security domain identifier may not be presented, but only the security domain names, "my home" and "my room" may be presented to the user.

When the security domain identifiers are different and the security domain names are the same, it is determined that two security domain networks exist, and the different security domain identifiers and the corresponding security domain names can be presented to the user. For example, the fourth device transmits "e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9" and the corresponding "my home" to the discovery device, and the sixth device transmits "61c74915-6491-12d2-7934-1da81f1ce27d" and the corresponding "my home" to the discovery device. Although the security domain names are the same, the comparison results (including "e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9" and corresponding "my home", 61c74915-6491-12d2-7934-1da81f1ce27d "and corresponding" my home ") are presented to the user because the security domain identifiers are different.

It should be appreciated that for more than two sets of security domain identifiers and corresponding security domain names, a comparison result may be obtained by selecting two sets at a time for comparison. However, the above comparison method is merely exemplary for facilitating understanding, and the present application should not be limited thereto, and any method suitable for comparing whether the security domain identifier and the corresponding security domain name in each group are the same should be included in the protection scope of the present application.

Fig. 10 is a schematic flow chart of a method for joining a security domain according to an embodiment of the present application. The method may be performed by a discovery device. The discovery device, after obtaining security domain information (including a security domain identifier or a security domain name) for a security domain present in the network, may present the security domain information for selection by a user.

As shown in fig. 10, the method for adding the security domain includes:

step 1010, requesting a user to select a security domain to be added;

step 1020, launching an instance of the security domain according to the security domain selected by the user.

Specifically, after performing the security domain discovery method shown in fig. 8 or 9, the discovery apparatus obtains security domain information of a security domain existing in the network. The discovery device may present this security domain information to the user requesting the user to select which security domain network the discovery device joins.

After receiving a user selection, an instance of the security domain is launched. Specifically, if an instance of the security domain selected by the user exists in the configured instance of the security domain, switching to the instance of the security domain. If there is no instance of the user-selected security domain in the configured instances of the security domains, an instance of the security domain is generated that is available for user selection. That is, the discovery apparatus checks security domain information of an instance that itself has been opened, and if it is determined that there is an instance of the security domain selected by the user therein, switches to the instance. Alternatively, the discovery device determines that the instance of the user-selected security domain does not correspond to the self-configured security domain, and generates a new client instance of the security domain that is available for user selection.

Each of the above examples is a separate logical client device. A plurality of logical client devices may be running in one client Application (APP), each device may correspond to a different security domain. When a new client instance is generated, the client instance is in an initialized state awaiting activation and configuration, at which point the OBT in the network may activate and configure the client instance to join the security domain in which the OBT resides.

Fig. 11 is a schematic flowchart of a method for discovering a security domain according to an embodiment of the present application. The method may be performed by an IoT device in the network that has completed the security domain configuration, feeding back security domain information to a discovery device that performs the discovery method of the security domain shown in fig. 8.

As shown in fig. 11, the discovery method of the security domain includes:

step S1110, in response to a received request message for executing resource discovery, the discovery resource is fed back;

step S1120, feeding back the security domain name in response to the received request message for obtaining the security domain name corresponding to the security domain identifier.

As described above, after receiving the broadcast/multicast message, the IoT device in the network verifies as a server whether the client sending the request has the right to acquire the required resources and whether the relevant attributes of the resources are readable. And if so, the server side sends a RETRIEVE response message carrying the res resource to the discovery device. After receiving the request for acquiring the security domain name, the security domain name of the user is fed back to the discovery device.

In embodiments of the present application, in the example of instructions, UPDATE operations are referred to, which is for the case where secDomain resources have been set in IoT devices. In practice, if the secDomain resource is not set in the device to be configured, the OBT may initiate a request by using a CREATE operation in the CREATE operation, and the device to be configured responds to the CREATE request message, and CREATEs a secDomain resource according to the first security domain information carried in the CREATE request message.

Furthermore, the above-mentioned communication procedure of the CRUDN operation is similar to the prior art, except that the request message and the corresponding message carry parameters related to secDomain resources. The communication procedure of the CRUDN operation will not be described in detail here.

It should be understood that, in various embodiments of the present application, the sequence numbers of the foregoing processes do not mean the order of execution, and the order of execution of the processes should be determined by the functions and internal logic thereof, and should not constitute any limitation on the implementation process of the embodiments of the present application.

The configuration, discovery, and joining methods of the security domain according to embodiments of the present application are described in detail above from different angles in conjunction with fig. 1 to 11, and a schematic interaction scenario between IoT devices according to embodiments of the present application will be described below in conjunction with fig. 12 to 15.

Fig. 12 illustrates a first exemplary interaction scenario among IoT devices according to an embodiment of the present application. Assuming that Mom's handset APP is the OBT in the home network, it is first self-activated and configures itself. The network has two devices Device1 and Device2, and the OBT configures the two devices respectively and sets security domain information. At this time, the OBT forms a secure domain network with Device1 and Device2 in the home. Thereafter, dad's cell phone APP enters the home network. As Client, dad's handset APP finds the controllable device and finds its corresponding security domain.

Fig. 13 illustrates a second exemplary interaction scenario among IoT devices according to an embodiment of the present application. Assuming that Mom's handset APP is the master OBT in the home network, it is first self-activated and configures itself. The mobile phone APP of Son is used as a slave OBT and is configured by the mobile phone APP of Mom. Mom's cell-phone APP will self security domain information configuration to Son's cell-phone APP. The network has two devices Device1 and Device2, and the master-slave OBT configures the two devices respectively and sets security domain information. At this time, the master OBT and the slave OBT form a secure domain network in the home with the devices 1 and 2. Thereafter, dad's cell phone APP enters the home network. As Client, dad's handset APP finds the controllable device and finds its corresponding security domain.

Fig. 14 illustrates a third exemplary interaction scenario among IoT devices according to an embodiment of the present application. Assuming that Mom's handset APP is the OBT1 in the home network, it is first self-activated and configures itself. The mobile phone APP of Son is also used as OBT2, and is self-activated and configured. The network is provided with two devices, namely Device1 and Device2, and the Mom mobile phone APP and the Son mobile phone APP respectively configure the two devices and set security domain information. At this time, the OBT1 and the Device1, and the OBT2 and the Device2 form two independent security domain networks in the home, respectively. Thereafter, dad's cell phone APP enters the home network. As Client, dad's handset APP finds the controllable device and finds its corresponding security domain.

Fig. 15 illustrates a fourth exemplary interaction scenario among IoT devices according to an embodiment of the present application. Assuming that Mom's handset APP is the OBT1 in the home network, it is first self-activated and configures itself. The mobile phone APP of Son is also used as OBT2, and is self-activated and configured. The network is provided with two devices, namely Device1 and Device2, and the Mom mobile phone APP and the Son mobile phone APP respectively configure the two devices and set security domain information. At this time, the OBT1 and the Device1, and the OBT2 and the Device2 form two independent security domain networks in the home, respectively. Thereafter, dad's cell phone APP enters the home network. As Client, dad's handset APP finds the controllable device and finds its corresponding security domain.

The configuration, discovery and joining methods of the security domain according to the embodiments of the present application are described in detail above in connection with fig. 1 to 15 from various different angles, and the apparatus according to the embodiments of the present application will be described below in connection with fig. 16 to 21.

As shown in fig. 16, a configuration apparatus of a security domain according to an embodiment of the present application includes: an acquisition module 1610 and a configuration module 1620.

Specifically, the obtaining module 1610 is configured to: and acquiring security domain information. The configuration module 1620 is configured to: and carrying out security domain configuration according to the acquired security domain information. Wherein the security domain information includes at least: a security domain identifier, a security domain name, and security domain discoverability.

Optionally, as an embodiment, the obtaining module is further configured to obtain the security domain information by:

automatically generating a random number as the security domain identifier;

requesting a user to set the security domain name;

requesting a user to set the security domain discoverability.

Optionally, as an embodiment, the obtaining module is further configured to: when the random number is automatically generated as the security domain identifier, the random number is generated according to the authentication root certificate of the random number, and the random number is used as the security domain identifier. Optionally, as an embodiment, the obtaining module is further configured to: receiving an instruction carrying the security domain information; correspondingly, the configuration module is further configured to: and carrying out security domain configuration according to the security domain information in the instruction.

Optionally, as an embodiment, the configuration module is further configured to: and mapping the security domain identifier to a discovery resource according to the attribute value of the security domain discoverability as discoverable.

Optionally, as an embodiment, the configuration module is further configured to: and setting the security domain information into the equipment to be configured by sending an instruction carrying the security domain information to the equipment to be configured.

As shown in fig. 17, a discovery apparatus of a security domain according to an embodiment of the present application includes: a first acquisition module 1710, a second acquisition module 1720, and a determination module 1730.

Specifically, the first obtaining module 1710 is configured to: obtaining discovery resources of internet of things (IoT) devices in a network; the second acquisition module 1720 is configured to: acquiring a security domain identifier from the discovery resource; the determining module 1730 is configured to determine a security domain corresponding to the security domain identifier in the network. Wherein the IoT device has configured security domain information comprising at least: a security domain identifier, a security domain name, and security domain discoverability.

Optionally, as an embodiment, the apparatus further comprises a third acquisition module 1740. The third obtaining module is configured to obtain, from the IoT device, a security domain name corresponding to the security domain identifier according to the security domain identifier obtained by the second obtaining module.

Optionally, as an embodiment, the third obtaining module 1740 includes a sending submodule 1741 and a receiving submodule 1742. The sending submodule 1741 is configured to send a request message to the IoT device for obtaining the security domain name corresponding to the security domain identifier. The receive submodule 1742 is for receiving the security domain name of the IoT device feedback.

Optionally, as an embodiment, the determining module includes a comparing sub-module 1731 and a determining sub-module 1732. Wherein the comparing sub-module 1731 is configured to compare the security domain identifiers when the security domain identifiers are obtained from at least two IoT devices. The determining submodule 1732 is configured to determine that a security domain exists in the network when the security domain identifiers are the same; when the security domain identifiers are different, it is determined that a plurality of security domains exist in the network.

Optionally, as an embodiment, the determining module further includes a representation submodule 1733. Wherein the representation sub-module 1733 is configured to:

when a security domain exists in the network, the security domain is represented by the security domain name;

when a plurality of security domains exist in a determination network and the plurality of security domains have different security domain names, the plurality of security domains are represented by respective security domain names;

when a plurality of security domains exist in the determination network and the plurality of security domains have the same security domain name, the plurality of security domains are represented by the security domain identifier and the corresponding security domain name.

As shown in fig. 18, the discovery apparatus of the security domain according to the embodiment of the present application discovers that security domain information is configured by a part or all of the methods shown in fig. 3 to 7. The discovery device of the security domain comprises: a first feedback module 1810 and a second feedback module 1820.

Specifically, the first feedback module 1810 is configured to: responding to a received request message for executing resource discovery, and feeding back the discovery resource; the second feedback module 1820 is configured to: and responding to the received request message for obtaining the security domain name corresponding to the security domain identifier, and feeding back the security domain name.

As shown in fig. 19, the joining device of the security domain according to the embodiment of the present application includes a request module 1910 and an initiation module 1920. Wherein, the request module 1910 is configured to request a user to select a security domain to be added. The activation module 1920 is configured to activate an instance of the security domain according to the security domain selected by the user. Wherein the security domain is discovered by the method as shown in fig. 8 or 9.

Optionally, as an embodiment, the starting module 1820 is further configured to:

switching to an instance of the security domain when the user-selected instance of the security domain exists in a configured instance of the security domain;

When there is no instance of the security domain selected by the user in the configured instances of security domains, an instance of the security domain available for the user selection is generated.

It should be understood that the above and other operations and/or functions of each module in the configuration, discovery and joining apparatus of the security domain according to the embodiments of the present application are respectively for implementing the corresponding flow of the terminal device in each method in fig. 1 to 11, and are not repeated herein for brevity.

Fig. 20 is a schematic structural diagram of an electronic device 2000 provided in an embodiment of the present application. The electronic device shown in fig. 20 includes a processor 2010, and the processor 2010 may call and execute a computer program from memory to implement the methods in the embodiments of the present application.

Optionally, as shown in fig. 20, the electronic device 2000 may also include a memory 2020. Wherein the processor 2010 may invoke and run a computer program from the memory 2020 to implement the methods in embodiments of the present application.

Wherein the memory 2020 may be a separate device from the processor 2010 or may be integrated in the processor 2010.

Optionally, as shown in fig. 20, the electronic device 2000 may further include a transceiver 2030, and the processor 2010 may control the transceiver 2030 to communicate with other devices, and in particular, may send information or data to other devices or receive information or data sent by other devices.

Among other things, the transceiver 2030 may include a transmitter and a receiver. The transceiver 2030 may further include antennas, the number of which may be one or more.

Optionally, the electronic device 2000 may be specifically an internet of things device in the embodiment of the present application, and the electronic device 2000 may implement corresponding flows in each method in the embodiment of the present application, which is not described herein for brevity.

The electronic device of the present embodiment may be, but is not limited to, a terminal device or a network device. "terminal device" as used herein includes, but is not limited to, a wireless device that transmits data via a wireless interface, such as for a cellular network, a wireless local area network (Wireless Local Area Network, WLAN), a digital television network such as a DVB-H network, a satellite network, an AM-FM broadcast transmitter; and/or means of the other terminal device arranged to receive/transmit communication signals; and/or internet of things (Internet of Things, ioT) devices. Terminal devices arranged to communicate over a wireless interface may be referred to as "wireless communication terminals", "wireless terminals" or "mobile terminals". Examples of mobile terminals include, but are not limited to, satellites or cellular telephones; a personal communications system (Personal Communications System, PCS) terminal that may combine a cellular radiotelephone with data processing, facsimile and data communications capabilities; a PDA that can include a radiotelephone, pager, internet/intranet access, web browser, organizer, calendar, and/or a global positioning system (Global Positioning System, GPS) receiver; and conventional laptop and/or palmtop receivers or other electronic devices that include a radiotelephone transceiver. A terminal device may refer to an access terminal, user Equipment (UE), subscriber unit, subscriber station, mobile station, remote terminal, mobile device, user terminal, wireless communication device, user agent, or User Equipment. An access terminal may be a cellular telephone, a cordless telephone, a session initiation protocol (Session Initiation Protocol, SIP) phone, a wireless local loop (Wireless Local Loop, WLL) station, a personal digital assistant (Personal Digital Assistant, PDA), a handheld device with wireless communication capabilities, a computing device or other processing device connected to a wireless modem, an in-vehicle device, a wearable device, a terminal device in a 5G network or a terminal device in a future evolved PLMN, etc. The network device may provide communication coverage for a particular geographic area and may communicate with terminal devices located within the coverage area. Alternatively, the network device may be a base station (Base Transceiver Station, BTS) in a GSM system or a CDMA system, a base station (NodeB, NB) in a WCDMA system, an evolved base station (Evolutional Node B, eNB or eNodeB) in an LTE system, or a radio controller in a cloud radio access network (Cloud Radio Access Network, CRAN), or the network device may be a mobile switching center, a relay station, an access point, a vehicle device, a wearable device, a hub, a switch, a bridge, a router, a network-side device in a 5G network, or a network device in a future evolved public land mobile network (Public Land Mobile Network, PLMN), etc.

Fig. 21 is a schematic structural diagram of a chip of an embodiment of the present application. The chip 2100 shown in fig. 21 includes a processor 2110, and the processor 2110 can call and run a computer program from a memory to implement the method in the embodiment of the present application.

Alternatively, as shown in fig. 21, the chip 2100 may further include a memory 2120. Wherein the processor 2110 may invoke and run a computer program from the memory 2120 to implement the method in the embodiments of the present application.

The memory 2120 may be a separate device from the processor 2110, or may be integrated into the processor 2110.

Optionally, the chip 2100 may further include an input interface 2130. The processor 2110 may control the input interface 2130 to communicate with other devices or chips, and in particular, may obtain information or data transmitted by other devices or chips.

Optionally, the chip 2100 may further include an output interface 2140. Wherein the processor 2110 may control the output interface 2140 to communicate with other devices or chips, in particular, may output information or data to other devices or chips.

Optionally, the chip may be applied to the internet of things device in the embodiment of the present application, and the chip may implement corresponding flows in each method in the embodiment of the present application, which is not described herein for brevity.

It should be understood that the chips referred to in the embodiments of the present application may also be referred to as system-on-chip chips, or the like.

It should be appreciated that the processor of an embodiment of the present application may be an integrated circuit chip having signal processing capabilities. In implementation, the steps of the above method embodiments may be implemented by integrated logic circuits of hardware in a processor or instructions in software form. The processor may be a general purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), an off-the-shelf programmable gate array (Field Programmable Gate Array, FPGA) or other programmable logic device, discrete gate or transistor logic device, discrete hardware components. The disclosed methods, steps, and logic blocks in the embodiments of the present application may be implemented or performed. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like. The steps of a method disclosed in connection with the embodiments of the present application may be embodied directly in hardware, in a decoded processor, or in a combination of hardware and software modules in a decoded processor. The software modules may be located in a random access memory, flash memory, read only memory, programmable read only memory, or electrically erasable programmable memory, registers, etc. as well known in the art. The storage medium is located in a memory, and the processor reads the information in the memory and, in combination with its hardware, performs the steps of the above method.

It will be appreciated that the memory in embodiments of the present application may be either volatile memory or nonvolatile memory, or may include both volatile and nonvolatile memory. The nonvolatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable EPROM (EEPROM), or a flash Memory. The volatile memory may be random access memory (Random Access Memory, RAM) which acts as an external cache. By way of example, and not limitation, many forms of RAM are available, such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (Double Data Rate SDRAM), enhanced SDRAM (ESDRAM), synchronous DRAM (SLDRAM), and Direct RAM (DR RAM). It should be noted that the memory of the systems and methods described herein is intended to comprise, without being limited to, these and any other suitable types of memory.

It should be understood that the above memory is exemplary but not limiting, and for example, the memory in the embodiments of the present application may be Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous Link DRAM (SLDRAM), direct RAM (DRRAM), and the like. That is, the memory in embodiments of the present application is intended to comprise, without being limited to, these and any other suitable types of memory.

Embodiments of the present application also provide a computer-readable storage medium for storing a computer program.

Optionally, the computer readable storage medium may be applied to a network device in the embodiments of the present application, and the computer program causes a computer to execute a corresponding flow implemented by the network device in each method in the embodiments of the present application, which is not described herein for brevity.

Optionally, the computer readable storage medium may be applied to a mobile terminal/terminal device in the embodiments of the present application, and the computer program causes a computer to execute a corresponding procedure implemented by the mobile terminal/terminal device in each method of the embodiments of the present application, which is not described herein for brevity.

Embodiments of the present application also provide a computer program product comprising computer program instructions.

Optionally, the computer program product may be applied to a network device in the embodiments of the present application, and the computer program instructions cause the computer to execute corresponding flows implemented by the network device in the methods in the embodiments of the present application, which are not described herein for brevity.

Optionally, the computer program product may be applied to a mobile terminal/terminal device in the embodiments of the present application, and the computer program instructions cause a computer to execute corresponding processes implemented by the mobile terminal/terminal device in the methods in the embodiments of the present application, which are not described herein for brevity.

The embodiment of the application also provides a computer program.

Optionally, the computer program may be applied to a network device in the embodiments of the present application, and when the computer program runs on a computer, the computer is caused to execute a corresponding flow implemented by the network device in each method in the embodiments of the present application, which is not described herein for brevity.

Optionally, the computer program may be applied to a mobile terminal/terminal device in the embodiments of the present application, where the computer program when run on a computer causes the computer to execute corresponding processes implemented by the mobile terminal/terminal device in the methods in the embodiments of the present application, and for brevity, will not be described herein.

Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.

It will be clear to those skilled in the art that, for convenience and brevity of description, specific working procedures of the above-described systems, apparatuses and units may refer to corresponding procedures in the foregoing method embodiments, and are not repeated herein.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices, and methods may be implemented in other manners. For example, the apparatus embodiments described above are merely illustrative, e.g., the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, e.g., multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The units described as separate units may or may not be physically separate, and units shown as units may or may not be physical units, may be located in one place, or may be distributed on a plurality of network units. Some or all of the units may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

In addition, each functional unit in each embodiment of the present application may be integrated in one processing unit, or each unit may exist alone physically, or two or more units may be integrated in one unit.

The functions, if implemented in the form of software functional units and sold or used as a stand-alone product, may be stored in a computer-readable storage medium. Based on such understanding, the technical solution of the present application may be embodied essentially or in a part contributing to the prior art or in a part of the technical solution, in the form of a software product stored in a storage medium, including several instructions for causing a computer device (which may be a personal computer, a server, or a network device, etc.) to perform all or part of the steps of the methods described in the embodiments of the present application. And the aforementioned storage medium includes: a usb disk, a removable hard disk, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a magnetic disk, or an optical disk, or other various media capable of storing program codes.

The foregoing is merely specific embodiments of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions are intended to be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A method of configuring a security domain, comprising:

acquiring security domain information;

carrying out security domain configuration according to the security domain information;

wherein the security domain information includes at least: a security domain identifier, a security domain name, and security domain discoverability,

wherein the acquiring security domain information includes:

automatically generating a random number as the security domain identifier;

requesting a user to set the security domain name;

requesting a user to set the security domain discoverability.

2. The method of claim 1, wherein the method further comprises:

and adding security domain resources in the logic device, wherein the security domain resources are used for configuring and managing the security domain to which the logic device belongs.

3. The method of claim 1, wherein the automatically generating a random number as the security domain identifier comprises:

Generating a random number according to the authentication root certificate of the self, and taking the random number as the security domain identifier.

4. The method of claim 1, wherein the performing the security domain configuration according to the acquired security domain information comprises:

and setting the security domain information into the equipment to be configured by sending an instruction carrying the security domain information to the equipment to be configured.

5. The method of claim 1, wherein the obtaining security domain information comprises:

receiving an instruction carrying the security domain information;

the security domain configuration according to the obtained security domain information comprises the following steps:

and carrying out security domain configuration according to the security domain information in the instruction.

6. The method according to any one of claims 1 to 5, wherein the performing security domain configuration according to the acquired security domain information comprises:

if the attribute value of the security domain discoverability characterizes discoverability, mapping the security domain identifier to a discovery resource.

7. A method of discovery of a security domain, comprising:

obtaining discovery resources of internet of things (IoT) devices in a network;

acquiring a security domain identifier from the discovery resource;

Determining a security domain corresponding to the security domain identifier in the network;

according to the security domain identifier, acquiring a security domain name corresponding to the security domain identifier from the IoT device;

8. The method of claim 7, wherein determining a security domain in the network to which the security domain identifier corresponds comprises:

upon obtaining the security domain identifiers from at least two IoT devices, comparing the security domain identifiers;

when the security domain identifiers are the same, determining that a security domain exists in the network;

when the security domain identifiers are different, it is determined that a plurality of security domains exist in the network.

9. The method of claim 7, wherein the obtaining, from the IoT device, a security domain name corresponding to the security domain identifier from the security domain identifier comprises:

sending a request message to the IoT device to obtain the security domain name corresponding to the security domain identifier;

the security domain name that receives the IoT device feedback.

10. The method of claim 7 or 9, wherein after obtaining, from the IoT device, a security domain name corresponding to the security domain identifier from the IoT device, the method further comprises:

11. A security domain discovery method performed by an internet of things device configured with security domain information by the security domain configuration method of any one of claims 1 to 6, comprising:

responding to a received request message for executing resource discovery, and feeding back the discovery resource;

responding to a received request message for obtaining a security domain name corresponding to a security domain identifier, and feeding back the security domain name;

wherein the security domain information includes at least: a security domain identifier, a security domain name, and security domain discoverability;

The security domain identifier is included in the discovery resource when an attribute value of the security domain discoverability characterizes discoverability.

12. A method of joining a security domain, comprising:

requesting a user to select a security domain to be added; wherein the security domain for selection by the user is a security domain discovered by the method of any one of claims 7 to 10;

13. The method of claim 12, wherein the launching an instance of the security domain according to the user-selected security domain comprises:

if the user-selected instance of the security domain exists in the configured security domain instance, switching to the instance of the security domain;

if no instance of the security domain selected by the user is in the configured instances of security domains, an instance of the security domain available for the user selection is generated.

14. A security domain configuration apparatus, comprising:

the acquisition module is used for acquiring the security domain information;

the configuration module is used for carrying out security domain configuration according to the security domain information;

Wherein the obtaining module is further configured to obtain the security domain information by:

automatically generating a random number as the security domain identifier;

requesting a user to set the security domain name;

requesting a user to set the security domain discoverability.

15. The apparatus of claim 14, wherein the apparatus further comprises:

and the security domain resource adding module is used for adding security domain resources in the logic device, wherein the security domain resources are used for configuring and managing the security domain to which the logic device belongs.

16. The apparatus of claim 14, wherein the acquisition module is further configured to:

when the random number is automatically generated as the security domain identifier, the random number is generated according to the authentication root certificate of the random number, and the random number is used as the security domain identifier.

17. The apparatus of claim 14, wherein the configuration module is further to: and setting the security domain information into the equipment to be configured by sending an instruction carrying the security domain information to the equipment to be configured.

18. The apparatus of claim 14, wherein the acquisition module is further configured to: receiving an instruction carrying the security domain information;

The configuration module is further configured to: and carrying out security domain configuration according to the security domain information in the instruction.

19. The apparatus of any of claims 14 to 18, wherein the configuration module is further to: the secure domain identifier is mapped to a discovery resource when an attribute value of the secure domain discoverability characterizes discoverability.

20. A security domain discovery apparatus comprising:

a third obtaining module, configured to obtain, from the IoT device, a security domain name corresponding to the security domain identifier according to the security domain identifier obtained by the second obtaining module;

21. The apparatus of claim 20, wherein the means for determining comprises:

a comparison sub-module to compare the security domain identifiers when the security domain identifiers are acquired from at least two IoT devices;

A judging submodule, configured to judge that a security domain exists in the network when the security domain identifiers are the same; when the security domain identifiers are different, it is determined that a plurality of security domains exist in the network.

22. The apparatus of claim 20, wherein the third acquisition module comprises: a sending submodule, configured to send a request message for obtaining the security domain name corresponding to the security domain identifier to the IoT device;

a receiving sub-module for receiving the security domain name fed back by the IoT device.

23. The apparatus of claim 20 or 22, wherein the determining module further comprises:

a representation sub-module for:

24. A security domain discovery apparatus configured with security domain information by the security domain configuration method according to any one of claims 1 to 6, comprising:

25. A joining apparatus of a security domain, comprising:

the request module is used for requesting a user to select a security domain to be added; wherein the security domain for selection by the user is a security domain discovered by the apparatus of any one of claims 7 to 10;

26. The apparatus of claim 25, wherein the means for starting is further configured to:

27. An electronic device, comprising: a processor and a memory for storing a computer program, the processor being adapted to invoke and run the computer program stored in the memory, to perform the method according to any of claims 1 to 13.

28. A chip, comprising: a processor for calling and running a computer program from a memory, causing a device on which the chip is mounted to perform the method of any one of claims 1 to 13.

29. A computer readable storage medium storing a computer program executable by a processor to implement the method of any one of claims 1 to 13.