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.

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
                              ^^^^^^^

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.

>
> 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.

>

-- 

  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

Reply via email to