Cookies op Tweakers

Tweakers maakt gebruik van cookies, onder andere om de website te analyseren, het gebruiksgemak te vergroten en advertenties te tonen. Door gebruik te maken van deze website, of door op 'Ga verder' te klikken, geef je toestemming voor het gebruik van cookies. Wil je meer informatie over cookies en hoe ze worden gebruikt, bekijk dan ons cookiebeleid.

Meer informatie

Door , , 27 reacties

Een vooraanstaande cryptografie-expert heeft zijn zorgen geuit over de mogelijkheid dat onontdekte rekenfouten van processors door aanvallers gebruikt kunnen worden om de beveiliging van publieke sleutel-cryptografie te doorbreken.

Sleutel + SlotAdi Shamir, een van de uitvinders van het RSA-algoritme, stuurde zijn waarschuwing eind vorige week naar een selecte groep collega's. Om een aanval te doen slagen is kennis van een wiskundige afwijking van de chip nodig en een met die kennis opgesteld kwaadaardig versleuteld bericht, volgens Shamir. Na verzending is het mogelijk de geheime sleutel te achterhalen van de ontvangende computer. Bij publieke sleutel-cryptografie worden berichten gecodeerd met een publieke sleutel en ontcijferd met een unieke, geheime sleutel. Dit principe wordt onder andere gebruikt bij transacties via internet.

Dat chips rekenfouten kunnen maken bewijst de ontdekking in 1994 van de FDIV-bug in Pentium-processors. 'Zelfs als we aannemen dat Intel ervan geleerd heeft en de correctheid van zijn multiplier-instructies minutieus nagaat, zijn er veel kleinere fabrikanten die minder zorgvuldig zijn met hun ontwerp', aldus Shamir. Intel wijst erop dat het om een theoretisch probleem gaat.

Vorige week wees een andere cryptografie-expert op de mogelijkheid dat een algoritme voor random number generators die tot een standaard is verklaard, een backdoor bevat van de National Security Agency.

De Amerikaanse standaardiseringsorganisatie National Institute of Standards and Technology heeft dit jaar vier nieuwe 'Deterministic Random Bit Generators' aangewezen als standaard. Deze gaan vrijwel zeker gebruikt worden door hardwarefabrikanten en software-ontwikkelaars voor beveiligingsdoeleinden. Volgens cryptografie-goeroe Bruce Schneier is het probleem echter dat de generator die gebaseerd is op elliptische krommen afwijkingen vertoont ten opzichte van de overige drie.

EncryptieDual_EC_DRBG, zoals de techniek gedoopt is, is niet alleen trager dan de andere generators, het is ook alleen een standaard vanwege het lobbywerk van de NSA, schrijft Schneier. In 2006 werd al aangetoond dat de generator een kleine afwijking vertoont, maar dit maakte het algoritme nog niet onwerkbaar.

Ernstiger is de kwetsbaarheid die de Nederlandse cryptograaf Niels Ferguson samen met Dan Shumow onthulde tijdens de bijeenkomt Crypto 2007. De standaard bevat een aantal constanten die gebruikt worden voor het bepalen van de elliptische krommen van het algoritme. Wat Shumow en Ferguson hebben aangetoond is dat deze getallen gerelateerd zijn aan een tweede, geheime verzameling nummers, die kan dienen als een soort loper. 'Als je de geheime nummers weet, kun je de output van de random-number generator voorspellen op basis van slechts 32 bytes van zijn output', aldus Schneier. Probleem is dat niemand weet waar de constanten vandaan komen. De mogelijkheid bestaat dat iemand bij de NSA met de constanten op de proppen is gekomen en over de geheime set getallen beschikt.

Moderatie-faq Wijzig weergave

Reacties (27)

