Recently submitted pull requests

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

Recently submitted pull requests

ttaylor
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
[hidden email]
Office: 781-271-2099

Principal Software Systems Engineer
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730-1420

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Recently submitted pull requests

Douglas E. Engert


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  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Recently submitted pull requests

ttaylor


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
[hidden email]
Office: 781-271-2099
Mobile: 617-893-0107

Principal Software Systems Engineer
The MITRE Corporation
202 Burlington Road
Bedford, MA 01730-1420

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Recently submitted pull requests

Douglas E. Engert


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  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel

pubkey-piv.diff (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Recently submitted pull requests

ttaylor


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
>>
>
>
>

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel
Reply | Threaded
Open this post in threaded view
|

Re: Recently submitted pull requests

Douglas E. Engert


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
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/opensc-devel
>

--

  Douglas E. Engert  <[hidden email]>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444

------------------------------------------------------------------------------
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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/opensc-devel