3.4. Platnost klíče, důvěryhodnost¶

Zajištění bezpečné distribuce klíčů je jedna z největších výzev pro kryptology. Asymetrická kryptografie část problémů vyřešila, ale mnohé zůstaly. Ukážeme si to na poslání zašifrované zprávy.

3.4.1. Útok MitM na distribuci veřejného klíče¶

Obr. 3.4 Alice požádá o klíč a poté s ním zašifruje zprávu.¶

Scénář odeslání zašifrované zprávy je jednoduchý. Alice chce poslat Bobovi zašifrovanou zprávu. Proto požádá Boba o poslání jeho veřejného klíče. Bob klíč pošle, Alice pomocí něho zašifruje zprávu a pošle ji Bobovi. Protože pouze Bob má privátní klíč, tak pouze on může zprávu dešifrovat.

Obr. 3.5 Útočník může odchytit počáteční dotaz, vrátit podvržený klíč a následně přečíst zašifrovanou zprávu.¶

Pro útočníka je nejjednodušší zaútočit na začátku komunikace mezi Alicí a Bobem. Mallory odchytí požadavek Alice, kterým žádá Boba o zaslání jeho veřejného klíče. Poté Mallory vygeneruje novou dvojici klíčů pro adresu bob@example.cz. Falešný veřejný klíč pošle Alici, ta si myslí, že klíč patří Bobovi, a proto pomocí něho zašifruje zprávu. Mallory zašifrovanou zprávu odchytí, a protože má odpovídající privátní klíč, tak může zprávu dešifrovat.

Poznámka

Jak Alice bezpečně ověří, že získaný veřejný klíč patří Bobovi, že ho nikdo nepodvrhl?

3.4.2. Platnost klíče (key validity)¶

Ověření identity majitele klíče je v případě OpenPGP poměrně komplikovaná záležitost. Nikdo není omezen, jaké jméno či e-mailovou adresu si do vytvářeného klíče zadá, a kdokoliv se tak může vydávat třeba za prezidenta USA. Z toho důvodu OpenPGP implicitně při použití cizího veřejného klíče upozorňuje na nejistotu přiřazení klíče ke konkrétní identitě a vyžaduje potvrzení akce od uživatele, viz následující výpis.

Výpis 3.19 GPG upozorňuje při použití veřejného klíče s neznámou platností (zde při šifrování).¶

It is NOT certain that the key belongs to the person named
in the user ID.  If you *really* know what you are doing,
you may answer the next question with yes.

Use this key anyway? (y/N)

Veřejný klíč je pro Vás platný (valid), pokud Vy věříte, že patří v něm uvedené identitě a současně pokud není expirovaný či revokovaný (odvolaný). Platnost není univerzální – pro někoho může být klíč platný a pro někoho jiného ne.

Expirace se ověří jednoduše – u klíče je datum od kdy platí a může být datum, do kdy platí 9. Informace o odvolání (revokaci) klíče je obvykle publikována na klíčovém serveru – musíte svoji klíčenku pravidelně aktualizovat vůči němu, abyste získali informaci o odvolání klíče. Jak revokovat svůj klíč je popsáno v kapitole TODO.

Správnost identifikačních údajů (jméno a příjmení, přiřazené e-mailové adresy a případně vložené fotografie) a přiřazení klíče k této identitě můžete ověřit sami či to můžete delegovat na někoho jiného – síť důvěry si popíšeme v kapitole TODO.

3.4.3. Osobní ověření identifikačních údajů klíče¶

Jednotlivé kroky kontroly si ukážeme na případu, kdy si Alice ověřuje veřejný klíč Boba:

Bob si vytiskne identifikační údaje a otisk klíče (fingerprint) na štítek 10:
Alice si domluví osobní schůzku s Bobem. Na ní převezme vytištěný štítek a nechá si od něho potvrdit, že to jsou jeho údaje.
Ještě na schůzce si Alice nechá předložit úřední doklad (např. občanský průkaz) a zkontroluje, zda Bob vzhledem odpovídá fotce v dokladu, ověří jméno a příjmení.
Alice dorazí domů, z klíčového serveru si stáhne klíč dle otisku uvedeného na štítku. Porovná údaje uvedené u klíče (jméno, e-mailová adresa, datum vytvoření) s údaji na štítku.
Pokud údaje odpovídají, tak svým klíčem podepíše e-mailovou adresu uvedenou u klíče. Podepsaný klíč vyexportuje, zašifruje klíčem Boba a pošle na uvedenou e-mailovou adresu. Pokud u klíče je více e-mailových adres, tak postup opakuje pro každou z nich.
Bob si vyzvedne zašifrovaný podepsaný klíč ze své poštovní schránky – tím se ověří, je schopen číst dopisy pro uvedenou e-mailovou adresu. Poté dešifruje soubor s klíčem – tím se ověří, že k veřejnému klíči má odpovídající privátní klíč. Nakonec podepsaný klíč nahraje na klíčový server.
Alice si stáhne z klíčového serveru aktualizovaný klíč Boba. Pokud je u klíče její podpis, tak se ověřili všechny údaje a klíč je pro Alici platný. Nyní ho může použít pro zašifrování zprávy, kterou chce poslat Bobovi.

Nemusí se používat klíčový server, Bob může klíč ukládat i na jiný sdílený prostor (např. LDAP server) či ho posílat elektronickou poštou.

Uvedený postup se používá při ověřování klíčů neznámých či málo známých osob např. na tzv. setkáních na podepisování klíčů (key signing party) 11.

Pokud podepisující ověřil některé údaje již v minulosti, tak se průběh zjednoduší. Při podepisování klíče dlouholetého kolegy v kanceláři nemusíte kontrolovat úřední doklad či ověřovat jeho pracovní e-mailovou adresu přeposláním klíče do jeho poštovní schránky. Pomůže, pokud máte důvěryhodnou e-mailovou komunikaci, kterou dotyčný podepisoval svým klíčem.

Někdy je osobní setkání komplikované či nemožné. Pokud ověřovanou osobu aspoň trochu znáte, tak můžete klíč ověřit s využitím dalšího kanálu. Bob nejdříve pošle podepsaný e-mail Alici, poté Alice např. zavolá Bobovi a nechá si od něho nadiktovat otisk jeho klíče 12 či požádá Boba o zaslání otisku jeho klíče pomocí SMS zprávy.

Ověření na dálku je méně bezpečné než osobní schůzka. Pokud vzdálenou osobu znáte málo či jste ji nikdy neviděli, tak je nejvhodnější delegovat ověření na někoho, komu důvěřujete, že kontrolu provede pečlivě.

3.4.4. Podepsání klíče¶

Ověření identifikačních údajů vyjádříte digitálním podepsáním příslušného klíče za použití přepínače --sign-key, popř. pomocí povelu sign při editaci podepisovaného klíče:

gpg --sign-key id_klíče

Výpis 3.20 Podepsání klíče uživatele gall@bis.vse.cz.¶

gpg --sign-key gall@bis.vse.cz

pub rsa4096/92001940314FDED5
    created: 2015-10-23 expires: 2018-04-01 usage: SC
    trust: unknown validity: unknown
sub rsa2048/416B647304AFC009
    created: 2016-03-12 expired: 2016-05-11 usage: E
sub rsa2048/06D962E87CE05B18
    created: 2016-10-08 expires: 2018-04-01 usage: E
sub rsa4096/25AA068C768822F3
    created: 2015-10-23 expired: 2015-11-06 usage: E
[ unknown] (1). Dr. Gall (R.U.R.) <gall@bis.vse.cz>

This key is due to expire on 2018-04-01.
Are you sure that you want to sign this key with your
key "Luboš Pavlíček <lubos.pavlicek@bis.vse.cz>" (531F3C9784EDED03)
Really sign? (y/N) y
... dotaz na heslo k privátnímu klíči ...

Nejdříve se z klíčenky zobrazí informace o podepisovaném klíči. Uživatel gall@bis.vse.cz má hlavní klíč pro podepisování klíčů a zpráv (usage: SC) a tři podklíče pro šifrování (usage: E). Z klíčů pro šifrování již dva expirovali, třetímu vyprší platnost 1. dubna 2018. Hlavní klíč má neznámou platnost (validity: unknown). Také před e-mailovou adresou je uvedena neznámá (unknown) platnost této identity.

Podepisujete svým privátním klíčem pro podepisování klíčů (usage: C) – musíte zadat heslo, pokud aktuálně není v paměti programu gpg-agent.

Podepisujete klíč pro podepisování klíčů (usage: C) a identifikaci uživatele (jméno, příjmení a e‑mailovou adresu). Podpis platí i pro podklíče a to včetně všech budoucích. Vlastník může též prodloužit dobu platnosti klíče a Váš podpis bude stále platný. Pokud si ale vlastník klíče přidá další e-mailovou adresu, tak tato nová adresa nebude Vámi podepsaná.

Po podpisu byste měli podepsaný klíč exportovat

gpg --export --armor --output gall_podepsany_klic gall@bis.vse.cz

a zašifrovat pro vlastníka klíče:

gpg --encrypt --recipient gall@bis.vse.cz --armor gall_podepsany_klic

Vznikne soubor gall_podepsany_klic.asc a ten pošlete na e-mailovou adresu vlastníka. Příjemce soubor dešifruje:

gpg gall_podepsany_klic.asc

a nahraje do své klíčenky:

gpg --import gall_podepsany_klic

Svůj klíč včetně informace o novém podpisu odešle na klíčový server (musí se uvést keyid, nestačí e-mailová adresa):

gpg --send-keys --keyserver bis.vse.cz 92001940314FDED5

Občas se podepisující a podepisovaný domluví, že již podepisující odešle podpis na klíčový server. Z něho si informaci o podpisu může stáhnout vlastník klíče i všichni ostatní.

Informace o podpisech klíčů lze vypsat pomocí přepínače --list-sigs:

gpg --list-sigs [id_klíče]

Výpis 3.21 Vypsání informací o podpisech klíče gall@bis.vse.cz po jeho podepsání.¶

gpg --list-sigs gall@bis.vse.cz

pub  rsa4096 2015-10-23 [SC] [expires: 2018-04-01]
     B697109046440776812A804A92001940314FDED5
uid      [ full ] Dr. Gall (R.U.R.) <gall@bis.vse.cz>
sig      DE6A7B75CFB69AAE 2015-10-23 [User ID not found]
sig      CA22AE326B9AD9A0 2016-11-11 [User ID not found]
sig      531F3C9784EDED03 2017-01-14 Luboš Pavlíček <lubos.pavlicek@bis.vse.cz>
sig 3    92001940314FDED5 2016-03-12 Dr. Gall (R.U.R.) <gall@bis.vse.cz>
sig 3    92001940314FDED5 2016-10-08 Dr. Gall (R.U.R.) <gall@bis.vse.cz>
sig 3    92001940314FDED5 2015-10-23 Dr. Gall (R.U.R.) <gall@bis.vse.cz>
sub rsa2048 2016-10-08 [E] [expires: 2018-04-01]
sig      92001940314FDED5 2016-10-08 Dr. Gall (R.U.R.) <gall@bis.vse.cz>

Podepsaný klíč je pro mne již plně (full) platný – přesněji je platná e‑mailová adresa gall@bis.vse.cz (řetězec „uid“ na začátku řádku) u klíče s otiskem B697109046440776812A804A92001940314FDED5 (řetězec „pub“ na začátku řádky).

Klíč podepsaly již dvě osoby (keyid DE6A7B75CFB69AAE a CA22AE326B9AD9A0), jejichž klíče se nenašli v klíčence. Můj podpis klíče je vidět na dalším řádku – podepsaní pomocí klíče s keyid 531F3C9784EDED03. Na dalších třech řádcích (viz „sig 3“ na začátku řádku) je vidět, že uživatel gall@bis.vse.cz podepsal tři své podklíče. Součástí výpisu je i informace o platných podklíčích (řetězec „sub“ na začátku řádky) – konkrétně je platný jeden podklíč pro šifrování, který podepsal vlastník hlavního klíče, tj. gall@bis.vse.cz.

OpenPGP podporuje též lokální podpis při použití přepínače --lsign-key (popř. pomocí povelu lsign při editaci klíče). Lokální podpis zůstává ve Vaší klíčence, nikam se neexportuje a neposílá. Klíč bude platný pouze pro Vás. Používá se v případě jenom částečného ověření identity či v klíčenkách pomocných procesů.

gpg --lsign-key id_klíče

3.4.5. Útok na podpisy na veřejných keyserverech¶

V červnu 2019 neznámá osoba zaútočila na podpisy klíčů na veřejných keyserverech keys.gnupg.net - k některým zveřejněným klíčům doplnili statisíce podpisů. A s takto velkým počtem podpisů u jednoho klíče si aplikace nedokážou v rozumném čase poradit. Z keyserverů používajících software SKS nelze uvedené klíče a podpisy odstranit, neboť jejich návrh používá princip append-only databáze. Lze přidávat, nelze odebírat.

Přijatá řešení:

v aplikaci gpg se změnil default pro stahování klíčů - nestahují se a neaktulizují podpisy,
doporučuje se přejít na keyserver keys.openpgp.org, na kterém běží odlišný software s jinými principy,

3.4.6. Kvalita ověření identity¶

OpenPGP umožňuje při podepisování zadat i kvalitu ověření. Existují čtyři úrovně:

– nezadáno/nepovím, defaultní úroveň,
– nijak jsem nekontroloval,
– částečně jsem ověřil,
– pečlivě jsem ověřil.

Úroveň ověření větší než nula vypisuje např. přepínač --list-sigs. Výpis 3.21 ukazuje kvalitu ověření 3 u podpisu vlastních podklíčů (trojka vedle řetězce sig).

V unixu se program gpg obvykle na kvalitu ověření neptá a automaticky doplní nulu. Kvalita ověření se exportuje s klíčem, odesílá se na klíčový server. Při kvalitě ověření 1 se klíč ignoruje při výpočtu platnosti dle důvěry.

3.4.7. Důvěryhodnost (trust) osoby¶

Důvěra v klíč „trust“ definuje, jakým způsobem věříte danému člověku v ověřování jiných lidí. Tedy jak věříte jeho podpisům. Existují možnosti:

nevím, neznámá důvěra (trust unknown),
nedůvěřuji (never trust),
částečně důvěřuji (marginal trust),
plně důvěřuji (full trust),
nekonečně (ultimate) – používá se pro vlastní veřejný klíč, tj. když k veřejnému klíči máte i privátní klíč. Pokud důvěřujete nekonečně cizímu klíči, tak to znamená, že věříte všem podpisům klíčů dotyčného i v případě, že vlastní klíč dotyčného pro Vás není platný (např. expiroval). Důrazně se nedoporučuje nastavovat nekonečnou důvěru v cizí klíče.

Nastavená důvěra se zobrazuje např. při podepisování klíče – má důvěra (trust) v uživatele gall@bis.vse.cz při ověřování klíčů je neznámá (unknown), viz Výpis 3.20 z předchozí kapitoly.

Důvěru lze nastavit při editaci klíče (přepínač --edit-key) pomocí povelu trust, viz následující výpis.

Výpis 3.22 Nastavení důvěry pro uživatele gall@bis.vse.cz.¶

gpg --edit-key gall@bis.vse.cz
... část výpisu vynechána ...
gpg> trust
pub  rsa4096/92001940314FDED5
     created: 2015-10-23  expires: 2018-04-01  usage: SC
     trust: unknown       validity: full
