Dinamik Eşleştirmede Biyometri ve Ödeme Yapanın Farkındalığı

Corbado'nun yaklaşımı, PSD2 RTS Madde 5'teki ("ne görüyorsan onu imzalarsın") gerekliliğini karşılamak için oltalama saldırılarına dayanıklı passkey'leri (SCA) banka kontrollü bir ekran ve sunucu tarafında dinamik eşleştirme ile birleştirir.

• Temel uygulama (bugün): İşlem tutarını ve alıcısını, passkey kimlik doğrulamasından hemen önce ve sırasında Bison Bank kontrollü bir kullanıcı arayüzünde gösteriyoruz. Arka ucumuz, standartlaştırılmış bir işlem anlık görüntüsüne (tutar, alıcı, txnId) bağlı tek seferlik bir challenge oluşturur. Yanıt, yalnızca bu anlık görüntüyle eşleşirse kabul edilir; herhangi bir değişiklik onu geçersiz kılar.

• Mevzuat açısından pozisyon: Passkey'lerle bile uzaktan ödemeler için dinamik eşleştirme zorunlu olmaya devam ediyor (PSD2 Mad. 97(2); RTS Mad. 5). RTS, dinamik eşleştirme "kimlik doğrulama kodunun" cihaz üzerinde hesaplanmasını gerektirmez; ekran bütünlüğü, belirginlik ve değişiklik durumunda geçersiz kılma zorunlu kılındığında sunucu tarafında oluşturma/doğrulama kabul edilebilir (ayrıca kodun nerede hesaplanabileceğine dair EBA Soru-Cevap 2020_5366'ya bakınız).

• Güvenlik ve denetlenebilirlik: Donanım tabanlı, oltalama saldırılarına dayanıklı bir passkey imzasını belirli işlem verilerine bağlamak, kurcalamayı ve aktarmayı önler ve ödeme yapanın rızasına dair güçlü, inkar edilemez kanıt sunar. Desteklendiği durumlarda, arka uç modelini değiştirmeden görüntülenen ayrıntıların kriptografik kanıtını eklemek için isteğe bağlı olarak Güvenli Ödeme Onayı'nı (SPC) benimseyebiliriz.

• SCA: Farklı kategorilerden (bilgi/sahiplik/biyometrik özellik) iki bağımsız unsur, ifşa/kopyalamaya karşı uygun azaltma önlemleriyle korunur (RTS Mad. 6–8). Bağımsızlık gereklidir (Mad. 9), çok amaçlı cihazlarda yürütüldüğünde ayrım da buna dahildir (ör. işletim sistemi düzeyinde korumalar, güvenli donanım).
• Dinamik eşleştirme (RTS Mad. 5):
  • (i) ödeme yapan, kimlik doğrulama sırasında tutar ve alıcıdan haberdar edilir
  • (ii) kimlik doğrulama kodu, o tutar/alıcıya özgüdür
  • (iii) herhangi bir değişiklik kodu geçersiz kılar
  • (iv) tutar, alıcı ve kodun gizliliği/bütünlüğü uçtan uca korunur. Bu, düzenlemenin “ne görüyorsan onu imzalarsın” amacını yerine getirir.
• Sonuç: Tek başına güçlü kullanıcı kimlik doğrulaması ödemeler için yeterli değildir. Onay, bağlayıcılığın ve ödeme yapana gösterimin denetlenebilir kanıtıyla birlikte belirli işlem verilerine bağlanmalıdır (RTS Mad. 5(1)(a–d)).

Açıklama — oltalama ve yetkilendirme karşılaştırması: Passkey'ler kaynağa bağlıdır, bu nedenle sahte alan adları geçerli imzalar alamaz. Ancak PSD2, uzaktan ödemelerde yetkilendirmeyi tam tutar ve alıcıya bağlamak, herhangi bir değişikliği geçersiz kılmak ve ödeme yapana gösterilenin bütünlüğünü korumak için hâlâ dinamik eşleştirme gerektirir (RTS Mad. 5(1)(a–d)). Dinamik eşleştirme, yalnızca oltalama saldırılarını değil, yetkilendirme bütünlüğünü de (MITM/MITB/TPP değişimi dahil) ele alır.

EBA 2019 Görüşü (EBA‑Op‑2019‑06), dinamik eşleştirmenin kimlik doğrulamayı tutara ve alıcıya bağladığını, faktörlerin bağımsızlığını gerektirdiğini ve benzersiz cihaz bağlama mevcut olduğunda cihaza bağlı kriptografik anahtarları sahiplik olarak kabul ettiğini pekiştirir. Ayrıca kimlik doğrulama sırasında ödeme yapana gösterilenin bütünlüğünü de vurgular. EBA Görüşü 2019

