On 4/4/2011 11:58 AM, Viktor TARASOV wrote: > Le 04/04/2011 17:39, Douglas E. Engert a écrit : >> On 4/4/2011 4:09 AM, Viktor TARASOV wrote: >>> Le 30/03/2011 18:38, Viktor TARASOV a écrit : >>>> What would you say if we accept the 'classic' GUID form as a default one, >>>> and give the possibility to define its own format to the pkcs15 card >>>> driver ? >>>> A new sc_pkcs15_operations callback will be used: >>>> http://www.opensc-project.org/opensc/browser/trunk/src/libopensc/pkcs15.h#L462 >>>> >>>> If no objections I'll prepare the patch. >>> After more reflexions it seems that I've got the reason of these debates -- >>> PIV card is believed to not have the source of the trusted uniqueness to >>> build the key-container identifier with the length of 16 bytes . >> Correct. >> >>> The 16 bytes of the PIV card's serial is believed to not contain the random >>> of sufficient length (15 bytes to satisfy the OpenSC-PIV and 13 bytes for >>> W7-PIV ). >>> (IMHO some sha1() over the serial would solve the problem, but, ... ) >> The "serial" number is derived from the FASC-N, and the leading bits are >> agency-code, >> and the lowest bits are something like an employee number. So the >> concatenate operation >> ends up dropping the lowest bits of the employee number. >> >> You asked how I know how Microsoft generated the ContainerID for PIV in >> their driver... >> On 3/28 in an E-mail I outlined how this was observed. >> >> On a test card, opensc-tool shows the serial number as: >> 6B 8E 7A C9 1D D2 11 B2 B7 19 00 14 4F 1F 5E F4 >> This is the value contained in the CHUID. >> >> The FASCN is a packed 4-bit+parity string of 40 digits and control codes, >> and is 25 bytes. If the CHUID agency code is 9999, and a GUID is >> present in the CHUID, the GUID will be used as a serial number as 16 bytes. >> This is a feature to allow the cards to be used by non-US-government >> Google for "PIV-Compatible" >> >> In the case of the test card, the GUID was used with 16 byte serial number. > > You mean the GUID where there are at least 15 random(digest) bytes (as it > explained by RFC 4122) ?
Yes. The PIV-Compatible defines a GUID in the CHUID. These would be non-US-gov issued cards. The test cards I generate used the Solaris 10 /usr/bin/makeuuid to generate a GUID. The FASCN then starts with 9999. But the real US-gov issued cards have a FASCN that is 25 bytes long, and the GUID is 30303030303030303030303030303030 on many of these cards. http://www.idmanagement.gov/documents/PIV_IO_NonFed_Issuers_May2009.pdf See Section 2.3. for a discussion on GUID and FASCN. Google for piv-compatible Card Management to see some security companies that appear to be using PIV cards in the PIV-compatible mode. The goal I have for PIV in OpenSC is not to issue cards but to allow both government and non-government issued cards to be used. So the FASCN derived serial is still a problem, both for OpenSC and Microsoft. > > >> On Vista with OpenSC r5272 the key container is: >> >> Key Container = {016B8E7A-C91D-D211-B2B7-1900144F1F5E} >> which drops the last byte of the serial number. >> The leading 01 is the cert ID. >> >> On W7 using Microsoft driver certutil shows: >> Key Container = c97a8e6b-d21d-b211-b719-00144f5fc105 >> >> Microsoft is treating the serial as a UUID with a format of >> typedef struct _GUID { >> DWORD Data1; >> WORD Data2; >> WORD Data3; >> BYTE Data4[8]; >> } GUID; >> >> So when the convert to character on a little endian machine >> the Data1, Data2 and Data3 are byte reversed. So >> 6B8E7AC9 1DD2 11B2 B719 001441F5EF4 becomes >> >> c97a8e6b-d21d-b211-b719-001441f5ef4 >> They then overlay the last 3 bytes from NIST 800-73 Table 6 >> "Object Identifiers of the PIV Data Objects for Interoperable Use" >> >> 5FC105 is the identifier for the Authentication certificate. >> Thus using: >> c97a8e6b-d21d-b211-b719-00144f5fc105 >> ^^^^^^^ > > On 4/2 in an E-mail I already asked this question. > > 15 random bytes in GUID (PIV's serial) > minus 3 bytes of predefined tag (5FC105), > results in the 12 random bytes that the key-container identifier contains. > > Considering that key-container identifiers are not used outside the given > post, > do you think that collision probability should be seriously taken into > account by W7-PIV ? > GUID based serial number would not be a big problem. but FASCN might. Or in other words, What is the probability of two users with cards which have similar FASCN numbers using the same computer? I would say its low > > >> With a real PIV card with a FASCN derived serial number, which is 25 bytes >> the first 13 bytes are used. >>> Other cards can use for this purpose the intrinsic identifier (that is in >>> fact the sha1()). >> OK then truncating a sha1 from 20 to 16 is still fairly unique, and would >> not be an issue. >> Updating the chart, to include PIV UUID and FASCN based serial numbers gives: Card ID Serial Min Max Meaning Min Max UUID? PIV 1 1 Same 25 25 No, using FASCN PIV-Compatible 1 1 Same 16 16 Should be UUID PIV-W7 3 3 Same 25 25 No, using FASCN PIV-W7-Compatible 3 3 Same 16 16 Should be UUID IAS/ECC 20 20 Unique 10 10 there is no UUID RutokenECP 20 20 Unique 8 8 there is no UUID AuthentIC 20 20 Unique 4 4 there is no UUID Oberthur 20 20 Unique 4 4 there is no UUID WestCOS* 20 20 Unique 8 8 there is no UUID * if it used default pkcs15.profile settings >>> I don't think that we should bring these fears and doubts into the >>> minidriver itself and try to resolve them on this level. >>> It's up to the card specific level to supply the unique GUID and for this >>> purpose the 'guid' pkcs15 callback is proposed. >>> This callback could have some default implementation. >>> For this default method I would propose to use an intrinsic ID as a source >>> of uniqueness, but without any insistence. >> The code in r5271 is better then what Microsoft is doing for PIV. >> They may catch on that their containerID is not as unique as it >> should be. >> >> So r5271 looks as good as it is going to get for now, if the only >> card that is going to have an issue is the PIV. On W7 I would expect >> that the opensc-minidriver will not be used for PIV. >> >> If you provide the callback I will look at using it with the PIV code. > > OK, thanks. > > -- 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
