7

I have smartcards by NXP that support ECC over GF(p) and that do not support ECC over GF(2^n).

In my project I need to use this particular type of smartcard (thousands of instances are used already). However, I need to add verification of EC signature over sect193r1, which is a curve over GF(2^n).

Performance is not an issue for me. It can take some time. Signature verification does not involve any private keys, so the security and key management are not issues, either. Unfortunately, I have to verify the signature inside my smartcard, not in the device equipped with smartcard reader.

Is there any solution? Is there any existing source code of a pure software JavaCard implementation of EC cryptography over GF(2^n)?

vojta
  • 5,591
  • 2
  • 24
  • 64
  • 2
    I would check first if both JCRE and Reader software implementations that you are using support an unlimited number of waiting extensions on the underlying 7816/14443 protocol layer as it will take almost for ever i guess – Paul Bastian Feb 12 '15 at 19:34
  • 1
    @PaulBastian Most implementations I see do have good WTX support nowadays, but I agree, that doesn't matter if it simply never returns :) – Maarten Bodewes Feb 13 '15 at 02:04
  • @MaartenBodewes Ok, that sounds very bad :-)... By "performance is not an issue" I meant something like "3 seconds are OK". Well, this seems to be a lost battle. Thanks for all replies! – vojta Feb 13 '15 at 19:49
  • The only real option is if there would be a way to escape the sandbox, but you would have to ask NXP if that's possible. – Maarten Bodewes Feb 13 '15 at 20:46

2 Answers2

3

Smart cards that are able to perform asymmetric cryptography always do this using a co-processor (that usually contains a Montgomery multiplier). Most smart cards (e.g. the initial NXP SmartMX processors) still operate using an 8 bit or 16 bit CPU. Those CPU's are not designed to perform operations on large numbers. Unfortunately Java Card doesn't provide direct support for calls to the multiplier - if that would be of use at all. Most cards (e.g. again the SmartMX) also don't support 32 bit (Java int) operations.

So if you want to perform such calculations you will have to program it yourself, using signed 8 bit and signed 16 bit primitives. This will require a lot of work and will be very slow. Add to this the overhead required to process Java byte-code and you will have an amazing amount of sluggishness.

Maarten Bodewes
  • 90,524
  • 13
  • 150
  • 263
  • 1
    GF(2) is polynomial arithmetic, where the co-processor designed for modular arithmetic is not overly useful. It may help to use some of its registers if the problem is RAM shortage, but I would surprised, if it can significantly contribute to the computation. Early Infineon SEL66 processors had a limited GF(2) co-processor. – guidot Feb 17 '15 at 08:22
  • Ah, thanks guidot, forgot about that. I'm strictly on F(p) myself. I presume you agree that this would not be fast on a 8 bit VM? – Maarten Bodewes Feb 17 '15 at 17:35
1

Just updating with some extra info in case someone is still looking for a solution.

The OpenCryptoJC lib indeed provides BigNumbers, EC curve primitive operations etc. So you should be able to load your own curve and its parameters.

However, if this curve is not supported natively by the card, you use the lib to implement the operations on the curve yourself. That's not-trivial though...

Alternatively, if there is any mapping between the GF(2^n) curve you want to use and another GF(p) you could try do all operations in GF(p) and them map the results back to GF(2^n). That could be easier to do assuming that there is such a mapping.

Disclaimer: I'm one of the lib authors. :)

Vasilios Mavroudis
  • 113
  • 2
  • 6