Klaus,
Please find my comments inline below. I hope they make sense. Please let me
know if the explanations do not address all your questions and concerns
completely.
Regards,
Nelson Araujo
Software Engineer
Google
On Fri, Jan 14, 2011 at 8:50 AM, Klaus Heinrich Kiwi <
[email protected]> wrote:
>
> Diego Elio Pettenò <[email protected]> wrote:
>
>
> > @@ -120,6 +123,7 @@ CK_ULONG usage_count = 0; // variable for number of
> times the DLL has been used
> >
> > CK_C_INITIALIZE_ARGS cinit_args = { NULL, NULL, NULL, NULL, 0, NULL };
> >
> > +CK_BYTE pub_exp[] = { 0x1, 0x0, 0x1 }; // 65537
>
> I don't get this patch.
>
> Is there an actually valid scenario where the public exponent is simply
> not stored or not returned by the TPM device?
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.
> Is 0x010001 the default
> exponent to be considered in those cases per the TPM spec?
>
Yes, it is. And If you search your code base you will notice a places where
you have "65537" defined as constant for the public exponent and you also
have *explicit* checks to make sure caller does not provide another
exponent, such as "3" (look in tpm_util.c, new_host.c, tpm_specific.c and
tpm_openssl.c). Some checks *fail* the call if the exponent is not 65537.
>
> On Fri, 14 Jan 2011 01:17:55 +0100
> > extern void stlogterm();
> > extern void stloginit();
> > @@ -1926,11 +1930,34 @@ CK_RV SC_GetAttributeValue( ST_SESSION_HANDLE
> sSession,
> > goto done;
> > }
> >
> > + for (i=0; i<ulCount; i++) {
> > + if (pTemplate[i].type == CKA_PUBLIC_EXPONENT) {
> > + // 'object_mgr_get_attribute_values' requires the buffer to be
> > + // of the right size, otherwise it will fail with a too generic
> > + // error code. if buffer is too small, return to the caller
> > + // failure with more appropriate (specific) error code.
> > + if (pTemplate[i].ulValueLen < sizeof(pub_exp)) {
> > + rc = CKR_BUFFER_TOO_SMALL;
> > + goto done;
> > + }
> > + }
> > + }
>
> I'm not following that. From quick inspection to the
> object_get_attribute_values() function in
> usr/lib/pkcs11/common/object.c, looks like it is following the spec,
> returning
> CKR_BUFFER_TOO_SMALL and more important: continuing processing for the
> other template attributes (which your code is not).
>
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
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
