Internetrecht door Arnoud Engelfriet

Een lezer vroeg me:

Na Lektober zijn we bij ons op het werk vol op de beveiliging gesprongen. Alle bestanden met persoonsgegevens zijn opgeschoond en alle systemen zijn maximaal beveiligd. Volgens mij net iets té ver: ik mag onze software niet meer testen met ‘echte’ persoonsgegevens, alleen met een bestand met een paar honderd nepadressen. Dit omdat testen met persoonsgegevens verboden zou zijn onder de Wet bescherming persoonsgegevens. Is dat echt zo?

De Wet bescherming persoonsgegevens (Wbp) verbiedt niet letterlijk het testen met productiegegevens. Die zegt alleen dat je de gegevens mag gebruiken voor het doel waarvoor je ze krijgt, en voor doelen die in duidelijk direct verband daarmee staan (art. 8 en 9 Wbp). Het testen van de omgeving waarbinnen je persoonsgegevens wilt gaan gebruiken, lijkt mij zonder meer voldoende verband te hebben met het daadwerkelijk (productie) gebruik van die omgeving.

De norm “Achtergrondstudies en Verkenningen Nr. 23” van het Cbp is streng:

Voor het testen van informatiesystemen met persoonsgegevens mogen uitsluitend gegevens van fictieve personen gebruikt worden.

Deze norm is niet wettelijk bindend. Je moet deze norm zien als “zo doe je het goed” maar daaruit volgt niet “als je wat anders doet, zit je fout”. Als je wat anders doet, begeef je je in onontgonnen terrein. Dat mag, zolang je zelf dan maar uiterst goed oppast wat je doet. Een eigen norm daarvoor maken is geen slecht idee dan. Ik vond de Richtlijn gebruik productiegegevens uit alweer 2005 van het Bureau Keteninformatie Werk en Inkomen waar nuttige tips in staan.

Testen met echte persoonsgegevens moet wel nodig zijn, oftewel het gebruik van die testgegevens zou niet voldoende moeten zijn. Om bijvoorbeeld te kijken of de interface voor het oproepen van klantgegevens of bestellingen prettig werkt (een usabilitytest), kun je prima volstaan met fictieve gegevens. Een stresstest op de performance kan echter niet met honderd nepadressen als je in productie met honderdduizend echte adressen gaat werken.

Natuurlijk moet je altijd adequate beveiliging (art. 13 Wbp) hanteren, dus ook in je testomgeving. De testomgeving moet dus op dezelfde wijze zijn afgeschermd voor ongeautoriseerde toegang en gebruik. De personen die het systeem testen, moeten aan dezelfde geheimhouding en audits onderworpen zijn als de personen die het productiesysteem beheren. Dat wordt nog wel eens vergeten - men huurt een IT-er in om een databasekoppeling te bouwen en denkt dan niet dat daarbij geheimhouding nodig is. Maar als hij dan een test met productiegegevens gaat doen, is dat wel degelijk wettelijk verplicht.

Het is jammer dat sommige bedrijven zo doorslaan meteen: van totale laksheid naar OMGWTFWBP alles-verbieden-volstrekte-geheimhouding-niets-mag-meer. Even rustig ademhalen graag voor je zulke beleidsregels opstelt.

Arnoud

De Nederlandse politie heeft een cruciale rol gespeeld in het oprollen van een groot malafide DNS-netwerk, meldde Webwereld gisteren. RIPE verklaart een bevel te hebben gehad om van 8 november tot 22 maart volgend jaar deze DNS entriesIP-adressen niet te mogen wijzigen. Hiermee heeft het KLPD zo te lezen weer een botnet overgenomen, want Ronald Prins van Fox-IT meldt bij Webwereld: “De DNS-servers draaiden op bepaalde ip-adressen. Nu zijn die vervangen door servers van de politie zelf.”

In Nederland geldt de regel dat de politie alleen bevelen mag geven als die gebaseerd zijn op een bevoegdheid uit het wetboek van strafrecht. Men mag dus niet zomaar gegevens vorderen, vernietigen of aftappen. Voor elke vordering moet een grondslag aangewezen zijn, en natuurlijk moet aan de eisen uit de wet voldaan zijn. Vragen staat dus niet vrij voor de politie.

Wat is hier dan de wettelijke grondslag? Het KLPD is zeer creatief in het toepassen van de wet bij ICT-problemen. Op zich lovenswaardig, zolang ze maar binnen de wet blijven. En het zou leuk zijn als het KLPD in haar persberichten dan ook zou melden welk wetsartikel ze gebruiken. Nu moeten we maar raden wat het zou kunnen zijn.

