Onderzoeker ontwerpt aanval op cryptografisch rc4-algoritme

Een onderzoeker van de TU Eindhoven heeft een praktische aanval voor het encryptiealgoritme rc4 opgezet. Dat het algoritme niet geheel veilig is, was al bekend, maar praktische aanvallen waren nog niet voorhanden. Toch zijn er nog de nodige beperkingen.

Al 15 jaar is bekend dat het 25 jaar oude encryptiealgoritme rc4 met gebreken kampt, maar een praktische aanval was nog niet voorhanden. Dat is nu veranderd, dankzij onderzoeker Daniel Bernstein van de Technische Universiteit Eindhoven. Bernstein zette een praktisch uit te voeren aanval op, waarbij telkens hetzelfde bericht opnieuw wordt versleuteld. Dankzij de gebreken in het rc4-protocol kan zo de inhoud van berichten worden achterhaald.

Het rc4-algoritme verhult de inhoud van berichten door de bits van de inhoud te combineren met willekeurige getallen, wat alleen ongedaan kan worden gemaakt door iemand die de sleutel kent. Het probleem zit in het feit dat de eerste 256 bits van een rc4-sleutel niet willekeurig genoeg zijn. Als een bericht vele miljoenen keren wordt gecodeerd, kunnen gedeeltes van het bericht worden uitgelezen; na enkele miljarden pogingen kan het hele bericht worden gelezen. Dat kan een of twee dagen rekenwerk kosten.

Daarmee is het waarschijnlijk niet de efficiëntste aanval op het cryptografische algoritme; eenvoudiger is het om fouten in de implementatie van het algoritme te misbruiken. Het rc4-algoritme wordt onder meer gebruikt in het tls-protocol, dat wordt gebruikt om websites te beveiligen. Het algoritme is nog steeds alomtegenwoordig en vanwege de Beast-aanval op https waren veel websites juist op rc4 overgestapt.

Reacties (14)

Als ik het goed begrepen hebt heeft TLS 1.1/1.2 heeft geen last van BEAST en staan toe dan een andere algoritme dan Rivest Cipher 4 (rc4) te gebruiken. Jammer echter dat de ondersteuning er voor, in IE Opera en firefox nog niet echt goed is. IE en Opera kan je het aan zetten, maar leg dat maar eens aan je gebruikers uit. Chrome support 1.1

Tijd om over te stappen naar TLS 1.1/1.2 in combi met Data Encryption Standard (DES), triple-strength DES (3DES).

Dus zullen de browsers moeten worden geupdate, wat als mooi side effect heeft dat support voor allerlei andere dingen beschikbaar word voor developers. (Html5 CORS etc..)

http://en.wikipedia.org/w...yer_Security#Web_browsers
http://security.stackexch...ed-in-all-modern-browsers

Voor de mensen die deze onderzoeker niet kennen: DJB is o.a. de maker van qmail en djbdns.

Zoals ik het begrijp in een sloten analogie:

In plaats van 1 keer draaien met de goede sleutel, moet je een miljard keer draaien met een 'loper' (een echte loper zou natuurlijk maar 1 keer draaien zijn), waardoor, door een fout in het slot, hij alsnog opengaat. Misschien dat je de analogie nog door kan trekken tussen het slijten van het slot en het verliezen van de randomness van de key.

Misschien dat iemand kan bevestigen/ontkrachten?

edit: Dit had een reactie op Thrackan moeten zijn.

[Reactie gewijzigd door Zartok op 15 maart 2013 16:29]

Edit: hmm, volgens mij had ik het toch niet helemaal goed begrepen.

Hier staat nog wat uitleg:
http://www.isg.rhul.ac.uk/tls/

Door een heleboel encrypties van hetzelfde stukje plaintext te bekijken, kunnen de eerste 256 bytes van die plaintext achterhaald worden. Dus door als attacker ergens in het netwerk pad tussen client en server te zitten en te zorgen dat de client steeds een nieuwe verbinding maakt, kan de aanvaller wat leren over een kort stukje uit het begin van het bericht dat de client naar de server stuurt.

Als dat stukje aan het begin een sessiecookie, of password of zo bevat, dan is dat dus interessant om te onderscheppen.

Praktische impact is dus op dit moment tamelijk beperkt, omdat het behoorlijk wat moeite kost om als attacker zo'n sloot aan sessies te veroorzaken en je alleen de eerste 256 bytes plaintext kan opvissen.

[Reactie gewijzigd door Orion84 op 15 maart 2013 16:59]

Als alleen de eerste 256 bits achterhaald kunnen worden met deze methode, zal het een kwestie van tijd zijn totdat de eerste 256 bits geen gevoelige data meer bevatten, en het algoritme nog steeds gebruikt kan worden.

Ehm sorry? Als de eerste 256 bits achterhaald kunnen worden, dan is het algorithme dusdanig hard gebroken dat het heel erg hoog tijd wordt om heel RC4 het raam uit te gooien en over te stappen op iets anders.
Ranzige non-oplossingen waarbij je eerst 256 bits random meuk verstuurt is vragen om nog veel ernstiger problemen.

Het RC4 protocol kwam ik al eens tegen toen ik onderzoek deed naar het challenge-response systeem van VNC.

Eigenlijk is het dus via brute forcing gewoon te achterhalen wat er in de packages zit. Het enige probleem is de relatief lange tijd die er voor nodig is om enkele pakketjes de data te achterhalen. Daarbij is er een verschil tussen de encryptie die gebruikt wordt en de encryptiesleutel. Een encryptiesleutel is vaak 2048 bits en de encryptie verbinding 128/256 bit.

Het RC4 protocol wordt op talloze plaatsen gebruikt en eerdere kwetsbaarheden hadden voornamelijk te maken met de specifieke manier van implementeren en berekenen van de initialisatie vectors. Zie bijvoorbeeld de kwetsbaarheden van RC4 in WEP.

Wat je bedoelt met je laatste opmerking is me een raadsel. Als er wordt gesproken over een x-bit encryptie dan wordt doorgaans toch echt gedoeld op de sleutellengte.

2048bits sleutels zie je eigenlijk niet bij gangbare symmetrische algoritmes. Dat soort sleutellengtes zijn wel gangbaar bij a-symmetrische (Public Key) algoritmes als RSA.

Wat wel veelvoorkomend is, is dat public key crypto (bijvoorbeeld 2048 bit RSA) wordt gebruikt om een verbinding op te zetten en sleutelmateriaal uit te wisselen en er daarna voor de daadwerkelijke encryptie van de data gebruik wordt gemaakt van een 128 of 256 bit symmetrische sleutel, omdat dat qua performance veel beter is dan RSA voor de hele verbinding blijven gebruiken.

[Reactie gewijzigd door Orion84 op 15 maart 2013 17:07]

Maar wacht even hoor, als je het bericht opnieuw versleutelt, moet je dan niet al het originele bericht hébben om dit te kunnen versleutelen? Of mis ik een stukje in de formulering?

je versleuteld je eigen bericht met het algoritme voor x aantal keer, waarna je de sleutel in handen krijgt.

Zo ver ik het begrepen heb krijg je de sleutel helemaal niet in handen, je krijgt 't bericht in handen!

(correct me if I'm wrong)

Heb me niet verdiept maar ik *vermoed* dat, vermits er random getallen aan de bits worden toegevoegd, het volstaat het geencrypteerde bericht tig-keer opnieuw te versleutelen om zodoende de random getallen (die niet random genoeg zijn) eruit te kunnen isoleren, met als gevolg dat de originele bits overblijven.

Rc4 beveiliging is niet alleen een probleem bij netwerken. Al je office bestanden die je thuis opslaagt met een wachtwoord, blijken ook 128 bit rc4 code te zijn. Dus al de mensen die een excel bestand met wachtwoord beveiliging ergens publiekelijk beschikbaar hebben: dit is ook veel te gemakkelijk te kraken. Ik hoopte alleen dat de nieuwe office een betere beveiliging had, maar helaas.

Moet je alleen wel even iemand zover krijgen om hetzelfde office bestand een miljard keer opnieuw te laten versleutelen. En dan nog leer je alleen de eerste 256 bytes van het bestand.

Ja, dit soort aanvallen geeft aan dat het hoog tijd is om RC4 te gaan vervangen. Maar het is niet alsof de wereld vergaat en elke wijsneus nu ineens met de grootste eenvoud jouw office bestanden kan lezen.

Het gebruikte wachtwoord bruteforcen zal doorgaans vele malen eenvoudiger zijn