Alle pseudo-random generatoren hebben last van dit probleem. Met behulp van een algorithme als C4.5 (zie bijvoorbeeld http://en.wikipedia.org/wiki/C4.5_algorithm ) zijn alle pseudo random generatoren te kraken. Dit is overigens in 1951 al bewezen door John von Neumann.

Op de URL http://picasaweb.google.com/freemovequantumexchange is een Proof-of-Concept Systeem te vinden dat bewijsbaar veilig is en dus ook geen gebruik maakt van pseudo random generatoren maar van true Quantum Random Generatoren.
Met behulp van een algorithme als C4.5 (zie bijvoorbeeld http://en.wikipedia.org/wiki/C4.5_algorithm ) zijn alle pseudo random generatoren te kraken.
Kun je dat uitleggen? Hoe kraak je een pseudo-random generator met C4.5? Die maakt decision trees over een aantal feature values/classes (gebaseerd op statistische informatie). Lijkt me niet geschikt om het "volgende pseudo random getal" o.i.d te voorspellen.

Freemove, bedankt voor de uitleg hieronder!

[Reactie gewijzigd door durian op 19 november 2007 12:39]

In de 1e stap gebruik je het C4.5 algorithme als een "distinguisher". Een voorbeeld van zo'n distinguisher is te vinden op de URL http://www.ecrypt.eu.org/stream/phorum/read.php?1,997

Als je na de 1e stap weet welke pseudo random generator gebruikt is, gebruik je in de 2e stap het C4.5 algorithme om de gebruikte initialisatie waarden (of seeds) van het pseudo random generator algorithme voor de random stream te classificeren. Als de grootte van de klasse van initialisatie waarden klein genoeg is kun je met brute force alle mogelijke initialisatie waarden proberen.

Dit is een wetenschappelijk gepubliceerde, geverifieerde en geaccepteerde methode om random generatoren en cryptografische methoden te kraken.

True Quantum Random Generatoren zoals gebruikt worden in de het FreeMove Quantum Exchange Proof-of-Concept http://picasaweb.google.com/freemovequantumexchange kunnen op deze manier niet gekraakt worden, omdat de 2e stap niet uitgevoerd kan worden. Deze blijven dus altijd onvoorspelbaar, hoewel in sommige gevallen wel identificeerbaar met de 1e stap.
Een 2e mogelijkheid om C4.5 te gebruiken om een pseudo random generator te kraken wordt beschreven op de URL www.cosic.esat.kuleuven.be/nessie/workshop/submissions/nextbit.ps

Nadat geclassificeerd is welke pseudo random generator gebruikt is voor de generatie van een random stream door het C4.5 algorithme te gebruiken als "distinguisher" ( zie http://www.ecrypt.eu.org/stream/phorum/read.php?1,997 voor een voorbeeld ) , kan als 2e stap met C4.5 de volgende bits voorspeld worden gegeven de voorgaande random bits en de gebruikte pseudo random generator.
Een Quantum Random Generator in de praktische vorm van USB2.0-device.
Dat chips rekenfouten kunnen maken bewijst de ontdekking in 1994 van de FDIV-bug in Pentium-processors. 'Zelfs als we aannemen dat Intel ervan geleerd heeft en de correctheid van zijn multiplier-instructies minutieus nagaat, zijn er veel kleinere fabrikanten die minder zorgvuldig zijn met hun ontwerp', aldus Shamir. Intel wijst erop dat het om een theoretisch probleem gaat.

Ik denk dat de hoeveelheid servers die van zulke processors gebruik maakt zo klein is dat het ook een theoretisch probleem blijft.
Ik denk dat de hoeveelheid servers die van zulke processors gebruik maakt zo klein is dat het ook een theoretisch probleem blijft.

True, en dat waren asl ik het me goed herinner de Pentium I 's

Dus niet echt actueel meer ;)

Maar dŠŠr gaat het hier ook niet om, het was een "vergelijk"

[Reactie gewijzigd door bord4kop op 19 november 2007 11:59]

http://core.tweakers.net/...-en-snellere-phenoms.html

hoezo niet actueel meer??

[Reactie gewijzigd door udybees op 19 november 2007 19:04]

Theorie is natuurlijk ook leuk :).
Als Alice een bericht stuurt aan Bob gebruikt ze de publieke sleutel van Bob. Om dit bericht te lezen gebruikt Bob zijn geheime sleutel. Door de ciphertext zorgvuldig te manipuleren, kan de berekening met Bob's geheime sleutel allerlei vreemde dingen doen. Alleen is het niet duidelijk hoe een fout in de onsleuteling op de PC van Bob informatie geeft over de geheime sleutel van Bob aan Alice. Dan moet Bob toch echt een bericht naar Alice sturen waarin zijn sleutel gebruikt wordt.
Ervan uitgaande dat het om bank transacties gaat ben ik het met je eens dat dit een niet bestaande kans is. Geen enkele bank zal nog gebruik maken van servers uitgerust met PI CPU´s. Echter hoeveel andere minder critische sites maken van deze functie gebruik die misschien wel op een PI draaien? Dit kan eigenlijk net zo gevaarlijk zijn als het om bv een site met bedrijfsgeheimen gaat.
Geen enkele bank zal nog gebruik maken van servers uitgerust met PI CPU´s.
Dit gaat niet over de P1 maar over fouten in chips in het algemeen.
Minder critische sites die bedrijfsgeheimen bevatten.....
Kijk een wat je allemaal moet weten om hierop een aanval uit te oefenen.
1) dat er bedrijfsgeheimen zijn
2) op welke server die dan draait met welke CPU
3) welke encryptie wordt gebruikt
Die kans nadert hard de 0%
1) dat er bedrijfsgeheimen zijn
Het kan ook geld zijn ipv van bedrijfs geheimen cq banken en mogelijk webshops of persoonsgegevens zijn ook waardevol. Dit soort bedrijven zijn meestal duidelijker aanwijsbaar.
2) op welke server die dan draait met welke CPU
Dit zou je kunnen automatiseren, dit is uiteindelijk automatisering. Logischerwijs kun je het aantal behoorlijk reduceren. Het zal in de meeste gevallen een x86 CPU van maximaal 5 jaar zijn en mogelijk een Sparc ook maximaal 5 jaar oud dan blijven de andere varianten over.
3) welke encryptie wordt gebruikt
Zou me niet verwonderen dat je dit via fingerprinting kunt achterhalen. Ook het encryptie algoritmes zijn behoorlijk beperkt.
Die kans nadert hard de 0%
Het is net als traditioneel inbreken. Er zitten de elementen tijd/risco en gewin in als deze voor die partij in balans zijn zal tot actie overgegaan worden.

