Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
In diesem Thema werden allgemeine Richtlinien für Entwickler erläutert, die mit intelligenten Karte Minitreibern arbeiten und/oder entwickeln, um Sie über das erwartete Verhalten der intelligenten Karte und der zugehörigen Anwendungen zu informieren.
Allgemeine Entwurfsrichtlinien
Informationen zum Verteilen von Karte Minidrivern, zum Zuordnen logischer Karte Dateisysteme und anderer Designrichtlinien für Minitreiber finden Sie im Abschnitt Allgemeine Entwurfsrichtlinien unter Übersicht über Smartcard-Minitreiber.
Challenge/Response-Methode zum Aufheben der Blockierung der Smartcard-PIN
Damit ein Administrator diesen Mechanismus erfolgreich zum Aufheben der Blockierung der Karte eines Benutzers verwenden kann, müssen Administratoren in der Lage sein, den auf dem Karte gespeicherten Administratorschlüssel zu identifizieren und zu verwenden, damit sie die Antwortdaten für die ausgegebene Herausforderung ordnungsgemäß generieren können.
Eine Möglichkeit besteht darin, den Karte-Bezeichner zu verwenden, um die Karte eindeutig zu identifizieren. (Der Karte-Bezeichner ist ein eindeutiger Bezeichner für eine Karte.) Dies kann benutzern in der Benutzeroberfläche in irgendeiner Form dargestellt werden, aber andernfalls könnte ein Programm geschrieben werden, um geeignete APDU-Befehle an die Karte zu senden, um diese Informationen zu lesen.
Diese Informationen können es dem Administrator dann ermöglichen, den geheimen Schlüssel auf der Karte zu identifizieren und die entsprechende Antwort auf die Anforderungsdaten zu berechnen, die an Benutzer ausgegeben werden.
Es wird davon ausgegangen, dass der auf einem Karte gespeicherte geheime Administratorschlüssel mithilfe eines sicheren Mechanismus gespeichert wird, auf den nur gültige und vertrauenswürdige Administratoren zugreifen können (vorzugsweise so wenige wie möglich). Dies geht jedoch über den Rahmen dieser Spezifikation hinaus.
Weitere Informationen finden Sie im abschnitt "Challenge/Response Mechanism".
Erweiterte PIN-Unterstützung
Version 6.0 unterstützte eine flexible Architektur für die Unterstützung mehrerer PINs. Mit dieser Architektur wurde ein neues Rollenkonzept eingeführt, bei dem jede Rolle einem PIN-Bezeichner entspricht. Die PIN-IDs werden verwendet, um PIN-Informationen aus dem Karte zu extrahieren und einem Schlüsselcontainer eine PIN zuzuordnen.
Der Bezeichner besteht aus einer Zahl, die derzeit auf 0 bis7 beschränkt ist. Außerdem wurde das Konzept einer PIN_SET eingeführt, bei der es sich um eine Bitmaske handelt, die aus dem PIN-Bezeichner generiert werden kann. Derzeit werden nur die unteren 8 Bits für den PIN-Satz verwendet. Wir können auch die verbleibenden Bits verwenden, um Bedingungen wie "and", "or" oder andere Informationen anzugeben, die in Zukunft nützlich sein könnten. Wir haben diesen Ansatz gewählt, damit die Bitmaske für die Karte einfach zu erzwingen ist.
Angenommen, der Benutzer authentifiziert sich mit Rolle 3, die pin 3 entspricht. Dies bedeutet die Bitmaske 0000 0100 (Basis 2). Der Karte kann dies als aktuell authentifizierte ID aufzeichnen und die Zugriffsregeln für Schlüssel und PINs einfach überprüfen, indem er einen bitweisen AND-Vorgang ausführt. Der Entwurf ermöglicht die gleichzeitige Verwendung mehrerer authentifizierter Identitäten auf dem Karte. Dies ist eine Voraussetzung für Karten, die v6 Karte Minidriver unterstützen. Wenn z. B. PIN #1 authentifiziert und anschließend PIN #2 authentifiziert wird, sollten Vorgänge zulässig sein, die von diesen PINs gesteuert werden.
Sitzungs-PINs und sicherer PIN-Kanal
Wenn Windows einen sicheren PIN-Kanal für die PIN-Authentifizierung einrichten muss, wird die folgende Abfolge von Vorgängen mit dem Minitreiber ausgeführt. Um dies zu erfüllen, müssen ein Minitreiber und der Karte mit der folgenden Sequenz kompatibel sein. Insbesondere Sitzungs-PINs sollten zwischen Prozessen übertragbar sein und nur für eine bestimmte Zeit dauern. (Es wird empfohlen, dass jede Sitzungs-PIN gültig ist, bis die Karte kalt zurückgesetzt wird, indem das flag CARD_AUTHENTICATE_ SESSION_PIN verwendet wird, auch wenn CardAuthenticateEx mit festgelegtem GENERATE_SESSION_PIN-Flag aufgerufen wird.)
Das folgende Verhalten sollte unterstützt werden:
- Anwendung A, ein vertrauenswürdiger Systemprozess, ruft ein Handle für die intelligente Karte ab und sammelt eine PIN.
- Anwendung A ruft dann die minidriver-Funktion Karte CardAuthenticateEx auf, übergibt die erfasste PIN und legt das flag CARD_AUTHENTICATE_GENERATE_SESSION_PIN fest. Dies führt nicht dazu, dass die Karte entsperrt wird.
- Anwendung A speichert die generierte Sitzungs-PIN und gibt das Handle für den Karte und Karte minidriver frei. Die Karte ist nicht kalt zurückgesetzt.
- Anwendung A sendet die Sitzungs-PIN und den Namen des Readers, der über die in Schritt 1 abgerufene Karte verfügt, an Anwendung B.
- Anwendung B ruft die gleiche Karte wie in 1 ab.
- Anwendung B ruft CardAuthenticateEx auf, übergibt die Sitzungs-PIN und legt das flag CARD_AUTHENTICATE_SESSION_PIN fest. Wenn die Sitzungs-PIN noch gültig ist, sollte die Karte authentifiziert und für die Verwendung gültig sein.
- Wenn Anwendung B mit dem Karte fertig ist, ruft sie CardDeauthenticateEx auf, um die Karte zu deaktivieren.
Dieses Verhalten hat die folgenden praktischen Einschränkungen:
Karten müssen ihre Fähigkeit zum Arbeiten mit Sitzungs-PINs deklarieren, indem sie den entsprechenden Wert für CP_CARD_PIN_STRENGTH_VERIFY zurückgeben.
Karten, die für jede Überprüfung auf die PIN angewiesen sind, sind nicht mit diesem System kompatibel.
Mehrere Anwendungen können das, was sie als gültige Sitzungs-PINs festlegen, jederzeit gleichzeitig haben. Wenn für jede PIN nur eine Sitzungs-PIN möglich ist, wird folgende Implementierung empfohlen:
- Der Karte sollte sich die zuletzt generierte Sitzungs-PIN merken.
- Wenn eine ungültige Sitzungs-PIN angezeigt wird, sollte der Karte die Authentifizierung fehlschlagen und, falls unterstützt, den Wiederholungszähler für die Sitzungs-PIN verringern. Wenn die Wiederholungsanzahl 0 erreicht und der nächste Authentifizierungsversuch ungültig ist, sollte die Sitzungs-PIN ungültig werden.
- Nachfolgende Sitzungs-PIN-Präsentationen sollten fehlschlagen, bis eine neue Sitzungs-PIN ausgehandelt wurde.
Die Sitzungs-PIN muss von verschiedenen Anwendungen im System verwendet werden können.
Die Sitzungs-PIN darf nicht einfach eine Codierung der PIN sein.
Die Sicherheit dieses Systems beschränkt sich auf die Stärke der Sitzungs-PIN und des Verhandlungsprotokolls, das zur Generierung verwendet wird. Die eigentliche Sitzungs-PIN-Aushandlung liegt außerhalb des Geltungsbereichs dieser Spezifikation. Wir stellen keine Anforderungen an den Entwurf, außer dass er wie in diesem Abschnitt beschrieben funktioniert.
Die Sitzungs-PIN gilt weiterhin als wertvoll und sollte als Geheimnis behandelt werden.
Die Karte sollte eine ungültige Sitzungs-PIN erkennen können.
Schreibgeschützte Karten
Um Karten zu adressieren, die außerhalb der Basis-CSP/KSP-Umgebung personalisiert und grundsätzlich schreibgeschützt sind, haben wir ein neues Konzept von schreibgeschützten Karten eingeführt. Wenn ein Karte schreibgeschützt ist, muss er dies über die CardGetProperty-Funktion ankündigen (siehe diesen Abschnitt weiter oben in dieser Spezifikation).
Schreibgeschützte Karten dürfen nur eine Teilmenge der Karte Minidriver-Schnittstelle von Version 7 unterstützen und müssen keine Administrator-PIN unterstützen.
In der folgenden Tabelle sind die Funktionen aufgeführt, die von einem schreibgeschützten Karte unterstützt werden müssen.
| Legende | |
|---|---|
| Ja | Diese Funktion muss implementiert werden. |
| Nein | Der Einstiegspunkt muss vorhanden sein und SCARD_E_UNSUPPORTED_FEATURE zurückgeben. |
| Nein (Optional) | Der Vorgang muss für einen schreibgeschützten Karte nicht unterstützt werden, kann aber implementiert werden, wenn der Karte den Vorgang unterstützt. Wird dies nicht unterstützt, muss der Einstiegspunkt SCARD_E_UNSUPPORTED_FEATURE zurückgeben. |
| Ja (Optional) | Diese Funktion sollte gemäß ihrer Definition in dieser Spezifikation implementiert werden, unabhängig davon, ob die Karte schreibgeschützt ist. |
Die folgenden Anforderungen sollten bei der Entwicklung eines Miniantriebs für eine schreibgeschützte Karte berücksichtigt werden:
- Alle erwarteten Basis-CSP/KSP-Dateien mit Ausnahme der Datei "msroots" (z. B. "cardcf" und "cardid") müssen auf dem schreibgeschützten Karte vorhanden sein (oder müssen über die Minidriver-Schnittstelle virtualisiert werden).
- Ein schreibgeschützter Karte muss mindestens einen Schlüssel auf dem Karte enthalten, der durch die primäre Karte-PIN (d. h. ROLE_USER) geschützt ist.
- Ein schreibgeschützter Karte darf keinen Administratorschlüssel enthalten. Wenn dies der Fall ist, wird erwartet, dass der Minitreiber CardGetChallenge, CardAuthenticateChallenge und CardUnblockPin nicht unterstützt.
- Bei der Abfrage sollte ein schreibgeschützter Karte 0 verfügbare Bytes und 0 verfügbare Container zurückgeben.
- Nur die Eigenschaften CP_PARENT_WINDOW und CP_PIN_CONTEXT_STRING sollten für einen schreibgeschützten Karte festgelegt werden dürfen.
- Bei einem schreibgeschützten Karte sollte die eigenschaft CP_SUPPORTS_WIN_X509_ENROLLMENT false sein.
Cachemodi
Der Basis-CSP/KSP unterstützt drei verschiedene Zwischenspeicherungsmodi, abhängig vom Cachemodus, der von cardGetProperty mit dem Parameter CP_CARD_CACHE_MODE zurückgegeben wurde:
- Wenn das zurückgegebene Flag CP_CACHE_MODE_GLOBAL_CACHE ist und die Karte die CP_READ_ONLY_CARD-Eigenschaft als TRUE gemeldet hat, ist der Basis-CSP/KSP-Datencache ein globaler Cache. Wenn der Karte schreibgeschützt ist, schreibt der Basis-CSP/KSP nicht in die cardcf-Datei. Wenn die Karte in den Basis-CSP/KSP geschrieben werden kann, wird sie wie heute ausgeführt.
- Weitere Informationen zu CP_CARD_CACHE_MODE und CP_CACHE_MODE_GLOBAL_CACHE finden Sie unter CardGetProperty.
- Wenn das zurückgegebene Flag CP_CACHE_MODE_SESSION_ONLY ist, wird der Basis-CSP/KSP so ausgeführt, dass der Datencache gelöscht wird, wenn erkannt wird, dass die Karte entfernt oder erneut eingefügt wurde. Mit anderen Worten, wir haben eine Sitzung als Spanne zwischen Karte Einfügen und Entfernen definiert.
- Der Cache wird auch für jeden Prozess implementiert und ist nicht global. Dieser Modus ist für schreibgeschützte Karten konzipiert, die sich nicht auf dem PC eines Benutzers ändern, sondern an einer Regierungsstation oder einem anderen externen Standort. (Dieser Modus wird für Lese-/Schreibkarten unterstützt, aber wir empfehlen den globalen Cache für diese Karten.)
- Wenn die Karte schreibgeschützt ist und die Möglichkeit besteht, dass sich die Karte auf dem PC des Benutzers ändert (mit anderen Mitteln als Basis-CSP/KSP), sollte die Anwendung den Modus ohne Cache verwenden, der später in dieser Spezifikation beschrieben wird, um die Situation zu vermeiden, in der der Cache veraltete Daten enthalten könnte.
- Wenn das Flag CP_CACHE_MODE_NO_CACHE ist, implementiert der Basis-CSP/KSP keine Datenzwischenspeicherung. Dieser Modus ist für Karte Minidriver konzipiert, die das Schreiben der cardcf-Datei nicht unterstützen, aber in denen sich der Karte Zustand ändern kann. Der Karte Minidriver entscheidet, ob er eine Zwischenspeicherung auf seiner Ebene durchführen möchte.
Herausforderungs-/Antwortmechanismus
Die Karte Minidriver-Schnittstelle unterstützt einen Authentifizierungsmechanismus für Herausforderungen und Antworten. Die Karte muss eine Herausforderung von mindestens 8 Byteblöcken generieren. Die authentifizierende Entität berechnet die Antwort, indem sie die Herausforderung mithilfe von Triple DES (3DES) verschlüsselt, das im CBC-Modus mit einem 168-Bit-Schlüssel arbeitet (und die Paritätsbits ignoriert).
Die Karte überprüft die Antwort mithilfe einer der folgenden Methoden:
- Wiederholen des Verschlüsselungsvorgangs für die zuvor ausgegebene Herausforderung und Vergleichen der Ergebnisse.
- Entschlüsseln der Antwort und Vergleichen des Ergebnisses mit der Herausforderung.
Wenn die resultierenden Werte identisch sind, ist die Authentifizierung erfolgreich.
Sowohl die Karte als auch die authentifizierende Entität müssen denselben symmetrischen Schlüssel verwenden.
Im folgenden Beispielcode wird beschrieben, wie die authentifizierende Entität die Antwort berechnen kann. Dieser Code deckt keine zugehörigen Garantien ab und wird lediglich als Beispiel und Anleitung bereitgestellt.
#include <windows.h>
#include <wincrypt.h>
#include <winscard.h>
#include <stdlib.h>
#include <stdio.h>
#include <memory.h>
int __cdecl wmain(int argc, __in_ecount(argc) WCHAR **wargv)
{
//Acquire the context Use CryptAcquireContext
HCRYPTPROV hProv= 0;
DWORD dwMode=CRYPT_MODE_ECB;
BYTE *pbLocData = NULL,tempbyte;
DWORD cbLocData = 8, count = 0;
HCRYPTKEY hKey = 0;
BYTE rgEncByte [] = {0xA8,0x92,0xD7,0x56,0x01,0x61,0x7C,0x5D };
BYTE DesKeyBlob [] = {
0x08, 0x02, 0x00, 0x00, 0x03, 0x66, 0x00, 0x00,
0x18, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00
};
pbLocData = (BYTE *) malloc (sizeof(BYTE)*cbLocData);
memcpy(pbLocData,rgEncByte,cbLocData);
if (!CryptAcquireContext(
&hProv,
NULL,
L"Microsoft Enhanced Cryptographic Provider V1.0",
PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT))
{
printf("Acquire context failed with 0x%08x \n", GetLastError());
goto Cleanup;
}
if (!CryptImportKey(
hProv,
DesKeyBlob,
sizeof(DesKeyBlob),
0,
0,
&hKey ) )
{
printf("Error 0x%08x in importing the 3Des key \n", GetLastError());
goto Cleanup;
}
if (!CryptSetKeyParam(
hKey,
KP_MODE,
(BYTE *)&dwMode,
0))
{
printf("Error 0x%08x in CryptSetKeyParam \n", GetLastError());
goto Cleanup;
}
if (!CryptEncrypt(
hKey,
0,
FALSE,
0,
pbLocData,
&cbLocData,
cbLocData))
{
printf("Error 0x%08x in CryptEncrypt call \n", GetLastError());
goto Cleanup;
}
for (count=0; count < cbLocData; ++count)
{
printf("0x%02x",pbLocData[count]);
}
printf("\n");
Cleanup:
if (hKey)
{
CryptDestroyKey(hKey);
hKey = 0;
}
if (pbLocData)
{
free(pbLocData);
pbLocData = NULL;
}
if (hProv)
{
CryptReleaseContext(hProv,0);
}
return 0;
}
Interoperabilität mit msroots
Die msroots-Datei ist ein PKCS #7-formatierter Zertifikatspeicher für vertrauenswürdige Unternehmensstammstämme. (Die Datei ist eine Sammlung von Zertifikaten mit leerem Inhalt und einer leeren Signatur und wird vom Basis-CSP geschrieben und gelesen.) Karten-Minidriver-Entwickler müssen keinen speziellen Code in den Karte Minidriver schreiben, um diese Datei zu verarbeiten. Beim Speichern von Zertifikaten in der msroots-Datei werden Eigenschaften wie CODE_SIGNING EKU nicht an die smarte Karte weitergegeben, da die msroots-Datei Zertifikate in einem anderen Format als die Computerspeicher speichert. Entwickler, die diese Datei aus anderen Anwendungen lesen oder schreiben möchten, können die folgenden Beispielcodeausschnitte verwenden, um auf die Daten zuzugreifen.
Lesevorgänge
if (FALSE == CryptQueryObject(CERT_QUERY_OBJECT_BLOB,
&dbStore,
CERT_QUERY_CONTENT_FLAG_PKCS7_SIGNED,
CERT_QUERY_FORMAT_FLAG_BINARY,
0,
NULL,
NULL,
NULL,
phCertStore,
NULL,
NULL))
{
dwSts = GetLastError();
}
Schreibvorgänge
// Serialize the store
if (FALSE == CertSaveStore( hCertStore,
PKCS_7_ASN_ENCODING | X509_ASN_ENCODING,
CERT_STORE_SAVE_AS_PKCS7,
CERT_STORE_SAVE_TO_MEMORY,
&dbStore,
0))
{
dwSts = GetLastError();
goto Ret;
}
dbStore.pbData = CspAllocH(dbStore.cbData);
if (NULL == dbStore.pbData)
{
dwSts = ERROR_NOT_ENOUGH_MEMORY;
goto Ret;
}
if (FALSE == CertSaveStore( hCertStore,
PKCS_7_ASN_ENCODING | X509_ASN_ENCODING,
CERT_STORE_SAVE_AS_PKCS7,
CERT_STORE_SAVE_TO_MEMORY,
&dbStore,
0))
{
dwSts = GetLastError();
goto Ret;
}
Gruppenrichtlinie Einstellungen für Microsoft Base SmartCard CSP
Gruppenrichtlinie Einstellungen für den Microsoft Base Smartcard Crypto Service Provider befinden sich unter [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Defaults \Anbieter\Microsoft Base Smartcard Crypto Provider].
| Schlüssel | BESCHREIBUNG |
|---|---|
| DefaultPrivateKeyLenBits | dword:00000400 Standardparameter für die Schlüsselgenerierung– 1024-Bit-Schlüssel. |
| RequireOnCardPrivateKeyGen | dword:00000000 Dadurch wird das Flag für die Anforderung einer Karte privaten Schlüsselgenerierung (Standard) festgelegt. Wenn dieser Wert festgelegt ist, kann der schlüssel, der auf einem Host generiert wird, in die Karte importiert werden. Dies wird für Karten verwendet, die keine on-Karte-Schlüsselgenerierung unterstützen oder bei denen die Schlüsseltresorierung erforderlich ist. |
| TransactionTimeoutMilliseconds | dword:000005dc 1500, 1,5 Sekunden ist das Standardtimeout für das Halten von Transaktionen im Karte. |
| AllowPrivateSignatureKeyImport | dword:00000000 Ermöglicht das Importieren von Signaturschlüsseln, d. h. Schlüsselarchivierungsszenarien. |
| AllowPrivateExchangeKeyImport | dword:00000000 Ermöglicht das Importieren von Austauschschlüsseln, d. h. Schlüsselarchivierungsszenarien. |
Gruppenrichtlinie Einstellungen für Microsoft CNG Smart Card KSP
Gruppenrichtlinie Einstellungen für den Microsoft CNG-Smartcard-Schlüsselspeicheranbieter befinden sich unter [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Cryptography \Providers\Microsoft SmartCard Key Storage Provider].
| Schlüssel | BESCHREIBUNG |
|---|---|
| DefaultPrivateKeyLenBits | dword:00000400 Standardparameter für die Schlüsselgenerierung– 1024-Bit-Schlüssel. |
| RequireOnCardPrivateKeyGen | dword:00000000 Dadurch wird das Flag für die Anforderung einer Karte privaten Schlüsselgenerierung (Standard) festgelegt. Wenn dieser Wert festgelegt ist, kann der schlüssel, der auf einem Host generiert wird, in die Karte importiert werden. Dies wird für Karten verwendet, die keine on-Karte-Schlüsselgenerierung unterstützen oder bei denen die Schlüsseltresorierung erforderlich ist. |
| TransactionTimeoutMilliseconds | dword:000005dc 1500, 1,5 Sekunden ist das Standardtimeout für das Halten von Transaktionen im Karte. |
| AllowPrivateSignatureKeyImport | dword:00000000 Ermöglicht das Importieren von Signaturschlüsseln, d. h. Schlüsselarchivierungsszenarien. |
| AllowPrivateExchangeKeyImport | dword:00000000 Ermöglicht das Importieren von Austauschschlüsseln, d. h. Schlüsselarchivierungsszenarien. |
| AllocPrivateECDHEKeyImport | dword:00000000 Ermöglicht das Importieren von ECDH-Schlüsseln, d.a. Schlüsselarchivierungsszenarien |
| AllowPrivateECDSAKeyImport | dword:00000000 Ermöglicht das Importieren von ECDSA-Schlüsseln, d. a. Schlüsselarchivierungsszenarien |
Besondere Überlegungen
In Windows Vista mit Service Pack 1 (SP1) ist das Betriebssystem zwar im abgesicherten Modus ausgeführt, aber außer der Windows-Anmeldung sind keine PIN-erforderlichen vorgänge für intelligente Karte möglich.
Der Aufruf von CryptAcquireContext mit einem der folgenden Flags fordert zur PIN-Authentifizierung mit USER_PIN unabhängig von der tatsächlichen PIN, die dem Container zugewiesen ist:
- CRYPT_NEWKEYSET
- CRYPT_DEFAULT_CONTAINER_OPTIONAL
- CRYPT_DELETEKEYSET
- CRYPT_VERIFYCONTEXT
CardDeleteContext kann auch aufgerufen werden, nachdem DllMain mit DLL_PROCESS_DETACH aufgerufen wurde.