Patent ID: 12204616

DETAILED DESCRIPTION

In order to make objectives, technical solutions and advantages of the present application more apparent, the present application now will be described in detail with reference to the accompanying drawings and by way of examples. Obviously, the embodiments described herein are only some of the embodiments of the present application instead of all of them. All other embodiments obtained by those of ordinary skills in the art based on the embodiments herein without any creative efforts are within the scope of the present application.

FIG.1is a schematic diagram of a legal key deployment scheme (i.e., a key deployment method) in an embodiment of the present application. Referring toFIG.1, in order to realize the loading and operation of a protected intelligent application (such as an intelligent algorithm library) in an intelligent apparatus (such as a smart card) within the specified authorization range, the legal key deployment scheme in this embodiment provides three keys, namely the first controlled key, Key_root110(also known as a root key), the second controlled key, Key_alg120(also known as an original intelligent apparatus key), and the secondary authentication key, Key_ladder130(also known as a work key).

The first controlled key Key_root110can be an AES (Advanced Encryption Standard) key. The first controlled key Key_root110can be burnt into the write-protected storage medium220of the intelligent apparatus200as a legal burnt-into-hardware key in the intelligent apparatus200, wherein the write-protected storage medium220can be a medium such as an OTP (One Time Programmable) storage medium that can prevent the tampering of the burnt-into-hardware key. The control right of the first controlled key Key_root110belongs to the first manager510(the manager is also referred to as a controller in the present application), which is different from the first developer410to which the device kernel application210belongs and from the second developer420to which the protected intelligent application300belongs. In order to facilitate the confidentiality and isolation of the first controlled key Key_root110from the first developer410and the second developer420, the first controlled key Key_root110may use the key server100with controlled access permission as a transfer carrier.

The second controlled key Key_alg120may also be an AES key, the second controlled key Key_alg120may be a legal encryption key by means of which ciphertext in the protected intelligent application is obtained through encryption, and the control right of the second controlled key Key_alg120belongs to the second manager520, which is not only different from the first manager510, but also different from the first developer410to which the device kernel application210belongs and from the second developer420to which the protected intelligent application300belongs.

The secondary authentication key Key_ladder130may be a secondary authentication key obtained by using the first controlled key Key_root110to encrypt the second controlled key Key_alg120based on Key Ladder mechanism. The secondary authentication key Key_ladder130may be shared within the first developer410to which the device kernel application210belongs, and the secondary authentication key Key_ladder130may be implanted in the device kernel application210by the first developer410as an implanted-into-kernel key.

FIG.2is an example flow diagram of the legal key deployment scheme shown inFIG.1. Referring toFIG.2, in an example of legal key deployment:the first developer410(for example, a development group of the belonger of the device kernel application) may deploy the key assignment tool in the key server100(S411), wherein the deployment location of the key assignment tool in the key server100may be known to only the first developer410.

After the key server100successfully completes the installation of the key assignment tool (S101), the first developer410will then receive a success response returned by the key server100(S102). At this time, the key server100has the ability to act as a transfer carrier of the first controlled key Key_root110. The key server100can receive the first controlled key uploaded by the first controller and the second controlled key uploaded by the second controller by using the key assignment tool; take the first controlled key as an encryption key to encrypt the second controlled key in order to obtain the secondary authentication key, and then use the key assignment tool to deliver the secondary authentication key to the first developer, so as to realize the transfer of the first controlled key.

The first controller510(for example, the key administrator of the belonger of the device kernel application) may upload the first controlled key Key_root110to the key server100(S511) so that the key server100can locally store the first controlled key Key_root110(S103). Wherein, the storage location of the first controlled key Key_root110in the key server100may be specified by the first controller510and be known to only the first controller510. In an example, Company A entrusts Company B to develop a device kernel application, then Company B is the first developer and Company A is the first controller.

The second controller520(for example, the key administrator of the belonger of the protected intelligent application) may upload the second controlled key Key_alg120to the key server100(S521), so that the key server100can call the deployed key assignment tool, and encrypt the uploaded second controlled key Key_alg120with the locally stored first controlled key Key_root110in order to obtain the hierarchical encryption mechanism based secondary authentication key Key_ladder130(S104). The hierarchical encryption mechanism here refers to that the secondary authentication key is key information of two levels that is obtained by encrypting the second controlled key with the first controlled key. In an example, Company C entrusts company D to develop an intelligent application, then Company D is the second developer and Company C is the second controller.

Thereafter, the key server100may deliver the hierarchical encryption mechanism based secondary authentication key Key_ladder130to the first developer410(S105), so that the first developer410may retain the secondary authentication key Key_ladder130, implant the secondary authentication key Key_ladder130into the device kernel application (S412), and then hand over the device kernel application implanted with the secondary authentication key Key_ladder130to the production line to be unchangeably loaded to the intelligent apparatus200(S413).

The intelligent apparatus200with the unchangeably loaded device kernel application will go through subsequent production processes in the production line, comprising the burning process of using the burnt-into-hardware key of a production line burning device430. That is, the production line burning device430may initiate the verification detection of the intelligent apparatus200(S431), and the device kernel application in the intelligent apparatus200may provide the production line burning device430with verification information pre-embedded in the device kernel application (S201) in response to the verification detection of the production line burning device430. Wherein the verification information is used to verify the legitimacy and version of the device kernel application, so as to determine the legitimacy of the intelligent apparatus200.

When detecting that the intelligent apparatus200is a legal apparatus with a correct version according to the verification information, the production line burning device430may initiate a key request to the key server100(S432). Wherein, the access permission of the production line burning device430to the key server100may be authenticated by the hot-plug encryption device (such as encryption dog) plugged into the production line burning device430. Therefore, after receiving the key request and passing the authentication of the key request, the key server100will send the encrypted key data to the production line burning device430(S106). The key server100and the production line burning device430are devices from different manufacturers. The access permission of the production line burning device430is authenticated by the key server100, so as to prevent illegal manufacturers from fraudulently using the production line burning device430to defraud the secondary authentication key.

The production line burning device430does not have the ability to decrypt the key data. Therefore, the production line burning device430will forward the encrypted key data to the intelligent apparatus200(S433).

The device kernel application of the intelligent apparatus200receives the encrypted key data provided by the production line burning device430, and may perform a decryption operation on the encrypted key data according to the reverse algorithm (e. g., deobfuscation algorithm) of the encryption algorithm (e. g., obfuscation algorithm) used by the key server100(S202), and burn on the write-protected storage medium (such as the OTP storage medium) of the intelligent apparatus200the key data (in this case, the first controlled key Key_root110) obtained by decrypting the encrypted key data to form a burnt-into-hardware key (S203). After the burning is completed, the device kernel application of the intelligent apparatus200may discard the key data used during the burning.

The second developer420(for example, the development group of the belonger of the protected intelligent application) may provide the authentication plaintext to the second controller520(S421) for encryption based on the second controlled key Key_alg120(S522). After receiving the authentication ciphertext provided by the second controller520(S523), the second developer420can implant the authentication ciphertext and authentication plaintext into the protected intelligent application (S422), wherein the authentication ciphertext is implanted in the protected intelligent application with unrestricted access, while the authentication plaintext is implanted in the way of preventing access from the device kernel application. After encrypting the authentication plaintext with the second controlled key to obtain the authentication ciphertext, the second controller sends the authentication ciphertext to the second developer. The second developer implants the authentication ciphertext into the protected intelligent application with unrestricted access, and implants the authentication plaintext into the protected intelligent application in the way of preventing access from the device kernel application.

FIG.3is a schematic diagram of the optimized principle of the legal key deployment scheme shown inFIG.1.FIG.4is an example flow diagram of the legal key deployment scheme shown inFIG.3. As an extended solution, the authentication ciphertext generation process based on the encryption of the authentication plaintext can also be completed in the second developer420. For example, the key server100can also deliver the secondary authentication key Key_ladder130to the second controller520(S107) and the second developer420(S108) respectively for retention.

