Make CardOS 5.3 working with OpenSC

[Jakuje]

These commits make signatures and encryption with RSA mechanisms working with CardOS 5.3 cards.

The changes are isolated for the this specific version (based on ATR) so it will not affect any previous cards. But it can be that the older cards (CardOS 5.0) can work with the same attributes and therefore I would be glad for some testing and feedback before merging this change from other people who contributed to the earlier versions of CardOS driver. Especially @szikora @mtausig who touched the driver in recent years in context of CardOS 5.0 (but anyone else comments and testing would be appreciated).

Basic test case that can be used to verify functionality is attached in the following gist (RSA_X_509 will not work for CardOS 5.3 and this PR):
https://gist.github.com/Jakuje/5a993d2b2d8a9cac35203599e49e6831

[frankmorgner]

RSA-X-509 and RSA-PKCS are both (still) working with CardOS 4.3B.

However, I think we can live with the limitation you've introduced for 5.3 if nobody comes up with a clever solution.

[frankmorgner]

Please use an explicit test (e.g. in a switch statement) instead of assuming a specific order of the card types.

[Jakuje]

fixed. Thanks for having a look into that.

[Jakuje]

Browsing through the history of PRs, there is #283 from @martelletto who was trying to implement the CardOS 5.0 driver. His work was not publishable because of licencing, but hopefully he could either test/verify functionality or confirm some of our assumptions or give some pointers.
Also @DDvO claimed he has CardOS 5.0 card so he can also test and answer some of the questions.

[mtausig]

I changed job an haven't touched a CardOS card in almost 2 years. Sorry, I won't be much help here.

[martelletto]

I am in the same situation as @mtausig. Sorry.

[debrouxl]

I have a CardOS 5.0 card, connected through a Cherry USB SC reader. I've built OpenSC Git HEAD on Debian sid amd64, through apt-get source opensc, then replacing files from OpenSC Git, then the usual dpkg-buildpackage invocation.

I can confirm that your patches improve CardOS 5.0 support as well :)
I experience some issues, but not all of them seem to be related to CardOS support.

After installing the locally built package version:

• pkcs11-tool -O prints 5 objects contained in the SC: two public key objects, two certificate objects, and a data object containing a license, whose ID changes upon every invocation. OpenSC 0.16 (Debian opensc & opensc-pkcs11 0.16.0-3) is unable to print objects; I haven't tried other operations;
• I can retrieve the certificates as described in your Gist;
• I can't seem to sign or decrypt with RSA-PKCS or RSA-X-509, with or without padding: "error: PKCS11 function C_SignFinal failed: rv = CKR_DATA_INVALID (0x20)", "error: PKCS11 function C_Decrypt failed: rv = CKR_DATA_INVALID (0x20)". I haven't tried RSA-X509;
• also, other operations such as ssh-add -L, run when a gpg-agent is active with enabled SSH agent support, somehow interfere with pkcs11-tool's operation: after using that command, all pkcs11-tool -O and other commands can do is error out with "PKCS11 function C_GetSlotInfo failed: rv = CKR_DEVICE_ERROR (0x30)". To get back pkcs11-tool operation, I have to either unplug and plug back the SC reader (removing and putting back the SC is not enough), or kill + restart the GPG agent, so the issues may be elsewhere.

[Jakuje]

@debrouxl Thank you for testing. It looks like my expectations were confirmed (CardOS 5.0 implementation does not work with RSA_X_509) so we should update the flags accordingly for that card too unless we will find other solution (resolving license issues in #283 -- it would be sad we could not use that code since it is already done).
It would be also interesting to see if the P1=0x41 works the same way so we could simplify the code.

This PR was already merged so for further changes I would have to open new one with further simplifications. So far in the following commit:
Jakuje@7356ee7

The other improvements you talk about are most probably related to other changes since last stable release.

[debrouxl]

I can't seem to use RSA-PKCS either.

The fact that ssh-add -L interferes with e.g. pkcs11-tool -O, signaled by CKR_DEVICE_ERROR, is simply a consequence of the former locking the SC reader for its own use.

I'm more interested in GPG interoperability (for SSH) than in signing / validation / encryption / decryption with that SC. But at least, your changes have made it possible to obtain some information from the SC :)

[Jakuje]

Oh ... was reading too fast. My bad. Though the commit I referenced in the previous comment can solve the problems with RSA-PKCS signatures/decryption for you (verification would be appreciated).
The locking is probably expected as you already wrote.

[debrouxl]

I applied the P1=0x41 change, which was the sole relevant line from Jakuje@7356ee7 .
The outcome of pkcs11-tool -t -l on my CardOS 5.0 card is now much, much better :)
It matches your tests for CardOS 5.3: RSA_X_509 decryption is broken. For me, it produces a total of 256 bytes: 245 bytes of padding (?) garbage, followed by 0x00, then the original 10-byte cleartext.

Commands such as pkcs15-tool -D, pkcs15-tool -k --list-public-keys work as well.
Unfortunately, pkcs15-tool --read-public-key <keyid> and pkcs15-tool --read-ssh-key <keyid> do not:
Public key enumeration failed: Required ASN.1 object not found

In verbose mode:
pkcs15-tool -vvv --read-ssh-key <keyid>
shows that the APDU contains two bytes of leading garbage (maybe header ? It seems to be reproducible) "7F 49", before content whose format looks somewhat more usual:

Incoming APDU (273 bytes):
7F 49
82 01 0A 81 82 01 01 00
(256 bytes of key data)
82 03 01 00 01
90 00 (those two trailing bytes occur in multiple other APDUs coming from the card)

Maybe that 7F 49 garbage / header is a difference between CardOS 5.0 and CardOS 5.3 ?

[martelletto]

Hi @Jakuje,
Hi @debrouxl,

Can you contact me at pedro [at] ambientworks [dot] net? I may be able to help.

-p.

[Jakuje]

@debrouxl The trailing 90 00 are SW bytes (Status Words), where 90 00 means success in APDU. You usually need a context to see what the data means (the debug logs are saying how it is parsed, interpreted).

I am not able to retrieve public keys using pkcs15-tool from CardOS 5.3 either.

Unfortunately I don't have a lot of time to spend on that changes at the moment, but feel free to add me to the conversation at jakuje [at] gmail [dot] com if it is something that cant be said here (I saw your patch somewhere cached on github and it is very sad that it can not be used, though it can clear up some guesses we can have here).

[dengert]

@debrouxl
7F 49 is a 2 byte tag for public key. Several other cards handle this. Grep for 7F49 to see what they do.

You also said:
"It matches your tests for CardOS 5.3: RSA_X_509 decryption is broken. For me, it produces a total of 256 bytes: 245 bytes of padding (?) garbage, followed by 0x00, then the original 10-byte cleartext."

Sounds like that is what is expected. RSA_X_509 does a raw RSA operation using the private key. It expects key size input, and produces the key size output. Since you are passing in an encrypted data, the result would be the padding and the data. PKCS 1.5 padding uses random non zero bytes followed by the last byte of the padding of 0x00. Software is then expected to verify the padding.

When a card can do RSA_X_509 the same operation is used for both sign and decrypt, as the software for signing pad then has the card do RSA_X_509 and the result is a signature With decrypt the card does RSA_X_509 first, and retuerns tthe padding and data. The software then completes the decrypt by checking for valid padding and removing it.