📅 Original date posted:2016-08-17
📝 Original message:On Tue, Aug 16, 2016 at 7:14 PM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> The other serious problem - and this is a problem with smartcards in
> general
> anyway - is that without Bitcoin-specific logic you're just signing
> blindly; we
> recently saw the problems with that with the Bitfinex/BitGo hack. And even
> then, without a screen most of the hardware wallets in are still just
> signing
> blindly, with at best hard-to-use limits on maximum funds moved
> per-transaction. Also note how even hardware wallets with a screen, like
> Trezor, aren't yet able to authenticate who you are paying.
>
"Welcome to my threat model."
In multisig scenarios, there must be a different "trust root" for each key.
For example, storing two private keys next to each other on the same web
server is broken because if one key is compromised it is infinitely trivial
to compromise the second key. Using multiple web servers is also broken if
the two servers are controlled by the same AWS keys or same "help me get my
servers back" support email request to whatever single sign-on service is
used. In some cases, it can be better to write software such that
transaction data is served at a particular location, and another
security-critical step is responsible for downloading that data from the
first machine, rather than the first computer directly pushing (with
authentication credentials in place for the attacker to compromise) the
data to the second computer.
I recommend using hardware security modules (HSMs). It's important to have
a public, reviewed bitcoin standard for hardware wallets, especially HSMs.
I expect this is something that the entire industry has a tremendous
interest in following and contributing to, which could even lead to
additional resources contributed (or at the very least, more detailed
requirements) towards libconsensus work.
Instead of signing any bitcoin transaction that the hardware wallet is
given, the hardware should be responsible for running bitcoin validation
rules and business logic, which I recommend for everyone, not only
businesses. Without running business logic and bitcoin validation rules,
the actual bitcoin history on the blockchain could be a very different
reality from what the hardware thinks is happening. Using a different
out-of-band communication channel, the hardware could query for information
from another database in another trust root, which would be useful for
business logic to validate against.
As for a screen, I consider that somewhat limited because you only get text
output (and I don't know if I can reasonably suggest QR codes here). With a
screen, you are limited to text output, which can compromise privacy of the
device's operations and info about the wallet owner. An alternative would
be to have a dedicated port that is responsibly only for sending out data
encrypted to the key of the wallet owner, to report information such as
whatever the hardware's transaction planner has decided, or to report about
the state of the device, state of the bitcoin validation rules, or any
accounting details, etc. Additionally, even a signed transaction should be
encrypted to the key of the device owner because a signed transaction can
be harmless as long as the owner still has the ability to control whether
the signed transaction is broadcasted to the network. It's "separation of
concerns" for transaction signing and decrypting a signed transaction
should be unrelated and uncoupled.
Also I am eager to see what the community proposes regarding signed and
authenticated payment requests.
((insert here general promotional statement regarding the value of reusable
checklists used during every signing ritual ceremony))
- Bryan
http://heybryan.org/
1 512 203 0507
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/5492f37f/attachment.html>;
Bryan Bishop [ARCHIVE] /
npub1vt…jsjpg
2023-06-07 17:52:54
in reply to nevent1q…qvk7
Author Public Key
npub1vtwuk4rjyj6zrq3tv2z9lvdm6a7g8zujf0gz9q2vljlztdaqw36sjjsjpgPublished at
2023-06-07 17:52:54Event JSON
{
"id": "9332eef1fe323d26e8e3459e5f9c8a54e873a9c0642abb3ea614c56a1bf814ae",
"pubkey": "62ddcb547224b421822b62845fb1bbd77c838b924bd022814cfcbe25b7a07475",
"created_at": 1686160374,
"kind": 1,
"tags": [
[
"e",
"6e7f7cb2c3110cb7289a3abd667304a3b4e6f9ba4e2581c492d7b93c214a5ea1",
"",
"root"
],
[
"e",
"653204bb2bf6007b0ed83231be84136496795ce29e67684398ea0abb76afad8c",
"",
"reply"
],
[
"p",
"e46a04d96699f2755b88397549642a542d0672ab34975f8e6a14c90d37d3e840"
]
],
"content": "📅 Original date posted:2016-08-17\n📝 Original message:On Tue, Aug 16, 2016 at 7:14 PM, Peter Todd via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e The other serious problem - and this is a problem with smartcards in\n\u003e general\n\u003e anyway - is that without Bitcoin-specific logic you're just signing\n\u003e blindly; we\n\u003e recently saw the problems with that with the Bitfinex/BitGo hack. And even\n\u003e then, without a screen most of the hardware wallets in are still just\n\u003e signing\n\u003e blindly, with at best hard-to-use limits on maximum funds moved\n\u003e per-transaction. Also note how even hardware wallets with a screen, like\n\u003e Trezor, aren't yet able to authenticate who you are paying.\n\u003e\n\n\"Welcome to my threat model.\"\n\nIn multisig scenarios, there must be a different \"trust root\" for each key.\nFor example, storing two private keys next to each other on the same web\nserver is broken because if one key is compromised it is infinitely trivial\nto compromise the second key. Using multiple web servers is also broken if\nthe two servers are controlled by the same AWS keys or same \"help me get my\nservers back\" support email request to whatever single sign-on service is\nused. In some cases, it can be better to write software such that\ntransaction data is served at a particular location, and another\nsecurity-critical step is responsible for downloading that data from the\nfirst machine, rather than the first computer directly pushing (with\nauthentication credentials in place for the attacker to compromise) the\ndata to the second computer.\n\nI recommend using hardware security modules (HSMs). It's important to have\na public, reviewed bitcoin standard for hardware wallets, especially HSMs.\nI expect this is something that the entire industry has a tremendous\ninterest in following and contributing to, which could even lead to\nadditional resources contributed (or at the very least, more detailed\nrequirements) towards libconsensus work.\n\nInstead of signing any bitcoin transaction that the hardware wallet is\ngiven, the hardware should be responsible for running bitcoin validation\nrules and business logic, which I recommend for everyone, not only\nbusinesses. Without running business logic and bitcoin validation rules,\nthe actual bitcoin history on the blockchain could be a very different\nreality from what the hardware thinks is happening. Using a different\nout-of-band communication channel, the hardware could query for information\nfrom another database in another trust root, which would be useful for\nbusiness logic to validate against.\n\nAs for a screen, I consider that somewhat limited because you only get text\noutput (and I don't know if I can reasonably suggest QR codes here). With a\nscreen, you are limited to text output, which can compromise privacy of the\ndevice's operations and info about the wallet owner. An alternative would\nbe to have a dedicated port that is responsibly only for sending out data\nencrypted to the key of the wallet owner, to report information such as\nwhatever the hardware's transaction planner has decided, or to report about\nthe state of the device, state of the bitcoin validation rules, or any\naccounting details, etc. Additionally, even a signed transaction should be\nencrypted to the key of the device owner because a signed transaction can\nbe harmless as long as the owner still has the ability to control whether\nthe signed transaction is broadcasted to the network. It's \"separation of\nconcerns\" for transaction signing and decrypting a signed transaction\nshould be unrelated and uncoupled.\n\nAlso I am eager to see what the community proposes regarding signed and\nauthenticated payment requests.\n\n((insert here general promotional statement regarding the value of reusable\nchecklists used during every signing ritual ceremony))\n\n- Bryan\nhttp://heybryan.org/\n1 512 203 0507\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/5492f37f/attachment.html\u003e",
"sig": "64cbb0dcd89655dc677e925080a05faa73d51b8a447d0744b9035119bdfa8bdf68006105d26c66d6d88bde9930a4696c6a0704a80e411a1bfca73b5bae80602f"
}