Tak for din feedback.

Filsystemet på Board-, Desk- og Room Series-enheder 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 fabriksindstilling overskrives nøglen og kan ikke gendannes, hvilket gør noget på disken ulæseligt. Dette gør fabriksindstilling til en sikker metode til sletning og rensning af data i overensstemmelse med US DOD 5220.22M og NIST 800-88r1.

Under en fabriksindstilling:

• Opkaldslogfiler slettes

• Adgangssætninger nulstilles til standard

• Alle enhedsparametre nulstilles til standardværdier

• Alle filer, der er uploadet til enheden, slettes

• Det forrige (inaktive) softwarebillede slettes

• Indstillingstaster påvirkes ikke

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

NIST 800-88r1

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

• Rengør: Bes kyt mod ikke-invasive genopretningsteknikker

• Rensning: Gør datagendannelse umulig

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

Afsnit 2.6 i standarden taler om brugen af Cryptographic Erase (CE), og hvordan den kan anvendes til at opfylde Purge-niveauet.

Afsnit 2.6.1 og 2.6.2 indeholder en liste over 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 ikke er kendt, om følsomme data blev gemt på enheden uden at blive renset før kryptering.

• Overvej at bruge CE, når alle data, der er beregnet til CE, er krypteret før lagring på mediet (inklusive data, såvel som virtualiserede kopier).

• Overvej at bruge CE, når vi kender placeringen (e) på mediet, hvor krypteringsnøglen er gemt (det være sig måldatas krypteringsnøgle eller en tilknyttet indpakningsnøgle) og kan rense disse områder ved hjælp af den relevante mediespecifikke saneringsteknik, hvilket sikrer, at den faktiske placering på mediet, 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, renses.

• Overvej at bruge CE, når måldataens krypteringsnøgler i sig selv er krypteret med en eller flere indpakningsnøgler, og vi er overbeviste om, at vi kan rense 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-operationen.

I RoomOS oprettes og krypteres de krypterede filsystemer, der bruges til kundedata, tidligt i den første 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øgleescrow-mekanisme.

Med alt dette i tankerne hævder Cisco, at fabriksindstillingsmekanismen i RoomOS er i overensstemmelse med Purge-niveauet i NIST 800-88r1.

Kundedatakryptering

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 en nulstilling til fabriksindstillinger udføres, 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 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

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.

Krypteringsnøglen, vi bruger, er en læsning på 20 bytes fra/dev/urandom, som er gennemkørende sha1sum for at få en ascii-repræsentation. Nøglen genereres ved den første opstart efter en fabriksindstilling og ændres ikke, før en ny fabriksindstilling 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ægpapir, opkaldslog, historiske logfiler osv.).

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

Op til og med ce-11.25.x gemmes den anden nøgle i EEPROM. Mens EEPROM er utilgængelig for brugere, der kommer gennem en 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 på er at erstatte 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 migr Room Navigator eringen vil være i en senere version.