Благодарим за обратната връзка.

Файловата система на устройствата Board, Desk и Room Series е криптирана с помощта на 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, когато сме уверени в способността на потребителя ясно да идентифицира и използва командите, предоставени от устройството за извършване на операцията 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 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

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

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

За мигра Room Navigator цията ще бъде в по-късна версия.