A method for designing network security of remote sensing constellation adapting multi-level keys

Abstract

The application provides a remote sensing constellation network security design method suitable for multi-level keys, comprising: building a key management module in a satellite-borne computer, managing at least three levels of satellite-borne keys, and different levels of keys corresponding to unlocking different levels of functions of the satellite; the ground station sends two independent seed keys to the satellite at a fixed time, ensuring that at least one key completes transmission and unlocking within a single over-the-top arc segment; all keys are double-encrypted by the ground station and distributed through the uplink, the ground station initiates key update actively, and the satellite stores or feeds back failure information after verification; the multi-level key mechanism is disabled by default, and the ground station sends an enable signal to start after on-orbit testing is qualified; the satellite calls the corresponding level key for identity verification according to the function call demand, unlocks the corresponding function after verification, and feeds back the information for the ground station to check if the verification fails. The application solves the problem of key unlocking failure caused by the short arc time of low-orbit satellites, and realizes the hierarchical safety control of satellite functions.

Description

Technical Field

[0001] This application belongs to the field of remote sensing constellation network security technology, specifically relating to a remote sensing constellation network security design method that adapts to multi-level keys. Background Technology

[0002] Remote sensing constellation technology has become one of the core means of acquiring and applying space information. With the rapid development of microelectronics, spaceborne communication, and satellite manufacturing technologies, remote sensing constellation systems composed of hundreds or even thousands of low-Earth orbit satellites, with their significant advantages such as global coverage, high revisit cycles, and near real-time data transmission, have been widely used in key areas of the national economy, including meteorological monitoring, marine environmental assessment, agricultural and forestry resource surveys, disaster early warning, and emergency response. In such systems, the normal operation of the telemetry and control links between satellites and ground stations, data transmission links, and the various functional subsystems of the satellite platform itself all highly depend on secure and reliable key authentication and access control mechanisms. As the last line of defense for ensuring the network security of remote sensing constellations, the quality of the key mechanism directly affects the security of remote sensing data and the controllability of the satellite platform itself. It is the core technological foundation for preventing eavesdropping on satellite-to-ground communication links, malicious data tampering, and illegal control of the satellite platform.

[0003] Currently, in existing literature and engineering practices, the key design of remote sensing satellite constellations mostly adopts a single master key or a fixed-level key architecture. For example, existing schemes typically configure a single global key for the entire satellite to unlock all functions, including platform management, payload operation, and communication link establishment; or set a few keys at the communication layer and application layer respectively, but the boundaries of each key's permissions are vague, failing to strictly classify them according to the importance of satellite functions and operational risks. Regarding key distribution strategies, common practices include on-board key programming before satellite launch, or a seed key being uploaded once by the ground station via an encrypted telemetry channel when the satellite passes overhead, serving as the basis for deriving other working keys. Furthermore, once the above key mechanisms are deployed on-board, they are usually in an activated state by default, meaning that the complete key verification logic is automatically enabled after the satellite enters orbit, without setting up independent on-orbit testing and phased enabling stages. Key updates also mostly rely on the ground control center to initiate through a centralized secure link, and the update process requires occupying the entire satellite overhead arc to ensure correct command execution.

[0004] However, existing key design methods and technical solutions for remote sensing constellations still have many inherent defects, making it difficult to meet the stringent requirements of current large-scale low-Earth orbit constellations for security, reliability, and flexibility.

[0005] Firstly, low-Earth orbit satellites have low orbital altitudes and high speeds, meaning the visible arc time of a single satellite relative to a ground station is typically extremely short, generally 10 to 20 minutes. Within such a limited time window, if the ground station only sends a seed key to the satellite, channel fading, atmospheric turbulence interference, or timing conflicts in equipment transmission and reception can easily lead to key data packet transmission failure or incomplete reception. Furthermore, the satellite must wait for the next orbital cycle after leaving the station before it can retry, causing a significant delay in the critical key unlocking operation. In severe cases, this can even affect the functional initialization in the satellite's initial safe mode after orbit insertion.

[0006] Secondly, the existing technology's mapping relationship between keys and satellite functions is too crude. A single key or a very small number of keys can unlock almost all functions, from basic communication to core attitude control. This "one key opens all locks" mechanism brings great security risks: once the key is leaked due to ground operation errors, decryption attacks, or internal management, attackers can gain complete control of the satellite platform, arbitrarily start or stop payloads, adjust attitude, or tamper with flight parameters, causing the satellite to lose its functions or even become permanently disabled. The consequences would be catastrophic for remote sensing constellation networks.

[0007] Third, existing key mechanisms generally adopt a default-enabled deployment mode, meaning that the key control logic takes effect immediately after the satellite is powered on in orbit. However, the satellite's in-orbit environment differs significantly from the ground testing environment. Onboard equipment may malfunction due to factors such as radiation and temperature variations, leading to a mismatch between the key verification algorithm and the satellite's actual functional execution interface. If the key function is forcibly enabled without sufficient in-orbit testing, it can easily cause unlocking anomalies, functional malfunctions, and other failures. These failures could lead to irreparable consequences during the critical operational phase in the early stages of satellite insertion, reducing the operational stability of the constellation network.

[0008] Fourth, some existing key distribution strategies rely on centralized ground control nodes. If these nodes are attacked or experience link interruptions, the global keys cannot be updated. Furthermore, existing key distribution to satellites is mostly transmitted via a single channel, lacking redundant distribution and anti-interception mechanisms designed for the highly dynamic topology of low-Earth orbit constellations, further exacerbating the risks of single points of failure and key leakage. In addition, under the centralized distribution model, key updates require serial operation on a satellite-by-satellite basis. For large constellations containing hundreds of satellites, this results in long update cycles, low efficiency, and difficulty in meeting key rotation needs in emergency situations. Summary of the Invention

