Windows 11 24H2 Smart Card PIV with ECC Certificates

Question

My company utilizes smart cards with ECC Certificates. Pre-24H2, we had no issues with signing in on/off-net, SSO, etc. for two years (Win 10 or 11). Post W11 24H2, smart card users can not log into their devices off-net. Even while On-Net, the users token for MFA is non-existent. A user is prompted via MFA for every Microsoft Application when first run after logging in. A reboot forces MFA again. This effects four different manufacturers with Intel 13th Gen+ (No AMD W11 24H2). I have done the following:

All drivers / firmware / BIOS updated

Cleared / reset TPM

Refreshed PC from Internet download

Refreshed PC from local re-install

Dell Data wipe and reload using OS Recovery

Enabled WHfB successfully and this DOES work off-net utilizing external security key

I created a test account, duplicated our smart card template, but changed the algorithm to RSA 2048. It all works. Everything. SSO, off-net, etc. I noticed this in the depreciated list: TLS server authentication certificates using RSA keys with key lengths shorter than 2048 bits. This is client authentication and not server, but ECC or ECDH certificates use ECDH_P256, ECDH_384, ECDH_512. The minimum key sizes are 256 / 384 / 512 respectively. RSA key's use 1024 / 2048, etc. Did this depreciation of key lengths take into account not just RSA key length but also ECC key length? From what I can tell, it looks as if this depreciation is not allowing a Windows 11 24H2 device to login via a smart card using ECC Certificates off-net / SSO / Tokens, etc from working. Can someone else confirm?

***Move from Windows / Windows 11 / Windows update ***

Answer 1

Thank you for taking the time to reply. ECC certificates are actually more secure than RSA at a base level. I have contacted the smart card manufacturer and they are unaware of any issues. I have contacted the computer manufacturers and they are unaware of any issues. I can 100% prove 24H2 is the issue. I can take a machine, load 23H2 and everything works as expected. I can take the same machine, load 24H2, the issue happens. I am using the built in Microsoft Smart Card Provider and nothing custom. I believe the issue is something with VBS and the new guard features added, along with accessing the TPM. Once logged in, the ticket and token are not saved, or they are saved but inaccessible to the user. If that is the case with them not saving or inaccessible from the user, when logging in off-net, you get a failure. That is the issue! Using a password or WHfB DOES save, but certificates do not. No users have admin rights on a machine, but even granting those rights makes no difference.

I appreciate the thoughtfulness of checking MFA configurations, but going backwards to SMS, CAPTCHA, etc. is a no go.

If this was a single manufacturer / model, I would point a finger at the manufacturer for their incompatible driver(s). This is not just one manufacturer. This is not just a single Intel model proc. The only common factor between all the variations of machine and hardware I have is Windows 11 24H2.

Answer 2

I have not had it fail on reading the certificates AFTER I was fully logged in, but the Azure PTR Token is not present or saved. I also turned off all VBS in the BIOS along with memory intergrity, etc. I forced off all VBS on Windows 11 after the change and still had the issue. Removing all smart card drivers did not yield results either.

About 10 months ago we went through something similar like this. That issue was with the TPM Module dropping (good job Lenovo with a terrible BIOS hence, no more Lenovo!). Once the TPM dropped, Windows would put the certificate / token into a hidden folder on the C drive that only Administrators could access. It was easy to prove by giving a user Admin rights to complete a login, then use their certificate with webpages / MS Apps. Once the TPM was re-established, you had to remove their certificate from the store, drop all saved credentials and folders relating to MS Apps and reboot. I have gone through this process again with no change.

Through extensive testing with an RSA certificate, everything is working perfectly. With ECC, only on-network devices successfully work, but MS Apps will not save credentials. Here are the tests / steps I have tried:

ECC Smartcard fails off-network, on-network login works, MS Apps not saving credentials regardless of login

RSA Smartcard good off/on-network and MS Apps DOES save credentials

Cleared TPM - ECC still broke, RSA good

Dropped / re-added to domain - ECC still broke, RSA good

Reloaded Windows 11 24H2 overtop - ECC still broke, RSA good

