DKIM – dopisy ověřeného původu

DKIM v sobě spojuje dřívější návrhy DomainKeys od Yahoo a Identified Internet Mail pocházející od Cisco Systems. Obě tyto technologie posloužily jako východisko pro pracovní skupinu DKIM při IETF, jejímž výsledkem je především RFC 4871 definující DKIM. Nyní skupina pracuje na doprovodných specifikacích, které přispějí k posuzování dopisů na straně příjemce.

Autoři DKIM usilovali o jeho maximální jednoduchost a co nejmenší dopad na existující poštovní systém. Jedná se vlastně o určitou formu elektronického podpisu, která se v dopise projeví přidáním hlavičky DKIM-Signature. To je jediná změna, jinak dopis zůstává v původní podobě, a je tudíž bez problémů zpracovatelný programy, které DKIM nepodporují.

Jednou ze zajímavých a příjemných vlastností je, že dopis nemusí a zpravidla ani nebude podepisovat přímo odesilatel. Jako typický scénář použití se předpokládá, že dopisy podepíše poštovní server odesílající instituce. Tedy že podepisování bude součástí přepravní infrastruktury pro elektronickou poštu, nikoli úkolem pro koncové programy. Podobně ověření podpisu a jeho využití může (a většinou bude) provádět přijímající poštovní server, nikoli poštovní program koncového uživatele.

Hodnota hlavičky DKIM-Signature nesoucí podpis obsahuje seznam dvojic jméno=hodnota oddělených navzájem středníky. Jména jeho položek a jejich významy shrnuje následující tabulka:

Postup podepisování vypadá následovně:

1. Spočítá se hash těla dopisu (případně jen jeho části, jejíž délku obsahuje l=) a výsledek se zapíše do  bh=.
2. Sestaví se hlavička DKIM-Signature, zatím s prázdným  b=.
3. Spočítá se hash hlaviček uvedených v h=  plus hlavičky DKIM-Signature (která se v h=  neuvádí, ale je zařazena do podpisu).
4. Hash hlaviček se podepíše soukromým klíčem a výsledek se vloží do položky  b=.

Vzhledem k tomu, že podpis zahrnuje i hash těla dopisu, lze důvěřovat pravosti zahrnutých hlaviček i vlastnímu obsahu. Jedním z velkých serverů již dnes podporujících DKIM je Google mail. Jeho podpis může vypadat takto:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=beta;
        h=received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition;
        bh=eurOoRB1CyEpIjF7pbs+NqrPh7tZRZQ0nLW/DGITqo8=;
        b=kECCK46Bj100THumV6j/3YuN0dOuEi/v7AjQGzAb8G1DO0Ip2pwK1c4NnrJC/AruOWvfgyy3MjNXd8FsVvA2CTVwUC+7m784eyHBbYmWBP1xrI7ORe08RufPFS5YzkXgbIg+RNj12X0YPo3US+PLMmy0Epl7EPlwFFZaEPF45G4=

Všimněte si opakovaného výskytu hlavičky received v položce h=. Pokud se hlavička vyskytuje v dopise opakovaně, je třeba ji uvést tolikrát, kolik výskytů je zahrnuto do podpisu. Počítá se od konce, takže v daném dopise jsou podepsány poslední dva exempláře received.

Hlavička obsahuje veškeré informace potřebné k ověření podpisu. Především je v ní uvedeno, kdo dopis podepsal a jak získat příslušný klíč. DKIM totiž připouští, aby procházející dopis podepsal víceméně kdokoli. Podpis zde neznamená garanci, že jeho autorem je skutečně osoba uvedená ve From. Význam DKIM podpisu je „potvrzujeme, že jsme odeslali tento dopis v dané podobě“. Jestliže je jako odesilatel uveden kdosi@gmail.com a podpis pochází od gmail.com, lze předpokládat, že odesilatel je pravý. Pokud stejný dopis podepíše thebesthaxxxor­sintheuniverse­.com, asi se na jeho důvěryhodnost příliš sázet nedá.

DKIM připouští různé metody získání veřejného klíče pro ověření podpisu. Slouží k tomu položka q=. Jedná se však spíše o přípravu na budoucnost, zatím se používá jediná metoda, jíž je uložení klíče do DNS záznamů typu TXT ( q=dns/txt, což je implicitní hodnota a zpravidla se neuvádí).

Klíče jsou uloženy v doméně s pevným názvem _domainkey, která je vnořena v doméně ohlášené položkou d=. Aby stejná doména mohla obsahovat více klíčů, jsou navzájem rozlišeny selektory ( s=). Selektor může obsahovat tečky, které pak představují hranice mezi doménami v dotazu. Dotaz do DNS tedy směřuje na záznam typu TXT pro doménové jméno selektor._doma­inkey.doména. Například k ověření výše uvedeného podpisu potřebujeme TXT záznam pro beta._domainke­y.gmail.com. Vypadá takto:

beta._domainkey.gmail.com.  300  IN  TXT  "t=y\; k=rsa\; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC69TURXN3oNfz+G/m3g5rt4P6nsKmVgU1D6cw2X6BnxKJNlQKm10f8tMx6P6bN7juTR1BeD8ubaGqtzm2rWK4LiMJqhoQcwQziGbK1zp/MkdXZEWMCflLY6oUITrivK7JNOLXtZbdxJG2y/RAHGswKKyVhSP9niRsZF/IBr5p8uQIDAQAB"

Jak je vidět, informace o klíči mají opět podobu seznamu dvojic jméno=hodnota. Tentokrát jsou k mání následující jména:

Kdokoli chce ověřit podpis, vyzvedne si z hlavičky DKIM-Signature potřebné údaje, pomocí DNS získá klíč a provede potřebné výpočty. Jestliže podpis odpovídá a důvěřuje jeho vydavateli, může považovat dopis za důvěryhodný. V opačném případě by s ním měl naložit, jako by žádný podpis neobsahoval.

Podpisů může dopis nést hned několik. Například odesílající instituce jej může podepsat několika různými algoritmy, z nichž některé nabídnou vyšší úroveň zabezpečení, jiné větší míru kompatibility (RFC 4871 požaduje podporu dvou, SHA-1 a SHA-256). Dalším typickým scénářem pro více podpisů je dopis poslaný do mailing listu. Může jej podepsat autorův odesílající poštovní server a následně další podpis přidá program rozesílající kopie členům listu. Do budoucna je myslitelné i to, že dopis budou postupně podepisovat všechny servery, jimiž projde, a příjemce tedy bude mít k dispozici ověřené záznamy o trase, kterou byl doručen.

DKIM pamatuje i na to, že některé prvky poštovní infrastruktury (např. zmíněné mailing listy) do dopisů částečně zasahují a mohou třeba poupravit formátování hlaviček nebo odříznout prázdné řádky na konci a podobně. Proto je dopis před zpracováním kryptografickým algoritmem kanonizován. Položka c= v hlavičce DKIM-Signature určuje způsob kanonizace odděleně pro hlavičky a tělo dopisu. K dispozici jsou dvě volby: Jednoduchá kanonizace (simple) znamená, že hash je počítán z víceméně nezměněného textu a jakákoli změna dopisu způsobí neplatnost podpisu. Naproti tomu volná kanonizace (relaxed) připouští změny formátování, protože před výpočtem vyhází z textu prázdné znaky na koncích řádků, skupiny prázdných znaků nahradí vždy jednou mezerou a podobně. Kanonizace samozřejmě nemění obsah dopisu, probíhá na jeho kopii, pro kterou bude následně proveden kryptografický výpočet.

Specifikace DKIM neřeší, jak s dopisem naložit při úspěšném či neúspěšném ověření podpisu. Její činnost končí prostým konstatováním, kdo dopis odeslal a zda byl podpis úspěšně ověřen. Případný vliv této informace na zpracování dopisu je otázkou lokální politiky, jejíž nastavení je vždy na správci dotyčného systému. V doprovodných dokumentech se pouze doporučuje, aby neověřený podpis nezpůsobil penalizaci dopisu, protože neplatnost podpisu mohl způsobit drobný zásah do těla či hlaviček během přepravy. S dopisem by mělo být naloženo stejně, jako kdyby žádný podpis neobsahoval.

Na DKIM je příjemné, že se dá nasadit i v malém. Jestliže organizaci X důvěřujete a ona své dopisy podepisuje, můžete si ve svém systému nastavit, že dopisy ověřeně pocházející od X přijímáte bez dalšího zkoumání. Nepotřebujete k tomu spolupráci nikoho dalšího ani žádnou speciální infrastrukturu. Stačí vytváření podpisů na jedné straně (a klíč v jejich DNS) a konfigurace poštovního programu na straně druhé.

Pokud se postupem času podepisování dopisů rozšíří, bude možné přistoupit k obecnějším mechanismům zpracování. V současném stavu poskytuje především kvalitní východisko pro whitelisting – podepsaný dopis z důvěryhodného zdroje bude vpuštěn. Aby se možnosti jeho využití prohloubily, pracuje skupina DKIM na specifikaci pro zveřejňování podpisových politik. Cílem je, aby organizace (opět pomocí DNS) mohla vyhlásit například „všechny své dopisy podepisujeme“. Jestliže pak dorazí nepodepsaný dopis, údajně z domény této organizace, lze jej oprávněně považovat za krajně podezřelý. Specifikace DKIM Sender Signing Practices je však zatím stále v podobě návrhu, najdete jej na stránkách skupiny.

Příklad Google Mail naznačuje, že DKIM není jen teoretickým cvičením, ale že začíná pronikat do praxe. Podepisovat dopisy můžete naučit Sendmail i Postfix pomocí dkim-milter, případně použít DKIM Proxy. Na straně příjmu jej podporuje například Spamassassin či AMaViS. Seznam implementací tím rozhodně nekončí, najdete jej třeba na stránkách dkim.org. Tak šťastné podepisování.