Waarom beveiligen we chat beter dan e-mail?

E-mail is een open boek

E-mail is notoir onveilig. Zonder in te gaan op alle technische details is het voornaamste probleem dat het aan de ontvanger is om te bepalen hoe (on)veilig je mailt. De meeste mailservers communiceren versleuteld met behulp van STARTTLS en controleren of de verzender betrouwbaar is via SPF, DKIM en DMARC maar je kan dit moeilijk afdwingen. Al richt je nog zo’n mooie, moderne mailserver in om mee te verzenden, als de ontvangers antieke jaren 90 server je mail niet snapt wordt het beveiligingsniveau automatisch verlaagd naar het equivalent van een luid gesprek in de trein.

Daarbij kan een hacker in het midden van je verbinding zitten (een zogenaamde Man-in-the-Middle-aanval) en zich voordoen als een oude server die *helaas* geen moderne standaarden ondersteunt. De mail moet aankomen, dus dan maar onversleuteld. En dat terwijl niemand nadenkt over wat er gemaild wordt. Veel instellingen hebben wel beleid dat er niks gevoeligs via e-mail gestuurd mag worden, maar ondertussen gaan er 2FA codes, gegevens van studenten, details over ICT-inrichting en gevoelige onderzoeksprojecten over de lijn. Voor chat is end-to-end encryptie inmiddels redelijk standaard. Het zou best de moeite waard zijn om email ook te versleutelen zodat niet iedereen mee kan lezen...

Hoe werkt ondertekening en encryptie?

Een tegenwoordig veelgebruikte standaard voor mailondertekening en -versleuteling is met S/MIME (Secure/Multipurpose Internet Mail Extensions) certificaten. Net zoals andersoortige certificaten gaat dit op basis van asymmetrische cryptografie. Om dat uit te leggen zou ik meerdere blogs nodig hebben dus hier is een leuk filmpje voor als je de basisconcepten van publieke en privésleutels nog niet kent: https://youtu.be/GSIDS_lvRv4. 

Voor het ondertekenen van een e-mail gebruik je jouw privésleutel. De ontvanger, laten we haar Alice noemen, kan daarna met behulp van jouw publieke sleutel controleren dat alleen jij die mail hebt kunnen ondertekenen. Als extra bonus kan Alice nu de volgende mail naar jou met je publieke sleutel versleutelen zodat die alleen door jou, met jouw privésleutel te lezen is. Elegant en effectief! Dit is de basis van bijna alle moderne encryptie. Zie voor meer uitleg bijvoorbeeld dit artikel van ZOHO. 

Waar begint het vertrouwen?

Er is echter nog één probleem: hoe weet Alice dat de publieke sleutel die ze initieel krijgt toegestuurd inderdaad van jou is? Daar zijn globaal twee tactieken voor:

• Alice vraagt aan aan haar collega Carol of die jouw sleutel toevallig heeft. Een vergelijkbare optie is dat jij een door Carol ondertekend bericht meestuurt waarin ze bevestigt dat jouw sleutel inderdaad bij jou hoort. Dit noemen we een *web of trust* waarbij vertrouwen transitief (A vertrouwt C, C vertrouwt jou, dus A vertrouwt jou) kan worden opgebouwd. Ook dat vertrouwen moet ergens starten, dus het is dan handig als Alice en Carol een keer fysiek kunnen verifiëren welk hoofd bij de sleutel hoort. Dit is hoe PGP, een van de oudste methodes voor versleuteling van digitale communicatie, werkt. In sommige kringen (bijvoorbeeld bij beveiligingsonderzoekers en CERT-teams) wordt dit nog veel gebruikt, maar het is nooit heel breed in gebruik genomen, uitzonderingen zoals het oude SURFnet daargelaten.
• Het alternatief is dat een centrale (certificaat) autoriteit de sleutels uitgeeft en voorziet van een bijbehorend certificaat van authenticiteit. Dit vereist natuurlijk dat de certificaatautoriteit (CA) vertrouwd wordt. Het idee is dat zo weinig partijen dat zouden mogen, dat het te doen is om hun publieke sleutel voor te installeren op computers of dat ze bekend genoeg zijn dat je op meerdere plekken de sleutel kan verifiëren. Als we het eenmaal eens zijn over wie een CA mag zijn en hun publieke sleutels algemeen bekend zijn (bij computers), schaalt dit veel makkelijker. Individuele gebruikers hoeven elkaar niet te verifiëren omdat ze bij de CA kunnen controleren of een sleutel bij een bepaalde gebruiker hoort. Nadeel is natuurlijk dat je centrale afhankelijkheden creëert, die bovendien 9 van de 10 keer commercieel partijen zijn. Dit is hoe S/MIME met certificaten van CA’s werkt.

En nu nog even doen

Met S/MIME certificaten hebben we dus een schaalbare manier om het benodigde sleutelmateriaal voor e-mail te krijgen en valideren. Daarbij wordt het ondersteund door de grote emailclients zoals Apple Mail, Outlook, Thunderbird en Gmail (alleen voor Workspace-accounts). Microsoft biedt zelfs de mogelijkheid om de benodigde S/MIME certificaten automatisch aan gebruikers uit te delen. In bijvoorbeeld Duitsland is het gebruikelijk dat ICT-afdelingen dit voor hun gebruikers regelen zodat er geen omkijken naar is.

Maar daar hoef je niet op te wachten. Hoewel ik er niet op zou gokken dat een hele organisatie dit individueel gaat regelen, is het voor een beetje computeraar goed te doen hier nu al gebruik van te maken. Je doet het volgende:

• Als je instelling SURFcertificaten gebruikt kan je via https://cm.harica.gr/sMIME gratis een persoonscertificaat aanmaken (kies IV+OV). 
• Als het goed is heeft je instelling de 'Academic Login' via SURFconext zo geconfigureerd dat HARICA je identiteit automatisch geverifieerd meekrijgt. Werkt dat niet meteen en word je gevraagd om een paspoort te uploaden? Vraag dan je ICT-afdeling dat samen met SURF op te lossen.
• Je krijgt na de stappen een .p12 bestand. Daar zitten zowel je privésleutel, publieke sleutel en certificaat in. Dit bestand beveilig je met een zelfgekozen wachtwoord.
• Importeer je certificaat en sleutels nu in je emailclient. Hier vind je handleidingen voor alle gangbare clients (in het Duits) maar een zoekopdracht naar 'Importeer S/MIME certificaat [client]' zal je ook op weg helpen. 

En voila, vanaf nu stuur jij alvast al je mails met een cryptografische ondertekening. Ontvangers weten op die manier zeker dat jouw mail niet onderweg gewijzigd is, en als ze dat willen kunnen ze versleuteld terugmailen. Voor echte schaal moeten ICT-afdelingen hier mee aan de slag. Als je daar niet op wil wachten kan je binnen je team of een andere specifieke groep je emailgesprekken nu eindelijk een beetje 21ste-eeuws beveiligen.