-
-
[原创]卫星互联网最难的不是加密，是几百万把钥匙怎么管（二）
-
发表于: 22小时前
-
一张被盗的证书，最长能被继续滥用多久？这个数字不用猜，用 OpenSSL 就能量出来。
验证工具：OpenSSL（本文命令都基于它）｜标准：RFC 5280
密钥管理拆开是五件事：生成、存储、分发、轮换、撤销。前三件做得好不好，取决于愿不愿意花钱；后两件做得好不好，取决于链路答不答应——而卫星链路恰好最不配合。
上篇讲了冷战时为什么要靠人把密钥押运到每个节点，以及那套办法依赖的四个前提（节点少、位置固定、可物理触达、生命周期长）如何被低轨星座同时打破。结论是：过时的不是算法，是分发和轮换的假设。
没看过上篇也能直接读这篇，只需记住一件事：加密、签名、哈希这些手段全都建立在"密钥没出事"的前提上，而密钥会不会出事，不由算法决定。
下面就看具体是哪几个环节会断。
把密钥管理拆成五个环节
"密钥管理"这个词太笼统，容易变成一句空话。拆开看，它是五件不同的事，每件事的失败方式都不一样。
环节 | 要解决什么 | 卫星互联网的特殊性 |
|---|---|---|
生成 | 密钥从哪来，随机性够不够 | 终端出货量大，产线本身是攻击面 |
存储 | 密钥放在哪，设备被拆开能不能读出来 | 终端在用户手里，浮标常年无人值守 |
分发 | 怎么让通信双方都拿到可信凭据 | 从预置密钥转向证书体系 |
轮换 | 多久换一次，换的过程会不会断 | 在轨设备不能停机，终端过站窗口短 |
撤销 | 出事之后怎么让全网都拒绝它 | 链路间断，撤销信息不一定送得到 |
前三个环节业界基本有共识，方案也成熟。真正难的是后两个——但前三个决定了后两个有没有条件做好。
生成：私钥有没有离开过芯片
终端密钥有两种来法。
出厂注入：产线上生成密钥，写进设备。成本低，流程简单。
设备内自生成：安全元件内部产生密钥对，私钥永不导出，只把公钥送出去申请证书。
两者的安全差距不在算法，在一个事实上的区别——注入意味着你的私钥明文曾经存在于厂商的产线上。产线的物理安全、日志留存、人员管理，从此都在你的信任边界里。
大规模消费级终端为了压成本，倾向选注入。更糟的情况是同批次设备共享密钥，那时候攻破一台等于攻破一批。
存储：假设设备已经被拆开
密钥是整个加密系统的心脏——这话听着像口号，意思却很具体：密钥泄露，等于所有加密同时失效。
放到卫星互联网，这一环的压力比传统机房大得多。用户终端装在别人家院子里，海上传感器和浮标常年无人值守，无人机可能直接落到对手手里。"设备可被物理获取"在这些场景里不是极端假设，而是默认前提。
于是判据可以很简单：假设攻击者已经拿到实物、并且有耐心拆开，他能不能读出密钥？
明文写在 flash 里，答案是能。硬编码在固件里，答案也是能——而且不用拆，下载一份固件就够了（怎么系统性地审这类问题，本号 2026-07-14日发表的那篇写过）。用安全元件，答案才变成"代价很高"。
注意，是代价高，不是不可能。
分发：PKI 没有消灭预置，只是改变了数量级
冷战方案的根本瓶颈是密钥对数量。n 个节点两两通信，要管理的密钥对是 n 的平方量级。几百个节点还能忍，上千万台终端完全不可行。
证书体系（PKI）换了个思路：不预置每一对通信的密钥，只预置根信任。设备出厂时带上根证书和自己的证书，验证对方时靠签名链，不靠事先见过面。
这一步用的正是数字签名。证书说白了就是一份"某个公钥属于某个身份"的声明，再由上级机构用它的私钥签个名。我不认识你，但我认识给你签名的那家机构，于是我用它的公钥验一下签名——只要这条链能一路验到我出厂就装好的那个根证书，我就信你。信任不再靠见过面，靠的是能不能验到共同的根。
这就是从"设备编号"到"密码学身份"的转变。它在一次具体握手里如何发生，本号 2026-08-18 那篇拆过。
但有个容易被跳过的点：PKI 并没有消灭预置这件事。根证书仍然要在出厂时进设备，这个动作依然需要一条可信的产线。PKI 真正做到的，是把预置规模从"每对通信一把密钥"降到"每台设备一份根信任"——数量级降了，环节没消失。
这个判断有实际意义。产线不可信，信任根就不可信，后面所有的证书验证都是在验证一个假前提。
轮换和撤销，才是卫星互联网的真问题
前三个环节的难点是成本和工程纪律，方案本身没有争议。后两个不一样——它们直接和卫星链路的物理特性打架。
轮换：不敢换，比不会换更常见
密钥用得越久，泄露的累积概率越高；一旦泄露，同一把密钥保护过的历史通信会被一起解开。定期更换，是把影响面切成小块。
道理没人反对。难的是在卫星互联网里执行。
在轨设备无法召回。星上密钥只能远程更换，而更换一旦中断，可能直接失去这颗卫星的可控性。这是把一个不可逆操作压在一条会丢包的链路上，所以工程上必须留退路——新旧密钥并存一段时间、双槽位切换、验证成功再废弃旧的。没有回滚路径的轮换设计，等于给自己埋一颗定时炸弹。
过站窗口短且不连续。低轨卫星一次过顶通常只有几分钟，终端也不保证一直在线。轮换动作不能假设"下发一次就成功"，必须可重试、可断点续传，而且重复执行不产生副作用。
规模会反噬。上千万台终端不可能同时轮换，签发系统会被自己打爆。所以必须分批、有节奏。这又意味着任何时刻网络里都同时存在新旧两代密钥，验证逻辑得容忍这种混杂状态。
三条加起来，是一个很朴素的运维现实：因为轮换有风险，很多系统的实际做法是能不换就不换。
安全材料通常把"密钥长时间不更换"归因为容易被破解。但在真实系统里，它往往不是因为团队不知道该换，而是因为没人敢在一个跑得好好的系统上做这个操作。
所以评估轮换能力，光看支不支持没用。该问的是：上一次真的换过是什么时候，换的时候出过什么问题。
撤销：从丢失到全网拒绝，需要多久
换一个更具体的事故。
一台终端被人拿走、拆开，私钥被提取出来了。
注意此时发生了什么：算法没有被攻破，证书还在有效期内，签名验证完全能通过。攻击者手上拿的是一个合法身份。
这里要回到签名的定义——它证明的是"这条消息出自持有该私钥的人"，从来不负责判断这个人该不该还持有它。私钥换了主人，签名照样有效，密码学在这里帮不上忙，因为系统的每一步验证都在正确工作。
唯一的补救是撤销——让所有校验点都开始拒绝这个身份。
问题于是变成一句话：这条"拒绝它"的消息，多久能送到最后一个校验点？
业界只有三条路，每条都要付代价。
• CRL（证书撤销列表）：定期下发的黑名单。好处是校验点可以离线用，天然适合链路间断的场景。代价是下发周期就等于暴露窗口，而且百万级规模下，这份列表本身会膨胀成一个需要认真对待的分发负担
• OCSP（在线状态查询）：每次验证实时问一次。好处是及时。代价是需要在线、每次验证多一个往返——放在高延迟或间断链路上是硬伤，而且校验点从此依赖一个新的在线服务
• 短有效期证书：干脆不撤销，让它自己过期，用重签频率换撤销及时性。有效期从 90 天压到 24 小时，暴露窗口差近两个数量级。代价是签发系统的持续负载，以及设备必须能定期联网续签——离线太久的设备会自己把自己锁死
三条路没有一条是免费的，选哪条取决于你对链路连续性的假设。如果能假设设备大体在线，OCSP 或短证书更合适；必须容忍长时间离线，就只能接受 CRL 那个延迟窗口。
这里可以收一个判断：撤销的时效性不是密码学问题，是分发问题。它取决于你的网络能多快把一条消息送到最后一个校验点——而这恰好是卫星互联网最不擅长的事。
难点不是均匀摊在五个环节上的。前三个环节做得好不好取决于愿不愿意花钱，后两个环节做得好不好取决于链路答不答应。
密钥生命周期的五个环节，难点集中在轮换与撤销
动手看：有效期和撤销窗口
有效期、CRL、OCSP 都不是抽象概念，它们就写在证书里。用 OpenSSL 几条命令就能把它们变成具体数字。
下面的输出是 2026 年 9 月 8 日实测的，你跑的时候数字会变，方法一样。
# 取 TLS 连接的证书，读出签发者与有效期
# 注意：管道只解析链上第一张（叶子）证书
openssl s_client -connect 616K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6i4y4@1j5i4u0D9K9h3&6C8i4K6u0W2j5$3!0E0i4K6y4m8y4o6b7K6 -servername cd5K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6i4y4@1j5i4u0D9K9h3&6C8i4K6u0W2j5$3!0E0 \
</dev/null 2>/dev/null \
| openssl x509 -noout -subject -issuer -dates实测输出：
subject=CN = starlink.com
issuer=C = US, O = Let's Encrypt, CN = YR2
notBefore=Sep 1 10:43:06 2026 GMT
notAfter=Nov 30 10:43:05 2026 GMT有效期正好 90 天。这个跨度就是签发方在"撤销及时性"和"签发负载"之间的选择——有效期越短，一张被盗证书能被滥用的窗口越小，代价是要更频繁地重签。
再看撤销信息发布在哪：
# 存下叶子证书
openssl s_client -connect 8b9K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6i4y4@1j5i4u0D9K9h3&6C8i4K6u0W2j5$3!0E0i4K6y4m8y4o6b7K6 -servername 9acK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6i4y4@1j5i4u0D9K9h3&6C8i4K6u0W2j5$3!0E0 \
</dev/null 2>/dev/null | openssl x509 -outform PEM > leaf.pem
# 撤销信息发布点（-ext 需要 OpenSSL 1.1.1 及以上）
openssl x509 -in leaf.pem -noout -ext crlDistributionPoints,authorityInfoAccess
# 单独取 OCSP 地址
openssl x509 -in leaf.pem -noout -ocsp_uri结果里有个值得停一下的地方：
Authority Information Access:
CA Issuers - URI:363K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4W2J5x3W2)9J5k6h3W2Q4x3X3g2D9k6h3&6U0M7W2)9J5k6h3!0J5k6#2)9J5c8R3`.`.
X509v3 CRL Distribution Points:
Full Name:
URI:549K9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4W2J5x3W2)9J5k6h3y4Q4x3X3g2D9k6h3&6U0M7W2)9J5k6h3!0J5k6#2)9J5c8U0t1@1i4K6u0W2j5%4u0D9Authority Information Access里只有 CA Issuers，没有 OCSP - URI；-ocsp_uri返回空。这张证书根本不提供 OCSP。
不是命令写错了。Let's Encrypt 在 2024 年 12 月的公告里给出了停止 OCSP 的时间表：2025 年 5 月 7 日起从证书中移除 OCSP 地址，8 月 6 日关停 OCSP 响应服务。所以 2026 年签发的证书里没有它，是预期结果。
公告给出的首要理由是隐私——每验证一次，运营 OCSP 的 CA 就立刻知道某个 IP 正在访问哪个网站；即便 CA 自己不留存，也可能被法律强制要求收集，而 CRL 没有这个问题。第二个理由更实际：多年来维持 OCSP 服务一直占用可观资源，砍掉它能让 CA 基础设施更简单。
它保留 CRL，同时靠 90 天有效期控制风险。
前面讲的第三条路，业界已经在走了。
那就顺着 CRL 看下去。这一步能量出撤销机制的真实代价：
# 从证书里取出 CRL 地址并下载
CRL=$(openssl x509 -in leaf.pem -noout -ext crlDistributionPoints \
| grep -oE 'http://[^ ]+')
curl -s -o crl.der "$CRL"
# 体积
ls -l crl.der | awk '{print "CRL 体积:", $5, "字节"}'
# 刷新窗口：lastUpdate 到 nextUpdate 之间，就是这份黑名单的保鲜期
openssl crl -in crl.der -inform DER -noout -lastupdate -nextupdate
# 列表里有多少条撤销记录
openssl crl -in crl.der -inform DER -noout -text | grep -c "Serial Number:"四个数字：
• CRL 体积：184995 字节，约 181 KB
•
lastUpdate：Sep 8 02:49:03 2026 GMT•
nextUpdate：Sep 17 02:49:02 2026 GMT• 撤销记录数：4919 条
把前两个放在一起，就得到了这套体系对"证书被盗后最长能被滥用多久"的实际承诺：证书有效期 90 天，撤销列表的刷新窗口 9 天。一张被盗证书在最坏情况下，可能有接近 9 天时间仍被那些还没拉取新列表的校验点接受。
这两个数字都不是缺陷，是明确的工程取舍。放到卫星互联网的语境下，麻烦才显出来。
181 KB、4919 条记录，这只是 Let's Encrypt 众多 CRL 分片中的一个。现在设想把同等量级的列表定期推送给上千万台终端，而这些终端过顶窗口只有几分钟、还不保证一直在线。
分发这份黑名单本身就成了一件需要认真设计的事——它和用户流量抢的是同一条链路。前面那个判断在这里落了地：撤销做不好，往往不是因为不会撤，而是因为消息送不到。
最后必须说清边界：这些命令验证的是地面互联网侧的证书体系，不等于看到了星座内部的密钥体系。卫星与地面站之间、星间链路上用什么密钥、多久轮换一次，属于运营方不公开的部分。终端侧究竟能观测到什么、边界在哪，本号 2026-09-04 那篇讨论过。
统一管理是对的，中央化不是免费的
这类问题的标准答案是：中央密钥管理中心，加上统一的 PKI、统一审计、统一应急响应。所有子系统的密钥由一个中心生成、分发、轮换、监控，发现泄露时统一撤销。
它解决的是真问题。三套系统各管一摊，就会有三套轮换节奏、三个应急流程，出事时没人说得清影响范围。统一之后，"撤销一个身份"至少有了唯一的执行入口。
但这个答案通常只讲了一半：中央化本身制造了一个新的高价值单点。
有个反复出现的案例——某机构的 CA 根密钥被获取，结果是它签发过的所有证书都不再可信。把签发权集中到一个中心，也就把攻击者的最优目标集中到了一个点。
所以更准确的说法是：中央化该集中的是策略和签发权，不是把所有密钥搬进同一个库里存着。根密钥离线保管、密钥分段、签发需要多人授权——这些措施之所以存在，正是因为承认了这个单点的存在。
顺带说一个在卫星安全讨论里出现频率很高的误解："已经加密了，所以安全"。
这正是加密、签名、哈希三件事互不替代的地方（上篇开头对齐过这三个词）。加密只挡"被人看到"，挡不住冒充（那要靠签名）和篡改（那要靠哈希），更挡不住访问控制、物理安全、人员流程上的漏洞。接收端的机器被人控制，前面所有加密都归零——信封封得再严，收信人已经把门打开了。
结语：三个问题
要评估一个卫星星座、或者一套卫星通信方案的安全成熟度，我建议别从算法问起。
算法这一层，公开标准早就够用了。真正区分水平的是生命周期运维，而它藏在三个很具体的问题里：
1. 密钥多久轮换一次，上一次真的换过是什么时候，轮换失败怎么回滚？
2. 一台终端丢失后，多久能让全网所有校验点都拒绝它？这个数字是能量出来的，就是前面用 OpenSSL 量的那种数字（有效期 + 撤销刷新窗口）
3. 在轨设备的密钥能不能远程更换，更换中断会发生什么？
三个都答得上来，说明对方在真的运营这套体系。答不上来、或者只反复强调用了什么算法，那大致可以判断：他们把密码学当成了一个采购项，而不是一件要持续做的事。
上篇开头那个提着箱子的人，其实很清楚一件事——钥匙送到，只算完成了一半。另一半是接下来十几年里每一次换钥匙。
这件事到今天没变。变的是要送的钥匙从几百把成了几百万把，而且再也没有人能亲手送过去。
参考资料
• RFC 5280：X.509 证书与 CRL profile
• Ending OCSP Support in 2025：Let's Encrypt 2024 年 12 月 5 日公告
• 本号相关文章：2026-05-29（卫星互联网四条路线）、2026-08-21（Starlink IoT 的加密与身份认证）、2026-07-14（卫星终端固件的 AI 代码审计）、2026-09-04（终端 gRPC 链路质量）
• 文中 OpenSSL 实测数据采集于 2026 年 9 月 8 日，OpenSSL 3.0.16，目标站点 31eK9s2c8@1M7q4)9K6b7g2)9J5c8W2)9J5c8Y4N6%4N6#2)9J5k6i4y4@1j5i4u0D9K9h3&6C8i4K6u0W2j5$3!0E0
文章来源：盛邦安全太湖实验室
|
|
|---|---|
