Karten-PIN-Vorgänge

Der Begriff PIN wurde von der Bankenindustrie geerbt, da sie zunächst auf der numerischen Tastatur von ATM-Computern verwendet wurde. Einige andere Branchendokumentationen verwenden die Überprüfung der Begriffskarte (CHV). Es ist verstanden, dass das Datenformat nicht nur numerische, sondern alles sein kann, was der Benutzer zur Verfügung stellen kann. Der Wert, der als PIN-Daten übergeben wird, wird durch Interoperabilitätsüberlegungen an den ANSI-Zeichensatz eingeschränkt.

Die Authentifizierung des Benutzers unterscheidet sich stark von der Authentifizierung des Administrators, in der der Benutzer normalerweise nicht privilegierter ist, um den administratorbasierten Authentifizierungsschlüssel zu besitzen. Dies hat viele Auswirkungen darauf, welche Art von Daten für diese Art verwendet werden kann und wie sie behandelt werden soll. Wenn der administrative Geheimschlüssel auf dem Clientcomputer verwendet wird, um etwas wie die Entsperrung der Karte eines Benutzers mit Hilfe einer zentralen Behörde zu tun, muss diese Daten entweder sicher an die Karte übertragen werden, ohne dass die Offenlegung möglich ist oder sonst völlig ephemerisch sein kann, damit es außerhalb der aktuellen Transaktion keinen Wert hat. Die Schwierigkeit, die sichere Übertragung an die Karte zu organisieren, ist die Verwendung einer PIN zum Authentifizieren des Administrators entmutigt.

Eine Authentifizierung ist nur innerhalb einer Transaktion gültig, um zu verhindern, dass eine andere Anwendung eine authentifizierte Sitzung entjackt. Die Deauthentication tritt beim Beenden einer Transaktion automatisch auf.

Das Ändern der PIN muss sicheres Token ungültig sein.

Allgemeine Definitionen

Zwei Datentypen sind für PINs definiert: eine für die Beschreibung einzelner PINs, die Rollen zugeordnet sind, und PIN_SET, die für ein Bitformat mit PIN-Bezeichnern verwendet werden. Außerdem haben wir Zeichenfolgen für Benutzernamen nicht mehr verwendet und Rollennummern eingeführt, die in PIN-Bezeichner übersetzt werden. Außerdem definieren wir zwei Flags für den PIN-Änderungsvorgang, der später in dieser Spezifikation erläutert wird.

typedef     DWORD                      PIN_ID, *PPIN_ID;
typedef     DWORD                      PIN_SET, *PPIN_SET;

#define     MAX_PINS                   8

#define     ROLE_EVERYONE              0
#define     ROLE_USER                  1
#define     ROLE_ADMIN                 2

#define     PIN_SET_ALL_ROLES          0xFF
#define     CREATE_PIN_SET(PinId)      (1 << PinId)
#define     SET_PIN(PinSet, PinId)     PinSet |= CREATE_PIN_SET(PinId)
#define     IS_PIN_SET(PinSet, PinId)  (0 != (PinSet & CREATE_PIN_SET(PinId)))
#define     CLEAR_PIN(PinSet, PinId)   PinSet &= ~CREATE_PIN_SET(PinId)

#define     PIN_CHANGE_FLAG_UNBLOCK    0x01
#define     PIN_CHANGE_FLAG_CHANGEPIN  0x02

Um mit den aktuellen Karten minidriverkarten funktionsfähig zu sein, müssen alle Karten mindestens mit drei Rollen bereitgestellt werden: ROLE_EVERYONE, ROLE_USER und ROLE_ADMIN. Jede Rolle entspricht einem PIN_ID auf der Karte. Es gibt nur eine true Administratorrolle für eine Karte, aber es können mehrere Rollen vorhanden sein, die andere Rollen aufheben können. Allerdings sollte nur eine Rolle den Zugriff auf die Ausführung von Vorgängen auf Administratorebene steuern, z. B. das Löschen des Dateisystems, und dies ist ROLE_ADMIN. Darüber hinaus muss ROLE_ADMIN in der Lage sein, ROLE_USER zu blockieren. Es gibt auch nur eine Benutzerrolle, die Zugriff auf das Dateisystem für eine Karte bietet. Die zusätzlichen Rollen 3 bis 7 sind optional und können nur schlüsselcontainern zugeordnet werden.

Besondere Überlegungen, die für schreibgeschützte Karten gelten können, finden Sie weiter unten in dieser Spezifikation unter "Schreibgeschützte Karten".

SECRET_TYPE

Die folgende Aufzählung beschreibt den Typ der PIN.

typedef enum
{
    AlphaNumericPinType = 0,    // Regular PIN
    ExternalPinType,            // External PIN
    ChallengeResponsePinType,   // Challenge/Response PIN
    EmptyPinType                // No PIN
} SECRET_TYPE;

Hinweis Beim Auftreten von PIN-SECRET_TYPEEmptyPinType fordert Windows keine PIN auf, und ruft cardAuthenticatePin oder CardAuthenticatePinEx nicht auf. Diese Einstellung ist nützlich, wenn ein bedingungsloser Zugriff auf Material auf der Karte gewünscht wird.

SECRET_PURPOSE

Die folgende Enumeration wird von der PIN_INFO Datenstruktur verwendet, um den Zweck der PIN für Benutzerinformationen zu beschreiben.

typedef enum
{
    AuthenticationPin,      // Authentication PIN
    DigitalSignaturePin,    // Digital Signature PIN
    EncryptionPin,          // Encryption PIN
    NonRepudiationPin,      // Non Repudiation PIN
    AdministratorPin,       // Administrator PIN
    PrimaryCardPin,
    UnblockOnlyPin          // Unblocking other PINs
} SECRET_PURPOSE;

Windows verwendet den Aufzählungswert, um eine entsprechende Nachricht für den Benutzer anzuzeigen, der beschreibt, welche Karten-PIN derzeit angefordert wird. Der Minidriver steuert vollständig, welche SECRET_TYPE verwendet werden sollen. Im Folgenden finden Sie eine Abbildung eines PIN-Eingabeaufforderungsdialogfelds, das Beispielkontextzeichenfolgen enthält.

Die erste Zeichenfolge in der Abbildung ("PIN eingeben. Die Registrierung für: BaseRSASmartcardLogon") wird von der aufrufenden Anwendung bereitgestellt, um Anwendungskontext bereitzustellen. Wenn keine Anwendungskontextzeichenfolge vorhanden ist, zeigt das Dialogfeld einen Standardtext an.

Die zweite Zeichenfolge ("Bitte geben Sie Ihre Authentifizierungs-PIN ein") wird von SECRET_PURPOSE auf eine der folgenden Arten gesteuert:

• Standardkontextzeichenfolgen

  Standardmäßig zeigt der Basis-CSP die folgenden vordefinierten Zeichenfolgen an, die entsprechend lokalisiert sind.

  Zeichenfolgenname	String
  AuthenticationPin	"Bitte geben Sie Ihre Authentifizierungs-PIN ein."
  DigitalSignaturePin	"Bitte geben Sie Ihre digitale Signatur-PIN ein."
  EncryptionPin	"Bitte geben Sie Ihre Verschlüsselungs-PIN ein."
  NonRepudiationPin	"Bitte geben Sie Ihre Nicht-Ablehnungs-PIN ein."
  AdministratorPin	"Bitte geben Sie Ihre Administrator-PIN ein."
  PrimaryCardPin	"Bitte geben Sie Ihre PIN ein."
  UnblockOnlyPin	"Geben Sie Ihre PIN ein, um die Benutzer-PIN zu blockieren."

• Benutzerdefinierte Zeichenfolgen

  Entwickler können die Standardkontextzeichenfolgen außer Kraft setzen, indem Sie benutzerdefinierte Zeichenfolgen in den folgenden Registrierungswerten des Registrierungsschlüssels des Minidrivers (HKLM\Software\SOFTWARE\Microsoft\Kryptografie\Calais\SmartCards\XYZ festlegen, wobei XYZ der Name des Karten-Minidrivers ist).

  Um eine vordefinierte Kontextzeichenfolge außer Kraft zu setzen, fügen Sie dem Registrierungsschlüssel des Minidrivers mit der benutzerdefinierten Zeichenfolge einen Registrierungszeichenfolgenwert hinzu. Der Name der Schlüsselsätze , die SECRET_PURPOSE vordefinierten Kontextzeichenfolge überschrieben werden, mit 0x80000100, die dem ersten Element von SECRET_TYPE und weiter entspricht. Es ist nicht möglich, nur eine Zeichenfolge, einige oder alle Kontextzeichenfolgen außer Kraft zu setzen.

  Der Wert der Zeichenfolge sollte dem folgenden Format folgen:

  “LangID,xxxx;LangID,xxxxx”
  

  Hinweis Anführungszeichen um die benutzerdefinierte Zeichenfolge werden nicht ordnungsgemäß behandelt und sollten nicht verwendet werden, um zu verhindern, dass Sonderzeichen innerhalb der Zeichenfolge analysiert werden.

Hinweis Einschließlich zwei verschiedener benutzerdefinierter Zeichenfolgen für dasselbe Gebietsschema führt dazu, dass die erste benutzerdefinierte Zeichenfolge aufgenommen wird.

Die dritte Zeichenfolge im Dialogfeld ("Digitale Signatur-PIN") ist eine vordefinierte Zeichenfolge, die durch den SECRET_PURPOSE-Wert in der PIN_INFO Datenstruktur bestimmt wird.

Bei UnblockOnlyPin besteht der beabsichtigte Zweck darin, die Benutzer-PIN zu deaktivieren. Diese PIN darf nicht für einen anderen Zweck verwendet werden.

PIN_CACHE_POLICY_TYPE

Die folgende Aufzählung beschreibt die PIN-Zwischenspeicherungsrichtlinie, die dieser PIN zugeordnet werden soll.

typedef enum
{
    PinCacheNormal = 0,
    PinCacheTimed,
    PinCacheNone,
    PinCacheAlwaysPrompt
} PIN_CACHE_POLICY_TYPE;

In der folgenden Tabelle wird beschrieben, wie die Basis-CSP auf die drei verschiedenen Cachemodi wirkt.

Cachemodus	BESCHREIBUNG
PinCacheNormal	Für diesen Modus wird die PIN vom Basis-CSP pro Prozess pro Anmelde-ID zwischengespeichert.
PinCacheTimed	Für diesen Modus wird die PIN nach einem angegebenen Zeitraum ungültig (Wert wird in Sekunden angegeben). Dies wurde implementiert, indem der Zeitstempel aufgezeichnet wird, wenn die PIN dem Cache hinzugefügt wird, und dann überprüfen Sie diesen Zeitstempel im Vergleich zum Zeitpunkt des Zugriffs auf die PIN. Dies bedeutet, dass die PIN potenziell im Cache länger als der angegebene Zeitstempel lebt, aber nach ablaufen nicht verwendet wird. Die PIN wird im Arbeitsspeicher verschlüsselt, um sie geschützt zu halten.
PinCacheNone	Wenn die PIN nicht zwischengespeichert werden kann, fügt Base CSP die PIN nie zum Cache hinzu. Wenn der Basis-CSP/KSP mit CryptSetProvParam aufgerufen wird, um eine PIN festzulegen, wird die PIN an die Karte übermittelt, um die Überprüfung zu überprüfen, aber nicht zwischengespeichert. Dies bedeutet, dass alle nachfolgenden Vorgänge auftreten müssen, bevor die Basis-CSP-Transaktionszeit abläuft.
PinCacheAlwaysPrompt	Im Gegensatz zu PinCacheNone ist der Basis-CSP-Transaktionstimeout nicht anwendbar, wenn dieser Cachemodus festgelegt ist. Die PIN wird vom Benutzer gesammelt und dann an die Karte übermittelt, um die Überprüfung vor jedem Anruf zu überprüfen, der eine Authentifizierung erfordert. Aufrufe an CryptSetProvParam und NcryptSetProperty zum Festlegen der PIN-Rückgabe ERROR_SUCCESS ohne Überprüfen und Zwischenspeichern der PIN. Dies bedeutet, dass Aufrufe von Anwendungen, die stumme Kontexte verwenden, fehlschlägt, wenn der Aufruf eine Authentifizierung erfordert.

Beachten Sie, dass die Anmeldung Windows möglicherweise nicht ordnungsgemäß funktioniert, wenn eine PIN nicht zwischengespeichert wird. Dieses Verhalten ist beabsichtigt. Daher sollte bei der Einstellung eines PIN-Cachemodus ein anderer Wert als PinCacheNormal berücksichtigt werden.

PIN_CACHE_POLICY

Die PIN-Cacherichtlinienstruktur enthält Informationen, die die PIN-Cacherichtlinie beschreiben. Es beschreibt den PIN-Cachetyp zusätzlich zu zugeordneten Informationen mit dieser PIN-Cacherichtlinie. Ein Beispiel für diese zugeordneten Informationen wäre ein Timeoutwert für den PIN-Cache, wenn die Richtlinie PinCacheTimed angibt.

#define      PIN_CACHE_POLICY_CURRENT_VERSION   6

typedef struct _PIN_CACHE_POLICY
{
    DWORD                   dwVersion;
    PIN_CACHE_POLICY_TYPE   PinCachePolicyType;
    DWORD                   dwPinCachePolicyInfo;
} PIN_CACHE_POLICY, *PPIN_CACHE_POLICY;

PIN_INFO

Die PIN-Objektstruktur enthält Informationen, die die PIN beschreiben. Es beschreibt den PIN-Typ, den pin nicht blockiert werden darf, und die PIN-Zwischenspeicherungsrichtlinie. Nachdem eine PIN-Informationsstruktur vom Basis-CSP/KSP abgerufen wurde, sollte es im Datencache zwischengespeichert werden, ähnlich wie Datendateien zwischengespeichert werden.

#define      PIN_INFO_REQUIRE_SECURE_ENTRY       1

typedef struct _PIN_INFO
{
    DWORD                   dwVersion;
    SECRET_TYPE             PinType;
    SECRET_PURPOSE          PinPurpose;
    PIN_SET                 dwChangePermission;
    PIN_SET                 dwUnblockPermission;
    PIN_CACHE_POLICY        PinCachePolicy;
    DWORD                   dwFlags;
} PIN_INFO, *PPIN_INFO;

Das dwUnblockPermission-Element ist ein Bitformat, das beschreibt, welche PINs über die Berechtigung zum Aufheben der Blockierung der PIN verfügen. Die Berechtigung basiert auf einem bitweisen "oder" der angegebenen PINs. Bei einem Unblock-Vorgang sollte der Karten-Minidriver alle Selbstreferenzen ignorieren. Die ROLE_USER hätte eine Aktualisierungsberechtigungs-Bitmaske von 0x00000100. Dies bedeutet, dass die Blockierung durch ROLE_ADMIN aufgehoben werden kann. ROLE_ADMIN, die über eine Aktualisierungsberechtigung für 0x00000000 verfügt. Dies bedeutet, dass die Blockierung nicht aufgehoben werden kann.

Das dwFlags-Element enthält PIN-Flags. Derzeit ist nur ein Flag definiert: PIN_INFO_REQUIRE_SECURE_ENTRY. Dieses Kennzeichen gibt an, ob für den PIN-Eintrag ein sicherer Desktop erforderlich ist.

Hinweis Mithilfe dieser Struktur können Sie ROLE_EVERYONE Berechtigung zum Ändern oder Aufheben der Blockierung einer PIN erteilen. Wir empfehlen dies nicht, und es wird kein Mechanismus in der Minidriver-API bereitgestellt, damit ROLE_EVERYONE eine PIN ändern oder aufheben können.