Detailed Description
To make the objects, features and advantages of the present invention more comprehensible and practical for a person skilled in the relevant art, the present invention is described in detail in the following description with reference to the accompanying drawings, and the present invention is further described in detail by referring to the preferred embodiments, which are not intended to limit the present invention, and the drawings referred to in the following are used to express the description of the features relevant to the present invention.
First, please refer to fig. 1A, which is a schematic diagram of an internet of things connection system according to the present invention. As shown in fig. 1A, the internet of things connection system is composed of a client device (client device)100, a cloud device (cloud device)500, and at least one broker device (broker device) 700; the client device 100 is a device having a wireless or wired communication function and a specific user identifier; a cloud device 500 having a function of communicating with the client 100, and confirming that the client 100 is the client 100 of one of the internet of things by using a specific user identifier of the client 100; and a proxy server 700 having its website address and password and capable of communicating with the cloud device 500.
In the Internet of things connection system of the present invention, the client device 100 may be a floating IP Address (Internet Protocol Address) that changes at any time, or may be a device with a fixed IP wireless communication function (e.g., a personal computer, a notebook computer, a smart phone, a smart mobile device, a smart reader, etc.), and each client device 100 has a unique Identifier (e.g., a code set by a manufacturer at a time of factory shipment; and hardware data such as MAC Address, etc.) so as to generate a universal unique Identifier (uid) of the client device 100 for identifying or preventing hackers from intruding. In addition, in the internet of things connection System of the present invention, the cloud device 500 is a fixed Domain Name System (DNS), which has a function of a server (server) and a function of performing wireless communication with each client device 100, and the cloud device 500 at least comprises a receiving/transmitting interface module, a data processing module, and a memory module; therefore, the cloud device 500 has recorded all uuids belonging to all clients in the internet of things of the present invention and has stored in the memory module 530 to form a database. Furthermore, the proxy server 700 is a floating IP that can change at any time, and the main task of the proxy server is to receive the encoded data string transmitted by the client device 100 in the internet of things and then directly transmit the encoded data string to the cloud device 500; specifically, the proxy server 700 does not perform any processing after receiving the data string transmitted by the client device, but directly transmits the received data string, and after receiving the data string of the proxy server 700 by the cloud device 500 and decoding, processes the data string transmitted by the client device 100. It is obvious that in the internet of things connection system of the present invention, in the process of the whole client device 100 passing the data string to the cloud device 500, the cloud device 500 does not directly expose its own address, so that the probability of hacking the cloud device 500 can be reduced, and the security of the internet of things can be greatly improved.
In the preferred embodiment of the internet of things connection system of the present invention, the plurality of client devices 100 can be divided into a plurality of groups, and each group corresponds to or is paired with one proxy server device 700, so that there can be a plurality of proxy server devices 700 in the internet of things connection system of the present invention, as shown in fig. 1B. When the cloud device 500 determines that one of the proxy servers 700 is hacked, the hacked proxy server 700 may be selected to be turned off, or a new website and password of the proxy server 700 may be re-established, so as to further ensure the security of the internet of things of the present invention. In addition, in the embodiment of the present invention, the proxy server 700 selects a communication standard (protocol) using mqtt (message Queuing technical transport) to transmit the data string. MQTT is a protocol designed for the Internet of things, particularly a lightweight message transfer protocol based on publish/subscribe mode, invented by IBM, Dr.Andy Stanford-Clark, and by Arcom, Dr.Arlen Nipper, 1999; originally, protocols were designed for communication between a large number of remote sensors and control devices with limited computational power and operating over low bandwidth, unreliable networks. Therefore, the MQTT has the advantages of small and light transmitted data and can have great advantages in bandwidth and speed; because the required network bandwidth is very low, the required hardware resource is also low, so that the efficiency of the internet of things system or various commercial operation systems (such as logistics management, establishment and inquiry of production histories of products, identification of product authenticity and the like) using the internet of things connection system can be improved; and therefore, the cost of commercial operation can be effectively reduced.
Next, the process and method for actually completing the connection of the internet of things according to the present invention will be described in detail.
Referring to fig. 1A, first, the client device 100 logs in to the cloud device 500 (the communication direction is indicated by S1 in fig. 1A), for example, the client device 100 logs in to the cloud device 500 through https, so as to start the internet of things system. Next, when the cloud apparatus 500 receives the request from the client apparatus 100 (as indicated by the communication direction indicated by S2 in fig. 1A), the cloud apparatus 500 verifies whether the hardware uuid (e.g., MAC Address) used by the client apparatus 100 is already stored in the database of the cloud apparatus 500; if it is confirmed that the hardware uuid (e.g., MAC Address) Address used by the client device 100 is already stored in the database of the cloud device 500, a client identifier (client uuid) is generated; next, the cloud device 500 generates a pair of keys for exclusive use by the client; in the preferred embodiment of the present invention, this Key is an RSM Asymmetric Key (Asymmetric Key); therefore, a pair of client _ pub _ key and client _ pri _ key can be generated; the RSM asymmetric key has long decoding time, so that the security is high. In another preferred embodiment, the cloud device 500 can further selectively generate a Symmetric Key (Symmetric Key) client _ share _ Key specific to the client device 100. Therefore, in the preferred embodiment of the present invention, the RSM asymmetric key and the RSM symmetric key can be selectively used together; since the symmetric key has short decoding time and relatively low security, the client _ share _ key needs to be changed at any time to ensure security; therefore, the cloud device 500 may further generate/set a variable time (share _ key _ exception data time), and the security is improved by changing the share _ key _ exception data time at variable times; therefore, when the cloud device 500 detects that the client _ share _ key that changes at any time exceeds the time that the share _ key _ expiry date time is set to change, a new client _ share _ key is automatically generated to ensure the security. When the cloud apparatus 500 determines that the hardware uuid (e.g., MAC addresses) of a client apparatus 100 is the same as the hardware uuid stored in the database, it determines that the client apparatus 100 is a client in the internet of things, and then the cloud apparatus 500 transmits messages such as uuid and key back to the client apparatus 100 (as indicated by S3 in fig. 1A), where the messages transmitted back to the client apparatus 100 include client _ uuid, server _ pub _ key (i.e., client _ pub _ key), and since all the client apparatuses 100 use the same pub _ key, they may be referred to as server _ pub _ key) and client _ print _ key.
In addition, if the cloud device 500 compares that the hardware uuid (e.g., MAC Address) used by the client device 100 is not in the database of the cloud device 500 after the cloud device 500 receives the request of the client device 100, and determines that the hardware uuid (e.g., MAC Address) used by the client device 100 is not a client device in the internet of things, the hardware uuid (e.g., MAC Address) message is stored in another database for subsequent comparison. It should be noted that, in general, the backhaul mechanism in the S3 communication direction has no error, but has a mechanism in which an error occurs; for example, if the Server response time is too long and the connection fails, the client device 100 executes the process again, but the cloud device 500 determines that the hardware uuid (e.g., MAC Address) is recorded in the database, and then returns the uuid corresponding to the hardware uuid (e.g., MAC Address), and at this time, the key generated by the cloud device 500 and returned to the client device 100 is updated. Therefore, even if there is a fake device that uses any method to counterfeit the hardware uuid (e.g., MAC Address) of the client device 100, the same key cannot be obtained. In other words, only one determined uuid can survive in the system.
Then, as indicated by S4 in fig. 1A, when the client device 100 obtains the client _ share _ key, the share _ key _ expiration date, the MQTT _ Broker IP, the MQTT _ Broker account and the password (user/password) through https "request" with the encoded client _ uuid (i.e., the client _ uuid would turn to a messy code according to the server _ pub _ key); when the cloud device 500 receives the client _ uuid converted into the random code, decoding is performed according to the server _ pri _ key to determine whether the client _ uuid is correct; after the cloud device 500 confirms that the client _ uuid is correct, the cloud device 500 encodes the client _ share _ key, the share _ key _ expiration date, the MQTT _ Broker IP, the MQTT _ Broker account number, the password, and the like by the client _ pub _ key and then transmits the encoded information back to the client device 100 (for example, the communication direction indicated by S5 in fig. 1A).
In addition, in a preferred embodiment of the present invention, the IP, account and password of MQTT _ Broker can be obtained twice; for example, for the first time (the communication direction indicated by S4 in fig. 1A), the client device 100 obtains the client _ share _ key, the share _ key _ expiration date time, and the MQTT _ Broker IP through https "request" with the encoded client _ uuid (i.e., the client _ uuid would turn into a scrambling code according to the server _ pub _ key); when the cloud device 500 receives the client _ uuid converted into the random code, decoding is performed according to the server _ pri _ key to determine whether the client _ uuid is correct; after the cloud device 500 confirms that the client _ uuid is correct, the cloud device 500 encodes and transmits the client _ share _ key, the share _ key _ explicit data time, the MQTT _ Broker IP, and the like with the client _ pub _ key back to the client device 100 (as the communication direction indicated by S5 in fig. 1A). For the second time (as the communication direction indicated by S6 in fig. 1A), the client device 100 obtains the MQTT _ Broker account and the password by using the encoded client _ uuid (i.e., the client _ uuid will turn into the messy code according to the server _ pub _ key) through https "request"; when the cloud device 500 receives the client _ uuid converted into the random code, decoding is performed according to the server _ pri _ key to determine whether the client _ uuid is correct; after the cloud device 500 confirms that the client _ uuid is correct, the cloud device 500 transmits the MQTT _ Broker account, the password, and the like encoded by the client _ pub _ key back to the client device 100 (as shown in the communication direction indicated by S7 in fig. 1A). Specifically, the content to be obtained for the first time and the second time only requires to obtain the IP, the account number, and the password of the MQTT _ Broker twice, and the others are not limited.
Obviously, in the process of identifying and confirming the client device 100 and the cloud device 500, https used by the client device 100 belongs to a hybrid cipher hack-proof, Secure communication protocol (SSL) or Transport Layer Security protocol (TLS), which belongs to a recognized Security protocol, and a recognized certificate required by the cloud device 500 can be used by the client device 100 to confirm whether a message is directly transmitted from the cloud device 500 by a digital signature of an authentication center; therefore, when a hacker performs tampering, embezzlement or denial actions in the message transmission process, the password can be prevented from being tampered or embezzled by the security authentication.
Then, as the communication direction indicated by S8 in fig. 1A, when the client device 100 obtains the relevant data from the cloud device 500, the client device 100 is connected to the proxy server device 700; before proceeding with the connection with the proxy server 700, it is necessary to confirm that the received message is complete, and the complete message includes 1. server _ pub _ key; client _ pri _ key; MQTT _ Broker IP; MQTT _ Broker username/password; client _ Share _ key; share _ key _ expiration date time. After the client device 100 confirms that the complete message is received, the client _ share _ key is used to encode the client _ uuid and the data content (datainvocated) to be transmitted to the cloud by the client device 100, and then the encoded data content is uploaded to the proxy server device 700 (MQTT Broker).
In the preferred embodiment of the present invention, the client device 100 further checks whether the aging of Share _ key _ expiration date time has expired (e.g., expiration date of 2015/0501); if the age of the Share _ key _ expiration time has elapsed (for example, the result of checking the expiration date is 2015/0502), the client device 100 will re-use the encoded client _ uuid (i.e., the client _ uuid will be converted into a scrambled code according to the server _ pub _ key), and request a new Share _ key _ expiration time message through https; when the cloud device 500 receives the client _ uuid converted into the random code, decoding is performed according to the server _ pri _ key to determine whether the client _ uuid is correct; after the cloud device 500 determines that the client _ uuid is correct, the cloud device 500 encodes the new share _ key _ exception data with the client _ pub _ key and transmits the encoded share _ key _ exception data back to the client device 100. In addition, to increase security, the time set by the share _ key _ expiration data time may be periodic or random, and may be determined by the cloud device 500.
After the client device 100 confirms that the complete message has been received, at this time, the client device 100 already knows the MQTT _ Broker IP and MQTT _ Broker account number and password of the proxy server device 700, so that the client device 100 can upload the encoded client _ uuid and data string (e.g., production history of the product, etc.) to the proxy server device 700 (as indicated by the communication direction indicated by S8 in fig. 1A); then, the proxy server 700 receives the encoded client _ uuid and the data string (e.g., the production history of the product) uploaded by the client device 100, and then directly (i.e., without any processing) transmits the message uploaded by the client device 100 to the cloud device 500; obviously, in the process of the entire internet of things that the client device 100 sends the message string to the cloud device 500, the cloud device 500 does not directly expose its address, so that the probability of hacking the cloud device 500 can be reduced. Since the proxy server 700 only directly transmits the data uploaded by the client device 100 to the cloud device 500, the probability of breaking the MQTT _ Broker IP and MQTT _ Broker account and password of the proxy server 700 can be reduced, and the security of the internet of things communication process can be further improved.
Then, as indicated by S9 in fig. 1A, after receiving the data (i.e., the encoded client _ uuid and the data string) directly transmitted by the proxy server 700, the cloud device 500 immediately decodes (Decode) the data by using the client _ share _ key, and verifies whether the received client _ uuid and the data string (e.g., the production history of the product, etc.) are complete and correct; if the data string is correct, the data string is stored in the memory module 530, and the user waits for the received data string (such as the production history of the product) to be applied specifically; for example, a production record database of at least one product is established; and if the received client _ uuid and the data string are verified to be incomplete or incorrect, recording. It should be noted that the purpose of verifying the incorrect message is to prevent or reduce the probability of hacking by the internet of things system through a verification mechanism of artificial intelligence for deep learning or artificial addition, modification or correction. In this embodiment, the incorrect message includes, for example, (1) news crawlers find the counterfeit of certain commodities rampant; or (2) the same client _ uuid set at the beginning of the program appears in two completely different places at the same time, at the moment, the internet of things system informs the company inspectors or gives an alarm, and the treatment modes which can be made by the inspectors at least have actions of observation or neglect and the like, so that the effects of early warning and preventing hacker are achieved; also, (3) the device 500 itself is continuously sent suspicious information by a specific proxy server 700, such as unknown client _ uuid information; if the incorrect message continues to appear, and it is determined that the proxy server 700 is likely to be hacked, the cloud device 500 may choose to turn off the proxy server 700 (as indicated by S10 in fig. 1A).
In the embodiment of the present invention, the client _ share _ key encoding manner may be matched with a hash function to prevent tampering, wherein the hash function may select MD5, SHA-1, SHA-256, or the like. Meanwhile, the client _ share _ key can also be matched with different decoding (decode) modes, such as block cipher, stream cipher, ECB mode or the mixed method, and the like, so that the decoding difficulty can be effectively improved, and the decoding time can not be lost.
Please refer to fig. 1B, which is a schematic diagram of another embodiment of the internet of things connection system of the present invention. As shown in fig. 1B, the internet of things connection system is composed of a plurality of client devices 100, a cloud device 500 and at least one proxy device 700; wherein each client device 100 is a device having a wireless communication function and a specific user identifier; a cloud device 500 having a communication function with each client 100, for identifying the client 100 as the client 100 in one of the internet of things by using a specific user identifier unique to each client 100; the proxy server 700 has its website address and password, and can communicate with the cloud device 500. Since the basic connection system of the embodiment of fig. 1B is the same as that of the embodiment of fig. 1A, the difference between the two is that after the cloud device 500 provides the address, account and password of each proxy server to the client devices 100 in at least one internet of things and forms a pair, the paired client devices 100 can only communicate with the paired proxy server 700, and then the proxy server 700 communicates with the cloud device 500, so as to transmit the data on each client device 100 to the cloud device 500. Therefore, the process of actually completing the connection of the internet of things in fig. 1B is briefly described as follows.
Referring to fig. 1B, first, each client device 100 logs in to the cloud device 500 through https. Then, after the cloud device 500 receives the request of each client device 100, the cloud device 500 verifies whether the hardware uuid (such as MAC Address) used by each client device 100 is already stored in the database of the cloud device 500; if it is confirmed that the hardware uuid (e.g., MAC Address) used by each client device 100 is already stored in the database of the cloud device 500, generating an individual identification code (client uuid) for each client; next, the cloud device 500 generates a pair of keys for the specific client according to each client device 100; after the cloud device 500 determines that each client device 100 is a client in the internet of things, the cloud device 500 returns the generated messages such as each uuid and the key to each corresponding client device 100, where the messages returned to each client device 100 include client _ uuid, server _ pub _ key, and client _ pri _ key.
Then, each client device 100 may obtain the client _ share _ key, share _ key _ expiry date, MQTT _ Broker IP, MQTT _ Broker account and password (username/password) from the encoded client _ uuid through https "request"; when the cloud device 500 receives the client _ uuid converted into the random code, the client _ uuid is decoded according to the respective server _ pri _ key, so as to determine whether each received client _ uuid is correct; after the cloud device 500 confirms that the client _ uuid is correct, the cloud device 500 encodes the client _ share _ key, the share _ key _ expiration date, the MQTT _ Broker IP, the MQTT _ Broker account number, the password and the like in the client _ pub _ key and then transmits the encoded information back to the client device 100. For example, the IP, the account number and the password of the agent device (Broker-1) are transmitted back to Client-1 to Client-5; the IP, the account and the password of the agent device (Broker-2) are transmitted back to Client-6 to Client-15; the IP, the account and the password of the agent device (Broker-3) are transmitted back to Client-16 to Client-50; it is obvious that the internet of things has paired 50 individual client devices 100 from 3 proxy servers 700 to communicate with the cloud device 500. Then, after each client device 100 obtains the related data through the cloud device 500, the client device 100 connects with the obtained paired proxy server 700; meanwhile, when each client device 100 determines that the message received by the cloud device 500 includes 1. set _ pub _ key; client _ pri _ key; MQTT _ Broker IP; MQTT _ Broker username/password; client _ Share _ key; after the Share _ key _ explicit data time, the client _ uuid and the data content to be transmitted to the cloud by the client apparatus 100 are encoded by using the client _ Share _ key, and then are uploaded to the proxy server 700 (i.e., MQTT Broker).
Since each client 100 knows the MQTT _ Broker IP and MQTT _ Broker account and password of the paired proxy server 700 after confirming that the client 100 has received the complete message, the client 100 can upload the encoded client _ uuid and the message string (e.g., the production history of the product, etc.) to the paired proxy server 700; then, each proxy server 700 receives the encoded client _ uuid and the message string (e.g., the production history of the product) uploaded by the client 100, and then directly (i.e., without any processing) transmits the message uploaded by the client 100 to the cloud device 500; obviously, in the process of the entire internet of things that the client device 100 sends the message string to the cloud device 500, the cloud device 500 does not directly expose its address, so that the probability of hacking the cloud device 500 can be reduced. Since each proxy server 700 only directly transmits the data uploaded by the client device 100 to the cloud device 500, the probability of breaking the MQTT _ Broker ip and MQTT _ Broker account numbers and passwords of the proxy server 700 can be reduced, and the security of the internet of things communication process can be further improved. Next, after receiving the data (i.e., the encoded client _ uuid and the encoded data string) directly transmitted by each proxy server 700, the cloud device 500 immediately decodes the data using each client _ share _ key, and verifies whether the received client _ uuid and the data string (e.g., the production history of the product, etc.) are complete and correct; if the data string is correct, the data string is stored in the memory module 530, and the user waits for the received data string to perform specific application; for example, a production record database of at least one product is established; if the received client _ uuid and the data string are verified to be incomplete or incorrect, recording; in this embodiment, the generation of the incorrect message may include that each client issues a message with a certain regularity, for example, if a message issued by a certain client with abnormal or excessive frequency is generated, the message is regarded as an incorrect message; or the agent server 700 itself issues the frequency release information not via MQTT, but tries to connect to the cloud device 500; when the incorrect message continues to appear, it is determined that the proxy server 700 is likely to be hacked; the cloud device 500 may choose to shut down the proxy server 700.
In summary, the main technical means of the internet-of-things connection system of the present invention is that after the cloud device 500 confirms that each client device 100 is a user of the internet of things, the cloud device 500 returns MQTT _ Broker IP, MQTT _ Broker account number and password of the proxy server device 700 to each client device 100, and then each client device 100 connects with the proxy server device 700 according to the received MQTT _ Broker IP, MQTT _ Broker account number and password, and uploads a data string (e.g., production history of a product, etc.) to be transmitted by each client device 100 to the proxy server device 700 after being encoded; next, the proxy server 700 directly transmits the data string transmitted from the client device 100 to the cloud device 500 for decoding and processing, without processing the data string (for example, the production history of the product) transmitted from the client device 100. It is obvious that the internet of things connection system of the present invention is divided into two stages for connection, and after the identification of the client device 100 is completed in the first stage, the client device 100 can only be connected with the proxy server device 700 in the second stage; since the first phase is completed before the client 100 connects, the client 100 can only connect and communicate with the proxy server 700 while it is transmitting data; therefore, the cloud device 500 does not directly expose its own address, so that the probability of hacking the cloud device 500 can be reduced, and the security of the internet of things connection system can be effectively improved.
Then, the embodiment of the invention for establishing the product production record and the product production record query system by using the internet of things connection system is further explained.
Referring to fig. 2, a schematic diagram of an embodiment of the present invention for establishing a production history and a product production history query system using an internet of things connection system is shown. As shown in fig. 2, the client device 100 may be a reader/writer device at the manufacturer end, and after recording the entire production and delivery history of the product from each manufacturing step to the delivery location with a time axis as an item of the product production history content and after confirming at S1-S7 in fig. 1A or fig. 1B (i.e. after confirming that each client device 100 is one client device in the internet of things and each client device 100 has acquired the website and password of the proxy server device 700 to be connected), the client device 100 may encode the content data of the production history and transmit the encoded content data to the proxy server device 700, and after receiving the messages, the proxy server device 700 may transmit the encoded content data to the proxy server device 700 without processing the data string (e.g. the production history of the product, etc.) transmitted by the client device 100, the data string transmitted by the client device 100 is directly transmitted to the cloud device 500 for decoding and processing, so as to establish a production history database in the memory module 530 of the cloud device 500, wherein the production history database can record the whole production history of each product from each manufacturing step to the delivery to the store; when the client device 100 transmits the data of the production history to the cloud device 500, it can only connect and communicate with the paired proxy server 700; therefore, in the whole process of establishing the production record database, the cloud device 500 does not directly expose its own address, so that the probability of hacking of the cloud device 500 can be reduced, and the security of establishing the production record database by the internet of things can be effectively improved.
Next, an embodiment of the query system for the production history of the internet of things product according to the present invention will be described. Referring to fig. 2 again, after the internet of things has established the production history database in the memory module 530 of the cloud end device 500, the cloud end device 500 may transmit the production history of the product to be queried, the type of the production history data (i.e. selecting text, picture, voice or film, etc.) or the security data to the communication device 100 of the user through the communication direction indicated by S11 and display the data according to the request of the user (the user has confirmed that the user is logged in, for example, a smart phone). Since the cloud device 500 can set the IP, the account and the password of the proxy server 700 ', when the cloud device 500 is to transmit the production history or the security data of the product to the user, the same can only be connected and communicated with the proxy server 700 ' through the IP, the account and the password of the proxy server 700 '; therefore, in the whole process that the cloud device 500 transmits the production history or the information such as the security data of the product to be inquired by the user to the smart phone of the user, the cloud device 500 does not directly expose the address of the user, so that the probability that the cloud device 500 is attacked by hackers can be reduced, and the security of the production history database of the internet of things can be effectively improved.
It is obvious that, in the query system of the product production history of the internet of things of the present invention, after the specific user identifier confirms that the client device 100 is one of the client devices in the internet of things, the client device 100 communicates the product data to be queried with the proxy server device 700 'only through the website and the password of the proxy server device 700', and then the proxy server device 700 'directly communicates with the cloud device 500, so that after the cloud device 500 compares the product data to be queried by the client device 100 with the product production history database, the cloud device 500 communicates the information in the product production history database with the proxy server device 700' only through the website and the password of another proxy server device 700 ', so that the proxy server device 700' transmits the information in the product production history database to the client device 100.
In a preferred embodiment of the present invention, a detailed content type record may be further created in the record taking the time axis as the key item of the product production history content, and the detailed content type may be created in the production history database of the cloud device 500 by using the text shown in fig. 3A, the text and the picture shown in fig. 3B, or the voice or the image, etc. In addition, a database formed by product warranty data may also be established, wherein the product warranty data at least includes data such as the product number of the product, the date of putting the product on shelf, the date of leaving the product from factory, the place of manufacture, the address of the manufacturer and the material of the product, and the like, as shown in fig. 3C.
Next, a connection method and a process for establishing and querying the production history of the internet of things connection system according to the present invention will be described in detail, and the innovation point of using the proxy server 700 according to the present invention can be more clearly understood through the connection method and the process of the internet of things connection system.
Please refer to fig. 4, which is a flowchart of a method for establishing a product production history and querying the product production history using the internet of things according to the present invention. As shown in fig. 4, the method for establishing a product production record and querying the product production record by using the internet of things of the present invention includes:
in step 1, the client device 100 logs in to the cloud device 500, for example, the client device 100 logs in to the cloud device 500 through https, so as to start the internet of things system.
Step 2, after the cloud device 500 receives the request from the client device 100, the cloud device 500 verifies whether the hardware uuid (e.g., MAC Address) used by the client device 100 is already stored in the database of the cloud device 500.
Step 3, when the cloud device 500 confirms that the hardware uuid (e.g., MAC Address) used by the client device 100 is already stored in the database of the cloud device 500, it is determined that the data of the client device 100 is correct, and the client device 100 is the client device 100 in the internet of things, and the cloud device 500 generates a client identifier (client uuid) and a key used by a pair of exclusive clients. In this embodiment, the Key is an RSM Asymmetric Key (asymmetry Key) with high security; therefore, a pair of client _ pub _ key and client _ pri _ key can be generated; the messages sent back to the client device 100 include client _ uuid and server _ pub _ key (the server _ pub _ key is client _ pub _ key), and if the cloud device 500 receives the request from the client device 100, the cloud device 500 compares that the hardware uuid (such as MAC Address) used by the client device 100 is not in the database of the cloud device 500, and determines that the hardware uuid (such as MAC Address) used by the client device 100 is not the client device in the internet of things, the hardware uuid (such as MAC Address) message is stored in another database for subsequent comparison.
Step 4, the client device 100 determines whether the uuid and the key generated by the cloud device 500 are correctly received; when the client device 100 confirms that the message such as the uuid and the key has been correctly received, the client device 100 immediately requests the cloud device 500 to obtain the client _ share _ key, the MQTT _ Broker IP of the proxy server device 700, and the MQTT _ Broker account and password (user/password) by https with the encoded client _ uuid (i.e., the client _ uuid is converted into the scrambled code according to the server _ pub _ key).
Step 5, after receiving the client _ uuid converted into the random code, the cloud device 500 decodes the client _ uuid according to the server _ pri _ key to determine whether the client _ uuid is correct; after the cloud device 500 confirms that the client _ uuid is correct, the cloud device 500 encodes and transmits the client _ share _ key, the MQTT _ Broker IP and MQTT _ Broker account number and password of the proxy server 700 and the like in the client _ pub _ key to the client device 100.
Step 6, after the client device 100 obtains the relevant data from the cloud device 500, the client device 100 immediately decodes the relevant data by using the client _ pri _ key and confirms that the received message is complete, wherein the complete message comprises 1. set _ pub _ key; client _ pri _ key; MQTT _ Broker IP; MQTT _ Broker username/password; client _ Share _ key. When the client device 100 confirms that the complete message is received, it will connect with the proxy server device 700; if the client device 100 determines that the received message is incomplete, it returns to step 4 to request the cloud device 500 to obtain the client _ share _ key, the MQTT _ Broker IP of the proxy server device 700, and the MQTT _ Broker account and password (user name/password).
Step 7, the client device 100 uses MQTT _ Broker IP and MQTT _ Broker account number and password to connect with the proxy server device 700; meanwhile, the client _ side _ key is used to encode the client _ uuid and the data content (for example, the production history of the product, etc.) to be transmitted to the cloud device 500 by the client device 100, and then the encoded data content is uploaded to the proxy server 700.
In step 8, the proxy server 700 directly (i.e., without any processing) transmits the message uploaded by the client device 100 to the cloud device 500 after receiving the encoded client _ uuid and the message string (e.g., the production history of the product) uploaded by the client device 100.
Step 9, after receiving the data directly transmitted by the proxy server 700, the cloud device 500 decodes the data by using the client _ share _ key, and verifies whether the received client _ uuid and data string (e.g., production history of the product, etc.) are complete and correct.
Step 10, when the cloud device 500 determines that the received client _ uuid and the data string are complete and correct, the decoded client data string (for example, the production history of the product, etc.) is stored in the memory module 530, and the user waits for the received data string to perform specific application, for example, the establishment of the production history database of the product is completed in the cloud device 500; if the received client _ uuid and the data string are verified to be incomplete or incorrect, recording; in this embodiment, the incorrect message includes (1) that the client _ u corresponding to an ip is incorrect, which may cause a theft problem (2) if a client _ u has data upload matching Geo Location, it can be verified by verifying the validity of Geo Location (whether a client _ u is in asia for one minute and in north america for the next minute); when the incorrect message continues to appear, it is determined that the proxy server 700 is likely to be hacked; the cloud device 500 may choose to shut down the proxy server 700.
Obviously, in the connection method process of the entire internet of things connection system, all the steps from step 1 to step 6 are completed with the cloud end device 500 before each client device 100 leaves the factory, that is, after each client device 100 leaves the factory, a complete message is obtained from the cloud end device 500, including 1. set _ pub _ key; client _ pri _ key; MQTT _ Broker IP; MQTT _ Broker username/password; client _ Share _ key. After the internet of things system is started, the data string to be transmitted to the cloud device 500 for processing by each client device 100 is transmitted to the proxy server device 700 according to MQTT _ BrokerIP, and then the proxy server device 700 directly transmits the data string of the client device 100 to the cloud device 500. Therefore, in the message transmission process from step 7 to step 10 (i.e., in the process of establishing the product production history database), the cloud device 500 does not directly expose its own address, so that the probability of hacking the cloud device 500 can be reduced. Since the proxy server 700 only directly transmits the data uploaded by the client device 100 to the cloud device 500, the probability of breaking the MQTT _ Broker IP and MQTT _ Broker account and password of the proxy server 700 can be reduced, and the security of the internet of things communication process can be further improved.
Then, when a consumer uses the smart phone to see a certain product on the network and wants to purchase the product, the consumer can check the production history or the warranty data of the product through the product number (product number) or the QR Code marked on the network, and the query process is described as follows.
Firstly, a consumer can establish a smart phone used by the consumer and the Internet of things to complete an identity identification program; for example, downloading APP software of the internet of things of the present invention, and through the process from step 1 to step 6 in fig. 4, allowing the consumer to use the smart phone to complete the identity recognition procedure in the internet of things of the present invention, that is, the consumer uses hardware uuid (such as MAC Address) of the smart phone to be stored in the database of the cloud device 500; then, when the consumer can use the smart phone, the consumer can transmit the product number (product number) or QR Code to be queried and the data string such as the production history or the security data of the product to the proxy server 700 through step 7 according to MQTT _ Broker IP, and then through step 8, the proxy server 700 directly transmits the data string to be queried by the consumer to the cloud device 500. Then, in step 9, when the cloud device 500 determines that the received client _ uuid and the data string are complete and correct, in step 11, according to the decoded consumer data string, it will compare whether the product number (product number) or QR Code to be queried is established in the product production record database; if the product number (goods number) or the QR Code that the consumer wants to query is compared, the cloud device 500 may further check whether the production history or the form of the secured data of the product that the consumer wants to query exists; if the product is in the form of the production history or the security data, the cloud device 500 is connected to the proxy server 700 ' via step 12, and the product is transmitted to the proxy server 700 ' via the step 12, and then the product is transmitted to the smart phone of the consumer via the proxy server 700 ', so that the consumer can see the product through the display of the smart phone.
Since the cloud device 500 can set the IP, the account and the password of the proxy server 700 ', when the cloud device 500 is to transmit the production history or the security data of the product to the user, the same can only be connected and communicated with the proxy server 700 ' through the IP, the account and the password of the proxy server 700 '; therefore, in the whole process that the cloud device 500 transmits the production history or the information such as the security data of the product to be queried by the user to the smart phone of the user, the cloud device 500 does not directly expose the address of the user, so that the probability that the cloud device 500 is attacked by hackers can be reduced, and the safety of the cloud device 500 and the internet of things production history database can be effectively improved.
Next, please refer to fig. 5, which is a flowchart illustrating a method for establishing product production records and querying product production records using the internet of things according to another embodiment of the present invention. As shown in fig. 5, the method for establishing a product production record and querying the product production record by using the internet of things of the present invention includes:
in step 1, the client device 100 logs in to the cloud device 500, for example, the client device 100 logs in to the cloud device 500 through https, so as to start the internet of things system.
Step 2, after the cloud device 500 receives the request from the client device 100, the cloud device 500 verifies whether the hardware uuid (e.g., MAC Address) used by the client device 100 is already stored in the database of the cloud device 500.
Step 3, when the cloud device 500 confirms that the hardware uuid (e.g., MAC Address) used by the client device 100 is already stored in the database of the cloud device 500, it is determined that the data of the client device 100 is correct, and the client device 100 is the client device 100 in the internet of things, and the cloud device 500 generates a client identifier (client uuid) and a key used by a pair of exclusive clients. In this embodiment, the Key is an RSM Asymmetric Key (asymmetry Key) with high security; therefore, a pair of client _ pub _ key and client _ pri _ key can be generated; the messages sent back to the client device 100 include client _ uuid and server _ pub _ key (the server _ pub _ key is client _ pub _ key), and if the cloud device 500 receives the request from the client device 100, the cloud device 500 compares that the hardware uuid (such as MAC Address) used by the client device 100 is not in the database of the cloud device 500, and determines that the hardware uuid (such as MAC Address) used by the client device 100 is not the client device in the internet of things, the hardware uuid (such as MAC Address) message is stored in another database for subsequent comparison.
Step 4, the client device 100 determines whether the uuid and the key generated by the cloud device 500 are correctly received; when the client device 100 confirms that the message such as the uuid and the key has been correctly received, the client device 100 immediately requests the cloud device 500 to obtain the client _ share _ key, the share _ key _ expiration date, the MQTT _ Broker IP of the proxy server device 700, the MQTT _ Broker account and the password (user/password) by using the encoded client _ uuid (i.e., the client _ uuid is converted into the random code according to the server _ pub _ key).
In the preferred embodiment of the present invention, this Key is an RSM Asymmetric Key (Asymmetric Key); therefore, a pair of client _ pub _ key and client _ pri _ key can be generated; the RSM asymmetric key has long decoding time, so that the security is high. In another preferred embodiment, the cloud device 500 can also selectively generate a Symmetric Key (Symmetric Key) client _ share _ Key specific to the client device 100. Therefore, in the preferred embodiment of the present invention, the RSM asymmetric key and the RSM symmetric key can be selectively used together; since the symmetric key has short decoding time and relatively low security, the client _ share _ key needs to be changed at any time to ensure security; therefore, the cloud device 500 may further generate a share _ key _ exception data time that changes at any time, so as to improve the security by changing the client _ share _ key at any time; therefore, when the cloud device 500 detects that the client _ share _ key that changes at any time exceeds the set change time, a new client _ share _ key is automatically generated to ensure security.
Step 5, after receiving the client _ uuid converted into the random code, the cloud device 500 decodes the client _ uuid according to the server _ pri _ key to determine whether the client _ uuid is correct; after the cloud device 500 confirms that the client _ uuid is correct, the cloud device 500 encodes and transmits the client _ share _ key, the share _ key _ expiry date, the MQTT _ Broker IP of the proxy server 700, the MQTT _ Broker account and the password to the client device 100 through the client _ pub _ key.
Step 6, after the client device 100 obtains the relevant data from the cloud device 500, the client device 100 immediately decodes the relevant data by using the client _ pri _ key and confirms that the received message is complete, wherein the complete message comprises 1. set _ pub _ key; client _ pri _ key; MQTT _ Broker IP; MQTT _ Broker username/password; client _ Share _ key; share _ key _ expiration date time. When the client device 100 confirms that the complete message is received, it will connect with the proxy server device 700; if the client device 100 determines that the received message is not complete, it returns to step 4 to request the cloud device 500 to obtain the message again.
Step 7, the client device 100 uses MQTT _ Broker IP and MQTT _ Broker account number and password to connect with the proxy server device 700; meanwhile, the client _ side _ key is used to encode the client _ uuid and the data content (for example, the production history of the product, etc.) to be transmitted to the cloud device 500 by the client device 100, and then the encoded data content is uploaded to the proxy server 700.
Step 8, the client device 100 checks whether the aging of the Share _ key _ expiration date time has expired; if the checking result is not expired, the encoded client _ uuid and the data string (such as the production history of the product) are uploaded to the proxy server 700; if the check result is the expired state, the process returns to step 4 to request the cloud device 500 to obtain a new Share _ key _ expiration date. For example, an expiration date of 2015/0501; if the check result is already aged by the Share _ key _ exception data time (for example, the check date result is 2015/0502), the client device 100 will re-use the encoded client _ uuid (i.e., the client _ uuid will be converted into a scrambled code according to the server _ pub _ key), and request to obtain a new Share _ key _ exception data time through https; when the cloud device 500 receives the client _ uuid converted into the random code, decoding is performed according to the server _ pri _ key to determine whether the client _ uuid is correct; after the cloud device 500 determines that the client _ uuid is correct, the cloud device 500 encodes the new share _ key _ exception time with the client _ pub _ key and transmits the encoded share _ key _ exception time back to the client device 100. In addition, to increase security, the time set by the share _ key _ expiration data time may be periodic or random, and may be determined by the cloud device 500.
In step 9, the proxy server 700 directly (i.e., without any processing) transmits the message uploaded by the client device 100 to the cloud device 500 after receiving the encoded client _ uuid and the message string (e.g., the production history of the product) uploaded by the client device 100.
Step 10, after receiving the data directly transmitted by the proxy server 700, the cloud device 500 decodes the data by using the client _ share _ key, and verifies whether the received client _ uuid and data string (e.g., production history of the product, etc.) are complete and correct.
Step 11, when the cloud device 500 determines that the received client _ uuid and the data string (e.g., the production history of the product, etc.) are complete and correct, the decoded client data string is stored in the memory module 530, and the user waits for the received data string (e.g., the production history of the product, etc.) to be specifically processed and applied; if the received client _ uuid and the data string are verified to be incomplete or incorrect, recording; in this embodiment, the incorrect message includes (1) that the client _ u corresponding to an ip is incorrect, which may cause a theft problem (2) if a client _ u has a data upload matching the Geo Location, it can be verified by verifying the validity of the Geo Location (whether a client _ u is in asia for one minute and in north america for the next minute). When the incorrect message continues to appear, it is determined that the proxy server 700 is likely to be hacked; the cloud device 500 may choose to shut down the proxy server 700.
Obviously, in the connection method process of the entire internet of things connection system, all the steps from step 1 to step 6 are completed with the cloud end device 500 before each client device 100 leaves the factory, that is, after each client device 100 leaves the factory, a complete message is obtained from the cloud end device 500, including 1. set _ pub _ key; client _ pri _ key; MQTT _ Broker IP; MQTT _ Broker username/password; client _ Share _ key; share _ key _ expiration date time. After the internet of things system is started, the data string to be transmitted to the cloud device 500 for processing by each client device 100 is transmitted to the proxy server device 700 according to MQTT _ Broker IP, and then the proxy server device 700 directly transmits the data string of the client device 100 to the cloud device 500. Therefore, in the message transmission process from step 7 to step 10, the cloud device 500 does not directly expose its own address, so that the probability of hacking the cloud device 500 can be reduced. Since the proxy server 700 only directly transmits the data uploaded by the client device 100 to the cloud device 500, the probability of breaking the MQTT _ Broker IP and MQTT _ Broker account and password of the proxy server 700 can be reduced, and the security of the internet of things communication process can be further improved.
Next, in step 4 of fig. 5, the process of the client device 100 obtaining the MQTT _ Broker IP, MQTT _ Broker account number, and MQTT _ Broker password of the proxy server device 700 from the cloud device 500 may be divided into two steps to be executed; for example, the client device 100 acquires the client _ share _ key and the MQTT _ Broker IP through https request for the first time with the encoded client _ uuid (i.e., the client _ uuid will be converted into scrambled code according to the server _ pub _ key); when the cloud device 500 receives the client _ uuid converted into the random code, decoding is performed according to the server _ pri _ key to determine whether the client _ uuid is correct; after the cloud device 500 confirms that the client _ uuid is correct, the cloud device 500 encodes the client _ share _ key, the MQTT _ Broker IP and the like by the client _ pub _ key and then transmits the encoded client _ share _ key back to the client device 100; the second time, the client device 100 uses the encoded client _ uuid (i.e. the client _ uuid will be converted into a messy code according to the server _ pub _ key) to obtain the MQTT _ Broker account and the password through https; when the cloud device 500 receives the client _ uuid converted into the random code, decoding is performed according to the server _ pri _ key to determine whether the client _ uuid is correct; after the cloud device 500 confirms that the client _ uuid is correct, the cloud device 500 transmits the MQTT _ Broker account and the password to the client device 100 after being encoded by the client _ pub _ key. Specifically, the content to be obtained for the first time and the second time only requires to obtain the IP, the account number, and the password of the MQTT _ Broker twice, and the others are not limited.
Then, when a plurality of consumers use their own smart phones to see a certain product on the network and want to purchase the product, the consumers can see the production history or warranty data of the product through the product number (product number) or QR Code marked on the network, and the query process is described as follows.
Firstly, each consumer can establish a program for identifying the identity of the smart phone used by the consumer and the Internet of things; for example, each consumer has downloaded APP software of the internet of things of the present invention, and through the process from step 1 to step 6 in fig. 4, the smart phone used by each consumer has completed the identity recognition procedure in the internet of things of the present invention, that is, the hardware uuid (e.g., MAC Address) of the smart phone used by each consumer has been stored in the database of the cloud device 500; next, when each consumer uses the smart phone, the product number (product number) or QR Code to be queried and the data string such as production history or warranty data to be checked are transmitted to the proxy server 700 through steps 7 to 8 according to the MQTT _ Broker IP paired by each consumer, and then the data string to be queried by the consumer is directly transmitted to the cloud device 500 through step 9 by the proxy server 700. Then, in step 10, when the cloud device 500 determines that the received client _ uuid and the data string are complete and correct, in step 12, comparing the decoded data string of each consumer with the product production history database to determine whether the product number (product number) or QR Code to be queried is established; if the product number (cargo number) or QR Code that each consumer wants to query is compared, the cloud device 500 may further check whether the production history or the form of the retention data of the product that the consumer wants to query exists; if the product is in the form of the production history or the retention data of the product to be queried by the consumer, the cloud device 500 is connected to the proxy server 700 ' via step 13, and transmits the production history or the retention data of the product to be queried by each consumer to another proxy server 700 ', and then the proxy server 700 ' directly transmits the production history or the retention data of the product to the smart phone of each consumer, so that each consumer can see the production history or the retention data of the product to be purchased through the display on the smart phone. It is obvious that the cloud device 500 can also communicate with a plurality of proxy servers 700 ', and each proxy server 700' can form a pair with a plurality of consumers.
Since the cloud device 500 can set the IP, the account and the password of the proxy server 700 ', when the cloud device 500 is to transmit the production history or the security data of the product to the user, the same can only be connected and communicated with the proxy server 700 ' through the IP, the account and the password of the proxy server 700 '; therefore, in the whole process that the cloud device 500 transmits the production history or the information such as the security data of the product to be queried by the user to the smart phone of the user, the cloud device 500 does not directly expose the address of the user, so that the probability that the cloud device 500 is attacked by hackers can be reduced, and the safety of the cloud device 500 and the internet of things production history database can be effectively improved.
Although the present invention has been described with reference to the above preferred embodiments, it should be understood that various changes and modifications can be made therein by those skilled in the art without departing from the spirit and scope of the invention.