Information sharing methods, devices, systems, media and equipment

Abstract

This application provides an information sharing method, an information sharing device, an information sharing system, a computer-readable storage medium, and an electronic device, relating to the field of computer technology. The method can record the access configuration of the information to be shared through a blockchain with immutable characteristics. The access configuration is uploaded by the sending end and used for access control after information sharing. For the receiving end, it is necessary to verify the access feasibility based on the access configuration in a trusted execution environment and then obtain the information to be shared based on the access configuration. This is conducive to realizing further real and effective information access control after information sharing. Furthermore, by combining the information sharing scheme provided by blockchain and trusted execution environment, the security of the information to be shared and the access configuration can be guaranteed.

Description

Technical Field

[0001] This application relates to the field of computer technology, and more specifically, to an information sharing method, an information sharing device, an information sharing system, a computer-readable storage medium, and an electronic device. Background Technology

[0002] Information sharing is a common feature in applications or cloud services. This feature allows users to easily share information with specified objects based on the application / cloud service.

[0003] The specific sharing methods are: setting an access password and sending the password to the specified object; or granting access permissions to the specified object ID so that the information can be shared with the specified object.

[0004] While the sender can control the accessed object through various operations, it is understandable that the sender only controls the accessed object. Once the information is shared, it becomes difficult for the sender to further control the shared information through secure means.

[0005] It should be noted that the information disclosed in the background section above is only used to enhance the understanding of the background of this application, and therefore may include information that does not constitute related technology known to those skilled in the art. Summary of the Invention

[0006] The purpose of this application is to provide an information sharing method, information sharing device, information sharing system, computer-readable storage medium, and electronic device. This allows for the recording of access configurations for information to be shared using a blockchain with immutable characteristics. The access configurations are uploaded by the sending end and used for access control after information sharing. For the receiving end, access feasibility needs to be verified based on the access configuration in a trusted execution environment before obtaining the information to be shared. This facilitates further, more reliable and effective access control after information sharing. Furthermore, by combining the information sharing scheme provided by blockchain and a trusted execution environment, the security of the information to be shared and the access configurations can be guaranteed.

[0007] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0008] According to one aspect of this application, an information sharing method is provided, the method comprising:

[0009] Retrieve the access configuration corresponding to the information to be shared, uploaded by the sender from the blockchain;

[0010] In a trusted execution environment, access feasibility is verified based on access configuration, and the verification results are obtained.

[0011] If the verification results indicate that the information to be shared is accessible, then in the trusted execution environment, the information to be shared is obtained from the server based on the access configuration.

[0012] According to one aspect of this application, an information sharing device is provided, the device comprising:

[0013] The access configuration acquisition unit is used to obtain the access configuration corresponding to the information to be shared, which was uploaded by the sender from the blockchain;

[0014] The access feasibility verification unit is used to verify access feasibility based on access configuration in a trusted execution environment and obtain the verification result.

[0015] The unit for obtaining information to be shared is used to obtain the information to be shared from the server based on the access configuration in a trusted execution environment when the verification result indicates that the information to be shared is accessible.

[0016] According to one aspect of this application, an information sharing system is provided, the system comprising a sender, a receiver, and a server, wherein:

[0017] The sending end is used to upload the access configuration corresponding to the information to be shared to the blockchain; and to upload the information to be shared to the server.

[0018] The receiving end is used to obtain the access configuration from the blockchain; verify the access feasibility based on the access configuration in the trusted execution environment and obtain the verification result; if the verification result indicates that the information to be shared is accessible, the information to be shared is obtained from the server based on the access configuration.

[0019] According to one aspect of this application, a computer program product or computer program is provided, comprising computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the methods provided in the various alternative implementations described above.

[0020] According to one aspect of this application, a computer-readable storage medium is provided, on which a computer program is stored, wherein the computer program, when executed by a processor, implements the method of any one of the above.

[0021] According to one aspect of this application, an electronic device is provided, comprising: a processor; and a memory for storing executable instructions of the processor; wherein the processor is configured to perform the method of any of the above by executing the executable instructions.

[0022] The exemplary embodiments of this application may have some or all of the following beneficial effects:

[0023] In an example embodiment of the information sharing method provided in this application, the access configuration of the information to be shared can be recorded using a blockchain with immutable characteristics. The access configuration is uploaded by the sending end and used for access control after information sharing. For the receiving end, it is necessary to verify the access feasibility based on the access configuration in a trusted execution environment before obtaining the information to be shared. This facilitates further genuine and effective information access control after information sharing. Furthermore, the information sharing scheme provided by the blockchain and the trusted execution environment can ensure the security of the information to be shared and the access configuration. In addition, recording the access configuration by the blockchain ensures that the access configuration related to the information to be shared cannot be tampered with; storing the information to be shared by the server makes the information to be shared invisible to each node in the blockchain, ensuring the privacy of the information to be shared; verifying the access feasibility and obtaining the information to be shared in the trusted execution environment ensures that the access configuration cannot be maliciously stolen, ensuring genuine and effective further information access control and preventing the leakage of the information to be shared.

[0024] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and do not limit this application. Attached Figure Description

[0025] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application. It is obvious that the drawings described below are merely some embodiments of this application, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0026] Figure 1 A flowchart illustrating an embodiment of an information sharing method according to this application is shown schematically.

[0027] Figure 2 This illustration schematically shows a sequence diagram of a receiver registration process according to an embodiment of the present application;

[0028] Figure 3 The illustration schematically shows a sequence diagram of an authentication process according to one embodiment of this application;

[0029] Figure 4 The diagram schematically illustrates a sequence of processes for acquiring information to be shared according to one embodiment of this application;

[0030] Figure 5 A flowchart illustrating another embodiment of an information sharing method according to this application is shown schematically;

