2004-ben MBA fokozatot szereztem a brit Buckinghamshire Chilterns University College-ben. 2006-ban CISA fokozatot szereztem.

A Microsec e-Szignó Hitelesítés Szolgáltatónál dolgozom, mint
K+F igazgató.

Mivel foglalkozom?

• PKI és elektronikus aláírás,
• Elektronikusan aláírt dokumentumok hosszú távú érvényessége és hosszú távú archiválásána,
• Elektronikus aláírás nem biztonságos terminálon,
• Intelligens kártya biztonság.

Elérhetőségeim:
e-mail:
telefon: +36302483630

Bruce Schneier blogjában találtam ezt a bejegyzést, amely erre a hírre mutat a Reuters oldalán. Én is csak ennyit tudok.

Eszerint többször is sikeresen feltörték a Verisignt, még 2010-ben. A közelmúltban változott az arra vonatkozó amerikai szabályozás, hogy egy cégnek milyen biztonsági incidenseket kell lejelenteni, ennek kapcsán derült ki most az ügy.

Szintén 2010-ben történt, hogy a Symantec megvette a Verisign SSL üzletágát. A Verisign tovább működött, főként a DNS biztonság területén (http://www.verisigninc.com), ugyanakkor a Symantec is Verisign (Authentication Services) márkanéven működtette tovább az SSL tanúsítvány üzletágat (http://www.verisign.com). (Nem sokkal ezután történt az is, hogy az SSL blogot vezető Tim Callen elment a Verisign-tól, és azóta az SSL blogban javarészt marketing bullshit van, Tim Callen pedig új blogot nyitott.)

Nem lehet tudni, hogy a támadásnak volt-e köze a Verisign CA-jához, illetve hogy amit feltörtek, az most a Verisignnál vagy a Symantec-nél van-e. Ami biztos, hogy manapság a Symantecre is alaposan rájár a rúd.

Az is tény, hogy túl sok PKI biztonsági esemény történit az utóbbi egy évben...

Frissítés: A Diginotartól leginkább azért vonta meg a világ a bizalmat, mert nem jelentették az incidenst, hanem el akarták titkolni. Ha igaz, hogy itt a CA-t érte a támadás, még 2010-ben, és ez csak most, 2012-ben látott napvilágot, akkor a Verisignt sem lehet azzal vádolni, hogy túlságosan elkapkodta volna a hiba bejelentését...

Frissítés2: Mégsem csak marketing bullshit van az SSL blog utódjában, szerepel ott két cáfolat, melyek szerint a Symantec egyáltalán nem érintett; nem az egész Verisignt, hanem csak egy független egységet vettek meg, ami csak "kicsit" volt összecsavarodva a Verisign többi részével.

A Google nagy erőkkel hirdeti a weben, hogy március 1-től megváltoznak az adatvédelmi irányelvei, és "ez fontos". Számomra ennek "nehogy később azt mondd, hogy mi nem szóltunk" hangulata van. Tapasztalatom szerint, ha adatvédelmi irányelvek változnak, annak vagy egyáltalán nincs jelentősége (csak valaki meg akar felelni egy zavaros jogi előírásnak), vagy van jelentősége, és akkor bizony semmi jót nem jelent.

Mindenesetre úgy gondoltam, utánaolvasok, mert érdekel.

Magukon az irányelveken nem rágtam át magam, mert IANAL; és bár egy jogi szövegtől nem ijedek meg, de az apró jogi finomságok jelentőségét nem érteném, itt pedig pont ezekre vagyok kíváncsi. A Google tájékoztató oldala büszkén hirdeti, hogy ez a változás mennyire jó a felhasználónak, mert így jobb szolgáltatást kaphat. Ezt sem olvastam végig, mert csak marketing blabla, engem pedig most épp az ügy sötét oldala érdekel (mármint az, hogy van-e sötét oldala).

Rákerestem, hogy mások mit írnak a témáról. Google-lel kerestem - természetesen.

Magyarul csak ezt és ezt a cikket találtam. Angolul sokkal több irodalom található a témában.

A következőt szűrtem le:

1. Mostanáig külön-külön adatvédelmi irányelvek vonatkoztak a Google egyes szolgáltatásaira (kereső, docs, gmail, youtube, blogger, picasa stb), és ezeket most egységesítik, így elég lesz egy dokumentumot elolvasni. Ez jó.

2. Mostanáig a Google vállalta, hogy nem köti össze a különböző szolgáltatásaiban nyilvántartott adatokat, de az Egy Irányelv lehetővé teszi ezt. Ez jó, mert így a Google többet tud a felhasználóról, így jobban ki tudja találni, hogy mire gondolsz, amikor keresel, és jobban tudja mit ajánljon neked (valamint jobban tudja célozni a reklámjait). Ugyanakkor ez rossz is, mert a Google így sokkal többet tud meg rólad.

3. Március 1-ét követően már nem lehet nem kérni ezt a plusz szolgáltatást, az egyes szolgáltatások adatai összekapcsolódnak, akár akarod, akár nem. (Eszerint a cikk szerint nincs opt out.) Ez nem jó.

4. Ez a cikk azt feszegeti, hogy vajon mindez mennyiben vonatkozik a Chrome böngészőre és az Androidra. Ez esetekben a Google a klienst is a kezében tartja, és így megint sokkal többet tudhat meg. E másik cikk szerint a Google kijelentette, hogy a Chrome-ra, a Google Wallet-re és a Google Books-ra nem vonatkozik az új irányelv.

Írnak olyat, hogy most a Google tényleg túlment egy határon, és fel fogja háborítani a felhasználói közösségét. Én nem vagyok biztos benne. A felhasználók többsége nem érti meg, hogy mit jelent ez, és igazság szerint pontosan én sem értem.

Azt sem érzem, hogy nekem fel kellene háborodnom. Igazság szerint nem tudtam, hogy a Google vállalt olyat, hogy nem köti össze a különböző szolgáltatásaiban tárolt adatokat. Van egy közös beléptető modulja, így a lehetősége biztosan megvan rá. Ha pedig két adatbázist össze lehet, kötni, azok bizony összekötődnek. (Persze nem maguktól kötődnek össze, informatikusok kötik őket össze vérrel, verejtékkel, switch-ekkel és SQL statementekkel.) Ha az üzleti motiváció megvan, akkor az összekötés csak idő kérdése. Hiába ígéri valaki, hogy nem, előbb-utóbb akkor is. Ez éppen olyan törvényszerűség, mint hogy ha egy pénzdarabot leejtek, akkor az lefelé fog esni, nem pedig felfelé. Aki a cloud ingyenes szolgáltatásait használja, az számítson az ilyenekre.

Azt sem mondom, hogy nem jó a cloud ingyenes szolgáltatásait használni. Hatalmas erő van a Web2.0-ban, épp akkora hiba nem kihasználni, mint teljesen rábízni magunkat. Használjuk inkább ésszel, és tartsunk be néhány elemi óvintézkedést (pl. külön feladatra külön Google fiók, privát böngészés üzemmód, gondoljuk meg, milyen titkot bízunk titkosítatlanul a cloud-ra, és ami fontos, arról legyen más, biztonságos mentésünk is).
Még ekkor is érhetnek meglepetések...

A tavalyi év végén derült egy wifi biztonsági hibára. Igen álnok dologról van szó, mert eddig biztonságosnak hitt beállításokkal működő wifi routerekről derült ki, hogy szinte tárva-nyitva állnak. Lényegében minden nagyobb gyártó friss termékei közt vannak érintettek.

A probléma onnan ered, hogy nehéz úgy beállítani egy wifi routert, hogy az biztonságos legyen. Közben olyan felhasználók is tömegével állítanak üzembe otthon wifi routert, akiknek a WPA, WEP, TKIP, AES, és más hasonló rövidítések semmit nem mondanak. Logikusan merült fel, hogy legyen egyszerű megoldás a routerek biztonságos beállítására.

A Wi-Fi Alliance kitalált egy Wi-Fi Protected Setup (WPS) nevű eljárást, ami - egyik üzemmódjában - arra épül, hogy a routerre kívül, egy matricán rá van írva egy jelszó/kulcs, és aki ezt tudja, az kapcsolódni tud a routerhez, el tudja kérni tőle a wifi rejtjelezéséhez használt kulcsot. Így aki oda tud menni a routerhez, az könnyen tud hozzá kapcsolódni is. (Le kell futtatni egy notebookon a router telepítő programját, meg kell adni neki a routerre ráírt jelszót, és a telepítő beállítja a notebookot, hogy kapcsolódhasson az adott routerhez.)

Az a probléma, hogy a jelszó/kulcs egy csupán 8 számjegyből álló PIN kód. Ez se túl sok, de más hibák következtében ebből elegendő lényegében 4 számjegyet kitalálni, és ez számítógéppel pillanatok alatt végigpróbálható.

(A 8 jegyű PIN kód 10^8 variációt jelentene. Csakhogy ha kipróbálunk egy PIN kódot, a router által visszaadott üzenetből kiderül, hogy a hiba az első 4 vagy a második 4 számjegyben van, így a támadó külön-külön keresheti végig az első 4 és a második 4 számjegyet. Ezen túl az egyik számjegy ellenőrző összeget tartalmaz, ami következik a többiből, azaz a támadónak elég 10^4 + 10^3 db próbálkozást futtatnia.)

Sok újonnan vásárolható routeren a WPS alapértelmezetten be van kapcsolva (hiszen csak így nyújthat segítséget a telepítésben). Így a WPS-nek köszönhetően azoknak a wifi routerét is fel lehet törni, akik eddig az sem tudták, hogy a WPS a világon van.
Hogy miért találnak ki egyesek ilyeneket!?

Ki kell kapcsolni a routerben a WPS-t (vagy meg kell győződni róla, hogy nincs ilyen a routerben).

Itt található a hibát bejelentő saját blogbejegyzése, a részleteket leíró cikk, és a cert által nyilvántartott sebezhetőség.

Az EU elnökség szervezett egy elektronikus aláírás konferenciát Varsóban, meghívott előadóként beszéltem a biztonságos aláírás-létrehozó eszközökről. Bemutattam, hogy milyen megközelítések

Az előadásom diái itt érhetőek el.

Felröppent egy hír, miszerint a TLS hibáját kihasználva le lehet hallgatni a https kapcsolatokat. A támadás részletei még nem ismertek, így nem lehet tudni, hogy pontosan mit érint, és mekkora a jelentősége. A támadást bejelentő Rizzo és Duong ismert nevek, így a hír valószínűleg igaz. A napokban mutatják be részletesen a támadásukat az Ekoparty konferencián, Buenos Airesben.

Az eddig megjelent hírekből a következőket szűrtem le:

• A támadás a TLS protokoll 1.0-s változatának egy hibáját használja ki. (A TLS az SSL újabb elnevezése, így én időnként felváltva használom ezeket az elnevezéseket.) Csak a protokoll 1.0-s változat ellen működik a támadás, bár vannak már frissebb, 1.1-es és 1.2-es változatai is.

  (Kérdés, hogy a protokoll tervezői tudtak-e a hibáról, és tudatosan javították-e ki a hibát az 1.1-es és 1.2-es változatban, vagy csak véletlenül oldódott meg a probléma.)

• A böngészők szinte kivétel nélkül csak a protokoll 1.0-s változatát támogatják. Van olyan böngésző, ami támogatja ugyan a magasabb (pl. 1.2-es verziót), de alapértelmezetten nem.

• A támadás segítségével a TLS-en forgalmazott információt lehet visszafejteni, azaz a támadás a bizalmasságot érinti, a hitelességet nem. Eszerint nem lehet észrevétlenül beszúrni információt az adatforgalomba, és nem tudja kiadni magát a támadó egy másik weboldalnak.

• A támadás "chosen plaintext attack", azaz akkor működik, ha az áldozat a támadó által meghatározott csomagokat küldi el a hálózaton. A támadó ezek titkosított változatát lehallgatva jut hozzá olyan információhoz, amely segíti a további üzenetek visszafejtésében.

• A TLS kommunikáció visszafejtése néhány perc alatt történik, azaz majdnem online.

A támadás ennyi alapján elég nagy durranásnak tűnik, de lehet, hogy az derül majd ki róla, hogy csak spec. körülmények között működik. Ha mégsem, akkor sem várom, hogy ettől dől össze az internetes kommunikáció biztonsága. Egy adott protokoll egy adott változatában (és nem is a legfrissebben) találtak hibát, valószínűleg nem a fő alapelveit kezdték ki. Igaz, a hiba javítása okoz majd némi felfordulást. Schneier azt szokta mondani, hogy szerinte nem az SSL/TLS a leggyengébb pontja az internetes biztonságnak, a támadók többnyire nem a hálózaton utazó hitelkártyaszámokat kapják el (mert az macerás), hanem sokkal egyszerűbb nekik feltörni a szervereket, ahol a hitelkártyaszámok (gyakran) ott figyelnek egy csomagban. (Igaz, a lehallgatásra is vannak már egyszerűen használható eszközök.)

Lényeges, hogy a fentiek az eddig megjelent hírekre alapuló spekulációk, biztosat akkor fogunk tudni, ha a támadás részleteit is publikálják. Ha lesz több információ, írni fogok róla. :)

Itt egy spekuláció arról, hogy hogyan működhet a támadás.

További bejegyzések a blogomban...