GPG verification

[Golddouble]

I want to use Trezor with Firefox in Windows.
So for this I have to install trezord-go.

I was able to download it via website.
I also got a asc-file for verification from this website.

Then I have installed Kleopatra.
I made a right click on the verification file to verify.
I searched with Kleopatra for an e-mail.

Then I got this:

The data cannot be verified.
The key used has not been authenticated.

1. Why can I be sure, that [email protected] is really the right mail address, and not any false e-mail-address, that Kleopatra has found per accident?
2. How can I be sure, that "91F3 ...." is the right code?
3. Which steps do I have to do, that I can authenticated "[email protected]" now without doubt.

Thank you.

[aspiers]

Yeah, I had the same questions. This is really disappointing for a security company not to be doing a good job of managing their PGP keys. It's easily fixed and would significantly increase confidence in the security of the software.

[aspiers]

See also https://www.reddit.com/r/TREZOR/comments/kmnzxd/how_to_verify_trezor_bridge_pgp_signature/

[aspiers]

It's even worse than I thought. In addition to the issues listed above:

• https://wallet.trezor.io/#/bridge does not provide any information about how to get the right key.
• This Reddit post is the only place I've been able to find a link to the relevant key.
• Where are the signatures for the Linux packages?

Come on Trezor, I know you're better than this.

[prusnak]

GPG UX is fundamentally broken. If you can't find the correct public key by yourself, does it makes sense to explain where to obtain it? The attacker could do the same and explain where to download their public key. In the end people are just downloading random keys from random locations and comparing some numbers they don't understand. Unless you have met me in person, you can't be sure you have the right key.

We are looking on better signing schemes such as sigstore which might replace GPG signatures.

Anyway, we improved lots of things you mention with the Trezor Suite - see download section on https://suite.trezor.io - this will soon become the default way how to get our software.

[daltek]

I don't disagree that GPG UX is rather outdated, so why not at least publish SHA256 hashes for each download, and GPG sign those. At least those who want some assurance that they've got the right file can verify the hash easily, and only the remaining geeks will need to go as far as GPG verifying the signature for the hashes. This is what the Debian project does and it seems like a good trade off.

[aspiers]

Firstly, thanks a lot for the quick reply - I really appreciate it. Before you read the rest of this comment, I should mention I'm a new owner of a Model T (having ditched Ledger in disgust over their recent hack), and other than this relatively minor issue I'm really impressed with the device and Trezor's general approach around open source. So the following is an attempt to give constructive feedback and help make your products even better.

@prusnak commented on March 16, 2021 5:03 PM:

GPG UX is fundamentally broken.

If by this you mean that the gpg CLI is far too hard for the average user, then I agree. But there's a danger of generalising that assessment to the whole PGP ecosystem. For example, there are great projects like Keybase which have made great strides towards making PGP more usable.

If you can't find the correct public key by yourself, does it makes sense to explain where to obtain it?

Yes, of course it does. Why would it make sense to deliberately waste users' time by making them hunt for it? I just wasted 30 minutes looking for it, and I'm a software architect who has been using PGP for over two decades, so if it's hard for me, it's probably hard for many others.

The attacker could do the same and explain where to download their public key.

Without defining the nature of the attack, this is a somewhat imprecise statement. A public key offered for download directly from https://trezor.io is substantially more trustable than some random key available elsewhere, given that trezor.io has a valid, verifiable TLS certificate. And indeed, Trezor already offers this on the Trezor Suite download page by linking to this signing key, and to various signatures for each of the binaries offered. Granted, this still requires an understanding of PGP to be able to verify the signatures, but it's a hell of a lot better than nothing.

In the end people are just downloading random keys from random locations and comparing some numbers they don't understand.

I'm sure you didn't mean that to come across as insulting, but I'm afraid it is somewhat, because it assumes that none your users understand PGP or know how to use it. The fact that some don't is not good justification for neglecting those who do. In fact, you can assume that in general Trezor customers are significantly more clued up on computer security than the average person, otherwise why would they be buying the product in the first place?

Unless you have met me in person, you can't be sure you have the right key.

This is incorrect; there are many perfectly good ways to validate keys and establish trust without meeting in person. As mentioned above, simply hosting the signing key and signatures on trezor.io would be a huge improvement following the 80/20 rule. If you wanted to tackle some of the remaining 20% and really impress your most security-conscious customers, you could go even further and ensure that the signing key is itself signed by other reputable keys. Keybase would make it easy to associate the key with other online identities, such as the official Trezor Twitter account, GitHub accounts of multiple Trezor employees, and so on.

We are looking on better signing schemes such as sigstore which might replace GPG signatures.

That sounds like it could be great. But I assume it will take quite a while to get that set up, and in the meantime surely it would be easy and quick to host the signing key and corresponding signatures on trezor.io, and to provide direct links from the Bridge installation page, just like has already been done with the Suite download page?

Anyway, we improved lots of things you mention with the Trezor Suite - see download section on suite.trezor.io - this will soon become the default way how to get our software.

Yes, the Suite page is fine - just struggling to understand why the Bridge page wasn't done in the same way.

