Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

Lehetetlen küldetés

2009.12.15. 22:00 | buherator | 5 komment

Azt mondja az Index:

A katonai szintű titkosító technológiákat fejlesztő izraeli cég provokálja a hackereket, és aranyrudakat ajánl annak, aki feltöri az algoritmusát. Az előző versenyükön nem volt győztes.

A hírt kb. két hete olvastam valahol, és már akkor is azt gondoltam, hogy ez egyszerű marketingfogás, ami nem érdemel sok szót. Most viszont, hogy magyarul is megjelent, na meg mivel kaptam egy tippet, hogy Schneier bácsi már megmondta a tutit a hasonló nagyotmondásokkal kapcsolatban, úgy gondoltam osztok egy kis észt: 

Először is, pusztán egy tízperces mintából megfejteni akármit csak a letriviálisabb algoritmusok esetén esélyes. A helyzet hasonló ahhoz, mint amikor az önjelölt jövőbelátók megfejtik valamelyik szent írásba rejtett "előrejelzéseket":  tetszőleges két bithalmaz között (az információelmélet határain belül) található egy megfelelő "titkosító algoritmus", amely az egyiket a másikba viszi át.

A Gold Lock esetében kicsit jobb a helyzet, ugyanis legalább a titkosító szoftverek elérhetőek, így az algoritmus (minden bizonnyal keserves munka árán) visszafejthető, plusz a cég azt is elárulja, hogy az AES szimmetrikus algoritmust, elliptikus görbéket és Diffie-Hellman kulccserét alkalmaz. Na itt álljunk meg egy-két szóra:

  • Az elliptikus görbéken alapuló eljárások nyilvános kulcsúak, akkor minek a kulccsere? 
  • A sajtóanyagban az szerepel, hogy folyamatosan változnak a kulcsok. Köztudott, hogy kulcspárokat generálni nem kis számításigényű művelet, főleg egy telefon hardverén, szóval szerintem inkább maradjunk a Diffie-Hellmannál
  • Ha rágugliztok a Gold Lockra, olyan hírdetést is láttok, hogy konkrétan az AES 256 bites változatát alkalmazza a cég. A sok bit az jó, csak nem ebben az esetben: nem olyan régen írtam az AES 256 kulcsidőzítőjét érintő problémáról, ami főleg ilyen, gyakori kulcsváltásokkal operáló alkalmazásoknál lehet kritikus.

Ez persze nem azt jelenti, hogy az algoritmus/protokoll rossz, de jó kicsit végiggondolni a hasonló dolgokat, mikor egy ilyen hírt hallunk. De nézzük végig Schneier úr vezényletével, hogy miért is értelmetlenek az ilyen versenyek:

Az bizonytalanságon alapuló biztonság (security through obscurity) nem működik, különösen a kriptográfia területén nem. Amennyiben meg akarjuk vizsgálni egy algoritmus jóságát, fel kell tételeznünk, hogy a támadó mindenhez hozzáfér az algoritmus "titkán" (ez általában a titkosítási kulcs) kívül. Gondoljunk bele: egy háborús szituációban az ellenség simán megszerezheti a titkosító algoritmus specifikációját (ahogy az Enigma esetében történt), hozzáférhet bizonyos nyílt-titkos szöveg párokhoz, vagy akár a titkosító kulcsok bizonyos részeihez vagy transzformáltjaihoz is! Mindez igen komoly segítséget adhat egy ismeretlen kriptoszöveg megfejtéséhez, a versenyeztetők azonban általában nem adják meg mindezeket az információkat.

Ezek mellet nem szabad elfeledkeznünk arról sem, hogy kik és hogyan végzik a vizsgálatokat? Egyáltalán nem biztos, hogy egyáltalán van olyan kompetens szakértő, aki hozzálát a megoldáshoz. A próbálkozók munkáját senki sem koordinálja, lehet hogy mindenki ugyanazokat a vakvágányokat futja végig. A fődíj megnyerésére pályázók pedig valójában jobban tennék, ha lottóznak: a szerencsejátékok befektetésigénye jóval kevesebb, mint amennyi időt és energiát egy ilyen bizonytalan kimenetelű munka igényel.  

Ha tehát a versenynek nem lesz nyertese, az nem jelent semmit az algoritmus minőségével vagy a szakértők képességeivel kapcsolatban. Különben is: Nagyon jó, sokat vizsgált kriptográfiai algoritmusokat ismerünk és alkalmazunk nap mint nap, amelyek bár elméletileg feltörhetők, ehhez jelenlegi ismereteink szerint több idő és energia lenne szükséges, mint amennyit akár csak el tudnánk képzelni.

Szóval ne dőljünk be az olcsó marketingfogásoknak, inkább higyjünk a matematikának és a józan észnek!

Címkék: kriptográfia gold lock

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben és az adatvédelmi tájékoztatóban.

synapse · http://www.synsecblog.com 2009.12.16. 10:06:45

Hali

En nem ertek a kriptografiahoz, de az ssh rfcvel picit kepben vagyok:

"Az elliptikus görbéken alapuló eljárások nyilvános kulcsúak, akkor minek a kulccsere?"

DH a perfect forward secrecy miatt van benne. Igy ha a priv kulcs kompromittalodik (utolag), akkor sem lesz baj belole mert a session keyt hasznalja.

"Köztudott, hogy kulcspárokat generálni nem kis számításigényű művelet, főleg egy telefon hardverén, szóval szerintem inkább maradjunk a Diffie-Hellmannál"

