DomainKeys Identified Mail ( DKIM ) on sähköpostin todennusmenetelmä , joka on suunniteltu tunnistamaan väärennetyt sähköpostit . Menetelmän avulla vastaanottaja voi varmistaa, että kirje todella lähetettiin ilmoitetusta toimialueesta [1] . DKIM helpottaa väärennettyjen lähettäjän osoitteiden käsittelyä, joita käytetään usein tietojenkalasteluviesteissä ja sähköpostiroskapostissa .
Tekniikka yhdistää useita olemassa olevia tietojenkalastelun ja roskapostin torjuntamenetelmiä parantaakseen laillisen sähköpostin luokituksen ja tunnistamisen laatua. IP-osoitteen sijaan DKIM lisää digitaalisen allekirjoituksen , joka liittyy organisaation verkkotunnuksen nimeen viestin lähettäjän määrittämiseksi . Allekirjoitus tarkistetaan automaattisesti vastaanottajan puolelta, ja sitten "valkoisia listoja" ja "mustia listoja" käytetään lähettäjän maineen määrittämiseen.
DomainKeys käyttää toimialueen nimiä lähettäjien todentamiseen ja käyttää olemassa olevaa Domain Name System ( DNS ) -järjestelmää julkisten salausavaimien välittämiseen .
DomainKeys - projektin käynnisti Yahoo (ensimmäinen versio DomainKeys-spesifikaatiosta julkaistiin 20. toukokuuta 2004), ja Identified Internet Mail -projektin aloitti Cisco Systems . Noin vuoden ajan epävirallinen järjestö, johon kuului tusinaa organisaatiota, mukaan lukien Yahoo , Cisco , EarthLink, Microsoft , PGP Corporation , StrongMail Systems, VeriSign ja Sendmail Inc, työskenteli uuden DKIM-määrittelyn luomiseksi. Heinäkuussa 2005 se lähetettiin IETF :lle harkittavaksi uutena sähköpostistandardina tietojenkalastelun ja roskapostin torjuntaan .
DKIM käyttää ulkoisia moduuleja avaimien etsimiseen ja sähköpostien edelleenlähettämiseen. Tämä kaavio määrittelee käyttöönoton edellyttämien komponenttien ydinjoukon, mukaan lukien DNS ja SMTP .
Kuten kuvasta näkyy, kirjeiden käsittelyn pääprosessi on jaettu kahteen osaan: kirjeen EDS :n luomiseen ja sen tarkistamiseen.
Kirjeen allekirjoitus Digitaalisen allekirjoituksen luomisen ja lisäämisen kirjeeseen suorittaa sisäinen luotettu moduuli ADMD (Administrative Management Domain), joka käyttää muistista poimittua yksityistä avainta , joka on luotu kirjeen tietojen perusteella. ADMD voi olla sähköpostiohjelma (MUA - Mail User Agent) tai sähköpostipalvelin (MTA - Mail Transfer Agent). Kirjeen EDS:n tarkistaminen Luotettu ADMD-moduuli suorittaa myös EDS-vahvistuksen. Tämä prosessi voidaan suorittaa sekä sähköpostipalvelimella että asiakaspuolella. Tämä moduuli todentaa julkisella avaimella ja määrittää, tarvitaanko allekirjoitusta ollenkaan. Jos digitaalisen allekirjoituksen aitous varmistetaan, kirje ja tiedot kirjoittajan "maineesta" siirretään viestisuodattimelle, joka päättää, onko kirje roskapostia. Jos viestissä ei ole digitaalista allekirjoitusta annetulle toimialueelle tai se ei läpäise todennusta, viesti välitetään viestisuodattimelle paikalliselta viestiltä saatujen lisäohjeiden (esim. roskapostisuodattimen sakkopisteet) kanssa. tai etätallennustilaa.Jos kirjeessä on useampi kuin yksi autenttinen digitaalinen allekirjoitus, määritetään DKIM-tekniikan ulkopuolelta DKIM-tekniikan ulkopuolella, miten käskyä sovelletaan tietoihin niistä alueista, joihin nämä allekirjoitukset kuuluvat.
Jokaiselle DKIM-järjestelmässä kiertävälle viestille annetaan digitaalinen allekirjoitus, joka vahvistaa lähettäjän ja takaa, että allekirjoitettua osaa ei ole muutettu. Itse vaihtoprosessi on samanlainen kuin työskentely PGP :n kanssa . Verkkotunnuksen omistaja luo avaimet - julkiset ja yksityiset. Yksityistä avainta käytetään SMTP-palvelimella lähettämään viestille digitaalinen allekirjoitus, joka välitetään DKIM-Signature-otsikossa ja sisältää tiedot lähettäjän toimialueesta. Esimerkki alkuperäisestä viestistä:
Lähettäjä: Joe SixPack <[email protected]> Vastaanottaja: Suzie Q <[email protected]> Aihe: Onko illallinen valmis? Päivämäärä: pe, 11. heinäkuuta 2003, 21:00:37 -0700 (PDT) Viestin tunnus: <[email protected]> Hei. Hävisimme pelin. Onko sinulla vielä nälkä? Joe.EDS-luonnin jälkeen lähetettäväksi valmisteltu viesti on seuraavanlainen:
DKIM-allekirjoitus: v=1; a = rsa-sha256; s = brisbane; d=esimerkki.fi; c = yksinkertainen/yksinkertainen; q = dns/txt; [email protected]; h=Vastaanotto: Lähettäjä: Vastaanottaja: Aihe: Päiväys: Viesti-ID; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; Vastaanotettu: osoitteesta client1.football.example.com [192.0.2.1] lähettäjänä palvelin.esimerkki.com ja SUBMISSION; pe, 11. heinäkuuta 2003, 21:01:54 -0700 (PDT) Lähettäjä: Joe SixPack <[email protected]> Vastaanottaja: Suzie Q <[email protected]> Aihe: Onko illallinen valmis? Päivämäärä: pe, 11. heinäkuuta 2003, 21:00:37 -0700 (PDT) Viestin tunnus: <[email protected]> Hei. Hävisimme pelin. Onko sinulla vielä nälkä? Joe.Tämän viestin allekirjoittaneella sähköpostipalvelimella on oltava pääsy yksityiseen avaimeen, joka liittyy "s="-tunnisteen "brisbane"-arvoon. Julkinen avain lisätään DNS-tietueen txt-kenttään .
Digitaalisen allekirjoituksen vahvistusprosessin aikana "d="-tunnisteeseen tallennettu "example.com"-verkkotunnus ja "s="-kytkintagin arvo - "brisbane" poimitaan "DKIM-Signature"-otsikosta, jolloin luodaan vahvistuspyyntö kohteelle "brisbane._domainkey. example.com" Tarkastus alkaa "Vastaanotettu"-kentällä, sitten "From" jne. "h="-tunnisteessa määritetyssä järjestyksessä. Tämän esimerkin pyynnön ja vahvistuksen tulos kirjoitetaan "X-Authentication-Results"-otsikkoon. Onnistuneen EDS-tarkastuksen jälkeen viesti näyttää tältä:
X-Authentication-Results: shopping.example.net [email protected]; dkim = pass Vastaanotettu: osoitteesta mout23.football.example.com (192.168.1.1) ostos.esimerkki.net SMTP:llä; pe, 11. heinäkuuta 2003, 21:01:59 -0700 (PDT) DKIM-allekirjoitus: v=1; a = rsa-sha256; s = brisbane; d=esimerkki.fi; c = yksinkertainen/yksinkertainen; q = dns/txt; [email protected]; h=Vastaanotettu: Lähettäjä: Vastaanottaja: Aihe: Päivämäärä: Viesti-ID; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; Vastaanotettu: osoitteesta client1.football.example.com [192.0.2.1] lähettäjä submitserver.example.com ja SUBMISSION; pe, 11. heinäkuuta 2003, 21:01:54 -0700 (PDT) Lähettäjä: Joe SixPack <[email protected]> Vastaanottaja: Suzie Q <[email protected]> Aihe: Onko illallinen valmis? Päivämäärä: pe, 11. heinäkuuta 2003, 21:00:37 -0700 (PDT) Viestin tunnus: <[email protected]> Hei. Hävisimme pelin. Onko sinulla vielä nälkä? Joe.DKIM käyttää vakiintuneita salaustyökaluja. Tällä hetkellä DKIM:n kirjoittajat tarjoavat digitaaliselle allekirjoitukselle kahta algoritmia: RSA-SHA256 ja RSA-SHA1 , mutta tulevaisuudessa tekniikkaa voidaan laajentaa tukemaan muita algoritmeja. Avaimen pituus on rajoitettu 4096 bittiin, koska suurempi avain ei mahdu DNS UDP -paketin maksimikokoon 512 tavua. Suositeltu avaimen pituus on 1024–2048 bittiä. Liian pitkä pituus kuormittaa palvelinta jokaisen viestin käsittelyssä, ja liian vähän (384 tai 512 bittiä) hakkeroidaan tällä hetkellä raa'alla voimalla henkilökohtaisella tietokoneella tai pilvipalveluilla.
Tämä tekniikka on yhteensopiva olemassa olevan verkkorakenteen kanssa eikä vaadi perustavaa muutosta palveluissa (paitsi SMTP:n määrityksessä) ja protokollissa , joten se voidaan ottaa käyttöön asteittain. DKIM:n allekirjoittama viesti on täysin "itsenäinen", jolloin DKIM voi toimia PKI :stä tai muista palveluista riippumatta, koska avain otetaan suoraan DNS-tietueesta eikä sitä tarvitse vahvistaa millään. DKIM:ää käyttävä organisaatio on täysin vastuussa palvelimensa toiminnasta, ja digitaalisen allekirjoituksen olemassaolo tarkoittaa vain, että joku on vastuussa tietystä viestistä.
Kuvauksessa tämän tekniikan kehittäjät korostavat, että EDS:n läsnäolo viestissä ei sido vastaanottavaa osapuolta mihinkään, ei suojaa allekirjoituksen varmentamisen jälkeen, eikä se voi millään tavalla vaikuttaa siihen, jos viesti lähetetään uudelleen. jos lähettäjä ja vastaanottaja ovat vaihtuneet. Siksi RFC suosittelee, että tavallisilta palvelimilta tulevat viestit, jotka eivät tue DKIM:ää, käsitellään tavallisella tavalla.
Roskapostittaja voi luoda oman DKIM-yhteensopivan SMTP -palvelimen ja DNS-palvelimen , mikä on DKIM:n kannalta laillista, mutta tässä tapauksessa tällaisen palvelimen verkkotunnukset ansaitsevat nopeasti "rangaistuspisteitä" ja ne estetään roskapostisuodatin tulevaisuudessa.