[0031] Figure 6 This illustration schematically shows an architecture diagram of an information sharing system according to an embodiment of this application;

[0032] Figure 7 This illustration schematically shows an architecture diagram of an information sharing system according to another embodiment of this application;

[0033] Figure 8 This illustration schematically shows a structural diagram of an information sharing device according to an embodiment of the present application;

[0034] Figure 9 The schematic diagram illustrates the structure of a computer system suitable for implementing the electronic devices of the present application. Detailed Implementation

[0035] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided to make this application more comprehensive and complete, and to fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a full understanding of the embodiments of this application. However, those skilled in the art will recognize that the technical solutions of this application can be practiced with one or more of the specific details omitted, or other methods, components, apparatus, steps, etc., can be employed. In other instances, well-known technical solutions are not shown or described in detail to avoid obscuring various aspects of this application.

[0036] Please see Figure 1 , Figure 1 A flowchart illustrating an embodiment of an information sharing method according to this application is shown schematically. Figure 1 As shown, the subject executing this method can be a receiving end (such as a mobile phone, tablet computer, or other smart terminal), and the sending end involved in the following steps can also be a smart terminal. This method includes the following steps.

[0037] Step S110: Obtain the access configuration corresponding to the information to be shared, uploaded by the sender, from the blockchain.

[0038] Step S120: Verify access feasibility based on access configuration in a trusted execution environment and obtain the verification results.

[0039] Step S130: If the verification result indicates that the information to be shared is accessible, then in the trusted execution environment, the information to be shared is obtained from the server based on the access configuration.

[0040] Implementation Figure 1The method described above uses a blockchain with immutable characteristics to record the access configuration of the information to be shared. This access configuration is uploaded by the sending end and used for access control after information sharing. For the receiving end, access feasibility needs to be verified based on the access configuration in a trusted execution environment before obtaining the information to be shared. This facilitates further, truly effective access control after information sharing. Furthermore, the information sharing scheme provided by the blockchain and the trusted execution environment ensures the security of the information to be shared and the access configuration. In addition, recording the access configuration on the blockchain ensures that the access configuration related to the information to be shared cannot be tampered with; storing the information to be shared on the server side makes it invisible to nodes in the blockchain, ensuring the privacy of the information; verifying access feasibility and obtaining the information to be shared in the trusted execution environment ensures that the access configuration cannot be maliciously stolen, guaranteeing truly effective further information access control and preventing the leakage of the information to be shared.

[0041] The steps described above in this example implementation will now be explained in more detail.

[0042] In step S110, the access configuration corresponding to the information to be shared, uploaded by the sender, is obtained from the blockchain.

[0043] Specifically, this application takes into account that blockchain is a data structure that stores transactions in a way that makes them immutable and subsequently verifiable. Therefore, data recorded in blockchain has the characteristic of being tamper-proof.

[0044] Based on this, in the technical solution of this application, the sending end can upload the access configuration of the information to be shared to the blockchain to ensure that access control of the information to be shared is achieved based on the access configuration that cannot be tampered with after the information is shared.

[0045] The access configuration can be used to describe the conditions for information sharing. For example, the access configuration may include fields such as: information ID, sender ID, receiver ID, preset number of reads, current number of reads, and key ciphertext.

[0046]

[0047]

[0048] It should be noted that the table above is only an illustrative representation of the access configuration. In actual applications, the access configuration can contain any number of fields and any number of field information. For example, optionally, if there are multiple receiver IDs, the access configuration can also include the preset number of reads and the current number of reads corresponding to each receiver ID. For example, the preset number of reads A corresponding to receiver ID (123), the preset number of reads B corresponding to receiver ID (456), and the preset number of reads C corresponding to receiver ID (789).

[0049] Furthermore, the sending end can also upload the information to be shared to the server (e.g., the cloud) to prevent the information from being obtained by nodes in the blockchain, thus ensuring the privacy of the information. The information to be shared can be in any form, such as text, image, audio, or video, and this application embodiment does not limit this. In addition, since the information sharing involved in this application is based on the server, servers typically have large storage space. Compared to end-to-end information sharing between the sending and receiving ends, the technical solution of this application does not limit the size of the information to be shared. The aforementioned end-to-end information sharing is limited by factors such as the storage space of the sending end, and may not be able to send large amounts of information to be shared.

[0050] Furthermore, regarding the blockchain used in this application, it should be noted that the blockchain comprises one or more blocks. Each block in the chain is linked to the preceding block by including its cryptographic hash value in the chain. Each block also includes a timestamp, its own cryptographic hash value, and one or more transactions. Transactions that have been verified by nodes in the blockchain network are hashed and encoded into a Merkle tree. A Merkle tree is a data structure in which data at the leaf nodes of the tree is hashed, and all hash values ​​in each branch of the tree can be linked to the root of the branch. This process continues along the tree to the root, where hash values ​​representing all data in the tree are stored. The hash value of a transaction claimed to be stored in the tree can be quickly verified by determining whether it is consistent with the structure of the tree.

[0051] Although a blockchain is a data structure used to store transactions, a blockchain network is a network of computing nodes that manage, update, and maintain one or more blockchains. Blockchains are generally classified into three types: public blockchains, private blockchains, and consortium blockchains. Furthermore, combinations of these types are possible, such as private blockchains + consortium blockchains, or consortium blockchains + public blockchains. The implementation methods provided in this disclosure can be implemented in suitable types of blockchains.

[0052] The emergence of blockchain provides the technological support for the implementation of smart contracts. A smart contract is a set of promises defined in digital form, on which the contract participants can execute these promises according to the protocol. Alternatively, a smart contract can be understood as a program deployed on a computer system; when the triggering conditions of the smart contract are met, it can be automatically executed. Writing smart contracts into the blockchain in digital form ensures, through the characteristics of blockchain technology, that the entire process of storing, reading, and executing smart contracts is transparent, traceable, and immutable.

