Windows Hello

Tento článek popisuje technologii Windows Hello, která se dodává jako součást Windows, a popisuje, jak můžou vývojáři implementovat tuto technologii za účelem ochrany svých aplikací pro Windows a back-endových služeb. Zdůrazňuje specifické možnosti těchto technologií, které pomáhají zmírnit hrozby, které vznikají z používání konvenčních přihlašovacích údajů, a poskytuje pokyny k návrhu a nasazení těchto technologií v rámci zavedení klienta Windows.

Poznámka:

Tento článek se zaměřuje na vývoj aplikací. Informace o architektuře a podrobnostech implementace Windows Hello najdete v tématu Plánování nasazení Windows Hello pro firmy.

Podrobný návod k vytvoření aplikace WinUI pomocí Windows Hello a backing authentication service najdete v článcích o přihlašovací aplikaci Windows Hello a přihlašovací službě Windows Hello .

Úvod

Základním předpokladem zabezpečení informací je, že systém dokáže identifikovat, kdo ho používá. Identifikace uživatele umožňuje systému rozhodnout, jestli je uživatel správně identifikován (proces označovaný jako ověřování), a pak rozhodnout, co by měl správně ověřený uživatel (autorizaci). Většina počítačových systémů nasazených na celém světě závisí na přihlašovacích údajích uživatelů při rozhodování o ověřování a autorizaci, což znamená, že tyto systémy závisejí na opakovaně použitelných, uživatelem vytvořených heslech jako základ pro jejich zabezpečení. Často citovaná maxima, která může zahrnovat "něco, co víte, něco, co máte, nebo něco, co jste," elegantně poukazuje na problém: opakovaně použitelné heslo je ověřovací faktor sám o sobě, takže každý, kdo zná heslo, se může vydávat za uživatele, který ho vlastní.

Problémy s tradičními přihlašovacími údaji

Od poloviny roku 1960, kdy Fernando Corbató a jeho tým v Massachusetts Institute of Technology zavedli zavedení hesla, uživatelé a správci se museli zabývat používáním hesel pro ověřování a autorizaci uživatelů. V průběhu času se stav úložiště hesel a použití poněkud zdokonalil (například se zabezpečeným hashováním a solením), ale stále čelíme dvěma problémům. Hesla se dají snadno naklonovat a snadno se ukradnou. Kromě toho mohou chyby implementace tyto systémy učinit nezabezpečenými, a uživatelé mají potíže s hledáním rovnováhy mezi pohodlím a zabezpečením.

Krádež přihlašovacích údajů

Největší riziko hesel je jednoduché: útočník je může snadno ukrást. Každé místo, kde se heslo zadává, zpracovává nebo ukládá, je zranitelné. Útočník může například ukrást kolekci hesel nebo hodnot hash z ověřovacího serveru tím, že odposlouchá síťový provoz na aplikační server, implantací malwaru do aplikace nebo zařízení, protokolováním stisknutí uživatelských kláves na zařízení nebo sledováním, které znaky uživatel zadá. Jedná se pouze o nejběžnější metody útoku.

Dalším souvisejícím rizikem je přehrání přihlašovacích údajů, kdy útočník zachytí platné přihlašovací údaje tím, že odposlouchá zabezpečenou síť a pak ho znovu přehraje, aby se zosobněl platný uživatel. Většina ověřovacích protokolů (včetně protokolu Kerberos a OAuth) chrání před útoky přehrávacími útoky zahrnutím časového razítka v procesu výměny přihlašovacích údajů, ale tato taktika chrání pouze token, který systém ověřování vydává, ne heslo, které uživatel poskytuje k získání lístku na prvním místě.

Opakované použití přihlašovacích údajů

Běžný přístup používání e-mailové adresy jako uživatelského jména zhoršuje špatný problém. Útočník, který úspěšně obnoví dvojici uživatelského jména a hesla z ohroženého systému, pak může zkusit stejný pár v jiných systémech. Tato taktika funguje překvapivě často, aby útočníci mohli přejít z kompromitovaného systému na jiné systémy. Použití e-mailových adres jako uživatelských jmen vede k dalším problémům, které prozkoumáme později v této příručce.

Řešení problémů s přihlašovacími údaji

Řešení problémů, které hesla představují, je složité. Samotné zpřísnění zásad hesel to neudělá; uživatelé mohou jenom recyklovat, sdílet nebo zapisovat hesla. I když je vzdělávání uživatelů kritické pro zabezpečení ověřování, vzdělávání samotný problém neodstraní.

Windows Hello nahrazuje hesla silným dvojúrovňovým ověřováním (2FA) ověřením existujících přihlašovacích údajů a vytvořením přihlašovacích údajů specifických pro zařízení, které chrání biometrické gesto nebo gesto uživatele založené na PIN kódu.

Co je Windows Hello?

Windows Hello je biometrický přihlašovací systém integrovaný do Windows, který umožňuje odemknout zařízení pomocí obličeje, otisku prstu nebo PIN kódu. Nahrazuje tradiční hesla bezpečnější a pohodlnější metodou. Vaše biometrická data jsou bezpečně uložena na vašem zařízení a i když někdo ukradne vaše zařízení, nemůže k nim přistupovat bez vašeho PIN kódu nebo biometrického gesta. Po odemknutí můžete bez problémů přistupovat k aplikacím, datům a službám.

Ověřovací program Windows Hello se označuje jako Hello. Každý Hello je jedinečný pro konkrétního uživatele a zařízení. Nesynchronizuje se mezi zařízeními ani nesdílí data se servery nebo aplikacemi. Pokud stejné zařízení používá více lidí, musí každá osoba nastavit vlastní konfiguraci Windows Hello. Tato konfigurace je svázaná s přihlašovacími údaji na tomto konkrétním zařízení. Hello si můžete představit jako klíč, který odemkne uložené přihlašovací údaje, které se pak použijí k přihlášení k aplikacím nebo službám. Nejedná se o samotné přihlašovací údaje, ale funguje jako druhá vrstva zabezpečení během ověřování.

Ověřování Windows Hello

Windows Hello poskytuje robustní způsob, jak zařízení rozpoznat jednotlivého uživatele, který řeší první část cesty mezi uživatelem a požadovanou službou nebo datovou položkou. Jakmile zařízení uživatele rozpozná, musí ho ještě před určením, jestli se má udělit přístup k požadovanému prostředku, ověřit ho. Windows Hello poskytuje silné 2FA, které je plně integrované do Windows a nahrazuje opakovaně použitelná hesla kombinací konkrétního zařízení a biometrickým gestem nebo PIN kódem.

Windows Hello ale není jen náhradou za tradiční systémy 2FA. Koncepčně se podobá čipovým kartám: Ověřování se provádí pomocí kryptografických primitiv namísto porovnání řetězců a klíč uživatele je zabezpečený uvnitř hardwaru odolného proti manipulaci. Windows Hello nevyžaduje pro nasazení čipových karet ani další součásti infrastruktury. Konkrétně nepotřebujete ke správě certifikátů infrastrukturu veřejných klíčů (PKI), pokud ho aktuálně nemáte. Windows Hello kombinuje hlavní výhody čipových karet – flexibilitu nasazení pro virtuální čipové karty a robustní zabezpečení fyzických čipových karet – bez jakýchkoli jejich nevýhod.

Jak funguje Windows Hello

Když uživatel na svém počítači nastaví Windows Hello, vygeneruje na zařízení novou dvojici veřejného a privátního klíče. Čip TPM ( Trusted Platform Module ) generuje a chrání tento privátní klíč. Pokud zařízení nemá čip TPM, je privátní klíč šifrovaný a chráněný softwarem. Kromě toho zařízení s povoleným čipem TPM generují blok dat, který lze použít k ověření, že klíč je svázán s čipem TPM. Tyto informace o ověření identity můžete ve vašem řešení použít k rozhodnutí, jestli má uživatel udělenou jinou úroveň autorizace.

Pokud chcete povolit Windows Hello na zařízení, musí mít uživatel účet Microsoft Entra ID nebo účet Microsoft připojený v nastavení Windows.

Jak jsou klíče chráněné

Kdykoli se vygeneruje klíčový materiál, musí být chráněn proti útoku. Nej robustnější způsob, jak to udělat, je prostřednictvím specializovaného hardwaru. Existuje dlouhá historie použití modulů hardwarového zabezpečení (HSM) ke generování, ukládání a zpracování klíčů pro důležité zabezpečení aplikací. Čipové karty jsou zvláštním typem HSM stejně jako zařízení, která splňují standard TPM od Trusted Computing Group. Kdykoli je to možné, implementace Windows Hello využívá k vygenerování, ukládání a zpracování klíčů hardwaru TPM. Windows Hello a Windows Hello for Work ale nevyžadují onboardování čipu TPM.

Kdykoli je to možné, Microsoft doporučuje používat hardware TPM. Čip TPM chrání před různými známými a potenciálními útoky, včetně útoků hrubou silou pin kódu. Čip TPM poskytuje další vrstvu ochrany i po uzamčení účtu. Pokud čip TPM uzamkne materiál klíče, uživatel musí PIN kód obnovit. Resetováním kódu PIN se odeberou všechny klíče a certifikáty zašifrované starým klíčem.

Autentizace

Když chce uživatel získat přístup k chráněnému materiálu klíče, proces ověřování začíná tím, že uživatel zadá pin kód nebo biometrické gesto k odemknutí zařízení, proces někdy označovaný jako "uvolnění klíče".

Aplikace nemůže nikdy používat klíče z jiné aplikace, ani nemůže klíče používat někdo jiný uživatel. Tyto klíče slouží k podepisování požadavků, které jsou odesílány zprostředkovateli identity nebo IDP, a které požadují přístup k určeným prostředkům. Aplikace můžou k vyžádání operací, které vyžadují klíčové materiály pro konkrétní akce, použít konkrétní rozhraní API. Přístup prostřednictvím těchto rozhraní API vyžaduje explicitní ověření gestem uživatele a klíčový materiál není vystaven žádosti o aplikaci. Místo toho aplikace požaduje konkrétní akci, jako je podepsání části dat, a vrstva Windows Hello zpracovává skutečnou práci a vrací výsledky.

Příprava k implementaci Windows Hello

Když teď máme základní znalosti o tom, jak funguje Windows Hello, pojďme se podívat, jak je implementovat v našich vlastních aplikacích.

Existují různé scénáře, které můžeme implementovat pomocí Windows Hello. Stačí se například přihlásit k aplikaci na zařízení. Dalším běžným scénářem je autentizace proti službě. Místo použití přihlašovacího jména a hesla budete používat Windows Hello. V následujících částech probereme implementaci několika různých scénářů, včetně postupu ověřování ve službách pomocí Windows Hello a převodu z existujícího systému uživatelského jména a hesla na systém Windows Hello.

Implementace Windows Hello

V této části začneme scénářem zeleného pole bez existujícího ověřovacího systému a vysvětlíme, jak implementovat Windows Hello.

V další části se dozvíte, jak migrovat ze stávajícího systému uživatelského jména a hesla. I když vás tato část zajímá víc, můžete se na tuto část podívat, abyste získali základní znalosti o procesu a požadovaném kódu.

Registrace nových uživatelů

Začneme úplně novou službou, která bude používat Windows Hello a hypotetický nový uživatel, který je připraven k registraci na novém zařízení.

Prvním krokem je ověření, že uživatel může používat Windows Hello. Aplikace ověřuje uživatelská nastavení a možnosti počítače, aby se zajistilo, že může vytvářet klíče ID uživatele. Pokud aplikace zjistí, že uživatel ještě nepovolil Windows Hello, vyzve uživatele, aby ho nastavil před použitím aplikace.

Pokud chcete povolit Windows Hello, stačí, aby uživatel v nastavení Windows nastavil PIN kód, pokud ho uživatel nenastavil během prostředí OOBE (Out of Box Experience).

Následující řádky kódu ukazují jednoduchý způsob, jak zkontrolovat, jestli je uživatel nastavený pro Windows Hello.

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

Dalším krokem je požádat uživatele o informace, aby se zaregistroval ve vaší službě. Můžete se rozhodnout požádat uživatele o křestní jméno, příjmení, e-mailovou adresu a jedinečné uživatelské jméno. E-mailovou adresu můžete použít jako jedinečný identifikátor; je na vás.

V tomto scénáři použijeme e-mailovou adresu jako jedinečný identifikátor uživatele. Jakmile se uživatel zaregistruje, měli byste zvážit odeslání ověřovacího e-mailu, abyste měli jistotu, že je adresa platná. To vám poskytne mechanismus pro resetování účtu v případě potřeby.

Pokud uživatel nastavil svůj PIN kód, aplikace vytvoří přihlašovací údaje uživatele KeyCredential. Aplikace také získá informace o ověření volitelného klíče pro získání kryptografického důkazu, že se klíč vygeneruje na čipu TPM. Vygenerovaný veřejný klíč a volitelně ověření identity se odešle na back-endový server, aby se zařízení zaregistrovalo. Každý pár klíčů vygenerovaný na každém zařízení bude jedinečný.

Kód pro vytvoření KeyCredential vypadá takto:

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

RequestCreateAsync je volání, které vytvoří veřejný a privátní klíč. Pokud má zařízení správný čip TPM, rozhraní API požádá čip TPM o vytvoření privátního a veřejného klíče a uložení výsledku; Pokud není k dispozici žádný čip TPM, operační systém vytvoří dvojici klíčů v kódu. Aplikace nemá přístup k vytvořeným privátním klíčům přímo. Součástí vytváření párů klíčů jsou také výsledné atestační informace. (Další informace o ověření identity najdete v další části.)

Po vytvoření páru klíčů a informací o ověření identity v zařízení musí být veřejný klíč, volitelné informace o ověření identity a jedinečný identifikátor (například e-mailová adresa) odeslány do služby registrace back-endu a uloženy v back-endu.

Aby mohl uživatel přistupovat k aplikaci na více zařízeních, musí být back-endová služba schopná uložit více klíčů pro stejného uživatele. Protože každý klíč je pro každé zařízení jedinečný, uložíme všechny tyto klíče připojené ke stejnému uživateli. Identifikátor zařízení slouží k optimalizaci části serveru při ověřování uživatelů. O tom mluvíme podrobněji v další části.

Ukázkové schéma databáze pro uložení těchto informací v back-endu může vypadat takto:

Logika registrace může vypadat takto:

Shromážděné informace o registraci můžou samozřejmě obsahovat mnohem více identifikačních informací, než do tohoto jednoduchého scénáře zahrneme. Pokud například vaše aplikace přistupuje k zabezpečené službě, jako je například služba pro bankovnictví, budete muset v rámci procesu registrace požádat o doklad o identitě a další věci. Po splnění všech podmínek se veřejný klíč tohoto uživatele uloží do back-endu a použije se k ověření při příštím použití služby.

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.
    }
}

Osvědčení

Při vytváření páru klíčů existuje také možnost vyžádat si informace o ověření identity, které vygeneruje čip TPM. Tyto volitelné informace je možné odeslat na server v rámci procesu registrace. Ověření klíče TPM je protokol, který kryptograficky prokáže, že klíč je vázaný na čip TPM. Tento typ ověření identity lze použít k zajištění, že v čipu TPM konkrétního počítače došlo k určité kryptografické operaci.

Když obdrží vygenerovaný klíč RSA, příkaz ověření identity a certifikát AIK, server ověří následující podmínky:

• Podpis certifikátu AIK je platný.
• Certifikát AIK vede až k důvěryhodnému kořenu.
• Pro identifikátor EKU OID 2.23.133.8.3 je povolený certifikát AIK a jeho řetěz (popisný název je "Certifikát klíče identity ověření identity").
• Certifikát AIK je platný.
• Všechny vystavující certifikáty certifikační autority v řetězci jsou časově platné a nezrušené.
• Prohlášení o osvědčení je správně vytvořeno.
• Podpis v objektu blob KeyAttestation používá veřejný klíč AIK.
• Veřejný klíč obsažený v objektu blob KeyAttestation odpovídá veřejnému klíči RSA, který klient odeslal spolu s příkazem ověření identity.

V závislosti na těchto podmínkách může aplikace uživateli přiřadit jinou úroveň autorizace. Pokud například některá z těchto kontrol selže, nemusí zaregistrovat uživatele nebo může omezit, co může uživatel dělat.

Přihlášení pomocí Windows Hello

Jakmile je uživatel zaregistrovaný ve vašem systému, může aplikaci používat. V závislosti na scénáři můžete uživatele požádat, aby se ověřili, než můžou začít používat aplikaci, nebo je požádat, aby se ověřili, jakmile začnou používat vaše back-endové služby.

Vynutit, aby se uživatel znovu přihlásil

V některých scénářích můžete chtít, aby uživatel prokázal, že je osoba, která je aktuálně přihlášená, před přístupem k aplikaci nebo někdy před provedením určité akce uvnitř vaší aplikace. Například před odesláním příkazu převodu peněz na server chcete zajistit, aby se jedná o uživatele, a ne o někoho, kdo našel přihlášené zařízení, a pokusil se provést transakci. Uživatele můžete vynutit, aby se v aplikaci znovu přihlásil pomocí třídy UserConsentVerifier . Následující řádek kódu vynutí, aby uživatel zadal své přihlašovací údaje.

Následující řádek kódu vynutí, aby uživatel zadal své přihlašovací údaje.

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

Můžete také použít mechanismus výzvy a odpovědi serveru, který vyžaduje, aby uživatel zadal svůj kód PIN nebo biometrické údaje. Závisí na scénáři, který musíte implementovat jako vývojář. Tento mechanismus je popsaný v následující části.

Ověřování v back-endu

Když se aplikace pokusí o přístup k chráněné back-endové službě, odešle aplikaci výzvu. Aplikace používá privátní klíč od uživatele k podepsání výzvy a odešle ho zpět na server. Vzhledem k tomu, že server uložil veřejný klíč pro tohoto uživatele, používá standardní kryptografická rozhraní API, aby se ujistil, že zpráva byla skutečně podepsána správným privátním klíčem. V klientovi podepisování provádí rozhraní API Windows Hello; vývojář nikdy nebude mít přístup k privátnímu klíči uživatele.

Kromě kontroly klíčů může služba také zkontrolovat osvědčení klíčů a zjistit, zda existují nějaká omezení ohledně toho, jak jsou klíče uložené v zařízení. Pokud například zařízení k ochraně klíčů používá čip TPM, je bezpečnější než zařízení, která klíče ukládají bez čipu TPM. Logika back-endu se může například rozhodnout, že uživatel může převést jenom určitou částku peněz, když se k omezení rizik nepoužívá žádný čip TPM.

Ověření identity je dostupné jenom pro zařízení s čipem TPM verze 2.0 nebo novějším. Proto je potřeba vzít v úvahu, že tyto informace nemusí být dostupné na všech zařízeních.

Pracovní postup klienta může vypadat jako následující graf:

Když aplikace volá službu na back-endu, server odešle výzvu. Výzva se podepíše následujícím kódem:

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)
    {

    }
}

První řádek KeyCredentialManager.OpenAsync požádá Windows, aby otevřel popisovač klíče. Pokud je to úspěšné, můžete podepsat výzvu pomocí metody KeyCredential.RequestSignAsync , což způsobí, že Systém Windows požádá o PIN kód nebo biometrické údaje uživatele prostřednictvím Windows Hello. Vývojář nebude mít přístup k privátnímu klíči uživatele. Všechno je zabezpečené prostřednictvím rozhraní API.

Rozhraní API požadují, aby systém Windows podepisuje výzvu pomocí privátního klíče. Systém pak požádá uživatele o kód PIN nebo nakonfigurované biometrické přihlášení. Po zadání správných informací může systém požádat čip TPM, aby provedl kryptografické funkce a podepisoval výzvu. (Nebo použijte náhradní softwarové řešení, pokud není k dispozici žádný čip TPM). Klient musí podepsanou výzvu odeslat zpět na server.

V tomto sekvenčním diagramu je znázorněn základní tok výzvy – odpověď:

V dalším kroku musí server podpis ověřit. Když požádáte o veřejný klíč a odešlete ho na server, který se má použít pro budoucí ověření, nachází se v objektu blob PUBLICKeyInfo s kódováním ASN.1. Pokud prozkoumáte ukázku kódu Windows Hello na GitHubu, uvidíte, že existují pomocné třídy pro zabalení funkcí Crypt32 k překladu objektu blob s kódováním ASN.1 do objektu blob CNG, který se běžně používá. Objekt blob obsahuje algoritmus veřejného klíče, což je RSA a veřejný klíč RSA.

V ukázce je důvod, proč objekt blob s kódováním ASN.1 převádíme na objekt blob CNG, aby ho bylo možné použít s CNG a rozhraním BCrypt API. Pokud vyhledáte objekt blob CNG, bude odkazovat na související strukturu BCRYPT_KEY_BLOB. Tato plocha rozhraní API se dá použít k ověřování a šifrování v aplikacích pro Windows. ASN.1 je zdokumentovaný standard pro komunikaci datových struktur, které je možné serializovat, a běžně se používá v kryptografii veřejného klíče a s certifikáty. Právě proto se informace o veřejném klíči vrátí tímto způsobem. Veřejný klíč je klíč RSA; a to je algoritmus, který Windows Hello používá, když podepíše data.

Jakmile máte CNG blob, musíte ověřit podepsanou výzvu proti veřejnému klíči uživatele. Vzhledem k tomu, že každý používá vlastní systém nebo back-endovou technologii, neexistuje žádný obecný způsob implementace této logiky. Jako hashový algoritmus používáme SHA256 a Pkcs1 pro SignaturePadding, proto se ujistěte, že je to, co používáte při ověřování podepsané odpovědi od klienta. Znovu si projděte ukázku, jak to udělat na serveru v .NET 4.6, ale obecně bude vypadat přibližně takto:

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

Přečteme uložený veřejný klíč, což je klíč RSA. Ověříme podepsanou výzvu pomocí veřejného klíče a pokud se tato kontrola ověří, autorizujeme uživatele. Pokud je uživatel ověřený, může aplikace volat back-endové služby jako obvykle.

Celý kód může vypadat přibližně takto:

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;
    }
}

Implementace správného mechanismu pro reakci na výzvy přesahuje rámec tohoto dokumentu, ale toto téma vyžaduje pozornost, aby bylo možné úspěšně vytvořit zabezpečený mechanismus, který zabrání útokům typu přehrání nebo útokům typu man-in-the-middle.

Registrace jiného zařízení

Je běžné, že uživatelé mají dnes nainstalované více zařízení se stejnými aplikacemi. Jak to funguje při používání Windows Hello s více zařízeními?

Při použití Windows Hello vytvoří každé zařízení jedinečnou sadu privátních a veřejných klíčů. To znamená, že pokud chcete, aby uživatel mohl používat více zařízení, musí být back-end schopen uložit několik veřejných klíčů od tohoto uživatele. Příklad struktury tabulky najdete v diagramu databáze v části Registrace nových uživatelů .

Registrace jiného zařízení je téměř stejná jako registrace uživatele poprvé. Stále musíte zajistit, aby uživatel, který se registruje k tomuto novému zařízení, byl skutečně uživatelem, kterému tvrdí, že je. Můžete to udělat pomocí jakéhokoli mechanismu dvojúrovňového ověřování, který se používá dnes. Existuje několik způsobů, jak toho dosáhnout bezpečným způsobem. Vše závisí na vašem scénáři.

Pokud například stále používáte přihlašovací jméno a heslo, můžete ho použít k ověření uživatele a požádat ho, aby používal některou z metod ověření, jako je SMS nebo e-mail. Pokud nemáte přihlašovací jméno a heslo, můžete také použít jedno z již registrovaných zařízení a odeslat oznámení aplikaci na daném zařízení. Příkladem je ověřovací aplikace MSA. Stručně řečeno, měli byste použít společný mechanismus 2FA k registraci dalších zařízení pro uživatele.

Kód pro registraci nového zařízení je úplně stejný jako první registrace uživatele (z aplikace).

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

Aby uživatel snadněji rozpoznal, která zařízení jsou zaregistrovaná, můžete v rámci registrace odeslat název zařízení nebo jiný identifikátor. To je také užitečné, například pokud chcete implementovat službu na vašem back-endu, kde uživatelé můžou zrušit registraci zařízení, když dojde ke ztrátě zařízení.

Použití více účtů v aplikaci

Kromě podpory více zařízení pro jeden účet je také běžné podporovat více účtů v jedné aplikaci. Možná se například připojujete k několika účtům Twitteru z vaší aplikace. Ve Windows Hello můžete vytvořit několik párů klíčů a podporovat více účtů v aplikaci.

Jedním ze způsobů, jak to udělat, je zachování uživatelského jména nebo jedinečného identifikátoru popsaného v předchozí části izolovaného úložiště. Proto při každém vytvoření nového účtu uložíte ID účtu v izolovaném úložišti.

V uživatelském rozhraní aplikace povolíte uživateli buď zvolit jeden z dříve vytvořených účtů, nebo se zaregistrovat pomocí nového účtu. Tok vytvoření nového účtu je stejný, jak je popsáno dříve. Vybrat účet znamená zobrazit uložené účty na obrazovce. Jakmile uživatel vybere účet, pomocí ID účtu se přihlaste k uživateli ve vaší aplikaci:

var openKeyResult = await KeyCredentialManager.OpenAsync(AccountId);

Zbytek toku je stejný, jak je popsáno výše. Aby bylo jasné, jsou všechny tyto účty chráněné stejným pin kódem nebo biometrickým gestem, protože v tomto scénáři se používají na jednom zařízení se stejným účtem Windows.

Migrace existujícího systému do Windows Hello

V této krátké části budeme řešit existující zabalenou aplikaci a back-endový systém, který používá databázi, která ukládá uživatelské jméno a hashované heslo. Tyto aplikace shromažďují přihlašovací údaje od uživatele při spuštění aplikace a používají je, když back-endový systém vrátí ověřovací výzvu.

Tady popíšeme, jaké části je potřeba změnit nebo nahradit, aby windows Hello fungoval.

Většinu technik jsme už popsali v předchozích částech. Přidání Windows Hello do stávajícího systému zahrnuje přidání několika různých toků do části registrace a ověřování v kódu.

Jedním z přístupů je umožnit uživateli zvolit, kdy se má upgradovat. Jakmile se uživatel přihlásí k aplikaci a zjistíte, že aplikace a operační systém podporují Windows Hello, můžete uživatele požádat, jestli chce upgradovat přihlašovací údaje, aby používaly tento moderní a bezpečnější systém. Pomocí následujícího kódu můžete zkontrolovat, jestli má uživatel možnost používat Windows Hello.

var keyCredentialAvailable = await KeyCredentialManager.IsSupportedAsync();

Uživatelské rozhraní může vypadat přibližně takto:

Pokud se uživatel rozhodne začít používat Windows Hello, vytvoříte dříve popsané přihlašovací údaje KeyCredential . Back-endový registrační server přidá do databáze veřejný klíč a volitelný příkaz ověření identity. Vzhledem k tomu, že uživatel je již ověřený pomocí uživatelského jména a hesla, může server propojit nové přihlašovací údaje s aktuálními informacemi o uživateli v databázi. Model databáze může být stejný jako v předchozím příkladu.

Pokud aplikace mohla vytvořit uživatele KeyCredential, uloží ID uživatele v izolovaném úložišti, aby uživatel mohl tento účet vybrat ze seznamu, jakmile se aplikace znovu spustí. Od tohoto okamžiku se tok přesně řídí příklady popsanými v předchozích částech.

Posledním krokem při migraci na úplný scénář Windows Hello je zakázání přihlašovacího jména a hesla v aplikaci a odebrání uložených hashovaných hesel z databáze.

Shrnutí

Systém Windows zavádí vyšší úroveň zabezpečení, která se také snadno zavádí do praxe. Windows Hello poskytuje nový biometrický přihlašovací systém, který rozpozná uživatele a aktivně porazí úsilí o obejití správné identifikace. Pak může dodávat více vrstev klíčů a certifikátů, které se nikdy nedají odhalit nebo použít mimo modul důvěryhodné platformy. Kromě toho je k dispozici další vrstva zabezpečení prostřednictvím volitelného použití klíčů a certifikátů pro ověření identity.

Jako vývojář můžete použít tyto pokyny k návrhu a nasazení těchto technologií a snadno přidat zabezpečené ověřování do zabalených zavedení aplikací pro Windows za účelem ochrany aplikací a back-endových služeb. Požadovaný kód je minimální a snadno pochopitelný. Systém Windows zvládne náročné úkoly.

Flexibilní možnosti implementace umožňují windows Hello nahradit stávající systém ověřování nebo pracovat s ním. Zkušenost s nasazením je bezbolestná a ekonomická. K nasazení zabezpečení Systému Windows není nutná žádná další infrastruktura. Systém Windows s integrovaným operačním systémem Microsoft Hello nabízí nejbezpečnější řešení problémů s ověřováním, které čelí modernímu vývojáři.

Mise splněna! Právě jste udělali internet bezpečnější místo!

Dodatečné zdroje

Články a vzorový kód

• Přehled Windows Hello
• Plánování nasazení Windows Hello pro firmy
• Ukázka kódu Windows Hello pro UPW na GitHubu

Terminologie

termín	Definice
AIK	Klíč ověření identity se používá k poskytnutí takového kryptografického důkazu (ověření klíče TPM) podpisem vlastností nemigrovatelného klíče a poskytnutím vlastností a podpisu spoléhající se straně k ověření. Výsledný podpis se nazývá "prohlášení o ověření identity". Vzhledem k tomu, že se podpis vytvoří pomocí privátního klíče AIK, který se dá použít jenom v čipu TPM, který ho vytvořil, může předávající strana důvěřovat tomu, že potvrzený klíč je skutečně nemigrovatelný a nedá se použít mimo tento čip TPM.
Certifikát AIK	Certifikát AIK se používá k ověření přítomnosti AIK v TPM. Používá se také k ověření, že další klíče certifikované protokolem AIK pocházejí z tohoto konkrétního čipu TPM.
IDP	IDP je zprostředkovatel identity. Příkladem je platforma IDP od Microsoftu pro účty Microsoft. Pokaždé, když se aplikace potřebuje ověřit pomocí MSA, může volat IDP MSA.
Infrastruktura veřejných klíčů	Infrastruktura veřejných klíčů se běžně používá k nasměrování na prostředí hostované samotnou organizací a zodpovídá za vytváření klíčů, odvolání klíčů atd.
Čip TPM	Modul důvěryhodné platformy lze použít k vytvoření párů kryptografických veřejných a privátních klíčů takovým způsobem, že privátní klíč nelze nikdy odhalit nebo použít mimo čip TPM (to znamená, že klíč není možné migrovat).
Ověření identity klíče TPM	Protokol, který kryptograficky prokáže, že klíč je svázaný s TPM. Tento typ ověření identity lze použít k zajištění, že v čipu TPM konkrétního počítače došlo k určité kryptografické operaci.

Související témata

• přihlašovací aplikace Windows Hello
• přihlašovací služba Windows Hello