| |
| Selecting Smart Card Hardware |  |
Updated: March 28, 2003 Single smart cards and smart card readers are relatively inexpensive. However, when you deploy smart cards and smart card readers to hundreds or even thousands of users, equipment cost becomes an important consideration. You must evaluate smart card hardware in order to select the devices that best meet the needs of your organization at the best price. Figure 16.3 shows the process for selecting smart card hardware.
Figure 16.3 Selecting Smart Card Hardware |
|
| Selecting Group Policy Settings to Manage Smart Card Use | |
Updated: March 28, 2003 Several Group Policy settings are specific to smart card management. You can use these Group Policy settings to manage smart cards in your organization. Note • | Other security policy settings, such as lockout policy or restricted logon times, can also impact smart card users if they use their cards for account logon. |
Smart card required for interactive logon When you set this policy on a user account, the user cannot log on to the account by using a password. They can only log on by using a smart card. The advantage of using this policy setting is that it enforces strict security. However, if users are unable to log on by using conventional passwords, you must provide an alternate solution in the event that smart cards become unusable. Note • | This policy setting applies to interactive and network logons only. It does not apply to remote access logons, which are managed by policy settings that are configured on the remote access server. |
The Smart card required for interactive logon policy is not recommended for users who need to: • | Join a computer to a domain. | • | Perform administrative tasks such as installing Active Directory on a member server. | • | Configure a network connection for remote access. |
If you choose not to use this security policy setting, users can revert to their standard network passwords if their smart cards are damaged or unavailable. However, this weakens security. In addition, users who use their passwords infrequently might forget them, and either write them down, or call the help desk for a password reset, increasing help desk costs to the organization. On smart card removal Users who walk away from computers that are running an active logon session create a security risk. To enforce the security of your system, it is best if users either log off or lock their computers when they leave. The On smart card removal policy allows you to force users to log off or lock their computers when they remove their smart cards. Note • | If you select the forced logoff option, users need to make sure they have saved changes to documents and other files before they remove their smart cards. Otherwise, they lose any changes they have made. |
Whether or not you set the On smart card removal policy depends on how your users interact with their computers. For example, this policy is a good choice if using computers in an open floor or kiosk environment. This policy might not be necessary when users have dedicated computers or exclusive use of multiple computers. You can use a password-protected screensaver or other means to lock the computers of these users. Note • | The On smart card removal policy is a local computer policy that is administered on a per computer basis. Set the On smart card removal policy on a per user account basis, along with other domain security policy settings. |
Do not allow smart card device redirection Use the Do not allow smart card device redirection policy if you do not want to use smart cards in conjunction with Terminal Services sessions. Restrict this use of smart cards if you are concerned about the network resources required for Terminal Services sessions in your environment. Account lockout threshold Use the Account lockout threshold policy to disable accounts after a set number of failed logon attempts. An account that is locked out cannot be used until an administrator resets it, or until the account lockout duration expires. You can specify a value of between 1 and 999 failed logon attempts, or you can specify that the account is never locked out by setting the value to 0. To thwart unauthorized attempts to use a smart card and PIN, establish account lockout thresholds to a low value, such as four or five attempts. For more information about creating a strategy for unlocking smart cards, see "Defining Administrative and Support Processes [http://technet2.microsoft.com/WindowsServer/en/library/e85b95ba-d797-40b7-a978-de693ce3a9c71033.mspx] " later in this chapter. |
 |
