Takk for tilbakemeldingen.

Filsystemet på Board, Desk og Room Series-enheter krypteres ved hjelp av Linux Unified Key Setup (LUKS), standarden for Linux-harddiskkryptering. Filsystemets krypteringsnøkkel lagres i enten NVRAM eller NOR-Flash. Under en fabrikkinnstilling blir nøkkelen overskrevet og kan ikke gjenopprettes, noe som gjør noe på disken uleselig. Dette gjør fabrikkinnstilling til en sikker metode for å slette og rense data i samsvar med US DOD 5220.22M og NIST 800-88r1.

Under en fabrikkinnstilling:

• Anropslogger slettes

• Passordfraser tilbakestilles til standard

• Alle enhetsparametere tilbakestilles til standardverdier

• Alle filer som er lastet opp til enheten slettes

• Det forrige (inaktive) programvarebildet slettes

• Alternativtastene påvirkes ikke

Du kan ikke angre en fabrikkinnstilling. Forsikre deg om at det er nødvendig å gjøre det, før du begynner.

NIST 800-88r1

NIST-standarden 800-88r1 spesifiserer tre nivåer av sanitering:

• Rengjør: Bes kytt mot ikke-invasive gjenopprettingsteknikker

• Rensing: Gjør datagjenoppretting umulig

• Ødelegg: Gjør datagjenoppretting umulig og forhindre fremtidig bruk

Seksjon 2.6 i standarden snakker om bruken av Cryptographic Erase (CE) og hvordan den kan brukes for å oppfylle Purge-nivået.

Avsnitt 2.6.1 og 2.6.2 viser betingelsene for når man (ikke) skal vurdere CE:

• Ikke bruk CE til å rense medier hvis krypteringen ble aktivert etter at sensitive data ble lagret på enheten uten å ha blitt renset først.

• Ikke bruk CE hvis det er ukjent om sensitive data ble lagret på enheten uten å bli renset før kryptering.

• Vurder å bruke CE når alle data beregnet for CE er kryptert før lagring på mediet (inkludert dataene, så vel som virtualiserte kopier).

• Vurder å bruke CE når vi kjenner plasseringen (e) på mediet der krypteringsnøkkelen er lagret (enten det er måldatas krypteringsnøkkel eller en tilknyttet pakningsnøkkel) og kan rense disse områdene ved hjelp av riktig mediespesifikk saniteringsteknikk, slik at den faktiske plasseringen på mediet der nøkkelen er lagret adresseres.

• Vurder å bruke CE når vi kan vite at alle kopier av krypteringsnøklene som brukes til å kryptere måldataene blir desinfisert.

• Vurder å bruke CE når måldataens krypteringsnøkler i seg selv er kryptert med en eller flere innpakningsnøkler, og vi er sikre på at vi kan rense de tilsvarende innpakningsnøklene.

• Vurder å bruke CE når vi er sikre på brukerens evne til tydelig å identifisere og bruke kommandoene som leveres av enheten for å utføre CE-operasjonen.

I RoomOS blir de krypterte filsystemene som brukes til kundedata satt opp og kryptert tidlig i den første oppstarten, før du oppretter sensitive data. Nøkkelen lagres som beskrevet ovenfor enten i eeprom (eldre programvare) eller ved hjelp av SoCs tillitssonemekanismer, og kan desinfiseres sikkert.

Nøkkelen blir aldri sikkerhetskopiert, og det er ingen nøkkelescrow-mekanisme.

Med alt dette i tankene hevder Cisco at fabrikkinnstillingsmekanismen i RoomOS er i samsvar med Purge-nivået i NIST 800-88r1.

Kundedatakryptering

Diskkryptering

Enhetene bruker en flash-enhet for masselagring, der sikker sletting er umulig å garantere. Alle kundedata på enhetene lagres derfor på krypterte filsystemer, og når en tilbakestilling til fabrikkinnstillinger utføres, blir bare krypteringsnøkkelen slettet, noe som gjør kundedataene utilgjengelige.

For å lette dette lager vi en passende stor fil på hovedblitsen og bruker standard Linux-verktøyet cryptsetup for å lage en loopback-enhet. På denne enheten oppretter vi et standard ext4-filsystem. Detaljer om hvor vi lagrer krypteringsnøkkelen er i neste avsnitt.

Loop-enheten er opprettet ved hjelp av LUKS1 med en nøkkelstørrelse på 512 biter 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 vanlig drift av enheten brukes cryptsetup til å dekryptere filsystemene før de er montert. Når krypteringsnøkkelen er slettet, er det ikke lenger mulig å sette opp loop-enheten og montere filsystemene.

Krypteringsnøkkelen vi bruker er en lesning på 20 byte fra /dev/urandom som er gjennomkjørt sha1sum for å få en ascii-representasjon. Nøkkelen genereres ved første oppstart etter en fabrikkinnstilling og endres ikke før en ny fabrikkinnstilling utføres.

Beskyttelse av datakrypteringsnøkkel

Vi bruker to forskjellige krypteringsnøkler på enhetene våre. En for /data-partisjonen inne i Android-beholderen (for Microsoft MTR og Zoom) og en for andre filsystemer (brukes til kundekonfigurasjon, veggpapir, anropslogg, historiske logger og så videre).

For /data-partisjonen i Android har den private nøkkelen alltid blitt lagret sikkert innenfor Nvidia TrustZone-grensen eller, på denRoom Navigator, kryptert ved hjelp av SoCs innebygde krypteringsmekanisme.

Opp til og med ce-11.25.x lagres den andre nøkkelen i EEPROM. Mens EEPROM er utilgjengelig for brukere som kommer gjennom en normal kanal, kan den fjernes med makt fra enheten (sammen med flashdisken) for å faktisk dekryptere innholdet.

Fra og med ce-11.26.x flytter vi den vanlige filsystemkrypteringsnøkkelen til Nvidia pålitelig eksekveringsmiljø (TEE) basert på ARM TrustZone [0], så nøkkelen vil ikke være mulig å trekke ut fra Nvidia SoC. Siden den eneste (kjente) måten å omgå den sikre oppstartsprosessen er å erstatte hele Nvidia SoC, som deretter vil fjerne nøkkelen, vil nøkkelutvinning være begrenset til å finne sårbarheter i CE-koden for å få et rotskall med tilstrekkelige tillatelser til å skaffe nøkkelen.

For migr Room Navigator eringen vil være i en senere versjon.