Onderzoekers presenteren nieuwe aanval op encryptiealgoritmes 3DES en Blowfish

Twee onderzoekers van het Franse overheidsinstituut Inria hebben een aanval met de naam 'Sweet32' op de encryptiealgoritmes 3DES en Blowfish gevonden. Hiermee is het bijvoorbeeld mogelijk om authenticatiecookies te achterhalen bij https-verbindingen.

De wetenschappers stellen tegenover Threatpost dat het niet gaat om een massale aanval die het gehele internet treft, maar dat het een signaal is om van 3DES en Blowfish af te stappen, zoals dat eerder al bij RC4 gebeurde. Onderzoekers Gaëtan Leurent en Karthikeyan Bhargavan zeggen dat de aanval te maken heeft met het feit dat er soms collisions ontstaan bij het gebruik van cbc bij encryptie. Dit is een modus waarbij met een blok van onversleutelde gegevens een xor-operatie wordt uitgevoerd met het voorgaande blok van versleutelde gegevens. Deze collisions kunnen uiteindelijk tot het achterhalen van de klare tekst van een versleuteld bericht leiden. Tot nu toe waren dit soort aanvallen echter niet praktisch, schrijven de onderzoekers.

3DES en Blowfish, waarbij de blokgrootte 64bit is, worden respectievelijk ingezet voor de beveiliging van https-verkeer en van OpenVPN-verbindingen. Ook komen zij voor in tls, ssh en ipsec. Daarbij komt 3DES voor bij ongeveer een tot twee procent van de meest populaire Alexa-sites. Volgens de onderzoekers is dit alsnog een groot aantal. Een aanval op een zodanig beveiligde verbinding zou uitgevoerd kunnen worden door een slachtoffer naar een kwaadaardige site te lokken en javascript in de browser te injecteren. Daardoor worden er een groot aantal verzoeken naar een site gestuurd, waarop het slachtoffer is ingelogd met een authenticatiecookie. Na het versturen en opvangen van 2³² verzoeken, kan de aanvaller het authenticatiecookie achterhalen met een man-in-the-middle-positie.

Om daadwerkelijk een cookie te achterhalen zou de benodigde hoeveelheid verkeer neerkomen op ongeveer 785GB. Dit konden de wetenschappers in het proefopstelling opvangen binnen 19 tot 38 uur. De onderzoekers stellen dat het afstappen van Blowfish en 3DES de beste manier is om zich tegen een dergelijke aanval te verdedigen. Zo zijn er betere encryptiealgoritmes die gebruikt kunnen worden voor dezelfde doeleinden, bijvoorbeeld AES dat een blokgrootte van 128bit gebruikt. Volgens Threatpost zullen OpenSSL en OpenVPN in de komende dagen afstappen van respectievelijk 3DES en Blowfish, als reactie op het onderzoek. Zo krijgt 3DES bijvoorbeeld een veiligheidsinschatting van 'gemiddeld' en moet het algoritme handmatig ingeschakeld worden.

De wetenschappers willen hun onderzoek in oktober presenteren op de ACM-conferentie voor computer- en communicatiebeveiliging in Wenen.

Man-in-the-middle-positie, afbeelding via sweet32.info

Reacties (31)

[mrdemc]

Wat betekent dit dan voor de password_hash functie in PHP aangezien deze bcrypt/blowfish gebruikt.

PASSWORD_DEFAULT - Use the bcrypt algorithm (default as of PHP 5.5.0). Note that this constant is designed to change over time as new and stronger algorithms are added to PHP. For that reason, the length of the result from using this identifier can change over time. Therefore, it is recommended to store the result in a database column that can expand beyond 60 characters (255 characters would be a good choice).
PASSWORD_BCRYPT - Use the CRYPT_BLOWFISH algorithm to create the hash. This will produce a standard crypt() compatible hash using the "$2y$" identifier. The result will always be a 60 character string, or FALSE on failure.

Of is deze methode daar niet geschikt voor en gaat het echt om 'verbindingen' die versleuteld zijn hiermee?

[Reactie gewijzigd door mrdemc op 23 juli 2024 08:42]

[xrf]

Bcrypt wachtwoordhashing is niet kwetsbaar, omdat dit alleen gebruik maakt van het van het key scheduling gedeelte van Blowfish; dit is niet het gedeelte dat door deze aanval getroffen wordt.

[deadinspace]

... omdat dit alleen gebruik maakt van het van het key scheduling gedeelte van Blowfish; dit is niet het gedeelte dat door deze aanval getroffen wordt.

Dat is niet correct.

bcrypt maakt wel degelijk gebruik van volledige Blowfish encryptie. Zie bijvoorbeeld deze pseudocode van wikipedia:

bcrypt(cost, salt, input)
. . state <- EksBlowfishSetup(cost, salt, input)
. . ctext <- "OrpheanBeholderScryDoubt" //three 64-bit blocks
. . repeat (64)
. . . . ctext <- EncryptECB(state, ctext) //encrypt using standard Blowfish in ECB mode
. . return Concatenate(cost, salt, ctext)

Bcrypt zal inderdaad niet kwetsbaar zijn, maar om andere redenen dan die jij geeft:

• De key schedule van bcrypt is een aangepaste versie van de Blowfish key schedule, eentje met - onder andere - veel meer iteraties (dat is ook waar de traagheid van bcrypt vandaan komt)
• Blowfish in bcrypt wordt gebruikt om interne state 64 keer te encrypten. Een zwakheid in Blowfish moet dus zo erg zijn dat de encrypted data 64 keer volledig teruggedraaid kan worden. En dan moet je nog de (uitgebreide) key scheduling reverten.
• De aanval in kwestie probeert collisions te genereren, en moet daarvoor het slachtoffer zo ver krijgen om ~2³² keer de gevoelige data te encrypten met Blowfish. Bij een wachtwoord is dat meestal niet het aanvalsmodel, je hebt dan alleen de hash en meer niet.

Bcrypt wachtwoordhashing is niet kwetsbaar, ...

Daar ben ik het dan wel mee eens

[Armin]

Of is deze methode daar niet geschikt voor en gaat het echt om 'verbindingen' die versleuteld zijn hiermee?

Voor dit soort aanvallen is het vereist dat de aangevallen client, een data pakket stuurt. Immers men kan via veel proberen en de transactie data bekijken informatie achterhalen. Echter in geval van file-encryptie is er geen client, en dus faalt de aanval. Idem voor 3DES zoals gebruikt in credit cards etc. Daar is het ook veilig.

Overigens ook in geval van TLS is deze aanval vooral theoretisch. Tweakers stelt dat ook correct: Het vooral "een signaal is om van 3DES en Blowfish af te stappen".

Immers er moet en een MITM aanval, en een Java-script injectie terwijl het slachtoffer niet de site pagina verlaten, en de server moet ook nog eens toestaan dat er zoveel foute pogingen ondernomen worden. En dan nog werkt het 'enkel' bij cookies en andere tokens.

Tenslotte de aanval is niet nieuw. Wat nieuw is dat het nu met minder berekeningen kan.

Gelukkig gebriukt bijna niemand meet 3DES op het web. Er wordt melding gemaakt van 2% van de top websites van Alexa, maar dat is click-bait. Meeste van die sites zijn non-HTTPS en hebben enkel hun TLS aan staan voor inloggen voor settings beheer (denk aan kranten websites etc). Echte secure sites zoals banken, Microsoft, Facebook, Tweakers, etc gebriiken 3DES als allerlaatste fallback om antieke browsers toch van content te kunnen voorzien. Met een enigsinds moderne browser (Denk reeds aan IE9 op Windows Vista!) gebruik je al zelden 3DES.

EDIT: eerste allinea aangepast.

[Reactie gewijzigd door Armin op 23 juli 2024 08:42]

[Anoniem: 636203]

Al deze aanvallen zijn vaak theoretisch en alleen onder heel specifieke omstandigheden toe te passen. Veel aanvallen op RC4 gaan bijvoorbeeld uit dat je de bias niet verwijderd door niet de eerste 1024-bytes uit de keystream weg te gooien. Als je de bias verwijderd dan is er geen probleem.

Ook hier moet je CBC gebruiken. Als je een andere mode gebruikt zoals PCBC, ECM, GCM of CTR is er geen probleem.

Maar Blowfish en 3DES zijn oude algoritmen en los daarvan is AES veel beter bestudeerd en sneller. Er is daarom geen reden om deze twee ciphers niet weg te gooien.

[Reactie gewijzigd door Anoniem: 636203 op 23 juli 2024 08:42]

[Cartman!]

In het geval van password_hash in PHP wordt het gebruikt voor hashing, niet als encryptie dus ik ga er zelf even vanuit dat dit geen invloed heeft hierop.

[Mr_Light]

Daar word volgens mij geen XOR over de (onversleutelde) data gedaan en opgeslagen/beschikbaar voor de aanvaller en is het herleiden derhalve niet mogelijk. Het wachtwoord past in 1 blok waardoor deze niet geschakeld hoeven te worden(blok-chaining).

Bovendien is uit de text te lezen dat ze voor die constant / de default een ander algoritme er in kunnen pluggen. Rehash on access is dat te fixen. weet niet of het helemaal transparant met een upgrade gedaan kan worden ligt aan de api en performance afweging( Bij mismatch terugvallen op de oude hashing toepassen -> check tegen waarde, if ok -> nieuwe hashing -> nieuwe hash storen).

[Dorank]

Wat betekent dit dan voor de password_hash functie in PHP aangezien deze bcrypt/blowfish gebruikt.

Helemaal niets.

Het artikel gaat over het Blowfish cipher, bcrypt maakt gebruik van een onderdeel van Blowfish, de key setup phase (omdat die zo duur is). De aanval gaat inderdaad over het vinden van deze (tijdelijke) key m.b.v. de encrypted stream, waar bcrypt de key als reproduceerbaar eindproduct heeft voor een salt, passphrase en een x aantal iteraties van het algoritme.

[Olaf van der Spek]

Om daadwerkelijk een cookie te achterhalen zou de benodigde hoeveelheid verkeer neerkomen op ongeveer 785GB.

Daar gaat je databundel...

Is dit nou echt een issue in Blowfish of is dit een probleem met CBC mode?
Waarom zijn er maar 2^32 requests nodig terwijl de blokgrootte 64 bit is.

Dat 3DES nog gebruikt wordt is erg.

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 08:42]

[Armin]

Is dit nou echt een issue in Blowfish of is dit een probleem met CBC mode?

Beide. Het is een probleem in ciphers in CBC mode met een korte key. Dat zijn Blowfish en 3DES.

Het moet CBC mode zijn omdat je anders niet via een XOR operatie via ene collission de oorspronkelijke data kunt achterhalen. En het moet een korte key lengte zijn omdat anders het aantal pakketjes dat je moet versturen om een collission te krijgen veel en veel te groot wordt.

Echter wanneer 3DES of Blowfish gebruikt wordt in een context waar het aantal paketjes dat encrypt wordt inherent klein genoeg is, is er geen gevaar. De truc is namelijk dat dezelfde data met elke keer een kleine aanpassing opnieuw versleuteld wordt.

Dat 3DES nog gebruikt wordt is erg.

3DES is nog steeds een heel veilige cipher. Het is vooral in onmin geraakt omdat het erg rekenintensief is in software. Er zijn veel plaatsen waar het nog steeds voldoet in combinatie met hardware encryptie/decryptie.

Deze aanval beperkt zich dus namelijk tot internet verkeer waar cookies/tokens als authentiatie gebruikt worden, en daar wordt het enkel op websites gebruikt als fallback om oude clients te voorzien van data. Immers je hebt geen keuze, het is of RC4, of 3DES of de client buiten sluiten. En dan is 3DES een relatief goede keuze.

En bij internet verkeer kun je verder ook gewoon de re-key tijd korter maken voor 3DES. Dan los je het probleem ook op.

[Reactie gewijzigd door Armin op 23 juli 2024 08:42]

[Olaf van der Spek]

Beide. Het is een probleem in ciphers in CBC mode met een korte key.

Block size (64-bit) bedoel je toch?
Keys van 3DES en Blowfish zijn niet zo kort.

[Reactie gewijzigd door Olaf van der Spek op 23 juli 2024 08:42]

[Armin]

Ja, block size bedoelde ik.

Keys zijn inderdaad langer (3x56 = 168 bits).

[JeRa]

Die 2³² komt door de birthday paradox, een upper bound op het zoeken van twee gelijke outputs van crypto/random-achtige blocks. Zie https://en.wikipedia.org/wiki/Collision_resistance; ze hanteren daar 2^n/2 pogingen voor 2ⁿ aantal mogelijke outputs.

[Olaf van der Spek]

Maar dit gaat over encryption, niet over hashing.. er is een 1:1 verband tussen plaintext en cryptotext, anders wordt decrypten zo lastig.

[Armin]

er is een 1:1 verband tussen plaintext en cryptotext, anders wordt decrypten zo lastig.

Bij CBC is er nu net géén 1:1 verband tussen de plaintext en de cryptotext. Dwz, er is ook nog een initialisatie factor van belang. Voor het eerste paketje is die random, maar voor de volgende paketjes is die gelijk aan de cryptotext van het vorige paketje. Deze link zorgt er enerzijds voor dat allerlei andere aanvallen onmogelijk zijn, maar introduceert wel de birthday paradox.

Het is dus niet de plain text input die de collession geeft, maar de combinatie van vector en plain text. De aanvaller moet dus van een van beide collission paketjes de plain text weten. De initializatie vector kan dan ge-elimineerd worden, omdat je het verband weet tussen initializatie vector X en X+1, en een van beide plain text inputs. In middelbare school wiskunde uitgedrukt: je houdt dan twee vergelijkingen over, met slechts twee onbekenden en dat kun je oplossen.

[Wildfire]

Heeft dit ook nog gevolgen voor Truecrypt/Veracrypt, waarin Blowfish ook gebruikt kan worden?

-- Edit: VeraCrypt gebruikt TwoFish, geen BlowFish.

[Reactie gewijzigd door Wildfire op 23 juli 2024 08:42]

[kris_112]

Het geeft in elk geval aan dat als men jou zo ver krijgt om, in het geval van het artikel, een door de aanvaller gekozen 785GB aan data te encrypten, men in staat is om geencrypte data te achterhalen.

Er staat niet bij dat ze na deze aanval ook daadwerkelijk de encryption key te pakken hebben, maar slechts een klein stukje data (het session cookie). En jou zo ver krijgen om 785GB van hun data te encrypten is ook niet niks, dus ik zou die geencrypte disks nog niet meteen door de shredder gooien. Maar het lijkt me wel een goed moment om een ander algoritme te overwegen.

[Reactie gewijzigd door kris_112 op 23 juli 2024 08:42]

[The Zep Man]

Heeft dit ook nog gevolgen voor Truecrypt/Veracrypt, waarin Blowfish ook gebruikt kan worden?

Truecrypt heeft ondersteuning voor AES, Serpent en Twofish, geen Blowfish.

Sowieso is met Truecrypt AES aan te raden als je CPU hardwareacceleratie daarvoor heeft. Natuurlijk kan je dat combineren met andere algoritmes, maar AES erbuiten laten heeft eigenlijk weinig nut.

[Wildfire]

[...]
Truecrypt heeft ondersteuning voor AES, Serpent en Twofish, geen Blowfish.

Sowieso is met Truecrypt AES aan te raden als je CPU hardwareacceleratie daarvoor heeft. Natuurlijk kan je dat combineren met andere algoritmes, maar AES erbuiten laten heeft eigenlijk weinig nut.

Je hebt gelijk - TwoFish, geen BlowFish.

Ik gebruik zelf nested encryption, AES met TwoFish.

[Elijan9]

Mocht je zelf OpenVPN gebruiken, de encryptie kan eenvoudig aangepast worden naar AES door de volgende regel te gebruiken in de configuratie (voor server en clients):
cipher AES-128-CBC

[Reactie gewijzigd door Elijan9 op 23 juli 2024 08:42]

[The Zep Man]

Mocht je zelf OpenVPN gebruiken, de encryptie kan eenvoudig aangepast worden naar AES door de volgende regel te gebruiken in de configuratie (voor server en clients):
cipher AES-128-CBC

Tenzij je CPU kracht beperkt is (client of server-side), is het beter om AES-256-CBC te gebruiken.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 08:42]

[Rafe]

Ongeacht lengte: je kan beter een authenticated encryption modus zoals aes-*-gcm gebruiken. GCM is stukken sneller dan CBC (met HMAC), en kan op moderne processoren worden versneld door instructies. Even kijken op de OpenVPN wiki leert dat het ook de standaard cipher wordt vanaf OpenVPN 2.4.

[Cornelisjuh]

Daardoor worden er een groot aantal verzoeken naar een site gestuurd, waarop het slachtoffer is ingelogd met een authenticatiecookie.

Dus als je website iets als Cloudfare gebruikt is het daar dus eigenlijk mee opgelost omdat je dan nooit/heel lastig de 2^32 verzoeken kan halen?

[mr_seeker]

Was de OV-chipkaart ook niet voorzien van 3DES?

[jozuf]

Jep, mifare classic werd toegepast in het begin wat nog onveiliger is dan mifare desfire wat wel 3des gebruikt.
Volgens mij gebruiken ze tegenwoordig de desfire/3des kaarten.

[Anoniem: 636203]

Nee, die gebruikten een eigen algoritme wat veel zwakker was.

[jozuf]

In het begin wel, nu gebruiken ze volgens mij al een flink lange tijd de desfire chips. Aanleiding was dat het vrij snel gehacked was na introductie. Zie bv
http://webwereld.nl/secur...fare-desfire-chip-van-nxp
En die desfire chip was ook weer vrij snel gehacked na intro overheid en it olé, olé!

[Reactie gewijzigd door jozuf op 23 juli 2024 08:42]

[CAPSLOCK2000]

Dat 3DES aan vervanging toe was verbaasd me niet, dat is al zo oud. Bij het nazoeken ontdekte ik dat Blowfish nog ouder is, dat had ik niet gedacht.
3DES komt uit 1998 en Blowfish uit 1993!

3DES is wel gebaseerd op DES uit 1975, het is feitelijk niet zo veel meer dan 3 keer het gewone DES-algoritme toepassen.

Hulde aan de bedenkers van deze algoritmes, ze hebben het erg lang volgehouden!

[sfranken]

Die laatste zin zou ik nog niet het wild inslingeren, Blowfish en 3DES worden nog heel veel gebruikt, en dat gaat niet zo snel veranderen ook, aangezien er nog aardig wat legacy software mee draait.

[Anoniem: 636203]

En wat als je een andere block chaining mode gebruikt zoals PCBC of GCM?

[Rafe]

GCM heeft een block size van 128 bit nodig.