EA036643B1 - Method for managing digital assets - Google Patents

Abstract

The invention relates to the field of information technology, in particular, to a method for digital assets management, and can be used for creation, operation, control and monitoring of various-purpose systems, including complex economical and social systems, where devices for collection and exchange of various information, information resources and digital assets are integrated. The invention is generally aimed at creation of such a method for digital assets management that could ensure solving the problems of the participant authentication, making transactions only between the trusted authenticated participants of the system (integrity, inaccessibility of the system for digital assets management and exchange), registration of digital assets operations, capability of legal cancellation of digital assets operations. The technical result of this invention is creation of a reliable system for digital assets management, which could allow for improving the existing digital assets management systems due to the production process, digital assets turnover becoming transparent and controlled, and the digital assets exchange system obtaining its integrity and eliminating the defects of prior art solutions, first of all, Bitcoin and Etherium.

Description

The invention relates to the field of computer science, namely, data processing systems or methods specifically designed for administrative, commercial, financial, management, supervisory or predictive purposes; and more specifically, to the method of managing digital assets (by digital assets we mean data in electronic devices and intended to perform the target functions of the system, including payment systems / electronic money / cryptocurrency).

The present invention can find application in the creation, operation, management and monitoring of systems for various purposes, including complex economic and social systems (including large distributed systems of social and economic management, big data systems, etc.), in which various storage and exchange means are integrated. information, information resources and digital assets.

The present invention is based on the task of creating such a method for managing digital assets, which would provide the following tasks:

authentication of a participant, transactions only between trusted authenticated participants of the system (closed, isolated control and exchange system of CA), registration of transactions with digital assets, the possibility of legitimate (that is, available to the sender and agreed with the system control center) cancellation of transactions with digital assets. There is a known system for managing transactions (patent No. 2158956, published 11/10/2000), which includes a plurality of control devices for system participants, including at least one bank control device, at least one customer control device, at least one vendor control device, characterized in that said system participant control devices are connected via a communication channel with a centralized control device and a certificate storage and verification device connected to at least one said centralized control device, which includes: participant registration device systems, a device for forming and storing a database on transactions between system participants, a device for forming and storing a database on contracts concluded between system participants, a data management device related to financial transactions, a control and analysis device the process of making a transaction between the participants of the system, a device for controlling the process of making a transaction, a device for forming and storing a database of system participants, a device for forming and storing a database of goods and services, a document management device, while said device for registering system participants is connected to said formation device and storing a database of system participants and with the input and output of said centralized control device, to which said transaction control device is also connected, which, in turn, is connected to said document management device, to said data management device related to financial transactions , with said device for forming and storing a database of goods and services, with said device for monitoring and analyzing the process of making a transaction between system participants, connected to the output of said device c centralized control, with the said device for forming and storing the database on the participants in the system and with the said device for forming and storing the database on the operations performed between the participants of the system, which, in turn, is connected to the said device for forming and storing the database on the concluded between the participants systems to contracts.

Significant disadvantages of this system are the focus on the participation of the bank, as well as the narrow scope, focused on the execution of a centralized transaction, as well as the openness of the system, which in modern economic conditions is in most cases impractical, since banks rarely serve digital assets. In addition, in this system, certificates solve only the problem of protecting the invariability of a transaction, whereas in modern conditions this is not enough, it is necessary to authenticate the participants and conduct operations only between the authenticated participants entering the system (isolation, isolation).

Another close and more modern analogue to this invention is the Bitcoin project (English Bitcoin, from bit - “bit” and coin - “coin”) - a peer-to-peer payment system using the same-named unit of account and the same-name data transfer protocol. To ensure the functioning and protection of the system, cryptographic methods are used. All information about transactions between system addresses is available in clear text.

Transactions are irreversible, electronic payment between the two parties takes place without intermediaries. But there is the possibility of attracting a third party guarantor using multisignature. No one can freeze funds, even temporarily, except for the owner himself.

Bitcoins can be used to exchange for goods or services from merchants who agree to accept them. Exchange for conventional currencies takes place through an online service for exchanging digital currencies, other payment systems or exchange offices.

The commission for the transactions is set by the sender voluntarily, the size of the commission affects

