Hoofdstuk 13 van KPN’s reactie op het Wiv20xx-wetsvoorstel (24 pagina’s) onderzoekt enkele praktische implicaties van de voorgestelde ontsleutelplicht voor aanbieders van communicatiediensten:

13. Netwerkbeveiliging versus medewerkingsplichten

Het uitgangspunt van het voorontwerp is de (mede in par. 8 hierboven al besproken) medewerkingsplicht tot ontsleuteling en/of de methode te delen van versleuteling. Deze medewerkingsplicht is voor aanbieders van communicatiediensten niet goed na te leven en zeker niet zonder hun overige verplichtingen ten aanzien van de beveiliging van netwerken, diensten en persoonsgegevens, die zij hebben ‘naar de stand van de techniek’. De medewerkingsplichten maken de mogelijkheden om hieraan te voldoen onmogelijk of onredelijk complex. Daarmee wordt het primaire doel van telecommunicatiediensten ten behoeve van de economische voortuitgang en de ontwikkeling naar een te vertrouwen ‘e-economy’ geweld aangedaan. Het wetsvoorstel lijkt de ‘veiligheidsfunctie’ van communicatienetwerken te zeer boven de primaire functie ervan te stellen.
Dit geldt ook voor de taak die wordt aangegeven voor de diensten tot het beschermen tegen digitale aanvallen. Zoals in par. 1 al aangegeven kan hierin worden gelezen dat de diensten bij aanvallen daadwerkelijk zouden mogen ingrijpen in netwerkverkeer. Technische toegang tot kabelgebonden telecommunicatie zou echter op zo’n manier moeten gebeuren zodat de diensten geen mogelijkheid hebben op welke manier dan ook om het verkeer te kunnen manipuleren of daarop zelf in te grijpen. De verantwoordelijkheid van de telecom aanbieders mag niet beïnvloed worden, om te voorkomen dat buiten hun invloed om zij niet meer de kwaliteit en continuïteit van hun dienstverlening zelf kunnen garanderen.

Hiervoor gelden mede technische redenen die zich als volgt laten samenvatten.

(a) Voor transportsleutels is de informatie onmogelijk op televeren:

• Transportsleutels zijn per definitie sessie-gebonden en in veel gevallen vluchtige informatie die enkel tijdelijk in het geheugen leven van de end-to-end oplossing. Daarna zijn ze weg. Dit is de moderne internationale standaard hiervoor (Elliptic Curve) Diffie-Hellman Key Exchange met Emphimeral (=vluchtige) sleutels.
• Oudere transport versleuteltechnieken (RSA key exchange) kunnen met een capture van de data worden teruggerekend te samen met de private key van het certificaat.
  • Dit veronderstelt dat er een volledige unsampled capture bestaat van een sessie en dat de private key opgeleverd kan worden. Deze captures kunnen alleen op selectieve momenten gemaakt worden om het netwerk te debuggen. Er is geen enkele voorziening getroffen om hier meer mee te doen.
  • Dit vereist dat er selectieve specifieke nieuwe oplossingen gemaakt worden, omdat er geen enkele noodzaak is voor de aanbieder van communicatiediensten om hierin te moeten voorzien. Dit zou betekenen dat alle netwerkverkeer opgeslagen moet worden. De kosten hiervoor zijn buiten proportioneel hoog en in strijd met de wettelijke regels voor de verwerking van persoonsgegevens.
• Private keys delen, in welke vorm van door, is volgens de internationale standaarden per definitie gelijk aan een ‘key-compromise’.
  • Appliances met en zonder Hardware Security Module (HSM) oplossingen bieden geen private key exportfunctie, maar alleen importfuncties. Dit is een veel voorkomende bescherming. Bij een HSM oplossing is een private key zelfs ‘tamper-proof’ opgeslagen en zijn er buiten dit systeem enkel mogelijkheden om de key’s te vervangen, niet te exporteren.
  • Operationeel gericht beleid eist dat een beheerder in een appliance, HSM en op het uiteindelijke doelsysteem de sleutels aanmaakt en nergens anders. Transport van een private key wordt hiermee uitgesloten om de privacy, security en soevereiniteit van de aanbieder te kunnen handhaven.

(b) Storage gerelateerde keys:

• Er zijn sleutels voor systemen en gebruikers die betrekking hebben op disk-volumes,
  databases, tabellen in databases, rijen en data-velden.
  • De keys zijn van verschillende typen, omvang, techniek, en hebben betrekking op
    uiteenlopende toepassingen.
  • Er is geen peil op te trekken hoe alle verschillende oplossingen op verschillende
    deelgebieden en verschillende implementaties met sleutels werken en in welke vorm. Aanbieders pentesten per oplossing of dit goed gebeurt en letten op de certificeringen wanneer het interne systemen/back-end systemen zijn. Dit zijn de waarborgen die aangeven hoe de status van de beveiliging is. De oplevering van een key is in al deze kwesties geen onderdeel van de vraagstelling geweest, behalve dan hoe te voorkomen dat anderen bij de sleutels zouden kunnen. Dit is in het belang van de soevereiniteit van de aanbieder.

(c) Algemene toevoegingen ten aanzien van geheime sleutels, zoals private keys of andere geheime sleutels:

• Het delen van een private key zou de privacy en security zorgplicht van aanbieders schenden. Het delen van een private key staat gelijk het delen van de identiteit van de aanbieder met de partij die de key heeft. De partij die de private key krijgt kan zich voordoen als de aanbieder. Dit is een aanvalsscenario van hackers en cyber-criminelen om ongezien man-in-the-middle attacks uit te voeren. Zoals in de volgende par. nader uitgewerkt acht KPN het uiterst onwenselijk dat de diensten deze rol zou kunnen vervullen zonder transparantie naar de aanbieders toe.
• Als collateral damage zou het mogelijk moeten maken van het delen van de private key betekenen dat alle beheerders moeten worden geïnstrueerd om met cryptografisch materiaal te moeten omgaan. Dit is specialistisch werk en het cryptografisch materiaal moet met diverse waarborgen worden getransporteerd. Iedere beheerder binnen een aanbieder zal een key ceremonie cursus moeten krijgen om dit te kunnen uitvoeren.
  • Het mogelijk maken van de oplevering van cryptografisch materiaal, zelfs tussen afdelingen binnen een aanbieder, zorgt ervoor dat de security en privacy zorgplicht wordt ondermijnd.

(d) Algemene toevoeging voor ‘one-way’ encryptie technieken:

• Volgens industry-best practices zijn er vele one-way encryptie technieken om bijvoorbeeld wachtwoorden op te slaan. Deze zijn nooit meer terug te halen, omdat er alleen een hash/digest wordt gemaakt van een wachtwoord en deze wordt dan vaak nog een aantal malen complexer opgeslagen om decryptie door aanvallers die de gehele database of harddisk zouden stelen te kunnen voorkomen.
  • Deze techniek wordt ook gebruikt om data te anonimiseren.
  • Deze techniek wordt ook gebruikt om cryptografische bewijslasten te vormen wanneer er challenge-response technieken of digitale handtekeningen moeten worden gezet.
  • Het gebruik van deze techniek is fundamenteel voor onze digitale samenleving.
  • In lekentermen betekent dat simpelweg: ‘wij (de aanbieder) weten meestal ook niet wat het wachtwoord is en wat er als data staat opgeslagen’. Dit is volledig aan de verantwoordelijkheid van de eindgebruikers overgelaten.

De conclusie hieruit is dat de primaire functie van adequaat beveiligde communicatiediensten in alle gevallen zonder inbreuk in stand moet blijven. Daarbij past het niet om aan aanbieders van die diensten verplichtingen op te leggen die daaraan afbreuk zouden kunnen doen. Als het gaat om doorbreken van beveiligde communicatie dient dat veelal niet gezocht te worden bij de aanbieders van de communicatiediensten, maar bij aan de zijde van de gebruikers zelf, omdat die veelal aan zet zijn, zowel wanneer data versleuteld is als voor het ontsleutelen hun wachtwoorden.

De bevoegdheden van de diensten dienen dan ook primair gericht te worden op de doorbreking van de beveiliging op het niveau van te onderzoeken eindgebruikers en niet op die van de diensten waarvan ook talloze ‘niet targets’ beveiligd gebruik maken. Alleen in zoverre in het kader van het bevoegd gerichte aftappen ontsleutelde communicatie kan worden geleverd zouden aanbieders daartoe gehouden moeten zijn, maar dat is in het huidige wettelijke kader al geregeld.

EOF