Full-period lightweight identity verification system and method for Internet of Things

Abstract

The invention provides a complete-cycle lightweight identity verification system and method for the Internet of Things, and the system comprises a registration module which is used for enabling an Internet of Things device to send a temporary identity code to a cloud server, generating and returning an authentication parameter through the cloud server, verifying and storing the authentication parameter through the Internet of Things device, and completing the registration of the Internet of Things device; the authentication module is used for realizing identity authentication and session key negotiation between the Internet of Things devices and between the Internet of Things devices and the cloud server by utilizing elliptic curve basic operation and a hash function for the registered Internet of Things devices; and the communication module is used for encrypting the image acquired by the Internet of Things equipment at the sending end by using the negotiated session key, generating a ciphertext image and embedding the authentication information into the ciphertext image for transmission through the embedded message verification code, and the Internet of Things equipment at the receiving end extracts and verifies the integrity of the ciphertext image. The system constructed by the invention provides better security, and the cost in the aspects of storage, communication and calculation is relatively low.

Description

Technical Field

[0001] This invention belongs to the field of Internet of Things (IoT) communication technology, specifically relating to a lightweight authentication system and method for the entire lifecycle of IoT. Background Technology

[0002] Due to the low computing and storage costs of IoT devices, lightweight IoT security authentication protocols are currently a hot research topic. IoT communication mainly includes communication between devices and servers, as well as communication between devices. Specifically, it is divided into three phases: registration, authentication, and communication. In the registration phase, IoT devices need to pre-configure parameters and auxiliary information with the server to support subsequent authentication and communication phases. The authentication and communication phases, as crucial links in data interaction, are not only frequent but also incur significant communication overhead. In the authentication phase, both parties need to perform mutual authentication and key negotiation, a process vulnerable to man-in-the-middle attacks, replay attacks, and impersonation attacks. In the communication phase, both parties use the negotiated key to encrypt and transmit information, a process susceptible to interception, tampering, and forgery.

[0003] Currently, existing Lightweight Authentication Protocols (LAPs) focus only on optimizing the registration and authentication phases. Commonly used techniques and mathematical methods include symmetric encryption, elliptic curve cryptography (ECC), fuzz extractors and biometrics, physically unclonable functions (PUFs), blockchain, and XOR operations and hash functions. LAPs designed by combining these techniques have made significant progress. However, among these methods, symmetric encryption has lower computational overhead, but its key management costs are high and it is vulnerable to man-in-the-middle attacks. Biometrics and PUFs are often used in conjunction with fuzz extractors. Fuzz extractors have the advantage of extracting secure keys from random noise data, supporting key updates, and improving the flexibility and security of authentication. However, they have relatively high computational complexity and require a large amount of storage space. Biometrics have the advantage of the uniqueness of biometrics, and the authentication process is bound to the biometric holder, but its application scenarios are limited. The uniqueness and unclonability of PUFs can provide a unique identity for each IoT device, and they are characterized by low power consumption and low cost. However, because the output of the hardware itself is susceptible to physical environmental factors, errors can occur, and a large number of challenge-response pairs need to be stored on the device during the registration phase to ensure subsequent secure authentication. Lightweight Protocol Applications (LPAs) designed based on blockchain offer significantly enhanced security due to their decentralized nature; however, using blockchain also increases the computational and storage overhead of the protocol. LAPs based on ECC combined with XOR and hash functions are a popular approach, as ECDHP guarantees data security. Therefore, reducing the number of hash or ECC operations through protocol design without compromising security is key to improving lightweightness. In summary, existing LAPs primarily improve efficiency in the registration and authentication phases by introducing lightweight cryptographic authentication technologies, but protocol security is constrained by various overheads. Furthermore, improving message transmission efficiency in the communication phase remains unresolved.

[0004] In IoT networks, the number of interactions and overhead during the communication phase account for the largest proportion. Furthermore, the efficiency of secure communication and authentication directly affects the practicality of the IoT system. The current mainstream communication model uses a session key negotiated during the authentication phase for encrypted communication. The integrity of the communication content and the secure authentication of the message source mainly rely on additional authentication data or additional message authentication codes. Based on this communication model, further reducing the number of communications or communication overhead is quite difficult.

[0005] In summary, to achieve lightweight improvements throughout the entire lifecycle of the Internet of Things (IoT), new security technologies should be effectively introduced to further reduce communication and computational overhead during the authentication and communication phases without compromising security. Summary of the Invention

[0006] To address the problems of existing technologies, this invention provides a lightweight authentication system and method for the entire lifecycle of the Internet of Things (IoT). In the authentication phase, a certificateless anonymous authentication and communication protocol based on a combination of non-interactive zero-knowledge proofs and elliptic curve cryptography (ECC) is designed, exhibiting low storage and computational complexity. In the communication phase, this invention introduces an embedded message authentication code (EMAC) based on reversible data hidden in the encrypted domain (RDH-ED), providing a new method to optimize communication by embedding the verification message into the transmitted ciphertext. This reduces both the number of communications and communication overhead. Furthermore, RDH-ED can be applied to IoT devices that upload data to cloud servers for trusted storage, thereby effectively ensuring data trustworthiness.

[0007] To achieve the above objectives, the present invention provides the following solution:

[0008] A lightweight, end-to-end authentication system for the Internet of Things (IoT) includes:

[0009] The registration module is used to enable IoT devices to send a temporary identity code to the cloud server, generate and return authentication parameters through the cloud server, verify and store the authentication parameters of the IoT devices, and complete the registration of the IoT devices.

[0010] The authentication module is used to authenticate registered IoT devices and negotiate session keys between IoT devices and between IoT devices and cloud servers by using elliptic curve basic operations and hash functions.

[0011] The communication module is used to encrypt images collected by the sending IoT device using a negotiated session key, generate ciphertext images, and transmit authentication information embedded in the ciphertext images via an embedded message verification code. The receiving IoT device extracts and verifies the integrity of the ciphertext images.

[0012] Preferably, the registration module includes:

[0013] The temporary identity code generation unit is used to calculate the identity ID and password of IoT devices, generate a temporary identity code, and send it to the cloud server.

[0014] The device parameter calculation unit is used by the cloud server to calculate authentication parameters using a private key and send them to the IoT device.

[0015] The message verification unit is used by IoT devices to determine whether the received authentication parameters have been attacked by calculating the hash function of the authentication parameters, and to store the authentication parameters that have not been attacked to the database.

[0016] Preferably, the authentication module includes a device and cloud service authentication unit, used to realize authentication between IoT devices and cloud servers and session key negotiation. The specific authentication process includes:

