Filsystemet på enheder i Board-, Desk- og Room-serien krypteres ved hjælp af Linux Unified Key Setup (LUKS), standarden for Linux-harddiskkryptering. Filsystemets krypteringsnøgle gemmes i enten NVRAM eller NOR-flash. Under en fabriksnulstilling overskrives nøglen, og den kan ikke gendannes, så der ikke kan genoprettes noget på disken. Dette gør fabriksnulstilling til en sikker metode til sletning og sletning af data i overensstemmelse med US DOD 5220.22M og NIST 800-88r1.

Under en fabriksnulstilling:

• Opkaldslogfiler slettes

• Adgangskoder nulstilles til standard

• Alle enhedsparametre nulstilles til standardværdier.

• Alle filer, der er overført til enheden, slettes

• Den forrige (inaktive) softwareafbildning slettes

• Valgtasterne påvirkes ikke

Du kan ikke fortryde en fabriksnulstilling. Sørg for, at det er nødvendigt, før du starter.

NIST 800-88R1

NIST-standarden 800-88r1 specificerer tre niveauer af desinficering:

• Ren: Beskyt mod ikke-invasive genopretningsteknikker

• Udrensning: Gør datagendannelse umulig

• Ødelægge: Gør datagendannelse umulig og forhindre fremtidig brug

Afsnit 2.6 i standarden taler om brugen af kryptografisk sletning (CE), og hvordan den kan anvendes til at opfylde rensningsniveauet.

Afsnit 2.6.1 og 2.6.2 angiver betingelserne for, hvornår man (ikke) skal overveje CE:

• Brug ikke CE til at rense medier, hvis krypteringen blev aktiveret, efter at følsomme data blev gemt på enheden uden først at være blevet renset.

• Brug ikke CE, hvis det er ukendt, om følsomme data blev gemt på enheden uden at blive desinficeret før kryptering.

• Overvej at bruge CE, når alle data, der er beregnet til CE, krypteres før lagring på mediet (inklusive dataene samt virtualiserede kopier).

• Overvej at bruge CE, når vi kender de steder på mediet, hvor krypteringsnøglen er gemt (det være sig måldataenes krypteringsnøgle eller en tilhørende indpakningsnøgle) og kan desinficere disse områder ved hjælp af den passende mediespecifikke desinficeringsteknik, hvilket sikrer, at den faktiske placering på medier, hvor nøglen er gemt, adresseres.

• Overvej at bruge CE, når vi kan vide, at alle kopier af krypteringsnøglerne, der bruges til at kryptere måldataene, er desinficeret.

• Overvej at bruge CE, når måldataenes krypteringsnøgler selv er krypteret med en eller flere indpakningsnøgler, og vi er overbeviste om, at vi kan desinficere de tilsvarende indpakningsnøgler.

• Overvej at bruge CE, når vi er sikre på brugerens evne til klart at identificere og bruge de kommandoer, der leveres af enheden til at udføre CE-handlingen.

I RoomOS konfigureres og krypteres de krypterede filsystemer, der bruges til kundedata, tidligt i den indledende opstart, inden der oprettes følsomme data. Nøglen gemmes som beskrevet ovenfor enten i eeprom (ældre software) eller ved hjælp af SoC's tillidszonemekanismer og kan desinficeres sikkert.

Nøglen sikkerhedskopieres aldrig, og der er ingen nøgledeponeringsmekanisme.

Med alt dette i tankerne hævder Cisco, at fabriksnulstillingsmekanismen i RoomOS er kompatibel med rensningsniveauet i NIST 800-88r1.

Kryptering af kundedata

Diskkryptering

Enhederne bruger en flash-enhed til masselagring, hvor sikker sletning er umulig at garantere. Alle kundedata på enhederne gemmes derfor på krypterede filsystemer, og når der foretages en nulstilling til fabriksindstillingerne, slettes kun krypteringsnøglen, hvilket gør kundedataene utilgængelige.

For at lette dette opretter vi en passende stor fil på hovedflashen og bruger standard Linux-værktøjet cryptsetup til at oprette en loopback-enhed. På denne enhed opretter vi et standard ext4-filsystem. Detaljer om, hvor vi gemmer krypteringsnøglen, findes i næste afsnit.

Loop-enheden oprettes ved hjælp af LUKS1 med en nøglestørrelse på 512 bit og aes-xts-plain64-krypteringen:

 $ cryptsetup status / dev / mapper / config / dev / mapper / config er aktiv og er i brug. type: LUKS1 chiffer: aes-xts-plain64 nøglestørrelse: 512 bit nøgle placering: dm-crypt enhed: / dev / loop5 loop: / mnt / base / image1 / rwfs / config.img sektor størrelse: 512 forskydning: 4096 sektorer størrelse: 61440 sektorer tilstand: læse / skrive

Under regelmæssig drift af enheden bruges cryptsetup til at dekryptere filsystemerne, før de monteres. Når krypteringsnøglen slettes, er det ikke længere muligt at konfigurere loop-enheden og montere filsystemerne.

Den krypteringsnøgle, vi bruger, er en læsning af 20 bytes fra / dev / urandom, som køres gennem sha1sum for at få en ascii-repræsentation. Nøglen genereres ved den første opstart efter en fabriksnulstilling og ændres ikke, før en ny fabriksnulstilling udføres.

Beskyttelse af datakrypteringsnøgle

Vi bruger to forskellige krypteringsnøgler på vores enheder. En til /data-partitionen inde i Android-containeren (til Microsoft MTR og Zoom) og en til andre filsystemer (bruges til kundekonfiguration, vægpapirer, opkaldslog, historiske logfiler osv.).

For partitionen /data i Android har den private nøgle altid været gemt sikkert inden for Nvidia TrustZone-grænsen eller, på Room Navigator, krypteret ved hjælp af SoC's indbyggede krypteringsmekanisme.

Til og med ce-11.25.x gemmes den anden nøgle i EEPROM. Mens EEPROM er utilgængelig for brugere, der kommer gennem enhver normal kanal, kan den fjernes med magt fra enheden (sammen med flashdisken) for faktisk at dekryptere indholdet.

Fra og med ce-11.26.x flytter vi den almindelige filsystemkrypteringsnøgle til Nvidia trusted execution environment (TEE) baseret på ARM TrustZone[0], så nøglen vil ikke være mulig at udtrække fra Nvidia SoC. Da den eneste (kendte) måde at omgå den sikre opstartsproces er at udskifte hele Nvidia SoC, som derefter fjerner nøglen, ville nøgleekstraktion være begrænset til at finde sårbarheder i CE-koden for at få en rodskal med tilstrækkelige tilladelser til at få nøglen.

For Room Navigator vil overførslen være i en senere version.