Smartcardarchitektur

In diesem Thema für IT-Experten wird die Systemarchitektur beschrieben, die Smartcards im Windows-Betriebssystem unterstützt, einschließlich der Architektur des Anmeldeinformationsanbieters und der Smartcard-Subsystemarchitektur.

Die Authentifizierung ist ein Prozess zum Überprüfen der Identität eines Objekts oder einer Person. Wenn Sie ein Objekt authentifizieren, z. B. eine Smartcard, besteht das Ziel darin, zu überprüfen, ob das Objekt original ist. Wenn Sie eine Person authentifizieren, besteht das Ziel darin, zu überprüfen, ob Sie es nicht mit einem Betrüger zu tun haben.

In einem Netzwerkkontext ist die Authentifizierung der Nachweis der Identität gegenüber einer Netzwerkanwendung oder -ressource. In der Regel wird die Identität durch einen kryptografischen Vorgang nachgewiesen, der einen Schlüssel verwendet, der nur dem Benutzer bekannt ist (z. B. mit Kryptografie mit öffentlichem Schlüssel) oder einen gemeinsam genutzten Schlüssel. Die Serverseite des Authentifizierungsaustauschs vergleicht die signierten Daten mit einem bekannten kryptografischen Schlüssel, um den Authentifizierungsversuch zu überprüfen. Das Speichern der kryptografischen Schlüssel an einem sicheren zentralen Ort macht den Authentifizierungsprozess skalierbar und verwaltbar.

Für Smartcards unterstützt Windows eine Anbieterarchitektur, die die Anforderungen an die sichere Authentifizierung erfüllt und erweiterbar ist, sodass Sie benutzerdefinierte Anmeldeinformationsanbieter einschließen können. Dieses Thema enthält Informationen zu folgenden Themen:

Architektur des Anmeldeinformationsanbieters

In der folgenden Tabelle sind die Komponenten aufgeführt, die in der interaktiven Anmeldearchitektur der Windows Server- und Windows-Betriebssysteme enthalten sind.

Komponente Beschreibung
Winlogon Stellt eine interaktive Anmeldeinfrastruktur bereit.
Anmeldeoberfläche Stellt interaktives Benutzeroberflächenrendering bereit.
Anmeldeinformationsanbieter (Kennwort und Smartcard) Beschreibt Anmeldeinformationen und Serialisierung von Anmeldeinformationen.
Lokale Sicherheitsautorität (LSA) Verarbeitet Anmeldeinformationen.
Authentifizierungspakete Enthält NTLM und das Kerberos-Protokoll. Kommuniziert mit Serverauthentifizierungspaketen, um Benutzer zu authentifizieren.

Die interaktive Anmeldung in Windows beginnt, wenn der Benutzer STRG+ALT+ENTF drückt. Die Tastenkombination STRG+ALT+ENTF wird als sichere Aufmerksamkeitssequenz (SAS) bezeichnet. Damit andere Programme und Prozesse sie nicht verwenden können, registriert Winlogon diese Sequenz während des Startvorgangs.

Nach dem Empfang der SAS generiert die Benutzeroberfläche dann die Anmeldekachel aus den Informationen, die von den registrierten Anmeldeinformationsanbietern empfangen werden. Die folgende Grafik zeigt die Architektur für Anmeldeinformationsanbieter im Windows-Betriebssystem.

Architektur des Anmeldeinformationsanbieters.

Abbildung 1Architektur des Anmeldeinformationsanbieters

In der Regel muss ein Benutzer, der sich mit einem lokalen Konto oder domänenkonto bei einem Computer anmeldet, einen Benutzernamen und ein Kennwort eingeben. Diese Anmeldeinformationen werden verwendet, um die Identität des Benutzers zu überprüfen. Für die Smartcardanmeldung sind die Anmeldeinformationen eines Benutzers auf dem Sicherheitschip der Smartcard enthalten. Ein Smartcardleser ermöglicht es dem Computer, mit dem Sicherheitschip auf der Smartcard zu interagieren. Wenn sich Benutzer mit einer Smartcard anmelden, geben sie eine persönliche Identifikationsnummer (PIN) anstelle eines Benutzernamens und kennworts ein.

Anmeldeinformationsanbieter sind prozessinterne COM-Objekte, die auf dem lokalen System ausgeführt werden und zum Sammeln von Anmeldeinformationen verwendet werden. Die Anmeldebenutzeroberfläche bietet interaktives Rendering der Benutzeroberfläche, Winlogon stellt eine interaktive Anmeldeinfrastruktur bereit, und Anmeldeinformationsanbieter arbeiten mit beiden Komponenten, um Anmeldeinformationen zu sammeln und zu verarbeiten.

Winlogon weist die Anmeldeoberfläche an, Kacheln des Anmeldeinformationsanbieters anzuzeigen, nachdem ein SAS-Ereignis empfangen wurde. Die Anmeldeoberfläche fragt jeden Anmeldeinformationsanbieter nach der Anzahl der Anmeldeinformationen ab, die er aufzählen möchte. Anmeldeinformationsanbieter haben die Möglichkeit, eine dieser Kacheln als Standard anzugeben. Nachdem alle Anbieter ihre Kacheln aufgelistet haben, werden sie dem Benutzer auf der Anmeldeoberfläche angezeigt. Der Benutzer interagiert mit einer Kachel, um die richtigen Anmeldeinformationen anzugeben. Die Anmeldeoberfläche übermittelt diese Anmeldeinformationen für die Authentifizierung.

In Kombination mit unterstützender Hardware können Anmeldeinformationsanbieter das Windows-Betriebssystem erweitern, um Benutzern die Anmeldung mithilfe von Biometrie (z. B. Fingerabdruck, Netzhaut- oder Spracherkennung), Kennwort, PIN, Smartcardzertifikat oder einem beliebigen benutzerdefinierten Authentifizierungspaket zu ermöglichen. Unternehmen und IT-Experten können benutzerdefinierte Authentifizierungsmechanismen für alle Domänenbenutzer entwickeln und bereitstellen, und sie können explizit verlangen, dass Benutzer diesen benutzerdefinierten Anmeldemechanismus verwenden.

Hinweis Anmeldeinformationsanbieter sind keine Erzwingungsmechanismen. Sie werden verwendet, um Anmeldeinformationen zu sammeln und zu serialisieren. Die LSA- und Authentifizierungspakete erzwingen Sicherheit.

Anmeldeinformationsanbieter können so konzipiert werden, dass sie einmaliges Anmelden (Single Sign-In, SSO) unterstützen. In diesem Prozess authentifizieren sie Benutzer bei einem sicheren Netzwerkzugriffspunkt (mithilfe von RADIUS und anderen Technologien), um sich beim Computer anzumelden. Anmeldeinformationsanbieter sind auch für die Unterstützung anwendungsspezifischer Anmeldeinformationen konzipiert und können für die Authentifizierung bei Netzwerkressourcen, den Beitritt von Computern zu einer Domäne oder für die Bereitstellung der Administratorzustimmung für die Benutzerkontensteuerung (UAC) verwendet werden.

Auf einem Computer können mehrere Anmeldeinformationsanbieter gleichzeitig vorhanden sein.

Anmeldeinformationsanbieter müssen auf einem Computer unter Windows registriert sein und sind für Folgendes verantwortlich:

  • Beschreiben der Anmeldeinformationen, die für die Authentifizierung erforderlich sind.

  • Verarbeiten von Kommunikation und Logik mit externen Authentifizierungsautoritäten.

  • Packen von Anmeldeinformationen für die interaktive Anmeldung und die Netzwerkanmeldung.

Hinweis Die Anmeldeinformationsanbieter-API rendert die Benutzeroberfläche nicht. Es beschreibt, was gerendert werden muss.
Nur der Kennwortanmeldeinformationsanbieter ist im abgesicherten Modus verfügbar.
Der Smartcard-Anmeldeinformationsanbieter ist während des Netzwerks im abgesicherten Modus verfügbar.

Architektur des Smartcard-Subsystems

Anbieter bieten Smartcards und Smartcardleser an, und in vielen Fällen unterscheiden sich die Anbieter für die Smartcard und den Smartcardleser. Treiber für Smartcardleser werden auf den Pc/Smartcard-Standard (PC/SC) geschrieben. Jede Smartcard muss über einen Kryptografiedienstanbieter (Cryptographic Service Provider, CSP) verfügen, der die CryptoAPI-Schnittstellen verwendet, um kryptografische Vorgänge zu ermöglichen, und die WinSCard-APIs, um die Kommunikation mit Smartcardhardware zu ermöglichen.

Basis-CSP- und Smartcard-Minitreiberarchitektur

