Java Card 2.2.2: temporary RSA public key as transient

Question

I'm designing a Java Card (2.2.2 thus Classic) applet that will, at each use, receive a RSA public key (validated using means immaterial to the question), then use that RSA public key to verify an RSA signature.

How can I keep that RSA public key in RAM (rather than writing it in EEPROM/Flash), for performance and device lifetime reasons ?

My problem is, in javacard.security.KeyBuilder of JC 2.2.2, the buildKey(byte keyType, short keyLength, boolean keyEncryption) API does not seem to have an option to specify transient memory; I see neither

a suitable keyType combining TYPE_RSA_PUBLIC and transcient, as we have with TYPE_DES_TRANSIENT_DESELECT;
not even TYPE_RSA_PRIVATE_TRANSIENT_DESELECT which conceivably could be abused into a public key (on platforms with no test for the size of d), for this is a novelty of Java Card Classic 3;
the buildKey(byte algorithmicKeyType, byte keyMemoryType, short keyLength, boolean keyEncryption) with a keyMemoryTypeparameter, which also is a novelty of Java Card Classic 3.

Would bracketing all changes and uses of my RSA public key with beginTransaction() and abortTransaction() achieve my goal?

@MaartenBodewes : Flagging this question to your attention as the resident Java Card expert. — fgrieu, Mar 09 '16 at 10:02
I guess java cards doesn't have TRANSIENT capability for RSA Key pairs because RSA long key sizes are too much for RAM limitations. (_A single RSA 2048 public key needs at least 2K of RAM!_) — Ebrahim Ghasemi, Mar 09 '16 at 12:37
@Abraham: your "2K of RAM" are [Kibibit](http://en.wikipedia.org/wiki/Kibibit), not [Kibibyte](https://en.wikipedia.org/wiki/Kibibyte). 256 bytes of RAM (plus a handful for the typical public exponent) is well within what Java Card TRANSIENT can hold. — fgrieu, Mar 09 '16 at 13:53

score 7 · Accepted Answer · answered Mar 09 '16 at 21:53

7

I have been dealing with exactly the same problem and had to use persistent memory and wear leveling (which worked).

Even had the same idea with beginTransaction()/abortTransaction(), but was told by the card manufacturer that this won't work (They said it would make things even worse regarding EEPROM lifetime). YMMV.

Some remarks:

The performance was sufficient for given use case (which surprised me).
Card lifetime can be estimated quite well (given you know how many re-write cycles the persistent memory has, it's block size, the frequency of different public key uses and wear leveling overhead).
Consider wear leveling both RSAPublicKey and Cipher objects together.
Use as much memory for object pool as you can.

There may be some vendor specific API which allows RSA computation (in our case there was no such possibility)

Good luck!

answered Mar 09 '16 at 21:53

vlp

7,811
2
23
51

Thanks for the spot-on field experience. On endurance; I have been told by a Java Card manufacturer that all writes to EEPROM go thru the same buffer and flags handling atomic writes, which is the bottleneck for guaranteed endurance; to the point that wear leveling in software would give low extra endurance on average, and little extra for the worst case in a large sample; or no bonus with a write countdown (that was not the case). It made sense. However, that was nearly a decade ago; now that EEPROM is often simulated by Flash with wear leveling, this reasoning might no longer apply. – fgrieu Mar 09 '16 at 22:06
1

@fgrieu Can't say much more than in this answer. 3.0 has improved this for a good reason. – Maarten Bodewes Mar 10 '16 at 00:34

Java Card 2.2.2: temporary RSA public key as transient

1 Answers1