无边界信任：卫星飞行软件的架构分析

大家读完觉得有帮助记得关注和点赞！！！

摘要

随着航天器变得更加软件驱动和互联，机载飞行软件成为一个日益重要的安全边界。流行的飞行软件架构通常将机载组件视为可信对等体，这简化了集成，同时限制了内部隔离和访问控制。我们分析了NASA的核心飞行系统，以研究权限、身份、通信、可观测性和持久性是如何在机载组件之间分布的。利用NASA具有飞行代表性的NOS3模拟器，我们通过五个实验验证了这些弱点，实验中使用了恶意机载组件来滥用合法的架构权限。然后，我们将cFS与其他模块化飞行软件框架进行比较，以识别重复出现的信任假设和架构弱点。我们的结果表明，单个受损组件可以以难以与合法行为区分的方式利用广泛共享的权限。最后，我们总结了架构意义，并讨论了在未来飞行软件系统中加强内部信任边界的机制。

I 引言

航天工业预计到2032年将超过一万亿美元[84]。卫星已成为支持电信、地球观测、科学实验、导航和国防的关键基础设施。为了满足快速部署日益增长的需求，现代航天器越来越依赖模块化的、基于组件的飞行软件框架。在此背景下，组件是一个模块化软件单元，它封装了特定功能，并通过定义的接口与系统其余部分交互[66]。这些框架将航天器功能分解为单独开发的组件，这些组件实现诸如导航、遥测处理或硬件控制等航天器功能。然后，这些组件通过共享消息基础设施和系统服务进行通信。这种架构模型提高了可维护性和灵活性，同时使得日益复杂的软件栈能够由可重用组件组装而成。

我们认为，共享软件服务在提高开发效率的同时，也通过公共消息基础设施、系统服务和运行时环境，在机载应用程序之间创建了隐含的信任关系。因此，安全不仅取决于防止初始组件受损，还取决于在预防措施失效时约束组件的权限。然而，现有的卫星安全研究主要集中于外部攻击、通信漏洞、地面段受损和实现缺陷，而对飞行软件架构本身是否强制执行安全边界关注相对较少。这一差距很重要，因为受损组件可能会滥用其被合法授予的权限，而无需利用额外的漏洞，从而可能规避针对初始入侵或实现级缺陷的代码审查和防御措施。

为弥补这一差距，我们将NASA的核心飞行系统（cFS）的架构作为现代基于组件的飞行软件的代表性示例进行分析，cFS是最 prolific 的开源飞行软件框架[59]。由于没有任何单一的架构机制能决定一个组件是否受到有意义的约束，我们通过五个互补的、以安全为中心的“视图”来审视cFS：执行、身份、通信、可观测性和持久性。这些视图共同捕捉了权限是如何授予组件的，它如何在系统中被行使，其行为是否可被归因，以及其影响是否能在恢复重置后存续。这使我们能够审视整个架构如何建立、传播和限制机载组件之间的能力。

为评估我们识别的架构弱点的实际后果，我们在NASA的航天器系统操作模拟器中实现了一个恶意的机载组件。我们使用此实现来测试这些弱点是否可在具有飞行代表性的任务环境中被利用。在确认弱点后，我们对其他开源飞行软件框架进行了有针对性的分析，以确定类似的信任假设和架构弱点是否超出了cFS的范围。

我们的结果表明，cFS通过共享执行、不受限制的组件间通信以及有限的基于身份和策略的强制措施，授予了机载组件广泛的权限。因此，该架构在受损组件开始执行后，几乎没有提供有效的机制来遏制它。我们的比较分析进一步表明，这些弱点并非cFS独有：其他开源飞行软件框架也表现出类似的对共享服务、可信组件和薄弱内部隔离的依赖。总之，这些发现表明，缺乏可强制执行的信任边界是现代模块化飞行软件中一个更广泛的架构问题，必须加以解决。

图 1： 模块化飞行软件中的架构信任关系可能允许低权限组件影响超出其预期职责的安全关键服务。

贡献。 本文做出以下贡献：

• 对cFS中架构弱点的系统性分析。 我们开发并应用了一个框架，用于分析基于组件的飞行软件在执行、身份、通信、可观测性和持久性方面的信任。利用该框架，我们识别了cFS在哪些方面未能建立可强制执行的信任边界，并描述了这些弱点的安全后果。

• 对架构信任假设的实验评估。 我们在NASA的NOS3模拟器中实验验证了已识别的架构弱点，并仅使用架构允许的机制展示了系统范围的影响。

• 对开源飞行软件的比较分析。 我们将我们的框架应用于其他开源飞行软件架构，以确定在cFS中识别的信任假设和强制弱点是否在当代基于组件的框架中重复出现。

• 架构设计意义。 基于我们的发现，我们讨论了在未来飞行软件系统中建立可强制执行信任边界所需的机制，包括身份传播、策略强制和强制日志记录。

II 背景与相关工作

II-A 飞行软件背景

飞行软件传统上是围绕可靠性、确定性执行、资源效率和容错等严格要求设计的。诸如cFS之类的框架通过提供用于通信、定时、事件报告、数据管理和硬件访问的共享服务来支持这些目标，从而减少重复并简化任务开发。这些架构通常假设机载应用程序作为单一软件栈的可信部分进行协作，而不是作为相互不信任的元素运行。因此，通用系统中用于实施强内部安全边界的机制可能在框架中缺失、可选或处于框架外部，从而允许受损组件通过其他合法的接口行使实质性的权限。

表I总结了本研究考虑的最著名的公开文档化开源飞行软件。尽管实现不同，但这些框架共享重复出现的架构特征，包括组件抽象、标准化的组件间接口、共享通信基础设施，以及对任务特定和第三方软件的支持[55]。这些特征与安全相关，因为它们决定了组件如何通信、访问共享服务、行使权限以及与任务关键资源交互，使得底层架构成为评估隔离、权限边界、可观测性和故障隔离的核心。

表 I：当今可用的著名开源飞行软件 [55]。

表 II：先前飞行软件安全研究与本工作的关系。

II-B 相关工作

卫星安全研究主要集中于外部通信链路和地面系统入侵 [34, 86, 32]，通常将飞行软件栈视为可信环境。因此，信任滥用的安全影响受到的关注有限。为明确这一差距，我们回顾了先前的工作，并根据其检查的攻击面进行组织。

外部通信和射频侧攻击。 最大量的先前工作将对手建模为在航天器外部运作，针对射频链路和协议级通信表面。这包括欺骗和干扰攻击 [67, 77, 74]，针对卫星星座的广播风暴和大规模拒绝服务 [29, 95, 51]，以及重放和注入攻击 [71, 96, 52]。这些工作大多忽略了飞行软件栈，并假定不安全性源于通信协议漏洞利用。

地面段和基础设施入侵。 第二类工作研究通过地面基础设施（包括地面站、任务控制软件和卫星网络服务提供商）进行 pivoting 的对手。代表性事件包括宽带网络入侵和任务控制滥用 [90, 73] 以及用户终端利用 [82]。这些工作也大多忽略了飞行软件栈，并假定不安全性源于入侵地面侧控制基础设施。

机载软件和飞行软件安全。 近期工作已证明机载软件中的实现缺陷如何导致系统受损。Donchev 等人 [9] 利用自定义飞行应用程序中的缓冲区溢出，在底层操作系统上执行 shellcode。Hansen 等人 [31] 通过修改文件管理组件演示了勒索软件，而 Willbold 等人 [92] 表明，不安全的遥控指令接口、内存漏洞和不安全的更新机制可以实现任意代码执行。这些研究展示了传统软件漏洞的后果，但并未审视飞行软件架构所建立的更广泛的信任关系。

其他工作研究了飞行软件架构中特定的安全相关机制。Boehm 等人 [2] 识别了 F' 外部接口中的弱点，并建议进行命令认证、链路加密和安全默认设置。Schalk 等人 [79, 80] 演示了针对 cFS 软件通信总线的攻击，并提出了总线级的检测和缓解措施。Furgala 等人 [28] 将 cFS 移植到 seL4 以加强操作系统隔离，而 McAmis 等人 [53] 表明，受损的外设可以操纵基于 cFS 的系统中的数据和时序。这些努力加强或评估了单个接口和机制，但并未分析信任和权限如何在整个飞行软件架构中传播。

研究空白。 综上所述，这些工作识别了整个飞行软件中的漏洞，包括软件总线、操作系统、外设接口和外部通信路径中的弱点。然而，如表II所总结，先前的研究主要是在孤立状态下评估单个攻击面和防御机制。因此，尚不清楚这些漏洞是源于实现缺陷，还是源于跨越整个飞行软件栈的架构信任假设。本工作通过评估决定机载组件可用权限及其对系统其余部分影响范围的信任关系来填补这一空白。

III 方法与威胁模型

为确定现代飞行软件架构是否在机载软件组件之间提供了可强制执行的信任边界，我们结合了架构分析、实验验证和比较分析，如图2所总结。

III-A 高层方法

目标1：描述架构信任。 我们系统地将NASA的核心飞行系统分解为其主要的架构元素：执行、身份、通信、可观测性和持久性，以确定该架构是否在机载组件之间强制执行最小权限和隔离。此分析源自公开文档、源代码、启动配置和参考任务部署 [64, 65, 58, 62, 63, 54, 61, 7, 27]。

目标2：验证架构行为。 我们实验评估受损的cFS应用程序是否可以使用合法的框架机制，在NASA的NOS3飞行代表性环境中产生超出其预期角色的安全相关影响。

目标3：评估普适性。 最后，我们使用我们的框架审视其他开源飞行软件，以确定在cFS中识别的架构信任假设是在当代飞行软件中重复出现，还是单个框架的实现问题。

图 2： 我们将工作组织为三个步骤：首先，我们对飞行软件架构进行系统分析。接下来，我们开发概念验证攻击以理解对已建立安全期望的违反。最后，我们衡量我们的发现对其他飞行软件框架的普适性。

III-B 威胁模型

我们假设攻击者已将恶意代码引入了一个原本功能正常的飞行软件系统的一个组件中。该代码可能源自受损的依赖项、恶意更新、内部人员行为或其他入侵机制。由于本研究侧重于受损组件的架构后果，初始入侵机制不在其范围内。

攻击者目标。 攻击者的总体目标是利用受损组件的合法访问权限，影响其预期角色之外的资源、应用程序或操作。每个攻击所评估的具体目标和成功条件在第V节中定义。

攻击者能力。 攻击者可以编写在组件被合法分配的上下文中执行的恶意代码。攻击者可以调用服务、访问资源并使用通常对该组件可用的通信机制。攻击者不利用额外的实现漏洞、不修改操作系统或飞行软件框架、不绕过强制控制，也不获取超出分配给受损组件权限的特权。

在此模型下，我们检查飞行软件架构在受损组件开始执行后是否对其进行了有意义的约束。

IV 架构分析

架构分析方法。

为使软件架构提供有意义的安全边界，它必须限制每个组件能做什么，识别哪个组件执行了某个动作，控制组件如何与系统其余部分交互，记录足够的信息以调查安全事件，并确保未经授权的更改不会在恢复后存续。这些要求遵循已建立的最小权限、完全仲裁、可问责性和可信恢复原则 [78, 33, 76]。

基于这些要求，我们将分析组织为五个以安全为中心的“架构视图” [4]。每个视图解决一个关于飞行软件是否围绕执行组件建立和强制边界的不同问题：

1. 执行视图： 组件在哪里运行，它接收什么权限和资源？

2. 身份视图： 系统是否为每个组件分配了不同的身份，并在交互过程中保留该身份？

3. 通信视图： 组件如何与其他组件和共享服务交互，这些交互是否受到可强制执行的策略检查的约束？

4. 可观测性视图： 组件行为是否以允许其被检测和归因的方式被记录？

5. 持久性视图： 哪些由组件控制的影响在重启后存续，恢复是否将系统返回到可信状态？

对于每个架构视图，我们首先审查框架文档和API参考，以识别主要组件、接口和预期的安全行为。然后，我们检查相应的源代码、启动脚本和参考任务配置，以确定这些机制是如何实现的，机载应用程序可以使用哪些能力，以及限制在实践中是否得到实施，或者是否依赖于可信行为或任务特定配置 [60, 62, 58, 30, 91, 27]。我们将所得结果按照五个架构视图进行组织，并通过文档、实现和配置证据进行 corroborate。对结论至关重要的发现随后在第V节中进行测试。

IV-A 执行视图

在cFS中，组件通常实现为飞行应用程序（例如，camera_app.c）以及一组支持源文件，并在需要时包含硬件设备驱动程序。应用程序是执行和资源分配的主要单元。因此，执行视图决定了这些应用程序是如何创建、调度和授予系统资源访问权限的。核心飞行执行环境作为中央运行时环境，加载和协调独立开发的应用程序。

cFE提供五个核心服务：执行服务管理应用程序生命周期和执行状态；软件总线提供应用程序间消息传递；事件服务记录地面可见的应用程序事件；表服务管理动态加载的配置数据；时间服务维护和分发航天器时间。

为确定机载组件获得何种权限，我们检查其执行环境。具体来说，我们分析cFE如何创建应用程序，底层操作系统如何运行和隔离它们，以及它们可以访问哪些系统服务和资源。

(1) 实例化： 应用程序在启动时由ES通过启动脚本实例化，这些脚本指定要加载和执行的二进制文件。ES动态加载每个列出的二进制文件并创建一个对应的操作系统线程。此过程不执行加密验证、来源检查或权限分配。因此，任何引用的二进制文件都会自动作为可信系统组件执行。

(2) 执行： 一旦实例化，所有应用程序，包括核心服务，都在单个共享地址空间内作为操作系统级任务执行。cFS在组件之间不提供进程隔离、内存保护或权限分离。启动条目不提供执行边界强制机制。因此，核心服务及其管理的组件在相同的运行时条件下运行。

(3) 权限： 应用程序通过标准的cfe.h接口与cFE交互，该接口提供对消息传递、命令处理、事件报告和时间同步的访问，这是正常运行所必需的。此接口还暴露了特权的生命周期、配置和系统管理功能，使应用程序能够调用从常规消息传递到终止或重启其他组件的cFE服务，如表III所示。因此，所有应用程序都被授予对系统资源和应用程序生命周期的广泛系统范围权限，没有架构机制来强制执行最小权限或层级控制。

表 III：所有应用程序可访问的强大 cFE API 调用。

总之，这些机制将所有核心服务和任务应用程序置于单一执行域内。应用程序在无需完整性或来源检查的情况下加载，无需隔离地执行，并通过强制接口继承广泛的系统权限。因此，cFS在组件之间不提供有意义的内部信任边界。一旦实例化，每个应用程序都作为共享地址空间内的对等任务运行，并获得对系统服务和资源的广泛访问权限，没有在组件之间强制执行最小权限的有意义机制。

IV-B 身份视图

最小权限强制要求系统行为可归因于执行实体。因此，我们检查cFS如何分配和维护执行身份。

cFE内部的身份： 在启动时，ES初始化一个全局注册表，将每个应用程序及其对应的操作系统线程绑定到一个唯一的应用程序标识符。每个应用程序恰好与一个AppID关联，该AppID在ES中作为生命周期管理和控制的单元。此绑定可通过ES接口访问，并且在应用程序实例的生命周期内保持不变。因此，cFE维护一个集中且一致的内部身份。

cFE外部的身份： AppID不会传播到cFE之外。因此，应用程序间行为与执行身份解耦，允许任何应用程序在无身份限制的情况下发出命令、发布遥测数据或访问共享服务。尽管cFS在cFE内为每个应用程序分配了不同的AppID，但该身份不会在消息传递和共享服务交互中保留，从而阻止了可靠的认证、授权和归因。

IV-C 通信视图

系统协调依赖于跨组件和信任边界交换命令和遥测数据。因此，通信视图决定了交互是否经过认证、授权和可归因。

内部消息传递和设备访问： 软件总线在cFS中提供主要的通信基础设施，基于消息标识符在应用程序之间路由命令和遥测数据。正如其他工作所观察到的，SB仅执行最少的语法验证，不认证消息生产者、不授权发布或订阅，也不在通信应用程序之间强制执行信任关系 [64, 79, 80]。因此，任何能够发布语法有效消息的应用程序都可以影响订阅的组件或设备驱动程序。

由于软件总线不保留发送者身份，下游服务无法验证消息来源或强制执行发送者特定的授权。因此，软件总线将内部通信置于单一信任域内：它不是在组件之间限制权限，而是允许一个组件的权限通过合法的通信路径传播，并影响系统中其他不相关的部分。

外部消息传递： 先前的工作表明，不安全的cFS配置将外部命令验证集中在命令输入应用程序。一旦CI将命令转发到软件总线，架构就不提供通用机制来认证其来源或强制执行发送者特定的授权 [79, 80]。

尽管cFS有一个密码组件可以提供链路层认证和完整性保护，但它仅对明确路由的流量起作用，并且不绑定机载组件身份或强制执行通信策略。它也不扩展到软件总线的内部通信，仅围绕无线电接口运作。因此，它可以保护外部传输，但不提供内部保护。

这些机制在架构内的通信安全方面没有提供有意义的安全保障。因此，应用程序可以通过软件总线与组件、服务和设备通信，而无需发送者认证或可强制执行的策略检查，允许其权限在整个系统中传播。

IV-D 可观测性视图

部署后，操作员无法直接访问机载存储、内存和运行时状态。异常行为的检测和归因则主要依赖于下行的遥测数据和日志。cFS提供了三种主要的日志记录机制——系统日志、性能日志和事件日志——它们共同决定了组件活动是否可以被观察、归因和信任。

系统和性能日志： ES维护诊断和性能日志，记录来自调用应用程序的字符串消息和计时标记。这些日志是选择加入的，并捕获有限的诊断信息，例如应用程序何时启动和何时崩溃。它们不记录入侵指标，如应用程序间消息传递、设备访问或文件活动。此外，它们不会自动下行到操作员，并且可以通过暴露的接口清除。

事件日志： EVS维护一个事件日志，应用程序使用EVS函数填充该日志。与系统和性能日志不同，事件嵌入了发送者的AppID，继承了cFE更强的身份语义。与系统和性能日志不同，事件包含明确的AppID归因和事件元数据。EVS将事件存储在本地内存中，并自动将日志下行到操作员，提供了比ES日志记录更大的可见性。

与执行模型中授予应用程序的广泛权限一致，EVS暴露了可命令的过滤和抑制机制，允许根据任何应用程序定义的规则，在日志记录或传输之前选择性地丢弃事件。EVS接口还允许调用者在任意AppID下发出事件并擦除本地日志，进一步削弱了操作员所依赖的可见性和归因保证。

因此，由于日志记录是不完整的、由应用程序控制的，并且容易受到抑制、擦除和身份欺骗的影响，cFS不提供能够可靠检测和归因组件行为的强制审计跟踪。

IV-E 持久性视图

如果卫星受损，作为最后一道防线，操作员可以依赖重置来恢复已知良好状态。这些措施的有效性取决于重新初始化是否能够恢复可信基线。

cFS跨电源周期和处理器重置保留部署状态。存储在非易失性存储器中的启动脚本在启动时自动重放，导致所有列出的二进制文件在无操作员验证的情况下重新启动。如第IV-A节所示，ES还暴露了生命周期管理接口，例如CFE_ES_RestartApp()，允许应用程序以编程方式控制重启行为。

除了可执行文件的持久性，cFS还提供了一个关键数据存储，可用于跨重置保留应用程序内存。应用程序可以自由地通过ES接口注册、修改和恢复CDS块，允许内部应用程序状态无限期地持续存在。

这些机制削弱了基于重置的恢复，因为cFS可能会在无独立验证的情况下重新加载受损的代码、配置或CDS状态。因此，重启无法保证恢复到已知良好状态。

图 3： 架构分析维度以及在执行、身份、通信、可观测性和持久性方面削弱内部信任边界的重复属性。

跨视图发现。 基于我们的分析，cFS将机载应用程序置于共享信任域内。应用程序以难以归因的广泛权限执行。如图3所示，这些弱点相互加强：受损的应用程序可以使用合法接口影响无关组件、掩盖其行为并在重启后恢复操作。因此，由此产生的风险是架构性的，源于机载应用程序将按预期正确行为的假设。

V 架构预测的实验验证

图 4： 从攻击者立足点到cFS机制、架构弱点和已证明影响的实验验证路径。每行显示受损应用程序如何使用合法框架机制产生超出其预期任务角色的影响。

前面的分析根据cFS文档、源代码和参考配置，识别了机载应用程序可用的能力和控制路径。然而，仅凭静态证据并不能确定这些能力在集成的飞行环境中是否仍然可用，因为任务配置、运行时检查、所有权规则或接收方验证可能会施加额外限制。因此，我们实验性地测试已识别的弱点在实践中是否仍然可利用。

V-A 实验平台

我们使用NASA的NOS3来评估cFS，这是一个通过NASA的GitHub仓库公开发布的具有飞行代表性的虚拟航天器环境 [63]。NOS3将飞行软件和地面站与航天器硬件的软件模型（包括无线电、推进器、电源系统、摄像头和导航传感器）集成在一起。尽管这些模型替换了物理设备，但NOS3保留了与我们分析相关的软件架构、应用程序权限、消息接口和信任关系，使我们能够测试已识别的弱点是否仍然可跨组件和设备边界利用。

V-B 方法

在第三节的威胁模型下，我们实现了一个正常集成的cFS应用程序，该应用程序仅使用文档化的接口和现有应用程序权限，执行五种代表性的信任滥用原语。每个原语为实验控制而进行命令激活，具有定义的技术目标和可观察的成功条件。当应用程序在其预期角色之外产生指定的效果，且不修改目标或框架，也不获取额外权限时，实验即成功。

我们还评估了默认NOS3配置中18个运行组件的暴露广度，涵盖成像、传感、导航、通信、安全和机载数据处理。对于每个组件，我们确定其正常接口或资源是否满足一个或多个已验证原语的前提条件。我们使用系统日志、遥测数据、命令响应、应用程序状态以及偏离正常组件行为的偏差来验证执行和目标影响。

V-C 实验

图4总结了五个实验，每个实验测试一个正常集成的应用程序是否能够影响其预期角色之外的资源。

(1) 对等生命周期覆盖。 攻击者试图中断任务运行或禁用可能干扰恶意活动的组件。我们的实验应用程序使用执行服务删除、重启和重新加载一个不相关的任务应用程序。遥测数据、ES状态和预期输出确认了状态变化。由于该应用程序既不拥有也不监督目标，且无需额外权限，该实验证明了通过合法接口进行跨应用程序生命周期控制。

(2) 发送者身份不连续性。 攻击者试图冒充可信应用程序或隐藏行为来源。在一种模式下，应用程序传输一个具有任意消息ID、功能代码和有效载荷的命令，而接收方未收到经过认证的发送者身份。在另一种模式下，它使用另一个应用程序的AppID发出归因于该应用程序的遥测事件。因此，数据包元数据和AppID不能可靠地识别发起应用程序。

(3) 未经授权的命令传播。 攻击者试图操纵受损应用程序任务角色之外的航天器或设备状态。实验应用程序通过软件总线发布了一个针对不相关设备的有效命令，该总线接受了该命令并改变了状态。这证实了授权依赖于数据包格式和路由，而非经过认证的发送者身份或应用程序特定的权限。

(4) 操作员视图等价性。 攻击者试图执行未经授权的操作而不暴露其发起应用程序。我们比较了由预期控制器和实验应用程序发出的相同设备命令。两者产生了相同的可观察效果，而可用的EVS、ES、性能、遥测、软件总线、命令响应和地面站数据并未可靠地区分它们的来源。实验应用程序还可以通过抑制、更改或为事件报告分配误导性身份来进一步掩盖归因。

(5) 重置后的入侵重放。 攻击者试图在无需额外外部命令的情况下，跨处理器重置保持恶意影响。实验应用程序存储了攻击者控制的状态，用它来改变运行时行为，并发出处理器重置。重启后，它恢复了该状态，并在无需进一步攻击者输入的情况下自动恢复了被改变的行为。这证明了组件控制的持久状态可以在正常初始化期间重新激活受损行为。

V-D 验证结果

所有五种原语在作为正常集成的cFS应用程序运行时，都产生了其预测的安全相关影响，证实了静态分析识别的能力在集成飞行配置中仍然可达。一旦应用程序受损，合法的框架机制就被用来将其影响扩展到预期的组件边界之外。

在18个运行组件中，每个应用程序都至少易受一种评估攻击的影响（表IV）。并非每种原语都适用于每个组件：有些应用程序不控制相关设备，或者缺少特定攻击所需的接口或资源。在这些情况下，缺少可利用路径反映了组件的功能，而非架构安全边界。当必要的攻击面存在时，相应的原语就会成功。我们并不声称每个组件都支持每种原语，或者所有任务配置都暴露相同的路径。相反，我们发现执行不同任务功能的组件依赖于相同的共享架构假设，使得当相应的前提条件存在时，基于信任的攻击成为可能。

表 IV：跨飞行组件的系统性架构信任暴露。
至少受一种攻击类别影响的组件。
ArduCam, CryptoLib, ADCS, CSS, EPS, FSS, IMU, MAG, PiCam
Radio, RW, ST, Thruster, Torquer, MGR, GNSS, OnAIR, SYN

VI 普适性

为确定类似的架构问题是否可泛化到不同的模块化框架，我们检查了另外四个开源飞行软件项目。对于每个项目，我们评估软件组件如何实例化、通信、建立身份，以及架构是否为最小权限和隔离提供了可强制执行的机制。此比较侧重于文档化的架构属性，辅以有针对性的源代码检查，而非对每个框架进行完整的源代码级审计。

表 V：评估的飞行软件框架中重复出现的架构弱点。“是”表示该弱点存在；“部分”表示部分或依赖于部署的缓解措施。

VI-A F Prime

F Prime (F´) 是一个基于组件的飞行软件框架，其中软件组件通过作为系统架构一部分定义的强类型通信端口进行连接 [57, 17]。这些连接通常在构建飞行软件时固定。组件可以通过直接调用另一个组件或将请求放入队列以供稍后执行来进行通信，具体取决于通信端口的类型 [16, 17]。

VI-A1 架构信任评估

• 执行： 组件可以使用独立的线程和队列，但一个部署内的组件通常共享相同的进程、内存和操作系统权限 [17, 18, 20]。强隔离需要单独的部署和外部强制执行的进程或平台边界 [18]。

• 身份： F´ 为组件分配标识符以连接它们和路由消息，但这些标识符并不安全地验证哪个组件执行了某个动作 [19, 21, 17]。当多个组件在同一进程中运行时，系统通常可以识别负责的进程，但无法可靠地将行为归因于特定组件 [18, 20]。

• 通信： 类型化端口和拓扑连接限制了预期的通信，而命令操作码通过命令调度器路由 [17, 21]。所审查的框架在其标准通信协议中未提供强制性的每次调用授权、认证的组件通道或加密保护 [18, 20, 25]。

• 可观测性： F´ 提供事件、遥测、命令响应、健康监控和可配置事件过滤 [22]。然而，它没有文档记录强制性的防篡改审计跟踪或不可伪造的组件归因 [22, 18]。

• F´ 持久性： F´ 重新加载明确保存到其参数数据库的参数值，并检查上传文件的完整性，但全系统验证和恢复到已知良好软件状态由部署平台负责 [24, 23]。

重复出现的弱点。 与cFS类似，F´ 通常缺乏同一部署中组件之间的强隔离、组件行为的认证归因、服务边界的强制授权、受保护的审计以及框架级的已知良好状态恢复。

VI-B KubOS

KubOS是一个基于Linux的飞行平台，其中任务应用程序和服务作为独立进程运行。服务在构建时选择，应用程序直接运行或通过调度服务运行。组件主要通过GraphQL over HTTP进行通信，而通信框架则在内部路由地面发起的GraphQL和UDP流量 [41, 42, 37, 36]。

VI-B1 架构信任评估

• 执行： 应用程序作为独立的Linux进程运行，但最小权限控制和独占的、服务中介的设备访问是依赖于部署的 [41, 40, 39, 44]。

• KubOS 身份： KubOS为进程分配操作系统身份，包括进程ID和用户ID，但其文档化的服务接口不会在请求间保留该身份，限制了共享服务的可靠归因和基于身份的授权 [47, 37, 38]。

• 通信： 配置、GraphQL模式和包路由调节通信，但未文档化强制认证、授权、消息完整性和重放保护 [37, 38, 36]。

• 可观测性： KubOS集中日志、监控和遥测，但未文档化可信调用者归因或防篡改审计 [45, 47, 46, 48]。

• KubOS 持久性： KubOS检测启动失败和内核损坏，并可恢复当前、先前或基础操作系统映像；然而，其用户数据分区在恢复后仍然存在，因此用户控制的文件和配置不一定会返回到已知良好状态 [43, 49, 37]。

重复出现的弱点。 KubOS提供了比cFS更强的进程分离，但仍存在缺乏保留的调用者身份、强制服务授权、防篡改审计以及安全相关持久状态的完整恢复等问题。

VI-C NanoSat MO 框架

NanoSat MO框架将飞行功能部署为独立的应用程序，每个应用程序在其自己的操作系统进程中执行。应用程序通过共享的Supervisor访问平台、监控、归档、发现和软件管理服务，并且也可以相互提供服务。已安装的应用程序集定义了部署，而Apps Launcher则启动和管理每个进程 [5, 12, 15]。

VI-C1 架构信任评估

• 执行： 应用程序在单独的进程中运行，可以选择在不同的用户下运行，但沙盒和资源限制不是强制性的 [15, 6]。

• NMF 身份： NMF可以在配置的操作系统用户下启动应用程序，并将每个应用程序注册为命名服务提供者，但所审查的文档并未确定此身份在服务请求间得到认证和保留 [6, 12, 5]。

• 通信： 应用程序通过NanoSat MO连接器和目录访问服务，但未文档化强制授权、发送者认证和消息完整性 [12, 5]。

• NMF 可观测性： NMF Supervisor将应用程序输出与启动的应用程序关联，并且某些服务操作存储在一个中央归档中，提供了有用的操作可见性，但未建立所有组件行为的完整、防篡改记录 [15, 13, 14]。

• 持久性： 应用程序包和归档状态在重启后持续存在，而未文档化签名强制、验证启动、回滚保护和已知良好恢复 [11, 15, 6]。

重复出现的弱点。 NMF提供了进程级分离，但像cFS一样，未建立强制限制、跨服务请求的认证归因、授权强制、受保护的审计或可信恢复。

VI-D CORDET-C2

CORDET-C2是一个基于C的面向服务的飞行软件框架，其中应用程序通过框架定义的接口交换命令和报告。一个系统可以由多个运行在同一或不同计算机上并通过外部中间件通信的CORDET应用程序组成 [70, 69]。

VI-D1 架构信任评估

• 执行： CORDET组件是由调度器调用的被动对象。在单个CORDET应用程序内，组件共享执行环境，未文档化组件级隔离 [70, 第22.1节]。

• 身份： 组件和包使用数字标识符进行路由和管理，但这些是逻辑标识符而非认证身份 [70, 第6.2和10.1.3节]。

• 通信： CORDET仲裁命令和报告，并执行框架定义的生命周期和接受检查，而包表示和额外的完整性检查由应用程序定义。发送者认证、访问控制列表和加密完整性未被文档化为框架级机制 [70, 第10和16节][70, 第9和16节]。

• 可观测性： 注册表和错误/状态报告提供了操作可见性；任务实现可能添加事件和FDIR机制，但受保护的归因和防篡改审计未被文档化为框架级机制 [70, 第15, 20和23节][3, 68]。

• CORDET-C2 持久性： CORDET-C2主要维护易失性的命令和报告状态，并将应用程序重置行为委托给任务特定代码，因此可执行软件、配置和持久任务状态的可信恢复在框架的保证之外 [70]。

重复出现的弱点。 CORDET-C2在共享执行环境、逻辑而非认证身份、缺乏强制授权、未受保护的运营记录以及由应用程序定义的恢复方面，与cFS非常相似。

VI-E 总结

在cFS、F´、KubOS、NMF和CORDET-C2中，组件化并不保证强安全隔离。共享进程框架缺乏组件级边界，而基于进程的框架则依赖于部署特定的权限和限制控制。在这两种模型中，标识符、通信检查、日志记录和持久性机制支持运行，但通常不提供认证身份、强制授权、可信归因或保证恢复到已知良好状态。因此，当这些控制由框架或协议一致地强制执行，而非委托给单个应用程序时，它们会更加健壮，这与Saltzer和Schroeder的最小权限和完全仲裁原则一致 [78]。

VII 讨论

我们的分析识别了飞行软件架构中重复出现的弱点，这些架构假设组件将按照其预期角色行事。先前的工作已引入了重要的安全改进，包括认证通信、操作系统级隔离、基于能力（Capability）的访问控制、受保护的日志记录、安全启动和认证更新。这些机制解决了攻击面的特定部分，但它们并未共同约束受损机载组件在框架服务、组件间通信、硬件接口和持久状态方面的权限。我们的发现指出了这些保护措施仍不完整的方面，并为扩展和整合现有防御措施提供了架构基础。

图 5： 推荐的安架构，其中认证身份和策略强制将组件与核心软件服务隔离，而经过验证的审计和可信恢复检测误用并在必要时恢复系统。

VII-A 架构修复

认证身份和策略强制。 现有机制保护通信链路和消息来源 [10]，但并未始终如一地将内部操作绑定到发起它的应用程序。在这些机制的基础上，飞行软件框架应在消息、服务、硬件访问和持久状态更改中保留认证的应用程序身份，然后基于该身份强制执行授权策略。

隔离和受限权限。 先前的工作已展示了操作系统级分区和基于能力的访问控制 [93, 28, 8]，提供了可以构成更强组件隔离基础的机制。我们的发现表明，隔离还必须限制应用程序对飞行软件资源的特定权限。因此，框架应将隔离与不同的凭证、资源限制、窄接口以及限于每个组件所需消息、服务、设备和持久对象的能力相结合。

防篡改的可问责性。 先前的工作支持受保护的日志记录和基于遥测的异常检测 [1, 88, 26]，但这些机制不一定为跨越飞行软件架构的安全敏感操作提供强制归因。框架应在框架、调度器、通信和硬件访问边界处扩展这些方法，设置可信审计点，以在防篡改日志中记录经过认证的请求者、资源、操作和结果。

可信恢复和受保护状态。 先前的工作展示了安全启动、认证更新、回滚和数据恢复 [1, 87, 50, 94]，建立了恢复软件完整性的重要机制。我们的发现表明，恢复还必须考虑由受损组件控制的安全相关持久状态。因此，框架应从独立可信的基线恢复，该基站在恢复正常运行前验证安全相关软件和持久状态。

总之，这些建议并未取代现有的飞行软件安全机制；它们展示了如何扩展和整合先前的方法，以解决我们分析中暴露的架构弱点。现有工作提供了许多必要的构建模块，但这些机制必须作为连贯架构的一部分运行，该架构跨系统边界约束组件权限。开发、测试和认证仍然是必要的，但它们不应成为防止组件超出其预期角色的唯一保障措施。飞行软件架构本身应限制未经授权的行为，保留可靠的违规证据，保护安全相关状态，并提供可信的恢复路径。

VII-B 局限性

建构效度。 本工作对cFS的评估比其他框架更深入。跨框架比较依赖于已发布的文档、API参考、维护的仓库和有针对性的源代码检查，而非等效的实验或全面的源代码审计。因此，文档质量和分析深度的差异可能影响比较的一致性。未文档化的任务特定控制也可能提供比此处识别的更强的边界。

外部效度。 实验是在NOS3中进行的，它保留了cFS应用程序模型、软件总线交互和相关API，但并未重现运行中航天器的每个处理器、时序、硬件保护、通信或恢复属性。威胁模型进一步假设恶意代码已进入集成组件。因此，结果表征了在评估环境中的入侵后能力和遏制效果，而非初始入侵的可能性或机制。

VIII 结论

我们的结果表明，许多先前识别的飞行软件弱点是一种共同底层属性的表现：架构隐式地建立信任，并且在组件开始执行后，提供很少的机制来强制、限制或撤销信任。通过在执行、身份、通信、可观测性和持久性方面对信任进行建模，我们提供了一个系统框架来推理这些行为及其安全后果。有意义的安全不能仅通过增量式加固来实现。安全关键的保证应由架构自身强制执行，而不是委托给单个实现或通过任务特定补丁事后添加。随着卫星继续支持通信、导航和国防的关键基础设施，建立安全的-by-construction飞行软件架构已不再是可选项。我们希望这项工作能促使对下一代空间系统中信任、治理和安全进行更广泛的重新评估