Systém souborů na zařízeních Board, Desk a Room Series je šifrován pomocí Linux Unified Key Setup (LUKS), což je standard pro Linux šifrování pevného disku. Šifrovací klíč systému souborů je uložen v paměti NVRAM nebo NOR-flash. Během obnovení továrního nastavení je klíč přepsán a nelze jej obnovit, takže cokoli na disku je nečitelné. Díky tomu je obnovení továrního nastavení bezpečnou metodou mazání a mazání dat v souladu s US DOD 5220.22M a NIST 800-88r1.

Během obnovení továrního nastavení:

• Logy hovorů jsou odstraněny

• Přístupová hesla jsou resetována na výchozí

• Všechny parametry zařízení jsou resetovány na výchozí hodnoty

• Všechny soubory, které byly nahrány do zařízení, budou odstraněny

• Předchozí (neaktivní) obraz softwaru bude odstraněn

• Klávesy možností nejsou ovlivněny

Obnovení továrního nastavení nelze vrátit zpět. Ujistěte se, že je to nutné, než začnete.

NIST 800-88R1

Standard NIST 800-88R1 specifikuje tři úrovně dezinfekce:

• Čistý: Ochrana před neinvazivními technikami zotavení

• Vyčistit: Znemožnit obnovu dat

• Zničit: Učinit obnovu dat neproveditelnou a zabránit budoucímu použití

Oddíl 2.6 standardu hovoří o použití kryptografického vymazání (CE) a o tom, jak může být použit pro splnění úrovně mazání.

Oddíly 2.6.1 a 2.6.2 uvádějí podmínky, kdy (ne)uvažovat o CE:

• Nepoužívejte CE k vyčištění médií, pokud bylo šifrování povoleno po uložení citlivých dat do zařízení, aniž by bylo nejprve dezinfikováno.

• Nepoužívejte CE, pokud není známo, zda byla citlivá data uložena v zařízení, aniž by byla před šifrováním dezinfikována.

• Zvažte použití CE, když jsou všechna data určená pro CE šifrována před uložením na médium (včetně dat, stejně jako virtualizovaných kopií).

• Zvažte použití CE, když známe umístění na médiu, kde je uložen šifrovací klíč (ať už je to šifrovací klíč cílových dat nebo přidružený balicí klíč), a můžeme tyto oblasti dezinfikovat pomocí vhodné techniky sanitace specifické pro média, která zajistí, že bude adresováno skutečné umístění na médiu, kde je klíč uložen.

• Zvažte použití CE, když můžeme vědět, že všechny kopie šifrovacích klíčů, které se používají k šifrování cílových dat, jsou dezinfikovány.

• Zvažte použití CE, pokud jsou šifrovací klíče cílových dat samy o sobě šifrovány jedním nebo více balicími klíči a jsme si jisti, že můžeme dezinfikovat odpovídající balicí klíče.

• Zvažte použití CE, pokud jsme si jisti schopností uživatele jasně identifikovat a používat příkazy, které zařízení poskytuje k provedení operace CE.

V RoomOS jsou šifrované souborové systémy, které se používají pro zákaznická data, nastaveny a zašifrovány brzy při počátečním spuštění, před vytvořením jakýchkoli citlivých dat. Klíč je uložen tak, jak je popsáno výše, buď v eeprom (starší software) nebo pomocí mechanismů zóny důvěryhodnosti SoC a může být bezpečně dezinfikován.

Klíč není nikdy zálohován a neexistuje žádný mechanismus úschovy klíčů.

S ohledem na všechny tyto skutečnosti Cisco tvrdí, že mechanismus obnovení továrního nastavení v RoomOS je kompatibilní s úrovní mazání v NIST 800-88r1.

Šifrování zákaznických dat

Šifrování disku

Zařízení používají flash zařízení pro velkokapacitní úložiště, kde není možné zaručit bezpečné vymazání. Všechna zákaznická data na zařízeních jsou proto uložena v šifrovaných systémech souborů a při obnovení výchozího továrního nastavení se odstraní pouze šifrovací klíč, čímž se zákaznická data stanou nepřístupnými.

Abychom to usnadnili, vytvoříme vhodně velký soubor na hlavním flash a použijeme standardní Linux nástroj cryptsetup k vytvoření zařízení zpětné smyčky. Na tomto zařízení vytvoříme standardní souborový systém ext4. Podrobnosti o tom, kde ukládáme šifrovací klíč, jsou v další části.

Zařízení smyčky je vytvořeno pomocí LUKS1 s velikostí klíče 512 bitů a šifrou aes-xts-plain64:

 $ cryptsetup status /dev/mapper/config /dev/mapper/config je aktivní a používá. typ: LUKS1 šifra: aes-xts-plain64 velikost klíče: 512 bitů umístění klíče: dm-crypt zařízení: / dev / smyčka 5 smyčka: / mnt / base / image1 / rwfs / config.img velikost sektoru: 512 posun: 4096 sektory velikost: 61440 sektory režim: čtení / zápis

Během běžného provozu zařízení se cryptsetup používá k dešifrování souborových systémů před jejich připojením. Po odstranění šifrovacího klíče již není možné nastavit smyčku a připojit souborové systémy.

Šifrovací klíč, který používáme, je čtení 20 bajtů z / dev / urandom, který je spuštěn sha1sum pro získání reprezentace ASCII. Klíč je generován při prvním spuštění po obnovení továrního nastavení a nezmění se, dokud není provedeno nové obnovení továrního nastavení.

Ochrana šifrovacího klíče dat

Na našich zařízeních používáme dva různé šifrovací klíče. Jeden pro oddíl /data uvnitř kontejneru Android (pro Microsoft MTR a Zoom) a jeden pro ostatní souborové systémy (používá se pro konfiguraci zákazníka, tapety, protokol hovorů, historické protokoly atd.).

Pro oddíl /data v Android byl soukromý klíč vždy bezpečně uložen uvnitř hranice Nvidia TrustZone nebo v Room Navigatoru zašifrován pomocí vestavěného šifrovacího mechanismu SoC.

Až do ce-11.25.x včetně je druhý klíč uložen v EEPROM. Zatímco EEPROM je nepřístupný uživatelům, kteří přicházejí přes jakýkoli normální kanál, může být násilně odstraněn ze zařízení (spolu s flash diskem), aby skutečně dešifroval obsah.

Počínaje ce-11.26.x přesouváme běžný šifrovací klíč souborového systému do důvěryhodného spouštěcího prostředí Nvidia (TEE) založeného na ARM TrustZone[0], takže klíč nebude možné extrahovat z Nvidia SoC. Vzhledem k tomu, že jediným (známým) způsobem, jak obejít zabezpečený spouštěcí proces, je nahradit celý Nvidia SoC, který by pak klíč odstranil, extrakce klíče by byla omezena na nalezení zranitelností v kódu CE, aby se získal kořenový shell s dostatečnými oprávněními k získání klíče.

Pro Room Navigator bude migrace provedena v novější verzi.