[0053] Furthermore, digital signatures can also be called public-key digital signatures, electronic seals, or signatures. A digital signature is a string of numbers that only the sender of the information can generate and that cannot be forged by others. This string of numbers also serves as valid proof of the authenticity of the information sent by the sender. Digital signatures can be verified using public and private keys for encryption and decryption. A set of digital signatures typically defines two complementary operations: one operation for signing and the other for verification. In blockchain, digital signatures can be used to prevent the information and data of sending nodes from being maliciously forged and tampered with.

[0054] As an optional embodiment, the method further includes: obtaining the environment identifier corresponding to the trusted execution environment and the hash value corresponding to the receiver's public key; generating remote proof information based on the environment identifier and hash value; and generating second registration information based on the remote proof information, the receiver's public key, and the environment identifier. This enables blockchain registration based on information related to the trusted execution environment. Simultaneously, the sending end can verify the receiver's identity by obtaining the receiver's registration information (i.e., the second registration information) on the blockchain, thus improving the security of the information sharing process.

[0055] A Trusted Execution Environment (TEE) is a security technology that protects data and code from external access. It is typically used in scenarios requiring the processing of sensitive data (such as electronic payments and digital rights management). Specifically, a TEE possesses computational and storage capabilities. It can allocate a separate, isolated memory block within the hardware for sensitive data, where all computations are performed. Furthermore, except for authorized interfaces, other parts of the hardware cannot access the information in this isolated memory. Programs running within a mobile TEE environment can be called Trusted Applications (TAs), generally referring to applications running on the TEE; in this application, they are referred to as TEE contracts. TEE contracts can be loaded within the TEE environment and represented as a binary file.

[0056] Specifically, since this application uses blockchain to achieve information sharing, both the sender and receiver can register in the blockchain first. A user terminal can be either a sender or a receiver; when a user terminal needs to share information, it acts as a sender, and when it needs to receive external information, it acts as a receiver.

[0057] Please see Figure 2 , Figure 2 This illustration schematically depicts a sequence diagram of a receiver registration process according to an embodiment of this application. The receiver includes a TEE contract loading module and a TEE contract, such as... Figure 2 As shown, it includes steps S210 to S270.

[0058] Step S210: The TEE contract loading module loads the TEE contract.

[0059] Step S220: The TEE contract generates the receiver's public key and receiver's private key.

[0060] Step S230: The TEE contract stores the receiver's private key in the RPMB.

[0061] Step S240: The TEE contract loading module creates remote proof information.

[0062] Step S250: The TEE contract loading module generates second registration information based on remote proof information, receiver public key, and environment identifier.

[0063] Step S260: The TEE contract loading module uploads the second registration information to the blockchain.

[0064] Step S270: The blockchain records the second registration information.

[0065] The TEE contract loading module loads the TEE contract, which then generates a pair of receiver public and private keys based on contract logic. The TEE contract can then store the receiver's private key in the RPMB (ReplayProtected Memory Block), a partition of the storage device in an embedded multimedia controller (eMMC). eMMC is a standard specification for embedded memory in products such as mobile phones and tablets, defined by the MultiMediaCard (MMC) Association. MMC is a small, high-capacity flash memory card. The TEE contract loading module creates remote proof information by: obtaining the environment identifier (MRTA) corresponding to the trusted execution environment and the hash value corresponding to the receiver's public key; generating remote proof information based on the environment identifier and hash value. The remote proof report proves that the contract running in the TEE is the specified contract and has not been attacked or tampered with. The MRTA can be understood as the unique identifier of the TEE contract, and its value is the digest result of the SHA256 algorithm. Furthermore, the second registration information generated based on remote authentication information, the receiver's public key, and the environment identifier can be uploaded to the blockchain for recording. This second registration information includes the remote authentication information, the receiver's public key, and the environment identifier.

[0066] Similarly, for the sending end, the receiving end contains a TEE contract loading module and a TEE contract. This can be triggered to load the TEE contract. The TEE contract generates the sending end's public and private keys, and stores the private key in RPMB. The TEE contract loading module creates remote proof information corresponding to the sending end. Based on the remote proof information, the receiving end's public key, and the environment identifier, the TEE contract loading module generates first registration information and uploads it to the blockchain. The blockchain records the first registration information. The first registration information includes the remote proof information, the sending end's public key, and the environment identifier.

[0067] The first registration information and the second registration information may correspond to the same field, but to different field information.

[0068] As an optional embodiment, the sending end is used to obtain the second registration information corresponding to the receiving end from the blockchain, and to verify the identity and legitimacy of the receiving end based on the second registration information. If the verification is successful, an access configuration is generated based on the second registration information, the first registration information corresponding to the sending end, and the key ciphertext. This ensures that the receiving end used to receive the information to be shared is a legitimate terminal, thus improving the security of the information sharing process.

[0069] Specifically, before uploading the information to be shared to the server, the sending end can obtain the second registration information from the blockchain and verify the identity of the receiving end based on the second registration information. The specific verification method is to compare the hash value of the receiving end's public key in the second registration information with the hash value of the receiving end's public key recorded in the remote proof information. If the two are consistent, the receiving end is determined to have a legitimate identity.

[0070] In addition, the sending end can also be used to delete information to be shared stored on the server.

[0071] Please see Figure 3 , Figure 3 A schematic diagram illustrating the sequence of an authentication process according to one embodiment of this application is shown. Figure 3 As shown, it includes steps S310 to S360.

[0072] Step S310: The sending end obtains the second registration information from the blockchain.

[0073] Step S320: The blockchain returns the second registration information to the sender.

