Kent,
We exercised the latest patch and everything looks great. We believe this
latest patch works fine. What is the process for committing it into the
tree?
Regards,
Nelson Araujo
Software Engineer
Google
On Wed, Mar 2, 2011 at 11:55 AM, Nelson Araujo <[email protected]>wrote:
> Sorry for the delayed response. We will be testing the patch no later than
> this weekend and get back if it works in all scenarios.
>
> Best regards,
> -- Nelson
>
>
>
>
> On Thu, Jan 20, 2011 at 1:56 PM, Kent Yoder <[email protected]> wrote:
>
>> On Thu, 2011-01-20 at 13:45 -0800, Nelson Araujo 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.
>>
>> Nope, no reason, I can change that.
>>
>> Kent
>>
>> >
>> > 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
>> > >
>> > >
>> >
>> >
>> >
>> >
>> >
>>
>>
>>
>
------------------------------------------------------------------------------
Colocation vs. Managed Hosting
A question and answer guide to determining the best fit
for your organization - today and in the future.
http://p.sf.net/sfu/internap-sfd2d
_______________________________________________
Opencryptoki-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opencryptoki-tech
