Architecture des cartes à puce

• S’applique à:

  ✅ Windows 11, ✅ Windows 10, ✅ Windows Server 2025, ✅ Windows Server 2022, ✅ Windows Server 2019, ✅ Windows Server 2016

Cette rubrique destinée aux professionnels de l’informatique décrit l’architecture système qui prend en charge les cartes à puce dans le système d’exploitation Windows, y compris l’architecture du fournisseur d’informations d’identification et l’architecture du sous-système smart carte.

L’authentification est un processus permettant de vérifier l’identité d’un objet ou d’une personne. Lorsque vous authentifiez un objet, tel qu’un carte intelligent, l’objectif est de vérifier que l’objet est authentique. Lorsque vous authentifiez une personne, l’objectif est de vérifier que vous n’avez pas affaire à un imposteur.

Dans un contexte de mise en réseau, l’authentification est l’acte de prouver l’identité d’une application ou d’une ressource réseau. En règle générale, l’identité est prouvée par une opération de chiffrement qui utilise une clé que seul l’utilisateur connaît (par exemple avec le chiffrement à clé publique) ou une clé partagée. Le côté serveur de l’échange d’authentification compare les données signées avec une clé de chiffrement connue pour valider la tentative d’authentification. Le stockage des clés de chiffrement dans un emplacement central sécurisé rend le processus d’authentification évolutif et maintenable.

Pour les cartes à puce, Windows prend en charge une architecture de fournisseur qui répond aux exigences d’authentification sécurisée et est extensible afin que vous puissiez inclure des fournisseurs d’informations d’identification personnalisés. Cette rubrique contient des informations sur :

• Architecture du fournisseur d’informations d’identification
• Architecture du sous-système smart carte

Architecture du fournisseur d’informations d’identification

Le tableau suivant répertorie les composants inclus dans l’architecture de connexion interactive :

Composant	Description
Winlogon	Fournit une infrastructure de connexion interactive.
Interface utilisateur d’ouverture de session	Fournit un rendu interactif de l’interface utilisateur.
Fournisseurs d’informations d’identification (mot de passe et carte intelligente)	Décrit les informations d’identification et la sérialisation des informations d’identification.
Autorité de sécurité locale (LSA)	Traite les informations d’identification de connexion.
Packages d’authentification	Inclut NTLM et le protocole Kerberos. Communique avec les packages d’authentification de serveur pour authentifier les utilisateurs.

La connexion interactive dans Windows commence lorsque l’utilisateur appuie sur Ctrl+Alt+Suppr. La combinaison de touches Ctrl+Alt+Suppr est appelée séquence d’attention sécurisée (SAS). Pour empêcher d’autres programmes et processus de l’utiliser, Winlogon inscrit cette séquence pendant le processus de démarrage.

Après avoir reçu la SAP, l’interface utilisateur génère la vignette de connexion à partir des informations reçues des fournisseurs d’informations d’identification inscrits. Le graphique suivant montre l’architecture des fournisseurs d’informations d’identification dans le système d’exploitation Windows.

En règle générale, un utilisateur qui se connecte à un ordinateur à l’aide d’un compte local ou d’un compte de domaine doit entrer un nom d’utilisateur et un mot de passe. Ces informations d’identification sont utilisées pour vérifier l’identité de l’utilisateur. Pour la connexion carte intelligente, les informations d’identification d’un utilisateur sont contenues sur la puce de sécurité du carte intelligent. Un lecteur de carte intelligent permet à l’ordinateur d’interagir avec la puce de sécurité du carte intelligent. Lorsque les utilisateurs se connectent avec un carte intelligent, ils entrent un numéro d’identification personnel (PIN) au lieu d’un nom d’utilisateur et d’un mot de passe.

Les fournisseurs d’informations d’identification sont des objets COM in-process qui s’exécutent sur le système local et sont utilisés pour collecter des informations d’identification. L’interface utilisateur d’ouverture de session fournit un rendu interactif de l’interface utilisateur, Winlogon fournit une infrastructure de connexion interactive et les fournisseurs d’informations d’identification fonctionnent avec ces deux composants pour faciliter la collecte et le traitement des informations d’identification.

