Request for object 5C017E in PIV

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

Request for object 5C017E in PIV

William Roberts
Having some issues deciphering an APDU its the NIST GET DATA command
with the data element set to BER-TLV 5C017E.

I generate this by issuing command:
$ piv-tool -A A:9B:07 -G 9A:07 -o foo

My question is, what container object is this associated with, I cant
find it in the PIV specs by Nist?

My card is returning 6A82 which is "Object Not Found"

Any help?

Thanks.

--
Respectfully,

William C Roberts

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request for object 5C017E in PIV

Douglas E Engert


On 6/19/2014 6:25 PM, William Roberts wrote:
> Having some issues deciphering an APDU its the NIST GET DATA command
> with the data element set to BER-TLV 5C017E.

Most likely that is a Discovery object, "7E", that is optional.
See NIST 800-73-3 part 2 Section 3.1.2 and
800-73-3 part 1 3.2.6 Discovery Object


I suspect that the APDU was:
00 CB 3F FF 03 5C 01 7E

Since the discovery object defines what pins can be used with the card,
the OpenSC tries to read it.

>
> I generate this by issuing command:
> $ piv-tool -A A:9B:07 -G 9A:07 -o foo

The -A option is for authenticate. It is vendor card specific.
Some use M some use A.

The 9B:07 would be a RSA 2048 key. All of the test cards I have used
use either 9B:01 (2des) or 9B:03(3des) Current OpenSC code may not handle
RSA for this. Check with your card vendor to see what is needed.


>
> My question is, what container object is this associated with, I cant
> find it in the PIV specs by Nist?
>
> My card is returning 6A82 which is "Object Not Found"

The discovery Object is optional.

>
> Any help?
>
> Thanks.
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request for object 5C017E in PIV

William Roberts
Thanks for the response, ahh Ive never seen a raw request for the
discovery object... normally I see requests come in like in table 6 sp
800_73-3_PART_1 where its show as the BER-TLV object in the APDU field
is:
'5FC102' for the CHUID. However only 0x7E for the discovery object...


RSA 2048 is preferred and supported by the card, but I can try tripple
des. This might explain why the code just error's out after the
unknown request as it cannot generate the next command apdu set to
send out as it cannot handle
RSA algorithm.




On Thu, Jun 19, 2014 at 8:12 PM, Douglas E Engert <[hidden email]> wrote:

>
>
> On 6/19/2014 6:25 PM, William Roberts wrote:
>> Having some issues deciphering an APDU its the NIST GET DATA command
>> with the data element set to BER-TLV 5C017E.
>
> Most likely that is a Discovery object, "7E", that is optional.
> See NIST 800-73-3 part 2 Section 3.1.2 and
> 800-73-3 part 1 3.2.6 Discovery Object
>
>
> I suspect that the APDU was:
> 00 CB 3F FF 03 5C 01 7E
>
> Since the discovery object defines what pins can be used with the card,
> the OpenSC tries to read it.
>
>>
>> I generate this by issuing command:
>> $ piv-tool -A A:9B:07 -G 9A:07 -o foo
>
> The -A option is for authenticate. It is vendor card specific.
> Some use M some use A.
>
> The 9B:07 would be a RSA 2048 key. All of the test cards I have used
> use either 9B:01 (2des) or 9B:03(3des) Current OpenSC code may not handle
> RSA for this. Check with your card vendor to see what is needed.
>
>
>>
>> My question is, what container object is this associated with, I cant
>> find it in the PIV specs by Nist?
>>
>> My card is returning 6A82 which is "Object Not Found"
>
> The discovery Object is optional.
>
>>
>> Any help?
>>
>> Thanks.
>>
>
> --
>
>   Douglas E. Engert  <[hidden email]>
>
>
> ------------------------------------------------------------------------------
> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
> Find What Matters Most in Your Big Data with HPCC Systems
> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
> http://p.sf.net/sfu/hpccsystems
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel



--
Respectfully,

William C Roberts

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request for object 5C017E in PIV

Douglas E Engert


On 6/19/2014 10:32 PM, William Roberts wrote:
> Thanks for the response, ahh Ive never seen a raw request for the
> discovery object... normally I see requests come in like in table 6 sp
> 800_73-3_PART_1 where its show as the BER-TLV object in the APDU field
> is:
> '5FC102' for the CHUID. However only 0x7E for the discovery object...

The Discovery Object appears to be some industry standard, for more then PIV.

>
>
> RSA 2048 is preferred and supported by the card, but I can try tripple
> des. This might explain why the code just error's out after the
> unknown request as it cannot generate the next command apdu set to
> send out as it cannot handle
> RSA algorithm.

Sounds like needs to be on the TODO list.


Who is the card vendor?
I have used Oberthur, some older GemAlto, and YubiKey NEO and a lot of
older cards from 8-10 years ago.

NOTE: The piv-tool was designed to allow a developer to create PIV test cards
using the commands defined in NIST 800-73-x. It does not have all the commands needed
to be the basis for a full card management system, as NIST left card management up to
the card vendors to define. These commands are usually in "confidential" documents
and may include Global platform commands. These are not added to the OpenSC code.
The pivtool -s option can be used to issue some of these if you have the vendor documents.

To get the -A option to work, you need the management key provided by the vendor
for the batch of cards when you buy them. Or the vendor provides a way to reset
the card, and the management key.

The YubiKey NEO has yubio-piv-tool to do some extra card management commands for
their card:

https://github.com/Yubico/yubico-piv-tool

>
>
>
>
> On Thu, Jun 19, 2014 at 8:12 PM, Douglas E Engert <[hidden email]> wrote:
>>
>>
>> On 6/19/2014 6:25 PM, William Roberts wrote:
>>> Having some issues deciphering an APDU its the NIST GET DATA command
>>> with the data element set to BER-TLV 5C017E.
>>
>> Most likely that is a Discovery object, "7E", that is optional.
>> See NIST 800-73-3 part 2 Section 3.1.2 and
>> 800-73-3 part 1 3.2.6 Discovery Object
>>
>>
>> I suspect that the APDU was:
>> 00 CB 3F FF 03 5C 01 7E
>>
>> Since the discovery object defines what pins can be used with the card,
>> the OpenSC tries to read it.
>>
>>>
>>> I generate this by issuing command:
>>> $ piv-tool -A A:9B:07 -G 9A:07 -o foo
>>
>> The -A option is for authenticate. It is vendor card specific.
>> Some use M some use A.
>>
>> The 9B:07 would be a RSA 2048 key. All of the test cards I have used
>> use either 9B:01 (2des) or 9B:03(3des) Current OpenSC code may not handle
>> RSA for this. Check with your card vendor to see what is needed.
>>
>>
>>>
>>> My question is, what container object is this associated with, I cant
>>> find it in the PIV specs by Nist?
>>>
>>> My card is returning 6A82 which is "Object Not Found"
>>
>> The discovery Object is optional.
>>
>>>
>>> Any help?
>>>
>>> Thanks.
>>>
>>
>> --
>>
>>    Douglas E. Engert  <[hidden email]>
>>
>>
>> ------------------------------------------------------------------------------
>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>> Find What Matters Most in Your Big Data with HPCC Systems
>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>> http://p.sf.net/sfu/hpccsystems
>> _______________________________________________
>> Opensc-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
>
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request for object 5C017E in PIV

William Roberts
Im the vendor of the smart card. Im writing the code myself.

The card management key is covered by object:
5FC10B

Is that correct?

Ill probably have to add support for the RSA 2048 into the piv-tool as
part of my work. I'll submit patches upstream, do you guys do github
requests or should
I send patches on the dev mailing list?

Thanks,
Bill

On Fri, Jun 20, 2014 at 6:01 AM, Douglas E Engert <[hidden email]> wrote:

>
>
> On 6/19/2014 10:32 PM, William Roberts wrote:
>>
>> Thanks for the response, ahh Ive never seen a raw request for the
>> discovery object... normally I see requests come in like in table 6 sp
>> 800_73-3_PART_1 where its show as the BER-TLV object in the APDU field
>> is:
>> '5FC102' for the CHUID. However only 0x7E for the discovery object...
>
>
> The Discovery Object appears to be some industry standard, for more then
> PIV.
>
>
>>
>>
>> RSA 2048 is preferred and supported by the card, but I can try tripple
>> des. This might explain why the code just error's out after the
>> unknown request as it cannot generate the next command apdu set to
>> send out as it cannot handle
>> RSA algorithm.
>
>
> Sounds like needs to be on the TODO list.
>
>
> Who is the card vendor?
> I have used Oberthur, some older GemAlto, and YubiKey NEO and a lot of
> older cards from 8-10 years ago.
>
> NOTE: The piv-tool was designed to allow a developer to create PIV test
> cards
> using the commands defined in NIST 800-73-x. It does not have all the
> commands needed
> to be the basis for a full card management system, as NIST left card
> management up to
> the card vendors to define. These commands are usually in "confidential"
> documents
> and may include Global platform commands. These are not added to the OpenSC
> code.
> The pivtool -s option can be used to issue some of these if you have the
> vendor documents.
>
> To get the -A option to work, you need the management key provided by the
> vendor
> for the batch of cards when you buy them. Or the vendor provides a way to
> reset
> the card, and the management key.
>
> The YubiKey NEO has yubio-piv-tool to do some extra card management commands
> for
> their card:
>
> https://github.com/Yubico/yubico-piv-tool
>
>
>>
>>
>>
>>
>> On Thu, Jun 19, 2014 at 8:12 PM, Douglas E Engert <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On 6/19/2014 6:25 PM, William Roberts wrote:
>>>>
>>>> Having some issues deciphering an APDU its the NIST GET DATA command
>>>> with the data element set to BER-TLV 5C017E.
>>>
>>>
>>> Most likely that is a Discovery object, "7E", that is optional.
>>> See NIST 800-73-3 part 2 Section 3.1.2 and
>>> 800-73-3 part 1 3.2.6 Discovery Object
>>>
>>>
>>> I suspect that the APDU was:
>>> 00 CB 3F FF 03 5C 01 7E
>>>
>>> Since the discovery object defines what pins can be used with the card,
>>> the OpenSC tries to read it.
>>>
>>>>
>>>> I generate this by issuing command:
>>>> $ piv-tool -A A:9B:07 -G 9A:07 -o foo
>>>
>>>
>>> The -A option is for authenticate. It is vendor card specific.
>>> Some use M some use A.
>>>
>>> The 9B:07 would be a RSA 2048 key. All of the test cards I have used
>>> use either 9B:01 (2des) or 9B:03(3des) Current OpenSC code may not handle
>>> RSA for this. Check with your card vendor to see what is needed.
>>>
>>>
>>>>
>>>> My question is, what container object is this associated with, I cant
>>>> find it in the PIV specs by Nist?
>>>>
>>>> My card is returning 6A82 which is "Object Not Found"
>>>
>>>
>>> The discovery Object is optional.
>>>
>>>>
>>>> Any help?
>>>>
>>>> Thanks.
>>>>
>>>
>>> --
>>>
>>>    Douglas E. Engert  <[hidden email]>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>>> Find What Matters Most in Your Big Data with HPCC Systems
>>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>>> http://p.sf.net/sfu/hpccsystems
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>>
>>
>>
>
> --
>
>  Douglas E. Engert  <[hidden email]>
>



