【笔记】移动设备的近场交互、离线凭证与硬件信任

手机读取 NFC 标签、模拟门卡，手环展示离线付款码，以及手机用指纹授权支付，看起来都是“拿移动设备碰一下或扫一下”。但它们并不是同一种通信。

理解这些场景的关键，不是笼统地把它们归为移动通信，而是分清三个问题：附近的设备如何交换数据、交换的凭证如何证明身份、秘密如何避免暴露给普通系统。

整体模型：通信、凭证与信任根

移动设备完成一次近场交互，通常可以拆成三层：

flowchart LR
    A[近场载体] --> B[协议与凭证]
    B --> C[验证与授权]

    A1[NFC 射频场] --> A
    A2[屏幕上的条码或二维码] --> A
    A3[蓝牙或互联网] --> A

    B1[UID / NDEF / APDU] --> B
    B2[动态付款 Token] --> B
    B3[交易数据的数字签名] --> B

    C1[本地读卡器] --> C
    C2[支付平台后台] --> C
    C3[TEE / SE / Android Keystore] --> C

三层不能混为一谈：

场景	近场载体	终端交出的内容	最终验证者
手机读取 NFC 标签	13.56 MHz NFC 射频	标签标识、NDEF 或底层协议数据	手机应用或系统
手机模拟 NFC 卡	13.56 MHz NFC 射频	防碰撞信息、ISO-DEP/APDU 等	门禁或 POS 读卡器
手环离线付款码	屏幕可见光	条码或二维码中的支付凭证	联网的商家终端与支付后台
指纹授权手机支付	本地传感器 + 互联网	认证结果约束下生成的密码学结果	应用后台

因此，“离线”也要说明是哪一端离线。手环可以不联网，但商家的扫码设备和支付后台通常仍需联网。NFC 卡模拟也不等于整个交易离线；它只说明手机或手环与读卡器之间使用近场射频通信。

手机为什么能在解锁后立即读到 NFC 标签

Reader/Writer 模式与轮询

读取标签时，手机处于 NFC Reader/Writer 模式。它作为主动设备产生 13.56 MHz 射频场，并在 discovery loop 中尝试发现附近支持的技术类型，例如 NFC-A、NFC-B、NFC-F 和 NFC-V。标签通常是无源设备，进入射频场后从中获取能量，再通过负载调制把响应送回手机。

从使用者视角看，手机似乎一直在扫描。更准确地说，NFC 控制器会在系统允许发现标签时执行周期性的发现流程。具体轮询节奏、低功耗检测方式和功耗策略由 NFC 控制器、驱动、Android 版本及厂商配置共同决定，不能为所有 Android 手机写死一个统一周期。

部分控制器支持 Low Power Card Detection 一类机制：低功耗阶段先检测天线负载或场环境是否变化，发现可能的目标后再进入完整轮询。这是一种常见硬件优化，不是 Android 应用层保证的统一实现。

屏幕与锁定状态不是一个固定真值表

“灭屏时 NFC 完全关闭、解锁后所有模式全部开启”只适用于部分设备和旧版本，不能当作 Android 的永恒规则。

Android 的标签读取、Host Card Emulation、Secure NFC 和厂商钱包可以有不同策略。以 HCE 为例，Android 官方文档明确区分了不同系统版本、requireDeviceUnlock、requireDeviceScreenOn 与 Secure NFC 的影响。因而实际行为要同时看：

• Android 版本；
• 设备是否支持并启用 Secure NFC；
• 卡模拟服务是否要求解锁或亮屏；
• 厂商是否为交通卡、门卡或支付提供 off-host 路由；
• 当前是在读标签，还是被外部读卡器读取。

应用若要在前台专门读取标签，可以调用 NfcAdapter.enableReaderMode()。该模式把控制器限制为读写器，暂时关闭本机的点对点和卡模拟模式。它说明“读标签”和“被当成卡读取”是两种角色，不能同时用一个模糊的“手机 NFC 开着”来描述。

从发现一张卡到访问应用数据

以 NFC-A 为例，一次交互至少要区分以下层次：

1. 射频发现与供能：读卡器建立场，卡进入工作状态。
2. 防碰撞与选择：存在多张卡时，读卡器逐步解析标识并选中一个目标。
3. 协议激活：双方根据卡的能力进入后续协议，例如 ISO-DEP。
4. 应用交互：在 ISO-DEP 之上交换 APDU，或者进入某种产品私有命令集。
5. 业务授权：门禁控制器或支付后台判断凭证是否有权限。

