WO2020162780A1 - Система и способ для безопасного хранения цифровых валют и осуществления транзакций в блокчейн сети - Google Patents

Система и способ для безопасного хранения цифровых валют и осуществления транзакций в блокчейн сети Download PDF

Info

Publication number
WO2020162780A1
WO2020162780A1 PCT/RU2019/000077 RU2019000077W WO2020162780A1 WO 2020162780 A1 WO2020162780 A1 WO 2020162780A1 RU 2019000077 W RU2019000077 W RU 2019000077W WO 2020162780 A1 WO2020162780 A1 WO 2020162780A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction
transactions
digital
users
rules
Prior art date
Application number
PCT/RU2019/000077
Other languages
English (en)
French (fr)
Inventor
Алексей Сергеевич СМИРНОВ
Original Assignee
Алексей Сергеевич СМИРНОВ
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Алексей Сергеевич СМИРНОВ filed Critical Алексей Сергеевич СМИРНОВ
Priority to PCT/RU2019/000077 priority Critical patent/WO2020162780A1/ru
Priority to US16/975,796 priority patent/US11308484B2/en
Publication of WO2020162780A1 publication Critical patent/WO2020162780A1/ru

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H04L9/0897—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage involving additional devices, e.g. trusted platform module [TPM], smartcard or USB
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G06Q20/3674—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes involving authentication
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
    • G06F21/71—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information
    • G06F21/74—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure computing or processing of information operating in dual or compartmented mode, i.e. at least one secure mode
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/04—Payment circuits
    • G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
    • G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/36—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes
    • G06Q20/367—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using electronic wallets or electronic money safes involving electronic purses or money safes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3825—Use of electronic signatures
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G06Q20/3829—Payment protocols; Details thereof insuring higher security of transaction involving key management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/389—Keeping log of transactions for guaranteeing non-repudiation of a transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/405—Establishing or using transaction specific rules
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/083—Network architectures or network communication protocols for network security for authentication of entities using passwords
    • H04L63/0838—Network architectures or network communication protocols for network security for authentication of entities using passwords using one-time-passwords
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/12—Applying verification of the received information
    • H04L63/126—Applying verification of the received information the source of the received data
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/20—Network architectures or network communication protocols for network security for managing network security; network security policies in general
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
    • H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
    • H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H04L9/3255—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures using group based signatures, e.g. ring or threshold signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/327—Short range or proximity payments by means of M-devices
    • G06Q20/3278—RFID or NFC payments by means of M-devices
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/385—Payment protocols; Details thereof using an alias or single-use codes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G06Q20/40145—Biometric identity checks
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q2220/00—Business processing using cryptography
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
    • H04L2209/80—Wireless
    • H04L2209/805—Lightweight hardware, e.g. radio-frequency identification [RFID] or sensor
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/082—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00 applying multi-factor authentication

