Secure Key exchange using javacard applet

I am working on a javacard applet project where i need...

1. Secure communication between two applets let say there is applet A and applet B. Let say both applet has their own RSA key pairs.
2. Now I want to perform Diffie-Hellman key exchange between these applet.So that both applet can talk securely.

How to perform above mentioned functionality if anyone can also suggest other than this where two applets can communicate by using asymmetric crypto.

Any help on this topic will be highly appreciated.

• Can you use libraries and if so can you just use a TLS library? – SEJPM Oct 16 '15 at 11:46
• @SEJPM TLS library not available for JAVA card. – Anurag Sharma Oct 16 '15 at 12:12
• @otus i want to know any asymmetric cipher mechanism so that 2 java card applet can communicate securely.Just like SCP02 but SCP02 is symmetric. – Anurag Sharma Oct 16 '15 at 12:14
• @SEJPM: a lot of what you know about Java does not apply to Java Card (Classic branch, the Connected branch has fossilized). Usual things are not done with the usual API, when they can be done at all. There's no int type (only short) on any JCRE that I ever used, making it impossible to run virtually any existing Java code without changes of type and adding casts. By default all objects live in EEPROM or Flash, which can only be written a limited number of times, and require milliseconds for a change. RAM is very limited (like few kilobytes). – fgrieu Oct 16 '15 at 12:51
• It is essential that you obtain the full version(s) name and number(s) of the Java Card API(s) that you want to support, and the subset of function parameters available on the target hardware (as it is extremely common that only a subset of the crypto parameters defined for a given API version is implemented on a particular platform, and that varies widely). In particular: you want to know if your platform(s) supports the KeyAgreement class [reposted with fixed link]. – fgrieu Oct 16 '15 at 12:55

You can use ephemeral Diffie-Hellman and then use RSA to authenticate the parameters and established key seed the same way as TLS does. Java Card implementations usually contain an implementation of ECDH key agreement. An advantage is that you don't need very large key sizes to be reasonably secure. Furhtermore, ECDH operation and key pair generation is plenty fast.

Note that Java Card 3.0.5 contains enhancements both with regards to Diffie-Hellman as well as handling Elliptic Curves and parameters in RAM. Furthermore implementations may contain authenticated ciphers making it easier to define your own efficient secure messaging channel.

[Historical] This is however probably only of concern to future readers, as I don't think any 3.0.5 implementations are out yet.

By now there should be 3.0.5 implementations available.

Both RSA and DH have a similarity which is the Modulus Exponential (modexp) function (RSA encrypt/decrypt function). Since both RSA and DH uses the same modexp function, you can make full use of the Cipher for ALG_RSA_NOPAD in JavaCard's crypto API.

I have sat down and taken time to adapt the RSA crypto functions for traditional non-ECC type of DH functions and you can find the open source applet code here (https://github.com/ASKGLab/DHApplet/blob/master/src/dhapplet/DH.java).

I have not yet done up the APDU commands to create a full fledge demo but I guess if you study the DH.java codes, it should be more than enough to give you a head start. I have included a ton of commends in the source code on how to adapt it to different scenarios and the thought process as well when designing the entire DH class and it's significance.

• have you tested your code on real card? – Anurag Sharma Feb 2 '16 at 11:40
• You can script a call to the APDUs. You need to call in sequence INS_INIT on the card to start the smart card's DH key generation and computing card's initial public value. Follow up, call GET_Y to get card's initial public value and do the host side keygen which you call the SET_Y to set the host side public values and finalize the card side with a INS_FINAL for card side to finalize it's shared secret and call a GET_Y again to retrieve card's side final public values and host side finalizes it's shared secret. Finally, calling a INS_TEST would encrypt a hard-coded test reply for testing. – thotheolh Feb 5 '16 at 4:04
• Diffie-Hellman desktop Java testing application can be found at github.com/ASKGLab/SCDHTestHostSide to verify if the applet is working. – thotheolh Oct 3 '16 at 9:34