Mulțumim pentru feedback.

Sistemul de fișiere de pe dispozitivele Board, Desk și Room Series este criptat folosind Linux Unified Key Setup (LUKS), standardul pentru criptarea hard disk-ului Linux. Cheia de criptare a sistemului de fișiere este salvată fie în NVRAM, fie în NOR-flash. În timpul unei resetări din fabrică, cheia este suprascrisă și nu poate fi recuperată, făcând nimic de pe disc imposibil de citit. Acest lucru face ca resetarea din fabrică să fie o metodă sigură de ștergere și ștergere a datelor în conformitate cu US DOD 5220.22M și NIST 800-88r1.

În timpul unei resetări din fabrică:

• Jurnalele de apeluri sunt șterse

• Frazele de acces sunt resetate la valoarea implicită

• Toți parametrii dispozitivului sunt resetați la valorile implicite

• Toate fișierele care au fost încărcate pe dispozitiv sunt șterse

• Imaginea anterioară (inactivă) a software-ului este ștearsă

• Tastele de opțiuni nu sunt afectate

Nu puteți anula o resetare din fabrică. Asigurați-vă că este necesar să faceți acest lucru, înainte de a începe.

NIST 800-88r1

Standardul NIST 800-88r1 specifică trei niveluri de igienizare:

• Curățați: Prote jați-vă împotriva tehnicilor de recuperare neinvazive

• Purge: Faceți recuperarea datelor imposibilă

• Distruge: Faceți recuperarea datelor imposibilă și împiedicați utilizarea viitoare

Secțiunea 2.6 a standardului vorbește despre utilizarea ștergerii criptografice (CE) și despre modul în care poate fi aplicată pentru a atinge nivelul de purjare.

Secțiunile 2.6.1 și 2.6.2 enumeră condițiile pentru momentul în care trebuie (nu) să se ia în considerare CE:

• Nu utilizați CE pentru a șterge suportul dacă criptarea a fost activată după ce datele sensibile au fost stocate pe dispozitiv fără a fi dezinfectate mai întâi.

• Nu utilizați CE dacă nu se știe dacă datele sensibile au fost stocate pe dispozitiv fără a fi igienizate înainte de criptare.

• Luați în considerare utilizarea CE atunci când toate datele destinate CE sunt criptate înainte de stocarea pe suport (inclusiv datele, precum și copiile virtualizate).

• Luați în considerare utilizarea CE atunci când cunoaștem locația (locațiile) de pe suportul media în care este stocată cheia de criptare (fie că este vorba de cheia de criptare a datelor țintă sau de o cheie de ambalare asociată) și putem dezinfecta acele zone folosind tehnica de igienizare specifică mediei corespunzătoare, asigurând că locația reală pe suportul în care este stocată cheia este adresată.

• Luați în considerare utilizarea CE atunci când putem ști că toate copiile cheilor de criptare care sunt utilizate pentru criptarea datelor țintă sunt igienizate.

• Luați în considerare utilizarea CE atunci când cheile de criptare ale datelor țintă sunt, ele însele, criptate cu una sau mai multe chei de ambalare și suntem încrezători că putem dezinfecta cheile de ambalare corespunzătoare.

• Luați în considerare utilizarea CE atunci când suntem încrezători în capacitatea utilizatorului de a identifica și utiliza în mod clar comenzile furnizate de dispozitiv pentru a efectua operația CE.

În RoomOS, sistemele de fișiere criptate care sunt utilizate pentru datele clienților sunt configurate și criptate la începutul pornirii inițiale, înainte de crearea oricăror date sensibile. Cheia este stocată așa cum este descris mai sus, fie în eeprom (software mai vechi), fie folosind mecanismele zonei de încredere ale SoC și poate fi igienizată în siguranță.

Cheia nu este niciodată salvată și nu există un mecanism de escrow cheie.

Având în vedere toate acestea, Cisco afirmă că mecanismul de resetare din fabrică din RoomOS este conform cu nivelul de purjare din NIST 800-88r1.

Criptarea datelor clientului

Criptarea discului

Dispozitivele folosesc un dispozitiv flash pentru stocarea în masă, unde ștergerea sigură este imposibil de garantat. Prin urmare, toate datele clienților de pe dispozitive sunt stocate pe sisteme de fișiere criptate, iar atunci când se efectuează o resetare la valorile implicite din fabrică, numai cheia de criptare este ștersă, făcând datele clientului inaccesibile.

Pentru a facilita acest lucru, creăm un fișier adecvat de mare pe flash-ul principal și folosim instrumentul standard Linux cryptsetup pentru a crea un dispozitiv loopback. Pe acest dispozitiv creăm un sistem standard de fișiere ext4. Detalii despre locul în care stocăm cheia de criptare sunt în secțiunea următoare.

Dispozitivul buclă este creat folosind LUKS1 cu o dimensiune a cheii de 512 biți și cifrul 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

În timpul funcționării regulate a dispozitivului, cryptsetup este utilizat pentru a decripta sistemele de fișiere înainte de a fi montate. Când cheia de criptare este ștersă, nu mai este posibilă configurarea dispozitivului buclă și montarea sistemelor de fișiere.

Cheia de criptare pe care o folosim este o citire de 20 de octeți din /dev/urandom, care este run-through sha1sum pentru a obține o reprezentare ascii. Cheia este generată la prima pornire după o resetare din fabrică și nu se modifică până când nu se efectuează o nouă resetare din fabrică.

Protecția cheii de criptare a datelor

Folosim două chei de criptare diferite pe dispozitivele noastre. Unul pentru partiția /data din interiorul containerului Android (pentru Microsoft MTR și Zoom) și unul pentru alte sisteme de fișiere (utilizate pentru configurarea clientului, hârtii de perete, jurnal de apeluri, jurnale istorice și așa mai departe).

Pentru partiția /data din Android, cheia privată a fost întotdeauna stocată în siguranță în interiorul limitei Nvidia TrustZone sau, pe ea, criptată folosind mecan Room Navigator ismul de criptare încorporat al SoC.

Până la și inclusiv ce-11.25.x, cealaltă cheie este stocată în EEPROM. În timp ce EEPROM este inaccesibil utilizatorilor care vin prin orice canal normal, acesta poate fi eliminat forțat de pe dispozitiv (împreună cu discul flash) pentru a decripta efectiv conținutul.

Începând cu ce-11.26.x mutăm cheia obișnuită de criptare a sistemului de fișiere în mediul de execuție de încredere Nvidia (TEE) bazat pe ARM TrustZone [0], astfel încât cheia nu va fi posibilă extragerea din Nvidia SoC. Deoarece singura modalitate (cunoscută) de a eluda procesul de pornire securizată este înlocuirea întregului SoC Nvidia, care ar elimina apoi cheia, extragerea cheii s-ar limita la găsirea vulnerabilităților în codul CE pentru a obține un shell root cu permisiuni suficiente pentru a obține cheia.

Pentru migr Room Navigator area va fi într-o versiune ulterioară.