sub  rsa2048/06D962E87CE05B18
     created: 2016-10-08  expires: 2018-04-01  usage: E
 [  full  ] (1). Dr. Gall (R.U.R.) <gall@bis.vse.cz>

Please decide how far you trust this user to correctly verify other users' keys
 (by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu

Your decision? 4

pub  rsa4096/92001940314FDED5
     created: 2015-10-23  expires: 2018-04-01  usage: SC
     trust: full          validity: full
sub  rsa2048/06D962E87CE05B18
     created: 2016-10-08  expires: 2018-04-01  usage: E
 [  full  ] (1). Dr. Gall (R.U.R.) <gall@bis.vse.cz>

gpg> save

Důvěra je individuální – informace o důvěře se neexportují s klíčem, neposílají se na klíčový server. Informace o důvěře se ukládají do samostatného souboru trustdb.gpg, při přenášení klíčenky na jiný počítač musíte samostatně přenést i údaje o důvěře, které exportujete pomocí:

gpg2 --export-ownertrust > otrust.txt

a na druhém počítači importujete pomocí:

cd ~/.gnupg
rm trustdb.gpg
gpg2 --import-ownertrust < otrust.txt

3.4.8. Vyhodnocení platnosti klíče, pavučina důvěry (Web of trust)¶

Při vyhodnocování platnosti klíčů pro Vás se postupuje následovně:

Platné jsou Vaše klíče, tj. veřejné klíče, ke kterým máte privátní klíč.
Platné jsou klíče, které jste sami podepsali.
Platné jsou klíče, které podepsal někdo, komu plně (full) důvěřujete a jehož klíč je pro Vás platný.
Platné jsou klíče, které podepsaly aspoň tři osoby, kterým částečně (marginal) důvěřujete a jejichž klíče jsou pro Vás platné.

Důvěra se nastavuje klíčům, které jsou pro Vás platné – u neplatných klíčů nemá význam.

Následující obrázek ukazuje podpisy klíčů a vztahy důvěry mezi 11 uživateli – používá se pojem síť důvěry (Web of Trust). Které klíče jsou platné pro uživatele A?

Obr. 3.6 Síť důvěry – podpisy klíčů a vztahy důvěry mezi 11 uživateli.¶

Řešení:

Platný je vlastní klíč A.
Platné jsou klíče B, C, D a E, neboť je uživatel A sám podepsal.
Platné jsou klíče F a G, neboť jsou podepsány uživatelem B, kterému A plně důvěřuje.
Platný je klíč H, neboť je podepsán třemi uživateli C, D a E, kterým A částečně důvěřuje.
Klíč I není platný, neboť má pouze dva podpisy od osob, kterým A důvěřuje jen částečně.
Klíč J je platný, neboť je podepsán uživatelem F, kterému plně důvěřuje uživatel A.
Klíč K je neplatný, neboť uživatel H má pouze částečnou důvěru a uživatel I není platný.

Souhrnná informace o síti důvěry se vypíše po přepínači --check-trustdb. Obrázek 1‑30 ukazuje platnost klíčů na jednotlivých úrovních pro uživatele s minimálně 44 klíči v klíčence.

Výpis 3.23 Výpis souhrnných informací o síti důvěry po zadání přepínače --check-trustdb.¶

gpg --check-trustdb
gpg: 3 marginal(s) needed, 1 complete(s) needed, PGP trust model
gpg: depth: 0  valid:   1  signed:   5  trust:  0-, 0q, 0n, 0m, 0f, 1u
gpg: depth: 1  valid:   5  signed:  38  trust:  0-, 0q, 0n, 4m, 1f, 0u
gpg: depth: 2  valid:  37  signed:   0  trust: 37-, 0q, 0n, 0m, 0f, 0u

Na úrovni 0 má platný jeden klíč, kterému důvěřuje na nekonečně (ultimate). Je to vlastní klíč uživatele. Uživatel podepsal 5 dalších klíčů.

Na úrovní 1 má uživatel platných dalších 5 klíčů (ty které podepsal), čtyřem důvěřuje částečně (marginal) a jednomu plně (full). Pomocí těchto 5 klíčů bylo podepsáno 38 jiných klíčů.

Na úrovni 2 je platných dalších 37 klíčů (z 38 podepsaných), u všech je důvěryhodnost neznámá.

3.4.9. Zneplatnění (revokování) klíče, revokování podpisu¶

Při kompromitaci vlastního privátního klíče je důležité nejen si vytvořit nový, ale dát i ostatním vědět, že Váš předchozí klíč již není platný a důvěryhodný.

Klíč revokujete pomocí povelu revkey při editaci klíče, klíč je následně považován za neplatný. Veřejný klíč je nadále distribuován s příznakem zneplatnění. Revokovat může vlastník privátního klíče.

Revokovat lze i pomocí tzv. revokačního certifikátu – Vašim privátním klíčem podepsaný speciální soubor, který se obvykle vytváří při generování klíče (viz výpis TODO) či pomocí přepínače --gen-revoke. Certifikát použijete k zneplatnění klíče v situaci, kdy ztratíte svůj soukromý klíč.

Výpis 3.24 Revokování testovacího klíče včetně odeslání informace na klíčový server.¶

gpg --edit-key C055D2005A788CF26603E1F03421AA984FAA8F8B
Secret key is available.

sec  ed25519/3421AA984FAA8F8B
     created: 2016-12-10  expires: never       usage: SC
     trust: ultimate      validity: ultimate
ssb  cv25519/CC6E03AF7C66F34B
     created: 2016-12-10  expires: never       usage: E
[ultimate] (1). test ecc <testecc@bis.vse.cz>

gpg> revkey
Do you really want to revoke the entire 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
Your decision? 3
Enter an optional description; end it with an empty line:
> test ukončen
>
Reason for revocation: Key is no longer used
test ukončen
Is this okay? (y/N) y

The following key was revoked on 2017-01-15 by ? key 3421AA984FAA8F8B test ecc <testecc@bis.vse.cz>
sec  ed25519/3421AA984FAA8F8B
     created: 2016-12-10  revoked: 2017-01-15  usage: SC
     trust: ultimate      validity: revoked
The following key was revoked on 2017-01-15 by ? key 3421AA984FAA8F8B test ecc <testecc@bis.vse.cz>
ssb  cv25519/CC6E03AF7C66F34B
     created: 2016-12-10  revoked: 2017-01-15  usage: E
[ revoked] (1). test ecc <testecc@bis.vse.cz>
gpg> save
gpg --send-keys --keyserver bis.vse.cz 3421AA984FAA8F8B

Uživatel může revokovat i svůj podpis pod cizím klíčem. Při editaci podepsaného klíče zadáte povel revsig. Nezapomeňte poté klíč s revokovaným podpisem odeslat na keyserver, aby se tato informace rozšířila.

9: Připomínám, že OpenPGP klíč se skládá obvykle ze dvou dvojic klíčů – jedna pro podepisování a druhá pro šifrování. Datum expirace může být uvedeno jen u veřejného klíče pro šifrování. Expirace i revokace se posuzuje u toho veřejného klíče, který chcete použít.
10: PDF soubor obsahující následující štítky jsem vygeneroval na http://openpgp.quelltextlich.at/slip.html. Aplikace hledá klíče na veřejném klíčovém serveru.
11: Další popis viz https://carouth.com/blog/2014/05/25/signing-pgp-keys/ či https://wiki.apache.org/apachecon/PgpKeySigning
12: Při diktování a poslouchání posloupnosti čtyřiceti hexadecimálních číslic lze snadno udělat chybu. Již v roce 1995 vznikl pro PGP slovník, který převádí dvojici číslic na anglická slova, která se při vyslovování od sebe výrazněji liší – viz https://en.wikipedia.org/wiki/PGP_word_list.