Szolgáltató adatai Help Sales ÁSZF Panaszkezelés DSA

About...

Napi betevő adag elírás, elütés és helyesírási hiba egy helyen! Amúgy meg #információbiztonság #webcserkészet néha #élettudomány

bardóczi ákos @post.r

blogavatar

minőségi kontent-egyveleg

RSS

cimketenger

ITsec (38),Facebook (18),privacy (17),egyéb (12),social media (11),itsec (11),social web (10),biztonság (9),mobil (8),Google (6),OSINT (6),jog (6),szellemi tulajdon (6),tudomány (6),magánszféra (6),szájbarágó (5),email (5),webcserkészet (5),molbiol (5),felzárkóztató (5),Nobel-díj (4),big data (4),Gmail (4),kultúra (4),terrorizmus (4),online marketing (4),kriminalisztika (4),plágium (4),webkettő (4),genetika (3),molekuláris biológia (3),pszichológia (3),azelsosprint (3),Android (3),biztonságpolitika (3),nyelvtechnológia (3),magatartástudomány (3),Apple (3),sajtó (3),2015 (3),orvosi-fiziológiai (3),élettudomány (3),gépi tanulás (3),jelszó (3),üzenetküldés (3),CRISPR (3),Onedrive (3),2-FA (3),popszakma (3),konferencia (3),levelezés (3),kriptográfia (3),reklám (3),biztonságtudatosság (3),hype (3),torrent (3),open source intelligence (3),neuropszichológia (2),Whatsapp (2),deep web (2),FUD (2),kulturális evolúció (2),nyílt forrású információszerzés (2),TOR (2),hitelesítés (2),titkosítás (2),Pécs (2),bűnügy (2),tweak (2),facebook (2),SPF (2),DKIM (2),bűnüldözés (2),DDoS (2),bejutas (2),videó (2),Reblog Sprint (2),természetes nyelvfeldolgozás (2),villámokosság (2),Hacktivity (2),Yoshinori Ohsumi (2),reblog (2),cyberbullying (2),arcfelismerés (2),ransomware (2),fiziológia (2),Netacademia (2),webkamera (2),szabad információáramlás (2),P2P (2),Balabit (2),cas9 (2),beszélgetés rögzítése (2),pszeudo-poszt (2),molekuláris genetika (2),bulvár (2),gépház (2),tartalomszolgáltatás (2),jövő (2),bolyai-díj 2015 (2),könyv (2),Tinder (2),öröklődő betegség (2),HR (2),sudo (2),Yandex (2),bug (2),nyelvtudomány (2),meetup (2),Twitter (2),tanulás (2),biológia (2),netkultúra (2),malware (2),IDC (2),social engineering (2),szociálpszichológia (2),kutatás (2),hírszerzés (2),iOS (2),vírus (2),farmakológia (2),pedofília (2),epic fail (2),génterápia (2)

így vigyáz az adataidra a Google


Google privacy ITsec titkosítás adatbiztonság bűnüldözésMakacsul tartja magát a hiedelem, ami szerint Svájc azoknak az országoknak az egyike, amelyik a leginkább kényes, ha a felhasználói adatok védelméről van szó, a nemzetközi jogi helyzete miatt. Féligazság, írom is, hogy miért. 

Ha mással kapcsolatban nem is nagyon került szóba a személyes adatokra olyan érzékeny Svájc a Snowden-bohózat óta, többen olvashattak arról, hogy a PRISM-parát meglovagoló viccesebbnél viccesebb cégek közül a világ egyik legbiztonságosabb email szolgáltatását ígérő Protonmail többek közt azzal az eszelős hülyeséggel bizonygatja a Svájcban tárolt információk sérthetetlenségét, hogy a szervertermük gyakorlatilag be van vájva egy hegy gyomrába, ami egyébként akár még igaz is lehet, de egy levelezőrendszer nem ettől lesz biztonságos. A Protonmail egyébként ugyanaz a vicces szolgáltató, amelyik ugyanakkor teljesen védtelen volt egy tankönyvi bonyolultságú ún. cross-site scripting támadás ellen, azaz sokáig szinte tetszőleges szkriptet, így rosszindulatú kódot is be lehetett illeszteni a levelek törzsébe, amik szépen le is futottak amikor a Protonmail-felhasználó megnyitotta a levelet. 

Mindez semmi ahhoz képest, hogy az ugyancsak ultrabiztonságosnak tartott Google-től a hatóságok az esetek felében-kéthamadában megkapták azokat a felhasználói adatokat, sejthetően svájci felhasználókról, amiket különböző hatóságok kértek, ami azért minimum elgondolkoztató arány. Swiss Federal Data Protection Ordinance ide, Swiss Federal Data Protection Act oda, az USA-tól és az EU-tól való viszonylagos függetlenség ide vagy oda, ha a svájci hatóságok valamit kikérnek, nagyon sokszor meg is kapják, azt pedig egy pillanatig se felejtsük el, hogy mindehhez az érintett felhasználónak nem kell rablógyilkosnak, terroristának vagy tonnás mennyiségekben seftelő drogdílernek lennie. Mivel egy kellően jól összerakott jogi indoklást követően az alapos gyanú is elég lehet ahhoz, hogy a Google már küldje is az adatokat, díszdobozban. Ugyan a transparency report nem tér ki rá, de eléggé világos, hogy döntően Gmail-fiókokról és adott Google-felhasználókhoz kapcsolódó, azonosításra alkalmas információkról lehet szó, ráadásul a kaliforninai bíróságon, amelyik szerintem illetékes lehet, általában meg sem próbálja a Google megfúrni az adatigényléseket, de nem is köteles a Google vizsgálni azoknak az indokoltságát. 

Google privacy ITsec titkosítás adatbiztonság bűnüldözés


Mindeközben Magyarországon... Ha megnézzzük, hogy mi a helyzet a magyar felhasználókat érintő, magyar hatóságok által kezdeményezett adatigénylésekkel kapcsolatban hízhat a májunk, mert az látszik, hogy az egyébként kis számú adatigénylésből egészen pontosan nulla százaléknak tett eleget a Google. 

Google privacy ITsec titkosítás adatbiztonság bűnüldözés

Innentől már csak lehet tippelgetni, hogy miért. Valószerűtlennek tartom, hogy a magyar nyomozó hatóságok annyira tompák lennének, hogy ne tudják, hogy hogyan állítsanak össze olyan adatigénylést, amire majd érdemben kapnak is választ, ezen kívül vannak azért kemény kötésű és tájékozott telco jogászok Magyarországon is bőven. Az egyik optimista feltételezett ok az lehet, hogy magát a nyomozást kellően bravúrosan végzik ahhoz, hogy ne kelljen a Google-hez rohangálni felhasználói adatokért, az átlagosan hülye bűnöző – vagy annak vélt bűnöző felhasználó – úgyis millió meg egy ponton elcsúszik máshol, ha valamit el akar titkolni, ami viszont tény. Azaz nem is kellenek olyan adatok a bizonyítási eljárásban, amit csak a Google-től közvetlenül lehetne beszerezni. 

A legpesszimistább, már-már a jó hírnév megsértését karcolászó feltételezés pedig az, hogy valóban előfordul Magyarországon is, ami elterjedt szerte a világon, csak államonként eltérő mértékben: azaz hogy a szükséges adatokat a nyomozók nem törvényes úton szerzik be, majd ha megvan, az eljárás későbbi szakaszában, közben találják ki, hogy a gyanusítottal kapcsolatban honnan tudják azt, amit tudnak. Arról már volt szó, hogy a magyar felhasználókat kiszolgáló Google-adatközpontokhoz hozzáférni nem olyan eszelősen bravúros dolog, mint ahogy arról is vannak legendák, hogy milyen mértékű rálátásuk van a hatóságoknak a magyar hálózatokra a netszolgáltatókon keresztül, amiken még ha titkosítva is szaladgál az adat, függetlenül a titkosítás erősségétől, a gyakorlatban sokszor kijátszató

És azt az ortó nagy blamát még nem is emlegettem, amikor kiderült, hogy a legnagyobb levelezőrendszerek, azaz az AOL, Google, Yahoo adatközpontjai közt az USA-ban teljesen titkosítatlan volt a forgalom, persze nem azért, hogy könnyebb dolga legyen az NSA-nek, hanem azért, mert a titkosítás és visszafejtés nagyon komoly számításigénnyel jár, ilyen módon drágább is, ha olyan gigantikus mértékű adatforgalomról van szó, mint amilyet ezek a rendszerek lebonyolítanak. Ne legyenek illúzióink: egyáltalán nem biztos, hogy Európán belül dedikált vonalakon a Google titkosítva tolja az adatforgalmat Magyarországra a maga "kis" 60 gigabit/másodperces peeringjén keresztül, az már egy teljesen más kérdés, hogy a budapesti vagy annak közelében lévő adatközpontok és a felhasználók gépei közt már valóban titkosított a kapcsolat, legyen szó szinte bármelyik Google szolgáltatásról. 

Hogy szemléletes példával éljek: teljesen mindegy, hogy hindi nyelven mond nekem valamit az, aki mellettem ül és nem szeretné, ha rajtam kívül más is megértse abban az esetben, ha magába az épületbe az üzenet egy egyszerű képeslapon érkezett, amit majd hindi nyelven suttognak el, hiszen így csak az nem látja az üzenetet még titkosítatlan formában a képeslapon a postázástól kezdve a recepcióson keresztül a titkárnőkig mindenki, aki nem is akarja. 

Ez a titkosítás nem keverendő azzal a viszonylag friss, ámde annál ködösebb Google bejelentéssel, ami szerint lakattal jelzi a Gmail a webes felületen, hogy az, aki a levelet küldte, titkosítva küldte-e, de azt a bejelentés egyáltalán nem teszi konkréttá, hogy ez mit is jelentene. Ha valaki levelet küld például egy Gmail-es címre, nem a Gmail rendszeréből, olyan módon, hogy a további kézbesítésre szánt levelet az első szerver titkosítva kapja meg, egyáltalán nem biztos, hogy a levél út közben nem halad át olyan csomóponton, amelyik viszont már titkosítatlanul passzolja tovább azt. Az pedig nem világos, hogy a Google a fejléc alapján az összes hosztnévhez tartozó sort megnézi-e, hogy azok egymás közt „hindi nyelven” beszéltek-e vagy éppenséggel csak küldő gépe azzal a szerverrel, amelyiknek a levelet elsőként megkapta további kézbesítésre. Ami biztos, hogy a bejelentést követően nem kevesen joggal írhattak róla, hogy mekkora parasztvakítás ez már megint. 

Az adatigénylésektől indultam, megint a titkosításnál kötöttem ki. A lényeg viszont, hogy az információk továbbításának sérthetetlensége sosem egy vagy kevés számú mechanizmusra támaszkodik: ha azt szeretnénk, hogy ne nagyon legyen látható, hogy merre kóválygunk a neten, kinek milyen rendszeren keresztül küldünk üzenetet, használjunk VPN-t, ha pedig még biztosabbra akarunk menni, használjunk PGP-t, ami tényleg egyik végponttól, azaz felhasználótól a másikig titkosít és így tovább. 

0 Tovább

Hogyan működik a világ legerősebb titkosítási eljárása?


Na jó, a címadással csaltam egy kicsit: egyrészt az egyik legerősebb ma ismert és civil használatra megengedett titkosítási eljárásról fogok írni, másrészt a számításelméleti részletekbe egyáltalán nem megyek bele.

A PGP vagy annak egy klónja, megbízható becslések szerint az egész világon a titkosítást alkalmazó kütyük - legyen szó mainframe szerverről vagy filléres mobilról - közt legtöbb helyen alkalmazott titkosítási eljárás. A PGP valójában két titkosítási eljárás, egy asszimmetrikus és valamelyik szimmetrikus módszer alkalmazásaként működik.

Az asszimmetrikus titkosítás gyakorlatilag minden esetben az RSA módszeren alapul, aminek a működését a következő módon szemléltetném, ráadásul már-már tankönyvi nevekkel: Alice szeretne üzenetet küldeni Bobnak, viszont abban az esetben, ha Alice az üzenetet titkosítja, akkor a titkosításhoz szükséges kulcsot is el kellene juttatnia Bobnak, hogy Bob ugyanazzal a kulccsal az üzenetet vissza tudja fejteni. Abban az esetben, ha a titkosításhoz szükséges kulcsot közben elkapják a titkosított üzenettel együtt, a titkosítás semmit sem ér, hiszen vissza tudja fejteni az is, aki elkapta. Ezzel szemben az asszimmetrikus titkosításnál Alice és Bob egyaránt rendelkezik egy kulcspárral: mindkettőjüknek van egy saját, privát kulcsa, amit csak ő ismer és egy publikus kulcsa, amit bárki ismerhet és ismernie is kell, ha titkosított üzenetet szeretne küldeni neki. Ebben az esetben a történet a következő módon néz ki:
1. Alice és Bob odaadják egymásnak a saját publikus kulcsukat [ezt csak egyszer kell megtenniük]
2. Alice titkosított üzenetet küld Bobnak olyan módon, hogy az üzenet titkosításához a saját privát és Bob publikus kulcsát használja, majd elküldi az üzenetet
3. az üzenet megérkezik Bobhoz, majd az üzenet visszafejtését a saját privát kulcsával, valamint Alice publikus kulcsával végzi el

Azaz egyszer sem haladt át a teljes titkosításhoz szükséges kulcs, mégis tudják olvasni az egymásnak küldött üzeneteket, így az 1970-es években a több ezer éves (!!) ún. kulcsmegosztási problémát oldották meg. Hogyan kombinálódik is az asszimmetrikus és szimmetrikus módszer?

A szimmetrikus kulcsú titkosításnál ugyan csak egy kulcs van, ami a titkosítást és a visszafejtést egyaránt végzi, de ez ideális esetben eléggé erős.

Teljes kommunikáció RSA-val titkosítani egyrészt elképesztően számításigényes lenne, másrészt szükségtelen is, ebből adódott az ötlet, hogy a kettőt össze lehetne lőni, így létrehozva egy olyan titkosítási eljárást, ami kellőképpen erős ahhoz, hogy minden ma ismert törési próbálkozásnak ellenálljon. Ennek az ötletnek az alapján valósította meg Phil Zimmermann a PGP-nek nevezett titkosítási eljárást 1991-ben, ami a következőképp működik:

1. Alice tömöríti az üzenetet, hogy a műveleteket kisebb adathalmazon kelljen végrehajtani
2. Alice egy egyszer használatos, akkor generált kulccsal titkosítja az üzenetet egy szimmetrikus módszerrel
3. Alice magához a szimmetrikus titkosításhoz használt kulcsot - amit beágyaz az üzenetbe - titkosítja Bob nyilvános kulcsával, majd elküldi az üzenetet

Bob az üzenet visszafejtésekor a saját privát kulcsával először az asszimmetrikus titkosításhoz használt kulcsot éri el, majd azzal bontja ki a teljes üzenetet.

nem a teljes PGP ábrája! csak az asszimmetrikus titkosításé

Kultúrtörténeti érdekesség, hogy az internet hőskorában az, hogy egy egyszerű otthoni számítógéppel olyan erős titkosított üzenetet lehetett létrehozni, amit még a nagy-nagy hárombetűs szervezetek sem tudnak visszafejteni szuperszámítógépekkel, akkora riadalmat keltett, hogy 1993-ban az USA-ban eljárást kezdeményeztek Phil Zimmermann ellen, viszont lévén, hogy nem lehet perelni valakit csak azért, mert túl hatékony algoritmust hozott létre, a vád a fegyverek exportját szabályozó törvény megsértése volt. Végül az eljárást 1996-ban megszüntették vádemelés nélkül, addigra pedig a PGP már úgyis elterjedt az egész világon.

Még középiskolás koromban gondolkoztam azon, hogy ha ennyire egyszerű és ennyire hatékony egy titkosítási eljárás, akkor miért nem megy át minden elképzelhető felhasználói adat két fél közt, azaz például ha emailt vagy SMS-t küldünk valakinek, az eszköz csak betöltené a címtárból a feladó nyilvános kulcsát és a címzett már meg is nyitná az üzenetet a saját privát kulcsával. A teljes magyarázat bőségesen meghaladná ennek a posztnak a kereteit, a legfontosabb indokok mogyoróhéjban az emailezés példáján keresztül: pont a 90-es évek elején robbantak be az ingyenesen elérhető email szolgáltatók, amik döntően webes felületen működtek és a felhasználóik tudatosság szempontjából egész egyszerűen nem voltak érdekeltek abban, hogy az üzeneteik titkosítva legyenek, a szolgáltatóknak pedig nem volt érdekük plusz munkát róni a saját szervereikre, ezen kívül a privát kulcsokat is biztonságosan tárolni kellett volna valahol, ha szempont, hogy a felhasználó a leveleit bárhonnan meg tudja nézni, ne csak azon a gépen, amin a saját privát kulcsa van. Megjegyzem: ebben az időben még pendrive-ok és hasonlók kanyarban sem voltak, amin lehetett volna tárolni és használni a privát kulcsot.

Ma pedig az ingyenes levelezőszolgáltatók leggyakoribb üzleti modellje az, hogy a levelezésért nem kell fizetni, viszont egy algoritmus megvizsgálja a levélben előforduló kifejezéseket, majd annak alapján sebészi pontossággal helyez el targetált hirdetéseket a levél szövege melletti oldallécben. Dollármilliárdos piacról van szó. Ha az üzenet titkosított, természetesen a hirdetés targetálása lehetetlen. A Gmailnek például nyilván veszteséges, de nem tiltja, hogy olyan üzenetek továbbítására használják a felhasználók a fiókjukat, amik teljesen elemezhetetlenek az elemzőmotorjaik számára, ez azonban a felhasználóknak csak nagyon kis részét érinti.

Elméletileg megoldható, hogy egy webes levelezőrendszerben PGP-t alkalmazzanak, ez azonban rendkívüli kockázatot rejt magában, hiszen ha valamilyen módon a privát kulcsokat ellopják, az összes felhasználó titkosított levelezése olvasható lesz, ráadásul új kulcsot kellene mindegyiküknek generálnia. Valójában a publikus levelezőrendszerek közt egyetlen normális kivétel van, a Hushmail, ami a privát kulcsok tárolását saját maga oldja meg, ez a kulcs egyébként le is tölthető.

De mit tegyünk, ha saját magunk akarunk olyan titkosított leveleket küldeni és fogadni, amit aztán tényleg nem olvas se ember, se isten, hacsak nem szerezte meg a privát kulcsunkat? Természetesen több konkrét megvalósítás is van, ezek közül az egyik legelterjedtebb kombót mutatom be, ami működik Windowsban, OSX-en és linuxokon is.

Először is a levelezőszolgáltatónknál engedélyezzük az IMAP4/POP3-letöltést - annyira alap szolgáltatás, hogy ha nem lenne lehetséges, időszerű szolgáltatót váltani - majd telepítsünk fel egy levelezőklienst, például a Thunderbirdöt. Ezt követően szükség lesz egy PGP motorra, amiből többféle is létezik, a legelterjedtebb a Gnu Project által feljesztett GnuPG, ami Windowshoz a http://www.gpg4win.org/ címről, OSX-hez pedig a https://gpgtools.org címről tölthető le, a linux-júzerek meg úgyis tudják. Ezek után a Thunderbirdbe telepítsük az Enigmail addont, ami meg fogja hívni a motort, amikor titkosításra van szükség.

Ha mindez megvan, indítsuk el a GnuPG részeként települt PGA-t [GnuPG Agent] vagy a Kleopatra-t, ahol már gyerekjáték új kulcspárt generálni, kezelni. A kulcsunk mérete lehet 1024, 2048, 3072 és 4096 bites is, viszont erősen ajánlott alapértelmezés szerinti 2048 bites kulcsot generálni, mivel más PGP-szoftverek ezzel garantáltan kompatibilisek, ideértve például mobiltelefonok esetén például Android platformon az APG-t, iPhone-nál használt iPGMailt-t is. Fontos, az is, hogy a kulcs több jellemzője is megváltoztatható, a mérete azonban nem!

Ha a kulcspár készen van, aminek a privát részét egy szerkeszthető jelszó is védi, készítsünk róla másolatot, a publikus kulcsot pedig küldjük át annak, akinek szeretnénk GPG-zet levelet küldeni ill. kérjük el az ő publikus kulcsát. Természetesen azért, hogy mindez egyszerűbb legyen, szerte a neten vannak óriási "GPG-telefonkönyvek", ahol ki lehet keresni más GPG-kulcsát az email címe, neve és egyéb adatok alapján, így a publikus kulcsok betölthetők a saját helyi kulcstárunkba illetve mi is feltölthetjük a sajátunkat. Ha egy nagy GPG-adatbázisba feltöltöttük a publikus kulcsunkat, a többibe már nem szükséges, hiszen ezek szinkronban vannak egymással, Magyarországon ilyen például a http://keys.niif.hu/

Amint mindez kész, írjuk meg a titkosítani kívánt levelet, majd küldéskor üssük be a privát kulcsunkhoz tartozó jelszavunkat, az Enigmail pedig a címzett alapján tudni fogja, hogy kinek a publikus kulcsát kell használnia az üzenet titkosításához a kulcstárunkból és a levelet el is küldtük.

Ami még hatalmas előnye a megoldásnak, hogy ha a levelet digitálisan alá is írtuk, az megmásíthatatlanul bizonyítja, hogy a levelet valóban mi írtuk, akkor, azzal a tartalommal, közben nem írt át benne senki semmit és mivel egy GPG-kulcshoz több email cím is hozzárendelhető, ha az email címünk megváltozik, de a leveleinket továbbra is aláirkáljuk, az igazolja a címzett oldalán, hogy tényleg mi vagyunk csak más címmel, nem pedig valaki a nevünkben akar levelet írni.

A posztban nem tértem ki rá, hogy természetesen minden normális levelezőklienshez hozzá lehet adni olyan kiegészítőt, ami lehetővé teszi a PGP-zést, csak éppen van, amelyikben iszonyatosan fapados módon működik. Ahogy nem tértem ki a kulcspár finomhangolási lehetőségeire sem [érvényességi idő, kulcs értvénytelenítésének lehetősége].

Amit viszont nagyon fontos megjegyeznem, hogy a szimmetrikus- és asszimmetrikus titkosítást természetesen nem csak emailek titkosításánál használják, hanem ez a lelke például az SSL/TSL-titkosításnak is, aminek a nyomát nap, mint nap látunk a böngészőben szinte minden, önmagára valamit is adó webszolgáltatásnál, kis lakatként a böngészőben a címsor elején. Ott az egyszer használatos kulcs ismétcsak nálunk van, de a böngésző belügye, hogy azt hogyan kezeli, míg a publikus kulcs a szervernél, ami éppen kiszolgálja a webhelyet. A titkosítás eléggé világos ok miatt sokkal kisebb, mint 2048 bites kulccsal dolgozik. De a technika egyre több internetes telefonálást vagy chatelést biztosító szolgáltatásban is ott figyel, nem mellékesen nem mindegyikben, amelyikre a gyártó azt mondja, hogy igen. A ütősebb, jóval erősebb hardveres titkosítást alkalmazó pendriveok titkosításának az alapja ugyanez.

Néhány kapcsolódó téma, amibe most szintén nem mentem bele: az alkalmazott asszimmetrikus módszertől függően bizonyos kulcsok csak titkosításra használhatók, digitális aláírásra viszont nem valamint az, hogy a titkosítás szigorúan számításelméleti szempontból feltörhetetlen, nem jelenti azt, hogy a gyakorlatban is az: például, ha az egész véletlenül hibásan van leprogramozva vagy az algoritmusnak az a része, ami a kulcspárok generálásához a dög nagy prímszámokat nem teljesen véletlenül választja ki, így a lehetséges privát kulcsokból sokkal kevesebb állítható elő - amiből nemrég orbitális botrány is lett

A GPG-ről egyébként Thunderbird-GunPG-specifikusabban egy behatóbb cikket is írtam néhány napja, amit itt találtok meg

[kollégák figyelmébe: itt ismeretterjesztő cikkről van szó, ennek megfelelően lett megírva, az egyszerűsítések és az érthetőség kedvéért alkalmazott kevésbé precíz megfogalmazás, a PGP és GPG itt-ott szinonimaként való használata az érthetőséget hivatott szolgálni] A magyarázó ábra forrása: Wikipedia. 

1 Tovább