Data transmission method, device, system and equipment and computing medium

By acquiring risk factor data from hardware devices to assess risk levels and determine target security configurations, security issues during car key upgrades are resolved. This enables intelligent upgrade strategies that adjust based on environment and threat levels, thereby improving transmission security.

CN121814338APending Publication Date: 2026-04-07BEIJING WATCH SMART TECH LTD
View PDF 0 Cites 0 Cited by

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-11-17
Publication Date
2026-04-07

AI Technical Summary

Technical Problem

Existing car key upgrade methods cannot adjust security strategies based on the usage environment and threat level, lacking intelligent upgrade decision-making and risk prediction capabilities, resulting in security issues during upgrade file transfer.

Method used

By acquiring risk factor data from the hardware devices to be upgraded, assessing the risk level and determining the target security configuration, and adjusting the transmission security policy of the upgrade files based on the level, security is ensured by using technologies such as AES-256 encryption algorithm, two-factor authentication and encrypted Bluetooth transmission.

Benefits of technology

The security of upgrade file transfer has been improved. By dynamically adjusting security policies to deal with different risk levels, the security and reliability of the car key upgrade process have been enhanced.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN121814338A_ABST
    Figure CN121814338A_ABST
Patent Text Reader

Abstract

The invention provides a data transmission method, device, system and equipment and a computing medium, and the method comprises the steps: obtaining risk factor data from to-be-upgraded hardware equipment, the risk factor data being used for evaluating the risk level of an upgrade file corresponding to the transmission hardware equipment; determining a target risk level of the upgrade file corresponding to the transmission hardware equipment based on the risk factor data; determining a target security configuration based on the target risk level; and sending the upgrading file obtained from the cloud server to the hardware equipment according to the target security configuration. According to the embodiment of the invention, the risk level of the risk factor data of the current hardware equipment is evaluated, and the security configuration for transmitting the upgrade file is determined based on the risk level, so that the transmission security of the upgrade file is improved.
Need to check novelty before this filing date? Find Prior Art

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of data processing, and particularly relates to a data transmission method, device, system, equipment and computing medium. BACKGROUND

[0002] In the related art, the vehicle key can be upgraded in an online upgrade manner, that is, an application program of a mobile terminal obtains a corresponding upgrade package from a cloud server, and sends the upgrade package to the vehicle key for upgrading.

[0003] However, the target upgrade manner has the following technical defects: unable to adjust the security policy according to the use environment and threat level; lacks intelligent upgrade decision and risk prediction capability, and can only adopt a passive upgrade mode, which may cause security problems in the process of upgrading file transmission. SUMMARY

[0004] The application provides a data transmission method, device, system, equipment and computing medium, which can solve the technical problem of security problems in the process of upgrading file transmission.

[0005] The first aspect of the application provides a data transmission method, comprising: obtaining risk factor data from a hardware device to be upgraded, wherein the risk factor data is used to evaluate the risk level of transmitting an upgrade file corresponding to the hardware device; determining a target risk level of transmitting the upgrade file corresponding to the hardware device based on the risk factor data; determining a target security configuration based on the target risk level; sending the upgrade file obtained from the cloud server to the hardware device according to the target security configuration.

[0006] The second aspect of the application provides a data transmission device, comprising: an obtaining module configured to obtain risk factor data from a hardware device to be upgraded, wherein the risk factor data is used to evaluate the risk level of transmitting an upgrade file corresponding to the hardware device; a determining module configured to determine a target risk level of transmitting the upgrade file corresponding to the hardware device based on the risk factor data; The determining module is further configured to determine a target security configuration based on the target risk level; a sending module configured to send the upgrade file obtained from the cloud server to the hardware device according to the target security configuration.

[0007] The third aspect of the application provides a data transmission system, comprising: a hardware device, an application program and a cloud server; The hardware device is configured to send risk factor data to the application program, the risk factor data being used to evaluate a risk level of transmitting an upgrade file corresponding to the hardware device; The application program is configured to determine a target risk level of transmitting the upgrade file corresponding to the hardware device based on the risk factor data, determine a target security configuration based on the target risk level, and send the upgrade file obtained from the cloud server to the hardware device according to the target security configuration. The cloud server is configured to send the upgrade file to the application program.

[0008] Embodiments of the fourth aspect of the present application provide an electronic device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the method of the first aspect.

[0009] Embodiments of the fifth aspect of the present application provide a computer readable storage medium having a computer program stored thereon, wherein the program is executed by a processor to implement the method of the first aspect.

[0010] The technical solutions provided in the embodiments of the present application have at least the following technical effects or advantages: The present application provides a data transmission method, device, system, equipment and computing medium, the method comprising: obtaining risk factor data from a hardware device to be upgraded, the risk factor data being used to evaluate a risk level of transmitting an upgrade file corresponding to the hardware device; determining a target risk level of transmitting the upgrade file corresponding to the hardware device based on the risk factor data; determining a target security configuration based on the target risk level; and sending the upgrade file obtained from a cloud server to the hardware device according to the target security configuration. The embodiments of the present application evaluate the risk level of the risk factor data of the current hardware device, and determine the security configuration of transmitting the upgrade file based on the risk level, thereby improving the transmission security of the upgrade file.

