📅 Original date posted:2021-01-16
📝 Original message:Hello Kevin,
Thanks for starting this thread, that's a really relevant discussion
ecosystem-wise !
> * Proposed improvement: The HW should display the Bitcoin Script itself
when possible (including the unlock conditions).
What level of script literacy are you assuming on your users ? I can see
enterprise/hobbyist folks to know enough of Script to understand the
intended behavior but I don't think that's a reasonable assumption for your
average user. Of course, Miniscript Policy makes things easier, but IMHO, I
still hope to see some mature, higher-level language (e.g Ivy) to ease
script semantic understanding and thus widen the crowd of users.
Further, I would do a bit on UX research on the correctness model expected
by your users. I.e if they fail to verify accordingly, are they losing
funds, transaction doesn't confirm, transaction doesn't even propagate,
etc. You should also make assumptions on the mental resources you're
required from them. Time-sensitive L2 protocols have a wide scope to check,
e.g not verifying the nSequence/nLocktime fields can provoke funds failures.
> This applies to pre-signed transaction protocols especially well as the
template of these transactions could be known
and recognized by the HW. Typically for Revault, the HW could display:
"Unvault Transaction, all expected pubkeys
present in the script".
In the future, I would expect templates of high-security protocols like
vaults to be part of the trusted computing base of any decent HW. I think
good standards there would avoid HW vendors to come with some kind of
certified-templates scheme and thus having to bless custom scripts of every
vaults implementations.
> Proposed improvement: The HW could know pubkeys or xpubs it does not hold
the private keys
for, and display a label (or
understand it for logic reasons, such as "expected pubkeys" as the previous
example).
I don't think you even need user input on this, the absence of pubkeys
knowledge itself is a trigger to display a label or ask for further
information. Where absence of pubkeys knowledge can be interpreted as
devoid from key whitelisting or privkey ownership.
> Going further, the xpubs could be
aliased the first time they are entered/verified (as part of, say, an
initial setup ceremony) for instance with the
previously mentioned Miniscript policy: or(pk(Alice), and(pk(Bob),
after(42))).
I would be careful about accidental or malicious alias collisions. But yes
that can be something, you can even conserve a merkle tree root in the
Secure Element where the hashed element are
previously authenticated alias/pubkeys. And require from the non-trusted
challenger to come with a merkle branch to validate address inclusion.
> Then there is PSBT support and the maximum transaction size limit for
these: we need more transparency from HW manufacturers on their li
mitations.
I understand them, Script is full of subtleties, taproot is likely to have
more of them and if you take sighash malleability that's not something you
want your average user to play with. Maybe it
would be better to come up with a first wave of script features on which
you expect transparency ? For sure, OP_CSV is a good candidate.
> Once any input of a (pre-signed)transaction is
spent, this transaction isn't valid anymore. Most pre-signed transactions
protocols are used today as a form of defense
mechanism, spending any input would mean incapacitating the entire defense
mechanism.
I don't see the exact issue here. E.g in Lightning, even if you pre-sign a
justice transaction punishing every revokeable outputs on counterparty
transaction, and one input is spent, will current HWs prevent you to-resign
an updated justice transaction ?
> I understand some of these changes may be very difficult, especially
given the low memory and computational power of
secure elements.
Instead of relying on hand-sized devices, what about relying on HSMs for a
first-wave of adoptions, those ones have far enough resources to run a
reasonable L2 stack on the trusted-side ?
But overall agree, on the requirement to level-up HWs for L2. IMO, a first
step could be to list a common set of features beyond
deployed/soon-to-be-deployed L2s, that would make things easier for HW
vendors to have a unique list of grievances. Before they engage in further,
dedicated tweaks to adapt for each protocol security model. OP_CSV/OP_CTLV
decoding/"burned" standard scripts support would be a good starter.
> Feel free to reply with your comments or adding suggestions, I am not a
hardware wallet expert and would take criticism
wit
hout being offended.
I don't know yet any *L2* hardware wallet expert :)
Cheers,
Antoine
Le jeu. 14 janv. 2021 à 13:46, Kevin Loaec via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> a écrit :
> Hello everyone,
>
> I would like to start a discussion on improving Hardware Wallets.
>
> My approach to this right now is from a vault protocol we are developing
> (Revault, [1]), and its Hardware Wallet
> requirements. I started working on a Github Issue in our repo [2], other
> people recommended us to do a more general
> discussion on the mailing list instead as it could benefit many other
> protocols and users.
> This email discusses improvements that would benefit everyone, and some
> that are more suitable for "layer 2" or pre-
> signed transactions protocols.
> The goal is to spark discussions and hopefully iterate to a more secure
> and more usable hardware ecosystem for all
> bitcoiners.
> While I mainly foresee issues/improvements that may affect Revault, I
> would be really happy to see people joining this
> thread with any other ideas and remarks that would benefit some parts of
> Bitcoin that I overlooked.
>
>
>
> Prior work on similar problematics:
> ===================================
> - ZmnSCPx
> j: [Lightning-dev] Speculations on hardware wallet support for Lightning
> [3]
> - mflaxman: Known Issues: Verifying a Receive Address [4]
> - ksedgwic and devrandom01: Lightning-signer [5]
> - benma: How nearly all personal hardware wallet multisig setups are
> insecure [6]
>
>
> The postulate we start from is that Hardware Wallets (HW) are useful to
> mitigate the compromission of the day-to-day
> device of a user. They mainly prevent private-key extraction today, and
> aren't very suitable against an attack on the
> transaction being signed, as explained further.
> To make this discussion security-focused, let's assume the general purpose
> device (laptop, for example) is compromised
> with a malware implanted by an attacker, capable of modifying PSBTs,
> displayed addresses, etc.
>
> Our study so far:
>
>
> Output Script Parsing:
> ======================
> Problem: A typical HW today would display the "destination" of a
> transaction in the form of a bitcoin address. A user
> would generally compare this wit
> h the address displayed on his laptop screen... which might have been
> compromised
> already. The correct usage would be for a user to verify this address on a
> third device (mobile phone, for example).
> This is weak security and bad user experience.
> Proposed improvement: The HW should display the Bitcoin Script itself when
> possible (including the unlock conditions).
> The best way to do so would be to lift this Script to a more user-friendly
> format such as a MiniScript Policy display,
> but anything would be better than an "address".
> This applies to pre-signed transaction protocols especially well as the
> template of these transactions could be known
> and recognized by the HW. Typically for Revault, the HW could display:
> "Unvault Transaction, all expected pubkeys
> present in the script".
>
>
> Pubkey Interpretation:
> ======================
> Problem: currently HW cannot "identify" addresses or keys.
> Proposed improvement: The HW could know pubkeys or xpubs it does not hold
> the private keys
> for, and display a label (or
> understand it for logic reasons, such as "expected pubkeys" as the
> previous example). Going further, the xpubs could be
> aliased the first time they are entered/verified (as part of, say, an
> initial setup ceremony) for instance with the
> previously mentioned Miniscript policy: or(pk(Alice), and(pk(Bob),
> after(42))).
> This should be done in the Secure Element if possible to avoid physical
> compromission, but would be a strong improvement
> versus a day-to-day laptop in any case.
>
>
> Better Bitcoin Compatibility:
> =============================
> Problem: most HW cannot interpret some Script OPs such as OP_CSV, or any
> conditional outputs. This is a major issue for
> anyone using Bitcoin "advanced" features. Related to this are the Sighash
> flags: most HW do not support most Sighash
> flags. Kind of annoying for a signing device. Then there is PSBT support
> and the maximum transaction size limit for
> these: we need more transparency from HW manufacturers on their li
> mitations.
> Solution: Make Bitcoin HW actually compatible with Bitcoin :D
>
>
> Inputs (mainly for pre-signed Tx):
> ==================================
> Problem: Poisoned inputs are a major risk for HW as they don't know the
> UTXO set. While this can be exploited for fee
> attacks, it is a bigger threat to pre-signed transactions protocols. Once
> any input of a (pre-signed)transaction is
> spent, this transaction isn't valid anymore. Most pre-signed transactions
> protocols are used today as a form of defense
> mechanism, spending any input would mean incapacitating the entire defense
> mechanism.
> Proposed improvement: for protocols that requires it, keeping track of
> inputs already signed once would be extremely
> helpful. Going further, most of these protocols require to follow a
> specific signing order (typically the "clawback"
> first, then the regular spend path) so adding a way to check that a
> "clawback" has been signed first, with the same
> input, would be very helpful. All of this on the dev
> ice itself.
>
>
>
>
> I understand some of these changes may be very difficult, especially given
> the low memory and computational power of
> secure elements. However I truly believe most of these points are a MUST
> have for any decent security. If you don't
> assume the computer on which the transaction is crafted is compromised,
> then you don't need a hardware wallet. If you
> assume it may be compromised, then the HW needs to be able to defend
> against those.
>
> Revault does not plan on building hardware wallets, we hope existing and
> upcoming manufacturers will implement a strong
> security that we could use for the Revault protocol users. Vault users
> will likely hold very large sums and would be
> happy to pay a high premium for more secure HW. This will hopefully
> encourage existing players to keep on improving
> their devices and that will ultimately benefit us all.
>
> Feel free to reply with your comments or adding suggestions, I am not a
> hardware wallet expert and would take criticism
> wit
> hout being offended.
>
> Kind Regards,
> Kevin Loaec
>
> [1]:
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.html
> [2]: https://github.com/re-vault/practical-revault/issues/59
> [3]:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002425.html
> [4]: https://btcguide.github.io/known-issues/verify-receive-address
> [5]: https://gitlab.com/lightning-signer/docs
> [6]:
> https://shiftcrypto.ch/blog/how-nearly-all-personal-hardware-wallet-multisig-setups-are-insecure/
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210116/7b763fff/attachment.html>;
Antoine Riard [ARCHIVE] /
npub1vj…4x8dd
2023-06-07 18:28:13
in reply to nevent1q…et5p
Author Public Key
npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddPublished at
2023-06-07 18:28:13Event JSON
{
"id": "d68af60e1b71c87eb8c263a6c44057f73640bb8fb6aadbc05d15826ef0abf6ba",
"pubkey": "6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551",
"created_at": 1686162493,
"kind": 1,
"tags": [
[
"e",
"39ba8486eb5c0a5939bf417f9f771fb3deb8129902423e68777f5afe11d3238b",
"",
"root"
],
[
"e",
"9a36c0402a9882bb98cac34415fe090349104ef44bb9b682346581a9e24256be",
"",
"reply"
],
[
"p",
"93e50f297b9985b1adba93e5476189e5e00720066bac1db9471ef7c229448b85"
]
],
"content": "📅 Original date posted:2021-01-16\n📝 Original message:Hello Kevin,\n\nThanks for starting this thread, that's a really relevant discussion\necosystem-wise !\n\n\u003e * Proposed improvement: The HW should display the Bitcoin Script itself\nwhen possible (including the unlock conditions).\n\nWhat level of script literacy are you assuming on your users ? I can see\nenterprise/hobbyist folks to know enough of Script to understand the\nintended behavior but I don't think that's a reasonable assumption for your\naverage user. Of course, Miniscript Policy makes things easier, but IMHO, I\nstill hope to see some mature, higher-level language (e.g Ivy) to ease\nscript semantic understanding and thus widen the crowd of users.\n\nFurther, I would do a bit on UX research on the correctness model expected\nby your users. I.e if they fail to verify accordingly, are they losing\nfunds, transaction doesn't confirm, transaction doesn't even propagate,\netc. You should also make assumptions on the mental resources you're\nrequired from them. Time-sensitive L2 protocols have a wide scope to check,\ne.g not verifying the nSequence/nLocktime fields can provoke funds failures.\n\n\u003e This applies to pre-signed transaction protocols especially well as the\ntemplate of these transactions could be known\nand recognized by the HW. Typically for Revault, the HW could display:\n\"Unvault Transaction, all expected pubkeys\npresent in the script\".\n\nIn the future, I would expect templates of high-security protocols like\nvaults to be part of the trusted computing base of any decent HW. I think\ngood standards there would avoid HW vendors to come with some kind of\ncertified-templates scheme and thus having to bless custom scripts of every\nvaults implementations.\n\n\u003e Proposed improvement: The HW could know pubkeys or xpubs it does not hold\nthe private keys\nfor, and display a label (or\nunderstand it for logic reasons, such as \"expected pubkeys\" as the previous\nexample).\n\nI don't think you even need user input on this, the absence of pubkeys\nknowledge itself is a trigger to display a label or ask for further\ninformation. Where absence of pubkeys knowledge can be interpreted as\ndevoid from key whitelisting or privkey ownership.\n\n\u003e Going further, the xpubs could be\naliased the first time they are entered/verified (as part of, say, an\ninitial setup ceremony) for instance with the\npreviously mentioned Miniscript policy: or(pk(Alice), and(pk(Bob),\nafter(42))).\n\nI would be careful about accidental or malicious alias collisions. But yes\nthat can be something, you can even conserve a merkle tree root in the\nSecure Element where the hashed element are\npreviously authenticated alias/pubkeys. And require from the non-trusted\nchallenger to come with a merkle branch to validate address inclusion.\n\n\u003e Then there is PSBT support and the maximum transaction size limit for\nthese: we need more transparency from HW manufacturers on their li\nmitations.\n\nI understand them, Script is full of subtleties, taproot is likely to have\nmore of them and if you take sighash malleability that's not something you\nwant your average user to play with. Maybe it\nwould be better to come up with a first wave of script features on which\nyou expect transparency ? For sure, OP_CSV is a good candidate.\n\n\u003e Once any input of a (pre-signed)transaction is\nspent, this transaction isn't valid anymore. Most pre-signed transactions\nprotocols are used today as a form of defense\nmechanism, spending any input would mean incapacitating the entire defense\nmechanism.\n\nI don't see the exact issue here. E.g in Lightning, even if you pre-sign a\njustice transaction punishing every revokeable outputs on counterparty\ntransaction, and one input is spent, will current HWs prevent you to-resign\nan updated justice transaction ?\n\n\u003e I understand some of these changes may be very difficult, especially\ngiven the low memory and computational power of\nsecure elements.\n\nInstead of relying on hand-sized devices, what about relying on HSMs for a\nfirst-wave of adoptions, those ones have far enough resources to run a\nreasonable L2 stack on the trusted-side ?\n\nBut overall agree, on the requirement to level-up HWs for L2. IMO, a first\nstep could be to list a common set of features beyond\ndeployed/soon-to-be-deployed L2s, that would make things easier for HW\nvendors to have a unique list of grievances. Before they engage in further,\ndedicated tweaks to adapt for each protocol security model. OP_CSV/OP_CTLV\ndecoding/\"burned\" standard scripts support would be a good starter.\n\n\u003e Feel free to reply with your comments or adding suggestions, I am not a\nhardware wallet expert and would take criticism\nwit\nhout being offended.\n\nI don't know yet any *L2* hardware wallet expert :)\n\nCheers,\nAntoine\n\nLe jeu. 14 janv. 2021 à 13:46, Kevin Loaec via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e Hello everyone,\n\u003e\n\u003e I would like to start a discussion on improving Hardware Wallets.\n\u003e\n\u003e My approach to this right now is from a vault protocol we are developing\n\u003e (Revault, [1]), and its Hardware Wallet\n\u003e requirements. I started working on a Github Issue in our repo [2], other\n\u003e people recommended us to do a more general\n\u003e discussion on the mailing list instead as it could benefit many other\n\u003e protocols and users.\n\u003e This email discusses improvements that would benefit everyone, and some\n\u003e that are more suitable for \"layer 2\" or pre-\n\u003e signed transactions protocols.\n\u003e The goal is to spark discussions and hopefully iterate to a more secure\n\u003e and more usable hardware ecosystem for all\n\u003e bitcoiners.\n\u003e While I mainly foresee issues/improvements that may affect Revault, I\n\u003e would be really happy to see people joining this\n\u003e thread with any other ideas and remarks that would benefit some parts of\n\u003e Bitcoin that I overlooked.\n\u003e\n\u003e\n\u003e\n\u003e Prior work on similar problematics:\n\u003e ===================================\n\u003e - ZmnSCPx\n\u003e j: [Lightning-dev] Speculations on hardware wallet support for Lightning\n\u003e [3]\n\u003e - mflaxman: Known Issues: Verifying a Receive Address [4]\n\u003e - ksedgwic and devrandom01: Lightning-signer [5]\n\u003e - benma: How nearly all personal hardware wallet multisig setups are\n\u003e insecure [6]\n\u003e\n\u003e\n\u003e The postulate we start from is that Hardware Wallets (HW) are useful to\n\u003e mitigate the compromission of the day-to-day\n\u003e device of a user. They mainly prevent private-key extraction today, and\n\u003e aren't very suitable against an attack on the\n\u003e transaction being signed, as explained further.\n\u003e To make this discussion security-focused, let's assume the general purpose\n\u003e device (laptop, for example) is compromised\n\u003e with a malware implanted by an attacker, capable of modifying PSBTs,\n\u003e displayed addresses, etc.\n\u003e\n\u003e Our study so far:\n\u003e\n\u003e\n\u003e Output Script Parsing:\n\u003e ======================\n\u003e Problem: A typical HW today would display the \"destination\" of a\n\u003e transaction in the form of a bitcoin address. A user\n\u003e would generally compare this wit\n\u003e h the address displayed on his laptop screen... which might have been\n\u003e compromised\n\u003e already. The correct usage would be for a user to verify this address on a\n\u003e third device (mobile phone, for example).\n\u003e This is weak security and bad user experience.\n\u003e Proposed improvement: The HW should display the Bitcoin Script itself when\n\u003e possible (including the unlock conditions).\n\u003e The best way to do so would be to lift this Script to a more user-friendly\n\u003e format such as a MiniScript Policy display,\n\u003e but anything would be better than an \"address\".\n\u003e This applies to pre-signed transaction protocols especially well as the\n\u003e template of these transactions could be known\n\u003e and recognized by the HW. Typically for Revault, the HW could display:\n\u003e \"Unvault Transaction, all expected pubkeys\n\u003e present in the script\".\n\u003e\n\u003e\n\u003e Pubkey Interpretation:\n\u003e ======================\n\u003e Problem: currently HW cannot \"identify\" addresses or keys.\n\u003e Proposed improvement: The HW could know pubkeys or xpubs it does not hold\n\u003e the private keys\n\u003e for, and display a label (or\n\u003e understand it for logic reasons, such as \"expected pubkeys\" as the\n\u003e previous example). Going further, the xpubs could be\n\u003e aliased the first time they are entered/verified (as part of, say, an\n\u003e initial setup ceremony) for instance with the\n\u003e previously mentioned Miniscript policy: or(pk(Alice), and(pk(Bob),\n\u003e after(42))).\n\u003e This should be done in the Secure Element if possible to avoid physical\n\u003e compromission, but would be a strong improvement\n\u003e versus a day-to-day laptop in any case.\n\u003e\n\u003e\n\u003e Better Bitcoin Compatibility:\n\u003e =============================\n\u003e Problem: most HW cannot interpret some Script OPs such as OP_CSV, or any\n\u003e conditional outputs. This is a major issue for\n\u003e anyone using Bitcoin \"advanced\" features. Related to this are the Sighash\n\u003e flags: most HW do not support most Sighash\n\u003e flags. Kind of annoying for a signing device. Then there is PSBT support\n\u003e and the maximum transaction size limit for\n\u003e these: we need more transparency from HW manufacturers on their li\n\u003e mitations.\n\u003e Solution: Make Bitcoin HW actually compatible with Bitcoin :D\n\u003e\n\u003e\n\u003e Inputs (mainly for pre-signed Tx):\n\u003e ==================================\n\u003e Problem: Poisoned inputs are a major risk for HW as they don't know the\n\u003e UTXO set. While this can be exploited for fee\n\u003e attacks, it is a bigger threat to pre-signed transactions protocols. Once\n\u003e any input of a (pre-signed)transaction is\n\u003e spent, this transaction isn't valid anymore. Most pre-signed transactions\n\u003e protocols are used today as a form of defense\n\u003e mechanism, spending any input would mean incapacitating the entire defense\n\u003e mechanism.\n\u003e Proposed improvement: for protocols that requires it, keeping track of\n\u003e inputs already signed once would be extremely\n\u003e helpful. Going further, most of these protocols require to follow a\n\u003e specific signing order (typically the \"clawback\"\n\u003e first, then the regular spend path) so adding a way to check that a\n\u003e \"clawback\" has been signed first, with the same\n\u003e input, would be very helpful. All of this on the dev\n\u003e ice itself.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e I understand some of these changes may be very difficult, especially given\n\u003e the low memory and computational power of\n\u003e secure elements. However I truly believe most of these points are a MUST\n\u003e have for any decent security. If you don't\n\u003e assume the computer on which the transaction is crafted is compromised,\n\u003e then you don't need a hardware wallet. If you\n\u003e assume it may be compromised, then the HW needs to be able to defend\n\u003e against those.\n\u003e\n\u003e Revault does not plan on building hardware wallets, we hope existing and\n\u003e upcoming manufacturers will implement a strong\n\u003e security that we could use for the Revault protocol users. Vault users\n\u003e will likely hold very large sums and would be\n\u003e happy to pay a high premium for more secure HW. This will hopefully\n\u003e encourage existing players to keep on improving\n\u003e their devices and that will ultimately benefit us all.\n\u003e\n\u003e Feel free to reply with your comments or adding suggestions, I am not a\n\u003e hardware wallet expert and would take criticism\n\u003e wit\n\u003e hout being offended.\n\u003e\n\u003e Kind Regards,\n\u003e Kevin Loaec\n\u003e\n\u003e [1]:\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-May/017835.html\n\u003e [2]: https://github.com/re-vault/practical-revault/issues/59\n\u003e [3]:\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-January/002425.html\n\u003e [4]: https://btcguide.github.io/known-issues/verify-receive-address\n\u003e [5]: https://gitlab.com/lightning-signer/docs\n\u003e [6]:\n\u003e https://shiftcrypto.ch/blog/how-nearly-all-personal-hardware-wallet-multisig-setups-are-insecure/\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210116/7b763fff/attachment.html\u003e",
"sig": "c7ffdd641036110354031c97607fe6d71d606ff1dc924dd20779d12d31f8b36cbca31ead1ad51e910b6119fa64f80c846028815cd6e7d9a76e948eb9b5ac5edb"
}