De koelkasten zijn gehackt. Wat Kerckhoffs ons daarover kan leren.

Zes tijdloze securityprincipes voor een wereld van cloud, API's en verbonden apparaten.

De afgelopen tijd is het regelmatig in het nieuws: aanvallers zijn erin geslaagd om op afstand tonnen voedsel te laten bederven door de temperatuurinstellingen van koelinstallaties in Europese supermarkten te manipuleren.¹ Ook bij een Franse bloedblank probeerden aanvallers de temperatuur van koelinstallaties te verhogen. Gelukkig sloegen de alarmsystemen op tijd aan en kon worden voorkomen dat bloedproducten verloren gingen.²

Uit de eerste berichtgeving blijkt dat verschillende koelsystemen verouderde firmware gebruikten en dat sommige controllers nog met standaardwachtwoorden waren beveiligd. Dit zette me aan het denken. Hoe heeft dit kunnen gebeuren? Welke aannames zijn er gedaan bij het ontwerpen van deze systemen? Ik moest meteen denken aan iets wat ik ooit op de universiteit heb geleerd: het tweede principe van Auguste Kerckhoffs. Dit stelt dat de veiligheid van een systeem nooit afhankelijk mag zijn van het geheimhouden van het ontwerp of de werking ervan. Oftewel: geen security through obscurity.

Toen ik het werk van Auguste Kerckhoffs opnieuw bekeek, ontdekte ik een aantal verrassende inzichten. Kerckhoffs werd geboren in 1835 en publiceerde in 1883 zijn werk La Cryptographie Militaire.³ Daarin formuleerde hij zes principes voor het ontwerpen van veilige cryptosystemen. Hoewel zijn werk geschreven is vanuit een militaire context en de cryptografie van zijn tijd, zijn de onderliggende principes ruim 140 jaar later nog verrassend relevant. Ze gaan namelijk niet alleen over cryptografie, maar ook over het ontwerpen van systemen die praktisch bruikbaar moeten zijn. In dit artikel bespreek ik de zes principes en vertaal ik ze naar de moderne wereld van softwareontwikkeling, cloudarchitectuur en cybersecurity.

Praktisch onbreekbaar

Dat een cryptosysteem in de praktijk onbreekbaar moet zijn, klinkt nogal vanzelfsprekend. Toch gaat het nog regelmatig mis. Recentelijk kwam het Indiase bedrijf eMudhra in het nieuws omdat acht van hun intermediate CA-certificaten cryptografisch zwakke privésleutels bleken te hebben. Hoewel er volgens het bedrijf geen certificaten met deze sleutels zijn uitgegeven en er geen aanwijzingen zijn voor misbruik, was het incident ernstig genoeg dat klanten het vertrouwen verloren en de beurswaarde onderuit ging⁴. In de cybersecuritybranche komt vertrouwen te voet en vertrekt het te paard.

De beste manier om een systeem weerbaarder te maken is door bewezen cryptografische algoritmes en implementaties te gebruiken, in combinatie met sterke sleutels. Rolling your own cryptography is bijna nooit een goed idee. Cryptografie is een vakgebied waarin al eeuwenlang slimme mensen proberen elkaars werk te kraken. Een van mijn favoriete boeken, The Code Book⁵ van Simon Singh, beschrijft die eeuwige strijd tussen codemakers en codekrakers. Zodra er een nieuwe manier wordt bedacht om informatie te beveiligen, zijn er anderen die proberen deze te doorbreken.

Maar zelfs wanneer je zelf de juiste technologie gebruikt en alles zorgvuldig implementeert, ben je afhankelijk van de beveiliging van anderen. Als het bij een derde partij misgaat, kan dat ook gevolgen hebben voor jouw systemen. Hoe je daarmee omgaat, komt bij een van de volgende principes van Kerckhoffs aan bod.

Geen security through obscurity

Het tweede principe van Kerckhoffs is misschien wel zijn bekendste: de veiligheid van een systeem mag niet afhankelijk zijn van het geheimhouden van het ontwerp of de werking ervan. Ik moet meteen denken aan een van mijn favoriete boeken van vroeger: De Vijf en de geheime doorgang, waarin de detectives op zoek gaan naar, jawel, een geheime doorgang. Wanneer ze de doorgang vinden, blijkt deze te openen door simpelweg op een houten paneel te drukken. Van verdere beveiliging is geen sprake. The Goonies pakt dat toch iets beter aan met een skeletpiano!

De les die ik daaruit heb geleerd is dat simpelweg het verbergen van iets niet voldoende is om iets te beveiligen. Dit geldt precies zo voor IT-infrastructuur. Tegenwoordig is het relatief eenvoudig om netwerkpoorten te scannen of zwakke wachtwoorden te kraken. AI verlaagt de drempel verder, waardoor zelfs mensen met minder technische kennis dit kunnen proberen.

Dit is overigens geen pleidooi om alle informatie openbaar te maken. Het verbergen van het ontwerp van je systeem is nuttig om een deel van de kwaadwilligen buiten de deur te houden, en gedreven aanvallers extra werk op te leveren. Maar het mag nooit de basis van je beveiliging zijn. Als je moet kiezen tussen een slot of een houten paneel, kies dan het slot.

Beheerbare sleutels

Je hebt per ongeluk een geheim ingecheckt op Git. Iets wat veel developers weleens overkomt en waardoor het geheim per direct geen geheim meer is. Of de certificaatautoriteit die je gebruikt voor je HTTPS-certificaten blijkt privésleutels te hebben gegenereerd die extreem zwak zijn.

Kerckhoffs stelde dat een cryptografisch systeem zo ontworpen moet zijn dat de gebruikte sleutel eenvoudig te vervangen is, zonder dat daarvoor het hele systeem aangepast hoeft te worden. Een principe dat vandaag de dag nog steeds bijzonder relevant is. Want wat gebeurt er als een sleutel uitlekt of niet langer veilig blijkt te zijn?

Zet wachtwoorden, API-keys en andere geheimen niet in je sourcecode. Gebruik bijvoorbeeld een secrets manager om ze tijdens runtime beschikbaar te stellen. Zo kun je geheimen vervangen zonder daarvoor een nieuwe versie van je applicatie uit te brengen.

Maak je gebruik van AWS, kijk dan bijvoorbeeld naar AWS Secrets Manager. Hiermee kun je wachtwoorden en andere geheimen centraal beheren en automatisch laten roteren. AWS KMS is een andere nuttige dienst. Applicaties kunnen KMS gebruiken voor encryptie en decryptie zonder zelf toegang te hebben tot het onderliggende sleutelmateriaal.

Hoe zorgvuldig je ook met geheimen omgaat, je moet er rekening mee houden dat er ooit een geheim op straat komt te liggen. Juist dan is het belangrijk dat je deze eenvoudig én snel kunt vervangen.

Geschikt voor het communicatiekanaal, praktisch inzetbaar en eenvoudig in gebruik

In dit laatste stukje zal ik het vierde, vijfde en zesde principe gezamenlijk behandelen, vertaald naar de moderne tijd. Kerckhoffs legt veel nadruk op draagbaarheid. Dat was ongetwijfeld belangrijk op een modderig Frans slagveld in de negentiende eeuw, maar in de moderne tijd zijn daar eisen bijgekomen. Denk bijvoorbeeld aan eenvoudige installatie en beheer op afstand. Een veilig systeem moet namelijk niet alleen technisch goed in elkaar zitten, het moet ook passen bij de manier waarop het wordt gebruikt. Dat brengt me bij het vierde principe: een systeem moet geschikt zijn voor het communicatiekanaal waarvoor het bedoeld is.

