CN113678421A

CN113678421A - Security domain configuration, discovery and joining method and device and electronic equipment

Info

Publication number: CN113678421A
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: 2021-11-19
Anticipated expiration: 2040-01-19
Also published as: WO2021142849A1; CN113678421B

Abstract

The embodiment of the application relates to a security domain configuration and discovery method, a security domain configuration and discovery device and an electronic device. In the embodiment of the application, security domain resources are added in the equipment of the Internet of things to configure and manage the security domain to which the equipment belongs, and a solution for configuring the security domain of the Internet of things existing in a network is provided. When the security domain information can be discovered, the attribute values are mapped to the discovery resources of the devices, so that the resource discovery process can be simplified, and other devices can conveniently discover and obtain 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 through discovered security domain information.

Description

Security domain configuration, discovery and joining method and device and electronic equipment

Technical Field

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

Background

The Internet of things (IoT), i.e., "Internet connected with everything", is an extended and expanded network based on the Internet, and combines various information sensing devices with the Internet to form a huge network, thereby realizing the intercommunication of people, machines and things at any time and any place. However, due to the property of the internet of things of 'everything interconnection', the hardware, software and data in the system of the internet of things are very easy to be damaged, changed and leaked due to accidental or malicious reasons. With the rapid development of the internet of things technology, the security of the internet of things is also more important.

A security domain network is a specific network of the internet of things, and the security domain network has an independent security protocol (or security mechanism), and devices of the internet of things in the security domain network can interconnect, intercommunicate, discover and transmit instructions to each other. Devices outside the security domain network cannot access other internet-of-things devices within the security domain network due to security protocol restrictions in the security domain network. The security domain network may be a sub-network of a local area network, and the local area network may have at least one security domain network, and the at least one security domain network is configured in the local area network through an access point device, and the at least one security domain network may have independent security protocols.

In the existing scheme, when a client device enters a local area network, multiple device interactions are required, and an internet of things security domain existing in the network cannot be found conveniently and quickly. In addition, when a plurality of security domains exist in the same network, it is difficult to distinguish the security domains.

Disclosure of Invention

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

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

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

acquiring discovery resources of IoT (Internet of things) equipment in a network;

obtaining a security domain identifier from the discovery resource;

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

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

In a third aspect, a security domain discovery method is provided, which is executed by an internet of things device configured with security domain information by the security domain configuration method described in the first aspect, and includes: feeding back discovery resources in response to a received request message for performing resource discovery; 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 at least comprises: 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 characterizing the security domain discoverability is discoverable.

In a fourth aspect, a security domain joining method is provided, including:

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

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

In a fifth aspect, an apparatus for configuring a security domain is provided, including:

the acquisition module is used for acquiring security domain information;

the configuration module is used for configuring a security domain according to the acquired security domain information;

wherein the security domain information at least comprises: 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 first acquisition module is used for acquiring discovery resources of the IoT equipment in the 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;

In a seventh aspect, there is provided a security domain discovering device, where the security domain configuring device configures security domain information, and the security domain discovering device includes:

a first feedback module, configured to feed back discovery resources in response to a received request message for performing resource discovery;

the second feedback module is used for 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 at least comprises: 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 characterizing the security domain discoverability is discoverable.

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

the request module is used for requesting a user to select a security domain to be added; wherein the security domain selected by the user is the 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.

In a ninth aspect, an electronic device is provided for executing the method in the first aspect or its implementation manners. In particular, the electronic device comprises functional modules for performing the methods of the first aspect or implementations thereof.

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.

In an eleventh aspect, a chip is provided for implementing the method in any one of the first to third aspects or implementations thereof. Specifically, the chip includes: a processor, configured to call and run a computer program from the memory, so that the device on which the chip is installed performs the method in any one of the first to fourth aspects or the implementation manners thereof.

In a twelfth aspect, a computer-readable storage medium is provided for storing a computer program, which causes a computer to execute the method of any one of the 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 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 first to fourth aspects or implementations thereof.

By the technical scheme, the security domain of the internet of things existing in the network can be configured, the resource discovery process can be simplified, and the client device can conveniently discover and obtain the security domain information in the network.

Drawings

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fig. 15 is a schematic diagram of still another interaction scenario 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 a specific embodiment of the present application.

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

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

Fig. 19 is a schematic block diagram of a security domain joining device according to a 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

Technical solutions in the embodiments of the present application will be described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are some embodiments of the present application, but not all embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

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

The IoT devices follow the internet of things device core protocol. Fig. 2 shows an example IoT device core protocol architecture, for example, a RESTful architecture (Representational State Transfer, REST for short) describes an architectural style network system, which refers to a set of architectural constraints and principles, and the application or design that satisfies these constraints and principles is RESTful.

In the protocol architecture shown in fig. 2, the service layer defines the service framework of the device, unifying the canonical IoT device model. Specifically, information such as entity equipment of the internet of things, and functional services and equipment states provided by the equipment 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. A device may be a client or a server, or a device may be both a client and a server. For example, a device (e.g., a light bulb) that implements a certain most basic function may be a server only, and provide the client with query and control, and no control itself or the need to query other devices.

The business interaction between the client and the server is realized by performing RESTful operations on resources, such as Create (Create), read (Retrieve), Update (Update), Delete (Delete), and Notify (Notify) (these operation methods are collectively referred to as "CRUDN operation"). The client is an initiator of the RESTful operation, and the server is a responder of the RESTful operation. The client sends a resource operation request to the server to request to operate the resource on the server. And the server executes the resource operation and returns a response to the client, wherein the response carries the content and the description information of the resource.

In the protocol architecture shown in fig. 2, the resources are described as Resource model layers, each Resource corresponds to a specific Uniform Resource Identifier (URI), and can be accessed by accessing the URI of the Resource, and each Resource has a corresponding interface supporting Restful operation. The transmission protocol layer is used for transmitting the resource content and the description information, and the Restful operation of each resource is converted into entity information to be transmitted among the devices by mapping the resource operation into a specific transmission protocol, so that a means is provided for interconnection and intercommunication among the devices.

In the Protocol architecture shown in fig. 2, for example, a restricted Application Protocol ("CoAP") Protocol may be used to carry resource operations. Each CRUDN operation is mapped to a request/response message of a CoAP protocol, and the client device can operate resources of a server by four methods of obtaining (GET), newly building (POST), updating (PUT) and Deleting (DELETE) in the CoAP protocol, so that the conversion of resource states is realized. However, the bearer Protocol used in the present application is not limited to the CoAP Protocol, and other protocols may also be used, for example, a Message Queue Telemetry Transport (MQTT) Protocol, a hypertext Transfer Protocol (HTTP), and other mainstream bearer protocols may also be used, which are not illustrated herein.

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

At least some IoT devices may have an activation Tool (OBT) disposed thereon. The OBT is a role in the security protocol, and is a tool for configuring an IoT device in a security domain network in which the security protocol is set. The OBT may run on at least one IoT device in the security 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 and also to configure other IoT devices in the security domain network in which it resides. The IoT devices configured by the OBT device may form a security domain network. In a security domain network, there is only one master OBT, and there may be multiple slave OBTs.

Each IoT Device may include one or more logical devices (devices), each logical Device may have multiple Device instances (Device instances), only one Device instance of each logical Device being in an active state and the other Device instances of the logical Device being in an inactive state. The device instance in the active state enables the logical device in which the device instance is located to be discovered, configured and accessed by the logical devices of other IoT devices in the security domain network, and conversely, the logical device in which the device instance in the inactive state is located cannot be discovered, configured and accessed by the logical devices of other IoT devices in the security domain network.

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

Each logic 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 the IoT device can configure a logic device in the IoT device using an OBT tool of a security domain network before entering the security domain network, and the configuration state may be a factory state. The working state refers to a state after the logic device in the IoT device is configured by the OBT of the security domain network, and the IoT device configured by the OBT device can enter the security domain network and interwork with the IoT device in the security domain network. The logic device in the operating state may receive a service instruction to change a function setting corresponding to the logic device, for example, the IoT device is an air conditioner, the air conditioner may correspond to a plurality of logic devices, each logic device may correspond to a function of the air conditioner, and the logic device corresponding to the temperature may receive a temperature instruction to change the temperature setting. The logic device in the configuration state is used for waiting to be configured by the OBT tool so as to enable the logic device to enter the working state. The logical device in the working state can restore the configuration state through reset (reset), when the logical device in the configuration state is in the active state, it can be discovered by the OBT device and can be configured by the OBT device, and conversely, when the logical device in the configuration state is in the inactive state, it can not be discovered by the OBT device and can not be configured by the OBT device.

Fig. 1 exemplarily shows 4 IoT devices, and optionally, the internet of things 100 may include a plurality of IoT devices, which is not limited in this embodiment.

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

On the basis of the related technologies, how to configure the security domain of the internet of things existing in the network 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 present application proposes a security domain configuration, discovery and joining method.

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

The following table 1 shows the characteristics of the secDomain resource, which mainly include a uniform resource identifier, a resource type header, a resource type identifier, an interface, and a description. Where the URI is used to identify and address secDomain resources. The resource type header is used to describe the function of the resource. The resource type identifier is used to distinguish the resource type. Interfaces (interfaces) indicate the mechanism of presentation and acquisition of resources, with different interfaces corresponding to different presentations of resources and to the corresponding mechanism of operation, such as the baseline (baseline) type given in table 1. The functionality for specifying resources is described.

TABLE 1

Exemplarily, the attribute definition of the secDomain resource is shown in table 2. Attributes are used to describe relevant information for a resource, including metadata for the resource. An attribute appears in the form of 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 ═ e61c3e6b-9c54-4b81-8ce5-f9039c1d04d 9". The format of the attribute is determined by the encoding, for example, in JSON the attribute is represented as "attribute name": value (e.g., "sdid": e61c3e6b-9c54-4b81-8ce5-f9039c1d04d 9).

TABLE 2

In addition to this, the value type defines the values that the attribute values may take. The value type may be a type of simple data such as a string (string), a boolean (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, which may be used for attribute values, and the attribute value rules may define value ranges, maximum/minimum values, formulas, enumerated value ranges, patterns, condition values, and even dependency relationships on attribute values of other attributes, which may be used to verify the attribute values. As shown in table 2, for example, the value types of the security domain identifier and the security domain name are both "string", and the value type of the security domain discoverability is "borolean".

The access mode specifies whether the attribute can be read, written, or read-writable. For example, "R" stands for readable, "W" stands for writable, "RW" stands for readable and writable. "W" writable does not automatically mean that the property must be readable. Illustratively, the security domain identifier, security domain name, and security domain discoverable access mode are all "RWs".

Readability of attributes describes information, describes the role and use of 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 via multicast (multicast). The security domain discoverability description indicates that: whether the security domain is discoverable; the security domain is discoverable when the attribute value of the security domain discoverability is TRUE (TRUE); and when the attribute value of the security domain discoverability is FALSE (FALSE), the security domain is not discoverable.

Table 2 shows that there are 3 attributes of the secDomain resource, and optionally, the secDomain resource may include more than 3 attributes, or less than 3 attributes (for example, only one of the security domain identifier and the security domain name and the security domain discoverability are included), which is not limited in this embodiment of the application.

Fig. 3 is a schematic flowchart of a security domain configuration method 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, security domain configuration of the OBT device itself can be completed.

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

step S310, security domain information is obtained;

step S320, performing security domain configuration according to the acquired security 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. Legitimate users establish device ownership using an Owner Transfer Method (OTM) through an activation tool (OBT). And after ownership is established, the OBT is used for carrying out equipment configuration, and finally the logic equipment can normally operate and interact with other logic equipment.

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

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

Illustratively, a 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 input a security domain identifier and/or security domain name. As another example, a check box may be presented for a user to select security domain discoverability. However, the present application should not be limited to the examples herein, and all existing human-computer interaction methods can 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:

when the attribute discover value is TRUE, the security domain identifier attribute value may be mapped into the secdomainnuuid of the res resource of the OBT device. For example, the security domain identifier may be represented in the res resource in the form of:

"secdomainuuid":"e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9"

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

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

step S410, security domain information is obtained;

step S420, setting the security domain information to 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 a device (hereinafter referred to as a device to be configured) which needs to be configured in the network, the device to be configured returns a owner assignment method supported by the OBT to the OBT, and the OBT establishes communication connection with the device to be configured according to the owner assignment method. Optionally, a secure communication connection is established between the OBT device and the device to be configured. This process is similar to the process of activating and establishing a communication connection in the prior art, and is not described in detail herein.

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

For example, the instructions may be of the form:

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

For another example, the instruction may be in the form of:

this instruction sets uuid (e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9), name (my home), and discoverability (non-discoverability) of the security domain into the device to be configured. For the convenience of explanation and explanation below, this instruction is referred to as "second instruction", and the device to be configured by the second instruction is referred to as "second device".

In addition to setting 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 types, identifying whether a device owner, device ID, device owner ID, and resource owner ID is created, etc.),/oic/sec/cred resources (for configuring selected credentials (including credentials for establishing secure connections with the CMS, credentials for establishing local area network secure connections with other devices), owner ID of resources, etc.), and so forth. These resource allocation procedures may adopt the existing allocation procedures, which are not described herein in detail.

After completing the configuration of all resources (the device completing the resource configuration may be referred to as a "configured device" for short), the OBT changes the state of the device to be configured to an operating state. The OBT is a master of the network, and can configure the interconnection and intercommunication of Client (Client) equipment and Server (Server) equipment in the network. After configuration, the OBT is the owner (owner) of the configured device.

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

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

step S510, receiving an instruction carrying security domain information;

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

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

Specifically, as described above, the device to be configured receives an UPDATE request message (i.e., the above-described "instruction") as a server. After receiving the UPDATE request, the device to be configured verifies whether the OBT sending the request has the right to UPDATE the related resources. If so, the device to be configured UPDATEs the information of the secDomain resource according to the attribute value of the secDomain resource, which is included in the UPDATE request message and needs to be updated. That is, after receiving an instruction from the 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 fact that the attribute value of the discover is true. The representation of sdid in res resource may be:

"secdomainuuid":"e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9"

in contrast, for the second instruction, since the attribute value of the discover 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 receives the second instruction may not be discoverable by other devices.

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

The configuration methods of the security domains shown in fig. 4 and 5 are executed in cooperation with each other, so that the OBT and the device to be configured may form a security domain network. It is worth noting 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 security domain configuration method according to an embodiment of the present application. The method may be performed by a primary OBT device. In this case, the master OBT device in the security domain network may perform a security domain configuration method for the slave OBT device similar to the security domain configuration method shown in fig. 4.

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

step 610, acquiring security domain information;

and step 620, setting the security domain information into the slave OBT equipment by sending an instruction carrying the security domain information to the slave OBT equipment.

After the main OBT device is self-activated and the device ownership time/time is configured, the main OBT also creates different roles in various security domain networks, and the different roles have different permissions. For example, there are various user roles such as administrator (admin), family member (family), guest (guest). As another example, an administrator (admin) has the authority to configure and manage other IoT devices in the same security domain network, while a family member (family) has the authority to control other IoT devices in the same security domain network. In practice, it should not be limited to the examples herein, and the user may create different roles according to the needs and set different permissions for the different roles.

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

The main OBT device can 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 main OBT device is a client, and the slave OBT device is a server. The request and response process between the master OBT device and the slave OBT device is consistent with the existing CRUDN operation process, and is not described in detail herein.

Fig. 7 is a schematic flowchart of a security domain configuration method according to an embodiment of the present application. The method may be executed by a slave OBT device in cooperation with the security domain configuration method shown in FIG. 6 to complete configuration of the security domain of the slave OBT device. In addition, the slave OBT may also perform a security domain configuration method similar to the security domain configuration method shown in fig. 4 to configure other devices to be configured.

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

