Hot questions for Using Applets in encryption

Question:

I am developing a JavaCard applet. Applet generates RSA public and private keys in constructor and with APDU command encrypt some byte array:

 public RSATestApplet() {
    keyPair = new KeyPair(KeyPair.ALG_RSA_CRT, KeyBuilder.LENGTH_RSA_2048);
    keyPair.genKeyPair();
    rsaPrivateKey = (RSAPrivateKey) keyPair.getPrivate();
    rsaPublicKey = (RSAPublicKey) keyPair.getPublic();

    cipher = Cipher.getInstance(Cipher.ALG_RSA_PKCS1, false);

    register();
}

And main method is:

private void encryptData(APDU apdu) {
    if (!rsaPublicKey.isInitialized()) {
        ISOException.throwIt(ISO7816.SW_CONDITIONS_NOT_SATISFIED);
    }
    byte[] apduBuffer = apdu.getBuffer();
    apdu.setIncomingAndReceive();

    cipher.init(rsaPrivateKey, Cipher.MODE_ENCRYPT);
    byte[] encryptedBuffer = new byte[apduBuffer.length];
    Util.arrayFillNonAtomic(encryptedBuffer, (short) 0,
            (short) encryptedBuffer.length, (byte) 0xAA);
    cipher.doFinal(encryptedBuffer, (short) 0, (short) encryptedBuffer.length, apduBuffer, (short) 0);
    // Just for testing send 120 bytes
    apdu.setOutgoingAndSend((short) 0, (short) 120);
}

And when I try to install applet APDU response is 6E00 (which means: No precise diagnosis).

I think problem may occurs when cipher.doFinal() is executing.

I tried with other applets and everything works fine.

I compile my applet with JavaCard 2.2.1 and Java 1.2

Do you have any idea what's going on?


Answer:

I strongly believe that the error you get during your installation of applet is not related to your encryptData method.

I would suggest you to use try catch inside your constructor to catch the exception thrown by JCVM. For example, when you create KeyPair object, it can throw an error if the algorithm and key length are not supported by the platform.

You can try something like this:

try {
     keyPair = new KeyPair(KeyPair.ALG_RSA, KeyBuilder.LENGTH_RSA_2048);
} catch (CryptoException e) {
     short reason = e.getReason();
     ISOException.throwIt(reason);
}

Question:

As browsers are ending the support for the plugin such as Applets, what are the alternatives for encrypting the text fields such as passwords in browser? Currently we are using applets to encrypt the password in text fields before sending to server.


Answer:

Depending on what your new implementation will be, JavaScript has the ability to encrypt text strings. Here are a few libraries:

(We still use this) https://code.google.com/archive/p/crypto-js/

This is a popular one by Stanford https://github.com/bitwiseshiftleft/sjcl

Question:

I have an applet (you can take a look at it there JavaCard applet is not working with RSA encryption). Applet generates RSA public and private keys in constructor and with APDU command encrypt some byte array.

Applet generates public and private keys with KeyBuilder.LENGTH_RSA_2048 in docs provided with cards sad that JavaCard supports 2048 bits key length only in DDA.

So question is what is DDA and SDA. Differences between them? And main question is: how to install (or run?) applet in this mode?

What I found out: Update 1: SDA -- Static Data Authentication DDA -- Dynamic Data Authentication


Answer:

So question is:

what is DDA and SDA. Differences between them?

SDA - SDA ensures the authenticity of ICC data. After SDA it is sure that the data from the ICC is real and hasn't changed by anyone. But SDA doesn't assure the uniqueness of ICC data. You can see the diagram of SDA is like,

Here you can see two RSA Pair is using during SDA, (1) - IssuerRSA

(2) - CA_RSA

this diagram is very descriptive and clear to understand the flow of SDA. Also you can check EMV BOOK 2 for more description about SDA. while DDA flow is like ,

here you can see 3 RSA Pair is using in DDA,

1 - IssuerRSA

2- CA_RSA

3 - ICC RSA ( new RSA key which is unique in all card, Each card generate this RSA pair during personalization of card so this RSA Pair will be different for each card)

SDA guarantees that data on cards is valid because we trust a high level certification authority which signs the data. But an attacker can record a card session and build for example a new virtuel card because same data is used here for all session.

But in DDA flow - we can say it is checking SDA + giving random data to card by Terminal to sign and here this part makes cloning of card impossible because each session use different random number so recording a card session will not work in next card session.

hope it helps and more can you read from SDA and DDA , Gemalto