UID、ATQA、SAK/SEL_RES 都属于较低层的发现或激活信息。它们能帮助读卡器判断后续该走什么协议，却不天然等于业务身份，更不等于安全认证。

NXP 的类型识别资料给出了典型值：MIFARE Classic 1K 的最终 SAK 常见为 0x08，支持 ISO/IEC 14443-4 的设备会设置 0x20 对应的能力位。但 SAK 是位字段，不应总被当成互斥枚举；多个能力位可以组合出现。

防碰撞不是穷举所有 UID

当多张 NFC-A 卡同时进入射频场时，读卡器通过防碰撞和级联选择逐张选中目标。它不是从 0x00000000 开始猜 UID，而是在卡片共同响应时识别碰撞位置，再指定已知 UID 前缀继续搜索分支。

可以把它理解为一棵按 UID 位展开的搜索树：

两张卡：10110010、10110111
共同前缀：10110
碰撞位置：下一位分别为 0 和 1
读卡器先继续 101100... 分支，再处理 101101... 分支

选中卡片后，后续认证和读写针对当前卡片会话。UID 在这里首先解决寻址问题。业务系统可以进一步把 UID 当数据库索引，但那是门禁应用的选择，不是 ISO/IEC 14443 对 UID 的安全承诺。

无源卡如何获得电并返回数据

典型无源 NFC 卡没有电池。读卡器天线产生交变磁场，卡片线圈通过电磁感应取得能量，经整流和稳压后驱动芯片。线圈本身既不保存 UID，也不维护认证状态；非易失数据存放在芯片内的 EEPROM 等存储中，会话状态则由芯片逻辑在当前上电期间维护。

卡片返回数据时不需要像 Wi-Fi 设备那样独立产生一个强射频载波。它改变自身天线回路的负载，让读卡器一侧观察到载波上的微小变化，这就是负载调制。由此可以把无源卡概括成：

读卡器：提供射频场、能量、时钟与命令
卡片：借场上电，通过改变负载返回响应

卡片离开场后通常会掉电，易失的选择、认证和密码流状态随之消失。新的读卡器不能继承上一个读卡器建立的认证状态。

MIFARE Classic：带分区权限的无线存储

MIFARE Classic 不是完整的 CPU 智能卡。更合适的心智模型是：ISO/IEC 14443-A 射频接口 + 固定协议状态机 + Crypto1 认证和加密 + EEPROM。

1K 卡的存储布局

MIFARE Classic 1K 有 16 个 sector。每个 sector 包含 4 个 16 字节 block，最后一个 block 是 sector trailer：

Sector n
├── Data Block 0       16 B
├── Data Block 1       16 B
├── Data Block 2       16 B
└── Sector Trailer     16 B
    ├── Key A           6 B
    ├── Access Bits     3 B
    ├── User Data       1 B
    └── Key B           6 B

Sector 0 的 Block 0 是 manufacturer block，包含 UID/BCC 及厂商数据，和普通数据块不同。MIFARE Classic EV1 1K 提供 4 字节 NUID 或 7 字节 UID 版本，不能把所有 Classic 卡都固定理解为 4 字节 UID。

Key A、Key B 与 Access Bits 是一个小型 ACL

每个 sector 有自己的 Key A、Key B 和访问条件。卡片不会理解“这是门禁机”或“这是充值机”，它只记得当前使用哪类 key 完成了哪个 sector 的认证，再用 Access Bits 判断后续命令是否允许。

AUTH with Key A
        ↓
当前会话获得 Key A 身份
        ↓
READ / WRITE / INCREMENT / 修改 trailer
        ↓
根据目标 block 的 Access Bits 放行或拒绝

所以 Key A、Key B 不是固定的“读密码”和“写密码”。到底谁能读、写、执行值操作或修改 trailer，由访问位组合决定。两把 key 的价值在于让同一 sector 支持两类能力主体，例如普通终端和管理终端；部署者也可能只使用其中一把，甚至把两把设置成相同值。

认证不是把 key 明文发到空中。读卡器和卡片通过随机数及 Crypto1 状态证明双方持有 key，认证成功后进入加密会话。AUTH 与后续 READ 虽然是独立命令，但卡片状态机保存了已认证 sector 和认证类型。离开射频场重新上电后，需要重新发现、选择和认证。

MIFARE Classic 的安全边界

MIFARE Classic 的访问控制设计并不意味着它今天仍提供足够强的密码学安全。公开研究已经证明 Crypto1、随机数生成及认证协议存在严重弱点，可用于恢复密钥。Nested、Darkside、Hardnested 等名称代表不同前置条件和卡片实现下的攻击路径，不能简化成“任意全加密卡都能在固定几分钟内破解”。

对系统设计的长期结论是：

• 默认 key、跨卡共享 key 会进一步放大风险；
• 只使用 UID 等于把可复制标识当认证凭证；
• 卡片数据加密不能替代后台的撤销、风控与审计；
• 新系统不应再把 MIFARE Classic/Crypto1 当作强安全根，应使用经过公开分析的现代密码协议与安全芯片方案。

CPU 卡、DESFire 或 MIFARE Plus 的具体安全能力取决于产品、配置和安全级别，不能只凭“CPU 卡”三个字保证安全。它们与 Classic 的关键区别，是能够执行更完整的应用协议和现代密码学挑战应答，而不只是暴露一块受简单 ACL 保护的存储。

手机模拟门卡为什么不是“复制所有字节”

两条卡模拟路径

Android 设备上的卡模拟至少有两类路径：

• Off-host card emulation：NFC 控制器把读卡器流量路由到 eSE 或 UICC 等安全元件，Android 应用不直接参与每个交易帧。
• Host Card Emulation（HCE）：控制器把 ISO-DEP/APDU 流量路由到主机 CPU 上的 HostApduService。

Android HCE 的标准能力是模拟基于 NFC Forum ISO-DEP、ISO/IEC 14443-4 和 ISO/IEC 7816-4 APDU 的智能卡应用。它不是任意 NFC 芯片的透明模拟器，也不能靠普通应用完整复刻 MIFARE Classic 的底层命令、固定 UID 和射频特征。

HCE 的 UID 与激活参数边界

Android 官方要求读卡器把 HCE 设备的 UID 视为随机值，不能依赖它做身份或认证。NFC-A 激活时，HCE 设备的 SEL_RES 至少设置 0x20 能力位，表示支持 ISO-DEP；其他位也可能同时设置。ATS 由 NFC 控制器产生，HCE 服务不能随意配置。

由此可以得到一个重要结论：普通 HCE 应用无法承诺“把某张 MIFARE Classic 卡的 UID、SAK、ATS 和底层命令全部原样复制”。厂商钱包若支持门卡模拟，可能使用厂商 NFC 固件、eSE、专有 provisioning 或特定白名单能力，但具体方案不能从 Android 公共 HCE API 反推，也不能假设所有手机都一样。

门禁失败可能发生在哪一层

当实体卡能开门、手机模拟卡不能开门时，原因可能分布在不同层：

• 手机没有呈现门禁所依赖的固定标识；
• 激活阶段的协议能力与原卡不同；
• 门禁继续发送 MIFARE Classic 私有认证或读块命令，而手机只支持 ISO-DEP/APDU；
• 卡内还有受密钥保护的数据或计数状态，没有被模拟；
• 厂商钱包只创建了另一种虚拟卡，并未复制原卡；
• 天线位置、耦合强度或终端兼容性导致射频交互不稳定。

仅凭“UID 一样但刷不开”不能断言门禁一定校验 SAK。要定位到具体层次，需要能够观察防碰撞、激活和后续命令的读卡器或协议分析设备。另一台手机上的普通标签应用通常只能看到 Android NFC 栈暴露的结果，未必能完整记录底层时序。

一个真实工牌案例如何收敛推理

现有材料里记录了一次很有价值的排查。实体工牌被识别为 MIFARE Classic 1K，典型信息包括 4 字节 UID、SAK = 0x08 且无 ATS。使用 Mifare Classic Tool 通过实际 Read Tag 保存的 dump 显示：

• Sector 1～15 的数据块全部为零；
• 各 sector trailer 使用默认 key FFFFFFFFFFFF；
• Access Bits 为常见默认配置；
• 手机、手环和实体卡在另一台 Android 手机可见的 dump 一致。

这些证据可以支持一个有限结论：在 MCT 能读取并展示的 MIFARE Classic 存储范围内，没有业务数据需要复制，相关门禁很可能至少使用 UID 作为身份索引。 它不能直接证明所有读卡器只读取 UID，也不能证明三个介质在射频波形、响应时序和控制器行为上完全一致。

现场行为进一步显示：消防门能接受实体卡、手机和手环；公司入口闸机始终接受实体卡，不接受手机，只偶尔接受手环。这个对照排除了“所有门禁都执行同一条验证路径”，但还不能唯一定位原因。候选解释包括：

• 两套门禁使用不同读卡器或后台策略；
• 手机、手环和实体卡在 Android API 不可见的激活参数或协议行为上不同；
• 天线耦合、场强、摆放位置或响应时序造成兼容性差异；
• 闸机读取了 manufacturer block 或执行了额外 MIFARE 命令；
• 闸机联网查询，现场一两秒延迟来自网络、控制器或机械动作，而非所谓“风控运算”。

“手环偶现成功”说明它至少在部分交互中满足了闸机条件，但不能单凭概率断言问题一定在射频层。确定原因需要抓取读卡器与三种介质的完整空中接口帧和时序，或者取得门禁控制器日志与配置。Proxmark3 一类研究设备可以帮助观察协议帧，但普通 Android NFC API 不是射频示波器，也不能给出完整模拟前端波形。

这个案例最值得保留的不是某个猜测，而是证据驱动的收敛过程：先由卡型排除 ISO-DEP CPU 卡，再用完整 dump 排除“业务数据藏在加密 sector”，最后把问题缩小到不同门禁路径以及 Android API 看不到的协议、射频或后台差异。

双接口 NFC EEPROM：无线存储与主控之间的桥

双接口 NFC EEPROM 把两种访问路径接到同一颗非易失存储器：一侧是 MCU 使用的 I²C，另一侧是手机或 RFID 读卡器使用的 NFC/RF 接口。部分产品还提供 SRAM mailbox 或 pass-through mode，让两侧交换临时数据，而不必把每次传输都写入 EEPROM。

flowchart LR
    Phone[手机 / NFC Reader] <-->|NFC-A 或 NFC-V| Tag[双接口 NFC Tag]
    MCU[设备 MCU] <-->|I2C| Tag
    Tag --- EEPROM[(EEPROM)]
    Tag --- SRAM[(SRAM / Mailbox)]

NXP NTAG I²C plus 是 NFC Forum Type 2 Tag，提供 I²C、EEPROM、64 字节 SRAM、32 位密码访问控制和能量采集。ST25DV 则基于 NFC-V/ISO 15693，提供 I²C、多个可保护区域、RF 与 I²C 侧密码及 fast transfer mode。它们说明“双接口 NFC EEPROM”是一个产品类别，不代表所有芯片遵循同一种射频协议或安全模型。

密码保护通常适合防止普通误写和未授权访问，但短密码或明文/弱保护的空中认证不能等同于现代加密认证。是否会暴露密码、是否限制尝试次数、不同接口如何仲裁、断场后会话权限是否清除，都必须查具体芯片数据手册。

能量采集也要准确理解：芯片可以从 NFC 场向外部负载提供有限能量，用于唤醒或低功耗操作；这不等于任意 MCU 都能靠手机 NFC 稳定运行。可用功率受天线、距离、场强和芯片工作状态限制，某些芯片在输出能量时甚至不保证同时通信。

这个类别把前文两个模型接了起来：线圈负责供能和通信，EEPROM 保存掉电状态，SRAM 负责临时交换，密码/权限控制访问范围。它仍然不是 SE；它的首要目标是连接与存储，而不是充当高等级防篡改信任根。

手环离线付款码：离线的是手环，不是验证系统

离线付款码和 NFC 支付最容易被混淆。两者都能在手机不在身边时使用，但数据路径完全不同：

sequenceDiagram
    participant W as 手环（离线）
    participant P as 商家扫码终端（联网）
    participant S as 支付平台后台

    W->>W: 展示当前可用的付款凭证
    W-->>P: 光学读取条码或二维码
    P->>S: 上传凭证与交易上下文
    S->>S: 识别主体、校验有效性与风控
    S-->>P: 返回受理或拒绝结果

付款码至少需要解决四件事：

1. 路由：后台如何从凭证定位账户、设备或某个令牌记录。
2. 真实性：凭证是否由合法设备或平台生成。
3. 新鲜度：凭证是否过期，是否已经使用，能否被截图重放。
4. 风险控制：设备丢失、长期离线或异常消费时如何止损。

