Merci pour votre commentaire.

Le système de fichiers des appareils Board, Desk et Room Series est crypté à l'aide de Linux Unified Key Setup (LUKS), la norme pour le cryptage des disques durs Linux. La clé de cryptage du système de fichiers est enregistrée dans la NVRAM ou dans la mémoire flash. Lors d'une réinitialisation d'usine, la clé est écrasée et ne peut pas être récupérée, ce qui rend tout ce qui se trouve sur le disque illisible. La réinitialisation aux paramètres d'usine est donc une méthode sécurisée pour supprimer et purger les données, conformément au DOD 5220.22M des États-Unis et au NIST 800-88r1.

Lors d'une réinitialisation d'usine :

• Les journaux d'appels sont supprimés

• Les phrases de passe sont réinitialisées par défaut

• Tous les paramètres de l'appareil sont réinitialisés aux valeurs par défaut

• Tous les fichiers qui ont été téléchargés sur l'appareil sont supprimés

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

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

Vous ne pouvez pas annuler une réinitialisation d'usine. Assurez-vous que c'est nécessaire avant de commencer.

NIST 800-88r1

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

• Propre : évitez les techniques de guérison non invasives

• Purge : rendre la récupération de données impossible

• Détruire : rendre la récupération des 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 manière dont il peut être appliqué pour atteindre le niveau de purge.

Les sections 2.6.1 et 2.6.2 énumèrent les conditions pour (ne pas) envisager le CE :

• N'utilisez pas CE pour purger les médias si le cryptage a été activé après le stockage de données sensibles sur l'appareil sans les avoir nettoyés au préalable.

• N'utilisez pas le 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 cryptage.

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

• Pensez à utiliser CE lorsque nous connaissons le ou les emplacements sur le support où est stockée la clé de cryptage (qu'il s'agisse de la clé de cryptage des données cibles ou d'une clé d'emballage associée) et que nous pouvons assainir ces zones à l'aide de la technique de désinfection adaptée au support, en veillant à ce que l'emplacement réel sur le support où la clé est stockée soit indiqué.

• Pensez à utiliser CE lorsque nous saurons que toutes les copies des clés de cryptage utilisées pour crypter les données cibles sont nettoyées.

• Envisagez d'utiliser CE lorsque les clés de cryptage des données cibles sont elles-mêmes cryptées avec une ou plusieurs clés d'encapsulage et que nous sommes convaincus de pouvoir désinfecter les clés d'encapsulation correspondantes.

• Pensez à 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 cryptés utilisés pour les données des clients sont configurés et chiffrés dès le démarrage initial, avant la création de toute donnée sensible. 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'existe aucun mécanisme d'entiercement des clés.

Dans cette optique, Cisco affirme que le mécanisme de réinitialisation des paramètres d'usine de RoomOS est conforme au niveau de purge du NIST 800-88r1.

Chiffrement des données clients

Chiffrement des disques

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 clients présentes sur les appareils sont donc stockées sur des systèmes de fichiers cryptés, et lorsqu'une réinitialisation des paramètres d'usine par défaut est effectuée, seule la clé de cryptage est supprimée, rendant les données des clients inaccessibles.

Pour faciliter cela, nous créons un fichier suffisamment volumineux sur la mémoire flash principale 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 cryptage se trouvent dans la section suivante.

Le périphérique en 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 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

Pendant le fonctionnement normal de l'appareil, le cryptsetup est utilisé pour déchiffrer les systèmes de fichiers avant leur montage. Une fois la clé de cryptage supprimée, il n'est plus possible de configurer le périphérique Loop et de monter les systèmes de fichiers.

La clé de cryptage que nous utilisons est une lecture de 20 octets depuis /dev/urandom, qui est exécutée via 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 n'est pas effectuée.

Protection des clés de cryptage des données

Nous utilisons deux clés de cryptage différentes sur nos appareils. L'un pour la partition /data du conteneur Android (pour Microsoft MTR et Zoom) et l'autre pour les autres systèmes de fichiers (utilisés pour la configuration des clients, les fonds d'écran, le journal des appels, les journaux historiques, etc.).

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

Jusqu'au ce-11.25.x inclus, l'autre clé est stockée dans l'EEPROM. Bien que l'EEPROM ne soit pas accessible aux utilisateurs via n'importe quel canal normal, elle peut être retirée de force de l'appareil (en même temps que la clé USB) pour en déchiffrer le contenu.

À partir de ce-11.26.x, nous allons déplacer la clé de cryptage standard du système de fichiers vers l'environnement d'exécution sécurisé Nvidia (TEE) basé sur ARM TrustZone [0]. La clé ne pourra donc pas être extraite du SoC Nvidia. Comme le seul moyen (connu) de contourner le processus de démarrage sécurisé est de remplacer l'intégralité du SoC Nvidia, ce qui supprimerait la clé, l'extraction de la clé se limiterait à détecter des vulnérabilités dans le code CE afin d'obtenir un shell root doté des autorisations suffisantes pour obtenir la clé.

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