The second controller520can make a plaintext encryption tool for deceptive encryption (S522) and provide it to the second developer420(S523), wherein the deceptive encryption takes the secondary authentication key Key_ladder130as an input key and the second controlled key Key_alg120as a real key to perform the encryption operation. The deceptive encryption here refers to an encryption operation in which the input key is different from the real key, that is, encryption is performed not with the input secondary authentication key but with the second controlled key.

Thus, the second developer420can use the retained secondary authentication key Key_ladder130and the plaintext encryption tool provided by the second controller520to encrypt the authentication plaintext (S421′) in order to obtain the authentication ciphertext encrypted with the second controlled key Key_alg120as the real key. After that, the second developer420can implant the authentication ciphertext and authentication plaintext into the protected intelligent application (S422), wherein the authentication ciphertext is implanted in the protected intelligent application with unrestricted access, while the authentication plaintext is implanted in the way of preventing access from the device kernel application.

The above description of the legal key deployment aims to facilitate the understanding of the key relationship of the first controlled key Key_root110(also known as the root key) to be burnt in the intelligent apparatus, the second controlled key Key_alg120(also known as the original intelligent apparatus key) to generate the authentication ciphertext of the protected intelligent application, and the secondary authentication key Key_ladder130to trigger decryption verification or further to trigger ciphertext encryption. It can be understood that the operation process, all identities and the details of key assignment in the above legal key deployment should not be considered as necessary restrictions on the key relationship.

Hereinafter, the method for calling permission verification of the protected intelligent application will be described in detail in combination with the first controlled key Key_root110, the second controlled key Key_alg120and the secondary authentication key Key_ladder130with the above key relationship.

In the present application, the specific type of intelligent apparatus is not limited. The intelligent apparatus can be any device that can load and run intelligent applications. In one example, the intelligent apparatus can be an intelligent camera or a hard disk video recorder, etc., and the protected intelligent application can be an intelligent analysis algorithm (for example, an algorithm such as a target recognition algorithm or a target trajectory analysis algorithm; or a client of a device such as a camera or hard disk video recorder, etc.). In one example, the intelligent apparatus can be a UAV (unmanned aerial vehicle) equipped with a pan-tilt, and the protected intelligent application can be an application that controls the pan-tilt, etc.

FIG.5is an exemplary flow diagram of the method for calling permission verification of a protected intelligent application in an embodiment of the present application. Referring toFIG.5, when the protected intelligent application is loaded into the intelligent apparatus (S500), the method for calling permission verification of the protected intelligent application in this embodiment may comprise the following steps performed by the device kernel application of the intelligent apparatus:S510: obtaining authentication ciphertext in the protected intelligent application;S530: calling a hardware decryption module, and delivering the implanted-into-kernel key pre-implanted in the device kernel application and the obtained authentication ciphertext to the hardware decryption module, so that the hardware decryption module:at S531, reads a burnt-into-hardware key from the write-protected storage medium of the intelligent apparatus;at S532, decrypts the implanted-into-kernel key pre-implanted in the device kernel application by using the burnt-into-hardware key in the write-protected storage medium; andat S533, decrypts the authentication ciphertext by using the decryption key obtained by decrypting the implanted-into-kernel key.

For example, the secondary authentication key Key_ladder can be obtained by performing a first encryption algorithm based encryption operation on the second controlled key Key_alg with the first controlled key Key_root, and the authentication ciphertext is obtained by encrypting sample plaintext (i.e. the authentication plaintext) with the second controlled key Key_alg. Accordingly, the hardware decryption module can use burnt-into-hardware key to perform the first decryption algorithm (the reverse algorithm of the first encryption algorithm) based decryption operation on the implanted-into-kernel key, and the hardware decryption module can use the decryption key obtained by decrypting the implanted-into-kernel key to perform the second decryption algorithm (the reverse algorithm of the second encryption algorithm) based decryption operation on the authentication ciphertext.

Thus, when the implanted-into-kernel key is the secondary authentication key Key_ladder obtained by encrypting the second controlled key Key_alg with the first controlled key Key_root and when the burnt-into-hardware key is the first controlled key Key_root, the decryption key obtained by decrypting the implanted-into-kernel key is the second controlled key Key_alg.

