WO2023056569A1

WO2023056569A1 - A method and a validation device for executing blockchain transactions

Info

Publication number: WO2023056569A1
Application number: PCT/CH2021/050022
Authority: WO
Inventors: Victor AMMER
Original assignee: Ammer Technologies Ag
Priority date: 2021-10-05
Filing date: 2021-10-05
Publication date: 2023-04-13

Abstract

The present technology relates to a method and a system for conducting transactions based on distributed ledger. In the present invention, this shortcoming is addressed by securely storing all the necessary blockchain data in a validation device. According to a first broad aspect of the present technology, there is provided a validation device for validation, authentication and/or authorization of blockchain transactions. The validation device comprising the following modules: non-volatile memory to store data; at least one physical communication interface; an integrated circuit (IC) capable of executing program instructions. According to a second broad aspect of the present technology, there is provided a method of executing blockchain transactions in a system, comprising a validation device and a computing device connected to at least one communication network in order to access a blockchain.

Description

A method and a validation device for executing blockchain transactions

Field of the technology

[0001] The present technology relates to a method and a system for conducting transactions based on distributed ledger.

Background of the technology

[0002] Electronic transactions including but not limited to financial transactions are used all over the world. Electronic transactions represent a convenient and user-friendly way of executing different operations including but not limited to: conducting payments, user identification and/or authorization, access to a physical locations and/or electronic information, digital signatures and remote validation and/or authorization of different actions.

[0003] Over past decades an average user got used to: conducting payments with a debit/credit card, entering physical locations (office, pool, public transport etc.) with an electronic key or ticket represented as a plastic card, applying various loyalty cards, gift cards, represented as well in a form of a plastic card. Plastic cards can be also emulated on smartphone, where the user may choose one of the emulated cards for conducting a required electronic transaction.

[0004] All conventional cards are issued and controlled by a particular issuer (bank, transport company, merchant, security department, government, etc.). Thus the user is dependent on the internal rules, fees of the issuer. Moreover, the level of security may vary depending on the issuer’s security system on their servers. Such conventional systems are centralized in case of any error or invasion some data and even values of the user can be lost or stolen. [0005] As an alternative to a centralized system, the distributed ledger (blockchain) technology has been developed. Blockchain technology is based on a decentralized system including multiple independent servers to maintain a distributed database. All records, transactions are synchronized and verified between multiple devices. Any invasion to one of the servers may not affect the distributed database.

[0006] However, the blockchain technology is complicated and unsafe for an average user since the keys to initiate and validate transaction are stored on the user’s device (smartphone, computer, USB-key etc.) which can be lost, stolen, hacked etc. and there is no particular issuer who may restore the keys.

[0007] US patent #101002510 (Arnold Yau et al) discloses a technology implementing a smart card to validate the blockchain based transaction. The existing system includes a mobile device, using a contactless token to store and protect a user' s secret key. A cryptocurrency payment instruction is received by the mobile device, prompting for a user credential to approve the instruction. In response the mobile device sends to the token a message comprising the encrypted wallet together with the payment instruction and the user credential. Using the secret key, the token then decrypts the cryptocurrency wallet from the encrypted wallet and creates a payment transaction by payment instruction, and transmitting the payment transaction to a cryptocurrency network or exchange. Confirmation of the transaction requires either a PIN, biometric or fingerprint on the mobile device, or authentication via button press, PIN or fingerprint on the token.

[0008] With the existing technology, the user may store a master key of high cryptographic strength (128 bits or above) on the portable security token, and this key can be used to either directly protect an app's data encryption key or a long and complex password, from which a sufficiently long and secure encryption key can be derived. This allows the user to protect any data stored on the device with a very strong encryption key. If the device is stolen, it is then infeasible for any potential attacker to decrypt the encrypted data on it without the associated token.

[0009] The disadvantage of the existing technology is that the transaction requires the user at least two devices: a mobile device of the user storing a wallet and a token (validation device) storing a key to decrypt the wallet. In case of lost or damage of at least one of the devices transaction is not possible.

[0010] Improvements in the field of blockchain based electronic transactions are still possible. Summary

[0011] The present technology overcomes at least some of the deficiencies of previously developed methods and systems for executing blockchain based electronic transactions. [0012] In the present invention, this shortcoming is addressed by securely storing all the necessary blockchain data in a validation device.

[0013] According to a first broad aspect of the present technology, there is provided a validation device for validation, authentication and/or authorization of blockchain transactions. The validation device comprising the following modules: non-volatile memory to store data; at least one physical communication interface; an integrated circuit (IC) capable of executing program instructions.

[0014] The validation device is configured to store blockchain-related data in a blockchain container, metadata and program instructions in the memory of the validation device, while the program instructions are configured to: generate a blockchain container; store a blockchain container in the memory of the validation device; establish a secure communication channel with a computing device via at least one communication interface; receive blockchain transaction data from a computing device via at least one communication interface; sign a blockchain transaction using the data in a blockchain container; return the signed blockchain transaction to the computing device via at least one communication interface.

[0015] The memory contains at least one of the following metadata types: the validation device ID, the validation device issuer ID, the end-user’s name, the end-user’s ID.

[0016] The program instructions are configured to use at least part of metadata as an input parameter for establishing a secure communication channel with a computing device and/or configured to sending at least part of metadata to a computing device via at least one communication interface. [0017] In some implementations of the validation device the memory contains at least one of the following supplementary metadata types: an issuance date, an expiration date, an activation flag, additional cryptographic keys for establishing secure communication with a computing device, locking factors flags indicating that a blockchain container is locked or unlocked, authentication factors required to unlock a blockchain container, the number of factors necessary to unlock a blockchain container, the number of tries remaining to unlock a blockchain container before the validation device is deactivated and/or the container is erased, wherein the program instructions are configured to use at least part of supplementary metadata as an additional input parameter for establishing a secure communication channel with a computing device and/or configured to sending at least part of supplementary metadata to a computing device via at least one communication interface.

[0018] In some implementations of the validation device the blockchain-related data in the blockchain container and/or the program instructions are preinstalled on the validation device and prestored.

[0019] In some implementations of the validation device the program instructions are configured to generate a blockchain container and store in the memory of the validation device by means of connecting the validation device to a computing device via at least one physical communication interface.

[0020] In some implementations of the validation device the blockchain-related data in the blockchain container and/or the program instructions are configured to be edited by means of connecting the validation device to a computing device via at least one physical communication interface. [0021] In some implementations of the validation device the program instructions are additionally configured to locking and unlocking the blockchain container using one or several of the following locking factors: a PIN, biometric data, a password, a security token.

[0022] In some implementations of the validation device the program instructions are configured to store at least one additional blockchain container in the memory of the validation device.

[0023] In some implementations of the validation device the blockchain container is configured to store at least one additional set of blockchain-related data.

[0024] In some implementations of the validation device supplementary metadata in the memory include an encryption flag for marking the encrypted state of the validation device comprising program instructions configured to encrypt and decrypt the blockchain container.

[0025] In some implementations of the validation device supplementary metadata in the memory include an emulation flag; the blockchain-related data are encrypted on the validation device; and the validation device includes additional program instructions configured to: decrypt at least part of the blockchain-related data stored in the blockchain container; export at least part of decrypted blockchain-related data, allowing at least partial emulation of the validation device.

[0026] In some implementations of the validation device supplementary metadata in the memory comprise an expiration date and blocking conditions, including at least one of the following: the number of tries remaining to unlock a blockchain container, an expiration date; and the validation device comprises additional program instructions configured to deactivate the validation device and/or erase the blockchain container in response to reaching the expiration date and/or the number of tries to unlock the container.

[0027] In some implementations of the validation device at least one of the communication interfaces is at least one or more of the following: NFC, Bluetooth, Bluetooth Low Energy, Wi-Fi or USB, and the validation device is configured to establish a secure communication channel with a computing device via at least one aforementioned communication interface.

[0028] In some implementations of the validation device the blockchain-related data stored in the blockchain container contain a blockchain wallet; program instructions stored in the memory are configured to apply the blockchain wallet to validate transactions for at least one of the following financial instruments: crypto (virtual) currencies on a blockchain, digital assets on a blockchain, digital securities issued on a blockchain, central bank digital currency; and the metadata stored in the memory additionally contain at least one of the following: a list of supported financial instruments, a balance for off-blockchain transactions, spending limits on funds, spending limits allowed without authentication, temporal limits, a list of allowed destinations for fund transfers.

[0029] In some implementations of the validation device the blockchain-related data stored in the blockchain container contain a gift card and/or voucher issued on a blockchain, and program instructions stored in the memory are configured to apply the gift card and/or voucher to validate transactions on a blockchain. [0030] In some implementations of the validation device the blockchain-related data stored in the blockchain container contain at least one loyalty program account issued on a blockchain, and program instructions stored in the memory are configured to apply at least one loyalty program account to validate transactions on a blockchain.

[0031] In some implementations of the validation device the blockchain-related data stored in the blockchain container contain a ticket maintained on a blockchain, and program instructions stored in the memory are configured to apply the ticket to validate transactions on a blockchain, while the data stored in the blockchain container additionally contain at least one of the following: a balance for off- blockchain transactions, spending limits on funds (for example, per unit of time), temporal limits, timestamps of a certain number of latest usages.

[0032] In some implementations of the validation device the data stored in the blockchain container additionally contain a limit value of the funds available in blockchain-related data stored in the blockchain container, and program instructions stored in the memory are configured to prohibit transactions in response to reaching the limit value of the funds available.

[0033] In some implementations of the validation device blockchain-related data stored in the blockchain container contain a membership account based on a blockchain, and program instructions stored in the memory are configured to apply the membership account to validate transactions on a blockchain; while the data stored in the blockchain container additionally contain at least one of the following: the end user’s tier, the end user’s age rating, a set of permissions to use the services. [0034] In some implementations of the validation device blockchain-related data stored in the blockchain container contain an access token based on a blockchain; and program instructions stored in the memory are configured to apply the access token to validate transactions on a blockchain; while the data stored in the blockchain container additionally contain at least one of the following: timestamps of the latest access grants or refusals, limits on access grants per unit of time, temporal limits, flags for access restriction.

[0035] In some implementations of the validation device blockchain-related data stored in the blockchain container contain personal identification data, and program instructions stored in the memory are configured to apply the personal identification data to validate transactions on a blockchain, while the data stored in the blockchain container additionally contain at least one of the following: the end user’s photograph, anthropometric and appearance data, timestamps of the latest document validation events. [0036] In some implementations of the validation device program instructions stored in the memory are configured to apply the blockchain-related data stored in the blockchain container to sign for data in automated document management workflows on a blockchain.

[0037] In some implementations of the validation device blockchain-related data stored in the blockchain container contain additional data representing information about the quorum of approvers to authorize and/or authenticate and/or sign and/or validate and/or verify blockchain transactions; program instructions stored in the memory are configured to validate transactions on a blockchain in response to the presence of the quorum of approvers; the data stored in the blockchain container additionally contain: cryptographic keys for establishing an encrypted communication channel and the list of supported transactions and/or transaction types.

[0038] In some implementations of the validation device the blockchain-related data stored in the blockchain container contain additional data specific to the transaction-signing broker system, and program instructions stored in the memory are configured to provide approver quorums for transactions with blockchain-based broker systems for secure transactions.

[0039] In some implementations of the validation device blockchain-related data stored in the blockchain container contains additional data representing conditions of blockchain-issued smart contract fulfilment, and program instructions stored in the memory are configured to hold and execute smart contracts on a blockchain in response to the conditions of smart contract fulfilment being met; while the data stored in the blockchain container additionally comprise a set of permissions and limits unlocked upon the execution of smart contracts.

[0040] In some implementations of the validation device blockchain-related data stored in the blockchain container contain additional data relevant to secondary actions, and program instructions stored in the memory are configured to sign and/or authenticate and/or authorize and/or validate secondary non-blockchain related actions.

[0041] According to a second broad aspect of the present technology, there is provided a method of executing blockchain transactions in a system, comprising a validation device and a computing device connected to at least one communication network in order to access a blockchain, the method comprising the following steps: step 1 ) connecting the validation device to the computing device via at least one communication interface; step 2) identifying the validation device by exchanging metadata between the validation device and the computing device; step 3) requesting by the computing device a key for establishing a secure communication channel with the validation device; step 4) receiving on the computing device a key from the validation device to establish a secure communication channel; step 5) establishing a secure communication channel between the validation device and the computing device for all consequent commands; step 6) receiving on the computing device metadata and public data from the blockchain container of the validation device to identify which transactions are supported; step?) generating blockchain transaction payload by the computing device; step 8) sending the transaction payload to the validation device; step 9) receiving by the computing device a signed transaction payload from the validation device, the transaction signed using the blockchain-related data stored in the blockchain container of the validation device; step 10) verifying the transaction on the computing device using the public data from the blockchain container of the validation device received on step 6); step 11 ) pushing the signed transaction to the blockchain; step 12) receiving by the computing device the success status of the transaction from the blockchain.

[0042] In some implementations the method further comprising an additional step between Step 5) and Step 6), with a view to checking the activation status of the validation device; the additional step including at least one of the following: receiving by the computing device supplementary metadata, including the activation flag stored on the validation device, and/or receiving activation status information of the validation device stored on the computing device and/or any external source available to the computing device via the communication network; in response to the validation device already having been activated, the method proceeds to Step 6 in response to the validation device not having been activated the method includes the following activation steps before proceeding to Step 6: requesting by the computing device a PIN and/or biometric data and/or other authentication factors and sending them to the validation device; saving the authentication factors by the validation device; generating keys to be stored in the blockchain container of the validation; putting the validation device into a protected state and encrypting the blockchain container of the validation device.

[0043] In some implementations of the method the activation steps additionally comprise: requesting from the end user by the computing device an ID for the validation device and sending it to the validation device; saving by the validation device the ID along with the authentication factors.

[0044] In some implementations the method, further comprising, if the blockchain container is in the protected state and encrypted, additional steps between Step 5) and Step 6), with a view to authenticating the validation device on the computing device by using one or several authentication factors, the additional steps being: receiving from the end user the authentication factors on the computing device; sending by the computing device the authentication factors to the validation device to be checked; checking the authentication factors on the validation device, in response to the authentication factors being valid, the validation device leaving the protected state, decrypting the blockchain container of the validation device; sending by the validation device a success status to the computing device.

[0045] In some implementations the method further comprising additional steps after the checking of the authentication factors on the validation device with a view to deactivating the validation device after a predefined number of unsuccessful authentication attempts; the additional steps being: erasing the blockchain- related data in the blockchain container of the validation device; setting the flag marking that the metadata stored in the memory of the validation device has been erased. [0046] In some implementations of the method the blockchain container of the validation device stores blockchain-related data representing a wallet for cryptocurrencies, digital assets, digital securities, the method including additional steps after the putting the validation device into a protected state and encrypting the blockchain container; the additional steps being: exchanging data between the validation device and computing device with a view to establishing a secure connection between the computing device and the blockchain provider server via a communication network; establishing a secure connection with the blockchain provider server; registering the validation device in the blockchain by sending the public data from the blockchain container of the validation device to the blockchain provider server.

[0047] In some implementations the method further comprising additional steps between Step 6) and Step 7), with a view to emulating the blockchain container on the computing device; the additional steps being: checking that the emulation flag in the validation device metadata permits emulation; sending the private data of the blockchain container of the validation device to the computing device; saving to the validation device the metadata indicating the fact that the validation device has been emulated, as well as the ID of the target computing device that serves for emulation; creating by the computing device an emulated blockchain container; putting the blockchain-related data into the emulated blockchain container; starting the activation procedure for the emulated validation device; wherein the computing device includes secure cryptoprocessor or similar specialized secure enclave and stores the emulated blockchain container therein. [0048] In some implementations of the method the blockchain container of the validation device stores blockchain-related data representing at least one of the following: a wallet for cryptocurrencies, digital assets, digital securities, a gift card, a voucher, a ticket; the method including additional steps between Step 6) and Step 7), with a view to checking the balance of the funds and/or the temporal limits for transactions available to the end user; the additional steps being: checking by the computing device the balance, spending limits and/or temporal limits by using the metadata from the blockchain container of the validation device and exchanging information with the blockchain provider server; comparing by the computing device the balance and/or the temporal limits stored on the validation device with the transaction data; denying the transaction on the computing device in response to the transaction data including the value exceeding the balance and/or the temporal limits stored on the validation device. [0049] In some implementations of the method the blockchain container of the validation device stores blockchain-related data representing membership cards, the method including additional steps between Step 6) and Step 7), with a view to checking whether the end user has the right to use the corresponding services; the additional steps being: checking by the computing device which services are available to the end user; denying the transaction by the computing device in response to the transaction data including at least one of the services not available to the end user of the validation device.

[0050] In some implementations of the method the blockchain container of the validation device stores blockchain-related data representing access tokens, the method including additional steps between Step 6) and Step 7), with the view of checking whether the end user has the right to access the corresponding facilities; denying by the computing device the transaction in response to the transaction data including at least one of access facilities not granted to the end user of the validation device. [0051] In some implementations of the method the blockchain container of the validation device stores blockchain-related data representing identification documents, the method including an additional step between Step 6) and Step 7), with a view to displaying additional information; the additional step being: receiving by the computing device the public data such as the end user’s photograph, anthropometric data and/or timestamps from the validation device to be displayed on the computing device.

[0052] In some implementations of the method the blockchain container of the validation device stores blockchain-related data for signing of documents in automated document flows, the method including additional steps after Step 6) for signing the documents; the additional steps being: checking by the computing device as to which documents and/or types of documents the end user is authorized to sign; with additional steps further comprising, between Step 7) and Step 8): obtaining by the computing device from the blockchain provider server the documents to be signed by the end user; denying the transaction by the computing device in response to the end user of the validation device not being authorized to sign at least one document or type of documents.