Ik kan twee opties bedenken:

1. Artikel 126k: betreden van een besloten plaats om daar “sporen veilig te stellen”. In dit geval zijn de DNS entries dan de sporen, en het bevriezen door RIPE is een vorm van veiligstellen. Dat voelt niet helemaal kloppend, dit artikel is bedoeld om een plaats te betreden die met een misdrijf te maken heeft.
2. Artikel 126ni (ni!): het bewaren en beschikbaar houden van gegevens “waarvan redelijkerwijs kan worden aangenomen dat zij in het bijzonder vatbaar zijn voor verlies of wijziging”. DNS entries voldoen daar wel aan. Alleen, men mag ze hooguit 90 dagen bewaren en 8 november + 90 dagen is bij mij geen 22 maart. Verlengen is mogelijk, zo staat in het laatste lid, maar om nu meteen vanaf dag 1 er een verlenging tegenaan te gooien?

Eigenlijk zouden dit soort zaken eens moeten worden aangevochten bij de rechter, zodat we jurisprudentie krijgen over welke cyberbevoegdheden de politie heeft. Maar ja, een botnetbeheerder gaat echt niet naar Nederland komen om te procederen over artikel 126ni Wetboek van Strafrecht.

Arnoud

Op opensource.com vond ik (via) een mooi overzicht van gefaalde DRM systemen, van Realnetworks/Rhapsody tot Apple, Microsoft PlaysForSure en Nokia. Aanleiding was de aankondiging van Rhapsody dat iedereen voor 7 november zijn DRM-beveiligde muziek moet omzetten naar een ander formaat, omdat anders ze niet meer af te spelen zijn op die datum.

Het artikel laat de geschiedenis van DRM beginnen in 1998, toen de Digital Millennium Copyright Act werd aangenomen en het omzeilen of kraken van DRM verboden werd. Het idee van DRM is eigenlijk nog ouder dan dat, en niet alleen omdat de DMCA afkomstig is uit het WIPO Auteursrechtenverdrag uit 1996. In datzelfde jaar publiceerde Mark Stefik van Parc de paper Letting loose the light (PDF, 2,5MB) waarin hij het idee beschreef waar DRM op gebaseerd is. (Stefik was later oprichter van Intertrust, een firma die DRM technologie ontwikkelde. Intertrust werd in 2002 gekocht door Philips en ja ik werkte daar toen.)

Stefiks artikel was een reactie op John Perry Barlow die schreef dat door het eenvoudig en perfect kopiëren dat het internet mogelijk maakt, het idee van auteursrecht ondergraven wordt. Auteursrecht is gebaseerd op de aanname dat je werken per stuk kunt verkopen, en zo kunt afrekenen per stuk ook. Het elegante van dit systeem is dat het geen kwaliteitstoets nodig heeft, in tegenstelling tot systemen waarbij de overheid subsidie geeft aan bepaalde kunstenaars (wie kies je? welke werken koop je aan?) of waarbij je als maker een mecenas moet zoeken die je werk hopelijk leuk genoeg geeft. Met het auteursrecht in deze vorm beslist de markt. Als veel mensen je werk kopen, dan verdien je veel geld. Maak je werk waar niemand op zit te wachten, dan krijg je geen inkomsten en dan moet je maar wat anders gaan doen. Zo ontstaat er een markt voor werken waar iedere auteur/maker zich op kan begeven en via zijn auteursrecht kan proberen zijn of haar boterham te verdienen.

Die aanname komt echter flink onder druk wanneer iedereen onbeperkt kan kopiëren zonder enige kwaliteitsverlies. Je kunt werken wel “bottelen” zoals Barlow het noemt, maar alles loopt meteen weg door het elektronisch vergiet. Stefiks idee was dan ook om de onbeperkte waterval die het internet is, weer om te zetten in een grote verzameling flessen. Hij introduceerde daarvoor het concept van “trusted systems”, systemen die de regels gezet door auteursrechthebbenden netjes naleven en weigeren acties uit te voeren die niet gelicentieerd zijn. Met zulke systemen zou de elektronische handel in flessen, pardon werken op gang moeten komen. Je hoeft als auteur niet meer bang te zijn dat je werk wordt gekopieerd, en daarmee zou je de markt moeten willen betreden.

Het systeem werd ook wel superdistributie genoemd, want distributie en beschikbaarstellen stond centraal. Iedereen mocht werk kopiëren, graag zelfs. Alleen: wie het werk wilde gebruiken, moest gaan betalen. Stefik introduceerde daarvoor het concept van een rechtenbeschrijving, waarin de rechten zouden worden vastgelegd die je voor een werk kon kopen. Daarmee is in theorie een heel flexibel model mogelijk. Wil je heel weinig, bijvoorbeeld één keer kijken, dan betaal je weinig en het rechtensysteem zorgt ervoor dat je ook niet meer kunt dan dat. Wil je veel, bijvoorbeeld onbeperkt kijken én delen met vrienden, dan betaal je meer en dan wordt dat ook allemaal mogelijk. Wettelijke uitzonderingen zoals citaatrecht zouden kunnen worden voorgeprogrammeerd binnen zekere grenzen.

Helaas bleek de praktijk weerbarstig: de industrie zag dit model en paste het toe als “u mag heel weinig én u betaalt heel veel”. Geen enkel DRM-systeem op de markt heeft ooit de consument écht de mogelijkheid geboden flexibel rechten te kopen, of zelfs maar om meer te kopen dan een tijdelijk gebruiksrecht voor een lageresolutieversie op de PC.

In 1999 werd Napster opgericht. Deze bestandsdeeldienst had een goede positie om een DRM-achtige oplossing te introduceren. Haar centrale server maakte het mogelijk om alle uitwisseling in de gaten te houden, en dan af te rekenen en/of beperkingen te introduceren à la het systeem van Stefik. De muziekindustrie zag Napster echter als niets meer dan piraterij en procedeerde de club kapot.

In Nederland speelde iets later ongeveer hetzelfde bij Kazaa. Dit bedrijf was ook in de gelegenheid om te monitoren wat mensen up- en downloadden, en was bereid daar een vergoeding over af te dragen aan Buma/Stemra. Dit werd echter op het laatste moment onmogelijk gemaakt doordat Kazaa in de VS werd aangeklaagd. Juridische stappen tegen B/S leidden wel tot een Hoge Raad-arrest dat de software legaal was maar niet tot een gelegaliseerde uitwisselingsdienst.

Daarmee was eigenlijk de kans voor DRM binnen bestandsuitwisseling (filesharing) wel verkeken. Ontwikkelaars van nieuwe systemen richtten zich op het niet-aanpakbaar maken, bijvoorbeeld door centrale servers te dumpen zodat geen partij meer aan te klagen was. De Pirate Bay zette daarbij de toon. In reactie daarop begon de industrie steeds verder om zich heen te slaan en partijen aan te pakken die op indirecte wijze bij inbreuk betrokken waren. Bij ons heeft stichting Brein de afgelopen vijf, zes jaar een heel raamwerk van rechtspraak opgetuigd rond partijen die hyperlinks of andere informatie aanboden naar illegaal uitwisselen, en men is van plan ook door te pakken naar betaalsystemen en internetproviders. Ondertussen wordt elk DRM- en encryptiesysteem gekraakt zodra het op de markt komt. Dat is een wapenwedloop die onmogelijk tot een zinnige oplossing kan leiden.

Nieuwe systemen waarbij mensen een eerlijke prijs betalen voor een redelijke set mogelijkheden zie ik echter niet meer ontstaan. Sterker nog, de trend is juist om DRM te dumpen. Deze trend werd ingezet door Steve Jobs, die op geheel eigen wijze de muziekindustrie min of meer dwong te accepteren dat hij DRM-vrije muziek kon verkopen via iTunes. Sindsdien is muziek steeds vaker DRM-vrij te koop, hoewel vaker wel duurder en tegen slechtere kwaliteit maar dat zou een kwestie van tijd moeten zijn.

Voor films blijft de industrie vasthouden aan DRM, en wel in het model “u mag niets en betaalt de hoofdprijs”. Want ja, eigenlijk moet er nog een paar jaar verdiend worden aan Blu-Ray voordat het verkoopkanaal “internet” aangeboord kan worden. De industrie gaat namelijk uit van het idee “iedereen moet betalen, voor elk gebruik” en wil maximaal verdienen uit elk kanaal. Het meest extreme voorbeeld is de Disneykluis: Disneyfilms komen slechts ééns per generatie uit, zodat iedereen ze weer opnieuw gaat kopen.

En dat is de tragiek van het systeem: het had zo mooi kunnen zijn, superdistributie en betalen per gebruik. Maar DRM is alleen ingezet als antipiraterijsysteem en voor het maximaal uitpersen van de consument. Daarmee is ieder draagvlak voor het systeem weggenomen.

Hoe het dan wel moet? Eerlijk gezegd heb ik geen idee. Het lijkt me te laat om nu nog een vriendelijk en bruikbaar DRM systeem te introduceren zoals Stefik dat voor ogen had. De kampen zijn te verhard - de discussie gaat nu zo ongeveer over de vraag of elektriciteitsmaatschappijen aansprakelijk zijn voor inbreuk gepleegd door hun afnemers, niet over hoe we filmverkoop via internet gaan stimuleren. En ook de politiek lijkt alleen nog te focusseren op het idee dat piraterij moet worden gestopt zodat magischerwijs er ineens een groot legaal aanbod gaat komen.

Ik blijf terugkomen bij het idee van verplichte licenties: sta toe dat iedereen werk kopieert maar verplicht winstafdracht aan rechthebbenden. En nee, ook dat systeem is niet perfect. Maar wie wat beters weet, mag het zeggen.

Arnoud
Foto: Michael Vroegop, Flickr, CC-BY 2.0

Een lezer vroeg me:

De wachtwoorden van een aantal van onze computersystemen worden in een archiefkast bewaard. Om de auditors enigszins gelukkig te maken wordt de toegang tot deze kast onder meer gecontroleerd met een handtekeningformulier. Wie de kast open wil doen, moet naam en handtekening (en tijdstip) vermelden. Mogen wij daarbij eisen dat werknemers zich legitimeren, en mogen we dan een kopie bewaren van dat legitimatiebewijs zodat we de authentieke handtekening hebben?

Ik ga nu iets zeggen dat voor veel mensen verrassend is: er is geen wet die vastlegt of regelt wat iemands authentieke handtekening is!

Een handtekening is een krabbel op een stuk papier waarmee de plaatser aangeeft dat de inhoud juist is of dat hij daarmee akkoord gaat. De wet bepaalt echter nergens hoe een handtekening eruit moet zien of hoe je “de” handtekening van de plaatser herkent. Je bent dus formeel vrij om naar verschillende instanties toe verschillende handtekeningen te gebruiken, zolang je maar goed onthoudt per instantie wat je handtekening daar is.

In securitytaal: een handtekening zetten is het papieren equivalent van een pincode intypen. “Something you can do” in plaats van “something you know”, als het ware. Wie de handtekening kan zetten, wordt geacht de betreffende persoon te zijn.

In de praktijk is het natuurlijk volstrekt ingeburgerd dat je met één handtekening werkt, en dat we met z’n allen doen alsof handtekeningen niet triviaal te vervalsen zijn. De wet zegt over handtekeningen eigenlijk niet veel meer dan wat in artikel 159 Rechtsvordering staat. Een ondertekend document is tegen de ondertekenaar bewijs van de inhoud (tenzij hij tegenbewijs aanlevert). Enkel roepen dat je het zo niet had bedoeld of dat er een fout is gemaakt, gaat je niet helpen. Echter, ontken je stellig dat je dat document nooit getekend hebt, dan moet eerst bewezen worden van wie de ondertekening afkomstig is.

En ja, dat is alles dat de wet hierover zegt. Niets over bewijsvermoedens wanneer vulpennen zijn gebruikt, of dat een betrouwbaar middel voor het overbrengen van inkt moet zijn gebruikt of dat minstens twee door TNO gecertificeerde getuigen aanwezig waren. Het is me dan ook al jaren een doorn in het oog dat we voor digitale handtekeningen een heel raamwerk hebben opgetuigd waarin dat allemaal wél wordt geëist. Met als uitsmijter dat als je dat allemaal doet je “vermoedelijk” een rechtsgeldige handtekening hebt gezet. Oh, en natuurlijk komt daar nog bij dat handtekeningen zelden juridisch nodig zijn. Ok sorry, ik ben alweer rustig.

Hoe dan ook. Een handtekening is dus handig om bewijs te verzamelen, in dit geval van het feit dat persoon X bij de archiefkast is geweest op tijdstip T. Om te verifiëren dat iemand is wie hij zegt dat hij is, kan het bedrijf vragen dat hij een controlehandtekening plaatst in een logboek. Men mag ook wel vergelijken met de bankpas of identiteitskaart, maar een kopie daarvan bewaren lijkt me niet echt nodig.

Update (12:00) heel toevallig lees ik dit vonnis waarin de handtekening onder een verkoopcontract (van een domeinnaam) werd betwist. De koper moest bewijzen dat het contract echt was en ondertekend door de verkoper. Deze had uitdrukkelijk betwist dat de handtekening van hem was (onder verwijzing naar “fotoshoppen”). Het contract was ooit op papier opgemaakt en vervolgens gescand.

Het origineel had de koper niet meegenomen, en uit de documenteigenschappen van de gescande PDF die wél was overlegd bleek dat deze pas was vervaardigd op 22 april 2010, terwijl in het document een datum van 20 februari 2010 genoemd stond. Dat was voor de rechter genoeg om de scan niet als bewijs te accepteren.

(In 4.10 staat “een overeenkomst hebben gesloten” maar volgens mij is dat fout, omdat in 5.1 de koper wordt verboden de domeinnaam te gebruiken tot dat vaststaat dat er wél een overeenkomst is.)

Arnoud

Hackers hebben malware verspreid via een advertentienetwerk, meldde Tweakers gisteren. Bekende sites van Wegener, Sanoma en Reed Business zouden zijn getroffen, maar niet Nu.nl, meldt Nu.nl. Het virus doet voorkomen alsof een computer crasht en biedt vervolgens een oplossing voor het probleem, waar de gebruiker dan wel voor moet betalen. Drie keer raden welke vraag ik nu ga behandelen.

De wet stelt het opzettelijk verspreiden of ter beschikking stellen van kwaadaardige software zoals virussen en wormen strafbaar, met de generieke definitie ‘programma’s die bestemd zijn om schade aan te richten in een geautomatiseerd werk’. Daarmee zijn zo ongeveer alle soorten virussen en wormen gedekt.

Het per ongeluk (laten) verspreiden van virussen of het beschadigen van systemen of informatie is in principe niet strafbaar. Als er door een lek in de software binnengedrongen is, dan is geen sprake van opzet. Er is echter een ondergrens: als systemen door grove nalatigheid beschadigd of onbruikbaar worden gemaakt, dan is het betrokken bedrijf wel degelijk strafbaar. Wel worden de maximumstraffen dan verlaagd.

Het virus (de Trojan?) blijkt verspreid via een advertentienetwerk. Hoe de advertentieserver van het netwerk kon worden besmet, kon men gisteren nog niet zeggen. Dat maakt het moeilijk bepalen of sprake is van grove nalatigheid.

Er is nog nooit iemand aangeklaagd met als beschuldiging grof nalatig te hebben gehandeld bij het verspreiden van virussen of het laten aanrichten van schade. Wellicht dat dit in de toekomst gaat gebeuren: nu het eigenlijk algemeen bekend is dat men eigenlijk een virusscanner en firewall op de pc moet hebben, kan het grof nalatig worden om dit niet te doen. Hetzelfde kan gelden voor bedrijven die hun software niet bijwerken door de updates van Microsoft, Apache en andere bedrijven niet te installeren.

Een boze schadeclaimbrief naar Wegener en andere partijen die meewerkten is echter snel geschreven, en wie weet schrikt er daar dan iemand zó van dat men zomaar gaat betalen.

Arnoud

Een lezer vroeg me:

Binnen onze organisatie is het onlangs verboden om gegevens van relaties te bewaren in mailboxen of naar elkaar te mailen. Wij mogen deze alleen opvragen in het centrale systeem als ze nodig zijn. Dit is buitengewoon onhandig, als ik een keer een telefoonnummer nodig heb dan moet ik apart inloggen. Waarom stelt men deze eis?

Deze organisatie neemt de privacywet wel érg serieus. De Wet bescherming persoonsgegevens eist dat je “adequate beveiliging” toepast bij ieder gebruik of verzending van persoonsgegevens.

Er zijn geen harde technische eisen die altijd gelden. Zo wordt bij contactformulieren vaak SSL gehanteerd, maar dat is een gebruik (of eis van een brancheorganisatie) en geen wettelijke plicht. Je moet dus per geval kijken wat je voor beveiliging hebt en of dat ‘adequaat’ is gezien de omstandigheden.

Bij e-mail is er het risico dat de mail naar een verkeerd persoon gaat. In dat beveiligde systeem speelt dat risico niet, omdat alleen de juiste ontvanger het wachtwoord zou moeten hebben. Maar verzenden met versleutelde e-mail zou op zich ook in orde moeten zijn.

Aan de andere kant, de meeste relaties sturen zelf elke keer per mail hun hele reeks contactgegevens mee in hun handtekening. Je kunt je dus afvragen of je als ontvanger dan nog wel zo streng moet zijn.

Arnoud

Uit onderzoek van Tweakers.net blijkt dat veel geregistreerde gebruikers in de praktijk een relatief zwak wachtwoord hebben ingesteld, rapporteerde de techsite gisteren. In minder dan een half uur bleek de helft van de versleutelde wachtwoorden eenvoudig te kraken met standaardtools. Leuk, alleen vroegen diverse mensen zich per mail af of dit eigenlijk wel mag, wachtwoorden gaan kraken van je gebruikers.

De analyse van Tweakers lijkt me in alle oprechtheid opgezet, maar dat is natuurlijk geen argument dat je dús binnen de wettelijke grenzen zit. Maar als je alleen intern test of wachtwoorden wel veilig zijn, en er voor zorgt dat niemand (ook de redactie die erover gaat schrijven niet) toegang krijgt tot de wachtwoorden zelf, dan zie ik eerlijk gezegd het probleem niet.

Het testen van wachtwoorden is een volstrekt gebruikelijke handeling, hoewel deze normaal alleen gebeurt bij het inschrijven. De bekende rood/geel/groene indicatoren zijn het bekendste voorbeeld, maar periodieke controles op wachtwoorden zijn niet ongebruikelijk. Verstandig ook, want kwaadwillenden kunnen óók zulke kraaksoftware draaien en zo proberen binnen te komen. Je kunt dus zelfs betogen dat Tweakers verplicht is sterke wachtwoorden af te dwingen omdat zij (de persoonsgegevens van) haar gebruikers moet beschermen.

Natuurlijk áls het misgaat en een derde bij het wachtwoord kan, dan is Tweakers de pineut. De voorwaarden met hun aansprakelijkheidsbeperking helpen dan niets: wie zelf wachtwoorden gaat kraken en dan deze lekt of laat misbruiken, handelt “grof nalatig” en is hoe dan ook aansprakelijk voor alle schade die mensen lijden.

Journalistiek heel interessant maar juridisch echt problematisch zou zijn om te kijken of diezelfde gebruikersnamen en wachtwoorden ook werken bij andere forums.

Meelezende sysadmins: hoe testen jullie wachtwoorden van gebruikers?

Arnoud
Afbeelding: Strongpasswordgenerator.com

Auw. Iraans verkeer naar Gmail kon worden afgetapt dankzij een door Diginotar goedgekeurd certificaat, zo bleek deze week. Alle grote browsers revoceerden meteen het certificaat van Diginotar, hoewel Firefox later een uitzondering maakte voor DigiD. Na enig getreuzel kwam Diginotar-eigenaar Vasco met een verklaring dat men in juli was gehackt, waarna bleek dat in ieder geval de website al jaren kwetsbaar was. En daarna dook nieuws op dat er nog veel meer valse certificaten in omloop waren, waaronder voor anonimiteitsnetwerk Tor. Heeft Diginotar nu een probleem of niet?

Laten we eens doen of de publiciteit niet al genoeg is om het einde van Diginotar als merknaam in te luiden, en de juridische gevolgen bekijken van deze faal. De wet kent namelijk de nodige bepalingen over certificatiedienstverleners, oftewel personen of bedrijven die certificaten afgeven of andere diensten in verband met elektronische handtekeningen verleent, zoals de Telecommunicatiewet ze definieert.

Toen e-commerce een beetje populair begon te worden, ontstond behoefte aan het zetten van digitale handtekeningen. Waarom is mij volstrekt onduidelijk, handtekeningen zijn namelijk zelden tot nooit nodig in het handelsverkeer. Ja, als je een huis wilt kopen, maar dat is nu net een van de weinige dingen die je niet via een internetdienst kunt doen. Maar goed, er moesten digitale, pardon elektronische handtekeningen komen en daar moest dan een hele infrastructuur bij opgezet worden om te kunnen controleren wie die had gezet. Ik ben daar ooit op afgestudeerd maar ondertussen best wel cynisch over het nut van deze hele poppenkast. Waar is de infrastructuur voor analoge handtekeningen?

Afijn, die infrastructuur oftewel PKI is waar Diginotar een rol in speelde. De opzet van deze infrastructuur is hiërarchisch: we vertrouwen een partij met een certificaat omdat de uitgever van dat certificaat zegt dat dat klopt. En we vertrouwen die uitgever omdat ook hij een certificaat heeft waarvan de uitgever zegt dat het klopt. Enzovoorts, enzoverder tot we bij de wortel van deze hiërarchische boom zijn. (Terzijde: informatici tekenen zulke bomen met de wortel aan de bovenkant. Argh.) Diginotar heeft de positie van root CA, wat zo veel wil zeggen als dat wanneer Diginotar het zegt, het klopt. Gewoon, omdat het kanergens ophoudt. (Overigens geldt dit niet voor DigiD, daar is Diginotar ’slechts’ sub-root onder de Staat der Nederlanden.)

Vertrouwen is dus het fundament waar de dienstverlening van een certificatiedienstverleners op stoelt. Immers, een echt certificaat is op geen enkele wijze te onderscheiden van een per abuis of met kwade trouw uitgegeven certificaat. De enige controle is de elektronische handtekening die erbij staat, maar die zegt niets over de inhoud. Het certificaat waar het allemaal mee begon, vermeldde de sites van Google (*.google.com) maar was in gebruik bij een partij die niet Google was. Dat is fataal voor de goede werking van een PKI.

“Gekwalificeerde” certificaten mag je alleen uitgeven als je geregistreerd bent bij de OPTA (wat Diginotar ook keurig is). Een gekwalificeerd certificaat is een certificaat dat uitgegeven is door een geregistreerde partij die zich netjes aan de regels houdt over betrouwbaarheid, en dat aan een persoon gekoppeld is.

Aan een dienstverlener die dergelijke certificaten uitgeeft, worden zware eisen gesteld door de wet en het daarbij behorende besluit. Zo moet je ETSI TS 101 456 naleven en houdt OPTA toezicht. En de wet (art. 6:196b BW) verklaart de dienstverlener aansprakelijk voor alle schade door onjuist uitgegeven certificaten, tenzij zij kan bewijzen dat zij niet onzorgvuldig heeft gehandeld, of als het certificaat ingetrokken was voordat de schade ontstond, of als het certificaat voor een niet in het certificaat vermeld doel werd aangemerkt.

Alleen: de SSL-certificaten waar het om gaat, zijn geen gekwalificeerde certificaten. Daarmee is die bijzonder strenge aansprakelijkheidsregel niet van toepassing. En dan wordt het lastig, want dan is Diginotar juridisch gezien gewoon een club die iets zegt met een digitale handtekening eronder, en tsja, afgaan op wat mensen zeggen is geen reden om ze aansprakelijk te stellen als ze het fout hadden. Anders heb ik nog wel een leuke claim tegen Astro-TV. Voor aansprakelijkheid is meer nodig: je moet een wettelijke norm geschonden hebben (die in direct verband staat met de schade) of je moet maatschappelijk onzorgvuldig hebben gehandeld, oftewel “dit staat niet in de wet maar vinden we toch dusdanig onfatsoenlijk dat je alsnog schade moet vergoeden”.

Bij die onzorgvuldigheidsnorm wegen altijd de exacte omstandigheden van het geval zwaar. Zo zal bijvoorbeeld meewegen wat de oorzaak van de hack is waarmee deze certificaten gegenereerd konden worden. Was men nalatig in het sleutelbeheer? Of was dit een buitengewoon geavanceerde zero-day hack (à la de RSA phish) die niemand had kunnen opmerken? Heeft Diginotar na het ontdekken van de hack alles gedaan om de gevolgen tegen te gaan, of heeft ze juist zitten treuzelen?

Als blijkt dat ze te weinig hebben gedaan, dan kunnen getroffen Gmailende Iraniërs ze aansprakelijk stellen voor hun schade - alleen zal die lastig aan te tonen zijn. Maar ook andere partijen die getroffen zijn door de onjuist uitgegeven certificaten kunnen dit proberen. Zo zou een webwinkel die zijn SSL-certificaat ongeldig ziet worden omdat Mozilla of Microsoft Diginotar niet meer erkent, omzet kunnen mislopen omdat mensen niet meer durven te bestellen door de foutmeldingen die ze dan krijgen. Gemiste omzet is natuurlijk wel lastig om te onderbouwen, maar zoals uit een zaak tussen TROS Radar en een hondenfokker bleek, kan een deskundige worden opgeroepen die de boeken onderzoekt en inschat wat de omzet of winst zou zijn geweest. In de Radar-zaak werd die op een half miljoen euro geschat.

Arnoud

Een lezer vroeg me:

Recent kwam mijn website (een colocated eigen server) onder vuur door een DoS-aanval van buitenaf. Ik heb toen mijn provider gevraagd maatregelen te nemen en met name de IP-adressen te filteren of blokkeren waar de aanval vandaan kwam. Zij weigeren dit echter omdat ze vinden dat ik het beheer moet doen op mijn machine. Ook zeggen ze dat het voor hen ondoenlijk is om maatregelen te nemen. Maar ik neem bij hen toch een dienst af, kan ik ze dan niet verplichten in te grijpen als de dienst niet goed werkt?

De plichten die de provider heeft, volgen primair uit het contract. De vraag is dus wat daar instaat over abuse en filteren. En als er niets staat, moet je uit de aard van het contract afleiden wiens verantwoordelijkheid dit moet zijn. Bij een eigen colocated server ben je als klant zelf verantwoordelijk voor het beheer; de plichten van de provider houden op bij de netwerkstekker. De vraag wordt dan dus, is een DDoS-aanval iets dat de stekker raakt of pas het apparaat waar die stekker in zit?

De klant kan zelf blokkeren op een eigen firewall maar dan zit zijn inkomende netwerkverkeer nog steeds vol. Droppen aan de buitenkant (netwerk van de ISP) is efficiënter, zeker, maar hoe weet de ISP dan welke adressen ze moeten droppen?

Een DDOS aanval zou ik eerder als iets van buitenaf zien, net zoals een hagelstorm. Je kunt het niet voorkomen, je kunt alleen de impact beperken. En dan wordt de vraag dus, wat moet een ISP doen om die impact te beperken. Zij hebben een zorgplicht, net zoals een huisbaas moet zorgen voor een goed dak in een huurhuis. Maar dat houdt ergens op: een hagelstorm met tennisbalformaat hagelstenen die onder een hoek van 45 graden binnenkomt en je kelderruitje eruit gooit, is overmacht. Je kunt dan geen vergoeding van je huisbaas eisen.

Verder speelt altijd de vraag tussen kosten en baten een belangrijke rol. Een dure maatregel tegen een uitzonderlijk probleem is niet billijk en hoeft niet te worden ingevoerd. Een goedkope maatregel tegen een routineprobleem moet er altijd zijn. En daartussen is het grijze gebied waar advocaten zich in thuisvoelen.

Ook speelt mee welke opvattingen er in de markt heersen: als iedereen vindt dat de klant dit moet doen, dan kun jij niet zomaar van de ISP eisen dat hij het oplost. Als de heersende mening is dat de ISP dit moet doen, dan kun je eisen dat jouw provider dat ook gaat doen.

Het is ontzettend moeilijk om iets te doen aan DDoS-aanvallen. Een tijd geleden las ik een uitgebreide review bij Tweakers over de technieken en mogelijkheden om het tegen te gaan. Maar fundamenteel is het nauwelijks op te lossen: er komt een berg verkeer binnen en dat moet je filteren.

Arnoud

Als iemand inbreekt op je VoIP-centrale en je duizend euro aan belkosten oplevert, is dat dan jouw probleem of dat van je telefonieprovider? Een lastige vraag, die maar al te vaak tot grote conflicten kan leiden. In een recent vonnis uit Maastricht legt de rechter de bal -terecht- bij de klant, maar wel mede (vooral?) vanwege het feit dat het ging om een eigen server.

De klant had een contract voor het leveren van VoIP-telefonie. Hij gebruikte daarbij een “eigen” server, maar het is me niet duidelijk of dat betekent “zelf gekocht” of “in eigen beheer”. Ik vermoed het laatste.

Voor deze dienst betaalde de klant gemiddeld € 33,50 per maand, en de factuur van april 2010 voor € 1.028,06 was dan ook enigszins een verrassing. Deze bleek te verklaren door een inbraak op de server in maart. Daarbij hadden derden vanuit Roemenië via hun centrale 150 keer naar Zimbabwe en Somalië gebeld.

De klant betwistte dat zij deze duizend euro moest betalen. De leverancier zou haar zorgplicht hebben geschonden, omdat zij geen beveiligingsmaatregelen of software had ingebouwd ter bescherming van de klant. Ook had de leverancier nooit gewaarschuwd voor malafide organisaties die op andermans kosten kunnen telefoneren. Plus, er kon zomaar onbeperkt gebeld worden, en dat is ongebruikelijk: andere bedrijven stellen een bellimiet in of geven een waarschuwing wanneer een afwijkend belpatroon optreedt.

De rechter gaat daar niet in mee. De klant had zich kunnen beveiligen tegen inbraken in de server, maar heeft daarvoor geen stappen genomen. Nergens is uit gebleken dat de leverancier nalatig was met waarschuwen of iets dergelijks.

En wat andere bedrijven doen (bellimieten of waarschuwingen) is niet relevant: de wet verplicht niet tot het overnemen van maatregelen van je concurrent. Dat zou pas kunnen als de maatregel zó evident is dat je van grove nalatigheid zou spreken als deze niet genomen wordt. En dan denk ik eerder aan het uitschakelen van alle wachtwoordbeveiliging dan aan een bellimiet.

Een professionele partij die een eigen VoIP-server heeft, wordt dus geacht zelf de beveiliging daarvan ter hand te nemen. De leverancier kan daarbij diensten verlenen, maar dat is niet standaard en hij mag er dus gewoon geld voor vragen.

Arnoud