If the authentication ciphertext is obtained by performing deceptive encryption on the sample plaintext with the secondary authentication key Key_ladder as an input key and the second controlled key Key_alg as a real key, the deceptive encryption can use the first controlled key Key_root to perform the first decryption algorithm (the reverse algorithm of the first encryption algorithm) based decryption operation on the input key, and use the deception key (the second controlled key Key_alg) obtained by decrypting the input key as a real key to perform the encryption operation based on the second encryption algorithm.

S550: providing the decrypted plaintext obtained by decrypting the authentication ciphertext returned by the called hardware decryption module to the protected intelligent application, so that the protected intelligent application decides whether to grant the calling permission to the device kernel application by verifying the consistency between the decrypted plaintext and the sample plaintext at S600.

Wherein, when the decryption key obtained by decrypting the implanted-into-kernel key is the second controlled key Key_alg, the decrypted plaintext obtained by decrypting the authentication ciphertext is consistent with the sample plaintext inaccessible from the device kernel application in the protected intelligent application.

Based on the above process, through the calling of the hardware decryption module by the device kernel application, the intelligent apparatus can decrypt the authentication ciphertext in the protected intelligent application by using the implanted-into-kernel key in the device kernel application and the burnt-into-hardware key in the write-protected storage medium, and:

only when the implanted-into-kernel key is the secondary authentication key Key_ladder obtained by encrypting the second controlled key Key_alg with the first controlled key Key_root and the burnt-into-hardware key is the first controlled key Key_root, the correct second controlled key Key_alg can be obtained to decrypt the authentication ciphertext and the decrypted plaintext consistent with the sample plaintext can be obtained after decryption, so that the protected intelligent application can grant the calling permission to the device kernel application through consistency verification.

Thus, the use permission of the protected intelligent application can be limited to the intelligent apparatus which is correctly configured with the secondary authentication key Key_ladder and burnt with the first controlled key Key_root, so as to prevent the malicious piracy of the protected intelligent application running in the illegal apparatus.

FIG.6is a schematic diagram of the key illegal deployment that can be prevented by the method for calling permission verification as shown inFIG.1. Referring toFIG.6, if a pirate610imitates the hardware and the loaded device kernel application of the intelligent apparatus, it is difficult for the pirate610to obtain both the secondary authentication key Key_ladder and the first controlled key Key_root at the same time, so that the counterfeit intelligent apparatus cannot obtain the calling permission of the protected application300.

FIG.7is an exemplary flow diagram of the method for calling permission verification as shown inFIG.5. Referring toFIG.7, the protected intelligent application comprises an intelligent application kernel310, an application verification module320, an access interface331and a verification interface332that grant access permission to the device kernel application, and a calling interface390that provides limited access permission to the device kernel application.

Wherein, the access interface331, the verification interface332and the calling interface390can be an API (Application Programming Interface), the authentication ciphertext implanted in the protected intelligent application with unrestricted access can be integrated in the access interface331, and the authentication plaintext implanted in the protected intelligent application in the way of preventing access from the device kernel application can be integrated in the application verification module320in a hidden manner.

Accordingly, inFIG.7, the device kernel application can obtain the authentication ciphertext by reading the access interface331of the protected intelligent application at S510, and the device kernel application can send the decrypted plaintext to the verification interface332at S550so that the application verification module320in the protected intelligent application can verify the consistency between the decrypted plaintext and the sample plaintext, so as to determine whether to grant calling permission to the device kernel application.

In addition, inFIG.7, the method for calling permission verification can further comprise, after S550, S570executed by the device kernel application: receiving the verification result returned by the protected intelligent application (application verification module320), and identifying the verification result to determine whether it is granted to call the protected intelligent application, that is, whether it can obtain a success calling response to the intelligent application kernel310by accessing the calling interface390.

FIG.8is an extended flow diagram of the method for calling permission verification as shown inFIG.5to support the legal key deployment example as shown inFIG.2. Referring toFIG.8, before the protected intelligent application is loaded into the intelligent apparatus (for example, the intelligent apparatus is in the production line manufacturing stage), the method for calling permission verification of the protected intelligent application in this embodiment may comprise the following steps performed by the device kernel application of the intelligent apparatus:S810: receiving the encrypted key data provided by the production line burning device.S830: performing a decryption operation on the encrypted key data.S850: burning on the write-protected storage medium of the intelligent apparatus by using the key data obtained by decrypting the encrypted key data to form a burnt-into-hardware key.