Abbildung 2 veranschaulicht die Beziehung zwischen CryptoAPI, CSPs, smartcard Base Cryptographic Service Provider (Base CSP) und Smartcard-Minitreibern.

Basis-CSP- und Smartcard-Minitreiberarchitektur.

Abbildung 2Basis-CSP- und Smartcard-Minitreiberarchitektur

Zwischenspeichern mit Basis-CSP und Smartcard-KSP

Die Smartcardarchitektur verwendet Zwischenspeicherungsmechanismen, um vorgänge zu optimieren und den Zugriff eines Benutzers auf eine PIN zu verbessern.

  • Datenzwischenspeicherung: Der Datencache bietet einen einzelnen Prozess, um Smartcard-E/A-Vorgänge zu minimieren.

  • PIN-Zwischenspeicherung: Der PIN-Cache hilft dem Benutzer, bei jeder nicht authentifizierten Smartcard erneut eine PIN eingeben zu müssen.

Datenzwischenspeicherung

Jeder CSP implementiert den aktuellen Smartcard-Datencache separat. Der Basis-CSP implementiert einen robusten Zwischenspeicherungsmechanismus, der es einem einzelnen Prozess ermöglicht, Smartcard-E/A-Vorgänge zu minimieren.

Der vorhandene globale Cache funktioniert wie folgt:

  1. Die Anwendung fordert einen kryptografischen Vorgang an. Beispielsweise soll ein Benutzerzertifikat von der Smartcard gelesen werden.

  2. Der CSP überprüft seinen Cache auf das Element.

  3. Wenn das Element nicht im Cache gefunden wird oder das Element zwischengespeichert, aber nicht aktuell ist, wird das Element von der Smartcard gelesen.

  4. Nachdem ein Element aus der Smartcard gelesen wurde, wird es dem Cache hinzugefügt. Jede vorhandene veraltete Kopie dieses Elements wird ersetzt.

Drei Arten von Objekten oder Daten werden vom CSP zwischengespeichert: Pins (weitere Informationen finden Sie unter PIN-Zwischenspeicherung), Zertifikate und Dateien. Wenn sich zwischengespeicherte Daten ändern, wird das entsprechende Objekt in aufeinander folgenden Vorgängen aus der Smartcard gelesen. Wenn beispielsweise eine Datei in die Smartcard geschrieben wird, wird der CSP-Cache für die Dateien veraltet, und andere Prozesse lesen die Smartcard mindestens einmal, um ihren CSP-Cache zu aktualisieren.

Der globale Datencache wird im Dienst Smartcards für Windows gehostet. Windows enthält zwei öffentliche Smartcard-API-Aufrufe: SCardWriteCache und SCardReadCache. Diese API-Aufrufe machen globale Datenzwischenspeicherungsfunktionen für Anwendungen verfügbar. Jede Smartcard, die der Smartcard-Minidriver-Spezifikation entspricht, verfügt über einen 16-Byte-Kartenbezeichner. Dieser Wert wird verwendet, um zwischengespeicherte Daten, die sich auf eine bestimmte Smartcard beziehen, eindeutig zu identifizieren. Der Standardmäßige Windows-GUID-Typ wird verwendet. Diese APIs ermöglichen es einer Anwendung, Daten zum globalen Cache hinzuzufügen und aus ihnen zu lesen.

PIN-Zwischenspeicherung

Der PIN-Cache schützt den Benutzer vor der Eingabe einer PIN, wenn die Smartcard nicht authentifiziert ist. Nachdem eine Smartcard authentifiziert wurde, unterscheidet sie sich nicht zwischen hostseitigen Anwendungen. Jede Anwendung kann auf private Daten auf der Smartcard zugreifen.

Um dies zu vermeiden, wechselt die Smartcard in einen exklusiven Zustand, wenn sich eine Anwendung bei der Smartcard authentifiziert. Dies bedeutet jedoch, dass andere Anwendungen nicht mit der Smartcard kommunizieren können und blockiert werden. Daher werden solche exklusiven Verbindungen minimiert. Das Problem besteht darin, dass ein Protokoll (z. B. das Kerberos-Protokoll) mehrere Signaturvorgänge erfordert. Daher erfordert das Protokoll exklusiven Zugriff auf die Smartcard über einen längeren Zeitraum oder mehrere Authentifizierungsvorgänge. Hier wird der PIN-Cache verwendet, um die exklusive Verwendung der Smartcard zu minimieren, ohne den Benutzer zur mehrfachen Eingabe einer PIN zu zwingen.

