Smart Card Minidrivers




Article
12/15/2021
2 minutes to read
2 contributors
The smart card minidriver provides a simpler alternative to developing a legacy cryptographic
service provider (CSP) by encapsulating most of the complex cryptographic operations from the
card minidriver developer.
For information about the specification for smart card minidrivers, see Smart Card Minidriver
Specification.
Beginning with Windows Vista, applications can use the Microsoft Cryptography API: Next
Generation (CNG) for smart card–based cryptographic services. As part of the elliptic curve
cryptography (ECC) effort that was introduced in Windows Vista, ECC smart cards are supported
in the new cryptographic framework. Applications and interfaces that interact with existing
Rivest-Shamir-Adleman (RSA) card minidrivers through the legacy CAPI subsystem continue to
work without modification.
RSA smart card minidrivers can also be registered with the smart card key storage provider (KSP)
so that they can be called through the CNG interface. Dual-mode ECC/RSA + ECC-only requests
are routed to the KSP and, through it, to the appropriate card minidrivers. For Windows Vista–
based clients, ECC-only and ECC/RSA dual-mode cards are supported by using the Windows
smart card framework. Dual-mode cards can also be accessed through CAPI primarily to expose
RSA-only features.
Applications use CAPI for smart card–based cryptographic services. CAPI, in turn, routes these
requests to the appropriate CSP to handle the cryptographic requirements.
The Microsoft Smart Card Base CSP and KSP is a refinement of the architecture that separates
commonly needed CAPI-based CSP and CNG-based KSP functionality, respectively, from the
implementation details that must change for every card vendor.
Although Base CSP can use the RSA capabilities of a smart card only by using the minidriver, the
CNG-based KSP supports ECC-only as well as ECC/RSA dual-mode smart cards in Windows Vista
and later versions of Windows.
Ultimately, the intention is for the new architecture to support all new smart cards—RSA, ECC,
and whatever follows. It splits the implementation of the CSP into two parts:


The Base CSP/KSP (the common part), which includes functionality for hashing, symmetric,
and public key cryptographic operations in addition to personal identification number
(PIN) entry and caching.
A series of plug-ins, which are known as “card minidrivers,” that translate the characteristics
of particular smart cards into a uniform interface that is the same for all smart cards. Card
minidrivers then communicate with their cards by using the services of the smart card
resource manager (SCRM) that similarly abstracts the characteristics of a variety of smart
card readers.
The remaining portion for smart card vendors is to implement a card minidriver, a reasonably
limited interface layer that provides an abstraction of the card to the Base CSP/KSP and that is
organized as a file system, and a set of primitive capabilities. Higher order functionality, such as
caching (ensuring that different files on the card have consistent content) or handling naming
collisions, is handled at a higher level, outside the card minidriver.
The following figure shows the interfaces between card minidrivers and CAPI-based
applications.
CSP-Minidriver Specification
The CSP-Minidriver is build on top of the token interface, which is part of the PKCS#11 module.
It inherits card and crypto support from the PKCS#11 module.
The CSP-Minidriver is a read-only driver that exposes RSA and ECDSA private keys, public keys
and certificates at it's interface. The CSP-Minidriver is based on the Smart Card Minidriver
Specification v7.07. It supports Windows 7, Windows 8 (8.1) and Windows 10. As it is a read-only
driver, generating keys and writing certificates is not supported. Key and certificate provisioning
can be done using OpenSCDP and the Smart Card Shell or via an application that supports the
PKCS#11 interface. A read/write CSP for the SmartCard-HSM is available as part of the OpenSC
Project.
Cryptography Functions




Article
08/20/2021
41 minutes to read
7 contributors
Cryptography functions are categorized according to usage as follows:
CryptXML Functions
Signer Functions
Base Cryptography Functions
o Service Provider Functions
o Key Generation and Exchange Functions
o Object Encoding and Decoding Functions
o Data Encryption and Decryption Functions
o Hash and Digital Signature Functions
 Certificate and Certificate Store Functions
o Certificate Store Functions
o Certificate and Certificate Store Maintenance Functions
o Certificate Functions
o Certificate Revocation List Functions
o Certificate Trust List Functions



Extended Property Functions
MakeCert Functions
Certificate Verification Functions
o Verification Functions Using CTLs
o Certificate Chain Verification Functions
Message Functions
o Low-level Message Functions
o Simplified Message Functions
Auxiliary Functions
o Data Management Functions
o Data Conversion Functions
o Enhanced Key Usage Functions
o Key Identifier Functions
o OID Support Functions
o Remote Object Retrieval Functions
o PFX Functions
Certificate Services Backup and Restore Functions
Callback Functions
Catalog Definition Functions
Catalog Functions
WinTrust Functions
Object Locator Functions
o










Base Cryptography Functions
Base cryptographic functions provide the most flexible means of developing cryptography
applications. All communication with a cryptographic service provider (CSP) occurs through these
functions.
A CSP is an independent module that performs all cryptographic operations. At least one CSP is
required with each application that uses cryptographic functions. A single application can
occasionally use more than one CSP.
If more than one CSP is used, the one to use can be specified in the CryptoAPI cryptographic
function calls. One CSP, the Microsoft Base Cryptographic Provider, is bundled with
the CryptoAPI. This CSP is used as a default provider by many of the CryptoAPI functions if no
other CSP is specified.
Each CSP provides a different implementation of the cryptographic support provided to
CryptoAPI. Some provide stronger cryptographic algorithms; others contain hardware
components, such as smart cards. In addition, some CSPs can occasionally communicate directly
with users, such as when digital signatures are performed by using the user's signature private
key.
Base cryptographic functions are in the following broad groups:





Service Provider Functions
Key Generation and Exchange Functions
Object Encoding and Decoding Functions
Data Encryption and Decryption Functions
Hash and Digital Signature Functions
Microsoft has two versions of cryptography susbsytems: Legacy CrypotAPI (simply CryptoAPI or
CAPI) and Cryptography Next Generation (CNG, CAPI2).
CrytpoAPI was invented in Windows 2000. Legacy CryptoAPI is morally outdated with no support for
ECC, SHA2: only RSA/legacy DSA (up to 1k long keys), DES/3DES, RCx, no built-in AES. Keys are
stored in legacy Cryptography Service Provider (or CSP). Though, in Windows Vista+, a legacy CSP
with SHA2 and AES was added to help older applications to utilize them without much changes in
code.
CNG was first introduced back in 2007 in Windows Vista/Windows Server 2008 and is really a good
stuff: it is pretty extensible, with native support of NSA Suite B cryptography (ECC asymmetric keys,
SHA2 algorithm groups), key isolation, unified set of BCrypt functions and must more. Most CNGonly APIs include NCrypt, BCrypt, CNG, NG suffixes/prefixes in their names to explicitly say it is CNG
APIs. In CNG, keys are stored in redesigned CSP called Key Storage Provider (KSP) to distinguish it
from legacy CSP, because they are not same (though, there is a one-way bridge to access CSP from
KSP, but not otherwise).
However, .NET was struggling in adopting CNG and made it more-or-less usable only in .NET 4.7
(implementations existed before, but with known limitations) and 3rd party applications support
CNG only when they explicitly add support for it, because CNG uses different APIs and .NET
Framework upgrade doesn't make application CNG-capable.
This was a bit of theory on what is the difference between CAPI and CAPI2.