Kunci Sandi Device-Bound vs. Synced (SCA & Passkeys I)

Ikhtisar: Autentikasi Pelanggan Kuat dengan Kunci Sandi#

• Analisis Persyaratan PSD2 & SCA
• Apa Arti Persyaratan SCA bagi Kunci Sandi
• Implikasi PSD3 / PSR untuk Kunci Sandi

1. Pengantar: Kunci Sandi Device-Bound vs. Synced#

Dalam postingan blog PSD2 tentang passkeys sebelumnya, kami membahas bagaimana kunci sandi (passkeys) telah digunakan oleh perusahaan Fintech seperti Revolut dan Finom, serta bagaimana teknologi ini meningkatkan keamanan digital untuk perbankan.

Kunci sandi memiliki dua bentuk utama: kunci sandi tersinkronisasi (synced passkeys) dan kunci sandi yang terikat perangkat (device-bound passkeys). Sementara kunci sandi tersinkronisasi memungkinkan pengguna untuk melakukan autentikasi di berbagai perangkat dengan mulus, kunci sandi device-bound secara ketat tertaut pada perangkat kunci sandi seperti kunci keamanan perangkat keras (hardware security key) atau autentikator lokal.

Melalui seri empat artikel blog ini, kami ingin menganalisis secara mendalam bagaimana berbagai jenis kunci sandi (device-bound vs. synced) mematuhi persyaratan SCA & PSD2.

Bagian pertama dari seri ini berfokus untuk memahami perbedaan antara kunci sandi device-bound dan tersinkronisasi.

Bagian kedua menjelaskan apa yang dimaksud dengan PSD2 dan Autentikasi Pelanggan Kuat (Strong Customer Authentication/SCA) dengan cara yang mudah dipahami, termasuk menjabarkan perkembangan historisnya.

Bagian ketiga dari seri ini menunjukkan bagaimana berbagai jenis kunci sandi mematuhi SCA dan apa artinya bagi bank, fintech, dan lembaga keuangan yang mempertimbangkan untuk mengadopsi kunci sandi.

Bagian keempat sekaligus terakhir dari seri ini menyimpulkan apa arti PSD3 / PSR bagi SCA dan kunci sandi di masa depan.

2. Strong Customer Authentication, PSD2, dan Kunci Sandi#

Setelah publikasi postingan blog terakhir kami, kami menerima banyak pertanyaan lanjutan mengenai pendirian kami tentang kunci sandi, khususnya terkait SCA di bawah kerangka PSD2. Terdapat minat yang jelas untuk memahami tidak hanya penerapan kunci sandi, tetapi juga bagaimana hal tersebut sejalan dengan Standar Teknis Regulasi (Regulatory Technical Standards/RTS). Selain itu, para pemangku kepentingan penasaran tentang potensi interpretasi dan panduan dari regulator, termasuk Otoritas Perbankan Eropa (European Banking Authority/EBA), mengenai penggunaan kunci sandi.

Menyadari hal ini, kami bertujuan untuk menggali lebih dalam tentang bagaimana kunci sandi dapat diintegrasikan di dalam arahan PSD2, RTS pada SCA, serta memberikan kejelasan mengenai posisi kami terkait penggunaan teknologi ini. Kami juga akan mengeksplorasi pertanyaan dan jawaban EBA yang sudah ada untuk memberikan pencerahan tentang bagaimana regulator dan EBA mungkin memandang kunci sandi. Pemeriksaan ini tidak hanya akan membahas perbedaan antara kunci sandi tersinkronisasi dan device-bound, tetapi juga aplikasi praktisnya dalam meningkatkan keamanan dan pengalaman pengguna.

Dengan memahami nuansa yang ada, pemangku kepentingan dapat membuat keputusan yang terinformasi yang tidak hanya mematuhi persyaratan ketat PSD2 tetapi juga memanfaatkan teknologi autentikasi terbaru untuk mengamankan transaksi digital. Diskusi kami bertujuan untuk semakin menerangi jalan bagi pengintegrasian kunci sandi ke dalam proses autentikasi, memastikan bahwa langkah-langkah keamanan sejalan dengan lanskap digital yang terus berkembang.

Tentu saja, setiap entitas yang diatur dan berada di bawah PSD2 perlu membuat keputusannya sendiri tentang bagaimana memenuhi target regulasi, karena setiap implementasi memiliki kompleksitasnya sendiri. Pendekatan individual ini mengakui bahwa meskipun kerangka regulasi memberikan standar yang seragam, aplikasi praktis dari standar ini akan bervariasi secara signifikan di antara berbagai organisasi karena lingkungan operasional, kemampuan teknologi, dan basis pengguna unik mereka.

Dengan demikian, meskipun wawasan kami bertujuan untuk memandu dan memberi informasi, wawasan ini tidak bersifat preskriptif. Setiap entitas harus mempertimbangkan keadaan dan tantangan spesifik mereka dalam mengintegrasikan kunci sandi ke dalam protokol keamanan dan autentikasi mereka.

3. Dari Kunci Sandi Device-Bound Menjadi Kunci Sandi Tersinkronisasi#

Untuk memahami perbedaan antara kunci sandi device-bound dan tersinkronisasi, kita akan menelusuri secara singkat bagaimana ekosistem ini berkembang.

3.1 Apa Itu Kunci Sandi Device-Bound (Kunci Sandi Perangkat Tunggal)?#

Kita mulai dengan melihat sejarah dan evolusi kunci sandi device-bound sebelum melihat lebih dalam detail teknisnya.

3.1.1 Sejarah Kunci Sandi Device-bound#

Secara historis, mekanisme autentikasi di dalam WebAuthn (standar yang mendasari kunci sandi) terikat erat dengan perangkat fisik: kunci keamanan (misalnya YubiKey). Sebelum adopsi kunci sandi yang meluas, kredensial FIDO2 yang terikat pada autentikator tunggal mewakili standar emas dalam hal keamanan. Kredensial ini tertaut dengan perangkat tempatnya berada. Implikasi dari pengikatan ini cukup signifikan: kredensial tidak dapat ditransfer atau digunakan di luar perangkat keras aslinya.

Pendekatan ini, meskipun meningkatkan keamanan dengan melokalisasi proses autentikasi ke satu perangkat, tentu saja menghadapi keterbatasan praktis yang memengaruhi adopsi secara luas, terutama di kalangan konsumen umum non-teknis. Pengguna dipaksa untuk menyiapkan perangkat autentikasi mereka untuk setiap upaya login, yang tidak hanya membatasi mobilitas pengguna tetapi juga menimbulkan kekhawatiran dalam skenario di mana perangkat hilang, rusak, atau tidak dapat segera diakses.

Lebih lanjut, terdapat juga keengganan konsumen untuk berinvestasi dalam perangkat keras tambahan. Secara historis, kepemilikan dan penggunaan kunci keamanan khusus sangat rendah di kalangan konsumen umum. Prospek untuk membeli perangkat keras khusus untuk tujuan autentikasi, meskipun menawarkan manfaat keamanan yang lebih baik, tidak begitu diminati oleh sebagian besar pengguna B2C, yang pada saat yang sama biasanya menjadi target kampanye phishing luas atau serangan credential stuffing.

3.1.2 Detail Teknis Kunci Sandi Device-Bound#

Kunci sandi device-bound dicirikan oleh kategorisasi spesifiknya menjadi kredensial yang dapat ditemukan (discoverable) dan tidak dapat ditemukan (non-discoverable), sebuah perbedaan yang pada dasarnya mendefinisikan kemampuan penemuannya. Namun, faktor utama yang membedakan kunci device-bound diringkas dalam properti kredensial WebAuthn, khususnya melalui flag isBackupEligible dan isBackupSynchronized. Untuk kunci sandi device-bound, kedua field ini diatur menjadi nol, yang menunjukkan bahwa kredensial tersebut tidak memenuhi syarat untuk dicadangkan atau disinkronkan ke seluruh perangkat. Karakteristik ini menggarisbawahi tautan intrinsiknya dengan perangkat fisik tempat kredensial tersebut dibuat, memastikan bahwa kredensial tetap terikat dan hanya dapat digunakan pada perangkat keras khusus tersebut.

Contoh penting dari praktik kredensial device-bound terlihat dalam ekosistem Windows. Kredensial Windows Hello di Windows 10 dan Windows 11 tetap bersifat device-bound—Windows Hello itu sendiri belum menyinkronkan kunci sandi lintas perangkat. Namun, Microsoft telah mengambil langkah pertama yang signifikan dengan memperkenalkan penyimpanan dan sinkronisasi kunci sandi di Microsoft Edge (dimulai dengan Edge 142). Sinkronisasi tingkat peramban melalui Pengelola Kata Sandi Microsoft (Microsoft Password Manager) ini memungkinkan kunci sandi disinkronkan di seluruh perangkat Windows saat menggunakan Edge, mirip dengan bagaimana Google Password Manager memungkinkan sinkronisasi kunci sandi pada peramban Chrome di Windows. Ini mewakili kemajuan penting dalam kemampuan kunci sandi Windows, meskipun ini khusus untuk peramban Edge, alih-alih pada autentikator platform Windows Hello. Kunci sandi Windows Hello tetap bersifat device-bound, tetapi integrasi Edge ini memberikan jalur praktis menuju kunci sandi tersinkronisasi di Windows sembari menunggu autentikator platform itu sendiri mungkin berkembang untuk mendukung sinkronisasi di masa mendatang.

Di sisi lain, Google telah mengartikulasikan pendirian yang jelas mengenai kunci sandi yang tidak dapat ditemukan, menunjukkan bahwa kunci sandi non-discoverable yang ada dapat tetap tidak disinkronkan dalam implementasi masa mendatang. Keputusan ini sejalan dengan prinsip yang lebih luas bahwa kredensial non-discoverable memainkan peran penting dalam konteks keamanan tertentu dengan tetap terikat erat pada perangkat (device-bound) dan tidak dapat ditemukan sehingga tidak dapat digunakan sebagai kunci sandi.

