Ius mentis Homepage | Categorieën | Lijst A-Z | Willekeurig artikel | Herpubliceren? | Over deze site | Blog | Contact
 

Betrouwbaar beveiligd - wanneer is iets te vertrouwen

Beveiligingsprogramma's zijn er tegenwoordig te kust en te keur. Folders vermelden de meest exotische features en beloven optimale beveiliging tegen alle mogelijke kwaadaardige aanvallers. Maar hoe weet de gebruiker nu of een beveiligingsprogramma werkelijk betrouwbaar is? En wat is nu echt belangrijk bij het kiezen van een encryptie-systeem?

Inhoudsopgave

Zichtbaar vertrouwen

Wie een tekstverwerker koopt, zal al vrij snel doorhebben of het programma doet wat het zegt. Als de knop ``Tekst cursief'' de tekst in een vet lettertype zet, of opgeslagen bestanden kunnen niet meer worden teruggelezen, kan het programma direct de vuilnisbak in. Subtielere fouten, zoals een spreadsheet-programma dat verkeerd afrondt, komen soms pas aan het licht na langdurig zoeken en narekenen. Dit zijn echter vrijwel allemaal fouten die de gebruiker onder normale omstandigheden tegen kan komen en ook wel kan detecteren. Bij beveiligingsprogramma's ligt dat anders.

Een programma dat belooft bestanden onkraakbaar te versleutelen, slaagt er meestal wel in om na invoer van een wachtwoord een bestand te produceren dat er uit ziet als willekeurige tekens. De gebruiker kan hier naar kijken en constateren dat als hij het wachtwoord opnieuw invoert, het oorspronkelijke bericht teruggevonden wordt. Het programma werkt dus zoals in de handleiding staat. Echter: hoe kan de gebruiker nu nagaan of de gebruikte methode om het bestand te versleutelen werkelijk ``onkraakbaar'' is? Er zijn zo veel factoren die van grote invloed zijn op de betrouwbaarheid van een beveiligingsprogramma.

Huisvlijt

Een veel voorkomend verschijnsel bij beveiligings-software is het gebruik van zelf ontwikkelde encryptie-algoritmen. Er zijn vele bekende encryptie-algoritmen, zoals DES (Engelstalig), IDEA, Blowfish of RSA (Engelstalig), die openbaar zijn en die iedereen kan gebruiken in zijn programma's (mogelijk tegen betaling van een octrooilicentie). Deze algoritmen zijn door wiskundigen en cryptografische experts gedurende vele jaren getest op zwakheden. Soms worden er ook inderdaad fouten gevonden in het algoritme. De ontdekker publiceert deze dan, en de ontwikkelaars kunnen dit gebruiken om het algoritme te verbeteren.

Zelf ontwikkelde algoritmen, die vaak ook nog eens bedrijfsgeheimen zijn, zijn veel minder getest. Vaak kan iemand die het algoritme wil controleren, alleen maar kijken naar de invoer en het resulterende versleutelde bestand, niet naar het algoritme zelf. Dit maakt testen een erg lastige zaak. Toch zijn veel encryptie-algoritmen uit bekende programma's op deze manier gekraakt. Dit zegt toch wel wat over hun (on)veiligheid.

Waarom gebruiken veel programma's dan toch eigen algoritmen? Een belangrijke reden is snelheid. Het is niet eenvoudig om een standaard-bibliotheek te integreren in een zelf ontwikkeld programma. De interface is vaak net iets anders dan wat het eigen programma gebruikt. Het is dan vaak verleidelijk om zelf iets te schrijven dat precies werkt zoals de programmeur wil. Soms kost het gebruik van een algoritme ook geld, omdat licentie-rechten moeten worden betaald. Zelf het algoritme nabouwen is dan een handige manier om dit geld uit te sparen.

Het schrijven van cryptografische software is echter geen eenvoudige zaak. Zo had Netscape in versie 2.0 een fout gemaakt bij de routines die sessiesleutels genereerde. Deze sleutels hadden willekeurig gekozen moeten zijn, maar door een minieme fout waren slechts een klein aantal sleutels mogelijk. Het was toen eenvoudig om de encryptie te kraken door eenvoudigweg alle sleutels uit te proberen. Aangezien het hier de SSL-encryptie betrof, waarmee credit-card en andere persoonlijke gegevens naar Websites worden gestuurd, had deze fout ernstige consequenties kunnen hebben. Gelukkig werd de fout tijdig ontdekt en hersteld.

Het gebruik van standaard-algoritmen is daarom een goede indicator van de betrouwbaarheid van een programma. Er bestaat nog steeds de kans op fouten bij de implementatie, maar de risico's bij een zelfverzonnen algoritme zijn vele malen groter.

Kraak ons!

Een interessante reclametruc is het opzetten van een server waar mensen op in mogen breken, of het aanbieden van een versleuteld bericht dat gekraakt moet worden. Vaak gaat dit vergezeld van een financi´┐Żle beloning. Wanneer na een aantal maanden niemand er in is geslaagd om op de server in te breken, of het bericht te ontcijferen, kan het bedrijf dit feit adverteren en zo het doen voorkomen alsof hun produkt veilig is.

Een dergelijke test bewijst echter niets. Vaak is de beloning zo laag dat mensen het alleen een keer voor de lol proberen, en er niet veel tijd aan willen besteden. Bruce Schneier, een bekend cryptograaf en auteur van diverse encryptie-algoritmen, schreef al dat een cryptograaf per dag meestal meer betaald krijgt dan de gemiddelde beloning, dus het is voor hem weinig interessant om een serieuze poging te doen. Bovendien is het best mogelijk dat onder andere omstandigheden wel eenvoudig mogelijk is om het systeem te kraken (bijvoorbeeld door honderd berichten met elkaar te vergelijken, of wanneer een stukje van de oorspronkelijke tekst bekend is). Zo'n kraaktest geeft dan alleen een vals idee van veiligheid.

De firma RSADSI, die de rechten heeft op het RSA-algoritme, organiseert al jaren een competitie waarin berichten die met RSA versleuteld zijn, gekraakt moeten worden. Deze competitie is echter niet bedoeld om aan te tonen dat RSA onveilig is, maar meer om de stand van de techniek te laten zien. In februari 1999 werd een 465-bits RSA sleutel gekraakt in ongeveer zes weken. In 1978, toen RSA net uitgevonden was, verwachtte men dat 256 bits al absoluut onkraakbaar zouden zijn. Nu is 1024 bits toch wel de minimum sleutellengte.

Distributed Computing Technologies, ofwel distributed.net, organiseert op Internet kraak-competities waaraan iedereen kan meedoen. De gebruiker installeert dan een programma op zijn computer dat in de achtergrond probeert een bericht te ontsleutelen door simpelweg een groot aantal sleutels uit te proberen. Een centrale server zorgt er voor dat iedereen andere sleutels uitprobeert. Als nu maar genoeg mensen meedoen, zal de sleutel vroeg of laat worden gevonden. In januari 1999 werd op deze manier een met DES versleuteld bericht in minder dan één dag gekraakt.

Het doel van deze competitie is te laten zien dat beperkte sleutellengtes (zoals de 56-bits sleutel van DES) onveilig zijn. Als een groep Internet-gebruikers in hun vrije tijd al het bericht kan kraken, dan kan een organisatie met één grote computer het nog veel sneller. En om dit te bewijzen bouwde de Electronic Frontier Foundation in juli 1998 een computer met speciale chips die er in slaagde om in slechts 56 uur een ander DES-bericht te ontsleutelen. In januari hielp deze machine mee bij het in 22 uur kraken van een DES-bericht.

De sleutellengte is van belang bij het bepalen van de betrouwbaarheid, maar minder dan het gebruikte algoritme. Veel Amerikaanse software gebruikt korte sleutels, vanwege exportrestricties op software die lange sleutels gebruikt. De toegestane sleutellengte (56 bits op dit moment) is zo kort dat al deze software in principe als onveilig beschouwd moet worden.

Open Source

Een bekend fenomeen onder Linux, maar de laatste tijd ook steeds vaker voor Windows, is het begrip Open Source. Dit houdt in dat de broncode voor software vrij beschikbaar is voor iedereen. Gebruikers mogen deze aanpassen om zo het programma te verbeteren of uit te breiden. Een voorbeeld is Netscape, of natuurlijk het Linux-besturingssysteem zelf. Voor cryptografische software is open source ook van belang, maar vanwege een andere reden.

Aan de hand van een versleuteld bestand is meestal weinig te achterhalen. Wie kennis heeft van het algoritme en de implementatie er van, kan al vaak heel wat sneller het systeem kraken. Veel bedrijven gebruiken dit als argument om het algoritme en de broncode geheim te houden. Hackers slagen er echter maar al te vaak in om deze toch te achterhalen, en kunnen dan deze informatie gebruiken om het systeem te kraken en zo gegevens te stelen. Tegelijk is het voor normale gebruikers onmogelijk om te controleren of het systeem veilig is.

Bij een open source programma is de broncode voor iedereen beschikbaar. Alhoewel nu een hacker nog steeds het systeem kan kraken, is het nu ook mogelijk voor een goedwillende programmeur om de fout te vinden en deze te verbeteren, zodat de kraak onmogelijk wordt. Hij kan deze verbetering dan verspreiden en zo het systeem veiliger maken. Het encryptie-programma PGP was een van de eerste beveiligingsprogramma's dat van dit systeem gebruik maakte. Dankzij vele tientallen programmeurs die fouten hebben verbeterd en nieuwe functionaliteit hebben geschreven, is het nu een van de veiligste programma's ter wereld.

Dat een programma Open Source is, betekent niet automatisch dat het veilig is, maar de kans dat er (opzettelijk of niet) een fout in zit, is wel veel kleiner.

Digitale handtekeningen

Met behulp van een digitale handtekening kan een onvervalsbare code worden toegevoegd aan een elektronisch bestand. Deze code is uniek voor de persoon die hem plaatste en voor het bestand waar hij bij hoort. De ontvanger van het bestand kan nu met behulp van een certificaat controleren of het bestand gewijzigd is en wie de handtekening heeft gezet. Deze techniek is dus prima geschikt om software te beschermen. Een firma kan een update voorzien van zijn digitale handtekening, zodat gebruikers weten dat ze een echte update downloaden en geen vervalsing of een vermomde Back Orifice server.

Microsoft gebruikt digitale handtekeningen in haar Authenticode systeem, waarmee ActiveX controls beveiligd worden. Een ActiveX control kan alles wat een normale Windows applicatie ook kan (van bestanden openen tot het systeem herstarten of de harddisk formatteren), maar door de digitale handtekening kan de gebruiker de eigenaar van de control identificeren en weet hij dus wie hij kan aanspreken als de control niet doet wat de bedoeling is. Een software-ontwikkelaar krijgt alleen een certificaat als hij belooft geen kwaadaardige code in de control op te nemen.

In de praktijk blijkt dit echter niet te werken zoals de bedoeling is. Fred McClain schreef een control die de computer van de gebruiker automatisch herstartte, en kreeg hiervoor zonder problemen een certificaat. Erger nog, vaak blijken certificaten niet te kloppen omdat ze door de verkeerde instantie zijn uitgegeven of omdat er inmiddels een nieuwe versie van de ActiveX control uit is die nog niet gesigneerd is. Veel installatie-instructies raden de gebruiker daarom aan om waarschuwingen over foute handtekeningen maar te negeren! Het moge duidelijk zijn dat hierdoor de veiligheid die een digitale handtekening biedt tot vrijwel nul wordt gereduceerd.

Te veel vertrouwen

Er is echter nog een belangrijke factor die bepalend is voor de veiligheid van het systeem. Dit is de gebruiker zelf. Het is noodzakelijk dat deze zich goed realiseert waar een programma hem precies tegen beschermt en hoe goed deze beveiliging is. Een goed voorbeeld van dit probleem is het privacy-lek dat Richard Smith in april 1999 ontdekte in de Anonymizer.

De Anonymizer is een service die mensen in de gelegenheid stelt om anoniem te surfen. Hij functioneert als proxy server, die Webpagina's en bestanden ophaalt zonder daarbij aan de Webserver te melden vanaf welk adres de gebruiker bezig is. De Webserver ziet dus alleen maar het IP-adres van de Anonymizer. Vervolgens stuurt hij de pagina's door naar de gebruiker. De fout die Smith ontdekte, was dat een Webpagina met een bepaald stukje Javascript code toch het werkelijke IP-adres van de gebruiker kon achterhalen.

Dit was strikt genomen geen fout in de Anonymizer. Het is onmogelijk voor een dergelijke service om alle scripts in elke pagina te controleren op malafide trucs. De enige oplossing zou het automatisch filteren zijn van alle scripts, en dat zou voor veel mensen niet acceptabel zijn, omdat dan ook de nuttige scripts weggehaald worden. Toch bleek dat veel mensen er van uit gingen dat zij volledig anoniem zouden zijn als zij de Anonymizer gebruikten. Zij hadden daarom geen verdere maatregelen genomen door bijvoorbeeld Javascript uit te zetten of het automatisch versturen van e-mail door hun browser te blokkeren.

Ook de al eerder genoemde digitale handtekeningen kunnen tot te veel vertrouwen leiden. Als een programma voorzien is van een digitale handtekening, wil dat nog niet zeggen dat het betrouwbaar is of dat er werkelijk aktie kan worden ondernomen tegen de auteur (zoals Verisign, een bedrijf dat certificaten uitgeeft, beweert). Ook bijvoorbeeld het gebruik van een SSL- of andere versleutelde verbinding biedt niet automatisch voldoende veiligheid; de gebruiker moet het bedrijf aan de andere kant van de verbinding nog steeds vertrouwen.

Conclusie

Er zijn allerlei technieken, programma's en protocollen waarmee surfen, e-mailen en andere Internet-aktiviteiten te beveiligen zijn. Deze technieken zijn echter niet meer dan hulpmiddelen waarmee een gebruiker zijn vertrouwen in het systeem kan vergroten. Dit bieden van vertrouwen is de belangrijkste taak van een beveiligingsprogramma.

Wie dus een dergelijk programma wil proberen, moet letten op een aantal factoren die van invloed zijn op de betrouwbaarheid er van. De hier genoemde bekende algoritmen, grote sleutellengtes en vrij beschikbare broncode zijn zulke factoren. Ook een digitale handtekening kan extra zekerheid bieden, maar momenteel zijn de mogelijkheden hiervoor nogal beperkt.

De belangrijkste factor blijft echter kennis van het programma zelf. Het is van het grootste belang om te weten wat een programma precies doet, waar het tegen beschermt en hoe goed deze bescherming is. De gebruiker moet -- zeker bij open source programma's -- zelf regelmatig controleren of er fouten gevonden zijn en er voor zorgen dat hij de nieuwste versie gebruikt. Ook moet hij voor zichzelf bepalen welke bedreigingen voor hem spelen, en op basis daarvan kijken welk programma hem hiertegen kan beschermen.

Gerelateerde artikelen

Gespecialiseerd advies nodig?

Heeft u na het lezen van dit artikel nog vragen, of zit u met een juridisch probleem waar u advies over wilt? Neem dan contact op met ICT-jurist Arnoud Engelfriet, auteur van dit artikel.

© Arnoud Engelfriet. Dit werk mag vrij worden verspreid en gepubliceerd zoals bepaald in de licentievoorwaarden.

Laatste wijziging:
16 december 2016