Alles over hedendaagse encryptiesoorten
Het versleutelen van communicatie blijft behoorlijk controversieel. Ondanks alle weerstand, onder meer vanuit sommige overheden en overheidsdiensten, wordt versleutelde communicatie langzaamaan de standaard. Hoe werkt encryptie eigenlijk en welke encryptiesoorten zijn er nu?
In de meeste democratische landen is het recht op vrije meningsuiting in de grondwet opgenomen, zoals in Nederland (artikel 7) en België (artikel 14). Deze visie sluit nauw aan bij wat de VN al in 1966 in het Verdrag voor Burgerrechten en Politieke Rechten stelde (artikelen 17 en 19). Het Europees Verdrag voor de Rechten van de Mens bevat verder het recht op respect voor onder meer ieders privéleven en correspondentie (artikel 8).
Veilig en vertrouwelijk communiceren, is dus een grondrecht. Dit recht hoort niet alleen bepaalde groepen te beschermen, zoals journalisten en dissidenten, maar geldt voor elke burger. Ook wanneer (je vindt dat) je niets te verbergen hebt, behoud je het recht op privacy. Dit blijkt trouwens steeds noodzakelijker in een informatiemaatschappij waarin je vaak niet eens kunt achterhalen welke persoonsgegevens zonder je toestemming waar en door wie worden gebruikt.
Daarbij komt dat vertrouwelijke communicatie je helpt om je te beschermen tegen allerlei vormen van cybercriminaliteit, zoals gegevens- en identiteitsdiefstal.
Tot zover een paar filosofische beschouwingen, over naar een meer technische insteek. De efficiëntste manier om vertrouwelijk te kunnen communiceren, blijft vooralsnog stevige versleuteling. Enig inzicht in hoe encryptie werkt en hoe die in diverse communicatiescenario’s kan worden toegepast, lijkt ons daarom best nuttig.
Rotatie van alfabet
Aan een versleutelde boodschap als ‘rra cyhf rra vf gjrr’ heb je niks zonder de bijbehorende sleutel. In dit geval is dat een simpele rotatie van dertien letters in het alfabet (ROT13). Vaak zijn zulke sleutels via trial-and-error (brute force) snel te achterhalen. Dat geldt des te meer als je daarbij rekening kunt houden met andere factoren, zoals de wetenschap dat de letter ‘e’ in het Nederlands de meest voorkomende letter is. Zou de ‘r’ in onze boodschap een ‘e’ kunnen zijn?
Bij encryptie is er bovendien het probleem van hoe je de sleutel veilig bij de beoogde ontvanger krijgt. En wat als deze versleuteling alleen maar ‘point-to-point’ verloopt (P2PE), bijvoorbeeld van de verzender tot aan de (eerste tussenliggende) ontvanger of server, zoals bij sommige vormen van digitale communicatie? Ten slotte, de eigenlijke boodschap mag dan nog over de hele route stevig versleuteld zijn via end-to-end encryptie (E2EE), in de praktijk zijn heel wat zogenoemde metadata toch niet versleuteld en daaruit valt alvast op te maken wie iets op welk moment naar wie heeft gecommuniceerd.
Allemaal beslommeringen waar de cryptografie zich al decennia over buigt en die hun weerslag vinden in diverse encryptietoepassingen. We bespreken kort een paar basisbeginselen van de cryptografie en vervolgens enkele technieken in communicatietoepassingen zoals e-mail en (tekst- en video-)chat.
Symmetrische encryptie
Onze versleutelde boodschap uit het voorbeeld is een schoolvoorbeeld van symmetrische encryptie. Dit houdt in dat de sleutel die voor de encryptie wordt gebruikt (ROT13 in dit geval) ook nodig is voor de ontcijfering van de boodschap. Bekende methodes voor symmetrische encryptie zijn bijvoorbeeld DES, Triple DES en AES (Advanced Encryption Standard, ook wel bekend als Rijndael). Het probleem met het inmiddels verouderde DES is vooral de beperkte sleutellengte (56 bit, of 3×56 bit bij 3DES), wat brute-force-aanvallen mogelijk maakte.
AES wordt als veilig(er) beschouwd, althans met een sleutellengte van minimaal 192 bit, en wordt daarom nog altijd gebruikt bij onder meer ssh, IPsec (VPN) en WPA2. We gaan hier wel voorbij aan mogelijke side-channel-aanvallen, waarbij niet de cryptografische methode op zich, maar wel (mogelijke datalekken afkomstig van) gebrekkige implementaties worden aangevallen.
Een probleem inherent aan elke symmetrische encryptiemethode is helaas de sleuteldistributie: hoe krijg je de sleutel veilig bij de bedoelde ontvanger? Met asymmetrische encryptie tracht men dat probleem aan te pakken.
Asymmetrische encryptie
Het idee van asymmetrische encryptie kreeg vorm in de jaren zeventig van vorige eeuw in de Diffie-Helman-sleuteluitwisseling, gevolgd door het nog complexere RSA-encryptiealgoritme. Bij deze vorm van encryptie horen twee verschillende sleutels: een geheime of privésleutel en een publieke sleutel die zuit handen mag worden gegeven. Dat kan doordat uit deze publieke sleutel de privésleutel niet kan worden afgeleid, terwijl het omgekeerde wel het geval is.
Het is dus de bedoeling dat je een boodschap met de publieke sleutel van de beoogde ontvanger versleutelt, aangezien alleen hij over de (privé)sleutel beschikt waarmee de boodschap kan worden ontcijferd.
Deze techniek levert nog een ander voordeel op. Stel: je versleutelt je bericht – in de praktijk is dat doorgaans een digest oftwel hash ervan (een unieke verkorte versie, zeg maar) – ook met je eigen privésleutel. Wanneer je vervolgens het resultaat, een zogenoemde digitale handtekening, aan je bericht toevoegt, kan de ontvanger via jouw publieke sleutel vaststellen of het bericht echt van jou komt (authenticatie) en of het onderweg niet heimelijk werd aangepast. Ook dat helpt mee aan een veiliger communicatie.
Hybride encryptie
Wie dacht dat de symmetrische en de asymmetrische encryptiemethode intussen in een eeuwige strijd verwikkeld zijn geraakt, denkt verkeerd. Integendeel zelfs: in de praktijk blijken beide methodes namelijk mooi complementair en gebruikt men ze gecombineerd in heel wat cryptografische implementaties. Hybride encryptie dus.
Zo worden verbindingen tussen computernetwerken vaak eerst asymmetrisch tot stand gebracht met behulp van een publieke en een geheime sleutel, waarna de eigenlijke gegevensoverdracht symmetrisch plaatsvindt op basis van de geheime sleutel, bijvoorbeeld met RSA of AES. Deze werkwijze combineert slim de hogere snelheid van de symmetrische methode met de veiligheid van de asymmetrische methode.
Laten we nu enkele concrete encryptieprotocollen en -implementaties bekijken, bij zowel e-mail als diverse chatdiensten. Ook hier komt hybride encryptie geregeld om het hoekje kijken.
E-mail: (START)TLS
SMTP (Simple Mail Transport Protocol) kunnen we gerust een verouderd protocol noemen. Er zijn immers geen ingebouwde voorzieningen naar encryptie of authenticatie toe. Gelukkig zijn er uitbreidingen en standaarden gekomen die voor een betere beveiliging zorgen. Zo ondersteunen haast alle mailservers en -clients inmiddels TLS (Transport Layer Security) en STARTTLS.
Je moet uiteraard wel je mailclient correct configureren. Om bijvoorbeeld in Microsoft Outlook na te gaan welk versleutelingsmechanisme wordt gebruikt, ga je naar Bestand / Accountinstellingen / Accountinstellingen, selecteer je een account, klik je op Herstellen / Geavanceerde opties en plaats je een vinkje bij Ik wil mijn account handmatig herstellen. Klik vervolgens op Repareren en controleer de instellingen bij Uitgaande e-mail.
Let wel, het gaat hierbij uitsluitend om transportversleuteling (op basis van hybride encryptie trouwens). Dit is een vorm van P2Pe, wat maakt dat de encryptie intact blijft tot aan de mailserver van je provider, maar niet noodzakelijk tijdens het verdere transport. Weet dus dat je mailprovider je berichtgeving nog altijd kan inkijken, eventueel na een dwangbevel.
DANE en MTA-STS
Er is dus wel versleuteling tijdens het transport van de verzender naar de mailserver van de provider, maar helaas mist (START)TLS enige vorm van authenticatie, zodat nog steeds allerlei aanvalsscenario’s mogelijk zijn.
Zo verneemt de verzender pas tijdens de sessie met de andere mailserver of deze transportversleuteling ondersteunt. Een aanvaller die de datastroom tussen beide controleert, kan vervolgens opzettelijk aangeven dat die datastroom geen encryptie ondersteunt, waarna de verzender de sessie downgradet en de berichten onversleuteld verstuurt. Of de aanvaller zet een MitM-scenario op, waarbij hij zich ongemerkt tussen beide mailservers positioneert, en zich als de legitieme doelserver voordoet, zodat hij de – versleutelde – berichtgeving probleemloos kan inkijken.
Om dergelijke scenario’s tegen te gaan, zijn er standaarden ontwikkeld als DANE (Dns-based Authentication of Name Entities) en MTA-STS (Mail Transfer Agent - Strict Transport Security). Terwijl DANE DNSSEC gebruikt voor de verificatie van het servercertificaat, houdt MTA-STS het wat eenvoudiger en berust die op een lijst van vertrouwde root-CA’s.
MTA-STS hanteert het TUFU-model (Trust Upon First Use; ook afgekort als TOFU), waarbij men ervan uitgaat dat de publieke sleutel bij de eerste verbinding correct is. Men zal hier dus de mogelijkheden van de server – zoals ondersteuning van STARTTLS – meteen vaststellen en ook netjes volgen, wat een downgrade-aanval moet uitsluiten. Helaas kan zowel DANE als MTA-STS in de praktijk vooralsnog op matige ondersteuning rekenen.
DMARC
Terwijl DANE en MTA-STS vooral MitM-bedreigingen tegengaan, waarbij de aanvaller bijvoorbeeld DNS-poisoning gebruikt om heimelijk een andere mailserver te kunnen inzetten, is een andere, complementaire standaard met de naam DMARC er vooral op gericht om de bedreigingen als spam tegen te gaan. Immers, het onderliggende SMTP-protocol verhindert niet dat iemand zich met de mailserver van een ontvanger verbindt om hem mail te versturen die van een ander domein afkomstig lijkt. DMARC hebben we in het vorige PCM-nummer uitvoerig besproken (in de reeks ‘De standaard’) en behandelen we hier dus heel beknopt.
In feite berust DMARC grotendeels op twee andere technieken: SPF (Sender Policy Framework) en DKIM (DomainKeys Identified Mail). SPF is bedoeld om e-mailspoofing tegen te gaan en werkt op basis van een txt-bestand in de nameserver-configuratie van een domein. Hiermee geef je aan dat een host alleen mail mag versturen namens een bepaald domein.
DKIM is een e-mailverificatieprotocol dat middels een handtekening moet vermijden dat berichten tijdens het transport kunnen worden aangepast. DMARC bouwt voort op beide protocollen en staat bovendien toe dat je via beleidsregels kunt aangeven hoe streng je de SPF- en DKIM-controles wilt uitvoeren, zoals verwerpen of in quarantaine plaatsen. Net als bij DANE en MTA-STS verloopt helaas ook de implementatie van DMARC op mailservers trager dan verhoopt.
S/MIMEen OpenPGP
Als eindgebruiker heb je (helaas) niets te zeggen over het toepassen van standaarden als DANE, MTA-STS of DMARC. Wil je zowel authenticatie als solide versleuteling, dan zit er vooralsnog weinig anders op dan end-to-end-encryptie in te zetten. De bekendste implementaties zijn S/MIME en PGP, die beide trouwens ook een vorm van hybride encryptie toepassen.
S/MIME vereist wel een certificaat en aangezien een volwaardig certificaat niet gratis is, wordt dit vooral in bedrijfsomgevingen ingezet. Bij onder meer de CA’s CAcert en Actalis kun je wel een gratis e-mailcertificaat aanvragen en in mailclients als bijvoorbeeld Outlook gebruiken. De verificatie gebeurt bij deze gratis certificaten wel alleen op basis van je e-mailadres.
Pgp wordt meer door de ‘gewone’ en privacybewuste gebruiker ingezet, meestal in de vorm van OpenPGP aangezien die licentieperikelen met het originele PGP omzeilt, net als GnuPG. Meer nog dan bij S/MIME vereist de installatie en configuratie wel enige inspanning. Bij Thunderbird, dat OpenPGP al geruime tijd heeft ingebouwd, werkt dit al iets makkelijker.
Dankzij deze end-to-end-encryptie worden je berichten weliswaar over de hele route versleuteld, van zender tot ontvanger, maar besef wel dat ook hier nog altijd metadata onversleuteld blijven, zoals e-mailadressen en timings. Het is wellicht wachten op een nieuw protocol om ook die zwakte aan te pakken.
Chat: E2EE
De aandachtspunten voor een veilige communicatie via chatdiensten zijn weinig anders dan die bij e-mail: wie kan er meelezen (of meeluisteren of -kijken, bij audio- en videochat), hoe bescherm je je tegen spoofing en in welke mate geef je tijdens je chatsessies ongewild metadata prijs?
Laten we met het eerste beginnen: hoe voorkom je dat je gesprekken worden afgeluisterd? Het antwoord op deze vraag is duidelijk: met behulp van end-to-end-encryptie, E2EE. Volledige versleuteling over de hele route dus maar helaas is dat (nog) niet bij alle communicatie-apps standaard ingebouwd.
Bij Microsoft Teams bijvoorbeeld worden de gesprekken wel met P2PE versleuteld, maar dat houdt in dat Microsoft je gesprekken kan opnemen. Er is gelukkig beterschap op komst. Op het Ignite Event (maart 2021) maakte Microsoft plannen bekend om E2EE alvast in 1-op-1-gesprekken mogelijk te maken door – weliswaar aan beide kanten – simpelweg een optie te activeren. Binnen afzienbare tijd zou deze functie ook beschikbaar komen voor geplande gesprekken en online meetings.
Microsoft Skype maakt wel al E2E-communicatie mogelijk maar dat gebeurt alleen in een privéchat, een optie die niet beschikbaar is in de webversie. Het is overigens wel de vraag of Skype nog een lang leven beschoren is.
Zoals je weet, maakt WhatsApp al langer gebruik van E2EE (sinds april 2016). Daarvoor maakte het systeem, net als Skype trouwens, gebruik van dezelfde opensource-cryptografie (Open Whisper Systems) als de app Signal. Degelijk dus, maar helaas is WhatsApp zelf niet opensource en heb je dus geen echte garantie dat er geen achterdeuren in de app zijn ingebouwd. Met een whitepaper hoopt WhasApp dat wantrouwen weg te krijgen. In dat bestand valt trouwens te lezen dat ook audio- en videogesprekken end-to-end worden versleutel, op basis van het SRTP-protocol (Secure Real-Time Transport Protocol).
Het al vermelde Signal doet beter, aangezien de app zelf ook opensource is, wat inhoudt dat je de broncode op potentiële achterdeurtjes kunt controleren.
Het is trouwens zo dat de meeste bekende communicatie-apps standaard end-to-end-encryptie ondersteunen, waaronder Google Duo en FaceTime (deze laatste weliswaar alleen tussen Apple-gebruikers onderling). Ook de videoconferentie-app Zoom ondersteunt deze functie, maar na het toelaten van end-to-end-encryptie in de instellingen van de web-app moet je het Default encryption type dan wel ook nog instellen op End-to-end encryption als je wilt vermijden dat de encryptiesleutel in de Zoom-cloud wordt bewaard.
Ook Jitsi ondersteunt inmiddels deze encryptie, weliswaar nog in bèta-versie en met recente browsers of via de eigen Electron-client. Jitsi laat zich trouwens ook op een eigen server hosten.
Authenticatie
Versleuteling is één zaak, maar eigenlijk net zo belangrijk is authenticatie. Je wilt namelijk zeker weten dat de persoon met wie je chat wel degelijk is wie hij beweert te zijn.
De meeste apps trachten zo’n scenario tegen te gaan met handtekeningen die je op basis van de publieke sleutel van de gesprekspartner kunt controleren. Dat kan via vertrouwde certificaten gebeuren, maar verloopt in de praktijk meestal op basis van TUFU (zie ook de paragraaf ‘DANE en MTA-STS’). Hierbij gaat men er dus van uit dat bij de eerste verbinding de publieke sleutel correct is.
De meeste apps waarschuwen de gebruiker wanneer deze identifier (publieke sleutel) wijzigt en sommige kennen ook een methode om die op elk moment te kunnen verifiëren. Dit geldt bijvoorbeeld voor Telegram en Signal. Bij deze laatste kan dat via een QR-code of door het ‘safety number’ over een geauthenticeerd kanaal uit te wisselen.
Authenticatie is dus een prima beveiligingsoptie, maar besef wel dat je door het ondertekenen van een bericht met je privésleutel onwillekeurig aangeeft dat dit bericht echt van jou afkomstig is. Je kunt dit ook later niet meer ontkennen (‘non-repudiation’), tenzij de sleutel voor de handtekening automatisch en regelmatig wordt aangepast.
Idealiter gebeurt deze aanpassing ook voor de encryptie van de berichten zelf, ook wel (Perfect) Forward Secrecy genoemd. Zelfs wanneer je privésleutel gecompromitteerd is, kunnen je eerdere berichten daarmee niet worden ontsleuteld – toekomstige eventueel nog wel. Onder meer het Signal-protocol ondersteunt deze functie.
Extra (meta)data
Op het vlak van encryptie zit het bij messaging- en videoconferencing-apps over het algemeen dus wel goed, aangezien de meeste end-to-end-encryptie ondersteunen, maar de vraag is nog welke data onversleuteld blijven. Helaas blijven, net als bij e-mail, bepaalde metadata buiten schot, zoals wanneer je met wie chatte, en zoeken veel apps bovendien op allerlei manieren naar extra informatie. Zo moet je tijdens de aanmelding doorgaans je smartphone (met telefoonnummer) koppelen aan de dienst.
Threema is een van de weinige uitzonderingen: je Threema-id hangt niet af van een telefoonnummer maar wordt permanent aan je publieke sleutel gekoppeld.
Veel apps pushen je meteen na de aanmelding ook om toegang tot je contactpersonen te verlenen, zoals WhatsApp en zelfs Signal. Dat is op zich handig, aangezien de app ook zelf naar potentiële gesprekspartners kan zoeken, maar als je weet dat WhatsApp in handen is van Facebook, stemt dit toch tot nadenken.
Vergeet ook niet dat het chatverkeer bij vrijwel alle apps over een centrale server loopt, wat evenmin bevorderlijk is voor het vertrouwen (en vertrouwelijke communicatie). De messenger-app Briar (www.briarproject.org; voor Android) is alvast één uitzondering op deze regel: berichten worden rechtstreeks en versleuteld tussen de apparaten zelf gesynchroniseerd via bluetooth of wifi, of via het TOR-netwerk. Zijn er nog klokkenluiders?
