Biztonsági kérdések

1. Biztonsági kérdések Távközlési és Médiainformatikai Tanszék simon@tmit.bme.hu

2. Biztonsági alapok simon@tmit.bme.hu

3. Alapvető fogalmak • Integrity (integritás) Fogadott adat = küldött adat • Availability (elérhetőség) Jogos felhasználók valóban hozzáférnek a tartalomhoz • Authentication (azonosítás) A küldő/fogadó fél ID ellenőrzése • Confidentiality (titkosság) Kizárólag jogos felhasználók feérnek hozzá a tartalomhoz • User management, access control (felhasználók ellenőrzése) Az adattulajdonos határozza meg a felhasználók jogosultságait • Non-repudiation (megtagadás tiltása) Küldő nem fedheti el ID-jét simon@tmit.bme.hu

4. Támadások • Interruption (komm. leállítása) • Interception (adatlopás) • Masquerade (ID lopás) • Alteration (adat módosítása) • Man in the middle – adatlopás • Denial of Service – zavarás • Aktív/Passzívtámadások simon@tmit.bme.hu

5. Kriptográfia - Algoritmusok • Matematikai módszerekkel algoritmusok kidolgozása – nehéz számítási feladatok • Az algoritmus nem elég a megoldáshoz • Meg kell valósítani • Különböző célokhoz különböző algoritmusok • Törvényi előírások, jogvédelem simon@tmit.bme.hu

6. Algoritmusok (2) • Nyilvános kulcs az üzenet kódolására • Átalakítás egy nehéz számítási feladatra • Nyilvános (nem biztonságos) csatornán elküldeni • Az adat kinyeréséhez meg kell oldani a számítási feladatot • Ha a titkos kulcs ismert • A kódolt adatot transzformálni lehet egy egyszerűbb feladtra, és csak azt kell megoldani simon@tmit.bme.hu

7. Mechanizmusok • Encryption (kódolás) – biztonságos adatkódolás (confidentiality, authentication, integrity) • Digital Signatures (digitális aláírás) – egyedi azonosító elrejtése az adatban (authentication, integrity, non-repudiation) • Hashing – a teljes adat egy rövid lenyomata (fingerprint), az adatból újra lehet generálni = egy támadó nem módosította az adatot (integrity, authentication) simon@tmit.bme.hu

8. Service Mechanism Algorithm Biztonsági szolgáltatások • Szolgáltatás = protokollok, megoldások • Mechanizmus, algoritmus segítségével valósul meg • Egy jó algoritmust haszontalanná tehet egy rossz szolgátltatás • Megvalósíthatóság – néha sokkal fontosabb a biztonságnál  • Senki sem védhet meg magad ellen !!! (pl. pwd elvesztése) simon@tmit.bme.hu

9. Jelölések • Kulcs nélküli kózdolás M=ABC C=E(M)=#$!@ D(E(M))=M • E – encryption/encode, D – decryption/decode • C = Cyphertext = encrypted text (kódolt üzenet), M = message (üzenet) • one-way function f() • C=f(M), M=f(C) –1 f invertálása egynagyon nehéz feladat • a titok-tulajdonosa E=f and D=f-1 használja,nem E-t invertálja simon@tmit.bme.hu

10. Kulcsok • f={E/D,K}, E/D – public functions, K - key • Secret key: • E(K,M), D(K,C), K must be kept in secret • instead of transferring the data over a secure channel, it has to be transmitted only the short (2048bits) K key • Public key: • E(K1,M), D(K2,C), K1 is public, K2 is secret • public key K1 advertised to everybody • K2 is known only by the issuer of K1, it decrypts only the text encrypted with K2 simon@tmit.bme.hu

11. Szimmetrikuskulcsok Confidentiality C = E( K, M) M = D( K, C) • Egy titkos kulcs mindkét fél részére = K • gondok: • Skálázhatóság: nfelhasználónak n(n-1)/2kulcs kell • HA K sérül, minden M elveszik • K terjesztése nehézkes B A simon@tmit.bme.hu

12. Nyilvános kulcsok Confidentiality C = E( B’s PUBLIC key, M) M = D( B’s SECRET key, C) • A titkos kulcsot csak a tulajdonos ismeri • A nyilvános kulcsot meg lehet hirdetni (nyilvános :) B A Digital Signature C = E( A’s SECRET key, M) M = D( A’s PUBLIC key, C) A B simon@tmit.bme.hu

13. Kulcscsere • Szimmetrikus kriptográfiával • Résztvevők: Alice, Bob, Trent simon@tmit.bme.hu

14. Kulcscsere 2. • Nyilvános kulcsok segítségével • Résztvevők: Alice, Bob simon@tmit.bme.hu

15. Kulcscsere 3. • Digitális aláírással (nyilvános kulcs) • Résztvevők: Alice, Bob, Trent simon@tmit.bme.hu

16. MANET-ekbiztonsága simon@tmit.bme.hu

17. MANET környezet • Intrusion Detection – ki a csaló? • Hamis info terjesztése • Véletlen • dinamikus környezet, interferencia, lemerült akku • Szándékos • Ritka (véletlenszerű) és állandó aktív, passzív • Secure Routing • Útvonalválasztás lehetetlenné tétele • DoS • hamis, nem létező hálózat-részek => skálázhatóság simon@tmit.bme.hu

18. Route request flooding Nem létező állomások keresése DoS - a RREQ elárasztja a hálózatot False distance vector Mindig “one hop to dest” válaszolni a fogadott RREQ-ra Egyúttal nagyon nagy SeqNr beállítani False destination sequence number Nagy SeqNr-al válaszolni A valós célállomásénál is nagyobb Wormhole Alagutazni a RREQ-t Minden adat az alagúton fog átmenni Koordinált támadás „Váltott lovas” támadások Igazolják egymás hamis ID-jét AODV lehetséges támadásai simon@tmit.bme.hu

19. AODV támadása simon@tmit.bme.hu

20. RREQ(D, 3) RREP(D, 5) RREQ(D, 3) RREQ(D, 3) RREQ(D, 3) RREP(D, 20) Példa a hamis DestSeqNr támadásra • S-től D-be indul a RREQ • ellenben M felé épül ki az útvonal • Minden adatcsomag elvesz S3 D S S1 S2 M simon@tmit.bme.hu

21. Hamis SeqNr támadás felderítése • Megszakad a link M felé • Új RREQ, S által használt SeqNr = régi + 1 = 21 • D által ismert SeqNr = 5, a várt SeqNr = 6 • A fogadott RREQ-ben a SeqNr > 6, tehát valaki más állította be a rá vonatkozó SeqNr-t D S3 RREQ(D, 21) S S1 S2 M S4 RREQ terjedése simon@tmit.bme.hu

22. Reverse Labeling Restriction (RLR) • Blacklist (Feketelisták) frissítése egy támadás felderítése esetén • Minden állomás fenntart egy feketelistát a gyanús szomszédairól: BL{} • A célállomás egy INVALID csomagot broadcastol • Tartalmazza az aláírását, saját feketlistáját • Jelenlegi SeqNr, támadó által haszmált SeqNr • Minden állomás összehasonlítja a saját D-re vonatkozó routing bejegyzésével • Ha az nagyobb mint a „Jelenlegi SeqNr” a D INVALID üzenetéből => ő is a támadás áldozata • A szomszédját, akitől a RREP-t kapta beállítja a feketlistájába (Reverse Label) simon@tmit.bme.hu

23. BL {S2} BL {} BL {S1} BL {} BL {M} BL {} Reverse Labeling Restriction példa S3 D INVALID ( D, 5, 21, {}, SIGN ) • A helyes SeqNr-t terjesztik • Minden egyes állomás frissíti saját feketelistáját (BL) S S1 M S2 S4 simon@tmit.bme.hu

24. Többszörös támadások • M-hez közelebbi állomások BL-jében mind szerepelni fog M • M négy állomást támad meg, négy BL-ben szerepel D1 D2 [M] S3 S4 [M] M D4 D3 [M] [M] S2 S1 simon@tmit.bme.hu

25. Lokális döntések és globális info • Amikor egy állomás rájön, hogy támadás áldozata lett, frissíti a BL-t és terjeszti saját, új BL-jét • Tehát adott állomás BL-t a többiek is megismerik • Ha M állomás több BL-be belekerül, • Egy küszöbérték felett • M „malicious host” = rosszindulatú állomásként lesz nyilvánítva simon@tmit.bme.hu

26. Kölcsönös ellenőrzés simon@tmit.bme.hu

27. MANET környezet Osztott közeg estén – WLAN Minden szomszéd hallja adott állomás forgalmát simon@tmit.bme.hu

28. Kölcsönös ellenőrzés simon@tmit.bme.hu

29. Byzantine Generals simon@tmit.bme.hu

30. Byzantine Generals probléma 1 i n • n tábornok van, egységes döntést kell hozni • Minden tábornok (general) áruló lehet • Akár az összes tábornok áruló • Ha az i. tábornok áruló • mást-mást állít a társainak • Minden állomás minden másikat el kell érnie, hogy észrevegyék a hamis állítást simon@tmit.bme.hu

31. Byznantine Agreement • Cél: Bizonytalan közegben egységes döntést hozni • Minden hűséges generálisnak • ugyanaz lesz az információja arról, amit a többi generális állított • a többi hűséges generálisnak meglesz ugyanaz az igaz információja az állításáról • Minden generális biztos lehet, hogy a többieknek ugyanaz az információja, mint a sajátja simon@tmit.bme.hu

32. Byzantine Agreement 2. • Voting-system – milyen szavazás esetében fogadjuk el a döntést • Egy bizonytalan közegben a többségi elv alapján hozzuk meg döntéseinket • n/2 + 1 állomás ugyanazt a döntést kell hozza • A „Byzantine Generals” probléma megoldása • Legalább 2/3n + 1 hű tábornok van simon@tmit.bme.hu

33. Byzantine Agreements • L. Lamport, R. Shostak, M. Pease, The Byzantine Generals Problem, ACM Transactions on Programming Languages and Systems, 1982 http://portal.acm.org/citation.cfm?id=357176 • Egy jó áttekintés: http://www.disappearing-inc.com/B/byzantineagreement.html simon@tmit.bme.hu

34. Felmerülő kérdés: felosztani a MANET-et Cél: minimálisra csökkenteni a biztonsági információ elárasztását simon@tmit.bme.hu

35. Megbízhatósági szint simon@tmit.bme.hu

36. P2P hálózatok biztonsága simon@tmit.bme.hu

37. Jellemző problémák • User-space • Fájlcserélés esetén • Back-door a rendszerbe • Trojan letöltése • DOS • Azonosítási kérdések • Fair-share (fair-trade) • Működőképesség biztosítása • Hiénák kiszűrése simon@tmit.bme.hu

38. Felhasználó barát p2p • Leginkább elterjedt alkalmazás • Fájlcserélés • Sysadmin helyett a felhasználó konfigurál • „out-of-the-box” módszer • Kicsomagolás után azonnal használható • Működését meghatározó protokollok titkosak • VESZÉLYEK • Tapasztalatlan felhasználók • Rosszindulatú felhasználók simon@tmit.bme.hu

39. Sybil támadások simon@tmit.bme.hu

40. Feltételek • Biztonságos p2p rendszer létrehozásának alap feltételei • Biztonságosan hozzárendelni a peerID-t az állomásokhoz • Biztonságosan fenntartani a routing táblákat • Biztonságosan továbbítani az üzeneteket simon@tmit.bme.hu

41. Azonosítás megtagadása • Felelősség • Következmények vállalása • p2p ID tér = felhasználó által alakítható • Sysadmin ismert (DNS, IP címek kiosztás) • Felhasználó nincs regisztrálva • „Lebukás” kockázata nélkül • Másolni v. keresni (lopni), DoS simon@tmit.bme.hu

42. Azonosítás megkövetelése • p2p platform „native” támogatása • Bármilyen kommunikáció előtt • azonosítás • Saját ID-t is regisztrálni kell a választott Certification Authority-nál simon@tmit.bme.hu

43. Sybil támadások • Azonosítás esetén is felmerülhet • DoS típusú támadás • Ingyenes azonosítás esetén • Nagyszámú peerID-t lehet igényelni • Ezzel sok kérést lehet indítani • 0 < f < 1 – támadók aránya a hálózatban • f-et növeli, és klasszikus körülmények között aránytalanul nagy kárt okoz • a támadó gép felhasználásával • f >> a támadó egység simon@tmit.bme.hu

44. Sybil támadás kivédése • peerID-t csak a node-ok rendszerbe lépésekor osztanak • peerID kiadása csak egy korlátozott rátával történik • peerID kibocsátása fizetőssé válik • J. R. Douceur, The Sybil Attack, International Workshop on Peer-to-Peer Systems, 2002 http://www.cs.rice.edu/Conferences/IPTPS02/101.pdf simon@tmit.bme.hu

45. Secure routing – lokalizált routing simon@tmit.bme.hu

46. Faulty Routing • N peer a rendszerben • 0 < f < 1, f – támadó peerek aránya • f N – támadó peerek száma • c > 1 koalíció alakul a támadó peerek között • Koalíció = támadást közösen elkövetők • A koalíciók függetlenek simon@tmit.bme.hu

47. Secure Routing P2P rendszerekben • Egy tisztességes állomás által küldött üzenet sikeresen eléri a tisztességes „replica root”-okat • Replica root-ok biztosítják az adott kulcs által indexált tartalom elérhetőségét • Legalább egy másolata az üzenetnek, amit egy adott kulcsnak szántak, nagy valószínűséggel eléri a helyes „replica root”-okat simon@tmit.bme.hu

48. Secure Routing céljai • Az üzenet eléri célját • Annak ellenére, hogy csaló állomások meg akarják ezt akadályozni • Korrumpálni (megváltoztatni, hiteltelenné tenni) • Eldobni • Rossz irányba routolni • Adott kulcsnak megfelelő és tisztességes „replica root”-okhoz juttatja el az üzeneteket • Annak ellenére, hogy csaló állomások replica rootnak adhatják ki maguknak • (Replica root-ok biztosítják az adott kulcs által indexált tartalom elérhetőségét) simon@tmit.bme.hu

49. Biztonságos routing tábla fenntartás • A tisztességes állomások routing táblájában hivatkozott csaló állomások száma nem haladja meg f-et • 0 < f < 1, f – csaló peerek aránya simon@tmit.bme.hu

50. Lokalizált routing veszélye • h ugrásból álló útvonal • (1-f)hvalószínűséggel lehet csalni • Nem éri meg • DE amennyiben a támadó által igényelt peerID lokálisan közel van a célhoz • Növekszenek az esélyek simon@tmit.bme.hu