Ransome attack in hardware wallets

This has been patched so please make sure you are running up to date firmware. Another reason I like offline wallets.

5 Likes

Very cool read. I had no idea that master key (passphrase) is not the only thing you need to recover your key… Crypto seems to always find a way how to make me scarred abotu the security of my funds :smiley:

Nice read. I’ll comment that I never have to worry about people ransoming my wallet that I carry cash in because we all know that the overarching concern with crypto and having full adoption is security and convenience. Can’t have convenience if someone can lock away your cash. If you need cash to buy a new computer to restore and that cash is on a hardware wallet or desktop wallet, you’re forced to use someone else’s computer to get your cash which means they have an opening to see/view your key or you have to borrow funds to get your funds. The last alternative is paying the ransom which may not be a good idea.

To be precise, it is not patched in a way that this attack is prevented. It still can and probably will happen sooner or later. But because Ledger thought it was a good idea to limit the key space to 5 million, is will be easier to brute force your way to your own funds after such an attack happens. But I think the majority would be overwhelmed and would just pay the ransom to get to the funds.

As the author suggests it would be the best to show the key index in the Ledger app, when a new address is generated. Although that’s not particularly urgent I think this should be considered and I tagged @SebastienGllmt a few days ago about it.

5 Likes

I had no idea, but that is pretty much the case generally :wink:

I think the only time I have ever seen “derivation path” is when connecting Nano s to Ethereum through MEW. And even then it shows up on the PC not on the Nano s.

Derivation path is something different. It’s a way to derive different private keys for different coins from the same seed words.

I am not sure showing the index helps, let’s say you are given the index number… what are the chances you can tell it is too large or remember it after pushing the accept button?

Ledger’s solution of displaying a warning and limiting the search space to 5 million seems a preferable one as it would prompt the user to deny requests for large indexes and seek help or find a safer computer to conduct their transaction.

You are right, but the index should not be displayed to memorize it.

First, a sudden jump in the index would be an indication that the PC has been compromised.

Second, a 4 million (or way lower) index would be still enough to do this attack without triggering the warning.

OK. So "Key derivation path " is not the same thing. :bulb:

You may be right.

I thought the logic for the trigger and the max search space were not linked, meaning you could trigger the warning even if your pc asked you to jump the index by some random number above your last index level, not necessarily 5M.

Limiting search space to 5M addresses would then be the second level of protection to make recovery easier should the first line of defense be breached.

Great article! Thanks :slight_smile: I also updated this Wikipedia hardware wallet article with a link to this information.

Nice read, security and adoption are the biggest challenge for the crypto community !! keep up

I don’t see why there’s much need for anything other than this. If the HW is asked for an index even +50 from the current highest index, then it should just put out an error that a bad actor may be trying to do nefarious things. If for some reason an app that interfaces with the HW isn’t programmed well and doesn’t do highest index + 1, well then that’s just what the app developer needs to deal with.

Or is there some use-case for having sized gaps between indexes? I at the very least can’t think of any.

2 Likes

Yes your are right. If you using only this one hardware wallet with only this one wallet you should be fine.

But as far as I understand it, gaps will occur if you create for some reasons addresses and then don’t use them. Maybe with different wallets.

Lets say I have a ticket shop and for every order a new address is generated. Maybe live on demand or in bulk up front.

Also I could generate addresses when someone clicks the order button, but then he decides to not send ADA to the address, because he no longer wants the product.

Maybe vanity addresses. (are they still a thing?)

Btw: it’s not 100% clear to me if Ledger implemented this in the firmware or in their Ledger apps like Bitcoin and what not, and if other developers need to fix this in their apps.

Hmm, I’m not sure how practical it would be for ticket shops to use a HW instead of a hot wallet and so whether such cases will actually matter in reality, but point taken. Though if for some reason such a thing was required, then it could probably work to have a local index cache on the HW which stores the highest index, even if that index never had any transactions to it.

Of course I made that up. You can’t store the index that’s the main problem of this attack.

It has to work without, otherwise you can’t for example have multiple Nanos with the same seed.

Ok, it looks like every Ledger app need to handle this by it’s own:

(…)Unfortunately, due to the nature of the vulnerability, each wallet app must be patched individually. Although Ledger has fixed their first-party wallet apps, third-party apps may still be vulnerable. (…)

This was the pull request: https://github.com/LedgerHQ/ledger-app-btc/pull/90