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 Linux du disque dur. 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 plus d'informations sur les différentes méthodes de sauvegarde et de réinitialisation de votre appareil.

NIST 800-88R1

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

  • Nettoyer : Se prémunir contre les techniques de récupération non invasives

  • Purge : Rendre la récupération des données impossible

  • Détruire : rendre la récupération des données impossible et empêcher l'utilisation future

La section 2.6 de la norme traite de l'utilisation de l'effacement cryptographique (CE) et de la manière dont il peut être appliqué pour répondre au niveau de purge.

Les sections 2.6.1 et 2.6.2 énumèrent les conditions dans lesquelles il faut ou non envisager 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 l'appareil sans avoir été nettoyées au préalable.

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

  • Envisagez d'utiliser CE lorsque toutes les données destinées à CE sont chiffré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'encapsulation 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 pris en compte.

  • 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 convaincus que nous pouvons 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 dès le démarrage initial, avant la création de données sensibles. La clé est stockée comme décrit ci-dessus, soit dans eeprom (logiciel plus ancien), 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 de séquestre de clé.

Avec tout cela à l'esprit, Cisco affirme que le mécanisme de réinitialisation d'usine dans RoomOS est conforme au niveau de purge dans NIST 800-88r1.

Cryptage des données client

Chiffrement du disque

Les appareils utilisent un périphérique 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 chiffrés, et lorsqu'une réinitialisation aux paramètres d'usine est effectuée, seule la clé de chiffrement est supprimée, ce qui rend les données client inaccessibles.

Pour faciliter cela, nous créons un fichier suffisamment volumineux sur la mémoire flash principale et utilisons l'outil standard Linux 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 cryptage se trouvent 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 secteurs taille : 61440 modes de secteurs : lecture/écriture

Lors du fonctionnement normal de l'appareil, le cryptsetup est utilisé pour déchiffrer 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 lors du 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 des clés de chiffrement des données

Nous utilisons deux clés de cryptage différentes sur nos appareils. L'une pour la partition /data à l'intérieur du conteneur Android (pour Microsoft MTR et Zoom) et l'autre pour les autres systèmes de fichiers (utilisée pour la configuration du 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 de la limite Nvidia TrustZone ou, sur le Room Navigator, chiffrée à l'aide du mécanisme de chiffrement 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 venant par n'importe quel canal normal, il peut être retiré de force de l'appareil (avec le disque flash) pour déchiffrer le contenu.

À partir de ce-11.26.x, nous déplaçons la clé de chiffrement du système de fichiers standard vers l'environnement d'exécution approuvé Nvidia (TEE) basé sur ARM TrustZone[0], de sorte que la clé ne pourra pas être extraite du SoC Nvidia. Étant donné que la seule façon (connue) de contourner le processus de démarrage sécurisé est de remplacer l'ensemble du SoC Nvidia, ce qui supprimerait ensuite la clé, l'extraction de la clé se limiterait à la recherche de 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.