WebAuthn'de Attestation (Tasdik) Nedir?

Attestation (Tasdik) üç anlama gelebilir (konuşma dilinde genellikle birbirinin yerine kullanılsa da, tam olarak ele alındığında farklı anlamlara gelirler):

1. İlk olarak ve daha genel anlamda, kriptografi alanında attestation, bir tarafın başka bir tarafa bir ifadeyi kriptografik olarak "tasdik ettiği" bir terimdir.

2. İkinci olarak, WebAuthn içindeki kayıt aşamasında, authenticator (doğrulayıcı) tarafından bir attestation object (tasdik nesnesi) oluşturulur ve Relying Party (Güvenen Taraf)'ye döndürülür. Bu, aşağıdaki bilgileri içeren bir kapsayıcı nesnedir:

   • attestation statement format (fmt) (tasdik beyanı formatı)
   • attestation statement (attStmt - aşağıya bakın) (tasdik beyanı)
   • authenticator data (authData) (doğrulayıcı verileri)

Become part of our Passkeys Community for updates & support.

Join

3. Üçüncü olarak, WebAuthn içinde, bir attestation statement (tasdik beyanı), tasdik nesnesinin isteğe bağlı bir öğesidir. Bu beyan, dahil edildiğinde, tasdik sürecine dahil olan authenticator (doğrulayıcının) (cihazın) belirli özelliklerini doğrular. Ancak, bazı cihaz üreticileri (örneğin Apple) bir tasdik beyanı sunmaz, çünkü spesifikasyonun bu yönü geçiş anahtarı senkronizasyonu için tasarlanmamıştır ve kimlik bilgileri farklı cihazlar arasında senkronize edilebildiğinde (örneğin, bir geçiş anahtarı bir iPhone'da oluşturulup aynı iCloud Keychain aracılığıyla bir MacBook'ta da kullanıldığında) güvenlik niteliklerini etkili bir şekilde doğrulayamaz. Tasdik beyanı sağlandığında verilebilecek özellikler:
   • Kimlik doğrulama sırasında orijinal ve güvenilir bir cihazın kullanıldığına dair kanıt sunar.
   • Cihazın kökeni, modeli ve diğer ilgili bilgiler hakkında ayrıntılar sağlar.
   • Özellikle cihazın güvenilirliğinin kritik olduğu senaryolarda (örneğin, sağlık gibi belirli düzenlenmiş sektörlerde) güvenlik önlemlerini artırır.

Aşağıdaki Kayıt işlem akışı, WebAuthn'deki attestation (nesnesinin) rolünü göstermektedir:

{
    "root": {
        "id": "QFPlQVypLmmx71e0tmS3IfCFky0",
        "rawId": "QFPlQVypLmmx71e0tmS3IfCFky0",
        "response": {
            "attestationObject": {
                "fmt": "none",
                "attStmt": {},
                "authData": {
                    "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
                    "flags": {
                        "userPresent": true,
                        "userVerified": true,
                        "backupEligible": true,
                        "backupStatus": true,
                        "attestedData": true,
                        "extensionData": false
                    },
                    "counter": 0,
                    "aaguid": "00000000-0000-0000-0000-000000000000",
                    "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0",
                    "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...",
                    "parsedCredentialPublicKey": {
                        "keyType": "EC2 (2)",
                        "algorithm": "ES256 (-7)",
                        "curve": 1,
                        "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM",
                        "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw"
                    }
                }
            },
            "clientDataJSON": {
                "type": "webauthn.create",
                "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
                "origin": "https://passkeys.eu",
                "crossOrigin": false
            },
            "transports": ["hybrid", "internal"],
            "publicKeyAlgorithm": -7
        },
        "authenticatorAttachment": "cross-platform"
    }
}

Yukarıdaki ekran görüntüsünde, hiçbir AAGUID ve hiçbir tasdik beyanı sağlanmamıştır.

Want to experiment with passkey flows? Try our Passkeys Debugger.

Try for Free

En önemli niteliklerin teknik bir dökümü için okumaya devam edin.

WebAuthn içinde, attestation kullanıcı kimlik doğrulamasının güvenli ve şeffaf olmasını sağlar. Tasdik beyanı ile, bir kimlik bilgisinin belirli bir authenticator (doğrulayıcı) / cihaz üzerinde oluşturulduğundan emin olabilirsiniz.

