Hi Douglas, thanks for your infos.
The minidriver.c already ensures that the cardid file is always 16 byte. It does this by repeating the token serial number until 16 bytes are filled. We can ensure uniqueness of the serial number for our cards, but no uniqueness among all other card vendors. There remains a (very) little probability that a hexadecimal encoded serial number of another vendor's card resembles one of our ASCII serial numbers. Our serial numbers are based on the numbering scheme for machine readable travel documents, a 2 digit country code followed by up to 9 ASCII digits (e.g. UTTM1234567 equals 5554544D313233343536375554544D31 in cardid). Our proposed change (see [1]) will not alter the current behaviour with existing cards. It will just allow a card that uses a ASCII serial number to work as well. An alternative approach - and probably more invasive - would be to use the result of SC_CARDCTL_GET_SERIALNR in minidriver.c as input for the cardid file. This way we could still have our human readable serial number at the PKCS#11 und PKCS#15 level and a little more uniqueness in the cardid file. This will however break existing installations, as the content of the cardid file might change with the driver update. Andreas [1] https://github.com/CardContact/OpenSC/commit/724cdd06e23ecd2e822bd1f138d9c3fbdafe9324 Am 22.08.2012 16:29, schrieb Douglas E. Engert: > > On 8/22/2012 5:28 AM, Andreas Schwier (ML) wrote: >> Hi everyone, >> >> we've come across an issue with the minidriver which assumes the card >> serial number to be a hex string. >> >> In our card the serial number is a string composed of ASCII characters. >> This works well with pkcs15-tool and the PKCS#11 library, however it >> fails with the current minidriver when it tries to convert the hex >> string into binary data for the cardid file. >> >> Neither in PKCS#11 spec nor in ISO 7816-15 I can find a definition for >> encoding the serial number as hex string. > The minidriver does not use the PKCS#11 standards, it is the Microsoft > definition of what it expects in the cardid file that counts. > > http://www.microsoft.com/whdc/device/input/smartcard/sc-minidriver.mspx > > Section 5.4.1 says: > > "The logical name for this file is “CardId”. It is in the root directory." > > "The file is organized as a 16-byte array. It should be treated as opaque > binary data." > > "This value is assigned by Microsoft software to assure that a unique value > is > generated for the card. It is unrelated to the serial number that may or > may not > be assigned to the card during manufacture." > > In other places it calls it as a GUID. > > This also means that when displayed, it maybe displayed as a GUID as hex > digits > with "{", "}" "," and "-" added for readability, and some bytes reversed in > little > endian machines. So it may not be recognizable as your serial number. > > That said, since the minidriver is emulating a card that should have a cardid > file, > the data to populate the emulated cardid file has to come from the card and > be the same > at every use, and unique across all cards not just one site or one card > vendor. > > The value or its derivatives are stored in the certificate store and used > to associate cards with data previously cached. > >> I therefore propose to change the code in minidriver.c to do the following: >> >> 1. try parsing tokeninfo->serial_number as hex string >> 2. if that fails copy serial_number as is with the length being the >> length of the ASCII encoded string > It must be 16 bytes. > >> This should not interfere with current card drivers which all use a hex >> string as serial number. >> >> Any objections ? > If you can show that your method has enough uniqueness, to not cause problems > with other cards, then no. > >> Andreas >> -- --------- CardContact Software & System Consulting |.##> <##.| Andreas Schwier |# #| Schülerweg 38 |# #| 32429 Minden, Germany |'##> <##'| Phone +49 171 8334920 --------- http://www.cardcontact.de http://www.tscons.de http://www.openscdp.org _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
