Windows Hello

Ez a cikk a Windows részét képező Windows Hello technológiát ismerteti, és ismerteti, hogyan implementálhatják a fejlesztők ezt a technológiát a Windows-alkalmazások és a háttérszolgáltatások védelme érdekében. Kiemeli ezeknek a technológiáknak a speciális képességeit, amelyek segítenek csökkenteni a hagyományos hitelesítő adatokból eredő fenyegetéseket, és útmutatást nyújt ezeknek a technológiáknak a Windows-ügyfél bevezetésének részeként történő tervezéséhez és üzembe helyezéséhez.

Megjegyzés:

Ez a cikk az alkalmazásfejlesztéssel foglalkozik. A Windows Hello architektúrájáról és implementációjáról további információt a Vállalati Windows Hello üzembe helyezésének megtervezése című témakörben talál.

A WinUI-alkalmazások Windows Hello és a háttérhitelesítési szolgáltatás használatával történő létrehozásáról részletes útmutatót a Windows Hello bejelentkezési alkalmazás és a Windows Hello bejelentkezési szolgáltatással kapcsolatos cikkekben talál.

Bevezetés

Az információbiztonság alapvető feltételezése, hogy a rendszer képes azonosítani, hogy ki használja. A felhasználó azonosítása lehetővé teszi a rendszer számára, hogy eldöntse, megfelelően van-e azonosítva a felhasználó (ezt a folyamatot hitelesítésnek nevezzük), majd eldöntheti, hogy a megfelelően hitelesített felhasználó mire legyen képes (engedélyezés). Az egész világon üzembe helyezett számítógépes rendszerek túlnyomó többsége a felhasználói hitelesítő adatoktól függ a hitelesítési és engedélyezési döntések meghozatalához, ami azt jelenti, hogy ezek a rendszerek a biztonság alapjaként az újrafelhasználható, felhasználó által létrehozott jelszavaktól függnek. A gyakran idézett maxima, miszerint a hitelesítés magában foglalhatja a "valamit, amit tud, valamit, amit birtokol, vagy valami, ami önmaga", jól kiemeli a problémát: az újrafelhasználható jelszó önmagában is hitelesítési tényező, így bárki, aki ismeri a jelszót, megszemélyesítheti azt a felhasználót, aki a tulajdonosa.

A hagyományos hitelesítő adatokkal kapcsolatos problémák

Az 1960-as évek közepe óta, amikor Fernando Corbató és csapata a Massachusetts Institute of Technology-ben a jelszó bevezetése mellett állt ki, a felhasználóknak és a rendszergazdáknak a jelszavak felhasználói hitelesítéshez és engedélyezéshez való használatával kellett foglalkozniuk. Idővel a jelszótárolás és -használat korszerű állapota valamelyest továbbhaladt (például biztonságos kivonatolással és sózással), de még mindig két problémával szembesülünk. A jelszavakat könnyen klónozni lehet, és könnyen ellophatóak. Emellett a megvalósítási hibák miatt nem biztonságosak, és a felhasználók nehezen tudják kiegyensúlyozni a kényelmet és a biztonságot.

Hitelesítő adatok ellopása

A jelszavak legnagyobb kockázata egyszerű: a támadók könnyen ellophatják őket. Minden olyan hely, ahol a jelszó be van írva, feldolgozva vagy tárolva van, sebezhető. A támadók például ellophatnak jelszavak vagy kivonatok gyűjteményét egy hitelesítési kiszolgálóról úgy, hogy lehallgatják az alkalmazáskiszolgáló felé irányuló hálózati forgalmat, kártevőt ültetnek be egy alkalmazásba vagy egy eszközre, naplóznak felhasználói billentyűleütéseket egy eszközön, vagy megnézik, hogy a felhasználó mely karaktereket használja. Ezek csak a leggyakoribb támadási módszerek.

Egy másik kapcsolódó kockázat a hitelesítő adatok visszajátszása, amelyben a támadó egy nem biztonságos hálózaton való lehallgatással rögzít egy érvényes hitelesítő adatot, majd később újra lejátszja egy érvényes felhasználó megszemélyesítéséhez. A legtöbb hitelesítési protokoll (beleértve a Kerberost és az OAuthot) úgy véd a visszajátszási támadások ellen, hogy időbélyeget foglal a hitelesítési folyamatba, de ez a taktika csak a hitelesítési rendszer által kibocsátott jogkivonatot védi, nem pedig a felhasználó által a jegy megszerzéséhez megadott jelszót.

Hitelesítő adatok újrafelhasználása

Az e-mail-címek felhasználónévként való használatának gyakori megközelítése rosszabbá teszi a problémát. Egy támadó, aki sikeresen helyreállít egy felhasználónév–jelszó párot egy feltört rendszerből, ezt a párot más rendszereken is kipróbálhatja. Ez a taktika meglepően gyakran működik, hogy lehetővé tegye a támadók számára, hogy feltört rendszerből más rendszerekbe lépjenek. Az e-mail-címek felhasználónévként való használata további problémákhoz vezet, amelyeket az útmutató későbbi részében fogunk megvizsgálni.

Hitelesítő adatok problémáinak megoldása

A jelszavak által okozott problémák megoldása bonyolult. A jelszószabályzatok szigorítása önmagában nem fogja megtenni; a felhasználók egyszerűen újrahasznosíthatják, megoszthatják vagy leírhatják a jelszavakat. Bár a felhasználói oktatás kritikus fontosságú a hitelesítés biztonsága szempontjából, az oktatás önmagában sem szünteti meg a problémát.

A Windows Hello a jelszavakat erős kéttényezős hitelesítésre (2FA) cseréli a meglévő hitelesítő adatok ellenőrzésével és egy olyan eszközspecifikus hitelesítő adat létrehozásával, amelyet egy biometrikus vagy PIN-kódalapú felhasználói kézmozdulat véd.

Mi az a Windows Hello?

A Windows Hello egy, a Windowsba beépített biometrikus bejelentkezési rendszer, amely lehetővé teszi az arc, az ujjlenyomat vagy a PIN-kód használatát az eszköz zárolásának feloldásához. A hagyományos jelszavakat egy biztonságosabb és kényelmesebb módszerre cseréli. A biometrikus adatok biztonságosan vannak tárolva az eszközön, és még ha valaki ellopja is az eszközt, akkor sem férhetnek hozzá a PIN-kód vagy a biometrikus kézmozdulat nélkül. A zárolás feloldása után zökkenőmentesen elérheti alkalmazásait, adatait és szolgáltatásait.

A Windows Hello hitelesítőt Hello-nak nevezzük. Minden Hello egyedi egy adott felhasználó és eszköz számára. Nem szinkronizálja az eszközöket, és nem oszt meg adatokat kiszolgálókkal vagy alkalmazásokkal. Ha többen használják ugyanazt az eszközt, minden személynek saját Windows Hello-konfigurációt kell beállítania. Ez a konfiguráció az adott eszközön lévő hitelesítő adataikhoz van kötve. A Hello egy olyan kulcs, amely feloldja a tárolt hitelesítő adatokat, amelyeket aztán az alkalmazásokba vagy szolgáltatásokba való bejelentkezéshez használnak. Ez nem egy hitelesítő adat, hanem a hitelesítés során a második biztonsági rétegként működik.

Windows Hello-hitelesítés

A Windows Hello robusztus módot kínál az eszközök számára az egyes felhasználók felismerésére, amely a felhasználó és a kért szolgáltatás vagy adatelem közötti elérési út első részét kezeli. Miután az eszköz felismerte a felhasználót, hitelesítenie kell a felhasználót, mielőtt eldöntené, hogy hozzáférést szeretne-e adni egy kért erőforráshoz. A Windows Hello erős 2FA-t biztosít, amely teljes mértékben integrálva van a Windowsba, és lecseréli az újrafelhasználható jelszavakat egy adott eszköz kombinációjára, valamint egy biometrikus kézmozdulatra vagy PIN-kódra.

A Windows Hello azonban nem csak a hagyományos 2FA-rendszerek pótlása. Fogalmilag hasonló az intelligens kártyákhoz: a hitelesítés a sztring-összehasonlítások helyett titkosítási primitívek használatával történik, és a felhasználó kulcsanyaga biztonságos a illetéktelen hozzáférésnek ellenálló hardveren belül. A Windows Hello nem igényli az intelligens kártya üzembe helyezéséhez szükséges további infrastruktúra-összetevőket sem. A tanúsítványok kezeléséhez nincs szükség nyilvános kulcsú infrastruktúrára (PKI), ha jelenleg nincs ilyen. A Windows Hello ötvözi az intelligens kártyák fő előnyeit – a virtuális intelligens kártyák üzembehelyezési rugalmasságát és a fizikai intelligens kártyák robusztus biztonságát –, hátrányaik nélkül.

A Windows Hello működése

Amikor a felhasználó beállítja a Windows Hello-t a gépén, létrehoz egy új nyilvános és privát kulcspárt az eszközön. A platformmegbízhatósági modul (TPM) létrehozza és védi ezt a titkos kulcsot. Ha az eszköz nem rendelkezik TPM-chippel, a titkos kulcs titkosítva van, és szoftver védi. Emellett a TPM-kompatibilis eszközök olyan adatblokkot hoznak létre, amely igazolja, hogy egy kulcs TPM-hez van kötve. Ez az igazolási információ felhasználható a megoldásban annak eldöntésére, hogy a felhasználónak például más engedélyezési szint van-e megadva.

