Adding support for AES General Auth

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

Adding support for AES General Auth

William Roberts
I am currently adding support for AES for general AUTH. I currently am
at this check in card-piv.c

if ( (*q++ != 0x7C)
|| (*q++ != rbuflen - 2)
|| (*q++ != 0x81)
|| (*q++ != rbuflen - 4)) {

This assumes that the response data can be represented in a single
byte length field for the TLVs, which is not always the case. Some of
the cards I have return 256 bytes of challenge data plus meta data.

I would like to change this to actually properly parse the nested
reponse TLV's, however, I am looking for some tlv parsing code in the
code base and have struck out. So the question is, do you have any
code for parsing nested tlv's?

FYI current status is that it sends to the card, gets the response via
multiple get response requests and then dies here. I added support
into the entry point to handle different key sizes and algortihms.


--
Respectfully,

William C Roberts

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding support for AES General Auth

Douglas E Engert


On 7/8/2014 3:47 PM, William Roberts wrote:

> I am currently adding support for AES for general AUTH. I currently am
> at this check in card-piv.c
>
> if ( (*q++ != 0x7C)
> || (*q++ != rbuflen - 2)
> || (*q++ != 0x81)
> || (*q++ != rbuflen - 4)) {
>
> This assumes that the response data can be represented in a single
> byte length field for the TLVs, which is not always the case.  Some of
> the cards I have return 256 bytes of challenge data plus meta data.
>
> I would like to change this to actually properly parse the nested
> reponse TLV's, however, I am looking for some tlv parsing code in the
> code base and have struck out. So the question is, do you have any
> code for parsing nested tlv's?

The card-piv.c does a lot of simple TLV like the above, and also more
complicated scans using  sc_asn1_find_tag() 23 times. This allows for
nested values, which can be large, like a certificate. The

>
> FYI current status is that it sends to the card, gets the response via
> multiple get response requests and then dies here. I added support
> into the entry point to handle different key sizes and algortihms.

1426 /*
1427  * will only deal with 3des for now
1428  * assumptions include:
1429  *  size of encrypted data is same as unencrypted
1430  *  challenges, nonces etc  from card are less then 114 (keeps tags simple)
1431  */
1432
1433 static int piv_general_mutual_authenticate(sc_card_t *card,
1434         unsigned int key_ref, unsigned int alg_id)

So the tag processing does need to be updated to use sc_asn1_find_tag.
and sbuf need to be bigger. rbuf defaults to 0 to use 4096 in piv_general_io.


The alg_id parameter of  piv_general_mutual_authenticate defines the algortihm
and key size, as defined in NIST 800-78 Table 6-2. (older versions define "04")
08, 0A and 0C are AES 128, 192, 256 ECB


Are you looking at NIST 800-73-3 or the draft 800-73-4?

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding support for AES General Auth

William Roberts
On Tue, Jul 8, 2014 at 4:10 PM, Douglas E Engert <[hidden email]> wrote:

>
>
> On 7/8/2014 3:47 PM, William Roberts wrote:
>> I am currently adding support for AES for general AUTH. I currently am
>> at this check in card-piv.c
>>
>> if ( (*q++ != 0x7C)
>> || (*q++ != rbuflen - 2)
>> || (*q++ != 0x81)
>> || (*q++ != rbuflen - 4)) {
>>
>> This assumes that the response data can be represented in a single
>> byte length field for the TLVs, which is not always the case.  Some of
>> the cards I have return 256 bytes of challenge data plus meta data.
>>
>> I would like to change this to actually properly parse the nested
>> reponse TLV's, however, I am looking for some tlv parsing code in the
>> code base and have struck out. So the question is, do you have any
>> code for parsing nested tlv's?
>
> The card-piv.c does a lot of simple TLV like the above, and also more
> complicated scans using  sc_asn1_find_tag() 23 times. This allows for
> nested values, which can be large, like a certificate. The
>

Thanks thats what I was missing, I was grepping for tlv and only found some
definitions from internal-winscard.h

>>
>> FYI current status is that it sends to the card, gets the response via
>> multiple get response requests and then dies here. I added support
>> into the entry point to handle different key sizes and algortihms.
>
> 1426 /*
> 1427  * will only deal with 3des for now
> 1428  * assumptions include:
> 1429  *  size of encrypted data is same as unencrypted
> 1430  *  challenges, nonces etc  from card are less then 114 (keeps tags simple)
> 1431  */
> 1432
> 1433 static int piv_general_mutual_authenticate(sc_card_t *card,
> 1434         unsigned int key_ref, unsigned int alg_id)
>
> So the tag processing does need to be updated to use sc_asn1_find_tag.
> and sbuf need to be bigger. rbuf defaults to 0 to use 4096 in piv_general_io.

I didn't hit any of these limits yet AFAIK. I re-worked a lot of the
key logic to escape the
hardcodes of 3des key sizes.

>
>
> The alg_id parameter of  piv_general_mutual_authenticate defines the algortihm
> and key size, as defined in NIST 800-78 Table 6-2. (older versions define "04")
> 08, 0A and 0C are AES 128, 192, 256 ECB
>
>
> Are you looking at NIST 800-73-3 or the draft 800-73-4?

800-73-3. I am currently testing with algorithm 0C - AES 256 ECB

Patches will come from me soon. I'll be disapearing on vacation soon
but will be back to finish them.

Do you want me to to the github pull request or send patches via the
mailing list?

>
> --
>
>   Douglas E. Engert  <[hidden email]>
>
>
> ------------------------------------------------------------------------------
> Open source business process management suite built on Java and Eclipse
> Turn processes into business applications with Bonita BPM Community Edition
> Quickly connect people, data, and systems into organized workflows
> Winner of BOSSIE, CODIE, OW2 and Gartner awards
> http://p.sf.net/sfu/Bonitasoft
> _______________________________________________
> Opensc-devel mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel



--
Respectfully,

William C Roberts

------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding support for AES General Auth

Douglas E Engert


On 7/8/2014 6:21 PM, William Roberts wrote:

> On Tue, Jul 8, 2014 at 4:10 PM, Douglas E Engert <[hidden email]> wrote:
>>
>>
>> On 7/8/2014 3:47 PM, William Roberts wrote:
>>> I am currently adding support for AES for general AUTH. I currently am
>>> at this check in card-piv.c
>>>
>>> if ( (*q++ != 0x7C)
>>> || (*q++ != rbuflen - 2)
>>> || (*q++ != 0x81)
>>> || (*q++ != rbuflen - 4)) {
>>>
>>> This assumes that the response data can be represented in a single
>>> byte length field for the TLVs, which is not always the case.  Some of
>>> the cards I have return 256 bytes of challenge data plus meta data.
>>>
>>> I would like to change this to actually properly parse the nested
>>> reponse TLV's, however, I am looking for some tlv parsing code in the
>>> code base and have struck out. So the question is, do you have any
>>> code for parsing nested tlv's?
>>
>> The card-piv.c does a lot of simple TLV like the above, and also more
>> complicated scans using  sc_asn1_find_tag() 23 times. This allows for
>> nested values, which can be large, like a certificate. The
>>
>
> Thanks thats what I was missing, I was grepping for tlv and only found some
> definitions from internal-winscard.h
>
>>>
>>> FYI current status is that it sends to the card, gets the response via
>>> multiple get response requests and then dies here. I added support
>>> into the entry point to handle different key sizes and algortihms.
>>
>> 1426 /*
>> 1427  * will only deal with 3des for now
>> 1428  * assumptions include:
>> 1429  *  size of encrypted data is same as unencrypted
>> 1430  *  challenges, nonces etc  from card are less then 114 (keeps tags simple)
>> 1431  */
>> 1432
>> 1433 static int piv_general_mutual_authenticate(sc_card_t *card,
>> 1434         unsigned int key_ref, unsigned int alg_id)
>>
>> So the tag processing does need to be updated to use sc_asn1_find_tag.
>> and sbuf need to be bigger. rbuf defaults to 0 to use 4096 in piv_general_io.
>
> I didn't hit any of these limits yet AFAIK. I re-worked a lot of the
> key logic to escape the
> hardcodes of 3des key sizes.
>
>>
>>
>> The alg_id parameter of  piv_general_mutual_authenticate defines the algortihm
>> and key size, as defined in NIST 800-78 Table 6-2. (older versions define "04")
>> 08, 0A and 0C are AES 128, 192, 256 ECB
>>
>>
>> Are you looking at NIST 800-73-3 or the draft 800-73-4?
>
> 800-73-3. I am currently testing with algorithm 0C - AES 256 ECB
>
> Patches will come from me soon. I'll be disapearing on vacation soon
> but will be back to finish them.
>
> Do you want me to to the github pull request or send patches via the
> mailing list?

github pull requests would work.


>
>>
>> --
>>
>>    Douglas E. Engert  <[hidden email]>
>>
>>
>> ------------------------------------------------------------------------------
>> Open source business process management suite built on Java and Eclipse
>> Turn processes into business applications with Bonita BPM Community Edition
>> Quickly connect people, data, and systems into organized workflows
>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>> http://p.sf.net/sfu/Bonitasoft
>> _______________________________________________
>> Opensc-devel mailing list
>> [hidden email]
>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>
>
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding support for AES General Auth

William Roberts
I currently have some messy patches for handling AES algo's for
general_auth command and larger nonces. However, the response to the
card is not done yet. Im hung up on the best way to format the
encrypted challenge to go back to the card.

We need to send 2 TLVs, one nested inside the other like so:
7C<len>[81<len><enc challenge>]

The existing code didn't handle the multiple length fields, so I am
looking through the asn1 routines since that's where the decode
operations were. I am looking at asn1_encode_entry() to encode this up
but I have 2 questions:
1. Is that even the function I want?
2. Its not clear to me how to use the function?

Any help?

Thanks

On Tue, Jul 8, 2014 at 5:12 PM, Douglas E Engert <[hidden email]> wrote:

>
>
> On 7/8/2014 6:21 PM, William Roberts wrote:
>>
>> On Tue, Jul 8, 2014 at 4:10 PM, Douglas E Engert <[hidden email]>
>> wrote:
>>>
>>>
>>>
>>> On 7/8/2014 3:47 PM, William Roberts wrote:
>>>>
>>>> I am currently adding support for AES for general AUTH. I currently am
>>>> at this check in card-piv.c
>>>>
>>>> if ( (*q++ != 0x7C)
>>>> || (*q++ != rbuflen - 2)
>>>> || (*q++ != 0x81)
>>>> || (*q++ != rbuflen - 4)) {
>>>>
>>>> This assumes that the response data can be represented in a single
>>>> byte length field for the TLVs, which is not always the case.  Some of
>>>> the cards I have return 256 bytes of challenge data plus meta data.
>>>>
>>>> I would like to change this to actually properly parse the nested
>>>> reponse TLV's, however, I am looking for some tlv parsing code in the
>>>> code base and have struck out. So the question is, do you have any
>>>> code for parsing nested tlv's?
>>>
>>>
>>> The card-piv.c does a lot of simple TLV like the above, and also more
>>> complicated scans using  sc_asn1_find_tag() 23 times. This allows for
>>> nested values, which can be large, like a certificate. The
>>>
>>
>> Thanks thats what I was missing, I was grepping for tlv and only found
>> some
>> definitions from internal-winscard.h
>>
>>>>
>>>> FYI current status is that it sends to the card, gets the response via
>>>> multiple get response requests and then dies here. I added support
>>>> into the entry point to handle different key sizes and algortihms.
>>>
>>>
>>> 1426 /*
>>> 1427  * will only deal with 3des for now
>>> 1428  * assumptions include:
>>> 1429  *  size of encrypted data is same as unencrypted
>>> 1430  *  challenges, nonces etc  from card are less then 114 (keeps tags
>>> simple)
>>> 1431  */
>>> 1432
>>> 1433 static int piv_general_mutual_authenticate(sc_card_t *card,
>>> 1434         unsigned int key_ref, unsigned int alg_id)
>>>
>>> So the tag processing does need to be updated to use sc_asn1_find_tag.
>>> and sbuf need to be bigger. rbuf defaults to 0 to use 4096 in
>>> piv_general_io.
>>
>>
>> I didn't hit any of these limits yet AFAIK. I re-worked a lot of the
>> key logic to escape the
>> hardcodes of 3des key sizes.
>>
>>>
>>>
>>> The alg_id parameter of  piv_general_mutual_authenticate defines the
>>> algortihm
>>> and key size, as defined in NIST 800-78 Table 6-2. (older versions define
>>> "04")
>>> 08, 0A and 0C are AES 128, 192, 256 ECB
>>>
>>>
>>> Are you looking at NIST 800-73-3 or the draft 800-73-4?
>>
>>
>> 800-73-3. I am currently testing with algorithm 0C - AES 256 ECB
>>
>> Patches will come from me soon. I'll be disapearing on vacation soon
>> but will be back to finish them.
>>
>> Do you want me to to the github pull request or send patches via the
>> mailing list?
>
>
> github pull requests would work.
>
>
>
>>
>>>
>>> --
>>>
>>>    Douglas E. Engert  <[hidden email]>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Open source business process management suite built on Java and Eclipse
>>> Turn processes into business applications with Bonita BPM Community
>>> Edition
>>> Quickly connect people, data, and systems into organized workflows
>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>> http://p.sf.net/sfu/Bonitasoft
>>> _______________________________________________
>>> Opensc-devel mailing list
>>> [hidden email]
>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>
>>
>>
>>
>
> --
>
>  Douglas E. Engert  <[hidden email]>
>



--
Respectfully,

William C Roberts

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding support for AES General Auth

William Roberts
On Thu, Jul 24, 2014 at 3:05 PM, William Roberts
<[hidden email]> wrote:

> I currently have some messy patches for handling AES algo's for
> general_auth command and larger nonces. However, the response to the
> card is not done yet. Im hung up on the best way to format the
> encrypted challenge to go back to the card.
>
> We need to send 2 TLVs, one nested inside the other like so:
> 7C<len>[81<len><enc challenge>]
>
> The existing code didn't handle the multiple length fields, so I am
> looking through the asn1 routines since that's where the decode
> operations were. I am looking at asn1_encode_entry() to encode this up
> but I have 2 questions:
> 1. Is that even the function I want?
> 2. Its not clear to me how to use the function?
>

I think I finally stumbled into what I was looking for:

put_tag_and_len(0xAC, out_len, &p);

memcpy(p, outdata, out_len);
p+=out_len;

> Any help?
>
> Thanks
>
> On Tue, Jul 8, 2014 at 5:12 PM, Douglas E Engert <[hidden email]> wrote:
>>
>>
>> On 7/8/2014 6:21 PM, William Roberts wrote:
>>>
>>> On Tue, Jul 8, 2014 at 4:10 PM, Douglas E Engert <[hidden email]>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On 7/8/2014 3:47 PM, William Roberts wrote:
>>>>>
>>>>> I am currently adding support for AES for general AUTH. I currently am
>>>>> at this check in card-piv.c
>>>>>
>>>>> if ( (*q++ != 0x7C)
>>>>> || (*q++ != rbuflen - 2)
>>>>> || (*q++ != 0x81)
>>>>> || (*q++ != rbuflen - 4)) {
>>>>>
>>>>> This assumes that the response data can be represented in a single
>>>>> byte length field for the TLVs, which is not always the case.  Some of
>>>>> the cards I have return 256 bytes of challenge data plus meta data.
>>>>>
>>>>> I would like to change this to actually properly parse the nested
>>>>> reponse TLV's, however, I am looking for some tlv parsing code in the
>>>>> code base and have struck out. So the question is, do you have any
>>>>> code for parsing nested tlv's?
>>>>
>>>>
>>>> The card-piv.c does a lot of simple TLV like the above, and also more
>>>> complicated scans using  sc_asn1_find_tag() 23 times. This allows for
>>>> nested values, which can be large, like a certificate. The
>>>>
>>>
>>> Thanks thats what I was missing, I was grepping for tlv and only found
>>> some
>>> definitions from internal-winscard.h
>>>
>>>>>
>>>>> FYI current status is that it sends to the card, gets the response via
>>>>> multiple get response requests and then dies here. I added support
>>>>> into the entry point to handle different key sizes and algortihms.
>>>>
>>>>
>>>> 1426 /*
>>>> 1427  * will only deal with 3des for now
>>>> 1428  * assumptions include:
>>>> 1429  *  size of encrypted data is same as unencrypted
>>>> 1430  *  challenges, nonces etc  from card are less then 114 (keeps tags
>>>> simple)
>>>> 1431  */
>>>> 1432
>>>> 1433 static int piv_general_mutual_authenticate(sc_card_t *card,
>>>> 1434         unsigned int key_ref, unsigned int alg_id)
>>>>
>>>> So the tag processing does need to be updated to use sc_asn1_find_tag.
>>>> and sbuf need to be bigger. rbuf defaults to 0 to use 4096 in
>>>> piv_general_io.
>>>
>>>
>>> I didn't hit any of these limits yet AFAIK. I re-worked a lot of the
>>> key logic to escape the
>>> hardcodes of 3des key sizes.
>>>
>>>>
>>>>
>>>> The alg_id parameter of  piv_general_mutual_authenticate defines the
>>>> algortihm
>>>> and key size, as defined in NIST 800-78 Table 6-2. (older versions define
>>>> "04")
>>>> 08, 0A and 0C are AES 128, 192, 256 ECB
>>>>
>>>>
>>>> Are you looking at NIST 800-73-3 or the draft 800-73-4?
>>>
>>>
>>> 800-73-3. I am currently testing with algorithm 0C - AES 256 ECB
>>>
>>> Patches will come from me soon. I'll be disapearing on vacation soon
>>> but will be back to finish them.
>>>
>>> Do you want me to to the github pull request or send patches via the
>>> mailing list?
>>
>>
>> github pull requests would work.
>>
>>
>>
>>>
>>>>
>>>> --
>>>>
>>>>    Douglas E. Engert  <[hidden email]>
>>>>
>>>>
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Open source business process management suite built on Java and Eclipse
>>>> Turn processes into business applications with Bonita BPM Community
>>>> Edition
>>>> Quickly connect people, data, and systems into organized workflows
>>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>>> http://p.sf.net/sfu/Bonitasoft
>>>> _______________________________________________
>>>> Opensc-devel mailing list
>>>> [hidden email]
>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>
>>>
>>>
>>>
>>
>> --
>>
>>  Douglas E. Engert  <[hidden email]>
>>
>
>
>
> --
> Respectfully,
>
> William C Roberts



--
Respectfully,

William C Roberts

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding support for AES General Auth

Douglas E Engert


On 7/24/2014 5:54 PM, William Roberts wrote:

> On Thu, Jul 24, 2014 at 3:05 PM, William Roberts
> <[hidden email]> wrote:
>> I currently have some messy patches for handling AES algo's for
>> general_auth command and larger nonces. However, the response to the
>> card is not done yet. Im hung up on the best way to format the
>> encrypted challenge to go back to the card.
>>
>> We need to send 2 TLVs, one nested inside the other like so:
>> 7C<len>[81<len><enc challenge>]
>>
>> The existing code didn't handle the multiple length fields, so I am
>> looking through the asn1 routines since that's where the decode
>> operations were. I am looking at asn1_encode_entry() to encode this up
>> but I have 2 questions:
>> 1. Is that even the function I want?
>> 2. Its not clear to me how to use the function?
>>
>
> I think I finally stumbled into what I was looking for:
>
> put_tag_and_len(0xAC, out_len, &p);
>
> memcpy(p, outdata, out_len);
> p+=out_len;
>
>> Any help?

the put_tag_and_len can be called with the third parameter as NULL.
In this case it will return the total size of tag + tag_len + len of data.
An example of this is at line 2435 /* now add the cert like another object */

  First get the lengths of the 3 sub fields, a cert, a 0x71 with a length of 1,
  and a 0xFE with a zero length.

                i2 = put_tag_and_len(0x70,certlen, NULL)
                                + put_tag_and_len(0x71, 1, NULL)
                                + put_tag_and_len(0xFE, 0, NULL);


Then get the length of the total object:
                certobjlen = put_tag_and_len(0x53, i2, NULL);

allocate certobjlen bytes.

build the buffer, starting with the 0x53 tag and total length
followed by the cert0x70, CertInfo 0x71 flag byte and Error detection Code
0xfe final zero length TLV.


piv_write_certificate uses the same logic, to create a cert object,
(NIST 800-73 part 1 table 9.)
It sets the 0x71 byte if the cert is gziped.

piv_put_data is then called yo put 0x5C tag round the BER-TLV Tag
(part 1 Table 2) and write it followed by the data with the 0x53
tag the card. (part2  table 7)


>>
>> Thanks
>>
>> On Tue, Jul 8, 2014 at 5:12 PM, Douglas E Engert <[hidden email]> wrote:
>>>
>>>
>>> On 7/8/2014 6:21 PM, William Roberts wrote:
>>>>
>>>> On Tue, Jul 8, 2014 at 4:10 PM, Douglas E Engert <[hidden email]>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 7/8/2014 3:47 PM, William Roberts wrote:
>>>>>>
>>>>>> I am currently adding support for AES for general AUTH. I currently am
>>>>>> at this check in card-piv.c
>>>>>>
>>>>>> if ( (*q++ != 0x7C)
>>>>>> || (*q++ != rbuflen - 2)
>>>>>> || (*q++ != 0x81)
>>>>>> || (*q++ != rbuflen - 4)) {
>>>>>>
>>>>>> This assumes that the response data can be represented in a single
>>>>>> byte length field for the TLVs, which is not always the case.  Some of
>>>>>> the cards I have return 256 bytes of challenge data plus meta data.
>>>>>>
>>>>>> I would like to change this to actually properly parse the nested
>>>>>> reponse TLV's, however, I am looking for some tlv parsing code in the
>>>>>> code base and have struck out. So the question is, do you have any
>>>>>> code for parsing nested tlv's?
>>>>>
>>>>>
>>>>> The card-piv.c does a lot of simple TLV like the above, and also more
>>>>> complicated scans using  sc_asn1_find_tag() 23 times. This allows for
>>>>> nested values, which can be large, like a certificate. The
>>>>>
>>>>
>>>> Thanks thats what I was missing, I was grepping for tlv and only found
>>>> some
>>>> definitions from internal-winscard.h
>>>>
>>>>>>
>>>>>> FYI current status is that it sends to the card, gets the response via
>>>>>> multiple get response requests and then dies here. I added support
>>>>>> into the entry point to handle different key sizes and algortihms.
>>>>>
>>>>>
>>>>> 1426 /*
>>>>> 1427  * will only deal with 3des for now
>>>>> 1428  * assumptions include:
>>>>> 1429  *  size of encrypted data is same as unencrypted
>>>>> 1430  *  challenges, nonces etc  from card are less then 114 (keeps tags
>>>>> simple)
>>>>> 1431  */
>>>>> 1432
>>>>> 1433 static int piv_general_mutual_authenticate(sc_card_t *card,
>>>>> 1434         unsigned int key_ref, unsigned int alg_id)
>>>>>
>>>>> So the tag processing does need to be updated to use sc_asn1_find_tag.
>>>>> and sbuf need to be bigger. rbuf defaults to 0 to use 4096 in
>>>>> piv_general_io.
>>>>
>>>>
>>>> I didn't hit any of these limits yet AFAIK. I re-worked a lot of the
>>>> key logic to escape the
>>>> hardcodes of 3des key sizes.
>>>>
>>>>>
>>>>>
>>>>> The alg_id parameter of  piv_general_mutual_authenticate defines the
>>>>> algortihm
>>>>> and key size, as defined in NIST 800-78 Table 6-2. (older versions define
>>>>> "04")
>>>>> 08, 0A and 0C are AES 128, 192, 256 ECB
>>>>>
>>>>>
>>>>> Are you looking at NIST 800-73-3 or the draft 800-73-4?
>>>>
>>>>
>>>> 800-73-3. I am currently testing with algorithm 0C - AES 256 ECB
>>>>
>>>> Patches will come from me soon. I'll be disapearing on vacation soon
>>>> but will be back to finish them.
>>>>
>>>> Do you want me to to the github pull request or send patches via the
>>>> mailing list?
>>>
>>>
>>> github pull requests would work.
>>>
>>>
>>>
>>>>
>>>>>
>>>>> --
>>>>>
>>>>>     Douglas E. Engert  <[hidden email]>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Open source business process management suite built on Java and Eclipse
>>>>> Turn processes into business applications with Bonita BPM Community
>>>>> Edition
>>>>> Quickly connect people, data, and systems into organized workflows
>>>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>>>> http://p.sf.net/sfu/Bonitasoft
>>>>> _______________________________________________
>>>>> Opensc-devel mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>>
>>>   Douglas E. Engert  <[hidden email]>
>>>
>>
>>
>>
>> --
>> Respectfully,
>>
>> William C Roberts
>
>
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding support for AES General Auth

William Roberts

Thanks

On Jul 24, 2014 5:15 PM, "Douglas E Engert" <[hidden email]> wrote:


On 7/24/2014 5:54 PM, William Roberts wrote:
On Thu, Jul 24, 2014 at 3:05 PM, William Roberts
<[hidden email]> wrote:
I currently have some messy patches for handling AES algo's for
general_auth command and larger nonces. However, the response to the
card is not done yet. Im hung up on the best way to format the
encrypted challenge to go back to the card.

We need to send 2 TLVs, one nested inside the other like so:
7C<len>[81<len><enc challenge>]

The existing code didn't handle the multiple length fields, so I am
looking through the asn1 routines since that's where the decode
operations were. I am looking at asn1_encode_entry() to encode this up
but I have 2 questions:
1. Is that even the function I want?
2. Its not clear to me how to use the function?


I think I finally stumbled into what I was looking for:

put_tag_and_len(0xAC, out_len, &p);

memcpy(p, outdata, out_len);
p+=out_len;

Any help?

the put_tag_and_len can be called with the third parameter as NULL.
In this case it will return the total size of tag + tag_len + len of data.
An example of this is at line 2435 /* now add the cert like another object */

 First get the lengths of the 3 sub fields, a cert, a 0x71 with a length of 1,
 and a 0xFE with a zero length.

               i2 = put_tag_and_len(0x70,certlen, NULL)
                               + put_tag_and_len(0x71, 1, NULL)
                               + put_tag_and_len(0xFE, 0, NULL);


Then get the length of the total object:
                certobjlen = put_tag_and_len(0x53, i2, NULL);

allocate certobjlen bytes.                                                                              

build the buffer, starting with the 0x53 tag and total length
followed by the cert0x70, CertInfo 0x71 flag byte and Error detection Code
0xfe final zero length TLV.


piv_write_certificate uses the same logic, to create a cert object,
(NIST 800-73 part 1 table 9.)
It sets the 0x71 byte if the cert is gziped.

piv_put_data is then called yo put 0x5C tag round the BER-TLV Tag
(part 1 Table 2) and write it followed by the data with the 0x53
tag the card. (part2  table 7)



Thanks

On Tue, Jul 8, 2014 at 5:12 PM, Douglas E Engert <[hidden email]> wrote:


On 7/8/2014 6:21 PM, William Roberts wrote:

On Tue, Jul 8, 2014 at 4:10 PM, Douglas E Engert <[hidden email]>
wrote:



On 7/8/2014 3:47 PM, William Roberts wrote:

I am currently adding support for AES for general AUTH. I currently am
at this check in card-piv.c

if ( (*q++ != 0x7C)
|| (*q++ != rbuflen - 2)
|| (*q++ != 0x81)
|| (*q++ != rbuflen - 4)) {

This assumes that the response data can be represented in a single
byte length field for the TLVs, which is not always the case.  Some of
the cards I have return 256 bytes of challenge data plus meta data.

I would like to change this to actually properly parse the nested
reponse TLV's, however, I am looking for some tlv parsing code in the
code base and have struck out. So the question is, do you have any
code for parsing nested tlv's?


The card-piv.c does a lot of simple TLV like the above, and also more
complicated scans using  sc_asn1_find_tag() 23 times. This allows for
nested values, which can be large, like a certificate. The


Thanks thats what I was missing, I was grepping for tlv and only found
some
definitions from internal-winscard.h


FYI current status is that it sends to the card, gets the response via
multiple get response requests and then dies here. I added support
into the entry point to handle different key sizes and algortihms.


1426 /*
1427  * will only deal with 3des for now
1428  * assumptions include:
1429  *  size of encrypted data is same as unencrypted
1430  *  challenges, nonces etc  from card are less then 114 (keeps tags
simple)
1431  */
1432
1433 static int piv_general_mutual_authenticate(sc_card_t *card,
1434         unsigned int key_ref, unsigned int alg_id)

So the tag processing does need to be updated to use sc_asn1_find_tag.
and sbuf need to be bigger. rbuf defaults to 0 to use 4096 in
piv_general_io.


I didn't hit any of these limits yet AFAIK. I re-worked a lot of the
key logic to escape the
hardcodes of 3des key sizes.



The alg_id parameter of  piv_general_mutual_authenticate defines the
algortihm
and key size, as defined in NIST 800-78 Table 6-2. (older versions define
"04")
08, 0A and 0C are AES 128, 192, 256 ECB


Are you looking at NIST 800-73-3 or the draft 800-73-4?


800-73-3. I am currently testing with algorithm 0C - AES 256 ECB

Patches will come from me soon. I'll be disapearing on vacation soon
but will be back to finish them.

Do you want me to to the github pull request or send patches via the
mailing list?


github pull requests would work.





--

    Douglas E. Engert  <[hidden email]>



------------------------------------------------------------------------------
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community
Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel





--

  Douglas E. Engert  <[hidden email]>




--
Respectfully,

William C Roberts




--

 Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding support for AES General Auth

Douglas E Engert
In reply to this post by William Roberts


On 7/24/2014 5:54 PM, William Roberts wrote:
> On Thu, Jul 24, 2014 at 3:05 PM, William Roberts
> <[hidden email]> wrote:
>> I currently have some messy patches for handling AES algo's for
>> general_auth command and larger nonces. However, the response to the
>> card is not done yet. Im hung up on the best way to format the
>> encrypted challenge to go back to the card.
>>
>> We need to send 2 TLVs, one nested inside the other like so:
>> 7C<len>[81<len><enc challenge>]

Looking closer, the piv_validate_general_authentication
does just that, for RSA  7c<len>[82<0>81<datalen>]
or for EC derive        7c<len>[82<0>85<datalen>]
it uses the put_tag_and_len
It takes some short cuts that could be more general.



>>
>> The existing code didn't handle the multiple length fields, so I am
>> looking through the asn1 routines since that's where the decode
>> operations were. I am looking at asn1_encode_entry() to encode this up
>> but I have 2 questions:
>> 1. Is that even the function I want?
>> 2. Its not clear to me how to use the function?
>>
>
> I think I finally stumbled into what I was looking for:
>
> put_tag_and_len(0xAC, out_len, &p);
>
> memcpy(p, outdata, out_len);
> p+=out_len;
>
>> Any help?
>>
>> Thanks
>>
>> On Tue, Jul 8, 2014 at 5:12 PM, Douglas E Engert <[hidden email]> wrote:
>>>
>>>
>>> On 7/8/2014 6:21 PM, William Roberts wrote:
>>>>
>>>> On Tue, Jul 8, 2014 at 4:10 PM, Douglas E Engert <[hidden email]>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 7/8/2014 3:47 PM, William Roberts wrote:
>>>>>>
>>>>>> I am currently adding support for AES for general AUTH. I currently am
>>>>>> at this check in card-piv.c
>>>>>>
>>>>>> if ( (*q++ != 0x7C)
>>>>>> || (*q++ != rbuflen - 2)
>>>>>> || (*q++ != 0x81)
>>>>>> || (*q++ != rbuflen - 4)) {
>>>>>>
>>>>>> This assumes that the response data can be represented in a single
>>>>>> byte length field for the TLVs, which is not always the case.  Some of
>>>>>> the cards I have return 256 bytes of challenge data plus meta data.
>>>>>>
>>>>>> I would like to change this to actually properly parse the nested
>>>>>> reponse TLV's, however, I am looking for some tlv parsing code in the
>>>>>> code base and have struck out. So the question is, do you have any
>>>>>> code for parsing nested tlv's?
>>>>>
>>>>>
>>>>> The card-piv.c does a lot of simple TLV like the above, and also more
>>>>> complicated scans using  sc_asn1_find_tag() 23 times. This allows for
>>>>> nested values, which can be large, like a certificate. The
>>>>>
>>>>
>>>> Thanks thats what I was missing, I was grepping for tlv and only found
>>>> some
>>>> definitions from internal-winscard.h
>>>>
>>>>>>
>>>>>> FYI current status is that it sends to the card, gets the response via
>>>>>> multiple get response requests and then dies here. I added support
>>>>>> into the entry point to handle different key sizes and algortihms.
>>>>>
>>>>>
>>>>> 1426 /*
>>>>> 1427  * will only deal with 3des for now
>>>>> 1428  * assumptions include:
>>>>> 1429  *  size of encrypted data is same as unencrypted
>>>>> 1430  *  challenges, nonces etc  from card are less then 114 (keeps tags
>>>>> simple)
>>>>> 1431  */
>>>>> 1432
>>>>> 1433 static int piv_general_mutual_authenticate(sc_card_t *card,
>>>>> 1434         unsigned int key_ref, unsigned int alg_id)
>>>>>
>>>>> So the tag processing does need to be updated to use sc_asn1_find_tag.
>>>>> and sbuf need to be bigger. rbuf defaults to 0 to use 4096 in
>>>>> piv_general_io.
>>>>
>>>>
>>>> I didn't hit any of these limits yet AFAIK. I re-worked a lot of the
>>>> key logic to escape the
>>>> hardcodes of 3des key sizes.
>>>>
>>>>>
>>>>>
>>>>> The alg_id parameter of  piv_general_mutual_authenticate defines the
>>>>> algortihm
>>>>> and key size, as defined in NIST 800-78 Table 6-2. (older versions define
>>>>> "04")
>>>>> 08, 0A and 0C are AES 128, 192, 256 ECB
>>>>>
>>>>>
>>>>> Are you looking at NIST 800-73-3 or the draft 800-73-4?
>>>>
>>>>
>>>> 800-73-3. I am currently testing with algorithm 0C - AES 256 ECB
>>>>
>>>> Patches will come from me soon. I'll be disapearing on vacation soon
>>>> but will be back to finish them.
>>>>
>>>> Do you want me to to the github pull request or send patches via the
>>>> mailing list?
>>>
>>>
>>> github pull requests would work.
>>>
>>>
>>>
>>>>
>>>>>
>>>>> --
>>>>>
>>>>>     Douglas E. Engert  <[hidden email]>
>>>>>
>>>>>
>>>>>
>>>>> ------------------------------------------------------------------------------
>>>>> Open source business process management suite built on Java and Eclipse
>>>>> Turn processes into business applications with Bonita BPM Community
>>>>> Edition
>>>>> Quickly connect people, data, and systems into organized workflows
>>>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>>>> http://p.sf.net/sfu/Bonitasoft
>>>>> _______________________________________________
>>>>> Opensc-devel mailing list
>>>>> [hidden email]
>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>
>>>>
>>>>
>>>>
>>>
>>> --
>>>
>>>   Douglas E. Engert  <[hidden email]>
>>>
>>
>>
>>
>> --
>> Respectfully,
>>
>> William C Roberts
>
>
>

--

  Douglas E. Engert  <[hidden email]>


------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding support for AES General Auth

William Roberts
Pull request for this was submitted:
https://github.com/OpenSC/OpenSC/pull/270

I dont have any cards I can test 3des support to make sure I didn't
break anything.
Can anyone test a known good system and make sure it still works?

I tested on AES-256 with 256 Byte nonces ONLY.

Thanks,
Bill


On Thu, Jul 24, 2014 at 5:25 PM, Douglas E Engert <[hidden email]> wrote:

>
>
> On 7/24/2014 5:54 PM, William Roberts wrote:
>>
>> On Thu, Jul 24, 2014 at 3:05 PM, William Roberts
>> <[hidden email]> wrote:
>>>
>>> I currently have some messy patches for handling AES algo's for
>>> general_auth command and larger nonces. However, the response to the
>>> card is not done yet. Im hung up on the best way to format the
>>> encrypted challenge to go back to the card.
>>>
>>> We need to send 2 TLVs, one nested inside the other like so:
>>> 7C<len>[81<len><enc challenge>]
>
>
> Looking closer, the piv_validate_general_authentication
> does just that, for RSA  7c<len>[82<0>81<datalen>]
> or for EC derive        7c<len>[82<0>85<datalen>]
> it uses the put_tag_and_len
> It takes some short cuts that could be more general.
>
>
>
>
>>>
>>> The existing code didn't handle the multiple length fields, so I am
>>> looking through the asn1 routines since that's where the decode
>>> operations were. I am looking at asn1_encode_entry() to encode this up
>>> but I have 2 questions:
>>> 1. Is that even the function I want?
>>> 2. Its not clear to me how to use the function?
>>>
>>
>> I think I finally stumbled into what I was looking for:
>>
>> put_tag_and_len(0xAC, out_len, &p);
>>
>> memcpy(p, outdata, out_len);
>> p+=out_len;
>>
>>> Any help?
>>>
>>> Thanks
>>>
>>> On Tue, Jul 8, 2014 at 5:12 PM, Douglas E Engert <[hidden email]>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On 7/8/2014 6:21 PM, William Roberts wrote:
>>>>>
>>>>>
>>>>> On Tue, Jul 8, 2014 at 4:10 PM, Douglas E Engert <[hidden email]>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 7/8/2014 3:47 PM, William Roberts wrote:
>>>>>>>
>>>>>>>
>>>>>>> I am currently adding support for AES for general AUTH. I currently
>>>>>>> am
>>>>>>> at this check in card-piv.c
>>>>>>>
>>>>>>> if ( (*q++ != 0x7C)
>>>>>>> || (*q++ != rbuflen - 2)
>>>>>>> || (*q++ != 0x81)
>>>>>>> || (*q++ != rbuflen - 4)) {
>>>>>>>
>>>>>>> This assumes that the response data can be represented in a single
>>>>>>> byte length field for the TLVs, which is not always the case.  Some
>>>>>>> of
>>>>>>> the cards I have return 256 bytes of challenge data plus meta data.
>>>>>>>
>>>>>>> I would like to change this to actually properly parse the nested
>>>>>>> reponse TLV's, however, I am looking for some tlv parsing code in the
>>>>>>> code base and have struck out. So the question is, do you have any
>>>>>>> code for parsing nested tlv's?
>>>>>>
>>>>>>
>>>>>>
>>>>>> The card-piv.c does a lot of simple TLV like the above, and also more
>>>>>> complicated scans using  sc_asn1_find_tag() 23 times. This allows for
>>>>>> nested values, which can be large, like a certificate. The
>>>>>>
>>>>>
>>>>> Thanks thats what I was missing, I was grepping for tlv and only found
>>>>> some
>>>>> definitions from internal-winscard.h
>>>>>
>>>>>>>
>>>>>>> FYI current status is that it sends to the card, gets the response
>>>>>>> via
>>>>>>> multiple get response requests and then dies here. I added support
>>>>>>> into the entry point to handle different key sizes and algortihms.
>>>>>>
>>>>>>
>>>>>>
>>>>>> 1426 /*
>>>>>> 1427  * will only deal with 3des for now
>>>>>> 1428  * assumptions include:
>>>>>> 1429  *  size of encrypted data is same as unencrypted
>>>>>> 1430  *  challenges, nonces etc  from card are less then 114 (keeps
>>>>>> tags
>>>>>> simple)
>>>>>> 1431  */
>>>>>> 1432
>>>>>> 1433 static int piv_general_mutual_authenticate(sc_card_t *card,
>>>>>> 1434         unsigned int key_ref, unsigned int alg_id)
>>>>>>
>>>>>> So the tag processing does need to be updated to use sc_asn1_find_tag.
>>>>>> and sbuf need to be bigger. rbuf defaults to 0 to use 4096 in
>>>>>> piv_general_io.
>>>>>
>>>>>
>>>>>
>>>>> I didn't hit any of these limits yet AFAIK. I re-worked a lot of the
>>>>> key logic to escape the
>>>>> hardcodes of 3des key sizes.
>>>>>
>>>>>>
>>>>>>
>>>>>> The alg_id parameter of  piv_general_mutual_authenticate defines the
>>>>>> algortihm
>>>>>> and key size, as defined in NIST 800-78 Table 6-2. (older versions
>>>>>> define
>>>>>> "04")
>>>>>> 08, 0A and 0C are AES 128, 192, 256 ECB
>>>>>>
>>>>>>
>>>>>> Are you looking at NIST 800-73-3 or the draft 800-73-4?
>>>>>
>>>>>
>>>>>
>>>>> 800-73-3. I am currently testing with algorithm 0C - AES 256 ECB
>>>>>
>>>>> Patches will come from me soon. I'll be disapearing on vacation soon
>>>>> but will be back to finish them.
>>>>>
>>>>> Do you want me to to the github pull request or send patches via the
>>>>> mailing list?
>>>>
>>>>
>>>>
>>>> github pull requests would work.
>>>>
>>>>
>>>>
>>>>>
>>>>>>
>>>>>> --
>>>>>>
>>>>>>     Douglas E. Engert  <[hidden email]>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> ------------------------------------------------------------------------------
>>>>>> Open source business process management suite built on Java and
>>>>>> Eclipse
>>>>>> Turn processes into business applications with Bonita BPM Community
>>>>>> Edition
>>>>>> Quickly connect people, data, and systems into organized workflows
>>>>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>>>>> http://p.sf.net/sfu/Bonitasoft
>>>>>> _______________________________________________
>>>>>> Opensc-devel mailing list
>>>>>> [hidden email]
>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>>
>>>>   Douglas E. Engert  <[hidden email]>
>>>>
>>>
>>>
>>>
>>> --
>>> Respectfully,
>>>
>>> William C Roberts
>>
>>
>>
>>
>
> --
>
>  Douglas E. Engert  <[hidden email]>
>



--
Respectfully,

William C Roberts

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Adding support for AES General Auth

William Roberts
It looks like it died on the jenkins auto-build:
https://opensc.fr/jenkins/job/OpenSC-pr-win32/148/

How do I get the output logs to view why it failed?

My guess is the stat() stuff since the existing code had
read/open in it. They should probably be using fopen and fread
if this is meant for windows?

On Fri, Jul 25, 2014 at 11:19 AM, William Roberts
<[hidden email]> wrote:

> Pull request for this was submitted:
> https://github.com/OpenSC/OpenSC/pull/270
>
> I dont have any cards I can test 3des support to make sure I didn't
> break anything.
> Can anyone test a known good system and make sure it still works?
>
> I tested on AES-256 with 256 Byte nonces ONLY.
>
> Thanks,
> Bill
>
>
> On Thu, Jul 24, 2014 at 5:25 PM, Douglas E Engert <[hidden email]> wrote:
>>
>>
>> On 7/24/2014 5:54 PM, William Roberts wrote:
>>>
>>> On Thu, Jul 24, 2014 at 3:05 PM, William Roberts
>>> <[hidden email]> wrote:
>>>>
>>>> I currently have some messy patches for handling AES algo's for
>>>> general_auth command and larger nonces. However, the response to the
>>>> card is not done yet. Im hung up on the best way to format the
>>>> encrypted challenge to go back to the card.
>>>>
>>>> We need to send 2 TLVs, one nested inside the other like so:
>>>> 7C<len>[81<len><enc challenge>]
>>
>>
>> Looking closer, the piv_validate_general_authentication
>> does just that, for RSA  7c<len>[82<0>81<datalen>]
>> or for EC derive        7c<len>[82<0>85<datalen>]
>> it uses the put_tag_and_len
>> It takes some short cuts that could be more general.
>>
>>
>>
>>
>>>>
>>>> The existing code didn't handle the multiple length fields, so I am
>>>> looking through the asn1 routines since that's where the decode
>>>> operations were. I am looking at asn1_encode_entry() to encode this up
>>>> but I have 2 questions:
>>>> 1. Is that even the function I want?
>>>> 2. Its not clear to me how to use the function?
>>>>
>>>
>>> I think I finally stumbled into what I was looking for:
>>>
>>> put_tag_and_len(0xAC, out_len, &p);
>>>
>>> memcpy(p, outdata, out_len);
>>> p+=out_len;
>>>
>>>> Any help?
>>>>
>>>> Thanks
>>>>
>>>> On Tue, Jul 8, 2014 at 5:12 PM, Douglas E Engert <[hidden email]>
>>>> wrote:
>>>>>
>>>>>
>>>>>
>>>>> On 7/8/2014 6:21 PM, William Roberts wrote:
>>>>>>
>>>>>>
>>>>>> On Tue, Jul 8, 2014 at 4:10 PM, Douglas E Engert <[hidden email]>
>>>>>> wrote:
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 7/8/2014 3:47 PM, William Roberts wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> I am currently adding support for AES for general AUTH. I currently
>>>>>>>> am
>>>>>>>> at this check in card-piv.c
>>>>>>>>
>>>>>>>> if ( (*q++ != 0x7C)
>>>>>>>> || (*q++ != rbuflen - 2)
>>>>>>>> || (*q++ != 0x81)
>>>>>>>> || (*q++ != rbuflen - 4)) {
>>>>>>>>
>>>>>>>> This assumes that the response data can be represented in a single
>>>>>>>> byte length field for the TLVs, which is not always the case.  Some
>>>>>>>> of
>>>>>>>> the cards I have return 256 bytes of challenge data plus meta data.
>>>>>>>>
>>>>>>>> I would like to change this to actually properly parse the nested
>>>>>>>> reponse TLV's, however, I am looking for some tlv parsing code in the
>>>>>>>> code base and have struck out. So the question is, do you have any
>>>>>>>> code for parsing nested tlv's?
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The card-piv.c does a lot of simple TLV like the above, and also more
>>>>>>> complicated scans using  sc_asn1_find_tag() 23 times. This allows for
>>>>>>> nested values, which can be large, like a certificate. The
>>>>>>>
>>>>>>
>>>>>> Thanks thats what I was missing, I was grepping for tlv and only found
>>>>>> some
>>>>>> definitions from internal-winscard.h
>>>>>>
>>>>>>>>
>>>>>>>> FYI current status is that it sends to the card, gets the response
>>>>>>>> via
>>>>>>>> multiple get response requests and then dies here. I added support
>>>>>>>> into the entry point to handle different key sizes and algortihms.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 1426 /*
>>>>>>> 1427  * will only deal with 3des for now
>>>>>>> 1428  * assumptions include:
>>>>>>> 1429  *  size of encrypted data is same as unencrypted
>>>>>>> 1430  *  challenges, nonces etc  from card are less then 114 (keeps
>>>>>>> tags
>>>>>>> simple)
>>>>>>> 1431  */
>>>>>>> 1432
>>>>>>> 1433 static int piv_general_mutual_authenticate(sc_card_t *card,
>>>>>>> 1434         unsigned int key_ref, unsigned int alg_id)
>>>>>>>
>>>>>>> So the tag processing does need to be updated to use sc_asn1_find_tag.
>>>>>>> and sbuf need to be bigger. rbuf defaults to 0 to use 4096 in
>>>>>>> piv_general_io.
>>>>>>
>>>>>>
>>>>>>
>>>>>> I didn't hit any of these limits yet AFAIK. I re-worked a lot of the
>>>>>> key logic to escape the
>>>>>> hardcodes of 3des key sizes.
>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The alg_id parameter of  piv_general_mutual_authenticate defines the
>>>>>>> algortihm
>>>>>>> and key size, as defined in NIST 800-78 Table 6-2. (older versions
>>>>>>> define
>>>>>>> "04")
>>>>>>> 08, 0A and 0C are AES 128, 192, 256 ECB
>>>>>>>
>>>>>>>
>>>>>>> Are you looking at NIST 800-73-3 or the draft 800-73-4?
>>>>>>
>>>>>>
>>>>>>
>>>>>> 800-73-3. I am currently testing with algorithm 0C - AES 256 ECB
>>>>>>
>>>>>> Patches will come from me soon. I'll be disapearing on vacation soon
>>>>>> but will be back to finish them.
>>>>>>
>>>>>> Do you want me to to the github pull request or send patches via the
>>>>>> mailing list?
>>>>>
>>>>>
>>>>>
>>>>> github pull requests would work.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>>     Douglas E. Engert  <[hidden email]>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> ------------------------------------------------------------------------------
>>>>>>> Open source business process management suite built on Java and
>>>>>>> Eclipse
>>>>>>> Turn processes into business applications with Bonita BPM Community
>>>>>>> Edition
>>>>>>> Quickly connect people, data, and systems into organized workflows
>>>>>>> Winner of BOSSIE, CODIE, OW2 and Gartner awards
>>>>>>> http://p.sf.net/sfu/Bonitasoft
>>>>>>> _______________________________________________
>>>>>>> Opensc-devel mailing list
>>>>>>> [hidden email]
>>>>>>> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>>
>>>>>   Douglas E. Engert  <[hidden email]>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Respectfully,
>>>>
>>>> William C Roberts
>>>
>>>
>>>
>>>
>>
>> --
>>
>>  Douglas E. Engert  <[hidden email]>
>>
>
>
>
> --
> Respectfully,
>
> William C Roberts



--
Respectfully,

William C Roberts

------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Opensc-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel