Il file system sui dispositivi Board, Desk, e Room Series viene crittografato utilizzando Linux Unified Key Setup (LUKS), lo standard per la crittografia del disco rigido Linux. La chiave di crittografia del file system è salvata su NVRAM o NOR-Flash. Durante un ripristino delle impostazioni di fabbrica, la chiave viene sovrascritta e non può essere recuperata rendendo tutto il contenuto del disco illeggibile. Ciò rende il ripristino delle impostazioni di fabbrica un metodo sicuro per eliminare ed eliminare i dati in conformità con US DOD 5220.22M e NIST 800-88r1.

Durante un ripristino delle impostazioni di fabbrica:

  • I registri delle chiamate vengono eliminati

  • Le passphrase vengono reimpostate per impostazione predefinita

  • Tutti i parametri del dispositivo vengono reimpostati sui valori predefiniti

  • Tutti i file caricati sul dispositivo vengono eliminati

  • L'immagine del software precedente (inattiva) viene eliminata

  • I tasti di opzione non sono interessati

Non è possibile annullare un ripristino delle impostazioni di fabbrica. Prima di iniziare, assicurarsi che sia necessario farlo.

Si consiglia di utilizzare l'interfaccia Web o l'interfaccia utente per ripristinare le impostazioni di fabbrica del dispositivo. Prima di eseguire un ripristino delle impostazioni di fabbrica, è necessario eseguire il backup dei file di registro, delle configurazioni e degli elementi personalizzati del dispositivo. In caso contrario, questi dati andranno perduti. Fare riferimento alla Guida all'amministrazione per informazioni sui diversi modi per eseguire il backup e il ripristino del dispositivo.

NIST 800-88R1

Lo standard NIST 800-88r1 specifica tre livelli di sanificazione:

  • Clean: Proteggiti dalle tecniche di recupero non invasive

  • Purge: rendere impossibile il recupero dei dati

  • Distruggi: rendi impossibile il recupero dei dati e impedisci l'uso futuro

La sezione 2.6 dello standard parla dell'uso della cancellazione crittografica (CE) e di come può essere applicata per soddisfare il livello di eliminazione.

Le sezioni 2.6.1 e 2.6.2 elencano le condizioni per (non) prendere in considerazione la CE:

  • Non utilizzare CE per eliminare i supporti se la crittografia è stata abilitata dopo che i dati sensibili sono stati memorizzati sul dispositivo senza essere stati prima disinfettati.

  • Non utilizzare CE se non è noto se i dati sensibili sono stati memorizzati sul dispositivo senza essere disinfettati prima della crittografia.

  • Considerare l'utilizzo di CE quando tutti i dati destinati a CE vengono crittografati prima dell'archiviazione sul supporto (inclusi i dati e le copie virtualizzate).

  • Prendi in considerazione l'utilizzo di CE quando conosciamo le posizioni sul supporto in cui è memorizzata la chiave di crittografia (sia essa la chiave di crittografia dei dati di destinazione o una chiave di avvolgimento associata) e possiamo disinfettare tali aree utilizzando la tecnica di sanificazione specifica del supporto appropriata, garantendo che venga indirizzata la posizione effettiva sul supporto in cui è memorizzata la chiave.

  • Prendi in considerazione l'utilizzo di CE quando possiamo sapere che tutte le copie delle chiavi di crittografia utilizzate per crittografare i dati di destinazione sono disinfettate.

  • Prendi in considerazione l'utilizzo di CE quando le chiavi di crittografia dei dati di destinazione sono, a loro volta, crittografate con una o più chiavi di wrapping e siamo sicuri di poter disinfettare le chiavi di wrapping corrispondenti.

  • Considerare l'utilizzo di CE quando siamo sicuri della capacità dell'utente di identificare e utilizzare chiaramente i comandi forniti dal dispositivo per eseguire l'operazione CE.

In RoomOS, i file system crittografati utilizzati per i dati dei clienti vengono configurati e crittografati all'inizio dell'avvio iniziale, prima della creazione di qualsiasi dato sensibile. La chiave viene memorizzata come descritto sopra in eeprom (software precedente) o utilizzando i meccanismi dell'area di fiducia del SoC e può essere disinfettata in modo sicuro.

Non viene mai eseguito il backup della chiave e non esiste un meccanismo di deposito delle chiavi.

Con tutto questo in mente, Cisco afferma che il meccanismo di ripristino delle impostazioni di fabbrica in RoomOS è conforme al livello di eliminazione in NIST 800-88r1.

Crittografia dei dati dei clienti

Crittografia disco

I dispositivi utilizzano un dispositivo flash per l'archiviazione di massa, dove la cancellazione sicura è impossibile da garantire. Tutti i dati dei clienti sui dispositivi vengono quindi archiviati su file system crittografati e, quando viene eseguito un ripristino delle impostazioni predefinite, viene eliminata solo la chiave di crittografia, rendendo inaccessibili i dati dei clienti.

Per facilitare questo, creiamo un file opportunamente grande sulla flash principale e utilizziamo lo strumento standard Linux cryptsetup per creare un dispositivo di loopback. Su questo dispositivo creiamo un file system ext4 standard. I dettagli su dove memorizziamo la chiave di crittografia sono nella sezione successiva.

Il dispositivo loop viene creato utilizzando LUKS1 con una dimensione della chiave di 512 bit e il cifrario aes-xts-plain64:

 $ cryptsetup status /dev/mapper/config /dev/mapper/config è attivo ed è in uso. tipo: LUKS1 cifrario: AES-XTS-PLAIN64 Dimensione chiave: 512 bit Posizione chiave: DM-CRYPT Dispositivo: /dev/loop5 loop: /mnt/base/image1/rwfs/config.img dimensione del settore: 512 offset: 4096 dimensione dei settori: 61440 modalità settori: lettura/scrittura

Durante il normale funzionamento del dispositivo, il cryptsetup viene utilizzato per decrittografare i file system prima che vengano montati. Quando la chiave di crittografia viene eliminata, non è più possibile impostare il dispositivo loop e montare i file system.

La chiave di crittografia che usiamo è una lettura di 20 byte da /dev/urandom che è run-through sha1sum per ottenere una rappresentazione ascii. La chiave viene generata al primo avvio dopo un ripristino delle impostazioni di fabbrica e non cambia fino a quando non viene eseguito un nuovo ripristino delle impostazioni di fabbrica.

Protezione della chiave di crittografia dei dati

Utilizziamo due diverse chiavi di crittografia sui nostri dispositivi. Uno per la partizione /data all'interno del contenitore Android (per Microsoft MTR e Zoom) e uno per altri file system (utilizzato per la configurazione del cliente, carte da parati, registro chiamate, registri storici e così via).

Per la partizione /data in Android, la chiave privata è sempre stata archiviata in modo sicuro all'interno del confine Nvidia TrustZone o, su Room Navigator, crittografata utilizzando il meccanismo di crittografia integrato del SoC.

Fino a ce-11.25.x incluso, l'altra chiave è memorizzata in EEPROM. Mentre EEPROM è inaccessibile agli utenti che passano attraverso qualsiasi canale normale, può essere rimosso forzatamente dal dispositivo (insieme al disco flash) per decrittografare effettivamente il contenuto.

A partire da ce-11.26.x stiamo spostando la normale chiave di crittografia del file system su Nvidia Trusted Execution Environment (TEE) basato su ARM TrustZone [0], quindi la chiave non sarà possibile estrarre dal SoC Nvidia. Poiché l'unico modo (noto) per aggirare il processo di avvio sicuro è sostituire l'intero SoC Nvidia, che rimuoverebbe quindi la chiave, l'estrazione della chiave sarebbe limitata alla ricerca di vulnerabilità nel codice CE per ottenere una shell root con autorizzazioni sufficienti per ottenere la chiave.

Per Room Navigator la migrazione avverrà in una versione successiva.