Winlogon indique à l’interface utilisateur d’ouverture de session d’afficher les vignettes du fournisseur d’informations d’identification après avoir reçu un événement SAS. L’interface utilisateur d’ouverture de session interroge chaque fournisseur d’informations d’identification pour connaître le nombre d’informations d’identification qu’il souhaite énumérer. Les fournisseurs d’informations d’identification ont la possibilité de spécifier l’une de ces vignettes par défaut. Une fois que tous les fournisseurs ont énuméré leurs vignettes, l’interface utilisateur d’ouverture de session les affiche à l’utilisateur. L’utilisateur interagit avec une vignette pour fournir les informations d’identification appropriées. L’interface utilisateur d’ouverture de session envoie ces informations d’identification pour l’authentification.

Associés au matériel de prise en charge, les fournisseurs d’informations d’identification peuvent étendre le système d’exploitation Windows pour permettre aux utilisateurs de se connecter à l’aide de la biométrie (par exemple, la reconnaissance digitale, rétinienne ou vocale), d’un mot de passe, d’un code confidentiel, d’un certificat carte intelligent ou de tout package d’authentification personnalisé. Les entreprises et les professionnels de l’informatique peuvent développer et déployer des mécanismes d’authentification personnalisés pour tous les utilisateurs du domaine, et ils peuvent exiger explicitement que les utilisateurs utilisent ce mécanisme de connexion personnalisé.

Remarque

Les fournisseurs d’informations d’identification ne sont pas des mécanismes d’application. Ils sont utilisés pour collecter et sérialiser les informations d’identification. Les packages LSA et d’authentification appliquent la sécurité.

Les fournisseurs d’informations d’identification peuvent être conçus pour prendre en charge l’authentification unique (SSO). Dans ce processus, ils authentifient les utilisateurs auprès d’un point d’accès réseau sécurisé (à l’aide de RADIUS et d’autres technologies) pour se connecter à l’ordinateur. Les fournisseurs d’informations d’identification sont également conçus pour prendre en charge la collecte d’informations d’identification spécifiques à l’application, et ils peuvent être utilisés pour l’authentification auprès des ressources réseau, la jonction d’ordinateurs à un domaine ou pour fournir le consentement de l’administrateur pour le contrôle de compte d’utilisateur (UAC).

Plusieurs fournisseurs d’informations d’identification peuvent coexister sur un ordinateur.

Les fournisseurs d’informations d’identification doivent être inscrits sur un ordinateur exécutant Windows, et ils sont responsables des tâches suivantes :

• Description des informations d’identification requises pour l’authentification
• Gestion de la communication et de la logique avec des autorités d’authentification externes
• Empaquetage des informations d’identification pour la connexion interactive et réseau

Remarque

L’API du fournisseur d’informations d’identification ne restitue pas l’interface utilisateur. Il décrit ce qui doit être rendu.
Seul le fournisseur d’informations d’identification de mot de passe est disponible en mode sans échec.
Le fournisseur d’informations d’identification smart carte est disponible en mode sans échec pendant la mise en réseau.

Architecture du sous-système smart carte

Les fournisseurs fournissent des cartes à puce et des lecteurs de carte intelligents. Dans de nombreux cas, les fournisseurs sont différents pour le carte intelligent et le lecteur carte intelligent. Les pilotes pour les lecteurs de carte intelligente sont écrits dans la norme ordinateur personnel/carte à puce (PC/SC). Chaque carte intelligent doit avoir un fournisseur de services de chiffrement (CSP) qui utilise les interfaces CryptoAPI pour activer les opérations de chiffrement, et les API WinSCard pour activer les communications avec du matériel carte intelligent.

Architecture du fournisseur de solutions Cloud de base et du minidriver smart carte

Le graphique suivant montre la relation entre cryptoAPI, csp, fournisseur de services de chiffrement de base de carte à puce (CSP) et minidrivers smart carte.

Mise en cache avec fournisseur de solutions cloud de base et carte KSP intelligent

L’architecture smart carte utilise des mécanismes de mise en cache pour simplifier les opérations et améliorer l’accès d’un utilisateur à un code confidentiel.

• Mise en cache des données : le cache de données fournit un processus unique pour réduire les opérations d’E/S carte intelligentes
• Mise en cache du code confidentiel : le cache de code confidentiel permet à l’utilisateur d’avoir à revenir à un code confidentiel chaque fois que le carte intelligent n’est pas authentifié

Mise en cache des données

Chaque fournisseur de solutions cloud implémente le cache de données smart carte actuel séparément. Le fournisseur de solutions cloud de base implémente un mécanisme de mise en cache robuste qui permet à un processus unique de réduire les opérations d’E/S carte intelligentes.

Le cache global existant fonctionne comme suit :

1. L’application demande une opération de chiffrement. Par exemple, un certificat utilisateur doit être lu à partir du carte intelligent
2. Le fournisseur csp vérifie l’élément dans son cache
3. Si l’élément est introuvable dans le cache, ou si l’élément est mis en cache mais n’est pas à jour, l’élément est lu à partir du carte
4. Une fois qu’un élément a été lu à partir du carte intelligent, il est ajouté au cache. Toute copie obsolète de cet élément est remplacée

Trois types d’objets ou de données sont mis en cache par le fournisseur de solutions Cloud : les broches (pour plus d’informations, consultez mise en cache du code confidentiel), les certificats et les fichiers. Si l’une des données mises en cache change, l’objet correspondant est lu à partir de la carte intelligente dans des opérations successives. Par exemple, si un fichier est écrit dans le carte intelligent, le cache CSP devient obsolète pour les fichiers, et d’autres processus lisent le carte intelligent au moins une fois pour actualiser leur cache CSP.

Le cache de données global est hébergé dans le service Cartes à puce pour Windows. Windows inclut deux appels d’API de carte intelligents publics, SCardWriteCache et SCardReadCache. Ces appels d’API rendent la fonctionnalité de mise en cache des données globale disponible pour les applications. Chaque carte intelligent conforme à la spécification du minidriver smart carte a un identificateur de carte de 16 octets. Cette valeur est utilisée pour identifier de façon unique les données mises en cache qui se rapportent à un carte intelligent donné. Le type de GUID Windows standard est utilisé. Ces API permettent à une application d’ajouter et de lire des données à partir du cache global.

Mise en cache du code confidentiel

Le cache de code confidentiel empêche l’utilisateur d’entrer un code confidentiel chaque fois que le carte intelligent n’est pas authentifié. Une fois qu’une carte intelligente est authentifiée, elle ne fait pas la distinction entre les applications côté hôte : toute application peut accéder aux données privées sur le carte intelligent.

Pour atténuer ce problème, le carte intelligent passe à l’état exclusif lorsqu’une application s’authentifie auprès du carte intelligent. Toutefois, cela signifie que les autres applications ne peuvent pas communiquer avec le carte intelligent et sont bloquées. Par conséquent, ces connexions exclusives sont réduites. Le problème est qu’un protocole (tel que le protocole Kerberos) nécessite plusieurs opérations de signature. Par conséquent, le protocole nécessite un accès exclusif au carte intelligent sur une période prolongée, ou nécessite plusieurs opérations d’authentification. C’est là que le cache de code confidentiel est utilisé pour réduire l’utilisation exclusive du carte intelligent sans forcer l’utilisateur à entrer un code confidentiel plusieurs fois.

L’exemple suivant illustre comment cela fonctionne. Dans ce scénario, il existe deux applications : Outlook et Internet Explorer. Les applications utilisent des cartes à puce à des fins différentes.

1. L’utilisateur démarre Outlook et tente d’envoyer un e-mail signé. La clé privée se trouve sur le carte intelligent
2. Outlook invite l’utilisateur à entrer le code confidentiel carte intelligent. L’utilisateur entre le code confidentiel correct
3. Les données de courrier électronique sont envoyées au carte intelligent pour l’opération de signature. Le client Outlook met en forme la réponse et envoie le courrier électronique
4. L’utilisateur ouvre internet Explorer et tente d’accéder à un site protégé qui nécessite l’authentification TLS (Transport Layer Security) pour le client
5. Internet Explorer invite l’utilisateur à entrer le code confidentiel carte intelligent. L’utilisateur entre le code confidentiel correct
6. L’opération de clé privée liée à TLS se produit sur le carte intelligent, et l’utilisateur est authentifié et connecté
7. L’utilisateur retourne à Outlook pour envoyer un autre e-mail signé. Cette fois, l’utilisateur n’est pas invité à entrer un code confidentiel, car il est mis en cache à partir de l’opération précédente. De même, si l’utilisateur utilise à nouveau Internet Explorer pour une autre opération, Internet Explorer n’invite pas l’utilisateur à entrer un code confidentiel

Le fournisseur csp de base gère en interne un cache par processus du code confidentiel. Le code confidentiel est chiffré et stocké en mémoire. Les fonctions utilisées pour sécuriser le code confidentiel sont RtlEncryptMemory, RtlDecryptMemory et RtlSecureZeroMemory, qui vident les mémoires tampons contenant le code confidentiel.

