Kiitos palautteestasi.

Board-, Desk- ja Room Series -laitteiden tiedostojärjestelmä salataan Linux Unified Key Setup (LUKS) -sovelluksella, joka on Linux-kiintolevyn salauksen standardi. Tiedostojärjestelmän salausavain tallennetaan joko NVRAM-muistiin tai NOR-flash-muistiin. Tehdasasetusten palautuksen aikana avain korvataan eikä sitä voida palauttaa, jolloin kaikki levyllä olevat tiedot ovat lukukelvottomia. Tämä tekee tehdasasetusten palauttamisesta turvallisen tavan poistaa ja tyhjentää tietoja Yhdysvaltain DOD 5220.22M: n ja NIST 800-88r1: n mukaisesti.

Tehdasasetusten palautuksen aikana:

• Puhelulokit poistetaan

• Salasanat palautetaan oletusarvoisiksi

• Kaikki laitteen parametrit palautetaan oletusarvoihin

• Kaikki laitteeseen ladatut tiedostot poistetaan

• Edellinen (passiivinen) ohjelmistokuva poistetaan

• Valintanäppäimet eivät vaikuta

Tehdasasetusten palauttamista ei voi kumota. Varmista, että se on välttämätöntä, ennen kuin aloitat.

NIST 800-88r1

NIST-standardi 800-88r1 määrittelee kolme desinfiointitasoa:

• Puhdas: Su ojaa ei-invasiivisilta palautustekniikoilta

• Puhdista: Tee tietojen palauttaminen mahdottomaksi

• Tuhoa: Tee tietojen palauttaminen mahdottomaksi ja estä tuleva käyttö

Standardin kohdassa 2.6 puhutaan salauspyyhkimisen (CE) käytöstä ja siitä, miten sitä voidaan soveltaa Purge-tason täyttämiseen.

Kohdissa 2.6.1 ja 2.6.2 luetellaan edellytykset sille, milloin (ei) ottaa huomioon CE:

• Älä käytä CE: tä tallennusvälineiden puhdistamiseen, jos salaus on otettu käyttöön sen jälkeen, kun arkaluonteiset tiedot on tallennettu laitteeseen ilman, että niitä on ensin puhdistettu.

• Älä käytä CE: tä, jos ei tiedetä, tallennettiinko arkaluonteisia tietoja laitteeseen puhdistamatta niitä ennen salausta.

• Harkitse CE: n käyttöä, kun kaikki CE: lle tarkoitetut tiedot on salattu ennen tallentamista tietovälineelle (mukaan lukien tiedot sekä virtualisoidut kopiot).

• Harkitse CE:n käyttöä, kun tiedämme tietovälineen sijainnit, joihin salausavain on tallennettu (olipa kyseessä kohdetiedon salausavain tai siihen liittyvä käärimisavain) ja voimme puhdistaa kyseiset alueet asianmukaisella tietovälinekohtaisella puhdistustekniikalla varmistaen, että todellinen sijainti tietovälineessä, johon avain on tallennettu, on osoitettu.

• Harkitse CE: n käyttöä, kun voimme tietää, että kaikki kohdetietojen salaamiseen käytettyjen salausavainten kopiot puhdistetaan.

• Harkitse CE: n käyttöä, kun kohdetietojen salausavaimet itsessään on salattu yhdellä tai useammalla kääreavaimella ja olemme varmoja, että voimme puhdistaa vastaavat käärimisavaimet.

• Harkitse CE: n käyttöä, kun olemme varmoja käyttäjän kyvystä tunnistaa ja käyttää selvästi laitteen antamia komentoja CE-toiminnon suorittamiseen.

RoomOS: ssä salatut tiedostojärjestelmät, joita käytetään asiakastietoihin, määritetään ja salataan alkuvaiheessa ennen arkaluonteisten tietojen luomista. Avain tallennetaan yllä kuvatulla tavalla joko eepromissa (vanhempi ohjelmisto) tai käyttämällä SoC: n luottamusvyöhykemekanismeja, ja se voidaan puhdistaa turvallisesti.

Avainta ei koskaan varmuuskopioida eikä avainten sulkemismekanismia ole.

Kaiken tämän mielessä Cisco väittää, että RoomOS: n tehdasasetusten palautusmekanismi on yhteensopiva NIST 800-88r1: n Puhdistustason kanssa.

Asiakastietojen salaus

Levyn salaus

Laitteet käyttävät massamallennukseen flash-laitetta, jossa turvallista poistoa on mahdotonta taata. Kaikki laitteiden asiakastiedot tallennetaan siten salattuihin tiedostojärjestelmiin, ja kun tehdasasetuksiin palautetaan, vain salausavain poistetaan, jolloin asiakastiedot eivät ole käytettävissä.

Tämän helpottamiseksi luomme sopivan suuren tiedoston pääsalamaan ja luomme loopback-laitteen vakiomuotoisella Linux-työkalulla cryptsetup. Tällä laitteella luomme tavallisen ext4-tiedostojärjestelmän. Yksityiskohdat siitä, mihin tallennamme salausavaimen, ovat seuraavassa osassa.

Silmukkalaite luodaan LUKS1: llä, jonka avaimen koko on 512 bittiä, ja aes-xts-plain64-salauksella:

 $ 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

Laitteen säännöllisen käytön aikana cryptsetupia käytetään tiedostojärjestelmien purkamiseen ennen niiden asentamista. Kun salausavain poistetaan, silmukkalaitetta ei voi enää asentaa ja asentaa tiedostojärjestelmiä.

Käyttämämme salausavain on 20 tavun lukema tiedostosta /dev/urandom, joka on suoritettu läpi sha1sum ascii-esityksen saamiseksi. Avain luodaan ensimmäisessä käynnistyksessä tehdasasetusten palauttamisen jälkeen, eikä se muutu ennen kuin uusi tehdasasetusten palautus suoritetaan.

Tietojen salausavaimen suojaus

Käytämme laitteissamme kahta eri salausavainta. Yksi Android-säilön sisällä olevalle /data-osiolle (Microsoft MTR- ja Zoomille) ja toinen muille tiedostojärjestelmille (käytetään asiakkaan kokoonpanoon, seinäpapereihin, puhelulokiin, historiallisiin lokeihin jne.).

Androidin /data-osiossa yksityinen avain on aina tallennettu turvallisesti Nvidia TrustZone -rajan sisällä tai salattu SoC Room Navigator :n sisäänrakennetulla salausmekanismilla.

Mukaan ce-11.25.x asti toinen avain on tallennettu EEPROMiin. Vaikka EEPROM ei ole käytettävissä minkään normaalin kanavan kautta tuleville käyttäjille, se voidaan poistaa väkisin laitteesta (yhdessä flash-levyn kanssa) sisällön purkamiseksi.

Ce-11.26.x: stä alkaen siirrämme tavallisen tiedostojärjestelmän salausavaimen Nvidian luotettuun suoritusympäristöön (TEE), joka perustuu ARM TrustZone [0] -järjestelmään, joten avainta ei voida purkaa Nvidia SoC: stä. Koska ainoa (tunnettu) tapa kiertää suojattu käynnistysprosessi on korvata koko Nvidia SoC, joka sitten poistaisi avaimen, avaimen poiminta rajoittuisi haavoittuvuuksien löytämiseen CE-koodista, jotta saadaan juurikuori, jolla on riittävät oikeudet avaimen hankkimiseen.

Siir Room Navigator to tapahtuu myöhemmässä versiossa.