Windows Credential Provider: Is interactive Smart Card Logon supported with a certificate backed by Microsoft Software Key Storage Provider (KSP)?

Question

I am implementing a custom Windows Credential Provider that performs certificate-based interactive logon. Instead of using a physical smart card or a TPM Virtual Smart Card, my workflow relies on a software-backed key pair.

Here are the implementation steps:

1.Generate a temporary non-exportable RSA key using the Microsoft Software Key Storage Provider (CNG KSP).

2.Generate a PKCS#10 CSR and submit it to an Enterprise CA.

3.Receive a valid Smart Card Logon certificate.

4.Install the certificate into the Current User "My" store and associate it with the generated CNG key by setting CERT_KEY_PROV_INFO_PROP_ID.

5.Populate a KERB_CERTIFICATE_UNLOCK_LOGON structure containing KERB_SMARTCARD_CSP_INFO.

6.Return the serialized credential packet from ICredentialProviderCredential::GetSerialization.

Certificate Details:

Enhanced Key Usage (EKU): Smart Card Logon (1.3.6.1.4.1.311.20.2.2) and Client Authentication (1.3.6.1.5.5.7.3.2).

SAN: Populated with the correct UPN.

Private Key: Non-exportable, resident in Microsoft Software Key Storage Provider.

The Issue: When submitting the serialized credential structure, ReportResult() returns ERROR_INVALID_PARAMETER (0x57).

Before spending more time debugging the buffer alignment, string offsets, or serialization code within KERB_SMARTCARD_CSP_INFO, I need to verify whether this architectural approach is fundamentally supported by the Windows Kerberos SSP.

My Questions:

Does Windows interactive Smart Card Logon natively support certificates whose private keys are stored in a software-only KSP (like Microsoft Software Key Storage Provider), or does the Kerberos authentication package strictly enforce that the provider must be a hardware-backed Smart Card KSP/CSP (or TPM Virtual Smart Card)?

Can KERB_CERTIFICATE_UNLOCK_LOGON or KERB_CERTIFICATE_LOGON be used with a pure software KSP, or do the underlying sub-systems rely on lower-level smart card IOCTLs that fail when using a software provider?

If software-backed KSP keys are supported for this specific serialization flow, are there any undocumented requirements or constraints for the fields inside KERB_SMARTCARD_CSP_INFO (e.g., CspName, KeySpec) when referencing a pure software provider?

Our goal is to achieve a temporary, software-defined certificate logon flow for automated environments without provisioning physical or virtual hardware smart cards.

Any clarification or reference to official documentation regarding this design constraint would be greatly appreciated.

Answer 1

Hello @Jamal ,

Thank you for providing such a detailed overview of your implementation.

I believe the software KSP approach for interactive logon faces an architectural limitation with the Local Security Authority (LSASS). The official architectural overview on How Smart Card Sign-in Works in Windows outlines how physical cards operate, but implicitly, the pre-logon phase executes under the SYSTEM authentication context. Because of this, LSASS might not be able to interact with a user's DPAPI-protected private key in the Current User store before the actual session is established. Hardware tokens process this independently, which might explain why they succeed where a software KSP fails.

Regarding the ERROR_INVALID_PARAMETER (0x57), this often points to IPC serialization constraints rather than a direct KSP rejection. While the KERB_CERTIFICATE_UNLOCK_LOGON documentation details the struct members, the LSA subsystem typically expects a strictly flat, contiguous memory buffer when passing structures to the authentication package. If the payload relies on standard memory pointers for strings instead of precise relative offsets within a single allocated block, the subsystem tends to reject it immediately.

If the SYSTEM versus User-space hurdle proves unviable for the automated environment, exploring TPM Virtual Smart Cards might be a practical alternative. Windows treats a TPM VSC as an always-inserted physical smart card, aligning with pre-logon LSASS requirements. The Virtual Smart Card Overview details this functionality, and its deployment can still be fully automated using built-in tools like tpmvscmgr.exe without needing physical hardware.

I hope this provides some helpful direction for your design. Let me know if you have any questions. If you found my response helpful or informative, I would greatly appreciate it if you could follow this guide for your confirmation.

Thank you.