A gateway-assisted fine-grained data sharing method suitable for hub navigation cross-domain industrial control

Abstract

The application provides a gateway-assisted fine-grained data sharing method suitable for hub navigation cross-domain industrial control, comprising: initializing a gateway-assisted hub navigation cross-domain industrial control system, and generating a master private key and a master public key based on a bilinear pair technology; a key generation center calls a key generation algorithm to calculate a sending end gateway public key, a sending end gateway private key, a conversion key and an attribute key according to the master private key and the master public key; the sending end gateway calculates broadcast ciphertext corresponding to the to-be-encrypted plaintext according to the sending end gateway key and the master public key, and broadcasts the broadcast ciphertext; after two-way authentication, the receiving end gateway receives the broadcast ciphertext and the sending end gateway public key, combines the sending end gateway public key and the conversion key to convert and decrypt the received broadcast ciphertext, and outputs the converted ciphertext; the receiving terminal receives the converted ciphertext and the sending end gateway public key, combines the sending end gateway public key and the attribute key to decrypt the converted ciphertext, and obtains the decrypted ciphertext.

Description

Technical Field

[0001] This invention belongs to the field of applied cryptography, specifically relating to a gateway-assisted fine-grained data sharing method suitable for cross-domain industrial control of hub navigation. Background Technology

[0002] Driven by both the "Smart Shipping" and "Green Hub" strategies, the navigation control system of a hub is rapidly evolving from single local control to deep cross-domain collaboration between ships, shore, and locks. By aggregating a massive number of heterogeneous devices, such as water level gauges, current meters, Automatic Identification System (AIS) terminals, and lock PLCs, into a unified network, modern hubs have achieved real-time monitoring and automated joint scheduling of navigation facilities. Faced with the explosive growth in data caused by the surge in shipping volume, efficient data interaction across multiple domains, including ships, locks, waterways, and dispatch centers, has become a key support for improving navigation efficiency and ensuring shipping safety.

[0003] However, large-scale cross-domain data interaction has also brought unprecedented security and privacy challenges to the hub industrial control network. High-value sensitive data such as navigation scheduling instructions, ship cargo lists, and hub operation status face severe threats during the flow: (1) Data eavesdropping and trajectory inference: Attackers can intercept encrypted text in the wireless channel to conduct traffic analysis, infer ship navigation trajectories or hub scheduling plans, resulting in the leakage of commercial secrets and navigation privacy; (2) Identity forgery and false scheduling: Malicious terminals may forge the identity of high-priority ships to issue false entry requests, or collude to obtain unauthorized hydrological data, seriously interfering with normal navigation order and even causing safety accidents; (3) Communication blockage and denial-of-service risk: The electromagnetic environment in closed spaces such as hub lock chambers is complex. Traditional point-to-point multi-party sharing methods require repeated encrypted transmission, resulting in the waste of valuable wireless spectrum resources and processing blockage of edge navigation terminals, which can easily lead to overload and paralysis of the scheduling system.

[0004] Therefore, in the cross-domain industrial control environment of hub navigation, it is essential to construct a mechanism that can ensure data confidentiality, authenticity of origin, and efficient distribution capabilities. Currently, mainstream technologies for solving one-to-many data security distribution mainly include broadcast encryption, attribute-based encryption, and sharing schemes combined with blockchain. However, when faced with the special needs of hub navigation, these existing solutions all reveal significant shortcomings: lack of fine-grained broadcast capabilities targeting navigation attributes, heavy computational burden on shipborne terminals, high wireless communication overhead, and lack of two-way authentication.

[0005] Cited Policy Attribute-Based Encryption (CP-ABE) and Matching Encryption (ME) are cryptographic technologies that have attracted much attention in recent years. CP-ABE allows data owners to define flexible access policies, and only navigation terminals whose attribute sets meet the policy can decrypt the data, making it highly suitable for the access control requirements of cross-domain joint scheduling. Matching Encryption, on the other hand, provides a mechanism to verify the matching relationship between ciphertext and key without complete decryption, enabling lightweight authentication and traffic pre-filtering. However, directly combining the two and applying them to hub navigation still faces the challenge of balancing "fine-grained control" and "low-latency response," especially how to reduce the computational burden on heterogeneous shipboard equipment through architectural innovation, which is a pressing technical problem that needs to be solved. Summary of the Invention

[0006] To overcome the problems of existing solutions, such as the lack of fine-grained broadcasting capabilities for navigation attributes, heavy computational burden on shipborne terminals, high wireless communication overhead, and lack of two-way authentication, this invention provides a gateway-assisted fine-grained data sharing method suitable for cross-domain industrial control of hub navigation. By combining attribute-based broadcast encryption and matching encryption techniques, a gateway-assisted fine-grained data sharing method for cross-domain industrial control of hub navigation is proposed. By introducing a gateway-assisted computation offloading architecture, fine-grained broadcasting of constant-length ciphertexts and two-way authentication are achieved without relying on cumbersome certificate management, effectively meeting the stringent requirements of hub industrial control systems for high efficiency, bandwidth saving, and security in data sharing.

[0007] According to a portion of this specification, the present invention provides a gateway-assisted fine-grained data sharing method suitable for cross-domain control systems in hub aviation, applicable to gateway-assisted cross-domain control systems in hub aviation, comprising:

[0008] Initialize the gateway-assisted hub navigation cross-domain industrial control system and generate master private key and master public key based on bilinear pairing technology;

[0009] The key generation center invokes the key generation algorithm to calculate the sending gateway public key, sending gateway private key, transformation key, and attribute key based on the master private key and master public key;

[0010] The sending gateway calculates the broadcast ciphertext corresponding to the plaintext to be encrypted based on the sending gateway key and the master public key, and then broadcasts the broadcast ciphertext.

[0011] After successful two-way authentication, the receiving gateway receives the broadcast ciphertext and the sending gateway's public key, and combines the sending gateway's public key and the conversion key to convert and decrypt the received broadcast ciphertext, and outputs the converted ciphertext.

