There is no way to validate Qubes Master Signing Key

General Discussion
4

Also keep in mind that the Qubes team handed out t-shirts with the fingerprint at least once during Chaos Communication Congress :wink: . While this of course is clever marketing, for me it also shows that folks actually thought about how to securely spread the key fingerprint.
I am quite certain that the Qubes assembly at CCC was benign and the folks there were actually affiliated with the project and handed out legitimate fingerprints, although I of course don’t know them personally.

Since I doubt someone will break into my appartment to replace the t-shirt in my wardrobe, I am confident that I know the actual fingerprint.

The more often such things happen (handing out fingerprints as merchandise, actually meeting people and verifying keys and signatures) the more thorough the Web of Trust gets.

Yes, the Master Key is, as far as I can see, not signed by any of the developer keys. Instead, they are signed by it (see, e.g., one of marmarek’s keys: http://keys.gnupg.net/pks/lookup?op=vindex&fingerprint=on&search=0x063938BA42CFA724).
To me this makes sense, as the master key is considered “the root of everything Qubes-related”.

4 Likes
5

@unman covered everything.

One addition: I imagine the reason is similar for other members of the Qubes team, but speaking for myself, the reason I haven’t directly signed the Qubes Master Signing Key (QMSK) is the same reason I haven’t directly signed any keys, namely because my master key is in a secure vault VM that I never import anything into. I don’t even expose my master key to my Split GPG backend. I only export my subkeys there (see here for details). This means that I can’t directly sign the QMSK with my own master key. Instead, I simply post a clearsigned text file that contains the QMSK fingerprtint.

(This has all come up before, by the way.)

This brings a whole new meaning to “evil maid attack.” :thinking:

4 Likes
6

In case anyone still doubts this without even bothering to check, here are some easy keyserver links showing a bunch of signatures on the QMSK:

http://hkps.pool.sks-keyservers.net/pks/lookup?op=vindex&fingerprint=on&search=0xDDFA1A3E36879494

https://keyserver.ubuntu.com/pks/lookup?search=0xddfa1a3e36879494&fingerprint=on&op=index

http://keys.gnupg.net/pks/lookup?op=vindex&fingerprint=on&search=0xDDFA1A3E36879494

Edit: It just occurred to me that perhaps the reason the commenter thinks that the QMSK has no signatures is due to a recent change in GnuPG itself. As you may recall, back in mid-2019 there was a certificate flooding attack. In response, the GnuPG developers released a new version that ignores all key signatures received from keyservers by default. This resulted in unexpected behavior for some users, who helped us to update our verifying signatures documentation to add --keyserver-options no-self-sigs-only,no-import-clean. If the commenter was not using these keyserver options when receiving the QMSK (or any key, for that matter) from a keyserver, it would appear that the QMSK (or any key) has no signatures at all. However, with these keyserver options, gpg receives the QMSK along with 70+ key signatures on it.

1 Like
7

Found a photo of the T-shirt, by the way:

The thread I linked earlier also has a bunch of links to the fingerprint in different places around the web.

1 Like
8

Ahh, the t-shirt and its resonably funny spelling error in all its glory ;). It could almost be considered a security feature. The evil maid would need to make the same spelling error, otherwise the counterfeit t-shirt could easily be identified. :wink:

2 Likes
9

By the way, here’s the Qubes Master Signing Key fingerprint:

pub   4096R/36879494 2010-04-01
      Key fingerprint = 427F 11FD 0FAA 4B08 0123  F01C DDFA 1A3E 3687 9494
uid   Qubes Master Signing Key
3 Likes
10

Not sure what exactly the problem is, but:

Signatures should go from the devs keys to the master key, not the other way around. Any other method of verification makes zero sense, it is bizarre the Qubes folks would think otherwise.

Beyond being bizarre, it makes it look compromised.

(I’m not suggesting that it is-- it’s just an extremely bad failure mode when you undermine your users ability to detect key substitution attacks by always looking like a key substitution is in progress).

