Kompletně zašifrovaný vnitřní mirror

[Jenda]

A pokud ti jde o pakárnu s updatem, tak na flashce můžeš mít systém, který disk odemkne, a potom spustí nový kernel z šifrovaného disku pomocí kexec.

[Reklama]

[the poloprdoch]

ok, dik, tohle zkusim pogoogit

[the poloprdoch]

Nebo jestli mas nejaky odkaz? Dik

[Karel]

Odbočka
Pánové nechci rušit, chci nabídnout  ... V PCBSD (a možná/jistě i jinde...) je možnost zašifrovat CELÝ disk a dokud nezadám správné heslo  a nerozešifruje si to (co?celý disk sectory), tak mě to nepustí (pokud se nepletu) narozdíl od jiných distrubucí, OS apd. ani do grubu / dál. Co vy na to?

[Jenda]

Odbočka
Pánové nechci rušit, chci nabídnout  ... V PCBSD (a možná/jistě i jinde...) je možnost zašifrovat CELÝ disk a dokud nezadám správné heslo  a nerozešifruje si to (co?celý disk sectory), tak mě to nepustí (pokud se nepletu) narozdíl od jiných distrubucí, OS apd. ani do grubu / dál. Co vy na to?

A jak to funguje? Napadá mě jenom že by tam byl jejich vlastní zavaděč. A tím jsme přesunuli problém z "jak zabezpečit GRUB" na "jak zabezpečit jejich zavaděč".

[Reklama]

[Karel]

Funguje  "kouzlem" (nebo nějakým kozlem  ). Asi bych se měl na to podívat když tvrdí, že je disk od prvního po poslední sektor šifrovaný ... Klíčové slovo GELI
https://en.wikipedia.org/wiki/Geli_%28software%29 a třeba ještě http://blog.pcbsd.org/2015/03/a-look-at-the-upcoming-features-for-10-1-2/ Ale vlastně nevím, co = jakou bezpečnost zakladatel vlákna hledá...

[he]

Mit /boot na flashce neni predmetem dotazu.

Pak jsem nepochopil dotaz. Co tedy mělo znamenat "start probiha z usb flasky, ale pak system bezi ze zasifrovaneho vnitrniho mirroru"?

dotaz je zrejme na zpusob zvany chainloader, kdo pamatuje jeste lilo. s tim, ze prvni chain je na flashce a obsahuje crypto kanal predavani informaci k druhemu v chainu.

[he]

Nevim to jiste, ale nemyslim si, ze se pri updatu jadra aktualizuje i bootsrap kod. Konfigurace grubu je ulozena v /boot/grub, coz by prave melo byt zasifrovane na disku (bezici system by /boot videl uz desifrovany). Update grubu (ktery neni zdaleka tak casty) by mohl pripadnou aktualizaci bootstrap kodu nahravat do /dev/null, pripadne nekam do souboru v /boot (protoze pro start systemu v tomhle pripade stejne neni treba).

pokud jde o odolny system, tak tohle je zrejme nedostatecne reseni.
optimalni kombinace je chainloader s kryptem na flashce.
hardwarovy read only zamek na cmos a bios
po bootu z flashky pripojit desifrovany /boot pockat do vytazeni flashky a po odpojeni pokracovat v bootu z desifrovaneho /boot
pripojit zbytek desifrovaneho systemu a odpojit boot
pokracovat initem
na spravna mista pridat verifikaci integrity
zrejme asi databazi balicku mit jeste na jinem oddilu a ten pripojit pred initem a provest verifikaci a odpojit.
atd atd.

[Jenda]

dotaz je zrejme na zpusob zvany chainloader, kdo pamatuje jeste lilo. s tim, ze prvni chain je na flashce a obsahuje crypto kanal predavani informaci k druhemu v chainu.

Dobře, a v čem je to lepší než mít na flashce celý /boot? Asi kvůli updatům. A mít na flashce systém s kexec?

Klíčové slovo GELI
https://en.wikipedia.org/wiki/Geli_%28software%29 a třeba ještě http://blog.pcbsd.org/2015/03/a-look-at-the-upcoming-features-for-10-1-2/

První odkaz popisuje něco jako cryptsetup na Linuxu. Druhý odkaz nepíše o full disk encryption.

[Karel]

dotaz je zrejme na zpusob zvany chainloader, kdo pamatuje jeste lilo. s tim, ze prvni chain je na flashce a obsahuje crypto kanal predavani informaci k druhemu v chainu.

Dobře, a v čem je to lepší než mít na flashce celý /boot? Asi kvůli updatům. A mít na flashce systém s kexec?

Klíčové slovo GELI
https://en.wikipedia.org/wiki/Geli_%28software%29 a třeba ještě http://blog.pcbsd.org/2015/03/a-look-at-the-upcoming-features-for-10-1-2/

První odkaz popisuje něco jako cryptsetup na Linuxu. Druhý odkaz nepíše o full disk encryption.

Takže se omlouvám za dezinformaci. Grub naběhne jako první, uvítá a zeptá se na heslo: "Attempting to decptrypt master key ... Enter passphrase for ..." Je možné, že to je v linuxu stejné/podobné jako cryptsetup - to jsem si ještě nezkoušel. Doporučuji si projet jejich pěkný obrázkový názorný průvodce instalací, kde píší  píší o "full disk encryption..." viz. http://www.linuxbsdos.com/2014/11/27/how-to-configure-full-disk-encryption-in-pc-bsd-10-1/  a mechanismus/klíčové slovo je GELI

[Sten]

Nicméně nezapomínej, že když dáš počítač z ruky, stále tu nějaká rizika jsou (i když je to dost dobré řešení oproti ostatním). Útočník ti může do počítače nainstalovat HW keylogger nebo upravit BIOS/UEFI, aby ukradl heslo k disku nebo rovnou data.

Anebo provede velmi jednoduchý a rychlý cold boot attack a heslo vytáhne z paměti.

Pokud uz budu resit fyzickej utok, tak samosebou mam case s detekci otevreni (a to nejen nejakym cumprdlikem, ale minimalne nejakou mrizkou po celym krytu), takze jakmile nekdo narusi integritu, prvni co se stane je likvidace klice.

Stačí nejdřív odpojit proud a až potom otevřít case a chladit paměti. I kdyby nevytáhli klíč přesně, přibližná podoba klíče je více než dostatečná pro následný brute-force.

[Josef]

Stačí nejdřív odpojit proud a až potom otevřít case a chladit paměti. I kdyby nevytáhli klíč přesně, přibližná podoba klíče je více než dostatečná pro následný brute-force.

Nelze držet klíč jen v registrech/cachi procesoru?

[Jenda]

Stačí nejdřív odpojit proud a až potom otevřít case a chladit paměti. I kdyby nevytáhli klíč přesně, přibližná podoba klíče je více než dostatečná pro následný brute-force.

A už se to někomu povedlo s DDR3/DDR4? Četl jsem že mají buňky tak malé, že to není prakticky realizovatelné ani s chlazením předem, natož pak vypnout za tepla a až pak otevřít case. https://brmlab.cz/pipermail/brmlab/2014-December/007864.html

Spíš bych se bál o nějaké obejití case-open detekce a následné připojení zařízení do PCIe, které si vynutí DMA přístup. Nebo o crashnutí kernelu pomocí USB zařízení (povedlo se mi omylem) po kterém zůstane viset, ale mechanismus na detekci už nefunguje.

[Sten]

Nelze držet klíč jen v registrech/cachi procesoru?

Teoreticky, praktická a ověřená implementace ale AFAIK zatím není. Spíš se to řeší pomocí TPM (OP ale uváděl, že jej nemá).

A už se to někomu povedlo s DDR3/DDR4? Četl jsem že mají buňky tak malé, že to není prakticky realizovatelné ani s chlazením předem, natož pak vypnout za tepla a až pak otevřít case. https://brmlab.cz/pipermail/brmlab/2014-December/007864.html

Hmm, tohle je hodně zajímavé. Ale na konci se tam píše, že není jasné, jestli za to může konstrukce DDR3, což by obejít nešlo, nebo řadič, což by teoreticky obejít šlo.

Pořád to ale jde obejít při vyvolání panic resetu (pokud je nastaven —  na serverech bývá, aby při kernel panic nikdo nemusel jezdit do serverovny), protože to je warn boot, nicméně je to samozřejmě o dost složitější.

Spíš bych se bál o nějaké obejití case-open detekce a následné připojení zařízení do PCIe, které si vynutí DMA přístup. Nebo o crashnutí kernelu pomocí USB zařízení (povedlo se mi omylem) po kterém zůstane viset, ale mechanismus na detekci už nefunguje.

Anebo pomocí FireWire či Thunderboltu, pokud tam jsou, prostě přečíst celou paměť

[Mirek Prýmek]

Odbočka
Pánové nechci rušit, chci nabídnout  ... V PCBSD (a možná/jistě i jinde...) je možnost zašifrovat CELÝ disk a dokud nezadám správné heslo  a nerozešifruje si to (co?celý disk sectory), tak mě to nepustí (pokud se nepletu) narozdíl od jiných distrubucí, OS apd. ani do grubu / dál. Co vy na to?

Že se pleteš Pokud myslíš geli, tak to je kernel modul, který se musí natáhnout z disku, který tímpádem nesmí být šifrovaný. Čili máš nešifrovanou partition, kde je /boot. Pokud myslíš nějaký jiný způsob, tak by to chtělo link...

S GPT by to asi nějak implementovat šlo, místo gptzfsboot by se tam nahrál nějaký gptzfscryptoboot, ale nevím o tom, že by to někdo implementoval.