JWWeatherman / yeticold

https://yeticold.com
Other
67 stars 24 forks source link

Similar Project - Tordl Wallet Protocols #66

Closed fresheneesz closed 3 years ago

fresheneesz commented 4 years ago

Hey JW, looks like we started our projects literally within a month of each other. I created The Tordl Wallet Protocols to give people an easy and flexible way to create secure bitcoin wallets. I posted about it recently and Ruben Somsen told me about your project.

I'd love to collaborate. Looks like you're putting together a small website and companion program intended to make the creation of a secure wallet easy, kind of similar to what the Glacier Protocol does. I love the idea. I'm wondering how we might be able to collaborate. I would like to get a deeper look into what Yeti does. I agree with issue 52 that its a bit hard to learn how Yeti operates, since most of the operation is controlled by custom python scripts that manage the textual content in the github repo. If I were to review the operation of one of the three wallets, how would you advise the best way to do that would be?

I also have a couple questions from your FAQ:

people believe that they are safe even when they plug them into insecure devices like a daily work laptop. This is false

I'm curious about that. What are you saying is false? I'm not aware of any hardware wallets that are insecure against USB-interface-based attacks.

With yeti all important security functions are handled by bitcoin core and it has the best developers and the largest number of people checking for errors.

However, it still requires the users to trust the creators and maintainers and reviewers of Yeti.

JWWeatherman commented 3 years ago

Hey man, so sorry i missed this @fresheneesz for so long. Would love to collaborate. Hit me up on our slack or twitter DMs.

https://join.slack.com/t/yeticold/shared_invite/zt-hisfxrra-BZzrYCDnqFv6whxVn~6FQQ

Robert just cranked out a great doc that covers the problems with hardware wallets here: https://twitter.com/RobertSpigler/status/1344411952186089472?s=20

And you don't need to trust yeti because everything is in python and all critical tasks are handled by bitcoin core. So for about $50 you can hire a python dev to review the code and confirm it isn't doing anything weird and all critical tasks are handled by core. This is why we went with a script rather than compiled code.

I'm going to close this, but hit me up.

fresheneesz commented 3 years ago

No worries. I'll hit you guys up on slack.

you don't need to trust yeti because everything is in python and all critical tasks are handled by bitcoin core

Well, what I mean is that if someone is following the instructions without expecting to fully understand all the implications and reasons that those instructions are done, if a malicious actor could insert instructions into the Yeti write up that someone will follow, that cause lead to loss of funds or other attack risks for that attacked person. In order to know that you're reading the right Yeti instructions, you need to trust that Yeti has not been compromised. This requires trusting Yeti to do their security right and to not be malicious themselves. Do you disagree that if the people controlling the releases of Yeti were malicious, that they could trick people into doing insecure things with their wallet?

Robert's write up is interesting and is a good documentation of the many problems that have been found in hardware wallets. I would have actually liked for this to be split up into two articles: one talking about prior and existing vulernabilities, and one talking about fundamental tradeoffs. As it stands, I'm more interested in the theoretical limits of HWW security and not so much the various bugs that have affected and are affecting them.

Some responses to Robert's write up, since I don't know where else to put it:

for Trezor devices, the passphrase is entered on the computer and not confirmed on the device

This is true for Trezor One, but not Trezor T.

the 15btc can be ransomed from the user, or profit shared with a miner.

I don't understand this part. I can see how malicious software can trick someone into sending multiple transactions to their intended recipient. However I don't see how funds can be held for ransom by the malicious party.

But also, how are the airgapped machines used in Yeti not vulnerable to this problem. Since they don't have internet access, they need to rely on an internet connected computer that could be compromised to actually interact with the blockchain. So if that machine is compromised, are you just as boned? What am I missing?

as bitcoin-specific hardware, hardware wallets would still represent serious risks of supply chain attacks, which ultimately are impossible to fix.

This is also true of any hardware you'd run a machine on. Imagine a world where everyone uses Yeti. Why would theives not put malicious hardware on generic machines when they could if everyone's using bitcoin? Perhaps the cost/benefit ratio would be slightly higher, but not to a degree much beyond what it would be for hardware wallets.

if you do not verify the physical hardware, it is game over

What's the alternative? Its not possible to verify hardware at all. This is true for any airgapped machine you might create.

using multiple insecure devices does not magically create a secure scheme

This point is particularly ill supported. Multisig when properly done does indeed eliminate any single point of failure. Using multisig on multiple different devices from different manufacturers makes it exponentially more unlikely for an attacker to be able to successfully attack you via relevant attacks like supply chain attacks, because malicious coordination between multiple entities and multiple supply chains is incredibly difficult. One key being compromised in a 2-of-3 multisig setup won't lead to loss of funds. Multisig is one of the very very few security things in this world that isn't only as strong as your weakest link. A 2-of-3 wallet is in fact as secure as its 2nd least secure key. With bitcoin vaults in the future, this security can go even higher.

Memorizing passwords is also absolutely not recommended.

Isn't memorizing a password is exactly the use case for a password. If you don't have to memorize it, a longer secret is better (ie more future proof). Yes humans generally create bad passwords and memory sucks, but if part of your security instrucitons teaches you how to create a secure password and how to ensure you remember it long term, this reduces that likelihood immensely.

The final defense of hardware wallets that I often hear is that they have a reduced attack surface.

I have to say much of Robert's write up has a couple disingenuous moments like this. I would be more convinced by a treatment of hardware wallets that was a little less openly hostile. This point basically reads like "Yeah, they're right that HWWs have a lower attack surface, but I'm not going to admit it". Instead of saying "yes, HWWs do have far lower attack surfaces than a linux desktop machine" he instead says "this does bring up some good points" and "Yeti solves this". A shameless plug could be excused here if credit to HWWs was given where it was due.

Besides Yeti, there currently is no other secure, offline, airgapped, HD multisig wallet built on top of Bitcoin Core with minimal software dependencies

Is the Glacier Protocol not another one? Which of those attributes is it missing?

In any case, I'm not convinced that HWWs are as lost of a cause as Robert thinks. However, I'm of course willing to entertain the possibility that I'm wrong and I certain support people's right to make different choices than me. I would certainly like to offer both choices (HWWs and airgapped machines) to whoever feels more comfortable with each in the work that I do. I'll see you on slack!

Rspigler commented 3 years ago

I don't understand this part. I can see how malicious software can trick someone into sending multiple transactions to their intended recipient. However I don't see how funds can be held for ransom by the malicious party.

This is because the bitcoin stolen from the user is sent as a fee in this vulnerability (the 'segwit' vulnerability).

how are the airgapped machines used in Yeti not vulnerable to this problem

Yeti is not vulnerable to this problem, because we don't tell users that they can use a malicious machine to broadcast transactions, and to run their node on (which I demonstrate is a false statement sold by HWW's). We also take our users through steps to secure their online device.

This is also true of any hardware you'd run a machine on

Um, no. Attackers aren't omipotent with unlimited funds. If they want to attack bitcoin users, the ROI is 1,000,000% better on bitcoin-specific hardware than it is on generic hardware, which is mostly just run by random people who take college courses or email their grandparents and try to pay their bills.

Its not possible to verify hardware at all.

You're basically right. That's why it's so important to purchase generic hardware, where the risk of supply chain attacks are much lower. Use hardware from different manufacturers, in a multisignature setup. In our more secure Level of accounts, we recommend PowerISA hardware, which is open source. Unfortunately it is not generic, however it is not bitcoin specific.

This point is particularly ill supported. Multisig when properly done does indeed eliminate any single point of failure

I never argue against multisig (in fact, I argue /for/ it through the article, and multisig is what Yeti was built for). My claim is, is that I clearly lay out the proof that each individual device is not secure. Relying on any two devices then, while perhaps marginally better, is still not a secure scheme. Use multisig with secure devices, and that is a great idea!

Isn't memorizing a password is exactly the use case for a password.

It is universally recommended to not rely on your memory for bitcoin storage. Far more people lose their funds due to memory issues than hacks. But you can protect against both (security w/ redundancy) by using multisignature with unencrypted backups.

I have to say much of Robert's write up has a couple disingenuous moments like this

Please let me know where I've been disingenuous. I wrote that "...it is true that HWWs are not a fully fledged computer, running the nearly 30 million lines of code that is the Linux Kernel, with a complete GRUB bootloader, coreboot BIOS, and all peripherals (including firmware)". That is the argument for the reduced attack surface, and it is true. However, I also write that "this is a very elementary of viewing attack vectors". You can't honestly say a HWW has a reduced attack surface if it can't correctly validate change addresses and has a centralized dev process. We also offer solutions for the increased attack surface of a laptop (https://github.com/JWWeatherman/yeticold/issues/82).

Is the Glacier Protocol not another one? Which of those attributes is it missing?

