nfc - 是否可以在 NFC 卡中实现 token 队列？

Question

这个问题专门针对 MIFARE Ultralight C/EV1，或 MIFARE DESFire EV1，甚至 NTAG 卡。我想实现一个 token 系统，这样每次普通用户读取其中一张卡片时，他们都会得到一个可用的 token ；该 token 将从他们正在读取的 NFC 卡中“弹出”。换句话说，每次读取 NFC 芯片时，它都会从卡的存储中发出不同的可用 token 。这有可能实现吗？

Answer 1

更新 2020/06/07>

NTAG 424支持可能适用于您的用例的“安全动态消息传递”。您可以存储任何带有“动态部分”的 NDEF 消息，该部分可以选择加密和验证。

引用 NTAG 424 datasheet 的第 9.3 节:

The Secure Dynamic Messaging (SDM) allows for confidential and integrity protected data exchange, without requiring a preceding authentication. NT4H2421Tx supports SDM for reading from one of the StandardData files on the PICC. Secure Dynamic Messaging allows adding security to the data read, while still being able to access it with standard NDEF readers. The typical use case is an NDEF holding a URI and some metadata, where SDM allows this meta-data to be communicated confidentiality and integrity protected toward a backend server.

但请注意，此解决方案不抵抗某些特定的尾部回放场景，引用:

When using SDM, residual risks coming with the Secure Dynamic Messaging for Reading have to be taken into account. As SDM allows free reading of the secured message, i.e. without any up-front reader authentication, anybody can read out the message. This means that also a potential attacker is able to read out and store one or multiple messages, and play them at a later point in time to the verifier. If this residual risk is not acceptable for the system’s use case, the legacy mutual authentication (using challenge response protocol) and subsequent secure messaging should be applied. This would require using an own application and operating outside a standard NDEF read operation. Other risk mitigation may be applied for SDM to limit the residual risk, without completely removing it:

• Track SDMReadCtr per tag at the verifying side. Reject SDMReadCtr values that have been seen before or that are played out-of-order. This is a minimum requirement any verifier should implement.

• Limit the time window of an attacker by requiring tags to be presented regularly (e.g. at least once a day) in combination with the previous mitigation.

• Read out the SDM-protected file more than once. This does not protect against attackers that have read out the valid tag also multiple times and play the received responses in the same sequence.

(请注意，上述遗留的相互身份验证协议(protocol)是我在下面的原始答案中描述的)

有一个有趣的 project implementing the backend server (与 tag personalization instructions )。

原答案如下:

常见 非可编程智能卡 通常提供以下之一(或某种组合):

fuse 钻头 -- 一个内存区域，其中单个位的值只能以一种方式改变(从零到一或从一到零，但不能同时改变)

单调计数器 -- 存储在卡片上的整数值，在个性化后只能在一个方向上改变(增加或减少，但不能同时改变)

电子钱包 -- 一个整数值，可以由一个实体减少并由另一个实体增加(两个实体都通过不同的 key 证明自己)

这些函数都没有直接提供任何不可预测的标记(见注 1)。

另一方面是您的“ token 收集器”必须拥有一个允许卡写访问的 key (以便能够修改计数器/钱包)——这使他们能够轻松耗尽所有剩余的 fuse 位或计数器/钱包值(有效地导致对其他“代币收集者”的拒绝服务条件)。访问控制不能细化到只允许收集单个 token (这可能是您想要的)。

与 可编程智能卡您可以(半)轻松地实现您需要的任何操作语义——看看 Java Card(虽然可编程智能卡更昂贵)。

鉴于您的“ token 收集器”在读取卡时在线，那么最简单的方法可能是仅使用该卡来证明“ token 收集器”在其附近并在服务器上生成“ token ”。

为了证明与卡的接近程度，“ token 收集器”将使用他/她的 NFC 手机在服务器和卡之间中继相互验证命令。他/她不需要知道任何卡片 key 。

任何具有相互身份验证的智能卡(例如 Ultralight-C 或 DESFire)都可以在这种情况下使用(参见注释 2 和 3)。

DESFire 的通信看起来与此类似:



祝你好运!

注1:实际上有些卡可以为他们的电子钱包生成一个不可预测的“余额证明”，但我不知道有任何CL卡支持这一点。

注 2:基于密码验证的卡不适合，因为“ token 收集者”很容易截获发送到卡的密码。 MIFARE Classic 不适合，加密 key 需要直接加载到阅读器(无法中继)。

注意 3:请注意，通过执行此中继身份验证，您授予“ token 收集器”绑定(bind)到相应 key 的所有访问权限(尽管他/她不知道 session key 的值)。因此，Ultralight-C 不是一个好的选择，因为从技术上讲，您可以让他/她完全访问该卡。同样，不要使用 DESFire 卡主 key 进行中继身份验证——使用 2 个应用程序 key (只有您知道的随机值)创建一个新应用程序，并使用第二个 key (不是应用程序主 key )进行中继身份验证。记住也要更改卡主 key 。

注 4:DESFire EV2 具有命令中继保护功能，因此您必须测试它是否适用于您的场景。