[0017] Based on the first preset verification condition, verify the correctness of the IoT device's identity ID and password. If correct, generate a first high-entropy random number n1, and calculate N1 = n1G. A i =H(B i ||N i Z i =n1+A i ×C i and will request data {A i Z i E i The data is sent to the cloud server via a public channel; where N1 = n1G represents the point-to-point operation between the first high-entropy random number n1 and the base point G of the elliptic curve. Represents the parameter E stored by the i-th IoT device. i The temporary identification code (DID) representing the i-th IoT device. i Perform XOR operation A i =H(B i ||N i H(.) represents hashing the result of the dot product operation with the result of the XOR operation; H(.) represents the hash function; and || represents the concatenation operation. i =n1+A i ×C i This represents performing scalar operations on the intermediate parameters;

[0018] The cloud server received the requested data {A} i Z i E i After that, the temporary identity code of the IoT device is calculated and the integrity of the requested data is verified based on the second preset verification condition. If the data is complete, a second high-entropy random number n2 is generated, N2 = n2G is calculated, and the session key k is obtained. shared =H(n2N1||C i ||DID i ) and authentication information Auth = H(DID) i ||C i ||k shared The system will return {N2,Auth} to the IoT device; where N2 represents the parameters required for the final session key, and Auth represents the authentication information, including the temporary identity code and parameter C. i and session key k shared The result of the hash operation;

[0019] After receiving {N2,Auth}, the IoT device calculates the session key k. shared =H(n1N2||Ci ||DID i ), verify Auth' = H(DID) i ||C i ||k shared If the condition is met, it means that the {N2,Auth} received by the IoT device was generated by the cloud server, thus completing the authentication between the IoT device and the cloud server and the establishment of the session key.

[0020] Preferably, the authentication module further includes a device-to-device authentication unit for authenticating IoT devices and negotiating session keys. The specific authentication process includes:

[0021] Based on the identity ID and password of the first IoT device, calculate the temporary identity code of the first IoT device, generate a third high-entropy random number m1, and calculate M. i =m1G, A i =H(B i ||N i Z i =n1+A i ×C i , And request data {A i Z i ,F i Send it to the second IoT device;

[0022] The second IoT device receives the request data {A} i Z i ,F i After that, calculate Get B j , through the received F i get By calculating M i =(Z i -A i ×C i G gets M i Post-verification of A' i =H(B j ||M i ) = A i If true, generate a third high-entropy random number m2 and calculate M. j =m2G, obtain session key k share =H(m2M) i ||B i ) and authentication information Auth = H(B j ||C i ||k shared), will message {M j Auth} is returned to the first IoT device; where E j 、R j Each represents a parameter stored in the j-th device, DID j This is the temporary identification code for the j-th device;

[0023] The first IoT device receives the message {M} returned by the second IoT device. j ,Auth}, using M j Calculate session key k shared =H(m1M) j ||B i ), and authenticate the equation Auth' = H(B i ||C i ||k share If the authentication is successful, the authentication between IoT devices and the establishment of session keys will be completed.

[0024] Preferably, the communication module includes:

[0025] Encryption unit, used by the transmitting IoT device to utilize session key k shared The acquired image Fig is encrypted pixel by pixel to obtain the ciphertext image P;

[0026] The authentication information generation unit is used to calculate the authentication information Auth = H(Fig||B) i Using the ciphertext field embedding algorithm, calculate M = Emb(P, Auth) and then embed the authentication information Auth = H(Fig||B). i Embed into the ciphertext image P and transmit the ciphertext M to the receiving IoT device; where Emb(,) represents the embedding operation.

[0027] The authentication information extraction unit is used by the receiving IoT device to extract the ciphertext image P and the embedded authentication information Auth=H(Fig||B) from the ciphertext M. i Calculate (P,Auth) = Extr(M), where Extr(,) represents the extraction operation;

[0028] Decryption unit, used to utilize session key k shared Decrypt the ciphertext image P and calculate... By determining Auth'=H(Fig||B) i The integrity of the received message is verified by checking whether the condition is true or false; where Dec represents the decryption operation.

[0029] Preferably, it also includes an analysis module for performing security and performance analysis on the full-lifecycle lightweight authentication system; wherein the security analysis includes informal security analysis and formal security analysis.

[0030] This invention also provides a lightweight authentication method for the entire lifecycle of the Internet of Things, wherein the system described above includes:

[0031] The IoT device sends a temporary identity code to the cloud server, the cloud server generates and returns authentication parameters, the IoT device verifies and stores the authentication parameters, and the IoT device registration is completed.

[0032] For registered IoT devices, elliptic curve basic operations and hash functions are used to achieve identity authentication and session key negotiation between IoT devices and between IoT devices and cloud servers.

[0033] Images collected by the sending IoT device are encrypted using a negotiated session key to generate ciphertext images. Authentication information is then embedded into the ciphertext images and transmitted via an embedded message verification code. The receiving IoT device extracts and verifies the integrity of the ciphertext images.

[0034] Preferred methods for registering IoT devices include:

[0035] Calculate the identity ID and password of the IoT device, generate a temporary identity code and send it to the cloud server;

[0036] The cloud server uses the private key to calculate authentication parameters and sends them to the IoT device;

[0037] IoT devices determine whether the received authentication parameters have been attacked by calculating a hash function of the authentication parameters, and store the authentication parameters that have not been attacked in the database.

[0038] Compared with existing technologies, the advantages of this invention are as follows: The Full-Lifecycle Lightweight Authentication Protocol (FCLAP) designed in this invention enables full-lifecycle IoT authentication communication between devices (D2D) and between devices and cloud servers (D2C). FCLAP consists of three phases: registration, authentication, and communication. In the registration and authentication phases, based on the concept of non-interactive zero-knowledge proof, only elliptic curve cryptography and hash functions are used to achieve D2D and D2C authentication and key negotiation. In the communication phase, EMAC technology is introduced to reduce communication frequency and overhead, and to achieve message integrity authentication without increasing the amount of additional information. The proposed scheme utilizes elliptic curve cryptography (ECS) combined with Reversible Data Hiding in Encrypted Domain (RDH-ED) technology to provide a smaller key size. Based on the properties of elliptic curve cryptography, necessary information is hidden within the transmitted data, effectively reducing the amount of data transmitted.

[0039] It achieves security while requiring fewer interactions and less data storage on devices and servers. The proposed authentication scheme has been proven semantically safe under the widely accepted stochastic oracle model. Attached Figure Description

[0040] To more clearly illustrate the technical solution of the present invention, the drawings used in the embodiments are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0041] Figure 1 This is a schematic diagram of the system model in an embodiment of the present invention;

[0042] Figure 2 This is a schematic diagram illustrating the traditional message authentication code and embedded message authentication code processes provided in embodiments of the present invention;

[0043] Figure 3 This is a flowchart illustrating the workflow of the FCLAP IoT communication protocol according to an embodiment of the present invention.

[0044] Figure 4 This is a diagram comparing the communication and computational overhead (D2C) of an embodiment of the present invention;

[0045] Figure 5 This is a diagram comparing the communication and computational overhead (D2D) of an embodiment of the present invention.

[0046] Figure 6This is a schematic diagram of image encryption and decryption according to an embodiment of the present invention; wherein, (a) is the original image of the aircraft; (b) is the encrypted image of the aircraft; (c) is the ciphertext image of the aircraft after embedding the message; (d) is the image of the recovered aircraft; (e) is the original image of the hill; (f) is the encrypted image of the hill; (g) is the ciphertext image of the hill after embedding the message; and (h) is the recovered image of the hill. Detailed Implementation

[0047] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0048] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0049] The following explanations are provided for some terms appearing in the embodiments: Non-interactive zero-knowledge proof is an important form of zero-knowledge proof (ZKP). Its core principle is that the prover can convince the verifier that a statement is true without revealing any useful information to the verifier. In identity authentication, this means that a user can prove they possess a secret without directly exposing that secret to the verifier. Therefore, this property can be used to prove that a user possesses a unique representation assigned by the server to prove they are a registered user.

[0050] It possesses three fundamental properties: Completeness: If A knows a certain secret, B will accept A's proof. Reliability: If A's statement is false, no malicious prover in polynomial time can generate a proof acceptable to the verifier (the probability is negligible). Zero-knowledge: The verifier gains no additional information from the proof except for the fact that "the statement is true".

[0051] Schnorr (1990) proposed an authentication protocol that designed an efficient challenge-response mechanism for smart card scenarios. Its core idea is to achieve knowledge proof without revealing the private key through the discrete logarithm problem. Here, we briefly review the core steps of the protocol (notation follows the original paper).

[0052] First, choose large prime numbers p and q (satisfying q|p-1, q≥2). 210 Multiplication group A generator α (of order q), a user private key s∈[1,q], and a public key v=α -s The process of establishing a key using the interactive key is as follows: mod p

[0053] 1) The prover chooses a random number r∈[1,q-1] and calculates x=α r mod p, and send x to the verifier.

[0054] 2) The verifier selects a random challenge c∈[0,2]. t -1].

[0055] 3) The prover calculates the response y = r + semod q and sends y to the verifier.

[0056] 4) The verifier checks x≡α y z e Does mod p hold true? If it does, then the argument is accepted.

[0057] The protocol is based on the discrete logarithmic relation x = α r =α r+se v e =α y v e Mod p allows the prover to prove possession of the private key without disclosing the private key s. However, Schnorr's paper points out that since the challenge e may depend on x, this proof does not satisfy the strict definition of zero-knowledge, but it provides a key idea for non-interactive proofs. Therefore, based on the idea of ​​non-interactive zero-knowledge proofs, this invention combines elliptic curve cryptography (ECC) and hash functions, and applies them to authentication between anonymous IoT devices, enabling authentication and key negotiation in two rounds of communication.

[0058] Embedded Message Authentication Code (EMAC) and Reversible Information Hiding in Cipherfields:

[0059] EMAC is an embedded message authentication code technology. For example... Figure 2 The diagram illustrates the specific implementation process of both standard authentication codes (MACs) and EMACs. By embedding the MAC into encrypted data, EMAC achieves an organic combination of data encryption and authentication. Unlike traditional MACs, EMAC does not transmit the MAC as an additional part of the data; instead, it embeds it within the encrypted data itself. This not only enhances data security by preventing the risk of tampering or truncation of the MAC but also reduces the amount of data during communication. A key feature of EMAC is its use of RDH-ED technology to fuse the two parts of the MAC, thereby ensuring data confidentiality while verifying the data's origin and integrity.

[0060] RDH-ED is a technique that allows additional data to be embedded in encrypted images while protecting image confidentiality and achieving lossless recovery of the original image. By adaptively predicting the most significant bit (MSB) of a pixel and combining it with Huffman coding to compress auxiliary information, it achieves high embedding capacity and lossless recovery, significantly outperforming traditional VRAE and RRBE frameworks. This invention extends it to lightweight IoT protocol scenarios by encrypting sensor images using a pre-negotiated key and leveraging its reversible embedding properties to directly hide authentication information in the ciphertext domain, thereby avoiding the communication overhead of transmitting additional authentication data.

[0061] Example 1

[0062] like Figure 3 As shown, a full-lifecycle lightweight authentication system for the Internet of Things, namely the Full-Lifecycle Lightweight Protocol FCLAP, includes: a registration module, an authentication module, and a communication module.

[0063] First, this embodiment constructs a system model.

[0064] like Figure 1 As shown, the system model comprises two entities: IoT devices and a cloud server (CS). The cloud server manages the registration, authentication, and data processing of all IoT devices. In the field of connected vehicles, the cloud server enables the collection, storage, processing, and analysis of vehicle data. In the medical field, the cloud server provides efficient storage services to medical institutions, enabling them to conduct telemedicine and other related businesses. IoT devices need to register with the cloud server and store relevant public parameters. By using local parameters, device-to-device (D2D) and device-to-cloud (D2C) authentication can be achieved, and session keys can be established. IoT devices use session keys to establish D2D and D2C sessions for data communication. Table 1 shows the definitions of the core symbols used in the protocol proposed in this invention.

[0065] Table 1

[0066]

[0067] The registration module enables IoT devices to send a temporary identity code to the cloud server. The cloud server then generates and returns authentication parameters, which the IoT device verifies and stores to complete the registration process. Each device must register with the cloud server (CS) before deployment in an autonomous environment to ensure seamless execution of subsequent authentication services.

[0068] A further implementation includes a registration module comprising: a temporary identity code generation unit, used to calculate the IoT device D. i Identity ID i and password PW i Generate a temporary identity code (DID)i =H(ID) i ||PW i The data is then sent to the cloud server CS; the device parameter calculation unit is used by the cloud server to calculate authentication parameters using the private key and send them to the IoT device; the specific calculation process is as follows:

[0069] B i =H(ID) cs ||X cs ),

[0070]

[0071] C i =H(DID) i ||X cs ),

[0072]

[0073] V i =H(E) i ||R i ||C i ||DID i ),

[0074] After the calculation is complete, the data {E} will be generated. i ||R i ||V i}Sent to D i .

[0075] Message verification unit for IoT devices D i By calculating the hash function V' of the authentication parameters i =H(E) i ||R i ||C i ||DID i ), determine whether the received authentication parameters have been attacked, and transfer the authentication parameters {E} that have not been attacked to the appropriate location. i ,R i V i The data is stored in the database. The specific registration process for the device is shown in Table 2:

[0076] Table 2

[0077]

[0078] The authentication module is used to authenticate registered IoT devices and negotiate session keys between IoT devices and between IoT devices and cloud servers by using elliptic curve basic operations and hash functions.

[0079] A further implementation involves an authentication module including a device and cloud service authentication unit, used to implement IoT device D... i The authentication and session key negotiation between the cloud server CS and the IoT device D includes the following authentication process: verifying the IoT device D based on the first preset verification conditions. i Identity ID i and password PW i If the result is correct, then generate the first high-entropy random number n1, and calculate N1 = n1G. A i =H(B i ||N i Z i =n1+A i ×C i and will request data {A i Z i E i The data is sent to the cloud server CS via a public channel; the first preset condition includes calculating the DID. i =H(ID) i ||PW i ), And detect V' i =H(E) i ||R i ||C i ||DID i ) = V i Whether it holds true. Where N1 = n1G represents the point-to-point operation between the first high-entropy random number n1 and the base point G of the elliptic curve. Represents the parameter E stored by the i-th IoT device. i The temporary identification code (DID) representing the i-th IoT device. i Perform XOR operation A i =H(B i ||N i H(.) represents hashing the result of the dot product operation with the result of the XOR operation; H(.) represents the hash function; and || represents the concatenation operation. i =n1+A i ×C i This represents performing scalar operations on the intermediate parameters; DID i =H(ID) i ||PW i This is the request message sent by the IoT device to the server during the registration phase, which calculates the hash of the identity and password. and V' i =H(E) i ||R i ||C i ||DIDi ) = V i This is to verify whether the messages sent by the cloud server to IoT devices during the registration phase are complete, because V i and R i Both are sent from the server to the IoT device. If the equation holds true, it means that the parameters sent by the server to the IoT device are accurate. The cloud server CS receives the request data {A}. i Z i E i After that, through B i =H(ID) cs ||X cs Calculate the temporary identity code of IoT devices. Then use your private key to calculate C i =H(DID) i ||X cs The system verifies the integrity of the request data based on the second preset verification condition. If the data is complete, it generates a second high-entropy random number n2, calculates N2 = n2G, and obtains the session key k. shared =H(n2N1||C i ||DID i ) and authentication information Auth = H(DID) i ||C i ||k shared ), and return {N2,Auth} to the IoT device D. i N2 represents the parameter required for the final session key, and Auth represents the authentication information, which is the temporary identity code along with parameter C. i and session key k shared The result of the hash operation; wherein, the second preset verification condition includes the idea of ​​using zero-knowledge proof, that is, through N i =(Z i -A i ×C i G and A' i =H(B i ||N i Check if A'1 = A1 are equal. The calculation formulas for the first and second preset verification conditions are to mix useful information with some random numbers of entropy. Except for Auth, which is the authentication message, the others are intermediate parameters. IoT device D i After receiving {N2,Auth}, calculate the session key k. shared =H(n1N2||C i ||DID i ), verify Auth' = H(DID) i ||C i ||k sharedIf the condition is met, it means that the {N2,Auth} received by the IoT device was generated by the cloud server, thus completing the authentication between the IoT device and the cloud server and the establishment of the session key. The specific steps of this stage are described in Table 3.

[0080] Table 3

[0081]

[0082] A further implementation includes an authentication module that further comprises a device-to-device authentication unit for authenticating IoT devices and negotiating session keys. The specific authentication process includes: based on the first IoT device D... i Identity ID i and password PW i Calculate the temporary identification code (DID) of the first IoT device. i =H(ID) i ||PW i Generate a third high-entropy random number m1, and calculate M. i =m1G, A i =H(B i ||N i ), And request data {A i Z i ,F i}Sent to the second IoT device D j Second IoT device D j Received request data {A i Z i ,F i After that, calculate Get B j , through the received F i get By calculating M i =(Z i -A i ×C i G gets M i Post-verification of A' i =H(B j ||M i ) = A i If true, generate a third high-entropy random number m2 and calculate M. j =m2G, obtain session key k share =H(m2M) i ||B i ) and authentication information Auth = H(B j ||C i ||k shared), will message {M j Auth} is returned to the first IoT device D i Among them, E j 、R j Each represents a parameter stored in the j-th device, DID j The temporary identification code for the j-th device; the first IoT device D i Received from the second IoT device D j The returned message {M j ,Auth}, using M j Calculate session key k shared =H(m1M) j ||B i ), and authenticate the equation Auth' = H(B i ||C i ||k share If the condition is met, the authentication between IoT devices and the establishment of the session key are completed. Table 4 describes the specific steps of this D2D stage.

[0083] Table 4

[0084]

[0085] The communication module is used to encrypt images collected by the sending IoT device using a negotiated session key, generate ciphertext images, and transmit authentication information embedded in the ciphertext images via an embedded message verification code. The receiving IoT device extracts and verifies the integrity of the ciphertext images.

[0086] A further embodiment of the invention includes a communication module comprising:

[0087] Encryption unit, used for transmitting IoT devices D i Using session key k shared The acquired image Fig is encrypted pixel by pixel to obtain the ciphertext image P; specifically, device D i First, use the session key k shared The image is encrypted using a stream cipher to generate a pseudo-random matrix. The original image Fig is encrypted pixel-by-pixel to generate a ciphertext image, and the process is then performed. The encryption process is as follows:

[0088]

[0089] Where r is based on k shared The generated pseudo-random stream.

[0090] The authentication information generation unit is used to calculate the authentication information Auth = H(Fig||B) iUsing the ciphertext field embedding algorithm, we calculate M = Emb(P, Auth) and embed the authentication information Auth = H(Fig||B). i The encrypted image M is embedded into the encrypted image P, and the encrypted data M is transmitted to the receiving IoT device. Specifically, a tag map is generated through multi-MSB prediction. Auxiliary information is compressed using Huffman coding, and the reserved most significant bit (MSB) of the encrypted pixel is adaptively replaced.

[0091]

[0092] Then message M is transmitted to D. j b s Let M(i,j) represent the s-th bit of radix information to be embedded (i.e., the bits of authentication or auxiliary information), M(i,j) refer to the pixel value of the ciphertext image after embedding the information, P() refer to the pixel value of the original ciphertext image, and t refer to the tag value of the current pixel. The number of bits that can be embedded is predicted by MSB. Using the above formula, the last 8-t bits of the original ciphertext pixel are retained, and the first t+1 bits are replaced with the information bits b0~bt to be embedded, thereby realizing the reversible embedding of authentication information in the encrypted domain.

[0093] The authentication information extraction unit is used for receiving IoT devices D. j Extract the ciphertext image P and the embedded authentication information Auth = H(Fig||B) from the ciphertext M. i The calculation (P,Auth) = Extr(M) is performed, and the extraction process relies on Huffman coding rules to recover the tag and locate the embedding bit.

[0094] Decryption unit, used to utilize session key k shared Decrypt the ciphertext image P and calculate... By determining Auth'=H(Fig||B) i The integrity of the received message is verified by checking whether the condition is true or false.

[0095] A further implementation includes an analysis module for performing security and performance analysis on the full-lifecycle lightweight authentication system; wherein the security analysis includes informal security analysis and formal security analysis.

[0096] In this embodiment, the protocol is formally analyzed based on the Real-Or-Random (ROR) model, and informal analysis is performed simultaneously. The security of the text protocol is analyzed using informal analysis, and its ability to resist various attack types is discussed: (1) Perfect forward and backward security: In the protocol of this invention, the generated session key is calculated by k... shared =H(n2N1||C i ||DIDi ) and k shared =H(m2M) i ||B i The random number is obtained by using a newly generated random number for each calculation. The key negotiation is based on the discrete logarithm problem on an elliptic curve, so the attacker cannot obtain the random number {n1n2m1m2}. Even if the key of this communication session is leaked, the attacker cannot deduce the keys in previous sessions and future sessions, and cannot crack more communication content. Therefore, the protocol of this invention satisfies complete forward secrecy. (2) Mutual authentication: During the registration phase, the device uses a hash to bind the private key of the cloud server and the user's identity information together. Then the server returns a series of parameters to the device and stores them securely. The user receives the message and verifies V'. i =H(E) i ||R i ||DID i ) = V i The validity of the message is checked to determine its completeness. During the D2C authentication phase, the device will... i Z i E i The key is sent to CS, who uses their private key to calculate B. i =H(ID) cs ||X cs ), and then through calculation Obtain the user's identity information to calculate C i =H(DID) i ||X cs Because only the server possesses the private key, therefore N i =(Z i -A i ×C i )G,A' i =H(B i ||N i If equation A'1 = A1 holds, then the correctness of the user's identity can be proven. After receiving the message, the user calculates the session key k. shared =H(n1N2||C i ||DID i And verify Auth' = H(DID) i ||C i ||k shared If the condition is met, it means the message was sent by CS, because the C key contains the CS key. i =H(DID) i ||X cs Only the server can calculate this. During the D2D authentication phase, device D... i {A i Zi ,F i}Sent to D j D j Through calculation Obtaining Ci enables the completion of M. i =(Z i -A i ×C i )·G obtains Mi, and passes the certification A' i =H(B j ||M i ) = A i Whether it is true or not can prove the request of device D i The server has been registered and the integrity of the data during transmission has been verified, completing one-way authentication. j By calculating the session key k share =H(m1M) j ||B i ) and the authentication message Auth' = H(B i ||C i ||k share Whether the completion of the D test is true or not i (3) Device anonymity: During the authentication process, the user uses a temporary identity identifier (DID) generated during registration. The CS does not store any user information, and the one-way hash function algorithm cannot obtain the user's real identity ID by reverse calculation. Therefore, even if an attacker can gain control of the exchange of messages by eavesdropping, they cannot obtain the device's real identity. (4) Session key sharing: In device-to-control center (D2C) authentication, the device D i The control center (CS) calculates a shared session key, k. shared =H(n2||N) i ||C i ||DID i )=k shared =H(n1||N2||C i ||DID i In addition, device D i With D j Shared session keys benefit from k shared =H(m2||M i ||B i )=k shared =H(m1||M j ||B jTherefore, the proposed protocol supports secure session key sharing. (5) Replay attack: Since the random numbers n1, n2, m1, m2, etc. used in the authentication process are all fresh, all messages transmitted in the channel for each session are different. Attackers use old packets to launch replay attacks, and CS and IOT devices will lose sessions due to insufficient freshness of the received information. Therefore, this protocol can resist replay attacks. (6) Man-in-the-middle attack: During the registration and authentication process of this protocol, attackers can obtain all messages in the public channel, but cannot obtain any useful information from these messages. We can guarantee mutual authentication during the communication process, so we can resist man-in-the-middle attacks. (7) Denial-of-service attack: In the scheme proposed in this invention, each authentication communication process is accompanied by verification information. If the verification fails, the communication will stop. If the attacker keeps sending error messages that cause authentication failure, the communication will be rejected, thereby resisting denial-of-service attacks. (8) Impersonation attack: During the device and server authentication phase, the attacker impersonates the device to generate a fake {A i Z i E i}, sent to the server, and the server can calculate B using its own private key. i =H(ID) cs ||X cs ), C i =H(DID) i ||X cc ), through authentication A' i =H(B i ||N i ) = A i This is valid. Because the fake data server will verify that the authentication failed, the attacker cannot impersonate D. i The authentication key is negotiated with the server. Similarly, if an attacker impersonates the server, they cannot obtain the correct Auth = H(DID). i ||C i ||k share The device cannot authenticate it either. Between devices, because the message sent is {A} i Z i ,F i An attacker can impersonate any device to send messages to another party, because each device contains a B sent by the server. i The imposter did not have B. i If we judge A' i =H(B j ||M i ) = A iIf this is not true, it means the message has been attacked by an attacker, and the imposter cannot obtain authentication. (9) Device theft attack: In this scheme, the parameters stored by the IoT device are {R i ||E i ||V i Therefore, even if the device is stolen, the attacker cannot obtain the DID without knowing the ID||PW, and thus cannot communicate with the server. (10) Server theft attack: During the registration phase, the server does not store any information about the device in the protocol designed in this invention, so even if the attacker breaks through the server's database, they cannot obtain the device information. (11) Time synchronization attack: In the solution of this invention, we use random numbers to ensure the freshness of the data instead of timestamps to defend against clock synchronization attacks, thus resisting time synchronization attacks.

[0097] Formal analysis employs the password authentication key exchange security model ROR.

[0098] In this embodiment, the following entities are set in the model: the device Devy participating in the protocol and its identity ID, adversary A, and cloud server CS.

[0099] Taking D2D authentication as an example, A can use a random oracle (RO) to generate a limited number of queries to simulate an actual attack. The main capabilities include using a random oracle to simulate protocol interactions and attacker actions.

[0100] In the ROR model, attackers can typically perform operations such as Execute (passively listening to protocol interactions), Send (actively sending or tampering with messages), and Test (attempting to distinguish between real and random keys), but are generally not allowed to perform Reveal (directly obtaining the session key). Attacker's objective: This describes the attacker's intended goal, such as obtaining the session key or disrupting the protocol's authentication process.

[0101] 1)Execute(D i D j This query allows adversary A to launch an eavesdropping attack during communication between two users, enabling them to query and return D. i and D j Messages transmitted over a public channel (simulating a passive attack to obtain communication messages from honest participants).

[0102] 2) Send(D i D j (m): Through this query, A can launch proactive attacks including intercepting, trimming, modifying, forging, and replaying messages to user D. i Or D j And able to Di Or D j The message output after receiving message m is received.

[0103] 3) Corrupt(D) i This query allows attacker A to obtain parameter information that has been stored on the device for a long time.

[0104] 4) Test: If A executes the query, the coin b is flipped. If b = 0, a random key of the same size as sk is returned to A. If b = 1, A obtains the correct session key sk.

[0105] 5) hash(m) query: If A executes this query, it can input a string m to obtain its hash value, which can be used to launch an active attack on the user.

