Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID

Fuchs, Andreas
Hi all,

I'm currently implementing a TPM2 engine for OpenSSL over at https://github.com/tpm2-software/tpm2-tss-engine
The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA from my engine with any hash alg, even though the TPM's keys are restricted to just one specific hash alg.

Most recently, David Woodhouse pointed out the possibility to require a certain hash-alg from the key to TLS via the ameth ASN1_PKEY_CTRL_DEFAULT_MD_NID at https://github.com/tpm2-software/tpm2-tss-engine/issues/31

Since I'm not that familiar with OpenSSL, I wanted to confirm that I'm following the right path for implementing this.
Thus: Is the following approach correct ?

So, at https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L328:
- I need to call "const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const EVP_PKEY *pkey)" to get the ameth ?
- I need to call EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth, (*pkey_ctrl)) to some pkey_ctrl for ECC keys of mine ?
- That pkey_ctrl is a int (*pkey_ctrl) (EVP_PKEY *pkey, int op, long arg1, void *arg2)) that implements the op ASN1_PKEY_CTRL_DEFAULT_MD_NID ?
- That pkey_ctrl()'s ASN1_PKEY_CTRL_DEFAULT_MD_NID looks up the hash for the provided pkey's ecc key from the tpm2data and returns it via *(int *)arg2 = NID_sha1 or NID_sha256 or etc and then returns 1 or 2 or something ?
- Which one of the return codes (1 or 2) makes it mandatory rather than recommended ?

Thanks a lot for any advice,
Andreas
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID

William Roberts
On Wed, Nov 28, 2018 at 1:22 AM Fuchs, Andreas
<[hidden email]> wrote:
>
> Hi all,
>
> I'm currently implementing a TPM2 engine for OpenSSL over at https://github.com/tpm2-software/tpm2-tss-engine
> The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA from my engine with any hash alg, even though the TPM's keys are restricted to just one specific hash alg.

What about when keys aren't restricted to one specific signing scheme
and support raw encrypt/decrypt?
You could just synthesize it by building up the signature structure on
the client side
and using the raw primitives to encrypt the signing structure directly.

>
> Most recently, David Woodhouse pointed out the possibility to require a certain hash-alg from the key to TLS via the ameth ASN1_PKEY_CTRL_DEFAULT_MD_NID at https://github.com/tpm2-software/tpm2-tss-engine/issues/31
>
> Since I'm not that familiar with OpenSSL, I wanted to confirm that I'm following the right path for implementing this.
> Thus: Is the following approach correct ?
>
> So, at https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L328:
> - I need to call "const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const EVP_PKEY *pkey)" to get the ameth ?
> - I need to call EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth, (*pkey_ctrl)) to some pkey_ctrl for ECC keys of mine ?
> - That pkey_ctrl is a int (*pkey_ctrl) (EVP_PKEY *pkey, int op, long arg1, void *arg2)) that implements the op ASN1_PKEY_CTRL_DEFAULT_MD_NID ?
> - That pkey_ctrl()'s ASN1_PKEY_CTRL_DEFAULT_MD_NID looks up the hash for the provided pkey's ecc key from the tpm2data and returns it via *(int *)arg2 = NID_sha1 or NID_sha256 or etc and then returns 1 or 2 or something ?
> - Which one of the return codes (1 or 2) makes it mandatory rather than recommended ?
>
> Thanks a lot for any advice,
> Andreas
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID

Fuchs, Andreas
The problem is as follows:
The digest parameter of the TPM2_Sign command is checked against the hash algorithms supported by the TPM.
If the TPM only supports SHA256, then the maximum size for the digest parameter is 32 bytes.
So you cannot pass in a SHA512 hash, even though the TPM does not even perform a hash operation.
Kind of stupid, I know, but thats how it goes.
For RSA, I could "emulate" signing by using the TPM2_RSA_Decrypt command. For ECDSA however there is no equivalent.
Thus the tpm2-tss-engine will only support up to SHA384 (since that's what most TPMs support).

Therefore, the engine needs to communicate to OpenSSL's TLS not to negotiate SHA512.

That was apparently added für 1.0.1 and 1.1.1 recently as the ASN1_PKEY_CTRL_DEFAULT_MD_NID ameth ctrl.

I just don't know enough about OpenSSL as to where to start with this.

Anyone have any hints please ?

________________________________________
From: William Roberts [[hidden email]]
Sent: Friday, November 30, 2018 15:55
To: [hidden email]
Cc: Fuchs, Andreas
Subject: Re: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID

On Wed, Nov 28, 2018 at 1:22 AM Fuchs, Andreas
<[hidden email]> wrote:
>
> Hi all,
>
> I'm currently implementing a TPM2 engine for OpenSSL over at https://github.com/tpm2-software/tpm2-tss-engine
> The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA from my engine with any hash alg, even though the TPM's keys are restricted to just one specific hash alg.

What about when keys aren't restricted to one specific signing scheme
and support raw encrypt/decrypt?
You could just synthesize it by building up the signature structure on
the client side
and using the raw primitives to encrypt the signing structure directly.

>
> Most recently, David Woodhouse pointed out the possibility to require a certain hash-alg from the key to TLS via the ameth ASN1_PKEY_CTRL_DEFAULT_MD_NID at https://github.com/tpm2-software/tpm2-tss-engine/issues/31
>
> Since I'm not that familiar with OpenSSL, I wanted to confirm that I'm following the right path for implementing this.
> Thus: Is the following approach correct ?
>
> So, at https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L328:
> - I need to call "const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const EVP_PKEY *pkey)" to get the ameth ?
> - I need to call EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth, (*pkey_ctrl)) to some pkey_ctrl for ECC keys of mine ?
> - That pkey_ctrl is a int (*pkey_ctrl) (EVP_PKEY *pkey, int op, long arg1, void *arg2)) that implements the op ASN1_PKEY_CTRL_DEFAULT_MD_NID ?
> - That pkey_ctrl()'s ASN1_PKEY_CTRL_DEFAULT_MD_NID looks up the hash for the provided pkey's ecc key from the tpm2data and returns it via *(int *)arg2 = NID_sha1 or NID_sha256 or etc and then returns 1 or 2 or something ?
> - Which one of the return codes (1 or 2) makes it mandatory rather than recommended ?
>
> Thanks a lot for any advice,
> Andreas
> --
> openssl-users mailing list
> To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
--
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
Reply | Threaded
Open this post in threaded view
|

Re: Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID

Blumenthal, Uri - 0553 - MITLL
The way I understand the ECDSA standard, it is supposed to truncate the provided hash - which is why it is possible to have ECDSA-over-P256-SHA384.

One possibility would be for you to truncate the SHA2 output yourself, IMHO.

On 11/30/18, 12:36 PM, "openssl-users on behalf of Fuchs, Andreas" <[hidden email] on behalf of [hidden email]> wrote:

    The problem is as follows:
    The digest parameter of the TPM2_Sign command is checked against the hash algorithms supported by the TPM.
    If the TPM only supports SHA256, then the maximum size for the digest parameter is 32 bytes.
    So you cannot pass in a SHA512 hash, even though the TPM does not even perform a hash operation.
    Kind of stupid, I know, but thats how it goes.
    For RSA, I could "emulate" signing by using the TPM2_RSA_Decrypt command. For ECDSA however there is no equivalent.
    Thus the tpm2-tss-engine will only support up to SHA384 (since that's what most TPMs support).
   
    Therefore, the engine needs to communicate to OpenSSL's TLS not to negotiate SHA512.
   
    That was apparently added für 1.0.1 and 1.1.1 recently as the ASN1_PKEY_CTRL_DEFAULT_MD_NID ameth ctrl.
   
    I just don't know enough about OpenSSL as to where to start with this.
   
    Anyone have any hints please ?
   
    ________________________________________
    From: William Roberts [[hidden email]]
    Sent: Friday, November 30, 2018 15:55
    To: [hidden email]
    Cc: Fuchs, Andreas
    Subject: Re: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID
   
    On Wed, Nov 28, 2018 at 1:22 AM Fuchs, Andreas
    <[hidden email]> wrote:
    >
    > Hi all,
    >
    > I'm currently implementing a TPM2 engine for OpenSSL over at https://github.com/tpm2-software/tpm2-tss-engine
    > The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA from my engine with any hash alg, even though the TPM's keys are restricted to just one specific hash alg.
   
    What about when keys aren't restricted to one specific signing scheme
    and support raw encrypt/decrypt?
    You could just synthesize it by building up the signature structure on
    the client side
    and using the raw primitives to encrypt the signing structure directly.
   
    >
    > Most recently, David Woodhouse pointed out the possibility to require a certain hash-alg from the key to TLS via the ameth ASN1_PKEY_CTRL_DEFAULT_MD_NID at https://github.com/tpm2-software/tpm2-tss-engine/issues/31
    >
    > Since I'm not that familiar with OpenSSL, I wanted to confirm that I'm following the right path for implementing this.
    > Thus: Is the following approach correct ?
    >
    > So, at https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L328:
    > - I need to call "const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const EVP_PKEY *pkey)" to get the ameth ?
    > - I need to call EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth, (*pkey_ctrl)) to some pkey_ctrl for ECC keys of mine ?
    > - That pkey_ctrl is a int (*pkey_ctrl) (EVP_PKEY *pkey, int op, long arg1, void *arg2)) that implements the op ASN1_PKEY_CTRL_DEFAULT_MD_NID ?
    > - That pkey_ctrl()'s ASN1_PKEY_CTRL_DEFAULT_MD_NID looks up the hash for the provided pkey's ecc key from the tpm2data and returns it via *(int *)arg2 = NID_sha1 or NID_sha256 or etc and then returns 1 or 2 or something ?
    > - Which one of the return codes (1 or 2) makes it mandatory rather than recommended ?
    >
    > Thanks a lot for any advice,
    > Andreas
    > --
    > openssl-users mailing list
    > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
    --
    openssl-users mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
   

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

