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 > -- Douglas E. Engert <deeng...@anl.gov> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 _______________________________________________ opensc-devel mailing list opensc-devel@lists.opensc-project.org http://www.opensc-project.org/mailman/listinfo/opensc-devel
