22
BIZTONSÁGI KÉRDÉSEK Ad hoc hálózatok, 2007. Készítette: Tóth Balázs Viktor

Biztonsági kérdések

  • Upload
    milek

  • View
    38

  • Download
    0

Embed Size (px)

DESCRIPTION

Biztonsági kérdések. Ad hoc hálózatok, 2007. Készítette: Tóth Balázs Viktor. Miért is kell a biztonság?. Harci alkalmazások, hőmérséklet és nyomás mérése az olajvezetékekben Harci környezet -> akár fegyver is lehet a nem megfelelő biztonság Kereskedelmi -> privacy protection - PowerPoint PPT Presentation

Citation preview

Page 1: Biztonsági kérdések

BIZTONSÁGI KÉRDÉSEKAd hoc hálózatok, 2007.

Készítette: Tóth Balázs Viktor

Page 2: Biztonsági kérdések

MIÉRT IS KELL A BIZTONSÁG?

Harci alkalmazások, hőmérséklet és nyomás mérése az olajvezetékekben

Harci környezet -> akár fegyver is lehet a nem megfelelő biztonság

Kereskedelmi -> privacy protection WSN esetén -> korlátozott erőforrások ->

tervezés Egyéni rendszer architektúra tervezés

2

Page 3: Biztonsági kérdések

WSN BIZTONSÁGI TULAJDONSÁGOK

Ellenséges környezet: fizikai támadások; mi van, ha a node-t megszerzik…

Limitált erőforrások: limitált mérettel, energiával, számítási kapacitással és tárolással rendelkeznek -> limitált algoritmusok

In-network feldolgozás: a kommunikáció fogyaszt a legtöbbet, nem az érzékelés -> lokalizált feldolgozás

Applikáció-függő architektúrák: a fent említett okok miatt a WSN rendszer architektúrákat alkalmazás specifikusan kell kifejleszteni 3

Page 4: Biztonsági kérdések

REAL-LIFE RENDSZEREK BIZTOSÍTÁSA

Tűzfal: a hozzáférés korlátozását jelenti az alhálózatra és alhálózatról, hátrányuk, hogy nem védik meg a hálózatot a belülről induló támadások ellen és csak ismert támadásokat tudnak kiszűrni.

Honeypot: olyan rendszerek, amelyek abból a célból lettek a hálózatba implementálva, hogy megtámadják őket, ismeretlen támadásokat tudnak detektálni.

Betolakodás detektáló technikák: a statisztikai és pattern szokatlanságokat tudják detektálni a bejövő és kimenő forgalomban.

Ezek a technikák ebben a formában nem alkalmasak WSN-ek esetében, de kicsit megváltoztatva őket tökéletes biztonsági eszközöket kapunk a WSN-ekhez.

4

Page 5: Biztonsági kérdések

MOBILE CODE A nehézségek ellenére az alkalmazásokat és a

rendszer kódot megváltoztató mechanizmusok kötelező jellegűek.

Egy mobile code beinjektálása néhány node-on keresztül történik, majd az szétterjed a hálózaton.

Három fő szemlélet létezik a mobile code biztonságossá tételére:

1. Code-signing: egy tipikus kliens-szerver autentikációs handshake protokollt követ.

2. Sandboxing: Megakadályozza az alkalmazáshoz való illetéktelen személyek hozzáférését és a hostot a rosszindulatú alkalmazásoktól.

3. Proof-carrying code: lehetővé teszi egy számítógép számára, hogy meghatározza elindít-e egy programot, ami egy nem megbízható forrásból érkezett.

5

Page 6: Biztonsági kérdések

MOBILE CODE (FOLYT.)

Négy fő mobile code feltörési technika létezik:

1. Vírus: a számítógépre települve arra használja fel az erőforrásokat, hogy új példányokat készítsen magából.

2. Trójai faló: úgy tüntetik fel magukat, mint egy általános funkciókat ellátó program, de közben rosszindulatú funkciókat látnak el.

3. Buffer túlcsordulást okozó támadások: olyan program funkcióját látják el, amely felett a támadó átveheti az irányítást és tönkre teheti a rendszert.

4. Titkosított kommunikációs csatornákkal manipulálók: az erőforrás megosztással kapcsolatban váltak használhatóvá. 6

Page 7: Biztonsági kérdések

BIZTONSÁGI ARCHITEKTÚRÁK

A biztonsági megfontolások alapján a WSN architektúrának két fajtája létezik:

Cella alapú WSN-ek: low-power és low-cost szenzor node-okból és bázisállomásokból állnak, viszonylag barátságos környezetben működnek, házak és irodák között.

Ad hoc alapú WSN-ek: csak low-cost szenzor node-okból állnak ad hoc módon elosztva barátságtalan környezetben, vezetéknélküli infrastruktúra nélkül.

7

Page 8: Biztonsági kérdések

CELLA ALAPÚ WSN A node-ok egy vagy több base station köré

vannak rendeződve, amelyeknek jóval nagyobb a számítási és erőforrás kapacitásuk, mint a node-oknak.

Aszimmetrikus biztonsági protokollok. SPINS: SNEP (sensor network encryption protocol)

és uTESLA A SPINS protokoll azon feltevésen alapul, hogy a

base station-k megosztanak egy egyedi master keyt minden node-dal a hálózatban, az összes többi kulcs a master keyből van számolva.

A SNEP biztosítja a unicast kommunikáció biztonságát a base station és a node között

A uTESLA a biztonságos broadcast üzenetek biztonságára ügyel.

8

Page 9: Biztonsági kérdések

SNEP

A SNEP RC5 blokk rejtjelezőt használ. Ugyanazon üzenet kódolása minden

alkalommal más kódszót eredményez, amelyet egy számláló inkrementálásával érnek el.

Minden node-nak megvan a master kulcs, így a SNEP tudja garantálni a base station-től érkező üzenetek autentikálását.

9

Page 10: Biztonsági kérdések

µTESLA

A base station-k egy reverse kulcsfolyamot generálnak: K0, K1, …, Kn.

Kn és n kiderül még a generálás előtt. A többi kulcsot egyirányú függvény

segítségével (F) generáljuk, Ki = F(Ki+1).

A K0-t a kulcsfolyam elfogadására használjuk: a K0 megköveteli, hogy minden node és a base station ossza meg a titkos kulcsát a küldő node-al.

Ezek után a base station szétküldi K0-t minden node-nak mint egy unicast üzenetet. 10

Page 11: Biztonsági kérdések

µTESLA (2.)

Az idő intervallumok: I1, …, In, ahol minden Ii intervallumhoz egy Ki kulcs tartozik.

Az F egy egyirányú függvény, így senki nem tudja kiszámolni K1-t K0-ból.

Az I1 intervallum végén a kulcs kiderülésekor mindenki összehasonlítja a K1-t az F(K1)-el. Ha ezek megegyeznek, akkor a base station küldheti az adatot.

Miután K1 kiderült, a következő üzenet autentikálva van – ami K2-t használ

K1 disclosed Ki disclosedKi-1 disclosed Ki+1 disclosed Kn disclosed

I1 Ii-1 Ii Ii+1 In

K0 disclosed in advance

MACK1(…) MACKi-1(…) MACKi(…) MACKi+1(…)MACKn(…)

11

Page 12: Biztonsági kérdések

AD HOC SZENZOR HÁLÓZAT A node-oknak fel kell állítaniuk a hálózatot

mindenféle base station segítség nélkül. Minden node lehet forrás és cél is. A node-k veszélynek vannak kitéve. Szimmetrikus titkosítás; a főbb meggondolások a

kulcsok elosztására:1. Ne lehessen egy vagy több node feltörésével

megfejteni a forgalmat.2. Lehessen újonnan csatlakozó node-okat bevonni

a hálózatba.3. Ne legyen „single point of failure”.4. Térbeli és időleges kulcs variációk, hogy a feltörés

nehezebb legyen.5. Broadcast támogatása.

12

Page 13: Biztonsági kérdések

KULCS ELOSZTÁSI SÉMÁK

Nyilvános kulcsú titkosítás „drága”. Online kulcskiosztó szerverek -> single point of

failure, továbbá megszerezhetik az összes kulcsot

Offline kulcskiosztás A rendszer beüzemelése előtt egy „pool” kulcs

generálva lesz, P. Minden node k db kulcsot választ a poolból. Ezek után kihírdetik és közös kulcsot keresnek. Ha létezik ilyen->kommunikálhatnak

egymással. Connectivity Graph

13

Page 14: Biztonsági kérdések

KULCS ELOSZTÁSI SÉMÁK(2.)

Ha egy node-t megszereznek, k kulcs elérhető a támadó számára.

Annak a valószínűsége, hogy egy bizonyos kulcsot kódolásra használtak ugyanaz minden kulcsra, így annak a valószínűsége, hogy egy támadó dekódolni tudja a forgalmat k/P.

Memória megtakarítás! Ha P csökken, annak a valószínűsége, hogy

több közös kulcs lesz nő – k/P is nő.

14

Page 15: Biztonsági kérdések

KULCS ELOSZTÁSI SÉMÁK(3.)

P kiszámítása:1. p annak a valószínűsége, hogy két gyűrű

megegyezik egy-két helyen.2. 10000 node3. d=40 (node szomszédság általában)4. k=15 (key ring hossza)5. P=1000006. A hálózat fully connected 0.9999 eséllyel. Egy javítás: ne egy kulcsot keljen

megosztaniuk egy link létrehozására, hanem q-t. 15

Page 16: Biztonsági kérdések

PRIVACY PROTECTION

Kereskedelmi célra szánt WSN -> PP is ugyanolyan fontos.

A privacy protection a legkevesebb adatra való szert tevést helyezi előbbre.

Teljesítmény <-> PP. A minimális generálás: a pontos információk

a felhasználókról általánosítva legyenek, annyira, hogy a megszerzett adatokat ne lehessen k-nál több emberhez kötni. A k a megkövetelt anonimitás erőssége.

16

Page 17: Biztonsági kérdések

HELY INFORMÁCIÓK TITKOSSÁGA

A leggyakrabban használt feladat WSN rendszerek esetén egy esemény helyének meghatározása.

Egy támadó a hely információkhoz hozzáférve következtethet plusz információkra – pl. szokások.

Minimális generálás -> kisebb pontosság.

17

Page 18: Biztonsági kérdések

HELY INFORMÁCIÓK TITKOSSÁGA(2.)

Általános rendszer architektúra:

Location Server Location Based Services

(pseudonym, location, request)

(location) (response)

(pseudonym, response)

WASN

18

Page 19: Biztonsági kérdések

HELY INFORMÁCIÓK TITKOSSÁGA(3.)

A location server felelőssége, hogy a felhasználók által megfigyelt helyeket átalakítsa egy olyan reprezentációvá, amely egy bizonyos biztonsági szint fölött van.

LBS: hely alapú szolgáltatást nyújtó server. Válasszuk szét a hely információt a

felhasználó identitásától. Álnév A privacy mérőszáma ebben a kontextusban

a k-anonimitás.

19

Page 20: Biztonsági kérdések

HELY INFORMÁCIÓK TITKOSSÁGA(4.)

A k-anonimitás egy k számosságú környezetben való anonimitás.

Egy usert nem lehet megkülönböztetni k-1 másiktól.

Azon alkalmazások számára, amelyek hely információt használnak, a k-anonimitás azt jelenti, hogy egy user csatolt hely információja tartalmazza a k-1 többi user információit is.

Mix zones: speciális k-anonimitás, ahol a userek megváltoztatják az ideiglenes anonim ID-jukat.

Az azonosítókkal való manipulálás a location serverre tartozik.

20

Page 21: Biztonsági kérdések

KONKLÚZIÓ

Biztonság és PP. Limitált erőforrások, fizikai hozzáférhetőség –

> a újfajta biztonsági mechanizmus kell. A fizikai hozzáférhetőség azt követeli meg,

hogy ha a node-k kriptográfiai titkai kiderülnek, akkor a protokollok védjék meg az integritást még ebben az esetben is.

PP: személyes adatok ne kerüljenek nyilvánsságra.

Adatok lebutítása -> az adat és az egyén nem köthető könnyen össze.

21

Page 22: Biztonsági kérdések

ITT A VÉGE…

Köszönöm a figyelmet!

22