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

Durante un restablecimiento de valores de fábrica:

  • Se eliminan los registros de llamadas

  • Las contraseñas se restablecen a los valores predeterminados

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

  • Se eliminan todos los archivos que se cargaron en el dispositivo

  • Se elimina la imagen de software anterior (inactiva)

  • Las teclas de opción no se ven afectadas

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

Le recomendamos que use la interfaz web o la interfaz de usuario para restablecer los valores de fábrica del dispositivo. Debe hacer una copia de seguridad de los archivos de registro, las configuraciones y los elementos personalizados del dispositivo antes de realizar un restablecimiento de los valores de fábrica; de lo contrario, estos datos se perderán. Consulte la Guía de administración para obtener información sobre las diferentes formas de realizar copias de seguridad y restablecer el dispositivo.

NIST 800-88r1

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

  • Limpieza: Protéjase contra técnicas de recuperación no invasivas

  • Purga: Hacer que la recuperación de datos sea inviable

  • Destruir: hacer que la recuperación de datos sea inviable y evitar el 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 la CE:

  • No utilice CE para purgar medios si el cifrado se habilitó después de que los datos confidenciales se almacenaron en el dispositivo sin haberse desinfectado primero.

  • No utilice CE si no se sabe si los datos confidenciales se almacenaron en el dispositivo sin desinfectarse antes del cifrado.

  • Considere la posibilidad de utilizar CE cuando todos los datos destinados a CE se cifran antes de almacenarlos en los medios (incluidos los datos, así como las copias virtualizadas).

  • Considere usar CE cuando conozcamos las ubicaciones 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 envoltura asociada) y podamos desinfectar esas áreas utilizando la técnica de desinfección específica de medios adecuada, asegurando que se aborde 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, a su vez, cifradas con una o más claves de ajuste y estamos seguros de que podemos desinfectar las claves de ajuste correspondientes.

  • Considere el uso de CE cuando estemos seguros de la capacidad del usuario para identificar claramente y utilizar 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 temprano en el arranque inicial, antes de la creación de cualquier dato confidencial. La clave se almacena como se describió anteriormente, ya sea en eeprom (software antiguo) o utilizando los mecanismos de zona de confianza del SoC, y se puede desinfectar de forma segura.

Nunca se realiza una copia de seguridad de la clave y no hay un mecanismo de custodia de claves.

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

Cifrado de datos del cliente

Cifrado de disco

Los dispositivos utilizan un dispositivo flash para el 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 usamos la herramienta estándar de Linux cryptsetup para crear un dispositivo de bucle invertido. 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 está activo y está en uso. Tipo: LUKS1 Cifrado: AES-XTS-PLAIN64 Tamaño de clave: 512 bits Ubicación de clave: dm-crypt Dispositivo: /dev/loop5 Bucle: /mnt/base/image1/rwfs/config.img Tamaño del sector: 512 Desplazamiento: 4096 Tamaño de los sectores: 61440 Modo de sectores: lectura/escritura

Durante el funcionamiento normal del dispositivo, cryptsetup se utiliza para descifrar los sistemas de archivos antes de que se monten. 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

Utilizamos dos claves de cifrado diferentes en nuestros dispositivos. Uno para la partición /data dentro del contenedor Android (para Microsoft MTR y Zoom) y otro para otros sistemas de archivos (utilizados 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 Room Navigator, cifrada utilizando el mecanismo de cifrado incorporado del SoC.

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

A partir de 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 se realizará en una versión posterior.