Sélection carte intelligente

Les sections suivantes de cet article décrivent comment Windows utilise l’architecture smart carte pour sélectionner le logiciel, le fournisseur et les informations d’identification du lecteur smart carte appropriés pour une connexion intelligente carte réussie :

• Niveaux de spécification du conteneur
• Opérations de conteneur
• Indicateurs de contexte
• Créer un conteneur dans un contexte silencieux
• Comportement de sélection carte intelligente
• Faire correspondre un lecteur carte intelligent
• Faire correspondre une carte intelligente
• Ouvrir un conteneur par défaut existant (aucun lecteur spécifié)
• Ouvrir un conteneur nommé GUID existant (aucun lecteur spécifié)
• Créer un conteneur (aucun lecteur spécifié)
• Supprimer un conteneur

Niveaux de spécification du conteneur

En réponse à un appel CryptAcquireContext dans CryptoAPI, le fournisseur csp de base tente de faire correspondre le conteneur spécifié par l’appelant à un carte et un lecteur intelligents spécifiques. L’appelant peut fournir un nom de conteneur avec différents niveaux de spécificité, comme indiqué dans le tableau suivant, et trié des requêtes les plus spécifiques aux requêtes les moins spécifiques.

De même, en réponse à un appel NCryptOpenKey dans CNG, le KSP intelligent carte tente de faire correspondre le conteneur de la même façon et prend le même format de conteneur, comme indiqué dans le tableau suivant.

Remarque

Avant d’ouvrir une clé à l’aide du KSP carte intelligent, un appel à NCryptOpenStorageProvider (MS_SMART_CARD_KEY_STORAGE_PROVIDER) doit être effectué.

Type	Nom	Format
Je	Nom du lecteur et nom du conteneur	\.<Reader Name><Container Name>
II	Nom du lecteur et nom du conteneur (NULL)	\.<Reader Name>
III	Nom du conteneur uniquement	<Container Name>
IV	Conteneur par défaut (NULL) uniquement	NULL

Les carte intelligentes du fournisseur de solutions Cloud de base et du cache KSP smart carte gèrent des informations sur le processus d’appel et sur les cartes à puce auxquelles le processus a accédé. Lors de la recherche d’un conteneur de carte intelligent, le fournisseur de solutions cloud de base ou le fournisseur de services partagés carte intelligent vérifie d’abord le processus dans son cache. Si le handle mis en cache n’est pas valide ou si aucune correspondance n’est trouvée, l’API SCardUIDlg est appelée pour obtenir le handle carte.

Opérations de conteneur

Les trois opérations de conteneur suivantes peuvent être demandées à l’aide de CryptAcquireContext :

1. Créez un conteneur. (L’équivalent CNG de CryptAcquireContext avec dwFlags défini sur CRYPT_NEWKEYSET est NCryptCreatePersistedKey.)
2. Ouvrez un conteneur existant. (L’équivalent CNG de CryptAcquireContext pour ouvrir le conteneur est NCryptOpenKey.)
3. Supprimer un conteneur. (L’équivalent CNG de CryptAcquireContext avec dwFlags défini sur CRYPT_DELETEKEYSET est NCryptDeleteKey.)

Les heuristiques utilisées pour associer un handle de chiffrement à un carte intelligent et un lecteur spécifiques sont basées sur l’opération de conteneur demandée et le niveau de spécification de conteneur utilisé.

Le tableau suivant présente les restrictions pour l’opération de création de conteneur.

Spécification	Restriction
Aucun contexte silencieux	La création d’un conteneur de clé doit toujours être en mesure d’afficher l’interface utilisateur, telle que l’invite de code confidentiel.
Aucun remplacement des conteneurs existants	Si le conteneur spécifié existe déjà sur le carte intelligent choisi, choisissez un autre carte intelligent ou annulez l’opération.

Indicateurs de contexte

Le tableau suivant présente les indicateurs de contexte utilisés comme restrictions pour l’opération de création de conteneur.

Flag	Description
CRYPT_SILENT	Aucune interface utilisateur ne peut être affichée pendant cette opération.
CRYPT_MACHINE_KEYSET	Aucune donnée mise en cache ne doit être utilisée pendant cette opération.
CRYPT_VERIFYCONTEXT	Seules les données publiques sont accessibles sur le carte intelligent.

En plus des opérations de conteneur et des spécifications de conteneur, vous devez prendre en compte d’autres options utilisateur, telles que les indicateurs CryptAcquireContext, lors de la sélection carte intelligente.

Important

L’indicateur CRYPT_SILENT ne peut pas être utilisé pour créer un conteneur.

Créer un conteneur dans un contexte silencieux

Les applications peuvent appeler le fournisseur de solutions Cloud de base avec CRYPT_DEFAULT_CONTAINER_OPTIONAL, définir le code confidentiel dans le contexte silencieux, puis créer un conteneur dans le contexte silencieux. Cette opération se produit comme suit :

1. Appelez CryptAcquireContext en transmettant le nom du lecteur smart carte dans en tant que niveau de spécification de conteneur de type II et en spécifiant l’indicateur CRYPT_DEFAULT_CONTAINER_OPTIONAL
2. Appelez CryptSetProvParam en spécifiant PP_KEYEXCHANGE_PIN ou PP_SIGNATURE_PIN et un code PIN ASCII terminé par null.
3. Libérer le contexte acquis à l’étape 1
4. Appelez CryptAcquireContext avec CRYPT_NEWKEYSETet spécifiez le niveau de spécification de conteneur de type I
5. Appeler CryptGenKey pour créer la clé

Comportement de sélection carte intelligente

Dans certains des scénarios suivants, l’utilisateur peut être invité à insérer un carte intelligent. Si le contexte utilisateur est silencieux, cette opération échoue et aucune interface utilisateur n’est affichée. Sinon, en réponse à l’interface utilisateur, l’utilisateur peut insérer un carte intelligent ou sélectionner Annuler. Si l’utilisateur annule l’opération, l’opération échoue. L’organigramme montre les étapes de sélection effectuées par le système d’exploitation Windows.

En général, le comportement de sélection smart carte est géré par l’API SCardUIDlgSelectCard. Le fournisseur csp de base interagit avec cette API en l’appelant directement. Le fournisseur csp de base envoie également des fonctions de rappel qui ont pour but de filtrer et de mettre en correspondance les cartes à puce candidates. Les appelants de CryptAcquireContext fournissent des informations de correspondance intelligentes carte. En interne, le fournisseur de solutions cloud de base utilise une combinaison de numéros de série carte intelligents, de noms de lecteur et de conteneurs pour rechercher des cartes à puce spécifiques.

Chaque appel à SCardUI * peut entraîner la lecture d’informations supplémentaires à partir d’un carte intelligent candidat. Les rappels de sélection smart carte CSP de base mettez en cache ces informations.

Faire correspondre un lecteur carte intelligent

Pour les niveaux de spécification de conteneur de type I et de type II, le processus de sélection smart carte est moins complexe, car seule la carte intelligente dans le lecteur nommé peut être considérée comme une correspondance. Le processus de mise en correspondance d’un carte intelligent avec un lecteur carte intelligent est le suivant :

1. Recherchez le lecteur de carte intelligent demandé. S’il est introuvable, le processus échoue (cela nécessite une recherche dans le cache par nom de lecteur)
2. Si aucun carte intelligent n’est dans le lecteur, l’utilisateur est invité à insérer un carte intelligent. (ceci est uniquement en mode non-ilent ; si l’appel est effectué en mode silencieux, il échoue)
3. Pour le niveau de spécification de conteneur II uniquement, le nom du conteneur par défaut sur le carte intelligent choisi est déterminé.
4. Pour ouvrir un conteneur existant ou supprimer un conteneur existant, recherchez le conteneur spécifié. Si le conteneur spécifié est introuvable sur ce carte intelligent, l’utilisateur est invité à insérer un carte
5. Si le système tente de créer un conteneur, si le conteneur spécifié existe déjà sur ce carte intelligent, le processus échoue

Faire correspondre une carte intelligente

Pour les niveaux de spécification de conteneur III et IV, une méthode plus large est utilisée pour faire correspondre un carte intelligent approprié avec un contexte utilisateur, car plusieurs cartes à puce mises en cache peuvent répondre aux critères fournis.

Ouvrir un conteneur par défaut existant (aucun lecteur spécifié)

Remarque

Pour cette opération, vous devez utiliser le carte intelligent avec le fournisseur de solutions Cloud de base.

1. Pour chaque carte intelligente qui a été consultée par le fournisseur csp de base et les informations de handle et de conteneur sont mises en cache, le fournisseur csp de base recherche un conteneur par défaut valide. Une opération est tentée sur le SCARDHANDLE mis en cache pour vérifier sa validité. Si le handle de carte intelligent n’est pas valide, le fournisseur csp de base continue à rechercher un nouveau carte intelligent
2. Si aucune carte intelligente correspondante n’est trouvée dans le cache CSP de base, le fournisseur de solutions cloud de base appelle le sous-système smart carte. SCardUIDlgSelectCard() est utilisé avec un filtre de rappel approprié pour rechercher un carte intelligent correspondant avec un conteneur par défaut valide

Ouvrir un conteneur nommé GUID existant (aucun lecteur spécifié)

Remarque

Pour cette opération, vous devez utiliser le carte intelligent avec le fournisseur de solutions Cloud de base.

1. Pour chaque carte intelligente qui est déjà inscrite auprès du fournisseur csp de base, recherchez le conteneur demandé. Essayez une opération sur le SCARDHANDLE mis en cache pour vérifier sa validité. Si le handle de carte intelligent n’est pas valide, le numéro de série du carte intelligent est transmis à l’API pour poursuivre la SCardUI * recherche de ce carte intelligent spécifique (plutôt qu’une seule correspondance générale pour le nom du conteneur)
2. Si aucune carte intelligente correspondante n’est trouvée dans le cache CSP de base, un appel est effectué vers le sous-système smart carte. SCardUIDlgSelectCard()est utilisé avec un filtre de rappel approprié pour rechercher une carte intelligente correspondante avec le conteneur demandé. Ou, si un numéro de série intelligent carte résulte de la recherche à l’étape 1, le filtre de rappel tente de correspondre au numéro de série, et non au nom du conteneur

Créer un conteneur (aucun lecteur spécifié)

Remarque

Pour cette opération, vous devez utiliser le carte intelligent avec le fournisseur de solutions Cloud de base.

Si le code confidentiel n’est pas mis en cache, aucune CRYPT_SILENT n’est autorisée pour la création du conteneur, car l’utilisateur doit être invité à entrer un code confidentiel, au minimum.

Pour les autres opérations, l’appelant peut être en mesure d’acquérir un contexte de vérification par rapport au conteneur CRYPT_DEFAULT_CONTAINER_OPTIONAL par défaut, puis d’effectuer un appel avec CryptSetProvParam pour mettre en cache le code confidentiel de l’utilisateur pour les opérations suivantes.

1. Pour chaque carte intelligente déjà connue par le csp, actualisez le SCARDHANDLE stocké et effectuez les vérifications suivantes :
   1. Si le carte intelligent a été supprimé, poursuivez la recherche
   2. Si le carte intelligent est présent, mais qu’il a déjà le conteneur nommé, poursuivez la recherche
   3. Si le carte intelligent est disponible, mais qu’un appel à CardQueryFreeSpace indique que le carte intelligent n’a pas suffisamment de stockage pour un conteneur de clé supplémentaire, poursuivez la recherche
   4. Sinon, utilisez la première carte intelligente disponible qui répond aux critères ci-dessus pour la création du conteneur
2. Si aucune carte intelligente correspondante n’est trouvée dans le cache CSP, appelez le sous-système smart carte. Le rappel utilisé pour filtrer les cartes à puce énumérées vérifie qu’un carte intelligent candidat n’a pas déjà le conteneur nommé et que CardQueryFreeSpace indique que le carte intelligent dispose de suffisamment d’espace pour un conteneur supplémentaire. Si aucune carte intelligente appropriée n’est trouvée, l’utilisateur est invité à insérer un carte

Supprimer un conteneur

1. Si le nom du conteneur spécifié est NULL, le conteneur par défaut est supprimé. La suppression du conteneur par défaut entraîne la sélection arbitraire d’un nouveau conteneur par défaut. Pour cette raison, cette opération n’est pas recommandée
2. Pour chaque carte intelligente déjà connue par le csp, actualisez le SCARDHANDLE stocké et effectuez les vérifications suivantes :
   1. Si le carte intelligent n’a pas le conteneur nommé, poursuivez la recherche
   2. Si le carte intelligent a le conteneur nommé, mais que le handle de carte intelligent n’est plus valide, stockez le numéro de série du carte intelligent correspondant et passez-le à SCardUI
3. Si aucune carte intelligente correspondante n’est trouvée dans le cache CSP, appelez le sous-système smart carte. Le rappel utilisé pour filtrer les cartes à puce énumérées doit vérifier qu’un carte intelligent candidat possède le conteneur nommé. Si un numéro de série a été fourni à la suite de la recherche précédente dans le cache, le rappel doit filtrer les cartes à puce énumérées sur le numéro de série plutôt que sur les correspondances de conteneur. Si le contexte n’est pas silencieux et qu’aucun carte intelligent approprié n’est trouvé, affichez l’interface utilisateur qui invite l’utilisateur à insérer un carte

Architecture csp de base et KSP dans Windows

Le diagramme suivant montre l’architecture de chiffrement utilisée par le système d’exploitation Windows.

Csp de base et propriétés KSP carte intelligentes dans Windows

Remarque

Les définitions d’API se trouvent dans WinCrypt.h et WinSCard.h.

Propriété	Description
PP_USER_CERTSTORE	- Utilisé pour retourner un HCERTSTORE qui contient tous les certificats utilisateur sur le carte intelligent - En lecture seule (utilisé uniquement par CryptGetProvParam) - Appelant responsable de la fermeture du magasin de certificats - Certificat encodé à l’aide de PKCS_7_ASN_ENCODING ou X509_ASN_ENCODING - Csp doit être défini KEY_PROV_INFO sur les certificats - Le magasin de certificats doit être supposé être un magasin en mémoire - Les certificats doivent avoir un valide CRYPT_KEY_PROV_INFO en tant que propriété
PP_ROOT_CERTSTORE	- Lecture et écriture (utilisées par CryptGetProvParam et CryptSetProvParam) - Permet d’écrire une collection de certificats racines dans le carte intelligent ou de retourner HCERTSTORE, qui contient les certificats racines du carte - Utilisé principalement pour joindre un domaine à l’aide d’une carte intelligente - Appelant responsable de la fermeture du magasin de certificats
PP_SMARTCARD_READER	- En lecture seule (utilisé uniquement par CryptGetProvParam) - Retourne le nom du lecteur smart carte sous la forme d’une chaîne ANSI utilisée pour construire un nom de conteneur complet (autrement dit, un lecteur carte intelligent plus un conteneur)
PP_SMARTCARD_GUID	- Retourne le GUID de carte intelligent (également appelé numéro de série), qui doit être unique pour chaque carte - Utilisé par le service de propagation de certificats pour suivre la source d’un certificat racine
PP_UI_PROMPT	- Utilisé pour définir la chaîne de recherche de la SCardUIDlgSelectCard boîte de dialogue d’insertion carte - Persistant pour l’ensemble du processus lorsqu’il est défini - Écriture seule (utilisée uniquement par CryptSetProvParam)

Implications pour les fournisseurs de services cloud dans Windows

Les fournisseurs de services de chiffrement (CSP), y compris les fournisseurs de services cloud carte personnalisés, continuent d’être pris en charge, mais cette approche n’est pas recommandée. L’utilisation du fournisseur de services de configuration de base et du KSP carte intelligent avec le modèle de mini-tourneviseur smart carte pour les cartes à puce offre des avantages significatifs en termes de performances et de mise en cache des codes confidentiels et des données. Un mini-pilote peut être configuré pour fonctionner sous les couches CryptoAPI et CNG. Cela offre des avantages d’une prise en charge améliorée du chiffrement, notamment le chiffrement à courbe elliptique et AES.

Si un carte intelligent est inscrit par un fournisseur de solutions Cloud et un mini-carte intelligent, celui qui a été installé le plus récemment sera utilisé pour communiquer avec le carte intelligent.

Écrire un minidriver carte intelligent, csp ou KSP

Les fournisseurs de services cloud et les fournisseurs de services clés sont destinés à être écrits uniquement si des fonctionnalités spécifiques ne sont pas disponibles dans l’architecture de mini-pilote smart carte actuelle. Par exemple, l’architecture smart carte minidriver prend en charge les modules de sécurité matériels. Par conséquent, un mini-lecteur peut être écrit pour un module de sécurité matériel, et un fournisseur de solutions cloud ou KSP peut ne pas être nécessaire, sauf s’il est nécessaire de prendre en charge les algorithmes qui ne sont pas implémentés dans le fournisseur de solutions cloud de base ou le fournisseur de services de configuration carte de base.

Pour plus d’informations sur l’écriture d’un minidriver carte intelligent, csp ou KSP, consultez Minidrivers de carte à puce.