CODEWITHSUNDEEP
javacryptographybouncycastlejavacardelliptic-curve
im_infamous
im_infamous

Reputation: 327

Add support for bouncycastle API to jCardSim

Now for javacard 2.2.2 there is no such emulator that supports elliptic curve points manipulation.

However, there is one emulator named jCardSim that delegates all crypto operations to Bouncycastle java library.

There are no clues on official site of how to add "proxy" bouncycastle API in order to use this in emulated applet.

So the goal is to upgrade this:

import javacard.framework.*;
import javacard.security.*;

to something like this: 

import javacard.framework.*;
import javacard.security.*;
import local.org.bouncycastle.math.ec.ECPoint;

Since the sources are freely available, there should be a way to rebuild certain emulator in order to provide ECPoint support for my applet. Of course, all this actions are required for applet testing before uploading it to card, that has native ECPoint support.

So, the question is: what exactly should I patch in order to achieve visiblity of bouncycastle API inside running applet?

Upvotes: 1

Views: 467

Answers (3)

Petr Svenda
Petr Svenda

Reputation: 61

An open-source implementation of ECPoint based only on public javacard API (no vendor-proprietary API) is available as part of JCMathLib library (together with Bignat and (Big-)Integer). JCMathLib runs both on real cards (requires native EC support KeyPair.ALG_EC_FP) as well as directly inside JCardSim simulator (as no non-standard API is required).

The potential drawback is a slower performance for some operations in comparison to vendor-proprietary API and lower resilience against side-channel and fault-induction attacks.

The advantage is portability between cards from different vendors and possibility to use JCardSim simulator instead of proprietary one.

Upvotes: 1

im_infamous
im_infamous

Reputation: 327

After a bit of work the solution was finished. Just a few clarifications before code

  1. ECPoint from Bouncycastle can not be imported "as is": there are two wrappers required. First one - to do high level tasks like point multiplication and addition(see ECOperation class). Second - some pure JavaCard class required in order to wrap hi-level construction for low level usage(see JCECC class).
  2. This integrated solution could not be more than test environment in jcardsim emulator. In order to back up ECPoint for hardware device then it's required to replace all jcardsim imports with token-specific imports (i.e. import com.licel.jcardsim.SESPAKE.JCECC; for instance import com.gemalto.javacard.gostservices.math.ECMathFp;) and ensure all API-provided functions are binded correctly within applet. Also .exp file will be needed to compile .cap file for corresponding device.

How this works:

  1. In order to apply the patch IDE should be set up this way and latest jcardsim source code version should be pulled out from repo.
  2. ECOperations class should be added to some jcardsim package. I've used crypto package in my sources.
  3. JCECC class should be added to some jcardsim package. I've used separate samples.SESPAKE package in my sources.
  4. Add some testing construction in applet just to verify all operations are ok:

private JCECC jcecc = new JCECC((short) 32); and then somewhere in process()

 jcecc.generatePointData();
 jcecc.multiplyBasepoint();
 byte[] Qpwx = { (byte) 0x9d,(byte) 0x33,(byte) 0x9b,(byte) 0x33,(byte) 0x96,(byte) 0xae,(byte) 0x4a,
                  (byte) 0x81,(byte) 0x63,(byte) 0x88,(byte) 0xa1,(byte) 0x4c,(byte) 0x79,(byte) 0xab,
                  (byte) 0x3a,(byte) 0x8d,(byte) 0xd4,(byte) 0x95,(byte) 0xfa,(byte) 0x4c,(byte) 0x53,
                  (byte) 0xf0,(byte) 0xd4,(byte) 0x07,(byte) 0x65,(byte) 0x79,(byte) 0x02,(byte) 0x2e,
                  (byte) 0xf2,(byte) 0xaa,(byte) 0xeb,(byte) 0x68 };
 byte[] Qpwy = { (byte) 0xda,(byte) 0xd9,(byte) 0x14,(byte) 0x82,(byte) 0xe2,(byte) 0x08,(byte) 0x59,
                  (byte) 0x0f,(byte) 0xd3,(byte) 0x16,(byte) 0xbf,(byte) 0x95,(byte) 0x94,(byte) 0x80,
                  (byte) 0xf5, (byte)0xec,(byte) 0x2c,(byte) 0x17,(byte) 0x46,(byte) 0x3e,(byte) 0xc8,
                  (byte) 0xfc,(byte) 0x8f,(byte) 0x63,(byte) 0x03,(byte) 0x06,(byte) 0x49,(byte) 0xb4,
                  (byte) 0x52,(byte) 0xcd,(byte) 0xdd,(byte) 0xa8 };
 jcecc.addPoints(jcecc.Qx, jcecc.Qy, Qpwx, Qpwy);
 Qpwx = jcecc.getRx();
 Qpwy = jcecc.getRy();

Sidenote

All these efforts might look really excessive: whoever needs this stuff when there is on-card ECDH support? Unfortunately, sometimes direct manipulation with EC poitns is the only way to implement protocols like SESPAKE in JavaCard.

Any feedback welcome.

Upvotes: 1

Maarten Bodewes
Maarten Bodewes

Reputation: 93948

You should not do this. Even if it is possible, you would expect that your Java Card doesn't handle int base type. Furthermore, the Bouncy API may well create objects, expect byte[] parameters and do all sorts of stuff that's not compatible with the idea of Java Card (classic).

Instead you should implement or extend the Java Card API for the functionality required, and then use Bouncy Castle to back it up.

Upvotes: 1

Related Questions