更新2020/06/07>
NTAG 424 https://www.nxp.com/products/rfid-nfc/nfc-hf/ntag/ntag-for-tags-labels/ntag-424-dna-424-dna-tagtamper-advanced-security-and-privacy-for-trusted-iot-applications:NTAG424DNA支持“安全动态消息传递”，这可能适用于您的用例。您可以使用“动态部分”存储任何 NDEF 消息，该部分可以选择加密和身份验证。
引用第 9.3 节NTAG 424 数据表 https://www.nxp.com/docs/en/data-sheet/NT4H2421Tx.pdf:
安全动态消息传递 (SDM) 可保护机密性和完整性
数据交换，无需事先进行身份验证。 NT4H2421Tx 支持
SDM 用于读取 PICC 上的标准数据文件之一。安全动态
消息传递允许增加数据读取的安全性，同时仍然能够使用
标准 NDEF 读卡器。典型的用例是 NDEF 保存 URI 和一些元数据，其中 SDM 允许传递此元数据的机密性和完整性
保护后端服务器。
但请注意，该解决方案不能抵抗某些特定的尾部重放场景，引用：
使用 SDM 时，必须考虑安全动态消息传递带来的残余风险。由于 SDM 允许自由读取受保护的
消息，即无需任何预先的读者身份验证，任何人都可以读出
信息。这意味着潜在的攻击者也能够读取并存储一个或多个
多条消息，并在稍后的时间点向验证者播放它们。
如果这种残余风险对于系统的用例来说是不可接受的，那么遗留的共同风险
身份验证（使用质询响应协议）和后续安全消息传递
应该应用。这需要使用自己的应用程序并在外部运行
标准 NDEF 读取操作。
SDM 可以应用其他风险缓解措施来限制剩余风险，而不需要完全
删除它：
在验证端跟踪每个标签的 SDMReadCtr。拒绝 SDMReadCtr 值
以前看过或者乱序播放的。这是最低要求
验证者应实施。
通过要求定期呈现标签来限制攻击者的时间窗口（例如，在
每天至少一次）与之前的缓解措施相结合。
多次读出受 SDM 保护的文件。这不能防止
攻击者也多次读出有效标签并播放收到的
以相同的顺序响应。
（请注意，上述遗留相互身份验证协议是我在下面的原始答案中描述的）
有一个有趣的实现后端服务器的项目 https://github.com/icedevml/ntag424-backend (with 标签个性化说明 https://github.com/icedevml/ntag424-backend#how-to-setup-sdm).
原答案如下：
Common 不可编程智能卡通常提供以下其中一项（或某种组合）：
熔丝位-- 一个存储区域，其中各个位的值只能以一种方式更改（从零到一或从一到零，但不能同时更改两者）
单调计数器-- 存储在卡上的整数值，在个性化后只能在一个方向上更改（增加或减少，但不能同时增加或减少）
电子钱包-- 一个整数值，可以由一个实体减少并由另一个实体增加（两个实体都通过不同的密钥证明自己）
这些函数都没有直接提供任何不可预测的标记（参见注释 1）。
另一方面是你的“令牌收集者”必须拥有一个允许卡写入访问的密钥（以便能够修改计数器/钱包）——这使他们能够轻松耗尽所有剩余的保险丝位或计数器/钱包值（有效地导致其他“令牌收集器”的拒绝服务条件）。访问控制不能细粒度到仅允许单个令牌收集（这可能是您想要的）。
With a 可编程智能卡您可以（半）轻松地实现您需要的任何操作语义——看看 Java Card（不过可编程智能卡更昂贵）。
假设您的“令牌收集器”在读取卡时在线，那么最简单的方法可能是仅使用该卡来证明“令牌收集器”位于其附近并在服务器上生成“令牌”。
为了证明与卡的接近度，“令牌收集者”将使用他/她的 NFC 手机在服务器和卡之间中继相互验证命令。为此，他/她不需要知道任何卡密钥。
任何具有相互身份验证功能的智能卡（例如 Ultralight-C 或 DESFire）都可以在这种情况下使用（参见注释 2 和 3）。
DESFire 的通信看起来与此类似：
祝你好运！
注1：实际上有些卡可以为其电子钱包生成不可预测的“余额证书”，但我不知道有任何CL卡支持此功能。
注 2：具有基于密码的身份验证的卡不适合，因为“令牌收集者”可以轻松拦截发送到卡的密码。 MIFARE Classic 不适合，并且加密密钥需要直接加载到读卡器（无法中继）。
注 3：请注意，通过执行此中继身份验证，您授予“令牌收集器”绑定到相应密钥的所有访问权限（尽管他/她不知道会话密钥的值）。因此，Ultralight-C 不是一个好的选择，因为从技术上讲，您将给予他/她对卡的完全访问权限。同样，不要使用 DESFire 卡主密钥进行中继身份验证 - 使用 2 个应用程序密钥（具有只有您知道的随机值）创建一个新应用程序，并使用第二个密钥（不是应用程序主密钥）进行中继身份验证。请记住也要更改卡主密钥。
注 4：DESFire EV2 具有命令中继保护功能，因此您必须测试它是否适用于您的场景。
