国防场景下的Android设备从硬件选型到系统镜像都会经历与消费级产品完全不同的验证流程。普通商用测试通常以用户体验和功能实现为核心，而国防测试要求的是在对抗性环境下依然保持可用性、机密性和完整性。下面从威胁模型、启动链、数据链路、外设管理和自动化测试几个层面展开说明。
国防测试与商用Android测试的核心差异
不能简单把CTS或GMS认证通过当作国防测试的入场券。CTS验证的是Android框架兼容性，GMS验证谷歌服务可用性，两者都没有覆盖敌手模型下的持久化攻击、物理内存提取或供应链植入。国防测试中，测试人员需要假设攻击者可以物理接触设备、可以拦截无线电信号、也可能在制造或运输环节替换关键固件。
因此，测试用例会围绕信任根展开，而不是围绕应用功能展开。例如需要验证bootloader是否锁定、AVB（Android Verified Boot）是否启用了防回滚保护、SELinux是否保持enforcing状态、调试接口是否被彻底关闭。一个容易忽略的差异是：商用测试允许设备在失败后重启恢复，但国防设备在一次启动链校验失败后必须进入安全失败状态，不能继续加载未验证镜像。
合规要求也更为严格。设备可能需要通过Common Criteria评估、NIAP保护配置文件或者遵循DISA STIG中针对移动设备的加固条目。测试报告需要记录每一次配置变更和测试证据，后续审计时会逐条核对，而不是只看最终通过率。
启动链完整性与密钥管理验证
启动链是所有验证工作的起点。测试时先确认设备处于锁定状态，执行 adb shell getprop ro.boot.verifiedbootstate 应返回绿色状态。如果返回orange或yellow，说明设备引导了未锁定或未完全验证的镜像，属于一票否决项。还需要检查dm-verity是否对系统分区启用，以及AVB版本是否支持防回滚索引。
# 检查启动校验状态与AVB锁定情况 adb shell getprop ro.boot.verifiedbootstate adb shell getprop ro.boot.vbmeta.device_state # 查看dm-verity相关内核命令行参数 adb shell cat /proc/cmdline | grep -E 'dm_verity|androidboot.verifiedbootstate'
加密和密钥管理方面，不能只测试锁屏密码是否生效。国防设备通常要求所有用户数据分区全盘加密或文件级加密，并且密钥必须存储在独立安全硬件中，例如StrongBox或专用安全芯片。测试需要验证KeyStore中的密钥是否真的由安全硬件保护，而不是仅存在于TEE之外。可以通过KeyStore API写入一个测试密钥，再尝试从应用层直接读取密钥材料，确认无法导出。
此外，通信链路的加密策略也要逐项验证。需要检查系统是否允许TLS 1.0或弱密码套件，VPN配置是否强制使用IKEv2/IPsec等协议。测试中可以使用 adb shell settings list secure 查看安全设置，结合抓包分析确认应用流量不会回退到明文。
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
KeyGenParameterSpec spec = new KeyGenParameterSpec.Builder(
"defense_key",
KeyProperties.PURPOSE_ENCRYPT | KeyProperties.PURPOSE_DECRYPT)
.setBlockModes(KeyProperties.BLOCK_MODE_GCM)
.setEncryptionPaddings(KeyProperties.ENCRYPTION_PADDING_NONE)
.setUserAuthenticationRequired(true)
.setIsStrongBoxBacked(true) // 强制由StrongBox安全芯片保护
.build();
KeyGenerator generator = KeyGenerator.getInstance(
KeyProperties.KEY_ALGORITHM_AES, "AndroidKeyStore");
generator.init(spec);
generator.generateKey();
外设隔离、数据销毁与渗透测试
物理接口是国防设备最容易出问题的攻击面。测试中要模拟攻击者通过USB、串口、JTAG或调试接口获取控制权。首先要确认生产版本中ADB默认关闭，并且连接主机后需要用户确认授权。可以通过读取系统属性与USB配置项判断是否残留调试通道。对于高安全等级设备，还需要验证USB配置是否只允许充电模式，数据通路被内核策略阻断。
# 查看当前USB配置与ADB状态 adb shell getprop sys.usb.config adb shell getprop persist.sys.usb.config adb shell settings get global adb_enabled # 若为高安全配置，应输出none或charging，且adb_enabled为0
数据销毁测试关注设备丢失或被缴获后，敏感数据能否被快速且不可恢复地清除。测试中需要触发远程擦除或本地多次失败解锁后的擦除策略，验证擦除操作不仅删除文件系统元数据，还执行底层存储的丢弃指令。可以使用 fstrim 或 blkdiscard 观察存储设备是否真正释放块，防止通过闪存芯片直接读取残留数据。
渗透测试环节则需要结合自动化工具和人工分析。使用MobSF或Drozer对预置应用进行静态与动态分析，寻找可被利用的导出组件、权限提升路径和WebView漏洞。还要检查系统是否允许安装未知来源应用，以及是否禁用了开发者选项中的备份功能，因为ADB备份有时会成为数据提取的捷径。
自动化测试框架与CI集成
手工测试无法保证每次构建都覆盖所有国防级检查项，所以需要把关键验证脚本嵌入CI流水线。测试脚本可以基于Python调用ADB命令，将返回结果与基线值比对，任何偏离都直接标记为构建失败。比如检查SELinux状态、启动校验状态、加密策略和调试接口开关。
import subprocess
def adb_getprop(prop):
result = subprocess.run(
["adb", "shell", "getprop", prop],
capture_output=True,
text=True
)
return result.stdout.strip()
checks = {
"ro.boot.verifiedbootstate": "green",
"ro.build.selinux": "1",
"ro.crypto.state": "encrypted",
}
def run_security_baseline():
failures = []
for prop, expected in checks.items():
actual = adb_getprop(prop)
if actual != expected:
failures.append(f"{prop}: expected {expected}, got {actual}")
if adb_getprop("sys.usb.config") not in ("none", "charging"):
failures.append("USB data channel is not disabled")
return failures
if __name__ == "__main__":
failed = run_security_baseline()
if failed:
print("Security baseline failed:")
for item in failed:
print(item)
exit(1)
print("All security baseline checks passed.")
CI中的测试结果需要自动归档到审计系统，并关联具体镜像版本号和构建时间。这样即使数月后发现问题，也能快速定位到哪些设备受到影响。测试脚本本身也要纳入版本管理，避免因为测试环境变更导致结果不可复现。
落地时常见误区是把安全测试集中在发布前一个月进行。国防项目周期长，但每次内核改动、供应商镜像更新或策略变化都可能重新引入风险。建议把基线检查作为每日构建的门禁，渗透测试作为里程碑节点，而完整的合规评估在版本冻结后集中执行。
最终要清楚一点：国防测试不是一个一次性交付物，而是从设计阶段延伸到设备退役的持续过程。只有把启动链验证、密钥管理、接口隔离、数据销毁和自动化审计串起来，测试结果才具备真正的工程价值。
Android安全测试国防级设备系统完整性校验修改时间：2026-09-22 04:57:44