Dziękujemy za opinię.

System plików na urządzeniach z serii Board, Desk i Room jest szyfrowany przy użyciu systemu Linux Unified Key Setup (LUKS), standardu szyfrowania dysków twardych Linux. Klucz szyfrowania systemu plików jest zapisywany w NVRAM lub NOR-Flash. Podczas przywracania ustawień fabrycznych klucz jest nadpisywany i nie można go odzyskać, co sprawia, że cokolwiek na dysku jest nieczytelne. To sprawia, że przywrócenie ustawień fabrycznych jest bezpieczną metodą usuwania i usuwania 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 domyślnych

• Wszystkie parametry urządzenia są resetowane do wartości domyślnych

• Wszystkie pliki, które zostały przesłane do urządzenia, są usuwane

• Poprzedni (nieaktywny) obraz oprogramowania zostanie usunięty

• Klawisze opcji nie są dotknięte

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

NIST 800-88r1

Standard NIST 800-88r1 określa trzy poziomy odkażania:

• Czysty: Ochr ona przed nieinwazyjnymi technikami regeneracji

• Oczyszczanie: Uczyń odzyskiwanie danych niewykonalnym

• Zniszczenie: Uczyń odzyskiwanie danych niewykonalnym i zapobiegaj przyszłemu wykorzystaniu

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

Sekcje 2.6.1 i 2.6.2 wymieniają warunki, kiedy należy (nie) brać pod uwagę CE:

• Nie używaj CE do czyszczenia nośników, jeśli szyfrowanie było włączone po przechowywaniu poufnych danych na urządzeniu bez uprzedniej dezynfekcji.

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

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

• Rozważ użycie CE, gdy znamy lokalizację (y) na nośniku, na którym przechowywany jest klucz szyfrowania (czy to klucz szyfrowania danych docelowych, czy powiązany klucz zawijający) i możemy zdezynfekować te obszary za pomocą odpowiedniej techniki dezynfekcji specyficznej dla mediów, zapewniając, że rzeczywista lokalizacja na nośniku, na którym klucz jest przechowywany, jest adresowana.

• Rozważ użycie CE, gdy możemy wiedzieć, że wszystkie kopie kluczy szyfrujących używane do szyfrowania danych docelowych są dezynfekowane.

• Zastanów się nad użyciem CE, gdy klucze szyfrowania danych docelowych są same w sobie szyfrowane jednym lub kilkoma kluczami do pakowania i jesteśmy pewni, że możemy zdezynfekować odpowiednie klucze do pakowania.

• Rozważ użycie CE, gdy jesteśmy pewni, że użytkownik może jasno zidentyfikować i używać poleceń dostarczanych przez urządzenie do wykonania operacji CE.

W RoomOS zaszyfrowane systemy plików, które są używane do przetwarzania danych klientów, są konfigurowane i szyfrowane na początku początkowego 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żna go bezpiecznie odkażać.

Klucz nigdy nie jest kopiowany i nie ma kluczowego mechanizmu depozytu.

Mając to wszystko na uwadze, Cisco twierdzi, że mechanizm resetowania fabrycznego w RoomOS jest zgodny z poziomem Purge w NIST 800-88r1.

Szyfrowanie danych klienta

Szyfrowanie dysku

Urządzenia wykorzystują urządzenie flash do masowej pamięci masowej, gdzie nie można zagwarantować bezpiecznego usunięcia. Wszystkie dane klientów na urządzeniach są zatem przechowywane w zaszyfrowanych systemach plików, a po przywróceniu ustawień fabrycznych usuwany jest tylko klucz szyfrowania, co sprawia, że dane klienta są niedostępne.

Aby to ułatwić, tworzymy odpowiednio duży plik na głównym flashu i używamy standardowego narzędzia Linux cryptsetup do utworzenia urządzenia pętli zwrotnej. Na tym urządzeniu tworzymy standardowy system plików ext4. Szczegóły dotyczące miejsca przechowywania klucza szyfrowania znajdują się w następnej sekcji.

Urządzenie pętli jest tworzone przy użyciu LUKS1 o rozmiarze klucza 512 bitów i szyfru 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

Podczas regularnej pracy urządzenia Cryptsetup służy do odszyfrowania 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 szyfrujący, którego używamy, to odczyt 20 bajtów z /dev/urandom, który jest run-through sha1sum, aby uzyskać reprezentację 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 szyfrujących. Jeden dla partycji /data wewnątrz kontenera Android (dla Microsoft MTR i Zoom) i drugi 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 zawsze był bezpiecznie przechowywany wewnątrz granicy Nvidia TrustZone lub szyfrowany przy użyciu wbudowanego mechanizmu szyfrowania SoC. Room Navigator

Do ce-11.25.x włącznie drugi klucz jest przechowywany w EEPROM. Chociaż EEPROM jest niedostępny dla użytkowników przechodzących przez dowolny normalny kanał, można go przymusowo 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 Nvidia (TEE) opartego na ARM TrustZone [0], więc klucz nie będzie można wyodrębnić z Nvidia SoC. Ponieważ jedynym (znanym) sposobem obejścia bezpiecznego procesu rozruchu jest zastąpienie całego SoC Nvidia, który następnie usunąłby klucz, wyodrębnienie klucza byłoby ograniczone do znalezienia luk w kodzie CE, aby uzyskać powłokę root z wystarczającymi uprawnieniami do uzyskania klucza.

Mi Room Navigator gracja będzie w późniejszej wersji.