Güvenlik Mimarisi Teknik Belgesi (Whitepaper)
Sürüm: Taslak 1.0 · Kapsam: Sıfır-bilgi (zero-knowledge) Türk dijital kimlik doğrulama platformunun güvenlik mimarisi, tehdit modeli ve doğrulanabilirlik garantileri.
1. Özet
VerifyBlind, kullanıcının kimlik bilgilerini hiçbir entegratör partnere ve VerifyBlind altyapısına ifşa etmeden, kişinin gerçek, canlı ve NFC çipiyle doğrulanmış bir kimlik sahibi olduğunu kanıtlayan bir doğrulama sistemidir.
Tasarımın merkezindeki ilke şudur: hassas kimlik verisi, kullanıcının cihazı ile AWS Nitro Enclave (donanımsal olarak izole, doğrulanabilir bir hesaplama ortamı) arasından dışarı çıkmaz. Partner yalnızca minimum doğrulama sonucunu alır (ör. age: 18+, takma kimlik kodu).
Bu belge; kriptografik tasarımı, donanımsal güven kökünü (Nitro attestation + PCR0 sürüm doğrulaması), NFC kimlik doğrulamayı, biyometrik canlılık kontrolünü, oturum/ticket güvenliğini, istemci bütünlüğünü ve build doğrulanabilirliğini açıklar.
2. Tasarım İlkeleri
- Veri minimizasyonu / sıfır-bilgi: Partner, "kim olduğunu" değil, yalnızca sorduğu doğrulama önermesinin doğru olup olmadığını öğrenir. Kimlik bilgileri partnere hiç iletilmez.
- İzolasyon: Tüm kriptografik açma ve kimlik işleme adımları yalnızca Nitro Enclave içinde olur. Genel ağa açık relay servisi (API) düz metin kimlik verisini göremez ve saklayamaz.
- Doğrulanabilirlik: Hangi enclave kodunun çalıştığı, attestation belgesindeki PCR0 ölçümüyle kriptografik olarak kanıtlanır; istemci uygulamaların bütünlüğü platform attestation'ı ile sınanır.
- Saklamama (no-retention): VerifyBlind, ham kimlik/biyometri verisini kalıcı olarak saklamaz; yalnızca denetim için gereken, kimliği açığa çıkarmayan kayıtları tutar (bkz. §12).
3. Sistem Mimarisi
Mobil Uygulama Relay (API) Enclave (Nitro)
(Android / iOS) :5102, ağ-açık izole, /dev/nsm
─────────────── ───────────── ────────────────
NFC kimlik okuma ──TLS──► yönlendirme/ şifre çözme,
canlılık (yüz) istek sınırlama, NFC doğrulama,
şifreleme (cihazda) nonce/state (Redis), biyometri, canlılık,
denetim/log ticket imzalama (MAC)
│ │
└── PostgreSQL 15 ───────────┘
└── Redis 7 (nonce/state)
Partner Web Sitesi ──► verifyblind.js widget ──► Relay (sonuç kanalı)- Relay (ASP.NET 9): Genel ağa açık tek bileşen. Mobil, partner ve enclave arasında köprü; istek sınırlama, nonce/state yönetimi (Redis), denetim kaydı ve webhook iletimi. Düz metin kimlik verisini görmez — enclave'e giden yük zaten cihazda şifrelenmiştir.
- Enclave (ASP.NET 9, ARM64/Graviton): AWS Nitro Enclave içinde çalışır. Üretimde dış dünyaya yalnızca vsock üzerinden bağlıdır; RAM'i ana makineden (parent EC2) donanımsal olarak izoledir. Tüm hassas kripto burada olur.
- Veri katmanı: PostgreSQL 15 (denetim, rıza, doğrulama logları, nonce defteri) + Redis 7 (kısa ömürlü nonce/state, atomik replay koruması).
- İstemciler: Android (
com.verifyblind.mobile) ve iOS (app.verifyblind.ios) mobil uygulamalar; partnerler için tarayıcı widget'ı (verifyblind.js) ve mobil/iOS SDK'ları.
4. Tehdit Modeli
VerifyBlind, "partner dürüsttür ve altyapı güvenlidir" varsayımını reddeder. Korunan başlıca saldırgan profilleri:
| # | Saldırgan | Hedef | Savunma |
|---|---|---|---|
| T1 | Kötü niyetli/meraklı partner | Kullanıcının TCKN'sini öğrenmek | Veri minimizasyonu; TCKN partnere hiç gitmez (§2, §12) |
| T2 | Ağ dinleyici / MITM | Transit veriyi okumak | TLS + uçtan uca hibrit şifreleme (§5) |
| T3 | Relay/parent EC2 shell’ini ele geçiren saldırgan | Düz metin kimliği hasat etmek / sahte ticket üretmek | Nitro izolasyonu + attestation; enclave-içi HMAC; attestation-bağlı KMS güveni (§6, §8, §10) |
| T4 | Sahte/klon kimlik kartı | Geçersiz kimlikle doğrulama geçmek | Pasif Doğrulama (CSCA+CRL+DG hash) + zorunlu Aktif Kimlik Doğrulama (§7) |
| T5 | Sunum saldırısı (foto/maske/ekran) | Canlılık kontrolünü atlamak | Pasif anti-spoof + biyometrik eşleşme (§7) |
| T6 | Sızdırılmış/çalınan ticket sahibi | Başkasının ticket'ıyla doğrulama geçmek | Holder-of-key imzası (§8) |
| T7 | Replay saldırganı | Geçerli bir isteği tekrar oynatmak | Tek-kullanımlık nonce + atomik Redis Lua + nonce defteri (§8) |
| T8 | Sahte/değiştirilmiş istemci uygulama | Emüle edilmiş cihazdan sahte akış | Play Integrity / App Attest (§9) |
| T9 | Tedarik zinciri / kötü enclave sürümü | Arka kapılı bir enclave'i çalıştırmak | PCR0 sürüm doğrulaması + sürüm-bazlı iptal (§6) |
5. Kriptografik Tasarım
5.1 Hibrit şifreleme (cihaz → enclave)
Mobil uygulama, hassas kayıt yükünü (NFC veri grupları, selfie, vb.) cihazda şifreler:
- İçerik: AES-256-GCM (gizlilik + bütünlük/AEAD).
- Anahtar sarma: Bir defalık AES anahtarı, enclave'in genel anahtarıyla RSA-OAEP-SHA256 (MGF1-SHA256) kullanılarak sarılır.
- Çözme yalnızca enclave içinde gerçekleşir; relay sarılı anahtarı açamaz.
5.2 İmzalama
İmzalar RSA-PSS (SHA-256, MGF1-SHA256, salt uzunluğu 32 bayt) ile üretilir. Bu, holder-of-key kanıtı (§8) ve ilgili imza yollarında kullanılır.
5.3 Partner sonuç kanalı (tarayıcı widget'ı)
Tarayıcıdaki verifyblind.js, Web Crypto API ile bir defalık (ephemeral) RSA-OAEP anahtar çifti üretir. Genel anahtarı partner backend'i üzerinden VerifyBlind'e iletilir; sonuç bu efemer genel anahtarla şifreli döner ve yalnızca o tarayıcı oturumundaki özel anahtarla açılır. Partnerin API anahtarı tarayıcıya hiç inmez (sunucu tarafındaki "nonce" ucunda kalır).
6. Donanımsal Güven Kökü: AWS Nitro Enclave + PCR0
6.1 İzolasyon
Enclave, ana makineden (parent EC2) ayrı, donanımsal olarak izole bir bellek bölgesinde çalışır. Parent makinenin işletim sistemi (ve onu ele geçiren bir saldırgan) enclave RAM'ini okuyamaz. Enclave dış dünyaya yalnızca dar bir vsock kanalından konuşur.
6.2 Attestation ve PCR0 sürüm doğrulaması
Nitro Güvenlik Modülü (NSM), çalışan enclave imajının ölçümlerini içeren bir attestation belgesi üretir. Bu belge AWS Nitro donanımı tarafından imzalanır ve sertifika zinciri AWS'nin kök otoritesine dayanır — yani belgenin gerçekten bir Nitro enclave'den geldiği kriptografik olarak doğrulanabilir. VerifyBlind, belgedeki PCR0 (enclave imaj ölçümü) değerini, izin verilen sürümlerin imzalı bir listesine karşı doğrular:
- Yalnızca bilinen ve onaylanmış enclave sürümleri kabul edilir (kayan pencere: mevcut + önceki).
- Bir enclave sürümü, PCR0'ı listeden düşürülerek sürüm bazında iptal edilebilir (T9).
7. Kimlik Kanıtı: NFC + Biyometri + Canlılık
7.1 NFC Pasif Doğrulama (Passive Authentication)
Kimlik kartının veri grupları (DG'ler) ve imzalı güvenlik nesnesi (SOD), enclave içinde doğrulanır:
- CSCA + CRL doğrulaması: Kartı imzalayan ülke sertifika otoritesi zinciri doğrulanır; iptal listeleri (CRL) kontrol edilir. İlgili kök sertifikalar ve iptal listeleri enclave'e gömülüdür.
- DG hash bağı (DG1 + DG2 + DG15): Okunan veri gruplarının hash'leri SOD'daki imzalı
LDSSecurityObject'e karşı doğrulanır. DG2 (yüz) zorunludur ve SOD'a karşı slot-bazlı bağlanır — yani doğrulanan yüz, kartın imzalı içeriğinin ayrılmaz parçasıdır.
7.2 NFC Aktif Kimlik Doğrulama (Active Authentication)
Kart, içindeki özel anahtarıyla bir challenge'ı imzalar; bu, çipin klonlanmamış, gerçek fiziksel kart olduğunu kanıtlar. VerifyBlind'de bu kontrol zorunludur: DG15 veya aktif imza eksikse/yanlışsa doğrulama reddedilir.
7.3 Biyometrik eşleşme
Kullanıcının canlı selfie'sinden çıkarılan yüz gömme vektörü (ArcFace tabanlı yüz gömme modeli), karttaki DG2 yüzüyle kosinüs benzerliği üzerinden karşılaştırılır. Gerçek güvenlik kapısı enclave içindedir (eşik enclave tarafında uygulanır); telefon tarafındaki eşik yalnızca kullanıcı deneyimi için bir ön-kontroldür ve saldırgan tarafından atlanabilse dahi güvenliği bozmaz.
7.4 Pasif canlılık (anti-spoof)
Selfie üzerinde, enclave içinde pasif bir sunum-saldırısı (anti-spoof) tespiti çalışır; canlılık olasılığı eşiğin altındaysa doğrulama reddedilir. Bu, foto/ekran/maske gibi sunum saldırılarına karşı enclave tarafında uygulanan güvenlik kapısıdır.
7.5 Aktif canlılık (hareket-tabanlı challenge)
Kayıt sırasında mobil uygulama kullanıcıdan rastgele hareketler ister (sağa/sola dönme, göz kırpma, gülümseme). Bu, cihaz tarafında çalışan ve statik foto/ekran tekrarını caydıran tamamlayıcı bir canlılık katmanıdır; nihai güvenlik kararı §7.3–§7.4'teki enclave kontrollerine dayanır.
8. Oturum / Ticket Güvenliği
Başarılı kayıt sonrası enclave, kullanıcı cihazında saklanan imzalı bir Ticket üretir. Sonraki doğrulamalar (login) bu ticket'a dayanır. Üç bağımsız mekanizma ticket'ı bir "hamiline yazılı jeton" olmaktan çıkarır:
8.1 Ticket-MAC (enclave-içi HMAC) — sahte ticket üretimine karşı
Ticket'ın bütünlüğü, yalnızca enclave içinde tutulan simetrik bir HMAC anahtarıyla doğrulanır. Bu anahtar bir KMS sarma-anahtarı (CMK) ile şifrelenir ve sarılı haliyle saklanır; her enclave açılışında attestation'a bağlı bir KMS şifre-çözme işlemiyle açılır — yani anahtarı yalnızca doğru PCR0 ölçümüne sahip enclave çözebilir. Böylece ticket bütünlüğünü doğrulayan sır enclave dışına hiç çıkmaz.
8.2 Holder-of-key — çalınan ticket'a karşı
Ticket içinde, sahibinin genel anahtarı MAC kapsamında taşınır. Login sırasında cihaz, login'e özgü kanonik bir mesajı (nonce + anahtar parmak izi + zaman damgası) bu anahtarın donanım-destekli özel eşiyle RSA-PSS/SHA-256 ile imzalar; enclave, MAC ile doğrulanmış genel anahtara karşı bu imzayı ve dar bir zaman penceresini doğrular. Sonuç: sızdırılmış bir ticket, ona ait özel anahtara sahip olmayan hiç kimse tarafından kullanılamaz (T6).
8.3 Nonce / replay koruması
Her akış tek-kullanımlık bir nonce'a bağlıdır. Nonce'un harcanması atomik bir işlemle yapılır; böylece iki isteğin aynı nonce'u yarıştırması (TOCTOU) engellenir. Kalıcı denetim için ayrı bir nonce defteri tutulur (T7).
9. İstemci Bütünlüğü: Play Integrity / App Attest
Kayıt akışı, isteğin gerçek, kurcalanmamış VerifyBlind mobil uygulamasından geldiğine dair bir platform attestation'ı taşır:
- Android: Google Play Integrity API ile uygulama ve cihaz bütünlüğü doğrulanır.
- iOS: Apple App Attest (challenge → enroll → assertion; CBOR + X.509 zinciri Apple Root CA'ya doğrulanır, ECDSA assertion ve katı-artan sayaç ile tekrar saldırısına direnç).
- Yönlendirme platforma göre yapılır (iOS → Apple App Attest, diğer → Play Integrity).
10. Parent İzolasyonu ve KMS Anahtar Güveni
Nitro, enclave RAM'ini parent'tan izole eder; ancak enclave, AWS kimlik bilgisini parent'ın IMDS vsock-proxy'sinden alır → IAM düzeyinde enclave ile parent ayırt edilemez. Tek ayırt edici attestation'dır. KMS kullanımı, parent ele geçirilse dahi güvenliği koruyacak şekilde tasarlanmıştır:
- KMS bağlantısı: Enclave↔KMS bağlantısında TLS sertifika zinciri ve hostname eşleşmesi katı biçimde doğrulanır. Parent ele geçirilip ağ trafiği saldırgana yönlendirilse bile, sahte bir uç geçerli bir KMS sertifikası sunamayacağı için işlenen hassas veri sızdırılamaz.
- Ticket bütünlüğü: Ticket, enclave-içi simetrik bir HMAC ile imzalanır ve doğrulanır (imzalayan = doğrulayan = enclave). Sarma anahtarı yalnızca attestation'a bağlı bir şifre-çözme işlemiyle açılır; üretim ortamındaki rol yalnızca asgari, ilgili anahtara kısıtlı yetkilere sahiptir — ticket imzalama, anahtar oluşturma veya anahtar politikası değiştirme yetkisi bulunmaz. Kullanıcı kimliklerinin takma-kimlik anahtarı KMS içinde kalır → partner veritabanını ele geçiren saldırgan dahi
user_id'den TCKN'yi geri çözemez.
11. Operasyonel Güvenlik
- Denetim kaydı: Her doğrulama işlemi, kimliği açığa çıkarmadan denetim kaydına ve olay akışına yazılır.
- İzleme ve olay müdahalesi: Altyapı ve yönetim olayları merkezî olarak loglanır ve anormallikler için uyarı üretir. Bir güvenlik olayında erişimi kesmek, sırları döndürmek ve değiştirilemez kanıt toplamak için hazır bir müdahale süreci bulunur.
- Yedekleme / kurtarma: Veritabanı yedekleri şifreli ve sürüm korumalı saklanır; geri-yükleme düzenli olarak tatbik edilir.
12. KVKK / Veri Minimizasyonu
- Hiç bir kimlik verisi partnere gitmez ve VerifyBlind tarafından saklanmaz.
- Partner yalnızca sorduğu önermenin sonucunu ve istenirse takma kimlik kodları alır:
user_id— TCKN tabanlı takma kod (kişinin tekrar gelişini saklamadan tanımak için);nsbd_id— biyografik kişi kovası (kart yenilemede dahi sabit);doc_id— belge bazlı sabit kod.
- KVKK altyapısı: açık rıza kayıtları, veri sahibi başvuruları (erişim/silme/taşıma/itiraz/düzeltme), ihlal kaydı, tablo-bazlı saklama (retention) kuralları, çalıntı/engelli kart listesi.
- Sonuç: En hassas kişisel veri (TCKN, kimlik fotoğrafı) partnere hiç iletilmediği ve hiçbir yerde kalıcı saklanmadığı için, partnerin KVKK kapsamındaki veri işleme yükü ve risk yüzeyi belirgin biçimde azalır. (Nihai uyum, partnerin işleme amacına bağlıdır; bu belge hukuki danışmanlık değildir.)
13. Doğrulanabilirlik (Verifiability)
VerifyBlind'in temel duruşu "bize güvenin" değil, "matematiği doğrulayın"dır: sistemin hangi kodu çalıştırdığı bağımsız olarak sınanabilir.
- Enclave — yeniden üretilebilir build + attestation (çekirdek garanti): Enclave kaynak kodu açıktır (
github.com/VerifyBlind/VerifyBlind-Enclave). Bu kaynaktan derlenen enclave imajı deterministik birPCR0parmak izi üretir — koddaki tek bir karakter bile değişse PCR0 tümüyle değişir. Bağımsız bir denetçi şunu yapabilir: (1) kaynağı klonlayıp derler ve çıkan PCR0'ı not eder; (2) çalışan sistemden, AWS Nitro donanımıyla imzalı canlı attestation belgesini alır (§6); (3) iki PCR0'ı karşılaştırır. Eşleşiyorsa, üretimde çalışan enclave birebir o yayımlanmış koddur. Böylece "VerifyBlind ham veriyi göremez/saklamaz" iddiası bir söze değil, herkesin tekrarlayabileceği bir ölçüme dayanır. Ek olarak, enclave her oturumda ürettiği taze anahtarı attestation belgesinin içine "mühürlettirir" → eski/başka bir enclave'e ait bir belge tekrar oynatılamaz. - Android — yeniden üretilebilir build: Yayınlanan APK'nın açık kaynak commit'inden (
github.com/VerifyBlind/VerifyBlind-Android) bit-bit yeniden üretilebildiği gösterilir; cihazdaki ikili beklenen hash'le karşılaştırılır (kamuya açık doğrulama scriptleri). Ayrıca Play "code transparency" (bundletool check-transparency) ile de sınanabilir. - iOS — build provenance: App Store dağıtımındaki FairPlay şifrelemesi, ikilinin cihazdan bit-bit yeniden üretilerek doğrulanmasını engeller. Bunun yerine, App Store'dan indirilen sürümün yayın kaynağına (
github.com/VerifyBlind/VerifyBlind-iOS) bağı, Mac üzerinde çalışan, kamuya açık bir doğrulama scriptiyle (uygulamayı ipatool ile indirip Sigstore/cosign attestation'ını kontrol eden) sınanabilir.
Bu mekanizmalar, son kullanıcı için sade dille şeffaflık ve zero-knowledge sayfalarında adım adım anlatılır.
14. Sözlük
- TCKN
- T.C. Kimlik Numarası.
- Enclave / Nitro Enclave
- Ana makineden donanımsal izole, doğrulanabilir hesaplama ortamı.
- Attestation
- Çalışan kodun ölçümlerini içeren, donanımca imzalanmış belge.
- PCR0
- Enclave imaj ölçümü; "hangi kod çalışıyor" sorusunun kriptografik cevabı.
- NFC Pasif Doğrulama
- Kart verilerinin ülke CA imzasına karşı doğrulanması.
- NFC Aktif Kimlik Doğrulama
- Çipin özel anahtarıyla challenge imzalayarak klon olmadığını kanıtlaması.
- Holder-of-key
- Ticket'ı sunanın, ticket'a bağlı özel anahtara da sahip olduğunu imzayla kanıtlaması.
- Ticket-MAC
- Ticket bütünlüğünü, yalnızca enclave'in bildiği simetrik HMAC ile doğrulama.
- Nonce
- Tek kullanımlık, replay'i önleyen rastgele değer.
Bu belge bir taslaktır ve ürün geliştikçe güncellenecektir.