Intelligent lighting field trusted data transmission method combining MQTT protocol and block chain

Abstract

The invention discloses a trusted data transmission method in the field of smart lighting in combination with an MQTT protocol and a block chain. The trusted data transmission method comprises the following steps: an initialization stage, a connection establishment stage, a subscription stage, a message sending stage and a disconnection stage. According to the method, a block chain is introduced to solve the problems of potential safety hazards and distrust among nodes, equipment behaviors are chained for tracing the equipment behaviors, and data needing to be commonly used, such as identity information of the nodes, are stored in the block chain; the data of which the data correctness needs to be checked by using the Hash is stored to the IPFS, and the Hash value is stored to the block chain to reduce the time required for data transmission, so that the method has the advantages of high reliability, good expandability, high security and the like.

Description

Technical Field

[0001] The present invention relates to the field of blockchain technology, and in particular to a trusted data transmission method in the field of smart lighting that combines the MQTT protocol and blockchain. Background Art

[0002] With the continuous development of Internet of Things technology and blockchain technology and people's pursuit of high-quality smart life, smart lighting, as an important part of urban intelligent construction, has been widely used. In the field of smart lighting, by connecting lighting equipment to the Internet, functions such as remote control, energy consumption monitoring and intelligent adjustment of lighting equipment can be realized. The trusted transmission of IoT node data has always been an important research topic. In the application process of smart lighting, the traditional node data transmission method has problems such as data tampering, insufficient security, and low credibility, which cannot meet the needs of smart lighting systems for trusted data. These problems seriously affect the reliability and stability of smart lighting. Therefore, combining blockchain and MQTT technology to propose a trusted IoT node data transmission solution has become the focus of research.

[0003] As a lightweight communication protocol, MQTT is simple, reliable, efficient, and scalable, and is widely used in the Internet field. The MQTT protocol adopts a publish-subscribe model, which can achieve low-power, low-real-time data transmission. It is suitable for node communication in the Internet of Things scenario. However, the MQTT protocol itself does not provide security and reliability guarantees for data transmission, and is vulnerable to threats such as network attacks and data tampering.

[0004] Blockchain technology is a distributed, decentralized data storage and transmission technology with the characteristics of tamper-proof and non-forgeable. Combining blockchain technology with MQTT technology can provide security and credibility of data transmission. Blockchain can be used to record and verify the transmission process of IoT node data to ensure the integrity and authenticity of the data.

[0005] Hussein et al. proposed that the main challenge facing such control systems for IoT devices such as smart bulbs, smart switches, and control gateways is how to maximize security under limited resource conditions such as low processing power, low data rate, and low bandwidth IoT networks. To meet this challenge, IoT devices use secure communication protocols, namely MQTT-based denial of service (DoS) attacks, man-in-the-middle (MitM) attacks, and feasibility of masquerading attacks on ZigBee networks (IoT standards used in wireless mesh networks) to ensure the key security goals of confidentiality, integrity, and availability. These attacks are implemented through MQTT, which in turn compromises adjacent constrained application protocol (CoAP) nodes. For application developers in this field, it is imperative to reduce vulnerabilities to prevent attacks. A. Vlachokostas et al. introduced blockchain technology to ensure the integrity of lighting shared data in order to address the increase in data sharing and the expansion of the scope of network attacks. HsuTC et al. believe that in the field of Internet of Things (IoT) communications, many devices operate in resource-limited environments, and the MQTT communication protocol is often used to establish a fast and efficient data sharing and exchange network. However, MQTT also has certain limitations. It mainly supports message broadcasting rather than point-to-point data exchange. Each endpoint can only broadcast messages to other endpoints that are subscribed to the same topic. In addition, MQTT lacks a built-in encryption mechanism, making data transmission vulnerable to potential eavesdropping. To address these shortcomings, blockchain technology is utilized and enhanced with features such as public and private key management, broadcasting, and message verification. The goal is to improve the quality of communication and ensure the reliability of information encryption.

[0006] However, although the research on IoT data transmission solutions combining blockchain and MQTT has made some progress, it still faces some challenges in practical applications. For example, how to improve the efficiency and real-time performance of data transmission, how to solve the storage and computing overhead of blockchain, etc., still need further research and exploration. Summary of the invention

[0007] The technical problem to be solved by the present invention is how to provide a trusted data transmission method in the field of smart lighting that combines the MQTT protocol and blockchain with strong reliability, good scalability and high security.

[0008] In order to solve the above technical problems, the technical solution adopted by the present invention is: a trusted data transmission method in the field of smart lighting combining the MQTT protocol and blockchain, comprising the following steps:

[0009] Initialization: Users upload their relevant identity information to the chain according to their roles;

[0010] Establishing a connection: After the publisher obtains the relevant information of the proxy server from the blockchain, it sends a message containing its own username, password, digital signature and unique identifier to the proxy server to establish a connection between the publisher and the server;

[0011] Subscription: After the subscriber obtains the relevant information of the proxy server from the blockchain, it sends a message containing a unique identifier, username, password, the topic to be subscribed and digital signature information to the proxy server. The proxy server verifies the signature of the above message and uploads the information of the topic subscribed by the subscriber to the chain after the signature verification is successful;

[0012] Message sending: After verifying the digital signature in the message sent by the proxy server, the publisher sends the data including the topic to the proxy server. After receiving the data sent by the publisher, the proxy server stores the data and the topic on IPFS, and then stores the hash value of the data on the blockchain for subsequent verification. At the same time, the proxy server uploads the publisher's data publishing behavior to the chain for subsequent tracing. After the proxy server uploads the relevant data to the chain, it obtains the subscribers who subscribe to the topic from the blockchain, and sends the data including the topic and its own signature to the subscriber. After receiving the data sent by the proxy server, the subscriber hashes the data and compares it with the hash value on the blockchain to verify the authenticity of the data.

[0013] Disconnection: When the publisher has finished sending the data, he will generate a message with his unique identifier, username, password, signature and disconnection identifier, and send it to the proxy server to request disconnection. After receiving the publisher's message, the proxy server will parse and verify the signature. After successful verification, the data transmission event will be uploaded to the chain for subsequent tracing and the connection will be disconnected.

[0014] The beneficial effect of adopting the above technical solution is that: the method introduces blockchain to solve the security risks and distrust problems between nodes and puts device behavior on the chain for tracing the device behavior. At the same time, the commonly used data itself, such as the identity information of the node, is stored on the blockchain, and the data whose hash is needed to verify the correctness of the data is stored in IPFS, and its hash value is stored on the blockchain to reduce the time required for data transmission. It has the advantages of strong reliability, good scalability and high security. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The present invention will be further described in detail below in conjunction with the accompanying drawings and specific embodiments.

[0016] Figure 1 is a flow chart of the method described in an embodiment of the present invention;

[0017] Figure 2 is a specific flow chart of the method described in the embodiment of the present invention;

[0018] Figure 3 is a running time-speed comparison diagram in the method described in the embodiment of the present invention;

[0019] Figure 4 It is a comparison diagram of transmission times and speed in the method described in the embodiment of the present invention. DETAILED DESCRIPTION

[0020] The following is a clear and complete description of the technical solutions in the embodiments of the present invention in conjunction with the drawings in the embodiments of the present invention. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0021] In the following description, many specific details are set forth to facilitate a full understanding of the present invention, but the present invention may also be implemented in other ways different from those described herein, and those skilled in the art may make similar generalizations without violating the connotation of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below.

[0022] like Figure 1 As shown, the embodiment of the present invention discloses a trusted data transmission method in the field of smart lighting that combines the MQTT protocol and blockchain, including the following steps:

[0023] Initialization: Users upload their relevant identity information to the chain according to their roles;

[0024] Establishing a connection: After the publisher obtains the relevant information of the proxy server from the blockchain, it sends a message containing its own username, password, digital signature and unique identifier to the proxy server to establish a connection between the publisher and the server;

[0025] Subscription: After the subscriber obtains the relevant information of the proxy server from the blockchain, it sends a message containing a unique identifier, username, password, the topic to be subscribed and digital signature information to the proxy server. The proxy server verifies the signature of the above message and uploads the information of the topic subscribed by the subscriber to the chain after the signature verification is successful;

[0026] Message sending: After verifying the digital signature in the message sent by the proxy server, the publisher sends the data including the topic to the proxy server. After receiving the data sent by the publisher, the proxy server stores the data and the topic on IPFS, and then stores the hash value of the data on the blockchain for subsequent verification. At the same time, the proxy server uploads the publisher's data publishing behavior to the chain for subsequent tracing. After the proxy server uploads the relevant data to the chain, it obtains the subscribers who subscribe to the topic from the blockchain, and sends the data including the topic and its own signature to the subscriber. After receiving the data sent by the proxy server, the subscriber hashes the data and compares it with the hash value on the blockchain to verify the authenticity of the data.

[0027] Disconnection: When the publisher has finished sending the data, he will generate a message with his unique identifier, username, password, signature and disconnection identifier, and send it to the proxy server to request disconnection. After receiving the publisher's message, the proxy server will parse and verify the signature. After successful verification, the data transmission event will be uploaded to the chain for subsequent tracing and the connection will be disconnected.

[0028] This application combines the MQTT technology of blockchain with that of smart lighting to propose a trusted IoT node data transmission method, which uses blockchain to ensure the correctness of node information, the immutability of transmitted data, and the traceability of device behavior. Blockchain uses on-chain and off-chain storage to reduce the storage pressure of blockchain, and at the same time stores frequently used data on the blockchain to increase the running speed of the entire solution.

[0029] The symbols and meanings involved are shown in Table 1:

[0030] Table 1

[0031]

[0032]

[0033] The following is a detailed description of the above method.

[0034] The method described in this application includes five stages, namely, initialization stage, connection establishment stage, subscription stage, message sending stage and disconnection stage. The specific process is as follows: Figure 2 shown.

[0035] Phase 1: Initialization phase

[0036] (1) Identity information chain setup → {SL (INFOF, INFOD, INFOY)}

[0037] In order to ensure the authenticity of each node during the entire data transmission process, each node needs to upload different attribute sets to the chain according to its own role information before data transmission. The data that the publisher needs to upload to the chain include the publisher's unique identifier, the user name on the proxy server, and the public key for digital signature. The data that the subscriber needs to upload to the chain include the subscriber's unique identifier, the user name on the proxy server, and the public key for digital signature. The data that the proxy server needs to upload to the chain include the proxy server's version information, authentication information, and the public key for digital signature.

[0038] Phase 2: Establishing a connection

[0039] (2) Request connection {FID, INFOD, user FID , pwd FID , QM FID}→{CONNECT message}

[0040] When a publisher needs to publish information, the publisher must first obtain relevant information about the proxy server from the blockchain to ensure the authenticity of the proxy server, and then organize its unique identification, username, password, and digital signature information on the proxy server into a CONNECT message and send it to the proxy server to wait for the proxy server to agree to establish a connection.

[0041] (3) Agree to establish {PK FID ,INFOF FID , CONNECT message}→{CONNACK message}

[0042] When the proxy server receives the CONNECT message sent by the publisher, it will parse the message and compare the information contained in the parsed message with the information on the blockchain. If they are consistent, it will return a CONNACK message containing its own digital signature, public key and other information to the publisher to indicate that it agrees to establish a connection. If they are inconsistent, it will ignore them and blacklist the node IP after a certain number of times and no longer receive messages from the node.

[0043] Phase 3: Subscription Phase

[0044] (4) Request subscription {YID, INFOD, topic, user YID , pwd YID , QM YID ...}→{SUBSCRIBE message}

[0045] When subscribers need to subscribe to certain topic information, they need to generate a SUBSCRIBE message with their unique identifier, username, password and digital signature on the proxy server and the topic information to be subscribed, and transmit it to the proxy server to subscribe to the relevant topic information.

[0046] (5) Agree to subscribe {SUBSCRIBE message, PK FID ,INFOY YID}→{SL(YID,DID,topic,QM YID , QM DID .)}

[0047] After receiving the message from the subscriber, the proxy server parses the message to obtain the subscriber's username, password and digital signature, and then compares this information with the information on the blockchain. If the comparison is consistent, the information of the topic subscribed by the subscriber is uploaded to the chain. The information uploaded to the chain includes the subscriber's unique identifier, subscribed topic, subscription time and other information.

[0048] Phase 4: Message sending phase

[0049] (6) Send message {FID, INFOD, user FID , pwdF ID , QM FID , DATA}→{PUBLISH message}

[0050] When the publisher receives the CONNACK message sent by the proxy server, it parses the message to obtain the information of the proxy server and then compares it with the information on the blockchain. After the comparison is consistent, it starts to send data. The publisher generates a PUBLISH message with the data to be sent and the subject of the message and sends it to the proxy server to wait for the proxy server to receive it.

[0051] (7) Message uplink {PUBLISH message, INFORMATION message, FID}→{SL(HASH(DATA),FID,DID,topic,QM FID , QM DID}

[0052] After receiving the PUBLISH message sent by the publisher, the proxy server parses and verifies the message. The message sending record, timestamp and subject are uploaded to the chain for subsequent tracing. Due to the large amount of data, in order to alleviate the storage pressure on the blockchain, the data carried by the message is hashed, the data hash value is uploaded to the chain, and the data is stored on IPFS for subsequent data verification.

[0053] (8) Get the message {topic, INFOD} → {DATA topic}

[0054] After the proxy server uploads the relevant data to the chain, it obtains the subscribers who subscribe to the topic from the blockchain, combines the publisher's message with its own signature, and sends it to each subscriber who subscribes to the topic.

[0055] (9) Message verification {DATA, hash(DATA)} → {TRUE or FALSE}

[0056] After the subscriber receives the message from the proxy server, it parses the message and compares the digital signature with the information on the blockchain. After the comparison is successful, it starts to receive data from the proxy server and uploads the event of receiving the proxy server data to the chain.

[0057] Phase 5: Disconnection Phase

[0058] (10) Request to disconnect {FID, INFOD, user FID , pwd FID , QM FID ...}→{CONNECT message}

[0059] After the publisher's message is sent, the publisher can obtain relevant information of the proxy server from the blockchain and generate a CONNECT message with its own unique identifier, user name, password, signature and disconnection identifier and send it to the proxy server to request disconnection.

[0060] (11) Successfully disconnected {CONNECT message, INFOF FID}→{trueorfalse}

[0061] After receiving the CONNECT message sent by the publisher, the proxy server parses the message and verifies the digital signature from the blockchain. After successful verification, it disconnects from the publisher.

[0062] Example analysis:

[0063] Assume there are five users, publisher A, publisher B, proxy server C, subscriber D, and subscriber E. The specific applications based on the scenario are as follows:

[0064] The first stage is the initialization stage, where five users upload their relevant identity information to the chain according to their roles. Publishers A and B upload their unique identifiers, usernames on the proxy server, and public keys for digital signatures to the chain. Proxy server C uploads its version information, authentication information, and public keys for digital signatures to the chain. Subscribers D and E upload their unique identifiers, usernames on the proxy server, and public keys for digital signatures to the chain.

[0065] The second stage is the connection establishment stage. After publisher A and publisher B obtain the relevant information of proxy server C from the blockchain, they send a CONNECT message including their own username, password, digital signature, and unique identifier to proxy server C. A Messages and CONNECT B After receiving the message sent by publisher A and publisher B, the proxy server parses the message and obtains the public key from the blockchain to verify the signature based on the unique identifier and digital signature in the message. After the signature verification is successful, the proxy server compares the username and password. After the comparison is successful, the proxy server sends a CONNACK containing its own digital signature and unique identifier to publisher A and publisher B respectively. A and CONNACK B Message information indicates that the connection is agreed to be established. If they are inconsistent, they will be ignored, and after reaching a certain number of times, publisher A or publisher B will be blacklisted and no longer receive messages from the publisher.

[0066] The third stage is the subscription stage. After subscribers D and E obtain the relevant information of proxy server C from the blockchain, they send a SUBSCRIBE message to proxy server C containing a unique identifier, user name, password, topic A and topic B to be subscribed, and digital signature information. A and SUBSCRIBE B After receiving the messages from subscribers D and E, proxy server C continues to parse and obtain the public key from the blockchain based on the unique identifier and digital signature in the message to verify the signature. After the verification is successful, the username and password are compared. After the comparison is successful, the information of the subscribed topic of the subscriber is uploaded to the chain, including the subscriber's unique identifier, subscribed topic, subscription time and other information.

[0067] The fourth stage is the message sending stage. After verifying the digital signature in the message sent by the proxy server, publisher A and publisher B send data DATA with the subject A and B to proxy server C respectively. A and data DATA BAfter receiving the data sent by publishers A and B, the proxy server stores the data, the topic on IPFS, and then stores the hash value of the data on the blockchain for subsequent verification. At the same time, the proxy server puts the publisher's behavior of publishing data on the chain for subsequent traceability. After proxy server C puts the relevant data on the chain, it obtains subscriber D who subscribes to topic A and subscriber E who subscribes to topic B from the blockchain, combines the data of topic A with its own signature and sends it to subscriber D, and combines the data of topic B with its own signature and sends it to subscriber E. After receiving the data sent by proxy server C, subscribers D and E hash the data and compare it with the hash value on the blockchain to verify the authenticity of the data.

[0068] The fifth stage is the disconnection stage. When publisher A or publisher B finishes sending data, it generates a CONNECT with its unique identifier, user name, password, signature and disconnection identifier. A and CONNECT B Message, sent to the proxy server to request disconnection. After receiving the message from publisher A and publisher B, proxy server C parses and verifies the signature. After the signature is successfully verified, it compares the username and password. After the comparison is successful, the data transmission event is uploaded to the chain for subsequent tracing and disconnection.

[0069] Performance Analysis

[0070] 1) Function comparison

