Security control method for realizing OTA upgrade of vehicle-mounted satellite communication terminal software through TBOX

Abstract

The invention provides a security control method for realizing OTA upgrade of vehicle-mounted satellite communication terminal software through TBOX. The security control method comprises the following steps: S1, security generation and encryption packaging of a cloud upgrade package; s2, performing bidirectional authentication on the TBOX and the cloud and establishing an encrypted communication channel; s3, the TBOX performs multiple security verification on the cloud upgrade package; s4, carrying out vehicle-mounted bus safety transmission between the TBOX and the SBOX; s5, the upgrading process is monitored in real time, and abnormal emergency processing is carried out; s6, final safety confirmation and auditing are carried out; according to the method, the Hash value of the package body is calculated by using the high-strength Hash algorithm, and the digital signature is generated in combination with asymmetric encryption, so that the integrity and security of the upgrade package are remarkably improved, and the risks of tampering attacks and forging the upgrade package are prevented; through the bidirectional authentication process of the TBOX and the cloud, the legality of the source of the upgrade package is ensured, and the access of malicious equipment is prevented.

Description

Technical Field

[0001] This invention relates to the field of vehicle networking technology, and in particular to a security control method for OTA software upgrades of vehicle-mounted satellite communication terminals via TBOX. Background Technology

[0002] With the rapid development of vehicle-to-everything (V2X) technology, the vehicle-mounted satellite communication terminal (SBOX) is the core device for vehicles to communicate remotely with the outside world. It undertakes key functions such as vehicle positioning, emergency communication, and data transmission. The stability and security of its system software are directly related to vehicle driving safety and user information security. In order to meet the needs of function iteration, vulnerability repair and performance optimization, the vehicle-mounted satellite communication terminal (SBOX) needs to support remote OTA upgrades. As the hub for interaction between the vehicle and the cloud, the TBOX (Telematics Module Box) is responsible for receiving cloud commands, managing vehicle device communication and data forwarding. It is often used as an intermediate node for SBOX OTA upgrades. The cloud sends the upgrade package to the TBOX, which then forwards it to the SBOX and controls the upgrade process. Because the SBOX involves satellite communication encryption protocols and sensitive vehicle data interaction, the OTA upgrade process faces multiple security risks, including upgrade package tampering, transmission link hijacking, and unauthorized upgrade attacks. Therefore, the TBOX needs to build a reliable security control mechanism to ensure the integrity, confidentiality, and legality of the SBOX upgrade process. The existing methods for OTA software upgrades of vehicle-mounted satellite communication terminals via TBOX have the following drawbacks: The upgrade package verification mechanism is weak: the existing technology only uses simple verification (such as CRC) to verify the integrity of the upgrade package, which cannot resist professional tampering attacks; the source of the upgrade package is not strictly verified, which may lead to malicious third parties forging upgrade packages and sending them to SBOX through TBOX, causing software abnormalities or functional failures. Insufficient encryption of transmission links: Communication between TBOX and SBOX relies heavily on vehicle bus (such as CAN), and the encryption strength of this link in the current technology is insufficient; at the same time, the interaction between TBOX and the cloud does not use a two-way authenticated encrypted channel (such as TLS two-way authentication), which is vulnerable to man-in-the-middle attacks, leading to the leakage of upgrade instructions or packet bodies. Summary of the Invention

[0003] The purpose of this invention is to address the shortcomings of existing technologies by proposing a secure control method for OTA software upgrades of vehicle-mounted satellite communication terminals via TBOX.

[0004] To achieve the above objectives, the present invention adopts the following technical solution: The method for secure control of OTA software upgrades for vehicle-mounted satellite communication terminals via TBOX includes the following steps: S1: Secure generation and encrypted encapsulation of cloud-based upgrade packages; S11: Generate differential upgrade package; Based on SBOX's software iteration requirements, cloud-based technical personnel compiled and generated differential upgrade packages. A high-strength hash algorithm is used to perform hash calculations on the generated differential upgrade package to obtain a unique package body hash value; S12: Encrypt the differential upgrade package; The cloud retrieves a dedicated private key from the Key Management System (KMS), uses the private key to perform asymmetric encryption on the packet body hash value using an asymmetric algorithm, and generates a digital signature; the digital signature is then bound to the differential upgrade package to obtain the signed differential upgrade package to be encrypted. A one-time symmetric encryption key (such as an AES key) is randomly generated in the cloud. The symmetric encryption key is used to perform overall symmetric encryption on the signed differential upgrade package to be encrypted, resulting in the encrypted differential upgrade package. The one-time symmetric encryption key is asymmetrically encrypted using the TBOX device public key stored in the cloud to generate an encrypted temporary key. The cloud generates basic information for the differential upgrade package according to a preset format. The basic information for the differential upgrade package includes a unique identifier, validity period, version number, etc. The encrypted differential upgrade package, the encrypted temporary key, the basic information of the differential upgrade package, and the package body hash value are integrated into a final cloud upgrade package and then encapsulated.

