Windows 7 complains on missing driver for smartcards – a practical workaround

Smartcards and smartcard-aware applications using application level commands (APDUs) are older than Windows and worked very well in the past, until Microsoft suddently decided that a smartcard shouldn’t be handheld directly by the applications anymore, and introduced the concept of smartcard driver software (ICC Service Provider withing the PC/SC framework). This issue sometimes occurs with our products in the SpringCard CSB6 Family (CSB6Prox’N’Roll PC/SCEasyFinger and CrazyWriter) and our NFC readers/encoders (H512NFC’Roll).

With Windows Seven, Microsoft goes one step further and mandates that every smartcard has its own driver (a ‘minidriver’ actually, i.e. a DLL running in user mode and not a SYS binary running in kernel mode). Everytime you put a smartcard on a contactless reader, or in a contact reader, the system tries to locate the appropriate driver, and this generally ends up with a red mark in the tray bar and this annoying message in the tray bar : “Device driver software was not successfully installed. Click here for details.” Luckily, smartcard-aware applications keep on working as usual on top of PC/SC API, thanks to classical SCardConnect / SCardTransmit function calls.

According to Microsoft, smartcard-issuers should provide a minidriver for their cards. The point is, the ICC Service Provider architecture is meaningfull to let security-sensitive applications access security features (digital signature, secure login) in an interoperable and high-level way, but it appears useless in other cases, when only one single software has to communicate with a single smartcard. And this is the case in 99% of the systems using contactless smartcards or contactless memory cards.

