Method and system for secure data sharing through granular access control

Abstract

Methods and apparatus for secure data sharing with granular access control are described. A modified attribute-based encryption (ABE) scheme is used to perform ABE in a cryptographically enforced manner using the attributes of a file access policy. A sender sends to a receiver: a file encrypted using a file encryption key; the file encryption key encrypted using ABE based on the file access policy set by the sender; and a set of private ABE keys that can be decrypted using a key stored in the receiver's trusted execution environment (TEE). The private ABE key is decrypted by the receiver's TEE when the file is accessed, such that the file encryption key is only decrypted if the attributes of the receiver's access action satisfy the file access policy. The decrypted file encryption key authorizes access to the file contents via a trusted viewer application. A user password may also be required and is cryptographically enforced as part of the ABE decryption.

Description

[0001] Related applications

[0002] This application claims priority to prior-filed U.S. non-provisional application No. 16 / 890,598, filed on June 2, 2020, entitled “METHODS AND SYSTEMS FOR SECURE DATA SHARING WITH GRANULAR ACCESS CONTROL,” the contents of which are incorporated herein by reference. Technical Field

[0003] The present disclosure relates to methods and systems for secure data sharing, such as granular access control using attribute-based encryption, which may include using a trusted execution environment of a processor device. Background Art

[0004] When data is shared with remote devices, the sender of the data may want to control the conditions under which the recipient can access the data. Existing technologies for sharing data with controllable, revocable, and fine-grained permissions rely on cloud-based systems, which may not be suitable for low-power environments such as mobile phones or Internet of Things (IoT) devices. Specifically, these cloud-based solutions often require the deployment of a trusted hardware security module (HSM) on the cloud server to provide a root of trust, which often results in high costs and poor flexibility.

[0005] Furthermore, existing technologies typically use logic encoded as software (e.g., a policy engine) to enforce access policies set by the sender, which may expose the policy engine software to attacks.

[0006] Existing technologies often also have one or more additional limitations. Some require sensitive data to be stored in the cloud, requiring the recipient to re-download the data each time it is accessed. Some may require decryption to occur on the cloud server rather than on the recipient's device, potentially compromising the security of the link between the server and the recipient. Some may be restricted in the access policy parameters they use: some may not allow the sender to revoke or update the access policy, limit the number of data access attempts by the recipient, or set expiration dates for access permissions.

[0007] Therefore, there is a need for a data sharing solution that overcomes one or more of the above-mentioned shortcomings of the prior art. Summary of the Invention

[0008] In various embodiments described herein, the following methods and apparatus are provided:

[0009] Various embodiments can enable granular access control of shared data. A peer-to-peer sharing system can be used to implement data sharing and access control without the need for a cloud server as an intermediary. A trusted hardware module on the receiving end can provide a root of trust to authorize access to data stored locally at the receiving end. Access policy enforcement can be protected against software attacks by cryptographically enforcing the policy.

[0010] In some aspects, the present disclosure describes a receiver-side method for secure data sharing. A receiver device includes a processor device, the processor device includes a trusted execution environment (TEE), and the TEE includes a private receiver TEE key. A file is received at the receiver. The file is encrypted using a file encryption key. The file encryption key is also received at the receiver. The file encryption key is encrypted using the sender's primary public attribute-based encryption (ABE) key and an access policy for the file. A set of one or more private ABE keys is also received at the receiver. The set of one or more private ABE keys has been generated using the access policy and encrypted using the public receiver TEE key. The trusted execution environment is used to apply the private receiver TEE key to decrypt the set of private ABE keys and provide at least a first private key in the set of private ABE keys to the processor device. The processor device is used to decrypt the file encryption key using the first private ABE key and a set of attribute values ​​that satisfy the access policy. The processor device is used to decrypt the file using the file encryption key, thereby generating a decrypted file.

[0011] In some examples, the method further includes: before receiving the file, the file encryption key, and the set of private ABE keys, receiving a setup request from the sender, the setup request including the access policy. In response to receiving the setup request, the TEE generates a public recipient TEE key and a private recipient TEE key. A response is sent to the sender, the response including the public recipient TEE key.

[0012] In some examples, the response also includes a key attestation report that includes a device identifier of the recipient device.

[0013] In some examples, the recipient device also includes a trusted clock. The access policy includes an expiration date for the recipient device's permission to access the file. In response to determining, using the trusted clock, that the expiration date has not yet been reached, the trusted execution environment applies the private recipient TEE key to decrypt the set of private ABE keys. The key attestation report includes a confirmation of the expiration date.

[0014] In some examples, one or more of the property values ​​are received from a trusted viewer.The method also includes, after decrypting the file, making content of the decrypted file available to a user using the trusted viewer.

[0015] In some examples, the method further includes deleting the decrypted file using the trusted viewer after making the contents of the file available to the user.

[0016] In some examples, the access policy includes a notification condition associated with the access action. The method further includes: in response to determining that the notification condition has been satisfied, sending a notification to the sender, the notification identifying the access action. In response to determining that the notification has been successfully sent, the access action is implemented on the recipient device.

[0017] In some examples, sending the notification to the sender includes: determining whether the sender is able to receive the notification; and in response to determining that the sender is unable to receive the notification, sending the notification to the server.

[0018] In some examples, the access policy includes a plurality of attribute configurations, each attribute configuration including a plurality of attribute values ​​that authorize access to file content. The set of private ABE keys includes a plurality of private ABE keys, each corresponding to an attribute configuration. The set of attribute values ​​that satisfy the access policy includes a plurality of attribute values ​​of the attribute configuration corresponding to the first private ABE key. Decrypting the file encryption key is performed using the first private ABE key and the set of attribute values ​​that satisfy the access policy.

[0019] In some examples, the set of attribute values ​​that satisfy the access policy includes an attribute indicating a number of times the file has been opened on the recipient device. The first private ABE key is selected by the trusted execution environment from the set of private ABE keys in response to: determining a number N of times the file has been opened on the recipient device; and determining that the set of attribute values ​​that satisfy the access policy includes a value corresponding to the attribute indicating the number N of times the file has been opened on the recipient device.

[0020] In some examples, the file encryption key is decrypted using the first private ABE key, the set of attribute values ​​that satisfy the access policy, and a user-supplied password.

[0021] In some aspects, the present disclosure describes a recipient device configured to perform the above method steps.

[0022] In some aspects, the present disclosure describes a sender-side method for secure sharing. A trusted execution environment (TEE) of a processor device of a sender device is used to decrypt a primary private attribute-based encryption (ABE) key of the sender device using a private sender TEE key of the trusted execution environment. A file is encrypted using the file encryption key. The file encryption key is encrypted using the primary ABE key of the sender device and an access policy for the file. A set of one or more private ABE keys is generated using the decrypted primary private ABE key of the sender device and the access policy. The set of private ABE keys is encrypted using the public TEE key of the recipient. The encrypted file, the encrypted file encryption key, and the encrypted set of private ABE keys are sent to the recipient device.

[0023] In some examples, the method further includes: sending a setup request to the recipient device before sending the encrypted file, the encrypted file encryption key, and the encrypted set of ABE keys, the setup request including the access policy; and receiving a response from the recipient device, the response including the public recipient TEE key.

[0024] In some examples, the response also includes a key attestation report that includes a device identifier of the recipient device.

[0025] In some examples, the access policy includes an expiration date for permission for the recipient device to access the file. In response to determining that the key certification report includes confirmation of the expiration date, the encrypted file, the encrypted file encryption key, and the encrypted set of private ABE keys are sent to the recipient device.

[0026] In some examples, the access policy includes a plurality of recipient attribute configurations, each recipient attribute configuration including a plurality of recipient attribute values ​​that authorize a recipient device to access the file content. The set of private ABE keys includes a plurality of private ABE keys, each private ABE key corresponding to a recipient attribute configuration.

[0027] In some examples, the access policy is a dynamic access policy. The method further includes: sending a policy confirmation request to the dynamic policy server before decrypting the file encryption key; and in response to receiving a policy confirmation from the dynamic policy server indicating that the dynamic access policy is valid, decrypting the file encryption key.

[0028] In some examples, the dynamic policy server is the sending device.

[0029] In some aspects, the present disclosure describes a sender device configured to perform the above method steps.

[0030] In some aspects, the present disclosure describes a recipient device. The recipient device includes a processor device, the processor device includes a trusted execution environment (TEE), and the TEE includes a private recipient TEE key. The recipient device includes a memory containing instructions, which, when executed by the processor device, causes the recipient device to perform the following steps. Receive an encrypted file, an encrypted file encryption key, and an encrypted set of one or more private ABE keys. Receive a decrypted first private ABE key of the encrypted set of private ABE keys from the trusted execution environment. Decrypt the file encryption key using the first private ABE key and a set of attribute values ​​that satisfy an access policy. Apply the file encryption key to decrypt the file, thereby generating a decrypted file. The trusted execution environment is configured to decrypt the encrypted set of private ABE keys using the private recipient TEE key and provide the decrypted first private ABE key to the processor device.

[0031] In some aspects, the present disclosure describes a sender device. The sender device includes a processor device, the processor device includes a trusted execution environment (TEE), and the TEE includes a private sender TEE key. The sender device includes a memory containing instructions that, when executed by the processor device, cause the sender device to perform the following steps. A file is encrypted using a file encryption key. The file encryption key is encrypted using a primary attribute-based encryption (ABE) key of the sender device and an access policy for the file. A set of one or more private ABE keys is generated using the decrypted primary private ABE key of the sender device and the access policy. The set of private ABE keys is encrypted using a public TEE key of a recipient. The encrypted file, the encrypted file encryption key, and the encrypted set of private ABE keys are sent to the recipient device. The trusted execution environment is configured to decrypt the primary private ABE key of the sender device using the private sender TEE key and provide the decrypted primary private ABE key to the processor device. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] Reference will now be made, by way of example, to the accompanying drawings which show example embodiments of the present application, in which:

[0033] Figure 1 is a block diagram of an example simplified system in which the examples disclosed herein may be implemented;

[0034] Figure 2 is a block diagram of an example sender device that can be used to implement the examples described herein;

[0035] Figure 3 is a block diagram of an example recipient device that can be used to implement the examples described herein;

[0036] Figure 4Ais a system diagram illustrating example access policy enforcement operations using a conventional policy engine;

[0037] Figure 4B is a system diagram illustrating example attribute-based encryption (ABE) access policy enforcement operations performed using ABE to enforce access policies;

[0038] Figure 5 is a system diagram illustrating the operation of an example system for secure data sharing using a sender device and a receiver device according to examples described herein;

[0039] Figure 6 It is shown by Figure 5 A flowchart of steps of an example method for secure data sharing implemented by a system;

[0040] Figure 7 It is shown by Figure 6 A flowchart of example sub-steps of a setup step of an example method;

[0041] Figure 8 is a system diagram illustrating the operation of an example system for controlled sharing of smart home data according to examples described herein;

[0042] Figure 9 is a system diagram illustrating the operation of an example system for controlled sharing of health data according to examples described herein;

[0043] Figure 10 is a system diagram illustrating the operation of an example system for fine-grained protection of personal data according to examples described herein;

