Onderzoekers waarschuwen dat rc4 in de praktijk snel te kraken is

De encryptiemethode rc4 die onder andere gebruikt wordt in wpa-tkip-versleutelingen en het tls-internetbeveiligingsprotocol, kan inmiddels in 52 uur gekraakt worden. Dat hebben onderzoekers van de Katholieke Universiteit in Leuven gedemonstreerd.

Hoewel het gebruik in de afgelopen jaren is afgenomen, wordt rc4 nog ongeveer in 30 procent van https-verbindingen gebruikt, stellen de onderzoekers Mathy Verhoef en Frank Piessens op een website die ze speciaal hebben opgezet om mensen af te raden om rc4 in te zetten. In een video tonen de Belgen hoe een aanvaller een cookie onderschept van een website die op tls-beveiliging met rc4-versleuteling draait. Daarna wordt de cookie in korte tijd ontsleuteld en is de aanvaller ingelogd op een website alsof hij daadwerkelijk de gebruikersnaam en het wachtwoord van zijn slachtoffer heeft achterhaald.

Volgens de onderzoekers is een dergelijke aanval inmiddels in de praktijk uitvoerbaar. "We verwachten dat dit soort aanvallen in de toekomst alleen maar verder ontwikkeld worden", zeggen ze. De twee Belgische onderzoekers zullen volgende maand hun bevindingen presenteren op het Usenix Security Symposium in Washington.

Microsoft waarschuwde in 2013 al dat websites en bedrijven niet langer rc4-encryptie moeten toepassen vanwege haar kwetsbaarheid. Rc4 stamt oorspronkelijk uit 1987.

Reacties (57)

Goed filmpje, duidelijke uitleg en een "mooi" resultaat.
Zou je deze vorm van encryptie niet als onveilig moeten vlaggen in een browser? Zodat men zich niet vals veilig voelt?

Firefox accepteert al geen RC4 meer in de initial handshake. De enige uitzondering zijn een paar grote sites op een whitelist. Mozilla heeft contact met die beheerders en weet dat ze bezig zijn met het uitfaseren.

Ik geloof dat het alleen nog wel aan te zetten is als fallback. De discussie over het volledig onmogelijk maken (en stoppen met de whitelist) wordt op dit moment gevoerd.

[Reactie gewijzigd door Maurits van Baerle op 16 juli 2015 16:09]

Klopt en ter volledigheid, deze truc is oorspronkelijk bedacht door Microsoft en in 2013 voor het eerst geimplementeerd in Windows 8.1 en IE 11. De truc is simpelweg officieel 'liegen' en zeggen dat je geen RC4 ondersteund. Enkel indien de handshake dan faalt met de specifieke foutmelding dat er geen passende cipher gevonden kan worden, probeert men het opnieuw maar dan mét RC4 in de lijst. Ook Windows Phone 8.1 ondersteunt deze truc.

Daarnaast is Microsoft toen begonnen met het contact zoeken met websites die enkel RC4 ondersteunden en heeft tegelijk een RFC draft opgesteld die RC4 officieel verbied voor servers in combinatie met TLS 1.1 en 1.2.

Firefox heeft sinds eind vorig jaar deze techniek van Microsoft overgenomen, en de RFC is sinds januari 2015 officieel geaccepteerd. Nu Chrome en Safari dus nog en dan in de praktijk is RC4 dus eigenlijk al verdwenen.

Overigens gebied eerlijkheid te zeggen dat in de praktijk deze aanval vooral zeer theoretisch is. Het werkt enkel bij authenticatie cookies, én de client moet al die tijd actief blijven, én de server moet deze grote hoeveelheid aanvallen (zowel in aantallen als aantallen oper tijdseenheid) zomaar accepteren. Maar aanvallen worden altijd beter met de tijd, dus is het inderdaad een goede zaak RC4 uit te faseren.

Merk tenslotte op dat zoals helaass tegenwoordig wel vaker de onderzoekers het minder relevante maar wel PR aantrekkelijke deel hypen, maar het veel leukere deel niet promoten. Dat de aanval op RC4 in combinatie met TLS nu van 75 naar 52 uur teruggebracht is, is leuk, maar verandert weinig aan de praktijk.

