PART I
Hi all,
I had posted a few weeks back as to how I was having trouble signing data with my Gemalto Cyberflex Access 64k v2 card.
Here is a link to that post:
9652818
I have had to invest considerable time and effort and now I have a better understanding of this problem. It seems to be a problem with this card and , therefore, anyone else using this card, please read and see if it behaves the same way for you.
First things first, this is a JC 2.1.1 card and does not support javacarx.crpto, and therefore I cannot encrypt/decrypt. At best, I can sign data and thats fine as my application ony needs to sign and verify.
I had been discussing with Shane on the above mentioned forum as to how this card signs exactly 20 bytes of data (no less, no more) when running the RSA_SHA1 algorithm.
To figure out more, I decided to code a program to encrypt and decrypt data(signs signing is only encrypting with a private key after hashing, etc). This program was coded entirely in Java and has nothing to do with JC. I initially had a feeling that my keys used on the JC may be wrong and thus made a program in Java to generate private/public keys that work perfectly, ie encrypt decrypt correctly. Now I use one of these keys that are known to work.
So, after generating these keys, I used the exact same keys in JC. I sent a dummy 20 bytes of data to JC for it to sign with the private key. I got the output in an APDU which I copied to my Java program and used the corresponding public key to decrypt this data. Upon decryption, I found the exact data that I had sent to the JC. This of course had been padded according to the specifiction given in ALG_RSA_SHA_PKCS1(http://www.cs.ru.nl/~woj/javacardapi221/javacard/security/Signature.html#init(javacard.security.Key, byte, byte[], short, short)
The main part is that the data was as is - not hashed at all. And this is why the card complains if you try to pass any data length that is less than or more than 20 bytes - It already expects a SHA1 hash and just pads that and encrypts with the private key. To further test this, I tried the RSA_MD5 algo - and that too only works with a 16 byta data payload - MD5 produces a 16 byte hash value which then the card expects.
In further tests, I checked with more input data (all 20 bytes of course) and each time I could successfully decrypt the output APDU on my JAVA code on my PC.
Futhermore, and this would of course be expected, I encrypted data after the requisite padding on my PC with the JAVA program and the encrypted data is identical to he signed data produced on the JC(SInce the JC essentially pads the data and encrypts it).
Anyone using this card, please let me know if you also can only sign 20 bytes. This is completely not expected if one were to go by the JC 2.1.1 API standard as signing involves hashing before encryption and therefore you can pass variable length data to it.