Gracias por sus comentarios.

El sistema de archivos de las series Board, Desk y Room se encripta mediante Linux Unified Key Setup (LUKS), el estándar para el cifrado de disco duro Linux. La clave de cifrado del sistema de archivos se guarda en NVRAM o NOR-Flash. Durante un restablecimiento de fábrica, la clave se sobrescribe y no se puede recuperar, lo que hace que cualquier cosa en el disco sea ilegible. Esto hace que el restablecimiento de fábrica sea un método seguro para eliminar y depurar datos de acuerdo con el DOD 5220.22M de los Estados Unidos y el NIST 800-88r1.

Durante un restablecimiento de fábrica:

• Los registros de llamadas se eliminan

• Las frases de contraseña se restablecen a la predeterminada

• Todos los parámetros del dispositivo se restablecen a los valores predeterminados

• Todos los archivos que se han cargado en el dispositivo se eliminan

• Se elimina la imagen de software anterior (inactiva)

• Las claves de opción no se ven afectadas

No puede deshacer un restablecimiento de fábrica. Asegúrese de que es necesario hacerlo, antes de comenzar.

NIST 800-88r1

El estándar NIST 800-88r1 especifica tres niveles de desinfección:

• Limpio: Proteja contra técnicas de recuperación no invasivas

• Depuración: hacer que la recuperación de datos sea inviable

• Destruir: hacer que la recuperación de datos sea inviable y evitar su uso futuro

La sección 2.6 de la norma habla sobre el uso del borrado criptográfico (CE) y cómo se puede aplicar para cumplir con el nivel de purga.

Las secciones 2.6.1 y 2.6.2 enumeran las condiciones para cuándo (no) considerar CE:

• No use CE para purgar medios si el cifrado se habilitó después de que los datos confidenciales se almacenaron en el dispositivo sin haber sido desinfectados primero.

• No utilice CE si se desconoce si los datos confidenciales se almacenaron en el dispositivo sin ser desinfectados antes del cifrado.

• Considere usar CE cuando todos los datos destinados a CE se cifran antes del almacenamiento en los medios (incluidos los datos, así como las copias virtualizadas).

• Considere usar CE cuando sepamos la (s) ubicación (s) en los medios donde se almacena la clave de cifrado (ya sea la clave de cifrado de los datos de destino o una clave de empaquetado asociada) y podamos desinfectar esas áreas utilizando la técnica de desinfección específica del medio adecuada, asegurando que se direcciona la ubicación real en los medios donde se almacena la clave.

• Considere usar CE cuando podamos saber que todas las copias de las claves de cifrado que se utilizan para cifrar los datos de destino están desinfectadas.

• Considere usar CE cuando las claves de cifrado de los datos de destino estén, ellas mismas, cifradas con una o más claves de empaquetado y estamos seguros de que podemos desinfectar las claves de envoltura correspondientes.

• Considere usar CE cuando estemos seguros de la capacidad del usuario para identificar y usar claramente los comandos proporcionados por el dispositivo para realizar la operación CE.

En RoomOS, los sistemas de archivos cifrados que se utilizan para los datos del cliente se configuran y cifran al principio del arranque inicial, antes de la creación de cualquier dato confidencial. La clave se almacena como se describe anteriormente, ya sea en eeprom (software antiguo) o utilizando los mecanismos de zona de confianza del SoC, y se puede desinfectar de forma segura.

La llave nunca se realiza una copia de seguridad y no hay un mecanismo de garantía de claves.

Con todo esto en mente, Cisco afirma que el mecanismo de restablecimiento de fábrica en RoomOS cumple con el nivel de purga en NIST 800-88r1.

Cifrado de datos del cliente

Cifrado de disco

Los dispositivos utilizan un dispositivo flash para almacenamiento masivo, donde la eliminación segura es imposible de garantizar. Por lo tanto, todos los datos del cliente en los dispositivos se almacenan en sistemas de archivos cifrados y, cuando se realiza un restablecimiento a los valores predeterminados de fábrica, solo se elimina la clave de cifrado, lo que hace que los datos del cliente sean inaccesibles.

Para facilitar esto, creamos un archivo adecuadamente grande en la memoria flash principal y utilizamos la herramienta estándar de Linux cryptsetup para crear un dispositivo de loopback. En este dispositivo creamos un sistema de archivos ext4 estándar. Los detalles sobre dónde almacenamos la clave de cifrado se encuentran en la siguiente sección.

El dispositivo de bucle se crea utilizando LUKS1 con un tamaño de clave de 512 bits y el cifrado 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 el funcionamiento regular del dispositivo, el cryptsetup se utiliza para descifrar los sistemas de archivos antes de montarse. Cuando se elimina la clave de cifrado, ya no es posible configurar el dispositivo de bucle y montar los sistemas de archivos.

La clave de cifrado que utilizamos es una lectura de 20 bytes de /dev/urandom que se ejecuta a través de sha1sum para obtener una representación ascii. La clave se genera en el primer arranque después de un restablecimiento de fábrica y no cambia hasta que se realiza un nuevo restablecimiento de fábrica.

Protección de clave de cifrado de datos

Usamos dos claves de cifrado diferentes en nuestros dispositivos. Una para la partición /data dentro del contenedor Android (para Microsoft MTR y Zoom) y otra para otros sistemas de archivos (utilizada para la configuración del cliente, papeles de pared, registro de llamadas, registros históricos, etc.).

Para la partición /data en Android, la clave privada siempre se ha almacenado de forma segura dentro del límite de Nvidia TrustZone o, en el Room Navigator caso, se ha cifrado mediante el mecanismo de cifrado integrado del SoC.

Hasta ce-11.25.x, incluyendo ce-11.25.x, la otra clave se almacena en EEPROM. Si bien EEPROM es inaccesible para los usuarios que vienen a través de cualquier canal normal, se puede quitar por la fuerza del dispositivo (junto con el disco flash) para descifrar realmente el contenido.

Comenzando con ce-11.26.x estamos moviendo la clave de cifrado del sistema de archivos normal al entorno de ejecución confiable (TEE) de Nvidia basado en ARM TrustZone [0], por lo que la clave no será posible extraer del SoC de Nvidia. Dado que la única forma (conocida) de eludir el proceso de arranque seguro es reemplazar todo el SoC de Nvidia, que luego eliminaría la clave, la extracción de claves se limitaría a encontrar vulnerabilidades en el código CE para obtener un shell raíz con permisos suficientes para obtener la clave.

Para Room Navigator la migración será en una versión posterior.