A shore-sea collaborative ship-shore grid cross-domain authentication key agreement method

Abstract

The application discloses a shore-sea cooperation-oriented ship-shore lattice cross-domain authentication key negotiation method, which comprises the following steps: a three-layer architecture of a security center (SC), a shore-based communication station (CRS) and an intelligent ship (VSL) is adopted to perform ship-shore lattice cross-domain authentication key negotiation; in the process of initial authentication key negotiation, the shore-based communication station (CRS) issues a cross-domain token to the intelligent ship (VSL) when the intelligent ship (VSL) and the shore-based communication station (CRS) interact with each other; after entering the cross-domain authentication key negotiation stage, the intelligent ship (VSL) only needs to present the cross-domain token held in hand to the newly accessed shore-based communication station (CRS), and the new shore-based communication station (CRS) verifies the cross-domain token. According to the three-level architecture of the security center (SC), the shore-based communication station (CRS) and the intelligent ship (VSL), the efficient lattice cross-domain authentication key negotiation between the intelligent ship and the shore-based communication station is realized based on ring learning with errors (RLWE), in combination with the cross-domain token and the proxy signature mechanism.

Description

Technical Field

[0001] This invention relates to the fields of intelligent shipping communication security and IoT identity authentication key negotiation technology. Specifically, it discloses a ship-shore grid-based cross-domain authentication key negotiation method for shore-sea collaboration, which is applicable to secure communication of multi-node collaboration in intelligent shipping scenarios and realizes identity privacy protection and rapid cross-domain authentication between intelligent ships and shore-based communication stations. Background Technology

[0002] With the development of smart shipping technology, smart ships (VSLs) need to obtain cross-domain tokens and report their navigation status through shore-based communication stations (CRS). However, the openness of maritime wireless channels and the complexity of heterogeneous shore-sea trust architectures expose this interaction process to serious security threats such as identity impersonation and data tampering. Furthermore, traditional encryption algorithms are vulnerable to attacks from quantum computing. Therefore, how to achieve secure and efficient cross-domain identity authentication and key negotiation in heterogeneous shore-sea environments has become a critical technical problem that urgently needs to be solved. Specifically, the main security risks are as follows:

[0003] 1. Identity authentication risk: The openness of wireless channels allows attackers to impersonate legitimate smart ships or shore-based communication stations, thereby stealing sensitive navigation data;

[0004] 2. Privacy leakage risk: If the true identities of smart ships and shore-based communication stations are transmitted directly in plaintext, they are easily tracked by attackers, thereby threatening the privacy of navigation tracks and operational behaviors;

[0005] 3. Low efficiency of cross-domain token update interaction: Traditional cross-domain tokens need to frequently request updates from the Security Center (SC), which increases the computing burden and communication latency of smart ships;

[0006] 4. Low efficiency of cross-domain authentication: When a smart ship moves to the communication coverage area of ​​a new shore-based communication station, it needs to re-negotiate the authentication key with the new shore-based communication station, which affects the efficiency of maritime navigation.

[0007] Existing authentication key negotiation schemes largely rely on traditional large integer factorization and elliptic curve discrete logarithm operations, which are vulnerable to quantum algorithms (such as Shor's algorithm) and cannot withstand quantum attacks. Furthermore, they lack two-way identity privacy protection for smart ships and shore-based communication stations. Simultaneously, the high mobility of smart ships leads to frequent cross-domain switching, and shore-based communication stations have limited processing capabilities, unable to handle real-time interactions in high-concurrency scenarios. Therefore, an efficient lattice-based cross-domain authentication key negotiation scheme is needed to meet the practical needs of smart shipping. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of the prior art and provide a ship-shore grid-based cross-domain authentication key negotiation method for shore-sea collaboration. Through a three-level architecture of "Security Center (SC) - Shore-based Communication Station (CRS) - Intelligent Ship (VSL)," based on on-ring error learning (RLWE), and combined with cross-domain tokens and proxy signature mechanisms, it realizes efficient grid-based cross-domain authentication key negotiation between intelligent ships and shore-based communication stations.

[0009] To achieve the above objectives, the technical solution adopted by the present invention is as follows:

[0010] A method for ship-shore grid-based cross-domain authentication key negotiation for shore-sea collaboration includes a three-layer architecture of Security Center (SC), shore-based Communication Station (CRS), and Intelligent Ship (VSL) for ship-shore grid-based cross-domain authentication key negotiation. During the initial authentication key negotiation process, when the Intelligent Ship (VSL) and the shore-based communication station (CRS) interact, the shore-based communication station (CRS) issues a cross-domain token to the Intelligent Ship (VSL). After entering the cross-domain authentication key negotiation stage, the Intelligent Ship (VSL) only needs to present the cross-domain token it holds to the newly connected shore-based communication station (CRS), and the new shore-based communication station (CRS) verifies the cross-domain token.

[0011] The ship-to-shore cross-domain authentication key negotiation process includes the following steps:

[0012] Step 1: The security center initializes core parameters, including the configuration of parameters for the polynomial ring and discrete Gaussian distribution based on the learning with error on rings (RLWE) problem, the selection and definition of cryptographic primitives and auxiliary functions, the generation of the system master key pair, and the public disclosure of global system parameters;

[0013] Step 2: Entity registration, which includes smart ships and shore-based communication stations registering with the security center to obtain relevant information;

[0014] Step 3: Initial Smart Ship Authentication Key Negotiation and Cross-Domain Token Issuance. During the authentication key negotiation between the smart ship and the shore-based communication station within its coverage area, the shore-based communication station authorized by the security center issues a cross-domain token to the smart ship.

[0015] Step 4: Rapid authentication of cross-shore communication stations. When a smart ship moves into the coverage area of ​​a new shore-based communication station, the new shore-based communication station verifies the cross-domain token signature.

[0016] Step 5: Entity pseudo-identity update. Smart ships and shore-based communication stations periodically generate new pseudo-identities to protect navigation privacy.

[0017] In step one, the parameter initialization method includes:

[0018] The Safety Center (SC) selects a polynomial ring based on on-ring error learning (RLWE). and discrete Gaussian distribution Define the ring dimension as Large prime numbers are The standard deviation of the discrete Gaussian distribution takes the value of ;

[0019] The difficult problem of learning with errors on rings (RLWE) includes two variations:

[0020] ① Search-based RLWE; ② Decision-based RLWE

[0021] Define characteristic function Used to assist the communicating party in recovering consistent key bits from its own approximate shared values;

[0022] Define the modulo function It can extract completely identical key bit sequences;

[0023] Define a hash function: , ;

[0024] Define the Generalized Lattice Signature Scheme (GLS): Based on the lattice problem, it generates unforgeable digital signatures to verify the integrity and authenticity of messages, and supports public verification;

[0025] Define a public-key encryption algorithm based on RLWE: Quantum-resistant public-key encryption is achieved based on the learning with error on rings (RLWE) problem, ensuring the confidentiality of messages on public channels, and only the holder of the corresponding private key can decrypt them;

[0026] Generate SC master key pair: private key ( ), public key ,in , ;

[0027] Public system parameters: .

[0028] In step two, the method for registering the Smart Ship License (VSL) with the Safety Center (SC) includes:

[0029] The Smart Ship License (VSL) submits registration messages to the Security Center (SC) via a physical security channel. ,in To verify the true identity of the smart ship's VSL, the VSL's public key is... , It is its public key component. For tracking tags;

[0030] After receiving the registration message from the Smart Ship VSL, the Security Center (SC) generates a pseudo-identity for the Smart Ship VSL. Issuing certificates for VSL (Variable Speed ​​List) for intelligent ships Generate certificate expiration time ,storage and return a response message. ;

[0031] After receiving the response message from the Safety Center (SC), the Intelligent Vessel (VSL) stores... .

[0032] In step two, the method for the shore-based communication station CRS to register with the security center SC includes:

[0033] The shore-based communication station (CRS) submits a registration message to the Security Center (SC) via a physical security channel. ,in To verify the true identity of the shore-based communication station CRS, the public key of CRS is... , It is its public key component. For tracking tags;

[0034] After receiving the registration message from the shore-based communication station CRS, the Security Center (SC) generates a fake identity for the shore-based communication station CRS. Generate agent expiration time for CRS of shore-based communication stations. Calculate hash components Generate proxy components and ,storage and return a response message. ;

[0035] After receiving the response message from the Security Center (SC), the shore-based communication station CRS calculates the proxy private key component. and Obtain the proxy private key Calculate the proxy public key component Obtain the corresponding proxy public key and store .

[0036] In step three, the method for initial CRS authentication key negotiation includes:

[0037] Smart Ship VSL Sends Messages The temporary public key for VSL is... , For VSL's temporary public key component, This is the current timestamp. Yes and Signature;

[0038] Initial shore-based communication station After verifying the smart ship's VSL identity, send a message. ,in The temporary public key is , for The temporary public key component, and It is an intermediate variable used to generate the session key. It is the ciphertext of the cross-domain token payload. This is the current timestamp. It is a cross-domain token signature;

[0039] Smart Ship VSL Validation Identity, derived session key Send message ,in It is an intermediate variable used to generate the session key. It's a verification code;

[0040] Derived session key .

[0041] In step four, the method for cross-CRS fast authentication includes:

[0042] Smart ship VSL to new shore-based communication station Send message ,in It is the ciphertext obtained by encrypting the cross-domain token payload and the random value selected by VSL. This is the current timestamp;

[0043] New Shore Base Communication Station After verifying the validity of the cross-domain token, derive the session key. Send message ,in Yes The ciphertext obtained by encrypting the selected random value It's a verification code. This is the current timestamp;

[0044] VSL Validation Identity, derived session key .

[0045] In step five, the method for updating the entity's pseudo-identity is as follows: the security center SC updates the entity e's current real identity. Public key With current timestamp Generate new pseudo-identities Update storage mappings and synchronize with entities. .

[0046] The method also includes step six: malicious entity tracking. When a malicious entity does something wrong, the Security Center (SC) tracks it. If the Security Center is corrupted and colludes with the malicious entity to frame an honest entity, the honest entity will release evidence to prove its innocence.

[0047] Step six includes methods for tracking malicious entities, including:

[0048] (1) Honesty SC

[0049] When a malicious entity acts maliciously, SC publishes tracking evidence to track the malicious entity and publicly verifies this tracking.

[0050] (2) Corruption SC

[0051] When SC is corrupted and colludes with malicious entities to frame honest entities, the honest entities release evidence to prove their innocence.

[0052] The advantages of this invention are as follows: A solution for efficient cross-domain authentication: This solution utilizes Learning with On-Ring Error (RLWE) as a fundamental number theory tool and integrates cross-domain tokens and proxy signature mechanisms to achieve efficient lattice-based cross-domain authentication key negotiation between intelligent ships and shore-based communication stations, thus possessing the ability to resist quantum attacks; In subsequent authentication key negotiation between the VSL and the new CRS, the single-round interaction method reduces the computational and signaling overhead generated during communication, while also lightweighting the communication load on the CRS side. This perfectly matches the real-time interaction requirements of the VSL under high-concurrency access scenarios;

[0053] Solution to the authentication architecture problem: Traditional solutions are inefficient when dealing with authentication key negotiation between smart ships and shore-based communication stations. To address this, this solution adopts a three-tier architecture of "Security Center (SC) - Shore-based Communication Station (CRS) - Smart Ship (VSL)". During the initial authentication key negotiation, when VSL and CRS interact, CRS issues a cross-domain token to VSL. After entering the cross-domain authentication key negotiation stage, VSL only needs to present the cross-domain token it holds to the newly connected CRS. The new CRS verifies the cross-domain token, without having to repeat the issuance step for VSL. This arrangement facilitates rapid handover in cross-domain situations and efficient collaboration between shore-based communication stations.

[0054] Security solutions: First, during the entity registration phase, SC assigns corresponding pseudo-identities to VSL and CRS to hide their real identity information and supports periodic updates to these pseudo-identities. No entity other than SC can know the real identities of VSL and CRS, thus ensuring privacy and security during maritime and shore navigation. Second, this solution employs cross-domain tokens and proxy signature mechanisms, enabling efficient cross-domain authentication key negotiation between VSL and CRS while preventing other entities from forging cross-domain tokens. Third, SC only locates the real identity of malicious VSL or CRS when it is necessary to trace malicious behavior, thus achieving robust tracing. Attached Figure Description

[0055] The following is a brief explanation of the contents of each of the accompanying drawings and the markings in the drawings:

[0056] Figure 1 This is a schematic diagram of the registration process for the intelligent ship VSL of this invention;

[0057] Figure 2 This is a schematic diagram of the registration process of the shore-based communication station CRS of the present invention;

[0058] Figure 3 This is a schematic diagram of the initial authentication key negotiation process of this invention;

[0059] Figure 4 This is a schematic diagram of the cross-domain authentication key negotiation process of the present invention;

[0060] Figure 5 This is an application scenario architecture diagram of the ship-shore grid-based cross-domain authentication key negotiation method for shore-sea collaboration according to the present invention. Detailed Implementation

[0061] The specific embodiments of the present invention will be further described in detail below with reference to the accompanying drawings and the description of the preferred embodiments.

[0062] This solution relates to the fields of intelligent shipping communication security and IoT identity authentication key negotiation. Specifically, it discloses a lattice-based cross-domain authentication key negotiation method for intelligent vessels (VSLs) and shore-based communication stations (CRSs) in shore-sea collaboration. This method is applicable to secure communication in multi-node collaboration scenarios in intelligent shipping, achieving identity privacy protection and rapid cross-domain authentication for intelligent vessels and shore-based communication stations. The specific steps include: Step 1: Initialization of core parameters of the Security Center (SC); Step 2: Registration of the intelligent vessel (VSL) and shore-based communication station (CRS) with the SC; Step 3: Initial CRS authentication key negotiation and cross-domain token issuance (CRS generation); Step 4: Rapid cross-CRS authentication key negotiation; Step 5: Fake identity update of the intelligent vessel and shore-based communication station; Finally, the SC performs tracking of malicious intelligent vessels and malicious shore-based communication stations.

[0063] This scheme proposes a ship-shore grid-based cross-domain authentication key negotiation method for shore-sea collaboration. It employs a three-layer architecture—Security Center (SC), Shore-based Communication Station (CRS), and Intelligent Ship (VSL)—for ship-shore grid-based cross-domain authentication key negotiation. During the initial authentication key negotiation process, when the Intelligent Ship (VSL) and the Shore-based Communication Station (CRS) interact, the Shore-based Communication Station (CRS) issues a cross-domain token to the Intelligent Ship (VSL). Once the cross-domain authentication key negotiation phase begins, the Intelligent Ship (VSL) only needs to present its cross-domain token to the newly connected Shore-based Communication Station (CRS), which then verifies the cross-domain token.

[0064] like Figure 1-5 As shown, a method for ship-shore grid-based cross-domain authentication key negotiation for shore-sea collaboration includes the following steps:

[0065] Step 1: The security center initializes core parameters, including the configuration of parameters for the polynomial ring and discrete Gaussian distribution based on the learning with error on rings (RLWE) problem, the selection and definition of cryptographic primitives and auxiliary functions, the generation of the system master key pair, and the public disclosure of global system parameters;

[0066] Step 2: Entity registration, including smart ships and shore-based communication stations registering with the security center to obtain relevant information; ensuring the legitimacy of subsequent authentication key negotiations;

[0067] Step 3: Initial Smart Ship Authentication Key Negotiation and Cross-Domain Token Issuance. During the authentication key negotiation between the smart ship and the shore-based communication station within its coverage area, the shore-based communication station authorized by the security center issues a cross-domain token to the smart ship; Initial CRS Authentication and Cross-Domain Token Issuance (CRS Generation), VSL Entry. After coverage, with When performing authentication key negotiation, Issue a cross-domain token to VSL;

[0068] Step 4: Cross-shore communication station rapid authentication. When a smart vessel moves to the coverage area of ​​a new shore-based communication station, the new shore-based communication station verifies the cross-domain token signature without requiring a re-request from the new shore-based communication station; cross-CRS rapid authentication (VSL does not require re-request), VSL moves to the new CRS ( When covering the area, there is no need to re-apply to [the relevant authority / resource]. Request a cross-origin token, by Verify the cross-domain token status;

[0069] Step 5: Entity (smart ship and shore-based communication station) pseudo-identity update. Entities interact with the outside world through pseudo-identities (temporary communication identifiers), which can hide the real identity ID without affecting necessary data exchange. Regularly updating pseudo-identities can sever the spatiotemporal correlation between the old and new identifiers, making the old trajectory invalid and the new identity untraceable, thereby effectively preventing the entity from being continuously tracked and protecting navigation privacy.

[0070] Step Six: Tracking Malicious Entities (Unauthorized smart ships or shore-based communication stations attempting to forge identities or interfere with communications). When a malicious entity acts maliciously (such as impersonating a legitimate entity to launch an attack), the security center tracks it. Anyone can publicly verify the authenticity of the tracking results by verifying the smart ship's certificate or the shore-based communication station's cross-domain token signature. If the security center is corrupted (i.e., it violates the "absolute trust" assumption and abuses its highest management authority) and colludes with malicious entities to frame honest entities, the honest entities can publish evidence (identity ID, public key, and secret value) to prove their innocence.

[0071] In step one, the Security Center (SC) performs the core parameter initialization as follows:

[0072] SC selects polynomial rings based on learning with error on the ring (RLWE). and discrete Gaussian distribution Define the ring dimension as (Powers of 2), a large prime number q, satisfies The standard deviation of the discrete Gaussian distribution takes the value of ;

[0073] The difficult problem of learning with errors on rings (RLWE) includes two variations:

[0074] ① Search-RLWE: Given a polynomial number of samples No probabilistic multinomial-time algorithm can recover the private key with a non-negligible probability. ;

[0075] ② Decision-RLWE: It is computationally infeasible to distinguish between the following two distributions: RLWE distribution With ring Uniform random distribution on In other words, the advantage of any probabilistic multinomial-time algorithm in distinguishing between the two is negligible.

[0076] Define characteristic function Used to assist the communicating party in recovering consistent key bits from its own approximate shared values;

[0077] The ring element to be processed Each coefficient and preset threshold The coefficients are compared; if the absolute value of the coefficient is less than or equal to the threshold, a bit 0 is output; otherwise, a bit 1 is output. The output bits corresponding to all coefficients constitute a signal vector. ;

[0078] Define the modulo function It can extract completely identical key bit sequences;

[0079] Get the element to be processed and signal vector For each coefficient position, calculate the correction value. Then to Perform the model The operation is performed, followed by a modulo-2 operation to obtain the final bits; the bits corresponding to all coefficients constitute the original material of the session key. This definition assumes that the difference norm of the shared values ​​between the communicating parties is less than a preset threshold. ;(in The noisy shared secret coefficients are calculated locally. These are interval indicator bits, generated by a characteristic function, indicating... It falls within the left / right half of the number line; It is a large prime number modulo; These are the corrected coordinates after translation. and (Together, ensure consistent key bit extraction under error conditions)

[0080] Define a hash function: , ,in For binary strings of arbitrary length, Challenge value in signature The set of elements whose order is less than 1. The coefficients are taken from The polynomials consisting of no more than 32 non-zero coefficients are also included. The output length is 320 bits. This indicates SHA3-256, with an output length of 256 bits.

[0081] Define the Generalized Lattice Signature Scheme (GLS): Based on the lattice problem, it generates unforgeable digital signatures to verify message integrity and authenticity, supporting public verification. The steps are as follows:

[0082] ①Key generation: Among them, the private key Public key .

[0083] ②Signature: The signature .

[0084] ③Verification: The output 1 indicates acceptance, and 0 indicates rejection.

[0085] Define a public-key encryption algorithm based on RLWE: Implement quantum-resistant public-key encryption based on the on-ring error learning (RLWE) problem, ensuring message confidentiality over public channels, with decryption only possible by the holder of the corresponding private key. The steps are as follows:

[0086] ①Key generation: The public key private key .

[0087] ② Encryption: Among the messages Considered The 0-1 coefficient polynomial in the ciphertext .

[0088] ③ Decryption: Output recovery message .

[0089] Generate SC master key pair: private key Public key ;(in , ; Indicates ring A discrete Gaussian distribution on [a_1, b_2, b_3] with a standard deviation of [a_1, b_2, b_3]. ; The ring elements are randomly and uniformly selected and used as common parameters of the system. For the public key component of SC, calculate as follows: Multiplication and addition are both in the ring. Execute above, coefficients according to modulus (Return)

[0090] Public system parameters: .

[0091] In step two, the specific method for VSL to register with SC is as follows:

[0092] VSL submits registration messages to SC via a physical secure channel. ,in To verify VSL's true identity, VSL's public key is... , For the public key component of VSL, For VSL tracking labels, , A secret value randomly selected for VSL;

[0093] After receiving the registration message from VSL, SC generates a pseudo identity for VSL. Issuing certificates for VSL Generate certificate expiration time ,storage and return a response message. ;

[0094] After receiving the response message from the SC, the VSL stores it. ,in , This is the private key for VSL.

[0095] In step two, the specific method for CRS to register with SC is as follows:

[0096] CRS submits registration messages to SC via a physical security channel. ,in To verify the true identity of CRS, the public key of CRS is... , For the public key component of CRS, For CRS tracking labels, , A secret value randomly selected for CRS;

[0097] After receiving the registration message from CRS, the Security Center (SC) generates a fake identity for CRS. Generate agent expiration time for CRS Calculate hash components Generate proxy components and ,storage and return a response message. ;

[0098] After receiving the response message from SC, CRS calculates the proxy private key component. and Obtain the proxy private key Calculate the proxy public key component Obtain the corresponding proxy public key and store ,in , This is the private key for CRS.

[0099] In step three, the specific method for initial CRS authentication key negotiation includes:

[0100] VSL Send Message The temporary public key for VSL is... , For VSL's temporary public key component, This is the current timestamp. Yes and The signature;

[0101] Initial shore-based communication station After verifying the VSL's identity, send a message. ,in yes A false identity The temporary public key is , for The temporary public key component, and It is an intermediate variable used to generate the session key. It is the ciphertext of the cross-domain token payload. This is the current timestamp. It is a cross-domain token signature;

[0102] VSL Validation Identity, derived session key Send message ,in It is an intermediate variable used to generate the session key. It's a verification code;

[0103] Derived session key .

[0104] In step four, the specific methods for cross-CRS fast authentication include:

[0105] VSL new CRS when crossing domains ( Send message ,in It is the ciphertext obtained by encrypting the cross-domain token payload and the random value selected by VSL. This is the current timestamp;

[0106] New Shore Base Communication Station After verifying the validity of the cross-domain token, derive the session key. Send message ,in yes A false identity Yes The ciphertext obtained by encrypting the selected random value It's a verification code. This is the current timestamp;

[0107] VSL Validation Identity, derived session key .

[0108] In step five, the specific method for updating the pseudo-identity of entities (smart ships and shore-based communication stations) is as follows:

[0109] SC based on the current real identity of entity e Public key With current timestamp Generate new pseudo-identities Update storage mappings and synchronize with entities. .

[0110] In step six, the specific methods for tracking malicious entities include:

[0111] (1) Honest SC (Security Center that strictly adheres to protocol specifications, does not act maliciously, and has not been compromised)

[0112] When a malicious entity (an unauthorized smart vessel or shore-based communication station attempting to forge an identity or interfere with communications) acts maliciously, such as by impersonating a legitimate entity to launch an attack, the SC can publish tracking evidence (the real ID, tracking tag, expiration time, and certificate corresponding to the malicious smart vessel, or the real ID, tracking tag, expiration time, signed cross-domain token, and cross-domain token signature corresponding to the malicious shore-based communication station) to track the malicious entity. Anyone can publicly verify the authenticity of the tracking results by verifying the smart vessel certificate or the cross-domain token signature of the shore-based communication station.

[0113] (2) Corrupting SC (violating the "absolute trust" assumption and abusing the highest management authority of the security center)

[0114] When SC is corrupted and colludes with malicious entities to frame honest entities, attempting to pin malicious actions on honest entities, honest entities can publish evidence (identity ID, public key, and secret value) to prove their innocence, thereby confirming that SC has engaged in corrupt practices.

[0115] Malicious entities (illegal smart ships or shore-based communication stations attempting to forge identities or interfere with communications) are tracked. When a malicious entity acts maliciously (such as impersonating a legitimate entity to launch an attack), the security center tracks it. Anyone can publicly verify the authenticity of the tracking results by verifying the smart ship's certificate or the shore-based communication station's cross-domain token signature. If the security center is corrupted (i.e., it violates the "absolute trust" assumption and abuses its highest management authority) and colludes with malicious entities to frame honest entities, the honest entities can publish evidence (identity ID, public key, and secret value) to prove their innocence.

[0116] As a further aspect of the present invention: In step two, the specific method for entity registration (VSL / CRS registration with SC) is as follows:

[0117] Intelligent Ship (VSL) Registration:

[0118] VSL submits its real identity and related information to SC to obtain a pseudo-identity (to protect privacy) and certificate. The steps are as follows:

[0119] VSL generates a real identity. Sample private key Calculate public key components Generate public key Random selection Calculate tracking tags Send registration message via physical security channel ;

[0120] After receiving the registration message from VSL, SC performs the following operations:

[0121]

[0122] Issuing a certificate for VSL: SC uses the master private key sign,

[0123] This refers to the certificate expiration date:

[0124] ;

[0125] storage: ;

[0126] Return response message: ;

[0127] After receiving the response message from SC, VSL performs the following operations:

[0128] storage: .

[0129] Coastal Communication Station (CRS) Registration:

[0130] CRS submits its real identity and related information to SC to obtain a false identity (to protect privacy) and a proxy private key. The steps are as follows:

[0131]

[0132] After receiving the registration message from CRS, SC performs the following operations:

[0133] Generate CRS pseudo-identity: randomly selected

[0134] Generate a fake identity for CRS (Regularly updated to hide real identity);

[0135] Generate proxy expiration time: ;

[0136]

[0137] storage: ;

[0138] Return response message: ;

[0139] After receiving the response message from the SC, the CRS performs the following operations:

[0140] Generate proxy private key Calculate the private key component of the proxy and ;

[0141] Obtain the proxy public key Calculate the proxy public key component ;

[0142] storage: .

[0143] Pre-certification: Smart ships will The broadcast is sent to neighboring shore-based communication stations for pre-verification and buffering. Simultaneously, each shore-based communication station broadcasts periodically. Other shore-based communication stations can pre-verify and store the pseudonyms and proxy public keys of neighboring shore-based communication stations. Through the mutual cooperation of neighboring shore-based communication stations, the smart ship pre-verifies and caches the pseudonyms and proxy public keys of shore-based communication stations.

[0144] As a further aspect of the present invention: in step three, initially... The specific method for authentication key negotiation is as follows:

[0145] VSL Entry After coverage, with When performing authentication key negotiation, obtain The steps to issue a cross-domain token are as follows:

[0146] ①VSL

[0147] VSL generates temporary public keys Random sampling Calculate the temporary public key component ;

[0148] Generate a signature: using the private key pair Sign ( (current timestamp)

[0149] ;

[0150] Send message: .

[0151] ②CRS1

[0152] take over Then, perform the following operations:

[0153] Current timestamp verification: Check ;

[0154]

[0155] ;

[0156]

[0157] Generate intermediate variables used to generate the session key: Calculate , ;

[0158] Encrypted cross-domain token payload:

[0159] ( (current timestamp);

[0160] Send message: .

[0161] ③VSL

[0162] VSL Receive Then, perform the following operations:

[0163] Current timestamp verification: Check the current time ;

[0164] generate The corresponding values ​​of the intermediate variables used to generate the session key: Calculate

[0165] ;

[0166] Restore cross-domain token load balancer:

[0167] ;

[0168] Verify cross-domain token signature: using proxy public key Verify cross-domain token:

[0169] ;

[0170] Generate intermediate variables used to generate the session key: Calculate , ;

[0171] Generate verification code:

[0172] ( (current timestamp);

[0173] Derived session key: ;

[0174] Storage: Local storage As a subsequent cross-domain authentication credential; send the message: ;

[0175] ④

[0176] Perform the following operations:

[0177] Current timestamp verification: Check the current time ;

[0178] generate The corresponding values ​​of the intermediate variables used to generate the session key: Calculate

[0179]

[0180] Check the verification code:

[0181] ;

[0182] Derived session key:

[0183] ;

[0184] As a further aspect of the present invention: In step four, the specific method for cross-CRS fast authentication is as follows:

[0185] VSL moved to the new CRS ( When covering the area, there is no need to re-apply to [the relevant authority / resource]. Request a cross-origin token, by To verify the cross-domain token status, follow these steps:

[0186] ①VSL

[0187] VSL Entry When covering the area, perform the following operations:

[0188] Encryption: Select random value ,use public key Encrypted cross-domain token payload and random value:

[0189] ;

[0190] Send message: ( (current timestamp)

[0191] ②

[0192] Perform the following operations:

[0193] Current timestamp verification: Check the current time ;

[0194] Decryption: Using Decrypt and recover the cross-domain token payload and random number:

[0195] ;

[0196] Verify cross-domain token signature: using proxy public key Verify cross-domain token:

[0197] ;

[0198] Encrypted random value: Select random value ,calculate ;

[0199] Calculate the verification code:

[0200] ;

[0201] Derived session key:

[0202] ;

[0203] Send message: ;

[0204] ③VSL

[0205] VSL Receive Then, perform the following operations:

[0206] Current timestamp verification: Check the current time

[0207] Restore random value: Calculate ;

[0208] Check the verification code: Calculate

[0209] Derived session key: .

[0210] As a further aspect of the present invention: In step five, the specific method for updating the pseudo-identity of intelligent ships (privacy protection) is as follows:

[0211] To prevent entities from being tracked, SC periodically updates its pseudo-identities, following these steps:

[0212] SC based on entity e's current identity Public key With current timestamp Generate new pseudo-identities

[0213] Update storage mappings and synchronize with entities. .

[0214] As a further aspect of the present invention: In step six, the specific method for tracking malicious entities is as follows:

[0215] Malicious smart ship tracking process:

[0216] (1) Honesty SC:

[0217] Malicious smart ship VSL in public key When committing wrongdoing, SC releases tracking evidence. Anyone can use SC's public key to verify

[0218] The tracking will be publicly verified.

[0219] (2) Corruption SC:

[0220] If corrupted SC and malicious smart ships Conspiring to frame the honest intelligent ship VSL, SC In identity The following generation VSL can publish evidence. Verifier calculation ,Discover This proves that SC has been corrupted.

[0221] Tracking process of malicious shore-based communication stations:

[0222] (1) Honesty SC:

[0223] Malicious shore-based communication station CRS in public key When committing wrongdoing, SC releases tracking evidence. ,in It is a cross-domain token signed by CRS, and anyone can verify the cross-domain token signature using a CRS proxy public key. The tracking will be publicly verified.

[0224] (2) Corruption SC:

[0225] If corrupted SC and malicious shore-based communication stations Conspiring to frame the honest shore-based communications station CRS, SC In identity The following generation CRS can publish evidence. Verifier calculation ,Discover This proves that SC has been corrupted.

[0226] Against the backdrop of the continuous development of smart shipping, the deep integration of wireless network and Internet of Things technologies is driving the field forward. The establishment of secure communication links between smart ships and shore-based communication stations provides necessary underlying support for smart ships to obtain navigation-related information and report real-time navigation status. On the other hand, it also empowers shipping management agencies to perceive the real-time movements of smart ships more efficiently, thereby ensuring the safety level and operational efficiency of smart ships during navigation. It should be noted that network channels are often open and lack complete protection measures. At the same time, the computing and storage resources of smart ships themselves are relatively limited. Under the condition of a large number of smart ships accessing the network concurrently, the processing performance and carrying capacity of shore-based communication stations become a key factor restricting the efficiency of interaction.

[0227] The existing intelligent ship authentication key negotiation schemes have the following drawbacks:

[0228] Disadvantage 1: In terms of quantum resistance: Most existing solutions are based on large integer factorization and elliptic curve discrete logarithm problems, which cannot resist quantum attacks;

[0229] Disadvantage 2: In terms of authentication architecture: Existing solutions are mostly limited to authentication key negotiation between smart ships and a single shore-based communication station, which makes it difficult to support efficient collaboration between multiple shore-based communication stations. This means that when smart ships cross domains, they need to re-negotiate authentication keys with new shore-based communication stations, thus affecting navigation efficiency.

[0230] Disadvantage 3: In terms of security, the existing solution still has several obvious shortcomings: First, the privacy protection for the real identities of smart ships and shore-based communication stations is relatively insufficient, making their real identities vulnerable to malicious association and tracking; Second, the security center still needs to intervene in the specific process of authentication key negotiation, which inadvertently broadens the potential attack scope of the system; Third, there is a lack of a reliable verification mechanism for the source of cross-domain token issuance, making it difficult for other shore-based communication stations to directly determine whether the cross-domain tokens they receive are indeed issued by legitimate shore-based communication stations authorized by the security center.

[0231] This application addresses the shortcomings of existing technologies in a targeted manner:

[0232] Solution to improve cross-domain authentication efficiency: To address the problem of low authentication key negotiation efficiency when intelligent ships switch between different shore-based communication stations, this invention adopts a cross-domain token and proxy signature mechanism, combined with lightweight cryptographic primitives such as hash functions and XOR operations. Through a relatively heavy initial authentication key negotiation followed by a lightweight authentication key negotiation, efficient cross-domain authentication key negotiation between intelligent ships and shore-based communication stations is achieved.

[0233] Solution to the authentication architecture problem: Addressing the inefficiency of traditional solutions in authenticating key agreements between smart ships and shore-based communication stations, this solution uses a three-tiered framework of "Security Center (SC) – Shore-based Communication Station (CRS) – Smart Ship (VSL)". The SC only handles offline entity registration without intervening in real-time interaction, while the actual authentication key agreement is handled directly by the VSL and CRS. This arrangement effectively reduces the load on the Security Center, minimizes communication latency and single-point-of-failure risks, and improves the efficiency of cross-domain authentication key agreement and the overall scalability of the system. During registration, the SC assigns periodically updated pseudo-identities to the VSL and CRS, and distributes corresponding proxy components to the CRS. In the initial authentication key agreement phase, when the VSL and CRS begin authentication key agreement, the CRS issues a cross-domain token to the VSL and delivers it via encryption. The VSL then verifies the proxy signature attached to the token to complete the authentication process for the CRS. Identity verification; after entering the cross-domain authentication key negotiation stage, the newly connected CRS can directly verify the cross-domain token held by the VSL without having to reissue it for the VSL, thereby achieving efficient collaboration between CRSs; in addition, this solution allows multiple VSLs to maintain communication connections with the CRS within the same time period, and the CRS issues cross-domain tokens to each VSL to meet the cross-domain authentication key negotiation needs of VSLs in high-concurrency scenarios;

[0234] Security solutions: First, during the registration phase, SC assigns unique pseudo-identities to VSL and CRS, concealing their true identities. This pseudo-identities are periodically updated, preventing any party other than SC from directly associating the real identities of VSL and CRS, thus protecting privacy during navigation. Second, the solution employs cross-domain tokens and proxy signature mechanisms, achieving rapid authentication key negotiation under cross-domain conditions while effectively verifying the trustworthiness of the cross-domain token issuance source. Third, SC only locates the entity's true identity when it is necessary to trace malicious behavior. This design reduces the potential risk of attacks on SC itself while retaining robust tracking capabilities for abnormal entities, thereby enhancing the overall security of the solution.

[0235] Obviously, the specific implementation of this invention is not limited to the above-described methods. Any non-substantial improvements made using the inventive concept and technical solution of this invention are within the protection scope of this invention.

Claims

1. A method for ship-shore grid-based cross-domain authentication key negotiation for shore-sea collaboration, characterized in that: This includes employing a three-tier architecture of Security Center (SC) – Coastal Communication Station (CRS) – Smart Ship (VSL) for ship-shore grid-based cross-domain authentication key negotiation. During the initial authentication key negotiation process, when the Smart Ship (VSL) and the Coastal Communication Station (CRS) interact, the Coastal Communication Station (CRS) issues a cross-domain token to the Smart Ship (VSL). After entering the cross-domain authentication key negotiation phase, the Smart Ship (VSL) only needs to present the cross-domain token it holds to the newly connected Coastal Communication Station (CRS), and the new Coastal Communication Station (CRS) verifies the cross-domain token.

2. The method for ship-shore grid-based cross-domain authentication key negotiation for shore-sea collaboration as described in claim 1, characterized in that: The ship-to-shore cross-domain authentication key negotiation process includes the following steps: Step 1: The security center initializes core parameters, including the configuration of parameters for the polynomial ring and discrete Gaussian distribution based on the learning with error on rings (RLWE) problem, the selection and definition of cryptographic primitives and auxiliary functions, the generation of the system master key pair, and the public disclosure of global system parameters; Step 2: Entity registration, which includes smart ships and shore-based communication stations registering with the security center to obtain relevant information; Step 3: Initial Smart Ship Authentication Key Negotiation and Cross-Domain Token Issuance. During the authentication key negotiation between the smart ship and the shore-based communication station within its coverage area, the shore-based communication station authorized by the security center issues a cross-domain token to the smart ship. Step 4: Rapid authentication of cross-shore communication stations. When a smart ship moves into the coverage area of ​​a new shore-based communication station, the new shore-based communication station verifies the cross-domain token signature. Step 5: Entity pseudo-identity update. Smart ships and shore-based communication stations periodically generate new pseudo-identities to protect navigation privacy.

3. The method for ship-shore grid-based cross-domain authentication key negotiation for shore-sea collaboration as described in claim 2, characterized in that: In step one, the parameter initialization method includes: The Safety Center (SC) selects a polynomial ring based on on-ring error learning (RLWE). and discrete Gaussian distribution Define the ring dimension as Large prime numbers are The standard deviation of the discrete Gaussian distribution takes the value of ; The difficult problem of learning on rings with error (RLWE) includes two variations: ① Search-based RLWE; ② Decision-based RLWE; Define characteristic function Used to assist the communicating party in recovering consistent key bits from its own approximate shared values; Define the modulo function It can extract completely identical key bit sequences; Define a hash function: , ; Define the Generalized Lattice Signature Scheme (GLS): Based on the lattice problem, it generates unforgeable digital signatures to verify the integrity and authenticity of messages, and supports public verification; Define a public-key encryption algorithm based on RLWE: achieve quantum-resistant public-key encryption based on the on-ring error learning RLWE problem, ensuring the confidentiality of messages on public channels, and only the holder of the corresponding private key can decrypt them; Generate SC master key pair: private key ( ), public key ,in , ; Public system parameters: .

4. The method for ship-shore grid-based cross-domain authentication key negotiation for shore-sea collaboration as described in claim 2, characterized in that: In step two, the method for registering the Smart Ship License (VSL) with the Safety Center (SC) includes: The Smart Ship License (VSL) submits registration messages to the Security Center (SC) via a physical security channel. ,in To verify the true identity of the smart ship's VSL, the VSL's public key is... , It is its public key component. It's a tracking tag; After receiving the registration message from the Smart Ship VSL, the Security Center (SC) generates a pseudo-identity for the Smart Ship VSL. Issuing certificates for VSL (Variable Speed ​​List) for intelligent ships Generate certificate expiration time ,storage and return a response message. ; After receiving the response message from the Safety Center (SC), the Intelligent Vessel (VSL) stores... .

5. The method for ship-shore grid-based cross-domain authentication key negotiation for shore-sea collaboration as described in claim 2, characterized in that: In step two, the method for the shore-based communication station CRS to register with the Security Center (SC) includes: The shore-based communication station (CRS) submits a registration message to the Security Center (SC) via a physical security channel. ,in To verify the true identity of the shore-based communication station CRS, the public key of CRS is... , It is its public key component. It's a tracking tag; After receiving the registration message from the shore-based communication station CRS, the Security Center (SC) generates a fake identity for the shore-based communication station CRS. Generate agent expiration time for CRS of shore-based communication stations. Calculate hash components Generate proxy components and ,storage and return a response message. ; After receiving the response message from the Security Center (SC), the shore-based communication station CRS calculates the proxy private key component. and Obtain the proxy private key Calculate the proxy public key component Obtain the corresponding proxy public key and store .

6. The method for ship-shore grid-based cross-domain authentication key negotiation for shore-sea collaboration as described in claim 2, characterized in that: In step three, the method for initial CRS authentication key negotiation includes: Smart Ship VSL Sends Messages The temporary public key for VSL is... , For VSL's temporary public key component, This is the current timestamp. Yes and Signature; After verifying the smart ship's VSL identity, send a message. ,in The temporary public key is , for The temporary public key component, and It is an intermediate variable used to generate the session key. It is the ciphertext of the cross-domain token payload. This is the current timestamp. It is a cross-domain token signature; Smart Ship VSL Validation Identity, derived session key Send message ,in It is an intermediate variable used to generate the session key. It's a verification code; Derived session key .

7. The method for ship-shore grid-based cross-domain authentication key negotiation for shore-sea collaboration as described in claim 2, characterized in that: In step four, the method for rapid cross-CRS authentication includes: Intelligent Ship VSL to New Shore-Based Communication Station Send message ,in It is the ciphertext obtained by encrypting the cross-domain token payload and the random value selected by VSL. This is the current timestamp; After verifying the validity of the cross-domain token, derive the session key. Send message },in Yes The ciphertext obtained by encrypting the selected random value It's a verification code. This is the current timestamp; VSL Validation Identity, derived session key .

8. A method for ship-shore grid-based cross-domain authentication key negotiation for shore-sea collaboration as described in claim 2, characterized in that: In step five, the method for updating the entity's pseudo-identity is as follows: the security center SC updates the entity e's current real identity. Public key With current timestamp Generate new pseudo-identities Update storage mappings and synchronize with entities. .

9. A method for ship-shore grid-based cross-domain authentication key negotiation for shore-sea collaboration as described in claim 2, characterized in that: The method also includes step six: malicious entity tracking. When a malicious entity does something wrong, the Security Center (SC) tracks it. If the Security Center is corrupted and colludes with the malicious entity to frame an honest entity, the honest entity must release evidence to prove its innocence.

10. A method for ship-shore grid-based cross-domain authentication key negotiation for shore-sea collaboration as described in claim 9, characterized in that: Step six includes methods for tracking malicious entities, including: (1) Honesty SC When a malicious entity acts maliciously, SC publishes tracking evidence to track the malicious entity and publicly verifies this tracking. (2) Corruption SC When SC is corrupted and colludes with malicious entities to frame honest entities, the honest entities release evidence to prove their innocence.

Images