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