(nem hivatalos e-kormányzati témájú oldal)
| Mottó: A srác az utcán nyomja a crack-et. /Tankcsapda: Nem ismerek rád/ | ||
| 2017. november 9. | ||
| WPA2: KRACK = CBC vs. GCM dilemma (és eIDAS?) | ||
| 2017-10-15. A "The Hacker News" azzal nyit, hogy elvérzett a WPA2... Mathy Vanhoef, a KU Leuven kutatója (imec-DistriNet Research Group) a KRACK címszó alatt értett "Key Reinstallation Attacks" révén tud rejtjelezett adatot megfejteni és csomagot visszajátszani (bizonyos esetekben módosítva is) a megfigyelt vezeték nélküli kommunikációban. A főcím még nem annyira beszédes, viszont az alcímet olvasva ("Breaking WPA2 by forcing nonce reuse") már gyanúsabb a dolog. Ez úgy tűnik, hogy nem csak a WPA2, hanem úgy általában a valamilyen "counter" módban (CTR, GCM) futó AES algoritmus témájáról szól, amire a fejlesztőknek valóban nagyon oda kell figyelnie. Nézzük is meg közelebbről! A jelen bejegyzésben nem is azt vizsgálnám, hogy vajon mennyire jelent könnyen kihasználható sérülékenységet a KRACK (gondot valószínűleg ott okozhat, ahol nem frissülnek be az érintett kódok), hanem inkább az AES különböző módjairól, a CBC vs. GCM témáról gondolkodnék. Na, de mi köze van a WPA2 problémának a CBC vs. GCM témához? A WPA2 AES-CCMP (Counter Mode with CBC-MAC Protocol) és AES-GCMP (Galois/Counter Mode Protocol) beállítása érintett a KRACK sérülékenység kapcsán a kutató szerint. Az AES-CCMP "combines CTR for data confidentiality and CBC-MAC for authentication and integrity" (forrás: https://en.wikipedia.org/wiki/CCMP_(cryptography)), míg az AES-GCMP a CTR módú rejtjelezés mellé a sértetlenség ellenőrizhetőségéhez mást használ ("Galois field multiplication used for authentication can be easily computed in parallel" (forrás: https://en.wikipedia.org/wiki/Galois/Counter_Mode)). Ha csak a rejtjelezési réteget nézzük, már akkor is a párhuzamosítható (és ezáltal jelentősen gyorsítható) működés a nagy különbség a CBC módú és CTR módú AES használata között. A sértetlenséghez kapcsolódó rétegben pedig a "Galois field multiplication" révén a teljes protokollra nézve biztosítható ez a párhuzamosíthatóság AES-GCMP esetében (ld. David A. McGrew, John Viega: The Galois/Counter Mode of Operation (GCM)). Ez tehát egy nagyon komoly előny a tisztán "counter" módban futó megoldásoknál. De van egy óriási hátrány is a tisztán "counter" módban futó megoldásoknál: könnyen lehet végzetes hibát elkövetni, ha pl. a "counter" vagy "nonce" vagy "IV" újrahasznosításra kerül. És a KRACK leírás alcíme ("Breaking WPA2 by forcing nonce reuse"), illetve a tanulmány is pontosan erre utal... In a key reinstallation attack, the adversary tricks a victim into reinstalling an already-in-use key. This is achieved by manipulating and replaying cryptographic handshake messages. When the victim reinstalls the key, associated parameters such as the incremental transmit packet number (i.e. nonce) and receive packet number (i.e. replay counter) are reset to their initial value. Essentially, to guarantee security, a key should only be installed and used once. /forrás: https://www.krackattacks.com/ /
/forrás: http://chimera.labs.oreilly.com/books/1234000001739/ch03.html /
/forrás: http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.694.695&rep=rep1&type=pdf / OK, a GCM módnak van egy komoly előnye, de ehhez képest mennyire jelent végzetes problémát a "nonce reuse"? Hááát... Az látszik, hogy a komoly előny miatt a világ próbál a GCM módban futó AES felé menni. A web szerverek és böngészők fejlesztőinél már megjelent az SSL/TLS réteg kódjaiban pár évvel ezelőtt. A jogszabályi háttérnél is lehet látni, hogy az EU tagállamaira nézve szó szerint érvényes eIDAS rendelet (910/2014/EU) műszaki követelményei között van olyan témakör (XML Encryption), ahol kizárólag a GCM módú AES engedélyezett, míg máshol (SSL/TLS) a GCM mód mellett egyelőre még a CBC mód is elfogadható. Maga a KRACK leírása is kiemeli, hogy a rejtjelezett adatot megfejteni és visszajátszani mind az AES-CCMP, mind az AES-GCMP esetében lehetséges, viszont az előbbiben levő, CBC-alapú ellenőrzőösszeg miatt a csomag módosítására AES-CCMP esetében nincs lehetőség, csak az AES-GCMP beállításnál.Simplified, against AES-CCMP an adversary can replay and decrypt (but not forge) packets. [...] Against WPA-TKIP and GCMP the impact is catastrophic: packets can be replayed, decrypted, and forged. /forrás: https://papers.mathyvanhoef.com/ccs2017.pdf /
/forrás: https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eIDAS+Profile / A CTR-alapú működés végzetes problémáját a következő OpenSSL mintaadatokon keresztül próbálom bemutatni (de ezzel kezdi a WPA2 KRACK sérülékenység bemutatását a Mojo Networks blogja is: https://blog.mojonetworks.com/wpa2-vulnerability). Ha a "key" kulcs ugyanaz, a "counter" vagy "nonce" vagy "IV" pedig újrahasznosításra kerül, illetve két "ciphertext" (pl. C[1] és C[2] block) mellett az egyik "plaintext" (pl. P[1]) is ismert, akkor a másik "plaintext" (pl. P[2]) kifejezhető egyszerűen XOR művelet révén (az egyik "plaintext" úgy is lehet teljesen vagy részben "ismert", hogy a támadó csak találgat, hogy mi lehet a szöveg, és figyeli, hogy az XOR után is értelmes szöveg esik-e ki).openssl enc -aes-256-ctr -in data_plaintext_1.txt -out data_ciphertext_1.txt -e -K 6B9724A06C67491E811DC54D22272466681F3BAEBD9DDC7888272FCECD50820D -iv 19F19066C4858A0CD9C3FADAFDF4916DUgyanez a támadás a CBC-alapú működés esetében csak bizonyos helyzetekben okozhat problémát (pl. két különböző üzenet P[1] block eleménél), de általánosságban nem ad lehetőséget a rejtjelezett szöveg teljes vagy részleges megfejtésére. Ez a támadás legalábbis nem, viszont a CBC-alapú működésnek van más problémája: "padding oracle attack". Azaz... Ha adott egy nyílt szöveg (P), ami egy szimmetrikus kulcs (key) és CBC módban futó algoritmus (alg), illetve a kezdőérték (IV) alapján létrehozza a rejtjelezett szöveget (C), majd ennek megfelelőségéről egy entitás állít valamit, akkor lépésről-lépésre, de a rejtjelezett szöveg megfejtésre kerülhet. Persze, ehhez kell egy "oracle" is, ami használható választ ad a támadó kérdéseire ("jó-e a padding?"): helyben, a saját gépen ilyet könnyen találhatunk, de kifelé ilyen információt nem jó visszaadni... Az én esetemben a PHP keretrendszer openssl_decrypt() függvénye az "oracle". A mintakódot a SkullSecurity blog nagyon jó, step-by-step leírása alapján raktam össze, de az értékeket (pl. "plaintext") módosítottam, hogy láthatóbb legyen a probléma súlya. A 12 byte "plaintext", ami rejtjelezésre kerül a "PWD is: HACK". A "plaintext" a 12 byte után még 4 byte padding-et kap (a block mérete alapján a jelen beállításnál). Mivel PKCS#5/PKCS#7 padding az alapértelmezett (különbség csak a méretben van, de a működési logika ugyanaz), ha 4 byte a padding, akkor 4 db "04" byte kerül a "plaintext" végére (szemben pl. a - más téma miatt már visszavont - ISO 10126 randomizált padding megoldásával). No, indulhat is a pörgetés! (Megjegyzés: Nem került minden C_mod[1][k] kiírásra, csak lépésenként 2 byte, amiből az egyik még XOR művelet révén kerül kiszámításra, a másik pedig már a [0..255] pörgetésből esik ki.) A kód lefutása után, a támadás eredményeképpen megjelenik a megfejtett utolsó 8 byte (1 block), ami jelen esetben pont a titkos jelszót tartalmazza (a "láthatatlan" padding adatokkal együtt): "HACK".
/forrás: https://blog.skullsecurity.org/2013/a-padding-oracle-example alapján készült mintakód / Vannak tehát előnyök és hátrányok mindkét oldalon, de akkor milyen egyéb szempont van, ami segíthetne eldönteni a "CBC vs. GCM" kérdést? Szép-szép, hogy a GCM mód már elég régóta támogatott a fontosabb alkalmazásokban, mint pl. SSL/TLS rétegben mind a szerver oldal, mind a kliens oldal fel van rá készülve kb. 2014 óta. A Firefox mögötti NSS library v3.13 és v3.14 verziójában jelent meg, de ugyanezen NSS library van a LibreOffice hátterében is többek közt Linux, illetve Android környezetben, így ott is él a támogatás, viszont pl. PHP keretrendszernél csak a v7.1.0 változatnál, 2016. december 1-én lett meg a teljes körű támogatás. De... A GCM mód esetében nem elegendő csak az SW-rétegben körülnézni és frissíteni. A GCM módú működés érzékeny a különböző "side channel attack" próbálkozásokra, ezért a legtöbb kriptográfiai library igénybe veszi a processzorokban 2008 környékén megjelent AES-NI (AES New Instructions) HW-támogatást is. (Érdemes ellenőrizni, hogy az adott CPU támogatja-e az AES-NI utasításkészletet: a Microsoft Sysinternals Coreinfo vagy a "grep flags /proc/cpuinfo" is alkalmas lehet erre, de persze, Google Search is meg tudja mondani...). Az AES-NI utasításai (AESENC, AESENCLAST, AESDEC, AESDECLAST, AESKEYGENASSIST, AESIMC, PCLMULQDQ) közül a PCLMULQDQ a legérdekesebb a GCM módú működés, azon belül is az GHASH ellenőrzőösszeg számítása szempontjából. Ennél a lépésnél van ugyan lehetőség arra, hogy optimalizált és ezáltal gyorsabb működés legyen elérhető, de a szakértők szerint ezzel megnyílik az út a "side channel" támadások előtt. (Ezen téma kapcsán köszönet és pacsi jár dnet - Hackerspace, Silent Signal - és Pintér Krisztián - Password Hashing Competition versenyen indított Gambit algoritmus tervezője - low-level értelmezéseiért!)The NSS team has released Network Security Services (NSS) 3.14, which is a minor release with the following new features: [...] /forrás: https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_3.14_release_notes /
/forrás: https://xkcd.com/1286/ / Én úgy szeretem édösapámat, mint az emberek a free WiFi-t! /XXI. századi népmese/Kapcsolódó anyagok: | ||
| vissza | ||
info@ugyfelkapu.info
