A device and cloud platform communication connection method and system
By using one device, one key, and mTLS two-way authentication, combined with single-device multi-channel connection and message topic modification, the security and data transmission efficiency issues of device-cloud platform connection are solved, and efficient device-cloud platform communication is achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SPIC INTEGRATED SMART ENERGY TECH CO LTD
- Filing Date
- 2023-07-19
- Publication Date
- 2026-06-09
Smart Images

Figure CN116980461B_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of communication technology, specifically to a method and system for communication connection between a device and a cloud platform. Background Technology
[0002] The one-device-one-key authentication method assigns a unique device certificate to each device, which serves as the access credential to the cloud platform. When a device establishes a connection with the platform, it uses the key information issued by the cloud platform for identity authentication. mTLS is a bidirectional transport layer security protocol. The server and client use a bidirectional encrypted channel, and both parties need to verify each other's identity. Only after successful authentication will a secure communication channel be established for data transmission.
[0003] Current one-type-one-key authentication methods involve burning the same product certificate to devices under the same product name. Devices obtain keys through dynamic registration, resulting in generally low security. Authentication methods based on device identifiers such as MAC addresses and serial numbers represent one-way authentication between the platform and the device. Summary of the Invention
[0004] This application aims to address the shortcomings of existing technologies by proposing a method and system for communication connection between a device and a cloud platform. It improves the security of device connection through one-device-one-key and mTLS two-way authentication, and can be expanded through multi-channel connection of a single device. It supports authentication with multiple clientIDs to meet higher data transmission requirements and improve data transmission performance.
[0005] To achieve the above objectives, this application provides the following solution:
[0006] A method for connecting a device to a cloud platform includes the following steps:
[0007] S1. Use the device's connection gateway to read the hardware device ID and load the gateway certificate;
[0008] S2. Enable mTLS authentication. The security gateway verifies the validity of the gateway certificate and reads the AuthID from the gateway certificate.
[0009] S3. After the legitimacy authentication is successful, the ClientID is obtained based on the hardware device ID, and an MQTT protocol connection is established based on the ClientID;
[0010] S4. Based on the ClientID, the hardware device ID is found. The security gateway calls the IoT management platform interface to verify the hardware device ID. After successful verification, the valid AuthID in the cloud platform is extracted.
[0011] S5. The security gateway verifies whether the AuthID and the valid AuthID are consistent. If they are consistent, a formal MQTT connection is established.
[0012] Preferably, the mTLS authentication method includes:
[0013] A two-way encrypted channel is used between the server and the client. The client verifies the server's public key certificate and uploads the client's public key certificate to the server.
[0014] The server verifies the client's public key certificate, and completes the mTLS authentication upon successful verification.
[0015] Preferably, in step S3, if it is a single device and a single channel connection, the single device corresponds to one client, and the hardware device ID is the same as the ClientID.
[0016] Preferably, in step S3, if it is a single device connected to multiple channels, and the single device corresponds to multiple clients, the method for obtaining the ClientID includes: obtaining the channel identifier, and combining the hardware device ID with the channel identifier to obtain the ClientID.
[0017] Preferably, the data transmission method between the device and the cloud platform includes subscribing to message topics;
[0018] By modifying the message topic, different channels will consume the uplink and downlink messages of the device equally.
[0019] Preferably, the message topic is modified in the following way:
[0020] By adding a shared subscription prefix before the original subscription message topic, a shared subscription method is adopted, allowing different channels under the multi-channel structure to poll and consume server messages in a round-robin fashion, ensuring that each channel consumes unique messages.
[0021] This application also provides a device-cloud platform communication connection system, including: an ID extraction module, an authentication module, a modification module, a verification module, and a comparison module;
[0022] The ID extraction module is used to read the hardware device ID using the device's connection gateway and load the gateway certificate;
[0023] The authentication module is used to enable mTLS authentication. The security gateway performs validity authentication on the gateway certificate and reads the AuthID from the gateway certificate.
[0024] The modification module is used to obtain the ClientID based on the hardware device ID after the legitimacy authentication is successful, and to establish an MQTT protocol connection based on the ClientID;
[0025] The verification module is used to look up the hardware device ID based on the ClientID, and use the security gateway to call the IoT management platform interface to verify the hardware device ID. After successful verification, the valid AuthID in the cloud platform is extracted.
[0026] The comparison module is used to verify whether the AuthID and the valid AuthID are consistent using the security gateway. If they are consistent, a formal MQTT connection is established.
[0027] Preferably, the mTLS authentication method includes:
[0028] A two-way encrypted channel is used between the server and the client. The client verifies the server's public key certificate and uploads the client's public key certificate to the server.
[0029] The server verifies the client's public key certificate, and completes the mTLS authentication upon successful verification.
[0030] Preferably, the workflow of the modification module includes: if it is a single device and a single channel connection, the single device corresponds to one client, and the hardware device ID is the same as the ClientID.
[0031] Preferably, the workflow of the modification module further includes: if it is a single device and multiple channels connection, and the single device corresponds to multiple clients, the method for obtaining the ClientID includes: obtaining the channel identifier, and combining the hardware device ID with the channel identifier to obtain the ClientID.
[0032] Compared with the prior art, the beneficial effects of this application are as follows:
[0033] The technical solution of this application improves the security of device connection, and the transmission efficiency is multiplied by the single device multi-channel connection method, which meets the higher data transmission requirements and improves data transmission performance. Attached Figure Description
[0034] To more clearly illustrate the technical solutions of this application, the drawings used in the embodiments are briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0035] Figure 1 This is a schematic diagram of the method flow of Embodiment 1 of this application;
[0036] Figure 2 This is a flowchart of the method in Embodiment 1 of this application;
[0037] Figure 3 This is a schematic diagram of the system structure of Embodiment 2 of this application. Detailed Implementation
[0038] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.
[0039] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments.
[0040] Example 1
[0041] In this first embodiment, as Figure 1 As shown, a method for communication connection between a device and a cloud platform includes the following steps:
[0042] S1. Use the device's connection gateway to read the hardware device ID and load the gateway certificate.
[0043] S2. Enable mTLS authentication. The security gateway verifies the validity of the gateway certificate and reads the AuthID from the gateway certificate. The mTLS authentication method includes: using a two-way encrypted channel between the server and client; the client verifies the server's public key certificate and uploads its own public key certificate to the server; the server verifies the client's public key certificate, and mTLS authentication is completed upon successful verification. SSLv3 is selected for mTLS.
[0044] In this embodiment, a bidirectional encrypted channel is used between the server and the client. Typically, security authentication only requires the client to authenticate the server's certificate. With mTLS, both the server and client need to verify each other's identity. In addition to verifying the server's public key certificate, the client also needs to upload its own public key certificate to the server for verification. Only after both parties have successfully verified each other will a secure communication channel be established for data transmission. In this embodiment, the following versions of mTLS can be selected: SSLv3, TLSv1, TLSv1.1, and TLSv1.2.
[0045] In this embodiment, if authentication fails, the connection fails.
[0046] S3. After successful authentication, obtain the ClientID based on the hardware device ID, and establish an MQTT protocol connection based on the ClientID.
[0047] For a single device and a single channel connection, each device corresponds to one client, and the hardware device ID is the same as the ClientID. For a single device and multiple channels connection, each device corresponds to multiple clients. The methods for obtaining the ClientID include: obtaining the channel identifier, and combining the hardware device ID with the channel identifier to obtain the ClientID.
[0048] In this embodiment, the ClientID for device access in the single-device single-channel scheme is the device ID, i.e., {deviceId}, and the device ID is unique. The single-device multi-channel scheme modifies the ClientID, with the naming convention being {deviceId}-channel-{channelId}, where channelId represents the channel identifier of the device. ClientIDs are dynamically assigned. In the authentication and authorization interfaces, the new ClientID is adapted so that the server can find the correct device ID for subsequent authentication steps. When a single device uses multiple channels for connection, there are multiple clients, but from the cloud platform's perspective, it is only one device. Therefore, multiple online connections are equivalent to a single online connection. When the device goes offline, the cloud platform confirms its offline status based on the number of established channels. Each time the device establishes a connection through a new channel, the channel count is incremented; each time the device goes offline, the channel count is decremented. When the channel count reaches 0, the device is considered officially offline.
[0049] Data transmission between devices and the cloud platform requires subscription to message topics. This embodiment further modifies the message topics so that different channels evenly distribute the consumption of uplink and downlink messages from the device. Increasing the number of channels from one to two doubles the data transmission efficiency, thus reducing transmission pressure and meeting the needs of large data volume transmission. The message topic modification method involves adding a shared subscription prefix before the original subscribed message topic, thereby adopting a shared subscription approach. This allows different channels under multiple channels to poll and consume server messages in a round-robin fashion, ensuring that each channel consumes unique messages.
[0050] S4. Based on the ClientID, the hardware device ID is located. The security gateway calls the IoT management platform interface to verify the hardware device ID. If the verification is successful, the valid AuthID in the cloud platform is extracted. In this embodiment, if the verification fails, the connection fails.
[0051] S5. The security gateway verifies whether the AuthID and the valid AuthID match. If they match, a formal MQTT connection is established. In this embodiment, if the verification fails, the connection fails.
[0052] The detailed process of the method in this embodiment is as follows: Figure 2 As shown.
[0053] Example 2
[0054] In this second embodiment, as Figure 3 As shown, a device-to-cloud platform communication connection system includes: an ID extraction module, an authentication module, a modification module, a verification module, and a comparison module.
[0055] The ID extraction module is used to read the hardware device ID using the device's connection gateway and load the gateway certificate.
[0056] The authentication module enables mTLS authentication. The security gateway verifies the validity of the gateway certificate and reads the AuthID from it. The mTLS authentication method includes: using a two-way encrypted channel between the server and client; the client verifying the server's public key certificate and uploading its own public key certificate to the server; and the server verifying the client's public key certificate. Upon successful verification, mTLS authentication is complete. The mTLS version selected is SSLv3.
[0057] In this embodiment, a bidirectional encrypted channel is used between the server and the client. Typically, security authentication only requires the client to authenticate the server's certificate. With mTLS, both the server and client need to verify each other's identity. In addition to verifying the server's public key certificate, the client also needs to upload its own public key certificate to the server for verification. Only after both parties have successfully verified each other will a secure communication channel be established for data transmission. In this embodiment, the following versions of mTLS can be selected: SSLv3, TLSv1, TLSv1.1, and TLSv1.2.
[0058] In this embodiment, if authentication fails, the connection fails.
[0059] The modified module is used to obtain the ClientID based on the hardware device ID after successful authentication, and then establish an MQTT protocol connection based on the ClientID.
[0060] The workflow of the modification module includes: if it is a single device and a single channel connection, the single device corresponds to one client, and the hardware device ID and ClientID are the same; if it is a single device and a multi-channel connection, the single device corresponds to multiple clients, and the method to obtain the ClientID includes: obtaining the channel identifier, combining the hardware device ID and the channel identifier to obtain the ClientID.
[0061] In this embodiment, the ClientID for device access in the single-device single-channel scheme is the device ID, and the device ID is unique. The single-device multi-channel scheme modifies the ClientID, dynamically allocating it. In the authentication and authorization interfaces, the new ClientID is adapted, allowing the server to find the correct device ID for subsequent authentication steps. When a single device uses multiple channels for connection, there are multiple clients, but from the cloud platform's perspective, it's only one device. Therefore, multiple online connections are equivalent to a single online connection. When the device goes offline, the cloud platform uses the number of established channels to determine if the device is offline. Each time the device establishes a connection through a new channel, the channel count is incremented; each time the device goes offline, the channel count is decremented. When the channel count reaches 0, the device is considered officially offline.
[0062] Data transmission between devices and the cloud platform requires subscription to message topics. In this embodiment, by modifying the message topics, different channels will equally distribute the uplink and downlink messages consumed by the devices. When the number of channels is increased from 1 to 2, the data transmission efficiency is doubled, which reduces the transmission pressure and meets the needs of large data transmission.
[0063] The verification module is used to look up the hardware device ID based on the ClientID, and uses the security gateway to call the IoT management platform interface to verify the hardware device ID. If the verification is successful, the valid AuthID in the cloud platform is extracted. In this embodiment, if the verification fails, the connection fails.
[0064] The comparison module is used to verify whether the AuthID and the valid AuthID match using the security gateway. If they match, a formal MQTT connection is established. In this embodiment, if the verification fails, the connection fails.
[0065] The embodiments described above are merely preferred embodiments of this application and are not intended to limit the scope of this application. Any modifications and improvements made to the technical solutions of this application by those skilled in the art without departing from the spirit of this application shall fall within the protection scope defined by the claims of this application.
Claims
1. A method for communication connection between a device and a cloud platform, characterized in that, Includes the following steps: S1. Use the device's connection gateway to read the hardware device ID and load the gateway certificate; S2. Enable mTLS authentication. The security gateway verifies the validity of the gateway certificate and reads the AuthID from the gateway certificate. S3. After the legitimacy authentication is successful, the ClientID is obtained based on the hardware device ID, and an MQTT protocol connection is established based on the ClientID; S4. Based on the ClientID, the hardware device ID is found. The security gateway calls the IoT management platform interface to verify the hardware device ID. After successful verification, the valid AuthID in the cloud platform is extracted. S5. The security gateway verifies whether the AuthID and the valid AuthID are consistent. If they are consistent, a formal MQTT connection is established. The mTLS authentication method includes: A two-way encrypted channel is used between the server and the client. The client verifies the server's public key certificate and uploads the client's public key certificate to the server. The server verifies the client's public key certificate, and completes the mTLS authentication upon successful verification. In S3, if it is a single device and a single channel connection, the single device corresponds to one client, and the hardware device ID is the same as the ClientID; In S3, if it is a single device connected to multiple channels, and the single device corresponds to multiple clients, the method for obtaining the ClientID includes: obtaining the channel identifier, and combining the hardware device ID with the channel identifier to obtain the ClientID; The data transmission method between the device and the cloud platform includes subscribing to message topics; By modifying the message topic, different channels will consume the uplink and downlink messages of the device equally. The message topic was modified as follows: By adding a shared subscription prefix before the original subscription message topic, a shared subscription method is adopted, allowing different channels under the multi-channel structure to poll and consume server messages in a round-robin fashion, ensuring that each channel consumes unique messages.
2. A device-cloud platform communication connection system, characterized in that, include: ID extraction module, authentication module, modification module, verification module, and comparison module; The ID extraction module is used to read the hardware device ID using the device's connection gateway and load the gateway certificate; The authentication module is used to enable mTLS authentication. The security gateway performs validity authentication on the gateway certificate and reads the AuthID from the gateway certificate. The modification module is used to obtain the ClientID based on the hardware device ID after the legitimacy authentication is successful, and to establish an MQTT protocol connection based on the ClientID; The verification module is used to look up the hardware device ID based on the ClientID, and use the security gateway to call the IoT management platform interface to verify the hardware device ID. After successful verification, the valid AuthID in the cloud platform is extracted. The comparison module is used to verify whether the AuthID and the valid AuthID are consistent using the security gateway. If they are consistent, a formal MQTT connection is established. The mTLS authentication method includes: A two-way encrypted channel is used between the server and the client. The client verifies the server's public key certificate and uploads the client's public key certificate to the server. The server verifies the client's public key certificate, and completes the mTLS authentication upon successful verification. The workflow of the modification module includes: if it is a single device and a single channel connection, the single device corresponds to one client, and the hardware device ID is the same as the ClientID; The workflow of the modification module also includes: if it is a single device and multiple channels connection, and the single device corresponds to multiple clients, the method for obtaining the ClientID includes: obtaining the channel identifier, and combining the hardware device ID with the channel identifier to obtain the ClientID; The data transmission method between the device and the cloud platform includes subscribing to message topics; By modifying the message topic, different channels will consume the uplink and downlink messages of the device equally. The message topic was modified as follows: By adding a shared subscription prefix before the original subscription message topic, a shared subscription method is adopted, allowing different channels under the multi-channel structure to poll and consume server messages in a round-robin fashion, ensuring that each channel consumes unique messages.