[0012] The receiving terminal receives the converted ciphertext and the sending terminal's gateway public key, and decrypts the converted ciphertext by combining the sending terminal's gateway public key and the attribute key to obtain the decrypted ciphertext.

[0013] As a further technical solution, the process of generating the master private key and master public key based on bilinear pairing technology includes:

[0014] Construct bilinear group ,in, It is a large prime number; For source group and The target group is both of order 1. The group; It is a bilinear mapping; For the group Generators;

[0015] From the model integer field Two secret integers are randomly selected from the pool, and source group elements with the maximum number of broadcast domains are randomly selected. The master public key and master private key are calculated and generated, mathematically represented as:

[0016] ;

[0017] ;

[0018] In the formula, Indicates the master public key; Indicates the master private key; , representing a secret integer, For model The integer field; , which is a source group element with the maximum number of randomly selected broadcast domains; The derived parameters are calculated from the secret integer and the generator.

[0019] As a further technical solution, the sending gateway's public key and private key are calculated by calling the sending gateway's key generation algorithm, based on the master public key, master private key, and the sending gateway's unique identifier. The process includes:

[0020] When the unique identifier is When the sending gateway method obtains the key, the key generation center inputs the master public key. Master private key Unique identifier of the sending gateway ;

[0021] The key generation center randomly selects two secret integers: Generate the sender gateway private key : And calculate the public key of the sending gateway. : .

[0022] As a further technical solution, the conversion key is calculated by calling a conversion key generation algorithm based on the master public key, master private key, and the unique identifier of the receiving gateway. The process includes:

[0023] When the unique identifier is When the receiving gateway method obtains the key, the key generation center first assigns the receiving gateway number to each method key in sequence. ;

[0024] The key generation center selects a random number for each receiving gateway. Calculate the conversion key for each receiving gateway. : ;in, , , .

[0025] As a further technical solution, the attribute key is calculated by calling an attribute key generation algorithm based on the master private key and the attribute set of the receiving terminal. The process includes:

[0026] When the attribute set is When the receiving terminal obtains the key, the key generation center first randomly selects a random number. and for each attribute element in the attribute set Select random number ;

[0027] The key generation center calculates the attribute private key of the receiving terminal. : ,in, For mapping to hash function, This represents a global value for the private key attribute. , This is a component of the attribute private key.

[0028] As a further technical solution, the calculation process for the broadcast ciphertext corresponding to the plaintext to be encrypted includes:

[0029] The sending gateway defines an access tree based on attribute sets. And select a polynomial for each node in the tree;

[0030] Random selection Based on the master public key, the sending gateway private key, and the plaintext to be encrypted, calculate the ciphertext component. , , , and And for accessing the set of leaf nodes Calculate the encrypted access tree structure :

[0031] ; ; ; ; ; ; ;

[0032] in, For the selected set of broadcast domains; The plaintext to be encrypted; , To access the components of a tree-structured ciphertext; H For hash functions; Indicates the first Accessing the attributes of a leaf node Indicates the number of the leaf node being visited; Indicates the first Each leaf node corresponds to a constant term in the polynomial;

[0033] The final broadcast ciphertext is generated based on the calculated ciphertext component and the access tree ciphertext component. : .

[0034] As a further technical solution, the two-way authentication process includes:

[0035] If the unique identifier of the receiving gateway is in the target broadcast domain set specified by the sending gateway, the authentication of the receiving gateway is successful. Then, the receiving gateway receives the broadcast ciphertext and the public key of the sending gateway from the sending gateway, and calculates the verification parameters based on the broadcast ciphertext and the public key of the sending gateway. If the verification parameters can be calculated correctly, the authentication of the sending gateway is successful. When both the authentication of the receiving gateway and the authentication of the sending gateway are successful, the two-way authentication is considered successful.

[0036] As a further technical solution, the steps of converting and decrypting the received broadcast ciphertext by combining the public key of the sending gateway and the conversion key, and outputting the converted ciphertext, include:

[0037] Calculate the verification parameters based on the broadcast ciphertext and the sender's public key. , and :

[0038] ;

[0039] ;

[0040] ;

[0041] Calculate the intermediate value based on the validation parameters. Generate converted ciphertext :

[0042] ;

[0043] In the formula, , To convert ciphertext The two components.

[0044] As a further technical solution, the process of decrypting the converted ciphertext by combining the public key of the sending gateway and the attribute key includes:

[0045] Traverse the tree of the converted ciphertext and visit each leaf node. If the attribute list of the receiving terminal contains the attribute corresponding to the leaf node, the match is successful. Then, combine the attribute corresponding to the leaf node, the attribute private key and the converted ciphertext to perform a bilinear pairing matching operation to obtain the matching result of the leaf node.

[0046] Based on the matching results of the leaf nodes, the secret factor for accessing the root node in the tree in the transformed ciphertext is recursively calculated. ; through formula The plaintext data is recovered to obtain the decrypted ciphertext.

[0047] According to another part of this specification, a gateway-assisted hub navigation cross-domain industrial control system is provided, comprising:

[0048] The key generation center is configured to initialize the hub navigation cross-domain industrial control system assisted by the gateway, generate the master private key and master public key based on bilinear pairing technology; and call the key generation algorithm to calculate the sending gateway public key, sending gateway private key, transformation key and attribute key based on the master private key and master public key.

[0049] The sending gateway is configured to calculate the broadcast ciphertext corresponding to the plaintext to be encrypted based on the sending gateway key and the master public key, and then broadcast the broadcast ciphertext.

[0050] After successful two-way authentication, the receiving gateway receives the broadcast ciphertext and the sending gateway's public key. It then uses the sending gateway's public key and the conversion key to convert and decrypt the received broadcast ciphertext and output the converted ciphertext.

[0051] The receiving terminal is configured to receive the converted ciphertext and the public key of the sending gateway, and decrypt the converted ciphertext by combining the public key of the sending gateway and the attribute key to obtain the decrypted ciphertext.

[0052] Compared with the prior art, the beneficial effects of the present invention are as follows: (1) Terminal burden reduction and real-time response: The introduction of a gateway-assisted encapsulation-decapsulation chain architecture offloads the heavy bilinear pairing calculation and some decryption tasks to the sending and receiving gateways with sufficient computing power, which significantly reduces the computing load and energy consumption of heterogeneous shipborne terminals and handheld devices, thereby freeing up terminal computing power to ensure the real-time processing of industrial control instructions. (2) Fine-grained control based on navigation attributes: Combined with the ciphertext policy attribute-based encryption mechanism, the dispatch center is allowed to formulate flexible access policies according to the needs of navigation services, realizing efficient "one-to-many" fine-grained secure sharing of multiple types of ships and facilities, ensuring that sensitive dispatch data is only sent to specific authorized targets. (3) Efficient communication and spectrum saving: The ciphertext size remains constant and does not increase linearly with the increase in the number of receiving ships or the scale of navigation terminals. The size of the system master public key is only related to the maximum number of broadcast domains in the hub. It effectively saves valuable wireless communication resources and avoids channel congestion during peak navigation periods. (4) Cross-domain two-way security authentication: Through the matching encryption mechanism, two-way control of the sender's identity verification and the receiver's permission verification is realized, which effectively prevents malicious attackers from forging scheduling instructions or unauthorized nodes from tampering with parameters, and ensures the high reliability of the ship-shore-lock communication link. Attached Figure Description

[0053] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the accompanying drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the accompanying drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0054] Figure 1 A flowchart illustrating a gateway-assisted fine-grained data sharing method applicable to cross-domain industrial control of hub aviation, provided as an embodiment of the present invention;

[0055] Figure 2 This is a schematic diagram of a gateway-assisted hub navigation cross-domain industrial control system provided in an embodiment of the present invention. Detailed Implementation

[0056] It should be noted that:

[0057] The terms “comprising” and “having”, and any variations thereof, in the specification, claims, and accompanying drawings of this invention are intended to cover a non-exclusive inclusion, such as a process, method, system, product, or apparatus that includes a series of steps or units, not necessarily limited to those explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0058] The block diagrams shown in the accompanying drawings are merely functional entities and do not necessarily correspond to physically independent entities. That is, these functional entities can be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices. The flowcharts shown in the accompanying drawings are merely illustrative and do not necessarily include all content and operations / steps, nor do they necessarily have to be performed in the described order. For example, some operations / steps can be decomposed, while others can be combined or partially combined; therefore, the actual execution order may change depending on the specific circumstances.

[0059] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention. In addition, the technical features of the various embodiments or individual embodiments provided by the present invention can be arbitrarily combined to form new technical solutions. Such combinations are not bound by the order of steps and / or structural composition patterns, but must be based on the ability of those skilled in the art to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be considered that such a combination of technical solutions does not exist and is not within the scope of protection claimed by the present invention.

[0060] like Figure 1 As shown, a gateway-assisted fine-grained data sharing method for cross-domain industrial control of hub aviation is applicable to gateway-assisted cross-domain industrial control systems for hub aviation, including:

[0061] Step 1: Initialize the gateway-assisted hub navigation cross-domain industrial control system and generate the master private key and master public key based on bilinear pairing technology;

[0062] Step 2: The key generation center calls the key generation algorithm to calculate the sending gateway public key, sending gateway private key, transformation key and attribute key based on the master private key and master public key;

[0063] Step 3: The sending gateway calculates the broadcast ciphertext corresponding to the plaintext to be encrypted based on the sending gateway key and the master public key, and broadcasts the broadcast ciphertext.

[0064] Step 4: After successful two-way authentication, the receiving gateway receives the broadcast ciphertext and the sending gateway's public key. It then uses the sending gateway's public key and the conversion key to convert and decrypt the received broadcast ciphertext and output the converted ciphertext.

[0065] Step 5: The receiving terminal receives the converted ciphertext and the sending terminal's gateway public key, and decrypts the converted ciphertext by combining the sending terminal's gateway public key and the attribute key to obtain the decrypted ciphertext.

[0066] This method is primarily applied to multi-party data collaboration and secure transmission scenarios in complex hub navigation environments, including but not limited to ship-shore cross-domain communication, collaborative scheduling of hub facilities, aggregation of navigation environment perception data, and cross-departmental data auditing and supervision among maritime / shipping enterprises. This method simultaneously ensures the confidentiality and authenticity of cross-domain industrial control commands and navigation status data transmission, and supports fine-grained access control based on navigation attributes, ensuring that only navigation terminals or control nodes meeting specific policies can decrypt data. Furthermore, this invention introduces a gateway-assisted encapsulation-decapsulation mechanism and a two-way authentication mechanism based on matching encryption, effectively protecting the recipient's identity privacy while achieving two-way permission verification between the control center and edge terminals. By offloading the heavy bilinear pairing computation task to the hub edge gateway and designing a constant-length ciphertext structure, this method overcomes the communication bandwidth bottleneck in the complex electromagnetic environment of hubs, significantly reducing the computational load and response latency of heterogeneous navigation terminals, and ensuring the efficiency and scalability of data authentication and sharing in large-scale hub industrial control networks.

[0067] The gateway-assisted hub navigation cross-domain industrial control system to which this method is applicable includes four entities:

[0068] Key Generation Center (KGC): Usually undertaken by the hub air traffic management agency, it is responsible for initializing the system's global parameters and generating and securely distributing public and private key pairs for the sending gateway, receiving gateway, and air traffic terminals.

[0069] Sending Gateway (SG): Located in the sending domain, it is responsible for encrypting scheduling instructions or status data in conjunction with access policies and broadcasting them to the hub network.

[0070] Receiver Gateway (RG): Located at the edge of the receiving domain, it has sufficient computing power and is responsible for verifying the authenticity of the ciphertext source and performing heavy bilinear pairing calculations to perform partial decryption (ciphertext conversion), thus offloading the computation.

[0071] Receiver Terminal (RT): The final data consumer (such as a shipboard smart terminal or gate control PLC) uses the attribute private key to perform lightweight final decryption of the ciphertext converted by the gateway to obtain the plaintext data.

[0072] Specifically, in step 1, the system initialization parameters include:

[0073] Security parameters of the key generation center And the system's maximum number of users (maximum number of broadcast domains). .

[0074] In step 1, the generation of the master private key and master public key based on bilinear pairing technology is performed at the key generation center. The steps include:

[0075] Step 1-1: Construct a bilinear group ,in, It is a large prime number; For source group and The target group is both of order 1. The group; It is a bilinear mapping; For the group Generators;

[0076] Steps 1-2, from the model Two secret integers are randomly selected from the integer field, and source group elements with the maximum number of broadcast fields are randomly selected to calculate and generate the master public key and master private key, mathematically represented as:

[0077]

[0078]

[0079] In the formula, Indicates the master public key; Indicates the master private key; , representing a secret integer, For model The set of integers; , which is a source group element with the maximum number of randomly selected broadcast domains; The derived parameters are calculated from the secret integer and the generator: .

[0080] Preferably, steps 1-1 and 1-2 are combined into an initialization algorithm for the key generation center: The overall performance is as follows: the key generation center inputs security parameters. and the system's maximum number of users Call the initialization algorithm The algorithm returns the master public key. and the master private key Furthermore, KGC locally stores the system's master private key. and publicly disclose the master key. .

[0081] As a supplementary explanation, in step 1, and These are the system security level and broadcast domain upper limit, which are preset during the system design phase. Bilinear group parameters. It is the fundamental mathematical structure of cryptographic operations, based on the initialization algorithm. generate. It is the system master private key, obtained by KGC from... Randomly selected from among them. It consists of elements of the master public key, which are obtained by exponentiation and random sampling of group elements, and are publicly available as a whole.

[0082] In step 2, the process of calling the key generation algorithm to calculate the sending gateway key, receiving gateway key, and terminal ciphertext based on the master private key and master public key is implemented in the key generation center. The process includes:

[0083] First, the sending gateway key generation algorithm is invoked. Based on the master public key, master private key, and unique identifier of the sending gateway, the sending gateway key is calculated, including the sending gateway public key and the sending gateway private key. The sending gateway key is then sent to the sending gateway through the Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) key exchange algorithm. The sending gateway secretly stores the sending gateway private key locally and publishes the sending gateway public key.

[0084] The mathematical representation of the sending-end gateway key generation algorithm is as follows:

[0085]

[0086] In the formula, This indicates the gateway key generation algorithm at the sending end; It serves as a unique identifier for the sending gateway; The public key of the sending gateway; This is the private key of the sending gateway.

[0087] Specifically, the process of calling the sending gateway key generation algorithm to calculate the sending gateway public key and sending gateway private key based on the master public key, master private key, and unique identifier of the sending gateway includes:

[0088] Step 2-1-1: When the unique identifier (ID) is When obtaining the key using the SG method, the KGC input Unique identifier of the sending gateway .

[0089] Step 2-1-2: Randomly select two secret integers: KGC generates the private key for the sending SG. And calculate the corresponding public key. .

[0090] Furthermore, the distribution process of the sending gateway key includes:

[0091] Step 2-1-3: KGC will transfer SG's private key. and public key Securely sent to SG via ECDHE.

[0092] Step 2-1-4: The sending end SG receives the private key. and public key Then, the private key is secretly stored locally. Publish public keys as needed .

[0093] Secondly, the conversion key generation algorithm is invoked to calculate the conversion key based on the master public key, master private key, and unique identifier of the receiving gateway. The conversion key is then sent to the receiving gateway through the temporary elliptic curve Diffie-Hellman key negotiation key exchange algorithm, and the receiving gateway secretly stores the conversion key locally.

[0094] The mathematical representation of the key generation algorithm is as follows:

[0095]

[0096] In the formula, This indicates the key generation algorithm for the conversion; This serves as a unique identifier for the receiving gateway. This is for converting the key.

[0097] Specifically, the process of calling the conversion key generation algorithm and calculating the conversion key based on the master public key, master private key, and the unique identifier of the receiving gateway includes:

[0098] Step 2-2-1, when ID is When the receiving gateway RG method obtains the key, KGC first sequentially assigns the RG label to each method key as follows: .

[0099] Step 2-2-2: KGC selects a random number for each RG. Calculate the conversion key for each RG. : ;

[0100] in, , , .

[0101] Furthermore, the distribution process of the conversion key includes:

[0102] Step 2-2-3: KGC will convert the key. It is sent to the corresponding receiving gateway RG via ECDHE.

[0103] Step 2-2-4: The receiving gateway RG receives the conversion key. It is then secretly stored locally.

[0104] Following steps 2-2-2 to 2-2-4, randomly select each receiving gateway. ; Calculate the conversion key ,in: ; ; (For all) and ).

[0105] Third, the attribute key generation algorithm is invoked, the master private key and the attribute set of the receiving terminal are input, the attribute key is calculated, and the attribute key is sent to the receiving terminal through the temporary elliptic curve Diffie-Hellman key negotiation key exchange algorithm. The receiving terminal secretly stores the attribute key locally.

[0106] The mathematical representation of the attribute key generation algorithm is as follows:

[0107]

[0108] In the formula, This indicates the attribute key generation algorithm; For the attribute set of the receiving terminal; This is the attribute key.

[0109] Specifically, the process of calculating the attribute key according to the attribute key generation algorithm includes:

