We will present you three techniques from the easiest to the safest. Again, none of them is a perfect and magic solution. Feel free to explore them according to your possibilities and technical skills.
Note that since all Tails releases are signed with the same key, you will not have to verify the key every time and the trust you might progressively build in it will be built once and for all. Still, you will have to check the ISO image every time you download a new one!
A simple technique to increase the trust you can put in Tails signing key would be to download it several times, from several locations, several computers, possibly several countries, etc.
For example you could save them every time with a different name in the same directory on a USB stick. Then run the following command from a terminal to check whether all the keys are identical:
cd [your download directory] sha256sum tails-signing*.key
This command would output something like this:
7d4636ed49f6dd09d6e606936b6e686daad4200925875443668843b633ef6df2 tails-signing-desktop.key 7d4636ed49f6dd09d6e606936b6e686daad4200925875443668843b633ef6df2 tails-signing-laptop.key 7d4636ed49f6dd09d6e606936b6e686daad4200925875443668843b633ef6df2 tails-signing-library.key 7d4636ed49f6dd09d6e606936b6e686daad4200925875443668843b633ef6df2 tails-signing-seattle.key
You would then need to visually check that all the checksums of the first column are the same, meaning that the keys are identical.
You could also use this technique to compare keys downloaded by your friends or other people you trust.
If you want to be extra cautious and really authenticate Tails signing key in a stronger way than what standard HTTPS offers you, you will need to use the OpenPGP Web of Trust.
One of the inherent problems of standard HTTPS is that the trust we usually put on a website is defined by certificate authorities: a hierarchical and closed set of companies and governmental institutions approved by web browser vendors. This model of trust has long been criticized and proved several times to be vulnerable to attacks as explained on our warning page.
We believe instead that users should be given the final say when trusting a website, and that designation of trust should be done on the basis of human interaction.
The OpenPGP Web of Trust is a decentralized trust model based on OpenPGP keys. Let's see that with an example.
You're a friend of Alice and really trust her way of managing OpenPGP keys. You're trusting Alice's key.
Furthermore, Alice met Bob, a Tails developer, in a conference, and signed Bob's key. Alice is trusting Bob's key.
Bob is a Tails developer who directly owns the Tails signing key. Bob fully trusts Tails signing key.
This scenario creates a trust path from you to Tails signing key that could allow you to trust it without having to depend on certificate authorities.
This trust model is not perfect either and requires both caution and intelligent supervision by users. The technical details of creating, managing and trusting OpenPGP keys is outside of the scope of this document.
We also acknowledge that not everybody might be able to create good trust path to Tails signing key since it based on a network of direct human relationships and the knowledge of quite complex tools such as OpenPGP.
Following the previous scenario, when Alice met Bob, a Tails developer, she could have made a new signature on Tails signing key with her own key to certify this trust relationship and make it public. Tails signing key would now come along with a signature made by Alice.
Tails signing key is actually already signed by the keys of several official
developers of Debian, the operating system on which Tails is based. Debian makes
an extensive use of OpenPGP and you can download the keys of all Debian
developers by installing the
debian-keyring package. You can then
verify the signatures those developers made with their own key on Tails signing
To download the Debian keyring you can do:
sudo apt-get install debian-keyring
To get a list of the signatures made by other people on Tails signing key you can do:
gpg --keyid-format long --list-sigs 1202821CBE2CD9C1
You will get something like this:
pub 4096R/1202821CBE2CD9C1 2010-10-07 [expires: 2012-10-06] uid Tails developers (signing key) <firstname.lastname@example.org> sig 3 1202821CBE2CD9C1 2011-04-16 Tails developers (signing key) <email@example.com> sig BACE15D2A57498FF 2011-04-16 [User ID not found] sig CCD2ED94D21739E9 2011-06-12 [User ID not found] uid T(A)ILS developers (signing key) <firstname.lastname@example.org> sig 3 1202821CBE2CD9C1 2010-10-07 Tails developers (signing key) <email@example.com> sig BACE15D2A57498FF 2010-10-07 [User ID not found] sig 8CBF9A322861A790 2010-12-24 [User ID not found] sig 7EF27D76B2177E1F 2010-12-27 [User ID not found] sig CCD2ED94D21739E9 2010-12-29 [User ID not found] sig AC0EC35285821C42 2011-03-22 [User ID not found] sig C2DEE7F336042734 2010-10-24 [User ID not found]
The lines ending with '[User ID not found]' are signatures made by keys you still don't have in your keyring. You could try to search for them in the Debian keyring by their key ID: the 16 digit code between the 'sig' tag and the date. You could for example do:
gpg --keyring=/usr/share/keyrings/debian-keyring.gpg --list-key CCD2ED94D21739E9
If this signature corresponds to a key in the Debian keyring you will get something like this:
pub 4096R/CCD2ED94D21739E9 2007-06-02 [expires: 2012-05-31] uid Daniel Kahn Gillmor <firstname.lastname@example.org> uid Daniel Kahn Gillmor <email@example.com> uid [jpeg image of size 3515] uid Daniel Kahn Gillmor <firstname.lastname@example.org> sub 4096R/C61BD3EC21484CFF 2007-06-02 [expires: 2012-05-31] sub 2048R/125868EA4BFA08E4 2008-06-19 [expires: 2011-05-31]
You can then import it in your own keyring by doing:
gpg --keyring=/usr/share/keyrings/debian-keyring.gpg --export CCD2ED94D21739E9 | gpg --import
Now you can try to verify the signature made by this new key on Tails signing key by doing:
gpg --keyid-format long --check-sigs 1202821CBE2CD9C1
On the output, the status of the verification is indicated by a flag directly following the "sig" tag. A "!" indicates that the signature has been successfully verified, a "-" denotes a bad signature and a "%" is used if an error occurred while checking the signature (e.g. a non supported algorithm). For example, in the following output the signature of Daniel Kahn Gillmor on Tails signing key has been successfully verified:
pub 4096R/1202821CBE2CD9C1 2010-10-07 [expires: 2012-10-06] uid Tails developers (signing key) <email@example.com> sig!3 1202821CBE2CD9C1 2011-04-16 Tails developers (signing key) <firstname.lastname@example.org> sig! CCD2ED94D21739E9 2011-06-12 Daniel Kahn Gillmor <email@example.com> uid T(A)ILS developers (signing key) <firstname.lastname@example.org> sig!3 1202821CBE2CD9C1 2010-10-07 Tails developers (signing key) <email@example.com> sig! CCD2ED94D21739E9 2010-12-29 Daniel Kahn Gillmor <firstname.lastname@example.org> pub 4096R/1202821CBE2CD9C1 2010-10-07 [expires: 2012-10-06] uid T(A)ILS developers (signing key) <email@example.com> sig!3 1202821CBE2CD9C1 2010-10-07 T(A)ILS developers (signing key) <firstname.lastname@example.org> sig! CCD2ED94D21739E9 2010-12-29 Daniel Kahn Gillmor <email@example.com> 3 signatures not checked due to missing keys
Since the Web of Trust is actually based on human relationships and real-life interactions the best would be to start establishing contacts with people knowledgeable about OpenPGP, start using it yourself and build trust relationships in order to find your own trust path to Tails signing key.
You could start by contacting a local Linux User Group or other Tails enthusiasts near you and exchange about their OpenPGP practices.