FIDO2 WEBAUTHN ATTESTATION-VERIFICATION BACKEND-SECURITY CRYPTOGRAPHY AUTHENTICATION SECURITY WEB-SECURITY PASSWORDLESS TRUST-MANAGEMENT API-SECURITY

Attestation Verification di FIDO2/WebAuthn: Membangun Kepercayaan dan Keamanan Backend yang Tak Tergoyahkan

⏱️ 13 menit baca
👨‍💻

Attestation Verification di FIDO2/WebAuthn: Membangun Kepercayaan dan Keamanan Backend yang Tak Tergoyahkan

1. Pendahuluan

Autentikasi tanpa kata sandi dengan FIDO2 dan WebAuthn telah merevolusi cara kita mengamankan akun pengguna. Ia menawarkan kenyamanan luar biasa bagi pengguna dan lapisan keamanan yang jauh lebih kuat dibandingkan kata sandi tradisional. Anda mungkin sudah familiar dengan konsep dasar WebAuthn: pengguna mendaftar dengan perangkat biometrik atau kunci keamanan fisik mereka, lalu login dengan sentuhan jari atau perangkat tersebut.

Namun, di balik kemudahan itu, ada sebuah pertanyaan krusial yang harus dijawab oleh setiap developer yang serius tentang keamanan: Bagaimana kita bisa yakin bahwa authenticator (perangkat FIDO2/WebAuthn) yang digunakan pengguna itu asli dan bukan perangkat palsu atau yang dimanipulasi?

Di sinilah konsep Attestation Verification berperan. Attestation adalah proses di mana authenticator membuktikan keasliannya kepada Relying Party (server aplikasi Anda) saat pendaftaran. Ini seperti kartu identitas digital untuk authenticator Anda. Tanpa verifikasi attestation yang tepat, sistem WebAuthn Anda mungkin rentan terhadap serangan menggunakan authenticator yang tidak tepercaya atau bahkan berbahaya.

Artikel ini akan membawa Anda menyelami dunia attestation verification dari sudut pandang backend. Kita akan memahami mengapa ini penting, bagaimana cara kerjanya, dan langkah-langkah praktis untuk mengimplementasikannya, memastikan fondasi keamanan aplikasi WebAuthn Anda benar-benar tak tergoyahkan.

2. Mengapa Attestation Verification Penting?

Bayangkan Anda adalah penjaga gerbang sebuah benteng. Anda tidak hanya perlu memastikan bahwa orang yang masuk adalah orang yang mengakuinya (verifikasi user), tetapi Anda juga ingin memastikan bahwa kartu identitas yang mereka tunjukkan itu asli dan bukan palsu. Attestation verification melakukan hal yang sama untuk authenticator Anda.

Pentingnya attestation verification terletak pada kemampuannya untuk:

Secara sederhana, jika verifikasi assertion (saat login) memastikan siapa yang login, maka verifikasi attestation (saat pendaftaran) memastikan dengan perangkat apa mereka login, dan apakah perangkat itu layak dipercaya.

3. Anatomi Attestation di FIDO2/WebAuthn

Ketika pengguna mendaftarkan authenticator baru, browser akan mengirimkan objek AuthenticatorAttestationResponse ke backend Anda. Objek ini berisi informasi penting, termasuk attestationObject, yang merupakan inti dari proses verifikasi attestation.

Mari kita bongkar attestationObject:

{
  // ... bagian lain dari AuthenticatorAttestationResponse
  "response": {
    "attestationObject": "base64url_encoded_cbor_data",
    // ...
  }
}

attestationObject sebenarnya adalah data yang dienkode dalam format CBOR (Concise Binary Object Representation). Setelah didekode, Anda akan menemukan struktur seperti ini:

{
  "fmt": "packed", // Format attestation
  "authData": "base64url_encoded_auth_data", // Data autentikator
  "attStmt": { // Attestation Statement
    "alg": -7,
    "sig": "base64url_encoded_signature",
    "x5c": [ // Rantai sertifikat (opsional, tergantung format)
      "base64url_encoded_cert_1",
      "base64url_encoded_cert_2"
    ]
  }
}

Mari kita pahami komponen utamanya:

4. Proses Verifikasi Attestation di Backend (Langkah-demi-Langkah)

Verifikasi attestation adalah proses multi-langkah yang melibatkan kriptografi dan pemeriksaan data. Jangan khawatir, Anda tidak perlu mengimplementasikan semua ini dari nol! Ada banyak library FIDO2/WebAuthn yang akan sangat membantu. Namun, memahami langkah-langkah di baliknya sangat penting.

Berikut adalah gambaran umum proses verifikasi attestation di backend:

📌 Langkah 1: Dekode dan Verifikasi authData