Refreshed Windows with local install AND downloaded install - ECC still broke, RSA good

Data wiped drive and re-installed Windows 11 locally - ECC still broke, RSA good

In all instances after the reload:

running: certutil -scinfo with the RSA certificate on login yielded successful chain validation on-network / off-network

running: certutil - scinfo with ECC certificate on login yielded successful chain validation as long as on network. If logged in and network removed, chain validation fails.

Cleared smart card drivers - ECC still broke, RSA good

Cleared all certs / drivers- ECC still broke, RSA good

Turned off VBS after reload - ECC still broke, RSA good

Enabled WHfB - Security key works / ECC still broke, RSA good

I did have ONE test that work with ECC, but it was a complicated one. With VBS fully enabled across the board, I cleared all certs / credentials. Logged in on-network with a password. Enabled WHfB and registered a security key. Logged in successfully with security key using WHfB on-network. Locked computer, logged in with ECC Certificate. Locked computer, logged in with WHfB. Rebooted, logged in with ECC Certificate on-network. ALL future ECC Logins worked on-network/off-network including MS Apps. Once I turned off WHfB, smartcard login with ECC Broke off-network and MS Apps. What is happening here when WHfB is enabled? Is it changing how all logins are cached?

This to me points to what security for certificates with device guard / credentials guard Microsoft took in this update. The process of chain validation is acting like the intermediate / root certificate can not be verified when off network. This should be a local check, but Windows is acting like the intermediate and root are not there and the cached CRL checks are not saved using ECC. Ill re-iterate, 23H2 does not have this issue!!!

Seriously Microsoft, chime in here....

Answer 3

I can confirm that Windows 11 version 24H2 introduced a regression issue for stroring ECC smart card login credentials. Below is a description of the online/offline smart card login tests with RSA and ECC keys on various Win 10 and Win 11 platforms. All the tests were done using WHQL certified minidriver and with all protection mechanisms ON. As a pre-requisite for all tests the 1st run is done with DC available. Online = DC available, offline = DC not available.

RSA keys smart card login:

Any platform – online and offline RSA login works

ECC keys smart card login:

Win10 any – online and offline login ECC work

Win11 22H2 – online and offline ECC work

Win11 23H2 – online and offline ECC work

Win11 24H2 – online ECC works , offline ECC NOT working!

Conclusion:

Microsoft update to 24H2 introduced a regression bug related to the cached ECC smart card login credentials storage and protection. On Windows11 24H2 the lsass.exe process never calls the appropriate WHQL certified smart card minidriver’s functions needed for deriving the encryption key (CardConstructDHAgreement, CardDeriveKey, CardDestroyDHAgreement ), while in all previous version of Win10 and Win11 it does.

Implications:

As this issue appears to affect also any US government/Security apparatus employees using PIV cards with ECC there could be a serious impact in the field out there. Also outside of the US is ECC cryptography much more frequently used./

Answer 4

JanPuskar,

Thank you for digging into this and proving I am not out of my mind! This issue is not just related to login scenarios. Since the call is not made, any Microsoft app that is opened requires re-authentication each time opened. This means that even if you are Online, opening Outlook or any other Microsoft App / SSO integrated app, you are forced to re-authenticate per app!

Microsoft, this is not a small issue. As JanPuskar implied, Gov't agencies and EU use ECC. Can we get this escalated?

Answer 5

Thank you for that information. So if I follow this correctly, it seems that Memory Integrity is blocking the Agreements and DeriveKey from properly storing at time of login. Turning off allows this to execute, turning back on protects the MIM attacks and since the key is already stored on the machine, it can be used until the next password change / logon cached count / etc. This still does not correct the issue of even if logged into the PC on the domain, O365 can not access the saved credentials because I guess it is still being blocked by Memory Integrity.

I did try turning off all VBS, including Memory Integrity, but still had the same issue previously. Unless a fix was implemented in the last 30 days, I believe the issue still exists. Luckily, we have <1000 users and the ability to shift certificates for users in a less painful manner than manually accessing each key.