[0005] Furthermore, a high-strength hash algorithm is used to perform hash calculations on the cloud upgrade package, and the resulting hash value is the baseline overall hash value of the upgrade package and stored in the cloud.

[0006] S2: TBOX performs two-way authentication with the cloud and establishes an encrypted communication channel; S21: TBOX initiates an authentication request; TBOX extracts a pre-installed device certificate from its local secure storage unit and encapsulates it into an authentication request message, which is then sent to the cloud via a cellular network (such as 4G / 5G). The device certificate contains information such as the TBOX's unique identifier, public key, certificate validity period, certificate status, and CA digital signature. The cloud receives the authentication request message and verifies the validity of the device certificate. If the verification passes, proceed to step S22; otherwise, the cloud generates a verification failure reminder. This includes basic validity verification, signature validity verification, and device association verification; S22: Cloud feedback and completion of two-way authentication; The cloud retrieves the cloud server certificate from the security key management system (KMS), encapsulates it into an authentication response message, and sends it to TBOX. The authentication response message includes a cloud server certificate and a random challenge value, wherein the random challenge value is a randomly generated string; The cloud server certificate contains information such as validity period, cloud certificate signature, and cloud server identifier; TBOX receives and verifies the cloud server certificate; after successful verification, TBOX uses its own device private key to encrypt the random challenge value, generates a challenge response value, and sends it back to the cloud. After receiving the data, the cloud uses the public key in the TBOX's device certificate to decrypt the challenge response value. If the decryption result matches the random challenge value, the TBOX currently interacting with is determined to be a legitimate device. S23: Generate a key and establish a secure channel; After successful two-way authentication, TBOX and the cloud initiate the ECDH key negotiation process to generate a session key known only to the two parties and establish an encrypted communication channel.

[0007] S3: TBOX performs multiple security checks on cloud upgrade packages; The cloud transmits the cloud upgrade package to TBOX through an encrypted communication channel. TBOX receives the cloud upgrade package and verifies it. S31: Verify the basic information of the differential upgrade package; The TBOX reads the version number from the basic information of the differential upgrade package and compares it with the current version number corresponding to this SBOX recorded by the TBOX to determine whether it conforms to the upgrade logic, which includes allowing only higher versions to overwrite lower versions; if it does not conform, the verification fails. If they match, the unique identifier in the basic information of the differential upgrade package is extracted and compared with the unique identifier of the associated SBOX in the local storage of the TBOX. If they do not match, the verification fails. If they match, extract the expiration date from the basic information of the differential upgrade package and compare it with the current system time of TBOX. If the expiration date has expired, the upgrade package is determined to be invalid, the process is terminated and feedback is sent to the cloud; otherwise, proceed to step S32. S32: Perform supplementary integrity verification; TBOX uses a high-strength hash algorithm to calculate the local overall hash value of the entire cloud upgrade package and generates an upgrade task ID. The local overall hash value and the upgrade task ID are sent to the cloud through an encrypted communication channel. The cloud compares the local overall hash value with the base overall hash value of the upgrade package. If the two are consistent, the integrity verification passes and proceeds to step S33; otherwise, the verification fails. S33: Verify the digital signature; TBOX disassembles the components of the cloud upgrade package according to a preset format, retrieves the TBOX device private key from the local pre-set secure storage, performs asymmetric decryption on the encrypted temporary key to obtain a one-time symmetric encryption key; and uses the symmetric encryption key to decrypt the encrypted differential upgrade package to obtain a signed differential upgrade package. The cloud public key is retrieved from the local pre-configured secure storage. The cloud public key is used to perform asymmetric decryption on the digital signature in the differential upgrade package to obtain the package body hash value. TBOX uses the same high-strength hash algorithm to recalculate the hash value of the decrypted differential upgrade package to obtain the locally calculated hash value. If the locally calculated hash value is consistent with the package body hash value, it indicates that the encrypted differential upgrade package has not been tampered with during transmission, and the process proceeds to step S4. If they are inconsistent, the process is terminated and a signature verification failure is reported to the cloud.

