Дякуємо за відгук.

Файлова система на пристроях серії Board, Desk та Room шифрується за допомогою Linux Unified Key Setup (LUKS), стандарту шифрування жорсткого диска Linux. Ключ шифрування файлової системи зберігається в NVRAM або NOR-flash. Під час скидання до заводських налаштувань ключ перезаписується і не може бути відновлений, що робить щось на диску нечитабельним. Це робить скидання до заводських налаштувань безпечним методом видалення та очищення даних відповідно до US DOD 5220.22M та NIST 800-88r1.

Під час скидання до заводських налаштувань:

• Журнали дзвінків видаляються

• Парольні фрази скинуті до типових

• Всі параметри пристрою скидаються до значень за замовчуванням

• Всі файли, які були завантажені на пристрій, видаляються

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

• Клавіші опцій не впливають

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

НІСТ 800-88р1

Стандарт 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 відповідає рівню очищення в NIST 800-88r1.

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

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

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

Щоб полегшити це, ми створюємо відповідний великий файл на основній флешці і використовуємо стандартний інструмент Linux cryptsetup для створення пристрою loopback. На цьому пристрої створюємо стандартну файлову систему 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 або, на ньому, шифрувався за допомогою вбудованого механізму шифрування SoC. Room Navigator

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

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

Для Room Navigator міграції буде в більш пізній версії.