[0071] The functional comparison of this application with the literature [4] (Gao Ting. Real-time data acquisition and visualization system of IoT greenhouse based on MQTT protocol [J]. Wireless Internet Technology, 2023, 20(12): 50-52), literature [5] (Xiong Hui, Chen Qing, Zhou Jiujun, etc. Blockchain smart agriculture system based on MQTT protocol [J]. Smart Agriculture Guide, 2021, 1(12): 18-20.), literature [6] (Zeng Zaorong, Chen Deji, Xiao Yang. IoT communication protocol based on blockchain and MQTT [J]. Electronic Technology, 2022, 51(05): 15-19), and literature [7] (SUN Shuang, DURong, CHEN Shudong. A secure and computable blockchain-based data sharing scheme in IoT system [J]. Information (Switzerland), 2021, 12(2): 47. DOl: 10.3390 / infol2020047.) is shown in Table 2:

[0072] Table 2 - Function comparison table

[0073]

[0074] Like the present application, references [4], [5], [6], and [7] all use asynchronous communication to enhance fault tolerance and reduce network overhead. References [4] and [7] do not use cloud proxy servers, so reliability and scalability may be slightly poor. References [4] and [5] do not use blockchain to prevent data tampering, which poses certain security risks. References [4], [5], and [6] do not use on-chain or off-chain storage methods. The high storage pressure and storage overhead of blockchain may cause waste of resources and increase the entry threshold of blockchain consensus nodes. References [4], [5], [6], and [7] do not use hierarchical storage, which is poor in the granularity of data storage. At the same time, they do not trace the device behavior, which may pose certain security risks.

[0075] 2) Speed ​​comparison

[0076] Assume that the speed of retrieving block data from the blockchain is U qkl , the data transmitted from the blockchain is U cqkl , the size of the relevant information of all users stored on the blockchain is INFO, and the speed of retrieving block data from IPFS is U ipfs , the data transmitted from IPFS is U cipfs , the average size of the message in the entire transmission process is D, the amount of data carried in the message is DATA, the number of messages that need to be transmitted every day is S, and it is currently the tth day of system operation. At the same time, TF is used to represent the time a publisher spends in a data transmission, TD is used to represent the time a proxy server spends in a data transmission, TY is used to represent the time a subscriber spends in a data transmission, and T represents the total time a topic spends in a data transmission.

[0077] First, let's analyze the TF in the solutions proposed in various documents. It is obvious that the TF in documents [5] and [6] should be equal to the time to retrieve the relevant information of the proxy server from the blockchain + the time to download the relevant information of the proxy server from the blockchain + the time for data transmission. The TF in document [7] should be equal to the time to retrieve the relevant information of the proxy server from the blockchain + the time to retrieve the relevant information of the proxy server from IPFS + the time to download the relevant information of the proxy server from IPFS + the time for data transmission. The TF in this application should be equal to the time to retrieve the relevant information of the proxy server from the blockchain + the time to download the relevant information of the proxy server from the blockchain + the time for data transmission.

[0078] TF 文献[5] =INFO / U qkl +INFO / Ucqkl +D / U

[0079] TF 文献[6] =INFO / U qkl +INFO / U cqkl +D / U

[0080] TF 文献[7] =hash(INFO) / U qkl +INFO / U ipfs +INFO / U cipfs +D / U

[0081] TF 本方案 =INFO / U qkl +INFO / U cqkl +D / U

[0082] Secondly, let's analyze the TD in the solutions proposed in various documents. It is obvious that the TD in documents [5] and [6] should be equal to the time to retrieve the relevant information of the publisher and subscriber from the blockchain + the time to download the relevant information of the publisher and subscriber from the blockchain + the time to upload the relevant data to the chain; the TD in document [7] should be equal to the time to retrieve the relevant information of the publisher and subscriber from the blockchain + the time to retrieve the relevant information of the publisher and subscriber from IPFS + the time to download the relevant information of the publisher and subscriber from IPFS + the time to upload the hash value of the relevant data to the chain + the time to transfer the data to IPFS; the TD of this application should be the time to retrieve the relevant information of the publisher and subscriber from the blockchain + the time to download the relevant information of the publisher and subscriber from the blockchain + the time to upload the hash value of the relevant data to the chain + the time to transfer the data to IPFS, that is:

[0083] TD 文献[5] =INFO / U qkl +INFO / U cqkl +DATA / U cqkl

[0084] TD 文献[6] =INFO / U qkl +INFO / U cqkl +DATA / U cqkl

[0085] TD 文献[7] =hash(INFO) / U qkl +INFO / U ipfs +INFO / U cipfs +hash(DATA) / U cqkl +DATA / U cipfs

[0086] TD 本方案 =INFO / U qkl +(INFO) / U cqkl +hash(DATA) / U cqkl +DATA / U cipfs

[0087] Then, analyzing the TY of the solutions proposed in various documents, it is obvious that the TY in documents [5] and [6] should be equal to the time to retrieve the relevant information of the proxy server from the blockchain + the time to download the relevant information of the proxy server from the blockchain + the time of data transmission + the time to retrieve the data from the blockchain + the time to download the data from the blockchain. The TY in document [7] should be equal to the time to retrieve the relevant information of the proxy server from the blockchain + the time to retrieve the relevant information of the proxy server from IPFS + the time to download the relevant information of the proxy server from IPFS + the time of data transmission + the time to retrieve the data from the blockchain + the time to download the data from the blockchain. The TY in this application should be equal to the time to retrieve the relevant information of the proxy server from the blockchain + the time to download the relevant information of the proxy server from the blockchain + the time of data transmission + the time to retrieve the data from the blockchain + the time to download the data from the blockchain, that is:

[0088]

[0089]

[0090]

[0091]

[0092] Finally, we analyze T in each solution, which is the total time for a topic data transmission in each solution. Assume that a topic has M publishers and N subscribers, then T should be equal to M*TF+TD+N*TY, that is,

[0093]

[0094]

[0095]

[0096]

[0097] This application is based on the Eclipse Mosquitto framework and is simulated in the virtual machine Ubuntu 18. The blockchain uses the Fabric open source framework, IPFS uses Official Go IPFS, and the computer configuration is an Intel (R) Core (TM) processor with a main frequency of 2.90GHz and 12GB of memory. In the experimental simulation, it is assumed that a topic has 10 publishers and 10 subscribers. The relevant parameters tested by the performance test tool are shown in Table 3:

[0098] Table 3- Meaning of related parameters

[0099]

[0100] First, set the independent variable to the number of running days t, set the amount of data DATA sent at a time to 1M, the message size D to 2M, the number of messages sent and received by a node per day to 100 times, the hash value to 1024 bits, and the information that each node needs to upload to the chain to 1M. Then, the time of references [5], [6], [7] and this application is as follows: Figure 3 As shown;

[0101] Next, the independent variable is set to the number of messages a node sends and receives per day S, the amount of data DATA sent once is 1M, the message size D is 2M, the hash value uses 1024 bits, and the information that each node needs to upload to the chain is 1M. It is currently the 10th day of operation. The time of references [5], [6], [7] and this application is as follows: Figure 4 As shown; in summary, the performance of this application is optimal.

Claims

