Authorization methods, apparatus, equipment and computer storage media for over-the-air download services

Abstract

This application discloses an authorization method, apparatus, device, and computer storage medium for over-the-air (OTA) download services. It encrypts the original authorization file based on an encrypted authorization file structure to generate an encrypted authorization file, which is then sent to the host machine for authorization verification, thereby improving the security of the authorization file. According to embodiments of this application, compared to authorization using text or JSON format, it offers higher security. Compared to hardware dongles, it eliminates the need for hardware dongle storage and the need to burn authorization information, making it easier to implement. Compared to authorization using a single-key encryption algorithm, it uses salted encryption to encrypt the original authorization file, making it more difficult to crack. Furthermore, by adding a signature encryption block, the authorization file can be further verified through signature verification, effectively preventing tampering and further enhancing its security.

Description

TECHNICAL FIELD

[0001] The application belongs to the technical field of over-the-air download, and particularly relates to an authorization method, device and equipment of over-the-air download service and a computer storage medium. BACKGROUND

[0002] With the increasing popularity of OTA (Over-the-Air Technology) and containerization technology, many OTA host computers run OTA services in the form of containers. In order to improve data security, the host computer needs to be authorized before running the OTA service.

[0003] The existing authorization methods mainly include authorization by using authorization text in the form of text or Json, authorization by using a hardware encryption lock, and authorization by using a single key encryption algorithm. Among them, when the authorization text is used for authorization, the authorization file is easy to be captured and tampered with, and the security is too low. Although the use of a hardware encryption lock improves the security of the authorization file, in the virtual machine environment of a docker container, the authorization information burned in the hardware encryption lock cannot be directly obtained, and the authorization information in the hardware encryption lock needs to be burned into the hardware lock storage space by additional mounting of the hardware lock storage space. Because the authorization information needs to be re-burned, it is too cumbersome and not easy to implement. When the single key encryption algorithm is used for authorization, it is easy to be cracked by computer brute force, and the security is low.

[0004] Therefore, there is a need for an over-the-air download service authorization method with higher security and easier implementation. SUMMARY

[0005] The embodiments of the application provide an over-the-air download service authorization method, device, equipment and computer storage medium, which can improve the security of the authorization file.

[0006] In a first aspect, the embodiments of the application provide an over-the-air download service authorization method, which comprises the following steps.

[0007] Obtaining a configured original authorization file and an encrypted authorization file structure, wherein the encrypted authorization file structure comprises an encrypted block type, an encrypted block order and an encrypted block corresponding bit number contained in the encrypted authorization file, the encrypted block type comprises a random key encrypted block, a password salt encrypted block and a signature encrypted block,

[0008] Generating a first random number and a second random number according to the bit number of the random key encrypted block and the bit number of the password salt encrypted block,

[0009] Encrypting the original authorization file by using the salted encryption mode with the first random number and the second random number as the key and the password salt respectively to obtain an encrypted authorization file block,

[0010] The first and second random numbers are encrypted separately to obtain a random key encryption block and a password salt encryption block.

[0011] The original authorization file is signed using a preset signature algorithm to obtain a signed encrypted block.

[0012] Based on the order of the encrypted blocks, the obtained random key encrypted block, password salt encrypted block, and signature encrypted block are combined to obtain the combined encrypted block.

[0013] The file header, combined encryption blocks, and encryption license file blocks are sequentially synthesized into an encryption license file based on the file byte stream. The file header contains a description field that specifies the types of encryption blocks, their order, and the bit width of each encryption block.

[0014] Send an encrypted authorization file to the host machine running the over-the-air download service.

[0015] As one possible implementation, the encryption block type also includes a confused key encryption block. Before obtaining the combined encryption block, the method further includes combining the obtained random key encryption block, cryptographic salt encryption block, signature encryption block, and encrypted authorization file block according to the encryption block order.

[0016] A third random number is generated based on the number of bits in the encryption block of the obfuscated key.

[0017] The third random number is encrypted to obtain a confused key encryption block.

[0018] Based on the order of the encrypted blocks, the obtained random key encrypted block, cryptographic salt encrypted block, signature encrypted block, and encrypted authorization file block are combined to obtain a combined encrypted block, including:

[0019] Based on the order of the encryption blocks, the obtained random key encryption block, obfuscated key encryption block, cryptographic salt encryption block, signature encryption block, and encrypted authorization file block are combined to obtain a combined encryption block.

[0020] As one possible implementation, the first and second random numbers are used as the key and password salt, respectively, and the original license file is encrypted using salted encryption to obtain an encrypted license file block, including:

[0021] The first and second random numbers are used as the key and password salt, respectively, and the original authorization file is encrypted using the PBKDF2 algorithm to obtain the encrypted authorization file block.

[0022] As one possible implementation, the first and second random numbers are used as the key and password salt, respectively, and the original license file is encrypted using salted encryption to obtain an encrypted license file block, including:

[0023] According to the pre-configured data block segmentation rules, the original license file is divided into multiple sub-data blocks.

[0024] The first and second random numbers are used as the key and password salt, respectively. Multiple sub-data blocks are then encrypted using salted encryption to obtain multiple encrypted sub-data blocks.

[0025] Generate an encrypted authorization file block based on multiple encrypted sub-data blocks.

[0026] As one possible implementation, the method further includes the following steps before generating the encrypted authorization file block from multiple encrypted sub-data blocks:

[0027] Generate the hash value for each sub-data block separately.

[0028] An encrypted authorization file block is generated based on multiple encrypted sub-data blocks, including:

[0029] For each encrypted sub-block within a plurality of encrypted sub-blocks, append the corresponding hash value to the end of the encrypted sub-block.

[0030] Multiple encrypted sub-data blocks with hash values ​​appended to their ends are combined to form an encrypted authorization file block.

[0031] As one possible implementation, the original license file includes hardware verification information and software verification information.

[0032] Hardware inspection information includes verification information for multiple hardware inspection items.

[0033] The software verification information includes verification information for multiple software verification items.

[0034] As one possible implementation, the original license file uses a binary byte stream format.

[0035] As one possible implementation, in the case of a host machine running an over-the-air download service, the method includes:

[0036] Utilize the over-the-air application service container on the host machine to obtain the encrypted authorization file.

[0037] The header of the encryption authorization file is parsed to obtain descriptive fields that indicate the types, order, and bit lengths of the encryption blocks contained within the file. These block types include random key encryption blocks, cryptographic salt encryption blocks, signature encryption blocks, and encryption authorization file blocks.

[0038] Based on the description fields, obtain the random key encryption block, password salt encryption block, signature encryption block, and encryption authorization file block from the encryption authorization file, respectively.

[0039] Decrypt the random key encryption block and the password salt encryption block respectively to obtain the corresponding first random number and second random number.

[0040] The encrypted authorization file block is decrypted using the first and second random numbers to obtain the original authorization file.

[0041] The original authorization file is verified by using a signature encryption block.

[0042] In response to the original license file passing signature verification, the host machine is then authorized using the original license file.

[0043] As one possible implementation, the encrypted authorization file block includes multiple encrypted sub-data blocks. The encrypted authorization file block is decrypted using a first random number and a second random number to obtain the original authorization file, including:

[0044] Using a first random number and a second random number, the encrypted sub-data blocks within multiple encrypted sub-data blocks are decrypted block by block to obtain the corresponding sub-data blocks.

[0045] In response to the failure to decrypt any encrypted sub-data block, it was determined that the host authorization verification failed.

[0046] In response to the successful decryption of multiple encrypted sub-data blocks, the decrypted sub-data blocks are merged into the original license file.

[0047] As one possible implementation, a hash value corresponding to the corresponding sub-data block is appended to the end of the encrypted sub-data block. The encrypted sub-data blocks are then decrypted block by block to obtain the corresponding sub-data block, including:

[0048] For each of the multiple encrypted sub-data blocks, decrypt the encrypted sub-data block.

[0049] In response to obtaining the sub-data block corresponding to the encrypted sub-data block through decryption, the hash value appended to the end of the encrypted sub-data block is used to verify the sub-data block.

[0050] Upon successful verification of the sub-data block, it is determined that the encrypted sub-data block has been successfully decrypted.

[0051] If the corresponding sub-data block is not obtained through decryption, or the sub-data block fails verification, it is determined that the decryption of the encrypted sub-data block has failed.

[0052] As one possible implementation, the original license file includes hardware verification information and software verification information. The hardware verification information includes verification information for multiple hardware verification items, and the software verification information includes verification information for multiple software verification items. The original license file is used to perform license verification on the host machine, including:

[0053] The verification information of multiple hardware verification items in the hardware verification information is matched one by one with the corresponding hardware information obtained from the over-the-air application service container to verify the hardware environment of the over-the-air service.

[0054] The verification information of multiple software verification items in the software verification information is matched one by one with the corresponding software information obtained from the over-the-air application service container in order to verify the software information of the over-the-air service.

[0055] In response to any mismatch between the verification information of any hardware verification item and the corresponding hardware information, and / or any mismatch between the verification information of any software verification item and the corresponding software information, the authorization verification is determined to have failed, and an error message is displayed indicating that the verification item is abnormal.

