Anonieme systemen te ontdekken door temperatuurvariaties

Tijdens het Chaos Communications Congress in Berlijn, een jaarlijks congres georganiseerd door de Chaos Computer Club over beveiliging van computersystemen, heeft een Britse onderzoeker aangetoond hoe door middel van temperatuurveranderingen anonieme computersystemen kunnen worden geïdentificeerd.

Steven J. Murdoch, verbonden aan de Cambridge University, liet zien dat door gebruik te maken van de 'clock skew' kan worden vastgesteld waarvandaan een bepaald netwerkpakket afkomstig is. Hierdoor is het mogelijk om het ip-adres van een computersysteem te bepalen, terwijl het systeem zijn dataverkeer verzendt via een anonimiserend systeem. De clock skew, een kleine variatie in de klokfrequentie van het computersysteem als gevolg van altijd aanwezige afwijkingen in de kristallen die worden gebruikt voor het genereren van de kloktikken, is terug te zien in het netwerkverkeer van een computersysteem doordat als gevolg van de variërende klokfrequentie de timestamps in de netwerkpakketten zeer kleine afwijkingen laten zien.

Murdoch heeft in een experimenteel onderzoek aangetoond hoe dit in de praktijk mogelijk is. Hiervoor zette hij een Tor-netwerk op waarbij de individuele computersystemen datapakketten kunnen verzenden naar systemen, maar waarbij het ontvangend systeem niet kan vaststellen waarvandaan een pakket afkomstig is. Om te bepalen of een pakket van een bepaald systeem afkomstig is, verstuurde de onderzoeker plotseling een verzoek voor gegevens die relatief veel rekenwerk vergen. Doordat het systeem plotseling zwaarder wordt belast, stijgt de temperatuur van de computer wat weer terug te zien is in een veranderende clock skew. Dit is weer vast te stellen door de ontvangende partij door de timestamps van de netwerkpakketten bij te houden, waardoor bewezen kan worden dat de data van een specifiek ip-adres afkomstig is.

Hierdoor is de anonimiteit van systemen die onderdeel uitmaken van een Tor-netwerk te doorbreken. Tor is een implementatie van 'onion routing', waarbij datapakketten via verschillende systemen versleuteld wordt verzonden, alvorens bij de uiteindelijke bestemming aan te komen. Hierdoor is het praktisch niet mogelijk om te achterhalen waarvandaan een pakket afkomstig is. De aanval van Murdoch op dit netwerk bouwt voort op resultaten van een eerdere publicatie van Tadayoshi Kohno, die bewees dat de clock skew is vast te stellen uit het netwerkverkeer van een computersysteem. Na de publicatie van Kohno werd gespeculeerd over de mogelijkheden van zijn ontdekking, zoals het detecteren van het aantal systemen achter een NAT-router. Volgens Murdoch is het lastig om de door hem gedemonstreerde aanval te voorkomen. Het zou mogelijk kunnen zijn om de timestamp vast te zetten, maar zelfs dan is het wellicht mogelijk om de aanval uit te voeren.

Reacties (70)

[TD-er]

Vergis ik mij nou, of is dit al een paar jaar bekend?
Ik meen dit al eens in de C'T of iets dergelijks te hebben gelezen.
edit:
Hier veel meer info hierover in een document uit mei 2006

[El Cid]

Mensen die zich hier echt zorgen om maken, moeten OpenBSD gebruiken. In OpenBSD wordt er een zekere 'willekeur' aan alle timestamps toegevoegd. Zeker als je dan ook nog NTP gebruikt, kun je dit soort technieken weerstaan.

[aTmosh]

Je komt er vrij snel achter of NTP wordt gebruikt of niet, en zodra dat bekend is kan je dat anticiperen en meenemen in de berekening, het voegt juist regelmaat toe. Ten tweede heeft het door de gebruikelijke frequentie mogelijk weinig invloed, die zou je moeten verhogen totdat de voor jouw hardware geldende skew onmeetbaar wordt, wat theoretisch om frakties van een seconde zou kunnen gaan. En dan spring je er weer door de nauwkeurigheid er tussen uit.

De beste strategie is om bij gebrek aan een nauwkeurige klok de TCP stack per pakket te laten randomizen (wat weer een goede random generator veronderstelt, normaal gesproken weer een functie van de klok, dus niet ideaal), of temperatuurwisselingen proberen te beperken. Dat doen al een hoop mensen:

[Verwijderd]

je zou ook de computer altijd vollast kunnen laten draaien, dan is er geen temperatuurverschil

[BasieP]

nog een reden om de DPC te joinen

[Chatslet]

Je kunt ook gewoon een proxy server gebruiken dan ziet men de timestamp van de proxy. Andere optie om de timeskew te elimineren is vrij ruw afronden van de timestamp dus niet op ns maar op ms of desnoods op hele seconden.

[Verwijderd]

mm... als ze inderdaad door variaties in de klok er achter kunnen komen van welk IP adres een pakket komt, lijkt het me voldoende om op de tussenliggende stations dmv een random number generator de timestamp wat te tweaken.

Natuurlijk zijn random number generators niet echt 'random' maar dan moet de aanvaller er eerst al achter zien te komen welke generator er wordt gebruikt. Als het echt van belang is zijn er ook random nomber generators die werken op basis van externe inputs (zoals attoomtrillingen ofzo).
Een andere methodes is mssn te werken met het store & forward principe. Als de tussenliggende node eerst alle data krijgt (en desnoods de verbinding verbreekt) en dan pas verder stuurt, dan kan alleen maar de tussenliggende node geidentificeerd worden (alle headers zijn toch in de vuilbak -> timestamps worden opnieuw gegenereerd)

In elk geval gaat dit weer een gezellig kat en muis spelletje worden.

[ciro-bonano]

Random noise toevoegen werkt niet; je hebt dan gewoon wat meer datapaketten nodig en met statistische analyse haal je er dan toch nog de gewenste gegevens uit (je verandert de spreiding, niet het gemiddelde). Maar misschien kan je het zo wel praktisch onmogelijk maken, maar theoretisch blijft het mogelijk.

[El Cid]

Random noise toevoegen werkt niet; je hebt dan gewoon wat meer datapaketten nodig en met statistische analyse haal je er dan toch nog de gewenste gegevens uit (je verandert de spreiding, niet het gemiddelde).

Als het echt random is, dan kan statistische analyse je ook niet meer helpen. Dat is nou net de definitie van random.

[Verwijderd]

Juist dan kan het wel, als jij perfecte random data toevoegd aan data waar een nette systematische golf in zit, dan kan je met enig analyse-werk gewoon die oude frequentie etc. weer terugvinden. Dat is dan namelijk de afwijking van de perfecte verdeling die je zou moeten hebben. Het kost wel meer data, maar uiteindelijk kan het gewoon.

[Parasietje]

Je begrijpt het niet... De clock skew zorgt ervoor dat de timestamps van een systeem steeds 2ns / s afwijken van de werkelijke tijd, ja? Stel dat we daar random noise aan toevoegen. Goed, nu kan je niet meer zoeken op "pakketten van een computer die een clock skew van 2ns/s heeft". Wat je wel kan doen, is kijken of een aantal vooraf geselecteerde pakketten van dezelfde computer komen: pak het gemiddelde van alle clock skews. Bij echt random noise zal de noise uitgemiddeld worden, en heb je dus een bepaald gemiddelde.

Detecteren hoeveel computers achter een NAT zitten kan dus nog steeds, met of zonder random noise. Je meet de gemiddelde clock skew op dag 1. Als die plots sterk verandert, dan betekent het dat er een tweede computer ook pakketjes verzendt. (of dat het huis in de fik staat natuurlijk )

[Mentalist]

Koop je voor €3 een FM radio en hang je die aan je line-in. Perfecte niet-random random number generator . Zet hem bij voorkeur (indien mogelijk) op een lokale piratenzender, dan kan de aanvaller ook niet zelf gaan luisteren (voor zover dat hem genoeg zou helpen, hij zou er toch eerst achter moeten komen welke zender je op hebt staan en überhaupt dat je een FM-radio hebt, en geen shoutcast stream, TV, satellietontvangst of wat dan ook).

[edit]Was een reactie op Satolf

[Verwijderd]

als je dat dan nog wilt perfectioneren dan koop je net als ik een FM transmitter voor je ipod, die werkt maar op een straal van ongeveer 10 meter,hoewel ik hem niet voor deze doeleinden gebruik is ie er wel voor geschikt...
als de persoen er dan achter wilt komen welke zender je gebruikt moet hij toch eerst binnen een straal van 10 meter van je ipod zien te komen....

Is dat slim of ben ik nou gewoon net terug van een avondje stappen???

[Mentalist]

Dat is heel slim, maar je bent tóch dronken. Want waarom hang je je Mp3-speler niet direct aan je line-in dan? Of nog makkelijker, waarom dump je de Mp3tjes niet op de computer en analyseer je de stream bits gewoon voor je "random" nummers?

Probleem daarmee is dat je geen DJ-gezeik hebt (wat vrij onvoorspelbaar is) en je bent een keer door je collectie heen, of je moet wel heel veel nummers hebben.

[i-chat]

nouw - omdat FM op zich ook al weer een zekere ruis heeft die ook nog weer 's plaats afhankelijk is ...

best wel briljant eigenlijk.

[Sorcerer8472]

Random noise werkt niet, maar bijvoorbeeld een algoritme toepassen wat juist de metingen verstoort die benodigd zijn om tot een identificatie te leiden.

Zo zou je zelf bijvoorbeeld kleine golfbewegingen aan random noise kunnen toevoegen, al dan niet afgeleid van het type gegevens dat je als tor-satelliet doorstuurt...

Door ook nog eens te variëren wélk algoritme er wordt gebruikt (je bouwt er uiteraard een aantal ) kun je uiteindelijk een soort algoritmisch opgebouwde random noise genereren: noise waardoor dit soort identificatie niet meer mogelijk is, of waardoor de foutmarge in ieder geval fors toeneemt.

[Emmef]

Je kunt ook de "random" factor in de timestamp, afhankelijk maken van de drukte op je systeem: bij een druk systeem werk je de door hitte veroorzaakte skew tegen. Daar zijn wel mogelijkheden voor.

[flossed]

volgens mij ben je met een software nat implementatie al een heel end of de beroemde ICS systeem van windows. Want in dat geval wordt het internet verkeer allemaal via een fysiek systeem verwerkt en doorgzet. Maar ik kan het mis heben.

[BRAINLESS01]

tja... het klinkt leuk, maar je kunt natuurlijk makkelijk de timestamp van je netwerkpakketjes aanpassen voordat die verstuurd worden, uiteindelijk is het allemaal software. Bovendien, waarom zou mijn computer reageren op iets dat veel rekenwerk gaat kosten als die man er om vraagt? Hij weet in eerste instantie nog niet eens mijn ip adres, dus kan hij mijn computer helemaal niks laten doen... het is dus wachten op een temperatuurverschil en dan hopen dat jij er op dat moment een verwachte ofzo. Doelloos

[TD-er]

Je PC reageert op ping-pakketjes en zo zijn er nog diverse andere mogelijkheden om iets naar jouw machine te sturen.
Bijv door iets aan te bieden aan jou, waardoor jij iets gaat binnen halen. Zo komen de antwoorden ook aan op jouw machine en dus door je firewall en NAT-router heen.
In de pakketjes zitten allerlei checksums en door die wat aan te passen moet je PC (of netwerkkaart) dus meer rekenwerk verrichten.

Edit:
@[Byte] & @TvL2386:
OK, mischien wat ping een verkeerd voorbeeld, maar wat ik dus bedoel is dat er wel degelijk communicatie mogelijk is.
Met iets aanbieden doelde ik dus op bijvoorbeeld een honeypot van de stichting Brein enz.
Die kunnen dan zien dat jij copyrighted materiaal download en als ze dan zelf ook andere dingen proberen te downloaden, kunnen ze zien of jij die ook gedownload hebt of niet. Bijv als je hun website oid zou bekijken die je niet via een tor-netwerk bekijkt.
Kwestie van een database aanmaken van dergelijke fingerprints.
Nu zal je dat vergelijken wel ongeveer op dezelfde tijd moeten doen om te voorkomen dat je andere omgevingsinvloeden meeneemt.
Maar goed, het gaat er hier om dat je dus minder anoniem bent, doordat ze kunnen zien of 2 pakketjes van hetzelfde systeem afkomstig zijn of niet.

[TvL2386]

De meeste firewalls en routers reageren niet op ping requests. Daarnaast als dat wel het geval is, dan stuurt mijn router dus een reply terug... Niet de PC welke je probeert te identificeren.

En waarom zou een PC een verbinding accepteren welke vervolgens veel rekenkracht vergt? Ik kan geen manier verzinnen (zonder een of andere service in te schakelen en hiervoor de poorten te forwarden op mijn router) dat dit mogelijk maakt.

Volgens mij zitten de meeste mensen tegenwoordig wel achter een router of firewall.

[UrsusX]

Er kan vastgesteld worden dat de data van één systeem komt, maar het ip-adres weet je dan nog steeds niet.
En deze hele methode werkt alleen als de temperatuur toeneemt bij belasting. Of dat zo veel is bij een oudere processor (zonder energiebeheer) in een goed gekoelde server vraag ik mij af.

[Dutch_Razor]

Als er meer geschakeld wordt volgt er volgens mij altijd een temperatuurstijging, je proc wordt toch warmer als je em stressed?

[Verwijderd]

In dat geval kan het een oplossing zijn je CPU steeds voor 100% te belasten, bv. door op de achtergrond een te draaien of zo.

[Kalief]

Ja dat leek mij ook al. Je zou volgens bovenstaand verhaal kunnen zien dat verschillende pakketjes van eenzelfde bron zouden kunnen zijn. Maar welk ip-adres daarbij hoort kun je daar toch niet van af leiden.

[Verwijderd]

Als ik het goed heb is hij dus in staat om alleen het ip-adres te bepalen van een anonieme computer waarvan hij via een ander kanaal al een bericht van de betreffende computer had opgevangen? Met andere woorden hij kan vaststellen of machine die iets verstuurd via een bepaald ip dezelfde is als de machine die iets verstuurd via een ander ip (bijv via een tor netwerk). Right?

[Skit3000]

Ik weet niet hoe dat Tor-netwerk precies werkt, maar zodra je van computer 1 een pakketje naar computer 2 stuurt, computer 2 buffert dit en stuurt het pas door naar computer 3 als er een bepaalde hoeveelheid data binnen is, dan is er niets meer terug te vinden van de klokslag van de oorspronkelijke computer bij de derde in rij?

Bovenstaande wordt trouwens ook al door routers gedaan. Sommige routers wachten tot de complete header van een TCP/IP pakketje binnen is en streamen daarna direct alle binnenkomende data door naar het juiste netwerk. Andere routers wachten eerst tot het complete TCP/IP pakket binnen is om eerst een CRC check uit te voeren voordat de data doorgezonden wordt. Met beide manieren is er dus niets terug te vinden van de oorspronkelijke klokslag, aangezien de router de TCP/IP pakketjes gewoon in een buffer plaatst tot er genoeg data binnen is en die daarna met zijn eigen tempo via het FIFO principe weer doorstuurt.

[Verwijderd]

Ik vind dit de grootste onzin van 2006, het was even wachten totdat ik echt iets vond wat als een tang op een varken slaat maat dit is het dan eindelijk, nog op de valpreep.

Deze meneer laat een groot aantal variabelen buiten beschouwing. Denk maar eens aan p2p programma's die encrypted informatie uitwisselen, IM's werken ook met pgp achtige constructies ...

Er gaat zoveel encrypted door het internet door zoveel applicaties dat je naar mijn mening absoluut niet kan veronderstellen dat iemand TOR of andere onion achtige anonymizers gebruikt. Iedere encrypted verbinding vergt extra inspanning van de clients voor decryptie en sluetel uitwisselingen. De clock skew wordt daardoor evenzeer beinvloed.

Blijkens het bericht heeft meneer Murdoch niet eens de moeite genomen om een realistische situatie op te zetten, zijn netwerk houdt geen rekening met: verschillende hardware configuraties, tussenliggende niet TOR proxies, systeembelasting door overige software.

Typisch zo'n lab rat conclusie. Door naar het ronde archief.

[TD-er]

Het gaat hier helemaal niet zozeer om alleen maar TOR-achtige netwerken. Er wordt hier aangegeven dat er zelfs via een TOR-netwerk toch individuele PC's onderscheiden kunnen worden.
Als je dan via een andere route ook dingen kunt communiceren naar die machine kun je zelfs de machine op andere maniere traceren, maar je weet dan in elk geval dat het via TOR-verstuurde van die PC af komt die je via de andere route ook hebt kunnen vinden.

In de PDF die ik eerder ook al linkte staat zelfs dat je met wat langdurig meten ook grofweg de breedte- en lengtegraden kunt bepalen van de machine, puur door de variatie in temp gedurende de dag. (zal volgens mij in een datacenter waarschijnlijk wat minder varieren, maar die machines zijn vaak minder interessant om te identificeren)

Kortom dit is zeker geen onzin

[TheCapK]

Jij gaat er vanuit dat enkele 10-den van graden verschil over een hele dag ergens anders kunnen worden waargenomen?
Als je kijkt dat het in lab-condities al lastig is om kleine temperatuursverschillen nauwkeurig reproduceerbaar te kunnen veroorzaken en dus ook meten dan wordt de afwijking dus juist steeds groter naarmate er meer stappen tussen zitten. Zeker als je bekijkt dat je het hier hebt over een netwerk waar verschillende configuraties tussen zitten vanwelke je sowieso niet weet hoe die zijn opgebouwd en hoe energiezuinig die zijn.
Voeg daar aan toe dat een dynamisch IP op de ene dag van Jantje is de volgende dag van Xiang-Pi en de dag daarna weer van Kluk-Kluk, dan weet je genoeg dat wat hier wordt voorgesteld toch heel wat meer voeten in aarde heeft in 'the real world' dan deze heer in zijn lab onderzoek heeft voor elkaar gekregen.

Zo maar afschieten van iets zonder dit te onderbouwen is net zulke grote onzin als iets beweren wat alleen nog maar in lab-situaties, lees: onder ideale omstandigheden, is vastgesteld. Hoe vaak is het niet gebeurd dat het een of ander "wondermiddel" in het lab totaal geen effect had buiten het lab? Te vaak helaas. Er zijn te veel variabelen waar rekening mee moet worden gehouden om bovenstaand verhaal als bedreiging te zien voor anonymiserende netwerken.

Edit: maar je snapt dat het allemaal niet meer zo makkelijk is als het in eerste instantie lijkt. Zeker als je er een dynamisch IP-adres mee probeert te vinden!

[TD-er]

Die optie om de geografische positie te kunnen bepalen werd in de PDF genoemd.
Ik heb zonet even gekeken of ik in de MRTG grafieken van mijn eigen thuis-servertje in de grafieken van de CPU en MB temps dag en nacht kan onderscheiden.
Aangezien ik dat met hele graden meet, valt het niet zo heel goed op, maar het is wel te herkennen. De maand juli valt wel goed op
Maar goed, je kunt op die manier dus wel de lengtegraad aflezen, omdat je weet wanneer het kouder is en dus waarschijnlijk 's nachts is.
De breedte graad lijkt mij iets lastiger te meten, maar als je kamertemp nogal afhangt van de stand van de zon, zou je dat ook kunnen meten.

[terabyte]

Ik vind dit de grootste onzin van 2006, het was even wachten totdat ik echt iets vond wat als een tang op een varken slaat maat dit is het dan eindelijk, nog op de valpreep.

En waarom publiceer je jouw bevindingen niet in een vooraanstaande journal op dit gebied?

Typisch zo'n lab rat conclusie. Door naar het ronde archief.

Op Tweakers.net commentaar leveren op zulke publicaties is erg makkelijk, maar probeer je commentaar zoals je die hier heb geformuleerd eens door het peer-reviewing proces te krijgen.

[DeArmeStudent]

"Volgens Murdoch is het lastig om de door hem gedemonstreerde aanval te voorkomen."

Een aanval wil ik het niet noemen, eerder een detecteringssysteem, maar wel slim bedacht....

[Verwijderd]

nee, je probeert via een methode een beveiliging te omzeilen, dit is dus een aanval.

[Part]

Misschien dat dit in een laboratorium nog wel te meten is maar in het veld denk ik niet meer.
Bij grotere afstanden zijn de signalen alles behalve netjes en is het minimale verandering in klokfrequentie echt niet meer te meten.

En als er ook nog eens een ADSL verbinding tussen zit is het al helemaal onmogelijk.

[TD-er]

Het gaat niet om de variatie waarop pakketjes binnen komen, maar om de timestamp in het pakketje.
Dus de afstand zal niet veel uitmaken.
Wat waarschijnlijk wel zal uitmaken is of de bandbreedte van de machine die je wilt onderzoeken vol zit of niet.

[Verwijderd]

Daarom zijn er ook koelers voor kristallen in zend-ontvangers zodat de temperatuur constant blijft.

[Verwijderd]

of anders genoemd een kristaloven. google maar eens op die term.