DomainKeys Identified Mail ( DKIM ) este o metodă de autentificare a e-mailului concepută pentru a detecta e-mailurile falsificate . Metoda permite destinatarului să se asigure că scrisoarea a fost trimisă efectiv din domeniul declarat [1] . DKIM facilitează gestionarea adreselor de expeditori false, care sunt adesea folosite în e-mailurile de phishing și spam -ul prin e-mail .
Tehnologia combină mai multe metode existente anti-phishing și anti-spam pentru a îmbunătăți calitatea clasificării și identificării e-mailurilor legitime. În loc de o adresă IP , DKIM adaugă o semnătură digitală asociată cu numele de domeniu al organizației pentru a determina expeditorul unui mesaj . Semnătura este verificată automat pe partea destinatarului, iar apoi „listele albe” și „listele negre” sunt folosite pentru a determina reputația expeditorului.
DomainKeys utilizează nume de domenii pentru a autentifica expeditorii și utilizează sistemul de nume de domeniu ( DNS ) existent pentru a comunica cheile publice de criptare .
Proiectul DomainKeys a fost lansat de Yahoo (prima versiune a specificației DomainKeys a fost publicată pe 20 mai 2004), iar proiectul Identified Internet Mail a fost inițiat de Cisco Systems . Timp de aproximativ un an, o asociație informală de o duzină de organizații, inclusiv Yahoo , Cisco , EarthLink, Microsoft , PGP Corporation , StrongMail Systems, VeriSign și Sendmail Inc, a lucrat pentru a crea o nouă specificație DKIM. În iulie 2005, a fost prezentat IETF pentru a fi luat în considerare ca un nou standard de e-mail pentru combaterea phishing -ului și a spam-ului .
DKIM folosește module externe pentru a căuta chei și a redirecționa e-mailuri. Această diagramă definește setul de bază de componente necesare pentru implementare, care include DNS și SMTP .
După cum se arată în figură, procesul principal de procesare a scrisorilor este împărțit în două părți: crearea unui EDS al unei scrisori și verificarea acesteia.
Semnătura scrisorii Procesul de creare a unei semnături digitale și adăugarea acesteia la scrisoare este realizat de modulul intern de încredere ADMD (Administrative Management Domain), care utilizează cheia privată extrasă din stocare , creată pe baza informațiilor despre scrisoare. Un ADMD poate fi un client de e-mail (MUA - Mail User Agent) sau un server de e-mail (MTA - Mail Transfer Agent). Verificarea EDS-ului unei scrisori Verificarea EDS este efectuată și de modulul ADMD de încredere. Acest proces poate fi efectuat atât pe serverul de e-mail, cât și pe partea clientului. Acest modul se autentifică cu cheia publică și determină dacă este necesară o semnătură. Dacă este confirmată autenticitatea semnăturii digitale, atunci scrisoarea, împreună cu informațiile despre „reputația” autorului, este transferată în filtrul de mesaje, care decide dacă scrisoarea este spam. Dacă nu există semnătură digitală în mesajul pentru domeniul dat sau nu trece autentificarea, atunci mesajul este transmis filtrului de mesaje împreună cu instrucțiuni suplimentare (de exemplu, puncte de penalizare pentru filtrul anti-spam) primite de la filtrul local. sau stocare la distanță.Dacă o scrisoare are mai mult de o semnătură digitală autentică, atunci procedura de aplicare a instrucțiunii bazată pe informații despre domeniile cărora le aparțin aceste semnături este determinată în afara tehnologiei DKIM.
Fiecărui mesaj care circulă în sistemul DKIM i se atribuie o semnătură digitală care confirmă expeditorul și garantează că partea semnată nu a fost schimbată. Procesul de schimb în sine este similar cu lucrul cu PGP . Proprietarul domeniului generează o pereche de chei - publice și private. Cheia privată este folosită pe serverul SMTP pentru a furniza mesajului o semnătură digitală, care este transmisă în antetul DKIM-Signature și conține informații despre domeniul expeditorului. Exemplu de mesaj original:
De la: Joe SixPack <[email protected]> Către: Suzie Q <[email protected]> Subiect: cina este gata? Data: vineri, 11 iulie 2003 21:00:37 -0700 (PDT) ID-ul mesajului: <[email protected]> Bună. Am pierdut jocul. Ți-e foame încă? Joe.După procedura de creare a EDS, mesajul pregătit pentru trimitere ia următoarea formă:
Semnătura DKIM: v=1; a=rsa-sha256; s=brisbane; d=example.com; c=simplu/simplu; q=dns/txt; [email protected]; h=Receivede: Fromo: ToT: Subjectc: Datet: Message-ID; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; Primit: de la client1.football.example.com [192.0.2.1] prin submit server.example.com cu SUBMISSION; Vineri, 11 iulie 2003 21:01:54 -0700 (PDT) De la: Joe SixPack <[email protected]> Către: Suzie Q <[email protected]> Subiect: cina este gata? Data: vineri, 11 iulie 2003 21:00:37 -0700 (PDT) ID-ul mesajului: <[email protected]> Bună. Am pierdut jocul. Ți-e foame încă? Joe.Serverul de e-mail care semnează acest mesaj trebuie să aibă acces la cheia privată asociată cu valoarea „brisbane” a etichetei „s=". Cheia publică este adăugată în câmpul txt al înregistrării DNS .
În timpul procesului de verificare a semnăturii digitale, domeniul „example.com” stocat în eticheta „d=" și valoarea etichetei de comutare „s=" - „brisbane” sunt extrase din antetul „DKIM-Signature” pentru a genera un cerere de verificare pentru „brisbane._domainkey. example.com” Verificarea începe cu câmpul „Primit”, apoi „De la”, etc. în ordinea specificată în eticheta „h=". Rezultatul solicitării și verificării din acest exemplu este scris în antetul „X-Authentication-Results”. După o verificare cu succes a EDS, mesajul arată astfel:
X-Authentication-Results: shopping.example.net [email protected]; dkim=pass Primit: de la mout23.football.example.com (192.168.1.1) prin shopping.example.net cu SMTP; Vineri, 11 iulie 2003 21:01:59 -0700 (PDT) Semnătura DKIM: v=1; a=rsa-sha256; s=brisbane; d=example.com; c=simplu/simplu; q=dns/txt; [email protected]; h=Primit : De la : La : Subiect : Data : ID-ul mesajului; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; Primit: de la client1.football.example.com [192.0.2.1] de submitserver.example.com cu SUBMISSION; Vineri, 11 iulie 2003 21:01:54 -0700 (PDT) De la: Joe SixPack <[email protected]> Către: Suzie Q <[email protected]> Subiect: cina este gata? Data: vineri, 11 iulie 2003 21:00:37 -0700 (PDT) ID-ul mesajului: <[email protected]> Bună. Am pierdut jocul. Ți-e foame încă? Joe.DKIM folosește instrumente criptografice bine stabilite. În acest moment, autorii DKIM oferă doi algoritmi pentru semnătura digitală: RSA-SHA256 și RSA-SHA1 , dar în viitor tehnologia poate fi extinsă pentru a suporta alți algoritmi. Lungimea cheii este limitată la 4096 de biți, deoarece o cheie mai mare nu se va încadra în dimensiunea maximă a pachetului DNS UDP de 512 octeți. Lungimea cheii recomandată este între 1024 și 2048 biți. Prea multă lungime creează o sarcină de calcul pe server pentru a procesa fiecare mesaj, iar prea puțin (384 sau 512 biți) este piratat prin forță brută pentru momentul actual, folosind un computer personal sau folosind un serviciu de cloud computing.
Această tehnologie este compatibilă cu structura de rețea existentă și nu necesită o schimbare fundamentală a serviciilor (cu excepția instalării SMTP) și modificări ale protocoalelor , prin urmare, poate fi introdusă treptat. Un mesaj semnat de DKIM este complet „autonom”, permițând DKIM să funcționeze independent de PKI sau de orice serviciu, deoarece cheia este preluată direct din înregistrarea DNS și nu trebuie să fie confirmată de nimic. O organizație care utilizează DKIM este pe deplin responsabilă pentru funcționarea serverului său, iar prezența unei semnături digitale înseamnă doar că cineva este responsabil pentru un anumit mesaj.
În descriere, dezvoltatorii acestei tehnologii subliniază că prezența unui EDS într-un mesaj nu obligă partea care o primește la nimic, nu oferă protecție după ce semnătura a fost verificată și nu poate afecta în niciun fel dacă mesajul este retransmis. dacă expeditorul și destinatarul s-au schimbat. Prin urmare, RFC recomandă ca mesajele de la serverele obișnuite care nu acceptă DKIM să fie tratate într-un mod standard.
Un spammer își poate crea propriul server SMTP și server DNS activat cu DKIM , ceea ce va fi legal din punctul de vedere al DKIM, dar în acest caz, domeniile de pe un astfel de server vor câștiga rapid „puncte de penalizare” și vor fi blocate de un filtrul de spam în viitor.