Ini adalah langkah pertama dan mutlak yang harus dilakukan, terlepas dari format attestation.

  1. Dekode attestationObject: Ambil attestationObject (yang dienkode base64url dan CBOR) dan dekode menjadi objek yang dapat dibaca.
  2. Ekstrak authData: Dapatkan authData mentah (binary) dari attestationObject.
  3. Verifikasi RP ID Hash: Pastikan hash ID Relying Party (RP ID) di dalam authData cocok dengan hash ID situs web Anda. Ini mencegah serangan cross-origin. 
    // Contoh pseudo-code (menggunakan library seperti @simplewebauthn/server)
// const verification = await verifyRegistrationResponse({
//   response: attestationResponse,
//   expectedChallenge: challenge,
//   expectedOrigin: origin,
//   expectedRPID: rpId,
// });
// const { authenticatorInfo } = verification;
// const { rpIdHash } = authenticatorInfo;
// if (rpIdHash !== calculateHash(rpId)) {
//   throw new Error('RP ID Hash mismatch');
// }
  4. Periksa Flag: Pastikan flag UP (User Present) dan UV (User Verified) disetel sesuai kebijakan Anda. Flag AT (Attested Credential Data Included) juga harus disetel jika Anda mengharapkan attestation.
  5. Simpan signCount: Simpan nilai signCount sebagai dasar untuk verifikasi assertion di masa mendatang. Ini membantu mendeteksi replikasi authenticator.
  6. Ekstrak Kunci Publik Kredensial: Dari authData, Anda juga akan mendapatkan kunci publik kredensial baru (credentialPublicKey) yang akan digunakan untuk verifikasi assertion (login) di masa mendatang.

📌 Langkah 2: Verifikasi attStmt Berdasarkan Format

Setelah authData diverifikasi, langkah selanjutnya adalah memverifikasi attStmt sesuai dengan fmt yang dilaporkan. Ini adalah bagian yang paling bervariasi dan kompleks.

🎯 Contoh: Format packed (Paling Umum)

Format packed adalah yang paling fleksibel dan banyak digunakan. Verifikasinya bisa melibatkan sertifikat atau hanya tanda tangan.

  1. Jika x5c (rantai sertifikat) ada:

    • Verifikasi Rantai Sertifikat: Bangun rantai kepercayaan (chain of trust) dari sertifikat daun (leaf certificate) yang disediakan oleh authenticator hingga ke sertifikat root yang tepercaya.
    • Periksa Sertifikat Root: Pastikan sertifikat root berada dalam daftar sertifikat root tepercaya yang Anda kelola (misalnya, dari FIDO Metadata Service).
    • Ekstrak Kunci Publik Attestation: Dapatkan kunci publik dari sertifikat daun.
    • Verifikasi Tanda Tangan (Signature): Gunakan kunci publik attestation yang diekstrak untuk memverifikasi tanda tangan (sig) yang ada di attStmt. Data yang ditandatangani adalah gabungan dari authData mentah dan hash dari clientDataJSON (yang diterima dari frontend).
    // Pseudo-code untuk verifikasi packed format dengan x5c
function verifyPackedAttestation(attestationObject, clientDataHash) {
    const { fmt, authData, attStmt } = attestationObject;
    if (fmt !== 'packed') throw new Error('Invalid format');

    const x5c = attStmt.x5c; // Array of certificates
    if (!x5c || x5c.length === 0) {
        // Handle self-attestation or other packed types if allowed
        throw new Error('Packed attestation without x5c not supported or allowed');
    }

    // 1. Dapatkan sertifikat daun (leaf certificate)
    const leafCert = x5c[0];
    // 2. Verifikasi rantai sertifikat (misalnya, terhadap FIDO MDS atau daftar root CA tepercaya)
    //    Ini adalah bagian yang kompleks dan biasanya ditangani oleh library kriptografi.
    //    Pastikan sertifikat valid, tidak dicabut, dan berasal dari CA yang tepercaya.

    // 3. Ekstrak kunci publik dari leafCert
    const publicKey = extractPublicKeyFromCertificate(leafCert);

    // 4. Buat data yang ditandatangani
    const signatureBase = Buffer.concat([authData, clientDataHash]);

    // 5. Verifikasi tanda tangan
    const signatureValid = verifySignature(publicKey, signatureBase, attStmt.sig, attStmt.alg);

    if (!signatureValid) {
        throw new Error('Attestation signature verification failed');
    }
    // Jika semua lolos, attestation valid
}

  2. Jika x5c tidak ada (misalnya, self-attestation atau ECDAA):

    • Untuk packed dengan self-attestation, Anda hanya perlu memverifikasi bahwa tanda tangan sig valid menggunakan kunci publik kredensial yang ada di authData. Ini memberikan jaminan yang lebih rendah karena tidak ada pihak ketiga yang mengesahkan authenticator.

