Filsystemet på enheter i Board-, Desk- och Room-serien krypteras med Linux LUKS (Unified Key Setup), standarden för Linux-hårddiskkryptering. Filsystemets krypteringsnyckel sparas i antingen NVRAM eller eller NOR-flash. Vid en fabriksåterställning skrivs nyckeln över och går inte att återställa, vilket gör att ingenting på disken går att läsa. 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 sker följande:

  • Samtalsloggar tas bort

  • Lösenfraser återställs till standardvärdet

  • Alla enhetsparametrar återställs till standardvärdena

  • Alla filer som har laddats upp till enheten tas bort

  • Den tidigare (inaktiva) programavbildningen tas bort

  • Alternativknappar påverkas inte

Du kan inte ångra en fabriksåterställning. Kontrollera att du måste utföra den innan du börjar.

Vi rekommenderar att du använder webbgränssnittet eller användargränssnittet när du ska fabriksåterställa enheten. Du bör säkerhetskopiera loggfilerna, konfigurationerna och de anpassade elementen på enheten innan du fabriksåterställer, annars går dessa data förlorade. Se administrationshandboken för information om olika sätt att säkerhetskopiera och återställa enheten.

NIST 800-88r1

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

  • Ren: Skydda 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 kryptografisk radering (CE) och hur den kan tillämpas för att uppfylla rensningsnivån.

Avsnitt 2.6.1 och 2.6.2 listar villkoren för när man (inte) ska överväga CE:

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

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

  • Överväg att använda CE när alla data som är avsedda för CE krypteras före lagring på mediet (inklusive data samt virtualiserade kopior).

  • Överväg att använda CE när vi känner till platserna på mediet där krypteringsnyckeln lagras (vare sig det är måldatas krypteringsnyckel eller en tillhörande omslagsnyckel) 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åldatas krypteringsnycklar själva är krypterade med en eller flera omslutningsnycklar och vi är övertygade om att vi kan sanera motsvarande paketeringsnycklar.

  • Ö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 konfigureras och krypteras de krypterade filsystemen som används för kunddata tidigt i den första starten, innan känsliga data skapas. Nyckeln lagras enligt beskrivningen ovan antingen i eeprom (äldre programvara) eller med hjälp av SoC: s förtroendezonmekanismer och kan saneras säkert.

Nyckeln säkerhetskopieras aldrig och det finns ingen nyckeldepositionsmekanism.

Med allt detta i åtanke hävdar Cisco att fabriksåterställningsmekanismen i RoomOS är kompatibel med rensningsnivån i NIST 800-88r1.

Kryptering av kunddata

Diskkryptering

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

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

Loopenheten skapas med LUKS1 med en nyckelstorlek på 512 bitar och aes-xts-plain64-chifferet:

 $ cryptsetup status /dev/mapper/config /dev/mapper/config är aktiv och används. typ: LUKS1 chiffer: aes-xts-plain64 nyckelstorlek: 512 bitar nyckelplats: dm-crypt enhet: / dev / loop5 loop: / mnt / base / image1 / rwfs / config.img sektorstorlek: 512 förskjutning: 4096 sektorer storlek: 61440 sektorer läge: läs / skriv

Under normal drift av enheten används cryptsetup för att dekryptera filsystemen innan de monteras. När krypteringsnyckeln raderas är det inte längre möjligt att ställa in slingenheten och montera filsystemen.

Krypteringsnyckeln vi använder är en läsning av 20 byte från /dev/urandom som är run-through sha1sum för att få en ASCII representation. Nyckeln genereras vid den första starten efter en fabriksåterställning och ändras inte förrän en ny fabriksåterställning utförs.

Skydd av datakrypteringsnyckel

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, historikloggar och så vidare).

För partitionen /data i Android har den privata nyckeln alltid lagrats säkert inom Nvidia TrustZone-gränsen eller, på Room Navigator, krypterats med SoC:s inbyggda krypteringsmekanism.

Fram till och med ce-11.25.x lagras den andra nyckeln i EEPROM. Medan EEPROM är otillgänglig för användare som kommer via någon normal kanal, kan den tvingas 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 krypteringsnyckeln för filsystemet till Nvidia Trusted Execution Environment (TEE) baserat på ARM TrustZone[0], så nyckeln går inte 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 nyckelextrahering begränsas till att hitta sårbarheter i CE-koden för att få ett rotskal med tillräcklig behörighet för att få nyckeln.

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