Glacier Protocol required address reuse (was not an HD wallet). Also was not secure because did not use a full node.

fresheneesz commented 3 years ago

If they want to attack bitcoin users, the ROI is 1,000,000% better on bitcoin-specific hardware than it is on generic hardware

Today I think you're right. But, let's think of a bitcoin future which might come sooner rather than later. If everyone's using bitcoin using Yeti, then one could expect that a large fraction of general purpose hardware of various types would interact with some bitcoin-related process. This fraction could be as high as 100% for some types of hardware. For hardware that's so general its in all kinds of machines, you'll have people's private machines which are very likely to interact with people's money, and you have work machines which woudln't, and you have business machines which probably also mostly don't, but some certainly would. So in a truely bitcoin world, its not unreasonable to imagine that for a particular model of general purpose computer hardware, it could easily have a 30%+ chance of interacting with bitcoin data or bitcoin processes in a way that could compromise something. So the ROI in such a case would not be 1 million % better, but would instead be 200% better.

And we can also imagine a world where people finally understand self custody of keys and everyone has a security device that they not only use for bitcion but also to sign into websites and sign into their computers and identify them in other ways. Such devices could eventually become ubiquitous and not all would be used for bitcoin.

Relying on any two devices then, while perhaps marginally better, is still not a secure scheme

It depends what you mean by "a secure scheme". If devices A and B have a 10% probability of being successfully attacked in a 10 year time, its very likely (barring identical design flaws or shared code) that a 2 of X multisig wallet would have a far less chance than 10%^2 = 1% of being compromised. Why far less than 1%? Because not only would they both have to be attacked, but they would have to both be attacked at the same time in a coordinated way. This might be more like the chance that both are attacked in the same day, which would be (10%/10/365)^2 = 0.000000075%. So barring the two HWW companies actually conspiring, using two separate devices in a multisig setup is quite a bit more than marginally better IMO, far more secure than any setup with a single point of failure. Add a 3rd and your chance of a 3 way conpiracy attack is basically nonexistent.

It is universally recommended to not rely on your memory for bitcoin storage

I agree, but if you're not trying to use your memory, you shouldn't be using a passphrase in the first place. A longer seed would be much more secure, wouldn't it?

A passphrase still can have a place in a secure wallet setup, as long as you consider the loss of the passphrase in your redundancy plans. Eg, if you have a 3 of 5 setup with 2 keys secured by passphrases, you can still recover even if you've forgotten the passphrases. If you want more redundancy, you can protect fewer keys with passphrases. But there isn't anything much more secure than a truly random passphrase only stored in your brain (at least not in the foreseeable future Ian Banks ; ).

You can't honestly say a HWW has a reduced attack surface if it can't correctly validate change addresses and has a centralized dev process

You absolutely can say that HWWs have vastly reduced attack surfaces. But in disagreements like this, I always want to make sure it isn't an argument of semantics. By "attack surface" I mean the amount of different peices and parts that need to be checked for security. I do not necessarily mean the number of ways that something can be attacked. Saying that something has a lower attack surface is not the same thing as saying it has fewer potential attack vectors, at least not in my understanding of the term. Would you agree that a HWW does indeed have vastly fewer "things that need to be checked" in order to verify its security? As opposed to the aforementioned 30 million lines of code in ubuntu from thousands of different sources, hundreds/1000s of parts in a laptop, numerous input and output methods, and supply chains. If your answer is "no" my question to you is: what are all these things that are making up the difference in attack surface?

But beyond that, I don't know why having a centralized dev process puts a HWW at a disadvantage in comparison to laptops, which also have centralized dev processes.

We also offer solutions for the increased attack surface of a laptop

I absolutely agree that multisig across devices improves the situation greatly. However its not exactly solving the problem of increased attack surface, but rather working around it. The attack surface remains huge, but multisig brings up the difficulty of attack so much that it makes up for the huge attack surface.

can't correctly validate change addresses

Why can a HWW not correctly validate change addresses?

Glacier Protocol required address reuse (was not an HD wallet).

Ah.

Also was not secure because did not use a full node.

I'm curious about this. My understanding is that light nodes like Electrum are quite secure Iin terms of accepting payments and knowing when you've been paid), however they just aren't as private. What am I missing?

Rspigler commented 3 years ago

let's think of a bitcoin future which might come sooner rather than later....it could easily have a 30%+ chance of interacting with bitcoin data

