Lazybit

The smart card service is a standard Windows component and it should be present on every system. However, in certain circumstances that is not the case - as a result, programs that depend on this service will fail.

I've previously discussed how to install the smart card service on Windows XP, and I've covered this procedure on Windows 2000. However, I had no solution for Windows Vista and Windows 7.

Fortunately, that is not the case anymore, a solution that works on 32-bit and 64-bit platforms was found, here is how it works.

Sometimes the smart card service is not in the list of services at all, but if you look for the files related to this service (ex: SCardSSP.dll) - they are present in the file system. So the problem is not in the fact that the modules are not there; they are - but they are not loaded.

Having had the opportunity to tinker with a problematic system, I was able to determine that the service is absent because some entries in the registry are different from their "normal system" counterparts.

In other words, the difference is only in the contents of HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\SCardSvr.

If the service is not listed, open regedit and view that key, it will most likely be absent. If it is present - it means that some of its sub-entries are incorrect.

1. Backup the key (right-click\Export) to a REG file
2. Delete the key
3. Download and import this REG file: http://dl.dropbox.com/u/3258602/scard-vistax86x64.reg
4. Reboot the system

If the planets are aligned properly - the service will be back, and it will be running after the restart. Give your software a try, everything should work. The registry file above works with Vista x86 and Vista x64.

For Windows 7, use this one: http://dl.dropbox.com/u/3258602/scardsvr-win7x64.reg (it should work on both types of platforms).

I hope you'll find this helpful and that you will save all the time I've lost. Feel free to share your experience or ask any questions.

If the sky falls down and Dropbox doesn't work, here is the contents of the files.

Full story »

If you have a SIM card reader for SIM recovery or contacts synchronization, you may notice some weird behaviour on Windows 7.

Every time you plug in the reader, Windows begins to look for a driver:

This is strange, because you have already installed the driver once; and what is stranger is that despite the fact that Windows fails to find a driver - the SIM card manager still works properly!

The explanation is very simple: Windows doesn't try to install the driver for the smart card reader, instead it attempts to install the driver for the smart card.

Take a look at your device manager, and pay attention to the names of the sections. Notice that the smart card readers are OK (highlighted with green), while the smart cards themselves are marked as "unknown" (highlighted with red). [please excuse the mess in my system, there are many items there because my computer is a testbed for all my experiments]

So, what is all this about? First of all, it is not a bug, it is a feature of Windows 7. It attempts to load a minidriver for the smart card that was plugged in (yes, a SIM card is a smart card, so Windows reacts to a newly inserted SIM card in exactly the same way).

This may be needed for some smart card applications, but it is not needed for SIM card management software (our smart card security tools don't need it either). You have two options here:

• Ignore it and let it be. This is somewhat annoying.
• Disable the feature, save some time and get rid of the annoyance.

How to disable smart card plug and play on Windows 7

1. Start the group policy editor, by typing gpedit.msc in the Start menu
   
2. Go to Computer Configuration\Administrative Templates\Windows Components\Smart Card
3. Find "Turn on Smart Card Plug and Play service" and double-click it
   
4. Disable it, click OK to apply the new setting
   

After you reboot the system, the pop-ups that show up every time you plug in a smart card will be gone.

Another way to disable smart card plug and play on Windows 7 is to run this from the command line, with admin rights:

Reg add HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\ScPnP\ /v EnableScPnP /t REG_DWORD /d 0

Should I disable smart card plug and play?

• If you don't disable it, the worst thing that can happen is that there is a delay before the inserted SIM card becomes readable. This happens because Windows locks access to the card, preventing the applications from reading it. After Windows fails to find a driver, the card becomes usable.
  This breaks some smart card programs, making them "believe" there is no card at all. SIM Manager was updated to take this feature of Windows 7 into account - so you can read your SIM card, its phonebook and SMS, etc
• If you disable it, the delay is removed, thus the card can be read instantly. Note that if you use Windows built-in smart card authentication mechanism, it may not work. If "smart card authentication" rings no bells to you, it is safe to disable smart card plug and play.
  Note that this feature does not affect Dekart Logon - our own program for smart card authentication in Windows.

p.s. those of you who already have SIM Manager, stay tuned for the upcoming release, it's new feature is deleted SMS recovery for the iPhone.

Dekart SIM card reader is a PC/SC compliant smart card reader that can be used to read SIM cards or any other type of ISO-7816 smart cards.

A Linux driver is now available, you can get it in DEB and RPM flavours (all of them are inside the archive): http://files.dekart.com/drivers/Dekart-DK38T-Linux-deb-rpm-tgz.zip

If you're looking for a way to re-install the smart card service on Windows XP, this story is your new best friend!

Summary

1. Prepare a Windows XP installation disc
2. Download WinXP-scardsvr-install.zip
3. Read the included readme.txt
4. Examine install.bat in order to see what it does
5. Run the BAT file

Steps 3 and 4 are optional, but if you're someone who tinkers with the service, I'm sure you want to know what's in there.

Explanations

• First of all you should make sure the service is completely removed. sc delete scardsvr is the standard and official way to remove the service (it is interesting that Microsoft provides a way to remove a service, but there is no known mechanism to re-install one).
• Copy scardsvr.inf to %windir%\inf
• Run sysocmgr.exe /i:caller.inf, this will invoke a wizard that will use the data inside scardsvr.inf to perform various actions (such as modifying registry keys, and copying files)

• Uncheck Smart card service and press Next to remove the files and registry entries
• Run the command again, the same window will be shown, check Smart card service and press Next (you will be asked to insert the Windows XP installation CD)
• Perform a system restart, after checking the service manager (by running services.msc) and making sure the Smart card service startup is set to Automatic

If you examine scardsvr.inf you will see that it contains references to a list of files and registry keys. These actions could be performed manually, the effect would be the same; but using an .inf file is much easier.

Last week we've released an update of the SmartKey library, one of the additions is compatibility with ACOS5 cards provided by ACS. Now these cards can be used with any of our data encryption or user authentication software, provided the cards were formatted with this version of the Key Formatting Tool. The tool is not yet officially released, because other features are being added; however, ACOS5 support is now thoroughly tested.

• The capacity of the card after formatting is about ~30 K;
• Dekart formatting can be done before and after formatting with another vendor's tool, therefore the card can be used for other, non-Dekart programs too;
• No transport key is required when the card is formatted.

To find out what SmartKey is, take a look at the timeline of Dekart software; you might also be interested in checking out the list of other supported hardware.

Here is a set of points that emphasize the benefits of a smart-cart or token-based authentication solution, coupled with biometric authentication; the example is focused on Dekart Logon for Citrix, but it also applies to other user authentication software by Dekart.

Q: what are the benefits of using your product? Am I simply substituting a PIN for a user/password combination? And can an external user without a flash drive or smart card still access the server?
A: Dekart Logon for Citrix is not a server-side application, it should be used on the clients.

The benefits can be summarized as:

• users don't have to enter passwords manually
• therefore you can use extremely complex passwords (they won't have to memorize them anyway)
• since they don't have to memorize them, you can be sure your passwords won't show up in clear-text on sticky notes, or written somewhere under the keyboard, etc
• the fact that the credentials are stored on a smart card means that brute-force attacks are out of the question
• optional biometric authentication takes that one step further

• the software can also be used with flash disks, being entirely self-contained:

  • the Citrix client itself can be migrated to the USB disk
  • and the same applies to our program
  • as a result, an end-user can plug the USB drive into any computer (even where the Citrix ICA Client is absent), and log on to the Citrix server. (Of course, this is also possible if you use a web-based client, but in that case you have to beware of keyloggers [note: we have a solution for that too])

In this case the user is immune to keyloggers. Even if the keylogger manages to capture the PIN:

• they won't obtain the connection credentials themselves, therefore they won't be able to connect to the server without actually having the smart card (token, or USB drive)
• and even if they do - you can use biometry as an added layer of security
• further, the program can be installed in 'simple' and 'advanced' modes. In the first case, end-users can only connect to predefined servers, they cannot change the credentials, nor see the connection details - this makes the system fool-proof.

And as a side effect, this also means that unloyal end-users won't be able to disclose confidential data even if they want to. In other words, you can implement the "need to know" approach, by not giving users more information than they actually need to get their work done.

The data stored on USB drives are encrypted with AES-256 bit, our implementation of the algorithm is certified by NIST. This is much stronger encryption than the one used by the Citrix client itself.

Q: And can an external user without a flash drive or smart card still access the server?
A: Technically, this is possible, but you can counter that by:

• using extremely complex passwords, or randomly generated ones
• not disclosing them (just write the credentials to a key and issue it to an end-user)

You will probably want to take a look at Key Manager, this is the tool that allows you to write credentials to keys, make copies, edit contents of a key, etc.

Note - you can do these with Dekart Logon for Citrix itself, but if you're planning to operate with many keys (in a corporate environment), you'll find Key Manager very useful. A license for the tool is given for free if a certain number of licenses for Logon for Citrix is purchased.

Q: Couldn't someone with a citrix client installed on their machine get to my server logon screen on the remote machine and execute a brute force attack there?
A: Although that is technically possible, it is not an optimal scenario for the attacker to use:

• most network admins configure the servers in a way that prevents any host from connecting again if they've connected N times during the last M minutes (to prevent brute force attacks, conserve CPU cycles and network bandwidth, thus avoid denial-of-service attacks)
• from the attacker's point of view, the bottleneck of the procedure is the network bandwidth. When brute forcing a local resource, it goes much quicker because reading/writing RAM is much faster than crafting a packet, sending it over the network, then waiting for a response from the server, etc.

In other words, a local brute-force attack can take thousands or millions of years, while doing it over the network is totally insane. It may only work for trivial passwords such as '11111' or ones that can be found in any dictionay. But even in that case, a dictionary attack won't be feasible if the network admin took the right measures and prevents one from physically connecting to the server if they've had too many unsuccessful attempts.

Finally, the last detail is that you can use randomly generated passwords, which are extremely long - brute forcing THAT is impractical.

If I were an attacker, I'd try to find alternative ways, such as social engineering applied against a naive employee.

Some might be interested in the history of data encryption programs developed by Dekart. The chronology is a bit different from what one expects, so here are some facts about what happened, as well as some ideas about what might happen in the future.

The first program in the line is Private Disk Multifactor, which was released somewhere in 1999; at that time it was called "Private Disk". This is a smart-card/token -oriented encryption tool that appeared as a "side effect" of Dekart's initial exposure to smart-card payment systems. It makes possible the use of three factors of authentication, adding a BioAPI or HA-API compliant scanner to the authentication procedure.

Some of Multifactor's core components are:

• The Smartkey library - it acts as an abstraction layer, providing a unified interface to a broad range of key storage devices such as smart cards, tokens. The list was further extended, encompassing floppy disks and CDs. Support for flash memory storage is now there as well (ex: SD or MMC cards, or digital mp3 players that are detected as mass storage class devices)
• Dekart BIOAPI - this library allows BioAPI and HA-API biometric scanners to be used in the same way, hiding the low-level details from the coder.

Other important components, such as the on-the-fly encryption, and the virtual drive mechanisms were tightly coupled to the program's source code. Later they were moved to a different module, to make maintainence easier. This is how Private Disk API was created.

Private Disk Light was released in 2001, being a "Hello world" application that demonstrates how the Private Disk API works. Eventually the program became more than just a simple demo.

In 2003 it was decided that Private Disk Light would evolve as Private Disk, a commercial product; the Light version continues to be a free encryption program. This is when the original "Private Disk" became "Private Disk Multifactor". It was expected that such a change would cause a confusion among end-users, but the transition went surprisingly smooth.

Throughout this time, Private Disk API was only used internally by Dekart developers. It was decided that the API would become a product on its own, which would encourage others to build their own encryption software with minimal time investments. The API was documented, and along with several sample projects, it is distributed as Private Disk SDK, the first date of release is August the 5th, 2005. The SDK is a very easy way to build a robust encryption solution, not only that it was tested by time (since Private Disk relies on the exact same API), but it also relies on NIST-certified cryptographic modules for encryption and hashing. Certification is handled by Dekart, so the coder who uses the SDK can have this at no additional cost. Other things that are there - support for 64-bit platforms (AMD64 and IA-64), as well as Windows Vista compatibility.

2006 is an important point on the timeline, Dekart has released Private Disk Multifactor 2.0, it was shown to the public during the Systems 2006 expo in Munich. This is a special release, the most important detail about it is that it relies on Private Disk API, rather than its old codebase.

(A silent photo of the Dekart-Ritlabs stand in Munich, click to enlarge)

At that point Multifactor became a super-set of Private Disk, if compared by the available features. This brought tools such as Disk Firewall, Autorun, Autofinish to the community of Private Disk Multifactor users. All of this happened without hindering the mobility of the program - Multifactor is fully self-contained, thus it can be used directly from a removable drive on another computer. Of course it is a bit different, because if multiple factors of authentication are used, drivers for the additional hardware are needed. However, if a USB drive (or a smart card reader for which Windows will automatically find a driver) is used as a key - two-factors of authentication can be applied.

The 2.0 release had a significant impact on the speed of development, because any change made in the underlying API would automatically become a part of Private Disk and Private Disk Multifactor.

It is now being discussed whether PD and PDMF should be merged into a single product, but a decision was not made yet.

Since several APIs were mentioned, it should be noted that Smartkey is also going to be available as a separate SDK. This makes the development of smart-card based solutions incredibly simple. Ease of use is not the only advantage; besides the fact that the API was thoroughly tested and used for many years, it provides compatibility with a lot of smart cards, tokens, and other types of storage devices.

Another important detail is that Smartkey interacts with the smart cards and tokens via APDU commands. As a result, the library is very light, and there is no need to install additional modules that came from the card or token manufacturer. A positive side-effect is that Smartkey can be used to build portable programs (i.e. programs that do not require a local installation).

Dekart also plans to release an API for SIM card management, as well as the biometric API which is used internally; it is not certain when they will become available to the public, but it is going to happen after Smartkey SDK is officially released. At that time it will probably be known as "Dekart Smart Card SDK".