Security in Computer Networks

2014-05-27

Bezpieczeństwo i ochrona

danych

Zastosowania kryptografii

Grzegorz Kołaczek, Ph.D., Eng.

Plan wykładu

• Zagrożenia bezpieczeństwa w sieci

Internet

• Protokoły bezpiecznej komunikacji
• Poufność, prywatność, anonimowość
• Test końcowy

Stos protokołów

Ataki w sieci LAN

• Cele:

– Odtworzenie wiadomości
– Podszywanie się
– Manipulacja mechanizmami dostarczania

wiadomości

• Metody:

– Sniffing (podsłuchiwanie)
– IP Spoofing
– ataki ARP

IP Spoofing

• Podszycie się pod inną stację wysyłając

datagram ze zmienionym adresem IP

– adresy IP nie są uwierzytelniane
– wykorzystywane w celu przejęcia krytycznych

dla bezpieczeństwa informacji

– uwierzytelnianie poprzez adres

• RPC, DNS

IP Spoofing

2014-05-27

IP Spoofing

• Jak można przeprowadzić taki atak?

– utworzyć gniazdo surowe (RAW socket)

• socket(AF_INET, SOCK_RAW, IPPROTO_RAW)

– Spreparuj pakiet

• z fałszywym adresem IP
• Zawierający wszystkie nagłówki z prawidłowymi wartościami

parametrów

• zawierający dane
• Zawierający sumy kontrolne
• Wysyłamy pakiet korzystając z gniazda surowego

Zatruwanie ARP (ARP Poisoning)

• ARP nie dostarcza mechanizmów uwierzytelniania
• Sytuacja wyścigu

– Dostarczenie fałszywego powiązania adres IP /adres fizyczny

• Fałszowanie pytań ARP

– W celu zapełnienia pamięci ARP błędnymi powiązaniami

• Obie sytuacje powodują przekierowanie ruchu do

atakującego

– Konieczność podtrzymywania błędnego zapisu w pamięci ARP

Zatruwanie ARP (ARP Poisoning)

2014-05-27

Bezpieczeństwo protokołów

• Inne ataki/zagrożenia?

– ICMP Smurf
– UDP/TCP Hijacking
– UDP Storm
– DNS Cache Poisoning
– NTP Amplification
– …

Protokół IPSEC

Protokoły bezpiecznej komunikacji

Cele IPsec.

– Zapewnienie integralności oraz poufności

danych przesyłanych przy pomocy IP,
niezależnie od protokołów stosowanych w
wyższych warstwach modelu ISO/OSI

– Zagwarantowanie autentyczności łączących się

stron

– Przezroczystość IPsec dla protokołów wyższych

warstw

Bezpieczna Komunikacja

Architektura IPSec.
Elementy składowe IPSec:

– IP SA – IP Security Association,
– IP SAD – IP

Security Association Database

– IP SPD – IP Security Policy Database
– IP AH – IP Authentication Header,
– IP ESP – IP Encapsulation Security Payload,
– ISAKMP – Internet Security Associations and

Key Management

Bezpieczna Komunikacja

Architektura IPSec.
IP Security Association

– SA jest podstawą całego IPSec.
– Jest to logiczny, jednokierunkowy kanał

komunikacyjny, stworzony dla celów
bezpieczeństwa.

Bezpieczna Komunikacja

Architektura IPSec.
Ad SPD

– SPD jest przełożeniem administracyjnie narzuconej polityki

bezpieczeństwa danego systemu na implementację IPSec i ma
wobec niej rolę nadrzędną.

– SPD pozwala na gradację wymogów, a więc zamiast ,,musi''

można zastąpić przez ,,może'' (w domyśle: ,,jeśli uda się
stworzyć odpowiedni kanał'').

– Można określić kierunek, w odniesieniu do ruchu przychodzącego

i wychodzącego.

– Można sprecyzować wymogi według adresów stacji, sieci,

numerów portów i rodzajów protokołów.

2014-05-27

SPD

IPSec policies

SAD

SPD = Security Policy Database
SAD = Security Association Database
SA = Security Association

Packet

IPSec - ruch wychodzący

Drop.

Bypass IPSec.

Apply IPSec.

out

SPD

IPSec policies

Packet

IPSec - ruch przychodzący

Przypadek 1:
Istnieje nagłówek IPSec
1.

Analiza nagłówka.

SPD

– sprawdzenie czy pakiet może

zostać zostać zaakceptowany na
podstawie odpowiedniego Sa

SPD

IPSec policies

Packet

IPSec – ruch przychodzący

Przypadek 2:
Nagłówek IPSec nie istnieje
1.

