WO2024016124A1

WO2024016124A1 - Device configuration methods and apparatuses, and communication device

Info

Publication number: WO2024016124A1
Application number: PCT/CN2022/106311
Authority: WO
Inventors: 茹昭; 吕小强; 包永明; 张军; 杨宁
Original assignee: Oppo广东移动通信有限公司
Priority date: 2022-07-18
Filing date: 2022-07-18
Publication date: 2024-01-25

Abstract

Provided in the embodiments of the present application are a device configuration method and apparatus, and a communication device. The method comprises: a first device acquiring a first certificate and/or a first credential from a server; and the first device configuring a first application in a second device with the first certificate and/or the first credential, wherein the first certificate is used by the first application to establish a secure connection with the server, and the first credential is used by the first application to register to the server.

Description

Equipment configuration method and device, communication equipment

Technical field

The embodiments of this application relate to the technical field of the Internet of Things, and specifically relate to a device configuration method and device, and communication equipment.

Background technique

When a device wants to access the cloud platform, the device needs to use a preset certificate to access the cloud platform. This method of accessing the cloud platform requires that the device and the cloud platform belong to the same application platform. The device needs to preset a certificate belonging to the same application platform as the cloud platform in advance. Only in this way can the device use the preset certificate to access the cloud platform. .

However, if the device and the cloud platform do not belong to the same application platform, the device cannot access the cloud platform. It can be seen that the current solution cannot enable devices to connect to the cloud platform across application platforms.

Contents of the invention

Embodiments of the present application provide an equipment configuration method and device, communication equipment, chips, computer-readable storage media, computer program products, and computer programs.

The device configuration method provided by the embodiment of this application includes:

The first device obtains the first certificate and/or the first voucher from the server;

The first device configures the first certificate and/or the first credential to the first application in the second device; wherein the first certificate is used to establish security between the first application and the server. connection, the first credential is used for the first application to register with the server.

The first application of the second device obtains the first certificate and/or the first credential configured by the first device, the first certificate and/or the first credential being obtained by the first device from the server;

The first application establishes a secure connection with the server based on the first certificate and/or registers with the server based on the first credential.

The server generates a first certificate and/or a first credential, and sends the first certificate and/or a first credential to the first device; wherein the first certificate and/or the first credential are configured by the first device to The first application in the second device; wherein the first certificate is used for the first application to establish a secure connection with the server, and the first credential is used for the first application to register with the server.

The device configuration device provided by the embodiment of the present application is applied to the first device, and the device includes:

An acquisition unit, used to acquire the first certificate and/or the first credential from the server;

A configuration unit configured to configure the first certificate and/or the first credential to the first application in the second device; wherein the first certificate is used to establish security between the first application and the server. connection, the first credential is used for the first application to register with the server.

The device configuration device provided by the embodiment of the present application is applied to the second device, and the device includes:

An acquisition unit, configured to acquire a first certificate and/or a first credential configured by the first device, the first certificate and/or a first credential being obtained by the first device from the server;

An access unit configured to establish a secure connection with the server based on the first certificate and/or register with the server based on the first certificate.

The device configuration device provided by the embodiment of this application is applied to the server, and the device includes:

A generating unit, used to generate the first certificate and/or the first voucher;

a communication unit configured for the first device to send the first certificate and/or the first voucher; wherein the first certificate and/or the first voucher are configured by the first device to the first application in the second device ; Wherein, the first certificate is used for the first application to establish a secure connection with the server, and the first credential is used for the first application to register with the server.

The communication device provided by the embodiment of the present application includes a processor and a memory. The memory is used to store computer programs, and the processor is used to call and run the computer programs stored in the memory to execute the above device configuration method.

The chip provided by the embodiment of this application is used to implement the above device configuration method.

Specifically, the chip includes: a processor, configured to call and run a computer program from a memory, so that the device installed with the chip executes the above device configuration method.

The computer-readable storage medium provided by the embodiment of the present application is used to store a computer program. The computer program causes the computer to execute the above device configuration method.

The computer program product provided by the embodiment of the present application includes computer program instructions, which cause the computer to execute the above device configuration method.

The computer program provided by the embodiment of the present application, when run on a computer, causes the computer to execute the above device configuration method.

Through the above technical solution, the first device applies for the first certificate and/or the first credential from the server for the first application in the second device, and configures the applied first certificate and/or first credential to the first application in the second device. The first application, in this way, the first application in the second device can use the first certificate to establish a secure connection with the server and/or use the first credential to register with the server, thereby achieving access to the server. Since the first certificate and/or the first credential are issued by the server to the second device, the first application of the second device uses the first certificate and/or the first credential to access the server and does not require the second device It needs to belong to the same application platform as the server. That is to say, when the second device and the server do not belong to the same application platform, the technical solutions of the embodiments of the present application can be used to enable the second device to access the server and realize the cross-application platform of the device. Access the server.

Description of drawings

The drawings described here are used to provide a further understanding of the present application and constitute a part of the present application. The illustrative embodiments of the present application and their descriptions are used to explain the present application and do not constitute an improper limitation of the present application. In the attached picture:

Figure 1 is a schematic diagram of communication between devices provided by an embodiment of the present application;

Figure 2 is a schematic diagram of a communication architecture provided by an embodiment of the present application;

Figure 3 is a flow chart for a device to access the cloud platform;

Figure 4 is a schematic flowchart 1 of the device configuration method provided by the embodiment of the present application;

Figure 5 is a schematic flow chart 2 of the device configuration method provided by the embodiment of the present application;

Figure 6 is a flowchart three of the device configuration method provided by the embodiment of the present application;

Figure 7 is a schematic flowchart 4 of the device configuration method provided by the embodiment of the present application;

Figure 8 is a schematic structural diagram of the equipment configuration device provided by the embodiment of the present application;

Figure 9 is a schematic diagram 2 of the structural composition of the equipment configuration device provided by the embodiment of the present application;

Figure 10 is a schematic diagram 3 of the structural composition of the equipment configuration device provided by the embodiment of the present application;

Figure 11 is a schematic structural diagram of a communication device provided by an embodiment of the present application;

Figure 12 is a schematic structural diagram of a chip according to an embodiment of the present application.

Detailed ways

In order to facilitate understanding of the technical solutions of the embodiments of the present application, the relevant technologies of the embodiments of the present application are described below. The following related technologies can be optionally combined with the technical solutions of the embodiments of the present application, and they all belong to the embodiments of the present application. protected range.

The business interaction between the client and the server is realized by performing Representational State Transfer (RESTful) operations on resources. RESTful operations can be Create-Read-Update-Delete-Notify (Create-Retrieve-Update-Delete- Notify, CRUDN) operation. Obviously, the CRUDN operation can be any one or more of the following operations: Create (Create), Read (Retrieve), Update (Update), Delete (Delete), Notify (Notify). The client is the initiator of RESTful operations, and the server is the responder of RESTful operations. The client sends a resource operation request to the server, requesting operations on resources on the server. The server performs resource operations and returns a response to the client. , the response carries the content and description information of the resource. It should be noted that the client and server are logical functional entities, and a device can be a client, a server, or both a client and a server.

Figure 1 is a schematic diagram of communication between devices provided by an embodiment of the present application. As shown in Figure 1, device 1 serves as a client and device 2 serves as a server. At the resource model layer, the interaction between the client and the server is implemented through CRUDN operations. At the transport protocol layer, the interaction between device 1 and device 2 is implemented through request messages or response messages. Between the resource model layer and the transport protocol layer, by mapping CRUDN operations to specific transport protocols, CRUDN operations are transformed into entity messages that are transmitted between devices, providing means for interconnection between devices. Among them, the transmission protocol uses Constrained Application Protocol (CoAP) to carry CRUDN operations, and each CRUDN operation is mapped to a CoAP request message or response message.

Figure 2 is a schematic diagram of a communication architecture provided by an embodiment of the present application. As shown in Figure 2, the communication architecture includes device 1, device 2 and an Internet of Things (IoT) cloud platform (hereinafter, the IoT cloud platform will be referred to as cloud for short). platform). Among them, device 1 serves as the server, device 2 serves as the client, and the interaction between device 1 and device 2 is realized through the cloud platform. The cloud platform includes the following three entities:

Cloud interface: The cloud interface is the anchor point on the cloud platform and is responsible for the access management of devices (such as device 1 and device 2), as well as message routing for remote communication between devices (such as between device 1 and device 2); cloud interface Provide an address to the outside world, that is, the address of the cloud platform. As an example: the address of the cloud platform can be a Uniform Resource Locator (URL).

Authorization server: The authorization server is responsible for the registration and authentication of devices (such as device 1 and device 2).

Resource directory: The resource directory includes the resource index of the server; the client can obtain the resources of the server by searching the resource directory.

It should be noted that the authorization server can be implemented as an entity in the cloud platform, or as a separate entity independent of the cloud platform.

Before interaction between device 1 and device 2 can be achieved through the cloud platform, device 1 and device 2 need to access the cloud platform. Figure 3 is a flow chart for device access to the cloud platform, as shown in Figure 3, including the following steps:

Step 301: The user applies to the authorization server to create the user's cloud platform account through the configurator in device 2, and the authorization server returns access token (Access Token) 1 to the configurator.

Here, the user can select the create account option in the configurator in device 2, enter the username and password, and configure the user's username and password in the configurator. In addition, the address of the cloud platform is also configured in the configurator. In this way, the configurator can send the user's username and password to the authorization server based on the address of the cloud platform, so that the authorization server can authenticate the user. After the authorization server authenticates the user, it generates access token 1 for the user based on the user's user name and password, and sends the access token 1 to the configurator.

Step 302: The configurator uses access token 1 to register with the cloud platform.

Here, the configurator provides access token 1 to the cloud platform. After the cloud platform verifies that access token 1 is passed, it allocates a user ID (User ID) to the configurator. This user ID is used to identify the user corresponding to the configurator.

Here, when the same user uses different configurators, the authorization server will provide different access tokens, but any configurator used by the same user corresponds to the same user ID.

Step 303: The configurator configures the cloud configuration resources in device 1.

Here, the configurator connects to device 1 through the device discovery process and then requests access token 2 for device 1 from the cloud platform. The configurator configures access token 2, the address of the cloud platform, and the identity of the cloud platform into the cloud configuration resource in device 1. As an example: the cloud configuration resource in device 1 could be the "oic.r.coapcloudconf" resource.

Step 304: Device 1 uses the preset certificate to establish a secure connection with the cloud platform.

Here, device 1 establishes a physical connection (that is, the underlying connection) with the cloud platform based on the address of the cloud platform and the identity of the cloud platform; device 1 uses a preset certificate to perform mutual authentication with the cloud platform based on the physical connection. After the authentication is completed, the device 1 and the cloud platform obtain each other's public keys, and then generate a shared key based on their own private key and the other party's public key, thereby completing the establishment of a secure connection.

As an example: a secure connection can be a Transport Layer Security (TLS) connection.

Step 305: Device 1 uses access token 2 to register with the cloud platform based on a secure connection, and publishes the resources of device 1 to the cloud platform.

Here, device 1 sends an update operation request to the account resource on the cloud platform. The update operation request includes the access token 2 of device 1. In addition, it may also include the device identification (Device ID) of device 1. The cloud platform maintains a unique instance of account resources for each device. For example, the instance corresponding to device 1 includes access token 2 (for example, A0001), the device identification of device 1 (for example, 0xA71CE), and the user identification corresponding to device 1 (for example, is u001).

As an example: the account resource on the cloud platform can be the "/oic/sec/account" resource.

Here, after device 1 is registered to the cloud platform, it needs to log in to the cloud platform to publish the resources of device 1 to the cloud platform. Device 1 can log in to the cloud platform in the following ways: Device 1 sends an update operation request to the session resource on the cloud platform. After the cloud platform successfully verifies the update operation request, Device 1 logs in to the cloud platform.

As an example: the session resource on the cloud platform can be the "/oic/sec/session" resource.

After device 1 logs in to the cloud platform, it exposes the resources it carries in the resource directory of the cloud platform, so that other devices (such as device 2) can remotely access these resources.

When device 2 performs a CRUDN operation on a resource referenced by a resource index (such as a resource link) in the resource directory of the cloud platform, the cloud platform forwards the CRUDN operation request to device 1, which actually carries the resource, and device 1 sends the request to the cloud platform. CRUDN operation response, the cloud platform then forwards the CRUDN operation response to device 2, that is, the communication path between device 2 and device 1 is: device 2 → cloud platform → device 1 → cloud platform → device 2.

The above process is explained with device 1 as the server. Of course, when device 1 serves as the client, device 1 can also be registered to the cloud platform through the above process.

It should be noted that if the authorization server is implemented as a separate entity independent of the cloud platform, after the cloud platform authenticates device 1, the cloud platform shares the authentication result of device 1 with the authorization server.

In the above process, if device 1 wants to access the cloud platform, device 1 needs to use a preset certificate to establish a secure connection with the cloud platform (ie, step 304 above). This method of accessing the cloud platform requires that device 1 and the cloud platform belong to the same application platform. In this way, device 1 can use the preset certificate to access the cloud platform. However, when device 1 and the cloud platform do not belong to the same application platform, device 1 cannot access the cloud platform. It can be seen that the current solution cannot enable devices to connect to the cloud platform across application platforms. To this end, the following technical solutions of the embodiments of the present application are proposed.

In order to facilitate understanding of the technical solutions of the embodiments of the present application, the technical solutions of the present application are described in detail below through specific embodiments. The above related technologies can be arbitrarily combined with the technical solutions of the embodiments of the present application as optional solutions, and they all fall within the protection scope of the embodiments of the present application. The embodiments of this application include at least part of the following contents.

In the embodiment of this application, the description of the server can also be replaced by a cloud platform, and the cloud platform can also be referred to as a cloud for short.

In this embodiment of the present application, the first device has a configurator, and the first device can configure other devices (such as a second device) to access the server through the configurator, and the first device with the configurator serves as a client. The description of "first device" can also be replaced by "configuration device". This application does not limit the name of the first device. As an example: the first device may be a terminal device such as a mobile phone or a tablet computer. The first device and the server belong to the same application platform. As an example: both the first device and the server belong to the application platform developed by manufacturer A.

In the embodiment of this application, the second device has a first application, and the second device can control some Internet of Things (IoT) devices that belong to the same application platform as itself through the first application. The second device has the first application. The device acts as a client. As an example: the second device may be an IoT device, such as a car. The second device and the server belong to different application platforms. As an example: the server belongs to the application platform developed by manufacturer A, and the second device belongs to the application platform developed by manufacturer B. After the first device configures the first application of the second device to access the server through its configurator, the second device can control another part of IoT devices belonging to the same application platform as the first device through its first application. As an example: the first application in the second device may be a smart home application (SmartHome APP). This application does not limit the name of the first application in the second device.

In the embodiment of this application, from the perspective of bottom-level communication, the communication between the first device and the second device refers to the communication between the communication module of the first device and the communication module of the second device. The communication module can be a Bluetooth module or a Bluetooth module. WiFi module etc. In terms of application layer communication, the communication between the first device and the second device refers to the communication between the configurator of the first device and the first application of the second device. Here, both the configurator and the first application belong to the application. (APP) category, where the configurator of the first device can be a system application of the first device or a third-party application, and the first application of the second device can be a system application of the second device or a third-party application. application. The configurator of the first device and the first application of the second device respectively call respective communication modules to implement communication with each other. Before the first device communicates with the second device, the first device needs to establish a connection with the second device. Here, establishing a connection between the first device and the second device means that the communication module of the first device establishes a connection with the communication module of the second device. . The configurator of the first device may also be described as a second application relative to the first application of the second device.

It should be noted that the interaction between the first device and the first application of the second device described in the following embodiments refers to the interaction between the configurator of the first device and the first application of the second device.

It should be noted that although the technical solution of the embodiment of the present application is explained with the first device configuring the first application access server in the second device (that is, the second device serves as the client), when the second device serves as the service In the case of the terminal, the technical solutions of the embodiments of the present application can also enable the first device to configure the second device to access the server.

Figure 4 is a schematic flow chart of a device configuration method provided by an embodiment of the present application. As shown in Figure 4, the device configuration method includes the following steps:

Step 401: The server generates a first certificate and/or a first voucher, and sends the first certificate and/or a first voucher to the first device; the first device obtains the first certificate and/or the first voucher from the server.

In some implementations, the first application of the second device generates a second certificate request (Certificate Signing Request, CSR) message and sends the second certificate request message to the first device; the first device receives the second certificate sent by the first application request message, the first device determines the first certificate request message based on the second certificate request message. Here, the first device may directly use the second certificate request message as the first certificate request message, or may modify the second certificate request message. (For example, adding relevant information of the first device) thereby generating a first certificate request message; the first device sends a first certificate request message and/or a certificate application message to the server, where the first certificate request message is used to request the server to be the first The application generates the first certificate, and the certificate application message is used to apply to the server to allocate the first certificate to the first application; the server receives the first certificate request message and/or the certificate application message sent by the first device, and the server generates the first certificate and/or The first certificate sends the first certificate and/or the first voucher to the first device; the first device receives the first certificate and/or the first voucher sent by the server. Here, the first certificate and/or the first credential are carried in the CSR response (CSRResponse) message, that is, the server provides the first certificate and/or the first credential to the first device through the CSR response message.

Here, after receiving the second certificate request message sent by the first application of the second device, the first device may determine that the first application of the second device wants to access the server. Considering that the prerequisites for the first application of the second device to access the server are: Condition 1: The first application establishes a secure connection with the server; Condition 2: The first application registers with the server. To this end, for condition 1, the first device needs to apply for a certificate (i.e., first certificate) from the server for the first application, so that the first application can establish a secure connection with the server based on the certificate; for condition 2, the first device needs to The first application applies for a certificate (ie, the first certificate) from the server, so that the first application can register with the server based on the certificate.

Before the first device interacts with the first application in the second device, the first device and the second device need to establish a connection first, and the first application in the second device needs to be started.

In some implementations, the first device and the second device may establish a connection through Bluetooth or WiFi.

In some implementations, the method of starting the first application in the second device may be, but is not limited to, the following methods:

Method 1: The first device sends a startup instruction to the second device, and the startup instruction is used to trigger the second device to start the first application; the second device receives the startup instruction sent by the first device, and starts the first application when triggered by the startup instruction.

As an example: the startup instruction can be a CSR startup instruction.

Optionally, before the first device sends the startup instruction to the second device, the first device outputs first prompt information, and the first prompt information is used to prompt the user whether to agree to launch the first application; the first device obtains user input for the first application. After confirming the prompt message, a start command is sent to the second device.

Optionally, before the first device sends the startup instruction to the second device, the first device determines that the second device supports the ability to control the IoT device. Here, the first device can query the capabilities of the second device and determine that the second device supports the capability of controlling the IoT device. Alternatively, the second device reports its own capabilities (ie, the ability to support controlling IoT devices) to the first device, so that the first device determines that the second device supports the ability to control IoT devices. It should be noted that the "ability to control IoT devices" is supported by the first application in the second device, and the "ability to control IoT devices" can also be called the first application capability, such as smart home application capabilities.

Method 2: The second device starts the first application based on the obtained startup operation.

Optionally, after the second device starts the first application based on the obtained startup operation, the first application of the second device determines that the first device supports the ability to configure the IoT device, and outputs the second prompt information, and the second prompt information is used to prompt the user Whether to connect the IoT device configured by the first device; after obtaining the confirmation operation for the second prompt information input by the user, the first application performs the step of sending a second certificate request message to the first device. It should be noted that the "ability to configure IoT devices" is supported by the configurator in the first device, and the "ability to configure IoT devices" can also be called configurator capabilities.

In some implementations, after the first application in the second device is started, the first application generates a key pair, that is, a public key and a private key pair, for subsequent use.

In some implementations, the first certificate request message and the second certificate request message (hereinafter collectively referred to as the certificate request message) in the above solution conform to the CSR data format defined by PKCS#10 and follow the following principles: the certificate request message carries the certificate request information and the first signature, the first signature is obtained by signing the certificate request information based on the private key of the first application; where,

The certificate request information includes version information, subject information and public key information. The version information includes a version number of the certificate request information. The subject information includes feature information of the second device. The public key information includes the public key of the first application. .

Here, the characteristic information of the second device includes at least one of the following: a manufacturer identification (Vendor ID) of the second device, a product identification (Product ID) of the second device, a device serial number (Device Serial Number or Device ID) of the second device. ).

Here, the public key of the first application is used by the server to verify the first signature, and after the signature verification is successful, the first certificate is generated for the first application. Specifically, after receiving the first certificate request message, the server obtains the public key of the first application based on the first certificate request information (that is, obtains the public key of the first application from the certificate request information in the first certificate request message), based on The public key of the first application verifies the first signature, and after the signature verification is successful, the step of generating the first certificate is performed.

In the embodiment of this application, the server generates the first certificate based on the public key of the first application; or, the server generates the first certificate based on the public key of the first application and the first application identifier, and the first application identifier is the identifier of the first application.

Here, the first application identification is generated by the server, or the first application identification is generated by the first device.

As an implementation manner, the first application identifier is generated by the server. Specifically, after receiving the first certificate request message sent by the first device, the server generates the first application identification for the first application.

As another implementation manner, the first application identifier is generated by the first device. Specifically, after receiving the second certificate request message sent by the first application, the first device generates a first application identification for the first application, and the first device sends the generated first application identification to the server; the server receives the first application identification generated by the first device. The first application identifier.

In this embodiment of the present application, after receiving the certificate application message, the server generates the first certificate for the first application.

As an implementation manner, the server allocates a first access token to the first application as the first credential. Here, the first credential is a first access token, and the first access token is allocated by the server for the first application.

As another implementation manner, the server allocates a first access token to the first application, and encrypts the first access token based on the public key of the first application to obtain a first encryption token as the first certificate. Here, the first credential is a first encryption token. The first encryption token is obtained by the server encrypting the first access token based on the public key of the first application. The first access token is allocated by the server to the first application.

In some embodiments, after the server generates the first access token for the first application, the server establishes a first binding relationship between the first user identification, the first access token and the first application identification, and the first user identification is The user ID corresponding to the first device,

The first application identifier is the identifier of the first application; wherein the first binding relationship is used by the server to determine whether to accept registration and/or login of the first application. Here, the first user identification is assigned by the server to the first device when the first device registers with the server. When the first device interacts with the server, the first device will provide the application identification (called application identification) corresponding to the first device to the server. is the second application identifier, which can be understood as the identifier of the configurator in the first device), and the server can determine the user identifier corresponding to the first device based on the application identifier corresponding to the first device.

It should be noted that the certificate application message and the first certificate request message in the above solution may be the same message, or they may be two different messages. When the certificate application message and the first certificate request message are the same message, they may be collectively referred to as the certificate request message. The certificate request message is used to request the server to generate a first certificate for the first application and/or allocate a first certificate to the first application. certificate.

Step 402: The first device configures the first certificate and/or the first credential to the first application in the second device, and the first application of the second device obtains the first certificate and/or the first credential configured by the first device.

In this embodiment of the present application, the first device sends a configuration command to the first application in the second device, and the configuration command carries the first certificate and/or the first credential; after receiving the configuration command, the first application sends the configuration command carried in the configuration command. The first certificate and/or the first credential are configured locally. In some implementations, the configuration command may be an AddCloudRequest command.

In some implementations, the first device configures the address of the server to the first application in the second device; wherein the address of the server is used for the first application to establish a physical connection with the server, and the first certificate is used to establish a third application based on the physical connection. A secure connection between an application and the server. As an example, the secure connection may be a TLS connection. As an example: the address of the server can be a URL or a URI.

Here, optionally, the first device can also configure the server's identity to the first application in the second device; wherein the server's address and server's identity are used for the first application to establish a physical connection with the server.

In some implementations, when the first device does not obtain the first credential from the server, the first device configures the second application identification to the first application; the second application identification is the application identification corresponding to the first device, and the second application The identification is used for the first application to register with the server. Here, the second application identifier is assigned by the server to the first device when the first device registers with the server.

Here, the reasons why the first device does not obtain the first credential from the server may be: 1. The first device does not apply to the server to allocate the first credential to the first application; 2. The server is incapable of allocating the first credential to the first application; 3. , the server allocated the first credential to the first application, but failed to successfully deliver it to the first device.

Step 403: The first application establishes a secure connection with the server based on the first certificate and/or registers with the server based on the first credential.

In the embodiment of this application, after obtaining the first certificate, the first application establishes a secure connection with the server based on the first certificate.

In some implementations, the first application exchanges respective certificates with the server. After the certificate is authenticated by the certificate receiving end, the certificate receiving end obtains the public key of the certificate sending end and generates a share based on the private key of the certificate receiving end and the public key of the certificate sending end. key to complete the establishment of a secure connection; wherein the certificate of the first application is the first certificate.

Specifically, the first application sends the first certificate to the server. Since the first certificate is generated based on the public key of the first application, after the server obtains the first certificate and authenticates the first certificate, it can obtain the first certificate from the first certificate. Obtain the public key of the first application. Similarly, the server will also send its own certificate (hereinafter referred to as the second certificate) to the first application. Since the second certificate is generated based on the server's public key, the first application obtains the second certificate and authenticates the second certificate. After passing, the server's public key can be obtained from the second certificate. For the first application, the first application uses its own private key and the public key of the server to generate a first shared key, and uses the first shared key to encrypt the data sent to the server and to encrypt the data received from the server. Data is decrypted. Similarly, for the server, the server uses its own private key and the public key of the first application to generate a second shared key, and uses the second shared key to encrypt the data sent to the first application and to encrypt the data received from the first application. The first application data is decrypted.

In some embodiments, before the first application interacts with the server for respective certificates, the first application obtains the address of the server configured by the first device; the first application establishes a physical connection with the server based on the address of the server, and interacts with the server based on the physical connection. respective certificates.

In this embodiment of the present application, after the first application establishes a secure connection with the server, it can safely interact with the server based on the secure connection. For example, the first application can initiate registration and/or login to the server based on a secure connection, or in other words, the data interacted with the server when the first application registers and/or logs in to the server is encrypted by a shared key.

In this embodiment of the present application, after obtaining the first credential, the first application registers with the server based on the first credential.

As an implementation manner, when the first credential is a first access token, the first application uses the first access token to register with the server.

As another implementation manner, when the first credential is the first encryption token, the first application decrypts the first encryption token based on the private key of the first application to obtain the first access token, and the first application uses The first access token is registered to the server.

In some implementations, the first application also obtains a first application identity, and the first application can register with the server using the first application identity and the first credential. Here, when the first certificate is generated by the server based on the public key of the first application and the first application identification, the first application obtains the first application identification based on the first certificate. Specifically, the server receives a registration request message sent by the first application, and the registration request message carries the first application identifier and the first access token; the server determines the first application identifier, the first access token, and the first binding relationship based on the first application identifier, the first access token, and the first binding relationship. The user ID corresponding to an application is the first user ID, and the registration of the first application is accepted.

Further, in some implementations, after the first application uses the first application identification and the first access token to register with the server, the first application uses the first application identification and the first access token to log in to the server. Specifically, the server receives a login request message sent by the first application, and the login request message carries the first application identifier and the first access token; the server determines the first application identifier based on the first application identifier, the first access token, and the first binding relationship. The user ID corresponding to the application is the first user ID, and the login of the first application is accepted.

Further, in some embodiments, after the first application uses the first application identification and the first access token to register with the server, the first application receives the second access token sent by the server and uses the first application identification and the second access token. Log in to the server. Specifically, the server generates a second access token and updates the first access token in the first binding relationship to the second access token; the server sends the second access token to the first application; the server receives the second access token sent by the first application. The login request message carries the first application identification and the second access token; the server determines that the user identification corresponding to the first application is the first user based on the first application identification, the second access token and the first binding relationship. Identifies the first application to accept login.

In some embodiments, when the first application of the second device does not obtain the first credential configured by the first device, the first application obtains the second application identification configured by the first device, and the second application identification corresponds to the first device. The application identifier (that is, the identifier of the configurator of the second device); the first application registers with the server based on the second application identifier.

In some implementations, the first application also obtains a first application identification, and the first application can register with the server using the first application identification and the second application identification. Here, when the first certificate is generated by the server based on the public key of the first application and the first application identification, the first application obtains the first application identification based on the first certificate. Specifically, the server receives a registration request message sent by the first application. The registration request message carries a first application identifier and a second application identifier; the first application identifier is the identifier of the first application; the second application identifier is the application corresponding to the first device. The identification is provided by the first device to the first application; the server determines the first user identification corresponding to the second application identification and accepts the registration of the first application.

Further, in some embodiments, after the first application registers with the server using the first application identifier and the second application identifier, the server generates a second access token and sends the second access token to the first application; the first application receives the server Send the second access token to log in to the server using the first application ID and the second access token.

In some embodiments, after the server generates the second access token for the first application, the server establishes a second binding relationship between the first user identification, the second access token and the first application identification, and the first application identification is The identification of the first application; wherein the second binding relationship is used by the server to determine whether to accept the login of the first application. Specifically, the server receives a login request message sent by the first application, and the login request message carries the first application identifier and the second access token; the server determines the first application identifier based on the first application identifier, the second access token, and the second binding relationship. The user identification corresponding to the application is the first user identification, and the login of the first application is authorized.

Through the above solution, the first device can be configured to configure the first application access server of the second device. When the first application of the second device accesses the server, the second device can control some IoT devices belonging to the same application platform as the first device through its first application.

In the above solution, IoT devices can be, but are not limited to, smart home devices.

The technical solutions of the embodiments of the present application are illustrated below with reference to specific application examples. In the following application examples, the first device is a mobile phone as an example, the second device is a car as an example, the first application in the second device is a smart home application as an example, and the server implements a cloud platform as an example. It should be noted that the car as the second device refers to the vehicle-mounted terminal.

Application example one

Figure 5 is a flow diagram 2 of the device configuration method provided by the embodiment of the present application. As shown in Figure 5, the device configuration method includes the following steps:

Step 501: The car establishes a connection with the mobile phone, and the mobile phone obtains the car's ability to support smart home applications.

Here, the car and the mobile phone can be connected through Bluetooth or WiFi.

Here, the mobile phone can query the car's capabilities and discover that the car supports smart home application capabilities. Or, the car reports its smart home application capabilities to the mobile phone. Here, smart home application capabilities refer to the capabilities supported by smart home applications, that is, the ability to support the control of smart home devices.

Step 502: The user confirms using the car to control the smart home device on the mobile phone.

Here, a dialogue interface pops up on the phone, prompting the user whether he agrees to use the car to control smart home devices.

Step 503: The mobile phone sends a start command to the car, triggering the car to start the smart home application.

Here, after the mobile phone obtains the user's confirmation operation of using the car to control the smart home device, it sends a start command to the car, triggering the car to start the smart home application.

Step 504: After the car's smart home application is started, a key pair is generated.

Here, the key pair refers to the public key and private key pair. Smart home applications store their own private keys in secure areas.

Step 505: The car's smart home application generates a CSR message and sends the CSR message to the mobile phone.

Here, the CSR message conforms to the CSR data format defined by PKCS#10 and follows the following principles: the CSR message carries certificate request information and the first signature, and the first signature is based on the private key of the smart home application (that is, the private key generated in step 504) The certificate request information is obtained by signing; among them, the certificate request information includes version information, subject information and public key information. The version information includes the version number of the certificate request information. The subject information includes the car’s characteristic information and the public key information. The information includes the public key of the smart home application (ie, the public key generated in step 504). Optionally, the subject information includes at least one of the following vehicle characteristic information: the vehicle's manufacturer identification (Vendor ID), the vehicle's product identification (Product ID), and the vehicle's device serial number (Device Serial Number or Device ID).

Step 506: The mobile phone forwards the CSR message to the cloud platform and applies for an access token (Access Token) for the smart home application to register with the cloud platform.

Step 507: The cloud platform assigns an application identification (APPID) to the smart home application, and uses the application identification and the public key of the smart home application to generate a certificate for the smart home application, and generates an access token for the smart home application, and uses the public key of the smart home application. Encrypt the access token to get the encryption token (CToken).

Here, in step 506, the mobile phone may also assign an application identification (APPID) to the smart home application and send the application identification to the cloud platform.

Here, after the cloud platform obtains the CSR message, it will verify the CSR message, and execute step 507 after the verification passes. The way the cloud platform verifies the CSR message is: the cloud platform obtains the public key of the smart home application from the certificate request information in the CSR message, and uses the public key of the smart home application to verify the first signature. If the verification is successful, it means Verification passed.

Step 508: The cloud platform establishes the binding relationship between the user ID (userID), the application ID (APPID) and the access token (AccessToken).

Step 509: The cloud platform returns the certificate and encryption token of the smart home application to the mobile phone.

Here, the parameters returned by the cloud platform to the mobile phone are shown in Table 1 below, including: encryption token (CToken), certificate chain (CertChain), and token validity period (TokenExpiration). Among them, the certificate chain includes at least level 2 certificates. For example, the certificate chain includes a root certificate and a target certificate. The target certificate is the certificate of the smart home application, and the target certificate is signed by the root certificate. For example, the certificate chain includes a root certificate, one or more intermediate certificates, and a target certificate. The target certificate is the certificate of the smart home application. The target certificate is signed by one or more intermediate certificates, and the intermediate certificate is signed by the root certificate. In the certificate-based authentication process, each level of the certificate in the certificate chain needs to be authenticated. After the authentication is passed, it can be determined that the identity of the certificate owner is legal.

Table 1

Step 510: The mobile phone configures the certificate and encryption token of the smart home application, and the address of the cloud platform to the smart home application.

Here, the mobile phone configures the certificate and encryption token of the smart home application, and the address of the cloud platform to the smart home application through configuration instructions. The configuration parameters carried by the configuration instructions are shown in Table 2 below, including: Smart Home Application Certificate (SmartHomeAPPCert) , intermediate certificate (IntermediateCert), root certificate (RootCert), cloud platform address (CloudAddress), encryption token (CToken), and token validity period (TokenExpiration). Among them, SmartHomeAPPCert, IntermediateCert and RootCert form the certificate chain (CertChain).

Table 2

Step 511: The car's smart home application uses the private key to decrypt the encrypted token, obtain the access token, and complete the configuration.

Step 512: The car's smart home application establishes a physical connection with the cloud platform based on the configured address of the cloud platform, and uses the configured certificate to establish a secure connection with the cloud platform based on the physical connection.

Step 513: The car's smart home application is registered to the cloud platform using the application ID and access token based on the secure connection.

Optionally, the cloud platform returns a new access token to the car's smart home application.

Here, the cloud platform will propose a registration interface. The description of the registration interface is shown in Table 3 below. The HTTP Method used by the registration interface is POST, and the interface access address corresponding to the registration interface is "/account".

HTTP方法HTTP method	接口访问地址Interface access address
POSTPOST	/account/account

table 3

The parameters involved in the registration interface of the cloud platform include registration request interface parameters and registration response interface parameters. Among them, the description of the registration request interface parameters is shown in Table 4 below. The registration request interface parameters are located in the body (Body) of the POST request message, including the access token (AccessToken) and the application identification (APPID). The description of the registration response interface parameters is shown in Table 5 below. The registration response interface parameters are located in the Body of the POST response message, including the access token (AccessToken) and the token validity period (TokenExpiration).

位置Location	参数parameter	值类型value type	必填Required	说明illustrate
BodyBody	AccessTokenAccessToken	字符串string	是yes	智能家居应用的访问令牌Access token for smart home applications
BodyBody	APPIDAPPID	字符串string	是yes	智能家居应用的应用标识Application ID for smart home applications

Table 4

table 5

Step 514: The car's smart home application uses the application identification and access token (use a new access token if there is a new access token) to log in to the cloud platform.

Here, after the Che's smart home application logs into the cloud platform, the user can use the Che's smart home application to control the smart home devices connected to the cloud platform through the cloud platform.

Application example two

Figure 6 is a schematic flowchart three of the device configuration method provided by the embodiment of the present application. As shown in Figure 6, the device configuration method includes the following steps:

Step 601: The car establishes a connection with the mobile phone.

Here, the car and the mobile phone can be connected through Bluetooth or WiFi.

Step 602: The user starts the smart home application in the car.

Step 603: The car's smart home application discovers the configurator capability of the mobile phone, displays a prompt message on its interface, and uses the prompt message to prompt the user whether to connect to the smart home device registered to the cloud platform.

Step 604: The user enters a confirmation connection operation on the interface of the car's smart home application.

Step 605: The car's smart home application generates a key pair.

Step 606: The car's smart home application generates a CSR message and sends the CSR message to the mobile phone.

Here, the CSR message conforms to the CSR data format defined by PKCS#10 and follows the following principles: the CSR message carries the certificate request information and the first signature, and the first signature is based on the private key of the smart home application (that is, the private key generated in step 604) The certificate request information is obtained by signing; among them, the certificate request information includes version information, subject information and public key information. The version information includes the version number of the certificate request information. The subject information includes the car’s characteristic information and the public key information. The information includes the public key of the smart home application (ie, the public key generated in step 604). Optionally, the subject information includes at least one of the following vehicle characteristic information: the vehicle's manufacturer identification (Vendor ID), the vehicle's product identification (Product ID), and the vehicle's device serial number (Device Serial Number or Device ID).

Step 607: The user confirms using the car to control the smart home device on the mobile phone.

Step 608: The mobile phone forwards the CSR message to the cloud platform and applies for an access token (Access Token) for the smart home application to register with the cloud platform.

Here, after the mobile phone obtains the confirmation operation of the user's consent to use the car to control the smart home device, it forwards the CSR message to the cloud platform and applies for an access token (Access Token) for the smart home application to register with the cloud platform.

Step 609: The cloud platform assigns an application identification (APPID) to the smart home application, and uses the application identification and the public key of the smart home application to generate a certificate for the smart home application, and generates an access token for the smart home application, and uses the public key of the smart home application. Encrypt the access token to get the encryption token (CToken).

Here, in step 608, the mobile phone may also assign an application identification (APPID) to the smart home application and send the application identification to the cloud platform.

Here, after the cloud platform obtains the CSR message, it will verify the CSR message, and execute step 609 after the verification passes. The way the cloud platform verifies the CSR message is: the cloud platform obtains the public key of the smart home application from the certificate request information in the CSR message, and uses the public key of the smart home application to verify the first signature. If the verification is successful, it means Verification passed.

Step 610: The cloud platform establishes the binding relationship between the user ID (userID), the application ID (APPID) and the access token (AccessToken).

Step 611: The cloud platform returns the certificate and encryption token of the smart home application to the mobile phone.

Here, the parameters returned by the cloud platform to the mobile phone are shown in Table 1 above, including: encryption token (CToken), certificate chain (CertChain), and token validity period (TokenExpiration).

Step 612: The mobile phone configures the certificate and encryption token of the smart home application, and the address of the cloud platform to the smart home application.

Here, the mobile phone configures the certificate and encryption token of the smart home application, and the address of the cloud platform to the smart home application through configuration instructions. The configuration parameters carried by the configuration instructions are shown in Table 2 above, including: Smart Home Application Certificate (SmartHomeAPPCert) , intermediate certificate (IntermediateCert), root certificate (RootCert), cloud platform address (CloudAddress), encryption token (CToken), and token validity period (TokenExpiration). Among them, SmartHomeAPPCert, IntermediateCert and RootCert form the certificate chain (CertChain).

Step 613: The car's smart home application uses the private key to decrypt the encrypted token, obtain the access token, and complete the configuration.

Step 614: The car's smart home application establishes a physical connection with the cloud platform based on the configured address of the cloud platform, and uses the configured certificate to establish a secure connection with the cloud platform based on the physical connection.

Step 615: The car's smart home application is registered to the cloud platform using the application identification and access token based on the secure connection.

Here, the cloud platform will propose a registration interface. The description of the registration interface is shown in Table 3 above. The HTTP method used by the registration interface is POST, and the interface access address corresponding to the registration interface is "/account".

The parameters involved in the registration interface of the cloud platform include registration request interface parameters and registration response interface parameters. Among them, the description of the registration request interface parameters is shown in Table 4 above. The registration request interface parameters are located in the body (Body) of the POST request message, including the access token (AccessToken) and the application identification (APPID). The description of the registration response interface parameters is shown in Table 5 above. The registration response interface parameters are located in the Body of the POST response message, including the access token (AccessToken) and the token validity period (TokenExpiration).

Step 616: The car's smart home application uses the application identification and access token (use a new access token if there is a new access token) to log in to the cloud platform.

Application example three

Figure 7 is a schematic flow chart 4 of a device configuration method provided by an embodiment of the present application. As shown in Figure 7, the device configuration method includes the following steps:

Step 701: The car establishes a connection with the mobile phone, and the mobile phone obtains the car's ability to support smart home applications.

Here, the car and the mobile phone can be connected through Bluetooth or WiFi.

Step 702: The user confirms using the car to control the smart home device on the mobile phone.

Step 703: The mobile phone sends a start command to the car, triggering the car to start the smart home application.

Step 704: After the car's smart home application is started, a key pair is generated.

Step 705: The car's smart home application generates a CSR message and sends the CSR message to the mobile phone.

