Method and apparatus for dynamic key update of serial communication network for shipboard environment

Abstract

This invention discloses a dynamic key update method and device for serial communication networks in a marine environment. The method includes: when a preset trigger condition is met, a master device generates a first random number and sends a key update request, encrypted and encapsulated by the current first session key, to a slave device; the slave device decrypts the request and returns a second random number; both devices independently calculate and generate a second session key based on a preset initial root key, the first random number, the second random number, and device identification information. Specifically, during the transition from the first session key to the second session key, when receiving encrypted messages, the slave device prioritizes using the second session key to attempt decryption and integrity verification. If the verification fails, it automatically reverts to using the first session key to try again. This invention improves the anti-replay and anti-hacking capabilities of marine communication while effectively ensuring service continuity in environments with high bit error rates on the bus.

Description

Technical Field

[0001] This invention relates to the field of industrial control network security technology, and more specifically, to a method and device for dynamic key update of serial communication networks for marine environments. Background Technology

[0002] As important water transportation vehicles and offshore operation platforms, ships typically have complex networked control systems deployed inside to achieve hierarchical access management and status monitoring of key areas such as the bridge, engine room, and communication room. In traditional ship security and control systems, the Access Control Unit (ACU) is usually connected to multiple card readers, biometric terminals, or security devices (PDs) via serial communication lines to achieve identity recognition, authorization verification, and command issuance.

[0003] Early ship access control and control systems mostly used the Wiegand protocol for communication. While simple in structure, this protocol has significant security and application limitations. First, its communication method is unidirectional; peripherals can only send data to the controller, and the controller cannot detect the online status of peripherals or issue configurations. Second, data is transmitted in plaintext, making it highly susceptible to eavesdropping, tampering, or forgery. Furthermore, the protocol has limited transmission distance, making it unsuitable for the complex physical environment of large ships with multiple compartments and long cables, and failing to meet the high-security requirements (such as SL3–SL4) of ship network security.

[0004] To address these issues, the Safety Industry Association (SIA) proposed the Open Supervised Device Protocol (OSDP). OSDP is based on the RS-485 bus physical layer, supports bidirectional communication, multi-device addressing, and status monitoring, and introduces a Secure Channel mechanism based on AES-128 encryption, which improves communication integrity and confidentiality to a certain extent. Currently, the OSDP protocol is gradually being adopted in shipboard intelligent access control, personnel access management, and device access control systems.

[0005] However, in actual ship applications, the existing standard OSDP protocol security channel mechanism still reveals many technical deficiencies.

[0006] First, the key mechanism is rigid and poses security vulnerabilities. The secure channels of the existing OSDP standard typically rely on a pre-defined, fixed foundation key (SCBK). During long-term device operation, this session key is often only updated when the device is powered on again or re-authenticated, lacking a mechanism for dynamically changing the key during communication. Once this fixed key is leaked, attackers have ample time to launch replay attacks or man-in-the-middle attacks, thereby forging device identity or tampering with control commands.

[0007] Secondly, key negotiation lacks sufficient randomness. In most existing implementations, the control and slave ends use a fixed initial seed or static derivation method to generate communication keys. In a relatively closed environment like a ship's LAN, long-term static configuration leads to increased key predictability, reducing the overall security of the system.

[0008] Third, there are shortcomings in environmental adaptability and business continuity. The electromagnetic environment inside ships is complex, with strong interference from large electromechanical equipment. Furthermore, the RS-485 bus cabling is long, resulting in significant network latency and packet loss. Existing OSDP authentication mechanisms typically employ a one-size-fits-all verification method. If interference causes key state desynchronization or verification failure, the system often needs to disconnect and re-perform the entire handshake process. This mechanism is highly susceptible to control commands (such as emergency door opening and alarms) being interrupted or lost during key updates or interference, severely impacting the robustness and reliability of the ship's control system.

[0009] Fourth, it does not support dynamic security management. With the development of ship intelligence, the system needs to support dynamic access for temporary maintenance terminals or wireless modules. The existing fixed key mechanism is difficult to meet the needs of this plug-and-play dynamic security authentication.

[0010] Therefore, how to design a dynamic key update scheme for serial communication networks that is compatible with the existing OSDP protocol architecture and meets the special needs of ship safety systems is a technical problem that urgently needs to be solved in the field of ship industrial control networks. Summary of the Invention