--
Respectfully,

William C Roberts

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request for object 5C017E in PIV

Douglas E Engert


On 6/20/2014 10:47 AM, William Roberts wrote:
> Im the vendor of the smart card. Im writing the code myself.
>
> The card management key is covered by object:
> 5FC10B

No.

NIST 800-78-2 covers all the PIV crypto. Table 6-1 maps the PIV Key Type to the
Key reference.

Card Management Key  = 9B
Key Management Key   = 9D

NIST 800-73-3 part 1 table 2:
"X.509 Certificate for Key Management" is "5Fc10B" This certificate and matching 9D key
are used by the user for encryption, not for card management.

There is no matching certificate for the "Card Management Key" 9B.

NIST 800-78-2:
  Table 6-2. Identifiers for Supported Cryptographic Algorithms
  Table 6-3. PIV Card Keys: Key References and Algorithms

says (since 2010), 9B can be 3DES or AES-128,192 or 256 but not RSA.


Note every card should have a different 9B key. Vendors usually ship
a batch of cards with the same key. Part of the card management software would
be to change and save the key so a user could not modify the card.

>
> Is that correct?
>
> Ill probably have to add support for the RSA 2048 into the piv-tool as
> part of my work. I'll submit patches upstream, do you guys do github
> requests or should
> I send patches on the dev mailing list?

No, see above.

RSA is not used with the 9B key which is used when provisioning the card
with the piv-tool -A option
but the GENERAL AUTHENTICATE command can be used with RSA and ECDSA
when used by the user So no changes should be needed at this time.


NIST has drafts of 800-73-4 and 800-78-4 But the 9B key is still
3DES or AES.

http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-73--4

http://csrc.nist.gov/publications/drafts/800-78-4/sp800_78-4_revised_draft.pdf

See:
5 PIV Card Application Administration Keys


>
> Thanks,
> Bill
>
> On Fri, Jun 20, 2014 at 6:01 AM, Douglas E Engert <[hidden email]> wrote:
>>
>>
>> On 6/19/2014 10:32 PM, William Roberts wrote:
>>>
>>> Thanks for the response, ahh Ive never seen a raw request for the
>>> discovery object... normally I see requests come in like in table 6 sp
>>> 800_73-3_PART_1 where its show as the BER-TLV object in the APDU field
>>> is:
>>> '5FC102' for the CHUID. However only 0x7E for the discovery object...
>>
>>
>> The Discovery Object appears to be some industry standard, for more then
>> PIV.
>>
>>
>>>
>>>
>>> RSA 2048 is preferred and supported by the card, but I can try tripple
>>> des. This might explain why the code just error's out after the
>>> unknown request as it cannot generate the next command apdu set to
>>> send out as it cannot handle
>>> RSA algorithm.
>>
>>
>> Sounds like needs to be on the TODO list.

Spoke too soon. see above.


>>
>>
>> Who is the card vendor?
>> I have used Oberthur, some older GemAlto, and YubiKey NEO and a lot of
>> older cards from 8-10 years ago.
>>
>> NOTE: The piv-tool was designed to allow a developer to create PIV test
>> cards
>> using the commands defined in NIST 800-73-x. It does not have all the
>> commands needed
>> to be the basis for a full card management system, as NIST left card
>> management up to
>> the card vendors to define. These commands are usually in "confidential"
>> documents
>> and may include Global platform commands. These are not added to the OpenSC
>> code.
>> The pivtool -s option can be used to issue some of these if you have the
>> vendor documents.
>>
>> To get the -A option to work, you need the management key provided by the
>> vendor
>> for the batch of cards when you buy them. Or the vendor provides a way to
>> reset
>> the card, and the management key.
>>
>> The YubiKey NEO has yubio-piv-tool to do some extra card management commands
>> for
>> their card:
>>
>> https://github.com/Yubico/yubico-piv-tool
>>
>>
>>>
>>>
>>>
>>>
>>> On Thu, Jun 19, 2014 at 8:12 PM, Douglas E Engert <[hidden email]>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On 6/19/2014 6:25 PM, William Roberts wrote:
>>>>>
>>>>> Having some issues deciphering an APDU its the NIST GET DATA command
>>>>> with the data element set to BER-TLV 5C017E.
>>>>
>>>>
>>>> Most likely that is a Discovery object, "7E", that is optional.
>>>> See NIST 800-73-3 part 2 Section 3.1.2 and
>>>> 800-73-3 part 1 3.2.6 Discovery Object
>>>>
>>>>
>>>> I suspect that the APDU was:
>>>> 00 CB 3F FF 03 5C 01 7E
>>>>
>>>> Since the discovery object defines what pins can be used with the card,
>>>> the OpenSC tries to read it.
>>>>
>>>>>
>>>>> I generate this by issuing command:
>>>>> $ piv-tool -A A:9B:07 -G 9A:07 -o foo
>>>>
>>>>
>>>> The -A option is for authenticate. It is vendor card specific.
>>>> Some use M some use A.
>>>>
>>>> The 9B:07 would be a RSA 2048 key. All of the test cards I have used
>>>> use either 9B:01 (2des) or 9B:03(3des) Current OpenSC code may not handle
>>>> RSA for this. Check with your card vendor to see what is needed.
>>>>
>>>>
>>>>>
>>>>> My question is, what container object is this associated with, I cant
>>>>> find it in the PIV specs by Nist?
>>>>>
>>>>> My card is returning 6A82 which is "Object Not Found"
>>>>
>>>>
>>>> The discovery Object is optional.
>>>>
>>>>>
>>>>> Any help?
>>>>>
>>>>> Thanks.
>>>>>
>>>>
>>>> --
>>>>
>>>>     Douglas E. Engert  <[hidden email]>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
>>>> Find What Matters Most in Your Big Data with HPCC Systems
>>>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>>>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>>>> http://p.sf.net/sfu/hpccsystems
>>>> _______________________________________________
>>>> Opensc-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>
>>>
>>>
>>>
>>
>> --
>>
>>   Douglas E. Engert  <[hidden email]>
>>
>
>
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request for object 5C017E in PIV