Here, the CSR message conforms to the CSR data format defined by PKCS#10 and follows the following principles: the CSR message carries certificate request information and the first signature, and the first signature is based on the private key of the smart home application (that is, the private key generated in step 704) The certificate request information is obtained by signing; among them, the certificate request information includes version information, subject information and public key information. The version information includes the version number of the certificate request information. The subject information includes the car’s characteristic information and the public key information. The information includes the public key of the smart home application (ie, the public key generated in step 704). Optionally, the subject information includes at least one of the following vehicle characteristic information: the vehicle's manufacturer identification (Vendor ID), the vehicle's product identification (Product ID), and the vehicle's device serial number (Device Serial Number or Device ID).

Step 706: The mobile phone forwards the CSR message to the cloud platform.

Step 707: The cloud platform assigns application identification 1 (APPID1) to the smart home application, and uses application identification 1 and the public key of the smart home application to generate a certificate for the smart home application.

Here, in step 706, the mobile phone may also allocate application identification 1 (clientID1) to the smart home application, and send the application identification 1 to the cloud platform.

Here, after the cloud platform obtains the CSR message, it will verify the CSR message, and execute step 707 after the verification passes. The way the cloud platform verifies the CSR message is: the cloud platform obtains the public key of the smart home application from the certificate request information in the CSR message, and uses the public key of the smart home application to verify the first signature. If the verification is successful, it means Verification passed.

Step 708: The cloud platform returns the certificate of the smart home application to the mobile phone.

Here, the parameters returned by the cloud platform to the mobile phone are shown in Table 6 below, including: Certificate Chain (CertChain). Among them, the certificate chain includes at least level 2 certificates. For example, the certificate chain includes a root certificate and a target certificate. The target certificate is the certificate of the smart home application, and the target certificate is signed by the root certificate. For example, the certificate chain includes a root certificate, one or more intermediate certificates, and a target certificate. The target certificate is the certificate of the smart home application. The target certificate is signed by one or more intermediate certificates, and the intermediate certificate is signed by the root certificate. In the certificate-based authentication process, each level of the certificate in the certificate chain needs to be authenticated. After the authentication is passed, it can be determined that the identity of the certificate owner is legal.

Table 6

Step 709: The mobile phone configures the certificate of the smart home application, the application identification 2 (APPID2) of the mobile phone, and the address of the cloud platform to the smart home application.

Here, the mobile phone configures the certificate of the smart home application, the application identification 2 of the mobile phone, and the address of the cloud platform to the smart home application through the configuration command. The configuration parameters carried by the configuration command are shown in Table 7 below, including: smart home application certificate ( SmartHomeAPPCert), intermediate certificate (IntermediateCert), root certificate (RootCert), cloud platform address (CloudAddress), application identification 2 (APPID2). Among them, SmartHomeAPPCert, IntermediateCert and RootCert form the certificate chain (CertChain).

Table 7

Step 710: The car's smart home application establishes a physical connection with the cloud platform based on the configured address of the cloud platform, and uses the configured certificate to establish a secure connection with the cloud platform based on the physical connection.

Step 711: The car's smart home application is registered to the cloud platform using application identification 1 and the mobile phone's application identification 2 based on a secure connection.

The parameters involved in the registration interface of the cloud platform include registration request interface parameters and registration response interface parameters. The description of the registration request interface parameters is shown in Table 8 below. The registration request interface parameters are located in the body (Body) of the POST request message, including application identification 2 (APPID2) and application identification 1 (APPID1). The description of the registration response interface parameters is shown in Table 9 below. The registration response interface parameters are located in the header (Header) and Body in the POST response message. The header includes the content type (Content-Type), and the body includes the access token (AccessToken) and token. Validity duration (TokenExpiration).

位置Location	参数parameter	值类型value type	必填Required	说明illustrate
BodyBody	APPID2APPID2	字符串string	是yes	手机的配置器的应用标识The application ID of the phone's configurator
BodyBody	APPID1APPID1	字符串string	是yes	智能家居应用的应用标识Application ID for smart home applications

Table 8

Table 9

Step 712: The cloud platform finds the corresponding user ID (userID) based on the mobile phone's application ID 2, and allocates an access token to the car's smart home application.

Step 713: The cloud platform establishes the binding relationship between user ID (userID), application ID 1 (APPID1) and access token (AccessToken).

Step 714: The cloud platform issues an access token to the car's smart home application.

Step 715: The car's smart home application uses the application identification 1 and the access token to log in to the cloud platform.

The preferred embodiments of the present application have been described in detail above with reference to the accompanying drawings. However, the present application is not limited to the specific details of the above-mentioned embodiments. Within the scope of the technical concept of the present application, various simple modifications can be made to the technical solutions of the present application. These simple modifications all belong to the protection scope of this application. For example, each of the specific technical features described in the above-mentioned specific embodiments can be combined in any suitable manner without conflict. In order to avoid unnecessary repetition, this application will no longer describe various possible combinations. Specify otherwise. As another example, any combination of various embodiments of the present application can be carried out. As long as they do not violate the idea of the present application, they should also be regarded as the contents disclosed in the present application. For another example, on the premise of no conflict, the various embodiments described in this application and/or the technical features in each embodiment can be arbitrarily combined with the existing technology, and the technical solution obtained after the combination shall also fall within the scope of this application. protected range.

It should also be understood that in the various method embodiments of the present application, the size of the sequence numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its functions and internal logic, and should not be used in this application. The implementation of the examples does not constitute any limitations.

Figure 8 is a schematic structural diagram of a device configuration device provided by an embodiment of the present application. It is applied to the first device. As shown in Figure 8, it includes:

Obtaining unit 801, used to obtain the first certificate and/or first voucher from the server;

Configuration unit 802, configured to configure the first certificate and/or the first credential to the first application in the second device; wherein the first certificate is used for the first application to establish a relationship with the server. Secure connection, the first credential is used for the first application to register with the server.

In some implementations, the device further includes: a communication unit 803; the obtaining unit 801 obtains the first certificate and/or the first voucher through the communication unit 803. The communication unit 803 is used to send a first certificate request message and/or a credential application message to the server. The first certificate request message is used to request the server to generate a first certificate for the first application. The credential application message is used to apply to the server for the first application. The application allocates the first credential; receives the first certificate and/or the first credential sent by the server.

In some implementations, the communication unit 803 is also configured to receive a second certificate request message sent by the first application. The second certificate request message is generated by the first application, and the first certificate request message is based on the second certificate request. The news is confirmed.

In some embodiments, the first certificate request message carries certificate request information and a first signature, and/or the second certificate request message carries certificate request information and a first signature; the first signature is based on the private key of the first application Obtained by signing the certificate request information; the certificate request information includes version information, subject information and public key information, the version information includes the version number of the certificate request information, the subject information includes feature information of the second device, and the public key information includes the first application public key.

In some implementations, the characteristic information of the second device includes at least one of the following: a manufacturer identification of the second device, a product identification of the second device, and a device serial number of the second device.

In some implementations, the public key of the first application is used by the server to verify the first signature, and after the signature verification is successful, the first certificate is generated for the first application.

In some embodiments, the first certificate is generated by the server based on the public key of the first application; or the first certificate is generated by the server based on the public key of the first application and the first application identifier, and the first application identifier is the first application's public key. logo.

In some implementations, the first application identification is generated by the server for the first application after receiving the first certificate request message sent by the first device.

In some implementations, the first application identification is generated by the first device for the first application after receiving the second certificate request message sent by the first application. The communication unit 803 is also configured to send the generated first application identification to server.

In some implementations, the first credential is a first access token, and the first access token is allocated by the server for the first application; or the first credential is a first encryption token, and the first encryption token is allocated by the server based on the first application. The first access token is obtained by encrypting the public key of an application, and the first access token is allocated by the server to the first application.

In some embodiments, when the first device does not obtain the first credential from the server, the configuration unit 802 is also configured to configure the second application identifier to the first application; the second application identifier is the application identifier corresponding to the first device. , the second application identifier is used for the first application to register with the server.

In some embodiments, the configuration unit 802 is also used to configure the address of the server to the first application in the second device; wherein the address of the server is used for the first application to establish a physical connection with the server, and the first certificate is used for establishing a physical connection with the server based on The physical connection establishes a secure connection between the first application and the server.

In some implementations, the communication unit 803 is also used to send a startup instruction to the second device, and the startup instruction is used to trigger the second device to start the first application.

In some embodiments, the device further includes: a human-computer interaction unit configured to output first prompt information, the first prompt information being used to prompt the user whether to agree to launch the first application; after obtaining user input for the first prompt information After the confirmation operation, a start command is sent to the second device.

In some implementations, the apparatus further includes: a determining unit configured to determine that the second device supports the ability to control the IoT device.

In some implementations, before the first device receives the certificate request message sent by the first application, the second device starts the first application based on the obtained startup operation.

In some implementations, the first device and the server belong to the same application platform, and the second device and the server belong to different application platforms.

Persons skilled in the art should understand that the relevant description of the above device configuration apparatus in the embodiment of the present application can be understood with reference to the relevant description of the device configuration method in the embodiment of the present application.

Figure 9 is a schematic diagram 2 of the structural composition of a device configuration device provided by an embodiment of the present application. It is applied to the second device (specifically, the first application of the second device). As shown in Figure 9, it includes:

Obtaining unit 901, configured to obtain the first certificate and/or the first credential configured by the first device, the first certificate and/or the first credential being obtained by the first device from the server;

Access unit 902, configured to establish a secure connection with the server based on the first certificate and/or register with the server based on the first certificate.

In some implementations, the apparatus further includes: a generating unit 903 and a communication unit 904; the generating unit 903 is used to generate a second certificate request message; the communication unit 904 is used to send the second certificate request message to the first device; The second certificate request message is used by the first device to determine the first certificate request message. The first certificate request message is forwarded by the first device to the server and used to request the server to generate a first certificate for the first application.

In some embodiments, the first certificate request message carries certificate request information and the first signature, and/or the second certificate request message carries the certificate request information and the first signature; the first signature is based on the private key pair certificate of the first application The request information is obtained by signing; the certificate request information includes version information, subject information and public key information. The version information includes the version number of the certificate request information. The subject information includes the characteristic information of the second device. The public key information includes the public key of the first application. .

In some implementations, the first application identifier is generated by the first device for the first application after receiving the second certificate request message sent by the first application, and is sent by the first device to the server.

In some embodiments, the access unit 902 is used to exchange respective certificates with the server. After the certificate is authenticated by the certificate receiving end, the certificate receiving end obtains the public key of the certificate sending end and based on the private key of the certificate receiving end and the certificate sending end. The public key generates a shared key to complete the establishment of a secure connection; the certificate of the first application is the first certificate.