[0044] Figure 11 is a system diagram illustrating the operation of an example system for controlled sharing of data with a third-party AI cloud platform according to examples described herein;

[0045] Figure 12 is a flow chart illustrating steps of an example method for secure sharing with sender notification enabled according to examples described herein;

[0046] Figure 13A is a flow chart illustrating steps of an example sender-side method for revoking an access policy according to examples described herein;

[0047] Figure 13B is a flow chart illustrating steps of an example receiver-side method for revoking access policy according to examples described herein.

[0048] Like reference numerals are used in different drawings to denote like components. DETAILED DESCRIPTION

[0049] In the examples disclosed herein, methods and apparatus are described that facilitate content delivery from a server using a trusted secure intermediary environment and data privacy from the server operator. The disclosed methods can be implemented with relatively low computational and memory costs per service request, which can make such solutions economically viable for commercialization.

[0050] The examples and embodiments described herein use attribute-based encryption (ABE), an encryption and decryption scheme that uses several different keys generated according to the operations described below in the section on attribute-based encryption and modified BSW CP-ABE. ABE encrypts data by using a set of attribute values ​​and a primary public ABE key to generate an access tree and a set of group elements that constitute the encrypted data. One or more private ABE keys corresponding to the attribute values ​​are generated; these private keys are transmitted to the recipient of the encrypted data, which decrypts the encrypted data using one of the private ABE keys and the matching set of attribute values. Decryption occurs in two stages: First, a modified version of the received private ABE key is generated by applying the attribute values ​​to the private ABE key. Then, the encrypted data is decrypted using the modified private ABE key. Because the attribute values ​​were used to encrypt the data, decryption succeeds only if the same attribute values ​​were used to decrypt the data. Therefore, the recipient's attribute values, as required by the sender's data access policy, are cryptographically enforced using ABE as described above. In some embodiments described herein, passwords may be used with attribute values ​​in encryption and decryption operations.

[0051] Example system, sender device, and receiver device

[0052] To help understand the present disclosure, first describe Figures 1 to 3 .

[0053] Figure 1 An example system 100 including a network 105 is shown. For ease of understanding, the system 100 is simplified in this example. In general, the entities and components in the system 100 may be compared to Figure 1There are many more entities and components shown. Network 105 can be any form of network (e.g., an intranet, the Internet, a P2P network, a WAN, and / or a LAN) and can be a public network. System 100 can be used to distribute data sent by a sender device 120 to a receiver device 150. For example, the sender device 120 and / or the receiver device 150 can be a personal electronic device or a network server. Server 110 can be used by the sender device 120 and / or the receiver device 150 to facilitate certain aspects of the methods described herein. Communication between the sender device 120, the receiver device 150, and the server 110 can be through network 105 or another network (which can be private or public), using wired or wireless connections or a combination thereof. As discussed further below, a trusted, secure environment (e.g., a trusted execution environment (TEE) of a processor device) exists in the sender device 120 (shown as the sender TEE 130) and the receiver device 150 (shown as the receiver TEE 160).

[0054] Figure 2 1 is a block diagram of a simplified example of a sender device 120. Other examples suitable for implementing the embodiments described in this disclosure may be used, and these examples may include components different from those described below. Figure 2 A single instance of each component is shown, but multiple instances of each component may exist in the sender device 120 .

[0055] The sender device 120 may include one or more processor devices 125, such as a processor, a microprocessor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a dedicated logic circuit, a dedicated artificial intelligence processor unit, or a combination thereof. The sender device 120 may also include one or more optional input / output (I / O) interfaces 132, which may support interfacing with one or more optional input devices 134 and / or optional output devices 136.

[0056] In the example shown, input device(s) 134 (e.g., a keyboard, mouse, microphone, touch screen, and / or keypad) and output device(s) 136 (e.g., a display, speakers, and / or printer) are shown as optional and external to sender device 120. In other examples, there may not be any input device(s) 134 and output device(s) 136, in which case I / O interface(s) 132 may not be needed.

[0057] The sender device 120 may include one or more network interfaces 122 for wired or wireless communication with the network 105, the recipient device 150, or other entities or nodes in the system 100. The network interface(s) 122 may include wired links (e.g., Ethernet cables) and / or wireless links (e.g., one or more antennas) for intra-network and / or inter-network communication.

[0058] The sender device 120 may also include one or more storage units 124, which may include large-capacity storage units such as solid-state drives, hard disk drives, magnetic disk drives, and / or optical disk drives. The storage unit(s) 124 may store one or more files 126, which may be requested by and sent to the recipient device 150, as further described below. In some embodiments, the files 126 may not be limited to files themselves and may be any data object. The files 126 may include any type of content, such as text, numbers, images, audio, and / or video data in any format. The files 126 stored by the sender device 120 may be transmitted to the recipient device 150 via one or more other devices other than the sender device 120 (e.g., a server 110 or other device in communication with the network 105). The files 126 may be encrypted prior to transmission, as further discussed below.

[0059] The sender device 120 may include one or more memories 128, which may include volatile or non-volatile memory (e.g., flash memory, random access memory (RAM), and / or read-only memory (ROM)). The non-transitory memory(s) 128 may store instructions executed by the processor(s) 125, for example, to perform the examples described in this disclosure. The memory(s) 128 may include other software instructions 138, such as software instructions for implementing an operating system and other applications / functionality. In some examples, the memory(s) 128 may include software instructions 138 for execution by the processor device 125 to implement a secure sharing module 140 for securely sharing files 126 with the recipient device 150, as further described below. In some examples, additionally or alternatively, the sender device 120 may execute instructions from external memory (e.g., an external drive in wired or wireless communication with the sender device 120), or executable instructions may be provided by a transient or non-transitory computer-readable medium. Examples of the non-transitory computer-readable medium include RAM, ROM, Erasable Programmable ROM (EPROM), Electrically Erasable Programmable ROM (EEPROM), flash memory, CD-ROM, or other portable memory.

[0060] The sender device 120 also includes a trusted, secure environment, such as a TEE 130 implemented as part of the processor device 125, within which operations can be performed to obfuscate or hide from the operator of the sender device 120. TEE 130 includes the sender device's private TEE key 131, which is inaccessible to the operator or user of the sender device 120 and can only be used by TEE 130. While TEE 130 is shown as an example of a hardware-enabled trusted environment within the sender device 120, the trusted environment can be implemented in other ways. A trusted environment, whether implemented using TEE 130 or otherwise, protects the privacy and security of data and operations executed within the trusted environment. The trusted environment includes security features (typically physical security features) that provide tamper resistance, protecting the integrity of stored data, cryptographic keys, and instructions executed within the trusted environment. The trusted environment provides a secure intermediary environment trusted by the recipient device 150 for dedicated and secure data transfer from the sender device 120. In some examples, the trusted environment can be any secure environment that mediates data transfer from sender device 120 to recipient device 150, and can include a trusted environment provided by hardware external to sender device 120. For example, the trusted environment can be within server 110 or another network entity, etc. For simplicity, this disclosure will refer to TEE 130; however, it should be understood that the trusted environment can be implemented in other ways. For example, the trusted environment can also be implemented using a hardware security module (HSM) or a trusted platform module (TPM), etc.

[0061] It is important to note that although TEE 130 is within sender device 120, because TEE 130 is protected by the operator of sender device 120, even though TEE 130 may be physically implemented within sender device 120, TEE 130 may be described and represented herein as a component separate from the entire sender device 120. In examples where TEE 130 is within sender device 120, signals and data may be communicated between TEE 130 and the entire sender device 120 (i.e., the environment of sender device 120 that is external to TEE 130). Therefore, although in some embodiments, TEE 130 is a physical part of sender device 120, TEE 130 may be considered to receive signals and data from and send electronic signals and data to sender device 120. For example, such communication between sender device 120 and TEE 130 within sender device 120 may involve internal communication between physical chips of sender device 120, among other possible implementations.

[0062] The sender device 120 may also include a bus 142 that provides communication between components of the sender device 120, including those described above. The bus 142 may be any suitable bus architecture including, for example, a memory bus, a peripheral bus, or a video bus.

[0063] Figure 3 1 is a block diagram of a simplified example of a recipient device 150. Other examples suitable for implementing the embodiments described in this disclosure may be used and may include components different from those described below. Figure 3 A single instance of each component is shown, but multiple instances of each component may exist in the recipient device 150 .

[0064] Each receiving device 150 may be any suitable end-user device for wireless operation and may include (or may be referred to as) the following devices: user equipment (UE), wireless transmit / receive unit (WTRU), mobile station, fixed or mobile subscriber unit, cellular phone, station (STA), personal digital assistant (PDA), smartphone, laptop, computer, tablet, wireless sensor, smart device or consumer electronic device, etc.

[0065] like Figure 3 As shown, the receiving device 150 includes at least one processor device 156. The processor device 156 can implement various processing operations of the receiving device 150. For example, the processor device 156 can perform signal encoding, data processing, power control, input / output processing, or any other function that enables the receiving device 150 to operate in the system 100. The processor device 156 can also be configured to implement some or all of the functions and / or embodiments described in more detail herein. For example, the processor device 156 can be a processor, a microprocessor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a dedicated logic circuit, a dedicated artificial intelligence processor unit, or a combination thereof.

[0066] The recipient device 150 may also include one or more optional input / output (I / O) interfaces 162 that may support interfacing with one or more optional input devices 164 and / or optional output devices 166. For example, the input / output device(s) 164, 166 may support interaction with a user. Each input / output device 164, 166 may include any suitable structure for providing information to or receiving information from a user, such as a speaker, microphone, keypad, keyboard, display, or touch screen, among others. In some examples, a single device may provide both input and output capabilities, such as a touch screen.

[0067] The receiving device 150 also includes one or more network interfaces 152 to support communications within the system 100. The communication interface(s) 152 include structures for generating signals for wireless or wired transmission or for processing any suitable signals received via wireless or wired means. The network interface(s) 152 may include wired links (e.g., Ethernet cables) and / or wireless links (e.g., one or more antennas) for intra-network and / or inter-network communications. In some examples, the network interface(s) 152 may include separate transmitter and receiver components; in other examples, the network interface(s) 152 may include a transceiver component that combines the functionality of a transmitter and a receiver.

[0068] The recipient device 150 may also include one or more storage units 154, which may include mass storage units such as solid-state drives, hard drives, magnetic disk drives, and / or optical disk drives. The recipient device 150 may include one or more memories 158, which may include volatile or non-volatile memory (e.g., flash memory, random access memory (RAM), and / or read-only memory (ROM)). The one or more non-transitory memories 158 may store instructions executed by the one or more processor devices 156, for example, to perform the examples described in this disclosure. The one or more memories 158 may include other software instructions, such as software instructions for implementing an operating system and other applications / functionality. In some examples, the one or more memories 158 may include software instructions 168 for execution by the processor device 156 to implement a secure sharing module 170 for securely sharing files 126 with the sender device 120, as further described below. In some embodiments, the secure sharing module 170 may include a trusted viewer 180 for securely viewing (or otherwise making available to a user) the contents of the file 126 shared by the sender device 120 .

[0069] Storage unit 154 may be used in some embodiments to store encrypted data used by secure sharing module 170, including encrypted files 174, encrypted file encryption keys 176, and encrypted private attribute-based encryption (ABE) keys 178, as further described below.

[0070] In some examples, additionally or alternatively, recipient device 150 may execute instructions from an external memory (e.g., an external drive in wired or wireless communication with recipient device 150), or executable instructions may be provided by a transitory or non-transitory computer-readable medium. Examples of non-transitory computer-readable media include RAM, ROM, erasable programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), flash memory, CD-ROM, or other portable memory.

[0071] Recipient device 150 also includes a trusted, secure environment, such as a TEE 160 implemented as part of processor device 156, within which operations can be performed to obfuscate or hide from the operator of recipient device 150. TEE 160 includes a private TEE key 161 from the sender device, which is inaccessible to the operator or user of recipient device 150 and can only be used by TEE 160. While TEE 160 is shown as an example of a hardware-enabled trusted environment within recipient device 150, a trusted environment can be implemented in other ways. Whether implemented using TEE 160 or in other ways, a trusted environment protects the privacy and security of data and operations executed within the trusted environment. The trusted environment has security features (typically physical security features) that provide tamper resistance, protecting the integrity of stored data, cryptographic keys, and instructions executed within the trusted environment. The trusted environment provides a secure intermediate environment trusted by sender device 120 for private and secure data transfer from sender device 120. In some examples, the trusted environment can be any secure environment that mediates the transfer of data from the sender device 120 to the recipient device 150, and can include a trusted environment provided by hardware external to the recipient device 150. For example, the trusted environment can be within the server 110 or another network entity, etc. For simplicity, this disclosure will refer to the TEE 160; however, it should be understood that the trusted environment can be implemented in other ways. For example, the trusted environment can also be implemented using a hardware security module (HSM) or a trusted platform module (TPM), etc.

[0072] It should be noted that although TEE 160 is within recipient device 150, because TEE 160 is protected by the operator of recipient device 150, even though TEE 160 may be physically implemented within recipient device 150, TEE 160 may be described and represented herein as a component separate from the entire recipient device 150. In examples where TEE 160 is located within recipient device 150, signals and data may be communicated between TEE 160 and the entire recipient device 150 (i.e., the environment of recipient device 150 that is external to TEE 160). Therefore, although TEE 160 is a physical part of recipient device 150 in some embodiments, TEE 160 can be considered to receive signals and data from and send electronic signals and data to recipient device 150. For example, such communication between recipient device 150 and TEE 160 within recipient device 150 may involve internal communication between physical chips of recipient device 150, as well as other possible implementations.

[0073] The recipient device 150 may also include a bus 172, including those components described above, that provides communication between components of the recipient device 150. The bus 172 may be any suitable bus architecture including, for example, a memory bus, a peripheral bus, or a video bus.

[0074] Attribute-Based Encryption (ABE)

[0075] The example methods and apparatus described herein may use a modified version of Ciphertext Policy Attribute-Based Encryption ("CP-ABE") described by Bethencourt, J., Sahai, A., and Waters, B., in Ciphertext Policy Attribute-Based Encryption, IEEE Symposium on Security and Privacy, pp. 321-334 (2007), available at https: / / www.cs.utexas.edu / ~bwaters / publications / papers / cp-abe.pdf, which is incorporated herein by reference in its entirety. The CP-ABE variant described in the aforementioned reference is referred to herein as "BSW CP-ABE." Unless otherwise noted, references herein to "ABE" or "attribute-based encryption" should be assumed to refer specifically to BSW CP-ABE or a modified version thereof.

[0076] CP-ABE is a cryptographic scheme for controlling data access. Data access control solutions based on ABE typically exhibit two characteristics. First, they encode data access policies in ciphertext: During the encryption phase, the access policy governing data access and usage is combined with the plaintext to produce ciphertext (i.e., the requested data, which is stored or transmitted in encrypted form). Second, usage conditions are cryptographically enforced: During the decryption phase, the attributes provided by the user requesting access to the data are cryptographically checked, and decryption is successful only if the required usage conditions (i.e., the access policy) are met.

[0077] The entity that controls access to the data (hereinafter referred to as the "sender") can configure an access policy so that only those who meet the policy can decrypt the ciphertext. For example, the policy might look like "Security Level >= 3 and Name = John". The user who requests the data (hereinafter referred to as the receiver) is associated with a set of attributes. For example, a user may have the following attributes: "Name = Sarah", "Age = 35", "Security Level = 2". In CP-ABE, the policy is encoded in ciphertext, and the receiver holds the encryption private key that encodes the receiver's attributes. The receiver can decrypt the ciphertext if and only if the attributes corresponding to the receiver's private key meet the policy encoded as ciphertext during the encryption phase.

[0078] BSW CP-ABE consists of four phases: setup, key generation (also called Keygen), encryption, and decryption.

[0079] The setup phase is performed by the sender. This generates a set of public parameters, a public key (also referred to herein as the "primary public key" or "primary public ABE key"), and a primary secret key (also referred to herein as the "primary secret ABE key"). The public parameters include information relevant to the pairing, as described below. The public key and primary secret key are stored with the sender.

[0080] The key generation phase begins when the sender receives a set of attributes from the receiver. The sender first verifies the attributes: if the attributes provided by the receiver do not match the sender's expectations, the sender can terminate the process. Otherwise, the sender uses the verified attributes and the master secret key to generate a private key corresponding to these attributes (also referred to herein as the "private ABE key") and passes the private key to the receiver.

[0081] The encryption phase is performed by the sender. The sender encrypts the message (i.e., the data being transmitted to the receiver) using the policy and the public key to generate ciphertext. The policy is parsed to generate an "access tree," where leaf nodes contain attribute=value pairs. A calculation is performed on each leaf node's (attribute, value) pair to generate two group elements. The access tree, along with the calculated group elements, constitutes the ciphertext. The (attribute, value) pairs in the leaf nodes are public in BSW CP-ABE. When used to encrypt data during the encryption phase, the public key can be referred to as the "primary ABE key."

[0082] The decryption phase is performed by the receiver. The receiver uses the private key received from the sender to decrypt the ciphertext. Decryption succeeds only if the private key meets the policy. Otherwise, decryption fails.

[0083] Each of the four stages of BSW CP-ABE is now described in more detail.

[0084] The setup phase uses an elliptic curve paired with the mapping e: G1xG2→GT. The pairing parameters are described by A. Kato, M. Scott, T. Kobayashi, and Y. Kawahara in Barreto-Naehrig Curves-draft-kasamatsu-bncurves-02 (2016), which is available at https: / / tools.ietf.org / html / draft-kasamatsu-bncurves-02, which is incorporated herein by reference in its entirety. For a 254-bit BN curve, the pairing parameters can be calculated using Aranha DF, Fuentes- L., Knapp E., Menezes A., Rodríguez-Henriquez F. (2013) Implementing Pairings at the 192-Bit Security Level. In: Abdalla M., Lange T. (eds.) Pairing-Based Cryptography - Pairing 2012. Pairing 2012, Lecture Notes in Computer Science, Vol. 7708, Springer Berlin Heidelberg, the entire text of which is incorporated herein by reference.

[0085] Setting stage generates public key = (g, h, H = h β , e(,g,h)^α) and the main secret key = (β,g α ). G1 is the BN elliptic curve E(F p ). G2 is a subgroup of order q of E(F p )'s six-point distortion GT is a subgroup of order q. p^{12} q-order subgroup of G1. g is the generator of G1, h is the generator of G2. α, β∈ R {0, ..., q-1}.

[0086] The key generation phase begins by specifying user attributes. Integer attributes must additionally specify the maximum number of digits used to represent their value. For example, "Trust Level = 4" is followed by a "#" symbol, and the maximum number of digits used to represent the trust level is selected, such as 3 (allowing trust level values ​​from 0 to 7). In this example, the attribute set might include: "Name = Teng", "Role = Manager", and "Trust Level = 4#3".

[0087] The key generation phase then continues by parsing the attributes. String attributes remain intact, but integer attributes are converted to their bitwise representations. For example, "trust level = 4#3" is converted to "trust level 3_0 = 0," "trust level 3_1 = 0," and "trust level 3_2 = 1," representing the 0th, 1st, and 2nd bit positions, respectively. The corresponding parsed attribute set for the above example is: "name = Teng," "role = manager," "trust level 3_0 = 0," "trust level 3_1 = 0," and "trust level 3_2 = 1."

[0088] After parsing the attributes, the key generation phase will proceed to generate the key. The private ABE key is generated by a trusted third party (such as a key management system or trusted execution environment) that holds the master secret ABE key. The private ABE key is generated according to the following specifications: D y =g r .Hash(y) ry and where r∈ R {0, .., q-1}, y is the attribute string, and Hash is the cryptographic hash mapped to G1.

[0089] The generation of private ABE keys can be achieved using the Fouque-Tibouchi method described by S. Scott, N. Sullivan, and C. Wood in Hashing to Elliptic Curves-draft-irtf-cfrg-hash-to-curve-03 (2019), which can be accessed at https: / / tools.ietf.org / html / draft-irtf-cfrg-hash-to-curve-03#section-5.3.5, the content of which is incorporated herein by reference in its entirety. This method is applicable to the above elliptic curves.

[0090] An example set of private ABE keys corresponding to the example properties above is:

[0091] D {Name＝Teng} =g r .Hash(Name=Teng) r-{Name＝Teng} ,

[0092] D {Role＝Manager} =g r .Hash(Role=Manager) r-{Role＝Manager} ,

[0093] D (Trust_level3_0＝0} =g r .Hash(TrustLevel3-0=0) r_{Trust_level3_0＝0} ,

[0094] D {Trust_level3_1＝0) =g r .Hash(TrustLevel3_1=0) r_{Trust_level3_1＝0} ,as well as

[0095] D {Trust_level3_2＝1} =g r .Hash(TrustLevel3_2=1) r-{Trust_level3_2＝1} .

[0096] The encryption phase begins with specifying an access policy. An example policy is: "(role=Manager and trust level>=4) or name=Yin".

[0097] Integer attributes like trust level can be used with comparison operators like <, >, <=, >=, and =, which are made simpler by converting to their bitwise representation. Policy conditions use AND, OR, or k-out-of-n combinations (e.g., AND is 2-out-of-2, or OR is 1-out-of-2).

[0098] The encryption phase then continues with parsing the access policy. The policy is converted into an access tree. Integer attributes are further decomposed into their bit representation and represented in the access tree. As mentioned above, this is necessary to represent inequality. All attributes are at the leaves of the tree, and they have equality. Each node has a unique index.

[0099] Then, the encryption phase continues with encryption. The encryption process is as follows:

[0100] Let M be the message to be encrypted. This must be a group element of GT.

[0101] Generate a secret key "s" for the root node, a number randomly selected from 0...q-1.

[0102] Use Shamir key sharing (as described in Adi Shamir, "How to share a secret," Commun. ACM 22, 11 (November 1979), pp. 612-613, DOI: https: / / doi.org / 10.1145 / 359168.359176, the entire contents of which are incorporated herein by reference) to generate a secret key for this node using its children's unique indices. This operation is performed recursively for all nodes in the visited tree. Let s_y denote the secret key for node y.

[0103] The ciphertext consists of the following: Visit the tree, for each attribute string y in each leaf node, the ciphertext Where C^=Me(g,h) as and

[0104] The decryption phase begins at the receiver. Decryption is only possible if the attributes in the private ABE key satisfy the policy (i.e., the access tree). If this is not the case, then it is computationally difficult to obtain the original encrypted message, i.e., the encryption itself must be broken.

[0105] A node of the access tree is satisfied if the attribute string it includes has a matching resolved attribute string in the private key. In the example above, the node containing "trust level 3_2 = 1" has a matching private key attribute and is therefore satisfied.

[0106] Due to the shared Shamir key used during encryption, for each parent node in the tree, a certain threshold number of child nodes needs to be met in order to satisfy the parent node. Decryption can only be successful if the root node is satisfied.

[0107] Decryption starts from the leaf node of the tree. If the leaf node is satisfied, the following operations are performed:

[0108] node-value=e(D Trust_levei3_1 =1, C Trust_leve13_1 =1) / e(C′ Trust_1eve13_1＝1 , D′ Trust_leve13_1＝1 ),

[0109] First, the node value is raised to an exponential (roughly, this is the product of the Lagrange coefficients of all nodes in the path from the leaf node to the root node). Then, the results of all satisfied nodes are multiplied together: this product is designated as A.

[0110] Next, calculate the quotient: e(C, D) / A. This quotient is equal to the C of the ciphertext. ～ =e(g,h) α.s "Shielding factor" e(g,h) in .M a.s Removing this masking factor yields the original message M.

[0111] Modified BSW CP-ABE

[0112] As mentioned above, the example embodiments described herein may use a modified version of the BSWCP-ABE technique described in the previous section.

[0113] A first modification to BSW CP-ABE, used in some embodiments, combines the asymmetric BSW CP-ABE encryption scheme with a second symmetric encryption scheme, such as the Advanced Encryption Scheme (AES). Using a symmetric encryption scheme can facilitate encryption of plaintext, such as files. To combine AES with BSW CP-ABE, a random group element M of G1 is selected and an AES symmetric key is obtained through a key derivation function (KDF). This key is used to encrypt the file to generate symmetric ciphertext. Next, the group element M is encrypted using CP-ABE (i.e., in the aforementioned ABE technique, group element M is considered to be message M) to generate asymmetric ciphertext. The asymmetric ciphertext and the symmetric ciphertext together constitute the encrypted form of the file (also referred to herein as the "encrypted file"). To decrypt, the asymmetric ciphertext is first decrypted to obtain M. The AES symmetric key used to encrypt the file is obtained by passing M through the KDF. The symmetric ciphertext can then be decrypted to generate the plaintext (i.e., unencrypted) file.

[0114] A second modification to BSW CP-ABE used in some embodiments requires that, in addition to satisfying the attributes of the access policy, the recipient also provide a password in order to decrypt the file contents. This modification to BSW CP-ABE operates very similarly to the BSW CP-ABE described above, and is modified as follows.

[0115] The setup phase, encryption phase, and decryption phase all proceed as in BSW CP-ABE. However, the key generation phase is divided into two operations: a sender-side operation and a receiver-side operation. In the first key generation operation, on the sender side, the password is selected by the sender (possibly based on another source, such as information provided by the receiver). It should be noted that, as described above, generating a private ABE key in BSW CP-ABE requires, for each (attribute, value) provided by the user, computing two group elements D and D′: D = g r H(attribute, value) r attribute , and D′=g r attribute .

[0116] In BSW CP-ABE using cryptographic modification, these group elements are calculated as follows: D = g r H(attribute, value) r attribute-G(password.(attribute，value)) , and D′=g r attribute Typically, the password is known only to the sender and the receiver. The private ABE key(s) generated at the sender are then sent to the receiver.

[0117] Then, the second key generation operation is performed on the receiver side. In order to make the private ABE key available for decryption, the receiver must combine D with H(attribute, value) G(password_v(attribute_v，value_v)) Multiply by , to generate a modified version of the private ABE key, where G is a hash function that maps to the group size, i.e., any number between 0 and (group size - 1). password_v (i.e., the password string) is input by the recipient, and (attribute_v, alue_v) is obtained from an attribute source of the recipient, such as the settings of a trusted file content viewer software application.

[0118] If (attribute_v, value_v)!=(attribute, value), or if password_v!=password, then the confidence level G(attribute_v, value_v)!=G(attribute, value), and the modified private key calculated on the receiving side, will be incorrect. Therefore, if the password is incorrect, decryption will fail. In some embodiments described herein, the second key generation operation (i.e., generating a modified version of the private ABE key by applying the attributes and the password hash) and the execution of the decryption phase of CP-ABE can be collectively referred to as "decrypting" the ciphertext using the private ABE key, the attributes, and the password.

[0119] The example embodiments described herein may use one or both of the above modified BSWCP-ABE versions. Further details of the ABE scheme used in specific embodiments or examples are further discussed below in conjunction with specific embodiments and examples.

[0120] Granular access policy enforcement using ABE

[0121] CP-ABE (such as the modified BSWCP-ABE variant described above) may exhibit many advantages when used for access control. Access control is cryptographically enforced rather than using programming logic such as if statements. A malicious user cannot combine their corresponding private keys to decrypt ciphertext encrypted using a policy that requires a combination of permissions or attributes. Furthermore, each user is assigned a private key based on the user's attributes: since the policy is embedded in the ciphertext, there is no need to publish different private ABE keys to allow decryption of different policies. Instead, a user only needs a new private ABE key when their attributes change.

[0122] Figure 4A is a system diagram illustrating an example of access policy enforcement operations 400 using a conventional software-based policy engine 404. The access policy enforcement operations 400 may be implemented on a computer or electronic device, or on multiple devices in communication with each other.