- 1 036643 for priority when processing a transaction. Usually, the client program suggests the recommended amount of the commission. Commission-free transactions are possible and can be processed as well, but not recommended because the processing time is unknown and can be quite long.

One of the main features of the "Bitcoin" system, which is also a significant drawback, is complete decentralization and openness of the system: there is no central administrator or any of its analogs. This creates the possibility of unregulated digital asset transactions. A necessary and sufficient element of this payment system is the basic client program, which is open source. Client programs launched on many computers are connected to each other in a peer-to-peer network, each node of which is equal and self-sufficient. It is impossible for public or private management of the system, including changing the total amount of bitcoins. The volume and timing of the release of new bitcoins are known in advance, but they are distributed relatively randomly among those who use their equipment for computing, the results of which are a mechanism for regulating and confirming the eligibility of transactions in the Bitcoin system.

As you can see from the description, this prototype has the following disadvantages:

the formation (production, mining) of a digital asset (CA) is completely uncontrolled;

the process of CA production and its turnover is non-transparent and uncontrollable;

the system is not closed from unscrupulous participants;

transactions carried out are irreversible, there is no mechanism for canceling a confirmed transaction (including cases when the payment was sent to an erroneous or non-existent address, or when the transaction was signed with a private key that became known to others).

The problems of the invention are solved and the disadvantages of the prototypes are eliminated in the method implemented according to the present invention for managing digital assets in a computer system consisting of at least one sender of transactions, at least one recipient of transactions, each of which has a storage of digital assets, at least one operator storages of digital assets, characterized in that all participants in the system possess electronic signature certificates, generate requests for transactions that are encrypted and signed with an electronic signature, and use a secret key to access the storage and make a transaction of the sender, and use a secret key to access the storage and carry out a transaction recipient - a public key that includes the following steps:

1) the sender of the transaction generates a request for the transaction, containing in encrypted form the secret key of the transaction, which can only be decrypted by the operator of the digital asset storage, signs this request with his electronic signature and sends it to the operator of the digital asset storage;

2) the operator of the digital asset repository, if necessary, verifies the correctness of the electronic signature of the request from the sender of the transaction and, if the verification of the electronic signature is positive, proceeds to step 3;

3) the digital asset storage operator decrypts the transaction sender's request and receives the sender's digital asset storage secret key;

4) the digital asset storage operator decrypts (if necessary) the public key of the recipient of the transaction;

5) the digital asset storage operator verifies the correctness of the electronic signature under the public key of the recipient of the transaction and, if the electronic signature is verified, proceeds to step 6;

6) the operator of the digital asset storage generates the requested transaction on the secret key of the sender's digital asset storage and sends the generated transaction to the recipient, while the transaction is recorded in the network of the corresponding digital asset;

7) the digital asset storage operator sends to the sender and / or the recipient of the transaction an electronically signed confirmation of the transaction.

The technical result to be solved by this invention is to create a reliable digital asset management system that would improve the existing digital asset management systems due to the fact that the process of production and circulation of the target audience becomes transparent and controllable, and the target audience exchange system would be closed and overcome the shortcomings of known solutions, primarily Bitcoin and Etherium.

These tasks are achieved by the fact that when a certificate is issued to the client, his mandatory authentication will be carried out, operations with the digital asset storage are registered and managed by managing the corresponding electronic signature certificates, in addition, legitimate cancellation of transactions is possible without the participation of the bank and the need to contact him.

The present invention will be disclosed in the following description of a computer system for managing digital assets with reference to the drawing, consisting of at least one sender of transactions, at least one recipient of transactions, each of which has a digital asset store, at least one operator storage of digital assets, while all participants in the system possess electronic signature certificates, generate 2,036643 requests for transactions that are encrypted and signed with an electronic signature, while the goal is to move a digital asset from the sender's digital asset store to the recipient's digital asset store, and a secret key is used to access the store and make a transaction of the sender, and a public key is used to access the store and make a transaction of the recipient, which includes the stages described in detail below.

Let us introduce the following short designations (a certificate means an electronic signature certificate obtained by signing an electronic signature of the certification authority of the open (public) key of the participant (client) of the system - senders and recipients of transactions):

iccn_head_ca_cert Certificate Head Certification Authority (CA) ccw_op_head_ca_cert Certificate Head CA operator ccw_op_hsm_private_key secret key CA storage HSM operator warehousing CA ccw_op_hsm_cert certificate HSM operator warehousing CA iccn_op_head_ca_cert Certificate Head CA CA storage operator iccn_op_end_user_ca_cer Certificate CA storage management clients of the operator t CA iccn_op_ccw_ca_cert Certificate CA storage CA end_user_iccn_cert Client certificate end_user_iccn_perms Client permissions end_user_ccw_cert Client CA repository certificate end_user_ccw_perms Client CA repository permissions ccw_private_key Client CA repository private key stored in HSM ccw_public_key Client CA public key repository key of client CA ccwken_private_key repository public key client CA storage ccwken_private_key

In the presented scheme, the authentication and authorization of end users is based on certificates and permissions that the corresponding CA will include in them. This model is static in the sense that it does not allow dynamically managing the permissions of end users and therefore, in practice, it may not be sufficient and then it is necessary to implement more flexible management models.

In the process of describing the scheme of work of digital asset management (UCA), various approaches will be considered to the fact that the end user knows his real address in the environment (network) of a digital asset.

The first is that despite the fact that the sender cannot use the secret key of the CA storage on his own, the real address of the CA storage is known to the end user (this means that he knows the public key of the CA storage).

The second approach is that the end user does not know the public key of the CA storage, that is, he does not know the address of the CA storage, which he controls. The choice of this or that approach is determined solely by the characteristics of the activity that the Central Asia Control Center (MCC) wants to organize. However, it is clear that the user's knowledge of his real address has a direct impact on the anonymity characteristics of the UCA environment.

The general diagram of UCA is shown in the drawing. Let's look at the main steps involved in initializing and operating UCA.

Phase 1. Initialization of the UCA GCC.

Initialization of UCA's parent CA.

The parent CA may be associated with government regulatory bodies, or another body that regulates the activities of digital asset operators.

Stage 2. Initialization CA storage operator.

Initialization of the CA storage operator begins with the receipt of its head CA certificate (ccw_op_head_ca_cert) from the CA MCC CA (step 2.1). Step 2.1 is the registration of a new CA storage in the system.

The CA storage operator consists of two main elements: the head CA and the HSM. To complete the initialization of the CA storage, HSM generates a secret key (ccw_op_hsm_private_key) and receives a certificate (ccw_.op_hsm_cert) of the public key from its HSC (step 2.2). Also, the public key certificate is placed in the CA storage directory (step 2.3).

Stage 3. Initialization of the CA MCC.

The CA MCC initialization, as well as the CA storage operator, begins with the receipt by its head CA of the certificate (dapc_op_head_ca_cert) from the CA MCC CA (step 3.1). Step 3.1 is the registration of the new MCC of the CA in the system.

The CA storage operator consists of four main elements: the head CA, the CA CA, the CA storage CA and the AV database of the CA storage. To complete the initialization, CA CA and CA storage CA request public key certificates (dapc_op_end_user_ca_cert and dapc_op_ccw_ca_cert) required for their activation (step 3.2 and step 3.3, respectively).

After activation of all CAs, the database of recovery operators is initialized. To do this, the recovery operator (s) generates (are) private keys and request public key certificates from their parent CA (step 3.4).

Stage 4. Registration of the sender of the transaction in the CA MCC.

The registration stage, as in other cases, is a request and receipt of a certificate (end_user_dapc_cert) from the CA MCC. The processing of these requests within the MCC CA is carried out by the CA MC. Thus, the client receives a public key certificate with permissions included in it (end_user_dapc_perms), which it will later use to authenticate when accessing UCA services.

What data the client must provide in order to obtain a certificate, as well as what data will be included in his certificate, depends on the policy of the corresponding MCC of the CA. In addition, an important point to be determined by the MCC CA is the access parameters to the certificate catalog. Whether it will be public, accessible only to authenticated clients, or closed is also determined by the current policy.

Stage 5. Obtaining the CA store certificate.

By now, the customer, having registered with the CA MCC and having received the appropriate certificate, has the opportunity to access UCA services.

Since within UCA the client works with the CA store through the CA store and does not own the secret key of the CA store, it is proposed to use a special certificate to identify the CA store, to which the CA store operator will bind real CA stores and on which encryption and digital signature of information will be performed associated with this CA repository. In addition, the use of a separate certificate for each CA store will allow the CA MCC to conduct, if necessary, targeted blocking of the CA store simply by revoking the corresponding certificate.

Thus, at this stage, the client contacts the CA of the CA store, authenticates and requests the CA store certificate (end_user_ccw_cert). Authentication can be carried out over the TLS protocol using the standard client authentication feature. When applying for a CA store certificate, the client can specify the permissions (end_user_ccw_perms) that he would like to receive. For example, the type of digital asset, the maximum storage capacity, the ability to access external UCA gateways, etc. The specific list of certificate permissions and requirements for obtaining it are determined by the policy of the CA MCC.

After successfully obtaining the CA storage certificate, the client can make requests to the CA storage operator.

Stage 6. Connecting the real CA store to the client certificate.

At this stage, the client contacts the appropriate CA storage operator to create a CA storage for him. The request is signed on the certificate received from the CA MCC at stage 6. Thus, the CA repository operator has the opportunity to verify the client's credentials to create the CA repository.

After checking the validity of the request, the HSM operator creates (or uses the already created) key pair of the CA store (ccw_private_key and ccw_public_key). A public key request is generated from the public key (ccw_public_key_token), and from the private key a private key request (ccw_private_key_token).

The ccw_private_key_token request is obtained by encrypting and signing ccw_private_key on the CA storage operator's certificate ccw_op_hsm_cert obtained in step 2 (step 2.2). The request also includes the end-user certificate identifier end_user_ccw_cert_id. The inclusion of the identifier is necessary so that the CA repository operator can, when requesting, verify that the identifier of the end-user certificate that addressed him and the identifier of the certificate from the request matches.

The ccw_public_key_token request can also be obtained by encrypting and signing on the certificate of the CA storage operator ccw_op_hsm_cert, if there is a need to hide the real address of the CA storage from the client. Otherwise, only the signature is sufficient. Part

- 4 036643 ccw__public_key_token also includes the end_user_ccw_cert_id certificate id.

Thereafter, both requests (ccw_private_key_.token and ccw_public_key_token) are sent to the client in response to his request.

Thus, after this step, the customer has all the information it needs to transact with UCA.

Stage 7. Conducting a transaction for the CA storage.

Now, to conduct a transaction, the client needs to generate the transaction parameters and sign the request with the end_user_ccw_cert certificate obtained in step 5.

To form a transaction, the end user must receive target addresses through the appropriate channels in the form of ccw_public_key_token requests. He can receive them either as a result of direct interaction with other users (for example, by e-mail) or the CA MCC can provide for some public directory for placing such information (for example, directly in the properties of certificates in the CA directory of the CA storage) (step 7.1) ...

Upon receiving the request, the CA warehouse operator performs the following actions (step 7.2):

1. Checks the validity of the request signature.

2. Decrypts (if necessary) the ccwpublickeytoken of the sender of the transaction.

3. Verifies the signature ccw_public_key_token of the sender of the transaction.

4. Decrypts the ccw_private_key_token of the sender of the transaction and obtains the secret key of the CA storage ccw_private_key.

5. Verifies the signature ccw_private_key_token of the sender of the transaction.

6. Decrypts (if necessary) the ccw_public_key_token recipients of the transaction.

7. Verifies the signature ccw_public_key_token of the recipients of the transaction.

8. Checks the validity of the end_user_ccw_cert certificates of the recipients of the transaction.

9. Checks the validity of the end_user_dapc_cert certificates of the recipients of the transaction.

10. Forms and signs the requested transaction on the ccw_private_key key of the transaction sender.

11. Sends the transaction to the network of the corresponding digital asset.

12. Sends a signed confirmation of the transaction to the end user.

This ensures that UCA end users can only transfer transactions to other registered UCA users.

After describing the work of UCA, the proposed technical solution for dividing the “full-featured” CA MCC into two independent components becomes clearer: the MCC itself and the CA storage operator. In the area of the CA warehouse operator, components are collected that work directly with end-user transactions and environments (networks) of digital assets. An organization interested in creating a CA MCC for any purpose may not have such specific competencies. The task of the CA small MCC is to manage the end-user connection to the UCA. In addition, the introduction of an additional independent operator will certainly increase the level of end-users' confidence in the system as a whole.

Let's make one more remark regarding the CA storage operator. As you can see from the above description, the CA warehouse operator does not store the results of his operations. The results of all his transactions are sent either to end users or to the digital asset network. This is a very advantageous property in terms of the ease of implementation of the HSM and the operator in general. However, the ultimate possibilities of such an implementation may not satisfy the requests of the CA MCC organizer.

The following sections discuss additional UCA components that allow you to dynamically manage end-user permissions.

Additional UCA Components.

In describing the basic principles of UCA's operation outlined in the previous section, several important components have been omitted for simplicity. These components are the CA storage directory, as well as the audit and management statements described in steps 8 and 9 in the diagram.

As already noted, a “static” permission management model in which end-user permissions are stored in the certificate and, accordingly, can only be changed by re-issuing the corresponding certificate, which may not always satisfy the requests of the CA's MCC. Thus, to store the directory of end users, associated CA repositories and the corresponding permissions, the repository directory component is introduced. From the side of the CA MCC, the current permissions stored in the directory are controlled by the CA storage management operator.

In connection with the introduction of new components, step 6 can be supplemented with step 9, which will check the current permissions of the end user for the requested transaction.

In addition to managing permissions, the CA MCC may certainly have an interest in ongoing auditing of end-user transactions. To do this, the operator of the audit of the CA storage can also contact the CA storage catalog and, having received the relevant information, audit the target network of the digital asset.

MCC CA may be interested in carrying out operations with storage

- 5 036643 target audience of end users. This may be primarily due to the need to ensure the possibility of the return of funds from a transaction recognized as invalid for some reason. To do this, the operator of the CA storage administration must have access to the secret keys of the CA storage. The most obvious scheme for implementing this requirement is the addition of step 6 with the step of creating a request for a private key encrypted on the CA storage administration operator certificate obtained in step 3. This request can, depending on the operator's requirements, be saved to the CA storage directory or directly transmitted to the CA's MCC for storage and use.

Thus, supplemented with CA storage catalog components and audit and administration operators, UCA acquires the ability to dynamically manage permissions when working with CA storage, audit user transactions and the ability to return fully or partially already completed transactions.

Compared with the known methods, the proposed method allows to fully take into account the interests of the state and regulatory authorities in the infrastructure for servicing digital assets. When a certificate is issued to a client, his mandatory authentication will be carried out, operations with the digital asset store are recorded and managed by managing the corresponding certificates, in addition, legitimate cancellation of transactions is possible.

Claims (7)

CLAIM A method for managing digital assets in a computer system consisting of at least one sender of transactions, at least one recipient of transactions, each of which has a storage of digital assets, at least one operator of a storage of digital assets, characterized in that all participants in the system have certificates of electronic signature, generate requests for transactions that are encrypted and signed with an electronic signature, and to access the storage and carry out the transaction of the sender, they use the secret key, and to access the storage and carry out the recipient's transaction - the public key and provides the following steps: 1) the sender of the transaction generates a request for the transaction, containing in encrypted form the secret key of the transaction, which can only be decrypted by the operator of the digital asset storage, signs this request with his electronic signature and sends it to the operator of the digital asset storage; 2) the operator of the digital asset repository, if necessary, verifies the correctness of the electronic signature of the request from the sender of the transaction and, if the verification of the electronic signature is positive, proceeds to step 3; 3) the digital asset storage operator decrypts the transaction sender's request and receives the sender's digital asset storage secret key; 4) the digital asset storage operator decrypts (if necessary) the public key of the recipient of the transaction; 5) the digital asset storage operator checks the correctness of the electronic signature under the public key of the recipient of the transaction and, if the electronic signature is verified, proceeds to step 6; 6) the operator of the digital asset storage generates the requested transaction on the secret key of the sender's digital asset storage and sends the generated transaction to the recipient, while the transaction is recorded in the network of the corresponding digital asset; 7) the digital asset storage operator sends to the sender and / or the recipient of the transaction an electronically signed confirmation of the transaction.