Bezpečnost počítačových sítí Jan Outrata únor-květen 2012-2020 Úvod ==== - bezpečnost protokolů LAN a Internetu - poznámky pro vlastní studium, široká, rychle se měnící oblast - zdroje: články (web, odborné, SW (operační systémy, autentizace, firewall, VPN, PKI, protokoly), kryptografie, normy RFC, ISO (abstraktní), ITU-T (např. X.509), ETSI aj. - proti čemu zapezpečovat, proti čemu z Internetu se chránit?: - ohrožení činnosti sítě (infrastruktura) nebo uzlů poskytujících služby (servery na LAN) s cílem je ochromit nebo zneužít - ohrožení uložených nebo přepravovaných dat - získání chráněných (emaily, hesla apod.), modifikace, zneužití - závadný obsah (proti ideologii, mravnosti atd.) -> cenzura - původně minimální až žádné zabezpečení = Internet ne-bezpečný! - útoky (metody): - chyby z technických příčin - přerušení a rušení média - inteligentní útočník ("hacker") - zneužití vlastností a chyb HW, SW a protokolů, k nelegální činnosti = kybernetická kriminalita (bezpečnostní události a incidenty) - na fyzickou bezpečnost - přerušení a rušení média, odposlech a modifikace dat, fyzická krádež dat, jednodušší na vyšších vrstvách na zařízení na koncích spoje - podvržení adres, autentizačních/autorizačních dat a údajů pro šifrování (klíčů, certifikátů) - typ útoku spoofing, phishing, pro vydávání se za původního účastníka, typ útoku Man-in-the-middle (MITM) - zahlcení sítě nebo příjemce (kvůli režii zpracování) - síť/příjemce odmítá další data, typ útoku flooding, amplifying, vedoucí k Denial of Service (DoS, znepřístupnění služby) - převzetí spojení/relace - vydávání se za původního účastníka, typ Man-in-the-middle (MITM) - ... - na organizační opatření = "sociální inženýrství" - např. uživatel nevědomky umožní útok (web. odkaz, napadaný SW aj.), zaměstnanci sami provedou útok zevnitř, podvodné identity na sociálních sítích atd. - dnes zabezpečovací metody/protokoly a zabezpečené protokoly - použití v rámci kybernetické bezpečnosti - ochrana/obrana (metody): - řešení chyb z technických příčin - fyzická ochrana, záložní spoje a zařízení, zabezpečení integrity dat kontrolním součtem - fyzická proti inteligentnímu útočníkovi - omezený a kontrolovaný přístup - softwarová proti inteligentnímu útočníkovi - bezp. kontrolní součet (hash) se sdíleným tajemstvím, autentizace/autorizace, šifrování, el. podpis, VPN, proxy, filtrace - na základě analýz incidentů a testů - organizační - pracovně-právní nebo smluvní vztah uživatele s provozovatelem sítě (např. u (W)LAN), mezinárodní právo proti útokům z Internetu, zákon o kybernetické bezpečnosti (Národní centrum) - bezpečnostní analýza: porovnání výše rizik útoku s náklady na obranu, trvalou i jen v případě útoku, stanovení min. požadavků na zabezpečení kritické inf. infrastruktury -> bezpečnost není stav, ale proces - požadavky a situace se neustále mění IDS (Intrusion Detection System) a IPS (Intrusion Prevention System) -------------------------------------------------------------------- - sledování a vyhodnocování nezvyklého/podezřelého provozu na uzlu/síti (dle databáze signatur a heuristik - aktualizace!) pro odhalení a příp. i zamezení útokům a průnikům do uzlu/sítě - upozornění (pasivní), zablokování přenosu (aktivní, IPS) - uzlové (host-based): pro lokální hrozby a útoky na PC, serverech - síťové (network-based): sondy na LAN pro sběr přenášených dat z filtru pro internet (firewallu) nebo diagnostických výstupů aktivních síťových prvků (switch, přístupový bod) - režie: (minimální) snížení výkonu zařízení a rychlosti sítě - testování simulováním útoků: destruktivní (zálohované uzly dostupné z Internetu), nedestruktivní (nezálohované uzly ve vnitřní síti) - honeypot = nezabezpečený uzel "lákající k útoku" na infrastrukturu, aplikace nebo OS, logující a analyzující útok, využití pro nastavení IDS/IPS - např. Snort, Samhain, AIDE, Suricata, Cisco Secure IDS Architektura TCP/IP =================== - původní historická představa do počátku 90. let - 3 oddělené "jednoduché" vrstvy: IP (plus ARP/RARP), TCP/UDP, aplikační protokoly - (prakticky) žádné zabezpečení proti inteligentnímu útočníkovi - jen řešení chyb z technických příčin (poškození, ztráta dat), při autentizaci heslo přenášené v otevřeném tvaru! - vznik z popudu ministerstva obrany USA!! Obr. Původní architektura TCP/IP [2.1] - dnešní představa složitější - vrstvy "složené" a neostře oddělené, protokoly a funkcionalita spadající do více vrstev, zasahování i do linkové vrstvy, důvod: zabezpečení - linková vrstva: autentizace vůči přístupovému bodu (AP), blokace/povolení portů AP, šifrování - síťová vrstva: nad IP (verze 4 a 6) překlad adres (NAT), šifrování (IPsec), VPN, tunely - aplikační vrstva: nad protokoly proxy, brány, tunely, pod protokoly prezentace a komprimace (VT, MIME), šifrování (SSL/TLS, S/MIME), el. podpis (DNSSec) - napříč vrstvami: autentizace uživatelů a autorizace dat, filtrace, překlady adres (NAT), VPN, tunely Obr. Dnešní architektura TCP/IP [2.2] Fyzická vrstva -------------- - technologie realizují ochranu a řešení chyb z technických příčin, např. vada média nebo vlivy prostředí, primárně se nepočítá s inteligentním útočníkem - nejméně citlivé optické spoje, nejvíce bezdrátové - ochrana: záložní spoje, vhodný materiál a izolace média, modulace a kódování signálu - útoky na samotné médium: přerušení a rušení přenosu, odposlech a modifikace signálu - obrana proti inteligentnímu útočníkovi: fyzická ochrana a izolace média, např. LAN, nebo smluvní vztah se správcem prostředí s médiem, záložní spoje - využití záložního spoje i při bezproblémové komunikaci - v TCP/IP netriviální (např. rozložení příchozího provozu od více poskytovatelů připojení k síti) - odposlech užitečný pro správce sítě při hledání chyby nebo detekci útoku - HW analyzátory Linková vrstva -------------- - útoky a ochrana/obrana podobné fyzické vrstvě - řešení chyb z technických příčin - ochrana: kontrolní součet rámce a zahození vadných, útočník může součet při změně dat přepočítat (algoritmus je součástí specifikace) - v LAN (s drátovým médiem) se primárně neřeší útoky inteligentním útočníkem - útoky snadné!, naopak u broadband spojů nebo WLAN se řeší - útoky: odposlech a modifikace dat, podvržení adres odesílatele i příjemce (MAC/ARP spoofing), zahlcení AP/příjemce odesíláním enormního množství rámců (MAC flooding), převzetí portu přístupového bodu (AP, např. přepínač, port stealing) - obrana proti inteligentnímu útočníkovi: statické nastavení AP, filtrace falešných rámců, autentizace vůči AP, blokace/povolení portů AP, autentizace a šifrování - SW (IEEE 802.1X, PPP, WLAN), HW (šifrátory) - odposlech užitečný pro správce sítě při hledání chyby nebo detekci útoku - SW Wireshark, MS Network Monitor aj. IPv4 ---- - řešení chyb: 2B kontrolní součet záhlaví paketu a ICMP zprávy, zahození vadných paketů, oznamování nemožnosti doručit paket (ICMP) - neřeší zabezpečení proti inteligentnímu útočníkovi - naopak některé volitelné položky záhlaví (směrování, striktní směrování) a některé ICMP zprávy (změň směrování, echo?, všechny?!) nebezpečné - nevyužívají se, pakety/zprávy ignorovány nebo filtrovány (na směrovačích) - útoky: odhalení uzlů v privátní síti (IP scanning), podvržení adres odesílatele a příjemce (IP spoofing), zahlcení sítě/příjemce odesíláním enormního množství paketů nebo (malých) fragmentů (ICMP floofing), např. ping -f (jen privilegovaný uživatel), zneužití nebezpečných položek IP/ICMP záhlaví (ICMP redirect) - obrana: filtrace paketů a fragmentů, překlad adres?, šifrování paketů, VPN - IPv6, zpětně i pro IPv4: bezpečnostní záhlaví pro IPsec (protokoly AH, ESP) TCP/UDP ------- - řešení chyb: 2B kontrolní součet záhlaví segmentu (a některých položek záhlaví IP paketu, vyplnění v UDP datagramu nepovinné), zahození vadných segmentů/datagramů, potvrzování přijatých, odesílatel opakuje nepotvrzené, číslování přenášených bajtů od náhodného čísla - pro rozlišení dat ze zatoulaných segmentů selhaného krátkého spojení a segmentů z nového stejného spojení - zabezpečení proti inteligentnímu útočníkovi: řízení toku dat proti cílenému zahlcení sítě/příjemce (DoS)? - útoky: před útokem skenování otevřených portů (s naslouchajícími servery) pokusem o navázání spojení (port scanning) - pro útok na apl. protokol/aplikaci, zahlcení příjemce vytvořením enormního množství (zahájení navázání) spojení, popř. s mnoha nastavenými příznaky (TCP syn/UDP flooding), převzetí spojení (connection hijacking) - vydávání se za klienta i/nebo server, po autentizaci v nezabezpečeném aplikačním protokolu!, zneužití otevřených portů (např. TCP pro HTTP, UDP pro DNS, NTP) pro jiné apl. protokoly na směrovačích? - obrana: server na jiném než well-known portu, filtrace (pokusů o navázání) spojení, sledování portů při navazování spojení a ignorování při skenování, port-knocking, šifrování segmentů/dat (SSL/TLS) - v případě filtrace podle záhlaví segmentu a IP fragmentace paketu je vhodná i filtrace ostatních fragmentů paketu, nejen prvního se záhlavím segmentu - potřeba "sledovat" spojení, tzv. příbuzné (related) pakety = stavovost filtru Aplikační protokoly ------------------- - původně prakticky žádné zabezpečení, nanejvýš prvotní autentizace jménem a heslem (přenášeným v otevřeném tvaru!) - později nutnost zabezpečení - kvůli charakteru služeb - dříve nezabezpečené protokoly: R-utility (rlogin, rsh aj.), Telnet - nadále pro testování znakových protokolů (virt. terminá), Gopher - dnes zabezpečení původních a nové - trvalá autentizace, šifrování, el. podpis: SSL/TLS obálka (HTTPS, SMTPS, IMAPS), SSH, DNSSec, aplikace PKI - důležitý správný čas = NTP - v LAN nezabezpečený přenos dat, trvalá autentizace (token): SMB/CIFS, NFS - útoky: podvržení adres protokolu (protokol spoofing, např. DHCP, DNS!, phishing, např. HTTP, SMTP), zahlcení příjemce (serveru, protokol flooding), podvržení autentizace, na aplikace - kompromitace dat "trojskými koni" před (zabezpečeným) přenosem, útoky na sítě Internet i intranet a servery i klienty z kompromitovaných aplikací, např. "síťoví červi", botnety - obrana: zabepečení aplikací a komunikace v síti - šifrování, el. podpis, šifrované tunely, bezpečné (bez chyb) aplikace serverů, oddělení klasifikovaných dat a důležitých serverů intranetu od internetu - firewall, proxy, brány, tunely TODO: protokoly DNS, HTTP, pošty, NTP Základní pojmy kryptografie a jejich aplikace ============================================= - kryptografie = konstrukce metod pro utajení informace - šifrovacích metod, šifer - kryptoanalýza = analýza metod (a jejich implementací) z hlediska zranitelnosti, cíle vylepšení metody nebo získání informace (bez znalosti klíče, tj. "zlomení" tajné metody nebo klíče, např. Enigma), např. lineární, diferenční analýza, metoda síta číselného tělesa (pro faktoriaci čísel) aj. - kryptologie = kryptografie + kryptoanalýza - symbol a_i, abeceda A, slovo/zpráva nad A v M_A, kód C: M_A -> M_B (C^-1, veřejný, tajný), šifra C(K), C^-1(K') (symetrická, asymetrická) a klíč K, K' (šifrovací a dešifrovací), otevřený a šifrovaný text - historický základ: substituce, transpozice Bezpečný kontrolní součet (Hash) = jednocestná funkce = výpočetně nenáročná (bitové operace, posuny), "inverzní" velice náročná (neexistuje - funkce není injektivní, "inverzní" = z daného obrazu najít alespoň jeden vzor) - z lib. dlouhého textu (nebo rozděleného do bloků a iterace) krátký řetězec konstantní délky = hash, např. 16 B u MD-5 (Message Digest), 20/28-64 B u SHA-1/2 (Secure Hash Alg.) => nejednoznačné - výrazně jiný výsledek i při malé změně textu - bezkolizní = nelze efektivně najít dva různé texty se stejným součtem (neexistence "inverzní" funkce) - ne šifrovací funkce, role "otisku prstu" (fingerprint) - kontrola integrity dat: odeslání dat spolu se součtem dat, příjemce spočítá součet z dat a porovná s přijatým Obr. Použití kontrolního součtu [1.3] - útok: změna dat a přepočet součtu -> obrana: součet z kombinace (zřetězení) dat a sdíleného tajemství (~ klíč) = MAC (Message Auth. Code)/"symetrický podpis" (jen integrita, ne pravost dat - útok příjemcem) - využití např. autentizace, zabezpečení linkových rámců, SSL/TLS, IPsec, SSH aj. Symetrická šifra - sdílený tajný symetrický šifrovací (a dešifrovací) klíč - šifrovací a dešifrovací algoritmus s využitím klíče - iterace s pracovním klíčem odvozeným od (základního) klíče, operace XOR, např. DES (Data Encryption Standard, 1976) s 56-bitovým klíčem, 3DES 112-bit, IDEA, RC-2, RC-4 128-bit, Blowfish, AES (Advanced Encryption Standard)/Rijndael 128/192/256-bit - blokové = šifrování dat po blocích (= slovo délky násobku znaku) typicky 8 B, mód šifry = způsob šifrování více bloků, nezávisle, např. ECB, s "vázáním" sousedních (inicializační vektor, postupné šifrování bloků se zpětnou/řetězovou vazbou), např. CFB, CBC Obr. Módy blokových šifer [7-6, 7-7, 7-8] - proudové = šifrování po znacích - bezpečné vygenerování a výměna klíče, např. Diffie-Hellmannův (DH) algoritmus: obě strany vygenerují soukromé (a,b) a z něj veřejné číslo (z nějž nelze soukromé efektivně zjistit, např. A==g^a mod p, B==g^b mod p, p veřejné prvočíslo, např. 13, g generátor cykl. grupy (Z_p^*,.), např. 6), které předají druhé straně, z veřejného čísla druhé strany a vlastního soukromého výpočet stejného sdíleného tajemství (s==B^a mod p==A^b mod p - diskrétní logaritmus, další např. eliptické křivky) a z něj klíče, použití např. u IPsec, SSL/TLS aj. - útok: nalezení ("zlomení") klíče ze znalosti původních a šifrovaných dat - krátký, "slabý" šifrovací algoritmus, změna pořadí bloků, Man-in-the-middle - obrana: dlouhý klíč, "silný" šifrovací algoritmus, mód šifry s "vázáním" sousedních bloků (CBC) Asymetrická šifra - šifrovací a dešifrovací klíč - z prvního nelze efektivně (dostupnými prostředky v dostupném čase) určit druhý - u některých šifer šifrování a dešifrování zaměnitelné -> veřejný a soukromý klíč - příjemce vygeneruje klíče, soukromý tajný, veřejný zveřejněn, odesílatel šifruje s využitím veřejného klíče příjemce, příjemce dešifruje s využitím svého soukromého klíče - implementace založeny na Public Key Infrastructure (PKI) Obr. Asymetrická šifra [1.6] - výpočetně jednoduché s využitím veřejného klíče šifrovat, ale velice náročné "dešifrovat" - např. nutný rozklad součinu dvou (velkých prvo-) čísel na ně (faktorizace) - např. RSA 1/2/4-kbit (Rivest, Shamir, Adleman, 1977, standard PKCS#1), ECC 160-bit (eliptické křivky), ElGamal, DSA (diskrétní logaritmus) - (mnohem) náročnější než symetrické šifry - delší klíč, "silnější" (složitější) algoritmus -> elektronická obálka: data šifrovaná symetrickou šifrou s náhodným klíčem + klíč šifrovaný asymetrickou šifrou (i pro různé příjemce), např. standard PKCS#7 Elektronický/digitální podpis - využití asymetrické šifry (a hashe) pro potvrzení a ověření (verifikace) pravosti dat, na základě vlastnictví soukromého klíče (a jednosměrnosti součtu) - implementace založeny na Public Key Infrastructure (PKI) - podpis dat = zašifrování hashe dat s využitím soukromého klíče podpisujícího - ověření podpisu: přijetí dat spolu se šifrovaným součtem dat, výpočet součtu z dat a porovnání s dešifrovaným přijatým (s využitím veřejného klíče podpisujícího) Obr. Podpis a ověření podpisu [1.9] - oproti asymetrickému šifrování prohození klíčů - potřeba šifry se zaměnitelným šifrováním a dešifrováním, např. RSA - obdoba klasického podpisu dokumentu (na základě schopnosti jedinečného podpisu), ale dokument/data nelze zfalšovat (bez znalosti soukromého klíče, potřeba zašifrovat přepočítaný součet změněných dat) - útok: podvržení veřejného klíče za jiný při zveřejnění (a dešifrování jiným soukromým a šifrování původním při přenosu dat) = vydávání se za odesílatele Obr. Podvržení veřejného klíče [1.10] - obrana: certifikace veřejného klíče Certifikace veřejného klíče = potvrzení pravosti klíče pomocí certifikátu - žádost o certifikát = identifikační údaje uživatele (předmětu certifikátu) a jeho veřejný klíč podepsané s využitím soukromého klíče - předání žádosti certifikační autoritě (CA): ověří podpis a totožnost uživatele (validitu předmětu) a vystaví certifikát = identifikační údaje uživatele (předmětu), jeho veřejný klíč, identifikační údaje CA, sériové číslo, doba platnosti aj. podepsané s využitím soukromého klíče CA - důvěryhodné potvrzení identity uživatele (předmětu) - ověření totožnosti uživatele (validity předmětu) -> úroveň certifikátu: držení doménového jména (předmět) - potvrzení přijetí e-mailu, vystavení souboru přes HTTP, vytvoření DNS záznamu aj. -> DV (domain-validated) certifikát, totožnost organizace (žadatele) - DV + identita organizace -> OV (organization-validated), totožnost osoby (žadatele) - důkladnější OV + identita osoby -> EV (extended-validated) - zveřejnění certifikátu místo klíče - implementace založeny na Public Key Infrastructure (PKI) Obr. Certifikace veřejného klíče [1.11] - ověření certifikátu: ověření podpisu CA s využitím veřejného klíče CA - útok: podvržení certifikátu při předávání žádosti nebo zveřejnění = vydávání se za CA podvržením veřejného klíče CA nebo (automaticky vydaný) certifikát od tzv. testovací CA (např. Verisignu, nedůvěryhodná, ale bývá v SW!) - obrana: certifikace veřejného klíče CA jinou (vyšší) CA => stejný problém -> řetěz důvěryhodnosti CA až ke kořenové CA se self-signed certifikátem, CTL (Certificate Trust List) - (el. podepsaný) seznam důvěryhodných CA, předinstalovaný v OS, web. prohlížečích aj. - pro ověření certifikátu vydáván spolu s certifikáty CA (řetěz důvěry, certificate chain), popř. seznamem odvolaných (např. starších) certifikátů - self-signed certifikát = podepsaný s využitím soukromého klíče asociovaného k certifikovanému veřejnému klíči => nepotvrzuje pravost klíče! - útok podvržením celého řetězu certifikátů až ke kořenovému včetně -> distribuce kořenového nebo jeho kontr. součtu ("otisku") jinou (bezpečnou) cestou = pevný bod důvěry - el. podpis spolu s certifikátem veřejného klíče - rovnocenná obdoba klasického podpisu? (za podmínek zákona o el. podpisu i v ČR), certifikace pro možnost důvěryhodného ověření podpisu, certifikát obdobou občanského průkazu (dnes může obsahovat) - archivace soukromého klíče k šifrovacímu certifikátu u CA (součást žádosti o certifikát, kvůli riziku jeho ztráty a nedostupnosti zašifrovaných zpráv) - důvěra v CA! - soukromý klíč k podepisovacímu nebo autentizačnímu certifikátu pouze u uživatele!, ideálně vytvořený a uložený v tzv. HW klíči (viz dále), při ztrátě vytvoření nového (s certifikátem), při zcizení okamžité odvolání certifikátu! TODO: atributový certifikát, časové razítko Autentizace a autorizace ======================== - klasicky jméno a přístupové heslo, dříve přenášené nezabezpečeně, dnes komplikovanější (asym. kryptografie, dig. podpis, certifikáty), ale bezpečnější - autentizace uživatele ~ přihlášení = prokázání/ověření totožnosti - uživatel něco ví/umí (heslo, PIN, odpověď, SW token - kopírovatelný), má (čipová karta, aut. kalkulátor, HW/security token - nekopírovatelný, mobilní telefon??), nebo je (biometrické vlastnosti) = faktory, kombinace = vícefaktorové (silné) autentizace - bezpečnější, nezávislé, alespoň jeden neznovupoužitelný a nereplikovatelný - autorizace uživatele k něčemu (přístupu) = souhlas/zákaz, ve vztahu k datům, ke službě apod., na základě oprávnění, typicky po autentizaci - autorizace dat = důkaz pravosti dat odeslaných uživatelem, ochrana před změnou útočníkem (hash/symetrická šifra) nebo před popřením pravosti odesílatelem (el. podpis) Heslo ----- - na druhé straně uložen hash nebo symetrická šifra - ochrana proti zneužití správcem systému - z přijatého hesla se vypočítá hash nebo ze stejného textu (např. samé 0) šifra za použití hesla jako klíče a porovná se s uloženým - salt ("sůl") = náhodný text přidávaný k heslu před hashem/šifrou, pro různý výsledek při stejném heslu, uložené (otevřeně) se součtem/šifrou - bezpečné dle zákona o kybernetické bezpečnosti: min. 8 znaků, alespoň tři z velké a malé písmeno, číslice a speciální znak, měněno každých 100 dnů Jednorázová hesla ----------------- - řešení problému zneužití odposlechnutého hesla - použití i mimo oblast poč. sítí, např. bankovní služby - mechanizmus výzva-odpověď (challenge-response) = druhá strana pošle náhodnou výzvu, uživatel na jejím základě vytvořené heslo - seznam: náhodně vygenerovaná hesla (uložená jako hashe/šifry), bezpečně předaná uživateli, používaná postupně nebo v určitém nebo náhodném pořadí (zadaným ve výzvě), těžko zapamatovatelný, kombinace s klasickým (vícenásobným) heslem - zadání obojího, varianta aut. karta = seznam údajů (čísel, znaků aj.), ze kterých se složí a zadá heslo na základě výzvy - rekurentní algoritmus (Lamportovo schéma): nejdříve si uživatel vygeneruje tajný text T a předá druhé straně číslo n a H^n(T) (popř. s autentizací pomocí jednorázového hesla), kde H je hash, pak při autentizaci ve výzvě číslo n-1, uživatel pošle H^{n-1}(T), druhá strana vypočítá a porovná H(H^{n-1}(T) = H^n(T), při úspěchu uloží n-1 místo n a H^{n-1}(T) místo H^n(T), n-1 hesel, při n=1 znovu - S/KEY: implementace rekurentního algoritmu s H = MD-4 a XOR polovin 16B součtu, T min. 8B, náhodná salt ve výzvě přidávaná k T, RFC 1760 - OTP (One Time Password): rozšíření S/KEY o další H, např. MD-5, SHA-1, předávaný ve výzvě ("otp-H n salt"), RFC 1938, rozšířená výzva a odpověď, RFC 2243, použití např. v IMAP4 s kódováním komunikace Base64 - sdílené tajemství: jedna strana náhodně vygeneruje tajemství a (bezpečně, např. DH) předá druhé straně, heslo = hash nebo sym. šifra (nebo jejich část) ze stejného textu s klíčem vytvořeným z výzvy (i jen čítač) a tajemství, obě strany musí znát tajemství - možnost zneužití jednou stranou, použití např. u SSL/TLS, využití pro autorizaci dat - (blokový) hash/sym. šifra z dat a tajemství ("symetrický podpis"), např. HMAC (Keyed-Hashing for Mesg. Auth, RFC 2401), jen ochrana před změnou dat, ne před popřením pravosti -> HOTP (An HMAC-Based One-Time Password Algorithm, RFC 4226), použití např. u (přístupových) čipových karet - autentizační kalkulátor - el. zařízení nebo SW (např. Google/OTP Authenticator) pro autentizaci, popř. i autorizaci dat, implementující hash (MD-5, SHA-1) nebo symetrickou šifru, v něm (příp. šifrované s klíčem PIN) a na druhé straně sdílené tajemství, místo nebo vedle výzvy druhé strany může být čas (obvykle s přesností na minuty) - porovnání s několika předchozími i následujícími hesly pro případ rozdílu času (a zaznamenání rozdílu času), např. TOTP (Time-based One-time Password Algorithm, RFC 6238), výhoda: nezávislost na bezpečnosti prostředí (bezpečnost zajišťuje kalkulátor), nevýhoda: přítomnost a opakování dat při autorizaci dat -> např. optický klíč = přenos dat modulovaných do obrazců (např. QR) na obrazovce PC snímaných kalkulátorem/klíčem - GSM/mobilní (běžná) "dvoufaktorová autentizace": SW token, ne nahrazení kalkulátoru (HW token), druhá strana zašle náhodné jednorázové heslo pomocí SMS - druhý nezávislý kanál (bezpečnost závisí na bezpečnosti kanálu!) => vícekanálová autentizace, faktor má ~> dostal! - SASL (Simple Auth. and Security Layer): systém popisu a registrace metod autentizace např. v OS, RFC 2222, popisy metod např. Anonymous SASL Mechanism (RFC 2245), OTP SASL Mech. (RFC 2444), SecureID(r) SASL Mech. (RFC 2808), Using Digest Auth. as SASL Mech. (RFC 2831) Asymetrické šifrování --------------------- - autentizace uživatele: na základě vlastnictví soukromého klíče - druhá strana pošle náhodnou výzvu, uživatel ji podepíše a druhá strana podpis ověří (s využitím veřejného klíče z certifikátu) - autorizace dat = el. podpis - šifrování soukromého klíče - útok "trojským koněm" zjišťujícím heslo nebo dešifrovaný klíč v paměti - HW klíč: el. zařízení se zabezpečeným podepisovacím a autentizačním soukromým klíčem implementující el. podpis, např. čipová karta, USB klíč, HSM (Host Security Modul, zabezpečení proti fyzickému útoku, např. vymazání nebo sym. šifrování klíče, popř. zničení se), soukr. klíč se neimportuje ani neexportuje (garance!) - podporuje generování páru klíčů, žádost o certifikát, uložení certifikátu a el. podpis, popř. import šifrovacích klíčů (veřejný i soukromý, jiné úložiště), útok podvržením dat k podpisu (např. podvržením SW předávajícího data) Biometrika ---------- - otisky prstů (stovky B), struktura oční sítnice nebo duhovky, charakteristiky obličeje, hlasu, prvky DNA aj. - jako (vícenásobné) heslo! => lokální použití a pro přístup např. k čipové kartě, USB klíči apod. - biometrika uložená stejně jako soukr. klíč, implementace porovnání (Match On Card) TODO: RADIUS, Kerberos Síťové technologie ================== Ethernet - lokální síť (LAN) -------- - rámce se šíří segmentem, rozhraní přijímá rámce adresované jemu, všesměrové a zvolené skupinové - tzv. promiskuitní režim = rozhraní přijímá všechny rámce - nepřepínaný = uzly připojené k opakovači (HUB), segment = všechny uzly připojené k opakovači, sdílené médium - žádná bezpečnost!, kolizní doména = celý segment -> dnes už se nepoužívá - přepínaný = uzly připojené k přepínači (switch), (virtuální) segment = uzly připojené k portům přepínače, ke kterým jsou připojené odesílatel a příjemce - "izolace" komunikací mezi uzly, kolizní doména = port IPv4 - zjištění prezence uzlu na LAN na základě MAC adresy: arp ping = ARP dotaz a odpověď - vždy, když ARP adresa k IP adrese není v ARP cache uzlu -> (IP) ping (ICMP echo) - slabiny ARP protokolu: žádné párování ARP dotazu s odpovědí, ARP odpověď je legitimní i bez předcházejícího ARP dotazu (pokud IP adresa z odpovědi už je v ARP cache, pokud ne -> ping) - útoky: ARP spoofing a.k.a. ARP cache poisoning = podvržení MAC adresy směrovače (typicky výchozí brány LAN) v ARP odpovědi uzlu, popř. i obráceně pro druhý směr -> MITM - falešná ARP odpověď pro IP adresu směrovače/uzlu se zdrojovou MAC adresou útočníka - uzel/směrovač si uloží do ARP cache - ARP gratuitous reply = falešná ARP odpověď na broadcast MAC adresu - podvržení MAC adresy na všech uzlech LAN - detekce: monitorování tabulky (spravovatelného, managed) přepínače a ARP cache (problém s DHCP), ARP odpovědi bez požadavku - obrana: statická ARP cache (vyřazení ARP protokolu, problém s DHCP -> DHCP snooping), filtrace falešných ARP odpovědí na (spravovatelném, na síťové vrstvě, L3) přepínači (např. u Cisco Dynamic ARP Inspection) a uzlu/směrovači nebo kontrola MAC-IP u všech paketů (Dynamic IP Lockdown) Port stealing = přepsání portu uzlu v tabulce přepínače -> data pro uzel k útočníkovi (s promiskuitním režimem), popř. i uzel=směrovač -> MITM - odeslání falešného rámce s cílovou MAC adresou útočníka (nebo broadcast, při více přepínačích a uzel na jiném než útočník) a zdrojovou uzlu - přepínač si uloží s portem útočníka do tabulky, uzel může poslat rámec => opakování - větší intenzita, krátké intervaly - pro přeposlání rámce uzlu: ARP dotaz na MAC adresu uzlu a po obdržení odpovědi odeslání rámce - detekce: více ARP dotazů na MAC adresu uzlu, na přepínači rámce s cílovou adresou na stejném portu, monitorování tabulky (spravovatelného) přepínače - obrana: statické nastavení tabulky (spravovatelného) přepínače (nebo DHCP Snooping) MAC flooding = přeplnění tabulky přepínače, který se začne chovat jako opakovač a (po čase) tabulku vymaže, a naplnění tabulky MAC adresami uzlů LAN s portem útočníka -> data k útočníkovi (s promiskuitním režimem) - odesílání velkého množství rámců s náhodnou zdrojovou i cílovou (možno i svojí) MAC adresou k přeplnění a pak se zdrojovými MAC adresami uzlů LAN, uzel může odeslat rámec po vymazání tabulky dřív než útočník => opakování - detekce: monitorování tabulky (spravovatelného) přepínače, odposlech mnoha cizích rámců (v promiskuitním režimu) - obrana: statické nastavení tabulky (spravovatelného) přepínače - další útoky např. na VLAN IPv6 - nekompatibilní s IPv4 => zabezpečení IPv4 nezabezpečuje IPv6 a obráceně! - "nevyzrálý" (?), nedostatečně podporovaný (?) a nedostatečně rozšířený (!) => nedostatečný tlak na řešení bezpečnosti -> obcházení - uzel má více adres - vždy link-local + veřejná - místo broadcastu multicast na ff02::1 (v IPv4 224.0.0.1) = všechny uzly na LAN, ff02::2 (224.0.0.2) směrovače aj. - místo ARP ND (Neighbor Discovery, RFC 4861) - využívá zprávy ICMPv6 => nelze filtrovat - i bezstavová autokonfigurace (SLAAC), zprávy směrovače, detekce duplicitních adres aj. - každý uzel a směrovač v tzv. solicited-node multicast skupině ff02::1:ff00:0/104, v posledních 24 bitech část IP adresy uzlu - cílová IP neighbor solicitation (NS, dotazu na MAC) - neighbor advertisement (NA, oznámení o MAC) zasílané i pravidelně na ff02::1, bity R pro odesílatel směrovač, S pro odpověď na dotaz a O pro doporučení přepisu údajů v ND cache příjemce - legitimní i bez předcházejícího NS?? - směrovač pravidelně rozesílá router advertisement (RA) na ff02::1, uzel si jej může vyžádat pomocí router solicitation (RS) na ff02::2 - RA na adresu uzlu - legitimní i bez předcházejícího RS?? - útoky: Zneužití RA = vydávání se za směrovač - rozesílání RA, se síťovým prefixem existující sítě a IP směrovače v ní! -> MITM - "sdílení internetu" v MS Windows - příp. přechodový mechanizmus z IPv4 (např. tunelování 6to4, Teredo) -> komunikace přes relay směrovač - detekce: monitorování RA - obrana: RA-Guard (RA snooping) na (spravovatelném) přepínači/směrovači (RFC 6105) = blokování RA od neznámých, SAVI (draft) ~ DHCPv6 snooping, vypnutí "sdílení internetu" RA flood = zahlcení uzlu (konfigurováním adresy a přidáním směrovače do směrovací tabulky) - rozesílání RA s náhodnými síťovými prefixy, příp. s informacemi (směry, i desítky!) do směrovací tabulky v route information option - obrana: omezení počtu zpracovávaných RA? - může být i legitimní, omezení počtu záznamů ve směrovací tabulce ND spoofing a.k.a. ND cache poisoning = podvržení MAC adresy dotazovaného uzlu v NA, pro dva uzly -> MITM - falešná NA pro IP adresu dotazovaného uzlu se zdrojovou MAC adresou útočníka s nastaveným bitem O - uzel přepíše údaj v ND cache - podvržení RA a vydávání se za směrovač (typicky výchozí bránu v LAN) -> MITM - záleží ale na OS uzlu, jak změní směrovací tabulku (přidání?) - falešné RA se zdrojovou IP směrovače a stejným síťovým prefixem, ale vyšší hodnotou default router preference (high místo medium) -> menší metrika ve směrovací tabulce, možné jiné IP DNS serverů - detekce: monitorování ND cache, NA a RA - obrana: statická ND cache (zejm. záznam pro výchozí bránu)?, RA-Guard, Secure ND (SeND)?? = kryptograficky generované link-local adresy a podpis ND zpráv, SAVI, IPSec - další útoky např. zneužití ICMPv6 redirect, podvržení DHCPv6 odpovědí - jednoduchá realizace útoků, možný velký zisk, nesnadná (drahá) obrana => nebezpečné -> šifrování komunikace TODO PPP/PPTP -------- - použití: připojení k Internetu přes telefonní (komutovanou) linku, připojení přes Internet do intranetu (VPN, tunel) - zabezpečení: autentizace, šifrování - volitelné, zpětné volání na uložené číslo ("druhý zámek" po autentizaci) Autentizace - nepovinná (nebo mimo PP(T)P terminálovým dialogem), mechanizmus výzva-odpověď, možnost oboustranné, způsob dohodnut ve fázi navazování spojení - autentizační protokoly: - PAP (Password Auth. Prot.) - obdoba term. dialogu, jméno a heslo, RFC 1334 - CHAP (Challegne Handshake Auth. Prot.) - ve výzvě (challenge) náhodný řetězec, v odpovědi hash ze spojení se sdíleným tajemstvím (jednorázové přístupové heslo), porovnání přijatého s vlastním hashem a potvrzení/zamítnutí, tajemství v otevřeném tvaru na obou stranách, RFC 1994, varianty MS CHAP verze 1 (RFC 2433) a 2 (RFC 2759) - tajemství = MD-4 hash hesla, hash MD-4, oboustranná a různé klíče pro šifrování odvozené nejen z tajemství až verze 2 - EAP (Extended Auth. Prot.) - dohoda na auth. schématu a vlastní autentizace, schémata minimálně EAP-MD5 (jako CHAP s MD-5 hashem), dále např. EAP-TLS (na základě certifikátů, vytvoření tzv. hlavního tajemství pro tvorbu šifrovacích klíčů), kalkulátor pro jednorázová hesla aj., RFC 2284 - útoky: prozrazení hesla, odposlech telefonní linky??, průnik do připojení do intranetu (VPN, tunel) Šifrování - ECP (Encryption Control. Prot.) - dohoda na šifrovacím algoritmu, ne výměna šifr. klíčů, RFC 1968 - odvození šifr. klíčů z informací vyměněných při autentizaci - hash kombinace sdíleného tajemství a náhodného řetězce z výzvy, RFC 3079 - MPPE (MS Point-to-Point Encryptio) - výběr klíče (40, 56, 128b), šifra RC-4, RFC 3078 WLAN (Wi-Fi) - lokální síť (LAN) ------------ - médium radiový signál v okolí přístupového bodu (Access Point, AP) -> snadný odposlech - přístup většinou (technicky) neomezený = útoky zevnitř => nedůvěryhodná síť (jako Internet) - výchozí konfigurace AP bez zabezpečení, původně nedostatečné bezp. mechanizmy ve standardech (WEP) -> WLAN nebezpečná! -> asociace, autentizace a šifrování na MAC podvrstvě - WLAN pak může být bezpečnější než drátová - ad-hoc konfigurace: obtížná autentizace (identifikace uživatele), dohoda na klíčích (Diffie-Hellman více stranami) aj., dále infrastrukturní (s AP) Asociace - AP (otevřeně) vysílá identifikátor sítě SSID = MAC AP nebo řetězec znaků (až 32B) - klient zjistí AP pasivním nebo aktivním (při ztrátě kvality signálu nebo reasociaci) skenováním frekvencí, vyšle požadavek na asociaci a čeká na potvrzení - potřeba znát SSID - když AP nevysílá v beacon rámcích, lze zjistit pomocí falešného požadavku na deasociaci aktivního klienta a odchycením rámců odpovědi (obsahujících SSID) WEP (Wired Equivalent Privacy) - 1999, součást 802.11a/b/g - integrita dat ICV: CRC-32 - autentizace: jednostranná (klient vůči síti), otevřená (= bez) nebo sdíleným tajným klíčem a MAC, ne autentizace uživatelů, klíč 40b nebo 104b, princip výzva-odpověď (při sdíleném klíči, jako CHAP) - šifrování: dat a ICV rámců, symetrická proudová šifra RC4 (generování pseudonáhodného šifrovacího proudu na základě tajného klíče a XOR s daty), klíč 64b nebo 128b - spojení sdíleného tajného klíče a proměnlivého inicializačního vektoru (IV) délky 24b, posílaného otevřeně, slabé: lze snadno zlomit po odposlechu autentizačních rámců nebo dostatečného množství datových - pasivní nebo aktivní (ARP broadcast, TCP SYN pakety) útok: FMS/KoreK, PTW aj. IEEE 802.1x (Port-Based Network Access Control) - 2001, obecný bezp. rámec pro řízení přístupu na LAN = autentizace (uživatelů), autorizace a správa klíčů - vzájemná (i AP/aut. server vůči klientovi), centralizovaná (volitelně autentizační server v pevné LAN nebo samotné AP) autentizace - EAP/EAPOL (EAP over LANs), různé aut. mechanizmy, více aut. metod na principu výzva-odpověď: EAP-MD5 (jako CHAP), LEAP (MS-CHAPv2), EAP-(T)TLS, PEAP aj. - blokování portů AP - log. porty AP vytvořené na základě asociace, před autentizací přístup pouze k aut. serveru - vygenerování a změny hlavního klíče (odvozeného ze sdíleného tajného klíče), z něj odvození a distribuce tajných klíčů pro šifrování klientům (management klíčů) - 4-way handshake (v PSK dále) WPA (Wi-Fi Protected Access, TSN, Transitional Security Network) - 2002, autentizace 802.11x (vzájemné EAP, WPA Enterprise) nebo (všemi) sdíleným tajným klíčem (PSK, WPA Personal), slabé šifrování jako u WEP, ale s proměnlivým klíčem, dočasné řešení před 802.11i/WPA2 (nevyžaduje změny HW) - integrita dat MIC: 64b kód za daty, 2 klíče 64b (klient a AP) ~ dig. podpis, v případě narušení deasociace - PSK (Pre-Shared Key) = generovaný 4096 hashi z hesla 8 až 63 šestnáctkových cifer a SSID, nahrazuje hlavní klíč, útok: lze uhádnout po odposlechu (nešifrovaných) autentizačních rámců slovníkovou silou - šifrování TKIP (Temporal Key Integrity Protocol, WEP-fix): dat a MIC a ICV rámců, RC4, klíč 128b - dvojí hash tajného klíče (104b), pořadového čísla rámce (32b) a MAC a pak výsledku a IV (16b) 802.11i/WPA2 (RSN, Robust Security Network) - 2004, silné šifrování s proměnlivým (při 802.1x) nebo stálým (při PSK) klíčem, volitelná předběžná autentizace (k jinému AP skrze stávající AP, pro rychlý roaming), ukládání klíčů do cache (eliminace EAP při reasociaci, ale hrozba krádeže), bezpečná deautentizace a deasociace (zabrání útokům typu MITM) - šifrování CCMP (Counter-mode CBC (Cipher Block Chaining) MAC (Message Authentication Code) Protocol): jako TKIP, ale silné šifrování AES (Advanced Encryption System), šifrovací klíč 128b se nemění pro každý paket - útoky: falešné AP (falešná deasociace po zfalšování MAC adres, automatická asociace k AP s nejlepším signálem), rušení/zahlcení AP (tzv. jamming) -> DoS, na jednosměrnou autentizaci (EAP-MD5), ARP -> MITM - ochrana: monitorování sítě (rušení, aktivní útoky, falešné AP), IDS, centralizovaný management (autentizace), bezpečnostní audit (simulace útočníka) - obrana: fyzická (zamezení přístupu k AP, omezení šíření signálu), připojení AP k pevné LAN v DMZ, nevysílat (B/E)SSID, přístupový seznam MAC adres, VLAN, nejvyšší možná autentizace a šifrování (WEP < WPA/PSK < WPA2/PSK < WPA/EAP < WPA2/EAP) - PSK s dlouhým komplikovaným heslem, EAP vzájemná s certifikáty, změny klíče/hesla, WPS? - WPS (Wi-Fi Protected Setup): automatická konfigurace klientů na nejsilnější autentizaci a šifrování (po "stisku tlačítka" na AP a zadání PIN na klientech generování SSID a klíčů/hesel a jejich distribuce z AP na klienty) IP a TCP/UDP vrstva =================== - oddělení vnitřních sítí (intranetů) od jiných nebo Internetu - pro zamezení útokům na uzly intranetu, jejich zneužití a krádeži dat Filtrace -------- = kontrola dat procházejících aktivním síťovým prvkem a rozhodnutí o přeposlání (povolení/zakázání), bez změny dat - na základě režijních informací (záhlaví) protokolu, např. adresy (linkové, IP, porty), příznaky (TCP SYN/ACK) aj., příp. dat aplikačního protokolu - provádí firewally - musí porozumět filtrovanému protokolu - typicky vytvoření polopropustného filtru - umožnění plného přístupu (navázání komunikace) z intranetu do Internetu a omezeného přístupu obráceně, u povolených přenos dat obousměrný! - dva přístupy (politiky): 1. něco zakázáno, ostatní povoleno, 2. něco povoleno, ostatní zakázáno, bezpečnější a častější 2. - na linkové vrstvě: na přepínačích, např. přístupový seznam MAC adres vs. portů, VLAN - na síťové (IP) a transportní (TCP/UDP) vrstvě: na (hraničních) směrovačích v rámci předávání paketů (forwarding), pro síť. rozhraní nebo na základě protokolů a informací ze záhlaví (adres) bez ohledu na rozhraní - na aplikační vrstvě: časté změny dat -> proxy, brány IP - na základě IP záhlaví paketu, typicky IP adresy odesílatele, a vybraných volitelných položek (např. explicitní směrování) - na základě ICMP záhlaví - nežádoucí zprávy (např. změna směrování = redirect, echo?) - rozlišení směru přenosu - na směrovači/síť. rozhraní pakety příchozí (ze sítě do směrovače) = ingress traffic a odchozí (ze směrovače do sítě) = egress traffic - specifikace pomocí filtračních pravidel: IP adresy (ne DNS jména - nezabezpečený překlad, útoky na DNS!), rozsahy adres, směr přenosu, vyhodnocení sekvenčně - typicky 1. vyhovující se aplikuje a vyhodnocení končí, na konci výchozí přístup (politika) - na síť. rozhraní blíže k nebezpečné síti (Internetu) - ochrana i samotného směrovače - povolení přenosu po "autentizaci": např. port knocking - útoky: podvržení IP adres příjemce i odesílatele (IP spoofing) -> MITM, DoS, ICMP redirect, DNS spoofing (podvržená IP adresa odesílatele na adresu DNS serveru v intranetu, útočník nepotřebuje odpověď oběti) - obrana: filtrace na základě IP adres odesílatele - doporučení (ingress) filtrace BCP 38 (RFC 2827) a BCP 84 (RFC 3704) dle zdrojových adres, které "nepatří do sítě" (pomocí reverse path filtering), šifrování - zabezpečená VPN, IPsec TCP/UDP - na základě TCP/UDP záhlaví, typicky portu příjemce a u TCP příznaků SYN/ACK, omezení komunikace aplikací na uzlech - kombinace s IP filtrací - IP fragmentace: TCP záhlaví jen v 1. fragmentu, při nefiltrování ostatních jejich zbytečné doručení příjemci, který navíc odešle odesílateli paketu (útočníkovi) ICMP zprávu (o nemožnosti sestavit paket z fragmentů) prozrazující IP adresu příjemce a filtraci -> filtrace všech fragmentů (sledování fragmentů) i ICMP zprávy - filtrace (příchozích) TCP spojení: na základě portu příjemce a nastaveného příznaku SYN/nenastaveného příznaku ACK (1. segment při navázování spojení), na základě "příbuznosti" s povoleným spojením (např. datový FTP kanál na základě řídícího), tzv. related provoz - u povolených spojení povolení ostatního (datového) provozu (nenastavený SYN/nastavený ACK nebo RST), tzv. established provoz - oběma směry!, automaticky vytvořené dočasné pravidlo filtru po dobu spojení (plus timeout, ukončení = nastavený příznak FIN v obou směrech nebo RST v jednom směru), podle 1. (příchozí) nebo 2. (odchozí) segmentu při navazování spojení (stejný protokol, IP adresy a porty) - podobně jako u TCP spojení filtrace výměny UDP datagramů, např. DNS dotaz a odpověď, multimediální služby - útoky: převzetí TCP spojení (connection hijacking) - "uhádnutí" číslování segmentů (není skutečně náhodné) - problém: apl. protokoly využívající další spojení v opačném směru, např. FTP v aktivním režimu -> sledování spojení (connection tracking) pro získání informací ze spojení pro povolení druhého spojení - dočasné pravidlo filtru, potřeba porozumět a sledovat apl. protokol (protocol tracking) TODO: filtrace apl. protokolů, NTP jen na směrovač, ne do intranetu (ten synchronizovat ze směrovače) NAT (Network Address Translation) --------------------------------- = překlad IP adres paketů (popř. i TCP/UDP portů segmentů/datagramů) procházejících směrovačem, RFC 1631, 2663, 2709, 2766, 2993 - původně pro odstranění potřeby přečíslování uzlů při změně sítě, pak výhodné (a nutné) pro ušetření (veřejných) adres - maškaráda - použití téměř výhradně pro IPv4 (ale pro IPv6 je experimentální Network Prefix Translation, NPTv6, dále tunelování Teredo) - v intranetu jiné adresy než v Internetu - typicky z vyhrazeného rozsahu IP adres pro intranety (uzly z různých intranetů spolu přímo nenavazují spojení -> tunel, VPN): 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16 - privátní adresy, nesměrují se do Internetu (filtrace) - funkce hraničních/přístupových směrovačů mezi intranetem a Internetem, pro "skrytí" intranetu z pohledu Internetu a umožnění komunikace s Internetem, popř. pro propojení intranetů, tzv. extranet (bez vlastností VPN), za cenu znemožnění koncové konektivity - carrier-grade/large-scale NAT (CGN/LSN): NAT z privátních adres na veřejné u poskytovatele připojení koncových sítí k internetu -- problém kolize privátních adres z koncové sítě a sítě poskytovatele -> vlastní vyhrazený rozsah pro poskytovatele 100.64.0.0/10 (RFC 6598) - nestandardizované metody překladu, různé (nedokumentované) implementace se specifickým chováním Jednoduchý (základní, one-to-one) = přepisování privátních adres na veřejné u odchozích paketů a opačně u příchozích paketů, 1:1 - Source (SNAT) = přepisování 1) adresy odesílatele u odchozích paketů (z intranetu do Internetu) a 2) opačně adresy příjemce u odpovědí -- pro umožnění komunikace uzlu v intranetu ven - Destination (DNAT) = přepisování 1) adresy příjemce u příchozích paketů a 2) opačně adresy odesílatele u odpovědí -- pro zpřístupnění uzlu (služby) v intranetu zvenku - odpověď z 2) doručena až po paketu z 1)! - uložení adres do převodní tabulky adres - statická nebo (u SNAT) dynamická z rozsahu veřejných adres, potřeba tolik veřejných adres, kolik uzlů v intranetu (u dynamické max. zároveň v Internetu komunikujících) Obr. Jednoduchý NAT [5-34] - použití pro rozložení zátěže (load distribution): přepis na adresu (cyklicky) vybranou z více (u SNAT na sdílenou, "virtuální", u DNAT z) Obr. Použití NAT pro rozložení zátěže [5-37] Rozšířený (one-to-many) = NAPT (NA and Port T, PAT, Port AT) - překlad i TCP/UDP portů segmentů/datagramů. ICMP typicky souvisí s TCP/UDP komunikací - možný přepis mezi více privátními adresami a méně veřejnými - 1:1 přepis dvojic adresa:port = adresa socketu (s rozlišením TCP/UDP), na základě rozšířené převodní tabulky - tzv. maškaráda - dynamický SNAT na (typicky) jednu veřejnou IP adresu směrovače v Internetu (N:1/1:N), s různými porty -> "NAT" Obr. Rozšířený NAT (maškaráda) [5-35] - metody překladu/implementace (SNAT, dle původního protokolu STUN, RCF 3489, viz dále): - full-cone: opakovaný překlad 1) ze stejné privátní adresy socketu na stejnou veřejnou, opačný překlad 2) u odpovědi odkudkoliv - (address-)restricted-cone: jako full-cone, ale jen u odpovědi z cílové IP adresy 1) (na portu nezáleží) - port-restricted cone: jako (address-)restricted-cone, ale jen u odpovědi z cílové adresy socketu (na portu záleží) - symetrický: překlad 1) z privátní (i stejné) adresy socketu na různé cílové pokaždé na unikátní veřejnou, opačný překlad 2) jako u port-restricted - dnešní NATy kombinace, terminologie chování dle RFC 4787 - Endpoint/Address (and Port)-In/Dependent Mapping a Endpoint/Address (and Port)-In/Dependent Filtering aj. (zachování portů, kdy a jak refresh překladu, NAT loopback/reflection/hairpinning + DNAT = použití vnějších adres z vnitřních uzlů, determinismus), nový STUN, RFC 5389 - (bezpečnostní) problém: kontr. součty TCP/UDP z tzv. pseudozáhlaví (obsahující IP adresy a porty) a dat -> sestavení fragmentů (!) a přepočítání, apl. protokoly (a ICMP) přenášející (privátní) adresy a porty z intranetu do Internetu a komunikace na ně (např. příchozí spojení), např. FTP v aktivním režimu -> sledování komunikace (protocol tracking) a (příp. znakový) překlad adres a portů v komunikaci - potřeba porozumět a sledovat apl. protokol - v součinnosti s aplikační bránou (application layer gateway), další např. NAT Port Mapping Protocol, Port Control Protocol v NAT Dvojitý (Illegal NAT, INAT) - při používání existujících (kolidujících) veřejných adres z Internetu v intranetu = překlad (kolizních) veřejných adres v Internetu, popř. i portů, na (interní, dočasné) privátní v intranetu, a NAT - problém u všech apl. protokolů přenášejících (veřejné) adresy a porty z Internetu do intranetu, např. i DNS (odpovědi)! Obr. Dvojitý/Illegal NAT (INAT) [5-36] NAT traversal (NAT-T) - problém a metody pro přímou komunikaci uzlů za (různými) NAT, kdy je na nich potřeba znát veřejnou adresu po NAT (a metodu překladu) - IM (video), VoIP, P2P aj. - přesměrování portů (port forwarding): ~ DNAT - automatické techniky: - vyžadující veřejně (mimo NATy) přístupný server (zprostředkovatele), i pro přenos dat nebo jen pro navázání spojení: hole punching metody - "zneužití" chování NATu vůči různým protokolům, např. STUN (Session Traversal Utilities for NAT), Interactive Connectivity Establishment (ICE), Traversal Using Relay NAT (TURN), ICMP/UDP/TCP hole punching - Hamachi aj., pro TCP potřeba zachování portů odchozích spojení - nevyžadující server: Autonomous NAT-T - pwnat TODO Firewall -------- = dedikovaný systém (SW na směrovačích nebo jiných uzlech nebo HW zařízení) k bezpečnému oddělení vnitřních sítí (intranetů) od jiných nebo Internetu, s omezeným přístupem do vnitřních sítí (a typicky plným opačně), RFC 2979 (nepřesné vymezení, zablokování nebezpečného sledovaného provozu mezi sítěmi) - použití mechanizmů filtrace*, NAT, aplikačních proxy* a bran, VPN aj., příp. využití jiných uzlů (v intranetu) např. pro autentizaci, kontrolu dat (na viry apod.) - z hlediska (TCP) spojení filtr (u filtrace, transparentní) nebo koncový bod (u proxy) - logování událostí, vyvolání akcí na události (např. mail na server v intranetu, zakázání přenosu - do seznamu) - (jako jeden síť. prvek) nerealizuje žádné apl. servery! - rozlišení síť. rozhraní pro intranet (vnitřní) a Internet (vnější), popř. i pro DMZ - filtrace na základě IP adres (odesílatele) pro rozhraní - tzv. demilitarizovaná zóna (DMZ) = samostatná síť oddělená od intranetu i Internetu, "mezi" nimi, např. filtrací s NAT, statické směrování - (omezeně, zabezpečeně) dostupná z intranetu i z Internetu, pro odstranění přímé komunikace mezi intranetem a Internetem - zakázaná nebo vymezená (filtrací, u proxy) spojení do intranetu - obsahuje apl. servery (např. webový, poštovní apod.) - aplikace samotné a DB v intranetu, potřebná data replikovaná/aktualizovaná z DB, ne dotazovaná/operovaná (pokud to není nutné, kvůli útoku na aplikace DB po kompromitaci apl. serveru), nebo proxy pro servery v intranetu - u firewallu se směrovači pro intranet (vnitřní) a Internet (vnější) možné 2 DMZ - vnitřní z Internetu nedostupná (např. pošta, autentizace) a vnější (např. web), různé bezp. požadavky Obr. DMZ [5-42] - s jedním síť. rozhraním přes něj přesměrování (filtrací s NAT) provozu mezi směrovači pro intranet a Internet nebo přes směrovač oddělující obě sítě, tzv. ochranná bašta Obr. Firewall jako ochranná bašta [5-40, 5-41] - více firewallů (firewall on firewall): různé za sebou nebo v intranetu je ještě menší zabezpečenější (pod)intranet (např. centrální servery) - útoky nejen z Internetu, ale i z intranetu - zabezpečení firewallu (jen konzole) a DMZ (šifrovaný přístup) - přístup z Internetu do intranetu: filtrované šifrované apl. protokoly (např. SSH), šifrovaná VPN (např. IPsec) s autentizačním přístupovým serverem (např. RADIUS) - personální firewall = SW pro oddělení/ochrana počítače (typicky PC) od Internetu, s omezeným přístupem do počítače (a plným opačně), součást OS nebo samostatný SW, použití filtrace pro přístup k síť. službám na počítači, prvky IDS/IPS TODO: apl. protokoly VPN (Virtual Private Network) ----------------------------- - privátní síť v jiné (větší) síti, pro přenos dat jen v privátní síti pomocí jiné sítě jako transportní, typicky zabezpečený - přenos dat: - privátní adresace - lib. IP adresy, ne v Internetu, problém oddělení sítí (včetně transportní sítě) - tunel - zapouzdření IP paketů privátní sítě do IP paketů transportní sítě = IP over IP - např. protokol GRE: před zapouzdřeným paketem záhlaví GRE, i jiné protokoly než IP, RFC 1701, IPsec, zapouzdření IP paketů privátní sítě do TCP spojení/UDP datagramů transportní sítě - např. OpenVPN - zabezpečení: IPsec, SSL/TLS, sym. šifrování TODO IPsec ----- - zabezpečení IP paketů, tzn. komunikace mezi uzly sítě, ne mezi aplikacemi nebo uživateli - na úrovni OS uzlu (počítače) nebo hraničního směrovače LAN - RFC 2401-2412, CISCO dříve vlastní standard CET (Cisco Encryption Technology), nástupce protokolů L2TP a PPTP - původně součást IPv6, pak backport pro IPv4 - poměrně složitý => náročná implementace -> podmnožina standardu - režimy zabezpečení: - transportní = zabezpečení datové části paketu specifikované bezpečnostním záhlavím za IP záhlavím paketu - tunelovací = zabezpečení celého paketu vnořeného do nového paketu s bezpečnostním záhlavím - Internet jako přenosové médium např. pro komunikaci mezi intranety, použití u VPN Obr. Režimy IPsec [15-1] - modely komunikace: mezi dvěma koncovými uzly, dvěma (hraničními) směrovači, nebo uzlem a (hraničním) směrovačem - pomocí brány IPsec na směrovačích, pouze u tunelovacího režimu, možné kombinace, např. zabezpečení integritou a autorizací dat mezi uzly a šifrováním mezi směrovači (IPsec v IPsec) - protokoly zabezpečení AH a ESP Protokol AH (Authentication Header) - poskytuje integritu (celého) paketu, autentizaci odesilatele, ochranu proti útoku zopakováním paketu, tzv. replay attack, NE šifrování dat paketu - bezp. záhlaví za IP záhlavím paketu: - číslo 51 jako protokol vyšší vrstvy v IP záhlaví paketu Obr. Bezp. záhlaví protokolu AH [15-4, 15-5] - další záhlaví (1B): číslo zabezpečeného protokolu dat, stejná jako u protokolu vyšší vrstvy v IP záhlaví, např. 1 pro ICMP, 4 pro IP (tunel), 6/17 pro TCP/UDP (transport) apod. - délka záhlaví (1B) : jednotka 4 B, hodnota o 2 (tj. 8 B) menší - pořadové číslo paketu protokolu AH (4B): od 1, proti útoku zopakováním paketu - kontrolní součet (4B): z neměnných nebo předvídatelných polí IP záhlaví, AH záhlaví (součet nastaven 0) a dat (u tunelu celý IP paket) Protokol ESP (Encapsulating Security Payload) - poskytuje navíc oproti AH šifrování dat paketu, integrita dat volitelná - bezp. záhlaví za IP záhlavím paketu a zápatí za paketem: - číslo 50 jako protokol vyšší vrstvy v IP záhlaví paketu Obr. Bezp. záhlaví a zápatí protokolu ESP [15-4, 15-7] - pořadové číslo - stejné jako u protokolu AH - výplň: zarovnání dat na násobek délky bloku blokové šifry, šífrována - délka výplně (1B), další záhlaví (1B) - stejné jako u protokolu AH, šífrované - kontrolní součet (4B) - volitelně, z ESP záhlaví a dat Security Association (SA) - pro ověření, popř. dešifrování, paketu musí příjemce znát zabezpečovací informace (metoda autentizace, sdílené tajemství, algoritmus kontrolního součtu, šifrovací algoritmus, klíč atd.) - specifikace v každém paketu (přenášeny nezávisle na sobě!) by byla neefektivní a nebezpečná => potřeba znát předem! -> Security Policy (SP) = pravidla specifikující typ zabezpečeného přenosu paketů - metoda autentizace druhé strany (na základě dříve vyměněného sdíleného tajemství, certifikátu, protokolem Kerberos aj.) a algoritmy kontrolního součtu (např. MD-5, SHA-1) a (de)šifrování (pro ESP, např. 3DES) pro protokoly AH/ESP, uložená v Security Policy Database (SPD) v konfiguraci obou uzlů - s pravidlem spojený filtr pro odchozí a příchozí pakety, popř. společný, tzv. zrcadlený, pro zabezpečení/ověření paketů podle pravidla - pro každý přenos (určený IP adresami a TCP/UDP porty odesílatele a příjemce a protokolem TCP/UDP) různá sdílená tajemství, šifrovací klíč aj. -> databáze hodnot, pro přenos index SPI (Security Parameter Index) = soubor zabezpečovacích informací pro přenos (zvlášť odchozí a příchozí) určený IP adresou druhé strany, protokolem AH/ESP a indexem SPI -> databáze SA Protokol ISAKMP (Internet Sec. Assoc. and Key Management Prot.) = aplikační protokol pro dynamické naplnění databází SA obou uzlů - port 500/UDP - model komunikace initiator/responder (žádost/odpověď) pro vytvoření SA, dvě fáze: 1. vytvoření SA pro svou (ISAKMP) zabezpečenou další komunikaci - šifrovaná, pro oba směry přenosu, bez indexu SPI 2. vytváření SA pro IPsec (AH/ESP) komunikace - poté možná zabezpečená komunikace pomocí IPsec - protokolem AH/ESP - specifikace formátu výměny zabezp. informací pomocí zpráv: Obr. Paket protokolu ISAKMP [15-11, 15-12] - další záhlaví a délka: typ další zprávy (poslední 0) a délka paketu/zprávy, v záhlaví paketu i každé zprávě - Initiator/Responder Cookie: náhodné číslo pro spárování žádosti a odpovědi, Initiator z žádosti zkopírovaný v odpovědi do Responder - příznaky: Encryption - následující pakety šifrovány, Commit - synchronizace při výměně klíčů, aj. - identifikace zprávy: ve fázi 1 0, ve fázi 2 náhodná pro odlišení dialogů pro vytvoření SA - zprávy: NONE (0), Security Association (1, vyjednání aut. metody, algoritmů kontr. součtů a šifrování aj., využití ISAKMP i pro jiné protokoly než IPsec), Proposal (2, vnořeny do 1, nabídka metod, algoritmů aj., pro protokol ISAKMP/AH/ESP, obsahuje index SPI), Transform (3, vnořeny do 2 v žádosti seřazené podle preference, v odpovědi zvolená, metoda, algoritmy, pseudonáhodná funkce, doba platnosti a délka klíče aj. v tzv. atributech SA typ-hodnota, např. [474-475]), Key Exchange (4, info pro vytvoření šifrovacích klíčů, u IPsec veřejné DH číslo odesilatele), Identification (5, identifikace odesilatele pro protokol vyšší vrstvy a port TCP/UDP, např. IP adresa, DNS jméno, email, subsíť aj.), Certificate (6, certifikát odesilatele), Certificate request (7, žádost o certifikát druhé strany, identifikace CA), Hash (8, kontr. součet ze zpráv a náhodného čísla), Signature (9, el. podpis zpráv), Nonce (10, náhodné číslo), Notification (11, chybový kód), Delete (12), Vendor ID (13) - vlastní výměna a obsah zpráv (SPI, atributy SA, DH číslo, ID, certifikát, součet/podpis z jakých zpráv aj.) pomocí "realizačního" protokolu IKE (ISAKMP je část IKE) Protokol IKE (Internet Key Exchange) - 1. fáze: vytvoření zabezpečeného ISAKMP kanálu (SA) ve 2 krocích: 1. dohoda na aut. metodě, algoritmech kontr. součtu a šifrování aj. - zpráva Security Association s vnořenými zprávami Proposal a Transform, a výměna veřejných DH čísel - zprávy Key Exchange a Nonce, vytvoření šifrovacího klíče a dále šifrovaně 2. vzájemná autentizace - zprávy Identification, (Certificate,) Hash/Signature, Nonce, el. podpis pseudonáhodnou funkcí ze sdíleného tajemství z DH algoritmu, zpráv Security Association a Identification aj., indentifikační data (např. DNS jméno) musí odpovídat datům v certifikátu (pro uzel) - tzv. agresivní režim: v žádosti zpráva Identifikace v 1. kroku a vše v 1 paketu, v odpovědi vše v 1. kroku v 1 paketu, 2. krok nešifrovaný Obr. 1. fáze protokolu IKE [15-22/15-23] - 2. fáze: vytváření zabezpečených IPsec (AH/ESP) kanálů (SA) - také obnovování ISAKMP/AH/ESP SA (šifr. klíčů) po vyčerpání času nebo množství dat, zprávy Hash, Security Association, Nonce Obr. 2. fáze protokolu IKE [15-24] - metoda PFS (Perfect Forward Security): při obnovování SA i zprávy Key Exchange (nová DH čísla) a Identification (reautentizace) z 1. fáze, vyšší bezpečnost, ale i režie (pozastavení přenosu) Aplikační vrstva ================ Proxy ----- = služba "prostředníka" mezi komunikujícími uzly - klientem a serverem, s rozhraními ke klientům (v intranetu) a serverům (v internetu) - často v rámci firewallu intranetu v DMZ - servery nebo aplikační služby nemusí být v/z intranetu dostupné - znalost aplikačního protokolu -> aplikační proxy, např. HTTP (rozmach proxy, funkce proxy přímo v protokolu) - části: serverová - vůči klientovi jako server, často na jiném portu (např. 8080 pro HTTP), vlastní proxy, klientská - vůči serveru jako klient, automaticky požadavky "ve jménu" původního klienta - manipulace s požadavky klienta a daty přenášenými mezi klientem a serverem - autentizace klienta (před použitím proxy, i jen IP adresa, popř. pomocí wrapperu), autorizace (i přístupu na server), filtrace ("obsahu", i klientů a serverů, požadavek z vnitřní nebo vnější sítě), kontroly a modifikace - příp. v součinnosti s nějakou jinou službou - cache požadavků a odpovědí serveru a vyřizování z ní stejných požadavků (i od jiného klienta) - problém aktuálnosti odpovědí (dynamický obsah, stavovost, zabezpečení dat), využití proxy i jen jako cache - pro "opačné" použití, klient v internetu a server v intranetu, nahrazena VPN (bránou) Obr. Činnost (HTTP) proxy [5-17] - lokální: aplikace na klientovi, typicky kvůli cache - řetězení více (proxy on proxy), např. mezi (vnitřním) intranetem a Internetem - útoky: falešná proxy, na ni změna konfigurace na klientovi, lokální proxy jako trojský kůň - některé apl. protokoly pracují jako proxy, např. SMTP (a NNTP, poštovní server/doménový koš pro intranet), NTP (časový server pro intranet), DNS (rekurzivní DNS servery - resolvery) - přesto v rámci firewallu (DMZ) jejich proxy, server v intranetu nebo také v DMZ (např. na jiném portu jen pro localhost) - klasická: klient explicitně komunikuje s proxy (místo přímo se serverem), prostředky proxy klientovi pro zahájení komunikace se serverem ("rozšíření" apl. protokolu), např. příkaz (connect), např. pro Telnet, FTP, HTTP (znakové protokoly, snadno rozšiřitelné) - generická: klient explicitně komunikuje s proxy (místo přímo se serverem), jednoduchá, klientská část proxy pevně nastavena na konkrétní server (IP adresa a port parametry spuštění, pro více serverů více proxy), často i pro UDP, např. pro POP, IMAP, SSH, LDAP (neumožňující rozšíření) - transparentní: RFC 1919, klient (předpokládá že) komunikuje přímo se serverem, ale komunikace je směrována přes (jednu!) proxy - pro klienta představuje původní server, info o něm (IP adesa a port) pro klientskou část z komunikace s klientem nebo zmanipulované, z pohledu klienta jako (příp. filtrující) směrovač, z pohledu serveru klasická proxy, pro lib. protokol SOCKS - odstranění samostatných proxy pro jednotlivé apl. protokoly - řešení autentizace klienta (příp. s autorizací) a "přepojení" komunikace mezi klientem a serverem = vytvoření proxy = obecná proxy pro všechny apl. protokoly Obr. SOCKS [5-19] = protokol pro komunikaci klienta se SOCKS-serverem (serverová část SOCKS proxy) - verze 5, RFC 1928, v řídícím kanálu (1080/tcp): - dohoda na autentizační metodě - klient nabídne, server vybere nebo zamítne, i šifrování a el. podpis (např. při přístupu z Internetu do intranetu) - volitelná autentizace - žádná nebo jen IP adresa, jméno a heslo, jednorázové heslo, včetně příp. přípravy šifrování a el. podpisu pro další komunikaci - vytvoření proxy - klient pošle IP adresu/DNS jméno a port cílového serveru - příkazy CONNECT pro TCP (nebo BIND pro aktivní FTP s alokací portu na proxy pro server), ASSOCIATE pro UDP, proxy v případě TCP se serverem zahájí komunikaci (u aktivního FTP opačně po příkazu od klienta) a v odpovědi pošle IP adresu a port datového kanálu pro zprostředkovanou komunikaci (u aktivního FTP nejprve IP adresu a port pro server a pak IP adresu a port serveru), v případě UDP případně doplňuje IP adresu serveru v záhlaví celého datagramu z DNS jména v SOCKS záhlaví před datagramem (pokud klient není překladu schopen) - vytvoření datového kanálu - po zahájení komunikace klienta na předanou adresu a port Obr. SOCKS protokol (příkaz CONNECT) [5-24] - klientské knihovny - obdoba std. knihoven Socket API, funkce s prefixem R - WIN SOCKS TODO 158 Brána (gateway) --------------- = proxy, která "mění" aplikační protokol mezi serverou a klientskou částí -> brána pro cílový protokol, např. z HTTP na FTP - "překlad" požadavku klienta a odpovědi serveru a často i dat mezi protokoly Tunel ----- = proxy, která nemusí znát aplikační protokol => žádná manipulace s daty přenášenými mezi komunikujícími stranami, bez cache - "kanál" mezi komunikujícími stranami - propojení komunikací částí tunelu s klientem a serverem, často šifrovaný - přenášená data (transparentně) šifrovaná, např. SSL/TLS, SSH - požadavky z klienta na server ne automaticky - prostředky tunelu klientovi pro zahájení komunikace se serverem, např. příkaz (connect), v rámci připojení k tunelu aj. - použití: "propašování" filtrovaných protokolů v intranetu (lokální síti) skrze tunel mimo intranet používající nefiltrovaný protokol, např. HTTP(S), DNS, zpřístupnění uzlů a služeb nepřístupných v intranetu skrze tunel mimo intranet aj. - SSH tunely - lokální: typicky kvůli šifrování PKI (Public Key Infrastructure) =============================== = soustava technických a organizačních opatření spojených s vydáváním, správou, používáním a odvoláváním platnosti šifrovacích klíčů a certifikátů - aplikace asym. kryptografie - normy ITU-T X.500, např. X.509 pro certifikáty, pro využití na Internetu (tzv. internetový profil) RFC 3279-81 - vychází z X.500, dále např. normy pro bezpečnou transportní službu (SSL/TLS), el. poštu (S/MIME) aj. - i jiné aplikace asym. kryptografie než PKI, např. SET pro platby platebními kartami na Internetu Certifikát ---------- = struktura obsahující identifikační údaje uživatele (předmětu certifikátu, např. i aplikace/serveru aj.), jeho veřejný klíč, identifikační údaje vydávající CA, sériové číslo, dobu platnosti a další, např. vymezení způsobu použití, dig. podepsaná CA - obsahuje identifikace algoritmů pro kontrolní součet a asym. šifru + vlastní podpis - v jazyce ASN.1 (Anstract Syntax Notation) definujícím typy objektů (např. čísla/ID, řetěce bitů/čísel/znaků, true/false, sekvence, množina, čas, odvozené, výběr, cokoliv aj., specifikované číslem, tzv. tag) pro přenos v kódování DER (Distinguished Encoding Rules) - podmnožina kódování BER (Basic Enc. Rules) bez uvádění výchozích hodnot pro kódování ASN.1 do bitové reprezentace (big endian) Př. Certifikát v jazyce ASN.1 a kódování DER [257, 258-1, 258-2] - typicky uložen v kódování Base64 do ASCII (7bit) -- tzv. "PEM/CER formát", úvodní řádek ---BEGIN CERTIFICATE---, koncový ---END CERTIFICATE--- Př. Certifikát v kódování Base64 v PEM/CER formátu [258-3] - pro Internet RFC 1421-24 (PEM, 1993), 2459, dnes 3280 (spolu s CRL), odvozené od ITU X.509 (1988, verze 1 až 3), dále RFC 3279 pro algoritmy a 3281 pro atributové certifikáty pro autorizaci - i jiné formy certifikátů než dle X.509, např. EDI - (podepsané) položky: - verze: implicitně 1, dnes 3 - sériové číslo: jednoznačné v rámci CA, spolu s položkou vydavatel certifikát jednoznačně identifikuje, až 20 B nezáporné číslo - algoritmy podpisu: stejná identifikace jako ve struktuře certifikátu, např. md5withRSAEncryption - vydavatel: identifikační údaje vydávající CA = jedinečné jméno (distinguished name, DN, dle X.501) CA = posloupnost relativních jedinečných jmen (RDN) = (typicky jednoprvková) množina dvojic identifikátor objektu/atribut (z hierarchické adresářové struktury, např. Country/C, Organization/O, Organizational Unit/OU, State/Province/SP, Common Name/CN, Domain Component/DC aj., pro rozlišení stejných DN pro různé objekty atributy DNQualifier a SerialNumber, použití závisí na aplikaci, certifikační politice CA apod.) a řetězec (UTF-8), např. Country=CZ, Organization=Prvni certifikacni autorita, a.s., Common Name=I.CA - platnost: doba platnosti od-do včetně, důvody bezpečnostní (omezená doba bezpečnosti šifry, pro CA delší než u vydávaných uživatelských), organizační (omezená životnost aplikace/účelu užití), po vypršení se nepoužívá certifikát/soukr. klíč k šifrování/podpisu, ale soukr. klíč/certifikát k dešifrování/ověření ano -> přešifrování/přepodepsání, také rozšíření doba platnosti soukr. klíče (kratší, pro podpis) - předmět: identifikační údaje uživatele (nebo aplikace/serveru aj., držitele certifikátu) = jeho DN, kopírované z žádosti o certifikát, jedinečné v rámci CA, např. C=CZ, O=UPOL, CN=www.inf.upol.cz, další údaje např. v rozšířeních nebo atributovém certifikátu, u certifikátů kořenových CA stejné jako DN v položce vydavatel - info o veřejném klíči: identifikace algoritmu, pro který je veřejný klíč určen, např. rsaEncryption, a veřejný klíč (bitový řetězec) - unikátní ID vydavatele: nestačí-li položka vydavatel, volitelně od verze 2, doporučeno nepoužívat - unikátní ID předmětu: nestačí-li položka předmět, volitelně od verze 2, doporučeno nepoužívat - rozšíření: volitelně od verze 3, posloupnost trojic identifikátor, kritičnost (výchozí ne, certifikát odmítnut, pokud aplikace kritické rozšíření nezná, např. u SET proti použití v SSL/TLS) a hodnota (bajtový řetězec, často aplikačně strukturovaná), např. ID klíče CA (soukr. použitého pro podpis certifikátu, pro ověření certifikátu CA obnovuje klíče/certifikát nejméně takovou dobu před vypršením, na jakou vydává certifikáty, ale vydavatel stejný) a předmětu (při více veř. klíčích, např. kontrolní součet klíče, u certifikátu CA stejné jako předchozí), doba platnosti soukr. klíče (v RFC 3280 zakázané), (rozšířené) použití klíče (omezení způsobů použití/účelu veř./skour. klíče, např. na podpis dat/certifikátů/CRL, ověření podpisu, šifrování sym. klíčů/dat aj., musí být u podpisových certifikátů, rozšířené pro server, klienta, podpis kódu, čas. razítka, e-mail aj.), alternativní jméno předmětu (typicky email nebo DNS jméno, také URI, IP adresa aj.) a vydavatele (CA), certifikační politiky (pravidla CA pro vydávání certifikátů, ID objektů politik, např. kvalifikovanost, URI na dokumenty, poznámka o použití certifikátu aj., mapování politik mezi CA), omezení (pouze u certifikátů CA, základní, např. certifikát CA nebo uživatelský proti vydávání se za CA, max. počet CA pod certifikátem, jména, DN nebo alternativní předmětu, např. na DNS doménu, politiky), distribuční místa (přírůstkového) seznamu odvolaných certifikátů (seznam URI s důvody odvolání a jmény CA), subject directory attributes (pro vyznačení uživ. práv, typicky vnitřní ID uživatele v přistupovaném systému, kde jsou uložena práva), přístupové informace CA/předmětu (jen RFC 3280, URI pro online služby CA, např. zjišťování platnosti certifikátu, politiky CA, repozitář certifikátů apod.), šablona (jen MS, např. pro přihlašování se), aj. Kvalifikovaný certifikát - použití v legislativě EU pro el. podpis právně nahrazující podpis rukou, v ČR zákon o el. podpisu - pro státní správu vydávány jen kvalifikovanými/akreditovanými CA (kořenové!): I. CA, PostSignum (Česká pošta), eIdentity - jen pro osoby, obsahuje oficiální identifikaci - jednoznačný předmět (jméno nebo pseudonym), pro rozlišení atribut serialNumber, v různých certifikátech různé veř. klíče (=> archivace u CA, zamítnutí žádosti se stejným z platného certifikátu), v rámci CA - základ v RFC 3039: povolené atributy DN vydavatele a předmětu (držitele, uvedené, plus např. givenName, surName, pseudonym, postalAddress, pkcs9mail aj.) a rozšíření (v "subject directory attributes" osobní údaje např. titul, datum a místo narození, pohlaví, občanství aj., kritické a povinné "použití klíče" -> 3 certifikáty jen pro podpis - kvalifikovaný, ověření podpisu a šifrování proti zneužití na jiný učel), nová rozšíření biometrické informace (jen kontrolní součty z biometrických vlastností držitele a volitelně URI na ně, např. foto, sken podpisu rukou, sken prstu) a příznaky kvalifikace (ID registrační autority, další ze zákona a vyhlášek) Odvolání certifikátu - uživatelem (popř. jinou zmocněnou osobou) nebo samotnou CA, při ztrátě nebo vyzrazení soukr. klíče co nejrychleji! - žádost na CA, resp registrační autoritu (RA) = zprostředkovatel CA - v cert. politice CA, např. el. podepsaný (soukr. klíčem k odvolávanému certifikátu) e-mail => ne při ztrátě klíče nebo když certifikát není určen k podpisu - jednorázové heslo při vydání certifikátu, jinak osobně (s doklady) na RA/CA, jinak otázky a odpovědi typu rodné jméno matky apod. (v DB RA/CA) - odvolaný certifikát je neplatný, na seznamu odvolaných certifikátů Seznam odvolaných certifikátů (Certificate Revocation List, CRL) - veřejně vydává CA nebo pověřená autorita (tzv. nepřímý CRL) - způsob v cert. politice, např. web (URI v rozšíření certifikátu "distribuční místa CRL") - vydáván v pravidelných intervalech => účinnost až s následujícím CRL -> protokol OCSP - obsahuje sériová čísla odvolaných certifikátů až do vypršení jejich původní doby platnosti - norma RFC 3280 vycházející z X.509 verze 2 jako pro certifikáty, stejná forma (el. podepsaná struktura, v Base64 řádky ---BEGIN/END X509 CRL---), (podepsané) položky: - verze: 1, algoritmy podpisu a vydavatel stejné jako u certifikátu - čas vydání, max. čas vydání následujícího CRL - seznam odvolaných certifikátů: pro každý jeho sériové číslo (spolu s "vydavatel" jednoznačná identifikace), čas žádosti o odvolání a volitelně rozšíření: stejná forma jako u certifikátu, např. důvod odvolání (např. nespecifikovaný, kompromitace klíče/CA, nahrazení aj.), instrukce při odvolání (např. nic, odmítnout aj.), čas kompromitace soukr. klíče, vydavatel (u nepřímých CRL pro jiné CA než "vydavatel", nebo při změně předmětu CA) - rozšíření: stejná forma jako u certifikátu, např. ID klíče CA a alternativní jméno vydavatele (CA) stejné, dále číslo CRL (vzestupně po 1), přírůstkové CRL (odvolané certifikáty od kompletního CRL určeného číslem), distribuční místo CRL (CRL není kompletní, URI kompletního aj.) Zjišťování platnosti certifikátu - u odvolaného dřív než bude na CRL, pro ochranu před jeho použitím např. při zneužití kompromitovaného soukr. klíče, nebo při velkém CRL - služba CA (popř. delegovaná), protokol OCSP (Online Certificate Status Protocol): klient/server např. nad HTTP(S) (pro dotaz < 255 GET URI/dotaz, jinak POST, kódován DER, u GET ještě Base64, Content-Type Application/ocsp-request/response), URI serveru z konfigurace klienta nebo v rozšíření "přístupové informace CA" certifikátu, metoda OneCRL? - dotaz na platnost certifikátů - volitelně el. podepsaný (server může nepodepsané odmítnout) s ID klienta, certifikáty identifikovány sériovým číslem a kontr. součty DN a veř. klíče CA - odpověď s platností/odvoláním certifikátů - při statutu "successful" el. podepsaná klíčem k certifikátu serveru (CA, "rozšířené použití klíče" pro OCSP podpis, nebo u klienta), obsahuje ID serveru (DN nebo kontr. součet veř. klíče), čas odpovědi, info o platnosti certifikátů (pro každý identifikace, status platný/odvolaný/neznámo, u odvolaného čas a důvod odvolání, čas, od kterého je statut, např. čas vydání CRL, a do kdy bude novější statut), v případě odvolání certifikátu CA neplatné všechny certifikáty jí vydané Žádost o certifikát - formát PEM dle RFC 1424 se neujal Formát PKCS#10 - obsahuje veř. klíč, el. podepsaná soukr. klíčem k veř. klíči - ověření podpisu i jako důkaz vlastnictví soukr. klíče, nepodepsané RA/CA neakceptuje => nevhodný pro certifikáty neurčené pro ověření el. podpisu, např. šifrovací - u následného certifikátu při použití starého klíče k el. podpisu (jako ID žadatele) vložení žádosti (podepsané novým klíčem) do zprávy protokolu CMS podepsané starým klíčem - RFC 2314, stejná forma jako certifikát (el. podepsaná struktura), v Base64 řádky ---BEGIN/END CERTIFICATE REQUEST--- ("ve formátu PEM"), (podepsané) položky: - verze: 0 - předmět: jako v certifikátu, kopírované do certifikátu - info o veřejném klíči: jako v certifikátu - atributy: volitelné, např. challengePassword s jednorázovým heslem pro odvolání certifikátu Formát CRMF (Certificate Request Message Format) - u šifrovacích certifikátů nepodepsaná: např. u Diffie-Hellmanova není soukr. klíč, ale "jen soukr. DH číslo", možnost generování dvojice klíčů až CA, po obdržení žádosti o certifikát - RFC 2511, struktura s vlastní žádostí o certifikát, důkazem vlastnictví soukromého klíče k veřejnému v žádosti a volitelnými dodatečnými informacemi, např. kontakt na žadatele nebo účtovací údaje - důkaz vlastnictví soukromého klíče: pro podepisovací certifikát (k ověření el. podpisu) el. podpis žádosti jako u PKCS#10, u šifrovacího vydaný certifikát zašifrovaný certifikovaným veřejným klíčem (možnost předat i soukr. klíč pro archivaci u CA), uživatel dešifruje a vrátí CA, nebo již ověřeno RA - (příp. podepsaná) žádost: - číslo požadavku: pro spárování s odpovědí - všechny položky ze struktury certifikátu: jako šablona, volitelné, při chybějícím veřejném klíči generovaný CA - atributy: např. jednorázové heslo pro vydání certifikátu obdržené při předchozím ověření totožnosti žadatele RA/CA, pro odvolání certifikátu aj., možnosti zveřejnění certifikátu, podmínky archivace soukromého klíče u CA, ID obnovovaného certifikátu, klíč CA použitý pro zabezpečení některých položek žádosti Komunikace uživatele s CA/RA ---------------------------- Protokol CMP (Certificate Management Protocol) - vydání, obnovení, odvolání (tj. správa) certifikátů, předání CRL aj. - přenáší žádosti o vydání a odvolání certifikátu, certifikáty, CRL atd. - průběh vydání certifikátu: uživatel odešle žádost o certifikát na RA, autentizace uživatele s ověřením vlastnictví soukromého klíče - aut. dotaz RA + odpověď, žádost CA, odpověď CA s certifikátem nebo chyba, potvrzení RA, přeposlání certifikátu uživateli, potvrzení přijetí Obr. Protokol CMP - vydání certifikátu [8-11] - zprávy přenášeny TCP (port 829), HTTP (MIME typ application/pkixcmp), e-mailem (kódovány Base64) - zpráva/paket: záhlaví, tělo, ochrana a volitelně další certifikáty (např. CA pro ověření vydaného certifikátu) - záhlaví: verze, jedinečné jméno (DN) odesilatele a příjemce, čas vytvoření zprávy, algoritmus ochrany, ID klíče odesílatele a adresáta, ID transakce, měněné řetězce odesilatele a příjemce pro obranu před útokem zopakováním (replay attack), zpráva pro člověka (čitelná) a počítač - tělo: (jedno z) žádost+odpoveď o certifikát a obnovení certifikátu (PKCS#10, CRMF, v odpovědi certifikát, příp. šifrovaný, u CRMF číslo odpovědi, volitelně certifikáty CA, vygenerovaný zašifrovaný soukr. klíč. v případě generování klíčů CA), obnovení klíčů (u ztracených klíčů generovaných CA), odvolání certifikátů (položky certifikátu, důvod, datum a čas nedůvěryhodnosti, rozšíření CRL, v odpovědi status, ID odvolaných certifikátů, CRL), vydání nového certifikátu CA (starý podepsaný novým, nový podepsaný starým a u kořenové nový podepsaný novým), nabídka certifikátu, CRL a odvolání certifikátu CA, dotaz na vlastnictví soukr. klíče + odpověď, potvrzení, vnořená zpráva, aj., status odpovědi se specifikací chyby - ochrana: zajištění integrity zprávy, např. kontrolním součtem ze záhlaví a těla, se sdíleným tajemstvím, el. podepsaným aj., chráněné zprávy uživatele po kontrole vnořené do chráněných (podepsaných) zpráv od RA k CA Použití certifikátů pro el. podpis a šifrování dat - protokoly PKCS#7 a CMS --------------------------------------------------------------- - další použití (v Internetu): zabezpečení nezabezpečeného apl. protokolu (SSL/TLS), virtuální privátní sítě (IPsec, OpenVPN), el. podpis kódu - PKCS#7 (RSA, RFC 2315) nahrazen CMS (Cryptographic Message Standard, RFC 2630, 3369) - el. podpis, šifrování a autorizace dat - vstupní i výstupní data určena dvojicí ID typu dat a data (nepovinná, např. externí podpis, distribuce certifikátů) - typicky el. podpis následovaný šifr. el. obálkou (vstupem podepsaná data) Obr. Proces CMS [8-15] - výstupní data kódována DER a Base64, formát PKCS#7 - typy dat (PKCS#7): Data - lib. data, vstupní pro další typy Signed Data - el. podepsaná data, i více podpisů nebo žádný (pro distribuci certifikátů a CRL), prázdná data pro distribuci certifikátů a CRL (PKCS#7 i jako formát exportu certifikátů, i se soukr. klíčem PKCS#11/PFX) nebo externí podpis = data mimo, např. u el. pošty, položky struktury: verze (1 pro PKCS#7, 3/4 pro CMS), algoritmy pro kontr. součet, podepisovaná data (typ a data), certifikáty a CRL (nepovinné, pro ověření podpisu), el. podpisy dat, příp. i tzv. podepisovaných atributů (např. kontr. součet podepisovaných dat, jejich typ, datum a čas podpisu) - položky struktury podpisu: verze, ID podepisujícího (DN CA a číslo certifikátu nebo ID klíče), alg. pro kontr. součet, podepisované atributy (ID typu + hodnoty), alg. podpisu vč. parametrů, podpis (kontr. součet z podepisovaných dat a příp. podepisovaných atributů), nepodepisované atributy (volitelné, např. kontrapodpis - "podpis z podpisu", struktura podpisu) Enveloped Data - data v el. obálce, šifrovaná 1. náhodným sym. klíčem šifrovaným veř. klíči z certifikátů příjemců (PKCS#7), 2. sym. klíčem vytvořeným z veř. klíče příjemce a soukr. klíče odesilatele (Diffie-Hellman, příjemce vytvoří sym. klíč z veř. klíče odesilatele a svého soukr. klíče), 3. náhodným sym. klíčem šifrovaným sym. klíčem předchozích dat (první distribuován jinak), položky struktury: verze (0 pro PKCS#7, 2/3 pro CMS), info o odesilateli (pro 2., certifikáty odesilatele příp. s CRL), informace pro adresáta (pro každého), šifrovaná data (typ, šifrovací alg. a data), nezabezpečené atributy (volitelné), struktura informací pro adresáta - verze (0 pro 1./PKCS#7, 3 pro 2., 4 pro 3.), ID certifikátu příjemce (DN CA a číslo certifikátu nebo ID klíče) pro 1. nebo ID předchozího sym. klíče pro 3., šifrovací alg. a šifrovaný sym. klíč Obr. Vytvoření elektronické obálky 1. [8-23] Digested Data - data s kontr. součtem, položky struktury: verze, alg. pro kontrolní součet, data Encrypted Data - data šifrovaná jinak, použití např. pro uložení soukr. klíče na disk, správa šifr. klíčů jinak, položky struktury: verze, data (typ, šifrovací alg. a data), nezabezpečené atributy (volitelné) Authenticated Data (jen CMS) - autorizovaná data, autentizace místo podpisu (asym. šifr. alg. neumožňuje, nepodepisovací certifikát aj.), autorizace pomocí náhodného sdíleného tajemství (kontr. součet z dat a tajemství) šifrovaným veř. klíči z certifikátů příjemců, položky struktury: verze (0), info o odesilateli (volitelné, jako u Enveloped Data), informace pro adresáta (pro každého, jako u Enveloped Data, jen sdílené tajemství místo sym. šifr. klíče), alg. kontr. součtu, alg. kontr. součtu při autorizovaných atributech (součet je atribut a kontr. součet předchozím alg. z atributů), data, autorizované atributy (volitelné), kontr. součet, neautorizované atributy (volitelné) - ve zprávě mouhou být certifikáty v řetězu důvěryhodnoti až ke kořenovému včetně => útok podvržením! -> kořenový nedůvěryhodný Protokol CMC (Certificate Management Messages over CMS) - stejný účel jako CMP, tj. komunikace uživatele s CA/RA pro vydání, obnovení, odvolání (tj. správa) certifikátů, předání CRL aj., také u šifr. certifikátů žádost CA o zaslání ztraceného soukr. klíče z archivu CA - zabezpečení (úplných) zpráv pomocí CMS - vstup od uživatele struktura PKIData (tělo zprávy), výstup el. podepsaná struktura příp. v el. obálce (pro CA, příp. i RA), odpověď od CA obdobně zabezpečená struktura ResponseBody - krátká zpráva: ne struktury PKIData a ResponseBody, žádost o vydání certifikátu jen PKCS#10, odpověď s certifikátem vč. certifikátů CA, příp. CRL, v CMS Signed Data bez dat a podpisu - nelze zamítavá odpověď - úplná zpráva: žádost o vydání certifikátu PKCS#10 i CRMF, příp. i bez podpisu (podpis je v rámci CMS) = struktura PKIData, podpis v rámci CMS soukr. klíčem k certifikovanému veř. klíči, odpověď s certifikáty a CRL (nebo chyba) podepsané v rámci CMS soukr. klíčem CA (popř. i RA) TODO 308-315 - položky PKIData: 4 posloupnosti částí, každá část má ID - položky ResponseBody: - zprávy v CMS přenášeny HTTP (MIME typy application/pkcs10, application/pkcs7-mime, přípony souborů .p10, .p7m, .p7c) nebo e-mailem (kódovány Base64), přímo (v BER kódování) jako soubory .crq (struktura PKIData) a .crp (struktura ResponseBody) Transport certifikátů a CRL - protokoly CMP, CMC - vyžaduje klientský SW - HTTP/FTP - např. URI v rozšíření certifikátu pro distribuční místa (přírůstkového) CRL, MIME typ application/pkix-cert a přípona souboru .cer pro certifikát a application/pkix-crl a .crl pro CRL TODO: časová razítka - protokol TSP, validace dokumentů a podpisů - protokol DVCSP, atributové certifikáty - obdoba např. průkazu ke vstupu, id. údaje z občanského průkazu (uživ. certifikátu) a přístupová práva Bezpečná pošta - S/MIME ----------------------- - Secure/Multipurpose Internet Mail Extension, verze 2 RSA, MD-5, PKCS#7, verze 3 CMS, RFC 2632, 2634 - zabezpečení el. pošty na apl. vrstvě (samotného emailu) = zpráva CMS (v Base64) v MIME - typy Data, Signed Data (jen PKCS#7), Enveloped Data, podepisované atributy kontr. součet podepisovaných dat, jejich typ, datum a čas podpisu, alg. podporované odesilatelem (ID + parametry) a DN CA a číslo certifikátu nebo ID klíče pro šifrování příjemcem a přidaného k podepsanému mailu v případě, že je jiný než podepisovací (např. kvalifikované nelze použít k šifrování), u Enveloped Data položka info pro adresáta i pro odesílatele - pro dešifrování tohoto odeslaného emailu - email podepsaný, v (šifrované) el. obálce nebo obojí - podepsaný celý S/MIME v obálce (opačně nepraktické) - emailová adresa ve From: (Sender:) musí u podepsaného mailu být v podepisovacím certifikátu, v To:, Cc: apod. u šifrovaného mailu v el. obálce v šifr. certifikátu, v předmětu nebo (lépe, lze více) rozšíření alternativní jméno předmětu, další vyžadovaná rozšíření, ostatní nekritická - typ MIME application/(x-)pkcs7-mime, volitelné parametry name pro jméno souboru (také filename v hlavičce Content-Disposition), typicky smime.p7m, popř. .p7c pro mail pouze s certifikáty nebo .p7s pro podpis typu application/(x-)pkcs7-signature v kompozitní typu multipart/signed (viz dále), smime-type pro typ emailu (signed-data/enveloped-data/certs-only) - kompozitní typ MIME multipart/signed pro podepsané maily (RFC 1847, multipart/encrypted pro maily v el. obálce se nepoužívá), krypt. protokoly protocol=typ/subtyp, např. application/(x-)pkcs7-signature, alg. pro kontr. součet micalg=alg. (např. SHA1), části pro text mailu (v ASCII nebo Base64 nebo quoted-printable) a externí podpis (CMS Signed Data s prázdnými daty; u multipart/encrypted info o šifr. klíčích a šifrovaný text) Obr. El. podepsaný mail [10-1, 355-356] a šifrovaný mail [368] Rozšířené S/MIME - ESS (Enhanced Security Services for S/MIME) - rozšíření v atributech el. podpisu, RFC 2634 - u některých (vnější) podpis (vnitřně) podepsaného emailu v obálce - žádost o doručenku: příjemce vrací po úspěšné verifikaci podpisu (a příp. dešifrování emailu) el. podepsanou doručenku (doručenky přijetí poštovním serverem příjemce a otevření emailu příjemcem nejsou podepisované), její vrácení ale není zaručeno = není (bezpečně) potvrzeno přijetí emailu (příjemce může zapřít), podepisované položky: generované ID pro spárování doručenky s emailem s žádostí, adresáti, od kterých je požadována doručenka (všichni, všichni přímí, ne např. z konference, seznam - specifikace* jako u alternativního jména předmětu u certifikátu), adresy odesilatele (*), na které vrátit doručenku (adresa ve From: nebo SMTP From není podepsaná), doručenka v CMS zprávě typu Signed Data (typ Signed Data/Receipt), položky struktury: verze (1), zkopírované ID pro spárování, podpis (hash) z původního emailu, volitelně podepisovaný atribut s kontr. součtem z podepisovaných atributů původního emailu - pokyny ke zpracování: textové info v případě el. podepsaného zašifrovaného emailu (v el. obálce), obdoba předmětu emailu - bezpečnostní návěští: info o charakteru utajení dat ("tajná data"), pro aplikace bezp. kategorie B, podepisovaný - bezpečné konference: (podepsaný a) šifrovaný (v el. obálce) email s využitím veř. klíče konference, ale členové nemají její soukr. klíč -> konference dešifruje sym. klíč a každému členovi jej přidá do emailu zašifrovaný jeho veř. klíčem (v rámci dalších informací pro adresáta v el. obálce) - potřeba certifikátu člena, emaily členům podepsané (vnější podpis) s atributem se seznamem ID konferencí, kterými zpráva prošla (DN CA a číslo certifikátu konference nebo ID klíče, datum a čas odeslání emailu konferencí, volitelně omezení vracení doručenek na některé/jiné/žádné adresáty) - obrana před cyklickým rozesíláním emailu konferencemi, další konference podpis "zahodí" (podepisovaná el. obálka je rozšířena), ale vezmou se z něj podepisované atributy Obr. Bezpečné konference [10-5] - certifikát k ověření podpisu: ID podepisujícího (DN CA a číslo certifikátu nebo ID klíče) pro ověření podpisu je ve struktuře podpisu, ale není podepisováno (součást dat podpisu) - možné přepsat a přidat nepovinné podvržené certifikáty (pro ověření) -> podepsaný atribut se seznamem ID certifikátů pro ověření podpisu (kontr. součet z certifikátu, volitelně i DN CA a číslo certifikátu) a volitelně jejich cert. politik TODO: el. podpis podle ETSI TS 101 733 (el. podpis jako náhrada za podpis rukou) SSL/TLS (Secure Sockets Layer/Transport Layer Security) ======================================================= - SSL Netscape (Microsoft PCT), verze 3, SSL 3.1 ~> TLS 1.0 - velice podobný, ale nezaměnitelné, RFC 2246, pro WAP existoval WTLS (Wireless TLS, i nad UDP) - zabezpečení přenášených dat mezi aplikačním protokolem a transportním protokolem TCP - nezávislé na apl. protokolu (SSL/TLS "nevidí" do apl. dat), použití pro zabezpečení apl. protokolů HTTP (HTTPS, ale existuje i S-HTTP!), SMTP (SMTPS), POP/IMAP (POPS/IMAPS), FTP (FTPS, ale existuje i SFTP!) aj. - klient/server, plně duplexní komunikace, při vytváření (SSL/TLS) spojení vždy autentizace serveru (na základě jeho certifikátu pomocí asym. kryptografie), autentizace klienta (na základě jeho cetifikátu) volitelná - není u tzv. anonymního SSL/TLS serveru (anonymní je klient) - aplikační server anonymní být nemusí! - aplikační data rozsekána na fragmenty a ty jsou komprimovány, zabezpečeny integritou a autorizací a šifrovány (sym. šifrou) - kontr. součet fragmentu s tajemstvím (pro kontr. součet), ne el. podpis! - vlastní formát a jazyk pro popis dat - ne ASCII, BER/DER), podobný C (struktury, ale např. proměnná délka dat. typů, na začátku hodnoty délka), ale např. certifikáty kódovány DER - 4 podprotokoly: Obr. Podprotokoly SSL/TLS [11-2] Record Layer Protocol (RLP) --------------------------- - "vrstva SSL/TLS" (prezentační vrstva), ostatní podprotokoly přenášené pomocí něj (jako apl. protokol) - seká apl. data na fragmenty max. 2^14 B, ty (dle dohody) komprimuje, počítá kontr. součet a šifruje (aktuálními šifr. parametry, ne první fragmenty), na druhé straně ověření součtu, dešifrování, dekomprimace a spojení fragmentů - v paketu typ dat (1 B, aplikační nebo podprotokol), verze (2 B), délka fragmentu (2 B) a fragment Obr. SSL/TLS RLP paket [11-4] Handshake Protocol (HP) ----------------------- - "jádro SSL/TLS" (relační vrstva), vytvoření a obnovení (příp. více) relací (session) zahrnujících (příp. více) spojení (connection): autentizace serveru a příp. i klienta (jen při vytvoření), dohoda na šifr. a kompr. algoritmu a algoritmu kontr. součtu, výměna dat (předběžného tajemství a náhodných čísel) pro odvození (hlavního) sdíleného tajemství a z něj sym. šifr. klíče a tajemství pro kontr. součet (připravované šifr. parametry), pro každý směr komunikace jiný sym. šifr. klíč a tajemství, obnovení relace dle nastavení (např. po prodlevě nebo restartu programu) - v paketu typ zprávy (1 B), její délka (3 B) a zpráva: ClientHello a ServerHello - verze (2 B), náhodné číslo (4 B datum a čas a 28 B), ID relace (1. B délka např. 32 B, v ClientHello při vytvoření relace nevyplněné = délka 0), šifr. algoritmy a algoritmy kontr. součtu (2 B délka 2B ID SSL|TLS_asym_WITH_sym+délka_kontr, asym např. [DH[E]_]RSA|DSS[_EXPORT] a NULL, sym+délka např. RC4|RC2_CBC|IDEA_CBC|[3]DES[40][_EDE]_CBC[_40|128] a NULL, kontr. např. MD5|SHA a NULL, v ServerHello bez délky 1) a kompr. algoritmy (1 B délka 1B ID včetně 0 bez komprese, v ServerHello bez délky 1) Certificate - řetěz certifikátů až ke kořenovému (který příjemce již musí mít!, 1. 3 B délka), kódovány DER (1. 3 B délka), může být i prázdný, speciální pro nové vytvoření relace (nová ClientHello atd.) s šiframi neomezenými exportem USA na délku klíče CertificateRequest - volitelná žádost o certifikát klienta, typy podporovaných certifikátů (1 B délka 1B ID, např. RSA|DSS) a DN důvěřovaných certifikačních autorit (2 B délka), kódovány DER (1. 2 B délka) ClientKeyExchange - předběžné tajemství (pre-master secret, náhodné číslo 46 B) šifrované veřejným klíčem serveru, dešifrování serverem = autentizace serveru, pokud nelze šifrovat, pak zpráva ServerKeyExchange CertificateVerify - při odeslání certifikátu volitelný el. podpis kontr. součtu z hlavního tajemství (master secret) a obsahu všech zpráv (kromě ClientHello, 1. 2 B délka) = autentizace klienta, server verifikuje Finished - kontr. součet obsahu všech zpráv (kromě ClientHello), šifrovaná (sym. šifrou) HelloRequest - prázdná říkající si o úvodní ClientHello Obr. Vytvoření a obnovení SSL/TLS relace [11-9, 11-10] Change Cipher Specificatino Protocol (CCSP) ------------------------------------------- - nastavení/změna šifr. parametrů připravených HP pro RLP - paket 1 B s konstantou 1, za ním zabezpečení novými šifr. parametry (nezávisle ve směru paketu) Alert Protocol (AP) ------------------- - signalizace chybových stavů (~ ICMP), úrovně upozornění (komunikace pokračuje) a chyba (komunikace končí) - paket 2 B úroveň a číslo, např. neobnovení relace, nepodporované algoritmy, chybný kontr. součet, certifikát (podrobněji nedostupný, nepodporovaný, revokovaný, prošlý aj.), parametr, chyba dekomprese, dešifrování, handshake aj. - relace: ID (až 32B), certifikát druhé strany, šifr. a kompr. algoritmus a algoritmus kontr. součtu, hlavní sdílené tajemství (48 B), příznak obnovitelnosti - spojení: zvlášť pro klienta i server náhodné číslo (první přenášena otevřeně ve zprávách *Hello), sym. šifr. klíč, tajemství pro kontr. součet, inic. vektor sym. (blok.) šifry, čísla přijatého a odeslaného fragmentu dat - sym. šifr. klíče, inic. vektory a tajemství pro kontr. součet z hlavního tajemství a náhodných čísel, hlavní tajemství z předběžného tajemství a (stejných) náhodných čísel, obojí pomocí pseudonáhodné funkce = bez její znalosti obtížně zjistitelný výsledek, ale ne náhodná (klient i server musí pro stejná data dostat stejný výsledek), různá pro SSL a TLS HTTPS ----- - autentizace jak SSL/TLS (certifikáty) tak HTTP (např. jméno a heslo) - well-known port 443/tcp, RFC 2818: SSL/TLS, URI https:, DNS jméno nebo IP adresa serveru v rozšíření Alternativní jméno předmětu certifikátu serveru, ne v předmětu v DN, i více jmen/adres nebo * - HTTP na portu 80/tcp a tzv. protocol upgrade, RFC 2817: URI http:, server pro vynucení vrací chybu 426 Upgrade Required s hlavičkami 'Upgrade: TLS/1.0' a 'Connection: Upgrade', klient zahajuje metodou GET nebo OPTIONS se stejnými hlavičkami, server odpoví 101 Switching protocols, následují zprávy SSL/TLS HP a HTTPS odpověď serveru POPS a IMAPS ------------ - well-known porty 995/tcp (POPS) a 993/tcp (IMAPS): SSL/TLS - na portech 110/tcp (POP3) a 143/tcp (IMAP4) a příkazy STLS (POP) a STARTTLS (IMAP), RFC 2595: klient příkaz, odpověď serveru 'Begin TLS negotiation', následují zprávy SSL/TLS HP a *S komunikace SSH (Secure SHell) ================== = aplikační protokol pro bezpečnou komunikaci na nezabezpečené síti, se silnou autentizací, klient/server, well-known port 22/tcp = bezpečná obdoba (náhrada) Telnetu a FTP (a tzv. R-utilit) na bázi asym. kryptografie - Telnet nebezpečný - šifrování přenášených dat sym. šifrou (AES, 3DES, Blowfish aj., CBC/CTR mód, klíč 128-256 bitů), klíčů asym. šifrou (RSA, DSA, ECDSA), volitelně komprimování - autentizace (klienta) heslem a (obou) veř. asym. klíčem - např. 2048 bitů, generovány pomocí programu ssh-keygen, soukromý a veřejný klíč klienta (soubory identity(.pub), soukromý příp. šifrovaný a chráněný heslem pouze na klientu!, pro správu programy ssh-agent, ssh-add), serveru (soubory host_key(.pub), soukromý pouze na serveru!) a veřejný klíč klienta na serveru (více v souboru authorized_keys), seznam důvěřovaných veř. klíčů serveru u klienta (soubor known_hosts) - šifrované tunely - podobně jako SSL/TLS nebo šifrovaná proxy, lib. aplikační protokol nad TCP (s 1 pevným portem serveru) - T. Ylönen, verze 1 1995, verze 2 1996, RFC 4252 2006 - implementace na téměř všech platformách: OpenSSH - po navázání TCP spojení dohoda na verzi (textově, klient i server zašlou svoji, 1.99 ekvivalentní 2.0, ale umožňující i 1.x) - služební podprotokoly (verze 2): Obr. Podprotokoly SSH [16-2] Transport Layer Protocol (TLP) ------------------------------ - soustava dalších podprotokolů: Binary Transport Protocol - "vrstva SSH" ("prezentační vrstva"), přenos dat služebních podprotokolů a (příp. více) aplikací - pro každou aplikační kanál, volitelně komprese paketů dat a kontr. součet (MAC - MD5, SHA1, SHA2 aj.) paketů a sdíleného tajemství, šifrování délky paketu (4 B) a výplně (1 B), (příp. komprimovaného s kontr. součtem) paketu a výplně (pro blok. sym. šifru), v paketech zprávy SSH_MSG_neco - typ (1 B) a obsah podle vlastního jazyka (datové typy byte, boolean - 0/1 v 1 B pro příznaky, uint32, uint64, string - délka uint32 a UTF-8 znaky, mpint - celé číslo jiného počtu bytů než 4 a 8, pole []) Obr. Binary Transport Protocol TLP SSH [16-1] Key Exchange Protocol - dohoda na algoritmech a tvorba šifr. parametrů po dohodě na verzi, výměna zpráv KEXINIT: náhodné číslo (16 B), seznamy alg. pro vytvoření sdíleného tajemství - z něj šifr. parametry, alg. autentizačních klíčů serveru, sym. šifry, kontr. součtu (i žádný) a komprese (i žádný) - pro oba směry přenosu dat zvlášť, seznamy jazyků ?, příznak následující zprávy pro výměnu šifr. klíčů a sdílených tajemství pro kontr. součet, např. KEXDH_INIT a KEXDH_REPLY s veřejnými DH čísly, veř. autentizačním klíčem serveru a el. podpisem kontr. součtu (z vyměněných dat od dohody na verzi a ze sdíleného tajemství) - verifikace klientem = autentizace serveru, součet a náhodné číslo = ID relace, šifr. parametry - pro oba změry přenosu dat zvášť: sym. šifr. klíče, inic. vektory sym. šifry, sdílená tajemství pro kontr. součet ~= kontr. součet ze sdíleného tajemství a kontr. součtu z předchozích zpráv a ID relace (v různém pořadí), poté zpráva NEWKEYS a šifrovaná další komunikace - výměna klíčů a zpráva periodicky Service Request Protocol - žádost klienta o službu po zahájení šifr. komunikace, zprávy SERVICE_REQUEST a SERVICE_ACCEPT s názvem služby "ssh-userauth" pro autentizaci klienta a "ssh-connection" pro vytvoření relace pro zprávy Disconnection, Ignored Data, Debug, Reserved Message Authentication Protocol (AP) ---------------------------- - služba autentizace klienta, zprávy USERAUTH_REQUEST s přihl. jménem uživatele (login), jménem služby ?, aut. metody a dalším podle metody a USERAUTH_SUCCESS nebo USERAUTH_FAILURE se seznamem aut. metod serveru a příznakem pokračování, aut. metody: žádná - server neposílá heslem - přenášeno již šifrovaně, jméno aut. metody "password", další příznak změny hesla, (staré) heslo a příp. nové heslo veř. klíčem (asym. šifry) klienta - jméno aut. metody "publickey", další příznak přítomnosti el. podpisu, jméno algoritmu veř. klíče klienta, klíč a příp. el. podpis obsahu zprávy a ID relace - verifikace serverem, při neuvedení podpisu další zprávy USERAUTH_PK_OK se zopakovaným jménem a klíčem a opět USERAUTH_REQUEST s el. podpisem Connection Protocol (CP) ------------------------ - služba vytvoření relace = soubor (příp. více) apl. kanálů pro současný (multiplexovaný) přenos dat (příp. více) aplikací - apl. kanály/aplikace: terminál ~ Telnet (samotné SSH), X11 pro komunikaci X klienta (na serveru) a X serveru (na klientu) v X Window System (unixový grafický subsystém), pro lib. TCP/IP spojení pro "přeposlání" (forward) komunikace z vybraného TCP portu klienta/serveru apl. kanálem na server/klienta a z něj (běžné) TCP/IP spojení - zprávy CHANNEL_OPEN pro vytvoření kanálu klientem nebo serverem s typem a číslem kanálu (u odesilatele) - i u dalších zpráv (jako číslo kanálu druhé strany), velikostí okna odesílaných nepotvrzených dat (stejně jako u TCP), max. velikosí paketu dat a dalším podle typu kanálu, typy "session" pro terminál, "x11" a "tcpip-forward", CHANNEL_OPEN_CONFIRMATION se stejnými položkami nebo CHANNEL_OPEN_FAILURE s důvodem a dalším popisem chyby a jazykem ?, CHANNEL_DATA nebo CHANNEL_EXTENDED_DATA pro přenos dat s daty nebo typem dat a daty a CHANNEL_EOF a CHANNEL_CLOSE pro uzavření a potvrzení uzavření kanálu SSH FTP (SFTP) -------------- - bezpečná obdoba (náhrada) FTP pro přenos souborů, od verze 2.0 SSH - nadstavba apl. kanálu/aplikace terminál s typem "sftp", zprávy pro operace se soubory a adresáři (otevření/uzavření, čtení/zápis, vytvoření/přejmenování/smazání, čtení/zápis atributů/práv aj.)