Smartcards kraken met een gloeilamp

Zonnet weet te melden dat het volgens onderzoekers van de Universiteit van Princeton mogelijk is om Java-applicaties te kraken door niets meer dan gezond verstand en een gloeilamp. Een voorbeeld gaven Andrew Appel en Sudhakar Govindavajhala afgelopen week op een Security & Privacy-symposium in Oakland. De hitte van een gloeilamp wordt losgelaten op een chip, waarna het de bedoeling is dat de chip door de hitte geheugenfouten gaat genereren, met het in de war raken van het onderliggende veiligheidsprotocol tot gevolg.

Dit behoort normaal gesproken te resulteren in een systeemcrash. Wanneer men er echter in slaagt om het geheugen te voorzien van een stukje eigen code, en het overige vrije geheugen naar dit stukje code laat verwijzen, is er een zeventig procent kans dat deze code wordt uitgevoerd. Volgens de onderzoekers zijn vooral smartcards een potentieel doel, aangezien deze over een eigen processor en in veel gevallen Java beschikken.

Reacties (34)

[gluip]

Ik vind dit een beetje een onwaarschijnlijk artikel. Natuurlijk valt een java applicatie te kraken. Maar op deze manier is een beetje vreemd.
Er wordt vanuit gegaan dat je een jump in het geheugen kan maken die je zelf daar neer gezet hebt. Warmte is de trigger en niet echt zeer belangrijk voor het mechanisme (gaat om het principe). Kortom er wordt dus wat xtra code in de applicatie of op de smartcard gezet. Dan vraag ik me af als je weet waar je deze jump moet zetten dan heb je de applicatie al redelijk ge-analyseerd en kon je op veel makelijkere manieren een jump veroorzaken. Zou je het blind implementeren dan is de kans op een harde crash veels te groot. En heb je er niks aan. Daarnaast kan je misschien best een smart media kaartje jatten maar hopelijk staan toch alle belangrijke (persoonlijke) gegevens server based opgeslagen. en zul je nog wel meer moeten doen om iets te achterhalen. En om nou met een warmte bron bij een bedrijf binnen te lopen lijkt me niet echt reeel. En als je dat toch lukt kan je nog veel gemakkelijker er een nieuwe applicatie neerzetten en de vm een schopje geven (of iets lastiger de classloader zich helemaal opnieuw laten initialiseren)

Is het een leak in java, .Net ............. Nee niet echt. wat ze claimen heeft met het manipuleren van het gedarg van de processor te maken. Dus dta zou dan evengoed met een C, Pascal, Cobol of weet ik wat voor een taal te maken kunnen hebben.
Juist daarom, dat ze 2 populaire talen noemen, rijst bij mij het vermoede dat het meer een hoax is.

(FF met de source code rommelen ............, tsja was het maar zo makelijk)

Mocht het allemaal wel kloppen dan mogen we toch wel een beetje trots zijn op Philips

[avon]

> overige vrije geheugen naar dit stukje code laat verwijzen

IF geheugen = "verwijzing" then....

Kortom, dan is dat geheugen niet vrij als er een verwijzing in staat...

Vreemd eigenlijk dat een onderliggend protocol
daar zo op reageert. Een key die niet klopt
blijft toch een key die niet klopt ook al stuur
je foutieve data naar dat protocol.

[Luxx]

Ik denk dat het net iets ingewikkelde ligt dan heel even wat data "stuk maken" en je hebt volledige controle. Voor het artikel wordt het natuurlijk vereenvoudigd weergegeven.

Het blijft natuurlijk wle dat het grote mogelijkheden heeft als je zo computers (nu zijn het nog kleintjes, maar wie weet hoe deze methode dit over te nemen is naar andere systemen) Je ziet steeds meer systemen met een computer die onbewaakt ergens controle over uitoefend (van koffieautomaar, parkeermeter tot stoplicht pinautomaat, als je daar overal misbruik van kan maken... Ik zie zeker mogelijkheden :-P Ik droom nog even lekker verder hoor....

[zeekoe]

> overige vrije geheugen naar dit stukje code laat verwijzen

IF geheugen = "verwijzing" then....

Kortom, dan is dat geheugen niet vrij als er een verwijzing in staat...

Volgens mij bedoelen ze dit:
Stel, jouw programmaatje staat op adres 9D95h. (ja, da's het standaard adres van de Ti83+ maar dat boeit niet )
Als je al het geheugen wat er nog vrij is vult met 9D95h, en de processor krijgt per ongeluk de instructie om te springen naar het adres wat ergens in het geheugen staat, dan zou het goed kunnen dat de processor de opdracht krijgt om naar 9D95h te springen, omdat dat zo'n beetje overal in het geheugen staat.
Natuurlijk moet je alleen vrij geheugen hiermee opvullen, anders ga je nuttige data overschrijven.

[Roland684]

Volgens jouw beredenering kun je ook heen leeg velletje papier volschrijven
want als je het vol geschreven hebt is het geen leeg velletje meer.
Zeekoe slaat de spijker op zijn kop.

[Maxonic]

Hmm, als dit zou kunnen, (wat ik overigens betwijfel) is hetzelfde dan niet mogelijk wanneer smartcards in de zon liggen of zelfs in de reader te warm worden?

Dit alles doet me denken aan de Casio-rekenmachines die we op de middelbare school hadden. Als je een stukje code in een variable opsloeg kon heel wat rare dingen uithalen.

[Maarten @klet.st]

Als jouw smartcard in de zon ligt zal ie niet echt actief zijn dus weinig kans dat er dan fouten optreden.

In een reader zou natuurlijk kunnen, maar dan nog zul je uiteraard wel de software nodig hebben die code injecteerd of op een andere manier misbruik maakt van het niet geheel correct functioneren van de smartcard.

Dit soort technieken zijn overigens niet echt nieuw, UV licht is een bekende manier om chips te foppen, fluctuaties in de spanning en zo verder. Een gloeilamp die de chips verhit is natuurlijk een sprekend voorbeeld, een tijd geleden was er iemand die iets dergelijks met een flitser deed..

[miw]

Er zijn een grote hoeveelheid externe invloeden die een smartcard buiten z'n normale werk voorwaarden brengen. Vaak treden er dan ongedefinieerde situaties op, met steeds wat andere reacties. In het algemeen is dat op te vatten als een fout in de hardware, waartegen je kan programmeren. Dit is zo oud als de eerste rekenmachines, die vaak stukken minder betrouwbaar waren dat de huidige electronica.
Verder neemt die gloeilamp techniek ook aan dat je een progje in de kaart kan laden. In alle serieuze smartcard applicaties vereist dit een authenticatie code voor elk stukje te instaleren code.
Verder schermt de Java interpreter verschillende applets van elkaar af, zodat elke applet allen z'n eigen data en code kan bekijken.
Kortom, niet echt interessant werk.

[zeekoe]

Hmm gaaf... ik heb dan wel een Texas Instruments, maar zou je daar wat meer over willen vertellen?

[Verwijderd]

typ in in t basisscherm, of execute t via n programmatje met de nietszeggende naam tetris ofzo :
expr(") (te vinden in catalog)
[enter]
laat je hele TI83 crashen, en je krijgt m minimaal een uur niet meer aan de praat, zelfs na resetten....

nu krijg ik hier n hardstikke -9 offtopic/vette onzin/aanzetten tot vandalisme modding voor natuurlijk
maar kheb wel weer iemand blij gemaakt...

[zeekoe]

Ik heb een plus, maar daarmee zal het ook wel werken.
Laat ik alleen wel wachten tot volgende week dinsdag, ná mn examens

[THC]

Een beetje zoals een virus zijn eigen DNA in een cel injecteerd welke vervolgens dat DNA in zijn eigen DNA opneemt. Slim.

[Verwijderd]

Met een paar CRC checks in de hard- of software moet je de kans op een succesvol verneukte kaart toch behoorlijk kunnen inperken.

Doet me op zich een beetje aan de xbox crack denken, waar 'gewoon' de memory bus uitgelezen werd.
Goede beveiliging omvat ook de hardware en niet alleen stoere algorithmes.

[Verwijderd]

is dit niks voor de Tweakers Kookcursus?

Data recovery door de smartcard even te blancheren?

[Verwijderd]

Een jaar geleden was de universiteit van Cambridge ook al met zoiets bezig, echt veel vorderingen hebben ze niet gemaakt schijnbaar.

zie Fototoestel geeft geheimen smart cards weer

[Zarc.oh]

Hmmm, kan dit niet makkelijk voorkomen worden door een checksum op de uitvoerbare code uit te voeren?
if checksum (code) == okay
{
execute();
}

[Roland684]

Nee, dat werkt niet.
Door een storing in de hardware kan de er code/data uitgevoerd gaan worden die nooit uitgevoerd had mogen worden. Als je die code zelf kunt schrijven dan ben je natuurlijk dom om die code zelf te laten controleren of het wel klopt.
Je zou een OS moeten maken dat de code inleest, controleert en dan pas uitvoert, maar dat is veel te zwaar voor zo'n lichte processor.

Wat wel werkt is de chip zo maken dat code en data in aparte geheugens staan waarbij de instructiepointer onmogelijk naar een adres in het datageheugen zou moeten kunnen wijzen en waarbij het instructiedeel van het geheugen read-only is of op zijn mist comtroleerd welke software er geupload wordt. Maar dan maak je het ook vrijwel onmogelijk om zelf code toe te voegen tenzij je met een certificering gaat werken oid.

[HunterPro]

misschien is dat wel het stukje wat uitvalt en wat je vervangt voor een open("adress van mijn 1337 h4x0r code");

[Lentje]

Back to the roots...
Niks ingewikkelde techniek, gewoon een gloeilamp

[RRRobert]

idd. Deze past wat dat betreft mooi in het rijtje "overclocken met potloodstreepjes" en "CD-beveiliging omzeilen met viltstift"

[D-Devil]

Lijkt me niet meteen het meest eenvoudige om te doen, in ieder geval niet iets voor de doodgewone leek. Maar goed, wel interessant om te weten hoe en dát het überhaupt mogelijk is. .

[DannyXP1600]

maar daar wordt een klein kastje voor gemaakt zodat wel iedere leek je betaalpass kan kraken...

[Verwijderd]

chipknip...

[Steven]

Maar je kan jezelf nooit checken... Je hebt altijd een onbeveiligd punt nodig om de beveiliging te controleren.

[miw]

Je kan inderdaad niet controleren of een programma in een onveilige omgeving draait. Waar het hier om gaat is dat de hardware eventjes ontregeld wordt en na een kleine fout toch weer verder draait. Dit soort fout gedrag laat sporen achter (verkeerde status bits en software status condities ed) die in andere stukken code kunnen worden opgespoord. Vaak kan je ookgebruik maken van het feit dat niet alle stukken van een programma even gevoelig zijn voor zulke tijdelijke hardware fouten.