SPD

– sprawdzenie jaki typ

usługi ma obsłużyć pakiet

Jeżeli ruch powinien być zabezpieczony,
a nie jest, to pakiet musi
zostać odrzucony

Bezpieczna Komunikacja

Architektura IPSec.
IP Authentication Header

– Ochroną obejmowane są te pola nagłówka, które nie

ulegają zmianie podczas wędrówki przez sieć (adresy,
identyfikator).

– Do zapewnienia integralności oraz, w pewnym stopniu

wiarygodności stron połączenia wykorzystywane są
kryptograficzne funkcje skrótu takie jak MD-5, SHA-1
czy RIPEMD-160 w tzw. trybie HMAC.

Bezpieczna Komunikacja

Architektura IPSec.
• IP Encapsulation Security Payload,

– Protokół ESP (Encapsulation Security Payload), zapewnia

szyfrowanie i ochronę integralności danych.

– Ta ostatnia jednak obejmuje wyłącznie dane wyższej warstwy,

bez nagłówka IP.

– Szyfrowanie oraz uwierzytelnienie są opcjonalne
– Algorytmy funkcji skrótu są dokładnie takie same jak w AH
– poufność zapewniają szyfry blokowe w trybie CBC, takie jak DES,

3DES, Blowfish, CAST-128 i - od niedawna - Rijndael/AES.

Bezpieczna Komunikacja

Tryby stosowania.

2014-05-27

Protokół SSL/TLS

Po co nam SSL/TLS?

• Dwie strony klient i serwer

nie znają się

– np. nie ustaliły wspólnego sekretu w bezpieczny sposób

• Muszą się

uwierzytelnić

wzajemnie

– np.,

“czy kontaktuję się z prawdziwym serwerem

www.edukacja.pwr.edu.pl?”

• Potrzebujemy również zapewnić

poufność

integralność

komunikacji w obu kierunkach

Budowa SSL

Obsługa komunikacji z klientem

Protocols

Ustalenie parametrów

bezpiecznej sesji

pomiędzy klientem i serwerem

Inicjuje bezpieczną

komunikację

Obsługa kompresji

i szyfrowania danych

Obsługa błędów

SSL Record Protocol

Warstwą odpowiadająca za realizację

zadań związanych z bezpieczeństwem

oraz integralnością danych jest SSL

Record Protocol .

Działalnie tego protokołu składa się

następujących kroków:

1. Pobranie danych ( np. dane aplikacji )

które mają zostać przesłane.

2. Podział danych.
3. Kompresja danych przy użyciu

uzgodnionego wcześniej algorytmu.

4. Szyfrowanie dokumentu oraz wyliczenie

wartości MAC ( ustalenie krótkiej i

łatwej do weryfikacji sygnatury ).

5. Przesłanie tak zbudowanego pakietu.

SSL Handshake Protocol

Oferta CIPHER SUITE
MENU dla serwera

Wybór CIPHER SUITE

Wysyła certyfikat i ścieżkę
do CA korzenia

CLIENT SIDE

SERVER SIDE

Wysyła klucz publiczny
do szyfrowania klucza sym.

Koniec negocjacji serwera

Wysyła zaszyfrowany klucz
symetryczny

Aktywacja szyfrowania

Koniec negocjacji

Weryfikacja opcji

Aktywacja szyfrowania
przez serwer

Koniec negocjacji

Klient sprawdza opcje

Negocjacja parametrów sesji SSL

Narzut SSL

• 2-10 wolniejsze niż sesjaTCP
• Dlaczego?

– Faza Handshake

• Klient korzysta z szyfrowania kluczem publicznym
• Serwer korzysta również z kryptografii

asymetrycznej (klucz prywatny)

• Klient musi oczekiwać na odpowiedź serwera

– Faza transferu danych

• Kryptografia symetryczna

2014-05-27

• Prywatność:

możliwość zagwarantowania ochrony danych
osobistych przed ujawnieniem

• Anonimowość:

możliwość ukrycia tożsamości jednostki,
pozostawanie nieodróżnialnym od innych
członków grupy/społeczności

Prywatność vs anonimowość

• Prywatność:

W Polsce prawo to gwarantowane jest w
art. 47 Konstytucji, oraz w przepisach
prawa cywilnego

• Anonimowość:

Anonimowość może być traktowana jako
funkcja bezpieczeństwa w rozumieniu
bezpieczeństwa teleinformatycznego.

Prywatność vs anonimowość

• Anonimowość:

– ukrycie danej aktywności w zbiorze

podobnych aktywności

– nie można być anonimowym w pojedynkę!