[0110] Step 2-3-1, when the attribute set is When the receiving terminal obtains the key using the RT method, KGC first randomly selects... and for Each attribute element in Select random number .

[0111] Step 2-3-2: KGC calculates the attribute private key of the receiving terminal RT: ,in, This represents a global value for the private key attribute. , This is a component of the attribute private key. For mapping to The hash function.

[0112] As a supplementary explanation, in this step, It is the private key of the sending gateway, which is randomly selected by KGC; It corresponds to the public key, which is obtained by exponentiation of the generator. It is the receiving end gateway. The random blinding factor is randomly selected by KGC; , , These are the components of the key conversion process, consisting of... It is calculated using the master and public key parameters. , It is the blinding factor of the attribute key, which is randomly selected by KGC; , , It is an attribute key component, which is calculated jointly from the master private key, the blinding factor, and the attribute hash value.

[0113] Furthermore, the distribution process of the attribute key includes:

[0114] Step 2-3-3: KGC will transfer the attribute key. The signal is sent to the corresponding receiving terminal RT via ECDHE.

[0115] Steps 2-3-4: The receiving terminal RT receives the attribute key. It is then secretly stored locally.

[0116] Step 3 mainly involves the sending gateway SG deployed at the edge of the hub's navigation site processing data and performing encryption and broadcasting. Its purpose is to ensure the authenticity of the sending source's identity, the mutual authentication between the sending and receiving sources, and the confidentiality of production data in cross-domain data interaction. When broadcasting sensing or control data to heterogeneous domains, the sending gateway needs to use its private key to encrypt plaintext data or instructions, thereby preventing malicious devices from stealing key monitoring data or industrial control instructions.

[0117] Step 3, the process of calculating the broadcast ciphertext corresponding to the plaintext to be encrypted, includes:

[0118] The sending gateway invokes the encryption algorithm, taking into account the master public key, the sending gateway's private key, the plaintext to be encrypted, and the specified target broadcast domain set and attribute access policy of the sending gateway, and calculates the broadcast ciphertext.

[0119] The mathematical representation of the encryption algorithm invoked by the sending gateway is as follows:

[0120]

[0121] In the formula, Indicates the encryption algorithm; This indicates the ciphertext to be encrypted; This represents the target broadcast domain set of the specified sending gateway; This indicates the attribute access policy of the specified sending gateway.

[0122] Specifically, the calculation process for the broadcast ciphertext corresponding to the plaintext to be encrypted includes:

[0123] The sending gateway defines an access tree based on attribute sets. And select a polynomial for each node in the tree;

[0124] Random selection Based on the master public key, the sending gateway private key, and the plaintext to be encrypted, calculate the ciphertext component. , , , and And for accessing the set of leaf nodes Calculate the encrypted access tree structure :

[0125] ; ; ; ; ; ; ;

[0126] in, For the selected set of broadcast domains; The plaintext to be encrypted; , To access the components of a tree-structured ciphertext; H For hash functions; Indicates the first Accessing the attributes of a leaf node Indicates the number of the leaf node being visited; Indicates the first Each leaf node corresponds to a constant term in the polynomial;

[0127] The final broadcast ciphertext is generated based on the calculated ciphertext component and the access tree ciphertext component. : .

[0128] Among them, the visit tree Each leaf node in the equation is associated with a specific attribute in its attribute group, and the root node polynomial satisfies... , The secret value is random, that is This is the core secret protected by the access tree in this encrypted session.

[0129] The steps for broadcasting the ciphertext include:

[0130] Step 3-1: The sending gateway SG first defines the set of attributes that meet the conditions according to the business requirements, and defines an attribute access control tree structure (an access tree based on attribute groups). .

[0131] Step 3-2: After establishing the visit tree Next, for the root node of the access tree The sending gateway first randomly selects a secret value. And set the polynomial .

[0132] Step 3-3: The sending gateway SG uses a multinomial secret sharing mechanism based on a threshold access structure to access each node in the tree. Recursively set the secret share: for any internal leaf node Construct polynomial Set its constant term to the value of the parent node in that child node, and define... Finally, a corresponding secret share is assigned to each leaf node (attribute node) for use in the subsequent generation of ciphertext components and the decryption and reconstruction of satisfying the strategy.

[0133] Steps 3-4: The sending gateway SG retrieves data from the integer field. Three random numbers are randomly selected from the data. Using the parameters and master public key generated above... ciphertext computation component , , , and For the set of leaf nodes of the access tree ,calculate and .

[0134] Steps 3-5: The sending gateway SG will assemble the broadcast ciphertext. Broadcast to a public channel for all network-wide receiving gateways to listen to and process.

[0135] As a supplementary explanation, in step 4, M is a random number for each encrypted session, obtained by the sending gateway from... Freshly selected randomly. The core secret for accessing the root node is randomly selected and recursively distributed to each leaf node through polynomial secret sharing, thus obtaining the secret share for each node. . to and These are the components of broadcast ciphertext, composed of plaintext. Random numbers , It is calculated using the formula along with the master public key and the sender's private key.

[0136] Step 4, the two-way authentication process includes:

[0137] If the unique identifier of the receiving gateway is in the target broadcast domain set specified by the sending gateway, the authentication of the receiving gateway is successful. Then, the receiving gateway receives the broadcast ciphertext and the public key of the sending gateway from the sending gateway, and calculates the verification parameters based on the broadcast ciphertext and the public key of the sending gateway. If the verification parameters can be calculated correctly, the authentication of the sending gateway is successful. When both the authentication of the receiving gateway and the authentication of the sending gateway are successful, the two-way authentication is considered successful.

[0138] This process manifests as follows: RG, which is in a public network listening state, when its identity is included in the target broadcast domain set of SG... At that time, it was believed that RG was authorized and RG certification was passed;

[0139] RG captures and receives broadcast ciphertext The broadcast ciphertext is stored locally on the RG, and the RG collects and receives the public keys of the sending gateways on the public network in the same way. .

[0140] According to the broadcast cipher and the public key of the sending gateway Calculate verification parameters , and :

[0141]

[0142]

[0143]

[0144] When the validation parameters can be correctly calculated (i.e.) (If it is used correctly), the SG identity is considered legitimate, SG authentication is successful, and thus two-way authentication is successful.

[0145] Step 4, which involves combining the sender's gateway public key and the conversion key to convert and decrypt the received broadcast ciphertext, and then outputting and broadcasting the converted ciphertext, includes the following steps:

[0146] The receiving gateway invokes the ciphertext conversion algorithm to calculate the converted ciphertext based on the broadcast ciphertext, the sending gateway's public key, and a partial decryption key, and then broadcasts the converted ciphertext.

[0147] The mathematical representation of the ciphertext conversion algorithm is as follows:

[0148]

[0149] In the formula, This represents the ciphertext conversion algorithm.

[0150] Optionally, when broadcasting the converted ciphertext, the receiving gateway re-encapsulates the generated converted ciphertext into an industrial data packet and broadcasts it to all receiving terminals within the domain via the industrial intranet using a publish / subscribe mechanism (such as the MQTT protocol) or a local area network multicast method.

[0151] Specifically, the steps of converting and decrypting the received broadcast ciphertext by combining the sender's gateway public key and the conversion key, and outputting the converted ciphertext, include:

[0152] According to the broadcast cipher and the sender's public key Calculate the verification parameters: , and ;

[0153] Calculate the intermediate value based on the validation parameters. Generate converted ciphertext : In the formula, , To convert ciphertext The two components,

[0154] Preferably, if the two-way authentication is successful, then the above pairing operation... This will eliminate interference terms, making The receiving gateway RG then calculates the converted ciphertext: .

[0155] As a supplementary explanation, in step 4, , , It is an intermediate parameter for authentication, obtained by the receiving gateway through a bilinear pairing operation of the conversion key, broadcast ciphertext, and sending public key. It is the core intermediate value for ciphertext conversion, by The calculation shows that when authentication is successful, the result is simplified to... . , These are the two components of the ciphertext, derived from the broadcast ciphertext and... Calculated.

[0156] In step 5, the receiving terminal RT does not directly connect to the public channel, but instead continuously listens for broadcast ciphertexts from its home gateway (RG) through the hub's internal network. .

[0157] Optionally, the receiving terminal (RT) continuously listens to preset broadcast channels, multicast addresses, or subscribes to specific message middleware topics within the aviation internal network through its configured wired or wireless communication interface, thereby capturing and receiving in real time messages encapsulated with transformed ciphertext broadcast by the receiving terminal gateway. Industrial data packets.

[0158] Furthermore, step 5, the decryption step using the attribute key, includes:

[0159] Receiver terminal RT input ciphertext conversion Sending gateway SG public key and decryption key Call the decryption algorithm The algorithm returns the final decrypted plaintext. .

[0160] Subsequently, the receiving terminal transmits the plaintext. Input to the local industrial control system or human-machine interface is used to adjust the industrial control parameters of the hub's navigation in real time, trigger the action of automated equipment, or conduct safety audits.

[0161] Specifically, the process of decrypting the converted ciphertext by combining the sender's gateway public key and the attribute key includes:

[0162] Traverse the tree of the converted ciphertext and visit each leaf node. If the attribute list of the receiving terminal contains the attribute corresponding to the leaf node, the match is successful. Then, combine the attribute corresponding to the leaf node, the attribute private key and the converted ciphertext to perform a bilinear pairing matching operation to obtain the matching result of the leaf node.

[0163] Based on the matching results of the leaf nodes, the secret factor for accessing the root node in the tree in the transformed ciphertext is recursively calculated. ; through formula The plaintext data is recovered to obtain the decrypted ciphertext.

[0164] As one specific implementation method, step 5 includes the following sub-steps:

[0165] Step 5.1: The receiving terminal RT obtains the public key of the sending gateway from the system's public memory or in advance during the initialization phase. And system parameters, used to assist in calculations.

[0166] Step 5.2: The receiving terminal RT receives the broadcast ciphertext. Then, it uses the attribute private key stored in its own security chip. For the access tree in the transformed ciphertext Execute the recursive decryption algorithm. This includes the following sub-steps:

[0167] Step 5.2.1: Traverse and visit every leaf node in the tree. The receiving end RT checks its own attribute list. Does it contain the attribute corresponding to this leaf node? , : If it contains, then if the match is successful ( Terminal utilizes attribute private key component and Combined with ciphertext components and Perform bilinear pairing matching operation: If not contained, the match fails: the leaf node outputs... (Null value).

[0168] Step 5.2.2: For non-leaf nodes in the tree The receiver RT determines the threshold value based on its logic gate. The calculation results of child nodes are collected. Using Lagrange interpolation, the results of child nodes that meet the threshold condition are aggregated to recover the value of the polynomial at 0 for that node. Through recursion, if the terminal's attribute set satisfies the entire access tree strategy, the terminal will eventually be at the root node. The core secret factor was calculated at the location. : .

[0169] Step 5.2.3: Obtaining the core secret factor Then, the receiving terminal RT performs the final deblinding operation to remove random masking items from the ciphertext and recover the original plaintext. The receiving terminal RT utilizes the converted ciphertext... The main component with its own private key Combined with the calculation in step 5.2.2 Calculate using the following formula: ,in .

[0170] If the above calculation is successful and no mathematical errors occur, the terminal will output plaintext data. This information is provided for display, alarm, or control decisions by the upper-level hub navigation application; otherwise, it outputs "decryption failed," indicating insufficient permissions or that the data has been tampered with.

[0171] As a supplementary explanation, in step 5, The result of the leaf node matching operation is composed of the attribute private key component. , It is obtained by pairing and operating with the corresponding ciphertext component. It is the core secret factor for accessing the root node of the tree, which is obtained by recursively aggregating the results of the leaf nodes that satisfy the policy through Lagrange interpolation. It is the final unblinding factor, by and The pairing result divided by Obtain; ultimately pass Restore plain text.

[0172] The implementation of the various embodiments of the present invention is based on programmed processing through a system with processor functionality. Therefore, in practical engineering, the technical solutions and functions of the various embodiments of the present invention are encapsulated into various modules. Based on this reality, and building upon the above embodiments, the embodiments of the present invention provide a gateway-assisted hub navigation cross-domain industrial control system. This system is used to execute a gateway-assisted fine-grained data sharing method applicable to hub navigation cross-domain industrial control, as described in the above method embodiments.

[0173] See Figure 2 The system includes:

[0174] The key generation center is configured to initialize the hub navigation cross-domain industrial control system assisted by the gateway, generate the master private key and master public key based on bilinear pairing technology; and call the key generation algorithm to calculate the sending gateway public key, sending gateway private key, transformation key and attribute key based on the master private key and master public key.

[0175] The sending gateway is configured to calculate the broadcast ciphertext corresponding to the plaintext to be encrypted based on the sending gateway key and the master public key, and then broadcast the broadcast ciphertext.

[0176] After successful two-way authentication, the receiving gateway receives the broadcast ciphertext and the sending gateway's public key. It then uses the sending gateway's public key and the conversion key to convert and decrypt the received broadcast ciphertext and output the converted ciphertext.

[0177] The receiving terminal is configured to receive the converted ciphertext and the public key of the sending gateway, and decrypt the converted ciphertext by combining the public key of the sending gateway and the attribute key to obtain the decrypted ciphertext.

[0178] It should be noted that the system embodiments provided by the present invention are used not only to implement the methods in the above method embodiments, but also to implement the methods in other method embodiments provided by the present invention. The only difference is that corresponding functional modules are set. The principle is basically the same as that of the above system embodiments provided by the present invention. As long as those skilled in the art can improve the modules in the above system embodiments by referring to the specific technical solutions in other method embodiments and combining technical features to obtain corresponding technical means and technical solutions composed of these technical means, on the basis of the above system embodiments, and on the premise of ensuring the practicality of the technical solutions, they can obtain corresponding system-like embodiments for implementing the methods in other method-like embodiments.

[0179] In summary, this invention provides a gateway-assisted fine-grained data sharing method suitable for cross-domain industrial control in hub navigation, comprising the following five steps: System initialization: The key generation center generates bilinear group parameters and generates the system master public key and master private key according to the maximum number of broadcast domains supported by the system; Key generation: The KGC generates a public-private key pair for the sending gateway; generates a conversion key for partial decryption for the receiving gateway (RG); generates an attribute-based private key for the receiving terminal; Encryption and broadcasting: The sending gateway combines broadcast encryption with attribute-based encryption of the ciphertext policy, using the broadcast domain set and attribute access structure of the receiving gateway to encrypt the data and generate ciphertext. The length of this ciphertext is constant and does not increase with the number of receivers; Ciphertext conversion: After receiving the ciphertext, the receiving gateway uses the conversion key to verify the sender's identity and its own receiving permissions. If the verification is successful, the gateway performs a partial decryption operation, converting the complex ciphertext into a simplified converted ciphertext, and sends it to the terminal; Terminal decryption: The receiving terminal uses its own attribute private key to finally decrypt the converted ciphertext and obtain the plaintext data.

[0180] By introducing a ciphertext policy attribute-based broadcast encryption mechanism, a gateway-assisted partial decryption architecture, and a two-way authentication technology based on matching encryption, fine-grained access control, computational efficiency, and communication security for data sharing in the complex electromagnetic environment of a navigation hub are achieved. This method significantly reduces the computational load and storage overhead of heterogeneous navigation terminals by offloading the heavy bilinear pair decryption calculation to the hub's edge gateway. It achieves constant ciphertext length and public key size, preventing linear growth with the number of connected ships or devices, effectively alleviating the wireless communication bandwidth pressure in enclosed areas such as locks. Simultaneously, it effectively protects the identity privacy of the dispatch center and navigation terminals and provides strict two-way authentication functions, ensuring the confidentiality, verifiability of the source, and compliance of access permissions for cross-domain industrial control commands and status data transmission. The method and system of this invention can be widely applied to scenarios including but not limited to navigation environment perception, ship-shore-lock collaborative scheduling, shipping logistics data sharing, and maritime remote supervision.

[0181] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features therein; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the technical solutions of the embodiments of the present invention.

Claims

1. A gateway-assisted fine-grained data sharing method for cross-domain industrial control of hub navigation systems, applicable to gateway-assisted cross-domain industrial control systems of hub navigation systems, characterized in that, include: Initialize the gateway-assisted hub navigation cross-domain industrial control system and generate master private key and master public key based on bilinear pairing technology; The key generation center invokes the key generation algorithm to calculate the sending gateway public key, sending gateway private key, transformation key, and attribute key based on the master private key and master public key; The sending gateway calculates the broadcast ciphertext corresponding to the plaintext to be encrypted based on the sending gateway key and the master public key, and then broadcasts the broadcast ciphertext. After successful two-way authentication, the receiving gateway receives the broadcast ciphertext and the sending gateway's public key, and combines the sending gateway's public key and the conversion key to convert and decrypt the received broadcast ciphertext, and outputs the converted ciphertext. The receiving terminal receives the converted ciphertext and the sending terminal's gateway public key, and decrypts the converted ciphertext by combining the sending terminal's gateway public key and the attribute key to obtain the decrypted ciphertext.

2. The gateway-assisted fine-grained data sharing method for cross-domain industrial control of hub navigation as described in claim 1, characterized in that, The process of generating the master private key and master public key based on bilinear pairing technology includes: Construct bilinear group ,in, It is a large prime number; For source group and The target group is both of order 1. The group; It is a bilinear mapping; For the group Generators; From the model integer field Two secret integers are randomly selected from the pool, and source group elements with the maximum number of broadcast domains are randomly selected. The master public key and master private key are calculated and generated, mathematically represented as: ； ； In the formula, Indicates the master public key; Indicates the master private key; , representing a secret integer, For model The integer field; , which is a source group element with the maximum number of randomly selected broadcast domains; The derived parameters are calculated from the secret integer and the generator.

3. The gateway-assisted fine-grained data sharing method for cross-domain industrial control of hub navigation as described in claim 2, characterized in that, The sending gateway's public key and private key are calculated by calling the sending gateway key generation algorithm, based on the master public key, master private key, and the unique identifier of the sending gateway. The process includes: When the unique identifier is When the sending gateway method obtains the key, the key generation center inputs the master public key. Master private key Unique identifier of the sending gateway ; The key generation center randomly selects two secret integers: Generate the sender gateway private key : And calculate the public key of the sending gateway. : .

4. The gateway-assisted fine-grained data sharing method for cross-domain industrial control of hub navigation as described in claim 2, characterized in that, The conversion key is calculated by calling a conversion key generation algorithm based on the master public key, master private key, and the unique identifier of the receiving gateway. The process includes: When the unique identifier is When the receiving gateway method obtains the key, the key generation center first assigns the receiving gateway number to each method key in sequence. ; The key generation center selects a random number for each receiving gateway. Calculate the conversion key for each receiving gateway. : ;in, , , .

5. A gateway-assisted fine-grained data sharing method for cross-domain industrial control of hub navigation, as described in claim 2, characterized in that... The attribute key is calculated by calling an attribute key generation algorithm based on the master private key and the attribute set of the receiving terminal. The process includes: When the attribute set is When the receiving terminal obtains the key, the key generation center first randomly selects a random number. and for each attribute element in the attribute set Select random number ; The key generation center calculates the attribute private key of the receiving terminal. : ,in, For mapping to hash function, This represents a global value for the private key attribute. , This is a component of the attribute private key.

6. The gateway-assisted fine-grained data sharing method for cross-domain industrial control of hub navigation as described in claim 3, characterized in that, The calculation process for the broadcast ciphertext corresponding to the plaintext to be encrypted includes: The sending gateway defines an access tree based on attribute sets. And select a polynomial for each node in the tree; Random selection Based on the master public key, the sending gateway private key, and the plaintext to be encrypted, calculate the ciphertext component. , , , and And for accessing the set of leaf nodes Calculate the encrypted access tree structure : ； ； ； ； ； ； ； in, For the selected set of broadcast domains; The plaintext to be encrypted; , To access the components of a tree-structured ciphertext; H For hash functions; Indicates the first Accessing the attributes of a leaf node Indicates the number of the leaf node being visited; Indicates the first Each leaf node corresponds to a constant term in the polynomial; The final broadcast ciphertext is generated based on the calculated ciphertext component and the access tree ciphertext component. : .

7. A gateway-assisted fine-grained data sharing method for cross-domain industrial control of hub navigation as described in claim 1, characterized in that, The process of two-way authentication includes: If the unique identifier of the receiving gateway is in the target broadcast domain set specified by the sending gateway, the authentication of the receiving gateway is successful. Then, the receiving gateway receives the broadcast ciphertext and the public key of the sending gateway from the sending gateway, and calculates the verification parameters based on the broadcast ciphertext and the public key of the sending gateway. If the verification parameters can be calculated correctly, the authentication of the sending gateway is successful. When both the authentication of the receiving gateway and the authentication of the sending gateway are successful, the two-way authentication is considered successful.

8. A gateway-assisted fine-grained data sharing method for cross-domain industrial control of hub navigation, as described in claim 6, is characterized in that... The steps for converting and decrypting the received broadcast ciphertext using the sender's gateway public key and the conversion key, and outputting the converted ciphertext, include: Calculate the verification parameters based on the broadcast ciphertext and the sender's public key. , and : ； ； ； Calculate the intermediate value based on the validation parameters. Generate converted ciphertext : ； In the formula, , To convert ciphertext The two components.

9. A gateway-assisted fine-grained data sharing method for cross-domain industrial control of hub navigation, as described in claim 6, characterized in that... The process of decrypting the converted ciphertext by combining the sender's gateway public key and attribute key includes: Traverse the tree of the converted ciphertext and visit each leaf node. If the attribute list of the receiving terminal contains the attribute corresponding to the leaf node, the match is successful. Then, combine the attribute corresponding to the leaf node, the attribute private key and the converted ciphertext to perform a bilinear pairing matching operation to obtain the matching result of the leaf node. Based on the matching results of the leaf nodes, the secret factor for accessing the root node in the tree in the transformed ciphertext is recursively calculated. ; through formula The plaintext data is recovered to obtain the decrypted ciphertext.

10. A gateway-assisted hub navigation cross-domain industrial control system, characterized in that, include: The key generation center is configured to initialize the hub navigation cross-domain industrial control system assisted by the gateway, and generates the master private key and master public key based on bilinear pairing technology. In addition, the key generation algorithm is invoked to calculate the sending gateway public key, sending gateway private key, transformation key and attribute key based on the master private key and master public key; The sending gateway is configured to calculate the broadcast ciphertext corresponding to the plaintext to be encrypted based on the sending gateway key and the master public key, and then broadcast the broadcast ciphertext. After successful two-way authentication, the receiving gateway receives the broadcast ciphertext and the sending gateway's public key. It then uses the sending gateway's public key and the conversion key to convert and decrypt the received broadcast ciphertext and output the converted ciphertext. The receiving terminal is configured to receive the converted ciphertext and the public key of the sending gateway, and decrypt the converted ciphertext by combining the public key of the sending gateway and the attribute key to obtain the decrypted ciphertext.

Images