A method, device, and medium for secondary authentication of digital terminals in power systems based on quantum key distribution.

Abstract

This invention discloses a method, device, and medium for secondary authentication of digital terminals in power systems based on quantum key distribution, belonging to the field of power system security technology. The method includes: the terminal and a platform pre-sharing a master key; the terminal initiating a session authentication key request containing a first random value to the platform; upon receiving the request, the platform generates a second random value and, based on the master key, the first random value, and the second random value, derives a session authentication key through a first key derivation function; the platform sends the second random value to the terminal, enabling the terminal to derive the same session authentication key; the terminal and platform use this session authentication key to complete subsequent two-way authentication. Compared with existing technologies, this invention significantly improves the security and flexibility of the authentication process, and enhances key management capabilities and anti-attack capabilities.

Description

Technical Field

[0001] This invention relates to the field of power system security technology, specifically to a method, device, and medium for secondary authentication of digital terminals in power systems based on quantum key distribution. Background Technology

[0002] Existing technology provides a two-way authentication method between a power system terminal and a quantum security service platform. In this method, after the terminal initiates registration, the platform responds with a random number and a quantum key identifier. The terminal retrieves a pre-shared quantum key based on this identifier, generates another random number, and uses this quantum key to calculate two message authentication codes: one for terminal-to-platform communication (MACab), and the other for platform-to-terminal communication (MACba). The terminal then sends both MACab and MACba to the platform. The platform verifies the MACab; if MACab is valid, it sends its calculated MACba to the terminal, which then verifies MACba, thus completing the two-way authentication.

[0003] However, the aforementioned existing technologies have several technical problems: 1. Lack of key lifecycle management: This method relies on pre-shared quantum keys, but does not elaborate on the full lifecycle management mechanism for the secure distribution, updating, and revocation of these quantum keys. If the key is leaked during the pre-sharing stage or becomes insecure due to long-term use, the security of the entire authentication system will be seriously threatened. 2. Lack of dynamic session key and forward security: Directly using long-term valid quantum keys to calculate message authentication codes means that once this long-term key is leaked, all past and future authentication sessions based on this key may be cracked, lacking forward security. 3. Replay attack risk: Although random numbers are used in the authentication process, in certain network attack scenarios, or in systems with low time synchronization requirements, if the generation or management of random numbers is improper, there may still be a risk of being subjected to carefully crafted replay attacks, especially if the key identifier and random numbers are intercepted by the attacker. 4. Atomicity and efficiency issues in the authentication process: Multiple message interactions (e.g., four message passes) may lead to low authentication efficiency when network latency is high or when facing large-scale terminal access requests. In addition, the non-atomicity of the authentication process may also lead to the risk of intermediate states being exploited by attackers. Summary of the Invention

[0004] In view of the above-mentioned problems, the present invention is proposed.

[0005] Therefore, the technical problem solved by this invention is: how to solve the problems of lack of quantum key lifecycle management, lack of session key dynamism and forward security, vulnerability to replay attacks, and insufficient authentication efficiency and atomicity.

[0006] To solve the above-mentioned technical problems, the present invention provides the following technical solution: a secondary authentication method for digital terminals in power systems based on quantum key distribution, comprising,

[0007] The master key is pre-shared between the terminal and the platform;

[0008] The terminal sends a session authentication key request containing a first random value to the platform.

[0009] After receiving the request, the platform generates a second random value;

[0010] The platform derives the session authentication key based on the master key, the first random value, and the second random value through the first key derivation function;

[0011] The platform sends the second random value to the terminal;

[0012] Based on the master key, the first random value, and the second random value, the terminal derives the same session authentication key as the platform through the first key derivation function.

[0013] The terminal and the platform use a session authentication key to complete the two-way authentication process.

[0014] As a preferred embodiment of the quantum key-based secondary authentication method for digital terminals in power systems according to the present invention, wherein: when the terminal initiates a session authentication key request, the request includes a first timestamp;

[0015] Before deriving the session authentication key from the platform, verify whether the first timestamp is within the preset first time window;

[0016] The platform includes a second timestamp in the response sent to the terminal;

[0017] The terminal verifies whether the second timestamp is within a preset second time window before deriving the session authentication key;

[0018] The input to the first key derivation function includes a first timestamp and a second timestamp.

[0019] As a preferred embodiment of the quantum key-based secondary authentication method for digital terminals in power systems according to the present invention, the terminal and the platform negotiate encryption parameters after completing the two-way authentication process.

[0020] The encryption parameters are derived from the session authentication key and the negotiated third and fourth random values, and the session encryption key is derived through the second key derivation function.

[0021] As a preferred embodiment of the quantum key-based secondary authentication method for digital terminals in power systems according to the present invention, the method includes: before the terminal communicates with the platform using a session encryption key, the method includes: the terminal encrypting a first known vector using the session encryption key and sending it to the platform;

[0022] The platform uses the currently derived session encryption key to decrypt and verify the first known vector to confirm that the terminal has correctly derived the session encryption key;

[0023] The platform uses the session encryption key to encrypt the second known vector and sends it to the terminal;

[0024] The terminal uses the currently derived session encryption key to decrypt and verify the second known vector to confirm that the platform has correctly derived the session encryption key.

[0025] As a preferred embodiment of the quantum key-based secondary authentication method for digital terminals in power systems according to the present invention, the terminal and the platform act as communication senders and receivers to each other.

[0026] The communication sender appends an incrementing sequence number to each application data message to be sent, and uses a session encryption key to encrypt and authenticate the message with the appended sequence number.

[0027] After the receiving party decrypts and authenticates the received message, it verifies whether the sequence number in the message is the expected sequence number, thus completing the detection of message loss, out-of-order delivery, or replay.

[0028] As a preferred embodiment of the quantum key-based secondary authentication method for digital terminals in power systems according to the present invention, wherein: when the terminal and the platform communicate using a session encryption key, a time synchronization verification step is performed;

[0029] The terminal records the local transmission time t1 and sends a time synchronization request message containing t1 to the platform in an encrypted manner;

[0030] The platform records the local time t2 when the request is received and the local time t3 when the response is prepared, and sends the time synchronization response message containing t1, t2, and t3 to the terminal in an encrypted manner;

