Digital asset custody system

Abstract

A digital asset custody system is disclosed for maintaining the custody of cryptocurrencies and / or other digital assets and controlling access to them. This digital asset custody system includes multiple layers of security to enable the secure maintenance of large amounts of digital assets. The system may include a combination of biometric-based multi-user authentication, transaction risk analysis, and a hardware security module (HSM) that provides authentication / verification functions and secure storage of private keys for digital assets.

Description

[0001] This application claims the benefit of U.S. Provisional Patent Application No. 62 / 636,106, filed February 27, 2018; U.S. Provisional Patent Application No. 62 / 640,429, filed March 8, 2018; and U.S. Patent Application No. 16,011,529, filed June 18, 2018, each of which is incorporated herein by reference in its entirety. Technical Field

[0002] At least one embodiment of the present invention relates to a computer system, and more particularly, to a computer-implemented system for maintaining the custody of digital assets such as cryptocurrencies. Background Technology

[0003] In recent years, cryptocurrencies such as Bitcoin, Ethereum, and Ripple have gained popularity and value, and many expect this to continue. The variety of cryptocurrency-based transactions is increasing daily, and it's conceivable that new types of crypto assets—not necessarily currencies—may emerge in the future.

[0004] As the use of crypto assets increases, there is a need for trusted custodian systems that can securely store large amounts of crypto assets and control access to them. In fact, U.S. securities regulations require certain entities holding more than a certain amount of funds (e.g., $150 million) on behalf of another party to use custodians to hold those funds. While hardware wallets and other forms of "cold storage" are sometimes used to store cryptocurrencies, these devices restrict access only to the device's owner, making them unsuitable for many business purposes where numerous individuals may need access to crypto funds or other crypto assets. Attached Figure Description

[0005] One or more embodiments of the invention are shown by way of example and not limitation in the figures, wherein the same reference numerals denote similar elements.

[0006] Figure 1 This is a high-level block diagram of the Crypto Asset Custody System (CCS).

[0007] Figure 2A This is a schematic diagram illustrating an example of a deposit processing flow using CCS.

[0008] Figure 2B This is a flowchart illustrating an example of the storage processing flow.

[0009] Figure 3A This is a schematic diagram illustrating an example of the withdrawal process using CCS.

[0010] Figure 3B This is a flowchart illustrating an example of the retrieval process.

[0011] Figure 4 This is a flowchart illustrating an example of the processing performed by the Hardware Security Module (HSM) in conjunction with the requested operation.

[0012] Figure 5 This is a flowchart illustrating an example of a process for endorsing a requested transaction using an offline user device.

[0013] Figure 6 This is a high-level block diagram illustrating an example of a hardware architecture that can be used to implement part or all of a processing system for a CCS or user device. Detailed Implementation

[0014] In this specification, references to "embodiment" or "an embodiment," etc., mean that a particular feature, function, structure, or characteristic being described is included in at least one embodiment of the technology described herein. The appearance of these phrases in this specification does not necessarily refer to the same embodiment. Furthermore, the mentioned embodiments are not necessarily mutually exclusive.

[0015] Overview

[0016] This document describes a computer-implemented crypto asset custody system (CCS), a computer-implemented system for maintaining custody of cryptocurrencies and / or other crypto assets and controlling access to them. A CCS may be owned and / or operated by a commercial enterprise (referred to herein as a crypto asset custody institution). A CCS incorporates multiple layers of security to enable the secure maintenance of large amounts of crypto assets. In some embodiments, a CCS includes a combination of biometric-based multi-user authentication, transaction risk analysis, and the use of a hardware security module (HSM) to provide authentication / verification functionality and secure storage of private keys for crypto assets. Furthermore, two or more different biometric authentication technologies can be applied to any given transaction request. As used herein, the term "hardware security module" or "HSM" refers to a dedicated physical computing device used to protect and manage digital keys used for authentication and to provide cryptographic processing functionality. An HSM may be embodied as a card or an external device directly attached to a computer.

[0017] In some embodiments, when a user requests a transaction involving crypto assets (such as the withdrawal or transfer of cryptocurrency funds), the CCS causes an endorsement request message to be sent to each of a plurality of user devices, each user device being associated with a different user who has been defined as a potential member of a predetermined number (quorum) for a transaction involving the crypto asset (in other embodiments, multiple users may share the same user device). The endorsement request message is configured to prompt each receiving user device to provide an endorsement of the requested transaction by its user. In this context, an endorsement is the user's approval or rejection of the operation. When a user who receives such a prompt endorses the transaction on his or her user device (e.g., a smartphone, tablet, or laptop), the user device signs the endorsement message with the user's private key and sends the signed endorsement message to the CCS. The private key is stored in a secure designated address space within the user device. The secure designated address space in each user device is used to store the corresponding user's private key and generate the user's digital signature.

[0018] The HSM determines whether a policy-based number of users have endorsed (approved) a requested action, such as the withdrawal or transfer of cryptocurrency funds. In the endorsement message received from the users, the HSM verifies the signature for each of the multiple users using the public key in their public-private key pair. Only after determining that the policy-based number of users have properly endorsed the requested action does the HSM then allow itself access to the private key of that specific crypto asset previously generated by the HSM (e.g., for a specific deposit into a cryptocurrency fund) and use that private key to sign the transaction as authorization for it to proceed. The private key of the crypto asset is stored only within the HSM, and no entity outside the HSM is permitted to read it. Transaction approval may include, for example, sending the transaction to a known blockchain network. In some embodiments, HSM approval of a transaction occurs only after the requested transaction has undergone a risk review, which may be partially or fully automated. Further details will become apparent from the following description. It should also be noted that the systems and techniques described herein are intended for the secure custody of other types of digital assets besides crypto assets.

[0019] Now for reference Figure 1 , Figure 1A high-level block diagram of the CCS is shown. In the illustrated embodiment, CCS 1 includes an online server 2, a relay server 3, a risk analysis phase 4, an HSM 5, and a data storage facility 6. The data storage facility 6 may include one or more databases, which may be or include relational databases or any other type of organization for storing data in an organized manner, wherein the data may be structured data and / or unstructured data. The HSM 5 also includes its own internal secure storage facility 7. Note that multiple instances of each of the above components may exist in CCS 1, although only one instance of each component is shown for simplicity. One or more user devices 8 (also referred to as clients) may communicate with CCS 1 via a public computer network 9 such as the Internet. Each user device may be, for example, a smartphone, tablet computer, laptop computer, and desktop computer. Each user device 8 may include a secure designated address space 14, such as an iOS-based secure designated address space, which stores the private key of the respective user and generates the digital signature of the user. In at least some embodiments, each user device 8 is associated with a different user, and such embodiments are used in the following description for ease of illustration. However, note that there may be embodiments where multiple users share the same user device 8.

[0020] Relay server 3 acts as a virtual air gap to isolate HSM 5 from the public computer network 9. Relay server 3 and HSM 5 operate within secure zone 10. HSM 5 can reside physically in a physically secure data center that has no direct access to any external networks. Messages between HSM 5 and online server 2 are routed to relay server 3 in secure zone 10 over a half-duplex (outbound request-response only) connection. Relay server 3 disconnects itself from the secure network when communicating with online server 2 and from all external networks when communicating with HSM 5, making it impossible to establish interactive sessions with these devices from the outside. This provides virtual "air gap" security for critical infrastructure.

[0021] In some embodiments, CCS 1 may also access at least one blockchain network 11 corresponding to the crypto assets for which CCS 1 has custody. Access to the blockchain network 11 may be via a public computer network 9 (e.g., the Internet).

[0022] In some embodiments, each transaction submitted by a CCS 1 customer will undergo a risk analysis phase 4, which may be partially or fully automated. For example, in some embodiments of CCS 1, a human risk analysis agent may evaluate the output of the automated risk analysis software displayed on a risk review dashboard to determine whether the transaction has been adequately authorized for acceptance. The risk analysis agent or software may follow strategies set on individual vaults and may review any risk signals from various sources (e.g., transaction amount, number of users authorizing the transaction, location of the request and approval, destination address) to calculate a final risk score that may lead to transaction approval or a request for more information.

[0023] deposit

[0024] Now for reference Figure 2A and 2B , Figure 2A and Figure 2B An example of the process of depositing crypto assets, such as a certain amount of cryptocurrency, using CCS 1 is illustrated. The deposit is initiated by a client via the Internet through a software application (hereinafter referred to as the "CCS application") (not shown) executed on the client's user device 8. This can be done by the client selecting the asset type and requesting a deposit of a given amount in the CCS application. Once initiated, the request for the blockchain deposit address is then sent to online server 2, which receives the request (step 201) and forwards the request to HSM5 via relay server 3 (as described above, HSM 5 is isolated from the Internet via relay server 3) (step 202). HSM 5 then generates a new public-private key pair 21 (step 203) to uniquely correspond to the deposit, i.e., to the requested blockchain address. In some embodiments, HSM 5 uses the private key of the relevant organization and a key derivation function (KDF) to generate a new key pair for the blockchain address. As discussed further below, "organization" in this context refers to a data structure corresponding to a specific client. The private key in the newly generated key pair cannot be extracted from HSM 5, but can be securely backed up in an encrypted file. Key generation within HSM 5 ensures that private key 21 exists only within HSM 5, is not available anywhere else in the world, and cannot be accessed by any entity outside of HSM 5.

[0025] Next, HSM 5 generates the blockchain address to be stored based on the public key in the newly created key pair (step 204). This can be achieved by using a blockchain-specific transformation of the public key of a well-known blockchain address. HSM 5 then signs the blockchain address with the organization's private key (step 205) and returns the signed blockchain address to online server 2. Online server 2 then causes the signed blockchain address 22 to be sent to the client's user device 8 (step 206), so that user device 8 can present the address to the client in an easy-to-use format (e.g., as a QR code) in the CCS application on the user device as the destination address in blockchain transactions. The CCS application on the user device verifies the signature of the address before presenting it to the client (step 207).

[0026] The client's user device 8 uses the organization's public key (which was previously received from CCS 1 and stored locally) to verify the authenticity of the blockchain address received by the user device 8 from CCS 1. The client then initiates a transaction to deposit assets into CCS 1 (step 208). This transaction can be initiated from an exchange, from the client's personal wallet, or from another crypto asset store. The assets appear in CCS 1 without requiring confirmation.

[0027] The deposited address is stored in a collection (referred to as the customer's "vault") along with other addresses belonging to the customer in CCS 1. In this context, the vault is a data entity containing assets and a policy graph that includes one or more policies for managing the deposits and withdrawals of these assets. Crypto assets are represented as slots within the vault that can hold a certain amount of an asset type (e.g., Bitcoin, Ethereum). Once custodied and deposited using CCS 1, the assets are entirely under the control of CCS 1.

[0028] Online server 2 determines whether the customer has confirmed the transaction within the defined time period (steps 209, 210). Once the deposit transaction is confirmed by the customer and verified on the blockchain, online server 2 notifies the customer of this status (step 211), and the asset is considered to be held in custody by CCS 1. If no confirmation is received within the defined time period, the online server notifies the customer of an error in the transaction (step 212).

[0029] take out

[0030] Figure 3A and 3BThis illustrates an example of the process for withdrawing a certain amount of previously deposited crypto assets (such as cryptocurrency). The withdrawal can be initiated from the CCS application on user device 8A by selecting the specific crypto assets and amount to be withdrawn. Once initiated, the withdrawal request is made known to all authorized parties, and each authorized party is required to authorize the withdrawal individually on their mobile devices 8A and 8B.

[0031] During this process, users are required to review and approve transactions, with each user's approval being biometrically authenticated (e.g., fingerprint, facial recognition, and / or voice recognition). In some embodiments, each request is sent to a risk analysis phase for scrutiny and authorization as legitimate before it can successfully proceed to the next stage. HSM 5 verifies that a transaction has been authorized for a defined, prescribed number of users (e.g., a majority), and the transaction is approved by risk review phase 4. For example, for a specific corporate client with five different employees who need the ability to transfer funds, an appropriate prescribed number configuration might be that a group of three of these five employees is required to move any funds. HSM 1 then proceeds to signing and submitting the asset flow transaction to blockchain 11.

[0032] exist Figure 3B The following further illustrates an example of the withdrawal process. Online server 2 initially receives withdrawal request 31 from the client (step 301). Online server 2 then checks the approval policy for the crypto asset being traded (as shown in the crypto asset vault) (step 302) to determine which individuals' authorizations (endorsements) are available to satisfy the prescribed amount required to approve the withdrawal. Online server 2 then sends endorsement requests to the mobile devices 8A, 8B of these individuals (which have previously been registered in CCS 1) (step 303). In response to these requests, one or more endorsement messages may be received from the users' mobile devices 8A, 8B, wherein, as further described below, these endorsement messages are locally signed by the users' respective private keys securely stored in their respective mobile devices and are authenticated by one or more biometric authentication technologies. Therefore, as specified in the policy for the crypto asset, online server 2 determines whether the prescribed number of authorizations has been received within the timeout period and whether the corresponding authorizing party has been authenticated (step 304). If yes, online server 2 forwards transaction request 31 to risk analysis stage 4 (step 305). Otherwise, the online server will send a transaction rejection notification at least to the user who requested the transaction (and possibly to all other users identified in the policy for the crypto asset) (step 310).

[0033] Risk analysis phase 4 involves risk analysis, which can be fully or partially automated as described above (step 306), or in some embodiments, can be performed entirely by one or more people (based on computer output data). If the transaction passes the risk analysis (step 306), the control flow is passed to HSM 5, which verifies that the specified quantity requirement is met by performing the same or similar judgment as in step 304 (step 308), as does risk analysis phase 4 (step 306) (further described below). If HSM 5 verifies that the specified quantity is met, HSM signs the withdrawal transaction with the private key of the blockchain address and submits the transaction to blockchain 11 to execute the withdrawal (step 309). Otherwise, HSM 5 signals a failure to online server 2, which in response sends a transaction rejection notification at least to the user who requested the transaction (and possibly to all other users identified in the policy for the crypto asset) (step 310).

[0034] User authentication

[0035] As described above, when a user endorses a transaction request, the user is authenticated by their mobile device and / or CCS 1 using one or more forms of authentication to determine that the user is the intended person to take the action. These forms of authentication may include one or more biometric authentication technologies, such as fingerprint verification, voiceprint verification, voice recognition, facial recognition, and / or gesture recognition. The user's mobile device (e.g., a smartphone) may perform one or more of these authentication technologies.

[0036] Additionally or optionally, users may be required to upload videos taken using their mobile devices to CCS 1, where the user's identity can be verified from the video, for example, by: identifying the user's face in the video against an image of a known face (e.g., a previous video of the user); identifying the user's voice in the video against a trained voice profile of the user; requesting the user to say specific words or perform specific actions in the video based on a transaction (see further discussion below); requesting the user to assume a previously specified posture or a painful posture when in pain; requesting the user to identify the intended room in the video; and / or any other actions deemed to increase the level of confidence that the user is who he or she claims to be.

[0037] When deemed necessary, a user can be asked to complete a challenge to verify that he or she is indeed the person authorized to take action on the transaction. These challenges can be generated deterministically based on the context of the transaction. For example, based on key information in the transaction such as ID, amount, destination, etc., CCS 1 can generate random numbers that can be used to select several (e.g., three to five) words from a set of known words. CCS 1 can present these words to the user and have the user say them in a video taken by the user's mobile device, which is then sent to CCS 1. During transaction review, the review body or human reviewer can independently generate the expected words based on the transaction data and verify that the user said those words. The video can also be subjected to facial and / or voice recognition. By generating such deterministic challenges, attackers can prevent forging transactions by taking and reusing previously sent authentication videos from users.

[0038] HSM Logic

[0039] The primary function of HSM 5 is to verify the legitimacy of operations. HSM 5 executes the signer's intent and authenticates the signer as the authorizing party of the operation through privileged access to the key via the HSM. The key required to sign a transaction is securely stored in the HSM 5 and never leaves. In some embodiments, HSM 5 reinforces these policies through a Secure Execution Environment (SEE), which runs code that cannot be altered except through physical access to the HSM 5 and requires a set of smart cards securely held by multiple employees of the crypto asset custodian.

[0040] In some embodiments, to facilitate the above functionality, HSM 5 stores multiple instances of a data structure called an "Organization" in its internal storage device 7, with one instance stored for each client of the crypto asset custodian. The Organization data structure may contain the following fields: an identifier (ID) for the organization, the name of the organization, the organization's public key, a list of users belonging to the organization, a policy graph, a list of vaults belonging to the organization and their respective policy graphs, and a generation number that increments with each update to the organization structure. A "policy graph" is a set of policies that includes a policy for each possible action that can be performed (e.g., adding a user, changing a vault policy, etc.). The organization is signed by HSM using the organization's private key (stored in HSM 5 and not readable by any external entity) to indicate that the organization was created through a valid set of changes authorized by users and risk reviewers. HSM keeps track of the latest version to prevent rollback attacks.

[0041] To add new customers, HSM 5 creates a new organization instance. To help ensure full security, HSM 5 can create the organization using a requested set of users already in the organization. In some embodiments, HSM 5 must generate a new, unique key for each new organization created in this way. This prevents attackers from asking HSM 5 to generate a "new" organization with the same ID as an existing organization and then deceiving users into trusting that "new" organization.

[0042] Figure 4 Examples of processing that can be performed by HSM 5 in response to a request to perform an operation are shown in at least some embodiments. This request may be received by HSM 5 from relay server 3. Initially, HSM 5 receives an operation description for a specified organization from relay server 3 (step 401). This operation description is a set of data and metadata describing the requested operation (such as the deposit, withdrawal, or transfer of requested cryptocurrency). HSM 5 then verifies the integrity of the specified organization (step 402).

[0043] Then, HSM 5 looks up the policy in the organization's or vault's policy graph (step 403). Next, HSM 5 examines the policies of internal risk reviewers to determine which internal risk endorsements must be made and how many (i.e., endorsements from personnel at the crypto asset custodian) (step 404). Then, HSM 5 determines whether any endorsements received (from the user) indicate a "REJECT" of the requested operation (step 405). If yes, HSM 5 rejects the requested operation by returning a "REJECT" message to the relay server (step 411), which then returns a corresponding "REJECT" message to the online server to notify the requester. In this case, HSM 5 does not bother to check the signature and simply rejects the operation.

[0044] HSM 5 then determines whether all received endorsements for the transaction are valid (step 406). This includes verifying the legitimacy of the provided endorsements by checking the following: i) the user is in the organization; ii) the signature is correct for the specified operation; and iii) each signature has an "approval" decision. If not all received endorsements for the transaction are valid, the process proceeds to step 411 as described above.

[0045] If all received endorsements for the transaction are valid, HSM 5 then determines whether the endorsement satisfies the relevant policy of the target crypto asset (i.e., meets the specified quantity) (step 407). If a valid endorsement does not satisfy the policy, the process proceeds to step 411 as described above. If the endorsement satisfies the policy, HSM 5 determines whether the requested operation passes the risk analysis phase (step 408). If "No", the process proceeds to step 411 as described above. If the requested operation passes the risk analysis phase, HSM 5 determines whether the requested operation is valid (step 409). This step may include verifying that the operation is internally consistent and can be applied to the organization, vault, or asset to which the operation is targeted. If the requested operation is invalid, the process proceeds to step 411 as described above. Otherwise, HSM 5 executes the requested operation (or triggers an action that causes the operation to be executed) (step 410). The operation used to change the organization, vault, or policy results in a new signed organization data structure with a higher generated value and applied changes. Operations used to withdraw assets enable HSM 5 to sign blockchain transactions using the private key corresponding to the asset. Operations used to deposit assets enable HSM 5 to generate a deposit address.

[0046] Offline device endorsement

[0047] As a method to reduce the risk of users interacting with CCS applications on their personal devices, CCS 1 may require authorization from an offline device. This device (such as a consumer phone or a similar computing device with a securely designated address space, or an iPod Touch) would be completely disconnected from the Internet under normal conditions and would be used offline to sign transactions required for authorization.

[0048] The process can be performed as follows: The user's phone or similar device is a designated number of members of his / her vault policy and is not connected to any wireless or cellular network. The device runs software similar to, or the same software operating in a different mode, the CCS application software used to enable the user to endorse the requested transaction. The user initiates a transaction for his / her vault through one of the designated number of devices. An online device, such as another phone or web browser, has access to the transaction. The online device can be another phone / security device among the designated number, or the online device may exist solely to display the transaction. The device is able to send data that requires signature by the offline device to the offline device. This can be achieved through a channel not accessible via the Internet (such as displaying a QR code, playing an encoded sound or sound sequence, or sending via Bluetooth). The offline device displays the data sent for the offline device's signature, for the user to approve or reject. The offline device signs the endorsement of the operation based on the user's expected action. The offline device sends its signed payload communication back to the online device in a manner similar to that used for receiving (e.g., displaying a QR code, playing an encoded sound or sound sequence, or sending via Bluetooth). The online device then sends the signed payload communication back to the online server of CCS 1.

[0049] Figure 5The flowchart further illustrates the process according to certain embodiments. The online user device receives an operation description from the CCS via the Internet (step 501). The online user device then sends the operation description (or a portion thereof) to an offline user device file via an offline channel (step 502). As described above, an offline channel is a channel not accessible via the Internet, such as utilizing the online user device's local visual display, sound or sound sequences generated by the online user device, or (e.g., via Bluetooth) short-range wireless transmission from the online user device. The offline user device receives the operation description from the online user device via the offline channel (step 503), and based on the information received therefrom, displays the operation description (or a portion thereof) and prompts the user for endorsement of the operation (step 504). If the offline device receives a valid endorsement as user input within a timeout period (step 505), the offline device sends an "Accept (ACCEPT)" message to the online user device via the same offline channel through which the operation description was received, or via a different offline channel (step 506). Then, the online user device receives the endorsement result from the offline device (step 507) and sends the result payload to the CCS via the Internet (step 509). If the offline user device does not receive a valid endorsement from the user within the timeout period (step 505), the offline user device sends a "REJECT" message to the online user device via the offline channel, and the online user device sends the "REJECT" payload to the CCS via the Internet (step 508).

[0050] Offline devices can be delivered to users in a state that is pre-registered in the organization with their security keys, or offline devices can be allowed to go online for initial registration processing, or offline devices can send their registration through the same process as authorization processing.

[0051] Periodic updates to the CCS software on offline devices may be required. To allow for such updates, offline devices can be scheduled to connect to the internet via Wi-Fi and update their software at a predefined pace, or the offline device may need to update its software as a result of receiving a transaction to be signed from an online user device (indicating that the software version on the offline device is no longer compatible). Whenever the device is online, it can record the fact that it can access the internet and attempt to send this fact to CCS 1 so that this information can be used by the platform to assess the risk at a later time.

[0052] In addition to remaining offline, offline user devices and one or more online devices can be restricted to taking action on transactions only within the range of predefined beacons. Wireless (e.g., Bluetooth) beacon devices can be made available to the user, and the CCS application can refuse to authorize transactions unless it detects that the beacon is available.

[0053] Auditability and proof of ownership

[0054] Each transaction submitted to CCS 1 is recorded in an internal ledger that is tamper-proof and allows auditors to have cryptographic evidence of every historical event in each user's account. Ownership of blockchain assets is controlled by possessing a private key corresponding to a public wallet address. CCS can prove ownership of these assets to an auditor by signing a randomly selected string of text chosen by the auditor using the private key corresponding to the user's vault. Consider the following example:

[0055] The auditor wanted to see evidence that CCS had access to funds in a wallet identified by the address “1BvBMSEYstn5Au4m4GFg7yJaNVN2”. Therefore, the auditor randomly generated a long string (e.g., “xGG8vQFnd8QDwHz6Uj1GX”) and submitted the following challenge:

[0056]

[0057] CCS 1 receives the challenge and forwards it as a predefined, templated serialized packet to HSM 5. HSM 5 is programmed to accept such audit requests (which are not arbitrary payloads, thus eliminating the risk of them being subsequently interpreted as signed blockchain transactions) and signs these requests with the private key associated with the specified address. CCS 1 then returns a valid signature for any challenge that an auditor can independently verify. This verification proves that CCS 1 controls the private key corresponding to the entry on the blockchain, thus providing proof of control over the asset.

[0058] Thresholding service

[0059] In some embodiments, CCS 1 includes a thresholding service that enables other parts of the system (Risk Analysis Phase 4 and HSM 5) to securely determine that user actions and transactions follow customer-specific business logic and have been approved by a human / automatic risk review system. The thresholding service can verify a specified number of multi-signature (multi-user) transactions to achieve this.

[0060] Thresholding service verifies user-initiated and approved operations to ensure they meet a threshold threshold before execution. Such operations can include transactions, adding or deleting other users, etc. Different users can have different access control roles (e.g., view-only, transaction-only, authorized, required). CCS 1 can notify each reportable condition of a specified number of accepted lifetimes, but cannot sign off on operations not authorized by the customer. All actions are logged in an append-only ledger for auditability across all accounts.

[0061] One function of the thresholding service is to verify that a specified number of authorized users have signed their consent to the requested action. Qualified actions that may require a specified number could include, for example, proposing a transaction (e.g., "withdraw 100 bitcoins"), adding a user to an account, changing a user's permissions, removing a user from an account, and modifying the thresholding logic. By default, the specified number can be defined as an absolute majority of users (e.g., 3 out of 5), or the specified number can be set to a custom specified number when a customer joins. Furthermore, authorized users can configure the specified number to require certain specific users to endorse the transaction to constitute the specified number. CCS 1 also allows thresholding across multiple desired groups. For example, in a company, it might be necessary to require the consent of a majority of the finance team and the front-line office.

[0062] In some embodiments, the thresholding service implements a fine-grained access control model in its specified number of verifications, where different users can have different access levels, which may include, for example:

[0063] -View Only

[0064] This is the default access level.

[0065] Users at this level can view all asset locations.

[0066] - Users at this level can tag any transaction.

[0067] Users at this level can freeze all assets.

[0068] -View-Authorization

[0069] - Users at this level can act as authorized voters towards a specified number of actions.

[0070] Users at this level can view the locations of all assets.

[0071] - Users at this level can tag any transaction.

[0072] Users at this level can freeze all assets.

[0073] -View-Authorize-Required

[0074] - Users at this level are the required voters for the action.

[0075] Users at this level can view the locations of all assets.

[0076] - Users at this level can tag any transaction.

[0077] Users at this level can freeze all assets.

[0078] In some embodiments, a user's access level may change only with the appropriate number of verification requirements verified through the thresholding service.

[0079] As described above, user approval of an action can be represented by a cryptographic digital signature to benefit from non-repudiation guarantees. The crypto asset custodian can verify that the associated user holding the private key is indeed the user who approved the action because the digital signature is unforgeable. In some embodiments, the user's signature is generated from the iOS secure designated address space in the user's mobile device and forwarded to CCS 1 by the iOS application programming interface (API) component in the user device 8. The cryptographic hash of the transaction content can be signed to ensure the transaction cannot be tampered with. It may be necessary for all users to sign the same hash with the same transaction identifier (ID) to ensure the signatures are counted in a prescribed number. The thresholding service can provide templates for client signing and can verify all completed signatures made by the iOS client. In at least some embodiments, the thresholding service verifies signatures using a public component of the user signing keys but does not hold the private component of these user signing keys.

[0080] Once the threshold is met, the thresholding service publishes the corresponding signature data to the risk analysis phase for further analysis before signing consent, and serializes the signature data into the payload to be consumed by the HSM signature service. Each additional signature provided to the thresholding service and for verification can be logged in an append-only log service. This provides additional auditing and status updates, in addition to the metadata captured in the thresholding service's storage, which is crucial for providing consumable updates to user clients.

[0081] Maintain the prescribed amount of activity

[0082] Assume a predetermined number of authorized members are available to cryptographically sign transactions. Therefore, this predetermined number should remain "active," meaning that at any given time, CCS 1 has a reasonable confidence that all potential members retain their security device keys and are actively participating in transactions. In some embodiments, CCS 1 may achieve this level of confidence by:

[0083] 1. Has the right to access the set of user public keys required to implement the policy.

[0084] 2. Set an activity threshold for the strategy, i.e., a time period after which the key is considered at risk of becoming unusable. This can be fixed or correlated with the normal trading rhythm.

[0085] 3. Require users to periodically sign proof transactions using their private keys. This can be explicit as an activity check, or implicit / hidden through regular operations requiring their keys, such as login.

[0086] 4. Record the latest activity time of the keys of any one or more users.

[0087] 5. Continuously monitor whether any user's activity time exceeds the activity threshold.

[0088] 6. Use the above information to prompt users to prove that these users still have the right to access their signing keys and / or to notify other users of the specified amount of potential risks.

[0089] Risk analysis phase

[0090] Phase 4 of the risk analysis can implement an API known as the Risk API, and may also include human review of all transactions and management user actions. In some embodiments, the Risk API drives a human review system. The Risk API can provide integration with internal risk dashboards for crypto asset custodian staff to manually review individual transactions.

[0091] In some embodiments, all transactions are manually approved by designated employees; all administrative user actions (addition, deletion, permission changes) are manually approved by designated crypto asset custodian employees; reviewable entities must pass automated verification processes before risk analysis is required; reviewable entities must provide robust context related to user approvals for manual review and further automated review; and risk approvals and rejections are logged in an append-only ledger for auditing purposes.

[0092] The Risk API re-verifies the appropriate threshold determined by the thresholding service. The Risk API can also handle additional business logic, such as in a simplified embodiment where the thresholding service is used: for example, if the thresholding service only checks a specified number, the Risk API can check the required signers. Other functionalities described herein can also be moved between modules.

[0093] The risk API can receive contextual data related to the users involved in a transaction to present to people and / or classification systems. This information may include, for example, the user who approved the transaction, the time of approval, the location of approval, and the device / key ID that approved the transaction. This data can be fed into an internal risk analysis dashboard and, possibly, into other automated review systems.

[0094] In some embodiments, if a transaction passes both manual and automated risk reviews, the Risk API requires human approval from one or more employees of the crypto asset custodian. For approval, an employee may be required to sign with a cryptographic key upon approving the transaction / operation, and the signature is presented to the Risk API for verification. Furthermore, it is preferable to have multiple keys (one for each risk reviewer) to log the individuals who have performed the reviews. Preferably, as a compromise, the risk approval key is easily transferable.

