Board、Desk 和 Room 系列裝置上的檔案系統使用 Linux 統一密鑰設定 (LUKS) 進行加密,這是 Linux 硬碟加密的標準。 檔案系統加密密鑰儲存在 NVRAM 或 NOR 閃存中。 在重設成出廠預設值期間,密鑰將會被覆寫且無法恢復,從而導致硬碟上的任何內容都無法讀取, 這使得恢復出廠設置成為一種符合美國 DOD 5220.22M 和 NIST 800-88r1 的刪除和清除數據的安全方法。

在恢復出廠設定期間:

  • 通話記錄被刪除

  • 密碼重設為預設值

  • 所有裝置參數重設為預設值

  • 已上傳至裝置的所有檔案都被刪除

  • 刪除之前的(不活躍)軟體映像

  • 選項鍵不受影響

重設成出廠預設值後您將無法復原。 在開始之前,確保有必要這樣做。

我們建議您使用 Web 介面或 UI 將裝置恢復出廠設定。 在執行恢復出廠設定之前,您應該備份裝置的記錄檔、組態和自訂元素;否則此資料將會丟失。 有關備份和重置設備的不同方法的資訊,請參閱 管理指南

NIST 800-88r1

NIST 標準 800-88r1 規定了三個級別的清理:

  • 清潔: 防範非侵入性恢復技術

  • 清除: 使資料恢復不可行

  • 銷毀: 使數據恢復不可行並阻止將來使用

該標準的第 2.6 節討論了加密擦除 (CE) 的使用以及如何應用它來滿足清除級別。

第 2.6.1 和 2.6.2 節列出了何時 (不) 考慮 CE 的條件:

  • 如果在敏感數據存儲在設備上而未先清理就啟用了加密,請不要使用 CE 清除媒體。

  • 如果不知道敏感數據是否存儲在設備上而未在加密之前進行清理,請不要使用 CE。

  • 若所有用於 CE 的資料在儲存至媒體 (包括資料及虛擬化複本) 前,皆已加密,請考慮使用 CE。

  • 當我們知道介質上存儲加密密鑰的位置 (無論是目標數據的加密密鑰還是關聯的包裝密鑰) 並且可以使用適當的特定於介質的清理技術清理這些區域,確保尋址密鑰在介質上的實際位置時,請考慮使用 CE。

  • 當我們知道用於加密目標數據的所有加密金鑰副本都已清理時,請考慮使用 CE。

  • 當目標數據的加密金鑰本身使用一個或多個包裝金鑰進行加密並且我們確信可以清理相應的包裝密鑰時,請考慮使用 CE。

  • 當我們確信使用者有能力清楚地識別和使用設備提供的命令來執行 CE 操作時,請考慮使用 CE。

在 RoomOS 中,用於客戶數據的加密檔案系統在初始啟動的早期,即在創建任何敏感數據之前進行設置和加密。 密鑰如上所述存儲在 eeprom (舊軟體) 中或使用 SoC 的信任區域機制,並且可以安全地清理。

金鑰永遠不會備份,也沒有金鑰託管機制。

考慮到所有這些,Cisco 斷言 RoomOS 中的恢復出廠設定機制符合 NIST 800-88r1 中的清除級別。

客戶資料加密

磁碟加密

這些設備使用快閃記憶體設備進行大容量存儲,無法保證安全刪除。 因此,設備上的所有客戶數據都存儲在加密的檔案系統上,當重置為出廠預設值時,僅刪除加密密鑰,從而使客戶數據無法訪問。

為了促進這一點,我們在主快閃記憶體上創建了一個適當大的檔,並使用標準的 Linux 工具 cryptsetup 來創建一個環回設備。 在此設備上,我們創建了一個標準的 ext4 檔案系統。 有關我們存儲加密金鑰的位置的詳細資訊,請參見下一節。

環路設備是使用 LUKS1 創建的,金鑰大小為 512 位,並使用 aes-xts-plain64 密碼:

 $ cryptsetup status /dev/mapper/config /dev/mapper/config 處於活動狀態且正在使用中。類型:LUKS1 密碼:AES-XTS-PLAIN64 密鑰大小:512 位密鑰位置:dm-crypt 設備:/dev/loop5 迴圈:/mnt/base/image1/rwfs/config.img 扇區大小:512 偏移量:4096 扇區大小:61440 扇區模式:讀/寫

在設備的常規操作期間,cryptsetup 用於在掛載檔案系統之前對其進行解密。 刪除加密金鑰后,將無法再設置迴圈設備和掛載檔案系統。

我們使用的加密密鑰是從 /dev/urandom 讀取 20 個字節,它是通過 sha1sum 運行以獲得 ascii 表示。 金鑰在恢復出廠設置後首次啟動時生成,並且在執行新的出廠重置之前不會更改。

資料加密金鑰保護

我們在設備上使用兩個不同的加密金鑰。 一個用於 Android 容器內的 /data 分區 (用於 Microsoft MTR 和 Zoom),另一個用於其他文件系統 (用於客戶配置、牆紙、通話記錄、歷史日誌等)。

對於 Android 中的 /data 分區,私鑰始終安全地存儲在 Nvidia TrustZone 邊界內,或者在 Room Navigator 上,使用 SoC 的內置加密機制進行加密。

在 ce-11.25.x 之前 (包括 ce-11.25.x),另一個密鑰存儲在 EEPROM 中。 雖然通過任何正常通道的用戶無法訪問 EEPROM,但可以從設備 (連同快閃記憶體盤) 中強行將其刪除以實際解密內容。

從 ce-11.26.x 開始,我們將常規文件系統加密密鑰移動到基於 ARM TrustZone[0] 的 Nvidia 可信執行環境 (TEE),因此無法從 Nvidia SoC 中提取密鑰。 由於規避安全啟動過程的唯一 (已知) 方法是替換整個 Nvidia SoC,然後刪除密鑰,因此密鑰提取將僅限於查找 CE 代碼中的漏洞,以獲得具有足夠許可權的根 shell 獲取密鑰。

Room Navigator 的遷移將在更高版本中進行。