Core ML 模型包安全边界：从内置到动态下载的验证缺口与加固判断

内置模型与动态下载的边界选择

内置模型跟随应用包分发时，其安全属性完全继承应用签名和包完整性保护机制。攻击者若能从设备提取应用包或利用越狱文件系统权限，即可获得完整模型文件。因此，内置模型只是将暴露风险延迟到安装之后，并没有独立的密钥控制或摘要验证能力来隔离模型资产。

动态下载模型消除了应用包体尺寸的瓶颈，允许独立于应用版本进行迭代。然而下载流程基于 URLSession 完成，本身没有强制要求响应体必须携带数字签名。文档指出编译由系统处理，但未声明下载阶段对 manifest 或证书固定存在依赖，这留下了中间人替换的风险窗口。

决策时需权衡具体场景：内置便于离线场景且编译不会因弱网环境而失败，但更新需整包发布；动态下载允许独立更新模型，但需要额外实施来源认证。两者必须分别确定静态存储与网络传输两个阶段的最低保护要求，不能混为一谈。

对于高敏感业务，内置模型应视为公开资产，仅依靠应用签名不足以防止逆向分析。动态模型则必须在网络层和应用层双重加固，否则下载过程等同于明文传输。工程上应根据数据敏感度决定模型交付形态，而非单纯追求包体优化。

• 是否明确内置模型在越狱环境下的不可保护性？
• 动态下载是否实施了域名证书固定或公钥锁定？
• 是否在编译前对响应体进行了独立的完整性校验？
• 是否对下载失败或校验失败的模型阻断了回退路径？

动态下载模型的前置安全条件

动态下载模型的入口是网络请求，这是整个链条中最脆弱的环节。若应用未对模型下载的域名实施证书固定，仅依赖系统信任库，则攻击者可通过中间人替换整个模型文件，进而控制预测流程。这并非 Core ML 的缺陷，而是网络层未提供对象级别验证时的通用问题。

根据官方文档描述，下载完成后系统会调用编译步骤。但该编译依赖文件头格式合格，不要求文件与开发者预期的摘要一致。于是恶意模型只要结构合法就能被加载并执行推断，给任意代码执行留下潜在突破点，因为模型结构可能包含恶意构造的计算图。

动态下载链路可先限制允许来源，再在使用缓存前验证内容摘要或独立签名，并把编译产物与可信 manifest 对照。具体项目可按现有信任根选择校验组合；当身份或摘要无法确认时，加载流程应进入明确的失败或回退分支。

此外，必须验证响应头的 Content-Length 与实际接收字节数是否一致，防止截断攻击。如果服务器支持范围请求，还需确保分段下载的拼接完整性。任何网络层面的异常都应触发重试或报错，而不是静默使用部分损坏的模型文件。

• 是否固定模型下载域名的证书或公钥以防止中间人攻击？
• 是否在编译前校验响应的 Content-Length 与实际大小一致？
• 是否在编译完成后比对产物摘要与期望值以确认未被篡改？
• 是否对下载失败或校验失败模型阻断回退路径避免使用旧版？

编译缓存与产物完整性的验证

Core ML 将下载或内置的 .mlmodel 编译为 .mlmodelc 目录，后续推理会使用其中的模型描述、权重和元数据。若本地编译缓存可被替换，而应用又不校验其来源与摘要，源模型阶段的检查就无法覆盖这一后续文件，因此缓存目录也应纳入完整性验证。

核对编译产物的手段是计算目录内容摘要并与可信 manifest 比对。但编译缓存的设计允许系统在不同时机重新编译，导致摘要可能合法变化。因此，必须确保一致性检查对象是可复现的特定文件，例如 mil 文件或编译后的 weight.bin，而非整个目录。

Apple Core ML 文档未提供编译产物摘要标准接口，开发者需自行选择稳定输入集。工程可锁定模型编译输出中的特定文件名与字节序，排除索引缓存、浮动临时文件。失败条件包括：摘要比对后短时间窗口内又被替换、或构建环境不同导致差异。

验证逻辑必须在模型加载前执行，且运行在受保护的上下文中。如果验证过程本身可被 Hook 或绕过，则整个机制失效。建议在 native 层实现哈希计算，并对比存储在只读区域或远程签名的期望值，减少内存中被篡改的风险。

import hashlib
import json
import os
import sys
import argparse

def hash_file(file_path, algo='sha256'):
    h = hashlib.new(algo)
    with open(file_path, 'rb') as f:
        while True:
            chunk = f.read(8192)
            if not chunk:
                break
            h.update(chunk)
    return h.hexdigest()

def load_manifest(manifest_path):
    if not os.path.isfile(manifest_path):
        print(f"错误：Manifest 文件不存在：{manifest_path}", file=sys.stderr)
        sys.exit(2)
    with open(manifest_path, 'r', encoding='utf-8') as mf:
        return json.load(mf)

def check_compiled(manifest_path, compiled_dir, algo='sha256'):
    manifest = load_manifest(manifest_path)
    errors = []
    for entry in manifest.get('models', []):
        name = entry.get('name')
        expected = entry.get('sha256')
        if not name or not expected:
            errors.append(f"跳过条目，缺少 name 或 sha256: {entry}")
            continue
        target_file = os.path.join(compiled_dir, f"{name}.mlmodelc", "model.mil")
        if not os.path.isfile(target_file):
            errors.append(f"缺失候选文件：{target_file}")
            continue
        actual = hash_file(target_file, algo)
        if actual != expected:
            errors.append(f"摘要不匹配 {name}: 期望 {expected}, 实际 {actual}")
    if errors:
        for e in errors:
            print(e, file=sys.stderr)
        sys.exit(1)
    else:
        print("所有模型摘要核验通过")

if __name__ == '__main__':
    parser = argparse.ArgumentParser(description='校验 Core ML 编译产物完整性')
    parser.add_argument('--manifest', required=True, help='模型 manifest JSON 路径')
    parser.add_argument('--compiled-dir', required=True, help='编译产物父目录')
    args = parser.parse_args()
    check_compiled(args.manifest, args.compiled_dir)

模型签名与版本授权

本文所引 Apple 资料没有给出与 App 代码签名等同的模型作者验证链。模型来源认证通常由应用的下载、更新或资源封装流程承担，因此需要明确期望签名者、可信公钥和失败处理，不能假设操作系统会替业务完成这些检查。

版本授权重点在于防止回滚攻击：攻击者提供旧版本模型以利用已知的弱推断或后门。TUF 规范要求在元数据中声明版本号、过期时间与私钥轮转机制，从而使客户端能拒止过旧或过期的模型。但该机制依赖每次启动时的在线查询或本地可信时钟。

在移动环境，必须将版本元数据嵌入 manifest 并让客户端在编译前校验版本单调递增或符合最小允许集。若仅由服务端下发版本号而客户端不执行本地单调递增判断，则攻击者可通过重放旧响应完成版本级降级，绕过最新的安全补丁。

实施版本控制时，需在本地持久化当前最高版本号，并在每次更新时严格比较。如果新版本号小于或等于本地记录，应拒绝加载。同时，manifest 本身必须签名，防止攻击者修改版本号字段来欺骗客户端接受旧模型。

• manifest 文件是否包含数字签名以保护版本信息？
• 客户端是否本地存储并校验版本号的单调递增性？
• 是否设置了元数据的过期时间以防止长期重放？
• 是否在离线模式下限制了可接受的最低模型版本？

Core ML 加密的保护强度与运行时可见性

根据官方文档，开发者可为模型归档或编译产物生成加密密钥，模型在使用前需要对应的解密密钥。这主要提高了静态存储和传输的安全门槛，防止直接二进制拷贝后解析。但这仅仅是增加了静态分析的难度，并非绝对防御。

但是，模型在被 Core ML 框架解密并加载后，其权重和计算图必须存在于进程地址空间。具备 root 或相同沙盒授权的调试工具、动态注入手段以及模型调优工具都可能通过内存扫描或框架接口读取部分或全部结构，这是物理执行的必然结果。

因此，加密提供的保护边界止于授权执行之前。对于需要保护商业模型机密或合规数据的场景，必须在授权分发、设备完整性认证和运行时反调试等多个层面叠加控制，不能假设加密能消除推理阶段后的全部信息泄露风险。

密钥管理同样关键，硬编码在代码中的密钥极易被逆向提取。应利用硬件安全模块或系统密钥链存储密钥，并结合设备指纹进行绑定。即便如此，一旦设备被攻破，内存_dump_依然可能暴露解密后的模型参数。

• 密钥是否与设备或用户绑定，或者关联到硬件密钥管理器？
• 模型解密后在内存中是否避免持久化明文权重？
• 是否有反调试和完整性检查防止动态提取？
• 加密是否仅保护归档文件，编译缓存是否得以豁免？

模型 manifest 与摘要核对的失败条件

manifest 是信任根基，其内容决定编译后产物应具备的摘要。如果 manifest 自身未经签名或传递过程未受保护，则攻击者可修改 manifest 同时替换模型文件，使摘要比对失效。因此 manifest 的完整性校验优先级高于模型文件本身。

in-toto 声明把产物摘要放进带类型的声明负载，并由签名者发布。映射到模型分发时，manifest 除摘要外还要能追溯签名者与适用版本；客户端验证的是签名和当前模型是否匹配，声明格式本身并不保证内容真实。

在核对流程中，失败条件需要区分：文件缺失（模型未下载或编译失败）、摘要不匹配（文件内容变化）、manifest 签名无效（信任源被破坏）。每个条件应触发不同阻断策略而非统一退回默认模型，否则可能被攻击者诱导使用低强度后备方案。

特别是当检测到摘要不匹配时，应立即清除本地缓存并终止进程，防止恶意模型被执行。如果是网络导致的文件缺失，可尝试重试，但必须有次数限制。任何涉及信任根失效的情况，都应视为严重安全事件并上报。

更新框架与回滚防护在移动侧的适用边界

TUF 的设计解决分发网络中混搭、冻结和回滚攻击，但其默认实现面向软件包管理器，未必直接适用移动端模型更新。移动场景下，元数据尺寸、更新频率和网络中断容忍度都有差异，必须裁剪以适应移动网络的波动特性。

在移动应用中，至少需要实施：元数据签名校验、版本单调递增检查、快照过期以及可信时间戳。如果应用仅比对本地缓存的最后版本号，攻击者可通过重放旧版本元数据配合旧模型实现降级，绕过新版本的修复逻辑。

应用长期离线时，版本过期和更新检查会受本地时间及网络状态影响。项目可在客户端保留最低可接受版本，并由服务端在恢复联网后复核；旧模型是降级运行还是拒绝使用，应由业务风险与可用性要求共同决定。

此外，需考虑密钥轮转机制。长期使用同一密钥签名会增加泄露风险，一旦密钥泄露，攻击者可签署任意恶意更新。因此，manifest 应包含密钥有效期，并支持平滑过渡到新密钥，确保旧密钥失效后无法再用于签名。

• 更新元数据是否包含签名且与可信根关联？
• 是否检查元数据内版本号较本地递增？
• 快照元数据是否有过期时间且客户端能验证？
• 是否具备设备时间被篡改时的备份判断？

供应链证明与模型资产可追溯

in-toto 声明格式允许将模型训练数据、依赖版本、编译环境等构建流程信息与制品摘要绑定，帮助识别供应链污染点。然而声明本身是数据对象，其真实性必须由签名和分布式门禁保证，否则只是一份普通的文本记录。

如果客户端只能读取声明字段，却无法核验签名链与发布者身份，这份记录只能作为普通元数据，不能直接参与访问控制。应用启动时应先验证发布者密钥和声明签名，再把其中的模型摘要、版本与本地文件逐项比对。

采用证明机制时，必须将信任边界清晰划定：声明内容说明“某环境产出了某摘要的模型”，但并不能说明“本地编译产物一定来自该环境”。仍需如同本章前述，对本地产物实施独立的摘要比对并与声明中的期望值校验，形成双重确认。

供应链证明的价值在于事后审计和溯源，而非实时的访问控制。在实时场景中，仍应依赖本地的密码学校验。只有当本地校验通过且声明验证无误时，才能确信模型资产的完整性和来源可靠性，缺一不可。

• 是否验证了供应链声明的数字签名有效性？
• 声明中的制品摘要是否与本地文件实际摘要一致？
• 是否确认了声明发布者的身份可信且证书未吊销？
• 是否将供应链证明作为辅助手段而非唯一信任依据？