[0008] S4: Perform secure transmission of the vehicle bus between TBOX and SBOX; Based on the communication characteristics of the vehicle bus, TBOX uses a bus-level encryption protocol to encrypt the signed differential upgrade package in real time to obtain the transmitted data. It adds a verification field (such as a message authentication code) to the transmitted data, encapsulates the transmitted data into a data frame, and sends it to SBOX through the vehicle bus. SBOX receives data frames transmitted from the vehicle bus, decrypts the data frames using a preset bus decryption key, and obtains a differential upgrade package with a digital signature. SBOX uses a locally preset cloud public key to verify the digital signature in the upgrade package. If the verification is successful, the source of the differential upgrade package with a digital signature is determined to be legitimate. SBOX then stores the differential upgrade package with a digital signature and prepares to enter the upgrade process. If the verification fails, reception is terminated and an exception is reported to TBOX.

[0009] The upgrade package is encrypted in real time using a bus-level encryption protocol, and a verification field is added to prevent data from being stolen or tampered with during transmission on the vehicle bus.

[0010] S5: Monitor the upgrade process in real time and handle any emergencies. Upgrades are performed using differential upgrade packages. TBOX and SBOX establish a real-time heartbeat interaction mechanism, with SBOX providing feedback on the upgrade progress of the differential upgrade package to TBOX at preset intervals. TBOX synchronously records the time of key nodes, forming a complete status log; When an anomaly is detected, the TBOX triggers an anomaly alarm and sends a rollback command to the SBOX. After receiving the rollback command, the SBOX stops the current upgrade process and performs the rollback operation. The abnormal situations include heartbeat interruption exceeding a preset duration, progress stopping exceeding a preset time threshold, upgrade errors (such as write failure, version incompatibility, etc.), and related function initialization failure after SBOX restart; During the rollback process, SBOX reports the rollback progress to TBOX at preset intervals, and TBOX records the rollback log; TBOX simultaneously reports the exception log, on-site data and rollback results to the cloud, awaiting further instructions; S6: Conduct final security verification and audit; After the SBOX completes the upgrade, it generates a result message containing the new version number and an upgrade success identifier, and sends it to the TBOX through an encrypted communication channel. After the TBOX verifies the authenticity of the message, it compares whether the current version of the SBOX is consistent with the target version, and checks whether the core functions of the SBOX are normal, thus confirming that the upgrade is effective. TBOX integrates and upgrades the entire process log, including authentication records, verification results, progress data, rollback command execution logs, etc., and generates audit reports in a preset format.

[0011] Compared with the prior art, the beneficial effects of the present invention are as follows: This method significantly improves the integrity and security of the upgrade package by using a high-strength hash algorithm to calculate the hash value of the package body and combining it with asymmetric encryption to generate a digital signature, preventing the risk of tampering attacks and forgery of the upgrade package; the two-way authentication process between TBOX and the cloud ensures the legitimacy of the upgrade package's source and prevents the access of malicious devices; and the verification of the matching between the device's unique identifier and the vehicle's VIN code further enhances security. By employing a two-way authenticated encrypted channel and ECDH key negotiation, the communication between TBOX and the cloud is ensured to be protected from man-in-the-middle attacks and tampering during transmission, effectively safeguarding the confidentiality and integrity of the upgrade package content. Attached Figure Description

[0012] Figure 1 This is a flowchart illustrating the steps of the security control method for OTA software upgrade of vehicle-mounted satellite communication terminal using TBOX according to the present invention. Detailed Implementation

[0013] To provide a further understanding of the purpose, structure, features, and functions of the present invention, detailed descriptions are provided below with reference to specific embodiments.

[0014] like Figure 1 As shown, the security control method for OTA software upgrade of vehicle-mounted satellite communication terminal through TBOX includes the following steps: S1: Secure generation and encrypted encapsulation of cloud-based upgrade packages; S11: Generate differential upgrade package; Based on SBOX's software iteration requirements (such as adding new features, fixing vulnerabilities, etc.), cloud-based technical personnel compile and generate differential upgrade packages; the differential upgrade packages contain executable code, configuration files, dependent components, and other files required for runtime. The generated differential upgrade package is hashed using a high-strength hash algorithm (such as SHA-256, SM3 algorithm, etc.) to obtain the package body hash value of the differential upgrade package. The package body hash value is unique. S12: Encrypt the differential upgrade package; The cloud retrieves a dedicated private key from the security key management system (KMS), uses the private key to perform asymmetric encryption on the packet body hash value using an asymmetric algorithm (such as RSA-2048 or ECC-256), and generates a digital signature; the digital signature is then bound to the differential upgrade package to obtain the signed differential upgrade package to be encrypted. A one-time symmetric encryption key (such as an AES key) is randomly generated in the cloud. The symmetric encryption key is used to perform overall symmetric encryption on the signed differential upgrade package to be encrypted, resulting in the encrypted differential upgrade package. The one-time symmetric encryption key is asymmetrically encrypted using the TBOX device public key stored in the cloud to generate an encrypted temporary key. The cloud generates basic information for the differential upgrade package according to a preset format. The basic information for the differential upgrade package includes a unique identifier, validity period, version number, etc. The encrypted differential upgrade package, the encrypted temporary key, the basic information of the differential upgrade package, and the package body hash value are integrated into a final cloud upgrade package and then encapsulated.

[0015] Furthermore, a high-strength hash algorithm is used to perform hash calculations on the cloud upgrade package, and the resulting hash value is the baseline overall hash value of the upgrade package and stored in the cloud.

[0016] The upgrade package is hashed using high-strength hash algorithms such as SHA-256 and the national cryptographic SM3 algorithm to generate a unique package body hash value, ensuring that the package body data is not tampered with during the upgrade process; the hash value of the upgrade package is encrypted using the RSA-2048 or ECC-256 algorithm to generate a digital signature, ensuring that the upgrade package comes from a legitimate source and preventing malicious third parties from forging the upgrade package.

[0017] S2: TBOX performs two-way authentication with the cloud and establishes an encrypted communication channel; S21: TBOX initiates an authentication request; TBOX extracts a pre-installed device certificate from a local secure storage unit (such as an embedded security chip eSE) and encapsulates it into an authentication request message, which is then sent to the cloud via a cellular network (such as 4G / 5G). The device certificate contains information such as the TBOX's unique identifier, public key, certificate validity period, certificate status, and CA digital signature. The cloud receives the authentication request message and verifies the validity of the device certificate. If the verification passes, proceed to step S22; otherwise, the cloud generates a verification failure reminder. This includes basic validity verification, signature validity verification, and device association verification; Specifically, the basic validity check involves the cloud checking whether the device certificate is within its validity period and verifying whether the device certificate is not revoked by querying the Certificate Revocation List (CR) of the Certificate Authority, i.e., whether the certificate status is "normal". If the device certificate is within its validity period and the certificate status is "normal", the basic validity check passes. Signature validity verification: Use the public key of the CA authority pre-installed in the cloud to decrypt the CA digital signature in the device certificate and obtain the hash value of the device certificate; at the same time, the cloud recalculates the hash value of the device certificate and compares whether the two hash values ​​are consistent. If they are consistent, the signature validity verification passes. Device association verification: If the unique identifier of the TBOX has been registered in the cloud, that is, the vehicle VIN code associated with this unique identifier of the TBOX exists in the cloud, and the vehicle status corresponding to the vehicle VIN code meets the upgrade prerequisites (such as not driving), then the device association verification passes. S22: Cloud feedback and completion of two-way authentication; The cloud retrieves the cloud server certificate from the security key management system (KMS), encapsulates it into an authentication response message, and sends it to TBOX. The authentication response message includes a cloud server certificate and a random challenge value, wherein the random challenge value is a randomly generated string; The cloud server certificate contains information such as validity period, cloud certificate signature, and cloud server identifier; TBOX receives and verifies the cloud server certificate; after successful verification, TBOX uses its own device private key to encrypt the random challenge value, generates a challenge response value, and sends it back to the cloud. After receiving the data, the cloud uses the public key in the TBOX's device certificate to decrypt the challenge response value. If the decryption result matches the random challenge value, the TBOX currently interacting with is determined to be a legitimate device. The specific verification method is as follows: Verify that the cloud server certificate is within its validity period to ensure that it has not expired; use the CA's public key to decrypt the cloud certificate signature and obtain the hash value. At the same time, TBOX recalculates the hash value of the cloud server certificate, and confirms the authenticity of the cloud server certificate by comparing the two hash values; extract the cloud server identifier from the cloud server certificate and check whether it matches the pre-set legitimate cloud address in TBOX to avoid connecting to a fake cloud server. S23: Generate a key and establish a secure channel; After mutual authentication is successful, TBOX and the cloud initiate the ECDH key negotiation process to generate a session key known only to the two parties. Specifically, TBOX generates a pair of temporary ECDH keys, including a temporary public key and a temporary private key, sends the temporary public key to the cloud, and the cloud synchronously generates its own temporary ECDH key pair and sends the temporary public key from the cloud back to TBOX; The original session key is obtained by using the ECDH algorithm based on the TBOX's own temporary private key and the cloud's temporary public key. The same original session key is also obtained by using the ECDH algorithm based on the cloud's own temporary private key and the TBOX's temporary public key. TBOX and the cloud respectively use key derivation functions combined with information such as random challenge values ​​to derive the original session key, thus obtaining the final TLS session key; TBOX and the cloud use TLS session keys to enable TLS-related protocols to build an encrypted communication channel.

[0018] Through multiple authentication mechanisms such as device certificate verification, CA digital signature verification, and device association verification, the TBOX ensures that the communication between the TBOX and the cloud is legitimate, preventing man-in-the-middle attacks and forgery of cloud servers. During the two-way authentication process, challenge value and private key encryption technology are used to further verify the identities of the communicating parties and avoid forgery or tampering attacks.

[0019] S3: TBOX performs multiple security checks on cloud upgrade packages; The cloud transmits the cloud upgrade package to TBOX through an encrypted communication channel. TBOX receives the cloud upgrade package and verifies it. S31: Verify the basic information of the differential upgrade package; The TBOX reads the version number from the basic information of the differential upgrade package and compares it with the current version number corresponding to this SBOX recorded by the TBOX to determine whether it conforms to the upgrade logic, which includes allowing only higher versions to overwrite lower versions; if it does not conform, the verification fails. If they match, the unique identifier in the basic information of the differential upgrade package is extracted and compared with the unique identifier of the associated SBOX in the local storage of the TBOX. If they do not match, the verification fails. If they match, extract the expiration date from the basic information of the differential upgrade package and compare it with the current system time of TBOX. If the expiration date has expired, the upgrade package is determined to be invalid, the process is terminated and feedback is sent to the cloud; otherwise, proceed to step S32. S32: Perform supplementary integrity verification; TBOX uses a high-strength hash algorithm to calculate the local overall hash value of the entire cloud upgrade package and generates an upgrade task ID. The local overall hash value and the upgrade task ID are sent to the cloud through an encrypted communication channel. The cloud compares the local overall hash value with the base overall hash value of the upgrade package. If the two are consistent, the integrity verification passes and proceeds to step S33; otherwise, the verification fails. S33: Verify the digital signature; TBOX disassembles the components of the cloud upgrade package according to a preset format, retrieves the TBOX device private key from the local pre-set secure storage, performs asymmetric decryption on the encrypted temporary key to obtain a one-time symmetric encryption key; and uses the symmetric encryption key to decrypt the encrypted differential upgrade package to obtain a signed differential upgrade package. The cloud public key is retrieved from the local pre-configured secure storage. The cloud public key is used to perform asymmetric decryption on the digital signature in the differential upgrade package to obtain the package body hash value. TBOX uses the same high-strength hash algorithm to recalculate the hash value of the decrypted differential upgrade package to obtain the locally calculated hash value. If the locally calculated hash value is consistent with the package body hash value, it indicates that the encrypted differential upgrade package has not been tampered with during transmission, and the process proceeds to step S4. If they are inconsistent, the process is terminated and a signature verification failure is reported to the cloud.

[0020] A session key is generated through ECDH key negotiation, and a TLS encrypted channel is enabled based on this key to achieve secure transmission between the TBOX and the cloud, preventing the leakage or tampering of communication content. A bus-level encryption protocol is used to ensure the security of transmission between the TBOX and SBOX, while data is encrypted and its integrity is verified in real time to ensure that data transmission in the vehicle bus is not threatened.

