Lattice-based lightweight provable security multi-factor authentication key exchange method for smart electric meter

Abstract

The invention provides a lattice-based lightweight provable security multi-factor authentication key exchange method for an intelligent electric meter, and belongs to the technical field of communication security. The problems that the existing MFAKE protocol is difficult to realize real three-factor security and has a signal leakage risk are solved; the technical scheme adopted to solve the technical problem is as follows: three-factor authentication of password + biological feature + smart card is combined, quantum computing attack can be resisted based on the RLWE problem, and polynomial multiplication operation with dense computing is transferred from a smart electric meter with limited resources to an NAN gateway with stronger computing power by adopting asymmetric computing optimization, so that the security of the smart electric meter is improved. The calculation burden of low-power-consumption equipment such as an intelligent electric meter is remarkably reduced, and the actual time consumption of polynomial multiplication is reduced through modular operation optimization and NTT acceleration technologies; and meanwhile, the security of the protocol is strictly proved under a random oracle model, the calculation and communication overhead of the intelligent electric meter is remarkably reduced, and an efficient and safe solution is provided for the intelligent electric meter.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of information security, in particular to a lattice-based lightweight provably secure multi-factor authenticated key exchange method for smart meters. BACKGROUND

[0002] With the growth of energy demand and the intelligent transformation of power systems, smart grids gradually replace traditional power grids and become the core infrastructure of future energy distribution. However, the communication between smart meters (SMs) and neighborhood area network (NAN) gateways faces security threats such as identity spoofing, data tampering, and man-in-the-middle attacks due to resource constraints and the vulnerability of wireless / wired channels, which may undermine the stability of the power grid and user privacy.

