Git-Mirrors/qubes-doc
1
0
Fork 0
mirror of https://github.com/QubesOS/qubes-doc.git synced 2024-10-01 01:25:40 -04:00
Code Issues Packages Projects Releases Wiki Activity

VerifyingSignatures changed

Browse Source
This commit is contained in:
Axon 2013-09-25 22:44:05 +00:00
parent a5b9d588ea
commit 0fc2f3be36
1 changed files with 16 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

32
VerifyingSignatures.md
View File

@ -7,29 +7,29 @@ permalink: /wiki/VerifyingSignatures/
On Digital Signatures and Key Verification
==========================================
What do the Digital Signatures Prove and What They DO NOT Prove
---------------------------------------------------------------
What Digital Signatures Can and Cannot Prove
--------------------------------------------
Most people, even programmers, often confuse the basic ideas behind digital signatures. Most people should read this section, even if it looks trivial at first sight.
Most people--even programmers--”are confused about the basic concepts underlying digital signatures. Therefore, most people should read this section, even if it looks trivial at first sight.
Digital Signatures can prove that a given file is authentic, i.e. that is has been indeed created by a person that signed it, and that its contents has not been tampered (so, integrity is preserved).
Digital signatures can prove both **authenticity** and **integrity** to a reasonable degree of certainty. **Authenticity** ensures that a given file was indeed created by the person who signed it (i.e., that it was not forged by a third party). **Integrity** ensures that the contents of the file have not been tampered with (i.e., that a third party has not undetectably altered its contents *en route*).
Digital Signatures do \*not\* prove any other property, e.g. that the file is not malicious. In fact there is nothing that could stop people from signing a malicious program (and it happens from time to time in realty).
Digital signatures **cannot** prove any other property, e.g., that the signed file is not malicious. In fact, there is nothing that could stop someone from signing a malicious program (and it happens from time to time in reality).
The point is, of course, that people need to choose to trust some people, e.g. Linus Torvalds, Microsoft, etc. and assume that if a file(s) was indeed signed by those individuals, then indeed it should not be malicious and buggy in some horrible way. But the decision of whether to trust certain people (e.g. those behind the Qubes Project) is beyond the scope of digital signatures. It's more of a sociological and political decision.
The point is, of course, that people must choose who they will trust (e.g., Linus Torvalds, Microsoft, the Qubes Project, etc.) and assume that if a given file was signed by a trusted party, then it should not be malicious or buggy in some horrible way. But the decision of whether to trust any given party is beyond the scope of digital signatures. It's more of a sociological and political decision.
However, once we make a decision to trust somebody (e.g. The Qubes Project and the files released by them), then the digital signatures are useful, because they make it possible to limit our trust only to those few people we chose, and not to worry about all the Bad Things That Can Happen In The Middle between us and the them (i.e. the vendor), like e.g.: server compromises (qubes-os.org will surely get compromised one day), dishonest IT stuff at the hosting company, dishonest stuff at the ISPs, WiFi attacks, etc.
Once we make the decision to trust certain parties, digital signatures are useful, because they make it possible for us to limit our trust only to those few parties we choose and not to worry about all the "Bad Things That Can Happen In The Middle" between us and the them, e.g., server compromises (qubes-os.org will surely be compromised one day), dishonest IT stuff at the hosting company, dishonest stuff at the ISPs, Wi-Fi attacks, etc.
If we verify all the files we download from the vendor, we don't need to worry about all the above bad things, because we would easily be able to detect when the file(s) has been tampered (and not execute/install/open them).
By verifying all the files we download which purport to be authored by a party we've chosen to trust, we eliminate concerns about the bad things discussed above, since we can easily detect whether any files have been tampered with (and subsequently choose to refrain from executing, installing, or opening them).
However, for the digital signatures to make any sense, one should ensure that the public keys we use for signature verification are indeed the original ones. Anybody can generate a GPG key pair that would pretend to be for "Qubes Project", but only the key pair that we generated is the legitimate one. The next paragraph describes how to verify the validity of the Qubes signing keys.
However, for digital signatures to make any sense, we must ensure that the public keys we use for signature verification are indeed the original ones. Anybody can generate a GPG key pair that purports to belong to "The Qubes Project," but of course only the key pair that we (i.e., the Qubes developers) generated is the legitimate one. The next section explains how to verify the validity of the Qubes signing keys.
Importing Qubes Signing Keys
----------------------------
Every file published by the Qubes Project (rpm, tgz, git repositories) is digitally signed by one of the developer or release keys. Each such key is signed by the Qubes Master Signing Key (`0x36879494`).
The public portion of the Master Key can be download from a keyserver, e.g.:
The public portion of the Master Key can be downloaded from a keyserver, e.g.:
``` {.wiki}
gpg --recv-keys 0x36879494
@ -37,7 +37,7 @@ gpg --recv-keys 0x36879494
(You can use other key server than `pgp.mit.edu`, which is just an example)
For additional security we also publish the The Master Key's fingerprint here in this document:
For additional security we also publish the the Master Key's fingerprint here in this document:
``` {.wiki}
pub 4096R/36879494 2010-04-01
@ -45,9 +45,9 @@ pub 4096R/36879494 2010-04-01
uid Qubes Master Signing Key
```
There should also be a copy of this key at the project's main website, as well as in the [​archives of the projects mailing list](https://groups.google.com/forum/#!msg/qubes-devel/RqR9WPxICwg/kaQwknZPDHkJ).
There should also be a copy of this key at the project's main website, as well as in the [​archives of the project's mailing list](https://groups.google.com/forum/#!msg/qubes-devel/RqR9WPxICwg/kaQwknZPDHkJ).
Once you download and verified the fingerprint of the Master Signing Key, you should import this key and set its trust level to 'ultimate' (oh, well), so that it could be used to automatically verify all the developer's keys:
Once you have downloaded and verified the fingerprint of the Master Signing Key, you should import this key and set its trust level to "ultimate" (oh, well), so that it can be used to automatically verify all the developers' keys:
``` {.wiki}
gpg --edit-key 0x36879494
@ -65,17 +65,17 @@ gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
```
You can also download all the currently used developer's keys (and also a copy of the Master Key) in the keys directory on our server:
You can also download all the currently used developers' keys (and also a copy of the Master Key) in the keys directory on our server:
[​http://keys.qubes-os.org/keys/](http://keys.qubes-os.org/keys/)
The developer keys are set to be valid for 1 year only, while the Qubes Master Signing Key has no expiration date. This key has been generated and is kept only within a special 'vault' machine that has no networking, and the private portion (hopefully) is never to leave this isolated machine.
The developer keys are set to be valid for 1 year only, while the Qubes Master Signing Key has no expiration date. This latter key was generated and is kept only within a dedicated, air-gapped "vault" machine, and the private portion will (hopefully) never leave this isolated machine.
Having problems verifying the ISO? See this thread:
[​https://groups.google.com/group/qubes-devel/browse\_thread/thread/4bdec1cd19509b38/9f8e219c41e1b232](https://groups.google.com/group/qubes-devel/browse_thread/thread/4bdec1cd19509b38/9f8e219c41e1b232)
Verifying Qubes code
Verifying Qubes Code
--------------------
Developers who fetch code from our Git server should always verify tags on the latest commit. Any commits that are not followed by a signed tag should not be trusted!