Kent,

Please find clarifications below...

On Mon, Jan 17, 2011 at 3:29 PM, Kent Yoder <[email protected]> wrote:

>
> Hi Nelson,
>
> > Yes, there are. I found this issue by hitting it in the real world,
> > even that sparkled the investigation. It reproduces on Mandriva
> > 2010.1, Ubuntu 10.04 and Chromium OS distributions.
>
>   Can you submit the testcase, or point us to the software that
> reproduces it?
>

To reproduce the issue you need:

a) OpenSC package
b) OpenSSL package
c) TPM hardware (e.g. Thinkpad T400 laptop)
d) Both OpenSC and OpenSSL configured to use openCryptoki
e) openCryptoki configured to use TPM device

To reproduce the issue, do:

1) Create a private key using OpenSC
2) Create a X.509 request using OpenSSL
3) Verify the request is malformed
   3.1) Extract the public key from request in #2 (pubexp = 0!)
   3.2) Verify the request using OpenSSL (verify failure)

You will notice that the public exponent of the public key output without
the patch is 0 (incorrect) and therefore the X.509 certificate request is
invalid. Applying the patch it will return the correct exponent (65537) and
request is now correct.


>
> > That's correct. This code does not process attributes. It keeps the
> > original call (which does the processing) and fixes the public
> > exponent, if appropriate. No other behavior should change other than
> > that. The only attribute targeted here is the public exponent (all
> > others are responsibility of the same players as before the patch.)
> >
> >
> >         Can you be more specific to what issue you're seeing here?
> >
> >
> >
> > Sure. The idea is the following:
> >
> >
> > 1) we need to check and return buffer too small upfront, because the
> > underlying functions will return generic errors if the buffer is
> > actually too small and there is no way from this level (and above) to
> > tell the difference. the only reason for the first check is to return
> > a more appropriate, and actionable, error code to the caller
>
>   I'm not seeing which generic errors you're referring to, can you give
> file/line #?
>
>
If you run the test case above you will notice the issues outlined,
especially the return code from original call to *
object_mgr_get_attribute_values* (the call in between the patch 2 sections).
If you want to get the generic error failure (which the first test in the
patch attempts to address), you will need an application that passes a
template with PUBLIC_EXPONENT defined and a buffer that is <3 bytes in size.


> Thanks,
> Kent
>
> > 2) if you have a buffer large enough for the exponent, we allow the
> > call to proceed. then:
> >
> >
> > 3) when it returns, we check if the exponent was filled by the
> > underlying layers. we noticed that 2 cases can happen:
> >   a) the exponent is filled by the callee (which happened if we
> > imported the private key into the TPM) and
> >   b) the exponent is not filled (which happened if we generated the
> > private key inside the TPM
> >
> > In (3a) I assume that happens because when I import the key it is
> > being stored "as is" and we pass the exponent as part of the private
> > key structure. Anyway, the if() check is prevent overwriting something
> > the callee already filled, and also does not make sense to copy over
> > the same data, and per the existing checks in place ensure the number
> > has to be 65537.
> >
> >
> >
> >
> >
> >
> >
> >          -Klaus
> >
> >
> >         --
> >         Klaus Heinrich Kiwi | [email protected] |
> >         http://blog.klauskiwi.com
> >         Open Source Security blog :     http://www.ratliff.net/blog
> >         IBM Linux Technology Center :   http://www.ibm.com/linux/ltc
> >
> >
> >
> ------------------------------------------------------------------------------
> > Protect Your Site and Customers from Malware Attacks
> > Learn about various malware tactics and how to avoid them. Understand
> > malware threats, the impact they can have on your business, and how you
> > can protect your company and customers by using code signing.
> > http://p.sf.net/sfu/oracle-sfdevnl
> > _______________________________________________ Opencryptoki-tech mailing
> list [email protected]
> https://lists.sourceforge.net/lists/listinfo/opencryptoki-tech
>
>
>
------------------------------------------------------------------------------
Protect Your Site and Customers from Malware Attacks
Learn about various malware tactics and how to avoid them. Understand 
malware threats, the impact they can have on your business, and how you 
can protect your company and customers by using code signing.
http://p.sf.net/sfu/oracle-sfdevnl
_______________________________________________
Opencryptoki-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opencryptoki-tech

Reply via email to