Sebaliknya, pendekatan yang diambil oleh Apple dengan macOS dan iOS sangat berbeda. Tidak seperti strategi device-bound tetap yang diamati pada Windows dan kunci non-discoverable Google, ekosistem Apple jauh lebih condong untuk hanya mengizinkan kunci sandi tersinkronisasi terutama di iOS sehingga mustahil untuk membuat kunci sandi device-bound melalui WebAuthn.

Segmentasi strategi di berbagai platform utama ini mengilustrasikan pendekatan yang beragam dalam mengelola kredensial WebAuthn, terutama ketika mempertimbangkan keseimbangan antara keamanan, kenyamanan, dan aksesibilitas pengguna. Walaupun kunci sandi device-bound menawarkan tingkat keamanan yang tinggi dengan memastikan bahwa kredensial tidak dapat dipindahkan atau disalahgunakan di luar perangkat yang dimaksud, industri terus berevolusi, mencari solusi yang mempertahankan standar keamanan tanpa mengorbankan pengalaman dan mobilitas pengguna.

3.2 Apa Itu Kunci Sandi Tersinkronisasi (Kunci Sandi Multi-Perangkat)?#

Di sini, kita juga melihat perkembangan historis kunci sandi tersinkronisasi sebelum menganalisis detail teknisnya. Terkadang kunci sandi tersinkronisasi juga disebut sebagai syncable passkeys.

3.2.1 Sejarah Kunci Sandi Tersinkronisasi#

Menyusul publikasi spesifikasi WebAuthn Level 2 dan CTAP 2.1 sekitar pertengahan hingga akhir tahun 2021, kelompok kerja WebAuthn meluncurkan inisiatif industri yang signifikan untuk mengatasi hambatan utama yang menghalangi kemampuan standar WebAuthn untuk menggantikan kata sandi dan meningkatkan adopsi. Inisiatif ini berfokus pada dua area kritis: menghilangkan persyaratan untuk perangkat keamanan perangkat keras tambahan dan memitigasi risiko yang terkait dengan kehilangan autentikator sekaligus menjaga kompatibilitas mundur (backward compatibility) secara penuh dengan standar yang ada.

3.2.1.1 Pemanfaatan Autentikator Platform Sebagai Modul Perangkat Keras Aman#

Tantangan pertama – menghilangkan kebutuhan perangkat keras baru – diatasi melalui penggunaan autentikator platform bawaan yang ditemukan di perangkat konsumen modern (misalnya Touch ID, Face ID, Windows Hello).

Perangkat modern semakin dilengkapi dengan modul keamanan khusus, seperti Trusted Execution Environment (TEE) pada Android, Secure Enclave pada iOS dan macOS, dan Trusted Platform Module (TPM) pada perangkat Windows. Penyimpanan kunci keamanan integral ini berfungsi sebagai fondasi yang kokoh untuk kunci sandi, secara efektif berfungsi sebagai "kunci keamanan" bawaan. Pendekatan ini memungkinkan adopsi luas dari kriptografi kunci publik (public key cryptography), tingkat keamanan yang sebelumnya hanya dapat dicapai melalui kunci keamanan perangkat keras eksternal (misalnya YubiKey), dan sebagian besar terbatas pada individu yang paham teknologi atau organisasi dalam industri yang sangat diatur.

Dengan memanfaatkan kemampuan TEE, Secure Enclave, atau TPM, protokol WebAuthn diberdayakan untuk menyediakan mekanisme autentikasi pengguna kriptografis yang kuat. Kini, metode autentikasi yang canggih dibuat ramah pengguna dan dapat diakses oleh masyarakat umum, tanpa memerlukan perangkat keras tambahan yang khusus.

Evolusi ini merupakan peningkatan yang sangat kuat dalam pendekatan keamanan digital, menekankan peran kritis yang dimainkan solusi keamanan berpusat pada pengguna dalam mendorong adopsi yang luas. Organisasi yang menggabungkan kunci sandi tersinkronisasi dengan alur pembuatan kunci sandi dan proses login yang dioptimalkan mencatat tingkat adopsi tertinggi. Dengan menggunakan fitur keamanan perangkat kontemporer, upaya industri ini berhasil mengatasi rintangan awal yakni menghilangkan keharusan memiliki perangkat keras eksternal.

Perkembangan ini merupakan langkah krusial di era baru ekosistem autentikasi digital, di mana penerapan luas dari kriptografi kunci publik menjadi langsung dapat diaplikasikan pada berbagai macam kasus penggunaan dan pada saat yang sama menyederhanakan autentikasi bagi pengguna.

3.2.1.2 Sinkronisasi Kunci Sandi ke Cloud#

