Am Mittwoch, den 05.12.2007, 10:58 +0100 schrieb Ludovic Rousseau: > 2007/12/5, Simon Eisenmann <[EMAIL PROTECTED]>: > > 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. > > Adding a configuration flag is not a really good idea. You would have > to change the configuration file if you change the card from a "ca" to > a "cc". > > A dynamic/automatic support is far better (if possible). >
Ok thats true. So you would prefer having some more flags inside the code which are set based on runtime data (eg string compare of label etc). There is already such a comparison to detect cards which require to sign using the decrypt key (inside pkcs15.c search for "for cardos cards initialized by Siemens: sign with decrypt"). However this is not exactly beautiful imho, but seems to be the only way. I can make a patch which adds support for these cc and ca cards in a similar way, but there should be a central "put this kind of code here" place inside opensc for such conditions, as there might be multiple of them. For example the existing check on siemens initialized cardos cards is true for D-Trust 2.0 cards as well, but they cannot use the decrypt key for signing. Best regards -- 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
