Ha az "RSA" és a "feltörés" kifejezések egy mondatban szerepelnek, az általában masszív hírfolyamot generál, nem történt ez másként a Project-Team Prosecco legújabb, hardver tokeneket és biztonsági kártyákat vizsgáló kutatásának esetében sem. Az persze általában kimarad az újságból, hogy nem csak az RSA Inc. termékei érintettek, valamint hogy az a "feltörés" mi a csodát is jelent pontosan - emiatt a vállalatnál véleményem szerint jogosan vannak kiakadva.

A szóban forgó hardver tokenek többek között arra jók, hogy kulcsokat tároljunk bennük, méghozzá úgy, hogy azokat csak a token birtokában lehessen használni (az egyéb funkciókat, mint például az egyszeri jelszavak generálását a támadás nem érinti). A kulcsok ezért nyilván nem nyerhetők ki az eszközből, még a token tulajdonosa által sem. Annak érdekében viszont, hogy a kulcsokról biztonsági mentéseket lehessen készíteni, a tokenek képesek tartalmukat titkosított formában - "csomagoltan" - exportálni. A csomaghoz tartozó mesterkulcsot csak az eszköz ismeri, a csomagot a legitim felhasználó sem bonthatja ki, csak importálhatja az eszközére. 

Felhasznált irodalom

Az eredeti publikáció

Matthew Green - A bad couple of years for the cryptographic token industry

Nate Lawson - Why RSA is misleading about SecurID vulnerability

Nate Lawson - RSA repeats earlier claims, but louder

Sam Curry - Don’t Believe Everything You Read…Your RSA SecurID Token is Not Cracked

Sam Curry- Still Not Cracked: a further dive into the PKCS #1 v1.5 vulnerability

A francia kutatóknak azonban sikerült találniuk egy módszert, amivel a csomagok tartalma a csillagok megfelelő együttállása esetén megfejthető, ezt a támadást pedig egy sor eszközön sikerrel demonstrálták. A csillagok megfelelő együttállása nagyjából azt jelenti, hogy a támadónak ismernie kell a felhasználó PIN kódját és hozzá kell férnie az eszköz PKCS#11 szerint megvalósított interfészéhez (ezt, hogy látni fogjuk, akár távolról is megteheti) néhány ezer kérés elküldésének erejéig, ami hardvertől függően perceket, esetleg néhány órát jelent. 

Ez a támadói modell első látásra erős, de ha feltételezzük, hogy az áldozat gépét gyökérig megtörték (magyarítás FTW!), máris optimális ökoszisztémát teremtettünk. Vegyük észre, hogy a tokenek egyik feladata éppen az, hogy ilyen esetekben is védjék a kulcsokat!

De hogyan is lehetséges mindez? A kutatók alapvetően most is Padding Oracle támadást hajtottak végre szokásos CBC módú blokktitkosítók, illetve az asszimmetrikus RSA algoritmussal szemben (ennek részleteiről egy külön posztot tervezek). Kis ismétlés: a Padding Oracle támadásnál a sérülékeny rendszer a normálistól eltérő (időtartamú) választ ad, ha elrontjuk a paddinget, így a támadó manipulált kriptoszövegeket küldhet a rendszernek, aki jó orákulumként apránként kiszivárogtatja a nyílt szöveget. Fontos megjegyezni, hogy a támadás a titkosítás kulcsát nem fedi fel (de ez nem is érdekel minket).

Valójában egy bizonyos Daniel Bleichenbachernek köszönhetően 1998 óta ismert, hogy a PKCS#1 szabvány 1.5-ös verziójának megvalósításai sérülékenyek ilyen támadásokkal szemben. Gondot jelent viszont, hogy ezek az apró tokenek elég lassúak, az orákulumtól pedig sokat kell kérdezni, így a teljes támadás lebonyolításához irreálisan sok időre lenne szükség. A kutatók legfőbb eredménye, hogy Bleichenbacher támadását sikerült optimalizálniuk olyan szintig, hogy a támadás a gyakorlatban is kivitelezhetővé vált. Ehhez egyrészt matematikai okosságra, másrészt egyszerre több, eltérő "erősségű" orákulumra, illetve a nyílt szöveg struktúrájának részleges ismeretére volt szükség. Ilyen módon a támadás időtartama a fenti táblázatban látható értékek szerint alakul a különböző eszközökön. Fontos kiemelni, hogy a támadást nem muszáj egy lélegzetvételből letudni, a 21 perc kijöhet például három 7 perces alkalomból is.

Ahogy a poszt elején is írtam, az RSA/EMC elég sokat kapott az eset kapcsán, és két blogposztban is igyekeztek helyretenni a tényeket, valamint védeni a termék becsületét. Ezekben a nyilvánvaló pontatlanságok, tárgyi tévedések jogos helyesbítésén túl azonban olyan gondolatok is szerepeltek, melyek mellett nem lehet szó nélkül elmenni:

• Egy munkaállomás teljes komprommitációja esetén a token kulcsainak komprommittálása nem jelent előnyt a támadónak - Akkor miért költünk rá pénzt? [trollface] :) Optimális esetben a támadó csak addig garázdálkodhatna, amíg a token csatlakoztatva van hozzá - a támadás kivitelezése után azonban ezt bármikor megteheti (amíg le nem cserélik a kulcsokat).
• A cég ügyfelei egyébként is rendkívül biztonságtudatos vásárlók, akik csak a szükséges időre hagyják a tokent a gépükben, és olyan kifinomult biztonsági kontrollokat is alkalmaznak, mint pl. antivírus - Ehhez nem fűznék kommentárt...

A cég emellett természetesen komolyan veszi és értékeli a kutatást, és egy olyan megoldáson dolgozik, melyben a jelenleg kompatibilitási okok miatt engedélyezett PKCS#1 v1.5-öt alapértelmezetten kikapcsolják.