[0011] Additional aspects and advantages of the present application will be made apparent from the following description of the application. BRIEF DESCRIPTION OF DRAWINGS

[0012] Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The accompanying drawings are included to provide a description of the preferred embodiments and are not intended to limit the scope of the present application. Moreover, the same reference numerals are used throughout the same figures. In the drawings: Figure 1 A flowchart of a data transmission method provided by an embodiment of the present application is shown; Figure 2A flowchart of determining a target risk level and a target security configuration based on risk factor data is shown according to an embodiment of the present application. Figure 3 A flowchart of determining a target security configuration is shown according to an embodiment of the present application. Figure 4 A timing flowchart of a zero-knowledge proof upgrade verification protocol is shown according to an embodiment of the present application. Figure 5 A structural diagram of a data transmission system is shown according to an embodiment of the present application. Figure 6 A structural diagram of a data transmission device is shown according to an embodiment of the present application. Figure 7 A structural diagram of an electronic device is shown according to an embodiment of the present application. Figure 8 A structural diagram of a storage medium is shown according to an embodiment of the present application. DETAILED DESCRIPTION

[0013] Exemplary embodiments of the present application will be described herein below with reference to the accompanying drawings. Although exemplary embodiments of the present application are shown in the drawings, it should be understood that the present application can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided so that this application will be thoroughly and completely understood, and will fully convey the scope of the application to those skilled in the art.

[0014] It should be noted that, unless otherwise specified, technical terms or scientific terms used in the present application should be understood as their common meanings to those skilled in the art to which the present application pertains.

[0015] To solve the technical problems mentioned in the background, the present application provides a data transmission method, device, system, equipment and computing medium. The method comprises: obtaining risk factor data from a hardware device to be upgraded, the risk factor data being used to evaluate the risk level of the transmission hardware device corresponding to the upgrade file; determining a target risk level of the transmission hardware device corresponding to the upgrade file based on the risk factor data; determining a target security configuration based on the target risk level; and sending the upgrade file obtained from a cloud server to the hardware device according to the target security configuration. The embodiments of the present application evaluate the risk level of the risk factor data of the current hardware device, and determine the security configuration of the transmission upgrade file based on the risk level, thereby improving the transmission security of the upgrade file.

[0016] A data transmission method, device, system, equipment and computing medium are described below according to an embodiment of the present application. The present application is described by taking an upgrade file data transmission method as an example. The execution terminal of the embodiment of the present application can be an application program, which can be an application program installed in a mobile device terminal.

[0017] Referring to Figure 1 The method specifically includes the following steps: S101, obtaining risk factor data from a hardware device to be upgraded.

[0018] The risk factor data is used to evaluate the risk level of the hardware device corresponding to the upgrade file.

[0019] S102, determining a target risk level of the hardware device corresponding to the upgrade file based on the risk factor data.

[0020] S103, determining a target security configuration based on the target risk level.

[0021] S104, sending the upgrade file obtained from the cloud server to the hardware device according to the target security configuration.

[0022] The hardware device can be a device supporting Over-The-Air (OTA) firmware upgrade, such as a digital car key, a car remote control, and a handheld wireless device such as a model remote control.

[0023] The risk factor data can include multiple dimensions of risk factor data, and the multiple dimensions can include address dimension, network environment dimension, time dimension, and user behavior dimension.

[0024] The hardware device can be provided with a sensor array, and each sensor in the sensor array can collect the multiple dimensions of risk factor data. Further, the application program can obtain the corresponding risk factor data by obtaining the corresponding permissions in the hardware device. For example, in the process of obtaining the risk factor data of the geographic dimension, the risk factor data of the address dimension can be obtained by obtaining the positioning permission. Thus, the risk factor data of each dimension can be obtained by the above method.

[0025] In some embodiments, the risk factor data can be determined by a risk prediction model to determine the target risk level of the hardware device corresponding to the upgrade file.

[0026] In some embodiments, the risk factor data can be input into the risk prediction model to obtain the target risk level output by the risk prediction model. In some embodiments, the target risk level corresponding to the risk factor can also be determined based on the comparison relationship between the risk factor data and the risk level.

[0027] Further, the corresponding security configuration can be selected according to the target risk level.

[0028] The security configuration is a set of protocols, algorithms, key lengths, authentication modes, and policy switches enabled on the complete path of data "leaving the source, entering the network, and reaching the destination".

[0029] In the embodiments of the present application, the security configuration can be an AES-256 encryption algorithm, a two-factor authentication mechanism, and an encrypted Bluetooth transmission combined with random frequency hopping technology, or an AES-128 encryption algorithm combined with basic authentication and a standard Bluetooth transmission protocol.

[0030] In some embodiments, the target risk level can be input into a corresponding configuration prediction model to output the corresponding target security configuration. Alternatively, the target risk level can be determined by a preset algorithm to determine the corresponding target security configuration.

