Hartelijk dank voor uw feedback

Het bestandssysteem op apparaten uit de Board-, Desk- en Room-serie is versleuteld met Linux Unified Key Setup (LUKS), de standaard voor versleuteling van harde schijven in Linux. De coderingssleutel van het bestandssysteem wordt opgeslagen in NVRAM of NOR Flash. Tijdens een fabrieksreset wordt de sleutel overschreven en kan deze niet worden hersteld, waardoor alles op de schijf onleesbaar wordt. Dit maakt van de fabrieksinstellingen een veilige methode om gegevens te verwijderen en te wissen in overeenstemming met de Amerikaanse DOD 5220.22M en NIST 800-88r1.

Tijdens een fabrieksreset:

• Oproeplogboeken worden verwijderd

• Wachtwoordzinnen worden teruggezet naar de standaardwaarden

• Alle apparaatparameters worden teruggezet naar de standaardwaarden

• Alle bestanden die naar het apparaat zijn geüpload, worden verwijderd

• De vorige (inactieve) softwarekopie is verwijderd

• Optietoetsen worden niet beïnvloed

U kunt een fabrieksreset niet ongedaan maken. Zorg ervoor dat dit nodig is voordat u begint.

NIST 800-88r1

De NIST-standaard 800-88r1 specificeert drie niveaus van ontsmetting:

• Schoon: bescherm uzelf tegen niet-invasieve hersteltechnieken

• Purge: gegevensherstel onmogelijk maken

• Vernietigen: gegevensherstel onmogelijk maken en toekomstig gebruik voorkomen

Paragraaf 2.6 van de standaard gaat over het gebruik van Cryptographic Erase (CE) en hoe dit kan worden toegepast om aan het Purge-niveau te voldoen.

Paragraaf 2.6.1 en 2.6.2 somt de voorwaarden op om CE (niet) te overwegen:

• Gebruik CE niet om media te wissen als de versleuteling is ingeschakeld nadat gevoelige gegevens op het apparaat zijn opgeslagen zonder eerst te zijn ontsmet.

• Gebruik CE niet als niet bekend is of gevoelige gegevens op het apparaat zijn opgeslagen zonder dat ze vóór de versleuteling zijn ontsmet.

• Overweeg om CE te gebruiken wanneer alle gegevens die bestemd zijn voor CE gecodeerd zijn voordat ze op de media worden opgeslagen (inclusief de gegevens, evenals gevirtualiseerde kopieën).

• Overweeg om CE te gebruiken als we de locatie (s) op het medium kennen waar de coderingssleutel is opgeslagen (of het nu de coderingssleutel van de doelgegevens is of een bijbehorende verpakkingssleutel) en die gebieden kunnen ontsmetten met behulp van de juiste mediaspecifieke saneringstechniek, waarbij ervoor wordt gezorgd dat de werkelijke locatie op het medium waar de sleutel is opgeslagen, wordt geadresseerd.

• Overweeg om CE te gebruiken als we weten dat alle kopieën van de coderingssleutels die worden gebruikt om de doelgegevens te versleutelen, gezuiverd zijn.

• Overweeg om CE te gebruiken wanneer de coderingssleutels van de doelgegevens zelf zijn versleuteld met een of meer inpaksleutels en we zijn ervan overtuigd dat we de bijbehorende inpaksleutels kunnen ontsmetten.

• Overweeg om CE te gebruiken als we er zeker van zijn dat de gebruiker de opdrachten van het apparaat duidelijk kan identificeren en gebruiken om de CE-bewerking uit te voeren.

In RoomOS worden de versleutelde bestandssystemen die worden gebruikt voor klantgegevens al vroeg bij de eerste keer opstarten ingesteld en versleuteld, voordat er gevoelige gegevens worden aangemaakt. De sleutel wordt opgeslagen zoals hierboven beschreven in eeprom (oudere software) of met behulp van de vertrouwenszonemechanismen van de SoC, en kan veilig worden ontsmet.

Er wordt nooit een back-up van de sleutel gemaakt en er is geen sleutelescrow-mechanisme.

Met dit alles in het achterhoofd beweert Cisco dat het mechanisme voor het terugzetten van de fabrieksinstellingen in RoomOS voldoet aan het Purge-niveau in NIST 800-88r1.

Encryptie van klantgegevens

Schijfversleuteling

De apparaten gebruiken een flashapparaat voor massaopslag, waarbij een veilige verwijdering niet kan worden gegarandeerd. Alle klantgegevens op de apparaten worden daarom opgeslagen op versleutelde bestandssystemen, en wanneer een reset naar de fabrieksinstellingen wordt uitgevoerd, wordt alleen de coderingssleutel verwijderd, waardoor de klantgegevens ontoegankelijk worden.

Om dit mogelijk te maken, maken we een voldoende groot bestand op de hoofdflash en gebruiken we de standaard Linux-tool cryptsetup om een loopback-apparaat te maken. Op dit apparaat maken we een standaard ext4-bestandssysteem. Informatie over waar we de coderingssleutel opslaan, vindt u in de volgende sectie.

Het loopapparaat is gemaakt met LUKS1 met een sleutelgrootte van 512 bits en het aes-xts-plain64-cijfer:

 $ 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

Tijdens het normale gebruik van het apparaat wordt de cryptsetup gebruikt om de bestandssystemen te decoderen voordat ze worden gemount. Wanneer de coderingssleutel wordt verwijderd, is het niet langer mogelijk om het loopapparaat in te stellen en de bestandssystemen te koppelen.

De coderingssleutel die we gebruiken is een leeswaarde van 20 bytes uit /dev/urandom, wat sha1sum wordt doorlopen om een ascii-representatie te krijgen. De sleutel wordt gegenereerd bij de eerste keer opstarten na een fabrieksreset en wordt niet gewijzigd totdat een nieuwe fabrieksreset wordt uitgevoerd.

Beveiliging van sleutels voor gegevenscodering

We gebruiken twee verschillende coderingssleutels op onze apparaten. Eén voor de /data-partitie in de Android-container (voor Microsoft MTR en Zoom) en één voor andere bestandssystemen (gebruikt voor klantconfiguratie, wallpapers, gesprekslogboeken, historische logboeken, enzovoort).

Voor de /data-partitie in Android is de privésleutel altijd veilig opgeslagen binnen de Nvidia TrustZone-grens of, op deRoom Navigator, versleuteld met behulp van het ingebouwde coderingsmechanisme van de SoC.

Tot en met ce-11.25.x wordt de andere sleutel opgeslagen in EEPROM. Hoewel EEPROM niet toegankelijk is voor gebruikers die via een normaal kanaal komen, kan het met geweld van het apparaat worden verwijderd (samen met de flashdisk) om de inhoud daadwerkelijk te ontsleutelen.

Vanaf ce-11.26.x verplaatsen we de normale coderingssleutel voor het bestandssysteem naar de Nvidia Trusted Execution Environment (TEE) op basis van ARM TrustZone [0], zodat de sleutel niet kan worden geëxtraheerd uit de Nvidia SoC. Aangezien de enige (bekende) manier om het veilige opstartproces te omzeilen is door de volledige Nvidia SoC te vervangen, waarbij dan de sleutel wordt verwijderd, zou de sleutelextractie beperkt blijven tot het vinden van kwetsbaarheden in de CE-code om een rootshell te krijgen met voldoende machtigingen om de sleutel te verkrijgen.

Want Room Navigator de migratie zal in een latere versie plaatsvinden.