On 1/9/2012 2:36 PM, Anders Rundgren wrote:
> Hi Douglas,
> Thanx for the extensive answer!
>
> You may find it odd but the origin to this question is not about
> using PIV cards but about the possibility emulating PIV commands
> in an SKS (Secure Key Store) device to leverage the huge work
> performed by you and others.

OK, so all the concerns about vendor initializing/provisioning
of the card are not an issue, as you are the vendor. Not having
SM to the card should not be in issue either.

Thank NIST for developing, publishing the standards and verifying
compliance with the standards:
   http://csrc.nist.gov/groups/SNS/piv/index.html

There is even some sample code for a card there.

You may also want to look at:
  http://fips201ep.cio.gov/apl.php
to see if there are similar products to what you want to develop.

>
> However, there may be another card standard that would be better
> but I'm really only helped by emulating a mainstream card,
> whatever mainstream means in this space :-)

This list may not want to hear this, but Windows 2008 and W7 have
a Microsoft PIV driver, so in the option of many, that makes
PIV main-stream.


>
> Regards
> Anders
>
> On 2012-01-09 17:21, Douglas E. Engert wrote:
>>
>>
>> On 1/7/2012 9:29 AM, Anders Rundgren wrote:
>>> Hi,
>>> I'm not particularly familiar with PIV but from the spec it seems that
>>> a PIV card supports 1-3 user certificates selected by some kind of index.
>>
>> The NIST 800-73 documents define the PIV card and the 4 basic certificates.
>> (and  newer cards can have 20 more certificates and keys, see below.)
>> See 800-73-3 part 1 in these sections:
>>     3.1.3 X.509 Certificate for PIV Authentication
>>     3.2.3 X.509 Certificate for Digital Signature
>>     3.2.4 X.509 Certificate for Key Management
>>     3.2.5 X.509 Certificate for Card Authentication
>>
>> see list of documents:
>>    http://csrc.nist.gov/publications/PubsSPs.html
>>
>> Basically:
>>    one cert/key for web or logon authentication
>>    one cert/key to sign E-mail and other documents
>>    one cert/key to encrypt/decrypt e-mail or other documents
>>    and one cert/key for the card to authenticate itself to others.
>>
>> They each have a specific purpose. The key for the Certificate
>> for Digital Signature enforces CKA_ALWAYS_AUTHENTICATE on the card.
>>    The key for the Certificate for Card Authentication does not
>> require a PIN as its intent is to authenticate the card, not the user.
>> If the card also supports contactless access there are some other
>> differences as well.
>>
>> So yes it does support more then one certificate/key, but for specific
>> purposes, with specific on card security rules for each key.
>>
>> There is no real "Index". The OpenSC driver uses 01, 02, 03...
>> but these are not on the card. What the card does support are
>> OIDs, and the objects on the card including objects that
>> contain the above certificates and defined in 800-73-3 part 1
>> table 2. The BER-LTV values are sent to the card as part of
>> a GET DATA our PUT DATA command. (Table 1 and 6 defines some
>> container IDs for some backward comparability, but these are not
>> sent to the card. (The OpenSC pkcs15-piv.c uses these for pkcs15
>> emulation.)
>>
>>>
>>> Lets say that I rather wanted 10 certificates, would drivers out there
>>> be able to cope with that?
>>
>> Also new with 800-73-3 are 20 more certificates and keys for retired Key
>> Management certificates and keys. Section 3.2.7 Key History Object
>> describes these. So it might be possible to use these for your extra
>> certificates.
>>
>> OpenSC 0.12.2 processes the Key History Object and can use these
>> certificates and keys. And since the key usage is defined in
>> the certificate, and all RSA operations to the card
>> use RAW mode thecard does not really have any way to enforce
>> the key usage. (With EC keys, it might be different.)
>>
>> Note the PIV does not contain intermediate CA certs either,
>> but one of these key history objects certs could be used
>> as long as the caller does not try and use the key that
>> would not be present.
>>
>> The PIV specifications do not define all the card management commands
>> needed and each vendor may have their own, so initializing these
>> or adding certificates and keys may be a problem with some cards.
>>
>> It also appears that a card does not check the contents of object
>> written to the card. This might change in the future.
>>
>> Many of the objects (on an officially issued card) would be signed.
>> For PKCS#11/minidriver purposes, checking of the signatures on an
>> object is up to the calling application. OpenSC can read the objects,
>> but only uses the cert objects (and keys) and the CHUID object,
>> if present, to derive a serial number. (The Microsoft PIV driver
>> in Window 7 requires the CHUID, to get the serial number)
>> Both OpenSC and Microsoft do not require the CHUID to be signed today.
>>
>>>
>>> I understand that this is outside of the actual PIV specification but I do
>>> believe that some people have experimented with additional certificates
>>> to not have to carry yet another card.
>>
>> Another approach is to have a second application on some Global Platform
>> card that also has a PIV Application.
>>
>> The PIV really does not define a card, but an application on a card.
>> There are a dozen approved PIV card vendors. The PIV SELECT command is an
>> ISO-7816 Select File command with the PIV AID.
>>
>> The intent of the PIV was to have U.S. Gov agencies issues the cards.
>> The military has for years had the CAC cards, and newer cards are
>> now dual CAC and PIV cards, so this approach is being used today.
>>
>>>
>>> thanx,
>>> Anders
>>> _______________________________________________
>>> opensc-devel mailing list
>>> opensc-devel@lists.opensc-project.org
>>> http://www.opensc-project.org/mailman/listinfo/opensc-devel
>>>
>>>
>>
>
>

-- 

  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