Das Dateisystem auf Geräten der Serien Board, Desk und Room wird mit Linux Unified Key Setup (LUKS) verschlüsselt, dem Standard für die Festplattenverschlüsselung von Linux. 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. Dadurch wird das Zurücksetzen auf die Werkseinstellungen zu einer sicheren Methode zum Löschen und Entfernen von Daten gemäß 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 Desinfektionsstufen:

  • Sauber: Vorsicht vor nichtinvasiven Wiederherstellungstechniken

  • Bereinigen: Datenwiederherstellung unmöglich machen

  • Zerstören: Die Datenwiederherstellung unmöglich machen und zukünftige Nutzung verhindern

Abschnitt 2.6 des Standards befasst sich mit der Verwendung von Cryptographic Erase (CE) und wie es angewendet werden kann, um die Bereinigungsstufe zu erreichen.

In den Abschnitten 2.6.1 und 2.6.2 sind die Bedingungen aufgeführt, unter denen CE in Betracht gezogen werden soll (und wann nicht):

  • 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 diese vorher zu bereinigen.

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

  • Erwägen Sie die Verwendung von CE, 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 der tatsächliche Speicherort auf dem Medium, an dem der Schlüssel gespeichert ist, angesprochen wird.

  • Erwägen Sie die Verwendung von CE, wenn Sie sicher sein 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 sicher sind, dass wir die entsprechenden Wrapping-Schlüssel bereinigen können.

  • Erwägen Sie die Verwendung von CE, wenn wir davon überzeugt sind, dass der Benutzer die vom Gerät bereitgestellten Befehle zum Ausführen des CE-Vorgangs eindeutig identifizieren und verwenden kann.

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

Der Schlüssel wird nie gesichert und es gibt keinen Mechanismus zur Hinterlegung des Schlüssels.

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

Verschlüsselung der Kundendaten

Festplattenverschlüsselung

Die Geräte verwenden einen Flash-Speicher zur Massenspeicherung, bei dem eine sichere Löschung nicht gewährleistet werden kann. Sämtliche Kundendaten auf den Geräten werden daher auf verschlüsselten Dateisystemen gespeichert und bei einer Rücksetzung auf die Werkseinstellungen wird lediglich der Verschlüsselungsschlüssel gelöscht, wodurch die Kundendaten unzugänglich werden.

Um dies zu ermöglichen, erstellen wir eine entsprechend große Datei auf dem Haupt-Flash und verwenden das Standardtool Linux 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üsselgröße von 512 Bit und der AES-XTS-Plain64-Chiffre 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üsselspeicherort: dm-crypt Gerät: /dev/loop5 Schleife: /mnt/base/image1/rwfs/config.img Sektorgröße: 512 Offset: 4096 Sektoren Größe: 61440 Sektoren Modus: Lesen/Schreiben

Während des regulären Betriebs des Geräts wird Cryptsetup verwendet, um die Dateisysteme zu entschlüsseln, bevor sie gemountet 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 von uns verwendete Verschlüsselungsschlüssel 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 Booten nach einem Werksreset generiert und ändert sich erst, wenn ein neuer Werksreset durchgeführt wird.

Schutz von Datenverschlüsselungsschlüsseln

Wir verwenden auf unseren Geräten zwei verschiedene Verschlüsselungsschlüssel. Eine für die /data-Partition im Container Android (für Microsoft MTR und Zoom) und eine für andere Dateisysteme (verwendet für Kundenkonfiguration, Hintergrundbilder, Anrufprotokoll, Verlaufsprotokolle usw.).

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 über normale Kanäle unzugänglich ist, kann es (zusammen mit der Flash-Disk) zwangsweise aus dem Gerät entfernt werden, um den Inhalt tatsächlich zu entschlüsseln.

Ab ce-11.26.x verschieben wir den regulären Dateisystem-Verschlüsselungsschlüssel in die vertrauenswürdige Ausführungsumgebung (TEE) von Nvidia basierend auf ARM TrustZone[0], sodass der Schlüssel nicht aus dem Nvidia-SoC extrahiert werden kann. Da die einzige (bekannte) Möglichkeit, den sicheren Startvorgang zu umgehen, darin besteht, den gesamten Nvidia-SoC auszutauschen, wodurch der Schlüssel entfernt würde, wäre die Schlüsselextraktion darauf beschränkt, Schwachstellen im CE-Code zu finden, um eine Root-Shell mit ausreichenden Berechtigungen zum Abrufen des Schlüssels zu erhalten.

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