Bert-Jaap Koops homepage - publications

Een ieder heeft recht op het bestaan van een zodanige maatschappelijke en internationale orde, dat de rechten en vrijheden, in deze Verklaring genoemd, daarin ten volle kunnen worden verwezenlijkt. (Artikel 28 UVRM)

verschenen in Computerrecht 1997 nr. 4, pp. 150-154

Dit artikel mag niet worden verspreid of vermenigvuldigd zonder toestemming van de auteur. Het uitprinten van één copie voor persoonlijk gebruik is toegestaan. Citeren met bronvermelding.

Notaris, ik houd mijn sleutels liever zelf

© Bert-Jaap Koops (*), 1997

Met het KNB-preadvies 'De notaris en het elektronisch rechtsverkeer' geeft het notariaat aan de elektronische snelweg in te willen slaan. Dat is een heuglijk feit, dat terecht positieve reacties heeft ontvangen. Op onderdelen passen echter wel enige bedenkingen, vooral waar het notariaat zich al te voortvarend stort op nieuwe technologie. De preadviseurs geven blijk de techniek van encryptie onvoldoende te beheersen. In dit artikel wordt het voorstel het notariaat cryptografische (privé)sleutels te laten beheren bekritiseerd als onnodig en ondoordacht.

1. Inleiding

Het preadvies 'De notaris en het elektronisch rechtsverkeer' [1] van de Koninklijke Notariële Broederschap is algemeen begroet als een welkome aanzet om het notariaat de aansluiting bij de komende informatiemaatschappij niet te laten verliezen. Het is verheugend dat een traditioneel wat behoudende beroepsgroep inziet dat ontwikkelingen in informatie- en communicatietechnologieën de manier waarop mensen met elkaar omgaan voor goed veranderen. Naast lovende besprekingen van het preadvies, zijn er ook enkele kritische kanttekeningen geplaatst met de strekking 'bezint eer ge begint'.[2] Op één (relatief klein) onderdeel van het preadvies wil ik mij bij deze kritiek aansluiten. Ik heb grote bedenkingen bij het voorstel de notaris cryptografische privésleutels te laten beheren. De preadviseurs realiseren zich onvoldoende de consequenties van dit voorstel, en geven in het geheel niet aan waarom deze functie eigenlijk vervuld zou moeten worden. Mijns inziens speelt onvoldoende inzicht in de techniek van encryptie - het versleutelen van gegevens - de preadviseurs hier parten. Ik zal in dit artikel daarom eerst aandacht besteden aan de verwijzingen naar encryptie in het preadvies, om vervolgens in te gaan op het voorstel sleutels te gaan beheren.

Voor ik inga op de behandeling van encryptie in het preadvies, is een korte uitleg van cryptografie op zijn plaats. Cryptografie is een verzamelterm voor systemen voor versleuteling van gegevens, waarmee de authenticiteit, integriteit en vertrouwelijkheid van die gegevens kunnen worden gewaarborgd. Hoewel cryptografie al sinds de Oudheid bestaat, heeft het sinds de jaren zeventig een enorme groei gekend door de ontwikkeling van moderne crypto-systemen. Naast snelle, conventionele systemen, die gebruik maken van één en dezelfde sleutel voor versleutelen en ontsleutelen (en daarom symmetrische systemen heten), zijn er publieke-sleutelsystemendie gebruik maken van een sleutelpaar, bestaande uit een publieke en een privésleutel: wat men vercijfert met de ene sleutel, kan men alleen ontcijferen met de andere. Met name de laatste categorie verruimt het toepassingsbereik enorm. Men kan nu vertrouwelijk communiceren zonder eerst geheime sleutels uit te wisselen: Alice [3] kan een bericht aan Bob sturen door het met zijn publieke sleutel te vercijferen; alleen Bob kan het bericht dan ontsleutelen - met zijn privésleutel, die hij zorgvuldig geheim houdt. Maar men kan ook de authenticiteit en integriteit van een bericht waarborgen: Alice versleutelt dan met haar eigen privésleutel, waarna iedereen met haar publieke sleutel het bericht kan ontsleutelen: als er een zinvol bericht uitkomt, moet het versleuteld zijn geweest door Alice - zij is immers de enige die over haar privésleutel beschikt. Deze vorm van versleuteling is daarom vergelijkbaar met het ondertekenen van een bericht en wordt aangeduid met 'digitale handtekening'. Omdat het (asymmetrisch) vercijferen van een volledig bericht teveel tijd kost, ondertekent Alice in de praktijk een hashwaarde (een wiskundig 'uittreksel') van het bericht in plaats van het bericht zelf; Bob kan de handtekening controleren door de versleutelde hashwaarde te ontsleutelen met Alice's publieke sleutel en vervolgens te verifiëren of de hashwaarde klopt bij het bericht.

2. Kloof met de techniek

In zijn bespreking van het preadvies merkt prof. Huijgen op dat er een tweedeling bestaat tussen notariële experts en informaticajuristen; 'personen die beide terreinen min of meer overzien zijn uiterst dun gezaaid'. [4] Helaas geldt hetzelfde binnen het terrein van recht en informatica: velen beheersen vooral een van beide terreinen. De 'recht en informatica'-preadviseurs zijn alle juristen, die zich in meer of mindere mate het terrein van informatica hebben eigen gemaakt. Bij het lezen van het preadvies krijg ik de indruk dat dat vooral in mindere mate is, waar het cryptografie betreft. [5]

Ten eerste valt op dat het taalgebruik ten aanzien van cryptografie nogal slordig is. Ik geef enkele citaten (cursief) met mijn commentaar daarop.

* 'indien de sleutel wordt ontcijferd' (p. 29): alleen een bericht kan worden ontcijferd, niet de sleutel.

* 'de chipkaart met de elektronische handtekening' (p. 30, evenzo p. 166): de chipkaart bevat niet de elektronische handtekening (die is immers documentafhankelijk), maar de sleutel waarmee een elektronische handtekening kan worden gezet.

* 'Encryptie: een techniek waarbij leesbare gegevens m.b.v. een algoritme en een geheime sleutel worden omgezet in gecodeerde gegevens' (p. 171, evenzo p. 48 en Verslag ALV, p. 7): bij asymmetrische systemen betekent het 'versleutelen' met de privésleutel [6] het ondertekenen van een bericht (eenieder kan immers met de corresponderende openbare sleutel het bericht 'ontsleutelen'); encryptie slaat echter veeleer op het geheimhouden van een bericht, en daarvoor is versleuteling met de openbare sleutel nodig (zodat alleen de houder van de corresponderende privésleutel het bericht kan ontsleutelen).

* 'Cryptografie: het (...) versleutelen van gegevens' (p. 171): cryptografie is het systeem (hardware of software) waarmee je versleutelt, het proces van versleutelen duidt men aan met 'encryptie'.

* 'Een veelgebruikte sleutel is bekend onder de naam DES' (Verslag ALV, p. 7): DES is een cryptografisch systeem, geen sleutel.

Ernstiger dan dergelijke slordigheden zijn echter de diverse uitspraken die doen vermoeden dat de preadviseurs onvoldoende inzicht hebben in de techniek die zij bespreken. Ik geef weer enkele voorbeelden.

* 'De vraag is of dan niet teveel kennis in één hand is', als de producent van de chipkaart ook de geheime sleutel zou beheren (p. 32). Dit gaat kennelijk uit van de veronderstelling dat de combinatie van kennis van het crypto-algoritme en kennis van de sleutel meer oplevert dan alleen kennis van een van beiden. Echter, de belangrijkste crypto-algoritmes zijn publiekelijk bekend - het is een cryptografisch principe dat algoritmes openbaar moeten zijn, opdat ze zoveel mogelijk getest en aangevallen kunnen worden. Kennis van een algoritme levert geen voordeel op voor het kraken van een versleuteld bericht: de kracht van een (goed) crypto-systeem berust geheel in de sleutel.

* Voor de integriteit van berichten kan een hashwaarde behulpzaam zijn, terwijl voor de authenticiteit een elektronische handtekening kan worden gebruikt (pp. 102/3, soortgelijk p. 162). De preadviseurs maken hier een te sterke scheiding tussen integriteit en authenticiteit. Hoewel beide functies goed te ónderscheiden zijn, kunnen zij in de cryptografische praktijk niet van elkaar worden géscheiden: het waarborgen van de integriteit betekent het waarborgen van de authenticiteit en omgekeerd. Integriteit wordt immers bewerkstelligd via een hashwaarde (een wiskundig 'uittreksel' dat aan het bericht wordt toegevoegd), doch deze hashwaarde moet worden ondertekend om zekerheid op te leveren. De meeste hashfuncties berekenen immers op een publieke manier een hashwaarde, zodat iemand die een bericht manipuleert, tegelijk een nieuwe hashwaarde kan berekenen en toevoegen. Zonder handtekening van de afzender over de hashwaarde kan de ontvanger daarom niet zeker zijn van de integriteit van het bericht. Aan de andere kant kan een elektronische handtekening nauwelijks zonder hashfunctie, omdat het ondertekenen van een volledig bericht teveel tijd kost; in de praktijk wordt daarom altijd een hash van het bericht ondertekend in plaats van het bericht zelf.

* De 'volledige onversleutelde tekst (...) naar de ontvanger verzonden met toepassing van de publieke sleutel van de ontvanger' (p. 146). Ook hierbij geldt dat het versleutelen van een volledige tekst met een publieke sleutel teveel tijd kost. In de praktijk gebruikt men daarom 'hybride' systemen: men versleutelt het bericht met een snel, symmetrisch algoritme, en men wisselt de daarbij gebruikte sleutel uit met behulp van asymmetrische cryptografie - deze sleutel is immers een klein berichtje, zodat de arbeidsintensieve asymmetrische versleuteling daarvan niet teveel tijd in beslag neemt.

* 'De TTP vervult (...) de taak private sleutels uit te geven aan de gebruikers van het informatiesysteem. Daarmee (...) beschikt [hij] over de mogelijkheid berichten te manipuleren en de identiteit van een gebruiker aan te nemen.' (p. 149) Hier wreekt zich het onvoldoende onderscheiden van de functies van ondertekenen en geheimhouden. Het feit dat de TTP privésleutels uitgeeft betekent nog niet dat hij deze ook bewaart (zie onder), zeker niet in het geval van sleutels die voor handtekeningen worden gebruikt. Dat zou wel een zeer grote verantwoordelijkheid leggen bij de TTP (denk bijvoorbeeld aan de beveiliging van de ondertekeningssleutels van (top)managers of ministers!). Juist omdat ondertekenen en geheimhouden verschillende functies zijn waarbij geheel andere belangen een rol spelen, zullen gebruikers twee sleutelparen moeten hebben: een voor de elektronische handtekening, en een voor geheimhouding van berichten. Het gebruiken van een en hetzelfde sleutelpaar voor beide toepassingen creëert onverantwoorde risico's. Daarbij zal de privésleutel voor ondertekening nooitaan iemand anders moeten worden gegeven (voor het geven van een volmacht tot ondertekening volstaat het ondertekenen van een bericht met die strekking; het overhandigen van de ondertekeningssleutel zelf is niet nodig).

* Bij het verifiëren van de authenticiteit van een bericht, gebruikt een notaris onder meer 'de bij hem in beheer zijnde herkenningskarakteristieken van de private sleutel' (p. 167). Dit is een merkwaardige opmerking, die ik moeilijk anders kan duiden dan de veronderstelling dat voor verificatie van de authenticiteit van een bericht op de een of andere manier de privésleutel nodig is. Dit miskent volledig het karakter van asymmetrische cryptografie, aangezien voor verificatie alleen de openbare sleutel nodig is. Als bij ontsleuteling met de openbare sleutel de juiste hashwaarde of een begrijpelijke tekst tevoorschijn komt, moet het bericht wel ondertekend zijn met de corresponderende privésleutel. Waarom daarbij nog 'karakteristieken van de privésleutel' betrokken zouden moeten worden, is mij een raadsel.

* 'De private sleutel bestaat uit twee priemgetallen en de publieke sleutel is het produkt van die twee priemgetallen.'(Verslag ALV, p. 7) Een typisch geval van klok en klepel. Bepaalde asymmetrische crypto-systemen gebruiken het product van twee grote priemgetallen als parameter; hierbij moet je de priemgetallen kennen om sleutelparen te kunnen berekenen. In dat opzicht zijn de twee priemgetallen het 'geheim' dat nodig is om uit een openbare sleutel een privésleutel te kunnen berekenen, maar het is een misvatting dat dit 'geheim' zelf de privésleutel zou zijn. In feite kunnen de priemgetallen worden weggegooid zodra de benodigde sleutelparen zijn berekend. Overigens zijn er ook asymmetrische cryptosystemen die niet zijn gebaseerd op het product van twee priemgetallen, maar op een ander wiskundig complex probleem (discreet logaritme); de nieuwste versie (5.0) van het populaire encryptie-programma Pretty Good Privacy bevat een dergelijk systeem.

Helaas, waar een notaris uit de zaal verzucht dat de verhalen over de nieuwe TTP-mogelijkheden 'zeer technisch van aard' zijn (Verslag ALV, p. 24), moet ik constateren dat de verhalen juist niet technisch genoeg zijn, althans onvoldoende gebaseerd op correct inzicht in de techniek.

3. Waarom sleutelbeheer?

Nu zal professor Franken tegenwerpen: 'het is eigenlijk net zoals met de auto. Je moet weten dat er benzine in de tank moet worden gegooid en dat is het wel. Zo ook hier: je moet bepaalde handelingen en technieken kunnen duiden, maar wat er gebeurt, hoeft u niet tot in de details te weten.' (Verslag ALV, p. 7) Ik vraag mij dat af. Natuurlijk, kennis van wiskundige details is niet nodig, maar enig inzicht in hoe de techniek functioneert lijkt mij onontbeerlijk voor wie iets met die techniek wil gaan doen. Met name het gebrekkige inzicht in de manier waarop cryptografie in de praktijk wordt gebruikt vind ik een manco.

Waar voor veel toepassingen de notaris misschien nog kan volstaan met de wetenschap 'dat een auto op benzine rijdt', lijkt mij dat niet op te gaan voor het beheren van sleutels. Met name preadviseurs Franken en Lekkerkerker stormen enthousiast af op dit nieuwe terrein. Daarbij gaan zij volledig voorbij aan de vraag waarom eigenlijk sleutels zouden moeten worden beheerd. Hun veronderstelling is blijkbaar dat het uitgeven en/of certificeren van sleutels automatisch gepaard gaat met het in bewaring houden ervan (zie bijvoorbeeld p. 32, 149 en Verslag ALV p. 7 en 19). Deze activiteiten hebben echter weinig met elkaar te maken.

De certificatie van sleutels is momenteel de meest dringende behoefte van gebruikers van cryptografie: men moet er immers van op aankunnen dat de openbare sleutel waarmee men een vertrouwelijk bericht versleutelt ook daadwerkelijk toebehoort aan de beoogde ontvanger, en evenzo voor de verificatie van een elektronische handtekening. Hiervoor is het nodig dat openbare sleutels worden gecertificeerd - een uitstekende taak voor de notaris. [7] Voor certificatie is alleen nodig dat de Certification Authority (CA) vaststelt dat een publieke sleutel toebehoort aan een (geïdentificeerde) gebruiker, liefst via diens persoonlijke aanwezigheid. De controle of de gebruiker beschikt over de bijbehorende privésleutel kan plaatsvinden door de gebruiker een standaardbericht te laten ondertekenen, hetgeen de CA kan verifiëren door het bericht met de openbare sleutel te ontsleutelen. Kennis van de privésleutel is voor certificering dus niet nodig.

Het uitgeven van sleutels gaat al een stapje verder: het betekent dat niet de gebruiker zelf sleutels genereert, maar ze uitgereikt krijgt van een instantie. Dit kan een legitieme en praktische mogelijkheid zijn, al zullen er ook gebruikers zijn die liever zelf hun sleutels genereren en vervolgens ter certificering willen aanbieden. Overigens hoeft ook het uitgeven van sleutels niet te betekenen dat de uitgever kennis draagt van de privésleutel. Het sleutelpaar kan in een 'black box' worden gegenereerd, waarbij de privésleutel wordt weggeschreven op een chipkaart - alles buiten de kennisneming van de sleuteluitgever om.

Veel verder gaat echter het beheren of bewaren van privésleutels. Het is een fundamenteel cryptografisch principe dat de privésleutel exclusief in bezit is van de eigenaar; zodra ook anderen over deze sleutel beschikken, vermindert de betrouwbaarheid van het systeem en neemt het risico van misbruik toe. De enige reden waarom gebruikers kunnen willen overgaan tot het in bewaring geven van sleutels bij Trusted Third Parties (TTP's) is om te voorkomen dat zij door verlies van hun privésleutel geen toegang meer hebben tot opgeslagen versleutelde informatie. In de praktijk zal zich deze wens vooral voordoen bij het bedrijfsleven, waar werknemers bestanden kunnen versleutelen en er vervolgens met de sleutel vandoor kunnen gaan. Grote bedrijven zullen echter niet willen dat hun sleutels buiten het bedrijf opgeslagen liggen: zij zullen overgaan tot self-escrow. Daarmee blijft alleen het MKB als potentiële klant van sleutelbeheerinstanties over.

In het preadvies ontbreekt echter enige analyse van de noodzaak van sleutelbeheer of van een mogelijke doelgroep. Alleen Lekkerkerker voelt zich aan het eind geroepen - ter verdediging tegen 'techneuten' - iets te zeggen over 'welke noodzaak er nog is voor sleutelbeheer, anders dan omwille van de registratie en het beheer van de publieke sleutels en het registreren van de gebruikers ervan' (p. 166). De bijzin is al merkwaardig, omdat voor registratie en beheer van publieke sleutels het beheren van privésleutels in het geheel niet nodig is (zie boven). De antwoorden die Lekkerkerker de 'techneuten' voorschotelt, zijn onbegrijpelijk. Ik vermag althans niet in te zien wat gebrek aan standaardisering en de behoefte aan externe identiteitscontrole te maken hebben met het beheren van privésleutels. De enige reden die Lekkerkerker nog resteert is de wens van de overheid om toegang te krijgen tot privésleutels van verdachten, zodat de politie afgetapte versleutelde berichten en gekopieerde versleutelde bestanden kan ontsleutelen. Het (verplicht) deponeren van sleutels is een omstreden en veelbediscussieerd onderwerp, niet in het minst vanwege het (gelukkig nooit officieel geworden) voorontwerp uit 1994 dat cryptografie wilde verbieden. [8] De publieke weerstand die het deponeren van sleutels opriep ligt nog vers in het geheugen. Hoewel veel landen aan het nadenken zijn over justitiële toegang tot sleutels, ligt de weg naar een wettelijke regeling bezaaid met (mijns inziens onoverkomelijke) obstakels. In elk geval is het speculeren over een wettelijke verplichting tot sleuteldeponering een uiterst magere reden om zo enthousiast te beweren dat het notariaat met sleutelbeheer aan de slag moet. De overheid zou daarbij ook niet blij zijn met de opmerking: 'voor de vraag onder welke voorwaarden overheidsinstanties tot [de privésleutel] toegang moeten hebben, kan bij het leerstuk van het verschoningsrecht worden aangehaakt' (p. 167): een wettelijk verplichting zou juist moeten bewerkstelligen dat de overheid te allen tijde (met een rechterlijke machtiging) toegang krijgt tot privésleutels - het verschonen van notarissen zal daarbij uiterst onwelkom zijn.

Er ontbreekt nog een ander belangrijk inzicht in het preadvies. Cryptografie kan worden gebruikt voor beveiliging van opgeslagen informatie en van telecommunicatie. In het eerste geval wordt een bestand versleuteld opgeslagen op een gegevensdrager, in het tweede geval wordt een bericht versleuteld verzonden over de telecommunicatie-infrastructuur. Alleen in geval van opslag speelt de eventuele noodzaak van sleutelbewaring, omdat daar de informatie later nog toegankelijk moet kunnen zijn. Bij telecommunicatie echter speelt het probleem van sleutelverlies en mogelijke latere toegang niet: het gaat immers om sessies waarbij een sessiesleutel wordt gebruikt, die direct na afloop kan worden weggegooid. Het gesprek is afgelopen, de e-mail of de fax zijn gelezen. (Voorzover men een bericht vervolgens wil opslaan voor latere raadpleging valt dit onder opslag, niet onder transport. [9]) Alle voorbeelden die de preadviseurs geven, gaan echter uit van transport: men spreekt consequent van een zender en ontvanger; hierbij is het beheren van privésleutels volstrekt niet aan de orde.

Naast het ontbreken van de noodzaak sleutels te beheren, miskent het preadvies nog het economische belang van privésleutels. Dat Franken suggereert TTP's die sleutels beheren wettelijk uit te sluiten van aansprakelijkheid voor mogelijke schade (p. 151, Verslag ALV, p. 8) lijkt mij niet bepaald een goede zet om vertrouwen te wekken in het functioneren van de TTP's. En, zoals diverse preadviseurs terecht opmerken, vertrouwen is een noodzakelijke voorwaarde voor een TTP om levensvatbaar te zijn. Met name waar het gaat om het beheren van privésleutels (waarbij voornamelijk, als gezegd, het MKB betrokken is), zal een ondernemer zich wel twee keer achter de oren krabben alvorens zijn privésleutel uit handen te geven, als hij de TTP niet kan aanspreken op schade veroorzaakt door het uitlekken van de sleutel. (Ik begrijp best dat de notaris hier niet aansprakelijk zal willen zijn: de schade kan immers aanzienlijk zijn; het lijkt mij een reden te meer om af te zien van sleutelbeheer.)

Wellicht kan ik het notariaat een andere suggestie aan de hand doen. In plaats van het bewaren van privésleutels, lijkt het me zinvoller na te denken over het bewaren van openbare sleutels. Op het eerste gezicht een merkwaardige taak - de sleutels zijn immers openbaar. Ik verwijs echter naar de opmerking van preadviseur Prins, [10] dat de 'integriteit en authenticiteit van digitaal opgeslagen informatie moet zijn gegarandeerd' (p. 84). Zo zal informatie die elektronisch is ondertekend om de authenticiteit en integriteit te waarborgen (denk aan contracten, testamenten, aktes) ook na jaren nog verifieerbaar moeten zijn. Het is dan ook noodzakelijk dat de betreffende publieke sleutel (inclusief certificaat) even lang beschikbaar blijft als de opgeslagen informatie. Omdat sleutelparen bepaald geen eeuwigheidswaarde hebben (gebruikers 'verversen' regelmatig een sleutelpaar, nemen een nieuwe omdat een oude is gecompromitteerd, of hebben verschillende paren voor allerlei functies), moet er ergens een depot zijn waar structureel gecertificeerde, openbare sleutels worden opgeslagen. Het lijkt mij een schone taak voor de notaris.

4. Conclusie

Ik ontkom niet aan de conclusie dat het voorstel notarissen privésleutels te laten beheren ondoordacht is. Ik vrees ook dat die onnadenkendheid voor een belangrijk deel komt door onbekendheid met de techniek. Men heeft zich te weinig willen verdiepen in de praktijk van cryptografie. Ik hoop dat dit artikel aangeeft dat op het terrein van informaticarecht voldoende kennis van beide gebieden - recht en techniek - noodzakelijk is. Hopelijk spoort dit de preadviseurs aan zich wat meer te verdiepen in het spannende vakgebied van de cryptografie. Vooralsnog onderstreep ik de uitroep van Huijgen: bezint eer ge begint - of in dit geval, beheerst de techniek eer ge de techniek beheert.

Noten

[*] Drs. B.J. Koops is AIO aan de Katholieke Universiteit Brabant (Strafrecht, Centrum voor recht, bestuur en informatisering) en de Technische Universiteit Eindhoven (Recht en techniek, Discrete wiskunde). Hij schrijft een proefschrift over justitiële en particuliere belangen bij encryptie.
E-mail: E.J.Koops@kub.nl
WWW: http://cwis.kub.nl/~frw/people/koops/bertjaap.htm

[1] Franken, Lekkerkerker, Tomlow, van Esch, Prins, De Jong, Heck-Vink, De notaris en het elektronisch rechtsverkeer, Koninklijke Vermande, 1996. Zie ook het Verslag van de Algemene Ledenvergadering van de Koninklijke Notariële Broederschap (wetenschappelijk gedeelte) gehouden te Breda op vrijdag 4 oktober 1996 (verder: Verslag ALV).

[2] Prof. mr W.G. Huijgen, 'De notaris en het Elektronisch Rechtsverkeer', WPNR 1996, pp. 637-642.

[3] Alice en Bob zijn personages uit de cryptografische vakliteratuur: zij zijn de standaardgebruikers van encryptie.

[4] Huijgen, op.cit., p. 637.

[5] Opvallend is het gebrek aan verwijzingen naar cryptografische literatuur. De sporadische verwijzingen zijn alle tweedehands naar andere juridische literatuur. Een verwijzing naar een standaardwerk als Bruce Schneier, Applied Cryptography (John Wiley, 1996) of het uiterst leesbare Kaufman, Perlman, Speciner, Network Security(Prentice Hall, 1995), of zelfs een Nederlandstalig werk als Van der Lubbe, Basismethoden cryptografie (Delft, 1994), was op zijn plaats geweest. Ik vermoed echter dat geen der preadviseurs ooit een boek over cryptografie heeft ingezien (of althans gelezen).

[6] Het is raadzaam de termen geheime sleutel en privésleutel uit elkaar te houden: een geheime sleutel is een sleutel die wordt gebruikt bij symmetrische encryptie (waarbij zender en ontvanger dezelfde, geheime sleutel gebruiken), een privésleutel is het geheime deel van een sleutelpaar dat wordt gebruikt bij asymmetrische encryptie.

[7] Zoals Huijgen opmerkt: de kern van de notariële functie ligt in het waarborgen van authenticiteit. Op. cit., p. 639.

[8] Zie het dossier cryptografie in Computerrecht 1994/4, pp. 138-162 en B.J. Koops, 'Sleutels en gaten in de opsporingspraktijk. Een verbod op versleuteling van gegevens stuit op weerstand', in A.J.H.W. Coppelmans et al. (red.), Het actuele recht 2, Koninklijke Vermande, Lelystad, 1995, pp. 139-142.

[9] Vergelijk het antwoord van Minister Sorgdrager op Kamervragen van Van Zuijlen en Roethof (2969710200) over mogelijke inzage in computerbestanden van Internetproviders in verband met emailverkeer van voetbalvandalen.

[10] De opmerking van preadviseur Prins (p. 76) dat in de literatuur verdeeldheid heerst over de interpretatie van art. 125k Sv laat zich eenvoudig verklaren door het feit dat de aangehaalde werken zich baseren op verschillende versies van het artikel, dat juist werd aangepast mede vanwege de opmerking van Kaspersen dat het voorgestelde artikel niet het ongedaan maken van encryptie impliceerde. Door toevoeging van een tweede lid bij de uiteindelijke versie is dat nu expliciet wel het geval, zodat Franken 'die mogelijkheid wel ziet'. Een simpele blik in het wetboek had uitkomst geboden.


© Bert-Jaap Koops, 1997. All rights reserved.
home | help | address | mail | links
research | crypto law survey | publications | personal | amnesty