Klónozás

1. A megbízható platform modul (TPM) identitásának alapjai és a TCG specifikáció¶

A TPM egy kritikus biztonsági komponens, amely a platform integritásának és hitelességének hardveres gyökerét képezi. Ahhoz, hogy megvizsgáljuk a TPM-identitások klónozásának kockázatát virtuális és konténerizált környezetekben, először meg kell érteni azokat a kriptográfiai garanciákat, amelyeket egy fizikai TPM nyújt.

1.1. A hardveres megbízhatósági gyökér és a szabványosítás¶

A TPM egy biztonságos kriptoprocesszor, amely az ISO/IEC 11889 szabványt (jelenleg a TPM 2.0-t, amelyet 2015-ben publikáltak) implementálja. Fő célja, hogy hardveres megbízhatósági gyökeret biztosítson a platform hitelesítéséhez, az integritás ellenőrzéséhez és a titkosítási kulcsok biztonságos tárolásához (lepecsételéséhez). A TPM 2.0 specifikáció bevezetése kritikus fontosságú volt, különösen azóta, hogy olyan modern operációs rendszerek, mint a Windows 11, rendszerkövetelményként írják elő a használatát.

1.2. A megváltoztathatatlan identitás: A Jóváhagyási Kulcs (EK)¶

A TPM identitásának alapja a Jóváhagyási Kulcs (Endorsement Key, EK). Ez egy egyedi, aszimmetrikus kulcspár (EKPub/EKPriv), amelyet a gyártó generál és a chipen belül tárol el véglegesen. A kulcs ezen egyedisége és permanenciája az, ami garantálja a platform egyedi azonosságát. A TCG specifikáció szerint az EK nem migrálható, ami azt jelenti, hogy azt fizikailag nem lehet áthelyezni egy másik TPM-be.

Az EK két elsődleges célt szolgál: egyedileg azonosítja a TPM-et (és ezáltal a hozzá csatolt eszközt), valamint alapvető szerepet játszik a megbízhatóság igazolásában (attestation). A fizikai TPM-ek esetében az EK nem-migrálhatósága a legfőbb biztonsági tulajdonság. Ha ez a tulajdonság megsérül a virtualizáció során, és az EK duplikálódik, azzal sérül a kriptográfiai garancia.

1.3. Állapotmérés: Platform Konfigurációs Regiszterek (PCR-ek)¶

A TPM funkcionalitásának másik kulcseleme a Platform Konfigurációs Regiszterek (PCR-ek). Ezek olyan regiszterek, amelyek kriptográfiai méréseket (egyirányú hasheket) tárolnak a platform indítási állapotáról, beleértve a hardvert, a BIOS-t, az operációs rendszer betöltőjét és a kernelt. Ezek a mérések biztosítják, hogy a rendszer integritása megőrződjön, és senki ne tudja manipulálni a betöltési folyamatot.

A TPM által végzett kulcskezelés az adatok "lepecsételésén" (sealing) alapul. Az érzékeny adatok (például lemeztitkosítási kulcsok) lepecsételhetők bizonyos PCR-értékekhez. Ha a szoftverkonfiguráció megváltozik, a PCR-értékek is változnak, és a lepecsételt adatok nem fejthetők vissza, ezáltal kikényszerítve a rendszer integritását a kulcsok felszabadítása előtt.

2. Virtuális TPM (vTPM) architektúra és identitásizoláció¶

A virtualizációs környezetekben a vTPM célja a fizikai TPM egyedi, nem migrálható identitásának replikálása szoftveres határok között. A vTPM-ek implementálása során azonban alapvető bizalmi és kezelési problémák merülnek fel, amelyek a klónozási kockázatok forrását jelentik.

2.1. A vTPM megvalósítási paradigmái¶

A vTPM egy virtuális TPM 2.0 chip, amely funkcionálisan azonos a fizikai megfelelőjével a vendég operációs rendszer szemszögéből.

1. VMware megvalósítás: A VMware vSphere-ben a vTPM implementációja a virtuális gép titkosítását (VM Encryption) használja. A vTPM-mel minden virtuális gép saját, egyedi és izolált TPM-mel rendelkezhet, amely képes támogatni olyan biztonsági funkciókat, mint a BitLocker. A vTPM megléte elengedhetetlen a Windows 11 biztonsági követelményeinek teljesítéséhez.
2. KVM/QEMU megvalósítás: KVM/QEMU környezetekben szoftveres TPM emulációt alkalmaznak, mint például az swtpm. Ez a megoldás a TCG PC Client TIS interfész specifikációt követi, elérhetővé téve egy memóriába leképzett I/O régiót a vendég operációs rendszer számára.