A techninal article has been published in Microsoft Knowledge base ( giving different solutions to prevent the system from looking for a driver and issuing the warning message. In this article we are detailing two solution :

  • 1st solution is to disable SmartCard PnP feature through a Group Policy. The side effect is that there’s not choice but to disable this feature for every cards, not only for the one that do not have a minidriver,
  • 2nd solution is to write in the system registry the list of cards that will not have a minidriver. In this article we do this through a small utility that makes it easier than entering the required lines in the registry one after the other.

Using a Group Policy to disable the smartcard PnP feature

Just follow this five steps :

  1. Run MMC.exe (Microsoft Management Console)
  2. Add Group Policy snap-in to the console
  3. Open Local Computer
  4. Browse to Policy\Computer Configuration\Windows Settings\Administrative Templates\Windows Components\Smart Card
  5. Disable Turn On Smart Card Plug And Play Services.

Command-line utility to selectively disable some smartcard minidrivers

The principle is to register in the system registry the ATRs of every smartcard we don’t want to go through the PnP feature, and to associate them to a dummy minidriver.

Here’s the technical part (details are to be found in MS’ reference article (,

  1. Create a branch under HKLM\Software\Microsoft\Cryptography\Calais\Smartcards, name the branch with any clever name that will describe the related smartcard
  2. In this branch create a REG_BINARY entry named ATR in which you put the smartcard’s ATR
  3. Create a REG_SZ entry named Crypto Provider and put the value $DisableSCPnP$ in it.

You may also add a REG_BINARY entry named ATRMask to associate this entry with more than one ATR. In the ATRMask, bits set to 1 means that the bits in ATR are relevant, and bits set to 0 act as wildcards.


A sample source code to do so is provided by MS’ with the article. We’ve  implemented this source code in a small command line tool, and added a lot of modifications to ease its use and to make it possible to disable smartcard PnP for any arbitrary-entered smartcard ATR, and not only for the smartcards physically inserted in the readers at the time of execution.

There are two binaries : pcsc_no_minidriver32.exe for 32-bit systems, and pcsc_no_minidriver64.exe for 64-bit systems. Invoke either software with the -h parameter to get help. With the -m parameter, the software starts monitoring all the PC/SC readers. For every card inserted, it disables the plug and play. Alternatively, the -a parameter let you specify the ATR (hexadecimal string) ; you may optionally use the -n parameter to specify a name for your smartcard (this is convenient if you want to remove it from the registry later on !).

Note, you must run this program as an administrator.

We supplied the software with 2 command line scripts (.CMD),

  • pcsc_no_minidriver_memory.cmd disables every memory card (ATR constructed according to PC/SC v.2 specification for memory cards)
  • pcsc_no_minidriver_well_known.cmd disables  some well-known contactless cards that do not have a minidriver (NXP Desfire, NXP Mifare Plus, various Calypso cards, …).

Of course, use this software and the related scripts with care and make sure you really do understand what it does, as it may prevent your system to work correctly with your 20$-cryptographic card that do need its minidriver to work with CryptoAPI.

Here’s the link to the package : . It comes with complete source code. Just unzip in a local folder and enjoy.

Mifare Plus in a nutshell

Following the breakdown of Mifare Classic security, NXP has released a new generation of contactless cards to fill the gap, the Mifare Plus. To ease the migration of the existing applications, this new chip keeps the memory model of the Mifare Classic : the card is structured as an array of 16-byte blocks, and the blocks are grouped into sectors of 4 or 16 blocks. The security (authentication and access control) is done on a per-sector basis. The two benefits of Mifare Plus are its new security scheme (EAL 4+ certified), based on state-of-art AES cipher with 128-bit keys, and its optional Random-ID for ISO 14443-3 anti-collision, useful to address card-holder-privacy concerns.

Type X or type S

Mifare Plus comes in two types.

Mifare Plus X is the full-featured product, allowing end-to-end AES-ciphered communication and a so-called ‘Proximity Check’ feature that makes it possible to prevent relay attacks, by measuring precisely the time elapsed between reader’s commands and card’s answers.

The command set of Mifare Plus X includes a function to select one-out-of-many Mifare Plus ‘Virtual Cards’ that could be emulated by a single NFC device.

Mifare Plus S is a lightweight version of the product, optimized to be a cost-effective drop-in replacement for Mifare Classic. It doesn’t support the ‘Proximity Check’ and has only limited support for the ‘Virtual Card’ scheme. More than that, it doesn’t support the Security Level 2 (see below).

Security Levels

The Mifare Plus has four different modes of operation, known as ‘Security Level’ 0, 1, 2 and 3. The Security Level is a static parameter of the card, the reader application can’t decide to operate the card arbitrary at one security level or at the other, it must operate the card given the card’ Security Level . Using a specific AES-secured exchange, the application may switch the card from one Security Level to a higher one, but this operation is not reversible (it is impossible to go from one Security Level to a lower one).

Security Level 0 is the out-of-factory configuration. In this mode, the card is not secured at all, and even not usable to store data.  Before all, the AES keys to be used all among the card’s life-cycle must be loaded, and the card must be switched to a higher Security Level. Pay attention that all the AES keys are transmitted in plaintext, so it is very important to do this personalization step in a trusted environment.

In Security Level 1, the Mifare Plus emulates a plain-old Mifare Classic. This gives the opportunity to replace existing Mifare Classic cards without the need to replace the readers or the handler applications. But as the card keeps on using the broken CRYPTO1 cipher, the security of the system is not better…  Yet an optional AES-based 3-pass authentication makes it possible to check whether the card is a real card and not an emulator, but per-se it doesn’t protect the data from unauthorized reading or modification.

In Security Level 2, the Mifare Plus uses the CRYPTO1 stream cipher just as Mifare Classic, but instead of using static 6-byte Mifare keys, the keys are generated dynamically by an AES-based 3-pass authentication. This is said to combine the security of AES with ‘the speed of CRYPTO1’. Anyway, in a typical architecture, the CRYPTO1 is implemented in the reader (by the NXP RC chipset actually) where AES is implemented in software on a very fast host computer. The gain in speed of ciphering remains small towards the overall bandwidth of the card-to-application channel; it may even be not significant enough to balance the added exchanges (loading of the CRYTO1 key into the reader after every AES authentication).  Also, the Mifare Plus S doesn’t support the Security Level 2.

In Security Level 3, the Mifare Plus doesn’t use CRYPTO1 anymore, but only AES. The new features (optional Random-ID, Virtual Card, Proximity Check) are available only at this Level.

Note that in Level 0 as in Level 3, communication is standard-compliant (ISO 14443-4 “T=CL”) where Security Levels  1 and 2 uses legacy Mifare frames (ISO 14443-3 type A).

Compliance between SpringCard contactless readers and Mifare Plus

Whatever the Security Level, all SpringCard contactless readers are fully able to communicate with the Mifare Plus chips (anti-collision loop and retrieval of UID, ISO 14443-3 A or ISO 14443-B communication protocols).

In Security Level 1 and 2, as the Mifare Plus’ UID is 7-byte long where the UID of a Mifare Classic is only 4-byte long, an upgrade had to be written in the CRYPTO1 authentication algorithm. This is available in firmware version 1.51 and newer. Earlier versions must be upgraded to be able to read and write data on a Mifare Plus at Level 1 or Level 2.

Using the card in Security Level 1 means only calling some functions embedded in the reader (Mifare Classic function set), but the other Security Levels  involve a new function set (AES authentication, ciphering and MACing, read and write commands on top of T=CL) that has to be implemented in the host computer. This requires a major redesign of the host applications. If the host is a microcontroller with limited resources, adding support for Mifare Plus could be difficult or even impossible without changing the hardware.

SpringCard APIs for Mifare Plus

As is has already been done for Desfire and Mifare UltraLight C, SpringCard has developed a convenient software library to ease the development of applications using Mifare Plus cards. This library is available as both as source code and as binary in the latest SDKs (PC/SC and SpringProx Legacy), together with a small sample software that shows how to personalize the card in Level 0, to change the Security Level (0 to 1, 1 to 2 or 3, 2 to 3) and to operate the card in Security Level 3, including

  • AES authentication (and generation of the session keys for ciphering and MACing)
  • Read and write functions with various options
  • Virtual Card feature

When the card is at Security Level 1, the existing samples for Mifare Classic could be used unchanged. The Security Level 2 is not implemented, as it isn’t available in Mifare Plus S that is expected to be the most frequently chosen one.

Documentation of the API is available online :

Choosing between Mifare Plus, Desfire EV1 or Mifare UltraLight C

The NXP Mifare family has now 3 contactless smartcards using ‘modern’ cryptography schemes for improved security.

Desfire EV1 is a full-featured microcontroller-based card, featuring 3DES and AES cryptography, a structured memory model (files within directories), and partially compliant with smartcard-standards (ISO 7816-4). Available capacities are 2KB, 4KB or 8KB.

Mifare UltraLight C is a low-cost wired-logic card with only 140 bytes of memory (the typical target is the market of disposable contactless tickets). A single 3DES key makes it possible to ensure that the card is genuine.

Just in-between, the Mifare Plus has a flat memory model (blocks) but with a good isolation between sectors,  2KB or 4KB of storage, and AES cryptography. The key advantage is the memory mapping that is the same as Mifare Classic, so existing applications that store data in the cards may be upgraded without major changes in their logic (yet changes in the security scheme and in the command set are not trivial…). But on the other hand, if the only need is to have a serial number or to store a small amount of data, Mifare UltraLight C does the job perfectly and is cheaper. As for Desfire EV1, its compliance to 7816-4 standard is the key in interoperable schemes (including future uses of NFC phones to emulate contactless cards), where the two other products remain totally proprietary.

Upgrade in our PC/SC SDK (release 1.20)

The release 1.20 of SpringCard PC/SC SDK is now available in the Download section of the website (direct link to latest version : This SDK is meant to be used with our products in the SpringCard CSB6 Family (CSB6Prox’N’Roll PC/SCEasyFinger and CrazyWriter).

People working in the ’emerging’ NFC field will be glad to discover the updated versions of NFCTool, a .NET based application (written in C#) that makes it easy to create or to read NFC Tags compliant with the SmartPoster specification (as published by NFC Forum). Command-line nfc_create utility is also very useful to encode batches of NFC Tags.

The Desfire support library (pcsc_desfire.dll on Windows) has been upgraded; it now fully supports all the new features of NXP Desfire EV1 smartcards: AES and Triple-DES with 3 keys (3KDES), ISO 7816-4 compliant directories and files, card-level configuration. NXP Mifare UltraLight C chips are supported easily thanks to a new library (pcsc_mifulc.dll). Also, we’ve added in the SDK the Calypso support library (pcsc_calypso.dll) and its related sample software. All those libraries come with C source code.

New command line utilities have also been written for the ones who want to master PC/SC from its very basis, or have portability in mind. Most our C examples now run on Linux without any modification.

Java + PC/SC = accessing smartcards from a web page

The Java Smartcard I/O API (javax.smartcardio, JSR 268) introduced in Java 1.6 is the bridge between PC/SC readers and the Java world. Java-based applications and applets may now communicate with smartcards in an interoperable and portable way. This makes it possible for web pages to access data stored in smartcards, or to invoke services running in a smartcard (either running a JavaCard cardlet or whatever native card application).

An interesting extension of this technique would be the ability for  JavaScript to access the smartcards as well. JavaScript is not Java: Java code is compiled into bytecode, then translated into native code and executed by the computer’s Java Virtual Machine (JVM). JavaScript is interpreted ‘on-the-fly’ by the browser’s JavaScript engine. This would open new opportunities for developers to build quickly and easily smartcard-aware web-based applications purely in HTML+JavaScript.

It is not difficult to implement such a bridge between HTML+JavaScript and smartcards, creating a GUI-less Java applet that will translate JavaScript function calls into calls to javax.smartcardio methods. There are two technical aspects that must be mastered to do so:

  • The applet has to be signed, as the smartcard is a critical computer’s resource, not immediately available to the applets running in the sandbox,
  • The applet has to be scriptable, in order to expose itself to JavaScript through functions and events. But scriptable and signed applets normally mandate signed JavaScript, something we want to avoid to remain ‘easy’.

We’ve written a small yet precise HOWTO that explains the whole process of developing such an applet. You may download it here.

Following this HOWTO, a sample applet has been developed and signed for demos and tests. You can test it online here (the applet is signed with our certificate ‘’. You must accept the signature, otherwhise you will be able to list the readers but not to connect to the cards).

You can develop this type of solution with our products in the SpringCard CSB6 Family (CSB6Prox’N’Roll PC/SCEasyFinger and CrazyWriter) and our NFC readers/encoders (H512NFC’Roll).

Mifare is out of 32-bit IDs

NXP Semiconductors has recently warned their customers that they are running out of unique IDs for the Mifare Classic family. A detailed application note is also available to give precize answers to technical questions.

Since the beginning, every card in the Mifare Classic family (1k, 4k, Mini) has a 32-bit identifier, said to be unique (4-byte UID according to ISO 14443-3 A standard). The reader uses this identifier to “see” and to select the card (anticollision + activation loop). Afterwards, the reader’s Crypto1 engine also has to know this identifier in order to perform the mutual authentication, to gain read or write access on card’s data.

Theoretically, 32 bits would mean that 4.2 billion cards coul’d be issued with different IDs (4 294 967 296 exactly). But as some values have been reserved or assigned by ISO to different uses, only 3.7 billion unique IDs were practically available. Therefore, NXP expects to run out of unique identifiers for Mifare Classic by the end of 2010.

Fortunately, ISO 14443 standard allows longer IDs: either 7-byte IDs (“cascade level 2”, widely used for years, by Mifare UltraLight and Desfire for instance) or 10-byte IDs (“cascade level 3”, but with no practical example at the date of writing). To overcome the 32-bit limit, NXP will introduce a new generation of Mifare Classic cards using 7-byte IDs. As a consequence, applications working with card IDs may have to be updated to accept longer numbers.

All SpringCard readers, whatever the version, support the whole ISO 14443 standard, including 7- or 10-byte IDs. But the Crypto1 authentication scheme has to be slightly updated to support the longer ID. In our contactless products (SpringProx, CSB, Prox’N’Roll, etc), this is implemented since version 1.51. Therefore, customers that need to read/write new Mifare Classic cards having 7-byte IDs (as well as Mifare Plus) shall make sure that their products run firmware 1.51 or newer.

SpringCard and Effitic ready for ‘at-home’ card-based services

Effitic, a french software engineering company, has set up a working demo that demonstrates how public transportation cards could be reloaded at home thanks to SpringCard’s contactless readers.


In this architecture, all the business logic and the security components (SAM or HSM) are centralised in Effitic’s back-office server. A lightweight Java applet runs in a standard web browser to communicate with the smartcard reader through the PC/SC middleware. The applet installs itself automatically upon first access to the service whatever the system/browser.

The demonstration is typically performed with Calypso cards and a SpringCard Prox’N’Roll PC/SC contactless reader. As Prox’N’Roll PC/SC complies to the CCID standard, a driver is available -and installed automatically in most cases- on current desktop operating systems.

This setup is a cost-effective solution for at-home reloading of public transportation cards. This removes the need for a dual-interface card as the Prox’N’Roll operates contactless (13.56MHz RFID interface, compliant with ISO/IEC 14443 A and B, ISO/IEC 15693, Calypso/Innovatron, and with current disposable contactless tickets).

It also opens new opportunities and a new approach of user’s experience with his/her contactless card or NFC mobile phone. In fact, this web-based contactless smartcard architecture is not limited to transport ticketing but could be the basis of a new generation of innovative projects in various fields such as e-ID/e-gov, loyalty, entertainment and online gaming, events and sport ticketing, etc.

Java PC/SC applet

Effitic back-office server communicates with the Prox'N'Roll PC/SC smart card reader thanks to a Java applet

Billing snapshot

Customer uses his/her credit card to buy a new ticket to be loaded into the Calypso card

Card reloaded snapshot

The new transport ticket is loaded in the contactless Calypso card. A receipt is sent by e-mail.

Cardpeek – open source tool to read the content of smartcards

We’ve discovered a new open source project (lead by “L1L1”) that sounds promising.

Cardpeek is a Linux tool to read the contents of ISO7816 smartcards. It uses a PC/SC reader to communicate with the card, and its GTK GUI represents card data is a tree view. Cardpeek list of supported cards is expandable thanks to a scripting language. Currently, the tool can explore EMV cards, Calypso cards (including the Navigo pass from Paris area, with translation of the station names -this part developed by pterjan), Moneo cards (french ePurse) and Vitale (french health card).

Here’s a few snapshot I’ve taken with a Prox’N’Roll PC/SC and my own Navigo card (Paris’ Calypso card)

Cardpeek + Prox'N'Roll PC/SC

Selecting Prox'N'Roll PC/SC reader

Content of a Calypso card: ATR and list of contracts

Card content explained: ATR and list of contracts

Content of a Calypso card: transport log

Card content explained: transport log, with station code translated to actual names

Project homepage :

A few more explanations on freshmeat :

Create and read NFC tags with SpringCard NFC Tool and NFC Decoder

NFC Tags in a nutshell

An NFC Tag is a regular ISO 14443 card (either a memory card or a microprocessor-based smartcard), holding a specific content. Depending on this content, the “reader” will perform automatically a predefined action. Typical actions are :

  • open a URL (Internet address),
  • dial a number or send an SMS (if the reader is a mobile phone),
  • launch a software,
  • etc…

NFC tags are for instance embedded in Smart Posters, a new media for advertisement. Users seing the poster and touching its NFC tag with their NFC-enabled mobile phone or smartphone they may receive easily coupons or detailed information, or be prompted to buy online the advertised goods.

NFC logo : identifies NFC Compliant devices

The NFC Tag logo has been designed by the NFC Forum to identify NFC Tags.

NFC Forum, the organisation in charge of NFC standardization, has registered 4 types of NFC Tags :

  • NFC Type 1 tags :  Innovision Research & Technology TOPAZ chips (proprietary communication protocol on top of ISO 14443-A modulation)
  • NFC Type 2 tags : NXP MIFARE Ultralight and Ultralight C chips (proprietary communication protocol on top of ISO 14443-A modulation)
  • NFC Type 3 tags : Sony FELICA chips (proprietary modulation and communication)
  • NFC Type 4 tags :  standard ISO 7816-4 smartcards using ISO 14443 A or B up to layer 4

NXP and Nokia also support using NXP MIFARE Classic (1k/4k) tags. Visit NXP’s website for more information on how to make NFC tags using their chips (including MIFARE DESfire as Type 4 tags).

The format on the content stored in the tags is specified by NFC Forum in NDEF standard (NFC Data Exchange Format).

Getting started with NFC Tags thanks to SpringCard readers and software

SpringCard has developed a set of software -with sources included in the new release of the SDKs- to demonstrate how NFC tags are encoded and processed by SpringCard contactless readers.

Customize your tags using NFC Tool

NFC Tool is a desktop application (Windows) to encode and read common NFC tags. NFC Tool works with PC/SC readers (Prox’N’Roll, CrazyWriter or CSB6 namely).

NFC Tool allows you to read/write NFC content on your cards

An example of use of NFC Tool with a Mifare UltraLight Card

Easily read and write NFC content in your cards using NFC Tool : Choose between SmartPoster, Text or URI ; fill in your URL or Text ; encode it to generate the NDEF and write it to your card.

At the date of writing, NFC Tool supports the following tags :

  • MIFARE Classic cards (standard 1K/4K)  as NFC Type 2 tags ;
  • MIFARE UltraLight (MF0ICU1) and UltraLight C (MF0ICU2) cards as NFC Type 2 tags ;
  • TOPAZ by Innovision cards as NFC Type 1 tags.

NFC Tool can be found in our PC/SC SDK (C# application for .NET framework).

Read NFC tags on your Pocket PC using NFC Decoder

NFC Decoder is a lighweight application for Windows Mobile (Pocket PC) that allows you to open an URL from an NFC tag card. NFC Decoder works with either SpringProx-CF, SpringProx-CF UP or SpringWAP through SpringProx API. It supports MIFARE 1K, MIFARE 4K and MIFARE UltraLight or UltraLight C as NFC Type 2 tags.

NFC Decoder

An URL found on tag with NFC Decoder

(C# application for .NET compact framework).

Mifare UltraLight C : low-cost yet high security

NXP (formerly Philips SemiConductors) Mifare UltraLight chip (MF0ICU1) is a inexpensive contactless memory, widely used to make disposable transport tickets or other low-cost identification tags. As MF0ICU1 lacks of authentication or even password protection schemes, the reading application has to way to determine whether the serial number and the data come from a genuine card, or from a a spy/replay device emulating it  (read this article for a few details).

The new Mifare UltraLight C chip (MF0ICU2), while remaining compatible with MF0ICU1, now provides a strong mutual-authentication algorithm, based on the standard 3DES (Triple-DES) algorithm. This allows to make sure the card in front of a reader is genuine (the application and the card share the same secret key).

A Mifare Ultralight C embedded in a wristband, used for ticketing and pre-payment during the Gala ECE event.

Gala ECE is a successful example of the Mifare UltraLight C‘s use for ticketing and payment. To prevent the risk of theft in this sort of giant night-club, the bars were not allowed to accept bills or coins ; wristbands had to be credited at a few kiosks, and then used as electronic purses. When it comes to money, security is a major concern. The organisators wanted a secure purse solution yet remaining compliant with low-cost tags, and SpringCard successfully help them to specify and develop the it on top of Mifare UltraLight C.

Here’s a few hints :

  • Thanks to a 3DES-based key diversification algorithm, each card has its own secret key (the secret key of the card is computed from a ‘root’ key and the ID of the card). Doing so, if one key gets corrupted, the whole system remains safe. Only the ‘root’ key is critical,
  • Confidence is based on the dynamic mutual-authentication (based on 3DES). This removes the need to digitally sign (or MAC) the data stored in the card, so the whole memory remains usable to store informations (including a small transaction log),
  • Selective locking and protection of different blocks in card’s memory allow a fast reading yet ensure that no writing could be made without prior authentication,
  • As the card doesn’t feature a true anti-tearing system, we choose to read-back the data after writing, but thanks to the fast USB link between the computer and the Prox’N’Roll, the added time is not noticeable for the consumer.

This experience has shown how easy it is to implement quickly a large scale ticketing and pre-payment system, in the same price range as ‘conventional’ memory cards (Mifare, Mifare UltraLight, or their equivalent in ISO 14443-B), but with a very good security level -that was before achievable only using more expensive smart cards.

Contactless ticketing and pre-payment using Mifare UltraLight C and Prox’N’Roll

Last saturday, SpringCard Prox’N’Roll PC/SC was the core component of the access control and payment system during the annual gala of french high-school École Centrale d’Électronique (ECE) located in Paris. NXP Mifare UltraLight C chips were embedded in the disposable wristbands (featuring the SpringCard logo) that were worn by 3000 attendees.

Starting from SpringCard SDK, ECE students working on the project have written in only a few days a dedicated cashier software (in C# for .NET). A clever use of UltraLight C security capabilities (3-DES authentication) allowed them to make sure that no money could be lost during the event.

The team appears in a short video that aims to promote the concept :