KORMÁNYABLAK, ÜGYFÉLKAPU - A ZÁRT AJTÓK MÖGÖTT... (nem hivatalos e-kormányzati témájú oldal)
BEMUTATKOZÁS
E-KÖZIGAZGATÁS
IT BIZTONSÁG
		Mottó: Spam, Spam, Spam, Egg, and Spam /Monty Python's Flying Circus: Spam (S02E12)/ 2024. április 1.       DKIM: Spam, Spam, Spam, GMail, and Spam         A húsvéti tojások festegetése és az április 1-i bolondozás közepette érdemes megvizsgálni a Google levelező (GMail) két hónappal ezelőtti (2024-02-01) módosításának hatásait, ugyanis a felhasználói panaszok alapján különböző cikkek is megjelentek már a hírportálokon arról, hogy "valami nem megy". De mi is történt most? Még 2023 őszén (2023-10-03) a GMail bejelentette, hogy 2024-02-01-től kezdődően módosít a spam-besorolási feltételein. Az egyik kötelezővé vált feltétel szerint amelyik levélben ezentúl nem szerepel a fejlécben a küldő fél digitális aláírása, az spam-nek fog minősülni. (Set up SPF or DKIM email authentication for your sending domains. [...] Sending to personal Gmail accounts requires a DKIM key of 1024 bits or longer. For security reasons, we recommend using a 2048-bit key if your domain provider supports this.) De kinek a digitális aláírását kell beilleszteni a levél fejlécébe? Most nem az egyszerű végfelhasználóról van szó, azaz nem a saját eSzemélyi okmányunkat vagy PGP/GPG kulcsunkat kell használni a levelezőprogramban. A küldő fél a jelen esetben az SMTP server, amelynek domain bejegyzéséhez (DNS TXT Record) kerül hozzárendelésre kriptográfiai kulcs, a fogadó félnek pedig el kell ezt érnie, hogy az ellenőrzést végre tudja hajtani. De milyen módon kell a digitális aláírást létrehozni és ellenőrizni? A "DomainKeys Identified Mail (DKIM) Signatures" réteget először az IETF RFC 4871 írta le (2007-05), amelynek jelenlegi verziója az IETF RFC 6376 (2011-09). Most, 17 év után a GMail elérkezettnek látta az időt, hogy kötelezővé tegye a DKIM szabvány alkalmazását. Ennek megfelelően az SMTP levélben a digitális aláírás, azaz a "DKIM-Signature" elem le kell, hogy fedje mind a törzset (body), mind a fejlécet (header), azaz kriptográfiailag védenie kell - hitelesség és sértetlenség szempontjából - többek közt a teljes üzenetküldői láncolatot is ("From:" és "Received:" elemek, amelyek alapján a DNS bejegyzésben levő nyilvános kulcs - az aláírás ellenőrzéséhez - lekérdezhető). A DKIM szabvány (IETF RFC 6376) leírása kellően részletes és pontos, illetve tartalmaz "test vector" adatokat (Appendix A), amelyek alapján a bit szintű működés könnyebben ellenőrizhető (kriptográfiai szabványoknál, főleg hash számításoknál ez mindenképpen hasznos). A folyamat leírásához ezen "test vector" adatait használtam fel. A folyamat a küldő fél, az SMTP server oldalán indul, a levél létrehozásával. A létrehozott levél átadásra kerül a küldő fél, az SMTP server számára: ezt - a "DKIM-Signature" elemben - a "d=example.com;" (domain) és "s=brisbane;" (subdomain) azonosítja be. A küldő fél, az SMTP server először a levél törzséről (body) készít egy lenyomatot, ami előtt egységes formátumra hozza azt: ez a kanonikalizálási mód (header/body) szerepel a "DKIM-Signature" elemben, mint "c=simple/simple;" (canonicalization), de az alapértelmezett "simple" mellett létezik "relaxed" mód is. A kanonikalizált levél törzséről (body) készített lenyomat - base64 kódolva - bekerül a levél fejlécében (header) a "DKIM-Signature" elembe, mint "bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;" elem. Ezután a küldő fél, az SMTP server a levél fejlécéről (header) készít egy lenyomatot - szintén kanonikalizálás után -, amiben már a "DKIM-Signature" elem is szerepel a paramétereivel, de pont a digitális aláírás értékét tartalmazó elem még csak "üresen", ld. "b=;" elem. A lenyomat - hash - által lefedett elemek a "DKIM-Signature" elemben vannak felsorolva, ld. "h=Received : From : To : Subject : Date : Message-ID;". Végül a küldő fél, az SMTP server létrehozza a digitális aláírás értékét a kiszámolt lenyomat és a saját titkos kulcsa alapján, ami - base64 kódolva - bekerül a "DKIM-Signature" elembe, mint "b=AuUo[..]bU4=;" elem. A digitálisan aláírt levél elküldésre kerül. A folyamat a fogadó oldalán folytatódik. A fogadó fél a levél fejlécéről (header) készít egy lenyomatot - kanonikalizálás után -, pontosan olyan sorrendben és olyan elemeken végigfuttatva, ahogy azt a küldő fél, az SMTP server is tette a "h=Received : From : To : Subject : Date : Message-ID;" elem értéke alapján (ebből látszik, hogy pontosan mely elemeket fedi le és védi - a "DKIM-Signature" elemmel együtt - a lenyomat a digitális aláírásban, a "b=AuUo[..]bU4=;" elemben). A fogadó fél ellenőrzi a digitális aláírás értékét a kiszámolt lenyomat és a nyilvános kulcs alapján. Siker esetén a levél fejléce (header) adatainak sértetlensége és hitelessége biztosított. A következő lépésben ellenőrizni kell még a levél törzsének (body) lenyomatát is, ami a fejlécben (header) szerepel védetten. Tehát, a fogadó fél a levél törzséről (body) is készít egy lenyomatot - kanonikalizálás után -, aminek - base64 kódolt - értékét összeveti a fejlécben (header) szereplő értékkel, ld. "bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;". Siker esetén a levél törzse (body) adatainak sértetlensége és hitelessége is biztosított. Ha pedig mind a levél törzse (body), mind a fejléce (header) sikeresen kerül ellenőrzésre, akkor a küldő fél adatai ("From:" elem) igazoltnak tekinthetők, illetve a levél tartalma sem módosult: a levél a Google levelező (GMail) szabályai szerint nem a "spam" mappába kerül. Bár, a A DKIM szabvány (IETF RFC 6376) "test vector" adatainál (Appendix A) a kriptográfiai réteg lefedi a "Received:" elemet is, a valóságban ezt nem szokták így használni, mert jelentősen bonyolítaná a feldolgozást. Ennek oka, hogy a láncolatban részt vevő minden SMTP server - a specifikáció szerint - beleilleszti a saját "Received:" elemét (egymás után), így pedig a digitális aláírás ellenőrzése a fogadó félnél nem is lenne annyira egyszerű. Éppen ezen lehetséges problémák elkerülése érdekében a valóságban - pl. OpenDKIM modul alapértelmezett beállításánál - ez a "Received:" elem nem szerepel a védendő adatok között (a küldő fél hiteles beazonosítására a digitális aláírással lefedett "From:" elem is elegendő). Ezen - együttműködési szempontból fontos - egyszerűsítés ellenére is a kriptográfiai védelemnek jelentős haszna lehet, főleg ha a tanúsítványok elfogadhatóságára is megfelelő szabályokat alkalmaznak majd. Ellenkező esetben előállhat ugyanaz a helyzet, mint az SSL/TLS web server tanúsítványoknál: megbízható szolgáltatóktól származó, ingyenes, jellemzően csak 90 napig érvényes - pl. "COMODO RSA Certification Authority" alatti "cPanel, Inc. Certification Authority" vagy "ISRG Root X1" alatti Let’s Encrypt "R3" - tanúsítványokat kezd el mindenki használni, azonban ezek mögött legfeljebb DV (Domain Validated) szerinti ellenőrzés történik, ami nem árul el semmit a mögöttes jogi személy kilétéről, megbízhatóságáról. Az eredményes működéshez - SSL/TLS web server, illetve SMTP server esetében is - OV (Organization Validated) vagy EV (Extended Validated) tanúsítványok megkövetelésére lenne szükség. Kapcsolódó anyagok: IETF RFC 6376 "test vector" (Appendix A) (HTML) IETF RFC 6376 "test vector" (Appendix A) (ZIP) levélküldési statisztikák, Talos (pl. t-online.hu)   vissza
			info@kormanyablak.org info@ugyfelkapu.info