On 8/22/2012 10:09 AM, Andreas Schwier wrote: > 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.
Unfortunately that gives OpenbSC 16 bytes but does not improve the uniqunness. Fortunately the uniqueness today only needs to extend over all the cards as seen on a single machine which may be only a hand full. the cardid is not sent to AD for example. But it also means that if the certificates or keys on a card are changed, the cardid should also change. > > 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). You did not say what was the minimum number of digits are, and in you example the first 4 "ACSII digits" are letters not numbers that introduce more uniqueness then numbers. Also for a single machine would it always see the same country code? If you have 9 ASCII characters that should introduce enough uniqueness to avoid conflicts with your other cards and other vendors cards. One point I am trying to make is the cardid value is not really seen by the user, thus it does not have to be printable, and it could hold more uniqueness then a printable string. But if there is not enough unique data on the card to populate the cardid you have to use whatever you have. > > 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. On some cards whewre there is no serial readable form the card the SC_CARDCTL_GET_SERIALNR does similar tricts to come up with a "serial number" from what ever data it can use on the card. > This will however break existing installations, as the > content of the cardid file might change with the driver update. > Yes it might break existing installations, as it would look like a new card to the application, but with the same certificate on two cards. This could be an issue if Windows searches the cert store for a certificate, then asks the user to insert the matching card. i.e. the old card, not the new one. As long as you have 6 digits or characters in your printable string that should be fine. > 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 >>> > > -- 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
