CN118540135A - System component communication method and storage medium applied to port network security - Google Patents

Abstract

The present invention discloses a system component communication method and storage medium applied to port network security, wherein the communication method includes the following steps: establishment of a certificate authority; creation and submission of a certificate signing request; review of identity authentication and certificate signing request; generation of a certificate; distribution of a certificate; data transmission: judging whether the digital certificates carried by both components to be communicated are valid, if so, communication is performed, if not, communication is rejected. A component is selected as a certificate authority to manage the key and digital certificate of the component, and is responsible for issuing digital certificates and digital signatures for other components added to the system. Thereafter, communications within the system will require the use of digital certificates issued by the certificate authority, which ensures that only authenticated components can communicate with each other, thereby preventing unauthorized devices from joining the system, thereby preventing unauthorized access and data leakage.

Description

A system component communication method and storage medium for port network security

Technical Field

The present invention relates to the technical field, and in particular to a system component communication method and storage medium applied to port network security.

Background Art

At present, the container throughput of my country's ports continues to grow, which will inevitably prompt terminal operators to continuously improve the work efficiency of various departments and links in the terminal, and the lifting speed of terminal cranes is the biggest factor affecting the terminal's operating efficiency. As a distribution center for goods and information, ports need to process a large amount of data every day, including cargo information, crane operating status, container lifting instructions, etc.

In the current field of port network security, with the improvement of port automation and intelligence, port network systems are increasingly dependent on communication between various components. These components include but are not limited to port machinery PLC (programmable logic controller), video signal server, video host and console, etc. Traditional communication methods may lack effective security mechanisms, resulting in data in the communication process being easily accessed, tampered or destroyed by unauthorized access, thus affecting the normal operation of the port and the confidentiality of the data. Therefore, how to implement an efficient and secure identity authentication mechanism in the port's network system has become an urgent problem to be solved.

Summary of the invention

Therefore, it is necessary to provide a system component communication method and storage medium applied to port network security to solve the problem of how to implement an efficient and secure identity authentication mechanism in the port's network system.

To achieve the above object, the present invention provides a system component communication method applied to port network security, comprising the following steps:

Establishment of a certificate authority: The components include port machinery PLC, video signal server, video host, and console. One of the components is selected as the certificate authority;

Creation and submission of certificate signing request: The requesting components generate their own key pairs. Each requesting component uses the private key of its own key pair to create a certificate signing request and sends it to the certificate authority. The certificate signature contains the public key of the key pair of the component and the identification information of the component.

Identity verification and certificate signing request review: The certificate authority receives the certificate signing request sent by the requested component, verifies the identity of the requested component, and reviews the certificate signing request to determine whether the public key of the requested component key pair has been tampered with. If not, the requested component passes the verification;

Certificate generation: The certificate authority uses the public key of the requested component key pair, combined with the identification information of the requested component, to create a digital certificate, and the certificate authority uses the private key to digitally sign the digital certificate;

Certificate distribution: The certificate authority sends the signed digital certificate to the requesting component, and the requesting component installs the issued digital certificate;

Data transmission: Determine whether the digital certificates carried by both components to be communicated are valid. If so, communication will proceed; if not, communication will be rejected.

Furthermore, in the step of “determining whether the digital certificates carried by both components to be communicated are valid”, the following steps are also included:

Exchange digital certificates: The components to be communicated exchange their respective digital certificates;

Verify the certificate signature: obtain the public key of the certificate authority from the trusted certificate repository and use this public key to verify the signature of the other party's digital certificate;

Check the validity period of the certificate: determine whether the digital certificate of the component to be communicated is within the validity period. If so, the digital certificate is valid and the corresponding components to be communicated can be used for communication. If not, the digital certificate is invalid and the corresponding components to be communicated cannot be used for communication.

Furthermore, after the "checking the validity period of the certificate", the following steps are also included:

Check the certificate revocation status: obtain the certificate revocation list of the certificate authority, and determine whether the digital certificate of the component to be communicated is in the certificate revocation list. If not, the digital certificate is valid and the corresponding components to be communicated can be used for communication. If so, the digital certificate is invalid and the corresponding components to be communicated cannot be used for communication.

Furthermore, during the “data transmission”, the following steps are also included:

Determine whether the sensitivity of the transmitted information is greater than a threshold. If so, communicate using asymmetric encryption; if not, communicate using symmetric encryption.

Furthermore, information with a sensitivity greater than a threshold includes user account passwords, personal identity information, and financial records.

Furthermore, when the “communication is carried out in an asymmetric encryption manner”, the following steps are also included:

A key pair is created through a random number generator, the certificate authority obtains the public key of the key pair, and the component encrypts, stores and backs up the private key of the key pair.

Furthermore, the method further comprises the following steps:

Determine whether the sensitivity of the transmitted information is greater than a threshold. If so, encrypt the information with a sensitivity greater than the threshold and store it on the server.

Furthermore, when “encrypting information with a sensitivity greater than a threshold and storing it on a server”, the following steps are also included:

The trusted platform module generates an encryption key, encrypts information with a sensitivity greater than a threshold value using the encryption key generated by the trusted platform module, and stores the information on the server.

Furthermore, the method further comprises the following steps:

The Trusted Platform Module periodically changes encryption keys.

To achieve the above-mentioned object, the present invention provides a storage medium, wherein the storage medium stores a computer program, wherein when the computer program is executed, any one of the system component communication methods for port network security is executed.

The above technical solution has the following beneficial effects:

The system component communication method proposed in this application manages the key and digital certificate of the component by selecting a component as a certificate authority, which is responsible for issuing digital certificates and digital signatures for other components joining the system. Thereafter, communication within the system will require the use of digital certificates issued by the certificate authority, which ensures that only authenticated components can communicate with each other, thereby preventing unauthorized devices from joining the system, thereby preventing unauthorized access and data leakage. As the port network security system expands and upgrades, new components can be easily added and digital certificates can be generated and distributed for them without major modifications to the entire system.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG1 is a flow chart of a method for communicating between system components in this embodiment;

FIG2 is a second flow chart of the system component communication method in this embodiment;

FIG3 is a third flow chart of the system component communication method in this embodiment;

FIG4 is a fourth flow chart of the system component communication method in this embodiment;

FIG5 is a fifth flowchart of the system component communication method in this embodiment;

FIG6 is a sixth flowchart of the system component communication method in this embodiment;

FIG. 7 is a schematic diagram of system components in this embodiment.

DETAILED DESCRIPTION

In order to explain the technical content, structural features, achieved objectives and effects of the technical solution in detail, the following is a detailed description in conjunction with specific embodiments and accompanying drawings.

Please refer to FIG1 . This embodiment provides a system component communication method for port network security, including the following steps:

Step S101, establishment of a certificate authority: the components include a port machinery PLC (programmable logic controller), a video signal server, a video host, and a control console, and one of the components is selected as a certificate authority;

The "port machinery" of a port usually refers to port loading and unloading machinery, which is a general term for various types of mechanical equipment used for port cargo loading and unloading operations. Port machinery can include cranes, conveyor belts, loading and unloading bridges, stackers and other equipment, which play a vital role in the logistics and cargo transshipment of ports. The port machinery PLC is connected to the port machinery to load and unload port cargo by controlling the port machinery. The programmable logic controller is connected to the video host through a video signal server. The video host is used to display the loading and unloading information of the container through a monitor. The structure is shown in Figure 7. When the port machinery is not operating, it is not bound to any console. When the port machinery is operating, it can be bound to any console. The relationship between the port machinery and the console is an M-to-N relationship. When the port terminal driver is operating on the console, he remotely controls the port machinery through the buttons and handles of the console. After receiving the command, the actuator of the port machinery performs mechanical actions and sends execution instructions to the programmable logic controller of the port machinery through the IO communication terminal.

During the system initialization phase, a reliable component is selected to act as a certificate authority based on security performance and reliability assessment. For example, a video signal server may be selected as a certificate authority to manage the security communications of the entire system. In some embodiments, a console may be selected as a certificate authority to manage the security communications of the entire system.

The Certificate Authority (CA) plays a core role in the port network security system, responsible for generating and managing digital certificates to ensure the security of the entire communication process. The CA first uses a mature public key infrastructure (PKI) algorithm, such as RSA or ECDSA, to generate a 2048-bit or higher key pair to ensure the security and encryption strength of the key. From this key pair, the CA extracts the public key and combines it with a defined, unique Distinguished Name (DN), using the private key to sign this information to form a self-signed root certificate, which serves as the starting point of the trust chain and provides the basis for verifying the validity of other certificates. In order to maintain the long-term security of the system, the CA sets the validity period of the root certificate to be usually for many years to reduce the frequency of updates. At the same time, before the certificate expires, it provides a mechanism for updating or renewing to ensure the continuity of communication. In addition, the environmental security of the CA is also crucial, including physical security measures to prevent unauthorized access and physical damage, as well as network security measures such as encryption and firewalls to resist network attacks. Through these measures, the CA ensures the security of communication between components in the port network system and the confidentiality of data.

Please refer to FIG. 1 , step S102 , creation and submission of a certificate signing request: the requesting components generate their own key pairs, each requesting component uses the private key of its own key pair to create a certificate signing request, and sends it to the certificate authority, the certificate signature contains the public key of the requesting component key pair and the identification information of the component;

After the video signal server is selected as the certificate authority, other components in the system, such as port machinery PLC, video host and console, must apply for digital certificates from the certificate authority if they want to join the system. The requesting (to be added) components need to generate their own key pairs and use their private keys to create certificate signing requests. These requests contain the public key and the component's identification information and are sent to the certificate authority.

The certificate signing request (CSR) contains the component's public key and a series of identification information, such as the component name, organization, department, etc. This information together defines the identity of the component and provides the certificate authority (CA) with the necessary data to verify the legitimacy of the component. The submission process of the CSR must be completed through a secure channel to ensure that the information is not intercepted or tampered with during transmission. In practical applications, this usually involves the use of a secure socket layer (HTTPS) connection, which provides an encrypted communication channel to ensure the security and integrity of data transmission. In addition, other encrypted message transmission protocols such as Secure/Multipurpose Internet Mail Extensions (S/MIME) or Transport Layer Security (TLS) can also be used, which can also provide strong security protection. Through these security measures, the CSR can be securely transmitted from the request component to the CA, laying a solid foundation for subsequent certificate generation and authentication.

Please refer to FIG. 1 , step S103, identity authentication and certificate signing request review: the certificate authority receives the certificate signing request sent by the requested component, verifies the identity of the requested component, and reviews the certificate signing request to determine whether the public key of the key pair of the requested component has been tampered with. If not, the requested component passes the verification, and the following step S104 may be executed. If yes, the requested component fails the verification, and the component is prohibited from joining the communication system, and the above step S102 may be executed;

When a certificate authority receives a certificate signing request (CSR) for a new component, it initiates a comprehensive identity verification process designed to ensure the authenticity of the requester. Identity verification can be manual, involving a human review of the identity documents or credentials provided by the new component, or it can be automated and completed through the system's built-in verification mechanisms. Automated verification may include checking the pre-shared key between the requested component and the certificate authority, verifying that the IP address of the requested component matches a known or authorized network address, and confirming that the hardware ID is consistent with the recorded device information. Once the identity of the requested component is verified, the certificate authority will conduct a detailed review of the CSR content to ensure the accuracy of the identification information contained therein, such as the component name, organization, and department, and use hash functions or digital signature technology to verify the integrity of the public key to ensure that it has not been tampered with during transmission. This continuous verification and review process is a key step in ensuring the security and reliability of the entire certificate issuance process.

Please refer to FIG. 1 , step S104 , generation of a digital certificate: the certificate authority uses the public key of the key pair of the requested component, combined with the identification information of the requested component, to create a digital certificate, and the certificate authority uses the private key to digitally sign the digital certificate;

After verifying the identity of the requested component and reviewing the CSR content, the certificate authority will enter the digital certificate creation phase. First, the certificate authority will build the basic framework of the certificate based on the public key in the CSR and the component's identification information, such as component name, organization, department, etc. Next, the certificate authority will set a clear validity period for the digital certificate, which is usually determined by the organization's security policy and the purpose of the certificate, and may be a few months, a year, or longer. Once all the parameters of the certificate are set, the certificate authority will use its own private key to digitally sign the newly created digital certificate. This signing process not only verifies the source of the certificate content and ensures the authenticity of the certificate, but also ensures the integrity of the certificate content during transmission and storage to prevent any unauthorized modification. In this way, the certificate authority ensures that the digital certificate of the new component is both safe and reliable, providing a solid trust foundation for inter-component communication in the port network security system.

Please refer to FIG. 1 , step S105 , certificate distribution: the certificate authority sends the signed digital certificate to the requesting component, and the requesting component installs the issued digital certificate;

The certificate authority sends the signed digital certificate to the verification (requesting) component. Once the requesting component receives the signed digital certificate, it needs to install and configure it to integrate the certificate into its own system environment. This usually includes importing the certificate into the component's certificate store and configuring related encryption communication software to ensure that the component can use the newly installed certificate for secure encryption communication.

Please refer to FIG. 1 , step S106, data transmission: determine whether the digital certificates carried by both components to be communicated are valid, if so, execute step S107 to communicate, if not, reject the communication, and then execute step S102.

When data is transmitted between components, the validity of the digital certificates of both parties is checked first. If valid, communication is allowed; if invalid, communication is rejected, thus ensuring the security of communication.

The system component communication method proposed in this application manages the key and digital certificate of the component by selecting a component as a certificate authority, which is responsible for issuing digital certificates and digital signatures for other components joining the system. Thereafter, communication within the system will require the use of digital certificates issued by the certificate authority, which ensures that only authenticated components can communicate with each other, thereby preventing unauthorized devices from joining the system, thereby preventing unauthorized access and data leakage. As the port network security system expands and upgrades, new components can be easily added and digital certificates can be generated and distributed for them without major modifications to the entire system.

Please refer to FIG. 2 . In this embodiment, in step S106 , when determining whether the digital certificates carried by both components to be communicated are valid, the following steps are also included:

Step S1061, exchanging digital certificates: the components to be communicated exchange their respective digital certificates;

During the secure session initialization phase, such as the Transport Layer Security (TLS) handshake process, the communicating parties perform a critical certificate exchange operation. During this process, each party presents its digital certificate to the other party, which includes not only its own public key, but also other important information in the certificate issued by the Certificate Authority (CA), such as the identification information of the certificate holder, the validity period of the certificate, the serial number of the certificate, the signature of the CA, and the purpose of the certificate. Through this exchange, both parties can verify the identity of the other party and ensure that the exchanged public keys are authentic. This process is the basis for establishing secure communication. It allows both parties to use the other party's public key for operations in subsequent communications, thereby ensuring the confidentiality and integrity of the data. This certificate-based mutual authentication mechanism not only improves the security of communication, but also provides support for the scalability and convenience of management of the system.

Please refer to FIG. 2 , step S1062 , verifying the certificate signature: obtaining the public key of the certificate authority from the trusted certificate repository, and using the public key to verify the signature of the other party's digital certificate;

Each party retrieves the public key of a known, trusted Certificate Authority (CA) from a trusted certificate repository. These public keys are pre-installed in the operating system or application and serve as trust anchors for the subsequent certificate verification process. Using these CA public keys, the communicating parties will verify the signature on the other party's digital certificate. This process involves decrypting the digital signature in the certificate using the CA's public key to confirm the validity of the signature. If the signature verification is successful, this not only proves that the certificate was issued by a trusted CA, but also that the certificate contents have not been tampered with or changed since the certificate was issued.

Please refer to Figure 2, step S1063, check the validity period of the certificate: determine whether the digital certificate of the component to be communicated is within the validity period. If so, the digital certificate is valid, and the corresponding components to be communicated can be used for communication, and execute step S1064 or S107. If not, the digital certificate is invalid, and the corresponding components to be communicated cannot be used for communication.

Each party checks the "Valid from" and "Valid to" fields in the certificate, which clearly indicate the validity range of the certificate. These date information is then compared with the current system date to verify that the certificate is still within its intended validity period. If the current system date is outside the range defined by the valid from and to dates of the certificate, the certificate is considered expired. Once a certificate is determined to be expired, it will no longer be suitable for any form of secure communication, because expired certificates may no longer be trusted by the certificate authority (CA) and may no longer meet current security standards. Therefore, this verification step is critical to preventing the use of outdated or invalid certificates for communication, which helps maintain the security of the entire communication process and the integrity of the data.

Please refer to Figure 3, step S1064, check the certificate revocation status: obtain the certificate revocation list of the certificate authority, and determine whether the digital certificate of the component to be communicated is in the certificate revocation list. If not, the digital certificate is valid, and the corresponding components to be communicated can be used for communication. Execute step S105 or S107. If so, the digital certificate is invalid, and the corresponding components to be communicated cannot be used for communication.

To further ensure the current status of the digital certificate, the communicating parties will access the Certificate Revocation List (CRL) published by the Certificate Authority (CA), which is a list of serial numbers of all revoked certificates. By comparing the serial number in the CRL with the serial number of the certificate to be verified, it can be determined whether the certificate has been revoked. If the serial number of the certificate to be verified appears in the CRL, it means that the certificate is no longer valid and cannot be used for secure communication.

To get faster revocation status updates, the communicating parties can also take advantage of the Online Certificate Status Protocol (OCSP). OCSP allows real-time queries to the OCSP server to get the latest revocation status of the certificate. Compared to CRL, OCSP can provide faster response speed because it allows instant updates and queries, while CRL usually needs to be updated regularly. By sending a query request to the OCSP server, the communicating parties can receive instant feedback on the current status of the certificate, including whether the certificate has been revoked or is still valid.

Step S1065, final verification: Once a series of verification steps for the digital certificate are completed, including signature verification, validity period check and revocation status query, the communicating parties will decide whether to continue encrypted communication based on the verification results. If the signature verification of the certificate is successful, it indicates that the certificate content has not been tampered with since it was issued, and the "valid start date" and "valid end date" fields of the certificate indicate that the certificate is within the validity period. At the same time, by accessing the certificate revocation list (CRL) or the online certificate status protocol (OCSP) to confirm that the certificate has not been revoked, then the certificate is deemed to have been verified, and the communicating parties can safely use the certificate for encrypted communication to ensure that the confidentiality and integrity of the data are protected.

On the contrary, if a problem is found in any verification step, such as a signature verification failure indicating that the certificate may have been tampered with, a certificate validity check showing that the certificate has expired, or CRL and OCSP query results showing that the certificate has been revoked, then the certificate verification will be considered a failure. In this case, the communicating parties should immediately terminate the communication process to prevent potential security risks. In addition, the system will take appropriate security measures, such as recording event logs for further analysis and auditing. If necessary, the system will also report these security events to the system administrator so that further actions can be taken, such as revoking relevant certificates, updating CRL or OCSP information, or strengthening security monitoring, etc., to maintain the security and stability of the entire system.

Please refer to FIG. 4 . In this embodiment, in step S107 , when communication is performed, the following steps are also included:

Step S1071, determine whether the sensitivity of the transmitted information is greater than a threshold, if so, execute step S1072: communicate using asymmetric encryption, if not, execute step S1073: communicate using symmetric encryption.

The encryption method used during data transmission will be determined based on the sensitivity of the information. In specific implementation, the system first defines a sensitivity threshold, which is used to distinguish the sensitivity level of information. When data needs to be transmitted, the system automatically evaluates the sensitivity of the data, which may be based on factors such as data type, data source, and data content.

The components in the system use an encrypted communication mode during the communication process to ensure the security and confidentiality of the exchanged information. Specifically, the system dynamically selects the encryption method according to the sensitivity level of the information: for information containing sensitive and private data, such as user account passwords, personal identity information and financial records, asymmetric encryption is used because asymmetric encryption provides stronger security. It uses a pair of public and private keys, where the public key is used to encrypt data and the private key is used to decrypt, ensuring that only the recipient with the private key can access the original data. For non-sensitive data, the system uses symmetric encryption, which uses the same key to encrypt and decrypt data. Compared with asymmetric encryption, symmetric encryption provides faster encryption speed and is suitable for processing large amounts of data. Based on the dynamic encryption method selection based on information sensitivity, the communication method of this patent not only improves the security of communication, but also optimizes the efficiency of the encryption process according to the characteristics of the data, achieving a balance between security and efficiency.

In this embodiment, careful classification of the data processed in the system is a key step to ensure data security. First, the data is divided into two categories: sensitive information and non-sensitive information. Sensitive information refers to data that may have a serious impact on individuals or organizations once leaked, including but not limited to personal identity information, financial records, account passwords, etc. This information is usually subject to strict privacy protection and security regulations, so a higher level of confidentiality, integrity and availability protection measures are required. Among them, for sensitive information, an existing public key infrastructure (PKI) is established or utilized to facilitate the secure distribution and management of public keys.

Relatively speaking, non-sensitive information refers to data that is publicly accessible or has low security requirements, such as some routine business information or publicly released data. Although the security requirements for this type of information are relatively low, it still needs to be properly managed and protected according to specific business needs and security policies. In order to ensure that each type of data is properly handled, the system will conduct a detailed security assessment for each type of data and establish the specific requirements for confidentiality, integrity, and availability. Confidentiality requires ensuring that sensitive information is not accessed or leaked without authorization; integrity requires ensuring that data is not tampered with or damaged during storage and transmission; availability requires ensuring that authorized users can access data when needed.

In this embodiment, the selected encryption method is implemented in the system. For symmetric encryption, ensure that the keys are securely stored and transmitted. For asymmetric encryption, ensure the wide availability of public keys and the strict confidentiality of private keys. The performance of the selected encryption algorithms is optimized to ensure that they do not negatively affect the response time of the system or the user experience. Key management is a core component to ensure the effective operation of the encryption system. A correct key management strategy can maximize the protection of data security. The keys of symmetric encryption must be kept confidential and only known to the two ends of the communication. Asymmetric encryption involves public keys and private keys. The public key can be made public, and the private key must be kept strictly confidential.

In this embodiment, in step S1072, when communication is performed in an asymmetric encryption manner, the following steps are also included:

A key pair is created through a random number generator, the certificate authority obtains the public key of the key pair, and the component encrypts, stores and backs up the private key of the key pair.

That is, the key management method for asymmetric encryption is:

