Bezpieczna konfiguracja GPG
Kategoria: Artykuły, etykiety: certyfikat, gpg, klucz, szyfrowanie
Dodany: 2014-09-21 23:20
(zmodyfikowany: 2014-09-21 23:21)
Przez: morfik
Wyświetleń: 19890
Przy okazji szukania info na temat kluczy GPG, natknąłem się na dość ciekawy artykuł o konfiguracji samego GnuPG. Tekst, o którym mowa jest dostępny pod tym linkiem. Jako, że jest tam sporo ciekawych informacji, postanowiłem napisać co nieco o GPG/PGP, tak by poniższe wiadomości choć trochę mi się utrwaliły.
Narzędzie gpg posiada swój własny plik konfiguracyjnych, który zwykle jest zlokalizowany w ~/.gnupg/gpg.conf . Można w nim sprecyzować większość z opcji, które zwykle są podawane w terminalu przy wywoływaniu polecenia gpg . Po zdefiniowaniu konfiguracji, nie musimy już podawać szeregu parametrów za każdym razem gdy będziemy chcieli skorzystać z gpg -- te będą dodawane z automatu w oparciu o plik gpg.conf .
Poniższy artykuł ma na celu opisanie zarówno konfiguracji narzędzia gpg, jak i generowania samych kluczy tak by te przeszły pomyślnie testy bezpieczeństwa.
Konfiguracja narzędzia gpg
Standardowo pakiet gnupg jest zainstalowany w debianie i wszystkie potrzebne nam narzędzia są już dostarczone i gotowe do użycia. Jest szereg rzeczy, które musimy wziąć pod uwagę przy konfigurowaniu gpg, pierwszą z nich jest serwer kluczy z jakiego mamy zamiar korzystać.
Serwery kluczy
Jeśli nie odświeżamy swoich publicznych kluczy regularnie, możemy przegapić pewne zdarzenia, np. unieważnienie któregoś z kluczy. Zwykle użytkownicy przesyłają informacje o zmianach w swoich kluczach do serwera kluczy i jeśli używamy jakiegoś keyservera, który działa prawidłowo, możemy skonfigurować swoją maszynę by ta pobierała aktualizacje kluczy regularnie.
Wiele klientów OpenPGP posiada zwykle jeden skonfigurowany keyserver. To nie jest idealne rozwiązanie, ponieważ jeśli ten serwer padnie albo, co gorsza, zdaje się działać prawidłowo, a tak naprawdę są z nim jakieś problemy, możemy nie otrzymać krytycznych aktualizacji kluczy. Dlatego też zalecane jest by używać puli serwerów sks. Maszyny w puli są regularnie sprawdzane czy aby działają prawidłowo i jeśli któryś ma jakieś problemy, zostanie usunięty z puli.
Co może człowieka zdziwić, to fakt, że zapytania o klucze gpg do sporej ilości serwerów nie wędrują zaszyfrowanym kanałem używającym protokołu hkps -- by z niego korzystać trzeba doinstalować pakiet gnupg-curl , po czym pobrać certyfikat serwera i zweryfikować odcisk palca (fingerprint) certyfikatu.
Jak możemy wyczytać na stronie sks, certyfikat X.509 podpisany przez Thawte powinien mieć odcisk palca SHA1 w postaci FC 5F B2 F5 E4 24 D3 47 B9 C4 07 32 34 6E 16 1F 91 6B F1 F2 . Dodatkowo jest też wzmianka na temat faktu, że ten odcisk palca nie pasuje do klucza RSA dla tego certyfikatu z powodu różnic w informacjach jakie są brane pod uwagę przy tworzeniu tego odcisku. Generalnie rzecz biorąc, ID klucza (KeyID) certyfikatu OpenPGP to 0xd71fd9994af34f0b i można ten klucz odnaleźć w puli sks. Odcisk palca tego klucza to 878F FB44 5E6E 13A6 4716 3BDC D71F D999 4AF3 4F0B , dodatkowo ten klucz jest podpisany przez inny klucz o ID 0x0B7F8B60E3EDFAE3 . Sprawdźmy zatem czy wszystko się zgadza.
By zweryfikować certyfikat dla strony www, klikamy myszą na kłódkę przy adresie > More information > View Certificate. W zakładce General na samym dole widnieje odcisk SHA1 -- jest zgodny z tym podanym na stronie, czyli tożsamość serwera www została potwierdzona.
Musimy także przeprowadzić weryfikację puli serwerów -- wszystkie serwery w niej są podpisane przez CA sks-keyservers.net , którego certyfikat można znaleźć na https://sks-keyservers.net/sks-keyservers.netCA.pem . Odcisk palca tego certyfikatu to 79:1B:27:A3:8E:66:7F:80:27:81:4D:4E:68:E7:C4:78:A4:5D:5A:17 , a X509v3 Subject Key Identifier to E4 C3 2A 09 14 67 D8 4D 52 12 4E 93 3C 13 E8 A0 8D DA B6 F3 . Pobieramy zatem certyfikat i weryfikujemy go:
$ mkdir ~/gpg_ca
$ cd ~/gpg_ca
$ wget https://sks-keyservers.net/sks-keyservers.netCA.pem
--2014-09-21 11:20:05-- https://sks-keyservers.net/sks-keyservers.netCA.pem
Resolving sks-keyservers.net (sks-keyservers.net)... 37.44.179.12, 2001:16d8:ee30::4
Connecting to sks-keyservers.net (sks-keyservers.net)|37.44.179.12|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 1984 (1.9K) [text/plain]
Saving to: ‘sks-keyservers.netCA.pem’
100%[===============================================>] 1,984 --.-K/s in 0.004s
2014-09-21 11:20:05 (495 KB/s) - ‘sks-keyservers.netCA.pem’ saved [1984/1984]
$ openssl x509 -fingerprint -in sks-keyservers.netCA.pem
SHA1 Fingerprint=79:1B:27:A3:8E:66:7F:80:27:81:4D:4E:68:E7:C4:78:A4:5D:5A:17
-----BEGIN CERTIFICATE-----
MIIFizCCA3OgAwIBAgIJAK9zyLTPn4CPMA0GCSqGSIb3DQEBBQUAMFwxCzAJBgNV
BAYTAk5PMQ0wCwYDVQQIDARPc2xvMR4wHAYDVQQKDBVza3Mta2V5c2VydmVycy5u
ZXQgQ0ExHjAcBgNVBAMMFXNrcy1rZXlzZXJ2ZXJzLm5ldCBDQTAeFw0xMjEwMDkw
MDMzMzdaFw0yMjEwMDcwMDMzMzdaMFwxCzAJBgNVBAYTAk5PMQ0wCwYDVQQIDARP
c2xvMR4wHAYDVQQKDBVza3Mta2V5c2VydmVycy5uZXQgQ0ExHjAcBgNVBAMMFXNr
cy1rZXlzZXJ2ZXJzLm5ldCBDQTCCAiIwDQYJKoZIhvcNAQEBBQADggIPADCCAgoC
ggIBANdsWy4PXWNUCkS3L//nrd0GqN3dVwoBGZ6w94Tw2jPDPifegwxQozFXkG6I
6A4TK1CJLXPvfz0UP0aBYyPmTNadDinaB9T4jIwd4rnxl+59GiEmqkN3IfPsv5Jj
MkKUmJnvOT0DEVlEaO1UZIwx5WpfprB3mR81/qm4XkAgmYrmgnLXd/pJDAMk7y1F
45b5zWofiD5l677lplcIPRbFhpJ6kDTODXh/XEdtF71EAeaOdEGOvyGDmCO0GWqS
FDkMMPTlieLA/0rgFTcz4xwUYj/cD5e0ZBuSkYsYFAU3hd1cGfBue0cPZaQH2HYx
Qk4zXD8S3F4690fRhr+tki5gyG6JDR67aKp3BIGLqm7f45WkX1hYp+YXywmEziM4
aSbGYhx8hoFGfq9UcfPEvp2aoc8u5sdqjDslhyUzM1v3m3ZGbhwEOnVjljY6JJLx
MxagxnZZSAY424ZZ3t71E/Mn27dm2w+xFRuoy8JEjv1d+BT3eChM5KaNwrj0IO/y
u8kFIgWYA1vZ/15qMT+tyJTfyrNVV/7Df7TNeWyNqjJ5rBmt0M6NpHG7CrUSkBy9
p8JhimgjP5r0FlEkgg+lyD+V79H98gQfVgP3pbJICz0SpBQf2F/2tyS4rLm+49rP
fcOajiXEuyhpcmzgusAj/1FjrtlynH1r9mnNaX4e+rLWzvU5AgMBAAGjUDBOMB0G
A1UdDgQWBBTkwyoJFGfYTVISTpM8E+igjdq28zAfBgNVHSMEGDAWgBTkwyoJFGfY
TVISTpM8E+igjdq28zAMBgNVHRMEBTADAQH/MA0GCSqGSIb3DQEBBQUAA4ICAQAR
OXnYwu3g1ZjHyley3fZI5aLPsaE17cOImVTehC8DcIphm2HOMR/hYTTL+V0G4P+u
gH+6xeRLKSHMHZTtSBIa6GDL03434y9CBuwGvAFCMU2GV8w92/Z7apkAhdLToZA/
X/iWP2jeaVJhxgEcH8uPrnSlqoPBcKC9PrgUzQYfSZJkLmB+3jEa3HKruy1abJP5
gAdQvwvcPpvYRnIzUc9fZODsVmlHVFBCl2dlu/iHh2h4GmL4Da2rRkUMlbVTdioB
UYIvMycdOkpH5wJftzw7cpjsudGas0PARDXCFfGyKhwBRFY7Xp7lbjtU5Rz0Gc04
lPrhDf0pFE98Aw4jJRpFeWMjpXUEaG1cq7D641RpgcMfPFvOHY47rvDTS7XJOaUT
BwRjmDt896s6vMDcaG/uXJbQjuzmmx3W2Idyh3s5SI0GTHb0IwMKYb4eBUIpQOnB
cE77VnCYqKvN1NVYAqhWjXbY7XasZvszCRcOG+W3FqNaHOK/n/0ueb0uijdLan+U
f4p1bjbAox8eAOQS/8a3bzkJzdyBNUKGx1BIK2IBL9bn/HravSDOiNRSnZ/R3l9G
ZauX0tu7IIDlRCILXSyeazu0aj/vdT3YFQXPcvt5Fkf5wiNTo53f72/jYEJd6qph
WrpoKqrwGwTpRUCMhYIUt65hsTxCiJJ5nKe39h46sg==
-----END CERTIFICATE-----
$ openssl x509 -in sks-keyservers.netCA.pem -text -noout
Certificate:
Data:
Version: 3 (0x2)
Serial Number: 12642669257862119567 (0xaf73c8b4cf9f808f)
Signature Algorithm: sha1WithRSAEncryption
Issuer: C=NO, ST=Oslo, O=sks-keyservers.net CA, CN=sks-keyservers.net CA
Validity
Not Before: Oct 9 00:33:37 2012 GMT
Not After : Oct 7 00:33:37 2022 GMT
Subject: C=NO, ST=Oslo, O=sks-keyservers.net CA, CN=sks-keyservers.net CA
Subject Public Key Info:
Public Key Algorithm: rsaEncryption
Public-Key: (4096 bit)
Modulus:
00:d7:6c:5b:2e:0f:5d:63:54:0a:44:b7:2f:ff:e7:
ad:dd:06:a8:dd:dd:57:0a:01:19:9e:b0:f7:84:f0:
da:33:c3:3e:27:de:83:0c:50:a3:31:57:90:6e:88:
e8:0e:13:2b:50:89:2d:73:ef:7f:3d:14:3f:46:81:
63:23:e6:4c:d6:9d:0e:29:da:07:d4:f8:8c:8c:1d:
e2:b9:f1:97:ee:7d:1a:21:26:aa:43:77:21:f3:ec:
bf:92:63:32:42:94:98:99:ef:39:3d:03:11:59:44:
68:ed:54:64:8c:31:e5:6a:5f:a6:b0:77:99:1f:35:
fe:a9:b8:5e:40:20:99:8a:e6:82:72:d7:77:fa:49:
0c:03:24:ef:2d:45:e3:96:f9:cd:6a:1f:88:3e:65:
eb:be:e5:a6:57:08:3d:16:c5:86:92:7a:90:34:ce:
0d:78:7f:5c:47:6d:17:bd:44:01:e6:8e:74:41:8e:
bf:21:83:98:23:b4:19:6a:92:14:39:0c:30:f4:e5:
89:e2:c0:ff:4a:e0:15:37:33:e3:1c:14:62:3f:dc:
0f:97:b4:64:1b:92:91:8b:18:14:05:37:85:dd:5c:
19:f0:6e:7b:47:0f:65:a4:07:d8:76:31:42:4e:33:
5c:3f:12:dc:5e:3a:f7:47:d1:86:bf:ad:92:2e:60:
c8:6e:89:0d:1e:bb:68:aa:77:04:81:8b:aa:6e:df:
e3:95:a4:5f:58:58:a7:e6:17:cb:09:84:ce:23:38:
69:26:c6:62:1c:7c:86:81:46:7e:af:54:71:f3:c4:
be:9d:9a:a1:cf:2e:e6:c7:6a:8c:3b:25:87:25:33:
33:5b:f7:9b:76:46:6e:1c:04:3a:75:63:96:36:3a:
24:92:f1:33:16:a0:c6:76:59:48:06:38:db:86:59:
de:de:f5:13:f3:27:db:b7:66:db:0f:b1:15:1b:a8:
cb:c2:44:8e:fd:5d:f8:14:f7:78:28:4c:e4:a6:8d:
c2:b8:f4:20:ef:f2:bb:c9:05:22:05:98:03:5b:d9:
ff:5e:6a:31:3f:ad:c8:94:df:ca:b3:55:57:fe:c3:
7f:b4:cd:79:6c:8d:aa:32:79:ac:19:ad:d0:ce:8d:
a4:71:bb:0a:b5:12:90:1c:bd:a7:c2:61:8a:68:23:
3f:9a:f4:16:51:24:82:0f:a5:c8:3f:95:ef:d1:fd:
f2:04:1f:56:03:f7:a5:b2:48:0b:3d:12:a4:14:1f:
d8:5f:f6:b7:24:b8:ac:b9:be:e3:da:cf:7d:c3:9a:
8e:25:c4:bb:28:69:72:6c:e0:ba:c0:23:ff:51:63:
ae:d9:72:9c:7d:6b:f6:69:cd:69:7e:1e:fa:b2:d6:
ce:f5:39
Exponent: 65537 (0x10001)
X509v3 extensions:
X509v3 Subject Key Identifier:
E4:C3:2A:09:14:67:D8:4D:52:12:4E:93:3C:13:E8:A0:8D:DA:B6:F3
X509v3 Authority Key Identifier:
keyid:E4:C3:2A:09:14:67:D8:4D:52:12:4E:93:3C:13:E8:A0:8D:DA:B6:F3
X509v3 Basic Constraints:
CA:TRUE
Signature Algorithm: sha1WithRSAEncryption
11:39:79:d8:c2:ed:e0:d5:98:c7:ca:57:b2:dd:f6:48:e5:a2:
cf:b1:a1:35:ed:c3:88:99:54:de:84:2f:03:70:8a:61:9b:61:
ce:31:1f:e1:61:34:cb:f9:5d:06:e0:ff:ae:80:7f:ba:c5:e4:
4b:29:21:cc:1d:94:ed:48:12:1a:e8:60:cb:d3:7e:37:e3:2f:
42:06:ec:06:bc:01:42:31:4d:86:57:cc:3d:db:f6:7b:6a:99:
00:85:d2:d3:a1:90:3f:5f:f8:96:3f:68:de:69:52:61:c6:01:
1c:1f:cb:8f:ae:74:a5:aa:83:c1:70:a0:bd:3e:b8:14:cd:06:
1f:49:92:64:2e:60:7e:de:31:1a:dc:72:ab:bb:2d:5a:6c:93:
f9:80:07:50:bf:0b:dc:3e:9b:d8:46:72:33:51:cf:5f:64:e0:
ec:56:69:47:54:50:42:97:67:65:bb:f8:87:87:68:78:1a:62:
f8:0d:ad:ab:46:45:0c:95:b5:53:76:2a:01:51:82:2f:33:27:
1d:3a:4a:47:e7:02:5f:b7:3c:3b:72:98:ec:b9:d1:9a:b3:43:
c0:44:35:c2:15:f1:b2:2a:1c:01:44:56:3b:5e:9e:e5:6e:3b:
54:e5:1c:f4:19:cd:38:94:fa:e1:0d:fd:29:14:4f:7c:03:0e:
23:25:1a:45:79:63:23:a5:75:04:68:6d:5c:ab:b0:fa:e3:54:
69:81:c3:1f:3c:5b:ce:1d:8e:3b:ae:f0:d3:4b:b5:c9:39:a5:
13:07:04:63:98:3b:7c:f7:ab:3a:bc:c0:dc:68:6f:ee:5c:96:
d0:8e:ec:e6:9b:1d:d6:d8:87:72:87:7b:39:48:8d:06:4c:76:
f4:23:03:0a:61:be:1e:05:42:29:40:e9:c1:70:4e:fb:56:70:
98:a8:ab:cd:d4:d5:58:02:a8:56:8d:76:d8:ed:76:ac:66:fb:
33:09:17:0e:1b:e5:b7:16:a3:5a:1c:e2:bf:9f:fd:2e:79:bd:
2e:8a:37:4b:6a:7f:94:7f:8a:75:6e:36:c0:a3:1f:1e:00:e4:
12:ff:c6:b7:6f:39:09:cd:dc:81:35:42:86:c7:50:48:2b:62:
01:2f:d6:e7:fc:7a:da:bd:20:ce:88:d4:52:9d:9f:d1:de:5f:
46:65:ab:97:d2:db:bb:20:80:e5:44:22:0b:5d:2c:9e:6b:3b:
b4:6a:3f:ef:75:3d:d8:15:05:cf:72:fb:79:16:47:f9:c2:23:
53:a3:9d:df:ef:6f:e3:60:42:5d:ea:aa:61:5a:ba:68:2a:aa:
f0:1b:04:e9:45:40:8c:85:82:14:b7:ae:61:b1:3c:42:88:92:
79:9c:a7:b7:f6:1e:3a:b2Odcisk oraz ten X509v3 Subject Key Identifier zgadzają się, co oznacza, że wszystko jest w należytym porządku.
Odpowiednia struktura katalogów w folderze domowym użytkownika jest tworzona przy pierwszym wywołaniu programu gpg. W naszym przypadku jeszcze nie ma tam żadnych plików czy folderów i musimy je sobie stworzyć:
morfik@morfikownia:~$ mkdir ~/.gnupg
morfik@morfikownia:~$ touch ~/.gnupg/gpg.confTeraz edytujemy plik ~/.gnupg/gpg.conf i dodajemy do niego poniższe dwa wpisy:
keyserver hkps://hkps.pool.sks-keyservers.net
keyserver-options ca-cert-file=/home/morfik/gpg_ca/sks-keyservers.netCA.pemOd tej chwili cała komunikacja z serwerem kluczy będzie szyfrowana, co utrudni nieco mapowanie naszych kontaktów, tak jak to może mieć miejsce podczas odświeżania kluczy przy pomocy gpg --refresh-keys , w przypadku gdy zapytania lecą tylko po hkp.
Została nam jeszcze jedna rzecz do zrobienia -- weryfikacja klucza RSA:
$ gpg --search-keys 0xd71fd9994af34f0b
gpg: keyring `/home/morfik/.gnupg/secring.gpg' created
gpg: keyring `/home/morfik/.gnupg/pubring.gpg' created
gpg: searching for "0xd71fd9994af34f0b" from hkps server hkps.pool.sks-keyservers.net
(1) https://sks-keyservers.net
https://www.sks-keyservers.net
4096 bit RSA key 0xD71FD9994AF34F0B, created: 2012-08-10
Keys 1-1 of 1 for "0xd71fd9994af34f0b". Enter number(s), N)ext, or Q)uit > 1
gpg: requesting key 0xD71FD9994AF34F0B from hkps server hkps.pool.sks-keyservers.net
gpg: /home/morfik/.gnupg/trustdb.gpg: trustdb created
gpg: key 0xD71FD9994AF34F0B: public key "https://www.sks-keyservers.net" imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
$ gpg --fingerprint 0xd71fd9994af34f0b
pub 4096R/4AF34F0B 2012-08-10
Key fingerprint = 878F FB44 5E6E 13A6 4716 3BDC D71F D999 4AF3 4F0B
uid https://www.sks-keyservers.net
uid https://sks-keyservers.net
$ gpg --list-sigs 0xd71fd9994af34f0b
pub 4096R/4AF34F0B 2012-08-10
uid https://www.sks-keyservers.net
sig E3EDFAE3 2013-10-27 [User ID not found]
sig 3 4AF34F0B 2013-10-27 https://www.sks-keyservers.net
uid https://sks-keyservers.net
sig E3EDFAE3 2012-08-10 [User ID not found]
sig 6B0B9508 2012-08-10 [User ID not found]
sig B75D0607 2013-07-10 [User ID not found]
sig 3 4AF34F0B 2012-08-10 https://www.sks-keyservers.netOdcisk się zgadza ale na stronie podany był ID klucza 0x0B7F8B60E3EDFAE3 , a my tutaj zdaje się nie mamy takiego. Jeśli się przyjrzymy bliżej, mamy tylko coś podobnego -- E3EDFAE3 . W zasadzie klucz można zidentyfikować na trzy sposoby -- po krótkim ID, po długim ID, oraz po odcisku palca. Ten ID, który został wyrzucony przez program gpg, to krótki ID. Na stronie www został podany dłuższy ID. Krótkie ID kluczy są długości 32 bitów i ten ciąg może zostać użyty przez inny klucz. Te dłuższe ID kluczy mają 64 bity ale one też mogą kolidować ze sobą. Jedyne wyjście by być pewnym co do ID klucza, to używanie pełnego odcisku palca danego klucza i nigdy nie powinno się polegać na krótkim czy nawet długim ID klucza. Dlatego, też powinniśmy w konfiguracji gpg uwzględnić poniższe dwie opcje, by to narzędzie pokazywało nam ten dłuższy ID oraz za każdym razem wyświetlało odcisk palca danego klucza:
keyid-format 0xlong
with-fingerprintJeśli teraz byśmy sprawdzili sygnatury, otrzymamy:
$ gpg --list-sigs 0xd71fd9994af34f0b
pub 4096R/0xD71FD9994AF34F0B 2012-08-10
Key fingerprint = 878F FB44 5E6E 13A6 4716 3BDC D71F D999 4AF3 4F0B
uid https://www.sks-keyservers.net
sig 0x0B7F8B60E3EDFAE3 2013-10-27 [User ID not found]
sig 3 0xD71FD9994AF34F0B 2013-10-27 https://www.sks-keyservers.net
uid https://sks-keyservers.net
sig 0x0B7F8B60E3EDFAE3 2012-08-10 [User ID not found]
sig 0x16E0CF8D6B0B9508 2012-08-10 [User ID not found]
sig 0x6D26C19CB75D0607 2013-07-10 [User ID not found]
sig 3 0xD71FD9994AF34F0B 2012-08-10 https://www.sks-keyservers.netJeśli jeszcze chodzi o klucze pobierane z publicznych keyserwerów, to trzeba się mieć na baczności, bo te klucze mogą należeć do każdego i bez weryfikacji osoby, która stoi za danym kluczem, nie da się tak naprawdę powiedzieć czy mamy do czynienia z tym kimś -- równie dobrze można dodać pierwszy lepszy klucz i mieć poczucie, że jest się bezpiecznym. Po zweryfikowaniu odciska palca klucza, sam klucz można pobrać z serwera kluczy posługując się poniższym poleceniem:
$ gpg --recv-key '878F FB44 5E6E 13A6 4716 3BDC D71F D999 4AF3 4F0B'
gpg: requesting key 0xD71FD9994AF34F0B from hkps server hkps.pool.sks-keyservers.net
gpg: key 0xD71FD9994AF34F0B: "https://www.sks-keyservers.net" not changed
gpg: Total number processed: 1
gpg: unchanged: 1Jak widać wyżej, klucz nie został pobrany, bo już siedzi u nas w keyringu. Apostrofy są wymagane by to polecenie zadziałało.
Niektóre osoby tworzące klucze gpg mogą zdefiniować określony serwer, z którego ich klucz ma być pobrany i dlatego też musimy wymusić odświeżanie kluczy w oparciu o zdefiniowany serwer kluczy. Wobec czego zalecane jest by dodać poniższą opcję do pliku konfiguracyjnego gpg:
keyserver-options no-honor-keyserver-urlKlucz RSA powinien używać hasha sha512. By nakazać gpg by używał tego konkretnego hasha, dodajemy do pliku konfiguracyjnego poniższe linijki:
cert-digest-algo SHA512
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP UncompressedPlik ~/.gnupg/gpg.conf
Poniżej jest wzór pliku konfiguracyjnego gpg -- trzeba tylko przejrzeć go i dostosować odpowiednie parametry:
#
# This is an implementation of the Riseup OpenPGP Best Practices
# https://help.riseup.net/en/security/message-security/openpgp/best-practices
#
#-----------------------------
# default key
#-----------------------------
# The default key to sign with. If this option is not used, the default key is
# the first key found in the secret keyring
#default-key 0xD8692123C4065DEA5E0F3AB5249B39D24F25E3B6
#-----------------------------
# behavior
#-----------------------------
# Disable inclusion of the version string in ASCII armored output
no-emit-version
# Disable comment string in clear text signatures and ASCII armored messages
no-comments
# Display long key IDs
keyid-format 0xlong
# List all keys (or the specified ones) along with their fingerprints
with-fingerprint
# Display the calculated validity of user IDs during key listings
list-options show-uid-validity
verify-options show-uid-validity
# Try to use the GnuPG-Agent. With this option, GnuPG first tries to connect to
# the agent before it asks for a passphrase.
use-agent
#-----------------------------
# keyserver
#-----------------------------
# This is the server that --recv-keys, --send-keys, and --search-keys will
# communicate with to receive keys from, send keys to, and search for keys on
keyserver hkps://hkps.pool.sks-keyservers.net
# Provide a certificate store to override the system default
# Get this from https://sks-keyservers.net/sks-keyservers.netCA.pem
keyserver-options ca-cert-file=/usr/local/etc/ssl/certs/hkps.pool.sks-keyservers.net.pem
# Set the proxy to use for HTTP and HKP keyservers - default to the standard
# local Tor socks proxy
# It is encouraged to use Tor for improved anonymity. Preferrably use either a
# dedicated SOCKSPort for GnuPG and/or enable IsolateDestPort and
# IsolateDestAddr
#keyserver-options http-proxy=socks5-hostname://127.0.0.1:9050
# Don't leak DNS, see https://trac.torproject.org/projects/tor/ticket/2846
keyserver-options no-try-dns-srv
# When using --refresh-keys, if the key in question has a preferred keyserver
# URL, then disable use of that preferred keyserver to refresh the key from
keyserver-options no-honor-keyserver-url
# When searching for a key with --search-keys, include keys that are marked on
# the keyserver as revoked
keyserver-options include-revoked
#-----------------------------
# algorithm and ciphers
#-----------------------------
# list of personal digest preferences. When multiple digests are supported by
# all recipients, choose the strongest one
personal-cipher-preferences AES256 AES192 AES CAST5
# list of personal digest preferences. When multiple ciphers are supported by
# all recipients, choose the strongest one
personal-digest-preferences SHA512 SHA384 SHA256 SHA224
# message digest algorithm used when signing a key
cert-digest-algo SHA512
# This preference list is used for new keys and becomes the default for
# "setpref" in the edit menu
default-preference-list SHA512 SHA384 SHA256 SHA224 AES256 AES192 AES CAST5 ZLIB BZIP2 ZIP UncompressedTworzenie dobrego klucza gpg
Mając już przygotowany plik ~/.gnupg/gpg.conf , możemy przejść do tworzenia klucza gpg. Dobry klucz nie powinien być krótszy niż 4096 bitów. Dodatkowo, nie powinno się ustawiać daty ważności klucza dłuższej niż 2 lata, a to z tego powodu, że zawszę tę datę można zmienić i to nawet w przypadku gdy klucz straci ważność. Chodzi generalnie o ustawienie jakiegoś mechanizmu zabezpieczającego na wypadek gdybyśmy stracili panowanie nad kluczem -- wtedy po jakimś czasie automatycznie się on unieważni i nie będziemy musieli się martwić czy ktoś może przez przypadek go używać.
Generowanie klucza
By stworzyć parę kluczy gpg, wpisujemy w terminalu poniższe polecenie:
$ gpg --gen-key
gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Please select what kind of key you want:
(1) RSA and RSA (default)
(2) DSA and Elgamal
(3) DSA (sign only)
(4) RSA (sign only)
Your selection? 1
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 2y
Key expires at Tue 20 Sep 2016 07:02:57 PM CEST
Is this correct? (y/N) y
You need a user ID to identify your key; the software constructs the user ID
from the Real Name, Comment and Email Address in this form:
"Heinrich Heine (Der Dichter) <[email protected]>"
Real name: Mikhail Morfikov
Email address: [email protected]
Comment: testing key
You selected this USER-ID:
"Mikhail Morfikov (testing key) <[email protected]>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a Passphrase to protect your secret key.
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 241 more bytes)
....+++++
gpg: key 0x0339957BF6449112 marked as ultimately trusted
public and secret key created and signed.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2016-09-20
pub 4096R/0x0339957BF6449112 2014-09-21 [expires: 2016-09-20]
Key fingerprint = 6DF3 C313 A0FE 1E7F 168D F9DC 0339 957B F644 9112
uid Mikhail Morfikov (testing key) <[email protected]>
sub 4096R/0x9845A1DBE59AC095 2014-09-21 [expires: 2016-09-20]Wiele tożsamości w jednym kluczu
W przypadku kiedy mamy wiele kont email, to zamiast tworzyć osobne klucze dla każdego z nich, możemy stworzyć wiele tożsamości w tym samym kluczu gpg:
$ gpg --edit-key 0x0339957BF6449112
gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub 4096R/0x0339957BF6449112 created: 2014-09-21 expires: 2016-09-20 usage: SC
trust: ultimate validity: ultimate
sub 4096R/0x9845A1DBE59AC095 created: 2014-09-21 expires: 2016-09-20 usage: E
[ultimate] (1). Mikhail Morfikov (testing key) <[email protected]>
gpg> adduid
Real name: Mikhail Morfikov
Email address: [email protected]
Comment: another testing key
You selected this USER-ID:
"Mikhail Morfikov (another testing key) <[email protected]>"
Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit? O
You need a passphrase to unlock the secret key for
user: "Mikhail Morfikov (testing key) <[email protected]>"
4096-bit RSA key, ID 0x0339957BF6449112, created 2014-09-21
pub 4096R/0x0339957BF6449112 created: 2014-09-21 expires: 2016-09-20 usage: SC
trust: ultimate validity: ultimate
sub 4096R/0x9845A1DBE59AC095 created: 2014-09-21 expires: 2016-09-20 usage: E
[ultimate] (1) Mikhail Morfikov (testing key) <[email protected]>
[ unknown] (2). Mikhail Morfikov (another testing key) <[email protected]>
gpg> savePodział podkluczy
Dobrze jest mieć także osobny klucz (klucz główny) do podpisów cyfrowych oraz inny podklucz używany do szyfrowania -- tak jak to widać wyżej, chodzi o usage: SC i E. Można też mieć dwa różne podklucze -- jeden do podpisów, drugi do szyfrowania i nie używać klucza głównego w ogóle. Jako, że mamy osobny podklucz do szyfrowania, dodajmy podklucz do podpisów:
$ gpg --edit-key 0x0339957BF6449112
gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2016-09-20
pub 4096R/0x0339957BF6449112 created: 2014-09-21 expires: 2016-09-20 usage: SC
trust: ultimate validity: ultimate
sub 4096R/0x9845A1DBE59AC095 created: 2014-09-21 expires: 2016-09-20 usage: E
[ultimate] (1). Mikhail Morfikov (another testing key) <[email protected]>
[ultimate] (2) Mikhail Morfikov (testing key) <[email protected]>
gpg> addkey
Key is protected.
You need a passphrase to unlock the secret key for
user: "Mikhail Morfikov (another testing key) <[email protected]>"
4096-bit RSA key, ID 0x0339957BF6449112, created 2014-09-21
Please select what kind of key you want:
(3) DSA (sign only)
(4) RSA (sign only)
(5) Elgamal (encrypt only)
(6) RSA (encrypt only)
Your selection? 4
RSA keys may be between 1024 and 4096 bits long.
What keysize do you want? (2048) 4096
Requested keysize is 4096 bits
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 2y
Key expires at Tue 20 Sep 2016 07:31:43 PM CEST
Is this correct? (y/N) y
Really create? (y/N) y
We need to generate a lot of random bytes. It is a good idea to perform
some other action (type on the keyboard, move the mouse, utilize the
disks) during the prime generation; this gives the random number
generator a better chance to gain enough entropy.
Not enough random bytes available. Please do some other work to give
the OS a chance to collect more entropy! (Need 212 more bytes)
.............+++++
pub 4096R/0x0339957BF6449112 created: 2014-09-21 expires: 2016-09-20 usage: SC
trust: ultimate validity: ultimate
sub 4096R/0x9845A1DBE59AC095 created: 2014-09-21 expires: 2016-09-20 usage: E
sub 4096R/0xDBA0A9602AF715C1 created: 2014-09-21 expires: 2016-09-20 usage: S
[ultimate] (1) Mikhail Morfikov (another testing key) <[email protected]>
[ultimate] (2)* Mikhail Morfikov (testing key) <[email protected]>
gpg> saveJak widzimy wyżej, został utworzony drugi podklucz i przy jego pozycji jest widoczny usage: S .
Główny UID
Mając utworzonych kilka UID w kluczu, trzeba sprecyzować jeden z nich jako główny:
$ gpg --edit-key 0x0339957BF6449112
gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
pub 4096R/0x0339957BF6449112 created: 2014-09-21 expires: 2016-09-20 usage: SC
trust: ultimate validity: ultimate
sub 4096R/0x9845A1DBE59AC095 created: 2014-09-21 expires: 2016-09-20 usage: E
sub 4096R/0xDBA0A9602AF715C1 created: 2014-09-21 expires: 2016-09-20 usage: S
[ultimate] (1). Mikhail Morfikov (another testing key) <[email protected]>
[ultimate] (2) Mikhail Morfikov (testing key) <[email protected]>
gpg> uid 2
pub 4096R/0x0339957BF6449112 created: 2014-09-21 expires: 2016-09-20 usage: SC
trust: ultimate validity: ultimate
sub 4096R/0x9845A1DBE59AC095 created: 2014-09-21 expires: 2016-09-20 usage: E
sub 4096R/0xDBA0A9602AF715C1 created: 2014-09-21 expires: 2016-09-20 usage: S
[ultimate] (1). Mikhail Morfikov (another testing key) <[email protected]>
[ultimate] (2)* Mikhail Morfikov (testing key) <[email protected]>
gpg> primary
You need a passphrase to unlock the secret key for
user: "Mikhail Morfikov (another testing key) <[email protected]>"
4096-bit RSA key, ID 0x0339957BF6449112, created 2014-09-21
pub 4096R/0x0339957BF6449112 created: 2014-09-21 expires: 2016-09-20 usage: SC
trust: ultimate validity: ultimate
sub 4096R/0x9845A1DBE59AC095 created: 2014-09-21 expires: 2016-09-20 usage: E
sub 4096R/0xDBA0A9602AF715C1 created: 2014-09-21 expires: 2016-09-20 usage: S
[ultimate] (1) Mikhail Morfikov (another testing key) <[email protected]>
[ultimate] (2)* Mikhail Morfikov (testing key) <[email protected]>
gpg> save
$Zmiana daty ważności klucza
Za każdym razem gdy zmienimy datę ważności, klucz trzeba wysłać do servera kluczy, by poinformować innych o zmianach jakie przeprowadziliśmy. Datę ważności można ustawić osobno dla klucza głównego oraz dla każdego z podkluczy. My mamy póki co jeden klucz główny oraz dwa podklucze, zatem potrzebujemy zmienić trzy daty:
$ gpg --edit-key 0x0339957BF6449112
gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Secret key is available.
gpg: checking the trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2016-09-20
pub 4096R/0x0339957BF6449112 created: 2014-09-21 expires: 2016-09-20 usage: SC
trust: ultimate validity: ultimate
sub 4096R/0x9845A1DBE59AC095 created: 2014-09-21 expires: 2016-09-20 usage: E
sub 4096R/0xDBA0A9602AF715C1 created: 2014-09-21 expires: 2016-09-20 usage: S
[ultimate] (1). Mikhail Morfikov (testing key) <[email protected]>
[ultimate] (2) Mikhail Morfikov (another testing key) <[email protected]>
gpg> expire
Changing expiration time for the primary key.
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 1y
Key expires at Mon 21 Sep 2015 08:43:10 PM CEST
Is this correct? (y/N) y
You need a passphrase to unlock the secret key for
user: "Mikhail Morfikov (testing key) <[email protected]>"
4096-bit RSA key, ID 0x0339957BF6449112, created 2014-09-21
pub 4096R/0x0339957BF6449112 created: 2014-09-21 expires: 2015-09-21 usage: SC
trust: ultimate validity: ultimate
sub 4096R/0x9845A1DBE59AC095 created: 2014-09-21 expires: 2016-09-20 usage: E
sub 4096R/0xDBA0A9602AF715C1 created: 2014-09-21 expires: 2016-09-20 usage: S
[ultimate] (1). Mikhail Morfikov (testing key) <[email protected]>
[ultimate] (2) Mikhail Morfikov (another testing key) <[email protected]>
gpg> key 1
pub 4096R/0x0339957BF6449112 created: 2014-09-21 expires: 2015-09-21 usage: SC
trust: ultimate validity: ultimate
sub* 4096R/0x9845A1DBE59AC095 created: 2014-09-21 expires: 2016-09-20 usage: E
sub 4096R/0xDBA0A9602AF715C1 created: 2014-09-21 expires: 2016-09-20 usage: S
[ultimate] (1). Mikhail Morfikov (testing key) <[email protected]>
[ultimate] (2) Mikhail Morfikov (another testing key) <[email protected]>
gpg> expire
Changing expiration time for a subkey.
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 1y
Key expires at Mon 21 Sep 2015 08:43:24 PM CEST
Is this correct? (y/N) y
You need a passphrase to unlock the secret key for
user: "Mikhail Morfikov (testing key) <[email protected]>"
4096-bit RSA key, ID 0x0339957BF6449112, created 2014-09-21
pub 4096R/0x0339957BF6449112 created: 2014-09-21 expires: 2015-09-21 usage: SC
trust: ultimate validity: ultimate
sub* 4096R/0x9845A1DBE59AC095 created: 2014-09-21 expires: 2015-09-21 usage: E
sub 4096R/0xDBA0A9602AF715C1 created: 2014-09-21 expires: 2016-09-20 usage: S
[ultimate] (1). Mikhail Morfikov (testing key) <[email protected]>
[ultimate] (2) Mikhail Morfikov (another testing key) <[email protected]>
gpg> key 1
pub 4096R/0x0339957BF6449112 created: 2014-09-21 expires: 2015-09-21 usage: SC
trust: ultimate validity: ultimate
sub 4096R/0x9845A1DBE59AC095 created: 2014-09-21 expires: 2015-09-21 usage: E
sub 4096R/0xDBA0A9602AF715C1 created: 2014-09-21 expires: 2016-09-20 usage: S
[ultimate] (1). Mikhail Morfikov (testing key) <[email protected]>
[ultimate] (2) Mikhail Morfikov (another testing key) <[email protected]>
gpg> key 2
pub 4096R/0x0339957BF6449112 created: 2014-09-21 expires: 2015-09-21 usage: SC
trust: ultimate validity: ultimate
sub 4096R/0x9845A1DBE59AC095 created: 2014-09-21 expires: 2015-09-21 usage: E
sub* 4096R/0xDBA0A9602AF715C1 created: 2014-09-21 expires: 2016-09-20 usage: S
[ultimate] (1). Mikhail Morfikov (testing key) <[email protected]>
[ultimate] (2) Mikhail Morfikov (another testing key) <[email protected]>
gpg> expire
Changing expiration time for a subkey.
Please specify how long the key should be valid.
0 = key does not expire
<n> = key expires in n days
<n>w = key expires in n weeks
<n>m = key expires in n months
<n>y = key expires in n years
Key is valid for? (0) 1y
Key expires at Mon 21 Sep 2015 08:43:46 PM CEST
Is this correct? (y/N) y
You need a passphrase to unlock the secret key for
user: "Mikhail Morfikov (testing key) <[email protected]>"
4096-bit RSA key, ID 0x0339957BF6449112, created 2014-09-21
pub 4096R/0x0339957BF6449112 created: 2014-09-21 expires: 2015-09-21 usage: SC
trust: ultimate validity: ultimate
sub 4096R/0x9845A1DBE59AC095 created: 2014-09-21 expires: 2015-09-21 usage: E
sub* 4096R/0xDBA0A9602AF715C1 created: 2014-09-21 expires: 2015-09-21 usage: S
[ultimate] (1). Mikhail Morfikov (testing key) <[email protected]>
[ultimate] (2) Mikhail Morfikov (another testing key) <[email protected]>
gpg> saveW powyższym przykładzie zmieniliśmy datę ważności z 2 lat na 1 rok.
Certyfikat unieważniający
Dobrze jest także wygenerować sobie certyfikat unieważniający klucz główny -- na wypadek gdybyśmy zapomnieli hasła do klucza, zgubili go, czy zostałby on skompromitowany. Z tym, że tego certyfikatu trzeba strzec, bo jeśli dostanie się w niepowołane ręce, ten ktoś będzie mógł bez problemu unieważnić nasz klucz główny. Generujemy certyfikat:
$ gpg --output 0x0339957BF6449112.gpg-revocation-certificate --armor --gen-revoke 0x0339957BF6449112
sec 4096R/0x0339957BF6449112 2014-09-21 Mikhail Morfikov (testing key) <[email protected]>
Create a revocation certificate for this key? (y/N) y
Please select the reason for the revocation:
0 = No reason specified
1 = Key has been compromised
2 = Key is superseded
3 = Key is no longer used
Q = Cancel
(Probably you want to select 1 here)
Your decision? 1
Enter an optional description; end it with an empty line:
> This revocation certificate was generated when the key was created.
>
Reason for revocation: Key has been compromised
This revocation certificate was generated when the key was created.
Is this okay? (y/N) y
You need a passphrase to unlock the secret key for
user: "Mikhail Morfikov (testing key) <[email protected]>"
4096-bit RSA key, ID 0x0339957BF6449112, created 2014-09-21
Revocation certificate created.
Please move it to a medium which you can hide away; if Mallory gets
access to this certificate he can use it to make your key unusable.
It is smart to print this certificate and store it away, just in case
your media become unreadable. But have some caution: The print system of
your machine might store the data and make it available to others!W katalogu, w którym wydaliśmy powyższe polecenie został utworzony plik 0x0339957BF6449112.gpg-revocation-certificate i to za jego pomocą można unieważnić klucz. Jeśli kiedyś by zaszła potrzeba unieważnienia certyfikatu, importujemy ten plik jak zwykły certyfikat:
$ gpg --import 0x0339957BF6449112.gpg-revocation-certificate
gpg: key 0x0339957BF6449112: "Mikhail Morfikov (testing key) <[email protected]>" revocation certificate imported
gpg: Total number processed: 1
gpg: new key revocations: 1
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0 valid: 1 signed: 0 trust: 0-, 0q, 0n, 0m, 0f, 1u
gpg: next trustdb check due at 2016-09-20I sprawdzamy, czy klucz został cofnięty:
$ gpg --list-keys
/home/morfik/.gnupg/pubring.gpg
--------------------------------
pub 4096R/0xD71FD9994AF34F0B 2012-08-10
Key fingerprint = 878F FB44 5E6E 13A6 4716 3BDC D71F D999 4AF3 4F0B
uid https://www.sks-keyservers.net
uid https://sks-keyservers.net
pub 4096R/0x0339957BF6449112 2014-09-21 [revoked: 2014-09-21]
Key fingerprint = 6DF3 C313 A0FE 1E7F 168D F9DC 0339 957B F644 9112
uid Mikhail Morfikov (testing key) <[email protected]>
uid Mikhail Morfikov (another testing key) <[email protected]>Przy naszym kluczu widnieje revoked , czyli z tego klucza się już nie da skorzystać. Jedyne co nam jeszcze pozostaje do zrobienia to wysłanie zaktualizowanych informacji do serwera kluczy via gpg --send-keys .
Przesyłanie nowego klucza do serwera kluczy
Po tym jak się przestaniemy bawić kluczami, musimy je przesłać do serwera kluczy. Robimy to w poniższy sposób:
$ gpg --send-key 0x0339957BF6449112
gpg: sending key 0x0339957BF6449112 to hkps server hkps.pool.sks-keyservers.netDla sprawdzenia, czy faktycznie klucz został wyeksportowany na publiczny serwer kluczy, przeszukajmy serwery pod kątem naszego klucza:
$ gpg --search-keys 0x0339957BF6449112
gpg: searching for "0x0339957BF6449112" from hkps server hkps.pool.sks-keyservers.net
(1) Mikhail Morfikov (testing key) <[email protected]>
Mikhail Morfikov (another testing key) <[email protected]>
4096 bit RSA key 0x0339957BF6449112, created: 2014-09-21, expires: 2015-09-21
Keys 1-1 of 1 for "0x0339957BF6449112". Enter number(s), N)ext, or Q)uit >Czasem klucz może nie zostać odnaleziony za pierwszym razem. To nie jest błąd tylko tak działają te serwery w puli -- nie zostaliśmy podłączeni do tego, który jest w posiadaniu naszego klucza. Po paru chwilach, wszystkie serwery sobie wymienią ten klucz automatycznie i kopia naszego klucza będzie dostępna bez problemu na każdym z nich, także bez obaw.
Usuwanie klucza głównego
Najpierw wykonajmy backup katalogu ~/.gnupg/ . Następnie eksportujemy podklucze do pliku, po czym usuwamy klucz główny z keyringa systemowego i dodajemy podklucze bez klucza prywatnego:
$ cp -a ~/.gnupg/ ~/.gnupg.back/
$ gpg -K
/home/morfik/.gnupg/secring.gpg
--------------------------------
sec 4096R/0x0339957BF6449112 2014-09-21 [expires: 2016-09-20]
Key fingerprint = 6DF3 C313 A0FE 1E7F 168D F9DC 0339 957B F644 9112
uid Mikhail Morfikov (testing key) <[email protected]>
uid Mikhail Morfikov (another testing key) <[email protected]>
ssb 4096R/0x9845A1DBE59AC095 2014-09-21
ssb 4096R/0xDBA0A9602AF715C1 2014-09-21
$ gpg --export-secret-subkeys 0x9845A1DBE59AC095! 0xDBA0A9602AF715C1! > subkeys
$ gpg --export 0x0339957BF6449112 > pubkeys
$ gpg --delete-secret-key 0x0339957BF6449112
gpg (GnuPG) 1.4.18; Copyright (C) 2014 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
sec 4096R/0x0339957BF6449112 2014-09-21 Mikhail Morfikov (testing key) <[email protected]>
Delete this key from the keyring? (y/N) y
This is a secret key! - really delete? (y/N) y
$ gpg --import pubkeys subkeys
gpg: key 0x0339957BF6449112: "Mikhail Morfikov (testing key) <[email protected]>" not changed
gpg: key 0x0339957BF6449112: secret key imported
gpg: key 0x0339957BF6449112: "Mikhail Morfikov (testing key) <[email protected]>" 1 new signature
gpg: Total number processed: 2
gpg: unchanged: 1
gpg: new signatures: 1
gpg: secret keys read: 1
gpg: secret keys imported: 1Teraz jeszcze zweryfikujmy czy jest tam klucz prywatny:
$ gpg -K
/home/morfik/.gnupg/secring.gpg
--------------------------------
sec# 4096R/0x0339957BF6449112 2014-09-21 [expires: 2016-09-20]
Key fingerprint = 6DF3 C313 A0FE 1E7F 168D F9DC 0339 957B F644 9112
uid Mikhail Morfikov (testing key) <[email protected]>
uid Mikhail Morfikov (another testing key) <[email protected]>
ssb 4096R/0x9845A1DBE59AC095 2014-09-21
ssb 4096R/0xDBA0A9602AF715C1 2014-09-21Pamiętajmy by zaktualizować informacje o kluczu na serwerze kluczy, jak i również o skopiowaniu plików, które potworzyliśmy podczas operacji usuwania klucza prywatnego, gdzieś w bezpieczne, zaszyfrowane miejsce.
Hash w sec# wskazuje, że może i info o kluczy prywatnym jest wyświetlane ale samego klucza jako takiego tam nie ma.
Test klucza gpg
Mając już własny klucz, sprawdźmy czy przejdzie on testy bezpieczeństwa. W tym celu potrzebne będą nam narzędzia zawarte w pakiecie hopenpgp-tools . Testujemy klucz:
$ hkt export-pubkeys '6DF3 C313 A0FE 1E7F 168D F9DC 0339 957B F644 9112' | hokey lint
hokey (hopenpgp-tools) 0.9.1
Copyright (C) 2012-2014 Clint Adams
hokey comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions.
hkt (hopenpgp-tools) 0.9.1
Copyright (C) 2012-2014 Clint Adams
hkt comes with ABSOLUTELY NO WARRANTY.
This is free software, and you are welcome to redistribute it
under certain conditions.
Key has potential validity: good
Key has fingerprint: 6DF3 C313 A0FE 1E7F 168D F9DC 0339 957B F644 9112
Checking to see if key is OpenPGPv4: V4
Checking to see if key is RSA or DSA (>= 2048-bit): RSA 4096
Checking user-ID- and user-attribute-related items:
Mikhail Morfikov (another testing key) <[email protected]>:
Self-sig hash algorithms: [SHA512]
Preferred hash algorithms:
[SHA512,SHA384,SHA256,SHA224]
Key expiration times:
[1y11m29d81000s = Tue Sep 20 17:04:03 UTC 2016]
Mikhail Morfikov (testing key) <[email protected]>:
Self-sig hash algorithms: [SHA512]
Preferred hash algorithms:
[SHA512,SHA384,SHA256,SHA224]
Key expiration times:
[1y11m29d81000s = Tue Sep 20 17:04:03 UTC 2016]Poprawny klucz powinien przejść wszystkie etapy testu. Jeśli z jakiegoś powodu gdzieś się zapali czerwona lampka, znaczy, że przydałoby się poprawić coś w naszym kluczu. Na szczęście nie ma takiej potrzeby i mój klucz przeszedł test bez problemu.
Test szyfrowania/podpisywania
Jako, że nasz klucz nie posiada już części prywatnej, przydałoby się sprawdzić czy ten klucz jest użyteczny, czyli czy potrafi szyfrować, deszyfrować i podpisywać wiadomości. Poniżej jest przeprowadzony test szyfrowania kawałka tekstu:
$ touch wiadomosc
$ echo "To jest bardzo tajny text" > wiadomosc
$ gpg --encrypt --armor -r [email protected] wiadomosc
You need a passphrase to unlock the secret key for
user: "Mikhail Morfikov (testing key) <[email protected]>"
4096-bit RSA key, ID 0xDBA0A9602AF715C1, created 2014-09-21
(subkey on main key ID 0x0339957BF6449112)Wygląda na to, że gpg zaszyfrował wiadomość -- można to także poznać po utworzeniu pliku wiadomosc.asc , w którym to mamy blok tekstu ujęty w -----BEGIN PGP MESSAGE----- oraz -----END PGP MESSAGE----- .
Spróbujmy teraz odszyfrować tę wiadomość:
$ gpg --decrypt wiadomosc.asc
You need a passphrase to unlock the secret key for
user: "Mikhail Morfikov (testing key) <[email protected]>"
4096-bit RSA key, ID 0x9845A1DBE59AC095, created 2014-09-21
(subkey on main key ID 0x0339957BF6449112)
gpg: encrypted with 4096-bit RSA key, ID 0x9845A1DBE59AC095, created 2014-09-21
"Mikhail Morfikov (testing key) <[email protected]>"
To jest bardzo tajny textJak widzimy powyżej, wiadomość została odszyfrowana.
Spróbujmy teraz podpisać zaszyfrowaną wiadomość:
$ gpg --encrypt --sign --armor -r [email protected] wiadomosc
You need a passphrase to unlock the secret key for
user: "Mikhail Morfikov (testing key) <[email protected]>"
4096-bit RSA key, ID 0xDBA0A9602AF715C1, created 2014-09-21
(subkey on main key ID 0x0339957BF6449112)Odszyfrowanie i weryfikacja podpisu:
$ gpg --decrypt wiadomosc.asc
You need a passphrase to unlock the secret key for
user: "Mikhail Morfikov (testing key) <[email protected]>"
4096-bit RSA key, ID 0x9845A1DBE59AC095, created 2014-09-21
(subkey on main key ID 0x0339957BF6449112)
gpg: encrypted with 4096-bit RSA key, ID 0x9845A1DBE59AC095, created 2014-09-21
"Mikhail Morfikov (testing key) <[email protected]>"
To jest bardzo tajny text
gpg: Signature made Sun 21 Sep 2014 10:14:46 PM CEST
gpg: using RSA key 0xDBA0A9602AF715C1
gpg: Good signature from "Mikhail Morfikov (testing key) <[email protected]>"
gpg: aka "Mikhail Morfikov (another testing key) <[email protected]>"
Primary key fingerprint: 6DF3 C313 A0FE 1E7F 168D F9DC 0339 957B F644 9112
Subkey fingerprint: 3CDD 36C1 9AF3 4E60 60E6 6103 DBA0 A960 2AF7 15C1Informacja o Good signature mówi sama za siebie.
Jeszcze tak tylko w ramach formalności, utwórzmy sobie podpis dołączony do wiadomości, bez jej szyfrowania:
$ gpg --clearsign -r [email protected] wiadomosc
gpg: WARNING: recipients (-r) given without using public key encryption
You need a passphrase to unlock the secret key for
user: "Mikhail Morfikov (testing key) <[email protected]>"
4096-bit RSA key, ID 0xDBA0A9602AF715C1, created 2014-09-21
(subkey on main key ID 0x0339957BF6449112)
$ cat wiadomosc.asc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
To jest bardzo tajny text
-----BEGIN PGP SIGNATURE-----
iQIcBAEBCgAGBQJUHz+gAAoJEM0EaBB3G2UgdBAQANhe27VYRSr+rz2NQYQIgGak
QlbBXZiV37gRtDjgiskHaCenlhLN7GuApRXMIaEgbruC25ukc/v3uBomSHf/CgU+
5ORPE/9hJOoc2uqTeVfBO+jaNEQEFV0+LJLIa1uSM6F6cAmsdMfZKQqSpi7Jbfv/
FEfqYbkCPthELmBkF9My8oarh8lHFrNA6/VxG9xQI6/ht1SgYaMFBxGCVT2sgLN9
4SVDs89JwXwEf6oZzKYfE7xdR2iyOHAHQMuTdmEV76nqDkP+aFAp66AOsIKxn/9C
bUhxM9Bn23uW2YE3yy0PVk3GiK7gKqGv2oJWfBPef98jlzjk0kHSwCkAHzn/j4q4
GqOpjAZRgxw/63P2+8eBN9n7YPO7F5D8/snwpGOSRK5rEzMoQO+/o6rSh9HnTCMX
5bLP6NLTG1r7l44wJ/a7nYDy3FaEnpQjyTV1K93yhzsHufvGzwccf+62JiT8tuM5
AdAnhHbWHuIAxFRN8vjWRkc3XVPUeztmBHhWROxsUcZZZHx09ruRtmIqZbwqKg/q
kC/dvMzAhTRHjghYZaQ28raUovQ4saAOZ+88pnXzikAoMCyoFWFqamayPT2j1c5p
G8rGFsOWGkfNdF498+eMB13NcpSGcXB9bN7N/DU6/PaeIcWp9knp/eHqAW4pToTd
dNkJw0YT4gR1IUdWTm7M
=lstD
-----END PGP SIGNATURE-----Teraz jeszcze weryfikujemy powyższą sygnaturę:
$ gpg --verify wiadomosc.asc
gpg: Signature made Sun 21 Sep 2014 10:18:54 PM CEST
gpg: using RSA key 0xDBA0A9602AF715C1
gpg: Good signature from "Mikhail Morfikov (testing key) <[email protected]>"
gpg: aka "Mikhail Morfikov (another testing key) <[email protected]>"
Primary key fingerprint: 6DF3 C313 A0FE 1E7F 168D F9DC 0339 957B F644 9112
Subkey fingerprint: 3CDD 36C1 9AF3 4E60 60E6 6103 DBA0 A960 2AF7 15C1Do poczytania
http://wiki.openwrt.org/doc/techref/signature.authentication
https://we.riseup.net/riseuphelp+en/riseup-ca
http://ekaia.org/blog/2009/05/10/creating-new-gpgkey/
https://help.riseup.net/security/message-security/openpgp/best-practices
https://www.gnupg.org/gph/en/manual/book1.html