Bu attestation türleri, attestation statement (tasdik beyanını) ifade eder (attestation nesnesini değil). Bunlar relying party (güvenen taraf) tarafından bir tercih olarak kabul edilir (bu nedenle authenticator (doğrulayıcı) farklı davranabilir çünkü bu sadece bir tercihtir).

• Attestation Yok (none): Gizliliğin en önemli olduğu veya senkronize edilmiş cihazların kullanıldığı durumlar için bu tür, cihaz hakkında hiçbir bilgi sağlamaz ve kullanıcının gizliliğinin korunmasını sağlar. Bu değeri kullanmanın bir başka nedeni, bir sertifika yetkilisine (CA) gidiş-dönüşü (roundtrip) engellemek olabilir. none aynı zamanda varsayılan değerdir.
• Dolaylı Attestation (indirect): Relying party (güvenen taraf), bir tasdik almayı tercih eder ancak istemcinin tasdik beyanlarını nasıl elde edeceğine karar vermesine izin verir. İstemci, kullanıcının gizliliğini korumak için doğrulayıcı tarafından oluşturulan tasdik beyanlarını anonim tasdik beyanlarıyla değiştirebilir.
• Doğrudan Attestation (direct): Bu en şeffaf formdur. Burada, relying party (güvenen taraf), doğrulayıcıya bir tasdik beyanı istediğini söyler, böylece relying party (güvenen taraf) cihaz hakkında markası, modeli ve diğer özellikleri de dahil olmak üzere ayrıntılı bilgi alır. En yüksek şeffaflığı sunsa da, belirli senaryolarda gizlilik endişeleri doğurabilir veya senkronize edilmiş kimlik bilgileri için gerçekten kullanışlı olmayabilir.
• Kurumsal Attestation (enterprise): Relying party (güvenen taraf), benzersiz tanımlayıcı bilgiler içerebilen bir tasdik beyanı almak ister. Bu tür bir tasdik, genellikle belirli cihazları / doğrulayıcıları takip etmek isteyen işletmelerde veya kuruluşlarda kullanılır. Web tarayıcıları (kullanıcı aracıları), ayarları istekte bulunan taraf için özel olarak izin vermedikçe bu ayrıntılı tasdiki sağlamamalıdır. Ayarlar izin veriyorsa, tarayıcı, bu özel tasdik türünün talep edildiğini cihaza (sürecin başında) bildirmelidir. Tarayıcı daha sonra cihazın benzersiz kimliğini ve tasdik kanıtını tam olarak aldığı gibi güvenen tarafa iletmelidir.

Subscribe to our Passkeys Substack for the latest news.

Subscribe

Attestation nesnesi birçok nitelik içerir, işte bazı seçilmiş niteliklerin hızlı bir açıklaması:

"attestationObject": {
        "fmt": "none",
        "attStmt": {},
        "authData": {
          "rpIdHash": "t8DGRTBfls-BhOH2QC404lvdhe_t2_NkvM0nQWEEADc",
          "flags": {
            "userPresent": true,
            "userVerified": true,
            "backupEligible": true,
            "backupStatus": true,
            "attestedData": true,
            "extensionData": false
          },
          "counter": 0,
          "aaguid": "00000000-0000-0000-0000-000000000000",
          "credentialID": "QFPlQVypLmmx71eOtmS3IfCFky0",
          "credentialPublicKey": "pQECAyYgASFYIEa-lpSiQ4P...",
          "parsedCredentialPublicKey": {
            "keyType": "EC2 (2)",
            "algorithm": "ES256 (-7)",
            "curve": 1,
            "x": "Rr6WlKJDg8MlbIq9mmHQzk2p2c_s7QoNKr7yMa7I8pM",
            "y": "tAELYp7h3sYNjZZIZgHPYiaSzF×QVT18cgZ_7wm13Vw"
          }
        }

attestationObject, yeni oluşturulan kimlik bilgileri, açık anahtar ve diğer ilgili veriler hakkında bilgi içeren CBOR kodlu bir nesnedir:

• fmt, tasdik formatını temsil eder, çünkü doğrulayıcılar tasdik verilerini farklı şekillerde sağlayabilir. Sunucuya, tasdik verilerini nasıl doğrulaması gerektiğini söyler. İzin verilen değerler "packed", "tpm", "android-key", "android-safetynet", "fido-u2f", "apple" veya "none" olabilir. Ayrıntılar için buraya bakın
• attStmt, tasdik beyanıdır. iOS veya Android cihazlarındaki geçiş anahtarları gibi durumlarda, iOS veya Android üzerindeki geçiş anahtarları senkronize edilebildiği için boş bırakılır ve Windows veya donanım güvenlik anahtarları gibi diğer cihazlar için doldurulur.
• authData, aşağıdaki verileri içeren bir değerler arabelleğidir:
  
  Tasdik edilmiş kimlik bilgisi verileri burada önemli bir rol oynar. Şunları içerir:
  • AAGUID,
  • Credential ID uzunluğu,
  • Credential ID ve
  • Kimlik bilgisi açık anahtarı.

Yukarıdaki attStmt'nin okunabilirlik nedeniyle boş bırakıldığı attestation nesnesinin aksine, doldurulmuş bir tasdik beyanı şöyle görünür.

{
    "alg": -65535,
    "sig": "MBHX7qov53SWqqPYCrxE5fcoAeDI83a0DzVJ2-N1KI6IAaCGGvINAIFzTEn44F6giANKte-8yEMDZbvbgDG1weaRj7SqsVaTty-TEQ",
    "ver": "2.0",
    "x5c": [
        "MIIFwDCCA6oIaK6tZ7M",
        "MIIG6zCCBNpG18-MCJrHyrpMT-ul7RgxE4dFxqcG59ftTXqJ1f-X_Lpo7K-d7OgKoQrUgzxgATz8YXtFAk3rE1cHXvW9W52V637eAihKn9-UKC0ijzVXrBGX4Iq1o1M0ZfR-tFoOn498xasMCTnharKiM562GBLVJtlvV3DMSLEBl5SfuGM-qYjQgTQknXccks9guCmNaN_b2fo1DisbufXfjM3DVaMqx7IJpSc3wAnxooMrAYGpPM"
    ],
    "pubArea": "AAEACwAw_c3Ousz865mUPx8O3w",
    "certInfo": "_1RDR4AXAniCekfsiDI"
}

• alg: alg özelliği, doğrulayıcı tarafından tasdik beyanını imzalamak için kullanılan kriptografik algoritma tanımlayıcısını belirtir.
• sig: sig özelliği, doğrulayıcı tarafından oluşturulan dijital imzayı içerir. Bu imza, tasdik beyanının orijinalliğini doğrulamak için kullanılır.
• ver: ver özelliği, tasdik beyanı formatının sürümünü belirtir.
• x5c: x5c dizisi, tasdikin doğrulanmasına yardımcı olan bir sertifikasyon yolu oluşturan bir veya daha fazla X.509 sertifikası içerir.
• pubArea: pubArea özelliği, açık anahtar ve doğrulayıcının özellikleri hakkında ayrıntılı bilgi içerir.
• certInfo: certInfo özelliği genellikle doğrulayıcının güvenilir bir taraf tarafından sertifikalandırılması hakkında bilgi içerir.

"clientDataJSON": {
        "type": "webauthn.create",
        "challenge": "AAABeB78HrIemh1jTdJICr_3QG_RMOhp",
        "origin": "https://www.passkeys-debugger.io",
        "crossOrigin": false
      }

clientDataJSON hakkında daha fazla bilgiyi ilgili sözlük makalesinde okuyun.

"transports": [
        "hybrid",
        "internal"
      ]

transports özelliği, bir doğrulayıcının bir istemciyle iletişim kurabileceği mekanizmaları belirtir. Bazı yaygın, örnek değer kombinasyonları şunlardır:

• "transports": ["internal","hybrid"]: Geçiş anahtarları, platform doğrulayıcısından (ör. Face ID, Touch ID, Windows Hello) veya cihazlar arası kimlik doğrulama yoluyla ( QR kodu ve Bluetooth kullanarak) kullanılabilir.
• "transports": ["internal"]: Geçiş anahtarları, platform doğrulayıcısından (ör. Face ID, Touch ID, Windows Hello) kullanılabilir.
• transports özelliği ayarlanmamışsa: herhangi bir belirti vermeyen varsayılan davranış.

Attestation (tasdik beyanı), WebAuthn içinde bir doğrulayıcının orijinalliğinin kanıtını sunduğu için önemlidir. Kimlik doğrulama işleminin güvenilir bir cihaz tarafından gerçekleştirilmesini sağlayarak potansiyel güvenlik tehditlerine karşı koruma sağlar.

Ben Gould

Head of Engineering

I’ve built hundreds of integrations in my time, including quite a few with identity providers and I’ve never been so impressed with a developer experience as I have been with Corbado.

3.000'den fazla geliştirici Corbado'ya güveniyor ve geçiş anahtarlarıyla İnternet'i daha güvenli hale getiriyor. Sorularınız mı var? Geçiş anahtarları üzerine 150'den fazla blog yazısı yazdık.

Passkeys Topluluğuna Katılın

Evet, geçiş anahtarları cihazlar arasında senkronize edilebildiği için (örneğin, iPhone'dan MacBook'a Keychain aracılığıyla), güvenen taraflar artık bir uygulamaya veya web sitesine gerçekten hangi tasdik edilmiş cihazın giriş yaptığını belirleyemezler. Bu nedenle, Apple ve Google, senkronize edilmiş geçiş anahtarları için artık tasdik beyanı sağlamamaya karar verdiler. Ancak, güvenen taraflar için kullanıcı deneyimini iyileştirmek ve onlara Apple ve Google ekosisteminden (iCloud Keychain ve Google Password Manager) gelen geçiş anahtarlarını tanıma ve görüntüleme fırsatı vermek için, AAGUID hala sağlanacaktır (WebAuthn sunucu ayarlarında PublicKeyCredentialCreationOptions için attestation direct veya indirect olarak ayarlandığı sürece). Ayrıntılar için bu GitHub konusuna bakın.

Web sitenize ve uygulamanıza geçiş anahtarı kimlik doğrulaması entegre etmek ve kullanıcılarınıza harika bir geçiş anahtarı kullanıcı deneyimi sunmak istiyorsanız, aşağıdakileri göz önünde bulundurmalısınız. Çözümünüzü öncelikle kullanıcılarınızın çoğunun Windows, iOS, macOS veya Android işletim sistemi kullandığı bir senaryo için oluşturduğunuzu varsayıyoruz. Ayrıca, geçiş anahtarlarının çoğunun (Windows hariç) senkronize edilmiş geçiş anahtarları olduğunu varsayıyoruz. Ne iOS, ne macOS ne de Android artık bir tasdik beyanı göndermediğinden, bir doğrulayıcının gerçek doğrulaması artık kullanılmamaktadır (Windows için bu hala çalışmaktadır, muhtemelen Windows henüz Windows Hello aracılığıyla senkronize edilmiş geçiş anahtarları sunmadığı için). Ancak, hesap ayarlarında daha iyi geçiş anahtarı yönetimi için AAGUID almak amacıyla, attestation tercihini indirect olarak ayarlamanızı öneririz, çünkü bu, tasdik beyanı gönderilirken (Windows) veya gönderilmezken (iOS, macOS, Android) AAGUID'yi almanıza olanak tanır.

FIDO metadata hizmeti, çeşitli doğrulayıcılar için bir metadata deposu sağlar. Attestation sırasında, bu hizmet doğrulayıcı hakkındaki ayrıntıları almak ve doğrulamak için sorgulanabilir, bu da doğruluğu sağlar ve sürecin güvenilirliğini artırır. FIDO metadata hizmeti, tasdik beyanını (attestation object'i değil) kontrol eder.

Evet, doğrudan attestation (tasdik beyanında), cihaz hakkında ayrıntılı bilgi sağlayarak en yüksek şeffaflığı sunsa da, belirli senaryolarda gizlilik endişeleri doğurabilir. Attestation türünü seçerken şeffaflık ihtiyacını gizliliğe karşı değerlendirmek çok önemlidir.

WebAuthn, farklı türde attestation tercihleri sunar – none, indirect, direct ve enterprise. Kullanıcı gizliliğinin önemli olduğu senaryolar için, cihaz hakkında hiçbir ayrıntı sağlamayan attestation=none kullanılabilir, bu da kullanıcının gizliliğinin korunmasını sağlar.