First, the system creates a pair of keys, including a public key and a private key, through a secure random number generator. To ensure security, the length of the key pair must comply with the latest security standards. For example, for the RSA algorithm, a key length of at least 2048 bits is recommended. The distribution of the public key can be carried out through public channels, such as websites, emails, or public key infrastructure (PKI). At the same time, in order to verify the authenticity of the public key, it can be issued and certified by a digital signature or through a trusted certificate authority (CA). The private key must be stored in a highly secure environment, such as using a hardware security module (HSM) or an encrypted storage solution with strong password protection to prevent unauthorized access. To further strengthen the security of the private key, strict access control measures are implemented to ensure that only authorized users can access the private key. In addition, the private key needs to be securely backed up to prevent the loss or damage of the original private key. The backup private key must also be encrypted and stored in a secure location. In order to deal with the possible loss or damage of the private key, a secure key recovery process is designed and implemented to ensure that the private key can be recovered when needed. At the same time, the system is also responsible for monitoring and managing the entire life cycle of the key, including the key's creation, activation, deactivation and final destruction, to ensure that the key's life cycle is properly managed.

In this embodiment, in step S1073, when communicating in a symmetric encryption manner, the following steps are also included: First, the system uses a secure random number generator (RNG) to generate a strong key to ensure that the length of the generated key is at least 128 bits, meeting the latest security standards of algorithms such as AES. During the key distribution process, a secure channel or a securely exchanged temporary key is used to encrypt and transmit the key to prevent the key from being intercepted during the transmission process. In addition, a key distribution center (KDC) is used to handle the distribution of keys to ensure the security and efficiency of the distribution process. When storing keys locally, the system uses a hardware security module (HSM) or an encrypted database to protect the keys to prevent unauthorized access. At the same time, strict access control and multi-factor authentication mechanisms are implemented to ensure that only verified and authorized users can access the keys. In order to reduce the risk of key cracking, the system will regularly replace the keys and replace them immediately when any risk of key leakage occurs. For keys that are no longer used, the system ensures that they are securely destroyed to avoid any unauthorized recovery. Through these comprehensive measures, the communication method of this patent not only ensures the security of the key generation, distribution, storage and replacement process, but also further enhances the security of the entire communication system and its ability to resist potential threats through regular replacement and secure destruction mechanisms.

In this embodiment, the encryption process involves symmetric encryption and asymmetric encryption. In symmetric encryption, the sender and the receiver use the same key for encryption and decryption; in asymmetric encryption, a pair of public and private keys are used for encryption and decryption. The following describes the implementation steps of these two encryption methods in detail.

A. Implementation steps of symmetric encryption

The sender and receiver need to share a secret key in advance. This is usually done through a secure key exchange protocol such as Diffie-Hellman key exchange or using a secure physical medium (such as a USB drive). The sender encrypts the message using the shared key and a selected symmetric encryption algorithm (such as AES). This involves converting the text into ciphertext, ensuring that it cannot be read without the key. The sender sends the encrypted ciphertext to the receiver via a network or other communication method. After the receiver receives the ciphertext, it decrypts it using the same shared key and the same encryption algorithm. The decryption process restores the original plaintext message. The receiver verifies that the decrypted information is complete and correct before using it.

B. Implementation steps of asymmetric encryption

The receiver generates a pair of keys: a public key and a private key. The public key can be distributed publicly, while the private key must be kept safe and cannot be disclosed. The sender obtains the receiver's public key. This can be done through a public key infrastructure (PKI), a website, email, or other reliable means. The sender uses the receiver's public key to encrypt the message to be sent. This ensures that only the receiver with the matching private key can decrypt the message. The encrypted ciphertext is sent to the receiver via the network or other communication method. The receiver uses his or her own private key to decrypt the received ciphertext. The decryption process converts the ciphertext back to the original plaintext format. The receiver verifies that the decrypted information is complete and correct before using it.

Please refer to FIG. 5 . In this embodiment, in step S107 , when communication is performed, the following steps are also included:

Step S1071, determine whether the sensitivity of the transmitted information is greater than a threshold. If so, execute step S1074, encrypt the information with a sensitivity greater than the threshold and store it on the server.

For such sensitive information, the system will automatically trigger the encryption process to encrypt the information using an appropriate encryption algorithm (such as AES, RSA, etc.). The encrypted information is then securely stored on the server. The storage process may involve using secure file transfer protocols, as well as ensuring that the server has the necessary security measures, such as firewalls, intrusion detection systems, etc., to protect the stored data from unauthorized access.

Please refer to FIG. 6 . In this embodiment, in step S1074, when the information with a sensitivity greater than a threshold is encrypted and stored on the server, the following steps are also included:

Step S10741, the Trusted Platform Module (TPM) generates an encryption key, and encrypts the information with a sensitivity greater than a threshold value using the encryption key generated by the Trusted Platform Module;

Step S10742: The trusted platform module encrypts information with a sensitivity greater than a threshold using a strong encryption algorithm such as AES or RSA. The key should be stored separately from the encrypted data to reduce the risk of being leaked at the same time.

Step S10743, the trusted platform module stores information with a sensitivity greater than a threshold on the server and periodically changes the encryption key.