Dus bijvoorbeeld niet interessant voor de gewone ADSL gebruiker. Mogelijk wel voor een webshop met veel omzet (creditcards).

[Reactie gewijzigd door worldcitizen op 19 november 2007 12:39]

Dit zou je kunnen automatiseren, dit is uiteindelijk automatisering. Logischerwijs kun je het aantal behoorlijk reduceren. Het zal in de meeste gevallen een x86 CPU van maximaal 5 jaar zijn en mogelijk een Sparc ook maximaal 5 jaar oud dan blijven de andere varianten over.
Maar dan moet je ook nog de stepping zien te achterhalen, want een P4 1,6Ghz is fysiek echt fors anders dan de laatste P4's.
Ook het encryptie algoritmes zijn behoorlijk beperkt
Maar het aantal implementaties is wel weer fors groot, en dan kan het zelfs nog uitmaken met welke compiler het gedaan is. Want uiteindelijk is de bytecode hetgeen wat kwetsbaar is, een andere bytecode voor hetzelfde probleem kan ineens wel of niet kwetsbaar zijjn. Dus zaken als SSE en andere extra's kunnen hier flink roet in het eten gooien.

Het is net als traditioneel inbreken. Er zitten de elementen tijd/risco en gewin in als deze voor die partij in balans zijn zal tot actie overgegaan worden.
Voor een NSA die wil inbreken bij een chinese veiligheidsdienst kan het misschien nog verantwoordbaar zijn. Maar de hoeveelheid kennis die nodig is om dit soort dingen te doen is dusdanig dat het al amper uitvoerbaar is om een test opstelling te bouwen. En dan nog is er absoluut geen zekerheid dat het werkt.

Theoretisch is er ook een kans dat ik met Scarlett Johansson... :+

[Reactie gewijzigd door TheGhostInc op 19 november 2007 13:46]

Nee hoor, het probleem is niet denkbeldig. Het probleem met de P1 wordt alleen als voorbeeld genoemd. Veel (of alle) processors bevatten bugs. Een recent voorbeeld is de bug in de Conroe processoren: http://core.tweakers.net/...n-het-licht-gebracht.html

[Reactie gewijzigd door pinockio op 19 november 2007 15:04]

Vorige week wees een andere cryptografie-expert op de mogelijkheid dat een algoritme voor random number generators die tot een standaard is verklaard, een backdoor bevat van de National Security Agency.
Erg zorgelijk, de bron is.

Misschien eens tijd dat organisaties en bedrijven bijvoorbeeld EU, financiŽle instelling en defensie etc waar security belangrijk is eens wakker worden. E zelf eens een secure OS gaan ontwikkelen.

Het voordeel was dat de documentatie ter inzage lag. Ik vraag me af of dit ooit in gesloten software gevonden zou zijn?
Gesloten beveiligingsproducten worden al heel lang niet meer geaccepteerd juist om de reden van verifieerbaarheid van de correcte functie. Overheden hebben vaak een veelvoud aan tegengestelde belangen ten opzichte van beveiliging en de inbreng van overhededn is daarom niet altijd bruikbaar in beveiligingsstandaarden.
Gesloten beveiligingsproducten worden al heel lang niet meer geaccepteerd juist om de reden van verifieerbaarheid van de correcte functie.
Volgens mij zijn firewalls beveiligingsproducten en tevens hun VPN mogelijkheden. Alle drie de grote spelers zijn helemaal gesloten. Checkpoint, Cisco (PIX), Juniper (Netscreen).
Probleem is dat niemand weet waar de constanten vandaan komen.
Dit lijkt me toch geen probleem, maar eerder mooi.
Ik mag ook hopen dat de NSA er voor heeft gezorgd dat niet ťťn persoon alle constanten kent, maar dit heeft gedistribueert over een aantal personen.

Een inderdaad, het andere onderwerp in de nieuwspost: het blijft een theoretische kans die vooral als waarschuwing naar de chip-ontwerpers gezien moet worden: "wees nauwkeurig want anders gaat het een keer fout"
Ik ben trouwens meer bang voor de normale rekenfouten die dit veroorzaakt in wat voor een applicatie dan ook, dan als veiligheids lek voor encryptie
Dit lijkt me toch geen probleem, maar eerder mooi.
Natuurlijk niet. Een backdoor voor de NSA kun je toch niet mooi noemen?
Dit lijkt wel op het Juvenalis Dilemma van Dan Brown..

NSA met een backdoor.. Kraken van cryptografische code..

Zometeen komt in het nieuws dat er een onkraakbare code blijkt te zijn wat in werkelijkheid een virus is..
Het is inderdaad vervelend dat codes die gebruik maken van pseudo-random generatoren te kraken zijn.

Wat echter wel blijft is dat veelal de tijd die voor de kraak benodigd is te lang is om bruikbaar te zijn.
Dat chips rekenfouten kunnen maken bewijst de ontdekking in 1994 van de FDIV-bug in Pentium-processors. 'Zelfs als we aannemen dat Intel ervan geleerd heeft en de correctheid van zijn multiplier-instructies minutieus nagaat, zijn er veel kleinere fabrikanten die minder zorgvuldig zijn met hun ontwerp'.
Dit is echt onzin. Cryptografische software maakt helemaal geen gebruik van de floating-point module van een processor. Deze ontbreekt het aan de benodigde nauwkeurigheid en snelheid.

In plaats daarvan wordt van de integer multiplier gebruik gemaakt. En die werkt heus wel gewoon naar behoren, anders zou er heel wat meer software omvallen. Sterker nog, met een kapotte integer multiplier zou je OS niet eens opstarten.

[Reactie gewijzigd door Tabsels op 19 november 2007 17:13]

Je kunt een chip niet 'kraken', wel reverse engineeren.

Dit bericht gaat over 'kraken'. Daarbij gaat het er dus niet om hoe de chip fysiek is opgebouwd (alhoewel dat wel van belang is natuurlijk) maar om het rekenwerk wat hij doet als we het over cryptografische berekeningen hebben.
Dit gaat niet over het kraken van chips maar over het kraken van cryptografische oplossingen. En die worden niet zo heel vaak gekraakt.

Op dit item kan niet meer gereageerd worden.



Apple iOS 10 Google Pixel Apple iPhone 7 Sony PlayStation VR AMD Radeon RX 480 4GB Battlefield 1 Google Android Nougat Watch Dogs 2

© 1998 - 2016 de Persgroep Online Services B.V. Tweakers vormt samen met o.a. Autotrack en Carsom.nl de Persgroep Online Services B.V. Hosting door True