DomainKeys Identified Mail ( DKIM ) är en e- postautentiseringsmetod utformad för att upptäcka förfalskade e-postmeddelanden . Metoden gör det möjligt för mottagaren att försäkra sig om att brevet verkligen skickades från den deklarerade domänen [1] . DKIM gör det lättare att hantera falska avsändaradresser, som ofta används i nätfiske -e- post och e -postspam .
Tekniken kombinerar flera befintliga anti-phishing och anti-spam metoder för att förbättra kvaliteten på klassificering och identifiering av legitim e-post. Istället för en IP-adress lägger DKIM till en digital signatur kopplad till organisationens domännamn för att fastställa avsändaren av ett meddelande . Signaturen verifieras automatiskt på mottagarens sida och sedan används "vitlistor" och "svarta listor" för att fastställa avsändarens rykte.
DomainKeys använder domännamn för att autentisera avsändare och använder det befintliga Domain Name System ( DNS ) för att kommunicera offentliga krypteringsnycklar .
DomainKeys - projektet lanserades av Yahoo (den första versionen av DomainKeys-specifikationen publicerades den 20 maj 2004), och Identified Internet Mail-projektet initierades av Cisco Systems . I ungefär ett år arbetade en informell sammanslutning av ett dussin organisationer, inklusive Yahoo , Cisco , EarthLink, Microsoft , PGP Corporation , StrongMail Systems, VeriSign och Sendmail Inc, för att skapa en ny DKIM-specifikation. I juli 2005 överlämnades det till IETF för övervägande som en ny e-poststandard för att bekämpa nätfiske och skräppost .
DKIM använder externa moduler för att söka upp nycklar och vidarebefordra e-post. Det här diagrammet definierar kärnuppsättningen av komponenter som krävs för distribution, vilket inkluderar DNS och SMTP .
Som visas i figuren är huvudprocessen för att behandla brev uppdelad i två delar: skapandet av en EDS för ett brev och dess verifiering.
Brev signatur Processen att skapa en digital signatur och lägga till den i brevet utförs av den interna betrodda modulen ADMD (Administrative Management Domain), som använder den privata nyckeln som extraheras från lagringen , skapad på basis av information om brevet. En ADMD kan vara en e-postklient (MUA - Mail User Agent) eller en e-postserver (MTA - Mail Transfer Agent). Kontrollerar EDS för ett brev EDS-verifiering utförs också av den betrodda ADMD-modulen. Denna process kan utföras både på e-postservern och på klientsidan. Den här modulen autentiserar med den publika nyckeln och avgör om en signatur överhuvudtaget krävs. Om äktheten av den digitala signaturen bekräftas, överförs brevet, tillsammans med information om författarens "rykte", till meddelandefiltret, som avgör om brevet är skräppost. Om det inte finns någon digital signatur i meddelandet för den givna domänen eller om det inte klarar autentisering, skickas meddelandet till meddelandefiltret tillsammans med ytterligare instruktioner (till exempel straffpunkter för anti-spam-filtret) som tas emot från den lokala eller fjärrlagring.Om ett brev har mer än en autentisk digital signatur, så bestäms proceduren för att tillämpa instruktionen baserat på information om de domäner som dessa signaturer tillhör utanför DKIM-tekniken.
Varje meddelande som cirkulerar i DKIM-systemet tilldelas en digital signatur som bekräftar avsändaren och garanterar att den signerade delen inte har ändrats. Själva utbytesprocessen liknar att arbeta med PGP . Domänägaren genererar ett par nycklar - offentliga och privata. Den privata nyckeln används på SMTP-servern för att förse meddelandet med en digital signatur, som sänds i DKIM-Signatur-huvudet och innehåller information om avsändarens domän. Exempel på originalmeddelande:
Från: Joe SixPack <[email protected]> Till: Suzie Q <[email protected]> Ämne: Är middagen klar? Datum: fre, 11 juli 2003 21:00:37 -0700 (PDT) Meddelande-ID: <[email protected]> Hej. Vi förlorade spelet. Är du hungrig än? Joe.Efter EDS-skapandet har meddelandet som förbereds för sändning följande form:
DKIM-signatur: v=1; a=rsa-sha256; s=brisbane; d=exempel.com; c=enkel/enkel; q=dns/txt; [email protected]; h=Mottaget: Fromo: ToT: Ämnec: Datum: Meddelande-ID; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; Mottaget: från client1.football.example.com [192.0.2.1] genom att skicka in server.example.com med SUBMISSION; Fre, 11 juli 2003 21:01:54 -0700 (PDT) Från: Joe SixPack <[email protected]> Till: Suzie Q <[email protected]> Ämne: Är middagen klar? Datum: fre, 11 juli 2003 21:00:37 -0700 (PDT) Meddelande-ID: <[email protected]> Hej. Vi förlorade spelet. Är du hungrig än? Joe.E-postservern som signerar detta meddelande måste ha tillgång till den privata nyckeln som är kopplad till "brisbane"-värdet för taggen "s=". Den publika nyckeln läggs till i txt - fältet i DNS - posten .
Under den digitala signaturverifieringsprocessen extraheras "example.com"-domänen lagrad i "d="-taggen och värdet på "s="-växeltaggen - "brisbane" från "DKIM-Signature"-huvudet för att generera en verifieringsbegäran för "brisbane._domainkey. example.com" Kontrollen börjar med fältet "Received" och sedan "From" etc. i den ordning som anges i "h="-taggen. Resultatet av begäran och verifieringen i detta exempel skrivs till rubriken "X-Authentication-Results". Efter en lyckad verifiering av EDS ser meddelandet ut så här:
X-Authentication-Results: shopping.example.net [email protected]; dkim=pass Mottaget: från Mout23.football.example.com (192.168.1.1) genom shopping.example.net med SMTP; Fre, 11 juli 2003 21:01:59 -0700 (PDT) DKIM-signatur: v=1; a=rsa-sha256; s=brisbane; d=exempel.com; c=enkel/enkel; q=dns/txt; [email protected]; h=Mottaget : Från : Till : Ämne : Datum : Meddelande-ID; bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=; b=AuUoFEfDxTDkHlLXSZEpZj79LICEps6eda7W3deTVFOk4yAUoqOB 4nujc7YopdG5dWLSdNg6xNAZpOPr+kHxt1IrE+NahM6L/LbvaHut KVdkLLkpVaVVQPzeRDI009SO2Il5Lu7rDNH6mZckBdrIx0orEtZV 4bmp/YzhwvcubU4=; Mottaget: från client1.football.example.com [192.0.2.1] av submitserver.example.com med SUBMISSION; Fre, 11 juli 2003 21:01:54 -0700 (PDT) Från: Joe SixPack <[email protected]> Till: Suzie Q <[email protected]> Ämne: Är middagen klar? Datum: fre, 11 juli 2003 21:00:37 -0700 (PDT) Meddelande-ID: <[email protected]> Hej. Vi förlorade spelet. Är du hungrig än? Joe.DKIM använder väletablerade kryptografiska verktyg. För närvarande erbjuder författarna till DKIM två algoritmer för digital signatur: RSA-SHA256 och RSA-SHA1 , men i framtiden kan tekniken utökas till att stödja andra algoritmer. Nyckellängden är begränsad till 4096 bitar, eftersom en större nyckel inte passar in i den maximala DNS UDP-paketstorleken på 512 byte. Den rekommenderade nyckellängden är mellan 1024 och 2048 bitar. För mycket längd skapar en beräkningsbelastning på servern för att bearbeta varje meddelande, och för lite (384 eller 512 bitar) hackas av brute force för den aktuella tiden med hjälp av en persondator eller med hjälp av en cloud computing-tjänst.
Denna teknik är kompatibel med den befintliga nätverksstrukturen och kräver ingen grundläggande förändring av tjänster (förutom för att ställa in SMTP) och ändringar i protokoll , därför kan den införas gradvis. Ett meddelande signerat av DKIM är helt "autonomt", vilket gör att DKIM kan fungera oberoende av PKI eller någon tjänst, eftersom nyckeln tas direkt från DNS-posten och inte behöver bekräftas av någonting. En organisation som använder DKIM är fullt ansvarig för driften av sin server, och närvaron av en digital signatur betyder bara att någon är ansvarig för ett visst meddelande.
I beskrivningen betonar utvecklarna av denna teknik att närvaron av en EDS i ett meddelande inte förpliktar den mottagande parten till någonting, inte ger skydd efter att signaturen har verifierats och inte kan påverka på något sätt om meddelandet återsänds om avsändare och mottagare har ändrats. Därför rekommenderar RFC att meddelanden från vanliga servrar som inte stöder DKIM hanteras på ett standard sätt.
En spammare kan skapa sin egen DKIM-aktiverade SMTP -server och DNS-server , vilket kommer att vara lagligt ur DKIMs synvinkel, men i det här fallet kommer domäner från en sådan server snabbt att tjäna "straffpoäng" och kommer att blockeras av en skräppostfilter i framtiden.