Wat wél interessant is, is dat de aanval op WPA-TKIP hetgeen RC4 intern gebruikt nu teruggebracht is tot één uur. Let wel, het gaat om WPA-TKIP en niet WPA-AES, en al helemaal niet om WPA2 wat sinds 2004 de standaard is. Maar toch, één uur is daadwerkelijk haalbaar. Dus na WEP is nu ook WPA-TKIP echt kraakbaar.

Merk tenslotte op dat zoals helaass tegenwoordig wel vaker de onderzoekers het minder relevante maar wel PR aantrekkelijke deel hypen, maar het veel leukere deel niet promoten. Dat de aanval op RC4 in combinatie met TLS nu van 75 naar 52 uur teruggebracht is, is leuk, maar verandert weinig aan de praktijk.

Da's niet wat er staat. De eerste aanval op RC4 duurde meer dan 2000 uur. Later is dat verbeterd naar 312 tot 776 uur, en nu komen deze onderzoekers met een aanval die 52-72 uur duurt. Zo'n 6 à 10 keer sneller dan de vorige dus. Dat noem ik wel significant.

Bron: http://www.rc4nomore.com/#compare

Je hebt deels gelijk, ik gooi mijn onderzoeken door de war. In 2013 (maar dat was geen end-to-end aanval!!!) zou het 2000 uur duren. Nu 75-52 uur. Die van 2014 moet ik even opzoeken, maar zat daar tussenin als ik het me goed herrinner.

(EDIT: opgezocht en het in 2014 was 776 uur voor semi-realistische omstandigheden, en 312 uur voor intranet achtige omstandigheden om bijvoorbeeld BasicAuth te kraken over TLS. Zij hebben echter minder berekeningen nodig, maar hun setup duurt langer per transfer omdat ze een alternatieve methode gebruiken.)

Echter de vooruitgang tussen de 2013 en deze aanval is enkel dat men de request sneller maakt. Dus qua effect inderdaad een vooruitgang, maar niet echt revolutionair. Het is dezelfde truc als in 2013 gebruikt was, maar dan meer requests per tijdseenheid.

Punt is echter dat als je de requests met X keer verhoogt de kans dat een server je gaat weigeren (denk aan DoS bescherming) ook flink toeneemt. Dus of de praktische aanval op TLS echt toegenomen is, betwijfel ik.

Echter het minder gehypte deel, namelijk de aanval op WPA-TKIP, is wél een echte vooruitgang. Immers WiFi accesspoints kennen geen DoS beschermingen en het is vrij makkelijk met een laptop in een geparkeerde auto zo'n aanval te doen uitvoeren. Het kost nu maar een uurtje. Dus het wordt nu echt tijd WPA1 uit te faseren.

[Reactie gewijzigd door Armin op 16 juli 2015 18:34]

Er staat dat de aanval van 2013 13958643712 (13*2^30) requests nodig heeft, terwijl deze nieuwe aanval 1207959552 (9*2^27) requests nodig heeft. Dus puur op basis daarvan is de aanval al een stuk beter. En in het filmpje laten ze dan ook nog eens zien dat ze meerdere cookies testen, volgens mij deed de vorige aanval dit niet?

Daarbovenop sturen ze dan ook nog eens sneller requests. Maar als ik het juist lees is dat dus toch niet het enige?

De 2015 aanval is een uitbouwen op de 2013 aanval. Die in 2013 was enkel theoretisch en nooit end-to-end in de praktijk gedaan.

Deze aanval is in feite 'enkel' een acceleratie van de 2013 variant en nu wel een praktijk-aanval. Goed werk, maar dus niet revolutionair daar men deze techniek gebruikte die al in 2013 ontdekt was. Dat is waar ik op doelde.

Echter ondanks de grote vooruitgang blijft deze methode heel erg moeilijk uit te voeren. Men heeft het aantal rekenstappen verkleint, maar de keerzijde is dat de server nu wel X keer meer requests en request/seconde moet accepteren zonder morren. En het blijft beperkt tot cookies en andere tokens en het aantal rekenstappen blijft onrealistisch hoog.

Ofwel: Evolutie, maar geen revolutie of doorbraak. Dwz op TLS gebied. Wél op WPA gebied. Maar de WPA aanval wordt door de meeste media minder interessant gevonden, terwijl het omgekleerde juist het geval is.

De 2014-variant vind ik bovendien nog steeds interessanter. Dat was de eerste end-to-end en dus het moment dat RC4 officieel in de praktijk gebroken was. Deze vereist 'slechts' 2^26 requests. Echter de methode is anders en trager dus heeft met wel ruim 700 uur nodig. Deze is echter niet beperkt tot cookies en dus potentieel veel gevaarlijker.

Daarna wordt de cookie in korte tijd ontsleuteld en is de aanvaller ingelogd op een website alsof hij daadwerkelijk de gebruikersnaam en het wachtwoord van zijn slachtoffer hebben achterhaald

Zit hier niet niet een minstens zo groot lek? We moeten echt van cookies af. Data voor gebruiker authenticatie moet je gewoon niet aan de client kant bewaren.

Heeft niks met client of server-side te maken, dan zouden we helemaal niks meer kunnen versturen in dat geval

Het gaat er om dat de manier van authentificatie op een veilige manier gedaan wordt, nu wordt er hooguit een versleutelde cookie geplaatst vaak. Daarom dat andere manieren zoals two factor authentication steeds meer gemeengoed worden; je meldingen krijgt als je inlogt vanaf een nieuwe locatie en dat soort dingen. Inloggen via een stevige key helpt ook aardig. Het is meer dat veel websites er geen hol om geven

Feit blijft dat RC4 onveilig blijft maar dat is gewoon een kwestie van uitfaseren en wanneer net zoals met SSL3 blijkt dat de boel écht onveilig is die ondersteuning er server-side gewoon uit knikkeren. Simpelweg even de cipher list updaten

en éénmaal je bent ingelogd na je 2factor auth. val je alsnog terug op een cookie die ze kunnen stelen, en waar men in de fout gaat met te denken dat een https-tunnel dat voorkomt...
(SSL was lek, nu dit,...)

security by obscurity.
(oh nee: sessie hyjacking mogelijk mbv firesheep: laten we het altijd in een https-tunnel verstoppen ipv enkel maar tijdens het inloggen maar er verder niets aandoen zodat als er iemand toch in die tunnel kan meekijken je alsnog je sessie kwijt kunt spelen...
of in dit geval: als iemand kan voorspellen waar de data van de cookie verstopt zit in de data van de https-tunnel - wat zij dus doen mbv MitM en wat script injection - die cookie kan bruteforcen en alsnog een sessie-hijack mbv cookie-replay kan doen ...)

je 2factor authentication gaat mogelijk helpen, maar vele sites vertrouwen er wellicht op dat éénmaal dat voorbij is hun 'we doen alleen aan https' wel voldoende is en ze niet meer op de rest moeten letten.

mijn eigen framework koppeld de cookie hard aan de combinatie van IP + browser.
1 afwijking == einde sessie.

Handig, met mobiele devices die nog wel eens van IP-adres kunnen wisselen. Of aan clients met IPv6 privacy extensions enabled (lees: Alle Windows installaties)

Het gaat om de sessie-cookie
Ik neem aan dat je IP niet tijdens een gebruikerssessie zal veranderen. Dan zou namelijk je connectie verloren zijn geweest.

Dat het per gebruikerssessie anders is maakt niet uit. Dan moet je sowieso opnieuw inloggen.

Die kan heel goed tijdens een sessie veranderen. Als ik nu een site bezoek vanuit me huis en loop de deur uit en me WiFi valt weg, ddan ga ik verder op diezelfde site over een mobiele aansluiting.

Dit doe ik zelfs vrij vaak. Op het moment dat ik de deur uit wandel pak ik vaak even de telefoon.

In zo'n geval inderdaad.
Al heeft de beveiliging bij mij geen ander gevolg dan je opnieuw de login prompt krijgt.

Het is de kleine onhandigheid met mobiele apparaten vs mogelijkheid dat je sessie gehighjacked wordt op een vreemd netwerk (open wifi's!).

Klopt, maar ik vraag me af of het middel niet erger dan de kwaal is. Ik heb een tijdje gewerkt met zo'n Dual-WAN router (router met 2 internet uplinks). Zo'n ding (althans de mijne) loadbalanced elk request over de 2 uplinks. Het bezoeken van 1 site door iemand achter zo'n router zorgt daardoor altijd voor hits vanaf 2 IPs.

Zo iemand kan je site dus eigenlijk geheel niet bezoeken. Want als de router 50/50 balanced komt elke hit van een ander IP dan de hit ervoor. Je krijgt dan dus continue een nieuw inlogscherm.

Ik zou daarom als je IP-binding wil toepassen wel kiezen voor een vinkje om dat uit te zetten.

Overigens is het probleem dat ik hierboven schets wel de reden dat ik die Dual WAN router de deur uit heb gedaan, want er zijn veel sites die IP-binding toepassen zonder het te melden. Daar kun je dan dus niet meer op inloggen.

het is natuurlijk een afweging tussen handig en veilig...
koppeling aan browser (user-agent header is natuurlijk zo te faken) misschien niet zo: als ik mbv MitM je https-tunnel kan kraken voor je cookie, dan kan ik mbv diezelfde script-injectie waarmee de 4000+ request geforceerd worden om de aanval mogelijk te maken natuurlijk ook direct even je header naar mijn server laten doorsturen ;-)
maar voor dat ip-adres dient men toch echt op die host of achter diezelfde proxy of router te zitten.

ps: mobiele devices die van ip-adres veranderen zitten vaak achter transparante round-robin proxies ;-)
(mobistar past dat toe: het externe ip-adres van je gsm verandert niet, toch zie je quasi elke request naar whatismyip 2 of meer andere ipadressen verschijnen... tenzij je natuurlijk vpn ofzo toepast om die proxies te passeren en vanuit je vpn-server de requests te doen)

Maar vooral: deze aanval laat wel zien dat security by obscurity wederom geen goed idee is: slecht cookie-beheer afschermen door al het verkeer in een https-tunnel te verstoppen is niet hoe je dat probleem oplost...
en de werkwijze van hackerhater's framework is een mogelijke oplossing.
je kunt het ook aan de tunnel koppelen
(elke https tunnel koppelen aan een eigen key/certificaat afgeleid van je hoofd certificaat en de sessie daaraan koppelen: veranderd één van beiden = einde van de cookie/sessie - ook van de originele sessie: gebruikers zullen zich snel melden, waardoor er mits logging wel kan ingekeken worden of er inderdaad een sessie-hijack heeft geprobeerd waardoor je gebruikers weer kunt geruststellen/verkopen dat je hen net beschermd hebt...)

Hoe wil je dan de sessie op de server koppelen aan een bepaalde client?

je kunt bv IP-binding toepassen, sessie aan https-tunnel koppelen, de oude sessie (vanuit IP X) droppen zodra dezelfde sessie vanuit IP Y binnenkomt.
(ja, dan ben je alsnog niet veilig voor een gebruiker die 'naast' je zit op hetzelfde subnet of achter dezelfde nat-router, maar toch al iets veiliger)

Als je als gebruiker steeds opnieuw moet inloggen en bv een melding krijgt dat de sessie tussentijds vanop een ander ip-adres bestond zal hopelijk ook het nodige doen om dat enerzijds te melden, anderszijds er zelfs verdere stappen tegen te ondernemen wegens "gehackd".
Moeten natuurlijk de providers die round-robin-transparent-proxies toepassen hun rommel wel in orde hebben ivm sessies.
(Mobistar past dat toe bij hun 3G en dat durft wel eens zulke sessies te verkloten.)
maar dat merk je dan weer wel als die melding telkens je huidige ip-adres weergeeft , dat die 'oude sessie' het ipadres was van bv 20sec. geleden...

IP binding bij cookies veranderd het mechaniek van de cookies zelf natuurlijk niet. Hoewel dat wel weer problemen kan geven bij bedrijven welke meerdere internet lijnen hebben en internet traffic loadbalancen over deze lijnen. Dat percentage is klein, maar niet verwaarloosbaar.

Een eenvoudigere methode zou natuurlijk zijn dat de cookie lifetime gewoon korter wordt gezet. Bij elke nieuwe server-side sessie zet je dan gewoon opnieuw de cookie, waarbij de ttl van de cookie dan 12 uur is. Opties zoals ingelogd blijven zijn dan helaas niet meer mogelijk wat natuurlijk best wel vervelend kan zijn op bepaalde websites zoals Tweakers of GOT.. Aan de andere kant zou elke dag opnieuw inloggen wel de veiligheid vergroten. Daarbij zullen veel gebruikers al password reminders gebruiken, waardoor het in de meeste gevallen beperkt blijkt tot op de 'log in' knop te klikken.

Maar cookies zullen een integraal onderdeel blijven van de HTTP standard omdat HTTP van nature nou eenmaal stateless is en het cookie mechanisme momenteel de enigste betrouwbare methode is om van 'stateful http' te simuleren..

Dat is ook het probleem dat ik aanhaal met het voorbeeld van Mobistar en hun transparante round-robin proxies waarop ze het sessie-beheer niet in orde hebben..
(als je pech hebt, en je bent ingelogd op een site met IP-locked-sessies, dan kan je elke x requesten opnieuw inloggen, want je zit weer maar op die andere proxy)

Voor de hacker wordt het dan wel iets lastiger want men moet ook een eigen of compromised host hebben achter diezelfde routers/proxies.
Waardoor het wel even makkelijk blijft om die cookie te verkrijgen op de hierboven vermelde manier (met een MitM-aanval eerder waar op de connectie), maar die cookie minder toepasbaar nut heeft als men niet achter datzelfde ip-adres zit.
maw: de mogelijke aanvalsvector voor de cookie-replay/sessionhijack wordt kleiner.

En zoiets doen vanop bv je werk om je collega te kloten zal in de meeste firma's het einde van de samenwerking betekenen.

Maar het was slechts één van de voorbeelden die ik gaf om het gebruik van cookies "veiliger" te maken.

(trouwens goed ingestelde load-balacing zou ook rekening moeten houden met sessies, anders worden bv vpn-connecties van werknemers of ingehuurde externe specialisten ook altijd verkloot )

Het probleem is vooral dat je als client eigenlijk nooit de site 100% kunt vertrouwen,
en als server mag je de klant nooit 100% vertrouwen.

dan mag je bv nog 3GPP-headers vanuit de server naar de klant sturen: als er iemand halfweg die headers kan manipuleren, kan de klant alsnog overtuigd worden dingen te doen die jij als oorspronkelijke server niet toeliet (externe script laden bv)

En als client mag je er eigenlijk ook niet blindelings vanuit gaan dat bv alle scripts die je krijgt van een site ook daadwerkelijk van die site's komen...

het stamt uit 1987, is het dan vreemd dat het na bijna 30!! jaar in 52 uur te kraken is?

ja en nee, een echte encryptie zou nooit te kraken moeten zijn... Die is echter nog niet uitgevonden

(technisch zijn alle encrypties te kraken, praktisch echter kan het miljoenen jaren duren)

Vergeet die miljoenen jaren maar als er zometeen kwantumcomputers zijn. Het heeft zo zijn redenen dat Den Haag een flinke bak met geld aan TU Delft heeft gegeven voor quantum computing research.

Zometeen?

Dat ding werkt in de praktijk maar fracties van een milliseconde. Ik hoop natuurlijk van harte dat de TU Delft een grote bijdrage gaat leveren aan de quantum computing in het algeheel. Maar die investering moet je eerder als algemene investering zien voor onderzoek. Het is geen bestelling voor een quantum computer hoor.

Vooralsnog is het een visie, een droom, dat een quantum computer die dit soort taken uit kan voeren op termijn beschikbaar komt, laat staan 'zometeen.'

Dat is dus niet waar. Quantum computers kunnen versleuteling welliswaar sneller kraken, maar zeker niet instantaan!
Waar een 64 bit sleutel nu 2⁶⁴ (ca. 16 triljoen) poginen nodig heeft, zou dat bij een quantum computer nog maar 64 pogingen zijn. Dat is gigantisch veel korter, maar nog steeds niet instantaan.

Nee, kwantumcomputers kunnen bruteforcen in de vierkantswortel van het aantal pogingen dat een normale computer dat moet doen. Voor een 64 bits sleutel is dat 2^32 pogingen. De oplossing is dus simpelweg het aantal bits verdubbelen. Een drumcomputer zal waarschijnlijk nooit 128 bits encryptie en zeker geen 256 bits encryptie kunnen bruteforcen.
Asymmetrische encryptie is een ander verhaal en daar hebben we (nog) geen (praktische) algoritmes die bestand zijn tegen kwantumcomputers.

Om precies te zijn is er al wel een onkraakbare encryptie uitgevonden.
One-time pad encryptie
Echter is deze voor dit soort toepassingen niet echt praktisch, aangezien er vooraf een key afgesproken moet worden die even lang is als het te sturen bericht.

[Reactie gewijzigd door Anoniem: 647778 op 16 juli 2015 16:08]

Om precies te zijn is er al wel een onkraakbare encryptie uitgevonden.
One-time pad encryptie
Echter is deze voor dit soort toepassingen niet echt praktisch, aangezien er vooraf een key afgesproken moet worden die even lang is als het te sturen bericht.

Kun je dan nog wel van encryptie spreken? Want feitelijk verplaats je dan het hele probleem alleen naar een andere plaats/tijd, namelijk het uitwisselen/bewaren van de sleutel, waardoor de sleutel de rol van cipher-text in gaat nemen.

Ik denk het wel, alleen het gaat om de situatie:
Een mogelijke oplossing is dat de key van te voren in een veilige omgeving wordt uitgewisseld. Niet handig voor internet gebruik zoals omschreven in het artikel, waar A en B nooit een vertrouwde omgeving zullen delen. Maar neem bijvoorbeeld een militair die wordt uitgezonden. Als die van te voren op de basis 10 GB aan random bits heeft uitgewisseld. Dan kan deze vervolgens (theoretisch) 10 GB aan data veilig uitwisselen.

Omdat het toch al om quantummagie gaat: zo'n sleutel kan je dan delen via quantumcryptografie, iets anders dan 'quantumcomputers' en al in een veel verder ontwikkeld stadium. (banken in Zwitserland gebruiken het als tweede middel, kort door de bocht gezegd). Quantumcryptografie gaat eigenlijk gewoon via een kanaal wat iedereen kan afluisteren, maar als dat daadwerkelijk ook wordt gedaan dan kan je er vrij, maar niet 100% zeker van zijn dat dat ook daadwerkelijk gebeurt. Je zet dus een verbinding op, kijkt of ie wordt afgeluisterd, en als ie veilig is, dan deel je je sleutel.

Uh, een one time pad kan niet gekraakt worden.

One time pads zijn niet te kraken...

encryptie is altijd een afwegen tussen hoelang moet je data veilig blijven en hoelang duurt het om die te hacken, en wat is je data waard vs hoeveel kost het om die tijdig te hacken...

Als je zoals hier een hack kunt terugbrengen van 2000 uren naar 50 uren, wat wellicht nog sneller kan door verdere optimalisering en/of snellere hardware, dan weet je dat die encryptie lek is en al lang had afgevoerd moeten worden.
(WPA2-TPIK kan zelfs nog sneller volgens hun paper - de 40-voudige reductie gaat over de sessie-hijack mbv cookie-replay waarbij de cookie uit de https-tunnel werd "gestolen")

Leeftijd zegt op zich niet zoveel over de veiligheid... er zijn wel meer oude ciphers die nog steeds niet gekraakt zijn. Denk aan de Beale Ciphers uit 1885 (!), die na 130 jaar nog steeds niet is gekraakt. Of de Dorabella Cipher uit 1897. En zo zijn er nog wel meer

Als je het daarmee vergelijkt is 30 jaar dus nog niet zoveel

Lol, lees ik die Baele Ciphers nu goed? Gaan we op schattenjacht? Lijkt me wel lachen om eens een keer over die cijfers te buigen

Niet dat ik ook maar iets van resultaat verwacht. Iets zegt me dat met mijn beperkte encryptie kennis alles wat ik kan verzinnen al ooit uitgeprobeerd is

Dorabella is ontcijferd hoor

AES is inmiddels ook bijna 15 jaar oud Goede cryptologie verouderd niet.

"To put this into perspective: on a trillion machines, that each could test a billion keys per second, it would take more than two billion years to recover an AES-128 key"
"Indeed, we are even not close to a practical break of AES at the moment. "

Goeie passive-aggressive LMGTFY link trouwens!

Er zijn efficientere methodes om AES te kraken dan er een rainbowtable tegen aan te gooien http://research.microsoft...s/cryptanalysis/aesbc.pdf

Er zijn efficientere methodes om AES te kraken dan er een rainbowtable tegen aan te gooien http://research.microsoft...s/cryptanalysis/aesbc.pdf

Rainbow tables hebben niets met AES te maken.

Maar als je bedoelt dat er efficientere methodes zijn om AES te kraken dan brute force: Nee, die zijn er (voorzover bekend) niet.

De paper die je linkt heeft beschrijft een wiskundige aanval op AES waarmee je grofweg 2 bits wint. AES-128 is dan te brute forcen in 2¹²⁶ ipv 2¹²⁸ pogingen. Een factor vier sneller dus. Maar het rekenwerk dat je moet verzetten om die aanval uit te voeren kost zoveel dat je die factor vier weer ruimschoots verliest, dus uiteindelijk is het trager.

Begrijp me niet verkeerd, dat soort onderzoek is belangrijk, en het beschrijft daadwerkelijk een cryptografische aanval op AES, en misschien volgen er met voortschrijdende inzichten geavanceerdere aanvallen. Maar het levert op dit moment geen efficientere methode op om AES te kraken.

Die zijn er wel. Ik ken de details niet meer van buiten maar het is bijvoorbeeld mogelijk om side-channel attacks te doen, als ik me niet vergis gaat het om cache-timing attacks waarbij bepaalde lookups in het algoritme een verschil in access tijd hebben en dan kan je zo de key reconstrueren.

[Reactie gewijzigd door dielc op 16 juli 2015 18:09]

Ja het duurt nog wel eventjes voordat AES gekraakt kan worden en anders maken ze wel weer AES-384 of AES-512, maar het ging mij er vooral om dat AES ook al zwakheden heeft, al zijn die nog niet praktisch uit te buiten. Maar ondanks dit kan een quantumcomputer dit wellicht in een veel kortere tijd gaan doen, als die dan nog even ontwikkeld wordt natuurlijk.

Haha.. ja lmgtfy is wel makkelijk om zo direct een rij links te geven waar eventuele zwakheden van aes al wordt besproken, scheelt mij tijd met het plaatsen van links. Ja ook ik ben soms lui.

Misschien moeten we ons niet fixeren op een bepaalde beveiliging, maar het combineren ervan. Het is een kwestie van de tijd en energie van de inbreker te verspillen door het combineren van verschillende beveiligingen. Een inbreker stopt ook met inbreken als hij ziet dat het inbreken op zich veel teveel tijd in beslag gaat nemen. Ontmoedigingsfactor speelt ook een rol dus ... dat vraagt natuurlijk een bepaald inschattingsvermogen van hoe sterk je data moet gaan beveiligen naar belangrijkheid met performantie als tegengewicht. Maar dat is nooit anders geweest.

Dit is een verkeerde logica en volstrekt onwerkbaar. Als je eenmaal een versleutelde verbinding hebt hoor je klaar te zijn. Dat ben je ook als je geen gedateerde versleutelingsmethoden gebruikt. Een defense in depth idee is hier een gigantische gimmick die alleen je beveiligingssysteem slechter maakt door echte beveiliging met obscurity te vervangen.

Misschien moeten we ons niet fixeren op een bepaalde beveiliging, maar het combineren ervan.

Het probleem is dat er naast veiligheid ook andere factoren zijn. Rekenkracht nodig om te kraken is bijvoorbeeld vaak evenredig met energieverbruik en kosten. Het combineren van veiligheidsmiddelen is vooral handig om te zorgen dat als een van de onderdelen gekraakt wordt de andere overeind blijven. Maar het verandert niets aan de afweging tussen veiligheid vs kosten/energie.

Toen DES gekraakt was had men als lapmiddel 3DES gemaakt hetgeen in feite niet meer doet dan 3 lagen DES op een slimme manier combineren. Ofwel het combineren van verschillende beveiligingen. Dat is anno 2015 nog steeds onkraakbaar en het ziet er niet naar uit dat het binnen enige afzienbare tijd gekraakt kan worden. Maar het is niet populair omdat het verschrikkelijk traag is in software en daarom ook veel energie verbruikt. Als je dus geen hardware accelerator hebt, is dat geen fijn algorithme. AES is toen gemaakt als officieel DES opvolger omdat dat ook veilig is, maar dan zonder de nadelen van 3DES.

RC4 was juist aantrekkelijk omdat het en veilig was, en makkelijk in zowel software als hardware uit te voeren en een laag energieverbruik had. Helaas is RC4 nu voorbij zijn houdbaarheidsdatum.

euhm. De capture tijd is toch 52 uur. Niet het daadwerkelijk kraken?!?.

Ik heb het ook even moeten uitzoeken want ik snapte het niet helemaal hoe het nu zat met die tijd, maar het gaat inderdaad om de capture tijd. Maar die is nodig om de benodigde data te vergaren om de cookie te kraken. De tijd voor de attack is dus ongeveer 52 uur, en zonder de input kun je de encryptie niet kraken.

Wat ik uit het artikel heb kunnen opmaken:
Om een cookie van 16 karakters te kunnen kraken, met een succes kans van 94% zijn er ongeveer 9*2²⁷ ecrypties van de cookie nodig. De client kon in dit scenario ongeveer 4450 requests per seconde doen, en daarmee zou de tijd op zo'n 75 uur uitkomen. Als je geluk hebt kun je het met minder doen, in dit geval 6.2⋅2*²⁷ requests waardoor ze al in 52 uur klaar waren.

