Counter Tanda Tangan WebAuthn Adalah Sinyal Kloning, Bukan Bukti Identitas

Relying party dapat memverifikasi assertion WebAuthn yang valid dan tetap menerima nilai counter yang tidak memberikan bukti berguna mengenai kloning credential. Tanda tangan membuktikan penguasaan private key credential untuk assertion yang ditandatangani. Field signCount memiliki peran yang lebih sempit: ketika authenticator memelihara counter tanda tangan yang dapat digunakan, perubahan nilainya dapat memberi relying party indikasi bahwa credential yang sama mungkin aktif di lebih dari satu tempat.

Pemisahan ini penting karena penanganan counter kadang diperlakukan sebagai bagian dari keputusan autentikasi inti. Counter bukan bukti identitas kedua. Ia merupakan sinyal berbasis state yang nilai keamanannya bergantung pada data yang dilaporkan authenticator, state yang sebelumnya disimpan relying party, dan apakah credential secara sah dapat tersedia di beberapa perangkat.

Counter berada di dalam data yang diautentikasi

Assertion WebAuthn memuat authenticatorData, yang mencakup hash identifier relying party, flags, dan signCount berupa unsigned integer 32-bit. Authenticator menandatangani data yang mencakup struktur ini, sehingga relying party yang berhasil memverifikasi assertion dapat memperlakukan nilai counter sebagai bagian dari pesan yang telah diautentikasi.

Keaslian field tersebut tidak berarti setiap authenticator menggunakannya sebagai counter per-credential yang selalu meningkat. WebAuthn mengizinkan perilaku counter yang tidak menyediakan properti itu. Karena itu, relying party perlu menafsirkan nilainya sesuai aturan protokol, bukan menganggap setiap assertion yang berhasil selalu menaikkan urutan unik milik credential.

State yang relevan berada di kedua sisi. Authenticator dapat memelihara counter dan mengembalikan nilainya saat ini. Relying party dapat menyimpan nilai terbesar yang telah diterima untuk credential tersebut. Assertion berikutnya kemudian dapat dibandingkan dengan state tersimpan itu.

Perbandingan ini membentuk mekanisme deteksi, bukan binding kriptografis ke satu perangkat fisik.

Nilai yang tidak meningkat dapat menandakan state credential terduplikasi

Misalkan sebuah credential memiliki counter 40, lalu private key beserta state counter-nya diduplikasi pada titik tersebut. Satu salinan menghasilkan assertion yang menaikkan counter menjadi 41 lalu 42. Relying party menyimpan 42. Jika salinan lain kemudian menghasilkan assertion dengan nilai 41, tanda tangannya tetap dapat valid karena kedua salinan menguasai private key credential yang sama.

Regresi counter menjadi sinyal tambahan. Relying party telah menerima nilai counter terautentikasi yang tidak konsisten dengan state yang sebelumnya diterima.

Pola tersebut dapat sesuai dengan kondisi state authenticator yang dikloning, tetapi bukan diagnosis lengkap. Semantik counter bervariasi, dan perilaku deployment dapat menciptakan kondisi yang membutuhkan konteks tambahan. Relying party sebaiknya tidak mengubah anomali counter menjadi pernyataan universal tentang kompromi tanpa mempertimbangkan model authenticator dan credential yang digunakan.

Properti keamanan yang penting terletak pada asimetri: penguasaan private key yang disalin dapat memenuhi verifikasi tanda tangan, sedangkan state yang menyimpang dapat mengungkap bahwa lebih dari satu salinan menghasilkan assertion. Counter dengan demikian dapat menampilkan beberapa bentuk duplikasi yang tidak dapat dibedakan hanya melalui verifikasi tanda tangan.

Nilai nol mengubah sinyal yang tersedia

WebAuthn secara eksplisit mengakomodasi authenticator yang tidak menerapkan counter tanda tangan bermakna. Nilai nol karena itu dapat sah. Jika counter tersimpan dan counter yang baru diterima sama-sama nol, relying party tidak memperoleh bukti deteksi kloning dari mekanisme ini.

Kondisi tersebut tidak membuat assertion menjadi tidak valid. Verifikasi tanda tangan, validasi challenge, pemeriksaan origin, binding relying party, kebijakan user presence atau user verification, serta pemeriksaan WebAuthn lain yang berlaku tetap menjadi bagian terpisah dari keputusan autentikasi.

Memperlakukan nol sebagai kegagalan autentikasi akan mencampur sinyal deteksi opsional dengan bukti penguasaan credential. Menganggap nol sebagai bukti bahwa kloning mustahil merupakan kekeliruan sebaliknya. Nilai itu berarti jalur counter ini tidak memberikan bukti pengurutan yang berguna bagi state credential tersebut.

Kebijakan operasional dapat mencatat tidak tersedianya sinyal counter tanpa menyatakannya sebagai pelanggaran protokol.

Credential tersinkronisasi melemahkan interpretasi berbasis perangkat fisik

Deployment passkey membuat interpretasi yang berpusat pada perangkat semakin tidak andal. Sebuah credential dapat tersedia melalui ekosistem yang mendukung sinkronisasi atau backup credential. Dalam model seperti ini, pertanyaan keamanan yang relevan tidak selalu berupa apakah satu credential privat hanya ada pada satu perangkat keras.

WebAuthn mengekspos flags terkait backup secara terpisah dari signCount. Sinyal tersebut memungkinkan relying party menilai properti credential tanpa memberikan arti pada counter yang tidak dijamin oleh protokol.

Relying party yang mensyaratkan credential terikat perangkat keras memerlukan kebijakan dan model credential yang mendukung persyaratan tersebut. Counter tanda tangan tidak dapat membuktikan eksklusivitas perangkat keras dengan sendirinya. Bahkan counter yang terus meningkat hanya menunjukkan urutan nilai terautentikasi yang konsisten dengan state tersimpan; hal itu tidak membuktikan bahwa salinan lain dari material credential tidak ada.

Batas ini sangat penting ketika kebijakan keamanan membedakan passkey tersinkronisasi dari credential yang disimpan pada security key khusus. Perbedaan tersebut harus berasal dari properti authenticator dan credential yang didukung, bukan dari asumsi bahwa urutan counter yang sehat sama dengan satu authenticator fisik.

Pemeriksaan counter membutuhkan state relying party yang atomik

Perbandingan counter yang berguna juga bergantung pada kontrol konkurensi di sisi server. Pertimbangkan dua assertion valid untuk credential yang sama yang tiba hampir bersamaan. Jika dua worker aplikasi membaca nilai tersimpan yang sama sebelum salah satu update di-commit, rangkaian check-and-write yang naif dapat menghasilkan state yang menyesatkan.

Relying party perlu memperlakukan perbandingan counter dan pembaruan state sebagai satu persoalan konsistensi. Implementasi tepatnya bergantung pada datastore, tetapi invariant-nya sederhana: state counter yang telah diterima tidak boleh bergerak mundur akibat dua request yang berpacu di application layer.

Untuk credential dengan semantik counter yang mendukung perbandingan monotonik, update secara konseptual dapat ditulis sebagai berikut:

received = assertion.authenticatorData.signCount
stored   = credential.signCount

if counter_signal_is_applicable:
    if received <= stored:
        record_counter_anomaly()
    else:
        atomically_advance(stored, received)

Predicate tersebut sengaja dibuat eksplisit. Penanganan counter harus memperhitungkan kondisi ketika mekanisme ini tidak menyediakan sinyal monotonik yang bermakna. Update atomik juga perlu terikat pada assertion yang sudah lolos pemeriksaan kriptografis dan kontekstual yang diwajibkan; request yang belum diautentikasi tidak boleh dapat menaikkan state credential.

Anomali berada di kebijakan risiko, bukan di verifikasi tanda tangan

Batas implementasi yang bersih memisahkan validitas kriptografis dari risiko yang diturunkan melalui counter. Tanda tangan valid menjawab apakah assertion dihasilkan menggunakan private key credential atas data yang diharapkan. Perbandingan counter menjawab apakah state terautentikasi yang baru konsisten dengan state counter yang sebelumnya diterima, ketika perbandingan tersebut memang bermakna.

Deployment dapat merespons anomali sesuai threat model-nya. Sistem dapat meminta faktor autentikasi lain, menandai credential untuk investigasi, memberi notifikasi kepada pemilik akun, membatasi tindakan sensitif, atau menolak assertion. Semua itu merupakan keputusan kebijakan. WebAuthn menyediakan counter terautentikasi dan kondisi untuk menafsirkannya; protokol tidak mengubah setiap nilai counter yang mencurigakan menjadi vonis kompromi akun yang lengkap.

Pemisahan batas tersebut juga memperbaiki bukti insiden. Log dapat membedakan assertion WebAuthn yang gagal dari assertion yang valid secara kriptografis tetapi membawa state counter anomali. Kedua peristiwa itu memiliki penyebab berbeda dan memerlukan jalur investigasi yang berbeda pula.

Properti yang bertahan adalah state terautentikasi, bukan keunikan

signCount paling berguna ketika diperlakukan sesuai sifatnya: state terautentikasi yang dapat mengungkap inkonsistensi antar-assertion. Kekuatannya berasal dari perlindungan tanda tangan credential dan perbandingannya dengan riwayat relying party. Keterbatasannya berasal dari fakta bahwa perilaku counter bukan bukti universal bahwa satu credential berada pada satu perangkat.

Relying party dapat mempertahankan nilai sinyal tersebut dengan menyimpan state counter secara konsisten, menafsirkan nilai nol dan kemampuan credential secara tepat, serta meneruskan regresi ke kebijakan risiko yang eksplisit. Kontrol yang dihasilkan dapat mendeteksi beberapa pola state terduplikasi tanpa membuat klaim yang lebih kuat bahwa counter WebAuthn membuktikan keunikan credential secara fisik.