smime.p7s (7K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID

Fuchs, Andreas
Thanks for the hint... I'll implement this.

Nevertheless, padding is not supported as far as I understand, right ?

Thus, in order to prevent SHA256 on a P384 curve, I'll have to set the DEFAULT_MD_NID hint, right ?

Could anybody give me some feedback, whether my intended approach is correct ?

________________________________________
From: openssl-users [[hidden email]] on behalf of Blumenthal, Uri - 0553 - MITLL [[hidden email]]
Sent: Friday, November 30, 2018 18:44
To: [hidden email]; William Roberts
Subject: Re: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID

The way I understand the ECDSA standard, it is supposed to truncate the provided hash - which is why it is possible to have ECDSA-over-P256-SHA384.

One possibility would be for you to truncate the SHA2 output yourself, IMHO.

On 11/30/18, 12:36 PM, "openssl-users on behalf of Fuchs, Andreas" <[hidden email] on behalf of [hidden email]> wrote:

    The problem is as follows:
    The digest parameter of the TPM2_Sign command is checked against the hash algorithms supported by the TPM.
    If the TPM only supports SHA256, then the maximum size for the digest parameter is 32 bytes.
    So you cannot pass in a SHA512 hash, even though the TPM does not even perform a hash operation.
    Kind of stupid, I know, but thats how it goes.
    For RSA, I could "emulate" signing by using the TPM2_RSA_Decrypt command. For ECDSA however there is no equivalent.
    Thus the tpm2-tss-engine will only support up to SHA384 (since that's what most TPMs support).

    Therefore, the engine needs to communicate to OpenSSL's TLS not to negotiate SHA512.

    That was apparently added für 1.0.1 and 1.1.1 recently as the ASN1_PKEY_CTRL_DEFAULT_MD_NID ameth ctrl.

    I just don't know enough about OpenSSL as to where to start with this.

    Anyone have any hints please ?

    ________________________________________
    From: William Roberts [[hidden email]]
    Sent: Friday, November 30, 2018 15:55
    To: [hidden email]
    Cc: Fuchs, Andreas
    Subject: Re: [openssl-users] Question on implementing the ameth ctrl ASN1_PKEY_CTRL_DEFAULT_MD_NID

    On Wed, Nov 28, 2018 at 1:22 AM Fuchs, Andreas
    <[hidden email]> wrote:
    >
    > Hi all,
    >
    > I'm currently implementing a TPM2 engine for OpenSSL over at https://github.com/tpm2-software/tpm2-tss-engine
    > The problem I'm facing is that OpenSSL's TLS negotiation will request ECDSA from my engine with any hash alg, even though the TPM's keys are restricted to just one specific hash alg.

    What about when keys aren't restricted to one specific signing scheme
    and support raw encrypt/decrypt?
    You could just synthesize it by building up the signature structure on
    the client side
    and using the raw primitives to encrypt the signing structure directly.

    >
    > Most recently, David Woodhouse pointed out the possibility to require a certain hash-alg from the key to TLS via the ameth ASN1_PKEY_CTRL_DEFAULT_MD_NID at https://github.com/tpm2-software/tpm2-tss-engine/issues/31
    >
    > Since I'm not that familiar with OpenSSL, I wanted to confirm that I'm following the right path for implementing this.
    > Thus: Is the following approach correct ?
    >
    > So, at https://github.com/tpm2-software/tpm2-tss-engine/blob/master/src/tpm2-tss-engine-ecc.c#L328:
    > - I need to call "const EVP_PKEY_ASN1_METHOD *EVP_PKEY_get0_asn1(const EVP_PKEY *pkey)" to get the ameth ?
    > - I need to call EVP_PKEY_asn1_set_ctrl(EVP_PKEY_ASN1_METHOD *ameth, (*pkey_ctrl)) to some pkey_ctrl for ECC keys of mine ?
    > - That pkey_ctrl is a int (*pkey_ctrl) (EVP_PKEY *pkey, int op, long arg1, void *arg2)) that implements the op ASN1_PKEY_CTRL_DEFAULT_MD_NID ?
    > - That pkey_ctrl()'s ASN1_PKEY_CTRL_DEFAULT_MD_NID looks up the hash for the provided pkey's ecc key from the tpm2data and returns it via *(int *)arg2 = NID_sha1 or NID_sha256 or etc and then returns 1 or 2 or something ?
    > - Which one of the return codes (1 or 2) makes it mandatory rather than recommended ?
    >
    > Thanks a lot for any advice,
    > Andreas
    > --
    > openssl-users mailing list
    > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users
    --
    openssl-users mailing list
    To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

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