[0021] S4: Perform secure transmission of the vehicle bus between TBOX and SBOX; Based on the communication characteristics of the vehicle bus, TBOX uses a bus-level encryption protocol to encrypt the signed differential upgrade package in real time to obtain the transmitted data. It adds a verification field (such as a message authentication code) to the transmitted data, encapsulates the transmitted data into a data frame, and sends it to SBOX through the vehicle bus. SBOX receives data frames transmitted from the vehicle bus, decrypts the data frames using a preset bus decryption key, and obtains a differential upgrade package with a digital signature. SBOX uses a locally preset cloud public key to verify the digital signature in the upgrade package. If the verification is successful, the source of the differential upgrade package with a digital signature is determined to be legitimate. SBOX then stores the differential upgrade package with a digital signature and prepares to enter the upgrade process. If the verification fails, reception is terminated and an exception is reported to TBOX.

[0022] After receiving the upgrade package from the cloud, TBOX compares the recalculated hash value with the hash value of the package body to confirm whether the upgrade package has been tampered with or damaged, ensuring that no data is lost during transmission. When verifying the upgrade package, in addition to checking the digital signature, TBOX also verifies the version number and validity period to ensure that the upgrade package conforms to the upgrade logic and conditions, preventing low-version upgrades from overwriting high-version upgrades or expired upgrade packages from being used.

[0023] S5: Monitor the upgrade process in real time and handle any emergencies. Upgrades are performed using differential upgrade packages. TBOX and SBOX establish a real-time heartbeat interaction mechanism. SBOX provides feedback to TBOX on the upgrade progress of the differential upgrade package at preset intervals (e.g., every 10 seconds) (e.g., "Package parsing in progress / Writing progress 30% / Rebooting"). TBOX synchronously records key node times (such as "start receiving time / verification pass time / upgrade start time"), forming a complete status log; When an anomaly is detected, the TBOX triggers an anomaly alarm and sends a rollback command to the SBOX. After receiving the rollback command, the SBOX stops the current upgrade process and performs the rollback operation. The abnormal situations include heartbeat interruption exceeding a preset duration, progress stopping exceeding a preset time threshold, upgrade errors (such as write failure, version incompatibility, etc.), and related function initialization failure after SBOX restart; During the rollback process, SBOX reports the rollback progress to TBOX at preset intervals, and TBOX records the rollback log; TBOX simultaneously reports the exception log, on-site data and rollback results to the cloud, awaiting further instructions; TBOX and SBOX monitor each other in real time through a heartbeat interaction mechanism to ensure the continuity and stability of the upgrade progress. If the progress stalls or anomalies occur, TBOX will promptly trigger an alarm and perform a rollback to prevent unexpected situations from occurring during the upgrade process. If any anomalies occur during the upgrade process, TBOX can promptly record and report the anomaly information to facilitate cloud analysis and the implementation of countermeasures.

[0024] S6: Conduct final security verification and audit; After the SBOX completes the upgrade, it generates a result message containing the new version number and an upgrade success identifier, and sends it to the TBOX through an encrypted communication channel. After verifying the authenticity of the message, the TBOX compares the current version of the SBOX with the target version to see if they are consistent, and checks whether the core functions of the SBOX (such as satellite communication connection and data transmission) are normal, thus confirming that the upgrade is effective. TBOX integrates and upgrades the entire process log, including authentication records, verification results, progress data, rollback command execution logs, etc., and generates an audit report in a preset format. After receiving the report, the cloud verifies the audit report. Once the verification is successful, the cloud archives the upgrade results, audit report, TBOX current version and other information to the security database.

[0025] By recording the entire authentication, verification, and upgrade progress process, the audit report generated by TBOX provides detailed evidence for subsequent security checks, ensuring the transparency and traceability of software upgrades. After receiving the TBOX audit report, the cloud can verify the legality of the upgrade process and archive the information, enhancing system security management and compliance. RSA asymmetric encryption is used to protect the temporary key, and communication between TBOX and SBOX is also protected by encryption keys, preventing malicious man-in-the-middle attacks from stealing upgrade packages or tampering with data.

[0026] The present invention has been described in the above-described embodiments; however, these embodiments are merely examples for implementing the present invention. It must be noted that the disclosed embodiments do not limit the scope of the present invention. Conversely, any modifications and refinements made without departing from the spirit and scope of the present invention are within the scope of patent protection of the present invention.

Claims

