Risk Framework for Bitcoin Custody Operation with the Revault Protocol
RRisk Framework for Bitcoin Custody Operationwith the Revault Protocol
Jacob Swambo , and Antoine Poinsot King’s College London, Department of Informatics WizardSardine
Abstract.
Our contributions with this paper are twofold. First, we elu-cidate the methodological requirements for a risk framework of custodialoperations and argue for the value of this type of risk model as comple-mentary with cryptographic and blockchain security models. Second, wepresent a risk model in the form of a library of attack-trees for Revault– an open-source custody protocol. The model can be used by organisa-tions as a risk quantification framework for a thorough security analysisin their specific deployment context. Our work exemplifies an approachthat can be used independent of which custody protocol is being consid-ered, including complex protocols with multiple stakeholders and activedefence infrastructure.
While mainstream acceptance of Bitcoin as an asset appears to be increasing,advanced tools and methods for secure custody of bitcoins are slow to develop.Bitcoin custody encompasses the protection of assets through software, hard-ware, and operational processes. The foundation of Bitcoin custody is key-management, a well understood topic in the academic literature and in prac-tice. However, Bitcoin custody, in particular multi-stakeholder custody, involveshuman processes, communication protocols, network monitoring and responsesystems, software, hardware and physical security environments. Given a securecryptographic layer, there are still vulnerabilities introduced at the applicationlayer by software developers, at the hardware layer throughout the supply chain,and at the operations layer by users. Without adequate risk management frame-works for custodial operations, Bitcoin users are likely to suffer unexpected losseswhether they self-custody funds or employ a third-party custodian.Open-source custody protocols are emerging [25,5,38,39] and are a criticalecosystem component for improving security standards. If a custody protocolstands to public scrutiny and offers a high-level of security without relying onproprietary processes, users, insurance companies and regulators can have moreconfidence in it. The emerging custody protocols are trying to reconcile theneeds of traditional businesses and banking with Bitcoin’s novel identity-less andirreversible transaction properties. A lack of available and accepted open-sourcecustody protocols means that organisations are heavily relying on third-partycustodians, or deploying their own custody protocol. a r X i v : . [ c s . C Y ] F e b J. Swambo & A. Poinsot
We propose an attack modelling technique as the basis for a risk frameworkfor Bitcoin custody operations, using the Revault protocol as a case-study [4,25].While the process of model construction is intensive, the resultant framework isextensible and modular and some of its components can be re-used with differ-ent custody protocols. It is intended to be readily comprehensible, and, givensufficient validation, the framework can be used by any organisation intendingto deploy Revault to better understand their risk posture.Risk quantification frameworks address several ecosystem problems. Organ-isations that control bitcoins or other digital assets need accurate models toengage in realistic risk-management. The complexity of custodial risks leavesinsurance companies guessing rather than systematically estimating when pric-ing their insurance offerings or assessing particular solutions for digital custody.Finally, emerging regulatory standards for custody [9,26] are simple and fail tocapture advanced custody architectures or enable context-specific risk analysesthat acknowledge the full security environment of a custody operation.The remainder of this paper is structured as follows. Section 2 summarises thecomponents and processes of the Revault protocol. Section 3 discusses our eval-uation criteria for an operational risk framework, and introduces the attack-treeformalism on which our risk model is based. Section 4 presents our operationalrisk model for Revault. Section 5 concludes this paper. Revault is a multi-party custody protocol that distinguishes between stakehold-ers and fund managers . The primary protection for funds is a high-thresholdmulti-signature Script controlled by the stakeholders. The day-to-day opera-tional overhead of fund management is simplified by enabling portions of fundsto be delegated to fund managers. Stakeholders define spending policies in-linewith traditional controls of expenses, and have automated servers to enforce theirpolicies. In addition, a deterrent is withheld by each stakeholder to mitigate in-centives to physically threaten the stakeholders. To achieve this, Revault makesuse of sets of pre-signed transactions coupled with an active defence mechanismfor detecting and responding to attempted theft transactions. In the following,we will outline the components of the Revault architecture, the transaction set,the stakeholders’ routine signing process and the managers’ spend process. Referto [4] for the detailed specification of the open-source protocol.
Each stakeholder and manager has a hardware module (HM) to manage theirprivate keys and generate signatures for transactions. A backup of private keysis stored for each HM in a separate protected physical environment. Specifically, the version identified as 609b40dda07155abe5cd4a5af77fc2211d11fbc1which can be found on the open-source repository hosted on Github [4].isk Framework for Bitcoin Custody Operation with the Revault Protocol 3
Fig. 1.
Diagram of the transaction (Tx) set structure in the Revault protocol. AnUnspent-transaction-output (UTxO) is created by a preceding Tx and is consumed byan input in a proceeding Tx.
Each stakeholder and manager uses a wallet software to track their co-ownedbitcoins, craft transactions, store transaction signatures and communicate witheach other through a coordinator . The coordinator is a proxy server that sim-plifies communication for the multi-party wallet. All communication uses NoiseKK encrypted and authenticated channels [33].Stakeholders each have one or more watchtower , an online server that enforcesthe stakeholder’s spending policy limitations. Stakeholders each have an anti-replay oracle server.
The use of hierarchical deterministic wallets means that each participant in theRevault protocol has a tree of public and private keys [41]. To discuss owner-ship of bitcoins, we refer to a generalisation of a locking Script, called a de-scriptor . The wallet will have multiple addresses that correspond to a singleabstracted descriptor. Funds are deposited into the multi-party wallet througha Deposit transaction (Tx) output that pays to the deposit descriptor, describ-ing N − signatories locking Scripts derived from the stakeholders ( stk ) extendedpublic keys ( xpub ). In descriptors language formalisation [2] it is defined as: thresh(N, stk_1_xpub, stk_2_xpub, ..., stk_N_xpub) The set of transactions prepared with stakeholders’ wallets and signed usingtheir hardware modules (HM) include the Emergency Tx, Unvault Tx, Unvault-Emergency Tx and Cancel Tx. The managers can only prepare and sign aSpend Tx type. Figure 1 depicts these transactions and the essential unspent-transaction-outputs (UTxOs) they create or consume.
J. Swambo & A. Poinsot
An Emergency Tx locks funds to an emergency descriptor which is unspec-ified by the Revault protocol and is kept private among stakeholders. The de-scriptor must however be harder to unlock than the deposit descriptor. This isthe deterrent for physical threats to the stakeholders.An Unvault Tx consumes the deposit UTxO and creates an unvault UTxOlocked to the unvault descriptor, or( thresh(N, stk_1_xpub, stk_2_xpub, ..., stk_N_xpub),and( thresh(K, man_1_xpub, ..., man_M_xpub),and( thresh(N, oracle_1_xpub, ..., oracle_N_xpub),older(X) ) ) ), that is redeemable by either the N stakeholders or the M managers ( man ) alongwith N automated anti-replay oracles after X blocks.A Cancel Tx consumes the unvault UTxO and creates a new deposit UTxO.The watchtowers’ role is to broadcast the Cancel Tx if a fraudulent spend at-tempt is detected (either through an unauthorised attempt at broadcasting anUnvault Tx or if a Spend Tx does not abide by the spending policy). The time-lock gives watchtowers X blocks worth of time to broadcast a Cancel Tx. AnUnvault-Emergency Tx consumes the unvault UTxO and locks funds to theemergency descriptor. It has the same purpose as the Emergency Tx, only itconsumes the unvault UTxO rather than the deposit UTxO. A Spend Tx isused by managers to pay to external addresses. Stakeholders’ wallets routinely check for new deposits and each one triggersa signing routine. Figure 2 shows the connections and message types for anexample Revault deployment enacting the signing routine. The wallet crafts anEmergency Tx and requests the stakeholder to sign it using their HM. Thestakeholder will verify the emergency descriptor on the HM before authorisingthe signature generation . The wallet then connects to the coordinator to pushits signature and will fetch other stakeholders’ signatures.Optionally, stakeholders may also sign the Cancel, Unvault-Emergency, andUnvault Txs to securely delegate funds to the managers. In this case the signingprocess is the same but is carried out in two steps: first, the signatures for theCancel and Unvault-Emergency Txs are exchanged with the other stakeholdersthrough the coordinator and then shared with the watchtower(s), and only thenare the Unvault Tx signatures shared with managers. Most spending policies cannot be inferred from the Unvault Tx alone and sothe Spend Tx must be known to the watchtower to validate an unvaulting at-tempt. In these cases the Spend Tx must be advertised to the watchtowers before This feature is not available with current HMs, but integrating compatibility with de-scriptors (along with other security features) would improve the human-verificationcomponent of HM security and is being discussed on the bitcoin-dev mailing list [24].isk Framework for Bitcoin Custody Operation with the Revault Protocol 5
Fig. 2.
Data flow diagram for the communication of the stakeholders’ signing routine with an example Revault deployment. There are three stakeholders (S) who each haveone or two watchtowers (WT). There are two managers (M) and a coordinator. Signa-ture messages, signature requests and watchtower acknowledgements (ACK) are onlyshown once per connection type but apply to each connection of that type (e.g. thereis {← signature, → ACK } between each WT and S). unvaulting, otherwise it will be cancelled. The anti-replay oracle is required toavoid the Spend Tx being modified by the managers after the unvault time-lockexpires and thus by-passing enforcement of the watchtowers’ spending policies.Any manager can initiate a spend. Figure 3 depicts the spend process . Theinitiator creates a Spend Tx, verifies and signs it using their HM and passesit back to the wallet in the partially-signed Bitcoin Tx (PSBT) format [10].It’s exchanged with a sufficient threshold of the other managers to add theirsignatures and hand it back to the initiator. The initiator requests a signaturefrom each of the anti-replay oracles and pushes the fully-signed Spend Tx tothe coordinator. The initiator broadcasts the Unvault Tx, triggering a lookupfrom the watchtowers to the coordinator for the Spend Tx. If the Spend Tx isvalid according to all of the watchtowers policies and none of them cancel thisunvaulting attempt, the manager waits X blocks and broadcasts the Spend Tx.If, during the unvaulting process, there’s a significant increase in the fee-level required for a Spend Tx to be mined, a manager needs to bump the fee.Managers use a dedicated single-party fee wallet for this. Similarly, watchtowersuse a fee wallet in the case there is high demand for block space to bump thefee for Cancel or emergency Txs. J. Swambo & A. Poinsot
Fig. 3.
Data flow diagram for the communication of the managers’ spend process. Inthis example there are two managers (M), three anti-replay oracles (O), five watch-towers (WT) and a coordinator. A Partially-signed Bitcoin Tx (PSBT) is exchangedamong managers and between a manager and the anti-replay oracles. A fully signedSpendTx is shared with the WTs through the coordinator.
To see where this research fits in to the big picture, consider the key life-cycleof a custodial operation. There are three phases; initialization, operation, andtermination. Initialization is where wallet and communication keys are gener-ated, where software integrity is verified, hardware security modules are checked,and relevant public information is shared among participants. Operation encom-passes the active fund management. Termination is the phase wherein the walletis de-commissioned and all sensitive information destroyed. Initialization andtermination are out of scope for this paper. Our risk model covers the oper-ations phase. In the following we present our rationale for our chosen attackmodeling formalism and explain how this can be used as a risk framework.
A framework for high-level risk analyses for the integration of custody into amulti-stakeholder context has not yet been presented. To-date the literature hasfocused primarily on cryptographic security modeling, dealing with low-levelrisks associated with cryptographic primitives, key-management protocols, HMsand single-party wallets. The underlying cryptographic security is fundamentalbut should be complemented by an operational security model, which is much isk Framework for Bitcoin Custody Operation with the Revault Protocol 7 more likely to be the domain where participants create vulnerabilities for anattacker. Advanced custody protocols that use multi-layer access control withboth static and active defences for insider and external attackers demand awhole-system approach to security analysis.We present now several requirements for our modelling formalism: a) theability to represent complex processes with numerous components and sequentialevents; b) supports qualitative risk analysis; c) supports automated quantitativemethods for multi-attribute risk analysis; d) readily comprehensible and visualmodels that are more amenable to open-source intelligence; and e) extensibleand modular models to support differential analysis and re-use of modules.The two most popular attack modeling techniques in cyber-security literatureare attack-trees and attack graphs [23]. In short, tools for attack graphs tendto produce graphs that aren’t readily comprehensible due to the complexity ofreal-world attack scenarios [14]. That is, attack graphs don’t scale well [35]. Onthe other hand, attack-trees seem to meet all of our requirements, at least whenconsidered with the right structure and semantics (as described in section 3.2)and thus we construct our risk model using this formalism.While a statement such as ‘our custody solution is based on an m − of − n security model’ can entail a lot for simple multi-signature custody protocols, itdoesn’t capture the reality nearly as well as our proposed methodology would.It is certainly not sufficient for a more complex custody protocol like Revault.What is the physical environment for those n private keys? Are any of those keysonline? Are there key backups and, if so, what protections are in place for these?Too much depends on the broader security environment of a custody protocolfor it to be left without scrutiny.Application threat modelling has been used to harden the Revault proto-col throughout both its theoretical development and implementation. For eachapplication process (spend, routine signing, emergency, revault) a component-by-component and connection-by-connection analysis has been carried out to deter-mine the consequences of outages, data tampering, component corruption, etc.,and has resulted in the design specification [4] and the transaction flow threatmodel [25]. The application threat modeling approach is complementary andhas informed us in enumerating the risks presented with the attack-trees. How-ever, in contrast to attack-trees, it lacks a semantic structure which is amenablefor automated risk quantification and thus isn’t suitable as the basis of a riskframework. The risk model is presented using the formalism of attack-trees [36,40,6]. Attack-trees have an attack at their root, and branches that capture alternate (OR) andcomplementary (AND) attack pathways comprised of intermediate attack goalsas non-leaf nodes and basic attack steps as leaf nodes. As in numerous otherworks [11,18,22,28,27,29], we extend the basic attack-tree to support sequentialconjunction of branches (SAND) allowing us to model an attack where somesub-tree of an attack pathway has to occur before and in addition to another
J. Swambo & A. Poinsot sub-tree. For brevity we depict our attack-trees as nested lists. The logical gates(OR, AND, SAND) shown with each node apply to the next node at the samedepth. This means that at any given depth, a node with a SAND gate occurs before other nodes that are shown below it. Some aspects of the system arebuilt to be resilient to attack and failure through redundancy. For example, anattacker needs to compromise all stakeholders’ private keys to steal funds lockedto the deposit descriptor. To be concise, rather than having several copies of thesame sub-tree we write ( X times) to note that the sub-tree has to happen X times. During an analysis, these sub-trees should be considered as X separateAND sub-trees, since they are contextually different (corresponding to differentparticipants, remote and physical environments).We provide a set of attack-trees, capturing prominent risks that have beenenumerated primarily by considering tangible and intangible assets. Tangibleassets (bitcoins) are distinguished by the access control structures determinedby the set of descriptors. We consider operational privacy and business continuityas intangible assets.Our work here is focused on security, rather than safety. In principle, the samemethodology could be extended to an integrated security-safety model by con-structing attack-fault-trees [22]. Another common extension to the attack-treeformalism is to include countermeasures, producing attack-defence-trees [19,16].The benefit of our modular modelling technique is that it enables future work tointegrate these extensions and re-use results from this work. Hence, we prioritiseconstructing a strong foundation based only on attacks, and aim to incrementallyimprove on the model presented as new intelligence emerges. Our purpose in constructing the risk model presented in section 4 is to pro-vide a framework to support both qualitative and quantitative risk analyses forspecific deployment instances of Revault custody. By determining costs, like-lihoods, and other attributes for risks associated with custodial processes, anorganisation can perform a differential analysis of countermeasures until theirrisk-tolerance is satisfied. An explicit framework not only helps an organisationdeploying Revault with risk-management but could form a standard by whichinsurance companies and regulators consider specific deployments. As with anymodel of complex reality, attack-trees are imperfect and cannot capture everypossible attack pathway, but the alternative—complete ignorance—is not better.To perform a context-specific risk analysis, a set of estimates are made (us-ing in-house empirical data, public research, and expert opinion) for each basicattack step on different attributes such as monetary cost, execution time, orlikelihood. With that, a bottom-up procedure (from leaf nodes to the root) isused to compute aggregated attributes. Bayesian methods can be used to updateprior estimates with more refined values as new data sources emerge. The processfor generating estimates is critical and should be considered with care. In-depthresearch-based practical guidance on this topic is given by D. W. Hubbard andR. Seiersen in [17]. Given specific contextual information, estimations can be isk Framework for Bitcoin Custody Operation with the Revault Protocol 9 improved by further decomposing basic attack steps (e.g. ‘steal keys backup’)into multiple steps (e.g. ‘bribe manager to determine backup location’ SAND‘break into safe’). If a basic attack step has a highly uncertain estimate, thenfurther decomposition into more explicit steps can be beneficial. On the otherhand, decomposing into quantities that are more speculative than the first couldcompound uncertainty rather than reducing it.Various methods for analysis can be used to compute aggregated attributesfor attack-trees. Kordy et al. gave an overview [20]. Our purpose here is toprovide the framework on which to perform analyses rather than to provide aspecific analysis. We have not performed a comprehensive evaluation of anal-ysis methods, but offer some suggestions based on a comparison in [21]. Twomethods that support evaluating the attributes of cost, probability, and timeare stochastic-model checking [22] and game-theoretic analysis [16]. Whichevermethods are used must appropriately capture the constraints of our model (in-cluding SAND gates) and should be automated to enable rapid attribute-basedqueries for security metrics such as; the expected attack pay-off for the mostlikely attack, or the possible attack pathways given a budget of $ We have constructed the risk model with several assumptions that limit the scopeof the analysis to the operational aspects of custody. Known risks from otherprotocol and environment dependencies that are discussed in other works shouldbe considered as complementary but are, for the purpose of clarity, assumed tobe benign here. First, we assume that the Bitcoin network is functional, realis-ing its live-ness and availability properties [12,13,32,8,7]. We assume that thereis significant hash-rate to prevent blockchain reorganisations of a depth higherthan the Unvault Tx’s relative lock-time. Next, we assume that Revault’s Txmodel is robust; with scripts that realise the access control structures we expect,without unintended consequences from Tx malleability and network propagationissues as described in [25]. We assume the initialization process was secure andsafe; private keys and backups were correctly and confidentially constructed foreach participant, software and hardware integrity were verified, relevant publickey information for both the wallet and communication was shared among par-ticipants leading to a correct configuration for the wallet clients, watchtowers,anti-replay oracles and the coordinator. We assume that Revault’s communica- tion security model as described in [4] is robust. That is, where messages needto be authenticated or confidential, they are. We assume that the software de-velopment life-cycle of Revault is secure, such that any deployment is using animplementation that adheres to the protocol specification. Finally, we assumethat entities constructing Deposit Txs don’t succumb to a man-in-the-middleattack. That is, they lock funds to the deposit descriptor rather than to anattacker’s address.
These attack sub-trees are common to different attacks on Revault, and a , b , c , d , e , f and g are likely to be common to attacks on other custody protocols. a : Compromise a participant (stakeholder or manager)
Coercion and insider threats from corrupt participants must be considered. Legaldefences for malicious employee behaviour can be effective deterrents here. b : Compromise a participant’s (stakeholder’s or manager’s) HM : Determine location of participant’s HM (SAND) : Access the physical security environment of the participant’s HM(SAND) : Exfiltrate keys (either on premise or after stealing it) (OR) : By-pass PIN and make the HM sign a malicious chosen message2 : Remote attack of HM (OR) : Compromise a device that is then connected to the HM (SAND) : (see g ) Compromise the participant’s wallet software (OR) : Trick participant into connecting their HM to a compromiseddevice via social engineering : Exploit a firmware vulnerability (OR) : Trick participant into compromising their own HM with the user in-terface of the compromised device3 : (see a ) Compromise a participant c : Compromise a participant’s (stakeholder’s or manager’s) keys backup : Determine location of the keys backup (SAND) : Watch the participant between the custody initialization andthe start of operations (OR) : Watch the participant during a backup check (OR) : Access the physical security environment of the keys backup (SAND) : Depending on backup format, steal or copy it2 : (see a ) Compromise a participant d : Compromise a server (watchtower, anti-replay oracle, or coordinator) : Exploit a software vulnerability (OR)isk Framework for Bitcoin Custody Operation with the Revault Protocol 11 : Determine the public interfaces of the server (SAND) : Exploit a vulnerability on one of the softwares listening on theseinterfaces : Exploit a human vulnerability (e.g. trick participant into performinga malicious update)2 : Physical attack (OR) : Determine server’s location (SAND) : Access the physical security environment of the server (SAND)3 : (see a ) Compromise the participant managing the server An attacker who successfully completes d for a watchtower will be able to stealfunds from the watchtower’s fee wallet and will be able to force an emergency sce-nario by broadcasting all Emergency and Unvault-Emergency Txs it has stored.They can also prevent broadcast of a Cancel Tx from this watchtower eitherpassively ( ACK the secure storage of the signature to the stakeholder, but thendrop the signature) or actively. e : Shutdown a watchtower : Determine watchtower’s location (SAND) : Sever the internet connection to the building in which the watchtoweris located (OR) : Sever the power-line connection to the building in which the watch-tower is located (OR) : Access the physical security of the watchtower and un-plug the ma-chine2 : Remote attack on the watchtower : Determine public interfaces of watchtower (SAND) : Denial of Service attack through one of the public interfaces (OR) : Eclipse attack on the watchtower’s Bitcoin node [15] (OR) : Slowly force de-synchronisation of watchtower with the trueblock height by delaying block propagation [34] (OR) : Prevent outgoing propagation of Cancel or Emergency Txs : Denial of Service attack on the fee-bumping UTxOs pool—not enoughfunds to pay competitive fees (OR) f : Get signature from participant to unlock UTxO for Theft Tx a ) Compromise a participant (OR)2 : (see b ) Compromise participant’s HM (OR)3 : (see c ) Compromise participant’s keys backup g : Compromise a participant’s wallet : Locate participant’s device (SAND) : Access physical security environment of participant’s device2 : Remote attack (OR) : Determine public interfaces of device (SAND) : Exploit a vulnerability3 : (see a ) Compromise participant Participant’s wallet devices are expected to be used for day-to-day activities.With many vulnerabilities to exploit, the likelihood of success for g is high. h : Determine the locking Script for a deposit or unvault UTxO (
WitnessScript ) g ) Compromise any participant’s wallet2 : (see d ) Compromise a watchtower3 : (see d ) Compromise an anti-replay oracle Deposit and unvault descriptors are deterministic, but public keys are needed toderive UTxO locking Scripts. These are stored by all wallets, watchtowers andanti-replay oracles. i : Satisfy an input in a Theft Tx that consumes an identified depositUTxO or unvault UTxO (through N − of − N ) h ) Determine the UTxO locking Script ( Witness Script ) (SAND)2 : Prevent the relevant Emergency Tx from being broadcast until the TheftTx is confirmed (where A + B = N ) (AND) : (see d ) Compromise a watchtower (A times) : (see e ) Shutdown a watchtower (B times) : (see g ) Compromise stakeholder’s wallet ( N times)3 : (see f ) Get signature from a stakeholder to unlock UTxO for Theft Tx ( N times) j : Satisfy an input in a Theft Tx that consumes an identified unvaultUTxO (through K − of − M , anti-replay oracles and time-lock) h ) Determine the UTxO locking Script ( Witness Script ) (SAND)2 : Receive signatures for Theft Tx from all N anti-replay oracles (AND) : Compromise a manager’s private communication keys and the set ofanti-replay oracles’ public communication keys (OR) : (see g ) Compromise a manager’s wallet (OR) : (see a ) Compromise a manager : (see d ) Compromise the anti-replay oracle3 : (see f ) Get signature from a manager to unlock UTxO for Theft Tx ( K times) k : Satisfy an input in a Theft Tx that consumes an identified emergencyUTxO etc .) The details of the emergency descriptor are intentionally not specified with theRevault protocol, except that it is more difficult to access than the depositdescriptor. Stakeholders may compartmentalise and distribute the descriptorinformation to afford its privacy some resilience to attack.
The following attack-trees are the foundation for an operational risk frameworkfor Revault. A : Compromise privacy of the custody operation (determine the set ofpublic UTxOs) isk Framework for Bitcoin Custody Operation with the Revault Protocol 131 : (see d ) Compromise any of the servers (OR)2 : (see a ) Compromise a participant (OR)3 : (see g ) Compromise a participant’s wallet (OR)4 : Traffic analysis of connections between servers and/or wallets (OR)5 : Blockchain analysis Without privacy support for advanced descriptors (such as by using MuSig2 [30]or MuSig-DN [31] if the proposed Taproot [1] upgrade is activated by the Bitcoinnetwork) Revault’s operational privacy is brittle. B : Broadcast Theft Tx(s) that consume all deposit UTxOs A ) Determine D , the set of deposit UTxOs (SAND)2 : (see h ) Determine the locking Script for deposit UTxO ( |D| times)3 : (see i ) Satisfy an input in a Theft Tx that consumes an identified depositUTxO ( |D| times) A Theft Tx that consumes all available deposit UTxOs would be catastrophicsince this comprises the majority of funds. We recommend a defence whereineach stakeholder is equipped with a panic button that is directly connected totheir watchtower or dedicated emergency service. When triggered, all the signedEmergency and Unvault-Emergency Txs are broadcast, negating the pay-off foran attacker and thus acting as a deterrent. C : Broadcast Theft Tx(s) that consume as many available unvault UTxOsas watchtower spending policies permit : (see a ) Compromise a participant (OR) : (see g ) Compromise a manager’s wallet : (see d ) Compromise a watchtower ( N times)2 : Determine U , the set of available unvault UTxOs (SAND) : (see A ) Compromise privacy of the custody operation (determine theset of public UTxOs) (SAND) : (see h ) Determine the locking Script for unvault UTxO ( |U| times)3 : (see i OR j ) Satisfy an input in a Theft Tx that consumes an identifiedunvault UTxO ( |U| times) C can be avoided if watchtowers have a white-list of addresses that Spend Txscan pay to. D : Broadcast Theft Tx(s) that consume all available unvault UTxOs, by-passing watchtowers’ spending policies N times SAND) : (see d ) Compromise a watchtower (OR) : (see e ) Shutdown a watchtower2 : Determine U , the set of available unvault UTxOs (SAND) : (see A ) Compromise privacy of the custody operation (determine theset of public UTxOs) (SAND) : (see h ) Determine the locking Script for unvault UTxO ( |U| times)3 : (see i OR j ) Satisfy an input in a Theft Tx that consumes an identifiedunvault UTxO ( |U| times)4 J. Swambo & A. Poinsot E : Broadcast a Theft Tx that by-passes watchtowers’ spending policies U , the set of available unvault UTxOs (SAND) : (see A ) Compromise privacy of the custody operation (determine theset of public UTxOs) (SAND) : (see h ) Determine the locking Script for unvault UTxO ( |U| times)2 : (see f ) Get signature from a manager to unlock U ⊆ U , a subset of availableunvault UTxOs for a valid Spend Tx ( K times)3 : (see i OR j ) Satisfy an input in a Theft Tx that consumes an identifiedunvault UTxO ( | U | times)4 : (see d ) Compromise an anti-replay oracle to get a signature for the validSpend Tx which consumes U , the UTxOs ( N times SAND)5 : Advertise the valid Spend Tx to the watchtowers through the coordinator(SAND)6 : Broadcast all Unvault Txs that the valid Spend Tx depends on and wait forthe time-lock to expire F : Force emergency scenario : (see d ) Compromise a watchtower (OR) : (see a ) Compromise a stakeholder The emergency deterrent results in better security from the most egregious phys-ical threats to participants (particularly stakeholders who control the majority offunds) but also in a fragility to the continuity of operations that could be abusedby an attacker. Attacks that rely on E may seek a pay-off other than fund theft,such as damaging the reputation of the organisation for having down-time andtaking a leveraged bet on the likely market consequences. However, forced down-time attacks through power or internet outages or detainment of personnel areprevalent threats for organisations who aren’t deploying Revault. In any case,with this risk model the consequence of not using an emergency deterrent canbe considered by performing an analysis with pruned attack-trees. G : Broadcast a Theft Tx which consumes all available UTxOs locked tothe emergency descriptor F ) Force an emergency scenario (SAND)2 : Determine E , the set of available emergency UTxOs (SAND) : (see A ) Compromise privacy of the custody operation (determine theset of public UTxOs)3 : (see k ) Satisfy an input in a Theft Tx that consumes an identified emergencyUTxO ( |E| times) H : Broadcast a Theft Tx which spends from a manager’s fee wallet g ) Compromise a manager’s wallet While this is a relatively simple attack, the fee wallet will never hold a significantportion of bitcoins and is considered external to the custody protocol. I : Prevent Emergency, Unvault-Emergency, and Cancel Tx valid signa-ture exchange N stakeholders doesn’t sign (OR)isk Framework for Bitcoin Custody Operation with the Revault Protocol 15 : Prevent stakeholder from accessing their HM (OR) : Prevent stakeholder from accessing their wallet (OR) : (see a ) Compromise a stakeholder2 : Shutdown coordinator (OR)3 : (see e ) Shutdown a watchtower ( N times) (OR)4 : Blockchain re-organization and Deposit Tx outpoint malleation. J : Prevent Unvault Tx signature exchange N stakeholders doesn’t sign (OR) : Prevent stakeholder from accessing their HM (OR) : Prevent stakeholder from accessing their wallet software (OR) : (see a ) Compromise a stakeholder2 : Shutdown coordinator (OR)3 : Prevent all managers from accessing their wallet software K : Prevent managers from broadcasting a Spend Tx : (see d ) Compromise an anti-replay oracle (OR) : Prevent sufficient threshold of managers from signing the Spend Tx(where A + B + C = M − K + 1) (OR) : (see a ) Compromise a manager ( A times) : Prevent manager from accessing their HM ( B times) : Prevent manager from accessing their wallet software ( C times)2 : Force broadcast of Cancel Tx (OR) : (see d ) Compromise a watchtower3 : Prevent broadcast of Unvault Tx : High demand for block space making the Unvault Tx not profitable tomine. : (see g ) Compromise manager’s wallet ( M times) The rise of Bitcoin has led to a new commercial ecosystem, with market ex-changes enabling its sale and purchase, companies and financial institutions of-fering secure custody services, and insurance brokers and underwriters willingto insure individuals, exchanges and custodians against loss or theft of their as-sets . In this paper we first posit that a methodology to better understand risksin custodial operations is needed, something complementary to understandingblockchain and cryptographic security. We put forth requirements of the mod-elling technique and propose attack-trees as a formalism which satisfies thoserequirements. We exemplify the approach by presenting a library of attack-treesconstructed for a multi-party custody protocol called Revault and explain howthis framework can be used as a basis for risk-management in custodial oper-ations. The next steps for this work are to: construct a set of defences to theprominent risks and incorporate them into the model; and to determine or builda suitable tool for automating computations for a specific analysis. Manager’s fee-bumping wallet can not cover this until a network policy such asPackage Relay [3] is implemented.6 J. Swambo & A. Poinsot
Acknowledgements
We thank Professor McBurney (King’s College London), Kevin Laoec (Wizard-Sardine) for insightful conversations and for reviewing the text.
Funding
Funding is gratefully acknowledged under a UK EPSRC-funded GTA Awardthrough King’s College London and from WizardSardine.
References
1. (Bitcoin Improvement Proposal) Taproot: SegWit version 1 spending rules, https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki , last ac-cessed 29 Jan 20212. Output Script Descriptors: a language for abstracting out the spending condi-tions of a Bitcoin transaction output, https://github.com/bitcoin/bitcoin/blob/master/doc/descriptors.md , last accessed 26 Jan 20213. Package Relay design questions for the Bitcoin P2P network, https://github.com/bitcoin/bitcoin/issues/14895 , last accessed 29 Jan 20214. Practical Revault: A specification for the initialization and operation of the Revaultcustody protocol, https://github.com/re-vault/practical-revault
5. Glacier design document (2017), https://glacierprotocol.org/assets/design-doc-v0.9-beta.pdf , last accessed 10 Jan 20216. Amoroso, E.G.: Fundamentals of Computer Security Technology. Prentice-Hall,Inc., USA (1994)7. Badertscher, C., Garay, J., Maurer, U., Tschudi, D., Zikas, V.: But Why Does ItWork? A Rational Protocol Design Treatment of Bitcoin. In: Nielsen, J.B., Rij-men, V. (eds.) Advances in Cryptology – EUROCRYPT 2018. pp. 34–65. SpringerInternational Publishing, Cham (2018)8. Badertscher, C., Maurer, U., Tschudi, D., Zikas, V.: Bitcoin as a transaction ledger:A composable treatment, vol. 10401 LNCS (2017). https://doi.org/10.1007/978-3-319-63688-7 119. Capital Markets and Technology Association: Digital AssetsCustody Standard (2020), ,last accessed 10 Jan 202110. Chow, A.: Partially signed bitcoin transaction format (2017), https://github.com/bitcoin/bips/blob/master/bip-0174.mediawiki , last accessed 18 May 202011. Gadyatskaya, O., Jhawar, R., Kordy, P., Lounis, K., Mauw, S., Trujillo-Rasua, R.:Attack Trees for Practical Security Assessment: Ranking of Attack Scenarios withADTool 2.0. vol. 9826, pp. 159–162 (08 2016). https://doi.org/10.1007/978-3-319-43425-4 1012. Garay, J., Kiayias, A., Leonardos, N.: The Bitcoin backbone protocol: Analysisand applications. Lecture Notes in Computer Science (including subseries LectureNotes in Artificial Intelligence and Lecture Notes in Bioinformatics) , 281–310(2015). https://doi.org/10.1007/978-3-662-46803-6 10isk Framework for Bitcoin Custody Operation with the Revault Protocol 1713. Garay, J., Kiayias, A., Leonardos, N.: The Bitcoin Backbone Protocol with Chainsof Variable Difficulty. In: Katz, J., Shacham, H. (eds.) Advances in Cryptology –CRYPTO 2017. pp. 291–323. Springer International Publishing, Cham (2017)14. Haque, M.S.: An evolutionary approach of attack graphs and attack trees: A surveyof attack modeling (09 2017)15. Heilman, E., Kendler, A., Zohar, A., Goldberg, S.: Eclipse attacks onbitcoin’s peer-to-peer network. In: 24th USENIX Security Symposium(USENIX Security 15). pp. 129–144. USENIX Association, Washington,D.C. (Aug 2015),
16. Hermanns, H., Kr¨amer, J., Krc´al, J., Stoelinga, M.: The value of attack-defencediagrams. vol. 9635, pp. 163–185 (04 2016). https://doi.org/10.1007/978-3-662-49635-0 917. Hubbard, D.W., Seiersen, R.: How to Measure Anything in Cybersecurity Risk(2016)18. Jhawar, R., Kordy, B., Mauw, S., Radomirovic, S., Trujillo-Rasua, R.: Attack Treeswith Sequential Conjunction. CoRR abs/1503.02261 (2015), http://arxiv.org/abs/1503.02261
19. Kordy, B., Mauw, S., Radomirovic, S., Schweitzer, P.: Foundations of at-tack–defense trees. vol. 6561, pp. 80–95 (09 2010). https://doi.org/10.1007/978-3-642-19751-2 620. Kordy, B., Pi`etre-Cambac´ed`es, L., Schweitzer, P.: Dag-based attack and defensemodeling: Don’t miss the forest for the attack trees. Computer Science Review (03 2013). https://doi.org/10.1016/j.cosrev.2014.07.00121. Kumar, R.: Truth or Dare: Quantitative security risk analysis using attack trees.Ph.D. thesis (10 2018). https://doi.org/10.3990/1.978903654625622. Kumar, R., Stoelinga, M.: Quantitative Security and Safety Analysis with Attack-Fault Trees (01 2017). https://doi.org/10.1109/HASE.2017.1223. Lallie, H., Debattista, K., Bal, J.: A review of attack graph and attack tree vi-sual syntax in cyber security. Computer Science Review , 100219 (02 2020).https://doi.org/10.1016/j.cosrev.2019.10021924. Loaec, K.: Hardware wallets and “advanced” Bitcoin features (2021), https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-January/018352.html , last accessed 19 Jan 202125. Loaec, K., Poinsot, A.: Revault: A multi-party Bicoin vault architecture (2020), https://github.com/re-vault/practical-revault/blob/master/revault.pdf
26. M. Sato, M. Shimaoka, H.N.: General Security Considerations forCryptoassets Custodians (2019), https://tools.ietf.org/html/draft-vcgtf-crypto-assets-security-considerations-05
27. Maynard, P., Mclaughlin, K., Sezer, S.: Modelling Duqu 2.0 Malware us-ing Attack Trees with Sequential Conjunction. pp. 465–472 (01 2016).https://doi.org/10.5220/000574570465047228. Maynard, P., McLaughlin, K., Sezer, S.: Decomposition and sequential-AND anal-ysis of known cyber-attacks on critical infrastructure control systems. Journalof Cybersecurity (1) (12 2020). https://doi.org/10.1093/cybsec/tyaa020, https://doi.org/10.1093/cybsec/tyaa020 , tyaa02029. Nguyen, H.N., Bryans, J., Shaikh, S.: Attack Defense Trees with Sequential Con-junction. IEEE (2019)30. Nick, J., Ruffing, T., Seurin, Y.: Musig2: Simple two-round schnorr multi-signatures. Cryptology ePrint Archive, Report 2020/1261 (2020), https://eprint.iacr.org/2020/1261 https://eprint.iacr.org/2020/1057
32. Pass, R., Seeman, L., Shelat, A.: Analysis of the Blockchain Protocol in Asyn-chronous Networks. In: Coron, J.S., Nielsen, J.B. (eds.) Advances in Cryptology –EUROCRYPT 2017. pp. 643–673. Springer International Publishing, Cham (2017)33. Perrin, T.: The Noise Protocol Framework (2018), https://noiseprotocol.org/noise.pdf , last accessed 19 Jan 202134. Riard, A., Naumenko, G.: Time-dilation attacks on the lightning network (2020)35. Schmitz, C., Sekulla, A., Pape, S.: Asset-Centric Analysis and Visualisation ofAttack Trees, pp. 45–64 (11 2020). https://doi.org/10.1007/978-3-030-62230-5 336. Schneier, B.: Attack Trees (1999), , last accessed 12 Jan 202137. Shostack, A.: Threat Modeling: Designing for Security (2014)38. Square: Subzero (2020), https://subzero.readthedocs.io/en/master/ , last ac-cessed 19 Jan 202039. Swambo, J., Hommel, S., McElrath, B., Bishop, B.: Custody protocols using bitcoinvaults (2020), https://arxiv.org/abs/2005.11776 , last accessed 10 Jan 202140. Weiss, J.D.: A system security engineering process. In: Proceedings of the 14thNational Computer Security Conf. (1991)41. Wuille, P.: Hierarchical deterministic wallets (2012), https://github.com/bitcoin/bips/blob/master/bip-0032.mediawikihttps://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki