Buildroot设备首次启动熵：随机种子、克隆镜像与密钥生成

把首次启动当作独立安全状态

从制造镜像克隆出来的设备，与已经正常启动并保存过新随机状态的设备，具有不同的随机性历史。两条路径如果都要生成长期密钥，就必须在安全初始化的随机生成器就绪后执行。启动快并不足以验收，尤其不能以可预测密钥或复制设备身份作为代价。

本文用户态示例固定Buildroot 2025.02及其systemd 256.7，内核行为核对Linux 6.12。其他初始化系统需要自行建立等价顺序与种子管理。本内容是设计和验证清单，没有进行熵质量测量、密钥生成或硬件测试。

列出主机密钥、注册密钥、TLS库和应用凭据等所有需要密码学随机性的操作，并标出它们可能发生在引导程序、initramfs、早期用户态还是正常服务阶段。最早消费者决定随机源何时必须就绪；稍后加载种子，不能追溯性保护已经生成的密钥。

还要区分创建与复用。预配置身份可能已经存在，不应在每次启动时意外重新生成。首次初始化、恢复出厂、替换镜像和恢复模式应有明确政策。身份生命周期与“让服务先启动”的修补要分开处理，因为前者影响设备之外的信任关系。

在Linux v6.12随机子系统源码中，getrandom未使用不安全标志时会等待密码学生成器就绪；使用GRND_NONBLOCK时，未就绪返回EAGAIN。应用应按API处理实际返回值、中断和部分结果，不能假设一次调用总能得到请求的全部字节。

生成密钥时，不能因为早启动等待就退回到时间、MAC、序列号或未初始化来源。这些信息或许能区分设备，却往往可预测。密码库应走受支持的安全路径；应用超时应报告初始化失败或安全等待，不能悄悄降低随机源要求。就绪是安全条件，不只是需要消除的启动延迟。

硬件随机外设只有在产品内核支持、设备启用且信任假设有依据时才有价值。检查所选驱动、固件或设备描述及相关内核配置。看到名为hwrng的节点，并不能证明来源健康、已正确进入内核生成器，或适合产品的所有威胁模型。

同样，可用熵计数器也不是完整质量审计。应依据精确配置与平台设计解释内核把哪些来源计入熵估算以及原因。修改信任选项属于安全决定，理由应随板级配置保存，不应只为消除等待就加入没有解释的启动调参。

systemd 256.7随机种子说明将状态保存在/var/lib/systemd/random-seed。默认情况下，加载这个文件不会自动计入熵估算。服务通常在initramfs结束且/var可用后运行，所以不能解决所有更早消费者的需求。

该服务使用已初始化内核的随机数据刷新种子，可作为原本存在不安全早期读取路径的服务之排序依据。但必须检查镜像内真实单元与依赖，不能因为文件名正确就推断启动关系正确。只读根设计也需安排受支持的可写种子位置或其他持久化方案，并通过权限保护种子秘密。

用于批量复制的镜像不应原样分发同一份有效随机种子。systemd文档提醒，在其他熵来源不足时，重复种子可能导致相关风险。应分开设计通用镜像准备与逐设备初始化，并确认备份、覆盖层或恢复归档不会重新引入相同种子。

序列号唯一，并不能让共享种子变得不可预测。引导程序提供种子只有在生成方式、逐设备唯一性、保密和更新机制都正确时，才真正改善早期可用性。不要把强制计入熵当作克隆或缺种子的通用解决方法。尤其对于正常启动完成前反复重启的设备，种子刷新与掉电行为必须进入生命周期评审。

实验矩阵覆盖没有历史状态的新设备、正常重启、首次启动中断、恢复镜像、恢复出厂和恢复模式。记录安全初始化何时可用、密钥服务是否正确等待，以及错误是否留下可恢复状态。日志不能打印种子字节、随机缓冲区或私钥。

当产品要求身份唯一时，可以比较公钥指纹发现意外重复身份。发现重复是可行动的证据，但小样本中没有重复不能证明密码学质量。保留配置、排序证据和通过失败结果，而不是收集秘密材料。可接受启动时间应在实际平台测量后结合产品要求制定，不能照搬另一块板子的数字。

验收应确认每个密钥消费者都有检查就绪的路径，复制镜像没有共享有效种子，持久状态受保护，首次启动和恢复场景有明确结果。示例systemd版本来自Buildroot 2025.02配方，产品仍需核对实际安装的包和内核版本。

明确制造镜像清理、内核随机源配置以及应用错误处理分别由谁维护。这些检查不构成随机生成器认证，也不替代产品安全评审。它们建立的是从初始设备状态到安全密钥生成的可追踪链条，避免只凭启动成功或密钥外观正常就宣布完成。