Благодарим вас за обратную связь.

Файловая система устройств серий Board, Desk и Room зашифрована с помощью Linux Unified Key Setup (LUKS), стандарта шифрования жестких дисков Linux. Ключ шифрования файловой системы сохраняется в NVRAM или Nor-Flash. Во время восстановления заводских настроек ключ перезаписывается и не может быть восстановлен, в результате чего все, что находится на диске, становится нечитаемым. Таким образом, сброс к заводским настройкам является безопасным методом удаления и очистки данных в соответствии с требованиями Министерства обороны США 5220.22M и NIST 800-88r1.

Во время восстановления заводских настроек:

• Журналы вызовов удалены

• Парольные фразы восстановлены по умолчанию

• Все параметры устройства возвращаются к значениям по умолчанию

• Все файлы, загруженные на устройство, удаляются

• Предыдущий (неактивный) образ программного обеспечения удален

• Клавиши опций не затронуты

Сброс к заводским настройкам отменить нельзя. Прежде чем начать, убедитесь в том, что это необходимо.

NIST 800-88r1

Стандарт NIST 800-88r1 определяет три уровня дезинфекции:

• Чистота: защита от неинвазивных методов восстановления

• Очистка: сделайте восстановление данных невозможным

• Уничтожение: сделайте восстановление данных невозможным и предотвратите их использование в будущем

В разделе 2.6 стандарта рассказывается об использовании криптографического стирания (CE) и о том, как его можно применять для достижения уровня очистки.

В разделах 2.6.1 и 2.6.2 перечислены условия, при которых следует (не) следует (не) рассматривать использование технологии CE:

• Не используйте CE для очистки носителя, если шифрование было включено после того, как конфиденциальные данные были сохранены на устройстве без предварительной очистки.

• Не используйте CE, если неизвестно, хранились ли на устройстве конфиденциальные данные без предварительной очистки перед шифрованием.

• Рассмотрите возможность использования CE, когда все данные, предназначенные для CE, перед хранением на носителе (включая данные и виртуализированные копии) шифруются.

• Используйте CE, если мы знаем, где хранится ключ шифрования на носителе (будь то ключ шифрования целевых данных или связанный с ним ключ упаковки), и можем дезинфицировать эти области с помощью соответствующей технологии очистки носителя, гарантируя фактическое местоположение на носителе, где хранится ключ.

• Рассмотрите возможность использования CE, если мы узнаем, что все копии ключей шифрования, используемых для шифрования целевых данных, прошли дезинфекцию.

• Рассмотрите возможность использования CE, если ключи шифрования целевых данных сами по себе зашифрованы одним или несколькими оберточными ключами, и мы уверены, что сможем дезинфицировать соответствующие ключи упаковки.

• Рассмотрите возможность использования CE, если мы уверены в способности пользователя четко идентифицировать и использовать команды, предоставляемые устройством, для выполнения операции CE.

В RoomOS зашифрованные файловые системы, используемые для данных клиентов, настраиваются и шифруются на ранних этапах начальной загрузки, перед созданием любых конфиденциальных данных. Как описано выше, ключ хранится либо в eeprom (старое программное обеспечение), либо с использованием механизмов зоны доверия SoC. Его можно безопасно дезинфицировать.

Резервное копирование ключа никогда не создается, а механизм условного депонирования ключей отсутствует.

Учитывая все это, Cisco утверждает, что механизм восстановления заводских настроек в RoomOS соответствует уровню очистки в NIST 800-88r1.

Шифрование данных клиентов

Шифрование диска

В устройствах используется флэш-устройство для хранения большого объема, безопасное удаление которого невозможно гарантировать. Поэтому все данные клиентов на устройствах хранятся в зашифрованных файловых системах, а при восстановлении заводских настроек удаляется только ключ шифрования, в результате чего данные клиента становятся недоступными.

Для облегчения этой задачи мы создаем достаточно большой файл на основной флэш-памяти и используем стандартный инструмент Linux cryptsetup для создания устройства обратной связи. На этом устройстве мы создаем стандартную файловую систему ext4. Подробнее о том, где мы храним ключ шифрования, читайте в следующем разделе.

Устройство петли создано с использованием LUKS1 с размером ключа 512 бит и шифра 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

Во время обычной работы устройства cryptsetup используется для расшифровки файловых систем перед их монтированием. После удаления ключа шифрования невозможно настроить кольцевое устройство и смонтировать файловые системы.

Используемый нами ключ шифрования представляет собой чтение 20 байт из /dev/urandom, которое затем прогоняется через sha1sum для получения представления в формате ascii. Ключ генерируется при первой загрузке после восстановления заводских настроек и не изменяется до тех пор, пока не будет выполнен новый сброс к заводским настройкам.

Защита с помощью ключа шифрования данных

На наших устройствах мы используем два разных ключа шифрования. Один для раздела /data в контейнере Android (для Microsoft MTR и Zoom), а другой — для других файловых систем (используется для настройки конфигурации клиентов, обоев, журнала вызовов, исторических журналов и т. д.).

Для раздела /data в Android закрытый ключ всегда надежно хранился на границе Nvidia TrustZone или шифровался с помощью встроенного Room Navigator механизма шифрования SoC.

До версии ce-11.25.x включительно другой ключ хранится в EEPROM. Хотя EEPROM недоступен пользователям по любому обычному каналу, его можно принудительно удалить с устройства (вместе с флэш-диском), чтобы фактически расшифровать содержимое.

Начиная с версии ce-11.26.x мы переносим обычный ключ шифрования файловой системы в доверенную среду выполнения Nvidia (TEE) на основе ARM TrustZone [0], поэтому его невозможно будет извлечь из Nvidia SoC. Поскольку единственным (известным) способом обойти процесс безопасной загрузки является замена всей SoC Nvidia, которая затем удалит ключ, извлечение ключа будет ограничено поиском уязвимостей в коде CE для получения корневой оболочки с достаточными разрешениями для получения ключа.

Ибо Room Navigator миграция будет осуществлена в более поздней версии.