[0053] In some implementations of the method the blockchain container of the validation device stores data for the approval of transactions that follow the four- eyes principle or require a quorum in a broker system for secure transactions, the method after Step 6) including additional steps of approving such transactions; and additional steps being: added between Step 6) and Step 7) comprising: checking by the computing device as to which transactions and/or types of transactions the end user of the validation device is authorized to sign; the method comprising: denying signing the transaction by the computing device in response to the end user of the validation device not being authorized to sign at least one of transaction or type of transections; the method further comprising between Step 13) and Step 14): approving the transaction in response to receiving the quorum from the blockchain provider server.

[0054] In some implementations of the method the validation device is configured to sign, authenticate, authorize and/or validate secondary non-blockchain actions, the method including additional steps after Step 6) for executing such actions; the additional steps being: requesting by the computing device the data about the actions available to the end user of the validation device; performing by the computing device actions according to the actions available to the end user of the validation device.

[0055] In some implementations of the method the blockchain container stores at least one additional set of blockchain-related data as well as the method comprising a step of choosing a set of blockchain-related data on the computing device and signing the transaction payload using the chosen blockchain-related data stored in the blockchain container of the validation device.

[0056] The following definitions may be used in the context of the present description:

[0057] Authentication factor, or Factor A credential used to authenticate an end user’s identity for security purposes; the three types of authentication factors are something the user knows, something the user has, and something the user is.

[0058] Applet A blockchain container created on a smart card. [0059] Blockchain A consensus of replicated, shared and synchronized digital data geographically spread across multiple sites, countries or institutions.

[0060] Blockchain container An entity configured in a validation device to store blockchain-related data. [0061] Blockchain-related data Data important or required for blockchain transactions, in particular, public and private keys used to sign and verify blockchain transactions.

[0062] Communication interface A technical means implemented in the validation device to exchange data with an external computing device. [0063] Computing device A device capable of interacting with a validation device.

Computing device is meant to include any computer hardware that is capable of running software appropriate to the relevant task at hand. The computing devices may be implemented, inter alia, as personal computers (desktops, laptops, netbooks, etc.), servers, mobile phones, smartphones, tablet computers, wearable mobile devices, smart devices, objects that compose the loT, electronic door locks, POS terminals, cash registers, vending machines, etc. It should be noted, that a device acting as a computing device in the present context is not precluded from acting as a server to other computing devices. The use of the expressions “a computing device” does not preclude multiple electronic devices being used in receiving/sending, carrying out or causing to be carried out corresponding task or request, or the consequences of corresponding task or request, or steps of any method described herein.

[0064] End user In the context of the present description the term “End user” may be one or more physical persons and/or organizations associated with the particular validation device to sign and verify blockchain transactions.

[0065] Emulation Imitation of behavior of a validation device or a computer system with the help of another computer system; emulation includes but is not limited to virtualization and duplication.

[0066] IC integrated circuit [0067] loT Internet of Things

[0068] NFC near-field communication

[0069] NVM non-volatile memory

[0070] Transaction An action that involves authorization via a validation device.

[0071] PIN personal identification number [0072] POS point of sales

[0073] Program instructions Machine-readable instructions and functions that can be executed by the IC of a validation device to perform certain tasks.

[0074] Validation device A device that has a storage (non-volatile memory), one or more physical communication interfaces and an IC capable of executing designated algorithms for the purpose of implementing corresponding steps and procedures of any method described herein.

Brief description of the drawings

[0075] Fig. 1 illustrates a validation device according to a non-limiting embodiment [0076] Fig. 2 illustrates a system for executing distributed ledger transactions according to a non-limiting embodiment

[0077] FIG.3 illustrates a block diagram of the method of executing distributed ledger transactions according to a non-limiting embodiment

[0078] FIG.4-5 illustrates a diagram of a validation device activation [0079] FIG.6-7 illustrates a diagram of conducting a payment transaction

[0080] FIG.8-9 illustrates a diagram of validation device emulation

[0081] FIG.10-11 illustrates a diagram of granting access to a facility

[0082] FIG. 12-13 illustrates a diagram of redeeming a gift card

[0083] FIG. 14-15 illustrates a diagram of verification of a person’s identity [0084] FIG. 16-17 illustrates a diagram of a transaction approval by a quorum of approvers

Description

[0085] According to the present invention there is provided a validation device 100 (Fig.1 ) for and a method 400 (Fig.3) of executing, including but not limited to authorization, authentication, validation, signing and verification of blockchain transactions. The validation device 100 serves as part of a system comprising a computing device 200 (Fig. 2) connected to a communication network 250 (e.g., the Internet or a LAN) through which the computing device 200 can receive and send blockchain transactions to the blockchain distributed ledger 300 to be authorized by means of the validation device 100.

[0086] The present invention allows for various embodiments depending on the use case it is applied to. However, several embodiments will be described by way of example. [0087] Validation device

[0088] Figure 1 schematically represents a non-limiting embodiment of the validation device which should be capable of being configured to and executing of cryptographic functions. [0089] The validation device (100) is adapted and configured to validate transactions on a blockchain. To this end, the validation device comprises a non-volatile memory (NVM) (102) capable of storing a blockchain container (108) and the corresponding metadata (110) and program instructions to be executed by the IC (106), and at least one communication interface (104) to interact with external computing devices 200 (Fig.2). The NVM (102), the IC (106) and the communication interface(s) (104) are connected in such a way that the program instruction can be executed in the IC (106) to process the data in the blockchain container (108) and exchange data with an external computing device (200) via at least one communication interface (104). [0090] The metadata (110) stored in the NVM (102) and managed by the program instructions may comprise, for example: device ID that identifies the blockchain device, issuer ID that identifies the issuer of the validation device, end user’s name, end user’s unique identification number,

[0091] In some non-limiting embodiments NVM (102) may store supplementary metadata including at least one or more of the following: an issuance date, an activation flag, additional cryptographic keys for establishing secure communication with a computing device, locking factors flags indicating that a blockchain container (108) is locked or unlocked, authentication factors used to protect the blockchain containers (108), the number of factors necessary to unlock a blockchain container (108), the number of tries remaining to unlock a blockchain container (108) before the validation device (100) is deactivated and/or the blockchain container (108) is erased blockchain container type(s) that provide type information on the blockchain container(s) (108) stored in the NVM (102), expiration date that prescribes the date when the validation will be deactivated, status flags that provide information on the state and capabilities of the validation device (100), access timestamps, and the like.

[0092] The important blockchain-related data (such as public and private keys) required for execution (authorization and/or authentication and/or validation and/or signing and/or verification) of blockchain transactions is stored inside a blockchain container 108 of the validation device (100). It is important that the validation device and its components are designed to make sure that the blockchain container (108) is securely protected and tamper-proof and the data cannot be extracted from the blockchain container (108) by an unauthorized third party. [0093] Blockchain container (108) stored in a NVM (102) comprises blockchain-related data related or representing at least one or more of the following:

[0094] At least one crypto (virtual) currency on a blockchain, digital assets on a blockchain, digital securities issued on a blockchain, central bank digital currency wallet; [0095] At least one gift card and/or voucher issued on a blockchain;

[0096] At least one loyalty program account issued on a blockchain;

[0097] At least one ticket issued on a blockchain;

[0098] At least one membership account based on a blockchain;

[0099] At least one access token based on a blockchain; [0100] End-user's personal identification data;

[0101] At least one set of data to sign documents in automated management workflows;

[0102] At least one set of data representing information about the quorum of approvers to validate blockchain transactions; [0103] At least one set of data specific to the transaction-signing broker system;

[0104] At least one set of data representing conditions of blockchain-issued smart contract fulfilment;

[0105] At least one set of data relevant to secondary non-blockchain related actions. [0106] It should be noted that for the present technology blockchain-related data stored in the blockchain container 108 of the validation device may comprise one or multiple entries associated with one or more types of blockchain related data listed above.

[0107] Data stored in the NVM 102 and/or the blockchain container 108 may additionally contain at least one of the following data and/or metadata: a balance for off-blockchain transactions, spending limits on funds (for example, per unit of time), temporal limits, timestamps of a certain number of latest usages, the end user’s tier, the end user’s age rating, a set of permissions to use the services, timestamps of the latest access grants or refusals, limits on access grants per unit of time, flags for access restriction, the end user’s photograph, anthropometric and appearance data, timestamps of the latest document validation events, cryptographic keys for establishing an encrypted communication channel, the list of supported transactions and/or transaction types, a set of permissions and limits unlocked upon the execution of smart contracts.

[0108] According to an aspect of the invention, for additional security, a blockchain container 108 may be encrypted using at least one authentication factor such as PIN or biometric data. In such a case, the end user will be prompted to provide a valid factor in order to be able to validate a blockchain transaction. [0109] Validation device 100 in some implementations may be embodied as at least one of the following:

[0110] A smart card which is the preferred embodiment comprising an electrical interface and a contactless NFC interface. [0111] Any device that can emulate a smart card, e.g., smartphones, wearable mobile devices, or laptops, which, compared to smart cards, may comprise additional interfaces such as NFC, Wi-Fi, Bluetooth, Bluetooth Low Energy, Ethernet, USB, more powerful processors, extensible storage, a display or a screen, etc. [0112] A hardware security token which may have a limited computation capabilities and may comprise such interfaces as USB, FireWire, Apple Lightning, Thunderbolt, RS232, RS485, Bluetooth, Bluetooth Low Energy, ZigBee and a screen.

[0113] An implantable chip which may have no external elements and no electrical interfaces.

[0114] Hardware security modules (HSMs) which are characterized by high-speed communication interfaces such as Ethernet, optical fiber, and additional security features such as specialized OS, tamper-proof case, fixed mounting and no physical user interface. [0115] One of the preferred embodiments is an ISO/IEC 7810 smart card that implements Java Card 3 (JCOP v3) and Global Platform standards; has a radio frequency contactless (wireless) communication interface according to, e.g., ISO14443, ISO/IEC 18092 and an electrical interface according to ISO 7816; is compliant with and/or conformant to the FIPS 140-2 and Common Criteria EAL4+ information security standards. E.g., the smart card NXP J3H145 can serve as a reference.

[0116] The smart card may have non-functional and visual elements such as printed or embossed text (e.g., for cardholder’s name, issuer name, expiration date), images (e.g., logos or trademarks), anticounterfeiting elements, punched holes, etching, etc.

[0117] The preferred embodiment has the following advantages:

[0118] It is highly secure and tamper-proof, which allows to protect the blockchain containers 108.

[0119] Multiple aspects of the present invention can be easily implemented in one card.

[0120] It is a well-known, tested and reliable technology widely adopted in cybersecurity-critical industries such as banking.

[0121] It has a form-factor familiar to the end user. [0122] Computing device

[0123] The computing device 200 (Fig.2) may be any device capable of communicating with a blockchain via a communication network (e.g., the Internet) in order to receive, form and send blockchain transactions which should be authorized by a validation device. To this end, the computing device

(200) and the validation device (100) must be configured to interconnect via at least one or more communication interfaces (104) such as, e.g., NFC or USB.

[0124] To this end, the computing device (200) has access to the program instructions and by execution of which is configured to: [0125] Establish a connection with the validation device (100) over at least one communication interface (104);

[0126] Identify the validation device (100);

[0127] Establish a secure communication channel with the validation device (100);

[0128] Check whether the validation device (100) is capable of performing the transactions selected on the computing device (200);

[0129] Form payload of a blockchain transaction;

[0130] Send the payload over at least one communication interface to the validation device (100);

[0131] Receive the signed blockchain transaction payload from the validation device (100) over at least one communication interface;

[0132] Check the received payload using the public data from the blockchain container 108 of the validation device (100);

[0133] Connect to the corresponding blockchain servers 300 over the communication interfaces such as Ethernet, Wi-Fi or mobile networks; [0134] Send the singed and checked payload to the blockchain servers 300;

[0135] Display the result of transactions to the user.

[0136] A computing device (200) may be also used to configure a validation device (100) (by either an end user or an issuer) before the first use. The configuration includes but not limited to creating at least one blockchain container (108), writing and reading blockchain-related data to the blockchain container (108), writing and reading metadata, setting authentication factors, setting status flags, and the like.

[0137] Embodiments of the computing device 200 (referred to herein) include but are not limited to: desktop computers, laptop computers, servers, mobile phones, smartphones, tablet computers, wearable mobile devices, smart devices, objects that compose the loT, electronic door locks, POS terminals, cash registers, vending machines.

[0138] System for executing blockchain transactions [0139] At a high level of abstraction, the preferred embodiment of a system for blockchain transaction will require:

[0140] An end user or a third party to form a blockchain transaction on a computing device 200.

[0141] The end user to execute (authorize and/or authenticate and/or validate and/or sign and/or verify) the transaction by means of their validation device 100.

[0142] The computing device 200 send the transaction to the blockchain 300 and receive a confirmation from the blockchain 300.

[0143] Fig. 2 illustrates a system for executing blockchain transactions according to a non-limiting embodiment. In such a system, a blockchain (300) operates via a communication network (250) such as the Internet or a LAN or any other suitable network. In order to perform blockchain transactions, to the same network (250) a computing device (200) is connected; the computing device is configured to receive and handle data from the blockchain (300), form blockchain transactions, authorize (authenticate, validate, sign, etc.) the formed blockchain transactions using a validation device (100) and send the authorized transactions back to the blockchain (300).

[0144] According to an aspect of the present invention, there is provided a method 400 (illustrated in Fig. 3) for executing blockchain transactions by validating of blockchain transactions on a validation device (100); the method comprising the following steps:

[0145] Stepl : Connecting (402) the validation device (100) to the computing device (200) via at least one communication interface (104).

[0146] Step 2: Identifying (404) the validation device (100) by exchanging metadata between the validation device (100) and the computing device (200). [0147] Step 3: Requesting (406) by the computing device (200) a key for establishing a secure communication channel with the validation device (100).

[0148] Step 4: Receiving (408) on the computing device (200) a key from the validation device (100) to establish a secure communication channel. [0149] Step 5: Establishing (410) a secure communication channel between the validation device (100) and the computing device (200) for all consequent commands.

[0150] Step 6: Receiving (412) on the computing device (200) metadata and public data from the blockchain container (108) of the validation device (100) to identify which transactions are supported.

[0151] Step 7: Generating (414) blockchain transaction payload by the computing device (200) related to at least one of the supported transactions.

[0152] Step 8: Sending (416) the transaction payload to the validation device (100). [0153] Step 9: Receiving (418) by the computing device (200) a signed transaction payload from the validation device (100), the transaction signed) using the blockchain-related data stored in the blockchain container (108) of the validation device (100).

[0154] Step 10: Verifying (420) the signed transaction on the computing device (200) using the public data from the blockchain container (108) of the validation device (100) received on Step 6) (412).

[0155] Step 11 : Pushing (422) the signed transaction payload to the distributed ledger (300).

[0156] Step 12: Receiving (424) by the computing device (200) the success status of the transaction from the blockchain.

[0157] Examples and operations

[0158] Validation device activation

[0159] According to as aspect of the invention, there is provided a method 500 (Fig. 4- 5) for activating a blockchain device before distributing it to end users who would use the validation devices to authorize (authenticate, sign, verify, etc.) blockchain transactions. The method 500 includes steps 4O2’-412’ similar to the corresponding steps 402-412 of method 400.

[0160] The following example illustrates how a validation device (100) is activated by an issuer before handing over to and end user. In the example, the computing device (200) is a workstation (e.g., a Dell Precision Workstation) equipped with a smart card reader (e.g., HID Global Omnikey) and appropriate software to configure smart cards and other validation devices, and the validation device (100) is a smart card according to one of the preferred embodiments.

[0161] In the example, the smart card is being configured by the issuer using the software on the workstation; the activation procedure comprising creating an applet in the NVM (102) of the smart card, creating a set of blockchain-related public and private keys and storing them in the applet, and setting the activation flag to ACTIVATED.

[0162] In the example, activation procedure consists of the following steps: [0163] Connecting (402’) the smart card to the workstation via electrical interface.

[0164] Identifying (404’) the smart card by exchanging metadata between the smart card and the workstation.

[0165] Requesting (406’) by the workstation a key for establishing a secure communication channel with the smart card. [0166] Receiving (408’) on the workstation a key from the smart card to establish a secure communication channel.

[0167] Establishing (410’) a SCP02/03 secure communication channel between the workstation and the smart card for all consequent commands.

[0168] Activation procedure further comprising: [0169] Sending (502) a GET METADATA instruction from the workstation to the smart card.

[0170] In response to the instruction, sending (504) the metadata from the smart card to the workstation. [0171] Receiving (412’) the metadata on the workstation.

[0172] Based on the received metadata, checking (506) on the workstation whether the smart card is activated.

[0173] Sending (508) an ACTIVATE instruction from the workstation to the smart card. [0174] In response to the instruction, generating (510) a blockchain-related data (a keypair comprising public and private keys) and storing it in a blockchain container.

[0175] Sending (512) a SET ACTIVATED instruction from the workstation to the smart card in order to set the activation flag to ACTIVATED. [0176] In response to the instruction, sending (514) an OK status word from the card to the workstation.

[0177] In response to receiving the OK status word, sending (516) a GET METADATA from the workstation to the smart card.

[0178] Sending (518) the metadata from the smart card to the workstation. [0179] Based on the received metadata, checking (520) on the workstation that the activation procedure is a success.

[0180] Example 1 (Payment transaction)

[0181] According to one of the aspects of the present technology, there is provided a device and a method 600 (Fig. 6-7) for authorizing payments made with cryptocurrencies. The method 600 includes steps 402”-424” similar to the corresponding steps 402-424 of method 400. Method 600 may further comprise supplementary steps 602-628 as shown on Fig.6-7. However, in general embodiments steps 402”-424” are sufficient for implementation of the claimed method. [0182] The following example illustrates how a validation device is used for signing cryptocurrency (e.g., Ethereum) transactions using a PIN-protected blockchain container on a validation device (100). In the example, the computing device (200) is an Android OS-based smartphone (e.g., Samsung Galaxy) equipped with an NFC wireless interface and appropriate application to sign cryptocurrency transactions using a smart card, and the validation device (100) is a smart card.

[0183] In the example, the smart card has been previously configured by the issuer to contain a cryptocurrency wallet (applet) that stores Ethereum-related public and private keys; metadata indicating that: Ethereum is supported by one of the applets, spending and temporal limits are set to indicate how much funds can the end user spend during a time period, PIN is used to encrypt the wallet; metadata storing the number of unsuccessful applet unlocking attempts; the activation flag set to ACTIVATED for the sake of the example.

[0184] In the example, payment transaction signing procedure consists of the following steps:

[0185] Opening (602) the cryptocurrency transaction application on the smartphone (computing device 200). [0186] Entering (604) the destination and the amount of the cryptocurrency transaction.

[0187] Connecting (402”) the smart card to the smartphone via NFC.

[0188] Identifying (404”) the smart card by exchanging metadata between the smart card and the smartphone. [0189] Requesting (406”) by the smartphone a key for establishing a secure communication channel with the smart card.

[0190] Receiving (408”) on the smartphone a key from the smart card to establish a secure communication channel.

[0191] Establishing (410”) a SCP02/03 secure communication channel between the smartphone and the smart card for all consequent commands.

[0192] Sending (606) a GET METADATA instruction and a GET PUBLIC DATA instruction from the smartphone to the smart card.

[0193] In response to the instruction, sending (608) an OK status word and the container metadata from the card to the smartphone. [0194] Receiving (412”) the metadata on the smartphone.

[0195] Based on the received metadata, ensuring (610) that the activation flag is set to ACTIVATED.

[0196] Sending (612) a SELECT APPLET instruction from the smartphone to the smart card in order to select the Ether wallet from the applets available on the smart card.

[0197] In the application on the smartphone, asking (614) the user to enter the PIN that protects the wallet.

[0198] Checking (616) PIN on the smart card and resetting the number of tries remaining to unlock a blockchain container if the PIN is correct. [0199] Sending (618) an UNLOCKED status word from the smart card to the smartphone.

[0200] Checking (620) on the smartphone the balance, spending limits and/or temporal limits by using the metadata. [0201] Generating (414”) on the smartphone a payload to be signed on the smart card. [0202] Sending (416”) a SIGN instruction and the transaction payload to the smart card. Signing the transaction payload on the smart card.

[0203] receiving (418”) by the smartphone a signed transaction payload from the smart card, the transaction signed on the smart card. [0204] Checking (622) whether the status word matches OK. If it does not, throwing an error and displaying the corresponding error message in the application on the smartphone.

[0205] Verifying (420”) the transaction on the smartphone using the public key from the applet. [0206] If the verification is successful, then establishing a secure communication channel with an Ether blockchain server over the Internet (via the mobile network or Wi-Fi) and sending (422”) the signed transaction payload to the blockchain via the blockchain server.

[0207] Receiving (424”) the response from the blockchain server. [0208] Showing (624) the status of the transaction to the end user in the cryptocurrency application on the smartphone.

[0209] Closing (626) the secure communication channel with the blockchain server.

[0210] Closing (628) the secure communication channel with the smart card.

[0211] Removing (630) the smart card from the smartphone. [0212] Example 2 (Validation device emulation)

[0213] According to an aspect of the invention, there is provided a method 700 (Fig. 8-9) of emulating a validation device (100) on a computing device (200). The emulation allows an end user to authorize (authenticate, sign, verify, etc.) blockchain transactions using the emulated device instead of the original one. The method 700 includes steps 402”’-412”’ similar to the corresponding steps

402-412 of the method 400.

[0214] The following example illustrates how a validation device with multiple blockchain containers (applets) can be at least partly emulated on a computing device (200). Thus, in some non-limiting embodiments the validation device 100 can be emulated on some computing device 200.

[0215] The computing device (200) is an Android OS-based smartphone (e.g., OnePlus 9) equipped with an NFC wireless interface and appropriate application for emulation smart cards, and the validation device (100) is a smart card.

[0216] In the example, the smart card has been previously configured by the issuer to comprise several blockchain containers; metadata indicating that: there are several applets on the smartcard; the metadata including the information on the emulating device; the emulation flag that is set to EMULATED during the procedure and the activation flag set to ACTIVATED for the sake of the example.

[0217] Opening (702) the cryptocurrency smart card emulation application on the smartphone. [0218] Connecting (402”’) the smart card to the smartphone via NFC.

[0219] Identifying (404”’) the smart card by exchanging metadata between the smart card and the smartphone.

[0220] Requesting (406’”) by the smartphone a key for establishing a secure communication channel with the smartphone. [0221] Receiving (408’”) on the smartphone a key from the smart card to establish a secure communication channel.

[0222] Establishing (410’”) a SCP02/03 secure communication channel between the smartphone and the smart card for all consequent commands.

[0223] Sending (704) a LIST APPLETS instruction from the smartphone to the smart card.

[0224] In response to the instruction, returning (706) the list of existing applets to the smartphone.

[0225] Sending (708) a SELECT APPLET instruction and the ID of the applet to be emulated to the card. [0226] Sending (710) an OK status word from the smart card to the smartphone.

[0227] Sending (712) a GET METADATA instruction from the smartphone to the smart card.

[0228] In response to the instruction, sending (714) the applet metadata from the card to the smartphone. [0229] Receiving (412”’) the metadata on the smartphone.

[0230] Checking (716) whether the EMULATION flag is unset and, therefore, allows emulation.

[0231] Sending (718) as EMULATE instruction from the smartphone to the smart card. [0232] In response to the instruction, setting (720) the EMULATED flag on the card.

[0233] Storing (722) the emulating device metadata on the smart card.

[0234] Exporting (724) the blockchain-related keys from the applet on the smart card to the smartphone.

[0235] Creating (726) a blockchain container on the smartphone and saving the exported keys in the container.

[0236] Closing (728) the secure communication channel with the smart card.

[0237] Removing (730) the smart card from the smartphone.

[0238] Setting (732) authentication factors for the emulated validation device if requested by the user. [0239] Example 3 (Access token)

[0240] According to an aspect of the present invention, there is provided a method 800 (Fig. 10-11 ) of granting an end user physical access to facilities, e.g., offices, warehouses or storage rooms.

[0241] The method 800 includes steps 402””-424”” similar to the corresponding steps 402-424 of method 400. Method 800 may further comprise supplementary steps 802-818 as shown on Fig. 10-11. However, in general embodiments steps 402””-424”” are sufficient for implementation of the claimed method.

[0242] The following example illustrates how a validation device (100) is used to grant access to facilities. In the example, the computing device (200) is an electronic smart lock equipped with NFC or electrical interface and comprising program instructions configured to interact with a blockchain-based access system, and the validation device (100) is a smart card.

[0243] In the example, the smart card has been previously configured by the owner of the facility to store a keypair that is used to verify access rights in a blockchain- based access system; the metadata indicating access granting per unit of time and temporal limits for access to the facility; the metadata storing the latest access timestamp; flags for access restrictions.

[0244] The access authorization procedure consists of the following steps: [0245] Connecting (402””) the smart card to the smart lock via NFC or electrical interface.

[0246] Identifying (404””) the smart card by exchanging metadata between the card and the smart lock. [0247] Requesting (406””) by the smart lock a key for establishing a secure communication channel with the card.

[0248] Receiving (408””) on the smart lock a key from the smart card to establish a secure communication channel.

[0249] Establishing (410””) a SCP02/03 secure communication channel between the smart lock and the smart card for all consequent commands.

[0250] Sending (802) a GET METADATA instruction and a GET PUBLIC DATA instruction from the smart lock to the smart card.

[0251] In response to the instruction, sending (804) an OK status word and the container metadata from the card to the smart lock. [0252] Receiving (412””) the metadata on the smart lock.

[0253] Using (806) the metadata, preliminary checking access granting per unit of time, temporal limits for access and flags for access restriction.

[0254] If the preliminary access rights check fails, playing (808) an error sound and/or flashing a red light on the smart lock. [0255] If the preliminary access rights check passes, generating (414””) on the smart lock a payload to be signed on the smart card.

[0256] Sending (416””) a SIGN instruction and the transaction payload to the smart card.

[0257] Receiving (418””) by the electronic smart lock a signed transaction payload from the smart card, the transaction signed (418””) on the smart card

[0258] Checking (810) whether the status word matches OK. If it does not, throwing an error (for instance playing an error sound and/or flashing a red light) on the smart lock.

[0259] If the status word does match, then verifying (420””) the signed transaction payload on the smart lock using the public data from the applet.

[0260] If the verification is successful, then establishing (422””) a secure communication channel with the blockchain server of the access control system over the Internet (or another communication network) and sending the signed transaction payload to the blockchain via the blockchain server. [0261] Receiving (424””) the response from the blockchain server. Showing the status of the transaction to the user by means of a green light on the smart lock.

[0262] Writing (812) the access timestamp of the granted access to the metadata.

[0263] Closing (814) the secure communication channel with the blockchain server. [0264] Closing (816) the secure communication channel with the smart card.

[0265] Removing (818) the smart card from the smart lock.

[0266] Example 4 (Gift card)

[0267] According to an aspect of the invention, there is provided a method 900 (Fig. 12-13) of redeeming gift cards issued by a merchant on a blockchain and represented as a validation device. The method 900 includes steps 402’””-

424””’ similar to the corresponding steps 402-424 of method 400. Method 800 may further comprise supplementary steps 902-920 as shown on Fig. 12-13. However, in general embodiments steps 402”’”-424’”” are sufficient for implementation of the claimed method. [0268] In the example, the computing device (200) is a point-of-sales (PCS) terminal (e.g., Verifone X990 or Sunmi V2 Pro Wireless data PCS system) equipped with NFC or the electrical interface comprising program instructions configured to interact with a blockchain-based gift card ledger, and the validation device (100) is a smart card activated and distributed by an issuer who assumes the obligation to provide goods or services according to the balance recorded on the blockchain and verified by the keys stored on the smart card.

[0269] In the example, the smart card has been previously configured by the merchant to comprise a gift card (applet) that stores blockchain-related public and private keys used to redeem the gift card; metadata indicating that a PIN is used to encrypt the gift card applet; metadata storing the number of unsuccessful applet unlocking attempts; the activation flag set to ACTIVATED for the sake of the example.

[0270] The redeeming procedure consists of the following steps:

[0271] Connecting (402’””) the smart card to the point-of-sales terminal via electrical interface.

[0272] Identifying (404’””) the smart card by exchanging metadata between the smart card and the point-of-sales terminal. [0273] Requesting (406””’) by the point-of-sales (POS) terminal a key for establishing a secure communication channel with the smart card.

[0274] Receiving (408””’) on the POS terminal a key from the smart card to establish a secure communication channel. [0275] Establishing (410’””) a SCP02/03 secure communication channel between the point-of-sales terminal and the smart card for all consequent commands.

[0276] Sending (902) a GET METADATA instruction from the point-of-sales terminal to the smart card.

[0277] In response to the instruction, sending (904) an OK status word and the container metadata from the smart card to the point-of-sales terminal.

[0278] Receiving (412’””) on the point-of-sales terminal metadata and public data from the applet.

[0279] In the software on the point-of-sales terminal, asking (906) the user to enter the PIN that protects the gift card (smart card). [0280] Checking (908) PIN on the smart card and resetting the number of tries remaining to unlock the blockchain container if the PIN is correct.

[0281] Sending (910) an UNLOCKED status word from the smart card to the point-of- sales terminal.

[0282] Checking (912) by the point-of-sales terminal the balance, spending limits and/or temporal limits by using the provided metadata.

[0283] Generating (414’””) on the point-of-sales terminal a transaction payload to be signed on the smart card.

[0284] Sending (416’””) a SIGN instruction and the payload to the smart card.

[0285] Receiving 418’”” by the point-of-sales terminal a signed transaction payload from the smart card, the transaction payload signed on the smart card.

[0286] Checking whether the status word matches OK and then verifying (420’””) the signed transaction payload on the point-of-sales terminal using the public data from the applet.

[0287] If the verification is successful, then establishing a secure communication channel with a blockchain server over the Internet (via the mobile network, Wi¬

Fi or Ethernet) and sending (422’””) the signed transaction payload to the blockchain via the blockchain server.

[0288] Receiving (424’””) the response from the blockchain server. [0289] Showing (914) the status of the transaction to the user in the application on the smartphone.

[0290] Closing (916) the secure communication channel with the blockchain server.

[0291] Closing (918) the secure communication channel between the smart card and the point-of-sales terminal.

[0292] Removing (920) the smart card from the point-of-sales terminal.

[0293] Example 5 (Personal identification)

[0294] According to an aspect of the present invention, there is provided a method 1000 (Fig. 14-15) of verification of blockchain-issued personal identification documents.

[0295] The method 1000 includes steps 402”””-424””” similar to the corresponding steps 402-424 of method 400. Method 1000 may further comprise supplementary steps 1002-1022 as shown on Fig.14-15. However, in general embodiments steps 402”””-424””” are sufficient for implementation of the claimed method.

[0296] The following example illustrates how a validation device representing personal ID is used for identity verification by a government officer. In the example, the computing device (200) is a workstation equipped with a connected biometric scanner and comprising program instructions configured to interact with validation devices and the corresponding blockchain-based ID system, and the validation device (100) is a USB token.

[0297] In the example, the USB token has been previously configured by a government agency to comprise a blockchain container storing the end user’s blockchain related data; metadata indicating that a biometric data is used to encrypt the ID applet; metadata storing the number of unsuccessful applet unlocking attempts; metadata storing the end user’s photograph and anthropometric data; metadata storing the latest ID verification timestamp; the activation flag set to ACTIVATED for the sake of the example.

[0298] The ID verification procedure consists of the following steps: [0299] Connecting (402”””) the USB token to the workstation via USB.

[0300] Identifying (404”””) the USB token by exchanging metadata between the token and the workstation. [0301] Requesting (406”””) by the workstation a key for establishing a secure communication channel with the USB token.

[0302] Receiving (408”””) on the workstation a key from the USB token to establish a secure communication channel. [0303] Establishing (410”””) a TLS secure communication channel between the USB token and the workstation for all consequent commands.

[0304] Sending (1002) an instruction GET METADATA to get the metadata and an instruction GET PUBLIC DATA to get the public data from the blockchain container. [0305] In response to the instruction, sending (1004) the metadata from the USB token to the workstation.

[0306] Receiving (412”””) on the workstation metadata and public data (for instance the end user’s photograph, anthropometric data and latest validation timestamp) from the blockchain container of the USB token. [0307] Displaying (1006) the end user’s photograph, anthropometric data and latest validation timestamp on the workstation.

[0308] In the software on the workstation, asking (1008) the user to provide via the connected scanner the biometric data that protects the ID blockchain container.

[0309] Checking (1010) the biometric data on the USB token and resetting the number of tries remaining to unlock the blockchain container if the data is valid.

[0310] Sending (1012) an UNLOCKED status word from the USB token to the workstation.

[0311] Preparing (414”””) on the workstation a payload to be signed on the USB token.

[0312] Sending (416”””) a SIGN instruction and the payload to the USB token. [0313] Receiving (418”””) by the workstation a signed transaction payload from the USB token, the transaction signed on the USB token.

[0314] Checking whether the status word matches OK. If it does not, throwing an error and displaying the corresponding error message in the software on the workstation. If the status word does match, then verifying (420”””) the signed transaction payload on the workstation using the public data from the blockchain container.

[0315] If the verification is successful, then establishing (422”””) a secure communication channel with the ID system blockchain server over the Internet (via the mobile network, Wi-Fi or Ethernet) and sending the signed transaction payload to the blockchain via the blockchain server.

[0316] Receiving (424”””) the response by the workstation from the blockchain server.

[0317] Showing (1014) the status of the ID verification transaction to the operator in the software on the workstation.

[0318] Writing (1016) the ID verification timestamp of the blockchain metadata.

[0319] Closing (1018) the secure communication channel with the blockchain server.

[0320] Closing (1020) the secure communication channel between the USB token and the workstation. [0321] Removing (1022) the USB from the workstation.

[0322] Example 6 (Transaction approval by a quorum of approvers)

[0323] According to an aspect of the invention there is provided a method 1100 (Fig. 16-17) of signing for blockchain transactions by a quorum of approvers which sign the transactions by means of a transaction broker system. [0324] The method 1100 includes steps 402”””’ -424”””’ similar to the corresponding steps 402-424 of method 400. Method 1100 may further comprise supplementary steps 1102-1126 as shown on Fig. 16-17. However, in general embodiments steps 402”’””-424’””” are sufficient for implementation of the claimed method. [0325] The following example illustrates how several validation devices are used by several corresponding approvers to sign one blockchain transaction. In the example, the computing device is either a smartphone equipped with NFC or a workstation comprising program instructions configured to interact with a broker system for secure transactions and equipped with a smart card reader, and the validation devices are smart card.

[0326] In the example, the validation devices (smart cards) have been previously configured by the organization that employs the broker system for transaction signing to comprise a blockchain container with public and private keys for approving blockchain transactions; metadata indicating that a PIN is used to encrypt the gift card applet; metadata storing the number of unsuccessful applet unlocking attempts; the activation flag set to ACTIVATED for the sake of the example.

[0327] The quorum-involving signing procedure consists of the following steps: [0328] Receiving (1102) to the software on each approver’s computing device the broker-provided list of transactions that can be signed by the approvers of the quorum each of whom holds a computing device and a validation device (smart card). [0329] Choosing (1104) by each approver the transaction to be signed.

[0330] Showing (1106) in the software on the computing devices a request to connect the smart card.

[0331] Connecting (402”””’) the smart card to the computing device via NFC or the electrical interface. [0332] Identifying (404’”””) the smart card by exchanging metadata between the card and the computing device.

[0333] Requesting (406’”””) by the computing device a key for establishing a secure communication channel with the smart card.

[0334] Receiving (408’”””) on the computing device a key from the smart card to establish a secure communication channel.

[0335] Establishing (410’”””) a SCP02/03 secure communication channel between the smart card and the computing device for all consequent commands.

[0336] Sending (1108) an instruction GET METADATA to get the metadata and an instruction GET PUBLIC KEY to get the public data from the applet. [0337] In response to the instruction, sending (1110) an OK status word and the container metadata from the smart card to the computing device.

[0338] Receiving (412’”””) on the computing device metadata and public data from the smart card applet.

[0339] In the software on the computing device, asking (1112) the user to enter the PIN that protects the smart card applet.

[0340] Checking (1114) PIN on the smart card and resetting the number of tries remaining to unlock the blockchain container if the PIN is correct.

[0341] Sending (1116) an UNLOCKED status word from the smart card to the computing device. [0342] Checking (1118) by the computing devices which operations their respective approvers can sign.

[0343] Preparing (414’”””) on each computing device a payload to be signed on each respective validation device (smart card). [0344] Sending (416) a SIGN instruction and the payload from each computing device to the respective validation device (smart card).

[0345] Receiving (418) by the computing device a signed transaction payload from the respective smart card, the transaction payload signed on the smart cards. [0346] Checking whether the status word matches OK. If it does not, throwing an error and displaying the corresponding error message in the software on the computing devices. It the status word does match, then verifying (420”””’) the signed transaction payload on the computing device using the public data from the smart card applet. [0347] If the verification is successful, then establishing a secure communication channel with the broker server over the Internet (via the mobile network, Wi-Fi or Ethernet) and sending (422”””’) the payloads to the broker (distributed ledger).

[0348] Receiving (1120) the response from the blockchain server that the required number of approvers have signed the transaction correctly.

[0349] Receiving (424’”””) the status of the transaction to the approvers in the software of their respective computing devices.

[0350] Closing (1122) the secure communication channel with the broker server.

[0351] Closing (1124) the secure communication channel between the smart cards and the computing devices.

[0352] Removing (1126) the smart cards from the computing devices.

[0353] Modifications and improvements to the above-described embodiments of the present technology may become apparent to those skilled in the art. The following description is illustrative only and is not intended to be in any way limiting. Thus, the scope of present technology is limited by the scope of the appended claims only.

Claims

Claims A validation device for validation (and/or authentication and/or authorization and/or signing and/or verification) of blockchain transactions, the validation device comprising the following modules: non-volatile memory to store data; at least one physical communication interface; an integrated circuit (IC) capable of executing program instructions; wherein the validation device is configured to store blockchain-related data in a blockchain container, metadata and program instructions in the memory of the validation device, while the program instructions are configured to: generate a blockchain container; store a blockchain container in the memory of the validation device; establish a secure communication channel with a computing device via at least one communication interface; receive blockchain transaction data from a computing device via at least one communication interface; validate and/or authenticate and/or authorize and/or sign and/or verify a blockchain transaction using the data in a blockchain container; return the validated and/or authenticated and/or authorized and/or signed and/or verified blockchain transaction to the computing device via at least one communication interface; wherein the memory contains at least one of the following metadata types: the validation device ID, the validation device issuer ID, the end-user’s name, the end-user’s ID, wherein the program instructions are configured to use at least part of metadata as an input parameter for establishing a secure communication channel with a computing device and/or configured to sending at least part of metadata to a computing device via at least one communication interface. The validation device according to claim 1 , wherein the memory contains at least one of the following supplementary metadata types: an issuance date, an expiration date, an activation flag, additional cryptographic keys for establishing secure communication with a computing device, locking factors flags indicating that a blockchain container is locked or unlocked, authentication factors required to unlock a blockchain container, the number of factors necessary to unlock a blockchain container, the number of tries remaining to unlock a blockchain container before the validation device is deactivated and/or the container is erased, wherein the program instructions are configured to use at least part of supplementary metadata as an additional input parameter for

36 establishing a secure communication channel with a computing device and/or configured to sending at least part of supplementary metadata to a computing device via at least one communication interface.

3. The validation device according to claim 1 , wherein the blockchain-related data in the blockchain container and/or the program instructions are preinstalled on the validation device and prestored.

4. The validation device according to claim 1 , wherein the program instructions are configured to generate a blockchain container and store in the memory of the validation device by means of connecting the validation device to a computing device via at least one physical communication interface.

5. The validation device according to claim 1 , wherein the blockchain-related data in the blockchain container and/or the program instructions are configured to be edited by means of connecting the validation device to a computing device via at least one physical communication interface.

6. The validation device according to claim 1 , wherein the program instructions are additionally configured to locking and unlocking the blockchain container using one or several of the following locking factors: a PIN, biometric data, a password, a security token.

7. The validation device according to claim 1 , wherein the program instructions are configured to store at least one additional blockchain container in the memory of the validation device.

8. The validation device according to claim 1 , wherein the blockchain container is configured to store at least one additional set of blockchain-related data.

9. The validation device according to claim 2, wherein supplementary metadata in the memory include an encryption flag for marking the encrypted state of the validation device comprising program instructions configured to encrypt and decrypt the blockchain container.

10. The validation device according to claim 2, wherein supplementary metadata in the memory include an emulation flag; the blockchain-related data are encrypted on the validation device; and the validation device includes additional program instructions configured to: decrypt at least part of the blockchain- related data stored in the blockchain container; export at least part of decrypted blockchain-related data, allowing at least partial emulation of the validation device.

37 The validation device according to claim 2, wherein supplementary metadata in the memory comprise an expiration date and blocking conditions, including at least one of the following: the number of tries remaining to unlock a blockchain container, an expiration date; and the validation device comprises additional program instructions configured to deactivate the validation device and/or erase the blockchain container in response to reaching the expiration date and/or the number of tries to unlock the container. The validation device according to any of the preceding claims, wherein at least one of the communication interfaces is at least one or more of the following: NFC, Bluetooth, Bluetooth Low Energy, Wi-Fi or USB, and the validation device is configured to establish a secure communication channel with a computing device via at least one aforementioned communication interface. The validation device according to any of the preceding claims, wherein the blockchain-related data stored in the blockchain container contain a blockchain wallet; program instructions stored in the memory are configured to apply the blockchain wallet to validate transactions for at least one of the following financial instruments: crypto currencies on a blockchain, digital assets on a blockchain, digital securities issued on a blockchain, central bank digital currency; and the metadata stored in the memory additionally contain at least one of the following: a list of supported financial instruments, a balance for off- blockchain transactions, spending limits on funds, spending limits allowed without authentication, temporal limits, a list of allowed destinations for fund transfers. The validation device according to any of the preceding claims, wherein the blockchain-related data stored in the blockchain container contain a gift card and/or voucher issued on a blockchain, and program instructions stored in the memory are configured to apply the gift card and/or voucher to validate transactions on a blockchain. The validation device according to any of the preceding claims, wherein the blockchain-related data stored in the blockchain container contain at least one loyalty program account issued on a blockchain, and program instructions stored in the memory are configured to apply at least one loyalty program account to validate transactions on a blockchain.

16. The validation device according to any of the preceding claims wherein the blockchain-related data stored in the blockchain container contain a ticket maintained on a blockchain, and program instructions stored in the memory are configured to apply the ticket to validate transactions on a blockchain, while the data stored in the blockchain container additionally contain at least one of the following: a balance for off-blockchain transactions, spending limits on funds, temporal limits, timestamps of a certain number of latest usages.

17. The validation device according to claims 12-15, wherein the data stored in the blockchain container additionally contain a limit value of the funds available in blockchain-related data stored in the blockchain container, and program instructions stored in the memory are configured to prohibit transactions in response to reaching the limit value of the funds available.

18. The validation device according to any of the preceding claims, wherein blockchain-related data stored in the blockchain container contain a membership account based on a blockchain, and program instructions stored in the memory are configured to apply the membership account to validate transactions on a blockchain; while the data stored in the blockchain container additionally contain at least one of the following: the end user’s tier, the end user’s age rating, a set of permissions to use the services.

19. The validation device according to any of the preceding claims, wherein blockchain-related data stored in the blockchain container contain an access token based on a blockchain; and program instructions stored in the memory are configured to apply the access token to validate transactions on a blockchain; while the data stored in the blockchain container additionally contain at least one of the following: timestamps of the latest access grants or refusals, limits on access grants per unit of time, temporal limits, flags for access restriction.

20. The validation device according to any of the preceding claims, wherein blockchain-related data stored in the blockchain container contain personal identification data, and program instructions stored in the memory are configured to apply the personal identification data to validate transactions on a blockchain, while the data stored in the blockchain container additionally contain at least one of the following: the end user’s photograph, anthropometric and appearance data, timestamps of the latest document validation events.