[0031] The terminal records the local time t4 of the received response and calculates the clock offset between the terminal and the platform based on t1, t2, t3, and t4.

[0032] Sending encrypted data to the terminal or platform also includes refreshing the session key;

[0033] The terminal or platform initiates a refresh request, and both parties exchange new random values;

[0034] The terminal and platform derive a new session authentication key and a new session encryption key based on the current session authentication key and the new random value.

[0035] Before the terminal initiates a session authentication key request, steps to defend against denial-of-service attacks are also included.

[0036] The platform sends a computational puzzle to the terminal, which then solves the puzzle to obtain the solution.

[0037] The terminal includes the puzzle solution in the current session authentication key request;

[0038] Before deriving the session authentication key, the platform verifies the validity of the puzzle solution.

[0039] As a preferred embodiment of the quantum key-based secondary authentication method for digital terminals in power systems according to the present invention, the method for establishing the master key is as follows: the terminal and the platform perform an elliptic curve key exchange protocol to negotiate a shared secret; the terminal and the platform derive the master key based on the shared secret.

[0040] This preferred solution proactively generates a migration token and a pre-master key after the first secure session is established, and sends them to the terminal, thus providing pre-defined conditions for subsequent rapid re-authentication. Compared to the traditional method of re-initiating a complete authentication process after a session interruption, this mechanism enables forward continuity of the authentication state, allowing the terminal to renegotiate the session key without needing to reacquire the master key. This reduces the platform's computational overhead and enhances the system's continuity under unstable communication conditions.

[0041] As a preferred embodiment of the quantum key-based secondary authentication method for power system digital terminals described in this invention, the terminal and the platform complete a two-way authentication process using a session authentication key, and then enter a first secure session. The platform generates a migration token and a pre-master key, and sends both to the terminal.

[0042] When the first secure session is interrupted, the terminal initiates a fast re-authentication request, which includes a migration token and a new terminal random value;

[0043] After the platform verifies the validity of the migration token, it derives a new session key from the pre-master key and a new random value with the terminal to establish a second secure session.

[0044] In the event of an unexpected interruption of the first secure session, this preferred solution allows the terminal to directly utilize the previously obtained migration token and pre-master key to quickly negotiate a new session key with the platform and establish a second secure session. This approach not only significantly reduces authentication latency and improves system recovery efficiency but also better adapts to common scenarios in the operation of power terminal equipment, such as short-term link jitter and module restarts.

[0045] The present invention provides a computer device, including a memory and a processor, wherein the memory stores a computer program, characterized in that the processor executes the computer program to implement the steps of the aforementioned quantum key-based power system digital terminal secondary authentication method.

[0046] The present invention provides a computer-readable storage medium storing a computer program thereon, characterized in that, when the computer program is executed by a processor, it implements the steps of the aforementioned quantum key-based power system digital terminal secondary authentication method.

[0047] The beneficial effects of this invention are as follows: By constructing an authentication mechanism that combines master key negotiation, key derivation, two-way authentication, and fast re-authentication, this invention effectively enhances the security and stability of the communication process between the terminal and the platform. Compared with existing technical solutions that use a single authentication process, this invention ensures the dynamism of the authentication key through master key negotiation and random number interaction in the initial stage of terminal access, and then uses the authentication key to perform two-way authentication operations, thereby improving the reliability of identity verification.

[0048] After two-way authentication is completed, the system enters the first secure session. The platform pre-generates a migration token and a pre-master key and sends them to the terminal, providing crucial support for the rapid re-authentication process. If the first secure session is interrupted, the terminal can use the obtained migration token and a new random number, combined with the pre-master key, to derive a new session key, thereby quickly establishing a second secure session. This mechanism, while ensuring authentication strength, improves the terminal's authentication recovery efficiency under network jitter or unplanned restart scenarios, avoiding the resource burden and connection interruption risks caused by a full re-authentication process.

[0049] This invention also introduces timestamp verification, sequence number verification, session key refresh, two-way encrypted communication, and anti-DoS processing mechanisms in the process of authentication information generation and transmission, constructing a multi-dimensional protection structure and enhancing the overall system's ability to defend against various threats such as time-series attacks, replay attacks, and spoofing attacks. Attached Figure Description

[0050] To more clearly illustrate the technical solutions of the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying 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.

[0051] Figure 1 The above is a flowchart of a quantum key-based secondary authentication method for digital terminals in power systems, provided as an embodiment of the present invention.

[0052] Figure 2 This is a flowchart illustrating an optional DoS defense mechanism for a quantum key-based secondary authentication method for digital terminals in power systems, provided as an embodiment of the present invention.

[0053] Figure 3 This is a schematic diagram of the time synchronization verification process for encrypted communication in a quantum key-based secondary authentication method for digital terminals in power systems, provided as an embodiment of the present invention.

[0054] Figure 4 This is a schematic diagram of the session migration and fast re-authentication process of a quantum key-based secondary authentication method for digital terminals in power systems, provided as an embodiment of the present invention.

[0055] Figure 5 This is a schematic diagram of the initial key negotiation process based on elliptic curve cryptography for a secondary authentication method for digital terminals in a power system based on quantum key distribution, provided as an embodiment of the present invention. Detailed Implementation

[0056] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of the present invention.

[0057] Example 1 is an embodiment of the present invention, which provides a secondary authentication method for digital terminals in power systems based on quantum key distribution, including:

[0058] In existing technologies, the secondary authentication method between power system terminals and quantum security service platforms can achieve identity verification by constructing two-way message authentication codes (MACab and MACba) using random numbers and quantum key identifiers. However, its authentication process still has the following key problems:

[0059] 1. Existing technologies directly rely on pre-shared quantum keys for authentication computations, without establishing a controllable session key update mechanism. If this key is leaked during long-term operation, it will expose all sessions to information security risks.

[0060] 2. The authentication process does not introduce an independent, dynamically generated session key. Instead, it reuses a long-term key to generate a MAC. Once this long-term key is leaked, the content of historical communications will also be exposed, and the system lacks forward confidentiality capabilities.

[0061] 3. Although random numbers are used in the authentication, no context binding mechanism or time constraint strategy is introduced to match the random numbers. If an attacker intercepts part of the communication content, they may be able to replay the attack process by forging requests, which could endanger the platform's response security.

