Cryptografie: “Ik begrijp het niet, dus het is veilig”?

Cqure Platformblog

Cryptografie is onlosmakelijk verbonden met de beveiliging van digitale gegevens. Een veilige verbinding met een website (HTTPS) is gebouwd op cryptografie, veilige betalingen met de chip op je bankpas is gebaseerd op cryptografie, het veilig op afstand kunnen openen van je auto maakt gebruik van cryptografie en ook het inloggen op het bedrijfsnetwerk begint met cryptografie.

Helaas gaat het vaak verkeerd. Vorige week werd dat weer aangetoond op de 30e editie van het Chaos Communication Congres in Hamburg, de grootste hackersbijeenkomst van Europa. Hackers kunnen eenvoudig binnenlopen in zo’n 9000 appartementencomplexen in Wenen, doordat er gebruik wordt gemaakt van zwakke cryptografie. De private key van 1 op de 200 op internet gevonden TLS-certificaten is achterhaald door zwakheden in de implementatie, met name in routers. En zelfs het openbreken van bestanden die versleuteld waren met een (extern ontwikkelde) encryptie-tool van de Duitse veiligheidsdienst blijkt mogelijk.

Waarom blijven we het steeds verkeerd doen?

Onbegrijpelijke data is geen bewijs van veilige cryptografie

Cryptografie is iets magisch. Als er iets versleuteld of ondertekend moet worden begin je met (meestal) begrijpelijke data, stop je de data in een veilige cryptografisch functie en vervolgens heb je onbegrijpelijke data dat ofwel de versleutelde data ofwel een handtekening is. Kort gezegd: goede cryptologie maakt van begrijpelijke data iets onbegrijpelijks.

Het probleem begint meestal op het moment dat de redenering omgedraaid wordt: er komt onbegrijpelijke data uit een functie, dus de gebruikte cryptografie is veilig. Dit is niet correct. Maar helaas is dit wel de redenering die meestal wordt toegepast op het moment dat bedrijven hun gegevens of communicatie beveiligen met behulp van cryptografie.

Het gaat fout bij maatwerk

Het zijn niet alleen kleinere bedrijven en organisaties die deze fout begaan. Daar gaat het vaak juist goed omdat zij gebruik maken van standaardfunctionaliteit die hen geboden wordt door de softwarepakketten of systemen waar zij gebruik van maken. Zij maken dan gebruik van bijvoorbeeld Active Directory voor gebruikersauthenticatie, zetten een wachtwoord op een Word-bestand en gebruiken Truecrypt voor bestandsversleuteling. Dit zijn goed doordachte en geteste pakketten die snel aangepast worden mocht er toch onverhoopt een zwakheid gevonden worden.


Het gaat verkeerd op het moment dat er iets meer nodig is dan deze standaardfunctionaliteit. Naar mijn idee zijn het juist daarom vaak de grotere bedrijven die de fout in gaan met cryptografie. Bijvoorbeeld in het geval dat een bedrijf op een geautomatiseerde en veilige wijze veel en vaak gegevens moet uitwisselen (bijvoorbeeld betalingstransacties, sturingsinformatie in bedrijven), op een geautomatiseerde wijze persoonsgegevens moet verwerken en opslaan (webwinkels, zorgdossiers), of toegang tot een object moet beveiligen (gebouwentoegang, elektronische autosleutels).

Op dat moment moet er maatwerk geleverd worden en dus iets nieuws ontwikkeld worden. In veel gevallen wordt de IT-ontwikkelaar die ook iets met getallen kan erbij geroepen. Varend op zijn eigen gevoel ontwikkelt hij een systeem waarin de gegevens versleuteld en ondertekend lijken te zijn. Het ziet er allemaal ingewikkeld uit, en de projectmanager is allang blij dat het moeilijke en vertragende onderdeel beveiliging afgehandeld is.

Jaren later, als het systeem flink uitgegroeid is, en er miljoenen euro’s aan waarde in omgaat, blijkt het systeem toch lek. In veel gevallen is zelfgebouwde of slecht geïmplementeerde cryptografie de oorzaak van het falen. Cryptografie waarbij het uitgangspunt was: het ziet er ingewikkeld uit, dus het is veilig.

Enkele uitgangspunten voor het correct toepassen van cryptografie

Helaas is er geen sluitende methode om systemen te beveiligen met behulp van cryptografie. Maar gelukkig kan ik wel enkele uitgangspunten meegeven tot een voldoende veilig systeem te komen.

Om te beginnen: maak altijd een goede analyse welke beveiligingseisen er aan het systeem gesteld worden, en beoordeel of de gekozen methoden en de uiteindelijke toepassing van cryptografie die eisen volledig invult. Ik zie vaak – zo niet meestal – dat de gekozen oplossing het eigenlijke probleem niet oplost.

Laat cryptografie daarna niet over aan de slimme jongens in het bedrijf. De kans is groot dat zij zelf iets gaan verzinnen wat er ingewikkeld uit ziet, maar niet veilig is. Maak in plaats daarvan alleen gebruik van algemeen geaccepteerde methoden en parameters om data te versleutelen of te ondertekenen.

Gebruik ook standaardcomponenten om deze methoden uit te voeren. In de meeste gevallen wordt niet de cryptografische methode gekraakt, maar wordt er gebruik gemaakt van implementatiefouten. Laat ontwikkelaars daarom altijd gebruik maken van standaardmodules zoals de door het besturingssysteem aangeboden security functies of standaard crypto-bibliotheken voor programmeertalen.

Realiseer je bovendien dat cryptografie geen eenmalige oplossing is. Er zijn regelmatig nieuwe ontwikkelingen die cryptografische methoden verzwakken of implementatiefouten in de standaardcomponenten ontdekken. Zorg dus voor een organisatie die snel verbeteringen kan doorvoeren en adequaat kan reageren op ontwikkelingen die de beveiliging verzwakken.

Maar bovenal: als het er ingewikkeld uitziet, en je het zelf allemaal niet snapt, ga er niet van uit dat het dan veilig is, maar vraag hulp van een expert om dat te beoordelen.