Sistemul de fișiere de pe dispozitivele din seriile Board, Desk și Room 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ă în NVRAM sau NOR-flash. În timpul unei resetări la setările din fabrică, cheia este suprascrisă și nu poate fi recuperată, făcând nimic de pe disc ilizibil. Acest lucru face ca resetarea la setările 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 la setările din fabrică:

  • Jurnalele de apeluri sunt șterse

  • Frazele de acces sunt resetate la valorile implicite

  • 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 la setările din fabrică. Asigurați-vă că este necesar să faceți acest lucru, înainte de a începe.

Vă recomandăm să utilizați interfața web sau interfața cu utilizatorul pentru a reseta dispozitivul la setările din fabrică. Ar trebui să faceți o copie de rezervă a fișierelor jurnal, a configurațiilor și a elementelor particularizate ale dispozitivului înainte de a efectua o resetare la setările din fabrică; în caz contrar, aceste date se vor pierde. Consultați Ghidul de administrare pentru informații despre diferitele moduri de copiere de rezervă și resetare a dispozitivului.

NIST 800-88r1

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

  • Clean: Protecție împotriva tehnicilor de recuperare neinvazive

  • Ștergere: Faceți recuperarea datelor imposibilă

  • Distrugere: 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 în care (nu) trebuie să se ia în considerare CE:

  • Nu utilizați CE pentru curățarea suporturilor dacă criptarea a fost activată după ce datele sensibile au fost stocate pe dispozitiv fără a fi fost igienizate mai întâi.

  • Nu utilizați CE dacă nu se cunoaște 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țiile de pe suportul media unde este stocată cheia de criptare (fie că este vorba de cheia de criptare a datelor țintă sau de o cheie de împachetare asociată) și putem igieniza acele zone folosind tehnica adecvată de igienizare specifică suportului, asigurându-ne 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 dezinfectate.

  • 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 împachetare și suntem încrezători că putem igieniza cheile de împachetare corespunzătoare.

  • Luați în considerare utilizarea CE atunci când suntem siguri de 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 încărcării 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 SoC și poate fi igienizată în siguranță.

Cheia nu este niciodată copiată de rezervă și nu există niciun mecanism de escrow cheie.

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

Criptarea datelor clienților

Criptare disc

Dispozitivele utilizează 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 în sisteme de fișiere criptate, iar atunci când se efectuează o resetare la valorile implicite din fabrică, numai cheia de criptare este ștearsă, făcând datele clienților inaccesibile.

Pentru a facilita acest lucru, creăm un fișier suficient de mare pe blițul principal și folosim criptsetup standard al instrumentului Linux pentru a crea un dispozitiv loopback. Pe acest dispozitiv creăm un sistem de fișiere ext4 standard. 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 este activ și este în uz. Tip: LUKS1 cifru: AES-XTS-Plain64 KeySize: 512 biți Locație cheie: DM-crypt Dispozitiv: /dev/loop5 buclă: /mnt/base/image1/rwfs/config.img Dimensiunea sectorului: 512 decalaj: 4096 sectoare Dimensiune: 61440 sectoare Mod: citire/scriere

În timpul funcționării obișnuite a dispozitivului, criptsetup-ul este utilizat pentru a decripta sistemele de fișiere înainte ca acestea să fie montate. Când cheia de criptare este ștearsă, nu mai este posibilă configurarea dispozitivului de buclă și montarea sistemelor de fișiere.

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

Protecția cheii de criptare a datelor

Folosim două chei de criptare diferite pe dispozitivele noastre. Unul pentru partiția /data din containerul 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 etc.).

Pentru partiția /data din Android, cheia privată a fost întotdeauna stocată în siguranță în interiorul graniței Nvidia TrustZone sau, pe Room Navigator, criptată folosind mecanismul 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 putea fi extrasă 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 ar fi limitată la găsirea vulnerabilităților în codul CE pentru a obține un shell rădăcină cu permisiuni suficiente pentru a obține cheia.

Pentru Room Navigator migrarea va avea loc într-o versiune ulterioară.