--- url: 'https://www.corbado.com/tr/blog/webauthn-pubkeycredparams-credentialpublickey-cbor-cose' title: 'WebAuthn pubKeyCredParams ve credentialPublicKey: CBOR ve COSE' description: 'WebAuthn''in passkey kimlik doğrulamasında asimetrik şifreleme algoritmalarını ve pubKeyCredParams''ı nasıl kullandığını, ayrıca credentialPublicKey, CBOR ve COSE''nin rolünü keşfedin.' lang: 'tr' author: 'Vincent Delitz' date: '2025-08-08T11:42:53.947Z' lastModified: '2026-08-29T06:06:31.599Z' keywords: 'pubKeyCredParams, credentialPublicKey, COSE, WebAuthn, CBOR' category: 'WebAuthn Know-How' --- # WebAuthn pubKeyCredParams ve credentialPublicKey: CBOR ve COSE ## 1. Giriş: pubKeyCredParams ve credentialPublicKey Dijital güvenlikte, [passkey'ler](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir) yeni şifresiz standarttır. Passkey'lerin kalbinde, temel aldıkları WebAuthn protokolü içinde kullanılan açık anahtarlı kriptografi yatar. **WebAuthn'de açık anahtarlı kriptografinin nasıl kullanıldığını**, özellikle passkey'lerin oluşturulması, çıkarılması, yönetilmesi ve saklanması süreçlerini anlamak, passkey kimlik doğrulaması tasarlarken veya kullanırken çok önemlidir. Açık anahtar, bir kullanıcıyı [passkey'ler](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir) aracılığıyla doğrulamak isteyen web sitesinin arka ucu olan [Relying Party](https://www.corbado.com/glossary/relying-party) (RP) sunucusunda saklanır. Özel anahtar ise işletim sistemine bağlı olarak bir Donanım [Güvenlik](https://www.corbado.com/tr/faq/kripto-gecis-anahtarlari) Modülü'nde güvenli bir şekilde tutulur: [Secure Enclave](https://www.corbado.com/glossary/secure-enclave) ([iOS](https://www.corbado.com/blog/how-to-enable-passkeys-ios)), TEE ([Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)) veya TPM (Windows). Bu blog yazısında, passkey'lerde kullanılan açık anahtarlı kriptografinin temellerini hızlıca gözden geçireceğiz. Yazının sonunda aşağıdaki soruların cevaplanmış olması hedeflenmektedir: - **WebAuthn'de hangi şifreleme algoritmaları destekleniyor?** - **Bir anahtar çifti oluştururken pubKeyCredParams nasıl çalışır?** - **Oluşturulan açık anahtarları çıkarırken credentialPublicKey nasıl çalışır?** ## 2. Açık Anahtarlı Kriptografi Nedir? WebAuthn içinde açık anahtarlı kriptografinin nasıl çalıştığını anlamak için, genel olarak nasıl işlediğine ve yaygın algoritma türlerinin neler olduğuna hızlıca bir göz atacağız. ### 2.1 Açık Anahtarlı Kriptografi Nasıl Çalışır? Asimetrik kriptografi olarak da bilinen açık anahtarlı kriptografi, hem şifreleme hem de de[şifreleme](https://www.corbado.com/tr/blog/guvenli-belge-yonetimi) için aynı anahtarın kullanıldığı simetrik kriptografinin tam tersidir. Asimetrik kriptografi iki farklı anahtar kullanır: biri herkese açık olarak paylaşılabilen bir açık anahtar, diğeri ise sahibi tarafından gizli tutulan bir özel anahtar. ![Açık ve Özel Anahtarlar](https://www.corbado.com/website-assets/public_private_keys_f58d96019d.png)_Kaynak: [https://en.wikipedia.org/wiki/Public-key_cryptography](https://en.wikipedia.org/wiki/Public-key_cryptography)_ Bu yöntem, verilerin gizliliğini sağlamak için şifrelenmesine olanak tanımakla kalmaz, aynı zamanda mesajların imzalanmasını da sağlar. İmzalama, gönderenin kimliğini doğrular ve mesajın değiştirilmediğini garanti ederek mesajın orijinalliğini ve bütünlüğünü teyit eder. ### 2.2 Yaygın Açık Anahtarlı Kriptografi Algoritma Türleri İşte açık anahtarlı kriptografide kullanılan bazı yaygın algoritma türlerine genel bir bakış: | **Kategori** | **RSA** | **DSA** | **ECDSA** | **EdDSA** | | ------------------------------------------- | ----------------------------------------- | -------------------------------------- | --------------------------------------------------------- | ------------------------------------------------------ | | **Buluş Tarihi** | 1977 | 1991 | 1999 | 2011 | | **Algoritma Türü** | Asimetrik açık anahtarlı kriptografi | Dijital imza algoritması | Eliptik eğri dijital imza | Edwards eğrisi dijital imza | | **Ana Kullanım Alanı** | Güvenli veri iletimi | Elektronik belgeleri imzalama | Güvenli işlemler ve imzalar | Güvenli işlemler ve imzalar | | **Yaygın Anahtar Boyutları** | 1024 ila 15360 bit | 1024 ila 3072 bit | 160 ila 512 bit | 256 bit | | **Performans** | Büyük anahtar boyutu nedeniyle daha yavaş | İmzalama için RSA'dan daha hızlı | Küçük anahtarlarla daha hızlı hesaplamalar | Hız ve güvenlik için optimize edilmiş | | **Popülerlik** | Tarihsel olarak yaygın kullanılıyor | RSA'dan daha az yaygın | Giderek daha popüler hale geliyor | Hızla popülerlik kazanıyor | | **Mobil cihazlar için verimlilik** | Mobilde daha az verimli | Orta derecede verimli | Mobil cihazlarda yüksek verimlilik | Maksimum verimlilik | | **Anahtarlar için Depolama Gereksinimleri** | Büyük anahtar boyutları nedeniyle yüksek | Orta | Düşük depolama alanı gerekli | Minimum depolama ihtiyacı | | **Pil Kullanımı** | Daha yüksek tüketim | Orta düzeyde tüketim | Daha düşük güç tüketimi | Pil ömrünü korumak için ideal | | **Mobil Uygunluk** | Boyut ve güç nedeniyle daha az uygun | Orta derecede uygun | Son derece uygun | Son derece uygun | | **Standartlarda Benimsenme** | Yaygın olarak benimsenmiş (TLS, SSH) | Daha az yaygın olarak benimsenmiş | Modern protokollerde yaygın olarak benimsenmiş (TLS, SSH) | Yeni protokollerde benimseniyor (TLS, SSH) | | **Gelecekteki Tehditlere Karşı Direnç** | Kuantum saldırılarına karşı savunmasız | Kuantum saldırılarına karşı savunmasız | Kuantum saldırılarına karşı potansiyel olarak dirençli | Kuantum saldırılarına karşı potansiyel olarak dirençli | | **Çok Yönlülük** | Platformlar arası yüksek çok yönlülük | Belirli kullanım durumlarıyla sınırlı | Yüksek çok yönlülük | Yüksek çok yönlülük | | **Patent Durumu** | Patentli değil | Patentli değil | Patentli değil | Patentli değil | ECDSA ve EdDSA dahil olmak üzere eliptik eğri kriptografisinin (ECC) matematiksel temeli, bu makalede ele almayacağımız eliptik eğrilerin özelliklerini içerir. Ancak yukarıdaki tablodan, bu algoritmaların benimsenmesini sağlayan avantajlar olduğu açıktır. Bir sonraki bölümde en önemlilerini ele alacağız. ### 2.3 ECC Tabanlı Açık Kriptografinin Artan Benimsenmesi Eliptik eğri kriptografisi, daha küçük anahtar boyutlarından faydalandıkları için mobil cihazlarda yaygın olarak benimsenmiştir. Bu da aşağıdaki avantajları beraberinde getirir: - **Azaltılmış Depolama Gereksinimleri:** ECC'nin daha küçük anahtarları, RSA gibi geleneksel kriptografik yöntemlere kıyasla daha az depolama alanı gerektirir. Bu, özellikle sınırlı bellek kaynaklarına sahip cihazlar için faydalıdır ve alanın daha verimli kullanılmasını sağlar. Aşağıdaki tablo, karşılaştırılabilir [güvenlik](https://www.corbado.com/tr/faq/kripto-gecis-anahtarlari) seviyelerini ve kullanılan anahtarların gerçek boyutlarının bir yaklaşık değerini göstermektedir. [Güvenlik](https://www.corbado.com/tr/faq/kripto-gecis-anahtarlari) seviyesi bit cinsinden ölçülür ve genellikle o boyuttaki bir simetrik anahtar şifresine karşılık gelir: | **Güvenlik Seviyesi (bit)** | **RSA Anahtar Boyutu (bit)** | **ECDSA/EdDSA Anahtar Boyutu (bit)** | | --------------------------- | ---------------------------- | ------------------------------------ | | 80 | 1024 | 160-223 | | 112 | 2048 | 224-255 | | 128 | 3072 | 256-383 | | 256 | 15360 | 512+ | Bu bağlamda **güvenlik seviyesi terimi, kriptografik sistemin gücünü**, yani bir saldırganın güvenlik önlemlerini aşmasının zorluk seviyesini ifade eder. Genellikle bit cinsinden ölçülür ve şifreyi kırmak veya bir imzayı taklit etmek için gereken iş miktarını (operasyon sayısını) temsil eder. Güvenlik seviyesi arttıkça, anahtar oranı boyutlarında 1:30'a varan avantajlar belirgin hale gelir. - **Gelişmiş Performans:** Daha küçük anahtarlar daha hızlı kriptografik işlemlere olanak tanır, bu da daha düşük işlem gücüne sahip cihazlar için çok önemlidir. Bu, daha hızlı şifreleme ve de[şifreleme](https://www.corbado.com/tr/blog/guvenli-belge-yonetimi) faaliyetleri ile sonuçlanır, mobil uygulamaların genel performansını ve yanıt verme hızını artırır. Benchmark türüne bağlı olarak [hızlanmalar 10-40 kat arasında değişir](https://aws.amazon.com/de/blogs/networking-and-content-delivery/cloudfront-now-supports-ecdsa-certificates-for-https-connections-to-origins/). İşte [AWS](https://www.corbado.com/blog/passkeys-amazon-cognito)'nin 2018'de Cloudfront için ECDSA'yı uygularken yürüttüğü benchmark verilerinden bir örnek: | **Algoritma** | **Anahtar Boyutu** | **İmza İşlemi** | **İmza/s** | | ------------- | ------------------ | --------------- | ----------- | | RSA | 2048 | 0.001012s | 987 | | ECDSA | 256 | 0.000046s | 21565 (x20) | - **İyileştirilmiş Pil Verimliliği:** Daha küçük anahtarlarla daha verimli işlem yapılması sayesinde, ECC işlemleri daha az güç tüketebilir. Bu enerji tasarrufu, pil ömrünü korumanın sürekli bir zorluk olduğu mobil cihazlar için hayati önem taşır. Bu faktörler, ECC'yi özellikle depolama, işlem hızı ve güç tüketiminin optimizasyonunun gerekli olduğu mobil ortamlar için uygun hale getirir. Sonuç olarak, ECC, cihaz performansından ödün vermeden sağlam güvenlik sağlama yeteneği nedeniyle mobil bilişimde giderek daha fazla tercih edilmektedir. Yine de, günümüze kadar HTTPS, FTPS veya SMTPS için kullanılan TLS, SSH veya IPsec gibi yaygın protokollerin birçok eski sürümü hala RSA'yı desteklemekte, ancak onları destekleyen istemcilere ECC tabanlı varyantlar sunmaya başlamıştır. ## 3. WebAuthn: Passkey'lerde Açık Anahtarlı Kriptografi Nasıl Kullanılır? WebAuthn standardı bir şifreleme standardı değil, web uygulamaları için güçlü, açık anahtar tabanlı [kimlik doğrulama](https://www.corbado.com/tr/blog/revolut-passkeys-analizi) sağlayan bir güvenlik protokolüdür. Kullanıcıların şifreler yerine [biyometri](https://www.corbado.com/tr/blog/dinamik-eslestirmede-biyometri-odeme-yapani-farkindaligi), mobil cihazlar veya donanım güvenlik anahtarları (örneğin [YubiKey](https://www.corbado.com/glossary/yubikey)'ler) kullanarak oturum açmalarını sağlar. Bu nedenle, WebAuthn hangi açık anahtar tabanlı kriptografinin kullanıldığı konusunda kasıtlı olarak agnostiktir. Şimdi bunun nasıl başarıldığına bir göz atalım. WebAuthn güvenlik protokolü, **Kullanıcı** ile **Relying Party** arasındaki kriptografik olarak güvenli kimlik doğrulamasını kolaylaştırır. Teknik terimlerle bu, [Relying Party](https://www.corbado.com/glossary/relying-party)'nin (kullanıcılarıyla passkey kullanmak isteyen bir web sitesi) tarayıcı üzerinden kullanıcı ve onun [Authenticator](https://www.corbado.com/glossary/authenticator)'ı ile anahtar alışverişi yapması gerektiği anlamına gelir. [Authenticator](https://www.corbado.com/glossary/authenticator) daha sonra özel anahtarı belirli donanım güvenlik modülünde (HSM) saklar. **Passkey kaydı / oluşturma için üç önemli adım vardır:** ![Passkey Kayıt Süreci](https://www.corbado.com/website-assets/passkey_registration_process_f27bc263ad.png) - **(1) Relying Party desteklenen şifreleme algoritmalarını bildirir:** [Relying Party](https://www.corbado.com/glossary/relying-party), desteklenen şifreleme algoritmalarını `PublicKeyCredentialCreationOptions.pubKeyCredParams` aracılığıyla diğer `PublicKeyCredentialCreationOptions` ile birlikte bildirir. - **(2) Kullanıcının Authenticator'ı anahtar çiftini oluşturur:** [Authenticator](https://www.corbado.com/glossary/authenticator), desteklediği şifreleme algoritmaları için `pubKeyCredParams` listesini kontrol eder ve benzersiz bir [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle) ile birlikte bir anahtar çifti oluşturur. Özel anahtarı HSM içinde saklar ve ardından açık anahtarı ve kullanılan şifreleme algoritmasını tarayıcıya döndürür. Daha sonra tarayıcı, "authData" bölümündeki attestationObject ile Relying Party arka ucuna bir POST isteği gönderir. **Desteklenen şifreleme algoritmaları arasında bir eşleşme olmaması durumunda, oluşturma işlemi başarısız olur.** - **(3) Relying Party açık anahtarı çıkarır ve saklar:** Relying Party, tarayıcıdan `attestationObject`'i alır. `authData.credentialPublicKey` bölümünü ayrıştırır ve açık anahtarı çıkarır. Açık anahtarla birlikte, kullanılan şifreleme algoritması ve [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle) hakkındaki bilgiler de Relying Party'ye geri gönderilir. **Sonraki passkey ile giriş / kimlik doğrulama için aşağıdaki adımlar gereklidir (detaylar basitleştirilmiştir):** ![Passkey Kimlik Doğrulama Süreci](https://www.corbado.com/website-assets/passkey_authentication_process_5d7c0b9320.png) - **(1) Relying Party bir challenge sunar:** Relying Party rastgele bir challenge oluşturur ve imza için Authenticator'a sunar. - **(2) Kullanıcının Authenticator'ı challenge'ı imzalar:** Authenticator, kimlik doğrulama isteğiyle eşleşen anahtarla challenge'ı imzalar ve [Credential ID](https://www.corbado.com/blog/webauthn-user-id-userhandle) ile birlikte Relying Party'ye döndürür. - **(3) Relying Party imzayı doğrular:** Relying Party bilgiyi alır ve kullanılan Credential ID ile ilişkili açık anahtarı arar. Ardından, passkey'lerin kaydı sırasında üzerinde anlaşılan şifreleme/imza algoritmasını kullanarak imzayı kriptografik olarak doğrular. Her iki duruma da baktığımızda, **sadece passkey kaydı / oluşturma için açık anahtar ve şifreleme algoritması bilgilerinin aktörler arasında taşındığını** görebiliriz. Sonraki passkey ile giriş / [kimlik doğrulama](https://www.corbado.com/tr/blog/revolut-passkeys-analizi) olayları için, iletilen verinin bir parçası yalnızca challenge ve imzadır. WebAuthn standardı, kullanılan şifreleme algoritmalarını tanımlamak için [IANA COSE Algoritma ID'lerini](https://www.iana.org/assignments/cose/cose.xhtml) kullanır. **COSE Algoritma ID'leri hem pubKeyCredParams'ta desteklenen algoritmaları bildirmek hem de credentialPublicKey'de fiilen oluşturulan anahtar çifti türünü iletmek için kullanılır.** Sonraki iki bölümde bunların uygulanmasına odaklanacağız. ## 4. Doğru pubKeyCredParams Ayarları Nasıl Seçilir? IANA'nın [COSE](https://www.corbado.com/blog/webauthn-pubkeycredparams-credentialpublickey) Algoritmaları listesi, teorik olarak WebAuthn Standardı ile kullanılabilecek 75'ten fazla algoritma içerir. Negatif ID'li algoritmaların çoğu asimetrik açık anahtarlı, pozitif olanların çoğu ise simetriktir, ancak bu daha çok bir gelenektir çünkü istisnalar vardır. ### 4.1 WebAuthn için Hangi COSE Algoritmaları İlgilidir? Daha önce de belirttiğimiz gibi, **şifreleme algoritmasının WebAuthn seremonisinde kullanılabilmesi için Authenticator ve Relying Party** arka ucu tarafından desteklenmesi gerekir. Çoğu Relying Party, geniş bir şifreleme algoritması yelpazesine erişimi olan mevcut WebAuthn kütüphanelerini kullandığından, hangi algoritmaların hangi Authenticator'lar tarafından desteklendiğine bakmak daha önemlidir: | **Ad** | **ID** | **Açıklama** | **Apple** | **Android** | **Windows 10** | **Windows 11+** | **Güvenlik anahtarları** | | ------ | ------ | ------------------------------------------------ | --------- | ----------- | -------------- | --------------- | ------------------------ | | RS256 | -257 | SHA-256 kullanan RSASSA-PKCS1-v1_5 | ❌ | ❌ | ✅ | ✅ | ✅ | | EdDSA | -8 | EdDSA | ❌ | ❌ | ❌ | ❌ | ✅ (\*) | | ES256 | -7 | SHA-256 ile ECDSA (NIST P-256 olarak da bilinir) | ✅ | ✅ | ❌ | ✅ | ✅ | (\*) = Güvenlik anahtarlarının küçük bir kısmı (ör. [Yubikey](https://www.corbado.com/glossary/yubikey)'ler 5+, Solokey veya Nitrokey) IANA Tablosundan alıntı: Tam listeyi [burada](https://www.iana.org/assignments/cose/cose.xhtml) görebilirsiniz Bu tablodan da görebileceğiniz gibi, tüm önemli Authenticator'ları desteklemek için RS256 ve ES256 yeterlidir. Topluluğun bazı kesimleri, güvenliği daha da artırmak için EdDSA'nın da entegre edilmesini önermektedir. Diğer yandan, saklanması gereken Credential ID'lerin [EdDSA anahtarları için önemli ölçüde daha uzun olduğu](https://github.com/kanidm/webauthn-rs/discussions/406#discussioncomment-8089897) görülmektedir. Bugün itibarıyla, W3C'nin yakında çıkacak olan [Seviye 3 WebAuthn Standardı üzerindeki Editör Taslağı her üç algoritmayı da önermektedir](https://w3c.github.io/webauthn/#dom-publickeycredentialcreationoptions-pubkeycredparams). ### 4.2 pubKeyCredParams'ta pubKeyCredParams-Dizisini Tanımlama Passkey oluşturma için desteklenen şifreleme algoritmalarını yapılandırmak `PublicKeyCredentialCreationOptions` aracılığıyla yapılır: ```javascript 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, }); ``` Örnek, algoritmaların [pubKeyCredParams](https://www.corbado.com/blog/webauthn-pubkeycredparams-credentialpublickey) içinde ID için `alg` ve algoritma türü olarak `public-key` eklenerek nasıl belirtildiğini gösterir. 29/30. satırlarda, [PublicKeyCredentialCreationOptions](https://www.corbado.com/glossary/publickeycredentialcreationoptions) tarayıcının WebAuthn API'si aracılığıyla Authenticator'a iletilir. ES256 veya RS256 desteğini kaldırmak hatalara yol açacaktır ve kesinlikle önerilmez. ![Windows Passkey'lerinde Bir Şeyler Ters Gitti](https://www.corbado.com/website-assets/windows_passkeys_something_went_wrong_7ddb1bad11.png) Çalışan bir örnek olarak, aşağıdaki `PublicKeyCredentialCreationOptions`'ı bir [Mac](https://www.corbado.com/tr/blog/parallels-passkeys-cda)'te [Passkeys Debugger](https://www.passkeys-debugger.io/) üzerinde çalıştıracağız. ```json { "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" } } ``` Authenticator tarafından üretilen yanıt, Relying Party'ye (attestation olarak) gönderilir ve şöyle görünür: ```json { "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": {} } ``` Bir sonraki bölümde, açık anahtarların ve kullanılan şifreleme algoritmasının yanıttan nasıl çıkarılabileceğini göreceğiz. ## 5. attestationObject'ten Açık Anahtar Nasıl Çıkarılır? Öncelikle, `attestationObject`'in nasıl oluşturulduğunu incelememiz gerekiyor, çünkü yukarıda gördüğümüz gibi Relying Party'ye JSON formatında iletilmiyor. ### 5.1 Genel Bakış: attestationObject Nedir? **attestationObject**, WebAuthn kayıt sürecinde önemli bir rol oynar ve Authenticator tarafından sağlanan [attestation](https://www.corbado.com/glossary/attestation) statement için bir taşıyıcı görevi görür. Bu nesne, Relying Party'nin (RP) yeni oluşturulan açık anahtar kimlik bilgisinin kökenini ve bütünlüğünü doğrulaması için gerekli birçok bilgiyi sağlar. Özünde, **attestationObject** karmaşık bir yapıdır. Çoğunlukla [CBOR](https://www.corbado.com/glossary/cbor) (Concise Binary Object Representation) formatında kodlanmıştır ve bu da en sonunda Base64URL kodlaması ile kodlanır. Authenticator verilerini ve bilgilerin orijinalliğini doğrulayan bir [attestation](https://www.corbado.com/glossary/attestation) ifadesini kapsar. [Passkey'ler](https://www.corbado.com/tr/blog/tamamen-sifresiz-sisteme-nasil-gecilir) [attestation](https://www.corbado.com/glossary/attestation) "none" ile oluşturulduğundan ve dolayısıyla bir attestation ifadesi taşımadığından, bu konuyu bu makalede ele almayacağız. Bir yan not olarak: Çoğunlukla [CBOR](https://www.corbado.com/glossary/cbor) yazdık çünkü isteğe bağlı uzantılar için gereken değişken uzunluklar nedeniyle standart olmayan [CBOR](https://www.corbado.com/glossary/cbor) önekleri de söz konusudur. Bu konuya daha derinlemesine girmeyeceğiz, karmaşıklıklar hakkındaki bir tartışma [burada](https://github.com/w3c/webauthn/issues/1614) bulunabilir. ![WebAuthn Attestation Object](https://www.corbado.com/website-assets/webauthn_attestation_object_ee7d5216e4.png)_WebAuthn spesifikasyonundan alınmıştır_ Authenticator verileri (**authData**) içinde, yeni oluşturulan açık anahtar, kullanıcının kimlik bilgisi ID'si ile birlikte güvenli bir şekilde saklanır ve Relying Party tarafından alınabilir. Geliştiricilerin herhangi bir WebAuthn tabanlı sistemde **attestationObject**'ten açık anahtarı çıkarma görevine yaklaşması gerektiğinden, mimarisini anlamak önemlidir. ### 5.2 Concise Binary Object Representation (CBOR) Nedir? CBOR (Concise Binary Object Representation), verileri kompakt, verimli ve genişletilebilir bir şekilde kodlamak için tasarlanmış bir veri formatıdır. İkili (binary) olması, metin tabanlı rol modeli JSON'dan daha küçük ve daha hızlı ayrıştırılmasını sağlar. Aşağıdaki örnek, JSON ve CBOR'un nasıl farklı olduğunu göstermektedir (Metin vs. İkili): | **JSON Metni** | **CBOR İkili Veri** | **CBOR kodu çözülmüş** | | ---------------- | ----------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | | **Ad**:_Corbado_ | A1 64 **4E 61 6D 65** 67 _43 6F 72 62 61 64 6F_ | A1 # bir girişli map(1)
64 # text(4)
**4E616D65** # **Ad**;
67 # text(7)
_436F726261646F_ # _Corbado_ | **Kalın olan Ad.** _İtalik olan Corbado._ (daha fazla bilgi [https://cbor.io/](https://cbor.io/) adresinde bulunabilir) WebAuthn bağlamında, CBOR birkaç nedenle kullanılır: - **FIDO2 / CTAP ile Bağlantı:** CBOR, temel standartlarda kullanıldığı için, hem WebAuthn hem de [CTAP](https://www.corbado.com/blog/passkeys-explained-clearly) aynı kompakt kodlama şemasını kullandığından verilerin ayrıştırılması ve işlenmesi kolaylaştırılır. - **Kompaktlık**: CBOR'un verimli kodlaması, özellikle mobil ağlarda veya bant genişliğinin kısıtlı olduğu ortamlarda veri boyutunu en aza indirmenin performansı önemli ölçüde etkileyebileceği web trafiği için mükemmel bir seçimdir. - **Esneklik**: CBOR, diziler, haritalar, metin dizeleri, bayt dizeleri ve genişletilebilirlik için etiketler dahil olmak üzere çeşitli veri türlerini ve yapılarını destekler. Bu, WebAuthn'in işlemleri için gereken farklı veri türlerini ve karmaşık yapıları işlemek için yeterince çok yönlü olmasını sağlar. - **Genişletilebilirlik**: Format, genişletilebilir olacak şekilde tasarlanmıştır, bu da mevcut uygulamalarla uyumluluğu bozmadan WebAuthn'e yeni özelliklerin eklenebileceği anlamına gelir. CBOR kullanımı, açık anahtarları ve **attestationObject**'i kodlamak için özellikle uygundur çünkü yukarıda tartıştığımız farklı formatları ve uzunlukları işlemesi gerekir. Örneğin, bir RSA anahtarı, bir ECDSA anahtarına kıyasla farklı niteliklere ve boyutlara sahip olacaktır. **attestationObject** içinde, açık anahtarlar CBOR tabanlı olan [COSE](https://www.corbado.com/blog/webauthn-pubkeycredparams-credentialpublickey) Anahtar formatında saklanır. ### 5.3 COSE Anahtar Formatı Nedir? Bir [COSE](https://www.corbado.com/blog/webauthn-pubkeycredparams-credentialpublickey) Anahtar yapısı, bir CBOR harita nesnesi üzerine kuruludur. RSA modülü ve üssü veya eliptik eğri açık anahtar koordinatları gibi çeşitli anahtar türlerini ve bunlara karşılık gelen parametreleri kapsayan, anahtar temsili için yapılandırılmış bir yol tanımlar. Bu standartlaştırılmış format, anahtarların temel kriptografik algoritmalarından bağımsız olarak, yukarıda tartıştığımız şifreleme algoritması ID'sine ek olarak tutarlı bir şekilde **serileştirilmesine ve deserileştirilmesine** olanak tanır. CBOR ve COSE Anahtar formatından yararlanarak, WebAuthn **geniş bir kriptografik işlem yelpazesini kolaylaştırırken yükün mümkün olduğunca küçük kalmasını sağlayabilir** ve kriptografik teknolojideki gelecekteki güncellemelere uyarlanabilir kalabilir. Bu seçim, WebAuthn'in web kimlik doğrulaması için güvenli, verimli ve ileriye dönük uyumlu bir protokol sağlama hedefleriyle uyumludur. ### 5.4 attestationObject'in Kodunu Çözme ve Ayrıştırma WebAuthn içinde **attestationObject**'in kodunu çözme söz konusu olduğunda, geliştiriciler önemli bir kararla karşı karşıya kalır: özel bir çözüm geliştirmek veya yerleşik bir kütüphaneden yararlanmak. Bu sürecin karmaşıklığı ve kritik doğası abartılamaz. Base64URL ve CBOR kod çözme işleminin manuel olarak uygulanması, teknik olarak mümkün olsa da, [kimlik doğrulama](https://www.corbado.com/tr/blog/revolut-passkeys-analizi) sürecinin bütünlüğünü tehlikeye atabilecek ince hatalar riskini beraberinde getirir. İmzanın kriptografik doğrulamasının yanı sıra diğer tüm doğrulama adımlarının doğruluğunu sağlamak için, **iyi test edilmiş ve yaygın olarak benimsenmiş bir WebAuthn kütüphanesi kullanılması şiddetle tavsiye edilir**. Bu tür kütüphaneler, **attestationObject**'in kodunu çözme ve doğrulama ayrıntılarını işlemek için şifreleme uzmanlığıyla oluşturulmuştur, bunlar arasında: - Attestation ifadesini ve Authenticator verilerini çıkarmak için CBOR formatını doğru bir şekilde ayrıştırma. - Açık anahtarı almak için COSE Anahtar formatını yorumlama. - WebAuthn standardına göre imzayı doğrulamak için kriptografik kontroller yapma. Saygın bir kütüphaneye güvenerek, geliştiriciler sadece zaman ve kaynak tasarrufu sağlamakla kalmaz, aynı zamanda içleri de rahat eder. Bu güvenilir araçlar aracılığıyla çıkarılan ve doğrulanan açık anahtar, daha sonra veritabanında güvenli bir şekilde saklanabilir ve güvenli kimlik doğrulama oturumları için kullanılmaya hazır hale gelir. Bu yaklaşım, protokolün spesifikasyonlarına bağlılığı sağlar ve WebAuthn uygulamalarında beklenen güvenlik duruşunu korur. Basitlik adına, CBOR alanlarının ayrıştırılmış JSON'a dönüştürüldüğü tamamen çözülmüş bir sürüm döndüren [SimpleWebauthn Debugger](https://debugger.simplewebauthn.dev/?credential=ewogICJpZCI6ICJhV01tRTRCRTlaenZSS2Q5clFoZHk2dWJybEIzQ09yVFJGUUFOZTZ5ZEhnIiwKICAicmF3SWQiOiAiYVdNbUU0QkU5Wnp2UktkOXJRaGR5NnVicmxCM0NPclRSRlFBTmU2eWRIZyIsCiAgInR5cGUiOiAicHVibGljLWtleSIsCiAgInJlc3BvbnNlIjogewogICAgImF0dGVzdGF0aW9uT2JqZWN0IjogIm8yTm1iWFJtY0dGamEyVmtaMkYwZEZOMGJYU2lZMkZzWnlaamMybG5XRWN3UlFJaEFJdlZOQ1RsWVhYN1dLT2ZldG83V3lCUUU2dXZYcHZuTnkyMmtxck14c19RQWlBbWFuRnFhbHJ2RF8xZmUwQ2IyZjYwbGp0aDRubmdja2tLSjhKUHRxWmlPMmhoZFhSb1JHRjBZVmlrdDhER1JUQmZscy1CaE9IMlFDNDA0bHZkaGVfdDJfTmt2TTBuUVdFRUFEZEZBQUFBQUszT0FBSTF2TVlLWklzTEpmSHdWUU1BSUdsakpoT0FSUFdjNzBTbmZhMElYY3VybTY1UWR3anEwMFJVQURYdXNuUjRwUUVDQXlZZ0FTRllJRFA0b25SS1ZIWGxod2JtV0Y0VjZqbWZzdVZ1U1hjaEdtNnhvY2VTQkd0aklsZ2czYnhaSWJLeUU3cVBjek1abVMwakNHQmY5Y2dhanM3N0VaTC1nTkFqTzBjIiwKICAgICJjbGllbnREYXRhSlNPTiI6ICJleUowZVhCbElqb2lkMlZpWVhWMGFHNHVZM0psWVhSbElpd2lZMmhoYkd4bGJtZGxJam9pUVVGQlFtVkNOemhJY2tsbGJXZ3hhbFJrU2tsRGNsOHpVVWRmVWsxUGFIQWlMQ0p2Y21sbmFXNGlPaUpvZEhSd2N6b3ZMMjl3YjNSdmJtNXBaV1V1WjJsMGFIVmlMbWx2SWl3aVkzSnZjM05QY21sbmFXNGlPbVpoYkhObGZRIiwKICAgICJ0cmFuc3BvcnRzIjogWwogICAgICAiaW50ZXJuYWwiCiAgICBdLAogICAgInB1YmxpY0tleUFsZ29yaXRobSI6IC03CiAgfSwKICAiYXV0aGVudGljYXRvckF0dGFjaG1lbnQiOiAicGxhdGZvcm0iLAogICJjbGllbnRFeHRlbnNpb25SZXN1bHRzIjoge30KfQo)'ı kullanacağız: ```json { "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": {} } ``` SimpleWebAuthn kütüphanesi, tüm attestationObject'in kodunu çözmek için kullanılır. Gördüğümüz gibi, tüm bilgiler artık okunabilir durumda. Tüm kriptografik bilgiler, authData bölümünün bir parçası olan [credentialPublicKey](https://www.corbado.com/blog/webauthn-pubkeycredparams-credentialpublickey)'nin içindedir ve kütüphane bunu parsedCredentialPublicKey ifadesine ayrıştırmıştır. Spesifikasyonda, COSE Anahtar Formatının nasıl göründüğüne dair birkaç örnek bulunmaktadır. ```json { "parsedCredentialPublicKey": { "keyType": "EC2 (2)", "algorithm": "ES256 (-7)", "curve": 1, "x": "M_iidEpUdeWHBuZYXhXqOZ-y5W5JdyEabrGhx5IEa2M", "y": "3bxZIbKyE7qPczMZmS0jCGBf9cgajs77EZL-gNAjO0c" } } ``` Bu çıktı, **credentialPublicKey**'nin tüm kriptografik öğelerini düzgün bir şekilde insan tarafından okunabilir forma ayrıştırılmış olarak gösterir. Bu özel örnek, algoritma parametresi ve **x** ve **y** koordinatlarının varlığıyla belirtildiği gibi, ES256 algoritması için bir EC2 anahtarını ortaya koymaktadır. Buna karşılık, bir Windows 10 sisteminin çıktısı aşağıdaki gibidir: ```json { "parsedCredentialPublicKey": { "keyType": "RSA (3)", "algorithm": "RS256 (-257)", "modulus": "mzRVwAL6jbccWT4NQ3rQWEYLkTKkEBeHPPUn0CXT8VwvvGE_IaXDeP9ZzcA7WoX3z6E0l_L-XZmRuKc9cO7BkiYyz3jOg_pNFTz5Ap9a1f_9H0m4mpL-30WHQZi1skB5f6zt8sO8q7rBYH0mRmH8LdCrhJRhVjB_UxbcAbYlpV98M5g-5OBs_boNXtMhMoyp-IOeGChp07wwSLVOH3hKMoxlU27hZ3QvK2LRWosNKhXSHcU9IOC0XOyhlZ5rtPX2ae3KsSE1H2rEJVcMaVMRAg8yx2SRM98pDvf829smrnJPdMBojKftne2j8o84i_xyDJ_jARlyVj0kxR37u0AVQQ", "exponent": 65537 } } ``` Burada, algoritma ID'si -257'dir, bu da RS256'ya karşılık gelir ve bu açık anahtarı karakterize eden niteliklerin bir ECDSA anahtarınınkilerden önemli ölçüde farklılaştığını görebiliriz. COSE Anahtar formatı, tür başına benzersiz nitelikler belirtmeye olanak tanır: | **Nitelik/Tür** | **ECDSA** | **RSA** | | -------------------- | ------------------------------ | ------------ | | Anahtar Türü | EC2 (Eliptik Eğri 2) | RSA (3) | | Algoritma | ES256 (-7) | RS256 (-257) | | Benzersiz nitelikler | Eğri X-koordinatı Y-koordinatı | Modül Üs | Ayrıca, RSA modülü, ES256 anahtarında kullanılan eliptik eğri koordinatlarından önemli ölçüde daha uzundur, bu da anahtar boyutlarındaki farklılıklar ve farklı kriptografik algoritmaların doğal gereksinimleri hakkındaki önceki tartışmamızı vurgulamaktadır. ## 6. Tavsiye Açık anahtarlı kriptografinin temellerini gözden geçirdikten ve WebAuthn / [FIDO2](https://www.corbado.com/glossary/fido2) standardına nasıl dahil edildiğini anladıktan sonra, Relying Party'ler için iki ana tavsiyemiz var: - **Doğru şifreleme algoritmalarını seçin:** WebAuthn uygulamasında, maksimum uyumluluk için doğru algoritmaları kullanmak önemlidir. Mevcut önerilere dayanarak, RS256, ES256 ve EdDSA kombinasyonu tavsiye edilir. RS256 ve ES256, geniş destekleri nedeniyle öne çıkar ve EdDSA'nın dahil edilmesi mümkün olan yerlerde güvenliği artırabilir. - **Açık anahtarı çıkarmak için iyi test edilmiş WebAuthn kütüphaneleri kullanın:** Algoritmalara karar verdikten sonra, bir sonraki adım iyi test edilmiş bir WebAuthn kütüphanesini entegre etmektir. Böyle bir kütüphane, _attestationObject_'i ayrıştırmanın karmaşıklıklarını yetkin bir şekilde ele alabilir. Kütüphane açık anahtarları ve ilişkili verilerini çıkardıktan sonra, veritabanında güvenli bir şekilde saklanabilir. Kütüphane tarafından kullanılan format genellikle anahtarın gelecekteki kimlik doğrulama amaçları için doğru bir şekilde okunabilecek ve kullanılabilecek şekilde saklanmasını sağlar. **Tekerleği yeniden icat etmemek çok önemlidir:** yerleşik kütüphanelerde yer alan kolektif bilgiden yararlanın. Özel uygulama, kimlik doğrulamanın etkinliğini ve sistemin genel güvenliğini baltalayabilecek hatalar ve güvenlik açıkları getirme riski taşır. ## 7. Sonuç Bu blog yazısında, başlangıçtaki üç temel soruyu yanıtlamak için açık anahtarlı kriptografinin temellerini araştırdık: 1. **WebAuthn'de Desteklenen Şifreleme Algoritmaları**: WebAuthn, esnek olacak şekilde tasarlanmıştır ve RSA (RS256), ECDSA (ES256) ve EdDSA dahil olmak üzere geniş bir şifreleme algoritması yelpazesini destekler. Bu uyarlanabilirlik, çeşitli Authenticator'lar ve platformlarla sorunsuz bir şekilde entegre olmasını sağlayarak geniş uyumluluk sağlar. 2. **Anahtar Çifti Oluşturmada pubKeyCredParams'ın İşlevselliği**: **pubKeyCredParams**, Relying Party'nin hangi kriptografik algoritmaları desteklediğini belirterek WebAuthn sürecinin kayıt aşamasında önemli bir rol oynar. Bu, oluşturulan anahtar çiftlerinin hem kullanıcının Authenticator'ı hem de Relying Party'nin gereksinimleriyle uyumlu olmasını sağlar. 3. **credentialPublicKey'nin İşlevselliği ve Açık Anahtarları Çıkarma**: **credentialPublicKey**, Authenticator'lar tarafından sağlanan attestationObject'ten açık anahtarları çıkarmak için kullanılır. Bunun yanı sıra, WebAuthn protokolünün belirli şifreleme algoritmalarından bağımsız olmasının, esnekliğini ve gelecekte ortaya çıkacak kriptografik yöntemlere karşı geleceğe dönüklüğünü önemli ölçüde artırdığını vurguladık. Bu makalenin, WebAuthn'de açık anahtarlı kriptografi ile ilgili kavramları / sorunları ayıklarken ve anlarken diğer geliştiricilere de yardımcı olacağını umuyoruz.