A vTPM-ek alapvető tervezési követelménye, hogy "minden VM saját, egyedi és izolált TPM-mel rendelkezzen". Továbbá, minden VM-nek egyedi vTPM példányszámhoz kell kapcsolódnia a kiszolgáló oldalon, megelőzve a csomaghamisítást és a jogosulatlan hozzáférést más vTPM-példányokhoz.

2.2. Virtuális Jóváhagyási Kulcs (vEK) generálása és a bizalmi áttolás¶

A fizikai EK-val ellentétben, amely a gyártás során égetődik a chipbe, a vTPM-ben a vEK a vTPM példány létrehozásakor generálódik.

1. vEK forrása és tárolása: VMware környezetben a vEK-t a VMware Certificate Authority (VMCA) vagy egy külső tanúsítványkezelő (CA) biztosítja. A vTPM persistent állapota (beleértve az EK-t és a lepecsételt kulcsokat) egy titkosított fájlban tárolódik (például a vSphere .nvram fájljában), amelyet a VMM kulcsszolgáltatója véd.
2. A bizalmi áttolás: A fizikai TPM-ről (pTPM) a virtuális TPM-re (vTPM) való áttérés alapvetően megváltoztatja a megbízhatósági gyökeret. A bizalom a fizikai chipről áttolódik a szoftveresen kezelt identitásra, amelyet a VMM kulcskezelési infrastruktúrája (VMCA/Kulcsszolgáltató) irányít. A vEK nem hardveresen égetett, hanem szoftveresen generált és titkosított fájlban tárolt. A biztonsági határ így teljes mértékben a VMM azon képességén nyugszik, hogy megvédje az állapotfájlt titkosító kulcsokat.
3. Migráció támogatása: Mivel minden vTPM-példányhoz egyedi EK generálódik, ez lehetővé teszi a kulcsokra támaszkodó TPM parancsok működését még azután is, hogy a virtuális TPM migrált (például élő migráció során), mivel a titkos EK-val történő visszafejtés továbbra is lehetséges.

2.3. A hypervisor kompromittálódásának kockázata¶

Mivel a vTPM állapota titkosítva van és a hypervisor kezeli, ha a hypervisor kompromittálódik, a titkosítás megkerülhető, és az egyedi identitás (a vEK) kinyerhető vagy duplikálható. Ez egy olyan kritikus pont, amely alapvetően érinti a klónozási kockázatokat.

Ezt a sebezhetőséget kezeli az a fejlődési irány, amikor a Bizalmas Számítástechnikai környezeteket (Confidential Computing), mint például az Azure bizalmas virtuális gépeket AMD SEV-SNP technológiával alkalmazzák. Ezekben a környezetekben a vTPM végrehajtása és tárolása hardveresen védett memóriaterületen belül történik, és a Platform Biztonsági Processzor (PSP) méri. Ez a megközelítés a bizalmi határt visszatolja a hardverbe, elszigetelve a vTPM-et a gazdakörnyezettől és a hypervisortól, garantálva az identitás izolációját.

3. A vTPM klónozás és duplikáció részletes elemzése¶

A felhasználói kérdés megválaszolásához elengedhetetlen annak vizsgálata, hogy a virtualizációs platformok hogyan kezelik a vTPM állapotot a másolás során. Az elemzés megerősíti, hogy a duplikáció a VMM-ek alapértelmezett működése volt, hacsak nem akadályozza meg explicit házirend.

3.1. Duplikáció a VMware vSphere-ben (Az alapértelmezett viselkedés)¶

A VMware vSphere korábbi verzióiban (6.7 és 7.x) a virtuális gép klónozása pontos replikát eredményezett, ami magában foglalta a vTPM duplikációját is.

1. Működési kényszerek: Ezt a duplikációt nagyrészt az operációs követelmények indokolták. Számos szervezet munkafolyamata megköveteli a VM pontos másolatát az alkalmazásfrissítésekből való helyreállításhoz, teszteléshez, biztonsági mentésekhez és a rugalmasság más formáihoz. Az EK-nak a klónozás során történő duplikálása lehetővé tette, hogy a BitLocker és más, TPM-re támaszkodó szolgáltatások működőképesek maradjanak az új példányon.
2. Azonossági kompromisszum: Azonban ez a viselkedés azt eredményezi, hogy két virtuális gép osztozik ugyanazon az egyedi virtuális identitáson (EK és lepecsételt kulcsok). Ez sérti a kriptográfiai garanciát, mivel az attesztációval már nem lehet egyértelműen azonosítani a hardveres gyökeret.

3.2. Enyhítés házirend bevezetésével (vSphere 8+)¶

A biztonsági és működési prioritások közötti mély konfliktus miatt a VMware vSphere 8-ban jelentős változtatást vezettek be a vTPM identitás kezelésére.

1. Választási lehetőség: A vSphere 8 bevezette a vTPM kiépítési házirendet (TPM Provisioning Policy), amely választási lehetőséget kínál a klónozás során: az EK-t vagy "másolni" (copy), vagy "cserélni" (replace) kell.
2. Adminisztratív ellenőrzés: Az alapértelmezett viselkedés a vCenter Server vpxd.clone.tpmProvisionPolicy paraméterével szabályozható. Ha ezt a paramétert "replace" (csere) értékre állítják, az új virtuális gép egyedi kriptográfiai identitást kap, biztosítva az elvárt izolációs elveket.
3. A csere következményei: Fontos megjegyezni, hogy az identitás cseréje egy magas súrlódású biztonsági lépés. Ha az adminisztrátor eltávolítja vagy kicseréli a vTPM eszközt egy Windows 11 VM-en, amely olyan funkciókat használ, mint a Windows BitLocker vagy a Windows Hello, ezek a funkciók leállnak, és megfelelő helyreállítási lehetőségek nélkül az adatok elvesztését kockáztathatja a felhasználó.

3.3. KVM/QEMU és Libvirt állapotkezelése¶

KVM környezetekben, ahol az swtpm szoftveres emulációt használják, a vTPM állapota jellemzően egy állandóan tárolt fájlban vagy Perzisztens Kötet Követelésben (Persistent Volume Claim, PVC) kerül elhelyezésre a QEMU konfigurációjában.

1. Klónozási kihívás: Az ilyen VM-ek klónozásakor a templát alapú klónozási folyamat könnyen duplikálhatja a perzisztens állapotot. Például az OKD Virtualization platformon kifejezetten figyelmeztetnek, hogy a vTPM-mel rendelkező VM klónozása vagy a pillanatképből történő létrehozása nem támogatott anélkül, hogy megfelelő lépéseket ne tennének az identitás egyediségének biztosítására.
2. Szükséges enyhítés: Az egyediség biztosításához a VMM vagy az orchestrációs logika (pl. KubeVirt) felelőssége, hogy minden klónozott VM példányhoz új, egyedi perzisztens tárolót (PVC) hozzon létre a vTPM állapotfájl számára. Ha a klónozási folyamat egyszerűen átmásolja a meglévő PVC-t, az identitás duplikálódik.

Az alábbi táblázat összefoglalja azokat az eseteket, amelyekben a vTPM identitás duplikációja előfordulhat, szembeállítva azt a hardveres alappal.

VM vTPM Identitás Kezelése Klónozás Során

A rendelkezésre álló adatokból levonható következtetés, hogy a vTPM biztonsága erősen függ a VMM-ek kulcskezelési képességeitől. Az operációs csapatok által preferált üzleti rugalmasság (gyors helyreállítás és pontos replikáció) és a biztonsági követelmények (egyedi, nem migrálható EK) közötti alapvető konfliktus vezetett ahhoz, hogy a VMM-szolgáltatók kezdetben a duplikációt választották alapértelmezettként. Ezért a biztonsági architektúráknak explicit módon felül kell bírálniuk ezeket a működési alapértelmezéseket az identitás integritásának fenntartása érdekében.

4. TPM integráció konténer környezetekben (Docker passthrough)¶

A konténerizáció eltérő biztonsági modellt használ, mint a virtualizáció. A fizikai TPM-nek a Docker konténerbe történő átadása (passthrough) azonnali választ ad arra a kérdésre, hogy az identitás egyedi marad-e: ebben a modellben a konténer-specifikus egyediség nem létezik.

4.1. A fizikai TPM áteresztési modellje¶

A Docker konténerek a gazdagép pTPM-eszközéhez (/dev/tpm0) vagy a TPM Erőforráskezelőjéhez (/dev/tpmrm0) férnek hozzá a --device jelző használatával.

