Installing New Cryptographic Service Providers

  • Article

The following article was kindly written byAdrian Beasley

General

That splendid company Smartcard focus (**ED - the broken link is now fixed**), purveyors of smart cards and ancillary equipment to the general public, has a number of types of card available, not all of them smart (many types are simple memory cards). Their best selling smart card has historically been the Cryptoflex for Windows, from Gemalto (formerly Axalto, formerly Schlumberger). The Cryptographic Service Provider required for these (i.e. Schlumberger) is already present in the default set in Windows Cryptographic Services. These cards are supplied already initialised, and they can be used to enrol certificates without further ado. They are very straightforward to use. I bought several of these and I recommend them.

The Rolls-Royce of the selection is evidently the StarCos SPK2.4 FIPS card. They claim a very high level of security, and cost around 3 times the Cryptoflex. I bought a couple of specimens to evaluate, and have recently been doing so. The cards are produced by Giesecke & Devrient GmbH (www.gi-de.com), but the software necessary to use them is called SafeSign and is from A.E.T.Europe B.V. (www.aeteurope.nl ). The readers come from yet somewhere else, vertically integrated markets seems to be an idea whose time has not yet come here.

On the other hand, Advanced Card Systems (ACS) is a Hong Kong-based company which manufactures several types of smart cards and memory cards, and also the readers for them. It also produces the software required to use them, which is called eCerts. They have recently released a new line of smart card, the ACOS5, which supports 2 standard PKI architectures, CSP for Windows and PKCS#11 for Netscape and associated environments. (Previously they specialised in Netscape; the CSP for Windows is a new departure for them.)

ACOS5 cards and ACS readers are available from Smartcard Focus, and ACOS5 is fast becoming their best seller. The cards are competitively priced, and even more of a bargain is the so-called SDK. It isn’t so much an SDK, as I understand them, (though it does have a lot of background information on the cards,) but rather a starter bundle, containing one normal reader, one USB-token type reader, 5 normal cards, 5 SIM-type pop-out cards for USB tokens, and a mini-CD containing the reader drivers and eCerts – the CSP and PKCS software, a card admin utility and lots of documentation, for a very favourable all-in price.

In the testing I have been doing recently, described in my article ‘Certificate Server Enterprise Edition and Smart Cards’, I found a need for a second CSP, and decided to use the SafeSign Standard CSP, and following sections describe how to install this, and my experiences with the software. I also recently purchased the ACOS5 SDK for evaluation, and have performed similar tests on this. Note that all the following applies to an Enterprise Certification Authority, thus integrated into Active Directory.

Cryptographic Service Providers

A Cryptographic Service Provider (CSP) is a software component controlling encryption, hashing and all the other features required to be able to use digital certificates in the Windows environment. (There are other approaches, such as PKCS, used by Netscape and others.) A point to stress about CSPs is that they are part of Cryptographic Services, which is a component of every Windows system (for it to be able to use digital certificates, of course). They are not part of Certificate Services; we obviously need to be able to use certificates whether or not we are running our own Certification Authority.

What happens when a certificate is enrolled, whether or not it is on a smart card, is that cryptographic services on the client machine generates a key pair, using a particular CSP; in the case of a smart card it is usually necessary to specify the CSP explicitly (or configure the certificate template accordingly). Also, in the case of the smart card, part of the CSP is actually on the card itself – the key pair is generated within the card and the private key never emerges from the card. (All processing involving the private key takes place within the card itself – that’s what ‘smart’ means. As a corollary, private key archival is not possible – nor even relevant – with smart cards.) After generating the key pair, the public key, and associated information including, obviously, the identity of the CSP, is passed across to the Certificate Server which issues a certificate incorporating it. This is true whether we are using an internal Enterprise CA (as assumed here) or an external CA. In the case of an external CA all manner of bureaucracy has to be gone through to reach this result, whereas with an internal CA it is effectively instantaneous (but it is still a client-server process, with different parts executed in different locations).

A particular CSP is required to be present on a given machine, either to enrol certificates (strictly, to generate key-pairs) to that CSP, or to be able to use certificates (especially on smart card) generated using that CSP. It is not required to be present on the Certificate Server, not for the purpose of generating the certificate, that is. If you try to log on to a machine using a smart card generated using a CSP which is not present on that machine, you get an error: The card supplied requires drivers which are not present on this system. Please try another card. This applies both to a local interactive logon, and also via remote desktop – it would be rather surprising if the latter were not the case.

If you are using just the standard set of CSPs which comes with every Windows system, then none of this is readily apparent. It only becomes clear when you install a new CSP, and start wondering about the strange effects you encounter. (And, as usual, this stuff’s not documented anywhere that I’ve found.) These strange effects include viewing the properties of certificate templates: if the machine you are viewing from includes the new CSP, then this CSP is visible in the list of available CSPs; if it doesn’t, then it isn’t. Certificate templates are Active Directory objects; they have no explicit cognisance of CSPs, except in one case: if you were to configure a template to require the use of a specific CSP, (or a choice of more than one,) then the identity of the relevant CSP(s) is stored in AD along with the template. If you configured the template to require use of the new CSP, then viewing this template’s properties from a machine where the CSP is not present would, on opening the Request Handling tab, display the message The following CSPs are not installed on the local computer: <CSP name(s)>. Template settings cannot be verified. Having acknowledged this message, you can then view the list of CSPs, and the new CSP is indeed present, but at the end of the list, not in its normal, alphabetic position. So far as I have seen, this is the only circumstance in which a new CSP manifests itself on machines where it is not installed.

Initialisation of Smart Cards

Neither StarCos nor ACOS5 cards come pre-initialised, so the first thing you must do is to initialise them. The software in both cases includes an administration utility, one of whose functions is to initialise the card. (If you attempt, as I, obviously, did, to enrol a certificate on an uninitialised card, you get an ‘unexpected error’ with the value 0x80100065, which is not very informative. Apparently it means that the card is ‘not supported’ – ‘uninitialised’ would be rather better.) Initialising the card includes setting the PIN value, and this utility is the only way of setting/resetting it. There is also another code, which SafeSign calls the PUK (Personal Unblocking Key) and eCerts calls the Global PIN, which allows the PIN to be reset after the card has become blocked, by inputting the PIN incorrectly a certain consecutive number of times (3, I believe, for SafeSign, 8 for eCerts). The PIN is known to the user of the card, but only the card registrar should know the PUK. (eCerts refers to the normal PIN as the Local PIN 81, there is also a Local PIN 82, whose significance is unclear.)

Cryptoflex cards come pre-initialised, so this point had not arisen before. They have default values of 00000000 for the PIN, and 11111111 for the ‘unblock PIN’ (i.e. PUK). There is also a value called the Transport Key, which is used, in conjunction with a ‘personalisation’ tool, downloadable from the Axalto website, which enables the cards to be reformatted to their original state. Unlike with SafeSign and eCerts, you get the option to reset the PIN from this default value when a certificate is enrolled on a Cryptoflex card.

SafeSign Installation and Use

The SafeSign software comes in Administrator and User versions, and is downloadable form AET’s FTP site, available on request. The admin version, SafeSign-Identity-Client-2.3.0-admin-eval.exe , must be installed on the machine you have selected as the Registration Authority (RA) – i.e. the one where smart card enrollment is to be performed. The installation process is straightforward:

  • select the setup language - English(US) the default
  • accept the license
  • select the components to install (see below)
  • carry out the installation
  • restart the machine to complete.

The installation components are:

  • PKCS #11 (required)
  • Common SafeSign Dialogs (required)
  • CSP (required)
  • GINA
  • Documentation
  • Local Language Support
  • Token Administration
  • Certificate Expiration Check Utility
  • Task Manager.

You will definitely need the Token Administration Utility, but GINA (which is in any case deselected by default, and is required only if using either a protected authentication path device, such as a secure pinpad reader), Documentation (which is in fact only the license agreement, so not all that useful), and Local Language Support (which is required only if supporting multiple languages), can normally be omitted.

