Hardware Wallet Passphrase Encryption

[nopara73]

Originally I was confused why hardware wallets call it passphrase, because to my knowledge passphrase was the thing that you add to your mnemonic words and I thought they use this as a password, but I realized they call it passphrase, because it's actually the thing what they add to their mnemonic words.

Reason #1 - Dangerous (Lost Password Inevitability)

The consequence is that whatever passphrase the user types in, it is valid, there's no way to verify if the passphrase is really what the user wanted or not or if there's even a passphrase or not.

In Wasabi we long struggled users losing their passwords and we implemented various strategies to avoid that and lately, despite the tremendous user growth we didn't get any lost password or "wasabi stole my money" support requests: zkSNACKs/zIPs#44

Passphrase encryption would bring back all the issues. Even worse, because the passphrase can't be validated.

Reason #2 - UX Nightmare

This was reason #1. Reason #2 is that it'd bring a huge UI clutter and usability issues for the 99% of people who don't use passphrase anyway. (Because we cannot figure out if passphrase is needed or not.) In Trezor T, the user can use passphrase if he wants on the device side, although even then I wouldn't recommend it: If the user later changes his mind, he wouldn't be able to setup a different passphrase wallet through the UI, because we remember the master fingerprint in the wallet file (and the passphrase changes that) so he would have to manually delete the wallet file. There's almost zero good UX that could handle this.

For these reasons, Wasabi won't implement PC side passphrase handling. It's dangerous, adds a huge amount of friction to the UX and unnecessary.

Note #1 - BitBox

Note this does not affect BitBox, because requires passphrase handling, so we would be able to detect this: if we find a BitBox, then passphrase would be required to type. This wouldn't ruin the user experience the rest of BitBox users, because they must be aware that passphrase is required. (Or is BitBox validates the passphrase? If not, then it may be even smarter to just a constant to the source code that'd be the all-time BitBox passphrase. So we could handle everything in the background.)

Note #2 - PC-side PIN Handling

Note this does not affect PC-side PIN handling. We can support that, because we can detect if the hardware requires PC-side PIN or not. (Trezor One and Ledger Nano)

Note #3 - Device-side Passphrase Handling

Note that device side passphrase handling, like what Trezor T does, will still work, but it's still dangerous. (See Reason #2.)

[achow101]

Or is BitBox validates the passphrase? If not, then it may be even smarter to just a constant to the source code that'd be the all-time BitBox passphrase. So we could handle everything in the background

The passphrase is set by the user on device setup and stored on device. You should not use a constant password.

Note that by doing this, some users will not be able to use their Trezor Ones or Keepkey's with Wasabi.

[nopara73]

The passphrase is set by the user on device setup and stored on device. You should not use a constant password.

Ok, so we have to show up the passwordbox when we encounter a BitBox. BitBox users know that passphrase is necessary.

Note that by doing this, some users will not be able to use their Trezor Ones or Keepkey's with Wasabi.

I can't follow. If Trezor One/KeepKey validates passphrase (and stored on the device) then we don't have an issue, because we can detect that so we know when to fire up a passwordbox. If they don't validate passphrase, then we go with the default empty string, so they will be able to use it.

Or do you mean they won't be able to use their old wallets with Wasabi? Because that's already a given, since it's unlikely they'd use their bech32 keypaths anyway, where Wasabi is working.

[achow101]

Or do you mean they won't be able to use their old wallets with Wasabi?

I meant this.

[MelbourneDeveloper]

@nopara73 it's interesting that you bring up passphrases. Just the other day, a user reported that they couldn't use Hardfolio because they couldn't enter their passphrase. I have a feeling that Trezor Passphrases are becoming more popular in order to avoid the "$5 wrench attack". https://wiki.trezor.io/Passphrase . I ended up adding passphrase functionality to Trezor.Net (MelbourneDeveloper/Trezor.Net#23), and rolling out the change to Hardfolio.

You may or may not consider the passphrase to be dangerous or a good, or bad idea, but nonetheless, people are using it. The good news as far as Trezor in concerned is that the workflow for passphrases are more or less the same as the pin. It's a bit easier to implement because the user does not need to interact with the screen. This is how the code is implemented at the base level for Trezor.Net which also covers KeepKey.

Code: https://github.com/MelbourneDeveloper/Trezor.Net/blob/6786995008ddb92a7f6a67c34294e27f39f722ec/src/Trezor.Net/Manager/TrezorManagerBase.cs#L80

        public async Task<TReadMessage> SendMessageAsync<TReadMessage, TWriteMessage>(TWriteMessage message)
        {
            ValidateInitialization(message);

            await _Lock.WaitAsync();

            try
            {
                var response = await SendMessageAsync(message);

                for (var i = 0; i < 10; i++)
                {
                    if (IsPinMatrixRequest(response))
                    {
                        var pin = await _EnterPinCallback.Invoke();
                        response = await PinMatrixAckAsync(pin);
                        if (response is TReadMessage readMessage)
                        {
                            return readMessage;
                        }
                    }

                    if (IsPassphraseRequest(response))
                    {
                        var passPhrase = await _EnterPassphraseCallback.Invoke();
                        response = await PassphraseAckAsync(passPhrase);
                        if (response is TReadMessage readMessage)
                        {
                            return readMessage;
                        }
                    }

                    else if (IsButtonRequest(response))
                    {
                        response = await ButtonAckAsync();

                        if (response is TReadMessage readMessage)
                        {
                            return readMessage;
                        }
                    }

                    else if (response is TReadMessage readMessage)
                    {
                        return readMessage;
                    }
                }

                throw new ManagerException($"Returned response ({response.GetType().Name})  was of the wrong specified message type ({typeof(TReadMessage).Name}). The user did not accept the message, or pin was entered incorrectly too many times (Note: this library does not have an incorrect pin safety mechanism.)");
            }
            finally
            {
                _Lock.Release();
            }
        }

The Trezor and KeepKey libraries both have implementations for these properties:

        protected override bool IsButtonRequest(object response) => response is ButtonRequest;

        protected override bool IsPinMatrixRequest(object response) => response is PinMatrixRequest;

        protected override bool IsInitialize(object response) => response is Initialize;

        protected override bool IsPassphraseRequest(object response) => response is PassphraseRequest;

Trezor.Net, and KeepKey.Net allow for pin/passphrase interaction by simply maintaining a Task based callback. This means that the UI implementation can be in any form. For example, typing at the command prompt, or navigating to a pin screen and then capturing the result UI interaction. This passphrase is obtained with this call:

                        var passPhrase = await _EnterPassphraseCallback.Invoke();

@achow101 is correct. If a user has a passphrase, they

won't be able to use their old wallets with Wasabi

So, if you don't implement passphrase interaction, you will need to throw some kind of error message back to the user to say that their device is invalid. My advice would probably be to allow it because if you have pin interaction, passphrase interaction is basically no different, and the danger/risk is on the user. There is clear documentation about how passphrases work with warnings. If the user implements the passphrase without understanding the risk, there's not much you can do from your point of view.

[nopara73]

I have a feeling that Trezor Passphrases are becoming more popular in order to avoid the "$5 wrench attack".

I did not think about it. Indeed that's a pretty good usecase. Not for Wasabi though, we keep the data on the disk, so the attacker can easily see that the user wants to trick him.

The good news as far as Trezor in concerned is that the workflow for passphrases are more or less the same as the pin.

The difference (and the issue) is that you cannot detect if there's a passphrase, so showing a password box would be confusing for users who don't have it or know what that is. It took me a while to finally grasp the concept, imagine how long it'd take someone who's not a Bitcoin developer. Forever?

So, if you don't implement passphrase interaction, you will need to throw some kind of error message back to the user to say that their device is invalid.

No, I don't, the wallet will load properly anyway. If there'd be an error message I'd be able to implement it in a non-UX-disrupting (but still dangerous) way.

[achow101]

The difference (and the issue) is that you cannot detect if there's a passphrase

We can detect whether there is a password, just that HWI has not exposed this yet. We could add a has_passphrase field to the enumerate output which indicates whether a passphrase needs to be sent for a device.

[nopara73]

We can detect whether there is a password, just that HWI has not exposed this yet. We could add a has_passphrase field to the enumerate output which indicates whether a passphrase needs to be sent for a device.

That'd be great! Also its little sister: has_pin

[MelbourneDeveloper]

@nopara73

showing a password box would be confusing for users who don't have it or know what that is. It took me a while to finally grasp the concept, imagine how long it'd take someone who's not a Bitcoin developer. Forever?

It doesn't work that way. To use the passphrase, you have to opt in to it. The user will know how it works because they have to choose it explicitly. It works pretty much exactly the same way the pin works except that the pin requires you to look at the Trezor One. The Trezor only asks for the passphrase if the user has supplied it.

@achow101 , if you're going to be receiving the PassphraseRequest message you may as well handle it. You need to handle the PinMatrixRequest for Trezor One so how is the PassphraseRequest message different?

the wallet will load properly anyway.

If the user has set up a passphrase on their device, the Trezor is going to ask for it no matter what. You can specify an empty string for the passphrase, but this will literally mislead the user. They'll be looking at a totally different wallet because the passphrase it part of their seed.

[MelbourneDeveloper]

@nopara73 , have a careful read of this and take some time to understand how it works:
https://wiki.trezor.io/Passphrase

You can think of the passphrase as literally an extra word in the user's seed. If they have enabled on their device, you cannot use the device without the passphrase. If you do not use the passphrase, the seed that the device will be working with will be different to their normal wallet. This is actually the most dangerous scenario because the user could transfer money to a wallet that doesn't actually exist.

At the very least, if the user has enabled the passphrase, you need to stop them from continuing.

[MelbourneDeveloper]

Also, it's important to differentiate between "Pin" and "Passphrase". They're too totally different things but both are things that can be enabled on the Trezor. A pin stops you from using the device. A passphrase adds complexity to your seed. Not knowing the pin would stop a user dead in their tracks. Not knowing the passphrase would have the user working with a randomly generated wallet.

[MelbourneDeveloper]

In Wasabi we long struggled users losing their passwords and we implemented various strategies to avoid that and lately, despite the tremendous user growth we didn't get any lost password or "wasabi stole my money" support requests: zkSNACKs/zIPs#44

Passphrase encryption would bring back all the issues. Even worse, because the passphrase can't be validated.

This is kind of true. You're going to get users saying this if you allow passphrases. But, if you ignore them, it's going to be a lot worse.

[MelbourneDeveloper]

@nopara73

This was reason #1. Reason #2 is that it'd bring a huge UI clutter and usability issues for the 99% of people who don't use passphrase anyway. (Because we cannot figure out if passphrase is needed or not.) [...] There's almost zero good UX that could handle this.

This is not really true. your UI needs to implement Pin code functionality. There's just no way to avoid it if you want to support Trezor One. Passphrase operates on the same mechanism. Either way, the Trezor will request either of these pieces of information from the user if they have these things enabled.

But, it will not ask the user if they have never enabled it before. The workflow of Trezor.Net handles all this, so you'd just need to prompt the user with a TextBox if they've enabled it on their device.

[nopara73]

Let me categorize the exceptions to my original post above:

1. When PIN or Password is known to be required, then there're no UX issues, because we know when to fire up the Password box or PIN box.
2. When PIN or Password is validated by the device, then there is no new danger introduced.

When any of these two conditions aren't met, then we won't support PC side handling of the hardware wallet feature.

Example: Trezor T

As I've mentioned before, Trezor T is the only one I worked with so far and for Trezor Passphrase stuff none of the above conditions are fulfilled, so we won't support PC side handling of this.
However in Trezor T one easily use device side passphrase if he wants, so the UX issue can be avoided that way.
However passphrase handling must be turned on from PC side, but Wasabi won't support it, because of the "dangerous" nature of this feature, so condition 2 isn't met.
So if the user want to use Trezor T-style passphrases he must set it up through Trezor's website.
This will not expose the user's extpubkey to Trezor's server, because the user can use a passphrase in Wasabi that he never used in Trezor's webwallet, so his links between addresses is safe.

[MelbourneDeveloper]

@prusnak what are your thoughts?

[achow101]

if you're going to be receiving the PassphraseRequest message you may as well handle it. You need to handle the PinMatrixRequest for Trezor One so how is the PassphraseRequest message different?

HWI already handles the passphrase just fine. It's passed in to it as a command line option and the software responds to PassphraseRequests. PinMatrixRequests are very different from PassphraseRequests - they require looking at the screen and the correct response is not something that is known before the command is entered.

What was being discussed earlier is that HWI should let callers know that a passphrase or a pin is needed for the device to work. That was not exposed earlier as the assumption was that users would already know whether a passphrase was required and would have set the command line options accordingly.

[MelbourneDeveloper]

@achow101 well I guess that makes sense from the command line perspective but it goes back to what I've been saying. Can you at least now see that you're going to have to make several changes to your library to expect input where it normally wouldn't?

As for Pin, that's something that you have to get right. If not, Trezor One is just not supported.

[MelbourneDeveloper]

@achow101 does HWI deal with the complex user interaction with Ledger where the device returns status codes to direct the user between states on the device?

[achow101]

Can you at least now see that you're going to have to make several changes to your library to expect input where it normally wouldn't?

No I don't. These "several changes" that you keep talking about are already in HWI, and you would know this if you tried to use it! I have made some changes related to bugs and ux issues that users have run into while testing Wasabi, but those aren't related to anything that you've said so far.

As for Pin, that's something that you have to get right. If not, Trezor One is just not supported.

Pin support existed in the very first implementation of Trezor into HWI. The current method of using PINs non-interactively was implemented several months ago.

does HWI deal with the complex user interaction with Ledger where the device returns status codes to direct the user between states on the device?

Complex user interaction for what? We have tested a lot of things on the ledger so far and, AFAIK, none have involved any user interaction on the PC side (obviously users have to interact with the Ledger, and that's fine). If you're talking about things for altcoins or generally not Bitcoin we related (e.g. password manager, PGP, SSH, etc.), it's not supported and we don't care.

[MelbourneDeveloper]

@achow101

No I don't. These "several changes" that you keep talking about are already in HWI, and you would know this if you tried to use it! I have made some changes related to bugs and ux issues that users have run into while testing Wasabi, but those aren't related to anything that you've said so far.

But you said:

HWI should let callers know that a passphrase or a pin is needed for the device to work. That was not exposed earlier as the assumption was that users would already know whether a passphrase was required and would have set the command line options accordingly.

Pin support existed in the very first implementation of Trezor into HWI. The current method of using PINs non-interactively was implemented several months ago.

OK. So, HWI supports PC side pins with Trezor One? Perhaps I misunderstood.

Complex user interaction for what?

Prompting the user to tell them which app to switch to, or which state to set the device to so that the function that the PC is trying to use will match the state of the device.

[achow101]

But you said:

HWI should let callers know that a passphrase or a pin is needed for the device to work. That was not exposed earlier as the assumption was that users would already know whether a passphrase was required and would have set the command line options accordingly.

That does not mean that changes need to be made to expect input. No input is expected there. The change was a simple one to output in enumerate a field indicating that the device has passphrase and/or pin protection enabled. If input was provided, it was handled and expected. That change is letting Wasabi (or other callers) know that they should prompt the user for input.

Considering that Wasabi has been tested to work for 3 other devices (Coldcard, Ledger Nano S, Trezor T, and 5 if you consider the Trezor One and Keepkey when the user hasn't set a password or pin) I don't think there really will be any big or other changes that need to be made to HWI. The Digital Bitbox will also work once Wasabi supports passphrases. The only other changes to HWI that may occur (and I doubt there will be many) will be for the Trezor T because it hadn't been fully tested and supported by HWI.

So, HWI supports PC side pins with Trezor One?

Yes. Wasabi doesn't use that yet.

Prompting the user to tell them which app to switch to,

Irrelevant. Changing apps means doing something that's not Bitcoin, so it doesn't matter. We only care about the things happening in the Bitcoin app.

which state to set the device to so that the function that the PC is trying to use will match the state of the device.

Not needed in the Bitcoin app AFAICT.

[MelbourneDeveloper]

@achow101

Irrelevant. Changing apps means doing something that's not Bitcoin, so it doesn't matter. We only care about the things happening in the Bitcoin app.

And what happens if the user has the Ethereum app open?

[achow101]

And what happens if the user has the Ethereum app open?

Hmm, that indeed is somewhat of an issue, but I don't see how that is a "complex user interaction". It is simply just expanding on the error messages that we already have as having another app open just gives an unhelpful error.

Regardless, I think this is getting off topic. The constant Q&A about HWI and what issues it may or may not have is quite a waste of time. I think it would be far better for all of us if you instead tested HWI and Wasabi for the conditions that you are concerned about and open issues in their respective repositories about what you have found.

[btcpirate]

Additional thoughts why passphrase feature is very important:

• If you set up your trezor through the trezor webpage (thats the only way 99.99% of users are able to do it as the cli option is out of reach for almost everybody) you will share your xpup with satoshilabs. But if you set up your trezor with the webpage, activate the passphrase option. open your electrum wallet and open a passphrase protected wallet through Electrum/EPS/Fullnode nobody can know all your addresses. That alone is a strong argument why it would be important to have that feature included into wasabi.

• the discuessed 5 usd wrench attack can only be countered with multiple passphrase protected wallets.

• multiple attack vectors on trezor itself are only possible if the wallet is not protected by a passphrase. penetration testers have found various ways to attack ledger/trezor successfully, but nobody has found a way yet to attack a trezor btc wallet that is protected with a complex passphrase.

• plausible deniabilty if you are forced to show goverment criminals (police, imigration, customs) for what ever reason your hardware wallets content. (it is a real threat in many countries already and this threat will increase over time!)

Long story short: it would be said the best privacy wallet today (wasabi) would not implement the most important security feature of trezor at all.

Thoughts on how it could be implemented without fucking up the UX:

In Electrum you get only asked about the passphrase if the passphrase option is activated on trezor itself.
If wasabi could do the same than it would not confuse any user because only the user that has intentionally activated that feature on his trezor will be asked to enter the passphrase and he will understand. If a user has not activated it than he would not see that input field pop up at all.

[nopara73]

Long story short: it would be said the best privacy wallet today (wasabi) would not implement the most important security feature of trezor at all.

For every IRL wrench attack there's 100 lost password case. It's not a good compromise. A security feature that results in a user to lose its money is not secure.

That being said, no matter how much I'd want to, we cannot prevent you to from using passphrase on the device side, which is even more secure since the passphrase doesn't hit the OS, so it's not like users are missing out on anything.

[molnard]

We made some research about this topic.
I tried the --password command on HWI. Then I used getmasterxpub to compare the one on the website. To do that I had to convert ypub to xpub I used this site to do that: https://jlopp.github.io/xpub-converter/
Unfortunately I cannot achieve the same xpub with the --password argument, it changes the xpub in some way but it is not compatible with the website.
I tried to use getxpub but that command is not working for some reason.
Corresponding part in hwi:
https://github.com/bitcoin-core/HWI/blob/a83fdc6be3e2bd31c256ca17226682b8c0474384/hwilib/cli.py

[prusnak]

https://wiki.trezor.io/Passphrase

[achow101]

I tried to use getxpub but that command is not working for some reason.

What was the error?

[dennisreimann]

That being said, no matter how much I'd want to, we cannot prevent you to from using passphrase on the device side, which is even more secure since the passphrase doesn't hit the OS, so it's not like users are missing out on anything.

@nopara73 This is true for the Model T but not for the TREZOR One. The latter does not have an option to specify the passphrase on device.

I'd be with @btcpirate here and would strongly plead for reconsidering to implement this.

IMHO the situation regarding the UX isn't as bad as it seems:

For every IRL wrench attack there's 100 lost password case. It's not a good compromise. A security feature that results in a user to lose its money is not secure.

AFAIK there is no compromise here: Using a passphrase is optional and the user proactively chooses to do so. The default case may be to omit the passphrase, but that does not mean Wasabi cannot offer this feature for the subset of users that would like to use it. Those users should know about the risks involved and maybe Wasabi can display a note to ensure that.

It can be seen as an additional security feature and at least in my naive imagination it could be implemented like this: When a device is connected (at least those that do not support device-side entering of the passphrase), offer the option to set a passphrase. This would create a new wallet for that device. Wasabi should prompt the user to specify a label for this new wallet, as it would need to be distinguishable from the one without the passphrase.

I'd be willing to help with mocking up the UI/UX for that. As I said I'd really like to see this implemented as otherwise devices that do not offer device-side entering cannot be used with a passphrase. And using a passphrase should be considered a best practice for the reasons @btcpirate pointed out.

[MelbourneDeveloper]

@dennisreimann agreed.

Both Trezor One and Model T support passphrase though.

[MelbourneDeveloper]

Whether passphrases are a good idea or not is irrelevant. If the user can choose to use them, you either support it, or you stop a bunch of users from using the software. Same thing with the pin on Trezor One.

[btcpirate]

@dennisreimann agreed.

Both Trezor One and Model T support passphrase though.

What Dennis ment is that you can only input the passphrase on Trezor T Deviceside, and thats why its only possible with Trehor T to use passphrase with Wasabiwallet.

Whether passphrases are a good idea or not is irrelevant. If the user can choose to use them, you either support it, or you stop a bunch of users from using the software. Same thing with the pin on Trezor One.

it is not irrelevant if its a good idea or not and currently a user has no choice if he uses Trezor One. He can only choose if he uses Trezor T.

Using a Passphrase is vital for key management/security.
Using a Trezor without passphrase is insecure and seed can be extracted easily. Using a Trezor with compley passphrase is very secure and the way I recommend every new Bitcoin user to store his big amounts.

The best thing one can do today to achieve the higghest level of security combined withe eas of use (no CLI interaction) is using trezor with passphrase through wasabi. This combination has so many great advantages on so many levels.

I really think that it is said that there is currently no way to input the passphrase on wasabi. Passphrases will increase in importance in the future as soon as more people learn about private key managment and privatge key security.

I also think that it would be very easy to solve from the UX perspective. dennisreimann had some great ideas already.

[MelbourneDeveloper]

@btcpirate it's because the underlying python library doesn't support it.

[btcpirate]

what does that mean?

[MelbourneDeveloper]

@btcpirate Wasabi depends on HWI and wasabi can't do what HWI can't do.

If wasabi used a library that supported passphrase non device side, it wouldn't be a problem.

[achow101]

@MelbourneDeveloper That's not true. HWI does support passphrases non-device side. Wasabi has chosen not to make use of it.

[MelbourneDeveloper]

@achow101 sorry again. I thought that was a limitation in HWI from the conversation in the past.

[dennisreimann]

Just to wrap this up and let you guys be in the know: On todays dev call I brought this up and asked to revisit the decision on not supporting non-device side passphrase input for the TREZOR One.
Decision was against this, because this is "an edge case of an edge case" and providing the passphrase from computer input is considered as a bad practice/possible security hole.

[pinheadmz]

This missing feature is a heart-breaking game changer for me. As @btcpirate said:

multiple attack vectors on trezor itself are only possible if the wallet is not protected by a passphrase. penetration testers have found various ways to attack ledger/trezor successfully, but nobody has found a way yet to attack a trezor btc wallet that is protected with a complex passphrase.

Essentially, physical access to a Trezor is only slightly safer than a piece of paper with 12 words on it. I think Wasabi is a great project and I was excited to learn about HWI integration, but I don't consider the hardware wallet safe enough without a passphrase.

[btcpirate]

actually i was not fully correct, it is possible to use passphrases on the Trezor T, as you can input it deviceside (witch is the way to do it anyway)

only problem i see currently is that you dont have enough time to input a secure passphrase because of the timeout mechanism that does not allow you extend a certain time. which is currently set too short.

[molnard]

The timeout has been increased to 3 minutes for the Enumeration command. It is in the new silent release. Give it a try:
https://github.com/zkSNACKs/WalletWasabi/releases/tag/v1.1.9.1

[btcpirate]

amazing, great work

[nopara73]

@btcpirate It's just about to be replaced, so it would be better if you'd try this instead: #1905 (comment)

I put out a testing release in case you're having issues with PR checkouts: https://github.com/nopara73/WalletWasabi/releases

[btcpirate]

will do
amazing stuff