Tack för din feedback.

Filsystemet på enheter i Board, Desk och Room Series krypteras med Linux Unified Key Setup (LUKS), standarden för Linux-hårddiskkryptering. Filsystemets krypteringsnyckel sparas antingen i NVRAM eller NOR-Flash. Under en fabriksåterställning skrivs nyckeln över och kan inte återställas, vilket gör allt på disken oläsligt. Detta gör fabriksåterställning till en säker metod för att radera och rensa data i enlighet med US DOD 5220.22M och NIST 800-88r1.

Under en fabriksåterställning:

• Samtalsloggar tas bort

• Lösenordsfraser återställs till standard

• Alla enhetsparametrar återställs till standardvärden

• Alla filer som har laddats upp till enheten raderas

• Den tidigare (inaktiva) programvarubilden tas bort

• Alternativtangenterna påverkas inte

Du kan inte ångra en fabriksåterställning. Se till att det är nödvändigt att göra det innan du börjar.

NIST 800-88r1

NIST-standarden 800-88r1 anger tre nivåer av sanering:

• Rengör: Sky dda mot icke-invasiva återhämtningstekniker

• Rensa: Gör data återställning omöjlig

• Förstör: Gör dataåterställning omöjlig och förhindra framtida användning

Avsnitt 2.6 i standarden talar om användningen av Cryptographic Erase (CE) och hur den kan tillämpas för att uppfylla Purge-nivån.

I avsnitt 2.6.1 och 2.6.2 anges villkoren för när CE ska (inte) beaktas:

• Använd inte CE för att rensa media om krypteringen aktiverades efter att känsliga data lagrats på enheten utan att ha sanerats först.

• Använd inte CE om det är okänt om känsliga data lagrats på enheten utan att saneras före kryptering.

• Överväg att använda CE när all data som är avsedd för CE är krypterad före lagring på media (inklusive data, såväl som virtualiserade kopior).

• Överväg att använda CE när vi känner till platsen/platserna på mediet där krypteringsnyckeln lagras (vare sig det är måldatans krypteringsnyckel eller en tillhörande omslagningsnyckel) och kan sanera dessa områden med lämplig mediespecifik saneringsteknik, vilket säkerställer att den faktiska platsen på media där nyckeln lagras adresseras.

• Överväg att använda CE när vi kan veta att alla kopior av krypteringsnycklarna som används för att kryptera måldata saneras.

• Överväg att använda CE när måldatans krypteringsnycklar själva är krypterade med en eller flera omslagsnycklar och vi är övertygade om att vi kan sanera motsvarande omslagningsnycklar.

• Överväg att använda CE när vi är övertygade om användarens förmåga att tydligt identifiera och använda kommandona som tillhandahålls av enheten för att utföra CE-operationen.

I RoomOS installeras och krypteras de krypterade filsystemen som används för kunddata tidigt i den första uppstarten, innan känsliga data skapas. Nyckeln lagras enligt beskrivningen ovan antingen i eeprom (äldre programvara) eller med hjälp av SoCs förtroendezonsmekanismer och kan saneras säkert.

Nyckeln säkerhetskopieras aldrig och det finns ingen nyckelspärrmekanism.

Med allt detta i åtanke hävdar Cisco att fabriksåterställningsmekanismen i RoomOS överensstämmer med Purge-nivån i NIST 800-88r1.

Kunddatakryptering

Diskkryptering

Enheterna använder en flash-enhet för masslagring, där säker radering är omöjlig att garantera. All kunddata på enheterna lagras därför i krypterade filsystem, och när en återställning till fabriksinställningar utförs raderas endast krypteringsnyckeln, vilket gör kunddata oåtkomliga.

För att underlätta detta skapar vi en lämplig stor fil på huvudblixten och använder det vanliga Linux-verktyget cryptsetup för att skapa en loopback-enhet. På den här enheten skapar vi ett standard ext4-filsystem. Detaljer om var vi lagrar krypteringsnyckeln finns i nästa avsnitt.

Loopenheten skapas med LUKS1 med en nyckelstorlek på 512 bitar och 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 regelbunden drift av enheten används cryptsetup för att dekryptera filsystemen innan de monteras. När krypteringsnyckeln tas bort är det inte längre möjligt att ställa in loopenheten och montera filsystemen.

Krypteringsnyckeln vi använder är en läsning av 20 byte från /dev/urandom vilket är genomgående sha1sum för att få en ascii-representation. Nyckeln genereras vid första start efter en fabriksåterställning och ändras inte förrän en ny fabriksåterställning utförs.

Skydd för datakrypteringsnycklar

Vi använder två olika krypteringsnycklar på våra enheter. En för partitionen /data inuti Android-behållaren (för Microsoft MTR och Zoom) och en för andra filsystem (används för kundkonfiguration, väggpapper, samtalslogg, historiska loggar och så vidare).

För partitionen /data i Android har den privata nyckeln alltid lagrats säkert inom Nvidia TrustZone-gränsen eller krypterats med hjälp av So Room Navigator C:s inbyggda krypteringsmekanism.

Fram till och med ce-11.25.x lagras den andra nyckeln i EEPROM. Medan EEPROM är oåtkomligt för användare som kommer via någon normal kanal, kan den med våld tas bort från enheten (tillsammans med flashdisken) för att faktiskt dekryptera innehållet.

Från och med ce-11.26.x flyttar vi den vanliga filsystemkrypteringsnyckeln till Nvidia Trusted Execution Environment (TEE) baserat på ARM TrustZone [0], så nyckeln kommer inte att vara möjlig att extrahera från Nvidia SoC. Eftersom det enda (kända) sättet att kringgå den säkra startprocessen är att ersätta hela Nvidia SoC, som sedan skulle ta bort nyckeln, skulle nyckelextraktion begränsas till att hitta sårbarheter i CE-koden för att få ett rotskal med tillräckliga behörigheter för att få nyckeln.

För migr Room Navigator eringen kommer att ske i en senare version.