WebAuthn pubKeyCredParams ve credentialPublicKey: CBOR ve COSE

Dijital güvenlikte, passkey'ler 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 aracılığıyla doğrulamak isteyen web sitesinin arka ucu olan Relying Party (RP) sunucusunda saklanır. Özel anahtar ise işletim sistemine bağlı olarak bir Donanım Güvenlik Modülü'nde güvenli bir şekilde tutulur: Secure Enclave (iOS), TEE (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?

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.

Asimetrik kriptografi olarak da bilinen açık anahtarlı kriptografi, hem şifreleme hem de deşifreleme 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.

Kaynak: 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.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

İşte açık anahtarlı kriptografide kullanılan bazı yaygın algoritma türlerine genel bir bakış:

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.

Become part of our Passkeys Community for updates & support.

Join

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 seviyelerini ve kullanılan anahtarların gerçek boyutlarının bir yaklaşık değerini göstermektedir. Güvenlik seviyesi bit cinsinden ölçülür ve genellikle o boyuttaki bir simetrik anahtar şifresine karşılık gelir:

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 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. İşte AWS'nin 2018'de Cloudfront için ECDSA'yı uygularken yürüttüğü benchmark verilerinden bir örnek:

• İ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.

WebAuthn standardı bir şifreleme standardı değil, web uygulamaları için güçlü, açık anahtar tabanlı kimlik doğrulama sağlayan bir güvenlik protokolüdür. Kullanıcıların şifreler yerine biyometri, mobil cihazlar veya donanım güvenlik anahtarları (örneğin 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'nin (kullanıcılarıyla passkey kullanmak isteyen bir web sitesi) tarayıcı üzerinden kullanıcı ve onun Authenticator'ı ile anahtar alışverişi yapması gerektiği anlamına gelir. 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:

• (1) Relying Party desteklenen şifreleme algoritmalarını bildirir: 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, desteklediği şifreleme algoritmaları için pubKeyCredParams listesini kontrol eder ve benzersiz bir Credential ID 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 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):

• (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 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 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 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.

IANA'nın COSE 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.

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:

(*) = Güvenlik anahtarlarının küçük bir kısmı (ör. Yubikey'ler 5+, Solokey veya Nitrokey) IANA Tablosundan alıntı: Tam listeyi burada 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 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.

Passkey oluşturma için desteklenen şifreleme algoritmalarını yapılandırmak PublicKeyCredentialCreationOptions aracılığıyla yapılır:

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 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 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.

Çalışan bir örnek olarak, aşağıdaki PublicKeyCredentialCreationOptions'ı bir Mac'te Passkeys Debugger üzerinde çalıştıracağız.

{
    "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:

{
    "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.

Ö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.

attestationObject, WebAuthn kayıt sürecinde önemli bir rol oynar ve Authenticator tarafından sağlanan 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 (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 ifadesini kapsar. Passkey'ler 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 yazdık çünkü isteğe bağlı uzantılar için gereken değişken uzunluklar nedeniyle standart olmayan CBOR önekleri de söz konusudur. Bu konuya daha derinlemesine girmeyeceğiz, karmaşıklıklar hakkındaki bir tartışma burada bulunabilir.

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.

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):

Kalın olan Ad. İtalik olan Corbado. (daha fazla bilgi 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 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 Anahtar formatında saklanır.

Bir COSE 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.

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 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'ı kullanacağız:

{
    "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'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.

{
    "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:

{
    "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:

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.

Açık anahtarlı kriptografinin temellerini gözden geçirdikten ve WebAuthn / 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.

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.