Файлова система на пристроях серій 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.

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

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

З огляду на все це, Cisco стверджує, що механізм скидання до заводських налаштувань у RoomOS відповідає рівню Purge у NIST 800-88r1.

Шифрування даних клієнтів

Шифрування диска

Пристрої використовують флеш-пристрій для зберігання мас, де безпечне видалення неможливо гарантувати. Таким чином, усі дані клієнтів на пристроях зберігаються в зашифрованих файлових системах, і коли виконується скидання до заводських налаштувань, видаляється лише ключ шифрування, що робить дані клієнта недоступними.

Щоб полегшити це, ми створюємо файл відповідного розміру на основному флеш-пам'яті та використовуємо стандартний інструмент Linux cryptsetup для створення пристрою зворотного зв'язку. На цьому пристрої ми створюємо стандартну файлову систему ext4. Детальна інформація про те, де ми зберігаємо ключ шифрування, знаходиться в наступному розділі.

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

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

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

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

Захист ключа шифрування даних

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

Для розділу /data в Android приватний ключ завжди надійно зберігався в межах Nvidia TrustZone або, у Навігаторі кімнати, зашифрований за допомогою вбудованого механізму шифрування SoC.

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

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

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