[0011] In view of this, the present invention proposes a dynamic key update method, master control device and slave device for serial communication networks suitable for ship environments, to solve the technical problems of rigid key update mechanism, weak anti-replay attack capability and easy communication interruption caused by key negotiation in high interference environment in existing ship control systems.

[0012] According to one aspect of the present invention, a dynamic key update method for a serial communication network in a ship environment is proposed, the method being applied to a ship control system including a master control device and slave devices, comprising:

[0013] The master control device and slave devices use the first session key to encrypt and transmit ship control commands and status messages;

[0014] When the preset triggering conditions are met, the master device generates a first random number and sends a key update request message to the slave device. The data field of the key update request message contains the first random number, and the key update request message is encrypted and encapsulated by the first session key.

[0015] The slave device receives and decrypts the key update request message, generates a second random number, and returns it to the master device.

[0016] The master device and the slave device independently calculate and generate the second session key based on the preset initial root key, the first random number, the second random number and the device identification information;

[0017] During the transition from the first session key to the second session key, when the slave device receives an encrypted message, it first attempts to decrypt and verify its integrity using the generated second session key. If the verification fails, it then attempts to decrypt and verify its integrity again using the first session key.

[0018] After the integrity verification is successful, the slave device executes the message command.

[0019] In some implementations, the preset triggering condition includes at least one of the following:

[0020] The usage duration of the current first session key has reached a preset time threshold;

[0021] The cumulative data transmission amount protected by the current first session key has reached the preset data volume threshold;

[0022] A potential security threat to the current ship's communication link has been detected.

[0023] In some implementations, potential security threats to the current ship communication link are detected, including:

[0024] The timestamp of the received message was detected to deviate from the ship's system time beyond the preset valid time window;

[0025] Alternatively, an abnormal jump or rollback in the sequence number of the received message may be detected.

[0026] In some implementations, the key update request message adopts an extended instruction frame structure, the data field of which logically includes:

[0027] The extended instruction code field is used to indicate the execution of a dynamic key negotiation operation;

[0028] The random number payload field is used to carry the first random number;

[0029] The timestamp field is used to carry the system time when the master control device initiates the request;

[0030] When transmitted via the ship's serial bus, the logical content of the data field is included within the verification scope of the message authentication code and encrypted by the first session key.

[0031] In some implementations, independently calculating to generate the second session key includes:

[0032] Both the master and slave devices use a hash-based message authentication code key derivation function to calculate and generate the second session key.

[0033] In some implementations, when a slave device receives an encrypted message, it first attempts to decrypt and verify its integrity using the generated second session key. If the verification fails, it then attempts to decrypt and verify the integrity again using the first session key, including:

[0034] The slave device uses the second session key to decrypt the received encrypted message and verify the message authentication code;

[0035] If the message authentication code verification fails, the integrity check is deemed to have failed, and the slave device immediately retrieves the first session key to decrypt the encrypted message and verify the message authentication code.

[0036] If the verification fails again, the encrypted message is discarded.

[0037] In some implementations, the method further includes the following anomaly recovery mechanism for high-disturbance environments on ships:

[0038] If the master device does not receive a response from the slave device within the preset timeout period after sending the key update request message, or receives a verification error response, the master device continues to use the first session key and resends the key update request message until a valid response is received or the maximum number of retries is reached.

[0039] In some implementations, the method further includes the following key expiration mechanism:

[0040] When the slave device successfully decrypts and passes the integrity verification of at least one subsequent message using the second session key, or after the preset transition period ends, the slave device marks the first session key as invalid, or overwrites the storage space of the first session key during the next key update.

[0041] According to another aspect of the present invention, a main control device for a ship control system is also provided, comprising:

[0042] The first communication interface module is used to connect with slave devices distributed in various compartments of the ship via a serial bus;

[0043] The first dynamic key negotiation module is used to generate a first random number when the triggering condition is met, construct a key update request message containing the first random number, and calculate a second session key based on the initial root key, the first random number, the received second random number, and the device identification information.

[0044] The first secure channel management module is used to encrypt and encapsulate the key update request message using the currently valid first session key, and to control the switching of the session key based on the response of the slave device during the key update.

[0045] According to another aspect of the present invention, a subordinate device for a ship control system is also provided, comprising:

[0046] The second communication interface module is used to connect to the main control device via a serial bus to send and receive encrypted ship control commands and status messages.

[0047] The second dynamic key negotiation module is used to decrypt the key update request message sent by the master control device after receiving the message encrypted and encapsulated by the first session key to obtain the first random number and generate a second random number to return to the master control device, and independently calculate and generate the second session key based on the preset initial root key, the first random number, the second random number and the device identification information.

[0048] The second secure channel management module is used to manage the storage and switching of session keys. It is configured to retain the first session key after the second session key is generated; and during the transition from the first session key to the second session key, the received encrypted messages are decrypted and their integrity is verified using the second session key first. If the verification fails, it automatically falls back to using the first session key for decryption and integrity verification.

[0049] This invention overcomes the limitations of the traditional OSDP protocol's reliance on static keys by introducing a trigger-based dynamic key negotiation mechanism into a serial communication network. It utilizes a first and second random number exchanged between the master and slave devices, combined with a preset initial root key and device identification information, to independently derive an update session key (i.e., a second session key). This effectively improves the unpredictability of the communication link, thereby significantly enhancing the ability to resist replay attacks and key cracking. In particular, considering the strong electromagnetic interference and high bus transmission error rate in the marine environment, this invention innovatively constructs a dual-key buffer and smooth switching mechanism during the key update transition. When receiving a message, the slave device prioritizes attempting to decrypt and verify its integrity using the newly generated update session key. If verification fails, it automatically reverts to using the old session key from before the update to attempt verification again. This fault-tolerant logic ensures that even if the key negotiation confirmation message is lost or damaged, critical control commands can still be correctly parsed and executed, effectively avoiding communication interruptions or system deadlocks caused by key state asynchrony. Thus, while ensuring high-level communication security, it achieves continuity and high reliability of ship control operations.

[0050] The methods and apparatus of the present invention have other features and advantages that will be apparent from or will be set forth in detail in the accompanying drawings and following detailed description, which together serve to explain the particular principles of the invention. Attached Figure Description

[0051] The above and other objects, features and advantages of the present invention will become more apparent from the more detailed description of exemplary embodiments of the invention in conjunction with the accompanying drawings, wherein the same reference numerals generally represent the same components in the exemplary embodiments of the invention.

[0052] Figure 1 This is a flowchart of a dynamic key update method for a serial communication network in a ship environment according to an embodiment of the present invention;

[0053] Figure 2 This is a schematic diagram of the overall system structure according to an exemplary embodiment of the present invention;

[0054] Figure 3 This is a schematic diagram of the overall process according to an exemplary embodiment of the present invention;

[0055] Figure 4 This is a schematic diagram illustrating the detailed interaction process between the master control device and the slave device according to an exemplary embodiment of the present invention. Detailed Implementation

[0056] Preferred embodiments of the invention will now be described in more detail with reference to the accompanying drawings. While preferred embodiments of the invention are shown in the drawings, it should be understood that the invention can be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that the invention will be thorough and complete, and will fully convey the scope of the invention to those skilled in the art.

[0057] The core concept of this invention lies in providing a dynamic key update mechanism for serial communication networks suitable for complex electromagnetic environments such as ships. Addressing the shortcomings of existing ship control systems (such as access control or security networks based on the OSDP protocol) that rely heavily on static keys and have weak anti-interference capabilities, this invention establishes a closed-loop security scheme of dynamic triggering, independent derivation, and smooth switching, while maintaining compatibility with existing physical buses (such as RS-485) and protocol frame formats. This scheme utilizes bidirectional random numbers exchanged between the master and slave devices, along with a preset initial root key, to achieve periodic or event-driven updates of the session key, completely eliminating the security risks associated with key fixation. Specifically, to cope with the high bit error rate and communication latency in the ship environment, this invention introduces dual-key buffering and trial-and-error decryption logic, allowing slave devices to simultaneously maintain the decryption capability of both the updated session key (i.e., the second session key) and the old session key (i.e., the first session key) during the key update transition window. The valid decryption key is automatically determined and selected based on the integrity verification result. This design ensures that critical ship control commands can be transmitted without interruption even in abnormal situations such as lost or out-of-synchronization negotiation messages, thus creating an industrial control network that combines high dynamic security with high business continuity.

[0058] Figure 1 A flowchart illustrating a dynamic key update method for a serial communication network in a marine environment according to an embodiment of the present invention is shown. This method is applied to a ship control system including a master device (such as a ship security controller) and slave devices (such as card readers and sensor terminals). The master device and slave devices can be connected via an RS-485 serial bus or other industrial fieldbus, and both parties can implement the following steps S101 to S106 through a preset logic or protocol stack.

[0059] In step S101, the master control device and the slave device use the first session key to encrypt and transmit ship control commands and status messages.

[0060] In this embodiment, the first session key is a relative concept, referring to the valid key currently being used by both communicating parties. In the initial stage when the system is first powered on and started, the first session key refers to the initial session key negotiated and generated by the master device and the slave device based on the preset initial root key K0 (also known as the static master key) through a standard handshake process (such as the CHALLENGE_CMD command in the OSDP protocol); while in the dynamic update cycle after the system enters stable operation, the first session key refers to the old session key determined in the previous round of negotiation and currently being used.

[0061] Specifically, the initial root key K0 is the fundamental security parameter of the entire system security architecture. In some implementations, K0 is burned into the secure storage area of ​​the master and slave devices at the factory. To ensure that the key of each device is unique, K0 is usually bound to the device's unique hardware identifier DevID (such as UUID).

[0062] After the first session key is established, all ship control commands issued by the master control device, such as door opening and alarm reset, as well as status messages reported by slave devices, such as card swiping data and door magnetic status, are encrypted (e.g., in AES-128-CBC mode) and protected for integrity using this key to ensure that the data is not eavesdropped on during transmission.

[0063] In step S102, when the preset triggering conditions are met, the master device generates a first random number and sends a key update request message to the slave device.

[0064] In some implementations, to further enhance security, the preset triggering conditions include at least one of the following: the duration of use of the current first session key reaches a preset time threshold (e.g., 30 minutes); the cumulative data transmission volume protected by the current first session key reaches a preset data volume threshold; or a potential security threat event against the current ship communication link is detected.

[0065] The detection of potential security threats to the current ship's communication link can include: detecting a deviation between the timestamp of a received message and the ship's system time that exceeds a preset effective time window (e.g., a deviation exceeding 5 seconds, indicating a possible replay attack); or detecting an abnormal jump or rollback in the sequence number of a received message. Once any of the above potential security threats are detected, the system can immediately initiate a key update process to minimize the time window for attackers to crack the key.

[0066] In this step, the master device uses its internal high-quality random number generator (TRNG or PRNG) to generate a first random number (Nonce_M) with high randomness. The master device then constructs a key update request message.

[0067] To achieve compatibility with standard protocols and ensure the security of the update command itself, this embodiment employs a specially designed encapsulation mechanism: the data field of the key update request message contains the first random number, and the entire message is encrypted and encapsulated by the current first session key.

[0068] In some implementations, the key update request message uses an extended instruction frame structure (e.g., a custom instruction code 0xF1). The data field of this instruction frame logically includes:

[0069] Extended instruction code field (e.g., 0xF1): used to instruct the slave device to perform dynamic key negotiation operation;

[0070] Random number payload field: Used to carry long random numbers (e.g., 16-byte Nonce_M) generated by the master device.

[0071] Timestamp field: Used to carry the system time when the master device initiates the request, preventing replay of the update command itself.

[0072] The following is the OSDP protocol message frame structure used in this invention. This format remains unchanged before and after the extension:

[0073]

[0074] Before the extension, the data fields of CHALLENGE_CMD (0x76) are as follows:

[0075]

[0076] The standard instructions before expansion can be shown as follows:

[0077]

[0078] After expansion, the data field of DYNAMIC_KEY_UPDATE_CMD (0xF1) is as follows:

[0079]

[0080] Specifically, when transmitted via the ship's serial bus, the aforementioned logical content (instruction code + random number + timestamp) is not sent in plaintext. Instead, it is included as payload within the verification scope of the Message Authentication Code (MAC) and encrypted by the first session key. Therefore, even if an attacker intercepts the message, without the first session key, they cannot decrypt it to obtain the random number or forge a legitimate update request.

[0081] Step S103: The slave device receives and decrypts the key update request message, generates a second random number, and returns it to the master device.

[0082] After receiving a message from the master device, the slave device first uses its currently held first session key to decrypt and verify the message's integrity. If the verification passes, it indicates that the request indeed originated from a legitimate master device.

[0083] Subsequently, the slave device can use its own random number generator to generate a second random number (Nonce_S). This second random number will be used by the slave device in key negotiation and will be encapsulated in a response message and sent back to the master device. Similarly, those skilled in the art will understand that this response message is also encrypted and protected by the first session key.

[0084] In step S104, the master device and the slave device independently calculate and generate the second session key based on the preset initial root key, the first random number, the second random number and the device identification information.

[0085] At this point, both communicating parties have all the information needed to calculate the new key: a pre-set and confidential initial root key (K0), a random number generated by the master device (Nonce_M), a random number generated by the slave device (Nonce_S), and device identification information (such as UUID).

[0086] To ensure the generated key has a high degree of unpredictability, the master and slave devices can independently calculate and generate the second session key using an HMAC-based key derivation function (HKDF). For example, using a preset initial root key (K0) as the key or salt value of the pseudo-random function, and the master device's random number (Nonce_M), the slave device's random number (Nonce_S), and the device's unique identifier (e.g., UUID) as input key materials, a fixed-length second session key can be calculated and generated.

[0087] This invention introduces bidirectional random numbers, ensuring the randomization of the key by preventing attackers from controlling the random number generation of one side, even if they can control the generation of one side's random numbers. Simultaneously, the introduction of a device ID parameter ensures that even if different devices share the same initial root key (though this is unlikely, it is possible), the generated session key remains unique. Furthermore, since each negotiation uses entirely new random numbers, the generated session keys are completely independent, further enhancing forward security.

[0088] In step S105, during the transition from the first session key to the second session key, when the slave device receives an encrypted message, it first attempts to decrypt and verify the integrity using the generated second session key. If the verification fails, it attempts to decrypt and verify the integrity again using the first session key.

[0089] This invention proposes a smooth transition mechanism specifically designed to cope with highly disruptive environments such as ships. After calculating the second session key, the slave device enters a dual-key buffer state, that is, it retains both the first and second session keys simultaneously.

[0090] The "transition period" refers to the uncertain time during which the slave device has generated a new key, but it has not yet confirmed whether the master device has successfully switched to the new key. During this period, the messages sent by the master device may fall into two categories:

[0091] (a) Normal situation: The master device has received the response from the slave device and has switched to using the second session key for encryption;

[0092] (ii) Abnormal situation: If the master device does not receive a response from the slave device (e.g., the response message is lost due to interference on the bus), the timeout mechanism is triggered. The master device will still use the first session key to resend the key update request message or query command.

[0093] In response to the above situation, the decryption logic for the slave device proposed in this invention specifically includes:

[0094] The slave device first assumes that the received message is encrypted using the new key, decrypts the ciphertext data using the second session key, and verifies the message authentication code (MAC). If the MAC verification is successful, it indicates that the master switch has been successfully completed, and the process can proceed to step S106.

[0095] If MAC verification fails (integrity verification fails), the slave device does not discard the message directly, but immediately retrieves the old key (i.e., the first session key) to decrypt the same ciphertext data and verify the MAC again.

[0096] If the verification passes, it means that the master device has not used the new key (it may be resending the old command), and can proceed to step S106, where the slave device will process the command normally and maintain the dual-key status.

[0097] If both verifications fail, the encrypted message is discarded.

[0098] Specifically, the performance loss caused by the aforementioned dual decryption logic in the ship control network scenario where this invention is applied is completely controllable. Firstly, the communication frequency of ship access control or alarm commands is relatively low, and the data payload per frame is small. Secondly, symmetric algorithms such as AES and HKDF have extremely high computational efficiency on modern embedded processors. In actual testing, the additional computational delay caused by this trial-and-error process typically occurs only in 1 to 2 messages during the key switching instant, consuming minimal time overhead and having no substantial impact on the real-time performance of the ship control system, while significantly improving service continuity.

[0099] In some embodiments, the method proposed in this invention further includes an anomaly recovery mechanism for high-interference environments on ships: if the master control device does not receive a response from the slave device within a preset timeout period after sending the key update request message, or receives a verification error response, the master control device continues to use the first session key and resends the key update request message until a valid response is received or the maximum number of retries is reached. This mechanism, in conjunction with the dual-key decryption logic of the slave device, ensures the robustness of the handshake process.

[0100] Step S106: After the integrity verification is successful, the slave device executes the message command.

[0101] Once the slave device successfully decrypts the received encrypted message using any key and passes the verification, it executes the corresponding control action (such as unlocking or status reporting).

[0102] In some implementations, in order to optimize storage space and end the transition period, the present invention also adopts a key elimination mechanism: when the slave device successfully decrypts and passes the integrity verification of at least one subsequent message using the second session key, it indicates that the master control end has confirmed the switchover, or after the preset transition period ends, the slave device marks the first session key as invalid, or uses the newly generated session key to overwrite the storage space of the first session key in the next round of key updates, that is, a ping-pong buffering mechanism is adopted to complete a smooth and seamless key rotation.

[0103] Figure 2 A schematic diagram of the overall system structure according to an embodiment of the present invention is shown. As shown in the figure, the ship control system mainly consists of a master device and slave devices, which are connected through a physical communication link (such as RS-485 bus, Ethernet or wireless network).

[0104] The main control equipment is typically deployed in the ship's security control host, and its core logic carrier is the main control terminal module. This main control terminal module may include three sub-modules: a first communication interface module, a first dynamic key negotiation module, and a first secure channel management module.

[0105] The first communication interface module is used to connect with slave devices distributed in various compartments of the ship via a serial bus, and is responsible for sending and receiving encrypted and encapsulated secure OSDP messages.

[0106] The first dynamic key negotiation module is the core unit for implementing key updates. For example... Figure 2 As shown, this module can be further subdivided into three functional units: a random number generation unit, which generates a first random number (Nonce_M) with high unpredictability when the triggering condition is met; a secure handshake management unit, which constructs a key update request message, encapsulating the first random number and timestamp parameters; and a key derivation unit, which independently calculates the update session key based on the initial root key K0, the first random number, the received second random number, and the device identification information.

[0107] The first secure channel management module is used to encrypt and encapsulate the key update request message using the currently valid first session key, and during the key update, to control the switching and activation of the session key based on the response of the slave device.

[0108] Correspondingly, slave devices are deployed on each distributed control node (such as the door controller), and their core logic carrier is the slave module. This slave module may include a second communication interface module, a second dynamic key negotiation module, and a second secure channel management module.

[0109] The second communication interface module is used to connect to the main control device via a serial bus to send and receive encrypted ship control commands and status messages.

[0110] The second dynamic key negotiation module may include three sub-units: a random number generation unit, a key derivation unit, and a secure handshake management unit. Specifically, after receiving a key update request message encrypted and encapsulated by the first session key from the master control device, the secure handshake management unit coordinates decryption to obtain the first random number; the random number generation unit generates a second random number and returns it to the master control device; and the key derivation unit independently calculates and generates an update session key based on a preset initial root key, the first random number, the second random number, and device identification information.

[0111] The second secure channel management module is used to manage the storage and switching of session keys. Specifically, this module is configured to perform dual decryption logic: after generating an updated session key, the old key is not immediately discarded, but the first session key is retained; and during the transition from the first session key to the second session key, received encrypted messages are preferentially decrypted and their integrity is verified using the second session key. If the verification fails, it automatically reverts to using the first session key for decryption and integrity verification.

[0112] Figure 3 The overall lifecycle flow of the method is further demonstrated, covering the entire process from system initialization to exception recovery.

[0113] Step S301 (Initialization Phase): The system first performs static master key (K0) authentication, establishes a basic OSDP secure channel, and generates initial dynamic negotiation parameters, including a random number (Nonce), a unique device identifier (DevID), and timestamp information.

[0114] Step S302 (Dynamic Key Negotiation): This is an interactive process. The master terminal sends a request containing the master terminal's random number (Nonce_M) and a timestamp; the slave terminal generates a response random number (Nonce_S) and uses the HKDF algorithm to derive the session key Ksession based on parameters such as K0, Nonce_M, Nonce_S, and DevID; the master terminal synchronously calculates the same session key.

[0115] Step S303 (Secure Channel Communication): Both parties use the generated session key (Ksession) to encrypt and transmit OSDP messages, and perform integrity verification. Messages at this stage are compatible with the original OSDP frame structure and contain encryption identifiers.

[0116] The system continuously monitors the session status to determine if preset trigger conditions are met. For example, has the session exceeded a preset time (e.g., 30 minutes)? Has the cumulative data transmission volume exceeded the limit? Has any anomaly or attack been detected? Has a ship mode switch occurred?

[0117] If the above triggering conditions are met, proceed to step S304 (key update), re-execute the negotiation process of step S302, generate a new session key Ksession, and realize key rotation. Then proceed to step S305 (channel synchronization and fault tolerance). Figure 3 As shown, at this stage, the slave end retains two sets of keys (the old session key and the newly generated session key) and has an automatic rollback mechanism for verification failure to ensure a smooth transition even if packet loss occurs during the update process, and then proceeds to step S306 (anomaly detection and recovery).

[0118] If the above triggering conditions are not met, the system skips steps S304 and S305, maintains the current secure communication state using the first session key, and proceeds to step S306 (anomaly detection recovery).

