Файловая система на устройствах серии Board, Desk и Room шифруется с помощью кода 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 инструмента 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 секторов режим: чтение/запись

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

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

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

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

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

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

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

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