Ha engedélyezni szeretné a Windows Hello szolgáltatást egy eszközön, a felhasználónak a Microsoft Entra ID-fiókjával vagy a Windows beállításai között csatlakoztatott Microsoft-fiókkal kell rendelkeznie.

A kulcsok védelme

Minden alkalommal, amikor kulcsanyag jön létre, meg kell védeni támadás ellen. Ennek leg robusztusabb módja a speciális hardver. A hardveres biztonsági modulok (HSM-ek) hosszú múltra nyúlnak vissza a biztonsági szempontból kritikus fontosságú alkalmazások kulcsainak létrehozására, tárolására és feldolgozására. Az intelligens kártyák a HSM egy speciális típusa, valamint a megbízható számítástechnikai csoport TPM szabványának megfelelő eszközök. Ahol csak lehetséges, a Windows Hello implementációja kihasználja a beépített TPM-hardver előnyeit a kulcsok létrehozásához, tárolásához és feldolgozásához. A Windows Hello és a Windows Hello for Work azonban nem igényel beépített TPM-et.

Amikor megvalósítható, a Microsoft a TPM-hardver használatát javasolja. A TPM az ismert és potenciális támadások széles skálájával szemben nyújt védelmet, beleértve a PIN-kód brute-force támadását is. A TPM további védelmi réteget biztosít a fiókzárolás után is. Ha a TPM zárolta a kulcsanyagot, a felhasználónak alaphelyzetbe kell állítania a PIN-kódot. A PIN-kód alaphelyzetbe állítása azt jelenti, hogy a régi kulcsanyaggal titkosított összes kulcs és tanúsítvány el lesz távolítva.

Hitelesítés

Amikor egy felhasználó védett kulcsanyaghoz szeretne hozzáférni, a hitelesítési folyamat azzal kezdődik, hogy a felhasználó PIN-kódot vagy biometrikus kézmozdulatot ad meg az eszköz zárolásának feloldásához, amelyet néha "a kulcs felszabadításának" is neveznek.

Egy alkalmazás soha nem használhatja egy másik alkalmazás kulcsait, és senki sem használhatja egy másik felhasználó kulcsait. Ezeket a kulcsokat az identitásszolgáltatónak küldött kérések aláírására használják, amelyek célja a megadott erőforrásokhoz való hozzáférés megszerzése. Az alkalmazások adott API-kat használhatnak olyan műveletek lekérésére, amelyek az adott műveletekhez kulcsfontosságú anyagokat igényelnek. Az ezen API-kon keresztüli hozzáféréshez felhasználói kézmozdulaton keresztül explicit ellenőrzés szükséges, és a kulcsanyag nem érhető el a kérelmező alkalmazás számára. Ehelyett az alkalmazás egy konkrét műveletet kér, például egy adat aláírását, és a Windows Hello réteg kezeli a tényleges munkát, és visszaadja az eredményeket.

Felkészülés a Windows Hello implementálására

Most, hogy alapszintű ismeretekkel rendelkezünk a Windows Hello működéséről, nézzük meg, hogyan implementálhatjuk őket a saját alkalmazásainkban.

A Windows Hello használatával különböző forgatókönyvek implementálhatók. Például csak jelentkezzen be az alkalmazásba egy eszközön. A másik gyakori forgatókönyv a szolgáltatáson való hitelesítés. Bejelentkezési név és jelszó használata helyett a Windows Hello-t fogja használni. A következő szakaszokban bemutatunk néhány különböző forgatókönyvet, többek között azt, hogyan hitelesíthetők a szolgáltatásokon a Windows Hello használatával, és hogyan konvertálhatók meglévő felhasználónév-jelszó rendszerről Windows Hello rendszerre.

A Windows Hello implementálása

Ebben a szakaszban egy zöldmezős forgatókönyvvel kezdjük, amely nem rendelkezik meglévő hitelesítési rendszerrel, és elmagyarázzuk, hogyan implementálható a Windows Hello.

A következő szakasz bemutatja, hogyan migrálhat meglévő felhasználónév/jelszórendszerből. Azonban még ha ez a szakasz jobban érdekli, érdemes lehet áttekinteni ezt a szakaszt, hogy alapszintű ismereteket szerezzen a folyamatról és a szükséges kódról.

Új felhasználók regisztrálása

Kezdjük egy teljesen új szolgáltatással, amely a Windows Hello-t fogja használni, és egy hipotetikus új felhasználóval, aki készen áll arra, hogy regisztráljon egy új eszközön.

Az első lépés annak ellenőrzése, hogy a felhasználó használhatja-e a Windows Hello szolgáltatást. Az alkalmazás ellenőrzi a felhasználói beállításokat és a gép képességeit, hogy biztosan létrehozhat-e felhasználói azonosítókulcsokat. Ha az alkalmazás megállapítja, hogy a felhasználó még nem engedélyezte a Windows Hello szolgáltatást, az alkalmazás használata előtt kéri a felhasználót, hogy állítsa be ezt a beállítást.

A Windows Hello engedélyezéséhez a felhasználónak csak be kell állítania egy PIN-kódot a Windows beállításai között, hacsak a felhasználó nem állítja be a Házon kívül felület (OOBE) során.

Az alábbi kódsorok egyszerű módot mutatnak annak ellenőrzésére, hogy a felhasználó be van-e állítva a Windows Hello-hoz.

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

A következő lépés az, hogy információt kérjen a felhasználótól, hogy regisztráljon a szolgáltatásra. Dönthet úgy, hogy a felhasználótól utónevet, vezetéknevet, e-mail-címet és egyedi felhasználónevet kér. Az e-mail-címet használhatja egyedi azonosítóként; Önön múlik.

Ebben az esetben az e-mail-címet használjuk a felhasználó egyedi azonosítójaként. Miután a felhasználó regisztrált, érdemes megfontolnia egy érvényesítési e-mail küldését annak érdekében, hogy a cím érvényes legyen. Ez lehetővé teszi, hogy szükség esetén visszaállítsa a fiókot.

Ha a felhasználó beállította a PIN-kódját, az alkalmazás létrehozza a felhasználó KeyCredential azonosítóját. Az alkalmazás az opcionális kulcsigazolási információkat is lekéri, hogy megszerezze a titkosítási bizonyítékot, amely igazolja, hogy a kulcs a TPM-en jön létre. A rendszer elküldi a létrehozott nyilvános kulcsot és opcionálisan az igazolást a háttérkiszolgálónak a használt eszköz regisztrálásához. Minden eszközön létrehozott kulcspár egyedi lesz.

A KeyCredential létrehozásához a következő kód jelenik meg:

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

A RequestCreateAsync az a hívás, amely létrehozza a nyilvános és a titkos kulcsot. Ha az eszköz rendelkezik a megfelelő TPM-chippel, az API-k megkérik a TPM-chipet, hogy hozza létre a titkos és nyilvános kulcsot, és tárolja az eredményt; Ha nincs elérhető TPM-chip, az operációs rendszer létrehozza a kulcspárt a kódban. Az alkalmazás nem férhet hozzá közvetlenül a létrehozott titkos kulcsokhoz. A kulcspárok létrehozásának része az eredményként kapott igazolási információ is. (Az igazolással kapcsolatos további információkért tekintse meg a következő szakaszt.)

Miután létrejött a kulcspár és az igazolási információ az eszközön, a nyilvános kulcsot, az opcionális igazolási adatokat és az egyedi azonosítót (például az e-mail-címet) el kell küldeni a háttérregisztrációs szolgáltatásnak, és a háttérrendszerben kell tárolni.

Ahhoz, hogy a felhasználó több eszközön is hozzáférhessen az alkalmazáshoz, a háttérszolgáltatásnak képesnek kell lennie több kulcs tárolására ugyanahhoz a felhasználóhoz. Mivel minden kulcs egyedi minden eszközön, ezeket a kulcsokat ugyanahhoz a felhasználóhoz csatlakoztatjuk. A rendszer egy eszközazonosítót használ a kiszolgálói rész optimalizálásához a felhasználók hitelesítése során. Erről részletesebben a következő szakaszban olvashat.

Egy mintaadatbázis-séma, amely ezeket az információkat a háttérrendszerben tárolja, a következőképpen nézhet ki:

A regisztrációs logika a következőképpen nézhet ki:

Az összegyűjtött regisztrációs adatok természetesen sokkal több azonosítási információt tartalmazhatnak, mint ebben az egyszerű forgatókönyvben. Ha például az alkalmazás hozzáfér egy biztonságos szolgáltatáshoz, például egy banki szolgáltatáshoz, akkor a regisztrációs folyamat részeként személyazonosság-igazolást és egyéb dolgokat kell kérnie. Az összes feltétel teljesülése után a rendszer a felhasználó nyilvános kulcsát a háttérrendszerben tárolja, és arra használja, hogy a felhasználó legközelebb mikor használja a szolgáltatást.

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

Igazolás

A kulcspár létrehozásakor lehetőség van az igazolási adatok lekérésére is, amelyet a TPM-chip generál. Ezek az opcionális információk a regisztrációs folyamat részeként küldhetők el a kiszolgálónak. A TPM-kulcsigazolás olyan protokoll, amely kriptográfiailag bizonyítja, hogy a kulcs TPM-hez kötött. Ez az igazolási típus garantálható, hogy egy adott számítógép TPM-jében bizonyos titkosítási művelet történt.

Amikor megkapja a létrehozott RSA-kulcsot, az igazolási utasítást és az AIK-tanúsítványt, a kiszolgáló a következő feltételeket ellenőrzi:

• Az AIK-tanúsítvány aláírása érvényes.
• Az AIK-tanúsítvány egy megbízható gyökérhez kapcsolódik.
• Az AIK-tanúsítvány és annak lánca engedélyezve van a "2.23.133.8.3" EKU OID esetében (a rövid név az "Igazolási identitáskulcs-tanúsítvány").
• Az AIK-tanúsítvány időben korlátozottan érvényes.
• A láncban lévő összes hitelesítésszolgáltatói tanúsítvány érvényes, és nem vonható vissza.
• Az igazolási nyilatkozat megfelelően van kialakítva.
• A KeyAttestation blob aláírása egy AIK nyilvános kulcsot használ.
• A KeyAttestation blobban található nyilvános kulcs megegyezik az ügyfél által az igazolási utasítás mellett küldött nyilvános RSA-kulccsal.

Az alkalmazás a feltételektől függően eltérő engedélyezési szintet rendelhet a felhasználóhoz. Ha például az egyik ellenőrzés sikertelen, előfordulhat, hogy nem regisztrálja a felhasználót, vagy korlátozhatja a felhasználó által elvégezhető műveleteket.

Bejelentkezés a Windows Hello szolgáltatással

Miután regisztrálta a felhasználót a rendszerében, használhatja az alkalmazást. A forgatókönyvtől függően megkérheti a felhasználókat, hogy hitelesítsék magukat, mielőtt elkezdhetik használni az alkalmazást, vagy csak megkérheti őket a hitelesítésre, amint elkezdik használni a háttérszolgáltatásokat.

A felhasználó ismételt bejelentkezésének kényszerítése

Bizonyos esetekben előfordulhat, hogy azt szeretné, hogy a felhasználó igazolja, hogy ő az a személy, aki jelenleg bejelentkezett, mielőtt hozzáfér az alkalmazáshoz, vagy néha egy bizonyos művelet végrehajtása előtt az alkalmazáson belül. Mielőtt például egy banki alkalmazás elküldi az átutalási pénzparancsot a kiszolgálónak, meg kell győződnie arról, hogy az a felhasználó, és nem olyan személy, aki talált egy bejelentkezett eszközt, és megpróbál tranzakciót végrehajtani. A UserConsentVerifier osztály használatával kényszerítheti a felhasználót, hogy jelentkezzen be újra az alkalmazásba. Az alábbi kódsor arra kényszeríti a felhasználót, hogy adja meg a hitelesítő adatait.

Az alábbi kódsor arra kényszeríti a felhasználót, hogy adja meg a hitelesítő adatait.

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

Használhatja a kiszolgáló kihíváskezelési mechanizmusát is, amely megköveteli a felhasználótól, hogy adja meg PIN-kódját vagy biometrikus hitelesítő adatait. Ez attól függ, hogy a fejlesztőnek milyen forgatókönyvet kell implementálnia. Ezt a mechanizmust a következő szakaszban ismertetjük.

Hitelesítés a háttérrendszerben

Amikor az alkalmazás megpróbál hozzáférni egy védett háttérszolgáltatáshoz, a szolgáltatás kihívást küld az alkalmazásnak. Az alkalmazás a felhasználó titkos kulcsával írja alá a feladatot, és visszaküldi a kiszolgálónak. Mivel a kiszolgáló a felhasználó nyilvános kulcsát tárolja, standard titkosítási API-kat használ annak érdekében, hogy az üzenet valóban a megfelelő titkos kulccsal legyen aláírva. Az ügyfélen az aláírást a Windows Hello API-k végzik; a fejlesztőnek soha nem lesz hozzáférése egyetlen felhasználó titkos kulcsához sem.

A kulcsok ellenőrzése mellett a szolgáltatás ellenőrizheti a kulcsigazolást is, és észlelheti, ha a kulcsok az eszközön való tárolására vonatkozó korlátozásokra hivatkoznak. Ha például az eszköz TPM-et használ a kulcsok védelmére, biztonságosabb, mint a kulcsokat TPM nélkül tároló eszközök. A háttérlogika döntheti el például, hogy a felhasználó csak bizonyos mennyiségű pénzt utalhat át, ha a kockázatok csökkentésére nem használnak TPM-et.

Az igazolás csak a 2.0-s vagy újabb verziójú TPM-chippel rendelkező eszközök esetében érhető el. Ezért figyelembe kell vennie, hogy ezek az információk nem minden eszközön érhetők el.

Az ügyfél munkafolyamata a következő diagramhoz hasonlóan nézhet ki:

Amikor az alkalmazás meghívja a szolgáltatást a háttérrendszeren, a kiszolgáló kihívást küld. A feladat aláírása a következő kóddal történik:

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

    }
}

Az első sor, KeyCredentialManager.OpenAsync, megkéri a Windowst, hogy nyissa meg a kulcsfogantyút. Ha ez sikeres, a KeyCredential.RequestSignAsync metódussal aláírhatja a kihívást jelző üzenetet, így a Windows a Windows Hello használatával kérheti le a felhasználó PIN-kódját vagy biometrikus adatait. A fejlesztőnek nincs hozzáférése a felhasználó titkos kulcsához. Ez mind biztonságos az API-kon keresztül.

Az API-k kérik a Windowst, hogy írja alá a kihívást a titkos kulccsal. A rendszer ezután PIN-kódot vagy konfigurált biometrikus bejelentkezést kér a felhasználótól. A megfelelő információk megadásakor a rendszer megkérheti a TPM-chipet, hogy végezze el a titkosítási függvényeket, és írja alá a kihívást. (Vagy használja a tartalék szoftvermegoldást, ha nincs elérhető TPM). Az ügyfélnek vissza kell küldenie az aláírt feladatot a kiszolgálónak.

Ebben a sorrendi diagramban egy egyszerű feladat–válasz folyamat látható:

Ezután a kiszolgálónak ellenőriznie kell az aláírást. Amikor kéri a nyilvános kulcsot, és elküldi a kiszolgálónak a későbbi ellenőrzéshez, az egy ASN.1 kódolású publicKeyInfo blobban található. Ha megvizsgálja a Windows Hello kódmintáját a GitHubon, látni fogja, hogy a Crypt32 függvények burkolásához vannak segédosztályok az ASN.1 kódolású blob egy CNG-blobra való fordításához, amelyet gyakrabban használnak. A blob tartalmazza a nyilvános kulcs algoritmusát, azaz az RSA-t és az RSA nyilvános kulcsot.

A mintában azért konvertáljuk az ASN.1 kódolású blobot CNG-blobmá, hogy a CNG-vel és a BCrypt API-val is használható legyen. Ha megkeresi a CNG-blobot, az a kapcsolódó BCRYPT_KEY_BLOB struktúrára mutat. Ez az API-felület használható a Windows-alkalmazások hitelesítéséhez és titkosításához. Az ASN.1 dokumentált szabvány a szerializálható adatstruktúrák kommunikációjára, és gyakran használják nyilvános kulcsú titkosításban és tanúsítványokkal. Ezért a rendszer így adja vissza a nyilvános kulcs adatait. A nyilvános kulcs egy RSA-kulcs; és ez az az algoritmus, amelyet a Windows Hello az adatok aláírásakor használ.

Miután megkapta a CNG-blobot, ellenőriznie kell az aláírt kihívást a felhasználó nyilvános kulcsával. Mivel mindenki a saját rendszerét vagy háttértechnológiáját használja, ennek a logikának nincs általános módja. Sha256 kivonatoló algoritmust és Pkcs1-et használunk a SignaturePaddinghez, ezért győződjön meg arról, hogy ezt használja az ügyfél aláírt válaszának ellenőrzésekor. Ismét hivatkozhat a mintára, hogyan lehet ezt megtenni a szerverén a .NET 4.6-ban, de általában így fog kinézni:

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

Elolvassuk a tárolt nyilvános kulcsot, amely egy RSA-kulcs. Az aláírt kihívást jelző üzenetet a nyilvános kulccsal érvényesítjük, és ha ez megtörténik, engedélyezzük a felhasználót. Ha a felhasználó hitelesítése megtörtént, az alkalmazás a szokásos módon hívhatja meg a háttérszolgáltatásokat.

A teljes kód a következőhöz hasonló lehet:

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

A megfelelő kihívás–válasz mechanizmus megvalósítása a dokumentum hatókörén kívül esik, de ez a témakör figyelmet igényel ahhoz, hogy sikeresen létrehozhasson egy biztonságos mechanizmust, amely megakadályozza az olyan műveleteket, mint a visszajátszási támadások vagy a középen belüli ember-in-the-middle támadások.

Másik eszköz regisztrálása

Gyakori, hogy a felhasználók több olyan eszközzel rendelkeznek, amelyeken ugyanazok az alkalmazások vannak telepítve. Hogyan működik ez, ha a Windows Hello-t több eszközzel használja?

A Windows Hello használatakor minden eszköz létrehoz egy egyedi privát és nyilvános kulcskészletet. Ez azt jelenti, hogy ha azt szeretné, hogy egy felhasználó több eszközt is használhasson, a háttérrendszernek több nyilvános kulcsot kell tárolnia a felhasználótól. A táblastruktúrára példaként tekintse meg az Új felhasználók regisztrálása szakaszban található adatbázisdiagramot.

Egy másik eszköz regisztrálása majdnem ugyanaz, mint amikor először regisztrál egy felhasználót. Továbbra is gondoskodnia kell arról, hogy az új eszközre regisztráló felhasználó valóban az a felhasználó legyen, akinek állítja magát. Ezt bármely ma használt kétfaktoros hitelesítési mechanizmussal megteheti. Ezt többféleképpen is elvégezheti biztonságos módon. Minden a forgatókönyvtől függ.