PSD2'den önce birçok banka, genellikle onay adımıyla birlikte tutarı veya alıcıyı göstermeyen SMS OTP'lerine veya basılı TAN listelerine güveniyordu. Bu boşluk, kimlik bilgileri çalındıktan sonra müşterileri istenmeyen transferleri yetkilendirmeye kandırmayı kolaylaştırıyordu. Dinamik eşleştirme, ödeme yapanın kimlik doğrulama sırasında tam tutar ve alıcıdan haberdar edilmesini sağlayarak ve kimlik doğrulama kodunu bu ayrıntılara özgü hale getirerek herhangi bir değişikliğin onu geçersiz kılmasını sağlamak için (RTS Mad. 5(1)(a–d)) bu boşluğu kapatmak amacıyla getirildi. SMS akışın bir parçası olduğunda, hizmet sağlayıcılar ayrıca kimlik doğrulamanın tüm aşamalarında tutar/alıcı ve kodun gizliliğini, orijinalliğini ve bütünlüğünü sağlamalıdır (Soru-Cevap 2018_4414; RTS Mad. 5(2)). Günümüzün uygulama içi onayları (örneğin, “John Smith'e Face ID ile 100 USD yetkilendirmek istiyor musunuz?”) bu “ne görüyorsan onu imzalarsın” ilkesini müşteri dostu bir şekilde uygular.

Bugün mobil cihazlarda iki model öne çıkıyor. Birincisi, bir anlık bildirim, müşteriyi işlem ayrıntılarını inceleyip onaylaması için uygulamaya derin bağlantı ile yönlendirebilir. Denetleyiciler, Madde 7 kontrollerinin yetkisiz kullanımı azaltmak ve kopyalamayı önlemek için mevcut olması ve genel sürecin RTS'ye uyması durumunda anlık bildirimin sahiplik unsurunun kanıtı olarak hizmet edebileceğini açıklığa kavuşturmuştur; yine de sosyal mühendislik riskleri devam etmektedir ve UX'te ele alınmalıdır (Soru-Cevap 2019_4984; RTS Mad. 7).

İkincisi, cihazın yerel biyometrik özelliklerini (PIN ile yedeklenmiş) kullanan onaylar, bir özel anahtar işleminin kilidini açmak için yerel olarak kullanıcı doğrulaması gerçekleştirir. Özel anahtar, güvenli bir donanım ortamında (Secure Enclave/TEE/TPM) bulunur ve bir challenge'ı imzalar. Bu, SCA'ya net bir şekilde karşılık gelir: biyometrik özellik (biyometri) artı cihaz bağlama ve cihaza bağlı bir kriptografik anahtarla kanıtlanan sahiplik (EBA‑Op‑2019‑06, para. 25, 35–37). Uzaktan ödemeler için, kodun tutara ve alıcıya dinamik olarak bağlanması ve bu ayrıntıların kullanıcı doğrulamasından önce ödeme yapana gösterilmesi gerekir (RTS Mad. 5). Her iki faktör de tek bir cihazdaysa, birinin ele geçirilmesinin diğerini tehlikeye atmaması için ayrı güvenli yürütme ortamları ve bütünlük kontrolleri uygulayın (RTS Mad. 9(2)–(3)).

İşin mutfağında, yerel biyometri doğrudan “bankaya kimlik doğrulaması” yapmaz. Bunun yerine, biyometrik (veya PIN yedeği) cihazda kullanıcı doğrulaması gerçekleştirir ve donanım destekli bir güvenlik modülünde saklanan dışa aktarılamayan bir özel anahtara erişimi kontrol eder. Ödeme yapan onayladığında, cihaz bu özel anahtarı kullanarak banka tarafından sağlanan bir challenge üzerinde dijital bir imza oluşturur. Banka bu challenge'ı işlemin standart bir anlık görüntüsüyle (tutar, alıcı, tanımlayıcılar) türetir veya ilişkilendirirse, sonuçtaki imza bu ayrıntılara özgü bir kimlik doğrulama kodu işlevi görür. Herhangi bir değişiklik, saklanan anlık görüntü artık eşleşmediği için veya gelişmiş tasarımlarda challenge türetimi değiştiği için kodu geçersiz kılar. Ödeme yapanın farkındalığı kısmı bir UX gerekliliği olarak kalır: kullanıcı doğrulamasından hemen önce banka kontrollü bir görünümde tutarı ve alıcıyı gösterin. Bu, birlikte, RTS Madde 5'in farkındalık, özgünlük/benzersizlik ve değişiklik durumunda geçersiz kılma gerekliliklerini karşılarken, Madde 7 kontrolleri ve cihaz bağlama sahiplik unsurunu kanıtlar.

• Sahiplik (cihaza bağlı ve senkronize anahtarlar): Passkey özel anahtarları güvenli donanımda (TEE/Secure Enclave/TPM) saklanır. Cihaza bağlı passkey'ler dışa aktarılamaz, bu da EBA'nın benzersiz cihaz bağlama beklentileriyle uyumludur (EBA‑Op‑2019‑06, para. 25, 35–37). Senkronize passkey'ler de, cihaz bağlama ve kopyalamayı önleyici kontroller etkili olduğu sürece her kimlik doğrulamada sahipliği kanıtlayabilir; düzenleyiciler unsur ile cihaz arasında güvenilir bir bağın gerekliliğini vurgulamıştır (EBA‑Op‑2019‑06; RTS Mad. 7).
• Biyometrik özellik/Bilgi (Kullanıcı Doğrulaması): Biyometrik (biyometrik özellik) veya cihaz PIN'i (bilgi) aracılığıyla Kullanıcı Doğrulaması, anahtarı yerel olarak etkinleştirir. Sahiplikle birleştiğinde, bu faktör bağımsızlığı ile gerçek 2FA'dır. Birinin ihlali diğerini tehlikeye atmaz.

Dinamik eşleştirme, kimlik doğrulamayı işleme bağlamakla ilgilidir. Bir banka için soru şudur: bir kullanıcının bir ödemeyi (örneğin, bir OTP veya imzalama cihazı yerine) bir passkey ile onaylamasına izin verirsek, bu onayın amaçlanan tutar ve alıcıya özgü olduğunu ve yeniden kullanılamayacağını veya manipüle edilemeyeceğini garanti edebilir miyiz?

Passkey'lerle dinamik eşleştirmeyi uygulamak için 2 seçenek vardır:

• Sunucu tarafı eşleştirme (standart): Arka ucun tam tutar ve alıcıyla ilişkilendirdiği tek seferlik bir WebAuthn challenge'ı oluşturun. Kullanıcı, banka kontrollü bir görünümde “Y'ye X€” görür ve bir passkey ile onaylar. Yanıt, yalnızca o işlem için kabul edilir. Herhangi bir değişiklik onu geçersiz kılar.
• Kriptografik dahil etme (gelişmiş): Tutar/alıcının bir hash'ini challenge'a gömün, böylece imza işlem verilerine taahhütte bulunur. Bu RTS tarafından gerekli değildir ancak arka uç değişikliklerinin bile doğrulamada başarısız olacağına dair güvence ekler.

Açık uyumluluk notu: RTS, dinamik eşleştirme “kimlik doğrulama kodunun” ödeme yapanın cihazında hesaplanmasını gerektirmez. Bir ödeme hizmeti sağlayıcısı, tutar/alıcı korunduğu ve herhangi bir değişiklik kodu geçersiz kıldığı sürece bunu sunucuda oluşturabilir ve doğrulayabilir (kodun konumu/zamanlaması hakkında EBA Soru-Cevap 2020_5366'ya bakınız). Bu bizim sunucu tarafı dinamik eşleştirme (standart) yaklaşımımızdır.

Her ikisi de işleme özgü, benzersiz, yeniden kullanılamaz bir “kimlik doğrulama kodu” üretir. Birincil uyarı ödeme yapanın farkındalığıdır: WebAuthn'ın kendisi neyin görüntülendiğini kanıtlamaz. Ekranın bütünlüğü banka kontrollü kullanıcı arayüzünden gelmelidir.

RTS Madde 5, ödeme yapanın kimlik doğrulama sırasında tutarı ve alıcıyı görmesini gerektirir. WebAuthn, neyin gösterildiğini tasdik etmez. Teoride, uygulama veya işletim sistemi ele geçirilirse, kimlik doğrulayıcı hâlâ imzalarken bir kullanıcı yanıltılabilir. Bu riskin pratikte nasıl ortaya çıktığını ve neden gerçek bir güvenlik riski olmadığını, daha çok bir düzenleme yorumu sorunu olduğunu aşağıda ayrıntılı olarak analiz edeceğiz.

Uyguladığımız ekran bütünlüğü kontrolleri:

• Banka kontrollü görünüm tutar + alıcıyı gösterir: görünüm engellenirse veya odak dışındaysa passkey çağrısını engelleriz
• Uygulama/web'de katman/kurcalama tespiti: gizli iframe'lerden passkey istemi gelmez
• Cihaz bütünlüğü/doğrulama denetimi: root'lu/jailbreak'li/ele geçirilmiş sinyallerde reddetme veya ek güvenlik adımı uygulama
• Sunucuda tutulan tutar/alıcı anlık görüntüsüne karşı atomik onay: herhangi bir parametre değişikliğinde yeni bir challenge gereklidir

Kriptografik dahil etme hakkında: WebAuthn “işlem görüntüleme” uzantıları (SPC) bugün yaygın olarak desteklenmemektedir. Taşınabilir temelimiz, imzanın bu değerlere taahhütte bulunması için challenge'ı işlem anlık görüntüsünden (ör. H(tutar ‖ alıcı ‖ txnId ‖ nonce)) türeterek güçlendirilmiş sunucu tarafı bağlamadır.

Her iki model de dışa aktarılamayan cihaz anahtarlarıyla açık anahtar kriptografisi kullanır ve her ikisi de imzalama işleminin kilidini açmak için yerel kullanıcı doğrulamasına dayanır. Her ikisinde de banka, kullanıcı doğrulamasından hemen önce tutarı ve alıcıyı banka kontrollü bir görünümde göstererek ödeme yapanın farkındalığını sağlar ve kimlik doğrulama kodunu bu ayrıntılara bağlayarak özgünlüğü sağlar — herhangi bir değişiklikte geçersiz kılar (RTS Mad. 5(1)(a–d)). RTS teknolojiden bağımsızdır ve tutar/alıcının bir işletim sistemi biyometrik penceresi içinde gösterilmesini gerektirmez; ödeme yapana gösterilmesini ve kodun bağlanmasını gerektirir (RTS Mad. 5). Her iki SCA unsuru tek bir cihazda yürütüldüğünde, Madde 9'un bütünlük ve ayırma gereklilikleri eşit şekilde uygulanır (RTS Mad. 9(2)–(3)). Son olarak, dinamik eşleştirme hesaplamasının konumu esnektir: bütünlük korunursa ve herhangi bir değişiklik kodu geçersiz kılarsa sunucu tarafında gerçekleştirilebilir (Soru-Cevap 2020_5366). Bunlar, düzenleyicilerin yerel biyometri ve PKI'yi zaten kabul ettiği aynı koşullardır — bu nedenle, aynı ödeme yapan farkındalığı ve bağlama kontrolleriyle uygulanan passkey'lerin eşdeğer bir temelde kabul edilmesi gerekir.

Peki, WebAuthn standardına göre basit passkey'ler dinamik eşleştirmenin amacını yerine getiriyor mu? Kısmen:

• MITM/ağ saldırıları: Evet. Kaynak bağlama ve challenge başına imzalar kurcalamayı ve yeniden oynatmayı önler.
• İşlem bütünlüğü: Evet. Sunucu ilişkilendirmesi veya challenge hash'leme, yalnızca orijinal tutar/alıcının doğrulanmasını sağlar.
• Ödeme yapanın rızası: Daha zor. Passkey'lerde kimlik doğrulayıcı düzeyinde bir ekran yoktur. Ele geçirilmiş cihazlarda kullanıcı arayüzü aldatmacası mümkün olabilir. Ödeme yapanın rızasını garanti altına almak için üzerine bir şeyler inşa edilmelidir.

Passkey'lerle dinamik eşleştirmeye neden hala ihtiyaç var?

• Yasal: PSD2 Mad. 97(2) ve RTS Mad. 5, tüm uzaktan ödeme başlatma işlemleri için dinamik eşleştirmeyi zorunlu kılar. Oltalama saldırılarına dayanıklı yöntemler için bir istisna yoktur.
• Güvenlik: Passkey'ler kaynaklar arası oltalama saldırılarını ortadan kaldırır, ancak kendi başlarına ödeme yapana neyin gösterildiğini kanıtlamazlar. Dinamik eşleştirme + ekran bütünlüğü kontrolleri, kullanıcının gördüğü belirli tutar/alıcının bankanın uyguladığı şey olmasını ve herhangi bir değişikliğin onayı geçersiz kılmasını sağlar.

Özetle, passkey'ler işlem verilerine sıkı sıkıya bağlandığında ve güvenilir görüntüleme mekanizmalarıyla eşleştirildiğinde dinamik eşleştirmeyi karşılayabilir. Geriye kalan zorluk, kullanıcının gerçekte ne gördüğünü kanıtlamaktır.

Corbado, yukarıdaki ödeme yapanın rızasıyla ilgili hususları açıkça ele alan, dinamik eşleştirmeyle uyumlu bir çözüm sunar.

// TODO KARUNA'DAN MOCKUP'LARI SAĞLA VE ONLARI AÇIKLA

Süreç akışı:

• Banka kontrollü ekran, ödeme yapana tam tutarı ve alıcıyı gösterir. Bu görünüm görünür olmadıkça hiçbir passkey istemi gösterilmez.
• Kimlik doğrulama: İstemci, standartlaştırılmış işlem için tek seferlik, bağlı bir challenge ile WebAuthn'ı çağırır. Kimlik doğrulayıcı, kullanıcı doğrulaması (biyometrik veya cihaz PIN'i) gerçekleştirir ve challenge ile kaynağı imzalar.
• Sunucu doğrulaması: Arka uç, RP ID hash'ini ve kaynağı doğrular, challenge'ı saklanan işlemle eşleştirir, UV/flag'leri kontrol eder, tek seferlik kullanımı ve süresinin dolmasını zorunlu kılar ve saklanan tutar/alıcı anlık görüntüsünü karşılaştırır.
• Onay ve denetim: Ancak o zaman işlem atomik olarak onaylanır. Herhangi bir uyuşmazlık/değişiklik reddedilir ve yeni bir kimlik doğrulaması gerektirir. Değişmez bir denetim kaydı saklanır (kimlik bilgisi ID'si, authenticatorData, clientDataJSON, imza, challenge ve standartlaştırılmış tutar/alıcı), isteğe bağlı olarak kurcalama kanıtı için hash zincirine bağlanır.
• Cihaz bütünlüğü denetimi: Cihaz bütünlüğünü ve doğrulama sinyallerini değerlendirin: cihaz root'lu/jailbreak'li/ele geçirilmişse reddedin veya ek güvenlik adımı uygulayın.
• Alıcı standardizasyonu: Kolay anlaşılır bir etiket görüntüleyin (ör. “ACME GmbH”), ancak standart bir alıcı tanımlayıcısına (ör. IBAN/BIC veya başka bir benzersiz şema) karşı bağlayın ve doğrulayın.

Teknik detaylar:

• Arka uç: Standartlaştırılmış verilerle bir işlem nesnesi oluşturun (ör. normalleştirilmiş para birimi/ondalıklar; standartlaştırılmış IBAN/lehtar). Bu değerlere taahhütte bulunan kısa ömürlü bir challenge oluşturun (ör. H(tutar||alıcı||txnId||nonce)); beklemede olarak saklayın; istemciye yalnızca opak ID'ler sunun.
• İstemci/kimlik doğrulayıcı: Ödeme yapan ayrıntılarını banka kontrollü bir görünümde oluşturun; yalnızca görünür olduğunda WebAuthn'ı (RP ID = Bison alanı) çağırın; kullanıcı doğrulaması gerektirin; kimlik doğrulayıcı, WebAuthn uyarınca challenge + kaynağı imzalar.
• Doğrulama/sonuçlandırma: İmza, RP ID hash'i, kaynak/tür, UV flag'lerini doğrulayın; yeniden oynatma/süre sonu önlemleri; değişmez tutar/alıcı anlık görüntüsünü karşılaştırın; atomik olarak onaylayın; denetim kaydını saklayın.
• Challenge'ı anlık görüntüden türetin:: challenge = H(tutar ‖ standartAlıcı ‖ txnId ‖ nonce)

UX politikaları:

• Tutar/alıcıya net vurgu; erişilebilir onay/iptal kontrolleri; kısa zaman aşımları; her zaman yeni bir challenge kullanarak sorunsuz yeniden denemeler; anında makbuzlar (ör. “Y'ye X€ onayladınız”). Ekran engellenirse passkey istemini engelleyin ve imzalamadan önce parametreler değişirse uyarın.
• Katmanları/engellenmiş içeriği tespit edin: işlem görünümü görünür değilse asla bir passkey istemi göstermeyin. Akış ortasında parametreler değişirse reddedin ve yeni bir challenge ile yeniden başlatın.

Uyumluluk notu: Bu uçtan uca tasarım RTS Madde 5'i karşılar: ödeme yapan farkındalığı (banka kontrollü ekran), özgünlük ve benzersizlik (tutar/alıcıya bağlı tek seferlik kod), değişiklik durumunda geçersiz kılma (sıkı sunucu kontrolleri) ve tüm aşamalarda tutar/alıcı ve kodun gizliliği/bütünlüğü (RTS Mad. 5(1)(a–d), 5(2); SMS bütünlüğü için ayrıca Soru-Cevap 2018_4414'e bakınız). Faktör bağımsızlığı (Mad. 7–9), uygun korumalara sahip çok amaçlı cihazlarda cihaza bağlı sahiplik ve yerel kullanıcı doğrulaması yoluyla korunur (RTS Mad. 9(2)–(3)).

Not:* Web akışları için Corbado, Apple'ın geniş destek sağlaması durumunda isteğe bağlı olarak Secure Payment Confirmation'ı benimseyecek ve tutar ile alıcıyı kriptografik olarak tasdik eden güvenilir bir tarayıcı aracılı ekran ekleyecektir.

Endişe: Oltalama saldırıları Yanıt: Passkey'ler tasarımları gereği oltalama saldırılarına dayanıklıdır: meşru kaynağa bağlıdırlar ve paylaşılan sırlar içermezler, bu nedenle kimlik bilgileri OTP'lerin aksine sahte bir sitede toplanamaz. Trafiği benzer görünümlü bir alan adına yönlendiren bir saldırgan, bankanın kaynağı için geçerli bir imza alamaz. Dinamik eşleştirme bu vektörde daha az katkıda bulunur, ancak herhangi bir onayın amaçlanan tutar ve alıcıya özgü olmasını sağlamak için zorunlu kalır. Tamamlayıcı önlemler (oltalama eğitimi, giriş ve ödeme onaylarının net bir şekilde ayrılması, olağandışı ödeme bağlamları için anomali/risk puanlaması) riski daha da azaltır.

Endişe: Sosyal mühendislik / Yetkilendirilmiş Anlık Ödeme (APP) dolandırıcılığı Yanıt: Hiçbir kimlik doğrulayıcı, bir kullanıcının sahte bahanelerle (ör. “güvenli hesap” dolandırıcılıkları) bir ödemeyi yetkilendirmesini tamamen engelleyemez. Dinamik eşleştirme, kullanıcının alıcıyı ve tutarı açıkça görmesini sağlar ve rızanın güçlü kanıtını sunar, ancak ikna edilmiş bir ödeme yapanı geçersiz kılamaz. Telafiler arasında bağlamsal uyarılar (yeni alıcı, ilk büyük transfer), yüksek riskli alıcılar için bekleme süreleri veya gecikmeli yürütme, daha güçlü alıcı doğrulaması ve risk sinyallerinde ek güvenlik kontrolleri (ekstra onay) bulunur. Ödeme sonrası bildirimler ve hızlı itiraz kanalları, zararın tespit edilmesine ve kontrol altına alınmasına yardımcı olur. Gerçek zamanlı bağlamsal uyarılar (ör. yeni alıcı, ilk büyük transfer), yüksek riskli alıcılar için bekleme süreleri, daha güçlü alıcı doğrulaması ve ödeme sonrası bildirimler (“Y'ye X€ onayladınız”) ekleyerek tespiti ve müdahaleyi hızlandırıyoruz.

Endişe: Kötü amaçlı yazılım veya cihazın ele geçirilmesi Yanıt: Özel anahtarlar dışa aktarılamaz ve her imza için yerel kullanıcı doğrulaması gerektirir, bu nedenle kötü amaçlı yazılımlar kimlik bilgilerini kolayca sızdıramaz. Gerçekçi risk, tamamen ele geçirilmiş bir işletim sisteminde kullanıcı arayüzü aldatmacasıdır. Güvenli/doğrulanmış kullanıcı arayüzü (ör. korumalı onaylar), cihaz bütünlüğü kontrolleri/doğrulama ve yüksek riskli cihazları engelleme ve SPC veya mevcut olduğunda bir onay uzantısı gibi güvenilir onaylarla riski azaltın. Ele geçirme göstergeleri ortaya çıkarsa (katman tespiti, root/jailbreak), bant dışı yeniden doğrulama kullanın veya yürütmeyi reddedin. Tamamen ele geçirilmiş bir cihazda hiçbir tüketici yöntemi mükemmel değildir, ancak bu kontroller pencereyi önemli ölçüde daraltır.

Endişe: Tarayıcıdaki adam / oturum ele geçirme Yanıt: Kötü amaçlı uzantılar veya enjekte edilen komut dosyaları, meşru kaynakta eylemler başlatabilir. Kaynağa bağlı passkey'ler siteler arası oltalama saldırılarını durdurur. Dinamik eşleştirme, tutar/alıcıya yönelik perde arkası düzenlemelerinin başarısız olmasını sağlar. Kanalı CSP/kurcalama önleyici kontrollerle ve her onay için yeni, tek seferlik bir challenge gerektirerek güçlendiriyoruz.

Endişe: İç tehdit veya sunucu tarafı kurcalama Yanıt: Kimlik doğrulama yanıtı, orijinal tutar/alıcıya benzersiz bir şekilde bağlıdır, bu nedenle herhangi bir sunucu tarafı değişikliği doğrulamada başarısız olur. Denetim/inkar edilemezlik için kurcalamaya dayanıklı, değişmez bağlantı kayıtlarını (challenge, kimlik bilgisi, imza ve standartlaştırılmış tutar/alıcı) koruyun. İç riski azaltmak için kritik ödeme işleme yollarında görevlerin ayrılması ve dört göz kontrollerini uygulayın.

Endişe: Çalınan cihazlar / kimlik bilgisi hırsızlığı Yanıt: Sadece cihaza sahip olmak yeterli değildir: her imza için kullanıcı doğrulaması (biyometrik/PIN) gereklidir, işletim sistemi düzeyinde hız sınırlamaları ve kilitlemelerle birlikte. Her ödeme, yeni, işleme özgü bir challenge gerektirir; genel oturum belirteçleri rastgele ödemeleri yetkilendiremez. Uzaktan cihaz iptali, yeni cihaz kullanımında ek güvenlik adımı, coğrafi hız kontrolleri ve bildirimler (“Y'ye X€ yetkilendirdiniz”) gibi eklemeler kötüye kullanımı daha da kısıtlar.

Genel olarak: passkey'ler oltalama ve yeniden oynatma risklerini önemli ölçüde azaltır; dinamik eşleştirme, işlem bütünlüğünü garanti etmek, onayları tutar/alıcıya bağlamak ve kalan tehdit senaryolarında bilgili rızanın güçlü kanıtını sağlamak için temel olmaya devam eder.

Soru 1: Bir passkey kullanırken kullanıcının tutarı ve alıcıyı gerçekten görüp onayladığını nasıl kanıtlayabiliriz? Yanıt: Ödeme yapanın gösterimini banka kontrollü bir görünümde zorunlu kılıyoruz ve onayı tutar/alıcının sunucu tarafı anlık görüntüsüne bağlıyoruz. Passkey onayı (authenticatorData, clientDataJSON, imza), yalnızca o anlık görüntüden türetilen challenge için kabul edilir; herhangi bir değişiklik yeni bir challenge gerektirir. Kurcalamaya dayanıklı denetimimiz, onayı “Payee-ID Y'ye X€” ile ilişkilendirir ve sistemimizin ayrıntılar farklı olsaydı devam etmeyeceğini kaydeder. Desteklendiği durumlarda, SPC, kullanıcının görüntülenen ayrıntıları onayladığına dair kriptografik kanıt ekler.

Soru 1: Bir passkey kullanırken kullanıcının tutarı ve alıcıyı gerçekten görüp onayladığını nasıl kanıtlayabiliriz? Yanıt: Bu esasen inkar edilemezlik sorusudur. PSD2 kapsamında, dinamik eşleştirme kullanıcının neyi onayladığının farkında olmasını sağlamak için tasarlanmıştır. Bir passkey ile elimizde tuttuğumuz kanıt, kriptografik imza (kimlik doğrulama kodu) ve ilgili verilerdir (sunucumuzda hangi tutar/alıcıya bağlı olduğu). Politika gereği, işlem ayrıntılarını kullanıcıya kimlik doğrulamadan önce uygulama veya web sayfasında gösteririz. O ekranı/görünümü ve o belirli işlem için sonraki başarılı passkey kimlik doğrulamasını günlüğe kaydederiz. Bir anlaşmazlık durumunda, kullanıcının cihazının (örneğin) “ACME Corp.'a 100€” ile ilişkilendirilmiş bir challenge için geçerli bir imza ürettiğini ve herhangi bir ayrıntı farklı olsaydı sistemimizin devam etmeyeceğini gösterebiliriz. Uyumluluğumuz güvenli günlük kaydına dayanır: sistemlerimizin passkey yanıtını işlem verilerine bağlarken kurcalamaya karşı korumalı olduğundan emin oluruz.

Soru 2: Cihaz veya işletim sistemi ele geçirilirse ne olur? Kötü amaçlı yazılım işlemi veya passkey sürecini manipüle edebilir mi? Yanıt: Cihazın ele geçirilmesi, herhangi bir dijital bankacılık senaryosunda kritik bir tehdittir. İşletim sistemi kötü niyetliyse, kullanıcıyı yanıltmaya veya süreçleri ele geçirmeye çalışabilir. Ancak, bu en kötü durumda bile, passkey'ler bazı temel korumaları sürdürür. Özel anahtar kötü amaçlı yazılımlar tarafından çıkarılamaz. Kötü amaçlı yazılım, kullanıcının biyometrik/PIN'i olmadan passkey imzasını üretemeyeceği için bankaya karşı kullanıcıyı taklit edemez. Yapabileceği en fazla şey, kullanıcıyı sahte bahanelerle bir şeyi doğrulamaya itmektir. Dinamik eşleştirme burada bütünlük kontrolleri gerektirerek yardımcı olur: kötü amaçlı yazılım, işlem ayrıntılarını sonradan sessizce değiştiremez – yaparsa, imza doğrulanmaz. En zayıf nokta ekran/kullanıcı arayüzüdür: gelişmiş bir Truva atı, kullanıcının gördüğünü değiştirebilir (ör. temeldeki işlem başka bir alıcıya giderken “ACME Corp” görüntülemek). Bu, özellikle banka uygulaması güvenli kullanıcı arayüzü çerçeveleri kullanıyorsa, önemsiz bir iş değildir, ancak düşünülebilir. Tüm bunlara rağmen, cihazın ele geçirildiğine dair işaretler tespit edersek (olağandışı davranış, bilinen kötü amaçlı yazılım imzaları vb.), bant dışı doğrulamaya geri döner veya işlemi reddederiz. Özetle: Kullanıcının cihazı bir saldırgan tarafından tamamen ele geçirilmişse hiçbir çözüm %100 değildir. Passkey'ler + dinamik eşleştirme, saldırı yüzeyini önemli ölçüde azaltır (bir saldırgan sadece kimlik bilgilerini proxy yapamaz veya ağ verilerini değiştiremez; kullanıcı üzerinde gerçek zamanlı bir oyun oynamak zorunda kalır). İşletim sistemi ele geçirilirse, dinamik eşleştirme en azından olması gereken ile onaylanan arasındaki herhangi bir uyuşmazlığın arka ucumuz tarafından yakalanmasını sağlar.

Soru 3: Passkey'in kilidini açmak için bir biyometrik kullanılırsa, bu tek faktör mü yoksa iki faktör mü sayılır? 2 faktör kuralına uyuyor muyuz? Yanıt: Tek başına bir biyometrik, SCA için yeterli değildir – sadece bir biyometrik özellik faktörüdür. Ancak, bir passkey uygulamasında biyometrik tek başına değildir: cihazın sahipliği diğer faktördür. Kullanıcının biyometrisi, cihazda saklanan özel anahtarın kilidini açar. Sahiplik ve biyometrik özellik iki farklı kategoridir. Bu, birçok bankacılık uygulamasının SCA'yı nasıl karşıladığına benzer: telefona sahipsiniz (sahiplik) ve uygulamanın kilidini açmak için parmak izinizi veya yüzünüzü kullanırsınız (biyometrik özellik). EBA, cihaz bağlama artı biyometrik kombinasyonlarını uyumlu SCA olarak açıkça tanımıştır. Passkey senaryosu tam olarak bu kombinasyondur. Kullanıcı passkey'in kilidini açmak için biyometrik yerine bir PIN kullanmayı seçerse, o zaman bu sahiplik + bilgidir, bu da uyumludur. Tüm passkey işlemlerinde kullanıcı doğrulaması zorunlu kılıyoruz (yani kullanıcının her seferinde biyometrik/PIN sağlaması gerekir), bu nedenle sadece cihaza sahip olmanın yeterli olduğu bir durum yoktur. Dolayısıyla, passkey aracılığıyla her ödeme yetkilendirmesi, PSD2 tanımları kapsamında iki faktörlü bir olaydır.

Soru 4: Bir saldırgan bir passkey kimlik doğrulamasını yeniden kullanabilir veya verileri taşıma sırasında manipüle ederek dinamik eşleştirmeyi bir şekilde atlatabilir mi? Yanıt: Hayır. Passkey'ler ve dinamik eşleştirmenin birlikte güçlü bir şekilde çalıştığı yer burasıdır. Her WebAuthn kimlik doğrulaması, (her işlem için oluşturduğumuz) challenge'a bağlı olan ve alan adımızla sınırlı olan benzersiz bir imza üretir. Bir saldırgan bu imzayı farklı bir işlem için yeniden oynatamaz. İmzanın kendisi challenge nonce'unu içerir ve yalnızca orijinal olarak verildiği şey için geçerlidir. Bir saldırgan ağ iletişimini ele geçirseydi, imzayı geçersiz kılmadan tutarı veya alıcıyı değiştiremezdi (çünkü challenge veya işlem bağlamı artık eşleşmezdi). Bu, tartıştığımız MITM korumasıdır. Ayrıca, passkey imzaları kaynak verilerini içerir – tam web sitemiz/uygulama kaynağımıza gönderilmezlerse doğrulanmazlar, bu nedenle oltalama veya yönlendirme işe yaramaz. Kısacası, herhangi bir manipülasyon girişimi, dinamik eşleştirme kurallarına göre kimlik doğrulama kodunu geçersiz kılar. Bu aslında, kullanıcıların bazen genel bir kodu onayladığı ve isteğin kurcalanmış olma riskinin bulunduğu bazı mevcut OTP tabanlı akışlardan daha güvenlidir. Passkey'lerle, kullanıcı kimlik doğrulamasını belirli bir oturuma/işleme kriptografik olarak bağlarız.

Soru 5: SCA için WebAuthn/passkey'ler hakkında bilinen herhangi bir düzenleyici görüş var mı? Düzenleyicilerin passkey'leri uyumlu olarak kabul edeceğinden emin miyiz? Yanıt: Şu an itibariyle, EBA Soru-Cevap veya rehberliğinde WebAuthn veya “passkey'ler” terimi hakkında açıkça görüş yayınlamamıştır. Ancak, ortaya koydukları ilkelere dayanarak, passkey'ler kabul edilebilir yöntemler arasına açıkça girmektedir. EBA'nın 2019 görüşü esasen FIDO2 benzeri yaklaşımları öngörmüştür: sahiplik için, sahiplik kanıtı olarak uygun cihaz bağlama ile “açık/özel anahtar alışverişini” açıkça belirtmişlerdir. Bir WebAuthn passkey'i tam olarak budur – özel yarısı cihaza güvenli bir şekilde bağlı olan bir açık/özel anahtar çifti. Ayrıca “bir cihaz tarafından oluşturulan imza”ya geçerli bir sahiplik kanıtı olarak onay vermişlerdir. Dolayısıyla, passkey terimini kullanmasalar da, yöntem örnekleriyle kapsanmaktadır. Ayrıca, Avrupa'daki büyük ödeme oyuncularının passkey uygulamalarına (ör. PayPal) yöneldiğini gözlemledik, bu da bunun PSD2 uyumlu olduğuna dair bir güven seviyesi olduğunu göstermektedir. Bu örnek, dinamik eşleştirme ve genel gereklilikler karşılandığı sürece passkey'lerin uyumlu SCA akışlarının bir parçası olarak kabul edildiğini göstermektedir.

Soru 6: Passkey'ler oltalama saldırılarına dayanıklıysa dinamik eşleştirmeye hâlâ ihtiyaç var mı? Yanıt: Evet. Passkey'ler kaynaklar arası oltalama saldırılarını ortadan kaldırır, ancak PSD2 uzaktan ödeme başlatma için hâlâ dinamik eşleştirme zorunlu kılar. Dinamik eşleştirme, belirli tutarı ve alıcıyı SCA sonucuna bağlar ve herhangi bir değişikliği geçersiz kılar, bu da oltalama dışındaki yetkilendirme bütünlüğünü (ör. MITM/MITB/TPP değişimi) ele alır.

Corbado'nun çözümü Dinamik Eşleştirme ve PSD2 uyumludur. Kimlik doğrulama öncesi ödeme yapan ekranı, tutar ve alıcıya bağlı tek seferlik challenge, sıkı sunucu doğrulaması ve değişmez denetim, RTS Madde 5'in ödeme yapan farkındalığı, benzersizlik/özgünlük, değişiklik durumunda geçersiz kılma ve bütünlük/gizlilik gerekliliklerini birlikte karşılar. Faktör bağımsızlığı, EBA rehberliğiyle uyumlu olarak cihaza bağlı sahiplik ve UV (biyometrik veya PIN) aracılığıyla korunur.

Günümüzün OTP/SMS yöntemlerine kıyasla Corbado, oltalama ve aktarmaya karşı direnç, sessiz parametre kurcalamasının önlenmesi, daha güçlü inkar edilemez kanıt ve cihaz içi UV aracılığıyla azaltılmış sürtünme gibi önemli ölçüde daha iyi güvenlik ve kullanıcı sonuçları sunar. Kalan riskler (ör. sosyal mühendislik, ele geçirilmiş cihazlar) somut kontrollerle azaltılır ve eski yöntemlere göre daha dardır. Web için Corbado, platform desteği (özellikle Apple) geniş olduğunda SPC'yi benimseyebilir ve temel uyumluluk duruşunu değiştirmeden ekranın kriptografik kanıtını ekleyebilir.

Kısacası, Corbado'nun passkey tabanlı işlem yetkilendirmesi, PSD2 dinamik eşleştirmenin lafzına ve ruhuna uyar ve eski yaklaşımlara kıyasla dolandırıcılığa karşı dayanıklılığı ve denetlenebilirliği artırırken, ekosistem olgunlaştıkça gelecekteki geliştirmelere (SPC) açık bir yol sunar.

Pratikte, passkey'ler üç şeyi yaptığımızda dinamik eşleştirmeyi karşılar: kullanıcı doğrulamasından önce tutarı ve alıcıyı ödeme yapana gösteririz; bu kesin ayrıntılara özgü bir kimlik doğrulama kodu oluştururuz; ve herhangi bir değişiklikte kodu geçersiz kılarız (RTS Mad. 5(1)(a–d)). Bu, düzenleyicilerin yerel biyometri için zaten kabul ettiği ilkeleri yansıtır, ek olarak passkey'lerin işletim sistemi yerel olması ve ek bir uygulama olmadan web ve uygulama kanallarında çalışması rahatlığıyla birlikte. Kaynak bağlama ile birleştirildiğinde, sahte istekleri yüzeye çıkarmazlar — yalnızca orijinal siteden veya uygulamadan gelen meşru istemler kullanıcıya görünür.