密码系统里有些组件容易获得关注算法、密钥长度、安全芯片、证书、签名、协议。还有一个东西通常被排在很靠后的位置——随机数。在多数工程代码里它看起来只是一项基础服务。需要一次性标识取一段随机数需要生成密钥调用系统接口需要挑战值再取一段。上层默认操作系统已经把随机性问题解决了。对大量普通软件来说这个抽象完全合理。但当系统开始涉及安全硬件、设备身份、密钥生成、会话建立、执行证据和协议交互时随机数就不能只被当作一个工具函数。因为许多密码学安全假设最终都依赖同一个前提攻击者无法预测那些本应不可预测的值。一旦这个前提失效即使算法没有漏洞、私钥从未导出、协议代码完全按设计运行整个系统的安全上限仍然可能被显著拉低。所以在构建执行边界时随机数也必须进入威胁模型。一、不可预测而不是看起来乱工程上最常见的误解是把随机性理解成数字没有明显规律。一串看不出模式的字节直觉上就是随机的。密码学要求的却不是视觉上的杂乱而是对攻击者不可预测。这是两个不同标准。一个伪随机算法即便能产生极其复杂、几乎看不出规律的数据只要攻击者知道它的初始状态、种子或内部状态或者能够据此推断后续输出它就无法承担密码学随机源的职责。这一点最直接的后果体现在密钥生成上。假设算法足够成熟、密钥长度也足够但生成时的随机源实际有效熵很小那么攻击者根本不需要搜索理论上的完整密钥空间他只需要搜索这个随机源真正可能生成的那一小部分空间。算法宣称的密钥空间不等于系统真正拥有的安全空间真正的上限取决于密钥最初是怎么产生的。保护密钥不是从存进安全芯片才开始而是从生成密钥的第一个随机比特就已经开始。源头一旦弱化后面再安全的存储也补不回已经丢失的熵。上一篇讨论过的一次性标识也有类似问题只是形态不同。它有时需要随机有时可以来自计数有时两者结合取决于协议设计。但只要某个协议明确依赖它的不可预测性或唯一性随机质量就会直接影响碰撞、重放、会话绑定和挑战应答等属性。所以不能简单地想它又不是密钥随机差一点没关系——它是不是秘密并非唯一问题关键在于协议究竟依赖这个值提供什么安全属性。不同用途对随机性的要求可能相差很远。二、熵是一个隐形的信任根我们习惯把根密钥、启动信任锚、硬件身份称作信任根。但如果这些对象的产生依赖一个不可验证的随机源那么在更底层其实还藏着另一个信任根熵源本身。设想一台设备在初次建立身份时生成了自己的长期密钥。之后我们可以证明私钥不可导出签名发生在安全边界内部证书链完全正确——但如果生成那一刻的随机性存在严重问题这条漂亮的信任链实际上建立在一个不够坚固的起点上。所以从架构上看熵不是密码学旁边的辅助输入它本身就是信任链的一部分。三、多个熵源以及多样性到底指什么在嵌入式系统里一个常见的熵来源是主控芯片自身的硬件随机能力。相比纯软件伪随机它的价值在于随机性不完全依赖系统时间、进程标识、软件状态、固定种子或某个可被观察的业务输入。但硬件随机四个字本身也不构成无限信任。仍然需要考虑硬件是否初始化成功当前是否处于正常状态接口有没有返回异常设备生命周期中是否出现过熵源健康问题。正确的抽象不是硬件随机源永远可靠而是把它当作一个需要被监测和验证的熵源。如果系统中还存在安全元件它通常也能提供自己的随机能力。既然主控已经有了为什么还要第二个答案与执行控制一贯强调的独立失陷条件一致如果所有随机性都出自同一个模块这个模块一旦异常整个系统就只剩一条熵源路径。来自不同安全域的随机源其底层实现、状态和边界并不相同可以降低共模失效的概率。要强调的是这里追求的并不是两段随机数拼在一起安全就翻倍。真正的目标是熵的来源多样性——不要让整个密码系统的随机性完全依赖某一个组件永远正确。也正因如此多熵源不能简化成把两路输出连接起来就算完成。真正需要事先定义的是每个源承担什么角色某一个失效时系统是否还能保持必要的安全属性如何发现失效组合方式如何避免一个坏输入污染另一个好输入以及系统在什么条件下才认为已经积累了足够的初始化材料。这里还有一个常见误区数据量大不等于熵高。收集大量时间戳、计数器、传感器读数或网络时序看上去变化丰富但变化量并不等于对攻击者不可预测的部分。如果这些值可以被观察或推断采集再多也未必贡献足够的安全熵。熵池真正关心的是质量而不是字节数——这也是硬件随机源值得被单独设计和验证的原因。四、从熵源到随机服务成熟系统通常不会让每个业务模块自己去调用一个硬件源、再调用另一个、然后自行拼接。那样会把熵源管理、错误处理、健康状态和随机策略分散进大量业务代码。更合理的做法是引入熵池不同可信来源把熵贡献给统一的随机子系统上层密码学代码不必关心某一段字节来自哪个组件它面对的是一个已经建立起来的安全随机服务。熵的采集、健康判断、状态管理、初始化与重新播种都被收进一个更小的边界里。这与本季反复强调的小可信边界原则一致——业务层不应该自己发明随机数工程。那么能不能每次需要时直接读硬件理论上可以工程上未必理想。硬件随机源可能吞吐有限、存在调用延迟、暂时不可用、需要特定工作状态或在不同平台上行为差异很大而密码学操作需要的是稳定、快速、可管理的随机字节流。因此常见结构是把熵源与确定性随机比特生成器分开前者提供高质量的熵后者基于内部状态持续产出随机数据。需要注意的是这类生成器本身是确定性的——给定完全相同的内部状态它会产生完全相同的输出。它并不创造新的熵只是把高质量的种子安全地扩展成可持续消费的随机流。整条路径可以理解为物理熵源汇入熵池熵池播种生成器生成器向上提供密码学随机字节。这样随机性从哪里来随机状态怎样建立上层如何稳定消费就成了三个可以分别处理的问题。初始化成功之后是否就可以一直用到设备报废通常不该这样理解。长期运行的系统还要考虑内部状态的生命周期、重新播种、异常恢复、状态是否可能被暴露、运行时间是否过长。随机状态本身也是安全状态它需要建立、使用、维护必要时重新建立并在异常时拒绝继续提供不可信的随机性。对上层而言接口最好保持很窄。业务模块不应该有权决定用哪个熵源、如何播种、是否跳过某项健康检查、异常时换用什么备用算法。它能表达的只有我需要安全随机字节而系统要么返回符合当前安全策略的输出要么明确告知随机能力当前不可用。这能显著减少业务代码错误配置密码学基础设施的机会。五、健康语义以及失败时的处理普通程序调用一个随机函数只要返回成功就认为拿到了随机数。安全系统不能这么简单——随机源可能异常、卡死、重复输出底层硬件可能报错内部健康状态可能已经失效。如果此时系统继续消费输出密码学逻辑表面上一切正常实际的随机性假设已经不再成立。所以熵源必须拥有健康语义系统不仅要拿到数据还要知道这个源当前是否仍有资格提供安全随机性。这与前面讨论过的设备健康验证是同一种思路。失败时最危险的处理是给一个默认值让流程继续用时间戳代替用序列号代替用固定种子甚至先返回一段可预测数据把系统跑起来。从可用性看程序没有崩溃从密码系统看这可能是灾难性的——上层仍然认为自己得到了密码学安全的随机数而实际安全属性已经完全改变。这是典型的静默降级随机性不足时不允许它悄悄退化成可预测性。熵源失效首先应该成为一个明确状态。假设系统有两个独立来源其中一个出现健康异常此时要问的不是还能不能生成数字而是剩下的来源是否仍然满足当前的安全设计要求。如果架构明确允许单源在通过独立健康验证后维持有限能力系统可以进入受控降级如果某项关键动作要求两个来源共同参与缺一就应当拒绝。重点不是一坏就永久停机而是——熵源失败之后的能力必须事先定义不能在运行时为了可用性临时发明。多熵源真正困难的设计恰恰在这里其中之一失败怎么办同时失败怎么办返回了数据但健康状态异常怎么办两路都返回成功却无法确认其中一路当前状态又怎么办。所以它不能被画成两个源相加得到安全随机中间还需要一整套准入判断源的状态、健康验证、是否允许其熵进入池、池是否已经具备条件、生成器是否具备继续服务的资格。并不是每一个看起来像随机数的输入都应该自动进入熵池。第一季建立的那套状态模型在这里同样适用。某个源的健康状态无法确认是未知关键熵源尚未初始化是缺失健康结论已经太旧无法代表当下是过期两个安全域对随机子系统是否健康给出相反结论是冲突。这些都不该被自动折叠成随机可用。不知道随机源是否健康不等于随机源健康。恢复同样要有边界。硬件随机源出现瞬态异常后当然可能恢复某些设备在受控流程之后能够重新通过健康验证——这与失败安全的原则一致允许有限恢复、重新初始化、重新验证和必要的重新播种但不能无限重试直到碰巧返回一段数据。那样会把健康失败误读成可用性问题。随机子系统需要的是重新建立可信状态而不是终于拿到了一串字节恢复之后仍须重新确认它的使用资格。六、这一层的失败别的层补不上假设一次高风险执行已经走到最后一步而随机子系统报告安全随机能力不可用。业务能不能说审批都过了先继续如果这一步依赖的密码学操作确实需要新的安全随机性那就不能。业务资格和密码学基础状态是两个独立条件审批为是覆盖不了随机源不健康规则放行也无法让一个失效的基础设施重新变得健康。这正是分层边界的意义——每一层只证明自己负责的事实任何一层的放行都不能替另一层补齐缺失的安全条件。设备首次建立身份的阶段尤其不容将就。那时生成的长期材料可能被使用很多年初始化时的一次随机性失败影响会持续整个生命周期。运行中某个随机值出问题波及的可能只是一轮协议长期身份密钥生成出问题风险却可能被永久固化。所以真正值得重视的不只是运行期的随机能力还包括初始化与身份建立阶段的熵质量——长期秘密不该建立在一次应该没问题的随机性上。原则上无法建立足够可信的随机状态就不应进入正常的设备身份生命周期。七、可以留下证据但不能留下秘密如果某次关键初始化或安全恢复依赖随机子系统系统至少应当能够说明当时随机能力是否处于有效状态某类子系统已正常初始化必要的健康检查通过恢复之后重新建立了可信状态。这让日后能够解释某个密码学操作当时为什么具备执行资格。这里必须和普通日志划清界限。安全工程常有一种冲动——为了将来排查把所有中间值都记下来。在随机系统里这非常危险种子、生成器内部状态、未加工的熵材料、关键中间值一旦进入普通日志就可能直接摧毁原有的安全属性。证明随机系统健康不等于公开随机系统的输出。值得留下的是状态与结论而不是秘密材料本身。也需要说明的是对许多服务器软件而言依赖操作系统提供的密码学随机服务是成熟且正确的方案。讨论硬件熵源并不是否定它真正的分歧点在威胁模型如果信任边界就是操作系统可信那么系统随机服务完全可以作为合理基础如果要进一步考虑主机失陷、设备需要独立身份、密码学操作希望与普通系统域隔离就需要独立的硬件熵源与专门的随机状态。随机性架构必须跟随信任架构——不是所有系统都需要多熵源但高风险系统不该在没有想清楚威胁模型的情况下默认随机数天然安全。八、它是一条流水线不是一个函数把前面这些放在一起会发现真正需要保护的对象并不是某个取随机数的接口而是一整条路径多个独立熵源经过健康检查后汇入熵池熵池播种确定性生成器生成器向上提供安全随机服务最终支撑密钥、一次性标识与挑战值。这条链上的每一层都需要明确的失败语义源失败怎么办健康状态不确定怎么办池未建立怎么办生成器初始化失败怎么办运行中出现异常怎么办恢复之后是否必须重新播种上层在什么条件下必须拒绝。回答了这些随机数才从一个工具函数变成一个安全子系统。它同样服从失败安全健康时正常提供遇到允许恢复的瞬态问题时进入受控恢复并重新验证无法恢复时拒绝那些依赖安全随机性的操作——而不是改用弱随机、固定种子或默认值。随机能力失效时执行能力可以收缩但随机性标准不能为了完成任务而收缩。引入独立熵源的意义与这一季反复出现的思路是同一个我们不希望某一个组件的失陷自动定义整个系统。如果所有长期密钥、一次性标识、挑战值和会话状态都建立在唯一一个随机源上这个源就拥有了极高的隐形权力。自主系统会让这件事更值得认真对待。模型本身不改变密码学原理但它会大幅提高自动执行的频率、凭据的使用次数、临时会话的数量和连接建立的规模。过去一天几十次的调用可能变成持续运行的基础负载——熵源健康、生成器生命周期、异常恢复与状态监测会从低频边缘问题变成系统性问题。密码学在纸面上是算法运行起来却是一条链算法、实现、密钥、随机性、协议、执行控制。其中任何一个基础假设严重失效都会把整体安全性拉回更低的水平。随机性的特殊之处在于它往往不可见——密钥泄露我们知道发生了什么签名失败会报错规则拒绝会明确停止而一个看起来一直正常的弱随机源可能长期输出结果却从不报警。一套密码系统的安全上限不会高于它随机性的可信程度。所以成熟的执行控制不该只问密钥有没有放进安全芯片、签名算法够不够强还要往更底层追一句那些被我们称为随机的东西究竟凭什么值得相信。当系统开始认真回答这个问题时随机性才真正从一个密码学接口变成信任边界的一部分。