eJavaToken E5 Specifications

Card Products

Moderator: horse dream

Posts: 149
Joined: Tue Sep 27, 2016 10:58 am
Points :2042

eJavaToken E5 Specifications

Post by tay00000 » Fri Dec 20, 2019 10:14 am

I have been digging around the eJavaToken E5 and here are my summary of what I noticed in the E5.

Normal algorithms like AES, DES, RSA and ECDSA (SHA1 with ECDSA signature) are expected and thus are omitted from the above tests. The test is simply to find out unique functions and to make a note on it.

RAM: 1997 bytes (using code to query for 'JCSystem.getAvailableMemory' function)

Code sample that I used to query for RAM memory:

Code: Select all

short[] sb = JCSystem.makeTransientShortArray((short) 3, JCSystem.CLEAR_ON_RESET);
JCSystem.getAvailableMemory(sb, (short) 0, JCSystem.MEMORY_TYPE_TRANSIENT_RESET);
shortToBytes(sb[0], buffer, (short) 0);
shortToBytes(sb[1], buffer, (short) 2);
apdu.setOutgoingLength((short) 4);
apdu.sendBytes((short) 0, (short) 4);

Code: Select all

public static void shortToBytes(short s, byte[] b, short offset) {
    b[offset] = (byte) ((s >> 8) & 0xFF);
    b[(short) (offset + 1)] = (byte) (s & 0xFF);
EEPROM: - Not yet measured. Maybe later ....

Notable supported cryptographic algorithms:
- ECC KeyAgreement.ALG_EC_SVDP_DH
- ECC Signature.signPreComputedHash
- SM4
- SM2
- Korean SEED

All algorithms specified above are found via querying and attempting to create keys via the KeyBuilder and then generating keys and setting the keys successfully without exceptions to consider the algorithm as being supported.

The Signature.signPreComputedHash() method is very useful as it allows manually feeding a pre-computed hash (i.e. SHA256) in the event that SHA256 hash signature may not be available or if the user wants to create their own hash algorithm (i.e. Keccak/SHA3 with ECDSA).

Executing ECDH KeyAgreement with PLAIN shared secret output is not supported and this is abit of a problem because the default DH KDF only generates SHA-1 output of the shared secret (according to IEEE P1363) and that means the final shared secret only gives you 20 bytes of random secret key which if you are using AES-256, you will have to somehow derive the remaining 16 bytes of key on your own or you might have to do another ECDH KeyAgreement session again to give you another 20 bytes of secret key for you to use in your AES-256 secret key.

Thus, ECDH KeyAgreement with PLAIN will be much more preferred because it gives you more flexibility on how you derive and how much key data you can get out of a single KeyAgreement session. It will be nice if the KeyAreement.ALG_EC_SVDP_DH_PLAIN can be introduced for this purpose.

Overall, the E5 token has a pretty substantial set of cryptographic key algorithms and one can do a quite a lot of function with the E5. If one is to nitpick at the E5, the only real downside of the E5 is still the small ~ 2 KB memory which means the developer must manage the RAM memory very tightly and cleanly. Otherwise, the lack of ECDH PLAIN type support can be considered not really a big issue but something that is highly desirable to have.

More details on the E5 would be added here in the future.

Posts: 54
Joined: Mon Jul 20, 2015 1:08 pm
Points :510

Re: eJavaToken E5 Specifications

Post by ThePhoenyx » Thu Jan 02, 2020 11:22 am

If you want an easier way to check devices, in the opensource applets subforum is JCAlg which runs a *lot* of tests and can tell you pretty much anything you want to know about a device.
The world is full of stories;
And sometimes they permit themselves to be told.
~Cherokee Proverb

Post Reply Previous topicNext topic

Who is online

Users browsing this forum: No registered users and 4 guests

JavaCard OS : Disclaimer