Windows Hello

Artikel ini menjelaskan teknologi Windows Hello baru yang dikirimkan sebagai bagian dari sistem operasi Windows 10 dan Windows 11 dan membahas bagaimana pengembang dapat menerapkan teknologi ini untuk melindungi aplikasi Platform Windows Universal (UWP) dan layanan backend mereka. Ini menyoroti kemampuan khusus dari teknologi ini yang membantu mengurangi ancaman yang muncul dari penggunaan kredensial konvensional dan memberikan panduan tentang merancang dan menyebarkan teknologi ini sebagai bagian dari peluncuran Windows 10 dan Windows 11.

Perhatikan bahwa artikel ini berfokus pada pengembangan aplikasi. Untuk informasi tentang arsitektur dan detail implementasi Windows Hello, lihat Panduan Windows Hello di TechNet.

Untuk sampel kode lengkap, lihat sampel kode Windows Hello di GitHub.

Untuk panduan langkah demi langkah dalam membuat aplikasi UWP menggunakan Windows Hello dan layanan autentikasi backing, lihat Windows Hello aplikasi masuk dan Windows Hello artikel layanan masuk.

1 Pendahuluan

Asumsi mendasar tentang keamanan informasi adalah bahwa sistem dapat mengidentifikasi siapa yang menggunakannya. Mengidentifikasi pengguna memungkinkan sistem untuk memutuskan apakah pengguna diidentifikasi dengan tepat (proses yang dikenal sebagai autentikasi), dan kemudian memutuskan apa yang dapat dilakukan pengguna yang diautentikasi dengan benar (otorisasi). Sebagian besar sistem komputer yang disebarkan di seluruh dunia bergantung pada kredensial pengguna untuk membuat keputusan autentikasi dan otorisasi, yang berarti bahwa sistem ini bergantung pada kata sandi yang dapat digunakan kembali dan dibuat pengguna sebagai dasar untuk keamanan mereka. Maksimal yang dikutip oft bahwa autentikasi dapat melibatkan "sesuatu yang Anda tahu, sesuatu yang Anda miliki, atau sesuatu yang Anda" menyoroti masalah dengan rapi: kata sandi yang dapat digunakan kembali adalah faktor autentikasi dengan sendirinya, sehingga siapa pun yang tahu kata sandi dapat meniru pengguna yang memilikinya.

1.1 Masalah dengan kredensial tradisional

Sejak pertengahan 1960-an, ketika Fernando Corbató dan timnya di Massachusetts Institute of Technology memperjuangkan pengenalan kata sandi, pengguna dan administrator harus berurusan dengan penggunaan kata sandi untuk autentikasi dan otorisasi pengguna. Seiring waktu, status seni untuk penyimpanan kata sandi dan penggunaan agak canggih (dengan hashing dan salting yang aman, misalnya), tetapi kita masih dihadapkan dengan dua masalah. Kata sandi mudah dikloning dan mudah dicuri. Selain itu, kesalahan implementasi dapat membuatnya tidak aman, dan pengguna mengalami kesulitan menyeimbangkan kenyamanan dan keamanan.

1.1.1 Pencurian kredensial

Risiko kata sandi terbesar sederhana: penyerang dapat mencurinya dengan mudah. Setiap tempat kata sandi dimasukkan, diproses, atau disimpan rentan. Misalnya, penyerang dapat mencuri kumpulan kata sandi atau hash dari server autentikasi dengan menguping lalu lintas jaringan ke server aplikasi, dengan menanamkan malware dalam aplikasi atau di perangkat, dengan mencatat penekanan tombol pengguna di perangkat, atau dengan menonton untuk melihat karakter mana yang diketik pengguna. Ini hanya metode serangan yang paling umum.

Risiko terkait lainnya adalah pemutaran ulang kredensial, di mana penyerang menangkap kredensial yang valid dengan menguping pada jaringan yang tidak aman, dan kemudian memutarnya kembali nanti untuk meniru pengguna yang valid. Sebagian besar protokol autentikasi (termasuk Kerberos dan OAuth) melindungi dari serangan pemutaran ulang dengan menyertakan stempel waktu dalam proses pertukaran kredensial, tetapi taktik itu hanya melindungi token yang menjadi masalah sistem autentikasi, bukan kata sandi yang disediakan pengguna untuk mendapatkan tiket terlebih dahulu.

1.1.2 Penggunaan kembali kredensial

Pendekatan umum menggunakan alamat email karena nama pengguna membuat masalah buruk menjadi lebih buruk. Penyerang yang berhasil memulihkan pasangan nama pengguna-kata sandi dari sistem yang disusupi kemudian dapat mencoba pasangan yang sama pada sistem lain. Taktik ini bekerja secara mengejutkan sering kali untuk memungkinkan penyerang untuk memulai dari sistem yang disusupi ke sistem lain. Penggunaan alamat email sebagai nama pengguna menyebabkan masalah tambahan yang akan kita jelajahi nanti dalam panduan ini.

1.2 Memecahkan masalah kredensial

Memecahkan masalah yang diposisikan kata sandi itu sulit. Memperketat kebijakan kata sandi saja tidak akan melakukannya; pengguna hanya dapat mendaur ulang, berbagi, atau menuliskan kata sandi. Meskipun pendidikan pengguna sangat penting untuk keamanan autentikasi, pendidikan saja juga tidak menghilangkan masalah.

Windows Hello mengganti kata sandi dengan autentikasi dua faktor (2FA) yang kuat dengan memverifikasi kredensial yang ada dan dengan membuat kredensial khusus perangkat yang dilindungi oleh gerakan pengguna berbasis biometrik atau PIN. 

2 Apa itu Windows Hello?

Windows Hello adalah nama yang diberikan Microsoft ke sistem masuk biometrik baru yang disertakan dalam Windows 10 dan Windows 11. Karena dibangun langsung ke dalam sistem operasi, Windows Hello memungkinkan identifikasi wajah atau sidik jari untuk membuka kunci perangkat pengguna. Autentikasi terjadi ketika pengguna memasok pengidentifikasi biometrik uniknya untuk mengakses kredensial khusus perangkat, yang berarti bahwa penyerang yang mencuri perangkat tidak dapat masuk ke sana kecuali penyerang tersebut memiliki PIN. Penyimpanan kredensial aman Windows melindungi data biometrik pada perangkat. Dengan menggunakan Windows Hello untuk membuka kunci perangkat, pengguna yang berwenang mendapatkan akses ke semua pengalaman, aplikasi, data, situs web, dan layanan Windows-nya.

Pengautentikasi Windows Hello dikenal sebagai Hello. Halo unik untuk kombinasi perangkat individu dan pengguna tertentu. Ini tidak menjelajah di seluruh perangkat, tidak dibagikan dengan server atau aplikasi panggilan, dan tidak dapat dengan mudah diekstraksi dari perangkat. Jika beberapa pengguna berbagi perangkat, setiap pengguna perlu menyiapkan akunnya sendiri. Setiap akun mendapatkan Halo unik untuk perangkat tersebut. Anda dapat menganggap Halo sebagai token yang dapat Anda gunakan untuk membuka (atau merilis) kredensial tersimpan. Hello itu sendiri tidak mengautentikasi Anda ke aplikasi atau layanan, tetapi merilis kredensial yang dapat. Dengan kata lain, Halo bukan kredensial pengguna tetapi merupakan faktor kedua untuk proses autentikasi.

2.1 autentikasi Windows Hello

Windows Hello menyediakan cara yang kuat bagi perangkat untuk mengenali pengguna individual, yang membahas bagian pertama dari jalur antara pengguna dan layanan atau item data yang diminta. Setelah perangkat mengenali pengguna, perangkat masih harus mengautentikasi pengguna sebelum menentukan apakah akan memberikan akses ke sumber daya yang diminta. Windows Hello menyediakan 2FA kuat yang sepenuhnya terintegrasi ke Windows dan mengganti kata sandi yang dapat digunakan kembali dengan kombinasi perangkat tertentu, dan gerakan biometrik atau PIN.

Windows Hello bukan hanya pengganti sistem 2FA tradisional. Ini secara konseptual mirip dengan kartu pintar: autentikasi dilakukan dengan menggunakan primitif kriptografi alih-alih perbandingan string, dan materi kunci pengguna aman di dalam perangkat keras yang tahan perubahan. Windows Hello juga tidak memerlukan komponen infrastruktur tambahan yang diperlukan untuk penyebaran kartu pintar. Secara khusus, Anda tidak memerlukan Infrastruktur Kunci Umum (PKI) untuk mengelola sertifikat, jika Saat ini Anda tidak memilikinya. Windows Hello menggabungkan keuntungan utama dari kartu pintar—fleksibilitas penyebaran untuk kartu pintar virtual dan keamanan yang kuat untuk kartu pintar fisik—tanpa kelemahannya.

2.2 Cara kerja Windows Hello

Ketika pengguna mengatur Windows Hello di komputernya, itu menghasilkan pasangan kunci publik-privat baru pada perangkat. Modul platform tepercaya (TPM) menghasilkan dan melindungi kunci privat ini. Jika perangkat tidak memiliki chip TPM, kunci privat dienkripsi dan dilindungi oleh perangkat lunak. Selain itu perangkat berkemampuan TPM menghasilkan blok data yang dapat digunakan untuk membuktikan bahwa kunci terikat ke TPM. Informasi pengesahan ini dapat digunakan dalam solusi Anda untuk memutuskan apakah pengguna diberikan tingkat otorisasi yang berbeda misalnya.

Untuk mengaktifkan Windows Hello di perangkat, pengguna harus memiliki akun Azure Active Directory atau Akun Microsoft yang tersambung di pengaturan Windows.

2.2.1 Bagaimana kunci dilindungi

Setiap kali materi kunci dihasilkan, bahan tersebut harus dilindungi dari serangan. Cara paling kuat untuk melakukan ini adalah melalui perangkat keras khusus. Ada riwayat panjang menggunakan modul keamanan perangkat keras (HSM) untuk menghasilkan, menyimpan, dan memproses kunci untuk aplikasi penting keamanan. Kartu pintar adalah jenis HSM khusus, seperti halnya perangkat yang sesuai dengan standar TPM Grup Komputasi Tepercaya. Sedapat mungkin, implementasi Windows Hello memanfaatkan perangkat keras TPM onboard untuk menghasilkan, menyimpan, dan memproses kunci. Namun, Windows Hello dan Windows Hello untuk Pekerjaan tidak memerlukan TPM onboard.

Setiap kali memungkinkan, Microsoft merekomendasikan penggunaan perangkat keras TPM. TPM melindungi dari berbagai serangan yang diketahui dan potensial, termasuk serangan brute force PIN. TPM juga memberikan lapisan perlindungan tambahan setelah penguncian akun. Ketika TPM telah mengunci materi kunci, pengguna harus mengatur ulang PIN. Mengatur ulang PIN berarti bahwa semua kunci dan sertifikat yang dienkripsi dengan materi kunci lama akan dihapus.

2.2.2 Autentikasi

Ketika pengguna ingin mengakses materi kunci yang dilindungi, proses autentikasi dimulai dengan pengguna memasukkan PIN atau gerakan biometrik untuk membuka kunci perangkat, proses yang terkadang disebut "melepaskan kunci".

Aplikasi tidak pernah dapat menggunakan kunci dari aplikasi lain, seseorang juga tidak dapat menggunakan kunci dari pengguna lain. Kunci ini digunakan untuk menandatangani permintaan yang dikirim ke IdP atau IDP, mencari akses ke sumber daya tertentu. Aplikasi dapat menggunakan API tertentu untuk meminta operasi yang memerlukan materi kunci untuk tindakan tertentu. Akses melalui API ini memang memerlukan validasi eksplisit melalui gerakan pengguna, dan materi kunci tidak terekspos ke aplikasi yang meminta. Sebaliknya, aplikasi meminta tindakan tertentu seperti menandatangani sepotong data, dan lapisan Windows Hello menangani pekerjaan aktual dan mengembalikan hasilnya.

2.3 Bersiap untuk menerapkan Windows Hello

Sekarang kita memiliki pemahaman dasar tentang cara kerja Windows Hello, mari kita lihat cara menerapkannya dalam aplikasi kita sendiri.

Ada berbagai skenario yang dapat kita terapkan menggunakan Windows Hello. Misalnya, cukup masuk ke aplikasi Anda di perangkat. Skenario umum lainnya adalah mengautentikasi terhadap layanan. Alih-alih menggunakan nama dan kata sandi masuk, Anda akan menggunakan Windows Hello. Dalam bab berikut, kita akan membahas penerapan beberapa skenario yang berbeda, termasuk cara mengautentikasi terhadap layanan Anda dengan Windows Hello, dan cara mengonversi dari sistem nama pengguna/kata sandi yang ada ke sistem Windows Hello.

3 Menerapkan Windows Hello

Dalam bab ini, kita mulai dengan skenario greenfield tanpa sistem autentikasi yang ada, dan kami menjelaskan cara menerapkan Windows Hello.

Bagian berikutnya mencakup cara bermigrasi dari sistem nama pengguna/kata sandi yang ada. Namun, bahkan jika bab itu lebih menarik minat Anda, Anda mungkin ingin melihat melalui bab ini untuk mendapatkan pemahaman dasar tentang proses dan kode yang diperlukan.

3.1 Mendaftarkan pengguna baru

Kami mulai dengan layanan baru yang akan menggunakan Windows Hello, dan pengguna baru hipotetis yang siap mendaftar di perangkat baru.

Langkah pertama adalah memverifikasi bahwa pengguna dapat menggunakan Windows Hello. Aplikasi ini memverifikasi pengaturan pengguna dan kemampuan mesin untuk memastikannya dapat membuat kunci ID pengguna. Jika aplikasi menentukan pengguna belum mengaktifkan Windows Hello, aplikasi akan meminta pengguna untuk menyiapkannya sebelum menggunakan aplikasi.

Untuk mengaktifkan Windows Hello, pengguna hanya perlu menyiapkan PIN di pengaturan Windows, kecuali pengguna mengaturnya selama Out of Box Experience (OOBE).

Baris kode berikut menunjukkan cara sederhana untuk memeriksa apakah pengguna disiapkan untuk Windows Hello.

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

Langkah selanjutnya adalah meminta informasi kepada pengguna untuk mendaftar dengan layanan Anda. Anda dapat memilih untuk meminta nama depan, nama belakang, alamat email, dan nama pengguna yang unik kepada pengguna. Anda dapat menggunakan alamat email sebagai pengidentifikasi unik; Terserah padamu.

Dalam skenario ini, kami menggunakan alamat email sebagai pengidentifikasi unik untuk pengguna. Setelah pengguna mendaftar, Anda harus mempertimbangkan untuk mengirim email validasi untuk memastikan alamat tersebut valid. Ini memberi Anda mekanisme untuk mengatur ulang akun jika perlu.

Jika pengguna telah menyiapkan PIN-nya, aplikasi akan membuat KeyCredential pengguna. Aplikasi ini juga mendapatkan informasi pengesahan kunci opsional untuk memperoleh bukti kriptografi bahwa kunci dihasilkan pada TPM. Kunci publik yang dihasilkan, dan secara opsional pengesahan, dikirim ke server backend untuk mendaftarkan perangkat yang digunakan. Setiap pasangan kunci yang dihasilkan pada setiap perangkat akan unik.

Kode untuk membuat KeyCredential terlihat seperti ini:

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

RequestCreateAsync adalah bagian yang membuat kunci publik dan privat. Jika perangkat memiliki chip TPM yang tepat, API akan meminta chip TPM untuk membuat kunci privat dan publik dan menyimpan hasilnya; jika tidak ada chip TPM yang tersedia, OS akan membuat pasangan kunci dalam kode. Tidak ada cara bagi aplikasi untuk mengakses kunci privat yang dibuat secara langsung. Bagian dari pembuatan pasangan kunci juga merupakan informasi Pengesahan yang dihasilkan. (Lihat bagian berikutnya untuk informasi selengkapnya tentang pengesahan.)

Setelah pasangan kunci dan informasi pengesahan dibuat pada perangkat, kunci publik, informasi pengesahan opsional, dan pengidentifikasi unik (seperti alamat email) perlu dikirim ke layanan pendaftaran backend dan disimpan di backend.

Untuk memungkinkan pengguna mengakses aplikasi di beberapa perangkat, layanan backend harus dapat menyimpan beberapa kunci untuk pengguna yang sama. Karena setiap kunci unik untuk setiap perangkat, kami akan menyimpan semua kunci ini yang terhubung ke pengguna yang sama. Pengidentifikasi perangkat digunakan untuk membantu mengoptimalkan bagian server saat mengautentikasi pengguna. Kami berbicara tentang ini secara lebih rinci di bab berikutnya.

Contoh skema database untuk menyimpan informasi ini di backend mungkin terlihat seperti ini:

Windows Hello skema database sampel

Logika pendaftaran mungkin terlihat seperti ini:

logika pendaftaran Windows Hello

Informasi pendaftaran yang Anda kumpulkan tentu saja mencakup lebih banyak informasi identifikasi daripada yang kami sertakan dalam skenario sederhana ini. Misalnya, jika aplikasi Anda mengakses layanan aman seperti layanan untuk perbankan, Anda harus meminta bukti identitas dan hal-hal lain sebagai bagian dari proses pendaftaran. Setelah semua kondisi terpenuhi, kunci umum pengguna ini akan disimpan di backend dan digunakan untuk memvalidasi saat pengguna menggunakan layanan berikutnya.

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;

        if (keyAttestationResult.Status == KeyCredentialAttestationStatus.Success)
        {
            keyAttestationIncluded = true;
            keyAttestation = keyAttestationResult.AttestationBuffer;
            certificateChain = keyAttestationResult.CertificateChainBuffer;
        }
        else if (keyAttestationResult.Status == KeyCredentialAttestationStatus.TemporaryFailure)
        {
            keyAttestationRetryType = KeyCredentialAttestationStatus.TemporaryFailure;
            keyAttestationCanBeRetrievedLater = true;
        }
        else if (keyAttestationResult.Status == KeyCredentialAttestationStatus.NotSupported)
        {
            keyAttestationRetryType = KeyCredentialAttestationStatus.NotSupported;
            keyAttestationCanBeRetrievedLater = true;
        }
    }
    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.
    }
}

3.1.1 Pengesahan

Saat membuat pasangan kunci, ada juga opsi untuk meminta informasi pengesahan, yang dihasilkan oleh chip TPM. Informasi opsional ini dapat dikirim ke server sebagai bagian dari proses pendaftaran. Pengesahan kunci TPM adalah protokol yang secara kriptografi membuktikan bahwa kunci terikat TPM. Jenis pengesahan ini dapat digunakan untuk menjamin bahwa operasi kriptografi tertentu terjadi dalam TPM komputer tertentu.

Ketika menerima kunci RSA yang dihasilkan, pernyataan pengesahan, dan sertifikat AIK, server memverifikasi kondisi berikut:

  • Tanda tangan sertifikat AIK valid.
  • Sertifikat AIK berantai hingga akar tepercaya.
  • Sertifikat AIK dan rantainya diaktifkan untuk EKU OID "2.23.133.8.3" (nama yang ramah adalah "Sertifikat Kunci Identitas Pengesahan").
  • Sertifikat AIK valid waktunya.
  • Semua sertifikat CA yang diterbitkan dalam rantai valid waktu dan tidak dicabut.
  • Pernyataan pengesahan dibentuk dengan benar.
  • Tanda tangan pada blob KeyAttestation menggunakan kunci umum AIK.
  • Kunci publik yang disertakan dalam blob KeyAttestation cocok dengan kunci RSA publik yang dikirim klien bersama pernyataan pengesahan.

Aplikasi Anda mungkin menetapkan tingkat otorisasi yang berbeda kepada pengguna, tergantung pada kondisi ini. Misalnya, jika salah satu pemeriksaan ini gagal, pemeriksaan mungkin tidak mendaftarkan pengguna atau mungkin membatasi apa yang dapat dilakukan pengguna.

3.2 Masuk dengan Windows Hello

Setelah pengguna terdaftar di sistem Anda, dia dapat menggunakan aplikasi. Bergantung pada skenarionya, Anda dapat meminta pengguna untuk mengautentikasi sebelum mereka dapat mulai menggunakan aplikasi atau hanya meminta mereka untuk mengautentikasi setelah mereka mulai menggunakan layanan backend Anda.

3.3 Memaksa pengguna untuk masuk lagi

Untuk beberapa skenario, Anda mungkin ingin pengguna membuktikan bahwa dia adalah orang yang saat ini masuk, sebelum mengakses aplikasi atau terkadang sebelum melakukan tindakan tertentu di dalam aplikasi Anda. Misalnya, sebelum aplikasi perbankan mengirim perintah transfer uang ke server, Anda ingin memastikannya adalah pengguna, daripada seseorang yang menemukan perangkat yang masuk, mencoba melakukan transaksi. Anda dapat memaksa pengguna untuk masuk lagi di aplikasi Anda dengan menggunakan kelas UserConsentVerifier . Baris kode berikut akan memaksa pengguna untuk memasukkan kredensial mereka.

Baris kode berikut akan memaksa pengguna untuk memasukkan kredensial mereka.

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

Tentu saja, Anda juga dapat menggunakan mekanisme respons tantangan dari server, yang mengharuskan pengguna untuk memasukkan kode PIN atau kredensial biometriknya. Ini tergantung pada skenario yang perlu Anda terapkan sebagai pengembang. Mekanisme ini dijelaskan di bagian berikut.

3.4 Autentikasi di backend

Saat aplikasi mencoba mengakses layanan backend yang dilindungi, layanan mengirimkan tantangan ke aplikasi. Aplikasi ini menggunakan kunci privat dari pengguna untuk menandatangani tantangan dan mengirimkannya kembali ke server. Karena server telah menyimpan kunci publik untuk pengguna tersebut, server menggunakan API kripto standar untuk memastikan pesan tersebut memang ditandatangani dengan kunci privat yang benar. Pada klien, penandatanganan dilakukan oleh API Windows Hello; pengembang tidak akan pernah memiliki akses ke kunci privat pengguna mana pun.

Selain memeriksa kunci, layanan juga dapat memeriksa pengesahan kunci dan membedakan apakah ada batasan yang dipanggil tentang bagaimana kunci disimpan di perangkat. Misalnya, ketika perangkat menggunakan TPM untuk melindungi kunci, perangkat lebih aman daripada perangkat yang menyimpan kunci tanpa TPM. Logika backend dapat memutuskan, misalnya, bahwa pengguna hanya diizinkan untuk mentransfer sejumlah uang ketika tidak ada TPM yang digunakan untuk mengurangi risiko.

Pengesahan hanya tersedia untuk perangkat dengan chip TPM versi 2.0 atau yang lebih baru. Oleh karena itu, Anda perlu mempertimbangkan bahwa informasi ini mungkin tidak tersedia di setiap perangkat.

Alur kerja klien mungkin terlihat seperti bagan berikut ini:

Windows Hello alur kerja klien

Ketika aplikasi memanggil layanan di backend, server mengirimkan tantangan. Tantangan ditandatangani dengan kode berikut:

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

    }
}

Baris pertama, KeyCredentialManager.OpenAsync, akan meminta OS untuk membuka handel kunci. Jika itu berhasil dilakukan, Anda dapat menandatangani pesan tantangan dengan metode KeyCredential.RequestSignAsync akan memicu OS untuk meminta PIN atau biometrik pengguna melalui Windows Hello. Tidak ada waktu pengembang akan memiliki akses ke kunci privat pengguna. Ini semua tetap aman melalui API.

API meminta OS untuk menandatangani tantangan dengan kunci privat. Sistem kemudian meminta kode PIN atau log masuk biometrik yang dikonfigurasi kepada pengguna. Ketika informasi yang benar dimasukkan, sistem dapat meminta chip TPM untuk melakukan fungsi kriptografi dan menandatangani tantangan. (Atau gunakan solusi perangkat lunak fallback, jika tidak ada TPM yang tersedia). Klien harus mengirim tantangan yang ditandatangani kembali ke server.

Alur respons tantangan dasar ditampilkan dalam diagram urutan ini:

Windows Hello respons tantangan

Selanjutnya, server harus memvalidasi tanda tangan. Ketika Anda meminta kunci publik dan mengirimkannya ke server untuk digunakan untuk validasi di masa mendatang, kunci tersebut berada dalam blob publicKeyInfo yang dikodekan ASN.1. Jika Anda melihat sampel kode Windows Hello di GitHub, Anda akan melihat bahwa ada kelas pembantu untuk membungkus fungsi Crypt32 untuk menerjemahkan blob yang dikodekan ASN.1 ke blob CNG, yang lebih umum digunakan. Blob berisi algoritma kunci publik, yaitu RSA, dan kunci umum RSA.

Dalam sampel, alasan kami mengonversi blob yang dikodekan ASN.1 ke blob CNG adalah agar dapat digunakan dengan CNG (/windows/desktop/SecCNG/cng-portal) dan BCrypt API. Jika Anda mencari blob CNG, itu akan mengarahkan Anda ke struktur BCRYPT_KEY_BLOB terkait. Permukaan API ini dapat digunakan untuk autentikasi dan enkripsi di aplikasi Windows. ASN.1 adalah standar terdokumen untuk mengkomunikasikan struktur data yang dapat diserialisasikan, dan umumnya digunakan dalam kriptografi kunci publik dan dengan sertifikat. Itu sebabnya informasi kunci publik dikembalikan dengan cara ini. Kunci publik adalah kunci RSA; dan itulah algoritma yang Windows Hello gunakan saat menandatangani data.

Setelah Anda memiliki blob CNG, Anda perlu memvalidasi tantangan yang ditandatangani terhadap kunci umum pengguna. Karena semua orang menggunakan sistem atau teknologi backend-nya sendiri, tidak ada cara umum untuk mengimplementasikan logika ini. Kami menggunakan SHA256 sebagai algoritma hash dan Pkcs1 untuk SignaturePadding, jadi pastikan itulah yang Anda gunakan saat memvalidasi respons yang ditandatangani dari klien. Sekali lagi, lihat sampel untuk cara melakukannya di server Anda di .NET 4.6, tetapi secara umum akan terlihat seperti ini:

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

Kami membaca kunci umum yang disimpan, yang merupakan kunci RSA. Kami memvalidasi pesan tantangan yang ditandatangani dengan kunci umum dan jika ini dicek keluar, kami mengotorisasi pengguna. Jika pengguna diautentikasi, aplikasi dapat memanggil layanan backend seperti biasa.

Kode lengkap mungkin terlihat seperti berikut ini:

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

Menerapkan mekanisme tantangan-respons yang benar berada di luar cakupan dokumen ini, tetapi topik ini adalah sesuatu yang membutuhkan perhatian agar berhasil membuat mekanisme yang aman untuk mencegah hal-hal seperti serangan pemutaran ulang atau serangan man-in-the-middle.

3.5 Mendaftarkan perangkat lain

Saat ini, adalah umum bagi pengguna untuk memiliki beberapa perangkat dengan aplikasi yang sama terinstal. Bagaimana cara kerjanya saat menggunakan Windows Hello dengan beberapa perangkat?

Saat menggunakan Windows Hello setiap perangkat akan membuat set kunci privat dan publik yang unik. Ini berarti bahwa jika Anda ingin pengguna dapat menggunakan beberapa perangkat, backend Anda harus dapat menyimpan beberapa kunci publik dari pengguna ini. Lihat diagram database di bagian 2.1 untuk contoh struktur tabel.

Mendaftarkan perangkat lain hampir sama dengan mendaftarkan pengguna untuk pertama kalinya. Anda masih perlu memastikan pengguna yang mendaftar untuk perangkat baru ini benar-benar pengguna yang diklaimnya. Anda dapat melakukannya dengan mekanisme autentikasi dua faktor apa pun yang digunakan saat ini. Ada beberapa cara untuk mencapainya dengan cara yang aman. Itu semua tergantung pada skenario Anda.

Misalnya, jika Anda masih menggunakan nama login dan kata sandi, Anda dapat menggunakannya untuk mengautentikasi pengguna dan meminta mereka untuk menggunakan salah satu metode verifikasi mereka seperti SMS atau email. Jika Anda tidak memiliki nama login dan kata sandi, Anda juga dapat menggunakan salah satu perangkat yang sudah terdaftar dan mengirim pemberitahuan ke aplikasi di perangkat tersebut. Aplikasi pengautentikasi MSA adalah contoh dari ini. Singkatnya, Anda harus menggunakan mekanisme 2FA umum untuk mendaftarkan perangkat tambahan untuk pengguna.

Kode untuk mendaftarkan perangkat baru persis sama dengan mendaftarkan pengguna untuk pertama kalinya (dari dalam aplikasi).

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

Untuk memudahkan pengguna mengenali perangkat mana yang terdaftar, Anda dapat memilih untuk mengirim nama perangkat atau pengidentifikasi lain sebagai bagian dari pendaftaran. Ini juga berguna, misalnya, jika Anda ingin menerapkan layanan di backend Anda di mana pengguna dapat membatalkan pendaftaran perangkat saat perangkat hilang.

3.6 Menggunakan beberapa akun di aplikasi Anda

Selain mendukung beberapa perangkat untuk satu akun, juga umum untuk mendukung beberapa akun dalam satu aplikasi. Misalnya, mungkin Anda terhubung ke beberapa akun Twitter dari dalam aplikasi Anda. Dengan Windows Hello, Anda dapat membuat beberapa pasangan kunci dan mendukung beberapa akun di dalam aplikasi Anda.

Salah satu cara untuk melakukan ini adalah dengan menyimpan nama pengguna atau pengidentifikasi unik yang dijelaskan dalam bab sebelumnya dalam penyimpanan yang terisolasi. Oleh karena itu, setiap kali Anda membuat akun baru, Anda menyimpan ID akun di penyimpanan yang terisolasi.

Di UI aplikasi, Anda mengizinkan pengguna untuk memilih salah satu akun yang dibuat sebelumnya atau mendaftar dengan akun baru. Alur pembuatan akun baru sama seperti yang dijelaskan sebelumnya. Memilih akun adalah masalah mencantumkan akun yang disimpan di layar. Setelah pengguna memilih akun, gunakan ID akun untuk masuk ke pengguna di aplikasi Anda:

var openKeyResult = await KeyCredentialManager.OpenAsync(AccountId);

Sisa alur sama seperti yang dijelaskan sebelumnya. Agar jelas, semua akun ini dilindungi oleh PIN atau gerakan biometrik yang sama karena dalam skenario ini mereka digunakan pada satu perangkat dengan Akun Windows yang sama.

4 Memigrasikan Sistem yang Ada ke Windows Hello

Di bagian singkat ini, kita akan membahas aplikasi Platform Windows Universal yang ada dan sistem backend yang menggunakan database yang menyimpan nama pengguna dan kata sandi yang di-hash. Aplikasi ini mengumpulkan kredensial dari pengguna saat aplikasi dimulai dan menggunakannya saat sistem backend mengembalikan tantangan autentikasi.

Di sini, kami akan menjelaskan bagian apa yang perlu diubah atau diganti untuk membuat Windows Hello berfungsi.

Kami telah menjelaskan sebagian besar teknik di bab-bab sebelumnya. Menambahkan Windows Hello ke sistem yang ada melibatkan penambahan beberapa alur yang berbeda di bagian pendaftaran dan autentikasi kode Anda.

Salah satu pendekatannya adalah membiarkan pengguna memilih kapan harus meningkatkan. Setelah pengguna masuk ke aplikasi dan Anda mendeteksi bahwa aplikasi dan OS mampu mendukung Windows Hello, Anda dapat bertanya kepada pengguna apakah dia ingin meningkatkan kredensial untuk menggunakan sistem modern dan lebih aman ini. Anda dapat menggunakan kode berikut untuk memeriksa apakah pengguna mampu menggunakan Windows Hello.

var keyCredentialAvailable = await KeyCredentialManager.IsSupportedAsync();

UI mungkin terlihat seperti ini:

ui Windows Hello

Jika pengguna memilih untuk mulai menggunakan Windows Hello, Anda membuat KeyCredential yang dijelaskan sebelumnya. Server pendaftaran backend menambahkan kunci publik dan pernyataan pengesahan opsional ke database. Karena pengguna sudah diautentikasi dengan nama pengguna dan kata sandi, server dapat menautkan kredensial baru ke informasi pengguna saat ini dalam database. Model database bisa sama dengan contoh yang dijelaskan sebelumnya.

Jika aplikasi dapat membuat pengguna KeyCredential, aplikasi menyimpan ID pengguna di penyimpanan terisolasi sehingga pengguna dapat memilih akun ini dari daftar setelah aplikasi dimulai lagi. Dari titik ini, alur persis mengikuti contoh yang dijelaskan dalam bab sebelumnya.

Langkah terakhir dalam bermigrasi ke skenario Windows Hello penuh adalah menonaktifkan opsi nama masuk dan kata sandi di aplikasi dan menghapus kata sandi hash yang disimpan dari database Anda.

5 Ringkasan

Windows 10 dan Windows 11 memperkenalkan tingkat keamanan yang lebih tinggi yang juga mudah dipraktikkan. Windows Hello menyediakan sistem masuk biometrik baru yang mengenali pengguna dan secara aktif mengalahkan upaya untuk menghindari identifikasi yang tepat. Kemudian dapat memberikan beberapa lapisan kunci dan sertifikat yang tidak pernah dapat diungkapkan atau digunakan di luar modul platform tepercaya. Selain itu, lapisan keamanan lebih lanjut tersedia melalui penggunaan opsional kunci identitas pengesahan dan sertifikat.

Sebagai pengembang, Anda dapat menggunakan panduan ini tentang desain dan penyebaran teknologi ini untuk dengan mudah menambahkan autentikasi aman ke peluncuran Windows 10 dan Windows 11 Anda untuk melindungi aplikasi dan layanan backend. Kode yang diperlukan minimal dan mudah dipahami. Windows 10 dan Windows 11 melakukan pengangkatan berat.

Opsi implementasi yang fleksibel memungkinkan Windows Hello untuk mengganti atau bekerja bersama sistem autentikasi yang ada. Pengalaman penyebaran tidak menyakitkan dan ekonomis. Tidak diperlukan infrastruktur tambahan untuk menyebarkan keamanan Windows 10 dan Windows 11. Dengan Microsoft Hello bawaan sistem operasi, Windows 10 dan Windows 11 menawarkan solusi paling aman untuk masalah autentikasi yang dihadapi pengembang modern.

Misi tercapai! Anda baru saja membuat Internet tempat yang lebih aman!

6 Sumber Daya

6.1 Artikel dan kode sampel

6.2 Terminologi

Istilah Definisi
AIK Kunci identitas pengesahan digunakan untuk memberikan bukti kriptografi (pengesahan kunci TPM) seperti itu dengan menandatangani properti kunci yang tidak dapat dimigrasikan dan memberikan properti dan tanda tangan kepada pihak yang mengandalkan untuk verifikasi. Tanda tangan yang dihasilkan disebut "pernyataan pengesahan." Karena tanda tangan dibuat menggunakan kunci privat AIK—yang hanya dapat digunakan dalam TPM yang membuatnya—pihak yang mengandalkan dapat mempercayai bahwa kunci yang dibuktikan benar-benar tidak dapat dimigrasikan dan tidak dapat digunakan di luar TPM tersebut.
Sertifikat AIK Sertifikat AIK digunakan untuk membuktikan keberadaan AIK dalam TPM. Ini juga digunakan untuk membuktikan bahwa kunci lain yang disertifikasi oleh AIK berasal dari TPM tertentu.
IDP IDP adalah IdP. Contohnya adalah build IDP oleh Microsoft untuk Akun Microsoft. Setiap kali aplikasi perlu mengautentikasi dengan MSA, aplikasi dapat memanggil MSA IDP.
PKI Infrastruktur kunci umum umumnya digunakan untuk menunjuk ke lingkungan yang dihosting oleh organisasi itu sendiri dan bertanggung jawab untuk membuat kunci, mencabut kunci, dll.
TPM Modul platform tepercaya dapat digunakan untuk membuat pasangan kunci publik/privat kriptografi sedemikian rupa sehingga kunci privat tidak pernah dapat diungkapkan atau digunakan di luar TPM (artinya, kuncinya tidak dapat dimigrasikan).
Pengesahan Kunci TPM Protokol yang secara kriptografi membuktikan bahwa kunci terikat TPM. Jenis pengesahan ini dapat digunakan untuk menjamin bahwa operasi kriptografi tertentu terjadi dalam TPM komputer tertentu