Ha például továbbra is bejelentkezési nevet és jelszót használ, azzal hitelesítheti a felhasználót, és megkérheti őket, hogy használják az egyik ellenőrzési módszerüket, például SMS-t vagy e-mailt. Ha nem rendelkezik bejelentkezési névvel és jelszóval, használhatja a már regisztrált eszközök egyikét is, és értesítést küldhet az eszközön lévő alkalmazásnak. Erre példa az MSA hitelesítő alkalmazás. Röviden, egy közös 2FA-mechanizmust kell használnia a további eszközök regisztrálásához a felhasználó számára.

Az új eszköz regisztrálásához használt kód pontosan ugyanaz, mint amikor először regisztrálja a felhasználót (az alkalmazáson belülről).

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

Annak érdekében, hogy a felhasználó könnyebben felismerhesse, mely eszközök vannak regisztrálva, a regisztráció részeként elküldheti az eszköz nevét vagy egy másik azonosítót. Ez akkor is hasznos, ha például olyan szolgáltatást szeretne implementálni a háttérrendszeren, ahol a felhasználók törölhetik az eszközök regisztrációját egy eszköz elvesztésekor.

Több fiók használata az alkalmazásban

Amellett, hogy egyetlen fiókhoz több eszközt is támogat, gyakori, hogy egyetlen alkalmazásban több fiókot is támogat. Előfordulhat például, hogy több Twitter-fiókhoz csatlakozik az alkalmazáson belül. A Windows Hello használatával több kulcspárt is létrehozhat, és több fiókot is támogathat az alkalmazásban.

Ennek egyik módja az elkülönített tárterület előző szakaszában leírt felhasználónév vagy egyedi azonosító megtartása. Ezért minden alkalommal, amikor új fiókot hoz létre, a fiókazonosítót elkülönített tárolóban tárolja.

Az alkalmazás felhasználói felületén engedélyezheti a felhasználónak, hogy válasszon egyet a korábban létrehozott fiókok közül, vagy regisztráljon egy új fiókkal. Az új fiók létrehozásának folyamata megegyezik a korábban ismertetett folyamatokkal. A fiók kiválasztása a tárolt fiókok képernyőn való listázásának kérdése. Miután a felhasználó kiválasztott egy fiókot, használja a fiókazonosítót a felhasználó bejelentkeztetéséhez az alkalmazásban.

var openKeyResult = await KeyCredentialManager.OpenAsync(AccountId);

A folyamat többi része megegyezik a korábban ismertetettel. Az egyértelműség érdekében ezek a fiókok ugyanazzal a PIN-kóddal vagy biometrikus kézmozdulattal vannak védve, mivel ebben a forgatókönyvben egyetlen eszközön használják őket ugyanazzal a Windows-fiókkal.

Meglévő rendszer áttelepítése a Windows Hello-ba

Ebben a rövid szakaszban egy meglévő csomagolt alkalmazással és háttérrendszerrel foglalkozunk, amely egy olyan adatbázist használ, amely tárolja a felhasználónevet és a kivonatolt jelszót. Ezek az alkalmazások az alkalmazás indításakor gyűjtik a hitelesítő adatokat a felhasználótól, és akkor használják őket, amikor a háttérrendszer visszaadja a hitelesítési kihívást.

Itt bemutatjuk, hogy milyen darabokat kell módosítani vagy cserélni a Windows Hello működéséhez.

A korábbi szakaszokban már ismertettük a legtöbb technikát. A Windows Hello meglévő rendszerhez való hozzáadása magában foglalja a kód regisztrációs és hitelesítési részének néhány különböző folyamatának hozzáadását.

Az egyik módszer az, hogy a felhasználó kiválaszthatja, hogy mikor frissítsen. Miután a felhasználó bejelentkezett az alkalmazásba, és észlelte, hogy az alkalmazás és az operációs rendszer képes támogatni a Windows Hello szolgáltatást, megkérdezheti a felhasználót, hogy frissíteni szeretné-e a hitelesítő adatokat a modern és biztonságosabb rendszer használatára. Az alábbi kóddal ellenőrizheti, hogy a felhasználó képes-e a Windows Hello használatára.

var keyCredentialAvailable = await KeyCredentialManager.IsSupportedAsync();

A felhasználói felület a következőhöz hasonlóan nézhet ki:

Ha a felhasználó a Windows Hello használatának megkezdését választja, akkor a korábban ismertetett KeyCredential-t kell létrehoznia. A háttérregisztrációs kiszolgáló hozzáadja a nyilvános kulcsot és az opcionális igazolási utasítást az adatbázishoz. Mivel a felhasználó hitelesítése már felhasználónévvel és jelszóval történik, a kiszolgáló összekapcsolhatja az új hitelesítő adatokat az adatbázis aktuális felhasználói adataival. Az adatbázismodell megegyezhet a korábban ismertetett példával.

