Bezpecˇna´ komunikace IBP protokolem
Transkript
Bezpecˇna´ komunikace IBP protokolem
}w !"#$%&'()+,-./012345<yA| MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Bezpečná komunikace IBP protokolem DIPLOMOVÁ PRÁCE Bc. Jan Bařinka Brno, podzim 2006 Prohlášenı́ Prohlašuji, že tato diplomová práce je mým původnı́m autorským dı́lem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracovánı́ použı́val nebo z nich čerpal, v práci řádně cituji s uvedenı́m úplného odkazu na přı́slušný zdroj. Vedoucı́ práce: Mgr. Lukáš Hejtmánek ii Shrnutı́ Tato práce se zabývá problematikou distribuovaných datových skladů a protokolu, který datové sklady spojuje. Sı́tě, které se starajı́ o efektivnı́ využitı́ distribuovaných datových skladů, se nazývajı́ logistické sı́tě. Cı́lem práce je navrhnout a upravit komunikačnı́ protokol užı́vaný pro komunikaci s datovými sklady v logistických sı́tı́ch tak, aby bylo možné logistické sı́tě začlenit do prostředı́ virtuálnı́ch organizacı́. iii Klı́čová slova logistické sı́tě, virtuálnı́ organizace, VOMS, IBP, X509, PKI, AES iv Obsah 1 2 3 4 5 6 7 8 9 Logistické sı́tě . . . . . . . . . . . . . . . . . . . . 1.1 Datové sklady . . . . . . . . . . . . . . . . . . 1.2 Vrstva IBP . . . . . . . . . . . . . . . . . . . Alternativa logistických sı́tı́ . . . . . . . . . . . . Bezpečnost v počı́tačových sı́tı́ch . . . . . . . . . 3.1 Bezpečnost služeb . . . . . . . . . . . . . . . . 3.2 Bezpečnost dat . . . . . . . . . . . . . . . . . 3.3 Bezpečnostnı́ mechanismy . . . . . . . . . . . Bezpečnost v logistických sı́tı́ch . . . . . . . . . 4.1 Důvěra . . . . . . . . . . . . . . . . . . . . . 4.2 Bezpečnost typu konec – konec . . . . . . . . . 4.3 Bezpečnostnı́ funkce vrstvy LoRS . . . . . . . 4.4 Ochrana datového skladu . . . . . . . . . . . . IBP protokol . . . . . . . . . . . . . . . . . . . . . 5.1 Historie IBP protokolu . . . . . . . . . . . . . 5.2 Stručný popis protokolu IBP . . . . . . . . . . 5.2.1 Přı́klad uloženı́ dat na server . . . . 5.3 Přı́kazy IBP protokolu . . . . . . . . . . . . . 5.3.1 Allocate . . . . . . . . . . . . . . . . 5.3.2 Store . . . . . . . . . . . . . . . . . . 5.3.3 Load . . . . . . . . . . . . . . . . . . 5.3.4 Copy (Send) . . . . . . . . . . . . . . 5.3.5 Mcopy . . . . . . . . . . . . . . . . . 5.3.6 Manage . . . . . . . . . . . . . . . . 5.3.7 Status . . . . . . . . . . . . . . . . . . 5.3.8 Přı́klad . . . . . . . . . . . . . . . . . Zabezpečenı́ protokolu IBP . . . . . . . . . . . . 6.1 Existujı́cı́ řešenı́ . . . . . . . . . . . . . . . . . 6.2 Výhody a nevýhody stávajı́cı́ho řešenı́ . . . . . IBP protokol v kontextu virtuálnı́ch organizacı́ 7.1 Jak se to řešı́ dnes . . . . . . . . . . . . . . . . 7.2 Požadavky na logistické sı́tě . . . . . . . . . . Návrh úprav . . . . . . . . . . . . . . . . . . . . . 8.1 Proces autorizace . . . . . . . . . . . . . . . . Řešenı́ . . . . . . . . . . . . . . . . . . . . . . . . 9.1 Mechanismus autentizace a autorizace . . . . . 9.2 Návrh implementace . . . . . . . . . . . . . . 9.2.1 Úpravy klienta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 5 7 9 9 10 10 12 12 12 13 13 15 15 16 16 17 17 17 17 17 17 17 18 18 19 19 21 23 23 24 25 25 27 27 28 30 1 10 11 12 13 9.2.2 Úprava serverové části . . . . . . . . . . 9.2.3 Implementace IBP protokolu v serveru 9.3 Nedostatky oproti návrhu . . . . . . . . . . . . . . Konkrétnı́ implementace . . . . . . . . . . . . . . . 10.1 Vlákna . . . . . . . . . . . . . . . . . . . . . . . . 10.2 Kryptografické mechanismy . . . . . . . . . . . . 10.3 Popis provedenı́ zabezpečenı́ . . . . . . . . . . . . 10.3.1 Navazovánı́ spojenı́ – klientská část . . 10.3.2 Navazovánı́ spojenı́ – server . . . . . . Testovánı́ . . . . . . . . . . . . . . . . . . . . . . . . . 11.1 Hlavnı́ testovánı́ . . . . . . . . . . . . . . . . . . 11.2 Prvnı́ série . . . . . . . . . . . . . . . . . . . . . . 11.2.1 Hardware . . . . . . . . . . . . . . . . . 11.2.2 Výsledky . . . . . . . . . . . . . . . . . . 11.3 Druhá série . . . . . . . . . . . . . . . . . . . . . 11.3.1 Hardware . . . . . . . . . . . . . . . . . 11.3.2 Výsledky . . . . . . . . . . . . . . . . . . 11.4 Doplňkové testy . . . . . . . . . . . . . . . . . . . 11.4.1 Výsledky . . . . . . . . . . . . . . . . . . Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . Popis API . . . . . . . . . . . . . . . . . . . . . . . . 13.1 Struktury a datové typy . . . . . . . . . . . . . . . 13.1.1 IBP authhandle . . . . . . . . . . . . . . 13.2 Funkce API . . . . . . . . . . . . . . . . . . . . . 13.2.1 ibp init . . . . . . . . . . . . . . . . . . . 13.2.2 IBP auth create . . . . . . . . . . . . . . 13.2.3 IBP auth . . . . . . . . . . . . . . . . . . 13.2.4 IBPs allocate . . . . . . . . . . . . . . . . 13.2.5 IBPs store . . . . . . . . . . . . . . . . . 13.2.6 IBPs load . . . . . . . . . . . . . . . . . 13.2.7 IBPs copy . . . . . . . . . . . . . . . . . 13.2.8 IBPs manage . . . . . . . . . . . . . . . 13.3 Doporučený postup – ukázka . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31 31 34 35 35 38 39 39 43 45 45 47 47 47 50 50 50 51 52 54 55 55 55 56 56 56 57 58 59 60 62 64 65 2 Seznam obrázků 1.1 Vrstvy logistické sı́tě 8.1 Autentizačnı́ a autorizačnı́ proces v logistických sı́tı́ch ve VO 9.1 9.2 9.3 Časový průběh navazovánı́ bezpečného spojenı́ v IBP protokolu Pracovnı́ cyklus IBP serveru 32 Průběh přı́kazu zabezpečeného IBP copy 33 11.1 11.2 11.3 Průběh funkcı́ Allocate, Store, Load a Copy pro 100 MB 47 Průběh funkce Store pro 50 MB a 100 MB dat 48 Průběh funkcı́ Store a Load pro 50 MB a 100 MB dat čtených z a psaných do jednoho nebo vı́ce souborů 49 Průběh funkcı́ Allocate, Store, Load a Copy pro 100 MB mezi MU a ZČU 50 Průběh funkcı́ Allocate, Store, Load a Copy pro 100 MB na ZČU 51 Průběh funkcı́ Allocate, Store, Load a Copy pro 10 MB 52 Průběh funkcı́ Store a Load pro 25 MB 53 11.4 11.5 11.6 11.7 5 26 28 3 Kapitola 1 Logistické sı́tě Významnou součástı́ rozvoje výpočetnı́ techniky je v poslednı́ch letech oblast počı́tačových sı́tı́. Propojenı́ počı́tačů pomocı́ sı́tě umožňuje sdı́let prostředky, kterými disponuje jeden počı́tač mezi ostatnı́ počı́tače v sı́ti. Sdı́leným prostředkem mohou být datová úložiště nebo výpočetnı́ výkon. Se vzrůstajı́cı́ velikostı́ sı́tı́ a nároků na sdı́lené prostředky vzrůstá i požadavek na jejich efektivnı́ využı́vánı́. Z pohledu poskytovatele sdı́leného prostředku jde předevšı́m o to, poskytnout co nejvı́ce služeb a co nejlepšı́ služby s co nejnižšı́mi náklady. Požadavky klienta v přı́padě, že vı́ce poskytovatelů umı́ sdı́let podobný prostředek, směřujı́ na zvolenı́ správného poskytovatele. Kritériı́, podle kterých si klient vybı́rá vhodného poskytovatele, může být vı́ce, jmenujme tedy ty nejzákladnějšı́. Důležitou vlastnostı́ je stabilita poskytované služby, dále pak cena a rychlost za jakou se ke službě klient dostane. Pro klienta sı́dlı́cı́ho v organizaci A je výhodnějšı́ využı́t služeb, které mu poskytuje server přı́mo v organizaci A, než stejnou službu využı́vat na serveru mimo tuto organizaci. Předpokládáme, že využitı́ počı́tačové sı́tě v rámci organizace je zdarma a sı́t’dosahuje vyššı́ propustnosti než sı́t’mimo organizaci a kvalita poskytované služby je přitom shodná. Na druhou stranu může nastat situace, kdy lokálnı́ server v organizaci A je vytı́žený a bud’ vůbec nemůže poskytnout žádanou službu v rozumném časovém horizontu, nebo službu poskytnout může, ale v čase vyššı́m, než je čas, ve kterém může tuto službu poskytnout server sı́dlı́cı́ mimo organizaci. Pak je pro klienta výhodnějšı́ využı́t externı́ server. Rozhodnutı́, který server využı́t, padá na uživatele. On si musı́ zjistit, jak moc je který server vytı́žený a na který je výhodné umı́stit výpočetnı́ úlohu, přı́padně jak moc jsou využita datová úložiště a kam svá data může uložit na dobu 14 dnů a kam jen na týden. Bylo by tedy vhodné, aby břı́mě rozhodnutı́ vzal na sebe počı́tač přı́padně vhodný počı́tačový systém. Počı́tačové sı́tě schopné řı́dit optimálnı́ využı́vánı́ sdı́lených prostředků se nazývajı́ logistické sı́tě. Termı́n byl odvozen od pojmenovánı́ obdobných mechanismů napřı́klad v armádě, kde se logistika stará o optimálnı́ využitı́ zásob potravin, techniky, střeliva atd. Logistická sı́t’ je definována jako globálnı́ plánovánı́ a optimalizace pohybu dat, úložných prostorů a výpočetnı́ch kapacit, postavené na modelu, který bere v úvahu všechny fyzické zdroje, které jsou sı́tı́ propojeny. 1.1 Datové sklady Mechanismy logistických sı́tı́ pro oblast sdı́lenı́ výpočetnı́ch prostředků jsou již běžně použı́vány. Jde o vhodné rozdělovánı́ úloh jednotlivým uzlům gridu. Oblast, ve které zatı́m nenı́ vyvinuto mnoho vhodných mechanismů, jsou distribuovaná datová úložiště. Tedy datová úložiště, která nejsou tvořena jednı́m uzlem počı́tačové sı́tě, ale mnoha uzly, které jsou rozmı́stěny v libovolných oblastech planety, jsou připojeny k sı́ti různorodými technologiemi a poskytujı́ různorodé datové kapacity. Tedy zcela heterogennı́ systém datových skladů, který se uživateli má jevit jako 4 1.2. VRSTVA IBP homogennı́ datové úložiště. Důležitou vlastnostı́ tohoto úložiště je právě to, že uživatel pouze zadá požadavek na velikost dat, dobu jejich uloženı́ a úroveň jejich zabezpečenı́ a mechanismy logistické sı́tě vyberou konkrétnı́ vhodné datové sklady a data tam uložı́. Tento mechanismus byl navržen v roce 1998 na Universitě v Tennessee v Knoxwille 1 a skládá se z několika vrstev. Obrázek 1.1: Vrstvy logistické sı́tě Z pohledu uživatele je svrchnı́ vrstvou LoRS vrstva (Logistical Runtime System), která se stará o vyhledávánı́ vhodných datových skladů pomocı́ vrstvy L–Bone. Následně o vytvořenı́ eXnodes, což jsou uzly nesoucı́ informaci o tom, ve kterém datovém skladu je uložena která část uživatelova souboru. Jde o ekvivalent I–nodes užı́vaných v Unixových souborových systémech. EXnode stavı́ na vrstvě IBP a rozšiřuje jejı́ vlastnosti. Stručně jmenujme napřı́klad zvětšenı́ maximálnı́ velikosti ukládaného souboru, udržovanı́ informace o vı́ce kopiı́ch souboru nebo přenositelnost, která je dána tı́m, že veškeré informace v eXnode jsou uloženy ve formátu XML. 1.2 Vrstva IBP Téměř nejnižšı́ vrstvou je IBP (Internet Backplane Protocol). Tato vrstva se přı́mo stará o prováděnı́ operacı́ s daty ve vzdálených datových skladech. Slovo „backplane“ v názvu vrstvy vyjadřuje jejı́ pozici v rámci architektury logistické sı́tě. Vrstva IBP se stavı́ do pozice základové desky, pomocı́ nı́ž mezi sebou komunikujı́ datové sklady či uživatel s datovými sklady. IBP protokol si vystačı́ jen s několika operacemi, které je možné nad datovým skladem provádět. IBP protokol sloužı́ pouze k tomu, aby si klient požádal o uloženı́ určitého množstvı́ dat po určitou 1. http://loci.cs.utk.edu/ 5 1.2. VRSTVA IBP dobu v určitém datovém skladu. Pokud toto datový sklad povolı́, klient může data uložit, následně pak čı́st nebo je nechat přesunout do jiného datového skladu. Data samotná jsou ve skladu uložena téměř anonymně, každý datový balı́k je identifikován jedinečným klı́čem. Z IBP vrstvy však nelze určit soubor, jehož součástı́ tento datový balı́k je. Rekonstruovat uložené soubory na úrovni IBP je tedy nemožné, protože potřebné informace nese až přı́slušný eXnode, který je ve vyššı́ vrstvě. Právě IBP vrstva a možnosti jejı́ho zabezpečenı́ jsou hlavnı́m tématem této práce. 6 Kapitola 2 Alternativa logistických sı́tı́ Logistické sı́tě nejsou prvnı́ a jedinou technologiı́, která se zabývá doručovánı́m dat v rámci internetu. Podobných projektů je vı́ce a souhrnně se označujı́ jako sı́tě pro doručovánı́ obsahu anglicky Content Delivery Networks (CDN). Cı́lem těchto sı́tı́ je poskytnout data klientům a to tak, aby klienti měli k datům vždy ideálnı́ přı́stup. Konkrétně aby klient z Evropy měl k datům stejně rychlý a spolehlivý přı́stup jako klient z Japonska a to i v přı́padě, že data pocházejı́ z Austrálie. Sı́t’ CDN musı́ data vhodně rozmı́stit po svých serverech a klientům nabı́dnout ty servery, které jsou pro ně nejvýhodnějšı́. CDN sı́t’se skládá z vı́ce uzlů rozmı́stěných po světě, které sloužı́ jako datové sklady a algoritmů a technologiı́ optimalizujı́cı́ch a řı́dı́cı́ch funkci celé sı́tě. Po vloženı́ dat do CDN sı́tě se data distribuujı́ po uzlech tak, aby se dostala co nejdřı́ve a co možná nejblı́že největšı́mu počtu klientů. Přenosy dat se dějı́ za plného provozu celé sı́tě. Pokud klient zažádá o data pomocı́ url, pak je url zpracováno CDN sı́tı́ a je přetransformováno tak, aby nasměrovalo klienta na ten uzel CDN sı́tě, který obsahuje požadovaná data a je klientovi nejblı́ž. Vzdálenost dat od klienta je zpravidla hodnocena počtem uzlů sı́tě mezi klientem a severem, dobou odezvy serveru, rychlostı́ linky nebo vytı́ženı́m serveru. K výběru vhodného serveru se užı́vá vı́ce technik z nichž nejběžnějšı́ je vyrovnávánı́ zátěže na úrovni vrstvy DNS, monitorovánı́ sı́tě a následně přepisovánı́ url, přesměrovánı́ url nebo jiný způsob jak přesměrovat požadavek na vybraný server v internetu. Vyrovnávánı́ zátěže na úrovni DNS serveru bere v potaz zatı́ženı́ a dostupnost cı́lových serverů a na základě toho vybere IP adresu nejvhodnějšı́ho z nich. Tato metoda vyžaduje podporu nejen na straně DNS serveru ale i na straně cı́lových serverů. Cı́lové servery musı́ na požádánı́ sdělit patřičné informace o svém stavu jako je zatı́ženı́ procesorů, využitı́ paměti nebo vytı́ženı́ konektivity. DNS server zjištěné údaje vyhodnotı́, každé vlastnosti přidělı́ zvolenou váhu a IP adresa nejlépe ohodnoceného serveru je vrácena klientovi. Jednı́m z nejznámějšı́ch systému pro doručovanı́ obsahu sı́tı́ je Akamai 2 . Jeho služeb využı́vajı́ velké společnosti jako CNN, BBC nebo Google předevšı́m pro šı́řenı́ multimediálnı́ch data. Akamai je globálně distribuovaný systém pro poskytovánı́ obsahu. Jeho cı́lem je operativně řešit úzká mı́sta v sı́ti, výpadky serverů a jejich přetı́ženı́. Aby toho systém dosáhl, využı́vá ve velkém měřı́tku replikaci dat a služeb. Systém se v současné době sestává z tisı́ců serverů rozmı́stěných v 71 zemı́ch světa. Klient si zadánı́m url vyžádá určitá data, sı́t’ Akamai pomocı́ svých mechanismů postavených předevšı́m na vylepšených DNS serverech, přeložı́ url na vhodnou sı́t’ovou adresu v internetu. DNS systém monitoruje vytı́ženı́ a dostupnost datových skladů a přeložı́ url na adresu toho skladu, který je dostupný a klient k němu má po sı́ti rychlý přı́stup. Systém se užı́vá předevšı́m pro poskytovánı́ obsáhlejšı́ch souborů na často navštěvovaných webových stránkách. Provozovatel webové stránky umı́stı́ napřı́klad obrazový materiál na servery 2. http://www.akamai.com/ 7 2. ALTERNATIVA LOGISTICKÝCH SÍTÍ systému Akamai, čı́mž odlehčı́ serveru provozovatele stránek, který tak poskytne rychle HTML kód webové stránky s textovými informacemi. Obrázky jsou následně staženy ze systému Akamai, který každému uživateli přidělı́ ke staženı́ dat ten nejvhodnějšı́ server. Systémy CDN jsou určeny pro doručovánı́ dat, tedy optimalizujı́ čtenı́ dat z distribuovaného datového skladu. Chybı́ tedy důležitá vlastnost, kterou požadujeme po logistických sı́tı́ch a to optimalizovánı́ zápisu dat do datového skladiště. 8 Kapitola 3 Bezpečnost v počı́tačových sı́tı́ch S nárůstem klientů počı́tačových sı́tı́ rostou i bezpečnostnı́ rizika spojená s přenosem dat po sı́tı́ a s provozovánı́m po sı́ti dostupných služeb. Čı́m vı́ce je sı́t’přı́stupná veřejnosti, tı́m je riziko vyššı́. Proto je vhodné uvažovat z hlediska bezpečnosti nejhoršı́ tedy nejveřejnějšı́ variantu sı́tě a tou je bezpochyby internet. Bezpečnosti mechanismy jsou různé, ale obecně lze řı́ct, že čı́m většı́ jsou bezpečnostnı́ opatřenı́, kterými musı́ uživatel projı́t při snaze využı́t některou službu, tı́m obtı́žnějšı́ to pro něj je. Může se stát, že uživatel bude přı́mo odrazen složitostı́ bezpečnostnı́ch opatřenı́, což nemusı́ být vždy žádoucı́. Toto lze v přı́padě, kdy jde o bezpečnost uživatelových dat, řešit tak, že uživatel sám zvolı́ mı́ru zabezpečenı́ tak, jak uzná za vhodné. 3.1 Bezpečnost služeb Bezpečnost provozované služby spočı́vá hlavně v zabráněnı́ jejı́ho zneužitı́ a jejı́ho znepřı́stupněnı́. V přı́padě datového skladu, jakým pro zjednodušenı́ může být veřejný FTP server, si pod jeho zneužitı́m lze představit skladovánı́ a distribuci nelegálnı́ho software. Pokud se útočnı́kovi podařı́ na FTP server uložit nežádoucı́ software, je tento následně přı́stupný široké veřejnosti. Znepřı́stupněnı́ služby může proběhnout obdobným způsobem. Vezměme FTP server, na který majı́ uživatelé právo ukládat data a který má omezenou datovou kapacitu. Pokud někdo uložı́ na server takové množstvı́ dat, že kapacitu zcela zaplnı́, pak je služba ukládánı́ dat znepřı́stupněna všem ostatnı́m uživatelům. Tyto problémy by měla řešit služba samotná bez ohledu na to, co by si přál uživatel. Pokud se na službu podı́váme z jiného pohledu, pak zjistı́me, že možným bezpečnostnı́m problémem může být zneužitı́ dat, která samotná služba zpracovává. V našem přı́kladu s FTP serverem jde o to, že správce serveru může data na serveru uložená čı́st, a tedy i snadno zneužı́t. I tuto situaci může řešit služba a to tak, že data při ukládánı́ bude šifrovat a při čtenı́ dešifrovat. Stále ale musı́ uživatel věřit, že toto služba provádı́. Zde je tedy vhodné, aby uživatel sám zvážil, jak citlivá data bude na server ukládat, a podle potřeby je sám před uloženı́m bezpečně zašifroval. Pokud si šifrovacı́ klı́č ponechá pro sebe, pak jsou jeho data v bezpečı́. Bezpečnost služby může být také brána z pohledu integrity dat uložených nebo zpracovávaných službou. Pro uživatele je jistě nežádoucı́, aby se jeho data uložená na FTP serveru ztratila z důvodu fyzického poškozenı́ média, na kterém byla uložena. Tento problém by měla řešit samotná služba. Uživatel by přı́padně mohl volit, v kolika kopiı́ch se majı́ data do datového skladu uložit. 9 3.2. BEZPEČNOST DAT 3.2 Bezpečnost dat Bezpečnost dat přenášených počı́tačovou sı́tı́ spočı́vá předevšı́m v tom, aby data od odesı́latele k přı́jemci opravdu doputovala, dále aby byla nepozměněna, aby zůstala ostatnı́m uživatelům sı́tě utajena a aby bylo možno ověřit jejich původ. Požadavek na spolehlivost je vcelku jasný. Těžko bychom mohli považovat za bezpečnou a užitečnou takovou komunikaci, kdy si nebudeme jisti, že adresát zprávu obdržel a přı́padně vykonal pokyny, které byly ve zprávě obsaženy. Obdobně nemusı́ být vhodné, aby ostatnı́ účastnı́ci sı́tě mohli zjistit, jaká data, v našem přı́kladě pokyny, zpráva obsahuje. Ještě zhoubnějšı́ následky může způsobit podvrženı́ pokynů třetı́ stranou. To může být provedeno tak, že třetı́ strana podvrhne celou novou zprávu, přı́padně že odposlechne komunikaci a odposlechnutou zprávu pozměnı́ a pak ji pošle přı́jemci. Pokud přı́jemce nedokáže rozeznat, že zpráva byla pozměněna, nebo že pocházı́ od jiného účastnı́ka, než je odesı́latel, pak může útočnı́k snadno způsobit škodu. Dalšı́ variantou útoku je zopakovánı́ odposlechnuté komunikace. Třetı́ strana jednoduše odposlechne komunikaci mezi odesı́latelem a přı́jemcem, a byt’ nezná jejı́ přesný obsah, dokáže komunikaci zopakovat. Tı́m donutı́ přı́jemce znovu provést stejné operace, jaké po něm žádal odesı́latel. Bezpečnost dat úzce souvisı́ s bezpečnostı́ služeb. Pokud si jako přenášená data představı́me řı́dı́cı́ přı́kazy pro libovolnou službu, pak je zřejmé, že při změně či zopakovánı́ těchto dat můžeme donutit službu provádět nežádoucı́ operace, tedy můžeme službu zneužı́t. Jako přı́klad si uved’me komunikaci mezi klientem a datovým skladem, kdy klient žádá o přidělenı́ určitého prostoru a datový sklad mu prostor přidělı́ a přidělený prostor odečte ze zbývajı́cı́ho volného prostoru. Pokud žádost o přidělenı́ nedorazı́ od klienta k serveru, pak je to nepřı́jemné, ale nenı́ to nebezpečné. Pokud si tuto žádost po cestě někdo přečte, pak nás jako klienta může udat nadřı́zeným, že v pracovnı́ době neděláme to, co máme. Pokud ale útočnı́k zprávu pozměnı́, pak může klientovým jménem žádat mnohem vı́ce mı́sta v datovém skladu a za předpokladu, že je sklad placenou službou, čeká klienta vyššı́ účet. Nedokáže-li datový sklad ověřit, že klient je opravdu ten, kdo požadavek poslal, může útočnı́k pro sebe zı́skat mı́sto v datovém skladu na klientův účet. Jestliže útočnı́k jen zopakuje odposlechnutou komunikaci, pak může opět znovu a znovu žádat datový sklad o přidělenı́ mı́sta na klientův účet, což bude klienta stát vı́ce peněz a navı́c může dojı́t k tomu, že datový sklad vyčerpá svou kapacitu. Tedy útočnı́k tak službu datového skladu částečně znepřı́stupnı́. 3.3 Bezpečnostnı́ mechanismy Základnı́ techniky zabraňujı́cı́ zneužitı́ služeb nebo útokům na služby jsou autentizace a autorizace. Pokud klient musı́ projı́t procesem autentizace, je prokázáno, že je tı́m za koho se vydává. Útočnı́k pak nemůže libovolně měnit svou identitu a vydávat se za někoho jiného. Obvykle na základě identity prokázané při autentizaci jsou klientovi přidělena práva k určitým operacı́m se službou. Klient je autorizován napřı́klad čı́st i psát do datového skladu, ale maximálně může zapsat 100 MB dat. Pokud vı́me, jakou maximálnı́ kapacitu má datový sklad, pak můžeme snadno ohlı́dat, aby součet kvót uživatelů nebyl většı́ než maximálnı́ kapacita skladu. Nemůže tedy dojı́t k situaci, kdy se datový sklad zaplnı́ a nenı́ schopen přijı́mat dalšı́ data. Pro zachovánı́ bezpečnosti dat sloužı́ šifrovanı́ dat a podepisovánı́ dat. Zašifrovaná data lze 10 3.3. BEZPEČNOSTNÍ MECHANISMY sice odposlechnout stejně snadno jako nešifrovaná, ale nelze zjistit jejich pravý obsah. Toto však nebránı́ útočnı́kovi v tom, aby data změnil. Efekt může přinést i zcela náhodná změna v datech. Proti změnám se užı́vá technologie podepisovánı́ dat. Podpis dat je tvořen na základě soukromého klı́če a je silně závislý na datech samotných. Pokud by útočnı́k chtěl data změnit, musel by vhodně změnit i podpis a k tomu by musel znát soukromý klı́č. Logistické sı́tě se musı́ se všemi výše zmı́něnými bezpečnostnı́mi systémy efektivně vypořádat. Některé mechanismy musı́ být pevně dané, jiné mohou být uživatelem logistické sı́tě voleny. Na druhou stranu logistická sı́t by proti některým útokům měla být odolná již z principu jejı́ho návrhu. Pokud je služba poskytována ve vı́ce uzlech sı́tě, pak by výpadek jednoho uzlu neměl poškodit uživatele, nebot’požadavky uživatele by měl obsloužit jiný uzel poskytujı́cı́ stejnou službu. 11 Kapitola 4 Bezpečnost v logistických sı́tı́ch Vzhledem k tomu, že logistické sı́tě majı́ za cı́l poskytnout flexibilnı́ a výkonné řešenı́ pro veřejné datové sklady, nelze tyto sı́tě pokládat za důvěryhodné. Jak již bylo zmı́něno výše, aby sı́t’mohla být považována za důvěryhodnou, musı́ poskytnout přenášeným datům utajenı́, nezměnitelnost a prokázánı́ jejich původu. Služby na sı́tı́ musı́ být schopné řı́dit přı́stup k datům a odolávat útokům. Poskytované služby musı́ také odolávat výpadkům, at’ už způsobeným útokem nebo fyzickým selhánı́m hardwaru. 4.1 Důvěra Pokud chceme, aby naše data zůstala utajena, pak nám nezbývá, než data šifrovat nebo důvěřovat všem systémům, přes které naše data putujı́. Důvěřovat musı́me správci našeho počı́tače, že si nebude data prohlı́žet, stejně tak správci počı́tačové sı́tě v našı́ organizaci, že nebude komunikaci odposlouchávat. V rámci jedné organizace by se dalo uvažovat o tom, že v tyto dva správce bude důvěra vložena. Ale co operačnı́ systém, který běžı́ na našem počı́tači? I tomu musı́me věřit a doufat, že do něj výrobce nevložil zadnı́ vrátka. Pokud chceme data poslat přes sı́t’ mimo naši organizaci či přı́mo přes internet, pak musı́me věřit provozovatelům těchto sı́tı́. Pokud by se jednalo o sı́tě a služby jedné, byt’ velké organizace, pak by požadovaná úroveň mohla být zajištěna, ale v přı́padě veřejných logistických sı́tı́ je to zcela nemožné. Veřejný datový sklad může zřı́dit jakýkoliv uživatel internetu a nikdo nemůže zjistit, jak provozovatel skladu s uloženými daty nakládá. Zda je kopı́ruje pro vlastnı́ potřebu nebo data dále analyzuje. Nenı́ zde žádná ochrana před odposlechem datových linek. Data putujı́ internetem přes mnoho uzlů a linky využı́vajı́ mnoho technologiı́, z nichž některé může být snadné odposlechnout. Toto vše vede k závěru, že logistické sı́tě nemohou být v žádném přı́padě pokládány za důvěryhodné. 4.2 Bezpečnost typu konec – konec Při bližšı́m zamyšlenı́ nad problémem zabezpečenı́ dat v logistických sı́tı́ch dojdeme nutně k závěru, že jedinou rozumnou cestou je data zabezpečit před jejich vloženı́m do logistické sı́tě. Tedy aby v přı́padě, že se data dostanou do nepovolaných rukou, byl pravý obsah dat utajen. Po té, co data projdou logistickou sı́tı́, musı́ být uvedena zpět do nezabezpečené podoby. Zpravidla sám odesı́latel může data zašifrovat vhodným algoritmem za užitı́ tajného klı́če. Takto upravená data svěřı́ datovému úložišti v logistické sı́ti. Odesilatel pak přı́jemci spolu s odkazem na uložená data předá také šifrovacı́ klı́č, s jehož pomocı́ přı́jemce data dešifruje do původnı́ podoby. Šifrovánı́ i dešifrovánı́ by mělo probı́hat co nejblı́že u uživatelů. Tedy počı́tač odesı́latele by měla opustit data již v zašifrované podobě a v zašifrované podobě by měla dorazit na počı́tač přı́jemce, kde 12 4.3. BEZPEČNOSTNÍ FUNKCE VRSTVY LORS budou lokálně dešifrována. Tento přı́stup k bezpečnosti dat se nazývá bezpečnost typu konec – konec. 4.3 Bezpečnostnı́ funkce vrstvy LoRS O bezpečnost typu konec – konec se v návrhu logistické sı́tě stará svrchnı́ vrstva LoRS. Tato vrstva obsahuje potřebné technologie a mechanismy, takže snı́má břemeno zabezpečenı́ z uživatele a sama se stará o vše potřebné. LoRS poskytuje tyto bezpečnostnı́ služby: • Kontrolnı́ součty. Umožňujı́ zjistit, zda byla data během jejich pobytu v logistické sı́tı́ změněna. • Šifrovánı́. Aplikovánı́m šifrovánı́ na data před jejı́ch vloženı́m do logistické sı́tě zajišt’uje utajenı́ jejich obsahu. Přı́slušné údaje pro dešifrovánı́ jsou uloženy v patřičném eXnode. Data tak mohou být bez obav uložena v libovolném datovém úložišti. • Fragmentace. Rozdělenı́ jednoho datového balı́ku na vı́ce částı́ a každá část je uložena v jiném datovém úložišti. I kdyby útočnı́k zı́skal fragment datového balı́ku, obtı́žně jej může analyzovat a sestavit celý datový balı́k. Typický postup ochrany dat na úrovni LoRS pak sestává z fragmentace odesı́laných dat na vı́ce částı́, zašifrovánı́ každé části jiným šifrovacı́m klı́čem a odeslánı́ každého fragmentu pokud možno na fyzicky jiné datové úložiště a tak, aby v ideálnı́m přı́padě každý fragment byl uložen na vı́ce jak jednom úložišti. Informace o umı́stěnı́ fragmentů v úložištı́ch a potřebné šifrovacı́ klı́če jsou vloženy do přı́slušného eXnode. EXnode lze exportovat jako XML soubor a transportovat ho na jiné mı́sto sı́tě, kde bude užit pro přečtenı́ dat z logistické sı́tě. Popsaný mechanismus se jevı́ jako bezpečný, předevšı́m z pohledu uživatele a jeho starosti o jı́m posı́laná data. Bohužel ale nenı́ zaručena žádná bezpečnost datových skladů proti jejich zneužitı́. Bezpečnostnı́ funkce vrstvy LoRS je významná a nezanedbatelná, nenı́ však dostačujı́cı́, protože vlastnı́ komunikace mezi klientem a datovým skladem nenı́ nijak chráněna. 4.4 Ochrana datového skladu Datový sklad, stejně jako každá jiná služba poskytovaná v počı́tačové sı́ti, musı́ čelit bezpečnostnı́m útokům. Jak již bylo zmı́něno jedná se předevšı́m o útoky s cı́lem využı́t neoprávněně datový sklad, poškodit jiné uživatele datového skladu (zneužı́t jeho účet nebo jeho data) nebo datový sklad vyřadit z provozu. Tyto útoky mohou být vedeny mnoha způsoby, jak již bylo popsáno obecněji v kapitole 3. Proti útoku směřujı́cı́mu k zaplněnı́ datového skladu, které vede k tomu, že datový sklad nemůže přijı́mat dalšı́ data a je tak částečně odstaven z funkce, se datový sklad bránı́ sám. Data uložená ve skladu majı́ limitovanou životnost. Tedy, i když je sklad dočasně zaplněn, některá data v konečném čase vypršı́ a mı́sto se uvolnı́. Maximálnı́ životnost dat je určena správcem serveru a klient sám si jı́ může volit, přičemž nemůže překročit zmiňované maximum. Většina útoků zneužı́vá komunikačnı́ protokol datového skladu. V logistických sı́tı́ch je pro tuto komunikaci užı́ván protokol IBP. Jde o bezstavovou komunikaci založenou na textových zprávách. 13 4.4. OCHRANA DATOVÉHO SKLADU Protokol tohoto typu se snadno implementuje, ale také se snadno odposlouchává a zpětně analyzuje. Je tedy nutné komunikačnı́ protokol bud’ změnit nebo vhodně zabezpečit. V situaci, kdy na IBP protokolu běžı́ již mnoho datových skladů a je na něm postaveno mnoho aplikacı́, je vhodným řešenı́m druhá varianta. Pokud se jen trochu zamyslı́me, napadne nás, že nejjednoduššı́m řešenı́m by pravděpodobně bylo zprávy zası́lané v rámci IBP komunikace šifrovat. Tı́m zabránı́me, nebo alespoň výrazně znesnadnı́me odposlech komunikace a jejı́ dalšı́ analýzu. Šifrovánı́ IBP komunikace spolu s dalšı́mi podpůrnými metodami jsme zvolili jako správný směr a je hlavnı́ náplnı́ této práce. 14 Kapitola 5 IBP protokol 5.1 Historie IBP protokolu IBP protokol byl navržen v roce 1998 s cı́lem vytvořit flexibilnı́ protokol pro snadnou práci s široce distribuovanými sdı́lenými datovými úložišti. Návrh protokolu IBP se od tehdy běžných protokolů pro datové sklady lišil ve třech hlavnı́ch bodech: • Datová úložiště budou poskytovat prostor pro zápis jako sdı́lený sı́t’ový prostředek. Do té doby bylo umožněno z datových úložišt’předevšı́m čı́st. • Protokol bude podporovat prováděnı́ vzdálených operacı́ s daty v datových úložištı́ch. • Datová úložiště umožnı́ zápis dat neautentizovaným uživatelům. V době vzniku IBP protokolu poskytoval internet dva základnı́ typy služeb. Datové zdroje umožňujı́cı́ pouze čtenı́ jako jsou web a anonymnı́ FTP, a vzdálené výpočetnı́ servery. Samozřejmě vznikaly projekty snažı́cı́ se rozšı́řit sı́t’ové služby, ale jen málo z nich se zabývalo poskytovánı́m zapisovatelného datového úložiště. A právě na tuto oblast se specializoval projekt protokolu IBP. Poskytovat zapisovatelné distribuované sı́t’ové úložiště dat má několik výhod. Jmenujme napřı́klad možnost dostat data zpracovávaná vzdáleným serverem do jeho bezprostřednı́ blı́zkosti. Lze vytvářet vyrovnávacı́ datové kapacity ve vhodných uzlech sı́tě. Důležitou vlastnostı́ je také ochrana proti ztrátě dat. Prováděnı́ vzdálených operacı́ s daty v úložištı́ch se týká předevšı́m možnosti iniciovat přenos dat z jednoho úložiště na druhé bez toho, aby přenášená data tekla přes mı́sto v sı́ti, ze kterého byl přenos dat iniciován. Tedy z uzlu C můžeme spustit přenos dat z A do B a to tak, že uzlu A řekneme, že má přenést data do B. Data tečou přı́mo z A do B mimo uzel C. Tuto vlastnost má i protokol FTP, ale v praxi se téměř nelze setkat se serverem, který by ji podporoval. Protokol IBP by tedy měl umožnit řešit napřı́klad tuto modelovou situaci. Mějme klientské uzly A a B, které jsou spojeny pomalou linkou. K uzlu A je řádově rychlejšı́ linkou připojen datový sklad X a k uzlu B je podobně rychlou linkou připojen datový sklad Y. Sklady X a Y jsou spojeny stejnou linkou jako A a B. A chce odeslat velké množstvı́ dat pro B, ale nechce čekat dlouhou dobu, než se data z A do B po pomalé lince přenesou. Proto uložı́ data do datového skladu X, což zabere řádově méně času a následně dá X přı́kaz, aby přenesl data do skladu Y. Operace z X do Y již probı́há nezávisle na A a uživatel uzlu A může tedy vypnout počı́tač a jı́t domů. Předtı́m ale pošle patřičnou informaci uživateli uzlu B, aby si B mohl začı́t vyzvedávat data ze skladu Y. Pokud si mezi sklady X a Y představı́me vı́ce dalšı́ch skladů vzájemně propojených různými linkami a uvědomı́me si, že přenášená data mohou být fragmentována a každý fragment může putovat přes jiné sklady po jiných linkách, a tedy vı́ce fragmentů může po sı́ti putovat paralelně, teprve pak si uvědomı́me možnosti a sı́lu IBP protokolu. 15 5.2. STRUČNÝ POPIS PROTOKOLU IBP Autentizace na rozumné úrovni nenı́ triviálnı́ proces, a proto se může stát úzkým hrdlem komunikace. Z tohoto důvodu byl IBP protokol od autentizace uživatelů oproštěn. Životnost dat v úložišti je omezena stejně tak jako jejich maximálnı́ velikost, a proto, i když libovolný uživatel data do úložiště zapı́še, zabraný prostor se v konečném čase uvolnı́. Každý zapsaný blok dat bude označen náhodně tvořeným klı́čem, který zná pouze ten, kdo data ukládal, a tento klı́č ho opravňuje provádět na datech dalšı́ operace. Nenı́ bez zajı́mavosti, že požadavek na silnějšı́ autentizaci uživatele v IBP komunikaci byl přece jen později vznesen a je jednı́m z problémů, který se v rámci této práce pokusı́me vyřešit. 5.2 Stručný popis protokolu IBP Protokol IBP je bezstavový protokol založený na výměně textových zpráv mezi klientem a serverem. Zpráva se sestává z textových polı́ oddělených mezerou a celá zpráva je ukončena znakem nového řádku. Obvyklý význam textových polı́ zprávy je následujı́cı́: • verze protokolu • čı́slo IBP přı́kazu • parametry IBP přı́kazu Odpověd’ serveru na přı́kaz od klienta, pak má zpravidla tento tvar: • návratový kód provedené operace • upřesňujı́cı́ informace 5.2.1 Přı́klad uloženı́ dat na server 0 2 IBP-0riGA7EAypMlvRkqz4uXnRIbDj9aipe8TEu2LC9qHiKuBp6MaHR0W1tE6JYJCcUUAjN k5ejajIPjR5Z1ZhsaCPjRwsyIkWMQGnbni0JwhtijJCcgBCGwt8A1 1188414977 1024 1000 Význam jednotlivých polı́: 1. čı́slo verze 2. čı́slo přı́kazu Store 3. klı́č pro práci s daty 4. typ operace pro jakou je klı́č určen 5. velikost dat 6. časový limit pro komunikaci Přı́kaz Store může server ukončit touto odpovědı́: -2 1010 Význam jednotlivých polı́: 1. čı́slo chyby 2. počet přenesených bajtů 16 5.3. PŘÍKAZY IBP PROTOKOLU 5.3 Přı́kazy IBP protokolu Základnı́ přı́kazy IBP protokolu verze 1.4 jsou: • Allocate • Store • Load • Copy • Mcopy • Manage • Status 5.3.1 Allocate Alokuje zvolenou velikost datového prostoru na cı́lovém serveru na zvolenou dobu. Server vracı́ množinu capabilit, což jsou řetězce, kterými následně klient identifikuje svůj alokovaný prostor na serveru. Řetězce jsou tři a sloužı́ k psanı́ (READ), čtenı́ (WRITE) a správě (MANAGE) dat uložených v alokovaném prostoru na serveru. 5.3.2 Store Uložı́ data na alokované mı́sto na serveru. Mı́sto i server jsou identifikovány pomocı́ capabilit pro zápis (write capability). Server vracı́ velikost zapsaných dat. 5.3.3 Load Načte data z alokovaného mı́sta na serveru. Mı́sto i server jsou identifikovány pomocı́ capabilit pro čtenı́ (read capability). Server pošle data. 5.3.4 Copy (Send) Pošle data z jednoho serveru na druhý. Klient musı́ zajistit capability pro čtenı́ ze zdrojového serveru, který přenos dat bude iniciovat a capability pro zápis na cı́lovém serveru, na který budou data ukládána. 5.3.5 Mcopy Obdoba Copy s tı́m rozdı́lem, že cı́lových serverů může být vı́ce jak jeden. 5.3.6 Manage Umožňuje klientovi provést některou ze správnı́ch funkcı́ nad alokovaným prostorem. Zvýšit nebo snı́žit čı́tač referencı́ na alokovaný prostor, zjistit stav prostoru atd. Alokovaný prostor je identifikován pomocı́ capabilit pro správu (manage capability). 17 5.3. PŘÍKAZY IBP PROTOKOLU 5.3.7 Status Umožňuje čı́st a měnit některé důležité vlastnosti datového skladu. Jde o maximálnı́ velikost uložených dat, maximálnı́ dobu uloženı́ dat atd. Klient tedy k operacı́m s daty potřebuje znát přı́slušné capability, které obdržı́ bud’ alokacı́ mı́sta na serveru přes přı́kaz Allocate, nebo jsou mu předány třetı́ stranou. 5.3.8 Přı́klad Ukažme si jednoduchý pseudokód jehož cı́lem bude uložit data do skladu A, přenést je do skladu B a načı́st je ze skladu B. mnozina_capabilit cap_A, cap_B; velikost_data size; vlastnosti_dat attrib; byte out_buffer[size], in_buffer[size]; cap_A = IBP_allocate(A, size, atrib); IBP_store(cap_A.write, out_buffer, size); IBP_B = IBP_allocate(B, size, atrib); IBP_copy(cap_A.read, cap_B.write, size); IBP_load(cap_B.read, in_buffer, size); Přesný popis API protokolu IBP verze 1.4 pro jazyk C naleznete v dokumentu Internet Backplane Protocol: C API 1.4 3 . 3. http://loci.cs.utk.edu/ibp/documents/IBPClientAPI.pdf 18 Kapitola 6 Zabezpečenı́ protokolu IBP Cı́lem této práce je navrhnout a implementovat zabezpečenı́ IBP protokol proti útokům jako jsou odposlech přenášených dat, modifikace přenášených dat či metoda opakovánı́ odposlechnuté sekvence. V rozporu s původnı́ myšlenkou IBP datových skladů jakožto skladů, do kterých může libovolný uživatel ukládat data, vznikl také požadavek na autentizaci uživatele. Zabezpečenı́ jsme se rozhodli implementovat do poslednı́ verze IBP, tedy do verze 1.4.0.2 z dubna roku 2005. 6.1 Existujı́cı́ řešenı́ Domovská stránka Laboratoře pro logistické počı́tánı́ a sı́tě (LoCI4 ) University v Tennessee, která vyvı́jı́ protokol IBP, se o zabezpečenı́ zmiňuje jen velmi sporadicky. V archivu zpráv pro rok 20035 je zmı́nka o IBP přes SSL v souvislosti s odposlechem capabilit posı́laných sı́tı́ při alokaci mı́sta v IBP skladu. Zpráva řı́ká, že pomocı́ SSL půjde odposlechu zabránit. Dále je již zmiňováno jen zabezpečenı́ typu konec – konec. Dalšı́ informace o stavu implementace SSL v IBP je taktéž na webové stránce LoCI, a to v sekci často kladených otázek. Otázka znı́: „Použı́vá IBP SSL/TSL nebo jiný zabezpečovacı́ mechanismus?“. Odpověd’ řı́ká, že nynı́ ne, ale verze s SSL/TSL se vyvı́jı́ a bude k dispozici, jakmile skončı́ finálnı́ testovánı́. Bohužel, nenı́ známo, ze kterého data tato zpráva pocházı́. Poslednı́ zmı́nkou je otázka z května roku 2006 položená v diskusnı́ skupině Loci-devel6 . Tazatel se ptá, zda existujı́ nějaké dokumenty ohledně SSL zabezpečenı́ IBP protokolu a zda SSL pokrývá jen komunikaci přes TCP/IP. Bohužel žádné dokumenty nejsou a SSL má šifrovat TCP/IP komunikaci, zejména řı́dı́cı́ zprávy IBP protokolu. Tazatelem byl vedoucı́ mé práce, Mgr. Lukáš Hejtmánek, a odpověd’ pocházı́ přı́mo od vedoucı́ho výzkumu IBP protokolu, pana Scotta Atchleyho. I přes zprávy, které spı́še naznačovaly, že zabezpečenı́ nenı́ pro protokol IBP zatı́m vůbec implementováno, jsem se pustil do pátránı́ ve zdrojových kódech, zda neobsahujı́ alespoň přı́pravu pro toto vylepšenı́. Zjistil jsem, že poslednı́ verze IBP protokolu již některé prvky bezpečnosti obsahuje. Jak na straně serveru, tak na straně klienta jsou naprogramovány funkce, které se podı́lejı́ na vytvořenı́ SSL spojenı́. Na straně serveru je struktura nesoucı́ informace o vytvořeném spojenı́ rozšı́řena o přı́znak šifrovaného spojenı́ a o řetězec cn, který je určen pro jméno subjektu stojı́cı́ho na klientské straně. typedef struct ibp_connection { 4. 5. 6. http://loci.cs.utk.edu/ http://loci.cs.utk.edu/news/ http://lists.cs.utk.edu/pipermail/loci-devel/2006-May/000199.html 19 6.1. EXISTUJÍCÍ ŘEŠENÍ /* connection handler */ int fd; /* connection status */ IBP_CONN_STATUS status; /* request sent on the connection */ struct ibp_request *request; /* the time connection start to wait data */ time_t stime; int authenticated; char *cn; char *ou; /* link to next connection structure */ struct ibp_connection *next; } IBP_CONNECTION; Server je v závislosti na direktivě pro kompilaci zkompilován bud’ v režimu nešifrovaných nebo šifrovaných spojenı́. Server nepodporuje obojı́ typ spojenı́ současně, na rozdı́l od klienta. Spojenı́ se tedy šifruje nikoliv na požadavek klienta, ale na požadavek serveru, a pokud klient nevyhovı́ serveru, pak spojenı́ nelze navázat. Navazovánı́ spojenı́ mezi klientem a serverem vyžadujı́cı́m zabezpečené probı́há následujı́cı́m způsobem: 1. klient naváže nešifrované spojenı́ se serverem 2. klient odešle IBP přı́kaz 3. server přı́kaz přijme, a pokud stávajı́cı́ spojenı́ nenı́ šifrované, pak odešle požadavek na zašifrovánı́ spojenı́ 4. klient odpovı́, že čeká na přijetı́ šifrovaného spojenı́ 5. server vytvářı́ spojenı́ 6. ověřı́ se formát a správnost certifikátů, kterými se prokazuje jak server, tak klient 7. spojenı́ je označeno jako bezpečné Algoritmus je implementován pomocı́ knihovny OpenSSL7 tak, jak je popsáno, s tı́m rozdı́lem, že po označenı́ spojenı́ za bezpečné je bezpečnostnı́ kontext zrušen a spojenı́ tedy dále pracuje jako nešifrované. Pravděpodobně tedy současný stav umožňuje pouze ověřenı́ identit serveru a klienta na základě certifikátů. 7. http://www.openssl.org/ 20 6.2. VÝHODY A NEVÝHODY STÁVAJÍCÍHO ŘEŠENÍ Ukázka serverové strany navazovánı́ bezpečného spojenı́: /* connect to client using ssl */ ctx = ibpGetSrvSSLCTX(); ssl = SSL_new(ctx); SSL_set_fd(ssl,fd); if ( SSL_connect(ssl) <= 0 ){ SSL_free(ssl); return(IBP_E_AUTHENTICATION_FAILED); } /* get client certificate */ if ( SSL_get_verify_result(ssl)!= X509_V_OK){ SSL_free(ssl); return(IBP_E_AUTHENTICATION_FAILED); } peer=SSL_get_peer_certificate(ssl); X509_NAME_get_text_by_NID(X509_get_subject_name(peer), NID_commonName,peer_cn,256); if ( conn->cn != NULL ){ free(conn->cn); } conn->cn = strdup(peer_cn); if ( conn->cn == NULL ){ fprintf(stderr,”Out of memory!\n”); exit(-1); } conn->authenticated = 1; SSL_free(ssl); fcntl(fd,F_SETFL,flags); return (IBP_OK); Za zmı́nku stojı́ volánı́ funkce SSL free, která uvolnı́ SSL kontext a zrušı́ tak šifrovánı́. To, že dosavadnı́ stav implementace umožňuje jen autentizaci na základě certifikátů je podpořeno i tı́m, že ve zdrojových kódech se vůbec nevyskytuje volánı́ funkcı́ SSL read a SSL write, které sloužı́ k výměně dat přes SSL spojenı́. 6.2 Výhody a nevýhody stávajı́cı́ho řešenı́ Vzhledem k tomu, že k plánovaným úpravám IBP protokolu za účelem zabezpečenı́ nenı́ žádná dokumentace, dá se těžko posoudit, zda autoři zvolili správný směr. Problém ale vidı́m již v tom, 21 6.2. VÝHODY A NEVÝHODY STÁVAJÍCÍHO ŘEŠENÍ že o zabezpečenı́ komunikace rozhoduje server a klient do toho vlastně nemá co mluvit. Bud’ se zabezpečenı́m souhlası́, nebo ne. Pokud ne, žádná komunikace se nekoná. Samozřejmě tato vlastnost může být žádána v určitých podmı́nkách, v zásadě by ale vhodnějšı́m modelem bylo, aby o úrovni zabezpečenı́ mohl rozhodovat i klient. Při současném návrhu také nenı́ možné provozovat server, který by akceptoval jak zabezpečená, tak i nezabezpečená spojenı́. Pokud bychom se drželi odpovědi, kterou nám poskytl vedoucı́ výzkumu, pak vidı́me, že šifrovány budou pouze řı́dı́cı́ zprávy IBP protokolu, ne však data, která budou čtena či psána do datového skladu. Tomu ale odporuje dosavadnı́ stav implementace a využitı́ SSL. SSL aplikuje šifrovánı́ na celý komunikačnı́ kanál, tedy i na přenášená data. Striktnı́ šifrovánı́ celé komunikace nemusı́ být vždy žádáno z výkonnostnı́ch důvodů a naopak nemožnost šifrovat i data může znamenat bezpečnostnı́ problém. Zde by se pravděpodobně autoři spoléhali na šifrovánı́ dat na úrovni LoRS vrstvy. V současném stavu nenı́ prováděna ani autorizace ani autentizace a nenı́ viditelná žádná interakce s jinými vrstvami logistické sı́tě za účelem autorizace či autentizace. 22 Kapitola 7 IBP protokol v kontextu virtuálnı́ch organizacı́ Cı́lem této práce je zabezpečenı́ IBP protokolu, což samo o sobě může působit samoúčelně. Ve skutečnosti se jedná jen o část projektu, jehož cı́lem je nasadit bezpečné logistické sı́tě ve virtuálnı́ch organizacı́ch. Potřeba distribuovaných datových skladů vzrůstá v mnoha odvětvı́ch výpočetnı́ techniky. Jednı́m z nich jsou gridy, pro které již existuje několik projektů v oblasti datových skladů, napřı́klad DataGrid nebo DataTag. Základnı́m návrhem na řešenı́ vztahů mezi subjekty v gridu je systém virtuálnı́ch organizacı́. Virtuálnı́ organizace řešı́ předevšı́m autentizaci, autorizaci a členstvı́ uživatelů což jsou služby, které logistické sı́tě, zejména IBP protokol, v současné době nepodporujı́. Operace s daty v prostředı́ gridu se obecně sestává z následujı́cı́ch kroků: 1. prohledánı́ metadata katalogu za účelem překladu logického názvu souboru na jedinečný identifikátor 2. prohledánı́ katalogu replik za účelem překladu jedinečného identifikátoru na storage URL 3. storage resource manager (SRM) vyhledá skutečné umı́stěnı́ dat a protokol pro přı́stup k nim a vytvořı́ transfer URL 4. klient za pomocı́ údajů v transfer URL provede operaci s daty napřı́klad pomocı́ GridFTP 7.1 Jak se to řešı́ dnes Možnostı́ jak řı́dit přı́stup k datům v gridech, je užitı́ specializovaného software. Tedy uživatel musı́ mı́t aplikaci, která spolupracuje v rámci gridu s patřičnými službami, což dohromady umožňuje řı́dit přı́stup k datům. Takovou aplikacı́ jsou gLite I/O server a klient. Druhou variantou je zajistit uživatelům přı́stup k souborům, jako by byly uloženy lokálně. V tomto přı́padě je nutné vytvořit mapovánı́ mezi lokálnı́mi identifikátory uživatelů a skupin a identifikátory v gridu. Za účelem dosáhnout řı́zenı́ přı́stupu k jednotlivým souborům je rozhodovánı́ o udělenı́ přı́stupu přeneseno na Storage Resource Manager a na samotný datový sklad. SRM a datový sklad náležı́ k poskytovateli služby, přičemž v rámci jedné virtuálnı́ organizace může působit vı́ce poskytovatelů. V přı́padě uloženı́ replik souborů na servery různých poskytovatelů vznikne problém se synchronizacı́ mapovanı́ identifikátorů a nastavenı́ přı́stupových práv. Teoreticky synchronizace možná je, ale zatı́m nenı́ v plánu ji implementovat. Řı́zenı́ práv je na úrovnı́ základnı́ho mechanismu Unixových práv a žádná implementace v současnosti nepodporuje řı́zenı́ přı́stupu pomocı́ access control list (ACL) kompatibilnı́ch s normou POSIX. 23 7.2. POŽADAVKY NA LOGISTICKÉ SÍTĚ 7.2 Požadavky na logistické sı́tě Cı́lem tedy je přepracovat logistické sı́tě tak, aby splňovaly požadavky na práci ve virtuálnı́ch organizacı́ch, tedy zajistit podporu pro autentizaci, autorizaci a ověřovánı́ přı́slušnosti. Tyto požadavky kladou nároky na úpravu mnoha vrstev logistické sı́tě. Ke stávajı́cı́m vrstvám byl ještě přidán manažer metadat, který má za úkol sejmout z uživatele povinnost skladovat metadata tvořı́cı́ eXnode. Jde o obdobu metadata katalogu, která na základě logického jména souboru dohledá patřičný eXnode s informacı́ o tom, kde jsou data souboru umı́stěna. Veškeré úpravy byly navrhovány v souladu s těmito požadavky: • Uživatel musı́ být autentizován u každé služby • Uživatel musı́ být autorizován k použitı́ služeb • Autorizaci musı́ být možno odvolat To vyžaduje, aby uživatel prokázal svou totožnost na úrovni metadata manažeru, L–Bone serveru a na IBP serverech. Metadata manažer musı́ poskytnout metadata jen těm uživatelům, kteřı́ na to majı́ oprávněnı́. L–Bone server musı́ poskytnout seznam IBP serverů také jen oprávněným uživatelům. A nakonec IBP server také obsloužı́ jen ty uživatele, kteřı́ na to majı́ právo. Požadavkem je také možnost řı́dit přı́stup k datovým skladům zvlášt’ pro každého uživatele nebo uživatelskou skupinu, a poskytnout rozšı́řené vlastnosti pro řı́zenı́ přı́stupu k souborům. Napřı́klad omezit čas, po který je soubor přı́stupný pro určitou skupinu uživatelů, nebo určit hodnotu zatı́ženı́ serveru, po jejı́mž překročenı́ bude pro určitou skupinu či jednotlivce přı́stup k souboru zamı́tnut. Tyto vlastnosti určuje majitel souboru. 24 Kapitola 8 Návrh úprav Důležitou vlastnostı́ navrhovaných úprav je prokázánı́ přı́slušnosti a kontrola oprávněnı́ na všech důležitých vrstvách logistické sı́tě. To zaručuje, že žádná fáze přı́stupu k datům nemůže být obejita, což má za cı́l zvýšit bezpečnost. Navrhovaná architektura se skládá ze samostatných služeb, které pro vykonánı́ své úlohy nepotřebujı́ kontaktovat žádné jiné služby. Předpokládáme sice, že virtuálnı́ organizace užı́vajı́ systém veřejných a soukromých klı́čů, ale vzhledem k tomu, že se uživatelské certifikáty nesoucı́ veřejné klı́če mohou v průběhu času měnit, a navı́c jeden uživatel může vlastnit vı́ce certifikátů, tak uživatelské certifikáty pro identifikaci uživatele nepoužijeme. Součástı́ rozšı́řenı́ certifikátů X509v3 jsou atributy identifikujı́cı́ uživatele (UID) a skupinu (GID), které nezávisı́ na veřejném klı́či neseném v certifikátu, ale jsou jeho podepsanou součástı́. Podpis je samozřejmě proveden důvěryhodnou autoritou. Existuje tedy mechanismus, který mapuje uživatelský certifikát (vı́ce certifikátů) na proxy certifikát s patřičnými atributy identifikujı́cı́mi uživatele a skupinu. 8.1 Proces autorizace 1. uživatel zı́ská proxy certifikát s identifikačnı́mi atributy (UID, GID) od VOMS (Virtual Organization Membership Server) serveru. Předpokládáme, že VOMS server vydá potřebný certifikát jen oprávněnému uživateli z dané virtuálnı́ organizace. 2. uživatel kontaktuje metadata manažer, prokáže se proxy certifikátem a požádá o informace o konkrétnı́m souboru. Metadata manažer na základě identifikačnı́ch atributů z certifikátu a přı́stupového seznamu (ACL) rozhodne o vydánı́ metadat klientovi. Platnost vydaných metadat je časově omezena. 3. uživatel kontaktuje L–bone server za účelem zı́skat seznam IBP serverů a L–Bone serverem podepsané oprávněnı́ na užitı́ těchto serverů. Podepsané oprávněnı́ zahrnuje identifikaci uživatele a je tedy platné jen pro jednoho konkrétnı́ho uživatele. Platnost oprávněnı́ je časově omezena. V přı́padě, že se jedná o operaci s existujı́cı́mi daty, pak nenı́ nutné zı́skat seznam IBP serverů. 4. uživatel kontaktuje IBP server, poskytne mu patřičnou část metadat a podepsanou položku ze seznamu IBP serverů, který obdržel od L–Bone serveru. IBP server zkontroluje platnost metadat a ověřı́ podpis. Pokud vše souhlası́, uživatel může provádět operace s daty. Požadavek na autentizaci a autorizaci u všech služeb je dodržen, nebot’ uživatel pro kontaktovánı́ IBP serveru potřebuje údaje od L–Bone serveru i od metadata manažeru. Oběma službám musı́ prokázat svou totožnost a oprávněnı́. Pokud se uživateli nepodařı́ zı́skat údaje od jedné ze 25 8.1. PROCES AUTORIZACE služeb, pak nesložı́ dohromady potřebné informace pro IBP server, a tedy nemůže IBP serveru prokázat ani svou totožnost, ani patřičná oprávněnı́. Obrázek 8.1: Autentizačnı́ a autorizačnı́ proces v logistických sı́tı́ch ve VO Hlavnı́ rozdı́l mezi stávajı́cı́mi metodami autentizace a autorizace při práci s daty v prostředı́ gridů a navrhovanou metodou uplatněnı́ logistických sı́tı́ je ve fázi, kdy probı́há mapovanı́ uživatelského certifikátu na uživatelské id a na id skupiny. Dnešnı́ běžné metody provádějı́ toto mapovánı́ až na úrovni datového skladu, což v distribuovaném prostředı́ neumožňuje zaručit konzistentnı́ pohled na přı́stupová práva k souborům. Navrhovaný přı́stup provádı́ autorizaci pomocı́ jedné služby a tou je metadata manažer. Tı́m je zaručena ucelená správa přı́stupových práv k souborům uloženým distribuovaně v různých datových skladech. 26 Kapitola 9 Řešenı́ Aby IBP protokol splňoval výše uvedené vlastnosti, museli jsme navrhnout jeho vhodné úpravy a rozšı́řenı́. Jak již bylo řečeno, původnı́ verze nepodporovala autentizaci, autorizaci ani šifrovaný přenos dat. Vše bylo nutné navrhnout od základů. Proces autentizace a autorizace musı́ být svázán s informacemi, které klient zı́ská z L–Bone serveru, a pokud je proces úspěšný, mělo by být navázáno částečně šifrované (crypto) nebo plně šifrované (full crypto) spojenı́. Samotné spojenı́ by mělo být odolné proti odposlechu, změně obsahu dat a duplicitnı́m zprávám. Samotný proces autentizace a autorizace by měl zabránit zneužitı́ datového skladu neoprávněným klientem. Pro autentizaci a autorizaci jsme zvolili systém soukromých a veřejných klı́čů s patřičným rozšı́řenı́m pro přenos atributů v certifikátu spolu s veřejným klı́čem. Tato metoda je velmi použı́vaná a široce podporovaná, zvláště v oblasti gridů a virtuálnı́ch organizacı́, což zaručı́ snadné nasazenı́ našeho projektu v praxi. Vlastnı́ spojenı́ je pak šifrováno symetrickou šifrou, která je výrazně rychlejšı́ než nesymetrické šifrovánı́. Neznamená to však, že symetrické šifrovánı́ je časově nenáročné. Přenos balı́ku dat bez šifrovánı́ je stále výrazně rychlejšı́ než v přı́padě, kdy jsou data před přenosem zašifrována a po přenosu dešifrována. Právě z tohoto důvodu jsme rozšı́řenı́ protokolu IBP navrhli tak, aby bylo umožněno šifrovat celou komunikaci, tedy přı́kazy i data, nebo šifrovat jen přı́kazy nebo nešifrovat vůbec nic. 9.1 Mechanismus autentizace a autorizace Autorizačnı́ proces probı́há na úrovni VOMS, metadata manažeru a L–Bone serveru. Klient se prokáže VOMS serveru svým certifikátem, který vydá proxy certifikát s atributy, které jednoznačně identifikujı́ uživatele v rámci gridu. Metadata manažer na základě proxy certifikátu a jeho atributů provede hlavnı́ autorizačnı́ rozhodnutı́. Pokud je kladné, metadata manažer vydá metadata. L–Bone server taktéž na základě proxy certifikátu a jeho atributů vydá seznam IBP serverů. Každá položka v seznamu je podepsána soukromým klı́čem L–Bone serveru spolu s jednoznačnou identifikacı́ uživatele, který o seznam zažádal. V této chvı́li je klient autorizován a může komunikovat přı́mo s IBP serverem. Klient vybere jeden server ze seznamu IBP serverů, který zı́skal od L–Bone serveru, a odešle mu svůj veřejný klı́č a podepsaný odkaz na IBP server od L–Bone serveru. IBP server ověřı́ pomocı́ veřejného klı́če L–Bone serveru, zda podpis IBP serveru pocházı́ od důvěryhodného L–Bone serveru, a dále ověřı́, zda spojenı́ navázal stejný uživatel, který požádal L–Bone server o seznam IBP serverů. Také je ověřeno, jestli IBP server je ten správný server, s nı́mž se chtěl klient spojit. Toto je provedeno současně s ověřovánı́m podpisu od L–Bone serveru. Pokud vše souhlası́, IBP server vygeneruje klı́č pro symetrickou šifru, zašifruje ho veřejným klı́čem klienta a klientovi ho odešle. Klient disponuje svým soukromým klı́čem, dešifruje, a zı́ská tedy symetrický klı́č, který mu zaslal IBP server. Tı́m je ustanoveno šifrované spojenı́. Klient se 27 9.2. NÁVRH IMPLEMENTACE prokázal IBP serveru jako důvěryhodný, a jak server tak klient, obdrželi symetrický šifrovacı́ klı́č, kterým bude dalšı́ komunikace utajena. Obrázek 9.1: Časový průběh navazovánı́ bezpečného spojenı́ v IBP protokolu V přı́padě, že by se útočnı́k chtěl vydávat za konkrétnı́ho klienta a použil k tomu jeho veřejný klı́č, pak může obdržet seznam IBP serverů od L–Bone serveru. Může také navázat spojenı́ s IBP serverem, který dokonce vygeneruje klı́č pro symetrickou šifru, a tento klı́č klientovi i zašle, ale symetrický klı́č je šifrován veřejným klı́čem klienta. To znamená, že k jeho rozšifrovánı́ je zapotřebı́ mı́t soukromý klı́č klienta, který ale útočnı́k nemá k dispozici. Pokud by útočnı́k měl jak veřejný, tak soukromý klı́č klienta, pak došlo k prolomenı́ bezpečnosti v jiné části komunikace napřı́klad, mezi klientem a VOMS serverem, přı́padně byla bezpečnost porušena na jiné než sı́t’ové úrovni. 9.2 Návrh implementace Stávajı́cı́ IBP API má podporu pro funkce alokace mı́sta v datovém skladu, uloženı́ dat do skladu, načtenı́ dat ze skladu, překopı́rovánı́ dat mezi sklady a správu dat. Z této sady funkcı́ jsme se rozhodli šifrovat všechny krom funkce pro zjištěnı́ stavu skladu (Status). Vznikly tedy ekvivalenty stávajı́cı́ch funkcı́ doplněné o šifrovánı́ a byla doplněna jedna zcela nová funkce sloužı́cı́ pro autentizaci a navázánı́ šifrované komunikace. Původnı́ funkce jsme se rozhodli zachovat v plné šı́ři z důvodu zpětné kompatibility a v rámci rozhodnutı́, že ani server, ani klient nebudou apriori vynucovat šifrované spojenı́. 28 9.2. NÁVRH IMPLEMENTACE Tabulka 9.1 Nové funkce v klientském IBP API Funkce Význam ibp init inicializuje IBP knihovnu IBP auth create vytvořı́ strukturu pro autentizaci IBP auth provede autentizaci (klient zpravidla neprovádı́ ručně) IBPs allocate alokovánı́ prostoru na IBP serveru IBPs store uložı́ data na IBP server IBPs load přečte data z IBP serveru IBPs copy přenos dat z jednoho IBP serveru na jiný IBP server IBPs manage funkce pro správu alokovaného prostoru a serveru Spojenı́ s IBP serverem je obstaráno automaticky při volánı́ funkce, která komunikaci se serverem vyžaduje. Pokud je k dispozici vyhovujı́cı́ volné spojenı́ mezi klientem a IBP serverem, pak je toto spojenı́ použito přednostně před vytvářenı́m spojenı́ nového. Tento přı́stup jsme zvolili za účelem maximálnı́ho snı́ženı́ časových ztrát při komunikaci. Při každém novém spojenı́ je prováděna autentizace klienta na serveru spolu s generovánı́m a výměnou symetrického klı́če, což zabere nezanedbatelný čas. Pokud použijeme existujı́cı́ spojenı́, tento čas ušetřı́me. Ukázka užitı́ zabezpečených funkcı́ pomocı́ pseudokódu. Vezměme přı́klad z kapitoly 5.3.8 a převed’me jej na zabezpečenou verzi. Jde o alokaci mı́sta na IBP serveru A, uloženı́ dat, přenos dat na jiný IBP server B a načtenı́ dat ze serveru B: mnozina_capabilit cap_A, cap_B; velikost_data size; vlastnosti_dat attrib; byte out_buffer[size], in_buffer[size]; autentizačnı́_struktura auth_A, auth_B; IBP_init(); auth_A = IBP_auth_create(A); cap_A = IBPs_allocate(A, auth_A, size, atrib); IBPs_store(auth_A, cap_A.write, out_buffer, size); auth_B = IBP_auth_create(B); IBP_B = IBPs_allocate(auth_B, B, size, atrib); IBPs_copy(auth_A, cap_A.read, cap_B.write, size); IBPs_load(auth_B, cap_B.read, in_buffer, size); Přehlednost kódu se nijak výrazně nezhoršila, což bylo také jednı́m z důležitých požadavků. Všimněme si, že přibyla navı́c jedna nová datová struktura nazvaná autentizačnı́ struktura, která je předávána jako parametr u všech zabezpečených komunikačnı́ch funkcı́ IBP API. Tato struktura sloužı́ k urychlenı́ navazovánı́ spojenı́ ze strany klienta. Obsahuje údaje, které jsou předem připraveny ve funkci IBP auth create do podoby, kdy je stačı́ jen odeslat serveru. Přı́prava spočı́vá v prováděnı́ kryptografických operacı́, které by bylo zbytečné provádět opakovaně při navazovánı́ každého nového spojenı́. Opět tedy ušetřı́me čas. Spojenı́ je proti odposlechu a změně obsahu chráněno šifrovánı́m, což ale nebránı́ útočnı́kovi 29 9.2. NÁVRH IMPLEMENTACE odposlechnout sekvenci přı́kazů a tu pak zopakovat. Aby tomuto útoku opakovánı́m bylo zabráněno, je většina přı́kazů, které si klient se serverem vyměnı́, čı́slována. Čı́slujı́ se jak odchozı́, tak přı́chozı́ zprávy a klient i server držı́ v rámci jednoho spojenı́ čı́tač pro přı́chozı́ a odchozı́ zprávy. Odchozı́ zprávy jsou oraženy aktuálnı́m čı́slem z čı́tače odchozı́ch zpráv, u přı́chozı́ch zpráv je kontrolováno jejich pořadové čı́slo s čı́tačem přı́chozı́ch zpráv. V přı́padě, že přı́chozı́ zpráva má neočekávané pořadové čı́slo, je spojenı́ ukončeno. 9.2.1 Úpravy klienta Klientské API bylo rozšı́řeno o zabezpečené funkce pro alokaci, přenos dat, navázánı́ spojenı́ a inicializaci IBP knihovny. Spolu s těmito úpravami byla vytvořena nová struktura IBP authhandle sloužı́cı́ pro autentizaci. Tato struktura obsahuje tři základnı́ informace nutné pro autentizaci a navázánı́ spojenı́ mezi klientem a serverem: • certifikát klienta • privátnı́ klı́č klienta • podpis odkazu na IBP server od L–Bone serverem Data v této struktuře jsou svázána s jednı́m klientem a jednı́m IBP serverem. Nelze je tedy užı́t k navázánı́ spojenı́ napřı́klad na dva rozdı́lné IBP servery z jednoho klienta. Dále byl upraven seznam navázaných spojenı́ doplněnı́m dalšı́ch informacı́ o jednotlivých spojenı́ch. Princip navazovánı́ spojenı́ je jednoduchý. Každá provedená komunikace od klienta na server nenı́ ukončena uzavřenı́m spojenı́, ale pouze změnou přı́znaku spojenı́, který udává, zda je spojenı́ užı́váno či nikoliv. U každého spojenı́ jsou kromě jiného drženy tyto informace, které sloužı́ k vyhledávánı́ navázaných spojenı́: • jméno hostujı́cı́ho IBP serveru • port hostujı́cı́ho IBP serveru • stav použı́vané / nepoužı́vané • čas poslednı́ho použitı́ • stav zabezpečené / nezabezpečené • odkaz na strukturu IBP authhandle, pomocı́ nı́ž bylo spojenı́ navázáno Při požadavku na navázánı́ spojenı́ je nejprve prohledán seznam spojenı́, zda již vhodné spojenı́ neexistuje. U každého testovaného spojenı́ je zkontrolován parametr poslednı́ho použitı́. Pokud je rozdı́l systémového času a času poslednı́ho použitı́ většı́ než zvolená konstanta, pak je spojenı́ uzavřeno, odstraněno ze seznamu a pokračuje se v prohledávanı́ ostatnı́ch spojenı́ v seznamu. Každý požadavek na spojenı́ se serverem obsahuje tyto parametry: • jméno hostitelského serveru • port hostitelského serveru 30 9.2. NÁVRH IMPLEMENTACE • požadavek na zabezpečenı́ • strukturu IBP authhandle Při hledánı́ vhodného spojenı́ se nejprve hledá spojenı́ se stejným jménem a portem hostitelského serveru, následně se pak porovná, zda odpovı́dá požadavek na zabezpečenı́ se zabezpečenı́m nalezeného spojenı́. Pokud je požadováno zabezpečené spojenı́ a nalezené spojenı́ zabezpečené je, pak se porovnajı́ odkazy na strukturu IBP authhandle. Toto porovnánı́ odkazů sloužı́ k tomu, aby v klientské aplikaci určené pro vı́ce uživatelů nevyužı́val jeden uživatel spojenı́, které bylo vytvořeno jiným uživatelem, byt’ostatnı́ parametry spojenı́ jsou totožné. Pokud je vhodné spojeni nalezeno, je nejprve otestováno, zda nebylo uzavřeno na straně serveru. Jestliže uzavřeno bylo, pak je spojenı́ ze seznamu odstraněno. Pokud je ale vše v pořádku, je spojenı́ označeno jako aktivnı́, čas poslednı́ho použitı́ je nastaven na aktuálnı́ systémový čas a spojenı́ je předáno dalšı́m funkcı́m k použitı́. Pokud vhodné spojenı́ nalezeno nenı́, pak je vytvořeno spojenı́ nové a to nejprve jako nezabezpečené. Je-li zabezpečenı́ požadováno, pak je provedena patřičná komunikačnı́ sekvence po jejı́mž úspěchu je ke spojenı́ přidán odkaz na IBP authhandle strukturu, na jejı́mž základě bezpečné spojenı́ vzniklo a jsou vygenerována dvě náhodná čı́sla, která se v rámci spojenı́ přičı́tajı́ při odeslánı́ a přijetı́ zprávy. Na závěr je spojenı́ označeno jako bezpečné. 9.2.2 Úprava serverové části Server byl kompletně znovu napsán a zpřehledněn. Pracovnı́ cyklus serveru je velmi prostý. Hlavnı́ vlákno poslouchá na přı́slušné adrese a portu a při každém navázaném spojenı́ vytvořı́ instanci obslužného vlákna, kterému spojenı́ předá. Obslužné vlákno čeká na přı́chozı́ data v předaném spojenı́. Pokud data ve zvoleném časovém limitu nepřijdou, je spojenı́ spolu s vláknem ukončeno. Přijatá data jsou zpracována a jedná-li se o přı́kaz IBP protokolu, je podle obsahu dat rozhodnuto, která funkce serveru bude provedena. Po provedenı́ funkce se řı́zenı́ vracı́ obslužnému vláknu, které dále čeká na přı́chozı́ data až do vypršenı́ časového limitu. Vlastnost čekánı́ na dalšı́ data i po té, co server zpracuje IBP přı́kaz od klienta je užitečná v souvislosti s klientovou schopnostı́ využı́vat již otevřená spojenı́, což zvyšuje propustnost komunikace mezi klientem a serverem. Tı́m, že server ponechá spojenı́ otevřené po určitou dobu dává prostor klientovi, aby toto spojenı́ mohl opětovně použı́t a nemusel tak vytvářet spojenı́ nové. Je vhodné, aby klient měl nastavenou časovou konstantu, po kterou považuje otevřené spojenı́ za ještě použitelné, na hodnotu stejnou nebo menšı́, než je časová konstanta serveru udávajı́cı́ maximálnı́ dobu čekanı́ na přı́chozı́ data od klienta. Pokud by klient považoval spojenı́ za použitelné i po době delšı́, než po kterou server čeká na data, pak zbytečně docházı́ k prodlevě při vytvářenı́ spojenı́. Klient totiž najde vhodné spojenı́, pokusı́ se ho navázat, zjistı́, že spojenı́ bylo ukončeno druhou stranou, a musı́ hledat dalšı́ spojenı́ nebo vytvořit spojenı́ nové. 9.2.3 Implementace IBP protokolu v serveru Byly implementovány serverové protějšky pro funkce IBP auth, IBPs store, IBPs load, IBPs copy a IBPs manage. Funkce IBPs store a IBP store a funkce IBPs load a IBP load jsou implementovány společně v jednom bloku kódu. Zda je volána funkce zabezpečená nebo nezabezpečená se rozlišuje podle typu spojenı́. Pokud je šifrované, pak jde o zabezpečenou variantu, pokud 31 9.2. NÁVRH IMPLEMENTACE Obrázek 9.2: Pracovnı́ cyklus IBP serveru nešifrované, pak o původnı́ nezabezpečenou variantu. Formát a obsah dat v zabezpečených a nezabezpečených přı́kazech se přı́liš nelišı́, proto mohou zabezpečené i nezabezpečené funkce sdı́let velkou část společného kódu. Kompletně musela být vytvořena funkce pro zpracovánı́ přı́kazu IBPs copy. Tato funkce musı́ zajistit přenos dat na dalšı́ IBP server, přičemž přenos musı́ být šifrovaný dle požadavku klienta. Prvnı́ server vůči druhému se musı́ tvářit jako klient, musı́ se druhému serveru prokázat a zı́skat od něj symetrický šifrovacı́ klı́č. Nastává však problém, za koho se má server, který bude klientem, vydávat. Snadné by bylo, kdyby se vydával přı́mo za klienta, což by znamenalo, že by klient musel serveru, který bude přenos iniciovat, poskytnout svůj veřejný, ale i soukromý klı́č. Toto je samozřejmě nepřı́pustné a jednalo by se o porušenı́ základnı́ch bezpečnostnı́ch pravidel. Proto byla zvolena metoda, která zajı́mavým způsobem křı́žı́ postavenı́ obou serverů v rámci přenosu souboru. Křı́žı́ proto, protože při prvnı́ části transakce vystupuje server, který iniciuje přenos jako klient, následně však při vytvářenı́ bezpečného spojenı́ vystupuje spı́še jako server a při vlastnı́m přenosu souboru je zpět v roli klienta. Předpokládejme, že klient disponuje daty na serveru S1 a chce je přenést na server S2. Přesný postup je následujı́cı́: 1. klient alokuje prostor na S2 2. klient odešle požadavek na přenos souboru z S1 do S2, součástı́ požadavku jsou potřebné údaje, jako jsou capability pro uloženı́ dat na S2 a L–Bone serverem podepsaný odkaz na S2 server 32 9.2. NÁVRH IMPLEMENTACE 3. S1 server provede IBP getkey přı́kaz na S2 4. S2 odešle svůj veřejný klı́č S1 5. S1 vygeneruje šifrovacı́ klı́č pro symetrickou šifru, zašifruje jej pomocı́ veřejného klı́če S2 a odešle jej S2 6. S2 za pomoci svého soukromého klı́če dešifruje a zı́ská šifrovacı́ klı́č pro symetrické šifrovánı́ 7. S2 odešle potvrzenı́ S1 8. S1 odešle data S2 šifrovaná symetrickou šifrou Obrázek 9.3: Průběh přı́kazu zabezpečeného IBP copy V bodech 2 se S1 chová jako server pro klienta, v bodě 3 a 4 se zachová jako klient pro S2, dále v bodech 5 se z pohledu navazovánı́ bezpečného spojenı́ chová jako server pro S2 a nakonec v bodech 7 a 8 je opět klientem pro S2. Tato metoda zaručuje dodrženı́ obecných bezpečnostnı́ch pravidel a zároveň dodrženı́ klientova požadavku na úroveň zabezpečenı́ přenosu dat. V souvislosti s výše uvedeným postupem při prováděnı́ funkce IBPs copy byla vytvořena funkce IBP getkey a specializovaná varianta funkce IBPs store. Serverová funkce IBP getkey je zodpovědná za sdělenı́ veřejného klı́če serveru klientovi. V přı́padě IBPs copy si jeden server vyžádá veřejný klı́č od druhého serveru. Veřejný klı́č nenı́ utajovaná informace, proto nenı́ nutné, aby se ten, kdo veřejný klı́č požaduje, autentizoval a autorizoval. Specializovaná varianta funkce IBPs store se od klasického IBPs store lišı́ předevšı́m v tom, že při klasickém IBPs store je již předem provedena autentizace mezi klientem a serverem přes funkci IBP auth, zatı́mco u IBPs store pro IBPs copy se užı́vá dočasný symetrický klı́č, 33 9.3. NEDOSTATKY OPROTI NÁVRHU který si servery mezi sebou musı́ vyměnit. Tato výměna začı́ná přı́kazem IBP getkey a pokračuje jako součást právě specializované funkce IBPs store. Server obsluhujı́cı́ IBPs store v rámci IBPs copy tedy před přijetı́m capabilit a vlastnı́ch dat, přijme ještě symetrický klı́č zašifrovaný svým veřejným klı́čem. Po té, co symetrický klı́č zı́ská, je připraven k přijetı́ šifrovaných capabilit a přı́padně šifrovaných dat. Za účelem udržovánı́ informacı́ o otevřeném spojenı́ byla vytvořena struktura cl info. Pro každé nové spojenı́ přijaté serverem je vytvořena nová instance této struktury a je do nı́ vložen popisovač souboru přı́slušného spojenı́ a také je spojenı́ označeno jako nezabezpečené. Následně, je-li proveden IBP auth, je do struktury vložen veřejný klı́č klienta, vygenerovaný symetrický klı́č a pořadová čı́sla zpráv zı́skaná od klienta. Pokud vše proběhne úspěšně, je spojenı́ označeno jako zabezpečené. Instance struktury cl info je platná v rámci jednoho obslužného vlákna IBP serveru. Spolu s vláknem instance struktury zaniká. 9.3 Nedostatky oproti návrhu IBP server v současné fázi vývoje nesplňuje všechny požadavky, které byly kladeny při navrhovánı́ změn. Nejzávažnějšı́m nedostatkem je chybějı́cı́ ověřovánı́ podpisu odkazu na IBP server od L– Bone serveru na straně IBP serveru. Jak bylo psáno výše, klient zı́ská od L–Bone serverů seznam vhodných IBP serverů. Každý odkaz na IBP server v seznamu je podepsán privátnı́m klı́čem L– Bone serveru spolu s identifikacı́ klienta. Klient následně vybere jeden IBP server ze zı́skaného seznamu a spojı́ se s nı́m přes přı́kaz IBP auth. Během navazovánı́ spojenı́ klient pošle IBP serveru i odkaz na server podepsaný L–Bone serverem. IBP server má ověřit, zda tento odkaz byl opravdu podepsán důvěryhodným L–Bone serverem. A právě toto ověřovánı́ nenı́ v současné době ještě implementováno. Server také dosud neprovádı́ pravidelné odstraňovánı́ dat z datového úložiště. Všechna data uložená v IBP datovém úložišti majı́ nastavenu dobu, po kterou musı́ být v úložišti držena. Po uplynutı́ této doby mohou být data smazána. Tato vlastnost je jednı́m ze stěžejnı́ch mechanismů IBP protokolu. Během práce na zabezpečenı́ IBP protokolu tato schopnost serveru nebyla vyžadována, ale nejedná se o složitý mechanismus, a tedy bude brzo doprogramován. 34 Kapitola 10 Konkrétnı́ implementace Stávajı́cı́ zdrojové kódy klientského IBP API i IBP serveru byly napsány v jazyce C, konkrétně dodržovaly kompatibilitu s ANSI C a při volánı́ funkcı́ operačnı́ho systému byla dodržována norma POSIX. Tyto standardy jsme se rozhodli zachovat z důvodu co nejsnadnějšı́ přenositelnosti kódu mezi různým hardwarem a různými operačnı́mi systémy. Pro kompilaci projektu byla užita běžně dostupná utilita Make spolu s aplikacemi autoheader, autoconf a automake. Pro uživatele to tedy znamená, že při sestavovánı́ projektu musı́ provést na Unixových systémech známou proceduru sestávajı́cı́ se z posloupnosti skriptů: 1. configure 2. make 3. make install I tento postup jsme v přı́padě klientského IBP API z pochopitelných důvodu nechali nepozměněn. IBP server se jako projekt osamostatnil a momentálně je ve stádiu, kdy se kompiluje pouze utilitou Make bez podpory autoconfu atd. 10.1 Vlákna Server je implementován standardně pomocı́ vláken a i klientské API je navrženo a implementováno tak, aby mohlo pracovat v prostředı́ vláken. Vlákna jsou naprogramována pomocı́ standardnı́ho API pro práci s vlákny v systémech kompatibilnı́ch s normou POSIX. Jde o knihovnu pthread, která je navržena tak, aby v součinnosti s operačnı́m systémem plně využı́vala výhody vı́ceprocesorových a vı́cejádrových systémů. Tı́m, že knihovna dodržuje normu POSIX je zaručeno, užitı́ klientského API dohromady s dalšı́mi knihovnami, které jsou také POSIX kompatibilnı́. Vše za předpokladu, že budou dodrženy doporučené postupy pro práci s vlákny. Během programovánı́ jsem v souvislosti s vlákny dbal předevšı́m na práci programu s globálnı́mi daty, tedy s daty, která mohou být použita vı́ce vlákny současně. Tento problém se v obecné rovině řešı́ tak, že to vlákno, které sdı́lený prostředek hodlá použı́t, tento prostředek zamkne, a až práci s nı́m dokončı́, prostředek odemkne. Pokud se vlákno snažı́ zamknout prostředek, který je již zamčen jiným vláknem, pak se prováděnı́ vlákna zastavı́ a čeká se, až je prostředek odemknut. Následně je pak prostředek znovu uzamčen dosud čekajı́cı́m vláknem. Praxe se od teorie přı́liš nelišı́. K zamykánı́ se užı́vá tak zvaných mutexů a vlákna pak operujı́ s těmito mutexy. Pro každý sdı́lený prostředek je vytvořen jeden mutex a vlákna při přı́stupu ke sdı́lenému prostředku mutex zamknou a po skončenı́ práce mutex odemknou. 35 10.1. VLÁKNA V přı́padě serveru jsme pomocı́ mutexů ošetřili tyto sdı́lené prostředky: • quotas – struktura typu Gtree nese globálnı́ informace o využitı́ stanovených datových kvót • resources – struktura typu Gtree, ve které jsou uloženy informace o všech datových blocı́ch uložených v datovém skladu Sdı́lený prostředek quotas musı́ být uzamykán, protože by mohlo dojı́t k situaci, kdy jsou na datovém skladu paralelně ve dvou vláknech alokovány datové bloky přičemž během alokovánı́ prvnı́ho bloku dojde ke změně údaje o zbývajı́cı́m mı́stě v úložišti a tato změna je zapsána do quotas. To je v pořádku. Během zápisu nového údaje do quotas probı́há současně alokovánı́ druhého datového bloku v úložišti. Před alokovánı́m se ověřı́ v quotas, zda je v úložišti mı́sto. Snadno se může stát, že při alokovánı́ druhého bloku je z quotas přečtena hodnota, která odpovı́dá ještě hodnotě před alokovánı́m bloku prvnı́ho. To je prvnı́ závada, nebot’tak může dojı́t k alokovánı́ vı́ce mı́sta, než určuje kvóta. Navı́c operace alokovánı́ druhého bloku může proběhnout podstatně rychleji než operace s prvnı́m blokem, a tedy do quotas bude zapsán prvnı́ údaj po alokovánı́ bloku druhého a následně údaj, který odpovı́dá hodnotě po alokovánı́ bloku prvnı́ho. Vhodným zamykánı́m prostředku quotas se uvedených problémů vyvarujeme. Z podobných důvodů je zamykán i sdı́lený prostředek resources. V programu je použit ještě jeden mutex, který sloužı́ k zamezenı́ vı́cenásobného volánı́ funkcı́ z knihovny glib8 , které provádějı́ operace s typem Gtree. Klientská část obsahuje také dva důležité sdı́lené prostředky: • glbConnList – seznam otevřených spojenı́ • glbCache – vyrovnávacı́ pamět’pro DNS dotazy Všechna vlákna klientské aplikace sdı́lejı́ společný seznam navázaných spojenı́ i společnou vyrovnávacı́ pamět’ pro DNS dotazy. Tento přı́stup zvyšuje pravděpodobnost, že navazované spojenı́ již bude existovat v seznamu a také že prováděný DNS dotaz již bude mı́t odpověd’ ve vyrovnávacı́ paměti. Zvláště se seznamem spojenı́ je třeba pracovat opravdu bezpečně, jinak může dojı́t k tomu, že jedno vytvořené spojenı́ dané popisovačem souboru se budou snažit využı́t dvě vlákna, přı́padně, že jedno vlákno, vyžadujı́cı́ nezabezpečené spojenı́, najde vhodné existujı́cı́ spojenı́, které však bude zrovna ve fázi navazovánı́ spojenı́ zabezpečeného. Ukázka vkládánı́ nového spojenı́ do globálnı́ho seznamu spojenı́: CONNECTION *insertConnFd(CONNECTION *con) { CONNECTION *list; int pos = -1,i; time_t oldestTime = -1; CONNECTION *con1; 8. http://www.gtk.org/tutorial/c2025.html 36 10.1. VLÁKNA #if IBP_PERSISTENT_CONN initConnList(); list = glbConnList; #ifdef HAVE_PTHREAD_H pthread_mutex_lock(glbConnListLock); #endif closeIdleConnections(); for ( i = 0 ; i < glbMaxOpenConn ; i ++ ){ if ( list[i].fd < 0 ){ pos = i; break; } } if ( pos < 0 ){ for ( i = 0 ; i < glbMaxOpenConn ; i ++ ){ if ( list[i].inUse == 1 ){ continue; } if ( oldestTime < 0 ){ oldestTime = list[i].lastUsed; pos=i; }else{ if ( oldestTime > list[i].lastUsed ){ oldestTime = list[i].lastUsed; pos = i; } } } } if ( pos >= 0 ){ if ( list[pos].fd >= 0 ){ _close_socket(list[pos].fd); } strncpy(list[pos].hostName, con->hostName,255); list[pos].port = con->port; list[pos].fd = con->fd; list[pos].lastUsed=time(0); list[pos].inUse = 1; list[pos].secure = con->secure; list[pos].seqIn = con->seqIn; 37 10.2. KRYPTOGRAFICKÉ MECHANISMY list[pos].seqOut = con->seqOut; list[pos].ch = con->ch; } #ifdef HAVE_PTHREAD_H pthread_mutex_unlock(glbConnListLock); #endif #endif con1 = list+pos; return con1; } 10.2 Kryptografické mechanismy V zabezpečeném IBP protokolu jsou užity dva druhy šifrovacı́ch metod a to šifrovanı́ asymetrické a symetrické. Pro asymetrické šifrovánı́ jsme zvolili technologii PKI (veřejné a soukromé klı́če) s využitı́m algoritmu RSA. Pro šı́řenı́ veřejného klı́če jsme použili standardnı́ch X509 certifikátů. Konkrétně verzi X509v3, která je rozšı́řena o atributy, které je možné přenášet jako součást certifikátu. Tuto technologii jsme vybrali ze dvou důvodů. V prvnı́ řadě je důležité, že v rámci virtuálnı́ch organizacı́ je technologie PKI hojně využı́vána a klı́če jsou šı́řeny právě v podobě X509 certifikátů, tedy bude snadné IBP server a celou logistickou sı́t’začlenit do bezpečnostnı́ch mechanismů virtuálnı́ organizace. Důležitý je také fakt, že vzhledem k velké oblı́benosti PKI a X509 je k dispozici mnoho kvalitnı́ch programátorských nástrojů pro práci s nimi. My jsme zvolili knihovny gnutls9 a gcrypt10 . Knihovna gnutls potřebuje gcrypt ke své činnosti a kromě toho některé funkce knihovny gcrypt využı́váme v našem programu přı́mo. Pro symetrické šifrovánı́ byl zvolen algoritmus AES s mohutnostı́ šifrovacı́ho klı́če 128 bitů. Algoritmus AES nabı́zı́ tři velikosti klı́če: 128, 192 a 256. S velikostı́ šifrovacı́ho klı́če vzrůstá bezpečnost, ale také vzrůstá doba potřebná k šifrovanı́ dat. Tedy snižuje se datová propustnost spojenı́. AES 128 zvládne za stejný čas zašifrovat cca o 20% vı́ce dat než AES 256. Funkce pro šifrovánı́ pomocı́ symetrické šifry AES poskytuje knihovna gcrypt. Knihovny gnutls i gcrypt jsou bezpečné i v prostředı́ vláken tvořených pomocı́ knihovny pthread. Knihovna gcrypt se pro použitı́ vláken musı́ vhodně inicializovat, což musı́ být provedeno jako zcela prvnı́ věc před všemi ostatnı́mi volánı́mi funkcı́ z této knihovny. Za tı́mto účelem vznikla v klientském IBP API funkce ibp init, která v společně s volánı́m makra GCRY THREAD OPTION PTHREAD IMPL inicializaci provede. Funkce ibp init inicializuje i knihovnu gnutls: void ibp_init() { #ifdef HAVE_PTHREAD_H gcry_control (GCRYCTL_SET_THREAD_CBS, &gcry_threads_pthread); #endif 9. http://www.gnu.org/software/gnutls/ 10. http://directory.fsf.org/security/libgcrypt.html 38 10.3. POPIS PROVEDENÍ ZABEZPEČENÍ gnutls_global_init(); } 10.3 Popis provedenı́ zabezpečenı́ Pro ustanovenı́ bezpečného komunikačnı́ho kanálu mezi klientem a IBP serverem je použit postup obdobný napřı́klad s vytvořenı́m SSL/TLS sezenı́. Klient vlastnı́ X509 certifikát, ten odešle serveru. Server vygeneruje 128 bitový šifrovacı́ klı́č pro AES šifrovánı́. Klı́č zašifruje veřejným klı́čem z certifikátu od klienta a odešle jej klientovi. Klient provede dešifrovánı́ svým soukromým klı́čem a zı́ská tak šifrovacı́ klı́č pro AES šifrovánı́. Klient i server tedy disponujı́ stejným klı́čem pro symetrickou šifru a dalšı́ posı́laná data už tı́mto klı́čem šifrujı́. 10.3.1 Navazovánı́ spojenı́ – klientská část Navázánı́ spojenı́ zahajuje klient. Prvnı́ musı́ připravit svůj certifikát do potřebného formátu pro přenos na server. Předpokládá se, že vstupnı́ formát certifikátu je PEM, což je běžná forma, kdy certifikát je zakódován BASE64 kódovánı́m a uložen mezi řetězce „----BEGIN CERTIFICATE----“ a „----END CERTIFICATE----“. PEM formát je konvertován do DER formátu, který je kapacitně menšı́ a je vhodně vytvořený tak, aby byl digitálně podepsán. buf.data = pubkey; buf.size = strlen(pubkey); gnutls_x509_crt_init (&cert); gnutls_x509_crt_import(cert, &buf, GNUTLS_X509_FMT_PEM); rlen = 4000; gnutls_x509_crt_export(cert, GNUTLS_X509_FMT_DER, tmp, &rlen); gnutls_x509_crt_deinit(cert); Certifikát v DER formátu je následně uložen do struktury IBP authhandle. Následně proběhne vytvořenı́ s–expression, což je datová struktura knihovny gcrypt, která nese potřebné informace pro asymetrickou kryptografii. Ze soukromého klı́če klienta jsou zı́skány koeficienty, specifikujı́cı́ tento klı́č a ty jsou použity při vytvořenı́ s–expression. Knihovny gcrypt a gnutls dávajı́ různý význam koeficientům p a q. Knihovna gcrypt počı́tá koeficient u jako u=p-1 mod q, zatı́m co gnutls jako u=q-1 mod p. Navı́c se tento nesoulad lišı́ podle použité verze knihoven. Problém byl vyřešen jednoduchým přepočı́tánı́m koeficientu p a q. At’už majı́ p a q stejný význam v obou knihovnách, či nikoliv, po přepočı́tánı́ se význam vždy sjednotı́. Záměna významu koeficientu p a q však nenı́ jedinou nesrovnalostı́. Knihovna gnutls bohužel od blı́že nezjištěné verze změnila názvy některých typů. V našem přı́padě šlo jak v serverové tak v klientské části tři typy, které jsou uvedeny v tabulce 10.1. Problém jsem vyřešil pomocı́ utility autoconf a přidánı́m vhodných maker do zdrojových souborů. Úpravou skriptu configure.in jsem zajistil detekci typu gnutls x509 crt t během prováděnı́ automatické konfigurace před kompilacı́. Pokud tento typ existuje, pak automatická konfigurace nadefinuje makro HAVE GNUTLS X509 CRT T. Pokud toto makro během vlastnı́ kompilace existuje, pak jsou nadefinována makra z tabulky 10.1 na hodnoty nové verze, jinak jsou nadefinována na hodnoty staré verze. Vytvořenı́ s–expression: 39 10.3. POPIS PROVEDENÍ ZABEZPEČENÍ Tabulka 10.1 Datové typy knihovny gcrypt Stará verze gnutls x509 crt gnutls datum gnutls x509 privke Nová verze gnutls x509 crt t gnutls datum t gnutls x509 privke t Makro GNUTLS X509 CRT T GNUTLS DATUM T GNUTLS X509 PRIVKEY T // create sexpression from private key buf.size = strlen(privkey); buf.data = privkey; gnutls_x509_privkey_init(&pkey); if(gnutls_x509_privkey_import(pkey, &buf, GNUTLS_X509_FMT_PEM) != 0) { IBP_errno = IBP_E_INVALID_PRIVATE_KEY_FILE; return -1; } gnutls_x509_privkey_export_rsa_raw(pkey, &m, &e, &d, &p, &q, &u); gcry_mpi_scan(&m_m, GCRYMPI_FMT_USG, m.data, m.size, &ret); gcry_mpi_scan(&m_e, GCRYMPI_FMT_USG, e.data, e.size, &ret); gcry_mpi_scan(&m_d, GCRYMPI_FMT_USG, d.data, d.size, &ret); /* Recompute coefficient as gnutls and libgcrypt uses p,q in the * reverse order*/ gcry_mpi_scan(&m_q, GCRYMPI_FMT_USG, p.data, p.size, &ret); gcry_mpi_scan(&m_p, GCRYMPI_FMT_USG, q.data, q.size, &ret); m_u = gcry_mpi_new(gcry_mpi_get_nbits(m_m)); gcry_mpi_invm(m_u, m_p, m_q); gnutls_free(m.data); gnutls_free(e.data); gnutls_free(d.data); gnutls_free(p.data); gnutls_free(q.data); gnutls_free(u.data); gnutls_x509_privkey_deinit(pkey); gcry_sexp_build(&s_pkey, NULL, ”(private-key(rsa((n%m)(e%m)(d%m)(p%m)(q%m)(u%m))))”, m_m, m_e, m_d, m_p, m_q, m_u); // private key s˜expression to handler hd->s_pkey = s_pkey; gcry_mpi_release(m_m); 40 10.3. POPIS PROVEDENÍ ZABEZPEČENÍ gcry_mpi_release(m_e); gcry_mpi_release(m_d); gcry_mpi_release(m_p); gcry_mpi_release(m_q); gcry_mpi_release(m_u); Vzniklá s–expression je také uložena do struktury IBP authhandle spolu s podpisem odkazu na IBP server, který klient zı́skal od L–Bone serveru. Tı́m je struktura IBP authhandle naplněna a může být použita v dalšı́ch funkcı́ch z IBP klient API. Definice IBP authhandle: typedef struct ibp_authhandle { char cert[4000]; /* server certificate in DER format */ size_t cert_len; /* certificate size */ gcry_sexp_t s_pkey; /* client private key s-expression */ unsigned char signature[256]; /* signature of IBP server */ int siglen; /* signature size */ } *IBP_authhandle; Struktura IBP authhandle tedy nese upravené informace nutné při navazovánı́ bezpečného spojenı́, což jednak vede k urychlenı́ navazovánı́ spojenı́, protože nenı́ nutné znovu provádět konverze certifikátu a vytvářenı́ s–expression, a navı́c to ulehčı́ práci při programovánı́. Ostatnı́ funkce IBP klient API tak vyžadujı́ mı́sto 3 parametrů (certifikát, soukromý klı́č, podpis odkazu na IBP server) jen jeden parametr a tı́m je struktura IBP authhandle. Pokud je zavolána některá z funkcı́ IBP klient API, která vyžaduje komunikaci se serverem a v přı́padě, že pro komunikaci nenı́ nalezeno žádné vhodné existujı́cı́ spojenı́, pak je spojenı́ vytvořeno a je automaticky zavolána funkce IBP auth. Funkce IBP auth dostane jako jeden z parametrů strukturu IBP authhandle. Nejprve je na server odeslán certifikát klienta a podpis odkazu na IBP server. Oba údaje jsou převzaty z IBP authhandle. Také je serveru předán výchozı́ stav čı́tačů přı́chozı́ch a odchozı́ch zpráv. Od serveru pak klient přijı́má svým veřejným klı́čem zašifrovaný 128 bitový AES klı́č. Před vlastnı́ data klı́če je ještě před šifrovánı́m na serveru doplněn kontrolnı́ řetězec AESKEY. Jak server, tak klient zná tento kontrolnı́ řetězec, a proto může sloužit k ověřenı́, zda šifrovánı́, přenos a dešifrovánı́ AES klı́če proběhlo správně. Předejdeme tak neočekávaným událostem při dalšı́ komunikaci, které mohou být způsobeny vinou vadného AES klı́če. Po té, co je šifrovaný AES klı́č dešifrován za pomoci s–expression, která byla uložena ve struktuře IBP authhandle, je ověřeno, zda prvnı́ch 6 znaků tvořı́ kontrolnı́ řetězec AESKEY. Pokud ano, pak je zbytek dat, která tvořı́ vlastnı́ 128 bitový šifrovacı́ klı́č pro AES šifru, uložen k dalšı́m parametrům vytvořeného spojenı́. Touto operacı́ obě strany zı́skaly shodný šifrovacı́ klı́č pro AES šifrovánı́, a veškerá dalšı́ komunikace tedy může probı́hat zabezpečeně. Pomocı́ AES šifrovacı́ho klı́če je vytvořen šifrovacı́ kontext, který je uložen k informacı́m o vzniklém spojenı́. Většina zpráv odesı́laných klientem je označena pořadovým čı́slem obdobně jako většina zpráv odesı́laných serverem. Klient při přijetı́ zprávy ověřı́, zda očekávané pořadové čı́slo v rámci spojenı́ souhlası́ se skutečným pořadovým čı́slem zprávy. Pokud čı́sla nesouhlası́, je indikována chyba. 41 10.3. POPIS PROVEDENÍ ZABEZPEČENÍ Očı́slovánı́ zprávy odesı́lané klientem na server: // zasifrovani poradoveho cisla odesilane zpravy sprintf(seq, ”%16d”, lp_iurl->con->seqOut); gcry_cipher_encrypt(lp_iurl->con->ch, seq, 16, NULL, 0); bin2hex(seq, 16, seqhex); // format odesilane zpravy sprintf(lc_line_buf,”%d %d %s %s %lu %d %d\n”, IBPv031, IBP_STORE, seqhex, tmp, pl_size, ps_timeout->ServerSync, encrypt); 42 10.3. POPIS PROVEDENÍ ZABEZPEČENÍ Ověřenı́ správného čı́sla zprávy přijaté klientem od serveru: // ziskani dat z prijate zpravy if (sscanf(lp_comm_unit->data_buf,”%d %s %lu”, &li_return, &seqhex, &ll_truesize) != 3) { IBP_errno = IBP_E_BAD_FORMAT; free_IURL(lp_iurl); return(0); } // odsifrovani poradoveho cisla hex2bin(seqhex); gcry_cipher_decrypt(lp_iurl->con->ch, seqhex, 16, NULL, 0); seqIn = atoi(seqhex); // kontrola poradoveho cisla if (seqIn != lp_iurl->con->seqIn) { IBP_errno = IBP_E_BAD_FORMAT; free_IURL(lp_iurl); return(0); } 10.3.2 Navazovánı́ spojenı́ – server Server přijme od klienta zprávu s přı́kazem provézt IBP auth. Zpráva obsahuje klientův certifikát v DER formátu, podpis odkazu na IBP server od L–Bone serveru a výchozı́ hodnoty pro čı́tače přı́chozı́ch a odchozı́ch zpráv v rámci spojenı́. Hodnoty čı́tačů jsou vloženy do struktury cl info, která nese veškeré potřebné informace o spojenı́. Na základě veřejného klı́če z přijatého certifikátu se vytvořı́ s–expression. Pak následuje vygenerovánı́ 128 bitového klı́če pro symetrickou šifrovacı́ metodu AES. do { gcry_randomize (cl->aes_key, 16, GCRY_STRONG_RANDOM); } while(cl->aes_key[0] == 0) Ke generovánı́ klı́če je použita funkce pro náhodná čı́sla z knihovny gcrypt. Tato funkce zaručuje vyššı́ nepravděpodobnost uhodnutı́ náhodného čı́sla, a je tedy vhodnějšı́ pro vyššı́ bezpečnost. Šifrovacı́ klı́č je generován tak, aby jeho počátečnı́ byte neměl hodnotu 0. Tento byte se užı́vá ke zjištěnı́, zda je klı́č přı́tomen (byte je nenulový), nebo nenı́ přı́tomen (byte je nulový). Dále je ověřeno podle podepsaného odkazu na IBP server, jestli souhlası́ jméno a port serveru se jménem a portem serveru v podepsaném odkazu a také, zda nenı́ podepsaný odkaz staršı́ než zvolená časová konstanta. Pokud je vše v pořádku, pak přijde na řadu opatřenı́ AES šifrovacı́ho klı́če kontrolnı́m řetězcem AESKEY a následně je celý řetězec zašifrován pomocı́ dřı́ve vytvořené s–expression. AES klı́č je také hned užit k vytvořenı́ šifrovacı́ho kontextu a vzniklý kontext je, stejně jako v přı́padě klienta, uložen k informacı́m o spojenı́, tedy do struktury cl info. 43 10.3. POPIS PROVEDENÍ ZABEZPEČENÍ struct cl_info { struct Stream *fd; /* komnunikacni stream */ pthread_t tid; /* id vlakna, pod kterym spojeni bezi */ gcry_sexp_t s_pubkey; /* s-expression z verejneho klice klienta */ int key_size; /* velikost AES klice v bitech */ unsigned char aes_key[16]; /* AES klic */ int group_id; int seqIn; /* citac prichozich zprav */ int seqOut; /* citac odchozich zprav */ gcry_cipher_hd_t c_hd; /* AES sifrovaci kontext spojeni */ } cl_info; 44 Kapitola 11 Testovánı́ Navržené a zpracované řešenı́ jsme podrobili sérii testů, a to jak za účelem zjištěnı́ stability, tak změřenı́ výkonnosti. Testuje se klientské IBP API proti IBP serveru a celá série testů se skládala z několika testovacı́ch cyklů. Posloupnost operacı́ provedených během jedné iterace cyklu je ve všech cyklech stejná. Cykly se lišı́ velikostı́ přenášených dat, zdrojem přenášených dat a úrovnı́ šifrovanı́ komunikace. Každý testovacı́ cyklus má 500 iteracı́ a výsledek každé iterace je zaznamenán. Měřenou hodnotou je čas, za který se provedou jednotlivé operace během jedné iterace cyklu. Jedna iterace obsahuje tuto posloupnost operacı́: 1. Allocate 2. Store 3. Load 4. Allocate 5. Copy Vyjádřeno slovy: klient alokuje mı́sto na serveru, následně uložı́ data, která zpět přečte, pak alokuje dalšı́ mı́sto na stejném serveru a provede vzdálené kopı́rovánı́ dat v rámci jednoho serveru. Z naměřených hodnot je odstraněno 1% nejhoršı́ch a 1% nejlepšı́ch výsledků za účelem odstranit chyby měřenı́, následně je zjištěna maximálnı́ a minimálnı́ hodnota a spočı́tán aritmetický průměr se směrodatnou odchylkou. Všechny hodnoty jsou vyneseny do grafů, vypočı́tané hodnoty pak do tabulek. 11.1 Hlavnı́ testovánı́ V rámci hlavnı́ho testovánı́ proběhla celá série testů dvakrát. Prvnı́ série byla provedena v rámci počı́tačové sı́tě v superpočı́tačovém centru Masarykovy univerzity, druhá série pak mezi Západočeskou univerzitou v Plzni a Masarykovou univerzitou v Brně. V prvnı́m přı́padě byl klient i server v jedné mı́stnı́ sı́ti, ve druhém přı́padě byl server s klientem propojen sı́tı́ internet. Testovacı́ série se skládá z následujı́cı́ch testovacı́ch cyklů: • 100MB dat čtených z paměti, plné šifrovánı́, 500 iteracı́ 100MB dat čtených z paměti, částečné šifrovánı́, 500 iteracı́ 100MB dat čtených z paměti, žádné šifrovánı́, 500 iteracı́ 45 11.1. HLAVNÍ TESTOVÁNÍ • 50MB dat čtených z paměti, plné šifrovánı́, 500 iteracı́ 50MB dat čtených z paměti, částečné šifrovánı́, 500 iteracı́ 50MB dat čtených z paměti, žádné šifrovánı́, 500 iteracı́ • 100MB dat čtených z různých souborů z disku, plné šifrovánı́, 500 iteracı́ 100MB dat čtených z jednoho souboru z disku, plné šifrovánı́, 500 iteracı́ • 50MB dat čtených z různých souborů z disku, plné šifrovánı́, 500 iteracı́ 50MB dat čtených z jednoho souboru z disku, plné šifrovánı́, 500 iteracı́ Cı́lem je porovnat kolik času navı́c v jednotlivých IBP operacı́ch zabere částečné šifrovánı́ oproti žádnému a plné šifrovánı́ oproti částečnému. Dále pak vliv vyrovnávacı́ch pamětı́ klienta na celkovou dobu přenosu. Před testovacı́m cyklem, který má za cı́l vyrovnávacı́ paměti zaplnit, jsou vygenerovány soubory o patřičné velikosti s rozdı́lnými jmény. Před každým provedenı́m přı́kazu Store je jeden soubor načten do paměti a po provedenı́ Load jsou načtená data z paměti uložena na disk. Souborů je celkem 40 a během testovánı́ se načı́tajı́ a ukládajı́ cyklicky. Druhý testovacı́ cyklus užı́vá jen jeden soubor, který by naopak měl operačnı́ systém držet ve vyrovnávacı́ paměti. Prováděnı́ dvou sériı́ testů sloužı́ k zjištěnı́, jaký vliv na rychlost přenosu má delšı́ odezva na sı́ti. Při prvnı́ sérii je totiž klient a server umı́stěn v jedné sı́ti a dokonce v jedné mı́stnosti. Ve druhé sérii jsou klient a server fyzicky vzdáleni několik stovek kilometrů a každý se nacházı́ v jiné univerzitnı́ sı́ti, které jsou vzájemně propojeny v rámci internetu. 46 11.2. PRVNÍ SÉRIE 11.2 Prvnı́ série 11.2.1 Hardware V prvnı́ sérii testů byl za server zvolen počı́tač vybavený procesorem Intel Pentium 4 3.0 GHz, 3 GB RAM, 1 Gbps NIC a hardwarovým diskovým polem RAID 0 složeném ze dvou disků na řadiči SATA. Klient byl osazen dvěma procesory Intel Pentium Xeon 3.0 GHz, 4 GB RAM, 1 Gbps NIC a hardwarovým diskovým polem RAID 5 o velikosti 7 TB na řadiči SATA. 11.2.2 Výsledky Obrázek 11.1: Průběh funkcı́ Allocate, Store, Load a Copy pro 100 MB Tabulka 11.1 Časy funkcı́ Allocate, Store, Load a Copy pro 100 MB dat (ms) 100MB Plné šifrovánı́ Částečné šifrovánı́ Bez šifrovánı́ Allocate 1, 51 ± 0, 06 1, 65 ± 0, 1 1, 05 ± 0, 09 Store 6800, 41 ± 339, 2 1212, 72 ± 238, 98 1460, 05 ± 350, 98 Load 6334, 15 ± 151, 01 1004, 15 ± 8, 85 1001, 35 ± 4, 78 Copy 1, 62 ± 0, 05 1, 59 ± 0, 08 0, 98 ± 0, 06 Během prováděnı́ přı́kazu Allocate se šifrujı́ pouze přenášené capability a žádná data, proto je rozdı́l mezi plně šifrovanou a šifrovanou verzı́ přı́kazu zanedbatelný. Rychlostně se výrazněji lišı́ až nešifrovaná verze přı́kazu, kdy neprobı́há vůbec žádné šifrovánı́, a proto si polepšila o cca 0,5 ms. U přı́kazu Store se výrazně projevuje rozdı́l mezi plně šifrovanou verzı́ a verzı́ částečně šifrovanou a nešifrovanou. Šifrovánı́ dat prodloužı́ jejich přenos vı́ce jak pětinásobně, zatı́mco šifrovánı́ 47 11.2. PRVNÍ SÉRIE přı́kazů je při přenosu dat o této velikosti časově zanedbatelné. Podobně si vede i přı́kaz Load, u kterého je plně šifrovaná varianta vı́ce jak šestkrát pomalejšı́ než varianta šifrovaná částečně nebo vůbec. Přı́kaz Copy se chová stejně jako přı́kaz Allocate, protože vlastnı́ přenos dat probı́há v rámci samotného serveru. Tedy rozdı́l mezi šifrovanou a plně šifrovanou verzı́ je z důvodu absence přenosu dat zanedbatelný a výrazněji se lišı́ až nešifrovaná verze, která je cca o 0,6 ms rychlejšı́. Obrázek 11.2: Průběh funkce Store pro 50 MB a 100 MB dat Tabulka 11.2 Časy funkce Store pro 50 MB a 100 MB dat (ms) Store Plné šifrovánı́ Částečné šifrovánı́ Bez šifrovánı́ 100 MB 6800, 41 ± 339, 2 1212, 72 ± 238, 98 1460, 05 ± 350, 98 50 MB 3389, 35 ± 101, 79 606, 03 ± 179, 5 532, 76 ± 89, 1 Z výše uvedených grafů a tabulky vyplývá, že čas strávený přenosem dat na server je při všech variantách přı́kazu Store lineárně závislý na velikosti dat. 48 11.2. PRVNÍ SÉRIE Obrázek 11.3: Průběh funkcı́ Store a Load pro 50 MB a 100 MB dat čtených z a psaných do jednoho nebo vı́ce souborů Tabulka 11.3 Časy funkce Store a Load pro 50 MB a 100 MB dat čtených z a ukládaných do jednoho nebo vı́ce souborů (ms) Store Vı́ce souborů Jeden soubor 50 MB 4558, 94 ± 584, 18 3461, 71 ± 117, 28 100 MB 10081, 73 ± 844, 44 7924, 07 ± 797, 69 Load Vı́ce souborů Jeden soubor 50 MB 3277, 08 ± 101, 35 3232, 68 ± 87, 42 100 MB 7983, 84 ± 830, 86 7541, 75 ± 842, 23 Při přı́kazu Store se projevı́ vlastnosti vyrovnávacı́ paměti klientského počı́tače. Pokud je každý balı́k dat načten z jiného souboru, pak se vyrovnávacı́ pamět’nevyužije v takové mı́ře, jako v přı́padě, kdy se načı́tá stále stejný soubor. Přenos dat načı́taných z různých souborů je cca o 1/3 pomalejšı́ než přenos dat ze stále stejného souboru. V přı́padě přı́kazu Load jsou data stažená z IBP serveru ukládána bud’ do různých nebo stále do stejného souboru. Tyto varianty se od sebe rychlostně nelišı́. 49 11.3. DRUHÁ SÉRIE 11.3 Druhá série 11.3.1 Hardware Za server byl zvolen počı́tač vybavený procesorem Intel Pentium 4 3.0 GHz, 3 GB RAM, 1 Gbps NIC a hardwarovým diskovým polem RAID 0 složeném ze dvou disků na řadiči SATA umı́stěný na Masarykově univerzitě (MU). Klientem byl počı́tač osazený dvěma procesory Intel Pentium Xeon 2.4 GHz, 1 GB RAM, 1 Gbps NIC a diskem na řadiči PATA o velikosti 40 GB. Domovskou institucı́ klienta je Západočeská univerzita v Plzni (ZČU). Server s klientem byl propojen v rámci internetu linkou o rychlosti 1 Gbps. 11.3.2 Výsledky Obrázek 11.4: Průběh funkcı́ Allocate, Store, Load a Copy pro 100 MB mezi MU a ZČU Rychlost sı́tě mezi servery má jasný vliv na rychlost přenosu dat. To je vidět na hodnotách přı́kazů Load a Store, které v přı́padě přenosu dat mezi ZČU a MU vykazujı́ přibližně dvojnásobné hodnoty oproti přenosu v rámci MU. Na průběhu přı́kazů Allocate a Copy se zřetelně projevilo zpožděnı́ sı́tě mezi MU a ZČU, které způsobilo přibližně čtyřnásobné prodlouženı́ času. Tabulka 11.4 Časy funkcı́ Allocate, Store, Load a Copy pro 100 MB dat mezi MU a ZČU (ms) 100MB Plné šifrovánı́ MU FI ZČU Allocate 1, 51 ± 0, 06 6, 77 ± 0, 07 Store 6800, 41 ± 339, 2 15320, 83 ± 137, 64 Load 6334, 15 ± 151, 01 12610, 77 ± 97, 02 Copy 1, 62 ± 0, 05 6, 93 ± 0, 08 50 11.4. DOPLŇKOVÉ TESTY Obrázek 11.5: Průběh funkcı́ Allocate, Store, Load a Copy pro 100 MB na ZČU Tabulka 11.5 Časy funkcı́ Allocate, Store, Load a Copy pro 100 MB dat na ZČU (ms) 100MB Plné šifrovánı́ Částečné šifrovánı́ Bez šifrovánı́ Allocate 6, 77 ± 0, 07 6, 84 ± 0, 2 6, 12 ± 0, 16 Store 15320, 11 ± 137, 64 8507, 11 ± 287, 81 9137, 12 ± 1219, 32 Load 12610, 77 ± 97, 02 8888, 78 ± 812, 92 9055, 99 ± 563, 92 Copy 6, 93 ± 0, 09 6, 86 ± 0, 24 6, 11 ± 0, 16 11.4 Doplňkové testy Za účelem zjistit chovánı́ IBP protokolu na dnes běžných linkách dostupných firmám a domácnostem jsme provedli upravenou sérii testů. Posloupnost operacı́ v rámci cyklu zůstala stejná, počet iteracı́ byl ale snı́žen podle potřeby na 50 až 20. Metodika zpracovánı́ výsledku zůstala stejná jako u hlavnı́ch testů. Klient i server byli umı́stěni u různých poskytovatelů internetu. Klient běžel na počı́tači s poněkud staršı́ konfiguracı́ Intel Celeron 433 MHz, 224 MB RAM, 100 Mbps NIC, softwarové diskové pole RAID 1 o kapacitě 80 GB na řadiči PATA. K internetu byl klient připojen v České republice populárnı́m bezdrátovým připojenı́m bez agregace s rychlostı́ 512 kbps upload a 512 kbps download. Předpokládáme, že i přes nı́zký výkon klientského počı́tače bude úzkým hrdlem přenosu dat připojenı́ klienta k internetu. Podobně je tomu i na straně serveru, který byl osazen procesorem Intel Pentium II 400 MHz, 256 MB RAM, 100 Mbps NIC a softwarovým diskovým polem RAID 1 o kapacitě 80 GB na řadiči PATA. Do internetu byl připojen také bezdrátovou linkou s agregacı́ 1:12 a rychlostmi 1 Mbps upload a 512 kbps download. 51 11.4. DOPLŇKOVÉ TESTY Testovány byly tyto varianty přenosu dat: • 25MB dat čtených z paměti, plné šifrovánı́, 20 iteracı́ 25MB dat čtených z paměti, částečné šifrovánı́, 20 iteracı́ • 10MB dat čtených z paměti, plné šifrovánı́, 50 iteracı́ 10MB dat čtených z paměti, částečné šifrovánı́, 50 iteracı́ 11.4.1 Výsledky Obrázek 11.6: Průběh funkcı́ Allocate, Store, Load a Copy pro 10 MB Tabulka 11.6 Časy funkcı́ Allocate, Store, Load a Copy pro 10 MB dat (ms) 10MB Plné šifrovánı́ Částečné šifrovánı́ Allocate 98, 01 ± 49, 01 84, 82 ± 47, 01 Store 105705, 09 ± 14370, 6 90208, 51 ± 3803, 85 Load 174641, 6 ± 2154, 95 171839, 33 ± 929, 41 Copy 98, 18 ± 27, 74 87, 63 ± 43, 11 Z grafu je jasně vidět, že na pomalých linkách se ztrácı́ rozdı́l mezi plným šifrovánı́m a částečným šifrovánı́m. Počı́tače, byt’ zastaralé, stı́hajı́ pro nı́zké přenosové rychlosti šifrovat data dostatečně rychle. Jak jsme předpokládali, rychlost přenosu je tedy brzděna samotnou linkou. Je zajı́mavé, že ukládánı́ dat na server je rychlejšı́, jak čtenı́ dat ze serveru. Tato nesrovnalost bude způsobena tı́m, že linka u klienta bude mı́t pro upload lepšı́ parametry, než udává poskytovatel. Při zvětšenı́ velikosti přenášených dat se potvrdil závěr předchozı́ch měřenı́. Na linkách, které má dnes široká veřejnost k dispozici a s výpočetnı́m výkonem, který je dnes běžný, se rozdı́ly mezi plným a částečným šifrovánı́m ztrácejı́. Předpokládáme, že běžně jsou k dispozici dvakrát až 52 11.4. DOPLŇKOVÉ TESTY Obrázek 11.7: Průběh funkcı́ Store a Load pro 25 MB Tabulka 11.7 Časy funkcı́ Store a Load pro 25 MB dat (ms) 25MB Plné šifrovánı́ Částečné šifrovánı́ Store 248292, 99 ± 22323, 46 245130, 29 ± 16043, 6 Load 434119, 44 ± 14370, 6 434945, 51 ± 8788, 58 čtyřikrát rychlejšı́ linky, ale současně výkony dnešnı́ch počı́tačů jsou několikanásobně vyššı́ než výkon testovacı́ho klienta a serveru. Pokud by logistické sı́tě byly veřejnosti dostupné již dnes, uživatelé by si mohli dovolit komfort plného zabezpečenı́. 53 Kapitola 12 Závěr Podařilo se nám navrhnout a implementovat důležitá rozšı́řenı́ logistických sı́tı́ o prvky nutné pro snadné začleněnı́ do architektury virtuálnı́ch organizacı́. Navržené změny se ukázaly jako vhodné řešenı́ zadaného úkolu, což podporuje kromě jiného i fakt, že během vlastnı́ implementace se na návrhu nenašly žádné vady vyžadujı́cı́ změnu. Začleněnı́ logistických sı́tı́ do prostředı́ virtuálnı́ch organizacı́ vyžaduje změny na vı́ce vrstvách architektury logistických sı́tı́. My jsme provedli úpravu nejnižšı́ vrstvy, tedy IBP protokolu, který sloužı́ pro přı́mou komunikaci s datovými sklady. V rámci virtuálnı́ organizace je požadováno, aby se uživatel při přı́stupu k IBP serveru autentizoval a autorizoval a aby komunikace pomocı́ IBP protokolu byla bezpečná. K tomuto účelu jsme užili ve virtuálnı́ch organizacı́ch hojně užı́vanou technologii veřejných a soukromých klı́čů spolu se symetrickou kryptografiı́. Datový sklad je tedy chráněn proti zneužitı́ a komunikace je chráněna proti odposlechnutı́, změně dat, útoku opakovánı́m odposlechnuté sekvence atd. Úroveň zabezpečenı́ je volitelná, což umožňuje přı́pad od přı́padu volit mezi rychlostı́ a bezpečnostı́ IBP protokolu. Za prostředky, kterými jsme dosáhli potřebných úprav, jsme zvolili běžně dostupné volně šiřitelné knihovny pro práci s PKI technologiı́ a se symetrickou a asymetrickou kryptografiı́. Důležitou vlastnostı́ vybraných knihoven je volná dostupnost zdrojových kódů, což umožňuje provést jejich bezpečnostnı́ audit a zvýšit tak bezpečnost a důvěryhodnost celého řešenı́. Nová rozšı́řenı́ byla navrhována a implementována s důrazem na zachovánı́ všech původnı́ch vlastnostı́ protokolu za účelem zpětné kompatibility. Tedy do stávajı́cı́ho IBP API byla přidána sada funkcı́ zpřı́stupňujı́cı́ch bezpečnostnı́ rozšı́řenı́ protokolu. Jak IBP server, tak IBP klient umı́ současně užı́t původnı́ nezabezpečenou i novou zabezpečenou verzi protokolu. Během závěrečných testů, které byly v celé své šı́ři provedeny několikrát, nevykazoval ani server ani klient žádné nežádoucı́ chovánı́. Samotné výsledky testů pak ukazujı́, že možnost volby úrovně zabezpečenı́ byla správná. Varianta částečného zabezpečenı́, tedy zabezpečenı́ řı́dı́cı́ch zpráv protokolu, nevykazuje téměř žádné zhoršenı́ rychlosti přenosu dat proti původnı́ zcela nezabezpečené verzi. Naopak, verze s plným zabezpečenı́m je výrazně pomalejšı́ než obě zbývajı́cı́ varianty. Rychlost při plném zabezpečenı́ se ztrácı́ během šifrovanı́ dat, byt’symetrickou metodou AES a na poměrně výkonných počı́tačı́ch. Doba přenosu narůstá až na šestinásobek doby přenosu bez šifrovánı́ dat. Zde v budoucnu pomůže jen výkonnějšı́ hardware nebo rychlejšı́ šifrovacı́ algoritmus. 54 Kapitola 13 Popis API Tato část obsahuje popis klientského IBP API. Popis zahrnuje nové funkce a nové datové struktury, které byly vytvořeny v souvislosti s touto pracı́. Datové typy a struktury, které budou v popisu použity a nebudou vysvětleny, jsou součástı́ původnı́ho API, jehož popis naleznete na webových stránkách LoCI11 . 13.1 Struktury a datové typy 13.1.1 IBP authhandle Datová struktura, která nesouce informace důležité pro navázánı́ bezpečného spojenı́. Většina funkcı́ v novém IBP API vyžaduje tuto vyplněnou strukturu. Navazovánı́ spojenı́ se provádı́ automaticky podle situace, a proto musı́ mı́t většina funkcı́ k dispozici informace jak spojenı́ navázat. Struktura je definována takto: typedef struct ibp_authhandle { char cert[4000]; size_t cert_len; gcry_sexp_t s_pkey; unsigned char signature[256]; int siglen; } *IBP_authhandle; cert – klientův X509 certifikát v DER formátu cert len – délka certifikátu v bytech s pkey – ukazatel na strukturu s-expression z knihovny gcrypt vytvořenou s klientova soukromého klı́če signature – odkaz na IBP server podepsaný L–Bone serverem siglen – délka podpisu K naplněnı́ struktury patřičnými daty sloužı́ funkce IBP auth create. 11. http://loci.cs.utk.edu/ 55 13.2. FUNKCE API 13.2 Funkce API 13.2.1 ibp init void ibp_init(); Provede inicializace IBP knihovny. Zatı́m jde předevšı́m o inicializaci knihoven gnutls a gcrypt pro použitı́ vláken. Tato funkce musı́ být zavolána před použitı́m všech ostatnı́ch funkcı́ z IBP API. Vstup: žádný Výstup: žádný Komunikace: žádná 13.2.2 IBP auth create int IBP_auth_create (IBP_depot ps_depot, IBP_authhandle *hdl, char *pubkey, char *privkey, IBP_timer ps_timout); Naplnı́ strukturu IBP authhandle určenou parametrem hdl patřičnými údaji zı́skanými z parametrů ps depot, pubkey, privkey a ps timout. Vstup: IBP depot – informace o IBP serveru hdl – odkaz na IBP authhandle strukturu pubkey – klientský certifikát v PEM formátu privkey – klientský privátnı́ klı́č v PEM formátu ps timeout – časové limity pro komunikaci (nemá význam) Výstup: Při úspěchu vracı́ IBP OK při neúspěchu vracı́ IBP E GENERIC a nastavı́ IBP errno na jednu z těchto hodnot: IBP E INV PAR HOST: nebyl zadán název serveru IBP E INV PAR PORT: port je mimo povolený rozsah IBP E INVALID PRIVATE KEY FILE: nezdařilo se importovat klientský soukromý klı́č Komunikace: žádná 56 13.2. FUNKCE API 13.2.3 IBP auth int IBP_auth(char int int IBP_authhandle CONNECTION *host, port, timeout, hdl, *con) Vytvořı́ bezpečné spojenı́ mezi klientem a serverem. Tuto funkci programátor běžně samostatně nevolá. Spojenı́ je navazováno automaticky, jak to vyžaduje situace. Nové spojenı́ je uloženo do con. Vstup: host – název IBP serveru port – port IBP serveru timeout – časový limit komunikace hdl – odkaz na strukturu IBP authhandle con – odkaz na strukturu CONNECTION Výstup: Při úspěchu vracı́ IBP OK při neúspěchu vracı́ IBP E GENERIC a nastavı́ IBP errno na jednu z těchto hodnot: IBP IBP IBP IBP IBP IBP E E E E E E TOO MANY UNITS: nelze vytvořit dalšı́ komunikačnı́ jednotku UNKNOWN FUNCTION: volána neznámá funkce pro zpracovánı́ komunikace SOCK READ: chyba čtenı́ dat při komunikaci SOCK WRITE: chyba zápisu dat při komunikaci BAD FORMAT: chybný formát přijatých dat AESKEY TRANS FAILED: selhal přenos AES šifrovacı́ho klı́če, nerozpoznán kontrolnı́ řetězec AESKEY Komunikace: Odešle: IBPv040 IBP_AUTH seqIn seqOut cert signature seqIn – počátek čı́tače přı́chozı́ch zpráv, integer seqOut – počátek čı́tače odchozı́ch zpráv, integer cert – klientův certifikát, řetězec znaků hexadecimálnı́ soustavy signature – odkaz na IBP server podepsaný L–Bone serverem, řetězec znaků hexadecimálnı́ soustavy Přijme: IBP_OK msgNum aeskey msgNum – pořadové čı́slo zprávy, integer aeskey – AES šifrovacı́ klı́č zašifrovaný veřejným klı́čem klienta, řetězec znaků hexadecimálnı́ soustavy Alternativně přijme: IBP_errno IBP errno – čı́slo chyby, integer Počet výměn: 1 57 13.2. FUNKCE API 13.2.4 IBPs allocate IBP_set_of_caps IBPs_allocate (IBP_depot IBP_authhandle IBP_timer unsigned long int IBP_attributes ps_depot, hdl, ps_timeout, pi_size, ps_attr) Alokuje prostor na IBP serveru. Alokovaný prostor má maximálnı́ velikost pi size bytů a vlastnosti udané v ps attr. Vstup: ps depot – informace o IBP serveru hdl – odkaz na strukturu IBP authhandle ps timeout – časové limity pro komunikaci ps attr – vlastnosti alokovaného prostoru Výstup: Při úspěchu vracı́ množinu capabilit IBP set of caps, při neúspěchu vracı́ NULL a nastavı́ IBP errno na jednu z těchto hodnot: IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP E E E E E E E E E E E E E E TOO MANY UNITS: nelze vytvořit dalšı́ komunikačnı́ jednotku UNKNOWN FUNCTION: volána neznámá funkce pro zpracovánı́ komunikace SOCK READ: chyba čtenı́ dat při komunikaci SOCK WRITE: chyba zápisu dat při komunikaci BAD FORMAT: chybný formát přijatých dat, chybné čı́slo zprávy CONNECTION: chyba při navazovánı́ spojenı́ s IBP serverem INV PAR ATDR: chybné údaje ve vlastnostech ps attr INV PAR HOST: nebyl zadán název serveru INV PAR PORT: port je mimo povolený rozsah INVALID RID: neplatné id zdroje ALLOC FAILED: selhala alokace paměti INVALID PARAMETER: chybný parametr v IBP přı́kazu WOULD EXCEED LIMIT: překročenı́ maximálnı́ povolené velikosti dat na serveru GROUP: špatná skupina Komunikace: Odešle: IBPv040 IBP_ALLOCATE msgNum rid reliability type lifetime size timeout msgNum – šifrované pořadové čı́slo zprávy, řetězec znaků hexadecimálnı́ soustavy rid – identifikace zdroje, integer realiabilty – typ spolehlivosti alokovaného mı́sta, integer type – typ alokovaného mı́sta, integer lifetime – doba životnosti alokovaného mı́sta, integer size – velikost alokovaného mı́sta, integer timeout – časový limit pro zpracovánı́ přı́kazu serverem, integer 58 13.2. FUNKCE API Přijme: IBP_OK msgNum capabilities msgNum – šifrované pořadové čı́slo zprávy, řetězec znaků hexadecimálnı́ soustavy capabilities – šifrovaný seznam capabilit, řetězec znaků hexadecimálnı́ soustavy Alternativně přijme: IBP_errno IBP errno – čı́slo chyby, integer Počet výměn: 1 (+ 1 v přı́padě navazovánı́ nového spojenı́) 13.2.5 IBPs store unsigned long int IBPs_store(IBP_authhandle IBP_cap IBP_timer char * unsigned long int char int hdl, pc_cap, ps_timeout, pc_data, pl_size, mid[37], encrypt); Provede uloženı́ dat pc data velikosti pl size s identifikátorem mid od metadata manažeru na IBP server udaný pomocı́ capabilit pc cap. Vstup: hdl – odkaz na strukturu IBP authhandle pc cap – capability pro zápis na IBP server ps timeout – časové limity pro komunikaci pc data – data pro uloženı́ na IBP server pl size – délka dat ukládaných na server mid – identifikátor dat od metadata manažeru encrypt – úroveň šifrovanı́. 0 – šifrovánı́ přı́kazů, 1 – šifrovánı́ přı́kazů i dat Výstup: Při úspěchu vracı́ počet bytů uložených na server, při neúspěchu vracı́ 0 a nastavı́ IBP errno na jednu z těchto hodnot: IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP E E E E E E E E E E E TOO MANY UNITS: nelze vytvořit dalšı́ komunikačnı́ jednotku UNKNOWN FUNCTION: volána neznámá funkce pro zpracovánı́ komunikace SOCK READ: chyba čtenı́ dat při komunikaci SOCK WRITE: chyba zápisu dat při komunikaci BAD FORMAT: chybný formát přijatých dat, chybné čı́slo zprávy CONNECTION: chyba při navazovánı́ spojenı́ s IBP serverem INV PAR HOST: nebyl zadán název serveru INV PAR PORT: port je mimo povolený rozsah INV PAR PTR: chybný odkaz na data INV PAR SIZE: chybná velikost dat WRONG CAP FORMAT: špatný formát capabilit 59 13.2. FUNKCE API IBP IBP IBP IBP IBP IBP IBP IBP E E E E E E E E CAP NOT FOUND: capabilitám neodpovı́dá žádný prostor na serveru CAP NOT WRITE: capability nejsou určeny pro zápis INVALID PARAMETER: chybný parametr v IBP přı́kazu WOULD EXCEED LIMIT: překročenı́ maximálnı́ povolené velikosti dat na serveru FILE ACCESS: server nemá přı́stup k souboru s daty CLIENT TIMEOUT: časový limit pro komunikaci s klientem vypršel FILE WRITE: server nemá právo psát do souboru s daty GROUP: špatná skupina Komunikace: Odešle: IBPv031 IBP_STORE msgNum identify size timeout encrypt msgNum – šifrované pořadové čı́slo zprávy, řetězec znaků hexadecimálnı́ soustavy identify – šifrovaný řetězec capabilities:keytype:mid capabilities – capability pro zápis na server, řetězec keytype – typ capabilit, řetězec mid – identifikátor dat od metadata manažeru. řetězec size – velikost dat, integer timeout – časový limit pro zpracovánı́ přı́kazu serverem, integer encrypt – úroveň zabezpečenı́ dat, integer Přijme: IBP_OK Alternativně přijme: IBP_errno IBP errno – čı́slo chyby, integer Odešle: data data – v závislosti na úrovni šifrovánı́ šifrovaná nebo nešifrovaná binárnı́ data Přijme: IBP_errno msgNum size IBP errno – výsledek operace, IBP OK nebo jiná chybová hodnota, integer msgNum – šifrované pořadové čı́slo zprávy, řetězec znaků hexadecimálnı́ soustavy size – velikost dat přijatých serverem, integer Počet výměn: 2 (+ 1 v přı́padě navazovánı́ nového spojenı́) 13.2.6 IBPs load unsigned long int IBPs_load (IBP_authhandle IBP_cap IBP_timer char unsigned long int unsigned long int char int hdl, pc_source, ps_timeout, *pc_buf, pl_size, pl_offset, *mcaps, encrypt); 60 13.2. FUNKCE API Provede načtenı́ dat od pozice pl offset o velikosti pl size z umı́stěnı́ pc source do pc buf. Vstup: hdl – odkaz na strukturu IBP authhandle pc source – capability pro čtenı́ z IBP serveru ps timeout – časové limity pro komunikaci pc data – odkaz na pamět’kam uložit data z IBP serveru pl size – délka dat čtených ze serveru pl offset – počátek čtenı́ dat ze souboru na IBP serveru mcaps – identifikátor dat od metadata manažeru encrypt – úroveň šifrovanı́. 0 - šifrovánı́ přı́kazů, 1 - šifrovánı́ přı́kazů i dat Výstup: Při úspěchu vracı́ počet bytů přečtených ze serveru, při neúspěchu vracı́ 0 a nastavı́ IBP errno na jednu z těchto hodnot: IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP E E E E E E E E E E E E E E E E E TOO MANY UNITS: nelze vytvořit dalšı́ komunikačnı́ jednotku UNKNOWN FUNCTION: volána neznámá funkce pro zpracovánı́ komunikace SOCK READ: chyba čtenı́ dat při komunikaci SOCK WRITE: chyba zápisu dat při komunikaci BAD FORMAT: chybný formát přijatých dat, chybné čı́slo zprávy CONNECTION: chyba při navazovánı́ spojenı́ s IBP serverem INV PAR HOST: nebyl zadán název serveru INV PAR PORT: port je mimo povolený rozsah INV PAR PTR: chybný odkaz na data INV PAR SIZE: chybná velikost dat WRONG CAP FORMAT: špatný formát capabilit CAP NOT FOUND: capabilitám neodpovı́dá žádný prostor na serveru CAP NOT READ: capability nejsou určeny pro čtenı́ INVALID PARAMETER: chybný parametr v IBP přı́kazu CLIENT TIMEOUT: časový limit pro komunikaci s klientem vypršel FILE READ: server nemá právo čı́st ze souboru s daty GROUP: špatná skupina Komunikace: Odešle: IBPv031 IBP_LOAD msgNum identify offset size timeout encrypt msgNum – šifrované pořadové čı́slo zprávy, řetězec znaků hexadecimálnı́ soustavy identify – šifrovaný řetězec capabilities:keytype:mcaps capabilities – capability pro zápis na server, řetězec keytype – typ capabilit, řetězec mcaps – identifikátor dat od metadata manažeru. řetězec offset – počátek čtenı́ dat ze souboru na IBP serveru, integer size – velikost dat, integer 61 13.2. FUNKCE API timeout – časový limit pro zpracovánı́ přı́kazu serverem, integer encrypt – úroveň zabezpečenı́ dat, integer Přijme: IBP_OK size size – velikost dat odesı́laných serverem, integer Alternativně přijme: IBP_errno IBP errno – čı́slo chyby, integer Přijme: data data – v závislosti na úrovni šifrovánı́ šifrovaná nebo nešifrovaná binárnı́ data Počet výměn: 1 (+ 1 v přı́padě navazovánı́ nového spojenı́) 13.2.7 IBPs copy unsigned long int IBPs_copy(IBP_authhandle IBP_cap IBP_cap IBP_timer IBP_timer unsigned long int unsigned long int char char int hdl, ps_source, ps_target, ps_sourceTimeout, ps_targetTimeout, pl_size, pl_offset, *mcaps, mid[37], encrypt); Provádı́ kopı́rovánı́ dat od pozice pl offset o velikosti pl size ze zdroje ps source do cı́le ps target. Vstup: hdl – odkaz na strukturu IBP authhandle pc source – capability pro čtenı́ z IBP serveru pc target – capability pro zápis na IBP server ps sourceTimeout – časové limity pro komunikaci se zdrojovým IBP serverem ps targetTimeout – časové limity pro komunikaci s cı́lovým IBP serverem pl size – délka přenášených dat pl offset – počátek čtenı́ přenášených dat mcaps – identifikátor dat od metadata manažeru na zdrojovém IBP serveru mid – identifikátor dat od metadata manažeru na cı́lovém IBP serveru encrypt – úroveň šifrovanı́. 0 – šifrovánı́ přı́kazů, 1 – šifrovánı́ přı́kazů i dat Výstup: Při úspěchu vracı́ počet přenesených bytů, při neúspěchu vracı́ 0 a IBP errno nastavı́ na jednou z těchto hodnot: 62 13.2. FUNKCE API IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP E E E E E E E E E E E E E E E E E E E E TOO MANY UNITS: nelze vytvořit dalšı́ komunikačnı́ jednotku UNKNOWN FUNCTION: volána neznámá funkce pro zpracovánı́ komunikace SOCK READ: chyba čtenı́ dat při komunikaci SOCK WRITE: chyba zápisu dat při komunikaci BAD FORMAT: chybný formát přijatých dat, chybné čı́slo zprávy CONNECTION: chyba při navazovánı́ spojenı́ s IBP serverem INV PAR HOST: nebyl zadán název serveru INV PAR PORT: port je mimo povolený rozsah INV PAR PTR: chybný odkaz na data INV PAR SIZE: chybná velikost dat WRONG CAP FORMAT: špatný formát capabilit CAP NOT FOUND: capabilitám neodpovı́dá žádný prostor na serveru CAP NOT READ: capability nejsou určeny pro čtenı́ CAP NOT WRITE: capability nejsou určeny pro zápis INV IP ADDR: nezdařilo se spojenı́ s cı́lovým IBP serverm INVALID PARAMETER: chybný parametr v IBP přı́kazu WOULD EXCEED LIMIT: překročenı́ maximálnı́ povolené velikosti dat na serveru FILE ACCESS: server nemá přı́stup k souboru s daty CLIENT TIMEOUT: časový limit pro komunikaci s klientem vypršel FILE WRITE: server nemá právo psát do souboru s daty Komunikace: Odešle: IBPv031 IBP_SENDs msgNum identify offset size srcTimeout trgTimeout trgTimeout2 encrypt msgNum – šifrované pořadové čı́slo zprávy, řetězec znaků hexadecimálnı́ soustavy identify – šifrovaný řetězec srcCaps trgCaps keytype mcaps mid srcCaps – capability pro čtenı́ ze zdrojového serveru, řetězec trgCaps – capability pro zápis na cı́lový server, řetězec keytype – typ capabilit pro zdrojový server, řetězec mcaps – identifikátor dat od metadata manažeru na zdrojovém IBP serveru, řetězec mid – identifikátor dat od metadata manažeru na cı́lovém IBP serveru, řetězec offset – počátek čtenı́ dat ze souboru na IBP serveru, integer size – velikost dat, integer srcTimeout – časový limit pro zpracovánı́ přı́kazu zdrojovým serverem, integer trgTimeout – časový limit pro zpracovánı́ přı́kazu cı́lovým serverem, integer trgTimeout2 – časový limit pro komunikaci mezi cı́lovým a zdrojovým serverem, integer encrypt – úroveň zabezpečenı́ dat, integer Přijme: IBP_errno1 IBP_errno2 size IBP errno1 – výsledek operace na zdrojovém serveru IBP errno2 – výskledek operace na cı́lovém serveru size – velikost dat odeslaných ze zdrojového serveru na cı́lový server, integer Počet výměn: 1 (+ 1 v přı́padě navazovánı́ nového spojenı́) 63 13.2. FUNKCE API 13.2.8 IBPs manage int IBPs_manage(IBP_authhandle IBP_cap IBP_timer int int IBP_CapStatus hdl, ps_cap, ps_timeout, pi_cmd, pi_cap_type, ps_info); Provede informačnı́ nebo správnı́ operaci typu pi cmd nad prostorem specifikovaným os cap a přı́padný výsledek uložı́ do ps info. Vstup: hdl – odkaz na strukturu IBP authhandle pc cap – capability pro správu, přı́padně pro čtenı́ nebo zápis ps timeout – časové limity pro komunikaci pi cmd – čı́slo přı́kazu pro správu pi cap type – typ capabilit, souvisı́ s patřičným přı́kazem pro správu ps info – odkaz na strukturu IBP CapStatus Výstup: Při úspěchu vracı́ 0, při neúspěchu vracı́ -1 a IBP errno nastavı́ na jednou z těchto hodnot: IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP IBP E E E E E E E E E E E E E E E E E E E E TOO MANY UNITS: nelze vytvořit dalšı́ komunikačnı́ jednotku UNKNOWN FUNCTION: volána neznámá funkce pro zpracovánı́ komunikace SOCK READ: chyba čtenı́ dat při komunikaci SOCK WRITE: chyba zápisu dat při komunikaci BAD FORMAT: chybný formát přijatých dat, chybné čı́slo zprávy CONNECTION: chyba při navazovánı́ spojenı́ s IBP serverem INV PAR HOST: nebyl zadán název serveru INV PAR PORT: port je mimo povolený rozsah INV PAR PTR: chybný odkaz na data INV PAR SIZE: chybná velikost dat WRONG CAP FORMAT: špatný formát capabilit CAP NOT FOUND: capabilitám neodpovı́dá žádný prostor na serveru INV IP ADDR: nezdařilo se spojenı́ s cı́lovým IBP serverm INVALID PARAMETER: chybný parametr v IBP přı́kazu WOULD EXCEED LIMIT: překročenı́ maximálnı́ povolené velikosti dat na serveru CLIENT TIMEOUT: časový limit pro komunikaci s klientem vypršel CAP NOT MANAGE: capability nejsou určeny pro správu INVALID MANAGE CAP: špatné capability pro správu WOULD DAMAGE DATA: pokus změnit alokovaný prostor typu IBP FIFO INTERNAL: na IBP serveru došlo k vnitřnı́ chybě Komunikace: Odešle: IBPv031 IBP_MANAGE msgNum identify pi_cmd pi_cap_type timeout msgNum – šifrované pořadové čı́slo zprávy, řetězec znaků hexadecimálnı́ soustavy 64 13.3. DOPORUČENÝ POSTUP – UKÁZKA identify – šifrovaný řetězec capabilities keytype capabilities – capability pro správu, řetězec keytype – typ capabilit, řetězec pi cmd – přı́kaz pro správu, integer pi cap type – typ capabilit, int timeout – časový limit pro zpracovánı́ přı́kazu serverem, integer Odešle: IBPv031 IBP_MANAGE msgNum identify pi_cmd pi_cap_type maxSize lt_life reliability timeout msgNum – šifrované pořadové čı́slo zprávy, řetězec znaků hexadecimálnı́ soustavy identify – šifrovaný řetězec capabilities keytype capabilities – capability pro správu, řetězec keytype – typ capabilit, řetězec pi cmd – přı́kaz pro správu, integer pi cap type – typ capabilit, int maxSize – maximálnı́ velikost skladovacı́ho prostoru, integer lt life – maximálnı́ doba skladovanı́, integer reliability – spolehlivost skladovacı́ho prostoru, integer timeout – časový limit pro zpracovánı́ přı́kazu serverem, integer Přijme při přı́kazu IBP PROBE: IBP_errno msgNum readRefCount writeRedCount currentSize maxSize duration reliability type msgNum – šifrované pořadové čı́slo zprávy, řetězec znaků hexadecimálnı́ soustavy readRefCount – počet odkazů na capability pro čtenı́, integer writeRefCount – počet odkazů na capability pro zápis, integer currentSize – velikost dat uložených ve skladovacı́m prostoru, integer maxSize – maximálnı́ velikost skladovacı́ho prostoru, integer duration – maximálnı́ doba skladovánı́ dat, integer reliability – spolehlivost skladovacı́ho prostoru, integer type – druh skladovacı́ho prostoru, integer 13.3 Doporučený postup – ukázka V této části je výňatek ze zdrojového kódu programu example.c.Jedná se o upravenou verzi programu, který byl užit k testovanı́. Program po sobě provede posloupnost IBP přı́kazů uvedenou v kapitole 11. Komentář k částem kódu se nacházı́ mezi částmi kódu nebo přı́mo uvnitř kódu samotného. #define #define #define #define FULL 1 // 0 - sifrovani jen prikazu, 1 - plne sifrovani SECURE 1 // 0 - nezabezpecena verze, 1 - zabezpecena verze PRINT_CON 0 // 0 - nevypisovat, 1 - vypisovat tabulku spojeni SIZE 1*1024*1024 // velikost prenasenych dat 65 13.3. DOPORUČENÝ POSTUP – UKÁZKA #define LOOPS 10 // pocet testovacich cyklu #define #define #define #define #define FULL 1 SECURE 1 PRINT_CON 0 SIZE 1*1024*1024 LOOPS 5 void *testing_thread(void *arg) { Depot lbone; Depot *ret, *ret1; LBONE_request req; struct ibp_timer ls_timeout; unsigned long a,b; int i,j; FILE *in; char tmp[2000]; char pubkey[2000]; IBP_authhandle hd; struct ibp_attributes attr; IBP_set_of_caps caps, caps1; char *buf; char timekey[257]; unsigned long alloc_size = SIZE, alloc_size_align; Pro zabezpečenou komunikaci je potřeba, aby klient měl svůj soukromý klı́č a certifikát. /* load client private key */ memset(tmp, 0, 2000); in = fopen(”./key”, ”r”); fread(tmp, 1, 2000, in); fclose(in); for(i = 0; i < 256; i++) timekey[i]=’a’+i%20; timekey[i] = 0; /* load public key */ memset(pubkey, 0, 2000); in = fopen(”./cert”, ”r”); fread(pubkey, 1, 2000, in); fclose(in); 66 13.3. DOPORUČENÝ POSTUP – UKÁZKA Nejprve je nutné zı́skat od L–Bone serveru seznam dostupných IBP serverů. Prvnı́m dotazem zjistı́me, kolik serverů je v databázi L–Bone. /* get depots from lbone server */ lbone = malloc(sizeof(struct ibp_depot)); strcpy(lbone->host,”cache01.video.muni.cz”); lbone->port = 6767; lbone_depotCount(&a, &b, lbone, 5); printf(”Total depots %ld, live depots %ld\n”, a,b); Následně vytvořı́me požadavek, kolik IBP serverů chceme a jaké majı́ mı́t vlastnosti. req.numDepots = 5; req.stableSize = 10; req.volatileSize = 10; req.duration = 10; req.location = NULL; req.certificate = NULL; lbone_readCert(&req, ”./cert”); Zı́skáme seznam všech dostupných serverů, které vyhovujı́ našim požadavkům. /* get list of available depots */ printf(”Get depots\n”); ret = lbone_getDepots(lbone, req, 0); if (ret == NULL) { printf(”List of available depots is empty\n”); return NULL; } Zkontrolujeme, jestli jsou zı́skané servery dostupné. /* check status of available depots */ printf(”Check depots\n”); ret1 = lbone_checkDepots(ret, req, 10); if (ret1 == NULL) { printf(”List of suitable depots is empty\n”); return NULL; } 67 13.3. DOPORUČENÝ POSTUP – UKÁZKA printf(”Suitable depots:\n”); i = 0; while(ret1[i]) { printf(”Hostname: %s:%d ”, ret1[i]->host, ret1[i]->port); printf(”\n”); i++; } Nastavı́me časové limity pro komunikaci. ls_timeout.ServerSync = 1000; ls_timeout.ClientTimeout = 1000; Pokud bude komunikace šifrovaná, pak musı́me vytvořit a správně vyplnit strukturu IBP authhandle. if (SECURE == 1) { printf(”Creating autentification handler: IBP_auth_create\n”); if (IBP_auth_create(ret1[0], &hd, pubkey, tmp, &ls_timeout) != IBP_OK) { perror(”IBP_auth_create()”); fprintf(stderr, ”IBP errno: %d\n”, IBP_errno); return NULL; } } Vyplnı́me parametry důležité pro zažádánı́ o mı́sto na IBP serveru a alokujeme pamět’, kterou využijeme jako zdroj a cı́l přenášených dat. /* create atributes for allocate */ memset(&attr, 0, sizeof(attr)); attr.duration = time(NULL) + 3*3600; attr.reliability = IBP_STABLE; attr.type = IBP_BYTEARRAY; /* create testing data buffer */ alloc_size_align = (alloc_size+15)&˜15; buf = calloc(1, alloc_size_align); memset(buf, ’A’, alloc_size); buf[alloc_size-1] = ’B’; Zahájı́me vlastnı́ testovacı́ cyklus. /* *** MAIN LOOP ************************************************* */ for(j = 0; j < LOOPS; j++) { printf(”***** Loop #%d *****\n”, j+1); 68 13.3. DOPORUČENÝ POSTUP – UKÁZKA Nejprve musı́me alokovat prostor na IBP serveru. K tomu potřebujeme výše vytvořenou strukturu s údaji o tom, jaké vlastnosti má alokovaný prostor mı́t. Úspěšná alokace vrátı́ ukazatel na množinu capabilit. Neúspěšná vrátı́ NULL. /* allocate space on IBP server */ printf(”Allocating space on IBP server: IBP_allocate/IBPs_allocate\n”); if (SECURE == 1) { caps = IBPs_allocate(ret1[0], hd, &ls_timeout, alloc_size, &attr); } else { caps = IBP_allocate(ret1[0], &ls_timeout, alloc_size, &attr); } if(!caps) { perror(”IBP_allocate()/IBPs_allocate()\n”); fprintf(stderr, ”IBP errno: %d\n”, IBP_errno); return NULL; } printf(”Acquired capabilities: \n %s\n %s\n %s\n”, caps->readCap, caps->writeCap, caps->manageCap); if (PRINT_CON == 1) printConn(); Do alokovaného prostoru, identifikovaného capabilitami pro zápis, nahrajeme data z připraveného kusu paměti. Pokud se zápis podařı́, funkce vrátı́ počet zapsaných bytů shodný s velikostı́ dat, která jsme chtěli na server zapsat. /* store testing buffer */ printf(”Storing data on IBP server: IBP_store/IBPs_store\n”); printf(”Data size: %lu bytes\n”, alloc_size); if (SECURE == 1) { i = IBPs_store(hd, caps->writeCap, &ls_timeout, buf, alloc_size, UUIDCHARS, FULL); } else { i = IBP_store(caps->writeCap, &ls_timeout, buf, alloc_size); } 69 13.3. DOPORUČENÝ POSTUP – UKÁZKA printf(”Stored size: %d bytes\n”, i); if (i != alloc_size) { perror(”IBP_store()/IBPs_store()\n”); fprintf(stderr, ”IBP errno: %d\n”, IBP_errno); return NULL; } if (PRINT_CON == 1) printConn(); Data uložená na server načteme zpět do bloku paměti. Pro identifikaci správných dat na serveru je potřeba poskytnout serveru capability pro čtenı́. Pokud čtenı́ proběhlo úspěšně, pak funkce vrátı́ počet bytů shodný s požadovanou velikostı́ přijı́maných dat. /* loading data from IBP server */ printf(”Loading data from IBP server: IBP_load/IBPs_load\n”); printf(”Data size: %lu bytes\n”, alloc_size); if (SECURE == 1) { i = IBPs_load(hd, caps->readCap, &ls_timeout, buf, alloc_size, 0, timekey, FULL); } else { i = IBP_load(caps->readCap, &ls_timeout, buf, alloc_size, 0); } printf(”Loaded size: %d\n”, i); if { (i != alloc_size) perror(”IBP_load()/IBPs_load()\n”); fprintf(stderr, ”IBP errno: %d\n”, IBP_errno); return NULL; } if (PRINT_CON == 1) printConn(); Pro provedenı́ kopı́rovánı́ dat z jednoho IBP serveru na druhý potřebujeme mı́t vhodné capability pro přı́stup ke zdrojovému serveru a alokovaný prostor na cı́lovém serveru. Capability pro zdroj dat již máme, capability specifikujı́cı́ cı́lový prostor pro data musı́me zı́skat. Proto znovu provedeme IBP allocate. 70 13.3. DOPORUČENÝ POSTUP – UKÁZKA /* allocate space on IBP server for COPY command */ printf(”Preparing for IBP_copy/IBPs_copy command\n”); printf(”Allocating space on IBP server: IBP_allocate/IBPs_allocate\n”); if (SECURE == 1) { caps1 = IBPs_allocate(ret1[0], hd, &ls_timeout, alloc_size, &attr); } else { caps1 = IBP_allocate(ret1[0], &ls_timeout, alloc_size, &attr); } if(!caps1) { perror(”IBP_allocate()/IBPs_allocate()\n”); fprintf(stderr, ”IBP errno: %d\n”, IBP_errno); return NULL; } if (PRINT_CON == 1) printConn(); Následuje provedenı́ přı́kazu IBP copy. Výstup přı́kazu IBP copy a IBPs copy se lišı́. IBP API udává, že by IBP copy mělo vracet velikost přenesených dat, ale praxe ukázala, že v přı́padě úspěchu vracı́ hodnotu 1, což odpovı́dá IBP OK. I když v ukázce je toho využito, bylo by lepšı́ úspěch funkce podmı́nit výstupnı́ hodnotou většı́ než 0. Funkce IBPs copy vracı́ počet přenesených bajtů, který se v přı́padě úspěchu rovná požadované velikosti přenášených dat. printf(”Copy data from one IBP server to another:”); printf(” IBP_copy/IBPs_copy\n”); if (SECURE == 1) { i = IBPs_copy(hd, caps->readCap, caps1->writeCap, &ls_timeout, &ls_timeout, alloc_size, 0, timekey, UUIDCHARS2, FULL); } else { printf(”copy\n”); i = IBP_copy(caps->readCap, caps1->writeCap, &ls_timeout, &ls_timeout, alloc_size, 0); 71 13.3. DOPORUČENÝ POSTUP – UKÁZKA } printf(”Copy returned: %d\n”, i); if (((SECURE == 1) && (i != alloc_size)) || ((SECURE == 0) && (i != IBP_OK))) { perror(”IBP_copy()/IBPs_copy()\n”); fprintf(stderr, ”IBP errno: %d\n”, IBP_errno); return NULL; } if (PRINT_CON == 1) printCon(); Po provedenı́ všech operacı́ jsou struktury capabilit uvolněny. Pokud cyklus provedl požadovaný počet iteracı́, je ukončen a vlákno testing thread je také ukončeno. free(caps->readCap); free(caps->writeCap); free(caps->manageCap); free(caps); free(caps1->readCap); free(caps1->writeCap); free(caps1->manageCap); free(caps1); } return NULL;n(); } V hlavnı́ funkci main je důležité volánı́ inicializačnı́ funkce ibp init, které předcházı́ všem ostatnı́m volánı́m funkcı́ z IBP API. int main() { pthread_attr_t attribs; pthread_t tid1, tid2; ibp_init(); if(pthread_attr_init(&attribs) != 0) { perror(”pthread_attr_init()”); } 72 13.3. DOPORUČENÝ POSTUP – UKÁZKA if(pthread_attr_setdetachstate(&attribs, PTHREAD_CREATE_JOINABLE) != 0) { perror(”pthread_setdetachstate()”); } if(pthread_create(&tid1, &attribs, testing_thread, NULL) !=0) { perror(”pthread_create()”); } if(pthread_create(&tid2, &attribs, testing_thread, NULL) !=0) { perror(”pthread_create()”); } pthread_join(tid1, NULL); pthread_join(tid2, NULL); return 0; } 73 Literatura [1] Alessandro Bassi. Logistical networking. 2003. http://gign.ibcp.fr/reunion.2003-01-15/fic/Bassi-Alessandro. presentation.pdf. [2] Micah Beck, James S. Plank, Jeremy Millar, Scott Atchley, Stephen Soltesz, Alessandro Bassi, and Huadong Liu. Information security on the logistical network: An end-to-end approach. 2002. http://loci.cs.utk.edu/lors/files/sisw.pdf. [3] Micah Beck, James S. Plank, and Terry Moore. Ibp – the internet backplane protocol: Two page summary. 1998. http://loci.cs.utk.edu/ibp/files/pdf/CS-98-407.pdf. [4] Micah Beck, James S. Plank, and Terry Moore. The logistical computing stack, a design for wide-area, scalable, uninterruptible computing. 2002. http://loci.cs.utk.edu/ibp/files/pdf/DSN-2002-SUC.pdf. [5] EGEE. Site access control architecture. 2004. https://edms.cern.ch/document/523948. [6] Lukáš Hejtmánek, Luděk Matyska, and Michal Procházka. Secure logistical networking in virtual organizations. 2006. [7] Werner Koch and Moritz Schulte. The Libgcrypt Reference Manual, 2005. http://www.cse.psu.edu/˜cg497c/gcrypt.pdf. [8] Nikos Mavroyanopoulos and Simon Josefsson. GNU TLS, Transport Layer Security Library for the GNU system, 2005. [9] Yong Zheng. Ibp network function unit (nfu) api specificationf. 2003. http://loci.cs.utk.edu/ibp/files/pdf/IBP_NFU.pdf. [10] Yong Zheng, Alessandro Bassi, Micah Beck, James S. Plank, and Rich Wolski. Internet Backplane Protocol: C API 1.4, 2004. http://loci.cs.utk.edu/ibp/documents/IBPClientAPI.pdf. 74 Rejstřı́k ACL, 23, 25 AES, 38, 39, 41, 43, 54 Akamai, 7 Allocate, 17, 18, 45, 47, 48, 50 API, 18, 28–30, 35, 38, 41, 45, 54–56, 72 capability, 17–19, 32, 34, 47, 58, 59, 69, 70, 72 CDN, 7 certifikát, 20, 21, 25–27, 30, 38, 39, 41, 43, 66 cl info, 34 Copy, 17, 45, 48, 50 datové úložiště, 4, 12, 13, 15, 34 datový sklad, 5, 7, 9, 10, 12, 13, 15, 18, 19, 22–24, 26–28, 36, 54 distribuované datové úložiště, 4, 15 DNS, 7, 36 eXnode, 5, 6, 13, 24 fragmentace, 13 FTP, 9, 15 IBPs IBPs IBPs IBPs copy, 31–33, 62, 71 load, 31, 61 manage, 64 store, 31, 33, 59, 71 kontrolnı́ součty, 13 L–Bone, 5, 24, 25, 27, 28, 30, 32, 34, 41, 43, 55, 57, 67 Load, 17, 45, 46, 48–50 logistická sı́t’, 4, 5, 11–13, 19, 22–26, 38, 54 LoRS, 5, 13, 22 metadata katalog, 24 metadata manažer, 24–27, 59 mutex, 35, 36 OpenSSL, 20 PKI, 38, 54 POSIX, 23, 35 RSA, 38 grid, 4, 23, 26, 27 s–expression, 39, 41, 43 sdı́lené prostředky, 4, 15, 35, 36 heterogennı́ datový sklad, 4 soukromý klı́č, 25, 27, 28, 32, 39, 54, 56, 66 homogennı́ datové úložiště, 5 SSL, 19, 21, 22, 39 IBP protokol, 5, 13, 15–19, 21, 23, 27, 31, 34, 38, Store, 16, 17, 45–50 51, 54 TLS, 39 IBP server, 24, 25, 27–30, 32, 35, 38, 39, 41, 43, 45, 49, 54–59, 61, 62, 67–70 url, 7 IBP vrstva, 5, 6 veřejný klı́č, 25, 27, 28, 32–34, 39, 41, 54, 57 IBP auth, 31, 33, 34, 41, 57 virtuálnı́ organizace, 23–25, 27, 38, 54 IBP auth create, 29, 55, 56 vlákno, 31, 34–36, 72 IBP authhandle, 30, 31, 39, 41, 43, 56 VOMS, 25, 27, 28 IBP getkey, 33, 34 ibp init, 56 IBP load, 31 IBP store, 31 IBPs allocate, 58 X509, 25, 38, 39 XML, 5, 13 75
Podobné dokumenty
Polohové spínače - eatonelektrotechnika.cz
Ovládání nastavitelnou tyčkou
pro pásy dopravující lehké materiály
Ovládání pružnou tyčkou
pro poddajné ovládání ze všech stran
Ovládání tyčkou
Odnímatelný mechanismus zepředu
a Strana 8
NeBezpečnost 2014
Karel: Kubo prosimtě, já bych se chtěl připojit na virtuální server X, jo a krom toho jsem
Administrátor.
Kuba: Jasný Karle, není problém.