Passkey Tadinya Hanya Bisa Mengetuk Pintu sampai Ekstensi PRF Mengajarinya Membuka Brankas Enkripsi

Saat Anda mengaktifkan fitur passkey pada aplikasi pengelola kata sandi atau brankas catatan terenkripsi, layar pengaturan menjanjikan masa depan tanpa kata sandi. Anda menempelkan jari ke sensor biometrik laptop atau menyentuh lempeng emas pada kunci keamanan fisik, dan peramban langsung menyetujui sesi masuk dalam waktu kurang dari satu detik. Namun tepat ketika Anda mengira brankas data akan terbuka, layar justru berhenti dan tetap meminta Anda mengetik kata sandi utama (master password).

Bagi jutaan pengguna dan pengembang perangkat lunak, kemunculan kolom kata sandi kedua ini terasa seperti janji yang diingkari. Jika passkey dibangun di atas kriptografi kunci publik tahan pancingan (phishing-resistant) yang cukup tangguh untuk mengamankan bank, jaringan korporat, dan lembaga pemerintah, mengapa ia tidak sanggup membuka brankas catatan pribadi atau kumpulan kredensial yang dienkripsi? Selama bertahun-tahun, jawabannya terletak pada batasan matematis mendasar di dalam standar Web Authentication (WebAuthn): passkey standar dirancang khusus hanya untuk membuktikan identitas, bukan untuk mengacak atau mendekripsi data.

Sekat arsitektur tersebut kini akhirnya runtuh. Melalui ekstensi baru di dalam spesifikasi World Wide Web Consortium (W3C) WebAuthn Level 3 yang bernama Pseudo-Random Function (prf), yang ditopang pada lapisan protokol perangkat keras oleh ekstensi FIDO2 Client to Authenticator Protocol (CTAP2) hmac-secret, passkey kini menguasai kemampuan kriptografi kedua. Tanpa sekalipun membocorkan kunci privat internalnya ke luar chip, autentikator modern kini dapat menghitung rahasia deterministik sepanjang 256-bit pada sentuhan biometrik yang sama saat Anda masuk. Pengelola kata sandi seperti Bitwarden dan 1Password, bersama prototipe dompet identitas digital Uni Eropa seperti proyek wwWallet, telah menggunakan mekanisme ini untuk memensiunkan master password sembari mempertahankan enkripsi ujung-ke-ujung berprinsip tanpa-pengetahuan (zero-knowledge).

Memahami mengapa passkey pada awalnya gagal melakukan enkripsi, serta bagaimana fungsi hash berpengunci di dalam elemen aman perangkat keras menuntaskan kebuntuan tersebut, memperlihatkan garis batas tipis antara membuktikan siapa diri Anda kepada server dan menjaga agar data Anda tetap mustahil dibaca oleh server yang sama.

Untuk melihat mengapa passkey standar tadinya hanya bisa mengetuk pintu server tanpa sanggup membuka brankas besi di dalamnya, kita perlu memisahkan dua pekerjaan kriptografi yang sama sekali berbeda: autentikasi dan enkripsi.

Autentikasi adalah percakapan interaktif dengan penjaga gerbang. Ketika Anda masuk ke situs web biasa menggunakan passkey, server situs web tersebut (yang dalam spesifikasi WebAuthn disebut sebagai Relying Party) tidak perlu mendekripsi apa pun untuk Anda. Server sudah menyimpan data akun Anda dalam bentuk rekaman basis data yang dapat dibaca; server hanya menolak menampilkan data tersebut sampai Anda membuktikan bahwa Anda memegang perangkat yang terdaftar pada akun itu.

WebAuthn menjalankan pembuktian ini melalui kriptografi kunci publik asimetris, umumnya menggunakan Elliptic Curve Digital Signature Algorithm (ECDSA di atas kurva NIST P-256) atau Edwards-curve Digital Signature Algorithm (Ed25519). Saat pendaftaran akun, autentikator Anda (baik berupa YubiKey, ponsel Android, maupun Secure Enclave pada perangkat Apple) membangkitkan sepasang kunci matematis:

• Kunci Privat: Dikunci permanen di dalam chip perangkat keras tahan bongkar atau enklave terisolasi pada perangkat. Tidak ada antarmuka pemrograman peramban, panggilan sistem operasi, maupun server jarak jauh yang dapat membaca atau mengekspor deretan bita ini.
• Kunci Publik: Diserahkan secara terbuka kepada server situs web untuk disimpan berdampingan dengan nama pengguna dan pengenal kredensial Anda.

Ketika Anda kembali untuk masuk, server membangkitkan deretan bita acak sekali pakai yang disebut tantangan (challenge atau nonce kriptografis) dan mengirimkannya ke peramban. Peramban menggabungkan tantangan tersebut dengan nama domain situs yang terverifikasi (origin), menghitung nilai hash-nya, lalu meneruskannya ke autentikator. Autentikator membubuhkan tanda tangan digital di atas nilai hash tersebut memakai kunci privat Anda, lalu mengembalikan hasilnya. Server kemudian memakai kunci publik Anda yang tersimpan untuk memverifikasi keabsahan tanda tangan tersebut secara matematis.

Akan tetapi, di dalam aplikasi terenkripsi ujung-ke-ujung berprinsip zero-knowledge, tidak ada penjaga gerbang yang memegang data siap baca. Layanan seperti Bitwarden, 1Password, Proton Pass, atau jurnal medis terenkripsi hanya menyimpan bongkahan teks tersandi (ciphertext) yang telah diacak menggunakan algoritma seperti AES-256-GCM. Server tidak bisa menyodorkan data yang terbaca setelah memeriksa identitas Anda, sebab server itu sendiri sama sekali tidak memiliki kunci untuk membuka sandinya. Untuk mengubah bongkahan ciphertext tersebut kembali menjadi teks yang dapat dibaca di dalam peramban, aplikasi klien Anda membutuhkan kunci enkripsi simetris: deretan 256-bit angka satu dan nol yang spesifik dan tidak pernah berubah.

Di titik inilah muncul mitos yang kerap menjebak banyak pengguna maupun pengembang perangkat lunak: Mengapa tidak langsung memakai tanda tangan digital passkey, atau kunci publiknya, sebagai kunci enkripsi simetris?

Setiap upaya memaksakan keluaran WebAuthn standar untuk menyandikan data langsung gugur ketika diuji dengan prinsip dasar kriptografi:

• Mengapa Kunci Publik Gagal: Sesuai namanya, kunci publik dikirimkan ke server jarak jauh saat pendaftaran agar server dapat memeriksa tanda tangan login berikutnya. Dalam arsitektur zero-knowledge, server jarak jauh diperlakukan sebagai gudang penyimpanan yang tidak boleh dipercaya memegang rahasia. Jika aplikasi klien mengenkripsi brankas Anda memakai kunci publik WebAuthn, server yang menampung brankas tersebut dapat langsung mendekripsi seluruh rahasia Anda detik itu juga.
• Mengapa Kunci Privat Gagal: Antarmuka WebAuthn (navigator.credentials.create() dan navigator.credentials.get()) tidak menyediakan satu pun metode untuk mengekspor atau mengintip kunci privat. Seluruh jaminan keamanannya bertumpu pada aturan mutlak bahwa kunci privat tidak boleh pernah masuk ke memori peramban, tempat celah injeksi skrip lintas-situs (XSS) atau ekstensi peramban berbahaya dapat mencurinya.
• Mengapa Tanda Tangan Digital Gagal: Enkripsi simetris menuntut sifat deterministik yang mutlak. Jika Anda mengunci sebuah berkas dengan Kunci $K$ pada hari Senin, Anda wajib memasukkan Kunci $K$ yang sama persis ke mesin dekripsi pada hari Jumat, hingga bit terakhir. Jika satu bit saja berubah, verifikasi tag autentikasi AES-GCM akan gagal dan data Anda terkunci selamanya. Sebaliknya, tanda tangan autentikasi FIDO2 sengaja dirancang non-deterministik (selalu berubah). Setiap kali Anda masuk, server mengeluarkan tantangan acak baru, autentikator menaikkan penghitung tanda tangan internal 32-bit (signCount), dan algoritma ECDSA menyuntikkan angka acak kriptografis baru ($k$) ke dalam persamaan kurva eliptik. Masuklah sepuluh kali dalam sepuluh menit, dan passkey Anda akan mengeluarkan sepuluh tanda tangan digital yang sama sekali berbeda. Bahkan pengiriman tantangan statis tetap gagal karena signCount dan nilai acak ECDSA selalu berubah pada tiap pemanggilan, serta penyadap jaringan akan langsung mengetahui kunci tersebut.

Karena passkey standar tidak pernah mengeluarkan nilai rahasia yang dapat diulang secara konsisten, aplikasi enkripsi sisi-klien terjebak dalam kompromi yang canggung. Mereka dapat memakai passkey untuk mempersilakan Anda masuk ke lobi akun tanpa mengetik alamat surel atau kode dua faktor, tetapi mereka tetap harus menahan layar dan meminta Anda mengetik master password hafalan agar peramban dapat menjalankan fungsi penurunan kunci berbasis kata sandi (PBKDF2-HMAC-SHA256 atau Argon2id) guna membentuk ulang kunci dekripsi statis Anda.

Untuk menyingkirkan kolom kata sandi kedua tersebut tanpa melubangi isolasi perangkat keras, para rekayasawan di Kelompok Kerja Web Authentication W3C bersama FIDO Alliance merancang mekanisme khusus di dalam WebAuthn Level 3 (yang diterbitkan sebagai W3C Candidate Recommendation Snapshot pada 26 Mei 2026): Bagian 10.1.4, **ekstensi Pseudo-Random Function (prf)**.

