JavaCard - ECC over GF(2^n) 的纯软件实现答案

【问题标题】：JavaCard - pure software implementation of ECC over GF(2^n)JavaCard - ECC over GF(2^n) 的纯软件实现
【发布时间】：2015-02-12 09:13:12
【问题描述】：

我有 NXP 的智能卡，支持 ECC over GF(p)，但不支持 ECC over GF(2^n)。

在我的项目中，我需要使用这种特殊类型的智能卡（已经使用了数千个实例）。但是，我需要在 sect193r1 上添加 EC 签名验证，这是一条 GF(2^n) 上的曲线。

性能对我来说不是问题。这可能需要一些时间。签名验证不涉及任何私钥，因此安全性和密钥管理也不是问题。不幸的是，我必须验证智能卡内的签名，而不是配备智能卡读卡器的设备。

有什么解决办法吗？是否有任何现有的纯软件 JavaCard 实现 EC 密码术 over GF(2^n) 的源代码？

【问题讨论】：

我会首先检查您使用的 JCRE 和 Reader 软件实现是否支持底层 7816/14443 协议层上无限数量的等待扩展，因为我猜这几乎永远都需要
@PaulBastian 现在我看到的大多数实现都具有良好的 WTX 支持，但我同意，如果它永远不会返回也没关系 :)
@MaartenBodewes 好的，这听起来很糟糕:-)...“性能不是问题”我的意思是“3 秒就可以”。好吧，这似乎是一场失败的战斗。感谢所有回复！
唯一真正的选择是是否有办法逃离沙箱，但你必须询问 NXP 是否有可能。

标签： security cryptography smartcard javacard

【解决方案1】：

能够执行非对称加密的智能卡始终使用协处理器（通常包含蒙哥马利乘法器）来执行此操作。大多数智能卡（例如最初的 NXP SmartMX 处理器）仍然使用 8 位或 16 位 CPU 运行。这些 CPU 的设计目的不是对大量数据执行操作。不幸的是，Java Card 不提供对乘法器调用的直接支持——如果这完全有用的话。大多数卡（例如 SmartMX）也不支持 32 位 (Java int) 操作。

因此，如果您想执行此类计算，您必须自己编程，使用带符号的 8 位和带符号的 16 位原语。这将需要大量工作并且会非常缓慢。再加上处理 Java 字节码所需的开销，您会感到非常缓慢。

【讨论】：

GF(2) 是多项式算术，其中为模块化算术设计的协处理器并不太有用。如果问题是 RAM 短缺，使用它的一些寄存器可能会有所帮助，但如果它可以显着促进计算，我会感到惊讶。早期的英飞凌 SEL66 处理器有一个有限的 GF(2) 协处理器。
啊，谢谢 guidot，忘记了。我自己严格使用 F(p)。我想你同意这在 8 位 VM 上不会很快？

【解决方案2】：

只是更新一些额外的信息，以防有人仍在寻找解决方案。

OpenCryptoJC 库确实提供了 BigNumbers、EC 曲线原语操作等。因此您应该能够加载自己的曲线及其参数。

但是，如果卡本身不支持此曲线，您可以使用 lib 自行实现对曲线的操作。不过，这不是微不足道的......

或者，如果您要使用的 GF(2^n) 曲线与另一个 GF(p) 之间存在任何映射，您可以尝试在 GF(p) 中执行所有操作，然后将结果映射回 GF(2 ^n)。假设有这样的映射，这可能更容易做到。

免责声明：我是lib 作者之一。 :)

【讨论】：