[0062] 4. Existing solutions typically rely on multiple rounds of message interaction. In scenarios with large-scale concurrent access from terminals or unstable networks, interruptions in the process can easily lead to authentication failures or abnormal authentication statuses, affecting system stability and response efficiency.

[0063] To address key technical shortcomings in existing power system authentication schemes, this embodiment designs a key derivation mechanism based on dual random numbers. This avoids the direct exposure of long-term master keys during the authentication process, fundamentally solving the security risks caused by long-term key validity. Simultaneously, by explicitly distinguishing the independent session keys generated for each authentication request, the isolation between sessions is enhanced, ensuring that even if one session key is leaked, it does not affect the security of other historical or subsequent sessions. Furthermore, random parameters generated by both the platform and the terminal are introduced as derivation inputs, strengthening the correlation of authentication information and preventing simple reuse, thereby improving resistance to replay attacks. The entire authentication process minimizes message interaction rounds while maintaining security strength, making it particularly suitable for large-scale power terminal access scenarios, and contributing to improved overall system authentication processing efficiency and stability.

[0064] The master key is pre-shared between the terminal and the platform.

[0065] The terminal sends a session authentication key request containing a first random value to the platform.

[0066] After receiving the request, the platform generates a second random value.

[0067] The platform derives the session authentication key based on the master key, the first random value, and the second random value through the first key derivation function.

[0068] The platform sends the second random value to the terminal.

[0069] The terminal derives the same session authentication key as the platform through the first key derivation function based on the master key, the first random value, and the second random value.

[0070] The terminal and the platform use a session authentication key to complete the two-way authentication process.

[0071] When a terminal initiates a session authentication key request, the request includes a first timestamp.

[0072] Before deriving the session authentication key from the platform, verify whether the first timestamp is within the preset first time window.

[0073] The platform includes a second timestamp in the response sent to the terminal.

[0074] Before deriving the session authentication key, the terminal verifies whether the second timestamp is within the preset second time window.

[0075] The input to the first key derivation function includes the first timestamp and the second timestamp.

[0076] After the terminal and the platform complete the two-way authentication process, the terminal and the platform negotiate encryption parameters.

[0077] The encryption parameters are derived from the session authentication key and the negotiated third and fourth random values, and the session encryption key is derived through the second key derivation function.

[0078] Before the terminal and the platform communicate using the session encryption key, the process includes: the terminal encrypting a first known vector using the session encryption key and sending it to the platform.

[0079] The platform uses the currently derived session encryption key to decrypt and verify the first known vector to confirm that the terminal has correctly derived the session encryption key.

[0080] The platform encrypts the second known vector using the session encryption key and sends it to the terminal.

[0081] The terminal uses the currently derived session encryption key to decrypt and verify the second known vector to confirm that the platform has correctly derived the session encryption key.

[0082] The terminal and the platform act as both the sender and receiver of communications.

[0083] The sender appends an incrementing sequence number to each application data message to be sent and uses a session encryption key to encrypt and authenticate the message with the appended sequence number.

[0084] After the receiving party decrypts and authenticates the received message, it verifies whether the sequence number in the message is the expected sequence number, thus completing the detection of message loss, out-of-order delivery, or replay.

[0085] When the terminal and platform communicate using a session encryption key, the time synchronization verification steps are performed.

[0086] The terminal records the local transmission time t1 and sends a time synchronization request message containing t1 to the platform via encrypted communication.

[0087] The platform records the local time t2 when the request is received and the local time t3 when the response is prepared, and sends a time synchronization response message containing t1, t2, and t3 to the terminal via encrypted communication.

[0088] The terminal records the local time t4 of the currently received response and calculates the clock offset between the terminal and the platform based on t1, t2, t3, and t4.

[0089] Sending encrypted communication to a terminal or platform also includes refreshing the session key.

[0090] The terminal or platform initiates a refresh request, and the two parties exchange new random values.

[0091] The terminal and platform derive a new session authentication key and a new session encryption key based on the current session authentication key and the new random value.

[0092] Before the terminal initiates a session authentication key request, it also includes steps to defend against denial-of-service attacks.

[0093] The platform sends a computational puzzle to the terminal, which then solves the puzzle to obtain the solution.

[0094] The terminal includes the puzzle solution in the current session authentication key request.

[0095] Before deriving the session authentication key, the platform verifies the validity of the puzzle solution.

[0096] The method for establishing the master key is for the terminal and the platform to perform an elliptic curve key exchange protocol to negotiate a shared secret; the terminal and the platform then derive the master key based on the shared secret.

[0097] After the terminal and platform complete the two-way authentication process using the session authentication key, they enter the first security session. The platform generates a migration token and a pre-master key and sends both to the terminal.

[0098] When the first secure session is interrupted, the terminal initiates a fast re-authentication request, which includes a migration token and a new terminal random value.

[0099] After the platform verifies the validity of the migration token, it derives a new session key from the pre-master key and a new random value with the terminal to establish a second secure session.

[0100] Example 2, refer to Figures 1-5 As an embodiment of the present invention, based on the previous embodiment, a secondary authentication method for digital terminals in power systems based on quantum key distribution is provided, comprising:

[0101] Methods for deriving and enhancing session authentication keys based on master keys.

[0102] This embodiment discloses the core steps of a quantum key-based secondary authentication method for digital terminals in power systems, particularly the derivation process of the session authentication key, and incorporates optional timestamp verification and DoS defense mechanisms. (Refer to...) Figure 1This method is applied between a power system terminal (hereinafter referred to as the terminal) and a quantum security service platform (hereinafter referred to as the platform), where both parties pre-share a long-term master key. and a master key identifier .

[0103] The process of deriving the session authentication key specifically includes: Step S201: The terminal initiates a session authentication key request.

[0104] The terminal generates an initial random number. (as the first random value), and send a session authentication key request to the platform.

[0105] The request message can be represented as:

[0106] ,

[0107] in, This is a session authentication key request message sent by the terminal to the platform. REGISTER_REQ is a registration request type identifier. The master key identifier.

[0108] Step S202: The platform generates session authentication key materials and responds.

[0109] After receiving the request, the platform uses the master key identifier. Retrieve the corresponding long-term master key The platform generates a platform random number. (As a second random value). The platform uses a key derivation function (KDF) based on... , , and a predefined context information (For example, the string "AUTH_KEY_DERIVATION") derives the session authentication key. and a session key identifier This process can be represented as:

[0110] ,

[0111] in, This indicates a concatenation operation. KDF can use functions conforming to standards such as NISTSP800-108, such as the HMAC-based Extract and Expand Key Derivation Function (HKDF). The platform generates a random number for subsequent authentication. To ensure The platform can ensure secure use and correct key derivation. , , and Calculate a key-derived acknowledgment message authentication code :

[0112] ,

[0113] The platform will use key identifiers , , and Send to the terminal. The response message can be represented as: .

[0114] in, This is the platform's response message.

[0115] Step S203: The terminal derives and verifies the session authentication key.

[0116] After receiving the response from the platform, the terminal uses locally stored... And received And what I generated before It adopts the same KDF (Key Derivation Function) as the platform and Derive session authentication key :

[0117] ,

[0118] in, A session authentication key is derived for the terminal, which then uses the long-term master key. calculate and verify Is it consistent with the received Consistent, among which, The authentication code for the confirmation message is derived from the key calculated for the terminal.

[0119] If there is a discrepancy, the certification process will be terminated, which may indicate that... The information has been tampered with or the platform's identity is questionable.

[0120] Step S204: Continue the original authentication process.

[0121] like Verification successful; terminal confirms connection with platform. (Right now An agreement was reached. At this point, As a session identifier for subsequent authentication, This serves as the session key. Subsequent two-way authentication steps (e.g., the terminal generates a random number) are also included. Calculate the message authentication code from the terminal to the platform. Platform-to-terminal message authentication code (etc.) will use this and Perform, rather than use directly and .

[0122] An optional timestamp mechanism can be introduced during the key derivation process to enhance resistance to replay attacks.

[0123] Step S201': Add a timestamp to the terminal request.

[0124] The terminal additionally includes its current timestamp in the request in step S201. (First timestamp). The request message becomes: .

[0125] Step S202': Add timestamp and verification to the platform response.

[0126] After receiving the request, the platform first verifies... The freshness, for example, is checked to see if it is within a preset acceptable time window. (relative to the current platform time) ), that is, to judge Is it true? If so... If invalid, the request is rejected. Valid, platform-generated random number and the platform's current timestamp (Second timestamp). Session authentication key Derivatives can incorporate timestamp information into the input of a KDF:

[0127] ,

[0128] Key Derivation Confirmation Message Authentication Code The calculation also includes timestamp information:

[0129] ,

[0130] The platform's response message changed to:

[0131] ,

[0132] It should be further explained that the preset acceptable time window The range of values ​​for:

[0133] 1. Ideal environment: Dedicated power network (such as a dedicated fiber optic network).

[0134] In this environment, network latency is very low and stable, and clock synchronization accuracy is high. Typical value range: tens of milliseconds to hundreds of milliseconds (e.g., 50ms~500ms).

[0135] 2. Standard environment: High-quality public network (such as a stable 4G / 5G network).

[0136] This is the access method adopted by many power IoT terminals. The network latency is relatively controllable, but it is higher than that of a private network and fluctuates to some extent. Typical range: 1 to 5 seconds.

[0137] 3. Complex or harsh environments: Satellite communications, cross-border networks, and mobile networks with unstable signals. In these scenarios, network latency is high and extremely unstable, potentially resulting in delays of several seconds or even longer. Typical range: 5 to 30 seconds, or even longer.

[0138] Step S203': Add timestamp verification in terminal derivation and verification.

[0139] After receiving the response, the terminal first verifies... The freshness of the data can be assessed, for example, by checking whether it falls within a preset acceptable time window, i.e., the second time window (relative to the current time of the terminal). ), that is, to judge Whether it is valid or not.

[0140] If the current timestamp If invalid, the authentication will be terminated.

[0141] If the current timestamp Effective, terminal use , , and the timestamps of both parties It adopts the same KDF derivation as the platform. Terminal computing And verify.

[0142] Step S204': The subsequent authentication includes a timestamp.

[0143] In subsequent use Authentication messages (such as) , The calculation of ) should also include the corresponding timestamp information, for example:

[0144] ,

[0145] ,

[0146] in It is sent by the terminal. The current timestamp of the time. It is sent by the platform. The current timestamp of the message. The receiver also needs to verify the freshness of the timestamp in the corresponding message before verifying the MAC address.

[0147] Optional DoS (Denial of Service) defense mechanisms are listed below. Figure 2 To prevent the platform from exhausting its resources due to processing a large number of initial key derivation requests, a client-side puzzle mechanism can be introduced before the formal session authentication key request.

[0148] Step S301: The terminal initiates a preliminary registration request.

[0149] The terminal sends a lightweight initial registration request to the platform:

[0150] ,

[0151] in, Master key identifier hint.

[0152] Step S302: Platform response puzzle.

[0153] After receiving the initial request, the platform does not immediately execute the agreement. Instead of involving expensive operations, it generates a computational puzzle. For example, finding a random number. Make The former The bit is 0. (The challenge value given by the platform is concatenated with a value X that the terminal tries, and then the hash value of this concatenated new data is calculated.)

[0154] The platform will assign puzzle challenge values and difficulty parameters (or a puzzle identifier pointing to a predefined puzzle) Send to the terminal: .

[0155] It should be further explained that the platform only sends one PID_puzzle. This approach is based on the premise that the platform and the terminal have pre-configured (or negotiated) a series of standard puzzles and assigned a number to each puzzle (this number is the PID_puzzle).

[0156] Step S303: The terminal solves the puzzle and initiates a complete request.

[0157] The terminal solves the puzzle and obtains the solution. Then, the terminal initiates a session authentication key request containing the solution to the puzzle (as in step S201 or S201'), the request additionally containing... (or )and .

[0158] This is random data generated by the platform (server) and sent to the terminal; it can be understood as the "stem" or "question" of the puzzle. The terminal needs to solve the puzzle based on this Challenge value. When the terminal sends the solution back to the platform, it must also include the Challenge value it received so that the platform knows which puzzle the solution addresses.

[0159] When distributing puzzles, the platform can choose not to directly provide a "Challenge" but instead provide a predefined puzzle ID (PID_puzzle). Therefore, when returning an answer, the terminal also needs to inform the platform which puzzle ID it solved.

[0160] The solution is the "answer" to the puzzle found by the terminal through computation. It's the specific value X that makes the calculation result of Hash(Challenge||X) satisfy a specific condition (such as the first k bits being 0). The terminal sends this solution to the platform to prove that it has invested the necessary computing resources to complete the "assignment" given by the platform, thus demonstrating that it is a legitimate and sincere customer.

[0161] For example:

[0162] ,

[0163] Step S304: The platform verifies the puzzle solution and continues.

[0164] After receiving the request, the platform first performs a quick verification. for The effectiveness.

[0165] If the solution is invalid, the platform rejects the request.

[0166] If the solution is valid, the platform will then proceed with subsequent key derivation steps (such as step S202 or S202'). At this point, The calculations should preferably also include puzzle-related information to enhance security:

[0167] ,

[0168] It involves concatenating the "Challenge" and the "Solution" of the puzzle, and then calculating a hash value.

[0169] The subsequent procedures are the same as described above.

[0170] This embodiment uses dynamically derived session authentication keys. Replacement long-term master key Direct participation in authentication enhances the security of the master key. The combination of a timestamp mechanism strengthens resistance to replay attacks. The integration of a puzzle mechanism mitigates the risk of DoS attacks on the platform.

[0171] Encrypted channel negotiation and confirmation based on session authentication keys:

[0172] Building upon the "Method for Derivation and Enhancement of Session Authentication Keys Based on Master Keys," this paper describes a method for deriving and enhancing session authentication keys. After successfully deriving and completing two-way authentication, how to further negotiate and derive the session encryption key? The key is then verified to establish a secure encrypted communication channel.

[0173] Session encryption key negotiation assumes that the terminal and platform have already shared the session authentication key using the method in Example 1. and session identifier and completed based on Identity authentication.

[0174] Step S401: The terminal initiates an encryption parameter negotiation request.

[0175] The terminal selects a set of encryption algorithm suites it supports. (e.g., AES-GCM-128) and a random number for deriving the encryption key. (As a third random value). The terminal combines this information with existing messages from subsequent authentication steps (e.g., messages containing a random number generated by the terminal). And a second timestamp recorded by the terminal. The authentication message is sent to the platform together with the authentication message.

[0176] For example, the message could be:

[0177] ,

[0178] in, use The calculation should take a random number generated by the terminal as input to derive the encryption key. and a list of cryptographic algorithm suites proposed by the terminal. (or hash value) to protect the integrity of these parameters:

[0179] ,

[0180] in, It is a standard hash function (such as SHA-256). To perform hash calculations on the list of cryptographic algorithm suites proposed by the terminal.

[0181] Step S402: The platform selects encryption parameters and derives the session encryption key.

[0182] Platform verification Afterwards, from Choose a suite of encryption algorithms that is supported by both parties and preferred by the platform. The platform generates a random number to derive the encryption key. (As the fourth random value).

[0183] Platform usage (Session authentication key) and (A platform-generated random number used to derive the encryption key) and a context used for encryption key derivation. (For example, "SESSION_ENCRYPTION_KEY") The session encryption key is derived through the second key derivation function. If the selected encryption suite is not in AEAD (Authenticated Encryption with Associated Data) mode, a session integrity key may also be derived. .

[0184] ,

[0185] in, This is the context string used to derive the encryption key.

[0186] If AEAD (such as AES-GCM) is used, only one key is typically derived. .

[0187] Step S403: Platform response encryption parameter selection.

[0188] The platform will select , Along with the original messages in subsequent authentication steps (e.g.) They are sent together to the terminal.

[0189] For example, the response message could be:

[0190] ,

[0191] in, The suite of encryption algorithms ultimately selected by the platform.

[0192] (Assuming) etc., which have been transmitted or included in previous steps (in the calculation). The calculation should also include these negotiated parameters at this point:

[0193] ,

[0194] in, To perform a hash calculation on the chosen suite of cryptographic algorithms for the platform.

[0195] Step S404: The terminal derives the session encryption key.

[0196] Terminal verification If verification is successful, the terminal uses... , (One's own) (Received) and and Derive the same session encryption key and the session integrity key derived from the terminal side At this point, there should be .

[0197] Session encryption key verification is to ensure that both parties have correctly derived and are ready to use the key. Then, verify the key.

[0198] Step S405: The terminal sends an encrypted key confirmation message.

[0199] The terminal constructs a first known vector (For example, a fixed string), using the new derived and selected Encrypt and / or authenticate it.

[0200] ,

[0201] in It is the first initialization vector. This is the first additional authentication data (which may include) ), For encryption actions, This encryption operation uses the session encryption key. To carry out.

[0202] The ciphertext generated by the terminal (as well as Send the authentication label (if separate) to the platform.

[0203] Step S406: The platform decrypts and verifies the information and sends an encrypted response.

[0204] The platform received Use its own derived Perform decryption and / or verification. If decryption / verification is successful and the data is recovered... as expected If they match, the platform confirms that the terminal has been used correctly. The platform constructs its own second known vector. The same method is used. and Encrypt and / or authenticate it.

[0205] ,

[0206] The platform will Send to the terminal. This is the second initialization vector. This is the second additional authentication data.

[0207] This represents the "first known vector" recovered by the platform after decryption.

[0208] It is the original, plaintext known vector.

[0209] When the platform receives Afterwards, they will use their own key. Perform decryption. The data obtained after successful decryption is recorded in the document as follows. The platform compares its recovered data with... and its expectations To verify that the keys and encryption operations on the terminal are completely identical, it is necessary to check their consistency. "Here, it means "the version decrypted / recovered by another party".

[0210] Step S407: Terminal decryption verification platform key confirmation.

[0211] The terminal received ,use Perform decryption and / or verification. If decryption / verification is successful and the data is recovered... as expected If they match, then the terminal confirms that the platform has also been used correctly. .

[0212] At this point, both parties have successfully negotiated and confirmed the session encryption key. Subsequent application data can be securely encrypted and protected for integrity using this key and a selected encryption suite.

[0213] Serial number management and time synchronization verification in encrypted communication:

[0214] Based on the encrypted channel established by "encrypted channel negotiation and confirmation based on session authentication key", this paper describes how to prevent message loss, out-of-order delivery or replay through sequence number management, and how to use this secure channel for time synchronization verification.

[0215] Serial number management, through In an encrypted session, a sequence number is introduced for each message.

[0216] Step S501: Initialize the serial number.

[0217] The terminal and platform each initialize and send a serial number. (Sent from terminal) (Sent by the platform), and the expected serial number to be received. (The terminal expects to receive from the platform) (The platform expects to receive from the terminal).

[0218] in, Send a serial number to the terminal. Send the serial number to the platform. The serial number that the terminal expects to receive. This is the expected receive sequence number.

[0219] Step S502: The sender encapsulates and sends the message.

[0220] When the sender (such as the terminal) has application data When it needs to be sent:

[0221] a. Set its current sending sequence number and Together constitute a message .

[0222] b. Use and selected right Encryption and authentication are performed to generate AAD may contain .

[0223] in, This represents a plaintext message. This is the raw, unencrypted data before encryption. According to the description of step S502, M is determined by the current sending sequence number. It is composed of the application data payload to be transmitted. .

[0224] This represents the initialization vector. It is a random number, associated with the key. It is used together in the encryption process. Its main purpose is to ensure that the same plaintext M generates different ciphertext each time it is encrypted, which is crucial for preventing attacks such as pattern analysis. The sender needs to... It is sent to the recipient along with the ciphertext because the recipient needs to use the same IV when decrypting.

[0225] (Additional Authenticated Data) This part of the data is not encrypted, but it is protected by an encryption algorithm to ensure its integrity. In other words, the receiver can ensure that this data has not been tampered with during transmission. AAD may contain session information. This prevents attackers from taking a message from one session and replaying it in another session.

[0226] c. The sender will Send to the recipient.

[0227] d. The sender will give it Increment by 1.

[0228] Step S503: The receiver processes the message.

[0229] When the recipient (such as the platform) receives back:

[0230] a. Use Decrypt and authenticate to obtain If it fails, discard it.

[0231] It should be further explained that: This is the message recovered after decryption. This is the message that the recipient (such as a platform) recovers after receiving the ciphertext, using the key. The result obtained after decryption and authentication with IV. If decryption is successful, the content of M' should be exactly the same as the original M from the sender.

[0232] This represents the transmission sequence number recovered from the decrypted message. This is the sequence number portion contained in M'. The receiver will... With the expected receive sequence number recorded by myself Compare the messages to check for any missing, out-of-order, or replayed messages.

[0233] b. Compare the received sequence number With its expected receive sequence number .like The message order is correct. Process. and will Increment by 1. If Message loss detected. You can cache, discard, or request a retransmission. The message is duplicated or outdated. It should be discarded. The platform follows the same steps when sending messages to the terminal, using its... and .

[0234] It should be further explained that: This refers to the application data recovered from the decrypted message.

[0235] This is included The application data portion of the payload. After all verifications (decryption, integrity, serial number) pass, the payload is the valid data that will ultimately be delivered to the upper-layer application for processing.

[0236] Time synchronization verification reference based on authentication encryption Figure 3 Time synchronization verification is performed using an established encrypted channel with a sequence number.

[0237] Step S601: The terminal initiates a time synchronization request.

[0238] The terminal records its current local high-precision timestamp. Terminal preparation time synchronization request message ,Include This message is sent to the platform using the aforementioned serial number management and encryption methods (step S502), for example:

[0239] ,

[0240] in, This is the encrypted ciphertext of the time synchronization request. It is the initialization vector (IV) used for encrypted time synchronization requests. It is additional authentication data used to encrypt time synchronization requests.

[0241] Step S602: The platform processes the request and responds.

[0242] The platform receives and decrypts the authentication. The decrypted and recovered time synchronization response message is obtained. and among them (Terminal check) Is it consistent with my own records? Consistency is required to confirm the correspondence between responses.

[0243] The platform records the local time when it receives the message. and the local time when processing is complete and ready to respond. Platform preparation time synchronized response message. ,Include , , This message is also sent back to the terminal using sequence number management and encryption methods, for example:

[0244] ,

[0245] in, This is the initialization vector for the encrypted time synchronization response.

[0246] Step S603: The terminal processes the response and calculates the deviation. .

[0247] Terminal receives and decrypts authentication ,get and among them , , . ( The "local time at which the request was received" recorded by the platform. The value, The "local time for preparing a response" recorded by the platform. The value of .

[0248] The terminal records the local time when it receives the response. The terminal uses four timestamps. Calculate clock offset and one-way network latency :

[0249] ,

[0250] ,

[0251] The terminal can be based on Verify that its time synchronization with the platform is within the allowable threshold and determine whether the local clock needs to be calibrated.

[0252] It should be further explained that: currently, "the terminal can be based on..." The "allowable threshold" in "verifying whether the time synchronization between the two clocks is within the allowable threshold" is used to determine whether the offset θ between the two clocks is within an acceptable range.

[0253] This threshold is typically defined as the maximum tolerable clock error for a specific power system application. It is not a fixed standard but is determined by business requirements. For the "digital terminal" of this invention, the threshold needs to be determined based on its specific function. If used for control, it may be in the tens of milliseconds range; if used for meter reading or logging, an error of a few seconds is acceptable.

[0254] Session key refresh and fast re-authentication: How to refresh the session key in an established secure session, and how to perform fast re-authentication after the session is interrupted.

[0255] Step S701: The platform prepares a refresh request.

[0256] Platform generates new random numbers and new session identifier The platform is preparing to refresh the request message. .

[0257] This message uses the current session encryption key. After serialization, encryption, and authentication, it is sent to the terminal.

[0258] Step S702: The terminal processes the refresh request and derives a new key.

[0259] After terminal decryption and authentication, the following is obtained and .

[0260] in, It is a new random number (Nonce) recovered after terminal decryption, generated by the platform for this key refresh. The identifier for the new session, as specified by the platform, that is recovered after the terminal is decrypted.

[0261] The terminal generates its own new random numbers. .

[0262] The terminal authenticates based on the current session key. and new context Derive a new session authentication key and new session encryption key .

[0263] The key refresh response message sent by the terminal to the platform. It is the context used to derive new authentication keys. It is the context used to derive new encryption keys.

[0264] For example:

[0265] ,

[0266] ,

[0267] in, For the new session authentication key, For the new session integrity key. To derive the context string for the new encryption key, The context string for deriving a new authentication key.

[0268] The terminal is preparing to refresh the response message. and use new It is then encrypted and sent to the platform.

[0269] Step S703: The platform completes the key refresh and confirmation.

[0270] After receiving the response, the platform attempts to use its corresponding derived (expected) new... Decrypt. If successful, the platform confirms that the terminal has switched to the new key. The platform may choose to send a key using... Encrypted final confirmation message.

[0271] Both parties subsequently used Communication is possible, and the serial number can be reset.

[0272] Session migration and fast re-authentication reference Figure 4 It allows terminals to quickly resume sessions after session interruptions and network switching.

[0273] Step S801: The platform generates a migration token.

[0274] In a certain active session (SessionA, key is...) In this process, the platform generates a time-limited migration token for the terminal. and an associated premaster key .

[0275] It can be constructed as:

[0276] ,

[0277] in, This represents an encryption function, which uses a name A special key is used to perform encryption. This is a concatenation operator. Expiration date For the pre-master key B, This is the identifier for session A.

[0278] And included a .

[0279] in, The message authentication code for the token. for The specific calculation process uses a special key. For the whole The HMAC value is calculated from the content.

[0280] and It is an internal key of the platform.

[0281] It should be further explained that: as well as Both of these are internal keys for the platform, but they serve different purposes. Therefore, they must be two different keys. This is an extremely important principle in cryptography called "key separation"—that is, "one key does only one thing."

[0282] as well as These are two different secret keys managed internally by the platform. Following best security practices for key separation, Specifically designed for encryption to ensure the confidentiality of the token's contents; and Specifically designed for generating HMACs to ensure the integrity and immutability of tokens. Assigning encryption / decryption and authentication functions to different keys prevents potential cryptographic attacks.

[0283] The platform will (migration token) Token message authentication code )and This information is sent to the terminal via the secure channel of the first secure session, SessionA. The terminal stores this information.

[0284] Step S802: The terminal initiates a fast re-authentication request.

[0285] After Session A is interrupted and the terminal switches networks, it sends a fast re-authentication request to the platform:

[0286] ,

[0287] in, To expedite re-authentication requests, It is a data packet generated and encrypted by the platform. It is a message authentication code used to verify the token. It is a new random value generated by the terminal.

[0288] It is an abbreviation for Fast Re-authentication Request. This is a message type identifier that tells the platform "This is a fast re-authentication request, not a normal initial authentication request".

[0289] Step S803: The platform verifies the token and derives a new session key.

[0290] Platform verification and The validity of the information (including validity period, terminal identity, etc.).

[0291] If effective, the platform receives... .

[0292] The platform generates new platform random numbers. Second security session, new session .

[0293] Platform usage , and Derive a new session authentication key and session encryption key :

[0294] ,

[0295] ,

[0296] in, It is the pre-master key B recovered after the platform decrypts the migration token. It is a new random number generated by the terminal for the new session. It is a new random number generated by the platform for a new session. Derived function for key. The context string used in the re-authentication process to derive the authentication key. The context string used to derive the encryption key during the re-authentication process.

[0297] Step S804: The platform responds and completes the re-authentication.

[0298] The platform uses a new derivative Calculate the message authentication code:

[0299] ,

[0300] Response message:

[0301] ,

[0302] in, This is the identifier for session B. The message authentication code for the re-authentication process.

[0303] Step S805: The terminal derives a new session key and verifies it.

[0304] The terminal uses its stored premaster key as well as .

[0305] Derive the authentication key of session B derived from the terminal. Encryption key of session B derived from the terminal .

[0306] Terminal computing And verify whether it matches the received Consistent.

[0307] If verification is successful, a new secure session, SessionB, will be established. .

[0308] Initial key negotiation based on elliptic curve public key encryption:

[0309] This embodiment provides an alternative or enhanced pre-shared master key. The method involves negotiating the initial session authentication key using elliptic curve cryptography (ECC). or for secure distribution This method can be combined with the DoS defense mechanism in Example 1. (Refer to...) Figure 5 .

[0310] Prerequisite: The platform possesses a long-term ECC key pair. ), public key The key can be publicly available or verified via a certificate. The terminal can dynamically generate temporary ECC key pairs. It is the platform's private key. This refers to the point of origin or the base point.

[0311] Step S901: The terminal initiates a request containing the ECC public key.

[0312] After the puzzle is solved, the terminal generates a temporary ECC key pair. ).

[0313] in, This is the terminal's temporary private key. This is the temporary public key for the terminal.

[0314] The terminal's request message contains :

[0315] ,

[0316] in, It's a registration request. It is the platform identifier that the terminal wants to connect to. It is a terminal random number. It is the terminal timestamp. It refers to the puzzle challenge value and the solution. It is the terminal's temporary public key.

[0317] Step S902: The platform verifies the request, generates a shared key, and responds.

[0318] The platform verifies the puzzle solution (if a puzzle mechanic was used) and The effectiveness.

[0319] The platform uses its private key and the terminal's temporary public key Computing part of the shared secret,

[0320] For example (If static ECDH (Elliptic Curve Diffie-Hellman) is used).

[0321] The solution is not an unknown variable, but a computational process. It means the platform uses its own private key. and the terminal's public key Performing a dot product operation on an elliptic curve yields a shared secret value that only the two communicating parties can calculate. It is a secret shared in the middle.

[0322] A more common approach that provides forward security is to use ephemeral elliptic curve Diffie-Hellman (ECDHE) key exchange.

[0323] The platform also generates its own temporary ECC key pair. ).

[0324] in, This is the platform's temporary private key. This is the platform's temporary public key.

[0325] The platform uses its own temporary private key and the terminal's temporary public key Computational shared secrets .

[0326] Platform based on (as well as Platform generated (etc.) derive session authentication keys and session key identifier :

[0327] ,

[0328] ,

[0329] in, To share secrets, For terminal random numbers, It's a random number generated by the platform. It is the authentication key for the session. It is a session identifier.

[0330] The platform can use its long-term private key For key negotiation parameters (such as) Sign .

[0331] Platform response message:

[0332] .

[0333] in, It is the platform's timestamp.

[0334] Step S903: The terminal calculates the shared key, verifies the signature, and derives the session key.

[0335] The terminal receives the response and verifies it. The validity of the terminal is determined by its temporary private key. and the platform's temporary public key Computational shared secrets .

[0336] due

[0337] Terminal verification signature (A trusted platform public key is required) ).

[0338] If the signature is valid, the terminal uses... Derived from the same KDF platform and .

[0339] The subsequent process is consistent with step S204 of the "Method for Derivation and Enhancement of Session Authentication Key Based on Master Key". Perform authentication and subsequent operations. If this method is used for distribution... ,but It can itself serve as Or used for encrypted transmission .

[0340] Example 3 is another embodiment of the present invention. This embodiment also provides an electronic device applicable to a secondary authentication method for a power system digital terminal based on quantum key distribution, comprising: a memory and a processor; the memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement the secondary authentication method for a power system digital terminal based on quantum key distribution as proposed in the above embodiments.