Alih-alih meminta autentikator memakai kunci penandatanganannya untuk urusan enkripsi, ekstensi prf menginstruksikan autentikator untuk memelihara satu rahasia simetris terpisah yang terikat khusus pada kredensial tersebut. Saat pendaftaran atau saat proses masuk, peramban mengirimkan satu atau dua bita masukan yang diketahui, yang disebut garam kriptografis (salt), ke dalam kamus ekstensi. Di dalam batas aman perangkat keras autentikator, rahasia internal kredensial tersebut digabungkan dengan nilai garam menggunakan fungsi hash berpengunci (HMAC-SHA-256) untuk menghasilkan keluaran pseudo-acak sepanjang 32-bita (256-bit).

Autentikasi WebAuthn Standar (Non-Deterministik):
[Tantangan Acak Server] + [Kunci Privat Autentikator] + [Angka Acak k]
       ===> Tanda Tangan ECDSA (Berbeda tiap login -> Mustahil untuk dekripsi)

Ekstensi WebAuthn PRF (Deterministik & Tak Tertebak):
[Garam Aplikasi] ===> SHA-256("WebAuthn PRF" || 0x00 || Garam)
       ===> [CTAP2 hmac-secret di Secure Element: HMAC-SHA-256(CredRandom, Garam)]
       ===> Keluaran PRF 32-Bita (Identik untuk garam sama -> Masuk HKDF -> Kunci AES-256-GCM)

Keluaran 32-bita ini memenuhi dua sifat matematis simultan yang wajib ada pada enkripsi sisi-klien berprinsip zero-knowledge:

1. Determinisme Ketat: Selama aplikasi web menyodorkan nilai garam (BufferSource) yang sama persis kepada kredensial passkey yang sama pada domain (rpId) yang sama, autentikator dijamin secara matematis akan mengembalikan deretan 32-bita yang persis identik setiap kali dipanggil.
2. Ketidaktertebakan Kriptografis: Bagi siapa pun yang tidak memegang autentikator fisik tersebut dan tidak melewati verifikasi pengguna (seperti pemindaian sidik jari, pengenalan wajah, atau PIN perangkat keras), keluaran 32-bita tersebut secara komputasi tidak dapat dibedakan dari derau acak murni di dalam ruang kemungkinan sebesar $2^{256}$. Sekalipun penyerang mencuri nilai garam publik dari server dan berhasil mengintip satu kunci turunan untuk garam tertentu, sifat satu arah dari HMAC-SHA-256 mencegah mereka menghitung balik rahasia akar di dalam autentikator maupun menebak keluaran untuk nilai garam lainnya.

Hal yang tak kalah penting, spesifikasi W3C menerapkan pemisahan domain dan konteks secara ketat di dalam peramban sebelum nilai garam dari pengembang web menyentuh perangkat keras autentikator. Bayangkan seorang pengguna mencolokkan YubiKey yang sama ke laptopnya baik untuk membuka enkripsi disk penuh Linux (systemd-cryptsetup / LUKS2 melalui pustaka libfido2) maupun untuk masuk ke aplikasi web. Aplikasi native yang berbicara langsung ke kunci USB melalui protokol CTAP2 mengirimkan garam mentah 32-bita ke ekstensi hmac-secret. Jika sebuah situs web jahat di dalam tab peramban diizinkan mengirimkan garam mentah 32-bita secara langsung ke kunci keamanan USB, situs tersebut bisa saja mencoba memutar ulang nilai garam yang dipakai oleh sistem enkripsi disk lokal.

Untuk memastikan tabrakan lintas-konteks semacam itu mustahil terjadi, Bagian 10.1.4 spesifikasi WebAuthn Level 3 mewajibkan peramban untuk tidak pernah meneruskan garam mentah milik pengembang web (eval.first atau eval.second) secara langsung ke autentikator. Sebagai gantinya, peramban terlebih dahulu mengubah setiap masukan dengan menempelkan rangkaian teks UTF-8 tetap "WebAuthn PRF" diikuti satu bita nol (0x00) sebelum menghitung nilai hash SHA-256 dari keseluruhannya:

$$\text{salt}_1 = \text{SHA-256}(\text{UTF8Encode}(\text{"WebAuthn PRF"}) \parallel \text{0x00} \parallel \text{eval.first})$$

$$\text{salt}_2 = \text{SHA-256}(\text{UTF8Encode}(\text{"WebAuthn PRF"}) \parallel \text{0x00} \parallel \text{eval.second})$$

Karena peramban menjalankan perhitungan hash berawalan ini secara tanpa syarat di dalam kode C++ atau Rust miliknya, tidak ada skrip JavaScript di halaman web mana pun yang sanggup meminta kunci FIDO2 mengevaluasi garam aplikasi native.

