RU2744970C2 - Systems and methods to control access to secure data - Google Patents

Abstract

FIELD: computer technology.

SUBSTANCE: invention relates to computer technology. A way to preserve an encrypted file with the help of chain blocks includes creating a cryptographic hash of the encrypted file; linking file permissions to a cryptographic hash; sending a transaction representing the cryptographic hash and file permissions from the client to the blockchain, with the block chain keeping the transaction to provide an audit trail for the encrypted document, while the audit trail maintains the integrity and security of the encrypted file without disclosing the contents of the encrypted file; transfer an encrypted file from the client to the server; encrypting an encrypted file with a secret key stored by a network of key servers; and storing the encrypted file by the server in a decentralized file system, with the decentralized file system identifying the encrypted file by a cryptographic hash.

EFFECT: technical result consists in upgrading security of access to protected data.

10 cl, 16 dwg

Description

BACKGROUND OF THE INVENTION

[001] A blockchain can be thought of as a finite state machine that has state (for example, permissions or balance of participants in the blockchain) and rules, as well as permissions to change this state (for example, exchange a token to change the balance) in accordance with a smart contract. ... Permits and smart contracts can be linked to something that exists in the real world, such as a bank account balance or the location of a shipping container. The data stored in the blockchain is public and tamper-proof because it cannot be changed except to comply with the smart contract rules that are enforced by many participants.

KNOWN TECHNOLOGY

[002] The applicant is not aware of any analogs.

SUMMARY OF THE INVENTION

[003] One problem with blockchain is the storage of secrets, in particular among multiple parties, in a way that does not violate distributed blockchain security guarantees. Secure Document Access Control System (SEDACS) can store secret data using distributed components including a secret vault, blockchain (proof of work or proof of authority), and content-addressable vault. The blockchain stores metadata, rules and permissions for every secret document; secrets used to access documents are distributed among key servers, which form a secret store; and documents are stored encrypted in distributed content-addressable storage. Validators (accompanying blockchains) enforce rules and permissions and record transactions associated with storing, accessing, and retrieving classified documents. For more details on enforcing rules and permissions and recording transactions, see Gavin Wood's article, “Ethereum: A Secure Decentralised Generalized Transaction Ledger,” available at gavwood.com/paper.pdf.

[004] The user stores the secret by first requesting one of the secret store's key servers to generate a new secret, which is the key used to encrypt the secret. The secret is stored in a distributed manner through a secret store. The authorized entity checks the blockchain to see if the user has permission to store the new secret. If so, then the authorized entity calls the method in the smart contract to store the new secret. For example, key servers can encrypt their parts of the secret and confirm that they hold the shared secret by sending transactions to the blockchain. Transactions create a log of control of user actions in the blockchain. If a user retrieves secret data, authorized subjects can send their respective encrypted pieces of secret data to the user with public keys for decryption using the corresponding private keys of the user.

[005] Since the data in the blockchain is public, the blockchain may store references to the secret data instead of the secret data itself. Such a link can be in the form of a hash, which is unique, a fixed length bit string created by applying a hash function to the file. Cryptographic hashing is reproducible but irreversible: the same input file will always generate the same hash, but each hash is difficult, if not impossible, to reverse, so the input file cannot be reproduced from its hash. The hash is unique; so the modified or encrypted version of the file has a different hash than the original file.

[006] SEDACS identifies secret files in the blockchain by the hashes of the secret files and stores the data using a file system such as the InterPlanetary File System (IPFS), which also identifies files by their hashes. The blockchain also stores the permissions and transactions associated with each hash: if the user has permission to the hash, then the user also has permission to the master data. By uniquely identifying a file by its cryptographic hash, the blockchain creates an audit trail without disclosing the contents of the file.

[007] It should be understood that all combinations of the above information and additional information described in more detail below (provided that such information provided is not mutually incompatible) are considered as part of the subject matter described herein. In particular, all combinations of the claimed subject matter presented at the end of this specification are contemplated as being part of the subject matter described herein. It should also be understood that the terminology unambiguously used in this document, which may also appear in any description given by reference, should correspond to the meaning most consistent with the specific information described in this document.

BRIEF DESCRIPTION OF THE GRAPHIC MATERIALS

[008] A person skilled in the art will understand that the drawings are primarily for illustrative purposes and are not intended to limit the scope of the subject matter described herein. Graphics are not necessarily drawn to scale; in some examples, various aspects of the subject matter described herein may be shown exaggerated or exaggerated in the figures to facilitate understanding of various features. In the drawings, like reference numbers generally refer to similar features (eg, functionally similar and / or structurally similar elements).

[009] FIG. 1 shows a Secure Document Access Control System (SEDACS).

[0010] FIG. 2A – 2F depict the process of storing a document in SEDACS.

[0011] FIG. 3A-3H depict the process of retrieving a document from SEDACS.

[0012] FIG. 4 shows the process of changing user permissions in SEDACS.

DETAILED DESCRIPTION OF THE INVENTION

[0013] FIG. 1 depicts SEDACS (Secure Data Access Control System), which provides secure data separation and permission management without a trusted third party. It leverages several new technologies including: blockchaining, smart contracts, threshold cryptography, distributed key generation, and content-addressable distributed file storage. Thanks to these new technologies, an unprecedented level of safety can be achieved. Unlike known solutions, there is not a single critical point and every action in the system can be recorded invariably in a block chain.

[0014] SEDACS contains two different types of nodes: (1) SEDACS servers (forming a trustless network), providing data storage and trust distribution, and (2) SEDACS clients, allowing users to access the system. The nodes in the network are connected to the blockchain and form part of the peer-to-peer network that is used to distribute transactions and blocks of the blockchain. In addition, servers can expose a View State Transfer (REST) interface to clients to upload and download encrypted data.

SEDACS client

[0015] As shown in FIG. 1, the SEDACS client can be implemented as a computing device with a processor, memory, network interface, and user interface (e.g., touch screen, traditional display, keyboard, touch pad, mouse, etc.). At runtime, the SEDACS client provides the Ethereum client, private key store, and SEDACS middleware. The Ethereum client provides interfacing to the blockchain. The private key store stores the user's private key (s) for accessing the stored documents. SEDACS middleware can be implemented as a JavaScript library that allows you to easily create user interfaces (UIs) that are served through a web browser and are suitable for a specific application. It manages communication between the local Ethereum client (and by extending smart contracts), the UI, and either the SEDACS servers or directly the key servers and IPFS nodes.

[0016] the UI can allow users to create a new account, manage permissions, and upload and view data. Any other functionality that leverages smart contracts effectively can be integrated into the UI. Each piece of functionality can obey the appropriate permissions as needed, and can leave an unchanged trace in the audit trail.

Vault of secrets

[0017] A secret store is a network of key servers that have the ability to generate secret keys in a distributed manner, store secrets in a distributed manner (store a partial secret), and assemble encrypted parts of the secret based on blockchain permissions. The generation of a secret for a given hash can be triggered by making a request to one of the key servers. After the secret is generated, the user requesting the secret sets the threshold number of servers needed to retrieve. The retrieval of the secret for a given hash is initiated by making a request to one of the key servers. In response to the request, the keyserver communicates with other keyservers about the requester's blockchain permissions to access the hash. If a threshold number of keyservers agree on permissions, then the keyservers send their partial secrets encrypted with the public key to the requester. Each request to generate and retrieve a secret can be recorded on the blockchain.

SEDACS Server

[0018] The SEDACS Server is a way to combine several different components that form a distributed network. The SEDACS server network is a combination of blockchain, secret store, and distributed file system.