William Roberts
On Fri, Jun 20, 2014 at 2:08 PM, Douglas E Engert <[hidden email]> wrote:

>
>
> On 6/20/2014 10:47 AM, William Roberts wrote:
>>
>> Im the vendor of the smart card. Im writing the code myself.
>>
>> The card management key is covered by object:
>> 5FC10B
>
>
> No.
>
> NIST 800-78-2 covers all the PIV crypto. Table 6-1 maps the PIV Key Type to
> the
> Key reference.
>
> Card Management Key  = 9B
> Key Management Key   = 9D
>
> NIST 800-73-3 part 1 table 2:
> "X.509 Certificate for Key Management" is "5Fc10B" This certificate and
> matching 9D key
> are used by the user for encryption, not for card management.
>
> There is no matching certificate for the "Card Management Key" 9B.

ok I see what you're saying. The 9B essentially maps to the private key
where the other BERTLV tag maps to the certificate.

>
> NIST 800-78-2:
>  Table 6-2. Identifiers for Supported Cryptographic Algorithms
>  Table 6-3. PIV Card Keys: Key References and Algorithms
>
> says (since 2010), 9B can be 3DES or AES-128,192 or 256 but not RSA.
>
>
> Note every card should have a different 9B key. Vendors usually ship
> a batch of cards with the same key. Part of the card management software
> would
> be to change and save the key so a user could not modify the card.

I was wondering what was done here, makes sense.

>
>
>>
>> Is that correct?
>>
>> Ill probably have to add support for the RSA 2048 into the piv-tool as
>> part of my work. I'll submit patches upstream, do you guys do github
>> requests or should
>> I send patches on the dev mailing list?
>
>
> No, see above.
>
> RSA is not used with the 9B key which is used when provisioning the card
> with the piv-tool -A option
> but the GENERAL AUTHENTICATE command can be used with RSA and ECDSA
> when used by the user So no changes should be needed at this time.
>
>
> NIST has drafts of 800-73-4 and 800-78-4 But the 9B key is still
> 3DES or AES.
>
> http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-73--4
>
> http://csrc.nist.gov/publications/drafts/800-78-4/sp800_78-4_revised_draft.pdf
>
> See:
> 5 PIV Card Application Administration Keys
>
>

Thanks.