Then again, it’s not just them. OpenSSL did this previously too-- replaced their key and the only source for the new key was the same https site as the software, and the key was signed by nothing and it stayed this way for a month.

During which time most Linux distributions shipped the new update, which presumably means that they’re not doing due diligence either. OpenSSL promptly fixed it after I reported that I couldn’t validate their key.

Fedora itself now has a nearly non-verifyable key, unlike qubes they don’t even have a master key that signs their release keys or sign new release keys with old ones. Presumably Qubes picked up their bad practices from Fedora.

It used to be that various developers at redhat would sign the fedora keys and post the signatures to the keyservers, but the DOS attacks on keyservers mean they can’t do this anymore.

From here: Signatures should go from the devs keys to the master key, not the other way aro... | Hacker News.

Apparently, a few people have their doubts concerning the current situation with the Master Key. Perhaps docs should have more information about it.

11

Not sure what exactly the problem is, but:

Signatures should go from the devs keys to the master key, not the other way around. Any other method of verification makes zero sense, it is bizarre the Qubes folks would think otherwise.

Beyond being bizarre, it makes it look compromised.

(I’m not suggesting that it is-- it’s just an extremely bad failure mode when you undermine your users ability to detect key substitution attacks by always looking like a key substitution is in progress).

Then again, it’s not just them. OpenSSL did this previously too-- replaced their key and the only source for the new key was the same https site as the software, and the key was signed by nothing and it stayed this way for a month.

During which time most Linux distributions shipped the new update, which presumably means that they’re not doing due diligence either. OpenSSL promptly fixed it after I reported that I couldn’t validate their key.

Fedora itself now has a nearly non-verifyable key, unlike qubes they don’t even have a master key that signs their release keys or sign new release keys with old ones. Presumably Qubes picked up their bad practices from Fedora.

It used to be that various developers at redhat would sign the fedora keys and post the signatures to the keyservers, but the DOS attacks on keyservers mean they can’t do this anymore.

From here: Signatures should go from the devs keys to the master key, not the other way aro... | Hacker News.

Not sure what exactly the problem is, but:

The problem is that they have a mental model of how keys should be used,
and cannot think beyond it.

Signatures should go from the devs keys to the master key, not the other way around. Any other method of verification makes zero sense, it is bizarre the Qubes folks would think otherwise.
Why “should” they? Why does it make zero sense?

Beyond being bizarre, it makes it look compromised.

Why does it make it look compromised? Because a key that isn’t signed by
the devs looks compromised.
This is just bizarre thinking.

Of course, there may be good arguments here - it’s just that I cant
see any.
And since the original comment that was quoted was just wrong in many
respects, I wouldn’t spend too much time one this.

1 Like
12

They have their doubts because, frankly, they don’t understand what they’re talking about.

In order to have a productive debate about this, they (or someone on their behalf) needs to advance specific arguments, not just vague insinuations and passive-aggressive ad hominem quips.

So far, all of the specific arguments they’ve advanced have been cleanly rebutted. For example, one argument was that the QMSK cannot be authenticated because no one has signed it at all (i.e., there are no signatures on the key at all). This has been proven false in two ways:

  1. There are actually 70+ signatures on the key (see above).
  2. Key signatures are not the only way to authenticate a key. If you can learn the genuine fingerprint (through any means), you can always use that to authenticate the key, since the fingerprint is cryptographically unique.

Again, this is just one example of an argument that they actually made and that we’ve already debunked.

Remember, any anonymous entity can spread misinformation and sow FUD by making vague, baseless accusations while sounding like they know what they’re talking about. This is not uncommon on the internet.

If there is any actual problem with the way we handle cryptographic signatures (or worthwhile improvement to be made), we’ll be happy to hear it and act on it, as we have for many years. Our track record proves that.

I just recently updated the page (in response to this very thread) to be more hand-holdy for people who don’t know much about this topic. Here’s a direct link to the most relevant section:

As always, we welcome feedback and contributions to help improve the documentation.

3 Likes
13

For the technically challenged user, is it possible to order a CD/DVD disk with all the needed keys/fingerprints and etc. from Qubes? Perhaps an app can be included that auto-checks uncertain files with these trusted keys? For a small fee and includes postal charges of course.

14

It’s amazing how careful Qubes OS team is and how open you are to the users’ suggestions and questions, both here and in the GitHub issues. Thank you so much!

2 Likes
15

This has come up many times before. There are two main problems:

  1. We can’t manufacture, warehouse, and ship physical inventory around the globe. We simply don’t have the capacity for it. Our forte is software, not selling physical merchandise. We could outsource it, but that exacerbates the second problem.

  2. It’s very difficult to ensure the physical security of such objects, especially if we outsource the manufacturing, warehousing, and shipping to a third party. Without some reasonable assurance that the physical object hasn’t been tampered with (or simply replaced) before it reaches you, it is practically useless as a means of key authentication.

16

Can’t we check the signature of a DVD? Or it’s hash? You distrust the infrastructure according to the FAQ.

17

There is some talk about the idea of making a tool like the “tails verification extension” to help not-so-technical users verify the downloaded files.

1 Like
18

Sure you can, but then it just pushes the problem back one step:

Need to verify ISO → Get DVD → Need to verify DVD

Yes, and…?

19

You probably did not understand what I mean. Can we check the signature of the whole information on the DVD, just like we check an .iso file? Or check the hash of this information. Shouldn’t it coincide with the hash of the .iso? (Or at least I expect it to be predictable).

20

I understood you perfectly well. My answer stands, same as above.

I’m puzzled about why you think I’m not understanding you. I believe I’m giving very clear and direct answers to your questions, yet there’s clearly some kind of gap in communication here. Perhaps it will help if I recap the discussion thus far, beginning with the context in which the DVD was brought up in the first place:

In other words, the DVD is supposed to serve as a secure root of trust for users. Rather than having to use the web of trust or learn the genuine QMSK fingerprint on their own, download keys and signature files, then using GnuPG or a similar tool to verify signatures, users would instead be able to get a DVD that contains everything they need to authenticate Qubes files, including ISOs.

That’s the theory. However, as I explained above, it is unlikely to work in practice. An attacker could replace the DVD while it is in transit or replace files at the facility where the DVDs are burned, or countless other things. A professional-looking Qubes logo printed on a DVD provides zero security. Anyone can do that.

Therefore, we would not be able to automatically trust that some DVD with a Qubes logo printed on it that came from some other part of the world is genuine. So, we’ll have to authenticate the DVD when we receive it. But notice now that we have simply pushed the original problem back by one step. Our original problem is that we had to authenticate the Qubes ISO. The proposed solution was to ship a DVD containing everything needed to authenticate the ISO. (Alternatively, it could simply be the desired Qubes ISO burned onto a DVD.) But now we have to authenticate the DVD. We have not solved the original problem. We have simply relocated it.

Now, it is certainly possible to authenticate the DVD (using essentially the same means as we would use to authenticate the ISO), but it is a pointless extra step. In that case, we might as well cut out the middle man and directly authenticate the ISO, which was our goal in the first place.

In the abstract, downloading an ISO over the internet and receiving a DVD in the mail are both means of receiving data through an untrusted infrastructure. Therefore, it should not be surprising that the same general security properties apply to both.

1 Like
21

This is exactly how I understand it. So at the end, there should be no difference between the two ways. Instead you were suggesting that DVDs add additional problems in the verification, where I don’t see any.

22

Where did I say that?

23

Well, here you probably meant that the Qubes team should verify every DVD. However, I suggest it might not be needed, since users can do it themselves, just like you do not verify that the infrastructure doesn’t tamper with the ISOs.

I also see now that it was a reply to

so the context was that a users wants to skip any verifications of the DVDs. This is of course not possible, I agree. Looks like my misunderstanding, sorry.