[0003] In order to ensure secure communication in smart grids, authenticated key exchange (AKE) protocols have been widely used to enable smart meters and NAN gateways to establish session keys for encrypted communication. Current mainstream authenticated key exchange (AKE) protocols rely on traditional public-key cryptography (such as RSA, ECC), but quantum computing (such as Shor's algorithm) can efficiently break these schemes. In recent years, lattice-based AKE protocols can resist quantum attacks, but the computational overhead is symmetrical, which leads to an excessive burden on resource-constrained smart meters. In addition, multi-factor AKE (MFAKE) protocols, which include identity verification factors such as passwords, biometric technology, smart cards, or mobile devices, have become an important research area. Compared with one-factor and two-factor AKE protocols, MFAKE protocols provide significant security advantages. However, many MFAKE protocols are difficult to achieve true three-factor security and have the risk of signal leakage. SUMMARY

[0004] To solve the above technical problems, the application provides a lattice-based lightweight provably secure multi-factor authenticated key exchange method for smart meters.

[0005] The technical scheme adopted by the application is as follows: a lattice-based lightweight provably secure multi-factor authenticated key exchange method for smart meters, comprising the following steps:

[0006] In the registration phase, the smart meter sends a registration request to the neighborhood gateway through a secure channel registers, and then sends a registration request to the neighborhood gateway issues a smart card , specifically including:

[0007] Step 1.1: According to the user / smart meter The identity, password, and biometrics are used to calculate the public key, biometric key, and hash value containing the identity, password, and biometrics, and the identity, public key, and hash value are sent to the neighborhood gateway through a secure channel. ;

[0008] Step 1.2: After receiving the request, the relevant intermediate data is calculated and the identity, timestamp and list of false authentication attempts are recorded in the registry. The relevant intermediate data is written into the new smart card and sent to the smart meter through a secure channel. ;

[0009] Step 1.3: Smart Meter After receiving the data from the new smart card, the corresponding parameters are stored in the new smart card after a series of calculations;

[0010] The specific process of login and identity authentication is as follows:

[0011] Step 2.1, Login Request: User After inserting the smart card and entering the identity, password and biometric key, a login request is sent to the neighborhood gateway after a series of calculations. ;

[0012] Step 2.2, Gateway Verification: The gateway verifies the login request and sends a response parameter including the session key to the smart meter based on a series of calculations after the verification is passed. ;

[0013] Step 2.3, Session Key Generation: Smart Meter The session key is calculated based on the received response parameters and verified to be the same as the received session key. If they are the same, the smart card parameters are updated.

[0014] Furthermore, it also includes a password and biometric update phase, during which users can update their passwords and biometrics independently without the need to Interaction.

[0015] Furthermore, before the registration phase, the neighborhood gateway generates global system parameters ,in is a large prime number, is a positive integer, is a polynomial ring, is a random matrix, is a discrete Gaussian distribution as the error distribution, is the public key, is a hash function.

[0016] Furthermore, the specific implementation process of step 1.1 is as follows:

[0017] (1) User / Smart Meter Selects identity , password , and enters biometric ;

[0018] (2) Selects random number , generates sample , calculates:

[0019] ;

[0020] ;

[0021] ;

[0022] Wherein is the "fuzzy key" of the biometric, is the auxiliary data for error correction;

[0023] (3) Sends the registration request to through a secure channel.

[0024] Further, step 1.2 is implemented as follows:

[0025] (1) Upon receiving the request, generates random number and timestamp , calculates:

[0026] ;

[0027] ;

[0028] ;

[0029] (2) Records in the registration table, and writes to the new smart card , and sends it to through a secure channel.

[0030] Wherein is the list of stored false authentication attempts.

[0031] Further, step 1.3 is implemented as follows:

[0032] (1) Upon receiving Then, generate a random number and ,calculate:

[0033] ;

[0034] ;

[0035] ;

[0036] ;

[0037] ;

[0038] ;

[0039] ;

[0040] (2) Smart card The following parameters are stored:

[0041] ;

[0042] in is the biometric key generation algorithm, It is the biometric key regeneration algorithm.

[0043] Furthermore, the specific implementation process of step 2.1 login request is as follows:

[0044] (1) User Insert smart card and enter and ,in and It is the password and biometrics that the user actively enters when logging in, used for authentication, and calculates:

[0045] ;

[0046] ;

[0047] ;

[0048] ;

[0049] ;

[0050] (2) Verification and Are they the same? If , terminate the login, otherwise continue (3);

[0051] (3) Generate random samples ,calculate:

[0052] ;

[0053] ;

[0054] ;

[0055] ;

[0056] ;

[0057] ;

[0058] ;

[0059] (4) Send a login request Give .

[0060] Furthermore, the specific process of step 2.2 gateway verification is as follows:

[0061] (1) calculate:

[0062] ;

[0063] ;

[0064] ;

[0065] ;

[0066] ;

[0067] (2) Check whether it exists in the registry If it does not exist, terminate the session; otherwise, verify Whether and equal;

[0068] (3) If the verification is successful, calculate and with the received If the comparison fails and The list is not full, Add to the list; otherwise suspend the smart card;

[0069] (4) Generate a new random number ,calculate:

[0070] ;

[0071] ;

[0072] Generate random samples ,calculate:

[0073] ;

[0074] ;

[0075] ;

[0076] ;

[0077] ;

[0078] ;

[0079] ;

[0080] (5) Send response Give .

[0081] Furthermore, the specific process of generating the session key in step 2.3 is as follows:

[0082] (1) calculate:

[0083] ;

[0084] ;

[0085] ;

[0086] ;

[0087] ;

[0088] (2) Verification Whether and Same, if the same, select an integer calculate:

[0089] ;

[0090] ;

[0091] ;

[0092] (3) Update smart card parameters .

[0093] Further, a formal analysis phase is also included, which proves the provable security of the method based on the Random Oracle model.

[0094] The present application has the following beneficial effects over the prior art:

[0095] (1) Based on the RLWE (Ring Learning with Errors) problem, the protocol can resist quantum computing attacks (such as Shor algorithm), and the security of the protocol is verified through formal proof (Random Oracle Model, ROM), ensuring that it can remain secure in the era of quantum computing;

[0096] (2) Asymmetric computation optimization is adopted, which transfers the computationally intensive polynomial multiplication operation from the resource-constrained smart meter (SM) to the NAN gateway with stronger computing power, significantly reducing the computational burden of low-power devices such as smart meters, and through modular operation optimization and NTT acceleration technology (Number Theorem Transform), the actual time consumption of polynomial multiplication is reduced;

[0097] (3) Combined with password + biometric + smart card three-factor authentication, the protocol extracts the fuzzy key of biometric features through Gen(·) and Rep(·) algorithms, avoiding direct storage of original biometric data, even if the attacker obtains two factors, it is also impossible to pass the authentication, and the password and biometric features can be updated locally without interaction with the gateway, and the protocol provides special protection against offline password guessing attacks, with higher security;

[0098] (4) Supports entity anonymity (temporary identity is generated for each session , hides the real identity of the user, preventing long-term tracking), forward security (even if the long-term key (such as ) is leaked, the historical session key is still secure, as the session key is generated based on a temporary random number ( , ) ), and effectively resists replay attacks (through timestamp and counter to ensure message freshness), formal security proof (defines a security game (Game 0–6 ) under the ROM model, proves that the protocol meets semantic security through differential lemma and probability analysis), man-in-the-middle attacks, and anti-leakage attacks (introduces random numbers and dynamic update mechanism to ensure that even if the signal value is leaked, the attacker cannot derive the long-term key);

[0099] (5) Using fuzzy verifier and Honeywords technology. The fuzzy verifier stores the hash value of the password instead of the plain text to prevent password cracking caused by smart card leakage. The Honeywords technology enables the protocol to record false parameters (such as Honey_List) when authentication fails. When the attacker tries to guess multiple times, the account lock mechanism (threshold T0=5) is triggered, effectively resisting brute force cracking. The attacker cannot distinguish between real passwords and false passwords, thereby increasing the difficulty of attack.

[0100] (6) Performance optimization: Actual measurements on a Raspberry Pi show that the protocol's energy consumption is 5%-6% lower than comparable solutions (such as LLRA and PLSR), making it suitable for large-scale smart meter deployment. Furthermore, the protocol requires only two rounds of communication, reducing latency.

[0101] (7) The protocol is not only applicable to smart meters, but can also be extended to medical IoT and other resource-constrained scenarios. In addition, the protocol is verified to be applicable in new energy charging scenarios by combining the actual deployment data of China Tower Corporation (246 charging stations in Taiyuan). BRIEF DESCRIPTION OF THE DRAWINGS

[0102] The present application will be further described below with reference to the accompanying drawings:

[0103] Figure 1 A flowchart of the registration phase provided for an embodiment of the present application;

[0104] Figure 2 Flowchart of the login and identity authentication phase provided for an embodiment of the present application;

[0105] Figure 3 A computer device structure diagram of a computer program that can implement the method of the present application is provided in an embodiment of the present application. DETAILED DESCRIPTION

[0106] like Figure 1-3 As shown, this application provides a lattice-based lightweight, provably secure, multi-factor authentication key exchange method for smart meters. This is a lightweight, provably secure, multi-factor authentication key exchange (PQMFA) protocol for smart meters. This protocol enables communicating parties to negotiate a secure session key. The symbols and their meanings used in this embodiment are shown in Table 1 below.

[0107] Table 1 Symbols and their meanings

[0108]

[0109] The implementation of this application method mainly includes the following stages:

[0110] 1. System setting stage:

[0111] At this stage, the neighborhood gateway Perform the following steps to generate global system parameters. The specific process is as follows:

[0112] (1) Select a large prime number q, a positive integer n, and a parameter k;

[0113] (2) Define a polynomial ring and from Uniformly sampled random matrices , and choose discrete Gaussian distribution as an error distribution; where represents the ring of integers modulo q, that is, the set of residue classes {0, 1, …, q−1} obtained by taking all integers modulo q, is a polynomial, is a variable used to represent the unknown number in the polynomial. represents the quotient ring, i.e. If two polynomials are equal under the modulus, they are considered to be the same element. Indicated by The elements in Matrix collection;

[0114] (3) Randomly select two numbers , calculate the public key ;

[0115] (4) Selecting a hash function ,in is the output length of the hash function;

[0116] (5) Release system parameters: .

[0117] 2. Registration stage: In this stage, smart meters Through a secure channel to the neighboring gateway ( ) Register, then Towards The specific process of issuing smart cards is as follows:

[0118] Step 1.1:

[0119] (1) User / Smart Meter Select an identity ,password , and enter biometrics ;

[0120] (2) Select random number , generate samples ,calculate:

[0121] ;

[0122] ;

[0123] ;

[0124] in is the "fuzzy key" of the biometric feature, Auxiliary data for error correction;

[0125] (3) Send a registration request over a secure channel Give .

[0126] Step 1.2:

[0127] (1) After receiving the request, generate a random number and timestamp ,calculate:

[0128] ;

[0129] ;

[0130] ;

[0131] (2) Record in the registry , and Writing to a new smart card , sent via a secure channel to .

[0132] Step 1.3:

[0133] (1) receive Then, generate a random number and ,calculate:

[0134] ;

[0135] ;

[0136] ;

[0137] ;

[0138] ;

[0139] ;

[0140] ;

[0141] (2) Smart card The following parameters are stored:

[0142] .

[0143] 3. Login and identity authentication stage:

[0144] This phase allows for mutual authentication and the generation of a shared session key. The specific process is as follows:

[0145] Step 2.1 (Login Request):

[0146] (1) User Insert smart card and enter and ,in and It is the password and biometrics that the user actively enters when logging in, used for authentication, and calculates:

[0147] ;

[0148] ;

[0149] ;

[0150] ;

[0151] ;

[0152] (2) Verification and Are they the same? If , terminate the login, otherwise continue (3);

[0153] (3) Generate random samples ,calculate:

[0154] ;

[0155] ;

[0156] ;

[0157] ;

[0158] ;

[0159] ;

[0160] ;

[0161] (4) Send a login request Give .

[0162] Step 2.2 (Gateway Verification):

[0163] (1) calculate:

[0164] ;

[0165] ;

[0166] ;

[0167] ;

[0168] ;

[0169] (2) Check whether it exists in the registry If it does not exist, terminate the session; otherwise, verify Whether and equal;

[0170] (3) If the verification is successful, calculate and with the received If the comparison fails and (List of false authentication attempts) is not full (threshold ),Will Add to the list; otherwise suspend the smart card;

[0171] (4) Generate a new random number ,calculate:

[0172] ;

[0173] ;

[0174] Generate random samples ,calculate:

[0175] ;

[0176] ;

[0177] ;

[0178] ;

[0179] ;

[0180] ;

[0181] ;

[0182] (5) Send response Give .

[0183] Step 2.3 (Session Key Generation):

[0184] (1) calculate:

[0185] ;

[0186] ;

[0187] ;

[0188] ;

[0189] ;

[0190] (2) Verification Whether and Same, if the same, select an integer calculate:

[0191] ;

[0192] ;

[0193] ;

[0194] (3) Update smart card parameters .

[0195] 4. Password and biometric update phase:

[0196] At this stage, users can update their passwords and biometrics independently without having to The specific process of interaction is as follows:

[0197] (1) The user inserts the smart card and enters ,Old Password and old biometrics ;

[0198] (2) Smart card calculation:

[0199] ;

[0200] ;

[0201] ;

[0202] ;

[0203] ;

[0204] verify Whether and If they are not the same, The update request will be rejected, otherwise, the update process will be started;

[0205] (2) Require Provide a new password and new biometrics , generate a random number ,calculate:

[0206] ;

[0207] ;

[0208] ;

[0209] ;

[0210] ;

[0211] ;

[0212] (3) Update smart card parameters .

[0213] 5. Formal Analysis

[0214] At this stage, the provable security of the protocol is proved based on the Random Oracle model. The security of the proposed protocol can be expressed as the adversary The probability of being able to distinguish between a uniform random number and the actual true key SK is To test the bits guessed by adversary A in the query, consider a series of security games, which proceed as follows:

[0215] (1) Simulating a real protocol execution environment, the adversary Interacting with protocol participants via random oracles to define adversary advantages ;

[0216] (2) Introduce a simulation list to record all random oracle queries (such as hash, send, execute query), so that the adversary cannot distinguish and , so ;

[0217] (3) Detect hash collisions or protocol message conflicts (such as repeated random numbers). According to the birthday paradox, the difference is bounded by ( is the number of hash queries, The number of queries sent, is the number of query executions);

[0218] (4) If the adversary fails to guess the verification state (such as password or biometric) through the random oracle, the game ends and the adversary succeeds with probability , ;

[0219] (5) The session key The generation of is bound to the RLWE problem. If the adversary does not query the hash oracle but guesses , then the challenger can use this to solve the RLWE problem, ;

[0220] (6) Restricting the passage of adversaries Query to obtain authentication factors (e.g., at most two factors, password, biometrics, and smart card cannot be obtained simultaneously), the advantage of the adversary in guessing the password online is limited to a constant ;

[0221] (7) If the adversary does not query the hash oracle but generates a valid , the game ends;

[0222] ;

[0223] (8) By accumulating game differences, the adversary’s advantage is limited to:

[0224] ;

[0225] Since the RLWE problem is difficult to solve in polynomial time, the adversary's advantage can be ignored, proving the security of the protocol.

[0226] Table 2 below is a comparison table of the computational and communication efficiency of the method of this application and other key exchange protocols.

[0227] Table 2 Computation and communication efficiency

[0228]

[0229] This application uses asymmetric computing (transferring the computing load to the NAN gateway) and anti-leakage design to achieve a lightweight multi-factor authentication key exchange scheme (reducing the actual time consumption of polynomial multiplication through modular operation optimization and NTT acceleration technology). At the same time, the security of the protocol is rigorously proved under the random oracle model (ROM), and its long-term security is guaranteed based on the computational complexity of the RLWE problem. While ensuring quantum security, this protocol significantly reduces the computing and communication overhead of smart meters, providing an efficient and secure solution for the secure communication of smart meters.

[0230] Figure 3 A block diagram of the structure of a computer device according to an embodiment of the present application is shown. As shown in Figure 3, the computer device includes: a memory and a processor, and the memory stores instructions that can be run on the processor. When the processor executes the instructions, the method in the above embodiment is implemented. The number of memories and processors can be one or more. The computer device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The computer device can also represent various forms of mobile devices, such as personal digital processing, cellular phones, smart phones, wearable devices and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the present application described and / or required herein.

[0231] The computer device may also include a communication interface for communicating with external devices and performing data exchange transmission. The various devices are interconnected using different buses and can be installed on a common motherboard or installed in other ways as needed. The processor can process instructions executed in the computer device, including instructions stored in or on the memory to display graphical information of the GUI on an external input / output device (such as a display device coupled to the interface). In other embodiments, if necessary, multiple processors and / or multiple buses can be used together with multiple memories and multiple memories. Similarly, multiple electronic devices can be connected, and each device provides some necessary operations (for example, as a server array, a group of blade servers, or a multi-processor system). The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Figure 3 Only one thick line is used in the diagram, but this does not mean that there is only one bus or one type of bus.

[0232] Optionally, in a specific implementation, if the memory, processor, and communication interface are integrated on a chip, the memory, processor, and communication interface can communicate with each other through an internal interface.

[0233] It should be understood that the processor may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor may be a microprocessor or any conventional processor, etc. It is worth noting that the processor may be a processor that supports the advanced reduced instruction set machine (ARM) architecture.

[0234] An embodiment of the present application provides a computer-readable storage medium (such as the memory mentioned above), which stores computer instructions. When the program is executed by a processor, the method provided in the embodiment of the present application is implemented.

[0235] Optionally, the memory may include a program storage area and a data storage area. The program storage area may store an operating system and application programs required for at least one function; the data storage area may store data generated based on the use of the mapping computer device. Furthermore, the memory may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state memory device. In some embodiments, the memory may optionally include a memory remotely located relative to the processor, and such remote memory may be connected to the mapping computer device via a network. Examples of such networks include, but are not limited to, the Internet, an intranet, a local area network, a mobile communication network, and combinations thereof.

[0236] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some or all of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the scope of the technical solutions of the embodiments of the present application.

Claims

1. A lattice-based lightweight and provably secure multi-factor authentication key exchange method for smart meters, characterized by: The following steps are involved: Registration stage, smart meter Neighborhood Gateway Register, then Towards Issuing smart cards , specifically including: Step 1.1: According to the user / Smart Meter The identity, password, and biometrics are used to calculate the public key, biometric key, and hash value containing the identity, password, and biometrics, and the identity, public key, and hash value are sent to the neighborhood gateway through a secure channel. ; Step 1.2: After receiving the request, it calculates the relevant intermediate data and records the identity, timestamp and a list of false authentication attempts in the registry, writes the relevant intermediate data into the new smart card, and sends it to the smart meter through a secure channel. ; Step 1.3: Smart Meter After receiving the data from the new smart card, the corresponding parameters are stored in the new smart card after a series of calculations; The specific process of login and identity authentication is as follows: Step 2.1, Login Request: User After inserting the smart card and entering the identity, password and biometric key, a login request is sent to the neighborhood gateway after a series of calculations. ; Step 2.2, Gateway Verification: The gateway verifies the login request and sends a response parameter including the session key to the smart meter based on a series of calculations after the verification is passed. ; Step 2.3, Session Key Generation: Smart Meter The session key is calculated based on the received response parameters and verified to be the same as the received session key. If they are the same, the smart card parameters are updated.

2. The lattice-based lightweight, provably secure, multi-factor authentication key exchange method for smart meters according to claim 1, characterized in that: It also includes a password and biometric update phase, during which users can update their passwords and biometrics independently without the need to Interaction.

3. A lattice-based lightweight, provably secure, multi-factor authentication key exchange method for a smart meter according to claim 1 or 2, characterized in that: Before the registration phase, the neighborhood gateway generates global system parameters ,in is a large prime number, is a positive integer, is a polynomial ring, is a random matrix, is a discrete Gaussian distribution as the error distribution, is the public key, is a hash function.

4. The lattice-based lightweight, provably secure, multi-factor authentication key exchange method for smart meters according to claim 3, characterized in that: The specific implementation process of step 1.1 is as follows: (1) User / Smart Meter Select an identity ,password , and enter biometrics ; (2) Select random number , generate samples ,calculate: ； ； ； in is the "fuzzy key" of the biometric feature, Auxiliary data for error correction; (3) Send a registration request over a secure channel Give .

5. The lattice-based lightweight, provably secure, multi-factor authentication key exchange method for smart meters according to claim 4, characterized in that: The specific implementation process of step 1.2 is as follows: (1) After receiving the request, generate a random number and timestamp ,calculate: ； ； ； (2) Record in the registry , and Writing to a new smart card , sent via a secure channel to ; in A list to store false authentication attempts.

6. The lattice-based lightweight, provably secure, multi-factor authentication key exchange method for smart meters according to claim 5, characterized in that: The specific implementation process of step 1.3 is as follows: (1) receive Then, generate a random number and ,calculate: ； ； ； ； ； ； ； (2) Smart card The following parameters are stored: ； in is the biometric key generation algorithm, It is the biometric key regeneration algorithm.

7. The lattice-based lightweight, provably secure, multi-factor authentication key exchange method for smart meters according to claim 6, characterized in that: The specific implementation process of step 2.1 login request is as follows: (1) User Insert smart card and enter and ,in and It is the password and biometrics that the user actively enters when logging in, used for authentication, and calculates: ； ； ； ； ； (2) Verification and Are they the same? If , terminate the login, otherwise continue (3); (3) Generate random samples ,calculate: ； ； ； ； ； ； ； (4) Send a login request Give .

8. The lattice-based lightweight, provably secure, multi-factor authentication key exchange method for smart meters according to claim 7, characterized in that: The specific process of step 2.2 gateway verification is as follows: (1) calculate: ； ； ； ； ； (2) Check whether it exists in the registry If it does not exist, terminate the session; otherwise, verify Whether and equal; (3) If the verification is successful, calculate and with the received If the comparison fails and The list is not full, Add to list; Otherwise, suspend the smart card; (4) Generate a new random number ,calculate: ； ； Generate random samples ,calculate: ； ； ； ； ； ； ； (5) Send response Give .

9. The lattice-based lightweight, provably secure, multi-factor authentication key exchange method for smart meters according to claim 8, characterized in that: The specific process of session key generation in step 2.3 is as follows: (1) calculate: ； ； ； ； ； (2) Verification Whether and Same, if the same, select an integer calculate: ； ； ； (3) Update smart card parameters .

10. A lattice-based lightweight, provably secure, multi-factor authentication key exchange method for a smart meter according to any one of claims 4 to 9, characterized in that: It also includes a formal analysis phase to prove the provable security of the method based on the Random Oracle model.

Images