[0095] Figure 6 This illustrates a high-level example of a hardware architecture that can be used to implement a portion or all of a CCS, or (alone) any user device, or both, of a processing system. A CCS may include, for example... Figure 6 One or more instances of the architecture shown, wherein multiple such instances may be coupled to each other via one or more private networks.

[0096] The illustrated processing system 600 includes one or more processors including a CPU 610, one or more memories 611 (at least a portion of which may be used as working memory, such as random access memory (RAM)), one or more data communication devices 612, one or more input / output (I / O) devices 613, and one or more mass storage devices 614, all of which are coupled to each other via interconnects 615. The interconnects 615 may be or include one or more conductive traces, buses, point-to-point connections, controllers, adapters, and / or other conventional connection devices. Each processor 610 controls part of the operation of the processing device 600 and may be or include, for example, one or more general-purpose programmable microprocessors, digital signal processors (DSPs), mobile application processors, microcontrollers, application-specific integrated circuits (ASICs), or programmable gate arrays (PGAs), or combinations of such devices.

[0097] Each memory 611 may be or include one or more physical storage devices, which may take the form of RAM, read-only memory (ROM) (which may be erasable and programmable), flash memory, small hard disk drive or other suitable types of storage devices, or combinations of such devices. Each large-capacity storage device 614 may be or include one or more hard disks, digital versatile discs (DVDs), or flash memory, etc. Each memory 611 and / or large-capacity storage device 614 may (individually or collectively) store data and instructions that configure the processor 610 to perform operations to implement the above-described technologies. Each communication device 612 may be or include, for example, an Ethernet adapter, a cable modem, a Wi-Fi adapter, a cellular transceiver, a baseband processor, or a Bluetooth or Bluetooth Low Energy (BLE) transceiver, etc., or combinations thereof. Depending on the specific nature and purpose of the processing system 600, each I / O device 613 may be or include devices such as a display (which may include a transparent AR display surface), audio speakers, a keyboard, a mouse or other pointing device, a microphone, a camera, etc. However, note that if the processing device 600 is only embodied as a server computer, such an I / O device may not be necessary.

[0098] In the case of a user device, the communication device 612 may be or include, for example, a cellular telecom transceiver (e.g., 3G, LTE / 4G, 5G), a Wi-Fi transceiver, a baseband processor, or a Bluetooth or BLE transceiver, or a combination thereof. In the case of a server, the communication device 612 may be or include, for example, any one of the communication devices of the types described above, a wired Ethernet adapter, a cable modem, or a DSL modem, or a combination of such devices.

[0099] Unless contrary to physical possibilities, it is contemplated that: (i) the methods / steps described herein can be performed in any order and / or in any combination; and (ii) the components of the various embodiments can be combined in any way.

[0100] The operations implemented by the aforementioned machine can be achieved through programmable circuitry programmed / configured by software and / or firmware, or entirely through dedicated (“hardwired”) circuitry, or a combination of these forms. Such dedicated circuitry (if available) can take the form of, for example, one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), system-on-a-chip (SoCs), etc.

[0101] The software or firmware used to implement the techniques described herein can be stored on a machine-readable storage medium and can be executed by one or more general-purpose or special-purpose programmable microprocessors. As used herein, "machine-readable medium" includes any entity that can store information in a machine-accessible form, such as a computer, network device, cellular phone, personal digital assistant (PDA), manufacturing tool, any device having one or more processors, etc. For example, machine-accessible media include recordable / non-recordable media (e.g., RAM or ROM; disk storage media; optical storage media; flash memory devices; etc.).

[0102] As used herein, the term "logic" means: i) dedicated hardwired circuitry, such as one or more application-specific integrated circuits (ASICs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), or other similar devices; ii) programmable circuitry programmed with software and / or firmware, such as one or more programmed general-purpose microprocessors, digital signal processors (DSPs) and / or microcontrollers, systems-on-a-chip (SoCs), or other similar devices; or iii) a combination of the forms described in i) and ii).

[0103] As will be apparent to those skilled in the art, any or all of the features and functions described above can be combined with each other, except to the extent otherwise stated above, or to the extent that any such embodiments may be incompatible by virtue of their functionality or structure. Unless contrary to physical possibility, it is contemplated that: i) the methods / steps described herein can be performed in any order and / or in any combination; and (ii) the components of the various embodiments can be combined in any manner.

[0104] Although the subject matter has been described in language specific to structural features and / or behavior, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or behaviors described above. Rather, the specific features and behaviors described above are disclosed as examples of implementing the claims, and other equivalent features and behaviors are also intended to be within the scope of the claims.

Claims

1. A method for authorizing an action, the method comprising: Receive action requests at the server system for actions associated with the organization's crypto assets. The hardware security module uses a policy graph generated for the organization to determine the policy for the requested action stored in the hardware security module. The policy graph specifies a policy for each possible action involving the cryptographic asset. The hardware security module generates a unique key for each new organization joined using the requested set of users already in the new organization. The hardware security module uses the stored policy to determine the number of authorizations that must be received for the requested action. The server system receives multiple cryptographic authorization endorsement messages from multiple user devices, each of the multiple cryptographic authorization endorsement messages being associated with a different user among the multiple users; The hardware security module is used to determine whether the endorsement messages of the multiple encrypted authorizations have been authenticated by the authorizing party based on the stored policies associated with the encrypted assets. The hardware security module uses a comparison of the number of endorsement messages for the plurality of encrypted authorizations to the number of authorizations that must be received according to the stored policy to determine whether a policy-defined number of users among the plurality of users have approved the requested action; and Only after the licensor has authenticated the endorsement messages based on the multiple encrypted authorizations using the hardware security module and the policy-based number of users have approved the requested action according to the stored policy, and the action is deemed to have been validly endorsed, is the action approved by signing the approval message of the action with an encryption key stored only in the hardware security module using the hardware security module, wherein the hardware security module does not permit any entity outside the hardware security module to read the encryption key.

2. The method according to claim 1, wherein, For each of the plurality of users, the private key of the public-private key pair for that user is stored in the secure storage device of the mobile device associated with that user.

3. The method according to claim 1, wherein, The requested action includes the requested transaction involving the crypto asset.

4. The method according to claim 1, further comprising: In response to the approval of the transaction, the transaction is sent to the blockchain network.

5. The method according to claim 1, wherein, The requested action includes the requested transaction involving the crypto asset, wherein the cryptographic key is the private key in a public-private key pair associated with the crypto asset, and the method further includes: using the hardware security module to generate the cryptographic key.

6. The method according to claim 1, further comprising: This enables the endorsement request message to be sent to each of the multiple user devices, and each endorsement request message is configured to prompt the receiving user device to endorse the requested action.

7. The method according to claim 6, further comprising: For at least two of the user devices, the server system verifies that the user devices have authenticated the corresponding user in connection with the endorsement of the requested action using biometric authentication technology.

8. A method for authorizing transactions involving crypto assets, the method comprising: Receive transaction requests at the server system for transactions involving the requested crypto assets of the organization. The hardware security module uses a policy graph generated for the organization to determine the policy for the requested transaction stored in the hardware security module. The policy graph specifies a policy for each possible action involving the cryptographic asset. The hardware security module generates a unique key for each new organization to join using the requested set of users already in the new organization. The hardware security module uses the stored policy to determine the number of authorizations that must be received for the requested transaction. At the server system, multiple endorsement messages are received from multiple user devices, each of the multiple endorsement messages being associated with a different user among the multiple users; The hardware security module is used to determine whether the received multiple endorsement messages have been authenticated by the authorized party based on the stored policy associated with the encrypted asset. The hardware security module uses a comparison of the number of endorsement messages it assigns to the plurality of endorsement messages with the number of authorizations that must be received to satisfy a specified number as defined in a stored policy associated with the cryptographic asset, to determine whether the plurality of endorsement messages and the authorizing party associated with the plurality of endorsement messages satisfy the policy-based quantity required to approve the requested transaction; and The requested transaction is authorized only after the hardware security module determines that a valid endorsement of the requested transaction has been made based on the multiple endorsement messages authenticated by the authorizing party and the determination that a specified number of users have approved the requested action according to the stored policy. The authorization of the requested transaction is then authorized by signing the approval of the requested transaction with the private key associated with the encrypted asset using the hardware security module.

9. The method according to claim 8, further comprising: For at least one of the plurality of user devices, the server system verifies that the user device has authenticated the corresponding user in relation to the authorization of the requested transaction through a first biometric authentication technology.

10. The method of claim 9, further comprising: A second biometric authentication technology is used at the server system to authenticate at least one of the users in relation to the authorization of the requested action.

11. The method of claim 8, further comprising: The server system uses authentication technology to authenticate the user in relation to the authorization of the requested transaction, the authentication technology including: The user's device outputs a prompt to the user, so as to record and upload the video of the user performing the specified action or saying the specified content to the server system. The server system receives the video uploaded in response to the prompt; and The user is authenticated by analyzing the video at the server system by performing at least one of the following operations: Verify the user's biometrics from the video; or Verify that the user performed the specified action or said the specified content in the video.

12. The method according to claim 8, further comprising: This causes at least one of the users' user devices to output a deterministic authentication challenge to the corresponding user, wherein the content of the deterministic authentication challenge is based on the context of the requested transaction.

13. The method of claim 8, further comprising: In response to the transaction request, the risk analysis of the requested transaction is invoked. Specifically, the authorization of the transaction is made only if the results of the risk analysis indicate that the risk level associated with the requested transaction meets the risk criteria, and the plurality of endorsement messages meet the prescribed quantity.

14. The method of claim 8, further comprising: The hardware security module is used to generate a private key associated with the encrypted asset.

15. The method of claim 8, further comprising: The hardware security module is used to generate a private key associated with the crypto asset as part of a public-private key pair associated with the crypto asset.

16. The method of claim 15, further comprising: The private key associated with the cryptographic asset is stored within the hardware security module, wherein the private key associated with the cryptographic asset cannot be read by any entity outside the hardware security module or sent to any entity outside the hardware security module.

17. The method of claim 8, further comprising: The public key of each of the plurality of user devices is stored in the hardware security module.

18. The method according to claim 17, wherein, Each authorization is signed by the corresponding user device using the private key from the public-private key pair associated with the corresponding user device.

19. The method of claim 17, further comprising: Before authorizing the requested transaction, a data packet is provided to the hardware security module, the data packet including data representing the specified quantity and a public key associated with each of the plurality of user devices.

20. The method according to claim 8, wherein, The hardware security module is not directly connected to any public computer network.

21. The method according to claim 8, wherein, The private key associated with the crypto asset is stored in the hardware security module. The private key is part of the public-private key pair associated with the crypto asset.

22. The method of claim 8, further comprising: The server system is used to send authorization request messages to each of the plurality of user devices, and each authorization request message is configured to prompt the receiving user device to prompt the corresponding user to authorize the requested transaction.

23. The method according to claim 8, further comprising: The policy associated with the crypto asset is stored, and the policy defines the specified number of users required to authorize the transaction.

24. The method according to claim 8, wherein, Determining whether the plurality of endorsement messages meet the specified number defined in the stored policy associated with the cryptographic asset is done by verifying the respective endorsement messages using the public key associated with each authorized user device that sent them.

25. The method according to claim 8, wherein, The multiple endorsement messages are generated by signing the user device using a private key stored in the user device's secure storage device.

26. The method of claim 8, further comprising: A data packet, including data specifying the number of policies contained therein and a public key associated with each of the plurality of user devices, is sent to the hardware security module.

27. A method for authorizing a transaction, the method comprising: The server computer system receives transaction requests from user devices via a public computer network for transactions relating to the organization's crypto assets. In response to the transaction request, the risk analysis of the requested transaction is invoked; The hardware security module uses the organization's policy graph to determine the stored policies associated with the crypto asset. The policy graph specifies a policy for each possible action involving the crypto asset. The policy specifies a prescribed number of users required to authorize the transaction. The hardware security module generates a unique key for each new organization joined using a requested set of users already in the new organization. The hardware security module uses the policy to determine the number of authorizations that must be received for the requested transaction. The server computer system is used to send authorization request messages to each of a plurality of mobile devices, each of which is associated with a different user among the plurality of users, and each authorization request message is configured to prompt the receiving mobile device to authorize the corresponding user for the requested transaction. At the server computer system, multiple authorizations are received from the plurality of mobile devices, each authorization indicating that the user has authorized the requested transaction using the corresponding mobile device in the mobile device, and each authorization is signed by the corresponding mobile device using the private key stored in the secure storage device in the corresponding mobile device; The hardware security module is used to check whether the received multiple authorizations have been authenticated by one or more authorized parties according to the stored policies associated with the encrypted asset; The hardware security module, which is not directly connected to any public computer network, stores a private key associated with the cryptographic asset, which is part of a public-private key pair associated with the cryptographic asset. Using the hardware security module, the corresponding authorization is verified by using the public key associated with each authorized mobile device. The hardware security module compares the number of valid authorizations received from two or more of the mobile devices with the number of authorizations that must be received to satisfy the specified number in the policy to determine whether a valid authorization has been received from two or more of the multiple mobile devices. The transaction is authorized only if the risk analysis determines that the level of risk associated with the requested transaction is below a threshold, and valid authorization for the requested transaction is received from each of the two or more mobile devices to meet the specified number according to the stored policy, by using the hardware security module to sign the approval of the requested transaction with the private key associated with the encrypted asset.

28. A digital asset custody system, comprising: An online server subsystem is configured to receive, via a public computer network, a requested transaction relating to an organization’s digital assets from a user, and in response to receiving the requested transaction, to cause an authorization request to be sent to a plurality of mobile devices according to a stored policy, each of the plurality of mobile devices being associated with at least one of a plurality of users who are specified in the policy as a number of possible members for approving the transaction, and the online server subsystem is further configured to receive a plurality of authorization messages from the respective mobile devices of the plurality of users; as well as The hardware security module is configured as follows: Generate a unique key for each new organization to join using the requested set of users already in the new organization; The strategy for the requested transaction is determined using a policy graph of the organization stored in the hardware security module, the policy graph specifying a strategy for each possible action involving the digital asset. The strategy determines the number of authorizations that must be received for the requested transaction. Receive the authorization instruction from the mobile devices of two or more of the plurality of users; The hardware security module determines whether two or more users have received valid authorizations by comparing the number of valid authorizations received from two or more users with the number of authorizations that must be received based on the public keys associated with each of the multiple users who have received authorizations to meet the number specified in the stored policy. It then checks whether the number of valid authorizations received has been authenticated by the authorizing party according to the policy, and authorizes the transaction by signing the approval of the requested transaction with the private key associated with the digital asset only if valid authorizations for the requested transaction have been received from each of the two or more users to meet the number specified in the stored policy.

29. The digital asset custody system according to claim 28 further includes a relay server, the relay server being used to isolate the security module from the Internet.

30. The digital asset custody system according to claim 28 further includes a risk analysis module, the risk analysis module being used to assign a risk score to the requested transaction.

31. The digital asset custody system according to claim 28, wherein the online server subsystem is further configured to send an authorization request message to each of the plurality of mobile devices, and each authorization request message is configured to prompt the receiving mobile device to authorize the requested transaction.

32. The digital asset custody system according to claim 28, wherein, The hardware security module is also configured to: Generate a private key associated with the digital asset as part of the public-private key pair associated with the digital asset; The public key of the public-private key pair associated with the digital asset is provided to a computer system outside the hardware security module; as well as The private key of the public-private key pair associated with the digital asset is maintained in a storage device within the hardware security module, and the private key of the public-private key pair associated with the digital asset is prevented from being read by any entity outside the hardware security module.

33. The digital asset custody system of claim 28, wherein the digital asset custody system is configured to verify, for at least one user device, that the user device has authenticated the corresponding user in connection with the authorization of the requested transaction via a first biometric authentication technology.

34. The digital asset custody system of claim 33, further configured to use a second biometric authentication technology to authenticate at least one of the users in relation to authorization of the requested action.

35. The digital asset custody system of claim 28, wherein the digital asset custody system is configured to authenticate the user in connection with the authorization of the requested transaction by: This causes the user's device to output a prompt to the user, so as to record and upload the video of the user performing the specified action or saying the specified content to the server system. Receive the video uploaded in response to the prompt; and The user is authenticated by analyzing the video by performing at least one of the following operations: Verify the user's biometrics from the video; or Verify that the user performed the specified action or said the specified content in the video.

36. The digital asset custody system of claim 28, wherein the digital asset custody system is configured such that a user device of at least one of the users outputs a deterministic authentication challenge to the respective user, wherein the content of the deterministic authentication challenge is based on the context of the requested transaction.

37. A hardware security module, comprising: Non-volatile storage devices used to store encrypted data; A communication interface, through which communication is made with the host computer system; as well as A logic circuit, coupled to the non-volatile memory device and the communication interface, is configured to cause the hardware security module to perform the following steps: Generate a unique key for each new organization to join using the requested set of users already in the new organization; Instructions for depositing digital assets from the receiving organization are processed from the caller. In response to the instruction, Generate a public-private key pair associated with the digital asset. Provide the public key from the public-private key pair to the call handler, and The private key in the public-private key pair is stored in a protected manner in the non-volatile storage device; The system receives instructions on the requested operation relating to the digital asset, instructions on the specified number of users who need to authorize the requested operation to authorize the requested transaction, and public keys associated with each of the multiple users who appear to have authorized the requested operation. The organization's policy graph is used to determine the policy protected by the hardware security module for the requested operation, the policy graph specifying a separate policy for each possible operation involving the digital asset. Based on the aforementioned strategy, determine how much authorization is required for the requested operation; Based on a comparison of the number of valid authorizations received from the plurality of users with an indication based on the specified number and the number of valid authorizations that must be received to satisfy the specified number by the public keys associated with each of one or more users who have ostensibly authorized the requested operation; it is determined whether two or more users have received valid authorizations. According to the stated strategy, check whether the received authorization has been authenticated by the authorizing party, and After determining that valid authorizations have been received from two or more users to meet the specified number, the requested operation is authorized by signing the approval of the requested operation with the private key from the public-private key pair associated with the digital asset.

38. The hardware security module according to claim 37, wherein, Prevent the private key in the public-private key pair associated with the digital asset from being read by any entity outside the hardware security module.

39. The hardware security module according to claim 37, further comprising: The operation is sent to the blockchain network only after the approval of the transaction has been signed.

Images