Windows Hello
Artikel ini menjelaskan teknologi Windows Hello yang dikirim sebagai bagian dari Windows dan membahas bagaimana pengembang dapat menerapkan teknologi ini untuk melindungi aplikasi Windows dan layanan backend mereka. Ini menyoroti kemampuan spesifik 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 klien Windows.
Catatan
Artikel ini berfokus pada pengembangan aplikasi. Untuk informasi tentang arsitektur dan detail implementasi Windows Hello, lihat Merencanakan penyebaran Windows Hello untuk Bisnis.
Untuk panduan langkah demi langkah tentang membuat aplikasi WinUI menggunakan Windows Hello dan layanan autentikasi cadangan, lihat artikel aplikasi masuk Windows Hello dan layanan masuk Windows Hello.
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), lalu memutuskan apa yang harus dapat dilakukan oleh pengguna yang diautentikasi dengan benar (otorisasi). Sebagian besar sistem komputer yang disebarkan ke 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. Maxim 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 semuanya dengan sendirinya, sehingga siapa pun yang tahu kata sandi dapat meniru pengguna yang memilikinya.
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 dan penggunaan kata sandi memiliki agak maju (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.
Pencurian kredensial
Risiko terbesar kata sandi 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 kunci pengguna pada 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 jaringan yang tidak aman, dan kemudian memutar ulang 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 masalah sistem autentikasi, bukan kata sandi yang disediakan pengguna untuk mendapatkan tiket di tempat pertama.
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 melakukan springboard dari sistem yang disusupi ke sistem lain. Penggunaan alamat email sebagai nama pengguna menyebabkan masalah tambahan yang akan kita jelajahi nanti dalam panduan ini.
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 menulis kata sandi. Meskipun pendidikan pengguna sangat penting untuk keamanan autentikasi, pendidikan saja tidak menghilangkan masalah juga.
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.
Apa itu Windows Hello?
Windows Hello adalah nama yang diberikan Microsoft ke sistem masuk biometrik baru yang terpasang di Windows. 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 dalamnya 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 Windows, aplikasi, data, situs web, dan layanan Windows-nya.
Pengautentikasi Windows Hello dikenal sebagai Halo. Halo unik untuk kombinasi perangkat individual 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 Hello sebagai token yang dapat Anda gunakan untuk membuka kunci (atau merilis) kredensial tersimpan. Halo 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.
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 kartu pintar—fleksibilitas penyebaran untuk kartu pintar virtual dan keamanan yang kuat untuk kartu pintar fisik—tanpa kekurangannya.
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 pada perangkat, pengguna harus memiliki akun ID Microsoft Entra atau Akun Microsoft yang tersambung di pengaturan Windows.
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. Jika memungkinkan, 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.
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 yang ditentukan. Aplikasi dapat menggunakan API tertentu untuk meminta operasi yang memerlukan materi utama 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.
Bersiap untuk mengimplementasikan Windows Hello
Sekarang setelah 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 masuk dan kata sandi, Anda akan menggunakan Windows Hello. Di bagian 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.
Menerapkan Windows Hello
Di bagian 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 bagian itu lebih menarik minat Anda, Anda mungkin ingin melihat melalui bagian ini untuk mendapatkan pemahaman dasar tentang proses dan kode yang diperlukan.
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 komputer 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 Pengalaman Di Luar Kotak (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 panggilan 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 bagian berikutnya.
Contoh skema database untuk menyimpan informasi ini di backend mungkin terlihat seperti ini:
Logika pendaftaran mungkin terlihat seperti ini:
Informasi pendaftaran yang Anda kumpulkan tentu saja dapat mencakup lebih banyak informasi identifikasi daripada yang kami sertakan dalam skenario sederhana ini. Misalnya, jika aplikasi Anda mengakses layanan aman seperti untuk perbankan, Anda harus meminta bukti identitas dan hal-hal lain sebagai bagian dari proses pendaftaran. Setelah semua kondisi terpenuhi, kunci publik 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;
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.
}
}
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 mudah diingat adalah "Sertifikat Kunci Identitas Pengesahan").
- Sertifikat AIK valid waktunya.
- Semua sertifikat CA yang diterbitkan dalam rantai valid waktu dan tidak dicabut.
- Pernyataan pengesahan terbentuk 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, mungkin tidak mendaftarkan pengguna atau mungkin membatasi apa yang dapat dilakukan pengguna.
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.
Paksa 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
}
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.
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 memang ditandatangani dengan kunci privat yang benar. Pada klien, penandatanganan dilakukan oleh WINDOWS Hello API; 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 memperhitungkan bahwa informasi ini mungkin tidak tersedia di setiap perangkat.
Alur kerja klien mungkin terlihat seperti bagan berikut:
Saat 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 Windows untuk membuka handel kunci. Jika berhasil, Anda dapat menandatangani pesan tantangan dengan metode KeyCredential.RequestSignAsync , yang menyebabkan Windows 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 Windows untuk menandatangani tantangan dengan kunci privat. Sistem kemudian meminta pengguna untuk kode PIN atau log masuk biometrik yang dikonfigurasi. 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 ditunjukkan dalam diagram urutan ini:
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 memeriksa 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 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 mengomunikasikan struktur data yang dapat diserialisasikan, dan umumnya digunakan dalam kriptografi kunci publik dan dengan sertifikat. Itulah sebabnya informasi kunci publik dikembalikan dengan cara ini. Kunci publik adalah kunci RSA; dan itulah algoritma yang digunakan Windows Hello saat menandatangani data.
Setelah Anda memiliki blob CNG, Anda perlu memvalidasi tantangan yang ditandatangani terhadap kunci publik pengguna. Karena semua orang menggunakan sistem atau teknologi backend-nya sendiri, tidak ada cara umum untuk menerapkan 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 publik 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.
Mendaftarkan perangkat lain
Pengguna umum memiliki beberapa perangkat dengan aplikasi yang sama yang terinstal saat ini. 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 Mendaftarkan pengguna baru untuk contoh struktur tabel.
Mendaftarkan perangkat lain hampir sama dengan mendaftarkan pengguna untuk pertama kalinya. Anda masih perlu memastikan bahwa pengguna yang mendaftar untuk perangkat baru ini benar-benar pengguna yang mereka klaim. 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 sama persis 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 Tempat pengguna dapat membatalkan pendaftaran perangkat saat perangkat hilang.
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 di bagian sebelumnya pada penyimpanan terisolasi. Oleh karena itu, setiap kali Anda membuat akun baru, Anda menyimpan ID akun dalam penyimpanan terisolasi.
Di antarmuka pengguna 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.
Memigrasikan Sistem yang Ada ke Windows Hello
Di bagian singkat ini, kita akan mengatasi aplikasi paket dan sistem backend yang ada 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 bagian sebelumnya. Menambahkan Windows Hello ke sistem yang ada melibatkan penambahan beberapa alur 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:
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 di bagian sebelumnya.
Langkah terakhir dalam bermigrasi ke skenario Windows Hello lengkap adalah menonaktifkan opsi nama masuk dan kata sandi di aplikasi dan menghapus kata sandi hash yang disimpan dari database Anda.
Ringkasan
Windows 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 aplikasi Windows paket Anda untuk melindungi aplikasi dan layanan backend. Kode yang diperlukan minimal dan mudah dipahami. Windows menangani angkat berat.
Opsi implementasi 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. Dengan Microsoft Hello bawaan sistem operasi, Windows menawarkan solusi paling aman untuk masalah autentikasi yang dihadapi pengembang modern.
Misi selesai! Anda baru saja membuat Internet tempat yang lebih aman!
Sumber Daya Tambahan:
Artikel dan kode sampel
- Gambaran umum Windows Hello
- Merencanakan penyebaran Windows Hello untuk Bisnis
- Sampel kode Windows Hello UWP di GitHub
Terminologi
| Term | Definisi |
|---|---|
| AIK | Kunci identitas pengesahan digunakan untuk memberikan bukti kriptografi seperti itu (pengesahan kunci TPM) 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 penyedia identitas. Contohnya adalah build IDP oleh Microsoft untuk Akun Microsoft. Setiap kali aplikasi perlu mengautentikasi dengan MSA, aplikasi dapat memanggil MSA IDP. |
| PKI | Infrastruktur kunci publik 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 |
Topik terkait
Windows developer