>
>>
>> Thanks,
>> Bill
>>
>> On Fri, Jun 20, 2014 at 6:01 AM, Douglas E Engert <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On 6/19/2014 10:32 PM, William Roberts wrote:
>>>>
>>>>
>>>> Thanks for the response, ahh Ive never seen a raw request for the
>>>> discovery object... normally I see requests come in like in table 6 sp
>>>> 800_73-3_PART_1 where its show as the BER-TLV object in the APDU field
>>>> is:
>>>> '5FC102' for the CHUID. However only 0x7E for the discovery object...
>>>
>>>
>>>
>>> The Discovery Object appears to be some industry standard, for more then
>>> PIV.
>>>
>>>
>>>>
>>>>
>>>> RSA 2048 is preferred and supported by the card, but I can try tripple
>>>> des. This might explain why the code just error's out after the
>>>> unknown request as it cannot generate the next command apdu set to
>>>> send out as it cannot handle
>>>> RSA algorithm.
>>>
>>>
>>>
>>> Sounds like needs to be on the TODO list.
>
>
> Spoke too soon. see above.
>
>
>
>>>
>>>
>>> Who is the card vendor?
>>> I have used Oberthur, some older GemAlto, and YubiKey NEO and a lot of
>>> older cards from 8-10 years ago.
>>>
>>> NOTE: The piv-tool was designed to allow a developer to create PIV test
>>> cards
>>> using the commands defined in NIST 800-73-x. It does not have all the
>>> commands needed
>>> to be the basis for a full card management system, as NIST left card
>>> management up to
>>> the card vendors to define. These commands are usually in "confidential"
>>> documents
>>> and may include Global platform commands. These are not added to the
>>> OpenSC
>>> code.
>>> The pivtool -s option can be used to issue some of these if you have the
>>> vendor documents.
>>>
>>> To get the -A option to work, you need the management key provided by the
>>> vendor
>>> for the batch of cards when you buy them. Or the vendor provides a way to
>>> reset
>>> the card, and the management key.
>>>
>>> The YubiKey NEO has yubio-piv-tool to do some extra card management
>>> commands
>>> for
>>> their card:
>>>
>>> https://github.com/Yubico/yubico-piv-tool
>>>
>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Thu, Jun 19, 2014 at 8:12 PM, Douglas E Engert <[hidden email]>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 6/19/2014 6:25 PM, William Roberts wrote:
>>>>>>
>>>>>>
>>>>>> Having some issues deciphering an APDU its the NIST GET DATA command
>>>>>> with the data element set to BER-TLV 5C017E.
>>>>>
>>>>>
>>>>>
>>>>> Most likely that is a Discovery object, "7E", that is optional.
>>>>> See NIST 800-73-3 part 2 Section 3.1.2 and
>>>>> 800-73-3 part 1 3.2.6 Discovery Object
>>>>>
>>>>>
>>>>> I suspect that the APDU was:
>>>>> 00 CB 3F FF 03 5C 01 7E
>>>>>
>>>>> Since the discovery object defines what pins can be used with the card,
>>>>> the OpenSC tries to read it.
>>>>>
>>>>>>
>>>>>> I generate this by issuing command:
>>>>>> $ piv-tool -A A:9B:07 -G 9A:07 -o foo
>>>>>
>>>>>
>>>>>
>>>>> The -A option is for authenticate. It is vendor card specific.
>>>>> Some use M some use A.
>>>>>
>>>>> The 9B:07 would be a RSA 2048 key. All of the test cards I have used
>>>>> use either 9B:01 (2des) or 9B:03(3des) Current OpenSC code may not
>>>>> handle
>>>>> RSA for this. Check with your card vendor to see what is needed.
>>>>>
>>>>>
>>>>>>
>>>>>> My question is, what container object is this associated with, I cant
>>>>>> find it in the PIV specs by Nist?
>>>>>>
>>>>>> My card is returning 6A82 which is "Object Not Found"
>>>>>
>>>>>
>>>>>
>>>>> The discovery Object is optional.
>>>>>
>>>>>>
>>>>>> Any help?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>     Douglas E. Engert  <[hidden email]>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk
>>>>> Solutions
>>>>> Find What Matters Most in Your Big Data with HPCC Systems
>>>>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>>>>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>>>>> http://p.sf.net/sfu/hpccsystems
>>>>> _______________________________________________
>>>>> Opensc-devel mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>>
>>>   Douglas E. Engert  <[hidden email]>
>>>
>>
>>
>>
>
> --
>
>  Douglas E. Engert  <[hidden email]>
>



--
Respectfully,

William C Roberts

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request for object 5C017E in PIV

Douglas E Engert


On 6/20/2014 8:09 PM, William Roberts wrote:

> On Fri, Jun 20, 2014 at 2:08 PM, Douglas E Engert <[hidden email]> wrote:
>>
>>
>> On 6/20/2014 10:47 AM, William Roberts wrote:
>>>
>>> Im the vendor of the smart card. Im writing the code myself.
>>>
>>> The card management key is covered by object:
>>> 5FC10B
>>
>>
>> No.
>>
>> NIST 800-78-2 covers all the PIV crypto. Table 6-1 maps the PIV Key Type to
>> the
>> Key reference.
>>
>> Card Management Key  = 9B
>> Key Management Key   = 9D
>>
>> NIST 800-73-3 part 1 table 2:
>> "X.509 Certificate for Key Management" is "5Fc10B" This certificate and
>> matching 9D key
>> are used by the user for encryption, not for card management.
>>
>> There is no matching certificate for the "Card Management Key" 9B.
>
> ok I see what you're saying. The 9B essentially maps to the private key

the 9B is a asymmetric key, stored on both the card and the card management system
and used only by the card management system to update the card.

> where the other BERTLV tag maps to the certificate.

The tags really map to objects stored on the card, some contain certificates.
See NIST 800-3 part 1 Appendix A, and table 9 fpor one of the certificate objects.
The card internally does not make any association between the objects stored
on the card and any keys on the card.

Keys on the card are referred to by the key reference. 9A, 9B, 9C, 9D, 9E etc.

The generate key pair command generates an RSA or ECC key pair on the card and returns
the public key. This is the only time the card will return the public key.

Card management software then creates a certificate request, containing the public
key and has the card sign the request. When the CA returns a certificate it is
written to the card.

The card also does not store the public key as an object. It is in the certificate
so the PIV code in OpenSC will extract the public key from the certificate
and return to PKCS#11 or PKCS#15 a public key.

The card internally does not verify that the key in the certificate matches the
private key on the card. The card management system is responsible for keeping
these in sync.

To assist with the creation of a key pair, and signing a certificate request
the piv-tool and code in the libopensc can save the public key when a key pair
is generated. It can then return this externally stored public key if no
corresponding certificate is on the card, *AND* PIV_XX_KEY points a the external
pubkey.


See:
https://github.com/OpenSC/OpenSC/wiki/PivTool

I corrected the wiki page today":
"these correspond with ID: 1, 3, 4, 5"
now reads
"these correspond with ID: 1, 2, 3, 4"