[0119] Step S306 (Anomaly Detection and Recovery): Throughout the communication process, the system continuously monitors the integrity and timestamp of the messages. Once an anomaly is detected (such as message tampering or excessive timestamp deviation), the system will forcibly disconnect the current channel and restart the dynamic negotiation process to restore system security.

[0120] After the system returns to normal, it resumes continuous monitoring.

[0121] Figure 4 It then describes in detail the actions and coordination between the master and slave ends during a complete key update process from the perspective of timing interaction.

[0122] S401 (Secure Channel Initialization): The master device and slave device use the pre-shared master key K0 to complete the establishment of a standard OSDP secure channel.

[0123] S402 (Monitoring Session Status and Determining Triggering Conditions): The system continuously monitors the current session status and determines whether time, traffic, or threat triggering conditions are met. If not, proceed to S407 to continue secure communication using the current session key; if met, proceed to the update process (S403, S404, S405, and S406).

[0124] S403: The master terminal generates Nonce_M and Timestamp_M and sends a key update request.

[0125] S404: The slave device generates a Nonce_S and returns a response message.

[0126] S405: The master and slave ends respectively use the HKDF algorithm (input K0, Nonce_M, Nonce_S and DevID) to derive a new session key (Ksession_new).

[0127] S406 (Key Switching and Synchronization): For example... Figure 4 As shown, the system activates Ksession_new (the newly generated session key, i.e., the second session key) and caches Ksession_prev (the old session key, i.e., the first session key) to provide a dual-key buffering mechanism.

[0128] S408: Secure communication is performed using the new session key Ksession_new. The process then loops back to S402, continuously monitoring the session status to determine whether to trigger the next round of key switching.

[0129] In summary, the embodiments of the present invention provide a dynamic key update scheme for serial communication networks in marine and industrial control environments. Compared with the Transport Layer Security (TLS) protocol or Internet Key Exchange (IKE) protocol widely used in the Internet field, the present invention makes substantial optimizations and improvements to the characteristics of half-duplex, low-bandwidth, and connectionless serial buses such as RS-485.

[0130] Firstly, regarding the handshake mechanism, traditional Internet protocols typically tend to immediately tear down and re-handshake when key negotiation fails or verification errors occur. This is acceptable for stable TCP / IP-based networks, but in ship security control systems, communication links often carry real-time access control or alarm commands. If a connection is lost and services are interrupted due to the loss of a single handshake message under strong interference, it will pose an unacceptable security risk. Therefore, this invention abandons the traditional key switching logic and adopts a smooth transition strategy. By introducing a dual-key buffer mechanism (i.e., simultaneously retaining the old session key and the updated session key) at the slave device end, the system can tolerate the loss or delay of key update acknowledgment messages (ACK). Even if the master end retransmits a message encrypted with the old key due to not receiving a response, the slave device can correctly parse it through dual decryption logic, thus achieving zero-interruption communication during key updates.

[0131] Secondly, regarding algorithm selection, considering that shipboard front-end equipment (such as card readers and sensors) typically has limited computing resources, this invention avoids high-overhead asymmetric encryption algorithms such as RSA or ECC. Instead, it uses a lightweight HKDF algorithm and bidirectional random number-derived session keys based on a pre-set root of trust (K0). This not only reduces computational latency but also ensures millisecond-level fast key rotation even on embedded devices with limited computing power.

[0132] Finally, considering the unique electromagnetic interference and long-distance wiring environment of ships, this invention places equal importance on security and robustness. By combining a triggered update mechanism with an automatic fallback mechanism for verification failures, this solution effectively solves the communication intermittent problems that easily occur in the standard OSDP protocol under harsh operating conditions. This design allows the ship's control system to enjoy the high level of security protection provided by dynamic keys while maintaining industrial-grade high reliability, completely resolving the contradiction between the risks of static keys and the stability of dynamic updates.

[0133] It should be emphasized that the descriptions of specific embodiments and the processes shown in the accompanying drawings in this specification are intended to clearly illustrate the technical solutions of the present invention, rather than limiting its scope of protection to the specific structures, sequences, or combinations described therein. Without departing from the core spirit and principles of the present invention, those skilled in the art will understand that the various technical features described in the embodiments can be arbitrarily reorganized or split, and the execution order of the steps can also be adjusted; in some cases, parallel or multi-tasking processing is also feasible. Therefore, any modifications, equivalent substitutions, and improvements made to the above embodiments based on the technical essence of the present invention should be included within the scope of protection of the present invention.

Claims

1. A dynamic key update method for serial communication networks in a shipboard environment, characterized in that, The method is applied to a ship control system that includes master control equipment and slave equipment, including: The master control device and slave devices use the first session key to encrypt and transmit ship control commands and status messages; When the preset triggering conditions are met, the master device generates a first random number and sends a key update request message to the slave device. The data field of the key update request message contains the first random number, and the key update request message is encrypted and encapsulated by the first session key. The slave device receives and decrypts the key update request message, generates a second random number, and returns it to the master device. The master device and the slave device independently calculate and generate the second session key based on the preset initial root key, the first random number, the second random number and the device identification information; During the transition from the first session key to the second session key, when the slave device receives an encrypted message, it first attempts to decrypt and verify its integrity using the generated second session key. If the verification fails, it then attempts to decrypt and verify its integrity again using the first session key. In this process, the slave device uses the second session key to decrypt the received encrypted message and verify the message authentication code. If the message authentication code verification fails, the integrity check is deemed to have failed, and the slave device immediately retrieves the first session key to decrypt the encrypted message and verify the message authentication code; if the verification fails again, the encrypted message is discarded. After the integrity verification is successful, the slave device executes the message command; The method also includes the following anomaly recovery mechanism for high-disruption environments on ships: If the master device does not receive a response from the slave device within the preset timeout period after sending the key update request message, or receives a verification error response, the master device continues to use the first session key and resends the key update request message until a valid response is received or the maximum number of retries is reached.

2. The method according to claim 1, characterized in that, The preset triggering conditions include at least one of the following: The usage duration of the current first session key has reached a preset time threshold; The cumulative data transmission amount protected by the current first session key has reached the preset data volume threshold; A potential security threat to the current ship's communication link has been detected.

3. The method according to claim 2, characterized in that, Potential security threats to the current ship's communication links have been detected, including: The timestamp of the received message was detected to deviate from the ship's system time beyond the preset valid time window; Alternatively, an abnormal jump or rollback in the sequence number of the received message may be detected.

4. The method according to claim 1, characterized in that, The key update request message adopts an extended instruction frame structure, and the data field of the instruction frame structure logically includes: The extended instruction code field is used to indicate the execution of a dynamic key negotiation operation; The random number payload field is used to carry the first random number; The timestamp field is used to carry the system time when the master control device initiates the request; When transmitted via the ship's serial bus, the logical content of the data field is included within the verification scope of the message authentication code and encrypted by the first session key.

5. The method according to claim 1, characterized in that, Each process is independently computed to generate the second session key, including: Both the master and slave devices use a hash-based message authentication code key derivation function to calculate and generate the second session key.

6. The method according to claim 1, characterized in that, The method also includes the following key expiration mechanism: When the slave device successfully decrypts and passes the integrity verification of at least one subsequent message using the second session key, or after the preset transition period ends, the slave device marks the first session key as invalid, or overwrites the storage space of the first session key during the next key update.

7. A main control device for a ship control system, characterized in that, The ship control system employs the dynamic key update method for a serial communication network in a ship environment as described in any one of claims 1 to 6, including: The first communication interface module is used to connect with slave devices distributed in various compartments of the ship via a serial bus; The first dynamic key negotiation module is used to generate a first random number when the triggering condition is met, construct a key update request message containing the first random number, and calculate a second session key based on the initial root key, the first random number, the received second random number, and the device identification information. The first secure channel management module is used to encrypt and encapsulate the key update request message using the currently valid first session key, and to control the switching of the session key based on the response of the slave device during the key update.

8. A slave device of a ship control system, characterized in that, The ship control system employs the dynamic key update method for a serial communication network in a ship environment as described in any one of claims 1 to 6, including: The second communication interface module is used to connect to the main control device via a serial bus to send and receive encrypted ship control commands and status messages. The second dynamic key negotiation module is used to decrypt the key update request message sent by the master control device after receiving the message encrypted and encapsulated by the first session key to obtain the first random number and generate a second random number to return to the master control device, and independently calculate and generate the second session key based on the preset initial root key, the first random number, the second random number and the device identification information. The second secure channel management module is used to manage the storage and switching of session keys. It is configured to retain the first session key after the second session key is generated; and during the transition from the first session key to the second session key, the received encrypted messages are decrypted and their integrity is verified using the second session key first. If the verification fails, it automatically falls back to using the first session key for decryption and integrity verification.

Images