[0074] Step S330: The sending end compares the hash value of the receiver's public key in the second registration information with the hash value of the receiver's public key recorded in the remote authentication information. If the two match, the receiver is deemed to have legitimate identity; otherwise, the receiver is deemed not to have legitimate identity.

[0075] Step S340: The sending end calculates the hash value of the information to be shared as the file ID; generates an encryption key; and then, based on the receiving end's public key and the encryption key, obtains the key ciphertext; and generates an access configuration based on the key ciphertext, file ID, sending end ID, receiving end ID, preset number of reads, and current number of reads.

[0076] Step S350: The sending end uploads the access configuration to the blockchain.

[0077] Step S360: The sending end uploads the information to be shared to the server.

[0078] Specifically, based on steps S310 to S360, the sending end can upload the access configuration to the blockchain and the information to be shared to the server after the receiving end's authentication is successful. For the sending end, the blockchain can ensure that the access configuration cannot be tampered with, and the server can ensure that the information to be shared cannot be maliciously obtained.

[0079] As an optional embodiment, the sending end is also configured to update the access configuration in response to a configuration update command. This provides access configuration update functionality, allowing the sending end to modify one or more pieces of information in the access configuration at any time according to actual needs. Setting up access configuration update functionality can help the sending end to exercise greater freedom in access control over shared information.

[0080] Specifically, configuration update commands can be used to change one or more pieces of information in the access configuration. Optionally, they can also be used to delete one or more pieces of information in the access configuration, or to add one or more pieces of information to the access configuration. Furthermore, the sending end is also used to upload the updated access configuration to the blockchain.

[0081] In step S120, access feasibility is verified based on access configuration in a trusted execution environment to obtain verification results.

[0082] As an optional implementation, the access configuration includes a current read count (e.g., 9) and a preset read count (e.g., 10). Access feasibility is verified based on the access configuration in a trusted execution environment to obtain a verification result. This includes comparing the current read count with the preset read count in the trusted execution environment; if the current read count is less than the preset read count, a verification result indicating that the information to be shared is accessible is obtained. This effectively controls the number of times the information to be shared is accessed, enriching the dimensions of access control for the information to be shared by the sending end.

[0083] Specifically, performing access feasibility verification within a trusted execution environment ensures that information recorded in the access configuration is not leaked. Furthermore, if the current read count equals the preset read count, it indicates that the information to be shared can no longer be obtained, and therefore the process can be terminated.

[0084] Please see Figure 4 , Figure 4 The diagram schematically illustrates a sequence of processes for acquiring information to be shared according to one embodiment of this application. Figure 4 As shown, it includes steps S400 to S490.

[0085] Step S400: The receiving end obtains the access configuration from the blockchain.

[0086] Step S410: The blockchain returns the access configuration to the receiving end.

[0087] Step S420: Since the access configuration includes the current number of reads and the preset number of reads, the receiving end can compare the current number of reads and the preset number of reads in the trusted execution environment; if the current number of reads is less than the preset number of reads, a verification result indicating that the information to be shared has access feasibility is obtained; if the current number of reads is equal to the preset number of reads, the process ends.

[0088] Step S430: The receiving end updates the access configuration.

[0089] Step S440: The receiving end uploads the updated access configuration to the blockchain.

[0090] Step S450: The blockchain returns the updated result to the receiving end.

[0091] Step S460: If the update is successful, the receiving end reads the key ciphertext in the access configuration; wherein, the key ciphertext is obtained by the sending end encrypting the information key based on the receiving end's public key; the key ciphertext is decrypted based on the receiving end's private key to obtain the information key.

[0092] Step S470: The receiving end obtains the information to be shared from the server.

[0093] Step S480: The server returns the information to be shared to the receiver.

[0094] Step S490: The receiving end decrypts the information to be shared using the information key in a trusted execution environment.

[0095] As an optional implementation, the access configuration includes a geographic location range. Access feasibility is verified based on the access configuration in a trusted execution environment to obtain a verification result. This includes: obtaining the current location of the receiving end; detecting the relationship between the current location and the geographic location range in the trusted execution environment; and obtaining a verification result indicating that the information to be shared is accessible if the current location is within the geographic location range. This effectively controls the access location of the information to be shared, enriching the dimensions of access control for the information to be shared by the sending end.

[0096] Specifically, the receiver's current location can be obtained based on the base station communicating with it. Furthermore, the geographical location range can be represented by geographic coordinates, administrative divisions, etc. Additionally, if the current location is not within the geographical range, the process can terminate.

[0097] Optionally, the access configuration includes an access time range. Access feasibility is verified based on the access configuration in a trusted execution environment to obtain a verification result. This includes: obtaining the current time; detecting the relationship between the current time and the access time range in the trusted execution environment; and if the current time is within the access time range, a verification result indicating that the information to be shared is accessible is obtained. Furthermore, optionally, if the preset number of reads is not reached within the access time range, the access configuration can be modified to terminate the sharing of the information.

[0098] As an optional embodiment, the method further includes updating the access configuration and uploading the updated access configuration to the blockchain. This allows for automatic updates to the access configuration, facilitating accurate and automated access control during subsequent information sharing processes and preventing excessive or unauthorized access to the information to be shared.

[0099] Specifically, the method for updating the access configuration is to update at least one field in the access configuration (e.g., the current number of reads); wherein, some specific fields in the access configuration (e.g., information ID, sender ID, receiver ID, key ciphertext) can correspond to an immutable identifier, that is, the receiver cannot modify specific fields during the update process, so as to ensure the security of the information to be shared.

[0100] In step S130, if the verification result indicates that the information to be shared is accessible, then in the trusted execution environment, the information to be shared is obtained from the server based on the access configuration.

[0101] Furthermore, if the verification results indicate that the information to be shared is not accessible, it means that the access conditions required by the access configuration are not met, and the information sharing process can be terminated.

