基于NTAG213和Ultralight C的支付应用程序（使用Android NFC）

Question

我有一个（大学）项目，我基本上使用Android设备从NFC标签中写入和读取文本，以便将余额存储在卡中（例如，可以在自助餐厅使用）。

现在，我正在使用NTAG213执行以下代码：

ndef.connect();
NdefRecord mimeRecord = NdefRecord.createMime("text/plain", messageEncrypted.getBytes(Charset.forName("US-ASCII")));
ndef.writeNdefMessage(new NdefMessage(mimeRecord));
ndef.close();

如您messageEncrypted所见，我正在使用应用程序级加密对消息（）进行加密，然后再将其写入标签（使用'com.scottyab：aescrypt：0.0.1'库进行AES-256加密-具有非常大的密码密钥，也使用标签UID作为其一部分）。

到目前为止一切顺利-只有我能理解标签上的数据。

在研究中，我发现涉及安全性Ultralight C> NTAG213。

---

问题1）使用应用程序级加密时，为什么（是？）MIFARE Ultralight C比NTAG213更安全？

问题2）我很确定我可以使用AES加密来保证安全性，但是我不希望人们（除了我之外）弄乱存储的数据（在其中格式化标签或写入信息）。我看到防止这种情况的唯一方法（如果我错了，请纠正我）是为标签设置密码。但是，NTAG213和Ultralight C都只有32位密码。够好吗？还有另一种方法可以防止某人（除我以外）写数据吗？

问题3）我可以在此类标签上使用其他哪些安全措施来加强安全性（标签和应用程序层）？

问题4）当您比较标签安全性（MIFARE DESFire> Ultralight> NTAG213> MIFARE Classic）时，真正比较的是什么？容易破解（本机标签）加密还是容易在标签上存储（任何东西）未经许可？

问题5）我看到很多其他技术（MIFARE DESFire，ICODE SLIX，英飞凌Cipurse）更安全，这使我想知道我使用的技术（NTAG213或Ultralight C）是否足以存储某人的平衡。您是否愿意（那是个人观点）说具有应用程序级加密和32位密码的NTAG213足以胜任此类应用程序？某人要花多长时间才能真正破坏其安全性？

Answer 1

使用应用程序级加密时，为什么Ultralight C比NTAG213更安全？那是真的吗？

首先，“更安全”取决于您的实际保护目标是什么。由于您想在卡上存储余额（现金！），因此您可能希望（至少）保护以下目标：

• 用户不能通过在卡上设置任意余额来打印自己的钱。
• 用户必须不能复制其卡，从而不能复制其现金余额。
• 用户必须不能通过将卡还原（回滚）到付款后的先前余额来打印自己的钱。
• 用户一定不能通过重放充值程序来打印自己的钱。
• 用户不得在付款交易过程中通过撕毁卡来逃避付款。
• 用户必须不能在充值过程中通过撕裂卡来产生任意（可能更高）的余额。

另外，您可能也不想信任运营商（接受付款并进行充值的人）。在一个系统中，一组操作员仅执行充值操作，而另一组操作员仅执行支付交易，可能不应该允许后一组操作员“创造”金钱。特别是，您必须非常清楚自己是否完全信任在现场使用的（Android）设备来执行这些操作，以及是否信任操作员（例如，他们不会对这些设备进行任何攻击）。

此外，您可能需要考虑隐私方面的问题（例如，余额可以自由阅读，用户可识别等）。

因此，让我们看一下“应用程序级别加密”在安全性方面添加的内容：

• 由于用户不知道加密密钥，因此他们可能无法在卡上产生任意余额。但是，这在很大程度上取决于余额的格式（未加密形式）。用户可以对密文进行任意修改，从而导致明文的“随机”修改。因此，尽管进行了加密，用户仍可以修改余额值。数字签名/消息身份验证代码是您可能希望用来克服此问题的路径。
• 由于加密密钥（假设加密就足够了，可能还不够）取决于标签的UID，因此可以安全地防止卡克隆（+余额）。但是，请注意，UID只是一个可自由读取的标识符。它绝不是经过身份验证的，也可能是可克隆的。查看NFC标签上的序列号-真正独特吗？可克隆的？。
• 加密的值无法保护您避免用户在付款后将其余额恢复到以前记录的值。以前已经发现了这种类型的漏洞（尤其是在基于MIFARE Ultralight的系统中），例如，参见Benninger，C.，Sobell，M.（2012）：NFC提供免费乘车和房间服务（在您的手机上）。在：在EUSecWest 2012上的演示。
• 由于您在充值过程中写入了完整的值（即没有特定的“增量平衡”命令），因此可以防止用户重播充值（此操作的回滚除外）。
• 如果您的系统仅允许有人看管的付款/充值，那么撕裂的影响可能会相当有限。

因此，让我们看看NTAG213可以具有哪些其他功能来保护系统安全：

• UID在正版标签上是唯一的。这没有太大帮助，请参阅NFC标签上的序列号-真正独特吗？可克隆的？。
• 创意签名：与上述相同，创意签名也只是一个静态的，可自由读取的值。因此，它也很容易克隆。
• 单向计数器可能是帮助您防止回滚的工具（通过将计数器值包括在签名中）。这仍然不会阻止克隆到允许生成任意计数器值的标签平台上。而且，该计数器不容易控制，如果用户试图读取标签，它将改变其值。因此，基于该值的实现是否可靠值得怀疑。
• 与MIFARE Ultralight不同，NTAG213没有可用的一次性可编程区域（因为功能容器已在使用该区域）。因此，您不能基于此实现一次性可抵扣余额。
• 密码保护功能可以帮助您验证标签（通过执行密码验证）和保护标签上存储的值（通过使该值仅在密码验证后才可读/可写）。但是，密码以明文形式传输（可能会被嗅探，特别是在（但不限于）无人值守的情况下），并且密码和实际的读/写之间没有密码绑定。

MIFARE Ultralight C将添加以下内容：

• 可以使用OTP字节。如果可以选择使标签一次性使用（即，它们以只能从余额中扣除且不能充值的特定余额开始），则可以使用OTP字节表示余额。请注意，还有很多事情可能会出错，例如Beccaro，M.，Collura，M.（2013）：OTP在MIFARE ULTRALIGHT中规避：谁说搭便车？在：DEFCON 21上的演示
• 身份验证已大大改善。3DES身份验证方案似乎足够安全，可以防止嗅探密钥。但是，读/写命令也没有密码绑定到身份验证步骤。因此，攻击者可能能够让真正的支付终端+真正的标签执行身份验证，但将读/写重定向到其他地方。在无人值守的情况下，这可能（尤其）是一个问题。

我很确定我可以使用AES加密来保证安全性。

往上看。这可能是不正确的。

我不希望人们弄乱存储的数据。我看到防止这种情况的唯一方法是为标签设置密码。

密码/身份验证密钥可能会有所帮助，但请注意由于身份验证与这些标签平台上的读/写分离而导致的限制。

NTAG213和Ultralight C都只有32位密码。

这不是真的。NTAG213具有32位密码。MIFARE Ultralight C使用具有112位密钥的更复杂的双向2K-3DES身份验证机制。

当您比较标签安全性时，真正要比较的是什么？

• 验证机制（算法，密钥大小）
• 通信安全性（例如，通信本身是否使用从身份验证步骤派生的会话密钥进行了加密/身份验证？）
• 访问控制（例如，充值和付款是否有单独的键？）
• 是否有用于余额管理的专用机制（例如，值字段，专用的增量/减量操作）？因此，还有其他机制来防止再次的撕裂攻击吗？
• 可能还有更多...

我看到许多其他技术更安全，这使我想知道我使用的技术是否足以存储某人的平衡。

您特定的系统在很多方面都有缺陷。在我看来，对于将现金存储在卡上的离线系统，MIFARE Ultralight / NTAG203 / NTAG21x绝对不是一个不错的选择。

MIFARE Ultralight C在某些预防措施下可能适用。我绝对不会在无人值守的情况下使用它，并且我可能会使用一个在线系统来跟踪余额并监视不一致性。

任何使用对称密码并将密码密钥存储在终端中的事物都肯定需要采取预防措施，以防止恶意操作者。对于操作员（了解一些知识）来说，从应用程序中提取密钥并产生自己的钱可能相当容易。