| | | | | Mottó:
Valamelyik francia szocialista azt
mondta, hogy a magántulajdon
lopás. Én azt mondom, nyűg.
/Erdős Pál, matematikus/ | | 2015. február 14. | | | | | Kleptográfia: helyből IV | | | | | | Pár hete ismét előjött egy blog oldalon a kleptográfia fogalma, amiről Tihanyi Norbert (NBF) nemrég a cryptonite előadásán is sokat beszélt. Ennek kapcsán kiderült, hogy hiába használunk egy matematikailag jó algoritmust közel 40 éve, még az utóbbi időben is finomítani kellett az RSA "best practice" paramétereinek ajánlását a kleptográfia megjelenése miatt. Az aktuális értékeket a német BSI, illetve a nemzetközi ETSI szabványosító szerv dokumentumai foglalják össze (érdekes, hogy a NIST dokumentumai nem ilyen részletesek).
A fogalomról - amely egyébként már 1996 óta létezik, de csak az utóbbi néhány évben került a középpontba - van már a neten több cikk is, amely leírja, hogy miért olyan nagy baj a túl hosszú, vagy kacifántosan előállított modulus az RSA-nál, vagy a furcsa paraméterezés a Dual_EC_DRBG PRNG esetében, milyen információt tudtak így elrejteni, kik tudták ezt kiolvasni. A trükkök ügyesek, de azoknak is kell lennie, hiszen pl. RSA alkalmazásában jártasabbak a rendszertervezők, fejlesztők, nehezebb észrevehetetlenné tenni ilyen csapdákat, egy ritkábban használt ECDSA esetében könnyebb ilyen backdoor-t elrejteni (ott a fejlesztők még alaphibákat is el tudnak követni, ld. Sony PlayStation 3 esete a fail0verflow csapatával 2010-ben).
Az RSA és kleptográfia kapcsán gondolkodtam el azon, hogy más esetekben is, vajon mennyire könnyű kicsempészni titkos adatokat? Bár, definíció szerint a kleptográfia az aszimmetrikus kódoló algoritmusokat érinti - és így e bejegyzés címe is sántít -, de szimmetrikus kódolókkal talán könnyebb bemutatni, hogy miről is van szó. Konkrétan egy pl. CBC-módú AES szimmetrikus kódoló algoritmusnál érdemes elgondolkodni azon, hogy mit lehet tudni arról, hogy mi kerül a 128 bites IV-be (Initialization Vector)? Volt már rá példa, hogy nem én adtam meg közvetlenül egy jó minőségű véletlen adat révén az IV-t, de nem is tudtam ellenőrzni, hogy a getIV() függvény pontosan mit csinál a háttérben. Pedig egy ilyen IV-re egészen komoly követelmények vonatkoznak, mint pl. "Implementations must randomly generate content-encryption keys, [...] initialization vectors (IVs) [...].", de talán a leglényegesebb, hogy ebből az IV-ből ne következzen semmi sem a titkos adatokra vonatkozólag. Ha ez nem áll fenn, akkor olyan támadásoknak lehet táptalaja, mint anno az SSL/TLS protokollt érintő BEAST (2011-09-23).
Hogy is árthatna az IV - véletlen vagy szándékos - rossz implementációja a rejtjelezett adat bizalmasságának? Mind a CMS adatstruktúránál (ld. Rejtelmek: CMS envelopedData bejegyzésemet), mind a W3C által gondozott XML Encryption Syntax and Processing szabványnál látható, hogy maga az IV publikus adat, és letárolásra kerül a rejtjelezett adat mellé/elé.[AES] is used in the Cipher Block Chaining (CBC) mode with a 128 bit initialization vector (IV). The resulting cipher text is prefixed by the IV.
/XML Encryption Syntax and Processing/ This document specifies the use of the AES cipher in CBC mode within ESP. This mode requires an Initialization Vector (IV) that is the same size as the block size. [...] The AES uses a block size of sixteen octets (128 bits).
/IETF RFC 3602/ Ha viszont publikus, akkor nem ártana tudnunk, hogy mi kerül bele, nem? A mellékelt példában - CBC-módú AES 128 bites kulccsal - egész egyszerűen magát a titkos szimmetrikus kulcsot pakoltam be az IV-be is (ez így persze, nagyon feltűnő, de ha csak egy néhány byte-eltolásos Caesar-kódolást rátennék, már nem szúrna szemet ennyire egyszerűen). XML Encryption adatstruktúra esetén az eredmény - IV és rejtjelezett adat összefűzve és base64 kódolva, ami a /EncryptedData/CipherData/CipherValue elembe kerül - valahogy így néz ki:
Szóval, vajon mennyire ismerjük a getIV() függvény működését? És vajon a többi paraméter mennyire szivárogtat ki titkos adatokat? Érdemes ellenőrizni a forráskódokat, ha vannak olyan paraméterek, amelyek létrehozását és kezelését nem tudjuk teljes mértékben ellenőrzésünk alatt tartani...
Kapcsolódó anyagok:
| | | vissza | | | | | |
|