[0106] Attacker A's victory is defined as SUCC. Definition: Adv Π ake (A)=|2Pr[β'=β]-1|, where P r [β'=β] is the probability that the attacker correctly guesses b, if Adv Π ake If (A) is negligible, then the protocol is considered secure.

[0107] In D2D authentication, there are

[0108]

[0109] Where q s q e q h These represent the number of queries for Send, Execute, and Hash, respectively. A ECDHP Is this a possibility for A to resolve ECHDHP? h It is the length of the hash string.

[0110] Adv Π ake (A) = |2Pr[SUCC]-1| where SUCC represents the position where A succeeds.

[0111] Proof: The theorem is proved using game sequence GM, defining five safe games GM0-GM5, and events are... Defined as "A successfully guesses the middle GM" i "coin b"

[0112] GM0: In the random oracle, the simulation of GM0 is the same as a real attack, without executing any queries. Therefore, the probability of A attacking D2D is:

[0113]

[0114] GM1: GM1 adds an Execute query to launch eavesdropping attacks on the protocol. Otherwise, GM1 is identical to GM0. A can only retrieve messages {A}. i Z i ,F i M j After GM1 is completed, A attempts to obtain the key through a Test query, while {B} i B j The sequence {m1, m2} is kept secret from A, therefore the probability of GM1 succeeding is the same as that of GM0, then we have

[0115]

[0116] GM2: Building upon GM1, GM2 involves A launching a further active attack, performing hash and send queries to attempt hash collisions and message collisions transmitted over public channels. Based on the birthday paradox, when N=2... m The collision probability in n samplings out of 10 possible values ​​is approximately Therefore, the probability of a hash collision can be defined as For messages on the transmission channel, a session key is established using two random numbers m1 and m2 of length L. A generates message transcripts through Send and Execute queries. The total number of interactions accumulated from these two types of queries is qs + qe. Each interaction is equivalent to a sampling, therefore, the probability of a birthday paradox and a collision is... Then we get:

[0117]

[0118] GM3: If A guesses the correct message without performing a hash lookup, otherwise the game is the same as GM2, this additional case:

[0119]

[0120] GM4: In this game, A can perform a corruption query based on GM3. Assuming A can obtain the possibility of long-term information stored on the device, A's probability of winning in this game is the probability of obtaining the DID, i.e., guessing ID||PW. In this case:

[0121]

[0122] GM5: Based on GM5, A can also guess C. iThat is, through Having obtained the DID, the game is otherwise identical to GM4. The probability of successfully querying A via Corrupt is:

[0123]

[0124] GM6: In GM5, A attempts to directly guess the session key sk. If A has the possibility of successfully solving ECDHP, it can calculate m1 and m2 by stealing information from the public channel. Even if it can calculate mM, it cannot obtain kshare. It also needs to complete a successful hash collision to obtain B. Therefore:

[0125]

[0126] After playing these games, the attacker failed to compromise the protocol and could only guess the key through a text query, thus still unable to distinguish correctness. Therefore:

[0127]

[0128] The above formula is derived as follows:

[0129]

[0130] In conclusion, the D2D authentication proposed in this invention is semantically safe. Similarly, the D2C authentication is also semantically safe.

[0131] This embodiment also includes an analysis of the performance of the three phases of the FCLAP protocol.

[0132] This includes storage costs during the registration phase, computational and communication costs during the authentication phase, and communication costs during the communication phase. Compared to some existing solutions, the FCLAP protocol has significant performance advantages. This embodiment is equipped with... Core TM Various operations were simulated and tested on a 64-bit Windows 11 system with an i5-1135G7 processor (base frequency 2.40GHz, maximum turbo frequency 2.42GHz).

[0133] To ensure fairness, the lengths of identity, random number, hash digest, and timestamp are defined as 160 bits, 160 bits, 160 bits, and 32 bits, respectively. A 160-bit elliptic curve cryptosystem (ECC) is used, and the elliptic curve point P is defined as (160 + 160 = 320 bits), where x and y are the x and y coordinates of point P, respectively.

[0134] For the analysis of computational overhead, the operation time of `x` and `y` is negligible compared to other operations. Each operation involved was performed 1000 times, and the average time was calculated in milliseconds. Table 5 shows the average time consumed for each operation:

[0135] Table 5

[0136]

[0137] T h T represents the time required to compute the hash. pm and T pa It is the time required for dot product and dot addition on an elliptic curve, T. sym It is the time required for symmetric encryption, T ee and T ed This refers to the time required for ECC encryption and decryption operations. Therefore, it can be concluded that fewer hash functions and elliptic curve cryptography operations can effectively reduce the computational overhead of devices in LAP.

[0138] This invention is compared on an equal footing with other similar technologies:

[0139] Technology 1: Efficient and privacy-preserving authentication scheme for wireless body area networks. This is a certificate-free anonymous authentication method for wireless body area networks based on elliptic curve cryptography. Its features include: using a semi-private key issued offline by the network administrator, the client and application complete mutual authentication and establish a session key through two rounds of messages; the process only uses ECC dot multiplication and hash operations, does not perform bilinear pairing, and does not require an online trusted third party or a stored verification table.

[0140] Technology 2: A lightweight cloud-assisted identity-based anonymous authentication and key agreement protocol for secure wireless body area network (WBAN). This technology is a lightweight cloud-assisted anonymous dual authentication key agreement method used between resource-constrained wireless body area network (WBAN) sensors and the cloud, employing 3 elliptic curve multiplication and 2 hash operations. It achieves anonymous login while generating a secure session key in one step, minimizing computational and storage overhead.

[0141] Technology 3: A provably secure and practical puf-based end-to-end mutual authentication and key exchange protocol for IoT. This method combines "chip fingerprint PUF" with "certificate-free elliptic curve cryptography" into one, allowing any two IoT devices to authenticate each other offline and negotiate a one-time key session using only three short messages, which is both resistant to physical theft and resource-saving.

[0142] Technology 4: A lightweight authentication and key exchange protocol with anonymity for IoT. This technology uses one ECC encryption, one symmetric encryption, and four hashes to package the device identity, password, random number, and timestamp, enabling two-way anonymous authentication and establishing a one-time key session key between resource-constrained IoT terminals and the cloud.

[0143] Technology 5: Provable secure anonymous device authentication protocol in iotenvironment. This technology hashes "password + biometrics" into a one-time identity token. It can simultaneously complete two-way anonymous authentication between device and cloud server, and between devices, and negotiate session keys through two ECC dot product and hash. No server needs to store any privacy information.

[0144] Technology 6: An anonymous device-to-device authentication protocol using ECC and self-certified public keys usable in internet-based autonomous devices. This technology is based on a two-round anonymous device authentication method using self-certified ECC: After registration, each device completes two rounds of interaction (168 bytes of communication) using only 6 dot multiplications, 2 dot additions, and 8 hashes to negotiate a one-time session key that is resistant to key leakage spoofing, replay attacks, and man-in-the-middle attacks. The entire process requires no third party online, and the identity remains completely anonymous.

[0145] Technology 7: A secure anonymous D2D mutual authentication and key agreement protocol for IoT. This technology is a lightweight D2D anonymous two-way authentication and key agreement method for IoT: the device only exchanges messages with an offline trusted server once through a public channel during the registration phase. In two rounds of interaction, anonymous authentication is completed using temporary identity, ECC dot multiplication and hashing, and a one-time session key that is resistant to key leakage spoofing, replay, man-in-the-middle, and device capture is negotiated. It also supports public and private key updates under public channels without the need for an online third party.

[0146] Storage overhead during registration phase:

[0147] Storage overhead refers to the memory space required for a device to pre-store confidential data before authentication. The device sends a registration request to the Control Center (CS), which then distributes relevant parameters to the device; these parameters do not change over time. In the FCLAP protocol, the CS does not store parameters during the registration phase, while the device stores the parameters assigned by the CS. Therefore, the total storage overhead of this scheme is only 480 bits. As shown in Table 6, the notation in the table is consistent with that used in the original paper. Compared with other protocols, it can be seen that our protocol has lower storage overhead.

[0148] Table 6

[0149]

[0150] Certification phase overhead:

[0151] Computational overhead:

[0152] As shown in Tables 7 and 8, FCLAP's computational overhead is superior to other schemes in both D2C and D2D processes. In the D2C phase, our scheme involves five hash operations and two dot product operations on the client side, and five hash operations and three dot product operations on the cloud server. Therefore, the overall computational overhead is superior to schemes in other literature. Similarly, our scheme also has advantages over similar schemes in the D2D process.

[0153] Table 7

[0154]

[0155] Table 8

[0156] protocol Total calculation Time elapsed (ms) Overhead (bit) Technology 3 <![CDATA[12T h +14T pm +4T pa ]]> 8.780 3200 Technology 5 <![CDATA[8T h +6T pm ]]> 3.426 2176 Technology 6 <![CDATA[6T h +8T pm +2T pa ]]> 4.936 1504 Technology 7 <![CDATA[14 h +8T pm ]]> 5.586 1344 This plan <![CDATA[8T h +5T pm ]]> 2.880 1120

[0157] Communication overhead:

[0158] Regarding the communication overhead of the proposed protocol, in the D2C process, each message requires (160+320+160) = 640 bits, and each message requires (160+320) = 480 bits, therefore the total communication overhead is 1120 bits. Similarly, in the D2D stage, the communication overhead of this invention is also 1120 bits. As can be seen from Tables 7 and 8, compared with other protocols, the communication cost of this invention is lower. A comparison of communication and computation overhead is provided below. Figure 4 , Figure 5 As shown.

[0159] Communication phase overhead:

[0160] The analysis will cover the communication overhead required to achieve verifiable communication, such as the transmission of images. Figure 6 As shown, the image is encrypted using a negotiated key, and additional data (such as authentication messages) is embedded into the ciphertext image based on an Embedded Message Authentication Code (EMAC). The receiver can extract the additional information and recover the original image without loss. This embodiment was tested on six images with an original size of 2,097,152 bits. As shown in Table 9, the maximum embedding size reached 3.3 bpps, and the communication overhead was reduced by approximately 30% compared to traditional authenticated transmission. The experiments demonstrate that EMAC-based authenticated transmission can effectively reduce communication overhead and has significant advantages in constrained IoT environments.

[0161] Table 9

[0162] picture raw bits Maximum embedding amount Embedding rate Extract total bits Reduce expenses airplane 2,097,152 1,005,663 3.84 3,102,815 32.41 hills 2,097,152 775,956 2.96 2,873,108 27.01 jet plane 2,097,152 891,780 3.40 2,988,932 29.83 Boat 2,097,152 750,417 2.86 2,847,569 26.35 people 2,097,152 958,377 3.66 3,055,529 31.37 houses 2,097,152 673,195 2.57 2,770,347 24.30

[0163] Example 2

[0164] This invention also provides a lightweight authentication method for the entire lifecycle of the Internet of Things (IoT). The applied system includes: enabling IoT devices to send a temporary identity code to a cloud server; generating and returning authentication parameters through the cloud server; verifying and storing the authentication parameters to complete the registration of the IoT device; for registered IoT devices, using elliptic curve basic operations and hash functions to achieve identity authentication and session key negotiation between IoT devices and between IoT devices and the cloud server; encrypting an image collected by the sending IoT device using the negotiated session key to generate a ciphertext image; embedding authentication information into the ciphertext image via an embedded message verification code for transmission; and extracting and verifying the integrity of the ciphertext image by the receiving IoT device. A further embodiment involves the following method for registering IoT devices: calculating the IoT device's identity ID and password; generating a temporary identity code and sending it to the cloud server; the cloud server calculating authentication parameters using a private key and sending them to the IoT device; and the IoT device determining whether the received authentication parameters have been attacked by calculating the hash function of the authentication parameters, and storing the unattacked authentication parameters in a database.

[0165] The lightweight key negotiation process of this invention, which involves registration and authentication, achieves key negotiation quickly while ensuring security, with minimal communication and computational overhead. The communication process utilizes different embedding algorithms to embed additional data during communication using the negotiated key, thus making the entire process lightweight.

[0166] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the scope of the present invention. Various modifications and improvements made to the technical solutions of the present invention by those skilled in the art without departing from the spirit of the present invention should fall within the protection scope defined by the claims of the present invention.

Claims

1. A lightweight, end-to-end authentication system for the Internet of Things (IoT), characterized in that, include: The registration module is used to enable IoT devices to send a temporary identity code to the cloud server, generate and return authentication parameters through the cloud server, verify and store the authentication parameters of the IoT devices, and complete the registration of the IoT devices. The authentication module is used to authenticate registered IoT devices and negotiate session keys between IoT devices and between IoT devices and cloud servers by using elliptic curve basic operations and hash functions. The communication module is used to encrypt images collected by the sending IoT device using a negotiated session key, generate ciphertext images, and transmit authentication information embedded in the ciphertext images via an embedded message verification code. The receiving IoT device extracts and verifies the integrity of the ciphertext images.

2. The system according to claim 1, characterized in that, The registration module includes: The temporary identity code generation unit is used to calculate the identity ID and password of IoT devices, generate a temporary identity code, and send it to the cloud server. The device parameter calculation unit is used by the cloud server to calculate authentication parameters using a private key and send them to the IoT device. The message verification unit is used by IoT devices to determine whether the received authentication parameters have been attacked by calculating the hash function of the authentication parameters, and to store the authentication parameters that have not been attacked to the database.

3. The system according to claim 2, characterized in that, The authentication module includes a device and cloud service authentication unit, used to realize authentication between IoT devices and cloud servers and session key negotiation. The specific authentication process includes: Based on the first preset verification condition, verify the correctness of the IoT device's identity ID and password. If correct, generate a first high-entropy random number n1, and calculate N1 = n1G. A i =H(B i ||N i Z i =n1+A i ×C i and will request data {A i Z i E i The data is sent to the cloud server via a public channel; where N1 = n1G represents the point-to-point operation between the first high-entropy random number n1 and the base point G of the elliptic curve. Represents the parameter E stored by the i-th IoT device. i The temporary identification code (DID) representing the i-th IoT device. i Perform XOR operation A i =H(B i ||N i H(.) represents hashing the result of the dot product operation with the result of the XOR operation; H(.) represents the hash function; and || represents the concatenation operation. i =n1+A i ×C i This represents performing scalar operations on the intermediate parameters; The cloud server received the requested data {A} i Z i E i After that, the temporary identity code of the IoT device is calculated and the integrity of the requested data is verified based on the second preset verification condition. If the data is complete, a second high-entropy random number n2 is generated, N2 = n2G is calculated, and the session key k is obtained. shared =H(n2N1||C i ||DID i ) and authentication information Auth = H(DID) i ||C i ||k shared The system will return {N2,Auth} to the IoT device; where N2 represents the parameters required for the final session key, and Auth represents the authentication information, including the temporary identity code and parameter C. i and session key k shared The result of the hash operation; After receiving {N2,Auth}, the IoT device calculates the session key k. shared =H(n1N2||C i ||DID i ), verify Auth' = H(DID) i ||C i ||k shared If the condition is met, it means that the {N2,Auth} received by the IoT device was generated by the cloud server, thus completing the authentication between the IoT device and the cloud server and the establishment of the session key.

4. The system according to claim 2, characterized in that, The authentication module also includes a device-to-device authentication unit for authenticating IoT devices and negotiating session keys. The specific authentication process includes: Based on the identity ID and password of the first IoT device, calculate the temporary identity code of the first IoT device, generate a third high-entropy random number m1, and calculate M. i =m1G, A i =H(B i ||N i Z i =n1+A i ×C i , And request data {A i Z i ,F i Send it to the second IoT device; The second IoT device receives the request data {A} i Z i ,F i After that, calculate Get B j , through the received F i get By calculating M i =(Z i -A i ×C i G gets M i Post-verification of A' i =H(B j ||M i ) = A i If true, generate a third high-entropy random number m2 and calculate M. j =m2G, obtain session key k share =H(m2M) i ||B i ) and authentication information Auth = H(B j ||C i ||k shared ), will message {M j Auth} is returned to the first IoT device; where E j 、R j Each represents a parameter stored in the j-th device, DID j This is the temporary identification code for the j-th device; The first IoT device receives the message {M} returned by the second IoT device. j ,Auth}, using M j Calculate session key k shared =H(m1M) j ||B i ), and authenticate the equation Auth' = H(B i ||C i ||k share If the authentication is successful, the authentication between IoT devices and the establishment of session keys will be completed.

5. The system according to claim 1, characterized in that, The communication module includes: Encryption unit, used by the transmitting IoT device to utilize session key k shared The acquired image Fig is encrypted pixel by pixel to obtain the ciphertext image P; The authentication information generation unit is used to calculate the authentication information Auth = H(Fig||B) i Using the ciphertext field embedding algorithm, calculate M = Emb(P, Auth) and then embed the authentication information Auth = H(Fig||B). i Embed into the ciphertext image P and transmit the ciphertext M to the receiving IoT device; where Emb(,) represents the embedding operation. The authentication information extraction unit is used by the receiving IoT device to extract the ciphertext image P and the embedded authentication information Auth=H(Fig||B) from the ciphertext M. i Calculate (P,Auth) = Extr(M), where Extr(,) represents the extraction operation; Decryption unit, used to utilize session key k shared Decrypt the ciphertext image P and calculate... By determining Auth'=H(Fig||B) i The integrity of the received message is verified by checking whether the condition is true or false; where Dec represents the decryption operation.

6. The system according to claim 1, characterized in that, It also includes an analysis module for performing security and performance analysis on the full-lifecycle lightweight authentication system; wherein the security analysis includes informal security analysis and formal security analysis.

7. A lightweight authentication method for the entire lifecycle of the Internet of Things, employing the system described in any one of claims 1-6, characterized in that, include: The IoT device sends a temporary identity code to the cloud server, the cloud server generates and returns authentication parameters, the IoT device verifies and stores the authentication parameters, and the IoT device registration is completed. For registered IoT devices, elliptic curve basic operations and hash functions are used to achieve identity authentication and session key negotiation between IoT devices and between IoT devices and cloud servers. Images collected by the sending IoT device are encrypted using a negotiated session key to generate ciphertext images. Authentication information is then embedded into the ciphertext images and transmitted via an embedded message verification code. The receiving IoT device extracts and verifies the integrity of the ciphertext images.

8. The method according to claim 7, characterized in that, Methods for registering IoT devices include: Calculate the identity ID and password of the IoT device, generate a temporary identity code and send it to the cloud server; The cloud server uses the private key to calculate authentication parameters and sends them to the IoT device; IoT devices determine whether the received authentication parameters have been attacked by calculating a hash function of the authentication parameters, and store the authentication parameters that have not been attacked in the database.

Images