Das folgende Beispiel veranschaulicht, wie dies funktioniert. In diesem Szenario gibt es zwei Anwendungen: Outlook und Internet Explorer. Die Anwendungen verwenden Smartcards für verschiedene Zwecke.

  1. Der Benutzer startet Outlook und versucht, eine signierte E-Mail zu senden. Der private Schlüssel befindet sich auf der Smartcard.

  2. Outlook fordert den Benutzer zur Eingabe der Smartcard-PIN auf. Der Benutzer gibt die richtige PIN ein.

  3. E-Mail-Daten werden für den Signaturvorgang an die Smartcard gesendet. Der Outlook-Client formatiert die Antwort und sendet die E-Mail.

  4. Der Benutzer öffnet Internet Explorer und versucht, auf einen geschützten Standort zuzugreifen, der tls-Authentifizierung (Transport Layer Security) für den Client erfordert.

  5. Internet Explorer fordert den Benutzer zur Eingabe der Smartcard-PIN auf. Der Benutzer gibt die richtige PIN ein.

  6. Der TLS-bezogene Private Key-Vorgang erfolgt auf der Smartcard, und der Benutzer wird authentifiziert und angemeldet.

  7. Der Benutzer kehrt zu Outlook zurück, um eine weitere signierte E-Mail zu senden. Dieses Mal wird der Benutzer nicht zur Eingabe einer PIN aufgefordert, da die PIN aus dem vorherigen Vorgang zwischengespeichert wird. Wenn der Benutzer Internet Explorer erneut für einen anderen Vorgang verwendet, fordert Internet Explorer den Benutzer nicht zur Eingabe einer PIN auf.

Der Basis-CSP verwaltet intern einen Prozesscache der PIN. Die PIN wird verschlüsselt und im Arbeitsspeicher gespeichert. Die Zum Sichern der PIN verwendeten Funktionen sind RtlEncryptMemory, RtlDecryptMemory und RtlSecureZeroMemory, die Puffer leeren, die die PIN enthalten.

Smartcardauswahl

In den folgenden Abschnitten dieses Themas wird beschrieben, wie Windows die Smartcardarchitektur nutzt, um die richtige Smartcardlesesoftware, den richtigen Anbieter und die richtigen Anmeldeinformationen für eine erfolgreiche Smartcardanmeldung auszuwählen:

Containerspezifikationsebenen

Als Reaktion auf einen CryptAcquireContext-Aufruf in CryptoAPI versucht der Basis-CSP, den Vom Aufrufer angegebenen Container mit einer bestimmten Smartcard und einem bestimmten Leser abzugleichen. Der Aufrufer kann einen Containernamen mit unterschiedlichen Spezifitätsebenen bereitstellen, wie in der folgenden Tabelle dargestellt, und von den meisten spezifischen bis zu den am wenigsten spezifischen Anforderungen sortiert werden.

Entsprechend versucht der Smartcard-KSP als Reaktion auf einen NCryptOpenKey-Aufruf in CNG, den Container auf die gleiche Weise abzugleichen, und verwendet das gleiche Containerformat, wie in der folgenden Tabelle gezeigt.

Hinweis Vor dem Öffnen eines Schlüssels mithilfe des Smartcard-KSP muss ein Aufruf von NCryptOpenStorageProvider (MS_SMART_CARD_KEY_STORAGE_PROVIDER) erfolgen.

Typ Name Format
Ich Lesername und Containername \\.\<Lesername>\<Containername>
II Lesername und Containername (NULL) \\.\<Lesername>
III Nur Containername <Containername>
IV Nur Standardcontainer (NULL) NULL

Die Basis-CSP- und Smartcard-KSP-Cache-Smartcard verarbeiten Informationen über den Anrufvorgang und die Smartcards, auf die der Prozess zugegriffen hat. Bei der Suche nach einem Smartcardcontainer überprüft der Basis-CSP oder Smartcard-KSP zuerst seinen Cache für den Prozess. Wenn das zwischengespeicherte Handle ungültig ist oder keine Übereinstimmung gefunden wird, wird die SCardUIDlg-API aufgerufen, um das Kartenhandle abzurufen.

Containervorgänge

Die folgenden drei Containervorgänge können mithilfe von CryptAcquireContext angefordert werden:

  1. Erstellen Sie einen neuen Container. (Die CNG-Entsprechung von CryptAcquireContext mit dwFlags ist auf CRYPT_NEWKEYSET ist NCryptCreatePersistedKey.)

  2. Öffnen Sie einen vorhandenen Container. (Das CNG-Äquivalent von CryptAcquireContext zum Öffnen des Containers ist NCryptOpenKey.)

  3. Löschen sie einen Container. (Die CNG-Entsprechung von CryptAcquireContext mit dwFlags ist auf CRYPT_DELETEKEYSET ist NCryptDeleteKey.)

Die Heuristiken, die zum Zuordnen eines kryptografischen Handles zu einer bestimmten Smartcard und einem bestimmten Leser verwendet werden, basieren auf dem angeforderten Containervorgang und der verwendeten Containerspezifikationsebene.

In der folgenden Tabelle sind die Einschränkungen für den Containererstellungsvorgang aufgeführt.

Spezifikation Einschränkung
Kein hintergrundbezogener Kontext Die Erstellung eines Schlüsselcontainers muss immer die Benutzeroberfläche anzeigen können, z. B. die PIN-Eingabeaufforderung.
Kein Überschreiben vorhandener Container Wenn der angegebene Container bereits auf der ausgewählten Smartcard vorhanden ist, wählen Sie eine andere Smartcard aus, oder brechen Sie den Vorgang ab.

Kontextflags

Die folgende Tabelle zeigt die Kontextflags, die als Einschränkungen für den Containererstellungsvorgang verwendet werden.

Flag Beschreibung
CRYPT_SILENT Während dieses Vorgangs kann keine Benutzeroberfläche angezeigt werden.
CRYPT_MACHINE_KEYSET Während dieses Vorgangs sollten keine zwischengespeicherten Daten verwendet werden.
CRYPT_VERIFYCONTEXT Auf der Smartcard kann nur auf öffentliche Daten zugegriffen werden.

Neben Containervorgängen und Containerspezifikationen müssen Sie bei der Smartcardauswahl auch andere Benutzeroptionen berücksichtigen, z. B. die CryptAcquireContext-Flags.

Wichtig Das CRYPT_SILENT-Flag kann nicht zum Erstellen eines neuen Containers verwendet werden.

Erstellen eines neuen Containers im automatischen Kontext

Anwendungen können den Basis-CSP mit CRYPT_DEFAULT_CONTAINER_OPTIONAL aufrufen, die PIN im automatischen Kontext festlegen und dann einen neuen Container im hintergrundbasierten Kontext erstellen. Dieser Vorgang erfolgt wie folgt:

  1. Rufen Sie CryptAcquireContext auf, indem Sie den Namen des Smartcardlesers als Typ II-Containerspezifikationsstufe übergeben und das CRYPT_DEFAULT_CONTAINER_OPTIONAL-Flag angeben.

  2. Rufen Sie CryptSetProvParam auf, indem Sie PP_KEYEXCHANGE_PIN oder PP_SIGNATURE_PIN und eine MIT NULL endende ASCII-PIN angeben.

  3. Geben Sie den in Schritt 1 abgerufenen Kontext frei.

  4. Rufen Sie CryptAcquireContext mit CRYPT_NEWKEYSET auf, und geben Sie die Containerspezifikationsebene typ I an.

  5. Rufen Sie CryptGenKey auf, um den Schlüssel zu erstellen.

Smartcardauswahlverhalten

In einigen der folgenden Szenarien kann der Benutzer aufgefordert werden, eine Smartcard einzufügen. Wenn der Benutzerkontext im Hintergrund ist, schlägt dieser Vorgang fehl, und es wird keine Benutzeroberfläche angezeigt. Andernfalls kann der Benutzer als Reaktion auf die Benutzeroberfläche eine Smartcard einfügen oder auf Abbrechen klicken. Wenn der Benutzer den Vorgang abbricht, schlägt der Vorgang fehl. Das Flussdiagramm in Abbildung 3 zeigt die Auswahlschritte, die vom Windows-Betriebssystem ausgeführt werden.

Smartcardauswahlprozess.

Abbildung 3Verhalten der Smartcardauswahl

Im Allgemeinen wird das Smartcardauswahlverhalten von der SCardUIDlgSelectCard-API behandelt. Der Basis-CSP interagiert mit dieser API, indem er sie direkt aufruft. Der Basis-CSP sendet auch Rückruffunktionen, die zum Filtern und Abgleichen von Kandidaten-Smartcards dienen. Anrufer von CryptAcquireContext stellen Smartcard-Abgleichsinformationen bereit. Intern verwendet der Basis-CSP eine Kombination aus Smartcard-Seriennummern, Lesernamen und Containernamen, um bestimmte Smartcards zu finden.

Jeder Aufruf von SCardUI * kann zu zusätzlichen Informationen führen, die von einer Kandidaten-Smartcard gelesen werden. Diese Informationen werden im Basis-CSP-Smartcardauswahlrückruf zwischengespeichert.

Erstellen einer Übereinstimmung mit einem Smartcardleser

Bei Den Spezifikationsebenen von Containern vom Typ I und Typ II ist der Smartcardauswahlprozess weniger komplex, da nur die Smartcard im benannten Reader als Übereinstimmung betrachtet werden kann. Der Prozess zum Abgleichen einer Smartcard mit einem Smartcardleser ist:

  1. Suchen Sie den angeforderten Smartcardleser. Wenn er nicht gefunden werden kann, schlägt der Prozess fehl. (Dies erfordert eine Cachesuche anhand des Lesernamens.)

  2. Wenn sich keine Smartcard im Reader befindet, wird der Benutzer aufgefordert, eine Smartcard einzufügen. (Dies ist nur im nicht automatischen Modus. Wenn der Aufruf im unbeaufsichtigten Modus erfolgt, schlägt er fehl.)

  3. Nur für Containerspezifikationsebene II wird der Name des Standardcontainers auf der ausgewählten Smartcard bestimmt.

  4. Suchen Sie nach dem angegebenen Container, um einen vorhandenen Container zu öffnen oder einen vorhandenen Container zu löschen. Wenn der angegebene Container auf dieser Smartcard nicht gefunden werden kann, wird der Benutzer aufgefordert, eine Smartcard einzulegen.

  5. Wenn das System versucht, einen neuen Container zu erstellen und der angegebene Container bereits auf dieser Smartcard vorhanden ist, schlägt der Prozess fehl.

Erstellen einer Smartcard-Übereinstimmung

Für die Containerspezifikationsstufen III und IV wird eine umfassendere Methode verwendet, um eine geeignete Smartcard mit einem Benutzerkontext abzugleichen, da mehrere zwischengespeicherte Smartcards die angegebenen Kriterien erfüllen können.

Öffnen eines vorhandenen Standardcontainers (kein Reader angegeben)

Hinweis Für diesen Vorgang müssen Sie die Smartcard mit dem Basis-CSP verwenden.

  1. Für jede Smartcard, auf die vom Basis-CSP zugegriffen wurde, und die Handle- und Containerinformationen werden zwischengespeichert, sucht der Basis-CSP nach einem gültigen Standardcontainer. Es wird versucht, einen Vorgang für die zwischengespeicherte SCARDHANDLE-Instanz durchzuführen, um deren Gültigkeit zu überprüfen. Wenn das Smartcardhandle ungültig ist, sucht der Basis-CSP weiterhin nach einer neuen Smartcard.

  2. Wenn im Basis-CSP-Cache keine übereinstimmende Smartcard gefunden wird, ruft der Basis-CSP das Smartcardsubsystem auf. SCardUIDlgSelectCard() wird mit einem geeigneten Rückruffilter verwendet, um eine passende Smartcard mit einem gültigen Standardcontainer zu finden.

Öffnen eines vorhandenen GUID-benannten Containers (kein Reader angegeben)

Hinweis Für diesen Vorgang müssen Sie die Smartcard mit dem Basis-CSP verwenden.

  1. Suchen Sie für jede Smartcard, die bereits beim Basis-CSP registriert ist, nach dem angeforderten Container. Versuchen Sie einen Vorgang für die zwischengespeicherte SCARDHANDLE, um deren Gültigkeit zu überprüfen. Wenn das Smartcardhandle ungültig ist, wird die Seriennummer der Smartcard an die SCardUI *-API übergeben, um die Suche nach dieser bestimmten Smartcard fortzusetzen (und nicht nur eine allgemeine Übereinstimmung mit dem Containernamen).

  2. Wenn im Basis-CSP-Cache keine übereinstimmende Smartcard gefunden wird, wird das Smartcardsubsystem aufgerufen. SCardUIDlgSelectCard() wird mit einem geeigneten Rückruffilter verwendet, um eine passende Smartcard mit dem angeforderten Container zu finden. Wenn bei der Suche in Schritt 1 eine Smartcardseriennummer entstanden ist, versucht der Rückruffilter, die Seriennummer und nicht den Containernamen abzugleichen.

Erstellen eines neuen Containers (kein Reader angegeben)

Hinweis Für diesen Vorgang müssen Sie die Smartcard mit dem Basis-CSP verwenden.

Wenn die PIN nicht zwischengespeichert wird, ist für die Containererstellung kein CRYPT_SILENT zulässig, da der Benutzer mindestens zur Eingabe einer PIN aufgefordert werden muss.

Bei anderen Vorgängen kann der Aufrufer möglicherweise einen Überprüfungskontext für den Standardcontainer (CRYPT_DEFAULT_CONTAINER_OPTIONAL) abrufen und dann einen Aufruf mit CryptSetProvParam durchführen, um die Benutzer-PIN für nachfolgende Vorgänge zwischenzuspeichern.

  1. Aktualisieren Sie für jede Smartcard, die dem CSP bereits bekannt ist, die gespeicherte SCARDHANDLE, und führen Sie die folgenden Überprüfungen durch:

    1. Wenn die Smartcard entfernt wurde, setzen Sie die Suche fort.

    2. Wenn die Smartcard vorhanden ist, aber bereits über den benannten Container verfügt, setzen Sie die Suche fort.

    3. Wenn die Smartcard verfügbar ist, aber ein Aufruf von CardQueryFreeSpace angibt, dass die Smartcard nicht über genügend Speicherplatz für einen zusätzlichen Schlüsselcontainer verfügt, fahren Sie mit der Suche fort.

    4. Verwenden Sie andernfalls die erste verfügbare Smartcard, die die oben genannten Kriterien für die Containererstellung erfüllt.

  2. Wenn im CSP-Cache keine übereinstimmende Smartcard gefunden wird, rufen Sie das Smartcardsubsystem auf. Der Rückruf, der zum Filtern aufgezählter Smartcards verwendet wird, überprüft, ob eine potenzielle Smartcard nicht bereits über den benannten Container verfügt, und dass CardQueryFreeSpace angibt, dass die Smartcard über ausreichend Speicherplatz für einen zusätzlichen Container verfügt. Wenn keine geeignete Smartcard gefunden wird, wird der Benutzer aufgefordert, eine Smartcard einzulegen.

Löschen eines Containers

  1. Wenn der angegebene Containername NULL ist, wird der Standardcontainer gelöscht. Das Löschen des Standardcontainers führt dazu, dass ein neuer Standardcontainer willkürlich ausgewählt wird. Aus diesem Grund wird dieser Vorgang nicht empfohlen.

  2. Aktualisieren Sie für jede Smartcard, die dem CSP bereits bekannt ist, die gespeicherte SCARDHANDLE, und führen Sie die folgenden Überprüfungen durch:

    1. Wenn die Smartcard nicht über den benannten Container verfügt, fahren Sie mit der Suche fort.

    2. Wenn die Smartcard über den benannten Container verfügt, das Smartcardhandle aber nicht mehr gültig ist, speichern Sie die Seriennummer der passenden Smartcard, und übergeben Sie sie an SCardUI *.

  3. Wenn im CSP-Cache keine übereinstimmende Smartcard gefunden wird, rufen Sie das Smartcardsubsystem auf. Der Rückruf, der zum Filtern aufgezählter Smartcards verwendet wird, sollte überprüfen, ob eine potenzielle Smartcard über den benannten Container verfügt. Wenn als Ergebnis der vorherigen Cachesuche eine Seriennummer angegeben wurde, sollte der Rückruf aufgezählte Smartcards nach Seriennummer und nicht nach Containervergleichen filtern. Wenn der Kontext nicht lautlos ist und keine geeignete Smartcard gefunden wird, zeigen Sie die Benutzeroberfläche an, die den Benutzer auffordert, eine Smartcard einzufügen.

Basis-CSP- und KSP-basierte Architektur in Windows

Abbildung 4 zeigt die Kryptografiearchitektur, die vom Windows-Betriebssystem verwendet wird.

Kryptografiearchitektur.

Abbildung 4Kryptografiearchitektur

Basis-CSP- und Smartcard-KSP-Eigenschaften in Windows

Die folgenden Eigenschaften werden in Windows-Versionen unterstützt, die in der Liste Gilt für am Anfang dieses Themas angegeben sind.

Hinweis Die API-Definitionen befinden sich in WinCrypt.h und WinSCard.h.

Eigenschaft Beschreibung
PP_USER_CERTSTORE – Wird verwendet, um einen HCERTSTORE zurückzugeben, der alle Benutzerzertifikate auf der Smartcard enthält.
– Schreibgeschützt (wird nur von CryptGetProvParam verwendet)
– Aufrufer, der für das Schließen des Zertifikatspeichers verantwortlich ist
– Mit PKCS_7_ASN_ENCODING oder X509_ASN_ENCODING codiertes Zertifikat
- CSP sollte KEY_PROV_INFO für Zertifikate festlegen
– Es sollte davon ausgegangen werden, dass es sich um einen In-Memory-Speicher handelt.
– Zertifikate sollten eine gültige CRYPT_KEY_PROV_INFO als Eigenschaft aufweisen.
PP_ROOT_CERTSTORE – Lesen und Schreiben (verwendet von CryptGetProvParam und CryptSetProvParam)
– Wird verwendet, um eine Sammlung von Stammzertifikaten auf die Smartcard zu schreiben oder HCERTSTORE zurückzugeben, der Stammzertifikate von der Smartcard enthält.
– Wird hauptsächlich für den Beitritt zu einer Domäne mithilfe einer Smartcard verwendet.
– Aufrufer, der für das Schließen des Zertifikatspeichers verantwortlich ist
PP_SMARTCARD_READER – Schreibgeschützt (wird nur von CryptGetProvParam verwendet)
– Gibt den Namen des Smartcardlesers als ANSI-Zeichenfolge zurück, die zum Erstellen eines vollqualifizierten Containernamens (d. a. eines Smartcardlesers und eines Containers) verwendet wird.
PP_SMARTCARD_GUID – Rückgabe der Smartcard-GUID (auch als Seriennummer bezeichnet), die für jede Smartcard eindeutig sein sollte
– Wird vom Zertifikatverteilungsdienst verwendet, um die Quelle eines Stammzertifikats nachzuverfolgen.
PP_UI_PROMPT – Wird verwendet, um die Suchzeichenfolge für das Dialogfeld zum Einfügen von SCardUIDlgSelectCard-Karten festzulegen.
– Persistent für den gesamten Prozess, wenn er festgelegt ist
– Schreibgeschützt (wird nur von CryptSetProvParam verwendet)

Auswirkungen auf CSPs in Windows

Kryptografiedienstanbieter (Cryptographic Service Providers, CSPs), einschließlich benutzerdefinierter Smartcard-CSPs, werden weiterhin unterstützt, aber dieser Ansatz wird nicht empfohlen. Die Verwendung des vorhandenen Basis-CSP und Smartcard-KSP mit dem Smartcard-Minidriver-Modell für Smartcards bietet erhebliche Vorteile in Bezug auf die Leistung sowie die PIN- und Datenzwischenspeicherung. Ein Minitreiber kann so konfiguriert werden, dass er unter CryptoAPI- und CNG-Ebenen funktioniert. Dies bietet Vorteile einer verbesserten kryptografischen Unterstützung, einschließlich Kryptografie mit elliptischer Kurve und AES.

Wenn eine Smartcard von einem CSP und einem Smartcard-Minidriver registriert wird, wird die zuletzt installierte smartcard für die Kommunikation mit der Smartcard verwendet.

Schreiben eines Smartcard-Minidrivers, CSP oder KSP

CSPs und KSPs sollen nur geschrieben werden, wenn in der aktuellen Smartcard-Minitreiberarchitektur keine spezifischen Funktionen verfügbar sind. Beispielsweise unterstützt die Smartcard-Minitreiberarchitektur Hardwaresicherheitsmodule, sodass ein Minitreiber für ein Hardwaresicherheitsmodul geschrieben werden kann, und ein CSP oder KSP ist möglicherweise nicht erforderlich, es sei denn, er ist erforderlich, um Algorithmen zu unterstützen, die nicht im Basis-CSP oder Smartcard-KSP implementiert sind.

Weitere Informationen zum Schreiben eines Smartcard-Minitreibers, eines CSP oder eines KSP finden Sie unter Smartcard-Minidriver.