1. A security control method for OTA software upgrade of vehicle-mounted satellite communication terminal via TBOX, characterized in that: Includes the following steps: S1: Secure generation and encrypted encapsulation of cloud-based upgrade packages; S11: Generate differential upgrade package; Cloud-based technicians compile and generate differential upgrade packages for the target version based on SBOX's software iteration requirements; S12: Encrypt the differential upgrade package; S2: TBOX performs two-way authentication with the cloud and establishes an encrypted communication channel; S21: TBOX initiates an authentication request; TBOX extracts the pre-installed device certificate and encapsulates it into an authentication request message, which is then sent to the cloud via the cellular network. The cloud receives the authentication request message and verifies the validity of the device certificate. If the verification passes, proceed to step S22; otherwise, the cloud generates a verification failure reminder. S22: Cloud feedback and completion of two-way authentication; The cloud retrieves the cloud server certificate from the security key management system (KMS), encapsulates it into an authentication response message, and sends it to TBOX. After receiving the data, the cloud uses the public key in the TBOX's device certificate to decrypt the challenge response value. If the decryption result matches the random challenge value, the TBOX currently interacting with is determined to be a legitimate device. S23: Generate a key and establish a secure channel; After mutual authentication is successful, TBOX and the cloud initiate the ECDH key negotiation process to generate a session key known only to the two parties. S3: TBOX performs multiple security checks on cloud upgrade packages; The cloud transmits the cloud upgrade package to TBOX through an encrypted communication channel. TBOX receives the cloud upgrade package and verifies it. S31: Verify the basic information of the differential upgrade package; S32: Perform supplementary integrity verification; S33: Verify the digital signature; S4: Perform secure transmission of the vehicle bus between TBOX and SBOX; S5: Monitor the upgrade process in real time and handle any emergencies. S6: Conduct final security verification and audit.

2. The security control method for OTA software upgrade of vehicle-mounted satellite communication terminal via TBOX as described in claim 1, characterized in that: The specific details of step S1 are as follows: S11: Generate differential upgrade package; Based on SBOX's software iteration requirements, cloud-based technical personnel compile and generate a differential upgrade package for the target version. The generated differential upgrade package is hashed using a high-strength hash algorithm to obtain the package body hash value of the differential upgrade package, and the package body hash value is unique; S12: Encrypt the differential upgrade package; The private key is retrieved from the cloud and used to perform asymmetric encryption on the packet body hash value using an asymmetric algorithm to generate a digital signature. The digital signature is then bound to the differential upgrade package to obtain the signed differential upgrade package to be encrypted. A one-time symmetric encryption key is randomly generated in the cloud. The symmetric encryption key is used to perform overall symmetric encryption on the signed differential upgrade package to be encrypted, resulting in the encrypted differential upgrade package. The one-time symmetric encryption key is asymmetrically encrypted using the TBOX device public key stored in the cloud to generate an encrypted temporary key. The cloud generates basic information for the differential upgrade package according to a preset format. The encrypted differential upgrade package, the encrypted temporary key, the basic information of the differential upgrade package, and the package body hash value are integrated into a final cloud upgrade package and then encapsulated. A high-strength hash algorithm is used to perform hash calculations on the cloud upgrade package, and the resulting hash value is the baseline overall hash value of the upgrade package and stored in the cloud.

3. The security control method for OTA software upgrade of vehicle-mounted satellite communication terminal via TBOX as described in claim 1, characterized in that: The specific details of step S2 are as follows: S21: TBOX initiates an authentication request; This includes basic validity verification, signature validity verification, and device association verification; S22: Cloud feedback and completion of two-way authentication; The authentication response message includes a cloud server certificate and a random challenge value, wherein the random challenge value is a randomly generated string; TBOX receives and verifies the cloud server certificate; after successful verification, TBOX uses its own device private key to encrypt the random challenge value, generates a challenge response value, and sends it back to the cloud. S23: Generate a key and establish a secure channel; TBOX generates a pair of temporary ECDH keys, including a temporary public key and a temporary private key, and sends the temporary public key to the cloud. The cloud synchronously generates its own temporary ECDH key pair and sends the temporary public key back to TBOX. The original session key is obtained by using the ECDH algorithm based on the TBOX's own temporary private key and the cloud's temporary public key. The same original session key is also obtained by using the ECDH algorithm based on the cloud's own temporary private key and the TBOX's temporary public key. TBOX and the cloud respectively use key derivation functions combined with information such as random challenge values ​​to derive the original session key, thus obtaining the final TLS session key; TBOX and the cloud use TLS session keys to enable TLS-related protocols to build an encrypted communication channel.

4. The security control method for OTA software upgrade of vehicle-mounted satellite communication terminal via TBOX as described in claim 1, characterized in that: The specific details of step S3 are as follows: S31: Verify the basic information of the differential upgrade package; The TBOX reads the version number from the basic information of the differential upgrade package and compares it with the current version number corresponding to this SBOX recorded by the TBOX to determine whether it conforms to the upgrade logic, which includes allowing only higher versions to overwrite lower versions; if it does not conform, the verification fails. If they match, the unique identifier in the basic information of the differential upgrade package is extracted and compared with the unique identifier of the associated SBOX in the local storage of the TBOX. If they do not match, the verification fails. If they match, extract the expiration date from the basic information of the differential upgrade package and compare it with the current system time of TBOX. If the expiration date has expired, the upgrade package is determined to be invalid, the process is terminated and feedback is sent to the cloud; otherwise, proceed to step S32. S32: Perform supplementary integrity verification; TBOX uses a high-strength hash algorithm to calculate the local overall hash value of the entire cloud upgrade package and generates an upgrade task ID. The local overall hash value and the upgrade task ID are sent to the cloud through an encrypted communication channel. The cloud compares the local overall hash value with the base overall hash value of the upgrade package. If the two are consistent, the integrity verification passes and proceeds to step S33; otherwise, the verification fails. S33: Verify the digital signature; TBOX disassembles the components of the cloud upgrade package according to a preset format, retrieves the TBOX device private key from the local pre-set secure storage, performs asymmetric decryption on the encrypted temporary key, and obtains a one-time symmetric encryption key. The encrypted differential upgrade packet is decrypted using the symmetric encryption key to obtain a signed differential upgrade packet; It retrieves the cloud public key from the local pre-installed secure storage, and uses the cloud public key to perform asymmetric decryption on the digital signature in the differential upgrade package to obtain the package body hash value; TBOX uses the same high-strength hash algorithm as in step S11 to recalculate the hash value of the decrypted differential upgrade packet to obtain the locally calculated hash value. If the locally calculated hash value is consistent with the packet body hash value, it indicates that the encrypted differential upgrade packet has not been tampered with during transmission, and proceeds to step S4; if they are inconsistent, the process is terminated and a signature verification failure is reported to the cloud.

5. The security control method for OTA software upgrade of vehicle-mounted satellite communication terminal via TBOX as described in claim 1, characterized in that: The specific details of step S4 are as follows: TBOX retrieves its own device private key from local secure storage, performs asymmetric decryption on the encrypted temporary key in the cloud upgrade package to obtain a one-time symmetric encryption key; and uses the one-time symmetric encryption key to decrypt the encrypted differential upgrade package to obtain a signed differential upgrade package. Based on the communication characteristics of the vehicle bus, TBOX uses a bus-level encryption protocol to encrypt the signed differential upgrade package in real time to obtain the transmitted data. A verification field is added to the transmitted data, and the transmitted data is encapsulated into a data frame and sent to SBOX through the vehicle bus. SBOX receives data frames transmitted from the vehicle bus, decrypts the data frames using a preset bus decryption key, and obtains a differential upgrade package with a digital signature. SBOX uses a locally preset cloud public key to verify the digital signature in the upgrade package. If the verification is successful, the source of the differential upgrade package with a digital signature is determined to be legitimate. SBOX then stores the differential upgrade package with a digital signature and prepares to enter the upgrade process. If the verification fails, reception is terminated and an exception is reported to TBOX.

6. The security control method for OTA software upgrade of vehicle-mounted satellite communication terminal via TBOX as described in claim 1, characterized in that: The specific details of step S5 are as follows: Upgrades are performed using differential upgrade packages. TBOX and SBOX establish a real-time heartbeat interaction mechanism, with SBOX providing feedback on the upgrade progress of the differential upgrade package to TBOX at preset intervals. TBOX synchronously records and generates a complete status log; When an anomaly is detected, the TBOX triggers an anomaly alarm and sends a rollback command to the SBOX. After receiving the rollback command, the SBOX stops the current upgrade process and performs the rollback operation. At the same time, it reports the anomaly log and on-site data to the cloud and waits for further instructions.

7. The security control method for OTA software upgrade of vehicle-mounted satellite communication terminal via TBOX as described in claim 1, characterized in that: The specific details of step S6 are as follows: After the SBOX completes the upgrade, it generates a result message and sends it to the TBOX through an encrypted communication channel. The TBOX verifies the authenticity of the message, compares the current version of the SBOX with the target version to see if they are consistent, and checks whether the core functions of the SBOX are normal, thus confirming that the upgrade is effective. TBOX integrates and upgrades the entire process log, generating audit reports in a preset format.

Images