ABSTRACT
Abstract
A cloud storage system includes an encryption server configured to encrypt a plurality of data by using encryption keys having a hierarchy, the hierarchy of encryption keys corresponding to a relationship among the plurality of encrypted data, and a cloud storage server configured to store the plurality of encrypted data.
Description
CROSS-REFERENCE TO RELATED APPLICATION
This application claims the benefit of U.S. Provisional Application No. 61/862,228, in the U.S. Patent and Trademark Office, the disclosures of which are incorporated herein by reference in their entireties.
BACKGROUND
1. Technical Field
Systems and methods consistent with exemplary embodiments relate to encryption and key management in a cloud storage.
2. Discussion of Related Art
As the use of cloud-based storage and file sharing becomes more widespread, ensuring security and privacy in uploading and/or downloading data while also reducing cost to end-consumers and enterprises has become gradually more important. One tool for decreasing cost is increasing server and space utilization rate through virtualization and introducing multi-tenancy in the cloud service, i.e., offering a âpublic cloudâ. However, when a plurality of users exchange and share data in the public cloud, the demand for technology for securely delivering data between the users has gradually increased.
Secure sockets layer (SSL) is primarily used to encrypt data sent over the public cloud. However, using SSL, a terminal manages a separate certificate for issuing a private key, thereby imposing a burden for certificate management on the terminal. Also, safety in a key issuance process may not be ensured. In particular, when a large number of files are shared among a plurality of users, key management may become complicated. Moreover, efficiency of a cloud storage may be reduced since the same data may be encrypted multiple times with different encryption keys due to multiple users. Not only, this sets bigger strain on computing resources, but also, when same data is encrypted with different keys, it produces different encrypted files, which hinders the operation of de-duplication systems that aim to reduce storage.
SUMMARY
One or more exemplary embodiments provide a file storage system in which data is encrypted for a user according to a key hierarchy, where relationship among the keys is mapped to relationships among access policies.
One or more exemplary embodiments also provide a stateless encryption server that may simply receive encryption keys or parameters for calculation of encryption keys from outside.
One or more exemplary embodiments further provide a key management system separate from a cloud storage service.
According to an aspect of an exemplary embodiment, a file storage system which stores objects in an encrypted format at a storage server and controls each user's access to objects through controlling access to decryption keys is provided.
In the file storage system, when required by access policies, objects may be encrypted by an encryption server using content encryption keys (CEKs). The content encryption keys may be generated based on a key hierarchy, and are accessible to the encryption server. The content encryption keys may be generated outside of the encryption server. A relationship between one content encryption key and other content encryption keys in the key hierarchy may be mapped to a relationship between objects being encrypted. The relationship between the objects being encrypted may correspond to a relationship between access policies or file directories within which the objects being encrypted reside. In an exemplary embodiment, the same content encryption key may be used for the objects being encrypted which belong to the same file directory, in which all the files therein have the same access policy. Thus, the same content encryption key may be used for encryption of more than one object. Also, the content encryption key may be used by more than one user of the same object. In this manner, the burden of key management as well as file storage may be reduced.
The content encryption key may be delivered to a user in an encrypted form, using a key encryption key (KEK), which belongs to at least one from among a unique user and a pre-defined group.
The key encryption key may be one of a Rivest-Shaman-Adleman (RSA) public key, an identification (ID)-based cryptography (IBC) public key, a symmetric key, and the key encryption key may be delivered through a secure channel to the user.
The encrypted form provided by the key encryption key may correspond to use of IBC encryption.
The IBC key encryption key may be delivered to the user, possibly through use of a secure channel, following a user authentication process.
The authentication service may be provided by a standalone (possibly not provided by cloud storage service) authentication server issuing authentication tokens for use by at least of one the user, a license server and a private key generator server. The authentication service may be part of the identity management system belonging to the organization/enterprise that is using the cloud storage service.
The authentication token may be used by the license server to create a license server ticket.
The license server ticket may be used by the private key generator server to authenticate the user before delivering the key encryption key (or the IBC private key).
The license server ticket may include a function of a user credential that the user uses for authentication to the private key generator server.
The authentication token may be issued for use by the private key generator server directly.
The key encryption key may be obtained from a user's locally available storage.
The user may be at least one from among an identifiable individual having, for example, a role within an organization, and a software application, requiring access to an object. An access policy may be specified based on at least one from among the user's role within a circle, a relationship between objects to be encrypted, a file directory structure, and a sensitivity level of an object.
The content encryption keys may be generated in a stateless manner based on a set of key derivation instructions that are receivable by the encryption server.
The key derivation instructions may include information on how to obtain key derivation information including at least one from among a set of a root key, a key derivation function, auxiliary information, and a key derivation policy.
The information on how to obtain key derivation information may be stored at a resource, whose location is conveyed to the encryption server, through a uniform resource identifier (URI), which may be accessed by the encryption server along with a representational state transfer (REST) instruction, such as a Hypertext Transfer Protocol Secure (HTTP)/HTTPS request.
A unique signature of each encrypted file may be created and used in storage de-duplication algorithm. The same content encryption key may be used for the same object regardless of the user, which may improve efficiency of signature creation and the de-duplication algorithm.
A separate key hierarchy may be generated based on a root key that is unique to each organization.
The content encryption key may be a temporary key, whose life time is specified as part of key derivation mechanism and life time information may be stored as metadata at the storage system, which upon expiry of the key may initiate at least of one an alert, actions to renew the key, and actions to re-encrypt data with new keys.
The storage system may not have access to the content encryption key and the key encryption key and may store files only in an encrypted form.
An initial owner of the object may contact the storage system using a REST request, provide at least one from among the object, key derivation information, and object policy group information.
BRIEF DESCRIPTION OF THE DRAWINGS
The above and/or other will be more apparent from the following detailed description of exemplary embodiments taken in conjunction with the accompanying drawings, in which:
FIG. 1 is a block diagram illustrating a cloud based storage system according to an exemplary embodiment;
FIG. 2 is a view for explaining a directory structure of files and a method of encrypting the files according to an exemplary embodiment;
FIG. 3 is a view for explaining a directory structure of files and a method of encrypting the files according to another exemplary embodiment.
FIG. 4 is a block diagram illustrating an ID-based key management system according to an exemplary embodiment;
FIG. 5 is a flowchart illustrating a method of authentication and private key issuance according to an exemplary embodiment;
FIG. 6 is a sequence diagram illustrating an authentication and private key issuance process in an ID-based key management system according to an exemplary embodiment; and
FIG. 7 is a sequence diagram illustrating an authentication and private key issuance process in an ID-based key management system according to another exemplary embodiment.
DETAILED DESCRIPTION
Although exemplary embodiments will be described in detail below with reference to the accompanying drawings, the present disclosure is not limited thereto.
In the following description, well-known technology related to the exemplary embodiments is not described in detail in order to keep the disclosure clear and concise. Terms used herein have been chosen in consideration of functionality of the exemplary embodiments, and may vary depending on a user's or an operator's intentions, or customs in the art. Therefore, the meanings of terms should be interpreted based on the overall context of the present specification.
Herein, the term âcontentâ is used to refer any types of files, image files, videos, audios, etc. In order to refer to an individual piece of content, the term âobjectâ may be used.
The term âuserâ is used to refer to a person or an application which attempts to access data in cloud storage. The person may belong to or include a plurality of individuals, for example, in a circle of friends, a team within an organization, a department (human resource (HR), accounting, research and development (R&D)). An application may include, for example, an email application, a procurement or customer relationship management (CRM) application. An application may be a part of, for example, circles of applications that have the same access policy with respect to the content. For example, financial and/or accounting application may have access to employee salary data files, while email and/or instant messaging and/or web conferencing application may have access to employee emails, phone number data files, etc. The access policy for an application may be defined based on a function of the application, users, and/or security capability in dealing with the content.
FIG. 1 is a block diagram illustrating a cloud based storage system 100 according to an exemplary embodiment.
Referring to FIG. 1 , a cloud based storage system 100 according to an exemplary embodiment includes an encryption provider 102 , an authentication server 104 , a license server 106 , a cloud storage server 110 , a first terminal 112 , and a second terminal 114 .
A user of the first terminal 112 may store data in the cloud storage server 110 to be used by the user or shared with another user, e.g., a user of the second terminal 114 . To do so, the first terminal 112 may establish a secure link (e.g., an Hypertext Transfer Protocol Secure (HTTPS) link that is protected with a secure sockets layer (SSL)) with the encryption server 102 and send the data, which the user of the first terminal 112 wants to store on the cloud, to the encryption server 102 to be encrypted. In this case, the first terminal 112 may contact a uniform resource identifier (URI) of the cloud storage server 110 through an HTTP session, and this session may be redirected to the encryption server 102 . Here, the encryption server 102 may be operated by a security provider distinct from a cloud provider.
The encryption server 102 encrypts the data transmitted from the first terminal 112 . The <figure-callout id="102" label="encryption server" filenames="US09465947-20161011-D00000.png,US
CROSS-REFERENCE TO RELATED APPLICATION
This application claims the benefit of U.S. Provisional Application No. 61/862,228, in the U.S. Patent and Trademark Office, the disclosures of which are incorporated herein by reference in their entireties.
BACKGROUND
1. Technical Field
Systems and methods consistent with exemplary embodiments relate to encryption and key management in a cloud storage.
2. Discussion of Related Art
As the use of cloud-based storage and file sharing becomes more widespread, ensuring security and privacy in uploading and/or downloading data while also reducing cost to end-consumers and enterprises has become gradually more important. One tool for decreasing cost is increasing server and space utilization rate through virtualization and introducing multi-tenancy in the cloud service, i.e., offering a âpublic cloudâ. However, when a plurality of users exchange and share data in the public cloud, the demand for technology for securely delivering data between the users has gradually increased.
Secure sockets layer (SSL) is primarily used to encrypt data sent over the public cloud. However, using SSL, a terminal manages a separate certificate for issuing a private key, thereby imposing a burden for certificate management on the terminal. Also, safety in a key issuance process may not be ensured. In particular, when a large number of files are shared among a plurality of users, key management may become complicated. Moreover, efficiency of a cloud storage may be reduced since the same data may be encrypted multiple times with different encryption keys due to multiple users. Not only, this sets bigger strain on computing resources, but also, when same data is encrypted with different keys, it produces different encrypted files, which hinders the operation of de-duplication systems that aim to reduce storage.
SUMMARY
One or more exemplary embodiments provide a file storage system in which data is encrypted for a user according to a key hierarchy, where relationship among the keys is mapped to relationships among access policies.
One or more exemplary embodiments also provide a stateless encryption server that may simply receive encryption keys or parameters for calculation of encryption keys from outside.
One or more exemplary embodiments further provide a key management system separate from a cloud storage service.
According to an aspect of an exemplary embodiment, a file storage system which stores objects in an encrypted format at a storage server and controls each user's access to objects through controlling access to decryption keys is provided.
In the file storage system, when required by access policies, objects may be encrypted by an encryption server using content encryption keys (CEKs). The content encryption keys may be generated based on a key hierarchy, and are accessible to the encryption server. The content encryption keys may be generated outside of the encryption server. A relationship between one content encryption key and other content encryption keys in the key hierarchy may be mapped to a relationship between objects being encrypted. The relationship between the objects being encrypted may correspond to a relationship between access policies or file directories within which the objects being encrypted reside. In an exemplary embodiment, the same content encryption key may be used for the objects being encrypted which belong to the same file directory, in which all the files therein have the same access policy. Thus, the same content encryption key may be used for encryption of more than one object. Also, the content encryption key may be used by more than one user of the same object. In this manner, the burden of key management as well as file storage may be reduced.
The content encryption key may be delivered to a user in an encrypted form, using a key encryption key (KEK), which belongs to at least one from among a unique user and a pre-defined group.
The key encryption key may be one of a Rivest-Shaman-Adleman (RSA) public key, an identification (ID)-based cryptography (IBC) public key, a symmetric key, and the key encryption key may be delivered through a secure channel to the user.
The encrypted form provided by the key encryption key may correspond to use of IBC encryption.
The IBC key encryption key may be delivered to the user, possibly through use of a secure channel, following a user authentication process.
The authentication service may be provided by a standalone (possibly not provided by cloud storage service) authentication server issuing authentication tokens for use by at least of one the user, a license server and a private key generator server. The authentication service may be part of the identity management system belonging to the organization/enterprise that is using the cloud storage service.
The authentication token may be used by the license server to create a license server ticket.
The license server ticket may be used by the private key generator server to authenticate the user before delivering the key encryption key (or the IBC private key).
The license server ticket may include a function of a user credential that the user uses for authentication to the private key generator server.
The authentication token may be issued for use by the private key generator server directly.
The key encryption key may be obtained from a user's locally available storage.
The user may be at least one from among an identifiable individual having, for example, a role within an organization, and a software application, requiring access to an object. An access policy may be specified based on at least one from among the user's role within a circle, a relationship between objects to be encrypted, a file directory structure, and a sensitivity level of an object.
The content encryption keys may be generated in a stateless manner based on a set of key derivation instructions that are receivable by the encryption server.
The key derivation instructions may include information on how to obtain key derivation information including at least one from among a set of a root key, a key derivation function, auxiliary information, and a key derivation policy.
The information on how to obtain key derivation information may be stored at a resource, whose location is conveyed to the encryption server, through a uniform resource identifier (URI), which may be accessed by the encryption server along with a representational state transfer (REST) instruction, such as a Hypertext Transfer Protocol Secure (HTTP)/HTTPS request.
A unique signature of each encrypted file may be created and used in storage de-duplication algorithm. The same content encryption key may be used for the same object regardless of the user, which may improve efficiency of signature creation and the de-duplication algorithm.
A separate key hierarchy may be generated based on a root key that is unique to each organization.
The content encryption key may be a temporary key, whose life time is specified as part of key derivation mechanism and life time information may be stored as metadata at the storage system, which upon expiry of the key may initiate at least of one an alert, actions to renew the key, and actions to re-encrypt data with new keys.
The storage system may not have access to the content encryption key and the key encryption key and may store files only in an encrypted form.
An initial owner of the object may contact the storage system using a REST request, provide at least one from among the object, key derivation information, and object policy group information.
BRIEF DESCRIPTION OF THE DRAWINGS
The above and/or other will be more apparent from the following detailed description of exemplary embodiments taken in conjunction with the accompanying drawings, in which:
FIG. 1 is a block diagram illustrating a cloud based storage system according to an exemplary embodiment;
FIG. 2 is a view for explaining a directory structure of files and a method of encrypting the files according to an exemplary embodiment;
FIG. 3 is a view for explaining a directory structure of files and a method of encrypting the files according to another exemplary embodiment.
FIG. 4 is a block diagram illustrating an ID-based key management system according to an exemplary embodiment;
FIG. 5 is a flowchart illustrating a method of authentication and private key issuance according to an exemplary embodiment;
FIG. 6 is a sequence diagram illustrating an authentication and private key issuance process in an ID-based key management system according to an exemplary embodiment; and
FIG. 7 is a sequence diagram illustrating an authentication and private key issuance process in an ID-based key management system according to another exemplary embodiment.
DETAILED DESCRIPTION
Although exemplary embodiments will be described in detail below with reference to the accompanying drawings, the present disclosure is not limited thereto.
In the following description, well-known technology related to the exemplary embodiments is not described in detail in order to keep the disclosure clear and concise. Terms used herein have been chosen in consideration of functionality of the exemplary embodiments, and may vary depending on a user's or an operator's intentions, or customs in the art. Therefore, the meanings of terms should be interpreted based on the overall context of the present specification.
Herein, the term âcontentâ is used to refer any types of files, image files, videos, audios, etc. In order to refer to an individual piece of content, the term âobjectâ may be used.
The term âuserâ is used to refer to a person or an application which attempts to access data in cloud storage. The person may belong to or include a plurality of individuals, for example, in a circle of friends, a team within an organization, a department (human resource (HR), accounting, research and development (R&D)). An application may include, for example, an email application, a procurement or customer relationship management (CRM) application. An application may be a part of, for example, circles of applications that have the same access policy with respect to the content. For example, financial and/or accounting application may have access to employee salary data files, while email and/or instant messaging and/or web conferencing application may have access to employee emails, phone number data files, etc. The access policy for an application may be defined based on a function of the application, users, and/or security capability in dealing with the content.
FIG. 1 is a block diagram illustrating a cloud based storage system 100 according to an exemplary embodiment.
Referring to FIG. 1 , a cloud based storage system 100 according to an exemplary embodiment includes an encryption provider 102 , an authentication server 104 , a license server 106 , a cloud storage server 110 , a first terminal 112 , and a second terminal 114 .
A user of the first terminal 112 may store data in the cloud storage server 110 to be used by the user or shared with another user, e.g., a user of the second terminal 114 . To do so, the first terminal 112 may establish a secure link (e.g., an Hypertext Transfer Protocol Secure (HTTPS) link that is protected with a secure sockets layer (SSL)) with the encryption server 102 and send the data, which the user of the first terminal 112 wants to store on the cloud, to the encryption server 102 to be encrypted. In this case, the first terminal 112 may contact a uniform resource identifier (URI) of the cloud storage server 110 through an HTTP session, and this session may be redirected to the encryption server 102 . Here, the encryption server 102 may be operated by a security provider distinct from a cloud provider.
The encryption server 102 encrypts the data transmitted from the first terminal 112 . The encryption server 102 performs encryption according to, for example, a predefined access control policy (i.e., an access policy) of the user and/or the cloud provider. In an exemplary embodiment, the access policy of the user may be based on a key hierarchy corresponding to (e.g., mapped to) a directory structure of the data in the cloud storage server 110 , which will be described in detail below with reference to FIGS. 2 and 3 .
Referring to FIG. 2 , according to an exemplary embodiment, data stored in the cloud storage server 110 may have a directory structure for files including a root node, first level directories D 1 (i.e., directories D 11 , D 12 , and D 13 ) under the root node, second level directories D 2 (i.e., directories D 21 , D 22 , and D 23 ) under the first level directories D 1 , and third level directories D 3 (i.e., directories D 31 , D 32 , and D 33 ) under the second level directories D 2 .
Generally, a group of objects and/or files that are encrypted using the same content encryption key (CEK) may be referred to as a homogeneous policy group (HPG). In the present exemplary embodiment, an HPG is based on the directory structure. Specifically, a lowest level directory is a directory within which all the files are governed by the same access control policy (e.g., a directory in which all files belong to the same project to be accessed only by team members of that project). In other words, if a user is authorized to see one of the files in this directory, the user can see all of the files within the directory. This allows the encryption system to encrypt all files within the directory with the same key (Kdir) mapped to the directory, while allowing authentication and licensing systems to handle access control and key management for all of the files within the directory in a similar, homogenous fashion. This directory level may be referred to as a homogenous level directory (HLD).
For example, referring to FIG. 2 , all the files in the third level directory D 33 may be controlled by a same access control policy. In other words, when a user is authorized to see one of files file 1 , file 2 , or file 3 in the third level directory D 33 , the user may see all the files file 1 , file 2 , and file 3 within the third level directory D 33 . Therefore, all the files within the same directory may be encrypted with the same key (i.e., content encryption key) Kdir. In this case, a key management process may employ a key hierarchy corresponding to or mapped to the directory structure. That is, all the files within the directory may be controlled by a similar, homogenous key management scheme or policy. For example, a content encryption key Kdir for encrypting the entire directory may be generated by using a root key Kr that is generated or obtained as a unique key for encrypting the root node, a path to the directory, and a key derivation policy of the user, as will be described in further detail below.
The encryption method using a key hierarchy according to the present exemplary embodiment may be implemented by the cloud based storage system 100 in a case where a plurality of users access the files based on pre-defined access control policies. Furthermore, regardless of which user is using the data, as long as the data is linked to a directory, the file is encrypted with the same algorithm and the same encryption key as other data stored in the same directory. That is, the encrypted data in the same directory has a unique signature such that, even when the data is stored by a plurality of users, all copies of the data may be effectively detected by a de-duplication algorithm implemented by the cloud storage server 110 . Therefore, de-duplication may be performed with improved efficiency.
FIG. 3 is a diagram for explaining a directory structure of files and a method of encrypting the files according to another exemplary embodiment.
The access control policies in FIG. 3 are different from that shown in FIG. 2 in that files within a directory may be controlled by different policies. That is, file 1 and file 2 of the third level directory are controlled by policy 1 while file 3 is controlled by policy 2 . Thus, files in the same directory may be encrypted in a different fashion according to, for example, an encryption policy field in the metadata for the file. In this case, a content encryption key Kfile for encrypting a specific file within the directory may be generated by using the encryption key Kdir for encrypting the corresponding directory and a policy which controls the specific file.
Although it is described above that access control is performed based on access policies corresponding to a directory structure, one or more other exemplary embodiments are not limited thereto. For example, in an exemplary embodiment, a plurality of objects and/or files located in different directories may be covered under the same policy. In this case, the plurality of objects and/or files may be encrypted with the same key. For example, an enterprise may store files in the cloud storage server 110 and allow employees, customers, and business partners of the enterprise to access the files based on the pre-defined access control policy.
Referring now back to FIG. 1 , the encryption server 102 may obtain a content encryption key in a stateless manner. For example, the encryption server 102 may receive the access policy in a form of a key derivation policy using a representational state transfer (REST)-based instruction. In this case, the first terminal 112 may build a representational state transfer (REST) request that includes a URI reference to a resource for key derivation information including at least one of the key derivation policy, the root key Kr, and a key derivation function. According to another exemplary embodiment, the encryption server 102 may obtain the content encryption key in a stateless manner by receiving the key derivation function and implementing the key derivation function on a root key stored by the encryption server 102 . The key derivation function is a cryptographic function on parameters of the key derivation information. The resource indicated by the URI may also include other information such as a corresponding directory path (or a policy group to which the data belongs to), and authorization parameters of the user. For example, the user's authorization parameters may be defined by the homogeneous policy group. The key derivation information may be stored at the license server 106 , and the encryption server 102 may obtain the key derivation information by connecting to the license server 106 . Based on the received key derivation information, the encryption server 102 determines (e.g., generates, obtains, etc.) the content encryption key for the content. The content encryption key may be used in a designated cryptography algorithm, which may be an advanced encryption standard (AES)-128) in an exemplary embodiment. Here, an interface between the encryption server 102 and the license server 106 may be provided to fetch the resource. The interface may be protected using Internet protocol security (IPsec) or using SSL.
The key derivation information may further include auxiliary information such as, for example, a validity period, a group name for restricting access control to a particular group of users, and a policy ID/URI for locating a specific policy document (or an encryption policy field that is part of metadata generated for the file and used for re-creation of the content encryption key CEK for decryption of encrypted objects). The validity period is a parameter that allows the license server 106 to rotate encryption keys on a predetermined period or when necessary. For example, the encryption key may be changed every month or whenever the encryption key is released to reduce the probability of piracy. The validity period may be provided with respect to a directory of data stored at the cloud storage server 100 . The cloud storage server 100 may set an alarm for the encryption server 102 and the license server 106 to inform the encryption server 102 and the license server 106 of an upcoming expiration of a validity period. When the validity period expires, all files within the corresponding directory may be re-encrypted with a new encryption key. In this case, the cloud storage server 110 may send data in the corresponding directory to the encryption server 102 for re-encryption. In this manner, the cloud storage server 110 may avoid liability for privacy issues regarding stored data. When the data is re-encrypted, the second terminal 114 may be authenticated again by the authentication server 104 and receive a public key with respect to the renewed encryption key.
By way of example, the content encryption key (Kdir) may be obtained according to the following equation 1:
K dir=KDF( K root,path|KDF Auxiliary information),ââ[Equation 1]
where KDF (key derivation function) is a cryptographic function that is used on the parameters inside the parentheses, Kroot is the root key, e.g., that is generated as a unique key at top of key hierarchy for each enterprise/organization, path is the directory path (e.g. â/c/projects/cloud-project/security-architecture/â), and KDF auxiliary information (e.g., other information) includes any other parameters that may be included in key derivation (examples of which are described above).
After performing encryption, the encryption server 102 sends the encrypted data along with corresponding metadata to the cloud storage server 110 . The cloud storage server 110 stores the encrypted data along with the metadata in a particular location, based on the provided metadata, which may include an encryption policy field.
In the present exemplary embodiment, the encryption server 102 may be operated by a security provider. However, it is understood that one or more other exemplary embodiments are not limited thereto and the encryption server 102 may be operated by, for example, the cloud provider.
The authentication server 104 is a server for performing user authentication of a user of the second terminal 114 (or the second terminal 114 ), which attempts to access data stored by the user of the first terminal 112 (or the first terminal 112 ) in the cloud storage server 110 . In an exemplary embodiment, the authentication server 104 may include an ID and a password of the user of the second terminal 114 and authenticate the second terminal 114 through, for example, a password authentication algorithm inside an HTTPS, where a user ID and a password is asserted inside an SSL tunnel. Alternatively, the authentication may be performed by using any other type of user authentication mechanism (e.g., Extended Authentication Protocol Tunneled Transport Layer Security (EAP-TTLS) or Microsoft CHAP version 2 (MS-CHAP2)). When the user is an enterprise user, the authentication may be performed according to a security policy of the enterprise.
When the user of the second terminal 114 is authenticated, the authentication server 104 provides an authentication token Auth_token including a user ID to the license server 106 .
Auth_token_LS= E [KAS-LS,AS-ID|Nonce|User_ID| f (PSWD)|validity],AS-signature,ââ [Equation 2]
where the nonce is a parameter that can be used to avoid replay attacks. For example, the nonce may be a random number or a time stamp pertaining to the time when the user was authenticated. f(PSWD) indicates a function of the user's password. The function can be a one-way cryptographic hash function that avoids revealing of the password. According to another exemplary embodiment, the authentication token Auth_token may include a user's password instead of the function of the user's password, e.g., when the password is not to remain private to the user and hidden from the license server 106 .
The authentication token Auth_token may be encrypted by using a key shared between the authentication server 104 and the license server 106 . In an alternative embodiment, the authentication token Auth_token may not be encrypted when a secure channel is established between the authentication server 104 and the license server 106 . In this case, the authentication token Auth_token may include a signature performed by the authentication server 104 on the token Auth_token. By using the authentication token Auth_token, the license server 106 may determine whether a user requesting a content from the cloud storage server 110 is allowed or permitted to access the content.
According to another exemplary embodiment, instead of generating the authentication token Auth_token, the authentication server 104 may verify the authentication of the user to the license server 106 through a secure channel between the authentication server 104 and the license server 106 .
When the user is an enterprise user, the enterprise user may want to manage its own keys. In this case, a dedicated encryption server may be configured with enterprise policies (e.g., directory structure, authorization policies, etc.) to apply encryption accordingly. For example, the enterprise policies may have a hierarchy structure which maps corresponding access policies. According to an exemplary embodiment, all the files within the same directory may have the same access policy. In this case, the hierarchy structure of the enterprise policies may correspond to the directory structure.
When the encryption server 102 is shared between a plurality of users, for example, when the encryption server 102 is provided by the security provider or the cloud provider, access policies may be communicated to the encryption server 102 using a REST-based instruction so that the encryption server 102 obtains the content encryption keys in a stateless manner.
For example, the encryption server 102 may store and/or receive the root key Kr and the key derivation policy KDP per user without a need for storing encryption keys for all levels of the file structure. The REST instruction may provide a URI where a resource is stored that has a representation (XML, JSON, etc) of the user's key derivation instruction, including the root key Kr, the key derivation policy KDP, and a key derivation function (KDF), policy information, file structure, etc. Thus, the encryption server 102 may refer to the URI included in the REST-based instructions from the user to locate a specific policy document. The encryption server 102 may not store the root key Kr, e.g., when the resource also provides information on the root key Kr. In this case, according to an exemplary embodiment, the root key Kr may be securely transferred to the encryption server 102 when needed.
The license server 106 determines whether the second terminal 114 , which requests the data stored in the cloud storage server 110 , is authorized to access the content based on a result of the authentication by the authentication server 104 (e.g., based on the authentication token Auth_token provided from the authentication server 104 ). When it is determined that the second terminal 114 is authorized to access the data, the license server 106 generates a license that allows the user to access the content. The license may include an encrypted content encryption key, which is encrypted for transmitting to the user of the second terminal 114 using a key encryption key that is unique to the user or a group of users to which the user belongs. In an exemplary embodiment, identity based cryptography (IBC) may be used to encrypt the content encryption key. Thus, only a user of the second terminal 114 may be allowed to use the IBC public key. Furthermore, the license may also include a ticket (LS-Ticket), which may include a validity period, an ID of the user, etc., as will be described in greater detail below. Alternatively, the ticket may use the authentication token Auth_token issued by the authentication server 104 . In this way, the user's privacy may be protected.
By way of example, the license server 106 may generate the license according to the following equation 3:
License=EIBC,Pub B [CEK],LS-Ticket.ââ[Equation 3]
Although it is described that the IBC may be used to encrypt the content encryption key, it is understood that one or more other exemplary embodiments are not limited thereto. For example, the content encryption key may be encrypted by using a Rivest-Shaman-Adleman (RSA) algorithm. In this case, the license may be generated according to the following equation 4:
License=ERSA,Pub B [CEK],LS-Ticket.ââ[Equation 4]
According to another exemplary embodiment, the content encryption key may be encrypted by using symmetric AES algorithm. For example, the license may be generated according to the following equation 5:
License=EAES, K _ B [CEK],LS-Ticket.ââ[Equation 5]
The cloud based storage system 100 may additionally include a private key generator (see FIG. 4 ) co-located with or separate from the license server to provide a private key to a user terminal. The private key generator is entity that stores a number of system wide secrets within its secure storage (e.g., a hardware security module (HSM)) and calculates private keys for authorized users based on their identity (ID) and public key (Pub). Thus, users can refer to the private key generator and after proper assertion of their credentials, receive a private key to decrypt anything that was sent to them in IBC-encrypted format (e.g., to decrypt the encrypted content encryption key).
The license server 106 may issue a ticket to the private key generator according to the following equation 6:
LS-Ticket=E[KLS-PKG,LS-ID|Random|User_ID|[ f (PSWD)]|[Auth_token_LS]|validity],LS-signature.ââ[Equation 6]
According to Equation 6, the ticket is encrypted with a key shared between the license server 106 and the private key generator (KLS-PKG) and includes an identity of license server 106 (LS-ID) and a random number (Random) that is shared out of band between the license server 106 and the private key generator. In some cases, both the license server 106 and the private key generator are run by the same security provider, while the authentication server 104 is implemented by the enterprise. In these cases, the KLS-PKG may simply be a key that is internal to the license server/private key generator housing.
The ticket also includes the User_ID, which is the same as the ID used in IBC, and a copy of the form of password as used by the user to authenticate to the authentication system. Alternatively, the ticket could simply use the Auth-token as issued by the authentication server 104 to preserve the user's and the enterprise's privacy
Depending on the channel between the license server 106 and the private key generator, the encryption (E[KLS-PKG, data]) may or may not be performed. For example, if there is an IPsec VPN between the license server 106 and the private key generator, a signature may be performed by the authentication server 104 on the token. The signature may either use a public-key signature (along with license server_certificate) or simply a symmetric key that is shared between the license server 106 and the private key generator.
Later on, when a user engages in a key exchange (e.g., Isomorphisms for Password-based Authenticated Key Exchange) with the private key generator, the user sends his or her password to the private key generator using an encryption key that is arrived as part of the key exchange. In this case, the private key generator may be pre-configured with user passwords, or may be tightly integrated with the authentication server to verify the password, sent by the user. In the present exemplary embodiment, however, the private key generator receives a copy of the password through the ticket issued by the license server 106 , and may not be pre-configured with passwords or be tightly integrated with the enterprise IT system.
Once the key exchange is complete, the private key generator delivers the private key to the user, so that the user can decrypt the content encryption key delivered with the license from the license server 106 and subsequently decrypt the data. The private key generator may authenticate the user using its private key generator certificates, or using implicit knowledge of the user's private key.
In an exemplary embodiment, the authentication server 104 and the license server 106 may be provided by the same entity, e.g., a security provider. Additionally, according to an exemplary embodiment, the authentication server 104 and the license server 106 may be implemented in a single server. However, it is understood that one or more other exemplary embodiments are not limited thereto. For example, according to another exemplary embodiment, the authentication server 104 and the license server 106 may be separate entities.
FIG. 4 is a block diagram illustrating an ID-based key management system 200 according to an exemplary embodiment. The same reference numerals are used to denote the same elements as those in FIG. 1 , and a repeated explanation is omitted below.
Referring to FIG. 4 , an ID-based key management system 200 according to an exemplary embodiment includes the <figure-callout id="104" label="authentication server" filenames="US09465947-20161011-D00000.png,US09465947-20161011-D00001.png" sta
CLAIMS
Claims ( 17 )
What is claimed is:
1. A cloud storage system, comprising:
an encryption server configured to encrypt a plurality of data by using encryption keys having a hierarchy, the hierarchy of encryption keys corresponding to a relationship among the plurality of encrypted data; and
a cloud storage server configured to store the plurality of encrypted data,
wherein at least two or more data are configured in a directory structure, the hierarchy of the encryption keys corresponding to the directory structure,
wherein the encryption keys are generated in a stateless manner based on key derivation information received by the encryption server, the key derivation information comprising information about a key derivation function, the key derivation function configured to determine an encryption key based on a root key and a directory path, the root key being a key at a top of the hierarchy of the encryption keys, and
wherein at least one of the encryption server and the cloud storage server is implemented by at least one hardware processor.
2. The cloud storage system according to claim 1 , wherein the relationship among the plurality of encrypted data is determined according to an access policy for each data.
3. The cloud storage system according to claim 2 , wherein, when at least two or more data have the same access policy, the two or more data are encrypted by using the same encryption key.
4. The cloud storage system according to claim 2 , wherein all of data in each directory have the same access policy and are encrypted by using the same encryption key.
5. The cloud storage system according to claim 2 , wherein the same data are encrypted by using the same encryption key regardless of a user who transmits the same data to be encrypted and stored in the cloud storage.
6. The cloud storage system according to claim 1 , wherein the key derivation information further comprises auxiliary information comprising at least one from among the directory path, a validity period of an encryption key, a name of a group of users having an access right, a policy identification (ID), and a uniform resource identifier (URI) for locating the policy ID.
7. The cloud storage system according to claim 6 , wherein the validity period is stored at the cloud storage server, and prior to or upon expiry of the encryption key, the cloud storage performs at least of one from among an alert, an action to renew the encryption key, an action to re-encrypt data with the renewed encryption key.
8. The cloud storage system according to claim 1 , wherein a representational state transfer (REST) instruction containing data to be encrypted is received by the encryption server, the REST instruction comprising a URI location of a resource at which the key derivation instruction is stored.
9. A cloud storage system in which data encrypted by an encryption key are stored, the cloud storage system comprising:
an authentication server configured to authenticate a user based on an identification (ID) and a password of the user;
a license server configured to provide a license to access the encrypted data to the user based on a result of the authentication, the license comprising a key encryption key obtained by encrypting the encryption key; and
a private-key generator configured to generate a private key for decrypting the encrypted data based on the license,
wherein at least two or more data are configured in a directory structure, the hierarchy of encryption keys corresponding to the directory structure,
wherein the encryption keys are generated in a stateless manner based on key derivation information, the key derivation information comprising information about a key derivation function, the key derivation function configured to determine the encryption key based on a root key and a directory path, the root key being a key at a top of the hierarchy of the encryption keys, and
wherein at least one of the authentication server, the license server, and the private-key generator is implemented by at least one hardware processor.
10. The cloud storage system according to claim 9 , wherein the key encryption key comprises at least one from among a Rivest-Shaman-Adleman (RSA) public key, an identification (ID)-based cryptography (IBC) public key, and a symmetric key, and the key encryption key is delivered to the user through a secure channel.
11. The cloud storage system according to claim 9 , wherein, when the user is authenticated by the authentication server, the authentication server generates an authentication token to be used by at least of one the user, the license server and the private key generator.
12. The cloud storage system according to claim 11 , wherein the license comprises a license server ticket generated based on the authentication token, and the private key generator authenticates, prior to generating the private key, the user based on the license server ticket.
13. The cloud storage system according to claim 12 , wherein the license server ticket comprises at least one from among the password and a function of the password of the user.
14. The cloud storage system according to claim 11 , wherein, when the user is authenticated by the authentication server, the authentication server generates authentication tokens for the license server and the private key generator, respectively.
15. An encryption method in a cloud storage system, the encryption method comprising:
receiving a plurality of data from a user; and
encrypting, at an encryption server separate from the cloud storage system, a plurality of data by using encryption keys having a hierarchy, the hierarchy of encryption keys corresponding to a relationship among the plurality of encrypted data, wherein the plurality of encrypted data are stored in the cloud storage system,
wherein at least two or more data are configured in a directory structure, the hierarchy of the encryption keys corresponding to the directory structure,
wherein the encryption keys are generated in a stateless manner based on key derivation information received by the encryption server, the key derivation information comprising information about a key derivation function, the key derivation function configured to determine an encryption key based on a root key and a directory path, the root key being a key at a top of the hierarchy of the encryption keys, and
wherein the encryption server is implemented by at least one hardware processor.
16. An encryption method according to claim 15 , wherein the relationship among the plurality of encrypted data is determined according to an access policy for each data.
17. An encryption method according to claim 16 , wherein, when at least two or more data have the same access policy, the two or more data are encrypted by using the same encryption key.
US14/507,720
2013-08-05
2014-10-06
System and method for encryption and key management in cloud storage
Expired - Fee Related
US9465947B2
( en )
Priority Applications (1)
Application Number
Priority Date
Filing Date
Title
US14/507,720
US9465947B2
( en )
2013-08-05
2014-10-06
System and method for encryption and key management in cloud storage
Applications Claiming Priority (2)
Application Number
Priority Date
Filing Date
Title
US201361862228P
2013-08-05
2013-08-05
US14/507,720
US9465947B2
( en )
2013-08-05
2014-10-06
System and method for encryption and key management in cloud storage
Publications (2)
Publication Number
Publication Date
US20150186657A1
US20150186657A1 ( en )
2015-07-02
US9465947B2
true
US9465947B2 ( en )
2016-10-11
Family
ID=53482118
Family Applications (1)
Application Number
Title
Priority Date
Filing Date
US14/507,720
Expired - Fee Related
US9465947B2
( en )
2013-08-05
2014-10-06
System and method for encryption and key management in cloud storage
Country Status (1)
Country
Link
US
( 1 )
US9465947B2
( en )
Cited By (5)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US20160357971A1
( en )
*
2015-02-25
2016-12-08
Anand Sinha
Parallel and hierarchical password protection on specific document sections
CN107317823A
( en )
*
2017-08-01
2017-11-03
广ä¸äºä¸æ±éç§ææéå ¬å¸
Encryption method and system in a kind of cloud storage system
US10895994B2
( en )
*
2017-12-11
2021-01-19
International Business Machines Corporation
File access control on magnetic tape by encrypting metadata
US10931443B2
( en )
2018-08-23
2021-02-23
International Business Machines Corporation
Hierarchical key management based on bitwise XOR operations
US11290436B2
( en )
2018-09-21
2022-03-29
Cisco Technology, Inc.
Mechanism for encryption key distribution in computer networks
Families Citing this family (76)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US8874935B2
( en )
2011-08-30
2014-10-28
Microsoft Corporation
Sector map-based rapid data encryption policy compliance
US9882713B1
( en )
*
2013-01-30
2018-01-30
vIPtela Inc.
Method and system for key generation, distribution and management
US20140344570A1
( en )
2013-05-20
2014-11-20
Microsoft Corporation
Data Protection For Organizations On Computing Devices
US9298942B1
( en )
*
2013-12-31
2016-03-29
Google Inc.
Encrypted augmentation storage
US10615967B2
( en )
2014-03-20
2020-04-07
Microsoft Technology Licensing, Llc
Rapid data protection for storage devices
US9922200B2
( en )
2014-06-30
2018-03-20
Microsoft Technology Licensing, Llc
Securely storing content within public clouds
US9825945B2
( en )
2014-09-09
2017-11-21
Microsoft Technology Licensing, Llc
Preserving data protection with policy
US9853812B2
( en )
*
2014-09-17
2017-12-26
Microsoft Technology Licensing, Llc
Secure key management for roaming protected content
US9900295B2
( en )
2014-11-05
2018-02-20
Microsoft Technology Licensing, Llc
Roaming content wipe actions across devices
EP3032453B1
( en )
*
2014-12-08
2019-11-13
eperi GmbH
Storing data in a server computer with deployable encryption/decryption infrastructure
US10560440B2
( en )
2015-03-12
2020-02-11
Fornetix Llc
Server-client PKI for applied key management system and process
US10630686B2
( en )
2015-03-12
2020-04-21
Fornetix Llc
Systems and methods for organizing devices in a policy hierarchy
US10965459B2
( en )
2015-03-13
2021-03-30
Fornetix Llc
Server-client key escrow for applied key management system and process
US20160364553A1
( en )
*
2015-06-09
2016-12-15
Intel Corporation
System, Apparatus And Method For Providing Protected Content In An Internet Of Things (IOT) Network
US9853820B2
( en )
2015-06-30
2017-12-26
Microsoft Technology Licensing, Llc
Intelligent deletion of revoked data
CN106559379A
( en )
*
2015-09-25
2017-04-05
å¯æ³°åå·¥ä¸ï¼æ·±å³ï¼æéå ¬å¸
High in the clouds encryption system and method
US9735962B1
( en )
*
2015-09-30
2017-08-15
EMC IP Holding Company LLC
Three layer key wrapping for securing encryption keys in a data storage system
US9900325B2
( en )
2015-10-09
2018-02-20
Microsoft Technology Licensing, Llc
Passive encryption of organization data
TWI575925B
( en )
*
2015-11-11
2017-03-21
大å®æ¸åµæè¡ä»½æéå ¬å¸
Method and system for data encryption and decryption
US10372926B1
( en )
2015-12-21
2019-08-06
Amazon Technologies, Inc.
Passive distribution of encryption keys for distributed data stores
US10581617B2
( en )
2015-12-23
2020-03-03
Mcafee, Llc
Method and apparatus for hardware based file/document expiry timer enforcement
US20170187700A1
( en )
*
2015-12-28
2017-06-29
Paypal, Inc.
Pregenerated two-factor authentication tokens
US10880281B2
( en )
2016-02-26
2020-12-29
Fornetix Llc
Structure of policies for evaluating key attributes of encryption keys
US10860086B2
( en )
*
2016-02-26
2020-12-08
Fornetix Llc
Policy-enabled encryption keys having complex logical operations
US11063980B2
( en )
*
2016-02-26
2021-07-13
Fornetix Llc
System and method for associating encryption key management policy with device activity
US10469246B2
( en )
2016-02-29
2019-11-05
Craxel, Inc.
Efficient encrypted data management system and method
US20180006809A1
( en )
*
2016-07-01
2018-01-04
Intel Corporation
Data security in a cloud network
KR20190050997A
( en )
*
2016-09-12
2019-05-14
í ë í°ì í°ìë³¼ë¼ê²ìì ìë¦ì¨(í)
A method for secure link layer connection over a wireless local area network
US10523645B2
( en )
*
2016-10-21
2019-12-31
Thales Esecurity, Inc.
Method and system for protecting user data using individualized keys to enable secure compartmentalized data backup/restore
EP3340560A1
( en )
*
2016-12-22
2018-06-27
Mastercard International Incorporated
Mobile device user validation method and system
US10489307B2
( en )
*
2017-01-05
2019-11-26
Pure Storage, Inc.
Periodically re-encrypting user data stored on a storage device
US12282436B2
( en )
2017-01-05
2025-04-22
Pure Storage, Inc.
Instant rekey in a storage system
US11196720B2
( en )
*
2017-01-09
2021-12-07
Introspective Power, Inc.
Secure storage and data exchange/sharing system using one time pads
US11393046B1
( en )
*
2017-01-17
2022-07-19
Intuit Inc.
System and method for perpetual rekeying of various data columns with a frequency and encryption strength based on the sensitivity of the data columns
US10303895B1
( en )
2017-01-19
2019-05-28
Intuit Inc.
System and method for perpetual rekeying of various data columns with respective encryption keys and on alternating bases
JP6575547B2
( en )
*
2017-03-17
2019-09-18
å¯å£«ã¼ããã¯ã¹æ ªå¼ä¼ç¤¾
Document management system
US10469254B2
( en )
2017-03-29
2019-11-05
Intuit Inc.
Method and system for hierarchical cryptographic key management
US10491576B1
( en )
2017-06-16
2019-11-26
Intuit Inc.
System and method for security breach response using hierarchical cryptographic key management
US10438006B2
( en )
*
2017-07-27
2019-10-08
Citrix Systems, Inc.
Secure information storage
US11343243B2
( en )
*
2017-08-23
2022-05-24
Corsha, Inc.
Machine-to-machine streaming authentication of network elements
US10972445B2
( en )
*
2017-11-01
2021-04-06
Citrix Systems, Inc.
Dynamic crypto key management for mobility in a cloud environment
US10623186B1
( en )
*
2017-11-10
2020-04-14
Amazon Technologies, Inc.
Authenticated encryption with multiple contexts
CN108063756B
( en )
*
2017-11-21
2020-07-03
é¿éå·´å·´éå¢æ§è¡æéå ¬å¸
A key management method, device and device
US11012237B1
( en )
2018-01-09
2021-05-18
Jpmorgan Chase Bank, N.A.
Systems and methods for inter-service authentication
US11347868B2
( en )
*
2018-04-17
2022-05-31
Domo, Inc
Systems and methods for securely managing data in distributed systems
CN111902804B
( en )
2018-06-25
2024-03-01
é¿éå·´å·´éå¢æ§è¡æéå ¬å¸
Systems and methods for managing resources of storage devices and quantifying I/O request costs
CN109561071B
( en )
*
2018-10-29
2020-07-07
å京åè¡æåä¿¡æ¯ç§ææéå ¬å¸
Data flow control's external terminal protective equipment and protection system
US11546174B2
( en )
*
2018-12-11
2023-01-03
Apple Inc.
Wireless terminal authentication
US11061735B2
( en )
2019-01-02
2021-07-13
Alibaba Group Holding Limited
System and method for offloading computation to storage nodes in distributed system
US11200337B2
( en )
*
2019-02-11
2021-12-14
Alibaba Group Holding Limited
System and method for user data isolation
JP7300845B2
( en )
*
2019-02-15
2023-06-30
ä¸è±éå·¥æ¥æ ªå¼ä¼ç¤¾
Control device, industrial control system, and encryption key life extension method
US11341261B2
( en )
*
2019-04-05
2022-05-24
Spideroak, Inc.
Integration of a block chain, managing group authority and access in an enterprise environment
US10860223B1
( en )
2019-07-18
2020-12-08
Alibaba Group Holding Limited
Method and system for enhancing a distributed storage system by decoupling computation and network tasks
US11617282B2
( en )
2019-10-01
2023-03-28
Alibaba Group Holding Limited
System and method for reshaping power budget of cabinet to facilitate improved deployment density of servers
US11658823B1
( en )
*
2019-10-29
2023-05-23
Boris Reitman
End-to-end encryption based on a simple shared secret
US11343080B1
( en )
*
2019-11-17
2022-05-24
Norman J Bagley
System and method for data privacy and authentication
US11943293B1
( en )
*
2019-12-06
2024-03-26
Pure Storage, Inc.
Restoring a storage system from a replication target
CN111245832A
( en )
*
2020-01-13
2020-06-05
æ·±å³äºå¡ä¿¡æ¯ææ¯æéå ¬å¸
Encryption system and method for interfacing with cloud storage platform
US11449455B2
( en )
2020-01-15
2022-09-20
Alibaba Group Holding Limited
Method and system for facilitating a high-capacity object storage system with configuration agility and mixed deployment flexibility
US11379447B2
( en )
2020-02-06
2022-07-05
Alibaba Group Holding Limited
Method and system for enhancing IOPS of a hard disk drive system based on storing metadata in host volatile memory and data in non-volatile memory using a shared controller
US11449386B2
( en )
2020-03-20
2022-09-20
Alibaba Group Holding Limited
Method and system for optimizing persistent memory on data retention, endurance, and performance for host memory
US11573929B2
( en )
2020-04-09
2023-02-07
Kyndryl, Inc.
Deduplication of encrypted data using multiple keys
US11385833B2
( en )
2020-04-20
2022-07-12
Alibaba Group Holding Limited
Method and system for facilitating a light-weight garbage collection with a reduced utilization of resources
US11556277B2
( en )
2020-05-19
2023-01-17
Alibaba Group Holding Limited
System and method for facilitating improved performance in ordering key-value storage with input/output stack simplification
US11507499B2
( en )
2020-05-19
2022-11-22
Alibaba Group Holding Limited
System and method for facilitating mitigation of read/write amplification in data compression
CN112035853B
( en )
*
2020-08-13
2024-07-05
å京è²å¿å ç§ææéå ¬å¸
Storage data access control system based on enterprise cloud disk
US11368314B2
( en )
*
2020-11-13
2022-06-21
Microsoft Technology Licensing, Llc
Secure digital signing
US11487465B2
( en )
2020-12-11
2022-11-01
Alibaba Group Holding Limited
Method and system for a local storage engine collaborating with a solid state drive controller
US11734115B2
( en )
2020-12-28
2023-08-22
Alibaba Group Holding Limited
Method and system for facilitating write latency reduction in a queue depth of one scenario
US11726699B2
( en )
2021-03-30
2023-08-15
Alibaba Singapore Holding Private Limited
Method and system for facilitating multi-stream sequential read performance improvement with reduced read amplification
US20250023872A1
( en )
*
2021-10-20
2025-01-16
Cryptography Research, Inc.
Secure asset management infrastructure for enforcing access control policies
US12335387B2
( en )
*
2021-11-08
2025-06-17
Adobe Inc.
Distributing and synchronizing encrypted data for multi-regional accessibility
DE102021129282A1
( en )
*
2021-11-10
2023-05-11
EPLAN GmbH & Co. KG
Flexible management of resources for multiple users
CN115277075A
( en )
*
2022-06-22
2022-11-01
ä¸æµ·æ é£ä¿¡æ¯ææ¯æéå ¬å¸
Application data safe transmission method in self-service alarm system
EP4322470B1
( en )
2022-08-08
2025-03-12
Ostrean IT Technologies s.r.o.
Data encryption system and method
CN119766525A
( en )
*
2024-12-23
2025-04-04
ä¸å½äºå¶éå¢æéå ¬å¸
An encryption deduplication method supporting continuous update of file keys
Citations (13)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US6868160B1
( en )
*
1999-11-08
2005-03-15
Bellsouth Intellectual Property Corporation
System and method for providing secure sharing of electronic data
US20050238175A1
( en )
*
2004-04-22
2005-10-27
Serge Plotkin
Management of the retention and/or discarding of stored data
US20060168446A1
( en )
*
2002-09-13
2006-07-27
Pasi Ahonen
Secure broadcast/multicast service
US20070192832A1
( en )
*
2006-01-11
2007-08-16
Intel Corporation
Apparatus and method for protection of management frames
US20070250713A1
( en )
*
2006-03-06
2007-10-25
Rahman Shahriar I
Securing multiple links and paths in a wireless mesh network including rapid roaming
US20080065888A1
( en )
*
2006-09-07
2008-03-13
Motorola, Inc.
Security authentication and key management within an infrastructure based wireless multi-hop network
US7822712B1
( en )
*
2007-10-18
2010-10-26
Google Inc.
Incremental data warehouse updating
US20130203384A1
( en )
*
2012-02-07
2013-08-08
Partha Narasimhan
System and method for determining leveled security key holder
US20130283392A1
( en )
*
2011-12-08
2013-10-24
Mojtaba Mirashrafi
Method and apparatus for policy-based content sharing in a peer to peer manner using a hardware based root of trust
US20140075184A1
( en )
*
2012-09-11
2014-03-13
Microsoft Corporation
Trust services for securing data in the cloud
US20140229736A1
( en )
*
2011-09-28
2014-08-14
Koninklijke Philips N.V.
Hierarchical attribute-based encryption and decryption
US20140281477A1
( en )
*
2013-03-14
2014-09-18
Alex Nayshtut
Secure Cloud Storage and Encryption Management System
US20140344850A1
( en )
*
2011-10-28
2014-11-20
Irdeto B.V.
Constructing a transport stream
2014
2014-10-06
US
US14/507,720
patent/US9465947B2/en
not_active
Expired - Fee Related
Patent Citations (13)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US6868160B1
( en )
*
1999-11-08
2005-03-15
Bellsouth Intellectual Property Corporation
System and method for providing secure sharing of electronic data
US20060168446A1
( en )
*
2002-09-13
2006-07-27
Pasi Ahonen
Secure broadcast/multicast service
US20050238175A1
( en )
*
2004-04-22
2005-10-27
Serge Plotkin
Management of the retention and/or discarding of stored data
US20070192832A1
( en )
*
2006-01-11
2007-08-16
Intel Corporation
Apparatus and method for protection of management frames
US20070250713A1
( en )
*
2006-03-06
2007-10-25
Rahman Shahriar I
Securing multiple links and paths in a wireless mesh network including rapid roaming
US20080065888A1
( en )
*
2006-09-07
2008-03-13
Motorola, Inc.
Security authentication and key management within an infrastructure based wireless multi-hop network
US7822712B1
( en )
*
2007-10-18
2010-10-26
Google Inc.
Incremental data warehouse updating
US20140229736A1
( en )
*
2011-09-28
2014-08-14
Koninklijke Philips N.V.
Hierarchical attribute-based encryption and decryption
US20140344850A1
( en )
*
2011-10-28
2014-11-20
Irdeto B.V.
Constructing a transport stream
US20130283392A1
( en )
*
2011-12-08
2013-10-24
Mojtaba Mirashrafi
Method and apparatus for policy-based content sharing in a peer to peer manner using a hardware based root of trust
US20130203384A1
( en )
*
2012-02-07
2013-08-08
Partha Narasimhan
System and method for determining leveled security key holder
US20140075184A1
( en )
*
2012-09-11
2014-03-13
Microsoft Corporation
Trust services for securing data in the cloud
US20140281477A1
( en )
*
2013-03-14
2014-09-18
Alex Nayshtut
Secure Cloud Storage and Encryption Management System
Non-Patent Citations (1)
* Cited by examiner, â Cited by third party
Title
Liang Yan;Strengthen Cloud Computing Security with Federal Identity Management Using Hierarchical Identity-Based Cryptography; year: 2009; South China Normal University; p. 167-177.
*
Cited By (7)
* Cited by examiner, â Cited by third party
Publication number
Priority date
Publication date
Assignee
Title
US20160357971A1
( en )
*
2015-02-25
2016-12-08
Anand Sinha
Parallel and hierarchical password protection on specific document sections
US9773119B2
( en )
*
2015-02-25
2017-09-26
Sap Se
Parallel and hierarchical password protection on specific document sections
US10032035B2
( en )
2015-02-25
2018-07-24
Sap Se
Parallel and hierarchical password protection on specific document sections
CN107317823A
( en )
*
2017-08-01
2017-11-03
广ä¸äºä¸æ±éç§ææéå ¬å¸
Encryption method and system in a kind of cloud storage system
US10895994B2
( en )
*
2017-12-11
2021-01-19
International Business Machines Corporation
File access control on magnetic tape by encrypting metadata
US10931443B2
( en )
2018-08-23
2021-02-23
International Business Machines Corporation
Hierarchical key management based on bitwise XOR operations
US11290436B2
( en )
2018-09-21
2022-03-29
Cisco Technology, Inc.
Mechanism for encryption key distribution in computer networks
Also Published As
Publication number
Publication date
US20150186657A1
( en )
2015-07-02
Similar Documents
Publication
Publication Date
Title
US20150186657A1
( en )
2015-07-02
System and method for encryption and key management in cloud storage
US11909868B2
( en )
2024-02-20
Orthogonal access control for groups via multi-hop transform encryption
US11855767B2
( en )
2023-12-26
Methods and systems for distributing encrypted cryptographic data
Zhao et al.
2010
Trusted data sharing over untrusted cloud storage providers
US9137017B2
( en )
2015-09-15
Key recovery mechanism
CN102655508B
( en )
2015-03-04
Method for protecting privacy data of users in cloud environment
USH2270H1
( en )
2012-06-05
Open protocol for authentication and key establishment with privacy
<tr itemprop="similarDocuments" itemscope rep