Windows login (update of #64)

[Muzosh]

Introduction

I think I will have to re-open issue #64 since it was closed due to not being related to PivApplet, but to Windows AD login infrastructure (which pivoted to ECC usage)- I have the same issue, except now I know for sure, the issue is in PivApplet.

I have the following scenario:

• Windows AD and access to a machine with user TEST inside this AD with fresh installation of Windows 10
• access to a .pfx (PKCS12) file containing a Smart Card Logon certificate for TEST user in AD
• access to a YubiKey 5 NFC after fresh PIV reset (all other interfaces like OTP, FIDO, ... are turned off, only PIV functionality is turned on)
• access to a JavaCard with freshly installed PivApplet-0.9.0-jc222-RESAaD.cap (I will call this as PivApplet in the following text)

I performed these actions:

1. Imported .pfx file to YubiKey: yubico-piv-tool.exe -a import-key -s 9a -a import-certificate -k -i "<path-to-pfx-file>.pfx" -K PKCS12 (PivApplet was not connected to PC at that time)
2. Imported .pfx file to PivApplet: yubico-piv-tool.exe -r '<name-of-sc-reader>' -a import-key -s 9a -a import-certificate -k -i "<path-to-pfx-file>.pfx" -K PKCS12 (YubiKey was not connected to a PC at that time)
3. I logged into the machine as TEST user using regular password and ran certutil.exe -scinfo for both devices (while the other one was not connected to the machine) - the results were exactly the same except the reader name and key container ID - which means, it identified connected card as Identity Device (NIST SP 800-73 [PIV]) using the Provider Microsoft Base Smart Card Crypto Provider = this is OK since I expect to use the native PIV support in Windows
4. I locked the machine and connected only YubiKey - the Windows offered me another Sign-in option, which after selection required PIN. Upon inputing 123456 as default PIN, I was successfully logged in as TEST user
5. I locked the machine and connected only PivApplet- the Windows offered me another Sign-in option, but now, it says the No valid certificates were found on this smart card (sometimes it says Connect a smart card but this is probably an issue with sharing the resources over RDP, which I use to access the machine)

Why I think this is an issue with PivApplet?

I have access to another card containing proprietary applet, which is capable of storing certificates and keypairs (driver for this card was installed on the machine). I imported the .pfx file on this applet as well and it works out-of-the-box the same way the YubiKey does. So the issue is not in the certificate or Windows AD Smart Card Logon technology.

Something worth mentioning

I can make PivApplet work, but it is really inconsistent. I run the certutil.exe -scinfo while no other devices are connected. As mentioned, it prints the correct SmartCardLogon certificate. After it finishes, I can lock the machine and in that case it starts working (it prompts me for a PIN and after that I am logged in successfully). I can repeat this process multiple times, but as soon as I remove the card with PivApplet from the reader, the issue with No valid certificates were found on this smart card starts again.

What do I need help with?

Mainly, I do not really know, where to look for logs, debugging information, etc. I'm kinda new to this so I would appreciate some kind of guidance. Please let me know, which information I should append to this issue. Thanks

[dengert]

What you may be seeing is the Yubikey token is using the Yubico minidriver installed via plug-and-play when the token was first inserted. But the PIVApplet is using the built in windows PIV support, which AFAIK does not support ECC.

It looks like most (if not all) PIV device venders provide their own minidriver It is not clear if Microsoft has updated their builtin PIV driver to support ECC.

Look at registry: "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais"

Under "PIV Device ATR Cache" look at the ATRs which are using the builtin Microsoft minidriver.

Under "Smartcards" you should see "Identity Device (NIST SP 800-73 [PIV])" using msclmd.dll with no "ATR" or "ATRMask". It is used for any of the cached entries. You may also see other smartcards which do have "ATR" and ATRMask, installed by other means, including plug-and-play,

You might be able to copy a Yubikey entry and change the ATR and ATRMask to that used by the PIVApplet and remove the ATR from the "PIV Device ATR Cache" and see if the Yubikey minidriver will work with the PIVApplet

If the Yubikey minidriver does not work, you could also try the OpenSC minidriver in 0.23.0 (released yesterday) https://github.com/OpenSC/OpenSC/releases/tag/0.23.0

This added support for ECC keys. But because of the "most (if not all) PIV device venders provide their own minidriver." the PIV entries are not added to the registry, but could be added. See this as example:

See: https://github.com/OpenSC/OpenSC/issues/2426#issuecomment-1280934853

Also see Microsoft docs: https://learn.microsoft.com/en-us/windows-hardware/drivers/smartcard/smart-card-minidriver-overview https://learn.microsoft.com/en-us/windows-hardware/drivers/smartcard/smart-card-plug-and-play https://learn.microsoft.com/en-us/windows-hardware/drivers/smartcard/discovery-process

[dengert]

You might also be seeing confusion within the cert store as it is not normal to have the same cert and key on two different devices. You may have to use certutil.exe or mmc's snapin >certificates->My account or control panel->internet Options->content->certificates to remove any entries.

[Muzosh]

Thank you for such a fast response! Let me comment on that.

What you may be seeing is the Yubikey token is using the Yubico minidriver installed via plug-and-play when the token was first inserted.

This is strange since when I look into HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Calais\SmartCards and HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Cryptography\Calais, I see only entries for the windows PIV and for the third proprietary smart card. No Yubico PIV driver anywhere.

AFAIK does not support ECC. It looks like most (if not all) PIV device venders provide their own minidriver It is not clear if Microsoft has updated their builtin PIV driver to support ECC.

Sorry, I forgot to mention it in the original text. The Smart Card Logon certificate on all three cards is RSA-1024

I will try the rest (manipulating ATRs, or trying OpenSC) tomorrow and let you know.

[dengert]

RSA 1024 may also be a problem.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-78-4.pdf NIST recommends 2048 with SHA 256 I would look closer at windows AD on its restrictions.

Or just use 2048 RSA key with SHA256 for hash in your tests.

Yubico has: https://support.yubico.com/hc/en-us/articles/360015654560-Deploying-the-YubiKey-Minidriver-to-Workstations-and-Servers and has to be installed, not plug-and-play.

I tried their minidriver it with Yubikey 5 NFC with self signed certificates but they expired in 2021. Certutil --scinfo did not like them, but it was using their minidriver.

[Muzosh]

RSA 1024 may also be a problem.

Well, it does not seem to be the problem with the YubiKey and the proprietary card. The way I imported this RSA1024 certificate on both YubiKey and PivApplet, is the same command with Yubi-PIV-tool. I will try RSA2048 anyway.

I tried their minidriver it with Yubikey 5 NFC with self signed certificates but they expired in 2021. Certutil --scinfo did not like them, but it was using their minidriver.

Yea, my whole aim is to use the PivApplet for OS login (since it is supposed to be supported by Windows, MacOS) without the need to install any more drivers and libraries. Is this impossible? I thought the "Identity Device (NIST SP 800-73 [PIV])" using "Microsoft Base Smart Card Crypto Provider" is the native and automatically supported way of using PIV devices.

This is why certutil -scinfo uses "Identity Device (NIST SP 800-73 [PIV])" in Microsoft Base Smart Card Crypto Provider when analyzing currently connected YubiKey and has no problem with it.

These are just my comments, I will try to do suggested things and research more today.

[Muzosh]

Resolution

So.... It seems like I do not have to do anything. The problem seemed to be in the smart card reader I was using. The machine with the test AD and test Smart Card Logon certificate is remote and I'm using Remote Desktop Protocol to access it. Although I have shared resources in the settings, it seems like my connected smart card reader is pretty inconsistent and if there is a change that it will read the certificate from the card, Windows detects it as invalid. When I switch to a built-in smart card reader in my laptop and access the remote machine, it works 100 % of the time. It reads the PivApplet, obtains the certificate, ask for PIN and successfully logs me in using the Smart Card Logon certificate and built-in PIV driver.

For those who read this issue later

This issue was mainly about using Windows smart card login into an account managed by Active Directory. For that, you supposedly do not need any driver or library installations and Windows (11 in my case) should support PivApplet (from this repo) atuomatically, as long as you load a valid keypair and certificate (preferable in pfx format) into a 9a slot (using Yubi-PIV-tool for example: yubico-piv-tool.exe -r '<name-of-sc-reader>' -a import-key -s 9a -a import-certificate -k -i "<path-to-pfx-file>.pfx" -K PKCS12). The certificate should have an extension "Smart Card Logon" and it should be possible to somehow generate this in some AD management? (I'm not sure for know, I have received the pfx file from the admin who created the testing environment).

Log into the Windows for a local account might require some installations I think: https://support.yubico.com/hc/en-us/articles/360013708460-Yubico-Login-for-Windows-Configuration-Guide

[Muzosh]

@dengert I apologize if I wasted your time. Thank you very much for quick effort to help me, I really appreciate it.

[dengert]

I thought the "Identity Device (NIST SP 800-73 [PIV])" using "Microsoft Base Smart Card Crypto Provider" is the native and automatically supported way of using PIV devices

Correct. But their is some question if it supports ECC or not.

You should also add a CHUID (Yubikey-piv-tool can do this) The CHUID has a UUID that is used to create the ContainerID in the Microsoft cert store. Without that multiple cards may have the same ContainerID.

10 years ago, we where using government issued PIV cards for AD login. On windows we used the builtin PIV driver and on linux used OpenSC.

We also setup a way to issue temporary cards with certificates issued by AD CA if:

• user left their card at home
• real PIV broke
• user was a temporary visitor
• new employee had not yet been issues a gov PIV
• employee did not qualify for a gov PIV

Being retired 8 years now, I have a lot of free time and open source projects keep me busy. No apology needed.