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

Lerajzoltam: Titkosítás vs. Felhő vs. NSA

2013.10.30. 21:53 | buherator | 7 komment

HC olvasóimtól előre is elnézést kérek, de szükségét láttam egy újságíró-kompatibilis poszt összedobásának, mielőtt a legújabb Snowden-folyást szétkenik a magyar sajtóban. 

Mint kiderült, az NSA már egy ideje rácuppant minimum a Google és a Yahoo! adatközpontjait összekötő, sokszor titkosítatlan optikákra [az MTI hírrel ellentétben nem a két cég közötti kommunikáció, hanem a cégek saját infrastrukturáin belül zajló kommunikáció figyelése a cél, ahogy az a kiszivárgott skiccről is leolvasható], és onnan a titkosítástól háborítatlanul szipkáznak ki minden adatot. Ez érthető okokból az érintett cégeknek nagyon nem tetszik - sokak szerint a helyzet analóg az Aurora Projekttel, csak az Új Világból nem olyan egyszerű kivonulni - de mi a helyzet a végfelhasználók szemszögéből?

Végtelenül leegyszerűsítve a dolgokat, így néz ki egy "felhős" szolgáltatás minden fajta védelem nélkül:

nsa_nocrypto.pngA Nagy Testvér megnézheti az adataimat az én gépemen, lehallgathatja út közben, vagy oda mehet a felhő szolgáltatóhoz, és elkérheti tőle.

Ha okosan TLS-re váltunk, a kommunikációnkat megvédhetjük, de az adaink felhőben történő kezeléséről továbbra sem rendelkezünk:

nsa_netcrypto.pngEzt a képet úgy tudjuk zöldíteni, hogy még mi magunk titkosítjuk az adatainkat, mielőtt kilőjük őket Bárhová. Ilyenkor még egy nagyon együttműködő szolgáltató sem tud sokat segíteni a Tesónak, mivel a nyílt adat soha nem érintette az ő hálózatát:

nsa_endpointcrypto.pngÉs kb. ennyi: mivel a nyílt adatokat valahol létre kell hozni, a saját területünk megfigyelésével (bepoloskázásával) a Nagy Testvér még mindig beleláthat a mocskos kis ügyeinkbe.

Hogy mi változott a mostani leak fényében? Az ég világon semmi: a felhőt definició szerint (kis túlzással) azért hívjuk így, mert nem tudjuk, és nem is érdekel minket, mi történik benne az adatokkal - ez a probléma és a  rá adott megoldások évek óta változatlanok.

Címkék: nsa snowden

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.

|Z| 2013.10.31. 09:33:27

Javaslom, hogy mától kezdve ITSEC kontextusban hanyagoljuk a felhő kifejezést. Helyette a köd használata a kötelező.

b. á. 2013.10.31. 11:50:26

Végre valaki leírta normálisan! Egyébként ha a két szolgáltató közt volt a nagyüzemi sniffelés, - feltételezve, hogy valamilyen TSL-megvalósítást használnak - egyszerűen elképzelhetetlen, hogy a két fél ne tudjon róla, hogy valaki közbe ékelődik. //Ha rosszul tudom, javítsatok ki. Észrevettem, hogy hirtelen megugrott az érdeklődés az alternatívák felé, pl. Mykolab és társai, mert az egység sugarú felhasználó egyszerűen nem érti, hogy maga a vas és az ország, ahova ki van helyezve, nem lehet elég biztonságos, ha még a Google-Yahoo-AOL-hármas is csapolható. Egyetlen megoldásnak a végponti titkosítás tűnik. Most pedig gurítsunk rá, hogy a hivatásos őrjöngő jogvédők, újságírók közül mennyien használnak PGP-t/Susnyamélt.

nevergone 2013.10.31. 17:33:58

És mivel titkosítsunk, amiben megbízhatunk? GPG? TrueCrypt? Valami AES-re alapulú megoldás megfelelően nagy kulccsal?

buherator · http://buhera.blog.hu 2013.10.31. 18:52:58

@|Z|: lájk

@b. á.: A lényeg éppen az, hogy a szolgálatnak legtöbbször nem kell foglalkoznia a kriptóval, mert van egyszerűbb út (jelen esetben a bérelt optikán nincs kriptó)

@nevergone: A legtöbb korszerű szoftver (TrueCrypt, PGP, GPG, stb.) belsejében AES van szimmetrikus kriptóra, ez nagy valószínűséggel jó is.

Aron bacsi 2013.10.31. 21:44:44

@nevergone: "Still, I trust the mathematics!" Nem a matekkal van baj, hanem az implementációval, illetve az általa használt környezeti elemekkel. Azaz, sajna, az AES is lehet vacak pl. rossz PRNG-vel... A TrueCrypt mondjuk pont több forrást használ a leírása szerint randomként egy kulcsgenerálásnál, de egy csomó Windows-os szoftverben elintézik az egészet egy MS CryptoAPI hívással, ami aztán szerencsétlen esetben egy Dual_EC_DRBG-t hív meg... Az NSA-ügynökök meg örvendeznek vala Bluffdale-ben! ;-)

Hunter Thompson 2013.10.31. 23:21:42

Ha sima háttértárként használod a felhőt, akkor még működhet az ötleted, de a felhőzés ötlete éppen az lenne - "szolgáltatást bérelsz, nem szoftvert veszel" - , hogy az adataiddal bűvészkedő applikációs szerver (SAP, Exchange, stb...) is a felhőben van. Innentől kezdve nyilván bukó a dolog, ha feldolgozás előtt a felhőben kell decryptelni az adataidat...

buherator · http://buhera.blog.hu 2013.11.03. 14:47:46

@Hunter Thompson: Én nem ötletekről beszélek, hanem elvekről. Természetesen ha a távoli szolgáltatás nyílt adatokon él, akkor nem sokat lehet tenni, de egyrészt máshogy is lehet(ne) szolgáltatásokat építeni (pl. Mega, Tresorit), másrészt néhány esetben a meglévő szolgáltatásokra is lehet olyan kliens-oldali kiegészítéseket gyártani, amik megoldják a titkosítást (GMail-re láttam ilyet pl.).