The token admin allows StarCos cards to be initialised, but you only get one shot at this: when a completely uninitialised card is loaded in the reader, the initialisation option is offered, and this, inter alia, allows the PUK to be set for the first time. You can subsequently use the utility to wipe, i.e. reinitilise a card, but you have to specify the PUK to do this, likewise for other admin facilities, to change or unblock the PIN, and to reset the PUK itself. (The user version of the SafeSign software appears identical to the admin version. I think that the only difference is that the admin utility – called Token Management - does not have the facility for the initial initialisation; it seems to have all the other facilities.)

I have enrolled a certificate (to the standard v1 Smartcard User template) on a StarCos card, by an agent with an enrolment agent certificate on a Cryptoflex card (this is my Smartcard Enrollment Agent template, generated from the standard v1 Smartcard Logon template, with the Enrollment Agent application policy extension added). This was the driving force of the present exercise.

The SafeSign CSP does what it should in that certificates can be enrolled on StarCos cards by an enrolment agent using the web interface to Certificate Services, in the usual way. The smart card thus configured seems to work entirely as expected.

However, I have noticed several strange effects, over and above those applying to all new CSPs, as recorded earlier, which were rather difficult to pin down with precision, and I now place these on record. I speculate on what is happening but cannot yet explain it.

I think that the SafeSign CSP may be relevant only to v1 templates (though I can’t say why). If the template properties are viewed from a machine on which the CSP is installed, the SafeSign CSP is visible in the list for all v1 templates, but not necessarily visible for the v2 templates (it is visible either for all of them or for none). It took a while, but I finally pinned it down thus: the CSP is visible, for v2 templates, only if there is a card physically present in the reader attached to that machine - any card at all, even an uninitialised one! I, too, found this hard to believe, but it’s reproducible: pull the card out and the CSP isn’t visible, put it back in and it reappears. To ensure that this is a mere-presence effect and not an effect of authentication, I perform the test in a session where I originally logged on by username/password (otherwise, removing the card would lock the machine, and require a reauthentication). Initially the CSP is not visible, insert any card and it is, remove the card and it isn’t. (Actually, in that last case, after removing the card you have to reload the MMC to demonstrate that the CSP has disappeared; it seems to cache its display in this case, although not in the other.)

Finally, I wanted to run my certificate enrollment test the other way round, with an enrolment agent certificate on a StarCos card, enrolling a certificate on a Cryptoflex card. But I couldn’t enroll the enrollment agent certificate (from a v2 template, of course) on StarCos. I tried it using the Certificates (local user) MMC and also the web enrollment tool. (I was logged on by smart card, so the SafeSign CSP was displayed as available.) In both cases the error was displayed: ‘The certificate request failed. The smart card has been removed, so that further communication is not possible.’ (It hadn’t, of course.) The web tool gave a bit of additional information – 0x80100069 – SCARD_W_REMOVED_CARD (though that doesn’t actually say any more).

Spooky, huh?

AET evidently think that the product performs to specification, and seem uninterested in these effects I’ve encountered.

eCerts Installation and Use

The mini-CD autoloads and offers 3 options:

  • Step 1: Getting Started
  • Step 2: Installing Smart Card Reader Driver
  • Step 3: Install SDK Components.

Steps 1 and 2 are perfectly straightforward; the only points of interest are in step 3.

Select the custom installation, and 5 components are offered:

  • CSP Components
  • PKCS Components
  • Smart Card Certificate Manager
  • Card Tool
  • Reference Manuals.

In a Windows environment, the PKCS components are not required, nor is the card tool (this doesn’t work in a CSP environment, according to the Getting Started section), but the other three should be selected for the RA station, where the cards are to be enrolled. Only the CSP components need to be installed on other machines.

The Smart Card Certificate Manager (eCerts Admin Tool) is used to initialise the cards. When you run the utility with an uninitialised card in the reader, the message is displayed: Card is not formatted to a PKCS #15 structure. Do you want to format it now? Warning: All files will be deleted. This is somewhat confusing as we aren’t using PKCS and don’t have it installed. However, the message simply reflects ACS’s background in the Netscape environment. In fact the cards are formatted the same way whichever technology is used. Having initialised the card, the global PIN (i.e. PUK) and the Local 81 PIN (which is actually the PIN) can be configured. Both of these are initially set to ‘12345678’ as a message points out, on completion of the initialisation. (There is also a Local 82 PIN – no idea what that is, but evidently it’s not used; it has an initial value of ‘88888888’.)

