Někdy se rozhlížím po tématu, o kterém bych mohl psát, a uvědomuji si, že existuje jedno, o kterém předpokládám, že jsem ho probral, ale při hledání zjistím, že ne. Jedním z těchto témat je měřené spouštění a důvěryhodné spouštění – někdy mylně označované jako „bezpečné spouštění“. Existují specifické postupy, které používají tyto výrazy s velkými písmeny (např. Secure Boot), kterým se v tomto článku pokusím vyhnout. Víc mě zajímají generické procesy – a velký potenciální pád – než se snažit jít do detailů specifik. Následuje (silně upravený) úryvek z mé připravované knihy o důvěře ve výpočetní techniku a cloud pro Wiley.
Další zdroje pro Linux
- Cheat pro příkazy Linuxu
- Cheat sheet pro pokročilé příkazy systému Linux
- Bezplatný online kurz:Technický přehled RHEL
- Síťový cheat pro Linux
- Cheat sheet SELinux
- Cheat pro běžné příkazy pro Linux
- Co jsou kontejnery systému Linux?
- Naše nejnovější články o Linuxu
Chcete-li porozumět tomu, čeho je cílem měřeného spouštění a důvěryhodného spouštění dosáhnout, podívejte se na zásobník virtualizace Linuxu:součásti, které spouštíte, pokud chcete na počítači se systémem Linux používat virtuální stroje (VM). Tento popis je pravděpodobně příliš zjednodušený, ale (jak jsem poznamenal výše) mě nezajímají podrobnosti, ale to, čeho se snažím dosáhnout. Zaměřím se na spodní čtyři vrstvy (na poměrně jednoduché úrovni abstrakce):CPU/management engine; BIOS/EFI; firmware; a hypervisor, ale budu také uvažovat o vrstvě jen nad CPU/management engine, který vkládá modul Trusted Platform Module (TPM) a některé pokyny k provedení jednoho ze dvou procesů (měřené spouštění a důvěryhodný boot ). Jakmile se systém spustí, spustí se TPM a začne pracovat. Mohou být také použity alternativní kořeny důvěry, jako jsou hardwarové bezpečnostní moduly (HSM), ale ve svém příkladu použiji TPM, nejběžnější příklad v této souvislosti.
V obou případech (důvěryhodné spouštění a měřené spouštění) začíná základní tok tím, že TPM provádí měření vrstvy BIOS/EFI. Toto měření zahrnuje kontrolu binárních instrukcí, které má tato vrstva provést, a vytvoření kryptografického hashu binárního obrazu. Vytvořený hash je pak uložen v jednom z několika „slotů“ Platform Configuration Register (PCR) v TPM. Lze je chápat jako části paměti, které lze později číst – buď TPM pro jeho účely, nebo entitami mimo TPM –, ale to nelze po jejich zapsání změnit. Tyto části paměti jsou chráněny integritou od okamžiku, kdy byly původně zapsány. To poskytuje záruky, že jakmile TPM zapíše hodnotu do PCR, lze ji považovat za konstantní po celou dobu životnosti systému až do vypnutí nebo restartu.
Po změření vrstvy BIOS/EFI se změří další vrstva (firmware). V tomto případě je výsledný hash zkombinován s předchozím hashem (který byl uložen ve slotu PCR) a poté také uložen do slotu PCR. Proces pokračuje, dokud nejsou změřeny všechny vrstvy zapojené do procesu a dokud nejsou uloženy výsledky hashů. Existují (někdy poměrně složité) procesy pro nastavení původních hodnot TPM (pro jednoduchost jsem v procesu vynechal některé nízkoúrovňové kroky) a pro povolení (doufejme autorizovaných) změn vrstev pro upgrade nebo bezpečnostní záplaty. , například. Tento proces „měřeného spouštění“ umožňuje entitám dotazovat se na TPM po dokončení procesu a kontrolovat, zda hodnoty ve slotech PCR odpovídají očekávaným hodnotám, předem vypočítaným s verzemi „známého dobrého“ různých vrstev – tzn. , předem zkontrolované verze, jejichž původ a integrita již byly stanoveny.
Existují různé protokoly, které stranám umožňují externí do systému, aby zkontroloval hodnoty (např. prostřednictvím síťového připojení), o kterých TPM ověří, že jsou správné:proces přijímání a kontroly takových hodnot z externího systému je známý jako "vzdálené ověřování."
Tento proces – měřené spouštění – vám umožňuje zjistit, zda jsou základy vašeho systému – nejnižší vrstvy – takové, jaké si myslíte, že jsou. Ale co když nejsou? Měřené spouštění (nepřekvapivě, vzhledem k názvu) měří, ale neprovádí žádné další akce.
Alternativa, „důvěryhodná bota“, jde ještě o krok dále. Když se provede důvěryhodný proces spouštění, proces nejen změří každou hodnotu, ale zároveň provede kontrolu proti známé (a očekávané!) dobré hodnotě. Pokud kontrola selže, proces se zastaví a zavádění systému se nezdaří. Může to znít jako poněkud extrémní přístup k systému, ale někdy je to naprosto správný. Tam, kde mohl být zvažovaný systém kompromitován – což je jeden z pravděpodobných závěrů, který můžete vyvodit ze selhání důvěryhodného spouštěcího procesu – je lepší, aby nebyl dostupný vůbec, než aby běžel na základě chybných očekávání.
To vše je velmi dobré, pokud jsem vlastníkem měřeného systému, zkontroloval jsem všechny různé měřené komponenty (a měření) a jsem šťastný, že to, co se spouští, je to, co chci. Ale co když například používám systém v cloudu nebo jakýkoli systém vlastněný a spravovaný někým jiným? V takovém případě svěřuji poskytovateli cloudu (nebo vlastníkovi/správci) dvě věci:
- Provádět všechna měření správně a hlásit mi správné výsledky
- Vytvářet něco, čemu bych měl v první řadě věřit
To je problém s nomenklaturou „důvěryhodná bota“ a co je ještě horší, „bezpečná bota“. Oba znamenají, že byla stanovena absolutní, objektivní vlastnost systému – je „důvěryhodný“ nebo „zabezpečený“ – když tomu tak zjevně není. Je zřejmé, že by bylo nespravedlivé očekávat od návrhářů takových procesů, že je pojmenují podle stavů selhání – „nedůvěryhodné spouštění“ nebo „nezabezpečené spouštění“ – ale pokud si nemohu být zcela jistý, že věřím, že vlastník systému provede krok dva zcela správně (a v mém nejlepším zájmu jako uživatele systému, spíše než jejich jako vlastníka), pak nemohu učinit žádná silnější tvrzení.
Existuje obrovské pokušení vzít systém, který prošel důvěryhodným bootovacím procesem, a označit jej jako „důvěryhodný systém“, když je nejlepší tvrzení, které můžete učinit, je, že konkrétní vrstvy měřené v měřeném a/nebo důvěryhodném zaváděcím procesu byly považovány za ty, které proces očekává, že budou přítomny. Takový proces neříká vůbec nic o vhodnosti vrstev poskytovat ujištění o chování ani o správnosti (nebo způsobilosti poskytovat ujištění o chování) jakýchkoli následujících vrstev nad nimi.
Je důležité poznamenat, že návrháři TPM mají zcela jasno, co se prosazuje, a že tvrzení o důvěře by měla být činěna opatrně a střídmě. Naneštěstí však složitost systémů, obecně nízká úroveň porozumění důvěře a složitost kontextu a tranzitivní důvěry velmi usnadňují návrhářům a implementátorům systémů udělat špatnou věc a předpokládat, že jakýkoli systém, který úspěšně provedl důvěryhodný spouštěcí proces lze považovat za „důvěryhodný“. Je také nesmírně důležité si uvědomit, že TPM jako hardwarové kořeny důvěry nabízejí jeden z nejlepších dostupných mechanismů pro vytvoření řetězce důvěry v systémy, které možná navrhujete nebo implementujete, a plánuji o nich brzy napsat článek.
- I když se ukázalo, že je to moc těžší, než byste čekali!
Tento článek byl původně publikován na stránkách Alice, Eve a Bob a je přetištěn se svolením autora.