Le système de fichiers des périphériques Board, Desk et Room Series est chiffré à l'aide de Linux Unified Key Setup (LUKS), la norme pour le chiffrement de disque dur Linux. La clé de chiffrement du système de fichiers est enregistrée soit dans la NVRAM, soit dans la NOR-flash. Au cours d'une réinitialisation d'usine, la clé est remplacée et ne peut pas être récupérée, rendant tout élément du disque illisible. Cela fait de la réinitialisation d'usine une méthode sécurisée de suppression et de purge des données conformément aux normes US DOD 5220.22M et NIST 800-88r1.

Pendant une réinitialisation aux paramètres d'usine :

  • Les journaux d'appels sont supprimés

  • Les phrases secrètes sont réinitialisées à la valeur par défaut

  • Tous les paramètres du périphérique sont réinitialisés aux valeurs par défaut

  • Tous les fichiers qui ont été téléchargés sur le périphérique sont supprimés

  • L'image précédente (inactive) du logiciel est supprimée

  • Les touches d'option ne sont pas affectées

Il est impossible d'annuler une réinitialisation d'usine. Assurez-vous qu'elle est vraiment nécessaire, avant de commencer.

Il est recommandé d'utiliser l'interface Web ou l'interface utilisateur pour réinitialiser le périphérique aux paramètres d'usine. Vous devez sauvegarder les fichiers journaux, les configurations et les éléments personnalisés du périphérique avant d'effectuer une réinitialisation d'usine, sinon ces données seront perdues. Reportez-vous au Guide d'administration pour connaître les différentes méthodes de sauvegarde et de réinitialisation de votre périphérique.

NIST 800-88R1

La norme NIST 800-88r1 spécifie trois niveaux de désinfection :

  • Nettoyer : Protégez-vous contre les techniques de récupération non invasives

  • Purger : Rendre la récupération de données impossible

  • Détruire : Rendre la récupération de données impossible et empêcher toute utilisation future

La section 2.6 de la norme traite de l'utilisation de l'effacement cryptographique (CE) et de la façon dont il peut être appliqué pour atteindre le niveau de purge.

Les sections 2.6.1 et 2.6.2 énumèrent les conditions dans lesquelles il faut (ne pas) considérer l'EC :

  • N'utilisez pas CE pour purger les supports si le chiffrement a été activé après que des données sensibles ont été stockées sur le périphérique sans avoir été préalablement nettoyées.

  • N'utilisez pas CE si l'on ne sait pas si des données sensibles ont été stockées sur le périphérique sans avoir été nettoyées avant le chiffrement.

  • Envisagez d'utiliser CE lorsque toutes les données destinées à CE sont cryptées avant d'être stockées sur le support (y compris les données, ainsi que les copies virtualisées).

  • Envisagez d'utiliser CE lorsque nous connaissons les emplacements sur le support où la clé de chiffrement est stockée (qu'il s'agisse de la clé de chiffrement des données cibles ou d'une clé d'emballage associée) et que nous pouvons nettoyer ces zones à l'aide de la technique de nettoyage spécifique au support appropriée, en veillant à ce que l'emplacement réel sur le support où la clé est stockée soit corrigé.

  • Envisagez d'utiliser CE lorsque nous pouvons savoir que toutes les copies des clés de chiffrement utilisées pour chiffrer les données cibles sont nettoyées.

  • Envisagez d'utiliser CE lorsque les clés de chiffrement des données cibles sont elles-mêmes chiffrées avec une ou plusieurs clés d'encapsulation et que nous sommes confiants de pouvoir nettoyer les clés d'encapsulation correspondantes.

  • Envisagez d'utiliser CE lorsque nous sommes sûrs de la capacité de l'utilisateur à identifier clairement et à utiliser les commandes fournies par l'appareil pour effectuer l'opération CE.

Dans RoomOS, les systèmes de fichiers chiffrés utilisés pour les données client sont configurés et chiffrés au début du démarrage initial, avant la création de données sensibles. La clé est stockée comme décrit ci-dessus soit dans eeprom (ancien logiciel), soit à l'aide des mécanismes de zone de confiance du SoC, et peut être nettoyée en toute sécurité.

La clé n'est jamais sauvegardée et il n'y a pas de mécanisme d'entiercement de clé.

Dans cet esprit, Cisco affirme que le mécanisme de réinitialisation d'usine de RoomOS est conforme au niveau de purge de la norme NIST 800-88r1.

Chiffrement des données client

Chiffrement de disque

Les appareils utilisent un dispositif flash pour le stockage de masse, où la suppression sécurisée est impossible à garantir. Toutes les données client sur les appareils sont donc stockées sur des systèmes de fichiers cryptés, et lorsqu'une réinitialisation aux paramètres d'usine est effectuée, seule la clé de cryptage est supprimée, rendant les données client inaccessibles.

Pour faciliter cela, nous créons un fichier suffisamment volumineux sur le flash principal et utilisons l'outil Linux standard cryptsetup pour créer un périphérique de bouclage. Sur cet appareil, nous créons un système de fichiers ext4 standard. Les détails sur l'endroit où nous stockons la clé de chiffrement sont dans la section suivante.

Le périphérique de boucle est créé à l'aide de LUKS1 avec une taille de clé de 512 bits et le chiffrement aes-xts-plain64 :

 $ cryptsetup status /dev/mapper/config /dev/mapper/config est actif et en cours d'utilisation. Type : LUKS1 chiffrement : AES-XTS-PLAIN64 Taille de la clé : 512 bits Emplacement de la clé : DM-crypt Périphérique : / dev / loop5 boucle : /mnt / base / image1 / rwfs / config.img Taille du secteur : 512 décalage : 4096 Taille des secteurs : 61440 Mode des secteurs : lecture / écriture

Pendant le fonctionnement normal de l'appareil, la cryptsetup est utilisée pour décrypter les systèmes de fichiers avant qu'ils ne soient montés. Lorsque la clé de chiffrement est supprimée, il n'est plus possible de configurer le périphérique de boucle et de monter les systèmes de fichiers.

La clé de chiffrement que nous utilisons est une lecture de 20 octets de /dev/urandom qui est exécutée par sha1sum pour obtenir une représentation ascii. La clé est générée au premier démarrage après une réinitialisation d'usine et ne change pas tant qu'une nouvelle réinitialisation d'usine n'est pas effectuée.

Protection de la clé de cryptage des données

Nous utilisons deux clés de chiffrement différentes sur nos appareils. Un pour la partition /data à l'intérieur du conteneur Android (pour Microsoft MTR et Zoom) et un pour les autres systèmes de fichiers (utilisé pour la configuration client, les papiers peints, le journal des appels, les journaux historiques, etc.).

Pour la partition /data dans Android, la clé privée a toujours été stockée en toute sécurité à l'intérieur des limites de Nvidia TrustZone ou, sur le navigateur de salle, cryptée à l'aide du mécanisme de cryptage intégré du SoC.

Jusqu'à ce-11.25.x inclus, l'autre clé est stockée dans l'EEPROM. Bien que l'EEPROM soit inaccessible aux utilisateurs passant par un canal normal, elle peut être retirée de force de l'appareil (avec le disque flash) pour décrypter réellement le contenu.

À partir de ce-11.26.x, nous déplaçons la clé de cryptage du système de fichiers standard vers l'environnement d'exécution de confiance (TEE) Nvidia basé sur ARM TrustZone[0], de sorte que la clé ne sera pas possible d'extraire du SoC Nvidia. Étant donné que le seul moyen (connu) de contourner le processus de démarrage sécurisé consiste à remplacer l'intégralité du SoC Nvidia, qui supprimerait ensuite la clé, l'extraction de clé se limiterait à trouver des vulnérabilités dans le code CE pour obtenir un shell racine avec des autorisations suffisantes pour obtenir la clé.

Pour Room Navigator, la migration se fera dans une version ultérieure.