🎯 Contoh: Format android-safetynet

Untuk perangkat Android, Anda akan menerima token JWS (JSON Web Signature) dari Google SafetyNet.

  1. Verifikasi JWS: Pastikan token ditandatangani oleh Google.
  2. Dekode Payload: Dekode payload JWS untuk mendapatkan laporan integritas SafetyNet.
  3. Periksa Status Integritas: Pastikan ctsProfileMatch dan basicIntegrity adalah true.
  4. Verifikasi Nonce: Pastikan nonce di dalam laporan SafetyNet cocok dengan hash dari authData dan clientDataJSON Anda.

🎯 Contoh: Format apple

Untuk perangkat Apple (Touch ID/Face ID), Anda akan menerima attestation statement khusus.

  1. Verifikasi Sertifikat: Mirip dengan packed, verifikasi rantai sertifikat Apple.
  2. Periksa Ekstensi Sertifikat: Pastikan ekstensi sertifikat berisi informasi yang sesuai dengan format Apple.
  3. Verifikasi Tanda Tangan: Verifikasi tanda tangan menggunakan kunci publik dari sertifikat.

💡 Gunakan Library FIDO2/WebAuthn!

Mengimplementasikan verifikasi attestation dari nol adalah tugas yang sangat kompleks dan rentan kesalahan. Kesalahan kriptografi bisa berakibat fatal. Sangat disarankan untuk menggunakan library FIDO2/WebAuthn yang sudah teruji dan diaudit.

Library ini akan mengurus sebagian besar kerumitan dekode CBOR, parsing authData, dan verifikasi tanda tangan/sertifikat untuk berbagai format attestation. Fokus Anda adalah mengonfigurasi kebijakan dan daftar akar kepercayaan.

5. Membangun Kebijakan Kepercayaan (Trust Policies)

Setelah Anda memahami mekanisme verifikasi, langkah berikutnya adalah menentukan kebijakan kepercayaan Anda. Tidak semua attestation diciptakan sama, dan Anda mungkin tidak ingin menerima setiap authenticator yang mencoba mendaftar.

❌ Jangan terima semua attestation tanpa kebijakan: Menerima fmt: 'none' atau authenticator dengan sertifikat yang tidak dikenal secara default bisa melemahkan keamanan Anda.

✅ Tentukan Tingkat Kepercayaan yang Dibutuhkan:

✅ Filter AAGUID (Authenticator Attestation GUID): Setiap authenticator yang mendukung attestation biasanya memiliki AAGUID yang unik untuk model atau vendor tertentu. Anda dapat menggunakan ini untuk:

✅ Manfaatkan FIDO Metadata Service (MDS): FIDO Alliance menyediakan Metadata Service (MDS) yang berisi informasi tentang ribuan authenticator FIDO yang berbeda, termasuk sertifikat root untuk verifikasi attestation, AAGUID, dan informasi tentang status keamanan (misalnya, apakah ada kerentanan yang diketahui). Mengintegrasikan MDS ke backend Anda memungkinkan Anda untuk:

6. Tantangan dan Pertimbangan Lanjutan

Implementasi attestation verification bisa jadi rumit, dan ada beberapa tantangan serta pertimbangan yang perlu Anda perhatikan:

Kesimpulan

Autentikasi tanpa kata sandi dengan FIDO2/WebAuthn adalah masa depan keamanan web, menawarkan pengalaman pengguna yang mulus dan perlindungan yang kuat. Namun, untuk benar-benar mengamankan aplikasi Anda, Anda tidak bisa berhenti pada implementasi dasar. Attestation verification adalah lapisan keamanan krusial di sisi backend yang memastikan keaslian authenticator, melindungi Anda dari perangkat palsu, dan membangun fondasi kepercayaan yang kuat.

Meskipun prosesnya bisa kompleks, dengan pemahaman yang tepat tentang anatomi attestation dan penggunaan library FIDO2/WebAuthn yang teruji, Anda dapat mengimplementasikan verifikasi attestation yang efektif. Jangan lupakan untuk merancang kebijakan kepercayaan yang sesuai dengan kebutuhan keamanan aplikasi Anda, dan pertimbangkan untuk memanfaatkan FIDO Metadata Service untuk manajemen kepercayaan yang lebih dinamis.

Dengan attestation verification, Anda tidak hanya memverifikasi siapa pengguna Anda, tetapi juga dengan perangkat apa mereka mengakses sistem Anda, dan apakah perangkat itu layak mendapatkan kepercayaan Anda. Ini adalah langkah proaktif menuju ekosistem web yang lebih aman dan tangguh.

🔗 Baca Juga