1. A trusted data transmission method in the field of smart lighting that combines the MQTT protocol and blockchain, characterized in that The steps include: Initialization: Users upload their relevant identity information to the chain according to their roles; Establishing a connection: After the publisher obtains the relevant information of the proxy server from the blockchain, it sends a message containing its own username, password, digital signature and unique identifier to the proxy server to establish a connection between the publisher and the server; Subscription: After the subscriber obtains the relevant information of the proxy server from the blockchain, it sends a message containing a unique identifier, username, password, the topic to be subscribed and digital signature information to the proxy server. The proxy server verifies the signature of the above message and uploads the information of the topic subscribed by the subscriber to the chain after the signature verification is successful; Message sending: After verifying the digital signature in the message sent by the proxy server, the publisher sends the data including the topic to the proxy server. After receiving the data sent by the publisher, the proxy server stores the data and the topic on IPFS, and then stores the hash value of the data on the blockchain for subsequent verification. At the same time, the proxy server uploads the publisher's data publishing behavior to the chain for subsequent tracing. After the proxy server uploads the relevant data to the chain, it obtains the subscribers who subscribe to the topic from the blockchain, and sends the data including the topic and its own signature to the subscriber. After receiving the data sent by the proxy server, the subscriber hashes the data and compares it with the hash value on the blockchain to verify the authenticity of the data. Disconnection: When the publisher has finished sending the data, he will generate a message with his unique identifier, username, password, signature and disconnection identifier, and send it to the proxy server to request disconnection. After receiving the publisher's message, the proxy server will parse and verify the signature. After successful verification, the data transmission event will be uploaded to the chain for subsequent tracing and the connection will be disconnected.

2. The trusted data transmission method in the field of smart lighting combining the MQTT protocol and blockchain as claimed in claim 1, characterized in that: The initialization comprises the following steps: Identity information on the chain: In order to ensure the authenticity of each node in the entire data transmission process, each node needs to upload different attribute sets to the chain according to its own role information before data transmission. The data that the publisher needs to upload to the chain includes the publisher's unique identifier, the user name on the proxy server, and the public key for digital signature; the data that the subscriber needs to upload to the chain includes the subscriber's unique identifier, the user name on the proxy server, and the public key for digital signature; The data that the proxy server needs to upload to the chain include the version information of the proxy server, authentication information and the public key for digital signature.

3. The trusted data transmission method in the field of smart lighting combining the MQTT protocol and blockchain as claimed in claim 1, characterized in that: The connection establishment comprises the following steps: Request connection: When the publisher needs to publish information, the publisher needs to first obtain the relevant information of the proxy server from the blockchain to ensure the authenticity of the proxy server, and then organize its unique identification, username, password, and digital signature information on the proxy server into a CONNECT message and send it to the proxy server, waiting for the proxy server to agree to establish a connection; Agree to establish a connection: When the proxy server receives the CONNECT message sent by the publisher, it parses the message and compares the information contained in the parsed message with the information on the blockchain. If they are consistent, it returns a CONNACK message containing its own digital signature and public key to the publisher to indicate that it agrees to establish a connection. If they are inconsistent, it will ignore it and blacklist the node IP after a certain number of times and no longer receive messages from the node.

4. The trusted data transmission method in the field of smart lighting combining the MQTT protocol and blockchain as claimed in claim 1, characterized in that: The subscription includes the following steps: Request subscription: When subscribers need to subscribe to certain topic information, they need to generate a SUBSCRIBE message with their unique ID, username, password and digital signature on the proxy server and the topic information to be subscribed, and transmit it to the proxy server to subscribe to the relevant topic information; Agree to subscription: After the proxy server receives the message from the subscriber, it parses the message to obtain the subscriber's username, password and digital signature, and then compares this information with the information on the blockchain. If the comparison is consistent, the information of the topic subscribed by the subscriber will be uploaded to the chain. The information uploaded to the chain includes the subscriber's unique identifier, the subscribed topic and the subscription time.

5. The trusted data transmission method in the field of smart lighting combining the MQTT protocol and blockchain as claimed in claim 1, characterized in that: The message sending comprises the following steps: Sending message: When the publisher receives the CONNACK message sent by the proxy server, it parses the message to obtain the information of the proxy server, and then compares it with the information on the blockchain. After the comparison is consistent, it starts to send data; the publisher generates a PUBLISH message with the data to be sent and the subject of the message and sends it to the proxy server to wait for the proxy server to receive it; Message on-chain: After receiving the PUBLISH message sent by the publisher, the proxy server parses and verifies the message, and uploads the message’s sending record, timestamp, and subject to the chain for subsequent tracing. Due to the large amount of data, in order to alleviate the storage pressure on the blockchain, the data carried by the message is hashed, the data hash value is uploaded to the chain, and the data is stored on IPFS for subsequent data verification. Get message: After the proxy server uploads the relevant data to the blockchain, it obtains the subscribers who subscribe to the topic from the blockchain, combines the publisher's message with its own signature, and sends it to each subscriber who subscribes to the topic; Message verification: After the subscriber receives the message from the proxy server, it parses the message and compares the digital signature with the information on the blockchain. After the comparison is successful, it starts to receive data from the proxy server and uploads the event of receiving the proxy server data to the chain.