Wherein, when the encrypted key data provided by the production line burning device comes from the key server, the key data obtained by decrypting the encrypted key data is the first controlled key Key_root.

Moreover, as a further optional optimization solution, the access permission of the production line burning device to the key server can be authenticated by the hot-plug encryption device (such as encryption dog) plugged into the production line burning device.

S870: discarding the key data after burning is completed.

In addition, as a further optional solution, the method for calling permission verification of the protected intelligent application in this embodiment may comprise, before S810, a step performed by the device kernel application of the intelligent apparatus: providing the production line burning device with verification information pre-implanted in the device kernel application in response to the verification detection of the production line burning device.

FIG.9is an exemplary schematic structural diagram of an intelligent apparatus in an embodiment. Referring toFIG.9, in this embodiment, the intelligent apparatus (which can be presented as a smart card) comprises an application carrying module910, a hardware decryption module920, and a write-protected storage medium930(e. g., an OTP storage medium).

The application carrying module910is configured to load and run the device kernel application, and when the protected intelligent application is recorded in the application carrying module, the device kernel application is configured to perform the method for calling permission verification as described in the above embodiment, that is, to execute the process shown inFIG.5orFIG.7, and to further execute the process shown inFIG.8.

The hardware decryption module920is used to provide decryption assistance for the device kernel application loaded in the application carrying module910, that is, to perform the steps S531, S532and S533in the process shown inFIG.5orFIG.7.

The burnt-into-hardware key is burned in the write-protected storage medium930. For example, the burnt-into-hardware key can be burned in the write-protected storage medium930through the process shown inFIG.8.

When implementing the above intelligent apparatus, the application carrying module910, the hardware decryption module920and the write-protected storage medium930(such as the OTP storage medium) can be integrated in the same IC (integrated circuit) chip.

The intelligent apparatus can further comprise a non-transitory computer-readable storage medium, which can be independent of the IC chip integrated with the application carrying module910, the hardware decryption module920and the write-protected storage medium930, and the non-transitory computer-readable storage medium can store instructions, some of which, when executed by a processor such as the IC chip, cause the processor such as the IC chip to load the device kernel application (loaded into the application carrying module910) and then to trigger the device kernel application to perform the method for calling permission verification as described in the above embodiment, that is, to perform the process shown inFIG.5orFIG.7, and further to perform the process shown inFIG.8.

Other instructions for a processor such as the IC chip to load the protected intelligent application (loaded to the application carrying module910) can also be imported into the non-transitory computer-readable storage medium.

The algorithm used by the hardware decryption module920to realize the decryption process can be fixed in the hardware decryption module920in advance, rather than be achieved by loading the program from a non-transitory computer-readable storage medium.

In the present application, the technical features in each optional solution can be combined to form solutions as long as they are not exclusive, and these solutions are within the scope of the disclosure of the present application. The relationship terms such as “first”, “second”, and the like are only used for distinguishing one entity or operation from another entity or operation, but do not necessarily require or imply that there is any actual relationship or order between these entities or operations. Moreover, the terms “include”, “comprise” or any other variants thereof are intended to cover non-exclusive inclusions, so that processes, methods, articles or devices comprising a series of elements comprise not only those elements listed but also those not specifically listed or the elements intrinsic to these processes, methods, articles, or devices. Without further limitations, elements defined by the sentences “comprise(s) a” or “include(s) a” do not exclude that there are other identical elements in the processes, methods, articles, or devices which comprise these elements. Each embodiment in this description is described in a relevant way. Each embodiment focuses on the differences from other embodiments. The same and similar parts of each embodiment can be referred to each other.

The description is only for preferred embodiments of the present application, and is not intended to limit the present application. Any modifications, substitutions, improvements, etc., which are made within the spirit and principles of the present application, will fall into the protection scope of the present application.