时间戳

首页 > 解决方案 > 基于 NTAG213 与 Ultralight C 的支付应用程序（使用 Android NFC）

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

问题描述

我有一个（大学）项目，我基本上使用 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如您所见，我使用应用程序级加密来加密消息（也使用标签 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、Infineon Cipurse），这让我想知道我使用的技术（NTAG213 或 Ultralight C）是否足以存储某人的余额。您会（这是个人意见）说具有应用程序级加密和 32 位密码的 NTAG213 足以满足此类应用程序的需求吗？真正破坏其安全性需要多长时间？

标签： securityencryptionnfcpaymentmifare

解决方案

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

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

  • 用户不得通过在卡上设置任意余额来打印自己的钱。
  • 用户不能复制他们的卡，因此也不能复制他们的余额。
  • 用户不得通过在付款后将其卡恢复（回滚）到以前的余额来打印自己的钱。
  • 用户不得通过重播充值过程来打印自己的钱。
  • 用户不得在支付交易过程中通过撕卡来逃避支付。
  • 用户不得通过在充值过程中撕毁他们的卡来在他们的卡上生成任意（并且可能更高）的余额。

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

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

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

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

那么让我们看看 NTAG213 有哪些附加功能可以用来保护您的系统：

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

MIFARE Ultralight C 将添加以下内容：

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

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

往上看。这可能不是真的。

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

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

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

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

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

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

我看到一堆其他更安全的技术，这让我想知道我使用的技术是否足以存储某人的余额。

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

MIFARE Ultralight C 可能适用于一些预防措施。我肯定会避免在无人看管的情况下使用它，我可能会使用一个在线系统来跟踪余额并监控不一致。

任何使用对称加密并将加密密钥存储在终端中的东西肯定需要对恶意操作者采取预防措施。对于操作员（具有一定知识）来说，从应用程序中提取密钥并自己赚钱可能相当容易。

推荐阅读