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

Under en tilbakestilling til fabrikkinnstillinger:

• Anropslogger slettes

• Passord tilbakestilles til standard

• Alle enhetsparametere tilbakestilles til standardverdier

• Alle filer som er lastet opp til enheten, slettes

• Den forrige (inaktive) programvareavbildningen slettes

• Alternativtastene påvirkes ikke

Du kan ikke angre en tilbakestilling til fabrikkinnstillinger. 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 desinfisering:

• Rengjør: Beskytt mot ikke-invasive gjenopprettingsteknikker

• Purge: Gjør datagjenoppretting umulig

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

Avsnitt 2.6 i standarden snakker om bruken av kryptografisk sletting (CE) og hvordan den kan brukes for å oppfylle rensenivået.

Punkt 2.6.1 og 2.6.2 lister opp vilkårene for når man (ikke) skal vurdere CE:

• Ikke bruk CE til å tømme 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, samt virtualiserte kopier).

• Vurder å bruke CE når vi kjenner stedene på mediet der krypteringsnøkkelen er lagret (det være seg måldataens krypteringsnøkkel eller en tilknyttet innpakningsnøkkel) og kan rense disse områdene ved hjelp av riktig mediespesifikk desinfiseringsteknikk, slik at den faktiske plasseringen på media der nøkkelen er lagret, blir adressert.

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

• Vurder å bruke CE når måldataens krypteringsnøkler 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 sensitive data opprettes. 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økkelsperremekanisme.

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

Kryptering av kundedata

Disk kryptering

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 fabrikkinnstillingene utføres, slettes bare krypteringsnøkkelen, noe som gjør kundedataene utilgjengelige.

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

Sløyfeenheten er opprettet ved hjelp av LUKS1 med en nøkkelstørrelse på 512 bits og aes-xts-plain64-krypteringen:

 $ cryptsetup status /dev/mapper/config /dev/mapper/config er aktiv og er i bruk. type: LUKS1 chiffer: aes-xts-plain64 keysize: 512 bits nøkkelplassering: dm-krypt enhet: / dev / loop5 loop: / mnt / base / image1 / rwfs / config.img sektorstørrelse: 512 offset: 4096 sektorer størrelse: 61440 sektorer modus: lese / skrive

Under vanlig drift av enheten brukes kryptoppsettet til å dekryptere filsystemene før de monteres. Når krypteringsnøkkelen slettes, er det ikke lenger mulig å sette opp sløyfeenheten og montere filsystemene.

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

Beskyttelse av datakrypteringsnøkkel

Vi bruker to forskjellige krypteringsnøkler på enhetene våre. En for /data-partisjonen 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å Room Navigator, kryptert ved hjelp av SoCs innebygde krypteringsmekanisme.

Til og med ce-11.25.x lagres den andre nøkkelen i EEPROM. Mens EEPROM er utilgjengelig for brukere som kommer gjennom en vanlig 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 trusted execution environment (TEE) basert på ARM TrustZone[0], slik at nøkkelen ikke vil 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 Romnavigatør vil migreringen være i en senere versjon.