In reactie op mijn betoog Versleutel alles tegen glurende AIVD (26 mei 2014, CIO) ontving ik een mailtje van iemand die wil weten hoe digitale communicatie te beschermen. De aanleiding van mijn betoog was trouwens dat de inzet van ongerichte interceptie van ethercommunicatie structureel onvoldoende wordt gemotiveerd, blijkens rapporten van toezichthouder CTIVD, en dat die bevoegdheid nu juist wordt uitgebreid naar kabelcommunicatie — inclusief zgn. ‘search’ op binnenlandse communicatie dat bijvoorbeeld mag worden toegepast om potentiële toekomstige targets te identificeren — zonder dat duidelijk is of en hoe dat structurele probleem (dixit CTIVD) wordt opgelosl.

Ik heb even de tijd genomen voor een antwoord, en wil die hier delen.

Dit is het bericht dat ik ontving:

Onlangs las ik uw artikel over versleuteling van alle digitale communicatie. Alhoewel ik op zich niets te verbergen heb, weet je het maar nooit in de huidige complexe wereld wie wie bespiedt! Alleen het woordje versleuteling kan al de nodige alarmbellen doen afgaan!

Kunt u een aanbeveling maken hoe of met welk pakket de versleuteling gedaan kan worden. Terwijl ik dit schrijf bedenk ik me dat hier (en ook in uw artikel) gesproken wordt over communicatie. Ik kan me goed voorstellen dat je je eigen gegevens op je eigen computer versleutelt, zodat bij inbraak hierin geen of minder schade kan worden toegebracht. Zelfs is de vracht of dit laatste wel juist is: misschien is het zo dat er hierbij geen twee keuzes zijn: de zaak is veilig (door versleuteling) of helemaal niet! Dit in analogie met het feit dat een vrouw ook niet een beetje zwanger kan zijn.

Maar hoe zit het met communicatie naar buiten. Wordt mijn uitgaande e-mail wel versleuteld en kan dan een willekeurige ontvanger deze dan nog wel lezen. Of moet je je computer (ik heb een Apple Mac) zodanig inrichten dat je een open gedeelte en een versleuteld gedeelte hebt. En ook hoe zit het met een externe Cloud die je gebruikt of (in mijn geval) een Airport Time Capsule die continue een backup maakt van alle wijzigingen En ‘ten slotte’ (bij elke vraag of statement komen er weer nieuwe bij) hoe veilig is de versleuteling-software? Wie zegt dat daarin geen geheim achterdeurtje ingebouwd is.

Mijn antwoord was als volgt (NB: ik geef niet op alle onderwerpen die de verzender noemt antwoord):

In het kader van dat CIO-artikel heb ik de volgende gedachten:

Kort antwoord: alle gegevens moeten tijdens transport zijn beveiligd met TLS. Gebruik TLS-versie 1.1 of hoger, sta alleen ciphers uit de categorie ‘HIGH’ toe met voor key agreement een Perfect Forward Secrecy (PFS)-enabled algoritme zoals ECDH. Voor end-to-end-beveiliging kun je PGP gebruiken, hoewel dat een steile leercurve heeft en geen PFS biedt.

Langer antwoord: bij een holistische aanpak van privacy/beveiliging moet worden nagedacht over gegevens in alle toestanden. Dus: in opslag, in transport en in verwerking. Voor wat ik in het CIO-artikel betoog, is primair van belang dat gegevens zo min mogelijk onversleuteld worden *getransporteerd*. Uit de Snowden-documenten blijkt bijvoorbeeld dat GCHQ toegang heeft tot zo’n 1500 glasvezelkabels kabels en mid-2012 probes heeft geplaatst op 200 glasvezelkabels. Als die kabels onversleutelde communicatie van miljoenen mensen dragen, is het wel wat *erg* eenvoudig om massaal heimelijk af te luisteren, en liggen misbruik en function creep op de loer. Persoonlijk vind ik het wenselijk dat de inlichtingendiensten (in bepaalde gevallen) afhankelijk zijn van medewerking van de IT-dienstverleners. Dat biedt de kans aan die bedrijven om tegenmacht te bieden, bijvoorbeeld door verplichtingen tot bepaalde vormen van medewerking bij de rechter aan te vechten. Daarmee is de discussie niet definitief beslecht, maar wordt de (te) scheve machtsbalans gecorrigeerd.

Mijn persoonlijke mening is dat de telecomsector, IT-dienstverleners en andere bedrijven op architectureel niveau aandacht zouden moeten hebben voor deze materie. [Je vraagt je altijd af of op dat niveau reeds druk wordt uitgeoefend vanuit inlichtingendiensten; zie in dat kader het verhaal over Room 641A bij AT&T.]

In reactie op een van je vragen: uitgaande mail wordt anno 2014 nog steeds dikwijls niet met TLS beveiligd tijdens transport. En als het *wel* beveiligd is, gaat het vaak alleen om de eerste link: de verbinding tussen jouw computer en de SMTP-server die je gebruikt voor het verzenden. De verbindingen tussen die SMTP-server en andere SMTP-servers in het pad naar de ontvanger zijn te vaak niet beveiligd.

Ik ben skeptisch over alles dat met clouds te maken heeft. In veel gevallen lijkt de houding niet veel anders dan “gooi maar over de schutting en het zit wel goed”. Er is sprake van een single-point-of-failure, en aanbieders bieden vaak geen of weinig garanties t.a.v. bescherming en beschikbaarheid van gebruikersdata. Ook op clouds kunnen gegevens ontoegankelijk raken.

Er is geen eenvoudig antwoord of turn-key-solution, omdat alles afhangt van de vraag wat er precies beschermd moet worden en tegen welke bedreiging, en zelfs als dat duidelijk is, blijft het complex. Je zou de situatie daartoe uit kunnen denken in attack trees en gebruikmaken van threat modeling en de optionele Windows-tooling.

Het klopt absoluut dat versleutelingssoftware achterdeurtjes kan bevatten. Het is schier onmogelijk om te bewijzen dat er geen achterdeurtjes zijn. En als die er in het origineel niet zijn, kunnen vervalste versies van de software worden verspreid die *wel* een achterdeurtje bevatten. Zie bijvoorbeeld het verhaal over een valse versie van de Tor-software voor geanonimiseerd browsen.

Ik kan geen specifieke pakketten aanraden, maar mijn voorkeur gaat uit naar open source software. Die kan net zo kwetsbaar zijn als gesloten software, maar iedereen die dat kan en wil, kan precies nagaan wat de software doet en verbeteringen aanbrengen.

Nogmaals: er is geen eenvoudig antwoord of turn-key-solution.

Addendum: TLS is natuurlijk geen panacee. Het is niet uitgesloten dat de Joint Sigint Cyber Unit (JSCU) certificaten van willekeurige domeinen kan (laten) ondertekenen door één van de sub-CA’s van de Staat der Nederlanden Root CA (of een andere CA, want SdN valt allicht te veel op). Dan kan met TLS-intercepting proxy’s, al dan niet in combinatie met QUANTUM-achtige methoden (DNS-injectie, HTTP-injectie), de inhoud van communicatie alsnog worden geïntercepteerd, afhankelijk van welke toegang de diensten hebben tot de netwerken van ISP’s en IT-dienstverleners. Maar actieve manipulatie van internetverkeer is complexer en risicovoller dan passief luisteren, en zal minder waarschijnlijk (grootschalig) ongericht worden ingezet. Hoewel we niet moeten vergeten dat de ongericht onderschepte niet-kabelgebonden communicatie op trefwoorden mag en wordt doorzocht; die behoefte zal er ook zijn voor kabelgebonden communicatie. Certificate pinning en DNS-based Authentication of Named Entities (DANE) werpen nieuwe drempels op, en met SSL Observatory-methoden zouden veranderingen in aangeboden TLS-certificaten kunnen worden gedetecteerd.

Om verdere drempels op te werpen is het van belang dat privacy en veiligheid serieus worden meegenomen tijdens de ontwikkeling van nieuwe IETF-internetstandaarden. RFC 7258 (mei 2014) en de initiatieven van o.a. Barnes et al. (juli 2014) en Dukhovni (augustus 2014) zijn stappen in de goede richting.

En ja, gezien alle complexiteit zullen we tot op zekere hoogte simpelweg moeten hopen dat de protocollen geen ernstige ontwerpfouten blijken te bevatten en dat ze veilig worden geïmplementeerd, dus niet zoals OpenSSL of software die servercertificaten niet goed valideert. En dat er geen al te grote onbekende doorbraken zijn/komen in cryptoanalyse. En ja, er zijn veiligere besturingssystemen nodig: zie het pragmatische multi-VM-model van Qubes OS en de meer fundamentele aanpak van microkernel-modellen zoals seL4 (tegenwoordig open source) en de kernel van MINIX 3. En ja, we willen ook hardware zonder achterdeurtjes, dat de gyroscoop op onze smartphone niet stiekem als always-on microfoon kan worden gebruikt, dat onze apparaten niet verbinden met valse WiFi-hotspots of valse GSM/CDMA2000/UMTS/LTE-basisstations (die ook al niet meer aan overheden zijn voorbehouden: bij DefCon 2010 demonstreerde Chris Paget een IMSI-catcher voor 2G op basis van een USRP; in 2013 demonstreerde iSec de interceptie van GSM-gesprekken en sms-berichten via geherprogrammeerde Verizon network extenders; en dan is er nog OpenBTS), en dat ook de firmware geen kwetsbaarheden bevat. En dan is er nog de mens.

EOF