And I suggest you add "// 65537" as well to make it easier to spot like in
other tpm_specific.c places (or consider moving them all to a global static
variable?)
943 CK_BYTE pub_exp[] = { 0x1, 0x0, 0x1 }; // 65537
Best regards,
-- Nelson
On Thu, Jan 20, 2011 at 1:45 PM, Nelson Araujo <[email protected]>wrote:
> Sounds like a good plan to me.
>
> Is there any reason you have an extra byte "0" in the public exponent
> array? If you don't I suggest removing as for 65537 exponent a buffer with 3
> bytes would be enough (if the app knows what's dealing with) and having it
> with 4 will fail with buffer too small.
>
> Best regards,
> -- Nelson
>
> On Thu, Jan 20, 2011 at 1:18 PM, Kent Yoder <[email protected]> wrote:
>
>> On Wed, 2011-01-19 at 15:48 -0800, Nelson Araujo wrote:
>> > Forgot to mention that you need to change "111111" in the sample below
>> > with your actual TPM user PIN for the change to work.
>>
>> Thanks Nelson, I was able to reproduce the issue.
>>
>> It looks like opencryptoki by default creates an empty public exponent
>> attribute for all rsa private keys, but then doesn't fill that attribute
>> in with its correct value. This probably hasn't come up before since
>> most software will query the public exponent from the public key object,
>> where its a required attribute, as opposed to the private key object,
>> where its not required.
>>
>> Right now, opencryptoki and the caller are both doing the "correct"
>> thing in the use of C_GetAttributeValue -- the app queries the public
>> exponent attribute, opencryptoki sees its a valid attribute and returns
>> its length (since the app passed in NULL as the pValue pointer) but
>> opencryptoki is operating on an incorrectly filled out template it
>> created.
>>
>> When using your patch, the checking of the real attribute value will
>> be bypassed, which is really just covering for the fact that
>> opencryptoki created an invalid attribute for that object.
>>
>> I think the right solution here will be to add code to opencryptoki's
>> tokens to correctly fill out the private key object's public exponent
>> attribute, then all should work correctly. Below is a patch that does
>> this for the TPM token. Let me know if it works for you. It did fix
>> the public exponent value in the generated cert for me, although openssl
>> verify passed on all of the certs I generated (even when public exponent
>> was 0).
>>
>> Thanks,
>> Kent
>>
>> diff --git a/usr/lib/pkcs11/tpm_stdll/tpm_specific.c
>> b/usr/lib/pkcs11/tpm_stdll/tpm_specific.c
>> index d5708c3..b31a861 100644
>> --- a/usr/lib/pkcs11/tpm_stdll/tpm_specific.c
>> +++ b/usr/lib/pkcs11/tpm_stdll/tpm_specific.c
>> @@ -2374,6 +2374,7 @@ token_specific_rsa_generate_keypair( TEMPLATE *
>> publ_tmpl,
>> CK_ULONG mod_bits = 0;
>> CK_BBOOL flag;
>> CK_RV rc;
>> + CK_BYTE tpm_pubexp[] = { 0, 1, 0, 1 };
>>
>> TSS_FLAG initFlags = 0;
>> BYTE authHash[SHA1_HASH_SIZE];
>> @@ -2490,6 +2491,13 @@ token_specific_rsa_generate_keypair( TEMPLATE *
>> publ_tmpl,
>> template_update_attribute( priv_tmpl, attr );
>> Tspi_Context_FreeMemory(tspContext, rgbBlob);
>>
>> + /* put the public exponent into the private key object */
>> + if ((rc = build_attribute(CKA_PUBLIC_EXPONENT, tpm_pubexp,
>> sizeof(tpm_pubexp), &attr))) {
>> + st_err_log(84, __FILE__, __LINE__);
>> + return rc;
>> + }
>> + template_update_attribute( priv_tmpl, attr );
>> +
>> /* wrap the authdata and put it into an object */
>> if (authData != NULL) {
>> if ((rc = token_wrap_auth_data(authData, publ_tmpl,
>> priv_tmpl))) {
>>
>>
>>
>> > Best regards,
>> > -- Nelson
>> >
>> >
>> > "Education is the antidote to war."
>> > -- Scott Adams
>> >
>> >
>> >
>> > On Wed, Jan 19, 2011 at 3:45 PM, Nelson Araujo
>> > <[email protected]> wrote:
>> >
>> > On Wed, Jan 19, 2011 at 1:42 PM, Kent Yoder
>> > <[email protected]> wrote:
>> >
>> > > a) OpenSC package
>> > > b) OpenSSL package
>> > > c) TPM hardware (e.g. Thinkpad T400 laptop)
>> > > d) Both OpenSC and OpenSSL configured to use
>> > openCryptoki
>> >
>> > Thanks Nelson. Which gateway from openssl -> pkcs11
>> > are you using? One
>> > of the engines?
>> >
>> >
>> > I am using engine_pkcs11.so. To pair OpenSSL => pkcs11 I am
>> > using the following config patch (apply to
>> > your /etc/<your-dist>/openssl.cnf):
>> >
>> >
>> > --- apps/openssl.cnf.ORG 2010-12-07
>> > 09:24:50.000000000 -0800
>> > +++ apps/openssl.cnf 2010-12-07 09:25:42.000000000
>> > -0800
>> > @@ -12,6 +12,21 @@
>> > #oid_file = $ENV::HOME/.oid
>> > oid_section = new_oids
>> >
>> >
>> > +openssl_conf = openssl_def
>> > +
>> > +[openssl_def]
>> > +engines = engine_section
>> > +
>> > +[engine_section]
>> > +pkcs11 = pkcs11_section
>> > +
>> > +[pkcs11_section]
>> > +engine_id = pkcs11
>> > +dynamic_path = /usr/lib/engines/engine_pkcs11.so
>> > +MODULE_PATH
>> > = /usr/lib/opencryptoki/libopencryptoki.so.0
>> > +PIN = 111111
>> > +init = 0
>> > +
>> > # To use this configuration file with the "-extfile"
>> > option of the
>> > # "openssl x509" utility, name here the section
>> > containing the
>> > # X.509v3 extensions to use:
>> >
>> >
>> > Best regards,
>> > -- Nelson
>> >
>> >
>> >
>> >
>> >
>> > Kent
>> >
>> >
>> > > 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
>> >
>> >
>>
>>
>>
>
------------------------------------------------------------------------------
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d
_______________________________________________
Opencryptoki-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opencryptoki-tech
