Method for authenticating call authority of protected intelligent application and intelligent device

Abstract

A method for authenticating the access right of a protected intelligent application and an intelligent device are provided. When a device kernel application calls a hardware decryption module, the intelligent device decrypts the authentication ciphertext of the protected intelligent application using the kernel embedded key of the device kernel application and the hardware write key of a write-protected storage medium. Only if the kernel embedded key is a second-level authentication key obtained by encrypting a second managed key with a first managed key and the hardware write key is the first managed key, can the intelligent device obtain the correct second managed key to decrypt the authentication ciphertext. The decrypted plaintext obtained through the decryption matches the sample plaintext, so that the protected intelligent application passes the identity verification and is granted access right to the device kernel application. This restricts the use right of the protected intelligent application to intelligent devices with the correct key configuration, thereby preventing malicious piracy in which the protected intelligent application is executed on an unauthorized device.

Description

[Technical field]

[0001] The present application relates to copyright protection of intelligent applications, and in particular to a method and an intelligent device for authenticating the invocation authority of a protected intelligent application. [Background technology]

[0002] With the popularization of intelligent applications, various intelligent applications have been born. However, how to effectively protect the copyright of intelligent applications and restrict the usage rights of intelligent applications to intelligent devices within a specified permitted range is a technical problem to be solved in the prior art. Summary of the Invention

[0003] In view of the above problems, the embodiments of the present application respectively provide an authentication method for the access authority of a protected intelligent application and an intelligent device using the authentication method for the access authority, so as to restrict the use right of a protected intelligent application to an intelligent device within a specified permission range. The specific technical solutions are as follows:

[0004] In one embodiment, a method for authenticating a call authority of a protected intelligent application is provided, and when the protected intelligent application is loaded into an intelligent device, the method for authenticating a call authority includes the following steps performed by a device kernel application of the intelligent device: Obtaining an authentication ciphertext for the protected intelligent application; Invoke a hardware decryption module, issue a kernel-embedded key pre-embedded in the device kernel application and the obtained authentication ciphertext to the hardware decryption module, make the hardware decryption module decrypt the kernel-embedded key using a hardware write key in a write-protected storage medium of the intelligent device, and make the hardware decryption module decrypt the authentication ciphertext using a decryption key obtained by decrypting the kernel-embedded key, where the kernel-embedded key is a second-level authentication key obtained by encrypting a second managed key using a first managed key, and when the hardware write key is the first managed key, the decryption key obtained by decrypting the kernel-embedded key is the second managed key; In order for the protected intelligent application to verify the consistency between the decrypted plaintext and the sample plaintext and decide whether to grant the device kernel application calling authority, the decrypted plaintext obtained by decrypting the authentication ciphertext returned by the call to the hardware decryption module is provided to the protected intelligent application, where the authentication ciphertext is obtained by encrypting the sample plaintext using the second managed key, and the decryption key obtained by decrypting the kernel embedded key is the second managed key, the decrypted plaintext obtained by decrypting the authentication ciphertext is consistent with the sample plaintext in the protected intelligent application to which the device kernel application's access is blocked.

[0005] Preferably, the authenticated ciphertext is obtained by performing deceptive encryption on the sample plaintext using the second-level authentication key as an input key and the second managed key as a true key.

[0006] Preferably, the second-level authentication key is obtained by performing an encryption operation on the second managed key based on a first encryption algorithm using the first managed key, the authentication ciphertext is obtained by performing an encryption operation on the sample plaintext based on a second encryption algorithm using the second managed key, the hardware decryption module performs a decryption operation on the kernel embedded key based on the first decryption algorithm using the hardware write key, and the hardware decryption module performs a decryption operation on the authentication ciphertext based on the second decryption algorithm using a decryption key obtained by decrypting the kernel embedded key, where the first decryption algorithm is an inverse algorithm of the first encryption algorithm, and the second decryption algorithm is an inverse algorithm of the second encryption algorithm.

[0007] Preferably, the authenticated ciphertext is obtained by performing deceptive encryption on the sample plaintext based on a first decryption algorithm, where the deceptive encryption involves performing a decryption operation on an input key based on the first decryption algorithm using a first managed key, and performing an encryption operation based on a second encryption algorithm using the deceptive key obtained by decrypting the input key as the true key.

[0008] Preferably, before the protected intelligent application is loaded into an intelligent device running a device kernel application, the call authority authentication method further includes the following steps, which are executed by the device kernel application of the intelligent device: receive encryption key data provided by a production line write device, perform a decryption operation on the encryption key data, and use the key data obtained by decrypting the encryption key data to write to the write-protected storage medium of the intelligent device to form a hardware write key, where if the encryption key data provided by the production line write device is from a key server, the encryption key obtained by decrypting the encryption key data is the first managed key, and discard the encryption key data after writing is completed.

[0009] Preferably, the access rights of the production line writing device to the key server are authenticated by a hot-pluggable encryption device connected to the production line writing device.

[0010] Preferably, the method further includes providing, to the production line writing device, authentication information pre-embedded in the device kernel application in response to authentication detection of the production line writing device before receiving the encryption key data provided by the production line writing device.

[0011] Preferably, management rights over the first managed key belong to a first administrator, management rights over the second managed key belong to a second administrator different from the first administrator, and both the first administrator and the second administrator are different from the first developer to which the device kernel application belongs and the second developer to which the protected intelligent application belongs.

[0012] Preferably, the write-protected storage medium of the intelligent device is an OTP storage medium.

[0013] In another embodiment, an intelligent device is provided, comprising an application-loaded module for loading and executing a device kernel application, a hardware decryption module, and a write-protected storage medium, and when a protected intelligent application is recorded in the application-loaded module, the device kernel application is used to perform the call authority authentication method described in the above embodiment.

[0014] In another embodiment, a non-transitory computer-readable storage medium is provided, the non-transitory computer-readable storage medium having instructions stored thereon that, when executed by a processor, cause the processor to load a device kernel application and cause the device kernel application to begin performing the method for authenticating call authority described in the above embodiment.

[0015] In another embodiment, a method for key placement is provided, the method comprising: Obtaining a first managed key of a first administrator, and writing the first managed key as a hardware write key to a write-protected storage medium of a designated intelligent device; Obtaining a second managed key of a second administrator, and setting the second managed key as an encryption key of a protected intelligent application; and encrypting the second managed key using the first managed key to obtain a second-level authentication key, and embedding the second-level authentication key as a kernel embedding key in a device kernel application of the specified intelligent device.

[0016] According to the above embodiment, the device kernel application calls the hardware decryption module, so that the intelligent device can use the kernel embedded key of the device kernel application and the hardware write key of the write-protected storage medium to decrypt the authentication ciphertext of the protected intelligent application. Moreover, only when the kernel embedded key is a second-level authentication key obtained by encrypting the second managed key with the first managed key and the hardware write key is the first managed key, the correct second managed key can be obtained to decrypt the authentication ciphertext, and the decrypted plaintext that is consistent with the sample plaintext can be obtained by decryption, so that the protected intelligent application passes the verification of consistency and the device kernel application is granted the calling authority. Therefore, the usage right of the protected intelligent application can be limited to the intelligent device that correctly configures the second-level authentication key and writes the first managed key, so that the malicious piracy of the protected intelligent application being executed on an unauthorized device can be prevented. [Brief description of the drawings]

[0017] In order to more clearly explain the technical solutions of the embodiments and the prior art of the present application, the drawings used in the embodiments and the prior art will be briefly described below. Note that the drawings described below are merely related to some embodiments of the present application, and it is obvious to those skilled in the art that other drawings can be obtained based on these drawings without creative efforts.

[0018] [Figure 1] FIG. 1 is a principle schematic diagram of a valid key allocation scheme according to an embodiment of the present application. [Diagram 2] FIG. 2 is a schematic flow chart of an example of a valid key placement scheme as shown in FIG. 1 in this application. [Diagram 3] FIG. 3 is a schematic diagram of the optimization principle of the valid key allocation plan as shown in FIG. 1 in this application. [Figure 4] FIG. 4 is a schematic flow chart of an example of a valid key placement scheme as shown in FIG. 3 in this application. [Diagram 5] FIG. 5 is an exemplary flowchart of a method for authenticating the calling authority of a protected intelligent application according to an embodiment of the present application. [Figure 6] FIG. 6 is a schematic diagram of an unauthorized allocation of a key that can be prevented by the method of authenticating the call authority as shown in FIG. 5 in this application. [Figure 7] FIG. 7 is a schematic flow chart of an example of a method for authenticating a calling authority as shown in FIG. 5 in the present application. [Figure 8] FIG. 8 is an expanded flowchart of the call authority authentication method as shown in FIG. 5 in the present application to support the key placement example as shown in FIG. [Figure 9] FIG. 9 is a schematic diagram of an exemplary structure of an intelligent device according to an embodiment of the present application. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0019] In order to make the purpose, technical solution and advantages of the present invention clearer, the present application will be described in more detail below by giving examples with reference to the drawings. It is clear that the described examples are only some of the examples of the present application, not all of the examples. All other examples that a person skilled in the art can obtain based on the examples of the present application without creative work are all within the scope of protection of the present application.

[0020] Fig. 1 is a schematic diagram of a key valid allocation scheme (i.e., a key allocation method) according to an embodiment of the present application. Referring to Fig. 1, in order to realize the loading and execution of a protected intelligent application (e.g., an intelligent algorithm library) in an intelligent device (e.g., a smart card) within a specified permission range, the key valid allocation scheme according to the embodiment provides three keys, a first managed key Key_root 110 (also called root key), a second managed key Key_alg 120 (also called the first key of the intelligent application), and a second-level authentication key Key_ladder 130 (also called work key).

[0021] The first managed key Key_root 110 may be an AES (Advanced Encryption Standard) key. The first managed key Key_root 110 may be written to a write-protected storage medium 220 of the intelligent device 200 as a valid hardware write key in the intelligent device 200. The write-protected storage medium 220 may be a medium capable of preventing tampering with the hardware write key, such as an OTP (One Time Programmable) storage medium. Moreover, the management right of the first managed key Key_root 110 belongs to a first administrator (in this application, an administrator is also called a controller) 510, and the first administrator 510 is different from the first developer 410 to which the device kernel application 210 belongs and the second developer 420 to which the protected intelligent application 300 belongs. To facilitate keeping the first managed key Key_root 110 secret and isolated from the first developer 410 and the second developer 420, the first managed key Key_root 110 may use a key server 100 controlled by access permissions as an intermediary carrier.

[0022] The second managed key Key_alg 120 may also be an AES key. The second managed key Key_alg 120 may be a valid encryption key for the ciphertext in the protected intelligent application obtained by encryption, and the management right of the second managed key Key_alg 120 belongs to a second administrator 520, which is different from the first administrator 510, the first developer 410 to which the device kernel application 210 belongs, and the second developer 420 to which the protected intelligent application 300 belongs.

[0023] The second-level authentication key Key_ladder 130 may be a second-level authentication key obtained by encrypting the second managed key Key_alg 120 with the first managed key Key_root 110 based on a key ladder mechanism. The second-level authentication key Key_ladder 130 may be shared with a group of the first developer 410 to which the device kernel application 210 belongs, and the second-level authentication key Key_ladder 130 may be embedded in the device kernel application 210 by the first developer 410 as a kernel embedded key.

[0024] FIG. 2 is a schematic flow chart of an example of a valid key placement scheme as shown in FIG. 1. Referring to FIG. 2, in one example of a valid key placement scheme, A first developer 410 (e.g., a development group of the owner of a device kernel application) places a key distribution tool in the key server 100 (S411). Here, the placement location of the key distribution tool in the key server 100 can be made known only to the first developer 410.

[0025] When the key server 100 successfully completes the installation of the key distribution tool (S101), the first developer 410 receives a success response returned by the key server 100 (S102). At this time, the key server 100 has the ability to function as a relay carrier of the first managed key Key_root 110. The key server 100 uses the key distribution tool to receive the first managed key uploaded by the first administrator and the second managed key uploaded by the second administrator, encrypts the second managed key using the first managed key as an encryption key to obtain a second-level authentication key, and issues the second-level authentication key to the first developer using the key distribution tool, thereby realizing relay of the first managed key.

[0026] The first administrator 510 (e.g., a key manager of the owner of a device kernel application) uploads the first managed key Key_root 110 to the key server 100 (S511), and the key server 100 stores the first managed key Key_root 110 locally (S103). Here, the storage location of the first managed key Key_root 110 in the key server 100 is specified by the first administrator 510 and is known only to the first administrator 510. As an example, when company A requests company B to develop a device kernel application, company B is the first developer and company A is the first administrator.

[0027] The second administrator 520 (e.g., a key manager of the owner of the protected intelligent application) uploads the second managed key Key_alg 120 to the key server 100 (S521), and the key server 100 calls the deployed key distribution tool and encrypts the uploaded second managed key Key_alg 120 using the locally stored first managed key Key_root 110 to obtain a second-level authentication key Key_ladder 130 based on a ladder encryption mechanism (S104). Here, the ladder encryption mechanism means that the second-level authentication key is obtained by encrypting the second managed key using the first managed key, and includes two layers of key information. As an example, when company C requests company D to develop an intelligent application, company D is the second developer and company C is the second administrator.

[0028] Then, the key server 100 issues a second-level authentication key Key_ladder 130 based on the ladder encryption mechanism to the first developer 410 (S105). This allows the first developer 410 to store the second-level authentication key Key_ladder 130, embed the second-level authentication key Key_ladder 130 in a device kernel application (S412), and further solidify and load the device kernel application with the embedded second-level authentication key Key_ladder 130 into the intelligent device 200 on the production line (S413).

[0029] The intelligent device 200 that has solidified and loaded the device kernel application continues to execute the subsequent production process on the production line, including the procedure of writing the hardware write key by the production line writing device 430. That is, the production line writing device 430 can start authentication detection for the intelligent device 200 (S431), and in response to the authentication detection of the production line writing device 430, the device kernel application of the intelligent device 200 can provide the production line writing device 430 with authentication information for verifying the authenticity and version of the device kernel application that is pre-embedded in the device kernel application (S201), thereby allowing the production line writing device 430 to determine the authenticity of the intelligent device 200.

[0030] When the production line writing device 430 detects that the intelligent device 200 is a legitimate device with the correct version according to the authentication information, it initiates a key request to the key server 100 (S432). Here, the authority of the production line writing device 430 to access the key server 100 can be authenticated by a hot-pluggable encryption device (such as a dongle) connected to the production line writing device 430. Thus, the key server 100 issues encrypted key data to the production line writing device 430 after receiving the key request and passing the authentication for the key request (S106). The key server 100 and the production line writing device 430 are devices of different manufacturers, and the key server 100 authenticates the access authority of the production line writing device 430 to prevent an unauthorized manufacturer from unauthorizedly using the production line writing device 430 to steal the second-level authentication key.

[0031] Since the production line writing device 430 does not have the function of decrypting the key data, the production line writing device 430 transfers the encrypted key data to the intelligent device 200 (S433).

[0032] The device kernel application of the intelligent device 200 receives the encryption key data provided by the production line write device 430, and performs a decryption operation on the encryption key data according to the inverse algorithm (e.g., deobfuscation algorithm) of the encryption algorithm (e.g., obfuscation algorithm) used by the key server 100 (S202), and then uses the key data obtained by decrypting the encryption key data (which is the first managed key Key_root 110 in this case) to write the key data to the write-protected storage medium (e.g., OTP storage medium) of the intelligent device 200 to form a hardware write key (S203). After the writing is completed, the device kernel application of the intelligent device 200 discards the key data used during writing.

[0033] A second developer 420 (e.g., a development group of the owner of the protected intelligent application) provides the authentication plaintext to the second administrator 520 (S421) for encryption with the second managed key Key_alg 120 (S522). After receiving the authentication ciphertext provided by the second administrator 520 (S523), the second developer 420 embeds the authentication ciphertext and the authentication plaintext in the protected intelligent application (S422). Here, the authentication ciphertext is embedded in the protected intelligent application with unlimited access rights, and the authentication plaintext is embedded to block the access of the device kernel application. After encrypting the authentication plaintext with the second managed key to obtain the authentication ciphertext, the second administrator sends the authentication ciphertext to the second developer. The second developer embeds the authentication ciphertext in the protected intelligent application with unlimited access rights, and embeds the authentication plaintext in the protected intelligent application to block the access of the device kernel application.

[0034] Figure 3 is a schematic diagram of the optimization principle of the valid key allocation plan as shown in Figure 1. Figure 4 is a schematic flow chart of an example of the valid key allocation plan as shown in Figure 3. As an extension, the process of generating the authentication ciphertext by encrypting the authentication plaintext may be performed by the second developer 420. For example, the key server 100 may issue and store the second authentication key Key_ladder 130 to the second administrator 520 (S107) and the second developer 420 (S108) respectively.

[0035] The second administrator 520 creates a plaintext encryption tool for realizing the deceptive encryption (S522) and provides it to the second developer 420 (S523). The deceptive encryption performs an encryption operation using the second-class authentication key Key_ladder 130 as an input key and the second managed key Key_alg 120 as a true key. Here, the deceptive encryption means an encryption operation in which the input key is different from the true key, that is, encryption is performed using the second managed key without using the input second-class authentication key.

[0036] Therefore, the second developer 420 uses the stored second-level authentication key Key_ladder 130 to encrypt the authentication plaintext with a plaintext encryption tool provided by the second administrator 520 (S421'), and obtains an authentication ciphertext encrypted with the second managed key Key_alg 120 as the true key. Then, the second developer 420 embeds the authentication ciphertext and the authentication plaintext into the protected intelligent application (S422). Here, the authentication ciphertext is embedded into the protected intelligent application with unlimited access authority, and the authentication plaintext is embedded to block the access of the device kernel application.

[0037] The above description of the authorized key configuration is intended to facilitate understanding of the key relationship in which the first managed key Key_root 110 (also called the root key) is used to write to the intelligent device, the second managed key Key_alg 120 (also called the first key of the intelligent application) is used to generate an authentication ciphertext for the protected intelligent application, and the second authentication key Key_ladder 130 is used to trigger decryption authentication or further trigger encryption of the ciphertext, and it can be understood that the details of the operation process, the identities of each party and key distribution in the above authorized key configuration do not constitute any necessary restrictions on the key relationship.

[0038] A method for authenticating the calling authority of a protected intelligent application using the first managed key Key_root 110, the second managed key Key_alg 120, and the second level authentication key Key_ladder 130 having the above key relationship will now be described in detail.

[0039] In this application, the specific type of the intelligent device is not limited. The intelligent device may be any device that can load and execute an intelligent application. As an example, if the intelligent device is a smart camera or digital video recorder, the protected intelligent application may be an intelligent analysis algorithm (e.g., an algorithm such as target identification or target trajectory analysis, or a client of a device such as a video camera or digital video recorder). As an example, if the intelligent device is a drone equipped with a camera head, the protected intelligent application may be an application that controls the head.

[0040] 5 is an exemplary flowchart of a method for authenticating the invocation authority of a protected intelligent application according to an embodiment of the present application. Referring to FIG. 5, when a protected intelligent application is loaded into an intelligent device (S500), the method for authenticating the invocation authority of a protected intelligent application according to the embodiment includes the following steps performed by a device kernel application of the intelligent device:

[0041] S510: Obtain an authentication ciphertext in a protected intelligent application.

[0042] S530: Call a hardware decryption module, issue a kernel embedded key previously embedded in the device kernel application and the obtained authentication ciphertext to the hardware decryption module, and In S531, reading a hardware write key from a write-protected storage medium of an intelligent device; In S532, a kernel embedding key that has been embedded in advance in a device kernel application is decrypted using a hardware write key in a write-protected storage medium; In S533, the authentication ciphertext is decrypted using a decryption key obtained by decrypting the kernel embedding key; Execute the command.

[0043] For example, the second-level authentication key Key_ladder is obtained by performing an encryption operation based on a first encryption algorithm on a second managed key Key_alg using a first managed key Key_root, and the authentication ciphertext is obtained by encrypting a sample plaintext (i.e., authentication plaintext) using the second managed key Key_alg. Correspondingly, the hardware decryption module performs a decryption operation based on a first decryption algorithm (a reverse algorithm of the first encryption algorithm) on the kernel embedded key using a hardware write key, and the hardware decryption module performs a decryption operation based on a second decryption algorithm (a reverse algorithm of the second encryption algorithm) on the authentication ciphertext using a decryption key obtained by decrypting the kernel embedded key.

[0044] As a result, when the kernel embedded key is a second-level authentication key Key_ladder obtained by encrypting the second managed key Key_alg using the first managed key Key_root, and the hardware write key is the first managed key Key_root, the decryption key obtained by decrypting the kernel embedded key is the second managed key Key_alg.

[0045] If the authentication ciphertext is obtained by performing deceptive encryption on a sample plaintext using the second-level authentication key Key_ladder as the input key and the second managed key Key_alg as the true key, the deceptive encryption performs a decryption operation based on a first decryption algorithm (the inverse algorithm of the first encryption algorithm) on the input key using the first managed key Key_root, and performs an encryption operation based on the second encryption algorithm using the deceptive key (second managed key Key_alg) obtained by decrypting the input key as the true key.

[0046] S550: The protected intelligent application provides the decrypted plaintext obtained by decrypting the authentication ciphertext returned by the call to the hardware decryption module in S600 to the protected intelligent application to verify the consistency of the decrypted plaintext with the sample plaintext and determine whether to grant the device kernel application calling authority.

[0047] Here, if the decryption key obtained by decrypting the kernel-embedded key is the second managed key Key_alg, the decrypted plaintext obtained by decrypting the authentication ciphertext matches the sample plaintext in the protected intelligent application to which access of the device kernel application has been blocked.

[0048] According to the above process, the device kernel application calls the hardware decryption module, so that the intelligent device can decrypt the authentication ciphertext of the protected intelligent application using the kernel embedded key of the device kernel application and the hardware write key of the write-protected storage medium. Then, only when the kernel embedded key is a second-level authentication key Key_ladder obtained by encrypting the second managed key Key_alg using the first managed key Key_root and the hardware writing key is the first managed key Key_root, can the correct second managed key Key_alg be obtained to decrypt the authentication ciphertext, and a decrypted plaintext that matches the sample plaintext can be obtained through decryption, so that the protected intelligent application passes the consistency verification and grants the device kernel application the calling authority.

[0049] Therefore, the right to use a protected intelligent application can be restricted to intelligent devices that have correctly configured the second-level authentication key Key_ladder and written the first managed key Key_root, thereby preventing malicious piracy in which the protected intelligent application is executed on an unauthorized device.

[0050] Fig. 6 is a schematic diagram of an unauthorized key allocation behavior that can be prevented by the method for authenticating the call authority as shown in Fig. 1. Referring to Fig. 6, when a plagiarist 610 imitates the hardware of an intelligent device and its loaded device kernel application, it is difficult for the plagiarist 610 to simultaneously obtain the second-level authentication key Key_ladder and the first managed key Key_root, so that the counterfeit intelligent device cannot obtain the call authority of the protected intelligent application 300.

[0051] Figure 7 is a schematic flow chart of an example of a method for authenticating invocation authority as shown in Figure 5. Referring to Figure 7, the protected intelligent application includes an intelligent application kernel 310, an application verification module 320, an access interface 331 and a verification interface 332 that grant access authority to the device kernel application, and a invocation interface 390 that provides limited access authority to the device kernel application.

[0052] Here, the access interface 331, the verification interface 332 and the call interface 390 may all be APIs (Application Programming Interfaces), and the authentication cryptogram embedded in the protected intelligent application with unlimited access privileges can be accumulated in the access interface 331, and the authentication plaintext embedded in the protected intelligent application can be hiddenly accumulated in the verification module 320 to block the access of device kernel applications.

[0053] 7, the device kernel application obtains the authentication ciphertext by reading the access interface 331 of the protected intelligent application in S510. Then, the device kernel application sends the decrypted plaintext to the verification interface 332 in S550, so that the application verification module 320 in the protected intelligent application can verify the consistency between the decrypted plaintext and the sample plaintext, and determine whether to grant the device kernel application the calling authority based on the verification result.

[0054] 7, the method for authenticating the calling authority further includes, after S550, S570, which is executed by the device kernel application, receiving a verification result returned by the protected intelligent application (application verification module 320), and recognizing the verification result to determine whether there is a right to call the protected intelligent application, i.e., obtaining a successful call response to the intelligent application kernel 310 by accessing the call interface 390.

[0055] Figure 8 is an extended flowchart in which the method for authenticating the call authority as shown in Figure 5 supports the legitimate key placement example as shown in Figure 2. Referring to Figure 8, before the protected intelligent application is loaded into the intelligent device (e.g., the intelligent device is in the manufacturing stage of the production line), the method for authenticating the call authority of the protected intelligent application according to the embodiment includes the following steps, which are executed by a device kernel application of the intelligent device: S810: Receive encryption key data provided by a production line writing device. S830: A decryption operation is performed on the encryption key data. S850: The encryption key data is decrypted to obtain key data, which is then written to a write-protected storage medium of the intelligent device to form a hardware write key.

[0056] Here, when the encryption key data provided by the production line writing device is from the key server, the key data obtained by decrypting the encryption key data is the first managed key Key_root.

[0057] As a more preferred optimization, the production line writing device's access rights to the key server are authenticated by a hot-pluggable encryption device (such as a dongle) connected to the production line writing device.

[0058] S870: After the writing is completed, the key data is discarded.

[0059] In addition, as a more preferred optimization solution, before S810, the method for authenticating the calling authority of the protected intelligent application of this embodiment includes the following steps, which are performed by the device kernel application of the intelligent device: in response to the authentication detection of the production line writing device, providing authentication information previously embedded in the device kernel application to the production line writing device.

[0060] Fig. 9 is a schematic diagram of an exemplary structure of an intelligent device according to an embodiment. Referring to Fig. 9, in this embodiment, the intelligent device (which may be expressed in the form of a smart card) includes an application loading module 910, a hardware decryption module 920, and a write-protected storage medium 930 (such as an OTP storage medium).

[0061] The application-loaded module 910 is for loading and executing a device kernel application, and when a protected intelligent application is recorded in the application-loaded module, the device kernel application is used to execute the calling authority authentication method described in the above embodiment, that is, to execute the process shown in FIG. 5 or FIG. 7, and can also be used to execute the process shown in FIG. 8.

[0062] The hardware decryption module 920 is for providing decryption support to device kernel applications loaded into the application-loaded module 910, i.e., it is used to perform steps S531, S532 and S533 in the process shown in FIG. 5 or FIG. 7.

[0063] A hardware write key is written to the write-protected storage medium 930. For example, the hardware write key is written to the write-protected storage medium 930 by the process shown in FIG.

[0064] In realizing the above-mentioned intelligent device, the application-loading module 910, the hardware decryption module 920, and the write-protected storage medium 930 (e.g., an OTP storage medium) can be integrated into one IC (Integrated Circuit) chip.

[0065] The intelligent device further includes a non-transitory computer-readable storage medium, which can be independent of the IC chip integrating the application-loaded module 910, the hardware decryption module 920, and the write-protected storage medium 930, and the non-transitory computer-readable storage medium stores instructions, some of which, when executed by a processor, such as an IC chip, can cause the processor, such as an IC chip, to load a device kernel application (loaded into the application-loaded module 910), and cause the device kernel application to perform the call authority authentication method described in the above embodiments, that is, to perform the process shown in FIG. 5 or FIG. 7, and can also perform the process shown in FIG. 8.

[0066] The non-transitory computer-readable storage medium may also include other instructions for causing a processor, such as the IC chip, to load a device kernel application (loaded into application loading module 910).

[0067] The algorithm for implementing the decoding process by the hardware decoding module 920 may be pre-solidified in the hardware decoding module 920 without using a method of loading a program from a non-transitory computer-readable storage medium.

[0068] In this application, the technical features of each preferred technical solution may be combined to form a technical solution unless they are inconsistent, and all of these technical solutions are within the scope of the disclosure of this application. The use of relational terms such as "first" and "second" is merely used to distinguish one entity or operation from another entity or operation, and does not necessarily require or suggest that such an actual relationship or sequence exists between these entities or operations. In addition, the terms "comprise", "include", and other variations are intended to cover a non-exclusive inclusion, such that a process, method, article, or device that includes a set of elements further includes not only those elements but also other elements not expressly listed, or further includes the inherent elements in such a process, method, article, or device. Unless otherwise limited, an element limited by "includes a ..." does not exclude that the process, method, article, or device that includes the above element further has other identical elements. Each embodiment in this specification is described in a related manner, but the important description of each embodiment is the difference from other embodiments, so that the same or similar parts between each embodiment may be referred to each other.

[0069] The above description is merely a preferred embodiment of the present application, and is not intended to limit the present application. Any amendments, equivalent replacements, modifications, etc. made within the scope of the spirit and principles of the present application are within the scope of protection of the present application.

[0070] (CROSS-REFERENCE TO RELATED APPLICATIONS) This application claims priority based on a Chinese patent application filed with the China Patent Office on April 3, 2020, bearing application number 202010259146.3 and entitled "Method for authenticating the call authority of protected intelligent applications and intelligent device," the entire contents of which are incorporated herein by reference.

Claims

1. A method for authenticating a call right of a protected intelligent application, when the protected intelligent application is loaded into an intelligent device, the method for checking the call right includes the following steps, which are performed by a device kernel application of the intelligent device: Obtaining an authentication ciphertext for the protected intelligent application; Invoke a hardware decryption module, issue a kernel-embedded key pre-embedded in the device kernel application and the obtained authentication ciphertext to the hardware decryption module, and make the hardware decryption module decrypt the kernel-embedded key using a hardware write key in a write-protected storage medium of the intelligent device, and decrypt the authentication ciphertext using a decryption key obtained by decrypting the kernel-embedded key, where the kernel-embedded key is a second-level authentication key obtained by encrypting a second managed key using the first managed key, and the hardware write key is the first managed key, and the decryption key obtained by decrypting the kernel-embedded key is the second managed key; The decrypted plaintext obtained by decrypting the authentication ciphertext returned by the call of the hardware decryption module is provided to the protected intelligent application so that the protected intelligent application can verify the consistency between the decrypted plaintext and the sample plaintext and determine whether to grant the device kernel application a calling authority, where the authentication ciphertext is obtained by encrypting the sample plaintext with the second managed key, and when the decryption key obtained by decrypting the kernel embedded key is the second managed key, the decrypted plaintext obtained by decrypting the authentication ciphertext is consistent with the sample plaintext in the protected intelligent application to which the device kernel application's access is blocked; A method for authenticating the invocation authority of a protected intelligent application.

2. The authenticated ciphertext is obtained by performing deceptive encryption on the sample plaintext using the second-level authentication key as an input key and the second managed key as a true key. The method of claim 1 .

3. the second-level authentication key is obtained by performing an encryption operation on the second managed key based on a first encryption algorithm using the first managed key; the authenticated ciphertext is obtained by performing an encryption operation on the sample plaintext using the second managed key based on a second encryption algorithm; The hardware decryption module performs a decryption operation on the kernel-embedded key based on a first decryption algorithm using the hardware write key, and the hardware decryption module performs a decryption operation on the authentication ciphertext based on a second decryption algorithm using a decryption key obtained by decrypting the kernel-embedded key; wherein the first decryption algorithm is an inverse algorithm of the first encryption algorithm, and the second decryption algorithm is an inverse algorithm of the second encryption algorithm; The method of claim 1 .

4. The authenticated ciphertext is obtained by performing a deceptive encryption based on a first decryption algorithm on the sample plaintext, where the deceptive encryption includes performing a decryption operation based on the first decryption algorithm on the input key using a first managed key, and performing an encryption operation based on a second encryption algorithm using the deceptive key obtained by decrypting the input key as a true key. The method of claim 3 .

5. Before the protected intelligent application is loaded into the intelligent device running the device kernel application, the method for authenticating the calling authority further includes the following steps, which are performed by the device kernel application of the intelligent device: receiving encryption key data provided by a production line writing device; A decryption operation is performed on the encryption key data, using key data obtained by decrypting the encryption key data to write to a write-protected storage medium of an intelligent device to form a hardware write key, where if the encryption key data provided by the production line write device is from a key server, the encryption key obtained by decrypting the encryption key data is a first managed key; After the writing is completed, the encryption key data is discarded. The method of claim 1 .

6. The access authority of the production line writing device to the key server is authenticated by a hot-pluggable encryption device connected to the production line writing device. The method of claim 5 .

7. Prior to receiving the encryption key data provided by the production line writing device, and in response to detecting an authentication of the production line writing device, providing the production line writing device with the authentication information pre-embedded in the device kernel application. The method of claim 5 .

8. The management right of the first managed key belongs to the first administrator; the management right of the second managed key belongs to a second administrator different from the first administrator; And the first administrator and the second administrator are different from the first developer to which the device kernel application belongs and the second developer to which the protected intelligent application belongs; The method of claim 2 .

9. The write-protected storage medium of the intelligent device is an OTP storage medium; The method of claim 1 .

10. An intelligent device, comprising: an application-loaded module for loading and executing a device kernel application; a hardware decryption module; and a write-protected storage medium; when a protected intelligent application is recorded in the application-loaded module, the device kernel application is used to execute the method for authenticating a call right according to any one of claims 1 to 9. Intelligent devices.

11. A non-transitory computer readable storage medium having instructions stored thereon that, when executed by a processor, cause the processor to load a device kernel application and cause the device kernel application to initiate execution of the method of authenticating call authority of any one of claims 1 to 9. A non-transitory computer-readable storage medium.

12. 1. A key placement method, comprising: Obtaining a first managed key of a first administrator, and writing the first managed key as a hardware write key to a write-protected storage medium of a designated intelligent device; obtaining a second managed key of a second administrator and setting the second managed key as an encryption key for a protected intelligent application; encrypting the second managed key with the first managed key to obtain a second-level authentication key, and embedding the second-level authentication key as a kernel embedding key in a device kernel application of the specified intelligent device. Key placement method.

Images