Australisch parlement stemt in met omstreden ‘anti-encryptiewet’

De Australische senaat heeft donderdag ingestemd met de omstreden wet die techbedrijven zoals Apple en Facebook verplicht om mee te werken bij het ongedaan maken van encryptie bij het onderscheppen van communicatie. Dat meldde Tweakers vorige week. De wet is omstreden omdat in het Angelsaksische rechtsgebied het doorbreken van encryptie door opsporingsdiensten als controversieel geldt, en deze wet de primeur heeft aldaar die er ook nog eens met trucjes doorgeduwd werd. Toch is het bepaald niet de “encryptie is nu verboden!!1!” wet die het in sommige media genoemd wordt. De regels over encryptie zijn volgens mij minder streng dan in Nederland.

De omstreden Assistance and Access-wet heeft inderdaad als gesteld doel bevoegdheden van politie en andere opsporingsdiensten te vergroten om het probleem van alomtegenwoordige encryptie op te kunnen lossen. Criminelen gebruiken encryptie om hun daden te verhullen, is dan het argument, dus moeten de diensten bij die versleutelde berichten kunnen in het belang van het onderzoek.

Een kernaspect van de wet is dan ook dat opsporingsdiensten zogeheten “technical assistance notices” en “technical capability notices” mogen sturen. Dat zijn bevelen om bepaalde technische ondersteuning te geven (assistance) maar ook om mogelijkheden in te bouwen (capability) om daarmee in de toekomst meer ondersteuning te realiseren. Dus “geef me de mailbox van Jan” is een assistance notice, maar “bouw iets in dat ik live mails van en naar Jan kan zien” is een capability notice. Met name die laatste is natuurlijk behoorlijk vérgaand, ook omdat je het gratis moet opvolgen.

Wat encryptie betreft is wel weer opgenomen dat zo’n notice niet mag leiden tot structurele verzwakking van encryptie of authenticatie. Een notice mag dus denk ik wel eisen dat een specifiek bericht wordt opengemaakt, maar niet dat standaard een achterdeur wordt ingebouwd.

Een specifiek bericht decrypten is dus een van de nieuwe bevoegdheden. In Nederland is dat helemaal niet zo nieuw, ons wetboek van strafvordering vermeldt onder meer in artikel 125k:

[Een bevel tot toegang tot gegevens kan worden gegeven in het belang van het onderzoek] indien in een geautomatiseerd werk versleutelde gegevens worden aangetroffen. Het bevel richt zich tot degeen van wie redelijkerwijs kan worden vermoed dat hij kennis draagt van de wijze van versleuteling van deze gegevens.

Dit vereist wel dat een verdenking bestaat van een ernstig misdrijf (minstens vier jaar cel, en enkele specifieke strafbare feiten zoals mensenhandel). Het bevel mag overigens niet aan de verdachte worden gegeven (dit staat ter discussie)

Als het gaat om een onderzoek door een toezichthouder, dan gaat de wet nog verder. Artikel 5:20 Awb:

Een ieder is verplicht aan een toezichthouder binnen de door hem gestelde redelijke termijn alle medewerking te verlenen die deze redelijkerwijs kan vorderen bij de uitoefening van zijn bevoegdheden.

Hieronder valt dus ook het ongedaan maken van encryptie. De letter van de wet sluit echter zelfs niet uit dat je dingen gaat bouwen om meer structureel bij bepaalde gegevens te kunnen, maar het zou wel een gedurfde* inzet van bevoegdheden zijn om dit te vorderen.

In de praktijk hebben vrijwel alle grotere bedrijven achterdeuren in hun encryptie-infrastructuur. Dat moet ook wel, want als een sleutelhouder ontslag neemt of overlijdt dan wil je als bedrijf door kunnen. Het openen van versleutelde berichten is dus altijd technisch mogelijk. En als dat zo is, dan mag bijvoorbeeld markttoezichthouder ACM vorderen dat dit gebeurt omdat zij een bestuursrechtelijke overtreding vermoeden.

Arnoud<br/> *Gedurfd besluit: een politiek besluit waarmee je de verkiezingen verliest. Yes, minister

18 reacties

  1. Het bevel richt zich tot degeen van wie redelijkerwijs kan worden vermoed dat hij kennis draagt van de wijze van versleuteling van deze gegevens.

    Een van de kenmerken van een goede versleuteling is dat kennis van de wijze van versleuteling niet bijdraagt tot het kunnen ontcijferen van een versleuteld bericht. En als je gebruik maakt van asymmetrische versleuteling (PGP of GPG) heb je er zelfs niets aan als je weet welke sleutel is gebruikt om het bericht te versleutelen.

  2. Arnoud, Goed de nuance te zoeken, maar m.i. blijft het een forse en fundamenteel heel foute ingreep. Per saldo zijn er 3 mogelijkheden: 1) de encryptie moet zo zwak zijn dat de leverancier of de dienst die kan kraken. 2) de private key is niet echt private, want de uitgever behoudt een kopietje 3) er is en backdoor, de befaamde TSA sleutel. In alle 3 gevallen zijn we met z’n allen veel slechter af: je kunt er niet langer op vertrouwen dat je versleuteling veilig en prive is, en wie er nog meer allemaal in je berichten kan meekijken. Bovendien lijkt het me erg lastig voor een bedrijf dat geen van 3-en wil doen. “Je moet me helpen dit bericht te openen”. “, ja maar dat kan ik technisch niet:”, “Oh, dan heb je een probleem, obv van deze wet had je moeten weten dat je het het wel zou moeten kunnen”. Kortom, heel slechte zaak.

    1. optie 4: Client1 encrypt bericht met de public key van de server, client1 stuur het encrypte bericht naar de server,de server decrypt het bericht, de server encrypt het bericht met de public key van client2, de server stuurt dat encrypte bericht naar client2.

  3. Omdat vrijwel niemand in staat is de kracht en gebreken van een versleutelingssysteem in te schatten, is vertrouwen in de leverancier van dergelijke systemen essentieel. Zo zal een bank geen transacties van potentieel vele honderden miljoenen euros achter een beveiliging stoppen als zij ook maar het vermoeden heeft dat elke willekeurige (potentieel corrupte) ambtenaar een leverancier kan dwingen een achterdeurtje in mijn systemen te bouwen, zelfs, of juist, als dat achterdeurtje specifiek op mijn systeem is gericht. Dit is precies de hele discussie omtrent Huawei (en Cisco in het verleden, waar de NSA inderdaad spionageapparatuur in routers heeft geplaatst — zoals de waard is vertrouwt hij zijn gasten).

    Vertrouwen is een paardendief: het komt te voet en gaat te paard. Om in een context waar dit vertrouwen zo belangrijk is met dergelijke wetgeving te komen is uiterst dom, en zal gecompenseerd moeten worden met maatregelen dergelijke ingrepen te voorkomen. Dit betekend dat nog meer dan in het verleden, alle beveiligings- en versleutelingssoftware open source zal moeten zijn, zodat iedereen kan zien wat er in de software zit, en hoe en wanneer de wordt aangepast. Elke verandering zal publiekelijk moeten worden uitgelegd, en aan de tand moeten worden gevoeld door experts. Binaries die gemaakt worden zullen controleerbaar afgeleid moeten zijn van de open source code (“reproducable builds”). Dit gaat veel verder dan de ietwat futiele “warrant canaries” die je nu wel eens ziet.

    Een ander zwak punt is het mechanisme van automatische updates. Nu wordt zo’n update uitgerold met een digitale handtekening van de producent. Dat is in de huidige juridische context niet meer voldoende. Nu zal een dergelijke update ondertekend moeten worden door een groep van onafhankelijke auditors in verschillende jurisdicties, liefst in jurisdicties die elkaar niet al te veel vertrouwen, en cryptografisch worden gekoppeld aan de gepubliceerde broncode, zodat een enkele partij nooit op eigen houtje aanpassingen kan maken in de beveiliging.

    Tenslotte zullen leveranciers van dergelijke systemen een zeer significant belang moeten hebben bij het niet breken van hun software. Net als bij DigiNotar moet het niet werken van de dienst of software het onvermijdelijke faillissement betekenen. Het hele bestaan van een beveiligingsbedrijf moet gekoppeld zijn aan dat niemand hun systeem kan breken, zelfs zij zelf niet, zelfs als de dat willen, zelfs als ze dat willen met de dreiging van een levenslange gevangenisstraf als stok achter de deur.

    Tenslotte, veel techneuten zien ondermijnende wetgeving als een bug in hun software, en zullen de software dus aanpassen om de bug op te lossen, vaak zolang er klanten zijn die hiervoor kunnen en willen betalen, maar vaak ook uit idealisme.

  4. In de praktijk hebben vrijwel alle grotere bedrijven achterdeuren in hun encryptie-infrastructuur. Dat moet ook wel, want als een sleutelhouder ontslag neemt of overlijdt dan wil je als bedrijf door kunnen. Het openen van versleutelde berichten is dus altijd technisch mogelijk.

    Ik denk dat je hierbij wel 2 verschillende zaken moet onderscheiden. Enerzijds is er de versleuteling van de data van ‘het product’, bijvoorbeeld de (end to end encrypted) berichten van whatsapp, of je apple mail. Ik geloof niet dat hier per definitie een backdoor in zit om het weer te kunnen ontsleutelen. Als het bedrijf een wachtwoordreset functie inbouwt is de kans dat het degelijk ge-encrypt is al weer kleiner, maar dat kan eventueel ook opgelost worden met een recovery token oid die als 2e decryptiesleutel is ingesteld.

    Vervolgens heb je de wachtwoorden die een bedrijf intern gebruikt, bijvoorbeeld het rootwachtwoord van een server. Ook die hoeft niet per se met een backdoor opgeslagen te worden ,als er maar meerdere beheeraccounts zijn die er bij kunnen. Komt Pietje onder een bus terecht, dan kunnen de keys van Keesje en Jantje ook nog gebruikt worden om de wachtwoorden te ontsleutelen. Wel is het dan natuurlijk zo dat inderdaad in de praktijk er ook nog een 4e key in de kluis ligt, just in case…

    1. Neem Skype als voorbeeld.

      Skype was p2p met e2e encryption. Na de overname door Microsoft is Skype aangepast, alle verbindingen lopen via MS. Jij kan in de client niet zien of je encrypt met de public key van je communicatie partner of met die van MS en zij als MitM de boel decrypten en weer encrypten met de sleutel van je gesprekspartner.

      Skype encryptie kan je dus per definitie niet vertrouwen als MS actief blijft in Australie (zo je dat nu al kan, de Amerikaanse overheid vertrouw ik wat dat betreft ook niet). Het is voor hun namelijk doodsimpel om aan een overheidsverzoek te voldoen. Skype is pas veilig als een functie ingebouwd wordt waarmee je de public key van gesprekspartners zelf kan controleren en bij een gesprek kan controleren of deze wel gebruikt wordt.

      Zoals bijvoorbeeld bij het WASTE netwerk indertijd. Om daar op aan te sluiten moest je jouw public key expliciet delen met anderen in het netwerk die je direct toegang tot jouw data wil geven. MitM is niet mogelijk omdat de client dan bij het opzetten van de verbinding de key niet meer herkent.

  5. Misschien kan bijvoorbeeld whatsapp encyptie via de app wel uitzetten (of vervangen door een encyptie waar de politie een key voor krijgt voor bepaalde accounts op verzoek van de wetgevers. Mensen denken dat een app hun data encypt en dat de data dan veilig is maar apps worden door leveranciers beheerd en daar zit wel een zwakte. Die hoeft dus niet in de encryptie te zitten.

    1. Helemaal mee eens. Er zullen bedrijven zijn die dan de encryptiesleutel in een TPM-chip opslaan, zodat ook zij de key niet uit kunnen lezen. Op die manier zijn berichten niet met terugwerkende kracht uit te lezen. Maar ook dan kan een leverancier natuurlijk alsnog ‘compelled’ worden om een extra key aan die TPM toe te voegen waarvan ook zij de encryptiesleutel hebben.

      Zonder de Richard Stallman uit te willen hangen is hier dan ook wat mij betreft een grote rol weggelegd voor Open Source. Niet dat iedereen continue alle broncode gaat auditten, maar een if’je met if($uid == ‘Pietje’) { addExtraEcnryptionKey($keyBckDr); } valt toch een keer iemand op zou je denken.

    2. En als ze het niet kunnen kunnen ze een versie pushen door de stores die incompatible is met de vorige die het wel kan. Net als bijna alle updates een omschrijving ‘various bug fixes’ meegeven en Bob’s your uncle.

      Stores en automatische updates zijn voor encryptie software niet te vertrouwen. Ironisch genoeg betekent dat dus dat een iPhone niet veilig genoemnd kan worden, met de walled garden van Apple. Android wel omdat je zelf de controle hebt over updates voor sideloaded apps.

      En eigenlijk zou al die software een plugin API voor encryptie moeten aanbieden met een open source voor ‘iedereeen’ te controleren plugin. Dan haal je de encryptie uit handen van degene die het netwerk en opzetten van de verbinding beheert en kan een dergelijk verzoek alleen nog maar effectief worden gericht aan de partij die je wil afluisteren. Stiekem afluisteren is er niet mee bij zonder fysiek toegang tot of hacken van de computer/telefoon om de software ongezien te vervangen.

      tl;dr Encryptie en opbouwen en onderhouden verbinding mag niet door zelfde partij gedaan worden.

      1. Dat gaat je niet helpen als er encryptie tussen de eindpunten is die zelf de sleutels managen en jij geen eindpunt bent. Je kan niet geven wat je niet hebt.

        En wat betreft geheime verzoeken tot decryptie. Je kan makkelijk een sleutel in tweeën hakken en die in twee heel verschillende juridicties opslaan. Dan kan je heel leuk met een uitspraak van de rechter komen, maar om te voldoen heb je medewerking nodig vanuit een andere jurisdictie waar die opdracht tot geheimhouding waardeloos is.

        En je kan er vergif op innemen dat dit soort zaken gemeen goed gaan worden als de overheid met de botte bijl encryptie te lijf gaat. Ik wens ze veel succes met bij mijn e-mail provider eisen dat ze mijn e-mail verkeer leesbaar maken. Maar mijn vertrouwelijk inkomend zakelijk e-mail verkeer is alleen te decrypten met een sleutel die ik heb, zelfs mijn werkgever heeft die niet. Hoe de ontvangende partij met sleutels om gaat weet ik niet, ik hoop ook zorgvuldig. Dan nog zouden ze alleen toegang tot de communicatie met die partij hebben. En mijn privé e-mail wens ik ze veel plezier mee, daar staat echt niets interessants in.

        Chat doe ik met Signal, daar wens ik ze ook veel plezier met de poging om Signal te verplichten te helpen met decrypten.

        Het meest trieste van dit alles is dat je dit alles moet doen om een grijpgrage overheid uit je zaken te houden, dezelfde overheid die juist met wetten zou moeten faciliteren om grijpgrage mensen uit je data te houden.

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.