First, in the key generation phase, the system uses a high-quality random number generator and combines hardware-specific information to generate a unique key, which not only ensures the uniqueness of the key, but also enhances the unpredictability of the key. In addition, the system also uses the hardware's Trusted Platform Module (TPM) to generate and store encryption keys. TPM provides a secure hardware environment for secure key generation and storage, further enhancing the security of the entire encryption process.

In terms of data encryption storage, all sensitive data, such as account passwords, must be encrypted before storage. The system uses strong encryption algorithms, such as AES or RSA, to encrypt data. To further reduce security risks, keys and encrypted data are stored separately to avoid the possibility of keys and data being leaked together.

Finally, in terms of security policy enforcement, the system implements a mechanism for regularly updating keys, which helps reduce the risk of key cracking. At the same time, the system also implements a strict access control policy to ensure that only authorized users can access sensitive data.

In this embodiment, the modality of the transmitted data includes one or more of text, image, video, and audio. Each modality corresponds to a unique identifier, which defines the format specification of each modality transmission. At the same time, other customized data types can be expanded according to actual needs. Each data type has a unique identifier so that it can be correctly identified and processed during transmission. The operator can customize various multimodal data types to meet the needs of different application scenarios.

In this embodiment, each modality is packaged into a unified data packet according to the format specification defined by each modality. Various data types are packaged into a unified data packet, and the data packet includes fields such as data type identification, data length, and data content, so that the receiving end can correctly parse the data. When data is packaged, the data is packaged in a prescribed format according to the definition of the data type.

For text data, the character string is directly packaged as the data content; for binary data such as images, audio and video, it is converted into a byte stream and information such as the data type identifier and data length is added so that the receiving end can parse it correctly.

The structure of the packet is designed as follows: During the packaging process, each data packet has fields such as data type identification, data length and data content. The data type identification is used to indicate the type of data so that the receiving end can correctly parse the data; the data length field is used to indicate the length of the data content so that the receiving end can correctly read the data; the data content field stores the actual data content.

In this embodiment, the communicating parties transmit data packets. For example, the transmitting end encrypts and transmits the data packet through the AES symmetric encryption algorithm, and the receiving end receives and decrypts the data packet. Among them, the modalities of the data packet include text and image, the encrypted text data is AES_Encrypt (plaintext_text, key), and the encrypted image data = AES_Encrypt (plaintext_image, key), wherein plaintext_text and plaintext_image represent the original unencrypted data of the text data and image data respectively, and key represents the key used for encryption.

In this embodiment, before the sending end sends a data packet, a hash value is calculated for the data of each modality and the hash value is attached to the data packet. After the receiving end receives the data, the hash value is recalculated and compared with the hash value in the data packet. If the recalculated hash value is the same as the hash value in the data packet, it indicates that the data has not been tampered with, thereby ensuring the integrity of the data.

For example, suppose there are two modal data, text data and image data, and the data packet of the text data with a hash value is:

data_type:text,data_length:20,data_content:"Hello, MDTP!",

The packet of image data with hash value attached is:

data_type:image,data_length:1024,data_content:<binary_image_data>.

In this embodiment, the video signal server communicates with the programmable logic controller (PLC) of each port machine, and the communication protocol adopted is ModbusRTU. The video signal server and the programmable logic controller have a data interface table, and both parties transmit data according to the registers defined in this data interface table. The video signal server sends a data request to the programmable logic controller at an acquisition frequency of 5 times per second, and the programmable logic controller sends data to the preset register after receiving the request. After the video signal server reads the key information of each port machine from each programmable logic controller, it converts and encrypts part of the information and puts it into the server's buffer queue. In the communication queue corresponding to the console, it finds the IP address and port number of the video host of the corresponding console, and samples the UDP communication mode and sends it to the video host of each console.

The above technical solution has the following beneficial effects:

Through a series of steps such as data type definition, data packaging, data transmission and verification, this method ensures the security of data transmission in the complex environment of the port. In particular, in the signature authentication link, it effectively prevents data from being tampered with or stolen during transmission, thereby ensuring the information security of port operations.

By optimizing the data transmission protocol and transmission method, the efficiency and stability of data transmission are improved. This enables port operations to be carried out more efficiently, reduces operation delays or interruptions caused by data transmission problems, and thus improves the overall operational efficiency of the port.

The application of this data transmission method provides strong technical support for the information development of ports. By improving the security and efficiency of data transmission, it promotes the progress of port information construction and provides important guarantees for the modern management of ports.

Before components communicate with each other, authentication is required to ensure that the source of data communication is reliable. Authentication uses digital signatures, and data communication uses encryption, which uses symmetric encryption or asymmetric encryption. The main components also use digital signature authentication, and the data involved is also encrypted.

