Bij de beveiliging van it-voorzieningen is sprake van een ratrace, waarbij op het ene moment het hackersgilde aan de winnende hand lijkt en op het andere moment de beveiligers. De nadruk ligt nog te veel op het afsluiten van de toegangspoorten. We moeten terug naar de bron en dat impliceert het beveiligen van softwarecode. Een nieuwe methode, de Blurry Box-technologie, gebaseerd op het oude principe dat het geheim in de sleutel ligt, heeft zich inmiddels in veldproeven bewezen.
De Blurry Box-technologie is gebaseerd op de Wet van Kerckhoffs. Auguste Kerckhoffs was een negentiende eeuwse Nederlandse linguïst en cryptograaf die, werkzaam in Parijs, onder de titel La Cryptographie Militaire een reeks aanbevelingen op papier had gezet voor het beveiligen van de toenmalige cryptografische systemen. De belangrijkste van zijn stellingen is dat het geheim in de sleutel zit en niet in het versleutelingsysteem.
In alle gangbare oplossingen voor softwarebeveiliging wordt voorbij gegaan aan de Wet van Kerckhoffs. De afscherming is geheel gericht op de beveiligingmethodiek. De hacker met kennis daarvan is hard op weg om door de beveiligingslinie heen te breken. In theorie bestaan er wel mogelijkheden om het principe van Kerckhoffs op software los te laten. In de praktijk blijken die te veel systeembronnen te gebruiken en tasten daardoor de prestaties van een softwaretoepassing aan. Zo is bijvoorbeeld Codemoving, een techniek die een beschermd programma laat uitvoeren vanuit een in hardware verpakte sleutel (dongle) eveneens te traag voor operationeel gebruik bij complexe applicaties.
Technologie
De Burry Box-technologie, een gezamenlijke ontwikkeling van het Duitse onderzoeksinstituut FZI (Forschungszentrum Informatik), het Karlsruhe Institute for Technology en mijn werkgever Wibu-Systems, voldoet wel aan het principe van Kerckhoffs. De gebruiker van Blurry Box gaat er dus vanuit dat potentiële hackers bekend zijn met de methode en tevens inzicht hebben in de te beschermen software. Die kunnen ze gebruiken en de regels code bekijken in tekstvorm. Blurry Box maakt het evenwel onmogelijk statische code te analyseren, terwijl door het toevoegen van extra beschermlagen analyse van dynamische code wordt voorkomen.
Het concept van de Blurry Box-technologie vindt zijn oorsprong in het wetenschappelijke onderzoek naar it-criminaliteit en experimenten op het gebied van softwareontwikkeling gedurende de afgelopen twintig jaar. Uit die verkenningen komen drie opmerkelijke conclusies.
– Gangbare software is zo complex is dat niemand de gehele code kan doorgronden door het programma simpelweg te activeren. Een doorsnee gebruiker past slechts 10 tot 20 procent van de functionaliteit toe, terwijl een power user 30 tot 50 procent activeert en interne kwaliteitscontroleurs 80 tot 90 procent van de code inzien.
– Een hacker beschikt meestal over aanzienlijke kennis van het feitelijke hackingproces. Daardoor is hij/zij in staat verborgen code te detecteren, waarden in terugkeeropdrachten te wijzigen, delen van de code te combineren, alsmede code te lezen uit of terug te plaatsen in het werkgeheugen van de computer.
– Een hacker kent niet het uiteindelijke doel van de software en de interne structuur.
Deze conclusies en het inzicht dat hackers over weinig, specifiek materiegerichte expertise beschikken, maken het mogelijk software te beschermen zonder een deel van de uitvoerbare code als referentie in een externe dongle onder te brengen.
Applicatie in functionele blokken
De Blurry Box-technologie combineert uiteenlopende beveiligingsmethoden. Elke applicatie laat zich onderverdelen in blokken met bepaalde functiegroepen. Een functieblok f[i] heeft de invoerparameter pln[i] en de uitvoer parameter pOut[i]. Afhankelijk van pln[i] zal het functieblok als resultaat pOut[i] opleveren. In het Blurry Box-proces, zijn de afzonderlijke functieblokken vermenigvuldigd naar verschillende varianten. Zo is functie blok f[i] samengesteld uit de blokken f[i,1] tot f[i,m]. De functieblokken f[i,j] zijn toegankelijk via een gebundelde functie fw[i], afhankelijk van de toegangparameter pln [i]. De uitvoer van de variant f[i,j] wordt teruggegeven als waarde pOut[i], hetgeen impliceert dat gedurende elke cyclus een minimale hoeveelheid code wordt uitgevoerd onder besturing van de gekozen bundel van parameters.
Een voor de hand liggende truc om de varianten te omzeilen, is te gaan knoeien met de bundelfunctie fw[i], zodat alleen een enkelvoudige variant per keer wordt uitgevoerd. Om die aanvalsmogelijkheid uit te sluiten, modificeert Blurry Box de varianten van een functieblok zodanig, dat ze alleen met de correcte reeks parameters kunnen werken. Een hacker zonder kennis van de interne structuur is niet in staat andere, onbekende varianten of de originele functieblokken gemakkelijk te herleiden uit enkelvoudige of zelfs meervoudige varianten.
Wijzigingen aan de code resulteren in varianten die incorrecte uitvoer leveren aan parameters die niet in hun bereik liggen. Zonder de kennis van een specialist heeft een hacker geen middelen om de expres ingebouwde fout te corrigeren. De onbekende variant is om die reden niet te vervangen door een bekende versie.
Elke enkelvoudige variant is volledig versleuteld met een sleutel die veilig is opgeborgen op een dongle. Die is ook voorzien van een application programm interface (api)-functie, waarmee versleutelde informatie op de dongle is te laden en daarbinnen is te decoderen. Die versie van de code wordt via de dongle-api teruggegeven en vervolgens geactiveerd als een uitvoerbare code variant. Zonder een dongle met de correcte sleutel is geen enkele variant te decoderen. Het encryptie proces verloopt volgens de advanced encryption standard (aes). Die werkt met willekeurig gekozen waarden in het verwerkingsproces van de computer. Die waarden representeren blokken met dezelfde inhoud in verschillend cijferschrift .
Via valluik naar ’booby trap’
Om te voorkomen dat aanvallers alle varianten op de dongle ontsleutelen zonder dat de applicatie correct activeert, zijn er in het systeem verschillende valluiken ingebouwd. Deze bestaan uit versleutelde varianten die de betreffende sleutel als ongeldig verklaren als ze door de dongle worden gedecodeerd. Omdat die valluiken ook moeten werken bij aanvallers die de betreffende broncode proberen te analyseren, bevat die code links die direct leiden naar ’booby-trapped’ blokken. In normale omstandigheden worden die nooit geopend. Ze worden immers alleen benaderd door varianten die niet opstarten wanneer de applicatie normaal draait.
Code moving, oftewel het activeren van softwarecode op een dongle, is meestal geen voor de hand liggende keuze; het maakt de beveiligde applicatie te traag. Ook het laten draaien van een stukje, maar wel vitaal deel, van de code op de dongle is geen optie. De complexiteit maakt die aanpak niet zinvol. Een goed alternatief is dus alleen code op de dongle te laten draaien die de processtappen uit een selectie van de functieblokvarianten uitvoert. Dat neemt niet veel tijd in beslag, maar is wel essentieel voor het oplossen van de beveiligingspuzzel. De selectie en implementatie van de betreffende variantencode kan automatisch verlopen zonder betrokkenheid van de oorspronkelijke ontwikkelaar van de software.
Het proces werkt als volgt: de index van de bundelfunctie (i) en de relevante parameter pln[i] worden overgebracht naar de dongle. Daarin vinden de berekeningen op de varianten plaats en het resultaat wordt teruggestuurd (j). Op deze manier is het voor hackers onmogelijk te voorspellen welke varianten (of valluiken) al dan niet zijn gekozen – ook al zijn het wel bekende met de geldige parameterreeks – tenzij de code draait met de juiste parameters.
De volgorde waarin de blokken worden gedecodeerd in operationele omstandigheden is niet willekeurig gekozen. Een blok wordt altijd gevolgd door een specifieke selectie uit de andere blokken. In het geheugen van de dongle onderscheidt Blurry Box een geldige en een niet geldige volgorde. In het laatste geval wordt de operatie afgesloten.
Validiteit Blurry Box-technology
Hackers zijn experts in het gebruik van verschillende aanvalsmethoden. Het ontbreekt hen evenwel aan kennis omtrent de interne structuur en werking van de applicatie. Dit gebrek aan inzicht vormt de ruggengraat van het innoverende beveiligingsproces ontwikkeld door FZI en Karlsruhe Institute for Technology. In veldproeven is aangetoond dat alleen aanvallen die vanwege hun geaardheid niet zijn te voorkomen, succesvol waren. Alle vormen van hackeraanvallen zijn uitgeprobeerd, inclusief die waarbij de aanvallers op de hoogte waren van de versleutelingmethode. Door de overeenstemming met het principe van Kerckhoffs is de methode onafhankelijk te testen en te valideren. Bij strikt geheimgehouden beveiligingsmethoden is dat niet mogelijk.
Marcel Hartgerink , manager Wibu-Systems Benelux
Een hele lap tekst waar ik dan uiteindelijk enkele overpeinzingen niet in tegenkom.
1. Fysiek beveiligen
Het is nu eenmaal alweer een oude wetmatigheid dat het beveiligen en hacken gewoon een damspelletje is. Zo moet je het overdrachtelijk bezien dan ook gewoon benaderen. In de praktijk heb ik me vaak verbaasd waarom iedereen zo enorm met softwarecodering bezig is wat beveiliging betreft terwijl ik altijd heb gezien dat fysieke beveiliging telkens weer het sterkst werkt.
2 Protocol
Wat ik in de praktijk, ook verbazingwekken, of misschien ook weer niet, ook telkens weer tegen kom is dat organisaties wat beveiliging betreft, op verschillende niveaus, helemaal niet eens een eenduidig protocol hebben.
Ik maak me daar wat minder druk om omdat ik namelijk de rekeningen van al die grootschalige incidenten niet hoef te betalen. Het zet mij hoogstens aan het denken.
Ook de beschreven methode is symptoombestrijding. Het werkelijke probleem, en dus ook de oplossing, ligt op een hoger niveau: de complexiteit van de software. Omdat “niemand” meer weet welke code waartoe dient kan ook “niemand” het probleem oplossen. We hebben echter te maken met door mensen gemaakte techniek, dus moet het probleem ook door mensen opgelost kunnen. Maar wel aan de bron, om uit te sluiten dat het probleem opnieuw optreedt.
Tot zover de filosofie van de oplossing. Nu de praktijk. We kunnen in principe kiezen uit vier methodes. 1. Het bestrijden van het symptoom door de complexiteit zodanig te vergroten dat (voorlopig!) “niemand” de methode kan kan ontcijferen. 2. Het bestrijden van het symptoom door een technische oplossing te bouwen die transparant maakt wat de techniek doet, zowel de gewenste als de ongewenste fucties. 3. De huidige techniek als te complex, niet te repareren, onveilig, gevaarlijk, etc. te beschouwen en derhalve niet meer “zomaar” te gebruiken. Dit is/wordt maatschappelijk vanuit de gebruiker gezien steeds meer noodzakelijk en zal vroeger of later tot oplossing 4: uithuilen en opnieuw beginnen…
Waarom dus niet meteen begonnen met een maatschappelijk gezien intrinsiek veilig systeem te ONTWERPEN en vervolgens de “code te krassen”. Het is wel de wereld van de softwaremakers op z’n kop. Maar na bijna 50 jaar wordt het toch wel tijd om vanuit de maatschappelijke functie van informatievoorziening een ICT infrastructuur te ontwerpen die functioneel voldoet. Horizon 20-20 heeft ruim voldoende geld en andere faciliteiten beschikbaar. En anders iedere, niet alleen de NL overheid wel, met miljarden kostende halve of hele ICT-project mislukkingen…
De belanghebbenden zijn wij, de gebruikers, de burgers, bedrijven en overheden. Wij zijn ook de betalers. En wie betaalt bepaalt. Of niet soms?
@NumoQuest,
Het is zeker zo dat je weinig hebt aan een goede softwarematige beveiliging waneer je server in het voor iedereen bereikbare poetshok staat.
Echter Marcel richt zich veel meer op de softwarematige beveiling.
Mischien moeten we met zijn allen maar eens wat social-hacking annekdotes delen om aan te geven dat er kwa beveiliging nog een heel onontgonnen gebied ligt.
Stellen dat oplossing niet gebaseerd is op principe van ‘security through obscurity’ lijkt me niet helemaal te kloppen, tenminste niet als de ruggegraat van beveiliging gebaseerd is op gebrek aan kennis van interne werking. Verder lijkt gebruik van dongles me een stap terug als ik kijk naar de moderne delivery modellen.
Het lijkt dan ook meer om de IP bescherming van (closed source) softwareleveranciers te gaan dan de belangen van de klant. Ik ben nieuwsgierig wat er bedoeld wordt met aanvallen die door hun geaardheid wel succesvol waren, vervangbaarheid is daarom nog belangrijker dan principes van Kerckhoff.
Verlies zal dus in het ontwerp opgenomen moeten worden om te kunnen acteren op de bedreigingen want dongles houden nog weleens (platform) migraties tegen. Een andere vraag die bij opkomt is of Kerckhoffs’ principes dan ook niet wat achterhaald zijn, rekenkracht in de cloud is tenslotte niet te vergelijken met de mogelijkheden van twee eeuwen geleden.
@Marcel Hartgerink: Heb je ook een wetenschapplijke publicatie waarin dit principe bechreven is ? ( dit is een ander principe van Keckhoff: het gehele cryptosysteem openbaar maken behalve de sleutel )
@Q: De wetenschappelijke publicatie van het onderzoek wordt deze zomer verwacht. De websites van de onderzoeksinstituten zijn http://www.fzi.de/en/research/ en
http://www.kit.edu/research/index.php.