Windows Hello

In diesem Artikel wird die Windows Hello-Technologie beschrieben, die als Teil von Windows ausgeliefert wird, und erläutert, wie Entwickler diese Technologie implementieren können, um ihre Windows-Apps und Back-End-Dienste zu schützen. Es hebt spezifische Funktionen dieser Technologien hervor, die dazu beitragen, Bedrohungen zu minimieren, die sich aus der Verwendung herkömmlicher Anmeldeinformationen ergeben, und bietet Anleitungen zum Entwerfen und Bereitstellen dieser Technologien als Teil eines Windows-Clientrollouts.

Hinweis

Dieser Artikel konzentriert sich auf die App-Entwicklung. Informationen zu den Architektur- und Implementierungsdetails von Windows Hello finden Sie unter Planen einer Windows Hello for Business-Bereitstellung.

Eine schrittweise exemplarische Vorgehensweise zum Erstellen einer WinUI-App mit Windows Hello und dem Sicherungsauthentifizierungsdienst finden Sie in den Artikeln zur Windows Hello-Anmelde-App und zum Windows Hello-Anmeldedienst .

Einführung

Eine grundlegende Annahme der Informationssicherheit besteht darin, dass ein System erkennen kann, wer es verwendet. Durch das Identifizieren eines Benutzers kann das System entscheiden, ob der Benutzer angemessen identifiziert wird (ein Prozess, der als Authentifizierung bezeichnet wird), und dann entscheiden, was ein ordnungsgemäß authentifizierter Benutzer tun sollte (Autorisierung). Die überwiegende Mehrheit der weltweit bereitgestellten Computersysteme hängt von Benutzeranmeldeinformationen ab, um Authentifizierungs- und Autorisierungsentscheidungen zu treffen, was bedeutet, dass diese Systeme von wiederverwendbaren, vom Benutzer erstellten Kennwörtern als Grundlage für ihre Sicherheit abhängen. Die oft zitierte Maxime, dass die Authentifizierung "etwas, was Sie kennen, etwas, das Sie haben oder was Sie sind" beinhalten kann, hebt das Problem ordentlich hervor: Ein wiederverwendbares Kennwort ist allein ein Authentifizierungsfaktor, sodass jeder, der das Kennwort kennt, den Identitätswechsel des Benutzers übernehmen kann, der es besitzt.

Probleme mit herkömmlichen Anmeldeinformationen

Seit Mitte der 1960er Jahre, als Fernando Corbató und sein Team am Massachusetts Institute of Technology die Einführung des Kennworts, Benutzer und Administratoren mit der Verwendung von Kennwörtern für die Benutzerauthentifizierung und Autorisierung umgehen mussten. Im Laufe der Zeit ist der Stand der Technik für die Kennwortspeicherung und -verwendung etwas fortgeschritten (z. B. mit sicherem Hashing und Salting), aber wir sind immer noch mit zwei Problemen konfrontiert. Kennwörter sind einfach zu klonen und leicht zu stehlen. Darüber hinaus können Implementierungsfehler sie unsicher machen, und Benutzer haben eine harte Zeit, Komfort und Sicherheit zu ausgleichen.

Diebstahl von Anmeldeinformationen

Wo das größte Risiko bei Kennwörtern besteht, ist offensichtlich: Ein Angreifer kann sie ohne Weiteres stehlen. Jeder Ort, an dem ein Kennwort eingegeben, verarbeitet oder gespeichert wird, ist angreifbar. Beispielsweise kann ein Angreifer eine Sammlung von Kennwörtern oder Hashes von einem Authentifizierungsserver stehlen, indem er den Netzwerkdatenverkehr an einen Anwendungsserver abhört, Schadsoftware in eine Anwendung oder auf einem Gerät einpfen kann, indem Benutzertastenschläge auf einem Gerät protokolliert werden, oder indem sie sehen, welche Zeichen ein Benutzer eingibt. Dies sind nur die am häufigsten verwendeten Angriffsmethoden.

Ein weiteres verwandtes Risiko besteht darin, dass anmeldeinformationen wiedergegeben werden, bei denen ein Angreifer eine gültige Anmeldeinformationen durch Abhören in einem unsicheren Netzwerk erfasst und später wiedergibt, um einen gültigen Benutzer zu imitieren. Die meisten Authentifizierungsprotokolle (einschließlich Kerberos und OAuth) schützen vor Replay-Angriffen, indem sie einen Zeitstempel im Anmeldeinformationsaustauschprozess einschließen, aber diese Taktik schützt nur das Token, das das Authentifizierungssystem ausgibt, nicht das Kennwort, das der Benutzer zum Abrufen des Tickets an erster Stelle bereitstellt.

Wiederverwendung von Anmeldeinformationen

Der gängige Ansatz, eine E-Mail-Adresse als Benutzername zu verwenden, macht ein schlechtes Problem schlimmer. Ein Angreifer, der erfolgreich ein Benutzername-Kennwort-Paar aus einem kompromittierten System wiederhergestellt hat, kann dann dasselbe Paar auf anderen Systemen ausprobieren. Diese Taktik funktioniert überraschend oft, um Angreifern das Springboard von einem kompromittierten System in andere Systeme zu ermöglichen. Die Verwendung von E-Mail-Adressen als Benutzernamen führt zu zusätzlichen Problemen, die wir später in diesem Leitfaden untersuchen werden.

Beheben von Anmeldeinformationsproblemen

Die Lösung der Probleme, die Kennwörter darstellen, ist schwierig. Die Verschärfung von Kennwortrichtlinien allein wird dies nicht tun; Benutzer können kennwörter einfach wiederverwenden, freigeben oder notieren. Obwohl die Benutzerschulung für die Authentifizierungssicherheit von entscheidender Bedeutung ist, beseitigt Bildungseinrichtungen das Problem auch nicht.

Windows Hello ersetzt Kennwörter durch eine sichere zweistufige Authentifizierung (2FA), indem vorhandene Anmeldeinformationen überprüft und gerätespezifische Anmeldeinformationen erstellt werden, die von einer biometrischen oder PIN-basierten Benutzergeste geschützt werden.

Was ist Windows Hello?

Windows Hello ist der Name, den Microsoft dem neuen in Windows integrierten biometrischen Anmeldesystem gegeben hat. Da es direkt in das Betriebssystem integriert ist, bietet Windows Hello die Möglichkeit, die Geräte der Benutzenden per Gesichtserkennung oder Fingerabdruck zu entsperren. Die Authentifizierung erfolgt, wenn der Benutzer seinen eindeutigen biometrischen Bezeichner für den Zugriff auf die gerätespezifischen Anmeldeinformationen bereitstellt. Dies bedeutet, dass sich ein Angreifer, der das Gerät gestohlen hat, nicht anmelden kann, es sei denn, dieser Angreifer verfügt über die PIN. Der sichere Windows Store für Anmeldeinformationen schützt die biometrischen Daten auf dem Gerät. Durch die Verwendung von Windows Hello zum Entsperren eines Geräts erhält der autorisierte Benutzer Zugriff auf alle Windows-Erfahrungen, Apps, Daten, Websites und Dienste.

Der Windows Hello-Authentifikator wird als Hello bezeichnet. Ein Hello ist einzigartig für die Kombination eines einzelnen Geräts und eines bestimmten Benutzers. Es wird nicht auf allen Geräten übertragen, nicht für einen Server oder eine aufrufende App freigegeben und kann nicht einfach von einem Gerät extrahiert werden. Wenn mehrere Benutzer ein Gerät freigeben, muss jeder Benutzer sein eigenes Konto einrichten. Jedes Konto erhält ein eindeutiges Hello für dieses Gerät. Sie können sich ein Hello als Token vorstellen, das Sie zum Entsperren (oder Freigeben) einer gespeicherten Anmeldeinformationen verwenden können. Das Hello selbst authentifiziert Sie nicht bei einer App oder einem Dienst, sondern gibt Anmeldeinformationen frei, die möglich sind. Mit anderen Worten, das Hello ist keine Benutzeranmeldeinformationen, sondern ein zweiter Faktor für die Authentifizierung.

Windows Hello-Authentifizierung

Windows Hello bietet eine robuste Möglichkeit für ein Gerät, eine*n einzelne*n Benutzer*in zu erkennen, was den ersten Teil des Weges zwischen einem/einer Benutzenden und einem angeforderten Dienst oder Datenelement darstellt. Nachdem das Gerät den/die Benutzende*n erkannt hat, muss es ihn/sie noch authentifizieren, bevor es entscheidet, ob es den Zugriff auf eine angeforderte Ressource gewährt. Windows Hello bietet starke 2FA, die vollständig in Windows integriert ist und wiederverwendbare Kennwörter durch die Kombination eines bestimmten Geräts und eine biometrische Geste oder PIN ersetzt.

Windows Hello ist jedoch nicht nur ein Ersatz für herkömmliche 2FA-Systeme. Es ähnelt konzeptuell Smartcards: Die Authentifizierung erfolgt mithilfe kryptografischer Grundtypen anstelle von Zeichenfolgenvergleichen, und das Schlüsselmaterial des Benutzers ist innerhalb manipulationssicherer Hardware sicher. Windows Hello erfordert nicht die zusätzlichen Infrastrukturkomponenten, die für die Smartcardbereitstellung erforderlich sind. Insbesondere benötigen Sie keine Public Key-Infrastruktur (PKI), um Zertifikate zu verwalten, wenn Sie derzeit kein Zertifikat besitzen. Windows Hello kombiniert die wichtigsten Vorteile von Smartcards – die Flexibilität bei der Bereitstellung von virtuellen Smartcards und die robuste Sicherheit von physischen Smartcards – ohne deren Nachteile.

Funktionsweise von Windows Hello

Wenn der Benutzer Windows Hello auf seinem Computer einrichte, generiert er ein neues öffentlich-privates Schlüsselpaar auf dem Gerät. Das Trusted Platform Module (TPM) generiert und schützt diesen privaten Schlüssel. Wenn das Gerät nicht über einen TPM-Chip verfügt, wird der private Schlüssel verschlüsselt und durch Software geschützt. Darüber hinaus generieren TPM-fähige Geräte einen Datenblock, der verwendet werden kann, um zu bestätigen, dass ein Schlüssel an TPM gebunden ist. Diese Nachweisinformationen können in Ihrer Lösung verwendet werden, um zu entscheiden, ob dem Benutzer beispielsweise eine andere Autorisierungsstufe gewährt wird.

Um Windows Hello auf einem Gerät zu aktivieren, muss der Benutzer entweder über sein Microsoft Entra-ID-Konto oder über ein Microsoft-Konto verfügen, das in den Windows-Einstellungen verbunden ist.

Schutz von Schlüsseln

Jedes Mal, wenn Schlüsselmaterial generiert wird, muss es vor Angriffen geschützt werden. Die robusteste Möglichkeit hierfür ist die spezielle Hardware. Es gibt eine lange Geschichte der Verwendung von Hardwaresicherheitsmodulen (Hardware Security Modules, HSMs) zum Generieren, Speichern und Verarbeiten von Schlüsseln für sicherheitskritische Anwendungen. Smartcards sind eine spezielle Art von HSM, ebenso wie Geräte, die mit dem TPM-Standard der Trusted Computing Group kompatibel sind. Wo immer möglich, nutzt die Windows Hello-Implementierung das Onboarding von TPM-Hardware, um Schlüssel zu generieren, zu speichern und zu verarbeiten. Windows Hello und Windows Hello for Work erfordern jedoch kein integriertes TPM.

Nach Möglichkeit empfiehlt Microsoft die Verwendung von TPM-Hardware. Das TPM schützt vor einer Vielzahl bekannter und potenzieller Angriffe, einschließlich PIN-Brute-Force-Angriffen. Das TPM bietet auch nach einer Kontosperre eine zusätzliche Schutzebene. Wenn das TPM das Schlüsselmaterial gesperrt hat, muss der Benutzer die PIN zurücksetzen. Das Zurücksetzen der PIN bedeutet, dass alle Schlüssel und Zertifikate, die mit dem alten Schlüsselmaterial verschlüsselt sind, entfernt werden.

Authentifizierung

Wenn ein Benutzer auf geschütztes Schlüsselmaterial zugreifen möchte, beginnt der Authentifizierungsprozess mit der Eingabe einer PIN oder biometrischen Geste, um das Gerät zu entsperren, ein Prozess, der manchmal als "Loslassen des Schlüssels" bezeichnet wird.

Eine Anwendung kann niemals die Schlüssel aus einer anderen Anwendung verwenden, noch kann jemand jemals die Schlüssel eines anderen Benutzers verwenden. Diese Schlüssel werden verwendet, um Anforderungen zu signieren, die an den Identitätsanbieter oder IDP gesendet werden, um Zugriff auf angegebene Ressourcen zu erhalten. Anwendungen können bestimmte APIs verwenden, um Vorgänge anzufordern, die schlüsselmaterial für bestimmte Aktionen erfordern. Der Zugriff über diese APIs erfordert eine explizite Überprüfung über eine Benutzergeste, und das Schlüsselmaterial wird nicht für die anfordernde Anwendung verfügbar gemacht. Stattdessen fordert die Anwendung eine bestimmte Aktion wie das Signieren eines Datenabschnitts auf, und die Windows Hello-Ebene behandelt die eigentliche Arbeit und gibt die Ergebnisse zurück.

Vorbereiten der Implementierung von Windows Hello

Nachdem wir nun ein grundlegendes Verständnis für die Funktionsweise von Windows Hello haben, schauen wir uns an, wie sie in unseren eigenen Anwendungen implementiert werden.

Es gibt verschiedene Szenarien, die wir mit Windows Hello implementieren können. Melden Sie sich beispielsweise einfach auf einem Gerät bei Ihrer App an. Das andere häufige Szenario wäre die Authentifizierung bei einem Dienst. Statt einen Anmeldenamen und ein Kennwort zu verwenden, verwenden Sie Windows Hello. In den folgenden Abschnitten befassen wir uns mit der Implementierung einiger verschiedener Szenarien, einschließlich der Authentifizierung bei Ihren Diensten mit Windows Hello und der Konvertierung von einem vorhandenen Benutzernamen-/Kennwortsystem in ein Windows Hello-System.

Implementieren von Windows Hello

In diesem Abschnitt beginnen wir mit einem Greenfield-Szenario ohne vorhandenes Authentifizierungssystem, und wir erläutern, wie Windows Hello implementiert wird.

Im nächsten Abschnitt wird beschrieben, wie Sie aus einem vorhandenen Benutzernamen-/Kennwortsystem migrieren. Auch wenn dieser Abschnitt Sie mehr interessiert, sollten Sie sich diesen Abschnitt ansehen, um ein grundlegendes Verständnis des Prozesses und des erforderlichen Codes zu erhalten.

Registrieren neuer Benutzer

Wir beginnen mit einem brandneuen Dienst, der Windows Hello verwendet, und einem hypothetischen neuen Benutzer, der bereit ist, sich auf einem neuen Gerät anzumelden.

Der erste Schritt besteht darin, sicherzustellen, dass der Benutzer Windows Hello verwenden kann. Die App überprüft Die Benutzereinstellungen und Computerfunktionen, um sicherzustellen, dass sie Benutzer-ID-Schlüssel erstellen kann. Wenn die App feststellt, dass der Benutzer Windows Hello noch nicht aktiviert hat, fordert sie den Benutzer auf, dies vor der Verwendung der App einzurichten.

Um Windows Hello zu aktivieren, muss der Benutzer lediglich eine PIN in den Windows-Einstellungen einrichten, es sei denn, der Benutzer hat sie während der Out of Box Experience (OOBE) eingerichtet.

Die folgenden Codezeilen zeigen eine einfache Möglichkeit, um zu überprüfen, ob der Benutzer für Windows Hello eingerichtet ist.

var keyCredentialAvailable = await KeyCredentialManager.IsSupportedAsync();
if (!keyCredentialAvailable)
{
    // User didn't set up PIN yet
    return;
}

Der nächste Schritt besteht darin, den Benutzer um Informationen zur Registrierung bei Ihrem Dienst zu bitten. Sie können den Benutzer nach Vornamen, Nachnamen, E-Mail-Adresse und einem eindeutigen Benutzernamen fragen. Sie könnten die E-Mail-Adresse als eindeutigen Bezeichner verwenden; es liegt an Ihnen.

In diesem Szenario verwenden wir die E-Mail-Adresse als eindeutigen Bezeichner für den Benutzer. Sobald sich der Benutzer registriert hat, sollten Sie erwägen, eine Überprüfungs-E-Mail zu senden, um sicherzustellen, dass die Adresse gültig ist. Dadurch erhalten Sie einen Mechanismus, um das Konto bei Bedarf zurückzusetzen.

Wenn der Benutzer seine PIN eingerichtet hat, erstellt die App die KeyCredential des Benutzers. Die App ruft außerdem die optionalen Schlüsselnachweisinformationen ab, um kryptografische Nachweise zu erhalten, dass der Schlüssel im TPM generiert wird. Der generierte öffentliche Schlüssel und optional der Nachweis werden an den Back-End-Server gesendet, um das verwendete Gerät zu registrieren. Jedes Schlüsselpaar, das auf jedem Gerät generiert wird, ist eindeutig.

Der Code zum Erstellen der KeyCredential sieht wie folgt aus:

var keyCreationResult = await KeyCredentialManager.RequestCreateAsync(
    AccountId, KeyCredentialCreationOption.ReplaceExisting);

RequestCreateAsync ist der Aufruf, der den öffentlichen und privaten Schlüssel erstellt. Wenn das Gerät über den richtigen TPM-Chip verfügt, fordert die APIs den TPM-Chip an, um den privaten und öffentlichen Schlüssel zu erstellen und das Ergebnis zu speichern. Wenn kein TPM-Chip verfügbar ist, erstellt das Betriebssystem das Schlüsselpaar im Code. Es gibt keine Möglichkeit für die App, direkt auf die erstellten privaten Schlüssel zuzugreifen. Ein Teil der Erstellung der Schlüsselpaare ist auch die resultierenden Nachweisinformationen. (Weitere Informationen zum Nachweis finden Sie im nächsten Abschnitt.)

Nachdem das Schlüsselpaar und die Nachweisinformationen auf dem Gerät erstellt wurden, müssen der öffentliche Schlüssel, die optionalen Nachweisinformationen und der eindeutige Bezeichner (z. B. die E-Mail-Adresse) an den Back-End-Registrierungsdienst gesendet und im Back-End gespeichert werden.

Damit der Benutzer auf mehreren Geräten auf die App zugreifen kann, muss der Back-End-Dienst mehrere Schlüssel für denselben Benutzer speichern können. Da jeder Schlüssel für jedes Gerät eindeutig ist, werden alle diese Schlüssel gespeichert, die mit demselben Benutzer verbunden sind. Ein Gerätebezeichner wird verwendet, um den Serverteil beim Authentifizieren von Benutzern zu optimieren. Dies wird im nächsten Abschnitt ausführlicher behandelt.

Ein Beispieldatenbankschema zum Speichern dieser Informationen im Back-End kann wie folgt aussehen:

Die Registrierungslogik sieht möglicherweise wie folgt aus:

Die von Ihnen gesammelten Registrierungsinformationen enthalten natürlich viel mehr Identifikationsinformationen als in diesem einfachen Szenario. Wenn Ihre App beispielsweise auf einen gesicherten Dienst wie z. B. eine für Banking zugreift, müssen Sie im Rahmen des Anmeldevorgangs identitätsnachweise und andere Dinge anfordern. Sobald alle Bedingungen erfüllt sind, wird der öffentliche Schlüssel dieses Benutzers im Back-End gespeichert und verwendet, um zu überprüfen, wenn der Benutzer das nächste Mal den Dienst verwendet.

using System;
using System.Runtime;
using System.Threading.Tasks;
using Windows.Storage.Streams;
using Windows.Security.Credentials;

static async void RegisterUser(string AccountId)
{
    var keyCredentialAvailable = await KeyCredentialManager.IsSupportedAsync();
    if (!keyCredentialAvailable)
    {
        // The user didn't set up a PIN yet
        return;
    }

    var keyCreationResult = await KeyCredentialManager.RequestCreateAsync(AccountId, KeyCredentialCreationOption.ReplaceExisting);
    if (keyCreationResult.Status == KeyCredentialStatus.Success)
    {
        var userKey = keyCreationResult.Credential;
        var publicKey = userKey.RetrievePublicKey();
        var keyAttestationResult = await userKey.GetAttestationAsync();
        IBuffer keyAttestation = null;
        IBuffer certificateChain = null;
        bool keyAttestationIncluded = false;
        bool keyAttestationCanBeRetrievedLater = false;

        keyAttestationResult = await userKey.GetAttestationAsync();
        KeyCredentialAttestationStatus keyAttestationRetryType = 0;

        switch (keyAttestationResult.Status)
        {
            case KeyCredentialAttestationStatus.Success:
                keyAttestationIncluded = true;
                keyAttestation = keyAttestationResult.AttestationBuffer;
                certificateChain = keyAttestationResult.CertificateChainBuffer;
                break;
            case KeyCredentialAttestationStatus.TemporaryFailure:
                keyAttestationRetryType = KeyCredentialAttestationStatus.TemporaryFailure;
                keyAttestationCanBeRetrievedLater = true;
                break;
            case KeyCredentialAttestationStatus.NotSupported:
                keyAttestationRetryType = KeyCredentialAttestationStatus.NotSupported;
                keyAttestationCanBeRetrievedLater = true;
                break;
        }
    }
    else if (keyCreationResult.Status == KeyCredentialStatus.UserCanceled ||
        keyCreationResult.Status == KeyCredentialStatus.UserPrefersPassword)
    {
        // Show error message to the user to get confirmation that user
        // does not want to enroll.
    }
}

Nachweis

Beim Erstellen des Schlüsselpaars gibt es auch eine Möglichkeit, die Nachweisinformationen anzufordern, die vom TPM-Chip generiert werden. Diese optionalen Informationen können als Teil des Registrierungsvorgangs an den Server gesendet werden. Der TPM-Schlüsselnachweis ist ein Protokoll, das kryptografisch nachweist, dass ein Schlüssel TPM-gebunden ist. Dieser Nachweistyp kann verwendet werden, um sicherzustellen, dass ein bestimmter kryptografischer Vorgang im TPM eines bestimmten Computers aufgetreten ist.

Wenn er den generierten RSA-Schlüssel, die Bescheinigungsanweisung und das AIK-Zertifikat empfängt, überprüft der Server die folgenden Bedingungen:

• Die AIK-Zertifikatsignatur ist gültig.
• Das AIK-Zertifikat wird mit einem vertrauenswürdigen Stamm verkettet.
• Das AIK-Zertifikat und seine Kette sind für EKU OID "2.23.133.8.3" aktiviert (Anzeigename lautet "Attestation Identity Key Certificate").
• Das AIK-Zertifikat ist zeit gültig.
• Alle ausstellenden Zertifizierungsstellenzertifikate in der Kette sind zeit gültig und werden nicht widerrufen.
• Die Attestationsanweisung wird richtig gebildet.
• Die Signatur auf dem KeyAttestation-BLOB verwendet einen öffentlichen AIK-Schlüssel.
• Der im KeyAttestation-BLOB enthaltene öffentliche Schlüssel entspricht dem öffentlichen RSA-Schlüssel, den der Client zusammen mit der Attestationsanweisung gesendet hat.

Ihre App weist dem Benutzer je nach diesen Bedingungen möglicherweise eine andere Autorisierungsstufe zu. Wenn z. B. eine dieser Prüfungen fehlschlägt, registriert er den Benutzer möglicherweise nicht, oder er schränkt möglicherweise ein, was der Benutzer tun kann.

Anmelden mit Windows Hello

Sobald der Benutzer in Ihrem System registriert ist, kann er die App verwenden. Je nach Szenario können Sie Benutzer bitten, sich zu authentifizieren, bevor sie mit der Verwendung der App beginnen können, oder sie einfach bitten, sich zu authentifizieren, sobald sie mit der Verwendung Ihrer Back-End-Dienste beginnen.

Erzwingen, dass sich der Benutzer erneut anmeldet

Für einige Szenarien möchten Sie möglicherweise, dass der Benutzer nachweisen kann, dass er oder sie die Person ist, die aktuell angemeldet ist, bevor Sie auf die App zugreifen oder manchmal eine bestimmte Aktion in Ihrer App ausführen. Bevor beispielsweise eine Banking-App den Überweisungsgeldbefehl an den Server sendet, möchten Sie sicherstellen, dass es sich um den Benutzer handelt, anstatt jemanden, der ein angemeldetes Gerät gefunden hat, versucht, eine Transaktion auszuführen. Sie können erzwingen, dass sich der Benutzer erneut in Ihrer App anmeldet, indem Sie die UserConsentVerifier-Klasse verwenden. Die folgende Codezeile erzwingt, dass der Benutzer seine Anmeldeinformationen eingibt.

Die folgende Codezeile erzwingt, dass der Benutzer seine Anmeldeinformationen eingibt.

UserConsentVerificationResult consentResult = await UserConsentVerifier.RequestVerificationAsync("userMessage");
if (consentResult.Equals(UserConsentVerificationResult.Verified))
{
    // continue
}

Sie können auch den Abfrageantwortmechanismus vom Server verwenden, der erfordert, dass ein Benutzer seinen PIN-Code oder biometrische Anmeldeinformationen eingibt. Dies hängt von dem Szenario ab, das Sie als Entwickler implementieren müssen. Dieser Mechanismus wird im folgenden Abschnitt beschrieben.

Authentifizierung im Back-End

Wenn die App versucht, auf einen geschützten Back-End-Dienst zuzugreifen, sendet der Dienst eine Abfrage an die App. Die App verwendet den privaten Schlüssel des Benutzers, um die Abfrage zu signieren und zurück an den Server zu senden. Da der Server den öffentlichen Schlüssel für diesen Benutzer gespeichert hat, verwendet er standardmäßige Krypto-APIs, um sicherzustellen, dass die Nachricht tatsächlich mit dem richtigen privaten Schlüssel signiert wurde. Auf dem Client erfolgt die Signatur durch die Windows Hello-APIs; der Entwickler hat nie Zugriff auf den privaten Schlüssel eines Benutzers.

Zusätzlich zur Überprüfung der Schlüssel kann der Dienst auch den Schlüsselnachweis überprüfen und erkennen, ob Einschränkungen hinsichtlich der Speicherung der Schlüssel auf dem Gerät auftreten. Wenn das Gerät beispielsweise TPM zum Schutz der Schlüssel verwendet, ist es sicherer als Geräte, die die Schlüssel ohne TPM speichern. Die Back-End-Logik könnte z. B. entscheiden, dass der Benutzer nur einen bestimmten Geldbetrag übertragen darf, wenn kein TPM verwendet wird, um die Risiken zu verringern.

Der Nachweis ist nur für Geräte mit einem TPM-Chip verfügbar, der Version 2.0 oder höher ist. Daher müssen Sie berücksichtigen, dass diese Informationen möglicherweise nicht auf jedem Gerät verfügbar sind.

Der Clientworkflow sieht möglicherweise wie im folgenden Diagramm aus:

Wenn die App den Dienst im Back-End aufruft, sendet der Server eine Abfrage. Die Herausforderung ist mit dem folgenden Code signiert:

var openKeyResult = await KeyCredentialManager.OpenAsync(AccountId);

if (openKeyResult.Status == KeyCredentialStatus.Success)
{
    var userKey = openKeyResult.Credential;
    var publicKey = userKey.RetrievePublicKey();
    var signResult = await userKey.RequestSignAsync(message);

    if (signResult.Status == KeyCredentialStatus.Success)
    {
        return signResult.Result;
    }
    else if (signResult.Status == KeyCredentialStatus.UserPrefersPassword)
    {

    }
}

Die erste Zeile, KeyCredentialManager.OpenAsync, fordert Windows auf, das Schlüsselhandle zu öffnen. Wenn dies erfolgreich ist, können Sie die Abfragenachricht mit der KeyCredential.RequestSignAsync-Methode signieren, wodurch Windows die PIN oder biometrische Daten des Benutzers über Windows Hello anfordert. Der Entwickler hat keinen Zugriff auf den privaten Schlüssel des Benutzers. Dies wird alle über die APIs sicher gehalten.

Die APIs fordern Windows an, die Abfrage mit dem privaten Schlüssel zu signieren. Das System fordert dann den Benutzer nach einem PIN-Code oder einer konfigurierten biometrischen Anmeldung auf. Wenn die richtigen Informationen eingegeben werden, kann das System den TPM-Chip bitten, die kryptografischen Funktionen auszuführen und die Abfrage zu signieren. (Oder verwenden Sie die Fallback-Softwarelösung, wenn kein TPM verfügbar ist). Der Client muss die signierte Abfrage zurück an den Server senden.

In diesem Sequenzdiagramm wird ein grundlegender Abfragereaktionsfluss gezeigt:

Als Nächstes muss der Server die Signatur überprüfen. Wenn Sie den öffentlichen Schlüssel anfordern und an den Server senden, der für die zukünftige Überprüfung verwendet werden soll, befindet es sich in einem ASN.1-codierten publicKeyInfo-Blob. Wenn Sie das Windows Hello-Codebeispiel auf GitHub untersuchen, sehen Sie, dass hilfsklassen zum Umschließen von Crypt32-Funktionen zum Übersetzen des ASN.1-codierten BLOB in ein CNG-Blob vorhanden sind, das häufiger verwendet wird. Das Blob enthält den Öffentlichen Schlüsselalgorithmus, der RSA und den öffentlichen RSA-Schlüssel ist.

Im Beispiel wird der Grund, warum wir das ASN.1-codierte Blob in ein CNG-Blob konvertieren, damit es mit CNG und der BCrypt-API verwendet werden kann. Wenn Sie das CNG-Blob nachschlagen, verweist es auf die zugehörige BCRYPT_KEY_BLOB Struktur. Diese API-Oberfläche kann für die Authentifizierung und Verschlüsselung in Windows-Anwendungen verwendet werden. ASN.1 ist ein dokumentierter Standard für die Kommunikation von Datenstrukturen, die serialisiert werden können, und es wird häufig in der Kryptografie für öffentliche Schlüssel und mit Zertifikaten verwendet. Aus diesem Grund werden die Informationen zu öffentlichen Schlüsseln auf diese Weise zurückgegeben. Der öffentliche Schlüssel ist ein RSA-Schlüssel; und das ist der Algorithmus, den Windows Hello beim Signiert von Daten verwendet.

Nachdem Sie über das CNG-Blob verfügen, müssen Sie die signierte Abfrage anhand des öffentlichen Schlüssels des Benutzers überprüfen. Da jeder seine eigene System- oder Back-End-Technologie verwendet, gibt es keine generische Möglichkeit, diese Logik zu implementieren. Wir verwenden SHA256 als Hashalgorithmus und Pkcs1 für SignaturePadding. Stellen Sie daher sicher, dass Sie die signierte Antwort vom Client überprüfen. Weitere Informationen finden Sie im Beispiel für eine Möglichkeit, dies auf Ihrem Server in .NET 4.6 zu tun, aber im Allgemeinen sieht es ungefähr wie folgt aus:

using (RSACng pubKey = new RSACng(publicKey))
{
    retval = pubKey.VerifyData(originalChallenge, responseSignature, HashAlgorithmName.SHA256, RSASignaturePadding.Pkcs1);
}

Wir lesen den gespeicherten öffentlichen Schlüssel, bei dem es sich um einen RSA-Schlüssel handelt. Wir überprüfen die signierte Abfragenachricht mit dem öffentlichen Schlüssel, und wenn dies auscheckt, autorisieren wir den Benutzer. Wenn der Benutzer authentifiziert ist, kann die App die Back-End-Dienste normal aufrufen.

Der vollständige Code sieht möglicherweise wie folgt aus:

using System;
using System.Runtime;
using System.Threading.Tasks;
using Windows.Storage.Streams;
using Windows.Security.Cryptography;
using Windows.Security.Cryptography.Core;
using Windows.Security.Credentials;

static async Task<IBuffer> GetAuthenticationMessageAsync(IBuffer message, String AccountId)
{
    var openKeyResult = await KeyCredentialManager.OpenAsync(AccountId);

    if (openKeyResult.Status == KeyCredentialStatus.Success)
    {
        var userKey = openKeyResult.Credential;
        var publicKey = userKey.RetrievePublicKey();
        var signResult = await userKey.RequestSignAsync(message);
        if (signResult.Status == KeyCredentialStatus.Success)
        {
            return signResult.Result;
        }
        else if (signResult.Status == KeyCredentialStatus.UserCanceled)
        {
            // Launch app-specific flow to handle the scenario 
            return null;
        }
    }
    else if (openKeyResult.Status == KeyCredentialStatus.NotFound)
    {
        // PIN reset has occurred somewhere else and key is lost.
        // Repeat key registration
        return null;
    }
    else
    {
        // Show custom UI because unknown error has happened.
        return null;
    }
}

Die Implementierung des richtigen Mechanismus für die Reaktion auf Herausforderungen liegt außerhalb des Umfangs dieses Dokuments, aber dieses Thema erfordert Aufmerksamkeit, um erfolgreich einen sicheren Mechanismus zu erstellen, um Dinge wie Replay-Angriffe oder Man-in-the-Middle-Angriffe zu verhindern.

Registrieren eines anderen Geräts

Es ist üblich, dass Benutzer mehrere Geräte mit den gleichen Apps haben, die heute installiert sind. Wie funktioniert dies bei verwendung von Windows Hello mit mehreren Geräten?

Bei Verwendung von Windows Hello erstellt jedes Gerät einen eindeutigen privaten und öffentlichen Schlüsselsatz. Dies bedeutet, dass Ihr Back-End mehrere öffentliche Schlüssel von diesem Benutzer speichern kann, wenn Sie möchten, dass ein Benutzer mehrere öffentliche Schlüssel verwenden kann. Ein Beispiel für die Tabellenstruktur finden Sie im Datenbankdiagramm im Abschnitt "Registrieren neuer Benutzer ".

Das Registrieren eines anderen Geräts entspricht fast dem erstmaligen Registrieren eines Benutzers. Sie müssen trotzdem sicherstellen, dass der Benutzer, der sich für dieses neue Gerät registriert, wirklich der Benutzer ist, den er bekommt. Dazu können Sie jeden zweistufigen Authentifizierungsmechanismus verwenden, der heute verwendet wird. Es gibt mehrere Möglichkeiten, dies auf sichere Weise zu erreichen. Alles hängt von Ihrem Szenario ab.

Wenn Sie beispielsweise den Anmeldenamen und das Kennwort weiterhin verwenden, können Sie ihn verwenden, um den Benutzer zu authentifizieren und ihn aufzufordern, eine ihrer Überprüfungsmethoden wie SMS oder E-Mail zu verwenden. Wenn Sie keinen Anmeldenamen und ein Kennwort haben, können Sie auch eines der bereits registrierten Geräte verwenden und eine Benachrichtigung an die App auf diesem Gerät senden. Die MSA-Authentifikator-App ist ein Beispiel dafür. Kurz gesagt, Sie sollten einen allgemeinen 2FA-Mechanismus verwenden, um zusätzliche Geräte für den Benutzer zu registrieren.

Der Code zum Registrieren des neuen Geräts entspricht genau dem erstmaligen Registrieren des Benutzers (aus der App).

var keyCreationResult = await KeyCredentialManager.RequestCreateAsync(
    AccountId, KeyCredentialCreationOption.ReplaceExisting);

Damit der Benutzer leichter erkennen kann, welche Geräte registriert sind, können Sie den Gerätenamen oder einen anderen Bezeichner als Teil der Registrierung senden. Dies ist beispielsweise hilfreich, wenn Sie einen Dienst in Ihrem Back-End implementieren möchten, in dem Benutzer die Registrierung von Geräten aufheben können, wenn ein Gerät verloren geht.

Verwenden mehrerer Konten in Ihrer App

Neben der Unterstützung mehrerer Geräte für ein einzelnes Konto ist es auch üblich, mehrere Konten in einer einzelnen App zu unterstützen. Beispielsweise können Sie eine Verbindung mit mehreren Twitter-Konten aus Ihrer App herstellen. Mit Windows Hello können Sie mehrere Schlüsselpaare erstellen und mehrere Konten in Ihrer App unterstützen.

Eine Möglichkeit hierzu ist das Beibehalten des Benutzernamens oder eindeutigen Bezeichners, der im vorherigen Abschnitt zum isolierten Speicher beschrieben wird. Daher speichern Sie bei jedem Erstellen eines neuen Kontos die Konto-ID im isolierten Speicher.

In der App-Benutzeroberfläche können Sie dem Benutzer entweder eines der zuvor erstellten Konten auswählen oder sich mit einem neuen registrieren. Der Fluss zum Erstellen eines neuen Kontos entspricht der zuvor beschriebenen Beschreibung. Wenn Sie ein Konto auswählen, müssen Sie die gespeicherten Konten auf dem Bildschirm auflisten. Nachdem der Benutzer ein Konto ausgewählt hat, verwenden Sie die Konto-ID, um sich bei dem Benutzer in Ihrer App anzumelden:

var openKeyResult = await KeyCredentialManager.OpenAsync(AccountId);

Der Rest des Flusses ist identisch mit der weiter oben beschriebenen. Um klar zu sein, werden alle diese Konten durch dieselbe PIN oder biometrische Geste geschützt, da sie in diesem Szenario auf einem einzelnen Gerät mit demselben Windows-Konto verwendet werden.

Migrieren eines vorhandenen Systems zu Windows Hello

In diesem kurzen Abschnitt befassen wir uns mit einem vorhandenen verpackten App- und Back-End-System, das eine Datenbank verwendet, in der der Benutzername und das Kennwort mit Hash gespeichert werden. Diese Apps sammeln Anmeldeinformationen vom Benutzer, wenn die App gestartet und verwendet wird, wenn das Back-End-System die Authentifizierungsanforderung zurückgibt.

Hier wird beschrieben, welche Teile geändert oder ersetzt werden müssen, damit Windows Hello funktioniert.

Die meisten Techniken in den früheren Abschnitten wurden bereits beschrieben. Das Hinzufügen von Windows Hello zu Ihrem vorhandenen System umfasst das Hinzufügen einiger verschiedener Flüsse im Registrierungs- und Authentifizierungsteil Ihres Codes.

Ein Ansatz besteht darin, dem Benutzer die Wahl zu geben, wann ein Upgrade durchgeführt werden soll. Nachdem sich der Benutzer bei der App angemeldet hat und Sie feststellen, dass die App und das Betriebssystem Windows Hello unterstützen können, können Sie den Benutzer fragen, ob er die Anmeldeinformationen aktualisieren möchte, um dieses moderne und sicherere System zu verwenden. Mit dem folgenden Code können Sie überprüfen, ob der Benutzer Windows Hello verwenden kann.

var keyCredentialAvailable = await KeyCredentialManager.IsSupportedAsync();

Die Benutzeroberfläche sieht möglicherweise ungefähr wie folgt aus:

Wenn sich der Benutzer entscheidet, Windows Hello zu verwenden, erstellen Sie die zuvor beschriebenen KeyCredential . Der Back-End-Registrierungsserver fügt der Datenbank den öffentlichen Schlüssel und die optionale Attestationsanweisung hinzu. Da der Benutzer bereits mit Benutzername und Kennwort authentifiziert ist, kann der Server die neuen Anmeldeinformationen mit den aktuellen Benutzerinformationen in der Datenbank verknüpfen. Das Datenbankmodell könnte mit dem zuvor beschriebenen Beispiel identisch sein.

Wenn die App die KeyCredential-Benutzer erstellen konnte, speichert sie die Benutzer-ID im isolierten Speicher, damit der Benutzer dieses Konto aus der Liste auswählen kann, sobald die App erneut gestartet wurde. Ab diesem Zeitpunkt folgt der Fluss genau den in früheren Abschnitten beschriebenen Beispielen.

Der letzte Schritt bei der Migration zu einem vollständigen Windows Hello-Szenario besteht darin, die Anmeldenamen- und Kennwortoption in der App zu deaktivieren und die gespeicherten Hashkennwörter aus Ihrer Datenbank zu entfernen.

Zusammenfassung

Windows führt eine höhere Sicherheitsstufe ein, die auch einfach in die Praxis umgesetzt werden kann. Windows Hello bietet ein neues, biometrisches Anmeldesystem, das Benutzende erkennt und Versuche, die korrekte Identifizierung zu umgehen, aktiv vereitelt. Sie kann dann mehrere Ebenen von Schlüsseln und Zertifikaten bereitstellen, die niemals außerhalb des vertrauenswürdigen Plattformmoduls offengelegt oder verwendet werden können. Darüber hinaus steht eine weitere Sicherheitsebene über die optionale Verwendung von Attestation Identity Keys und Zertifikaten zur Verfügung.

Als Entwickler können Sie diese Anleitung zum Entwerfen und Bereitstellen dieser Technologien verwenden, um Ihren verpackten Windows-App-Rollouts auf einfache Weise sichere Authentifizierung hinzuzufügen, um Apps und Back-End-Dienste zu schützen. Der erforderliche Code ist minimal und leicht verständlich. Windows behandelt die schwere Hebe.

Flexible Implementierungsoptionen ermöglichen Windows Hello das Ersetzen oder Arbeiten mit Ihrem vorhandenen Authentifizierungssystem. Die Bereitstellungserfahrung ist schmerzlos und wirtschaftlich. Für die Bereitstellung der Windows-Sicherheit ist keine zusätzliche Infrastruktur erforderlich. Mit Microsoft Hello, das in das Betriebssystem integriert ist, bietet Windows die sicherste Lösung für die Authentifizierungsprobleme, die dem modernen Entwickler gegenüberstehen.

Mission erfüllt! Sie haben gerade das Internet zu einem sichereren Ort gemacht!

Zusätzliche Ressourcen

Artikel und Beispielcode

• Übersicht über Windows Hello
• Planen einer Windows Hello for Business-Bereitstellung
• Windows Hello-UWP-Codebeispiel auf GitHub

Begriff

Begriff	Definition
AIK	Ein Nachweisidentitätsschlüssel wird verwendet, um einen solchen kryptografischen Nachweis (TPM-Schlüsselnachweis) bereitzustellen, indem die Eigenschaften des nicht migrierenden Schlüssels signiert und die Eigenschaften und Signatur für die Überprüfung an die vertrauende Seite bereitgestellt werden. Die resultierende Signatur wird als "Bescheinigungsanweisung" bezeichnet. Da die Signatur mit dem privaten AIK-Schlüssel erstellt wird , der nur im TPM verwendet werden kann, das es erstellt hat, kann die vertrauende Seite vertrauen, dass der attestierte Schlüssel wirklich nicht migriert werden kann und nicht außerhalb dieses TPM verwendet werden kann.
AIK-Zertifikat	Ein AIK-Zertifikat wird verwendet, um das Vorhandensein eines AIK in einem TPM zu bestätigen. Es wird auch verwendet, um zu bestätigen, dass andere schlüssel, die von der AIK zertifiziert wurden, von diesem bestimmten TPM stammen.
IDP AKTIVIERT	Ein IDP ist ein Identitätsanbieter. Ein Beispiel ist der IDP-Build von Microsoft für Microsoft-Konten. Jedes Mal, wenn eine Anwendung sich bei einem MSA authentifizieren muss, kann sie den MSA-IDP aufrufen.
PKI	Public Key-Infrastruktur wird häufig verwendet, um auf eine Umgebung zu verweisen, die von einer Organisation selbst gehostet wird und für das Erstellen von Schlüsseln, das Widerrufen von Schlüsseln usw. verantwortlich ist.
TPM	Das vertrauenswürdige Plattformmodul kann verwendet werden, um kryptografische öffentliche/private Schlüsselpaare so zu erstellen, dass der private Schlüssel niemals außerhalb des TPM offengelegt oder verwendet werden kann (d. a. der Schlüssel ist nicht migrierend).
TPM-Schlüsselnachweis	Ein Protokoll, das kryptografisch beweist, dass ein Schlüssel TPM-gebunden ist. Dieser Nachweistyp kann verwendet werden, um sicherzustellen, dass ein bestimmter kryptografischer Vorgang im TPM eines bestimmten Computers aufgetreten ist.

Zugehörige Themen

• Windows Hello-Anmelde-App
• Windows Hello-Anmeldedienst