step 710, receiving an instruction carrying security domain information;

step 720, configuring a security domain according to the security domain information in the instruction;

step 730, security domain information is acquired;

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

Steps

710 and 720 are similar to

steps

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

steps

410 and 420 of the configuration method of the security domain shown in fig. 4, respectively, and therefore, for avoiding repetition, detailed descriptions thereof are omitted here.

After the slave OBT device completes the security domain configuration, the secDomain resource of the slave OBT device may be configured as the same secDomain resource as the master OBT device. For example, in the form:

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

and when the security domain is configured, the slave OBT equipment maps the sdid attribute to the res resource according to the fact that the attribute value of the convertible in the security domain information is true. For example, the representation of sdid of the slave OBT device in res resource may be:

"secdomainuuid":"e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9"

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

In practice, there may be more than one OBT device in the same network, e.g., OBT1 and OBT 2. The OBT1 and the OBT2 may generate random numbers from 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 OBT1 and its configured IoT devices (including the slave OBT device and the device to be configured) have the same security domain identifier and security domain name, forming a first security domain network, while the OBT2 and its configured IoT devices (including the slave OBT device and the device to be configured) have the same security domain identifier and security domain name, forming a second security domain network. Regardless of whether the first security domain network and the second security domain network have the same security domain name, the first security domain network and the second security domain network are independent security domain networks because the first security domain network and the second security domain network have different security domain identifiers.

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

the secDomain resource of the OBT2 and its configured IoT device (hereinafter referred to as "fifth device") may be configured, for example, in the following form:

the secDomain resource of the OBT2 and its configured IoT device (hereinafter referred to as "sixth device") may be configured, for example, in the following form:

when security domain configuration is performed, the OBT2 maps the sdid attribute to the res resource according to the fact that the attribute value of the discover in the security domain information is true. For example, sdid of OBT2 may be represented in res resource in the form of:

"secdomainuuid":"61c74915-6491-12d2-7934-1da81f1ce27d"

"61c74915-6491-12d2-7934-1da81f1ce27d" in the above representation is different from the security domain identifier "e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9" of the OBT1 in the foregoing example, so that the OBT1 and the OBT2 form independent security domain networks respectively.

The internet of things devices in the network configure security domain information by executing part or all of the security domain configuration methods in fig. 3 to 7, and form at least one security domain network. At this time, if a new IoT device (hereinafter referred to as a "discovery device") enters the network and wants to discover an existing security domain network in the network, the security domain discovery method provided by the embodiment of the present application may be executed.

Fig. 8 is a schematic flowchart illustrating a security domain discovery method 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 security domains includes, at step S810, acquiring discovery resources of IoT devices in a network.

In this step, acquiring discovery resources of IoT devices in the network may employ any existing performing resource discovery procedure. For example, a request message for performing resource discovery is first 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, acting 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 in the form of:

RETRIEVE/oic/resif＝oic.if.baseline

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

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

Then, the discovery device receives a RETRIEVE response message carrying res resources, and acquires the security domain identifier from res resources 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 foregoing example is not discoverable, the discovery device cannot acquire 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" is transmitted from the above-described fifth device to the discovery device.

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

For example, if a 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 acquired from at least two IoT devices. And when the security domain identifiers are the same, judging that one security domain exists in the network. When the security domain identifiers are different, the existence of a plurality of security domains in the network is determined. There are as many security domains as there are different security domain identifiers. Further, security domains existing in the network may be represented by security domain identifiers, which are displayed for a user to view or select a security domain to join.

Fig. 9 is a schematic flowchart of a security domain discovery method 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 domains existing in the network, the corresponding security domain name may be further acquired according to the security domain identifier.

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

step S910, acquiring discovery resources of IoT equipment in a network;

step S920, security domain identifiers are obtained from the discovery resources;

step S930, determining a 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, representing security domains existing in the network according to the security domain identifiers and the corresponding security domain names.

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

After the discovery device obtains the security domain identifier, the 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 for obtaining 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 the secDomain resource on the first device. At this time, the RETRIEVE request message may be in the form of:

RETRIEVE/oic/sec/secDomain

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

In this embodiment, after acquiring the security domain name corresponding to the security domain identifier, the security domain name may be used to represent a security domain existing in the network. Because, as described above, the security domain name is generally set by the user and is relatively easy to be identified by the user, representing the security domain existing in the network by the security domain name can facilitate the user to view or select the security domain to be joined. Specifically, when it is determined that one security domain exists in the network, the security domain may be represented by a security domain name. When it is determined that a plurality of security domains exist in the network and have different security domain names, the plurality of security domains may be represented by respective security domain names. When it is determined that a plurality of security domains exist in the network and have the same security domain name, the plurality of security domains are represented by security domain identifiers and corresponding security domain names.

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

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

When there are two sets of security domain identifiers and their corresponding security domain names, it is compared whether the security domain identifiers and security domain names are the same. When the security domain identifier and the security domain name are respectively the same, the security domain name can be directly presented to the user. For example, the first device and the third device may send "e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9" and a corresponding "my home" to the discovery device, respectively. Since the security domain identifiers and the security domain names are respectively the same, although there are two sets of security domain identifiers and their corresponding security domain names, the security domain name ("my home") can also be directly presented to the user.

And when the security domain identifier and the security domain name are different, judging that two security domain networks exist, and presenting the different security domain identifiers and the corresponding security domain names to the user.

For example, the fourth device sends "e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9" and the corresponding "my home" to the discovery device, and the fifth device sends "61c74915-6491-12d2-7934-1da81f1ce27d" and the corresponding "my room" to the discovery device. Since both the security domain identifier and the security domain name are not the same, the comparison results (including "e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9" and the corresponding "my home", 61c74915-6491-12d2-7934-1da81f1ce27d "and the corresponding" my room ") are presented to the user. In another example, the security domain identifier may also not be presented, only the security domain names, i.e., "my home" and "my room", are 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 sends "e61c3e6b-9c54-4b81-8ce5-f9039c1d04d9" and the corresponding "my home" to the discovery device, and the sixth device sends "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 understood that, for more than two sets of security domain identifiers and corresponding security domain names, a way of selecting two sets at a time for comparison may be adopted, and finally obtaining a comparison result. However, the above comparison method is only an example for convenience of 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 shall be included in the scope of protection of the present application.

Fig. 10 is a schematic flowchart illustrating a security domain joining method 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 security domain joining method includes:

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

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

Specifically, after performing the discovery method of security domains illustrated in fig. 8 or 9, the discovery device obtains security domain information of security domains 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 the user's 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 security domain instances, switching to the instance of the security domain. If there is no instance of the user-selected security domain in the configured instance of the security domain, an instance of the security domain available for user selection is generated. That is, the discovery apparatus checks security domain information of its own opened instance, and if it is determined that there is an instance of the security domain selected by the user, switches to the instance. Alternatively, the discovery device determines that the instance of the user-selected security domain is inconsistent with its own configured security domain, and generates a new client instance that is available for the user-selected security domain.

Each of the above examples is a separate logical client device. A client Application (APP) may run a plurality of logical client devices, each of which may correspond to a different security domain. When a new client instance is generated, the client instance is in an initialization state, and waits for 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 is located.

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

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

step S1110, feeding back discovery resources in response to the received request message for performing resource discovery;

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

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

In the embodiment of the present application, the example of the instruction relates to UPDATE operation, which is a case where secDomain resources are already set in an IoT device. 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 CRUDN 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 communication process of the above-mentioned referred CRUDN operation is similar to the prior art, except that parameters related to secDomain resources are carried in the request message and the corresponding message. The communication process of the CRUDN operation will not be described in detail herein.

It should be understood that, in the various embodiments of the present application, the sequence numbers of the above-mentioned processes do not mean the execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

The configuration, discovery, and joining methods of security domains according to embodiments of the present application are described in detail above with reference to fig. 1 to 11 from different perspectives, and a schematic interaction scenario between IoT devices according to embodiments of the present application will be described below with reference to 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 acts as an OBT in the home network, it first self-activates and configures itself. The network has two devices, Device1 and Device2, and the OBT configures the two devices and sets security domain information. At this time, the OBT and the devices 1, 2 form a security domain network in the home. Then, the handset APP of Dad enters the home network. As a Client, the mobile APP of Dad discovers 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 acts as the primary OBT in the home network, it first self-activates and configures itself. The Son mobile phone APP is configured by the Mom mobile phone APP as a slave OBT. And the mobile phone APP of the Mom configures the security domain information of the Mom to the mobile phone APP of the Son. The network has two devices 1 and 2, and the master and slave OBTs configure the two devices respectively and set security domain information. At this time, the master OBT, the slave OBT and the devices 1, 2 form a security domain network in the home. Then, the handset APP of Dad enters the home network. As a Client, the mobile APP of Dad discovers 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 disclosure. Assuming that Mom's handset APP acts as an OBT1 in the home network, it first self-activates and configures itself. Son's cell phone APP also self-activates and configures itself as an OBT 2. The network has two devices Device1 and Device2, and the mobile phone APP of Mom and the mobile phone APP of Son respectively configure the two devices and set security domain information. At this time, the OBT1 and Device1, and the OBT2 and Device2 form two independent security domain networks in the home, respectively. Then, the handset APP of Dad enters the home network. As a Client, the mobile APP of Dad discovers the controllable device and finds its corresponding security domain.

Fig. 15 illustrates a fourth exemplary interaction scenario among IoT devices in accordance with an embodiment of the present disclosure. Assuming that Mom's handset APP acts as an OBT1 in the home network, it first self-activates and configures itself. Son's cell phone APP also self-activates and configures itself as an OBT 2. The network has two devices Device1 and Device2, and the mobile phone APP of Mom and the mobile phone APP of Son respectively configure the two devices and set security domain information. At this time, the OBT1 and Device1, and the OBT2 and Device2 form two independent security domain networks in the home, respectively. Then, the handset APP of Dad enters the home network. As a Client, the mobile APP of Dad discovers the controllable device and finds its corresponding security domain.

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

As shown in fig. 16, the security domain configuring apparatus 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: security domain information is obtained. The configuration module 1620 is configured to: and configuring the security domain according to the acquired security domain information. Wherein the security domain information at least comprises: 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: and when the random number is automatically generated as the security domain identifier, generating the random number according to the self authentication root certificate, and using the random number as the security domain identifier. Optionally, as an embodiment, the obtaining module is further configured to: receiving an instruction carrying the security domain information; accordingly, the configuration module is further configured to: and configuring a security domain according to the security domain information in the instruction.

Optionally, as an embodiment, the configuration module is further configured to: mapping the security domain identifier to a discovery resource in accordance with the security domain discoverability attribute value being 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 security domain discovery apparatus 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: acquiring discovery resources of IoT (Internet of things) equipment in a network; the second acquisition module 1720 is to: obtaining 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, the 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 includes a third obtaining module 1740. The third obtaining module is configured to obtain, according to the security domain identifier obtained by the second obtaining module, a security domain name corresponding to the security domain identifier from the IoT device.

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

Optionally, as an embodiment, the determination module includes a comparison sub-module 1731 and a decision sub-module 1732. Wherein the comparison submodule 1731 is configured to compare the security domain identifiers when the security domain identifiers are acquired 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; and when the security domain identifiers are different, judging that a plurality of security domains exist in the network.

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

when judging that one security domain exists in the network, representing the security domain by using the security domain name;

when it is determined that a plurality of security domains exist in a network and have different security domain names, representing the plurality of security domains by respective security domain names;

when it is determined that a plurality of security domains exist in a network and 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 security domain discovering device according to the embodiment of the present application discovers that the security domain information is configured by a partial or whole method as shown in fig. 3 to 7. The security domain discovery device comprises: a first feedback module 1810 and a second feedback module 1820.

Specifically, the first feedback module 1810 is configured to: feeding back discovery resources in response to a received request message for performing resource discovery; 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, a security domain joining device according to an embodiment of the present application includes a requesting module 1910 and a starting module 1920. The requesting module 1910 is configured to request a user to select a security domain to be joined. The starting module 1920 is configured to start an instance of the security domain according to the security domain selected by the user. Wherein the security domain is discovered by a 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 security domain instance;

generating an instance of the security domain available for the user selection when there is no instance of the security domain selected by the user in the configured instance of the security domain.

It should be understood that the above and other operations and/or functions of each module in the security domain configuring, discovering, and joining apparatus according to the embodiment of the present application are respectively for implementing corresponding processes of the terminal device in each method in fig. 1 to fig. 11, and are not described herein again for brevity.

Fig. 20 is a schematic structural diagram of an electronic device 2000 according to 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 a memory to implement the method in the embodiment of the present application.

Optionally, as shown in fig. 20, the electronic device 2000 may also include a memory 2020. From the memory 2020, the processor 2010 may call and execute a computer program to implement the method in the embodiment of the present application.

The memory 2020 may be a separate device from the processor 2010 or may be integrated into 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 transmit information or data to the other devices or receive information or data transmitted by the other devices.

The transceiver 2030 may include a transmitter and a receiver, among others. The transceiver 2030 may further include one or more antennas.

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

The electronic device of this embodiment may be, but is not limited to, a terminal device or a network device. As used herein, "terminal device" includes, but is not limited to, a terminal device via a Wireless interface, such as for a cellular Network, a 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 another terminal device arranged to receive/transmit communication signals; and/or Internet of Things (IoT) devices. A terminal device arranged to communicate over a wireless interface may be referred to as a "wireless communication terminal", "wireless terminal", or "mobile terminal". Examples of mobile terminals include, but are not limited to, satellite or cellular telephones; personal Communications Systems (PCS) terminals that may combine cellular radiotelephones with data processing, facsimile, and data Communications capabilities; PDAs that may include radiotelephones, pagers, internet/intranet access, Web browsers, notepads, calendars, and/or Global Positioning System (GPS) receivers; and conventional laptop and/or palmtop receivers or other electronic devices that include a radiotelephone transceiver. Terminal Equipment 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 (SIP) phone, a Wireless Local Loop (WLL) station, a Personal Digital Assistant (PDA), a handheld device having Wireless communication capabilities, a computing device or other processing device connected to a Wireless modem, a vehicle mounted device, a wearable device, a terminal device in a 5G network, or a terminal device in a future evolved PLMN, etc. A network device may provide communication coverage for a particular geographic area and may communicate with terminal devices located within that coverage area. Optionally, the Network device may be a Base Transceiver Station (BTS) in a GSM system or a CDMA system, a Base Station (NodeB, NB) in a WCDMA system, an evolved Node B (eNB or eNodeB) in an LTE system, or a wireless controller in a Cloud Radio Access Network (CRAN), or may be a Network device in a Mobile switching center, a relay Station, an Access point, a vehicle-mounted 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 Public Land Mobile Network (PLMN) for future evolution, or the like.

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 may call and run a computer program from a memory to implement the method in the embodiment of the present application.

Optionally, as shown in fig. 21, the chip 2100 may further include a memory 2120. From the memory 2120, the processor 2110 may call and run a computer program 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 with 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 specifically, may obtain information or data transmitted by other devices or chips.

Optionally, the chip 2100 may further include an output interface 2140. The processor 2110 may control the output interface 2140 to communicate with other devices or chips, and 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 processes in each method in the embodiment of the present application, and for brevity, details are not described here again.

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

It should be understood that the processor of the embodiments 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 performed by integrated logic circuits of hardware in a processor or instructions in the form of software. The Processor may be a general purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), an off-the-shelf Programmable Gate Array (FPGA) or other Programmable logic device, discrete Gate or transistor logic device, or discrete hardware components. The various methods, steps, and logic blocks disclosed 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 the method disclosed in connection with the embodiments of the present application may be directly implemented by a hardware decoding processor, or implemented by a combination of hardware and software modules in the decoding processor. The software module may be located in ram, flash memory, rom, prom, or eprom, registers, etc. storage media as is well known in the art. The storage medium is located in a memory, and a processor reads information in the memory and completes the steps of the method in combination with hardware of the processor.