Lebih jauh lagi, autentikator mengikat rahasia PRF internalnya secara ketat pada Relying Party ID situs web yang telah diverifikasi oleh peramban (rpId, misalnya vault.bitwarden.com). Sekalipun situs pancingan palsu di alamat vault-bitwarden-security.com menyalin kode JavaScript yang sama persis dan mengirimkan bita garam yang identik, peramban akan mengikat permintaan tersebut ke domain penipu. Autentikator otomatis menolak mengenali kredensial tersebut, sehingga situs penipu tidak mendapatkan tanda tangan login maupun rahasia enkripsi.

Sementara pengembang web berinteraksi dengan antarmuka JavaScript yang ringkas, yakni menyisipkan extensions: { prf: { eval: { first: saltBuffer } } } ke dalam panggilan navigator.credentials.get(), kerja berat kriptografi sesungguhnya berlangsung satu lapis lebih dalam pada FIDO Client to Authenticator Protocol (CTAP) v2.1, tepatnya pada Bagian 12.5: **ekstensi hmac-secret**.

Memahami apa yang mengalir di jalur kabel atau gelombang radio antara peramban dan autentikator perangkat keras menjelaskan mengapa WebAuthn PRF jauh lebih tangguh ketimbang menyimpan kunci enkripsi di dalam localStorage atau IndexedDB peramban. Ketika pengguna mencolokkan token FIDO2 seperti YubiKey 5C NFC ke port USB atau menempelkannya ke antena NFC ponsel, komunikasi tersebut melintasi jalur fisik yang dikelola oleh sistem operasi. Apabila kunci keamanan langsung memuntahkan rahasia enkripsi 32-bita ke komputer dalam bentuk paket USB Human Interface Device (HID) atau bingkai radio NFC tanpa enkripsi, program latar belakang tanpa hak khusus yang memantau lalu lintas USB atau antena penyadap NFC di dekatnya dapat langsung memungut kunci enkripsi tersebut di tengah jalan.

Untuk mencegah penyadapan di jalur antara autentikator dan peramban, spesifikasi CTAP2 hmac-secret membungkus seluruh pertukaran garam dan keluaran PRF di dalam terowongan terenkripsi Diffie-Hellman sementara (ephemeral) yang dinegosiasikan khusus untuk transaksi tersebut:

• **Tahap 1: Pembuatan Kredensial (authenticatorMakeCredential)**: Ketika aplikasi web mendaftarkan passkey baru dengan extensions: { prf: {} }, peramban menyetel bendera hmac-secret: true pada perintah CTAP2. Di dalam elemen aman tahan bongkar miliknya, autentikator membangkitkan rahasia acak 32-bita (CredRandom) berdampingan dengan pasangan kunci P-256 atau Ed25519. Meskipun spesifikasi dasar CTAP2 mendefinisikan dua rahasia internal (CredRandomWithUV dan CredRandomWithoutUV), spesifikasi W3C WebAuthn Level 3 prf mewajibkan peramban untuk hanya membuka akses ke PRF yang terverifikasi pengguna (uv=1). Pencuri yang menyambar YubiKey dari meja kerja Anda tidak akan bisa membangkitkan kunci enkripsi hanya dengan sentuhan fisik tanpa melewati pemindaian biometrik atau PIN perangkat keras.
• Tahap 2: Kesepakatan Kunci ECDH Sementara: Saat pengguna masuk (authenticatorGetAssertion), peramban memanggil authenticatorClientPIN (getKeyAgreement) untuk mengambil kunci publik P-256 sementara milik autentikator, membangkitkan pasangan kunci sementara miliknya sendiri, lalu menjalankan algoritma Elliptic Curve Diffie-Hellman (ECDH) guna membentuk satu sharedSecret sekali pakai antara peramban dan chip autentikator.
• **Tahap 3: Mengenkripsi Masukan Garam (saltEnc)**: Peramban mengenkripsi nilai salt1 sepanjang 32-bita (atau 64-bita apabila salt2 diminta sekaligus) menggunakan AES-256-CBC di bawah kunci sharedSecret sementara, membubuhkan tag HMAC-SHA-256 (saltAuth), dan mengirimkannya ke autentikator.
• **Tahap 4: Evaluasi Perangkat Keras dan Keluaran Terenkripsi (outputEnc)**: Di dalam chip elemen aman, autentikator memeriksa saltAuth, mendekripsi salt1, memverifikasi PIN atau biometrik pengguna, lalu menghitung:

$$\text{output}_1 = \text{HMAC-SHA-256}(\text{CredRandomWithUV}, \text{salt}_1)$$

Autentikator kemudian mengenkripsi output1 di bawah sharedSecret sementara, menempatkannya ke dalam blok authenticatorData, lalu menandatangani paket respons.

• Tahap 5: Dekripsi Klien dan Kebutaan Server: Peramban mendekripsi outputEnc di memori lokal dan menaruh rahasia 32-bita tersebut di assertion.getClientExtensionResults().prf.results.first. Sementara itu, meskipun struktur authenticatorData bertanda tangan dikirimkan ke server web sebagai bukti sah login, server jarak jauh tidak pernah mengetahui nilai sharedSecret USB/NFC lokal Anda. Deretan bita outputEnc di dalam paket login tersebut mustahil didekripsi oleh server, sehingga pemisahan zero-knowledge terjaga utuh dari ujung ke ujung.

Mendapatkan larik deterministik 32-bita dari prf.results.first memang memecahkan kebuntuan determinisme passkey, tetapi para arsitek keamanan di Yubico, Bitwarden, 1Password, dan IETF mengingatkan satu kesalahan implementasi yang berbahaya: jangan pernah memasukkan keluaran mentah 32-bita dari PRF langsung ke dalam cipher enkripsi AES, dan jangan pernah mengenkripsi data pengguna secara langsung dengan kunci turunan satu passkey.

Dalam rekayasa kriptografi formal, bita 32-bita yang dikembalikan oleh ekstensi WebAuthn PRF diklasifikasikan sebagai **Bahan Kunci Masukan (Input Keying Material atau IKM)**, bukan kunci kriptografi siap pakai. Memperlakukan IKM mentah langsung sebagai kunci enkripsi melanggar dua prinsip utama pengelolaan kunci produksi:

1. Tidak Adanya Pengikatan Tujuan (Purpose Binding): Aplikasi terenkripsi di dunia nyata jarang hanya membutuhkan satu kunci. Aplikasi mungkin memerlukan kunci AES-256-GCM untuk mengenkripsi isi catatan, kunci terpisah untuk mengenkripsi lampiran berkas, dan kunci HMAC untuk memeriksa keutuhan metadata lokal. Memasukkan deretan bita mentah yang sama ke berbagai algoritma berbeda tanpa pemisahan domain akan merusak jaminan keamanan kriptografis.
2. Bencana Kehilangan Autentikator: Bayangkan sebuah aplikasi mengambil kunci turunan dari YubiKey atau ponsel Anda lalu memakainya secara langsung untuk mengenkripsi 10.000 foto dan dokumen penting. Enam bulan kemudian, ponsel Anda hancur dalam kecelakaan atau YubiKey Anda terjatuh di perjalanan. Karena setiap kredensial passkey membangkitkan nilai CredRandom unik yang tidak bisa diekspor saat pertama kali dibuat, YubiKey pengganti yang baru Anda beli akan menghasilkan keluaran PRF 32-bita yang sama sekali berbeda meskipun diberi nilai garam yang persis sama. Apabila data Anda dienkripsi langsung menggunakan kunci PRF dari passkey pertama, kehilangan perangkat keras tersebut berarti seluruh data Anda terkunci secara matematis selamanya.

Untuk mengatasi kedua masalah tersebut sekaligus, arsitektur aplikasi zero-knowledge modern memadukan standar **IETF RFC 5869 (HKDF, yakni HMAC-based Extract-and-Expand Key Derivation Function) dengan pola berlapis yang dikenal sebagai Envelope Encryption (Enkripsi Amplop)**.

Pertama, sebagaimana diterapkan pada kode penyimpanan kunci proyek **wwWallet** Eropa dan arsitektur rujukan WebAuthn milik Yubico, peramban segera memasukkan bita mentah prfResults ke dalam antarmuka native Web Crypto API (window.crypto.subtle.importKey) sebagai kunci induk HKDF mentah dengan atribut extractable: false dan izin penggunaan yang dibatasi ketat hanya untuk ['deriveKey']. Sesaat setelah panggilan importKey selesai, aplikasi langsung menimpa ArrayBuffer JavaScript yang menampung bita mentah prfResults tadi dengan angka nol.

Selanjutnya, aplikasi memanggil crypto.subtle.deriveKey() menggunakan algoritma HKDF berbasis SHA-256 disertai parameter konteks info yang eksplisit, misalnya new TextEncoder().encode("AES-GCM Vault Key Encryption Key V1"), guna menurunkan objek CryptoKey AES-GCM 256-bit yang juga berstatus extractable: false. Karena objek CryptoKey hasil turunan ini menetap di dalam memori kriptografi terisolasi milik mesin peramban dengan status tidak dapat diekspor, kode JavaScript dapat meminta peramban mendekripsi data menggunakan kunci tersebut, namun andaikata penyerang berhasil menyisipkan skrip berbahaya di tengah sesi, mereka tetap tidak bisa memanggil exportKey() untuk mencuri bita kunci mentahnya.

Kedua, demi menjamin bahwa hilangnya ponsel atau kunci keamanan fisik tidak pernah menghanguskan isi brankas pengguna, aplikasi menempatkan kunci hasil turunan HKDF tadi sebagai **Kunci Enkripsi Kunci (Key Encryption Key atau KEK)** di dalam hierarki Envelope Encryption:

Arsitektur Envelope Encryption (Siap Multi-Passkey & Pemulihan Darurat):

                    [Data Brankas Pengguna / Catatan / Sandi]
                                      |
                        Dienkripsi sekali via AES-256-GCM
                                      |
                 [Kunci Enkripsi Data Utama (DEK / 256-bit)]
                   /                  |                   \
     Dibungkus KEK_1          Dibungkus KEK_2          Dibungkus KEK_3
            |                         |                         |
  [Passkey 1: Ponsel]      [Passkey 2: YubiKey]     [Kode Pemulihan Darurat]
  (via WebAuthn PRF)       (via WebAuthn PRF)       (via Argon2id / PBKDF2)

Berikut adalah cara kerja Envelope Encryption dalam menjaga ketahanan penyimpanan zero-knowledge berbasis passkey di kehidupan sehari-hari:

• **Kunci Enkripsi Data (DEK)**: Saat Anda membuat brankas akun, peramban membangkitkan satu kunci simetris acak 256-bit (DEK). Seluruh catatan, kata sandi, dan dokumen di dalam brankas Anda dienkripsi menggunakan satu DEK ini.
• **Membungkus DEK dengan Passkey 1 (KEK_1)**: Ketika Anda mendaftarkan passkey utama, peramban mengevaluasi ekstensi PRF, menjalankan HKDF untuk menghasilkan KEK_1, lalu mengenkripsi (membungkus) salinan DEK sepanjang 32-bita tadi. Bungkusan terenkripsi itu (Wrapped_DEK_1) diunggah ke server berdampingan dengan ID Kredensial 1.
• **Menambahkan Passkey Cadangan (KEK_2, KEK_3)**: Selagi brankas Anda terbuka, Anda mendaftarkan YubiKey cadangan atau Kode Pemulihan Darurat tercetak. Peramban menurunkan KEK_2 dari keluaran PRF passkey kedua, mengenkripsi salinan kedua dari DEK yang sama (Wrapped_DEK_2), lalu menyimpannya berdampingan dengan ID Kredensial 2.

Saat Anda masuk dari perangkat mana pun dan menyentuh Passkey 1, server mengirimkan Wrapped_DEK_1, passkey Anda menghitung KEK_1 lewat PRF, dan peramban membuka bungkusan DEK dalam hitungan milidetik untuk mendekripsi brankas Anda. Apabila Passkey 1 hilang di perjalanan, Anda cukup masuk memakai Passkey 2, yang menghitung KEK_2 lewat PRF dan membuka Wrapped_DEK_2 guna memulihkan DEK yang sama persis. Anda kemudian tinggal menghapus Passkey 1 beserta Wrapped_DEK_1 dari pengaturan akun tanpa perlu mengenkripsi ulang data brankas Anda.

Lebih menarik lagi, spesifikasi W3C WebAuthn Level 3 menyiapkan mekanisme bawaan untuk rotasi kunci atomik yang selaras dengan pedoman **NIST SP 800-57**. Karena kamus masukan prf.eval menerima dua nilai garam sekaligus (first dan second), aplikasi yang memperbarui KEK pengguna dari salt_v1 ke salt_v2 cukup mengirimkan first: salt_v1 dan second: salt_v2 dalam satu panggilan navigator.credentials.get(). Hanya dengan satu sentuhan biometrik, autentikator mengembalikan results.first sekaligus results.second, memungkinkan peramban membuka DEK dengan kunci lama dan membungkusnya kembali di bawah kunci baru dalam satu transaksi utuh.

Peralihan WebAuthn PRF dari naskah spesifikasi W3C menuju perangkat lunak konsumen harian kini sudah mengubah cara platform keamanan utama menangani proses masuk dan dekripsi brankas.

Pada Bitwarden, pengguna yang masuk ke brankas web atau ekstensi peramban berbasis Chromium dapat mendaftarkan hingga lima passkey pada akun gratis (dan hingga sepuluh passkey pada akun berbayar) dengan mengaktifkan opsi "Use for vault encryption" (Gunakan untuk enkripsi brankas). Berdasarkan dokumentasi arsitektur keamanan Bitwarden, saat pengguna mendaftarkan passkey yang mendukung PRF untuk enkripsi brankas, aplikasi klien Bitwarden menjalankan upacara kriptografi empat tahap:

1. Autentikator membangkitkan pasangan kunci autentikasi WebAuthn sekaligus mengevaluasi ekstensi prf memakai garam dari Bitwarden untuk menghasilkan kunci simetris PRF 32-bita yang deterministik.
2. Klien Bitwarden membangkitkan pasangan kunci publik dan kunci privat PRF secara lokal di dalam peramban.
3. Klien menggunakan kunci publik PRF untuk mengenkripsi Account Encryption Key (Kunci Enkripsi Akun) utama milik pengguna, dan menggunakan kunci simetris PRF dari autentikator untuk mengenkripsi kunci privat PRF.
4. Klien mengunggah ID kredensial passkey, kunci publik WebAuthn, kunci publik PRF, Account Encryption Key yang telah terenkripsi PRF, serta kunci privat PRF yang telah terenkripsi ke server Bitwarden.

Ketika pengguna kembali ke sesi Bitwarden yang terkunci dan mengeklik "Log in with passkey", mereka tidak perlu lagi mengetik alamat surel, master password, ataupun kode verifikasi dua langkah. Cukup dengan menyentuhkan YubiKey atau biometrik passkey, identitas mereka terverifikasi lewat WebAuthn sekaligus kunci simetris PRF 32-bita terbentuk kembali secara lokal. Kunci simetris tersebut langsung mendekripsi kunci privat PRF, yang kemudian mendekripsi Account Encryption Key dan membuka seluruh isi brankas kata sandi dalam satu langkah tunggal. Apabila pengguna mendaftarkan passkey dari perangkat yang belum mendukung ekstensi prf, Bitwarden otomatis menyesuaikan alur: passkey tetap mengizinkan pengguna masuk tanpa mengetik surel dan kode 2FA, lalu Bitwarden hanya meminta master password untuk membuka enkripsi brankas.

1Password memperluas dukungan PRF dari arah ekosistem yang saling melengkapi: menjadikan aplikasi pengelola kata sandi itu sendiri sebagai penyedia passkey yang mendukung PRF. Selain menguji pembukaan brankas akun dengan passkey, 1Password membangun dukungan penuh WebAuthn PRF ke dalam pustaka Rust sumber terbuka miliknya (passkey-crates), ekstensi peramban, serta aplikasi Android dan iOS. Ketika Anda menyimpan passkey situs web pihak ketiga di dalam brankas 1Password, 1Password ikut membangkitkan dan menyimpan kunci internal PRF untuk kredensial tersebut. Saat Anda mengunjungi aplikasi web terenkripsi ujung-ke-ujung lalu masuk memakai passkey yang tersimpan di 1Password, 1Password mencampurkan garam dari aplikasi web tersebut dengan kunci ketiga tadi dan mengembalikan rahasia deterministik 32-bita ke peramban, memungkinkan pengembang membangun layanan zero-knowledge tanpa memaksa pengguna membuat kata sandi baru.

Sementara itu di ranah infrastruktur publik Eropa, proyek sumber terbuka **wwWallet**, yang dikembangkan dalam tantangan inovasi FUNKE oleh SPRIND Jerman untuk kerangka kerja **European Digital Identity (EUDI) Wallet, menjadikan WebAuthn PRF sebagai fondasi arsitektur dompet identitas warga negara non-kustodian**. Dengan menurunkan kunci enkripsi penyimpanan AES-GCM secara langsung dari kunci keamanan FIDO2 atau passkey perangkat warga melalui prf dan HKDF, server wwWallet hanya menyimpan bongkahan data terenkripsi sembari menjaga pengalaman pengguna tetap semudah menempelkan sidik jari di layar ponsel.

Sebelum Anda membuang kertas catatan master password dan menggantungkan seluruh kehidupan digital pada satu passkey, sangat penting untuk melihat peta kesiapan perangkat keras, sistem operasi, dan peramban secara jujur. Karena setiap panggilan WebAuthn prf harus melewati Mesin Peramban Web, Antarmuka WebAuthn Sistem Operasi, dan Firmware Autentikator atau Penyedia Sinkronisasi Passkey, tingkat dukungannya bergantung pada kombinasi perangkat yang Anda gunakan.

Berikut adalah lanskap kompatibilitas teknis yang terverifikasi lintas platform dan autentikator pada tahun 2026:

• Peramban Berbasis Chromium (Google Chrome, Microsoft Edge, Brave, Vivaldi, Opera): Menyediakan implementasi ekstensi WebAuthn prf paling matang di Windows, macOS, Linux, serta Android, mendukung penuh parameter eval maupun evalByCredential, menerapkan perhitungan hash awalan "WebAuthn PRF" SHA-256, dan meneruskan perintah hmac-secret secara mulus ke kunci perangkat keras USB/NFC maupun pengelola kredensial platform.
• Kunci Keamanan Perangkat Keras FIDO2 (YubiKey 5 Series, YubiKey Bio Series, Nitrokey 3, Token2): Hampir seluruhnya mendukung penuh di tingkat perangkat keras karena ekstensi CTAP2 hmac-secret telah tertanam di firmware FIDO2 sejak bertahun-tahun lalu, asalkan peramban dan sistem operasi mengizinkan parameter tersebut lewat menuju port USB atau NFC.
• Penyedia Passkey Tersinkronisasi (1Password, Google Password Manager, iCloud Keychain): Mendukung evaluasi ekstensi prf langsung dari passkey yang disinkronkan pada perangkat Android modern, iOS/macOS, dan profil desktop Chromium. Catatan arsitekturnya: rahasia akar PRF pada passkey tersinkronisasi ikut mengalir melalui jaringan sinkronisasi awan terenkripsi milik penyedia layanan, sedangkan nilai CredRandom pada kunci perangkat keras fisik seperti YubiKey terisolasi permanen di dalam chip silikon tahan bongkar.
• Ekosistem Apple WebKit / Safari dan Kunci Perangkat Keras Eksternal: Meskipun Apple telah menambahkan dukungan prf untuk passkey platform di dalam iCloud Keychain pada iOS, iPadOS, dan macOS modern, kunci keamanan FIDO2 eksternal (seperti YubiKey via USB-C atau NFC) menghadapi keterbatasan jembatan CTAP pada WebKit (tiket WebKit Bugzilla #259934). Sebagaimana dicatat dalam panduan Bitwarden dan Yubico, pengguna macOS yang ingin membuka enkripsi brankas memakai YubiKey fisik saat ini perlu masuk melalui peramban berbasis Chromium, bukan Safari.
• Autentikator Platform Windows Hello: Windows 11 mendukung CTAP2 hmac-secret untuk kunci keamanan eksternal dan akses masuk luring korporat, sedangkan sistem Windows 10 lama memiliki keterbatasan ketika menggabungkan evaluasi PRF dengan alur login dua langkah sekaligus.

Baik Anda seorang pengguna harian yang hendak mengaktifkan pembukaan brankas tanpa kata sandi maupun rekayasawan perangkat lunak yang sedang merancang aplikasi web terenkripsi, tiga langkah praktis berikut akan menjaga data Anda tetap aman sekaligus terhindar dari risiko terkunci permanen:

1. Jangan Pernah Mengandalkan Satu Autentikator Tunggal untuk Enkripsi: Sebelum menonaktifkan kolom kata sandi pada aplikasi terenkripsi apa pun, daftarkan sedikitnya dua jalur dekripsi independen di dalam pengaturan Envelope Encryption, misalnya satu passkey biometrik harian ditambah satu kunci keamanan fisik FIDO2 cadangan atau Kode Pemulihan Darurat tercetak di tempat terpisah.
2. **Periksa Kapabilitas Perangkat Sebelum Meminta Enkripsi (getClientCapabilities dan prf.enabled)**: Gunakan await PublicKeyCredential.getClientCapabilities("public-key") untuk memeriksa dukungan prf, pastikan newCredential.getClientExtensionResults()?.prf?.enabled === true seusai pendaftaran, dan sediakan tampilan fallback menuju kata sandi pemulihan bila perangkat belum mendukung.
3. Gunakan Garam Unik per Kredensial dan Kunci Web Crypto Non-Ekstrak: Bangkitkan garam acak kriptografis 32-bita yang unik per kredensial (evalByCredential), masukkan keluaran 32-bita PRF ke crypto.subtle.importKey('raw', prfOutput, 'HKDF', false, ['deriveKey']), turunkan kunci AES-GCM 256-bit dengan label konteks info yang tegas, lalu hapus bita sementara di memori dengan angka nol.

Selama lebih dari satu dekade, keamanan tinggi di web memaksakan kompromi yang melelahkan: Anda bisa menikmati kecepatan passkey perangkat keras yang kebal pancingan, atau Anda bisa melindungi berkas pribadi dengan enkripsi ujung-ke-ujung berprinsip zero-knowledge, tetapi menggabungkan keduanya berarti kembali mengetik master password yang panjang. Dengan mengajari autentikator cara menghitung rahasia deterministik yang terisolasi per domain di dalam perangkat keras tanpa sekalipun menyerahkan kunci privatnya, ekstensi WebAuthn PRF menuntaskan kepingan terakhir dalam kriptografi tanpa kata sandi. Passkey kini tidak lagi sekadar menyebut nama Anda di depan gerbang, melainkan langsung memutar gerendel baja pada brankas pribadi Anda.

*Sumber: W3C Web Authentication (WebAuthn) Level 3 Specification: Section 10.1.4 Pseudo-random function extension (prf), FIDO Alliance Client to Authenticator Protocol (CTAP) v2.1: Section 12.5 HMAC Secret Extension, Yubico Developers: A Developer's Guide to Deriving Keys with WebAuthn PRF and YubiKeys, Yubico Developers: Under the Hood, A Security Deep Dive into CTAP2 hmac-secret, Bitwarden Official Blog: PRF WebAuthn and its role in passkeys, Bitwarden Help Center: Log in with Passkeys, 1Password Blog: 1Password can now encrypt data using your saved passkeys, dan IETF RFC 5869: HMAC-based Extract-and-Expand Key Derivation Function (HKDF).*