CN111090865B - Secret key authorization method and system - Google Patents
Secret key authorization method and system Download PDFInfo
- Publication number
- CN111090865B CN111090865B CN201911304078.1A CN201911304078A CN111090865B CN 111090865 B CN111090865 B CN 111090865B CN 201911304078 A CN201911304078 A CN 201911304078A CN 111090865 B CN111090865 B CN 111090865B
- Authority
- CN
- China
- Prior art keywords
- key
- program
- code
- execution environment
- escrow
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000000034 method Methods 0.000 title claims abstract description 56
- 238000013475 authorization Methods 0.000 title claims abstract description 53
- 238000012550 audit Methods 0.000 claims description 27
- 238000012795 verification Methods 0.000 claims description 24
- 238000012545 processing Methods 0.000 claims description 18
- 238000005516 engineering process Methods 0.000 abstract description 8
- 230000008569 process Effects 0.000 description 15
- 230000006399 behavior Effects 0.000 description 13
- 238000010586 diagram Methods 0.000 description 10
- 238000012986 modification Methods 0.000 description 10
- 230000004048 modification Effects 0.000 description 10
- 230000005540 biological transmission Effects 0.000 description 7
- 230000003190 augmentative effect Effects 0.000 description 5
- 230000003287 optical effect Effects 0.000 description 4
- 238000004891 communication Methods 0.000 description 3
- 238000011161 development Methods 0.000 description 3
- 230000006870 function Effects 0.000 description 3
- 239000011521 glass Substances 0.000 description 3
- 230000006872 improvement Effects 0.000 description 3
- 239000000463 material Substances 0.000 description 3
- 230000000644 propagated effect Effects 0.000 description 3
- 230000006978 adaptation Effects 0.000 description 2
- 238000003491 array Methods 0.000 description 2
- 238000004590 computer program Methods 0.000 description 2
- 238000012937 correction Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 239000000835 fiber Substances 0.000 description 2
- 230000004075 alteration Effects 0.000 description 1
- 238000013459 approach Methods 0.000 description 1
- 230000000712 assembly Effects 0.000 description 1
- 238000000429 assembly Methods 0.000 description 1
- 230000009286 beneficial effect Effects 0.000 description 1
- 230000014509 gene expression Effects 0.000 description 1
- 238000002955 isolation Methods 0.000 description 1
- 239000010977 jade Substances 0.000 description 1
- 230000007774 longterm Effects 0.000 description 1
- 238000004519 manufacturing process Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000010295 mobile communication Methods 0.000 description 1
- 239000003607 modifier Substances 0.000 description 1
- 238000012806 monitoring device Methods 0.000 description 1
- 230000002265 prevention Effects 0.000 description 1
- 230000002441 reversible effect Effects 0.000 description 1
- 239000004065 semiconductor Substances 0.000 description 1
- 239000004984 smart glass Substances 0.000 description 1
- 239000007787 solid Substances 0.000 description 1
- 241000894007 species Species 0.000 description 1
- 230000003068 static effect Effects 0.000 description 1
- 230000001360 synchronised effect Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
- 238000012800 visualization Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/602—Providing cryptographic facilities or services
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
- G06F21/6245—Protecting personal data, e.g. for financial or medical purposes
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Hardware Design (AREA)
- General Engineering & Computer Science (AREA)
- Software Systems (AREA)
- General Health & Medical Sciences (AREA)
- Physics & Mathematics (AREA)
- Health & Medical Sciences (AREA)
- General Physics & Mathematics (AREA)
- Bioethics (AREA)
- Databases & Information Systems (AREA)
- Medical Informatics (AREA)
- Storage Device Security (AREA)
Abstract
The embodiment of the specification discloses a secret key authorization method and a secret key authorization system, wherein the method comprises the following steps: a trusted key escrow program is created in the trusted execution environment, and the key is stored in a memory corresponding to the key escrow program. The key escrow program receives a request sent by the key using program for obtaining the key, and judges whether the key using program is a trusted application program in the trusted execution environment. If the key using program is a trusted application program in the trusted execution environment, the key escrow program sends the key to the key using program. The key escrow program records identification information of the key usage program that acquires the key, so that the third party can acquire the recorded identification information, and so that the third party can acquire the code of the key usage program based on the identification information. The trusted execution environment may be implemented based on SGX (software guard extensions) technology from Intel corporation.
Description
Technical Field
The present disclosure relates to the field of data processing, and in particular, to a method and system for key authorization.
Background
With the development of information technology, data is used as an important resource of an owner, and data privacy is more and more emphasized by people. In order to ensure the use security of data, one current way is to use data in a secure computing Environment provided by a Trusted Execution Environment (TEE), and the behavior of a program running in the Trusted Execution Environment is expected, that is, the privacy and security of user data can be ensured. However, in actual use, the program in the trusted execution environment necessarily needs to be upgraded by program code such as modification and correction. In order to ensure the privacy and security of the user data, the program after the modified and corrected code needs to be authenticated again to ensure that the behavior of the program running in the trusted execution environment is in accordance with the expectation. Therefore, it is necessary to provide a key authorization method and system.
Disclosure of Invention
One aspect of embodiments of the present specification provides a key authorization method. The method comprises the following steps: a trusted key escrow program may be created in a trusted execution environment, the keys stored in a corresponding memory of the key escrow program. The key escrow program receives a request sent by a key using program for obtaining the key, and judges whether the key using program is a trusted application program in a trusted execution environment. And if the key using program is a trusted application program in a trusted execution environment, the key escrow program sends the key to the key using program. The key escrow program records identity identification information of the key using program for obtaining the key, so that a third party can obtain the recorded identity identification information, and the third party can obtain the code of the key using program based on the identity identification information, and audit the key using program after key authorization based on the code.
Another aspect of embodiments of the present specification provides a key authorization method. The method comprises the following steps: the key using program sends a request for obtaining the key to a key hosting program, so that the key hosting program can respond to the request and can determine that the key using program is a trusted application program in a trusted execution environment, wherein the key hosting program is a trusted application program created in the trusted execution environment, and the key is stored in a memory corresponding to the key hosting program. And the key using program receives the cipher text which is sent by the key escrow program and encrypted by the key. And the secret key uses a program to decrypt the ciphertext to obtain the plaintext of the secret key. The key using program sends the code of the key using program or the encrypted value of the code to a third party, so that the third party can audit the key using program based on the code or the encrypted value. Or the key using program stores the code of the key using program or the encrypted value of the code to a target storage platform, so that the third party can obtain the code or the encrypted value from the target storage platform and can audit the key using program based on the code or the encrypted value.
Another aspect of an embodiment of the present specification provides a key authorization system, the system including: the system comprises a creating module and a processing module, wherein the creating module is used for creating a trusted key escrow program in a trusted execution environment, and the key is stored in a memory corresponding to the key escrow program. And the receiving and judging module is used for receiving a request which is sent by a key using program and is used for acquiring the key and judging whether the key using program is a trusted application program in a trusted execution environment. The first sending module is used for sending the key to the key using program when the key using program is a trusted application program in a trusted execution environment. And the recording module is used for recording the identity identification information of the key using program for obtaining the key, so that a third party can obtain the recorded identity identification information, and the third party can obtain the code of the key using program based on the identity identification information, and audit the key using program after the key is authorized based on the code.
Another aspect of embodiments of the present specification provides a key authorization system. Applied to a key usage program, the system comprising: a second sending module, configured to send a request for obtaining the key to a key escrow program, so that the key escrow program can respond to the request, and can determine that the key using program is a trusted application program in a trusted execution environment, where the key escrow program is a trusted application program created in the trusted execution environment, and the key is stored in a memory corresponding to the key escrow program. And the receiving module is used for receiving the cipher text which is sent by the key escrow program and encrypted by the key. And the decryption module is used for decrypting the ciphertext to obtain the plaintext of the secret key. The sending storage module is used for sending the code of the third party or the encrypted value of the code to the third party so that the third party can audit the key using program based on the code or the encrypted value; or, the third party is configured to store the code of the key using program itself or the encrypted value of the code in a target storage platform, so that the third party can obtain the code or the encrypted value from the target storage platform, and can audit the key using program based on the code or the encrypted value.
Another aspect of an embodiment of the present specification provides a key authorization apparatus comprising at least one storage medium and at least one processor, the at least one storage medium storing computer instructions; the at least one processor is configured to execute the computer instructions to implement a key authorization method.
Another aspect of embodiments of the present specification provides a computer-readable storage medium storing computer instructions, and a computer executes a key authorization method when the computer instructions in the storage medium are read by the computer.
Drawings
The present description will be further explained by way of exemplary embodiments, which will be described in detail by way of the accompanying drawings. These embodiments are not intended to be limiting, and in these embodiments like numerals are used to indicate like structures, wherein:
FIG. 1 is a schematic diagram of an application scenario of a key escrow system according to some embodiments of the present description;
FIG. 2 is an exemplary flow diagram of a key authorization method according to some embodiments of the present description;
FIG. 3 is an exemplary flow diagram of another key authorization method according to some embodiments of the present description;
FIG. 4 is a block diagram of a key authorization system according to some embodiments of the present description;
FIG. 5 is a block diagram of a key authorization system according to some embodiments of the present description.
Detailed Description
In order to more clearly illustrate the technical solutions of the embodiments of the present disclosure, the drawings used in the description of the embodiments will be briefly described below. It is obvious that the drawings in the following description are only examples or embodiments of the present description, and that for a person skilled in the art, the present description can also be applied to other similar scenarios on the basis of these drawings without inventive effort. Unless otherwise apparent from the context, or otherwise indicated, like reference numbers in the figures refer to the same structure or operation.
It should be understood that "system", "device", "unit" and/or "module" as used herein is a method for distinguishing different components, elements, parts, portions or assemblies at different levels. However, other words may be substituted by other expressions if they accomplish the same purpose.
As used in this specification and the appended claims, the terms "a," "an," "the," and/or "the" are not intended to be inclusive in the singular, but rather are intended to be inclusive in the plural, unless the context clearly dictates otherwise. In general, the terms "comprises" and "comprising" merely indicate that steps and elements are included which are explicitly identified, that the steps and elements do not form an exclusive list, and that a method or apparatus may include other steps or elements.
Flow charts are used in this description to illustrate operations performed by a system according to embodiments of the present description. It should be understood that the preceding or following operations are not necessarily performed in the exact order in which they are performed. Rather, the various steps may be processed in reverse order or simultaneously. Meanwhile, other operations may be added to the processes, or a certain step or several steps of operations may be removed from the processes.
Currently, data privacy is more and more emphasized by people, and nowadays, with the development of society, joint use of data, which may be involved in cooperation among multiple parties, has become a normal state. How to protect the data privacy security is crucial in the process of joint use of data by multiple parties. One way to protect data privacy is to use a secure computing Environment technology provided by a Trusted Execution Environment (TEE) and isolated from an untrusted Environment for data usage, and the security isolation and the Trusted verification mechanism of the TEE make the TEE technology widely applied in the field of Confidential computing (Confidential computing), and various large enterprises (e.g., microsoft, international business machines corporation, google, and arroun) have introduced computing products based on the TEE.
SGX (software Guard extensions) is a TEE technology introduced by Intel corporation, and is one of the more widely used TEE technologies, and similarly includes SEV (secure Encrypted visualization) of AMD corporation, TrustZone of ARM corporation, and the like. For illustrative purposes only, the SGX is taken as an example in the present specification to describe the disclosed technical solution in detail, and is not intended to limit the scope of the present specification.
The SGX can protect application code and data from being leaked and maliciously tampered with by using a set of proprietary instruction sets. The core idea is that a Trusted Computing Base (TCB) only includes a program itself and basic hardware, even though an OS kernel, a Hypervisor, or even a BIOS cannot read a memory and data, so as to protect the security of the data. However, during actual use, the TEE program (the program running in the TEE) will have the need for code upgrade such as modification and correction. Each time a TEE program is upgraded or modified, the user needs to re-check the identity information of the TEE program (e.g., determine that its code has not been maliciously replaced or attacked, etc.). This causes great trouble to the users, especially when the number of users is large, once the program running in the TEE is upgraded, each user needs to be informed to verify the identity information again, which is very time-consuming and labor-consuming, and even difficult to do. Therefore, the present specification proposes a key escrow method, which provides a key escrow program, and performs program verification and key-related behavior based on the key escrow program, so as to solve the problem that the TEE program needs to be verified again after being upgraded or modified. The technical solution disclosed in the present specification is explained by the description of the drawings below.
FIG. 1 is a schematic diagram of an application scenario of a key escrow system according to some embodiments of the present description. As shown in fig. 1, the key escrow system 100 may provide a key escrow service to a user, for example, providing services such as key escrow, key inquiry, key authorization record, and the like to the user. The key escrow system 100 may include a server 110, a key owner terminal 120, a storage device 130, a network 140, and a key user terminal 150.
In some embodiments, the server 110 may be used to process key-related service requests, information, and/or data, e.g., service requests for key escrow. In particular, the server may receive a service request from the key owner terminal 120 and process the service request to save the user key. For example, a trusted execution environment is deployed in the server 110 and a key escrow program is run in the trusted execution environment to escrow the user's keys through the key escrow program. In some embodiments, the server 110 may be a single server or a group of servers. The server farm can be centralized or distributed (e.g., the servers 110 can be distributed systems). In some embodiments, the server 110 may be local or remote. For example, server 110 may access information and/or data stored in storage device 130, key owner terminal 120, through network 140. As another example, server 110 may be directly connected to storage device 130, key owner terminal 120 to access stored information and/or data. In some embodiments, the server 110 may be implemented on a cloud platform. By way of example only, the cloud platform may include a private cloud, a public cloud, a hybrid cloud, a community cloud, a distributed cloud, between clouds, multiple clouds, the like, or any combination of the above.
In some embodiments, the server 110 may include a processing engine 112. Processing engine 112 may process data and/or information related to the key to perform one or more of the functions described herein. For example, the processing engine 112 may receive a key inquiry request sent by the key owner terminal 120, and send a key authorization record to the user. In some embodiments, the processing engine may authenticate the key usage program requesting the key, verifying whether the key usage program is located in the trusted execution environment. In some embodiments, processing engine 112 may include one or more processing engines (e.g., a single chip processing engine or a multi-chip processor). By way of example only, the processing engine 112 may include a Central Processing Unit (CPU), an Application Specific Integrated Circuit (ASIC), an application specific instruction set processor (ASIP), an image processing unit (GPU), a physical arithmetic processing unit (PPU), a Digital Signal Processor (DSP), a Field Programmable Gate Array (FPGA), a Programmable Logic Device (PLD), a controller, a microcontroller unit, a Reduced Instruction Set Computer (RISC), a microprocessor, or the like, or any combination thereof.
In some embodiments, the key owner terminal 120 and/or the key user terminal 150 may be smart devices directly associated with the request. In some embodiments, the key owner terminal 120 may be a terminal that possesses the key and the key user terminal 150 may be a terminal that uses the key. The key owner terminal 120 and/or the key user terminal 150 may be service requesters, for example, the key owner terminal 120 initiates a key escrow, key usage record lookup service request to the server 110, and the key user terminal 150 initiates a key usage request to the server 110. In some embodiments, the key owner terminal 120 may include a mobile device 120-1, a tablet 120-2, a laptop 120-3, or the like, or any combination thereof. In some embodiments, the mobile device 120-1 may include a smart home device, a wearable device, a smart mobile device, a virtual reality device, an augmented reality device, and the like, or any combination thereof. In some embodiments, the smart home devices may include smart lighting devices, smart appliance control devices, smart monitoring devices, smart televisions, smart cameras, interphones, and the like, or any combination thereof. In some embodiments, the wearable device may include a smart bracelet, smart footwear, smart glasses, smart helmet, smart watch, smart wear, smart backpack, smart accessory, or the like, or any combination thereof. In some embodiments, the smart mobile device may include a smart phone, a Personal Digital Assistant (PDA), a gaming device, a navigation device, a point of sale (POS), or the like, or any combination thereof. In some embodiments, the virtual reality device and/or the augmented reality device may include a virtual reality helmet, virtual reality glasses, virtual reality eyeshields, enhanced virtual reality helmets, augmented reality glasses, augmented reality eyeshields, and the like, or any combination thereof. For example, the virtual reality device and/or augmented reality device may include Google Glass, Oculus Rift, HoloLens, or Gear VR, among others. In some embodiments, the key user terminal 150 may be a similar or identical device as the key owner terminal 120.
In some embodiments, storage device 130 may be connected to network 140 to communicate with one or more components (e.g., server 110, key owner terminal 120, key user terminal 150) in key authorization system 100. One or more components in key authorization system 100 may access data or instructions stored in storage device 130 through network 14. In some embodiments, storage 130 may be directly connected or in communication with one or more components in key authorization system 100 (e.g., server 110, key owner terminal 120, key user terminal 150, etc.). In some embodiments, storage device 130 may be part of server 110.
Fig. 2 is an exemplary flow diagram of a key authorization method according to some embodiments of the present description. The flow 200 may be performed by a processing device (e.g., server 110). The trusted execution environment may be deployed in a server, for example, the process 200 may be stored in the server in the form of a program or instructions that, when executed in the trusted execution environment, may implement the process 200. As shown in fig. 2, the process 200 may include:
step 202, a trusted key escrow program is created in a trusted execution environment, and the key is stored in a memory corresponding to the key escrow program. Step 202 may be performed by the creation module 410.
In some embodiments, the trusted execution environment may be deployed in a smart device, for example, the trusted execution environment may be deployed in the server 110. The key escrow program may be a piece of instructions that a computer can recognize and execute, for example, the key escrow program may be a piece of code or a result of a compilation of a piece of code. The key escrow program may be used to escrow keys, verify identity information of a program (e.g., a program running in a trusted execution environment), authorize keys to other programs, record key authorization behavior, provide a user with key authorization record query functionality, and the like, or any combination thereof. Creating a trusted key escrow program may be a compilation result obtained by a user independently writing a piece of code in a trusted execution environment, or a compilation result obtained by putting code into a trusted execution environment after other users (e.g., a client of the user) write the code and the logic of the code is checked by the user to be in accordance with expectations (i.e., only expected behavior will be performed). After the code of the key escrow program is verified once by a user, the code logic of the key escrow program is simple, the key escrow program can be kept stable after the development is completed, the key escrow program cannot be frequently upgraded, the frequency of auditing the key escrow program by the user can be reduced, and the use experience of the user is improved.
In some embodiments, the key escrow program may have its corresponding memory, e.g., Cache (Cache). The user may place the key into a memory corresponding to the key escrow program. Information and/or data in the memory can be accessed to obtain the key only by the key escrow program based on a security environment provided by the trusted execution environment and isolated from the untrusted environment, so that the key stored in the memory can be ensured not to be intercepted or leaked by malicious attacks.
Step 204, receiving a request sent by a key using program for obtaining the key, and determining whether the key using program is a trusted application program in a trusted execution environment. If yes, go to step 206, otherwise go to step 208. Step 204 may be performed by the reception determination module 420.
In some embodiments, the key using program may be a program that requires the use of a key. The key usage program may encrypt and/or decrypt data using a key. When the key using program needs to use the key, a request to obtain the key may be sent to the key escrow program over a network (e.g., network 140). The request may include identity information of the key usage program, the requested key, user data information desired to be accessed, etc.
In some embodiments, after receiving the request, the key management program needs to determine whether the key using program that sent the request is a trusted application program in a trusted execution environment, and will not perform illegal activities using the key and reveal the key. As an example, determining whether the key usage program is a trusted application in a trusted execution environment may be performed in the following manner:
the key escrow program may receive a verification result of the verification platform regarding hardware information used by the key usage program, and determine whether the key usage program is a trusted application in the trusted execution environment based on the verification result. The verification platform may be a service side of a trusted execution environment where the key using program is located, for example, when the trusted execution environment is an SGX, the third party is an Intel service side; and when the trusted execution environment is TrustZone, the third party is an Arm service party and the like. A trusted application may refer to a program that runs in a trusted execution environment and whose code logic is expected to perform no illegal actions (e.g., reveal a key, use a key illegally, etc.). As an example, taking a key escrow program and a key usage program as programs in an SGX (Software Guard Extensions) environment, it is exemplified how the key escrow program judges whether or not the key usage program is a trusted application.
When the key consuming program runs in the SGX, in order to prove its identity information to the key escrow program to request to obtain the key, the SGX may provide credentials (e.g., verification of hardware information) that reflect that the key consuming program is being protected by the SGX's envelope (trusted zone), with a special listening envelope in the SGX that may create a signature key EPID (e.g., private key of the trusted execution environment) for SGX platform authentication, which is only accessible by the listening envelope when the envelope system is running. Assuming that the key management program needs to authenticate the key usage program, the key usage program may request the hardware (e.g., the key user terminal 150) where the key usage program is located to generate a REPORT structure REPORT (e.g., the hardware information of the key usage program running in the trusted execution environment), the querying Enclave first verifies whether the key usage program runs on the same platform (e.g., whether the key usage program runs in the SGX) through the REPORT structure, and after the verification is passed, the REPORT is encapsulated by the queuing envelope into a queue structure, the main components of the structure include REPORT and envelope more information, then the Quoting envelope uses the key EPID to sign the quantum structure, obtains a verification result (for example, a verification result of the hardware information used by the key usage program), and then sends the verification result to the key escrow program requesting verification to verify. The key using program is verified by using the key hosting program, the verification of the key using program can be automatically completed when the code of the key using program is upgraded and/or revised, and a new key using program applies for key authorization, and the manual operation of a user is not needed, so that the authorization safety of the key is ensured, and the user experience is improved.
After receiving the verification result, the key escrow program determines that the verification result includes a certificate structure authenticated by the signature, and the signature is correct, that is, it can be determined that the key using program runs in the trusted execution environment, and then step 206 is performed. Determining that the verification result does not include a signed and authenticated quantum structure or a signature error means that the key consuming program is not running in a trusted execution environment, and it is difficult to ensure that its code logic is in accordance with expectations, and therefore, in order to ensure user data and keys are secure, authorization to provide keys to the key consuming program may be denied.
In some embodiments, the key escrow program may send the key to the key usage program over a network (e.g., network 140). In some embodiments, the key escrow program may also send the key to the key usage program after storing the key to the encryption memory, by communicating with the key usage program through the encryption memory.
In some embodiments, the key escrow program sending the key to the key usage program may take the following form: the key escrow program encrypts the key with the public key of the key usage program to obtain a ciphertext. The key escrow program can send the ciphertext to the key using program, so that the key using program can decrypt the ciphertext to obtain the plaintext of the key by using the private key corresponding to the public key. In order to ensure security during key transmission, the key needs to be encrypted. The key using program runs in the trusted execution environment, and the security technology based on the trusted execution environment can ensure that the private key can be obtained only by the key using program, so that the security of the key when the key escrow program sends the key to the key using program can be ensured. In some embodiments, the plaintext of the key may include key parameters, key text, and the like.
It should be understood that the above-described manner of encrypting the key using the public key of the key using program is only an example and is not intended to limit the present specification, for example, the encryption manner may include one or a combination of public key encryption technology, digital certificate, symmetric encryption, asymmetric encryption, and the like.
In some embodiments, the identity information of the key usage program is used to distinguish the identity of the key usage program, which may be a program number (e.g., ID XXX) of the key usage program. The third party may be the owner of the key, e.g., the key owner terminal 120. As another example, the key escrow program may be commonly used by multiple partners belonging to a project to constrain the key usage behavior of the partners, and the third party may be each partner participating in the cooperation, such as the key owner terminal 120-1, the key owner terminal 120-2, the key owner terminal 120-3, and so on. The third party can search which key using programs request the authorized key through the identity identification information of the key using programs recorded by the key escrow program, and then verify the code logic of the key using programs authorized by the key, and judge whether the code logic accords with the expectation, so that the key is prevented from being leaked, and the use safety of the key is ensured. For example, when a third party wants to audit whether a behavior of a certain key using program using a key after requesting the key is expected, the third party may first request the key hosting program for obtaining the identification information of the key using program according to the program number (e.g., IDXXX) of the key using program to be audited, and then obtain the code of the key using program, the code compiling result of the key using program, the hash value of the key using program code, and the like according to the identification information. The third party can audit whether the code logic and compiling result of the key using program are in accordance with the expectation. Further, the third party may also obtain the current running code of the key using program, compare whether the current running code is consistent with the program code obtained based on the identification information, whether the upgrade or modification behavior is expected, whether the hash value of the code is consistent (for example, the hash value of the code should be consistent if the key using program has not been upgraded or modified), and so on, and further, by auditing the code logic of the key using program. The audit may be a way to manually inspect the source code.
As an example, the third party may obtain the identification information of the key using program in various ways, and may use the method shown in the following embodiments, or may use other methods, which is not limited in this specification.
In some embodiments, the key escrow program may send the identification information of the key usage program that obtained the key to the third party so that the third party can audit after receiving the identification information. For example, the transmission may be by way of secure e-mail.
In some embodiments, the key escrow program may store the identification information to the target storage platform to enable a third party to obtain the identification information from the target storage platform. The target storage platform may comprise any securely authenticated storage platform, such as a blockchain platform, a securely authenticated database, a securely authenticated storage device (e.g., memory in a trusted execution environment), and so forth. The storage platform which stores the identity information value and is subjected to security authentication can ensure the security of the stored identity information, for example, taking a target storage platform as a block chain as an example, the block chain platform has the characteristics of decentralization, openness, tamper resistance, traceability, abandonment resistance and the like, and the identity information is stored to the block chain platform, so that the security of the identity information can be effectively ensured by utilizing the characteristics of the block chain, and further, whether the behavior of a third party which can correctly audit a key using program through the identity information meets expectations is ensured.
It should be noted that the above description related to the flow 200 is only for illustration and description, and does not limit the applicable scope of the present specification. Various modifications and alterations to flow 200 will be apparent to those skilled in the art in light of this description. However, such modifications and variations are intended to be within the scope of the present description.
FIG. 3 is an exemplary flow diagram of another key authorization method according to some embodiments of the present description. Process 300 may be performed by a processing device (e.g., key user terminal 150). As shown in fig. 3, the process 300 may include:
In some embodiments, the key usage program may send a request for obtaining a key to the key escrow program over a network (e.g., network 140). The key escrow program may authenticate the key usage program based on the received request to obtain the key to determine whether the key usage program is a trusted application in the trusted execution environment. Further description of the key escrow program determining the key usage program as a trusted application in a trusted execution environment, and the key escrow program, may be found elsewhere in this specification, for example, fig. 2 and its related description, which are not repeated here.
In some embodiments, the key usage program may receive encrypted ciphertext for the key sent by the key escrow program over a network (e.g., network 140). In some embodiments, the key usage program may also communicate directly with an encryption memory that stores ciphertext to receive key-encrypted ciphertext sent by the key escrow program. For example, the key escrow program may store the encrypted ciphertext to the encryption memory and then communicate the ciphertext with the key usage program through the encryption memory to send the ciphertext to the key usage program. Further description may be found elsewhere in this specification, for example, fig. 2 and its associated description.
And step 306, decrypting the ciphertext to obtain the plaintext of the key. Step 306 may be performed by decryption module 530.
In some embodiments, the key usage program may decrypt the ciphertext in a manner corresponding to the key encryption. For example, the key escrow program may encrypt the key using the public key of the key usage program, which decrypts the ciphertext using its own private key. In some embodiments, the key usage program may decrypt the key using a corresponding decryption method based on the way the key is encrypted by the key escrow program. For example, the manner in which the key escrow program encrypts the key may include one or a combination of public key encryption techniques, digital certificates, symmetric encryption, asymmetric encryption, and the like. Further description may be found elsewhere in this specification, for example, fig. 2 and its associated description. After decrypting the plaintext of the key, execution of step 308 or step 310 may be entered.
And 308, sending the code of the third party or the encrypted value of the code to the third party so that the third party can audit the key using program based on the code or the encrypted value. Step 308 may be performed by the transmit memory module 540.
In some embodiments, to apply for key authorization to a third party (e.g., the key owner terminal 120, the owner or creator of the key escrow program), the key usage program may send its code or encrypted value of the code to the third party for auditing. The sending can be performed based on e-mails which are subjected to security certification and the like, and a third party can check the received code of the key using program to judge whether the code logic of the code accords with expectations or not and whether the key leaks or not and other security problems exist. The encrypted value of the code can be a ciphertext obtained by encrypting the code based on a public key of a third party, the third party decrypts the ciphertext to obtain a plaintext of the code by using a private key corresponding to the public key of the third party after receiving the ciphertext, and then audits the code, so that the code which is expected to be kept secret can be ensured not to be disclosed. Further description of the auditing of the key usage program by a third party may be found elsewhere in this specification, for example, in fig. 2 and its associated description.
In some embodiments, the target storage platform may comprise any securely authenticated storage platform, such as a blockchain platform, a securely authenticated database, a securely authenticated storage device (e.g., memory in a trusted execution environment), and so forth. In some embodiments, the key using program may store its own code or an encrypted value of the code to the target storage platform through a network (e.g., the network 140), or may store the code after storing the code in an encrypted storage and then communicating with the target storage platform through the encrypted storage. The third party may obtain the code or cryptographic value by sending a request or communication to the target storage platform. For example, the third party may obtain identification information of the key usage program that needs to be audited, and request a corresponding code or encrypted value from the target storage platform based on the identification information. More description can be found elsewhere in this specification, for example, fig. 2 and its related description, which are not repeated here.
It should be noted that the above description of the process 300 is for illustration and description only and is not intended to limit the scope of the present disclosure. Various modifications and changes to flow 300 will be apparent to those skilled in the art in light of this description. However, such modifications and variations are intended to be within the scope of the present description.
FIG. 4 is a block diagram of a key authorization system according to some embodiments of the present description. As shown in fig. 4, the system may include a creation module 410, a reception determination module 420, a first transmission module 430, and a recording module 440.
The creation module 410 may create a trusted key escrow program.
In some embodiments, the creation module 410 may create a key escrow program in a trusted execution environment deployed by a server (e.g., server 110), with keys stored in a corresponding memory of the key escrow program. The key escrow program may be a piece of instructions that a computer can recognize and execute, for example, the key escrow program may be a piece of code or a result of a compilation of a piece of code. The key escrow program may be used to escrow keys, verify identity information of a program (e.g., a program running in a trusted execution environment), authorize keys to other programs, record key authorization behavior, provide a user with key authorization record query functionality, and the like, or any combination thereof. Creating a trusted key escrow program may be a compilation result obtained by a user independently writing a piece of code in a trusted execution environment, or a compilation result obtained by putting code into a trusted execution environment after other users (e.g., a client of the user) write the code and the logic of the code is checked by the user to be in accordance with expectations (i.e., only expected behavior will be performed). In some embodiments, the trusted execution environment is a Software protection extension policy (SGX) based trusted execution environment.
The receiving determination module 420 may receive a request sent by a key using program to obtain the key, and determine whether the key using program is a trusted application in a trusted execution environment.
In some embodiments, the receipt determination module 420 may send a request to the key escrow program over a network (e.g., network 140) to obtain the key. The request may include identity information of the key usage program, the requested key, user data information desired to be accessed, etc. In some embodiments, the receiving determining module 420 may determine whether the key using program sending the request is a trusted application program in the trusted execution environment after receiving the request, and may not perform illegal activities using the key and reveal the key. A verification result of the verification platform regarding hardware information used by the key usage program may be received, and it may be determined whether the key usage program is a trusted application in the trusted execution environment based on the verification result.
The first transmission module 430 may transmit the key to the key usage program.
In some embodiments, the first sending module 430 may send the key to the key usage program over a network (e.g., network 140). In some embodiments, the key escrow program may also send the key to the key usage program after storing the key to the encryption memory, by communicating with the key usage program through the encryption memory.
In some embodiments, to send the key to the key using program, the first sending module 430 is further configured to: encrypting the secret key by using a public key of the secret key using program to obtain the ciphertext; and sending the ciphertext to the key using program, so that the key using program can decrypt the ciphertext to obtain the plaintext of the key by using a private key corresponding to the public key.
The recording module 440 may record the identity information of the key usage program that obtained the key.
In some embodiments, the recording module 440 may record identification information of the key usage program that obtained the key. So that a third party can obtain the recorded identification information and obtain the code of the key using program based on the identification information, and audit the key using program after key authorization based on the code. The identification information of the key usage program is used to distinguish the identity of the key usage program, and may be a program number (e.g., ID XXX) of the key usage program. The third party may be the owner of the key, e.g., the key owner terminal 120. As another example, the key escrow program may be commonly used by multiple partners belonging to a project to constrain the key usage behavior of the partners, and the third party may be each partner participating in the cooperation, such as the key owner terminal 120-1, the key owner terminal 120-2, the key owner terminal 120-3, and so on.
In some embodiments, to record the identification information of the key usage program that obtained the key, so that the third party can obtain the identification information of the record, the recording module 440 may be further configured to: and sending the identity identification information of the key using program for acquiring the key to the third party so that the third party can receive the identity identification information, or storing the identity identification information to a target storage platform so that the third party can acquire the identity identification information from the target storage platform. In some embodiments, the target storage platform is a blockchain platform, or a securely authenticated database.
For a detailed description of the modules of the key authorization system, reference may be made to the flowchart section of this application, for example, the relevant description of fig. 2 or fig. 3.
FIG. 5 is a block diagram of a key authorization system according to some embodiments of the present description. As shown in fig. 5, the system may include a second transmitting module 510, a receiving module 520, a decrypting module 530, and a transmitting storage module 540.
The second sending module 510 may send a request to the key escrow program to obtain the key.
In some embodiments, the second sending module 510 may send a request for obtaining a key to a key management program, so that the key management program can respond to the request and can determine that the key using program is a trusted application program in a trusted execution environment, where the key management program is a trusted application program created in a trusted execution environment, and the key is stored in a corresponding memory of the key management program. In some embodiments, the second sending module 510 may send a request for obtaining a key to the key escrow program over a network (e.g., network 140).
The receiving module 520 may receive the ciphertext encrypted by the key sent by the key escrow program.
In some embodiments, the receiving module 520 may receive the encrypted ciphertext of the key sent by the key escrow program over a network (e.g., network 140). In some embodiments, the key usage program may also communicate directly with an encryption memory that stores ciphertext to receive key-encrypted ciphertext sent by the key escrow program. For example, the key escrow program may store the encrypted ciphertext to the encryption memory and then communicate the ciphertext with the key usage program through the encryption memory to send the ciphertext to the key usage program.
The decryption module 530 may decrypt the ciphertext to obtain a plaintext of the key.
In some embodiments, the decryption module 530 may decrypt the ciphertext in a manner corresponding to key encryption. For example, the key escrow program may encrypt the key using the public key of the key usage program, which decrypts the ciphertext using its own private key. In some embodiments, the key usage program may decrypt the key using a corresponding decryption method based on the way the key is encrypted by the key escrow program. For example, the manner in which the key escrow program encrypts the key may include one or a combination of public key encryption techniques, digital certificates, symmetric encryption, asymmetric encryption, and the like.
The transmission storage module 540 may transmit the own code or the encrypted value of the code to the third party and store the own code or the encrypted value of the code to the target storage platform.
In some embodiments, the transmission storage module 540 may transmit the code of the key usage program itself or the encrypted value of the code to a third party to enable the third party to audit the key usage program based on the code or the encrypted value. In some embodiments, the sending storage module 540 may store the code of the key using program itself or the encrypted value of the code to the target storage platform, so that the third party can obtain the code or the encrypted value from the target storage platform and audit the key using program based on the code or the encrypted value. In some implementations, the target storage platform is a blockchain platform or a securely authenticated database and the trusted execution environment is a software protection extension policy-based trusted execution environment.
For a detailed description of the modules of the key authorization system, reference may be made to the flowchart section of this application, for example, the relevant description of fig. 2 or fig. 3.
It should be appreciated that the systems and their modules shown in fig. 4 and/or 5 may be implemented in a variety of ways. For example, in some embodiments, the system and its modules may be implemented in hardware, software, or a combination of software and hardware. Wherein the hardware portion may be implemented using dedicated logic; the software portions may be stored in a memory for execution by a suitable instruction execution system, such as a microprocessor or specially designed hardware. Those skilled in the art will appreciate that the methods and systems described above may be implemented using computer executable instructions and/or embodied in processor control code, such code being provided, for example, on a carrier medium such as a diskette, CD-or DVD-ROM, a programmable memory such as read-only memory (firmware), or a data carrier such as an optical or electronic signal carrier. The system and its modules in this specification may be implemented not only by hardware circuits such as very large scale integrated circuits or gate arrays, semiconductors such as logic chips, transistors, or programmable hardware devices such as field programmable gate arrays, programmable logic devices, etc., but also by software executed by various types of processors, for example, or by a combination of the above hardware circuits and software (e.g., firmware).
It should be noted that the above description of the key authorization system and the modules thereof is merely for convenience of description, and does not limit the present specification to the scope of the illustrated embodiments. It will be appreciated by those skilled in the art that, given the teachings of the present system, any combination of modules or sub-system configurations may be used to connect to other modules without departing from such teachings. For example, in some embodiments, for example, in fig. 4, the creating module 410, the receiving determining module 420, the first sending module 430, and the recording module 440 may be different modules in one system, or may be a module that implements the functions of two or more modules described above. For example, the creating module 410 and the receiving judgment processing module 420 may be two modules, or one module may have both the acquiring and processing functions. For example, each module may share one memory module, and each module may have its own memory module. Such variations are within the scope of the present disclosure.
The beneficial effects that may be brought by the embodiments of the present description include, but are not limited to: (1) the key escrow program is created in the trusted execution environment, a user can escrow a key, verify a key using program and the like through the key escrow program, the code logic of the key escrow program is simple, the key escrow program can be kept stable after the key using program is developed, the problem that the user needs to perform key authorization for many times when the key using program is frequently upgraded is solved, and meanwhile the security of the key can be ensured based on the security characteristics of the trusted execution environment. (2) When the key using program wants to use and obtain the key, the key using program can be directly verified through the key escrow program without authorization of a user, and the user can audit through the key escrow program afterwards to determine the behavior that the key using program leaks the key, so that the security of the key is ensured. (3) The key authorization record is stored in the block chain, so that the property of the block chain such as non-tampering and loss prevention can be used for ensuring that an audit object is not tampered, and the correctness of an audit result is ensured. It is to be noted that different embodiments may produce different advantages, and in different embodiments, any one or combination of the above advantages may be produced, or any other advantages may be obtained.
Having thus described the basic concept, it will be apparent to those skilled in the art that the foregoing detailed disclosure is to be regarded as illustrative only and not as limiting the present specification. Various modifications, improvements and adaptations to the present description may occur to those skilled in the art, although not explicitly described herein. Such modifications, improvements and adaptations are proposed in the present specification and thus fall within the spirit and scope of the exemplary embodiments of the present specification.
Also, the description uses specific words to describe embodiments of the description. Reference throughout this specification to "one embodiment," "an embodiment," and/or "some embodiments" means that a particular feature, structure, or characteristic described in connection with at least one embodiment of the specification is included. Therefore, it is emphasized and should be appreciated that two or more references to "an embodiment" or "one embodiment" or "an alternative embodiment" in various places throughout this specification are not necessarily all referring to the same embodiment. Furthermore, some features, structures, or characteristics of one or more embodiments of the specification may be combined as appropriate.
Moreover, those skilled in the art will appreciate that aspects of the present description may be illustrated and described in terms of several patentable species or situations, including any new and useful combination of processes, machines, manufacture, or materials, or any new and useful improvement thereof. Accordingly, aspects of this description may be performed entirely by hardware, entirely by software (including firmware, resident software, micro-code, etc.), or by a combination of hardware and software. The above hardware or software may be referred to as "data block," module, "" engine, "" unit, "" component, "or" system. Furthermore, aspects of the present description may be represented as a computer product, including computer readable program code, embodied in one or more computer readable media.
The computer storage medium may comprise a propagated data signal with the computer program code embodied therewith, for example, on baseband or as part of a carrier wave. The propagated signal may take any of a variety of forms, including electromagnetic, optical, etc., or any suitable combination. A computer storage medium may be any computer-readable medium that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code located on a computer storage medium may be propagated over any suitable medium, including radio, cable, fiber optic cable, RF, or the like, or any combination of the preceding.
Computer program code required for the operation of various portions of this specification may be written in any one or more programming languages, including an object oriented programming language such as Java, Scala, Smalltalk, Eiffel, JADE, Emerald, C + +, C #, VB.NET, Python, and the like, a conventional programming language such as C, Visual Basic, Fortran 2003, Perl, COBOL 2002, PHP, ABAP, a dynamic programming language such as Python, Ruby, and Groovy, or other programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any network format, such as a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet), or in a cloud computing environment, or as a service, such as a software as a service (SaaS).
Additionally, the order in which the elements and sequences of the process are recited in the specification, the use of alphanumeric characters, or other designations, is not intended to limit the order in which the processes and methods of the specification occur, unless otherwise specified in the claims. While various presently contemplated embodiments of the invention have been discussed in the foregoing disclosure by way of example, it is to be understood that such detail is solely for that purpose and that the appended claims are not limited to the disclosed embodiments, but, on the contrary, are intended to cover all modifications and equivalent arrangements that are within the spirit and scope of the embodiments herein. For example, although the system components described above may be implemented by hardware devices, they may also be implemented by software-only solutions, such as installing the described system on an existing server or mobile device.
Similarly, it should be noted that in the preceding description of embodiments of the present specification, various features are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure aiding in the understanding of one or more of the embodiments. This method of disclosure, however, is not intended to imply that more features than are expressly recited in a claim. Indeed, the embodiments may be characterized as having less than all of the features of a single embodiment disclosed above.
Numerals describing the number of components, attributes, etc. are used in some embodiments, it being understood that such numerals used in the description of the embodiments are modified in some instances by the use of the modifier "about", "approximately" or "substantially". Unless otherwise indicated, "about", "approximately" or "substantially" indicates that the number allows a variation of ± 20%. Accordingly, in some embodiments, the numerical parameters used in the specification and claims are approximations that may vary depending upon the desired properties of the individual embodiments. In some embodiments, the numerical parameter should take into account the specified significant digits and employ a general digit preserving approach. Notwithstanding that the numerical ranges and parameters setting forth the broad scope of the range are approximations, in the specific examples, such numerical values are set forth as precisely as possible within the scope of the application.
For each patent, patent application publication, and other material, such as articles, books, specifications, publications, documents, etc., cited in this specification, the entire contents of each are hereby incorporated by reference into this specification. Except where the application history document does not conform to or conflict with the contents of the present specification, it is to be understood that the application history document, as used herein in the present specification or appended claims, is intended to define the broadest scope of the present specification (whether presently or later in the specification) rather than the broadest scope of the present specification. It is to be understood that the descriptions, definitions and/or uses of terms in the accompanying materials of this specification shall control if they are inconsistent or contrary to the descriptions and/or uses of terms in this specification.
Finally, it should be understood that the embodiments described herein are merely illustrative of the principles of the embodiments of the present disclosure. Other variations are also possible within the scope of the present description. Thus, by way of example, and not limitation, alternative configurations of the embodiments of the specification can be considered consistent with the teachings of the specification. Accordingly, the embodiments of the present description are not limited to only those embodiments explicitly described and depicted herein.
Claims (19)
1. A method of key authorization, the method comprising:
creating a trusted key escrow program in a trusted execution environment, the key being stored in a memory corresponding to the key escrow program;
the key escrow program receives a request for acquiring the key sent by a key using program, and judges whether the key using program is a trusted application program in a trusted execution environment;
if the key using program is a trusted application program in a trusted execution environment, the key escrow program sends the key to the key using program;
the key escrow program records identity identification information of the key using program for obtaining the key, so that a third party can obtain the recorded identity identification information, and the third party can obtain the code of the key using program based on the identity identification information, and audit the key using program after key authorization based on the code.
2. The method of claim 1, the determining whether the key usage program is a trusted application in a trusted execution environment, comprising:
the key escrow program receiving a verification result of a verification platform on hardware information used by the key usage program;
and judging whether the key using program is a trusted application program in a trusted execution environment or not based on the verification result.
3. The method of claim 1, the key escrow program recording identification information of the key usage program that acquired the key, to enable the third party to acquire the identification information of the record, comprising:
the key escrow program sends the identity information of the key using program for obtaining the key to the third party so that the third party can receive the identity information, or stores the identity information to a target storage platform so that the third party can obtain the identity information from the target storage platform.
4. The method of claim 3, wherein the target storage platform is a blockchain platform or a securely authenticated database.
5. The method of claim 1, the key escrow program sending the key to the key usage program, comprising:
the key escrow program encrypts the key by using a public key of the key using program to obtain a ciphertext;
and the secret key escrow program sends the ciphertext to the secret key using program, so that the secret key using program can decrypt the ciphertext by using a private key corresponding to the public key to obtain a plaintext of the secret key.
6. The method of claim 1, the trusted execution environment being a software protection extension policy based trusted execution environment.
7. A method of key authorization, the method comprising:
the key using program sends a request for obtaining the key to a key hosting program, so that the key hosting program can respond to the request and can determine that the key using program is a trusted application program in a trusted execution environment, wherein the key hosting program is a trusted application program created in the trusted execution environment, and the key is stored in a memory corresponding to the key hosting program;
the key using program receives a ciphertext which is sent by the key escrow program and encrypted by the key;
the cipher text is decrypted by the key using a program to obtain a plaintext of the key;
the key using program sends a code of the key using program or an encrypted value of the code to a third party so that the third party can audit the key using program based on the code or the encrypted value; or,
the key using program stores the code of the key using program or the encrypted value of the code to a target storage platform, so that the third party can obtain the code or the encrypted value from the target storage platform and audit the key using program based on the code or the encrypted value.
8. The method of claim 7, wherein the target storage platform is a blockchain platform or a securely authenticated database.
9. The method of claim 7, the trusted execution environment being a software protection extension policy based trusted execution environment.
10. A key authorization system for use with a key escrow program, the system comprising:
the system comprises a creating module, a storage module and a processing module, wherein the creating module is used for creating a trusted key escrow program in a trusted execution environment, and a key is stored in a memory corresponding to the key escrow program;
the receiving and judging module is used for receiving a request which is sent by a key using program and is used for acquiring the key, and judging whether the key using program is a trusted application program in a trusted execution environment;
the first sending module is used for sending the secret key to the secret key using program when the secret key using program is judged to be a trusted application program in a trusted execution environment;
and the recording module is used for recording the identity identification information of the key using program for obtaining the key, so that a third party can obtain the recorded identity identification information, and the third party can obtain the code of the key using program based on the identity identification information, and audit the key using program after the key is authorized based on the code.
11. The system of claim 10, wherein to determine whether the key usage program is a trusted application in a trusted execution environment, the reception determination module is further to:
receiving a verification result of a verification platform on hardware information used by the key using program;
and judging whether the key using program is a trusted application program in a trusted execution environment or not based on the verification result.
12. The system of claim 10, wherein to record identification information of the key usage program that obtained the key, such that the third party can obtain the identification information of the record, the recording module is further configured to:
and sending the identity identification information of the key using program for acquiring the key to the third party so that the third party can receive the identity identification information, or storing the identity identification information to a target storage platform so that the third party can acquire the identity identification information from the target storage platform.
13. The system of claim 12, wherein the target storage platform is a blockchain platform or a securely authenticated database.
14. The system of claim 10, wherein to send the key to the key usage program, the first sending module is further to:
encrypting the secret key by using the public key of the secret key using program to obtain a ciphertext;
and sending the ciphertext to the key using program, so that the key using program can decrypt the ciphertext to obtain the plaintext of the key by using a private key corresponding to the public key.
15. The system of claim 10, the trusted execution environment being a software protection extension policy based trusted execution environment.
16. A key authorization system applied to a key usage program, the system comprising:
a second sending module, configured to send a request for obtaining the key to a key escrow program, so that the key escrow program can respond to the request, and can determine that the key using program is a trusted application program in a trusted execution environment, where the key escrow program is a trusted application program created in the trusted execution environment, and the key is stored in a memory corresponding to the key escrow program;
a receiving module, configured to receive a ciphertext obtained by encrypting the key sent by the key escrow program;
the decryption module is used for decrypting the ciphertext to obtain a plaintext of the secret key;
the sending storage module is used for sending the code of the key using program or the encrypted value of the code to a third party so that the third party can audit the key using program based on the code or the encrypted value; or,
storing the code of the key using program or the encrypted value of the code to a target storage platform, so that the third party can obtain the code or the encrypted value from the target storage platform and audit the key using program based on the code or the encrypted value.
17. The system of claim 16, wherein the target storage platform is a blockchain platform or a securely authenticated database.
18. The system of claim 16, the trusted execution environment being a software protection extension policy based trusted execution environment.
19. A key authority comprising at least one storage medium and at least one processor, the at least one storage medium storing computer instructions; the at least one processor is configured to execute the computer instructions to implement the method of any of claims 1-6 or claims 7-9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911304078.1A CN111090865B (en) | 2019-12-17 | 2019-12-17 | Secret key authorization method and system |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911304078.1A CN111090865B (en) | 2019-12-17 | 2019-12-17 | Secret key authorization method and system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN111090865A CN111090865A (en) | 2020-05-01 |
| CN111090865B true CN111090865B (en) | 2022-01-25 |
Family
ID=70395051
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911304078.1A Active CN111090865B (en) | 2019-12-17 | 2019-12-17 | Secret key authorization method and system |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111090865B (en) |
Families Citing this family (8)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112507302B (en) * | 2020-12-10 | 2024-04-19 | 支付宝(杭州)信息技术有限公司 | Calling party identity authentication method and device based on execution of cryptographic module |
| CN114692113B (en) * | 2020-12-31 | 2024-02-13 | 成都鼎桥通信技术有限公司 | Decryption method, decryption device, mobile terminal and readable storage medium |
| CN112632589A (en) * | 2020-12-31 | 2021-04-09 | 深圳前海微众银行股份有限公司 | Key escrow method, device, equipment and computer readable storage medium |
| CN113343234B (en) * | 2021-06-10 | 2023-01-20 | 支付宝(杭州)信息技术有限公司 | Method and device for carrying out credible check on code security |
| CN114338149B (en) * | 2021-12-28 | 2022-12-27 | 北京深盾科技股份有限公司 | Login credential authorization method of server, terminal and key escrow platform |
| CN114584307B (en) * | 2022-05-07 | 2022-09-02 | 腾讯科技（深圳）有限公司 | Trusted key management method and device, electronic equipment and storage medium |
| CN116055032B (en) * | 2022-05-11 | 2023-09-22 | 荣耀终端有限公司 | Key generation method and electronic equipment |
| CN115270134B (en) * | 2022-07-18 | 2023-04-18 | 京信数据科技有限公司 | Computing method and system based on FPGA trusted execution environment |
Family Cites Families (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP5390619B2 (en) * | 2008-09-24 | 2014-01-15 | インターデイジタル パテント ホールディングス インコーポレイテッド | HOMENODE-B device and security protocol |
| EP3026557A1 (en) * | 2014-11-28 | 2016-06-01 | Thomson Licensing | Method and device for providing verifying application integrity |
| CN105138904B (en) * | 2015-08-25 | 2018-06-15 | 华为技术有限公司 | A kind of access control method and device |
| CN110199309B (en) * | 2017-01-23 | 2023-06-16 | 万事达卡国际公司 | Method and system for authentication via trusted execution environment |
| CN109960903A (en) * | 2017-12-26 | 2019-07-02 | 中移（杭州）信息技术有限公司 | A kind of method, apparatus, electronic equipment and storage medium that application is reinforced |
| CN109101822B (en) * | 2018-07-10 | 2021-01-29 | 西安交通大学 | Method for solving data privacy disclosure problem in multi-party computing |
| CN109933987A (en) * | 2018-11-30 | 2019-06-25 | 上海点融信息科技有限责任公司 | For the key generation method of block chain network, endorsement method, storage medium, calculate equipment |
| CN110034924B (en) * | 2018-12-12 | 2022-05-13 | 创新先进技术有限公司 | Data processing method and device |
| WO2019120317A2 (en) * | 2019-03-26 | 2019-06-27 | Alibaba Group Holding Limited | Program execution and data proof scheme using multiple key pair signatures |
| CN110138799B (en) * | 2019-05-30 | 2020-07-17 | 东北大学 | SGX-based secure cloud storage method |
-
2019
- 2019-12-17 CN CN201911304078.1A patent/CN111090865B/en active Active
Also Published As
| Publication number | Publication date |
|---|---|
| CN111090865A (en) | 2020-05-01 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN111090865B (en) | Secret key authorization method and system | |
| CN111027086B (en) | Private data protection method and system | |
| US10164778B2 (en) | Method and system for distributing attestation key and certificate in trusted computing | |
| US11711222B1 (en) | Systems and methods for providing authentication to a plurality of devices | |
| US9542568B2 (en) | Systems and methods for enforcing third party oversight of data anonymization | |
| US9680654B2 (en) | Systems and methods for validated secure data access based on an endorsement provided by a trusted third party | |
| EP3175575B1 (en) | Secure content packaging using multiple trusted execution environments | |
| JP5361894B2 (en) | Multi-factor content protection | |
| US9867043B2 (en) | Secure device service enrollment | |
| US9374361B2 (en) | Cross-native application authentication application | |
| WO2015180691A1 (en) | Key agreement method and device for verification information | |
| US10771467B1 (en) | External accessibility for computing devices | |
| WO2017193950A1 (en) | Mobile office method, server, client, and system | |
| US9954834B2 (en) | Method of operating a computing device, computing device and computer program | |
| CN103246850A (en) | Method and device for processing file | |
| WO2015180689A1 (en) | Method and apparatus for acquiring verification information | |
| US11956242B2 (en) | Distributed directory caching techniques for secure and efficient resource access | |
| WO2024139273A1 (en) | Federated learning method and apparatus, readable storage medium, and electronic device | |
| US20240048361A1 (en) | Key Management for Cryptography-as-a-service and Data Governance Systems | |
| Choi et al. | Hardware-assisted credential management scheme for preventing private data analysis from cloning attacks | |
| US20240048532A1 (en) | Data exchange protection and governance system | |
| US20240048380A1 (en) | Cryptography-as-a-Service | |
| WO2017117080A1 (en) | Systems and methods for true privilege application elevation | |
| WO2024030308A1 (en) | Data exchange protection and governance system | |
| JP2012169983A (en) | Data processing apparatus and program |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40029285 Country of ref document: HK |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |