WebAuthn pubKeyCredParams & credentialPublicKey: CBOR & COSE

Dalam keamanan digital, passkey adalah standar baru tanpa kata sandi. Inti dari passkey adalah kriptografi kunci publik, yang digunakan dalam protokol WebAuthn yang menjadi dasar passkey. Memahami bagaimana kriptografi kunci publik digunakan dalam WebAuthn, terutama dalam membuat, mengekstrak, mengelola, dan menyimpan passkey, sangat penting saat merancang atau menggunakan autentikasi passkey. Kunci publik disimpan di server relying party (RP), yang merupakan backend situs web yang ingin mengautentikasi pengguna melalui passkey, dan kunci privat disimpan dengan aman di Modul Keamanan Perangkat Keras, tergantung pada sistem operasi, seperti Secure Enclave (iOS), TEE (Android), atau TPM (Windows).

Dalam postingan blog ini, kita akan membahas secara singkat dasar-dasar kriptografi kunci publik yang digunakan dalam passkey. Pertanyaan-pertanyaan berikut akan terjawab di akhir postingan blog ini:

• Algoritma enkripsi mana yang didukung di WebAuthn
• Bagaimana cara kerja pubKeyCredParams saat membuat pasangan kunci?
• Bagaimana cara kerja credentialPublicKey saat mengekstrak kunci publik yang dibuat?

Untuk memahami cara kerja kriptografi kunci publik dalam WebAuthn, kita akan melihat sekilas cara kerjanya secara umum dan apa saja jenis algoritma yang umum digunakan.

Kriptografi kunci publik, juga dikenal sebagai kriptografi asimetris, berbeda dengan kriptografi simetris di mana kunci yang sama digunakan untuk enkripsi dan dekripsi. Kriptografi asimetris menggunakan dua kunci yang berbeda – kunci publik, yang dapat dibagikan secara terbuka, dan kunci privat, yang dirahasiakan oleh pemiliknya.

Diambil dari: https://en.wikipedia.org/wiki/Public-key_cryptography

Metode ini tidak hanya memungkinkan enkripsi data untuk mengamankan kerahasiaannya, tetapi juga memungkinkan untuk menandatangani pesan. Penandatanganan memverifikasi identitas pengirim dan memastikan bahwa pesan belum diubah, sehingga mengonfirmasi keaslian dan integritasnya.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Berikut adalah gambaran umum beberapa jenis algoritma yang umum digunakan dalam kriptografi kunci publik:

Dasar matematika dari kriptografi kurva eliptik (ECC), termasuk ECDSA dan EdDSA, melibatkan sifat-sifat kurva eliptik yang tidak akan kita bahas dalam artikel ini. Namun, dari tabel di atas, jelas terlihat ada keuntungan yang mendorong adopsi mereka. Kita akan membahas yang paling penting di bagian selanjutnya.

Become part of our Passkeys Community for updates & support.

Join

Kriptografi kurva eliptik telah banyak diadopsi untuk perangkat seluler karena mereka mendapat manfaat dari ukuran kunci yang lebih kecil, yang membawa keuntungan berikut:

• Mengurangi Kebutuhan Penyimpanan: Kunci ECC yang lebih kecil membutuhkan lebih sedikit ruang penyimpanan dibandingkan dengan metode kriptografi tradisional seperti RSA. Ini sangat bermanfaat untuk perangkat dengan sumber daya memori terbatas, memungkinkan penggunaan ruang yang lebih efisien. Tabel berikut menunjukkan perkiraan tingkat keamanan yang sebanding dan ukuran sebenarnya dari kunci yang digunakan. Tingkat keamanan diukur dalam bit dan biasanya sesuai dengan sandi kunci simetris dengan ukuran tersebut:

Istilah tingkat keamanan dalam konteks ini mengacu pada kekuatan sistem kriptografi, khususnya tingkat kesulitan bagi penyerang untuk mengalahkan langkah-langkah keamanan. Ini umumnya diukur dalam bit dan mewakili jumlah pekerjaan (jumlah operasi) yang akan diperlukan untuk memecahkan enkripsi atau memalsukan tanda tangan. Dengan meningkatnya tingkat keamanan, keuntungan ukuran menjadi jelas hingga rasio ukuran kunci 1:30.

• Peningkatan Performa: Kunci yang lebih kecil memungkinkan operasi kriptografi yang lebih cepat, yang sangat penting untuk perangkat dengan daya pemrosesan yang lebih rendah. Ini menghasilkan aktivitas enkripsi dan dekripsi yang lebih cepat, meningkatkan performa dan responsivitas aplikasi seluler secara keseluruhan. Tergantung pada jenis tolok ukur, peningkatan kecepatan berkisar antara 10-40x dalam eksekusi. Berikut adalah contoh data tolok ukur yang dilakukan AWS saat mengimplementasikan ECDSA untuk Cloudfront pada tahun 2018:

• Peningkatan Efisiensi Baterai: Dengan pemrosesan yang lebih efisien dari kunci yang lebih kecil, operasi ECC dapat mengonsumsi lebih sedikit daya. Konservasi energi ini sangat penting untuk perangkat seluler, di mana menjaga masa pakai baterai adalah tantangan yang konstan.

Faktor-faktor ini membuat ECC sangat cocok untuk lingkungan seluler, di mana optimalisasi penyimpanan, kecepatan pemrosesan, dan konsumsi daya sangat penting. Akibatnya, ECC semakin disukai dalam komputasi seluler karena kemampuannya untuk memberikan keamanan yang kuat tanpa mengorbankan performa perangkat. Meskipun demikian, hingga saat ini banyak versi lama dari protokol yang tersebar luas seperti TLS (digunakan untuk HTTPS, FTPS, atau SMTPS), SSH, atau IPsec yang masih mendukung RSA tetapi telah mulai menawarkan varian berbasis ECC kepada klien yang mendukungnya.

Standar WebAuthn bukanlah standar enkripsi, melainkan protokol keamanan yang menyediakan autentikasi berbasis kunci publik yang kuat untuk aplikasi web, memungkinkan pengguna untuk masuk menggunakan biometrik, perangkat seluler, atau kunci keamanan perangkat keras (misalnya, YubiKeys) alih-alih kata sandi. Oleh karena itu, WebAuthn sengaja agnostik terhadap kriptografi berbasis kunci publik yang sebenarnya digunakan, mari kita lihat bagaimana ini dicapai.

Protokol keamanan WebAuthn memfasilitasi autentikasi aman secara kriptografis antara Pengguna dan Relying Party. Secara teknis, ini berarti bahwa Relying Party (situs web yang ingin menggunakan passkey dengan penggunanya) perlu bertukar kunci melalui browser dengan pengguna dan autentikatornya yang kemudian menyimpan kunci privat di modul keamanan perangkat keras (HSM) tertentu.

Untuk pendaftaran passkey, ada tiga langkah penting:

• (1) Relying Party memberi sinyal algoritma enkripsi yang didukung: Relying party memberi sinyal algoritma enkripsi yang didukung melalui PublicKeyCredentialCreationOptions.pubKeyCredParams bersama dengan PublicKeyCredentialCreationOptions lainnya.
• (2) Autentikator pengguna membuat pasangan kunci: Autentikator memeriksa daftar pubKeyCredParams untuk algoritma enkripsi yang didukungnya dan membuat pasangan kunci bersama dengan ID Kredensial yang unik. Ia menyimpan kunci privat di dalam HSM dan kemudian mengembalikan kunci publik dan algoritma enkripsi yang digunakan ke browser. Kemudian, browser mengirimkan permintaan POST ke backend Relying Party dengan attestationObject di bagian “authData”. Jika tidak ada kecocokan algoritma enkripsi yang didukung, proses pembuatan akan gagal.
• (3) Relying Party mengekstrak kunci publik dan menyimpannya: Relying party menerima attestationObject dari browser. Ia mem-parsing bagian authData.credentialPublicKey dan mengekstrak kunci publik. Bersama dengan kunci publik, informasi tentang algoritma enkripsi yang digunakan dan ID Kredensial juga dikirim kembali ke relying party.

Untuk login / autentikasi berikutnya dengan passkey, langkah-langkah berikut diperlukan (detail disederhanakan):

• (1) Relying Party menyajikan sebuah challenge: Relying party menghasilkan sebuah challenge acak dan memberikannya kepada autentikator untuk ditandatangani.
• (2) Autentikator pengguna menandatangani challenge: Autentikator menandatangani challenge dengan kunci yang cocok dengan permintaan autentikasi dan mengembalikannya dengan ID Kredensial ke Relying Party.
• (3) Relying Party memvalidasi tanda tangan: Relying Party menerima informasi dan mencari kunci publik yang terkait dengan ID Kredensial yang digunakan. Kemudian secara kriptografis memvalidasi tanda tangan menggunakan algoritma enkripsi/tanda tangan yang disepakati selama pendaftaran passkey.

Dengan melihat kedua kasus tersebut, kita dapat melihat bahwa hanya untuk pendaftaran passkey, informasi kunci publik dan algoritma enkripsi yang dipertukarkan antar aktor.

Untuk acara login / autentikasi berikutnya dengan passkey, hanya challenge dan tanda tangan yang menjadi bagian dari data yang dikirimkan.

Standar WebAuthn menggunakan ID Algoritma COSE IANA untuk mengidentifikasi algoritma enkripsi yang digunakan. ID Algoritma COSE digunakan baik untuk memberi sinyal algoritma yang didukung di pubKeyCredParams maupun untuk mengirimkan jenis pasangan kunci yang sebenarnya dibuat di credentialPublicKey. Kita akan fokus pada implementasinya di dua bagian berikutnya.

Daftar Algoritma COSE dari IANA mencakup lebih dari 75 algoritma yang secara teoritis dapat digunakan dengan Standar WebAuthn. Sebagian besar algoritma dengan ID negatif adalah kunci publik asimetris dan sebagian besar yang positif adalah simetris, tetapi ini lebih merupakan konvensi karena ada pengecualian.

Seperti yang telah kami tunjukkan sebelumnya, algoritma enkripsi harus didukung oleh Autentikator dan backend Relying Party agar dapat digunakan dalam seremoni WebAuthn. Karena sebagian besar relying party menggunakan pustaka WebAuthn yang ada yang memiliki akses ke berbagai macam algoritma enkripsi, lebih penting untuk melihat algoritma mana yang didukung oleh autentikator mana:

(*) = Sebagian kecil kunci keamanan (misalnya, Yubikeys 5+, Solokey atau Nitrokey) Kutipan dari Tabel IANA: Lihat daftar lengkap di sini

Seperti yang dapat Anda lihat dari tabel ini, untuk mendukung semua autentikator penting, RS256 dan ES256 sudah cukup. Ada beberapa bagian dari komunitas yang merekomendasikan untuk mengintegrasikan juga EdDSA untuk lebih meningkatkan keamanan. Di sisi lain, ID Kredensial yang juga perlu disimpan tampaknya secara signifikan lebih panjang untuk kunci EdDSA. Hingga hari ini, draf Editor W3C tentang Standar WebAuthn Level 3 yang akan datang menyarankan ketiga algoritma tersebut.

Mengonfigurasi algoritma enkripsi yang didukung untuk pembuatan passkey dilakukan melalui PublicKeyCredentialCreationOptions:

const publicKeyCredentialCreationOptions = {
    challenge: "*",
    rp: {
        name: "Corbado",
        id: "corbado.com",
    },
    user: {
        id: "user-X",
        name: "user@corbado.com",
        displayName: "Corbado Name",
    },
    pubKeyCredParams: [
        {
            alg: -8,
            type: "public-key",
        },
        {
            alg: -7,
            type: "public-key",
        },
        {
            alg: -257,
            type: "public-key",
        },
    ],
    authenticatorSelection: {
        authenticatorAttachment: "platform",
        requireResidentKey: true,
    },
};
 
const credential = await navigator.credentials.create({
    publicKey: publicKeyCredentialCreationOptions,
});

Contoh ini menunjukkan bagaimana algoritma ditentukan dalam: pubKeyCredParams oleh alg untuk ID dan menambahkan public-key sebagai tipe algoritma. Pada baris 29/30, PublicKeyCredentialCreationOptions diteruskan ke autentikator melalui API WebAuthn dari browser. Menghapus dukungan untuk ES256 atau RS256 akan menghasilkan kesalahan dan sangat tidak disarankan.

Sebagai contoh yang berfungsi, kita akan menjalankan PublicKeyCredentialCreationOptions berikut pada Mac di Passkeys Debugger.

{
    "rp": {
        "id": "www.passkeys-debugger.io",
        "name": "Relying Party Name"
    },
    "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
    "pubKeyCredParams": [
        {
            "type": "public-key",
            "alg": -8
        },
        {
            "type": "public-key",
            "alg": -7
        },
        {
            "type": "public-key",
            "alg": -257
        }
    ],
    "excludeCredentials": [],
    "timeout": 120000,
    "authenticatorSelection": {
        "residentKey": "required",
        "requireResidentKey": true,
        "userVerification": "required",
        "authenticatorAttachment": "platform"
    },
    "hints": [],
    "attestation": "direct",
    "user": {
        "name": "User-2024-08-19",
        "displayName": "User-2024-08-19",
        "id": "LlakhOS2vobxxwdkInYP-277Atf0S5OsJax_uBCNNINk"
    }
}

Respons yang dihasilkan oleh autentikator dikirim ke relying party (sebagai attestation) dan terlihat seperti:

{
    "id": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "rawId": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "type": "public-key",
    "response": {
        "attestationObject": "o2NmbXRmcGFja2VkZ2F0dFN0bXSiY2FsZyZjc2lnWEcwRQIhAIvVNCTlYXX7WKOfeto7WyBQE6uvXpvnNy22kqrMxs_QAiAmanFqalrvD_1fe0Cb2f60ljth4nngckkKJ8JPtqZiO2hhdXRoRGF0YVikt8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADdFAAAAAK3OAAI1vMYKZIsLJfHwVQMAIGljJhOARPWc70Snfa0IXcurm65Qdwjq00RUADXusnR4pQECAyYgASFYIDP4onRKVHXlhwbmWF4V6jmfsuVuSXchGm6xoceSBGtjIlgg3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c",
        "clientDataJSON": "eyJ0eXBlIjoid2ViYXV0aG4uY3JlYXRlIiwiY2hhbGxlbmdlIjoiQUFBQmVCNzhIckllbWgxalRkSklDcl8zUUdfUk1PaHAiLCJvcmlnaW4iOiJodHRwczovL29wb3Rvbm5pZWUuZ2l0aHViLmlvIiwiY3Jvc3NPcmlnaW4iOmZhbHNlfQ",
        "transports": ["internal"],
        "publicKeyAlgorithm": -7
    },
    "authenticatorAttachment": "platform",
    "clientExtensionResults": {}
}

Di sesi berikutnya, kita akan melihat bagaimana kunci publik dan algoritma enkripsi yang digunakan dapat diekstrak dari respons.

Pertama-tama, kita perlu memeriksa bagaimana attestationObject sebenarnya dibangun, karena seperti yang kita lihat di atas, itu tidak dikirim dalam format JSON ke Relying Party.

attestationObject memainkan peran penting dalam proses pendaftaran WebAuthn, berfungsi sebagai wadah untuk pernyataan atestasi yang disediakan oleh autentikator. Objek ini menyediakan banyak informasi yang diperlukan bagi Relying Party (RP) untuk memverifikasi asal dan integritas kredensial kunci publik yang baru dibuat.

Pada intinya, attestationObject adalah struktur yang kompleks. Sebagian besar dikodekan dalam format CBOR (Concise Binary Object Representation), yang kemudian pada akhirnya dikodekan dengan pengodean Base64URL. Ini merangkum data autentikator bersama dengan pernyataan atestasi yang memverifikasi keaslian informasi. Karena passkey dibuat dengan atestasi “none” dan oleh karena itu tidak membawa pernyataan atestasi, kami tidak akan membahas ini dalam artikel ini. Sebagai catatan samping: Kami menulis sebagian besar CBOR karena ada juga awalan CBOR non-standar yang terlibat karena panjang variabel yang diperlukan untuk ekstensi opsional. Kami tidak akan membahas lebih dalam tentang itu, diskusi tentang kompleksitasnya dapat ditemukan di sini.

Diambil dari spesifikasi WebAuthn

Di dalam data autentikator (authData), kunci publik yang baru dibuat, bersama dengan ID kredensial pengguna, disimpan dengan aman dan dapat diambil oleh relying party. Karena pengembang harus mendekati tugas mengekstrak kunci publik dari attestationObject dalam sistem berbasis WebAuthn apa pun, memahami arsitekturnya adalah penting.

CBOR (Concise Binary Object Representation) adalah format data yang dirancang untuk mengkodekan data dengan cara yang ringkas, efisien, dan dapat diperluas. Ini adalah biner, yang membuatnya lebih kecil dan lebih cepat untuk di-parse daripada modelnya yang berbasis teks, JSON. Contoh berikut mengilustrasikan bagaimana JSON dan CBOR berbeda (Teks vs. Biner):

Tebal adalah Nama. Miring adalah Corbado. (informasi lebih lanjut dapat ditemukan di https://cbor.io/)

Dalam konteks WebAuthn, CBOR digunakan karena beberapa alasan:

• Tautan ke FIDO2 / CTAP: Karena CBOR digunakan dalam standar yang mendasarinya, penguraian dan pemrosesan data yang disederhanakan tercapai, karena baik WebAuthn maupun CTAP menggunakan skema pengkodean ringkas yang sama.
• Keringkasan: Pengkodean efisien CBOR menjadikannya pilihan yang sangat baik untuk lalu lintas web di mana meminimalkan ukuran data dapat secara signifikan memengaruhi kinerja, terutama melalui jaringan seluler atau di lingkungan di mana bandwidth menjadi kendala.
• Fleksibilitas: CBOR mendukung berbagai tipe dan struktur data, termasuk array, map, string teks, string byte, dan tag untuk ekstensibilitas. Ini membuatnya cukup serbaguna untuk menangani berbagai tipe data dan struktur kompleks yang diperlukan untuk operasi WebAuthn.
• Ekstensibilitas: Format ini dirancang agar dapat diperluas, yang berarti fitur baru dapat ditambahkan ke WebAuthn tanpa merusak kompatibilitas dengan implementasi yang ada.

Penggunaan CBOR sangat cocok untuk mengkodekan kunci publik dan attestationObject karena perlu menangani berbagai format dan panjang yang telah kita bahas di atas. Misalnya, kunci RSA akan memiliki atribut dan ukuran yang berbeda dibandingkan dengan kunci ECDSA. Di dalam attestationObject, kunci publik disimpan dalam format Kunci COSE, yang didasarkan pada CBOR.

Struktur Kunci COSE dibangun di atas objek map CBOR. Ini mendefinisikan cara terstruktur untuk representasi kunci, mencakup berbagai jenis kunci dan parameter yang sesuai, seperti modulus dan eksponen RSA, atau koordinat kunci publik kurva eliptik. Format standar ini memungkinkan kunci untuk diserialisasi dan dideserialisasi secara konsisten, terlepas dari algoritma kriptografi yang mendasarinya, selain ID algoritma enkripsi yang telah kita bahas di atas.

Dengan memanfaatkan CBOR dan format Kunci COSE, WebAuthn dapat memfasilitasi berbagai operasi kriptografi sambil memastikan payload tetap sekecil mungkin, dan tetap dapat beradaptasi untuk pembaruan di masa depan dalam teknologi kriptografi. Pilihan ini sejalan dengan tujuan WebAuthn untuk menyediakan protokol yang aman, efisien, dan kompatibel di masa depan untuk autentikasi web.

Ketika mendekode attestationObject dalam WebAuthn, pengembang dihadapkan pada keputusan penting: mengembangkan solusi kustom atau memanfaatkan pustaka yang sudah mapan. Kompleksitas dan sifat kritis dari proses ini tidak dapat dilebih-lebihkan. Implementasi manual dari dekode Base64URL dan CBOR, meskipun secara teknis memungkinkan, memperkenalkan risiko kesalahan halus yang dapat membahayakan integritas proses autentikasi.

Untuk memastikan verifikasi kriptografis dari tanda tangan, serta keakuratan semua langkah validasi lainnya, sangat disarankan untuk menggunakan pustaka WebAuthn yang telah teruji dengan baik dan diadopsi secara luas. Pustaka semacam itu dibangun dengan keahlian enkripsi untuk menangani detail dekode dan validasi attestationObject, termasuk:

• Mem-parsing format CBOR dengan benar untuk mengekstrak pernyataan atestasi dan data autentikator.
• Menafsirkan format Kunci COSE untuk mengambil kunci publik.
• Melakukan pemeriksaan kriptografis untuk memvalidasi tanda tangan sesuai dengan standar WebAuthn.

Dengan mengandalkan pustaka yang memiliki reputasi baik, pengembang tidak hanya menghemat waktu dan sumber daya tetapi juga mendapatkan ketenangan pikiran. Kunci publik, setelah diekstraksi dan diverifikasi melalui alat yang andal ini, kemudian dapat disimpan dengan aman di database, siap digunakan untuk sesi autentikasi yang aman. Pendekatan ini memastikan kepatuhan terhadap spesifikasi protokol dan menjaga postur keamanan yang diharapkan dalam implementasi WebAuthn. Untuk kesederhanaan, kita akan menggunakan SimpleWebauthn Debugger yang mengembalikan versi yang sepenuhnya didekode dengan bidang CBOR diubah menjadi JSON yang diperluas:

{
    "id": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "rawId": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
    "type": "public-key",
    "response": {
        "attestationObject": {
            "fmt": "packed",
            "attStmt": {
                "alg": "ES256 (-7)",
                "sig": "MEUCIQCL1TQk5WF1-1ijn3raO1sgUBOrr16b5zcttpKqzMbP0AIgJmpxampa7w_9X3tAm9n-tJY7YeJ54HJJCifCT7amYjs"
            },
            "authData": {
                "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
                "flags": {
                    "userPresent": true,
                    "userVerified": true,
                    "backupEligible": false,
                    "backupStatus": false,
                    "attestedData": true,
                    "extensionData": false
                },
                "counter": 0,
                "aaguid": "adce0002-35bc-c60a-648b-0b25f1f05503",
                "credentialID": "aWMmE4BE9ZzvRKd9rQhdy6ubrlB3COrTRFQANe6ydHg",
                "credentialPublicKey": "pQECAyYgASFYIDP4onRKVHXlhwbmWF4V6jmfsuVuSXchGm6xoceSBGtjIlgg3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c",
                "parsedCredentialPublicKey": {
                    "keyType": "EC2 (2)",
                    "algorithm": "ES256 (-7)",
                    "curve": 1,
                    "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M",
                    "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c"
                }
            }
        },
        "clientDataJSON": {
            "type": "webauthn.create",
            "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
            "origin": "https://opotonniee.github.io",
            "crossOrigin": false
        },
        "transports": ["internal"],
        "publicKeyAlgorithm": -7
    },
    "authenticatorAttachment": "platform",
    "clientExtensionResults": {}
}

Pustaka SimpleWebAuthn digunakan untuk mendekode attestationObject secara lengkap. Seperti yang bisa kita lihat, semua informasi sekarang dapat dibaca. Semua informasi kriptografis adalah bagian dari credentialPublicKey yang merupakan bagian dari authData. Pustaka tersebut telah menguraikannya menjadi pernyataan parsedCredentialPublicKey. Dalam spesifikasi, ada beberapa contoh bagaimana Format Kunci COSE terlihat.

{
    "parsedCredentialPublicKey": {
        "keyType": "EC2 (2)",
        "algorithm": "ES256 (-7)",
        "curve": 1,
        "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M",
        "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c"
    }
}

Output ini menampilkan semua elemen kriptografis dari credentialPublicKey yang di-parse dengan rapi ke dalam bentuk yang dapat dibaca manusia. Contoh khusus ini mengungkapkan kunci EC2 untuk algoritma ES256, seperti yang ditunjukkan oleh parameter algoritma dan adanya koordinat x dan y.

Sebaliknya, output dari sistem Windows 10 terlihat sebagai berikut:

{
    "parsedCredentialPublicKey": {
        "keyType": "RSA (3)",
        "algorithm": "RS256 (-257)",
        "modulus": "mzRVwAL6jbccWT4NQ3rQWEYLkTKkEBeHPPUn0CXT8VwvvGE_IaXDeP9ZzcA7WoX3z6E0l_L-XZmRuKc9cO7BkiYyz3jOg_pNFTz5Ap9a1f_9H0m4mpL-30WHQZi1skB5f6zt8sO8q7rBYH0mRmH8LdCrhJRhVjB_UxbcAbYlpV98M5g-5OBs_boNXtMhMoyp-IOeGChp07wwSLVOH3hKMoxlU27hZ3QvK2LRWosNKhXSHcU9IOC0XOyhlZ5rtPX2ae3KsSE1H2rEJVcMaVMRAg8yx2SRM98pDvf829smrnJPdMBojKftne2j8o84i_xyDJ_jARlyVj0kxR37u0AVQQ",
        "exponent": 65537
    }
}

Di sini, ID algoritma adalah -257, sesuai dengan RS256, dan kita dapat melihat bahwa atribut yang mencirikan kunci publik ini berbeda secara signifikan dari kunci ECDSA. Format Kunci COSE memungkinkan untuk menentukan atribut unik per jenis:

Juga, modulus RSA secara substansial lebih panjang daripada koordinat kurva eliptik yang digunakan dalam kunci ES256, menggarisbawahi diskusi kita sebelumnya mengenai perbedaan ukuran kunci dan persyaratan inheren dari algoritma kriptografi yang berbeda.

Setelah membahas dasar-dasar kriptografi kunci publik dan memahami bagaimana hal itu dimasukkan ke dalam standar WebAuthn / FIDO2, kami memiliki dua rekomendasi utama untuk relying party:

• Pilih algoritma enkripsi yang tepat: Dalam implementasi WebAuthn, penting untuk menggunakan algoritma yang benar untuk kompatibilitas maksimum. Berdasarkan rekomendasi saat ini, kombinasi RS256, ES256, dan EdDSA disarankan. RS256 dan ES256 menonjol karena dukungan luasnya, dan penyertaan EdDSA dapat meningkatkan keamanan jika memungkinkan.
• Gunakan pustaka WebAuthn yang teruji untuk mengekstrak kunci publik: Setelah Anda memutuskan algoritma, langkah selanjutnya adalah mengintegrasikan pustaka WebAuthn yang teruji. Pustaka semacam itu dapat dengan kompeten menangani kompleksitas parsing * attestationObject*. Setelah pustaka mengekstrak kunci publik dan data terkaitnya, kunci tersebut dapat disimpan dengan aman di database. Format yang digunakan oleh pustaka biasanya memastikan bahwa kunci disimpan dengan cara yang dapat dibaca dan digunakan secara akurat untuk tujuan autentikasi di masa mendatang.

Sangat penting untuk tidak menciptakan kembali roda: manfaatkan pengetahuan kolektif yang tertanam dalam pustaka yang sudah mapan. Implementasi kustom berisiko menimbulkan kesalahan dan kelemahan keamanan yang dapat merusak efektivitas autentikasi dan keamanan sistem secara keseluruhan.

Dalam postingan blog ini, kami telah menyelidiki dasar-dasar kriptografi kunci publik untuk menjawab tiga pertanyaan inti awal:

1. Algoritma Enkripsi yang Didukung di WebAuthn: WebAuthn dirancang agar fleksibel dan mendukung berbagai algoritma enkripsi, terutama termasuk RSA (RS256), ECDSA (ES256), dan EdDSA. Kemampuan beradaptasi ini memungkinkannya untuk berintegrasi secara mulus dengan berbagai autentikator dan platform, memastikan kompatibilitas yang luas.
2. Fungsionalitas pubKeyCredParams dalam Pembuatan Pasangan Kunci: pubKeyCredParams memainkan peran penting dalam fase pendaftaran proses WebAuthn dengan menentukan algoritma kriptografi mana yang didukung oleh relying party. Ini memastikan bahwa pasangan kunci yang dibuat kompatibel dengan autentikator pengguna dan persyaratan relying party.
3. Fungsionalitas credentialPublicKey dan Mengekstrak Kunci Publik: credentialPublicKey digunakan untuk mengekstrak kunci publik dari attestationObject yang disediakan oleh autentikator.

Selain itu, kami telah menyoroti kemandirian protokol WebAuthn dari algoritma enkripsi tertentu, yang secara signifikan meningkatkan fleksibilitas dan kemampuannya untuk menghadapi metode kriptografi yang muncul di masa depan. Kami berharap artikel ini juga membantu pengembang lain saat melakukan debug dan memahami konsep / masalah yang terkait dengan kriptografi kunci publik di WebAuthn.