Menggali Lebih Dalam WebAuthn Attestation: Membangun Kepercayaan dan Keamanan Ekstra pada Autentikasi Tanpa Kata Sandi

1. Pendahuluan

Jika Anda sudah familiar dengan Membangun Autentikasi Tanpa Kata Sandi dengan WebAuthn, Anda mungkin sudah merasakan betapa revolusionernya autentikasi tanpa kata sandi. WebAuthn tidak hanya menawarkan kemudahan penggunaan, tetapi juga keamanan yang jauh lebih superior dibandingkan kata sandi tradisional, berkat penggunaan kriptografi kunci publik.

Namun, ada satu aspek WebAuthn yang seringkali disederhanakan atau bahkan diabaikan dalam implementasi awal: Attestation. Bayangkan Anda mendaftarkan sebuah authenticator (misalnya, YubiKey atau Touch ID di MacBook Anda). WebAuthn assertion (proses login) memastikan bahwa Anda adalah pemilik kunci privat yang benar. Tapi bagaimana Anda bisa yakin bahwa authenticator itu sendiri adalah perangkat yang sah dan bukan perangkat lunak palsu yang mencoba meniru authenticator asli? Di sinilah Attestation berperan.

Attestation adalah mekanisme opsional di WebAuthn yang memungkinkan Relying Party (server aplikasi Anda) untuk memverifikasi keaslian dan karakteristik cryptographical dari authenticator yang baru didaftarkan. Ini seperti meminta “sertifikat lahir” untuk authenticator Anda. Jika Anda membangun aplikasi dengan persyaratan keamanan tinggi, kepatuhan regulasi, atau hanya ingin jaminan ekstra, memahami dan mengimplementasikan Attestation adalah langkah penting.

Artikel ini akan membawa Anda lebih dalam ke dunia WebAuthn Attestation, menjelaskan mengapa ini penting, jenis-jenisnya, cara kerjanya, dan bagaimana Anda bisa mengimplementasikannya untuk membangun sistem yang lebih tangguh dan tepercaya. Mari kita mulai! 🚀

2. Apa itu WebAuthn Attestation?

📌 Attestation dalam konteks WebAuthn adalah proses di mana authenticator membuktikan identitas dan integritasnya kepada Relying Party (server Anda) saat pendaftaran kunci kredensial baru. Tujuan utamanya adalah untuk memberikan server kepercayaan tentang properti tertentu dari authenticator yang baru saja membuat pasangan kunci publik/privat.

Singkatnya, ketika pengguna mendaftarkan authenticator baru, authenticator tersebut tidak hanya mengirimkan kunci publiknya, tetapi juga sebuah Attestation Statement. Pernyataan ini berisi informasi tentang authenticator itu sendiri, seperti:

• AAGUID (Authenticator Attestation GUID): Pengidentifikasi unik untuk model atau vendor authenticator.
• Sertifikat Attestation: Sertifikat digital yang ditandatangani oleh pembuat authenticator, yang bisa diverifikasi oleh server Anda.
• Signature: Tanda tangan digital atas data pendaftaran, menggunakan kunci attestation yang dipegang oleh authenticator.

Server kemudian dapat menggunakan informasi ini untuk:

1. Memverifikasi Keaslian Authenticator: Apakah ini benar-benar YubiKey, atau biometrik bawaan OS, atau perangkat lunak yang berpura-pura menjadi authenticator?
2. Menilai Tingkat Keamanan (Security Properties): Apakah authenticator ini mendukung fitur tertentu seperti PIN, biometrik, atau apakah ia berada di dalam hardware yang aman (Trusted Platform Module/TPM)?
3. Mendeteksi Authenticator Malicious/Palsu: Jika Attestation Statement tidak valid atau tidak dapat diverifikasi, server dapat menolak pendaftaran, mencegah penggunaan authenticator yang tidak tepercaya.

Perlu diingat, Attestation adalah proses satu kali yang terjadi saat pendaftaran kredensial. Setelah kredensial terdaftar dan diverifikasi, proses login (assertion) selanjutnya tidak lagi melibatkan Attestation.

3. Jenis-jenis Attestation yang Perlu Anda Tahu

WebAuthn mendukung beberapa format attestation, masing-masing dengan tingkat privasi dan kepercayaan yang berbeda. Memilih jenis yang tepat tergantung pada kebutuhan aplikasi Anda.

3.1. none (Default)

💡 none adalah jenis attestation paling umum dan seringkali menjadi default jika tidak ada permintaan spesifik.

• Cara Kerja: Authenticator tidak memberikan Attestation Statement sama sekali. Server hanya menerima kunci publik dan ID kredensial.
• Kepercayaan: Server tidak memiliki jaminan tentang keaslian authenticator. Ini mengasumsikan bahwa semua authenticator yang kompatibel dengan WebAuthn adalah tepercaya.
• Privasi: Maksimal, karena tidak ada informasi identifikasi tentang authenticator yang dikirim.
• Kapan Digunakan: Untuk sebagian besar aplikasi konsumen di mana privasi pengguna lebih diutamakan dan risiko authenticator palsu dianggap rendah atau dikelola dengan cara lain.

3.2. direct

📌 direct berarti authenticator mengirimkan Attestation Statement secara langsung.

• Cara Kerja: Attestation Statement berisi sertifikat attestation yang ditandatangani oleh authenticator itu sendiri, dan seringkali juga AAGUID.
• Kepercayaan: Tinggi, karena server dapat memverifikasi sertifikat terhadap daftar “trust anchors” (otoritas sertifikat yang dikenal) yang diterbitkan oleh vendor authenticator.
• Privasi: Lebih rendah, karena informasi spesifik tentang model atau vendor authenticator dapat terungkap. Ini bisa digunakan untuk fingerprinting authenticator.
• Kapan Digunakan: Untuk aplikasi yang memerlukan jaminan kuat tentang keaslian hardware authenticator, seperti di lingkungan perusahaan dengan kebijakan keamanan ketat atau untuk akun admin.

3.3. indirect

📌 indirect adalah kompromi antara none dan direct, menawarkan kepercayaan tinggi dengan privasi yang lebih baik.

• Cara Kerja: Authenticator mengirimkan Attestation Statement, tetapi sertifikat attestation itu sendiri mungkin bukan dari authenticator langsung. Sebaliknya, mungkin ada Attestation Certificate Authority (CA) pihak ketiga yang menandatangani sertifikat attestation, atau sertifikat tersebut bisa bersifat anonim (misalnya, sertifikat yang sama digunakan oleh banyak authenticator).
• Kepercayaan: Tinggi, karena server masih dapat memverifikasi sertifikat, tetapi tanpa secara langsung mengidentifikasi authenticator individu.
• Privasi: Sedang hingga tinggi, tergantung pada implementasi CA pihak ketiga. Ini mencegah fingerprinting individu.
• Kapan Digunakan: Pilihan yang baik ketika Anda membutuhkan verifikasi keaslian tetapi ingin menjaga privasi pengguna semaksimal mungkin. Ini adalah pilihan yang disarankan oleh FIDO Alliance.

3.4. enterprise

⚠️ enterprise adalah jenis attestation yang spesifik untuk lingkungan perusahaan.

• Cara Kerja: Memungkinkan Relying Party untuk menentukan kebijakan attestation khusus yang hanya berlaku untuk authenticator yang memenuhi kriteria tertentu yang ditetapkan oleh organisasi.
• Kepercayaan: Sangat tinggi, karena dikustomisasi untuk kebutuhan spesifik perusahaan.
• Privasi: Rendah, karena tujuannya adalah kontrol dan visibilitas penuh terhadap authenticator yang digunakan dalam organisasi.
• Kapan Digunakan: Hanya dalam skenario enterprise di mana organisasi memiliki kontrol penuh atas authenticator yang diizinkan dan memerlukan audit atau manajemen inventaris yang ketat.

Anda dapat meminta jenis attestation ini dengan mengatur properti attestation dalam authenticatorSelection saat membuat PublicKeyCredentialCreationOptions di frontend Anda.

const publicKeyCredentialCreationOptions = {
  // ... properti lainnya
  authenticatorSelection: {
    authenticatorAttachment: 'platform', // atau 'cross-platform'
    userVerification: 'required',
    attestation: 'direct' // Bisa 'none', 'direct', 'indirect', 'enterprise'
  },
  // ...
};

4. Memahami Attestation Statement dan Trust Anchors

Setelah authenticator menghasilkan Attestation Statement, server Anda memiliki tugas untuk memverifikasinya. Proses ini melibatkan dua komponen kunci: Attestation Statement itu sendiri dan Trust Anchors.

4.1. Attestation Statement

Attestation Statement adalah objek data kompleks yang dikirimkan oleh authenticator ke server. Meskipun formatnya bisa bervariasi (misalnya packed, fido-u2f, android-key, android-safetynet, apple), umumnya ia akan berisi:

• Format Attestation: Menunjukkan jenis format attestation yang digunakan (misalnya packed).
• Auth Data (Authenticator Data): Data yang ditandatangani oleh authenticator, berisi informasi penting seperti RP ID Hash, flags (misalnya apakah user present atau user verified), counter, dan credential ID serta public key yang baru dibuat.
• Attestation Signature: Tanda tangan digital atas Auth Data dan Client Data Hash, menggunakan kunci attestation yang ada di authenticator.
• Attestation Certificate Chain: Rangkaian sertifikat digital yang mengarah ke root certificate yang tepercaya. Sertifikat ini membuktikan bahwa kunci attestation adalah sah.
• AAGUID (Authenticator Attestation GUID): Pengidentifikasi unik untuk model atau vendor authenticator. Ini membantu server mengidentifikasi jenis authenticator yang digunakan.

Server Anda perlu mem-parse attestationObject yang diterima dari frontend, yang merupakan CBOR-encoded data. Pustaka WebAuthn server-side akan sangat membantu dalam proses ini.

4.2. Peran Trust Anchors

🎯 Trust Anchors adalah fondasi kepercayaan dalam verifikasi Attestation. Ini adalah kumpulan root certificate yang tepercaya yang dimiliki oleh server Anda. Root certificate ini biasanya diterbitkan oleh vendor authenticator (misalnya, Yubico, Google, Apple) atau oleh organisasi standar seperti FIDO Alliance.

Proses verifikasi Attestation Signature melibatkan:

1. Memverifikasi Attestation Signature: Server menggunakan kunci publik yang ada di sertifikat attestation (yang merupakan bagian dari Attestation Statement) untuk memverifikasi tanda tangan digital yang diberikan oleh authenticator.
2. Memverifikasi Sertifikat Attestation Chain: Server kemudian memverifikasi rantai sertifikat attestation. Ini berarti memeriksa bahwa setiap sertifikat dalam rantai ditandatangani oleh sertifikat berikutnya, hingga mencapai root certificate.
3. Membandingkan dengan Trust Anchors: Root certificate terakhir dalam rantai harus cocok dengan salah satu Trust Anchors yang disimpan oleh server Anda. Jika cocok, server dapat percaya bahwa Attestation Statement itu sah dan authenticator itu asli.

⚠️ Penting: Mengelola Trust Anchors bisa menjadi tantangan. Anda perlu menjaga daftar ini tetap up-to-date dan memastikan hanya root certificate yang benar-benar tepercaya yang ada di dalamnya. Kesalahan dalam manajemen Trust Anchors dapat menyebabkan pendaftaran authenticator yang sah ditolak atau, lebih buruk, authenticator palsu diterima.

5. Implementasi Attestation di Backend Anda

Implementasi Attestation sebagian besar terjadi di sisi backend, di mana server Anda menerima data pendaftaran dari browser dan melakukan verifikasi.

5.1. Permintaan Attestation dari Frontend

Di frontend, saat memanggil navigator.credentials.create(), Anda perlu menambahkan properti attestation di dalam authenticatorSelection.

// Contoh di frontend (JavaScript)
const publicKeyCredentialCreationOptions = {
  challenge: Uint8Array.from('random_challenge_string', c => c.charCodeAt(0)),
  rp: {
    name: 'Nama Aplikasi Anda',
    id: window.location.hostname,
  },
  user: {
    id: Uint8Array.from('user_id_unik', c => c.charCodeAt(0)),
    name: 'username@example.com',
    displayName: 'Nama Pengguna',
  },
  pubKeyCredParams: [
    { type: 'public-key', alg: -7 }, // ES256
    { type: 'public-key', alg: -257 }, // RS256
  ],
  timeout: 60000,
  attestation: 'direct', // Meminta attestation 'direct'
  // atau 'indirect', 'none', 'enterprise'
  authenticatorSelection: {
    authenticatorAttachment: 'platform', // atau 'cross-platform'
    userVerification: 'required',
  },
};

navigator.credentials.create({ publicKey: publicKeyCredentialCreationOptions })
  .then(credential => {
    // Kirim credential ke backend Anda
    console.log(credential);
  })
  .catch(error => {
    console.error('Pendaftaran gagal:', error);
  });

Browser akan menangani komunikasi dengan authenticator dan mengembalikan PublicKeyCredential yang berisi response.attestationObject jika attestation berhasil diminta.

5.2. Verifikasi di Backend

Di backend, Anda akan menerima objek PublicKeyCredential ini. Berikut adalah langkah-langkah verifikasi Attestation secara konseptual:

1. Parse attestationObject: Objek ini biasanya dalam format CBOR (Concise Binary Object Representation) dan perlu di-decode. Setelah di-decode, Anda akan mendapatkan fmt (format attestation) dan attStmt (attestation statement).
2. Verifikasi clientDataJSON dan authenticatorData: Ini adalah bagian standar dari verifikasi pendaftaran WebAuthn, memastikan tantangan (challenge) cocok dan asal (origin) benar.
3. Verifikasi attestationStatement berdasarkan fmt:
   • Jika fmt adalah none: Tidak ada yang perlu diverifikasi terkait attestation. Cukup pastikan attStmt kosong.
   • Jika fmt adalah packed: Ini adalah format paling umum. Anda akan menemukan x5c (rantai sertifikat) dan sig (tanda tangan).
     • Ambil kunci publik dari sertifikat pertama di x5c.
     • Verifikasi sig menggunakan kunci publik tersebut terhadap gabungan authenticatorData dan clientDataHash.
     • Verifikasi seluruh rantai x5c hingga mencapai Trust Anchor yang dikenal