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

По време на фабрично нулиране:

  • Дневниците на обажданията се изтриват

  • Фразите за достъп се връщат по подразбиране

  • Всички параметри на устройството се нулират до стойности по подразбиране

  • Всички файлове, които са качени на устройството, се изтриват

  • Предишното (неактивно) изображение на софтуера се изтрива

  • Опционните клавиши не са засегнати

Не можете да отмените фабрично нулиране. Уверете се, че е необходимо да го направите, преди да започнете.

Препоръчваме ви да използвате web интерфейс или потребителски интерфейс, за да възстановите фабричните настройки на устройството. Трябва да архивирате регистрационните файлове, конфигурациите и персонализираните елементи на устройството, преди да извършите фабрично нулиране; в противен случай тези данни ще бъдат загубени. Вижте Ръководството за администриране за информация относно различните начини за архивиране и нулиране на вашето устройство.

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 /dev/mapper/config /dev/mapper/config е активен и се използва. тип: LUKS1 шифър: aes-xts-plain64 размер на ключа: 512 бита местоположение на ключа: dm-crypt устройство: /dev/loop5 цикъл: /mnt/base/image1/rwfs/config.img размер на сектора: 512 отместване: 4096 размер на сектора: 61440 режим на сектори: четене/запис

По време на редовна работа на устройството, cryptsetup се използва за декриптиране на файловите системи, преди да бъдат монтирани. Когато ключът за криптиране бъде изтрит, вече не е възможно да настроите устройството за цикъл и да монтирате файловите системи.

Ключът за криптиране, който използваме, е четене на 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 миграцията ще бъде в по-късна версия.