De hele hack zit dus in elkaar met het doen van requests om maar genoeg ecrypted data te kunnen vergaren om de cookie te kunnen ontcijferen.

Dus de impact valt dus wel mee... Rc4 algoritme is simpel en elegant.. In een paar regels code te implementeren. Kwetsbaarheden komen door verkeerd gebruik. https://nl.m.wikipedia.org/wiki/RC4_(encryptie)

Nee, deze kwetsbaarheid is inherent aan RC4. Het blijkt dat de 'randomness' niet echt random is, maar voorkeuren heeft. Ofwel een bepaalde input wordt vertaalt in een random reeks bits, die niet helemaal random is. Door simpelweg veel requests te doen, kun je via simpele statistische analyse deze voorkeuren omzetten in (bijna) zekerheden en zo de oorspronkelijke bits raden.

Dit was al langer bekend, en in 2013 werd deze voorkeuren goed beschreven. En in oktober 2014 is de eerste end-to-end aanval opgezet en was RC4 dus officieel gekraakt.

Deze aanval is wel nog heel erg theoretisch, want het aantal pogingen nodig om de statistische analyse te doen is erg groot. Het werkt eigenlijk alleen op zaken als authenticatie cookies bij TLS/HTTPS of WiFi WPA-headers. Bij TLS/HTTPS moet de client bovendien al die tijd aanwezig blijven, en de server moet al die requests zomaar accepteren. Dat is in de praktijk vrijwel nooit het geval bij TLS/HTTPS.

Maar zoals dit onderzoek laat zien, gaat het kraken steeds beter. Nu moet een client bijvoorbeeld 'slechts' 52 uur aanwezig zijn ipv 75 uur. En bij WPA in combinatie met RC4 duurt kraken nu slechst één uur ...

Voorbeeld in video laat RC4 128bits zien.
Veel sites (waaronder Microsoft Azure) gebruiken dit nog:

https://www.ssllabs.com/s...l?d=www.azurewebsites.net

@Redactie @Microsoft hoe kan het dat bijna 2 jaar na het advies van Microsoft (zie artikel), hun belangrijkste online omgeving nog RC4 gebruikt.

Compatibiliteit met oude clients en slecht geconfigureerde bedrijfs malware scanner proxies. Die laatste willen nog wel eens RC4-only zijn. In Zuid-Amerika en Azie schijnen die nog voor te komen.

Merk op dat het ondersteunt wordt, niet gebruikt. Enkel clients die enkel RC4 ondersteunen en zelfs geen 3DES zullen RC4 gebruiken.

Overigens wel eens dat het inconsequent is.

Komt dit ook niet neer op een cookie-replay-"exploit"?
het kraken van de cookie is misschien een rc4-kraak, maar het gebruiken van die cookie is imho gewoon een cookie-replay-exploit
maw: de site's die enkel vertrouwen op hun TLS-encrypted-https-verbinding om gebruikers te beveiligen en niet nadenken op het 'wat als men toch de cookies kan snoopen'-gevalletje...

Als je als server er volledig vanuit gaat dat van de ingelogde client kom omdat ie de juiste cookie heeft - die jij hem over https hebt meegedeeld, terwijl in de tijd met firesheep al is aangetoond dat vele sites (toen nog over http) al gevoelig waren voor cookie-replay - tja dan ben je gewoon dom bezig denkend dat https je server en klants beschermd tegen zulke aanvallen...:
het volledige plaatje dient nog steeds te kloppen
regel nr: 1 in beveiliging:
als beveiliger moet je rekening houden met alles, want een "hacker" dient maar éénmaal het geluk te hebben een exploit te vinden en je hebt prijs.

[Reactie gewijzigd door soulrider op 16 juli 2015 18:46]

De gebruiker in het filmpje gaat met zijn 'muiswijzer' van de ene klik naar de andere 'klik' en van het ene tabblad naar het andere. Het is duidelijk dat het voor de maker van het filmpje gesneden koek is.
Het filmpje heeft erg veel informatie, wat op zich een pluspunt is. Helaas heeft het filmpje een tekort aan rust momenten zodat je de materie als kijker kunt even kunt verwerken.