Autentizace dat

}w
!"#$%&'()+,-./012345<yA|
MASARYKOVA UNIVERZITA
FAKULTA INFORMATIKY
Autentizace dat
DIPLOMOVÁ PRÁCE
Bc. David Cimbůrek
Brno, 2005
Prohlášenı́
Prohlašuji, že tato diplomová práce 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: doc. RNDr. Václav Matyáš ml., M.Sc., Ph.D.
ii
Poděkovánı́
Děkuji vedoucı́mu mé práce doc. RNDr. Václavu Matyášovi ml., M.Sc., Ph.D.
za cenné rady, připomı́nky a všechen čas, který mi věnoval. Dále bych chtěl
poděkovat Mgr. Jiřı́mu Denemarkovi za jeho rady během mé práce na systému Netrw. Poděkovánı́ patřı́ i Petru Kovářovi za pomoc při testovánı́
přenosové rychlosti systému Netrw.
iii
Shrnutı́
V dnešnı́ době stále progresivněji se rozvı́jejı́cı́ digitálnı́ komunikace se stává
čı́m dál vı́ce aktuálnı́ otázka bezpečnosti této komunikace. Někdy je potřeba
obsah přenášených zpráv šifrovat, aby si jejich obsah mohli přečı́st pouze
povolanı́ lidé. Mnohdy však postačuje, když u zı́skané zprávy máme jistotu,
že ji skutečně zaslal ten, o kom si myslı́me, že ji zaslal, a že zpráva nebyla
během přenosu změněna. Touto problematikou se zabývá autentizace dat a
autentizaci dat je věnována tato práce.
Důležité pro autentizaci dat jsou hashovacı́ funkce, které dokážı́ udělat
z jakkoliv dlouhých dat jakýsi jejich otisk vždy stejné délky, který původnı́
data pokud možno co nejvěrněji reprezentuje. Tyto funkce je možné použı́t pro autentizaci dat napřı́klad ve spojenı́ s tajným heslem, nebo v mechanismech digitálnı́ch podpisů. Digitálnı́ podpisy hrajı́ v digitálnı́m světě
podobnou roli, jako ručně psané podpisy ve světě papı́rové komunikace.
Algoritmy digitálnı́ch podpisů jsou založeny převážně na objevech kryptografie.
Systém Netrw sloužı́ k rychlému přenosu dat přes Internet. V rámci
této práce do něj byl doplněn jednoduchý, avšak účinný a bezpečný systém
autentizace uživatelů a přenášených dat, který by měl ještě rozšı́řit jeho
použitelnost.
iv
Klı́čová slova
autentizace dat, autentizace uživatelů, digitálnı́ podpisy, hashovacı́ funkce,
Netrw
v
Sem bude v papı́rové podobě diplomové práce vložena kopie oficiálnı́ho
zadánı́.
vi
Obsah
Úvod . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1 Hashovacı́ funkce . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1.1 Základnı́ vlastnosti hashovacı́ch funkcı́ . . . . . . . . . . . .
1.2 Neklı́čované hashovacı́ funkce . . . . . . . . . . . . . . . . .
1.2.1 Hashovacı́ funkce založené na blokových šifrách . . .
1.2.2 Speciálnı́ hashovacı́ funkce . . . . . . . . . . . . . . .
1.2.3 Hashovacı́ funkce založené na modulárnı́ aritmetice .
1.2.4 Kontrolnı́ součty . . . . . . . . . . . . . . . . . . . . .
1.3 Klı́čované hashovacı́ funkce – autentizačnı́ kódy . . . . . . .
1.3.1 Autentizačnı́ kódy založené na blokových šifrách . .
1.3.2 Vytvářenı́ autentizačnı́ch kódů z hashovacı́ch funkcı́
1.3.3 MAA a MD5-MAC algoritmy . . . . . . . . . . . . . .
1.4 Útoky na hashovacı́ funkce . . . . . . . . . . . . . . . . . . .
2 Digitálnı́ podpisy . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1 RSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2 ElGamal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3 DSA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4 Feige-Fiat-Shamir . . . . . . . . . . . . . . . . . . . . . . . . .
3 Netrw . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1 Autentizace komunikujı́cı́ch stran . . . . . . . . . . . . . . . .
3.1.1 Autentizace jedné strany . . . . . . . . . . . . . . . . .
3.1.2 Autentizace obou stran . . . . . . . . . . . . . . . . .
3.2 Autentizace dat po dokončenı́ jejich přenosu . . . . . . . . .
3.2.1 Jednostranná autentizace dat . . . . . . . . . . . . . .
3.2.2 Oboustranná autentizace dat . . . . . . . . . . . . . .
3.3 Pomocné soubory . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 Soubor rand . . . . . . . . . . . . . . . . . . . . . . .
3.3.2 Soubor prev . . . . . . . . . . . . . . . . . . . . . . .
3.3.3 Soubor keys . . . . . . . . . . . . . . . . . . . . . . .
3.4 Použité nástroje . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Ověřenı́ bezpečnosti funkce mhash keygen ext() .
3.5 Parametry Netrw . . . . . . . . . . . . . . . . . . . . . . . . .
1
4
6
10
12
13
14
15
15
16
16
17
17
17
19
22
25
26
27
28
30
31
32
32
32
32
33
33
33
34
35
36
37
OBSAH
3.6
3.7
Implementace . . . . . . . . . . . . . . . . . . . . . .
Přı́klady použitı́ Netrw . . . . . . . . . . . . . . . .
3.7.1 Přenos dat bez autentizace . . . . . . . . . .
3.7.2 Přenos dat za použitı́ autentizace . . . . . . .
3.8 Testy rychlosti . . . . . . . . . . . . . . . . . . . . . .
3.8.1 Intel Celeron 900MHz . . . . . . . . . . . . .
3.8.2 AMD Duron 600MHz . . . . . . . . . . . . .
3.8.3 2× Pentium III 1 GHz . . . . . . . . . . . . .
3.8.4 Intel Celeron 900MHz, AMD Duron 600MHz
3.8.5 Shrnutı́ testů . . . . . . . . . . . . . . . . . . .
4 Závěr . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A Hashovacı́ funkce . . . . . . . . . . . . . . . . . . . . . . .
A.1 Hashovacı́ funkce Matyas-Meyer-Oseas . . . . . . .
A.2 Hashovacı́ funkce MD5 . . . . . . . . . . . . . . . . .
A.3 Hashovacı́ funkce SHA-1 . . . . . . . . . . . . . . . .
A.4 Algoritmus CBC-MAC . . . . . . . . . . . . . . . . .
A.5 Algoritmus MAA . . . . . . . . . . . . . . . . . . . .
A.6 Yuvalův narozeninový útok . . . . . . . . . . . . . .
B Netrw – komunikačnı́ protokol . . . . . . . . . . . . . .
B.1 Použı́vané zprávy . . . . . . . . . . . . . . . . . . . .
B.2 Komunikace . . . . . . . . . . . . . . . . . . . . . . .
C Testy rychlosti přenosu dat . . . . . . . . . . . . . . . . .
C.1 Intel Celeron 900 MHz . . . . . . . . . . . . . . . . .
C.2 AMD Duron 600 MHz . . . . . . . . . . . . . . . . .
C.3 2× Pentium III 1 GHz . . . . . . . . . . . . . . . . . .
C.4 Intel Celeron 900 MHz, AMD Duron 600 MHz . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
40
42
42
43
44
45
45
45
46
46
47
53
53
54
56
58
59
60
61
61
63
67
68
70
72
74
2
Seznam obrázků
1.1
1.2
1.3
1.4
1.5
1.6
Použitı́ CRC. . . . . . . . . . . . . . . . . . . . . . . . . .
Použitı́ hashovánı́ za pomoci autentizovaného kanálu.
Použitı́ hashovánı́ ve spolupráci s šifrovánı́m dat. . . .
Použitı́ autentizačnı́ch kódů. . . . . . . . . . . . . . . . .
Hashovacı́ funkce Matyas-Meyer-Oseas. . . . . . . . . .
Autentizačnı́ kód CBC-MAC. . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
7
8
8
9
13
16
2.1
2.2
2.3
2.4
2.5
2.6
Obecné schéma digitálnı́ho podpisu. . . . . . . . . . .
Schéma digitálnı́ho podpisu využı́vajı́cı́ho hashovánı́.
Rozšı́řený Eukleidův algoritmus. . . . . . . . . . . . .
Algoritmus RSA. . . . . . . . . . . . . . . . . . . . . .
Algoritmus ElGamal. . . . . . . . . . . . . . . . . . . .
Feige-Fiat-Shamir. . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
20
21
22
23
26
27
3.1
3.2
Komunikačnı́ protokol Netrw verze 1.2 (přı́klad). . . . . . .
Autentizačnı́ protokol – autentizace uživatelů (přı́klad). . . .
40
41
3
.
.
.
.
.
.
Úvod
Lidé mezi sebou odjakživa potřebovali komunikovat. Pokud se od sebe
nacházeli ve většı́ vzdálenosti, zası́lali si zprávy. Dřı́ve se tak dělo pomocı́
poslů a kurýrů, kteřı́ předávali informace od odesı́latele k přı́jemci. U takto
doručovaných zpráv se ovšem mohlo stát (a také stávalo), že byl během
jejich přepravy pozměněn jejich obsah nebo bylo dokonce doručeno úplně
jiné sdělenı́, než bylo odesláno. Takovéto modifikace často působily aktérům
komunikace značné škody, a proto byly postupně vyvinuty různé způsoby,
jak těmto změnám zabránit nebo je alespoň odhalit. Zprávy a dopisy se
začaly opatřovat podpisy odesı́latelů, voskovými pečetěmi a podobnými
mechanismy. Ty měly zajistit, aby odeslaná zpráva nemohla být nahrazena
zprávou podvodnou, přı́padně aby ke zprávě nemohl být dopsán dalšı́
text (podpis či pečet’byly pořı́zeny přı́mo pod poslednı́ řádek textu). Tento
způsob využitı́ samozřejmě předpokládal, že napsat správný podpis nebo
obtisknout do vosku pravou pečet’může pouze původnı́ odesı́latel.
S nástupem výpočetnı́ techniky a digitálnı́ komunikace se ovšem stávajı́cı́ situace dramaticky změnila. Stále vı́ce a vı́ce komunikace probı́há elektronickou formou a od starých metod zası́lánı́ zpráv se postupně upouštı́.
Mnoho lidı́ vyřizuje svou osobnı́ nebo obchodnı́ korespondenci pomocı́
e-mailu. Obchody se mnohdy domlouvajı́ a provádějı́ pomocı́ Internetu,
elektronickou formou se realizuje i množstvı́ velkých finančnı́ch operacı́ a
bankovnı́ch převodů, mnoho bank dnes poskytuje svým klientům internetové bankovnictvı́. Podvržená zpráva tedy může napáchat velmi rozsáhlé
škody. Proto je i v digitálnı́ komunikaci nutné zajistit integritu vyměňovaných zpráv a jistotu o identitě autorů těchto zpráv.
U digitálnı́ komunikace jsou ale dřı́ve uplatňované techniky ověřovánı́
integrity zprávy a identity jejı́ho autora nepoužitelné. Každý bit je stejný
jako kterýkoliv jiný a nelze tedy použı́t analogii ručně psaného podpisu.
Naštěstı́ přicházı́ na pomoc jiné techniky a metody. Byly vyvinuty postupy,
souhrnně označované jako digitálnı́ podpisy, které v digitálnı́m světě plnı́ podobnou (i když ne úplně stejnou) funkci jako klasické ručně psané podpisy.
Algoritmy digitálnı́ch podpisů jsou převážně založeny na poměrně nových
objevech v kryptografii. Důležitou roli v autentizaci dat hrajı́ i tzv. hashovacı́
4
ÚVOD
funkce, které dokážı́ z jakkoliv dlouhé zprávy vytvořit řetězec pevně dané
(většinou malé) délky, se kterým se dá dále operovat (např. právě v mechanismech digitálnı́ho podpisu). Základnı́ metody, nejpoužı́vanějšı́ algoritmy
a přı́klady použitı́ těchto postupů jsou popsány v dalšı́m textu této práce.
Součástı́ práce je systém Netrw-2.0 určený pro rychlý a jednoduchý
přenos dat přes Internet. Tento systém implementuje některé algoritmy a
postupy autentizace popsané v teoretické části. Umožňuje provádět autentizaci zası́laných dat i autentizaci uživatelů účastnı́cı́ch se přenosu. Snažı́
se tak při zachovánı́ vysoké přenosové rychlosti zvýšit bezpečnost výměny
dat přes počı́tačové sı́tě.
Rozvrženı́ kapitol
Prvnı́ kapitola práce se věnuje hashovacı́m funkcı́m, principům jejich práce
a několika nejpoužı́vanějšı́m algoritmům. Druhá kapitola se zaměřuje na
digitálnı́ podpisy, způsoby jejich použitı́ a obsahuje popis nejpoužı́vanějšı́ch
schémat digitálnı́ch podpisů. Třetı́ kapitola je věnována systému Netrw,
popisu implementace autentizace uživatelů a dat a testům rychlosti přenosu
dat.
5
Kapitola 1
Hashovacı́ funkce
Kryptografické hashovacı́ funkce (dále jen hashovacı́ funkce, pokud nebude explicitně uvedeno jinak) hrajı́ v autentizaci dat a potažmo v celé
kryptografii velmi důležitou a nezastupitelnou roli. Vytvářejı́ ze vstupnı́ch
dat libovolné délky jakési jejich „otisky“ pevné délky (řádově stovky bitů)
nazývané hash (hash-code, hash-result, hash-value, digest, fingerprint), které
původnı́ data (pokud možno jednoznačně) reprezentujı́. Toto se dá využı́t
v mnoha aplikacı́ch.
V oblasti kryptografických hashovacı́ch funkcı́ došlo v poslednı́ době
k závažným událostem. V zářı́ 2004 byly publikovány útoky, pomocı́ kterých byly prolomeny hashovacı́ funkce MD5, RIPEMD-128, HAVAL-128 a
SHA-0 a byly nalezeny nové obecnějšı́ techniky hledánı́ slabin iterativnı́ch
hashovacı́ch funkcı́, což jsou prakticky všechny dnes použı́vané důležité
hashovacı́ funkce.
Hashovacı́ funkce SHA-0 nenı́ přı́liš rozšı́řena, byla již dřı́ve nahrazena
dokonalejšı́ modifikacı́ nazývanou SHA-1. Rovněž funkce RIPEMD-128 a
HAVAL-128 se přı́liš nepoužı́vajı́. Ovšem hashovacı́ funkce MD5, přestože
se již delšı́ dobu doporučuje ji nepoužı́vat, je stále obsažena v mnoha současných systémech. Podrobnějšı́ informace o těchto hashovacı́ch funkcı́ch
jsou v kapitole 1.2.2.
Hashovacı́ funkce jsou velice užitečné ve dvou oblastech: při autentizaci
původu dat a při kontrole integrity dat. Co tyto dva pojmy přesně znamenajı́?
Mějme situaci, kdy subjekt B obdržı́ nějaká data. O těchto datech tvrdı́
subjekt A, že je jejich odesı́latelem. A právě pomocı́ mechanismů autentizace
původu dat je možné s jistotou určit, zda je A skutečným odesı́latelem těchto
dat.
Pomocı́ kontroly integrity dat je zase možné s jistotou určit, zda nebyla
data od doby vytvořenı́, během přenosu od odesı́latele k přı́jemci, až po
převzetı́ přı́jemcem nějakým způsobem neautorizovaně změněna.
Je třeba si uvědomit, že tyto dvě vlastnosti jsou spolu nerozlučně spjaty.
Data, která byla cestou od odesı́latele k přı́jemci změněna, majı́ nového
autora. A pokud nenı́ možné autora určit, nemůžeme se bavit o otázce
6
1. HASHOVACÍ FUNKCE
změny dat během přenosu.
Existuje několik způsobů, jak použı́t hashovacı́ funkce k autentizaci původu a ke kontrole integrity dat.
Hashovánı́ může být použito pro jednoduchou nezaručenou kontrolu
integrity dat dı́ky mechanismu kontrolnı́ch součtů (checksums), napřı́klad
pomocı́ CRC (Cyclic Redundancy Check). Tento postup ovšem odhalı́ pouze
neúmyslné chyby vzniklé při přenosu dat. Pro zjištěnı́, zda data nebyla nějakým způsobem modifikována či přı́mo zaslána nějakým útočnı́kem, se musı́
použı́vat sofistikovanějšı́ metody, protože CRC může k libovolným datům
vytvořit kdokoliv, tedy i přı́padný útočnı́k. Hashovacı́ funkce, které počı́tajı́
CRC, nejsou kryptografické (viz požadované vlastnosti kryptografických
hashovacı́ch funkcı́ popsané v kapitole 1.1).
Pøíjemce
Odesílatel
Neautentizovaný
kanál
Data
Data
CRC
CRC
CRC
?
Obrázek 1.1: Použitı́ CRC.
Způsoby, jak využı́t hashovacı́ funkce k skutečně zaručené kontrole integrity dat, jsou následujı́cı́.
Prvnı́ z nich je využitı́ jiného zabezpečeného komunikačnı́ho kanálu.
Data se zašlou normálně standardnı́m nezabezpečeným způsobem. Avšak
hash těchto dat se zašle přı́jemci nějakým zabezpečeným způsobem tak,
aby ji přı́padný útočnı́k nemohl pozměnit či zaměnit za nějakou jinou hash.
Přı́jemce si poté spočı́tá z obdržených dat svou hash a porovná ji s hashı́,
kterou obdržel od odesı́latele. Pokud se tyto hashe shodujı́, má jistotu, že
data nebyla cestou nijak změněna.
Hashovacı́ funkce je možné použı́t pro kontrolu integrity dat ve spojenı́ s nějakým šifrovacı́m mechanismem použı́vajı́cı́m symetrickou nebo
asymetrickou metodu šifrovánı́. Pokud je potřeba zajistit integritu dat, ale
nenı́ nutné obsah dat utajovat, je jejich šifrovánı́ zbytečné. Zabı́rá zbytečně
mnoho času a zvláště u asymetrické kryptografie je zdrženı́ u většı́ho množstvı́ dat reálně neúnosné. Ze zası́laných dat se tedy udělá hash stejně jako
7
1. HASHOVACÍ FUNKCE
Pøíjemce
Odesílatel
Neautentizovaný
kanál
Data
Data
Autentizovaný
kanál
Hash
Hash
?
Hash
Obrázek 1.2: Použitı́ hashovánı́ za pomoci autentizovaného kanálu.
v předchozı́m přı́padě, ale takto zı́skaná hash se zašifruje a zašle se společně
se zprávou nezabezpečeným způsobem. Přı́jemce zprávy si obdrženou hash
rozšifruje a z obdržených dat si spočı́tá svou vlastnı́ hash. Pokud jsou tyto
dvě hashe identické, znamená to, že data majı́ integritu neporušenou.
Neklı́čované hashovacı́ funkce (tj. funkce, které pro výrobu hashe nepoužı́vajı́ žádný tajný klı́č) jsou v anglické terminologii často označovány
zkratkou MDC (Modification Detection Code).
Pøíjemce
Odesílatel
Neautentizovaný
kanál
Data
Hash
Zašifrovaná
hash
Šifrovací
algoritmus
Hash
?
Data
Zašifrovaná
hash
Hash
Dešifrovací
algoritmus
Obrázek 1.3: Použitı́ hashovánı́ ve spolupráci s šifrovánı́m dat.
Dalšı́m způsobem využitı́ hashovacı́ch funkcı́ jsou tzv. autentizačnı́ kódy
(Message Authentication Codes, odtud často použı́vané zkratky MAC, plurál
MACs, též digitálnı́ pečetě, digital seals). Autentizačnı́ kódy dovolujı́ zajistit
autentizaci dat pomocı́ symetrických technik. Použı́vajı́ hashovacı́ funkce,
které majı́ dva různé vstupy: hashovaná data a tajný klı́č. Tyto funkce pak
produkujı́ hash, která má tu vlastnost, že za neznalosti klı́če je výpočetně
8
1. HASHOVACÍ FUNKCE
velmi obtı́žné požadovanou hash vyprodukovat.
Pøíjemce
Odesílatel
Neautentizovaný
kanál
Data
MAC
Data
MAC
Tajný klíè k
Tajný klíè k
MAC
?
Obrázek 1.4: Použitı́ autentizačnı́ch kódů.
Odesı́latel tedy spočı́tá za pomoci tajného klı́če MAC zası́laných dat,
data i MAC odešle přı́jemci, který si z obdržených dat spočı́tá pomocı́ svého
tajného klı́če (identického s klı́čem druhé strany) svůj MAC a tyto dva autentizačnı́ kódy porovná. Pokud jsou stejné, data nebyla cestou pozměněna
či nahrazena jinými.
Hashovacı́ funkce jsou též velmi často využı́vány v mechanismech digitálnı́ho podpisu (podrobně viz kapitola 2).
Poznámka. Český překlad anglického slova „hash“ zatı́m nenı́ ujednocený.
Běžně se použı́vajı́ výrazy haš, heš, či nepřekládané hash. Já se v celé diplomové práci budu držet termı́nu hash, i dı́ky vyjádřenı́ Jazykové poradny
Ústavu pro jazyk český AV ČR [1]:
Přejı́mánı́ cizı́ch slov je v terminologické oblasti velice časté. Právě
zde je výhodná mezinárodnı́ srozumitelnost a často i většı́ schopnost
vytvářet odvozeniny (přı́davná jména, slovesa). Přestože je pro češtinu
charakteristická tendence začleňovat přejı́maná slova co nejúplněji do
domácı́ho jazykového systému, a to jak po stránce hláskové, tak morfologické, nenı́ možné mechanicky nahrazovat jednotlivé cizı́ termı́ny
českými ekvivalenty, pokud nenı́ zaručena návaznost v rámci celého
pojmenovávacı́ho systému dané oblasti. Mı́ra tohoto začleněnı́ je pochopitelně u různých slov různá, nemůžeme postupovat mechanicky,
protože každé slovo reaguje na počešt’ovánı́ různě. Proces zapojovánı́
do české slovnı́ zásoby je pozvolný a postupný, některá slova si stále
zachovávajı́ původnı́ pravopis.
Doporučujeme zatı́m užı́vat anglickou podobu hash, proti počeštěnı́
mluvı́ i ne zcela jednotná výslovnost (heš – haš, „něco mezi a-e“).
9
1. HASHOVACÍ FUNKCE
1.1 Základnı́ vlastnosti hashovacı́ch funkcı́
V dalšı́ části diplomové práce jsem mnoho informacı́ (definice, kódy algoritmů) čerpal z [2].
Jak vlastně hashovacı́ funkce vypadajı́? Základnı́ neformálnı́ definice
řı́ká následujı́cı́:
Definice 1.1 – Hashovacı́ funkce. Hashovacı́ funkce je funkce h, která má
následujı́cı́ dvě vlastnosti:
• komprese – zobrazuje vstupnı́ data x libovolné (konečné) bitové délky
na data h(x) pevně dané bitové délky;
• snadnost výpočtu – pro danou hashovacı́ funkci h a libovolná vstupnı́
data x musı́ být výpočetně snadné spočı́tat hash h(x).
Přı́klad 1.2. Funkce, která počı́tá modulo 256 (tedy funkce, která vezme
vstupnı́ data, sečte všechny bajty těchto dat a jako výstup produkuje zbytek
po dělenı́ tohoto součtu čı́slem 256) je hashovacı́ funkce ve smyslu definice
1.1.
Dalšı́ důležité vlastnosti hashovacı́ch funkcı́ jsou následujı́cı́:
Definice 1.3 – Jednosměrnost. Hashovacı́ funkce h je jednosměrná (one-way,
preimage resistant), pokud pro každou zadanou hodnotu hashe y je výpočetně
obtı́žné nalézt nějakou vstupnı́ hodnotu x tak, aby platilo h(x) = y.
Přı́klad 1.4. Funkce f , která sčı́tá hodnoty znaků (podle tabulky ASCII)
ze zadaného řetězce modulo 256, nenı́ jednosměrná, protože pro dané čı́slo
v intervalu [0, 255] lze snadno nalézt data, jejichž modulo 256 má tuto hodnotu. Přı́klad – je zadáno čı́slo 195. Vezme se libovolný řetězec, napřı́klad
„ahoj“. Hodnota f (”ahoj”) je (97+104+111+106) mod 256 = 418 mod 256,
což je 162. Vezme se tedy znak s ASCII hodnotou 195 − 162 = 33, což je znak
„!“. Máme tedy nalezen řetězec „ahoj!“, pro který platı́: f (”ahoj!”) = 195.
Funkce f tedy nenı́ jednosměrná.
Naopak napřı́klad hashovacı́ funkce SHA-1 (viz přı́loha A.3) jednosměrná je.
Definice 1.5. Slabá bezkoliznost. Hashovacı́ funkce h má vlastnost slabé
bezkoliznosti (weak collision resistance, 2nd-preimage resistance), pokud je výpočetně obtı́žné nalézt k určené pevně dané vstupnı́ hodnotě x jinou vstupnı́
hodnotu x0 , x 6= x0 takovou, že h(x) = h(x0 ).
10
1. HASHOVACÍ FUNKCE
Slabá jednosměrná hashovacı́ funkce. Slabá jednosměrná hashovacı́
funkce (weak one-way hash function, one-way hash function) je hashovacı́ funkce
ve smyslu definice 1.1, která je navı́c jednosměrná a má vlastnost slabé
bezkoliznosti.
Definice 1.6. Silná bezkoliznost. Hashovacı́ funkce h má vlastnost silné
bezkoliznosti (collision resistance, strong collision resistance), pokud je výpočetně obtı́žné nalézt dvě různé libovolné vstupnı́ hodnoty x a x0 , pro které
platı́ h(x) = h(x0 ).
Silná jednosměrná hashovacı́ funkce. Silná jednosměrná hashovacı́
funkce (strong one-way hash function, collision resistant hash function) je hashovacı́ funkce ve smyslu definice 1.1, která má navı́c vlastnosti slabé i silné
bezkoliznosti.
Proč jsou tyto vlastnosti důležité?
Napřı́klad v mnoha systémech jsou hesla uložena v hashované podobě.
Uživatel při přihlašovánı́ zadá své heslo, z něj se spočı́tá jeho hash, která se
poté porovná s hashı́ uloženou v systému. Pokud jsou tyto hashe totožné,
přihlášenı́ proběhlo úspěšně. Pokud by měl potenciálnı́ útočnı́k přı́stup
k hashı́m v systému a použitá hashovacı́ funkce by nebyla jednosměrná,
mohl by lehce nalézt nějaké jiné heslo, které by mělo stejnou hash jako heslo
původnı́. Mohl by tak neoprávněně proniknout do systému.
U algoritmů digitálnı́ho podpisu (viz kapitola 2) se velmi často nepodepisujı́ celá data x, ale pouze jejich hash h(x). Použitá hashovacı́ funkce musı́
mı́t vlastnost slabé bezkoliznosti. Proč? Pokud odesı́latel podepı́še hash,
která byla zı́skána hashovacı́ funkcı́ nemajı́cı́ vlastnost slabé bezkoliznosti,
mohl by přı́padný útočnı́k nalézt nějaká jiná data x0 6= x, pro která by platilo
h(x0 ) = h(x). O těchto nových datech by mohl útočnı́k tvrdit, že je odesı́latel
podepsal a neexistovala by možnost, jak toto tvrzenı́ vyvrátit.
Pokud by mohl útočnı́k určit, jaká data bude odesı́latel podepisovat, je
nutné, aby použitá hashovacı́ funkce měla vlastnost silné bezkoliznosti. Tak
se opět zamezı́ útočnı́kovi (nebo nepoctivému odesı́lateli) v prohlášenı́, že
odesı́latel podepsal jiná data, než skutečně podepsal.
Definice 1.7 – Autentizačnı́ kódy. Autentizačnı́ kódy (MACs) tvořı́ skupinu
funkcı́ hk , kde k je tajný klı́č, s následujı́cı́mi vlastnostmi:
• Snadnost výpočtu – Pro daný autentizačnı́ kód hk , daný tajný klı́č k a
libovolná vstupnı́ data x musı́ být výpočetně snadné spočı́tat hodnotu
autentizačnı́ho kódu hk (x).
• Komprese – hk zobrazuje vstupnı́ data x libovolné (konečné) bitové
délky na data hk (x) pevně dané bitové délky.
11
1. HASHOVACÍ FUNKCE
• Odolnost při dané výpočetnı́ sı́le (computational resistance) – Pro každé
pevně zvolené k musı́ platit: Pokud je dáno libovolné množstvı́ dvojic
dat a jejich autentizačnı́ch kódů (xi , hk (xi )), je výpočetně obtı́žné bez
znalosti k nalézt nějakou dvojici (x, hk (x)), x 6= xi . (Nemusı́ platit
podmı́nka hk (x) 6= hk (xi ).)
Výrazy „výpočetně snadné“ a „výpočetně obtı́žné“ zde nejsou formálně
definovány. V praxi to ale znamená, že pokud je zı́skánı́ hodnoty funkce
výpočetně snadné, má výpočet maximálně polynomiálnı́ časovou a prostorovou složitost, tj. doba výpočtu (resp. množstvı́ paměti potřebné během
výpočtu) je vzhledem k délce vstupnı́ch dat shora omezena nějakou polynomiálnı́ funkcı́ (napřı́klad n6 nebo n2 + n, kde n je délka vstupnı́ch dat).
Doba výpočtu výpočetně snadných funkcı́ se za obvyklých okolnostı́ (a na
běžném hardwarovém vybavenı́) pohybuje v řádu maximálně vteřin či minut, zatı́mco pro výpočetně obtı́žné problémy se tato doba počı́tá od roků
až po miliardy let. Záležı́ ale samozřejmě na každé konkrétnı́ funkci a na
výpočetnı́ sı́le, kterou máme k dispozici. Většinou se u výpočetně obtı́žných problémů jedná o hledánı́ výsledku hrubou silou procházenı́m všech
možných řešenı́.
1.2 Neklı́čované hashovacı́ funkce
Drtivá většina hashovacı́ch funkcı́ pracuje iterativnı́m způsobem. To znamená, že nezahashuje všechna vstupnı́ data x najednou, ale rozdělı́ je na
bloky x1 , . . . , xn . Poté se jednotlivé bloky zpracovávajı́ hashovacı́m algoritmem, a to tı́m způsobem, že h(xi ) vždy závisı́ jak na přı́slušném bloku dat,
tak i na hashi předchozı́ho bloku. Platı́ tedy vztah h(xi ) = f (xi , h(xi−1 )).
Výsledná hash je rovna h(xn ). Takto je zaručeno, že hash je závislá na všech
částech dat.
Jistou nepřı́jemnostı́ ovšem je, že všechny vstupnı́ bloky xi musı́ mı́t
pevnou stejnou délku. Vstupnı́ data jsou ale velikosti libovolné. Tı́m docházı́
ke stavu, kdy je poslednı́ blok ve většině přı́padů kratšı́. Takovéto krátké
bloky se proto zarovnávajı́ na správnou délku. Této metodě „doplňovánı́“
poslednı́ho bloku se řı́ká padding. Bity do bloku by se měly doplňovat tak,
aby ze dvou různých vstupnı́ch bitových řetězů nemohly vzniknout po
doplněnı́ řetězy totožné. Padding by měl obsahovat i údaj udávajı́cı́ bitovou
délku původnı́ch dat.
12
1. HASHOVACÍ FUNKCE
1.2.1 Hashovacı́ funkce založené na blokových šifrách
Hlavnı́ důvod použı́vánı́ a vyvı́jenı́ hashovacı́ch funkcı́ založených na blokových šifrách je jednoduchý. Využı́vá se zde totiž funkce, která je již v systému obsažena (at’již softwarově či hardwarově) a nemusı́ se tudı́ž vyvı́jet
znovu.
Proč nemohou být jako hashovacı́ funkce použity přı́mo tyto blokové
šifry? Odpověd’ je nasnadě – samotné blokové šifry nemajı́ potřebné vlastnosti, napřı́klad nejsou jednosměrné. Proto se musı́ upravit tak, aby výsledná hashovacı́ funkce požadované vlastnosti měla.
Hashovacı́ funkce vytvořené z nbitových blokových šifer (tedy z šifer
produkujı́cı́ch nbitový výstup) lze rozdělit na dvě skupiny: funkce vytvářejı́cı́ hash délky n (single-length) a funkce, které produkujı́ hash délky 2n
(double-length). Proč se funkce s délkou hashe 2n zavádějı́? V praxi existuje
velké množstvı́ blokových šifer s délkou bloku 64 bitů. A hashe této délky
vytvořené použitı́m takovéto blokové šifry nemajı́ vlastnost silné bezkoliznosti. Proto se z těchto blokových šifer vytvářı́ hashovacı́ funkce produkujı́cı́
hash dvojnásobné délky, které již vlastnost silné bezkoliznosti majı́.
Z předcházejı́cı́ho vyplývá, že hashovacı́ funkce produkujı́cı́ hash délky
stejné jako je délka použité blokové šifry se konstruujı́ tak, aby měly vlastnosti slabých jednosměrných funkcı́. A hashovacı́ funkce, které vytvářejı́
hash dvojnásobné délky než použitá bloková šifra, jsou navrhovány tak,
aby měly vlastnosti silných jednosměrných hashovacı́ch funkcı́.
x2
x1
IV
g
E
H1
H1
g
xt
E
... H
t-1
g
H2
E
Ht
Obrázek 1.5: Hashovacı́ funkce Matyas-Meyer-Oseas.
Mezi slabé jednosměrné hashovacı́ funkce založené na blokových šifrách
patřı́ napřı́klad algoritmy Matyas-Meyer-Oseas (viz obrázek 1.5 a detailnı́
popis v přı́loze A.1), Davies-Meyer [3] nebo Miyaguchi-Preneel [4]. Typická
délka hashe při použitı́ těchto funkcı́ je 64 bitů.
Jako přı́klad silných jednosměrných hashovacı́ch funkcı́ použı́vajı́cı́ch
blokové šifry je možné uvést algoritmy MDC-2 a MDC-4 [5], které využı́vajı́
13
1. HASHOVACÍ FUNKCE
symetrickou blokovou šifru DES [6]. Obě generujı́ hash délky 128 bitů.
1.2.2 Speciálnı́ hashovacı́ funkce
Pod názvem speciálnı́ hashovacı́ funkce (customized hash functions) se skrývajı́ funkce, které byly od prvopočátku navrhovány jako hashovacı́ a nepoužı́vajı́ žádné jiné externı́ komponenty (jako napřı́klad blokové šifry).
Prvnı́m zástupcem z této skupiny je algoritmus MD4 [7] (Message Digest).
Z dat libovolné délky vytvářı́ 128bitovou hash. Funkce byla navrhována tak,
aby měla vlastnosti silné jednosměrné hashovacı́ funkce. Jejı́ rozlomenı́ tedy
mělo být možné pouze za použitı́ hrubé sı́ly. Nalezenı́ dvou vstupů, které
majı́ stejnou hash, mělo zabrat průměrně 264 operacı́ a nalezenı́ nějakých
vstupnı́ch dat odpovı́dajı́cı́ch předem zadané hashi mělo trvat průměrně
2128 operacı́.
Pro tuto hashovacı́ funkci ovšem byly nalezeny kolize, které snižujı́ čas
potřebný pro útok hrubou silou na pouhých 220 operacı́. Proto je doporučováno hashovacı́ funkci MD4 nadále nepoužı́vat.
Po tomto zjištěnı́ byla vytvořena hashovacı́ funkce MD5 [8] (viz detailnı́
popis v přı́loze A.2), která je založena na MD4, ale odstraňuje problémy
s kolizemi, které má funkce MD4. MD5 je opět 128bitová. Obsahuje 4 16krokové cykly (na rozdı́l od 3 cyklů u MD4) a dalšı́ změny oproti MD4, které
měly zaručovat bezkoliznost.
Na podzim roku 2004 byla však hashovacı́ funkce MD5 prolomena [9]
(byly nalezeny kolize) a neměla by již tedy být jako kryptografická hashovacı́ funkce použı́vána. MD5 dosáhla velikého rozšı́řenı́ a přestože již bylo
několik let doporučováno ji nepoužı́vat (mimo jiné proto, že byly nalezeny
kolize pro kompresnı́ funkci, kterou MD5 použı́vá), je dnes součástı́ mnoha
systémů a jejı́ nahrazenı́ nějakým bezpečným algoritmem bude stát v mnoha
přı́padech nemalé úsilı́ a náklady.
Spolu s MD5 byly prolomeny ještě dalšı́ hashovacı́ funkce: RIPEMD-128,
HAVAL-128 a SHA-0. Tyto funkce ale nejsou naštěstı́ přı́liš rozšı́řeny.
Obecně by se mělo upouštět od použı́vánı́ 128bitových hashovacı́ch
funkcı́, protože při dnešnı́ výpočetnı́ sı́le přestávajı́ poskytovat záruku bezpečnosti. Použı́vat by se měly alespoň 160bitové hashovacı́ funkce.
Mezi 160bitové hashovacı́ funkce patřı́ SHA-1 [10] (the Secure Hash Algorithm). Tento algoritmus je nástupcem algoritmu SHA-0. V současné době je
považován za bezpečný. Rozšı́řenı́ oproti SHA-0 jej dělá bezpečným i proti
nejnovějšı́m útokům. Dnes patřı́ mezi nejpoužı́vanějšı́ hashovacı́ funkce.
Je využı́ván napřı́klad v algoritmu digitálnı́ho podpisu DSS [11] (Digital
Signature Standard, viz kapitola 2.3).
14
1. HASHOVACÍ FUNKCE
Dalšı́ 160bitovou hashovacı́ funkcı́ založenou na MD4 je RIPEMD-160
[12]. V současné době se považuje za stejně silnou jako SHA-1.
Existujı́ i vı́cebitové varianty hashovacı́ funkce SHA-1. Jsou to funkce
SHA256, SHA384 a SHA512 [13], jejichž hashe majı́, jak je již z jejich názvů
patrné, délku postupně 256, 384 a 512 bitů. Tyto funkce byly vytvořeny
kvůli potřebám, které vznikly při vyvı́jenı́ nové symetrické šifry AES [14].
Souhrnně jsou označovány jako hashovacı́ funkce třı́dy SHA-2.
1.2.3 Hashovacı́ funkce založené na modulárnı́ aritmetice
Hlavnı́ výhodou funkcı́ založených na modulárnı́ aritmetice je, podobně
jako u hashovacı́ch funkcı́ vytvořených z blokových šifer, využitı́ v systému
již existujı́cı́ch částı́ pracujı́cı́ch s modulárnı́ aritmetikou, napřı́klad funkcı́
pro práci s digitálnı́mi podpisy. Nepřı́jemnou vlastnostı́ těchto hashovacı́ch
funkcı́ ovšem je, že ve srovnánı́ se speciálnı́mi hashovacı́mi funkcemi jsou
pomalejšı́.
Mezi hashovacı́ funkce pracujı́cı́ na principu modulárnı́ aritmetiky patřı́
napřı́klad MASH-1 nebo MASH-2 [15].
1.2.4 Kontrolnı́ součty
Kontrolnı́ součty (checksums), jak již bylo řečeno dřı́ve, patřı́ mezi nekryptografické mechanismy a použı́vajı́ se pro jednoduchou kontrolu integrity dat
během přenosu, nebo pro různé samoopravné kódy (error-correcting codes),
kdy jsou některé chyby nejen rozpoznány, ale i opraveny.
Nejčastěji použı́vanými kontrolnı́mi součty je skupina funkcı́ CRC [16]
(Cyclic Redundancy Code, nebo Cyclic Redundancy Check). Vytvářejı́ z dat libovolné délky hashe o pevné délce k (většinou 16 nebo 32 bitů). CRC je
založeno na vhodně zvoleném (k − 1)bitovém vektoru, jehož jednotlivé bity
jsou chápány jako koeficienty polynomu stupně k. Napřı́klad pro funkci
CRC-16 je často použı́ván polynom g(x) = 1 + x2 + x15 + x16 . Na vstupnı́
data délky t je obdobně nahlı́ženo jako na polynom d(x) stupně t − 1. Výsledná 16bitová hash je zbytek po dělenı́ polynomu x16 · d(x) polynomem
g(x). CRC funkce jsou často implementovány pomocı́ hashovacı́ch funkcı́,
mohou však použı́vat i jiné mechanismy.
Tento způsob kontroly integrity dat nemůže, jak již bylo řečeno dřı́ve, odhalit úmyslné změny v přenášených datech. Nedokáže také odhalit všechny
náhodné chyby, které vznikly během přenosu (i když naprostou většinu
ano).
15
1. HASHOVACÍ FUNKCE
1.3 Klı́čované hashovacı́ funkce – autentizačnı́ kódy
Klı́čované hashovacı́ funkce se vytvářejı́ podobnými způsoby jako neklı́čované. Pouze s tı́m rozdı́lem, že součástı́ vstupu je tajný klı́č k, bez jehož
znalosti musı́ být výpočetně velmi obtı́žné přı́slušný MAC vytvořit.
1.3.1 Autentizačnı́ kódy založené na blokových šifrách
Autentizačnı́ kódy vytvořené pomocı́ blokových šifer se svou konstrukcı́
velmi podobajı́ hashovacı́m funkcı́m pracujı́cı́m na tomto principu. Jako základ algoritmu je použita nějaká bloková symetrická šifra. Vstupnı́ data jsou
rozdělena na jednotlivé bloky a tyto bloky spolu s tajným klı́čem (přı́padně
ještě nějakým způsobem upravené) jsou zpracovány blokovou šifrou.
x1
0
k
E
xt
x3
x2
H3
H2
H1
E
k
H1
k
...
E
k
E
Ht
H3
H2
Ht-1
Zvýšení bezpeènosti
H
k
k'
E
E
-1
Obrázek 1.6: Autentizačnı́ kód CBC-MAC.
Nejčastěji použı́vanou klı́čovanou hashovacı́ funkcı́ založenou na blokové šifře je algoritmus CBC-MAC [17] (Cipher-Block-Chaining MAC), viz
schéma na obrázku 1.6 a přı́loha A.4). Jako blokovou šifru použı́vá nejčastěji DES, kde je délka jednotlivých bloků 64 bitů a klı́č má délku 56 bitů.
Pro zvýšenı́ bezpečnosti tohoto algoritmu se často použı́vá druhý klı́č k 0 ,
který snižuje možnost odhalenı́ hodnoty k a zabraňuje útokům vybraným
textem.
16
1. HASHOVACÍ FUNKCE
1.3.2 Vytvářenı́ autentizačnı́ch kódů z hashovacı́ch funkcı́
Hashovacı́ch funkcı́ existuje poměrně velké množstvı́. Tudı́ž se při vytvářenı́
autentizačnı́ch kódů nabı́zı́ myšlenka je nějakým způsobem využı́t tak, aby
se daly použı́t jako autentizačnı́ kódy.
Takovýchto metod je několik, většinou se nějak připojı́ tajný klı́č k ke
zpracovávaným datům. Možné je tedy zařadit k jako prefix dat, výsledný
MAC má tedy hodnotu hk (x) = h(k k x) (kde k je operace zřetězenı́),
nebo jako postfix: hk (x) = h(x k k). Použı́vané jsou i dalšı́, sofistikovanějšı́
metody, napřı́klad Hash-based MAC [18] (HMAC): HM AC(x) = h(k k p1 k
h(k k p2 k x)), kde p1 a p2 jsou řetězce, které doplňujı́ k tak, aby jeho délka
byla celočı́selným násobkem délky bloku.
1.3.3 MAA a MD5-MAC algoritmy
Tyto algoritmy byly navrženy úplně od začátku jako autentizačnı́ kódy,
nejsou v nich tedy použity žádné jiné mechanismy, jako napřı́klad blokové
šifry nebo hashovacı́ funkce.
Algoritmus MAA [19] (Message Authenticator Algorithm) použı́vá 64bitový tajný klı́č a vytvářı́ MAC o délce 32 bitů. Hlavnı́ smyčka algoritmu
je tvořena dvěma paralelnı́mi, na sobě nezávislými výpočty. Běh tohoto
algoritmu je zhruba dvakrát pomalejšı́ v porovnánı́ s hashovacı́ funkcı́ MD4.
MAA je detailně popsán v přı́loze A.5.
Algoritmus MD5-MAC [20] je odvozen od hashovacı́ funkce MD5. Tajný klı́č k se zde ovšem nepřidává pouze jako součást vstupnı́ch dat (jako
u autentizačnı́ch kódů založených na blokových šifrách), ale je, po určitých úpravách, použit odlišným způsobem dále v těle algoritmu. Rychlost
algoritmu MD5-MAC je zhruba srovnatelná s rychlostı́ hashovacı́ funkce
MD5.
1.4 Útoky na hashovacı́ funkce
Co je cı́lem útoků na hashovacı́ funkce? Útočnı́ci se vždy snažı́ využı́t slabin
jednotlivých funkcı́ a dosáhnout toho, čeho by teoreticky neměli být schopni.
U slabých jednosměrných hashovacı́ch funkcı́ je snahou útočnı́ka k zadané hashi y nalézt nějaká data x taková, aby platilo h(x) = y, nebo k zadané
dvojici (x, h(x)) nalézt data x0 , x0 6= x, pro která platı́ h(x0 ) = h(x). Ideálnı́
sı́la slabých jednosměrných hashovacı́ch funkcı́ by měla být 2n , tedy k jejich prolomenı́ by ideálně mělo být zapotřebı́ průměrně 2n operacı́, kde n
je bitová délka výsledné hashe. Tato délka by v současnosti měla být při
17
1. HASHOVACÍ FUNKCE
praktickém použitı́ alespoň 80 bitů.
Při útoku na silnou jednosměrnou hashovacı́ funkci je nutné nalézt různá
vstupnı́ data x a x0 taková, že platı́ h(x) = h(x0 ). Ideálnı́ sı́la této funkce je
2n/2 . Délka hashe silných jednosměrných funkcı́ by měla být při dnešnı́
výpočetnı́ sı́le počı́tačů alespoň 160 bitů.
Velké množstvı́ útoků proti hashovacı́m funkcı́m je postaveno na takzvaném „narozeninovém paradoxu“ (birthday paradox). Ten lze ilustrovat
následovně. Pokud je v jedné mı́stnosti 23 náhodně vybraných lidı́, pak
pravděpodobnost, že dva z nich budou mı́t narozeniny v ten samý den
v roce, je překvapivě vysoká – vı́ce než 50 %. S přibývajı́cı́m počtem lidı́ tato
pravděpodobnost rychle roste, takže pro 30 lidı́ je to již vı́ce než 70 %. Této
vlastnosti se dá využı́t při hledánı́ kolizı́ hashovacı́ch funkcı́.
Mezi nejznámějšı́ narozeninové útoky patřı́ Yuvalův narozeninový útok
(Yuval’s birthday attack) popsaný v přı́loze A.6. Je aplikovatelný na všechny
neklı́čované hashovacı́ funkce. Útok je úspěšný po průměrně 2n/2 operacı́ch.
Jeho nevýhodou ovšem je, že ke svému chodu potřebuje velké množstvı́
paměti. Velikost potřebné paměti je možné zmenšit tı́m, že vytvářenı́ modifikacı́ x01 a x02 z x1 a x2 je deterministické a nenı́ tedy potřeba pozměněná
data ukládat.
Dalšı́ útoky využı́vajı́ konkrétnı́ vlastnosti jednotlivých hashovacı́ch
funkcı́. Zaměřujı́ se na jejich iterativnı́ podstatu, zkoumajı́ kompresnı́ funkci
(napřı́klad použı́vanou symetrickou šifru), řetězcové proměnné a snažı́ se
nalézt slabiny v jejich aplikaci.
U autentizačnı́ch kódů se útočnı́k snažı́ bez znalosti klı́če k spočı́tat
nějakou novou dvojici (x, hk (x)) za znalosti libovolného množstvı́ dvojic
(xi , hk (xi )), xi 6= x. U správně navrženého MACu by měla být pravděpodobnost nalezenı́ takovéto dvojice rovna maximu z hodnot 2−t a 2−n , kde
t je délka tajného klı́če a n délka autentizačnı́ho kódu. K odhalenı́ klı́če by
mělo být třeba průměrně 2t operacı́. Pro praktickou bezpečnost by měla být
v dnešnı́ době délka autentizačnı́ho kódu alespoň 64 bitů při délce klı́če
64–80 bitů.
18
Kapitola 2
Digitálnı́ podpisy
Klasický ručně psaný podpis má široké uplatněnı́ a použı́vá se v mnoha oblastech. Od klasického podpisu očekáváme několik zásadnı́ch vlastnostı́. Je
to předevšı́m nepadělatelnost, tedy nikdo by neměl být schopen podepsat
se podpisem někoho jiného. Z podpisu by mělo být jednoznačně určitelné
(resp. ověřitelné), kdo jej pořı́dil. Podpis musı́ být neoddělitelně spjatý s podepisovaným dokumentem, aby ho přı́padný útočnı́k nemohl použı́t pro
podpis nějakého jiného dokumentu. Dalšı́ důležitou vlastnostı́ je nepopiratelnost původu – když někdo nějaký dokument podepı́še, nemůže později
tento podpis popřı́t.
Technologie digitálnı́ch podpisů sloužı́ ke stejným účelům, jako podpisy
klasické, použı́vajı́ se ovšem v digitálnı́m světě.
Mějme dva subjekty A a B (v literatuře jsou často označovány jako Alice
a Bob), které si chtějı́ vyměňovat zprávy podepsané pomocı́ technik digitálnı́ho podpisu. Jaké vlastnosti musı́ digitálnı́ podpis mı́t?
Obecná definice digitálnı́ho podpisu je následujı́cı́:
Definice 2.1 – Digitálnı́ podpis. Digitálnı́ podpis je datový řetězec, který
spojuje zprávu (v digitálnı́ podobě) s odesı́latelem této zprávy.
V praxi se jedná o nějaká data, která jsou nerozlučně spojena s podepisovanou zprávou (či obecně s jakýmikoliv daty) a která poskytujı́
• autentizaci – o daném dokumentu je možné s jistotou řı́ci, kdo jej
podepsal;
• integritu – jistotu, že zpráva nebyla během přenosu neoprávněně
pozměněna;
• nepopiratelnost původu – pokud někdo podepı́še nějakou zprávu,
nemůže později tvrdit, že ji nepodepsal
pomocı́ mechanismu veřejných klı́čů.
Jak výše zmı́něný mechanismus veřejných klı́čů vypadá? Každá osoba,
která chce podepisovat zprávy, musı́ mı́t dva tzv. klı́če – soukromý (private
19
2. DIGITÁLNÍ PODPISY
key) a veřejný (public key). Jejich délka je typicky několik set bitů. Soukromý
klı́č se použı́vá při pořizovánı́ digitálnı́ho podpisu. Musı́ platit, že bez znalosti soukromého klı́če je (prakticky) nemožné digitálnı́ podpis vytvořit.
Každý tedy musı́ zajistit důvěrnost svého soukromého klı́če, protože při
jeho znalosti by mohl správný digitálnı́ podpis vytvořit kdokoliv. U veřejného klı́če je situace opačná. Hodnotu veřejného klı́če přı́slušné osoby musı́
znát každý, kdo chce ověřit platnost digitálnı́ho podpisu tohoto člověka.
Odesílatel
(Alice)
Data
Pøíjemce
(Bob)
Alicin
soukromý klíè
Algoritmus
digitálního podpisu
Alicin
veøejný klíè
Certifikát Alicina
veøejného klíèe
Podepsaná data
Algoritmus ovìøení
digitálního podpisu
Obrázek 2.1: Obecné schéma digitálnı́ho podpisu.
Při komunikaci Alice s Bobem se může stát, že nějaký útočnı́k podstrčı́
Bobovi svůj veřejný klı́č, ale prohlásı́ ho za Alicin. Poté může Bobovi zası́lat
zprávy podepsané svým soukromým klı́čem. Bob si bude myslet, že zprávy
jsou od Alice a že jejich digitálnı́ podpis je v pořádku.
Proto je nutné zajistit nějakým způsobem integritu veřejného klı́če. K tomu se použı́vá certifikát veřejného klı́če. Certifikát veřejného klı́če je údaj, který
spojuje veřejný klı́č s určitou osobou (nebo spı́še s nějakým identifikátorem,
který danou osobu jednoznačně určuje). Certifikát veřejného klı́če bývá
většinou digitálně podepsán certifikačnı́ autoritou, což je nějaká instituce,
které všechny zúčastněné strany důvěřujı́. Tento podpis zaručuje pravost
certifikátu, a tedy i veřejného klı́če s tı́mto certifikátem spojeným.
Tı́mto způsobem se problém integrity veřejných klı́čů všech účastnı́ků
komunikace redukuje na problém zajištěnı́ integrity veřejného klı́če certifikačnı́ autority. Tu je již třeba zajistit jiným způsobem, napřı́klad osobnı́m
odběrem veřejného klı́če v pobočce certifikačnı́ autority.
Naprostá většina použı́vaných algoritmů digitálnı́ho podpisu je založena na asymetrické kryptografii. Ta je ovšem časově velmi náročná. Při
podepisovánı́ zpráv, které majı́ většı́ délku, by digitálnı́ podepisovánı́ znamenalo neúměrné zdrženı́. Proto se v praxi nepodepisuje celá zpráva, ale
20
2. DIGITÁLNÍ PODPISY
pouze jejı́ hash. Ta musı́ být vytvořena pomocı́ silné jednosměrné hashovacı́
funkce, jak je popsáno v kapitole 1.1.
Odesílatel
(Alice)
Data
Pøíjemce
(Bob)
Alicin
soukromý klíè
Alicin
veøejný klíè
Certifikát Alicina
veøejného klíèe
Data
Data
Hash
Hash
?
Hash
Algoritmus
digitálního podpisu
Podepsaná hash
Algoritmus ovìøení
digitálního podpisu
Obrázek 2.2: Schéma digitálnı́ho podpisu využı́vajı́cı́ho hashovánı́.
Pokud chce tedy Alice zaslat Bobovi digitálně podepsanou zprávu za
pomoci hashovánı́, probı́há celý proces následovně. Alice vytvořı́ ze zası́lané zprávy hash, tu digitálně podepı́še a zprávu i podepsanou hash zašle
Bobovi. Ten si pomocı́ Alicina veřejného klı́če (opatřeného certifikátem)
zkontroluje, že hash skutečně podepsala Alice. Poté si z obdržené zprávy
spočı́tá hash a zkontroluje, zda je shodná s hashı́, která byla opatřena digitálnı́m podpisem. Pokud ano, má jistotu, že zprávu odeslala skutečně Alice
a že byla řádně podepsána.
V praxi přicházı́ s použı́vánı́m soukromých a veřejných klı́čů spousta
problémů, které je potřeba nějakým způsobem řešit. Může se stát, že přes
veškerá opatřenı́ zı́ská útočnı́k hodnotu např. Alicina soukromého klı́če.
V takovém přı́padě je nutné zajistit, aby certifikačnı́ autorita přestala poskytovat certifikát k veřejnému klı́či, který přı́slušı́ k tomuto Alicinu odcizenému soukromému klı́či. Problém spočı́vá v tom, jak zajistit, aby se všichni
účastnı́ci komunikace dozvěděli o zrušenı́ certifikátu včas a útočnı́k nestačil
napáchat nějaké škody. Zároveň je potřeba, aby si Alice vytvořila nový pár
svých klı́čů a veřejný opět nechala opatřit certifikátem.
Podobný problém nastává, pokud zaměstnanec opouštı́ své mı́sto v ně-
21
2. DIGITÁLNÍ PODPISY
Vstup: Dvě celá nezáporná čı́sla a a b, a ≥ b.
Výstup: Čı́slo d = nsd (a, b) a celá čı́sla x, y, pro která platı́: ax + by = d.
1. Pokud b = 0, pak nastav hodnoty výsledných proměnných na d = a, x = 1, y = 0
a skonči.
2. Nastav pomocné proměnné: x2 = 1, x1 = 0, y2 = 0, y1 = 1.
3. Dokud platı́ b > 0, dělej následujı́cı́:
• q = b ab c, r = a − qb, x = x2 − qx1 , y = y2 − qy1 .
• a = b, b = r, x2 = x1 , x1 = x, y2 = y1 , y1 = y.
4. Nastav hodnoty výsledných proměnných na d = a, x = x2 , y = y2 a skonči.
Obrázek 2.3: Rozšı́řený Eukleidův algoritmus.
jakém podniku a použı́val zde soukromý klı́č, kterým podepisoval zprávy
coby zaměstnanec podniku. Při jeho odchodu se musı́ zajistit, aby tento klı́č
nemohl nikdo nadále použı́vat (napřı́klad proto, aby zaměstnanec nemohl
svůj bývalý podnik zneužitı́m tohoto soukromého klı́če poškodit).
Důležité je, že digitálnı́ podpis sám o sobě nedává žádnou informaci
o tom, kdy byl pořı́zen. Pokud je tuto informaci potřeba k podpisu připojit,
musı́ se použı́t jiných mechanismů.
2.1 RSA
Kryptografický systém RSA [21] je pojmenován po pánech Rivestovi, Shamirovi a Adelmanovi, kteřı́ jej v roce 1977 publikovali.1 Dnes je to nejpoužı́vanějšı́ algoritmus v systémech pracujı́cı́ch s asymetrickou kryptografiı́,
proto bude popsán podrobněji než ostatnı́ algoritmy. Systém RSA je založen na myšlence, že přestože násobenı́ dvou prvočı́sel je relativně snadné,
faktorizace jejich násobku je obtı́žná (samozřejmě bez znalosti oněch dvou
součinitelů).
Pokud chce Alice Bobovi zaslat nějakou zprávu opatřenou digitálnı́m
podpisem pomocı́ RSA, musı́ mı́t nejdřı́ve vygenerován svůj soukromý a
veřejný klı́č. To provede následovně. Nejprve zvolı́ dvě velká různá prvo1
Algoritmus, který je ekvivalentnı́ s RSA, byl ve skutečnosti objeven již v roce 1973. Použı́vala jej ovšem britská informačnı́ služba GCHQ (Government Communications Headquarters) a tento objev podléhal přı́snému utajenı́. K odhalenı́ tohoto faktu došlo až
v roce 1997.
22
2. DIGITÁLNÍ PODPISY
Generovánı́ klı́čů
1. Vygeneruj dvě velká náhodná a od sebe různá prvočı́sla p a q, která majı́ přibližně
stejnou velikost.
2. Spočı́tej n = pq a ϕ(n) = (p − 1)(q − 1).
3. Zvol libovolné celé čı́slo e, 1 < e < ϕ(n), pro které platı́: nsd(e, ϕ(n)) = 1.
4. Použij rozšı́řený Eukleidův algoritmus (viz obrázek 2.3) pro nalezenı́ jedinečného
čı́sla d, 1 < d < ϕ(n), pro které platı́ ed ≡ 1 (mod ϕ(n)), tedy d ≡ e−1 (mod ϕ(n)).
5. Veřejný klı́č je (e, n), soukromý klı́č je (d, n).
Vytvořenı́ digitálně podepsané zprávy
1. Zpráva m musı́ být čı́slo v rozsahu [0, n).
2. Spočı́tej s = md mod n. s je digitálnı́ podpis zprávy m.
Ověřenı́ digitálnı́ho podpisu
1. Zı́skej Alicin veřejný klı́č (e, n).
2. Spočı́tej m = se mod n. m je původnı́ hodnota zprávy.
Obrázek 2.4: Algoritmus RSA.
čı́sla p a q. Z nich spočı́tá jejich součin pq = n. Dále spočı́tá hodnotu Eulerovy
funkce pro n (viz definice 2.3), ϕ(n) = (p − 1)(q − 1) (podle věty 2.4). Potom zvolı́ libovolné celé čı́slo e menšı́ než ϕ(n), které je s ϕ(n) nesoudělné.
Dvojice čı́sel (e, n) nynı́ tvořı́ Alicin veřejný klı́č.
Dále musı́ Alice vypočı́tat svůj soukromý klı́č d. Ten spočı́tá podle vztahu
ed ≡ 1 (mod ϕ(n)). Platı́ tedy d ≡ e−1 (mod ϕ(n)). e−1 existuje, protože e
bylo zvoleno s ϕ(n) nesoudělné. Hodnota d se dá spočı́tat napřı́klad pomocı́
rozšı́řeného Eukleidova algoritmu popsaného na obrázku 2.3. Soukromý
klı́č Alice tvořı́ dvojice čı́sel (d, n).
Pokud chce nynı́ Alice podepsat nějakou zprávu m, stačı́ když spočı́tá
s = md (mod n). Digitálnı́ podpis zprávy m je s.
Jestliže chce Bob ověřit digitálnı́ podpis zprávy a zı́skat jejı́ hodnotu,
spočı́tá pomocı́ hodnoty Alicina veřejného klı́če (e, n) (ponechme nynı́ stranou otázku certifikátu veřejného klı́če) původnı́ hodnotu zprávy: m = se
(mod n).
Celé schéma RSA je popsáno na obrázku 2.4.
Přı́klad 2.2. Alice volı́ prvočı́sla p = 7, q = 17 (pro praktické použitı́ jsou
23
2. DIGITÁLNÍ PODPISY
prvočı́sla přı́liš malá, jako přı́klad však postačujı́). Dále spočı́tá n = pq =
7 · 17 = 119 a ϕ(n) = ϕ(119) = 6 · 16 = 96. Zvolı́ e = 77 a spočı́tá d, napřı́klad
podle schématu na obrázku 2.3. Vyjde d = 5. Soukromý klı́č Alice je tedy
(5, 119), jejı́ veřejný klı́č tvořı́ dvojice čı́sel (77, 119). Předpokládejme, že
Alicı́ zası́laná zpráva má hodnotu napřı́klad m = 197. Toto čı́slo se nevejde
do požadovaného rozsahu [0, 119). Musı́ se tedy rozdělit, napřı́klad na dva
bloky s hodnotami m1 = 19 a m2 = 7, ze kterých si poté Bob složı́ původnı́
hodnotu zprávy. Nynı́ Alice podepı́še oba bloky: s1 = 195 mod 119 = 66,
s2 = 75 mod 119 = 28. Alice tedy zašle Bobovi čı́sla 66 a 28.
Bob zı́ská Alicin veřejný klı́č a na obdržená čı́sla aplikuje výpočet: m1 =
77
66 mod 119 = 19 a m2 = 2877 mod 119 = 7. Z těchto výsledků poskládá
původnı́ zprávu m = 197.
Jak vypadá matematické pozadı́ celého algoritmu? Při obnovovánı́ zprávy m z s se počı́tá jejı́ původnı́ hodnota jako se mod n. Protože platı́ s ≡ md
(mod n), dá se odvodit se ≡ (md )e ≡ mde (mod n). Ze vztahu mezi veřejným
a soukromým klı́čem ed ≡ 1 (mod ϕ(n)) je vidět, že platı́ ed = 1 + k(p −
1)(q − 1) pro nějaké k ∈ Z − {0}. Dostáváme tedy se ≡ m1+k(p−1)(q−1) ≡
m · mk(p−1)(q−1) (mod n).
Protože je p prvočı́slo, platı́ podle malé Fermatovy věty (2.5) m(p−1) ≡ 1
(mod p). Dále je vidět, že m(p−1)(q−1)k ≡ (m(p−1) )(q−1)k ≡ 1(q−1)k (mod p) ≡
1 (mod p). q je také prvočı́slo, musı́ tedy platit analogicky m(q−1)(p−1)k ≡ 1
(mod q).
Podle věty 2.6 dostáváme m(p−1)(q−1)k mod pq = 1 mod pq = 1 mod
n. Pokud se nynı́ vrátı́me k původnı́mu vztahu, dostaneme požadovaný
výsledek: se mod n = m · mk(p−1)(q−1) mod n = m · 1 mod n = m mod
n = m.
Zde jsou uvedeny použı́vané definice a věty.
Definice 2.3 – Eulerova funkce. Necht’n je přirozené čı́slo. Symbolem ϕ(n)
označı́me počet všech přirozených čı́sel menšı́ch než n a nesoudělných s n.
Funkce ϕ se nazývá Eulerova funkce.
Věta 2.4.
(a) Pro libovolné prvočı́slo p platı́: ϕ(p) = p − 1.
(b) Pro libovolná nesoudělná přirozená čı́sla p, q platı́: ϕ(p·q) = ϕ(p)·ϕ(q).
Věta 2.5 – Malá Fermatova věta. Necht’p je prvočı́slo a a je čı́slo, které je s p
nesoudělné. Pak platı́ ap−1 ≡ 1 (mod p).
Věta 2.6 – Čı́nská zbytková věta. Pokud jsou p a q dvě nesoudělná čı́sla a
24
2. DIGITÁLNÍ PODPISY
pro čı́sla x a y platı́ x ≡ y (mod p) a x ≡ y (mod q), pak platı́ x ≡ y (mod pq).
Bezpečnost RSA vyplývá ze skutečnosti, že aby bylo možné z veřejného
klı́če (e, n) zı́skat hodnotu soukromého klı́če (d, n), musel by útočnı́k faktorizovat čı́slo n, aby zı́skal hodnoty prvočı́sel, z nichž se n skládá a pomocı́
nichž je tedy možné soukromý klı́č vypočı́tat. Dnes ovšem neexistuje pro
faktorizaci velkých čı́sel žádný efektivnı́ algoritmus,2 zbývá tedy metoda
hrubou silou. Délka klı́če by proto dnes měla být alespoň 1024 bitů.
2.2 ElGamal
Dalšı́m použı́vaným schématem pro digitálnı́ podpis je algoritmus ElGamal [22]. Jeho bezpečnost je založena na obtı́žnosti výpočtu diskrétnı́ch
logaritmů, tedy obecně na obtı́žnosti výpočtu hodnoty čı́sla a ze vztahu
q a ≡ y (mod p), kde hodnoty q, q a , y a p jsou známé.
Celý algoritmus je podrobně popsán na obrázku 2.5. Na rozdı́l od RSA
nenı́ možné z digitálnı́ho podpisu obnovit původnı́ hodnotu zprávy, ta musı́
být zaslána zvlášt’.
Přı́klad 2.7. Alice chce vygenerovat svůj veřejný a soukromý klı́č a zası́lat
Bobovi digitálně podepsané zprávy pomocı́ schématu ElGamal.
Volı́ tedy parametry p = 2357, q = 2, a = 1751. Dále spočı́tá y = 21751
mod 2357 = 1185. Veřejný klı́č Alice je tedy (2357, 2, 1185).3
Pro zjednodušenı́ předpokládejme, že pro podepisovanou zprávu platı́
m ∈ Z∗p a pro hashovacı́ funkci platı́ h(m) = m. Alice chce Bobovi zaslat
napřı́klad zprávu m = 1463. Zvolı́ náhodné k = 1529 a spočı́tá r = 21529
mod 2357 = 1490 a k −1 mod (p − 1) = 245. Nynı́ již může spočı́tat s =
245{1463 − 1751 · 1490} mod 2356 = 1777. Digitálnı́ podpis zprávy m tvořı́
dvojice čı́sel (1490, 1777).
Aby Bob digitálnı́ podpis ověřil, spočı́tá v1 = 11851490 · 14901777 mod
2357 = 1072 a v2 = 21463 mod 2357 = 1072. Protože v1 = v2 , je digitálnı́
podpis v pořádku.
2
Ve skutečnosti takový algoritmus existuje, jmenuje se Shorův. Jeho časová složitost je
polynomiálnı́. Je ovšem navržený pro kvantové počı́tače. V současné době však žádný
kvantový počı́tač schopný pracovat s velkými čı́sly neexistuje a pravděpodobně ještě
dlouho existovat nebude.
3
Zvolené parametry jsou, stejně jako v přı́kladu 2.1, pro praktické použitı́ přı́liš malé.
V praxi se volı́ délka p několik set bitů.
25
2. DIGITÁLNÍ PODPISY
Generovánı́ klı́čů
1. Vygeneruj velké náhodné prvočı́slo p a generátor q multiplikativnı́ grupy Z∗p .
2. Zvol náhodné celé čı́slo a, 1 ≤ a ≤ p − 2.
3. Spočı́tej y = q a mod p.
4. Veřejný klı́č je trojice (p, q, y). Soukromý klı́č je (p, q, a).
Vytvořenı́ digitálně podepsané zprávy
1. Zvol náhodné tajné celé čı́slo k, 1 ≤ k ≤ p − 2, pro které platı́ nsd(k, p − 1) = 1.
2. Spočı́tej r = q k mod p.
3. Spočı́tej k−1 mod (p − 1).
4. Spočı́tej s = k−1 {h(m) − ar} mod (p − 1). h je hashovacı́ funkce, jejı́ž obor hodnot
musı́ být Z∗p .
5. Digitálnı́ podpis zprávy m je dvojice (r, s).
Ověřenı́ digitálnı́ho podpisu
1. Zı́skej Alicin veřejný klı́č (p, q, y).
2. Zkontroluj, zda platı́ 1 ≤ r ≤ p − 1. Pokud ne, podpis je chybný.
3. Spočı́tej v1 = y r rs mod p.
4. Spočı́tej h(m) a v2 = q h(m) mod p.
5. Pokud platı́ v1 = v2 , je digitálnı́ podpis v pořádku. Pokud platı́ v1 6= v2 , je podpis
chybný.
Obrázek 2.5: Algoritmus ElGamal.
2.3 DSA
Na obtı́žnosti výpočtu diskrétnı́ch logaritmů je založen i dalšı́ algoritmus
digitálnı́ho podpisu, jmenuje se DSA [11] (Ditital Signature Algorithm) a je
velmi podobný algoritmu ElGamal. Algoritmus DSA je zajı́mavý tı́m, že byl
v roce 1994 vybrán americkým standardizačnı́m úřadem NIST [23] (National
Institute of Standards and Technology) pro standard digitálnı́ho podpisu DSS
(Digital Signature Standard). Bylo to vůbec prvnı́ schéma digitálnı́ho podpisu,
které bylo uznáno za standard vládou nějaké země.
26
2. DIGITÁLNÍ PODPISY
Generovánı́ klı́čů
1. Vygeneruj dvě velká náhodná a od sebe různá prvočı́sla p a q, která majı́ přibližně
stejnou velikost. Spočı́tej n = pq.
2. Zvol kladné celé čı́slo k a navzájem různá celá čı́sla s1 , s2 , . . . , sk ∈ Z∗n .
3. Spočı́tej vj = s−2
mod n, 1 ≤ j ≤ k.
j
4. Veřejný klı́č je k-tice (v1 , v2 , . . . , vk ) a čı́slo n. Soukromý klı́č je k-tice (s1 , s2 , . . . , sk )
a čı́slo n.
Vytvořenı́ digitálně podepsané zprávy
1. Zvol náhodné celé čı́slo r, 1 ≤ r ≤ n − 1
2. Spočı́tej u = r2 mod n.
3. Spočı́tej e = (e1 , e2 , . . . , ek ) = h(m k u); pro každé ei platı́: ei ∈ {0, 1}.
4. Spočı́tej s = r ·
k
Q
e
sj j mod n.
j=1
5. Digitálnı́ podpis zprávy m je dvojice (e, s).
Ověřenı́ digitálnı́ho podpisu
1. Zı́skej Alicin veřejný klı́č (v1 , v2 , . . . , vk ) a n.
2. Spočı́tej w = s2 ·
k
Q
e
vj j mod n.
j=1
3. Spočı́tej e0 = h(m k w).
4. Pokud platı́ e0 = e, je digitálnı́ podpis v pořádku. Pokud je e0 6= e, podpis odmı́tni.
Obrázek 2.6: Feige-Fiat-Shamir.
2.4 Feige-Fiat-Shamir
Algoritmus digitálnı́ho podpisu Feige-Fiat-Shamir [24] je založen na faktu,
že zatı́mco nalezenı́ odmocniny nějakého čı́sla modulo p, kde p je prvočı́slo,
je relativně snadné, problém nalezenı́ odmocniny modulo n, kde n je čı́slo
složené a jeho součinitelé nejsou známi, je považován za výpočetně velmi
obtı́žný. Bezpečnost algoritmu je tedy, podobně jako u RSA, založena na
obtı́žnosti faktorizace velkých čı́sel.
27
Kapitola 3
Netrw
Balı́k Netrw [25] sloužı́ pro jednoduchý a rychlý přenos dat přes Internet
bez použitı́ dalšı́ch podpůrných nástrojů jako napřı́klad ftp. Umožňuje
také spočı́tat hash zası́laných dat pomocı́ několika hashovacı́ch algoritmů
(MD5, SHA-1 a RIPEMD-160). Netrw je možné provozovat na unixových
operačnı́ch systémech (Linux [26], Solaris [27], IRIX [28], OpenBSD [29],
. . . ) a na systémech Windows [30] (95/98/NT/2000/XP). Celý je napsaný
v programovacı́m jazyce C pod licencı́ GNU GPL [31].
Balı́k se skládá ze dvou programů – klientů: netwrite sloužı́ pro zası́lánı́ dat a netread pro přijı́mánı́ těchto dat.
Typické použitı́ Netrw vypadá následovně. Pro přenesenı́ napřı́klad
souboru data.tar.bz2 z počı́tače host1.somewhere.net na počı́tač
host2.somewhere.net stačı́ zadat přı́kazy:
• Na počı́tači host2.somewhere.net:
netread 50000 >data.tar.bz2
Po tomto přı́kazu bude netread čekat na portu 50000 na spojenı́ a na
přı́chozı́ data, která po obdrženı́ uložı́ do souboru data.tar.bz2.
• Na počı́tači host1.somewhere.net:
netwrite host2.somewhere.net 50000 <data.tar.bz2
Tento přı́kaz ustanovı́ spojenı́ s počı́tačem host2.somewhere.net
na portu 50000 (kde již musı́ být spuštěn netread očekávajı́cı́ spojenı́
na tomto portu) a pošle mu soubor data.tar.bz2.
Po ukončenı́ přenosu si obě strany vzájemně zašlou hash přenesených
dat pro kontrolu jejich integrity během přenosu. Jsou takto informovány,
zda byla data doručena v pořádku a bez chyb.
Data je možné přenášet protokoly TCP [32] a UDP [33] (přičemž druhý
z nich sloužı́ spı́še pro testovacı́ účely).
Za normálnı́ch okolnostı́ navazuje spojenı́ netwrite. Pokud je ovšem
na straně klienta netread v jeho lokálnı́ sı́ti aplikován překlad adres nebo
28
3. NETRW
zakázáno navazovánı́ spojenı́ zvenku lokálnı́ sı́tě, spojenı́ takto nelze ustanovit. Proto obsahuje Netrw přepı́nač -f, který zapne tzv. firewall mód. Ten
způsobı́, že spojenı́ naváže netread.
Přenos dat potom vypadá následovně:
• Na počı́tači host1.somewhere.net se zadá přı́kaz
netwrite -f 50000 <data.tar.bz2
• Na počı́tači host2.somewhere.net se zadá
netread -f host1.somewhere.net 50000 >data.tar.bz2
Pokud je potřeba přenést vı́ce souborů najednou, na unixových strojı́ch
se to dá provést napřı́klad pomocı́ přı́kazů
netread 50000 | tar xf na straně přijı́majı́cı́ a přı́kazů
tar cf - file1 file2 | \
netwrite host2.somewhere.net 50000
na straně odesı́lajı́cı́.
Na systémech Windows je nutné vı́ce souborů sdružit do jednoho pomocı́ nějakého jiného nástroje (napřı́klad WinZip [34], WinRar [35]), přenést
tento jeden soubor a na přijı́majı́cı́ straně z tohoto archı́vu vyextrahovat
původnı́ soubory.
Data se během přenosu žádným způsobem nešifrujı́. Proto je jejich přenos velmi rychlý. U velkého množstvı́ datových přenosů šifrovánı́ dat ani
nenı́ třeba. A pokud je, pro šifrovaný přenos souborů existujı́ jiné nástroje
(napřı́klad SCP [36]).
U obdržených dat zaslaných pomocı́ Netrw však také neexistuje ani
žádná záruka, že jejich odesı́latel je skutečně ten, koho přı́jemce na druhé
straně spojenı́ očekává. Data mohou být podvržena nějakým útočnı́kem,
a naopak, data se ke správnému přı́jemci nemusı́ vůbec dostat, protože je
může přijmout útočnı́k.
Úkolem této práce bylo upravit systém Netrw tak, aby si zachoval svou
dosavadnı́ funkčnost, a navı́c implementoval systém autentizace dat a autentizace jednotlivých komunikujı́cı́ch stran.
Před vlastnı́m přenosem obě strany zjistı́, zda komunikujı́cı́ partner je
skutečně tı́m, za koho se vydává (aby se data zbytečně neposı́lala nějakému
útočnı́kovi, nebo naopak od útočnı́ka nepřijı́mala). Poté se provede vlastnı́
přenos dat a pomocı́ výměny autentizačnı́ho kódu těchto dat (spočı́taného
pomocı́ sdı́leného klı́če) se ověřı́ jejich autenticita. Přijetı́m autentizačnı́ho
kódu si zároveň odesı́latel ověřı́, že data dorazila ke správnému přı́jemci.
29
3. NETRW
3.1 Autentizace komunikujı́cı́ch stran
Proces autentizace mezi dvěmi komunikujı́cı́mi stranami zajišt’uje jedné
nebo oběma stranám určitou (samozřejmě pokud možno co největšı́) dávku
jistoty o skutečné identitě druhé strany.
Pro autentizaci přes sı́t’je nutné použı́t nějaký autentizačnı́ protokol. Nejčastěji použı́vané autentizačnı́ protokoly jsou protokoly typu výzva-odpověd’.
Na autentizačnı́ protokoly typu výzva-odpověd’ jsou kladeny tyto podmı́nky:
• Odposlech zası́laných zpráv útočnı́kovi nepomůže v podvodné autentizaci.
• Po odeslánı́ a přijetı́ všech zpráv má jedna nebo obě strany jistotu
o identitě druhého komunikujı́cı́ho partnera.
Autentizačnı́ protokoly jsou založeny na několika různých technikách.
Některé protokoly použı́vajı́ symetrickou kryptografii, jiné zase asymetrickou. Existujı́ i tzv. „zero knowledge“ protokoly (protokoly s nulovým
rozšı́řenı́m znalostı́), které umožňujı́ demonstrovat znalost nějakého tajemstvı́ bez odhalenı́ jakékoliv informace vedoucı́ k zı́skánı́ tohoto tajemstvı́
útočnı́kem.
V systému Netrw bude použit pro autentizaci obou stran před začátkem
přenosu dat autentizačnı́ protokol založený na symetrické kryptografii. Symetrická kryptografie je rychlá, nevyžaduje spoluúčast třetı́ strany a pokud
se zvolı́ vhodný algoritmus, pak je i bezpečná.
Co bývá obsahem zası́laných zpráv? Většinou se jedná o obdobu jedné
z následujı́cı́ch variant:
• Náhodná čı́sla – Pokud se autentizuje Alice Bobovi, zašle nejprve
Bob Alici nějaké náhodné čı́slo r. Alice pak Bobovi zašle zpět toto
náhodné čı́slo zašifrované pomocı́ sdı́leného symetrického klı́če nebo
jeho autentizačnı́ kód. Bob si takto může snadno ověřit, že Alice skutečně zná sdı́lené tajemstvı́. Ve skutečnosti se většinou nepoužı́vajı́
přı́mo náhodná čı́sla (jejich generovánı́ je obtı́žné, vyžaduje speciálnı́
hardware), ale čı́sla pseudonáhodná.
• Sekvence – Mı́sto náhodných čı́sel se použı́vá monotónně rostoucı́
sekvence čı́sel. Takto se zajistı́ jednoznačná identifikace zpráv. Zajišt’uje se tak i zabráněnı́ útokům přehránı́m předchozı́ komunikace.
30
3. NETRW
• Časová razı́tka – Obě strany musı́ mı́t spolu synchronizované hodiny. Každá zpráva pak obsahuje své časové razı́tko. Tak je zajištěna
jedinečnost zpráv a časová přesnost.
Při použitı́ sekvencı́ a časových razı́tek musı́ být obě strany nějakým způsobem sesynchronizované. Tato skutečnost vyžaduje jejich dalšı́ dodatečnou
komunikaci, která nemusı́ být triviálnı́. Při použitı́ těchto mechanismů by
musel být návrh Netrw zbytečně složitý. Proto bude autentizace prováděna
pomocı́ pseudonáhodných čı́sel.
Zprávy budou navı́c obsahovat časový údaj, aby nemohly být použity
pro nějakou variantu útoku přehránı́m. Časový údaj zde neplnı́ úlohu časového razı́tka (komunikujı́cı́ strany nemajı́ synchronizované hodiny). Navı́c je možné, že jedna strana (přı́padně obě) má hodiny nastavené úplně
špatně. To je bohužel skutečnost, se kterou se bez sofistikované časové synchronizace nedá nic dělat. Na tyto časové údaje se tedy nedá spoléhat, plnı́
zde spı́še jakousi informativnı́ funkci (pokud se napřı́klad posunou hodiny
komunikujı́cı́ho partnera o většı́ časový úsek nazpět oproti předchozı́ komunikaci, může se jednat o nějaký útok přehránı́m atp.).
3.1.1 Autentizace jedné strany
Pokud se před začátkem přenosu autentizuje pouze Bob Alici, komunikace
vypadá následovně:
A → B : tA , rA , nameA @machineA , nameB @machineB
B → A : tB , Hk (tA , tB , rA , nameB @machineB , nameA @machineA )
Použité symboly majı́ následujı́cı́ významy:
tA – Časový údaj strany A. Údaj tvořı́ jedno čı́slo, které má podobu
unix time.qqqqqq, kde prvnı́ část tvořı́ unixový čas (tedy počet vteřin od 1. ledna 1970) a qqqqqq udává počet mikrosekund.
rA – Pseudonáhodné čı́slo strany A délky 8 bajtů (tj. čı́slo v rozmezı́ 0
až 264 − 1).
nameA @machineA – Označenı́ komunikujı́cı́ strany. nameA může být
napřı́klad login nebo plné jméno (ve formátu napřı́klad Jmeno
Prijmeni bez mezery mezi slovy). Vzhledem k tomu, že jména
budou použı́vána jak v unixových systémech tak i v systémech
Windows, je lepšı́ se vyvarovat znaků z národnı́ch abeced a vystačit si se standardnı́mi ASCII znaky. machineA je jméno stroje
v podobě napřı́klad host1.somewhere.net.
31
3. NETRW
Hk – Autentizačnı́ kód s klı́čem k. V systému bude použit autentizačnı́
kód typu HMAC (viz kapitola 1.3.2). Klı́č je symetrický a obě
strany jej sdı́lejı́.
3.1.2 Autentizace obou stran
Pokud se před začátkem přenosu autentizujı́ vzájemně obě strany, jejich
komunikace pak bude vypadat následovně:
A → B : tA , rA , nameA @machineA , nameB @machineB
B → A : tB , rB , nameB @machineB , nameA @machineA ,
Hk (tB , tA , rB , rA , nameB @machineB , nameA @machineA )
A → B : Hk (tA , tB , rA , rB , nameA @machineA , nameB @machineB )
3.2 Autentizace dat po dokončenı́ jejich přenosu
Vlastnı́ protokol autentizace dat po dokončenı́ jejich přenosu vypadá podobně, jako protokol zajišt’ujı́cı́ autentizaci komunikujı́cı́ch stran. Pouze jsou
v autentizačnı́m kódu započı́távána i přenášená data.
3.2.1 Jednostranná autentizace dat
Při prováděnı́ jednostranné autentizace dat provádı́ výpočet autentizačnı́ho
kódu jenom jedna strana a po dokončenı́ výpočtu tento kód zašle straně
druhé.
Protože se při autentizaci dat bude jednat o stále stejné TCP spojenı́
jako při autentizaci uživatelů a hodnoty náhodných čı́sel a časových údajů
použitých při autentizaci uživatelů nebyly v žádné předchozı́ komunikaci
použity pro autentizaci dat, je možné je zde použı́t. Ušetřı́ se tı́m režie
potřebná pro jejich zası́lánı́.
B → A : tB , Hk (data, tA , tB , rA , nameB @machineB , nameA @machineA )
3.2.2 Oboustranná autentizace dat
Protokol oboustranné autentizace dat po dokončenı́ jejich přenosu je prováděn analogicky jako při jednostranné autentizaci. Autentizačnı́ kód ovšem
počı́tajı́ obě strany a po přenosu dat si své kódy vyměnı́.
B → A : Hk (data, tB , tA , rB , rA , nameB @machineB , nameA @machineA )
32
3. NETRW
A → B : Hk (data, tA , tB , rA , rB , nameA @machineA , nameB @machineB )
3.3 Pomocné soubory
Netrw bude ke své činnosti využı́vat některé pomocné soubory. Soubory
budou uloženy v adresáři $HOME/.netrw každého uživatele. Tento adresář
musı́ mı́t nastavena práva čtenı́, přı́stupu a zápisu pouze pro jejich vlastnı́ka, aby citlivý obsah souborů v něm obsažených nemohl čı́st (či dokonce
modifikovat) někdo nepovolaný. Stejně tak samotné tyto soubory musı́ mı́t
nastavena práva pro čtenı́ a zápis pouze pro vlastnı́ka.
Musı́ být také nějakým způsobem omezena maximálnı́ velikost těchto
souborů (to se netýká souboru keys). Po přesáhnutı́ této velikosti se ze
souborů budou automaticky vymazávat nejstaršı́ položky.
U pomocných souborů rand a prev by se mohlo stát, že v přı́padě, kdy
by nějaký útočnı́k zı́skal právo zápisu do těchto souborů, mohl by je naplnit
falešnými údaji nebo přı́padně ze souboru prev odstranit údaje o předchozı́
komunikaci a využı́t toho k nějaké variantě útoku přehránı́m předchozı́
komunikace (viz popis obsahu souboru prev v části 3.3.2). Proto budou
tyto dva soubory obsahovat autentizačnı́ kód, který bude počı́tán z jejich
obsahu. Jako klı́č bude použito globálnı́ heslo uživatele (viz kapitola 3.3.3).
Při každém čtenı́ údajů z těchto souborů bude prováděna kontrola jejich
integrity a při každém zápisu bude jejich autentizačnı́ kód přepočı́táván.
3.3.1 Soubor rand
Tento soubor obsahuje u Alice položky ve tvaru
< autentizační kód >
rA1
rA2
rA3
.
.
.
kde rAi jsou pseudonáhodná čı́sla, která uživatel během předchozı́ činnosti
použı́val. Každé nově vygenerované pseudonáhodné čı́slo je porovnáváno
s čı́sly v tomto souboru. Pokud již bylo toto čı́slo použito dřı́ve, vygeneruje
se nové.
3.3.2 Soubor prev
V tomto souboru jsou ukládány položky ve tvaru
33
3. NETRW
< autentizační kód >
rA1 jmenoB @strojB tB1
rA2 jmenoC @strojC tC1
rA3 jmenoB @strojB tB2
rA4 jmenoD @strojD tD1
..
.
rB1
rC1
rB2
rD1
Znak značı́ mezeru. Tento soubor obsahuje historii dřı́vějšı́ komunikace
(autentizace).
Při komunikaci s Bobem provádı́ Alice následujı́cı́ testy:
• Pokud je hodnota přijatého tB menšı́ nebo rovna hodnotě největšı́ho
tBn uloženého v souboru, odmı́tni spojenı́, protože se může jednat
o útok.
• Pokud je hodnota přijatého rB stejná, jako hodnota některého rBi , rCi ,
. . . v souboru, vyžádej si nové rB .
Samozřejmě se může stát, že Bob si od doby poslednı́ komunikace s Alicı́
přenastavil na svém počı́tači hodiny o nějaký čas nazpátek. Od tohoto okamžiku jej však bude při každém pokusu o spojenı́ s nı́m považovat Alice za
útočnı́ka. Tomu lze zabránit bud’ smazánı́m Bobových záznamů z Alicina
souboru prev nebo přepı́načem, který Netrw obsahuje a který způsobuje,
že informace ze souboru prev nebudou brány v potaz.
3.3.3 Soubor keys
Aby si nemusel uživatel pamatovat všechna hesla pro komunikaci se svými
partnery, je vhodné uložit je do nějakého souboru. Zároveň je možné uložit do tohoto souboru „základnı́ “ port, tj. port, přes který bude probı́hat
komunikace, pokud nebude explicitně zadán port jiný. Položka portu je
volitelná.
Tento způsob je ale velmi nebezpečný. Pokud by dokázal útočnı́k zı́skat
tento soubor, zı́ská tı́m zároveň i všechna hesla v otevřené podobě. Proto
musı́ být tato hesla uložena v zašifrované podobě.
Velmi vhodná pro tento účel je symetrická šifra AES. Platı́ dnes prakticky
za standard symetrického šifrovánı́. Je založena na algoritmu Rijndael.
Ten pracuje s bloky délky 128 bitů, tj. 16 bajtů. Nabı́zı́ se tedy omezit
maximálnı́ délku šifrovaného hesla na tuto hodnotu, aby stačilo pro jeho
zašifrovánı́ zpracovat pouze jeden blok. AES dovoluje pro šifrovánı́ použı́vat klı́če délky 128, 192 a 256 bitů. Protože šifrovaná data budou mı́t délku
128 bitů, budou mı́t tuto délku i klı́če.
34
3. NETRW
Heslo však bývá většinou kratšı́ (délka hesla se typicky pohybuje okolo 8
znaků, tedy 64 bitů). Je tedy nutné expandovat toto heslo na klı́č požadované
délky. K tomu sloužı́ expanznı́ funkce. Ty „roztáhnou“ heslo tak, že jeho
efektivnı́ délka se zvětšı́ na požadovaný počet bitů. Je důležité, aby expanznı́
funkce fungovala správně a neměla žádné slabiny, kterých by mohl útočnı́k
využı́t při pokusu o prolomenı́ klı́če (tj. slabiny, pomocı́ kterých je možno
snı́žit efektivnı́ délku takto vytvořeného klı́če).
Globálnı́ heslo, pomocı́ kterého se budou šifrovat ostatnı́, sdı́lená hesla,
musı́ být také nějak uloženo, aby bylo možné kontrolovat, zda uživatelem
zadané heslo je správné. Z výše uvedených důvodů nemůže být heslo uloženo v souboru přı́mo. Protože samotné heslo uživatel při každé komunikaci zadává ručně, pro kontrolu jeho správnosti postačı́, když bude uložena
pouze jeho hash. Pro jejı́ výpočet se bude použı́vat algoritmus SHA-1, který
je v dnešnı́ době považován za bezpečný. Hash bude uložena vždy na prvnı́m řádku souboru keys (samozřejmě pouze v přı́padě, že heslo již bylo
uživatelem zadáno).
Dalšı́ hodnotou, kterou je potřeba uložit v nějakém souboru, je jméno,
pod kterým bude klient vystupovat při komunikaci. Vytvářet kvůli němu
zvláštnı́ soubor by znamenalo zbytečnou režii (otevı́ránı́ a zavı́ránı́ souboru). Proto bude hodnota jména uložena taktéž v souboru keys. Bude
vždy v 1. řádku tohoto souboru. Jméno bude tvořit posloupnost znaků bez
mezer, která neobsahuje znak @. Při prvnı́m spuštěnı́ programu bude do
souboru uložen aktuálnı́ login uživatele a bude použı́ván jako jeho jméno
do té doby, než si své jméno uživatel nastavı́ sám.
Konečná podoba souboru keys tedy vypadá následovně:
jmeno hash(globální heslo)
jmenoB @strojB šifra(hesloAB ) port1
jmenoC @strojC šifra(hesloAC )
jmenoD @strojD šifra(hesloAD ) port2
..
.
3.4 Použité nástroje
Netrw bude použı́vat následujı́cı́ externı́ knihovny a nástroje:
• mhash [37] – Knihovna poskytujı́cı́ hashovacı́ funkce, autentizačnı́
kódy a funkce pro expanzi hesel na klı́če. Z této knihovny budou využity funkce implementujı́cı́ autentizačnı́ kódy založené na hashovacı́ch funkcı́ch SHA-1, SHA-256, RIPEMD-160 a TIGER-160. Dále bude
35
3. NETRW
využita funkce pro expanzi hesla na klı́č. Pro běh Netrw je nutné, aby
byla tato knihovna nainstalována v systému.
• AES [38] – Knihovna implementujı́cı́ algoritmus symetrického šifrovánı́. Zdrojové texty této knihovny jsou vloženy do zdrojových textů
Netrw, takže se tato knihovna nemusı́ instalovat do systému.
3.4.1 Ověřenı́ bezpečnosti funkce mhash keygen ext()
Pro expanzi hesla na klı́č je použita funkce mhash keygen ext() z knihovny mhash. Ta umı́ vytvářet klı́če z hesel několika různými způsoby.
Pro Netrw byla vybrána tzv. Simple String-to-key metoda, která je popsána
např. v [39] a je použı́vána v systému OpenPGP [40]. Pro vytvářenı́ klı́čů
použı́vá hashovacı́ funkci, kterou je možné si zvolit. Z hashovacı́ch funkcı́
podporovaných knihovnou mhash byla vybrána SHA-1, protože je v dnešnı́
době považována za bezpečnou a délka jı́ produkované hashe je pro klı́č
postačujı́cı́.
Pro jistotu byly provedeny testy, zda je implementace této expanznı́
funkce v knihovně mhash korektnı́ a zda se nepodařı́ v nı́ nalézt nějaká
slabá mı́sta.
Funkce by předevšı́m neměla mı́t žádné slabiny, kterých by mohl útočnı́k
zneužı́t při pokusu o snı́ženı́ efektivnı́ délky klı́če. Jaké vlastnosti by tedy
tato funkce měla mı́t?
Při malé změně zadávaného hesla (např. 1 nebo 2 bity) by měla nastat
velká změna ve vygenerovaném klı́či. Tj. pokud se napřı́klad zadajı́ dvě
hesla, která se mezi sebou lišı́ pouze v 1 bitu, výsledné klı́če by se měly mezi
sebou lišit průměrně o 64 bitů (při délce klı́čů 128 bitů).
Pro testovánı́ byl použit program Automated Password Generator [41],
který umı́ generovat náhodná hesla. Pomocı́ něj byl vygenerován 1 000 000
testovacı́ch hesel tak, aby splňovala základnı́ pravidla praktické použitelnosti:
• délka hesel je v rozmezı́ 8–10 znaků;
• byla použita velká a malá pı́smena, čı́slice, i nealfanumerické znaky;
• byla generována pouze tzv. pronounceable hesla – hesla, která se dajı́
vyslovit jako jedno slovo (nebo několik málo slov), a tudı́ž jsou lépe
zapamatovatelná.
Pro ukázku několik takto vygenerovaných hesel:
36
3. NETRW
RabcynRap9 Ghenshulf. myujNoc” cac{ojNi Lith?Wrod
Skolnoac2 failNuev3 guockRiar> (ovjanHowz eepDef7ot
K těmto heslům byly vypočı́tány jim odpovı́dajı́cı́ klı́če. Poté byla v heslech provedena náhodná změna o jeden bit. Změny, které transformovaly
původnı́ znaky na znaky, které nejsou tisknutelné, byly anulovány a byly
prováděny nové náhodné změny tak dlouho, dokud ordinálnı́ hodnota pozměněného znaku nebyla v požadovaném rozsahu. K takto transformovaným heslům se opět vypočı́taly přı́slušné klı́če. Tyto klı́če byly poté porovnány s klı́či přı́slušejı́cı́mi původnı́m heslům.
Průměrný počet bitových změn byl 63,997605. Nejmenšı́ počet změněných bitů byl 36, nejvyššı́ počet bitových změn byl 90.
Pokud se v hesle provedly dvě různé náhodné změny, přı́slušejı́cı́ klı́če
se lišily průměrně o 64,002008 bitů (nejméně 37, nejvı́ce 90 bitů).
Pokud se v hesle změnila celá polovina všech bitů, v rozdı́lech výsledných klı́čů se projevila změna průměrně o 63,999959 bitů (nejméně o 36,
nejvı́ce o 90 bitů).
Z pohledu počtu bitových změn klı́če v závislosti na bitových změnách
použitého hesla se tedy expanznı́ funkce mhash keygen ext() dá považovat za bezpečnou.
3.5 Parametry Netrw
netread a stejně tak i netwrite bude obsahovat všechny funkce a přepı́nače obsažené ve stávajı́cı́ verzi (1.2). Nově obsažené přepı́nače jsou následujı́cı́:
netread -a name@machine [-A mode]
[-i] [-m hmac] [-f] [port]
netread -n name@machine [port]
netread -d name@machine
netread -t machine
netread -s
netread -o name
netread -O
netread -g
Všechny výše vypsané přepı́nače akceptuje i netwrite. Následuje popis těchto přepı́načů:
• -a name@machine – Při spojenı́ s uživatelem označeným name na
počı́tači machine bude vyžadována oboustranná autentizace uživa37
3. NETRW
telů před začátkem přenosu. Po přenesenı́ dat bude provedena oboustranná autentizace těchto dat. Způsob autentizace lze změnit pomocı́
následujı́cı́ho (nepovinného) přepı́nače:
• -A mode – Při spojenı́ s druhou stranou bude, v závislosti na hodnotě
mode, použit následujı́cı́ způsob autentizace uživatelů před začátkem
přenosu dat a vlastnı́ch dat po dokončenı́ jejich přenosu:
-A none – zakáže jakoukoliv autentizaci;
-A allowed – nevyžaduje žádnou autentizaci, ale umožňuje
provést autentizaci druhé straně, pokud o autentizaci požádá;
-A you only – požaduje autentizaci druhé strany a od druhé
strany vyžaduje po přenosu dat jejich autentizačnı́ kód, ale zakazuje autentizaci sama sebe a zası́lánı́ vlastnı́ho MACu;
-A you – požaduje autentizaci druhé strany a autentizačnı́ kód
od druhé strany a umožňuje druhé straně ověřit svou autenticitu;
-A both – chová se stejně, jako by nebyl přepı́nač -A vůbec
použit, tj. požaduje oboustrannou autentizaci.
Nejbezpečnějšı́ je samozřejmě oboustranná autentizace uživatelů i dat.
Po provedenı́ autentizace uživatelů se nepřenášejı́ zbytečně data podvržená útočnı́kem. Po výměně autentizačnı́ch kódů má přı́jemce jistotu, že data jsou autentická a odesı́latel se zase ujistı́, že data obdržel
správný přı́jemce.
V následujı́cı́ tabulce je uvedeno, které autentizačnı́ módy jsou vzájemně kompatibilnı́.
none
allowed
you only
you
both
none
×
×
×
allowed
×
you only
×
×
×
×
you
×
×
×
both
×
×
×
×
• -i – Tento přepı́nač způsobı́, že budou ignorovány záznamy v souboru prev. Tak je možné komunikovat i s partnerem, který si pozměnil
čas na svém počı́tači směrem dozadu a kvůli záznamu předchozı́ komunikace je považován za útočnı́ka. Rovněž nenı́ prováděna kontrola
integrity autentizačnı́ch kódů u souborů prev a rand. Této volby by
mělo být použı́váno uvážlivě.
38
3. NETRW
• -m hmac alg – Určuje algoritmus, který bude použit při počı́tánı́
autentizačnı́ho kódu. Vybı́rat je možno mezi následujı́cı́mi autentizačnı́mi kódy: sha1, sha256, ripemd160 a tiger160. Standardně
je použit algoritmus sha1. Pokud se požadavky obou stran lišı́, je
použita volba požadovaná klientem netread.
• -f – Tato volba spouštı́ tzv. firewall mód, který způsobı́, že spojenı́
nenavazuje netwrite, ale netread.
• port – Tato položka určuje, na jakém portu bude navázáno spojenı́.
• -n name@machine – Přidá záznam o uživateli označeném name na
počı́tači machine do souboru keys. Uživatel je poté interaktivně dotázán na heslo pro komunikaci s tı́mto uživatelem, které se poté zašifruje (pomocı́ hesla globálnı́ho, na které je uživatel opět dotázán).
Pokud je zadán port, je čı́slo portu uloženo a bude použı́váno jako
výchozı́.
• -d name@machine – Odebere zadanou položku ze souboru keys.
• -t machine – Odebere ze souboru prev všechny záznamy přı́slušı́cı́ počı́tači machine. Tato volba sloužı́ pro přı́pad, kdy se na tomto
počı́tači změnı́ čas směrem zpět a z tohoto důvodu s nı́m klienti majı́cı́
uloženy soubory s předchozı́ komunikacı́ odmı́tajı́ ustanovit spojenı́
kvůli špatnému časovému údaji.
• -s – Tato volba vypı́še všechny položky ze souboru keys spolu s přı́padným výchozı́m portem.
• -o name – Nastavı́ jméno aktuálnı́ho uživatele, pod kterým bude
komunikovat s ostatnı́mi stranami a uložı́ ho do souboru keys.
• -O – Vypı́še nastavené jméno aktuálnı́ho uživatele uložené v souboru
keys.
• -g – Pomocı́ této volby se zadává hodnota globálnı́ho hesla. Pokud
bylo globálnı́ heslo zadáno již dřı́ve, je uživatel nejprve dotázán na
starou hodnotu. Poté zadá hodnotu nového globálnı́ho hesla (dvakrát,
pro potvrzenı́). Potom je nová hodnota hesla uložena v zahashované
podobě do souboru keys. Následně se provede překódovánı́ všech
položek v tomto souboru pomocı́ nového hesla. Zároveň se přepočı́tajı́
i autentizačnı́ kódy v souborech rand a prev.
39
3. NETRW
3.6 Implementace
Spojenı́ s druhou stranou navazuje standardně netwrite. Pouze pokud
je zapnut firewall mód, navazuje spojenı́ netread. Jak ale vypadá situace
dále, když je spojenı́ navázáno?
1. netread −→ netwrite : netrw control protocol
netread −→ netwrite : requested params: checksum
netread −→ netwrite : checksum: rmd160, md5, sha1
2. netwrite −→ netread : netrw control protocol
netwrite −→ netread : checksum: sha1
..
.
3. přenos dat
..
.
4. netwrite −→ netread : netrw control protocol
netwrite −→ netread : checksum(sha1):
c2f7ce0398c69a167b35e839ceb2084cc167eb57
5. netread −→ netwrite : netrw control protocol
netread −→ netwrite : checksum(sha1):
c2f7ce0398c69a167b35e839ceb2084cc167eb57
Obrázek 3.1: Komunikačnı́ protokol Netrw verze 1.2 (přı́klad).
Ve stávajı́cı́ verzi Netrw zası́lá jako prvnı́ svá pomocná data vždy netread. netwrite tato data zpracuje a zašle svou odpověd’. Proto bude i
protokol pro autentizaci koncipován tak, aby zachovával toto uspořádánı́.
Stávajı́cı́ způsob komunikace (resp. jeden jejı́ konkrétnı́ přı́pad) je zobrazen
na obrázku 3.1.
Komunikace je uvozena frázı́ netrw control protocol. Poté zašle
netread frázi requested params:, která uvozuje seznam parametrů,
jež netread požaduje od druhé strany. Dále jsou zaslány hodnoty parametrů, které netread posı́lá druhé straně. Odpověd’ druhé strany má stejnou
strukturu. Ve stávajı́cı́ podobě je do protokolu implementována pouze výměna informacı́ o tom, které hashovacı́ algoritmy má která strana k dispozici
a po skončenı́ přenosu dat se provede výměna hodnot hashı́.
Použitý protokol je navržen natolik obecně, že je možné jej v principu
využı́t dále a pouze do něj doplnit nové vlastnosti, tj. dohodu obou stran na
40
3. NETRW
použitém algoritmu pro výpočet autentizačnı́ho kódu, dohodu o způsobu
autentizace uživatelů před samotným přenosem dat a výměnu autentizačnı́ch kódů po skončenı́ přenosu dat.
1. netread −→ netwrite : netrw control protocol
netread −→ netwrite : auth type: you
netread −→ netwrite : hmac alg: sha1 sha256
ripemd160 tiger160
netread −→ netwrite : time: 1094834140.866685
netread −→ netwrite : rand: 15464947654308140132
netread −→ netwrite : name nw: host2.somewhere.net
netread −→ netwrite : name nr: host1.somewhere.net
2. netwrite −→ netread : netrw control protocol
3. Možná (několikanánobná) výměna nového náhodného čı́sla:
• netwrite −→ netread : requested params: rand
• netread −→ netwrite : rand: 10923986926823690823
4. netwrite −→ netread : auth type: allowed
netwrite −→ netread : hmac alg: sha1
netwrite −→ netread : time: 1094834141.258439
netwrite −→ netread : hmac:
ce02cceb2081673e8398edf655c569ab5fdcaf2b
Obrázek 3.2: Autentizačnı́ protokol – autentizace uživatelů (přı́klad).
Komunikace pomocı́ komunikačnı́ho protokolu pak bude vypadat podobně jako na obrázku 3.2. V tomto přı́padě netread požaduje autentizaci
druhé strany a umožňuje druhé straně svou autentizaci. netwrite autentizaci nepožaduje, pouze poskytuje svou.
Obě strany se domluvı́ na použitém algoritmu pro výpočet autentizačnı́ho kódu a vyměnı́ si potřebné informace jako aktuálnı́ čas, náhodné čı́slo
atd. Po obdrženı́ nevyhovujı́cı́ho náhodného čı́sla (tj. náhodného čı́sla použitého již při některé předchozı́ autentizaci) od komunikujı́cı́ho partnera
si může klient vyžádat (i několikrát po sobě) zaslánı́ nového náhodného
čı́sla. Poté se provede (jednostranné nebo vzájemné) zaslánı́ spočı́taného
autentizačnı́ho kódu. Pokud proběhne ověřenı́ zaslaných kódů bez chyby,
je možné přikročit k vlastnı́mu datovému přenosu. Po dokončenı́ přenosu
dat se provede jejich autentizace a informace o nı́ se opět přenesou pomocı́
41
3. NETRW
autentizačnı́ho protokolu.
Podrobný popis komunikačnı́ho protokolu (obsahujı́cı́ popis komunikace při autentizaci uživatelů i při autentizaci dat včetně popisu všech
zası́laných zpráv) je obsažen v přı́loze B.
3.7 Přı́klady použitı́ Netrw
V této části práce bude uvedeno několik typických přı́kladů použitı́ Netrw
s různými typy autentizace.
3.7.1 Přenos dat bez autentizace
Tento přı́klad ukazuje základnı́ použitı́ Netrw: přenos souboru z jednoho
počı́tače na druhý bez použitı́ autentizace uživatelů i dat. Pro přenos je použit port 50000. Tento způsob je možné použı́t jak na unixových systémech,
tak i na systémech Windows:
Netread:
netread 50000 >data.zip
Netwrite:
netwrite machine2.somewhere.net 50000 <data.zip
Spojenı́ standardně navazuje netwrite. Pokud je z nějakého důvodu
potřeba, aby spojenı́ navázal netread, použije se parametr -f:
Netread:
netread -f machine1.somewhere.net 50000 >data.zip
Netwrite:
netwrite -f 50000 <data.zip
Pokud je potřeba přenést vı́ce souborů najednou, je možné (pouze na
unixových systémech) použı́t program tar:
Netread:
netread 50000 | tar xf Netwrite:
tar cf - <soubory> | netwrite machine2.somewhere.net 50000
42
3. NETRW
3.7.2 Přenos dat za použitı́ autentizace
Před prvnı́m použitı́m autentizace musı́ každý uživatel nejdřı́ve nastavit
své globálnı́ heslo a přı́padně i své jméno. Poté může uložit do konfiguračnı́ho souboru údaje o svém komunikačnı́m partnerovi: jeho jméno, jméno
jeho stroje a přı́padně i port, na kterém bude standardně navazováno spojenı́. Zároveň s těmito údaji se do konfiguračnı́ho souboru uložı́ i heslo
pro prováděnı́ autentizace s tı́mto uživatelem. Heslo je zašifrované pomocı́
globálnı́ho hesla, takže později při prováděnı́ autentizace u kteréhokoliv
uživatele stačı́ zadávat pouze jedno globálnı́ heslo. Poté se již může provést
napřı́klad oboustranná autentizace uživatelů a dat:
Netread (Bob):
netread -g
netread -o bob
netread -n [email protected] 50000
netread -a [email protected] >data.zip
Netwrite (Alice):
netwrite -g
netwrite -o alice
netwrite -n [email protected] 50000
netwrite -a [email protected] <data.zip
Stejně jako v přı́padě bez použitı́ autentizace je možné použı́t firewall
mód:
Netread (Bob):
netread -a [email protected] -f >data.zip
Netwrite (Alice):
netwrite -a [email protected] -f <data.zip
Pokud chceme použı́t pro výpočet autentizačnı́ho kódu jiný algoritmus
než výchozı́ SHA-1, napřı́klad RIPEMD-160, provede se to takto (algoritmus
vybı́rá uživatel na straně netread):
Netread (Bob):
netread -a [email protected] -m ripemd160 >data.zip
Netwrite (Alice):
netwrite -a [email protected] <data.zip
Pokud Alice na straně odesı́latele požaduje Bobovu autentizaci a svou
autentizaci si přeje zakázat, dá se to zařı́dit takto:
43
3. NETRW
Netread (Bob):
netread -a [email protected] -A allowed >data.zip
Netwrite (Alice):
netwrite -a [email protected] -A you only <data.zip
I při použitı́ autentizace je samozřejmě možné přenést na unixových systémech vı́ce souborů (nebo i adresářů s jejich obsahem) za pomoci nástroje
tar:
Netread (Bob):
netread -a [email protected] | tar xf Netwrite (Alice):
tar cf - <soubory> | netwrite -a [email protected]
Poznámka. Pokud při testovánı́ autentizačnı́ch vlastnostı́ Netrw použije
uživatel pro spouštěnı́ netread i netwrite stejný účet na jednom počı́tači,
může se stát, že se oba programy „zaseknou“. Toto chovánı́ spočı́vá ve
výměně náhodných čı́sel. Jeden klient vygeneruje své náhodné čı́slo, zapı́še
jej do pomocného konfiguračnı́ho souboru rand a zašle druhé straně. Druhý
klient ovšem obdržené čı́slo porovnává s náhodnými čı́sly zapsanými ve
svém souboru rand. Pokud je ovšem tento soubor pro oba klienty společný,
přı́jemce vždy obdržené čı́slo v souboru nalezne, a tudı́ž bude stále od svého
partnera vyžadovat nová a nová náhodná čı́sla.
3.8 Testy rychlosti
Po doplněnı́ autentizace dat do Netrw se nabı́zı́ otázka, jakou časovou zátěž
autentizace dat během přenosu představuje. Proto byla provedena série
testů. Byla měřena doba přenosu datových segmentů různých velikostı́ na
různých systémech.
Nejprve byla testována rychlost bez použitı́ čtenı́ a zápisu na disk a bez
přenosu dat sı́tı́. Takto jsou rychlostnı́ rozdı́ly vidět nejlépe, rychlost ovlivňuje pouze výpočetnı́ výkon použitého systému. Na všech testovaných systémech nebyly během testovánı́ spuštěny žádné jiné aplikace (samozřejmě
kromě těch nezbytných pro běh systému). Při porovnávánı́ výsledků je
nutné si uvědomit, že při spouštěnı́ netread i netwrite na jednom stroji
je jeho procesor při počı́tánı́ kontrolnı́ch součtů či autentizačnı́ch kódů zatı́žen dvojnásobně oproti normálnı́m podmı́nkám, protože tyto výpočty provádı́ pro oba klienty zároveň a přenosová rychlost klesá zhruba na polovinu
oproti přı́padu, kdy jsou výpočty prováděny pouze pro jednoho klienta.
44
3. NETRW
3.8.1 Intel Celeron 900MHz
Přenos (zde možná lépe řečeno zpracovánı́) dat bez počı́tánı́ kontrolnı́ho
součtu pomocı́ Netrw-1.2 proběhl rychlostı́ přibližně 30 MB/s u všech
datových objemů. Zajı́mavé zjištěnı́ je, že u Netrw-2.0 je tato rychlost
o několik megabytů většı́, přestože pro přenos dat bez počı́tánı́ kontrolnı́ho
součtu a autentizačnı́ho kódu je použit prakticky totožný kód programu.
Použitı́ kontrolnı́ho součtu SHA-1 v Netrw-1.2 snižuje dosaženou rychlost
na zhruba 13 MB/s, což je necelá polovina rychlosti přenosu bez použitı́
kontrolnı́ho součtu. Počı́tánı́ jednostranného autentizačnı́ho kódu SHA-1
přenos zpomalilo asi o 1 MB/s, na přibližně 12 MB/s. U oboustranného
SHA-1 autentizačnı́ho kódu byla průměrná rychlost přenosu dat na úrovni
asi 6,5 MB/s. U jednostranného autentizačnı́ho kódu počı́taného pomocı́
algoritmu SHA-256 došlo k většı́m rozdı́lům u různých objemů dat: pro
100 MB a 200 MB byla rychlost mı́rně nad 5 MB/s, u 500 MB a 1000 MB byla
rychlost přenosu takřka 7 MB/s. U oboustranného SHA-256 autentizačnı́ho
kódu byla průměrná rychlost přenosu dat na úrovni necelých 4 MB/s.
Kompletnı́ grafy výše shrnutých měřenı́ jsou v přı́loze C.1.
3.8.2 AMD Duron 600MHz
U tohoto procesoru také nastal nepoměr mezi rychlostı́ přenosu dat bez
počı́tánı́ kontrolnı́ho součtu a autentizačnı́ho kódu mezi jednotlivými verzemi programu, ovšem v odlišném poměru oproti předchozı́mu přı́padu.
Netrw-1.2 přenesl data rychlostı́ zhruba 90 MB/s, Netrw-2.0 však pouze
rychlostı́ necelých 80 MB/s.
Při použitı́ kontrolnı́ho součtu SHA-1 klesla přenosová rychlost na přibližně 20 MB/s. U jednostranného autentizačnı́ho kódu SHA-1 přenosová
rychlost klesla na 14 MB/s. Přenos za použitı́ oboustranně počı́taného autentizačnı́ho kódu proběhl očekávanou rychlostı́ cca 7,5 MB/s. Rychlostı́
8 MB/s byla data přenesena za počı́tánı́ jednostranného autentizačnı́ho
kódu SHA-256. Když byl autentizačnı́ kód SHA-256 počı́tán oboustranně,
byla přenosová rychlost mı́rně nad hranicı́ 4 MB/s.
Kompletnı́ grafy výše shrnutých měřenı́ jsou v přı́loze C.2.
3.8.3 2× Pentium III 1 GHz
Přenos dat bez počı́tánı́ kontrolnı́ho součtu proběhl u tohoto dvouprocesorového stroje rychlostı́ přibližně 100 MB/s. Počı́tánı́ kontrolnı́ho součtu pomocı́ algoritmu SHA-1 snı́žilo rychlost přenosu na cca 35 MB/s. Netrw-2.0
bez počı́tánı́ autentizačnı́ho kódu přenesl data rychlostı́ necelých 120 MB/s.
45
3. NETRW
Při použitı́ jednostranného autentizačnı́ho kódu založeného na algoritmu
SHA-1 byla rychlost přenosu 30 MB/s, při použitı́ oboustranného autentizačnı́ho kódu 18 MB/s. Pokud byl použit autentizačnı́ kód SHA-256, přenos
s jednostrannou autentizacı́ proběhl rychlostı́ 19 MB/s, s oboustrannou autentizacı́ rychlostı́ 10 MB/s.
Kompletnı́ grafy výše shrnutých měřenı́ jsou v přı́loze C.3.
3.8.4 Intel Celeron 900MHz, AMD Duron 600MHz
Typické použitı́ Netrw ovšem spočı́vá v přenosu dat z pevného disku jednoho počı́tače na pevný disk počı́tače druhého. Testy přenosu dat mezi
dvěma počı́tači již tedy byly prováděny za použitı́ pevných disků. Při přenosu dat mezi dvěma linuxovými operačnı́mi systémy byla přenosová rychlost u všech datových objemů na úrovni 5 MB/s. Pokud byl přenosu účasten
operačnı́ systém Windows XP (at’již na jedné, druhé, nebo obou stranách),
klesla přenosová rychlost na 4 MB/s.
Kompletnı́ grafy výše shrnutých měřenı́ jsou v přı́loze C.4.
3.8.5 Shrnutı́ testů
Testy rychlosti ukazujı́, že i při použitı́ autentizace si systém Netrw zachoval
relativně vysokou přenosovou rychlost. U kontrolnı́ho součtu a autentizačnı́ho kódu počı́taného pomocı́ algoritmu SHA-1 se sice objevily rychlostnı́
rozdı́ly v neprospěch autentizačnı́ho kódu, tyto rozdı́ly ale nejsou nijak
dramatické a použitelnost programu nesnižujı́. Algoritmus autentizačnı́ho
kódu využı́vajı́cı́ hashovacı́ funkci SHA-256 snižuje rychlost přenosu znatelněji. Přesto zůstává přenosová rychlost na vysoce použitelné úrovni.
46
Kapitola 4
Závěr
Cı́lem práce bylo shrnout základnı́ principy a postupy při autentizaci dat
a do existujı́cı́ho systému pro přenos dat implementovat mechanismus pro
autentizaci uživatelů a dat.
V prvnı́ch dvou kapitolách jsem popsal obecné principy autentizace dat,
k čemu autentizace dat sloužı́ a jakými prostředky se autentizace dat provádı́. Rozebral jsem principy fungovánı́ hashovacı́ch funkcı́ včetně popisu
nejpoužı́vanějšı́ch algoritmů. Dále jsem obecně rozebral mechanismus digitálnı́ch podpisů, které plnı́ obdobnou funkci jako ručně psané podpisy, a
uvedl několik nejpoužı́vanějšı́ch schémat včetně jejich matematického pozadı́ a přı́kladů.
Digitálnı́ a ručně psané podpisy se však od sebe v několika aspektech
lišı́. Digitálnı́ podpis je neoddělitelně spjatý s podepisovanou zprávou a
nenı́ možné jej nějakým způsobem od zprávy oddělit a použı́t jej pro podpis
jiné zprávy. Podpis je ale možné ze zprávy odstranit tak, aby zpráva nebyla
podpisem „ušpiněna“. Naproti tomu u ručně psaného podpisu jeho použitı́
pro jinou zprávu možné je, napřı́klad odstraněnı́m původnı́ zprávy z papı́ru
a dopsánı́m zprávy nové. Pro důvěryhodné ověřenı́ správnosti digitálnı́ho
podpisu je většinou zapotřebı́ účasti nějaké třetı́ strany v podobě certifikačnı́
autority. Při použitı́ klasického podpisu postačı́ podpisový vzor. Důležité
je věnovat pozornost skutečnosti, že zatı́mco klasický ručnı́ podpis může
pořı́dit pouze člověk, podpis digitálnı́ může vytvořit prakticky kterýkoliv
počı́tač.
Do balı́ku Netrw, který sloužı́ pro rychlý přenos dat přes Internet, jsem
navrhl a implementoval mechanismus autentizace uživatelů a dat. Tento
mechanismus jsem se snažil navrhnout tak, aby byl bezpečný, ale zároveň co
nejjednoduššı́, flexibilnı́ a dal se dobře spravovat. Provedené testy ukazujı́,
že při použitı́ autentizace je přenosová rychlost jen o málo nižšı́, než při
prováděnı́ prostého kontrolnı́ho součtu. Vytčený cı́l zachovánı́ co nejvyššı́
přenosové rychlosti byl tedy splněn. Doufám, že balı́k Netrw obohacený
o autentizaci nalezne v praxi své uplatněnı́.
Oblast autentizace dat a vůbec celé kryptografie procházı́ bouřlivým vý47
4. ZÁVĚR
vojem. Nedávná prolomenı́ několika široce použı́vaných a rozšı́řených hashovacı́ch funkcı́ nás nutı́ klást si otázku, zda i jiné hashovacı́ funkce nejsou
v ohroženı́. Problémy, které jsou dnes pokládány za obtı́žně řešitelné, se mohou za pár let s nástupem nových generacı́ počı́tačů nebo aplikacı́ nových
poznatků stát řešitelnými. V oblasti kryptografie se máme do budoucna jistě
na co těšit.
48
Literatura
[1] Ústav pro jazyk český Akademie věd České republiky. Jazyková poradna Ústavu pro jazyk český AV ČR. http://www.ujc.cas.cz/
oddeleni/index.php?page=poradna.
[2] Alfred J. Menezes, Paul C. van Oorschot, Scott A. Vanstone. Handbook
of Applied Cryptography. CRC Press, 1996. http://www.cacr.math.
uwaterloo.ca/hac/.
[3] B. Preneel, K. U. Leuven. The Davies-Meyer Hash Function. Květen 2004.
http://www.win.tue.nl/˜henkvt/davies-meyerv1.pdf.
[4] B. Preneel, K. U. Leuven. Hash Functions. Květen 2004. http://www.
win.tue.nl/˜henkvt/hashv4.pdf.
[5] B. Preneel, K. U. Leuven. MDC-2 and MDC-4. Řı́jen 2004. http:
//www.win.tue.nl/˜henkvt/mdc2-4v2.pdf.
[6] National Institute of Standards and Technology. Data Encryption Standard (DES). Řı́jen 1999. http://csrc.nist.gov/publications/
fips/fips46-3/fips46-3.pdf.
[7] R. Rivest. The MD4 Message-Digest Algorithm. RFC 1320. Duben 1992.
http://www.ietf.org/rfc/rfc1320.txt.
[8] R. Rivest. The MD5 Message-Digest Algorithm. RFC 1321. Duben 1992.
http://www.ietf.org/rfc/rfc1321.txt.
[9] Xiaoyun Wang, Dengguo Feng, Xuejia Lai, Hongbo Yu. Collisions for
Hash Functions MD4, MD5, HAVAL-128 and RIPEMD. Srpen 2004.
http://eprint.iacr.org/2004/199.pdf.
[10] D. Eastlake, P. Jones. US Secure Hash Algorithm 1 (SHA1). RFC 3174.
Zářı́ 2001. http://www.ietf.org/rfc/rfc3174.txt.
[11] National Institute of Standards and Technology. Digital Signature Standard (DSS). Květen 1994. http://www.itl.nist.gov/fipspubs/
fip186.htm.
49
LITERATURA
[12] A. Bosselaers. The hash function RIPEMD-160. Srpen 2004. http:
//www.esat.kuleuven.ac.be/˜bosselae/ripemd160.html.
[13] National Institute of Standards and Technology. Secure Hash Standard. Srpen 2002. http://csrc.nist.gov/publications/
fips/fips180-2/fips180-2.pdf.
[14] National Institute of Standards and Technology. Advanced Encryption Standard (AES). Prosinec 2001. http://csrc.nist.gov/
CryptoToolkit/aes/.
[15] B. Preneel, K. U. Leuven. The MASH Hash Functions (Modular Arithmetic
Secure Hash). Květen 2004. http://www.win.tue.nl/˜henkvt/
mashv1.pdf.
[16] National Institute of Standards and Technology.
Cyclic redundancy check. Květen 2002. http://www.nist.gov/dads/HTML/
cyclicRedundancyCheck.html.
[17] National Institute of Standards and Technology. DES Modes of Operation. Prosinec 1980. http://www.itl.nist.gov/fipspubs/
fip81.htm.
[18] H. Krawczyk, M. Bellare, R. Canetti. HMAC: Keyed-Hashing for Message
Authentication. RFC 2104. Únor 1997. http://www.ietf.org/rfc/
rfc2104.txt.
[19] B. Preneel, V. Rijmen, P. C. van Oorschot. Security Analysis of the
Message Authenticator Algorithm (MAA). Duben 1997. http://www.
scs.carleton.ca/˜paulv/papers/MAA-ETT.pdf.
[20] B. Preneel, P. C. van Oorschot.
MDx-MAC and Building Fast MACs from Hash Functions.
Srpen 1995.
http:
//citeseer.ist.psu.edu/rd/44619770%2C159901%2C1%
2C0%2CDownload/ftp%3AqSqqSqftp.esat.kuleuven.ac.
beqSqpubqSqCOSICqSqpreneelqSqmdxmac_crypto95.ps.gz.
[21] B. Kaliski, J. Staddon. RSA Cryptography Specifications Version 2.0.
RFC 2437. Řı́jen 1998. http://www.ietf.org/rfc/rfc2437.txt.
[22] Y. Tsiounis, M. Yung. On the Security of ElGamal based Encryption.
Únor 1998. http://www.ccs.neu.edu/home/yiannis/papers/
eg.ps.
50
LITERATURA
[23] National Institute of Standards and Technology. http://www.nist.
gov/.
[24] U. Feige, A. Fiat, A. Shamir. Zero Knowledge Proofs of Indentity. 1987.
http://portal.acm.org/ft_gateway.cfm?id=28419&type=
pdf&coll=GUIDE&dl=GUIDE&CFID=29827796&CFTOKEN=
17015179.
[25] J. Denemark.
netrw/.
Netrw.
http://www.fi.muni.cz/˜xdenemar/
[26] The Linux Homepage at Linux Online. http://www.linux.org/.
[27]
Solaris Operating System.
solaris/.
http://wwws.sun.com/software/
[28] IRIX. http://www.sgi.com/products/software/irix/.
[29] OpenBSD. http://www.openbsd.org/.
[30] Microsoft Corporation. http://www.microsoft.com/.
[31] The GNU Project. GNU General Public License. http://www.gnu.
org/copyleft/gpl.html.
[32] Information Sciences Institute, University of Southern California.
Transmission Control Protocol. RFC 793. Zářı́ 1981. http://www.ietf.
org/rfc/rfc793.txt.
[33] J. Postel. User Datagram Protocol. RFC 768. Srpen 1980. http://www.
ietf.org/rfc/rfc768.txt.
[34] WinZip HomePage. http://www.winzip.com/.
[35] WinRAR archiver, a powerfull tool to process RAR and ZIP files. http:
//www.rarlab.com/.
[36] SSH Communications Security. http://www.ssh.com/.
[37] Mhash. http://mhash.sourceforge.net/.
[38]
Implementations of AES (Rijndael) in C/C++ and Assembler. Červen 2003.
http://fp.gladman.plus.com/cryptography_
technology/rijndael/.
51
LITERATURA
[39] J. Callas, L. Donnerhacke, H. Finney, R. Thayer. OpenPGP Message
Format. RFC 2440. Listopad 1998. http://www.ietf.org/rfc/
rfc2440.txt.
[40] The OpenPGP Alliance HomePage. http://www.openpgp.org/.
[41] Automated Password Generator (APG). http://www.adel.nursat.
kz/apg/.
[42]
Linux From Scratch.
index.html.
http://www.linuxfromscratch.org/
[43] Mandrakelinux. http://www.mandrakelinux.com/.
[44] Source Mage GNU/Linux. http://www.sourcemage.org/.
Všechny výše uvedené Internetové odkazy byly naposledy kontrolovány v prosinci 2004.
52
Přı́loha A
Hashovacı́ funkce
A.1 Hashovacı́ funkce Matyas-Meyer-Oseas
Vstup: Data x (bráno jako posloupnost bitů).
Výstup: nbitová hash dat x.
1. Vstupnı́ data rozděl na bloky délky n. Poslednı́ blok přı́padně doplň na patřičnou délku (padding). Vzniknou tak bloky x1 , x2 , . . . , xt . Naplň iniciálnı́ nbitovou
hodnotu IV.
2. H0 = IV .
3. Hi = Eg(Hi −1) (xi ) ⊕ xi , 1 ≤ i ≤ t, kde zápis „Ek (x)“ značı́ symetrickou blokovou
šifru použı́vajı́cı́ klı́č k, aplikovanou na parametr x, ⊕ znamená exkluzivnı́ bitový
součet (XOR) a g je funkce upravujı́cı́ hash předchozı́ho bloku do podoby vhodné
pro E.
4. Výsledná hash = Ht .
53
A. HASHOVACÍ FUNKCE
A.2 Hashovacı́ funkce MD5
Vstup: Řetězec bitů x libovolné délky b ≥ 0.
Výstup: 128bitová hash řetězce x.
1. Definice konstant. Definuj čtyři 32bitové řetězcové hodnoty: h1 = 0x67452301,
h2 = 0xef cdab89, h3 = 0x98badcf e, h4 = 0x10325476.
Dále definuj 32bitové sčı́tacı́ konstanty:
y[j] = 0, 0 ≤ j ≤ 15;
y[j] = prvnı́ch 32 bitů z binárnı́ho zápisu výrazu abs(sin(j + 1)), 0 ≤ j ≤ 63, kde
j je bráno jako hodnota v radiánech a abs značı́ absolutnı́ hodnotu.
Definuj pořadı́ pro přı́stup ke zdrojovým slovům:
z[0..15] = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15],
z[16..31] = [1, 6, 11, 0, 5, 10, 15, 4, 9, 14, 3, 8, 13, 2, 7, 12],
z[32..47] = [5, 8, 11, 14, 1, 4, 7, 10, 13, 0, 3, 6, 9, 12, 15, 2],
z[48..63] = [0, 7, 14, 5, 12, 3, 10, 1, 8, 15, 6, 13, 4, 11, 2, 9].
Definuj počet bitových pozic pro rotace:
s[0..15] = [3, 7, 11, 19, 3, 7, 11, 19, 3, 7, 11, 19, 3, 7, 11, 19],
s[16..31] = [3, 5, 9, 13, 3, 5, 9, 13, 3, 5, 9, 13, 3, 5, 9, 13],
s[32..47] = [3, 9, 11, 15, 3, 9, 11, 15, 3, 9, 11, 15, 3, 9, 11, 15],
s[48..63] = [6, 10, 15, 21, 6, 10, 15, 21, 6, 10, 5, 21, 6, 10, 15, 21].
2. Předvýpočet. Doplň x tak, aby jeho délka byla násobkem 512 následovně: Na konec x přidej jeden bit s hodnotou 1. Za tento bit přidej r − 1 bitů s hodnotou 0,
kde r je nejmenšı́ takové čı́slo, pro které platı́, že délka takto vzniklého řetězce
je o 64 bitů menšı́ než násobek 512. Nakonec data doplň 64bitovou reprezentacı́
čı́sla b mod 264 branou jako 2 32bitová slova s méně významným slovem jako prvnı́m. Označ m jako počet 512bitových bloků upravených dat. Výsledný doplněný
řetězec má tedy délku b + r + 64 = 512m = 32 · 16m. Data se pro dalšı́ průběh algoritmu rozdělı́ na 16m 32bitových slov: x0 , x1 , · · · , x16m−1 . Dále inicializuj vektor
(H1 , H2 , H3 , H4 ) = (h1 , h2 , h3 , h4 ).
54
A. HASHOVACÍ FUNKCE
3. Výpočet. Pro všechna i od 0 do m − 1 zkopı́ruj i-tý blok z 16 32bitových slov do
přechodného úložiště: X[j] = x16i+j , 0 ≤ j ≤ 15 a proved’ následujı́cı́ kroky:
Inicializace: Inicializuj vektor pracovnı́ch proměnných: (A, B, C, D)
(H1 , H2 , H3 , H4 ).
=
Prvnı́ cyklus: Pro j od 0 do 15 dělej:
t = A + ((B ∧ C) ∨ (B ∧ D)) + X[z[j]] + y[j],
(A, B, C, D) = (D, B + t ←- s[j], B, C),
kde použité operátory majı́ následujı́cı́ význam:
+ . . . sčı́tánı́ modulo 232 ,
∧ . . . bitový logický součin (AND),
∨ . . . bitový logický součet (OR),
A . . . bitová inverze A,
t ←- s . . . rotace t doleva o s pozicı́.
Druhý cyklus: Pro j od 16 do 31 dělej:
t = A + ((B ∧ C) ∨ (B ∧ D) ∨ (C ∧ D)) + X[z[j]] + y[j],
(A, B, C, D) = (D, B + t ←- s[j], B, C).
Třetı́ cyklus: Pro j od 32 do 47 dělej:
t = A + (B ⊕ C ⊕ D) + X[z[j]] + y[j],
(A, B, C, D) = (D, B + t ←- s[j], B, C),
kde ⊕ značı́ exkluzivnı́ bitový součet (XOR).
Čtvrtý cyklus: Pro j od 48 do 63 dělej:
t = A + (C ⊕ (B ∨ D) + X[z[j]] + y[j]),
(A, B, C, D) = (D, B + t ←- s[j], B, C).
Upravenı́ hodnot řetězcových proměnných: (H1 , H2 , H3 , H4 ) = (H1 + A, H2 +
B, H3 + C, H4 + D).
4. Výsledek. Výsledná hash vznikne zřetězenı́m H1 až H4 : H = H1 k H2 k H3 k H4 ,
kde Hi je zapisováno s nejméně významným bitem jako prvnı́m.
55
A. HASHOVACÍ FUNKCE
A.3 Hashovacı́ funkce SHA-1
Vstup: Řetězec bitů x libovolné délky b ≥ 0.
Výstup: 160bitová hash řetězce x.
1. Definice konstant. Definuj pět 32bitových řetězcových hodnot:
h1 = 0x67452301, h2 = 0xef cdab89, h3 = 0x98badcf e, h4 = 0x10325476, h5 =
0xc3d2e1f 0.
Dále definuj čtyři 32bitové sčı́tacı́ konstanty:
y1 = 0x5a827999, y2 = 0x6ed9eba1, y3 = 0x8f lbbcdc, y4 = 0xca62c1d6.
2. Předvýpočet. Proved’ padding stejně jako u algoritmu MD5 s tı́m rozdı́lem, že poslednı́ dvě 32bitová slova udávajı́cı́ délku původnı́ch dat, jsou v opačném pořadı́.
Stejně jako u MD5 data pro dalšı́ průběh algoritmu rozděl na 16m 32bitových slov:
x0 , x1 , · · · , x16m−1 . Dále inicializuj vektor
(H1 , H2 , H3 , H4 , H5 ) = (h1 , h2 , h3 , h4 , h5 ).
56
A. HASHOVACÍ FUNKCE
3. Výpočet. Pro všechna i od 0 do m − 1 zkopı́ruj i-tý blok z 16 32bitových slov do
přechodného úložiště: X[j] = x16i+j , 0 ≤ j ≤ 15 a proved’ následujı́cı́ kroky:
pro j od 16 do 79 dělej:
X[j] = ((X[j − 3] ⊕ X[j − 8] ⊕ X[j − 14] ⊕ X[j − 16]) ←- 1).
Inicializace: Inicializuj vektor pracovnı́ch proměnných:
(A, B, C, D, E) = (H1 , H2 , H3 , H4 , H5 ).
Prvnı́ cyklus: Pro j od 0 do 19 dělej:
t = (A ←- 5) + ((B ∧ C) ∨ (B ∧ D)) + E + X[j] + y1 ,
(A, B, C, D, E) = (t, A, B ←- 30, C, D).
Druhý cyklus: Pro j od 20 do 39 dělej:
t = (A ←- 5) + (B ⊕ C ⊕ D) + E + X[j] + y2 ,
(A, B, C, D, E) = (t, A, B ←- 30, C, D).
Třetı́ cyklus: Pro j od 40 do 59 dělej:
t = (A ←- 5) + ((B ∧ C) ∨ (B ∧ D) ∨ (C ∧ D)) + E + X[j] + y3 ,
(A, B, C, D, E) = (t, A, B ←- 30, C, D).
Čtvrtý cyklus: Pro j od 60 do 79 dělej:
t = (A ←- 5) + (B ⊕ C ⊕ D) + E + X[j] + y4 ,
(A, B, C, D, E) = (t, A, B ←- 30, C, D).
Upravenı́ hodnot řetězcových proměnných: (H1 , H2 , H3 , H4 , H5 ) = (H1 +
A, H2 + B, H3 + C, H4 + D, H5 + E).
Označenı́ operátorů je zde stejné, jako u hashovacı́ funkce MD5.
4. Výsledek. Výsledná hodnota hashe je H1 k H2 k H3 k H4 k H5 .
57
A. HASHOVACÍ FUNKCE
A.4 Algoritmus CBC-MAC
Vstup: Vstupnı́ data x, specifikace použité blokové šifry E, tajný klı́č k pro blokovou šifru
E; v přı́padě použitı́ kroku 3: druhý tajný klı́č k0 6= k.
Výstup: nbitový autentizačnı́ kód (MAC) zı́skaný z dat x, kde n je délka bloku E.
1. Doplněnı́ a rozdělenı́ do bloků. Pokud je potřeba, doplň x tak, aby jeho délka
byla celočı́selným násobkem délky bloku (za data připoj jeden bit s hodnotou 1
a poté potřebný počet bitů s hodnotou 0). Rozděl takto doplněná data na bloky
x1 , . . . , xt .
2. Výpočet. Necht’Ek je bloková šifra E použı́vajı́cı́ tajný klı́č k. Potom se výsledný
autentizačnı́ kód Ht zı́ská následujı́cı́m iterativnı́m postupem:
H1 = Ek (x1 ),
Hi = Ek (Hi−1 ⊕ xi ), 2 ≤ i ≤ t.
0
3. Zvýšenı́ bezpečnosti (nepovinný krok). Ht0 = Ek−1
0 (Ht ), Ht = Ek (Ht ).
4. Výsledek. Výsledná hodnota autentizačnı́ho kódu je Ht .
58
A. HASHOVACÍ FUNKCE
A.5 Algoritmus MAA
Vstup: Data x délky 32j, 1 ≤ j ≤ 106 ; 64bitový klı́č Z = Z[1] . . . Z[8].
Výstup: 32bitový autentizačnı́ kód (MAC) zı́skaný z dat x a klı́če Z.
1. Úprava klı́če (nezávislá na x). Expanduj klı́č Z do šesti 32bitových částı́ X, Y
(iniciálnı́ hodnoty), V , W (proměnné hlavnı́ho cyklu algoritmu) a S, T (připojı́ se
později na konec x) následovně:
1.1 Nahrad’ všechny bajty 0x00 a 0xff v Z následovně:
P = 0;
pro i od 1 do 8 dělej:
P = 2P ;
pokud je Z[i] rovno 0x00 nebo 0xff, pak P = P + 1, Z[i] = Z[i] ∨ P .
1.2 Do J přiřad’ prvnı́ 4 bajty Z, do K zase poslednı́ 4 bajty Z.
X = J 4 mod (232 − 1) ⊕ J 4 mod (232 − 2),
Y = [K 5 mod (232 − 1) ⊕ K 5 mod (232 − 2)](1 + P )2 mod (232 − 2),
V = J 6 mod (232 − 1) ⊕ J 6 mod (232 − 2),
W = K 7 mod (232 − 1) ⊕ K 7 mod (232 − 2),
S = J 8 mod (232 − 1) ⊕ J 8 mod (232 − 2),
T = K 9 mod (232 − 1) ⊕ K 9 mod (232 − 2).
1.3 Zpracuj vzniklé dvojice (X, Y ), (V, W ), (S, T ) tak, aby neobsahovaly bajty
0x00 nebo 0xff (stejným postupem jako v bodě 1.2 pro Z). Dále definuj 4
AND-OR konstanty A = 0x02040801, B = 0x00804021, C = 0xbf ef 7f df
D = 0x7df ef bf f .
2. Předvýpočet. Inicializuj rotačnı́ vektor: v = V a řetězcové proměnné H1 = X a
H2 = Y . Na konec x připoj S a T . Výsledná data nynı́ tvořı́ t 32bitových bloků
x1 , · · · , xt , kde poslednı́ dva bloky jsou právě S a T .
3. Zpracovánı́ bloků. Pro každý blok xi (pro i od 1 do t) dělej:
v = (v ←- 1), U = (v ⊕ W ),
t1 = (H1 ⊕ xi ) ×1 (((H2 ⊕ xi ) + U ) ∨ A) ∧ C),
t2 = (H2 ⊕ xi ) ×2 (((H1 ⊕ xi ) + U ) ∨ B) ∧ D),
H 1 = t1 , H 2 = t2 .
Operátor ×i značı́ speciálnı́ násobenı́ mod (232 − i), i = 1, 2.
4. Výsledek. Výsledný autentizačnı́ kód je H = H1 ⊕ H2 .
59
A. HASHOVACÍ FUNKCE
A.6 Yuvalův narozeninový útok
Vstup: Původnı́ data x1 , útočnı́kova data x2 , nbitová hashovacı́ funkce h.
Výstup: x01 a x02 , které vznikly drobnými úpravami x1 a x2 a pro které platı́: h(x01 ) = h(x02 ).
1. Vygeneruj t = 2n/2 různých x01 , které jsou drobnými modifikacemi x1 .
2. Každé modifikované x01 zahashuj pomocı́ h a tuto hash společně s patřičným x01
ulož v takové podobě, aby bylo možné později v těchto dvojicı́ch vyhledávat podle
hodnoty hashe.
3. K x2 postupně generuj drobné modifikace x02 . Ke každému x02 spočı́tej hash h(x02 )
a zjisti, zda hash nenı́ shodná s nějakou hashı́ h(x01 ). Pokud ne, bod 3 opakuj tak
dlouho, dokud na shodu nenarazı́š. Pokud ano, předej na výstup aktuálnı́ x01 a x02 .
Platı́ pro ně h(x01 ) = h(x02 ).
60
Přı́loha B
Netrw – komunikačnı́ protokol
B.1 Použı́vané zprávy
V této části přı́lohy jsou popsány všechny zprávy, které jsou použı́vány
v komunikačnı́m protokolu pro autentizaci uživatelů a dat. Každá zpráva
začı́ná svým jménem. Poté následuje dvojtečka a mezera. Pak již následuje
obsah zprávy. Ten většinou tvořı́ jedno slovo (řetězec), přı́padně několik
slov oddělených mezerami. Zprávy, které Netrw v autentizačnı́ části použı́vá, jsou uvedeny v následujı́cı́m seznamu, zároveň i se vzorovými obsahy
zpráv:
• auth type: both
Určuje typ autentizace, kterou chce klient použı́vat.
• hmac alg: sha1 sha256 ripemd160 tiger160
Určuje, které algoritmy je možné použı́t pro výpočet autentizačnı́ho
kódu. Algoritmy jsou seřazené podle priority, preferované jsou ty na
začátku seznamu.
• time: 1094834140.866685
Aktuálnı́ čas odesı́latele zprávy.
• rand: 15464947654308140132
Náhodné čı́slo odesı́latele zprávy.
• name nr: host1.somewhere.net
Jméno stroje, kde je spuštěn netread.
• name nw: host2.somewhere.net
Jméno stroje, kde je spuštěn netwrite.
• hmac: 8dbf4855323191db403cf8166ba828709e636f1e
Hodnota autentizačnı́ho kódu.
61
B. NETRW – KOMUNIKAČNÍ PROTOKOL
• error: Buddy says: Wrong hmac obtained!
User authentication failed!
Pokud na jedné straně přenosu nastane nějaká fatálnı́ chyba, o které
by se měl dozvědět i partner na druhé straně (napřı́klad chyba při
autentizaci), zašle se tato zpráva. Klient na druhé straně spojenı́ pak
tuto chybovou zprávu vypı́še na výstup a ukončı́ se.
• requested params: rand
Pokud jedné straně nevyhovuje obdržené náhodné čı́slo svého komunikačnı́ho partnera, může si pomocı́ této zprávy zažádat o čı́slo jiné.
Tato žádost se může opakovat tak dlouho, dokud nenı́ náhodné čı́slo
v pořádku.
Zası́lánı́ svých zpráv ukončuje odesı́latel zaslánı́m prázdného řetězce.
62
B. NETRW – KOMUNIKAČNÍ PROTOKOL
B.2 Komunikace
Pokud si oba klienti přejı́ provést přenos dat bez autentizace, vypadá jejich
komunikace jednoduše:
1. netread −→ netwrite : netrw control protocol
netread −→ netwrite : auth type: none
2. netwrite −→ netread : netrw control protocol
netwrite −→ netread : auth type: none
Podobně jednoduchá je situace, kdy má jeden klient autentizaci povolenou, ale druhý ji nevyžaduje:
1. netread −→ netwrite : netrw control protocol
netread −→ netwrite : auth type: none
2. netwrite −→ netread : netrw control protocol
netwrite −→ netread : auth type: allowed
1. netread −→ netwrite : netrw control protocol
netread −→ netwrite : auth type: allowed
netread −→ netwrite : hmac alg: sha1 sha256 ripemd160 tiger160
2. netwrite −→ netread : netrw control protocol
netwrite −→ netread : auth type: none
1. netread −→ netwrite : netrw control protocol
netread −→ netwrite : auth type: allowed
netread −→ netwrite : hmac alg: sha1 sha256 ripemd160 tiger160
2. netwrite −→ netread : netrw control protocol
netwrite −→ netread : auth type: allowed
63
B. NETRW – KOMUNIKAČNÍ PROTOKOL
Pokud jedna strana autentizaci vyžaduje a druhá ji povoluje, vypadá
jejich komunikace takto (v závislosti na tom, zda netread autentizaci povoluje nebo naopak vyžaduje):
1. netread −→ netwrite : netrw control protocol
netread −→ netwrite : auth type: allowed
netread −→ netwrite : hmac alg: sha1 sha256 ripemd160 tiger160
2. netwrite −→ netread : netrw control protocol
netwrite −→ netread : auth type: you only nebo you
netwrite −→ netread : hmac alg: sha1
netwrite −→ netread : time: 1094834140.866685
netwrite −→ netread : rand: 15464947654308140132
netwrite −→ netread : name nw: host1.somewhere.net
netwrite −→ netread : name nr: host2.somewhere.net
3. Možná (několikanásobná) výměna nového náhodného čı́sla:
• netread −→ netwrite : requested params: rand
• netwrite −→ netread : rand: 10923986926823690823
4. netwrite −→ netread : time: 1094834141.239482
netwrite −→ netread : hmac:
3bbc089a516cd5c9b8871a95d207bb5d6fe7d60f
1. netread −→ netwrite : netrw control protocol
netread −→ netwrite : auth type: you only nebo you
netread −→ netwrite : hmac alg: sha1 sha256 ripemd160 tiger160
netread −→ netwrite : time: 1094834140.866685
netread −→ netwrite : rand: 15464947654308140132
netread −→ netwrite : name nw: host2.somewhere.net
netread −→ netwrite : name nr: host1.somewhere.net
2. netwrite −→ netread : netrw control protocol
netwrite −→ netread : auth type: allowed
3. Možná (několikanásobná) výměna nového náhodného čı́sla:
• netwrite −→ netread : requested params: rand
• netread −→ netwrite : rand: 10923986926823690823
4. netwrite −→ netread : hmac alg: sha1
netwrite −→ netread : time: 1094834141.258439
netwrite −→ netread : hmac:
ce02cceb2081673e8398edf655c569ab5fdcaf2b
64
B. NETRW – KOMUNIKAČNÍ PROTOKOL
Následovně vypadá komunikace, pokud požadujı́ autentizaci obě strany
(vzájemně kompatibilnı́ jsou pouze autentizačnı́ módy both–both a you–
you; nenı́ možné použı́t na jedné straně mód you a na druhé both):
1. netread −→ netwrite : netrw control protocol
netread −→ netwrite : auth type: both nebo you
netread −→ netwrite : hmac alg: sha1 sha256 ripemd160 tiger160
netread −→ netwrite : time: 1094834140.866685
netread −→ netwrite : rand: 15464947654308140132
netread −→ netwrite : name nw: host2.somewhere.net
netread −→ netwrite : name nr: host1.somewhere.net
2. netwrite −→ netread : netrw control protocol
netwrite −→ netread : auth type: both nebo you
3. Možná (několikanásobná) výměna nového náhodného čı́sla:
• netwrite −→ netread : requested params: rand
• netread −→ netwrite : rand: 10923986926823690823
4. netwrite −→ netread : hmac alg: sha1
netwrite −→ netread : time: 1094834141.258439
netwrite −→ netread : rand: 13980349850394538972
netwrite −→ netread : name nr: host1.somewhere.net
netwrite −→ netread : name nw: host2.somewhere.net
netwrite −→ netread : hmac:
ce02cceb2081673e8398edf655c569ab5fdcaf2b
5. Možná (několikanásobná) výměna nového náhodného čı́sla:
• netread −→ netwrite : requested params: rand
• netwrite −→ netread : rand: 9034809348509384537
6. netread −→ netwrite : hmac:
ce02cceb2081673e8398edf655c569ab5fdcaf2b
65
B. NETRW – KOMUNIKAČNÍ PROTOKOL
Ještě zbývá popsat podobu protokolu při autentizaci dat. Protože se
jedná o stále stejné TCP spojenı́ jako při autentizaci uživatelů a hodnoty náhodných čı́sel a časových údajů použitých při autentizaci uživatelů nebyly
v žádné předchozı́ komunikaci použity pro autentizaci dat, je možné je zde
použı́t. Protokol pak vypadá (v závislosti na tom, zda se jedná o jednostrannou nebo oboustrannou autentizaci dat) následovně.
Jednostranná autentizace dat, autentizačnı́ kód vyžaduje netwrite:
1. netread −→ netwrite : hmac:
0654043ce3e04a1bb18a7b982648afc82d35753b
Jednostranná autentizace dat, autentizačnı́ kód vyžaduje netread:
1. netwrite −→ netread : hmac:
0654043ce3e04a1bb18a7b982648afc82d35753b
Oboustranná autentizace dat:
1. netread −→ netwrite : hmac:
0654043ce3e04a1bb18a7b982648afc82d35753b
2. netread −→ netwrite : hmac:
f128cd285824ad5e2e1a3abe0e622059b52f7c85
66
Přı́loha C
Testy rychlosti přenosu dat
V následujı́cı́ch podkapitolách jsou obsaženy výsledky jednotlivých sériı́
rychlostnı́ch testů. Ve všech testech bylo přenášeno několik různě velikých
datových objemů: 100 MB, 200 MB, 500 MB a 1000 MB. Rychlost přenosu
byla testována v následujı́cı́ch režimech a verzı́ch programu (verze 1.2 je
původnı́ verze programu, verze 2.0 je nová verze obsahujı́cı́ autentizaci
dat):
• Netrw-1.2 bez počı́tánı́ kontrolnı́ho součtu.
• Netrw-1.2 s počı́tánı́m kontrolnı́ho součtu pomocı́ algoritmu SHA-1.
• Netrw-2.0 bez počı́tánı́ autentizačnı́ho kódu.
• Netrw-2.0 s jednostranným počı́tánı́m autentizačnı́ho kódu pomocı́
algoritmu SHA-1.
• Netrw-2.0 s oboustranným počı́tánı́m autentizačnı́ho kódu pomocı́
algoritmu SHA-1.
• Netrw-2.0 s jednostranným počı́tánı́m autentizačnı́ho kódu pomocı́
algoritmu SHA-256.
• Netrw-2.0 s oboustranným počı́tánı́m autentizačnı́ho kódu pomocı́
algoritmu SHA-256.
Výsledky měřenı́ jsou zobrazeny v grafech. Na vodorovných osách je
zobrazeno množstvı́ přenášených dat, na svislých osách je zobrazena rychlost přenosu těchto dat v MB/s.
Každý test byl v zájmu co největšı́ přesnosti měřenı́ prováděn pětkrát
po sobě. Výsledné hodnoty v jednotlivých sloupcı́ch grafů jsou pak aritmetickým průměrem těchto pěti měřenı́.
67
C. TESTY RYCHLOSTI PŘENOSU DAT
C.1 Intel Celeron 900 MHz
Procesor:
Intel Celeron 800 MHz, přetaktován na 900 MHz
Pamět’:
192 MB
Základnı́ deska: Via Apollo Pro 133T, 100 MHz
Operačnı́ Systém: Linux (LFS [42])
Způsob přenosu: Ze zařı́zenı́ /dev/zero do zařı́zenı́ /dev/null
Netrw 1.2, bez počítání kontrolního součtu
Netrw 1.2, kontrolní součet SHA-1
35,0
14,0
30,0
12,0
25,0
10,0
20,0
8,0
15,0
6,0
10,0
4,0
5,0
2,0
0,0
0,0
100 MB
200 MB
500 MB
1000 MB
Netrw 2.0, bez počítání aut. kódu
100 MB
500 MB
1000 MB
Netrw 2.0, jednostranný aut. kód SHA-1
40,0
14,0
35,0
12,0
30,0
200 MB
10,0
25,0
8,0
20,0
6,0
15,0
4,0
10,0
2,0
5,0
0,0
0,0
100 MB
200 MB
500 MB
1000 MB
Netrw 2.0, oboustranný aut. kód SHA-1
100 MB
500 MB
1000 MB
Netrw 2.0, jednostranný aut. kód SHA-256
7,0
7,0
6,0
6,0
5,0
5,0
4,0
4,0
3,0
3,0
2,0
2,0
1,0
1,0
0,0
200 MB
0,0
100 MB
200 MB
500 MB
1000 MB
100 MB
200 MB
500 MB
1000 MB
68
C. TESTY RYCHLOSTI PŘENOSU DAT
Netrw 2.0, oboustranný aut. kód SHA-256
4,0
3,5
3,0
2,5
2,0
1,5
1,0
0,5
0,0
100 MB
200 MB
500 MB
1000 MB
69
C. TESTY RYCHLOSTI PŘENOSU DAT
C.2 AMD Duron 600 MHz
Procesor:
AMD Duron 600 MHz
Pamět’:
128 MB
Základnı́ deska: VIA KT133/KM133, 100 Mhz
Operačnı́ Systém: Linux (Mandrake 10.0 [43])
Způsob přenosu: Ze zařı́zenı́ /dev/zero do zařı́zenı́ /dev/null
Netrw 1.2, bez počítání kontrolního součtu
100,0
Netrw 1.2, kontrolní součet SHA-1
22,5
90,0
20,0
80,0
17,5
70,0
15,0
60,0
12,5
50,0
10,0
40,0
7,5
30,0
20,0
5,0
10,0
2,5
0,0
0,0
100 MB
200 MB
500 MB
1000 MB
Netrw 2.0, bez počítání aut. kódu
90,0
100 MB
200 MB
500 MB
1000 MB
Netrw 2.0, jednostranný aut. kód SHA-1
14,0
80,0
12,0
70,0
10,0
60,0
50,0
8,0
40,0
6,0
30,0
4,0
20,0
2,0
10,0
0,0
0,0
100 MB
200 MB
500 MB
1000 MB
Netrw 2.0, oboustranný aut. kód SHA-1
8,0
100 MB
200 MB
500 MB
1000 MB
Netrw 2.0, jednostranný aut. kód SHA-256
9,0
7,0
8,0
6,0
7,0
6,0
5,0
5,0
4,0
4,0
3,0
3,0
2,0
2,0
1,0
1,0
0,0
0,0
100 MB
200 MB
500 MB
1000 MB
100 MB
200 MB
500 MB
1000 MB
70
C. TESTY RYCHLOSTI PŘENOSU DAT
Netrw 2.0, oboustranný aut. kód SHA-256
4,5
4,0
3,5
3,0
2,5
2,0
1,5
1,0
0,5
0,0
100 MB
200 MB
500 MB
1000 MB
71
C. TESTY RYCHLOSTI PŘENOSU DAT
C.3 2× Pentium III 1 GHz
Procesor:
2× Pentium III 1 GHz
Pamět’:
1 GB
Základnı́ deska: VIA VT82C Apollo
Operačnı́ Systém: Linux (Source Mage [44])
Způsob přenosu: Ze zařı́zenı́ /dev/zero do zařı́zenı́ /dev/null
Netrw 1.2, bez počítání kontrolního součtu
110,0
Netrw 1.2, kontrolní součet SHA-1
40,0
100,0
35,0
90,0
80,0
30,0
70,0
25,0
60,0
20,0
50,0
40,0
15,0
30,0
10,0
20,0
5,0
10,0
0,0
0,0
100 MB
200 MB
500 MB
1000 MB
Netrw 2.0, bez počítání aut. kódu
100 MB
500 MB
1000 MB
Netrw 2.0, jednostranný aut. kód SHA-1
140,0
35,0
120,0
30,0
100,0
25,0
80,0
20,0
60,0
15,0
40,0
10,0
20,0
5,0
0,0
200 MB
0,0
100 MB
200 MB
500 MB
1000 MB
Netrw 2.0, oboustranný aut. kód SHA-1
100 MB
500 MB
1000 MB
Netrw 2.0, jednostranný aut. kód SHA-256
20,0
20,0
17,5
17,5
15,0
15,0
12,5
12,5
10,0
10,0
7,5
7,5
5,0
5,0
2,5
2,5
0,0
200 MB
0,0
100 MB
200 MB
500 MB
1000 MB
100 MB
200 MB
500 MB
1000 MB
72
C. TESTY RYCHLOSTI PŘENOSU DAT
Netrw 2.0, oboustranný aut. kód SHA-256
11,0
10,0
9,0
8,0
7,0
6,0
5,0
4,0
3,0
2,0
1,0
0,0
100 MB
200 MB
500 MB
1000 MB
73
C. TESTY RYCHLOSTI PŘENOSU DAT
C.4 Intel Celeron 900 MHz, AMD Duron 600 MHz
Zdrojový systém (čtenı́ dat z disku a zası́lánı́ dat)
Procesor:
Intel Celeron 800 MHz, přetaktován na 900 MHz
Pamět’:
192 MB
Základnı́ deska: Via Apollo Pro 133T, 100 MHz
Pevný disk:
Seagate Baracuda 120 GB, 7200 rpm, 8 MB cache
Operačnı́ Systém: Linux (LFS) a Windows XP
Cı́lový systém (přı́jem dat a jejich zápis na disk)
Procesor:
AMD Duron 600 MHz
Pamět’:
128 MB
Základnı́ deska: VIA KT133/KM133, 100 Mhz
Pevný disk:
Seagate Baracuda 40 GB, 5400 rpm, 2 MB cache
Operačnı́ Systém: Linux (Mandrake 10.0) a Windows XP
Způsob přenosu: Z disku na disk
Autentizačnı́ kód: SHA-256
Linux → Linux
Linux → Windows
5,5
4,5
5,0
4,0
4,5
3,5
4,0
3,0
3,5
2,5
3,0
2,5
2,0
2,0
1,5
1,5
1,0
1,0
0,5
0,5
0,0
0,0
100 MB
200 MB
500 MB
1000 MB
100 MB
Windows → Linux
200 MB
500 MB
1000 MB
Windows → Windows
4,5
4,5
4,0
4,0
3,5
3,5
3,0
3,0
2,5
2,5
2,0
2,0
1,5
1,5
1,0
1,0
0,5
0,5
0,0
0,0
100 MB
200 MB
500 MB
1000 MB
100 MB
200 MB
500 MB
1000 MB
74