A point to note is that the eCerts Admin Tool works (currently) only with the ACS card reader, so you do need to have this installed. The cards, once they have a certificate, are readable, in principle, by any reader, of course. I use a mixture of ACS and OmniKey readers. Initially, the OnmiKey readers could not read ACOS5 cards, but OmniKey very quickly produced a fix when I reported this:

  • Create a new registry key HKLM\SYSTEM\CurrentControlSet\Control\CardMan.
  • Below this create a DWORD value named GuardTime, and set the value to 16 (0x10).

This does indeed enable Omnikey readers to read ACOS5 cards, but it doesn’t enable them to write to ACOS5 cards (this is, of course, of considerably less importance). OmniKey will shortly be releasing a new driver for the card readers which is supposed to fix these problems at source, but I wish to note the very prompt way in which they produced a fix for the main problem as soon as they knew about it.

eCerts manifests the usual new CSP effects, described earlier, but the ACS CSP does always appear in the list for v2 templates as well as v1.

ACOS5 cards now work very much to spec. (This was not initially the case. The first release of the software had serious problems. But over a period of some 4 months, ACS have successfully cleared the problems my testing has detected. I can now confidently recommend the product.) Specifically, I have enrolled certificates to the standard v1 Smartcard Login template on ACOS5 cards, by an agent with an enrollment agent certificate on a Cryptoflex card, similar to SafeSign. But I have also enrolled an enrolment agent certificate on an ACOS5 card, and used that to enrol Smartcard Logon certificates on Cryptoflex cards. This is as it should be.

Windows Vista

The findings in this article are valid at Windows Server 2003 and XP. The first draft of the article was written as far back as October 2006, and the delay in coming to publication has been due to validating the ACOS5 product.

But with the arrival of Windows Vista, the whole situation changes. Vista is the first OS to enforce the new Windows Smart Card Framework. There is an excellent exposition of this topic which can be downloaded from http://www.microsoft.com/downloads/details.aspx?FamilyID=fa7ec97c-11be-4e53-a0c4-04719b6a7ab6&DisplayLang=en

What this means in the present context is that in future CSPs will be layered, instead of monolithic. Microsoft provides the Base CSP, which implements the bulk of the cryptographic functionality, and the card manufacturers are required to supply only a card-module/mini-driver to interface with this, incorporating just the hardware-specific aspects. Previously, the entire CSP was produced by the card manufacturer, and the functionality and general quality of these varied enormously. In future, all CSPs will be equivalent, as far as the smart card administrator is concerned, thus, for example, a standard Windows utility will be used to initialise the cards, set the PIN, unblock blocked cards and so on. This brings to smart cards the sort of benefits that we have enjoyed for years with device drivers. It greatly reduces the work required from manufacturers to implement their products on Windows.

However. The smart card manufacturers all seem to be sitting on their hands, each unwilling to be the first to implement the new mini-drivers. The consequence is that there are no cards currently available which work with Vista. None of the old-style CSPs are accepted by Vista. The Base CSP has been available for some time, to allow the new mini-drivers to be implemented to work with W2K3 and XP, and thus be available well in advance of the Vista launch. But nobody has taken advantage of this.

When I say that there are no cards currently available, I mean that there are none that I can get my hands on. Such cards do exist – Microsoft has several thousand of them - but I can’t get hold of any, nor can my suppliers. The current situation is infuriating and frustrating. Until this is resolved, I am unable to validate the smart card facilities of Vista, as tantalisingly described in ch. 3 of the Windows Vista Security Guide, available from http://go.microsoft.com/?linkid=5639874.

I do know that some smart card manufacturers are finally coming to terms with Vista, but lead times of several months are anticipated, so don’t hold your breath.