[0019] Each participating party must run at least one SEDACS server to provide security through trust distribution. The SEDACS server can be packaged as a Docker Compose solution, optionally hosted by Parity Technologies. This simplifies blockchain processing distribution, secret storage, and encrypted document storage.

[0020] As shown in FIG. 1, the SEDACS server can be implemented as a computing device with a processor, memory, and user interface (eg, touch screen, traditional display, keyboard, touch pad, mouse, etc.). At runtime, the SEDACS server can provide a SEDACS connector, Ethereum client, key server, and an IPFS node. The SEDACS connector can interface directly with the client using the SEDACS middleware. The Ethereum client provides interfacing to the blockchain. The secret vault key server stores partial secrets for encrypting documents. And IPFS stores encrypted documents.

SEDACS properties

● The blockchain is the only source of permissions.

● Each document insertion, document retrieval and permission change can be recorded along with the authorization of the subject in the blockchain, with the cryptographic database providing strong guarantees regarding tamper resistance and uptime.

● Documents are stored and transmitted in securely encrypted form (for example, SECP256k1 ECIES).

● Users receive documents encrypted with their public key.

● Documents are identified by a cryptographic insert (hash) of their content, which means that the modified document is considered a different document from the corresponding original document.

Saving a file to SEDACS

[0021] FIG. Figures 2A – 2G show the process of saving a file to SEDACS from the SEDACS client. Some of the steps in this process involve encrypting and transferring the file, while other steps create portions of the audit trail that maintains the integrity and security of the file and system.

[0022] The process can be performed in two different ways, depending on whether the SEDACS client has access to the IPFS node or the SEDACS server.

Saving a File to SEDACS Using SEDACS Server

[0023] In step 1, the user submits the transaction to the blockchain using the individual private key from the client's private key store. The public key associated with the private key describes the permissions associated with the encrypted file. In step 2, the user encrypts the file with the public key of the SEDACS server using the client side SEDACS middleware. In step 3, the user sends the encrypted file directly to the SEDACS server through the SEDACS middleware.

[0024] In step 4, the SEDACS connector receives the encrypted file from the SEDACS client. It also validates the blockchain for the related transaction. In step 5, SEDACS requests the secret from the secret store and uses it to encrypt the file. And in step 6, the SEDACS server saves the encrypted file to IPFS. It also sends another transaction to the blockchain confirming the receipt and storage of the encrypted file.

Saving a file directly to SEDACS

[0025] In step 1, the user submits the transaction to the blockchain using the individual private key from the client's private key store. The public key associated with the private key describes the permissions associated with the encrypted file. In Phase 2, the SEDACS middleware requests the secret from the secret store and then encrypts the file with it. Then, in step 3, the file can be inserted directly into IPFS.

Extracting a file from SEDACS

[0026] FIG. 3A-3H depict the process of retrieving a file to a SEDACS server from a SEDACS client using the system shown in FIG. 1. In step 1, the user uses the SEDACS client to view the current document permissions. If the user has permission to check out the document, the SEDACS client sends the transaction requesting the document to the blockchain in step 2. In step 3, the SEDACS middleware sends a request to the SEDACS server for the document itself, or fetches the encrypted file directly from IPFS.

[0027] Further steps 4-7 are used if the user does not start the IPFS node. In step 4, the SEDACS server checks the blockchain against the document retrieval transaction. It retrieves the document from IPFS in step 5. And in step 6, the SEDACS server sends the encrypted document along with the encrypted partial secrets to the client and sends a transaction confirming the retrieval and transfer of the document to the blockchain.

[0028] In step 7, the SEDACS client obtains the encrypted document and secret from the SEDACS server. In step 8, the secret is decrypted using the user's private key and used to decrypt the document on the SEDACS client side.

[0029] As noted above, the SEDACS middleware can retrieve the encrypted file directly from the IPFS in step 3. In this case, the SEDACS middleware requests the secret directly from one of the key servers in the secret store, rather than from the SEDACS server. The SEDACS client decrypts the secret using the user's private key and uses it to decrypt the document on the SEDACS client side, as in step 8.

Change file permissions

[0030] If the user has the appropriate permissions for the document stored in SEDACS, the user can change the permissions of the document by sending a transaction to the blockchain requesting the permission change, as shown in FIG. 4. The transaction is then triggered by one of the authorized subjects of the blockchain, representing a permission modification. SEDACS middleware provides instant response when a transaction is enabled.

Conclusion

[0031] While various embodiments of the present invention have been described and depicted herein, those skilled in the art can easily envision various other means and / or structures for performing a function and / or obtaining results and / or one or more of the advantages described in herein, and each of such variations and / or modifications is considered to fall within the scope of the embodiments of the present invention described herein. In general, it will be clear to those skilled in the art that all parameters, dimensions, materials and configurations described herein are to be understood as exemplary, and that actual parameters, dimensions, materials and / or configurations will depend on the particular application or applications. for which the principles of the present invention are used. Those skilled in the art will find, or can be convinced by mere routine experimentation, many equivalents to specific embodiments of the present invention described herein. Thus, it should be understood that the above embodiments are provided by way of example only and that, within the scope of the appended claims and their equivalents, the embodiments of the present invention may be applied other than as specifically set forth in the description and claims. Embodiments of the present invention are directed to each individual feature, system, article, material, kit, and / or method described herein. In addition, any combination of two or more such features, systems, products, materials, kits and / or methods, unless such features, systems, products, materials, kits and / or methods are mutually incompatible, falls within the scope of the present invention.

[0032] Moreover, various concepts of the present invention may be implemented as one or more methods, an example of which has been given. The actions performed as part of the method can be ordered in any suitable manner. Accordingly, embodiments can be created in which actions are performed in an order that differs from that depicted, which can include performing multiple actions at the same time, although in illustrative embodiments, the actions are performed in turn.

[0033] All definitions as defined and used herein are to be understood to take precedence over dictionary definitions, definitions from documents incorporated by reference, and / or the usual meanings of certain terms.

[0034] The singular words used in the description and the claims of this document, unless clearly indicated otherwise, should be understood as meaning "at least one".

[0035] The phrase "and / or" as used in the description and claims of this document should be understood to mean "one of or both" of the elements so linked, that is, elements that in some cases are present together, and in other cases, they are present separately. The plurality of items listed with “and / or” are to be understood in a similar manner, that is, “one or more” of the items linked in this way. Other elements may not necessarily be represented differently than those specifically indicated by the phrase "and / or", whether or not they are related or unrelated to those specifically indicated elements. Thus, as a non-limiting example, a reference to "A and / or B" when used in conjunction with words implying an open list, such as "containing", may refer, in one embodiment, only to A (optionally including the elements other than B); in another embodiment, only to B (optionally including elements other than A); in yet another embodiment, both A and B (optionally including other elements); etc.

[0036] As used in the description and claims of this document, it is intended that "or" has the same meaning as "and / or" as defined above. For example, when separating elements in a list, “or” or “and / or” should be understood to include, i.e., the inclusion of at least one, but also the inclusion of more than one, from a number or list of elements, and optional additional unlisted items. Only terms that clearly indicate the opposite, such as "only one of" or "exactly one of", or, when used in the claims, "consisting of", will refer to the inclusion of only one element from any number or list of elements ... In general, the term “or” as used herein should only be understood to indicate exclusionary alternatives (ie, “one or the other, but not both”) when preceded by exclusivity terms such as “ each ”,“ one of ”,“ only one of ”, or“ exactly one of ”. When used in claims, the expression "consisting essentially of" should carry its usual meaning as is commonly used in the field of patent law.