Dalam rangka mengatasi risiko yang terkait dengan kehilangan ponsel genggam dan, dengan demikian, kunci sandi yang tersimpan di dalamnya, inisiatif industri berfokus untuk memungkinkan sinkronisasi kredensial discoverable ke cloud. Pendekatan ini secara efektif mengubah kredensial yang tadinya murni terikat pada perangkat (device-bound) menjadi multi-perangkat dan, lebih tepatnya, terikat ke akun cloud pengguna dengan penyedia cloud mereka, seperti iCloud untuk perangkat Apple atau Google untuk perangkat Android.

Solusi praktis ini berarti bahwa meskipun ponsel pengguna hilang atau diganti, kredensial yang sebelumnya dibuat tidak akan hilang secara permanen. Alih-alih demikian, kredensial ini dapat diambil dari akun cloud pengguna dan disinkronkan ke perangkat baru. Perubahan ini secara signifikan mengurangi ketidaknyamanan dan risiko keamanan yang sebelumnya terkait dengan hilangnya autentikator fisik.

Dengan memanfaatkan sinkronisasi cloud, kunci sandi kini dapat bertransisi dengan mulus di antara perangkat-perangkat pengguna, menjaga integritas dan keamanannya apa pun perangkat yang sedang digunakan. Misalnya, saat pengguna login ke situs web dari perangkat baru, kredensial yang tersedia di akun cloud mereka dapat disarankan secara otomatis untuk autentikasi. Jika perlu, kredensial ini dapat ditransmisikan ke perangkat baru, menjaga pengalaman autentikasi yang konsisten dan aman di berbagai platform dan perangkat.

Transisi ke kredensial yang terikat dengan akun dan disinkronkan melalui cloud ini merepresentasikan pendekatan pragmatis terhadap keamanan digital. Pendekatan ini mengakui realitas penggunaan perangkat modern dan kejadian umum berupa pertukaran perangkat, baik karena hilang, rusak, maupun upgrade. Dengan mengikat kredensial ke akun cloud pengguna – baik itu dengan layanan cloud Google maupun iCloud Apple – solusi ini tidak hanya memitigasi risiko terkait kehilangan perangkat tetapi juga meningkatkan kemampuan pengguna dalam mengelola dan memulihkan identitas digital mereka di berbagai perangkat.

Perkembangan ini secara efektif memperluas penerapan mekanisme autentikasi kriptografis yang kuat dari WebAuthn, menjadikannya lebih mudah beradaptasi dengan skenario pengguna di dunia nyata. Hal ini juga memastikan bahwa autentikasi kuat dapat diakses dan dikelola, bukan hanya bagi mereka yang memiliki latar belakang teknis atau mereka yang berada di industri dengan regulasi tinggi, melainkan juga bagi pengguna rata-rata yang menavigasi dunia digital dengan beberapa perangkat.

3.2.2 Detail Teknis Kunci Sandi Tersinkronisasi#

Kunci sandi tersinkronisasi juga dikenal sebagai kredensial discoverable atau kunci residen (resident keys). Ini dibedakan dari kunci device-bound melalui dua properti kritis: isBackupEligible dan isBackedUp memiliki nilai yang berbeda. Untuk kunci sandi tersinkronisasi, flag isBackupEligible diatur ke 1, menunjukkan bahwa kredensial ini memenuhi syarat untuk pencadangan. Setelah sinkronisasi yang sukses ke cloud, flag isBackedUp juga diatur ke 1, mengonfirmasi bahwa kredensial telah disinkronkan dengan benar. Penting untuk dicatat bahwa status sinkronisasi dapat berubah seiring waktu, mencerminkan sifat dinamis dari penggunaan dan manajemen perangkat.

Saat platform meminta resident keys, dengan mengatur parameter "requireResidentKey" menjadi required atau preferred, platform yang mendukung layanan cloud secara otomatis membuat kunci sandi tersinkronisasi. Proses ini memastikan bahwa pengguna dapat mengandalkan kredensial mereka dapat diakses di berbagai perangkat. Di Windows, kunci sandi tersinkronisasi kini tersedia melalui Microsoft Edge/Microsoft Password Manager (sinkronisasi tingkat peramban), sementara kredensial autentikator platform Windows Hello tetap bersifat device-bound. Pengelola kata sandi pihak ketiga (misalnya Dashlane, KeePassXC, 1Password) dengan kapabilitas manajemen kunci sandi juga menyediakan sinkronisasi lintas platform. Dalam skenario di mana kunci sandi tersinkronisasi digunakan, flag isBackupEligible dan isBackedUp diatur ke 1, mengindikasikan kelayakan pencadangan dan sinkronisasi yang berhasil.

Selanjutnya, walaupun saat ini masih memungkinkan untuk mengidentifikasi autentikator spesifik di mana kunci sandi telah disimpan, ketiadaan atestasi untuk sebagian besar kredensial ini berarti bahwa asal-usulnya tidak dapat diverifikasi secara kriptografis. Aspek ini menyoroti potensi batasan dalam menjamin keaslian keamanan kunci sandi tersinkronisasi semata-mata melalui mekanisme standar WebAuthn.

