Jak zweryfikować certyfikat HKPS sks-keyservers?


1

Próbuję zrozumieć, w jaki sposób PGP powinno być bezpiecznie używane, ale spójne i pomocne informacje na ten temat są zaskakująco trudne do znalezienia.

Tak więc serwery kluczy SKS dostarczają swój certyfikat HKPS wraz z następującymi informacjami:

  1. Link do pobrania certyfikatu
  2. Link do pobrania podpisu OpenPGP
  3. Link do pobrania listy CRL (lista odwołania certyfikatów?)
  4. Odcisk palca certyfikatu: 79:1B:27:A3:8E:66:7F:80:27:81:4D:4E:68:E7:C4:78:A4:5D:5A:17
  5. Identyfikator klucza podmiotu X509v3: E4 C3 2A 09 14 67 D8 4D 52 12 4E 93 3C 13 E8 A0 8D DA B6 F3

Mam tylko swoją stronę gpg (GnuPG) 2.2.10i dostęp do Internetu.

Moje pytania to:

  • Jak należy wykorzystać każdą informację?
  • Jak mam ustalić, którego klucz publiczny powinienem pobrać osobno z serwera kluczy (aby nie ufać samej stronie)?

Odpowiedzi:


0

Po pierwsze, należy pamiętać, że można całkowicie pominąć cały proces, ponieważ certyfikat CA puli SKS jest dołączony do najnowszych dystrybucji GnuPG - zwykle znajdujących się pod adresem /usr/share/gnupg/sks-keyservers.netCA.pem.

Po drugie, zauważ, że użycie HKPS nie uwierzytelnia danych przechowywanych w puli. Jest to tylko środek ochrony prywatności (aby zapobiec ujawnieniu całego breloka przez --refresh-keys). Ale rzeczywiste blokady klawiszy PGP pobrane z serwerów kluczy nadal muszą być weryfikowane w taki sam sposób, jak zawsze. Oznacza to, że nadal musisz zweryfikować odcisk palca każdego importowanego klucza lub polegać na Web-of-Trust lub tofu.db GnuPG.

Więc jeśli chodzi o:

Jak mam ustalić, którego klucz publiczny powinienem pobrać osobno z serwera kluczy (aby nie ufać samej stronie)?

Gdyby ktoś mógł skompromitować witrynę, aby przesłał fałszywy plik CA.pem, równie dobrze mógłby przesłać fałszywy podpis CA.pem.asc obok niego. A gdyby ktoś mógł wstawić fałszywy klucz publiczny do witryny, mógłby załadować ten sam klucz do serwerów kluczy.

Innymi słowy, pobieranie czyjegoś klucza oddzielnie od serwera kluczy nie zapewnia żadnego dodatkowego bezpieczeństwa. Serwer kluczy nie powstrzymuje nikogo przed przesyłaniem fałszywych kluczy pod tą samą nazwą i adresem e-mail. Wszystko nadal sprowadza się do weryfikacji odcisku palca klucza lub weryfikacji sieci zaufania. Jeśli nie masz odcisku palca do weryfikacji, możesz go uzyskać, pytając właściciela.

(Aby wiedzieć, która osoba zarządza pulą SKS, powiedziałbym, że środki techniczne nie są wystarczające. Moim podejściem byłoby zbieranie informacji z różnych źródeł, takich jak pytanie innych osób lub sprawdzanie web.archive.org, lub pytanie na IRC GnuPG kanał (jeśli ufasz losom na IRC). Jeśli wszędzie widujesz tę samą osobę „Kristian Fiskerstrand”, prawdopodobnie jest to właściwa).

Jeśli nie masz żadnej formy wcześniejszego kontaktu z właścicielem witryny, jedyną opcją jest zaufanie, że strona internetowa dostarcza ci wiarygodnych informacji. (Na szczęście twoje połączenie z nim jest uwierzytelniane przez HTTPS i WebPKI, więc możesz wykluczyć większość ataków MITM - pozostawiając tylko kompromis serwera).

Być może możesz sprawdzić różne migawki w czasie na stronie internetowej web.archive.org (aby sprawdzić, czy ten sam klucz był na miejscu przez ostatnie kilka miesięcy lub lat).

Jak należy wykorzystać każdą informację?

Odcisk palca certyfikatu i / lub skrót SPKI służą praktycznie temu samemu celowi, co w przypadku, gdy witryny internetowe oferują zwykłe skróty SHA1 obok plików do pobrania. (Rzeczywiście odcisk palca jest po prostu skrótem SHA1 certyfikatu pomniejszonym o kodowanie Base64). Możesz ich użyć, jeśli ufasz witrynie internetowej ... ale wtedy jest to w większości zbędne, ponieważ sam certyfikat CA pochodzi z tej samej witryny. Może jednak zapobiec przypadkowym błędom.

Aby wyświetlić odcisk palca certyfikatu (SHA1):

openssl x509 -in $file -noout -fingerprint -sha1
certtool --fingerprint < $file
cat $file | sed "/^-/d" | base64 -d | sha1sum

Wyświetlanie identyfikatora klucza podmiotu X.509v3 wymaga zwrócenia uwagi na różnicę między samodzielnym obliczaniem skrótu SPKI (jak widać w „Innych informacjach”), a jedynie patrzeniem na ten osadzony w rozszerzeniach X.509 (jak widać w „Rozszerzeniach”):

certtool -i < $file | grep -C3 "Public Key ID"

CRL (lista odwołania certyfikatów) jest używana przez dirmngr GnuPG w celu zapewnienia, że ​​zaatakowane certyfikaty serwera kluczy nie będą mogły być ponownie użyte, dopóki nie wygasną. Lista CRL jest podpisana przez urząd certyfikacji i myślę, że dirmngr automatycznie pobiera i odświeża ją, więc nie musisz.

Podpis składa właściciel witryny i można go użyć do weryfikacji pliku CA.pem, jeśli masz już inne sposoby weryfikacji klucza PGP właściciela. Samo pobranie go z tej samej strony nie dodaje wiele.

Aby zweryfikować podpis:

gpg --verify sks-keyservers.netCA.pem.asc

Przede wszystkim dziękuję za tę pouczającą odpowiedź. Rozumiem, że większość tego, o co pytam, jest niepotrzebna, ale nadal chcę wiedzieć o własnej edukacji. Mam tylko jedno pytanie uzupełniające: jak dokładnie mam sprawdzić pobrany certyfikat na podstawie odcisku palca i kodu SKI podanego na stronie?
CBlew

Główny odcisk palca: [skrót 32 znaków] gpg2 - zweryfikuj plik $ file.asc $, a także upewnij się, że główny odcisk palca jest dokładnie DOKŁADNIE zgodny z tym, co twierdzi strona
linuxdev2013
Korzystając z naszej strony potwierdzasz, że przeczytałeś(-aś) i rozumiesz nasze zasady używania plików cookie i zasady ochrony prywatności.
Licensed under cc by-sa 3.0 with attribution required.