{{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 the context of an air gap wallet, use a QR code scanner or camera? For example, Electrum running as a watch-only wallet on an online computer while Electrum is offline. A QR code scanner is supposedly working similarly 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) cannot, in theory, 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, and no multisig. Related: [[Live Mode]]. = multisig = To be able to restore a multisig setup, every cosigner MUST back up all extended public keys (xpubs) (also known as Master Public Keys (MPKs)) of all cosigners as well as the derivation path. * 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}} For example, with a quorum of 2/4 setup: 
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
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 elapsed to avoid hasty and coerced transactions. Has [[#Complexity Risk|Complexity Risk]]. == Blockchain Based Timelocks == This is an 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 multi user or institutional level cryptocurrency custody. = whitelists = Self-custody cryptocurrency wallets, enforced using blockchain features: Conceivable with smart contracts to permit spending only to defined recipients, 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: Withdrawal whitelists make sense, specifically if withdrawals are only allowed to high security (self-custody) wallets. Has [[#Complexity Risk|Complexity Risk]]. = spend limits = Similar to [[#whitelists|whitelists]]. = Complexity Risk = {{IntroLike| You can make your setup so complicated that you lose your funds because of complexity risk. }} Quote [https://en.wikipedia.org/wiki/Andreas_Antonopoulos Andreas Antonopoulos]. {{quotation |quote=Different audiences, different groups of people are going to have different risk models and they are also going to have different tolerance for technical complexity. The important thing to realize here is that '''technical complexity is part of the risk model. Meaning that if what you are trying to do with security is more technically complex than your level of skill you introduce a very serious risk, that you will lose your crypto. Not because it is stolen but because your ambition for technical excellence exceeded your skill level for technical execution and you frankly messed it up.''' This applies to every level of technical expertise. There is always a higher level of security you can achieve by adding a bit more complexity. Security is not an on, off thing. It is not “It is secure” or “It is not secure.” There is no gold standard for security that applies for everyone. There is a sweet spot where the risks that you face from external factors, from the adversarial model that you have identified where you understand who might be after your crypto and under what circumstances they might access it. The risk model you have for resilient long term storage and also you should be thinking about inheritance and how your loved ones will deal with this is if something happens to you. The risk model you have for simple loss which includes a fire, a flood, an environmental disaster, a problem with your home or the other areas where you store keys, termites that eat through your paper backups or whatever else the risk model might be. Then you balance against your technical skill and you find which of these risks you can eliminate in a way that both you and the people you will designate as helping your loved ones recover your crypto if something happens to you can execute that technical plan flawlessly. That’s the sweet spot. |context=[https://btctranscripts.com/andreas-antonopoulos/2019-02-01-andreas-antonopoulos-hardware-wallet-security source] }} Quote Andreas Antonopoulos. {{quotation |quote=For most people the simple Stone Age technology of paper, pencil with a little modern addition of a laminated sheet so you don’t get moisture damage and a simple cheap, plastic envelope that makes it obvious if someone has peeked at your seed is sufficient. You don’t need to go to the extremes and the technical complexity of Glacier protocol. Here’s the problem. When people give advice like this, when they say that if you don’t achieve this level of “I feel confident” you are not secure, what they are doing is not encouraging people to achieve better security. They are either pushing people to try to overextend their technical skill and making them at risk of losing their crypto due to a variety of technical problems or they are pushing people to go to custodial exchanges. The vast majority of people having read things like the Glacier protocol will go “ I don’t even know.” They will either try to do it without understanding it fully, be very uncomfortable with their knowledge and probably lose their crypto because they messed it up or they are just going to give up on the first page and move their crypto into custodial storage and let someone else take care of the security. |context=[https://diyhpl.us/wiki/transcripts/andreas-antonopoulos/2019-02-01-andreas-antonopoulos-hardware-wallet-security/ source] }} 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 the time of writing (2021), these funds would be worth even more in fiat money equivalent. This has not been resolved, and 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 Sepior blog on advanced MPC] [https://images.squarespace-cdn.com/content/v1/5f62f501406011026c1a26f2/1627682581701-H5FUQNWFU946744LHAR9/Custody+Wallet+Comparison+Table.png?format=1500w Custody wallet comparison table] [https://web.archive.org/web/20221019171209/https://sepior.com/blog/top-5-reasons-threshold-signature-wallets-are-better-than-multisig Sepior blog on threshold signature wallets] = Further Reading =
* [[Hardware_Wallet_Security|Cryptocurrency Hardware Wallet: Threat Model]] * [[Social_Engineering|Social Engineering and (Spear) Phishing]] * [[Bitcoin]] * [[Electrum]] * [[Monero]] * [[Ethereum]]
= Footnotes = {{reflist|close=1}} {{Footer}} [[Category:Documentation]]