Файлова система на пристроях Board, Desk і Room Series шифрується за допомогою 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 для створення loopback пристрою. На цьому пристрої ми створюємо стандартну файлову систему ext4. Деталі про те, де ми зберігаємо ключ шифрування, наведені в наступному розділі.

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

 $ Cryptsetup статус /dev/mapper/config /dev/mapper/config активний і використовується. тип: LUKS1 Шифр: aes-xts-plain64 Розмір ключа: 512 біт Розташування ключа: dm-Crypt Пристрій: /dev/loop5 Цикл: /mnt/base/image1/rwfs/config.img Розмір сектора: 512 Зсув: 4096 Розмір секторів: 61440 Сектори Режим: читання/запис

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

Ключ шифрування, який ми використовуємо, — це зчитування 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 Trusted Execution Environment (TEE) на базі ARM TrustZone[0], тому ключ буде неможливо витягти з Nvidia SoC. Оскільки єдиний (відомий) спосіб обійти процес безпечного завантаження — це замінити весь Nvidia SoC, що потім видаляє ключ, вилучення ключа обмежиться пошуком вразливостей у коді CE, щоб отримати root-shell з достатніми дозволами для отримання ключа.

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