Файловата система на устройствата от серията 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 е съвместим с нивото Purge в NIST 800-88r1.

Криптиране на клиентски данни

Криптиране на диска

Устройствата използват флаш устройство за масово съхранение, където сигурното изтриване е невъзможно да се гарантира. Всички клиентски данни на устройствата се съхраняват в криптирани файлови системи и когато се извърши нулиране към фабричните настройки, се изтрива само ключът за криптиране, което прави клиентските данни недостъпни.

За да улесним това, създаваме подходящо голям файл на основната флаш памет и използваме стандартния инструмент Linux cryptsetup, за да създадем loopback устройство. На това устройство създаваме стандартна файлова система ext4. Подробности за това къде съхраняваме ключа за криптиране са в следващата секция.

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

 $ cryptsetup status /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 миграцията ще бъде в по-късна версия.