Gpg: BAD signature from "Qubes OS Release 4 Signing Key" [full]

User Support
11

The hashes in the DIGESTS files were all the same. Running the *sum for SHA1, SHA256, SHA512 all verified the iso integrity. The concern was why did the verification of the DIGESTS file fail. diff showed there was a line or character difference when comparing the three DIGESTS files which did not apparently affect the hashes.
As mentioned in the reply to unman, the DIGESTS files ending in -1 and-2 were downloaded using the ‘Save As’ feature in firefox. The DIGESTS file ending in -cp was text copied/pasted from the website. Nothing was added/deleted from the files ending in -1 or -2. The file ending in -cp was a direct copy/paste using gvim to a text file.
DIGESTS-2 file passed the integrity verification and the hashes it contained verified the iso integrity which allowed the install to proceed.

The NSA quip could have easily been martians since both will probably have a hand in the upcoming elections.

12

gvim is locally configured with IDE bundles, multiple blank lines are stripped to one. That is likely happened when copy/pasting using gvim to create …DIGESTS-cp. However, less was used to inspect -1 and -2. -1 appears to have an extra line at the end of the file.
-2 was the goldylocks DIGESTS file.

13

@unman, @qubesnewb
Good challenges, Thanks for taking the time to respond.

14

Please use code blocks (preformatted text). This will make your post much easier to read, and you won’t have to do weird stuff like this. You can either use the buttons in the GUI editor or learn some Markdown syntax (which is a great skill to learn anyway).

That shouldn’t be concerning. Anyone can create a text file that contains valid Qubes ISO hash values. The hash values are public knowledge, so someone can simply copy/paste them into a file, add whatever else they like (perhaps hash values for malicious ISOs), then (clear)sign the whole file with their own PGP key.

In other words:
(1) If the ISO passes the hash tests, then the .DIGESTS file contains valid hash values. [If A, then C.]
(2) If the .DIGESTS file is authentic, then the .DIGESTS file contains valid hash values. [If B, then C.]

“If A, then B” does not logically follow from (1) and (2).

This is correct. When a text file is PGP clearsigned, the exact contents, character for character, is the content being signed. If the contents change even by one character (including spaces and line breaks), you should not expect signature verification to succeed.

Unfortunately, we don’t control the disposition of the .DIGESTS files on the Qubes website, since it’s hosted on GitHub pages. It would be better for .asc and .DIGEST files to be downloaded rather than display by the user’s browser by default. I’ll had some hover text instructing the user to save the file; maybe that’ll help a little.

It’s worth noting that you had already successfully verified the detached PGP signature on the ISO, so checking the hash values after that was superfluous (though I can understand the desire to do so, since it’s easy and can provide some extra peace of mind).

15

I was taking a quick look at this and it seems it is not possible to force the download on buttons (<a href=""></a>) due to the same-origin policy (downloaded file is in a different website than qubes-os.org/).

I’m not sure it will help much since most people when they see a button they just click it right away, but it’s better than nothing.

16

Yup.

Yup.

1 Like
17

@adw
The reason for the http:-- was the first attempt to post was kicked back with a notification that more than one link was not allowed in a post.
Also,

was in regard to the cautions found in:

“However, it is possible that an attacker replaced Qubes-RX-x86_64.iso with a malicious ISO, computed the hash values for that ISO, and replaced the values in Qubes-RX-x86_64.iso.DIGESTS with his own set of values. Therefore, ideally, we should also verify the authenticity of the listed hash values.”
At the time the DIGESTS file failed verification left the hashes in question, and further the iso validity.

18

All hashes SHOULD be the same. What would a failure of one hash, while the passing of the other hashes imply?

19

Yes, I wrote that section, and it’s consistent with what I said above: It shouldn’t be concerning that the ISO passed the hash tests. Anyone can create a file that has valid hashes for an authentic Qubes ISO, since those hash values are public knowledge.

If you have an authentic .DIGESTS file, and an ISO successfully checks against it, then it follows that the ISO must also be authentic. However, the converse does not hold: If you have an authentic ISO, and it successfully checks against a .DIGESTS file, it does not follow that the .DIGESTS file must also be authentic.

Each .DIGESTS file is simply a PGP-clearsigned text file that contains several different hash values output by several different cryptographic has functions: MD5, SHA-1, SHA-256, and SHA-512. Each hash value is on its own line, output by (and readable by) the corresponding standard GNU utilities: md5sum, sha1sum, sha256sum, and sha512sum. When you check one, say SHA-512, you compute the SHA-512 hash value of the ISO. The resultant value should match the SHA-512 value contained in the .DIGESTS file. The intention of including such a variety of hash values in each .DIGESTS file is to grant flexibility to users in selecting the hash function of their choice when verifying the ISO. It is neither necessary nor expected that users will verify every hash value separately, though there is no harm in doing so.

Some cryptographic hash functions are known to be weaker than others in certain ways. For example, MD5 is known to be vulnerable to collision attacks and is thought to be theoretically vulnerable to a preimage attack. Therefore, if the MD5 check were to succeed while the others failed, one might consider the possibility that the ISO had been replaced with a forgery with the same MD5 hash value. However, such an attack would seem to be highly impractical and unlikely at present. A more likely explanation for such an occurrence would be a hardware fault, e.g., data corruption in non-ECC memory, perhaps due to a solar proton event. At any rate, from a practical security perspective, it is easy to run such checks several times and, if an ISO fails to pass verification consistently, to re-download the appropriate files, possibly over a different connection and/or on a different machine.

20

Yet another reason to use preformatted text. They won’t be converted into hyperlinks.

21

“If you have an authentic .DIGESTS file …”
At the time the first DIGESTS file failed verification. The second downloaded DIGESTS file passed. Both DIGESTS verified the iso. Thanks for the explanation of how it works.

1 Like
22

I got some similar issues with the 4.0.4

While downloading the most recent OS version 4.0.4. To install it on an old machine, the process went well. This time I took my time going through the verification of signatures and I had a few questions about the outputs.

Who’s signature are these?
5817A43B283DE5A9181A522E1848792F9E2795E9 or 51629CD41240D51DDAA773397AF9C6537BB6DE87

It’s not the master signing key nor is it the signing key for the Q4.0.4? Perhaps, it’s a developer signature but who’s?

(Here’s where I noticed it first)

[user@download ~]$ gpg2 -k "Qubes OS Release"
pub   rsa4096 2017-03-06 [SC]
      5817A43B283DE5A9181A522E1848792F9E2795E9
uid           [  full  ] Qubes OS Release 4 Signing Key

pub   rsa4096 2017-06-12 [SC]
      51629CD41240D51DDAA773397AF9C6537BB6DE87
uid           [ unknown] Qubes OS Release 4 Unstable Signing Key

(and again during this step)

[user@download ~]$ gpg2 --check-signatures "Qubes OS Release 4 Signing Key"
pub   rsa4096 2017-03-06 [SC]
      5817A43B283DE5A9181A522E1848792F9E2795E9
uid           [  full  ] Qubes OS Release 4 Signing Key
sig!3        1848792F9E2795E9 2017-03-06  Qubes OS Release 4 Signing Key
sig!         DDFA1A3E36879494 2017-03-08  Qubes Master Signing Key

pub   rsa4096 2017-06-12 [SC]
      51629CD41240D51DDAA773397AF9C6537BB6DE87
uid           [ unknown] Qubes OS Release 4 Unstable Signing Key

At this point, I not trying to use an unstable version Since I inadvertently downloaded these signatures.

/etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-templates-community
/etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-unstable

It may make sense, why I may have 2 versions of the OS? (or packages) by the following output.

[user@download ~]$ gpg2 -k "Qubes OS Release"
pub   rsa4096 2017-03-06 [SC]
      5817A43B283DE5A9181A522E1848792F9E2795E9
uid           [  full  ] Qubes OS Release 4 Signing Key

pub   rsa4096 2017-06-12 [SC]
      51629CD41240D51DDAA773397AF9C6537BB6DE87
uid           [ unknown] Qubes OS Release 4 Unstable Signing Key

Ultimately, I would like to get rid of the unstable versions and their signatures. How can I do that once I use the bootable USB on a different machine?

thanks,

23

Well, 5817A43B283DE5A9181A522E1848792F9E2795E9 is just the Qubes OS Release 4 Signing Key.

But it is. What makes you think it’s not?

As for 51629CD41240D51DDAA773397AF9C6537BB6DE87, I don’t recognize it, and I don’t know where it came from. Mysteriously, I have it in one of my qubes’ keyrings too, but I don’t know from where or when. Importantly, it is not signed by the QMSK or any other key in the aforementioned keyring and is not in the qubes-secpack, which makes me doubt its authenticity.

@marmarek, do you know anything about this key?

To clarify, these are paths to keys (not signatures) that are already in your filesystem, likely from a template. Merely having these doesn’t harm you in any way, nor does it mean you are or will use an unstable version.

This merely shows that you’ve imported these two public keys into your keyring. It doesn’t mean that you have any packages, and it doesn’t mean that you are or will use an unstable version.

If the only ISO you’ve downloaded is the current stable release (4.0.4), then you don’t have any unstable version to get rid of. There is currently no testing version listed on the downloads page, so if that’s where you got your download, you have nothing to worry about.

24

It is a key used to sign packages in “unstable” repository (described at How to install software in dom0 | Qubes OS). You can find the key in the qubes-release package: https://github.com/QubesOS/qubes-qubes-release/blob/master/RPM-GPG-KEY-qubes-4-unstable. It is intentionally not signed by QMSK, as it is never used to sign official releases, only experimental or debug packages.

2 Likes
25

@adw @marmarek Thanks for clarifying, the signature’s origin. In the past, I’ve had issues with disappearing documents from off-network apVMs and their respective folders. So, I hope you can appreciate my extrapolated concern.

So why would a verification signature process check the signature of a OS module we did not download?

Would there be way to check for or remove certain “modules” from an OS? i.e. anything that is “unstable or not practical”.

Lastly, if I had a spare machine and a day or so, I could do some testing ;however, this current machine is not for testing or evaluation.

thanks,

26

It doesn’t. As I explained above, you’re simply seeing that key in your own keyring.

That’s not how it works. You can think of each ISO as an atomic unit. Unless you build your own (which is something only people far more advanced than me do), you can’t add or remove anything from the ISO. So, a stable release ISO is just a stable release, and an unstable release ISO is an unstable release. If you’re using a stable release ISO, you won’t have anything unstable. There is no need to worry about checking for or removing any unstable “modules.”

27

@Libertad, @adw, and @marmarek,
Thanks for the question and the responses.
It helps to understand a little more how things are done.

1 Like
28

Thanks for explaining the processes. I am bit foreign to the OS and structure, so it helps. Thanks,

1 Like
29

Not just them, you should add anyone involved with data theft, extortion, espionage and stalking.

30

Answer me this… why are there three dates?

Imagine if Qubes is just NSA all the way? Now i suddenly don’t trust Qubes as much… I need an explanation… What’s up with the dates, and why can’t we know more about the masterkey and sign that one?
Openbsd seems more secure… Or if i’m just confused, you are the experts… What’s up with the dates? I need to learn PGP… One date seems the most logical to me anyways. One key and one date.