21. The validation device according to any of the preceding claims, wherein program instructions stored in the memory are configured to apply the blockchain-related data stored in the blockchain container to sign for data in automated document management workflows on a blockchain.

22. The validation device according to claim 21 , wherein blockchain-related data stored in the blockchain container contain additional data representing information about the quorum of approvers to authorize and/or authenticate and/or sign and/or validate and/or verify blockchain transactions; program instructions stored in the memory are configured to validate transactions on a blockchain in response to the presence of the quorum of approvers; the data stored in the blockchain container additionally contain: cryptographic keys for establishing an encrypted communication channel and the list of supported transactions and/or transaction types.

23. The validation device according to claim 21 , wherein the blockchain-related data stored in the blockchain container contain additional data specific to the transaction-signing broker system, and program instructions stored in the memory are configured to provide approver quorums for transactions with blockchain-based broker systems for secure transactions.

24. The validation device according to any of the preceding claims, wherein blockchain-related data stored in the blockchain container contains additional data representing conditions of blockchain-issued smart contract fulfilment, and program instructions stored in the memory are configured to hold and execute smart contracts on a blockchain in response to the conditions of smart contract fulfilment being met; while the data stored in the blockchain container additionally comprise a set of permissions and limits unlocked upon the execution of smart contracts.

25. The validation device according to any of the preceding claims, wherein blockchain-related data stored in the blockchain container contain additional data relevant to secondary actions, and program instructions stored in the memory are configured to sign and/or authenticate and/or authorize and/or validate secondary non-blockchain related actions.

26.A method of executing blockchain transactions in a system, comprising a validation device according to claims 1 -25 and a computing device connected to at least one communication network in order to access a blockchain, the method comprising the following steps: Step 1 ) connecting the validation device to the computing device via at least one communication interface; Step 2) identifying the validation device by exchanging metadata between the validation device and the computing device; Step 3) requesting by the computing device a key for establishing a secure communication channel with the validation device; Step 4) receiving on the computing device a key from the validation device to establish a secure communication channel; Step 5) establishing a secure communication channel between the validation device and the computing device for all consequent commands; Step 6) receiving on the computing device metadata and public data from the blockchain container of the validation device to identify which transactions are supported; Step 7) generating blockchain transaction payload by the computing device; Step 8) sending the payload to the validation device; Step 9) receiving by the computing device a signed transaction payload from the validation device, the transaction signed using the blockchain-related data stored in the blockchain container of the validation device; Step 10) verifying the signed transaction payload on the computing device using the public data from the blockchain container of the validation device received on Step 6); Step 11 ) pushing the signed transaction to the blockchain; Step 12) receiving by the computing device the success status of the transaction from the blockchain. The method according to claim 26, further comprising an additional step between Step 5) and Step 6), with a view to checking the activation status of the validation device; the additional step including at least one of the following: receiving by the computing device supplementary metadata, including the activation flag stored on the validation device, and/or receiving activation status information of the validation device stored on the computing device and/or any external source available to the computing device via the communication network; in response to the validation device already having been activated, the method proceeds to Step 6 in response to the validation device not having been activated the method includes the following activation steps before proceeding to Step 6: requesting by the computing device a PIN and/or biometric data and/or other authentication factors and sending them to the validation device; saving the authentication factors by the validation device; generating keys to be stored in the blockchain container of the validation device; putting the

41 validation device into a protected state and encrypting the blockchain container of the validation device. The method according to claim 26, wherein the activation steps additionally comprise: requesting from the end user by the computing device an ID for the validation device and sending it to the validation device; saving by the validation device the ID along with the authentication factors. The method according to claim 26, further comprising, if the blockchain container is in the protected state and encrypted, additional steps between Step 5) and Step 6), with a view to authenticating the validation device on the computing device by using one or several authentication factors, the additional steps being: receiving from the end user the authentication factors on the computing device; sending by the computing device the authentication factors to the validation device to be checked; checking the authentication factors on the validation device, in response to the authentication factors being valid, the validation device leaving the protected state, decrypting the blockchain container of the validation device; sending by the validation device a success status to the computing device. The method according to claim 29, further comprising additional steps after the checking of the authentication factors on the validation device with a view to deactivating the validation device after a predefined number of unsuccessful authentication attempts; the additional steps being: erasing the blockchain- related data in the blockchain container of the validation device; setting the flag marking that the metadata stored in the memory of the validation device has been erased. The method according to claim 26, wherein the blockchain container of the validation device stores blockchain-related data representing a wallet for cryptocurrencies, digital assets, digital securities, the method including additional steps after the putting the validation device into a protected state and encrypting the blockchain container; the additional steps being: exchanging data between the validation device and computing device with a view to establishing a secure connection between the computing device and the blockchain provider server via a communication network; establishing a secure connection with the blockchain provider server; registering the validation device

42 in the blockchain by sending the public data from the blockchain container of the validation device to the blockchain provider server.

32. The method according to any of the claims 26-31 , further comprising additional steps between Step 6) and Step 7), with a view to emulating the blockchain container on the computing device; the additional steps being: checking that the emulation flag in the validation device metadata permits emulation; sending the private data of the blockchain container of the validation device to the computing device; saving to the validation device the metadata indicating the fact that the validation device has been emulated, as well as the ID of the target computing device that serves for emulation; creating by the computing device an emulated blockchain container; putting the blockchain-related data into the emulated blockchain container; starting the activation procedure for the emulated validation device according to claim 29; wherein the computing device includes secure cryptoprocessor or similar specialized secure enclave and stores the emulated blockchain container therein.

33. The method according to any of claims 26-32, wherein the blockchain container of the validation device stores blockchain-related data representing at least one of the following: a wallet for cryptocurrencies, digital assets, digital securities, a gift card, a voucher, a ticket; the method including additional steps between Step 6) and Step 7), with a view to checking the balance of the funds and/or the temporal limits for transactions available to the end user; herewith the additional steps being: checking by the computing device the balance, spending limits and/or temporal limits by using the metadata from the blockchain container of the validation device and exchanging information with the blockchain provider server; comparing by the computing device the balance and/or the temporal limits stored on the validation device with the transaction data; denying the transaction on the computing device in response to the transaction data including the value exceeding the balance and/or the temporal limits stored on the validation device.

34. The method according to claims 26-33, wherein the blockchain container of the validation device stores blockchain-related data representing membership cards, the method including additional steps between Step 6) and Step 7), with a view to checking whether the end user has the right to use the corresponding services; the additional steps being: checking by the computing device which

43 services are available to the end user; denying the transaction by the computing device in response to the transaction data including at least one of the services not available to the end user of the validation device. The method according to claims 25-33, wherein the blockchain container of the validation device stores blockchain-related data representing access tokens, the method including additional steps between Step 6) and Step 7), with the view of checking whether the end user has the right to access the corresponding facilities; denying by the computing device the transaction in response to the transaction data including at least one of access facilities not granted to the end user of the validation device. The method according to claims 26-35, wherein the blockchain container of the validation device stores blockchain-related data representing identification documents, the method including an additional step between Step 6) and Step 7), with a view to displaying additional information; the additional step being: receiving by the computing device the public data such as the end user’s photograph, anthropometric data and/or timestamps from the validation device to be displayed on the computing device. The method according to claims 26-36, wherein the blockchain container of the validation device stores blockchain-related data for signing of documents in automated document flows, the method including additional steps after Step 6) for signing the documents; the additional steps being: checking by the computing device as to which documents and/or types of documents the end user is authorized to sign; with additional steps further comprising, between Step 7) and Step 8): obtaining by the computing device from the blockchain provider server the documents to be signed by the end user; denying the transaction by the computing device in response to the end user of the validation device not being authorized to sign at least one document or type of documents. The method according to claims 26-37, wherein the blockchain container of the validation device stores data for the approval of transactions that follow the four- eyes principle or require a quorum in a broker system for secure transactions, the method after Step 6) including additional steps of approving such transactions; and additional steps being: added between Step 6) and Step 7) comprising: checking by the computing device as to which transactions and/or

44 types of transactions the end user of the validation device is authorized to sign; the method comprising: denying the transaction by the computing device in response to the end user of the validation device not being authorized to sign at least one of transaction or type of transections; the method further comprising between Step 13) and Step 14): approving the transaction in response to receiving the quorum from the blockchain provider server. The method according to claims 26-38, wherein the validation device is configured to sign, authenticate, authorize and/or validate secondary nonblockchain actions, the method including additional steps after Step 6) for executing such actions; the additional steps being: requesting by the computing device the data about the actions available to the end user of the validation device; performing by the computing device actions according to the actions available to the end user of the validation device. The method according to claims 26-39, wherein the blockchain container stores at least one additional set of blockchain-related data as well as the method comprising a step of choosing a set of blockchain-related data on the computing device and signing the payload using the chosen blockchain-related data stored in the blockchain container of the validation device.

45