Board、Desk 和 Room 系列设备上的文件系统使用 Linux 统一密钥设置(LUKS)进行加密,LUKS(Linux 硬盘加密标准)。 文件系统加密密钥保存在 NVRAM 或 NOR 闪存中。 在恢复出厂设置期间,密钥会被覆盖且无法恢复,从而导致磁盘上的所有内容都无法读取。 这使得恢复出厂设置成为一种安全的删除和清除数据的方法,符合美国国防部 5220.22M 和 NIST 800-88r1 的要求。

在恢复出厂设置期间:

  • 呼叫日志删除

  • 密码重置为默认值

  • 所有设备参数重置为默认值

  • 已上传到设备的所有文件都删除

  • 以前的(非活动)软件映像删除

  • 选项键不受影响

恢复出厂设置无法撤销。 在开始之前,请确保有必要这样做。

我们建议您使用 Web 界面或用户界面来恢复设备的出厂设置。 在恢复出厂设置之前,应备份设备的日志文件、配置和自定义元素;否则此数据将会丢失。 请参阅“ 管理指南 ”了解有关备份和重置设备的不同方法的信息。

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 的信任区域机制中,并且可以安全地进行清理。

密钥永远不会备份,也没有密钥托管机制。

考虑到所有这些,思科断言 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 代码中的漏洞,以获取具有足够权限的根外壳来获取密钥。

对于会议室导航器,迁移将在更高版本中进行。