Das Dateisystem auf Geräten der Board-, Desk- und Room-Serie wird mit Linux Unified Key Setup (LUKS), dem Standard für die Verschlüsselung von Linux-Festplatten, verschlüsselt. Der Verschlüsselungscode für das Dateisystem wird entweder im NVRAM oder im NOR-Flash gespeichert. Während einer Zurücksetzung auf die Werkseinstellungen wird der Code überschrieben und kann nicht wiederhergestellt werden, sodass alle Daten auf der Festplatte unlesbar werden. Dies macht das Zurücksetzen auf die Werkseinstellungen zu einer sicheren Methode zum Löschen und Bereinigen von Daten in Übereinstimmung mit US DOD 5220.22M und NIST 800-88r1.

Während einer Zurücksetzung auf die Werkseinstellungen passiert Folgendes:

  • Alle Anrufprotokolle werden gelöscht.

  • Passphrasen werden auf den Standardwert zurückgesetzt.

  • Alle Geräteparameter werden auf die Standardwerte zurückgesetzt.

  • Alle Dateien, die auf das Gerät hochgeladen wurden, werden gelöscht.

  • Das vorherige (inaktive) Software-Image wird gelöscht.

  • Optionscodes sind nicht betroffen.

Eine Zurücksetzung auf die Werkseinstellungen kann nicht rückgängig gemacht werden. Stellen Sie sicher, dass die Zurücksetzung erforderlich ist, bevor Sie beginnen.

Wir empfehlen, die Weboberfläche oder die Benutzeroberfläche zu verwenden, um das Gerät auf die Werkseinstellungen zurückzusetzen. Sie sollten die Protokolldateien, Konfigurationen und benutzerdefinierten Elemente des Geräts sichern, bevor Sie eine Zurücksetzung auf die Werkseinstellungen durchführen. Andernfalls gehen die Daten verloren. Informationen zu den verschiedenen Möglichkeiten zum Sichern und Zurücksetzen Ihres Geräts finden Sie im Administrationshandbuch .

NIST 800-88r1

Der NIST-Standard 800-88r1 spezifiziert drei Stufen der Desinfektion:

  • Sauber: Schutz vor nicht-invasiven Wiederherstellungstechniken

  • Bereinigung: Machen Sie die Datenwiederherstellung unmöglich

  • Zerstören: Machen Sie die Datenwiederherstellung unmöglich und verhindern Sie die zukünftige Verwendung

Abschnitt 2.6 der Norm befasst sich mit der Verwendung von Cryptographic Erase (CE) und wie es angewendet werden kann, um die Bereinigungsstufe zu erfüllen.

In den Abschnitten 2.6.1 und 2.6.2 sind die Bedingungen aufgeführt, unter denen CE (nicht) berücksichtigt werden sollte:

  • Verwenden Sie CE nicht zum Löschen von Medien, wenn die Verschlüsselung aktiviert wurde, nachdem vertrauliche Daten auf dem Gerät gespeichert wurden, ohne zuvor bereinigt worden zu sein.

  • Verwenden Sie CE nicht, wenn nicht bekannt ist, ob vertrauliche Daten auf dem Gerät gespeichert wurden, ohne vor der Verschlüsselung bereinigt zu werden.

  • Ziehen Sie die Verwendung von CE in Betracht, wenn alle für CE vorgesehenen Daten vor der Speicherung auf dem Medium verschlüsselt werden (einschließlich der Daten sowie virtualisierter Kopien).

  • Erwägen Sie die Verwendung von CE, wenn wir die Speicherorte auf dem Medium kennen, an denen der Verschlüsselungsschlüssel gespeichert ist (sei es der Verschlüsselungsschlüssel der Zieldaten oder ein zugehöriger Wrapping-Schlüssel), und diese Bereiche mit der entsprechenden medienspezifischen Bereinigungstechnik bereinigen können, um sicherzustellen, dass die tatsächliche Position auf dem Medium, an der der Schlüssel gespeichert ist, adressiert wird.

  • Erwägen Sie die Verwendung von CE, wenn wir wissen können, dass alle Kopien der Verschlüsselungsschlüssel, die zum Verschlüsseln der Zieldaten verwendet werden, bereinigt sind.

  • Erwägen Sie die Verwendung von CE, wenn die Verschlüsselungsschlüssel der Zieldaten selbst mit einem oder mehreren Wrapping-Schlüsseln verschlüsselt sind und wir zuversichtlich sind, dass wir die entsprechenden Wrapping-Schlüssel bereinigen können.

  • Ziehen Sie die Verwendung von CE in Betracht, wenn wir davon überzeugt sind, dass der Benutzer in der Lage ist, die vom Gerät bereitgestellten Befehle zum Ausführen des CE-Vorgangs eindeutig zu identifizieren und zu verwenden.

In RoomOS werden die verschlüsselten Dateisysteme, die für Kundendaten verwendet werden, früh im ersten Start eingerichtet und verschlüsselt, bevor sensible Daten erstellt werden. Der Schlüssel wird, wie oben beschrieben, entweder im EEPROM (ältere Software) oder unter Verwendung der Trust-Zone-Mechanismen des SoC gespeichert und kann sicher desinfiziert werden.

Der Schlüssel wird nie gesichert und es gibt keinen Schlüsselhinterlegungsmechanismus.

Vor diesem Hintergrund behauptet Cisco, dass der Mechanismus zum Zurücksetzen auf die Werkseinstellungen in RoomOS mit der Löschstufe in NIST 800-88r1 konform ist.

Verschlüsselung von Kundendaten

Festplattenverschlüsselung

Die Geräte verwenden ein Flash-Gerät für die Massenspeicherung, bei dem eine sichere Löschung nicht gewährleistet werden kann. Alle Kundendaten auf den Geräten werden daher in verschlüsselten Dateisystemen gespeichert, und wenn ein Zurücksetzen auf die Werkseinstellungen durchgeführt wird, wird nur der Verschlüsselungsschlüssel gelöscht, wodurch auf die Kundendaten nicht mehr zugegriffen werden kann.

Um dies zu erleichtern, erstellen wir eine entsprechend große Datei auf dem Hauptflash und verwenden das Standard-Linux-Tool cryptsetup, um ein Loopback-Gerät zu erstellen. Auf diesem Gerät erstellen wir ein Standard-ext4-Dateisystem. Details dazu, wo wir den Verschlüsselungsschlüssel speichern, finden Sie im nächsten Abschnitt.

Das Loop-Gerät wird mit LUKS1 mit einer Schlüssellänge von 512 Bit und der Verschlüsselung aes-xts-plain64 erstellt:

 $ cryptsetup Status /dev/mapper/config /dev/mapper/config ist aktiv und wird verwendet. Typ: LUKS1 Chiffre: AES-XTS-Plain64 Schlüsselgröße: 512 Bit Schlüsselort: dm-crypt Gerät: /dev/loop5 Schleife: /mnt/base/image1/rwfs/config.img Sektorgröße: 512 Offset: 4096 Sektorgröße: 61440 Sektormodus: Lesen/Schreiben

Während des regulären Betriebs des Geräts wird das cryptsetup verwendet, um die Dateisysteme zu entschlüsseln, bevor sie eingehängt werden. Wenn der Verschlüsselungsschlüssel gelöscht wird, ist es nicht mehr möglich, das Loop-Gerät einzurichten und die Dateisysteme zu mounten.

Der Verschlüsselungsschlüssel, den wir verwenden, ist ein Lesevorgang von 20 Bytes aus /dev/urandom, der durch sha1sum ausgeführt wird, um eine ASCII-Darstellung zu erhalten. Der Schlüssel wird beim ersten Start nach dem Zurücksetzen auf die Werkseinstellungen generiert und ändert sich erst, wenn ein erneuter Werksreset durchgeführt wird.

Schutz des Datenverschlüsselungsschlüssels

Wir verwenden zwei verschiedene Verschlüsselungsschlüssel auf unseren Geräten. Eine für die /data-Partition innerhalb des Android-Containers (für Microsoft MTR und Zoom) und eine für andere Dateisysteme (wird für die Kundenkonfiguration, Tapeten, Anrufprotokolle, Verlaufsprotokolle usw. verwendet).

Für die /data-Partition in Android wurde der private Schlüssel immer sicher innerhalb der Nvidia TrustZone-Grenze gespeichert oder im Room Navigator mit dem integrierten Verschlüsselungsmechanismus des SoC verschlüsselt.

Bis einschließlich ce-11.25.x wird der andere Schlüssel im EEPROM gespeichert. Während EEPROM für Benutzer, die über einen normalen Kanal kommen, nicht zugänglich ist, kann es gewaltsam vom Gerät (zusammen mit der Flash-Disk) entfernt werden, um den Inhalt tatsächlich zu entschlüsseln.

Beginnend mit ce-11.26.x verschieben wir den regulären Dateisystem-Verschlüsselungsschlüssel in die Nvidia Trusted Execution Environment (TEE), die auf ARM TrustZone[0] basiert, sodass der Schlüssel nicht aus dem Nvidia-SoC extrahiert werden kann. Da die einzige (bekannte) Möglichkeit, den Secure Boot-Prozess zu umgehen, darin besteht, den gesamten Nvidia-SoC auszutauschen, der dann den Schlüssel entfernen würde, würde sich die Schlüsselextraktion darauf beschränken, Schwachstellen im CE-Code zu finden, um eine Root-Shell mit ausreichenden Berechtigungen zum Abrufen des Schlüssels zu erhalten.

Für Room Navigator wird die Migration in einer späteren Version erfolgen.