[0341] This embodiment also provides a storage medium storing a computer program that, when executed by a processor, implements a quantum key-based secondary authentication method for digital terminals in power systems, as proposed in the above embodiments.

[0342] The storage medium proposed in this embodiment belongs to the same inventive concept as the method for secondary authentication of a power system digital terminal based on quantum key distribution proposed in the above embodiments. Technical details not described in detail in this embodiment can be found in the above embodiments, and this embodiment has the same beneficial effects as the above embodiments.

[0343] Based on the above description of the implementation methods, those skilled in the art can clearly understand that the present invention can be implemented using software and necessary general-purpose hardware, and of course, it can also be implemented using hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as a computer floppy disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk, or optical disk, etc., including several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods of the various embodiments of the present invention.

[0344] It should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to preferred embodiments, those skilled in the art should understand that modifications or equivalent substitutions can be made to the technical solutions of the present invention without departing from the spirit and scope of the technical solutions of the present invention, and all such modifications or substitutions should be covered within the scope of the claims of the present invention.

Claims

1. A secondary authentication method for digital terminals in power systems based on quantum key distribution, characterized in that: include, The master key is pre-shared between the terminal and the platform; The terminal sends a session authentication key request containing a first random value to the platform. After receiving the request, the platform generates a second random value; The platform derives the session authentication key based on the master key, the first random value, and the second random value through the first key derivation function; The platform sends the second random value to the terminal; Based on the master key, the first random value, and the second random value, the terminal derives the same session authentication key as the platform through the first key derivation function. The terminal and the platform use a session authentication key to complete the two-way authentication process. When the terminal initiates a session authentication key request, the request includes a first timestamp; Before deriving the session authentication key from the platform, verify whether the first timestamp is within the preset first time window; The platform includes a second timestamp in the response sent to the terminal; The terminal verifies whether the second timestamp is within a preset second time window before deriving the session authentication key; The input to the first key derivation function includes a first timestamp and a second timestamp; After the terminal and the platform complete the two-way authentication process, the terminal and the platform negotiate encryption parameters. The encryption parameters are derived from the session authentication key and the negotiated third and fourth random values, and the session encryption key is derived through the second key derivation function. Before the terminal communicates with the platform using the session encryption key, the process includes: the terminal encrypting a first known vector using the session encryption key and sending it to the platform; The platform uses the currently derived session encryption key to decrypt and verify the first known vector to confirm that the terminal has correctly derived the session encryption key; The platform uses the session encryption key to encrypt the second known vector and sends it to the terminal; The terminal uses the currently derived session encryption key to decrypt and verify the second known vector to confirm that the platform has correctly derived the session encryption key; The terminal and the platform act as each other as communication senders and receivers; The communication sender appends an incrementing sequence number to each application data message to be sent, and uses a session encryption key to encrypt and authenticate the message with the appended sequence number. After the receiving party decrypts and authenticates the received message, it verifies whether the sequence number in the message is the expected sequence number, thus completing the detection of message loss, out-of-order delivery, or replay.