[0009] To address the aforementioned problems in the existing technology, this application provides a network security design method for remote sensing constellations that adapts to multi-level keys. The technical problem to be solved by this application is achieved through the following technical solution: A network security design method for remote sensing constellations that adapts to multi-level keys includes: S1: A key management module is built in the onboard computer of the remote sensing constellation satellite. The key management module manages at least three levels of onboard keys. The onboard keys are encrypted using an encryption algorithm. Different levels of onboard keys unlock the corresponding level of functions of the remote sensing constellation satellite. S2: Design two independent seed keys that the ground station periodically sends to the remote sensing constellation satellites, wherein the seed keys correspond to unlocking the functions of the corresponding level of the remote sensing constellation satellites; S3: Design the uplink and update mechanisms for the onboard keys at each level and the seed key; the uplink mechanism is that all keys are double-encrypted by the ground station and then distributed through the uplink; the update mechanism is that the ground station actively initiates the key update, sends the updated key to the remote sensing constellation satellite, which verifies the updated key, stores it when the verification is successful, and sends the verification failure information back to the ground station when the verification fails. S4: Design the working mechanism of the on-board keys at each level so that they are disabled by default. After the ground station passes the on-orbit test of the remote sensing constellation satellite, send an enable signal to the remote sensing constellation satellite so that it can enable the on-board keys at each level. S5: Design the unlocking and control mechanism of the key management module so that the remote sensing constellation satellite can call the onboard key or the seed key of the corresponding level according to the function call requirements. In the call process, the key to be called is first authenticated, and the key and the function of the corresponding level are unlocked after the authentication is passed.

[0010] Compared with the prior art, this application has the following beneficial effects: (1) This application designs a ground station to send two independent seed keys to the satellite at regular intervals. The two keys are transmitted in parallel using different encryption paths and each has independent unlocking permissions. This ensures that even if one key fails to be transmitted during a single satellite overhead arc, the other key can still unlock the satellite. This effectively avoids the risk of key unlocking failure caused by the short arc time of low-orbit satellites (usually only 10 to 20 minutes), ensures the continuous and stable operation of satellite functions, and avoids the problem of satellite functions being unavailable due to the inability to update keys for a long time.

[0011] (2) This application constructs a satellite key architecture with at least three levels. Different levels of keys unlock different levels of satellite functions, with higher levels granting higher privileges. Level 1 keys unlock basic communication functions, Level 2 keys unlock remote sensing data acquisition and transmission functions, and Level 3 keys unlock core management functions such as attitude control and payload start / stop. The hierarchical unlocking logic (basic privileges must be unlocked with lower-level keys before higher-level keys can be entered to complete the unlock) further enhances the security of function management, effectively avoids the risk of unauthorized manipulation of satellite core functions due to the leakage of a single key, and significantly improves the security level of the remote sensing constellation network.

[0012] (3) This application adopts a working mechanism of "disabled by default and enabled after on-orbit testing" to ensure that the multi-level key mechanism is fully tested after the satellite is deployed in orbit (including seed key reception and decryption testing, corresponding function testing of unlocking at each level of key, dual seed key redundancy unlocking testing, and anti-interference testing) before it is officially enabled. This avoids problems such as key mismatch with satellite function and unlocking abnormality affecting satellite operation and effectively reduces the on-orbit failure rate. On-orbit testing uses GNSS+NTP synchronization technology to achieve microsecond-level time synchronization, further improving the testing accuracy and efficiency.

[0013] (4) All keys in this application are distributed by the ground station via a secure uplink with double encryption. The first encryption is performed using a session key generated by quantum key distribution technology, and the second encryption is performed using the AES-256-GCM protocol, ensuring that the keys are not leaked or tampered with during satellite-to-ground transmission. The satellite keys are stored in a secure satellite storage unit with anti-tampering and anti-electromagnetic interference capabilities using the AES-256 encryption algorithm, further ensuring the security of the keys themselves. The two seed keys are transmitted independently using different encryption paths, reducing the risk of the keys being intercepted simultaneously.

[0014] (5) In this application, the ground station actively initiates a key update and sends the updated key to the satellite. After the satellite completes the verification, it updates its storage or sends back verification failure information so that the ground station can resend the key accordingly. The key update does not require the satellite to restart in orbit and will not interrupt the satellite's current mission, thus improving the operation and maintenance efficiency and availability of the constellation network. At the same time, the ground station performs troubleshooting after receiving the unlocking failure information instead of simply resending the key, further improving the system's security and intelligence.

[0015] (6) The multi-level key architecture of this application can flexibly adjust the number of key levels and corresponding functional permissions according to the actual needs of the remote sensing constellation (such as setting it to 4 levels, adding the highest permission function of the core payload to control the four-level key), adapting to the security needs of different types of remote sensing satellites. The more levels there are, the more refined the function division and the finer the security control granularity, which can further improve the overall security level of the constellation network.

[0016] The present application will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a network security design method for a remote sensing constellation that adapts to multi-level keys, as provided in this application.

[0018] Figure 2 A flowchart illustrating the overall network security process for a remote sensing constellation with multi-level key protection provided for this application.

[0019] Figure 3 A key management hierarchy diagram provided for this application.

[0020] Figure 4 A schematic diagram illustrating the satellite function unlocking provided in this application.

[0021] Figure 5 This is a schematic diagram of the key ground uplink and update process provided in this application.

[0022] Figure 6 The timing diagram of satellite-ground station interaction provided for this application. Detailed Implementation

[0023] The present application will be described in further detail below with reference to specific embodiments, but the implementation of the present application is not limited thereto.

[0024] like Figure 1 As shown, Figure 1 This is a flowchart illustrating a network security design method for a remote sensing constellation adapted to multi-level keys, as provided in this application. The flowchart shows the core steps of the method. The execution order of the five core steps (S1 to S5) is represented by numbered boxes, with arrows connecting each step, reflecting the logical progression of the technical solution.

[0025] like Figure 2 As shown, Figure 2 The flowchart illustrating the overall implementation process of this application for a remote sensing constellation network security system with multi-level key protection is provided. Figure 2 The document details the data flow and module interactions between each stage, including core aspects such as building a multi-level key architecture, a dual-seed key transmission mechanism, key uplink and update on the ground, multi-level key progressive unlocking, and dual-seed redundancy protection. The arrow connections between modules illustrate the transmission paths and logical order of signals and data, and do not constitute a limitation on the scope of protection of this application.

[0026] S1: Build a key management module in the onboard computer of the remote sensing constellation satellite.

[0027] A key management module is installed in the onboard computer of the remote sensing constellation satellite. This module manages at least three levels of onboard keys, which are encrypted using an encryption algorithm. Different levels of onboard keys unlock corresponding functions of the remote sensing constellation satellite.

[0028] Specifically, the hierarchical classification of the onboard keys is as follows: Level 1 onboard keys unlock the basic communication functions of the remote sensing constellation satellites, ensuring basic signal interaction between the satellites and the ground; Level 2 onboard keys unlock the routine remote sensing data acquisition, preprocessing, and transmission functions of the remote sensing constellation satellites, enabling normal acquisition and transmission of remote sensing data; Level 3 onboard keys unlock the core control functions of the remote sensing constellation satellites, such as attitude control, payload start / stop, and orbit adjustment, ensuring the controllability of satellite operation. The higher the level, the higher the unlockable satellite function permissions.

[0029] The encryption algorithm used is AES-256 (Advanced Encryption Standard). The onboard keys for each level are stored in an onboard secure storage unit. This onboard secure storage unit is tamper-proof and electromagnetic interference-resistant, effectively preventing the keys from being illegally obtained.

[0030] As an optional approach in this application, Figure 2 The onboard keys at each level can also be set to four levels: Level 1 onboard key (basic communication), Level 2 onboard key (data acquisition and transmission), Level 3 onboard key (attitude control), and Level 4 onboard key (payload management). The Level 4 onboard key is used to unlock the highest-level functions of the satellite's core payload, such as starting / stopping and adjusting parameters. The number of levels can be flexibly adjusted according to the actual security needs of the remote sensing constellation. More levels allow for more refined functional divisions and finer-grained security control, further enhancing the overall security level of the constellation network.

[0031] like Figure 3 As shown, Figure 3This is a key management hierarchy diagram, illustrating the mapping relationship between keys at each level and satellite functions using a pyramid structure. The priority in this application is as follows: Level 1 keys are at the bottom of the pyramid, corresponding to unlocking basic satellite communication functions; Level 2 keys are in the middle layer, corresponding to unlocking routine remote sensing data acquisition and transmission functions; and Level 3 keys are at the top, corresponding to unlocking core control functions such as satellite attitude control and payload start / stop. The key management module is located at the bottom layer, serving as the core management unit of the onboard key system, managing multiple levels of onboard keys upwards. Keys at each level are arranged in a pyramid structure or stacked manner: Level 1 keys are at the bottom, corresponding to unlocking basic satellite communication functions; Level 2 keys are in the middle layer, corresponding to unlocking routine remote sensing data acquisition and transmission functions; and Level 3 keys are at the top, corresponding to unlocking core control functions such as attitude control and payload start / stop. The higher the level, the higher the corresponding functional permissions, and the more stringent the unlocking conditions. The key management module uniformly manages all levels of onboard keys, responsible for the entire lifecycle management operations of keys, including storage, verification, updating, and authentication. Figure 3 Intuitively, this application achieves a hierarchical mapping between keys and satellite functions by constructing a key architecture with at least three levels. The hierarchical and progressive division of permissions effectively avoids the risk of unauthorized control of core satellite functions due to the leakage of a single key, thereby improving the security level of the remote sensing constellation network.

[0032] S2: Design two independent seed keys that the ground station periodically sends to the remote sensing constellation satellites.

[0033] This application designs two independent seed keys that the ground station periodically sends to the remote sensing constellation satellites. Each seed key corresponds to a function that unlocks a specific level of the remote sensing constellation satellite.

[0034] Specifically, the two independent seed keys are designated as the first seed key and the second seed key, respectively. The first seed key and the second seed key are transmitted via a satellite-to-ground laser communication link using different encryption paths. The satellite-to-ground laser communication link is either a laser communication link or a quantum key distribution link, with a transmission rate of no less than 10 Gbps. Transmitting the two seed keys using different encryption paths reduces the risk of simultaneous interception and further enhances the security of key transmission.

[0035] The ground station sets a fixed time interval for transmitting the first seed key and the second seed key based on the orbital period and arc time of the remote sensing constellation satellites. In this embodiment, the orbital period is 95 minutes, the arc time is 10 to 20 minutes, and the fixed time interval is 45 minutes to 1 hour. By setting the above time interval, it is ensured that at least one seed key can be transmitted and unlocked within a single satellite overhead arc, effectively avoiding the risk of key unlocking failure caused by the short arc time (10 to 20 minutes) of low-Earth orbit satellites, and ensuring the continuous and stable operation of satellite functions.

[0036] Preferably, when the low-Earth orbit satellite arc time is shorter (e.g., 10 minutes), the fixed time interval can be set to 45 minutes to accommodate more stringent overpass time constraints. The first seed key and the second seed key can be transmitted using a satellite-to-ground quantum key distribution link, with a key generation rate of up to 1.2 Mbit / s, further enhancing the security of key transmission.

[0037] After the satellite receives the first seed key and the second seed key, the onboard key management module performs a preliminary verification. If the verification is successful, the key is temporarily stored for subsequent function unlocking.

[0038] S3: Design the uplink and update mechanisms for the onboard keys at each level and the seed keys. This application designs the uplink and update mechanism for the spaceborne keys at each level and the seed key. Specifically, the uplink mechanism involves all keys undergoing double encryption at the ground station before being distributed via the uplink.

[0039] Specifically, the dual encryption process involves the ground station first encrypting the onboard keys at each level and the seed key using a session key generated by quantum key distribution technology, and then performing a second encryption using the AES-256-GCM (Galois / Counter Mode) protocol. This dual encryption method, combining quantum key distribution and the AES-256-GCM protocol, ensures that the keys are not leaked or tampered with during satellite-to-ground transmission.

[0040] After receiving the encrypted onboard keys and seed keys for each level, the remote sensing constellation satellite first decrypts them using the session key, and then decrypts them using the AES-256-GCM protocol to complete key verification. If key verification passes, the onboard keys and seed keys for each level are stored in the onboard secure storage unit; if key verification fails, a verification failure message is sent back to the ground station.

[0041] The update mechanism is as follows: the ground station proactively initiates key updates. The ground station can initiate updates periodically according to a preset key validity period policy, trigger emergency updates according to instructions from the ground control center, or proactively initiate a forced update when a security risk is detected in the current key (such as suspected leakage). The specific triggering conditions for key updates are uniformly determined by the ground station based on the operation and management strategy of the remote sensing constellation.

[0042] When the ground station decides to initiate a key update, it first generates the updated key. If the update target is a level of onboard key (e.g., replacing the level 3 onboard key), the ground station generates new key data according to the key format and length requirements of that level. If the update target is a seed key (e.g., replacing the first seed key), the ground station regenerates two independent seed keys. After generating the updated key, the ground station follows the same security procedures as the initial distribution, first encrypting the updated key with a session key generated using quantum key distribution technology, and then encrypting it a second time using the AES-256-GCM protocol, forming a double-encrypted key update data packet.

[0043] The ground station transmits the key update data packet to the remote sensing constellation satellite via the uplink. Upon receiving the updated key, the key management module of the remote sensing constellation satellite performs a verification operation. This verification operation is of the same type as the initial key distribution verification described in S3, namely, data-level integrity verification. Specifically, the satellite first decrypts the received key update data packet using the session key, then decrypts it a second time using the AES-256-GCM protocol, and then verifies whether the decrypted key data format is correct, whether the key length meets expectations, and whether the checksum matches. This verification process aims to confirm whether the key update data packet has been tampered with or damaged during satellite-to-ground transmission, ensuring that the satellite stores complete and correct key data.

[0044] After successful verification, the satellite stores the updated key in the onboard secure storage unit, overwriting the original key or seed key at the corresponding level, and returns a successful update confirmation message to the ground station. The successful update confirmation message includes a key type identifier (such as "Level 3 onboard key update successful" or "First seed key update successful") and an update timestamp.

[0045] When verification fails, the satellite refuses to store the updated key, maintains the original key as valid, and sends a verification failure message back to the ground station. This message includes the key type identifier, the reason for the failure (e.g., decryption failure, incorrect format, checksum mismatch), and a timestamp of the failure. Upon receiving the verification failure message, the ground station analyzes the reason for the failure, regenerates and resends the updated key, continuing this process until the update is successful.

[0046] Throughout the key update process, the operation of each functional module of the satellite remains unaffected. The key update operation is completed in the background without requiring the satellite to be restarted in orbit. Therefore, it does not interrupt the satellite's current mission, thus improving the operation and maintenance efficiency and availability of the constellation network.

[0047] S4: Design the working mechanism of the onboard keys at each level.

[0048] This application designs the operating mechanism of the onboard keys at each level, making them disabled by default. After the ground station passes the on-orbit test of the remote sensing constellation satellite, it sends an enable signal to the remote sensing constellation satellite, which then enables the onboard keys at each level.

[0049] Specifically, the on-orbit testing includes: seed key reception and decryption testing, onboard key unlocking function testing at each level, and redundant unlocking testing of two independent seed keys. The seed key reception and decryption testing verifies whether the satellite can correctly receive and decrypt the seed key sent by the ground station; the onboard key unlocking function testing at each level verifies the compatibility between each level of key and the corresponding satellite function; and the redundant unlocking test with two seed keys verifies whether both independent seed keys can independently complete the unlocking operation at their respective levels.

[0050] The on-orbit testing also includes anti-interference testing of the seed key and the onboard key, simulating key reception and unlocking performance under strong electromagnetic interference environments to ensure the reliability of the key mechanism in complex environments. The on-orbit testing employs GNSS (Global Navigation Satellite System) + NTP (Network Time Protocol) synchronization technology for time synchronization, with a time synchronization accuracy at the microsecond level, effectively improving the accuracy and efficiency of the on-orbit testing.

[0051] By adopting the logic of "disabled by default and enabled after on-orbit testing", the key mechanism is fully tested after the satellite is deployed in orbit, avoiding problems such as key mismatch with satellite functions or unlocking abnormalities that may affect satellite operation and effectively reducing the on-orbit failure rate.

[0052] During testing, the ground station sends test commands, and the satellite uses the corresponding key to unlock the satellite, verifying the unlocking success rate and functional compatibility. When the test pass rate reaches 100%, the on-orbit test is considered successful. The ground station sends an enable signal to the satellite via uplink commands, and upon receiving the enable signal, the satellite activates a multi-level key mechanism.

[0053] If the test fails, the ground station adjusts the key parameters via uplink commands and retests until it passes before enabling the system.

[0054] S5: Design the unlocking control mechanism of the key management module.

[0055] This application designs an unlocking and control mechanism for the key management module, enabling the remote sensing constellation satellite to call the corresponding level of the onboard key or the seed key according to the function call requirements. During the call process, the key to be called is first authenticated, and after the authentication is successful, the key and the function of the corresponding level of the key are unlocked.

[0056] Specifically, when the remote sensing constellation satellite needs to access the function corresponding to the Nth level onboard key, the key management module first authenticates the (N-1)th level onboard key. Upon successful authentication, the function access corresponding to the (N-1)th level onboard key is unlocked. Then, the Nth level onboard key is authenticated, and upon successful authentication, the function corresponding to the Nth level onboard key is unlocked. Here, N is an integer greater than 1, and N does not exceed the total number of levels of onboard keys. This hierarchical unlocking logic further enhances the security of function control.

[0057] When authentication fails, the remote sensing constellation satellite records an anomaly log and sends unlocking failure information back to the ground station. The ground station then troubleshoots the problem based on this information. Two independent seed keys can each independently complete the unlocking operation at their respective levels. If one seed key transmission fails, the other seed key can be used to complete the unlocking at the corresponding level, ensuring uninterrupted satellite functionality.

[0058] It should be explained in detail that the "verification" mentioned in S3 and the "authentication" mentioned in S5 are two completely different verification mechanisms that operate at different stages and solve different security problems.

[0059] First, regarding the timing and stages of verification, S3 verification occurs during the uplink transmission of the key from the ground to the satellite, specifically including the initial key distribution stage and the key update stage. At this time, the key is not yet in use and is in the "transmission-storage" stage. S5 authentication occurs when the satellite is operating normally, and when there is a function call requiring key unlocking, the key has already been stored on the satellite and is in the "use-unlock" stage.

[0060] Second, from the perspective of the verification object and purpose, S3 verification verifies the integrity of the key data itself. After receiving the key data packet sent by the ground station, the satellite confirms, through decryption and checksum comparison, whether the data packet has been damaged or altered due to channel errors, interference, interception, or tampering during its journey through the satellite-to-ground link. The purpose of verification is to ensure that the key stored by the satellite is completely consistent with the key sent by the ground station at the data level, that is, to verify "whether the received key data is intact." S5 authentication verifies the authorization matching of the key requested for unlocking. When the satellite receives a key for unlocking, the key management module compares the key byte-by-byte with the corresponding level key stored in the onboard secure storage unit to confirm whether the two are completely matched. The purpose of authentication is to confirm "whether the entity requesting unlocking has a legitimate identity and authorization."

[0061] Third, regarding the handling of failures, an S3 verification failure means that the key data itself is corrupted or untrusted, and the satellite cannot correctly receive the key. In this case, the satellite refuses to store it and sends a verification failure message to the ground station, which must resend the complete key data packet. An S5 authentication failure, on the other hand, means that the key data itself is complete, but the requested unlock key does not match the stored key. In this case, the satellite records an anomaly log and sends an unlock failure message. The ground station needs to troubleshoot the problem to determine if it's due to a key version mismatch, an expired key, or an unauthorized access attempt. After identifying the cause, appropriate measures should be taken, rather than simply resending the key.

[0062] Fourth, from the perspective of the impact on satellite operation, the failure of S3 verification only affects the storage and update process of the key, and does not affect the normal operation of the unlocked functions of the satellite; while the failure of S5 authentication directly affects the unlocking and invocation of new functions. If multiple verification failures occur, a security alarm mechanism may be triggered. The two are at different stages in the technical solution and serve different purposes, together forming a full-link security system for the key from ground transmission to onboard storage and then to function unlocking.

[0063] Taking a three-level key architecture as an example, during normal satellite operation: When basic communication functions need to be invoked, the Level 1 onboard key is entered. The onboard key management module authenticates the key; if authentication is successful, basic communication functions are unlocked. When remote sensing data needs to be acquired, the Level 1 onboard key must first be used to unlock basic communication functions, followed by the Level 2 onboard key. After successful authentication, remote sensing data acquisition and transmission functions are unlocked. When satellite attitude needs to be adjusted, basic permissions must be unlocked sequentially using the Level 1 and Level 2 onboard keys, followed by the Level 3 onboard key. After successful authentication, attitude control functions are unlocked.

[0064] In a four-level key architecture scenario, when a satellite needs to call the core payload control function corresponding to the fourth-level onboard key, it must first unlock the basic communication function through the first-level onboard key, then unlock the data acquisition function through the second-level onboard key, then unlock the attitude control function through the third-level onboard key, and finally enter the fourth-level onboard key. Only after the identity verification is passed can the start / stop and parameter adjustment functions of the core payload be unlocked, thus achieving a more stringent hierarchical security control.

[0065] like Figure 4 As shown, Figure 4 This diagram illustrates the process of unlocking satellite functions using onboard keys at various levels. It also demonstrates the process of a ground station unlocking remote sensing constellation satellite functions using two independent seed keys. Figure 4 As shown, the ground station generates two independent seed keys, designated Seed Key 1 and Seed Key 2, and transmits them to the remote sensing constellation satellites via a satellite-to-ground link. Each seed key has independent unlocking permissions and is transmitted independently using different transmission or encryption paths, each capable of independently unlocking its corresponding function level. Upon receiving either seed key, the satellite's onboard key management module performs authentication; successful authentication unlocks the corresponding function on the satellite. Figure 4 Intuitively, in this application, the ground station sends two independent seed keys to the satellite at regular intervals to ensure that even if one seed key fails to transmit or fails to unlock during a single satellite overhead arc, the other seed key can still unlock independently, thereby achieving dual seed redundancy protection and effectively improving the reliability of network security management and control for remote sensing constellations.

[0066] Figure 5 This diagram illustrates the key uplink and update process provided in this application, showing the complete uplink and update process from key generation on the ground to onboard storage. Figure 5 As shown, the ground station first generates keys at each level, followed by double encryption: the first layer of encryption uses a QKD session key, and the second layer uses the AES-256-GCM protocol for secondary encryption, forming a double-encrypted key data packet. This data packet is transmitted to the remote sensing constellation satellite via a secure space-to-ground link. Upon receiving the encrypted key data packet, the satellite performs double decryption (first using the session key, then using the AES-256-GCM protocol), and then verifies the validity of the decrypted key, checking the key format, length, and checksum. If the verification passes, the key is stored in the onboard secure storage unit; if the verification fails, an error message is sent to the ground station, which then resends the key. Figure 5The complete uplink and update process of the key in this application can be intuitively understood, from ground generation, double encryption, secure transmission between satellite and ground, to satellite reception, double decryption, legality verification, and then to successful storage or retransmission after failure. This demonstrates the security and controllability of the key's transmission and storage throughout the entire link.

[0067] like Figure 6 As shown, Figure 6 The diagram illustrates the interaction sequence between the satellite and the ground station, showing the complete interaction process between the ground station and the remote sensing constellation satellites in the method of this application. Figure 6 The diagram illustrates the complete interaction process from top to bottom in chronological order, from the initial satellite orbit insertion phase, seed key transmission and reception, onboard key distribution at various levels, on-orbit testing, unlocking during normal operation, key update, to anomaly handling. Vertical lines represent the two lifelines: the ground station and the satellite; arrows indicate the direction of message transmission between them; and rectangles represent key processing steps in each interaction phase. Figure 6 It allows for an intuitive understanding of the signaling interaction sequence and data transmission relationship between the ground station and the satellite at different stages.

[0068] The following is combined with Figure 6 The interaction sequence diagram shown provides a more detailed explanation of the interaction process between the satellite and the ground station. This embodiment uses a three-level key architecture as an example to fully demonstrate the key-related interaction process between the ground station and the remote sensing constellation satellites throughout the entire lifecycle from satellite insertion into orbit to normal operation.

[0069] I. Interaction during the initial stage of satellite orbit insertion After the remote sensing constellation satellites are deployed in orbit, the multi-level key management module in the onboard computer is powered on and started along with the satellite platform. At this time, the onboard key working mechanism at each level is disabled by default. That is, although the onboard keys at each level are pre-stored in the onboard secure storage unit, the key management module does not execute any unlocking verification logic, and the satellite's functional modules can directly respond to the basic commands of the ground station.

[0070] The ground station establishes an initial communication connection with the satellite via the space-to-ground telemetry, tracking, and command (TT&C) link. The ground station first sends a handshake request command. Upon receiving the command, the satellite returns its platform status information, including the onboard computer's operational status, the secure storage unit's self-test status, and the readiness status of each functional module. Based on the status information returned by the satellite, the ground station determines that the satellite is ready to receive key distribution.

[0071] II. Seed Key Sending and Receiving Interaction The ground station sets a fixed time interval of 1 hour based on the satellite's orbital period (95 minutes) and arc time (15 minutes). When the satellite first passes overhead, the ground station generates two independent seed keys, which are denoted as the first seed key and the second seed key, respectively.

[0072] The ground station transmits the first seed key via a satellite-to-ground laser communication link and the second seed key simultaneously via a quantum key distribution link. The two seed keys are transmitted in parallel using different encryption paths. During transmission, both seed keys pass through the satellite-to-ground laser communication link, with a transmission rate of no less than 10 Gbps.

[0073] The satellite receives the first and second seed keys during the overhead arc. Since the two seed keys are transmitted in parallel using different encryption paths, even if one link experiences a momentary interruption due to atmospheric turbulence or channel interference, the other link can still independently complete the seed key transmission. After receiving the seed keys, the satellite's onboard key management module performs a preliminary verification. This verifies whether the received data packet format is complete and whether it contains a valid key identifier. If the verification passes, the satellite returns a seed key reception confirmation message to the ground station; if the verification fails, the satellite returns a reception failure message to the ground station. If the ground station does not receive the confirmation message within a preset time, it retransmits the corresponding seed key using the still available links within the current overhead arc.

[0074] Because the ground station is set to send a seed key once per hour, and each transmission contains two independent seed keys, even if both seed keys fail to be transmitted within a single overhead arc, the satellite can still receive a new seed key in the overhead arc of the next orbital cycle (95 minutes later). This effectively avoids the problem of keys not being able to be updated for a long time due to the short arc time in traditional schemes.

[0075] III. Distribution and Interaction of Onboard Keys and Seed Keys at All Levels After the seed key is successfully transmitted and preliminarily verified, the ground station begins distributing the onboard keys at each level (Level 1, Level 2, and Level 3) to the satellite via a secure uplink. Before distribution, the ground station first encrypts each level of onboard key using a session key generated by quantum key distribution technology, and then performs a second encryption using the AES-256-GCM protocol, forming a double-encrypted key data packet.

[0076] The ground station transmits the double-encrypted key data packet to the satellite via the uplink. Upon receiving the encrypted key data packet, the satellite's onboard key management module first decrypts it using the session key, then decrypts it a second time using the AES-256-GCM protocol, completing key verification. The satellite then performs integrity verification on each level of the decrypted key, including verifying the correct key length and checksum matching.

[0077] If the verification passes, the satellite stores the onboard keys at each level in the onboard secure storage unit and sends a successful storage confirmation message back to the ground station. Simultaneously, the satellite also stores the previously received and temporarily stored first and second seed keys in the onboard secure storage unit. If the verification fails, the satellite refuses to store the keys and sends a verification failure message to the ground station. The failure message includes the key type identifier and the reason for the failure (e.g., decryption failure, incorrect format, checksum mismatch, etc.). Upon receiving the verification failure message, the ground station retransmits the corresponding keys.

[0078] IV. On-orbit Testing and Interaction Phase The multi-level key mechanism is disabled by default. After confirming that the satellite has completed the storage of keys at each level, the ground station begins on-orbit testing. The ground station uses GNSS+NTP synchronization technology to achieve microsecond-level time synchronization with the satellite, ensuring the accurate timing of test commands.

[0079] The ground station sent the following test commands in sequence: First, the seed key reception and decryption test. The ground station sends a test command, requesting the satellite to perform a decryption operation once each using the first and second seed keys to verify the correctness of the seed keys. After the satellite completes the operation, it returns the decryption result, and the ground station confirms that both seed keys can be used normally.

[0080] Second, the functions corresponding to the unlocking of each level of onboard key are tested. The ground station sends call commands for Level 1, Level 2, and Level 3 functions, respectively. The satellite calls the corresponding onboard key in sequence according to the command to unlock, verifying the compatibility between each level of key and its corresponding function. For example, the ground station sends a remote sensing data acquisition command, and the satellite calls the Level 2 onboard key to attempt to unlock the remote sensing data acquisition and transmission function. After successful unlocking, the satellite returns data acquisition status information, which the ground station uses to confirm the compatibility between the Level 2 key and the data acquisition function.

[0081] Third, dual-seed key redundancy unlocking test. The ground station tested whether the satellite could independently complete the corresponding level of unlocking operation using only the first seed key and only the second seed key. The ground station sent commands to the satellite to complete the unlocking of functions from level one to level three using a single seed key, verifying whether each seed key could work independently.

[0082] Fourth, key anti-interference test. The ground station simulates a key reception scenario under strong electromagnetic interference. By adjusting the link parameters, signal attenuation or interference is artificially introduced to verify the satellite's key reception and unlocking performance in complex environments.

[0083] When the pass rate of all test items reaches 100%, the ground station determines that the on-orbit test is qualified. The ground station sends an enable signal to the satellite via uplink command. After receiving the enable signal, the satellite's onboard key management module switches the onboard key working mechanism at each level from "disabled state" to "enabled state," meaning the key management module begins executing the complete unlocking verification logic. The satellite returns an enable completion confirmation message to the ground station.

[0084] If any test item fails, the ground station analyzes the cause of the fault based on the abnormal information returned by the satellite, adjusts the key parameters through uplink commands (such as regenerating a matching key), and re-tests until all tests pass before sending the enable signal.

[0085] V. Unlocking and Interaction During Normal Satellite Operation Once the multi-level key mechanism is enabled, the satellite enters the normal operation phase. The following example, using a complete remote sensing data acquisition mission, illustrates the unlocking and interaction process between the satellite and the ground station.

[0086] The ground station sends a remote sensing data acquisition command to the satellite, which includes a secondary function call request identifier. Upon receiving the command, the satellite identifies that the remote sensing data acquisition and transmission function corresponding to the secondary onboard key needs to be invoked.

[0087] The onboard key management module first checks whether the current Level 1 functional permissions have been unlocked. If the current Level 1 function is not yet unlocked, the satellite returns a prompt message to the ground station, requesting the ground station to send the Level 1 onboard key first. Upon receiving the prompt, the ground station sends the Level 1 onboard key to the satellite via a secure uplink. After receiving the Level 1 onboard key, the satellite's onboard key management module compares and verifies the input key with the Level 1 onboard key stored in the onboard secure storage unit. If the verification is successful, the Level 1 functional permissions (basic communication functions) are unlocked, and a Level 1 unlock success confirmation message is returned to the ground station.

[0088] Subsequently, the ground station sends the secondary onboard key to the satellite. Upon receiving the secondary onboard key, the key management module, after confirming that the primary functional permissions have been unlocked, verifies the identity of the secondary onboard key. The input secondary key is compared with the secondary onboard key stored in the onboard secure storage unit. If the verification is successful, the secondary functional permissions (remote sensing data acquisition and transmission functions) are unlocked. The satellite performs the remote sensing data acquisition task, and after completion, transmits the data back to the ground station via the unlocked communication link.

[0089] When the ground station needs to adjust the satellite's attitude, since attitude control is a Level 3 function, a more stringent hierarchical unlocking process is required. The ground station sequentially sends the Level 1 and Level 2 onboard keys. After the satellite verifies and unlocks the Level 1 and Level 2 functional permissions, the ground station then sends the Level 3 onboard key. The onboard key management module authenticates the Level 3 onboard key. Once authentication is successful, Level 3 functional permissions (attitude control function) are unlocked, and the satellite performs the attitude adjustment operation.

[0090] VI. Key Update Interaction During the long-term operation of the satellite, the ground station may proactively initiate key updates as needed. The ground station can initiate updates periodically according to a preset key validity period policy, or it can trigger emergency updates based on instructions from the ground control center.

[0091] When the ground station decides to initiate a key update, it first generates the updated key. If the update target is a spaceborne key at a certain level, the ground station generates new key data according to the key format and length requirements of that level; if the update target is a seed key, the ground station regenerates two independent seed keys. After generating the updated key, the ground station follows the same security procedures as the initial distribution, first encrypting the updated key with a session key generated using quantum key distribution technology, and then encrypting it a second time using the AES-256-GCM protocol, forming a double-encrypted key update data packet.

[0092] The ground station transmits the key update data packet to the satellite via the uplink. Upon receiving the updated key, the satellite's key management module performs a data-level integrity check. The satellite first decrypts the received key update data packet using the session key, then decrypts it a second time using the AES-256-GCM protocol. It then verifies that the decrypted key data format is correct, the key length meets expectations, and the checksum matches. If the verification is successful, the satellite stores the updated key in its onboard secure storage unit, overwriting the original key or seed key at the corresponding level, and returns a successful update confirmation message to the ground station. If the verification fails, the satellite refuses to store the updated key, maintaining the original key's validity, and sends a verification failure message to the ground station, which then retransmits the updated key.

[0093] The entire update process does not require the satellite to be restarted in orbit and will not interrupt the satellite's current mission.

[0094] VII. Exception Handling Interaction During the unlocking process, if authentication fails (e.g., the key sent by the ground station does not match the key stored in the onboard secure storage unit), the onboard key management module refuses to unlock the corresponding function, records the exception log, and reports the unlocking failure information to the ground station. The unlocking failure information includes the failed function level identifier, the failure timestamp, and the reason for the failure (key mismatch). After receiving the unlocking failure information, the ground control personnel conduct troubleshooting based on the feedback information. The troubleshooting directions include: confirming whether the key version sent by the ground station is correct, confirming whether the key stored onboard is damaged due to storage anomalies, and confirming whether the version difference is due to asynchronous key updates. After identifying the specific cause, the ground station takes corresponding measures (such as redistributing the correct key), rather than simply resending the same key.

[0095] If seed key transmission fails during the unlocking process (e.g., neither the first nor the second seed key is successfully transmitted within a certain overhead arc), the satellite will still have a chance to receive a new seed key in the next overhead arc because the ground station continuously sends seed keys at fixed time intervals (1 hour) and the two seed keys are transmitted in parallel using different encryption paths. If both seed keys are unavailable, the satellite will maintain its currently unlocked functional permissions and continue executing the current task. Once a new seed key is successfully received, a new unlocking operation will be performed according to the task requirements, avoiding satellite function interruption due to a single transmission failure.

