Geli a gbde - pripominky

[Dan Lukes]

Kaminar napsal/wrote, On 08/02/07 10:12:
> U mazani klicu vim, ze by to mozna neprineslo asi moc uzitku, ale vychazim
> zatim z toho, ze u gbde je heslo vyzadovano, i kdyz je to jina metoda a heslo
> tam muze byt vic opodstatnene.

	Do GBDE vidim jeste min nez do GELI. Nicmene, skoro se mi zda, ze tu 
jde o kryptografii a bezpecnost u ktere si nadute myslim, ze ji rozumim 
trochu vic, nez je celorepublikovy prumer.

	A metoda hledani bezpecneho reseni "protoze jiny system, o kterem 
nevime jak je vnitrne udelany to dela nejak -> tak to udelejme taky tak" 
se mi moc nezamlouva. Opisovani bez detailni analyzy byva na tomhle poli 
dost nebezpecne.

	Navic, pripustme, ze ty systemy jsou dostatecne podobne a opisovat lze 
- i tak je otazka, jestli spravny pozadavek je "pridat heslo do GELI" 
nebo jestli bys spis nemel zadat "odebrat heslo z GDBE protoze je tam 
uplne zbytecne".

	Ja fakt nevim - na to je potreba nastudovat ty dve implementace, a jak 
uz jsem psal, zamerit se na otazku zda pozadovanou zmenou skutecne 
dosahnu toho cile, ktery dosahnout chci. Ty zatim jako cil uvadis "aby 
to bylo stejne jako v GBDE" coz mi jako dobry duvod na zmenu nepripada.

	Sam ale ted nemam cas se v tom detailne stourat a takhle tu spekulujeme 
nad hypotezama ...

> Jedna se o zalohu metadat, tj. jeden sektor, ktery je pouzivany k ulozeni
> informaci o sifrovanem disku, vcetne MasterKey.

	Ktery je tam ovsem dvakrat, pokazde zasifrovany, a to klici U1 a U2. 
Bez jejich znalosti neziskas MasterKey a bez nej zas pristup k datum.

> Uvazoval jsem napriklad tento pripad:
> Uzivatel U1 zasifruje disk heslem H1. Uzivatel U2, ktery bude mit pristup
> k disku, ale nebude znat heslo si stahne metadata. Nejakym zpusobem
> se proflakne heslo H1 a U1 rychle zmeni heslo z H1 na H2.
> A je problem, protoze U2 ma zalohovana metadata s proflaknutym heslem
> H1. Takze mu staci obnovit metadata a ma pristup k sifrovanym datum.

	Jestlize je H1 pouzit jako klic pro sifrovani uloznych dat (zatimco sam 
je sifrovany U1 a U2) a proflakne se ten, pak jeho zmena na H-new obnasi 
kompletni presifrovani dat na disku (tak, ze jiz nejsou chranena klicem 
H1, ale H-new). Pokud utocnik nasledne prepise metadata a vrati do hdy 
klic H1, pak zcela ztrati pristup k datum, protoze tento klic je v teto 
chvili pro ulozena data jiz nespravny.

	Znovu pripominam, ze vychazim z *predpokladu* jak je to uvnitr 
implementovano (protoze takhle nejak se podobne veci obvykle 
implementuji) nikoliv z detailni znalosti teto konkretni implementace.

> Dalsi otazka je, jestli ta metadata jsou sifrovana.

	Ano. To je legitimni otazka. I kdyz, spis nez to, jestli jsou sifrovana 
cela metadata nas zajima jen jestli je v nich sifrovany MasterKey. A pak 
nas dal zajima, jestli utilita, ktera nam metadata poskytuje k nim ma 
vylucny pristup, nebo se k nim da dostat i jinak (a utilita je jen 
pomocny nastroj, ktery to dokaze snadno a data pekne zobrazi). A pokud 
se k nim da dostat i jinak, pak je treba zkoumat, kdo k nim smi 
pristoupit tim-kterym zpusobem a zda jsou tyto okruhy osob opravdu 
takove, jake maji byt.

	Ja osobne predpokladam, ze "dump" je jen kopie nejakeho sektoru, ke 
kteremu by se dalo dostat i beznymi operacemi se sektory, pokdu bude 
clovek vedet, ktery sektor to je.

	Ocekavam, ze i v takto "vystoupenych" metadatech (at uz ziskanych 
utilitou nebo primym ctenim z media) je MasterKey dvakrat, jednou 
presifrovany U1 a jednou U2 a bez znalosti uzivatelskych hesel tak 
dostupny neni.

>> 	Kazdopadne je treba tvuj pozadavek zkoumat z toho uhlu zda se nahodou 
>> nepokousis zabranit necemu co i tak nejde (opravnenemu pristupu k 
>> metadatum, ktery by jinak nebyl mozny) nebo naopak, co i tak pujde
> 
> Myslim, ze prinejmensim akce backup (mozna i dump) by mela vyzadovat heslo.

	Jestlize vsechno co "dump" prinasi oproti primemu pristupu k sektorum 
je znalost "ktery sektor" pak je vyzadovani hesla z bezpecnostniho 
hlediska bezcenne, naopak, zbytecne vyzadovani hesla ma na celkovou 
bezpecnost spise negativni dopad. Cim casteji se heslo zadava tim vetsi 
je riziko prozrazeni.

	Obdobne to plati pro "backup", ktery take podezrivam, ze se od 
sektor-by-sektor kopi lisi jen tim, ze "automaticky" vi ktere sektory.

> Proto jsem to take posilal sem, protoze vic hlav vic vi. :-)

	Muj spoluzak z gymplu to rikal jinak:
Vic hlav, vic skopovyho ;-)

	Kazdopadne, nevypada to, ze by tu nekdo mel implementaci GELI a GBDE 
nastudovanou a rozumel ji a pokud ano, podle vseho nema v umyslu se teto 
diskuse ucastnit.

	A se mnous stesti neudelal, protoze tebou polozena otazka vyzaduje 
detailni analyzu konkretni implementace a ja mam spis povsechny prehled. 
A nemyslim, ze se do toho ponorim hloubeji driv, nez to budu mit v planu 
poprve pouzit.

	Takze to podle vseho ceka na tebe ;-)

	Kazdopadne, pokud hlavni nebo dokonce jedinny argument pro zmenu, ktery 
mas, je "protoze to tak dela GBDE" tak bych se zasilanim pozadavku na 
zmenu jeste poseckal. Ale nekdo ti tu posilal nejake kontaktni udaje 
mezi nimiz byly i nejake konference - mozna bys vhodneho partnera pro 
diskusi nad timto problemem nasel tam.

						Dan



-- 
Dan Lukes                                               SISAL MFF UK
AKA: dan at obluda.cz, dan at freebsd.cz, dan at (kolej.)mff.cuni.cz