[0123] An access request is received by a policy enforcement point (e.g., an operating system's file system) 402. For example, an access request may be generated when a user attempts to access the contents of a file stored in the file system using the user interface of a file browser software application. Policy enforcement point 402 provides the access request, including any necessary metadata associated with the access request, to policy engine 404. The access request indicates details of the user account, a device identifier, and the type of access to the requested file (which may be referred to herein as an "access action"), e.g., whether the access request is a request to view, copy, modify, delete, or print the file or file contents. Some or all of the metadata associated with the access request may be obtained by policy engine 404 from one or more attribute sources 406 (e.g., a repository of user account details or settings of the software application that generated the access request). Typically, attribute sources 406 of policy engine 404 are referred to as policy information points (PIPs). The metadata associated with the access request can be considered equivalent to "attributes," as that term is used in attribute-based encryption: for example, details of a user account may include attributes such as the user's name, security level, and role.

[0124] The policy engine 404 can be a software module configured to execute file access policies stored in the policy repository 408. For example, the access policies can be defined by a system administrator or an operating system. The policy repository 408 can be part of the storage device or memory of the device. Typically, the policy repository 408 and the attribute source 406 will be stored in a secure format or a secure part of the storage device or memory to prevent malicious changes. The access policy can define the attribute or metadata value or range required for the access request to return a positive response, that is, access to the requested file content can be obtained. Thus, an example access policy can only authorize access to a given file by user accounts with a security level higher than 3 and an administrator role, which is derived from a device ID that matches the local device where the file is stored. The policy can also limit the access operations of such requests to "view", "copy" and "print" operations.

[0125] If the attributes or other metadata satisfy the policy, for example, in the example above, if the access request provides attribute values ​​of (user account security level = "5", user account role = "Administrator", device ID = [local device ID], user account name = "Alice", access action = "Print"), then access block 410 provides the file content for printing 412. On the other hand, an access request with attributes that do not satisfy the access policy, for example, an access request providing attribute values ​​of (user account security level = "6", user account role = "Administrator", device ID = [local device ID], user account name = "Bob", access action = "Modify"), will be denied by deny block 414, and the operating system may return an error message to the user or application that initiated the access request, indicating that the user account does not have permission to perform the requested access action on the requested file.

[0126] Figure 4A The example access policy execution operation 400 presents multiple potential attack surfaces for malicious unauthorized access attempts. The attribute source 406 may be attacked to modify or replace the attribute values ​​provided to the policy engine 404. The policy repository 408 may be attacked to modify or replace the access policy. The policy engine 404 can be attacked by software vulnerabilities that attempt to subvert the logical operation of the software that implements the policy engine, causing the policy to not be executed or to return a positive (i.e., "access granted") result for an incompatible access request. The file content 412 can also be intercepted or misused when it is provided to the requesting user or application, or the file content 412 can be accessed without authorization if the file content is ever stored or communicated in an unencrypted form.

[0127] The example methods and apparatus described herein can minimize the attack surface available for malicious unauthorized access attempts while providing granular access control for peer-to-peer shared file content. By using a modified form of BSW CP-ABE (BSW CP-ABE is described in detail above, with modifications described below), the described embodiments can limit unauthorized access attempts to attacks that break encryption.

[0128] Figure 4B is a system diagram illustrating an example of ABE access policy enforcement operations 450 using an ABE (e.g., BSW CP-ABE or a modified version thereof, as described below). The ABE access policy enforcement operations 450 may be implemented on a computer or electronic device, or on multiple devices in communication with each other, as further described below in conjunction with example embodiments and example contexts in which the described embodiments may be used.

[0129] and Figure 4AAs with the access policy enforcement operation 400 of FIGURE 4, the access request is received by the policy enforcement point 402. In the ABE access policy enforcement operation 450, the policy enforcement point 402 provides the access request to the ABE decryption block 454. Figure 4A As with the access policy execution operation 400, attribute source 406 is used to provide attributes associated with the access request. ABE Key Management System (KMS) 452 provides the private ABE key(s) used by ABE decryption block 454 in ABE decryption. The file content itself is stored as ABE encrypted file content 456, which effectively encodes the access policy described above in the attribute-based encryption section.

[0130] ABE decryption block 454 receives at least one private ABE key from ABE key management system (KMS) 452 and generates a modified version of the received private ABE key using attribute values ​​provided by attribute source 406. The modified private ABE key is used by ABE decryption block 454 to decrypt ABE encrypted file content 456.

[0131] If decryption is successful, then the access block 410 provides the file content 412 to the requesting user or application for the requested access action. If decryption fails, then the deny block 414 may be used to return an error indicating lack of authorization.

[0132] In the example embodiments described herein, the vulnerability of the attribute source 406 and the content 412 can be minimized by using a trusted viewer application (e.g., a cryptographically signed binary executable file) to directly receive and process the decrypted file content 412 from the ABE decryption block 454 and to act as the attribute source 406 by providing trusted values ​​for attributes associated with access actions enabled by the trusted viewer. Furthermore, the file contents 412 are protected from attack prior to the ABE decryption operation because they are stored in ABE-encrypted form as ABE-encrypted file content 456.

[0133] Figure 4A The vulnerability of the policy engine 404 of method 400 does not exist in the ABE access policy enforcement operation 450 because there is no software logic that can be exploited or subverted - the policy is cryptographically enforced, requiring an attacker to subvert the encryption scheme itself to gain access to the ABE encrypted file content 456.

[0134] Peer-to-peer secure granular access control using modified BSW CP-ABE

[0135] In peer-to-peer (P2P) scenarios, CP-ABE may offer advantages over symmetric key-based solutions for several reasons. First, for recipient attributes that change over time (e.g., the number of times a recipient's device attempts to open an encrypted file), each time the attribute changes, a new symmetric key and a new ciphertext encrypted with that key need to be published to the recipient. In contrast, CP-ABE only requires the republication of the private key; the ciphertext (i.e., the encrypted file) remains unchanged, and no additional encryption steps are required. Furthermore, in CP-ABE, in some cases, the new private key to be published can be derived from the old private key, simplifying key management.

[0136] Consider the following problematic scenario. In this example, the sender verifies the recipient's attributes before generating and sending a private key, and at least some of the recipient's attributes are provided by the viewer app on the recipient's device. However, an attacker could obtain the private key corresponding to the policy (attribute, value) pair "Screenshot" = "Not Allowed") and then maliciously change the viewer app settings to enable screenshots. In this scenario, the recipient could successfully decrypt files whose policy disallows screenshots, but still be able to take screenshots.

[0137] One way to enforce such properties is to perform a check in the software before decrypting the ciphertext to confirm that the viewer settings satisfy the access policy. However, even if the viewer application is a trusted viewer application with unbreakable logic, such checks may be skipped.

[0138] Another solution is to verify the message authentication code (MAC) or cryptographic signature of the viewer application, but this may require additional keys and / or computation.

[0139] A third solution used in some embodiments described herein is to use the modified CP-ABE scheme described above, which uses ABE itself to enforce viewer application settings (e.g., "cannot take screenshots of file contents" or "cannot save file contents"). This ensures that decryption will fail if the viewer application has incorrect settings. This can be more secure than using programmatic logic such as if statements or using a MAC or other hardware identifier to check whether the viewer application settings match those specified in the ciphertext-encoded access policy.

[0140] A detailed description will now be given of a peer-to-peer example based on ABE, as well as similar embodiments adapted to enable and extend certain features using a network server or cloud computing platform (e.g., server 110). Sharing groups may also be employed using similar configurations, as described below with reference to other examples. The described embodiments may provide an extensible platform that supports many different use cases.

[0141] Now combine Figure 5 、 Figure 6 and Figure 7 Example embodiments are described. Figure 5 A system diagram of an example system 500 for secure data sharing using a sender device 120 and a recipient device 150 is shown. Figure 6 It is shown by Figure 5 Flowchart of steps of an example method for secure data sharing implemented by system 500. Figure 7 It shows Figure 6 A flowchart of example sub-steps of a setup step of an example method.

[0142] As described above, system 500 uses AES as the symmetric encryption scheme, combined with ABE, and further uses a password to protect file content, implementing a modified BSW CP-ABE. It should be understood that some embodiments may omit or modify one or both of these modifications, or may use a different ABE variant besides BSW CP-ABE, while still achieving the other described features of system 500.

[0143] As mentioned above Figure 2 and Figure 3 As described above, both the sender device 120 and the receiver device 150 include trusted execution environments: a sender TEE 130 and a receiver TEE 160, respectively. The sender TEE 130 is used to protect the primary sender ABE private key 530 from sender-side attacks that attempt to subvert the secure sharing operations of the system 500. This is achieved by storing the primary sender private ABE key 530 in the sender storage 124 as an encrypted primary sender private ABE key 550, which can only be decrypted by the sender TEE 130 using a private TEE key 131 securely stored in the sender TEE 130. During the first sender-side operation of the key generation phase, the sender TEE performs a TEE decryption operation 552 using the private TEE key 131 to provide the decrypted primary sender ABE private key 530 to the sender secure sharing module 140. The receiver TEE 160, in some embodiments, performs a number of operations, as described in further detail below.

[0144] The sender device 120 and the receiver device 150 include a sender security sharing module 140 and a receiver security sharing module 170, respectively, as described above with reference to Figure 2 and Figure 3 In some embodiments, these modules 140, 170 are trusted software applications that are cryptographically signed by a trusted authority.

[0145] Figure 6The method 600 shown in the flowchart of FIG. 5 sets forth the steps for executing a method for peer-to-peer secure sharing of files (or other data objects) using a secure sharing system such as system 500. At 602, the setup phase of the modified BSW CP-ABE is performed, as described above. In some embodiments, the setup step 602 may include one or more additional operations, such as Figure 7 As shown in the flowchart of FIG. 6 , further sub-steps of setting step 602 are provided.

[0146] refer to Figure 7 , in 702, the sender device 120 specifies an access policy 528 for the file 126. The sender device 120 may also optionally define a password 563, as described above.

[0147] An access policy includes one or more attribute configurations, each of which includes a plurality of attribute values ​​that authorize access to the contents of file 126. An example access policy may include attributes or configurations indicating the following: a maximum number of times a file may be opened; a user account of the user making the access request; a device identifier of the device making the access request; other attributes related to the entity making the access request; whether screenshots are allowed; whether viewing the file is allowed; whether saving the file is allowed; whether copying the file or its contents is allowed; whether forwarding the file is allowed; whether printing the contents of the file is allowed; other attributes related to the nature of the access operation requested; an identifier of the specific data for which access is requested, data contained within the file; and any other attributes as will be understood. Access policy 528 may also optionally include an expiration date for the recipient device 150's permission to access the file. Finally, as discussed in more detail below, access policy 528 may also, in some embodiments, enable certain active accesses.

[0148] In 704 , the sender device 120 sends a setup request to the recipient device 150 . The setup request includes the access policy 528 defined in step 702 .

[0149] In response to receiving the setup request, at 706, the recipient device 150 generates a key attestation report 558. The recipient device 150 uses the recipient TEE 160 to generate a public recipient TEE key 554 and a private recipient TEE key 161. The private recipient TEE key 161 is stored in the recipient TEE 160 for use during the decryption phase. The key attestation report 558 includes a copy of the public recipient TEE key 554. If the access policy 528 includes an expiration date, the key attestation report 558 may also include a confirmation of the expiration date. In some embodiments, the key attestation report 558 may include other information, such as a device identifier of the recipient device 150, to allow the sender device 120 to confirm that the recipient device 150 is compliant or authorized. The recipient device 150 may also record the details of the access policy 528. For example, if the access policy 528 includes an expiration date 556, the expiration date 556 is recorded within the recipient TEE 160 to facilitate future enforcement of the expiration date 556, as described below.

[0150] In 708 , the recipient device 150 sends the key certification report 558 to the sender device 120 .

[0151] At 710, the sender device 120 confirms that the recipient device 150 is compliant or authorized. In some embodiments, this can be achieved by confirming that the device identifier of the recipient device 150 matches a list of devices authorized (e.g., cryptographically signed) by the trusted viewer application 180 and / or the recipient secure sharing module 170. In this step 710, the sender device 120 can also use the device identifier to identify the capabilities of the recipient device 150 that are not capable of complying with various aspects of the secure sharing scheme. For example, in some embodiments, the sender device 120 may be able to use the device identifier to identify that the recipient device 150 is a device that does not enable text input (e.g., an IoT device), and therefore a password cannot be used to protect files sent to the recipient device 150. In some such embodiments, the sender can specify an access policy in which a non-text input such as a device identifier or a scanned QR code can be used in place of a password. It should be understood that other capabilities or limitations of the recipient device 150 can be identified by the server device 120 based on the device identifier provided as part of the key attestation report 558.

[0152] return Figure 6 , the sender device 120 then enters the encryption phase. In 604, the sender device 120 encrypts the file 126 using the file encryption key 524, which in some embodiments may be an AES key or other symmetric key, such as Figure 5 Shown is a file encryption operation 532. This operation 532 generates an encrypted file 174.

[0153] At 606, the sender device 120 encrypts the file encryption key 524. The access policy 528 and the primary sender ABE public key 526 (i.e., the primary public ABE key used by the sender) are used by the ABE encryption operation 534 to perform the encryption phase of the modified BSW CP-ABE as described above, thereby generating the encrypted file encryption key 544. As described above, the primary sender ABE public key 526 is stored or generated locally on the sender device 120 based on the access policy 528. In embodiments using a password 563, the password may be included in the access policy 528 and thus encoded into the ABE ciphertext (i.e., the encrypted file encryption key 544).

[0154] At 608, the sender device 120 generates a private ABE key 546. The ABE KeyGen operation 536 uses the primary sender ABE private key 530 (i.e., the primary private ABE key used by the sender, as decrypted by the sender TEE 130, as described above) to generate the private ABE key 546. As described above, the private ABE key 546 is generated based on the policy attribute values ​​and / or the password 563. In some embodiments, the set of private ABE keys 546 may include multiple private ABE keys, each corresponding to an attribute configuration (i.e., a set of attribute values ​​that satisfies the access policy 528).

[0155] In 609 , the sender device 120 encrypts the set of ABE keys 546 using the public recipient TEE key 554 received as part of the key attestation report 558 , generating a set of encrypted private ABE keys 548 .

[0156] It should be understood that in other embodiments, steps 604 , 606 , 608 , and 609 may be performed in a different order.

[0157] In 610, the sender device 120 sends the encrypted file 174, the encrypted file encryption key 544, and the encrypted private ABE key 548 to the recipient device 150. The received encrypted file 174, the encrypted file encryption key 544, and the encrypted private ABE key 548 may be stored by the recipient device 150 upon receipt, for example, in the recipient's local storage 154.

[0158] In 612, if the access policy 528 includes an expiration date 556 for the receiver to access the file 126, the TEE decryption operation 560 of the receiving TEE 160 determines whether the expiration date has been reached. The receiving TEE 160 compares the current time and date with the expiration date 556 included in the access policy 528 based on the trusted clock 557.

[0159] At 614, if the expiration date 556 has not yet arrived or if the access policy 528 does not define an expiration date 556, the TEE decryption operation 560 of the recipient TEE 160 applies the private recipient TEE key 161 to decrypt the set of encrypted private ABE keys 548, thereby generating a set of decrypted raw private ABE keys 546. At least one of these private ABE keys 546 is provided directly by the recipient TEE 160 to the recipient secure shared module 170.

[0160] In some examples, access policy 528 may include an attribute indicating the number of times file 126 has been opened at recipient device 150. In some embodiments, recipient TEE 160 may be configured to track the number of times file 126 has been opened by recipient device 150 and provide a private ABE key to recipient device 150 only if the current number of open attempts satisfies access policy 528. Receiving TEE 160 may use a counter to track the number of times recipient device 150 has requested access to file 126. Each time recipient device 150 requests access to file 126, the current counter value N is compared to the corresponding attribute value specified in access policy 528. If the counter value N matches the allowed attribute value for the number of file access requests, the corresponding individual private key of the set of private ABE keys 546 is provided to recipient secure sharing module 170. Thus, in the first example embodiment, each private ABE key corresponds to a set of attribute values ​​that satisfy the access policy, and the attribute indicating the number of times a file can be opened has three possible values: "at most 5 times," "at most 10 times," and "at most 20 times." The value of the attribute "open attempts" can be an integer index into a corresponding range table, e.g., 0 = "at most 5 times," 1 = "at most 10 times," and 2 = "at most 20 times." (It will be understood that other implementations are possible, including string values ​​for the attribute, or integer values ​​indicating the exact number of open attempts allowed.) In an example use case using this embodiment, the recipient device 150 receives an access policy 528 that allows up to 10 file open attempts. Thus, the set of private ABE keys 546 will include a first key corresponding to "at most 5 times" (e.g., the integer index attribute value for "open attempts" must be less than 1, i.e., each bit must be 0) and a second key corresponding to "at most 10 times" (e.g., the integer index attribute value for "open attempts" must be less than 2, i.e., the second bit must be 0). Whenever the recipient TEE 160 receives a request from the recipient device 150 to open a file, it checks the current counter value N against the access policy 528 and, if a corresponding private ABE key exists, provides that individual key to the recipient security shared module 170. The counter is then incremented (N = N + 1). Therefore, on the third file open attempt, the counter value (N=3) is checked, the access policy 528 is checked (3<=5→"at most 5 times"), and the first private ABE key ("Open Attempts" bit 1=0, "Open Attempts" bit 2=0) is provided to the recipient security shared module 170 along with the corresponding attribute value ("Open Attempts" bit 1=0, "Open Attempts" bit 2=0). Alternatively, the scheme can rely entirely on the recipient TEE 160 to enforce the "Open Attempts" attribute, and the attribute can be completely omitted from the ABE encryption.

[0161] In other embodiments, the selection between multiple keys corresponding to changing the recipient's attributes can be performed outside the recipient TEE 160, such as in the logic of the recipient security shared module 170 or elsewhere. However, performing this check within the recipient TEE 160 can improve security.

[0162] In 616, the recipient device 150 uses the attribute values ​​and / or password 563 to generate modified private key(s) based on the received decrypted private ABE key(s) 546. This step 616 constitutes the first step of ABE decryption and is equivalent to the second recipient-side operation of the key generation phase of the modified BSW CP-ABE described above. The attribute values ​​are received from one or more attribute sources, such as a set of viewer attributes 561 provided by the trusted viewer application 180. For example, other attribute sources may include the operating system of the recipient device 150, which provides user attributes for the user account requesting access to the file 126. The password 563 may be entered by the user, such as via the input device 164, or it may be provided by another source (e.g., a software application such as a password manager). The ABE decryption operation 562 applies the (attribute, value) pairs and the password (if any) to generate the modified private key(s) as described above: that is, for each D and the corresponding H(attribute, value) G(password_v，(attribute_v，value_v)) Multiplied to generate modified private key(s).

[0163] At 618, recipient device 150 decrypts encrypted file encryption key 544 using the modified private key(s). This step 618 constitutes the second step of ABE decryption, equivalent to the decryption phase of the modified BSW CP-ABE described above. ABE decryption operation 562 decrypts encrypted file encryption key 544 using one of the modified private keys, thereby generating decrypted file encryption key 524.

[0164] In different embodiments, identification of the correct private ABE key can be performed in different ways. In some embodiments, the ABE decryption operation 562 receives multiple private ABE keys in step 616, generates multiple corresponding modified private keys, and attempts to decrypt the encrypted file encryption key 544 using each modified private key in turn until one succeeds. Other embodiments may include a mechanism for identifying the correct private ABE key without trial and error. Some embodiments may use the stored access policy 528 as a reference to identify the correct private ABE key within the recipient TEE 160; the recipient TEE 160 then provides only the correctly identified private ABE key to the recipient secure sharing module 170. Other embodiments may perform identification within the recipient secure sharing module 170. In some embodiments, the sender device 120 may provide metadata identifying the different private ABE keys; for example, this metadata may be appended to the encrypted private ABE key 548 when it is sent to the recipient device 150. The metadata may be digitally signed or integrity protected.

[0165] At 620, the recipient device 150 decrypts the encrypted file 174 using the decrypted file encryption key 524. As described above, the file encryption key 524 may be a symmetric key, such as an AES key, and the file decryption operation 564 may perform conventional AES decryption to recover the plaintext file 126 from the encrypted file 174 by applying the file encryption key 524.

[0166] At 622, the contents of the decrypted file 126 are provided to the trusted viewer application 180. The trusted viewer 180 can then perform the authorized access action(s) using the trusted viewer settings provided as viewer properties 561. For example, the file 126 may be available for the user to view, print, screenshot, copy, or save, as indicated by the access policy 528 and the trusted viewer settings.

[0167] At 624, once the access is complete (e.g., after the user closes the viewer or performs an access action, such as printing the file contents), the file delete operation 566 of the trusted viewer 180 can delete the received plaintext file 126 and all of its contents stored in memory. In some embodiments, all copies of the plaintext file 126 and / or its contents, as well as any decryption keys decrypted during the above-described access operation, are deleted once they are used. Thus, after the file encryption key 524 is used to decrypt the encrypted file 174, the receiving secure sharing module 170 can immediately delete the file encryption key 524.

[0168] It should be understood that each of the operations shown in the sender security sharing module 140 and the receiver security sharing module 170 can be implemented by executable instructions stored in the memory of the corresponding device. Therefore, the sender instructions 138 may include instructions for implementing the file encryption operation 532, the ABE encryption operation 534, the ABE KeyGen operation 536, and the like. Figure 5 , and these instructions may be part of the instructions for implementing the sender security sharing module 140. Similarly, the receiver instructions 168 may include instructions for implementing the file decryption operation 564, the ABE decryption operation 562, and Figure 5 The instructions for other receiver-side operations shown in , and these instructions may be part of the instructions for implementing the receiver security sharing module 170 .

[0169] Cloud Server for Active Access Policy Options

[0170] In some embodiments, the peer-to-peer secure sharing system 500 may include active access options in its access policy settings. These active access options are access policy settings that require the recipient device 150 to contact the sender device 120 upon an access action. Some embodiments may allow the access policy 528 to be configured to require the recipient device 150 to notify the sender device 120 upon an access action, granting access only after the notification has been successfully delivered. The access policy 528 may also specify that certain access operations require notification while others do not. For example, the access policy may require notification whenever a file is opened, or only when a screenshot is taken. Some embodiments may allow the access policy 528 to be configured to allow the sender device 120 to revoke the access policy 528 and / or replace it with a new access policy that replaces the previous access policy. Each of these active access options can be implemented using a peer-to-peer configuration such as the system 500; however, this may limit file access on the recipient device 150 side to times when the sender device 120 is reachable to receive notification, or it may allow an attacker to circumvent the access policy revocation feature by disabling communication on the recipient device 150 side.

[0171] Thus, some embodiments may use a server, such as server 110 (which may be a network or cloud server or platform), to enable an always-on active access feature of access policy 528. This server or platform may be referred to as a "dynamic policy server," and an access policy with one or more active access options enabled may be referred to as a "dynamic policy." Server 110 may be configured to receive notifications on behalf of sender device 120 and relay notifications to sender device 120 when they become available. Server 110 may also relay access policy revocation messages from sender device 120 to recipient device 150 when the recipient device becomes available.

[0172] Figure 12 An example method 1200 for sending a notification required by an access policy is shown. At 1202, the recipient device 150 determines that a notification condition has been met. The notification condition can be included in the access policy 528, associating the notification condition with one or more access actions (e.g., open, print, screenshot). In response to determining that the notification condition has been met, the recipient device 150 attempts to send a notification to the sender device 120, identifying the access action being attempted or requested.

[0173] If the sender can receive notifications, method 1200 proceeds to 1204 : the recipient device 150 sends the notification directly to the sender device 120 .

[0174] If the sender is unable to receive the notification, the method 1200 instead proceeds to 1205 where the recipient device 150 determines that the sender device 120 is unable to receive the notification. In this case, the method 1200 proceeds to step 1207 where the recipient device 150 sends the notification to the server 110 instead.

[0175] Once the notification is successfully sent at step 1204 or 1207, method 1200 proceeds to step 1206, where the recipient device determines that the notification has been successfully sent. In some embodiments, sender device 120 and / or server 110 can confirm receipt of the notification by sending an acknowledgment to recipient device 150.

[0176] In response to determining that the notification has been successfully sent, the recipient device enables the access action at 1208. In some embodiments, this may mean that the recipient TEE 160 simply provides the private ABE key(s) 546 to the recipient secure shared module 170 at step 1208. In other embodiments, the notification method 1200 is implemented entirely within the logic of the recipient secure shared module 170, or by a separate module.

[0177] Some embodiments may always use the server 110 to mediate the sending and confirmation of notifications of the notification method 1200, regardless of whether the sending device 120 is reachable.

[0178] Figure 13A An example sender-side method 1300 for revoking an access policy is shown. At 1302, the sender device 120 generates an access policy revocation message. The access policy revocation message is intended to revoke authorization for the recipient device 150 to access the file 126 under the access policy 528. In some embodiments or use cases, the access policy revocation message can be accompanied by a new access policy 528 that sets a different set of permissions.

[0179] If the recipient device 150 can receive the access policy revocation message, the method 1300 proceeds to step 1304 ; otherwise, proceeds to step 1305 .

[0180] In 1304 , the sender device 120 sends an access policy revocation message to the recipient device 150 .

[0181] At 1306, the recipient device revokes the access policy 528. In some embodiments, this may mean that the recipient device 150 deletes one or more of the encrypted file 174, the encrypted file encryption key 544, and / or the encrypted private ABE key 548. Some embodiments may implement revocation of the access policy within the recipient TEE 160, for example, by configuring the recipient TEE 160 to refuse to decrypt the ABE access private key 548 of the revoked access policy 528. Some embodiments may implement the revocation feature by updating the expiration date 556 stored in the recipient TEE 160 so that the access policy 528 expires at some time in the past (i.e., immediately) or in the future.

[0182] In 1305 , the sender device determines that the recipient device 150 is unable to receive the access policy revocation message, for example because the recipient device 150 is unreachable over the network 105 .

[0183] In response to determining that the recipient device 150 is unavailable, the sender device 120 sends an access policy revocation message to the server 110 in 1307. The completion of the access policy revocation is then performed on the recipient side by method 1350, as shown in FIG. Figure 13B shown and described below.

[0184] Figure 13B An example recipient-side method 1350 for revoking an access policy is shown. At 1352, a recipient device 150 receives an access request to access the contents of a file 126, such as from a user account or a software application. The recipient device 150 checks the locally stored access policy 528 to determine whether it has been revoked (e.g., via step 1306 of method 1300). If the policy has been revoked and is therefore no longer valid, the method 1350 proceeds to step 1354. If the policy is still valid, the method 1350 continues to check whether the sender device 120 is available (e.g., reachable via network 105). If the sender is not available, the method 1350 proceeds to step 1356. If the sender is available, the method 1350 proceeds to step 1358.

[0185] In 1354, in response to determining that the local access policy 528 is invalid, the recipient device 150 denies the access request. In some embodiments, this may prompt the recipient device 150 to initiate a new setup request to the sender device 120, as described above in conjunction with Figure 6 As described in method 600.

[0186] In 1356, in response to a determination that the sender device 120 is unavailable, the recipient device 150 contacts the server 110 to confirm the status of the access policy 528. In 1358, in response to a determination that the sender device 120 is available, the recipient device 150 contacts the sender device 120 to confirm the status of the access policy 528. Contacting the sender device 120 or the server 110 may include a policy confirmation request sent by the recipient device 150 and a policy confirmation returned to the recipient device indicating the validity or invalidity of the access policy.

[0187] If confirmation of the status of the access policy 528 results in a determination that the access policy 528 is still in effect (ie, has not been revoked), then the method 1350 proceeds to step 1360 : the access request proceeds normally (eg, according to the method 600 ).

[0188] If confirmation of the status of access policy 528 results in a determination that access policy 528 is invalid (ie, has been revoked), method 1350 proceeds to step 1362 where recipient device 150 revokes access policy 528, as described above with reference to step 1306 of method 1300. Method 1350 then proceeds to step 1354 where the access request is denied.

[0189] In various embodiments of methods 1300 and 1350, it will be understood that various steps can be performed by sender security sharing module 140, recipient security sharing module 170, or recipient TEE 160, as appropriate. It will also be understood that methods 1300 and / or 1350 can be simplified in some embodiments: for example, some embodiments or some access policy configurations can use a dynamic policy server to mediate all policy revocation communications between sender device 120 and recipient device 150, thereby eliminating steps 1304 and 1358 and requiring recipient device 150 to contact the dynamic policy server each time an access request is received. In other words, direct communication between sender device 120 and recipient device 150 can essentially treat sender device 120 as an alternative to a dynamic policy server in some embodiments.

[0190] In some embodiments, other active access options for dynamic access policies are possible. Notification may be required under various conditions, including conditions based on the access action (view, screenshot, etc.), conditions based on the user making a request, or any other attribute or set of attributes. Policy revocation can be enabled, and some embodiments can allow the access policy to select from multiple options how revocation operates (e.g., any of the variations mentioned above can be used for selection in a single embodiment). It should be understood that other active access options are possible using the methods, systems, and devices described herein.

[0191]

[0046] Further examples of methods and systems for secure file sharing with granular access control using the modified ABE technique described above will now be described.

[0192] The systems described below may refer to sensitive information being encrypted "using ABE." It should be understood that this may mean that at least some embodiments encrypt the sensitive data itself using, for example, AES or another symmetric encryption scheme, encrypt the AES key using ABE, and send it along with the encrypted sensitive data, as described above with reference to system 500.

[0193] Controlled sharing of smart home data

[0194] Figure 8 A system diagram illustrates an example system 800 for controlled sharing of smart home data using the methods and devices described above. Operations of system 800 may be implemented using one or more computing devices, including a smart home system 802 running on some combination of a cloud computing platform, a network server, a personal electronic device, and / or a smart speaker or other smart IoT device located within a home. System 800 implements secure authorization of transactions and controls for users of the system based on the granularity of authorization granted to various users in the form of access policies.

[0195] In operation, the smart home system 802 receives a user request to, for example, perform a transaction (e.g., make an online purchase), operate a smart home control (e.g., raise the thermostat setting to 73 degrees Fahrenheit), or access data (e.g., the amount of milk in the refrigerator). The user request may be received through a user interface such as a microphone or a smartphone interface, and the requesting user may be identified by some combination of the device initiating the request, voice recognition, facial recognition, a password or passphrase, etc.

[0196] To determine whether the user request can be authorized, the smart home system 802 collects attributes of the user request at operation 804. In this example, the user request is determined to be made by user "John" and the request is to purchase 2 bottles of shampoo online for a total dollar value of $20, and the user request attributes 806 include some attributes associated with the user making the request (name=John, role=owner, trust level=6) and some attributes associated with the nature of the request (transaction amount=20).

[0197] Once the user has been identified and the user request attributes 806 have been collected, the user's private ABE key is obtained from the key management system 810 in operation 808 .

[0198] The smart home system 802 also collects sensitive details of the user's account (e.g., bank or credit card details) in operation 812. Encrypted account details 814 are provided to the smart home system 802, including sensitive details 816 encoded in the account details encryption using ABE, as described above, and access policies 818 for the sensitive details 816. This operation 812 can be performed at any time relative to operations 804 and 808.

[0199] The smart home system 802 then decrypts the encrypted account details 814 using the user request attributes 806 and the user's private ABE key using an ABE decryption operation 820, as described above. As described above, some embodiments or access policy configurations may also require the user to provide a password or passphrase. If the decryption is successful, the user request is satisfied in operation 822, for example by being relayed to a satisfaction module or platform along with the sensitive account details 816. Figure 8 Taking the example user request shown in , this could mean relaying the user’s credit card data to the online retailer platform while authorizing the shipment of 2 bottles of shampoo to user “John” for a $20 transaction.

[0200] Controlled sharing of health data

[0201] Figure 9 A system diagram of an example system 900 for controlled sharing of health data using the methods and devices described above is shown. The operations of system 900 can be implemented using one or more computing devices, including a health monitoring device 906, such as a smartwatch equipped with health monitoring sensors, and potentially including a smartphone and a cloud computing platform for managing a user's health records.

[0202] The system 900 allows a user to define access policies for accessing his or her health data and also updates the remotely stored health data with new data collected, for example, by the user's health monitoring device 906. In an example use case, the user defines an access policy in operation 904. The access policy is defined by the user's health monitoring device 906, which communicates with a cloud computing platform that stores the user's health records 908. Based on the user-defined access policy, the health records 908 are securely stored using ABE.

[0203] In operation 902, a user requests to update his or her health record 908. The update request may optionally include a new access policy defining the permissions to access the health record 908 defined in operation 904.

[0204] First, the user's existing health records 908 are retrieved from the cloud computing platform via the health monitoring device 906. In operation 930, the encrypted retrieved records 910 are decrypted using ABE. In operation 932, the decrypted records are updated, for example, using user input or new data stored on the health monitoring device 906. In operation 934, the updated records are encrypted using ABE and the existing or new access policy defined in operation 904. The encrypted updated records 912 are sent to the cloud computing platform, where they replace or supplement the existing stored user health records 908.

[0205] When a third party (i.e., any account or device other than the user's personal health monitoring device 906) wishes to access the user's health records 908, the third party must first obtain a private ABE key from the ABE key authority 920. The private ABE keys stored or obtained by the ABE key authority 920 may be generated based on the attributes of each third-party user.

[0206] Under the access policy, different third-party accounts or devices may be granted different permissions. For example, a software application ("app") running on a user's smartphone may be granted a first set of limited permissions to access the user's health records (e.g., view the user's running statistics) based on its role attribute of "app" 914, while a user with the role of "friend" 916 may be granted medium access permissions (e.g., view exercise routines, heart rate, and running statistics), and a user with the role of "family" 918 may be granted access to view all of the user's health records 908.

[0207] Thus, if a user with a role attribute value of "family" attempts to view the user's health records 908, the health records 908 are decrypted using ABE in operation 922, and the encrypted health records, the user's private ABE key, and the user's attributes are input. If decryption operation 922 is successful, the user can view all health records 908 in operation 924.

[0208] Thus, system 900 may be considered a special case or variation of system 500 , where sender device 120 corresponds to health monitoring device 906 , cloud computing platform, and key management authority 920 , and recipient device 150 corresponds to each third-party device or account.

[0209] Fine-grained protection of personal data

[0210] Figure 10A system diagram of an example system 1000 for fine-grained protection of personal data using the methods and devices described above is shown. Operations of system 1000 can be implemented using one or more computing devices, including a smartphone device 1002 and a wearable device 1004. System 1000 illustrates the use of one or more access policies that define fine-grained control over access to data with varying levels of sensitivity or impact.

[0211] The wearable health tracking application 1006 of the wearable device 1004 stores three tiers of data: high-impact data 1022, medium-impact data 1024, and low-impact data 1026. Access to specific data within each tier is controlled by an access policy corresponding to each tier: a high-impact data policy 1032, a medium-impact data policy 1034, and a low-impact data policy 1036. In some embodiments, these multiple policies 1032, 1034, 1036 may be different access policies as described above, while in other embodiments, each access policy is implemented by a different set of attribute configurations within a single access policy. For example, a single access policy may be used in which each data in a given tier 1022, 1024, 1026 may be associated with an attribute value, such as "Data_sensitivity = 2" for high-impact data 1022, "Data_sensitivity = 1" for medium-impact data 1024, and "Data_sensitivity = 0" for low-impact data 1026. In another example, each data in each tier is controlled by an access policy configuration (e.g., access to high-impact data "precise location" requires one set of attributes, access to medium-impact data "exercise routine" requires another set of attributes, and so on).

[0212] Wearable health tracking application 1006 runs on an account with account identifier 1054, shown here as account ID = 1. Wearable device 1004 has device identifier 1052, shown here as device ID = 124. Wearable device 1004 may also store non-personal information 1028, such as clock information providing the current time and date.

[0213] Smartphone device 1002 runs a mobile health tracking application 1007 and a mobile sleep tracking application 1008. Mobile health tracking application 1007 runs on an account with account identifier 1044, shown here as Account ID=1, and has a private ABE key 1042. Mobile health tracking application 1008 runs on an account with account identifier 1048, shown here as Account ID=2, and has a private ABE key 1046. Smartphone device 1002 has a device identifier 1050, shown here as Device ID=123.

[0214] If a software application of the smartphone device 1002 requests access to data stored on the wearable device 1004, the access policies 1032, 1034, 1036 define which information stored by the wearable health tracking application 1007 the device can be authorized to access on which applications. Figure 10 As shown, the high-impact data policy 1032 includes an attribute configuration (device ID = 124, account ID = 1 and attribute = "precise location"), the medium-impact data policy 1034 includes an attribute configuration (device ID from {123, 321, 213}, account ID = 1 and attribute = "exercise routine"), and the low-impact data policy 1036 includes an attribute configuration (device ID from {123, 321, 213} and attribute = "gender"). Thus, the system 1000 can achieve secure sharing of information from the wearable device 1004 to the smartphone device 1002 providing fine-grained permissions by using a set of operations similar to those of the system 500, where the wearable device 1004 assumes at least some functionality of the sender device 120 and the smartphone device 1002 assumes at least some functionality of the recipient device 150. This produces Figure 10 The access request results shown are: mobile health tracking application 1007 is allowed to access the data "exercise routine" in medium-impact data 1024 or the data "gender" in low-impact data 1026, but is prohibited from accessing the data "precise location" in high-impact data 1022; and mobile sleep tracking application 1008 is allowed to access the data "gender" in low-impact data 1026, but is prohibited from accessing the data "exercise routine" in medium-impact data 1024 or the data "precise location" in high-impact data 1022. In some embodiments, private keys 1042 and 1046 are generated in response to a specific setup request and are therefore limited to authorizing access to the specific data specified in the setup request.

[0215] Controlled sharing of data with third-party AI cloud platforms

[0216] Figure 11 A system diagram of an example system 1100 for controlled sharing of data with a third-party AI cloud platform using the above-described methods and devices is shown. The operations of system 1100 can be implemented using one or more computing devices, including a user device 1102, a cloud-based secure sharing platform 1120 composed of one or more devices providing cloud computing services, and a third-party cloud platform 1150 composed of one or more devices providing cloud computing services, including an AI engine 1180 providing artificial intelligence services.

[0217] The system 1100 is capable of securely and controlled sharing of data from a user device 1102 with a relatively untrusted third-party application (e.g., an AI engine 1180 of a third-party cloud platform 1150) via a trusted cloud-based secure sharing platform 1120. Figure 5 The system 500 shown in FIG is very similar, with the cloud-based secure sharing platform 1120 playing the role of the sender device 120 and the third-party cloud platform 1150 playing the role of the receiver device 150. Many of the data and operations of the system 1100 are the same as those of the system 500; they are described above with reference to FIG. Figure 5 Operate as described.

[0218] In system 1100, a user device 1102 (e.g., a smartphone or desktop computer) provides a file 126 to a secure cloud-based sharing platform 1120 via a gateway interface 1142 provided by the secure cloud-based sharing platform 1120. File 126 includes data that the user of user device 1102 wishes to process using an AI service of an AI engine 1180: for example, file 126 may constitute a photographic image captured by a camera of user device 1102, and the AI ​​service may process the photographic image to identify or classify different objects depicted therein. System 1100 can be used to ensure that the contents of file 126 (which may include sensitive personal information) are not misused or exposed by a third-party cloud platform 1150, but are instead used solely for processing the image using AI engine 1180.

[0219] Once the secure cloud-based sharing platform 1120 receives the file 126, it uses the Figure 5 The described techniques encrypt the file 126. In the illustrated embodiment, the ABS key management system 1130 of the cloud-based secure sharing platform 1120 can be used to perform the setup phase of ABE 1134 and private ABE key generation 1136, thereby generating the primary sender ABE public key 526 (which is provided to the secure data sharing service 1140 of the cloud-based secure sharing platform 1120) and the private ABE key 1146 (which is provided to the third-party data sharing service 1170 of the third-party cloud platform 1150). File encryption 532 and ABE encryption 534 of the file encryption key 524 are performed by the secure data sharing service 1140. The encrypted file 174 and the encrypted file encryption key 544 are sent to the third-party data sharing service 1170 of the third-party cloud platform 1150.

[0220] The third-party data sharing service 1170 performs ABE decryption 562 and file decryption 564 as in the system 500 to produce a decrypted file 126. The file 126 is provided to the AI ​​engine 1180, which performs its AI operations on the contents of the file 126 before performing file deletion 566. The AI ​​results 512 of the AI ​​operations are returned to the cloud-based secure sharing platform 1120, which in turn can provide the AI ​​results 512 to the user device 1102.

[0221] The access policy used in the ABE step of the system 1100 can define restrictions on what the third-party cloud platform 1150 is allowed to do with the file 126. For example, the access policy might set an expiration date on the permissions; it might limit the number of file open attempts to a low number, such as one; and it might prevent saving or copying file contents.

[0222] While this disclosure makes reference to a TEE, it should be understood that examples may be implemented using other forms of trusted intermediate environments, including any trusted environment within a sender device, within a recipient device, or at some other network entity.

[0223] Furthermore, although this disclosure describes examples in the context of static data, the examples described herein can be generalized to any type of data, including dynamic data interactions or data streams.

[0224] Although the present disclosure describes methods and processes in a specific order, one or more steps of the methods and processes may be omitted or modified as appropriate. One or more steps may be performed in sequence, but not in the order described (as appropriate).

[0225] Although the present disclosure has been described, at least in part, in terms of methods, it will be understood by those skilled in the art that the present disclosure also relates to various components for performing at least some aspects and features of the described methods through hardware components, software, or any combination of the two. Accordingly, the solutions of the present disclosure may be embodied in the form of a software product. Suitable software products may be stored in a pre-recorded storage device or other similar non-volatile or non-transitory computer-readable medium, such as a DVD, CD-ROM, USB flash drive, removable hard drive, or other storage medium. The software product includes instructions stored thereon that enable a processor device (such as a personal computer, server, or network device) to perform examples of the methods disclosed herein.

[0226] The present disclosure may be embodied in other specific forms without departing from the subject matter of the claims. The described exemplary embodiments are in all respects merely illustrative and not restrictive. Selected features from one or more of the above-described embodiments may be combined to create alternative embodiments not explicitly described, and it is understood that features suitable for such combinations are within the scope of the present disclosure.

[0227] All values ​​and subranges within the disclosed ranges are also disclosed. Furthermore, while the systems, devices, and processes disclosed and illustrated herein may include a specific number of elements / components, the systems, devices, and assemblies may be modified to include more or fewer of such elements / components. For example, while any disclosed element / component may be referenced as singular, the embodiments disclosed herein may be modified to include a plurality of such elements / components. The subject matter described herein is intended to encompass and encompass all suitable technical variations.

Claims

1. A method for data sharing, comprising: The following is received at a recipient device, the recipient device comprising a processor device, the processor device comprising a trusted execution environment (TEE), the TEE comprising a private recipient TEE key: Files encrypted using a file encryption key; the file encryption key encrypted using the sender's primary public attribute-based encryption (ABE) key and an access policy for the file; A set of one or more private ABE keys generated using the access policy and encrypted using the public recipient TEE key; decrypting the set of private ABE keys using the trusted execution environment and applying the private recipient TEE key, and providing at least a first private key in the set of private ABE keys to the processor device; Use the processor device to perform the following operations: decrypting the file encryption key using the first private ABE key and a set of attribute values ​​that satisfy the access policy; and The file encryption key is applied to decrypt the file, thereby generating a decrypted file.

2. The method according to claim 1, further comprising: Prior to receiving the file, the file encryption key and the set of private ABE keys, receiving a setup request from a sender, the setup request including the access policy; In response to receiving the setup request: Generate the public recipient TEE key and the private recipient TEE key using the TEE; as well as A response is sent to the sender, the response including the public recipient TEE key. 3 . The method of claim 2 , wherein the response further comprises a key certification report, the key certification report comprising a device identifier of the recipient device.

4. The method according to claim 3, wherein: The receiving device also includes a trusted clock; The access policy includes an expiration date of permission for the recipient device to access the file; In response to determining, using the trusted clock, that the expiration date has not been reached, the trusted execution environment applies the private recipient TEE key to decrypt the set of private ABE keys; The key certification report includes a confirmation of the expiration date.

5. The method according to any one of claims 1 to 4, wherein one or more of the attribute values ​​are received from a trusted viewer; and Also includes: After decrypting the file, the contents of the decrypted file are made available to the user using the trusted viewer.

6. The method according to claim 5, further comprising: After making the contents of the file available to the user, the decrypted file is deleted using the trusted viewer.

7. The method according to claim 2, wherein the access policy includes a notification condition associated with the access action; The method further comprises: In response to determining that the notification condition has been met: sending a notification to the sender, the notification identifying the access action; In response to determining that the notification has been successfully sent, the access action is implemented on the recipient device.

8. The method of claim 7, wherein sending a notification to the sender comprises: determining whether the sender is capable of receiving notifications; In response to determining that the sender is unable to receive the notification, the notification is sent to a server.

9. The method according to any one of claims 1 to 8, wherein the access policy includes a plurality of attribute configurations, each attribute configuration including a plurality of attribute values ​​for authorizing access to the file content; The set of private ABE keys includes a plurality of private ABE keys, each private ABE key corresponding to an attribute configuration; The set of attribute values ​​satisfying the access policy includes the multiple attribute values ​​of the attribute configuration corresponding to the first private ABE key; The step of decrypting the file encryption key is performed using the first private ABE key and the set of attribute values ​​that satisfy the access policy.

10. The method according to claim 9, wherein: The set of attribute values ​​that satisfy the access policy includes an attribute indicating a number of times the file has been opened on the recipient device; The first private ABE key is selected by the trusted execution environment from the set of private ABE keys in response to: Determine a number N of times the file has been opened on the recipient device; Determining that the set of property values ​​that satisfies the access policy includes a value of the property corresponding to N that indicates the number of times the file has been opened on the recipient device.

11. The method of any one of claims 1 to 10, wherein the file encryption key is decrypted using: the first private ABE key, the set of attribute values ​​that satisfy the access policy, and a user-supplied password.

12. A method for data sharing, comprising: decrypting, using a trusted execution environment (TEE) of a processor device of the sender device, a primary private attribute-based encryption (ABE) key of the sender device using a private sender TEE key of the trusted execution environment; Encrypt files using a file encryption key; encrypting the file encryption key using a primary ABE key of the sender device and an access policy for the file; generating a set of one or more private ABE keys using the decrypted primary private ABE key of the sender device and the access policy; Encrypt the set of private ABE keys using the recipient's public TEE key; The encrypted file, the encrypted file encryption key, and the encrypted set of private ABE keys are sent to the recipient device.

13. The method according to claim 12, further comprising: Before sending the encrypted file, the encrypted file encryption key and the encrypted set of private ABE keys, sending a setting request to the recipient device, the setting request including the access policy; and A response is received from the recipient device, the response including the public recipient TEE key.

14. The method of claim 13, the response further comprising a key certification report, the key certification report comprising a device identifier of the recipient device.

15. The method according to claim 14, wherein: The access policy includes an expiration date for permission for the recipient device to access the file; and In response to determining that the key certification report includes confirmation of the expiration date, the encrypted file, the encrypted file encryption key, and the encrypted set of private ABE keys are sent to the recipient device.

16. The method according to any one of claims 12 to 15, wherein: The access policy includes a plurality of recipient attribute configurations, each recipient attribute configuration including a plurality of recipient attribute values ​​that authorize a recipient device to access the file content; and The set of private ABE keys includes a plurality of private ABE keys, each private ABE key corresponding to a recipient attribute configuration.

17. The method according to claim 13, The access policy is a dynamic access policy. The method further comprises: Before decrypting the file encryption key, Send a policy confirmation request to the dynamic policy server; as well as In response to receiving a policy confirmation from the dynamic policy server indicating that the dynamic access policy is valid, the file encryption key is decrypted.

18. The method of claim 17, the dynamic policy server being the sender device.

19. A receiving device, comprising: a processor device comprising a trusted execution environment (TEE), the TEE comprising a private recipient TEE key; as well as a memory containing instructions that, when executed by the processor device, cause the recipient device to: receiving an encrypted file, an encrypted file encryption key, and an encrypted set of one or more private ABE keys; receiving a decrypted first private ABE key of the encrypted set of private ABE keys from the trusted execution environment; Decrypting the file encryption key using the first private ABE key and a set of attribute values ​​that satisfy an access policy; as well as Decrypting the file using the file encryption key to generate a decrypted file, The trusted execution environment is configured to decrypt the encrypted set of private ABE keys using the private recipient TEE key and provide the decrypted first private ABE key to the processor device.

20. A sending device, comprising: a processor device comprising a trusted execution environment (TEE), the TEE comprising a private sender TEE key; as well as a memory containing instructions that, when executed by the processor device, cause the sending device to: Encrypt files using a file encryption key; encrypting the file encryption key using a primary attribute-based encryption (ABE) key of the sender device and an access policy for the file; generating a set of one or more private ABE keys using the decrypted primary private ABE key of the sender device and the access policy; Encrypt the set of private ABE keys using the recipient's public TEE key; as well as Sending the encrypted file, the encrypted file encryption key and the encrypted set of private ABE keys to the recipient, The trusted execution environment is configured to decrypt the primary private ABE key of the sender device using the private sender TEE key and provide the decrypted primary private ABE key to the processor device.

Images