[0096] The above content combined Figure 6 This paper details the complete interaction process between the ground station and the remote sensing constellation satellites during the initial satellite orbit insertion phase, seed key transmission and reception phase, key distribution phases at various levels, on-orbit testing phase, normal operation phase, key update phase, and anomaly handling phase. Those skilled in the art should understand that the specific execution order and triggering conditions of the above interaction steps can be adaptively adjusted according to the actual mission planning and satellite status of the remote sensing constellation, and these adjustments do not depart from the scope of protection of this application.

[0097] It is worth noting that in the description of this application, "multiple" means two or more, unless otherwise explicitly specified. The above description is a further detailed explanation of this application in conjunction with specific preferred embodiments, and should not be construed as limiting the specific implementation of this application to these descriptions. For those skilled in the art, several simple deductions or substitutions can be made without departing from the concept of this application, and all such modifications or substitutions should be considered within the scope of protection of this application.

Claims

1. A method for designing network security for remote sensing constellations that adapts to multi-level keys, characterized in that, include: S1: A key management module is built in the onboard computer of the remote sensing constellation satellite. The key management module manages at least three levels of onboard keys. The onboard keys are encrypted using an encryption algorithm. Different levels of onboard keys unlock the corresponding level of functions of the remote sensing constellation satellite. S2: Design two independent seed keys that the ground station periodically sends to the remote sensing constellation satellites, wherein the seed key corresponds to unlocking the function of the corresponding level of the remote sensing constellation satellites; wherein the onboard key and the seed key are independent of each other and are in parallel relationship; S3: Design the uplink and update mechanisms for the onboard keys at each level and the seed key; the uplink mechanism is that all keys are double-encrypted by the ground station and then distributed through the uplink; the update mechanism is that the ground station actively initiates the key update, sends the updated key to the remote sensing constellation satellite, which verifies the updated key, stores it when the verification is successful, and sends the verification failure information back to the ground station when the verification fails. S4: Design the working mechanism of the on-board keys at each level so that they are disabled by default. After the ground station passes the on-orbit test of the remote sensing constellation satellite, send an enable signal to the remote sensing constellation satellite so that it can enable the on-board keys at each level. S5: Design the unlocking and control mechanism of the key management module so that the remote sensing constellation satellite can call the onboard key or the seed key of the corresponding level according to the function call requirements. In the call process, the key to be called is first authenticated, and the key and the function of the corresponding level are unlocked after the authentication is passed.

2. The remote sensing constellation network security design method adapting to multi-level keys according to claim 1, characterized in that, In S1, the different levels of onboard keys are divided into the following categories for unlocking the functions of the remote sensing constellation satellites at the corresponding levels: Level 1 onboard keys unlock the basic communication functions of the remote sensing constellation satellites; Level 2 onboard keys unlock the conventional remote sensing data acquisition and transmission functions of the remote sensing constellation satellites; and Level 3 onboard keys unlock the attitude control functions and payload start / stop functions of the remote sensing constellation satellites.

3. The remote sensing constellation network security design method adapting to multi-level keys according to claim 1, characterized in that, In S1, the encryption algorithm is AES-256, and the onboard keys at each level are stored in the onboard secure storage unit.

4. The remote sensing constellation network security design method adapting to multi-level keys according to claim 1, characterized in that, In S2, the two independent seed keys are respectively referred to as the first seed key and the second seed key. The first seed key and the second seed key are transmitted through a satellite-to-ground laser communication link using different encryption paths. The satellite-to-ground laser communication link used by the first seed key is a laser communication link, and the satellite-to-ground laser communication link used by the second seed key is a quantum key distribution link, with a transmission rate of not less than 10Gbps.

5. The remote sensing constellation network security design method adapting to multi-level keys according to claim 4, characterized in that, In S2, the ground station sets a fixed time interval for sending the first seed key and the second seed key according to the orbital period and arc time of the remote sensing constellation satellite. The orbital period is 95 minutes, the arc time is 10 to 20 minutes, and the fixed time interval is 45 minutes to 1 hour.

6. The remote sensing constellation network security design method adapting to multi-level keys according to claim 1, characterized in that, In S3, the dual encryption process is as follows: the ground station first encrypts the onboard keys at each level and the seed key using a session key generated by quantum key distribution technology, and then performs a second encryption using the AES-256-GCM protocol; after receiving the encrypted onboard keys at each level and the seed key, the remote sensing constellation satellite first decrypts them using the session key, and then decrypts them using the AES-256-GCM protocol to complete key verification; if the key verification passes, the onboard keys at each level and the seed key are stored in the onboard secure storage unit; if the key verification fails, verification failure information is sent back to the ground station.

7. The remote sensing constellation network security design method adapting to multi-level keys according to claim 1, characterized in that, In S4, the on-orbit test includes: the reception and decryption test of the seed key, the corresponding function test of the onboard key unlocking at each level, and the redundancy unlocking test of the two independent seed keys.

8. The remote sensing constellation network security design method adapting to multi-level keys according to claim 7, characterized in that, In S4, the on-orbit test also includes anti-interference testing of the seed key and the satellite key. The on-orbit test uses GNSS+NTP synchronization technology for time synchronization, with a time synchronization accuracy of microseconds.

9. The remote sensing constellation network security design method adapting to multi-level keys according to claim 1, characterized in that, When the remote sensing constellation satellite needs to call the function corresponding to the Nth level satellite key, the key management module first authenticates the N-1 level satellite key. After successful authentication, the function permission corresponding to the N-1 level satellite key is unlocked. Then, the Nth level satellite key is authenticated. After successful authentication, the function corresponding to the Nth level satellite key is unlocked. Here, N is an integer greater than 1, and N does not exceed the total number of levels of the satellite keys at each level.

10. The remote sensing constellation network security design method adapting to multi-level keys according to claim 1, characterized in that, In S5, when authentication fails, the remote sensing constellation satellite records an anomaly log and sends unlocking failure information back to the ground station, which then performs troubleshooting based on the unlocking failure information.

Images