您可以在不同的模式下对 NFC 进行编程。任务是发送双向消息。在 NFC 中，您可以使用多种组合操作模式来完成此操作：
我有两个不同方面的问题：
使用方面
通过所有三个选项，您可以进行双向通信，并且基本上可以发送您想要的任何内容。您为什么不使用其他选项之上的一个选项？
安全方面
安全性是指窃听、数据破坏、数据修改和中间人攻击等滥用的脆弱性。
我读过 选项 3 (HCE) 也用于例如移动支付。当您使用数据加密等额外措施时，这是安全的选项，还是选项 1 也安全？
谢谢！
【问题讨论】：
标签： android security nfc hce nfc-p2p
为什么会有不同的操作模式？
NFC 背后的最初想法是将现有标准（特别是 ISO/IEC 14443 非接触式智能卡技术和 FeliCa/JIS X 6319-4）结合到一个系统中，该系统既可以与现有的转发器/智能卡/标签进行通信，又可以与现有的读卡器基础设施进行通信并且可用于与专用 NFC 设备轻松通信。
因此，最初的 NFC 标准 (ISO/IEC 18092) 定义了基于那些现有协议的点对点通信模式。除了向后兼容之外，NFC 标准还允许两个 NFC 设备（自动）握手两个 NFC 设备之间的连接。这在读卡器+卡设置中是不可能的：两个读卡器和两张卡都不能相互通信，因此必须在读卡器/卡场景中预定义角色。
因此，最初，读写器模式仅用于访问 NFC 标签（无源数据存储设备）和可能的非接触式智能卡。卡仿真模式（基于 HCE 或 SE）旨在与现有的 ISO/IEC 14443（或 FeliCa）基础设施（例如，在演变为 NFC 之前已经存在的读卡器）进行交互。并且专门为 NFC 设备之间的通信引入了点对点模式。
为什么现在所有模式都可以用于几乎任何场景？
我猜这一发展的驱动因素之一是 Android 上的点对点模式缺乏 API 支持。在 Android 上，点对点模式只能通过 Android Beam 访问，因此不能真正用于双向通信。另一个因素可能是点对点模式协议栈比读写器模式（NFC-DEP + LLCP (+ SNEP) + 应用协议 vs. ISO-DEP + 应用）更复杂协议）。
所以选项 1 主要是因为它是（在 Android 4.4 之前）通过 NFC 实现双向通信的唯一选项。由于 Android 4.4 也选项 3 可用于构建类似的场景。
选项 3 是否比其他选项更安全？
不，一点也不。在所有三种情况下，安全性都必须由应用层来处理。底层通信协议不采用任何加密/完整性保护等。机制。
选项 3 更适合移动支付的原因仅仅是向后兼容方面：使用 HCE，您可以实现与现有非接触式智能卡读卡器交互的应用程序（例如，它们用于 EMV 支付系统）。
【讨论】：