-
Notifications
You must be signed in to change notification settings - Fork 0
/
Cryptocurrency_Security_Threats.mw
191 lines (141 loc) · 9.65 KB
/
Cryptocurrency_Security_Threats.mw
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
{{Header}}
{{Title|
title=Cryptocurrency Security Threats
}}
{{#seo:
|description=Cryptocurrency Threat Model
|image=Cryptothreats123.jpg
}}
{{crypto_hardware_wallets_mininav}}
[[File:Cryptothreats123.jpg|thumb|350px]]
{{intro|
This wiki page provides information on cryptocurrency security threats. The article discusses the use of QR codes, the best protection against theft, and multisig strategies. The page also lists specific rules to follow when using multisig for cryptocurrency storage, including the need to back up extended public keys (xpubs) and verifying the xpub of each hardware wallet used in a multisig quorum on the device it belongs to.
}}
= Introduction =
{{stub}}
= QR codes =
When scanning QR codes in context of an air gap wallet, use a QR code scanner or camera? Such as electrum running as watch-only wallet on an online computer while electrum offline
QR code scanner is supposedly working similar to a USB keyboard, i.e. technically implemented the same way a USB keyboard is implemented. What would be more trustworthy?
= Best Protection from Theft =
brain wallet + live system
Advantage: Access to spend funds stored in a brain wallet (a cryptocurrency recovery seed phrase memorized in human memory) combined with a live system (read-only) in theory cannot be stolen by stealing any storage devices (hard drives) or by offline forensics since data is never written to such devices in the first place.
Disadvantage: Higher risk of loss (forgotten seed phrase), difficult inheritance planning, no multisig.
Related: [[Live Mode]].
= multisig =
To be able to restore a multisig setup every cosigner MUST backup all <u>extended public keys (<code>xpub</code>s)</u> (also known as Master Public Keys (MPKs)) of all cosigners as well as the <u>derivation path</u>. <ref>
* https://bitcoin.stackexchange.com/questions/107450/is-there-a-multisignature-scheme-that-dont-need-xpub-backups
* https://bitcointalk.org/index.php?topic=2280898.msg23146497
* {{Twitter_link|_benma_/status/1229414020391800833|Twitter}}
</ref> For example, with a quorum of 2/4 setup:
<pre>
Location 1: wallet seed 1, master pub key 2, master pub key 3, master pub key 4
Location 2: master pub key 1, wallet seed 2, master pub key 3, master pub key 4
Location 3: master pub key 1, master pub key 2, wallet seed 3, master pub key 4
Location 4: master pub key 1, master pub key 2, master pub key 3, wallet seed 4
</pre>
It is highly recommended to exercise the multisig restoration process before relying on multisig for anything except test transactions.
{{Quotation
|quote=
Now let's talk some multisig...
|context=
https://btcguide.github.io , ({{Twitter_link|mflaxman|@mflaxman}} guide)
}}
{{Quotation
|quote=
Rule #4: Verify the xpub of each hardware wallet used in a multisig quorum on the device it belongs to.
This is not 100% mandatory - but if you're no expert - you really should do it.
If a hardware wallet doesn't support displaying the xpub, (like Trezor), it could be fine to just verify each address on it - so long as you verify consistency on all other devices as well, but I wouldn't recommend such a device for non-experts.
}}
{{Quotation
|quote=
Rule #5: Verify "receive" addresses on EVERY device of the multisig quorum.
This is especially true for at least one address (see next rule) but recommended for all. If using a device that you haven't verified the xpub of on-screen, you should verify all receive addresses on it!
}}
{{Quotation
|quote=
Rule #6: While it is best to verify each receive addresses on ALL devices in the multisig setup - you might choose to trust a specific one, verifying the xpub/ first address on all - then the rely only on the "trusted" device - ONLY IF YOU ALSO VERIFY XPUBS...
By that, I mean verify on the "trusted" hww used for general verification, that the xpubs are consistent for all cosigners.
This is needed only once with wallets like ColdCard, Cobo Vault, Bitbox02, and Specter DIY - since they allow saving the multisig xpubs on the device.
With Trezor T - you have to verify the xpubs of cosigners every time - which is why it's not recommended for that purpose - with Trezor One it's simply not possible...
So while you might use a Trezor in a multisig, I would not recommend it to non-experts.
}}
{{Quotation
|quote=
Rule #7: Do NOT use Ledger in a multisig setup! (unless you are an expert or have a very good reason...)
Ledger currently does not allow verifying multisig addresses on the device - nor displaying the XPUB on its screen.
This means you have no way to verify it was not swapped by an attacker in your multisig setup - EVEN IF YOU DO A SUCCESSFUL TEST TRANSACTION!
It is still possible for a (very) sophisticated attacker to make you think it worked, while it was him signing for you...
}}
{{Quotation
|quote=
Rule #8: For convenience, you may print out/ write down a large batch of your receiving addresses - verify all at the same time, and rely on that paper list for your day to day verification.
This is very useful for multisig! - where devices might be distributed in various places.
}}
{{Quotation
|quote=
Rule #9: Multisig change verification should be the same as with Rule #3 - on the device at the time of signing.
Popular devices (besides Ledger as said), can verify that the address you send from and the change address used belong to the same multisig wallet (from same xpubs).
If they fail to verify the change address - they will show it as a standard, independent, recipient - in that case YOU SHOULD NOT MAKE THE TRANSACTION.
This is valid for both single sig and multisig! (although even more relevant for the latter).
}}
{{Quotation
|quote=
Please note: Some things here might not be fully accurate for the expert user (especially around multisig address verification), but for the less advanced users' sake, I have tried to be on the safe side when things get tricky...
That said, if you see inaccuracies or mistakes (or just have questions), please comment!!
Also check out some more info on multisig setups over at:
|context=
https://btcguide.github.io , ({{Twitter_link|mflaxman|@mflaxman}} guide)
}}
= Timelocks =
== Introduction ==
Prevention of spending coins until a defined time has lapsed to avoid hasty and coerced transactions.
Has [[#Complexity Risk|Complexity Risk]].
== Blockchain Based Timelocks ==
This is a uncommon feature.
{{Quotation
|quote=
It is not advised to lock up bitcoins into the far future because it takes on risk of the bitcoin network changing. For example, if there were an ECDSA or RIPEMD160 algorithm break that made any coins spendable with a few months of CPU time, the network might need to to prohibit moving old unspent coins after some transition, but long locktimed coins could not make such a transition.
|context=https://en.bitcoin.it/wiki/Timelock#Far-future_locks
}}
{{Quotation
|quote=
The problem I see with time-locking coins is, if the keys are compromised, you'll find yourself in a race with an attacker when the coins are unlocked. The attacker might even set an enormous fee to get in a block before you.
|context=
https://www.reddit.com/r/Bitcoin/comments/7e0ums/best_way_to_timelock_bitcoin_to_hodl/dq1qtud/?utm_source=reddit&utm_medium=web2x&context=3
}}
== Software Based Timelocks ==
Less trusted employees with limited permissions to spend cryptocurrency could be prevented from spending until a time defined on the trusted server has lapsed. Since the trusted server enforcing the timelock is by definition trusted, this does not seem possible outside of a multi user or institutional level cryptocurrency custody.
= whitelists =
Self-custody cryptocurrency wallets, enforced using blockchain features: Conceivable with smart contracts to permit spending to defined recipients only such as perhaps a centralized cryptocurrency exchange. But how could the whitelist be updated if need be? Unpopular. No known example implementations.
Self-custody cryptocurrency wallets, enforced using software: Similar to [[#Software Based Timelocks|Software Based Timelocks]].
Funds on centralized exchanges: withdraw whitelists make sense, specifically if withdraws are only allowed to high security (self-custody) wallets.
Has [[#Complexity Risk|Complexity Risk]].
= spend limits =
Similar to [[#whitelists|whitelists]].
= Complexity Risk =
For example the parity blockchain based multisig locked Ethereum (ETH).
{{Quotation
|quote=
Multi-sig wallets have been frozen which are estimated to hold roughly $150 million in Ethereum.
|context=
https://www.zdnet.com/article/ethereum-user-accidentally-exploits-major-vulnerability-locks-wallets/
}}
At time of writing (2021) these funds would be even more worth in fiat money equivalent, has not been resolved, a previous vote (#EIP-999) to resolve it failed.
= Smart Contract On Chain Multisig vs Threshold Signature Wallets =
Smart Contract On Chain Multisig is very much Too complex. [https://web.archive.org/web/20210922113708/https://www.springworks.in/blog/parity-multi-sig-wallets-funds-frozen-explained/ Millions worth of ETH was and still is frozen in the parity multisig smartcontract.]
https://web.archive.org/web/20220909050353/https://sepior.com/blog/advanced-mpc
https://images.squarespace-cdn.com/content/v1/5f62f501406011026c1a26f2/1627682581701-H5FUQNWFU946744LHAR9/Custody+Wallet+Comparison+Table.png?format=1500w
https://web.archive.org/web/20221019171209/https://sepior.com/blog/top-5-reasons-threshold-signature-wallets-are-better-than-multisig
= Further Reading =
<div style="column-count:2;-moz-column-count:2;-webkit-column-count:2">
* [[Hardware_Wallet_Security|Cryptocurrency Hardware Wallet: Threat Model]]
* [[Social_Engineering|Social Engineering and (Spear) Phishing]]
* [[Bitcoin]]
* [[Electrum]]
* [[Monero]]
* [[Ethereum]]
</div>
= Footnotes =
{{reflist|close=1}}
{{Footer}}
[[Category:Documentation]]