6. The trusted data transmission method in the field of smart lighting combining the MQTT protocol and blockchain as claimed in claim 1, characterized in that: The disconnection comprises the following steps: Request to disconnect: After the publisher completes sending the message, the publisher obtains the relevant information of the proxy server from the blockchain, generates a CONNECT message with its unique identifier, username, password, signature and disconnection identifier, and sends it to the proxy server to request to disconnect; Successful disconnection: After receiving the CONNECT message sent by the publisher, the proxy server parses the message and verifies the digital signature from the blockchain. After successful verification, it disconnects from the publisher.

7. The trusted data transmission method in the field of smart lighting combining the MQTT protocol and blockchain as claimed in claim 1, characterized in that: There are five users in the method, namely publisher A, publisher B, proxy server C, subscriber D and subscriber E.

8. The trusted data transmission method in the field of smart lighting combining the MQTT protocol and blockchain as claimed in claim 7, characterized in that: The method specifically comprises the following steps: Initialization phase: Five users upload their relevant identity information to the chain according to their roles; publisher A and publisher B upload their unique identifiers, user names on the proxy server, and public keys for digital signatures to the chain respectively; Proxy server C uploads its version information, authentication information, and public key for digital signature to the chain; Subscribers D and E upload their unique identifiers, user names on the proxy server, and public keys for digital signature to the chain respectively; Establish connection: After publisher A and publisher B obtain relevant information of proxy server C from the blockchain, they send a CONNECT message containing their own username, password, digital signature, and unique identifier to proxy server C. A Messages and CONNECT B Message; After receiving the message sent by publisher A and publisher B, the proxy server parses the message and obtains the public key from the blockchain according to the unique identifier and digital signature in the message to verify the signature. After the signature verification is successful, the proxy server compares the username and password. After the comparison is successful, a CONNACK containing its own digital signature and unique identifier is sent to publisher A and publisher B respectively. A and CONNACK B The message information indicates that the connection is established. If it is inconsistent, it will be ignored and publisher A or publisher B will be blacklisted after reaching a certain number of times and the message of the publisher will no longer be received. Subscription: After subscribers D and E obtain the relevant information of proxy server C from the blockchain, they send a SUBSCRIBE message to proxy server C containing a unique identifier, user name, password, topic A and topic B to be subscribed, and digital signature information. A and SUBSCRIBE B Message; After receiving the messages from subscribers D and E, proxy server C continues to parse and obtain the public key from the blockchain based on the unique identifier and digital signature in the message to verify the signature. After the signature verification is successful, the username and password are compared. After the comparison is successful, the information of the subscribed topic of the subscriber is uploaded to the chain. The uploaded information includes the subscriber's unique identifier, subscribed topic, subscription time and other information; Sending message: After verifying the digital signature in the message sent by the proxy server, publisher A and publisher B send data DATA with the subject A and B to proxy server C respectively. A and data DATA B After receiving the data sent by publishers A and B, the proxy server stores the data,topic on IPFS and then stores the hash value of the data on the blockchain for subsequent verification. At the same time, the proxy server puts the publisher's data publishing behavior on the chain for subsequent traceability; after proxy server C puts the relevant data on the chain, it obtains subscriber D who subscribes to topic A and subscriber E who subscribes to topic B from the blockchain, combines the data with its own signature and sends it to subscriber D, and combines the data with its own signature and sends it to subscriber E; after receiving the data sent by proxy server C, subscribers D and E hash the data and compare it with the hash value on the blockchain to verify the authenticity of the data. Disconnect: When publisher A or publisher B finishes sending data, it will generate a CONNECT with its unique ID, user name, password, signature and disconnection ID. A and CONNECT B The message is sent to the proxy server to request disconnection; After receiving the messages from publishers A and B, proxy server C parses and verifies the signatures. After successful verification, it compares the username and password. After successful comparison, the data transmission event is uploaded to the chain for subsequent tracing of device behavior and disconnection.

Images