Mag een maildienst met encryptie onkraakbaar zijn?

pgp-bericht-encryptie-versleutelingMet de dienst Startmail kunnen mensen versleuteld met elkaar mailen, ook als ze geen eigen encryptiesoftware (PGP) hebben. Dat las ik bij Tweakers. Heel mooi, maar PGP is erg sterke encryptie dus ga je je afvragen, hoe zit dat met opsporingsdiensten? Wanneer mag Justitie bij versleutelde mail opgeslagen bij een provider?

Op grond van artikel 125k Strafvordering kan een officier van justitie bij opsporing het bevel geven dat zaken moeten worden ontsleuteld. Het moet wel gaan om een ernstig misdrijf (art. 67 Rechtsvordering).

Het bevel mag aan bijna iedereen worden gericht:

… degeen van wie redelijkerwijs kan worden vermoed dat hij kennis draagt van de wijze van beveiliging van een geautomatiseerd werk, het bevel worden gericht toegang te verschaffen tot de aanwezige geautomatiseerde werken of delen daarvan. Het bevel richt zich tot degeen van wie redelijkerwijs kan worden vermoed dat hij kennis draagt van de wijze van versleuteling van deze gegevens.

De enige uitzondering is – niet verrassend – de verdachte zelf. Deze is immers niet verplicht aan zijn eigen veroordeling mee te werken.

Een tussenpersoon als Startmail is zelf geen verdachte en moet dus meewerken aan een bevel als aan de voorwaarden uit de wet is voldaan. En in theorie kunnen ze dat, ik lees bij Tweakers dat Startmail berichten op de server versleutelt en dat daar de privésleutel van de gebruiker is opgeslagen. Het is voor mij juridisch simpel: kún je erbij dan móet je erbij als dat wordt bevolen.

Liever had ik gezien dat de dienst GPG of PGP op de clientside inzet, zodat ze geen sleutels om mee te ontsleutelen hebben. Maar Startmail meldt in haar whitepaper (p5 en 6) een aantal stevige redenen om wél serverside te versleutelen. Kort gezegd: dat moet je niet willen als de client side omgeving een browser met Javascript is. En daar zit ook weer wat in.

Arnoud