In some embodiments, the obtaining unit 901 is also used to obtain the address of the server configured by the first device; the access unit 902 is used to establish a physical connection with the server based on the address of the server, and exchange respective certificates with the server based on the physical connection. .

In some embodiments, when the first certificate is generated by the server based on the public key of the first application and the first application identification, the obtaining unit 901 is further configured to obtain the first application identification based on the first certificate, and the first application identification is Register the first application to the server.

In some implementations, the access unit 902 is used to register with the server using the first access token when the first credential is a first access token; or, when the first credential is a first encryption token , decrypt the first encryption token based on the private key of the first application to obtain the first access token, and use the first access token to register with the server.

In some implementations, the access unit 902 is configured to register with the server using a first application identification and a first access token, and the first application identification is obtained based on the first certificate.

In some embodiments, the access unit 902 is used to log in to the server using the first application identification and the first access token; or, to receive the second access token sent by the server and use the first application identification and the second access token. Log in to the server.

In some embodiments, the obtaining unit 901 is also used to obtain the second application identification of the first device configuration when the first credential configured by the first device is not obtained. The second application identification is the application identification corresponding to the first device. ; Access unit 902, configured to register with the server based on the second application identification.

In some implementations, the access unit 902 is configured to register with the server using a first application identification and a second application identification, and the first application identification is obtained based on the first certificate.

In some implementations, the communication unit 904 is used to receive the second access token sent by the server; the access unit 902 is used to log in to the server using the first application identification and the second access token.

In some embodiments, the startup unit is configured to receive a startup instruction sent by the first device, start the first application when triggered by the startup instruction, or start the first application based on the obtained startup operation.

In some embodiments, the device further includes: a human-computer interaction unit, used to determine the ability of the first device to support the configuration of the IoT device, and to output second prompt information. The second prompt information is used to prompt the user whether to connect to the first device to configure the device. IoT device; after obtaining the confirmation operation input by the user for the second prompt information, trigger the communication unit 904 to perform the step of sending a certificate request message to the first device.

In some implementations, the first device and the server belong to different application platforms, and the first device and the server belong to the same application platform.

Figure 10 is a schematic diagram 3 of the structure of a device configuration device provided by an embodiment of the present application. It is applied to a server. As shown in Figure 10, it includes:

Generating unit 1001, used to generate a first certificate and/or a first voucher;

The communication unit 1002 is configured to send the first certificate and/or first voucher; wherein the first certificate and/or first voucher are configured by the first device to the first application in the second device; wherein , the first certificate is used for the first application to establish a secure connection with the server, and the first credential is used for the first application to register with the server.

In some implementations, the communication unit 1002 is also configured to receive a first certificate request message and/or a certificate application message sent by the first device. The first certificate request message is used to request the server to generate a first certificate for the first application. The certificate The application message is used to apply to the server to allocate the first credential to the first application.

In some embodiments, the first certificate request message carries certificate request information and a first signature. The first signature is obtained by signing the certificate request information based on the private key of the first application; the certificate request information includes version information, subject information and public key. information, the version information includes the version number of the certificate request information, the subject information includes the characteristic information of the second device, and the public key information includes the public key of the first application.

In some embodiments, the device further includes: a verification unit 1003, configured to obtain the public key of the first application based on the first certificate request information, verify the first signature based on the public key of the first application, and verify After the signature is successful, the generation unit 1001 is triggered to execute the step of generating the first certificate.

In some implementations, the generating unit 1001 is configured to generate a first certificate based on the public key of the first application; or, generate the first certificate based on the public key of the first application and the first application identifier, and the first application identifier is the first The identification of the application.

In some implementations, the generating unit 1001 is further configured to generate a first application identifier for the first application after receiving the first certificate request message sent by the first device.

In some embodiments, the first application identification is generated by the first device for the first application after receiving the second certificate request message sent by the first application. The communication unit 1002 is also configured to receive the first application generated by the first device. logo.

In some implementations, the generating unit 1001 is configured to allocate a first access token to the first application as the first credential; or to allocate the first access token to the first application based on the public key of the first application. An access token is encrypted to obtain the first encrypted token, which serves as the first credential.

In some implementations, the apparatus further includes: an establishing unit, configured to establish a first binding relationship between the first user identification, the first access token and the first application identification, and the first user identification is the first device. The corresponding user identification, the first application identification is the identification of the first application; wherein, the first binding relationship is used by the server to determine whether to accept the registration and/or login of the first application.

In some implementations, the communication unit 1002 is also configured to receive a registration request message sent by the first application, where the registration request message carries the first application identifier and the first access token; the verification unit 1003 is also configured to based on the first application identifier , the first access token and the first binding relationship, determine the user identification corresponding to the first application as the first user identification, and accept the registration of the first application.

In some implementations, the communication unit 1002 is also configured to receive a login request message sent by the first application, where the login request message carries the first application identifier and the first access token; the verification unit 1003 is also configured to based on the first application identifier , the first access token and the first binding relationship determine that the user identification corresponding to the first application is the first user identification, and accept the login of the first application.

In some implementations, the generation unit 1001 is also configured to generate a second access token and update the first access token in the first binding relationship to the second access token; the communication unit 1002 is also configured to provide the first access token to the second access token. An application sends a second access token; receives a login request message sent by the first application, the login request message carries the first application identifier and the second access token; the verification unit 1003 is also used to based on the first application identifier, the second access token The token and the first binding relationship determine that the user identification corresponding to the first application is the first user identification, and the login of the first application is accepted.

In some implementations, the communication unit 1002 is also configured to receive a registration request message sent by the first application. The registration request message carries the first application identifier and the second application identifier; the first application identifier is the identifier of the first application; The application identification is an application identification corresponding to the first device, and is provided by the first device to the first application; the verification unit 1003 is also configured to determine the first user identification corresponding to the second application identification based on the second application identification, and accept the registration of the first application.

In some implementations, the generation unit 1001 is also used to generate a second access token; the communication unit 1002 is also used to send the second access token to the first application; the second access token is used for the first application to log in to server.

In some embodiments, the establishment unit is also configured to establish a second binding relationship between the first user identification, the second access token and the first application identification, where the first application identification is the identification of the first application; wherein, The second binding relationship is used by the server to determine whether to accept the login of the first application.

In some implementations, the communication unit 1002 is also configured to receive a login request message sent by the first application, where the login request message carries the first application identifier and the second access token; the verification unit 1003 is also configured to based on the first application identifier , the second access token and the second binding relationship determine that the user identification corresponding to the first application is the first user identification, and authorize the login of the first application.

In some implementations, the server and the first device belong to the same application platform, and the server and the second device belong to different application platforms.

Figure 11 is a schematic structural diagram of a communication device 1100 provided by an embodiment of the present application. The communication device can be a first device or a second device or a server. The communication device 1100 shown in Figure 11 includes a processor 1110. The processor 1110 can call and run a computer program from the memory to implement the method in the embodiment of the present application. .

Optionally, as shown in Figure 11, the communication device 1100 may further include a memory 1120. The processor 1110 can call and run the computer program from the memory 1120 to implement the method in the embodiment of the present application.

The memory 1120 may be a separate device independent of the processor 1110, or may be integrated into the processor 1110.

Optionally, as shown in Figure 11, the communication device 1100 may also include a transceiver 1130. The processor 1110 may control the transceiver 1130 to communicate with other devices. Specifically, it may send information or data to other devices, or receive other devices. Information or data sent by the device.

Among them, the transceiver 1130 may include a transmitter and a receiver. The transceiver 1130 may further include an antenna, and the number of antennas may be one or more.

Optionally, the communication device 1100 may specifically be the first device in the embodiment of the present application, and the communication device 1100 may implement the corresponding processes implemented by the first device in the various methods of the embodiment of the present application. For the sake of brevity, they are not mentioned here. Again.

Optionally, the communication device 1100 may specifically be the second device in the embodiment of the present application, and the communication device 1100 may implement the corresponding processes implemented by the second device in the various methods of the embodiment of the present application. For the sake of brevity, they are not mentioned here. Again.

Optionally, the communication device 1100 can be specifically a server in the embodiment of the present application, and the communication device 1100 can implement the corresponding processes implemented by the server in the various methods of the embodiment of the present application. For the sake of brevity, details will not be repeated here.

Figure 12 is a schematic structural diagram of a chip according to an embodiment of the present application. The chip 1200 shown in Figure 12 includes a processor 1210. The processor 1210 can call and run a computer program from the memory to implement the method in the embodiment of the present application.

Optionally, as shown in Figure 12, the chip 1200 may also include a memory 1220. The processor 1210 can call and run the computer program from the memory 1220 to implement the method in the embodiment of the present application.

The memory 1220 may be a separate device independent of the processor 1210, or may be integrated into the processor 1210.

Optionally, the chip 1200 may also include an input interface 1230. The processor 1210 can control the input interface 1230 to communicate with other devices or chips. Specifically, it can obtain information or data sent by other devices or chips.

Optionally, the chip 1200 may also include an output interface 1240. The processor 1210 can control the output interface 1240 to communicate with other devices or chips. Specifically, it can output information or data to other devices or chips.

Optionally, the chip can be applied to the first device in the embodiment of the present application, and the chip can implement the corresponding processes implemented by the first device in the various methods of the embodiment of the present application. For the sake of brevity, the details will not be described again.

Optionally, the chip can be applied to the second device in the embodiment of the present application, and the chip can implement the corresponding processes implemented by the second device in the various methods of the embodiment of the present application. For the sake of brevity, the details will not be described again.

Optionally, the chip can be applied to the server in the embodiment of the present application, and the chip can implement the corresponding processes implemented by the server in the various methods of the embodiment of the present application. For the sake of brevity, the details will not be described again.

It should be understood that the chips mentioned in the embodiments of this application may also be called system-on-chip, system-on-a-chip, system-on-chip or system-on-chip, etc.

It should be understood that the processor in the embodiment of the present application may be an integrated circuit chip and has signal processing capabilities. During the implementation process, each step of the above method embodiment can be completed through an integrated logic circuit of hardware in the processor or instructions in the form of software. The above-mentioned processor can be a general-purpose processor, a digital signal processor (Digital Signal Processor, DSP), an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), an off-the-shelf programmable gate array (Field Programmable Gate Array, FPGA) or other available processors. Programmed logic devices, discrete gate or transistor logic devices, discrete hardware components. Each method, step, and logical block diagram disclosed in the embodiments of this application can be implemented or executed. A general-purpose processor may be a microprocessor or the processor may be any conventional processor, etc. The steps of the method disclosed in conjunction with the embodiments of the present application can be directly implemented by a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software module can be located in random access memory, flash memory, read-only memory, programmable read-only memory or electrically erasable programmable memory, registers and other mature storage media in this field. The storage medium is located in the memory, and the processor reads the information in the memory and completes the steps of the above method in combination with its hardware.

