Sprava klicu (key management)

vyznamna cast bezpecnostni strategie nad danou domenou

Zakladnim ukolem spravy klicu je kontrola klicoveho materialu po celou dobu jeho existence, zabranujici neautorizovanemu odhaleni, modifikaci, substituci, opakovanemu nebo nespravnemu pouziti.
Dulezitym ukolem spravy klicu je zajistit, ze klice nikdy nebudou pristupny v otevrene forme.

Obecne pozadavky na spravu klicu:

Nebezpeci prozrazeni klice roste s dobou a intenzitou jeho pouzivani. Caste zmeny klicu jsou ale neunosne.

Resenim je provadet prenos klicu automaticky -> pouzivany klice pro sifrovani klicu (tez sekundarni klice).
Nejvyssi vrstva klicu - tzv. master klice - je potom distribuovana manualne.

Sluzby spravy klicu:

Registrace entit - mechanismus, prostrednictvim ktereho je pro system provadena autentizace uzivatelu a zarizeni

Generovani klicu - nepredikovatelny generator nahodnych cisel, pro aplikace vyzadujici nejvyssi stupen bezpecnosti nutne generatory pracujici na skutecne nahodnem, zvnejsku neovlivnitelnem jevu.

Tvorba certifikatu - certifikaty pouzivany pro ucely autentizace. Autorita provadejici certifikaci doplnenim certifikatu k danemu objektu prohlasi tento za "pravy".
on-line / off line

Autentizace, verifikace - rozlisujeme tri druhy


Verifikace se tyka samotneho procesu dokazovani urcitych tvrzeni, caste pouziti certifikatu, overovani pravosti certifikatu.

Distribuce klicu - procedury, kterymi jsou klice dorucovany entitam, jez o ne legitimne zadaji.

Dnes modni modularni system spravy klicu, kde jednotlive elementy protokolu splnuji jim odpovidajici pozadavky:

Point-to-point distribuce klicu - v pripade symetrickych algoritmu nutna predchozi existence sdileneho klice, v pripade asymetrickych systemu existence paru klicu na kazdem uzlu a notarizovane verejne klice na klic-serveru

Je-li distribuce klicu zalozena na pouziti symetrickych algoritmu, neni mozne zcela vyloucit nutnost provest jistou cast tohoto procesu manualne.

Udrzba klicu - aktivace klicu, problematika uschovy klicu, vymeny klicu, obnovy poskozenych klicu, cerne listiny vyzrazenych klicu, deaktivace klicu a jejich likvidace.

Sluzby casto sdruzovany do tzv. zarizeni spravy klicu (key management facility), jejichz obsah je (fyzicky) chranen proti poskozeni, vyzrazeni, zamene, modifikaci atp.
Priklady:

Z duvodu dosazeni potrebne granularity popisu celeho systemu je mozne i zarizeni dale slucovat do vetsich celku - jednotek spravy klicu (key management units), nebo tez serveru.

Servery povazovany za duveryhodne (trusted)

Vymena exponencialnich klicu.

Autory jsou Diffie a Hellman
Metoda je zalozena na obtiznosti pocitani logaritmu nad GF(p)
  1. Uzel A vypocita
    Ya = gXa mod p
     a posle je druhe strane.

    Xa - nahodne zvolene cislo, g - nektery z generatoru GF(p).

  2. Obdobnou akci provede i uzel B Yb.
  3. Obe strany spoctou
    Kab = gXaXb mod p

Pripadny utocnik by musel Kab spocitat pouze s pouzitim Ya nebo Yb coz nejde rychleji, nez spocitat logaritmus jednoho z cisel Xa nebo Xb.
Ma-li p okolo 300 cifer, A i B potrebuji radove tisic operaci, potencialni utocnik zhruba 1030 operaci.

Dohoda o klici zalozena na skladani funkci

Predpokladejme konecny automat s prechodovou funkci F. Po jednom kroku automat prejde z pocatecniho stavu s0 do stavu S1 = F(s0). Po n krocich tedy

sn = F(F(...F(s0)...) = Fn(s0)
Dale definujeme tyto dve funkce:
g: y = Fm(x)
h: y = Fn(x)
funkce g a h komutuji, pokud h(g(x)) = g(h(x)).

Protokol 1

A a B maji dohodnut spolecny konecny automat s prechodovou funkci F a pocatecnim stavem s0.
  1. A nahodne zvoli tajne cislo n1 a provede n1 kroku stroje z pocatecniho stavu.
    s(1) = sn1 = Fn1(s0)
     Vysledek sn1 je zaslan entite B.
    Obdobne se zachova B.
    s(2) = sn2 = Fn2(s0)
     Vysledek sn2 zasle entite A.

  2. A nastavi ve svem automatu jako aktualni stav prijaty sn2 a provede dalsich n1 kroku automatu.
    s(12) = Fn1(s(2)) = Fn1(Fn2(s0)) = F(n1 + n2)(s0)
     Stejnym zpusobem postupuje i entita B
    s(21) = Fn2(s(1)) = Fn2(Fn1(s0)) = F(n2 + n1)(s0)
  3. Protoze vsechny stavy automatu maji jednoznacne urceneho naslednika s(21) a s(12) musi byt stejne.

F musi mit vhodne vlastnosti, zejmena je nutne, aby platilo:

vhodnou funkci muze byt kuprikladu F(x) = xe.

Dalsi moznou prechodovou funkci lze popsat treba nasledne:
Predpokladejme pouziti posuvneho registru se zpetnou vazbou.
Prechodova funkce F: (x, y) -> (y, xy) (mod p).
Polozme s0 = (a, b) kde a, b neni 1. Potom

sn = (aFn-1bFn, aFnbFn-1)
Fn znaci n-te Fibonacciho cislo.
Rozbit tento system je ekvivalentni s pocitanim diskretniho logaritmu modulo p - 1. aa b muzeme totiz vyjadrit vzhledem k nejakemu generatoru takto:
a = ge1 (mod p), a = ge2 (mod p)
 a odtud
sn = (ge1Fn-1+e2Fn, ge1Fn+e2Fn-1)

Pokud povolime, aby se prechodova funkce menila v prubehu vypoctu, dostavame se k nasledujicimu protokolu.

Protokol 2

opet komunikujici entity maji predem dohodnuty spolecny konecny automat s prechodovou funkci F a pocatecnim stavem s0. Funkce g a h definovane stejne jako v predchozim protokolu.
  1. A nahodne zvoli tajne cislo n1 a spocita funkcni predpis
    g1(*) = Fn1(*)
     a g1 zasle entite B. Obdobne se zachova entita B se svym tajnym cislem n2.

  2. A pouzije prijate g2 jako prechodovou funkci automatu a provede n1 kroku pocinaje stavem s0, cimz ziska
    s(12) = g2n1(s0) = (Fn2)n1(s0) = Fn1n2(s0)
     Opet, stejnym zpusobem se zachova i B.

  3. Vysledne stavy s12 a s21 jsou identicke a mohou tedy slouzit jako sdileny klic.

Opet je treba, aby prechodova funkce automatu mela vhodne vlastnosti:

Polozme F(x) = ax (mod p) a dale s0 = 1.

g1(x) = Fn1(x) = an1x = a1x mod p
a
g2(x) = Fn2(x) = an2x = a2x mod p
 A posle popis funkce g1 pozustavajici z koeficientu a1 entite B. B nastavi aktualni stav s0 = 1 a pouzije g1 jako prechodovou funkci automatu a provede n2 kroku:
s(12) = (a n1)n2 mod p
 Stejnym zpusobem B pouzije prijate g2.

Jinou moznosti je polozit F(x) = xe (mod p), kde 1 < s0 < p-1. Potom

g1(x) = xen1 = xe1 (mod p)   a   g2(x) = xen2 = xe2 (mod p)
Na zaklade obdrzeneho popisu g1 sestavajiciho z e1 B spocita
s(12) = g1n2(s0) = s0e1n2 = s0en1n2 (mod p)
 A bude postupovat shodnym zpusobem. Opet s(12) lze pouzit jako klic. Stejne jako v predchozim protokolu, bezpecnost systemu je zalozena na slozitosti pocitani logaritmu modulo p-1.

Analyza

Protokol 1 neni bezpecny, pokud je pouzita funkce linearni. Pokud je v protokolu 2 pouzita linearni funkce, system je ekvivalentni s D-H metodou vymeny exponencialnich klicu. Zatim neni znamo, zda navrhovany protokol prinasi podstatne zlepseni rychlosti nebo bezpecnosti puvodniho Diffie-Hellmanova protokolu.

Distribuce klicu zalozena na identifikaci komunikujicich stran

Obe schemata jsou zalozena na obtiznosti vypoctu logaritmu nad vhodnym okruhem, lze je rozsirit i o digitalni podpisy a provadeni identifikace uzivatelu.

Protokol 1 - distribuce klicu s neprimou autentizaci

Inicializace

Centrum pro autentizaci klicu (CAK) vybere 'one-way' funkci f , velke prvocislo p a prvek a okruhu, ktery neni trivialnim delitelem nuly. Vsechna tato cisla zverejni. P melo byt vybrano tak, aby melo tvar p = 2p'-1, kde p' je rovnez prvocislo.
CAK zvoli svuj tajny klic, nahodne cislo x z mnoziny {1,...,p1} tak, aby NSD(x, p1) = 1. Na zaklade tohoto cisla CAK spocita svuj verejny klic
Y = ax (mod p)

Registrace uzivatele

Kazda nova entita musi navstivit CAK se svojii identifikaci IDi a obdrzi tzv. rozsirenou identifikaci EIDi jako
EIDi = f(IDi)
 a podpis (ri, si) jez SAK vypocte dle vztahu
si = (EIDi - kiri)x-1 mod p-1
 Zde ri = aki a ki je nahodne zvoleno z mnoziny {1,...,p-1}, si je v systemu pouzivano jako tajny klic entity Ei.

Distribuce klice

Ei a Ej chteji sdilet spolecny klic ki,j. Entita Ei zasle (IDi, ri) entite Ej a naopak. Entita Ei potom muze spocitat klic ki,j dle vztahu
si,j = (aEIDj(rjrj)-1)si mod p = (Y sj)si mod p
 obdobne entita Ej muze spocitat klic kj,i
sj,i = (aEIDi(riri)-1)sj mod p = (Y si)sj mod p

Protoze ki,j = ki,j, lze tyto hodnoty pouzit jako sdileneho klice pro entity Ei a Ej. Popsane schema umoznuje pouze neprimou autentizaci klicu v tom smyslu, ze pouziti spravneho klice lze poznat pouze dle smysluplnosti desifrovaneho textu.

Protokol 2 -distribuce klicu s primou autentizaci

Protokol navic umoznuje provadet autentizaci informaci, ktere si entity vymenuji v ramci tvorby spolecneho tajneho klice.

Faze inicializace celeho systemu a registrace uzivatele jsou shodne s predchozim protokolem.

sdileny klic ki,j pro entity Ei, Ej:
Krok 1: Entita i nahodne vybere cislo vi z mnoziny {1,...,p-1} a spocita

Wi = Yvi mod p = (Y si)sj mod p
Pouzitim schematu pro elektronicke podpisy dale entita Ei vygeneruje elektronicky podpis Wi ve tvaru (Wi, ni). Entite Ej zasle ctverici (IDi, ri, Wi, ni). Obdobne se zachova i entita Ej.

Krok 2: Po prijeti ctverice (IDi, ri, Wi, ni) entita Ej verifikuje, zda je spravny podpis Wi. Pokud je vse v poradku, entita Ej je jiz schopna spocitat sdileny klic:

Ki,j = Wivi mod p
I v tomto kroku se druha z komunikujicich entit zachova obdobne.
Uvazime-li, ze
Ki,j = (Y vj)vi mod p = (Y vi)vj mod p = Kj,i
 Ki,j muze byt pouzit jako sdileny tajny klic. Protoze vi a vj jsou nahodne voleny, je i vytvoreny klic rozdilny pro kazde navazane spojeni.

Analyza

Predpoklada se odolnost vuci nejznamejsim utokum, oba protokoly jsou z hlediska mozneho rozbiti patrne ekvivalentni s vypoctem logaritmu nad Galoisovym okruhem.
Vyhodou protokolu je moznost unifikovaneho rozsireni o autentizaci zprav vcetne casovych znamek a identifikace uzivatelu.

System distribuce klicu pro konference komunikujicich entit

schopnost vytvorit spolecny sdileny klic pro libovolnou skupinu komunikujicich - konferenci.

Protokol

umoznuje ustanovit sdileny tajny klic bez predchozi komunikace jednotlivych clenu zamyslene konference, autentizaci informaci, predavanych v ramci procesu ustanovovani klice. Opet je nezbytna existence duveryhodneho centra.

Krok 1: Centrum vygeneruje tri velka prvocisla p, q, r a cislo n = pq. Dale nalezne dvojici (e, d) zpusobem podobnym, jako v kryptosystemu RSA tak, aby platilo

ed = 1 (mod L)
L = NSD((p-1), (q-1), (r-1)),       2 < e, d < L
 Rovnez urci prvocislo c (2 < c < L) a cislo g, jez je primitivnim prvkem v Galoisovych okruzich GF(p). GF(q) a GF(r). Pro kazdou entitu i majici identifikaci Ii centrum spocita
si = Iid mod nr
 Na zaver tohoto kroku entita i obdrzi sestici (n, r, q, e, c, Si).
Pokud jiz neocekavame prijeti zadnych dalsich entit, je mozne cisla p, q a d zrusit. Cislo Si si kazda entita podrzi v tajnosti, zbyla cisla jsou spolecna pro vsechny.

Krok 2: V ramci tohoto kroku probiha vlastni tvorba sdileneho klice konference.

  1. Entita j vygeneruje nahodne cislo Uj ktere uchova v tajnosti a vsem zasle Ej, kde Ej = geUj mod n
  2. Entita i vygeneruje nahodne cislo Pi, ktere neni primitivnim delitelem p-1 a spocita Pi-1 tak, aby platilo PiPi-1 = 1 (mod (r-1)). Obe cisla ponecha v tajnosti, stejne jako nahodne vygenerovane cislo Vi. Entite j odesle ctverici (Xi, Yi, Zij, Fi):
    Xi = gePi mod nr,    Yi = SigcPi mod nr,
    Zij = EjPi mod nr,    Fi = XieVi mod n
  3. Entita j obdrzi (Xi, Yi, Zij, Fi) a overi platnost nasledujicich kongruenci:
    Yie/Xie = Ii (mod nr),    Zij = XiUj mod n
    Pokud se podari overit platnost uvedenych kongruenci, entita j verifikovala, ze odesilatelem prijatych dat je opravdu entita i. Entita j tedy vygeneruje nahodne cislo Rj, ktere rovnez podrzi v tajnosti. Entite i zasle trojici (Aji, Bji, Cji), kde
    Aji = XieRj mod nr,     Bji = SjXieRj mod nr
    Cji = FiRj mod n
     pricemz si ponecha Ajj = XjeRj.
  4. Entita i prijme (Aji, Bji, Cji). Overenim platnosti nasledujicich kongruenci zjisti, zda prijata data byla opravdu zaslana entitou j:
    Bjie/Ajic = Ij (mod nr),    Cji = AjiVi mod n
    Pokud je vse vporadku, je entita i jiz schopna spocitat sdileny klic zamyslene konference dle vztahu
    K=soucin Aji pro j=1..m umocneny na 1/Pi to cele mod r
  5. Ziskany klic je vskutku sdilenym tajnym klicem konference, nebot
    ge2(PiR1+PiR2+...+PiRm)Pi-1 mod r = ge2(R1+R2+...+Rm) mod r

Analyza

Utok na jednotlive casti protokolu by mel byt ekvivalentni s vyresenim alespon jednoho ze dvou znamych obtiznych problemu - vypocet prvociselneho rozkladu, nebo vypocet logaritmu nad Galoisovym polem.

Sprava klicu pro bezpecnou komunikaci ATM terminalu

System umoznujici uzivatelum platby prostrednictvim bezhotovostvich plateb. Kazdy uzivatel ma vlastni kartu obsahujici jeho osobni udaje, cislo uctu atd. Kazdy z uzivatelu ma rovnez pridelen PIN konstantni delky.
System potom sestava z mnozstvi terminalu slouzicich jako uzivatelske rozhrani a nekolika center, ktere si lze predstavit jako pobocky ruznych bank.

Protokol

Klic transakce

Klic karty Kk - zavisly na osobe majitele karty
Kazdy terminal obsahuje pro kazde centrum i, se kterym komunikuje, jeden klicovy registr KRi, jehoz hodnota je vyuzivana pro tvorbu klice transakce.

Predpokladejme system v beznem provoznim stavu, uzivatel prave vlozil kartu a dozaduje se platby.

  1. Terminal precetl Kk a cislo uctu CU jejiho majitele a zjistil, ktere centrum provadi spravu tohoto uctu.
  2. Je vygenerovan klic transakce KT:
    KT = (DEA(Kk, KRi)) xor Kk
  3. Aby i centrum bylo schopno sestavit klic, zprava, kterou terminal centru posila, obsahuje v otevrene podobe cislo uctu a identifikaci terminalu.
  4. Centrum rovnez ma k dispozici registr klice, se shodnou hodnotou a dostatecne informace o kazdem spravovanem uctu, je schopno si ze zaslanych informaci tez sestavit klic transakce.

Dotaz

  1. Dotaz obsahuje ve forme otevreneho textu cislo uctu a identifikaci terminalu.
    Uzivatelovo PIN, pozadovanou castku atd., je samozrejme nutne separatne zasifrovat s pouzitim klice transakce.
  2. Autentizacni blok zpravy je vygenerovan procedurou pro tvorbu autentizacniho bloku zpravy. Dotaz je sifrovan pouzitim algoritmu DEA metodou CFB. Autentizacni blok zpravy vznikne jako posledni vystupni blok tohoto procesu.
  3. Autentizacni blok rozdelime na dve poloviny.
    Leva polovina bude slouzit jako autentizacni kod.
    Zbyvajicich 32 bitu autentizacniho bloku oznacme jako reziduum dotazu RD. Terminal si jej uschova pro pozdejsi autentizaci odpovedi od centra.
  4. Centrum po prijeti dotazu zkonstruuje klic transakce, od dotazu oddeli autentizacni kod a spocita autentizacni blok zpravy a overi jej.I centrum si ponecha pravou cast (reziduum dotazu) pro pozdejsi pouziti.

Odpoved

  1. Centrum sestavi odpoved a opet spocita autentizacni blok zpravy. Pred pocitanim autentizacniho bloku centrum pripoji na zacatek zpravy RD.
  2. Leva cast autentizacniho bloku je jako autentizacni kod pripojena ke zprave a odeslana terminalu. Pravou cast, oznacme ji reziduum odpovedi RO, si centrum ponecha.
  3. Terminal obdobnym zpusobem jako v pripade dotazu centrum vypocita autentizacni blok a provede verifikaci prijatych dat. Pokud je vse v poradku, v souladu s doslou odpovedi provede odpovidajici akci a dokonci svoji cast transakce. I terminal si ponecha pravou cast spocitaneho autentizacniho bloku (reziduum odpovedi).

Aktualizace registru klice

  1. Centrum zrusi klic transakce, uschova puvodni hodnotu registru klice.
  2. Nova hodnota registru klice je vypocitana takto:
    KT = (DEA(RO + RD, KRi))
  3. Terminal zrusi klic transakce a zpusobem stejnym jako centrum provede aktualizaci sveho registru klice.
  4. Pokud se vsak ztrati odpoved od centra, terminal pro pristi transakci pouzije tuto starou hodnotu registru klice. Centrum registr klice naplni uschovanou predchozi hodnotou a pokusi se znovu o autentizaci.

Analyza

Klic transakce je 'end-to-end' a je jedinecny pro kazdou transakci. Dokonce ani znalost tohoto klice transakce a klice karty nasledujici karty nemozni pripadnemu utocnikovi odvodit klic nasledujici tansakce. Podobne neni mozno odvodit neco o predesle transakci.
Funkce systemu byla popsana pocinaje nejakym rutinnim stavem. Inicializaci a pripadnou reinicializaci je mozno provest napriklad v ramci instalace a nebo bezne udrzby terminalu pouzitim specialni servisni karty.

Sprava klicu pro implementaci DES

Predpokladejme vypocetni system skladajici se z jisteho mnozstvi terminalu pripojenych k hostitelskemu procesoru. V dalsim pak provedeme zobecneni pro pripad vetsiho mnozstvi hostitelskych procesoru.
Zde uvedena sprava klicu umoznuje integrovat DES do systemu pro zpracovani dat takovym zpusobem, aby bylo mozne provadet end-to-end ochranu dat. S timto zpusobem ochrany se data v zadnem okamziku prenosu nevyskytuji v otevrene forme . Navic je takto elegantne odstraneno nebezpeci zneuziti na spatnou adresu dorucenych paketu, nebot spravne desifrovani je shopen provest pouze adresat. Dalsi vyhodou je moznost snadneho doplneni mechanismu umoznujiciho sifrovani dat, ulozenych v danem uzlu.
End-to-end sifrovani je provadeno pomoci sdileneho sifrovaciho klice - tzv. primarniho klice, ktery je dynamicky generovan a je pouzivan po dobu jednoho spojeni. Proto jej nazyvame tez klic spojeni (KS). KS je vytvoren hostitelskym procesorem a dopraven na odpovidajici terminal zasifrovany master-klicem tohoto terminalu. Tento system je mozne zobecnit pro pripad existence vetsiho mnozstvi hostitelskych procesoru. V takovem pripade jeden z hostitelskych procesoru vygeneruje KS a zasle jej druhemu procesoru zasifrovany sdilenym klicem, ktery budeme nazyvat sekundarni komunikacni klic (KNC). Samozrejme kazda dvojice hostitelskych procesoru sdili jiny KNC.
Bezpecnost klicu je zajistena nasledujicim zpusobem. Vsechny klice s vyjimkou master-klice jsou chraneny kryptograficky zasifrovanim pomoci master-klice. Vlastni master-klic a cely kryptograficky algoritmus je potom ulozen v otevrene forme v nepristupne oblasti kryptografickeho zarizeni. Jinymi slovy master-klic a algoritmus jsou chraneny fyzickou ochranou, master-klic je do daneho kryptografickeho zarizeni distribuovan manualne. Vyhodou popsaneho usporadani je, ze i kdyz se utocnikovi podari zmocnit se ulozenych klicu, nemuze je pouzit k desifrovani drive zachycene komunikace. Kdyby totiz utocnik mel k dispozici nezasifrovane klice, byl by schopen sam provadet desifrovani. V nasem pripade by jeste potreboval pristup ke kryptografickemu zarizeni, odkud klice pochazeji, aby mohl provest jejich desifrovani.
Je samozrejme, ze veskere kryptograficke vypocty se provadeji uvnitr bezpecneho kryptografickeho zarizeni, aby nemohlo dojit k uniku informaci, jako treba mezivysledku po jednotlivych etapach sifrovaciho procesu DES atp [EHR78].

Protokol 1 - jediny hostitelsky procesor.

Oznacme KMT master-klic terminalu a KMH0 master-klic hostitelskeho procesoru. Klic spojeni KS je vygenerovan jednim uzlem a zasifrovany zaslan druhemu uzlu. Jako sdileny klic v tomto pripade poslouzi KMT. Na strane hostitelskeho procesoru jsou k dispozici operace ECPH pro sifrovani a DCPH pro desifrovani definovane nasledujicim zpusobem:
ECPH: {EKMH0(key), data} -> Ekey(data)
DCPH: {EKMH0(key), Ekey(data)} -> data
Notace zapisu: symboly uvnitr slozenych zavorek znamenaji vstupni parametry kryptografickeho zarizeni, symboly napravo od sipky pak predstavuji odpovidajici vystup z tohoto zarizeni.

Protoze terminal muze v danem case komunikovat pouze s jednim hostitelskym procesorem, funguji operace sifrovani a desifrovani na terminalu trochu jinak. Po prijeti KS od hostitelskeho procesoru je provedena operace DMK - desifrovani podle master-klice, ktera je definovana takto: DMK: {EKMT(KS)} -> KS
ziskana hodnota KS je ulozena do pracovniho registru klice uvnitr kryptografickeho zarizeni. Operace sifrovani a desifrovani jsou potom rizeny hodnotou tohoto registru. Definovany jsou nasledujicim zpusobem:
ECPH: {data} -> EKS(data), DCPH: EKS(data) -> {data}
Proces generovani KS klicu byl umisten na hostitelsky procesor z ekonomickych duvodu. Pri tomto usporadani jej totiz mohou sdilet vsechny pripojene terminaly, jejichz zarizeni muze byt jednodussi. Dokonce neni nutne, aby vlastni generovani klicu spojeni probihalo v ramci bezpecne oblasti uvnitr kryptografickeho zarizeni. Je pouzito takovehoto triku. Generator nahodnych cisel generuje (pseudo)nahodne cislo RN, na ktere je vsak pohlizeno timto zpusobem: RN = EKMH0(KS). Pred prenosem KS na terminal je samozrejme potreba provest desifrovani master-klicem ridiciho procesoru a nasledne zasifrovani pomoci KMT daneho terminalu, kterezto operace jiz pochopitelne probihaji uvnitr kryptografickeho zarizeni. Ridici procesor ma k dispozici master-klice vsech pripojenych terminalu,jak jiz vyplynulo z predchoziho popisu.
Poslednim nevyresenym problemem je prave zpusob ulozeni master-klicu jednotlivych terminalu na hostitelskem procesoru. Jednoduche zasifrovani KMT pomoci KMH0 je nedostacujici. Operace DCPH: {EKMH0(KMT), EKMT(KS)} -> KS by totiz vedla k vyzrazeni KS, pricemz obe vstupni hodnoty je mozne ziskat pristupem do nechranene oblasti ulozeni zasifrovanych klicu na strane hostitelskeho procesoru, respektive odposlechem komunikace s terminalem.
Moznym resenim shora popsaneho problemu je zavedeni dalsiho master-klice ridiciho procesoru KMH1. Klice KMT jsou ulozeny zasifrovany prave timto klicem. Potom je ovsem nutne, aby presifrovani EKMH0(KS) na EKMT(KS) pobihalo za pouziti EKMH1(KMT). Proceduru, ktera toto provadi budeme nazyvat presifrovani z master-klice a je definovana takto: RFMK: {EKMH1(KMT), EKMT(KS)} -> EKMT(KS). V prakticke implementaci se vsak casto pouziva jenom jeden master-klic KMH0 s tim, ze druhy klic z dvojice je interne dopocitavan jako nejaka jednoducha funkce druheho (napr. bitovy doplnek). Vzhledem k vhodnym kryptografickym vlastnostem DESu (difuse, nelinearita) tato metoda neni narusenim bezpecnosti systemu.

Protokol 2 - vice hostitelskych procesoru

Necht i resp. j oznacuji hostitelske uzly s master-klici KM0i resp. KM0j. Soubor uzlu sestavajici z hostitelskeho procesoru i a vsech pripojenych terminalu budeme nazyvat domenou i. Problem spociva v ustanoveni klice spojeni KS mezi dvema uzly z ruznych domen. Za timto ucelem musi hostitelske procesory domen i a j sdilet specialni klic pouzivany pouze pro posilani klicu spojeni z jedne domeny do druhe. Tento specialni klic oznacme jako sekundarni komunikacni klic (KNC). Popisovany protokol pouziva tyto sekundarni komunikacni klice: Obecne receno, v danem okamziku existuje pouze jeden klic KNCij a jeden KNCji, avsak velke mnozstvi klicu KNCjj a KNCii. V pripade terminalu master-klic KMT plni funkci sekundarniho komunikacniho klice - je pouzivan k prenosu klicu spojeni KS, ale nikoliv pro jejich ulozeni. Mnozina klicu {KNCii} tedu vskutku odpovida mnozine {KMT1i, KMT2i, ..., KMTni}.
Metoda ustanoveni spolecneho klice spojeni v ramci jedne domeny zustava stejna, jako v predchozim protokolu. Nadale se tedy budeme zabyvat pouze otazkou ustanoveni klice spojeni mezi domenami, rekneme mezi uzlem z domeny i a uzlem z domeny j. Opet vygenerujeme (pseudo)nahodne cislo RN, ktere budeme chapat ve smyslu RN = EKM0i(KS). RN muze byt primo pouzito v procedurach ECPH a DCPH pro sifrovani a desifrovani dat, nebo muze byt pouzito v operaci RFMK k presifrovani KS master-klicem terminalu, nalezejiciho do domeny i. Pokud chceme poslat KS do domeny j, je v uzlu i pouzita procedura RFMK za ucelem vygenerovani EKNCij(KS):
RFMK: {EKM1i(KNCij), EKM0i(KS)} -> EKNCij(KS)

Retezec EKNCij(KS) je prenesen do uzlu j, kde je pomoci operace presifrovani master-klicem (RTMK) sestaven :EKM0i(KS)
RTMK: {EKM2j(KNCij), EKNCij(KS)} -> EKM0j(KS)

vysledek muze byt primo pouzit v procedurach ECPH a DCPH k sifrovani a desifrovani dat, nebo v procedure RFMK k presifrovani KS master-klicem terminalu, nalezejiciho do domeny j.
Poznamenejme, ze retezec EKNCij(KS) je z uzlu i prenasen po nechranene lince. Pripadny utocnik vsak tuto informaci nemuze v uzlu i zadnym zpusobem vyuzit, nebot hodnota EKM2j(KNCij)
nikde v systemu neni ulozena. Opak je pravdou v uzlu j. Metoda umoznujici uzlu j spocitat EKM0i(KS) by mohla byt zneuzita utocnikem. Z tohoto duvodu by operace RTMK mela byt privilegovana a jeji provadeni by melo byt kontrolovano systemem. Strucne receno, pokud je sekundarni komunikacni klic pouzit zaroven se shora uvedenym procesorem k prenosu klice spojeni z jedne domeny do druhe, mel by mechanismus obnovy tohoto klice v cilove domene chranen jinymi, nez kryptografickymi prostredky.

Sprava klicu pomoci kontrolnich vektoru

Charakteristika

S kazdym klicem K je asociovan kontrolni vektor C skladajici se z mnoziny poli specifikujicich pripustne pouziti klice v ramci systemu. V ramci generovani klice jsou klic a odpovidajici kontrolni vektor kryptograficky spojeny tak, aby byla vyloucena moznost nasledne zmeny vektoru. Toto je zajisteno zasifrovanim vygenerovaneho klice klicem KK xor C, kde KK je klic pro sifrovani klicu a xor predstavuje operaci XOR. Pri pouziti je KK opet zkombinovan se zadanym C a je desifrovan klic K. Protoze K je tajny klic, musi byt cely proces vytvareni KK xor C a sifrovani a desifrovani K provadeno uvnitr kryptografickeho hardware. Proces spojovani K a C nemuze byt tedy napodobovan uzivatelem.

Po svem vytvoreni jsou klic a jeho kontrolni vektor pouzivany k inicializaci a prizpusobovani kryptografickeho hardware. Klic nastavuje vlastni kryptograficky algoritmus vyberem jedne z mnoha mapovacich funkci. Kontrolni vektor slouzi k nastavovani procesoru kryptograficke jednotky. Jde napriklad o vyber sady povolenych instrukci, pracovnich modu a operacich, ktere mohou byt s asociovanym klicem provadeny. Jinymi slovy je takto vymezeno povolene pouziti daneho klice.

Pozadovane vlastnosti spravy vektoru

Rozsiritelnost - v podstate jde o moznost do systemu zavadet dalsi pozadavky a snizovat granularitu rizeni.
Ortogonalita - specifikace navzajem nesouvisejicich vlastnosti by mely byt ulozeny tak, aby mohly byt pouzivany oddelene.
Obecnost - metoda by mela pokryt co nejsirsi tridu moznych aplikaci.
Spojitost - informace o klici by mely zustat pristupne v puvodni forme po celou dobu existence klice.
Jednoduchost - specifikace spravy klicu a sifrovaci funkce pro parovani klice s odpovidajicim kontrolnim vektorem by mela byt jednoducha a jasna.
Metoda pouziti kontrolnich vektoru splnuje shora uvedena kriteria nasledujicim zpusobem: Rozsiritelnosti je dosazeno pouzitim vektoru o delce 64, 128, popripade i vice bitu, ortogonality kodovanim jednotlivych opravneni pro pouzivani klice ve forme oddelenych poli v ramci kontrolniho vektoru. Obecnosti je dosazeno externalizaci kontrolnich vektoru. Informaci zde ulozenych tak krome vlastniho kryptografickeho HW muze vyuzivat i aplikacni software. Spojitost je zajistena kryptografickym spojenim vektoru a klice.

Protokol

Jak jiz bylo naznaceno, kazdy klic K je kryptograficky spojen s kontrolnim vektorem C. Kazde kryptograficke zarizeni je navrzeno tak, aby pri kazdem pokusu o pouziti daneho klice nejprve provedlo verifikaci, zda tento pokus je v souladu s povolenym rozsahem operaci tak, jak je zaznamenano v kontrolnim vektoru.

Kryptograficke spojovani K a C

Spojeni K a C je nutne provest takovym zpusobem, aby pripadny utocnik nemel moznost provadet nasledne zmeny kontrolniho vektoru. Jsou mozne dve metody parovani. Prvni metodou je zapojit kontrolni vektor do procesu sifrovani a desifrovani klice. Druhou moznosti je provest konkatenaci klice a kontrolniho vektoru a na vzniklem retezci spocitat autentizacni kod AC, ktery zajisti nemoznost naslednych zmen takto zabezpeceneho retezce.

Pri pouziti prvni z uvedenych metod muze byt puvodni klic K obnoven pouze pri opetovne spravne specifikaci odpovidajiciho kontrolniho vektoru C. V pripade specifikace nespravneho vektoru C' dojde k vytvoreni odlisneho klice K', ktery je dale pouzit namisto spravneho klice K. Zde je potom nutne zajistit, aby tento vadny klic nemel pro pripadneho utocnika zadnou hodnotu. Vyhodou metody je vysoka efektivita a zanedbatelna vypocetni narocnost spojena s kazdym pouzitim klice.

Druha metoda dovoluje zjistit, zda byl zadan spravny kontrolni vektor a v pripade nesouladu je tedy mozne zrusit vyrizovani celeho pozadavku. Nevyhodou je nutnost staleho overovani AC vzdy pri kazdem pouziti klice.

Algoritmus pro sifrovani a desifrovani klicu

Vstupem algoritmu pro sifrovani klicu je kontrolni vektror C, klic pro sifrovani klicu KK a klic K. C je prostrednictvim hasovaci funkce h preveden na 128-bitovou hodnotu H, kterou je XOR-ovan klic KK. Nasledne je K zasifrovan klicem KK xor H. K sifrovani je pouzit e-d-e algoritmus dle ANSI standardu X9.17-1985. Vysledkem je sifra eKK xor H(K). Zasifrovany klic je rozsifrovan zpusobem obdobnym s tim, ze misto vstupu K je pouzita sifra eKK xor H(K) a namisto e-d-e algoritmu inversni algoritmus d-e-d.

Pouzita hasovaci funkce pouze zajistuje normalizaci delky kontrolniho vektoru na 128 bitu. Toto je provedeno bud zopakovanim, popripade identickym opsanim vstupu, nebo, v pripade vektoru o delce vetsi nez 128 bitu nahrazenim vektoru odpovidajicim MDC kodem.

Generovani klicu

Schema rovnez obsahuje funkci G pro tvorbu novy klicu s vystupem
ekey1 xor H1(K) a ekey2 xor H2(K)
K interne generovany nahodny klic, C1 a C2 kontrolni vektory, key1 a key2 vhodne klice - napr. master klice jednotlivych zarizeni, klice pro sifrovani klicu sdilene mezi odesilatele a prijemce, nebo mezi toto generujici zarizeni a nejake dalsi zarizeni v systemu.
H1 a H2 jsou hodnoty hasovaci funkce pro oba kontrolni vektory. V prubehu vypoctu je overeno, zda oba kontrolni vektory jsou konzistentni s celkovou architekturou systemu a zdali tvori mozny par. V pripade chyby je proces tvorby klice zastaven.

Distribuce klicu

Zadame vstupni parametry G (KMi, C1) a (KKij, C2), tedy na miste key1 je pouzit master klic zarizeni i a na miste key2 klic pro sifrovani klicu sdileny mezi zarizeni i a j. Vysledkem jsou baliky
(eKMi xor H1(K), C1) a (eKKij xor H2(K), C2).
Prvni z nich je ulozen v zarizeni i a druhy je prostrednictvim kanalu pro prenos klicu dopraven do zarizeni j.
Zde je proveden import - dosly balik je desifrovan, preneseny klic K je okamzite znovu zasifrovan master klicem KMj za pouziti C2 a ulozen.

Kerberos

pracovni stanice povazujeme za neduveryhodne, pozadujeme autentizaci zadatele pri kazdem pozadavku na sluzbu. Kazdy uzivatel a kazda sluzba me vlastni heslo. System obsahuje duveryhodny autentizacni server.
  1. V ramci prihlasovani do systemu uzivatel zada sve heslo.
  2. Stanice zasle autentizacnimu serveru zpravu
    {login-name, TGS-name}
    TGS-name - jmeno akreditacniho serveru.
  3. Autentizacni server vyhleda sifrovaci klic obou techto entit. (klicemi jsou zasifrovana hesla)
  4. Autentizacni server vytvori odpoved
    {TGS-session_key, sealed_ticket}
    zasifruje ji uzivatelovym heslem a zasle stanici.
    Ticket ma tvar:
    {login-name, TGS-name, WS-net_address, TGS-session_key}
    zasifrovanim ticketu sifrovacim klicem TGS vznikne sealed_ticket. WS-net_address je adresa stanice, TGS-session_key klic oznacujici relaci s TGS.
  5. Po prijeti zpravy z bodu 4. stanice pozada uzivatele o heslo, zasifruje je a ziskany klic pouzije k desifrovani zpravy a uschova ji.

Pri zadosti o libovolnou sluzbu bude nyni treba nejprve ziskat odpovidajici listek.

  1. Stanice zasle akreditacnimu serveru zadost
    {sealed_ticket, sealed_authenticator, end_server_name}
    kde authenticator ma tvar
    {login-name, WS-net_address, current_time}
    Sealed_authenticator vznikne zasifrovanim klicem TGS-session_key.
  2. Akreditacni server desifruje sealed_ticket, cimz ziska TGS-session_key. Timto klicem desifruje sealed_authenticator, overi platnost listku (login-name, TGS-name, WS-net_address) a porovna cas.
  3. Akreditacni server vyhleda heslo ciloveho serveru, a vytvori klic transakce session-key.
  4. Pracovni stanici akreditacni server zasle zpravu
    {session_key, sealed_ticket}
    kde sealed_ticket vznikne zasifrovanim ticketu
    {login-name, end_server_name, WS-net_address, session_key}
    klicem ciloveho serveru.
    Pred odeslanim je zprava zasifrovana klicem TGS-session_key.
  5. Desifrovanim zpravy z predchoziho bodu stanice ziska ticket pro cilovy server. Rovnez od akreditacniho serveru dostane novy TGS-session_key.
  6. Stanice zasle cilovemu serveru zpravu
    {sealed_ticket, sealed_authenticator, end_server_name}
    kde sealed_authenticator je
    {login-name, WS-net_address, current_time}
    zasifrovany klicem session_key.
  7. Cilovy server desifruje sealed_ticket a nasledne sealed_authenticator a provede obdobnou verifikaci jako akreditacni server v bode 2. tohoto postupu.
  8. Je-li vse v poradku, vyhovi pozadavku a odpoved zasifruje klicem session_key.

Struktura systemu Kerberos

© Tonda Benes, 1995
S prevodem tohoto dokumentu do HTML pomahal ©Dan Lukes, 1995
Toto je revision 1.0, 29.11.95
Tuto stranku shledlo jiz <pocet navstevniku> zvedavcu ...