[prusnak]

Yes, the Suite page is fine - just struggling to understand why the Bridge page wasn't done in the same way.

We are a small team and focused our effort on getting things right with the Suite.

The Bridge is part of the Suite, so users will not have to install the Bridge separately anymore.

[aspiers]

I see, thanks for the info.

[xanoni]

It has to be easier to find the right keys ... it took me far too long to find the right key for the Trezor Suite repo.

[prusnak]

It has to be easier to find the right keys ... it took me far too long to find the right key for the Trezor Suite repo.

They are right under the green download button at https://suite.trezor.io

[xanoni]

But how do you know if you're browsing the GitHub repos ... I don't randomly visit the website.

[schnerring]

They are right under the green download button at https://suite.trezor.io

They certainly are not. Are the Linux binaries for the bridge not signed? I can only see signatures for Windows and macOS... am I supposed to blindly trust those Linux binaries? 😰

Is the bridge deprecated? Why is the latest version on the website 2.0.27 but GitHub includes three newer versions? This is super confusing...

In the end people are just downloading random keys from random locations and comparing some numbers they don't understand

Isn't that why you spread the fingerprint of the key everywhere to make it less likely to be compromised by an attacker? Twitter, the docs, GitHub, Reddit. Even other people blogging about their installation steps and including the fingerprint in their blog post...

[xanoni]

I think he was referring only to the pubkey, which is hiding behind that tiny gray-on-gray "Signing key" link. Even if I had gone to the website, not sure if I would have seen it.

[schnerring]

Your screenshot is from the suite download. Go check out the download page for the bridge: https://wallet.trezor.io/#/bridge

It is outdated. I opted to use the suite instead which includes the bridge which I verified by browsing to http://127.0.0.1:21325/status/

[xanoni]

K, didn't realize we were talking about the Bridge. I didn't even realize the Bridge was different from the Suite, I thought they were shipped together. Good to know.

[aspiers]

I've come back to this issue 2 years later, because I'm trying to get my Trezor working on a different computer, and despite all the above info, I'm still very confused. @prusnak I'd be really grateful if you or someone else from Trezor could answer a few quick questions about Trezor on Linux.

Above, you said "The Bridge is part of the Suite, so users will not have to install the Bridge separately anymore." Is this (still) true?

If so:

1. Please could https://suite.trezor.io/web/bridge/ be updated to make this crystal clear?
2. Also please could https://trezor.io/support/a/trezor-suite-doesn-t-see-my-device be updated, and indeed anywhere else which refers to the bridge .
3. Should we also remove any previously installed trezor-bridge rpm?
4. To use Trezor on Linux with MetaMask in a web browser like Chrome, does this mean that we should first run the Trezor Suite AppImage, rather than the trezord service from the old trezor-bridge rpm? Or is it unnecessary to start anything? If we're expected to keep the AppImage running, this seems like a step backwards in UX, because AFAICS there is no way to run it in the background. Being able to run trezord as a system service was a nice solution, especially for those of us who don't use the Suite UI much.
5. As long as the bridge is available for download, it's crucially important that users can easily find how to verify the integrity of the bridge download, for reasons I explained above. If you don't want anyone to use it ever, then it's better to remove it entirely. But this halfway situation where it's available but really hard to figure out how to verify is dangerous.

Thanks!

[prusnak]

@aspiers The sentence "The Bridge is part of the Suite, so users will not have to install the Bridge separately anymore." does not mean you cannot install and use it manually, so questions 1 and 2 are invalid.

3. No, you are fine.

4. You can keep running trezord from the RPM, that's fine.

5. You can verify my key (which was used to sign the bridge) on https://keybase.io/stick

[aspiers]

@prusnak Thanks a lot for the quick and helpful reply! I really appreciate it.

It's great to know that the Bridge is still a supported solution alongside the Suite.

Also, it's awesome that we can verify your key via keybase - this is a great solution since I can now be confident that anything signed by your key is from the owner of your Twitter and GitHub accounts 😁

It would be a bit nicer if the software had been signed by an official Trezor key linked via keybase to https://trezor.io/, https://twitter.com/Trezor, and https://github.com/trezor, since that would eliminate the need to manually verify that you are the "real" Pavol Rusnak associated with Trezor and Satoshi Labs. Of course this can be achieved by looking at your GitHub, Twitter etc. but it's not quite as strong as direct verifiable cryptographic links with the official Trezor website and GitHub / Twitter accounts.

The only other small thing remaining to make this all perfect would be to add to https://suite.trezor.io/web/bridge/ the info about being able to obtain and verify your key via keybase. Presumably it would only take a few minutes to do that? Then we could resolve this GitHub issue.

Thanks again for listening to your users!

[sime]

@aspiers You already have a solution, but wanted to let you know

To use Trezor on Linux with MetaMask in a web browser like Chrome

If bridge (trezord) is not detected, using Trezor on Chrome will fall back to WebUSB.

[aspiers]

Thanks @sime. For some reason WebUSB wasn't working hence the questions, but I wasn't clear about the fallback mechanism so this is helpful to know.