2

I'm implementing data deciphering into my Java application using javax.smartcardio APIs. I'm using Yubikey NEO smart card element. I managed to:

  1. Select OpenPGP applet CW=9000.
  2. Present the right PIN to the applet CW=9000.
  3. Encrypt data using matching certificate using Bouncy Castle

The encrypted message is OK (or at lest usable). I successfully deciphered ASCII armored version of it it using gpg tool and the Yubikey.

I'm not able to replicate the same thing with Java.

  • My encrypted data length is 313 bytes
  • I'm sending two APDUs (Yubikey does not seem to support extended ones)
  • The result is CW=6f00

The key is 2048 bit long - I tried truncating the data to 256 bytes as mentioned in GPG source code but without any success.

The APDUs I'm using:

10 2a 80 86 ca 00 85 ..data.. d1 99 00 (208 bytes)    cw=9000
00 2a 80 86 70 0f e9 ..data.. 71 85 00 (118 bytes)    cw=6700
atok
  • 5,880
  • 3
  • 33
  • 62
  • It's context is but I expect the mistake to be mostly RSA related. – atok Nov 22 '15 at 14:41
  • It question would be welcome on stackoverflow. 6F00 (unknown error) is comparable with a runtime exception though, and the APDU's you are showing ends with 6700 (invalid length) so make sure you got your facts right. – Maarten Bodewes Nov 22 '15 at 14:42
  • Good catch. I got both in the process. Thank you. – atok Nov 22 '15 at 14:45
  • You are sending 0xCA+0x70=0x13A=314 data bytes in the composite APDU, not 313 bytes as stated. Also, I conjecture that removing the final 00 (Le) in the first command sent could only help (by removing the possibility that javax.smartcardio does a spurious Get Response). Disclaimer: I have no idea about what that INS=0x2a, P1=0x80, P2=0x86 APDU is supposed to mean to a Yubikey, much less what the 313 or 314 bytes you pass are, their formatting, or suitability. – fgrieu Nov 22 '15 at 21:31
  • 1
    Based on the document linked in your previous http://stackoverflow.com/questions/33841380/ you should be sending 1 byte padding indicator 00 for RSA per page 54 and the encrypted *part* (body octets after the first 10) of the Public-Key Encrypted Session Key Packet (identified by tag=1) which will be exactly the size of the RSA modulus (256 bytes for RSA-2048). – dave_thompson_085 Nov 22 '15 at 22:15
  • And while I'm at it, you should expect a successful response to contain 1 byte algorithm id, N bytes key for the symmetric cipher where N depends on the algorithm, and 2 bytes check value. – dave_thompson_085 Nov 22 '15 at 22:45
  • Any special reason to write *cw* instead of the much more common *sw1/sw2*? – guidot Nov 23 '15 at 10:12

0 Answers0