Menu
▾
▴
opensc-devel
|
From: Tim T. <tt...@mi...> - 2013-09-24 19:23:30
|
Greetings. I just submitted three pull requests (#184, #185, #186) for consideration that I developed while trying to use the OpenSC minidriver on Windows 7 with a pin pad capable reader, and a PIV token. I'll provide a brief description of each pull request. #184: Set output buffer len variable if padding removed. Note: I started my development with the 0.13.0 source code tarball. When I got to the point where I was ready to submit pull requests, it appears that the issue addressed by this pull request has a "fix" in place. However I think this pull request is preferable The sc_pkcs1_strip_02_padding function in padding.c takes a pointer to an output buffer (out) and a pointer to the max length of the buffer (out_len). On input, out_len is expected to point to the maximum length of the output buffer. On output, this value should be over written with the length of un-padded data copied to the out buffer, but this was not being done. #185: Extract public key from cert if no object on card The PIV token that I am using is a US DoD Common Access Card (CAC). These tokens do not have separate containers for the public keys. When I first started using these tokens with the windows minidriver, and the certutil command line tool to read the token, I was getting a bunch of messages in the debug log: "No way to get public key: -1416 (Not implemented)". With this patch, when the PIV pkcs#15 emulation object is being initialized, it will extract the public key for each private key from the corresponding certificate. #186: Use reader pin pad if available and allowed This patch allows this use of a pin pad reader with the Windows minidriver (if using Version 6 or higher of the MS Base Card Services implementation -- it requires support for CardAuthenticateEx). This is accomplished by setting the PinType to ExternalPinType instead of AlphaNumericPinType. This also requires handling some additional properties (CP_PARENT_WINDOW, and CP_PIN_CONTEXT_STRING). =============== I would appreciate the consideration of the project committers for each of these improvements. I've tried to make sure I conformed to the project coding conventions. If I fell short of the conventions, please let me know and I'd be happy to rework the pull requests. Also, if there is another alternative for achieving any of these that would be more acceptable for inclusion, just let me know. - Tim -- Tim Taylor tt...@mi... Office: 781-271-2099 Principal Software Systems Engineer The MITRE Corporation 202 Burlington Road Bedford, MA 01730-1420 |
|
From: Douglas E. E. <dee...@an...> - 2013-09-24 20:04:14
|
On 9/24/2013 2:23 PM, Tim Taylor wrote: > Greetings. > > I just submitted three pull requests (#184, #185, #186) for > consideration that I developed while trying to use the OpenSC minidriver > on Windows 7 with a pin pad capable reader, and a PIV token. I'll > provide a brief description of each pull request. > > #184: Set output buffer len variable if padding removed. > Note: I started my development with the 0.13.0 source code tarball. > When I got to the point where I was ready to submit pull requests, it > appears that the issue addressed by this pull request has a "fix" in > place. However I think this pull request is preferable > > The sc_pkcs1_strip_02_padding function in padding.c takes a pointer to > an output buffer (out) and a pointer to the max length of the buffer > (out_len). On input, out_len is expected to point to the maximum length > of the output buffer. On output, this value should be over written with > the length of un-padded data copied to the out buffer, but this was not > being done. > > #185: Extract public key from cert if no object on card > The PIV token that I am using is a US DoD Common Access Card (CAC). > These tokens do not have separate containers for the public keys. PIV cards dont either. > When I > first started using these tokens with the windows minidriver, and the > certutil command line tool to read the token, I was getting a bunch of > messages in the debug log: "No way to get public key: -1416 (Not > implemented)". (You know that Windows 7 and above have a PIV driver from Micrsoft, that works with login, IE, Outlook, and any application that can use the certificate store, like Chrome.) I would rather see the piv_ops (*read_public_key) implemented in the card_piv.c as this will only do it when needed. As I said in a note in response to the pull request, the PKCS11 code can emulate a pubkey. > > With this patch, when the PIV pkcs#15 emulation object is being > initialized, it will extract the public key for each private key from > the corresponding certificate. > > #186: Use reader pin pad if available and allowed > This patch allows this use of a pin pad reader with the Windows > minidriver (if using Version 6 or higher of the MS Base Card Services > implementation -- it requires support for CardAuthenticateEx). This is > accomplished by setting the PinType to ExternalPinType instead of > AlphaNumericPinType. This also requires handling some additional > properties (CP_PARENT_WINDOW, and CP_PIN_CONTEXT_STRING). What type of pin pad reader are you using? > > =============== > > I would appreciate the consideration of the project committers for each > of these improvements. I've tried to make sure I conformed to the > project coding conventions. If I fell short of the conventions, please > let me know and I'd be happy to rework the pull requests. Also, if > there is another alternative for achieving any of these that would be > more acceptable for inclusion, just let me know. > > - Tim > -- Douglas E. Engert <DEE...@an...> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 |
|
From: Tim T. <tt...@mi...> - 2013-09-24 21:06:06
|
On 09/24/2013 04:04 PM, Douglas E. Engert wrote: > (You know that Windows 7 and above have a PIV driver from Micrsoft, > that works with login, IE, Outlook, and any application that can use > the certificate store, like Chrome.) Yes, that is true. However, the MS-provided smartcard stack does not support using an external pinpad to enter the token pin. Their middleware does not attempt to discover what features are supported by the reader connected to the system. Even if the vendor reader driver is installed, the MS Card Services treat the pinpad reader as a basic USB CCID reader and prompt the user to enter their PIN via the system keyboard. That's why I was looking at using OpenSC in the first place. Except the OpenSC minidriver (without my fix) sets the PIN Type to be AlphaNumeric instead of External. This causes the MS base card service module to prompt the user for their token PIN via a dialog box, instead of having them enter it on the pin pad. When the PIN Type is set to External, the minidriver has complete control over how the PIN is collected and verified. > > > I would rather see the piv_ops (*read_public_key) implemented in the card_piv.c > as this will only do it when needed. I will look into doing it this way. This was actually the path I started down, but I seem to recall running into difficulty, but can't remember exactly what went wrong. I'll try again. > > What type of pin pad reader are you using? We are using both an two different pin pad readers: the OmniKey 3821 and the Gemalto PC Pinpad (I think it's now called the IDBridge CT700). - Tim -- Tim Taylor tt...@mi... Office: 781-271-2099 Mobile: 617-893-0107 Principal Software Systems Engineer The MITRE Corporation 202 Burlington Road Bedford, MA 01730-1420 |
|
From: Douglas E. E. <dee...@an...> - 2013-09-25 17:42:24
Attachments:
pubkey-piv.diff
|
On 9/24/2013 4:05 PM, Tim Taylor wrote: > > > On 09/24/2013 04:04 PM, Douglas E. Engert wrote: > >> (You know that Windows 7 and above have a PIV driver from Micrsoft, >> that works with login, IE, Outlook, and any application that can use >> the certificate store, like Chrome.) > > Yes, that is true. However, the MS-provided smartcard stack does not > support using an external pinpad to enter the token pin. Their > middleware does not attempt to discover what features are supported by > the reader connected to the system. Even if the vendor reader driver is > installed, the MS Card Services treat the pinpad reader as a basic USB > CCID reader and prompt the user to enter their PIN via the system keyboard. > > That's why I was looking at using OpenSC in the first place. Except the > OpenSC minidriver (without my fix) sets the PIN Type to be AlphaNumeric > instead of External. This causes the MS base card service module to > prompt the user for their token PIN via a dialog box, instead of having > them enter it on the pin pad. When the PIN Type is set to External, the > minidriver has complete control over how the PIN is collected and verified. > >> >> >> I would rather see the piv_ops (*read_public_key) implemented in the card_piv.c >> as this will only do it when needed. > > I will look into doing it this way. This was actually the path I > started down, but I seem to recall running into difficulty, but can't > remember exactly what went wrong. I'll try again. Having looked at the options, the most straight forward way is to do some like what you have done. I would like to propose this attached simpler fix to pkcs15-piv.c > >> > >> What type of pin pad reader are you using? > > We are using both an two different pin pad readers: the OmniKey 3821 and > the Gemalto PC Pinpad (I think it's now called the IDBridge CT700). > > - Tim > -- Douglas E. Engert <DEE...@an...> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 |
|
From: Tim T. <tt...@mi...> - 2013-09-25 21:17:07
|
On 09/25/2013 01:42 PM, Douglas E. Engert wrote: > > > On 9/24/2013 4:05 PM, Tim Taylor wrote: >> >> >> On 09/24/2013 04:04 PM, Douglas E. Engert wrote: >> >>> (You know that Windows 7 and above have a PIV driver from Micrsoft, >>> that works with login, IE, Outlook, and any application that can use >>> the certificate store, like Chrome.) >> >> Yes, that is true. However, the MS-provided smartcard stack does not >> support using an external pinpad to enter the token pin. Their >> middleware does not attempt to discover what features are supported by >> the reader connected to the system. Even if the vendor reader driver is >> installed, the MS Card Services treat the pinpad reader as a basic USB >> CCID reader and prompt the user to enter their PIN via the system >> keyboard. >> >> That's why I was looking at using OpenSC in the first place. Except the >> OpenSC minidriver (without my fix) sets the PIN Type to be AlphaNumeric >> instead of External. This causes the MS base card service module to >> prompt the user for their token PIN via a dialog box, instead of having >> them enter it on the pin pad. When the PIN Type is set to External, the >> minidriver has complete control over how the PIN is collected and >> verified. >> >>> >>> >>> I would rather see the piv_ops (*read_public_key) implemented in the >>> card_piv.c >>> as this will only do it when needed. >> >> I will look into doing it this way. This was actually the path I >> started down, but I seem to recall running into difficulty, but can't >> remember exactly what went wrong. I'll try again. > > Having looked at the options, the most straight forward way is to do > some like > what you have done. > > I would like to propose this attached simpler fix to pkcs15-piv.c > I reworked my pull request to use your suggested changes and verified that pkcs15-tool can read the public keys. I also submitted a new pull request (#189) that addresses the root problem that led me down this path. It turns out that the minidriver function CardGetContainerInfo() was extracting the public key from the certificate successfully, but the return value was still an error code (set after the attempt to read the public key directly failed). My new pull request fixes that problem by resetting the return value to success if the attempt to get the public key from the cert succeeds. >>> >> >>> What type of pin pad reader are you using? >> >> We are using both an two different pin pad readers: the OmniKey 3821 and >> the Gemalto PC Pinpad (I think it's now called the IDBridge CT700). >> >> - Tim >> > > > |
|
From: Douglas E. E. <dee...@an...> - 2013-09-25 21:59:32
|
On 9/25/2013 4:17 PM, Tim Taylor wrote: > > > On 09/25/2013 01:42 PM, Douglas E. Engert wrote: >> >> >> On 9/24/2013 4:05 PM, Tim Taylor wrote: >>> >>> >>> On 09/24/2013 04:04 PM, Douglas E. Engert wrote: >>> >>>> (You know that Windows 7 and above have a PIV driver from Micrsoft, >>>> that works with login, IE, Outlook, and any application that can use >>>> the certificate store, like Chrome.) >>> >>> Yes, that is true. However, the MS-provided smartcard stack does not >>> support using an external pinpad to enter the token pin. Their >>> middleware does not attempt to discover what features are supported by >>> the reader connected to the system. Even if the vendor reader driver is >>> installed, the MS Card Services treat the pinpad reader as a basic USB >>> CCID reader and prompt the user to enter their PIN via the system >>> keyboard. >>> >>> That's why I was looking at using OpenSC in the first place. Except the >>> OpenSC minidriver (without my fix) sets the PIN Type to be AlphaNumeric >>> instead of External. This causes the MS base card service module to >>> prompt the user for their token PIN via a dialog box, instead of having >>> them enter it on the pin pad. When the PIN Type is set to External, the >>> minidriver has complete control over how the PIN is collected and >>> verified. >>> >>>> >>>> >>>> I would rather see the piv_ops (*read_public_key) implemented in the >>>> card_piv.c >>>> as this will only do it when needed. >>> >>> I will look into doing it this way. This was actually the path I >>> started down, but I seem to recall running into difficulty, but can't >>> remember exactly what went wrong. I'll try again. >> >> Having looked at the options, the most straight forward way is to do >> some like >> what you have done. >> >> I would like to propose this attached simpler fix to pkcs15-piv.c >> > > I reworked my pull request to use your suggested changes and verified > that pkcs15-tool can read the public keys. OK, will try it. Since the PIV cards are not PKCS#15 cards the OpenSC emulated the PKCS#15. Part of the emulation was to emulate a pubkey from the certificate in case it was needed. The certificate is the only way to find out what type of key (RSA or EC) and what size the key is on card, so the pkcs15-piv.c got that info. The emulation of returning a pubkey object for PKCS#11 is handled in the pkcs11/framework-pkcs15.c, so pkcs11-tool could return a key. But the pkcs15-tool could not. This code was in the original 2005 code (for RSA only) long before the mindriver and the fact that the pkcs15 code could not return a pubkey was never a problem. The current patch also allows the pkcs15-tool to return a pubkey. > > I also submitted a new pull request (#189) that addresses the root > problem that led me down this path. It turns out that the minidriver > function CardGetContainerInfo() was extracting the public key from the > certificate successfully, but the return value was still an error code > (set after the attempt to read the public key directly failed). My new > pull request fixes that problem by resetting the return value to success > if the attempt to get the public key from the cert succeeds. > >>>> >>> >>>> What type of pin pad reader are you using? >>> >>> We are using both an two different pin pad readers: the OmniKey 3821 and >>> the Gemalto PC Pinpad (I think it's now called the IDBridge CT700). >>> >>> - Tim >>> >> >> >> > > ------------------------------------------------------------------------------ > October Webinars: Code for Performance > Free Intel webinars can help you accelerate application performance. > Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from > the latest Intel processors and coprocessors. See abstracts and register > > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk > _______________________________________________ > Opensc-devel mailing list > Ope...@li... > https://lists.sourceforge.net/lists/listinfo/opensc-devel > -- Douglas E. Engert <DEE...@an...> Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X