Hi, while testing 2048 bit cards with various readers and various hash algorithms i notices that some card os cards of the same CA (in this case D-Trust) work different.
Both require code modifications to the card-cardos opensc driver. One card is D-Trust card 2.0 2cc and the other one is 2.0 2ca. Both are exactly the same (same flags, same caps, same ATR ..). Only the label is different. Both cards can neither do RSA_PURE_SIG nor RSA_SIG. The only work with the raw hash value, and cannot sign with the encryption key. Though there comes the problem: - The first card (2cc) always adds an SHA1 hash prefix to the date it is going to encrypt. It even does this when there is already a hash prefix before the data. Thus for this cards it is only possible to use SHA1 and to strip the SHA1 prefix (sign raw hash value only). So its not possible to sign other hashes than SHA1 with the 2cc card. - The second card (2ca) does not do this, so opensc must not strip the prefix. Any hash type can be signed with this card. I could produce a patch which supports both cards properly by doing string matching and adding some new flags to card os to disable certain parts of signature tries in card-cardos.c, but could this be the general solution? There should be a possibility to detect what type of data has to be sent to the card. Or if that is not possible, some better way to enable / disable code which is required for some card vendors, based on some kind of configuration file. I do not like to add all kinds of conditions to the code based of string compare to some card meta data. Best regards, Simon -- Simon Eisenmann [ mailto:[EMAIL PROTECTED] ] [ struktur AG | Kronenstraße 22a | D-70173 Stuttgart ] [ T. +49.711.896656.68 | F.+49.711.89665610 ] [ http://www.struktur.de | mailto:[EMAIL PROTECTED] ]
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