This is likely atleast a decade away, and even then, there are so many different laptop vendors with crazy high production that your calculation of 30% is far too high. Even so, you still proved my point. General computing devices are more secure from supply chain attacks, even if you think they are 'just' 3x as secure.

If devices A and B have a 10% probability of being successfully attacked in a 10 year time

HWW's have about a 90+% probability of being attacked in a 1 year time. This is demonstrated through their historical vulnerabilities. There hasn't been a year yet AFAIK where an embarrassingly high number of vulns have not been published. 90%^2=81%. Congrats, your private key management is still terrible. Keep in mind these vulnerabilities typically last for long periods without fixes, HWW's have centralized development teams with limited peer review, they don't work well with multisig wallets, etc (https://robertspigler.wixsite.com/blog/in-defense-of-my-attack-on-hardware)

By "attack surface" I mean the amount of different peices and parts that need to be checked for security. I do not necessarily mean the number of ways that something can be attacked. Saying that something has a lower attack surface is not the same thing as saying it has fewer potential attack vectors, at least not in my understanding of the term.

This hurts my brain, and I don't understand the differentiation. Yes, HWW's aren't a full computer, and they run less lines of code. But there's no reason to be proud of that, if they do so in an insecure manner. Otherwise, I feel like I'm debating with a lawyer. Don't we have the same goal of storing bitcoin in the most secure way? If attack surface =/ attack vectors, this seems like a really meaningless point.

Why can a HWW not correctly validate change addresses?

BitBox02 is the only one that might finally be getting there now. But I suggest reading my article I linked above for the history and analysis of the serious issues with HWW's

My understanding is that light nodes like Electrum are quite secure

Bitcoin requires a full node. Without it, you can't know whether or not you are receiving fake bitcoin, if inflation has occurred, the block reward schedule is being followed, etc. It is the only way to use Bitcoin trustlessly. Using a light node trusts the miners.

fresheneesz commented 3 years ago

This is likely atleast a decade away

I think thinking about the future is important. But thinking about today is also important. In any case, I agree that general purpose hardware is significantly less cost effective to attack today.

HWW's have about a 90+% probability of being attacked in a 1 year time.

That is saying something completely different than what I'm saying. I was giving a hypothetical probability that any individual instance of a hardware wallet will be attacked. Eg, my personal hardware wallet has some probability of being attacked. That's very different than saying a vulnerability will be discovered in a particular model of hardware wallet. So while the probability that a hardware wallet will have a vulnerability discovered is relevant, it is not the number of import when discussing multisignature security. For a multisig wallet to be compromised, an attack has to actually attack both wallets in some short period of time. The probability of a vulnerability existing on one HWW at the same time as another vulnerability on another HWW is far higher than the likelihood your multisig setup is to be compromised.

Keep in mind these vulnerabilities typically last for long periods without fixes

It sounds like you're very knowledgable about the history of HWW vulnerabilities. How many vulnerabilities would you say aren't patched within 6 months?

Congrats, your private key management is still terrible.

I would appreciate it if you dialed down the snark, please. I'm trying to have a serious conversation with you and you're being a bit obnoxious. I'm not trying to crush your argument to win a debate trophy. I'm trying to learn from you why you think hardware wallets are bad, and I hope you're also trying to learn why I think hardware wallets are good. On Twitter, you explicitly asked for people to discuss this with you, but the feeling I get is that you're being somewhat short and impatient with me. Without both sides attempting to learn from the other, this conversaion will be fruitless. I like my conversations to be fruitful. So please, there's no need to be defensive.

HWW's have centralized development teams with limited peer review

So does commodity hardware. So this point isn't relevant.

they don't work well with multisig wallets

By what definition do you mean "don't work well"? I can create a multisig wallet with Coldcard, Trezor, and Bitbox (and Ledger if I wanted to, which I don't).

I don't understand the differentiation... But there's no reason to be proud of that, if they do so in an insecure manner.

If a hardware wallet comes along that has a decentralized development team with a good amount of peer review, that would be something to be proud of, no? Even if the resulting hardware wallet still ends up having vulnerabilities? Good attributes of something are still good attributes desptite that something having other attributes that aren't as good.

The differentiation is that the attack surface of something is the number of points where an attack vector could potentially exist (this is the "number of things to check" that I mentioned). A system can have a large attack surface and still have no attack vectors. By contrast, something with a low attack surface could have multiple attack vectors per attack point. Low attack surface is one of many attributes of a system that comprise its security. A low attack surface is not sufficient for the system to be secure, neither is using commodity harware, neither is any single thing. Security depends on the whole, it depends on all the attributes of the sytem you're talking about. So I do believe low attack surface is in fact something to be proud of.

Otherwise, I feel like I'm debating with a lawyer.

I don't think I'm being a lawyer by saying that I think most people are using the phrase "attack surface" differently than you are. You're certainly using it differently from how I use it.

But I suggest reading my article I linked above for the history and analysis of the serious issues with HWW's

I have already read you're entire article. However unless you actually say what you're talking about or refer to something specific in your article, I don't know what you're talking about. It sounded to me like you were saying that no hardware wallet can properly validate change addresses. But now I think maybe you just meant a particular hardware wallet at a particular time.

Using a light node trusts the miners.

You're right. I agree that light nodes are not as secure as using a full node. But "not as secure" is not the same statement as "not secure". There are levels, and using a light node to store. Additionally send your bitcoin is no less secure than using a full node. Its only when accepting bitcoin that your security is lower. Since the primary part of a cold storage protocol is to store coins for the long term, using a light node can be a quite secure way to do that.

fresheneesz commented 3 years ago

I'm also curious what you think of https://specter.solutions/ - open source DIY harware wallet using commodity hardware.

Rspigler commented 3 years ago

The probability of a vulnerability existing on one HWW at the same time as another vulnerability on another HWW is far higher than the likelihood your multisig setup is to be compromised.

At Yeti, we prefer to set up a protocol that protects our users from as many possible attacks as possible, even targeted attacks. If there is a possible vulnerability (and there are many overlapping ones across HWW vendors), we are not just going to tell our users to cross their fingers and hope statistics are on their side.

How many vulnerabilities would you say aren't patched within 6 months?

I'd have to go do further research, but I know there's currently multiple vulnerabilities in existing HWW's that remain unpatched, like Trezor's 5 minute physical chip attack, Ledger's SE attestation, Coldcard's supply chain attack...Again, these are all discussed in my article.

I would appreciate it if you dialed down the snark, please

It's just a bit annoying to me that I have to rehash points I've already written. I don't think you've read my article, and this is a waste of my time.

Re: Attack Surface. End of Section 3.0

The final defense of hardware wallets that I often hear is that they have a reduced attack surface. While it is true that HWWs are not a fully fledged computer, running the nearly 30 million lines of code that is the Linux Kernel, with a complete GRUB bootloader, coreboot BIOS, and all peripherals (including firmware) – this is a very elementary way of viewing attack vectors. Threat analysis is so much more than just counting lines of code. The in depth analysis I just performed in the previous sections clearly demonstrates this. However, this does bring up some good points, like the fact that the Linux Kernel is monolithic and doesn’t have great hardening [84]. Yeti (the solution I propose in the next section) solves this not by reverting to poorly designed hardware wallets, but by recommending a combination of secure operating systems with certain special attributes, and by running them in a multisignature offline setup.

Why can a HWW not correctly validate change addresses?

Read section 2.2.1, lists many instances

By what definition do you mean "don't work well"? I can create a multisig wallet with Coldcard, Trezor, and Bitbox (and Ledger if I wanted to, which I don't).

No, not securely. Read the 2nd and 3rd paragraph of Section 3.0 (and citations).

If a hardware wallet comes along that has a decentralized development team with a good amount of peer review, that would be something to be proud of, no?

I discuss this word for word in Section 2.3 - Inherent Architectural Issues:

Let’s continue to make assumptions, for the benefit of hardware wallet vendors. All of the vulnerabilities, remote and physical, have been fixed. No more will occur. You are able to purchase and receive the device (somehow) without giving away personal information. Somehow, they gain about a hundred developers, a decentralized development process, a strong community (that took Bitcoin 10 years to build), and better cryptographic libraries (that can run on restricted MCUs). They switch to QR codes. They instruct users to only use the device with a segregated, Bitcoin-only computer as a full node. (At this point, I’m not sure what benefits the HWW has for the user). Even if this all were true, as bitcoin-specific hardware, hardware wallets would still represent serious risks of supply chain attacks, which ultimately are impossible to fix.

fresheneesz commented 3 years ago

It's just a bit annoying to me that I have to rehash points I've already written. I don't think you've read my article, and this is a waste of my time.

If you think this is a waste of your time, why even bother asking people for comment on your writing? Its insulting to me that you lash out and accuse me of lying about having read your whole article, which I did in fact do. I think you're right, this was a waste of time.