Tak otázkou je, proč to děláš, před kým chráníš data, jaký přístup k té aplikaci má zákazník, co ta aplikace obecně umožňuje.
Přesně tak, tímhle je potřeba začít, ne dumáním nad logováním ssh.
- zkontrolujete zda jsou na cilovem RPI vsechny soubory potrebne pro odemceni LUKS nemodifikovane zakaznikem => tim zamezite podvrzeni skriptu nebo binarky
Nedovedu si teď úplně představit, jak to udělat dobře na nedůvěryhodném systému. Když budu dělat sha checksumy, jak zjístím, že samotná binárka sha256sum není modifikovaná? Ok, můžu si tam přes ssh nakopírovat svoji binárku, jak zjistím, že není jádro modifikováno tak, že mi pro checksum předhotí správné binárky, ale jinak použije kompromitované?
Jediný způsob, jak to udělat fakt dobře, o kterým vím, je TPM, který RasPi nemá.
- system se preda zakaznikovi
Btw, nebylo ani řečeno, co tohle přesně znamená. Zákazník má to RasPi v ruce? Má k němu ssh přístup? Na roota nebo uživatele? Má přístup jenom přes nějakou aplikaci? Je ta aplikace nějak auditovaná?
Riziko co mne napada:
- pokud ma zakaznik plnou kontrolu nad systemem, muze si vlozit do odemceneho LUKS svuj vlastni klic (ted z hlavy nevim zda je to treba pri uz otevrenem LUKSu autorizovat existujicim klicem nebo heslem)
No já hlavně úplně nechápu, jaký smysl by mělo LUKS otevřít a dá k němu uživateli plný přístup. Tak si celý obsah zkopíruje a dál klíč nepotřebuje... ...a jsme zpátky u toho, že se musí začít sepsáním toho, co proti komu chráním a jaké má potenciální útočník v ruce prostředky.