Ha az alkalmazás képes volt létrehozni a felhasználók KeyCredential azonosítóját, a felhasználói azonosítót elkülönített tárolóban tárolja, hogy a felhasználó az alkalmazás újraindulása után kiválaszthassa ezt a fiókot a listából. Ettől a ponttól kezdve a folyamat pontosan követi a korábbi szakaszokban leírt példákat.

A Teljes Windows Hello-forgatókönyvre való migrálás utolsó lépése az alkalmazás bejelentkezési nevének és jelszavának letiltása, valamint a tárolt kivonatolt jelszavak eltávolítása az adatbázisból.

Összefoglalás

A Windows magasabb szintű biztonságot vezet be, amely szintén egyszerű a gyakorlatban. A Windows Hello egy új biometrikus bejelentkezési rendszert biztosít, amely felismeri a felhasználót, és aktívan legyőzi a megfelelő azonosítás megkerülésére irányuló erőfeszítéseket. Ezután több olyan kulcs- és tanúsítványréteget képes szolgáltatni, amelyeket soha nem lehet felfedni vagy használni a megbízható platformmodulon kívül. Emellett egy további biztonsági réteg is elérhető az igazolási azonosítók és tanúsítványok opcionális használatával.

Fejlesztőként ezen technológiák tervezésével és üzembe helyezésével kapcsolatos útmutatással egyszerűen hozzáadhat biztonságos hitelesítést a csomagolt Windows-alkalmazások bevezetéséhez az alkalmazások és a háttérszolgáltatások védelme érdekében. A szükséges kód minimális és könnyen érthető. A Windows elvégzi a nehéz munkát.

A rugalmas megvalósítási lehetőségek lehetővé teszik, hogy a Windows Hello lecserélje vagy együttműködjön a meglévő hitelesítési rendszerrel. Az üzembe helyezési élmény fájdalommentes és gazdaságos. A Windows biztonságának telepítéséhez nincs szükség további infrastruktúrára. Mivel a Microsoft Hello beépített az operációs rendszerbe, a Windows a legbiztonságosabb megoldást kínálja a modern fejlesztővel szemben felmerülő hitelesítési problémákra.

Küldetés befejezve! Most tette biztonságosabbá az internetet!

További erőforrások

Cikkek és mintakód

• Windows Hello áttekintése
• A Windows Hello vállalati verzió üzembe helyezésének megtervezése
• Windows Hello UWP-kódminta a GitHubon

Terminológia

Időszak	Definíció
AIK	Az igazolási identitáskulcs titkosítási igazolásként (TPM-kulcs igazolása) szolgál azáltal, hogy aláírja a nem migrálható kulcs tulajdonságait, és ezeket a tulajdonságokat, valamint a hozzá tartozó aláírást a hitelesítést végző entitásnak biztosítja ellenőrzés céljából. Az eredményként kapott aláírást "igazolási nyilatkozatnak" nevezzük. Mivel az aláírás az AIK titkos kulcsával jön létre – amely csak az azt létrehozó TPM-ben használható –, a függő entitás megbízhat abban, hogy az igazolt kulcs valóban nem migrálásra alkalmas, és nem használható azon a TPM-en kívül.
AIK-tanúsítvány	Az AIK-tanúsítvány az AIK TPM-en belüli jelenlétének igazolására szolgál. Azt is tanúsítják, hogy az AIK által hitelesített egyéb kulcsok az adott TPM-ből származnak.
Belföldön lakóhelyüket elhagyni kényszerült személyek (belső menekültek)	Az IDP egy identitásszolgáltató. Ilyen például a Microsoft for Microsoft Accounts idP-buildje. Minden alkalommal, amikor egy alkalmazásnak hitelesítenie kell magát egy MSA-val, az MSA IDP-hez fordulhat.
PKI	A nyilvánoskulcs-infrastruktúrát gyakran használják arra a környezetre, amelyet maga a szervezet üzemeltet, és amely a kulcsok létrehozásáért, a kulcsok visszavonásáért stb. felelős.
TPM	A megbízható platformmodul olyan titkosítási nyilvános/titkos kulcspárok létrehozására használható, amelyek segítségével a titkos kulcs soha nem tárható fel vagy használható a TPM-en kívül (azaz a kulcs nem migrálásra alkalmas).
TPM-kulcsigazolás	Egy protokoll, amely kriptográfiailag bizonyítja, hogy a kulcs TPM-hez kötött. Ez az igazolási típus garantálható, hogy egy adott számítógép TPM-jében bizonyos titkosítási művelet történt

Kapcsolódó témakörök

• Windows Hello bejelentkezési alkalmazás
• Windows Hello bejelentkezési szolgáltatás