Definitions

  • the claimed solution relates to a method for carrying out transactions in a blockchain infrastructure using a secure hardware and software complex to ensure secure storage of digital currencies (cryptocurrencies) and manage the entire life cycle of multiple wallets simultaneously to carry out transactions in the blockchain network.
  • the presented technical solution is aimed at eliminating the existing technical problems in this field of technology, and provides increased security for simultaneous work with multiple digital wallets in various blockchain networks and centralized management of their life cycle, and also offers an integrated software and hardware complex for corporate clients , which has a high degree of protection against unauthorized access to private information and its use for transactions in the blockchain infrastructure.
  • the main functionality of the hardware and software complex includes effective management of the full life cycle of cold wallets, the creation of digital wallets and the secure storage of their private keys in an isolated environment using hardware security modules (HSMs), as well as providing multi-level signature control blockchain transactions. All the functionality of the complex can be used by interacting with the program interface (API), which allows you to integrate the complex into existing software solutions, for example, banking systems.
  • API program interface
  • the invention provides a system for securely storing digital currencies, as well as processing and executing transactions in at least one blockchain network, comprising at least a control server associated with at least one blockchain network and providing lifecycle management digital wallets of users, tracking and validation of incoming transactions, formation and primary validation of transactions of blockchain networks, and the server contains administrator module, which is designed to create accounts and manage administrator rights, create accounts and manage user rights, view statistics on users'wallets;
  • a custom module that is configured to create digital wallets for users, assign multisignature rules for transactions and rules for their confirmation by users for each created digital wallet;
  • a database storing information about the addresses of digital wallets, transactions, accounts of administrators and users, their rights and authentication data, about the rules for multisignature and validation of transactions;
  • At least one hardware security module associated with the control server and providing an isolated environment for creating and ensuring the full life cycle of digital wallets, secure storage of private keys of digital wallets, storing the authentication data of administrators and users to ensure the process of transferring addresses of digital wallets to management server, validating transactions, signing confirmed transactions and transferring them to the management server.
  • AMB hardware security module
  • the multisig rules are set when the user's digital wallet is created.
  • the confirmation rules are at least one of: following a hyperlink, entering a code, entering a one-time password, biometric identification, confirmation using a hardware token or cryptographic signature.
  • the multisignature rules include at least one of: M of N signatures, a signature from K groups of users with a quorum within at least L groups.
  • the hardware token is a smart card, USB, or NFC token.
  • control server when processing a transaction for a digital wallet, performs its initial check for compliance with the multisignature conditions and confirmation for said wallet to approve the transaction.
  • control server upon receipt of a request for a transaction via a digital wallet, performs an initial verification of the signatures of all users assigned in the multisignature rules when creating a digital wallet.
  • control server collects primary information on the wallet in the blockchain network and forms on its basis a raw transaction, which is stored in the database.
  • weights and a threshold are set for each of the groups, where the threshold must be exceeded by the sum of the weights of all signers in the group to confirm the transaction.
  • the management server after validating the transaction and initially verifying all signatures, transmits the transaction and signature data to the AMB.
  • AMB checks incoming raw transactions from the control server for the validity of the signatures with which the transaction was confirmed, and, if successful, signs the raw transactions using the private key of the digital wallet corresponding to this transaction.
  • the AMB after signing the raw transaction, transfers the signed transaction to the management server for its subsequent transfer to the blockchain network.
  • a method for performing transactions using digital currencies in a blockchain network comprising the steps of:
  • AMB hardware security module
  • the public key of the created digital wallet and the authentication data of the users assigned to confirm transactions on the created digital wallet are transmitted and stored in the database of the control server;
  • the AMB checks the rules for confirming the transaction by each signer, the conditions for performing the multisignature of the raw transaction, in case of successful verification, the signature of the raw transaction is performed using the private key of the digital wallet for which the transaction was initiated;
  • an administrator account is created and stored on the server with the right to manage administrator accounts, and the administrator account is used to create administrator and / or user accounts that are assigned a set of rights.
  • a user account allows at least one of: initiate transactions, approve and reject transactions, veto transactions for a specified period of time after the transaction has been offered, create digital wallets.
  • the transaction confirmation rules are at least one of: double verification, following a hyperlink, entering a code, entering a one-time password, biometric identification, cryptographic signature, or hardware token confirmation.
  • the multisignature transaction rules include at least one of: M of N signatures, a signature from multiple groups, or a signature from multiple groups with a quorum within a group, and setting a time period for confirming a transaction, after which the transaction is rejected.
  • weights and a threshold are set for each of the groups, and the threshold must be exceeded by the sum of the weights of all signers in the group to confirm the transaction.
  • a time period is set during which the transaction can be vetoed.
  • the AMB is configured with a real-time data replication function that is performed using one or more duplicate AMBs.
  • FIG. 1 illustrates a general view of the system.
  • FIG. 2A illustrates a flow diagram for creating an administrator account.
  • FIG. 2B illustrates a flow diagram for creating a user account.
  • FIG. 2C illustrates a block diagram for creating a digital wallet.
  • FIG. ZA illustrates a block diagram of the formation of a transactional request.
  • FIG. ZV illustrates a block diagram of a transaction request approval.
  • FIG. ST illustrates a flow diagram of a validation of a transaction request by a controller user.
  • FIG. 4 illustrates a schematic diagram of a computing device. DETAILED DESCRIPTION OF THE INVENTION
  • the claimed system (100) includes a control server (software) that processes all incoming requests from users (10) and administrators (20), a hardware security module (AMB) (120), which is connected to the server and is also connected to one or more redundant AMBs (121) - (123).
  • AMB hardware security module
  • the server (110) contains an administrator module (111), which provides the creation of accounts and management of administrator rights, the creation of accounts and management of user rights (10) and provides the ability to obtain detailed information on digital wallets of users.
  • administrator module 111
  • the server (110) contains an administrator module (111), which provides the creation of accounts and management of administrator rights, the creation of accounts and management of user rights (10) and provides the ability to obtain detailed information on digital wallets of users.
  • the server (software) contains a user module (112) that provides the creation of digital wallets for users, assignment of rules for multisignature transactions and rules for their confirmation by users (10) for each created digital wallet.
  • Module (112) also provides processing of user (10) requests, depending on the confirmation rules assigned when creating a digital wallet, connecting users (10) of multifactor authentication methods.
  • the server (110) contains a database (113) that stores information about the addresses of digital wallets, transactions, accounts of administrators and users (10), their rights and authentication data, multisignature rules and transaction validation. This information is used further in the process of performing transactions. Also, the database (113) stores authentication data (public keys) of users (10) and administrators (20) and logs of user actions. The database has high requirements for fault tolerance and data replication. The database (113) can also be replicated and contain multiple associated redundant storage media.
  • Modules (111) and (112) are implemented in the form of application programming interfaces (API) that provide interaction with user interfaces and integration with other software systems.
  • API application programming interfaces
  • Each API interacts with the corresponding web interface: admin panel and client panel, which can be executed on computing devices on the admin and client side, respectively.
  • the User Module (112) can be a separate secure web portal where users (10) can track analytics and history of transactions in their digital wallets, as well as offer and sign transactions depending on the role that a given user has.
  • the system assumes three types of roles: the requesting party (Requestor - a user / group of users who can offer transactions for withdrawal), the approving party (Approver - a user / group of users who must approve a transaction in order for it to become valid and be signed) and controllers (Controller - a user / group of users who have the right to reject a transaction within a certain time after the transaction was created by the requester).
  • the administrator module (111) can be a separate secure web portal where administrators (20) can observe a list of users (10) and their digital wallets, observe digital wallet analytics, including current balances, user's transaction history, and all applications for the input / output of digital assets.
  • Administrators (20) have the ability to approve withdrawal requests in cases where the signature of bank representatives is required. Administrators (20) can also set limits on the withdrawal of digital assets for each specific user (10), so that any transaction exceeding this limit will require manual verification and approval from the bank manager. Similarly for deposits, the administrator (20) can manage a trusted list of addresses (white list), deposits from which are automatically credited to the user's balance (10). If the deposit came from an unknown address, then validation by the manager is required for its crediting. Similarly, administrators (20) can set the limit of the allowable deposit so that in the event of an abnormally large deposit arriving at the user's wallet (10), they can request a proof of source of funds from him before the funds are credited to his account.
  • user roles 10
  • Requestor is a user / group of users who can offer transactions for withdrawal
  • Approver is a user / group users who must approve the transaction in order for it to become valid and signed
  • Controller - user / group of users who have the right to reject the transaction within a certain time after the transaction was created by the requester multisignature transaction rules (transaction signing mechanics), and a method for confirming transactions.
  • M of N signatures signature from K groups of users with quorum within at least L groups.
  • Some of the methods for confirming transactions may include, for example, following a hyperlink, entering a code, entering a one-time password, biometric identification, confirmation with a hardware token or cryptographic signature.
  • a smart card, USB or NFC token, etc. can be used as a hardware token.
  • the administrator module (111) also provides the creation of a trusted address list (white list) for the withdrawal of digital assets, management of procedures for restoring access to users (10) in case of loss of account credentials or loss of a hardware token, for example, a smart card.
  • the manager can also register new users (10), restrict user access (10) to the account and put users (10) in read-only mode, preventing them from performing any actions with transactions on their digital wallets.
  • Control Server (110) is also connected to the blockchain network (150), through which transactions are carried out in various blockchain networks.
  • ABM (120) is a physical computing device that allows generating, storing, and managing digital keys.
  • the module can be used in any application that uses digital keys. Since all cryptographic operations are performed directly by the module (120) itself, this allows you to organize an additional security loop when performing transactions and checking cryptographic keys in an isolated environment.
  • AMB (120) is isolated from the public Internet, which makes it possible to secure the process of checking the necessary information before carrying out the transaction itself in the blockchain network (150) and excludes the possibility of any data leakage.
  • One or several well-known solutions from such manufacturers as: Securosys SA, Gemalto, Utimaco, Demos, etc. can be used as AMB (120) (English HSM - Hardware Security Module).
  • AMB (120) can be performed with a real-time data replication function that is performed using one or more duplicating AMB, which allows to increase the safety of information and the overall fault tolerance of the system.
  • AMB (120) provides an isolated secure environment for generating and storing digital wallet addresses and private keys, as well as signing approved withdrawal transactions.
  • AMB (120) stores authentication information, including the public keys of all users (10).
  • Another feature of AMB (120) is the provision of random generation of private keys with very high entropy.
  • the general principle of operation of the claimed system (100) is the multi-factor confirmation of transactions before they are sent to the blockchain (150).
  • the server (110) receives and validates user requests (10) to create digital wallets, and also provides storage of data about users' digital wallets (10), while creating digital wallets for each of them, rules for multisignature of transactions and rules for their confirmation by users are established (ten).
  • the Control Server (110) processes incoming requests for the creation of digital wallets by users (10), carries out procedures for verifying the signature of requests using the authentication data of users and provides the formation of raw (primary) transactions, which are subsequently transmitted for their further confirmation to the AMB ( 120).
  • AMB (120) performs additional verification of the signatures of all requests for signing the raw transaction with the private key of the corresponding digital wallet and sending the signed transaction to the management server (110) for further transmission to the blockchain network (150). If the procedure for checking the transaction confirmation rules and user signatures (319) and checking the multisignature conditions (320) in AMB (120) is successful, then AMB (120) performs the procedure for signing the received raw transaction and sends the signed transaction back to the server (software), which subsequently forwards the signed transaction for execution to the blockchain network (150).
  • AMB (120) provides secure storage of private keys of digital wallets, which are created on AMB (120) based on a confirmed request received from the management server (110).
  • AMB (120) stores the authentication data of administrators and users for validating transactions and requests to create wallets.
  • FIG. 2A shows the process of creating an administrator account
  • the creation of an administrator account (210) is performed based on the creation of a primary control command generated by the module (111).
  • a command can be a registration with the corresponding rights of a person who will be granted administrator rights (20).
  • Such rules can be the setting of limits on the withdrawal of digital assets from digital wallets and the approval of incoming transactions.
  • a request is generated to create an administrator account (212), which is signed (213) using an administrator hardware token, for example, a smart card that contains a private cryptographic key.
  • the signed request (213) is sent to the server (110) to the administrator module (111).
  • the request (213) is transmitted to the AMB (120) for further verification.
  • the signature of the request (218) is verified, in particular the administrator's private key, with which the request was signed (213).
  • a public key (219) is generated for this request, which is stored in the AMB database (120) for the corresponding authentication data of the administrator. Further, information about the created account, its data and the generated public key are transferred (217) to the server database (113).
  • FIG. 2B shows the process of creating a user account (220).
  • the creation of an account (220) is carried out by the administrator (20) using the administrator module (111).
  • the signed request to create a user account (223) is transmitted to the server (software) for further processing.
  • the server (software) verifies the user signature (225), with which the request was signed (223). If verification fails, then the request to create a user account (10) is rejected (226).
  • the request (223) is transmitted to the AMB (120) for further verification.
  • the signature of the request (228) is checked against the stored authentication data.
  • a new user is created in the AMB (120) and his authentication data (public key) (229) is saved.
  • the information about the created account (220), and the authentication data is transmitted to the management server (227), where it is stored in the database (113).
  • the user module (112) is assigned roles to the user account (10).
  • the user (10) can be made responsible for confirming and controlling transactions for a given wallet, as well as for one or more other digital wallets.
  • the role of a user account can be different for different digital wallets.
  • FIG. 2C presents a procedure (230) for creating a digital wallet for carrying out transactions with digital assets, in particular cryptocurrency.
  • the user (10) receives a request to create a digital wallet.
  • the request (231) includes the type of cryptocurrency, multisignature rules and transaction confirmation rules, and is generated using a custom module (112).
  • the request (231) to create a digital wallet is signed with the user's private key (232) stored on the user's hardware token.
  • the signed request is sent to the server (110) for its subsequent validation (233).
  • the validation process (233) consists in processing the authentication data of the user account (220), in particular, checking the signature of the request (231) for compliance with the authentication data, in particular, the public key stored in the server database (113). Also, in the verification process (233), the rights of the user (10) are checked. [0069] After successful validation of the request on the management server (software), the user request is transmitted to the AMB (120) where the validation process (234) is also performed, during which it is checked that the signature of the request (232) matches the public key stored in the AMB ( 120).
  • a public / private key pair (235) is generated for the new digital wallet. Also, the AMB (120) stores the parameters for the created wallets and the multisignature and transaction confirmation rules for these wallets (236). As a result of processing a request to create a digital wallet, information on the successful status of the procedure (230) for creating a digital wallet and its public key are transmitted to the server (237).
  • M of N signatures signature from K groups of users with a quorum within at least L groups.
  • the digital wallet can be used for various types of cryptocurrencies, for example, BTC, BCH, ETH, ETC, ERC20, ERC223, LTC, etc.
  • FIG. 3A - Fig. ZV presents the process of making transactions using digital wallets of users.
  • a request to execute a transaction is made with the help of the requested party (301).
  • the generated request (301) is signed using the user's private key (302) and transmitted to the server (110) for further processing.
  • the transactional request (301), as a rule, comes from the user (30), who was assigned the role of the filling party - "requestor" during registration.
  • the server (110) Upon receipt of the signed request (302), the server (110) performs the transaction validation process, verifying that all conditions specified when creating the wallet of the user (30) requesting the transaction are met. The server (110) checks the role (303) of the user (30) requesting the execution of the transaction. Next, the signature of the transaction request (304) is checked for compliance with the authentication data, in particular, the user's public key, which is stored in the server database (113). If the check is not successful, then the transaction request is refused, and a corresponding notification is sent to the user (30).
  • the server After successful verification at step (304), the server (software) collects primary data on the digital wallet in the blockchain network (305). Such information can be, for example, the balance of a digital wallet, transaction history, etc.
  • primary data can be, for example, the balance of a digital wallet, transaction history, etc.
  • step (306) based on the primary data obtained at step (305), a raw transaction is generated and this transaction is saved (307) on the management server (110).
  • FIG. The IO presents a process for verifying the transaction created in step (307) by the approver (31).
  • the user checks all the transaction parameters for the digital wallet, such as transaction size, recipient address, etc. If the verification succeeds, then a request for approval of the transaction (312) is generated, which is signed (313) with the private key of the approving party (31). The signed request (313) is sent to the server (110).
  • the server (HO) checks (314) the established rules for confirming the transaction, as well as the signature of the party (31) with which the request was signed (313).
  • a check (315) of the established user role (31) is carried out and a check of the fulfillment of the multisignature conditions (316), i.e. that the transactional request was signed by all established users.
  • the management server (110) sends the raw transaction and signed requests of users who approved the transaction to the AMB (120). Also, in the server database (113), a record of the request for approval of the transaction (317) is performed. If the multisignature condition for the raw transaction is not met, then waiting for a specified period of time for the signing of the transaction by all established users is performed. If the transaction is not signed at the specified time, the transaction request is rejected.
  • the AMB (120) checks (319) the rules for confirming the transaction by each signer and the conditions for performing the multisignature (320) of the received raw transaction. In case of successful verification, using the program logic of AMB (120), the signature (321) of the raw transaction is performed using the private key of the digital wallet, which was used to initiate the request for approval of the transaction (313).
  • the signed transaction is transmitted from the AMB (120) to the management server (110), from which it is further transmitted to the blockchain network (150).
  • FIG. The ST represents the process of verifying a transaction using a user account (33), which has been assigned the role of a controller. Based on the information received about the generated raw transaction, the user (33) checks its parameters, such as the size of the transaction, the address of the recipient, etc.
  • the user (33) makes a decision to approve the transaction request (332) or to reject this request (333).
  • the user (33) signs the request to reject the transaction using his private key (334) and sends the signed request to the server (software).
  • a check (335) is performed on the role of the user (33) to reject transactional requests, as well as the signature (336), with which the corresponding request to reject the transaction was signed.
  • the server (110) stores the status of the completed request to reject the transaction (337), and the transaction is transferred to the rejected status.
  • the user account allows you to initiate transactions, approve and reject transactions, veto transactions for a certain period of time after the transaction has been proposed, and create digital wallets, if such authority was generated using the administrator module (111).
  • Rules for multisig transactions include, for example, M of N signatures, signature from multiple groups, or signature from multiple groups with quorum within a group, and setting a time period for transaction confirmation after which the transaction is rejected.
  • a weighting factor and a threshold can be set for each of the user groups assigned to a given digital wallet to confirm a transaction.
  • the threshold value must be exceeded by the sum of the weights of all signers in the group for the transaction confirmation procedure to proceed.
  • a time period can be set during which the transaction can be vetoed.
  • FIG. 4 shows an example of a computing device (400), on the basis of which, for example, a server (software) or other devices can be executed, with the help of which it is possible to interact with the declared system and carry out transactions with digital assets.
  • the device (400) can be selected from a wide range of electronic devices known in the art, for example, personal computers, laptops, tablets, supercomputers, server clusters, smartphones, and the like.
  • the device (400) may contain one or more processors (401) or one or more microcontrollers, RAM (402), persistent data storage (403), input / output interfaces (404), input / output devices (405), network interactions (406).
  • the processor (401) is the main computing module that provides logical processing of algorithmic instructions necessary for the device (400) to perform the necessary functions.
  • RAM (402) is a standard random access memory designed to store instructions executed by the processor that implement the work of the embedded program logic.
  • the means for permanent storage of data may be, but is not limited to: hard disk drive (HDD), flash memory (NAND, EEPROM, SD cards, etc.), solid state drive (SSD), optical drives data (CD / DVD / BlueRay discs, etc.).
  • HDD hard disk drive
  • flash memory NAND, EEPROM, SD cards, etc.
  • SSD solid state drive
  • optical drives data CD / DVD / BlueRay discs, etc.
  • I / O interfaces (404) may be, but are not limited to: ADC / DAC, USB (micro-, Type C, mini-, etc.), PS / 2, PCI, VGA, RS232, RJ45, FireWire, SATA, IDE, COM, LPT, Audio Jack, HDMI, Display Port, Lightning, etc.
  • the I / O means may be, but are not limited to: display, touch display, keyboard (mechanical, touch, projection, etc.), trackball, joystick, touch pad, speakers, microphone, projector, indicator light, buzzer, biometric sensor (fingerprint scanner, retina, iris, voice, palm, vein pattern, etc.), camera, optical sensor, accelerometer, gyroscope, light sensor, proximity sensor, gravity sensor, etc. P.
  • the networking tool (406) may be, but is not limited to: Bluetooth module, BLE module, NFC, Ethernet card, modem, router, IrDa, GSM modem, GPRS modem, LTE modem, 5 G modem , WLAN, Wi-Fi module, satellite modem, GNSS receiver, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Computer Security & Cryptography (AREA)
  • Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • General Engineering & Computer Science (AREA)
  • Computing Systems (AREA)
  • Development Economics (AREA)
  • Economics (AREA)
  • Software Systems (AREA)
  • Mathematical Physics (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • General Health & Medical Sciences (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Storage Device Security (AREA)

Abstract

Заявленное решение относится к способу осуществления транзакций в блокчейн инфраструктуре с помощью защищенного программно-аппаратного комплекса для обеспечения безопасного хранения цифровых валют (криптовалют) и управления всем жизненным циклом множества кошельков одновременно для осуществления транзакций в блокчейн сети. К основному функционалу программно-аппаратного комплекса относится эффективное управление полным жизненным циклом холодных кошельков, создание цифровых кошельков и безопасное хранение их приватных ключей в изолированной среде с использованием аппаратных модулей безопасности (HSM - Hardware Security Module), а также обеспечение многоуровневого контроля подписи блокчейн транзакций. Все функциональные возможности комплекса могут использоваться за счет взаимодействия с программным интерфейсом (API), который позволяет интегрировать комплекс в уже существующие программные решения, например, банковские системы.

Description

СИСТЕМА И СПОСОБ ДЛЯ БЕЗОПАСНОГО ХРАНЕНИЯ ЦИФРОВЫХ ВАЛЮТ И ОСУЩЕСТВЛЕНИЯ ТРАНЗАКЦИЙ В БЛОКЧЕЙН СЕТИ
ОБЛАСТЬ ТЕХНИКИ
[0001] Заявленное решение относится к способу осуществления транзакций в блокчейн инфраструктуре с помощью защищенного программно-аппаратного комплекса для обеспечения безопасного хранения цифровых валют (криптовалют) и управления всем жизненным циклом множества кошельков одновременно для осуществления транзакций в блокчейн сети.
УРОВЕНЬ ТЕХНИКИ
[0002] С развитием блокчейн инфраструктуры для осуществления транзакций в различных блокчейн сетях, важной проблемой стало обеспечение безопасного хранения средств на кошельках, которые, как правило, являются программным приложением и подвержены риску программного взлома и утечки конфиденциальных данных.
[0003] Альтернативой программным кошелькам являются аппаратные кошельки, обеспечивающие сохранность приватных ключей и осуществляющие оффлайн подпись блокчейн транзакций. Однако, для крупных инвесторов и организаций, предоставляющих кастодиальные услуги (банки, фонды и пр.), требуется качественно новый подход хранения цифровых активов, который обеспечивает высокие требования безопасности для тысяч блокчейн кошельков одновременно. При этом возникает необходимость в централизованном и безопасном управлении жизненным циклом криптографических ключей— их генерации, распределении, холодном хранении и резервировании. Все эти функции должны выполняться в изолированной среде, защищенной от любых внешних воздействий.
[0004] Для решения данной проблемы на текущий момент предлагаются различные решения, которые используют аппаратные средства защиты ключевой информации для управления цифровыми кошельками и формирования блокчейн транзакций. Однако, на текущий момент нет решения, которое бы позволяло с должной степенью защиты осуществлять централизованное управление процессом создания и управления цифровыми кошельками, а также обеспечивало гибкую настройку правил мультиподписи, правил подтверждения транзакции и их валидацию в изолированной безопасной среде.
[0005] В качестве примера, такой подход был предложен в решении, описанном в патентной заявке US 20150287026 (Modernity Financial Holdings, Ltd., 08.10.2015), который предполагает использование аппаратных модулей для холодного хранения резервных копий ключей от цифровых кошельков клиентов, а также предлагался принцип подтверждения транзакций в виде мультиподписи. Однако, такой подход имеет существенные недостатки, заключающиеся в том, что мультиподпись формируется исходя из заданной последовательности подтверждения транзакции от установленных серверов, которые должны подтвердить факт осуществления транзакции, и использование холодного хранилища заключается исключительно в целях хранения резервных копий ключей от цифровых кошельков, что не подразумевает использование данных аппаратных средств в процессе осуществления транзакций.
СУЩНОСТЬ ИЗОБРЕТЕНИЯ
[0006] Представленное техническое решение направлено на устранение существующих технических проблем в данной области техники, и обеспечивает повышенную безопасность для одновременной работы с множеством цифровых кошельков в различных блокчейн сетях и централизованного управления их жизненным циклом, а также предлагает интегрированный программно-аппаратный комплекс для корпоративных клиентов, обладающий высокой степенью защиты от несанкционированного доступа к приватной информации и ее использования для осуществления транзакций в блокчейн инфраструктуре.
[0007] К основному функционалу программно-аппаратного комплекса относится эффективное управление полным жизненным циклом холодных кошельков, создание цифровых кошельков и безопасное хранение их приватных ключей в изолированной среде с использованием аппаратных модулей безопасности (HSM - Hardware Security Module), а также обеспечение многоуровневого контроля подписи блокчейн транзакций. Все функциональные возможности комплекса могут использоваться за счет взаимодействия с программным интерфейсом (API), который позволяет интегрировать комплекс в уже существующие программные решения, например, банковские системы.
[0008] В предпочтительном варианте осуществления изобретения предлагается система для безопасного хранения цифровых валют, а также обработки и осуществления транзакций в по меньшей мере одной блокчейн сети, содержащая по меньшей мере управляющий сервер, связанный с по меньшей мере одной блокчейн сетью и обеспечивающий управление жизненным циклом цифровых кошельков пользователей, отслеживание и валидацию входящих транзакций, формирование и первичную валидацию транзакций блокчейн сетей, причем сервер содержит модуль администратора, который выполнен с возможностью создания аккаунтов и управления правами администраторов, создания аккаунтов и управления правами пользователей, возможностью просмотра статистики по кошелькам пользователей;
пользовательский модуль, который выполнен с возможностью создания цифровых кошельков пользователей, назначения правил мультиподписи транзакций и правил их подтверждения пользователями для каждого создаваемого цифрового кошелька;
обработки пользовательских запросов в зависимости от правил подтверждения, назначенных при создании цифрового кошелька;
подключения пользователями методов мультифакторной аутентификации;
базу данных, хранящую информацию об адресах цифровых кошельков, транзакциях, аккаунтах администраторов и пользователей, их правах и аутентификационных данных, о правилах мультиподписи и валидации транзакций;
по меньшей мере один аппаратный модуль безопасности (АМБ), связанный с управляющим сервером и обеспечивающий изолированную среду для создания и обеспечения полного жизненного цикла цифровых кошельков, безопасного хранения приватных ключей цифровых кошельков, хранения аутентификационных данных администраторов и пользователей для обеспечения процесса передачи адресов цифровых кошельков на управляющий сервер, валидации транзакций, подписи подтвержденных транзакций и их передачи на управляющий сервер.
[0009] В одном из частных вариантов осуществления системы правила мультиподписи устанавливается при создании цифрового кошелька пользователя.
[0010] В другом частном варианте осуществления системы правила подтверждения представляют собой по меньшей мере одно из: переход по гиперссылке, ввод кода, ввод одноразового пароля, биометрическая идентификация, подтверждение с помощью аппаратного токена или криптографической подписью.
[ООН] В другом частном варианте осуществления системы правила мультиподписи включают в себя по меньшей мере одно из: М из N подписей, подпись от К групп пользователей с кворумом внутри по меньшей мере L групп.
[0012] В другом частном варианте осуществления системы аппаратный токен представляет собой смарт-карту, USB или NFC токен.
[0013] В другом частном варианте осуществления системы при обработке транзакции для цифрового кошелька управляющий сервер осуществляет ее первичную проверку на предмет соблюдения условий мультиподписи и подтверждения для упомянутого кошелька для одобрения транзакции. [0014] В другом частном варианте осуществления системы при получении запроса на транзакцию по цифровому кошельку, управляющий сервер по аутентификационным данным осуществляет первичную проверку подписей всех пользователей, назначенных в правилах мультиподписи при создании цифрового кошелька.
[0015] В другом частном варианте осуществления системы после валидации запроса создания транзакции, управляющий сервер осуществляет сбор первичной информации по кошельку в сети блокчейн и формирует на ее основании сырую транзакцию, которая сохраняется в базе данных.
[0016] В другом частном варианте осуществления системы для каждой подписи устанавливаются весовые коэффициенты и пороговое значение для каждой из групп, причем пороговое значение должно быть превышено суммой весов всех подписантов группы, для подтверждения транзакции.
[0017] В другом частном варианте осуществления системы после валидации транзакции и первичной проверки всех подписей, управляющий сервер передает данные транзакции и подписей на АМБ.
[0018] В другом частном варианте осуществления системы по аутентификационным данным АМБ осуществляет проверку поступающих сырых транзакций от управляющего сервера на предмет валидности подписей, с помощью которых была подтверждена транзакция, и в случае успешной проверки осуществляет подпись сырых транзакций с помощью приватного ключа цифрового кошелька, соответствующего данной транзакции.
[0019] В другом частном варианте осуществления системы после подписания сырой транзакции АМБ осуществляет передачу подписанной транзакции на управляющий сервер для ее последующей передачи в блокчейн сеть.
[0020] В другом предпочтительном варианте осуществления представленного решения предложен способ выполнения транзакций с использованием цифровых валют в блокчейн сети, содержащая этапы, на которых:
- принимают на управляющем сервере запрос на создание цифрового кошелька для осуществления транзакций с помощью цифровых валют, в котором устанавливают правила мультиподписи транзакций и правила подтверждения транзакций пользователями для созданного цифрового кошелька, причем правила мультиподписи включают в себя по меньшей мере данные пользователей, назначенных для подписи транзакции;
- по аутентификационным данным осуществляют проверку прав и подписи запроса на создание цифрового кошелька; - передают подписанный запрос в аппаратный модуль безопасности (АМБ), на котором создают цифровой кошелек пользователя путем генерации приватного и публичного ключей;
сохраняют в АМБ приватный и публичный ключи цифрового кошелька и аутентификационные данные пользователей, назначенных для подтверждения транзакций по созданному цифровому кошельку;
передают и сохраняют в базу данных управляющего сервера публичный ключ созданного цифрового кошелька и аутентификационные данные пользователей, назначенных для подтверждений транзакций по созданному цифровому кошельку;
- получают на управляющем сервере запрос на выполнение транзакции по одному из созданных цифровых кошельков;
осуществляют на управляющем сервере сбор первичных данных по цифровому кошельку в сети блокчейн;
- на основании первичных данных формируют сырую транзакцию и сохраняют первичную транзакцию на управляющем сервере;
- осуществляют подтверждение сырой транзакции всеми пользователями с помощью установленных правил мультиподписи транзакций и правил подтверждения транзакций для данного цифрового кошелька;
- после проверки подтверждения транзакции управляющим сервером передают сырую транзакцию и подписи пользователей, подтвердивших транзакцию, на АМБ;
- по аутентификационным данным осуществляют на АМБ проверку правил подтверждения транзакции каждым подписантом, условий выполнения мультиподписи сырой транзакции, в случае успешной проверки, выполняют подпись сырой транзакции с помощью приватного ключа цифрового кошелька по которому была инициирована транзакция;
- передают подписанную транзакцию на управляющий сервер для ее дальнейшей передачи в блокчейн сеть.
[0021] В одном из частных вариантов осуществления способа создают и сохраняют на сервере учетную запись администратора с правом управления аккаунтами администраторов, причем с помощью учетной записи администратора выполняют создание учетных записей администраторов и/или пользователей, которым назначается набор прав.
[0022] В другом частном варианте осуществления способа учетная запись пользователя позволяет по меньшей мере одно из: инициировать транзакции, одобрять и отклонять транзакции, накладывать вето на транзакции в течение определенного периода времени после того как транзакция была предложена, создавать цифровые кошельки.
[0023] В другом частном варианте осуществления способа правила подтверждения транзакции представляют собой по меньшей мере одно из: двойная верификация, переход по гиперссылке, ввод кода, ввод одноразового пароля, биометрическая идентификация, криптографическая подпись или подтверждение с помощью аппаратного токена.
[0024] В другом частном варианте осуществления способа правила мультиподписи транзакций включают в себя по меньшей мере одно из: М из N подписей, подпись от нескольких групп, или подпись от нескольких групп с кворумом внутри группы, а также установление временного периода для подтверждения транзакции, по истечении которого транзакция отклоняется.
[0025] В другом частном варианте осуществления способа для каждой подписи устанавливаются весовые коэффициенты и пороговое значение для каждой из групп, причем пороговое значение должно быть превышено суммой весов всех подписантов группы, для подтверждения транзакции.
[0026] В другом частном варианте осуществления способа для каждой инициированной транзакции устанавливается временной период, в течение которого на транзакцию может быть наложено вето.
[0027] В другом частном варианте осуществления способа АМБ выполнен с функцией репликации данных в режиме реального времени, которая выполняется с помощью одного или нескольких дублирующих АМБ.
ЧЕРТЕЖИ
[0028] Фиг. 1 иллюстрирует общий вид системы.
[0029] Фиг. 2А иллюстрирует блок-схему создания учетной записи администратора.
[0030] Фиг. 2В иллюстрирует блок-схему создания учетной записи пользователя.
[0031] Фиг. 2С иллюстрирует блок-схему создания цифрового кошелька.
[0032] Фиг. ЗА иллюстрирует блок-схему формирования транзакционного запроса.
[0033] Фиг. ЗВ иллюстрирует блок-схему одобрения транзакционного запроса.
[0034] Фиг. ЗС иллюстрирует блок-схему проверку транзакционного запроса пользователем-контроллером .
[0035] Фиг. 4 иллюстрирует схему вычислительного устройства. ДЕТАЛЬНОЕ ОПИСАНИЕ ИЗОБРЕТЕНИЯ
[0036] Как показано на Фиг. 1, заявленная система (100) включает в себя управляющий сервер (ПО), осуществляющий обработку всех поступающих запросов от пользователей (10) и администраторов (20), аппаратный модуль безопасности (АМБ) (120), который связан с сервером и также связан с одним или несколькими резервирующими АМБ (121) - (123).
[0037] Сервер (110) содержит модуль администратора (111), который обеспечивает создание аккаунтов и управления правами администраторов, создание аккаунтов и управления правами пользователей (10) и обеспечивает возможность получения детализированной информации по цифровым кошелькам пользователей.
[0038] Также сервер (ПО) содержит пользовательский модуль (112), который обеспечивает создание цифровых кошельков пользователей, назначение правил мультиподписи транзакций и правил их подтверждения пользователями (10) для каждого созданного цифрового кошелька. Модуль (112) также обеспечивает обработку пользовательских (10) запросов в зависимости от правил подтверждения, назначенных при создании цифрового кошелька, подключение пользователями (10) методов мультифакторной аутентификации.
[0039] Сервер (110) содержит базу данных (113), которая хранит информацию об адресах цифровых кошельков, транзакциях, аккаунтах администраторов и пользователей (10), их правах и аутентификационных данных, правилах мультиподписи и валидации транзакций. Данная информация используется в дальнейшем в процессе выполнения транзакций. Также база данных (113) хранит аутентификационные данные (публичные ключи) пользователей (10) и администраторов (20) и логи действий пользователей. К базе данных предъявляются высокие требования по отказоустойчивости и реплицированию данных. База данных (113) также может выполняться с функцией репликации и содержать несколько связанных резервирующих средств хранения данных.
[0040] Модули (111) и (112) выполняются в виде программных интерфейсов приложений (API), обеспечивающих взаимодействие с пользовательскими интерфейсами и интеграцию с другими программными комплексами. Каждое API взаимодействует с соответствующим веб-интерфейсом: панелью администратора и панелью клиента, которые могут выполняться на вычислительных устройствах на стороне администратора и клиента, соответственно.
[0041] Пользовательский модуль (112) может представлять собой отдельный защищенный веб-портал, на котором пользователи (10) могут отслеживать аналитику и историю транзакций по своим цифровым кошелькам, а также предлагать и подписывать транзакции в зависимости от роли, которой обладает данный пользователь. В системе предполагается три вида ролей: запрашивающая сторона (Requestor - пользователь/группа пользователей, которые могут предлагать транзакции на вывод), одобряющая сторона (Approver - пользователь/группа пользователей, которые должны одобрить транзакцию для того, чтобы она стала валидной и была подписана) и контроллеры (Controller - пользователь/группа пользователей, которые обладают правом отклонить транзакцию в течение определенного времени после того, как транзакция была создана запрашивающей стороной).
[0042] Модуль администратора (111) может представлять собой отдельный защищенный веб-портал, в котором администраторы (20) могут наблюдать список пользователей (10) и их цифровых кошельков, наблюдать аналитику по цифровым кошелькам, включая текущие балансы, историю транзакций пользователя и все заявки на ввод/вывод цифровых активов.
[0043] Администраторы (20) имеют возможность одобрять заявки на вывод в тех случаях, когда требуется подпись представителей банка. Администраторы (20) могут также выставить лимиты на вывод цифровых активов для каждого конкретного пользователя (10), так что любая транзакция, превышающая данный лимит, потребует ручной проверки и одобрения со стороны менеджера банка. Аналогично для депозитов, администратор (20) может управлять доверенным листом адресов (white list), депозиты с которого автоматически засчитываются на баланс пользователя (10). Если же депозит пришел с неизвестного адреса, то для его зачисления потребуется валидация со стороны менеджера. Аналогично администраторы (20) могут задавать предел допустимого депозита, чтобы в случае поступления аномально большого депозита на кошелек пользователя (10) иметь возможность запросить у него соответствующее доказательство (proof of source of funds) до того, как средства будут зачислены на его счет.
[0044] При создании цифрового кошелька с помощью пользовательского модуля (112) может выполняться настройка ролей пользователей (10) (запрашивающая сторона (Requestor) - пользователь/группа пользователей, которые могут предлагать транзакции на вывод; одобряющая сторона (Approver) - пользователь/группа пользователей, которые должны одобрить транзакцию для того, чтобы она стала валидной и была подписана; контроллер (Controller) - пользователь/группа пользователей, которые обладают правом отклонить транзакцию в течение определенного времени после того, как транзакция была создана запрашивающей стороной), правил мультиподписи транзакций (механики подписи транзакций) и способ подтверждения транзакций.
[0045] В качестве правил мультиподписи транзакций могут использоваться следующие подходы: М из N подписей, подпись от К групп пользователей с кворумом внутри по меньшей мере L групп.
[0046] В части способов подтверждения транзакций могут использоваться, например, переход по гиперссылке, ввод кода, ввод одноразового пароля, биометрическая идентификация, подтверждение с помощью аппаратного токена или криптографической подписью. В качестве аппаратного токена может применяться смарт-карта, USB или NFC- токен и т.п.
[0047] Модуль администратора (111) также обеспечивает создание доверенного списка адресов (white list) для вывода цифровых активов, управление процедурами восстановления доступа пользователей (10) в случае утери им реквизитов доступа к кабинету или утрате аппаратного токена, например, смарт карты.
[0048] С помощью панели администратора менеджер также может регистрировать новых пользователей (10), ограничивать доступ пользователей (10) к аккаунту и переводить пользователей (10) в режим просмотра (read-only mode), запрещая им производить какие-либо действия с транзакциями по их цифровым кошелькам.
[0049] Управляющий сервер (110) связан также с блокчейн сетью (150), через которую осуществляются транзакции в различных блокчейн сетях.
[0050] АБМ (120) представляет собой физическое вычислительное устройство, которое позволяет формировать, хранить и управлять цифровыми ключами. Модуль может применяться в любом приложении, использующем цифровые ключи. Так как все криптографические операции выполняются непосредственно самим модулем (120), это позволяет организовать дополнительный контур безопасности при выполнении транзакций и проверке криптографических ключей в изолированной среде. АМБ (120) является изолированным от общедоступной сети Интернет, что позволяет обезопасить процесс проверки необходимой информации перед осуществлением самой транзакции в блокчейн сети (150) и исключает возможность утечки каких-либо данных. В качестве АМБ (120) (англ. HSM - Hardware Security Module) может использоваться одно или несколько известных решений таких производителей, как: Securosys SA, Gemalto, Utimaco, Demos и др.
[0051] АМБ (120) может быть выполнен с функцией репликации данных в режиме реального времени, которая выполняется с помощью одного или нескольких дублирующих АМБ, что позволяет повысить сохранность информации и общую отказоустойчивость системы.
[0052] АМБ (120) обеспечивает изолированную безопасную среду для генерации и хранения адресов цифровых кошельков и приватных ключей, а также подписи одобренных транзакций по выводу средств. АМБ (120) хранит аутентификационную информацию, в том числе публичные ключи всех пользователей (10). Еще одна особенность АМБ (120) - обеспечение случайной генерации приватных ключей с очень высокой энтропией.
[0053] Общий принцип работы заявленной системы (100) заключается в многофакторном подтверждении транзакций перед их отправкой в блокчейн (150). Сервер (110) осуществляет получение и валидацию запросов пользователей (10) на создание цифровых кошельков, а также обеспечивает хранение данных о цифровых кошельках пользователей (10), при этом при создании цифровых кошельков для каждого из них устанавливаются правила мультиподписи транзакций и правила их подтверждения пользователями (10).
[0054] Управляющий сервер (110) выполняет обработку поступающих запросов на создание цифровых кошельков пользователями (10), осуществляет процедуры проверки подписи запросов с помощью аутентификационных данных пользователей и обеспечивает формирование сырых (первичных) транзакций, которые впоследствии передаются для их дальнейшего подтверждения в АМБ (120).
[0055] АМБ (120) осуществляет дополнительную проверку подписей всех запросов для подписания сырой транзакции приватным ключом соответствующего цифрового кошелька и отправкой подписанной транзакции на управляющий сервер (110) для дальнейшей передачи в сеть блокчейн (150). Если процедура проверки правил подтверждения транзакции и подписей пользователя (319) и проверки условий мультиподписи (320) в АМБ (120) проходит успешно, то АМБ (120) осуществляет процедуру подписания полученной сырой транзакции и передает подписанную транзакцию обратно на сервер (ПО), который впоследствии направляет подписанную транзакцию для выполнения в сеть блокчейн (150).
[0056] АМБ (120) обеспечивает безопасное хранение приватных ключей цифровых кошельков, которые создаются на АМБ (120) на основании подтвержденного запроса, полученного от управляющего сервера (110). АМБ (120) хранит аутентификационные данные администраторов и пользователей для валидации транзакций и запросов на создание кошельков. [0057] На Фиг. 2 А представлен процесс создания учетной записи администратора
(210) на управляющем сервере (110) с помощью модуля администратора (111). Создание учетной записи администратора (210) выполняется на основании создания первичной управляющей команды, формируемой посредством модуля (111). Такой командой может выступать регистрация с соответствующими правами лица, которому будут предоставлены права администратора (20). При создании управляющей команды на создание учетной записи администратора (210) на управляющем сервере (ПО), задаются его аутентификационные данные (например, логин/пароль, публичный ключ) и набор прав
(211). Такими правилами могут выступать установка лимитов на вывод цифровых активов с цифровых кошельков и одобрением входящих транзакций.
[0058] На основании сформированной команды (211) выполняется формирование запроса на создание учетной записи администратора (212), который подписывается (213) с помощью аппаратного токена администратора, например, смарт-карты, которая содержит приватный криптографический ключ. Подписанный запрос (213) передается на сервер (110) в модуль администратора (111).
[0059] После получения подписанного запроса (213) на создание учетной записи администратора (210) на сервере (ПО) выполняется его последующая проверка (214). В ходе проверки (214) выполняется проверка подписи администратора (215), с помощью которой было выполнено подписание запроса (213). Если проверка не выполняется, то запрос на создание учетной записи администратора (210) отклоняется (216).
[0060] Если проверка подписи (215) запроса проходит успешно, то далее запрос (213) передается в АМБ (120) для дальнейшей проверки. На АМБ (120) осуществляется проверка подписи запроса (218), в частности приватного ключа администратора, с помощью которого был подписан запрос (213). После успешной проверки подписи запроса на АМБ (120) для данного запроса формируется публичный ключ (219), который сохраняется в БД АМБ (120) для соответствующих аутентификационных данных администратора. Далее информация о созданной учетной записи, ее данные и сформированный публичный ключ передаются (217) в БД сервера (113).
[0061] На Фиг. 2В представлен процесс создания учетной записи пользователя (220). Создание учетной записи (220) осуществляется администратором (20) с помощью модуля администратора (111).
[0062] При создании учетной записи пользователя (220) задаются его аутентификационные данные и определяется набор прав, назначаемых для данной учетной записи (221). По данной информации формируется запрос на создание учетной записи (222), который подписывается с помощью приватного ключа администратора (223), хранимого на аппаратном токене, например, USB-токене или смарт-карте.
[0063] Подписанный запрос на создание аккаунта пользователя (223) передается на сервер (ПО) для дальнейшей обработки. В ходе проверки (224) на сервере (ПО) выполняется проверка подписи пользователя (225), с помощью которой было выполнено подписание запроса (223). Если проверка не выполняется, то запрос на создание учетной записи пользователя (10) отклоняется (226).
[0064] Если проверка подписи (225) запроса проходит успешно, то далее запрос (223) передается в АМБ (120) для дальнейшей проверки. На АМБ (120) осуществляется проверка подписи запроса (228) на соответствие сохраненным аутентификационным данным. После успешной проверки подписи запроса в АМБ (120) создается новый пользователь и сохраняются его аутентификационные данные (публичный ключ) (229). Далее информация о созданной учетной записи (220), и аутентификационные данные передаются на управляющий сервер (227), где сохраняются в БД (113).
[0065] При создании цифрового кошелька, с помощью пользовательского модуля (112) выполняется назначение ролей учетной записи пользователей (10). В частности, пользователь (10) может быть назначен ответственным за подтверждение и контроль транзакций для данного кошелька, а также по одному или нескольким другим цифровым кошелькам. Роль учетной записи пользователя может быть различной, для различных цифровых кошельков.
[0066] На Фиг. 2С представлена процедура (230) создания цифрового кошелька для осуществления операций с цифровыми активами, в частности криптовалютой. На первом этапе (231) от пользователя (10) поступает запрос на создание цифрового кошелька. Запрос (231) включает в себя тип криптовалюты, правила мультиподписи и правила подтверждения транзакций, и формируется с помощью пользовательского модуля (112).
[0067] Запрос (231) на создание цифрового кошелька подписывается приватным ключом пользователя (232), хранимого на аппаратном токене пользователя. Подписанный запрос передается на сервер (110) для его последующей валидации (233).
[0068] Процесс валидации (233) заключается в обработке аутентификационных данных учетной записи пользователя (220), в частности проверка подписи запроса (231) на соответствие аутентификационным данным, в частности, публичному ключу, хранимому в БД сервера (113). Также, в процессе проверки (233) проверяются права пользователя (10). [0069] После успешной валидации запроса на управляющем сервере (ПО), пользовательский запрос передается в АМБ (120) где также выполняется процесс валидации (234), в ходе которого проверяется, что подпись запроса (232) соответствует публичному ключу, хранимому в АМБ (120).
[0070] По итогам валидации запроса на АМБ (234) формируется пара публичный/приватный ключ (235) для нового цифрового кошелька. Также, на АМБ (120) сохраняются параметры для создаваемых кошельков и правила мультиподписи и подтверждения транзакций для данных кошельков (236). По итогам обработки запроса на создание цифрового кошелька, информация об успешном статусе процедуры (230) создании цифрового кошелька и его публичный ключ передаются на сервер (237).
[0071] В качестве правил мультиподписи транзакций могут использоваться следующие подходы: М из N подписей, подпись от К групп пользователей с кворумом внутри по меньшей мере L групп.
[0072] В части способов подтверждения транзакций могут использоваться, например, переход по гиперссылке, ввод кода, ввод одноразового пароля, биометрическая идентификация, подтверждение с помощью аппаратного токена или криптографической подписью, двойная аутентификация и т.п. В качестве аппаратного токена может применяться смарт-карта, USB или NFC-токен и т.п.
[0073] Цифровой кошелек может использоваться для различного типа криптовалют, например, BTC, ВСН, ЕТН, ETC, ERC20, ERC223, LTC и др.
[0074] На Фиг. ЗА - Фиг. ЗВ представлен процесс осуществления транзакций с помощью цифровых кошельков пользователей. Как показано на Фиг. ЗА запрос на выполнение транзакции осуществляется с помощью запрашиваемой стороны (301). Сформированный запрос (301) подписывается с помощью приватного ключа пользователя (302) и передается на сервер (110) для последующей обработки. Транзакционный запрос (301), как правило, поступает от пользователя (30), которому при регистрации была установлена роль заправшиваемой стороны - «requestor».
[0075] После получения подписанного запроса (302) сервер (110) осуществляет процесс валидации транзакции, проверяя, что все условия, заданные при создании кошелька пользователя (30), запрашивающего осуществление транзакции, соблюдены. На сервере (110) осуществляется проверка роли (303) пользователя (30), запрашивающего выполнение транзакции. Далее осуществляется проверка подписи транзакционного запроса (304) на соответствие аутентификационным данным, в частности публичному ключу пользователя, который хранится в БД сервера (113). Если проверка не успешна, то осуществляется отказ в выполнении транзакционного запроса, о чем передается соответствующее уведомление пользователю (30).
[0076] После успешной проверки на шаге (304) на сервере (ПО) выполняется сбор первичных данных по цифровому кошельку в сети блокчейн (305). Такой информацией может служить, например, баланс цифрового кошелька, история транзакций и т.п. Далее на этапе (306) на основании первичных данных, полученных на шаге (305), формируют сырую транзакцию и сохраняют данную транзакцию (307) на управляющем сервере (110).
[0077] На Фиг. ЗВ представлен процесс проверки транзакции, созданной на шаге (307), одобряющей стороной (31). На первом шаге (311) пользователь выполняет проверку всех параметров транзакции для цифрового кошелька, таких как размер транзакции, адрес получателя и т.п. Если проверка заканчивается успешно, то выполняется формирование запроса на одобрение транзакции (312), который подписывается (313) приватным ключом одобряющей стороны (31). Подписанный запрос (313) передается на сервер (110).
[0078] На сервере (НО) осуществляется проверка (314) установленных правил подтверждения транзакции, а также подписи стороны (31), с помощью которой был подписан запрос (313). Далее осуществляется проверка (315) установленной роли пользователя (31) и проверка выполнения условий мультиподписи (316), т.е. что транзакционный запрос был подписан всеми установленными пользователями.
[0079] Если проверка на этапе (316) была успешной, то далее управляющий сервер (110) передает сырую транзакцию и подписанные запросы пользователей, одобривших транзакцию, на АМБ (120). Также, в БД сервера (113) осуществляется запись запроса на одобрение транзакции (317). Если условие мультиподписи для сырой транзакции не выполнено, то осуществляется ожидание в заданный промежуток времени подписания транзакции всеми установленными пользователями. Если в заданное время подписание транзакции не происходит, то запрос на осуществление транзакции отклоняется.
[0080] По полученным от сервера (110) данным на АМБ (120) осуществляют проверку (319) правил подтверждения транзакции каждым подписантом и условий выполнения мультиподписи (320) полученной сырой транзакции. В случае успешной проверки, с помощью программной логики АМБ (120) выполняется подпись (321) сырой транзакции с помощью приватного ключа цифрового кошелька, по которому был инициирован запрос на одобрение транзакции (313).
[0081] Подписанная транзакция передается от АМБ (120) на управляющий сервер (110), с которого она далее передается в блокчейн сеть (150). [0082] На Фиг. ЗС представлен процесс проверки транзакции с помощью учетной записи пользователя (33), которому была назначена роль контроллера. По полученной информации о сформированной сырой транзакции, пользователь (33) осуществляет проверку ее параметров, таких как размер транзакции, адрес получателя и т.п.
[0083] Пользователь (33) по итогам проверки принимает решение об одобрении транзакционного запроса (332) или об отклонении данного запроса (333). В случае отклонения транзакционного запроса (333) пользователь (33) осуществляет подписание запроса на отклонение транзакции с помощью его приватного ключа (334) и передает подписанный запрос на сервер (ПО). На сервере (110) с помощью пользовательского модуля (112) выполняется проверка (335) роли пользователя (33) для осуществления отклонения транзакционных запросов, а также проверка подписи (336), с помощью которой был подписан соответствующий запрос на отклонение транзакции. По итогам проверки на сервере (110) сохраняется статус выполненного запроса на отклонение транзакции (337), и транзакция переводится в статус отклоненной.
[0084] Учетная запись пользователя позволяет инициировать транзакции, одобрять и отклонять транзакции, накладывать вето на транзакции в течение определенного периода времени после того как транзакция была предложена, а также создавать цифровые кошельки, если такие полномочия были сформированы с помощью модуля администратора (111).
[0085] Правила мультиподписи транзакций включают в себя, например, М из N подписей, подпись от нескольких групп, или подпись от нескольких групп с кворумом внутри группы, а также установление временного периода для подтверждения транзакции, по истечении которого транзакция отклоняется.
[0086] Для каждой подписи может устанавливаться весовой коэффициент и пороговое значение для каждой из групп пользователей, назначенных для данного цифрового кошелька для подтверждения транзакции. Пороговое значение должно быть превышено суммой весов всех подписантов группы для осуществления процедуры подтверждения транзакции. При этом для каждой инициированной транзакции может устанавливаться временной период, в течение которого на транзакцию может быть наложено вето.
[0087] На Фиг. 4 представлен пример выполнения вычислительного устройства (400), на базе которого может быть выполнен, например, сервер (ПО) или иные устройства, с помощью которых возможно взаимодействие с заявленной системой и осуществления транзакций с цифровыми активами. [0088] В общем случае, устройство (400) может выбираться из широкого перечня электронных устройств, известных из уровня техники, например, персональных компьютеров, ноутбуков, планшетов, суперкомпьютеров, серверных кластеров, смартфонов и т.п. Устройство (400) может содержать один или несколько процессоров (401) или один или несколько микроконтроллеров, ОЗУ (402), средство постоянного хранения данных (403), интерфейсы ввода/вывода (404), устройства ввода/вывода (405), средство сетевого взаимодействия (406).
[0089] Процессор (401) представляет собой основной вычислительный модуль, обеспечивающий логическую обработку алгоритмических команд, необходимых для осуществления устройством (400) необходимых функций. ОЗУ (402) представляет собой стандартную оперативную память, предназначенную для хранения исполняемых процессором инструкций, реализующих работу заложенной программной логики.
[0090] Средства для постоянного хранения данных (403) могут представлять собой, не ограничиваясь: жесткий диск (HDD), флэш-память (NAND, EEPROM, SD-карты и т.п.), твердотельный накопитель (SSD), оптические накопители данных (CD/DVD/BlueRay диски и т.п.).
[0091] Интерфейсы В/В (404) могут представлять собой, не ограничиваясь: АЦП/ЦАП, USB (micro-, Туре С, mini- и т.п.), PS/2, PCI, VGA, RS232, RJ45, FireWire, SATA, IDE, COM, LPT, Audio Jack, HDMI, Display Port, Lightning и т.п.
[0092] Средства В/В (405) могут представлять собой, не ограничиваясь: дисплей, сенсорный дисплей, клавиатуру (механическая, сенсорная, проекционная и т.п.), трекбол, джойстик, тач-пад, динамики, микрофон, проектор, световой индикатор, зуммер, биометрический сенсор (сканер отпечатка пальца, сетчатки глаза, радужной оболочки, голоса, ладони, рисунка вен и т.п.), камера, оптический сенсор, акселерометр, гироскоп, датчик освещенности, датчик приближения, грависенсор и т.п.
[0093] Средство сетевого взаимодействия (406) может представлять собой, не ограничиваясь: Bluetooth-модуль, BLE модуль, NFC, Ethernet карта, модем, роутер, IrDa, GSM - модем, GPRS-модем, LTE-модем, 5 G-модем, WLAN, Wi-Fi модуль, спутниковый модем, ГНСС - приемник и т.п.
[0094] Представленные описание заявленного решения раскрывает лишь предпочтительные примеры его реализации и не должно трактоваться как ограничивающее иные, частные примеры его осуществления, не выходящие за рамки объема правовой охраны, которые являются очевидными для специалиста соответствующей области техники.

Claims

Формула
1. Система для безопасного хранения цифровых валют, а также обработки и осуществления транзакций в по меньшей мере одной блокчейн сети, содержащая по меньшей мере управляющий сервер, связанный с по меньшей мере одной блокчейн сетью и обеспечивающий управление жизненным циклом цифровых кошельков пользователей, отслеживание и валидацию входящих транзакций, формирование и первичную валидацию транзакций блокчейн сетей, причем сервер содержит
модуль администратора, который выполнен с возможностью создания аккаунтов и управления правами администраторов, создания аккаунтов и управления правами пользователей, возможностью просмотра статистики по цифровым кошелькам пользователей;
пользовательский модуль, который выполнен с возможностью
создания цифровых кошельков пользователей, назначения правил мультиподписи транзакций и правил их подтверждения пользователями для каждого созданного цифрового кошелька;
обработки пользовательских запросов в зависимости от правил подтверждения, назначенных при создании цифрового кошелька;
подключения пользователями методов мультифакторной аутентификации;
базу данных, хранящую информацию об адресах цифровых кошельков, транзакциях, администраторах и пользователях, их правах и аутентификационных данных, правилах мультиподписи и валидации транзакций;
по меньшей мере один аппаратный модуль безопасности (АМБ), связанный с управляющим сервером и обеспечивающий изолированную среду для создания и обеспечения полного жизненного цикла цифровых кошельков, безопасного хранения приватных ключей цифровых кошельков, хранения аутентификационных данных администраторов и пользователей для обеспечения процесса передачи адресов цифровых кошельков на управляющий сервер, валидации транзакций, подписи подтвержденных транзакций и их передачи на управляющий сервер.
2. Система по п.1, характеризующаяся тем, что правила мультиподписи устанавливается при создании цифрового кошелька пользователя.
3. Система по п.1, характеризующаяся тем, что правила подтверждения представляют собой по меньшей мере одно из: переход по гиперссылке, ввод кода, ввод одноразового пароля, биометрическая идентификация, подтверждение с помощью аппаратного токена или криптографической подписью.
4. Система по п.1, характеризующаяся тем, что правила мультиподписи включают в себя по меньшей мере одно из: М из N подписей, подпись от К групп пользователей с кворумом внутри по меньшей мере L групп.
5. Система по п.З, характеризующаяся тем, что аппаратный токен представляет собой смарт-карту, USB или NFC токен.
6. Система по п.1, характеризующаяся тем, что при обработке транзакции для цифрового кошелька управляющий сервер осуществляет ее первичную проверку на предмет соблюдения условий мультиподписи и подтверждения для упомянутого кошелька для одобрения транзакции.
7. Система по п.6, характеризующаяся тем, что при получении запроса на транзакцию по цифровому кошельку, управляющий сервер по аутентификационным данным осуществляет первичную проверку подписей всех пользователей, назначенных в правилах мультиподписи при создании цифрового кошелька.
8. Система по п.7, характеризующаяся тем, что после валидации запроса создания транзакции, управляющий сервер осуществляет сбор первичной информации по кошельку в сети блокчейн и формирует на ее основании сырую транзакцию, которая сохраняется в базе данных.
9. Система по п.4, характеризующаяся тем, что для каждой подписи устанавливаются весовые коэффициенты и пороговое значение для каждой из групп, причем пороговое значение должно быть превышено суммой весов всех подписантов группы, для подтверждения транзакции.
10. Система по п.8, характеризующаяся тем, что после валидации транзакции и первичной проверки всех подписей, управляющий сервер передает данные транзакции и подписей на АМБ.
11. Система по п.10, характеризующаяся тем, что по аутентификационным данным АМБ осуществляет проверку поступающих сырых транзакций от управляющего сервера на предмет валидности подписей, с помощью которых была подтверждена транзакция, и в случае успешной проверки осуществляет подпись сырых транзакций с помощью приватного ключа цифрового кошелька, соответствующего данной транзакции.
12. Система по п.11 характеризующаяся тем, что после подписания сырой транзакции АМБ осуществляет передачу подписанной транзакции на управляющий сервер для ее последующей передачи в блокчейн сеть.
13. Способ выполнения транзакций с использованием цифровых валют в блокчейн сети, содержащий этапы, на которых:
- принимают на управляющем сервере запрос на создание цифрового кошелька для осуществления транзакций с помощью цифровых валют, в котором устанавливают правила мультиподписи транзакций и правила подтверждения транзакций пользователями для созданного цифрового кошелька, причем правила мультиподписи включают в себя по меньшей мере данные пользователей, назначенных для подписи транзакции;
- по аутентификационным данным осуществляют проверку прав и подписи запроса на создание цифрового кошелька;
- передают подписанный запрос в аппаратный модуль безопасности (АМБ), на котором создают цифровой кошелек пользователя путем генерации приватного и публичного ключей;
сохраняют в АМБ приватный и публичный ключи цифрового кошелька и аутентификационные данные пользователей, назначенных для подтверждения транзакций по созданному цифровому кошельку;
- передают и сохраняют в базу данных управляющего сервера публичный ключ созданного цифрового кошелька и аутентификационные данные пользователей, назначенных для подтверждений транзакций по созданному цифровому кошельку;
- получают на управляющем сервере запрос на выполнение транзакции по одному из созданных цифровых кошельков;
- осуществляют на управляющем сервере сбор первичных данных по цифровому кошельку в сети блокчейн;
- на основании первичных данных формируют сырую транзакцию и сохраняют первичную транзакцию на управляющем сервере;
- осуществляют подтверждение сырой транзакции всеми пользователями с помощью установленных правил мультиподписи транзакций и правил подтверждения транзакций для данного цифрового кошелька;
- после проверки подтверждения транзакции управляющим сервером передают сырую транзакцию и подписи пользователей, подтвердивших транзакцию, на АМБ;
по аутентификационным данным осуществляют на АМБ проверку правил подтверждения транзакции каждым подписантом, условий выполнения мультиподписи сырой транзакции, в случае успешной проверки, выполняют подпись сырой транзакции с помощью приватного ключа цифрового кошелька по которому была инициирована транзакция; - передают подписанную транзакцию на управляющий сервер для ее дальнейшей передачи в блокчейн сеть.
14. Способ по п.13, характеризующийся тем, что создают и сохраняют на сервере учетную запись администратора с правом управления аккаунтами администраторов, причем с помощью учетной записи администратора выполняют создание учетных записей администраторов и/или пользователей, которым назначается набор прав.
15. Способ по п.14, характеризующийся тем, что учетная запись пользователя позволяет по меньшей мере одно из: инициировать транзакции, одобрять и отклонять транзакции, накладывать вето на транзакции в течение определенного периода времени после того как транзакция была предложена, создавать цифровые кошельки.
16. Способ по п.13, характеризующийся тем, что правила подтверждения транзакции представляют собой по меньшей мере одно из: двойная верификация, переход по гиперссылке, ввод кода, ввод одноразового пароля, биометрическая идентификация, криптографическая подпись или подтверждение с помощью аппаратного токена.
17. Способ по п.13, характеризующийся тем, что правила мультиподписи транзакций включают в себя по меньшей мере одно из: М из N подписей, подпись от нескольких групп, или подпись от нескольких групп с кворумом внутри группы, а также установление временного периода для подтверждения транзакции, по истечении которого транзакция отклоняется.
18. Способ по п.17, характеризующийся тем, что для каждой подписи устанавливаются весовые коэффициенты и пороговое значение для каждой из групп, причем пороговое значение должно быть превышено суммой весов всех подписантов группы, для подтверждения транзакции.
19. Способ по п.13, характеризующийся тем, что для каждой инициированной транзакции устанавливается временной период, в течение которого на транзакцию может быть наложено вето.
20. Способ по п.13, характеризующийся тем, что АМБ выполнен с функцией репликации данных в режиме реального времени, которая выполняется с помощью одного или нескольких дублирующих АМБ.
PCT/RU2019/000077 2019-02-08 2019-02-08 Система и способ для безопасного хранения цифровых валют и осуществления транзакций в блокчейн сети WO2020162780A1 (ru)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/RU2019/000077 WO2020162780A1 (ru) 2019-02-08 2019-02-08 Система и способ для безопасного хранения цифровых валют и осуществления транзакций в блокчейн сети
US16/975,796 US11308484B2 (en) 2019-02-08 2019-02-08 System and method for secure storage of digital currencies and making transactions in a blockchain network

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/RU2019/000077 WO2020162780A1 (ru) 2019-02-08 2019-02-08 Система и способ для безопасного хранения цифровых валют и осуществления транзакций в блокчейн сети

Publications (1)

Publication Number Publication Date
WO2020162780A1 true WO2020162780A1 (ru) 2020-08-13

Family

ID=71948016

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/RU2019/000077 WO2020162780A1 (ru) 2019-02-08 2019-02-08 Система и способ для безопасного хранения цифровых валют и осуществления транзакций в блокчейн сети

Country Status (2)

Country Link
US (1) US11308484B2 (ru)
WO (1) WO2020162780A1 (ru)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112738106A (zh) * 2020-12-29 2021-04-30 合肥达朴汇联科技有限公司 一种区块链匿名用户审计***
WO2022037596A1 (zh) * 2020-08-20 2022-02-24 上海万向区块链股份公司 组合签名及验证签名方法、***及存储介质
WO2023046409A1 (en) * 2021-09-21 2023-03-30 International Business Machines Corporation Digital asset platform with hsm verification

Families Citing this family (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11665161B2 (en) * 2019-06-18 2023-05-30 Cisco Technology, Inc. Identity services for passwordless authentication
US20210097528A1 (en) * 2019-09-26 2021-04-01 Rui Wang Blockchain hot wallet based on secure enclave and multi-signature authorization
CN112200565A (zh) * 2020-10-26 2021-01-08 成都商通时代数字科技有限公司 usbKey在区块链数字酒证钱包中的应用方法及应用***
WO2023164651A1 (en) * 2022-02-25 2023-08-31 Coinbase, Inc. Systems and methods for facilitating secure blockchain operations in decentralized applications using cryptography-based, storage applications in computer networks
US11989276B2 (en) 2022-06-24 2024-05-21 Bank Of America Corporation Intelligent authentication of users in Metaverse leveraging non-fungible tokens and behavior analysis
US11989316B1 (en) * 2023-01-10 2024-05-21 AnonyDoxx, LLC Systems and methods for blockchain wallet owner verification and access management

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20150287026A1 (en) * 2014-04-02 2015-10-08 Modernity Financial Holdings, Ltd. Data analytic and security mechanism for implementing a hot wallet service
US20160292672A1 (en) * 2015-03-31 2016-10-06 Nasdaq, Inc. Systems and methods of blockchain transaction recordation
US10068228B1 (en) * 2013-06-28 2018-09-04 Winklevoss Ip, Llc Systems and methods for storing digital math-based assets using a secure portal
RU2667801C1 (ru) * 2016-03-28 2018-09-24 Блэк Голд Койн, Инк. Система и способ для многофакторной аутентификации личности на основе блокчейна

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170048209A1 (en) 2015-07-14 2017-02-16 Fmr Llc Crypto Key Recovery and Social Aggregating, Fractionally Efficient Transfer Guidance, Conditional Triggered Transaction, Datastructures, Apparatuses, Methods and Systems
US11386420B2 (en) * 2017-12-29 2022-07-12 Intel Corporation Contextual authentication of an electronic wallet
US10929842B1 (en) * 2018-03-05 2021-02-23 Winklevoss Ip, Llc System, method and program product for depositing and withdrawing stable value digital assets in exchange for fiat
US11444779B2 (en) * 2018-08-02 2022-09-13 Paypal, Inc. Techniques for securing application programming interface requests using multi-party digital signatures
US11263315B2 (en) * 2018-12-03 2022-03-01 Ebay Inc. System level function based access control for smart contract execution on a blockchain

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10068228B1 (en) * 2013-06-28 2018-09-04 Winklevoss Ip, Llc Systems and methods for storing digital math-based assets using a secure portal
US20150287026A1 (en) * 2014-04-02 2015-10-08 Modernity Financial Holdings, Ltd. Data analytic and security mechanism for implementing a hot wallet service
US20160292672A1 (en) * 2015-03-31 2016-10-06 Nasdaq, Inc. Systems and methods of blockchain transaction recordation
RU2667801C1 (ru) * 2016-03-28 2018-09-24 Блэк Голд Койн, Инк. Система и способ для многофакторной аутентификации личности на основе блокчейна

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2022037596A1 (zh) * 2020-08-20 2022-02-24 上海万向区块链股份公司 组合签名及验证签名方法、***及存储介质
CN112738106A (zh) * 2020-12-29 2021-04-30 合肥达朴汇联科技有限公司 一种区块链匿名用户审计***
WO2023046409A1 (en) * 2021-09-21 2023-03-30 International Business Machines Corporation Digital asset platform with hsm verification

Also Published As

Publication number Publication date
US20210383363A1 (en) 2021-12-09
US11308484B2 (en) 2022-04-19

Similar Documents

Publication Publication Date Title
US11308484B2 (en) System and method for secure storage of digital currencies and making transactions in a blockchain network
US20220277307A1 (en) Systems and methods for personal identification and verification
US11411730B2 (en) Cryptoasset custodial system with different rules governing access to logically separated cryptoassets and proof-of-stake blockchain support
US11757627B2 (en) Cryptoasset custodial system with proof-of-stake blockchain support
US11763305B1 (en) Distributed ledger for device management
US11263605B2 (en) Weighted multiple authorizations
US20190268165A1 (en) Cryptoasset custodial system with different rules governing access to logically separated cryptoassets
JP6046765B2 (ja) 秘密情報にアクセスするための、多重パーティ及び多重レベルの承認を可能にするシステム及び方法
CN114631286B (zh) 具有自定义逻辑的加密资产托管***
CN110753944B (zh) 用于基于区块链的数据管理的***和方法
US11881939B2 (en) System for authorization of electronic data access and processing functions within a distributed server network
US11810130B2 (en) Security policy enforcement
WO2022081921A1 (en) Multisignature key custody, key customization, and privacy service
US20180375847A1 (en) Stored value user identification system using blockchain or math-based function
JP7447127B2 (ja) 分散型台帳システムへのデータの記録の誤ったコピーの送信を防止する
US11372958B1 (en) Multi-channel authentication using smart cards
US20230254153A1 (en) System and method for reducing authentication delays related to security module processing
US20230360123A1 (en) Cryptocurrency exchange platform
US11854011B1 (en) Identity management framework
WO2023069505A1 (en) Non-transferable token

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 19914566

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 19914566

Country of ref document: EP

Kind code of ref document: A1