It will be appreciated that the memory in the embodiments of the subject application can be either volatile memory or nonvolatile memory, or can include both volatile and nonvolatile memory. The non-volatile Memory may be a Read-Only Memory (ROM), a Programmable ROM (PROM), an Erasable PROM (EPROM), an Electrically Erasable PROM (EEPROM), or a flash Memory. Volatile Memory can be Random Access Memory (RAM), which acts as external cache Memory. By way of example, but not limitation, many forms of RAM are available, such as Static random access memory (Static RAM, SRAM), Dynamic Random Access Memory (DRAM), Synchronous Dynamic random access memory (Synchronous DRAM, SDRAM), Double Data Rate Synchronous Dynamic random access memory (DDR SDRAM), Enhanced Synchronous SDRAM (ESDRAM), Synchronous link SDRAM (SLDRAM), and Direct Rambus 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 memories are exemplary but not limiting illustrations, for example, the memories in the embodiments of the present application may also be Static Random Access Memory (SRAM), dynamic random access memory (dynamic RAM, DRAM), Synchronous Dynamic Random Access Memory (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (enhanced SDRAM, ESDRAM), Synchronous Link DRAM (SLDRAM), Direct Rambus RAM (DR RAM), and the like. That is, the memory in the embodiments of the present application is intended to comprise, without being limited to, these and any other suitable types of memory.

The embodiment of the application also provides a computer readable storage medium for storing the computer program.

Optionally, the computer-readable storage medium may be applied to the network device in the embodiment of the present application, and the computer program enables the computer to execute the corresponding process implemented by the network device in each method in the embodiment of the present application, which is not described herein again for brevity.

Optionally, the computer-readable storage medium may be applied to the mobile terminal/terminal device in the embodiment of the present application, and the computer program enables the computer to execute the corresponding process implemented by the mobile terminal/terminal device in each method in the embodiment of the present application, which is not described herein again 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 the network device in the embodiment of the present application, and the computer program instructions enable the computer to execute corresponding processes implemented by the network device in the methods in the embodiment of the present application, which are not described herein again for brevity.

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

The embodiment of the application also provides a computer program.

Optionally, the computer program may be applied to the network device in the embodiment of the present application, and when the computer program runs on a computer, the computer is enabled to execute the corresponding process implemented by the network device in each method in the embodiment of the present application, and for brevity, details are not described here again.

Optionally, the computer program may be applied to the mobile terminal/terminal device in the embodiment of the present application, and when the computer program runs on a computer, the computer is enabled to execute the corresponding process implemented by the mobile terminal/terminal device in each method in the embodiment of the present application, which is not described herein again for brevity.

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 implementation. 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 is clear to those skilled in the art that, for convenience and brevity of description, the specific working processes of the above-described systems, apparatuses and units may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.

In the several embodiments provided in the present application, it should be understood that the disclosed system, apparatus and method may be implemented in other ways. For example, the above-described apparatus embodiments are merely illustrative, and for example, the division of the units is only one logical division, and other divisions may be realized in practice, for example, a plurality of units or components may be combined or integrated into another system, or some features may be omitted, or not executed. In addition, the shown or discussed mutual coupling or direct coupling or communication connection may be an indirect coupling or communication connection through some interfaces, devices or units, and may be in an electrical, mechanical or other form.

The units described as separate parts may or may not be physically separate, and parts displayed 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 can be selected according to actual needs to achieve the purpose of the solution of the embodiment.

In addition, functional units in the embodiments of the present application may be integrated into one processing unit, or each unit may exist alone physically, or two or more units are integrated into 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 or portions thereof that substantially contribute to the prior art may be embodied in the form of a software product stored in a storage medium and including instructions for causing a computer device (which may be a personal computer, a server, or a network device) to execute all or part of the steps of the method according to the embodiments of the present application. And the aforementioned storage medium includes: various media capable of storing program codes, such as a usb disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk, or an optical disk.

The above description is only for the 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 conceive of the changes or substitutions within the technical scope of the present application, and shall 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

A security domain configuration method, comprising:

acquiring security domain information;

performing security domain configuration according to the acquired security domain information;

wherein the security domain information comprises: security domain discoverability and at least one of a security domain identifier and a security domain name.
The method of claim 1, wherein the obtaining security domain information comprises:

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.
The method of claim 2, wherein the automatically generating a random number as the security domain identifier comprises:

and generating a random number according to the self authentication root certificate, and using the random number as the security domain identifier.
The method according to any one of claims 1 to 3, wherein the configuring of the security domain 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.
The method of claim 1, wherein the obtaining security domain information comprises:

receiving an instruction carrying the security domain information;

the configuring the security domain according to the acquired security domain information includes:

and configuring a security domain according to the security domain information in the instruction.
The method according to any one of claims 1 to 5, wherein the configuring of the security domain according to the acquired security domain information comprises:

mapping the security domain identifier to a discovery resource if the security domain discoverability attribute value characterizes discoverability.
A security domain discovery method, comprising:

acquiring discovery resources of IoT (Internet of things) equipment in a network;

obtaining a security domain identifier from the discovery resource;

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

wherein the IoT device has configured security domain information, the security domain information comprising at least: a security domain identifier, a security domain name, and security domain discoverability.
The method of claim 7, wherein determining the security domain corresponding to the security domain identifier in the network 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, judging that one security domain exists in the network;

and when the security domain identifiers are different, judging that a plurality of security domains exist in the network.
The method of claim 7 or 8, wherein after acquiring the security domain identifier from the discovery resource, further comprising:

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

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

receiving the security domain name fed back by the IoT device.
The method of claim 9 or 10, wherein after obtaining the security domain name corresponding to the security domain identifier from the IoT device according to the security domain identifier, the method further comprises:

when judging that one security domain exists in the network, representing the security domain by using the security domain name;

when it is determined that a plurality of security domains exist in a network and have different security domain names, representing the plurality of security domains by respective security domain names;

when it is determined that a plurality of security domains exist in a network and have the same security domain name, the plurality of security domains are represented by the security domain identifier and the corresponding security domain name.
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:

feeding back discovery resources in response to a received request message for performing resource discovery;

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 at least comprises: 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 characterizing the security domain discoverability is discoverable.
A security domain joining method, 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 of claims 7 to 11;

according to the security domain selected by the user, starting an instance of the security domain.
The method of claim 13, wherein the initiating, according to the security domain selected by the user, an instance of the security domain comprises:

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

if there is no instance of the security domain selected by the user in the configured instance of security domains, an instance of the security domain available for the user selection is generated.
A security domain configuration apparatus, comprising:

the acquisition module is used for acquiring security domain information;

the configuration module is used for configuring a security domain according to the acquired security domain information;

wherein the security domain information at least comprises: a security domain identifier, a security domain name, and security domain discoverability.
The apparatus of claim 15, wherein the obtaining means 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.
The apparatus of claim 16, wherein the means for obtaining is further configured to:

and when the random number is automatically generated as the security domain identifier, generating the random number according to the self authentication root certificate, and using the random number as the security domain identifier.
The apparatus of any of claims 15 to 17, wherein 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.
The apparatus of claim 15, wherein the means for obtaining is further configured to: receiving an instruction carrying the security domain information;

the configuration module is further to: and configuring a security domain according to the security domain information in the instruction.
The apparatus of any of claims 15 to 19, wherein the configuration module is further configured to: mapping the security domain identifier to a discovery resource when an attribute value of the security domain discoverability characterizes discoverability.
A security domain discovery apparatus, comprising:

the first acquisition module is used for acquiring discovery resources of the IoT equipment in the 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;

wherein the IoT device has configured security domain information, the security domain information comprising at least: a security domain identifier, a security domain name, and security domain discoverability.
The apparatus of claim 21, wherein the means for determining comprises:

a comparison submodule, configured to compare the security domain identifiers when the security domain identifiers are acquired from at least two IoT devices;

the judgment submodule is used for judging that one security domain exists in the network when the security domain identifiers are the same; and when the security domain identifiers are different, judging that a plurality of security domains exist in the network.
The apparatus of claim 21 or 22, wherein the apparatus further comprises:

a third obtaining module, configured to obtain, according to the security domain identifier obtained by the second obtaining module, a security domain name corresponding to the security domain identifier from the IoT device.
The apparatus of claim 23, wherein the third obtaining means comprises: a sending submodule, configured to send, to the IoT device, a request message for obtaining the security domain name corresponding to the security domain identifier;

a receiving submodule, configured to receive the security domain name fed back by the IoT device.
The apparatus of claim 23 or 24, wherein the means for determining further comprises:

a representation submodule for:

when judging that one security domain exists in the network, representing the security domain by using the security domain name;

when it is determined that a plurality of security domains exist in a network and have different security domain names, representing the plurality of security domains by respective security domain names;

when it is determined that a plurality of security domains exist in a network and have the same security domain name, the plurality of security domains are represented by the security domain identifier and the corresponding security domain name.
A security domain discovery apparatus, configured with security domain information by the security domain configuration method of any one of claims 1 to 6, comprising:

a first feedback module, configured to feed back discovery resources in response to a received request message for performing resource discovery;

the second feedback module is used for 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 at least comprises: 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 characterizing the security domain discoverability is discoverable.
A security domain joining apparatus, 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 of claims 7 to 11;

and the starting module is used for starting the instance of the security domain according to the security domain selected by the user.
The apparatus of claim 27, wherein the means for initiating is further for:

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

generating an instance of the security domain available for the user selection when there is no instance of the security domain selected by the user in the configured instance of the security domain.
An electronic device, comprising: a processor and a memory for storing a computer program, the processor being configured to invoke and execute the computer program stored in the memory to perform the method of any of claims 1 to 14.
A chip, comprising: a processor for calling and running a computer program from a memory so that a device on which the chip is installed performs the method of any one of claims 1 to 14.
A computer-readable storage medium for storing a computer program which causes a computer to perform the method of any one of claims 1 to 14.
A computer program product comprising computer program instructions for causing a computer to perform the method of any one of claims 1 to 14.
A computer program, characterized in that the computer program causes a computer to perform the method according to any of claims 1 to 14.