Adding support for AES General Auth
Locked
Adding support for AES General Auth
 
|
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 |
Re: Adding support for AES General Auth
|
|
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 |
Re: Adding support for AES General Auth
|
|
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 |
Re: Adding support for AES General Auth
|
|
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 |
Re: Adding support for AES General Auth
|
|
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 |
Re: Adding support for AES General Auth
|
|
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 |
Re: Adding support for AES General Auth
|
|
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 |
Re: Adding support for AES General Auth
|
|
Thanks On Jul 24, 2014 5:15 PM, "Douglas E Engert" <[hidden email]> wrote:
------------------------------------------------------------------------------ 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 |
Re: Adding support for AES General Auth
|
|
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 |
Re: Adding support for AES General Auth
|
|
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 |
Re: Adding support for AES General Auth
|
|
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 |
«
Return to Developer
|
1 view|%1 views
| Free forum by Nabble | Edit this page |