# NFC 协议中 PKO 与 Relay 攻击的技术分析与防御策略 > 深入分析 MIFARE Ultralight 系列芯片在 3DES/AES 保护下的密钥空间缩减攻击，揭示 Relay 攻击与 Partial Key Overwrite 的技术原理及实操参数。 ## 元数据 - 路径: /posts/2026/01/30/nfc-pko-relay-attacks-3des-aes/ - 发布时间: 2026-01-30T01:31:21+08:00 - 分类: [security](/categories/security/) - 站点: https://blog.hotdry.top ## 正文 当我们从一张全新的 MIFARE Ultralight C 芯片中读取其 16 字节 3DES 密钥时，会得到一个颇具挑衅意味的字符串：`BREAKMEIFYOUCAN!`。这并非安全研究者的恶作剧，而是 NXP 工程师在 2008 年刻入每一片芯片的默认密钥。正是这个充满挑战意味的默认配置，催生了名为「BREAKMEIFYOUCAN」的安全研究项目，其核心发现是：攻击者可以通过 Relay 攻击与 Partial Key Overwrite（PKO，部分密钥覆盖）技术，将原本理论上需要 $2^{112}$ 次运算才能暴力破解的密钥，缩减至仅需 $2^{28}$ 次——后者在普通硬件上可在数分钟内完成。 ## 受影响的技术生态与攻击面 这项研究覆盖了当前部署最广泛的低成本 NFC 智能卡技术，包括 MIFARE Ultralight C（MFOICU2）、MIFARE Ultralight AES（MFOAES）以及 NTAG 223 DNA（NT2H2331G0/NT2H2331S0）和 NTAG 224 DNA（NT2H2421G0/NT2H2421S0）。这些芯片广泛应用于酒店门禁、校园一卡通、展会门票和公共交通等场景。研究团队在对酒店行业的抽样调查中发现，约 34% 的在用卡片并非正品 NXP 芯片，而是来自 Giantec（GT23SC4489）、Feiju（FJ8010）等厂商的兼容卡——这些非 NXP 芯片存在更严重的安全缺陷。 从攻击者视角来看，该研究揭示了一个令人不安的现实：这些芯片的防护机制并非毁于加密算法本身（3DES 与 AES-128 在算法层面依然安全），而是倒在协议设计的细节上。具体而言，问题集中于三个层面：认证后的内存写入缺乏完整性保护、跨页密钥写入不具备原子性、以及大量部署系统未正确配置可用安全选项。 ## Relay 攻击的技术实现路径 理解 Relay 攻击是理解整个攻击链的关键。与传统的中间人攻击不同，Relay 攻击的核心是「中继」——攻击者在两个合法通信方之间建立一个透明通道，将一方的请求转发给另一方，再将响应返回。NFC 场景下的 Relay 攻击典型架构由两部分组成：「发起端」（Proxy Tag）模拟目标芯片响应读卡器，「接收端」（Proxy Reader）将真实芯片的响应转发给远程系统。 MIFARE Ultralight C 在认证阶段确实实现了双向验证，读卡器与芯片都会证明自己掌握共享密钥。但问题出在认证完成之后。与 MIFARE DESFire 不同，Ultralight C 在认证后发送的所有命令均为明文，不携带任何 MAC 或加密校验。这意味着攻击者只要能够 Relay 认证过程，让芯片认为自己已经与合法读卡器完成握手，就可以在此基础上注入任意命令。更为关键的是，该芯片在认证过程中没有任何超时限制——它会无限期等待读卡器的响应，这消除了 Relay 攻击中最大的技术障碍：时延控制。 实际攻击中，研究团队使用两台 Flipper Zero 设备通过 433 MHz 无线频段建立通信通道，也可以使用 Proxmark3 设备。整个中继链路的延迟可以控制在可接受范围内，足以欺骗芯片的响应等待机制。一旦 Relay 通道建立，攻击者就获得了芯片的「在线」状态，可以执行任意认证后命令。 ## Partial Key Overwrite：密钥空间的数学坍塌 Relay 攻击的价值在于它提供了「认证后访问」，而真正实现密钥恢复的是 Partial Key Overwrite（PKO）技术。MIFARE Ultralight C 将 112 位 2TDEA 密钥存储在四个连续的 4 字节内存页中（页 44 至 47）。芯片的固件设计允许对这四个页面进行独立写入，而不强制要求原子性——也就是说，攻击者可以逐页覆盖密钥内容，而芯片不会阻止这种操作。 攻击流程如下：首先，攻击者通过 Relay 获得芯片的认证后访问权限；然后，依次对四个密钥页中的三个执行写入操作，将其覆盖为零值或其他已知常量；最后，对保留的那个未知密钥页执行暴力破解。由于每个 4 字节页包含 32 位信息，暴力破解仅需 $2^{32}$ 次尝试。更进一步，如果将四次攻击分别针对不同的密钥页执行，然后将四段恢复的密钥片段组合，理论上可以用 $4 \times 2^{32}$ 的代价恢复完整的 112 位密钥——这正是 $2^{28}$ 量级的来源。 对于非 NXP 兼容芯片（如 ULCG、FJ8010、USCUID-UL），攻击成本甚至可以进一步降低至「单卡秒级」。这些芯片的伪随机数生成器（PRNG）存在可预测性缺陷，且缺乏防撕裂（anti-tearing）机制。研究团队实测表明，使用普通智能手机即可在这类卡片上实现完整密钥恢复，全程不超过 60 秒。 ## NTAG 22x DNA 的特殊脆弱性 NTAG 223 DNA 和 NTAG 224 DNA 虽然采用了 AES-128 保护机制，但其安全模型存在结构性缺陷。研究发现，这些芯片在 SUN（Secure Unique NFC）消息的 CMAC 计算上存在设计疏漏：CMAC 是在密文而非明文上计算的，且缺乏对命令本身的完整性校验。这产生了一个「未认证密文 oracle」，攻击者可以通过_partial key overwrite_技术修改部分密钥材料，然后利用离线 CMAC 暴力破解来恢复完整的 SUN_CMAC_KEY。整个过程同样可以在分钟级时间窗口内完成。 对于系统运营者而言，这意味着即使采用了 AES 保护，如果未启用 SEC_MSG_ACT（安全消息激活）配置位，攻击者依然可以绕过其防护机制。NTAG 22x DNA 的 AUTH0 和 AUTH1 配置位提供了细粒度的访问控制，但调查发现大多数 Hospitality 部署系统未启用这些选项。 ## 实操参数与设备需求 从威胁建模角度，我们需要明确攻击者的资源门槛。研究论文列出了完整的攻击装备清单：Relay 攻击阶段需要两台 Flipper Zero（通过 433 MHz 通信）或两台 Proxmark3 设备；在线暴力破解阶段，Proxmark3 或 Flipper Zero 可实现约每秒 100 次认证尝试；离线计算阶段，普通笔记本电脑即可处理非 NXP 卡片，而针对 NXP 卡片的两标签变体攻击需要 GPU 集群加速。整个攻击套件的成本控制在 500 美元以下，且相关代码已集成至 Proxmark3、Flipper Zero 和 ChameleonUltra 的官方固件仓库。 这一成本门槛意味着，攻击者无需国家级别的资源支持即可实施攻击。对于酒店、公寓等依赖 Ultralight C 或 Ultralight AES 进行门禁管理的场所，这是一个需要立即评估的现实威胁。 ## 防御策略与缓解措施 针对不同风险等级的场景，我们建议采用分层防御策略。对于高风险部署（使用静态密钥、未锁定密钥页、供应链中存在非 NXP 卡片），应当立即启动迁移评估。短期内可行的缓解措施包括：使用 Proxmark3 的 `hf mfu info` 命令审计现有卡片，识别非 NXP 兼容产品（ULCG 卡片可通过 UID 后缀 1589 快速识别）；对仍可写的密钥页执行锁定操作（Ultralight C 的 Lock byte 3 第 7 位）；在 Ultralight AES 上启用 AUTH_LIM 认证尝试限制并锁定配置位。 中期而言，所有新发行的卡片应当强制执行密钥 diversification（密钥分散化），即使用卡片 UID 与站点特定盐值通过 KDF 生成唯一密钥，而非全系统共享同一密钥。这可以有效限制单卡泄露对整体系统的影响范围。长期来看，对于安全需求较高的场所，建议迁移至 MIFARE DESFire EV3 等具备端到端加密和硬件级防撕裂保护的下一代技术。 ## 结语 BREAKMEIFYOUCAN 研究的重要意义在于，它揭示了安全工程中一个常被忽视的真理：加密算法的安全性与系统安全性之间存在巨大鸿沟。3DES 和 AES-128 在数学上依然强壮，但协议设计中的一个疏漏——认证后明文传输——就足以让整个安全模型崩塌。对于依赖 NFC 智能卡进行访问控制的组织而言，现在是时候审视自己的部署配置，确认那些「理论上可用」的安全选项是否已经在生产环境中真正启用。 资料来源：研究论文发表于 Cryptology ePrint Archive（2026/100），完整技术报告与 POC 工具见 GitHub 仓库 `zc-public/breakme-resources`。 ## 同分类近期文章 ### [微软终止VeraCrypt账户：平台封禁下的供应链安全警示](/posts/2026/04/09/microsoft-terminates-veracrypt-account-platform-lock-risk/) - 日期: 2026-04-09T00:26:24+08:00 - 分类: [security](/categories/security/) - 摘要: 从VeraCrypt开发者账户被终止事件，分析Windows代码签名的技术依赖、平台封禁风险与开发者应对策略。 ### [GPU TEE 远程认证协议在机密 AI 推理中的工程实现与安全边界验证](/posts/2026/04/08/gpu-tee-remote-attestation-confidential-ai-inference/) - 日期: 2026-04-08T23:06:18+08:00 - 分类: [security](/categories/security/) - 摘要: 深入解析 GPU 可信执行环境的远程认证流程，提供机密 AI 推理场景下的工程参数配置与安全边界验证清单。 ### [VeraCrypt 1.26.x 加密算法演进与跨平台安全加固深度解析](/posts/2026/04/08/veracrypt-1-26-encryption-algorithm-improvements/) - 日期: 2026-04-08T22:02:47+08:00 - 分类: [security](/categories/security/) - 摘要: 深度解析 VeraCrypt 最新版本的核心加密算法改进、跨平台兼容性与安全加固工程实践，涵盖 Argon2id、BLAKE2s 及内存保护机制。 ### [AAA 游戏二进制混淆：自研加壳工具的工程现实与虚拟化保护参数](/posts/2026/04/08/binary-obfuscation-in-aaa-games/) - 日期: 2026-04-08T20:26:50+08:00 - 分类: [security](/categories/security/) - 摘要: 解析 AAA 级游戏二进制保护中的自研加壳工具、代码虚拟化性能开销与反调试实现的技术选型。 ### [将传统白帽黑客习惯引入氛围编程：构建 AI 生成代码的防御纵深](/posts/2026/04/08/old-hacker-habits-for-safer-vibecoding/) - 日期: 2026-04-08T20:03:42+08:00 - 分类: [security](/categories/security/) - 摘要: 将传统白帽黑客的安全实践应用于氛围编程，通过隔离环境、密钥管理与代码审计，为 AI 生成代码建立防御纵深，提供可落地的工程参数与清单。