This document discusses the needs in term of signing devices to have reasonable security. Its audience is people interested to develop or modify hardware wallets compatible with Revault.
It covers risk mitigation for very advanced attacks, compromising all participants computers. These attacks are very unlikely in the first place but shouldn't be considered impossible given the incentive.
Revault is engineered to withstand advanced and well funded attacks. Some Revault wallets will secure hundreds of million USD worth of bitcoin. One core assumption is that Revault users will have the client (Revaultd and GUI) running on their work laptop, and it is assumed to be easily compromised.
This means all transactions, especially the critical Cancel and Emergency transactions, are potentially poisoned at time of generation (for example output with an external pubkey added to the multisig for example).
The signing isn't happening on this laptop, but on a separate signing device to protect the private keys better.
While a signing device could technically be any machine capable of signing bitcoin signatures (currently: ECDSA), key management is still important. We recommend (and assume going forward) our users to store their private keys on security modules such as Hardware Wallets with secure elements. This improves the physical attack resilience significantly. (again: Revault doesn't limit itself to online/remote threats).
--
Output Script Parsing
In 2020, hardware wallets typically display the amount and the destination address to be checked by the user. This is not sufficient to prevent an attack as the user cannot know what this address corresponds to, it is only a hash after all.
We need a few improvements to make Revault more secure.
the hardware wallet should display the output script(s), not an address (whenever possible). This can be done in multiple ways:
Raw Script
Miniscript Policy (better)
A more verbose and user friendly parsing (best)
We don't expect anyone to be able to understand what Script does, so this option isn't acceptable.
The minimal viable implementation would be a Miniscript Policy display, and this is still hard to check even for technical users.
The better implementation would display the transactions in a user friendly manner such as:
Transaction type: Unvault Tx
Spending path: Timelock of 10 blocks, and signatures of (here goes PubKey1) AND (here goes PubKey2).
Cancel path: All of (PubkeyA, PubkeyB, PubkeyC, PubkeyD).
This is quite easy to attack, as users may not have access to all the Stakeholders public keys to double check. I.E, the format can be respected but not the actual participants...
The solution is to be able to identify all the participants' PubKeys directly on the HW. The display would look as follow:
Transaction type: Unvault Tx
Spending path: Timelock of 10 blocks, and signatures of Alice AND Bob.
Cancel path: All Stakeholders.
Any transaction trying to add different participants or omit them would generate an error, not respecting the normal Unvault output. To support this, each hardware wallet needs to be able to store and derive the public keys of every participant.
While such a logic could be made on the MCU (general purpose chip, low security) of the hardware wallets, it would be preferable to have it in the tamper-proof Secure Element.
We understand the Secure Elements are very limited in performance and memory and this will not be an easy feat.
--
Inputs
With the Private Key extraction and Output attacks now covered, we need to discuss another risk specifically annoying in a pre-signed transaction architecture: poisoned Inputs.
In Bitcoin, inputs refer to previous transactions' "unspent outputs". A pre-signed transaction (not broadcast yet) is only valid as long as its inputs stay unspent. Revault mitigates the risk of two Spend transactions to spend from the same outputs with the addition of the Cosigning Servers.
The security pre-signed transactions (Cancel and Emergency tx) are still at risk because the Hardware Wallets do not have the "state" of Bitcoin, they are not full nodes. The Inputs provided in the PSBT might be inexistant, wrong or already spent.
As Revault does not use Secure Key Deletion, the funds are not at risk of permanent loss. The risk is a malware sending the correct Inputs for the Unvault, but not for the Cancel or Emergency transaction. A malicious transaction wouldn't be "revault-able" in this case.
Against theft, we do not need to know if the Inputs are valid UTXOs. We only need to make sure the signing device checks that the Unvault transaction uses inputs already pre-signed with Cancel and Emergency transactions. If the inputs are invalid, the Unvault is also invalid therefore no Spend can happen.
The issue remaining would be that the Emergency spending from the Vault directly may be invalid, creating a false sense of security in case an Emergency is broadcast (the funds would stay in the Vault instead of moving to the Emergency Vault).
The alternative would be to have a full node on, or trusted by, the hardware wallet. Again: we do not want to consider the day-to-day laptop to be trusted.
Conclusion:
The signing device needs to keep track of the inputs of Cancel and Emergency transaction to make sure no Unvault is signed without its corresponding security transactions.
An even better implementation would require the HW to be a full node or an external trusted state such as a the PSBTs to be signed by the watchtowers or something equivalent.
--
Revault uses quite a few features of Bitcoin that may or may not be supported by existing hardware wallets.
To be "Revault compatible", HW needs to support:
sighash flags
OP_CSV time locks
conditional outputs
PSBT
large transactions. A "Revault-compatible" hardware wallet should specify what maximum size of PSBT it can process.
As previously stated, Miniscript Policy and Output Descriptors parsing is also considered a must.
WORK IN PROGRESS. Edit number 2
This document discusses the needs in term of signing devices to have reasonable security. Its audience is people interested to develop or modify hardware wallets compatible with Revault. It covers risk mitigation for very advanced attacks, compromising all participants computers. These attacks are very unlikely in the first place but shouldn't be considered impossible given the incentive.
Revault is engineered to withstand advanced and well funded attacks. Some Revault wallets will secure hundreds of million USD worth of bitcoin. One core assumption is that Revault users will have the client (Revaultd and GUI) running on their work laptop, and it is assumed to be easily compromised. This means all transactions, especially the critical Cancel and Emergency transactions, are potentially poisoned at time of generation (for example output with an external pubkey added to the multisig for example). The signing isn't happening on this laptop, but on a separate signing device to protect the private keys better.
While a signing device could technically be any machine capable of signing bitcoin signatures (currently: ECDSA), key management is still important. We recommend (and assume going forward) our users to store their private keys on security modules such as Hardware Wallets with secure elements. This improves the physical attack resilience significantly. (again: Revault doesn't limit itself to online/remote threats).
--
Output Script Parsing
In 2020, hardware wallets typically display the amount and the destination address to be checked by the user. This is not sufficient to prevent an attack as the user cannot know what this address corresponds to, it is only a hash after all. We need a few improvements to make Revault more secure.
We don't expect anyone to be able to understand what Script does, so this option isn't acceptable. The minimal viable implementation would be a Miniscript Policy display, and this is still hard to check even for technical users. The better implementation would display the transactions in a user friendly manner such as:
This is quite easy to attack, as users may not have access to all the Stakeholders public keys to double check. I.E, the format can be respected but not the actual participants...
The solution is to be able to identify all the participants' PubKeys directly on the HW. The display would look as follow:
Any transaction trying to add different participants or omit them would generate an error, not respecting the normal Unvault output. To support this, each hardware wallet needs to be able to store and derive the public keys of every participant.
While such a logic could be made on the MCU (general purpose chip, low security) of the hardware wallets, it would be preferable to have it in the tamper-proof Secure Element. We understand the Secure Elements are very limited in performance and memory and this will not be an easy feat.
--
Inputs
With the Private Key extraction and Output attacks now covered, we need to discuss another risk specifically annoying in a pre-signed transaction architecture: poisoned Inputs. In Bitcoin, inputs refer to previous transactions' "unspent outputs". A pre-signed transaction (not broadcast yet) is only valid as long as its inputs stay unspent. Revault mitigates the risk of two Spend transactions to spend from the same outputs with the addition of the Cosigning Servers. The security pre-signed transactions (Cancel and Emergency tx) are still at risk because the Hardware Wallets do not have the "state" of Bitcoin, they are not full nodes. The Inputs provided in the PSBT might be inexistant, wrong or already spent. As Revault does not use Secure Key Deletion, the funds are not at risk of permanent loss. The risk is a malware sending the correct Inputs for the Unvault, but not for the Cancel or Emergency transaction. A malicious transaction wouldn't be "revault-able" in this case. Against theft, we do not need to know if the Inputs are valid UTXOs. We only need to make sure the signing device checks that the Unvault transaction uses inputs already pre-signed with Cancel and Emergency transactions. If the inputs are invalid, the Unvault is also invalid therefore no Spend can happen. The issue remaining would be that the Emergency spending from the Vault directly may be invalid, creating a false sense of security in case an Emergency is broadcast (the funds would stay in the Vault instead of moving to the Emergency Vault).
The alternative would be to have a full node on, or trusted by, the hardware wallet. Again: we do not want to consider the day-to-day laptop to be trusted.
Conclusion:
--
Revault uses quite a few features of Bitcoin that may or may not be supported by existing hardware wallets. To be "Revault compatible", HW needs to support:
As previously stated, Miniscript Policy and Output Descriptors parsing is also considered a must.
--
To Be Continued... ( transaction types, "bypass")