This embodiment further provides a storage medium, wherein the storage medium stores a computer program, and when the computer program is executed, the system component communication method applied to port network security described in any one of the above embodiments is executed.

It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that the process, method, article or terminal device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or terminal device. In the absence of further restrictions, the elements defined by the statement "include..." or "comprise..." do not exclude the existence of other elements in the process, method, article or terminal device including the elements. In addition, in this article, "greater than", "less than", "exceed" and the like are understood to exclude the number itself; "above", "below", "within" and the like are understood to include the number itself.

Although the above embodiments have been described, once those skilled in the art know the basic creative concepts, they can make additional changes and modifications to these embodiments. Therefore, the above description is only an embodiment of the present invention and does not limit the patent protection scope of the present invention. Any equivalent structure or equivalent process transformation made by using the contents of the specification and drawings of the present invention, or directly or indirectly used in other related technical fields, are also included in the patent protection scope of the present invention.

Claims (10)

1. A system component communication method applied to port network security, comprising the steps of:

Establishment of certificate authority: the components comprise a port machine PLC, a video signal server, a video host and a console, and one of the components is selected as a certificate authority;

Creation and submission of certificate signing requests: the requesting components generate respective key pairs, each requesting component creates a certificate signing request by using the private key of the respective key pair and sends the certificate signing request to a certificate authority, and the certificate signing contains the public key of the key pair of the component and the identification information of the component;

Authentication and review of certificate signing requests: the certificate authority receives a certificate signing request sent by a requested component, verifies the identity of the requested component, examines the certificate signing request, judges whether the public key of the requested component key pair is tampered, and if not, the requested component passes the verification;

Generation of a certificate: the certificate authority uses the public key of the requested component key pair, and creates a digital certificate in combination with the identification information of the requested component, and the certificate authority uses the private key to digitally sign the digital certificate;

Distribution of certificates: the certificate authority transmits the signed digital certificate to the requested component, and the requested component installs the issued digital certificate;

And (3) data transmission: and judging whether the digital certificates carried by the two parts of the components to be communicated are valid or not, if so, carrying out communication, and if not, refusing the communication.

2. The communication method according to claim 1, wherein when "determining whether the digital certificate carried by both the components to be communicated is valid", further comprising the steps of:

Exchanging digital certificates: the two parties of the components to be communicated exchange respective digital certificates;

verifying certificate signature: obtaining a public key of a certificate authority from a trusted certificate repository, and verifying the signature of the digital certificate of the opposite party by using the public key;

Checking the certificate validity period: and judging whether the digital certificate of the component to be communicated is in the validity period, if so, the digital certificate is valid, both corresponding components to be communicated can be used for communication, and if not, the digital certificate is invalid, and both corresponding components to be communicated cannot be used for communication.

3. The communication method according to claim 2, characterized by further comprising, after said "check certificate validity period", the steps of:

Checking certificate revocation status: acquiring a certificate revocation list of a certificate authority, judging whether a digital certificate of a component to be communicated is in the certificate revocation list, if not, enabling the digital certificate to be valid, enabling two corresponding components to be communicated to be used for communication, and if so, enabling the digital certificate to be invalid, and enabling the two corresponding components to be communicated to be unavailable for communication.

4. The communication method according to claim 1, characterized in that at the time of the "data transmission", further comprising the steps of:

Judging whether the sensitivity of the transmitted information is greater than a threshold value, if so, adopting an asymmetric encryption mode for communication, and if not, adopting a symmetric encryption mode for communication.

5. The communication method of claim 4, wherein the information with sensitivity greater than the threshold includes a user account password, personal identification information, and a financial record.

6. The communication method according to claim 4, characterized in that, in the "communication in an asymmetric encryption manner", the communication method according to claim 4 further comprises the steps of:

The key pair is created by a random number generator, the public key of the key pair is acquired by a certificate authority, and the private key of the key pair is stored and backed up by a component in an encrypted mode.

7. The communication method according to claim 4, further comprising the step of:

Judging whether the sensitivity of the transmitted information is greater than a threshold value, if so, encrypting and storing the information with the sensitivity greater than the threshold value on a server.

8. The communication method according to claim 7, wherein when the "information having a sensitivity greater than the threshold is encrypted and stored on the server", further comprising the steps of:

The trusted platform module generates an encryption key, encrypts the information with sensitivity greater than the threshold value through the encryption key generated by the trusted platform module, and stores the information on the server.

9. The communication method according to claim 8, further comprising the step of:

the trusted platform module periodically replaces the encryption key.

10. A storage medium storing a computer program which, when executed, performs the system component communication method for port network security according to any one of claims 1 to 9.