Grazie per il feedback.

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

Durante un ripristino delle impostazioni di fabbrica:

• I registri delle chiamate vengono eliminati

• Le passphrase vengono ripristinate ai valori predefiniti

• Tutti i parametri del dispositivo vengono ripristinati ai valori predefiniti

• Tutti i file che sono stati caricati sul dispositivo vengono eliminati

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

• I tasti di opzione non sono interessati

Non può annullare un ripristino delle impostazioni di fabbrica. Si assicuri che sia necessario farlo prima di iniziare.

NIST 800-88r1

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

• Pulito: proteggersi dalle tecniche di recupero non invasive

• Purge: rendere impossibile il recupero dei dati

• Distruggere: rendere impossibile il recupero dei dati e impedirne l'uso futuro

La sezione 2.6 dello standard parla dell'uso di Cryptographic Erase (CE) e di come può essere applicato per soddisfare il livello Purge.

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

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

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

• Prenda in considerazione l'utilizzo di CE quando tutti i dati destinati a CE sono crittografati prima dell'archiviazione sui supporti (inclusi i dati e le copie virtualizzate).

• Prenda in considerazione l'uso di CE quando conosciamo la posizione o le posizioni sul supporto in cui è archiviata la chiave di crittografia (che si tratti della chiave di crittografia dei dati di destinazione o di una chiave di wrapping associata) e possiamo disinfettare quelle aree utilizzando la tecnica di sanificazione appropriata specifica per il supporto, assicurando che la posizione effettiva sul supporto in cui è archiviata la chiave sia indirizzata.

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

• Prenda in considerazione l'utilizzo di CE quando le chiavi di crittografia dei dati di destinazione sono esse stesse crittografate con una o più chiavi di wrapping e siamo certi di poter disinfettare le chiavi di wrapping corrispondenti.

• Prenda in considerazione l'uso della CE quando siamo certi 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, prima della creazione di qualsiasi dato sensibile. La chiave viene archiviata come descritto sopra in eeprom (software precedente) o utilizzando i meccanismi della zona di fiducia del SoC e può essere disinfettata in modo sicuro.

La chiave non viene mai salvata e non esiste un meccanismo di deposito a garanzia delle chiavi.

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

Crittografia dei dati dei clienti

Crittografia del disco

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

Per facilitare ciò, creiamo un file di dimensioni adeguate sulla memoria flash principale e utilizziamo lo strumento Linux standard cryptsetup per creare un dispositivo di loopback. Su questo dispositivo creiamo un file system ext4 standard. I dettagli su dove archiviamo 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 codice 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

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

La chiave di crittografia che utilizziamo è una lettura di 20 byte da /dev/urandom che viene eseguita tramite sha1sum per ottenere una rappresentazione ascii. La chiave viene generata al primo avvio dopo il ripristino delle impostazioni di fabbrica e non cambia finché non viene eseguito un nuovo ripristino delle impostazioni di fabbrica.

Protezione delle chiavi di crittografia dei dati

Utilizziamo due diverse chiavi di crittografia sui nostri dispositivi. Una per la partizione /data all'interno del contenitore Android (per Microsoft MTR e Zoom) e una per altri file system (utilizzata per la configurazione del cliente, gli sfondi, il registro delle chiamate, i registri cronologici e così via).

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

Fino a ce-11.25.x incluso, l'altra chiave è memorizzata nella EEPROM. Sebbene la EEPROM sia inaccessibile agli utenti che arrivano attraverso qualsiasi canale normale, può essere rimossa forzatamente dal dispositivo (insieme al disco flash) per decrittografare effettivamente i contenuti.

A partire da ce-11.26.x stiamo spostando la normale chiave di crittografia del file system in un ambiente di esecuzione affidabile (TEE) Nvidia 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 si limiterebbe alla ricerca di vulnerabilità nel codice CE per ottenere una shell root con autorizzazioni sufficienti per ottenere la chiave.

Perché Room Navigator la migrazione sarà in una versione successiva.