Děkujeme za vaši zpětnou vazbu.

Souborový systém na zařízeních Board, Desk a Room Series je šifrován pomocí Linux Unified Key Setup (LUKS), což je standard pro šifrování pevného disku Linux. Šifrovací klíč systému souborů je uložen buď v 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 čištění dat v souladu s US DOD 5220.22M a NIST 800-88r1.

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

• Protokoly hovorů jsou smazány

• Heslové fráze jsou resetovány 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í, jsou smazány

• Předchozí (neaktivní) obraz softwaru je smazán

• Option klíče 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

Norma NIST 800-88r1 specifikuje tři úrovně dezinfekce:

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

• Čištění: Z nemožnit obnovu dat

• Zničit: Z nemožnit obnovu dat a zabránit budoucímu použití

Oddíl 2.6 normy hovoří o použití Cryptographic Erase (CE) a o tom, jak jej lze použít ke splnění úrovně Purge.

V oddílech 2.6.1 a 2.6.2 jsou uvedeny podmínky, kdy (ne) brát v úvahu CE:

• Nepoužívejte CE k čištění média, pokud bylo šifrování povoleno poté, co byla v zařízení uložena citlivá data, aniž by byla nejprve dezinfikována.

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

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

• Zvažte použití CE, pokud známe umístění (místa) na médiu, kde je uložen šifrovací klíč (ať už jde o šifrovací klíč cílových dat nebo přidružený klíč pro balení) a můžeme tyto oblasti dezinfikovat pomocí příslušné techniky sanitace specifické pro média a zajistit, aby bylo 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ě zašifrovány jedním nebo více balicími klíči a jsme přesvědčeni, že můžeme dezinfikovat odpovídající balicí klíče.

• Zvažte použití CE, pokud jsme přesvědčeni o schopnosti uživatele jasně identifikovat a použít příkazy poskytované zařízením k provedení operace CE.

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

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

S ohledem na to vše společnost Cisco tvrdí, že mechanismus obnovení továrního nastavení v RoomOS je v souladu s úrovní Purge 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í. Veškerá zákaznická data na zařízeních jsou proto uložena v šifrovaných souborových systémech a při obnovení továrních výchozích hodnot je smazán 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 pomocí standardního Linuxového nástroje cryptsetup vytvoříme zařízení pro zpětnou smyčku. Na tomto zařízení vytvoříme standardní souborový systém ext4. Podrobnosti o tom, kam ukládáme šifrovací klíč, jsou v další části.

Smyčkové zařízení je vytvořeno pomocí LUKS1 s velikostí klíče 512 bitů a šifrou aes-xts-plain64:

 $ cryptsetup status /dev/mapper/config
 /dev/mapper/config is active and is in use.
 type: LUKS1
 cipher: aes-xts-plain64
 keysize: 512 bits
 key location: dm-crypt
 device: /dev/loop5
 loop: /mnt/base/image1/rwfs/config.img
 sector size: 512
 offset: 4096 sectors
 size: 61440 sectors
 mode: read/write

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

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

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 další souborové systémy (používá se pro konfiguraci zákazníků, tapety, protokol hovorů, historické protokoly atd.).

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

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

Počínaje ce-11.26.x přesouváme běžný šifrovací klíč systému souborů 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. Protože jediným (známým) způsobem, jak obejít proces bezpečného spouštění, 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.

Migrace bude v novější verzi. Room Navigator