# NFC 访问控制与支付协议的密钥安全差异：PKO 在线认证的中继攻击面分析 > 深入分析 MIFARE Ultralight C 等 NFC 访问控制系统的部分密钥覆盖攻击，对比 PKO 在线认证与 Apple Pay、Google Pay 离线验证的安全模型差异。 ## 元数据 - 路径: /posts/2026/01/30/nfc-pko-relay-attacks/ - 发布时间: 2026-01-30T03:47:41+08:00 - 分类: [security](/categories/security/) - 站点: https://blog.hotdry.top ## 正文 当你使用酒店门禁卡或会议室钥匙扣时，这些设备采用的 NFC 技术与 Apple Pay 或 Google Pay 存在本质上的安全架构差异。2026 年 1 月发布的研究报告 BREAKMEIFYOUCAN! 揭示了广泛部署的 MIFARE Ultralight C、MIFARE Ultralight AES 以及 NTAG 22x DNA 系列芯片中的关键漏洞，攻击者可通过部分密钥覆盖与中继攻击技术，将原本需要 2¹¹² 次尝试的密钥空间压缩至 2²⁸ 以下。这一发现不仅暴露了访问控制系统的物理安全盲区，也凸显了 PKO（PIN Online）在线认证协议在面对中继攻击时的结构性脆弱性。 ## 部分密钥覆盖攻击的技术机理 MIFARE Ultralight C 将其 112 位双密钥 3DES（2TDEA）分散存储在四个连续的记忆体页面中，具体对应页面编号 44 至 47。芯片的固件设计并未强制要求原子性写入——这意味着每个页面都可以被独立修改，而非必须作为一个不可分割的整体同时更新。攻击者在获得初始认证权限后（可通过中继攻击实现），可以利用这一特性进行部分密钥覆盖：将三个密钥页面的内容替换为已知值（如全零），仅保留一个页面的未知状态。由于每个页面包含 28 位有效密钥数据，攻击者只需对单个页面进行 2²⁸ 次暴力尝试即可恢复该部分密钥。重复此过程针对不同标签的不同密钥分片，攻击者能够在数天至数周内重建完整的 112 位密钥，具体耗时取决于可用硬件和目标标签数量。原始 2¹¹² 的密钥空间被压缩至约 4 × 2²⁸，计算复杂度降低了约 75 个数量级。 更值得警惕的是，研究团队发现约 34% 的 hospitality 部署中使用的卡片并非正品 NXP 芯片，而是来自兼容芯片厂商的产品。这些非 NXP 兼容卡片（如 Giantec GT23SC4489、Feiju FJ8010、USCUID-UL）存在严重的实现缺陷：伪随机数生成器可预测且缺乏抗撕裂机制。研究人员在实际测试中成功实现了从单张卡片恢复完整密钥，整个过程在移动设备上耗时不足 60 秒。对于正品 NXP Ultralight C 芯片，虽然需要多个共享静态密钥的标签才能完成攻击，但攻击者可以通过酒店或办公楼宇中大量流通的门禁卡收集所需样本。每张卡片都是攻击者情报收集链中的一环，而许多组织并未建立卡片丢失后的快速注销机制。 ## 协议层面的安全模型鸿沟 理解这一漏洞的关键在于认识到 NFC 访问控制系统与支付系统采用了截然不同的认证协议。PKO（PIN Online）认证要求持卡人输入个人识别码，终端将 PIN 加密后发送至发卡行进行在线验证。这种模式在传统银行卡支付中广泛采用，但其核心假设是持卡人、物理卡片与终端之间存在可信的物理邻近关系。当攻击者通过中继技术打破这一假设时，PKO 协议无法区分合法持卡人与远程攻击者——协议设计者未曾预见卡片可能被位于数百公里外的攻击者控制。BreakMeIfYouCan 研究中使用的双 Flipper Zero 设备通过 433 MHz 频段建立中继通道，整个认证过程对标签而言如同与本地读者完成交互，对终端而言如同与合法卡片通信，协议层面的时间窗口限制被精心规避。 Apple Pay 与 Google Pay 的安全模型则从根本上规避了这一问题。现代移动支付系统将敏感的支付凭证存储在设备专用安全元件（Secure Element）中，该元件与主操作系统物理隔离，即使设备被越狱或 ROOT，攻击者也无法直接提取原始卡号。支付时使用的并非真实卡号，而是经过代币化（Tokenization）处理的动态令牌，每次交易生成的令牌均不同。终端与设备之间采用离线密码学验证：设备使用基于设备唯一密钥和交易计数器计算的动态安全码（Dynamic Security Code），终端通过离线验证该安全码的有效性确认交易合法性。这种设计意味着即使攻击者能够中继通信数据，也无法获取可用于未来交易的凭证，因为每次交易的安全码都是一次性有效的。与依赖在线认证的 PKO 协议相比，移动支付系统的离线验证机制从根本上消除了中继攻击的价值。 ## 攻击成本与现实威胁评估 实施 BreakMeIfYouCan 研究中描述的攻击所需的技术门槛与经济成本均处于可接受范围。硬件层面，攻击者可以使用两台 Flipper Zero 设备搭建中继通道，总成本约 200 美元；或选择功能更强大的 Proxmark3 设备，单台价格同样在百美元量级。在线暴力破解阶段，Proxmark3 或 Flipper Zero 可实现约每秒 100 次认证尝试，对 2²⁸ 密钥空间进行完整搜索需要约 31 天，但对于只需恢复单个 28 位分片的情形则仅需数小时。若攻击者使用标准笔记本电脑进行离线计算，针对存在缺陷的非 NXP 卡片可实现分钟级密钥恢复。整个攻击链条的设备投资不足 500 美元，技术要求对具有中等嵌入式系统经验的攻击者而言完全可行。 从防御者视角审视，威胁严重程度取决于具体部署场景。对于采用静态密钥且未配置锁定位（Lock Byte）的 Hospitality 系统，风险等级评估为高：攻击者可通过收集废弃门禁卡逐步还原主密钥，进而伪造任意卡片权限。研究团队已成功对真实 Hospitality 系统实施凭证伪造攻击。但对于已实施密钥分散化（Key Diversification）、锁定关键记忆体页面并启用 CMAC 完整性校验的系统，同一攻击链的可行性大幅下降。此外，MIFARE DESFire EV3 等更先进的智能卡技术提供了端到端加密通信、强制完整性保护以及硬件级抗撕裂机制，可作为高安全需求场景的迁移目标。NFC 访问控制系统的安全提升路径清晰，但需要系统运营商主动升级配置或更换硬件，而非依赖芯片层面的根本性修复。 ## 缓解措施与架构演进建议 面对部分密钥覆盖与中继攻击威胁，系统运营商应采取分层防御策略。在配置层面，立即检查所有关键记忆体页面是否已锁定，特别是 Ultralight C 的密钥页面（Lock Byte 3，第 7 位）以及 Ultralight AES 的 AUTH0 配置字节。未锁定的配置意味着攻击者仍可通过认证后写入修改密钥状态，这一窗口期应被压缩至最短。对于仍在使用静态密钥的存量部署，建议尽快规划向密钥分散化架构迁移——使用卡片 UID 与站点特定盐值通过安全 KDF 生成个性化密钥，可有效阻止跨卡片攻击。启用 AUTH_LIM（认证尝试限制）功能可增加暴力破解的时间成本，而 CMAC 完整性验证（SEC_MSG_ACT）的强制启用则可阻止未授权的内存篡改。 从长期架构演进角度，NFC 访问控制系统可参考支付行业的技术路线。虽然完全迁移至 DESFire EV3 涉及硬件更换成本，但新项目建设时应将向后兼容性与安全基线纳入采购标准。对于现有系统，额外的后端验证层可作为快速缓解措施：在凭证验证时引入卡片使用模式分析、异常时段告警以及多因素认证（如结合手机端动态码），可在密钥泄露后限制攻击者的横向移动能力。供应链审计同样不可忽视——约三分之一的 Hospitality 部署中混入了非正品卡片，这意味着组织的安全边界实际已超出其可控范围。使用 Proxmark3 最新固件的 `hf mfu info` 指令可快速识别具有特定 UID 后缀（如 1589）的伪造卡片，应纳入入场检测流程。 ## 结语 BreakMeIfYouCan 研究揭示的核心问题并非底层密码学算法的缺陷，而是协议设计选择与系统配置疏漏的叠加效应。3DES 与 AES-128 本身仍保持其密码学强度，但缺乏认证后完整性保护、允许非原子性密钥写入、以及配置层面的锁定位缺失，共同构成了可被利用的攻击面。与之形成鲜明对比的是，现代移动支付系统通过离线密码学验证、一次性动态令牌与硬件安全元件的组合，从架构层面消除了 PKO 协议面对中继攻击时的结构性脆弱。对于依赖 NFC 技术的访问控制系统运营商而言，这一研究是明确的警示信号：在物理安全领域，技术债务的偿还成本往往与漏洞曝光后的补救成本成正比。 **资料来源**： 1. BREAKMEIFYOUCAN! - Exploiting Keyspace Reduction and Relay Attacks in 3DES and AES-protected NFC Technologies (https://breakmeifyoucan.com) 2. Tap-and-Steal: The Rise of NFC Relay Malware on Mobile Devices, Zimperium zLabs (https://zimperium.com/blog/tap-and-steal-the-rise-of-nfc-relay-malware-on-mobile-devices) ## 同分类近期文章 ### [微软终止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 生成代码建立防御纵深，提供可落地的工程参数与清单。