Файловая система на борту, настольных и комнатных устройствах шифруется с помощью системы Linux Unified Key Setup (LUKS), стандартного для шифрования жестких дисков Linux. Ключ шифрования файловой системы сохраняется в NVRAM или NOR-flash. При возврате к заводским настройкам ключ перезаписывается и не может быть восстановлен, таким образом, содержимое диск прочитать невозможно. Это делает сброс до заводских настроек защищенным методом удаления и очистки данных в соответствии с US DOD 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 tool cryptsetup для создания устройства с петлей. На этом устройстве создается стандартная файл-система ext4. Подробности о том, где мы храним ключ шифрования, в следующем разделе.

Петлевое устройство создается с помощью LUKS1 с размером ключа 512 бит и шифром aes-xts-plain64:

 $ cryptsetup статус /dev/mapper/config /dev/mapper/config активен и используется. тип: LUKS1 шифр: aes-xts-plain64 keyize: 512 битов ключ расположение: dm-криптоустройство: /dev/loop5: /mnt/base/image1/rwfs/config.idf размер сектора: 512 смещ.: 4096 размер секторов: 61440 секторов режим: чтение/запись

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

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

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

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

Для раздела /data в Android закрытый ключ всегда надежно хранился в граничной системе хранящейся на граничной системе Шнвиан-Зоны Или в Навигаторе комнаты шифровался с помощью встроенного механизма шифрования soC.

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

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

Для Навигатора комнат миграция будет в более поздней версии.