It can be understood that the memory in the embodiment of the present application may be a volatile memory or a non-volatile memory, or may include both volatile and non-volatile memories. Among them, non-volatile memory can be read-only memory (Read-Only Memory, ROM), programmable read-only memory (Programmable ROM, PROM), erasable programmable read-only memory (Erasable PROM, EPROM), electrically removable memory. Erase programmable read-only memory (Electrically EPROM, EEPROM) or flash memory. Volatile memory may be Random Access Memory (RAM), which is used as an external cache. By way of illustration, but not limitation, many forms of RAM are available, such as static random access memory (Static RAM, SRAM), dynamic random access memory (Dynamic RAM, DRAM), synchronous dynamic random access memory (Synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (Double Data Rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (Enhanced SDRAM, ESDRAM), synchronous link dynamic random access memory (Synchlink DRAM, SLDRAM) ) and direct memory bus random access memory (Direct Rambus RAM, DR RAM). It should be noted that the memory of the systems and methods described herein is intended to include, but is not limited to, these and any other suitable types of memory.

It should be understood that the above memory is an exemplary but not restrictive description. For example, the memory in the embodiment of the present application can also be a static random access memory (static RAM, SRAM), a dynamic random access memory (dynamic RAM, DRAM), Synchronous dynamic random access memory (synchronous DRAM, SDRAM), double data rate synchronous dynamic random access memory (double data rate SDRAM, DDR SDRAM), enhanced synchronous dynamic random access memory (enhanced SDRAM, ESDRAM), synchronous connection Dynamic random access memory (synch link DRAM, SLDRAM) and direct memory bus random access memory (Direct Rambus RAM, DR RAM) and so on. That is, memories in embodiments of the present application are intended to include, but are not limited to, these and any other suitable types of memories.

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

Optionally, the computer-readable storage medium can be applied to the first device in the embodiment of the present application, and the computer program causes the computer to execute the corresponding processes implemented by the first device in the various methods of the embodiment of the present application. For the sake of simplicity, I won’t go into details here.

Optionally, the computer-readable storage medium can be applied to the second device in the embodiment of the present application, and the computer program causes the computer to execute the corresponding processes implemented by the second device in the various methods of the embodiment of the present application. For the sake of simplicity, I won’t go into details here.

Optionally, the computer-readable storage medium can be applied to the server in the embodiment of the present application, and the computer program causes the computer to execute the corresponding processes implemented by the server in the various methods of the embodiment of the present application. For the sake of brevity, they will not be described here. Repeat.

An embodiment of the present application also provides a computer program product, including computer program instructions.

Optionally, the computer program product can be applied to the first device in the embodiment of the present application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the first device in the various methods of the embodiment of the present application. For simplicity, in This will not be described again.

Optionally, the computer program product can be applied to the second device in the embodiment of the present application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the second device in the various methods of the embodiment of the present application. For simplicity, in This will not be described again.

Optionally, the computer program product can be applied to the server in the embodiment of the present application, and the computer program instructions cause the computer to execute the corresponding processes implemented by the server in the various methods of the embodiment of the present application. For the sake of brevity, they will not be described again here. .

An embodiment of the present application also provides a computer program.

Optionally, the computer program can be applied to the first device in the embodiment of the present application. When the computer program is run on the computer, it causes the computer to execute the corresponding processes implemented by the first device in each method of the embodiment of the present application. For the sake of brevity, no further details will be given here.

Optionally, the computer program can be applied to the second device in the embodiment of the present application. When the computer program is run on the computer, it causes the computer to execute the corresponding processes implemented by the second device in the various methods of the embodiment of the present application. For the sake of brevity, no further details will be given here.

Optionally, the computer program can be applied to the server in the embodiment of the present application. When the computer program is run on the computer, it causes the computer to execute the corresponding processes implemented by the server in the various methods of the embodiment of the present application. For simplicity, in This will not be described again.

Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented with electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Skilled artisans may implement the described functionality using different methods for each specific application, but such implementations should not be considered beyond the scope of this application.

Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working processes of the systems, devices and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be described again here.

In the several embodiments provided in this application, it should be understood that the disclosed systems, devices and methods can be implemented in other ways. For example, the device embodiments described above are only illustrative. For example, the division of the units is only a logical function division. In actual implementation, there may be other division methods. For example, multiple units or components may be combined or can be integrated into another system, or some features can be ignored, or not implemented. On the other hand, the coupling or direct coupling or communication connection between each other shown or discussed may be through some interfaces, and the indirect coupling or communication connection of the devices or units may be in electrical, mechanical or other forms.

The units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place, or they may be distributed to multiple network units. Some or all of the units can be selected according to actual needs to achieve the purpose of the solution of this embodiment.

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

If the functions are implemented in the form of software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the existing technology or the part of the technical solution can be embodied in the form of a software product. The computer software product is stored in a storage medium, including Several instructions are used to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in various embodiments of this application. The aforementioned storage media include: U disk, mobile hard disk, read-only memory (Read-Only Memory,) ROM, random access memory (Random Access Memory, RAM), magnetic disk or optical disk and other media that can store program code. .

The above are only specific embodiments of the present application, but the protection scope of the present application is not limited thereto. Any person familiar with the technical field can easily think of changes or substitutions within the technical scope disclosed in the present application. should be covered by the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

A device configuration method, the method includes:

The first device obtains the first certificate and/or the first voucher from the server;

The first device configures the first certificate and/or the first credential to the first application in the second device; wherein the first certificate is used to establish security between the first application and the server. connection, the first credential is used for the first application to register with the server.
The method according to claim 1, wherein the first device obtains the first certificate and/or the first voucher from the server, including:

The first device sends a first certificate request message and/or a credential application message to the server. The first certificate request message is used to request the server to generate a first certificate for the first application. The credential application message is used to request the server to generate a first certificate for the first application. The server applies to allocate the first credential to the first application;

The first device receives the first certificate and/or the first voucher sent by the server.
The method according to claim 2, wherein before the first device sends the first certificate request message and/or the credential request message to the server, the method further includes:

The first device receives a second certificate request message sent by the first application, the second certificate request message is generated by the first application, and the first certificate request message is determined based on the second certificate request message. .
The method according to claim 3, wherein the first certificate request message carries certificate request information and a first signature, and/or the second certificate request message carries certificate request information and a first signature; A signature is obtained by signing the certificate request information based on the private key of the first application; the certificate request information includes version information, subject information and public key information, and the version information includes the version number of the certificate request information , the subject information includes characteristic information of the second device, and the public key information includes the public key of the first application.
The method of claim 4, wherein the characteristic information of the second device includes at least one of the following: a manufacturer identification of the second device, a product identification of the second device, a device name of the second device serial number.
The method according to claim 4 or 5, wherein the public key of the first application is used by the server to verify the first signature, and after the signature verification is successful, the public key is generated for the first application. Describe the first certificate.
The method according to any one of claims 4 to 6, wherein,

The first certificate is generated by the server based on the public key of the first application; or,

The first certificate is generated by the server based on the public key of the first application and a first application identifier, where the first application identifier is the identifier of the first application.
The method of claim 7, wherein the first application identification is generated by the server for the first application after receiving the first certificate request message sent by the first device.
The method of claim 7, wherein the first application identification is generated by the first device for the first application after receiving the second certificate request message sent by the first application, so The above methods also include:

The first device sends the generated first application identification to the server.
The method according to any one of claims 1 to 9, wherein,

The first credential is a first access token, and the first access token is allocated by the server for the first application; or,

The first credential is a first encryption token. The first encryption token is obtained by encrypting a first access token by the server based on the public key of the first application. The first access token is obtained by The server assigns the first application.
The method according to any one of claims 1 to 9, wherein if the first device does not obtain the first credential from the server, the method further includes:

The first device configures a second application identification to the first application; the second application identification is an application identification corresponding to the first device, and the second application identification is used for the first application to register to the server.
The method according to any one of claims 1 to 11, wherein the method further comprises:

The first device configures the address of the server to the first application in the second device; wherein the address of the server is used for the first application to establish a physical connection with the server, and the first certificate is used for Establishing a secure connection between the first application and the server based on the physical connection.
The method according to claim 3, wherein before the first device receives the certificate request message sent by the first application, the method further includes:

The first device sends a startup instruction to the second device, and the startup instruction is used to trigger the second device to start the first application.
The method of claim 13, wherein:

Before the first device sends a startup instruction to the second device, the method further includes: the first device outputs first prompt information, and the first prompt information is used to prompt the user whether to agree to start the first device. application;

The first device sending a startup instruction to the second device includes: the first device sending a startup instruction to the second device after obtaining a user input confirmation operation for the first prompt information.
The method according to claim 13 or 14, wherein before the first device sends a startup instruction to the second device, the method further includes:

The first device determines that the second device supports the ability to control Internet of Things (IoT) devices.
The method of claim 3, wherein before the first device receives the certificate request message sent by the first application, the second device starts the first application based on the obtained start operation.
The method according to any one of claims 1 to 16, wherein the first device and the server belong to the same application platform, and the second device and the server belong to different application platforms.
A device configuration method, the method includes:

The first application of the second device obtains the first certificate and/or the first credential configured by the first device, the first certificate and/or the first credential being obtained by the first device from the server;

The first application establishes a secure connection with the server based on the first certificate and/or registers with the server based on the first credential.
The method according to claim 18, wherein before the first application of the second device obtains the first certificate and/or the first credential configured by the first device, the method further includes:

The first application generates a second certificate request message and sends the second certificate request message to the first device; the second certificate request message is used by the first device to determine the first certificate request message, and the A first certificate request message is sent by the first device to the server for requesting the server to generate a first certificate for the first application.
The method according to claim 19, wherein the first certificate request message carries certificate request information and a first signature, and/or the second certificate request message carries certificate request information and a first signature; A signature is obtained by signing the certificate request information based on the private key of the first application; the certificate request information includes version information, subject information and public key information, and the version information includes the version number of the certificate request information , the subject information includes characteristic information of the second device, and the public key information includes the public key of the first application.
The method according to claim 20, wherein the characteristic information of the second device includes at least one of the following: a manufacturer identification of the second device, a product identification of the second device, a device name of the second device. serial number.
The method according to claim 20 or 21, wherein the public key of the first application is used by the server to verify the first signature, and after the signature verification is successful, the public key is generated for the first application. Describe the first certificate.
The method according to any one of claims 20 to 22, wherein,

The first certificate is generated by the server based on the public key of the first application; or,

The first certificate is generated by the server based on the public key of the first application and a first application identifier, where the first application identifier is the identifier of the first application.
The method of claim 23, wherein the first application identification is generated by the server for the first application after receiving the first certificate request message sent by the first device.
The method of claim 23, wherein the first application identification is generated by the first device for the first application after receiving the second certificate request message sent by the first application, and Sent by the first device to the server.
The method according to any one of claims 23 to 25, wherein the first application establishes a secure connection with the server based on the first certificate, comprising:

The first application interacts with the server with respective certificates. After the certificate is authenticated by the certificate receiving end, the certificate receiving end obtains the public key of the certificate sending end based on the private key of the certificate receiving end and the certificate. The public key of the sending end generates a shared key to complete the establishment of a secure connection; wherein the certificate of the first application is the first certificate.
The method of claim 26, wherein:

Before the first application and the server interact with respective certificates, the method further includes: the first application obtains the address of the server configured by the first device;

The first application and the server exchange respective certificates, including: the first application establishes a physical connection with the server based on the address of the server, and exchanges respective certificates with the server based on the physical connection.
The method according to any one of claims 23 to 27, wherein when the first certificate is generated by the server based on the public key of the first application and the first application identification, the method further includes :

The first application obtains the first application identification based on the first certificate, and the first application identification is used for the first application to register with the server.
The method according to any one of claims 18 to 28, wherein,

The first credential is a first access token, and the first access token is allocated by the server for the first application; or,

The first credential is a first encryption token. The first encryption token is obtained by encrypting a first access token by the server based on the public key of the first application. The first access token is obtained by The server assigns the first application.
The method of claim 29, wherein the first application registers with the server based on the first credential, comprising:

If the first credential is a first access token, the first application uses the first access token to register with the server; or,

When the first credential is a first encrypted token, the first application decrypts the first encrypted token based on the private key of the first application to obtain the first access token, so The first application uses the first access token to register with the server.
The method of claim 30, wherein the first application registers with the server using the first access token, comprising:

The first application registers with the server using a first application identification and the first access token, the first application identification being obtained based on the first certificate.
The method of claim 31, wherein after the first application registers with the server using the first application identification and the first access token, the method further includes:

The first application uses the first application identification and the first access token to log in to the server; or,

The first application receives the second access token sent by the server, and logs in to the server using the first application identification and the second access token.
The method according to any one of claims 18 to 28, wherein if the first application of the second device does not obtain the first credential configured by the first device, the method further includes:

The first application obtains a second application identifier configured by the first device, and the second application identifier is an application identifier corresponding to the first device;

The first application is registered with the server based on the second application identification.
The method of claim 33, wherein the first application registers with the server based on the second application identification, comprising:

The first application registers with the server using a first application identification and a second application identification, and the first application identification is obtained based on the first certificate.
The method according to claim 34, wherein after the first application is registered with the server using the first application identification and the second application identification, the method further includes:

The first application receives the second access token sent by the server, and logs in to the server using the first application identification and the second access token.
The method according to any one of claims 19 to 28, wherein before sending the certificate request message to the first device, the method further includes:

The second device receives a startup instruction sent by the first device, and starts the first application when triggered by the startup instruction.
The method according to any one of claims 19 to 28, wherein before sending the certificate request message to the first device, the method further includes:

The second device launches the first application based on the obtained launch operation.
The method according to claim 37, wherein after the second device starts the first application based on the obtained startup operation, the method further includes:

The first application of the second device determines that the first device supports the ability to configure an IoT device, and outputs second prompt information. The second prompt information is used to prompt the user whether to connect the IoT device configured by the first device;

After the first application obtains the confirmation operation input by the user for the second prompt information, it performs the step of sending the certificate request message to the first device.
The method according to any one of claims 18 to 38, wherein the first device and the server belong to different application platforms, and the first device and the server belong to the same application platform.
A device configuration method, the method includes:

The server generates a first certificate and/or a first credential, and sends the first certificate and/or a first credential to the first device; wherein the first certificate and/or the first credential are configured by the first device to The first application in the second device; wherein the first certificate is used for the first application to establish a secure connection with the server, and the first credential is used for the first application to register with the server.
The method according to claim 40, wherein before the server generates the first certificate and/or the first voucher, the method further includes:

The server receives a first certificate request message and/or a certificate application message sent by the first device. The first certificate request message is used to request the server to generate a first certificate for the first application. The certificate application message Used to apply to the server to allocate a first credential to the first application.
The method of claim 41, wherein the first certificate request message carries certificate request information and a first signature, and the first signature is obtained by signing the certificate request information based on the private key of the first application. ; The certificate request information includes version information, subject information and public key information. The version information includes the version number of the certificate request information. The subject information includes feature information of the second device. The public key information Contains the public key of the first application.
The method according to claim 42, wherein the characteristic information of the second device includes at least one of the following: a manufacturer identification of the second device, a product identification of the second device, a device name of the second device. serial number.
The method of claim 42 or 43, wherein the method further comprises:

The server obtains the public key of the first application based on the first certificate request information, verifies the first signature based on the public key of the first application, and generates the first signature after the verification is successful. Steps to First Certificate.
The method according to any one of claims 42 to 44, wherein the server generates a first certificate, comprising:

The server generates the first certificate based on the public key of the first application; or,

The server generates the first certificate based on the public key of the first application and a first application identifier, where the first application identifier is the identifier of the first application.
The method of claim 45, wherein the method further includes:

The server generates the first application identifier for the first application after receiving the first certificate request message sent by the first device.
The method of claim 45, wherein the first application identifier is generated by the first device for the first application after receiving a second certificate request message sent by the first application. Also includes:

The server receives the first application identification generated by the first device.
The method according to any one of claims 40 to 47, wherein the server generates a first credential, including:

The server allocates a first access token to the first application as the first credential; or,

The server allocates a first access token to the first application, and encrypts the first access token based on the public key of the first application to obtain a first encryption token as the first certificate.
The method of claim 48, wherein the method further includes:

The server establishes a first binding relationship between a first user identification, the first access token, and a first application identification. The first user identification is the user identification corresponding to the first device, and the third user identification is the user identification corresponding to the first device. An application identifier is the identifier of the first application; wherein the first binding relationship is used by the server to determine whether to accept registration and/or login of the first application.
The method of claim 49, wherein the method further includes:

The server receives a registration request message sent by the first application, where the registration request message carries the first application identifier and the first access token;

The server determines that the user identification corresponding to the first application is the first user identification based on the first application identification, the first access token and the first binding relationship, and accepts the first user identification. Application registration.
The method of claim 50, wherein the method further includes:

The server receives a login request message sent by the first application, where the login request message carries the first application identifier and the first access token;

The server determines that the user identification corresponding to the first application is the first user identification based on the first application identification, the first access token and the first binding relationship, and accepts the first application Login.
The method of claim 50, wherein the method further includes:

The server generates a second access token and updates the first access token in the first binding relationship to the second access token;

The server sends the second access token to the first application;

The server receives a login request message sent by the first application, where the login request message carries the first application identifier and the second access token;

The server determines that the user identification corresponding to the first application is the first user identification based on the first application identification, the second access token and the first binding relationship, and accepts the first application Login.
The method according to any one of claims 40 to 47, wherein when the server does not generate the first credential, the method further includes:

The server receives a registration request message sent by the first application, the registration request message carries a first application identifier and a second application identifier; the first application identifier is the identifier of the first application; the second application identifier The application identifier is an application identifier corresponding to the first device, and is provided by the first device to the first application;

The server determines the first user identification corresponding to the second application identification and accepts the registration of the first application.
The method of claim 53, wherein the method further includes:

The server generates a second access token and sends the second access token to the first application; the second access token is used by the first application to log in to the server.
The method of claim 54, wherein the method further includes:

The server establishes a second binding relationship between the first user identification, the second access token and a first application identification, where the first application identification is an identification of the first application; wherein, The second binding relationship is used by the server to determine whether to accept the login of the first application.
The method of claim 55, wherein the method further includes:

The server receives a login request message sent by the first application, where the login request message carries the first application identifier and the second access token;

The server determines that the user identification corresponding to the first application is the first user identification based on the first application identification, the second access token and the second binding relationship, and authorizes the first application Login.
The method according to any one of claims 40 to 56, wherein the server and the first device belong to the same application platform, and the server and the second device belong to different application platforms.
An equipment configuration device, applied to a first device, the device includes:

An acquisition unit, used to acquire the first certificate and/or the first credential from the server;

A configuration unit configured to configure the first certificate and/or the first credential to the first application in the second device; wherein the first certificate is used to establish security between the first application and the server. connection, the first credential is used for the first application to register with the server.
A device configuration device, applied to a second device, the device includes:

An acquisition unit, configured to acquire a first certificate and/or a first credential configured by the first device, the first certificate and/or a first credential being obtained by the first device from the server;

An access unit configured to establish a secure connection with the server based on the first certificate and/or register with the server based on the first certificate.
A device configuration device, applied to a server, the device includes:

A generating unit, used to generate the first certificate and/or the first voucher;

a communication unit configured for the first device to send the first certificate and/or the first voucher; wherein the first certificate and/or the first voucher are configured by the first device to the first application in the second device ; Wherein, the first certificate is used for the first application to establish a secure connection with the server, and the first credential is used for the first application to register with the server.
A communication device, including: a processor and a memory, the memory is used to store a computer program, the processor is used to call and run the computer program stored in the memory, and execute as described in any one of claims 1 to 17 The method, or the method described in any one of claims 18 to 39, or the method described in any one of claims 40 to 57.
A chip, including: a processor for calling and running a computer program from a memory, so that a device equipped with the chip executes the method according to any one of claims 1 to 17, or claims 18 to 39 The method of any one of claims 40 to 57.
A computer-readable storage medium for storing a computer program, the computer program causing a computer to perform the method according to any one of claims 1 to 17, or the method according to any one of claims 18 to 39 , or the method of any one of claims 40 to 57.
A computer program product comprising computer program instructions that cause a computer to perform the method as claimed in any one of claims 1 to 17, or the method as claimed in any one of claims 18 to 39, or the method as claimed in any one of claims 18 to 39, or The method of any one of claims 40 to 57.
A computer program that causes a computer to perform the method according to any one of claims 1 to 17, or the method according to any one of claims 18 to 39, or any one of claims 40 to 57. method described in one item.