LUKS získá možnost destrukce (diskuse)

[stativ]

Už jenom to propojit s velkým červeným tlačítkem.

[Kyosuke]

Super, takže to bude vypadat nějak takhle? Já chci taky hlasovou autorizaci!

[deda.jabko]

hele, tak to je nudna autorizace.... takhle vypada poradna autorizace!

[MiHl]

To mi nepřijde jako nějaká extra novinka...

for klic in 0 1 2 3 4 5 6 7
do
  cryptsetup -q luksKillSlot /dev/zarizeni $klic
done

udělá to samé a nepotřebuje k tomu žádné heslo (tzn. lze to skutečně udělat na tlačítko)

dd if=/dev/urandom of=/dev/zarizeni count=10240

Taky zazařízení vyřadí a to i s hlavičkou, takže se nepozná, že to vůbec nějaké šifrované zařízení bylo. (Při destrukci klíče klasicky (z prvního způsobu), klíč přepisuje vícekrát a i s náhodným vzorem.

[Milan]

Tady ale asi jde spis o to aby jsi normalnim zpusobem zadal heslo ktery znepristupni data. Takze kdyz ti bude nekdo za zady stat s bouchackou a chtit po tobe aby jsi to desifroval, zadas to destrukcni heslo a je po vsem

Jinak ale nevim k cemu jinymu by to mohlo byt. I to jak jsem to popsal ma pouze teoreticke momznosti k pouziti (moznost kopie pred adanim hesla)...

[Xerces]

Co když si ten někdo nejdříve udělá kopii toho zašifrovaného a pak teprve nad tou kopií Vás požádá s bouchačkou za hlavou abyste to dešifroval

[Milan]

No, vsak to same rikam v posledni vete v zavorkach

[MiHl]

teď jsem zkouknul i ten patch... a:

1) šifrovaná zařízení a soubory s obrazem oddílu nejsou používány jen nástrojem cryptsetup-luks. Je tu i další soft (FreeOTFE,...) , který implementuje specifikaci LUKS z http://luks.endorphin.org/spec . Ve specifikaci ale o tom není ani zmínka, takže tento postup je dle mě špatně.

2) Pokud se spěchá, je lepší použít zmíněné :

for key in 0 1 2 3 4 5 6 7
do
  cryptsetup -q luksKillSlot /dev/zarizeni $key
done

udělá to úplně to samé a nepotřebuje to zadávat žádný klíč.

3) Pokud se nebude jednat o něčí desetiletou sestru (kterou by to nejspíše skutečně zastavilo), tak nevidím důvod, proč se domnívat, že se bude jednat o tak velkého blba, že si předem neudělá kopii hlavičky před tím, než se z vás pokusí heslo vymlátit.

[Kvakor]

3) Pokud se nebude jednat o něčí desetiletou sestru (kterou by to nejspíše skutečně zastavilo), tak nevidím důvod, proč se domnívat, že se bude jednat o tak velkého blba, že si předem neudělá kopii hlavičky před tím, než se z vás pokusí heslo vymlátit.

Bohuzel, pokud je pouzito jen heslo bez nejakeho hardwaroveho udelatoru (obsahujici samotny desiforvaci klic, ktery heslo pouze zpristupni), ktery se dokaze sam fyzicky zdestruovat, je odolnost proti tomuto postupu (eufemisicky zvanemu Rubber-hose cryptanalysis) zavisla pouze a jen na osobe, znajici heslo.

[Shadow]

Security by obscurity, řekl bych. Spoléhat na to, že útočník o této funkci neví a bude heslo zadávat přímo prostřednictvím mého softwaru (který jsem si mohl libovolně upravit), aniž by si před tím pořídil kopii, bych vážně nechtěl. Spíše bych ocenil, kdyby nějak vyřešili (nebo ztížili) cold boot attack.

[Non_E]

Cold boot attack je problém hardware, s tím podle mě nic luks neudělá.

[Käyttäjä 11133]

Asi tak.

[Jakub Lucký]

leda šifrovat RAMku ;)

[Shadow]

Možná by to šlo útočníkům alespoň nějak ztížit, třeba fragmentací klíče v paměti, jeho částečným zašifrováním či zakódováním, nevím. Bohužel nejsem programátor na této úrovni, abych věděl, co je reálně proveditelné a co ne.