[0031] Further, the upgrade file obtained from the cloud server can be sent to the hardware device according to the target security configuration to ensure the security of the upgrade file transmission.

[0032] The present application proposes a data transmission method, device, system, equipment, and computing medium. The method comprises: obtaining risk factor data from a hardware device to be upgraded, the risk factor data being used to evaluate the risk level of the upgrade file corresponding to the hardware device; determining the target risk level of the upgrade file corresponding to the hardware device based on the risk factor data; determining the target security configuration based on the target risk level; and sending the upgrade file obtained from the cloud server to the hardware device according to the target security configuration. The embodiments of the application evaluate the risk level of the risk factor data of the current hardware device, and determine the security configuration of the upgrade file based on the risk level, thereby improving the transmission security of the upgrade file.

[0033] In some embodiments, determining the target risk level of the upgrade file corresponding to the hardware device based on the risk factor data comprises: inputting the risk factor data into a risk prediction model to obtain the target risk level of the upgrade file corresponding to the hardware device.

[0034] In some embodiments, the risk factor data can be directly input into the risk prediction model to obtain the target risk level corresponding to the risk factor data.

[0035] In some embodiments, the risk factor data includes risk factor sub-data in multiple dimensions, and the risk prediction model includes risk prediction sub-models corresponding to each of the risk factor sub-data in multiple dimensions. Inputting the risk factor data into the risk prediction model to obtain the target risk level of the upgrade file corresponding to the transmission hardware device includes: inputting the risk factor sub-data in multiple dimensions into the corresponding risk prediction sub-models to obtain the risk level corresponding to each of the risk factor sub-data in multiple dimensions; and determining the target risk level of the upgrade file corresponding to the transmission hardware device based on the risk weight coefficients and risk levels corresponding to each risk factor sub-data.

[0036] As mentioned above, risk factor data includes risk factor sub-data in multiple dimensions, which may include address dimension, network environment dimension, time dimension, and user behavior dimension, etc.

[0037] The risk prediction model includes risk prediction sub-models corresponding to risk factor sub-data in multiple dimensions. The risk factor sub-data in multiple dimensions can be input into the corresponding risk prediction sub-model to obtain the risk level corresponding to each risk factor sub-data in multiple dimensions.

[0038] The model's input features include environmental data such as geographic location, network type, number of surrounding devices and signal strength, historical time series data covering the threat level change trend over the past 24 hours, and user behavior pattern vectors describing individual usage habits.

[0039] The geolocation risk assessment builds a regional threat model based on historical attack data. It calculates location risk values ​​through real-time matching of GPS coordinates with a threat database, classifying risk levels into three tiers: low-risk, medium-risk, and high-risk areas. The network environment analysis module detects the security configuration of the WiFi network, measures the strength of Bluetooth interference signals, and identifies abnormal scanning behavior from surrounding devices. The time pattern recognition module analyzes security risks at different times based on historical data, giving increased weight to high-risk time points such as late nights, detecting abnormal upgrade requests, and calculating the degree of deviation in user behavior patterns.

[0040] After determining the risk levels corresponding to the risk factor sub-data in multiple dimensions, the target risk level can be determined based on the risk levels corresponding to the risk factor sub-data in multiple dimensions.

[0041] The risk level and target risk level corresponding to each of the risk factor sub-data can be divided based on risk scoring.

[0042] In some embodiments, a risk level with a risk score less than 30 can be classified as low risk, a risk level with a risk score greater than or equal to 30 and less than 70 can be classified as medium risk, and a risk level with a risk score greater than or equal to 70 and less than or equal to 100 can be classified as high risk.

[0043] In some embodiments, the target risk level of the upgrade file corresponding to the transmission hardware device can be determined based on the risk weight coefficient and the risk level corresponding to each risk factor sub-data.

[0044] For example, if the four risk dimensions have different risk weighting coefficients: geographical location risk accounts for 30%, network risk accounts for 25%, time risk accounts for 20%, and behavioral risk accounts for 25%, and the corresponding risk scores for the four risk dimensions are 20 for geographical location risk, 60 for network risk, 50 for time risk, and 20 for behavioral risk, then the highest score would be 20*30%+60*25%+50*20%+20*25%=36, meaning the target risk level is medium risk.

[0045] In some embodiments, determining the target security configuration based on the target risk level includes: obtaining a correlation between the risk level and the security configuration; and determining the target security configuration based on the correlation and the target risk level.

[0046] The application can store a mapping between risk levels and security configurations, and the target security configuration corresponding to the target risk level can be found from the mapping.

[0047] In some embodiments, this application provides a process for determining the target risk level and target security configuration based on risk factor data, such as... Figure 2 As shown: First, the risk factor data is input into the risk prediction model. The risk factor data includes risk factor sub-data in multiple dimensions, namely address dimension, network environment dimension, time dimension and user behavior dimension. The risk prediction model includes risk prediction sub-models corresponding to each of the risk factor sub-data in multiple dimensions.

[0048] The risk factor sub-data of multiple dimensions are input into the risk prediction model. The risk weight coefficients corresponding to the four risk dimensions are: geographical location risk accounts for 30%, network risk accounts for 25%, time risk accounts for 20%, and behavioral risk accounts for 25%.

[0049] The risk prediction model determines the target risk level of the upgrade file corresponding to the transmission hardware device based on the risk weight coefficients and risk levels corresponding to each risk factor sub-data.

[0050] Risk scores less than 30 can be classified as low risk, risk scores greater than or equal to 30 and less than 70 as medium risk, and risk scores greater than or equal to 70 and less than or equal to 100 as high risk.

[0051] If the target risk level is determined to be low, the target security configuration is determined to be AES-128 encryption algorithm with basic authentication and standard Bluetooth transmission protocol. If the target risk level is determined to be medium, the target security configuration is determined to be AES-256 encryption algorithm, enabling two-factor authentication mechanism, and using encrypted Bluetooth transmission with random frequency hopping technology. If the target risk level is determined to be high, the target security configuration is determined to be a hybrid encryption system of AES-256 combined with RSA-4096, multi-factor authentication combined with biometric technology, and quantum encryption channel transmission protection.

[0052] In some embodiments, determining the target security configuration based on the comparison relationship and the target risk level includes: determining the risk level range of the target risk level; if the risk level range is a first risk level range or a third risk level range, then searching for the target security configuration corresponding to the target risk level from the comparison relationship; if the risk level range is a second risk level range, then obtaining the upgrade preference setting, and searching for the target security configuration corresponding to the risk level range and the upgrade preference setting from the comparison relationship, wherein the risk level corresponding to the first risk level range is less than the risk level corresponding to the second risk level range, and the risk level corresponding to the second risk level range is less than the risk level corresponding to the third risk level range.

[0053] In some embodiments, the final target security configuration can also be determined by combining the user's upgrade preference settings during the process of determining the target security configuration.

[0054] The first risk level range can be a low risk level range, the second risk level range can be a medium risk level range, and the third risk level range can be a high risk level range.

[0055] The upgrade preference settings mainly include security and performance preferences. When the upgrade preference is set to performance priority, the system will appropriately reduce the security configuration to improve execution efficiency. When the upgrade preference is set to maximum security, the system will further strengthen security measures on the basis of the standard configuration.

[0056] It is understandable that if the target risk level is in the first risk level range, the target risk level is low and there will be no security issues. Therefore, the target security configuration adopted mainly considers transmission performance. Thus, there is no need to consider upgrade preference settings to determine the corresponding target security configuration. The target security configuration corresponding to the target risk level can be found directly from the comparison relationship.

[0057] For the same reason, if the target risk level is in the third risk level range, the target risk level is relatively high and the highest security configuration is required to ensure the security of transmission. Therefore, the target security configuration adopted is the highest security configuration. It is not possible to reduce the security configuration based on upgrade preference settings. Therefore, the target security configuration corresponding to the target risk level can be found directly from the comparison relationship.

[0058] If the target risk level is in the second risk level range, and the target risk level is in the middle position, then you can consider upgrading the preference settings to determine the final target security configuration. That is, you can find the target security configuration corresponding to the risk level range and the upgraded preference settings from the comparison relationship.

[0059] In some embodiments, the security configuration corresponding to the second risk level range is a balanced configuration and a performance-optimized configuration. If the upgrade preference is set to performance priority, the performance-optimized configuration is selected; if the upgrade preference is set to security priority, the balanced configuration is selected.

[0060] In some embodiments, this application provides a flowchart for determining a target security configuration, such as... Figure 3 As shown: The risk prediction model determines the target risk level of the upgrade file corresponding to the transmission hardware device based on the risk weight coefficients and risk levels corresponding to each risk factor sub-data.

[0061] Risk scores less than 30 can be classified as low risk, risk scores greater than or equal to 30 and less than 70 as medium risk, and risk scores greater than or equal to 70 and less than or equal to 100 as high risk.

[0062] If the target risk level is determined to be low, the target security configuration will be AES-128 encryption algorithm combined with basic authentication and standard Bluetooth transmission protocol. If the target risk level is determined to be medium, and the upgrade preference is set to performance priority, the target security configuration will be AES-256 encryption algorithm with two-factor authentication enabled. If the upgrade preference is set to security priority, the target security configuration will be optimized with AES-256 encryption algorithm with fast two-factor authentication enabled. If the target risk level is determined to be high, the target security configuration will be a hybrid encryption system combining AES-256 and RSA-4096, multi-factor authentication combined with biometric technology, and quantum encryption channel transmission protection.

[0063] In some embodiments, the application on the mobile device terminal is also provided with an interactive interface. After determining the target security configuration and receiving the upgrade file, if a sending instruction for the upgrade file is received on the interactive interface, the upgrade file obtained from the cloud server will be sent to the hardware device according to the target security configuration.

[0064] In some embodiments, before obtaining risk factor data from the hardware device to be upgraded, the method further includes: receiving a first zero-knowledge proof sent by the hardware device to be upgraded, the first zero-knowledge proof being generated based on private input information, public input information, and a proof key; verifying the validity of the first zero-knowledge proof based on a verification key and public input information; and, if the first zero-knowledge proof is verified to be valid, returning a first authorization token and obtaining risk factor data from the hardware device to be upgraded, the first authorization token being used to indicate that the hardware device is eligible for upgrade.

[0065] Obtaining risk factor data from the hardware devices to be upgraded requires determining whether the hardware devices are eligible for upgrades.

[0066] In some embodiments, after receiving an upgrade command from the cloud server, the hardware device obtains its own private input information, which includes: the device digital certificate, the current firmware version, and the device integrity hash value.

[0067] Further determine whether the private input information meets the preset constraints. These preset constraints can be: certificate verification constraints to ensure the validity and authenticity of the device's digital certificate; version check constraints to verify that the current firmware version meets the upgrade compatibility requirements; integrity verification constraints to confirm that the device has not been tampered with and that the system is in normal condition; and resource check constraints to verify that the device has sufficient storage space and battery power to support the upgrade process.

[0068] Once it is determined that the private input information meets the preset constraints, the verification key and public input information are obtained. The public input information includes the upgrade policy rules and the minimum version requirements.

[0069] Furthermore, based on the proof key, public input information, and secret input, a preset proof algorithm is run to generate a first zero-knowledge proof, wherein the preset proof algorithm can be a proof algorithm of the zk-SNARKs protocol.

[0070] The hardware device sends the first zero-knowledge proof to the application. The application obtains the verification key and public input information, and runs a preset verification algorithm based on the verification key, public input information and the first zero-knowledge proof to verify whether the first zero-knowledge proof is valid.

[0071] If the first zero-knowledge proof is verified to be valid, a first authorization token is returned to indicate that the hardware device is eligible for upgrade and to obtain risk factor data from the hardware device to be upgraded.

[0072] In some embodiments, the method further includes: obtaining commitment information corresponding to the upgrade file from a cloud server; sending the commitment information and the upgrade file to a hardware device; receiving a second zero-knowledge proof sent by the hardware device after verifying the validity of the commitment information; returning a second authorization token after verifying the validity of the second zero-knowledge proof, the second authorization token being used to instruct the hardware device to perform an upgrade based on the upgrade file; receiving a third zero-knowledge proof sent by the hardware device; and sending the third zero-knowledge proof to the cloud server after verifying its validity, the third zero-knowledge proof being used by the cloud server to update the device status record of the hardware device, and the third zero-knowledge proof being used to indicate that the upgrade is complete.

[0073] In some embodiments, during the process of the application obtaining the upgrade file from the cloud server, the cloud server also sends a commitment message to the application. This commitment message is used to guarantee the integrity and authenticity of the upgrade file, and includes the hash value or digest information of the upgrade file.

[0074] In some embodiments, the process of the cloud server generating the commitment information can be implemented as follows: The upgrade file is hashed to generate an upgrade file hash value or digest information. The hash value or digest information is then encapsulated to obtain the commitment information.

[0075] After the commitment information is sent to the hardware device, the hardware device verifies the commitment information. If the commitment information is verified to be valid, a second zero-knowledge proof is generated. This second zero-knowledge proof is used to prove whether the hardware device can perform a firmware upgrade based on the upgrade file. If the second zero-knowledge proof is verified to be valid, a second authorization token is returned. The second authorization token is used to instruct the hardware device to perform an upgrade based on the upgrade file.

[0076] Upon receiving the second authorization token, the hardware device upgrades the firmware based on the upgrade file. Once the upgrade is complete and the system is in normal condition, a third zero-knowledge proof is generated. If the validity of the third zero-knowledge proof is verified, the firmware upgrade is considered complete, and the third zero-knowledge proof is sent to the cloud server so that the cloud server can update the device status record based on the third zero-knowledge proof.

[0077] It should be noted that the process of generating the second and third zero-knowledge proofs is the same as that of generating the first zero-knowledge proof, except that the private input information and corresponding constraints need to be determined, which will not be elaborated here.

[0078] In this embodiment of the application, a zero-knowledge proof protocol is used to ensure that no sensitive device information is disclosed during the upgrade process, thereby improving the security of the firmware upgrade process.

[0079] To illustrate the verification process at each end during the data transmission, this application provides a timing flowchart of a zero-knowledge proof upgrade verification protocol, as follows: Figure 4 As shown: First, during the pre-qualification process: The hardware device generates the first zero-knowledge proof based on private input information, public input information, and proof key.

[0080] The hardware device sends the first zero-knowledge proof to the application.

[0081] The application verifies the validity of the first zero-knowledge proof based on the verification key and public input information.

[0082] If the application verifies that the first zero-knowledge proof is valid, it returns the first authorization token to the hardware device.

[0083] During the upgrade package verification process: The application sends an upgrade file request to the cloud server.

[0084] The cloud server generates the commitment information corresponding to the upgrade file.

[0085] The cloud server sends the commitment information and upgrade documents to the application.

[0086] The application will send commitment information and upgrade files to the hardware device.

[0087] The hardware device sends a second zero-knowledge proof to the application, which is sent after verifying the validity of the commitment information.

[0088] If the application verifies that the second zero-knowledge proof is valid, it returns a second authorization token, which is used to instruct the hardware device to upgrade the firmware based on the upgrade file.

[0089] Once the firmware upgrade is complete, the hardware device sends a third zero-knowledge proof to the application.

[0090] Once the application verifies the validity of the third zero-knowledge proof, it sends the third zero-knowledge proof to the cloud server.

[0091] The cloud server updates the device status records of the hardware device based on the third zero-knowledge proof.

[0092] The following description, in conjunction with the accompanying drawings, illustrates a data transmission system proposed according to an embodiment of this application, such as... Figure 5 As shown, the system includes: hardware devices, applications, and cloud servers.

[0093] The hardware device is used to send risk factor data to the application, and the risk factor data is used to assess the risk level of the corresponding upgrade file of the transmitted hardware device. The application is used to determine the target risk level of the upgrade file corresponding to the transmission hardware device based on risk factor data; determine the target security configuration based on the target risk level; and send the upgrade file obtained from the cloud server to the hardware device according to the target security configuration. The cloud server is used to send upgrade files to the application.

[0094] To describe the overall process of the above data transmission method, combined with Figure 5 The above data transmission method is explained as follows: The hardware device includes a security chip unit, a sensor array unit, and a storage unit.

[0095] Upon receiving an upgrade command, the security chip unit acquires the hardware device's private input information, verification key, and public input information. Based on the proof key, public input information, and secret input, it runs a preset proof algorithm to generate a first zero-knowledge proof. This first zero-knowledge proof is then sent to the application.

[0096] The storage unit includes a running partition and a backup partition. The running partition stores the current firmware and system state; the backup partition saves the firmware version before the upgrade for fault recovery.

[0097] The application includes: a risk perception engine unit, a security configuration decision unit, a verification unit, and a user interaction unit.

[0098] The verification unit verifies the first zero-knowledge proof. If the verification is successful, the sensor array unit acquires risk factor data. The risk perception engine unit determines the target risk level of the upgrade file corresponding to the transmission hardware device based on the risk factor data. The security configuration decision unit determines the target security configuration based on the target risk level.

[0099] The application will also send an upgrade file retrieval request to the cloud server.

[0100] The cloud server includes an upgrade package management unit, which sends the upgrade file to the application upon receiving an upgrade file retrieval request.

[0101] If the application receives a send command from the user through the interactive interface provided by the user interaction unit after obtaining the upgrade file, it will send the upgrade file obtained from the cloud server to the hardware device according to the target security configuration.

[0102] The hardware device upgrades the stored firmware based on the upgrade file.

[0103] This application also provides a data transmission apparatus, applied to a server, which is used to perform the above-described... Figure 1 The data transmission method provided in the embodiment. For example... Figure 6 As shown, the device includes: an acquisition module 601, a determination module 602, and a transmission module 603.

[0104] The acquisition module 601 is used to acquire risk factor data from the hardware device to be upgraded, and the risk factor data is used to assess the risk level of transmitting the upgrade file corresponding to the hardware device; The determination module 602 is used to determine the target risk level of transmitting the upgrade file corresponding to the hardware device based on the risk factor data; The determining module 602 is further configured to determine the target security configuration based on the target risk level; The sending module 603 is used to send the upgrade file obtained from the cloud server to the hardware device according to the target security configuration.

[0105] This application proposes a data transmission method, apparatus, system, device, and computing medium. The method includes: obtaining risk factor data from a hardware device to be upgraded, wherein the risk factor data is used to assess the risk level of the upgrade file corresponding to the hardware device; determining a target risk level of the upgrade file based on the risk factor data; determining a target security configuration based on the target risk level; and sending the upgrade file obtained from a cloud server to the hardware device according to the target security configuration. The application embodiment improves the security of upgrade file transmission by assessing the risk level of the current hardware device's risk factor data and determining the security configuration of the upgrade file based on the risk level.

[0106] In some embodiments, the determining module 602 is specifically used for: The risk factor data is input into the risk prediction model to obtain the target risk level of transmitting the upgrade file corresponding to the hardware device.

[0107] In some embodiments, the risk factor data includes risk factor sub-data across multiple dimensions, and the risk prediction model includes risk prediction sub-models corresponding to each of the risk factor sub-data across multiple dimensions. The determining module 602 is further specifically used for: By inputting risk factor sub-data from multiple dimensions into the corresponding risk prediction sub-model, the risk level corresponding to each of the risk factor sub-data from multiple dimensions is obtained; The target risk level for transmitting the upgrade file corresponding to the hardware device is determined based on the risk weight coefficient and the risk level corresponding to each risk factor sub-data.

[0108] In some embodiments, the determining module 602 is further specifically used for: Obtain the correlation between risk levels and security configurations; The target security configuration is determined based on the aforementioned comparison relationship and the target risk level.

[0109] In some embodiments, the determining module 602 is further specifically used for: Determine the risk level range for the target risk level; If the risk level range is the first risk level range or the third risk level range, then find the target security configuration corresponding to the target risk level from the comparison relationship; If the risk level range is the second risk level range, then the upgrade preference setting is obtained, and the target security configuration corresponding to the risk level range and the upgrade preference setting is found in the comparison relationship. The risk level corresponding to the first risk level range is less than the risk level corresponding to the second risk level range, and the risk level corresponding to the second risk level range is less than the risk level corresponding to the third risk level range.

[0110] In some embodiments, the above-described apparatus further includes: a receiving module, a verification module, and a return module; The receiving module is used to: receive a first zero-knowledge proof sent by the hardware device to be upgraded, wherein the first zero-knowledge proof is generated based on the private input information, public input information and proof key; The verification module is used to: verify whether the first zero-knowledge proof is valid based on the verification key and the public input information; The return module is used to: return a first authorization token and obtain risk factor data from the hardware device to be upgraded if the first zero-knowledge proof is verified to be valid, wherein the first authorization token is used to indicate that the hardware device is eligible for upgrade.

[0111] In some embodiments, the acquisition module 601 is further configured to: Obtain commitment information corresponding to the upgrade file from the cloud server; the commitment information includes the hash value or digest information of the upgrade file. The sending module 603 is also used for: Send the commitment information and upgrade file to the hardware device; The receiving module is also used for: Receive the second zero-knowledge proof sent by the hardware device after verifying the validity of the commitment information; The verification module is also used for: If the second zero-knowledge proof is verified to be valid, a second authorization token is returned, which is used to instruct the hardware device to upgrade the firmware based on the upgrade file; The receiving module is also used for: Receive the third zero-knowledge proof sent by the hardware device; The sending module 603 is also used for: If the third zero-knowledge proof is verified to be valid, the third zero-knowledge proof is sent to the cloud server. The third zero-knowledge proof is used by the cloud server to update the device status record of the hardware device and to indicate that the upgrade is complete.

[0112] This application also provides an electronic device for performing the above-described data transmission method. Please refer to... Figure 7 It illustrates a schematic diagram of an electronic device provided by some embodiments of this application. For example... Figure 7 As shown, the electronic device 7 includes: a processor 700, a memory 701, a bus 702, and a communication interface 703. The processor 700, the communication interface 703, and the memory 701 are connected via the bus 702. The memory 701 stores a computer program that can run on the processor 700. When the processor 700 runs the computer program, it executes the data transmission method provided in any of the foregoing embodiments of this application.

[0113] The memory 701 may include high-speed random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Communication between the device network element and at least one other network element is achieved through at least one communication interface 703 (which can be wired or wireless), such as the Internet, wide area network, local area network, metropolitan area network, etc.

[0114] Bus 702 can be an ISA bus, PCI bus, or EISA bus, etc. The bus can be divided into address bus, data bus, control bus, etc. Memory 701 is used to store programs. After receiving execution instructions, processor 700 executes the program. The data transmission method disclosed in any of the aforementioned embodiments of this application can be applied to processor 700, or implemented by processor 700.

[0115] The processor 700 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 700 or by instructions in software form. The processor 700 may be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it may also be a digital signal processor (DSP), an application-specific integrated circuit (ASIC), an off-the-shelf programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied in the execution of a hardware decoding processor, or executed by a combination of hardware and software modules in the decoding processor. The software modules may reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. The storage medium is located in memory 701. Processor 700 reads the information in memory 701 and, in conjunction with its hardware, completes the steps of the above method.

[0116] The electronic device and the data transmission method provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods they adopt, operate or implement.

[0117] This application also provides a computer-readable storage medium corresponding to the data transmission method provided in the foregoing embodiments. Please refer to... Figure 8 The computer-readable storage medium shown is an optical disc 30, on which a computer program (i.e., a program product) is stored. When the computer program is run by a processor, it executes the data transmission method provided in any of the aforementioned embodiments.

[0118] It should be noted that examples of computer-readable storage media may also include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other optical and magnetic storage media, which will not be elaborated here.

[0119] The computer-readable storage medium provided in the above embodiments of this application and the data transmission method provided in the embodiments of this application are based on the same inventive concept and have the same beneficial effects as the methods adopted, run or implemented by the applications stored therein.

[0120] It should be noted that: Numerous specific details are set forth in the specification provided herein. However, it will be understood that embodiments of this application may be practiced without these specific details. In some instances, well-known structures and techniques have not been shown in detail so as not to obscure the understanding of this specification.

[0121] Similarly, it should be understood that, for the sake of brevity and to aid in understanding one or more of the various inventive aspects, in the above description of exemplary embodiments of this application, various features of this application are sometimes grouped together in a single embodiment, figure, or description thereof. However, this disclosure should not be construed as reflecting a schematic diagram in which the claimed application requires more features than expressly recited in each claim. Rather, as reflected in the following claims, inventive aspects lie in fewer than all features of a single foregoing disclosed embodiment. Therefore, the claims following the detailed description are hereby expressly incorporated into that detailed description, wherein each claim itself is a separate embodiment of this application.

[0122] Furthermore, those skilled in the art will understand that although some embodiments herein include certain features included in other embodiments but not others, combinations of features from different embodiments are intended to be within the scope of this application and form different embodiments. For example, in the following claims, any of the claimed embodiments can be used in any combination.

[0123] The above are merely preferred embodiments of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A data transmission method, characterized in that, Applied to the server side, including: Risk factor data is obtained from the hardware device to be upgraded, and the risk factor data is used to assess the risk level of transmitting the upgrade file corresponding to the hardware device; Based on the aforementioned risk factor data, determine the target risk level for transmitting the corresponding upgrade file for the hardware device; Determine the target security configuration based on the target risk level; The upgrade file obtained from the cloud server will be sent to the hardware device according to the target security configuration.

2. The method according to claim 1, characterized in that, Determining the target risk level for transmitting the upgrade file corresponding to the hardware device based on the risk factor data includes: The risk factor data is input into the risk prediction model to obtain the target risk level of transmitting the upgrade file corresponding to the hardware device.

3. The method according to claim 2, characterized in that, The risk factor data includes risk factor sub-data across multiple dimensions, and the risk prediction model includes risk prediction sub-models corresponding to each of the risk factor sub-data across multiple dimensions. The step of inputting the risk factor data into the risk prediction model to obtain the target risk level for transmitting the upgrade file corresponding to the hardware device includes: By inputting risk factor sub-data from multiple dimensions into the corresponding risk prediction sub-model, the risk level corresponding to each of the risk factor sub-data from multiple dimensions is obtained; The target risk level for transmitting the upgrade file corresponding to the hardware device is determined based on the risk weight coefficient and the risk level corresponding to each risk factor sub-data.

4. The method according to claim 1, characterized in that, The process of determining the target security configuration based on the target risk level includes: Obtain the correlation between risk levels and security configurations; The target security configuration is determined based on the aforementioned comparison relationship and the target risk level.

5. The method according to claim 4, characterized in that, The process of determining the target security configuration based on the comparison relationship and the target risk level includes: Determine the risk level range for the target risk level; If the risk level range is the first risk level range or the third risk level range, then find the target security configuration corresponding to the target risk level from the comparison relationship; If the risk level range is the second risk level range, then the upgrade preference setting is obtained, and the target security configuration corresponding to the risk level range and the upgrade preference setting is found in the comparison relationship. The risk level corresponding to the first risk level range is less than the risk level corresponding to the second risk level range, and the risk level corresponding to the second risk level range is less than the risk level corresponding to the third risk level range.

6. The method according to claim 1, characterized in that, Before obtaining risk factor data from the hardware device to be upgraded, the method further includes: Receive a first zero-knowledge proof sent by the hardware device to be upgraded, the first zero-knowledge proof being generated based on private input information, public input information, and a proof key; The validity of the first zero-knowledge proof is verified based on the verification key and the public input information. If the first zero-knowledge proof is verified to be valid, a first authorization token is returned and risk factor data is obtained from the hardware device to be upgraded. The first authorization token is used to indicate that the hardware device is eligible for upgrade.

7. The method according to claim 1, characterized in that, The method further includes: Obtain commitment information corresponding to the upgrade file from the cloud server; the commitment information includes the hash value or digest information of the upgrade file. Send the commitment information and upgrade file to the hardware device; Receive the second zero-knowledge proof sent by the hardware device after verifying the validity of the commitment information; If the second zero-knowledge proof is verified to be valid, a second authorization token is returned, which is used to instruct the hardware device to upgrade the firmware based on the upgrade file; Receive the third zero-knowledge proof sent by the hardware device; If the third zero-knowledge proof is verified to be valid, the third zero-knowledge proof is sent to the cloud server. The third zero-knowledge proof is used by the cloud server to update the device status record of the hardware device and to indicate that the upgrade is complete.

8. A data transmission device, characterized in that, Applied to the server side, including: The acquisition module is used to acquire risk factor data from the hardware device to be upgraded, and the risk factor data is used to assess the risk level of transmitting the upgrade file corresponding to the hardware device; The determination module is used to determine the target risk level of transmitting the upgrade file corresponding to the hardware device based on the risk factor data; The determining module is further configured to determine the target security configuration based on the target risk level; The sending module is used to send the upgrade file obtained from the cloud server to the hardware device according to the target security configuration.

9. A data transmission system, characterized in that, The system includes: hardware devices, applications, and cloud servers; The hardware device is used to send risk factor data to the application, and the risk factor data is used to assess the risk level of transmitting the upgrade file corresponding to the hardware device. The application is used to determine the target risk level for transmitting the upgrade file corresponding to the hardware device based on the risk factor data; determine the target security configuration based on the target risk level; and send the upgrade file obtained from the cloud server to the hardware device according to the target security configuration. The cloud server is used to send the upgrade file to the application.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, The processor executes the computer program to implement the method as described in any one of claims 1-7.

11. A computer-readable storage medium having a computer program stored thereon, characterized in that, The program is executed by a processor to implement the method as described in any one of claims 1-7.