System plików na urządzeniach z serii Board, Desk i Room jest szyfrowany przy użyciu Linux Unified Key Setup (LUKS), standardu szyfrowania dysku twardego Linux. Klucz szyfrowania systemu plików jest zapisywany w pamięci NVRAM lub NOR-flash. Podczas przywracania ustawień fabrycznych klucz zostaje nadpisany i nie można go odzyskać, co powoduje, że nic na dysku jest nieczytelne. Dzięki temu przywrócenie ustawień fabrycznych jest bezpieczną metodą usuwania i czyszczenia danych zgodnie z US DOD 5220.22M i NIST 800-88r1.

Podczas przywracania ustawień fabrycznych:

  • Dzienniki połączeń są usuwane

  • Hasła są resetowane do wartości domyślnych

  • Wszystkie parametry urządzenia zostaną przywrócone do wartości domyślnych

  • Wszystkie pliki przesłane na urządzenie zostaną usunięte

  • Poprzedni (nieaktywny) obraz oprogramowania zostanie usunięty

  • Nie ma to wpływu na opcji

Przywrócenia ustawień fabrycznych nie można cofnąć. Upewnij się, że jest to konieczne, zanim zaczniesz.

Zalecamy przywrócenie ustawień fabrycznych urządzenia za pomocą interfejsu internetowego lub interfejsu użytkownika. Przed przywróceniem ustawień fabrycznych należy wykonać kopię zapasową plików dziennika, konfiguracji i elementów niestandardowych urządzenia. w przeciwnym razie dane te zostaną utracone. Zapoznaj się z Podręcznikiem administratora, aby uzyskać informacje o różnych sposobach tworzenia kopii zapasowych i resetowania urządzenia.

NIST 800-88R1

Norma NIST 800-88r1 określa trzy poziomy sanityzacji:

  • Czystość: Ochrona przed nieinwazyjnymi technikami odzyskiwania

  • Oczyszczanie: Spraw, aby odzyskiwanie danych było niewykonalne

  • Zniszcz: Uniemożliwia odzyskiwanie danych i uniemożliwia ich wykorzystanie w przyszłości

Sekcja 2.6 standardu mówi o użyciu Cryptographic Erase (CE) i o tym, jak można go zastosować, aby osiągnąć poziom oczyszczania.

Sekcja 2.6.1 i 2.6.2 wymienia warunki, kiedy (nie) rozważyć CE:

  • Nie używaj CE do czyszczenia nośników, jeśli szyfrowanie zostało włączone po zapisaniu poufnych danych na urządzeniu bez uprzedniego oczyszczenia.

  • Nie używaj CE, jeśli nie wiadomo, czy poufne dane były przechowywane na urządzeniu bez oczyszczenia przed szyfrowaniem.

  • Rozważ użycie CE, gdy wszystkie dane przeznaczone dla CE są szyfrowane przed przechowywaniem na nośniku (w tym danych, a także zwirtualizowanych kopii).

  • Rozważ użycie CE, gdy znamy lokalizacje na nośniku, w których przechowywany jest klucz szyfrowania (czy to klucz szyfrowania danych docelowych, czy powiązany klucz opakowujący) i możemy oczyścić te obszary przy użyciu odpowiedniej techniki oczyszczania specyficznej dla nośnika, zapewniając, że rzeczywista lokalizacja na nośniku, na którym klucz jest przechowywany, jest adresowana.

  • Rozważ użycie CE, gdy wiemy, że wszystkie kopie kluczy szyfrowania używanych do szyfrowania danych docelowych są oczyszczone.

  • Rozważ użycie CE, gdy klucze szyfrowania danych docelowych są szyfrowane za pomocą jednego lub więcej kluczy opakowujących i jesteśmy pewni, że możemy oczyścić odpowiednie klucze opakowujące.

  • Rozważ użycie CE, gdy mamy pewność, że użytkownik jest w stanie wyraźnie zidentyfikować i użyć poleceń dostarczanych przez urządzenie do wykonania operacji CE.

W RoomOS zaszyfrowane systemy plików, które są używane dla danych klienta, są konfigurowane i szyfrowane na wczesnym etapie pierwszego rozruchu, przed utworzeniem jakichkolwiek poufnych danych. Klucz jest przechowywany w sposób opisany powyżej w eeprom (starsze oprogramowanie) lub przy użyciu mechanizmów strefy zaufania SoC i może być bezpiecznie oczyszczony.