一种系统可以预先下发一批短期 Token，也可以让设备根据受保护秘密和状态动态生成凭证，还可以混合两者。时间、计数器、随机数、服务端挑战、设备状态和签名都可能参与设计。具体支付宝、微信或手环厂商采用哪种格式、是否纯 TOTP、是否维护固定数量的码池、离线多少次或多少天，属于闭源实现；没有公开证据时不能写成事实。

TOTP 只是理解动态凭证的参考模型

RFC 6238 定义的 TOTP 是 HOTP 的时间变体：双方共享密钥，以从 Unix 时间和时间步长导出的值替代 HOTP 的事件计数器，再使用 HMAC 和截断函数得到一次性密码。

T = floor((UnixTime - T0) / X)
TOTP = HOTP(K, T)

验证端可以接受有限的相邻时间窗口以容忍时钟漂移，但在一次成功验证后不能再次接受同一 OTP。TOTP 能解释“设备离线也能产生、服务器在线验证”的基本形态，却不能证明商业付款码就是标准 TOTP。支付凭证通常还要承载路由、风控和交易网络自身的协议语义。

本地计数器与云端风控是不同状态

设备可以维护本地出码次数、上次同步时间或单调计数器，用于限制长期离线使用。后台则能记录凭证使用情况、消费金额、设备状态和账户风险。两边状态可能在重新联网时同步，但“本地固定 50 次、7 天后由云端签令牌清零”只是一种可能设计，不是公开标准。

更稳妥的心智模型是：本地限制降低离线设备无限出码的风险，云端状态负责最终受理和全局止损。具体阈值与同步协议由产品实现决定。

SE、TEE 与 Android Keystore 分别保护什么

SE 与 TEE 不是同一个东西

Secure Element（SE）通常是独立的防篡改安全组件，拥有受保护的存储、计算环境和受控通信接口。eSE、UICC/SIM 都可以承载安全应用。

Trusted Execution Environment（TEE）通常与主处理器共享一个 SoC，通过硬件隔离建立受信执行环境。它比普通 Android 应用所在的 Rich Execution Environment 更难被直接访问，但不等同于一颗独立 SE。

两者的共同目标是让敏感密钥在隔离环境中生成或导入，只允许执行经过授权的密码学操作。具体芯片可能采用防探测布线、传感器、侧信道缓解和故障注入防护，但不能把“任何异常都会立即物理自毁并擦除全部密钥”当成所有 SE 的统一保证。

密钥不出安全边界，不等于输入输出都保密

当普通 CPU 请求安全硬件签名时，普通系统可以持有密钥的引用或句柄，并把待签名消息传入安全组件。私钥材料本身不需要进入应用进程，安全组件只返回签名结果。

这种模型主要防止导出密钥材料。如果攻击者已经完全控制了获准使用密钥的应用或系统流程，他仍可能尝试让安全硬件替他执行操作。因此还需要用途限制、用户认证、交易绑定、速率限制和远程风控，不能把“密钥不可导出”等同于“设备绝对不会被滥用”。

Provisioning 不能简化成“拿设备公钥加密一次”

向 SE 安装支付应用或密钥通常需要安全 provisioning：验证设备或安全元件身份，建立受保护信道，校验命令的来源、完整性与新鲜度，再在安全域中写入数据。设备证书链、预置密钥、安全通道和远程服务都可能参与。

“平台直接拿每颗 SE 的公钥加密种子密钥，由 CPU 原样转发”是一个可行的教学模型，却不是所有产品的真实协议。只有厂商或支付平台的公开规范才能证明具体采用哪条信任链。

Android Keystore 如何把认证与签名连接起来

Android Keystore 为应用提供统一密钥容器。Keystore 密钥的材料不可导出；密钥还可以绑定到 TEE 或 StrongBox 等安全硬件，并限制用途、算法和使用条件。是否真正由硬件保护，需要通过 KeyInfo.getSecurityLevel() 或密钥证明等机制确认，不能仅凭使用了 AndroidKeyStore 就断言密钥一定在独立 SE 中。

一个典型的“每次认证后才能签名”流程是：

1. 应用在 AndroidKeyStore 中生成只能用于签名的密钥，并设置用户认证要求。
2. 应用创建并初始化 Signature 密码学操作。
3. 应用把 Signature 包装成 BiometricPrompt.CryptoObject，交给系统认证界面。
4. 生物认证成功后，该次密码学操作获得授权。
5. 应用送入待签名消息并取得签名，再由服务器用注册的公钥验签。

CryptoObject 的准确含义是“与认证绑定的密码学操作”，不是把私钥从硬件里解冻并交给应用。对于 auth-per-use key，它允许当前操作在认证成功后使用受保护密钥。

同样，数字签名不是“用公钥解密私钥加密的字符串”。签名方用私钥对消息摘要等结构产生签名，验证方用公钥和原始消息执行验证。公钥验证的是签名与消息是否匹配，并不会恢复一段被私钥加密的交易明文。

至于微信、支付宝是否在某个版本和设备上直接使用 Android Keystore、IFAA、厂商 TEE SDK 或组合方案，属于产品实现，不能仅从 Android 提供这些 API 推断出来。

四个容易混淆的边界

NFC 不等于所有近距离交互

NFC 是明确的射频通信技术。二维码和条形码是光学数据载体；蓝牙是另一套无线链路；指纹是本地传感器输入。它们可以参与同一笔支付，却不能在协议层合并为 NFC。

UID 不等于安全身份

UID 首先服务于发现、选择或标识。某些简单门禁确实可能直接把 UID 当权限索引，但可复制或随机化的 UID 不适合作为强认证凭证。安全系统需要额外的密钥认证、动态状态或后台校验。

能读取卡不等于能模拟卡

Reader/Writer 模式负责主动发现和访问标签；Card Emulation 模式负责响应外部读卡器。手机支持某种卡的读取协议，不代表控制器也允许它原样模拟该卡的射频与协议行为。

安全硬件不等于业务协议已经可信

SE、TEE 和硬件 Keystore 提供隔离、密钥保护与受控计算能力。账户路由、交易绑定、防重放、撤销、额度和风险决策仍要由上层协议补齐。安全芯片是信任根的一部分，不是完整支付系统。

复习索引

• 手机“持续扫描 NFC”应理解为系统允许期间的 discovery loop；精确周期和低功耗方式依赖设备实现。
• NFC-A 的发现、选择、协议激活和业务认证是不同层次；UID、ATQA、SAK 不能替代应用认证。
• Android HCE 面向 ISO-DEP/APDU，UID 应按随机值处理，激活参数部分由 NFC 控制器决定。
• MIFARE Classic 的透明模拟不属于普通 HCE 应用可保证的能力；厂商门卡方案可能使用专有固件或安全元件。
• MIFARE Classic 的 Key A、Key B 和 Access Bits 组成 sector 级 ACL；认证状态只属于当前射频会话。
• 无源卡由读卡器射频场供能，以负载调制返回数据；线圈不保存状态，芯片内存储与状态机才保存数据和会话。
• 手环付款码是光学凭证；离线的是手环，联网商户终端和支付后台仍完成最终验证。
• TOTP 是理解离线动态凭证的参考模型，不能据此断言某个商业付款码的真实算法。
• 双接口 NFC EEPROM 连接 RF 与 I²C，可提供 mailbox、密码区和有限能量采集，但不是 SE。
• Keystore 的私钥对象是受控密钥引用，不包含可导出的私钥材料；硬件保护级别需要单独确认。
• 生物认证可以授权一次密码学操作，但具体支付 App 使用哪套接口仍是实现细节。

依据与未决问题

已核验的公开依据：

• Android NFC 概览
• Android Host-based card emulation 概览
• Android NfcAdapter API
• Android Keystore 系统
• Android BiometricPrompt.CryptoObject API
• NXP MIFARE 类型识别流程 AN10833
• NXP MIFARE Classic EV1 1K 数据手册
• NXP NTAG I²C plus 数据手册
• ST ST25DV 数据手册
• A Practical Attack on the MIFARE Classic
• Dismantling MIFARE Classic
• RFC 6238：TOTP
• GlobalPlatform Secure Element 简介

仍无法从公开材料确认：

• 具体小米设备和钱包版本如何模拟某张门卡；
• 特定门禁终端究竟校验 UID、SAK、卡内数据还是射频时序；
• 支付宝、微信及具体手环的付款码格式、密钥分发、离线阈值和同步协议；
• 特定支付 App 在不同 Android 厂商设备上使用 Android Keystore、IFAA 或私有 TEE SDK 的实际路径。