2. The quantum key-based secondary authentication method for digital terminals in power systems as described in claim 1, characterized in that: The terminal performs time synchronization verification when communicating with the platform using a session encryption key; The terminal records the local transmission time t1 and sends a time synchronization request message containing t1 to the platform in an encrypted manner; The platform records the local time t2 when the request is received and the local time t3 when the response is prepared, and sends the time synchronization response message containing t1, t2, and t3 to the terminal in an encrypted manner; The terminal records the local time t4 of the received response and calculates the clock offset between the terminal and the platform based on t1, t2, t3, and t4. Sending encrypted data to the terminal or platform also includes refreshing the session key; The terminal or platform initiates a refresh request, and both parties exchange new random values; Based on the current session authentication key and the new random value, the terminal and the platform derive a new session authentication key and a new session encryption key; Before the terminal initiates a session authentication key request, steps to defend against denial-of-service attacks are also included. The platform sends a computational puzzle to the terminal, which then solves the puzzle to obtain the solution. The terminal includes the puzzle solution in the current session authentication key request; Before deriving the session authentication key, the platform verifies the validity of the puzzle solution.

3. The quantum key-based secondary authentication method for digital terminals in power systems as described in claim 2, characterized in that: The method for establishing the master key is that the terminal and the platform perform an elliptic curve key exchange protocol to negotiate a shared secret; the terminal and the platform derive the master key based on the shared secret.

4. The quantum key-based secondary authentication method for digital terminals in power systems as described in claim 3, characterized in that: After the terminal and the platform complete the two-way authentication process using the session authentication key, they enter the first security session. The platform generates a migration token and a pre-master key and sends them to the terminal. When the first secure session is interrupted, the terminal initiates a fast re-authentication request, which includes a migration token and a new terminal random value; After the platform verifies the validity of the migration token, it derives a new session key from the pre-master key and a new random value with the terminal to establish a second secure session.

5. A computer device comprising a memory and a processor, wherein the memory stores a computer program, characterized in that, When the processor executes the computer program, it implements the steps of the quantum key-based secondary authentication method for digital terminals in power systems according to any one of claims 1 to 4.

6. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the secondary authentication method for a power system digital terminal based on quantum key distribution, as described in any one of claims 1 to 4.

Images