Perkembangan kunci sandi tersinkronisasi ini pada dasarnya memperluas lingkup kredensial discoverable dengan mengintegrasikannya ke dalam kerangka kerja sinkronisasi berbasis cloud. Dengan membuat kunci ini memenuhi syarat untuk dicadangkan dan memastikan sinkronisasinya di seluruh perangkat pengguna, WebAuthn mengatasi dua tantangan utama dalam autentikasi digital: risiko kehilangan akses akibat kehilangan perangkat dan ketidaknyamanan dalam mengelola beberapa kredensial device-bound.

3.3 Pengikatan Perangkat Tunggal (Single-Device-Binding) Kredensial WebAuthn Dikorbankan Demi Kebaikan Bersama#

Transisi dari kunci sandi device-bound menjadi kunci sandi tersinkronisasi memicu dialog kritis di dalam kelompok kerja WebAuthn, yang berpusat pada kebutuhan akan langkah-langkah keamanan lanjutan, pertanyaan hukum yang terlibat, dan kompromi yang ramah konsumen sekaligus aman.

Adopsi kunci sandi tersinkronisasi dirayakan atas janjinya untuk meningkatkan kenyamanan dan keamanan pengguna melalui fitur-fitur seperti sinkronisasi cloud dan fungsionalitas multi-perangkat yang mulus. Namun, hal ini memunculkan ketidaknyamanan di antara beberapa pihak pengandalan (Relying Parties/RP), khususnya terkait implikasi keamanan dan kepatuhan dalam lingkungan dengan persyaratan yang tinggi. Esensi dari perdebatan ini adalah perlunya mekanisme yang memastikan bahkan kunci sandi yang tersinkronisasi tetap memiliki koneksi ke perangkat tertentu, sebuah konsep krusial bagi pihak pengandalan yang menangani transaksi sensitif atau beroperasi di bawah standar regulasi yang ketat.

Bagi RP yang tidak dapat atau tidak mau mengadopsi kunci sandi, ketiadaan metode yang andal untuk mengikat kredensial ini ke perangkat spesifik dalam aplikasi kritis memberikan tantangan yang signifikan. Mekanisme tersebut dianggap sangat penting oleh beberapa RP. Ketiadaan kemampuan device-binding ini, sebuah ekspektasi yang mungkin tidak dinyatakan secara eksplisit tetapi sudah pasti diharapkan, merupakan kejutan yang serius dan pelanggaran kepercayaan dari perspektif mereka.

Diskusi ini menyimpulkan bahwa harus ada harmonisasi kepentingan, namun pada awalnya kebaikan bersama untuk menyebarluaskan kunci sandi harus lebih diutamakan. Dalam diskusi tersebut, ekstensi devicePubKey dipandang sebagai salah satu cara untuk mengatasi kekhawatiran tersebut, yang kemudian diganti dengan supplementalPubKeys yang mengambil pendekatan yang lebih luas ke dalam draf WebAuthn Level 3 saat ini. Sayangnya pendekatan ini juga dihentikan pada Agustus 2024.

3.4 Yang Terbaik dari Dua Dunia: Ekstensi Kunci Sandi dan supplementalPubKeys [tidak digunakan lagi per Agustus 2024]#

Mari kita analisis bagaimana kompromi dengan ekstensi supplementalPubKeys terbentuk dan apa artinya secara teknis.

3.4.1 Dari devicePubKey Menjadi Ekstensi supplementalPubKeys#

Diskusi seputar transisi dari ekstensi devicePubKey menjadi ekstensi supplementalPubKeys menyoroti sifat dinamis dari spesifikasi WebAuthn. Awalnya, devicePubKey berfungsi untuk meningkatkan keamanan melalui kunci publik device-bound, tetapi ini kemudian diganti dengan usulan supplementalPubKeys dalam WebAuthn Level 3 Editor's Working Draft. Ekstensi yang lebih baru ini menawarkan solusi yang lebih komprehensif dengan memungkinkan tersedianya beberapa kunci untuk meningkatkan proses autentikasi.

Inti dari perdebatan ini berfokus pada keseimbangan antara ukuran keamanan yang ditingkatkan dengan adopsi yang lebih luas dan utilitas praktis kunci sandi di berbagai platform dan perangkat. Ekstensi supplementalPubKeys mewakili kombinasi prioritas ini, yang memungkinkan autentikasi yang lebih ketat. Contohnya, ekstensi ini mengakomodasi regulasi yang mewajibkan standar autentikasi tertentu dengan mengizinkan penambahan “sub-kunci” (sub-keys) dengan pernyataan atestasi (attestation statements). Kunci ini dapat memberikan sinyal kepatuhan terhadap persyaratan autentikasi, yang berpotensi mengurangi kebutuhan akan tantangan masuk (sign-in) tambahan di bawah kondisi tertentu (bahkan dengan kunci sandi).

Sebuah contoh langsung dari draf WebAuthn:

“Katakanlah ada permintaan login yang muncul di sebuah situs web beserta beberapa sinyal geolokasi yang belum pernah terlihat untuk akun pengguna ini sebelumnya, dan berada di luar jam penggunaan normal yang diamati untuk akun tersebut. Risikonya mungkin dianggap cukup tinggi untuk menolak permintaan tersebut, bahkan dengan asersi oleh kredensial multi-perangkat sekalipun. Tetapi jika tanda tangan dari kunci suplemen yang terikat pada perangkat (device-bound), dan yang terverifikasi kuat untuk pengguna ini, juga dapat disajikan, maka hal itu dapat memberikan pertimbangan tambahan.”

Selama diskusi ini, disoroti bahwa ini hanya ditujukan untuk RP dengan persyaratan keamanan yang sangat tinggi (misalnya dalam konteks pemerintah).

Dengan memasukkan umpan balik dan menangani kasus penggunaan spesifik – juga mencakup transaksi keuangan yang diregulasi dan kebutuhan akan sinyal yang terikat pada perangkat (device-bound) dalam lingkungan kredensial multi-perangkat – komunitas WebAuthn bertujuan untuk menjawab permasalahan keamanan dan interoperabilitas. Ekstensi supplementalPubKeys dengan demikian merupakan pendekatan yang berupaya menyediakan fitur keamanan yang tangguh sekaligus juga mendukung pengalaman pengguna yang mulus dan kompatibilitas luas yang esensial untuk meluasnya adopsi kunci sandi. Ini merupakan ekstensi sepenuhnya opsional yang tidak mengganggu implementasi kunci sandi yang telah terlihat selama 2 tahun terakhir.

Evolusi ke arah kerangka kerja yang lebih inklusif dan fleksibel ini menggarisbawahi komitmen komunitas WebAuthn untuk memperbaiki metode autentikasi web bahkan untuk kasus penggunaan yang lebih ketat.

3.4.2 Detail Teknis supplementalPubKeys#

Ekstensi supplementalPubKeys yang diperkenalkan dalam WebAuthn mengizinkan penggunaan pasangan kunci tambahan (keypairs) di samping kredensial primer.

Diambil dari GitHub issue asli

Gambar tersebut menunjukkan konsep supplementalPubKey yang diambil dari GitHub issue asli (pk = passkey, pspk=provider supplemental key, dspk = device supplemental key).

Berikut adalah penjabaran tentang bagaimana cara kerjanya dan tujuan penggunaannya:

Tujuan dan Fungsionalitas supplementalPubKey

• Hanya ada satu kredensial kunci sandi utama: Penting untuk diingat bahwa hanya satu kunci sandi pusat yang tetap menjadi metode utama autentikasi pengguna, dan kunci tambahan memberikan lapisan keamanan dan kepastian ekstra. Struktur ini mempertahankan kesederhanaan dan efisiensi dalam menggunakan satu kunci sandi inti untuk autentikasi di berbagai perangkat, memastikan pengalaman pengguna yang mulus. Sementara itu, kunci suplemen berfungsi untuk meningkatkan konteks autentikasi, menawarkan sinyal tambahan kepada Pihak Pengandalan (Relying Party/RP) mengenai lingkungan keamanan atau kepatuhan terhadap standar autentikasi spesifik. Kunci suplemen ini bukanlah metode autentikasi mandiri melainkan mengaugmentasi kunci sandi primer, memperkuat keterpercayaannya dengan bukti integritas perangkat.
• Kunci Terikat Perangkat (Device-Bound Keys): Kunci ini diikat secara spesifik ke satu perangkat. Kunci ini dapat memberikan kepastian bahwa sebuah permintaan autentikasi berasal dari perangkat tepercaya yang sebelumnya telah diautentikasi. Kunci ini tidak akan disinkronkan dalam situasi apa pun.
• Kunci Terikat Penyedia (Provider-Bound Keys): Kunci ini memiliki ruang lingkup "penyedia" (provider), yang berarti dapat menawarkan kepastian tambahan berdasarkan kebijakan penyedia autentikasi atau atestasi spesifik dari penyedia tersebut. Sebagai contoh, sebuah penyedia mungkin hanya menerbitkan kunci seperti itu setelah pengguna menyelesaikan tingkat autentikasi yang lebih tinggi (seperti 2FA).
• Kunci Publik Multipel (Multiple Public Keys): Tidak seperti pendahulunya, ekstensi devicePubKey, yang hanya mengizinkan satu kunci publik device-bound, supplementalPubKeys memungkinkan pencantuman satu atau dua tipe kunci suplemen. Kunci-kunci ini dapat melayani berbagai tujuan dan ruang lingkup – yaitu, ruang lingkup device-bound dan provider-bound.

Kasus Penggunaan dan Contoh supplementalPubKey

1. Keamanan yang Ditingkatkan: Dalam situasi di mana sebuah situs web (pihak pengandalan) harus mematuhi standar keamanan yang ditingkatkan tertentu untuk autentikasi, kunci suplemen dapat digunakan untuk memenuhi persyaratan ini. Jika kunci suplemen ini pernah dilihat dan diverifikasi oleh situs web sebelumnya, pengguna mungkin diizinkan untuk melewati tantangan proses masuk tambahan karena kontinuitas perangkat dapat dikonfirmasi oleh sinyal sebelumnya.
2. Manajemen Risiko: Untuk permintaan proses masuk yang tampak berisiko (misalnya, berasal dari geolokasi baru atau pada jam tidak biasa), kehadiran kunci suplemen device-bound yang memiliki rekam jejak penggunaan bersama akun pengguna dapat mengurangi risiko yang dirasakan dan mengizinkan permintaan tersebut diproses, yang jika tidak ada kunci tersebut mungkin akan diblokir.

Aspek Teknis supplementalPubKey

• Tidak Memiliki Credential ID Sendiri: Kunci suplemen bukanlah kredensial pengguna dan tidak memiliki Credential ID sendiri.
• Pernyataan Atestasi (Attestation Statements): Kunci suplemen secara opsional dapat memiliki sebuah atestasi. Hal ini krusial untuk memahami ruang lingkup dan tingkat keamanan dari kunci suplemen. Sebuah atestasi dapat mengindikasikan tingkat proteksi yang dinikmati oleh kunci yang terikat pada perangkat keras (hardware-bound key), atau kebijakan untuk jenis kunci suplemen lainnya.
• Implementasi bagi Pihak Pengandalan (Relying Parties): Pihak pengandalan dapat meminta kunci suplemen ini sebagai bagian dari proses autentikasi. Namun, kerumitan dalam menangani beberapa kunci dan pernyataan atestasi berarti bahwa ekstensi ini paling sesuai untuk entitas dengan kebutuhan keamanan spesifik, seperti bank atau layanan yang beroperasi di bawah persyaratan regulasi yang ketat.

Penting untuk dicatat bahwa, per April 2024, ekstensi supplementalPubKeys belum diadopsi oleh peramban utama mana pun, dan spesifikasi WebAuthn Level 3 masih dalam tahap pengembangan dan dapat berubah. Apakah fitur ini akan disertakan dalam versi akhir spesifikasi, dan potensi implementasi dan adopsinya di masa mendatang, masih tidak pasti, karena saat ini hanya berada dalam Draf Editor.

3.4.3 Penghentian Penggunaan supplementalPubKeys pada Agustus 2024#

Per Agustus 2024, ekstensi supplementalPubKeys secara resmi telah dihentikan penggunaannya. Kelompok kerja WebAuthn memutuskan untuk menghapus fitur ini karena kurangnya dukungan. Penghentian ekstensi ini juga menyoroti arah baru. Saat ini, FIDO Alliance sedang bekerja mengembangkan pendekatan yang berbeda untuk mendukung Pihak Pengandalan (Relying Parties) dengan persyaratan keamanan yang tinggi. Solusi yang akan datang ini diharapkan dapat mengisi kesenjangan yang ditinggalkan akibat penghentian supplementalPubKeys dan menawarkan metode baru untuk memperkuat proses autentikasi dalam skenario di mana standar keamanan yang ketat sangat penting.

Untuk detail lebih lanjut mengenai penghentian ini, lihat WebAuthn GitHub pull request resminya.

4. Bagaimana Corbado Menangani Perbedaan Kunci Sandi Device-bound vs. Tersinkronisasi dalam Praktik#

Memahami perbedaan antara kunci sandi device-bound dan tersinkronisasi adalah suatu keharusan, namun bank juga memerlukan alat untuk mengoperasionalkan perbedaan ini dalam skala besar. Platform Corbado menyediakan intelijen kepercayaan perangkat (device trust intelligence) yang secara otomatis mengklasifikasikan jenis kunci sandi dan menerapkan perlakuan SCA yang tepat untuk masing-masing jenis.

Visibilitas Kepercayaan Perangkat (Device Trust Visibility) pada Seluruh Tipe Kunci Sandi#

Dasbor Device Trust Corbado menunjukkan bagaimana performa kunci sandi device-bound dan tersinkronisasi berbeda di dalam sistem produksi. Kunci sandi device-bound mencapai tingkat keberhasilan yang lebih tinggi (99,1%) dengan nol kebutuhan step-up, sedangkan kunci sandi tersinkronisasi dengan sinyal kepercayaan perangkat mencapai 98,4% dengan persentase step-up kecil untuk perangkat baru.

Dasbor ini juga melacak klasifikasi perangkat — mengidentifikasi perangkat mana yang eksklusif untuk satu pengguna (92% dalam penerapan perbankan khusus), mana yang dibagikan oleh dua pengguna (7%), dan mana yang merupakan perangkat bersama/kios (0,8%). Klasifikasi ini dimasukkan secara langsung ke dalam keputusan kepatuhan SCA.

Kontrol Berbasis Kebijakan untuk Skenario Kunci Sandi yang Berbeda#

Daripada memperlakukan semua kunci sandi sama rata, kebijakan kepercayaan (trust policies) Corbado memungkinkan bank untuk menerapkan aturan yang berbeda berdasarkan tipe kunci sandi, status perangkat, dan tingkat kepercayaan. Kunci sandi device-bound pada perangkat yang dikenal akan mendapatkan autentikasi tanpa hambatan (frictionless), sedangkan kunci sandi tersinkronisasi pada perangkat baru memicu verifikasi step-up — tepat seperti pendekatan bernuansa yang dituntut oleh kerangka kerja SCA dari PSD2.

