操作系统嵌入式嵌入式OS【免费下载链接】tockA secure embedded operating system for microcontrollers项目地址https://gitcode.com/gh_mirrors/to/tock点击查看免费下载本文基于 doc/wg/opentitan/case_studies/datacenter_security_model.md作者 cfrantz2022-11-15 发布展开。该文档以 Google 专有根信任芯片Titan为对象系统阐述了它在数据中心场景下的安全模型、启动流程与固件交付方式并进一步探讨了在迁移到开源OpenTitan后如何借助 Tock 的进程隔离模型与Application IDAppID机制重构固件交付与密钥管理。读者读完本文将完整掌握RoT 芯片如何保证服务器首指令启动完整性first-instruction boot integrity与机器身份授权的端到端安全架构并理解 Tock 的 AppID/凭据Credentials/ShortId 三层机制如何在此场景中落地。1. 文档定位与核心结论该文档描述的是Root-of-TrustRoT芯片在数据中心用例中的安全模型其描述的部署方式代表了当时 Google 专有 RoT 芯片公开名称为Titan及其固件的实际工作方式。文档明确说明这一安全模型会随 Google 生产安全需求与 RoT 芯片能力的演进而持续变化。Titan RoT 在服务器产品中的集成其核心目的有两个维持首指令启动完整性first-instruction boot integrity从机器复位后的第一条指令开始保证启动栈boot stack是预期的启动栈为机器授予在 Google 生产环境俗称prod中的有效身份cryptographic identity机器必须掌握wield其密码学身份才能与生产服务交互。此外Titan RoT 还通过强制安全固件更新来缓解拒绝服务DoS攻击。2. 背景Google 生产环境的机器身份模型Google 的 Platforms 团队负责设计并委托生产构成其生产环境的服务器与外围设备NIC、SSD、定制加速器等。在 Google 内部客户即 websearch、gmail、cloud 等产品团队购买计算资源来执行任务。一台机器要运行客户任务必须通过一系列健康检查health checks获得一个密码学身份cryptographic identity。能够展示或掌握其身份的机器可以与集群调度器、存储服务及其他内部服务如网页索引、图像识别等交互而无法展示身份的机器只被允许访问一组面向自动化或人工维修的受限服务——即进入repairs flow维修流程。这一有身份才能进生产网无身份只能进维修网的模型是整个安全设计的目标函数。3. Titan 芯片与数据中心集成方式3.1 Titan 硬件特性Google Titan 芯片是 Google 设计的根信任芯片硬件特性包括32 位嵌入式 ARM Cortex-M 内核内部 flash 与 RAM密码学加速硬件包括SHA 哈希模块SHA hashing block密钥派生模块key derivation block大数加速器bignum accelerator。3.2 在服务器中的集成方式Titan 芯片被集成进服务器产品使其对机器的复位过程与启动固件拥有控制权。具体而言Titan 具备两项关键能力监控并驱动应用处理器Application Processor, AP的复位信号在 AP 与其 EEPROM 之间的 SPI 总线上进行插接interposes即对启动固件的读取路径进行中间人式控制。该设计同时应用于三类产品形态带 CPU 的简单服务器、带基板管理控制器BMC的服务器以及 NIC、加速器等外围设备。Titan 在外围设备中的集成与在服务器产品中非常相似Titan 对外围设备的复位信号拥有底层控制权并处于能控制其启动固件的位置。根据外围设备的具体需求如启动时序通常会有集成定制但就本文安全模型而言集成方式基本相同。4. Titan 的三种代码镜像Code ImagesTitan 固件由三个层次分明、更新频率截然不同的代码镜像构成镜像变更频率职责ROM image永不改变芯片复位后的第一条执行路径内置验证密钥Bootloader极少变更配置密码学硬件与底层安全特性扫描并验证应用固件Application firmware每隔数月推送一次单体镜像包含内核、硬件支持代码与应用代码这一ROM 不变 → Bootloader 少变 → 应用固件常更的层次化设计是 RoT 安全的关键越靠近信任根代码变更越少越容易进行形式化验证与严格审计。5. 假设与需求Assumptions and Requirements5.1 安全假设Google 生产基础设施对 Titan 系统做出以下假设Titan 硅片启动过程是安全的Titan 只会启动由获得授权、有权使用 Google Titan 签名密钥的工程师签名的固件Titan 签名密钥被妥善保管只有经过适当授权的工程师法定人数quorum才能访问。脚注1补充说明密钥的具体保管方式超出本文范围但没有任何工程师拥有单方面访问权访问通过M-of-N 法定人数并经过多因素认证授予Titan 硬件正确执行密钥与固件版本的绑定要求Titan 固件升级提供一条安全的迁移路径可以迁移离开绑定到坏固件的密钥。5.2 需求数据中心机器必须掌握其密码学身份才能加入 prod没有密码学身份的机器禁止加入生产环境必须走维修流程数据中心机器必须从预期的启动栈启动才能访问其密码学身份Titan 固件是启动固件与软件链的根环节root linkTitan 验证自身固件与机器的第一段启动固件。Titan 不要求验证机器启动固件之后的任何东西如果机器的启动固件可信启动栈的进一步验证可以委托给栈的上层完成启动栈各环节的签名与验证不能过于繁重负责启动栈每个环节的团队中经授权的负责人principals应为该环节签名每个环节的公钥必须提供给启动栈前一阶段的作者。实现细节包括启动栈中大部分环节的密钥存放在 Google 内部密钥管理服务中签名是在线过程委托给负责在 Google 发布自动化系统中构建与发布软件的角色账户role accountsTitan 固件的签名密钥被认为过于强大不能存放在任何在线系统中Titan 固件密钥存放在安全设施中的隔离系统内Titan 签名法定人数可以访问该安全设施并在 Titan 固件发布流程中执行离线签名仪式offline signing ceremony。6. 机器启动流程Machine Boot Process文档给出了每个上电周期per-power-cycle的完整机器生命周期共 11 个步骤这是理解 Titan 安全模型的核心机器上电电源时序器power sequencer释放复位与此同时一个简单的 RC 电路充电并释放 Titan 的复位典型值为 R 10KΩ、C 0.1μF时间常数约 10ms。Titan GPIO 的上电状态保证即使电源时序器已释放复位Titan 仍将服务器保持在复位状态Titan ROM 执行Titan 退出复位后 ROM 执行ROM 在其内部 flash 中找到 bootloader用ROM 中存储的密钥对 bootloader 进行密码学验证。验证通过则跳转执行 bootloader失败则 Titan 自复位Bootloader 执行bootloader 对密码学硬件与芯片底层安全特性做初始配置如锁定某些 flash 区域、配置入侵检测特性然后扫描内部 flash 寻找应用固件。应用固件使用bootloader 中存储的密钥进行密码学验证。通过则跳转失败则 Titan 自复位应用固件硬件配置Titan 应用固件执行额外的硬件配置如配置 GPIO 与其它 IO 外设验证 AP 启动固件应用固件仍将机器保持在复位状态扫描离散 SPI flash 部件寻找有效的 AP 启动固件。找到后Titan 用Titan 应用固件中存储的密钥验证 AP 启动固件的不可变部分immutable portions记录验证结果然后释放 AP 复位AP 启动与测量启动在 AP 是多层启动如 UEFI、kernel 等的服务器 CPU 场景下CPU 遵循测量启动流程measured boot——每一层运行前先由前一层测量。Titan 表现得像一个 TPM只有当 CPU 通过预期软件启动时才释放机器的密码学身份机器启动BMC 启动时保持主 CPU 复合体处于复位状态BMC 扫描机器 BIOS用 BMC 固件中存储的公钥验证它记录有效性后释放主 CPU 复合体复位主 CPU 启动、找到 OS、验证并记录其有效性后启动 OS身份授予判定操作系统启动后安全守护进程security daemon收集各启动阶段的有效性声明并呈交给 Titan。若 Titan 能确定整个启动栈是预期启动栈则授予机器访问其密码学身份的权限机器加入 prod否则拒绝授予身份机器被迫进入维修流程运行期复位监控机器运行期间Titan 一旦检测到复位将机器2保持在复位状态启动流程从第 5 步重复SPI 写保护策略Titan 应用固件在运行期监控 SPI 总线在 SPI EEPROM 上强制写保护策略固件内含描述写保护策略的描述符包括受保护区域的偏移量固件更新必须经 Titan 验证机器不允许直接写 flash所有固件更新都必须由 Titan 验证。其中脚注2说明存在一些变化或例外情况但所有情况下 Titan 都控制机器或外设的启动过程。7. Titan 服务器固件的显著特性面向数据中心用例的应用固件具有以下显著特性从首指令起验证机器启动固件的有效性attests to the validity of the machines boot firmware from the first instruction安全守护机器的密码学身份身份只授予启动了预期启动栈的机器失败开放fail-open的故障模式除 Titan 自身外启动栈完整性中的任何失败仍允许机器启动但将其访问限制在自动化维修系统中通过 flash 写保护与受管固件更新提供机器韧性Titan 维护 EEPROM 上的写保护策略并管理固件更新。Titan 的 SPI 插接器特性支持A/B 固件更新——更新保留现有固件作为新固件失败时的回退3。脚注3说明TL;DR 是 flash 部件容量为所需大小的两倍Titan 可以选择向机器展示哪一半可将密码学密钥绑定到主要应用固件版本若 Titan 固件发现严重 bug可发布新版主版本号递增的应用固件并签发绑定到该固件的新密钥。较新固件可以访问并掌握绑定到较旧固件的密钥但较旧固件无法访问新密钥4。脚注4补充若攻击者能将 Titan 强制降级到已知不良固件硬件会拒绝其访问或掌握新密钥的尝试。最后一点本质上是固件版本与密钥的硬件级绑定它直接抑制了降级攻击 密钥泄露的组合风险。8. Tock 与 AppID固件交付模型的重构向 OpenTitan 的迁移代表着当前数据中心 Titan 固件开发与交付方式的根本性变化使团队得以重新审视现有系统的假设与需求并做出改进。8.1 现状单体镜像Today当前数据中心 Titan 应用固件是一个单体软件镜像monolithic software image由三个主要组件构成内核与驱动组件kernel drivers component硬件集成组件hardware integration component指 Titan 对服务器系统控制的具体实现密码学与身份服务组件cryptographic identity services component。组件之间的边界较为模糊内核与应用组件之间没有强分离。三个组件由 Google 内部不同团队维护Platforms 团队维护内核、驱动与硬件集成组件prod-identity 团队维护密码学与身份服务组件。多个团队向同一个单体固件镜像贡献代码一直是复杂性的来源偶尔导致混乱或延迟。8.2 未来Tock 内核 独立应用The Glorious Golden Future后续章节描述的是假设性用例或对现有用例的假设性修改。它们假设 OpenTitan 是根信任芯片、采用 OpenTitan 术语并假定 OpenTitan 芯片在启动 Tock 内核前已完成安全启动与芯片配置。Tock 提供内核与用户空间边界kernel/userspace boundary与进程隔离process isolation。Tock 还允许应用与内核负载分离交付与加载——这使得数据中心固件可以按组件交付每个组件拥有不同的访问控制。文档由此提出了两项核心观察硬件集成组件不需要访问芯片内的密码学硬件其主要关注点是执行复位控制与管理对 SPI flash 芯片的访问密码学服务组件同样不需要访问 OpenTitan 芯片的 IO 接口。在此基础上两个团队可以各自独立工作GooglePlatforms 团队作为silicon_ownerOpenTitan 术语中silicon_owner 是 OpenTitan 芯片或包含 OpenTitan 芯片设备的购买方可以签名并交付用于数据中心集成的Tock 内核以及提供 OpenTitan 集成最低层机器控制服务的硬件集成应用Google生产身份团队可以签名并交付密码学服务应用负责守护与维护机器或子系统身份并证明其启动固件的有效性。这些应用可以由不同的密钥签名允许不同应用拥有独立的运营安全与发布流程。应用签名密钥与内核签名密钥相互独立且每种密钥可以有不同的存储要求。例如内核密钥可被视为高价值资源限制在**离线硬件安全模块HSM**中应用签名密钥则可以认为足够安全存放在 Google 的在线密钥管理服务中因为它们可以作为新内核发布的一部分进行轮换。这种权威与权限分离允许 Platforms 与 prod-identity 团队独立开发各自的应用并在无需离线仪式的情况下签名与交付这些应用而内核升级或部署新的应用签名密钥才需要离线仪式。由此大幅降低了功能新增与其它维护工作的成本。8.3 OpenTitan 资源的委托Delegation of OpenTitan Resources内核与应用签名权威的分离也为 OpenTitan 平台开启了新的服务交付模式。文档给出三个示例外设身份获取服务器中的硬件外设可能希望获得绑定到服务器平台主板的身份或密钥。负责该外设的团队可以编写自己的身份授予 Tock 应用并部署到主板的 RoT有时称为Platform Root-of-Trust, PRoT上。投入使用后外设可与 PRoT 建立通信获取从主板派生的身份安全日志Secure logging服务器平台或 prod 中部署的服务器子集可能要求对日志消息进行密码学记录这些记录由 RoT 防篡改边界内认证或存储。一个可选的安全日志应用可部署到 RoT生成安全日志子系统所需的日志令牌logging tokens云终端客户应用基础设施提供商理论上可以选择出售或以其它方式提供 RoT 上的执行时间允许终端客户部署自己的 Tock 应用。这需要确立向终端客户应用开放哪些 Tock 服务与系统调用但有望让云客户在其购买的计算资源的安全元件secure element内执行某些操作。9. 仓库源码佐证Tock 的 AppID 机制如何支撑上述愿景上述独立签名、独立交付的设想之所以成立依赖 Tock 内核的Application IdentifierAppID机制。Tock 仓库中对应的设计文档为 doc/reference/trd-appid.md实现集中在kernelcrate 的 process_checker.rs 与 process_loading.rs。9.1 三个核心概念AppID、Credentials 与 ShortIdApplication Credentials应用凭据任意 k 字节序列通常存储在用户程序二进制的TBFTock Binary Format脚注footers中用于建立用户空间二进制的完整性Application IdentifierAppID应用的数值标识符。内核绝不允许两个具有相同 AppID 的进程同时运行——若两个用户空间二进制具有相同 AppID内核在同一时刻只允许其中一个运行。AppID 与进程 IDProcessId相互独立进程 ID 标识一次特定的执行而 AppID 标识应用本身可跨重启持久ShortId32 位压缩形式的 AppID。应用标识符可能很大如 RSA 密钥或比较昂贵如字符串名ShortId 用于提升身份检查的时空开销。ShortId使用core::num::NonZeroU320 保留给LocallyUnique变体见 process.rs 的ShortId枚举定义。三个核心 trait定义见 process_checker.rsTrait职责AppCredentialsPolicy定义内核接受哪些类型的凭据、是否接受特定二进制的特定凭据内核只加载被其接受的用户程序AppUniqueness比较两个进程的 AppID 是否不同内核据此保证运行进程的 AppID 唯一Compress将 AppID 压缩为 32 位ShortId用于快速比较如对照访问控制列表AppIdPolicy是AppUniqueness Compress的复合 trait便于以单个引用传递。9.2 凭据检查流程与加载判定在内核的加载流程见 process_loading.rs中引导时内核扫描应用 flash 区域中的 TBF 对象解析 TBF 头与脚注对每个TbfFooterV2Credentials脚注调用check_credentials返回Accept则停止检查并继续加载返回Reject则拒绝加载返回Pass则检查下一个脚注若遍历结束仍无结果由require_credentials()决定默认行为true则不加载、false则加载进程加载采用确定性算法若两个进程二进制具有相同 AppID 或相同 ShortId则版本号TBF Program Header 中的version字段较高的进程获胜若版本相同先发现的进程启动。该设计明确用于抵御降级攻击downgrade attacks与配置错误通过AppUniqueness::different_identifier与to_short_id完成 AppID/ShortId 唯一性判定后计算short_app_id并创建进程对象process_loading.rs。capsules 层提供了开箱即用的实现见 capsules/system/src/process_checker/basic.rs 与 capsules/system/src/process_checker/tbf.rsAppIdAssignerNames以 TBF 头中的包名package name为输入、经哈希函数映射为ShortId实现AppUniqueness与CompressAppIdAssignerTbfHeader直接使用 TBF 头中的 ShortId 字段无该字段时分配LocallyUniqueAppCheckerRsaSimulated接受带 RSA3072/RSA4096 凭据的二进制注意该实现不真正验证签名仅用于测试内核加载逻辑对 ID 冲突与版本号的处理。9.3 与文档设想的对应关系回到数据中心场景这套机制直接支撑了第 8 节的设想独立签名Tock 内核与应用可以由不同密钥分别签名TBF 脚注可携带多个凭据而AppCredentialsPolicy决定接受哪些密钥的凭据独立交付应用与内核负载分离交付、加载硬件集成应用与密码学服务应用可以作为独立 Tock 应用部署到 OpenTitan RoT权限差异化capsules 可通过ProcessId::short_app_id()取得应用的ShortId进而实施基于身份的访问控制ShortId跨重启与应用更新持久天然满足身份绑定到应用而非执行实例的需求见 process.rs。10. OpenTitan 板级支持现状Tock 仓库对 OpenTitan 的板级支持位于 boards/opentitan当前支持 ChipWhisperer CW310 FPGA 板与 Verilator 仿真earlgrey-cw310子目录。从 boards/opentitan/README.md 可以确认Tock 内核以riscv32imc-unknown-none-elf目标构建应用通过make flash-app APP...或 Verilator 下的make APP... BOARD_CONFIGURATIONsim_verilator verilator加载应用 flash 区域位于0x20030080、RAM 区域位于0x10005000。该板级支持与 OpenTitan Tock 工作组路线图见 doc/wg/opentitan/roadmap.md中P2 System Updater Application支持 A/B 更新方案P2 Crypto Driver Abstractions优先覆盖 RoT 用例等目标相互呼应——A/B 更新与密码学驱动抽象正是数据中心 RoT 部署如第 7 节的 A/B 固件更新、第 3 节的密码学加速硬件在 Tock 中的直接对应物。11. 结语该文档展示了一个清晰的演进脉络从单体固件 离线签名仪式 硬件级密钥版本绑定的 Titan 专有方案走向可独立签名、独立交付、进程隔离的 Tock 内核 多应用的 OpenTitan 方案。后者通过 Tock 的 AppID 机制把谁可以签名什么、谁可以访问哪些硬件资源的权限边界从硅片硬件下沉到软件策略层从而在不牺牲安全性的前提下显著降低多团队协作与功能迭代的运维成本。对于任何研究可信启动、测量启动、固件供应链安全或 Tock 应用身份模型的开发者而言本文档及其在仓库中的对应实现process_checker.rs、process_loading.rs、trd-appid.md都是一份不可多得的综合参考。脚注密钥的确切保护方式超出本文档范围。没有任何工程师拥有单方面访问权访问通过 M-of-N 法定人数并经过多因素认证授予。↩存在一些变化或例外情况。在所有情况下Titan 都控制机器或外设的启动过程。↩ ↩TL;DRflash 部件容量为所需大小的两倍Titan 可以选择向机器展示哪一半。↩ ↩若攻击者能将 Titan 强制降级到已知不良固件硬件将拒绝其访问或掌握新密钥的尝试。↩ ↩赞分享操作系统嵌入式嵌入式OS【免费下载链接】tockA secure embedded operating system for microcontrollers项目地址https://gitcode.com/gh_mirrors/to/tock点击查看免费下载相关推荐10个keyphrase-extraction-kbir-semeval2017高级使用技巧与最佳实践10个keyphrase extraction kbir semeval2017高级使用技巧与最佳实践 关键短语提取技术 是自然语言处理领域的重要应用能够自动OpenTitan开源硅根信任项目OpenTitan开源硅根信任项目 OpenTitan 是一个由 lowRISC CIC 管理的开源硅根信任Root of Trust, RoT项目。该项硬件开发固件密码学嵌入式Tock安全启动流程完整指南从硬件信任根到应用层的完整信任链构建Tock安全启动流程完整指南从硬件信任根到应用层的完整信任链构建 Tock是一个专注于安全性的嵌入式操作系统其安全启动流程通过硬件信任根、加密验证和分层隔离操作系统嵌入式嵌入式OS创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考