• Brak możliwości powiązań:

– akcja (np. wysłanie e-mail) nie może być

przypisana do konkretnego podmiotu

• Nieobserwowalność (trudna do osiągnięcia)

– obserwator nie może odnotować danego

zdarzenia

Prywatność vs anonimowość

• Internet to sieć publiczna

– Komputery w sieci LAN mogą „widzieć” swoje

pakiety nawzajem, router „widzi” ruch
przepływający, …

• Informacja o routingu jest publiczna

– nagłówek IP identyfikuje nadawcę i odbiorcę

• Szyfrowanie nie ukrywa tożsamości

– ukrywa jedynie dane, informacje związane z

routingiem są jawne

Prywatność Internetu

• Algorytm:

– Agreguj ruch
– Dodaj ruch losowy
– Wprowadź opóźnienia
– Przekieruj przez wiele węzłów pośrednich

• Cel:

– Zapobieżenie analizie ruchu

Sieci anonimowe

Anonimowość

• Rozwiązania wspierające anonimowość
• Pojedyncze proxy

– Szyfrowanie:

Safeweb, anonymizer, etc.

– Ukryty kanał komunikacji:

Infranet

• Sieć proxy

– Mixnets
– Szyfrowanie(onion routing):

nym.alias.net, Tor

– Sieć ucztujących kryptografów (Dining

Cryptographer Networks):

Herbivore

2014-05-27

Pojedyncze Proxy

• Zalety

– Zazwyczaj szybkie rozwiązanie, małe opóźnienia

• Wady

– Pytacz musi ufać Proxy
– Pojedynczy punkt awarii i ataków.

Pytacz

Proxy

Zasobnik

Sieci Proxy - Mixnets

• Zaproponowane przez Chauma w 1981
• Każde proxy obsługuje wiadomości w

paczkach

• Kluczowa własność:

brak możliwości

odtworzenia powiązań

• Kryptografia klucza publicznego +

zaufany serwer pośredniczący (proxy)

Sieci Proxy - Mixnets

Mix

,{r

,M}

pk(B)

,B}

pk(mix)

,M}

pk(B)

,{r

,M’}

pk(E)

,E}

pk(mix)

,{r

,M’’}

pk(B)

,B}

pk(mix)

,M’’}

pk(B)

,M’}

pk(E)

Podglądający zna wszystkich

wysyłających i odbierających, ale

nie może powiązać wiadomości z

nadawcą i odbiorcą

Anonimowy adres nadawcy

slide 40

MIX

,{r

,M}

pk(B)

,B}

pk(mix)

,M}

pk(B)

M zawiera

,A}

pk(mix

)

, K

gdzie K

jest kluczem publicznym

Response MIX

,A}

pk(mix

)

,M’}

A,{{r

,M’}

}

Tajność bez uwierzytelniania

• Wiadomości przekazywane przez sieć

serwerów Mix

• Nawet gdy część serwerów Mix jest

przejętych przez intruza, wystarczy jeden
bezpieczny, aby zapewnić anonimowość

Kaskada serwerów Mix

• Ukryj źródło wiadomości poprzez losowe

routowanie (crowds, freenet, onion
routing)

• Router nie wie jakie jest rzeczywiste

źródło wiadomości

Losowy routing

2014-05-27

• Nadawca wybiera losowo listę routerów

– Część routerów jest uczciwa, część może być

przejęta przez intruza

– Nadawca kontroluje długość ścieżki

Onion routing

Bob

Alice

• Informacja o routingu dla każdego łącza jest

zaszyfrowana kluczem publicznym routera

• Każdy router zna tożsamość jedynie następnego

routera

Ustalenie ścieżki

Bob

Alice

}

pk(R1)

,{ }

}

pk(R2)

,{ }

}

pk(R3)

,{ }

{B,k

}

pk(R4)

,{ }

{M}

pk(B)

• Sieć drugiej generacji onion routing

– Projektowana z myślą o niskich opóźnieniach
– Istnieje od października 2003

• Setki węzłów na wszystkich kontynetach
• Łatwy w użyciu klient proxy

– dostępny za darmo
– Umożliwia anonimowe przeglądanie sieci www

Tor

Test końcowy!

Zasady obowiązujące w trakcie testu końcowego z wykładu

"Bezpieczeństwo i ochrona danych"

1. Test będzie pisemny i odbędzie się dniu

03.06.2014

w sali

wykładowej (

329 A1

)

2. Test będzie przeprowadzony w dwóch turach

a) Osoby o nazwiskach zaczynających się na litery alfabetu

od A do Ł

piszą

test w pierwszej turze, od godz.

13:15

b) Pozostałe osoby piszą test w drugiej turze, od godz.

14.15

3. Test trwa 30 min.

Test końcowy!

4. Każdy z Państwa otrzyma kartkę z około 30 pytaniami

dotyczącymi zagadnień omawianych na wykładzie

5. Odpowiedź na pytanie polega na wskazaniu właściwego

wariantu spośród 4 wymienionych (tzw. test wyboru,
tylko jedna odpowiedź jest poprawna)

np.

Ile rund ma 3DES?
a) 16
b) 3 razy tyle co DES
c) 3,333
d) 2

123

Test końcowy!

• Odpowiedź na każde pytanie jest oceniana binarnie:

dobrze - 1 pkt., źle 0 - pkt.

• Korzystanie z pomocy kolegów/koleżanek oraz tzw.

ściąganie automatycznie powoduje wystawienie
końcowej oceny 2.0,

bez możliwości poprawy

• Ewentualne wątpliwości będzie można wyjaśnić dopiero

po teście. W trakcie pisania, na sali obowiązuje cisza.

• Informacje o wynikach, wpisach, itd. Będzie podana na

stronie kursu

• W przypadku wątpliwości proszę o kontakt

Grzegorz.Kolaczek@pwr.wroc.pl

2014-05-27

Konkurs

• Na kolejnych slajdach znajduje się lista nagród za

aktywność i uczestnictwo w wykładach

• Wartości w tabeli są wartościami wyjściowymi funkcji

skrótu SHA-256

• Wartość wejściowa jest postaci:

– Nr_indeksu;ocena

• np. 11111111;5,5

lub
– Nr_indeksu;dodatkowe_punkty;pkt

• np. 11111111;5;pkt

• Przystąpienie do testu końcowego unieważnia ofertę

SHA-256

01460658dd077b88bee6f1ed6f03180afe05490e120bdba2bb0538e89c58ecd5

045529a19b3cc386436ff57553b38e98ffdb2eaeb116acf8bfd35706c033bec7

08df6df78e14ace5f74ccc121588026e30470fa61929a97739d738bfceb80f0b

174c1ed6c7aa2c2c7c75c02a3a5e13bf439beb15535543b49b7007e44c9885a1

1a023b626fb017de79c8f4e3e7338f9093ee01100d99bc00b8aac33f01527862

21c151acc56c8d2236841a578deb1c1a74480d607063d6f1e15189afe3b97f50

26f98f8910a92930bb003f0f7950c1c1feea0199f9895a8752c2af6acb9ce74b

3b38e0db1e24e5a907dcc179416faebbe697fcccdcab55e0fd8d2c649e187f0d

4370aab378b55f3faf1abfc7c6f996d5e722003af7068447cbf2c4fc2b6e3c2d

454124a7ec021dee5baeb1279af4daeb3d3ed7f4d6298e6aa54b17cfec074b87

SHA-256

45c2a6259b808d0fe0c9dd8ac6b4f74baca83d3a9384121f5b0c15df8394d168

4bf501a70e7fa18d492d13d9e9bcec2e538acbb5c4f00546e0da9754c669d53e

4e3e1b2533cc470995af2af7e8a2777a949788a56d1e196fc6d9e40c9d70dab7

5291ff433831cc0a10e592ed7eed740cd430429544aeeb7f9251ed4ef3e8fffc

54dd4926ecfaebef6562cb527d149e7b82d439a5da769cd0a10fa07623343ec1

61a3045e445246b7ebc0ab8b4b845857095782123d64109f6b9dba839ce1e8fc

64e2c23f86734a0ee434c79eb63096733763fb31b9b76b16c3f43e5084c087ef

80f1cc8e25de255f71810870434f89f0360e5788d00e98151c8c804ec9036731

880440c2d7677cc45baa1b0f74adc7fe108874c92350905e17262272a619e546

8fc17dda04cf462f52297456f3ff02bcf62a5562e35e4f93901c30d37fae2de9

SHA-256

9931445d13c764abb04eed2b92562ca978579064e2c2bf623e777983a3418829

9d05caebdfb0b35714fabddb1579af0bd661d51e8fdda5d77fcd224fc50e1661

9e1c12739c4c093bcad853719cda1a5a5aac52a8f1ceddaa68eac415eb5b6092

a92d7d57b711dd241039259ee17fc726a8314a162008ebabbfe65bc2b2bfc17d

b536f97be1f1c1f61cc6bf68944a58f9210317f7e8760cbb58f20d53326dac9d

fab2a2143ce810f29400c5b2a1eb78d7d422fb1726a8ffba98d4c881c839f5be