【中国观察2026年11月13日讯】
事件背景
Quantum Systems（德国无人机公司，产品包括Vector等侦察无人机，被德国联邦国防军、乌克兰等使用）的QBase地面控制/任务规划软件更新通道遭到攻击。攻击者在更新服务器上放置了伪装成正常更新的恶意文件，文件传到了Bundeswehr等客户服务器，但未实际感染无人机，被检测后德国军方曾临时停飞相关无人机作为预防措施。公司已确认事件并称威胁已遏制、系统可安全运行。这些信息均来自Financial Times、Der Spiegel等公开报道，以及公司官方声明。
现代无人机的安全边界，早已不只是机体、发动机、通信链路和飞控系统。地面控制终端接收什么软件、软件由谁生成、更新包经过谁的签署、客户端凭什么相信它，这些环节同样决定一套无人机系统能否安全运行。
Quantum Systems的QBase更新通道事件，提供了一个值得从密码学角度深入研究的案例。假设攻击者已经控制软件更新服务器，接下来会遇到一道关键门槛：服务器可以把文件发送给客户，却不一定有权让客户相信这个文件。真正的技术较量发生在数字签名、密钥管理、软件构建和客户端验证之间。
这也是为什么分析这类攻击，不能只问服务器有没有被攻破，而应当追问：攻击者能否让一份未经授权的程序获得合法软件的身份？如果可以，究竟是密码学被突破，还是企业内部的发布权限被滥用？两者在技术上有本质区别。
数字签名真正保护的是什么
软件更新通常包含程序文件、配置文件、资源文件和版本信息。供应商将更新包发布到服务器，客户终端下载后安装。假如客户端只检查文件是否来自指定服务器，那么服务器一旦被入侵，攻击者就可能替换文件、修改下载内容，甚至让恶意程序借用正常更新的下载地址。
数字签名就是为了避免客户端完全相信服务器。
典型流程是：软件发布者使用私钥对软件包或包含软件包摘要的元数据进行签名，客户端使用事先信任的公钥验证签名。验证成功，说明签名对应的私钥参与了签署，而且被签署的内容没有在签署之后遭到修改。验证失败，客户端应当拒绝安装。
这里有一个容易被误解的地方：数字签名并不能证明程序没有恶意代码。它只能证明程序符合某个密钥所代表的授权身份，并且内容与签署时一致。如果攻击者控制了合法发布流程，恶意程序也可能获得合法签名。密码学可以证明谁签过文件，却不能自动判断签署者是否受到欺骗、胁迫或内部权限滥用。
这正是软件供应链攻击最危险的地方。
假设QBase客户端采用严格的数字签名验证，攻击者仅仅控制更新服务器，通常不足以让任意篡改文件通过验证。攻击者还需要寻找其他突破口：取得签名密钥、控制签名服务、操纵构建系统，或者利用客户端验证程序本身的缺陷。反过来，如果客户端只检查下载地址、文件名或普通哈希值，却没有可靠的签名验证，那么控制分发服务器就可能足以改变客户端接收的程序。
因此，所谓“恶意更新被发送”，并不等于“恶意更新通过数字签名验证”，更不等于“恶意更新已经成功执行”。这三个阶段必须分别取证。
三种攻击路径决定事件严重程度
第一种情况是攻击者只控制分发服务器。攻击者替换更新包，客户终端下载文件，但客户端使用预置公钥验证时发现签名不匹配，于是拒绝安装。这种情况下，更新服务器已经失守，但签名体系仍然发挥作用。攻击者可以造成更新中断、制造告警、迫使供应商更换服务器，却未必能够执行任意代码。
第二种情况是攻击者控制了软件构建或发布流程。程序源代码可能被修改，构建环境可能被操纵，或者发布审批账户遭到盗用。最终生成的恶意程序仍然经过合法签名服务签署，客户端自然可能验证通过。此时，签名算法没有被破解，私钥也未必被直接盗走，问题出在签名之前的授权链条已经失去可信度。
第三种情况是攻击者取得签名私钥，或者获得能够调用私钥的权限。此时攻击者可以尝试为恶意软件生成合法签名，直接冒用供应商身份。假如同一把密钥被用于多个产品、多个客户或多个软件版本，影响范围可能远远超出最初遭入侵的服务器。
这三种情况的差别，不在于恶意程序看起来是否相似，而在于攻击者获得了哪一种权限。第一种是控制文件分发，第二种是控制合法发布过程，第三种是控制软件身份凭证。对于QBase事件，目前没有公开技术报告说明其签名机制、密钥管理方式或攻击者是否取得签名权限，因此不能判断它究竟属于哪一种。
但从军事安全角度看，最需要排查的不是服务器是否已经重装，而是攻击者有没有获得能够持续冒充供应商的权限。
Ed25519为什么适合无人机软件更新
在现代软件更新系统中，Ed25519是一种值得考虑的数字签名算法。它属于EdDSA签名体系，使用Curve25519的Edwards形式构造，不能简单地说它就是使用X25519密钥交换算法。根据IETF RFC 8032标准，Ed25519公钥为32字节，签名为64字节，安全强度约为128位。
它的优势首先体现在效率和部署便利性。相比RSA-2048，Ed25519的密钥和签名数据明显更短；在许多现代处理器和软件库中，签名与验证性能也很有竞争力。具体速度取决于处理器、密码库和实现方式，不能笼统认定它在所有环境下都比RSA快一个数量级。对于需要在不同地面终端、便携设备和低带宽网络中分发更新的系统，较小的密钥和签名数据有实际价值。
Ed25519另一个重要特点是确定性签名。签名过程不需要像传统随机化ECDSA那样，在每次签名时依赖一个新的高质量随机数。ECDSA如果发生随机数重复或生成质量严重不足，可能导致私钥泄露；Ed25519通过确定性方式生成签名中的临时值，减少了这一类随机数管理风险。
不过，这不意味着Ed25519天然免疫侧信道攻击。程序执行时间、缓存行为、内存访问、错误处理和硬件实现仍可能暴露信息。密钥如果存放在已经被控制的主机内，算法再优秀也无法保护它。Ed25519解决的是签名数学与实现层面的一部分问题，不负责保护操作系统、密钥调用权限和企业发布流程。
还存在一个实际部署问题：部分硬件安全模块、智能卡和嵌入式安全芯片对Ed25519的支持并不一致。有些设备对P-256等算法支持更成熟。因此，军用系统选择签名算法时，不能只比较理论性能，还必须考虑密钥能否放入受保护硬件、客户端能否可靠验证、供应商能否完成密钥轮换，以及整个装备生命周期内能否持续维护。
对QBase这样的系统，Ed25519可以是一个合理选项，但没有证据证明Quantum Systems实际使用了它。更重要的是，即使使用Ed25519，也无法单独解决软件供应链的信任问题。
真正危险的地方是签名密钥如何被调用
许多人谈到软件签名，会把重点放在私钥是否存储于硬件安全模块HSM。HSM确实能够保护私钥，限制密钥导出，并在受控环境中执行签名操作。但它无法自动判断每一次签名请求是否合法。
假设一家无人机企业将签名私钥存放在HSM中，攻击者无法把密钥复制出来，却控制了拥有签名权限的发布服务器。如果该服务器可以不经审批直接调用HSM，那么攻击者仍可能提交恶意程序的摘要，让HSM使用合法密钥完成签名。
从密码学角度看，HSM没有被攻破，私钥也没有被窃取；从实际安全结果看，攻击者却可能获得了合法签名能力。
这说明密钥保护必须分成两个问题：私钥能否被偷走，以及谁能够要求它签名。
更成熟的设计应当把代码构建、软件测试、发布审批和签名操作分开。签名服务不应仅凭一台企业服务器的请求就签署任何文件。系统需要核对发布任务、软件版本、构建来源、审批身份和目标产品。涉及军事用户的更新，还可以要求不同人员或不同组织分别批准。
如果使用多重签名机制，攻击者就不能只控制一个账户便完成发布。例如，软件更新需要三把授权密钥中的两把签署，密钥分别由不同部门或不同管理人员掌握。攻击者必须同时突破多个独立权限边界，难度明显提高。
这里还应区分多重签名和简单的多人登录审批。多人共同输入密码，并不必然形成独立的密码学信任边界。如果所有审批最终都由同一台被控制的服务器执行，所谓多人审批可能只是流程上的形式。
更新服务器之外，还需要一套独立的信任体系
传统更新系统经常采用这样的结构：客户端连接供应商服务器，下载更新包，再验证签名。如果服务器被控制，攻击者至少可以控制客户端看到什么、何时看到，以及是否能够正常获取更新。
即使攻击者没有签名密钥，也可能通过阻断更新、持续提供旧版本或隐瞒最新安全修复，制造另一类攻击。这类风险被称为回滚攻击和冻结攻击。
回滚攻击是让客户端安装已经存在漏洞的旧版本；冻结攻击则是让客户端一直停留在旧状态，使其无法获知新版本或安全修复已经发布。它们不一定需要伪造合法签名，只要利用更新系统对版本、时间和发布状态检查不足，就可能得逞。
这正是The Update Framework（TUF，软件更新框架）试图解决的问题。TUF并不只依靠一把密钥签署所有更新，而是把信任拆分为不同角色，包括根密钥、目标文件密钥、快照元数据和时间戳元数据，并支持多密钥阈值签名、密钥轮换、版本检查和过期时间验证。客户端可以据此识别未经授权的更新、旧版本回滚和长期冻结。
这套思路对无人机软件尤其重要。假设攻击者控制了QBase更新服务器，却没有控制根密钥和目标文件签名密钥，那么服务器就不能随意改变客户端认可的软件版本和文件摘要。即使服务器故意提供旧文件，客户端也可以通过版本号和元数据有效期识别异常。
更进一步，军事用户可以把更新包从供应商服务器下载到隔离环境，再通过独立渠道核对签名和版本元数据。供应商负责提供软件，军方保留验证软件的能力。这样，供应商服务器就不再是唯一决定软件可信度的权威。
软件签名之前，必须证明程序是怎样生成的
数字签名还有一个经常被忽略的盲区：它不能证明程序来自安全的源代码，也不能证明构建环境没有被操纵。
设想攻击者没有接触签名私钥，却成功进入开发人员账户，在源代码中植入一段隐藏功能。代码通过自动构建系统生成软件包，再由合法签名服务签署。客户端收到的程序通过所有签名检查，但恶意代码早已进入构建结果。
这时，单纯检查签名没有意义。需要进一步验证软件包从源代码到最终二进制文件的完整生产过程。
一种重要方法是软件构建来源证明，也就是Build Provenance。它记录软件由哪个代码仓库、哪个提交版本、哪个构建平台、使用哪些依赖和参数生成，并通过数字签名保护这些记录。接收方可以核对软件包的加密摘要与构建来源证明，判断文件是否来自预期的构建流程。
SLSA框架提出了逐级提高构建安全性的要求，包括构建来源证明、由受控构建平台生成并签署证明，以及强化构建环境，降低攻击者在构建过程中篡改软件的可能性。
如果把这套机制应用到无人机软件更新，军方收到的就不应当只有一个安装包，还应当有一份可以验证的生产记录：哪个版本的源代码生成了它，构建发生在什么环境，依赖库是否经过审查，最终文件的哈希值是什么，签名由哪一组授权密钥完成。
这会改变军事用户与软件供应商之间的关系。军方不必获得供应商全部源代码，也能要求供应商提供经过签署的构建证明，并由独立审计机构核验关键环节。软件是否可信，不能只由供应商自己宣布。
如果签名密钥失陷，如何让整个系统重新建立信任
最棘手的情况，是攻击者已经取得合法签名密钥，或者有证据表明签名服务曾被未经授权调用。
此时，简单删除恶意文件、重装更新服务器并不能彻底解决问题。攻击者可能已经复制密钥，也可能掌握了签名服务的访问凭据。即使企业重新部署服务器，只要客户端仍然信任原来的密钥，旧有信任关系就可能继续被利用。
正确的处置应当包括撤销或更换受影响密钥、重新建立客户端信任锚、审查历史签名记录，并确认攻击者是否在失陷期间签署过其他软件包。对于已经离线或长期未联网的军事终端，还必须考虑如何安全地传递新的信任根。
这里存在一个比更换服务器复杂得多的问题：客户端凭什么相信新的公钥？
如果新公钥仍然由已经失陷的旧密钥签署，攻击者可能继续伪造密钥轮换过程。因此，成熟的更新体系通常需要预先设计根密钥轮换机制、多重签名和可信的密钥恢复程序。TUF的根角色更新流程就要求新根元数据同时满足旧信任体系和新信任体系规定的签名阈值，并检查版本连续性，防止攻击者利用密钥替换过程夺取控制权。
这也是为什么军用软件不能等到发生攻击后才临时考虑密钥轮换。密钥失陷后的恢复方案必须在系统设计阶段就准备好，而且要定期演练。
对QBase最有价值的技术推演
把上述技术机制放回QBase事件，可以提出几个比“服务器是否被黑”更有穿透力的调查问题。
如果QBase客户端强制验证数字签名，那么被篡改的更新文件究竟是被客户端拒绝，还是成功通过验证？如果通过了验证，是因为签名密钥遭到控制，还是发布审批账户被滥用？如果文件没有通过验证，恶意文件为什么仍然能够进入客户笔记本电脑？它是被下载但没有执行，还是通过其他安装机制运行？
其次，Quantum Systems是否将签名密钥与更新服务器隔离？签名服务是否部署在HSM中？企业管理员能否直接调用签名接口？签名是否需要多人审批？每一次签名是否都有不可随意修改的审计记录？这些问题决定攻击者能否从服务器入侵进一步升级为合法软件发布权限的控制。
还需要核查QBase是否具备防回滚和防冻结机制。假如攻击者无法签署新版本，却可以控制服务器持续提供旧版本，军方终端是否能够发现软件版本长期没有更新？如果攻击者只让部分客户接收不同版本，供应商能否从独立日志中识别这种异常？
最后是军方自己的验证能力。德国联邦国防军是否持有独立的可信公钥或根密钥？是否能够脱离供应商服务器验证软件包？恢复飞行前，是否核对了软件摘要、签名证书、版本元数据和构建来源证明？这些细节目前没有公开，不能仅凭恢复飞行推断所有环节都已经通过独立审计。
从技术上推演，最危险的情况未必是攻击者破解Ed25519或RSA这样的密码算法。现代密码算法经过长期研究和标准化，直接破解它们通常远比寻找密钥管理、发布审批和客户端验证中的薄弱环节困难。攻击者更可能寻找的是密码学体系之外的入口：被盗账户、失控的CI/CD流水线、可被滥用的签名接口、没有隔离的构建环境，以及无法独立验证更新的客户终端。
这也解释了一个重要现象：一套系统即使使用了最先进的签名算法，仍然可能遭受严重的软件供应链攻击。算法负责保护签名，工程架构负责保护签名之前和之后的整个过程。任何一个环节把权限集中在同一台服务器、同一个账户或同一组管理员手中，攻击者就可能绕开密码学本身。
对于军事无人机，理想的更新架构应当采用独立根密钥、阈值签名、硬件保护的签名服务、受控构建环境、可验证的软件生产记录、客户端强制签名检查，以及防回滚和防冻结机制。军方还应当保留独立验证和恢复能力。Ed25519可以成为其中的签名工具，但真正的安全来自多个相互独立的信任边界。
QBase事件尚未公开足够的技术资料，无法确认Quantum Systems采用了哪一种签名算法，也无法判断攻击者是否突破了签名或构建环节。然而，这并不妨碍提出一个明确的技术判断：控制更新服务器，只代表攻击者获得了向客户发送文件的能力；控制合法发布权限，才可能获得让客户信任恶意软件的能力。 这两者之间隔着整套软件供应链安全体系，而这道防线究竟有多坚固，才是这次事件最值得调查的技术核心。
资料来源与技术标准
IETF RFC 8032，EdDSA：Ed25519与Ed448数字签名标准
The Update Framework（TUF），软件更新安全框架及客户端验证规范
SLSA Framework，软件构建来源证明与构建完整性标准
Quantum Systems，2026年11月12日网络安全事件声明
Reuters及Financial Times，2026年11月关于Quantum Systems网络攻击和QBase更新事件的报道