RU2782153C2 - Method and system for organization of protected information exchange, using blockchain technology and distributed data storage systems - Google Patents

Abstract

FIELD: information protection.

SUBSTANCE: invention relates to a method and a system for organization of protected information exchange, using a blockchain technology and distributed data storage systems. In the method, a name of a database is entered, while additionally entering a password to this database. The presence of the database on a device is checked. In case of the presence of the database, it is decrypted using symmetric AES-256 encryption, the correctness of a database file is checked. In case of the absence of the database, a new database is created, while forming a password to the new database, required to encrypt and decrypt a file with the new database, using the AES-256 algorithm. The work with the database is completed, while, after checking for the correctness of the database file or after creating a new database, network services are launched, at least a client for requests from a central server for an up-to-date list of IP addresses on a network and sending a “hello message” is launched. A request processing server is launched to receive a hash of the last transaction and an up-to-date copy of the blockchain. A transaction processing server is launched to participate in the consensus process. After that, transaction hashes are requested from servers of all IP addresses available on the network. The current hash of the last transaction is selected according to the majority rule. A request is made to receive an up-to-date copy of the blockchain from one of senders of the current hash of the last transaction. An algorithm for analyzing the received up-to-date copy of the blockchain is launched. A list of added users is displayed. At least one of functions is selected: addition of a new user, view of the history of correspondence with the specified user and sending to this user of a text message, view of the history of correspondence with the specified user and sending to this user of a text file up to 1 KB in size, update of an encryption key for the specified user, sending of a file to a distributed storage, request for a file from the distributed storage, update of an information display interface, safe logout of a system, which the system needs to perform. The fact that the safe logout function is selected is checked. If this function is not selected, then, the selected function is performed, while, after performing the selected function, a new function is selected. If the safe logout function is selected, then, the database is encrypted using the previously entered password, using the AES-256 algorithm.

EFFECT: provision of protected information exchange.

10 cl, 14 dwg

Description

Technical field

The invention relates to the field of information security, in particular, to methods for the confidential transmission of information using distributed data storage systems and blockchain technology.

State of the art

Modern technologies possessed by large IT companies, for example, owners of popular free instant messaging systems - instant messengers and applications for sharing photos and videos with elements of social networks, allow you to track various information about users: social circle, interests, request history, history messages, etc. In this regard, it can be argued that there is a theoretical possibility of spoofing correspondence, as well as sending messages from usernames. This thesis is based on the fact that part of the source code of the above applications is closed, and companies' statements about the use of "end-to-end", i.e. End-to-end encryption does not exclude the possibility of collecting user data, including personal messages, audio and video conversations, etc. Also, these companies have the ability to block users. In addition, the possibility of hacking the central server, and as a result of data leakage, such as, for example, photos of user documents, bank card numbers, passwords, etc., cannot be ruled out. Provided that users are authenticated through a mobile phone number, there is also no need to talk about anonymity. Considering all of the above, it is safe to say that the use of classic messengers and social networks, based on the architecture of which are centralized data processing servers, does not ensure the anonymity of users and does not guarantee the confidentiality of personal data.

Improving the security of communications between Internet users and their anonymization is possible by creating an open source messenger using blockchain technology and a distributed data storage system, as well as a theoretically indecipherable (TNDS) system for encrypting information.

For the convenience of describing the method and system of secure information exchange using blockchain technology and distributed data storage systems, we introduce a number of definitions.

Blockchain is a continuous sequential chain of blocks containing information built according to certain rules (see https://ru.wikipedia.org/wiki/Blockchain).

Mining is the activity of creating new structures, usually new blocks in the blockchain, to ensure the functioning of cryptocurrency platforms (see https://ru.wikipedia.org/wiki/Mining).

Miner - an object participating in mining (see https://ru.wikipedia.org/wiki/Miner).

A hash function is a function that converts an array of input data of arbitrary length into an output bit string of a set length, performed by a certain algorithm (see https://ru.wikipedia/org/wiki/Hash function).

Hash (Hash sum) - the value of the hash function (see https://ru.wikipedia.org/wiki/Hash).

A transaction is a group of sequential operations with a database, which is a logical unit of work with data (see https://ru.wikipedia/org/wiki/Transaction_(computer science)).

Messenger - instant messaging services, online consultant programs and client programs for real-time messaging over the Internet (see https://ru.wikipedia/org/wiki/Instant_messaging_system).

Proxy server - an intermediate server or a set of programs in computer networks that acts as an intermediary between the user and the target server, while mediation may or may not be known to both parties, allowing clients to both make indirect requests, receiving and transmitting them through a proxy -server, to other network services, and receive responses (see https://ru.wikipedia.org/wiki/Proxyserver).

A Virtual Private Network (VPN) is a technology that extends a private network over the public Internet and allows users to send and receive data over public or public networks as if their computing devices were connected to a private network. https://en.wikipedia.org/wiki/Virtual_private_network).

Meta information (metadata) - information about other information, or data related to additional information about the content or object (see https://ru.wikipedia.org/wiki/Metadata).

Consensus - making a decision based on general agreement without a vote, if no one opposes it, or with the exception of the opinion of a few dissenting participants (see https://ru.wikipedia.org/wiki/Consensus).

Under the majority rule for choosing a decision by voting, we mean the rule according to which the decision that receives the majority of votes is considered elected.

By a link file we mean a file generated by the proposed system that contains a part of the encrypted source target file, links to servers that store the remaining parts of the encrypted source target file, as well as the necessary meta-information to correctly assemble the file when this file is requested from the distributed storage.

Under the global blockchain, we mean the version of the blockchain that is in the possession of the majority of participants in the blockchain communication at the current time.

There is a known method and system "Method and system for storage and retrieval of blockchain blocks using galois fields" (patent US 9569771 B2 dated 03.11.2016), including one or more blocks of the blockchain, which are stored and retrieved using modified Galois fields in a cloud or peer-to-peer (for example, P2P) communication network. The modified Galois field provides, at a minimum, additional layers of security and privacy for blockchains.

There is a known method "Method and system for distributed storage of recoverable data while ensuring the integrity and confidentiality of information" (patent RU 2680350 C2 dated February 19, 2019), which consists in replacing a failed node that stores data related to part of the data file, whereby each of the plurality of available data storage nodes receives an instruction from the control unit to replace the failed node with a new data storage node, each of the available data storage nodes contains a set of checksums generated from the data file, which can be generated based on parts of the data file using erasure coding techniques, wherein a replacement checksum is generated at each of the many available storage nodes by creating a linear combination of checksums at each storage node using random coefficients, these replacement checksums are then used to recover the lost an explicit data file, characterized in that each of the available data processing units with the corresponding data storage nodes contains a set of data formed from files corresponding to the data processing units with data storage nodes, while the set of data is previously subjected to a block encryption procedure with non-linear bijective transformations, and the generated set of blocks of cryptograms of data processing units with data storage nodes is distributed among the available data storage nodes, in which, using the methods of multivalued error-correcting coding, the corresponding set of redundant data is formed, then the blocks of cryptograms received from other data processing units with data storage nodes are removed in order to reducing the overall redundancy, while the generated set of redundant data with blocks of cryptograms of the data processing unit with the data storage node that generated them is used to restore the lost files data files, while the data recovery unit receives information from the control unit regarding which data processing units with the corresponding data storage nodes are currently available and, accordingly, have a lot of information and redundant file data, then the data recovery unit receives a lot of information and redundant data from the specified data processing units with data storage nodes, the data recovery unit performs a complete recovery of lost data files, the data restored by the data recovery unit, together with the data of the available data processing units with the corresponding data storage nodes, is transferred to the newly introduced data processing unit by the control unit with a data storage node to form blocks of redundant data.

The closest in technical essence to the claimed method and system is "Discrete blockchain and blockchain communications" (patent WO 2019/195691 A1 dated 10/10/2019), which consists in the fact that they encrypt and decrypt signals between devices to ensure that messages using blockchain technology can only be discovered by designated third parties or not at all. To keep the network running, miners are needed - network participants with high levels of computing power that compete to confirm transactions by computing transaction hashes. In this method, various types of practically indecipherable symmetric encryption and asymmetric encryption systems (PNDS) can be used, and "Data security" (patent US 2005/0081048 A1 dated April 14, 2005), which consists in the fact that they encrypt at least one key, at least one or more parts of the input data to generate at least one or more corresponding parts of the output data, which will be stored in one or more storage locations, and can also create checks on at least one or more corresponding parts of the output data. data to be stored in a storage or multiple storages located in a storage device.

The technical problem of these analogues and prototypes is the threat of compromise of address information and user data stored in the blockchain, as well as the threat of identifying senders and recipients of files in distributed data storage systems.

The reasons why this might happen are:

- in the considered analogues, it is assumed that the information in the blockchain is either open or encrypted using asymmetric encryption or symmetric encryption using PNDS systems, which ultimately does not guarantee the absolute resistance of information to decryption;

- the ability to collect statistical information about the transmitted traffic in communication channels, which can lead to the compromise of senders and recipients of files in a distributed data storage system, as well as the ability to collect all parts of an encrypted file and, consequently, to decrypt it.

The technical result is that the present invention is aimed at preventing the threat of compromise of address information and user data stored in the blockchain through the use of a distributed data storage system in which part of the data from files intended to be sent to remote data storages is stored on a local storage device. At the same time, false parts of these files are generated, which makes it possible to exchange transactions in blockchain communications encrypted using the TNDS system, thereby excluding the possibility of unambiguous decryption of transactions. All files sent to the distributed storage, including keys for TNDS systems, are pre-encrypted using the aes-256 algorithm in cipher feed back mode (CFB), in which each part of the encrypted data depends on the other, which excludes the ability to decrypt a file in the absence of any part of the encrypted file.

Another technical result is the solution of the technical problem of compromising information about senders and recipients of files in a distributed data storage system due to the fact that when sending a file to a distributed data storage, the device participating in the blockchain communication encrypts the file using symmetric encryption using the PNDS system using the algorithm aes-256 in CFB mode. At the same time, a distributed data warehouse can consist of any third-party data stores. The sent file is split into several parts, false parts are introduced, files are mixed before sending, each file that contains a part of the encrypted file or a false part of the file is assigned the servers on which these files will be stored. The above measures, on the one hand, greatly complicate the task of collecting statistics on sent files, and on the other hand, guarantee the impossibility of decrypting files stored in a distributed storage system. In order to make it impossible to determine the sender and recipient of parts of the encrypted file, all connections are made either through IP address spoofing mechanisms, or through Proxy servers, or through VPN.

Disclosure of invention

In the claimed method, this technical problem is solved by the fact that in the method of organizing a secure exchange of information using blockchain technology and distributed data storage systems, which consists in entering the name of the database, entering the password for this database, checking the presence of the database on the device, if there is a database, it is decrypted using symmetric encryption, the correctness of the database file is checked, if there is no database, a new database is created, and a password for the new database is generated, which is necessary for encrypting and decrypting the new database file using the aes-256 algorithm , exit the database. Additionally, after checking the correctness of the file with the database, or after creating a new database, network services are launched, at the same time, at least, the client is launched to query the central server for an up-to-date list of IP addresses on the network and send a "hello" message, the server is launched processing requests for a hash of the last transaction and an up-to-date copy of the blockchain, start the transaction processing server, namely, to participate in the consensus process. After starting the network services, transaction hashes are requested from the servers of all IP addresses available on the network, the current hash of the last transaction is selected by the majority rule, a request is made to receive the current copy of the blockchain from one of the senders of the current hash of the last transaction. Run the algorithm for analyzing the received current copy of the blockchain and display a list of added users. They select one of the functions: adding a new user, viewing the history of correspondence with the specified user and sending a text message to this user, viewing the history of correspondence with the specified user and sending this user a text file up to 1 KB in size, updating the encryption key for the specified user, sending the file to distributed storage, requesting a file from distributed storage, updating the information display interface, a safe logout that the system needs to perform. The fact that the secure logout function is selected is checked, if this function is not selected, then the selected function is executed, and after the selected function is executed, a new function is selected, if the secure logout function is selected, then the database is encrypted using previously entered password using the aes-256 algorithm.

According to one of the private implementation options, when starting the server for processing requests to obtain the hash of the last transaction and the current copy of the blockchain, the request processing server receives messages from the client with the request. The type of the request is checked by the server, if a request is received to obtain the hash of the last transaction of the server blockchain copy, then the hash of the last transaction is retrieved from the database, if a request is received to obtain the current copy of the server blockchain, then the current copy of the server blockchain is retrieved from the database. The correct message is formed to be sent to the client, taking into account the characteristics of the information extracted from the database, and the generated response is sent to the client.

According to one particular implementation, when the transaction processing server starts up, the transaction processing server receives transactions from the client. The ID offered by the client and the hash of the last transaction from the local copy of the client's blockchain are extracted from the transaction. The last ID of the local copy of the blockchain of the transaction processing server is checked, and the ID must be one less than that offered by the client. The correctness of the ID is checked, if the check gave a negative result, then a message is sent to the client about the refusal by this transaction processing server to confirm the transaction received from the client. If the verification is successful, then the hash of the last transaction of the local copy of the client's blockchain, contained in the transaction sent by the client, and the hash of the last transaction of the local copy of the transaction processing server's blockchain are checked. In this case, the hash must match, if the hash does not match, then a message is sent to the client about the refusal by this transaction processing server to confirm the transaction received from the client. If the hash matches, then a response with a positive decision is sent to the client, confirming the transaction received from the client by this transaction processing server. They add the transaction received from the client by the transaction processing server to their local copy of the blockchain. Run the content analysis algorithm for incoming messages from one of the added users on this transaction processing server.

According to one of the private implementation options, when starting the content analysis algorithm for incoming messages from one of the added users on the transaction processing server, the encrypted part of the transaction is extracted from the entire transaction by extracting the ID offered by the client and the hash of the last transaction from the client copy of the blockchain. The private part of the transaction is decrypted by overlaying the key of each user added by the transaction processing server to the encrypted part of the transaction, taking into account the key offset, while the encrypted part of the transaction is decrypted only if the sender field, which is also encrypted, contains the name of the user on whose key the decryption is performed, and the recipient field will be the name of the user whose transaction processing server is decrypting this transaction. Check whether it was possible to decrypt the message on one of the keys of the added users. If it succeeds, then the decrypted part of the transaction is divided into logical elements at least, the time of sending, the name of the sender, the name of the recipient, the transmitted message, which can be either a text file up to 1 KB in size, or a text message, and entered into the local database transaction processing server in open form. If it was not possible to decrypt the message on one of the keys of the added users, then the transaction is not intended for the user of this transaction processing server.

According to one of the private implementation options, when executing a request to obtain an up-to-date copy of the blockchain, the previous local copy of the blockchain is deleted from the database and the copy of the local blockchain is written to the database received from the server for processing requests to obtain the hash of the last transactions and the actual copy of the blockchain. Check the number of transactions of the previous local copy of the blockchain with the accepted copy. If the previous local copy of the blockchain has more transactions than the accepted copy, then the global blockchain has been updated, while resetting the key offsets for all added users. In the case when the update of the global blockchain did not occur, then the key offset values for all added users are left unchanged. Each transaction is analyzed for the presence of incoming messages, while extracting the encrypted part of the transaction from the entire transaction by extracting the ID offered by the client and the hash of the last transaction from the client copy of the blockchain. The private part of the transaction is decrypted by overlaying the key of each user added by the transaction processing server to the encrypted part of the transaction, taking into account the key offset, while the encrypted part of the transaction is decrypted only if the sender field, which is also encrypted, contains the name of the user on whose key the decryption is performed , and the recipient field will be the name of the user whose transaction processing server is decrypting this transaction.

According to one of the private implementation options, in which one of the functions is selected: adding a new user, while entering the name of the new user and specifying the path to the file with the key for this user, viewing the history of correspondence with the specified user and sending a text message to this user, viewing the history correspondence with the specified user and sending this user a text file up to 1 KB in size, updating the encryption key for the specified user, sending the file to distributed storage, requesting a file from distributed storage, updating the interface for displaying user information, safe logout that the system needs to perform.

According to one of the private implementation options, when requesting to send a file to a distributed storage, the path to the source file is entered. The source file is encrypted with the Advanced Encryption Standard encryption algorithm with a key length of 256 bits, i.e. aes-256, in the feedback gamma mode, while the encryption key is placed in the link file. The hash of the encrypted file is calculated, and the hash is placed in the link file. The encrypted file is split into N parts, which are separate files, of random size, while all meta-information and one of the N parts of random size, which is not sent to the network, is placed in the link file. K false parts are added, while all meta-information is placed in the link file. Each of (N-1+K) files of R servers in a distributed data storage system is assigned and a hash of each of these files is calculated, with all meta-information being placed in a link file. Mix (N-1+K) files, while all meta-information is placed in the link file. Each of the (N-1+K) files is sent to R servers in a distributed storage system using proxy servers, VPN or IP address spoofing system. Form the final version of the link file.

According to one of the private implementation options, when requesting a file from a distributed storage, the path to the link file to the source file is entered, meta-information about the source file is extracted from the link file: the number of parts into which the source file was split, the number of false parts, file names on remote servers, rules for mixing files before sending, IP addresses of file storage servers, encryption key on which the entire file is encrypted, hashes of parts of the file, hash of the entire file; request parts of files from the servers using Proxy servers, VPN or IP address spoofing system, check the hashes of the parts of the file in such a way that if at least one correct copy of each part of the file came from the servers in the distributed storage system and its hash is correct, then go to the next step, if at least one condition is not met, then give an error message and stop collecting the source file, mix the received parts of the file, separate the false parts of the file, assemble the encrypted source file, check the hash of the entire encrypted file, if the check is negative, then they issue an error message and stop collecting the source file, if the check was successful, then the encrypted file is decrypted.

According to one of the private implementation options, when viewing the history of correspondence with the specified user and sending him a text message, the previous correspondence with the given user from the database is displayed. Enter a new message for the user and add to the message at least the time the message was sent, the sender's name field, the recipient's name field. These fields are encrypted on the key of the given user. The ID of the last transaction is retrieved from the database and this value is increased by one. Form a new ID for the transaction. The hash of the last transaction of the local copy of the sender's blockchain is retrieved from the database. In this case, the hash of any transaction, except for the first one, is formed by calculating a hash from two values: the hash of the transaction recorded in the local copy of the sender's blockchain before the current transaction and the current transaction in the local copy of the sender's blockchain. A transaction is created for transmission, which includes a new ID, a hash of the last transaction of the local copy of the sender's blockchain, and encrypted data encrypted in the Vernam cipher using the user's key. Therefore, provided that the user key is represented as a one-time pad consisting of a random set of bits and each message has its own sequence of key bits, which cannot be reused later as a key for another message, then it can be argued that the condition for the TNDSH encryption system is satisfied. They send a generated transaction to all available IP addresses from the list of current IP addresses sent by the central server located in the system we are considering. They receive from all available IP addresses from the list of current IP addresses sent by the central server located in the system under consideration, a response about the readiness of confirmation of the generated transaction by the transaction processing servers. According to the majority rule, the fact of confirmation of the transaction is checked, if the verification was not successful, then the request for the current copy of the blockchain is performed, if the verification was successful, then the transaction is added to the local copy of the sender's blockchain. A field is added in unencrypted form - the time the transaction was sent, a field - the name of the sender, a field - the name of the recipient and the message to be sent to the database. The key is shifted for the given user by the length of the encrypted data.

A new set of essential features allows you to achieve the technical result of the impossibility of compromising senders and recipients of files in a distributed storage system due to the fact that when you request to send a file to a distributed storage, you enter the path to the source file, encrypt the source file using the "Advanced Encryption Standard" encryption algorithm with key length is 256 bits in CFB feedback gamma mode, while the encryption key is placed in the link file, the hash of the encrypted file is calculated, the hash is placed in the link file, the encrypted file is split into N parts (files) of random size, while all meta-information and one of N parts of random size that is not sent to the network is placed in the link file, K false parts are added, while all meta-information is placed in the link file, assigned to each of the (N-1 + K) files of R servers in the distributed storage system and calculate the hash of each of these files, with all meta-information placed put into a link file, mix (N-1 + K) files, while all meta-information is placed in a link file, send each of the (N-1 + K) files to R servers in a distributed data storage system using the IP spoofing mechanism -addresses, either through Proxy servers or through VPN, form the final version of the link file; when requesting a file from a distributed storage, enter the path to the file-link to the source file, extract meta-information about the source file from the link file: the number of parts into which the source file was split, the number of false parts, file names on remote servers, rules for mixing files before sending, the IP addresses of the file storage servers, the encryption key on which the entire file is encrypted, the hashes of the parts of the file, the hash of the entire file, request parts of the files from the servers using the IP address spoofing mechanism, either through Proxy servers or through VPN, check hashes of the file parts, taking into account the fact that if at least one copy of each part of the file is received from the servers in the distributed data storage system and its hash has been checked for correctness, then go to the next step, if at least one condition is not met, then a message is displayed about an error and stop collecting the source file, shuffle the received parts of the file, separate the false parts of the file, assemble the encrypted about the source file, check the hash of the entire encrypted file, if the check is negative, then issue an error message and stop collecting the source file, if the check was successful, then decrypt the encrypted (received) file.

In the claimed system, this problem is solved by the fact that in the system for organizing secure information exchange using blockchain technology and distributed data storage systems, consisting of at least one central server, including a module for receiving / transmitting information in a communication network for receiving and transmitting data over channels communication, a common information exchange bus for exchanging information between device modules, a "hello-message" processing module for receiving "hello-messages" from devices participating in the blockchain communication and updating the current list of currently available IP addresses in the network, the module processing requests for obtaining an up-to-date copy of the list of currently available IP addresses on the network to send an up-to-date list of currently available IP addresses on the network upon request, a memory module for storing an up-to-date list of currently available IP addresses on the network, device power supply module to provide power to all device modules wa and at least three devices participating in blockchain communication, including a module for receiving / transmitting information in a communication network for receiving and transmitting data via communication channels, a common information exchange bus for exchanging information between device modules, a module for sending requests to servers for sending requests to servers for processing requests to receive a hash of the last transaction and an up-to-date copy of the blockchain and to transaction processing servers, a client module for inquiring the central server for an up-to-date list of IP addresses on the network and sending a “hello message” to identify a device on the network as available by sending to the central “hello-message” server and receiving an up-to-date list of currently available IP addresses on the network, a server module for processing requests to receive the hash of the last transaction and the current copy of the blockchain to send the hash of the last transaction on request and send a copy of the local blockchain on request , a transaction processing server module for I participate in the consensus process for processing transactions and sending a response to a request for its confirmation or rejection, a database module for storing and providing access to modules to all necessary information, a memory module for storing files and link files, as well as a database module input/output of information for input/output of information to the device, the power supply module of the device for providing electricity to all modules of the device, and each device participating in the blockchain communication interacts with the central server either through IP address spoofing mechanisms, or through proxy servers, or via VPN.

A new set of essential features makes it possible to achieve the technical result of preventing the threat of compromise of address information and user data stored in the blockchain, through a system for organizing secure information exchange using blockchain technology and distributed data storage systems, which contains at least one central server, including a reception module / transfer of information in the communication network, a common bus for information exchange, a module for processing "hello messages", a module for processing requests for obtaining an up-to-date copy of the list of IP addresses in the network at the current time, a memory module, a device power module, and, at least, three devices - a participant in blockchain communication, including a module for receiving / transmitting information in a communication network, a common bus for information exchange, a module for sending requests to servers, a client module for requesting an up-to-date list of IP addresses on the network from the central server and sending a "hello message" , request processing server module ov to receive the hash of the last transaction and the current copy of the blockchain, a transaction processing server module to participate in the consensus process, a database module, a memory module, an information input / output module, a device power module, and each device participating in the blockchain communication interacts with the central server either through IP address spoofing mechanisms, or through Proxy servers, or through VPN.

The analysis of the prior art made it possible to establish that there are no analogues characterized by a set of features identical to all the features of the claimed method of organizing secure information exchange using blockchain technology and distributed data storage systems. Therefore, the claimed invention meets the condition of patentability "novelty".

The results of the search for known solutions in this and related fields of technology in order to identify features that match the distinguishing features of the prototype of the claimed object showed that they do not follow explicitly from the prior art. From the prior art, the influence of the transformations provided for by the essential features of the claimed invention on the achievement of the specified technical result has not been revealed either. Therefore, each of the claimed inventions meets the condition of patentability "inventive step".

To more clearly illustrate the technical solutions according to the embodiments of the present invention, a brief description of the accompanying drawings is given below.

In FIG. 1 - a method for organizing a secure exchange of information using blockchain technology and distributed data storage systems;

in fig. 2 - scheme of the server for processing requests to receive the hash of the last transaction and the current copy of the blockchain;

in fig. 3 is a diagram of the operation of a transaction processing server that takes part in the consensus process;

in fig. 4 - analysis of the transaction for the presence of incoming messages;

in fig. 5 - transaction decryption logic;

in fig. 6 - analysis of the received copy of the blockchain;

in fig. 7 - the logic of choosing one of the functions implemented in the system;

in fig. 8 - functions for displaying the history of correspondence with the specified user and sending him a text message;

in fig. 9 is a diagram of interaction with a distributed data storage system;

in fig. 10 - scheme for sending a file to a distributed storage;

in fig. 11 - a diagram of a file request from a distributed storage;

in fig. 12 - diagram of the interaction of the devices of the system;

in fig. 13 - scheme of the central server;

in fig. 14 is a diagram of a device participating in the blockchain communication process.

The technical solutions for the embodiments of the present invention will be fully and clearly described below with reference to the accompanying drawings. It should be obvious that the embodiments described below are only a part of the present invention and not all possible embodiments of the present invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention and not using creativity fall within the protection scope of the present invention.

The implementation of the claimed method is as follows (Fig. 1):

1. Enter the name of the database, which will store all the information necessary for the operation of the system.

2. Enter a password for this database to protect it from unauthorized access.

3. Check for the presence of a database - a file containing a database.

4. Create a database and generate a password for it based on the previously entered one.

5. The database is decrypted using the previously entered password.

6. Check the correctness of the file with the database - the correctness of the decryption of the database by signature.

7. When decrypting the database file, the client program is launched to send requests to the central server, which is responsible for maintaining the network by maintaining an up-to-date list of IP addresses currently available on the network, to receive an up-to-date copy of the list of IP addresses currently active on the network. addresses, as well as sending him a “hello message”, the fact of sending which means that the client who sent this message is currently an active member of the network.

8. Launch the server for processing requests to receive the hash of the last transaction and the current copy of the blockchain. The hash of the last transaction allows you to check the entire previous blockchain for a change, because. the hash of each new transaction is formed from the transaction itself and the hash of the previous transaction. An up-to-date copy of the blockchain allows the requester to analyze all the transactions that took place on the network during his absence - when the requester did not participate in the consensus process.

As an example, let us explain the principle of operation of the server for processing requests to obtain the hash of the last transaction and the current copy of the blockchain (Fig. 2):

8.1. The request processing server receives a client message with a request.

8.2. They check the type of request: a request for an up-to-date copy of the blockchain or a request for a hash of the last transaction.

8.3. An up-to-date copy of the server blockchain is retrieved from the database if the incoming request is a request for an up-to-date copy of the blockchain.

8.4. The hash of the last transaction of the server is retrieved from the database if the incoming request is a request to obtain the hash of the last transaction.

8.5. A response is formed and sent to the client in accordance with the received request.

9. Start the transaction processing server to participate in the consensus process. This server processes transactions for adding new records that are initialized by other network members.

Let us explain in more detail the principle of operation of the transaction processing server that takes part in the consensus process (Fig. 3):

9.1. The transaction processing server receives the transaction received from the client.

9.2. The ID offered by the client and the hash of the last transaction from the local copy of the client's blockchain are extracted from the transaction.

9.3. The last ID of the local copy of the blockchain of the transaction processing server is checked, and the ID must be one less than that offered by the client.

9.4. Perform validation of the ID.

9.5. The hash of the last transaction of the local copy of the client's blockchain, contained in the transaction sent by the client, and the hash of the last transaction of the local copy of the transaction processing server's blockchain are checked, and the hash must match.

9.6. Checking for hash equality.

9.7. A response is sent to the client with a positive decision to confirm the transaction received from the client by this transaction processing server.

9.8. If a negative result is obtained as a result of the check at steps 94 or 96, then a message is sent to the client about the refusal by this transaction processing server to confirm the transaction received from the client. At this point, the processing of the transaction by the transaction processing server is completed.

9.9. They add the transaction received from the client by the transaction processing server to their local copy of the blockchain.

9.10. Run the content analysis algorithm for incoming messages from one of the added users on this transaction processing server.

Next, we describe in more detail the principle by which the transaction is analyzed for the presence of incoming messages (Fig.4):

9.10.1. The encrypted part of the transaction is extracted from the entire transaction by extracting the ID and hash of the last transaction offered by the client from the client copy of the blockchain.

9.10.2. The private part of the transaction is decrypted by overlaying the key of each user added by the transaction processing server to the part of the transaction encrypted using the Vernam cipher, taking into account the key offset, while the encrypted part of the transaction will be considered decrypted only if in the sender field, which is also encrypted using the Vernam cipher , there will be the name of the user on whose key the decryption is performed, and in the recipient field there will be the name of the user whose transaction processing server performs the decryption of this transaction (Fig. 5).

9.10.3. They check whether it was possible to decrypt the message on one of the keys of the added users, if it succeeded, then the decrypted part of the transaction is divided into logical elements: the time of sending, the name of the sender, the name of the recipient and the transmitted message, which can be either a text file up to 1 KB in size, or a text message ; and is entered in the local database of the transaction processing server in clear text, if it was not possible to decrypt the message on one of the keys of the added users, then the transaction is not intended for the user of this transaction processing server.

10. Request transaction hashes from the servers of all currently available IP addresses in the network.

11. The current hash of the last transaction is selected by the majority rule.

12. A request is made to obtain an up-to-date copy of the blockchain from one of the senders of the up-to-date hash of the last transaction.

13. The algorithm for analyzing the received copy of the blockchain is launched. This algorithm is necessary to select from the entire set of transactions that occurred in the network during the absence of the requester, those transactions that relate to the requester and further process these transactions and record the information extracted from these transactions in the database.

Let us explain in more detail the principle by which the analysis of the received copy of the blockchain is performed (Fig. 6):

13.1. The previous local copy of the blockchain is deleted from the database and a copy of the local blockchain is written to the database received from the server for processing requests for obtaining the hash of the last transaction and the current copy of the blockchain.

13.2. The number of transactions of the previous local copy of the blockchain with the accepted copy is checked, if the previous local copy of the blockchain has more transactions than the accepted copy, then the global blockchain has been updated.

13.3. Check if the global blockchain has been updated. If yes, then reset the key offsets for all added users, if not, all offsets are left with the old values.

13.4. Analyze each transaction for incoming messages.

14. Display a list of added users with the number of unread messages from each of them.

15. One of the functions implemented in the system under consideration is selected for execution.

Next, we describe in detail the choice of one of the functions implemented in the system (Fig. 7):

15.1. Selecting the function number to be executed.

15.2. Check if function #1 is selected. If selected, then a new user is added, while entering the name of the new user and specifying the path to the file with the key for this user.

15.3. Check if function #2 is selected. If selected, then display the correspondence with a specific user and send him a text message.

The following is a description of the function of displaying the history of correspondence with the specified user and sending him a text message (Fig. 8):

15.3.1. Display the previous correspondence with the given user from the database.

15.3.2. Enter a new message for the user.

15.3.3. Add to the message, at least, the field of the time of sending the message, the sender's name field, the recipient's name field and encrypt these fields on the key of the given user.

15.3.4. The ID of the last transaction is retrieved from the database and this value is increased by one and a new ID for the transaction is generated.

15.3.5. The hash of the last transaction of the local copy of the sender's blockchain is retrieved from the database, and it should be noted that the hash of any transaction, except for the first one, is formed by calculating the hash from two values: the hash of the transaction recorded in the local copy of the sender's blockchain before the current transaction and the current transaction in local copy of the sender's blockchain.

15.3.6. A transaction is created for transmission, which includes a new ID, a hash of the last transaction of the local copy of the sender's blockchain, and encrypted data on the user key using the Vernam cipher, which is the TNDS system, provided that the user key is a completely random set of bits.

15.3.7. Sent to all available IP addresses from the list of current IP addresses sent by the central server, i.e. located in the system we are considering, the generated transaction.

15.3.8. Accepted from all available IP addresses from the list of actual IP addresses sent by the central server, i.e. located in the system we are considering, a response about the readiness to confirm the generated transaction by the transaction processing servers.

15.3.9. They check the fact of confirmation of the transaction according to the majority rule.

15.3.10. If the verification is successful, then the transaction is added to the local copy of the sender's blockchain.

15.3.11. If the verification was not successful, then a request for an up-to-date copy of the blockchain is performed.

15.3.12. A field is added in unencrypted form - the time the transaction was sent, a field - the name of the sender, a field - the name of the recipient and the message to be sent to the database.

15.3.13. The key is shifted for the given user by the length of the encrypted data.

15.4. Check whether function #3 is selected. If selected, then the correspondence with a specific user is displayed and a text file up to 1 Kb in size is sent to this user, and it should be noted that the size of 1 Kb was determined empirically as the most rational maximum transaction size for storage in the blockchain. The maximum transaction size can be changed to any other.

15.5. Check if function #4 is selected. If selected, then update the encryption key for a specific user. To update, you must enter the username and path to the file containing the new key. The offset for the key will be set to zero.

15.6. Check whether function #5 is selected. If selected, the file is sent to the distributed data store (FIG. 9).

The following is a more detailed description of sending a file to distributed storage (Fig. 10):

15.6.1. Enter the path to the source file.

15.6.2. The source file is encrypted with the Advanced Encryption Standard encryption algorithm with a key length of 256 bits, in the CFB feedback gamma mode, while the encryption key is placed in the link file. Encryption mode gamming with feedback is chosen so that in the absence of one of the parts of the encrypted file, or the wrong order of the parts of the encrypted file, it would be impossible to decrypt either the entire file or its part.

15.6.3. The hash of the encrypted file is calculated, and the hash is placed in the link file.

15.6.4. The encrypted file is split into N parts, each of which is written to a separate file, of random size, while all meta-information and one of the N parts of random size, which is not sent to the network, is placed in a link file to exclude the possibility of collecting the entire encrypted file.

15.6.5. K false parts are added in order to increase the entropy about the original encrypted file, while all the meta-information necessary for the correct recovery of the encrypted file is placed in the link file.

15.6.6. Each of (N-1+K) files of R servers in a distributed data storage system is assigned to organize duplication and increase system fault tolerance, and calculate the hash of each of these files, while all meta-information is placed in a link file.

15.6.7. Shuffle (N-1+K) files - change the queue for sending parts of the encrypted file to the network, while all meta-information is placed in the link file.

15.6.8. Send each of the (N-1+K) files to R servers in a distributed storage system using Proxy servers, VPN or IP address spoofing system - to make it difficult to identify the sender of each of the files.

15.6.9. Form the final version of the link file.

15.7. Check whether function #6 is selected. If selected, the file is requested from the distributed data store (FIG. 9).

The following is a more detailed description of a file request from distributed storage (Fig. 11):

15.7.1. Enter the path to the file-link to the source file.

15.7.2. Meta-information about the source file is extracted from the link file: the number of parts into which the source file was split, the number of false parts, file names on remote servers, rules for mixing files before sending, IP addresses of file storage servers, encryption key on which the entire file, hashes of parts of the file, hash of the entire file.

15.7.3. They request parts of files from servers using proxy servers, VPNs, or an IP address spoofing system in order to make it difficult to determine the recipient of parts of an encrypted file.

15.7.4. The hashes of the file parts are checked in such a way that if at least one correct copy of each part of the file has come from the servers in the distributed storage system and its hash is correct, then proceed to the next step, if at least one of the above conditions is not met, then a message is displayed about an error and stop collecting the source file.

15.7.5. The received parts of the file are shuffled in order to arrange them in the correct order, and it should be noted that all the necessary meta-information is contained in the link file.

15.7.6. Separate the false parts of the file.

15.7.7. Build the encrypted source file.

15.7.8. They check the hash of the entire encrypted file, if the check fails, they issue an error message and stop collecting the source file.

15.7.9. Perform decryption of the encrypted file.

15.8. Check whether function No. 7 is selected. If selected, the user information display interface is updated.

15.9. Check whether function #8 is selected. If selected, perform a secure logout.

16. Verify that the secure logout feature is selected.

17. If the secure logout function is not selected, then the selected function is executed. After this function is executed, the function to be executed is again selected (step 15).

18. If the secure logout function is selected, or the result of checking the correctness of the decryption of the database file in paragraph 6 is negative - the database file was not decrypted correctly, then the database is encrypted using the previously entered correct password.

19. Finish working with the database.

The claimed method of organizing a secure exchange of information using blockchain technology and distributed data storage systems makes it possible to achieve the technical result of the impossibility of compromising senders and recipients of files in a distributed data storage system due to the fact that when sending a file to a distributed data storage, the device participating in the blockchain communication encrypts the file using symmetric encryption on the aes-256 algorithm in CFB mode. At the same time, a distributed data warehouse can consist of any third-party data stores. The sent file is split into several parts, false parts are introduced, files are mixed before sending, each file that contains a part of the encrypted file or a false part of the file is assigned the servers on which these files will be stored. The above measures, on the one hand, greatly complicate the task of collecting statistics on sent files, and on the other hand, guarantee the impossibility of decrypting files stored in a distributed storage system. In order to make it impossible to determine the sender and recipient of parts of the encrypted file, all connections are made either through IP address spoofing mechanisms, or through Proxy servers, or through VPN.

The secure information exchange system using blockchain technology and distributed data storage systems (Fig. 12) consists of one central server 101 (Fig. 13) and at least three devices participating in the blockchain communication 102 (Fig. 14).

The central server (Fig. 13) contains a module for receiving / transmitting information in a communication network for receiving and transmitting data via communication channels, a common information exchange bus for exchanging information between device modules, a module for processing "hello messages" for receiving from devices participating in the blockchain - communications (Fig. 14) of "hello messages" and updating the current list of currently available IP addresses in the network, a module for processing requests for obtaining an up-to-date copy of the list of IP addresses in the network at the current time to send an up-to-date list of IP addresses available in the network a given point in time of IP addresses in the network upon request, a memory module for storing an up-to-date list of currently available IP addresses in the network, a device power module to provide power to all device modules.

The device participating in the blockchain communication (Fig. 14) contains a module for receiving/transmitting information in a communication network for receiving and transmitting data via communication channels, a common information exchange bus for exchanging information between device modules, a module for sending requests to servers for sending requests to servers processing requests to obtain a hash of the last transaction and an up-to-date copy of the blockchain and to transaction processing servers, a client module for requesting the central server for an up-to-date list of IP addresses on the network and sending a “hello message” to identify the device on the network as available by sending it to the central server “hello messages” and getting an up-to-date list of currently available IP addresses on the network, a server module for processing requests to receive a hash of the last transaction and an up-to-date copy of the blockchain to send a hash of the last transaction on request and send a copy of the local blockchain on request, server module processing transactions to participate in the process consensus for processing transactions and sending a response to a request for its confirmation or rejection, a database module for storing and providing access to modules to all necessary information, a memory module for storing files and link files, as well as databases, an information input / output module for input/output of information to the device, the power supply module of the device to provide electricity to all modules of the device.

The central server can be implemented according to a well-known scheme, for example, as a personal computer (PC) based on an Intel Corei3-10100 processor with a clock speed of 3.6 MHz, 2 GB DDR4 RAM and an installed operating system (OS) Ubuntu 16.04 LTS.

A device participating in blockchain communication can be implemented according to a well-known scheme, for example, as a personal computer (PC) based on an Intel Core i3-10100 processor with a clock frequency of 3.6 MHz, 2 GB DDR4 RAM and an installed Ubuntu 16.04 LTS operating system.

The interactive process of a secure information exchange system using blockchain technology and distributed data storage systems is described below.

When entering the system, the device participating in the blockchain communication sends a “hello message” to the central server, in response receives confirmation of the receipt of the “hello message” by the central server, and then requests the central server for an up-to-date list of IP addresses available on the network. The above actions are periodically repeated, because. devices participating in the blockchain communication leave the network and enter the network.

Next, the device participating in the blockchain communication needs to receive an up-to-date copy of the global blockchain of the network, because during his absence from the network, the global blockchain could change. To do this, the device participating in the blockchain communication asks all available IP addresses, namely the servers for processing requests for the hash of the last transaction or for obtaining the current copy of the blockchain, in the network the hash of the last transaction from their local copy of the blockchain and selects the current hash by majority of the last transaction and asks one of the senders of the current hash of the last transaction for its local copy of the blockchain, accepting it as up-to-date. Then it performs analysis on incoming messages in this blockchain.

When a device participating in a blockchain communication sends a text message or a text file up to 1 Kbyte in size to one of the added users, it sends to all available IP addresses in the network the transmitted transaction in the form: for TNDSH system message". It includes: fields of sending time, sender, recipient and the transmitted information itself.

This transaction is processed by all transaction processing servers, and if they agree to confirm the accepted transaction, then they send “YES” in response and add the sent transaction to their local copy of the blockchain, and if they do not agree, they send “NO”. If the majority of the responses received from the transaction processing servers are “YES”, then the transaction is added to the local copy of the blockchain of the device participating in the blockchain communication that sent the transaction to the network, if the majority of the responses are “NO”, then the transaction is not added and the actual copy is requested blockchain, because if most of the IP addresses in the network did not confirm the transaction, then the device participating in the blockchain communication that sent the transaction currently contains an incorrect copy of the blockchain.

The organization of a remote exchange of regular keys for the TNDSH system, as well as any other files, without the threat of their compromise, is carried out as follows.

When sending a file to a distributed data store, which may consist of any third-party data stores 103, the device participating in the blockchain communication encrypts the file using symmetric encryption using the aes-256 algorithm in CFB mode on the key for the PNDS system. Splits the file being sent into several parts, introduces false parts, shuffles files before sending, assigns each file that contains part of a real encrypted file or a false part of a file to the servers where these files will be stored. In order to make it difficult to determine the recipient of parts of an encrypted file, all connections occur either through IP address spoofing mechanisms, or through Proxy servers, or through VPN.

In order to decrypt an encrypted source file, it is necessary to assemble the encrypted file in its entirety and in the correct order. To make this impossible, we place one or more of the real parts of the encrypted source file in a link file that is located on the device participating in the blockchain communication and in the future will be transmitted over the network only in the form encrypted with the user key for the TNDS system , and therefore, if the user key is not compromised, it will be impossible to unambiguously decrypt it, and therefore it will be impossible to obtain the missing part of the original encrypted file, which means that even if the attacker puts together all parts of the file, separates the false parts from the real ones, builds them in the correct order, will determine which part is missing, then it will not be able to unambiguously decrypt the file, because it will not have the missing part of the original encrypted file.

All meta-information about each file sent to a distributed storage system is entered in a link file: to which servers, or several servers - for duplication, each small file is sent - a file that is part of the original encrypted file, a hash of each small file, a hash of the entire file, part the encrypted source file, the encryption key on which the source file was encrypted, the rule for mixing small files, how many false and how many real files, etc.

If it is necessary to request a file from a distributed storage, the device participating in the blockchain communication performs the above actions in reverse order: accesses the link file, requests parts of the original encrypted file from the servers, checks the hashes of the received small files, mixes them in the correct order, separates the false parts from the real ones , collects the original encrypted file in its entirety by adding the missing parts from the link file, checks the hash of the entire encrypted file and decrypts it.

Thanks to a new set of essential features, the specified technical result is achieved through the use of a secure information exchange organization system using blockchain technology and distributed data storage systems, which contains at least one central server, including a module for receiving / transmitting information in a communication network for receiving and transmitting data via communication channels, a common information exchange bus for exchanging information between device modules, a “hello-message” processing module for receiving “hello-messages” from devices participating in the blockchain communication and updating the current list of currently available IP addresses in the network , a module for processing requests for obtaining an up-to-date copy of the list of currently available IP addresses on the network to send an up-to-date list of currently available IP addresses on the network upon request, a memory module for storing an up-to-date list of currently available IP addresses in networks, power module devices for providing electricity to all modules of the device and at least three devices participating in blockchain communication, including a module for receiving / transmitting information in a communication network for receiving and transmitting data via communication channels, a common information exchange bus for exchanging information between device modules, a module sending requests to servers to send requests to servers for processing requests to obtain a hash of the last transaction and an up-to-date copy of the blockchain and to transaction processing servers, a client module for requests from the central server for an up-to-date list of IP addresses on the network and sending a “hello message” to identify the device on the network as available by sending a “hello message” to the central server and receiving an up-to-date list of currently available IP addresses on the network, a server module for processing requests to receive the hash of the last transaction and an up-to-date copy of the blockchain to send the hash of the last transaction upon request, and sending a copy locally on request, a transaction processing server module for participating in the consensus process for processing transactions and sending a response to a request for its confirmation or rejection, a database module for storing and providing access to modules to all necessary information, a memory module for storing files and files - links, as well as a database, an information input/output module for input/output of information to the device, a device power supply module for providing electricity to all device modules, and each device participating in the blockchain communication interacts with the central server or through IP substitution mechanisms. addresses, either through Proxy servers or through VPN.

According to Shannon's theorem on the perfect cipher (see Zubov A.Yu. Perfect ciphers: Introductory speech by Corresponding Member of the Russian Academy of Sciences B.A. Sevastyanov. - M .: Helios ARV, 2003. - 160 p.) TNDSH encryption systems require, so that the used encryption keys are equally probable among themselves - they are random sequences of bits, and so that the number of key options is greater than or equal to the number of options for the transmitted information intended for encryption on a given key.

In the proposed method, the fulfillment of the condition of equiprobability of encryption keys is assigned to the user of the system (participant of blockchain communication), allowing him to independently generate keys in the most appropriate way for him. The fulfillment of the second condition is that for each sent message there is a separate one-time pad, represented as a set of bits with a length equal to the length of the transmitted message in binary form, and, therefore, the number of key options is equal to the number of options for the transmitted information, which is used only once for encrypt this message. Using the same bit sequence to re-encrypt another message is not allowed.

In particular, this method uses "XOR-encryption" - the Vernam Cipher, which has absolute cryptographic strength under certain conditions (see A.Yu. Zubov. Perfect ciphers: Opening speech by Corresponding Member of the RAS B.A. Sevastyanov. - M.: Helios ARV, 2003.- 160 p.).

But in order to securely exchange keys for this encryption algorithm, you need either an absolutely reliable communication channel, and this is only a channel that is already protected by the TNDS system, or a personal meeting. However, transmitting 1 GB of a new TNDS system key over a completely secure channel, protected by the TNDS system, while using up 1 GB of the current TNDS system key, makes no sense.

The proposed distributed file storage system solves the problem of secure transmission of key information for TNDS systems via communication channels. When sending a file to a distributed data store, which can consist of any third-party data stores, the device participating in the blockchain communication encrypts the file using symmetric encryption using the aes-256 algorithm in CFB mode on the key for the system's PNDS. Splits the file being sent into several parts, introduces false parts, shuffles files before sending, assigns each file that contains part of a real encrypted file or a false part of a file to the servers where these files will be stored. In order to hinder the process of assembling parts of the encrypted source file and the process of identifying file senders by an attacker, all connections occur either through IP address spoofing mechanisms, or through Proxy servers, or through VPN. Since the distributed data storage contains only encrypted parts of the file, and one or more parts of the original encrypted file are contained only in the link file, and the original file is encrypted using the feedback gamma method, therefore, without all parts of the original encrypted file, decryption will be meaningless. Moreover, the link file will be transmitted over a communication channel protected by the TNDSH encryption system. Based on this, we can conclude that by transmitting a link file no larger than 1 KB over a communication channel protected by the TNDSH encryption system, we will receive a full-fledged key for the TNDSH system of any size. The Vernam encryption method was chosen as the encryption method in the proposed method for organizing secure information exchange using blockchain technology and distributed data storage systems. Thus, the threat of decrypting messages in the future is minimized. However, to start the communication process, users of the proposed system need to meet in person once and exchange encryption keys. Thus, when using the proposed method and system, the number of personal meetings or other methods of absolutely reliable transmission of encryption keys for TNDS systems is reduced from an indefinite number of times, depending on the amount of information that users of the system (participants of blockchain communication) will exchange, to one times.

To ensure anonymity in the network, the classic consensus process has been changed - there is no need to confirm the correctness of transaction data: information is encrypted, the sender and recipient are encrypted;

This allows consensus to be reduced to the ordering of the entire set of transactions by all users currently available on the network. The philosophy of the proposed system is that each user can send any information to any other user, but only the user who has the same encryption key on which the message is encrypted can decrypt the incoming message and understand that it is addressed to him. Thus, there is a blockchain where neither senders, nor recipients, nor the content of messages are known, which solves the issue of anonymity of users and confidentiality of transmitted data.

Claims (10)

1. A method for organizing a secure exchange of information using blockchain technology and distributed data storage systems, which consists in entering the name of the database, while additionally entering a password for this database, checking the presence of the database on the device, if the database is available, it is carried out decryption using AES-256 symmetric encryption, check the correctness of the file with the database, in the absence of a database, create a new database, while generating a password for the new database, which is necessary to encrypt and decrypt the file with the new database using the AES-256 algorithm, complete work with the database, characterized in that after checking the correctness of the file with the database or after creating a new database, they start network services, at least start the client to query the central server for an up-to-date list of IP addresses on the network and send a “hello message ”, start the server for processing requests for the hash of the last tr transactions and the current copy of the blockchain, launch the transaction processing server to participate in the consensus process, then request transaction hashes from the servers of all IP addresses available on the network, select the current hash of the last transaction according to the majority rule, make a request to receive the current copy of the blockchain from one of the senders of the current hash of the last transaction, run the algorithm for analyzing the received current copy of the blockchain, display a list of added users, select at least one of the functions: adding a new user, viewing the history of correspondence with the specified user and sending a text message to this user, viewing the history of correspondence with the specified user and sending this user a text file up to 1 KB in size, updating the encryption key for the specified user, sending the file to distributed storage, requesting a file from distributed storage, updating the information display interface, without safe exit from the system that the system needs to perform, check the fact that the safe exit function is selected, if this function is not selected, then the selected function is executed, while after the selected function is executed, a new function is selected if the safe exit function is selected from the system, then the database is encrypted using the previously entered password according to the AES-256 algorithm. 2. A secure information exchange system using blockchain technology and distributed data storage systems, consisting of at least one central server, including a module for receiving / transmitting information in a communication network for receiving and transmitting data over communication channels, a common information exchange bus for exchanging information between modules of the device, a module for processing “hello messages” for receiving “hello messages” from devices participating in the blockchain communication and updating the current list of currently available IP addresses in the network, a module for processing requests to receive an up-to-date copy of the list of currently available point in time of IP addresses on the network to send an up-to-date list of currently available IP addresses on the network upon request, a memory module to store an up-to-date list of currently available IP addresses on the network, a device power supply module to provide power to all device modules and at least three devices participating in the blockchain - communications, including a module for receiving / transmitting information in a communication network for receiving and transmitting data over communication channels, a common information exchange bus for exchanging information between device modules, a module for sending requests to servers for sending requests to the server module for processing requests to receive the hash of the last transaction and the actual copy of the blockchain and the transaction processing server module to participate in the consensus process, the client module to query the central server for an up-to-date list of IP addresses in the communication network and send a "hello message" to identify the device on the network as available by sending it to the central server "hello-messages" and obtaining an up-to-date list of currently available IP addresses on the network, a server module for processing requests to receive a hash of the last transaction and an up-to-date copy of the blockchain to send a hash of the last transaction upon request and send a copy of the local blockchain upon request, a server module transaction processing for I participate in a consensus process to process transactions and send a response to a request for confirmation or rejection, a database module for storing data on at least transactions, user encryption keys, message history, a memory module for storing files and reference files, and databases data, an information input/output module for input/output of information to the device, a device power supply module for providing electricity to all device modules, and each device participating in the blockchain communication interacts with the central server either through IP address spoofing mechanisms or through Proxy- servers, or through a VPN. 3. The method according to claim 1, in which when starting the server for processing requests to obtain the hash of the last transaction and the current copy of the blockchain: the request processing server receives the client's messages with the request, checks the type of request by the server, if a request is received to obtain the hash of the last transaction of the server's blockchain copy , then the hash of the last transaction is retrieved from the database, if a request is received to obtain an up-to-date copy of the server blockchain, then an up-to-date copy of the server blockchain is retrieved from the database, a message is generated to be sent to the client, taking into account the characteristics of the information extracted from the database, the generated response is sent to the client. 4. The method according to claim 1, wherein when the transaction processing server is started: the transaction processing server receives transactions from the client, extracts from the transaction the ID offered by the client and the hash of the last transaction from the local copy of the client's blockchain, checks the last ID of the local copy of the transaction processing server's blockchain, when this ID must be one less than the one offered by the client, the correctness of the ID is checked, if the check gave a negative result, then the client is sent a message about the refusal by this transaction processing server to confirm the transaction received from the client, if the check was successful, then the hash of the last transaction of the local copy of the blockchain is checked of the client, contained in the transaction sent by the client, and the hash of the last transaction of the local copy of the blockchain of the transaction processing server, while the hash must match, if the hash does not match, then send the client a message that this transaction processing server refuses to confirm the accepted transaction from client, if the hash matches, then send a response to the client with a positive decision on confirmation by this transaction processing server of the accepted transaction from the client, add the transaction received from the client by the transaction processing server to its local copy of the blockchain, run the content analysis algorithm for incoming messages from one of the added users on this transaction processing server. 5. The method according to claim 4, in which, when running the content analysis algorithm for incoming messages from one of the added users on this transaction processing server: extracting the encrypted part of the transaction from the entire transaction by extracting the ID offered by the client and the hash of the last transaction from the client copy of the blockchain , decrypt the private part of the transaction by overlaying the key of each user added by the transaction processing server to the encrypted part of the transaction, taking into account the key offset, while the encrypted part of the transaction is decrypted only if the sender field, which is also encrypted, contains the name of the user on whose key the decryption, and the recipient field will contain the name of the user whose transaction processing server decrypts this transaction, check whether it was possible to decrypt the message using one of the keys of the added users, if so, then the decrypted part of the transaction is divided into logical elements: send time, sender's name, recipient's name and the message to be sent, which can be either a text file up to 1 KB in size, or a text message, and is entered in the local database of the transaction processing server in clear text if the message could not be decrypted on one of the keys of added users, then the transaction is not intended for the user of this transaction processing server. 6. The method according to claim 1, in which, when executing a request to obtain an up-to-date copy of the blockchain: the previous local copy of the blockchain is deleted from the database and the copy of the local blockchain received from the server for processing requests for obtaining the hash of the last transaction and the current copy of the blockchain is written to the database, check the number of transactions of the previous local copy of the blockchain with the accepted copy, if the previous local copy of the blockchain has more transactions than the accepted copy, then the global blockchain has been updated, while resetting the key offsets for all added users, in the case when the global blockchain is updated did not happen, then leave the key offset values for all added users the same, analyze each transaction for incoming messages, while extracting the encrypted part of the transaction from the entire transaction by extracting the ID and hash of the last transaction offered by the client from the client copy of the blockchain, distributing encrypt the private part of the transaction by overlaying the key of each user added by the transaction processing server to the encrypted part of the transaction, taking into account the key offset, while the encrypted part of the transaction is decrypted only if the sender field, which is also encrypted, contains the name of the user on whose key the decryption is performed , and the recipient field will contain the name of the user whose transaction processing server is decrypting this transaction, if it was possible to decrypt the message using one of the keys of the added users, then the decrypted part of the transaction is a message, which can be either a text file up to 1 KB in size, or a text message, and is entered into the local database of the transaction processing server in cleartext, if it was not possible to decrypt the message using one of the keys of the added users, then tra The transaction is not intended for a user of this transaction processing server. 7. The method according to claim 1, in which at least one of the functions is selected: adding a new user, while entering the name of the new user and specifying the path to the file with the key for this user, viewing the history of correspondence with the specified user and sending this user a text message , viewing the history of correspondence with the specified user and sending to this user a text file up to 1 KB in size, updating the encryption key for the specified user, sending the file to distributed storage, requesting a file from distributed storage, updating the interface for displaying user information, safely logging out of the system that you need execute the system. 8. The method according to claim 1, in which, when requesting to send a file to a distributed storage, the path to the source file is entered, the source file is encrypted using the "Advanced Encryption Standard" encryption algorithm with a key length of 256 bits in the gamma mode with CFB feedback, while the encryption key is placed in the link file, the hash of the encrypted file is calculated, the hash is placed in the link file, the encrypted file is split into N parts (files) of random size, with all meta-information and one of the N parts of random size, which is not sent to the network, are placed in the link file, K false parts are added, while all meta-information is placed in the link file, each of the (N-1 + K) files of R servers in the distributed storage system is assigned and the hash of each of these files is calculated, while all meta-information is placed in a link file, (N-1 + K) files are mixed, while all meta-information is placed in a link file, each of the (N-1 + K) files is sent to R servers in a distributed storage system data exchange using the mechanism of IP address spoofing, either through Proxy servers or through VPN, form the final version of the link file. 9. The method according to claim 1, in which, when requesting a file from a distributed storage, the path to the file-link to the source file is entered, meta-information about the source file is extracted from the link file: the number of parts into which the source file was split, the number of false parts, file names on remote servers, rules for shuffling files before sending, IP addresses of file storage servers, encryption key on which the entire file is encrypted, hashes of parts of the file, hash of the entire file, request parts of files from the servers using the IP address spoofing mechanism or through Proxy servers, or through a VPN, check the hashes of the file parts, taking into account the fact that if at least one copy of each part of the file is received from the servers in the distributed storage system and its hash has been checked for correctness, then they proceed to the next step, if at least one the condition is not met, then they issue an error message and stop collecting the source file, mix the received parts of the file, separate the false parts of the file, execute assemble the encrypted source file, check the hash of the entire encrypted file, if the check is negative, then issue an error message and stop collecting the source file, if the check was successful, then decrypt the encrypted (received) file. 10. The method according to claim 6, in which, when viewing the history of correspondence with the specified user and sending him a text message, display the previous correspondence with this user from the database, enter a new message for the user, add to the message at least the message sending time field, the name field sender, recipient name field, encrypt these fields on the key of this user, extract the ID of the last transaction from the database and increase the current value by one, form a new ID for the transaction, extract the hash of the last transaction of the local copy of the sender's blockchain from the database, create a transaction for transmission, which includes a new ID, a hash of the last transaction of the local copy of the sender's blockchain and encrypted data on the Vernam cipher using a user key, is sent to all available IP addresses from the list of actual IP addresses sent by the central server, the generated transaction is received from all available IP addresses and from the list of current IP addresses sent by the central server, the response about the readiness to confirm the generated transaction by the transaction processing servers, check the fact of transaction confirmation according to the majority rule, if the check is negative, then the request for the current copy of the blockchain is performed according to clause 6, if the check was positive, then add a transaction to the local copy of the sender's blockchain, add the fields in clear form: the time the transaction was sent, the name of the sender, the name of the recipient, the message to be sent to the database, perform a key shift for this user by the length of the encrypted data.

Images