openssl 1.1 certificate verification fails with non-standard public key algorithm

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

openssl 1.1 certificate verification fails with non-standard public key algorithm

Ken Goldman-2
Seeking advice.

I have a certificate with a non-standard public key algorithm
-rsaesOaep.  See snippet #2.

With openssl 1.0, I can validate  the certificate chain.  With openssl
1.1 it fails with the error X509_V_ERR_EE_KEY_TOO_SMALL.  See dump #1.

I believe that this is due to new 1.1 code x509_vfy.c:check_key_level()
calling X509_get0_pubkey().  That call will fail for the non-standard
algorithm.

The certificate is for old vendor hardware that cannot be updated.  What
are my choices?

- Remain on 1.0
- Some configuration option?
- Something else?


#1 ~~~~~~~~~

openssl verify -CAfile cafile.pem infcert.pem

error 66 at 0 depth lookup: EE certificate key too weak
error infcert.pem: verification failed
22794983405376:error:0609E09C:digital envelope
routines:pkey_set_type:unsupported algorithm:crypto/evp/p_lib.c:206:
22794983405376:error:0B09406F:x509 certificate
routines:x509_pubkey_decode:unsupported
algorithm:crypto/x509/x_pubkey.c:113:

#2 ~~~~~~~~~

         Subject:
         Subject Public Key Info:
             Public Key Algorithm: rsaesOaep
             Unable to load Public Key
140619228055400:error:0609E09C:digital envelope
routines:PKEY_SET_TYPE:unsupported algorithm:p_lib.c:239:
140619228055400:error:0B07706F:x509 certificate
routines:X509_PUBKEY_get:unsupported algorithm:x_pubkey.c:155:
         X509v3 extensions:

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: openssl 1.1 certificate verification fails with non-standard public key algorithm

Viktor Dukhovni


> On Jul 25, 2018, at 10:05 AM, Ken Goldman <[hidden email]> wrote:
>
> I have a certificate with a non-standard public key algorithm -rsaesOaep.  See snippet #2.
>
> With openssl 1.0, I can validate  the certificate chain.  With openssl 1.1 it fails with the error X509_V_ERR_EE_KEY_TOO_SMALL.  See dump #1.
>
> I believe that this is due to new 1.1 code x509_vfy.c:check_key_level() calling X509_get0_pubkey().  That call will fail for the non-standard algorithm.
>
> The certificate is for old vendor hardware that cannot be updated.  What are my choices?
>
> - Remain on 1.0
> - Some configuration option?
> - Something else?

The immediate cause is the order of the checks in check_key_level().
It first checks for a supported key, and only then short-circuits
the logic at level <= 0 (my fault).  Perhaps level 0 should not be
strict in this way, in which case we might reverse the order of
then (pkey == NULL) and (level <= 0) tests:

static int check_key_level(X509_STORE_CTX *ctx, X509 *cert)
{
    EVP_PKEY *pkey = X509_get0_pubkey(cert);
    int level = ctx->param->auth_level;

    /* Unsupported or malformed keys are not secure */
    if (pkey == NULL)
        return 0;

    if (level <= 0)
        return 1;
    if (level > NUM_AUTH_LEVELS)
        level = NUM_AUTH_LEVELS;

    return EVP_PKEY_security_bits(pkey) >= minbits_table[level - 1];
}

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: openssl 1.1 certificate verification fails with non-standard public key algorithm

Ken Goldman-2
On 7/25/2018 10:47 AM, Viktor Dukhovni wrote:

>
>
>> On Jul 25, 2018, at 10:05 AM, Ken Goldman <[hidden email]> wrote:
>>
>> I have a certificate with a non-standard public key algorithm -rsaesOaep.  See snippet #2.
>>
>> With openssl 1.0, I can validate  the certificate chain.  With openssl 1.1 it fails with the error X509_V_ERR_EE_KEY_TOO_SMALL.  See dump #1.
>>
>> I believe that this is due to new 1.1 code x509_vfy.c:check_key_level() calling X509_get0_pubkey().  That call will fail for the non-standard algorithm.
>>
>> The certificate is for old vendor hardware that cannot be updated.  What are my choices?
>>
>> - Remain on 1.0
>> - Some configuration option?
>> - Something else?
>
> The immediate cause is the order of the checks in check_key_level().
> It first checks for a supported key, and only then short-circuits
> the logic at level <= 0 (my fault).  Perhaps level 0 should not be
> strict in this way, in which case we might reverse the order of
> then (pkey == NULL) and (level <= 0) tests:
>
> static int check_key_level(X509_STORE_CTX *ctx, X509 *cert)
> {
>      EVP_PKEY *pkey = X509_get0_pubkey(cert);
>      int level = ctx->param->auth_level;
>
>      /* Unsupported or malformed keys are not secure */
>      if (pkey == NULL)
>          return 0;
>
>      if (level <= 0)
>          return 1;
>      if (level > NUM_AUTH_LEVELS)
>          level = NUM_AUTH_LEVELS;
>
>      return EVP_PKEY_security_bits(pkey) >= minbits_table[level - 1];
> }

If you're suggesting that altering the above code to do the level check
before the call to get pkey, I think that would fix my problem.

... if I can set level to a negative value.  How do I set level?  Is
there an API or a configuration file.


--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: openssl 1.1 certificate verification fails with non-standard public key algorithm

Viktor Dukhovni


> On Jul 25, 2018, at 3:00 PM, Ken Goldman <[hidden email]> wrote:
>
>
> If you're suggesting that altering the above code to do the level check before the call to get pkey, I think that would fix my problem.

Yes, that's what I'm saying, but also asking the broader list for feedback
on such a change.  Should security level zero succeed even with unsupported
EE keys (which somehow get used with some other software???).

> ... if I can set level to a negative value.  How do I set level?  Is there an API or a configuration file.

It does not need to be negative, the test is "<= 0", but the default is
in fact -1 (not set).  There is indeed a function for setting a non-default
security level:

   X509_VERIFY_PARAM_set_auth_level()

and it is documented.

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: openssl 1.1 certificate verification fails with non-standard public key algorithm

Ken Goldman-2
On 7/25/2018 4:27 PM, Viktor Dukhovni wrote:
>
> Yes, that's what I'm saying, but also asking the broader list for feedback
> on such a change.  Should security level zero succeed even with unsupported
> EE keys (which somehow get used with some other software???).

For background, this is the TPM 1.2 endorsement key certificate.  I.e.,
this is a real application with millions of certificates issued.  The
key is an RSA-2048 key.

The TCG (for a while) specified

       Public Key Algorithm: rsaesOaep

rather than the commonly used

       Public Key Algorithm: rsaEncryption

because the key is an encryption key rather than a signing key.
The X509 certificate parser fails to get the public key.

~~~~~~~~~~~~~~~~~~~~~~~~

An alternative fix (I got a patch for 098 from an openssl maintainer)
that accepts rsaOaep would also fix the issue.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: openssl 1.1 certificate verification fails with non-standard public key algorithm

Viktor Dukhovni


> On Jul 25, 2018, at 4:50 PM, Ken Goldman <[hidden email]> wrote:
>
> For background, this is the TPM 1.2 endorsement key certificate.  I.e., this is a real application with millions of certificates issued.  The key is an RSA-2048 key.
>
> The TCG (for a while) specified
>
>      Public Key Algorithm: rsaesOaep
>
> rather than the commonly used
>
>      Public Key Algorithm: rsaEncryption
>
> because the key is an encryption key rather than a signing key.
> The X509 certificate parser fails to get the public key.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~
>
> An alternative fix (I got a patch for 098 from an openssl maintainer)
> that accepts rsaOaep would also fix the issue.

Or perhaps both.  It is not clear that my choice of rejecting
unsupported key algorithms at security level 0 is the right one,
but it would of course be best if the key algorithm were supported
if it has non-negligible "legitimate" use.

Perhaps open an issue (or PR) on github proposing (or implementing)
a change to the check_key_level() logic and see whether there is
support for it?

--
        Viktor.

--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users