Güvenlik Mimarisi Teknik Belgesi (Whitepaper)

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.

1. 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.
2. İ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.
3. 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.
4. 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).

  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) ile Android ve iOS SDK'ları.

VerifyBlind, "partner dürüsttür ve altyapı güvenlidir" varsayımını reddeder. Korunan başlıca saldırgan profilleri:

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.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ğerinin VerifyBlind geliştirici anahtarıyla imzalanmış olmasını şart koşar:

• Mobil uygulama, attestation belgesini ve PCR0 için sunulan geliştirici imzasını uygulamaya gömülü geliştirici genel anahtarıyla doğrular. İmzası olmayan bir enclave sürümüne kimlik verisi gönderilmez (T9).
• Relay, yayındaki enclave sürümünün ve bir önceki sürümün imzasını sunar.
• Partnerler de aynı kontrolü yapabilir: doğrulama sonucuyla birlikte attestation belgesi ve PCR0 imzası gelir; geliştirici genel anahtarı /api/public/developer-key adresinde yayınlanır.

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. Bu karşılaştırma kayıtta ve sonraki her doğrulamada yapılır (§8.4). 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 dizisi)

Kullanıcıdan telefonu tek ve rahat bir mesafede tutarak kısa hareketler yapması istenir. Hareketler göz kırpma, gülümseme, ağız açma ve çift göz kırpmadır. Hangi hareketlerin hangi sırayla isteneceği, işlemin nonce'undan türetilir; istemci diziyi seçemez.

• Kart eklemede: beş hareket; aynı hareket art arda gelmez.
• Her doğrulamada: tek hareket (gülümseme, ağız açma ya da çift göz kırpma).

Hareketi telefon algılar; her hareket için bir nötr kare ve bir hareket karesi enclave'e gönderilir. Enclave, kanıtın istenen diziyle uyuştuğunu ve her karedeki yüzün kart sahibine ait olduğunu doğrular. Böylece hareket yapamayan bir fotoğraf geçemez; hareketi başka birinin yüzüyle yapmak da kimlik kontrolüne takılır.

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. Dört 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 sahibinin anahtar çifti kayıt sırasında cihazda üretilir. Özel anahtar Android'de Android Keystore'da (destekleyen cihazlarda donanım korumalı alanda, TEE), iOS'ta ise Keychain'de yalnız o cihaza bağlı olarak tutulur. Yedeklere ve başka cihazlara aktarılmaz; yalnızca kullanıcı biyometri ya da ekran kilidiyle onay verdiğinde kullanılabilir.

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 özel anahtarla 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).

8.4 Her doğrulamada canlı yüz

Kayıtta, SOD ile doğrulanmış DG2'den çıkarılan yüz fotoğrafı ticket'a MAC kapsamında mühürlenir. Her doğrulamada enclave, telefondan gelen canlı kareyi bu referansla karşılaştırır, pasif anti-spoof kontrolünü çalıştırır ve tek hareketlik diziyi (§7.5) doğrular. Kontrollerden biri geçmezse doğrulama reddedilir. Amaç, telefonun kilidini açabilen başka birinin kart sahibi adına doğrulama yapmasını engellemektir.

Kayıt ve doğrulama akışları, 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üğü ile uygulamanın imza sertifikası 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).

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:

1. 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.
2. 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. Takma kimlik kodlarını (user_id, nsbd_id, doc_id) üreten HMAC sırrı da aynı biçimde KMS ile sarılı saklanır, yalnızca attestation'a bağlı şifre çözmeyle enclave içinde açılır ve kodlar enclave içinde hesaplanır → partner veritabanını ele geçiren saldırgan dahi user_id'den TCKN'yi geri çözemez.

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

• 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.
  Bu kodlar, partnere kimliği açığa çıkarmadan mükerrer hesap tespiti ve süreklilik sağlar. Üç kod da partnere özel (partner-scoped) türetilir: aynı kişi iki farklı partnerde birbirinden farklı kodlar alır. Böylece partnerler arası ilişkilendirme (cross-partner correlation) engellenir — bir partnerdeki kodlar başka bir partnerdeki aynı kişiyle eşleştirilemez.
• 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ı.
• 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.)

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 herkese açıktır (github.com/VerifyBlind/VerifyBlind-Enclave). Bu kaynaktan derlenen enclave imajı deterministik bir PCR0 parmak 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 açılışta ürettiği anahtarı attestation belgesinin içine "mühürlettirir" → eski/başka bir enclave'e ait bir belge tekrar oynatılamaz.
• Android — yeniden üretilebilir build: Her sürüm açık kaynak commit'inden (github.com/VerifyBlind/VerifyBlind-Android) GitHub Actions'da derlenir; aynı commit ikinci kez derlenerek kod (DEX) dosyalarının birebir aynı çıktığı ayrıca doğrulanır. Kamuya açık doğrulama betikleri, telefondaki uygulamanın DEX dosyalarını o sürümün yayımlanan hash listesiyle karşılaştırır. 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 her sürüm, herkese açık kaynak kodunun commit'inden (github.com/VerifyBlind/VerifyBlind-iOS) GitHub Actions'da derlenir ve Sigstore imzalı build provenance ile yayınlanır. Windows, macOS ve Linux için kamuya açık doğrulama betikleri, yayımlanan IPA'nın hash'ini sürüm manifestiyle karşılaştırır ve provenance kaydını cosign ile doğrular. Cihazdaki uygulamanın gerçek App Store build'i olduğunu ise sunucu, App Attest ile her korunan istekte sınar (§9).

Bu mekanizmalar, son kullanıcı için sade dille şeffaflık ve zero-knowledge sayfalarında adım adım anlatılır.

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.