|
| Smart Card Removal Options in Windows 2000 | |
This article was previously published under Q227873 IMPORTANT: This article contains information about modifying the registry. Before you modify the registry, make sure to back it up and make sure that you understand how to restore the registry if a problem occurs. For information about how to back up, restore, and edit the registry, click the following article number to view the article in the Microsoft Knowledge Base: 256986 (http://support.microsoft.com/kb/256986/EN-US/) Description of the Microsoft Windows Registry SUMMARYThere are two options that you can enable in Windows 2000 for smart card removal. The first option locks the computer when a smart card is removed. This option lets you take a smart card with you when you leave your desk, keeping the session protected. The second option logs you off the workstation when you remove a smart card. MORE INFORMATIONWARNING: If you use Registry Editor incorrectly, you may cause serious problems that may require you to reinstall your operating system. Microsoft cannot guarantee that you can solve problems that result from using Registry Editor incorrectly. Use Registry Editor at your own risk. To enable either of these options, set the data value of the ScRemoveOption value in the following registry key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon Value: ScRemoveOption (REG_SZ) Setting: 0 - No action 1 - Lock workstation 2 - Force logoff
APPLIES TO| • | Microsoft Windows 2000 Server | | • | Microsoft Windows 2000 Advanced Server | | • | Microsoft Windows 2000 Professional Edition | | • | Microsoft Windows 2000 Datacenter Server |
 Back to the top
| kbenv kbhardware kbinfo KB227873 |
|
| |
|
| Windows Vista Smart Card Infrastructure | |
Windows Vista® Smart Card Infrastructure provides details about the Microsoft® Windows® smart card infrastructure and how smart card-related components work in Windows. This document also contains information about troubleshooting and debugging tools, and tools that information technology (IT) developers and administrators can use to deploy smart card-based strong authentication in the enterprise. Audience This document provides low-level details of how the Windows smart card infrastructure works. You must have basic knowledge of public key infrastructure (PKI) and smart card concepts to make full use of the recommendations in this document. This document is intended for: Developers and enterprise IT professionals who are planning or implementing a smart card deployment. This includes IT directors and IT personnel. Smart card vendors who write smart card mini-drivers or credential providers. This document details the inner workings of the Windows smart card architecture and provides information about how IT departments will plan for smart card deployments.
Windows Smart Card Infrastructure Smart card support was initially included in Windows 2000. Windows Server 2003 and Windows XP also support smart cards.  Note
| The smart card service (SCardSvr.exe) and WinSCard API were available as optional components for Windows 95, Windows 98, and Windows ME. |
Because smart cards were integrated into Windows 2000, users can log on and sign and encrypt e-mail digitally. However, there are some limitations in the implementation. Before Windows Vista: A smart card could support only one certificate for logon. Only one container on the smart card could be marked default. Additional certificates could be stored on the smart card for other purposes, such as S/MIME. Changing the PIN and unblocking a smart card were not natively supported or integrated. As a result, a user had to log on first with a standard user name and password to perform these tasks.
Windows Vista enhancements Winlogon has been re-architected in Windows Vista. In previous versions of Windows, a custom GINA dynamic link library (DLL) was used to support customizable user identification and authentication. On Windows Vista, the GINA functionality has been distributed among three components: MSGINA.DLL has been removed, and custom GINAs will not be loaded on systems running Windows Vista and later versions. Both the password credential provider and the smart card credential provider are provided by default, and the ability to support custom authentication mechanisms will require the creation of a custom credential provider. After Winlogon launches the logon UI, it loads registered credential providers. The smart card credential provider uses interfaces that are exposed through the credential provider framework to gather the required credentials, package them, and return them to the logon UI. Then the logon UI passes the credentials to Winlogon to be used for Kerberos authentication. In Vista, Winlogon supports multiple logon certificates and containers on the same smart card. The number of certificates that can be stored and containers that can be created depends on how much space is available on the smart card. Each smart card must have a cryptographic service provider (CSP). A CSP uses the Cryptography Application Programming Interface (CAPI) interfaces on the top and the WinSCard APIs at the bottom. (For detailed information, see Smart card subsystem architecture.) In the past, writing a smart card CSP was not a trivial task. However, a new CSP called the Base CSP now helps facilitate writing a smart card CSP. The Base CSP allows smart card vendors to write card-specific modules called smart card mini-drivers. Microsoft provides the Base CSP as part of the platform. A downloadable package of it exists for Windows XP SP2, Windows 2000 SP4, and Windows Server 2003 SP1. A smart card mini-driver is an interface that Microsoft supports for smart card vendors to write implementations to their smart card. This is analogous to writing a printer driver for a printer. WinSCard API has been extended to provide caching (storing of non-sensitive data on a per-user-basis) at the smart card resource manager level. The smart card resource manager was formerly called the smart card service. To support additional cryptographic algorithms and to provide extensible architecture, Cryptography API: Next Generation (CNG) was designed. Architecturally, this is parallel to CAPI. As with CSP, a key storage provider (KSP) is beneath the CNG. In Windows Vista, smart card KSP implementation is provided by default. The same smart card mini-driver interface that is available for Base CSP is also applicable for smart card KSP. Smart card mini-driver support for RSA and elliptic curve cryptography (ECC) is available with smart card KSP. |
| |
|
| Group Policy Administrative Tools | |
Updated: March 28, 2003 Group Policy Administrative Tools There are three primary tools used to administer Group Policy: Microsoft Group Policy Management Console (GPMC), Group Policy Object Editor, and Resultant Set of Policy (RSoP) snap-in. Each of these tools is a Microsoft Management Console (MMC). Administrators use GPMC for the bulk of Group Policy management tasks. Group Policy Object Editor is for editing Group Policy objects. Although administrators can still use the RSoP snap-in for reporting and planning the effects of Group Policy, much of its functionality has been subsumed into GPMC.
Group Policy Administrative Tools Architecture
The diagram below illustrates the relationship between the domain controller, client, and the three primary tools used to administer Group Policy. Group Policy Administrative Tools Architectural Diagram
Components of Group Policy Administrative Tools Architectural Diagram Component | Description | Group Policy Object Editor | The Group Policy Object Editor is used to edit GPOs. It was previously known as the Group Policy snap-in, Group Policy Editor, or Gpedit. A notable feature of the Group Policy Object Editor is its extensibility. Developers can extend the server-side snap-ins that ship with Group Policy Object Editor or they can develop completely new extensions for implementing Group Policy. The Group Policy Object Editor is capable of read and write access to Active Directory, Sysvol, and the Local GPO. | Server-Side Snap-Ins | The nodes of the Group Policy Object Editor are MMC snap-ins. These snap-ins include Administrative Templates, Scripts, Security Settings, Software Installation, Folder Redirection, Remote Installation Services, and Internet Explorer Maintenance. Snap-ins may in turn be extended. For example, the Security Settings snap-in includes several extension snap-ins. Developers can also create their own MMC extension snap-ins to the Group Policy Object Editor to provide additional policy settings. Extensions are capable of read and write access to the Local GPO. | Group Policy Management Console (GPMC) | GPMC makes Group Policy much easier to manage by providing a view of GPOs, sites, domains, and organizational units (OU) across an enterprise. GPMC can be used to manage either Windows Server 2003 or Windows 2000 domains. GPMC simplifies the management of Group Policy by providing a single place for managing core aspects of Group Policy, such as scoping, delegating, filtering, and manipulating inheritance of GPOs. You can also back up GPOs to the file system as well as restore GPOs from backups. GPMC includes features that enable an administrator to predict how GPOs are going to affect the network as well as to determine how GPOs have actually changed settings on any particular computer or user. GPMC is capable of read and write access to the Sysvol using the SMB protocol. It is also capable of read and write access to Active Directory via the LDAP protocol. In addition, GPMC is capable of read access to the event log and RSoP infrastructure. | Resultant Set of Policy (RSoP) snap-in | The Resultant Set of Policy snap-in is an MMC used to determine which policy settings are in effect for a given User or Computer, or to predict the effect of applied policy. The snap-in itself is contained within the same binary as the Group Policy Object Editor snap-in (gpedit.dll). The user interface is mostly a read-only view of the same information available in the Group Policy Object Editor. However there is one important difference: While the Group Policy Object Editor can show only a single GPO setting at a time, the RSoP snap-in shows the cumulative effect of many GPOs. For RsoP functionality it is recommended to use GPMC, which includes its own integrated RsoP features. The RSoP snap-in is capable of read access to the Active Directory, Sysvol, Event Log, RSoP infrastructure, and Local GPO. Although the RSoP snap-in is capable of read only access to the Active Directory and Sysvol, most of the work of predicting or reporting Group Policy is done using RPC/COM communication with the RSoP provider, either on the client or the domain controller. | Domain Controller (Server) | In an Active Directory forest, the domain controller is a server that contains a writable copy of the Active Directory database, participates in Active Directory replication, and controls access to network resources. GPOs are stored in two parts of domain controllers: The Active Directory database and the Sysvol share. |
Client | In an Active Directory forest, settings from GPOs are applied to clients. GPMC and the RSoP snap-in query the client to determine how policy has been applied to a particular user or computer. | Active Directory | Active Directory, the Windows-based directory service, stores information about objects on a network and makes this information available to users and network administrators. Administrators link GPOs to Active Directory containers such as sites, domains, and OUs that include user and computer objects. In this way, policy settings can be targeted to users and computers throughout the organization. | Sysvol | Sysvol is a shared directory that stores the server copy of the domain’s public files, which are replicated among all domain controllers in the domain. The Sysvol contains the largest part of a GPO: the Group Policy template (GPT), which includes Administrative Template-based policy settings, security settings, and script files. File Replication Service (FRS) replicates this information throughout the network. | RsoP infrastructure | All Group Policy processing information is collected and stored in a Common Information Model Object Management (CIMOM) database on the local computer. This information, such as the list of GPOs that have been processed, as well as content and logging of processing details for each GPO, can then be accessed by tools using Windows Management Instrumentation (WMI). With Group Policy Results in GPMC, or logging mode for the RSoP snap-in, the RSoP service is used to query the CIMOM database on the target computer; it receives information about the policies that were applied and displays the resulting information in GPMC or the RSoP snap-in. With Group Policy Modeling in GPMC, or planning mode for the RSoP snap-in, the RSoP service simulates the application of policy using the Group Policy Directory Access Service (GPDAS) on a Domain Controller. GPDAS simulates the application of GPOs and passes them to virtual client-side extensions on the Domain Controller. The results of this simulation are stored in a local CIMOM database on the domain controller before the information is passed back and displayed in either GPMC or the RSoP snap-in. |
|
| |
|
| Architecture - Windows Smart Card Infrastructure | |
Architecture The smart card registry database is located in HKLM\Software\Microsoft\Cryptography\Calais\SmartCard. This database contains smart card and smart card reader information. The smart card infrastructure in Windows includes two primary components: Windows interactive logon architecture Before Windows Vista, the Windows interactive logon architecture included the components shown in Table 1. Table 1 Pre-Windows Vista interactive logon components Component | Description | Winlogon | Provides interactive logon infrastructure. | Graphical Identification and Authentication (GINA) component | Provides interactive UI rendering. | Local Security Authority (LSA) | Processes logon credentials. | Authentication packages | Includes NTLM and Kerberos. Communicates with server authentication packages to authenticate users. |
Windows Vista credential provider architecture Table 2 shows the components in the Windows Vista interactive logon architecture. Table 2 Windows Vista interactive logon components Component | Description | Winlogon | Provides interactive logon infrastructure. | Logon UI | Provides interactive UI rendering. | Credential providers (password and smart card) | Describes credential information and serializing credentials. | LSA | Processes logon credentials. | Authentication packages | Includes NTLM and Kerberos. Communicates with server authentication packages to authenticate users. |
Figure 1 Windows credential provider architecture 
Windows Vista interactive logons begin when the user presses CTRL+ALT+DEL. The CTRL+ALT+DEL key combination is called a secure attention sequence (SAS). Winlogon registers this sequence during the boot process, in order to keep other programs and processes from using it. The logon UI then generates the tile from information received from the registered credential providers. The following figure shows the Windows Vista logon dialog. Figure 2 Windows Vista logon user interface 
A user who logs on to a computer using either a local account or a domain account must enter a user name and password. These credentials are used to verify the user’s identity. However, in the case of smart card logons, a user’s credentials are contained on the smart card’s security chip. An external device called a smart card reader reads the security chip. During a smart card logon, a user enters a personal identification number (PIN) instead of a user name, domain, and password. Credential providers are in-process COM objects that are used to collect credentials in Windows Vista and run in local system context. In summary, the logon UI provides interactive UI rendering, Winlogon provides interactive logon infrastructure, and credential providers help gather and process credentials. In Windows Vista, Winlogon instructs the logon UI to display tiles after it receives a SAS event. Logon UI queries each credential provider for the number of credentials it wants to enumerate. Credential providers have the option of specifying one of these tiles as the default. After all providers have enumerated their tiles, the logon UI displays them to the user. The user interacts with a tile to supply his or her credentials. The logon UI submits these credentials for authentication. Combined with supporting hardware, credential providers can extend the Microsoft Windows operating system to enable users to log on through biometric (fingerprint, retinal, or voice recognition), password, PIN, smart card certificate, or any custom authentication package a third-party developer wants to create. Enterprises and IT professionals may develop and deploy custom authentication mechanisms for all domain users and may explicitly require users to use this custom logon mechanism. Credential providers are not enforcement mechanisms. They are used to gather and serialize credentials. The LSA and authentication packages enforce security. Credential providers may be designed to support single sign-on (SSO), authenticating users to a secure network access point (by using RADIUS and other technologies) as well as computer logon. Credential providers are also designed to support application-specific credential gathering, and may be used for authentication to network resources, joining computers to a domain, or to provide administrator consent for User Account Control (UAC). Multiple credential providers may co-exist on a computer. Credential providers are registered on a Windows Vista computer and are responsible for: - Describing the credential information required for authentication
- Handling communication and logic with external authentication authorities.
- Packaging credentials for interactive and network logon.
The Credential Provider API does not design UI. It does describe what needs to be rendered. Only password credential provider is available in safe mode. In-box smart card credential provider is available in safe mode with networking. For more information on credential providers and their uses, please refer to the Credential Provider Technical Reference (http://go.microsoft.com/fwlink/?LinkId=93340). Figure 3 illustrates Windows Vista logon screen flow with PIN unblock and PIN change. Figure 3 PIN unblock and PIN change user experience 
Smart card subsystem architecture Vendors and partners are very important for the success of smart card-based scenarios. Vendors provide smart cards and smart card readers, and in many cases the smart card and reader vendors are different. Reader drivers are written to the PC/SC standard version 1.0. Each smart card must have a CSP that uses the CAPI interfaces on the top and the WinSCard APIs at the bottom. The GINA module also has smart card logon capability to provide the relevant user interface for capturing the credentials and subsequent marshalling to be sent to the LSALogonUser for authentication. Base CSP and smart card mini-driver architecture for Windows 2000, Windows XP, and Windows 2003 Requirements: The Base CSP must be installed. The Base CSP is a free, optional download available at the Microsoft Web site (http://go.microsoft.com/fwlink/?LinkId=93341). Figure 4 illustrates how CAPI, CSPs, the Base CSP, and smart card mini-drivers are architecturally layered. Figure 4 Base CSP and smart card mini-driver architecture 
Smart card selection heuristics Container specification levelsIn response to a CryptAcquireContext call, the Base CSP will try to match the container that the caller specifies to a specific card and reader. The caller can provide a container name with varying levels of specificity, shown in the following list, sorted from more-specific to less-specific requests. Similarly for the smart card KSP, NCryptOpenKey takes the same format as shown in Table 3. Before open key, a call NCryptOpenStorageProvider(MS_SMART_CARD_KEY_STORAGE_PROVIDER) is made. Table 3 Container specification levels Type | Name | Format | I | Reader Name and Container Name | \\.\<Reader Name>\<Container Name>\ | II | Reader Name and Container Name (NULL) | \\.\<Reader Name>\ | III | Container Name Only | <Container Name> | IV | Default Container (NULL) Only | NULL |
For the first two cases, in which a reader name is provided, the Base CSP usually will search for the specified reader and perform the requested operation on the card inserted in that reader. For the second two cases, in which a smart card reader name is not provided, the Base CSP will search for a card and reader suitable for the current request, beginning with cards already known to the Base CSP and continuing to all smart cards and readers available with the smart card subsystem. For each of the above cases, the Base CSP will first search for a matching card in its list of cached card data. This cache includes a list of smart cards and associated smart card state information that the CSP has encountered in the current session (where the session will typically be the lifetime of the current process). In general, if a matching smart card is found in the cache, the card handle associated with the cache item should be refreshed. This determines whether the card is still in the reader, because the smart card might have been removed since the cache item was created. If a matching smart card is found cached, but the cached smart card handle is no longer valid, the SCardUIDlg API is used to refresh the card handle. Additional information, such as the serial number of the matching smart card, is provided to SCardUIDlg to help filter candidate smart cards quickly. |
| |
|
| Container operations | |
Container operations Three main container operations can be requested using CryptAcquireContext. These are: - Create new container (CRYPT_NEWKEYSET)
- Open existing container
- Delete container (CRYPT_DELETEKEYSET)
The heuristics that are used to associate a user context with a particular card and reader are based mainly on the container operation requested and the level of container specification used. Table 4 shows the restrictions for the container creation operation. Table 4 Container creation operation restrictions Specification | Restriction | No Silent context | Key container creation must always be able to show UI, such as the PIN prompt. | No overwriting existing containers | If the specified container already exists on the chosen smart card, either chose another card or cancel the operation. |
Context flagsTable 5 shows the context flags for the container creation operation restrictions. Table 5 Restriction flags Flag | Description | CRYPT_SILENT | No UI may be displayed during this operation. | CRYPT_MACHINE_KEYSET | No cached data should be used during this operation. | CRYPT_VERIFYCONTEXT | Only public data may be accessed on the smart card. |
In addition to container operations and container specification, you must consider other user options, such as the above CryptAcquireContext flags, during card selection.  Important
| The CRYPT_SILENT flag cannot be used with container operation A (create new container). |
Creating a new container in silent context Applications can call the Base CSP with CRYPT_DEFAULT_CONTAINER_OPTIONAL, set the PIN in silent context, and then create a new container in silent context: 1. Call CryptAcquireContext passing the smart card reader name in as type II, specifying the CRYPT_DEFAULT_CONTAINER_OPTIONAL flag. 2. Call CryptSetProvParam by specifying PP_KEYEXCHANGE_PIN or PP_SIGNATURE_PIN and a null-terminated ASCII PIN. 3. Release the context acquired in Step 1. 4. Call CryptAcquireContext with CRYPT_NEWKEYSET specifying the type I format. 5. Call CryptGenKey to create the key. Smart card selection behavior In some of the following scenarios, the user can be prompted to insert a smart card. If the user context is silent, this operation fails and no UI is displayed. Otherwise, in response to the UI, the user may either insert a smart card or click Cancel. If the user cancels the operation, the operation fails. Figure 5 Smart card selection behavior 
In general, card selection behavior will be handled by the SCardUIDlgSelectCard API. The Base CSP will interact with this API by calling it directly. The Base CSP will also send callback functions, whose purpose will be to filter and match candidate smart cards. Callers of CryptAcquireContext provide card matching information. Internally, the Base CSP uses a combination of smart card serial numbers, reader names, and container names to find specific smart cards. Each call to SCardUI* may result in additional information read from a candidate smart card. The Base CSP smart card selection callbacks cache this information. The SCardUI* API is used to refresh smart card handles, because a target smart card may be removed or re-inserted after a card handle has been cached. The matching serial number is discovered by FindCachedCard(), which is passed to FindCard() along with a status indicating that the search was successful but that the card handle needs to be re-acquired. (Or that the corresponding smart card state structure could be returned, instead of just the serial number. This would prevent the callback from having to search the list of cards again.) FindCard will provide the serial number to the appropriate card-matching callback using SCardUI*. Making a reader match For container specification levels I and II, the smart card selection process is less complex because only the smart card in the named reader can be considered a match. 1. Find the requested reader. If it cannot be found, the process fails. (This requires a cache search by reader name.) 2. If no smart card is in the reader, the user is prompted to insert a smart card (only in non-silent mode; if the call is made in silent mode, it will fail). 3. For level II only, the name of the default container on the chosen smart card is determined. 4. For container operations B (open existing) and C (delete), find the specified container. If the specified container cannot be found on this smart card, the user is prompted to insert a smart card. 5. For container operation A (create new), if the specified container already exists on this smart card, the process fails. Making a smart card match For container specification levels III and IV, a broader method is used to match an appropriate card with a user context, because multiple cached smart cards might meet the criteria provided. Open existing default container - no reader specified Note | This scenario requires that you use the smart card KSP with the Base CSP. |
1. For each smart card already known by the Base CSP, look for a valid default container. An operation is attempted on the cached SCARDHANDLE to verify its freshness. If the smart card handle is not valid, the Base CSP continues to search for a new smart card. 2. If a matching card is not found in the Base CSP cache, call into the smart card subsystem. SCardUIDlgSelectCard() is used with an appropriate callback filter to find a matching card with a valid default container. Open existing GUID-named container, no reader specified Note | This scenario requires that you use the smart card KSP with the Base CSP. |
1. For each smart card that the Base CSP already knows, look for the requested container. Attempt an operation on the cached SCARDHANDLE to verify its freshness. If the card handle is not valid, the smart card’s serial number is passed to the SCardUI* API to continue searching for this specific smart card (rather than only a general match for the container name). 2. If a matching card is not found in the Base CSP cache, a call is made into the smart card subsystem. SCardUIDlgSelectCard() is used with an appropriate callback filter to find a matching card with the requested container. Or, if a smart card serial number resulted from the search in Step 1, the callback filter attempts to match the serial number, not the container name. Create new container, no reader specified Note | This scenario requires that you use the smart card KSP with the Base CSP. |
If the PIN is not cached, no CRYPT_SILENT is allowed on container creation because the user must be prompted for a PIN, at a minimum. For other operations, the caller may be able to acquire a “verify” context against the default container (CRYPT_DEFAULT_CONTAINER_OPTIONAL) and then make a CryptSetProvParam call to cache the user PIN for subsequent operations. 1. For each smart card already known by the CSP, refresh the stored SCARDHANDLE and make the following checks: a. If the smart card has been removed, continue the search. b. If the smart card is still present but already has the named container, continue the search. c. If the smart card is available, but a call to CardQueryFreeSpace indicates that the card has insufficient storage for an additional key container, continue the search. d. Otherwise, use the first available smart card that meets the above criteria for the container creation. 2. If a matching smart card is not found in the CSP cache, call into the smart card subsystem. The callback used to filter enumerated smart cards should verify that a candidate smart card does not already have the named container, and that CardQueryFreeSpace indicates that the card has sufficient space for an additional container. If no suitable card is found, display UI prompting the user to insert a smart card. Delete a container 1. If the specified container name is NULL, then the default container is deleted. Deleting the default container causes a new default container to be selected arbitrarily. For this reason, this operation is not recommended. 2. For each smart card already known by the CSP, refresh the stored SCARDHANDLE and make the following ch |
|
| |
|