1. Megosztott identitás: Ez a mechanizmus a konténert a gazdagép megosztott, egyedi kriptográfiai identitásához köti. A konténer hozzáfér a TPM funkciókhoz, de nem kap saját egyedi identitást. Az erőforráskezelő lehetővé teszi a pTPM multiplexelt elérését, általában úgy, hogy a felhasználót vagy folyamatot (pl. erősSwan VPN daemon) hozzáadják a jogosult csoportokhoz (pl. tss).
2. PCR lepecsételési kontextus hiánya: A legfőbb biztonsági hiányosság a megosztott biztonsági tartomány létrehozása. A pTPM PCR-jei a gazda operációs rendszer indítási állapotát mérik. Ha egy konténer a pTPM-et használja kulcsok lepecsételésére, azok a kulcsok a gazdagép integritási állapotához pecsételődnek le, nem pedig az efemer, konténer-specifikus állapothoz.

4.2. Az identitás- és állapotizoláció hiánya konténerekben¶

A Docker passthrough feláldozza az identitás izolációját. Míg a konténerek a kernel névterekre (namespaces) és a cgroup-okra támaszkodnak a folyamat elszigeteléséhez , a kriptográfiai megbízhatósági gyökér definíció szerint megosztott marad.

1. Gazdagéphez kötött sebezhetőség: A pTPM passthrough elsődleges biztonsági hibája az, hogy megosztott biztonsági tartományt hoz létre. Ha egy konténer titkosít egy titkot a PCR-ekhez, és a gazdagép platformjának integritása fennmarad, minden azonos gazdagépen futó konténer potenciálisan feloldhatja a kulcsokat (feltételezve a megfelelő jogosultságot), ami megszünteti a konténer-szintű adatszegmentációt.
2. Korlátozott használat: A passthrough modell elegendő lehet az olyan csak olvasható forgatókönyvekhez, ahol egy számítási feladatnak csak a gazdagépen szolgáltatott titkokhoz kell hozzáférnie (például az IoT Edge Eszközkiépítési Szolgáltatásához használt identitáskulcsokhoz). Azonban soha nem szabad használni olyan kulcsok generálására és biztonságos lepecsételésére, amelyeknek egyedieknek kell lenniük az adott konténerpéldányhoz. A passthrough elégtelen a magas biztonságú, több bérlős alkalmazásokhoz, mivel a PCR-ek a gazdagépre korlátozódnak, és minden konténer osztozik ezeken az indítási méréseken, így az egyedi lepecsételés gyakorlatilag lehetetlen.

5. Kriptográfiai izoláció és egyediség elérése konténer munkaterhelésekben¶

Ha egy konténernek szüksége van egyedi TPM-identitásra, a pTPM passthrough korlátait szoftveres emulációval kell orvosolni, amely visszaállítja az egyedi EK identitást és az állapotizolációt.

5.1. Szoftveres TPM emuláció konténerekhez¶

A pTPM passthrough korlátainak leküzdésére a konténerrendszereknek szoftveres TPM emulációt kell használniuk (vTPM proxy vagy swtpm). A cél, hogy "minden konténer saját egyedi, emulált, szoftveres TPM-et kapjon".

1. Izoláció és EK generálás: Ez a megközelítés minden konténerpéldányhoz egyedi EK-t és izolált NVRAM-ot generál, amelyet a konténeren kívül, biztonságosan tárolnak.
2. Példák: Olyan konténerplatformok, mint az Incus, szoftveres TPM-eket használnak a tanúsítványok lepecsételésére, biztosítva, hogy a kulcsok a konténeren kívül, de az adott példányhoz kötve legyenek tárolva. Ez a megoldás visszaállítja azt az elkülönített identitást, amelyet a hardveres passthrough szükségszerűen megszüntet.

5.2. Integritásmérés konténerkontextusokban¶

Bár kihívást jelent az izoláció (a megosztott kernel miatt), léteznek fejlett módszerek az integritás kontextuális mérésére.

1. Kontextuális PCR-ek (cPCR): Egyes kutatások azt vizsgálják, hogyan lehet módosítani a PCR kiterjesztési házirendeket úgy, hogy magukban foglalják a folyamat létrehozásával kapcsolatos mérési eredményeket (measure(createProcess)), ezzel definiálva egy "konténer PCR-t" (cPCR). Ez elméletileg lehetővé tenné a titkok lepecsételését az adott konténer futásidejű állapotához, a gazdagép állapotától elkülönítve.
2. IMA integráció: A Linux gazdagépeken az Integritásmérési Architektúra (IMA) képes a gazdagép TPM-jét használni PCR-ek kiterjesztésére fájlintegritási mérésekkel , de ennek zökkenőmentes és egyedi integrálása konténerenként továbbra is összetett.

Az alábbi táblázat összehasonlítja a különböző hozzáférési modellek biztonsági garanciáit és a klónozhatósági kockázatokat.

TPM Identitás és Klónozhatóság Összehasonlítás