Enkele jaren geleden waren de servers van mijn favoriete online game een paar dagen uitgevallen en ik was al bang dat mijn in-game personage verloren en dood zou zijn met al zijn prestaties. Gelukkig hebben ze hun problemen opgelost en enkele dagen later stond alles weer online. Ik wilde voorbereid zijn op het volgende incident van dit type, dus ik logde in op hun website en maakte een screenshot van alle eigenschappen van mijn personage.
Even was ik blij. De volgende keer – zelfs als alle gegevens verloren waren – kon ik bewijzen wat ik had gewonnen en zou ik al mijn spullen terugkrijgen. Toen keek ik naar mijn screenshot en realiseerde me dat ik het even gemakkelijk kon aanpassen om nog betere in-game items te krijgen. Dus eigenlijk was het waardeloos. Zelf digitaal ondertekenen zou daar geen verbetering in brengen.
Dit scenario is niet beperkt tot online gamen. In staat zijn om te bewijzen dat een bestelling is geplaatst, een overtreding is begaan of een taak is vervuld, lijkt de moeite waard om enige algemene overweging te investeren.
Zo’n screenshot kun je natuurlijk niet zelf maken en ondertekenen. Men heeft de hulp nodig van een betrouwbare derde partij, maar vaak is de kwestie te triviaal om een advocaat uit de ‘echte wereld’ te betrekken of zelfs maar te betalen. Je eerste gedachte zou kunnen zijn om te controleren of sommige webarchiveringssites zoals archive.org toevallig een kopie van die pagina zouden kunnen hebben. Vaak doen ze dat niet. En zelfs als dat zo was, hadden ze nooit toegang kunnen krijgen tot de onderdelen die zijn beveiligd door in te loggen.
Geen enkele automatische tool kan de stappen van het inlogproces beheersen en als de website-eigenaren overwegen een captcha te gebruiken, is er weinig hoop dat een programma dit ooit zou kunnen omzeilen. Dit moet met de hand en met een webbrowser worden gedaan. Dus sommige mensen proberen plug-ins te gebruiken om alle gegevens die vanaf de server worden verzonden op te slaan en digitaal te ondertekenen.
Nogmaals, dit is niet de oplossing. Het is relatief eenvoudig om DNS of routering op uw machine te manipuleren om een andere computer of zelfs een virtuele machine de rol van “de server” te laten spelen. Browsers beschermen tegen dit soort fraude door gebruik te maken van SSL en certificaten, maar dit is alleen van toepassing op versleuteld verkeer en het installeren van uw eigen “root-certificaat” om man-in-the-middle-manipulaties mogelijk te maken, is gebruikelijk.
Het zorgvuldig controleren van de gebruikte sleutels kan dergelijke methoden blootleggen. Als alle verzonden gegevens werden versleuteld met asymmetrische codes zoals RSA, zou dit zelfs kunnen worden beschouwd als al ondertekend door de oorspronkelijke server, waardoor het probleem bijna teniet wordt gedaan. Maar om prestatieredenen worden bij SSL asymmetrische methoden alleen gebruikt om sleutelzinnen te verzenden voor snellere symmetrische codering. Dus het vervalsen van een log van de versleutelde code van de gegevens die daadwerkelijk zijn verzonden, is theoretisch mogelijk voor de klant, omdat hij die symmetrische sleutel kent (hoewel dit waarschijnlijk nog moeilijker is dan reverse-engineering van een plug-in).
Om al deze problemen te voorkomen, mag de browser niet op uw eigen computer draaien. Wat men nodig heeft, is een zogenaamde “remote controlled browser” (ReCoBS) zoals deze – om totaal andere redenen – wordt gebruikt in sterk beveiligde faciliteiten. Dit is een browser die op een andere computer draait, bestuurd wordt door een derde partij, die alleen een videostream van zijn vensters naar de client stuurt en slechts een beperkt aantal opdrachten accepteert. Deze externe browser kan alle log- en ondertekeningsbewerkingen uitvoeren, aangezien deze niet door de gebruiker kan worden gemanipuleerd.
Welke aanvalspaden tegen dit systeem moeten worden overwogen? Ten eerste is er een kans om de hele ReCoBS daadwerkelijk te hacken. Het is een risico op zich dat een browser wordt bestuurd door een externe en mogelijk onbekende gebruiker. De browser moet in een goed afgesloten sandbox draaien, niet alleen om het systeem te beschermen tegen hacking, maar ook om onderlinge afhankelijkheid tussen parallelle of volgende sessies op dezelfde computer te voorkomen,
Als het gaat om het vervalsen van de resultaten van websessies, lijkt DNS-cachevergiftiging de gevaarlijkste optie. Dit kan worden verholpen door DNSSEC te gebruiken wanneer dit op een dag het hele web omvat, of mogelijk door een netwerk van machines over de hele wereld te hebben en het DNS-verzoek willekeurig te routeren. Scriptinjecties op de bezochte websites zijn een tweede manier om gemanipuleerde resultaten te krijgen, maar er kan geen werkende tegenmaatregel zijn door de ReCoBS als de injectie van een vierde partij komt, en openstaan voor een dergelijke aanval zou in de eerste plaats een groter probleem moeten zijn naar de getroffen site dan de logboeken die hierdoor zijn gemaakt.
Zelfs als we deze problemen in ogenschouw nemen, lijken ReCoBSes nog steeds de enige optie die op zijn minst een theoretische kans op geloofwaardig bewijs biedt. Als ze correct worden geïmplementeerd, kunnen ze werken. De meeste andere technologieën hebben ontwerpfouten en het is slechts een kwestie van tijd voordat openbare exploits beschikbaar zullen zijn.
