O sistema de arquivos em dispositivos a bordo, Mesa e Série de salas é criptografado usando o Linux Unified Key Setup (LUKS), o padrão para criptografia do disco rígido Linux. A chave de criptografia do sistema de arquivos é salva em NVRAM ou em NOR-flash. Durante uma redefinição das configurações de fábrica, a chave é substituída e não pode ser recuperada, o que faz com que qualquer coisa no disco fique ilegível. Isso torna a redefinição de fábrica um método seguro de exclusão e eliminação de dados em conformidade com os US DOD 5220.22M e NIST 800-88r1.

Durante uma redefinição das configurações de fábrica:

  • Os logs de chamadas são excluídos

  • As frases secretas são redefinidas como padrão

  • Todos os parâmetros do dispositivo são redefinidos para valores padrão

  • Todos os arquivos que foram carregados no dispositivo são excluídos

  • A imagem de software anterior (inativo) é excluída

  • As teclas de opção não são afetadas

Não é possível desfazer uma redefinição das configurações de fábrica. Certifique-se de que é necessário fazer isso antes de começar.

Recomendamos que você use a interface da Web ou a interface do usuário para fazer a redefinição das configurações de fábrica do dispositivo. Você deve fazer o backup dos arquivos de log, das configurações e dos elementos personalizados do dispositivo antes de executar uma redefinição das configurações de fábrica. caso contrário, esses dados serão perdidos. Consulte o Guia de administração para obter informações sobre as diferentes formas de fazer backup e redefinição do dispositivo.

NIST 800-88r1

O padrão NIST 800-88r1 especifica três níveis de sanitização:

  • Limpo: Guarda contra técnicas de recuperação não invasivas

  • Purgação: Tornar a recuperação de dados inviável

  • Destruir: Tornar a recuperação de dados inviável e prevenir uso futuro

A seção 2.6 do padrão fala sobre o uso da Era criptográfica (CE) e como ela pode ser aplicada para atender ao nível de Limpeza.

As seçãos 2.6.1 e 2.6.2 listam as condições para quando (não) considerar CE:

  • Não use a CE para limpar a mídia se a criptografia tiver sido ativada depois que dados confidenciais foram armazenados no dispositivo sem terem sido primeiro higienizados.

  • Não use a CE se não se sabe se dados confidenciais foram armazenados no dispositivo sem serem higienizados antes da criptografia.

  • Considere o uso da CE quando todos os dados destinados à CE forem criptografados antes do armazenamento na mídia (incluindo os dados, bem como cópias virtualizadas).

  • Considere o uso da CE quando conhecermos os locais na mídia onde a chave de criptografia é armazenada (seja a chave de criptografia dos dados de destino ou uma chave de encapsulamento associada) e pode higienizar essas áreas usando a técnica adequada de sanitização específica da mídia, garantindo que o local real na mídia onde a chave é armazenada seja tratada.

  • Considere o uso da CE quando pudermos saber que todas as cópias das chaves de criptografia usadas para criptografar dados de destino são higienizadas.

  • Considere o uso da CE quando as chaves de criptografia dos dados de destino forem, elas mesmas, criptografadas com uma ou mais chaves de embrulho e estamos confiantes de que podemos higienizar as chaves de embrulho correspondentes.

  • Considere o uso da CE quando estivermos confiantes da capacidade do usuário de identificar e usar claramente os comandos que são fornecidos pelo dispositivo para executar a operação CE.

No RoomOS, os sistemas de arquivos criptografados usados para dados do cliente são configurados e criptografados no início da inicialização inicial, antes da criação de qualquer dado sensível. A chave é armazenada conforme descrito acima em eeprom (software mais antigo) ou usando os mecanismos de zona de confiança do SoC, e pode ser higienizada com segurança.

O backup da chave nunca foi feito e não há um mecanismo chave de escrow.

Com tudo isso em mente, a Cisco afirma que o mecanismo de redefinição de fábrica no RoomOS é compatível com o nível de Limpeza em NIST 800-88r1.

Criptografia de dados do cliente

Criptografia de disco

Os dispositivos usam um dispositivo flash para armazenamento em massa, onde a exclusão segura é impossível de garantir. Todos os dados dos clientes nos dispositivos são, portanto, armazenados em sistemas de arquivos criptografados e, quando é realizada uma redefinição para os padrões de fábrica, apenas a chave de criptografia é excluída, tornando os dados do cliente inacessível.

Para facilitar isso, criamos um arquivo grande de forma adequada no flash principal e usamos a cryptsetup padrão da ferramenta Linux para criar um dispositivo de loopback. Neste dispositivo, criamos um sistema de arquivos ext4 padrão. Detalhes sobre onde armazenamos a chave de criptografia estão na próxima seção.

O dispositivo de loop é criado usando LUKS1 com um tamanho de chave de 512 bits e a fervífera aes-xts-plain64:

 O status de $cryptsetup /dev/mapper/config /dev/mapper/config está ativo e está em uso. tipo: cipher luks1: aes-xts-plain64 keysize: 512 bits localização de chave: dispositivo dm-crypt: /dev/loop5 loop: /mnt/base/image1/rwfs/config.img tamanho do setor: 512 compensação: 4096 tamanho dos setores: 61440 setores: modo de leitura/gravação

Durante a operação regular do dispositivo, a cryptsetup é usada para descriptografar os sistemas do arquivo antes de serem montados. Quando a chave de criptografia é excluída, não é mais possível configurar o dispositivo de loop e montar os sistemas de arquivos.

A chave de criptografia que utilizamos é uma leitura de 20 bytes do /dev/urandom que é sha1sum run-through para obter uma representação ascii. A tecla é gerada na primeira inicialização após uma reinicialização de fábrica e não é alterada até que uma nova reinicialização de fábrica seja executada.

Proteção de chave de criptografia de dados

Usamos duas teclas de criptografia diferentes em nossos dispositivos. Uma para a partição de /dados dentro do container do Android (para Microsoft MTR e Zoom) e uma para outros sistemas de arquivos (usados para configuração do cliente, papéis de parede, log de chamadas, logs históricos e assim por diante).

Para a partição de /dados no Android, a chave privada sempre foi armazenada seguramente dentro da fronteira Nvidia TrustZone ou, no Navegador de sala, criptografada usando o mecanismo de criptografia interno do SoC.

Até e incluindo ce-11.25.x, a outra chave é armazenada na EEPROM. Embora o EEPROM seja inacessível para usuários que vêm através de qualquer canal normal, ele pode ser forçado a remover do dispositivo (juntamente com o disco flash) para realmente descriptografar o conteúdo.

Começando com ce-11.26.x, estamos movendo a chave de criptografia do sistema de arquivo regular para o ambiente de execução confiável (TEE) da Nvidia com base no ARM TrustZone[0], de modo que a chave não será possível para extrair do Nvidia SoC. Uma vez que a única maneira (conhecida) de contornar o processo de inicialização segura é substituir todo o Nvidia SoC, que removeria a chave, a extração de chave seria limitada a encontrar vulnerabilidades no código CE para obter um shell raiz com permissões suficientes para obter a chave.

Para o Room Navigator, a migração estará em uma versão posterior.