24 reacties

  1. Het is natuurlijk ook mogelijk om de sleutel in twee of meer delen op te splitsen, waarbij beide delen nodig zijn om de decryptie functie uit te voeren. Een deel op de server (want kennelijk nodig voor veiligheid) een een deel op de client (voor bescherming tegen de dienstverlener en andere email-meelezers).

    1. In principe kan dat makkelijker: versleutel de geheime sleutel zelf weer met een wachtwoord. Op die manier kun je de geheime sleutel op zich opslaan, terwijl je er pas iets mee kunt zodra je ook het wachtwoord hebt.

      Echter, op het moment dat je 2e deel (of wachtwoord dus) aan de server wordt gegeven, moet je maar vertrouwen dat die server ‘m niet opslaat voor hergebruik. Daarom is end-to-end erop gebaseerd dat je NOOIT je geheime sleutel aan een ander systeem geeft, alleen de eindstations mogen ‘m hebben.

      End-to-end encryption is absoluut noodzakelijk om echt veilig te communiceren, en intrinsiek incompatible met het concept van clouddiensten die moeten werken in willekeurige domme browsers. Je zult voor goede versleuteling clientsoftware moeten hebben die je kunt vertrouwen.

      Arnoud, hoe zit het met dat “als het kan, dan moet het”-argument, als je nog niet de hele private key in handen hebt (bijvoorbeeld omdat die nog met een passphrase is versleuteld), maar die wel gemakkelijk kunt krijgen (door die op te slaan bij het eerstvolgende gebruik)?

      1. Wat niet kan, dat hoeft niet. Er is geen plicht om een constructie te bouwen waarmee in de toekomst een encryptie ontsleuteld kan worden. Men zou je soms wel kunnen verplichten data te tappen en te bewaren voor Justitie, en zo’n bevel kan dan specifiek toezien op de datastroom waarin de sleutel te verwachten is. Maar dan moet Fox-IT, pardon Justitie, vervolgens gaan snuffelen naar die sleutel en de decryptie toepassen. Wel met jouw input: datzelfde artikel verplicht je informatie over de beveiliging te geven als daar een geldig bevel toe is.

  2. Hoe lang hebben we die 125k Strafvordering al? Ik ben er helemaal niet blij mee: ik heb veel liever een universeel onschendbaar briefgeheim.

    Hoe werkt dat verschil tussen verdachten en anderen precies? Kan de politie eerst van jou eisen dat je communicatie ontsleuteld wordt, en je daarna pas als verdachte aanmerken?

    Is het niet mogelijk bij zo’n mail-service dat de gebruiker zijn public key aan de mail-server geeft, waarna de mail-server alle binnenkomende e-mail versleuteld opslaat? De mail-server kan de e-mail dan niet ontsleutelen. Je kunt dan natuurlijk geen webmail meer aanbieden (tenzij met ontsleuteling in Javascript), maar dat is iets waar de gebruiker dan voor kiest.

    Het lijkt me nog steeds niet een ideale oplossing: echt goede encryptie doe je end-to-end; een tussenpersoon zoals de mail-host zou geen toegang moeten hebben tot de niet-versleutelde tekst. Idealiter maak je gebruik van zoiets als Bitmessage, waarbij zelfs de meta-data (wie mailt met wie) verborgen blijft.

    1. Wat altijd een nadeel is van e-mail, is dat zowel de verdachte als de ontvanger een kopie van de mail hebben. Dus zelfs als de mailprovider de mail niet kan ontcijferen, dan kan de ontvanger dit nog wel. Ik weet niet of Justitie mag eisen dat de ontvanger de ontcijferde mails moet aanleveren, maar die heeft in ieder geval niet de plicht om deze voor een bepaalde tijd te bewaren, en de provider wel.

    2. ik heb veel liever een universeel onschendbaar briefgeheim.

      Briefgeheim kon je ook altijd al overrulen met bijvoorbeeld en gerechtelijk bevel. Waarom zou het trouwens niet wenselijk zijn om mbv een dergelijk middel zware misdrijven proberen op te lossen. En bij voorbaat zeg ik dan al vast maar dat ALLE opsporingshandelingen van politie en justitie altijd voor iemand een negatief effect hebben voor de privacy. Misdaadopsporing zonder privacy inbreuk is onmogelijk.

      1. Misdaadopsporing zonder privacy inbreuk is onmogelijk.

        Misschien.

        Ik heb het liefst dat misdaadopsporing is gebaseerd op informatie die al openbaar is, en op informatie die vrijwillig en/of per ongeluk wordt verspreid. Bijvoorbeeld: overvaller laat per ongeluk zien dat hij een bepaald T-shirt aan heeft; getuige meldt dit vrijwillig aan de politie.

        Er hoeft wat mij betreft geen waterdichte bescherming van misdadigers tegen de politie te zijn, maar zelfverdediging en verdediging van anderen moet altijd toegestaan zijn, zelfs als dat zeer effectieve verdediging is.

        Zolang de politie niet bezig is om de hele bevolking te monitoren, maar al hun inspanning richt op het oplossen van misdaden, en gewoon wacht tot een misdadiger een keer een fout maakt, dan kunnen ze, met een boel werk, veel misdadigers wel opsporen.

        Het is wel de bedoeling dat het een boel werk blijft: dat houdt de politie gefocust op de echte misdadigers, zodat de gewone bevolking buiten schot blijft.

  3. Beetje jammer die framing van JavaScript. Het is ontworpen om makkelijk in te kunnen stappen, maar dat betekent niet dat je altijd volgens die methode hoeft te blijven programmeren. Cryptocat is in JavaScript geschreven en wordt toch gezien als een vrij goede en veilige tool. Ik zal het paper eens doornemen of ze ook uitgebreider op de problemen van JavaScript ingaan want als dit hun enige argument is zou ik in dat startmail niet zoveel vertrouwen hebben.

    1. Misschien is het ook niet zozeer wantrouwen in JavaScript zelf, als meer wantrouwen in de veiligheid van de clientkant überhaupt. Een client heeft veel meer aanvalsvectoren dan de servers van Startmail. Aan de andere kant, als die gekraakt is dan maakt het niet meer uit waar de encryptie/decryptie plaatsvind omdat je dan toch ook toegang hebt tot de plaintext mail. Het grote voordeel van client-side is natuurlijk dat de mail zelf nooit plaintext over de lijn hoeft, wat MITM aanvallen een stuk moeilijker maakt. En als Startmail een goed PGP script schrijft en deze over een veilig kanaal bij de client krijgt, is dat minstens zo veilig.

      Apple had haar crypto ook aangepast zodat ze zelf geen keys meer hebben om te decrypten, waarop de FBI natuurlijk gelijk moord en brand begon te roepen: Beefed-Up iPhone Crypto “Will Lead to a Child Dying”, DOJ Warned Apple Execs

  4. Cryptocat is een browser extensie, en dat maakt dat een groot deel van de argumenten tegen JavaScript teniet wordt gedaan. Alleen voor webmail is een browser extensie weer niet praktisch, want dan kun je op vakantie nog steeds niet bij je mail.

    StartMail schrijft in hun whitepaper dat ze wachten tot het software-landschap voldoende is ontwikkeld om crypto in de browser te kunnen doen. Daaruit mag je concluderen dat ze zelf niet de benodigde capaciteit hebben om een veilige browser extensie te ontwikkelen (wat ook in C(++) zou kunnen en niet perse in “onveilig” JavaScript).

  5. Ik vind het interessanter worden voor gebruikers met een eigen domeinnaam, die daarbij zelf een server opzetten als email-host. Dit zou prima kunnen in een virtuele machine onder Microsoft Azure of zo. De software voor deze mail-host zou daarbij een zeer sterke encryptie toe kunnen passen en zware beperkingen kunnen opleggen betreffende de client applicatie die ermee kan communiceren. Je hebt dan nog steeds een mailhost (Azure) maar men kan niet de inhoud van de emails bekijken. Daarvoor moet je dan weer de client applicatie hebben met alle extra toeters en bellen erbij die de boel beveiligen. En als de software een self-destruct functie kent kan het nog wel eens een stuk lastiger worden. (Plus, men moet bij Microsoft om de virtuele machine vragen, wat ook enigszins lastig is.) Maar goed, niets is onkraakbaar. Het probleem is alleen dat het kraken van sommige zaken gewoon enorm veel tijd en energie kost waardoor het niet de moeite waard wordt.

    1. (Plus, men moet bij Microsoft om de virtuele machine vragen, wat ook enigszins lastig is.)

      Bij tilaa.com is dat helemaal niet lastig, maar een kwestie van 5 minuten en nog geen tientje per maand. Plus, het zit in Nederland, dus niks te maken met de Amerikaanse overheid.

      Ik heb er mijn eigen mailserver maar encryptie hoeft voor mij niet want zo geheim is het allemaal niet. Ik heb al zo’n 20 jaar een publieke PGP-sleutel op mijn site vermeld staan en daar heeft NOG NOOIT iemand gebruik van gemaakt. Ook geen klanten die wel zeggen te hechten aan geheimhouding. Dus wat nou geheime e-email?

      1. Tja, ik gebruik Google Apps, aangezien geen van mijn emails echt boeiend zijn. De 250+ emails per dag worden dankzij Google netjes gefilterd en ontspamt en wat interessant is, lees ik. Wat ik stiekem wil doen, doe ik gewoon niet online. 🙂 Dat het onder de Amerikaanse overheid valt is een voordeeltje. Jouw email wordt dan een internationale kwestie omdat justitie in Nederland niet bij jouw mailbox komt zonder de hulp van Microsoft en de server in de USA staat. Dat vormt een juridische uitdaging. En justitie in de USA heeft ook een probleem want ze kunnen misschien wel bij de machine, maar hebben geen toegang tot de decryptie-app op je eigen PC. En dus ook niet tot de private key. Binnenkomende emails worden op de server namelijk encrypted met je public key en dan komen ze er niet meer bij. Dan moeten ze weer in Nederland jouw PC zien te verkrijgen.

        1. Bedrijven als Google en Microsoft zullen niet meewerken met een verzoek van een officier van justitie als dat niet hoeft maar een gerechtelijk bevel van een Nederlandse rechter tav van een Nederlandse burger en die emails komen zo binnenrollen (ook vanaf amerikaanse servers)

  6. Voor een dergelijke dienst om immun te zijn voor rechterlijke bevelen, is het essentieel dat de privesleutels niet op de servers van de provider belanden. Dat kan alleen als de versleuteling client side plaatsvindt, en sterker, dat de software die die versleuteling uitvoert niet onder controle staat van de aanbieder van de dienst (anders is het een fluitje van een cent om een bevel te geven die software aan te passen, zodat hij toch de privesleutels naar de server lekt, en, oh ja, de dienstverlener mag daar verder niets over zeggen. Lijkt mij een vrijwel onoverkoombare horde voor web-based email. Conclusie, je zult, om je tegen overheidsinstanties te beveiligen toch zelf wat meer moeite moeten doen, en zeker niet op willekeurige machines op de browser vertrouwen.

    Als je slechts een paar korte mededelingen wilt doen, en ze ruim van te voren kunt afspreken, dan werkt het ouderwetse codewoord natuurlijk nog altijd prima: staat er “aardappels” in mijn mailtje, en ergens anders een datum, dan is dat het signaal dat ik op die datum op de Van Goch straat op je wacht…. en schrijf je daarna een onschuldig keuvelend briefje over wat je die avond allemaal gaat eten.

  7. Client-side is helaas ook lek, zelfs met de laatste web crypto api. Zelfs als de sleutels afgesloten blijven can de provider door van de javascript het systeem altijd not als ontsleutelingsorakel gebruiken. Wellict is het mogelijk om de standaard zo om te schrijven dat door een sandbox de informatie niet naar de server kan. Om dat te doen zonder informatieverlies maar met gebruikersvriendelijke applicatie is zeer complex.

    1. Kun je je argument misschien wat verder uitweiden, of misschien wat bronnen linken? Ik zeg niet dat het niet zo is, maar je maakt een statement zonder dit verder te ondersteunen met relevante links. Volgens mij is het prima mogelijk om een veilige implementatie van PGP in javascript te bouwen. Er is niets inherent aan de taal ‘javascript’ waardoor dit niet zou kunnen. De implementatie in de browser kunnen buggy en onveilig zijn, maar dat heeft met de taal zelf niet zoveel te maken.

      1. Volgens mij is het prima mogelijk om een veilige implementatie van PGP in javascript te bouwen
        Probleem is alleen dat de provider die de javascript aanlevert de code ook zou kunnen aanpassen (op bevel van en rechter) om bijvoorbeeld iemands lokale sleutel niet alleen te gebruiken voor decryptie maar die te stelen en door te geven aan de server war de politie die in beslag kan nemen. Javascript kan in principe wel veilig encrypten maar je kunt niet zeker zijn dat die scriptcode altijd veilig blijft en niet op 1 of ander manier gecompromitteerd kan raken.

        1. Goed punt. Dit geldt natuurlijk in principe ook voor gewone software (TrueCrypt). Al zijn er meerdere PGP implementaties, dus het zal wel een stuk lastiger tot onmogelijk zijn om net die software die de verdachte gebruikt aan te laten passen, de verdachte te dwingen om een update te doen, en dan je slag te slaan.

  8. @Arnoud:

    Op grond van artikel 125k Strafvordering kan een officier van justitie bij opsporing het bevel geven dat zaken moeten worden ontsleuteld. Het moet wel gaan om een ernstig misdrijf (art. 67 Rechtsvordering).
    Dit lijkt me niet juist. Art. 67 Sv gaat over wanneer een bevel tot voorlopige hechtenis mag worden gegeven, niet over wanneer een bevel tot ontsleuteling mag worden gegeven.

    1. Het klopt volgens mij wel. Art 67 Strafvordering (niet rechtsvordering) bepaalt kort gezegd wanneer we misdrijven ‘ernstig’ vinden. Dat wordt vaak als criterium gebruikt om te bepalen of bepaalde bevelen of middelen mogen worden ingezet. Het bevel tot ontsleutelen mag dan niet zomaar bij elk misdrijf worden gegeven, maar dit vereist een misdrijf genoemd in artikel 67.

  9. Ik zie dat er inderdaad vaak in andere artikelen naar artikel 67 Sv eerste lid verwezen wordt. Onder andere in de artikelen 96b, 96c, eerste, tweede en derde lid, 97, eerste tot en met vierde lid, die in artikel 125i genoemd worden, waarnaar verwezen wordt in 125k (ontsleuteling). Deze artikelen gaan over doorzoekingen ter inbeslagname door opsporingsambtenaren en de OvJ.

    Maar: • in die artikelen 96b, 96c, eerste, tweede en derde lid, 97, eerste tot en met vierde lid, wordt behalve in geval van verdenking van een ernstig feit zoals beschreven in 67 ook ontdekking op heterdaad genoemd. • in artikel 125i wordt ook artikel 110, eerste en tweede lid genoemd. Deze geeft de rechter-commissaris de bevoegdheid om bij onderzoekshandelingen een doorzoeking ter inbeslagneming uit te voeren, ook bij niet-ernstige feiten.

    Als ik het goed begrijp zou een bevel tot ontsleuteling (aan een ander dan de verdachte) in deze gevallen dus ook mogelijk zijn. Het eisen tot ontsleuteling zou dan grofweg mogelijk zijn bij iedere doorzoeking ter vastlegging van gegevens, wat min of meer mogelijk is wanneer een doorzoeking ter inbeslagneming mogelijk is.

    Samengevat: 125k: bevel tot ontsleuteling mag bij doorzoeking ter vastlegging van gegevens (125i). 125i: doorzoeking ter vastlegging van gegevens mag onder dezelfde voorwaarden als een doorzoeking ter inbeslagneming (96b, 96c (1e, 2e, 3e lid), 97 (1e t/m 4e lid), en 110 (1e en 2e lid)). 96b, 96c (1e, 2e, 3e lid), 97 (1e t/m 4e lid): doorzoeking (van bepaalde plaatsen) mag (onder bepaalde voorwaarden) door opsporingsambtenaar of OvJ bij ernstige feiten of heterdaad. 110 (1e en 2e lid): doorzoeking mag (onder bepaalde voorwaarden) door rechter-commissaris.

    Voor zover ik het als niet-jurist begrijp.

Geef een reactie

Handige HTML: <a href=""> voor hyperlinks, <blockquote> om te citeren, <UL>/<OL> voor lijsten, en <em> en <strong> voor italics en vet.