[0037] As used in the description and claims of this document, the phrase "at least one", with reference to a list of one or more elements, should be understood as at least one element selected from any one or more elements from the list of elements but does not necessarily include at least one of all, without exception, elements specifically specified in the list of elements, and does not exclude any combination of elements from the list of elements. Such a definition also allows other elements to optionally be present in addition to those specifically indicated in the list of elements referenced by the phrase “at least one”, whether or not they are associated with those specifically indicated elements. Thus, as a non-exclusive example, “at least one of A and B” (or equivalently “at least one of A or B”, or equivalently “at least one of A and / or B”) may be referred to in in one embodiment, at least one, optionally including more than one, A in the complete absence of B (and optionally including other elements than B); in another embodiment, at least one, optionally including more than one, B in the complete absence of A (and optionally including other elements than A); in yet another embodiment, at least one, optionally including more than one, A, and at least one, optionally including more than one, B (and optionally including other elements); etc.

[0038] In the claims, as in the description above, all intermediate phrases such as “containing”, “including”, “bearing”, “having”, “covering”, “touching”, “containing”, “ consisting of ", etc. are to be understood as having an open list, that is, they have an inclusive meaning, but are not limited to it. Only the intermediate phrases “consisting of” and “consisting essentially of” will be closed or semi-closed-listed intermediate phrases, respectively, as specified in the US Patent Office Examination Procedures Manual, Section 2111.03.

Claims (35)

1. A method for saving an encrypted file using a blockchain, including: creating a cryptographic hash of an encrypted file; linking file permissions to a cryptographic hash; sending a transaction representing the cryptographic hash and file permissions from the client to the blockchain, while the blockchain stores the transaction to provide a control log for the encrypted document, while the control log maintains the integrity and security of the encrypted file without exposing the contents of the encrypted file; transferring an encrypted file from a client to a server; encrypting the encrypted file with a secret key held by a network of key servers; and the server storing the encrypted file in the decentralized file system, while the decentralized file system identifies the encrypted file by a cryptographic hash. 2. The method according to claim 1, further comprising: view the file permissions stored in the blockchain; determining that the user can check out the file based on the permissions of the file; sending a transaction from the client requesting an encrypted file to the blockchain; and receiving on the client side the encrypted file and the public key to decrypt the encrypted file from the server connected to the blockchain. 3. The method according to claim 2, further comprising client-side decryption of the encrypted file using the public key and the private key held by the client. 4. The method of claim 1, wherein transferring the encrypted file comprises transferring the encrypted file to the host by means of middleware connecting the client and the host. 5. The method according to claim 1, further comprising: setting a threshold number of key servers required to retrieve the secret to encrypt the encrypted file; and obtaining a secret from the network of keyservers in response to a threshold number of keyservers agreeing on file permissions. 6. A method for saving an encrypted file using a blockchain, including: creating a cryptographic hash of an encrypted file; linking file permissions to a cryptographic hash; sending a transaction representing the cryptographic hash and file permissions from the client to the blockchain, while the blockchain stores the transaction to provide a control log for the encrypted document, while the control log maintains the integrity and security of the encrypted file without exposing the contents of the encrypted file; encrypting the encrypted file with a secret key held by a network of key servers; and storing an encrypted file in a decentralized file system, whereby the decentralized file system identifies the encrypted file by a cryptographic hash. 7. The method according to claim 6, further comprising: view the file permissions stored in the blockchain; determining that the user can check out the file based on the permissions of the file; sending a transaction from the client requesting an encrypted file to the blockchain; and receiving on the client side the encrypted file and the public key to decrypt the encrypted file from the server connected to the blockchain. 8. The method according to claim 7, further comprising: client-side decryption of the encrypted file using the public key and the private key held by the client. 9. The method of claim 6, wherein transferring the encrypted file comprises transferring the encrypted file to the host by means of middleware connecting the client and the host. 10. The method according to claim 6, further comprising: setting a threshold number of key servers required to retrieve the secret to encrypt the encrypted file; and obtaining a secret from the keyserver network in response to a threshold number of keyservers agreeing on file permissions.

Images