Ini berarti bank dapat dengan percaya diri meluncurkan kunci sandi tersinkronisasi demi pengalaman pengguna yang lebih baik sembari mempertahankan kendali perangkat ketat yang disediakan oleh kunci sandi device-bound untuk skenario keamanan tinggi — yang kesemuanya dikelola melalui konfigurasi kebijakan daripada alur autentikasi yang terpisah.

Tentang Corbado

Corbado adalah Passkey Intelligence Platform untuk tim CIAM yang menjalankan autentikasi consumer dalam skala besar. Kami membantu Anda melihat apa yang tidak bisa ditunjukkan oleh log IDP dan tool analytics generik: device, versi OS, browser, dan credential manager mana yang mendukung passkey; mengapa enrollment tidak menjadi login; di mana flow WebAuthn gagal; dan kapan update OS atau browser diam-diam merusak login — semuanya tanpa mengganti Okta, Auth0, Ping, Cognito, atau IDP internal Anda. Dua produk: Corbado Observe menambah observability untuk passkey dan metode login lainnya. Corbado Connect menghadirkan managed passkey dengan analytics terintegrasi (berdampingan dengan IDP Anda). VicRoads menjalankan passkey untuk 5M+ pengguna dengan Corbado (aktivasi passkey +80%). Bicara dengan pakar Passkey →

Pertanyaan yang Sering Diajukan (FAQ)#

Bagaimana kunci sandi device-bound meningkatkan keamanan?#

Kunci sandi device-bound adalah kredensial WebAuthn yang secara ketat terikat ke perangkat tempat mereka dibuat. Tidak seperti kunci sandi tersinkronisasi, mereka tetap berada di satu perangkat, membuatnya secara inheren lebih aman untuk kasus penggunaan tertentu:

• Tidak ada pencurian kredensial: Kunci privat tidak pernah meninggalkan perangkat, sehingga penyerang tidak dapat mencegat kredensial.
• Pencegahan akses tidak sah: Autentikasi hanya terjadi dari perangkat spesifik tempat kunci sandi dibuat.
• Tidak ada ketergantungan cloud: Mengeliminasi risiko terkait pembobolan data cloud atau pengambilalihan akun.
• Kepatuhan keamanan tinggi: Memenuhi persyaratan ketat autentikasi device-bound untuk industri teregulasi seperti layanan keuangan (AAL3).

Kelemahan utamanya adalah portabilitas yang terbatas. Jika perangkat hilang, kunci sandi tidak dapat dipulihkan kecuali pengguna mendaftarkan yang baru di perangkat lain.

Mengapa kunci sandi tersinkronisasi diperkenalkan dan apa manfaatnya?#

Kunci sandi tersinkronisasi (multi-perangkat) diperkenalkan untuk memecahkan tantangan kegunaan dari kunci sandi device-bound, terutama kurangnya portabilitas dan potensi terkuncinya akun jika perangkat hilang. Manfaat utamanya meliputi:

• Autentikasi multi-perangkat: Akses akun dari beberapa perangkat tanpa mendaftarkan kunci sandi baru secara manual untuk tiap-tiap perangkat.
• Tidak ada risiko kehilangan akses: Kredensial dicadangkan ke cloud (mis. iCloud Keychain, Google Password Manager), memastikan pemulihan jika sebuah perangkat hilang.
• UX yang Ditingkatkan: Menghilangkan hambatan (friction) dengan menghapus perlunya transfer atau membuat ulang kredensial secara manual.
• Tidak memerlukan perangkat keras tambahan: Tidak seperti kunci keamanan perangkat keras, kunci sandi tersinkronisasi menggunakan modul keamanan perangkat bawaan.
• Keamanan tangguh dengan kenyamanan cloud: Enkripsi end-to-end memastikan kunci privat tidak pernah meninggalkan perangkat dalam format tidak terenkripsi.

5. Kesimpulan#

Pada bagian pertama dari seri 4 bagian kami, kami telah menganalisis perbedaan historis dan teknis dari kunci sandi device-bound dan tersinkronisasi. Memahami perbedaan ini akan membantu kita untuk menerapkan persyaratan PSD2 dan SCA secara semestinya. Kami juga telah melihat apa yang mungkin terjadi di masa depan dengan mencermati perubahan terbaru dalam Standar Webauthn Level 3 yang masih terus berevolusi.

Berikut ini adalah tautan ke bagian-bagian lain dari seri kami:

• Bagian 2 “Analisis Persyaratan PSD2 & SCA (SCA & Passkeys II)”
• Bagian 3 "Apa Arti Persyaratan SCA Bagi Kunci Sandi (SCA & Passkeys III)"
• Bagian 4 "Implikasi PSD3 / PSR bagi Kunci Sandi (SCA & Passkeys IV)"