Het bestandssysteem aan boord, Desk en Room Series apparaten wordt versleuteld met Linux Unified Key Setup (LUKS), de standaard voor Linux-vaste schijfcodering. De coderingssleutel van het bestandssysteem wordt opgeslagen in NVRAM of NOR-flash. Bij het terugzetten van fabrieksinstellingen wordt de sleutel overschreven en kan niet worden hersteld, waardoor alles op de schijf onleesbaar wordt. Dat maakt dat de fabriek opnieuw wordt ingesteld in overeenstemming met US DOD 5220.22M en NIST 800-88r1.

Bij het terugzetten van fabrieksinstellingen:

  • Gesprekslogs worden verwijderd

  • Wachtwoordzinnen worden teruggezet op de standaardwaarde

  • Alle apparaatparameters worden teruggezet op de standaardwaarden

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

  • De vorige (inactieve) software-image wordt verwijderd

  • De optietoetsen worden niet beïnvloed

Terugzetten naar fabrieksinstellingen kan niet ongedaan worden gemaakt. Verzeker u ervan dat het echt nodig is, voordat u begint.

Wij raden u aan de webinterface of gebruikersinterface te gebruiken om het de fabrieksinstellingen van het apparaat terug te zetten. Maak een back-up van de logbestanden, configuraties en aangepaste elementen van het apparaat voordat u de fabrieksinstellingen terugzet, anders gaan deze gegevens verloren. Raadpleeg de Beheerdershandleiding voor informatie over verschillende manieren om een back-up van uw apparaat te maken en deze opnieuw in te stellen.

NIST 800-88r1

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

  • Schoonmaken: beveiligt tegen niet-grote hersteltechnieken

  • Opschonen: maak gegevensherstel onhaalbaar

  • Vernietigen: maak gegevensherstel onhaalbaar en voorkomen toekomstig gebruik

In sectie 2.6 van de standaard wordt gesproken over het gebruik van CE (Cryptoic Erase) en hoe deze kunnen worden toegepast op het niveau voor opschonen.

In sectie 2.6.1 en 2.6.2 worden de voorwaarden beschreven voor wanneer CE wel (niet) moet worden gebruikt:

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

  • Gebruik CE niet als onbekend is of gevoelige gegevens op het apparaat zijn opgeslagen zonder te worden ontsmet voorafgaand aan codering.

  • Overweeg het gebruik van CE wanneer alle gegevens die zijn bestemd voor CE, worden versleuteld voordat de media worden opgeslagen (inclusief de gegevens en virtuele kopieën).

  • Overweeg het gebruik van CE wanneer we op de hoogte zijn van de locaties op de media waar de coderingssleutel wordt opgeslagen (of het nu de codeersleutel van de doelgegevens of een bijbehorende afrondingssleutel betreft) en de gebieden met de juiste mediaspecifieke ontsmettingstechniek kunnen worden opgeslagen, waarbij u ervoor zorgt dat de daadwerkelijke locatie op de media waar de sleutel is opgeslagen, wordt geadresseerd.

  • Overweeg het gebruik van CE wanneer we weten dat alle kopieën van de coderingssleutels die worden gebruikt voor het coderen van de doelgegevens, worden ontsmet.

  • Overweeg het gebruik van CE wanneer de encryptiesleutels van de doelgegevens zelf zijn gecodeerd met een of meer afrondingssleutels en we zijn er zeker van dat we de bijbehorende afrondingssleutels kunnen ontsmetten.

  • Overweeg het gebruik van CE wanneer we er zeker van zijn dat de gebruiker de opdrachten die het apparaat biedt voor het uitvoeren van de CE-bewerking duidelijk kan identificeren en gebruiken.

De versleutelde bestandssystemen die voor klantgegevens worden gebruikt, worden in RoomOS ingesteld en vroeg tijdens het opstarten geconfigureerd en versleuteld, voorafgaand aan het maken van eventuele gevoelige gegevens. De sleutel wordt zoals hierboven beschreven opgeslagen in eeprom (oudere software) of met behulp van de mechanismen van de trustzone van de SoC, en kan veilig worden ontsmet.

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

Met al dit in gedachten beweert Cisco dat het mechanisme voor het resetten van de fabriek in RoomOS voldoet aan het opschoonniveau in NIST 800-88r1.

Encryptie van klantgegevens

Schijfcodering

De apparaten gebruiken een flash-apparaat voor massaopslag, waarbij veilig verwijderen onmogelijk is te garanderen. Alle klantgegevens op de apparaten worden daarom opgeslagen op gecodeerde bestandssystemen, en wanneer een reset naar de fabrieksstandaarden wordt uitgevoerd, wordt alleen de coderingssleutel verwijderd, waardoor de klantgegevens niet meer toegankelijk zijn.

Om dit te vergemakkelijken, maken we een ruim bestand op de hoofdflitser en gebruiken de standaard Linux-tool cryptsetup om een loopbackapparaat te maken. Op dit apparaat maken we een standaard ext4 bestandssysteem. Details over waar de coderingssleutel wordt opgeslagen, vindt u in de volgende sectie.

Het lusapparaat is gemaakt van LUKS1 met de sleutelgrootte 512 bits en de aes-xts-plain64-code:

 $ cryptsetup status /dev/mapper/config /dev/mapper/config is actief en in gebruik. Type: LUKS1-code: aes-xts-plain64 keysize: 512 bits sleutellocatie: dm-crypt apparaat: /dev/loop5 loop: /dev/loop5 lus: /mnt/base/image1/config.img sector grootte: 512 offset: 4096 sectoren grootte: 61440 sectoren modus: lezen/schrijven

Tijdens de normale werking van het apparaat, wordt de cryptsetup gebruikt om de bestandssystemen te decoderen voordat ze worden gemonteerd. Wanneer de codeersleutel wordt verwijderd, is het niet meer mogelijk om het lusapparaat in te stellen en de bestandssystemen te monteren.

De encryptiesleutel die we gebruiken is een read van 20 bytes van /dev/urandom. Dit wordt uitgevoerd door sha1sum om een ascii-weergave te krijgen. De sleutel wordt gegenereerd bij de eerste opstart na een reset van de fabriek en verandert pas nadat de fabriek opnieuw wordt gereset.

Beveiliging van gegevenscoderingssleutels

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, wall papers, logboeken, historische logbestanden, enzovoort).

Voor de/data-partitie in Android is de privésleutel altijd veilig opgeslagen binnen de grenzen van de Nvidia TrustZone of, op de Room Navigator, versleuteld met 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 gedurfd van het apparaat worden verwijderd (samen met de flashschijf) om daadwerkelijk de inhoud te decoderen.

Beginnend met ce-11.26.x verplaatsen we de normale versleutelingssleutel van het bestandssysteem naar de vertrouwde uitvoeromgeving van Nvidia (TEE) op basis van ARM TrustZone[0], dus de sleutel is niet mogelijk om uit de Nvidia SoC te extraheren. Omdat de enige (bekende) manier om het veilig opstartproces te omzeilen is het vervangen van de hele Nvidia SoC, die vervolgens de sleutel zou verwijderen, zou het ophalen van de sleutel beperkt zijn tot het vinden van kwetsbaarheden in de CE-code om een root-shell te krijgen met voldoende machtigingen om de sleutel te verkrijgen.

Voor Room Navigator vindt de migratie in een latere versie plaats.