>
>>
>> NIST 800-78-2:
>>   Table 6-2. Identifiers for Supported Cryptographic Algorithms
>>   Table 6-3. PIV Card Keys: Key References and Algorithms
>>
>> says (since 2010), 9B can be 3DES or AES-128,192 or 256 but not RSA.
>>
>>
>> Note every card should have a different 9B key. Vendors usually ship
>> a batch of cards with the same key. Part of the card management software
>> would
>> be to change and save the key so a user could not modify the card.
>
> I was wondering what was done here, makes sense.
>
>>
>>
>>>
>>> Is that correct?
>>>
>>> Ill probably have to add support for the RSA 2048 into the piv-tool as
>>> part of my work. I'll submit patches upstream, do you guys do github
>>> requests or should
>>> I send patches on the dev mailing list?
>>
>>
>> No, see above.
>>
>> RSA is not used with the 9B key which is used when provisioning the card
>> with the piv-tool -A option
>> but the GENERAL AUTHENTICATE command can be used with RSA and ECDSA
>> when used by the user So no changes should be needed at this time.
>>
>>
>> NIST has drafts of 800-73-4 and 800-78-4 But the 9B key is still
>> 3DES or AES.
>>
>> http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-73--4
>>
>> http://csrc.nist.gov/publications/drafts/800-78-4/sp800_78-4_revised_draft.pdf
>>
>> See:
>> 5 PIV Card Application Administration Keys
>>
>>
>
> Thanks.
>
>>
>>>
>>> Thanks,
>>> Bill
>>>
>>> On Fri, Jun 20, 2014 at 6:01 AM, Douglas E Engert <[hidden email]>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On 6/19/2014 10:32 PM, William Roberts wrote:
>>>>>
>>>>>
>>>>> Thanks for the response, ahh Ive never seen a raw request for the
>>>>> discovery object... normally I see requests come in like in table 6 sp
>>>>> 800_73-3_PART_1 where its show as the BER-TLV object in the APDU field
>>>>> is:
>>>>> '5FC102' for the CHUID. However only 0x7E for the discovery object...
>>>>
>>>>
>>>>
>>>> The Discovery Object appears to be some industry standard, for more then
>>>> PIV.
>>>>
>>>>
>>>>>
>>>>>
>>>>> RSA 2048 is preferred and supported by the card, but I can try tripple
>>>>> des. This might explain why the code just error's out after the
>>>>> unknown request as it cannot generate the next command apdu set to
>>>>> send out as it cannot handle
>>>>> RSA algorithm.
>>>>
>>>>
>>>>
>>>> Sounds like needs to be on the TODO list.
>>
>>
>> Spoke too soon. see above.
>>
>>
>>
>>>>
>>>>
>>>> Who is the card vendor?
>>>> I have used Oberthur, some older GemAlto, and YubiKey NEO and a lot of
>>>> older cards from 8-10 years ago.
>>>>
>>>> NOTE: The piv-tool was designed to allow a developer to create PIV test
>>>> cards
>>>> using the commands defined in NIST 800-73-x. It does not have all the
>>>> commands needed
>>>> to be the basis for a full card management system, as NIST left card
>>>> management up to
>>>> the card vendors to define. These commands are usually in "confidential"
>>>> documents
>>>> and may include Global platform commands. These are not added to the
>>>> OpenSC
>>>> code.
>>>> The pivtool -s option can be used to issue some of these if you have the
>>>> vendor documents.
>>>>
>>>> To get the -A option to work, you need the management key provided by the
>>>> vendor
>>>> for the batch of cards when you buy them. Or the vendor provides a way to
>>>> reset
>>>> the card, and the management key.
>>>>
>>>> The YubiKey NEO has yubio-piv-tool to do some extra card management
>>>> commands
>>>> for
>>>> their card:
>>>>
>>>> https://github.com/Yubico/yubico-piv-tool
>>>>
>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Jun 19, 2014 at 8:12 PM, Douglas E Engert <[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 6/19/2014 6:25 PM, William Roberts wrote:
>>>>>>>
>>>>>>>
>>>>>>> Having some issues deciphering an APDU its the NIST GET DATA command
>>>>>>> with the data element set to BER-TLV 5C017E.
>>>>>>
>>>>>>
>>>>>>
>>>>>> Most likely that is a Discovery object, "7E", that is optional.
>>>>>> See NIST 800-73-3 part 2 Section 3.1.2 and
>>>>>> 800-73-3 part 1 3.2.6 Discovery Object
>>>>>>
>>>>>>
>>>>>> I suspect that the APDU was:
>>>>>> 00 CB 3F FF 03 5C 01 7E
>>>>>>
>>>>>> Since the discovery object defines what pins can be used with the card,
>>>>>> the OpenSC tries to read it.
>>>>>>
>>>>>>>
>>>>>>> I generate this by issuing command:
>>>>>>> $ piv-tool -A A:9B:07 -G 9A:07 -o foo
>>>>>>
>>>>>>
>>>>>>
>>>>>> The -A option is for authenticate. It is vendor card specific.
>>>>>> Some use M some use A.
>>>>>>
>>>>>> The 9B:07 would be a RSA 2048 key. All of the test cards I have used
>>>>>> use either 9B:01 (2des) or 9B:03(3des) Current OpenSC code may not
>>>>>> handle
>>>>>> RSA for this. Check with your card vendor to see what is needed.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> My question is, what container object is this associated with, I cant
>>>>>>> find it in the PIV specs by Nist?
>>>>>>>
>>>>>>> My card is returning 6A82 which is "Object Not Found"
>>>>>>
>>>>>>
>>>>>>
>>>>>> The discovery Object is optional.
>>>>>>
>>>>>>>
>>>>>>> Any help?
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>      Douglas E. Engert  <[hidden email]>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk
>>>>>> Solutions
>>>>>> Find What Matters Most in Your Big Data with HPCC Systems
>>>>>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>>>>>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>>>>>> http://p.sf.net/sfu/hpccsystems
>>>>>> _______________________________________________
>>>>>> Opensc-devel mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>>    Douglas E. Engert  <[hidden email]>
>>>>
>>>
>>>
>>>
>>
>> --
>>
>>   Douglas E. Engert  <[hidden email]>
>>
>
>
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Request for object 5C017E in PIV

William Roberts
Thanks again doug. This clarified a lot for me, and greatly simplified
my understanding of the internal key mappings.

If I have any updates ill be sure to send them your way.

Bill

On Sat, Jun 21, 2014 at 7:23 AM, Douglas E Engert <[hidden email]> wrote:

>
>
> On 6/20/2014 8:09 PM, William Roberts wrote:
>>
>> On Fri, Jun 20, 2014 at 2:08 PM, Douglas E Engert <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On 6/20/2014 10:47 AM, William Roberts wrote:
>>>>
>>>>
>>>> Im the vendor of the smart card. Im writing the code myself.
>>>>
>>>> The card management key is covered by object:
>>>> 5FC10B
>>>
>>>
>>>
>>> No.
>>>
>>> NIST 800-78-2 covers all the PIV crypto. Table 6-1 maps the PIV Key Type
>>> to
>>> the
>>> Key reference.
>>>
>>> Card Management Key  = 9B
>>> Key Management Key   = 9D
>>>
>>> NIST 800-73-3 part 1 table 2:
>>> "X.509 Certificate for Key Management" is "5Fc10B" This certificate and
>>> matching 9D key
>>> are used by the user for encryption, not for card management.
>>>
>>> There is no matching certificate for the "Card Management Key" 9B.
>>
>>
>> ok I see what you're saying. The 9B essentially maps to the private key
>
>
> the 9B is a asymmetric key, stored on both the card and the card management
> system
> and used only by the card management system to update the card.
>
>
>> where the other BERTLV tag maps to the certificate.
>
>
> The tags really map to objects stored on the card, some contain
> certificates.
> See NIST 800-3 part 1 Appendix A, and table 9 fpor one of the certificate
> objects.
> The card internally does not make any association between the objects stored
> on the card and any keys on the card.
>
> Keys on the card are referred to by the key reference. 9A, 9B, 9C, 9D, 9E
> etc.
>
> The generate key pair command generates an RSA or ECC key pair on the card
> and returns
> the public key. This is the only time the card will return the public key.
>
> Card management software then creates a certificate request, containing the
> public
> key and has the card sign the request. When the CA returns a certificate it
> is
> written to the card.
>
> The card also does not store the public key as an object. It is in the
> certificate
> so the PIV code in OpenSC will extract the public key from the certificate
> and return to PKCS#11 or PKCS#15 a public key.
>
> The card internally does not verify that the key in the certificate matches
> the
> private key on the card. The card management system is responsible for
> keeping
> these in sync.
>
> To assist with the creation of a key pair, and signing a certificate request
> the piv-tool and code in the libopensc can save the public key when a key
> pair
> is generated. It can then return this externally stored public key if no
> corresponding certificate is on the card, *AND* PIV_XX_KEY points a the
> external
> pubkey.
>
>
> See:
> https://github.com/OpenSC/OpenSC/wiki/PivTool
>
> I corrected the wiki page today":
> "these correspond with ID: 1, 3, 4, 5"
> now reads
> "these correspond with ID: 1, 2, 3, 4"
>
>
>>
>>>
>>> NIST 800-78-2:
>>>   Table 6-2. Identifiers for Supported Cryptographic Algorithms
>>>   Table 6-3. PIV Card Keys: Key References and Algorithms
>>>
>>> says (since 2010), 9B can be 3DES or AES-128,192 or 256 but not RSA.
>>>
>>>
>>> Note every card should have a different 9B key. Vendors usually ship
>>> a batch of cards with the same key. Part of the card management software
>>> would
>>> be to change and save the key so a user could not modify the card.
>>
>>
>> I was wondering what was done here, makes sense.
>>
>>>
>>>
>>>>
>>>> Is that correct?
>>>>
>>>> Ill probably have to add support for the RSA 2048 into the piv-tool as
>>>> part of my work. I'll submit patches upstream, do you guys do github
>>>> requests or should
>>>> I send patches on the dev mailing list?
>>>
>>>
>>>
>>> No, see above.
>>>
>>> RSA is not used with the 9B key which is used when provisioning the card
>>> with the piv-tool -A option
>>> but the GENERAL AUTHENTICATE command can be used with RSA and ECDSA
>>> when used by the user So no changes should be needed at this time.
>>>
>>>
>>> NIST has drafts of 800-73-4 and 800-78-4 But the 9B key is still
>>> 3DES or AES.
>>>
>>> http://csrc.nist.gov/publications/PubsDrafts.html#SP-800-73--4
>>>
>>>
>>> http://csrc.nist.gov/publications/drafts/800-78-4/sp800_78-4_revised_draft.pdf
>>>
>>> See:
>>> 5 PIV Card Application Administration Keys
>>>
>>>
>>
>> Thanks.
>>
>>>
>>>>
>>>> Thanks,
>>>> Bill
>>>>
>>>> On Fri, Jun 20, 2014 at 6:01 AM, Douglas E Engert <[hidden email]>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 6/19/2014 10:32 PM, William Roberts wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Thanks for the response, ahh Ive never seen a raw request for the
>>>>>> discovery object... normally I see requests come in like in table 6 sp
>>>>>> 800_73-3_PART_1 where its show as the BER-TLV object in the APDU field
>>>>>> is:
>>>>>> '5FC102' for the CHUID. However only 0x7E for the discovery object...
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The Discovery Object appears to be some industry standard, for more
>>>>> then
>>>>> PIV.
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> RSA 2048 is preferred and supported by the card, but I can try tripple
>>>>>> des. This might explain why the code just error's out after the
>>>>>> unknown request as it cannot generate the next command apdu set to
>>>>>> send out as it cannot handle
>>>>>> RSA algorithm.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> Sounds like needs to be on the TODO list.
>>>
>>>
>>>
>>> Spoke too soon. see above.
>>>
>>>
>>>
>>>>>
>>>>>
>>>>> Who is the card vendor?
>>>>> I have used Oberthur, some older GemAlto, and YubiKey NEO and a lot of
>>>>> older cards from 8-10 years ago.
>>>>>
>>>>> NOTE: The piv-tool was designed to allow a developer to create PIV test
>>>>> cards
>>>>> using the commands defined in NIST 800-73-x. It does not have all the
>>>>> commands needed
>>>>> to be the basis for a full card management system, as NIST left card
>>>>> management up to
>>>>> the card vendors to define. These commands are usually in
>>>>> "confidential"
>>>>> documents
>>>>> and may include Global platform commands. These are not added to the
>>>>> OpenSC
>>>>> code.
>>>>> The pivtool -s option can be used to issue some of these if you have
>>>>> the
>>>>> vendor documents.
>>>>>
>>>>> To get the -A option to work, you need the management key provided by
>>>>> the
>>>>> vendor
>>>>> for the batch of cards when you buy them. Or the vendor provides a way
>>>>> to
>>>>> reset
>>>>> the card, and the management key.
>>>>>
>>>>> The YubiKey NEO has yubio-piv-tool to do some extra card management
>>>>> commands
>>>>> for
>>>>> their card:
>>>>>
>>>>> https://github.com/Yubico/yubico-piv-tool
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, Jun 19, 2014 at 8:12 PM, Douglas E Engert <[hidden email]>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 6/19/2014 6:25 PM, William Roberts wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Having some issues deciphering an APDU its the NIST GET DATA command
>>>>>>>> with the data element set to BER-TLV 5C017E.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Most likely that is a Discovery object, "7E", that is optional.
>>>>>>> See NIST 800-73-3 part 2 Section 3.1.2 and
>>>>>>> 800-73-3 part 1 3.2.6 Discovery Object
>>>>>>>
>>>>>>>
>>>>>>> I suspect that the APDU was:
>>>>>>> 00 CB 3F FF 03 5C 01 7E
>>>>>>>
>>>>>>> Since the discovery object defines what pins can be used with the
>>>>>>> card,
>>>>>>> the OpenSC tries to read it.
>>>>>>>
>>>>>>>>
>>>>>>>> I generate this by issuing command:
>>>>>>>> $ piv-tool -A A:9B:07 -G 9A:07 -o foo
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The -A option is for authenticate. It is vendor card specific.
>>>>>>> Some use M some use A.
>>>>>>>
>>>>>>> The 9B:07 would be a RSA 2048 key. All of the test cards I have used
>>>>>>> use either 9B:01 (2des) or 9B:03(3des) Current OpenSC code may not
>>>>>>> handle
>>>>>>> RSA for this. Check with your card vendor to see what is needed.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> My question is, what container object is this associated with, I
>>>>>>>> cant
>>>>>>>> find it in the PIV specs by Nist?
>>>>>>>>
>>>>>>>> My card is returning 6A82 which is "Object Not Found"
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The discovery Object is optional.
>>>>>>>
>>>>>>>>
>>>>>>>> Any help?
>>>>>>>>
>>>>>>>> Thanks.
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>      Douglas E. Engert  <[hidden email]>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> HPCC Systems Open Source Big Data Platform from LexisNexis Risk
>>>>>>> Solutions
>>>>>>> Find What Matters Most in Your Big Data with HPCC Systems
>>>>>>> Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
>>>>>>> Leverages Graph Analysis for Fast Processing & Easy Data Exploration
>>>>>>> http://p.sf.net/sfu/hpccsystems
>>>>>>> _______________________________________________
>>>>>>> Opensc-devel mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>    Douglas E. Engert  <[hidden email]>
>>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>>
>>>   Douglas E. Engert  <[hidden email]>
>>>
>>
>>
>>
>
> --
>
>  Douglas E. Engert  <[hidden email]>
>



--
Respectfully,

William C Roberts

------------------------------------------------------------------------------
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing & Easy Data Exploration
http://p.sf.net/sfu/hpccsystems
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel