Obrigado pelos seus comentários.

O sistema de arquivos nos dispositivos Board, Desk e Room Series é criptografado usando o Linux Unified Key Setup (LUKS), o padrão para criptografia de disco rígido Linux. A chave de criptografia do sistema de arquivos é salva na NVRAM ou no Nor-flash. Durante uma redefinição de fábrica, a chave é sobrescrita e não pode ser recuperada, tornando qualquer coisa no disco ilegível. Isso torna a redefinição de fábrica um método seguro de excluir e eliminar dados em conformidade com o DOD 5220.22M dos EUA e o NIST 800-88r1.

Durante uma redefinição de fábrica:

• Os registros de chamadas são excluídos

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

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

• Todos os arquivos que foram enviados para o dispositivo são excluídos

• A imagem anterior (inativa) do software é excluída

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

Você não pode desfazer uma redefinição de fábrica. Certifique-se de que é necessário fazer isso antes de começar.

NIST 800-88r1

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

• Limpo: proteja-se contra técnicas de recuperação não invasivas

• Purge: torne a recuperação de dados inviável

• Destrua: torne a recuperação de dados inviável e evite o uso futuro

A seção 2.6 da norma fala sobre o uso do Cryptographic Erase (CE) e como ele pode ser aplicado para atingir o nível de purga.

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

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

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

• Considere usar o CE quando todos os dados destinados ao CE forem criptografados antes do armazenamento na mídia (incluindo os dados e as cópias virtualizadas).

• Considere usar o CE quando soubermos os locais na mídia em que a chave de criptografia está armazenada (seja a chave de criptografia dos dados de destino ou uma chave de empacotamento associada) e pudermos higienizar essas áreas usando a técnica apropriada de higienização específica da mídia, garantindo que a localização real na mídia em que a chave está armazenada seja endereçada.

• Considere usar o CE quando soubermos que todas as cópias das chaves de criptografia usadas para criptografar os dados de destino foram higienizadas.

• Considere usar o CE quando as chaves de criptografia dos dados de destino forem, elas mesmas, criptografadas com uma ou mais chaves de encapsulamento e tivermos certeza de que podemos limpar as chaves de encapsulamento correspondentes.

• Considere usar o CE quando tivermos certeza da capacidade do usuário de identificar e usar claramente os comandos fornecidos pelo dispositivo para realizar a operação do CE.

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

O backup da chave nunca é feito e não há mecanismo de custódia de chaves.

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 purga no 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. Portanto, todos os dados do cliente nos dispositivos são armazenados em sistemas de arquivos criptografados e, quando uma redefinição para os padrões de fábrica é executada, somente a chave de criptografia é excluída, tornando os dados do cliente inacessíveis.

Para facilitar isso, criamos um arquivo adequadamente grande no flash principal e usamos a ferramenta padrão do Linux cryptsetup 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 cifra 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 a operação regular do dispositivo, o cryptsetup é usado para descriptografar os sistemas de arquivos 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 usamos é uma leitura de 20 bytes de /dev/urandom, que é executada por sha1sum para obter uma representação ASCII. A chave é gerada na primeira inicialização após uma redefinição de fábrica e não muda até que uma nova redefinição de fábrica seja executada.

Proteção de chave de criptografia de dados

Usamos duas chaves de criptografia diferentes em nossos dispositivos. Um para a partição /data dentro do contêiner Android (para Microsoft MTR e Zoom) e outro para outros sistemas de arquivos (usados para configuração do cliente, papéis de parede, registro de chamadas, registros históricos e assim por diante).

Para a partição /data no Android, a chave privada sempre foi armazenada com segurança dentro do limite da Nvidia TrustZone ou, noRoom Navigator, criptografada usando o mecanismo de criptografia integrado do SoC.

Até ce-11.25.x, inclusive, a outra chave é armazenada na EEPROM. Embora a EEPROM seja inacessível para usuários que acessam qualquer canal normal, ela pode ser removida à força do dispositivo (junto com o disco flash) para realmente descriptografar o conteúdo.

A partir do ce-11.26.x, estamos movendo a chave de criptografia regular do sistema de arquivos para o ambiente de execução confiável (TEE) da Nvidia baseado no ARM TrustZone [0], portanto, não será possível extrair a chave do SoC da Nvidia. Como a única maneira (conhecida) de contornar o processo de inicialização segura é substituir todo o SoC da Nvidia, que então removeria a chave, a extração da chave se limitaria a encontrar vulnerabilidades no código CE para obter um shell raiz com permissões suficientes para obter a chave.

Pois Room Navigator a migração será em uma versão posterior.