Neem de koelkasten uit het begin van dit artikel. Het is handig als de fabrikant of het winkelmanagement op afstand de temperatuur kan uitlezen, bijvoorbeeld om te voorkomen dat voedsel bederft door een kapotte koelkast. Maar is het ook noodzakelijk dat iemand via het internet de temperatuur kan veranderen? Waarschijnlijk niet. Je kunt ervoor kiezen om het uitlezen op afstand toe te staan, terwijl het aanpassen van de temperatuur alleen met de hand mogelijk is. Daarmee beperk je de mogelijkheden voor een aanvaller aanzienlijk.

Een vergelijkbaar principe zie je bij de PSD2-standaard voor API's van banken. Daar wordt onderscheid gemaakt tussen API's waarmee je alleen informatie kunt uitlezen (AIS) en API's waarmee je daadwerkelijk transacties kunt uitvoeren (PIS). Voor beide gelden andere beveiligingseisen. Hoewel ik liever niet heb dat iemand van mijn koffieverslaving afweet, heb ik toch liever dat dan dat al mijn spaargeld naar een geheimzinnige cryptorekening wordt overgeschreven.

Maar dat is slechts een deel van het verhaal. Je kunt de koelkasten ook in een afgeschermd netwerk plaatsen, waarbij alleen het noodzakelijke verkeer wordt toegestaan. De fabrikant kan zo’n netwerk kant-en-klaar leveren in de vorm van een kleine gateway die de communicatie tussen de koelkasten en het internet beheert. Zo hoeft de gebruiker niet zelf na te denken over allerlei ingewikkelde netwerk- en beveiligingsinstellingen. De fabrikant heeft de juiste keuzes al gemaakt, wat een mooie illustratie is van het vijfde (praktisch inzetbaar) en zesde (eenvoudig in gebruik) principe.

Ook bij het instellen van wachtwoorden kan het ontwerp van de fabrikant een grote rol spelen. Een eenvoudig standaardwachtwoord lijkt handig, maar vormt een enorme zwakte in de beveiliging. Door gebruikers tijdens de installatie een uniek wachtwoord te laten instellen, of apparaten standaard van unieke inloggegevens te voorzien, voorkom je dat een aanvaller met één wachtwoord toegang kan krijgen tot een hele reeks apparaten.

Conclusie

De les die ik hieruit trek, is dat de beveiliging van een systeem staat of valt met fundamentele ontwerpkeuzes, zoals het correct implementeren van bewezen standaarden. Gebruiksgemak speelt daarbij een grote rol. Mensen kiezen over het algemeen de makkelijkste weg, ook als die niet de veiligste is. Bescherm je gebruikers tegen zichzelf door de juiste weg de enige weg te maken. Het bestuderen van de zes principes van Kerckhoffs heeft mijn geloof dat een goede beveiliging begint bij de basis alleen maar versterkt. Door al vanaf het begin rekening te houden met principes zoals least privilege en no security through obscurity kunnen een hoop problemen worden voorkomen.

Sommige van deze gedachten over goede verdediging zijn al millennia oud, in het Chinese boek De Kunst van het Oorlogvoeren⁶ uit de vijfde eeuw voor Christus verwoordde Sun Tzu het al treffend: “Reken er niet op dat de vijand niet komt, maar reken op onze gereedheid voor hem”.

[1] https://www.theguardian.com/world/2026/oct/17/who-hacked-frances-supermarket-fridges

[2] https://nos.nl/artikel/2638045-franse-bloedbanken-ontsnappen-aan-schade-na-cyberaanval-op-koelinstallaties

[3] https://www.petitcolas.net/kerckhoffs/

[4] https://tweakers.net/nieuws/253680/emudhra-stopt-certificaattak-na-blunder-met-zwakke-private-keys.html

[5] https://simonsingh.net/books/the-code-book/

[6] http://geschiedenisklas.nl/wp-content/uploads/2018/03/the-art-of-war-nederlands.pdf