Klucz nigdy nie jest archiwizowany i nie ma mechanizmu depozytu klucza.

Mając to wszystko na uwadze, Cisco zapewnia, że mechanizm przywracania ustawień fabrycznych w RoomOS jest zgodny z poziomem Purge w NIST 800-88r1.

Szyfrowanie danych klientów

Szyfrowanie dysku

Urządzenia wykorzystują urządzenie flash do pamięci masowej, gdzie bezpieczne usunięcie jest niemożliwe do zagwarantowania. Wszystkie dane klienta na urządzeniach są zatem przechowywane w zaszyfrowanych systemach plików, a po przywróceniu ustawień fabrycznych usuwany jest tylko klucz szyfrowania, co uniemożliwia dostęp do danych klienta.

Aby to ułatwić, tworzymy odpowiednio duży plik na głównym flashu i używamy standardowego narzędzia Linux cryptsetup do stworzenia urządzenia sprzężenia zwrotnego. Na tym urządzeniu tworzymy standardowy system plików ext4. Szczegółowe informacje na temat tego, gdzie przechowujemy klucz szyfrowania, znajdują się w następnej sekcji.

Urządzenie pętli jest tworzone przy użyciu LUKS1 z kluczem o rozmiarze 512 bitów i szyfrem aes-xts-plain64:

 $ Cryptsetup status /dev/mapper/config /dev/mapper/config jest aktywny i jest w użyciu. typ: Szyfr LUKS1: AES-XTS-PLAIN64 Rozmiar klucza: 512 bitów Lokalizacja klucza: dm-crypt Urządzenie: / dev / loop5 pętla: / mnt / base / image1 / rwfs / config.img Rozmiar sektora: 512 Przesunięcie: 4096 Rozmiar sektorów: 61440 Tryb sektorów: odczyt/zapis

Podczas normalnego działania urządzenia cryptsetup jest używany do odszyfrowywania systemów plików przed ich zamontowaniem. Po usunięciu klucza szyfrowania nie jest już możliwe skonfigurowanie urządzenia pętli i zamontowanie systemów plików.

Klucz szyfrowania, którego używamy, to odczyt 20 bajtów z / dev / urandom, który jest uruchamiany sha1sum w celu uzyskania reprezentacji ascii. Klucz jest generowany przy pierwszym uruchomieniu po przywróceniu ustawień fabrycznych i nie zmienia się, dopóki nie zostanie wykonane nowe przywrócenie ustawień fabrycznych.

Ochrona klucza szyfrowania danych

Na naszych urządzeniach używamy dwóch różnych kluczy szyfrowania. Jeden dla partycji /data wewnątrz kontenera Android (dla Microsoft MTR i Zoom) i jeden dla innych systemów plików (używany do konfiguracji klienta, tapet, dziennika połączeń, dzienników historycznych itd.).

W przypadku partycji /data w systemie Android klucz prywatny był zawsze bezpiecznie przechowywany w granicach Nvidia TrustZone lub, w Room Navigator, zaszyfrowany przy użyciu wbudowanego mechanizmu szyfrowania SoC.

Do ce-11.25.x włącznie, drugi klucz jest przechowywany w pamięci EEPROM. Podczas gdy EEPROM jest niedostępny dla użytkowników przechodzących przez jakikolwiek normalny kanał, można go siłą usunąć z urządzenia (wraz z dyskiem flash), aby faktycznie odszyfrować zawartość.

Począwszy od ce-11.26.x przenosimy zwykły klucz szyfrowania systemu plików do zaufanego środowiska wykonawczego Nvidii (TEE) opartego na ARM TrustZone[0], więc klucz nie będzie możliwy do wyodrębnienia z Nvidia SoC. Ponieważ jedynym (znanym) sposobem obejścia procesu bezpiecznego rozruchu jest zastąpienie całego SoC Nvidii, który następnie usunąłby klucz, ekstrakcja klucza ograniczyłaby się do znalezienia luk w kodzie CE, aby uzyskać powłokę główną z wystarczającymi uprawnieniami do uzyskania klucza.

W przypadku programu Room Navigator migracja nastąpi w nowszej wersji.