Windows 10 TPM 2.0 Client Authentication in TLS 1.2 with RSA PSS making trouble

Question

Hi everyone

I just wanted let you know that we have found an error in combination with TPM-saved RSA certificates and Client Authentication on TLS1.2 with newer Windows 10 Clients (probably all after 1909).
It seems that a lot of 2.0 TPMs have a problem with RSA PSS.

I wanted to share this problem because we have spent a lot of time to identify the issue. So I hope that other admins will find this post before they spend a lot of time in troubleshooting.

The issue happens during the TLS handshake. The TPM just doesn't signs the certificate verify step as shown on this print screen:

By disabling RSA PSS on the client, the client uses another cipher to sign the packet and then it works.
You can disable RSA PSS by following those steps:

• Backup this key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography\Configuration\Local\SSL\00010003
• Under Functions remove the following signature suites from the list:
• RSAE-PSS/SHA256
• RSAE-PSS/SHA384
• RSAE-PSS/SHA512
• Reboot

After the reboot, the client uses now RSA PKCS1 and the signature step runs successful:

The issue was initially identified on a EAP-TLS authentication for an IPSec tunnel. But the issue happens also on client certificate authentication on https websites as both use TLS for the handshake.

Keep in mind that this is only a workaround and should not be used as a final solution. We are actually still working with Microsoft on a solution.
It's still not 100% clear if it's the TPM that is making the issue or if it is the OS.

I will keep you updated...

Answer 1

I had opened a ticket with Microsoft on this specific issue. Response from support is below.

This is indeed a limitation with the TPM. Specifically, we have seen this behaviour with TPM v2.0 revision 1.16 (higher revisions do not exhibit this issue).

The TLS 1.3 RFC requires the RSA-PSS signature algorithm salt to be equal to the length of the output of the digest algorithm (also applies to TLS 1.2).

On the affected machines, the salt size does not match:
[TPM version: PCP_PLATFORM_TYPE: "TPM-Version:2.0 -Level:0-Revision:1.16-VendorID:'IFX '-Firmware:458815.858368"]

11/15/22-09:38:07.1611301 [Microsoft.Tpm.DebugTracing.KSP] [FunctionEnd] PartA_PrivTags=16777216, Name=DetectPSSPaddingSalt, HResult=The operation completed successfully. (0x00000000)
11/15/22-09:38:07.1611392 [Microsoft.Tpm.DebugTracing.KSP] [FunctionEnd] PartA_PrivTags=16777216, Name=TpmKey20Rsa::SignHash, HResult=The requested salt size for signing with RSAPSS does not match what the TPM uses. (0x40290423)
11/15/22-09:38:07.1611529 [Microsoft.Tpm.DebugTracing.KSP] [FunctionEnd] PartA_PrivTags=16777216, Name=ProviderSignHash, HResult=The requested salt size for signing with RSAPSS does not match what the TPM uses. (0x40290423)

Compare this with a working machine:
[TPM version: PCP_PLATFORM_TYPE: "TPM-Version:2.0 -Level:0-Revision:1.38-VendorID:'NTC '-Firmware:458754.131072"]

11/15/22-09:49:31.3205956 [Microsoft.Tpm.DebugTracing.KSP] [FunctionEnd] PartA_PrivTags=16777216, Name=DetectPSSPaddingSalt, HResult=The operation completed successfully. (0x00000000)
11/15/22-09:49:31.3206060 [Microsoft.Tpm.DebugTracing.KSP] [FunctionEnd] PartA_PrivTags=16777216, Name=TpmKey20Rsa::SignHash, HResult=The operation completed successfully. (0x00000000)
11/15/22-09:49:31.3206072 [Microsoft.Tpm.DebugTracing.KSP] [FunctionEnd] PartA_PrivTags=16777216, Name=ProviderSignHash, HResult=The operation completed successfully. (0x00000000)

The possible solutions are:

1. Upgrade the TPM to a higher revision (if available)
2. Disable the RSA-PSS signature algorithms on the client
3. Use a certificate that does not use RSA signature algorithms

We've been attempting to source a TPM upgrade to get us to subversion 1.38 on affected devices.

Answer 2

This problem gave me the following error when saving the Bitlocker recovery key in AzureAD:

Failed to backup BitLocker Drive Encryption recovery information for volume C: to your Azure AD.
TraceId: {....}
Error: Unknown HResult Error code: 0x80072f8f

Problem occured on Windows 11 version 10.0.22621

Removing the 3 registry values helped.

Output from tpmtool getdeviceinformation

-TPM Present: True
-TPM version: 2.0
-TPM Vendor ID: IFX
- Full name of TPM manufacturer: Infineon
-TPM Manufacturer Version: 7.63.3353.0
-PPI version: 1.3
-Is initialized: True
-Ready to save: True
-Ready for Evidence: True
-Is verifiable: True
-Must be deleted to restore: False
-Can be deleted: True
  Incorrect
-Bitlocker PCR7 Binding Status: Bound
-Maintenance task completed: True
-TPM specification version: 1.16
-TPM Errata Date: Wednesday, September 21, 2016
-PC client version: 1.00
-Lockout information:
         -Is blocked: False
         -Lockout counter: 0
         -Max. Authentication error: 31
         -Lockout interval: 600s
         -Lockout recovery: 86400s

Answer 3

Hi,

Welcome to Q&A platform.

Please kindly understand that analyze Wireshark network traffics is beyond our forum support level. Due to forum security policy, we have no such channel to collect user log information. So we recommend you open a case with MS Professional tech support service, they will help you open a phone or email case to Microsoft, so that you would get a technical support on a one-to-one basis while ensuring private information.

Here is the link:

https://support.microsoft.com/en-us/gp/customer-service-phone-numbers

Best Regards,
Sunny

----------

If the Answer is helpful, please click "Accept Answer" and upvote it.

Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.

Answer 4

THANK YOU for this. Mystery handshake error with EAP/TLS Wi-Fi authentication to Cisco ISE on Surface Pro 4 solved instantly. (after hours of head scratching in the lab)

Answer 5

Thanks for the information! This caused connection problems to the AlwaysOn VPN service in Azure on our user computers that were recently updated to the Win 10 23H2 version. Manually removing those three ciphers did fix the issue. Another solution is to revert back to 22H2 update.

The error message in Event viewer was:
The user xxxxx dialed a connection named xxxxx which has failed. The error code returned on failure is -1878457596.