A resource sharing system
By using an encryption module to re-encrypt the key ciphertext in the resource-sharing system, the problem of resource leakage in proxy re-encryption technology is solved, achieving higher security and privacy protection.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- SHANGHAI 100 METERS NETWORK TECH CO LTD
- Filing Date
- 2023-03-07
- Publication Date
- 2026-06-02
AI Technical Summary
In existing proxy re-encryption technologies, the storage and encryption of data resources are handled by a third party. This can lead to a significant risk of resource leakage if the private key of the resource requester is leaked, as the third party may obtain the resources from the resource authorizer.
In a resource-sharing system, the public and private keys of the resource requester and the resource grantor are stored in an encryption module. The encryption module generates a re-encryption key based on the private key of the resource grantor and the public key of the resource requester, re-encrypts the key ciphertext, and sends the re-encrypted key ciphertext to the resource requester. The resource requester uses its own private key to decrypt and obtain the data key to decrypt the resource ciphertext.
By storing the encrypted resource ciphertext in the storage module and re-encrypting the key ciphertext in the encryption module, the unauthorized decryption of resources by the encryption module is avoided, the risk of resource licensors leaking resources to third parties is reduced, and the security of resource sharing is improved.
Smart Images
Figure CN116340972B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of data encryption technology, and in particular to a resource sharing system. Background Technology
[0002] With the development of information technology, data has become the most crucial component of the entire network. Whether it's big data analytics, machine learning, or risk assessment and algorithm optimization in real-world applications, all require substantial amounts of foundational data. Therefore, data openness and sharing have always been themes advocated by academia and industry. However, it's important to note that, from both a commercial and legal perspective, the leakage of sensitive and private data can lead to serious consequences.
[0003] Therefore, to achieve secure data sharing and avoid the leakage of sensitive and private data, proxy re-encryption is currently the primary method used for data sharing. The resource licensor uploads the encrypted resource data (encrypted with its public key) to a third party. When a resource requester requests resources from the resource licensor, the licensor uses its own private key and the resource requester's public key to generate a re-encryption key. This re-encryption key is then used at the third party to re-encrypt the encrypted resource data into encrypted data that can be decrypted using the resource requester's private key, thus enabling resource sharing between the resource licensor and the resource requester.
[0004] However, existing proxy re-encryption technologies still have problems in practical applications that urgently need to be solved: the storage and encryption of data resources are both entrusted to a third party, which places high demands on that party. Once the private key of the resource requester is leaked, the third party may gain access to the resource authorizer's resources, leading to resource leakage. Summary of the Invention
[0005] This invention provides a resource sharing system to address the problem that current proxy re-encryption technology poses a significant risk of resource licensors leaking their resources to third parties.
[0006] In a first aspect, embodiments of the present invention provide a resource sharing system, comprising: a resource authorizer, a resource requester, a storage module, and an encryption module;
[0007] The resource requester is used to send a request message to the resource authorizer, and the request message is used to request the first resource;
[0008] The resource licensor is configured to send a first storage address to the resource requester and a second storage address to the encryption module when authorizing the resource requester to obtain the first resource; the first storage address is the storage address corresponding to the first resource ciphertext, the second storage address is the storage address corresponding to the first key ciphertext, the first resource ciphertext is the ciphertext of the first resource encrypted with a first data key, and the first key ciphertext is the ciphertext of the first data key encrypted with the public key of the resource licensor;
[0009] The storage module is used to store the first resource ciphertext and the first key ciphertext;
[0010] The encryption module is configured to obtain the first key ciphertext from the storage module according to the second storage address, encrypt the first key ciphertext according to the re-encryption key to generate a first re-encryption key ciphertext, and send the first re-encryption key ciphertext to the resource requester, wherein the re-encryption key is generated based on the private key of the resource authorizer and the public key of the resource requester;
[0011] The resource requester is further configured to obtain the first resource ciphertext from the storage module according to the first storage address, decrypt the first encryption key ciphertext according to the private key of the resource requester to obtain the first data key, and decrypt the first resource ciphertext according to the first data key to obtain the first resource.
[0012] This resource-sharing system allows the encryption module to retrieve the ciphertext key from the storage module when a resource requester requests resources from the resource licensor. The encryption module then re-encrypts the ciphertext key and sends it to the resource requester. The requester can then decrypt the re-encrypted key using their private key to obtain the data key, retrieve the resource ciphertext from the storage module, and decrypt it using the data key to obtain the requested resource. By storing the encrypted resource ciphertext in the storage module and re-encrypting the key within the encryption module, the encryption module cannot access the ciphertext, thus preventing unauthorized decryption of the resource licensor's resources. This reduces the risk of disclosing the resource licensor's resources to third parties and enhances the security of resource sharing.
[0013] Optionally, the resource licensor is further configured to encrypt the first resource according to the first data key to generate the first resource ciphertext, encrypt the first data key according to the public key of the resource licensor to generate the first key ciphertext, and send the first resource ciphertext and the first key ciphertext to the storage module.
[0014] The storage module is also used to send the first storage address and the second storage address to the resource licensor.
[0015] Optionally, the resource licensor is further configured to encrypt the second resource according to the second data key to generate a second resource ciphertext, and encrypt the second data key according to the public key of the resource licensor to generate a second key ciphertext; wherein the second resource is different from the first resource, and the second data key is different from the first data key.
[0016] As can be seen from the above, different data keys are used to encrypt different resources, thereby improving the security of resource sharing.
[0017] Optionally, the resource licensor is further configured to generate the re-encryption key based on the resource licensor's private key and the resource requester's public key, and send the re-encryption key to the encryption module.
[0018] Optionally, the encryption module is further configured to generate the re-encryption key based on the private key of the resource licensor and the public key of the resource requester.
[0019] Optionally, the encryption module is configured to receive an authorization permission before generating the re-encryption key based on the private key of the resource licensor and the public key of the resource requester. The authorization permission is used to authorize the encryption module to use the private key of the resource licensor.
[0020] Optionally, the resource requester is further configured to send a first registration request to the encryption module before sending a request message to the resource authorizer;
[0021] The encryption module is further configured to call the key generation module to generate the public key and the private key of the resource requester after receiving the first registration request, and the public key and the private key of the resource requester are stored in the encryption module.
[0022] The resource licensor is further configured to send a second registration request to the encryption module before authorizing the resource requester to obtain the first resource. After receiving the second registration request, the encryption module calls the key generation module to generate the public key and private key of the resource licensor. The public key and private key of the resource licensor are stored in the encryption module.
[0023] Secondly, embodiments of the present invention provide a resource sharing method applied in an encryption module, comprising:
[0024] Receive the second storage address, where the second storage address is the storage address corresponding to the first key ciphertext;
[0025] The first key ciphertext is obtained from the storage module according to the second storage address;
[0026] The first key ciphertext is encrypted with the re-encryption key to generate the first re-encryption key ciphertext, wherein the re-encryption key is generated based on the private key of the resource authorizer and the public key of the resource requester;
[0027] Send the first encryption key ciphertext to the resource requester.
[0028] By using the above method, the encryption module cannot access the encrypted resource, thus avoiding the risk that the encryption module can illegally decrypt the resource licensor's resources, thereby reducing the risk of leaking the resource licensor's resources to third parties and improving the security of resource sharing.
[0029] Optionally, it further includes: generating the re-encryption key based on the private key of the resource licensor and the public key of the resource requester.
[0030] Optionally, before generating the re-encryption key based on the private key of the resource licensor and the public key of the resource requester, the process includes:
[0031] Receive an authorization license, which authorizes the encryption module to use the private key of the resource licensor. Attached Figure Description
[0032] Figure 1 A system architecture diagram of a resource sharing system provided in an embodiment of the present invention;
[0033] Figure 2 A system architecture diagram of an encryption module provided in an embodiment of the present invention;
[0034] Figure 3 This is a flowchart illustrating a resource sharing method provided in an embodiment of the present invention. Detailed Implementation
[0035] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.
[0036] The application scenarios described in the embodiments of this invention are for the purpose of more clearly illustrating the technical solutions of the embodiments of this invention, and do not constitute a limitation on the technical solutions provided by the embodiments of this invention. Those skilled in the art will understand that with the emergence of new application scenarios, the technical solutions provided by the embodiments of this invention are also applicable to similar technical problems. In the description of this invention, unless otherwise stated, "multiple" means two or more.
[0037] Currently, proxy re-encryption is commonly used to achieve secure data sharing. However, existing proxy re-encryption technologies have some problems: the storage and encryption of existing data resources are handled by third parties, which places high demands on these parties. Once the private key of the resource requester is leaked, the third party can decrypt the stored data resources and obtain them, leading to data leakage.
[0038] Based on this, this application proposes a resource sharing system to address the problem that current proxy re-encryption technology poses a significant risk of leaking the resources of the resource licensor to third parties.
[0039] For example, Figure 1 This is a system architecture diagram of a resource sharing system proposed in this application. Specifically, as shown... Figure 1 As shown, a resource sharing system 100 includes a resource authorizer 101, a resource requester 102, a storage module 103, and an encryption module 104.
[0040] Specifically, the resource requester 102 sends a request message to the resource grantor 101, which requests a first resource.
[0041] Specifically, when the resource licensor 101 obtains the first resource, it sends a first storage address to the resource requester 102 and a second storage address to the encryption module 104. The first storage address is the storage address corresponding to the first resource ciphertext, and the second storage address is the storage address corresponding to the first key ciphertext. The first resource ciphertext is the ciphertext encrypted with the first data key, and the first key ciphertext is the ciphertext encrypted with the first data key using the public key of the resource licensor 101.
[0042] Specifically, the storage module 103 is used to store the first resource ciphertext and the first key ciphertext.
[0043] Specifically, the encryption module 104 is used to obtain the first key ciphertext from the storage module 103 according to the second storage address, encrypt the first key ciphertext according to the re-encryption key to generate the first re-encryption key ciphertext, and send the first re-encryption key ciphertext to the resource requester 102. The re-encryption key is generated according to the private key of the resource authorizer 101 and the public key of the resource requester 102.
[0044] Specifically, the resource requester 102 is also used to obtain the first resource ciphertext from the storage module 103 according to the first storage address, decrypt the first encryption key ciphertext according to the private key of the resource requester 102 to obtain the first data key, and decrypt the first resource ciphertext according to the first data key to obtain the first resource.
[0045] The number of resource requesters can be one or more, the number of resource licensors can be one or more, and the number of resources that each resource licensor can provide can be one or more.
[0046] For details on the specific functions of each component of the resource sharing system 100, please refer to the following: Figure 3 The relevant description of the illustrated embodiment.
[0047] For example, Figure 2 The system architecture diagram for encryption module 104 is as follows: Figure 2 As shown, the encryption module 104 includes a data layer 200, a core layer 201, an interface layer 202, and a security component 203.
[0048] Specifically, the data layer 200 includes multiple nodes 200a, which are used by the encryption module 104 to store and manage the public and private keys of the resource authorizer 101 and the resource requester 102, as well as to perform threshold backup management. Nodes 200a can rely on a peer-to-peer database (OrbitDB) in a distributed network for the storage and backup management of the public and private keys.
[0049] Specifically, the core layer 201 includes a key generation module 201a, a threshold sharing module 201b, an encryption / decryption module 201c, a re-encryption key generation module 201d, a re-encryption execution module 201e, and a splicing module 201f. Specifically, the key generation module 201a is used by the encryption module 104 to help the resource licensor 101 or the resource requester 102 generate their private and public keys after registration in the encryption module 104; the threshold sharing module 201b is used by the encryption module 104 to perform threshold backups of the private and public keys of the resource licensor 101 and the resource requester 102; the encryption / decryption module 201c is used by the resource licensor 101 to encrypt the resource and by the resource requester 102 to decrypt the resource; the re-encryption key generation module 201d and the re-encryption execution module 201e are used to implement the re-encryption function of the encryption module 104; and the concatenation module 201f is used by the resource requester 102 to concatenate the re-encryption key ciphertext with the locally stored binary ciphertext during data transmission to generate content that can be decrypted by its own private key.
[0050] Specifically, the interface layer 202 includes a registration interface 202a, a login interface 202b, a passwordless authorization interface 202c, a password authorization interface 202d, a time-update interface 202e, a re-encryption interface 202f, a key acquisition interface 202g, and a key update interface 202h. All of the above interfaces are used by the encryption module 104 to connect and exchange data with internal or external systems in order to achieve corresponding specific functions.
[0051] Specifically, security component 203 includes an encryption software toolkit 203a, a decryption software toolkit 203b, an Iframe security control 203c, an authorization code secure input control 203d, a streaming media secure playback component 203e, and an image secure viewing component 203f. Among these, encryption software toolkit 203a and decryption software toolkit 203b are used by encryption module 104 to provide encryption and decryption services to resource licensor 101 and resource requester 102. Specifically, resource licensor 101 calls encryption software toolkit 203a to perform encryption, and resource requester 102 calls decryption software toolkit 203b to perform decryption. The iframe security control 203c is used to enable secure access and protection of embedded documents in the encryption module 104; the authorization code secure input control 203d is used by the resource licensor 101 to ensure that the verification code and other information are not stolen by illegal eavesdroppers when entering SMS verification codes and other information; the streaming media secure playback component 203e and the image secure viewing component 203f are used to ensure that the displayed content, such as videos and images, is not maliciously tampered with when displaying multimedia content on the front-end page. The above security components 203 effectively ensure the security of the encryption module 104 during use.
[0052] For example, before the resource requester requests resources from the resource licensor (e.g., before step 300), the resource licensor sends a second registration request to the encryption module. After receiving the registration request, the encryption module can call its internal key generation module (e.g., key generation module 201a) to generate the resource licensor's public key and private key. Both the resource licensor's public key and private key can be stored in the encryption module; for example, they can be stored in a node 200a.
[0053] For example, before the resource requester sends a request message to the resource licensor, the resource requester also sends a first registration request to the encryption module. After receiving the registration request, the encryption module can call its internal key generation module to generate the resource requester's public key and private key. Both the resource requester's public key and private key can be stored in the encryption module.
[0054] Specifically, there are no requirements regarding the execution order of the registration request sent by the resource authorization direction to the encryption module and the registration request sent by the resource request direction to the encryption module.
[0055] For example, when resource licensors and resource requesters register in the encryption module, they can complete the registration by entering their own username and the authentication information corresponding to the username. In subsequent use, registered resource licensors and resource requesters can log in to the encryption module using their username and the authentication information corresponding to the username.
[0056] Specifically, the encryption module can build a private network based on the InterPlanetary File System (IPFS) protocol, and store the public and private keys of the resource grantor and the resource requester in both the encryption module's local database and the private network. Alternatively, the encryption module can use other methods to store the public and private keys; this application does not impose any limitations on these methods.
[0057] Specifically, the encryption module can also utilize a distributed network peer-to-peer database (OrbitDB) data management software to store and manage the public and private keys of the resource authorizer and the resource requester through a key-value database. Furthermore, the encryption module can employ other methods to manage public and private keys, which are not limited in this application.
[0058] like Figure 3 As shown, the resource sharing method proposed in this application has the following specific process:
[0059] Step 300: The resource requester sends a request message to the resource authorizer.
[0060] Specifically, the request message is used to request the first resource.
[0061] In one possible implementation, before the resource licensor receives the request message, the resource licensor can encrypt the first resource using the first data key to generate first resource ciphertext, and can also encrypt the first data key using its own public key to generate first key ciphertext, and then send the first resource ciphertext and first key ciphertext to the storage module. For example, the resource licensor can call the encryption / decryption module 201c to encrypt the first resource and the first data key.
[0062] In another possible implementation, after the resource licensor receives the request message, if the resource licensor agrees to the resource requester's request message for the first resource, the resource licensor can encrypt the first resource according to the first data key to generate the first resource ciphertext, and the resource licensor can also encrypt the first data key according to its own public key to generate the first key ciphertext, and then send the first resource ciphertext and the first key ciphertext to the storage module.
[0063] Regarding the two possible implementations described above, after the storage module receives the first resource ciphertext and the first key ciphertext, it stores both. The storage address corresponding to the first resource ciphertext is designated as the first storage address, and the storage address corresponding to the first key ciphertext is designated as the second storage address. The storage module then sends the first storage address and the second storage address to the resource licensor.
[0064] For example, the request message sent by the resource requester to the resource licensor can also be used to request any resource other than the first resource. For any resource other than the first resource, the resource licensor should use a different data key for encryption. Specifically, the resource licensor can encrypt the second resource using the second data key to generate second resource ciphertext, and the resource licensor also encrypts the second data key using its own public key to generate second key ciphertext. Here, the second resource is different from the first resource, and the second data key is different from the first data key.
[0065] Step 310: The resource authorizing party sends the first storage address to the resource requester.
[0066] Specifically, in step 300, the resource requester requests the first resource from the resource licensor, the resource licensor agrees to the resource requester's request, and when authorizing the resource requester to obtain the first resource, the resource licensor sends the first storage address corresponding to the encrypted first resource to the resource requester.
[0067] Step 320: The resource authorization direction sends the second storage address to the encryption module.
[0068] Specifically, in step 300, when the resource licensor agrees to the resource requester's request and authorizes the resource requester to obtain the first resource, the resource licensor may also send the second storage address corresponding to the first key ciphertext to the encryption module.
[0069] Specifically, the execution order of step 310, where the resource authorization direction sends the first storage address to the resource requester, and step 320, where the resource authorization direction sends the second storage address to the encryption module, is not required.
[0070] Step 330: The encryption module retrieves the first key ciphertext from the storage module based on the second storage address.
[0071] For example, after the resource authorization direction sends the second storage address corresponding to the first key ciphertext to the encryption module in step 320, the encryption module can obtain the first key ciphertext from the storage module according to the second storage address.
[0072] Step 340: The encryption module encrypts the first key ciphertext according to the re-encryption key to generate the first re-encryption key ciphertext.
[0073] For example, after the encryption module obtains the first key ciphertext in step 330, it can encrypt the first key ciphertext using the re-encryption key to generate a first re-encryption key ciphertext. For instance, the encryption module encrypts the first key ciphertext using the re-encryption execution module 201e. Specifically, the re-encryption key is generated based on the private key of the resource licensor and the public key of the resource requester.
[0074] In one possible implementation, the re-encryption key can be generated by the encryption module based on the private key of the resource licensor and the public key of the resource requester. For example, the encryption module generates the key based on the re-encryption key generation module 201d. Specifically, before generating the re-encryption key, the encryption module needs to send a private key authorization to the resource licensor. Only after receiving the authorization from the resource licensor's private key can the encryption module use the resource licensor's private key to generate the re-encryption key.
[0075] Specifically, when the encryption module sends a private key to the resource licensor for the first time to authorize permission for the first resource, the resource licensor can use dual authentication with a real-time verification code and identity verification information to authorize permission. When the encryption module subsequently sends a private key to the resource licensor again for the first resource, considering that the resource licensor has already authorized permission for that resource, the resource licensor can perform simple authorization by providing identity verification information, or can achieve passwordless authorization without providing any information. Specifically, any other methods can be used to implement dual authentication authorization and simple authorization; this application does not limit the scope of these methods.
[0076] In another possible implementation, the re-encryption key can also be generated by the resource licensor using its private key and the resource requester's public key. For example, the resource licensor calls the re-encryption key generation module 201d to generate the re-encryption key. After generating the re-encryption key, the resource licensor needs to send it to the encryption module.
[0077] Furthermore, for the two possible implementations mentioned above, within a preset period, the re-encryption key for the first resource can be cached in the encryption module or the resource licensor. When the resource requester repeatedly requests the first resource, the already generated re-encryption key can be used for encryption, reducing the data processing steps for generating the re-encryption key. After the preset period expires, the resource licensor can update its own private and public keys, allowing the encryption module or the resource licensor to regenerate the re-encryption key based on the updated private key of the resource licensor and the public key of the resource requester. The preset period is determined based on empirical values.
[0078] Specifically, the resource requester or encryption module can use the secp256k1 elliptic curve algorithm to generate the re-encryption key, ensuring the reliability of the re-encryption key as no third party can deduce the private key of the resource licensor from it. Alternatively, any other algorithm can be used; this application does not limit its application.
[0079] Step 350: The encryption module sends the first encryption key ciphertext to the resource requester.
[0080] For example, after the encryption module generates the first encryption key ciphertext in step 340, it can send the first encryption key ciphertext to the resource requester. Specifically, before the encryption module sends the first encryption key ciphertext to the resource requester, the resource licensor informs the encryption module of the identification information of the resource requester it has authorized for the first resource, so that the encryption module can send the first resource to the corresponding resource requester.
[0081] Step 360: The resource requester obtains the first resource ciphertext from the storage module based on the first storage address.
[0082] For example, after the resource authorizing party sends the first storage address to the resource requester in step 320, the resource requester can obtain the first resource ciphertext from the storage module according to the first storage address.
[0083] Step 370: The resource requester decrypts the first encryption key ciphertext using its own private key to obtain the first data key, and then decrypts the first resource ciphertext using the first data key to obtain the first resource.
[0084] For example, after the resource requester obtains the first resource ciphertext in step 360, the resource requester can decrypt the first encryption key ciphertext using its own private key to obtain the first data key, and then decrypt the first resource ciphertext using the first data key to obtain the first resource it requested. For instance, the resource requester calls the concatenation module 201f to concatenate the first data key with locally stored binary ciphertext to form content decryptable by its own private key, obtains the first data key through decryption, and then calls the encryption / decryption module 201c to decrypt the first resource ciphertext to obtain the first resource.
[0085] The resource licensor encrypts the resource using a data key to obtain encrypted resource ciphertext, and then encrypts the data key using its own public key to obtain encrypted key ciphertext. Both the resource ciphertext and key ciphertext are stored in a storage module. The storage address of the resource ciphertext is known to both the resource licensor and the resource requester authorized by the resource licensor. The encryption module cannot access the resource ciphertext, thus reducing the risk of the current proxy re-encryption technology leaking the resource licensor's resources to third parties and improving the security of resource sharing. Furthermore, storing both the resource licensor's and resource requester's public and private keys in the encryption module prevents the loss of their private keys.
[0086] For example, this application specifically illustrates the scenario where a resource requester requests resource X from a resource licensor.
[0087] First, the resource licensor and the resource requester send registration requests to the encryption module. After receiving the registration requests from the resource licensor and the resource requester, the encryption module calls its internal key generation module to generate public key A and private key a for the resource licensor, and public key B and private key b for the resource requester. Then, public key A, private key a, public key B and private key b are stored in the encryption module.
[0088] Next, after the resource licensor completes registration, it encrypts resource X using data key C to obtain resource ciphertext X', and then encrypts data key C using public key A to obtain data key ciphertext C'. The resource licensor then stores resource ciphertext X' and data key ciphertext C' in the storage module. The storage module informs the resource licensor of the storage addresses of resource ciphertext X' and data key ciphertext C'. Then, the resource requester requests resource X from the resource licensor. After the resource licensor agrees to authorize the resource requester, it informs the resource requester of the storage address of resource ciphertext X' and the encryption module of the storage address of data key ciphertext C'. Specifically, referring to step 300, the resource licensor can also encrypt the requested resource X and data key C and store them in the storage module after the resource requester sends the request for resource X.
[0089] Then, after receiving the storage address of the data key ciphertext C', the encryption module retrieves the data key ciphertext C' from the storage module based on that address. Simultaneously, the encryption module can also generate a re-encryption key D based on the resource licensor's private key a and the resource requester's public key B. Furthermore, the encryption module encrypts the data key ciphertext C' using the re-encryption key D to obtain the re-encryption key ciphertext C" . Specifically, the process of generating the re-encryption key D is described in step 340, and as can be seen from step 340, the re-encryption key D can also be generated by the resource licensor.
[0090] Finally, the encryption module sends the re-encryption key ciphertext C" to the resource requester, and the resource requester retrieves the resource ciphertext X' from the storage module based on its storage address. The resource requester then uses its private key b to decrypt the re-encryption key ciphertext C" to obtain the data key C, and uses the data key C to decrypt the resource ciphertext X' to obtain the requested resource X.
[0091] The division of units in the embodiments of this invention is illustrative and represents only one logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional units in the various embodiments of this invention can be integrated into a single processor, exist as separate physical units, or be integrated into a single unit. The integrated units described above can be implemented in hardware or as software functional units.
[0092] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.
[0093] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.
[0094] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.
[0095] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.
[0096] Although preferred embodiments of the invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the invention.
[0097] Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.
Claims
1. A resource sharing system, characterized in that, The system includes: a resource authorizer, a resource requester, a storage module, and an encryption module; The resource requester is used to send a request message to the resource authorizer, and the request message is used to request the first resource; The resource licensor is configured to send a first storage address to the resource requester and a second storage address to the encryption module when authorizing the resource requester to obtain the first resource; the first storage address is the storage address corresponding to the first resource ciphertext, the second storage address is the storage address corresponding to the first key ciphertext, the first resource ciphertext is the ciphertext of the first resource encrypted with a first data key, and the first key ciphertext is the ciphertext of the first data key encrypted with the public key of the resource licensor; The storage module is used to store the first resource ciphertext and the first key ciphertext; The encryption module is configured to obtain the first key ciphertext from the storage module according to the second storage address, encrypt the first key ciphertext according to the re-encryption key to generate a first re-encryption key ciphertext, and send the first re-encryption key ciphertext to the resource requester, wherein the re-encryption key is generated based on the private key of the resource authorizer and the public key of the resource requester; The encryption module is further configured to call the key generation module to generate the public key and the private key of the resource requester after receiving the first registration request; the encryption module cannot access the first resource ciphertext; The resource requester is further configured to obtain the first resource ciphertext from the storage module according to the first storage address, decrypt the first encryption key ciphertext according to the private key of the resource requester to obtain the first data key, and decrypt the first resource ciphertext according to the first data key to obtain the first resource.
2. The system as described in claim 1, characterized in that, The resource licensor is further configured to encrypt the first resource according to the first data key to generate the first resource ciphertext, encrypt the first data key according to the public key of the resource licensor to generate the first key ciphertext, and send the first resource ciphertext and the first key ciphertext to the storage module. The storage module is also used to send the first storage address and the second storage address to the resource licensor.
3. The system as described in claim 2, characterized in that, The resource licensor is further configured to encrypt the second resource according to the second data key to generate a second resource ciphertext, and encrypt the second data key according to the public key of the resource licensor to generate a second key ciphertext; wherein the second resource is different from the first resource, and the second data key is different from the first data key.
4. The system as described in claim 1, characterized in that, The resource licensor is further configured to generate the re-encryption key based on the resource licensor's private key and the resource requester's public key, and send the re-encryption key to the encryption module.
5. The system as described in claim 1, characterized in that, The encryption module is further configured to generate the re-encryption key based on the private key of the resource licensor and the public key of the resource requester.
6. The system as described in claim 5, characterized in that, The encryption module is configured to receive an authorization permission before generating the re-encryption key based on the private key of the resource licensor and the public key of the resource requester. The authorization permission is used to authorize the encryption module to use the private key of the resource licensor.
7. The system as described in claim 1, characterized in that: The resource requester is also configured to send a first registration request to the encryption module before sending a request message to the resource authorizer; The encryption module stores the public key and private key of the resource requester. The resource licensor is further configured to send a second registration request to the encryption module before authorizing the resource requester to obtain the first resource. After receiving the second registration request, the encryption module calls the key generation module to generate the public key and private key of the resource licensor. The public key and private key of the resource licensor are stored in the encryption module.
8. A resource sharing method applied in an encryption module, characterized in that, The method includes: Receive the second storage address, where the second storage address is the storage address corresponding to the first key ciphertext; The first key ciphertext is obtained from the storage module according to the second storage address; The first key ciphertext is encrypted with the re-encryption key to generate the first re-encryption key ciphertext, wherein the re-encryption key is generated based on the private key of the resource authorizer and the public key of the resource requester; Send the first encryption key ciphertext to the resource requester; It is also used to call the key generation module to generate the public key and private key of the resource requester after receiving the first registration request; the encryption module cannot access the first resource ciphertext; The first resource ciphertext is obtained by the resource requester from the storage module according to the first storage address; the first storage address is the storage address corresponding to the first resource ciphertext.
9. The method as described in claim 8, characterized in that, Before generating the re-encryption key based on the private key of the resource licensor and the public key of the resource requester, the process includes: Receive an authorization license, which authorizes the encryption module to use the private key of the resource licensor.