Decrypt my World : Smart Card

How to clean up expired certs on your smart card

alejacma — Thu, 30 Oct 2008 13:37:00 GMT

Hi all,

The other day a colleague of mine was trying to renew his smart card certificate, but he got an error telling him that there was not enough space in the card to store the new cert. So he asked me: Alex, how can I delete a certificate from my smart card so there is room for a new one?

Well, admins generally have special tools for this task, but sometimes it may be necessary for an end/admin user to manually free up space on an smart card in order to enroll or renew certs. If you are in this situation, you may follow these steps:

1) Run the following command to get a list of certificates stored in the smart card:

certutil -scinfo > output.txt

Note: Certutil tool should be included on Windows Vista/Server 2008 by default. You may also get it from Windows Server 2003 Admin Pack, for instance.

Cerutil may request the smart card PIN several times. You can safely ignore these requests by pressing Esc every time. You will finally get a dialog with a list of certificates in the card (in my particular case I got 3 certs, and one of them had already expired). Now close that dialog and wait until certutil finishes running.

2) Take a look to output.txt. For example, in my case the first cert (“Certificate 0”) was the expired one (I could see strings like “Chain on smart card is invalid”, “CERT_TRUST_IS_NOT_TIME_VALID” and “Expired certificate”). Copy its related “Key Container” value (“f6138188-3725-4c2b-8cf6-9c421d8bee69” in my case).

3) Run the following command to remove the certificate associated to the key container you copied before:

certutil -delkey -csp "Microsoft Base Smart Card Crypto Provider" "f6138188-3725-4c2b-8cf6-9c421d8bee69"

Note: your smart card CSP may be different. Use yours.

Now you should be able to store a new cert in the card.

I hope this helps.

Kind regards,

Alex (Alejandro Campos Magencio)

PKCS#11 interface support on Windows 2000/Server 2003

alejacma — Thu, 06 Mar 2008 09:07:00 GMT

Hi all, welcome back,

I recently had some issues involving PKCS#11 interface on Windows, and it seems quite clear that we don't support it, at least on Windows 2000 & Server 2003, and as far as I know on any other version of Windows:

Public Key Interoperability
"
Hardware Support
...
Windows 2000 uses CryptoAPI to abstract hardware-based key management from applications and uses the PC/SC standard instead of PKCS#11 to communicate with smart cards and readers. Entrust, Netscape and Baltimore have their own cryptographic APIs and use PKCS#11 to interface to hardware tokens like smart cards. IBM uses CDSA as its cryptographic framework that includes support for hardware devices. Because Windows 2000 requires hardware devices to also support Plug and Play and Power Management features, and Microsoft's implementation of PC/SC includes support for these ease-of-use features, there are no plans to add support for PKCS#11 in Windows 2000.
"

Evaluating Factors That Affect Extended Trusts
"
Algorithm Support
...
Windows Server 2003 uses CryptoAPI to abstract hardware-based key management from applications, and it uses the PC/SC standard instead of PKCS#11 to communicate with smart cards and readers. Many third-party CAs have their own cryptographic APIs and use PKCS#11 to interface to hardware tokens such as smart cards. Because Windows 2000 and Windows Server 2003 require hardware devices to support Plug and Play and power management features, and PC/SC includes support for these ease-of-use features, Windows Server 2003 does not support PKCS#11.
Note
• The Windows Server 2003 PKI can use third-party CSPs, and can enroll users for certificates that have keys that were generated by third-party CSPs.
"

So if you have any issues with a PKCS#11 interface, Microsoft Technical Support is not the one you should contact, but the provider of the interface instead.

I hope this helps.

Cheers,

Alex (Alejandro Campos Magencio)

How to select which Smart Card reader to perform actions on

alejacma — Mon, 03 Mar 2008 14:40:00 GMT

Hi all, welcome back,

Most of the time we only have a smart card reader in our machine, and we only use one smart card to perform crypto operations. But what if we have several readers and cards, and those cards share the same CSP (Cryptographic Service Provider)? Can we select the one we want to use when working with CryptoAPI/XEnroll/CertEnroll?

Let's take a look to XEnroll, for instance: We can set WriteCertToCSP Property of the ICEnroll4 Interface to TRUE so the certificates will be written to the smart card in addition to being written to "MY" store when calling i.e. acceptPKCS7 method (Note: WriteCertToCSP is TRUE by default). But apparently we can't specify which card we want to write the cert to. So what happens if we have two cards with same CSP inserted at the same time? Well, in this case the CSP itself will be responsible of giving the user the possibility to choose the card it wants. When we enroll the cert, the CSP should show a dialog so we can choose the appropiate card.

As you sure know, XEnroll won’t work on Vista. Vista now uses the new certificate enrollment component CertEnroll (see Certificate Enrollment API for more info). But my comments still apply here: the CSP should help us to choose the card.

And what if we want to do the selection programmatically? Can that be done? Yes, we may be able to do it. If we want to select the card for the CSP then we should figure out which reader the card is in, and then use the "\\.\<Reader Name>\" format for the container name when calling CryptAcquireContext API, for instance. If we also know the container name we can use "\\.\<Reader Name>\<Container Name>\" (See the smart card white paper for more details on our MS Base CSP). The CSP should be able to work with the right card.

I hope this helps.
Cheers,

Alex (Alejandro Campos Magencio)

SCardGetStatusChange fails with SCARD_E_NO_SERVICE error

alejacma — Mon, 17 Dec 2007 12:41:00 GMT

Hi, welcome back,

Smart Card Redirection on Microsoft Remote Desktop Protocol (RDP) client 6.0 may cause SCardGetStatusChange to fail with error 0x8010001d - SCARD_E_NO_SERVICE - "The Smart card resource manager is not running.".

When a user connects from her machine A (i.e. Windows XP SP2) to a remote machine B (i.e. Windows Vista) using Microsoft RDP client, she can use her smart card inserted in a reader on machine A to perform operations on remote machine B. This is called smart card redirection and is enabled by default.

However, from RDP client 6.0 on, there appears to be a problem with applications on machine B which call SCardGetStatusChange() in order to monitor smart card status changes, such as smart card insertions and removals. SCardGetStatusChange API fails with the error shown above. Previous versions of the RDP client did not exhibit this problem.

Well, I've seen that this issue happens when some fields of the rgReaderStates structure being passed to SCardGetStatusChange are not being initialized, so they contain invalid values that SCardGetStatusChange tries to use unsuccessfully.

A piece of advice: clean up the fields of the rgReaderStates structure before calling SCardGetStatusChange, so all unused fields are set to 0.

I hope this helps.

Cheers,

Alex (Alejandro Campos Magencio)

Smart Card's PIN gets cached

alejacma — Wed, 12 Dec 2007 21:00:00 GMT

Hi, welcome back,

When we use a Smart Card with any application (i.e. Internet Explorer), the PIN that user inserted to access the card the first time may get cached and not requested again during the live of the application. But what if we need the PIN to be requested everytime we use the card with that application?

The Smart Card CSP (Crypto Service Provider) is in charge of PIN cache. PIN is cached by card/process/time.

We may have two possible solutions here:

1) The CSP has a parameter that we can set in i.e. the registry to disable the PIN cache. This depends on the CSP.

2) We can flush the cache with CryptSetProvParam API, but not all CSP implement this. Microsoft Base Smart Card Crypto Provider implements it, for instance. This is the way we should call this CryptoAPI:

CryptSetProvParam(hProv, PP_SIGNATURE_PIN, NULL, 0)

I hope this helps.

Cheers,

Alex (Alejandro Campos Magencio)