[0102] As an optional embodiment, in a trusted execution environment (TEA), obtaining information to be shared from the server based on the access configuration includes: reading the key ciphertext in the access configuration; wherein the key ciphertext is obtained by the sender encrypting the information key based on the receiver's public key; decrypting the key ciphertext based on the receiver's private key to obtain the information key; obtaining the information to be shared from the server, and decrypting the information to be shared in the TEA using the information key. This approach ensures the security of the information to be shared through multi-layered encryption. Furthermore, this application allows for real-time unlocking operations within the TEA, leveraging the memory isolation features of the TEA to ensure that the decryption rules for the information to be shared are executed according to predetermined rules and are not illegally controlled by the receiver.

[0103] Specifically, the key ciphertext and the information key can be one or more of characters, symbols, and numbers. The key ciphertext recorded in the access configuration can be obtained by reading the corresponding field. Furthermore, since the key ciphertext is obtained by encrypting the information key with the receiver's public key, and the receiver's public key and private key are calculated using an asymmetric encryption algorithm, the key ciphertext can be decrypted using the receiver's private key to obtain the information key.

[0104] As an optional embodiment, the method further includes: displaying the content of the information to be shared online in response to an online viewing operation. This provides users with online viewing functionality, preventing the content of the information to be shared from being leaked after being saved locally by the user.

[0105] Specifically, when an online viewing operation is detected, the content of the information to be shared can be displayed online within the application. Optionally, operation restriction functions can also be used to restrict operations such as screenshotting, screen recording, and downloading to prevent the content to be shared from being saved or leaked by the user. The online viewing operation can be any form of user operation such as touch screen operation or voice control operation, and this application embodiment does not limit it.

[0106] Please see Figure 5 , Figure 5 A flowchart illustrating another embodiment of an information sharing method according to this application is shown schematically. Figure 5 As shown, the information sharing method includes steps S510 to S524.

[0107] Step S510: The sender obtains the sender's public key and sender's private key; obtains the environment identifier corresponding to the trusted execution environment and the hash value corresponding to the sender's public key; generates sender remote proof information based on the sender's environment identifier and the hash value corresponding to the sender's public key; generates first registration information based on the sender's remote proof information, sender's public key, and sender's environment identifier; and uploads the first registration information to the blockchain.

[0108] Step S512: The receiving end obtains the receiving end public key and the receiving end private key; obtains the environment identifier corresponding to the trusted execution environment and the hash value corresponding to the receiving end public key; generates receiving end remote proof information based on the receiving end environment identifier and the hash value corresponding to the receiving end public key; generates second registration information based on the receiving end remote proof information, the receiving end public key, and the receiving end environment identifier; and uploads the second registration information to the blockchain.

[0109] Step S514: The sending end obtains the second registration information corresponding to the receiving end from the blockchain, and verifies the identity of the receiving end based on the second registration information. If the verification is successful, the sending end generates an access configuration based on the second registration information, the first registration information corresponding to the sending end, and the key ciphertext.

[0110] Step S516: The sending end uploads the access configuration corresponding to the information to be shared to the blockchain; and uploads the information to be shared to the server.

[0111] Step S518: The receiving end obtains the access configuration from the blockchain. The access configuration includes the current number of reads and the preset number of reads. The current number of reads and the preset number of reads are compared in the trusted execution environment. If the current number of reads is less than the preset number of reads, a verification result indicating that the information to be shared has the feasibility of access is obtained.

[0112] Step S520: The receiving end reads the key ciphertext in the access configuration; wherein, the key ciphertext is obtained by the sending end encrypting the information key based on the receiving end's public key.

[0113] Step S522: The receiving end decrypts the key ciphertext based on the receiving end's private key to obtain the information key; obtains the information to be shared from the server, and decrypts the information to be shared in the trusted execution environment using the information key.

[0114] Step S524: In response to the online viewing operation, display the content of the information to be shared online.

[0115] It should be noted that steps S510 to S524 are related to... Figure 1 For the specific implementation details of steps S510 to S524, please refer to the examples shown. Figure 1 The steps and their embodiments shown are not repeated here.

[0116] It is evident that implementation Figure 5 The method described above uses a blockchain with immutable characteristics to record the access configuration of the information to be shared. This access configuration is uploaded by the sending end and used for access control after information sharing. For the receiving end, access feasibility needs to be verified based on the access configuration in a trusted execution environment before obtaining the information to be shared. This facilitates further, truly effective access control after information sharing. Furthermore, the information sharing scheme provided by the blockchain and the trusted execution environment ensures the security of the information to be shared and the access configuration. In addition, recording the access configuration on the blockchain ensures that the access configuration related to the information to be shared cannot be tampered with; storing the information to be shared on the server side makes it invisible to nodes in the blockchain, ensuring the privacy of the information; verifying access feasibility and obtaining the information to be shared in the trusted execution environment ensures that the access configuration cannot be maliciously stolen, guaranteeing truly effective further information access control and preventing the leakage of the information to be shared.

[0117] Please see Figure 6 , Figure 6 An architectural diagram of an information sharing system according to an embodiment of this application is illustrated schematically. Figure 6 As shown, the information sharing system 600 may include a sender 610, a receiver 620, and a server 630, wherein:

[0118] The sending end 610 is used to upload the access configuration corresponding to the information to be shared to the blockchain; and to upload the information to be shared to the server 630.

[0119] The receiver 620 is used to obtain the access configuration from the blockchain; verify the access feasibility based on the access configuration in the trusted execution environment and obtain the verification result; if the verification result indicates that the information to be shared has access feasibility, the information to be shared is obtained from the server 630 based on the access configuration.

[0120] It is evident that implementation Figure 6The system shown can record the access configuration of information to be shared using a blockchain with immutable characteristics. The access configuration is uploaded by the sending end and used for access control after information sharing. For the receiving end, it needs to verify the access feasibility based on the access configuration in a trusted execution environment before obtaining the information to be shared. This facilitates further, truly effective access control after information sharing. Furthermore, the information sharing scheme provided by the blockchain and the trusted execution environment can ensure the security of the information to be shared and the access configuration. In addition, recording the access configuration on the blockchain ensures that the access configuration related to the information to be shared cannot be tampered with; storing the information to be shared on the server side makes it invisible to nodes in the blockchain, ensuring the privacy of the information; verifying access feasibility and obtaining the information to be shared in the trusted execution environment ensures that the access configuration cannot be maliciously stolen, guaranteeing truly effective further information access control and preventing the leakage of the information to be shared.

[0121] Please see Figure 7 , Figure 7 An architectural diagram of an information sharing system according to another embodiment of this application is illustrated schematically. Figure 7 As shown, the information sharing system 700 includes: a sending end 710, a server end 720, a blockchain 730, and a receiving end 740.

[0122] First, in order to achieve information sharing based on this scheme, the sender 710 and receiver 740 can obtain public and private keys, as well as the environment identifier corresponding to the trusted execution environment and the hash value corresponding to the public key. Based on the environment identifier and the hash value corresponding to the public key, remote proof information is generated. Based on the remote proof information, public key, and environment identifier, registration information is generated and uploaded to the blockchain 730. The blockchain 730 completes the registration of each end by running the smart contract in the smart contract library 731.

[0123] Furthermore, when the sending end 710 needs to share information, it can obtain the second registration information corresponding to the receiving end 740 from the blockchain 730 (it should be noted that if there are multiple receiving ends 740, the second registration information of each receiving end 740 is obtained separately), and verify the identity and legitimacy of the receiving end based on the second registration information. If the verification is successful, an access configuration 712 is generated based on the second registration information, the first registration information corresponding to the sending end, and the key ciphertext. The access configuration 712 corresponding to the information to be shared 711 is then uploaded to the blockchain 730; the information to be shared 711 is uploaded to the server 720, and the server 720 manages the information to be shared 711 through the information management module 721.

[0124] Based on this, the receiving end 740 can obtain the access configuration 712 from the blockchain 730. If the access configuration 712 includes the current number of reads and the preset number of reads, it triggers the TEE contract loading module 741 to load the TEE contract 742. By executing the TEE contract 742, the current number of reads and the preset number of reads can be compared in a trusted execution environment. If the current number of reads is less than the preset number of reads, a verification result indicating that the information 711 to be shared has access feasibility is obtained. Furthermore, the key ciphertext in the access configuration 712 can be read; wherein, the key ciphertext is obtained by the sending end encrypting the information key based on the receiving end's public key; the key ciphertext can be decrypted based on the receiving end's private key in the key management module 743 to obtain the information key. Then, the information 711 to be shared can be obtained from the server 720, and the TEE contract 742 can be executed to decrypt the information to be shared in a trusted execution environment using the information key.

[0125] It is evident that implementation Figure 7 The system shown can record the access configuration of information to be shared using a blockchain with immutable characteristics. The access configuration is uploaded by the sending end and used for access control after information sharing. For the receiving end, it needs to verify the access feasibility based on the access configuration in a trusted execution environment before obtaining the information to be shared. This facilitates further, truly effective access control after information sharing. Furthermore, the information sharing scheme provided by the blockchain and the trusted execution environment can ensure the security of the information to be shared and the access configuration. In addition, recording the access configuration on the blockchain ensures that the access configuration related to the information to be shared cannot be tampered with; storing the information to be shared on the server side makes it invisible to nodes in the blockchain, ensuring the privacy of the information; verifying access feasibility and obtaining the information to be shared in the trusted execution environment ensures that the access configuration cannot be maliciously stolen, guaranteeing truly effective further information access control and preventing the leakage of the information to be shared.

[0126] Please see Figure 8 , Figure 8 A schematic block diagram of an information sharing device according to one embodiment of this application is shown. Figure 8 As shown, the information sharing device 800 may include the following units.

[0127] Access configuration acquisition unit 801 is used to acquire access configuration corresponding to the information to be shared, which was uploaded by the sender from the blockchain;

[0128] The access feasibility verification unit 802 is used to verify access feasibility based on access configuration in a trusted execution environment and obtain the verification result.

[0129] The information to be shared acquisition unit 803 is used to acquire the information to be shared from the server based on the access configuration in a trusted execution environment when the verification result indicates that the information to be shared is accessible.

[0130] It is evident that implementation Figure 8 The device shown can record the access configuration of the information to be shared using a blockchain with immutable characteristics. The access configuration is uploaded by the sending end and used for access control after information sharing. For the receiving end, it is necessary to verify the access feasibility based on the access configuration in a trusted execution environment before obtaining the information to be shared. This facilitates further genuine and effective information access control after information sharing. Furthermore, the information sharing scheme provided by the blockchain and the trusted execution environment can ensure the security of the information to be shared and the access configuration. In addition, recording the access configuration by the blockchain ensures that the access configuration related to the information to be shared cannot be tampered with; storing the information to be shared by the server makes the information invisible to nodes in the blockchain, ensuring the privacy of the information to be shared; verifying access feasibility and obtaining the information to be shared in the trusted execution environment ensures that the access configuration cannot be maliciously stolen, ensuring genuine and effective further information access control and preventing the leakage of the information to be shared.

[0131] As an optional embodiment, the access configuration includes the current number of reads and the preset number of reads. The access feasibility verification unit 802 verifies the access feasibility based on the access configuration in a trusted execution environment and obtains the verification result, including:

[0132] Compare the current number of reads with the preset number of reads in a trusted execution environment;

[0133] If the current number of reads is less than the preset number of reads, a verification result indicating that the information to be shared is accessible is obtained.