Azert nemart neha megujitani ezt a kulcsot, mondjuk ha 6 napig telefonalsz egyhuzamban. Tudom, tudom sarkos pelda, telefon hardveren tenyleg nem tul celszeru.

"A sok bit az jó, csak nem ebben az esetben: nem olyan régen írtam az AES 256 kulcsidőzítőjét érintő problémáról, ami főleg ilyen, gyakori kulcsváltásokkal operáló alkalmazásoknál lehet kritikus."

Ha erre (buhera.blog.hu/2009/08/02/ujabb_aes_tamadasok) gondolsz, akkor gondolom vagod hogy 10 koros aes256ra vonatkozik es az aes256 (elvileg :))14 koros. Emellett a tamadasnak vannak limitacioi, de azert franko cucc :)

Amugy en szemely szerint mar regota vagyok egy ilyen appra ami ezt frankon meg tudja oldani. Elsosorban manapsag az sms-eket lenne celszeru eloszor cryptelni mert azt torveny szerint minden providernek logolni kell x evig. Persze gondolom a telefont is lehallgatjak de probalok nem paranoid lenni :)

synapse

buherator · http://buhera.blog.hu 2009.12.16. 11:20:25

@synapse:
"DH a perfect forward secrecy miatt van benne. Igy ha a priv kulcs kompromittalodik (utolag), akkor sem lesz baj belole mert a session keyt hasznalja." OK, de DH-hoz alapból nem kell privát kulcs, csak egy jó RNG. Nem mondom, hogy nincs értelme így kombinálni a dolgokat, lehet hogy pl. hitelesítésre használják a MitM-t.

"Azert nemart neha megujitani ezt a kulcsot, mondjuk ha 6 napig telefonalsz egyhuzamban."
Erre lenne jó a DH

"... gondolom vagod hogy 10 koros aes256ra vonatkozik es az aes256 (elvileg :))14 koros"
Ofkosz, de ezeket a támadásokat szokták kiterjeszteni a teljes algoritmusra, éppen ezért mondják azt a nálam okosabbank, hogy az AES256-ot komoly helyen óvatosan használjuk.

Írtam is, nem arra akartam kifuttatni ezt az egészet, hogy a megoldás szar, csak hogy jó eszünkbe jut pár potenciális buktató, akkor is, ha kriptóban gondolkozunk.

"Amugy en szemely szerint mar regota vagyok egy ilyen appra ami ezt frankon meg tudja oldani"
Ha ezt tényleg az izraeli hadsereg használja, az már elmond valamit, szerintem neked is jó lesz ;)

Aron bacsi 2009.12.16. 16:45:30

DH temakorhoz:
Az SSL/TLS-nel is ket megoldas van a "session key" megosztasara: DH (ket fel szamol es ugyanarra jutnak) vagy RSA (egyik fel szamol es atkuldi).

Tehat DH-nal valoban egy jo RNG kell, de azert ott is van mindket felnel "titkos adat" (de nem "titkos kulcs"): a kitevok, amiket a hatvanyozasnal hasznalnak a felek.

Az egy dolog, hogy az egyeztetett "session key"-t lehet talalgatni, es masik dolog, hogy ezeket a titkos adatokat, kitevoket is, de synapse altal emlegetett "perfect-forward-secrecy" tulajdonsagnak pont az a jellemzoje (ha jol ertem), hogy a kitevoket is dobjak session-onkent.

Tehat uj session eseten DH-nal minden "titkos adat" uj, RSA-nal viszont a "titkos kulcs" nem valtozik session-onkent, csak a "session key", azaz RSA-nal lehet ertelme keresgelni a "titkos kulcsot". ;-)

conscience 2009.12.16. 20:28:14

@synapse: Magam sem állok kriptóból a helyzet magaslatán, hogy a paranoiát ne is említsük. Törtem is a fejem a lehallgatás kínos problémáján, azonban nyilvánvaló, hogy a titkosításnak feltétlenül kétoldalinak kell lennie, tehát a túloldali eszköznek képesnek kell lennie a kódolt adatok visszafejtésére. Ezzel együtt a teflon [sic :D] funkcióit bővíteni kell egy "Titkosított hívás indítása" darabbal. Gyanítom,h a firmware-be kellene belenyúlni, egy szimpla app nem biztos, hogy tudja manipulálni a low-level eseményeket, persze nem nagyon csesztettem még telefont, úgyhogy ha valaki jártas a témában, kijavíthatna, mindenesetre JAVA jóeséllyel kizárva. Az AES256 azonban elég jól hangzik erre a célra, feltéve, hogy a hardver képes vele megbirkózni. Istenigazából az én múzeumi hulladékomnak (3510i) már édesmindegy...

buherator · http://buhera.blog.hu 2009.12.17. 03:28:30

@Aron bacsi: Pont azt írom, hogy ilyen értelemben a pukey módszerek és a DH helyettesítik egymást. Viszont a DH önmagában nem biztosít hitelesítést, ezért MitM-elhető, ezen viszont pubkey hitelesítéssel lehet segíteni, itt is _vszínű_ ez a helyzet. Ilyen értelemben kicsit hiányos a poszt gondolatmenete, de ezek csak ötletek, iránymutatók, ezer lehetőség van még. Pl.: azt hiszem stef hozta fel a side-channel támadások lehetőségét, amire egy ilyen SW-only megoldás esetében jó sansszal lehet lőni.
süti beállítások módosítása