Onderzoek: Infineon-chips produceren onveilige rsa-sleutels

Onderzoekers hebben een fout ontdekt in de manier waarop chips van het Duitse Infineon rsa-sleutels genereren. Daardoor is een privésleutel met een publieke sleutel te achterhalen. Verschillende bedrijven zijn getroffen, waaronder Microsoft en Google.

De onderzoekers hebben hun bevindingen gepresenteerd onder de naam Roca. De kwetsbare implementatie is aanwezig in een rsa-softwarebibliotheek van Infineon, die onder meer wordt gebruikt in smart cards, trusted platform modules en in de id-kaarten van Estland. De gebrekkige implementatie zou al sinds 2012 aanwezig zijn. Onder meer Microsoft, Google, Lenovo, HP en Fujitsu hebben inmiddels patches of work-arounds uitgebracht om het probleem op te lossen. Ook Yubico is getroffen. De onderzoekers onderstrepen dat rsa zelf niet onveilig is. Ze vonden de kwetsbaarheid door een groot aantal rsa-sleutels in smart cards te analyseren.

De door de chips geproduceerde rsa-sleutels zijn vatbaar voor een zogenaamde factorization attack. Dit betekent dat de publieke sleutel de privésleutel kan onthullen, wat nooit zou mogen gebeuren. Volgens de onderzoekers is het mogelijk om met een Intel E5-2650 v3 op 3GHz een 512bit-sleutel in 2 cpu-uren te kraken. Voor een 1024bit-sleutel is dat 97 dagen en een 2048bit-sleutel vereist 140 jaren. Er zou nog geen manier zijn om 4096bit-sleutels aan te vallen, al zou dat wel kunnen zodra de aanval is verbeterd.

Door toegang tot een privésleutel kan een aanvaller zich bijvoorbeeld voordoen als het doelwit of versleutelde communicatie inzien, aldus de onderzoekers. Ze zochten naar kwetsbare sleutels in bijvoorbeeld id-kaarten, tpm's, https- of tls-sleutels en pgp. Daarbij vonden ze 760.000 kwetsbare sleutels, maar schatten dat het er ook twee of drie keer zoveel kunnen zijn.

Ze hebben een onlinetool ter beschikking gesteld waar gebruikers een publieke sleutel kunnen controleren op de kwetsbaarheid. Er is ook een offlinevariant beschikbaar. De onderzoekers, Matus Nemec, Marek Sys, Petr Svenda, Dusan Klinec en Vashek Matyas, presenteren hun bevindingen op de ACM-conferentie, die eind deze maand in de VS plaatsvindt en waar ook de Krack-aanval wordt gepresenteerd.

Reacties (56)

[Keypunchie]

Dit geeft ook aan dat 2048-bits key-length toch echt wel het minimum is geworden.

Die 140 jaar met 1 cpu lijkt veel, maar als je als (staats)hacker een beetje rekenkracht ertegen aan gooit wordt dat niks (Een serverparkje van 2000 cpu's kan het dan binnen een maand kraken). Een overheid/geheime dienst heeft dat soort rekenkracht wel ter beschikking. Een black hat hacker kan bijvoorbeeld een bot-net hiervoor gebruiken.

Of om het in geld uit te drukken: als het een stuiver kost voor ieder uur dat een cpu eraan moet besteden, dan ben je met een 2048-bits sleutel zo'n 62.000 euro kwijt. Hoop geld, maar als je daarmee als geheime dienst staatsgeheimen kunt stelen, of als je als crimineel van een rijke Est zijn bankrekening kunt plunderen, kan het de moeite waard zijn.

[dtech]

Bedenk wel dat deze getallen zijn voor een gekraakte implementatie van RSA. Conclusie is vooral dat voor huis-tuin-en-keukengebruik 2048 bits RSA keys van deze implementatie nog steeds veilig zijn.

Voor (vooralsnog) ongekraakte implementaties is een 1024-key nog steeds niet praktisch te achterhalen, zelfs niet met state-level/NSA resources.

[MSalters]

Precies. Je kunt problemen met een defecte RSA implementatie niet generaliseren naar correcte RSA implementaties. Als ik een RSA implementatie maak, en de Random Number Genereator initialiseer met het aantal seconden sinds 1-1-1970 (een gebruikelijk methode voor simpele RNG's) dan is zelfs een 8192 bits key in minuten te kraken.

Anders gezegd, het probleem is niet het aantal bits aan de uitgang, maar het aantal random bits in de interne key generatie.

[deadinspace]

Voor (vooralsnog) ongekraakte implementaties is een 1024-key nog steeds niet praktisch te achterhalen, zelfs niet met state-level/NSA resources.

Onderzoekers hebben begin 2010 een 768-bit RSA sleutel gekraakt. Dat kostte 2000 CPU-jaren op een single core AMD Opteron. Een 1024-bit RSA sleutel kost ongeveer 1000 keer zoveel werk om te kraken, dus 2 miljoen CPU-jaren.

Als je er van uit gaat dat een moderne CPU 2.5 keer zo snel is per core en 8 cores heeft, dan heb je het over 100.000 CPU-jaren. Dat is ruim een maand op een miljoen CPU's, niet ondenkbaar met cloud computing of botnets. De grootste supercomputer van de wereld heeft 10 miljoen cores dus ik vermoed dat die het ook in grofweg een maand of twee kan.

Ja, dat zijn serieuze resources, maar wel degelijk haalbaar voor state/NSA level adversaries, als ze echt willen.

Bovendien kun je ook risico's lopen als een algoritme in de nabije toekomst te kraken is. Iemand kan nu je RSA-1024 encrypted verkeer onderscheppen, over 10 jaar goedkoop kraken, en dan de verkregen informatie alsnog tegen je gebruiken (bijvoorbeeld door een nog steeds geldig wachtwoord/key uit de gekraakte stream te halen).

Al met al wordt RSA-1024 niet meer als veilig beschouwd. Bijvoorbeeld Chrome en Firefox accepteren al een paar jaar geen certificaten met 1024-bit RSA meer.

[Reactie gewijzigd door deadinspace op 23 juli 2024 06:21]

[Skamba]

Hoe kom je aan dat 1024 slechts 1000 keer zoveel is om te kraken? Voor zover ik weet, is iedere bit een verdubbeling van de complexiteit. De 256 bit verschil zou dan eerder ~10⁷⁷ keer zo lastig zijn.

[deadinspace]

Hoe kom je aan dat 1024 slechts 1000 keer zoveel is om te kraken?

Dat staat letterlijk in de eerste link in mijn post:

Factoring a 1024-bit RSA modulus would be about a thousand times harder, and a 768-bit RSA modulus is several thousands times harder to factor than a 512-bit one.

.

Voor zover ik weet, is iedere bit een verdubbeling van de complexiteit. De 256 bit verschil zou dan eerder ~10⁷⁷ keer zo lastig zijn.

Dat weet je dan verkeerd

Je hebt gelijk dat dit zo is als elke sleutel even waarschijnlijk is. Als een aanvaller op de een of andere manier weet welke sleutels hij wel moet proberen, en welke niet, dan wordt dit getal kleiner.

Stel, BlaatCrypt™ heeft 20-bit sleutels. Hoeveel berekeningen moet een aanvaller doen voor een brute-force aanval? 2²⁰ ~= 10⁶. Maar wat nou als in BlaatCrypt™ geldige sleutels deelbaar moeten zijn door 101? Dan heeft BlaatCrypt™ dus maar 2²⁰ / 101 = 10381 ~= 10⁴ geldige sleutels. Dus hoeveel berekeningen moet een aanvaller doen? 10⁴! Ondanks de 20-bit (10⁶) sleutellengte.

In de cryptografie wordt dit fenomeen aangeduid met cryptographic strength, gemeten in bits. BlaatCrypt™ heeft een key length van 20 bits, maar slechts een cryptographic strength van log2(2²⁰ / 101) ~= 13.3 bits.

Voor sommige ciphers, zoals AES, geldt dat cryptographic strength ~= keylength. AES-128 biedt dus ongeveer 128 bits aan beveiliging. Prima.

Maar hoe zit het bij RSA? Het voornaamste deel van een RSA public key is de modulus n, welke het product is van twee enorme priemgetallen. Om een RSA-sleutel te kraken hoeft een aanvaller alleen maar te vinden door welke getallen n deelbaar is. Omdat dit gebruik maakt van de wiskundige structuur van getallen hebben we daar veel snellere manieren voor bedacht dan simpelweg alle mogelijke delers uitproberen.

Het resultaat van de huidige situatie is dat RSA-1024 slechts ordegrootte 80 bits aan beveiliging biedt. En RSA-768 ongeveer 10 bits (factor 1024) minder dus. Zie bijvoorbeeld de tabel onderaan deze pagina voor meer waarden. Dit zijn de NIST-recommendations voor minimale (RSA) sleutellengtes. Ik heb al eens eerder hier op tweakers daar een reactie over geschreven.

Overigens, als beveiliging ~= sleutellengte opging voor RSA, dan zou RSA-2048 ook 2048 bits aan beveiliging leveren, en dat is meer dan we nodig hebben. Ook daar heb ik een keer een reactie aan gewijd.

[Verwijderd]

Een 2048-bits RSA keypair kost best wel veel tijd om te genereren, zeker op een smartphone. Voor PC's is een 4096-bit RSA keypair nog wel te doen.

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:21]

[Verwijderd]

Is het een bug of een feature ?

Eerste kwartaal van 2011 heeft Intel voor 1.4 miljard dollar de 3G/4G chip afdeling van Infineon overgenomen. Voor zo'n grote overname is toestemming van toezichthouders van de betrokken landen nodig.
In 2012 is de bug in de tpm's van Infineon geïntroduceerd.
Is Infineon onder druk gezet door bijv. BND of NSA om een 'bug' in zijn TPM's te introduceren omdat anders genoemde overname afgekeurd zou worden ?

Ironisch dat Infineon's CEO Peter Bauer de verkoop van het 3g/4g chip onderdeel rechtvaardigde door te vertellen dat Infineon zich ging concentreren op chips voor auto's en security ...

[robvanwijk]

Is Infineon onder druk gezet door bijv. BND of NSA om een 'bug' in zijn TPM's te introduceren omdat anders genoemde overname afgekeurd zou worden ?

Nee.

De NSA heeft een boel dubieuze dingen gedaan, maar het probleem is dat hun prioriteiten anders liggen dan die van (privacy-bewuste) burgers, niet dat het een stel incompetente prutsers zijn die geen enkel inzicht hebben in waar ze mee bezig zijn.

Zal het de NSA aan hun reet roesten dat talloze Esten slachtoffer worden van identiteitsfraude? Ja uiteraard; als je geen Amerikaans paspoort hebt dan kun je lekker omhoog vallen. Maar kijk nog eens goed naar de getroffen bedrijven, daar zitten een paar van de grootste Amerikaanse bedrijven tussen. Het wil er bij mij niet in dat de NSA willens en wetens Google, HP en Microsoft torpedeert. Zowel Rusland als China hebben meer dan genoeg resources om hier hun voordeel mee te doen en die bedrijven hebben talloze Amerikaanse gebruikers (zowel personen als andere bedrijven), precies degenen die de NSA wél probeert te beschermen.

[Verwijderd]

Ben je vergeten dat NSA aan het bedrijf RSA Security miljoenen heeft betaald om in bsafe crypto library Dual_EC_DRBG default te maken waarvoor NSA een exploit heeft ?

https://www.reuters.com/a...udy-idUSBREA2U0TY20140331

[robvanwijk]

Ben je vergeten dat NSA aan het bedrijf RSA Security miljoenen heeft betaald om in bsafe crypto library Dual_EC_DRBG default te maken waarvoor NSA een exploit heeft ?

<devil's advocate>
"waarvoor de NSA mogelijk een exploit heeft"
<devil's advocate>

In dat geval ging het erom dat de standaard een aantal getallen gebruikt waarvan niet duidelijk is waar ze vandaan komen. Het is mogelijk om, bij het kiezen van die getallen, zodanige keuzes te maken dat je de "willekeurige" getallen die gegenereerd worden kunt voorspellen. Maar, dat werkt alleen bij het kiezen; achteraf terugrekenen wat de speciale relatie tussen die getallen is (en daarmee de resultaten voorspelbaar maken) is niet mogelijk.

In dit geval is het mogelijk om sleutels te kraken met als enige "voorkennis" een hele rij andere sleutels die door hetzelfde ding gegenereerd zijn. Dit is precies het soort backdoor wat door "de tegenpartij" (of, in dit geval, academici) gevonden en misbruikt kan worden. Dit is het soort backdoor dat je zou bedenken als je niet weet waar je mee bezig bent. Met andere woorden: ik zie de NSA er zonder meer voor aan dat ze hier een backdoor in willen en dat ze evil genoeg zijn om dat (hetzij via chantage, hetzij via omkoping, hetzij via nog smeriger trucjes) ook te doen. Maar ze zijn veel te slim om het op zo'n ontzettend klungelige manier te doen, die zo'n enorm risico met zich meebrengt om zichzelf keihard in hun eigen voet te schieten.

[Armin]

Dual_EC_DRBG default te maken waarvoor NSA een exploit heeft ?

Ja, maar die "exploit" was een private-public key. Omdat de NSA als enige de private key had is dat dus in feite geen gewone backdoor.

Overigens als je je verdiept in deze bug, zie je dat het gewoone en fout in het implementatie algorithme was. Dus theorieen kunnen gewoon de prullenbak in.

De oplossing van Microsoft is overigens een interessante: al vorige maand werd al support om de software versie van dit algorithme te gebruiken ipv die ingebouwd in de TPM geintroduceerd. En deze maand wordt die geactiveerd voor de defecte TPM's.

[rbr320]

Met andere woorden, een bedrijf heeft een library gemaakt met daar in een slechte eigen implementatie van RSA, een encryptieprotocol dat in principe als zeer veilig mag worden beschouwd. Ik hoop dat men hier lering uit trekt en in het vervolg gewoon de gratis en open source variant gebruikt die zichzelf ruimschoots heeft bewezen.

[begintmeta]

Ik zou niet weten welke gratis open-sourcevariant op de bewuste chips van Infineon zou moeten kunnen draaien, heb jij hem al gevonden?

In iedergeval mag het BSI nog eens naar het certificatieproces kijken.

[Reactie gewijzigd door begintmeta op 23 juli 2024 06:21]

[Dryhte]

Ik las op Ars Technica dat er chips met deze gebreken gebruikt zijn in e-ID's. Ik vraag me af hoe het staat met de e-ID's gebruikt in België (en Nederland)... Hoe kan je nagaan of je ID kwetsbaar is?

[RaZer0r]

Ik heb net een check gedaan op mijn publieke keys van men BE-eID en die zijn veilig gebleken.

[Dryhte]

Voor wie het mocht interesseren, ik kreeg antwoord van de belgische 'dienst eID' waarin men stelt dat de keys op de belgische eIDs niet door de libraries met de vulnerability gegenereerd worden.

[Dryhte]

Hoe deed je dat dan? Ik heb geen e-id lezer, heb dus nog nooit gezien hoe die keys op de kaart te vinden zijn.

[RaZer0r]

Die zijn te verkrijgen via de kaartlezer hoor . Als je een verificatie doet van de geldigheid worden deze toch( in osx) in de Keychain opgeslagen. Daarna is het maar een kwestie van exporteren naar een leesbaar formaat en door de tool te gooien

[Verwijderd]

2048b in Belgische e-ID. Impact is dat iemand fake info op zijn kaart kan zetten.

Belgische e-ID's hebben in elk geval Infineon chips:
https://eid.belgium.be/si...age-attachments/rn429.pdf

[Reactie gewijzigd door Verwijderd op 23 juli 2024 06:21]

[Dryhte]

blijkbaar zijn alleen de sleutels die door die infineon library gegenereerd zijn, kwetsbaar. (zie het artikel bij Ars Technica https://arstechnica.com/i...ty-keys-750k-estonian-ids )

Dus ik zou graag weten hoe je kan nakijken of je public key hiervoor kwetsbaar is (normaal kan je uit de public key de private key niet afleiden, alleen kan dat wel voor de keys die gegenereerd zijn door de infineon library in kwestie)

[Verwijderd]

Als je je publieke sleutel hebt kun je het volgende gebruiken: https://github.com/crocs-muni/roca

[Arum]

In dat artikel op https://arstechnica.com/i...y-keys-750k-estonian-ids/ staat een link naar een tool om te checken of je key veilig is:
https://keychest.net/roca

[SteveWoz]

Door toegang tot een privésleutel kan een aanvaller zich bijvoorbeeld voordoen als het doelwit of versleutelde communicatie inzien, aldus de onderzoekers.

Maar dat kan alleen als ze jouw publieke sleutel hebben (en ze weten waar jouw smart card voor dient).

[Royale de Luxe]

Ze stellen toch duidelijk dat de boel te kraken is binnen de zoveel uur:

De door de chips geproduceerde rsa-sleutels zijn vatbaar voor een zogenaamde factorization attack. Dit betekent dat de publieke sleutel de privésleutel kan onthullen, wat nooit zou mogen gebeuren. Volgens de onderzoekers is het mogelijk om met een Intel E5-2650 v3 op 3GHz een 512bit-sleutel in 2 cpu-uren te kraken. Voor een 1024bit-sleutel is dat 97 dagen en een 2048bit-sleutel vereist 140 jaren. Er zou nog geen manier zijn om 4096bit-sleutels aan te vallen, al zou dat wel kunnen zodra de aanval is verbeterd.

[SteveWoz]

Ze stellen toch duidelijk dat de boel te kraken is binnen de zoveel uur.

Dat klopt, maar je zou wel eerst de publieke sleutel moeten bemachtigen voordat je überhaupt tot kraken over kunt gaan. En daarnaast moet je weten welke applicatie de sleutels hebben, anders heb je iets gekraakt waarvan je niet weet wat je ermee kan.

[ShenkieDeGrote]

Publieke sleutels zijn in principe niet geheim en worden overal opgeslagen. De publieke sleutel van je Bitcoin portemonnee is bijvoorbeeld overal bekend, stel je voor dat de privé sleutel van je portemonnee op deze manier gekraakt word dan ben je alles kwijt zonder dat mensen mee hebben gekeken met je verkeer o.i.d.

[SteveWoz]

Dat begrijp ik. Mijn punt is dat je eerst een publieke sleutel moet bemachtigen en weten waarvoor die dient. Ik weet jouw publieke sleutel voor je bitcoin portemonnee toch niet. Eveneens weet ik de publieke sleutel van jouw bedrijfspas niet. Ik kan me dus niet zomaar uit gaan geven voor ShenkieDeGrote en daarnaast je bitcoins bemachtigen. Geef me een willekeurige publieke sleutel die je gebruikt. Die zou ik vervolgens kunnen kraken. Dan weet ik nog steeds niet wat ik ermee moet, want ik heb geen idee waar de sleutel voor dient.

[Cilph]

Volgens mij kun je de public key triviaal uitrekenen als je de private key al hebt.

[RJG-223]

Algoritme-technisch is er zover ik weet geen verschil tussen de publieke sleutel en de (echte) private sleutel. Er worden twee sleutels gegenereerd die elkaars tegenhanger zijn (dwz: wat met de ene sleutel versleuteld is, kan (enkel) met de ander sleutel ontsleuteld worden). Één van die sleutels wordt als 'privé' bestempeld, en één wordt als 'publiek' bestempeld. Maar dat had net zo goed andersom kunnen zijn.

Dus wat doorgaans de 'private sleutel' genoemd wordt, is waarschijnlijk in feite de combinatie van publieke en private sleutel. En daaruit kun je inderdaad triviaal de publieke sleutel bepalen :-)

Maar als je dus echt alléén de private sleutel bezit, dan is de publieke sleutel net zo moeilijk uit te rekenen als andersom.

[Verwijderd]

Maar als je dus echt alléén de private sleutel bezit, dan is de publieke sleutel net zo moeilijk uit te rekenen als andersom.

Nee hoor, bij RSA is het doodsimpel om van de private sleutel naar de publieke te gaan: ruwweg bestaat de prive sleutel uit 2 grote priemgetallen p en q, de publieke sleutel uit het product n = pq. Als je alleen n hebt kost het heel veel werk om daar p en q uit te halen (factorisatie is lastig). Als je p en q hebt kun je n zo uitrekenen (vermenigvuldigen is eenvoudig).

[RJG-223]

Zeker wel. Lees de theorie er maar eens op na.

Het produkt n = pq is een onderdeel van zowel de publieke sleutel, als de privé sleutel.

Een andere eigenschap van RSA, is dat je ook met de privé sleutel kunt encrypten, zodat iemand anders met de publieke sleutel kan decrypten. Die eigenschap wordt voor authenticatie gebruikt. Als de privé-sleutel uit p en q bestond, dan was authenticatie met RSA niet mogelijk.

[Verwijderd]

Als je echt in de details gaat kijken is het niet altijd duidelijk wat men opslaat onder "private key", maar in de praktijk kun je van wat men gewoonlijk als private key opslaat makkelijk de public key terughalen. Zie o.a. de discussie op https://stackoverflow.com...ey-to-generate-public-key

[MSalters]

Natuurlijk weet je de publieke sleutel van z'n bitcoin wallet. Dat is namelijk het adres, en dat adres staat hard in de Block Chain. Sterker nog, de publieke sleutels van alle niet-lege wallets staan in de Block Chain.

[RJG-223]

Het is een beetje kort door de bocht om er vanuit te gaan dat je tegenstander niet weet waarvoor een sleutel dient. Je kunt (moet) er vanuit gaan dat ie dat wel weet. Je zou verbaasd staan als je wist hoeveel anderen over jou weten.

Daarnaast: als je beveiligde communicatie wilt ontvangen, dan kan dat alléén als je aan andere mensen jouw publieke sleutel vertelt. Als je met RSA authenticatie beveiligd wilt inloggen op een server, dan moet die server jouw publieke sleutel hebben. Als jij een https server hebt, dan zul je andere mensen de publieke sleutel daarvan moeten geven zodat ze een beveiligde verbinding kunnen opzetten. Als je een certificaat wil aanvragen bij een certificate authority, dan moet je hun jouw publieke sleutel geven. Etc. etc. etc.

Misschien RSA voor jou alleen zichtbaar is bij jouw bitcoin wallet of jouw ge-encrypte harde schijf, betekent niet dat het alleen daarvoor gebruikt wordt. Sterker nog: voor die toepassingen is RSA zelfs niet eens nodig, en voldoet een niet-assymetrisch algoritme ook perfect. De kracht van RSA is juist dat het assymetrisch is (dwz privé en publieke sleutel zijn verschillend), en je het dus kunt gebruiken om beveiligd met anderen te communiceren zonder last te hebben van de problemen van het veilig verspreiden van een geheime sleutel.

[robvanwijk]

En daarnaast moet je weten welke applicatie de sleutels hebben, anders heb je iets gekraakt waarvan je niet weet wat je ermee kan.

Ergens heb je een punt, maar van de andere kant, je gaat toch ook niet je pincode hier posten omdat ik eerst nog je pinpas moet stelen voordat ik misbruik kan maken van de code?

Daarnaast, bij een heleboel van deze sleutels is het waarschijnlijk zeer eenvoudig om zowel de publieke sleutel (die immers bedoeld is om links en rechts rond te strooien!) en "het doel" te achterhalen. Ik weet bijvoorbeeld niet precies waarvoor Estland hun id-kaart gebruikt, maar als je er iets mee kunt ondertekenen ("ik ben 18+" om drank te kunnen kopen!?), dan gaat het meteen mis: om een ondertekening te kunnen controleren moet je de publieke sleutel hebben, dus het zit er dik in dat je simpelweg aan de Estse overheid kunt vragen "wat is de publieke sleutel van Pietje?" en dan netjes antwoord krijgt.

Voor de duidelijkheid: ik ken de details van het Estse systeem niet, dus bovenstaande is speculatie, maar de kern van het verhaal (publieke sleutels te pakken krijgen en achterhalen waar je die kunt misbruiken) is in veel gevallen hartstikke simpel.

[RJG-223]

Maar dat kan alleen als ze jouw publieke sleutel hebben (en ze weten waar jouw smart card voor dient).

Maar je kunt er vanuit gaan dat de publieke sleutel bij tegenstanders bekend is. Het is niet voor niets een publieke sleutel. En voor nuttig gebruik van RSA encryptie is het overigens (bijna) noodzakelijk dat de publieke sleutel bekend is bij mensen die je niet kunt en/of niet wilt vertrouwen. Bijvoorbeeld het volledig bona-fide bedrijf waarmee je zaken wilt doen.

[E-Flex]

Worden zulk soort chips niet uitgebreid getest en geaudit voor een bedrijf of overheid besluit ze in gebruik te nemen?

[Sandor_Clegane]

Complexe materie, zie GOTO FAIL.

Wel zuur, denk je het goed te doen door een HSM te nemen, blijkt die slecht te zijn.

[robvanwijk]

Worden zulk soort chips niet uitgebreid getest en geaudit voor een bedrijf of overheid besluit ze in gebruik te nemen?

Testen is sowieso zinloos:

quote: https://www.cs.utexas.edu...tions/EWD03xx/EWD303.html

program testing can be used very effectively to show the presence of bugs but never to show their absence.

Ja, daar staat "never". Ja, daar wordt ook echt "never" bedoeld. Wat je moet doen is aantonen dat je code (of, je algorithme) correct is, niet dat je geen fouten kunt vinden.

Het probleem is dat je dan wel precies moet weten wát je gaat bewijzen. In dit geval: het bewijs dat je een correct key pair gegenereerd hebt is prima te doen (p is priem, q is priem en n = p*q; makkelijk zat), maar bewijzen dat je key pair veilig ("onkraakbaar") is... Dat komt eigenlijk neer op "de snelste manier om deze key te kraken is door alle mogelijkheden uit te proberen (brute force attack)", met andere woorden "er bestaat geen manier, wezenlijk sneller dan brute force, om deze key te kraken". Tja, dan moet je iets gaan zeggen over elke methode om een key te kraken, dat kan natuurlijk niet.

Ik heb de details van de aanval nog niet bestudeerd. Maar "Ze vonden de kwetsbaarheid door een groot aantal rsa-sleutels in smart cards te analyseren." lijkt te suggereren dat als je slechts één key gegenereerd zou hebben, dat dan "het patroon" niet duidelijk is en die ene sleutel gewoon veilig is. Pas als je talloze keys genereert valt er "iets" op en wordt kraken mogelijk. Dat maakt het bovenstaande bewijs "nog onmogelijker" dan het toch al was.

[E-Flex]

Wow, dat is best wel scary.

[Verwijderd]

Klok, klepel.

Het bewijs dat een key pair "veilig" is, is al inherent aan de onderliggende wiskunde van RSA. Dat is ook niet wat er mis is gegaan. Wat Infineon verkeerd deed, is dat ze p en q niet volledig willekeurig genereerden (wat de onderzoekers in het kort hebben omschreven op hun pagina). Daardoor is er een grote verzameling combinaties uit te sluiten en zakt de complexiteit van een brute force-aanval keihard ineen. Key pairs die met OpenSSL zijn gegenereerd zijn bijvoorbeeld niet kwetsbaar.

[Rodeobull]

Hoelang zou zoiets duren met een 12xGPU rig

[dabronsg]

hangt van de GPU's af die je gebruikt...

[Rodeobull]

offcourse

En natuurlijk wat voor algoritme gebruikt word. RSA encryptie?

Zou je dat ergens kunnen uitrekenen? weet iemand dat?

[equit1986]

hangt er van af of de GPU's goed zijn in het encrypten en decrypten van RSA algoritmes.
Het kan best zijn dat CPU's hier beter in zijn. En dan zijn er nog giga verschillen in type CPU's, bijv Intel sneller dan AMD, of vice versa.

[Verwijderd]

Betekent dit dat de Calypso-types kaarten voor het openbaar vervoer opnieuw kraakbaar zijn?

[xorpd]

Pas op 2 november wordt de gebruikte methode uit de doeken gedaan, tot die tijd blijft het speculeren. Ik zal eens kijken naar de software implementatie van Infineon.

[Verwijderd]

Gelukkig dat ik me geen zorgen hoef te maken: mijn pgp keys zijn geen RSA maar ElGamal, mijn mailserver certificaat is gegenereerd op een Intel CPU en Signal gebruikt geen RSA maar elliptic curve als asymetrisch algorithme.

[robvanwijk]

Totdat je verbinding maakt met online bankieren en jouw computer het certficaat van de website probeert te valideren, wat wel RSA kan zijn.

Hoe realistisch het is dat die sleutel op een Infineon chip is gegenereerd is een andere vraag, maar "de eerste drie dingen die in me opkomen gaan goed, dus ik heb hier geen last van" is extreem kortzichtig.

[keranoz]

Hangt er in dat geval maar net vanaf of het online bankieren platform gebruikt maakt van 512, 1024, 2048 of zelfs 4096 bits. In de laatste twee gevallen is dit probleem helemaal niet relevant staat denk ik. In het artikel staat dat 2048bit al 140 jaar duurt op een redelijk dikke Xeon...

[robvanwijk]

In het artikel staat dat 2048bit al 140 jaar duurt op een redelijk dikke Xeon...

Als het goed te parallelliseren is (dat is een aanname, maar wel een realistische), dan duurt het op 140 van die Xeons opeens nog maar 1 jaar; gooi er 1680 machines tegenaan en het duurt een maand...

Edit:
Uit de bron gelinkt vanuit het artikel:

quote: https://crocs.fi.muni.cz/public/papers/rsa_ccs17

The factorization can be easily parallelized on multiple CPUs. Where k CPUs are available, the wall time required for the attack will be reduced k-times - allowing for practical factorization in order of hours or days.

Oftewel: perfecte scalablity, het ideale geval voor de aanvaller.

[Reactie gewijzigd door robvanwijk op 23 juli 2024 06:21]

[keranoz]

Ik snap het principe, maar al die processing power lijkt me niet het kraken van 1 apparaat waard. Beetje "cost > benefit" lijkt me.

[robvanwijk]

Dat hangt er helemaal vanaf welke sleutel je kraakt! Die smart cards waar het artikel het over heeft worden bijvoorbeeld gebruikt in two-factor authentication. Ik denk dat je behoorlijk interessante informatie kunt vinden als je (bijvoorbeeld) de servers van Google kunt vertellen "Hoi, ik ben Larry Page, kijk maar, hier is mijn smart card". Ook het kunnen faken van de id-kaart van de leden van het Estse kabinet, of de directeuren van grote Estse bedrijven kan de moeite meer dan waard zijn (zeker voor de Russische overheid; die hebben geen al te goede relatie met Estland).

[DonDaaf]

RSA is niet gekraakt hoor. Het is de implementatie (in een crypto-library) van RSA in een specifieke chip van Infineon.