[0134] As can be seen, implementing this optional embodiment can effectively control the number of times the information to be shared is accessed, enriching the dimensions of access control for the information to be shared by the sending end.

[0135] As an optional embodiment, the access configuration includes a geographical location range. The access feasibility verification unit 802 verifies access feasibility based on the access configuration in a trusted execution environment and obtains the verification result, including:

[0136] Obtain the current location of the receiving end and detect the relationship between the current location and the geographical range in a trusted execution environment;

[0137] If the current location is within the geographic range, a verification result indicating that the information to be shared is accessible is obtained.

[0138] As can be seen, implementing this optional embodiment can effectively control the location of the information to be shared, enriching the dimensions of access control for the information to be shared by the sending end.

[0139] As an optional embodiment, it also includes:

[0140] The configuration update unit is used to update the access configuration and upload the updated access configuration to the blockchain.

[0141] As can be seen, implementing this optional embodiment can automatically update the access configuration, so as to enable accurate and automated access control for the subsequent information sharing process, and avoid excessive or illegal access to the information to be shared.

[0142] As an optional embodiment, the information to be shared acquisition unit 803, in a trusted execution environment, acquires the information to be shared from the server based on the access configuration, including:

[0143] Read the ciphertext key from the access configuration; the ciphertext key is obtained by the sender encrypting the information key based on the receiver's public key.

[0144] The information key is obtained by decrypting the ciphertext of the key using the receiver's private key.

[0145] The information to be shared is obtained from the server and decrypted using an information key in a trusted execution environment.

[0146] As can be seen, implementing this optional embodiment can ensure the security of the information to be shared through multi-layer encryption. Furthermore, this application can perform real-time unlocking operations in a trusted execution environment. It can utilize the memory isolation characteristics of the trusted execution environment to ensure that the decryption rules of the information to be shared are executed according to predetermined rules and will not be illegally controlled by the receiving end.

[0147] As an optional embodiment, wherein:

[0148] The sending end is used to obtain the second registration information corresponding to the receiving end from the blockchain, and to verify the identity and legitimacy of the receiving end based on the second registration information. If the verification is successful, the sending end generates an access configuration based on the second registration information, the first registration information corresponding to the sending end, and the key ciphertext.

[0149] As can be seen, implementing this optional embodiment can ensure that the receiving end used to receive the information to be shared is a legitimate terminal, thereby improving the security of the information sharing process.

[0150] As an optional embodiment, the sending end is also configured to update the access configuration in response to a configuration update command.

[0151] As can be seen, implementing this optional embodiment can provide an access configuration update function. For the sending end, one or more pieces of information in the access configuration can be changed at any time according to actual needs. Setting the access configuration update function can help improve the sending end's access control over shared information with greater freedom.

[0152] As an optional embodiment, it also includes:

[0153] The registration information generation unit is used to obtain the environment identifier corresponding to the trusted execution environment and the hash value corresponding to the public key of the receiving end; generate remote proof information based on the environment identifier and hash value; and generate second registration information based on the remote proof information, the public key of the receiving end, and the environment identifier.

[0154] As can be seen, implementing this optional embodiment can realize blockchain registration based on information related to the trusted execution environment. At the same time, the sending end can also verify the identity and legitimacy of the receiving end by obtaining the registration information of the receiving end on the blockchain (i.e., the second registration information), which helps to improve the security of the information sharing process.

[0155] As an optional embodiment, it also includes:

[0156] The online reading unit is used to respond to online reading operations and display the content of information to be shared online.

[0157] As can be seen, implementing this optional embodiment can provide users with online viewing functionality, preventing the content of information to be shared from being leaked after being saved locally by the user.

[0158] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0159] Since the functional modules of the information sharing device in the example embodiments of this application correspond to the steps of the example embodiments of the information sharing device described above, for details not disclosed in the device embodiments of this application, please refer to the embodiments of the information sharing device described above.

[0160] Please see Figure 9 , Figure 9 A schematic diagram of the structure of a computer system suitable for implementing the electronic device of the present application is shown.

[0161] It should be noted that, Figure 9The computer system 900 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0162] like Figure 9 As shown, the computer system 900 includes a central processing unit (CPU) 901, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 902 or programs loaded from storage section 908 into random access memory (RAM) 903. The RAM 903 also stores various programs and data required for system operation. The CPU 901, ROM 902, and RAM 903 are interconnected via a bus 904. An input / output (I / O) interface 905 is also connected to the bus 904.

[0163] The following components are connected to I / O interface 905: an input section 906 including a keyboard, mouse, etc.; an output section 907 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 908 including a hard disk, etc.; and a communication section 909 including a network interface card such as a LAN card, modem, etc. The communication section 909 performs communication processing via a network such as the Internet. A drive 910 is also connected to I / O interface 905 as needed. A removable medium 911, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on drive 910 as needed so that computer programs read from it can be installed into storage section 908 as needed.

[0164] In particular, according to embodiments of this application, the processes described below with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 909, and / or installed from removable medium 911. When the computer program is executed by central processing unit (CPU) 901, it performs the various functions defined in the methods and apparatus of this application.

[0165] In another aspect, this application also provides a computer-readable medium, which may be included in the electronic device described in the above embodiments; or it may exist independently and not assembled into the electronic device. The computer-readable medium carries one or more programs that, when executed by the electronic device, cause the electronic device to implement the methods described in the above embodiments.

[0166] It should be noted that the computer-readable medium shown in this application can be a computer-readable signal medium or a computer-readable storage medium, or any combination of the two. A computer-readable storage medium can be, for example,—but not limited to—an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device. In this application, a computer-readable signal medium can include a data signal propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals can take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media can also be any computer-readable medium other than computer-readable storage media, which can send, propagate, or transmit a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the computer-readable medium can be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0167] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram or flowchart, and combinations of blocks in a block diagram or flowchart, may be implemented using a dedicated hardware-based system that performs the specified function or operation, or using a combination of dedicated hardware and computer instructions.

[0168] The units described in the embodiments of this application can be implemented in software or hardware, and the described units can also be located in a processor. The names of these units do not necessarily limit the specific unit itself.

[0169] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the claims.

Claims

1. An information sharing method, characterized in that, include: Retrieve from the blockchain the access configuration corresponding to the information to be shared, uploaded by the sender; wherein the access configuration includes the current number of reads and the preset number of reads; In a trusted execution environment, the access feasibility is verified based on the access configuration to obtain a verification result, including: comparing the current number of reads with the preset number of reads in the trusted execution environment; if the current number of reads is less than the preset number of reads, a verification result indicating that the information to be shared has access feasibility is obtained; If the verification result indicates that the information to be shared is accessible, then in the trusted execution environment, the information to be shared is obtained from the server based on the access configuration, including: Read the key ciphertext in the access configuration; wherein the key ciphertext is obtained by the sending end encrypting the information key based on the receiving end's public key; The sending end obtains the second registration information corresponding to the receiving end from the blockchain, and performs identity verification on the receiving end based on the second registration information. If the verification is successful, the access configuration is generated based on the second registration information, the first registration information corresponding to the sending end, and the key ciphertext. The key ciphertext is decrypted using the receiver's private key to obtain the information key; The information to be shared is obtained from the server and decrypted using the information key in the trusted execution environment. The process of generating the second registration information includes: obtaining the environment identifier corresponding to the trusted execution environment and the hash value corresponding to the receiving end public key; generating remote proof information based on the environment identifier and the hash value; and generating the second registration information based on the remote proof information, the receiving end public key, and the environment identifier.

2. The method according to claim 1, characterized in that, The access configuration includes a geographical location range. Access feasibility is verified based on the access configuration in a trusted execution environment, and the verification results are obtained, including: Obtain the current location of the receiving end, and detect the relationship between the current location and the geographical location range in a trusted execution environment; If the current location is within the geographical location range, a verification result indicating that the information to be shared is accessible is obtained.

3. The method according to claim 1, characterized in that, Also includes: Update the access configuration and upload the updated access configuration to the blockchain.

4. The method according to claim 1, characterized in that, The sending end is also used to update the access configuration in response to a configuration update command.

5. The method according to claim 1, characterized in that, Also includes: In response to the online viewing operation, the content of the information to be shared is displayed online.

6. An information sharing device, characterized in that, include: An access configuration acquisition unit is used to acquire access configurations corresponding to the information to be shared, uploaded by the sender, from the blockchain; wherein, the access configurations include the current number of reads and the preset number of reads; The access feasibility verification unit is used to verify access feasibility based on the access configuration in a trusted execution environment and obtain a verification result, including: comparing the current number of reads with the preset number of reads in the trusted execution environment; if the current number of reads is less than the preset number of reads, a verification result indicating that the information to be shared has access feasibility is obtained. A unit for obtaining information to be shared is configured to, in the trusted execution environment, obtain the information to be shared from the server based on the access configuration when the verification result indicates that the information to be shared has access feasibility, including: reading the key ciphertext in the access configuration; wherein the key ciphertext is obtained by the sending end encrypting the information key based on the receiving end's public key; decrypting the key ciphertext based on the receiving end's private key to obtain the information key; obtaining the information to be shared from the server, and decrypting the information to be shared in the trusted execution environment using the information key; The sending end obtains the second registration information corresponding to the receiving end from the blockchain, and performs identity verification on the receiving end based on the second registration information. If the verification is successful, the access configuration is generated based on the second registration information, the first registration information corresponding to the sending end, and the key ciphertext. The process of generating the second registration information includes: obtaining the environment identifier corresponding to the trusted execution environment and the hash value corresponding to the receiving end public key; generating remote proof information based on the environment identifier and the hash value; and generating the second registration information based on the remote proof information, the receiving end public key, and the environment identifier.

7. An information sharing system, characterized in that, Includes the sender, receiver, and server, among which: The sending end is used to upload the access configuration corresponding to the information to be shared to the blockchain; and to upload the information to be shared to the server. The receiving end is configured to obtain the access configuration from the blockchain; verify access feasibility based on the access configuration in a trusted execution environment to obtain a verification result; if the verification result indicates that the information to be shared has access feasibility, obtain the information to be shared from the server based on the access configuration, including: reading the key ciphertext in the access configuration; wherein the key ciphertext is obtained by the sending end encrypting the information key based on the receiving end's public key; decrypting the key ciphertext based on the receiving end's private key to obtain the information key; obtaining the information to be shared from the server, and decrypting the information to be shared in the trusted execution environment using the information key; The access configuration includes the current number of reads and the preset number of reads. Obtaining the verification result includes: comparing the current number of reads and the preset number of reads in a trusted execution environment; if the current number of reads is less than the preset number of reads, a verification result indicating that the information to be shared has access feasibility is obtained. The sending end is used to obtain the second registration information corresponding to the receiving end from the blockchain, and to verify the identity and legality of the receiving end based on the second registration information. If the verification is successful, the access configuration is generated based on the second registration information, the first registration information corresponding to the sending end, and the key ciphertext. The process of generating the second registration information includes: obtaining the environment identifier corresponding to the trusted execution environment and the hash value corresponding to the receiving end public key; generating remote proof information based on the environment identifier and the hash value; and generating the second registration information based on the remote proof information, the receiving end public key, and the environment identifier.

8. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the method of any one of claims 1-5.

9. An electronic device, characterized in that, include: processor; as well as Memory for storing the executable instructions of the processor; The processor is configured to perform the method of any one of claims 1-5 by executing the executable instructions.

Images