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

A Microsec zrt, e-Szignó Hitelesítés Szolgáltatónál dolgozom.

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

(Ez az egész még februárban történt, de csak most írok róla.. mert lusta voltam.)

A Trustwave (http://www.trustwave.com) nevű hitelesítés-szolgáltató nagy kavarodást okozott a közelmúltban. A Trustwave kibocsátott egy hitelesítés-szolgáltatói (CA) tanúsítványt valaki olyannak, aki nem volt hitelesítés-szolgáltató, és nem a hitelesítés-szolgáltatókra vonatkozó szabályok szerint működött.

A különböző (böngésző)programok alapértelmezetten tartalmazzák egyes bevizsgált, megbízható hitelesítés-szolgáltatók gyökértanúsítványait. A programok felhasználói ezáltal automatikusan elfogadják, ha ezek a hitelesítés-szolgáltatók tanúsítanak egy weboldalt. A böngészőprogramjuk kiírja, hogy a weboldal tanúsítvánnyal rendelkezik, és a felhasználó elhiheti, hogy valóban azon az oldalon jár, és az oldallal történő kommunikációját senki nem hallgathatja le, és nem manipulálhatja.

A hitelesítés-szolgáltatók nemcsak weboldalaknak (és végfelhasználóknak) adhatnak ki tanúsítványt, hanem más hitelesítés-szolgáltatónak is. Ezáltal a (böngésző)programok a felülhitelesített hitelesítés-szolgáltató tanúsítványait is elfogadják. (A felülhitelesített szolgáltató gyakran nem másik szervezet, hanem ugyanannak a szolgáltatónak másik egysége. Egy szolgáltató általában sok egységet szokott működtetni, amelyek rafinált módon kapcsolódnak össze. Pl. itt látható egy ábra a Microsec szolgáltatói tanúsítványainak hierarchiájáról.)

Egy hitelesítés-szolgáltató felülhitelesítése nagyon kényes ügy, mert ekkor mindenki, aki megbízik a felülhitelesítő szolgáltatóban, automatikusan elfogadja a felülhitelesített szolgáltató tanúsítványait is. Általában akkor szabad felülhitelesíteni egy másik szolgáltatót, ha meg tudok győződni róla, hogy az ugyanolyan szigorú eljárásrend szerint működik, mint én magam, pl. webszerver tanúsítványt kizárólag az érintett domain tulajdonosának hozzájárulásával szabad kibocsátani.

Esetünkben a következő történt:

A Trustwave ügyfele szűrni, monitorozni akarta a belső hálózatából kifelé menő SSL forgalmat. Például, vizsgálni akarta, hogy dolgozói nem töltenek-e le vírust a gmail-es levelezésen keresztül. Az SSL forgalom titkosított, így a tűzfal normál esetben csak annyit lát, hogy SSL kapcsolat megy keresztül rajta, a kapcsolatba nem lát bele, így szűrni sem tudja. A következő megoldást találták ki: A tűzfal kapott egy CA tanúsítványt, és ha valaki a belső hálózatról a https://xyz.com címre akart kapcsolódni, akkor a tűzfal kiadott saját magának egy webszerver tanúsítványt erre a címre, és megszemélyesítette a kérdéses weboldalt. A végfelhasználó azt hitte, hogy a gmail.com oldallal épített ki SSL kapcsolatot, holott valójában a tűzfallal kapcsolódótt össze, a tűzfal visszafejtette a kapcsolatot, vírusellenőrizte, majd egy másik SSL kapcsolatot épített ki a gmail.com oldallal. (Ez lényegében egy ún. man-in-the middle támadás, amit a tűzfal intéz a felhasználó ellen - a felhasználó védelmében.)

Senki nem akart rosszat. A cél "fehér" volt, de az eszköz elég csúnya. Az ilyen célt úgy szokás megvalósítani, hogy a vállalat saját gyökértanúsítványt hoz létre, ezt feltelepíti a vállalat összes kliensgépére, és a tűzfal erre a gyökérre visszavezethető tanúsítványokat ad ki. (Gondolom, azért használtak inkább nyilvános CA-t, amelyet minden böngésző automatikusan elfogad, hogy ne kelljen a kliensgépekre telepíteni a saját gyökeret.)

A cél nem volt rossz, de egy nyilvánosan működő CA egész egyszerűen nem teheti meg, hogy fűnek-fának olyan tanúsítványokat ad ki, amelyekkel azok bármelyik Internet-felhasználót becsaphatnak. Nyilvánosan működő CA a nyilvánosan elfogadott gyökerével - amit minden Internet-felhasználó elfogad - nem vehet részt ilyenben. Szaktanácsot persze adhat, segíthet kiépíteni a vállalatnak a saját PKI-ját, de a nyilvánosan elfogadott gyökerét csak a szabályok szerint használhatja, különben a teljes internetes közösséget veszélyezteti.

A Trustwave egyébként állítólag gondosan járt el, a man-in-the-middle támadásokat végrehajtó CA magánkulcsát kriptográfiai hardver modul (HSM) védte, a weboldalakat megszemélyesítő kulcsok szintén e HSM-ben keletkeztek, és csak nagyon rövid ideig léteztek stb. Ennek ellenére a szakma felháborodott ezen az eljáráson, és a Trustwave most vesszőfutáson megy keresztül.

Az a pletyka járja, hogy mások is csináltak ilyet, és a Trustwave nem egyedi eset volt...

A Mozilla kiküldött minden CA-nak egy levelet, hogy ez csúnya dolog, és ilyet nem szabad csinálni. Az Opera is élesen elhatárolódott az esettől. A Mozilla visszavonatta az érintett CA tanúsítványt, és minden szolgáltatót beszámoltatott, hogy csinál-e ilyet, és ha igen, vissza kellett vonnia a hasonló tanúsítványokat.

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.

További bejegyzések a blogomban...