Köszönjük visszajelzését.

A Board, Desk és Room Series eszközök fájlrendszere a Linux Unified Key Setup (LUKS) segítségével van titkosítva, amely a Linux merevlemez titkosításának szabványa. A fájlrendszer titkosítási kulcsa NVRAM vagy Nor-flash programban kerül mentésre. A gyári alaphelyzetbe állítás során a kulcsot felülírják, és nem állítható vissza, így a lemezen lévő bármi olvashatatlanná válik. Ez a gyári visszaállítás biztonságos módszerré teszi az adatok törlésére és tisztítására az US DOD 5220.22M és a NIST 800-88r1 szabványnak megfelelően.

Gyári alaphelyzetbe állítás során:

• A hívásnaplók törlődnek

• A jelszavak alapértelmezett állapotba kerülnek

• Az összes eszközparaméter alapértelmezett értékekre van állítva

• Az eszközre feltöltött összes fájl törlődik

• Az előző (inaktív) szoftverkép törlődik

• Az opciós billentyűket nem érinti

A gyári alaphelyzetbe állítást nem lehet visszavonni. Győződjön meg róla, hogy erre szükség van, mielőtt elkezdené.

NIST 800-88r1

A 800-88r1 NIST szabvány a fertőtlenítés három szintjét határozza meg:

• Tiszta: Védje a nem invazív helyreállítási technikák ellen

• Tisztítás: Az adatok helyreállítását megvalósíthatatlanná tegye

• Pusztítás: Teg ye megvalósíthatatlanná az adatok helyreállítását és megakadályozza a jövőbeni felhasználást

A szabvány 2.6. szakasza a kriptográfiai törlés (CE) használatáról és arról beszél, hogyan alkalmazható a Purge szint eléréséhez.

A 2.6.1. és 2.6.2. szakasz felsorolja azokat a feltételeket, amelyek alapján (nem) kell figyelembe venni a CE-t:

• Ne használja a CE-t a hordozók tisztítására, ha a titkosítás engedélyezve volt, miután érzékeny adatokat tároltak az eszközön anélkül, hogy először fertőtlenítették volna őket.

• Ne használja a CE-t, ha nem ismert, hogy érzékeny adatokat tároltak-e a készüléken anélkül, hogy a titkosítás előtt fertőtlenítették volna őket.

• Fontolja meg a CE használatát, ha a CE-re szánt összes adat titkosítva van a hordozón való tárolás előtt (beleértve az adatokat, valamint a virtualizált másolatokat is).

• Fontolja meg a CE használatát, ha a titkosítási kulcs tárolásának helyét ismerjük (legyen az a céladat titkosítási kulcsa vagy a hozzá tartozó csomagoló kulcs), és a megfelelő média-specifikus fertőtlenítési technikával fertőtleníthetjük ezeket a területeket, biztosítva, hogy a kulcs tárolására szolgáló adathordozón tényleges hely legyen címezve.

• Fontolja meg a CE használatát, ha tudhatjuk, hogy a céladatok titkosításához használt titkosítási kulcsok minden példányát fertőtlenítik.

• Fontolja meg a CE használatát, ha a céladatok titkosítási kulcsai önmagukban egy vagy több csomagolókulccsal vannak titkosítva, és biztosak vagyunk abban, hogy meg tudjuk fertőtleníteni a megfelelő csomagolókulcsokat.

• Fontolja meg a CE használatát, ha biztosak vagyunk abban, hogy a felhasználó képes egyértelműen azonosítani és használni a készülék által a CE művelet végrehajtásához biztosított parancsokat.

A RoomOS-ban az ügyféladatokhoz használt titkosított fájlrendszereket a kezdeti rendszerindítás elején állítják be és titkosítják, mielőtt bármilyen érzékeny adat létrehozását megelőzően történik. A kulcsot a fent leírtak szerint tárolják az eepromban (régebbi szoftver) vagy a SoC bizalmi zóna mechanizmusai segítségével, és biztonságosan fertőtleníthető.

A kulcsot soha nem készítik biztonsági mentést, és nincs kulcsfontosságú letéti mechanizmus.

Mindezt szem előtt tartva a Cisco azt állítja, hogy a RooMOS gyári visszaállítási mechanizmusa megfelel a NIST 800-88r1 Purge szintjének.

Ügyféladatok titkosítása

Lemez titkosítás

Az eszközök flash eszközt használnak tömeges tároláshoz, ahol a biztonságos törlést lehetetlen garantálni. Az eszközökön található összes ügyféladatot ezért titkosított fájlrendszereken tárolják, és amikor a gyári alapbeállítások visszaállítása történik, csak a titkosítási kulcs törlődik, így az ügyféladatok elérhetetlenné válnak.

Ennek megkönnyítése érdekében egy megfelelő nagy fájlt hozunk létre a fő flash-en, és a szokásos Linux eszköz cryptsetup segítségével hozzunk létre egy visszacsatoló eszközt. Ezen az eszközön létrehozunk egy szabványos ext4 fájlrendszert. A titkosítási kulcs tárolásának részletei a következő részben találhatók.

A hurokeszköz LUKS1 segítségével jön létre 512 bites kulcsmérettel és az aes-xts-plain64 titkosítással:

 $ 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

Az eszköz rendszeres működése során a cryptsetup a fájlrendszerek visszafejtésére szolgál a telepítés előtt. A titkosítási kulcs törlésekor már nem lehet beállítani a hurok-eszközt és a fájlrendszereket csatlakoztatni.

Az általunk használt titkosítási kulcs a /dev/urandom 20 bájtból olvasható, amely a sha1sum átfuttatásával egy ascii ábrázolást kapunk. A kulcs a gyári alaphelyzetbe állítás után az első indításkor jön létre, és addig nem változik, amíg egy új gyári alaphelyzetbe állítás nem történik.

Adattitkosítási kulcs védelme

Két különböző titkosítási kulcsot használunk készülékeinken. Az egyik az Android tárolóban lévő /data partícióhoz (Microsoft MTR és Zoom esetében), egy pedig más fájlrendszerekhez (ügyfélkonfigurációhoz, fali papírokhoz, hívásnaplóhoz, korábbi naplókhoz stb.).

Az Android /data partíciójához a privát kulcsot mindig biztonságosan tárolták az Nvidia TrustZone határvonalán belül, vagy a SoC beépített titkosítási mechanizmusával titkosították. Room Navigator

A ce-11.25.x-ig, beleértve a másik kulcsot az EEPROM-ban tárolják. Bár az EEPROM nem érhető el bármely normál csatornán keresztül érkező felhasználók számára, erőszakkal eltávolítható az eszközről (a flash lemezzel együtt) a tartalom tényleges visszafejtése érdekében.

A ce-11.26.x-től kezdve a szokásos fájlrendszer titkosítási kulcsát az ARM TrustZone [0] alapú Nvidia megbízható végrehajtási környezetbe (TEE) helyezzük át, így a kulcsot nem lehet kinyerni az Nvidia SoC-ből. Mivel a biztonságos indítási folyamat megkerülésének egyetlen (ismert) módja a teljes Nvidia SoC cseréje, amely ezután eltávolítaná a kulcsot, a kulcs kibontása a CE-kód sebezhetőségeinek megtalálására korlátozódik, hogy olyan gyökérhéjat kapjon, amely elegendő engedélyekkel rendelkezik a kulcs megszerzéséhez.

Room NavigatorA migráció egy későbbi verzióban lesz.