.Net 9 Core > TPM Provider > tlsv1 alert decrypt error:../ssl/record/rec_layer_s3.c:1584:SSL alert number 51

[serkanturhanxl]

If I run the openssl server and client commands it communicates to each other.

openssl s_server -provider tpm2 -provider default -propquery '?provider=tpm2' -accept 4567 -key handle:0x81000006 -cert ssl_certificate.pem -cert_chain combinedchain.pem -cipher AES128-GCM-SHA256 -max_protocol TLSv1.2

openssl s_client -connect localhost:4567 -cipher AES128-GCM-SHA256 -debug -msg -min_protocol TLSv1.2 -max_protocol TLSv1.2

But If I implement the Server command into a console application and (client the same as console) It gives error:

Interop+Crypto+OpenSslCryptographicException: error:0A000093:SSL routines::decryption failed

Here is the client side error:

4067BCE3AC7F0000:error:0A00041B:SSL routines:ssl3_read_bytes:tlsv1 alert decrypt error:../ssl/record/rec_layer_s3.c:1584:SSL alert number 51

Here is the wiereshark screenshot.

This is the code I used to get key from TPM.

string handle = "handle:0x81000006";
SafeEvpPKeyHandle privateKey = SafeEvpPKeyHandle.OpenKeyFromProvider("tpm2", handle);
RSAOpenSsl rsa = new(privateKey);
X509Certificate2 tmpCert = new X509Certificate2("/etc/ssl/certs/ssl_certificate.pem");
X509Certificate2 certificate = tmpCert.CopyWithPrivateKey(rsa);

Here is the code to set sslOptions:

SslServerAuthenticationOptions sslOptions = new SslServerAuthenticationOptions
{
    EnabledSslProtocols = SslProtocols.Tls12, // Only use these protocols
    CipherSuitesPolicy = new CipherSuitesPolicy(new[]
    {
        TlsCipherSuite.TLS_RSA_WITH_AES_128_GCM_SHA256
    }),
    ServerCertificate = cert, //cert from 0x81000006 handle
    ClientCertificateRequired = true,
    EncryptionPolicy = EncryptionPolicy.RequireEncryption,
    
};
_stream.AuthenticateAsServer(sslOptions);

Here is the example application to reproduce the issue:
https://github.com/serkanturhanxl/TPMHandler

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones
See info in area-owners.md if you want to be subscribed.

[bartonjs]

@krwq Any immediate thoughts spring to mind?

[krwq]

First validate if encrypt and decrypt work with RSA instance you get from the provider - make sure to use public key directly rather than using provider key for verify/encryption.

Now assuming that works fine I have two things which come to my mind:

• lifetime bug: I noticed the test app disposes of RSA instance - it might be worth trying out if that's the case by removing the dispose and assigning RSA in the instance of your server/client somewhere to exclude that is the possibility
• possibly I missed to pass library context similarly to https://github.com/dotnet/runtime/blob/main/src/native/libs/System.Security.Cryptography.Native/pal_evp_pkey.c#L758 somewhere in https://github.com/dotnet/runtime/blob/main/src/native/libs/System.Security.Cryptography.Native/pal_ssl.c - if I were to guess right now maybe https://github.com/dotnet/runtime/blob/main/src/native/libs/System.Security.Cryptography.Native/pal_ssl.c#L207 - but that logic becomes really weird because I don't know what context to pass until I know which key is being used so it would likely need to be unified with setting private key in order to fix and making sure lifetime of LIB_CTX is still tracked correctly...

For a workaround right now you might need to use OpenKeyFromEngine instead which doesn't require separately passing OSSL_LIB_CTX along with EVP_PKEY

[GuyWithDogs]

I'm wondering if my question about where the OpenSSL default provider is being loaded (ref. #111250) might be relevant here.

Looking at the OpenSSL README-PROVIDERS page (https://github.com/openssl/openssl/blob/master/README-PROVIDERS.md), it says

The Default Provider
The default provider collects together all of the standard built-in OpenSSL algorithm implementations. If an application doesn't specify anything else explicitly (e.g. in the application or via config), then this is the provider that will be used. It is loaded automatically the first time that we try to get an algorithm from a provider if no other provider has been loaded yet. If another provider has already been loaded then it won't be loaded automatically. Therefore, if you want to use it in conjunction with other providers, then you must load it explicitly. This is a "built-in" provider, which means that it is compiled and linked into the libcrypto library and does not exist as a separate standalone module.

I did some experimenting using the openssl s_server command and found that it would fail if the default provider was not available, either as a -provider default parameter or by being activated in openssl.cnf.

[krwq]

It's possible although IIRC I've seen different errors when the right provider wasn't loaded. If any of you is interested in playing around with the source code in the meantime to speed the resolution then please go ahead - if not then I'll pick this up at one point (I'll be assigned when I start looking into this).

[serkanturhanxl]

It's possible although IIRC I've seen different errors when the right provider wasn't loaded. If any of you is interested in playing around with the source code in the meantime to speed the resolution then please go ahead - if not then I'll pick this up at one point (I'll be assigned when I start looking into this).

Do you have timeline when possibly you can look?

[krwq]

@serkanturhanxl I hope ASAP but I need to also take a look at some other seemingly more pressuring bugs at the moment so I don't have a clear timeline :-( This is still high on my priority list though

[GuyWithDogs]

Just to add some investigative results to what we're seeing on this issue:

In the earlier bug in .NET 8 with the TPM2 engine, there was a suggestion to validate that the certificate actually works, with a snippet of code
using (RSA rsa = cert.GetRSAPrivateKey()) { byte[] sig = rsa.SignData(Array.Empty<byte>(), HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1); Console.WriteLine($"Signature of empty data: {Convert.ToHexString(sig)}"); }

That code got added to the test program, and run. To double-check, a second certificate was created today using a new private key in the TPM2 and that combination was tried in the same test program. It fails.

The new certificate does work with the openssl s_server command line. It actually connected with our external device that wants to establish a TLS/SSL connection. So we think the actual certificates are OK.

But when we run the snippet above after loading the certificate from the TPM2 in our test server program, we get exceptions (as shown in the attached image below). Interestingly, it says `tpm2::unknown algorithm'.

Loading the existing certificate we use, from two PEM files for public and private components, generates a signature value (shown in other image below). That operation does not use the TPM2.

I don't know if this provides any more insight into the issue. I hope it does.

[appcodr]

@krwq Any luck with this issue?