[0056] If the verification information for all hardware verification items matches the corresponding hardware information, and the verification information for all software verification items matches the corresponding software information, the authorization verification is deemed successful and the over-the-air download service is started.

[0057] As one possible implementation, the original license file is in binary byte stream format. Before using the original license file to verify the license on the host machine, the method also includes:

[0058] The original license file is converted to a usable license file.

[0059] Perform authorization verification on the host machine using the original license file, including:

[0060] Use an operable license file to perform license verification on the host machine.

[0061] As one possible implementation, after verifying the authorization on the host machine using the original license file, the method includes:

[0062] Check if the authorization verification time has been reached.

[0063] In response to the arrival of the authorization verification time, the host machine is re-verified using the original authorization file.

[0064] As one possible implementation, detecting whether the authorization verification time has been reached includes:

[0065] Check if the preset timer has reached the preset timeout period.

[0066] In response to the timer reaching its set time, determine the timer's authorization verification time.

[0067] As one possible implementation, the random key encryption block and the cryptographic salt encryption block are decrypted separately, including:

[0068] The random key encryption block and the password salt encryption block are decrypted in parallel.

[0069] Secondly, embodiments of this application also provide an authorization device for over-the-air download services, the device comprising:

[0070] The configuration information acquisition module is used to acquire the original license file and the encrypted license file structure. The encrypted license file structure indicates the types of encrypted blocks, the order of the encrypted blocks, and the corresponding bit length of the encrypted blocks. The types of encrypted blocks include random key encrypted blocks, cryptographic salt encrypted blocks, and signature encrypted blocks.

[0071] The random number generation module is used to generate a first random number and a second random number based on the number of bits in the random key encryption block and the number of bits in the password salt encryption block, respectively.

[0072] The authorization file encryption module uses a first random number and a second random number as the key and a password salt, respectively, to encrypt the original authorization file using a salting encryption method, resulting in an encrypted authorization file block.

[0073] The random number encryption module is used to encrypt the first random number and the second random number respectively to obtain a random key encryption block and a password salt encryption block.

[0074] The signature module is used to sign the original authorization file using a preset signature algorithm to obtain a signed encrypted block.

[0075] The combined encryption block module is used to combine the obtained random key encryption block, cryptographic salt encryption block, and signature encryption block according to the encryption block order to obtain a combined encryption block.

[0076] The encryption license file generation module is used to sequentially synthesize an encryption license file based on a file byte stream, consisting of a file header, combined encryption blocks, and encryption license file blocks. The file header contains a description field that specifies the types of encryption blocks, their order, and the bit width of each encryption block.

[0077] The sending module is used to send encrypted authorization files to the host machine running the over-the-air download service.

[0078] Fourthly, embodiments of this application also provide an electronic device, characterized in that the device includes: a processor and a memory storing computer program instructions.

[0079] When the processor executes the computer program instructions, it implements the authorization method for the over-the-air download service as described in the first aspect.

[0080] In a sixth aspect, embodiments of this application also provide a computer-readable storage medium, characterized in that the computer-readable storage medium stores computer program instructions, which, when executed by a processor, implement the authorization method for the over-the-air download service as described in the first aspect.

[0081] Fifthly, embodiments of this application also provide a computer program product, characterized in that, when the instructions in the computer program product are executed by the processor of an electronic device, the electronic device performs the authorization method for the over-the-air download service as described in the first aspect.

[0082] The authorization method, apparatus, device, and computer storage medium for over-the-air download services in this application embodiment encrypt the original authorization file based on an encrypted authorization file structure to generate an encrypted authorization file. This encrypted authorization file is then sent to the host machine for authorization verification, thereby improving the security of the authorization file. According to this application embodiment, compared to authorization using text or JSON format, this method offers higher security. Compared to hardware encryption locks, it eliminates the need for hardware lock storage space and the burning of authorization information, making it easier to implement. Compared to authorization using a single-key encryption algorithm, salting encryption of the original authorization file makes it more difficult to crack. Furthermore, by adding a signature encryption block, the authorization file can be further verified through signature verification, effectively preventing tampering and further enhancing the security of the authorization file. Attached Figure Description

[0083] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments of this application will be briefly introduced below. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0084] Figure 1 This is a schematic diagram of an OTA remote upgrade scenario provided in one embodiment of this application;

[0085] Figure 2 This is a flowchart illustrating an embodiment of the authorization method for an over-the-air download service provided in this application;

[0086] Figure 3 This is a schematic diagram illustrating the determination of the order of encrypted blocks according to an embodiment of this application;

[0087] Figure 4 This is a schematic diagram of the structure of an encrypted authorization file block provided in one embodiment of this application;

[0088] Figure 5 This is a schematic diagram of the structure of an encrypted authorization file provided in one embodiment of this application;

[0089] Figure 6 This is a flowchart illustrating an authorization method for an over-the-air download service provided in another embodiment of this application;

[0090] Figure 7 This is a schematic diagram of the overall process of host machine decryption of encrypted authorization file and verification of whether OTA service meets the verification items, provided in one embodiment of this application;

[0091] Figure 8 This is a schematic diagram of an authorized system provided in one embodiment of this application;

[0092] Figure 9 This is a schematic diagram of the configuration interface of a REST interface provided in one embodiment of this application;

[0093] Figure 10 This is a schematic diagram of the structure of the original license document provided in one embodiment of this application;

[0094] Figure 11 This is a schematic diagram of an authorization device for an over-the-air download service provided in one embodiment of this application;

[0095] Figure 12 This is a schematic diagram of an authorization device for an over-the-air download service provided in another embodiment of this application;

[0096] Figure 13 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0097] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are only intended to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0098] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0099] Given that existing OTA service authorization methods suffer from low security and difficulty in implementation, this application provides a novel authorization method, apparatus, device, storage medium, and program for over-the-air (OTA) download services, which can be applied to OTA remote upgrade scenarios to authorize OTA services.

[0100] See Figure 1 This is a schematic diagram of an OTA remote upgrade scenario provided in an embodiment of this application, as shown below. Figure 1 As shown, it includes: a host machine 110 running the OTA service and an OTA cloud server 120, a communication connection between the host machine 110 and the OTA cloud server 120, and the OTA cloud server 120 providing the host machine 110 with the relevant content required for the upgrade.

[0101] The host machine 110 contains an OTA application service container, within which the OTA service runs. The host machine 110 can be a computer, server, vehicle controller, or other similar device.

[0102] In this embodiment, the OTA cloud server 120 can provide an encrypted authorization file, and the OTA service in the host machine 110 has embedded code blocks that can parse the encrypted authorization file. The actual OTA operating environment depends on the encrypted authorization file; all information in the authorization file must be verified before the OTA service in the host machine 110 can operate normally.

[0103] The following describes the authorization method for the over-the-air download service provided in the embodiments of this application, taking the OTA cloud server and the host machine as the execution entities respectively.

[0104] See Figure 2 This is a flowchart illustrating an authorization method for an over-the-air (OTA) download service provided in an embodiment of this application, which can be executed by an OTA cloud server. Figure 2As shown, the authorization method for the over-the-air download service provided in this application embodiment may include the following steps:

[0105] S21. Obtain the original license file and encrypted license file structure of the configuration.

[0106] The original license file is the file ultimately used to verify the license on the host machine. The structure of the encrypted license file includes the types of encrypted blocks, the order of the encrypted blocks, and the corresponding bit length of each encrypted block. The types of encrypted blocks include random key encrypted blocks, cryptographic salt encrypted blocks, signature encrypted blocks, and encrypted license file blocks. The order of the encrypted blocks refers to their relative positions within the encrypted license file, and the bit length of each encrypted block refers to the number of bits it occupies.

[0107] In this embodiment of the application, step S21 can be performed if it is determined that an encrypted authorization file needs to be generated.

[0108] In one example, upon receiving an authorization issuance request or authorization update request from the host machine running the over-the-air (OTA) download service, it can be determined that an encrypted authorization file needs to be generated. The authorization issuance request instructs the OTA cloud server to issue an encrypted authorization file to the host machine, while the authorization update request instructs the OTA cloud server to update the encrypted authorization file issued to the host machine.

[0109] In one example, it can also be determined that an encrypted license file needs to be generated if the user inputs an instruction to generate an encrypted license file.

[0110] S22. Generate a first random number and a second random number based on the number of bits in the random key encryption block and the number of bits in the password salt encryption block, respectively.

[0111] Specifically, the number of bits in the random key encryption block is determined based on the structure of the encryption authorization file, and a first random number is generated based on this number of bits.

[0112] The number of bits in the cryptographic salt encryption block is determined based on the structure of the encryption authorization file, and a second random number is generated based on this number of bits.

[0113] In one example, an OTA cloud server may have a pre-configured random number generator, which can be used to generate a first random number and a second random number.

[0114] S23. Using the first random number and the second random number as the key and password salt respectively, the original license file is encrypted using salting encryption to obtain the encrypted license file block.

[0115] When encrypting the original license file, the first random number is used as the key and the second random number is used as the password salt. The key and password salt are used to generate a salting key, and the original license file is encrypted using the salting key, thereby achieving salting encryption of the original license file.

[0116] In this embodiment, the original authorization file is encrypted using salting encryption, which effectively increases the difficulty for attackers to crack it and improves the security of the authorization file.

[0117] S24. Encrypt the first random number and the second random number respectively to obtain a random key encryption block and a password salt encryption block.

[0118] Among them, the random key encryption block and the password salt encryption block are used to decrypt the encrypted authorization file block after decryption.

[0119] When encrypting the first and second random numbers, a preset encryption algorithm can be obtained. The first random number is then encrypted using this preset algorithm to obtain a random key encryption block. The second random number is then encrypted using the same preset algorithm to obtain a password salt encryption block.

[0120] In this embodiment, when encrypting the original authorization file, a pre-negotiated key is not used; instead, random numbers are used for encryption, which greatly increases the difficulty of decryption. Furthermore, by encrypting the first and second random numbers, the random key encryption block and the password salt encryption block must be decrypted before the original authorization file can be decrypted. This is equivalent to applying double encryption to the original authorization file, thereby further enhancing the security of the authorization file.

[0121] S25. Sign the original authorization file using a preset signature algorithm to obtain a signed encrypted block.

[0122] The signature encryption block is used to verify the integrity of the original authorization file after decryption.

[0123] The default signature algorithm can be set by the user according to the actual request.

[0124] S26. According to the order of the encryption blocks, combine the obtained random key encryption block, password salt encryption block and signature encryption block to obtain a combined encryption block.

[0125] After obtaining the random key encryption block, the password salt encryption block, and the signature encryption block, the obtained multiple encryption blocks are sorted and combined according to the order of the encryption blocks to obtain the combined encryption block.

[0126] S27. Combine the file header, combined encryption block, and encryption authorization file block into an encryption authorization file in sequence based on the file byte stream.

[0127] The file header contains a description field, which describes the types of encryption blocks, their order, and the bit length of each encryption block in the encryption authorization file.

[0128] The file byte stream is arranged in the following order: file header + combined encryption block + encryption authorization block. That is, the file header is at the top, the encryption authorization block is at the bottom, and the combined encryption block is in the middle.

[0129] S28. Send an encrypted authorization file to the host machine running the over-the-air download service.

[0130] The generated encrypted authorization file is sent to the host machine running the over-the-air download service. The host machine can then obtain the encrypted authorization file, decrypt it to obtain the original authorization file, and then perform authorization verification based on the original authorization file.

[0131] This application provides an authorization method for over-the-air (OTA) download services. It encrypts the original authorization file based on an encrypted authorization file structure to generate an encrypted authorization file, which is then sent to the host machine running the OTA service for authorization verification, thereby improving the security of the authorization file. According to this application, compared to authorization using text or JSON format, this method offers higher security. Compared to hardware dongles, it eliminates the need for hardware dongle storage and burning authorization information, making it easier to implement. Compared to single-key encryption, salting the original authorization file makes it more difficult to crack. Furthermore, by adding a signature encryption block, the authorization file can be further verified through signature verification, effectively preventing tampering and further enhancing its security.

[0132] In some embodiments, the encryption block type of the encryption authorization file may also include a confused key encryption block. Accordingly, before step S26 above, the following steps may be performed first:

[0133] A third random number is generated based on the number of bits in the obfuscated key encryption block. The third random number is then encrypted to obtain the obfuscated key encryption block.

[0134] The third random number can also be generated using a random number generator.

[0135] The third random number can be encrypted using a preset encryption algorithm, which can be the same encryption algorithm used when encrypting the first random number.

[0136] Based on this, the specific implementation method of step S26 above is as follows:

[0137] Based on the order of the encryption blocks, the obtained random key encryption block, obfuscated key encryption block, cryptographic salt encryption block, and signature encryption block are combined to obtain a combined encryption block.

[0138] Thus, the final generated encrypted authorization file contains a file header, a random key encryption block, a confusion key encryption block, a password salt encryption block, a signature encryption block, and an encrypted authorization file block.

[0139] According to this embodiment, by adding a confusion key encryption block to the encrypted authorization file, it can be confused with the random key encryption block, thereby increasing the difficulty of deciphering the encrypted authorization file and improving the security of the authorization file.

[0140] In some embodiments, step S21 above requires obtaining the configured original license file and encrypted license file structure. Therefore, before step S21 above, the original license file and encrypted license file structure can be configured first.

[0141] The types of encryption blocks and the corresponding bit lengths of the encryption blocks contained in the original authorization file and the encrypted authorization file can be dynamically configured by the user according to the actual situation. The order of the encryption blocks can be obtained by the OTA cloud server based on the ID (Identity document) of the application service container downloaded over the air in the host machine, i.e., the OTA service container.

[0142] In one example, when configuring the order of encrypted blocks, a preset command for obtaining the container ID can be used to obtain the ID of the OTA service container on the host machine. Then, the largest N characters are taken from the ID string of the OTA service container in sequence and converted into the order of encrypted blocks accordingly. The value of N is the number of types of encrypted blocks contained in the encryption authorization file. If the types of encrypted blocks include random key encrypted blocks, obfuscated key encrypted blocks, cryptographic salt encrypted blocks, and signature encrypted blocks, then the value of N is 4.

[0143] For example Figure 3 As shown, taking the encryption block types including random key encryption block, obfuscated key encryption block, cryptographic salt encryption block and signature encryption block as an example, when the OTA service container ID obtained by the command release-deploy / backend / keys / verify#docker ps is b0648f566803, the 4 characters extracted from it are b / 6 / 8 / f. These 4 characters are then converted to C / A / B / D, which means that the order of the encryption blocks is cryptographic salt encryption block - random key encryption block - obfuscated key encryption block - signature encryption block.

[0144] This embodiment enables dynamic configuration of the original authorization file and encrypted authorization file structure. The order of multiple encrypted blocks is obtained by calculating the ID of the OTA service container, making the specific file arrangement order relatively hidden.

[0145] In some embodiments, the specific implementation of step S23 above may include:

[0146] The second random number is used as the password salt to form a key string with the first random number. The original authorization file is then encrypted using the PBKDF2 algorithm to obtain the encrypted authorization file block.

[0147] The PBKDF2 algorithm works by adding a cryptographic salt to a hash algorithm and performing multiple iterative hash operations to obtain the final salted key. Encryption is then performed using this salted key, significantly increasing the difficulty of cracking the algorithm. When using the PBKDF2 algorithm, either SHA1 or SHA256 hash algorithms are typically chosen.

[0148] In one example, the user sets the number of iterations according to the actual situation, inputs the key (i.e., the first random number), the password salt (i.e., the second random number), and the number of iterations into the PBKDF2 algorithm. The PBKDF2 algorithm performs a hash operation on the key and the password salt, and then uses the result as the new password salt to perform a hash operation with the key again. This process is repeated multiple times until the number of iterations is reached to generate the final salted key. The salted key is then used to encrypt the original authorization file to obtain the encrypted authorization file block.

[0149] In this embodiment, the PBKDF2 algorithm is used to encrypt the original authorized file. Compared with the salted key generated by simply concatenating the key with the password salt, the salted key generated by the PBKDF2 algorithm is more difficult to crack, and the encrypted file is therefore more secure.

[0150] In some embodiments, the specific implementation of step S23 above may further include:

[0151] According to the pre-configured data block segmentation rules, the original authorization file is divided into multiple sub-data blocks. The first and second random numbers are used as the key and password salt, respectively. The multiple sub-data blocks are encrypted using salting encryption to obtain multiple encrypted sub-data blocks. An encrypted authorization file block is generated based on the multiple encrypted sub-data blocks.

[0152] The data block partitioning rules can include the size of the sub-data blocks. Based on this, the original license file can be divided into multiple sub-data blocks of the same size according to the data partitioning rules.

[0153] In one example, the size of the sub-data block can be pre-configured by the user in the OTA cloud server according to the actual situation, which makes the block partitioning highly flexible.

[0154] In this embodiment, by dividing the original license file into multiple sub-data blocks and encrypting each sub-data block separately, the encrypted sub-data blocks can be decrypted block by block when the encrypted license file blocks are decrypted in the future. If the decryption of an encrypted sub-data block fails, the decryption failure can be directly determined without having to decrypt other undecrypted encrypted sub-data blocks, which is more efficient.

[0155] In some embodiments, the specific implementation of step S23 above may further include:

[0156] Before generating an encrypted authorization file block from multiple encrypted sub-data blocks, a hash value for each sub-data block can be generated separately. For each encrypted sub-data block in the multiple encrypted sub-data blocks, the corresponding hash value is added to the end of the encrypted sub-data block. Then, multiple encrypted sub-data blocks with hash values ​​added to the end are combined to form an encrypted authorization file block.

[0157] The hash value of each sub-data block can be obtained by hashing the sub-data block. Specifically, a hash function can be pre-defined for hashing the sub-data blocks, and the hash value of the sub-data block can be obtained by using the hash function. The hash function used can be the cryptographic hash function SHA256.

[0158] For example Figure 4 The diagram shown is a structural schematic of an encrypted authorization file block provided in an embodiment of this application. The hash value of the sub-data block is taken as the SHA256 value calculated using SHA256, for example... Figure 4 As shown, each encrypted sub-data block is appended with a corresponding SHA256 value, where the original block refers to the unencrypted sub-data block. Multiple encrypted sub-data blocks with appended SHA256 values ​​together form the encrypted authorization file block.

[0159] In this embodiment, when generating the encrypted authorization file block, a corresponding hash value is added to the end of each encrypted sub-data block. This allows for real-time verification and comparison of each decrypted sub-data block using the corresponding hash value during decryption. This enables timely detection of sub-data blocks that are inconsistent with the original data, allowing the decryption process to end promptly without having to complete all decryption steps before determining decryption failure.

[0160] In some embodiments, the specific implementation of step S24 above may include:

[0161] The first random number is encrypted using the RSA asymmetric encryption algorithm with a preset OTA service public key to obtain a random key encryption block.

[0162] The second random number is encrypted using the DES (Data Encryption Standard) symmetric encryption algorithm to obtain a password salt encryption block.

[0163] In one example, the OTA service public key and OTA service private key used by the RSA asymmetric encryption algorithm can be negotiated in advance by the OTA cloud server and the host machine running the over-the-air download service (hereinafter referred to as the host machine). After negotiation, the OTA service public key is stored in the OTA cloud server and used to encrypt the first random number, and the OTA service private key is stored in the host machine and used to decrypt the random key encryption block encrypted with the OTA service public key.

[0164] In one example, the key used by the DES symmetric encryption algorithm can be negotiated in advance by the OTA cloud server and the host machine running the over-the-air download service (hereinafter referred to as the host machine). After negotiation, the negotiated key is stored in the OTA cloud server and the host machine respectively. The OTA cloud server uses the key to encrypt the second random number, and the host machine can use the key to decrypt the cryptographic salt encryption block used to encrypt with the key.

[0165] In this embodiment, the first random number and the second random number are encrypted using different encryption algorithms. This achieves hybrid encryption using multiple encryption algorithms. Compared with using a single encryption algorithm, hybrid encryption can effectively increase the difficulty of decryption, thereby improving the security of the authorized file.

[0166] In some embodiments, the specific implementation of step S25 above may include:

[0167] The original authorization file is signed using the ECDSA digital signature algorithm, also known as the elliptic curve digital signature algorithm, to obtain a signed encrypted block.

[0168] The ECDSA digital signature algorithm is an analog of the Digital Signature Algorithm (DSA) using elliptic curve cryptography (ECC).

[0169] In this implementation, the ECDSA digital signature algorithm is used to sign the original authorization document. This ensures that, given the public key, the corresponding private key cannot be derived. Furthermore, it allows for the proof that an object possesses a private key corresponding to a public key, without exposing any information about the private key during this process. Therefore, using the ECDSA digital signature algorithm effectively improves data security.

[0170] In some embodiments, the original license file obtained in step S21 above may include hardware verification information and software verification information, wherein the hardware verification information includes verification information of multiple hardware verification items, and the software verification information includes verification information of multiple software verification items.

[0171] The specific hardware and software verification items can be configured by the user according to the actual situation.

[0172] In one example, taking the host machine as the vehicle controller, hardware verification items may include the authorized start and end time, motherboard number, container address, number of replicas, etc., while software verification items may include the number of vehicles, number of parts, number of activities, number of OTA users, etc.

[0173] In this embodiment, by adding hardware verification information and software verification information to the original license file, it is possible to verify the hardware and software in the host machine based on the original license file.

[0174] In some embodiments, the original license file obtained in step S21 above may be in binary byte stream format, i.e., protobuf format.

[0175] In this embodiment, serializing the original license file using the protobuf binary byte stream format can reduce the readability of the original license file and improve transmission performance.

[0176] For ease of understanding, see [link to relevant documentation]. Figure 5 This is a schematic diagram of the structure of an encrypted authorization file provided in an embodiment of this application, as shown below. Figure 5 As shown, it includes a file header, a combined encryption block, and an encrypted authorization file block. The order of the encryption blocks in the combined encryption block is as follows: random key encryption block A, signature encryption block D, password salt encryption block C, and obfuscated key encryption block B.

[0177] Figure 5 The document also shows the structure of the file header, such as... Figure 5 As shown, the file header contains the content A032 D684C016 B032 F512 K, which means that block A is 32 bits long, block D is 684 bits long, block C is 16 bits long, and block B is 32 bits. The original license file is divided and encrypted in 512kb blocks. ADCB represents the order of the encrypted blocks within the encrypted license file.

[0178] The above describes the authorization method for over-the-air download services executed by OTA cloud servers. As long as it involves encrypting the original authorization file, the host machine that receives the encrypted authorization file can perform authorization verification based on the encrypted authorization file after the encrypted authorization file is generated. The following describes the authorization method for over-the-air download services executed by the host machine running the OTA service, which mainly involves decrypting the encrypted authorization file.

[0179] See Figure 6 This is a flowchart illustrating an authorization method for an over-the-air (OTA) download service provided in an embodiment of this application, which can be executed by the host machine running the OTA service. Figure 6 As shown, the authorization method for the over-the-air download service provided in this application embodiment may include the following steps:

[0180] S61. Use the over-the-air download application service container in the host machine to obtain the encrypted authorization file.

[0181] The OTA service on the host machine runs in an over-the-air application download service container.

[0182] When authorization verification is required, the over-the-air (OTA) application service container on the host machine is started. The encrypted authorization file is obtained and parsed by the running OTA service through container Docker volume mapping.

[0183] After generating the encrypted authorization file, the OTA cloud server sends the encrypted authorization file to the host machine. After receiving the encrypted authorization file sent by the OTA cloud server, the host machine can pre-install the encrypted authorization file in a specified directory. In this way, when starting the over-the-air download application service container, the host machine can directly obtain it from the specified directory.

[0184] By pre-installing the encrypted license file in a specified directory, the encrypted license file can be easily replaced, enabling OTA services to be stopped / renewed and other operations.

[0185] S62. Parse the header of the encryption license file to obtain a description field that describes the type of encryption blocks, the order of encryption blocks, and the bit length of the encryption blocks contained in the encryption license file.

[0186] The types of encryption blocks include random key encryption blocks, cryptographic salt encryption blocks, signature encryption blocks, and encrypted authorization file blocks.

[0187] The host machine can be pre-configured with a decryption module for decrypting encrypted license files. After obtaining the encrypted license file, the pre-configured decryption module can be used to decrypt it.

[0188] S63. According to the description field, obtain the random key encryption block, the password salt encryption block, the signature encryption block and the encryption authorization file block from the encryption authorization file respectively.

[0189] By calculating the number of bits and the order of each block in the encryption authorization file, the start and end positions of each block in the encryption authorization file can be determined. Thus, based on the start and end positions, the corresponding parts can be extracted from the encryption authorization file to obtain the random key encryption block, the cryptographic salt encryption block, the signature encryption block, and the encryption authorization file block.

[0190] S64. Decrypt the random key encryption block and the password salt encryption block respectively to obtain the corresponding first random number and second random number.

[0191] The host machine knows in advance the encryption algorithm used for the first and second random numbers and has stored the corresponding decryption key, so it can directly use the pre-stored key to decrypt.

[0192] For example, if the first random number is encrypted using the RSA asymmetric encryption algorithm with the OTA service public key, the host machine can directly decrypt the random key encryption block using the pre-stored OTA service private key.

[0193] The first random number can be obtained by decrypting the random key encryption block, and the second random number can be obtained by decrypting the password salt encryption block.

[0194] S65. Use the first random number and the second random number to decrypt the encrypted authorization file block to obtain the original authorization file.

[0195] Similarly, the host machine knows the encryption method used for the encrypted license file block. Based on this, it can directly use the corresponding decryption method to decrypt and obtain the original license file.

[0196] S66. Verify the signature of the original authorization file using the signature encryption block.

[0197] The original authorization file obtained in S65 is signed using the same signature algorithm as that used by the OTA cloud server to generate the signature encryption block. The signature result is then compared with the signature encryption block to determine if they are consistent. If they are consistent, the original authorization file is determined to have passed the signature verification; otherwise, the original authorization file is determined to have failed the signature verification.

[0198] S67. In response to the original license file passing signature verification, perform license verification on the host machine using the original license file.

[0199] This application provides an authorization method for over-the-air (OTA) download services. An encrypted authorization file is sent from an OTA cloud server to the host machine and can be obtained and parsed by the OTA service running on the host machine via container-mapped volumes. This allows for dynamic replacement of the encrypted authorization file without requiring a replacement of the OTA service itself. The original authorization file is encrypted using a first random number and a second random number, which are then further encrypted, effectively applying double encryption to the original authorization file and significantly improving its security. Furthermore, after decrypting the original authorization file, a signature verification process is used to further verify its integrity. Authorization verification is then performed based on the original authorization file after the signature verification passes. Compared to existing authorization methods, this method is more secure, easier to implement, and more difficult to crack.

[0200] In some embodiments, the encrypted authorization file block includes multiple encrypted sub-data blocks. Based on this, the specific implementation of step S65 above may include:

[0201] Using a first random number and a second random number, the encrypted sub-data blocks within multiple encrypted sub-data blocks are decrypted block by block to obtain the corresponding sub-data blocks.

[0202] In response to the failure to decrypt any encrypted sub-data block, it was determined that the host authorization verification failed.

[0203] In response to the successful decryption of multiple encrypted sub-data blocks, the decrypted sub-data blocks are merged into the original license file.

[0204] This involves decrypting each encrypted sub-data block in a block-by-block manner, or decrypting the encrypted sub-data blocks in a block-by-block fashion.

[0205] In one example, when decrypting encrypted sub-data blocks one by one in multiple encrypted sub-data blocks, multiple encrypted sub-data blocks can be decrypted in parallel to improve decryption efficiency.

[0206] In this embodiment, each encrypted sub-data block is decrypted block by block. If any encrypted sub-data block fails to decrypt, it is determined that the encrypted authorization file has failed to decrypt, and thus the host authorization verification is directly determined to have failed. At the same time, the decryption of other encrypted sub-data blocks that have not been decrypted is stopped. Compared with the time when all data has been decrypted before the decryption failure can be determined, the verification efficiency is greatly improved.

[0207] In some embodiments, a hash value corresponding to the sub-data block is appended to the end of the encrypted sub-data block. Based on this, step S65 above, when decrypting each encrypted sub-data block in a plurality of encrypted sub-data blocks sequentially to obtain the sub-data block corresponding to each encrypted sub-data block, may include:

[0208] For each of the multiple encrypted sub-data blocks, the encrypted sub-data block is decrypted. In response to obtaining the corresponding sub-data block through decryption, the sub-data block is verified using the hash value added to the end of the encrypted sub-data block. In response to the sub-data block passing the verification, it is determined that the encrypted sub-data block has been successfully decrypted. In response to the sub-data block failing to obtain the corresponding sub-data block through decryption, or the sub-data block failing the verification, it is determined that the encrypted sub-data block has failed to be decrypted.

[0209] Specifically, for each sub-data block, verifying the sub-data block using the hash value appended to the end of the encrypted sub-data block may include using a hash function that is consistent with the hash function used when the OTA cloud server generates the hash value of the sub-data block, performing hash calculation on the decrypted sub-data block to obtain a hash value, comparing the calculated hash value with the hash value appended to the end of the encrypted sub-data block, and determining that the sub-data block passes verification if the two hash values ​​match, otherwise determining that the sub-data block fails verification.

[0210] In this embodiment, verifying the sub-data blocks based on hash values ​​can ensure the accuracy of the sub-data blocks, thereby ensuring the accuracy of the original authorized file obtained after final decryption.

[0211] In some embodiments, the original license file includes hardware verification information and software verification information. The hardware verification information includes verification information for multiple hardware verification items, and the software verification information includes verification information for multiple software verification items. Based on this, the specific implementation of step S67 above may include:

[0212] The hardware verification information is matched one by one with the corresponding hardware information obtained from the over-the-air application service container to verify the hardware environment of the over-the-air service. The software verification information is matched one by one with the corresponding software information obtained from the over-the-air application service container to verify the software information of the over-the-air service. If the verification information of any hardware verification item does not match the corresponding hardware information, and / or the verification information of any software verification item does not match the corresponding software information, the authorization verification is determined to have failed and an error message is displayed. If the verification information of all hardware verification items matches the corresponding hardware information and the verification information of all software verification items matches the corresponding software information, the authorization verification is determined to have passed and the over-the-air service is allowed to run.

[0213] Verifying the software information of the over-the-air download service can include verifying whether the number of operable over-the-air download services is within the authorized actual threshold. For example, if the software verification item includes the number of registered vehicles, then if the number of registered vehicles is less than the number of vehicles configured in the authorization file, it is determined that the number of registered vehicles is within the authorized actual threshold; otherwise, it is determined that the number of registered vehicles is not within the actual threshold.

[0214] The hardware and software information obtained within the over-the-air application service container is the information within the container's Docker system mapped volume.

[0215] This embodiment utilizes Docker system mapped volume information for authorization verification, allowing for seamless comparison of host machine characteristics at runtime code level. Furthermore, by providing alerts for verification anomalies, users can handle exceptions promptly and effectively.

[0216] In some embodiments, the original license file is in binary byte stream format. Based on this, the following steps can be performed before performing step S67 above:

[0217] The original license file is converted to a working license file, which is then used to verify the license on the host machine.

[0218] In one example, if the original license file is a binary byte stream format obtained by serializing it using the protobuf binary byte stream format, then the original license file can be converted to a working license file by deserializing it using protobuf.

[0219] This embodiment ensures the operability of the authorization document.

[0220] In some embodiments, after step S67 described above, the following steps may also be performed:

[0221] Detect whether the authorization verification time has arrived, and in response to the arrival of the authorization verification time, perform authorization verification on the host machine again using the original authorization file.

[0222] In one example, multiple authorization verification times can be preset, and an authorization verification will be performed once each authorization verification time is reached.

[0223] This embodiment enables regular detection / focused monitoring of information in the authorization file, facilitating timely understanding of the host machine's authorization status. Once it is determined that the information does not conform to the authorization file, the OTA service will automatically stop working.

[0224] In some embodiments, a timer and a timed thread checking module can be preset in the host machine. Based on this, the following method can be used to detect whether the authorization verification time has been reached:

[0225] Detect whether the preset timer has reached the preset timeout period, and in response to the timer reaching the timeout period, determine whether the authorization verification time has been reached.

[0226] This method allows for automatic repetition of authorization verification at regular intervals.

[0227] In some embodiments, step S64 above can decrypt the random key encryption block and the password salt encryption block in parallel.

[0228] This embodiment demonstrates that parallel decryption can improve decryption efficiency.

[0229] See Figure 7 This is a schematic diagram illustrating the overall process of decrypting the encrypted authorization file on the host machine and verifying whether the OTA service meets the verification items, as provided in this application embodiment. Figure 7 As shown, it mainly includes the following steps:

[0230] S70: Pre-install / replace encrypted license files.

[0231] Before starting the OTA service, the encrypted authorization file received from the OTA cloud server will be pre-installed in the specified directory.

[0232] S71: OTA service is running.

[0233] The OTA application service container runs on the host machine.

[0234] S72: Decrypt the encrypted authorization file.

[0235] The encrypted authorization file is decrypted using the pre-built decryption module in the OTA application code layer.

[0236] S73: Parse the header of the encrypted authorization file.

[0237] Parse the 21-bit data in the file header to determine the position and length of blocks ABCD and the size of each encrypted sub-data block in the encrypted authorization file block.

[0238] S74: According to the block bit length and order parsed in S73, obtain each encrypted block and encrypted authorization file block in sequence, and decrypt the random key encrypted block and the password salt encrypted block.

[0239] Since the number of bits in each block is fixed, the start and end positions of each block can be calculated directly, and the corresponding part can be extracted directly from the whole file.

[0240] The random key encryption block and the password salt encryption block are decrypted in parallel to prepare for the restoration of the original authorization file.

[0241] S75: Based on the data obtained from decryption in S74, decrypt each encrypted sub-data block in the encrypted authorization file block one by one.

[0242] S76: For encrypted sub-data blocks that have been decrypted, verify the decrypted sub-data blocks; for encrypted sub-data blocks that have failed to be decrypted, terminate the OTA service and exit.

[0243] The decrypted sub-data blocks are verified by matching the hash value, such as the SHA256 value, added to the end of the encrypted sub-data blocks. If they match completely, the block is successfully decrypted; otherwise, decryption fails.

[0244] S77: After decrypting all encrypted sub-data blocks, merge all the decrypted sub-data blocks into the original authorization file and perform signature verification. If the verification is successful, execute S78.

[0245] All sub-data blocks can be merged into a complete original authorization file based on file stream merging, and then digitally signed and verified with the D block.

[0246] S78: Serialize the original license file.

[0247] The original license file is deserialized using protobuf to obtain an operable license file.

[0248] S79: Verify the verification information in the authorization file. If the verification information is inconsistent, the verification is determined to have failed, the OTA service ends and exits, and the user is prompted which verification failed. If all verification information is verified successfully, the OTA service will run normally.

[0249] The hardware verification information in the license file is matched one-to-one with the hardware information obtained from the Docker container in the OTA service runtime environment to ensure that the running hardware environment is correct. The software verification information in the license file is also matched one-to-one with the software information in the OTA service's internal database to ensure that the data operable by the OTA is within the actual authorized threshold (e.g., the number of registered vehicles must be less than the number of vehicles configured in the license file). The system will then notify the user which verification items are abnormal and that the OTA service is unavailable. In this case, the user can request the OTA cloud license server to regenerate a new license file to replace the old one.

[0250] S710: The OTA service's internal timer periodically checks and verifies information.

[0251] The OTA service also has a built-in timed thread check module that repeatedly verifies this information at regular intervals.

[0252] This application provides an authorization system that can implement the above-described authorization method for over-the-air download services, such as... Figure 8 As shown, the authorized system includes a host machine 810 that runs the OTA service and an OTA cloud server 820 that are connected by communication. Hereinafter, the host machine 810 that runs the OTA service will be referred to as host machine 810, and the OTA cloud server 820 will be referred to as cloud server 820.

[0253] like Figure 8 As shown, the cloud server 820 includes an authorization file configuration module, a protobuf serialization module, a certificate private key management module, and an authorization file encryption module.

[0254] The authorization file configuration module is used to configure the relevant information required to generate the encrypted authorization file, such as the original authorization file, the encrypted authorization file structure, and data block segmentation rules. The authorization file configuration module may include a REST interface, allowing users to configure relevant information on the REST interface using testing tools. The configured information will then be transmitted to the cloud server 820 via the REST interface.

[0255] See Figure 9 This is a schematic diagram of the configuration interface when configuring a REST interface using the Postman tool, as provided in an embodiment of this application. Postman is a simple and convenient interface debugging tool with functions such as interface debugging, interface set management, environment configuration, parameterization, assertion, batch execution, interface recording, Mock Server, interface documentation, and interface monitoring.

[0256] like Figure 9 The diagram shown is mainly a schematic of the interface design area in the Postman interface, which mainly includes four functional blocks: "encrypt Type", "checkHwData", "checkOtaData" and a sub-block without a title located between "encrypt Type" and "checkHwData".

[0257] The "encrypt Type" setting configures the bit width of each encryption block included in the encryption license file. A represents a random key encryption block, B represents a confused key encryption block, C represents a cryptographic salt encryption block, and D represents a signature encryption block.

[0258] The block segmentation function is used to configure the data block segmentation rules, where F represents the size of each sub-data block after segmentation, and type represents the unit of data block size.

[0259] "checkHwData" is used to configure the hardware verification information in the original application file. The hardware verification items may include: issuedTime (the start time of the authorization), expireTime (the end time of the authorization), mainBoardSerial (the motherboard number), docker-ip (the container address), copy-num (the number of copies), etc.

[0260] "checkOtaData" is used to configure the software verification information in the original application file. The software verification items may include: vehicleNum (number of vehicles), ecuNum (number of parts), canpaignNum (number of activities), userId (registered user), etc.

[0261] It should be noted that the information configured in the figure is only an example, and each item can be dynamically configured according to the actual situation.

[0262] See Figure 10 This is a schematic diagram of the structure of an original license document used in this embodiment, as shown below. Figure 10 As shown, the possible parameters include authorization validity period, container copy number verification, limited upgrade parts, deployment host fingerprint, limited upgrade vehicle series, and limited upgrade users.

[0263] The protobuf serialization module is used to serialize the original license file, thereby converting the original license file into a binary byte stream format.

[0264] The certificate and private key management module is mainly used to manage the encryption algorithms, data signature algorithms, keys, etc. required to generate encrypted authorization files.

[0265] The authorization file encryption module is mainly used to generate encrypted authorization files based on configuration-related information, using encryption algorithms, data signature algorithms, and keys.

[0266] The encrypted authorization file generated by the cloud server 820 can be issued to the host machine 810.

[0267] Multiple OTA services can run on the host machine 810, for example Figure 8 As shown, it includes three OTA services. The encrypted license files for different OTA services are different, but the encrypted license files for different OTA services can all be issued by the cloud server 820.

[0268] Based on the authorization method for over-the-air (OTA) download services provided in the above embodiments, this application also provides specific implementations of OTA download service authorization devices. Please refer to the following embodiments.

[0269] See Figure 11This application provides a schematic diagram of an authorization device for an over-the-air (OTA) download service. This device can be applied to an OTA cloud server and may include the following modules:

[0270] The configuration information acquisition module 1101 is used to acquire the original authorization file and the encrypted authorization file structure of the configuration. The encrypted authorization file structure is used to indicate the type of encryption blocks, the order of encryption blocks and the corresponding bit length of encryption blocks contained in the encrypted authorization file. The types of encryption blocks include random key encryption blocks, cryptographic salt encryption blocks and signature encryption blocks.

[0271] The random number generation module 1102 is used to generate a first random number and a second random number based on the number of bits in the random key encryption block and the number of bits in the password salt encryption block, respectively.

[0272] The authorization file encryption module 1103 is used to encrypt the original authorization file by using the first random number and the second random number as the key and the password salt, respectively, to obtain the encrypted authorization file block.

[0273] The random number encryption module 1104 is used to encrypt the first random number and the second random number respectively to obtain a random key encryption block and a password salt encryption block.

[0274] The signature module 1105 is used to sign the original authorization file using a preset signature algorithm to obtain a signature encryption block.

[0275] The combined encryption block module 1106 is used to combine the obtained random key encryption block, password salt encryption block and signature encryption block according to the encryption block order to obtain a combined encryption block.

[0276] The encryption authorization file generation module 1107 is used to sequentially synthesize the file header, combined encryption blocks, and encryption authorization file blocks based on the file byte stream. The file header contains a description field that describes the types of encryption blocks, the order of encryption blocks, and the corresponding bit length of the encryption blocks contained in the encryption authorization file.

[0277] The sending module 1108 is used to send encrypted authorization files to the host machine running the over-the-air download service.

[0278] The authorization device for the over-the-air (OTA) download service in this application embodiment encrypts the original authorization file based on the encrypted authorization file structure by the OTA cloud server, generates an encrypted authorization file, and sends the encrypted authorization file to the host machine for authorization verification, thereby improving the security of the authorization file. According to this application embodiment, compared to authorization using text or JSON format, it offers higher security. Compared to hardware encryption locks, it eliminates the need for hardware lock storage space and the need to burn authorization information, making it easier to implement. Compared to authorization using a single-key encryption algorithm, salting encryption of the original authorization file makes it more difficult to crack. Furthermore, by adding a signature encryption block, the authorization file can be further verified through signature verification, effectively preventing tampering and further improving the security of the authorization file.

[0279] In some embodiments, the encryption block type also includes obfuscated key encryption blocks.

[0280] The random number generation module 1102 is also used to generate a third random number based on the number of bits in the obfuscated key encryption block.

[0281] The random number encryption module 1104 is also used to encrypt a third random number to obtain a confused key encryption block.

[0282] The combined encryption block module 1106 is also used to combine the obtained random key encryption block, obfuscated key encryption block, cryptographic salt encryption block, signature encryption block and encrypted authorization file block according to the encryption block order to obtain a combined encryption block.

[0283] In some embodiments, the authorization file encryption module 1103 is specifically used for:

[0284] The first and second random numbers are used as the key and password salt, respectively, and the original authorization file is encrypted using the PBKDF2 algorithm to obtain the encrypted authorization file block.

[0285] In some embodiments, the authorization file encryption module 1103 may include:

[0286] The chunking submodule is used to divide the original license file into multiple sub-data blocks according to pre-configured data block chunking rules.

[0287] The encryption submodule is used to encrypt multiple sub-data blocks separately using a first random number and a second random number as the key and a password salt, respectively, to obtain multiple encrypted sub-data blocks.

[0288] The combination submodule is used to generate an encrypted authorization file block from multiple encrypted sub-data blocks.

[0289] In some embodiments, the authorization file encryption module 1103 may further include: a hash submodule, used to generate a hash value for each sub-data block before generating an encrypted authorization file block based on multiple encrypted sub-data blocks, and to add the corresponding hash value to the end of the encrypted sub-data block.

[0290] The combination submodule is used to combine multiple encrypted sub-data blocks with hash values ​​appended to their ends into an encrypted authorization file block.

[0291] In some embodiments, the original license file includes hardware verification information and software verification information.

[0292] Hardware inspection information includes verification information for multiple hardware inspection items.

[0293] The software verification information includes verification information for multiple software verification items.

[0294] In some embodiments, the original license file is in binary byte stream format.

[0295] See Figure 12 This application provides a schematic diagram of an authorization device for an over-the-air (OTA) download service. This device can be applied to a host machine running an OTA service and may include the following modules:

[0296] The encrypted authorization file acquisition module 1201 is used to obtain the encrypted authorization file generated by the over-the-air application service container.

[0297] The parsing module 1202 is used to parse the header of the encrypted authorization file to obtain description fields that describe the types of encrypted blocks, the order of encrypted blocks, and the corresponding bit length of the encrypted blocks contained in the encrypted authorization file. The types of encrypted blocks include random key encrypted blocks, cryptographic salt encrypted blocks, signature encrypted blocks, and encrypted authorization file blocks.

[0298] The block extraction module 1203 is used to extract the random key encryption block, the password salt encryption block, the signature encryption block, and the encryption authorization file block from the encryption authorization file according to the description field.

[0299] The random number decryption module 1204 is used to decrypt the random key encryption block and the password salt encryption block respectively to obtain the corresponding first random number and second random number.

[0300] The authorization file decryption module 1205 is used to decrypt the encrypted authorization file block using a first random number and a second random number to obtain the original authorization file.

[0301] The signature verification module 1206 is used to verify the signature of the original authorization file using the signature encryption block.

[0302] The authorization verification module 1207 is used to perform authorization verification on the host machine using the original authorization file in response to the original authorization file passing the signature verification.

[0303] This application provides an authorization method for over-the-air (OTA) download services. An encrypted authorization file is sent from an OTA cloud server to the host machine and can be obtained and parsed by the OTA service running on the host machine via container-mapped volumes. This allows for dynamic replacement of the encrypted authorization file without requiring a replacement of the OTA service itself. The original authorization file is encrypted using a first random number and a second random number, which are then further encrypted, effectively applying double encryption to the original authorization file and significantly improving its security. Furthermore, after decrypting the original authorization file, a signature verification process is used to further verify its integrity. Authorization verification is then performed based on the original authorization file after the signature verification passes. Compared to existing authorization methods, this method is more secure, easier to implement, and more difficult to crack.

[0304] In some embodiments, the encrypted authorization file block includes multiple encrypted sub-data blocks, and the authorization file decryption module 1205 includes:

[0305] The decryption submodule is used to decrypt each encrypted sub-data block in a plurality of encrypted sub-data blocks using a first random number and a second random number, thereby obtaining the sub-data block corresponding to the encrypted sub-data block.

[0306] The response submodule is used to respond to any failure to decrypt any encrypted sub-data block, indicating that the host authorization verification has failed.

[0307] The response submodule is also used to respond to the successful decryption of multiple encrypted sub-data blocks and merge the decrypted sub-data blocks into the original license file.

[0308] In some embodiments, the decryption submodule is specifically used for:

[0309] For each of the multiple encrypted sub-data blocks, decrypt the encrypted sub-data block.

[0310] In response to obtaining the sub-data block corresponding to the encrypted sub-data block through decryption, the hash value appended to the end of the encrypted sub-data block is used to verify the sub-data block.

[0311] Upon successful verification of the sub-data block, it is determined that the encrypted sub-data block has been successfully decrypted.

[0312] If the corresponding sub-data block is not obtained through decryption, or the sub-data block fails verification, it is determined that the decryption of the encrypted sub-data block has failed.

[0313] In some embodiments, the original license file includes hardware verification information and software verification information. The hardware verification information includes verification information for multiple hardware verification items, and the software verification information includes verification information for multiple software verification items. The license verification module 1207 may include:

[0314] The hardware verification submodule is used to match the verification information of multiple hardware verification items in the hardware verification information with the corresponding hardware information obtained from the over-the-air application service container, in order to verify the hardware environment of the over-the-air service.

[0315] The software verification submodule is used to match the verification information of multiple software verification items in the software verification information with the corresponding software information obtained from the over-the-air application service container, in order to verify the software information of the over-the-air service.

[0316] The exception notification submodule is used to respond to situations where the verification information for any hardware verification item does not match the corresponding hardware information, and / or the verification information for any software verification item does not match the corresponding software information, determining that the authorization verification has failed and indicating that the verification item is abnormal.

[0317] The response submodule is also used to determine that the authorization verification has passed and to run the over-the-air download service when the verification information of all hardware verification items matches the corresponding hardware information and the verification information of all software verification items matches the corresponding software information.

[0318] In some embodiments, the original license file is in binary byte stream format, and the apparatus may further include: a format conversion module, used to convert the original license file to a format before performing license verification on the host machine using the original license file, so as to obtain an operable license file.

[0319] The authorization verification module 1207 is specifically used for:

[0320] Use an operable license file to perform license verification on the host machine.

[0321] In some embodiments, the apparatus may further include: a timed verification module, configured to detect whether the authorization verification time has been reached after the host machine is authorized using the original authorization file, and in response to the arrival of the authorization verification time, to perform authorization verification on the host machine again using the original authorization file.

[0322] In some embodiments, detecting whether the authorization verification time has been reached includes:

[0323] Check if the preset timer has reached the preset timeout period.

[0324] In response to the timer reaching its set time, determine the timer's authorization verification time.

[0325] In some embodiments, the random number decryption module 1204 is specifically used for:

[0326] The random key encryption block and the password salt encryption block are decrypted in parallel.

[0327] Figure 13 A schematic diagram of the hardware structure of the electronic device provided in an embodiment of this application is shown.

[0328] The electronic device may include a processor 1301 and a memory 1302 storing computer program instructions.

[0329] Specifically, the processor 1301 may include a central processing unit (CPU), an application-specific integrated circuit (ASIC), or one or more integrated circuits that can be configured to implement the embodiments of this application.

[0330] Memory 1302 may include mass storage for data or instructions. For example, and not limitingly, memory 1302 may include a hard disk drive (HDD), floppy disk drive, flash memory, optical disk, magneto-optical disk, magnetic tape, or Universal Serial Bus (USB) drive, or a combination of two or more of these. Where appropriate, memory 1302 may include removable or non-removable (or fixed) media. Where appropriate, memory 1302 may be internal or external to the integrated gateway disaster recovery device. In a particular embodiment, memory 302 is non-volatile solid-state memory. Memory 1302 may include read-only memory (ROM), random access memory (RAM), disk storage media devices, optical storage media devices, flash memory devices, electrical, optical, or other physical / tangible memory storage devices. Therefore, typically, memory 1302 includes one or more tangible (non-transitory) computer-readable storage media (e.g., memory devices) encoded with software including computer-executable instructions, and when the software is executed (e.g., by one or more processors), it can perform the operations described in any of the licensing methods for over-the-air download services in the above embodiments.

[0331] The processor 1301 implements any of the over-the-air download service authorization methods in the above embodiments by reading and executing computer program instructions stored in the memory 1302.

[0332] In one example, the electronic device may also include a communication interface 1303 and a bus 1310. For example, Figure 13 As shown, the processor 1301, memory 1302, and communication interface 1303 are connected through bus 1310 and complete communication with each other.

[0333] The communication interface 1303 is mainly used to realize communication between various modules, devices, units and / or equipment in the embodiments of this application.

[0334] Bus 1310 includes hardware, software, or both, that couples components of an online data traffic metering device together. For example, and not limitingly, the bus may include an Accelerated Graphics Port (AGP) or other graphics bus, an Enhanced Industry Standard Architecture (EISA) bus, a Front Side Bus (FSB), HyperTransport (HT) interconnect, an Industry Standard Architecture (ISA) bus, an Infinite Bandwidth Interconnect, a Low Pin Count (LPC) bus, a memory bus, a Microchannel Architecture (MCA) bus, a Peripheral Component Interconnect (PCI) bus, a PCI-Express (PCI-X) bus, a Serial Advanced Technology Attachment (SATA) bus, a Video Electronics Standards Association Local (VLB) bus, or other suitable buses, or combinations of two or more of these. Where appropriate, bus 310 may include one or more buses. Although specific buses are described and illustrated in embodiments of this application, any suitable bus or interconnect is contemplated herein.

[0335] Furthermore, in conjunction with the authorization method for over-the-air (OTA) download services in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions, which, when executed by a processor, implement any of the OTA download service authorization methods in the above embodiments.

[0336] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0337] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0338] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0339] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can also be implemented by special-purpose hardware performing the specified functions or actions, or can be implemented by a combination of special-purpose hardware and computer instructions.

[0340] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. An authorization method of an over-the-air download service, characterized by, The method comprises: obtaining a configured original authorization file and an encrypted authorization file structure, wherein the encrypted authorization file structure comprises an encrypted block type, an encrypted block sequence and an encrypted block corresponding bit number contained in an encrypted authorization file, the encrypted block type comprises a random key encrypted block, a password salt encrypted block and a signature encrypted block, generating a first random number and a second random number according to the bit number of the random key encrypted block and the bit number of the password salt encrypted block, encrypting the original authorization file by using a salted encryption mode with the first random number and the second random number as a key and a password salt respectively to obtain an encrypted authorization file block, encrypting the first random number and the second random number respectively to obtain a random key encrypted block and a password salt encrypted block, signing the original authorization file by using a preset signature algorithm to obtain a signature encrypted block, combining the obtained random key encrypted block, password salt encrypted block and signature encrypted block according to the encrypted block sequence to obtain a combined encrypted block, sequentially synthesizing a file header, the combined encrypted block and the encrypted authorization file block into an encrypted authorization file in the form of a file byte stream, wherein the file header contains an explanation field, and the explanation field is used to explain the encrypted block type, the encrypted block sequence and the encrypted block corresponding bit number contained in the encrypted authorization file, sending the encrypted authorization file to a host running an over-the-air (OTA) service, obtaining an id of an OTA service container in the host according to a preset command for obtaining a container identity certificate id, sequentially taking the maximum N-bit characters from the id string of the OTA service container and sequentially converting them into the sequence of encrypted blocks, wherein the value of N is the number of encrypted block types contained in the encrypted authorization file.

2. The method of claim 1, wherein, The encrypted block type further comprises a confusion key encrypted block, and before the combining the obtained random key encrypted block, password salt encrypted block, signature encrypted block and encrypted authorization file block according to the encrypted block sequence to obtain a combined encrypted block, the method further comprises: generating a third random number according to the bit number of the confusion key encrypted block, encrypting the third random number to obtain a confusion key encrypted block, The combining the obtained random key encrypted block, password salt encrypted block, signature encrypted block and encrypted authorization file block according to the encrypted block sequence to obtain a combined encrypted block comprises: combining the obtained random key encrypted block, confusion key encrypted block, password salt encrypted block, signature encrypted block and encrypted authorization file block according to the encrypted block sequence to obtain a combined encrypted block.

3. The method of claim 1, wherein, The encrypting the original authorization file by using a salted encryption mode with the first random number and the second random number as a key and a password salt respectively to obtain an encrypted authorization file block comprises: encrypting the original authorization file by using a PBKDF2 algorithm with the first random number and the second random number as a key and a password salt respectively to obtain an encrypted authorization file block.

4. The method of claim 1, wherein, The first random number and the second random number are respectively used as a key and a password salt to encrypt the original authorization file by using salted encryption to obtain an encrypted authorization file block, including: According to a pre-configured data block segmentation rule, the original authorization file is segmented into a plurality of sub-data blocks, The first random number and the second random number are respectively used as a key and a password salt to encrypt the plurality of sub-data blocks by using salted encryption to obtain a plurality of encrypted sub-data blocks, According to the plurality of encrypted sub-data blocks, an encrypted authorization file block is generated.

5. The method of claim 4, wherein, Before the encrypted authorization file block is generated according to the plurality of encrypted sub-data blocks, the method further includes: A hash value of each sub-data block is respectively generated, The encrypted authorization file block is generated according to the plurality of encrypted sub-data blocks, including: For each encrypted sub-data block in the plurality of encrypted sub-data blocks, a corresponding hash value is added to the tail of the encrypted sub-data block, A plurality of encrypted sub-data blocks with hash values added to the tail are combined to form an encrypted authorization file block.

6. The method of claim 1, wherein, The original authorization file includes hardware verification information and software verification information, The hardware verification information includes verification information of a plurality of hardware verification items, The software verification information includes verification information of a plurality of software verification items.

7. The method of claim 1, wherein, The original authorization file adopts a binary byte stream format.

8. The method according to any one of claims 1 to 7, characterized in that, In the case of starting a host computer running an over-the-air download service, the method includes: An over-the-air download application service container in the host computer is used to obtain the encrypted authorization file, A file header of the encrypted authorization file is parsed to obtain an explanation field used to explain a type of encrypted block, an order of encrypted block, and a corresponding bit number of the encrypted block contained in the encrypted authorization file, wherein the type of encrypted block includes a random key encrypted block, a password salt encrypted block, a signature encrypted block, and an encrypted authorization file block, According to the explanation field, the random key encrypted block, the password salt encrypted block, the signature encrypted block, and the encrypted authorization file block are respectively obtained from the encrypted authorization file, The random key encrypted block and the password salt encrypted block are respectively decrypted to obtain a corresponding first random number and a second random number, The encrypted authorization file block is decrypted using the first random number and the second random number to obtain an original authorization file, The original authorization file is signature-verified using the signature encrypted block, In response to the original authorization file passing the signature verification, the host computer is authorized and verified using the original authorization file.

9. The method of claim 8, wherein, The encrypted authorization file block includes a plurality of encrypted sub-data blocks, and the encrypted authorization file block is decrypted using the first random number and the second random number to obtain an original authorization file, including: The encrypted sub-data blocks in the plurality of encrypted sub-data blocks are decrypted block by block using the first random number and the second random number to obtain sub-data blocks corresponding to the encrypted sub-data blocks, In response to any encrypted sub-data block failing to be decrypted, it is determined that the authorization verification of the host computer fails, In response to all the plurality of encrypted sub-data blocks being successfully decrypted, the plurality of sub-data blocks obtained by decryption are combined into an original authorization file.

10. The method of claim 9, wherein, The tail of the encrypted sub-data block is added with a hash value of the corresponding sub-data block, the encrypted sub-data block in the plurality of encrypted sub-data blocks is decrypted block by block, and the sub-data block corresponding to the encrypted sub-data block is obtained, comprising: decrypting the encrypted sub-data block in the plurality of encrypted sub-data blocks, in response to obtaining the sub-data block corresponding to the encrypted sub-data block through decryption, verifying the sub-data block by using the hash value added at the tail of the encrypted sub-data block, in response to the sub-data block passing the verification, determining that the encrypted sub-data block is successfully decrypted, in response to not obtaining the sub-data block corresponding to the encrypted sub-data block through decryption, or the sub-data block failing to pass the verification, determining that the encrypted sub-data block fails to be decrypted.

11. The method of claim 8, wherein, The original authorization file includes hardware verification information and software verification information, the hardware verification information includes verification information of a plurality of hardware verification items, and the software verification information includes verification information of a plurality of software verification items. The authorization verification of the host computer by using the original authorization file comprises: matching the verification information of the plurality of hardware verification items in the hardware verification information with the corresponding hardware information obtained from the over-the-air application service container one by one to verify the hardware environment of the over-the-air service, matching the verification information of the plurality of software verification items in the software verification information with the corresponding software information obtained from the over-the-air application service container one by one to verify the software information of the over-the-air service, in response to any of the verification information of the hardware verification items not matching the corresponding hardware information, and / or any of the verification information of the software verification items not matching the corresponding software information, determining that the authorization verification fails and prompting the verification item exception, in response to the verification information of all hardware verification items matching the corresponding hardware information, and the verification information of all software verification items matching the corresponding software information, determining that the authorization verification passes and running the over-the-air service.

12. The method of claim 8, wherein, The original authorization file adopts a binary byte stream format, and before the authorization verification of the host computer by using the original authorization file, the method further comprises: format-converting the original authorization file to obtain an operable authorization file, the authorization verification of the host computer by using the original authorization file comprises, authorization verification of the host computer by using the operable authorization file.

13. The method of claim 8, wherein, After the authorization verification of the host computer by using the original authorization file, the method comprises: detecting whether the authorization verification time is reached, in response to reaching the authorization verification time, re-performing the authorization verification of the host computer by using the original authorization file.

14. The method of claim 13, wherein, The detection of whether the authorization verification time is reached comprises: detecting whether a preset timer reaches a preset timing time, in response to the timer reaching the timing time, determining that the authorization verification time is reached.

15. The method of claim 8, wherein, The decryption of the random key encryption block and the password salt encryption block respectively comprises: parallel decryption of the random key encryption block and the password salt encryption block.

16. An authorization device for an over-the-air (OTA) download service, characterized in that, The device comprises: The configuration information obtaining module is configured to obtain a configured original authorization file and an encrypted authorization file structure, wherein the encrypted authorization file structure comprises an encrypted block type, an encrypted block sequence and an encrypted block corresponding bit number contained in an encrypted authorization file, the encrypted block type comprises a random key encrypted block, a password salt encrypted block and a signature encrypted block, The random number generating module is configured to generate a first random number and a second random number according to the bit number of the random key encrypted block and the bit number of the password salt encrypted block respectively, The authorization file encrypting module is configured to encrypt the original authorization file by using a salted encryption manner with the first random number and the second random number as a key and a password salt respectively, to obtain an encrypted authorization file block, The random number encrypting module is configured to encrypt the first random number and the second random number respectively to obtain a random key encrypted block and a password salt encrypted block, The signature module is configured to sign the original authorization file by using a preset signature algorithm to obtain a signature encrypted block, The combined encrypted block module is configured to combine the obtained random key encrypted block, password salt encrypted block and signature encrypted block according to the encrypted block sequence to obtain a combined encrypted block, The encrypted authorization file generating module is configured to sequentially synthesize an encrypted authorization file based on a file byte stream form of a file header, the combined encrypted block and the encrypted authorization file block, wherein the file header comprises an explanation field, and the explanation field is used to explain the encrypted block type, the encrypted block sequence and the encrypted block corresponding bit number contained in the encrypted authorization file, The sending module is configured to send the encrypted authorization file to a host machine running an over-the-air (OTA) service. The combined encrypting module is further configured to obtain an id of an OTA service container in the host machine according to a preset command used to obtain a container identity id; sequentially take the maximum N-bit characters from the id string of the OTA service container, and sequentially correspondingly convert the maximum N-bit characters into the sequence of the encrypted blocks, wherein the value of N is the number of the encrypted block types contained in the encrypted authorization file.

17. An electronic device, comprising: The device comprises a processor and a memory storing computer program instructions, The processor executes the computer program instructions to implement the authorization method of the over-the-air service according to any one of claims 1-15.

18. A computer-readable storage medium, characterized in that, The computer readable storage medium stores computer program instructions, and the computer program instructions are executed by the processor to implement the authorization method of the over-the-air service according to any one of claims 1-15.

19. A computer program product, characterised in that, The instructions in the computer program product are executed by the processor of the electronic device, so that the electronic device executes the authorization method of the over-the-air service according to any one of claims 1-15.

Images