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）进行加密之前将其写入标记（AES-256使用＆com; scottyab加密：aescrypt： 0.0.1＆＃39;库 - 一个非常大的密码密钥，它也使用标签UID作为其一部分。）

到目前为止一直很好 - 只有我能理解标签上的数据。

在我的研究中，我发现在安全性方面，Ultralight C＆gt; NTAG213。

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

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

问题3）我可以在此类代码上使用哪些其他安全措施来强制执行安全措施（代码和应用程序层）？

问题4）当你比较标签安全性（MIFARE DESFire＆gt; Ultralight＆gt; NTAG213＆gt; MIFARE Classic）时，真正被比较的是什么？在未经许可的情况下，很容易破解（本机标签）加密或标签上的一个商店（任何东西）的易用性？

问题5）我看到一些更安全的其他技术（MIFARE DESFire，ICODE SLIX，Infineon Cipurse），这让我想知道我使用的技术（NTAG213）或超轻C）足以存储某人的平衡。你（以及那个人的意见）会说NTAG213具有应用级加密和32位密码，足以满足这类应用吗？一个人真正打破其安全需要多长时间？

Answer 1

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

首先，＆＃34;更安全＆＃34;取决于您的实际保护目标。既然您想在卡上存储余额（现金钱！），您可能希望（至少）保护以实现以下目标：

用户不得通过在卡片上设置任意余额来打印自己的钱。
用户必须无法复制他们的卡片，因此才能重复他们的余额。
用户必须无法通过在付款后将其卡片恢复（回滚）到之前的余额来打印自己的钱。
用户必须无法通过重播充值程序来打印自己的钱。
在付款交易期间，用户不得通过撕毁卡来逃避付款。
用户必须在充值过程中撕掉卡片，才能在卡片上产生任意（可能更高）的余额。

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

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

让我们来看看你的应用程序级加密＆＃34;增加了安全性：

由于用户不知道加密密钥，因此他们可能无法在卡上生成任意余额。但是，这在很大程度上取决于您的余额格式（以未加密的形式）。用户可以对密文进行任意修改，结果为＆＃34; random＆＃34;纯文本的修改。因此，尽管加密，用户仍可以修改余额值。数字签名/消息身份验证代码是您可能想要克服此问题的路径。
由于加密密钥（假设加密足够，可能不是）取决于标签的UID，因此您可以安全地克隆卡（+余额）。但是，请注意UID只是一个可自由读取的标识符。它本身并不是经过验证的，也可能是可克隆的。见Serials on NFC Tags - truly unique? cloneable?。
加密值不会保护您免受用户在付款后将余额恢复为之前记录的值。之前已发现此类漏洞（特别是在基于MIFARE Ultralight的系统中），例如，请参阅Benninger, C., Sobell, M. (2012): NFC for free rides and rooms (on your phone). In: Presentation at EUSecWest 2012。
由于您在充值过程中写入了完整的值（即没有特定的＆＃34;增量余额＆＃34;命令），您可以安全地反对用户重播充值（滚动除外）回到这方面）。
如果您的系统仅允许参与付款/充值，则撕裂的影响可能相当有限。

因此，让我们看看NTAG213可以用来保护系统的其他功能：

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

MIFARE Ultralight C会添加以下内容：

可以使用OTP字节。如果它是一个使标签可以一次性使用的选项（即它们以只能从中扣除而不是加满的特定余额开始），那么使用OTP字节来表示余额将是一个选项。请注意，还有很多事情你可以做错，例如Beccaro, M., Collura, M. (2013): OTP circumventing in MIFARE ULTRALIGHT: Who says free rides?. In: Presentation at DEFCON 21
身份验证得到了很大改善。 3DES认证方案似乎足够安全，以防止嗅探密钥。但是，读/写命令也不以加密方式绑定到身份验证步骤。因此，攻击者可能能够让真正的支付终端+正版标签执行身份验证，但将读/写重定向到其他地方。这可能（尤其）在无人看管的情况下会出现问题。

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

见上文。这可能不是真的。

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

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

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

事实并非如此。 NTAG213有一个32位密码。 MIFARE Ultralight C使用更复杂的2K-3DES认证机制和112位密钥。

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

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

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

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

MIFARE Ultralight C可能适合采取一些预防措施。我绝对不会在无人值守的情况下使用它，我可能会使用在线系统跟踪平衡并监控不一致性。

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

Answer 2

我猜你的问题太宽泛了，并不是所有的子问题，这部分SO都是最合适的。

通过专注于加密强度，你会错过一些东西：如果令牌的低级别安全性很容易被攻击，那么没有人需要破解你的密钥。

简单转储和稍后恢复（在付款后）对应于打印钱
如果令牌直接包含钱（而不是仅识别存储在后台系统中的钱包），则需要一个更安全的系统来避免经济损失。这涉及动态加密的通信，但仍有大量的进一步主题。

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

2 个答案: