S/MIME, BIMI, VMC, SPF, DKIM, DMARC, TLS?

S/MIME, BIMI, VMC, SPF, DKIM, DMARC, TLS?
17 dec ‘21

Ziet u door de bomen het bos niet meer?

 Email beveiliging is belangrijk, daar is iedereen het over eens. Om toegang tot email te beveiligen wordt gebruik gemaak van een gebruikersnaam met wachtwoord, of bij voorkeur van Multi Factor Authentication (MFA), waarbij de verbinding via Transport Layer Security (TLS) verloopt middels een SSL-certificaat. Ook voor het verzenden van email tussen mailservers wordt TLS gebruikt.

Maar hoe weet het ontvangende network, en nog belangrijker de ontvangende persoon, nu zeker dat de ontvangen email, verstuurd is door de persoon waarvan je aanneemt dat deze het is?  Hiervoor bestaan verschillende standaarden die elkaar aanvullen en ieder hun eigen specifieke nut hebben.

  • Secure Multipurpose Internet Mail Extensions (S/MIME) is er sinds 2002 en is een defacto standaard voor end-to-end beveiligde/verifieerbare email.
  • Hoewel Sender Policy Framework (SPF), DomainKeys Identified Email (DKIM) en Domain-based Message Authentication, Reporting & Conformance (DMARC) al de nodige jaren bestaan, worden ze pas grootschalig toegepast sinds 2018.
  • Sinds 2021 komt daar nu een nieuwe standaard bij: Brand Indicators for Message Identification (BIMI) met een daarvoor benodigd Verified Mark Certificate (VMC)

Wat is waarvoor:

Alle genoemde standaarden hebben hun eigen specifieke nut en toepassing waardoor ze elkaar ook niet vervangen of uitsluiten:

 

S/MIME Vereist per email adres een S/MIME certificaat dat meestal op het apparaat van een gebruiker wordt geinstalleerd. Dit zorgt ervoor dat:

  • De ontvanger zeker weet wie de email stuurde
  • De ontvanger zeker weet dat de email niet is gewijzigd qua inhoud (body en attachments)
  • Voor beide bovenstaande opties is alleen een S/MIME certificaat nodig voor verzenden
  • Het email bericht voor zowel ontvanger als verzender versleuteld is op het apparaat waarop de email kan worden gelezen en tijdens verzending, zodat alleen de verzender en ontvanger het bericht kunnen lezen.

 

TLS Vereist per mailomgeving een of meerdere SSL-certificaten aan de netwerk kant. Dit zorgt ervoor dat:

  • De mail vanaf het moment van versturen vanaf de mailclient, versleuteld is, tot en met deze de ontvanger bereikt (versleuteling tijdens transport).

 

SPF Vereist alleen een DNS record. Dit zorgt ervoor dat:

  • E-mail geauthentiseerd wordt, zodat op network niveau gevalideerd kan worden dat het verstuurd is van een geïdentificeerde mailserver voor een specifiek domein.
  • Echter geen bewijs van identiteit en geen bewijs dat boodschap niet na verzending is aangepast.

 

DKIM Vereist alleen een DNS record. Dit zorgt ervoor dat:

  • Elke verzonden e-mail op domein niveau (dus niet op e-mailadres niveau) een digitale handtekening meekrijgt, om te bewijzen dat de email daadwerkelijk verzonden is vanaf het domein van de verzender.

 

DMARC Vereist enkel een DNS record. Dit zorgt ervoor dat:

  • De ontvangende mailserver weet wat het met een e-mail moet doen die niet voldoet aan de SPF en DMARC validatie. Bijvoorbeeld: stop de ontvangen e-mail in quarantaine.

 

BIMI Vereist alleen een DNS record. Dit zorgt ervoor dat:

  • Ontvangen e-mails door de ontvangende e-mail provider worden voorzien een een gevalideerd logo van de organisatie die de e-mail verzond.

 

VMC Vereist een aantoonbaar beschermd beeldmerk, waarbij er 1 Verified Mark Certificate per beeldmerk moet worden aangeschaft (geldig 1 jaar). Dit zorgt ervoor dat:

  • Indien er BIMI is ingestelt, dat deze kan verwijzen naar een logo/beeldmerk.
  • Indien de ontvangende e-mailprovider BIMI ondersteunt, het logo van de verzender wordt weergegeven bij een ontvangen e-mail

 

Veel voorkomende verwarring

 Nu de verschillende standaarden zijn uitgelegd, is het makkelijk om veel gestelde vragen te beantwoorden:

  •  Als ik DKIM gebruik, dan heb ik toch geen S/MIME voor digitale handtekeningen nodig?

DKIM zorgt voor een digitale handtekening op mail niveau die alleen wordt gebruikt en zichtbaar is voor de mail-provider van de ontvanger. Deze DKIM digitale handtekening is niet zichtbaarbaar of bruikbaar voor de daadwerkelijke ontvanger.

Een S/MIME gebaseerde handtekening is wel zichtbaar voor de echte ontvanger. De mailclient zal door deze S/MIME gebaseerde digitale handtekening direct een indicatie geven of een e-mail qua body en attachment is gewijzigd nadat deze verzonden was EN stelt de ontvanger in staat om te valideren wie de e-mail daardwerkelijk heeft gestuurd.

  • Als ik toch al email versleuteld via TLS verstuur, dan heb ik toch geen S/MIME email encryptie nodig?

TLS zorgt ervoor dat email, versleuteld is vanaf het moment dat er op “verstuur” wordt gedrukt in de mailclient, tot de mail aankomt bij de ontvanger. Kortom data in beweging versleuteling, ook wel punt-naar-punt versleuteling genoemd.

S/MIME zorgt ervoor dat de verzonden email aan de kant van de verzender, als ook aan de kant van de ontvanger in rust versleuteld is. Ook wel end-to-end versleuteling genomend. Niemand kan de bijlages en email bodytekst lezen, tenzij ze over de private sleutel beschikken van de ontvanger. Iemand die illegaal kan inloggen op een mailaccount, kan dus niet de mails lezen.

Maar ook de email provider kan de inhoud van de emails niet scannen, bijvoorbeeld voor het leveren van specifieke advertenties.

  1. BIMI en VMC zorgen als standaard toch wereldwijd voor extra email beveiliging?

BIMI en VMC zorgen voor merkherkenning, en is daarmee vooral bedoeld voor marketing.

Daarbij zijn BIMI en VMC op wereldwijde schaal op het moment van schrijven van dit artikel, alleen ondersteunt door GMail en Yahoo! Mail

Microsoft heeft aangegeven niet voornemens te zijn om BIMI en VMC te gaan ondersteunen, en ondersteunt het ook niet op dit moment.

Online controleren van BIMI/VMC en DMARK/DKIM/SPF

Wilt u controleren of een bedrijf voor haar domein DMARK, DKIM, SPF, BIMI, en VMC (goed) heeft ingesteld? Dit kan eenvoudig via: https://bimigroup.org/bimi-generator/

Wilt u een duidelijk pad in dit donkere IT bos? Neem contact op met ons!

 

Het KeyTalk Team