Dijital Kimlik Demosunu Üretime Taşımak: Testler, Tehdit Modeli ve Standartlaşma Yol Haritası

Bir prototipin çalışması ile üretime hazır olması aynı şey değildir. Dijital kimlik alanında bu fark özellikle önemlidir; çünkü başarısızlık yalnızca teknik hata değil, kimlik hırsızlığına, yetkisiz veri paylaşımına veya vatandaşın hizmete erişememesine dönüşebilir.

Serinin son bölümünde yerel dijital kimlik laboratuvarını test sonuçları, tehdit modeli, mahremiyet etkisi ve standartlara geçiş açısından analiz ediyorum. Amaç bir “açık listesi” çıkarmak değil; prototipin hangi varsayımlarla çalıştığını ve üretim sistemine dönüşmek için hangi mühendislik katmanlarının eklenmesi gerektiğini netleştirmektir.

Test stratejisi: Ekran değil, davranış doğrulamak

Arayüzde yeşil bir onay işareti görmek yeterli değildir. Güncel sürümde Node.js test koşucusuyla 22 test çalıştırıldı; yerelde ve gerçek SoftHSM’ye bağlı izole Docker ortamında tamamı geçti. Aşağıdaki tablo temel test alanlarını, sonraki bölüm ise eklenen kurum ve şablon kontrollerini özetliyor.

• İmzalı yaş kanıtı — Sunum imzalı, minimum alanlı, kuruma ve nonce’a bağlıdır; ikinci kez kullanılamaz.
• 18 yaş altı senaryosu — Koşul sonucu doğru üretilir; farklı kurumlar farklı pairwise kimlik alır.
• Belge yaşam döngüsü — İptal edilmiş belge sunulamaz; yeniden yayınlama sonrası kullanılabilir.
• Kurum politikası — Tanımsız kurum ve izin verilmeyen senaryo reddedilir.
• Süre sonu — Süresi geçen talep sunulamaz ve expired durumuna geçer.
• Mobil akış — İşlem kodu ve bağlantı aynı talebe çözülür; kapalı talep yeniden açılamaz.
• Alan minimizasyonu — Yalnızca seçilmiş ve yetkilendirilmiş adres/aile alanları kanıta girer.
• Cihaz imzası — İmza nonce, kişi ve seçilen alanlara bağlıdır; uyuşmazlık reddedilir.
• Hedefli bildirim — Yanlış kişi, yanlış QR ve başka talebe ait pairing token kabul edilmez.
• Cüzdan keşfi — Opak kod tek kullanımlıdır; kuruma ve tek talebe bağlı oturum üretir.
• TTL — Eşleştirme kodu ve bağlantı oturumu süre sonunda geçersiz olur.

Bu testler prototipte tanımlı davranışların tekrar üretilebilir olduğunu gösterir. Kriptografik tasarımın bağımsız uzmanlarca doğrulandığını, mobil uygulamanın saldırıya dayanıklı olduğunu veya mevzuata uygunluğu kanıtlamaz.

Mahremiyet analizi

Olumlu tasarım kararları

• Kurum portalında vatandaş listesi ve T.C. kimlik numarası araması bulunmuyor.
• Cüzdan keşfi opak, kısa ömürlü ve tek kullanımlık kodla yapılıyor.
• Verifier yalnızca senaryonun izin verdiği ve kullanıcının seçtiği alanları alıyor.
• Farklı kurumlara farklı pairwise tanımlayıcı üretiliyor.
• Kilit ekranı bildirimi hassas alan değerlerini göstermiyor.
• Kamera görüntüsü cihaz üzerinde işleniyor ve sunucuya yüklenmiyor.
• Reddedilen işlem de “hiçbir bilgi paylaşılmadı” şeklinde makbuzlanıyor.

Bilinçli prototip sınırı: çevrimiçi yayıncı modeli

Demo, cüzdandaki belgeyi sunarken yayıncı servise bağlanır. Yayıncı belgeyi doğrular, seçilen alanları alır ve verifier ile nonce’a bağlı yeni bir kanıt imzalar. Bu yaklaşım geliştirme ve anlatım açısından basittir; ancak yayıncı her kullanım işlemini görebilir.

Üretim tasarımında kullanım senaryosuna göre SD-JWT VC, ISO mdoc veya uygun başka bir seçici açıklama formatı değerlendirilebilir. Hedef, cüzdanın yayıncıyı her sunumda çevrimiçi hâle getirmeden, verifier’ın gerekli alanları ve holder binding’i doğrulayabilmesidir.

Güven sınırları

Web cüzdanı prototip akışını görünür kılıyor; üretimde roller ve güven alanları ayrı servislerde çalışmalıdır. İlk sürüm ekranı.

Güncel laboratuvarda imzalama ayrı SoftHSM servisindedir; issuer/verifier iş mantığı ve doğrulama merkezi API’de kalır. Kurumlar, hesap özetleri, alan yetkileri ve şablon sürümleri SQLite’ta kalıcıdır. Talepler, bağlantılar, cihaz kayıtları ve makbuzlar bellektedir. Kurum rolleri oturumla doğrulanır; cüzdan kişisi seçimi ise hâlâ sentetik demo mekanizmasıdır.

Bunlar gizli kusurlar değil, laboratuvarın açık varsayımlarıdır. Üretim mimarisinde en az şu güven alanları ayrılmalıdır:

1. Issuer: Yetkili kayıt kaynağı, credential yayınlama politikası ve HSM ile korunan imza anahtarları.
2. Wallet: Cihaza bağlı anahtar, kullanıcı oturumu, rıza ekranı, güvenli kurtarma ve cihaz kaybı süreci.
3. Verifier: Kurum kimliği, kayıtlı talep amaçları, talep edilen alan politikası ve doğrulama kayıtları.
4. Trust infrastructure: Güvenilir issuer/verifier kayıtları, sertifika zincirleri, durum ve iptal hizmetleri.
5. Audit: Değiştirilmeye dayanıklı fakat kişisel veriyi gereksiz saklamayan denetim kayıtları.

Anahtar yönetimi

Canlı demoda ihraççı anahtarı SoftHSM token’ında üretilir ve PKCS#11 üzerinden dışa aktarımı kapalıdır. Üretimde uygun donanımsal koruma, görev ayrımı, kontrollü rotasyon ve kurtarma gerekir. Eski imzaları doğrulamak için anahtar kimlikleri ile güvenilir açık anahtarların yaşam döngüsü ayrıca yönetilmelidir.

Cihaz tarafında gerçek iPhone için Secure Enclave P-256 anahtarı kullanılıyor. Ancak üretimde yalnızca anahtarın donanımda bulunması yetmez. Anahtarın hangi vatandaş cüzdanına hangi kayıt süreciyle bağlandığı, cihaz değişiminde nasıl iptal edildiği ve yeni cihaza hangi güven seviyesinde yeniden credential verildiği belirlenmelidir.

Kimlik doğrulama ve cüzdan kaydı

Prototipte person: "adult" gibi bir demo seçimi vardır. Bu seçim yalnızca sentetik akışı kolaylaştırır. Üretimde cüzdan kaydı; e-kimlik, NFC, PIN, yüz yüze kontrol veya mevzuatın kabul ettiği başka yüksek güvenli kanallarla yapılmalıdır.

İlk kayıt zayıfsa Secure Enclave yanlış kişiye ait cüzdanı çok güvenli biçimde korur. Bu nedenle onboarding, cihaz bağlama ve credential issuance tek bir güvence zinciri olarak tasarlanmalıdır.

Standartlara geçiş yol haritası

Prototip kendi küçük JSON ve API sözleşmelerini kullanıyor. Üretimde birlikte çalışabilirlik için özel protokolden standart profillere geçilmelidir.

1. Credential veri modeli ve formatı

W3C Verifiable Credentials Data Model 2.0, issuer-holder-verifier ekosistemini ve credential yapısını tanımlar. Bunun yanında kullanım bağlamına göre SD-JWT VC veya ISO mdoc gibi formatlar seçilebilir. Format kararı yalnızca veri yapısı değil; selective disclosure, holder binding, offline doğrulama ve mobil performans kararlarını da etkiler.

2. Credential issuance

OpenID for Verifiable Credential Issuance 1.0, credential yayınlama için OAuth korumalı bir API tanımlar ve Eylül 2025’te Final Specification olmuştur. Demo içindeki /api/credential işlevi, gerçek sistemde kimliği doğrulanmış ve yetkilendirilmiş OID4VCI akışına dönüştürülmelidir.

3. Credential presentation

OpenID for Verifiable Presentations 1.0, verifier’ın credential istemesi ve wallet’ın sunması için standart akışı tanımlar. Demodaki audience ve nonce bağları doğru güvenlik fikrini gösterir; üretimde request object, verifier kimliği, response mode, presentation formatı ve hata akışları standarda uygun uygulanmalıdır.

4. Güven kayıtları ve verifier politikası

Kurumların alan yetkileri ve talep gerekçeleri artık yalnızca sabit kod listesi değildir: demo, yönetici onaylı kayıtlar ve sürümlü şablonlar kullanır. Üretimde bunların gerçek kurum doğrulaması, imzalı güven listesi, credential şemaları ve sertifika durumlarıyla tamamlanması gerekir.

5. Durum ve iptal

Demoda revoked bayrağı bellektedir. Üretimde credential status mekanizması; güncellik, performans ve mahremiyet dengesini sağlamalıdır. Her durum sorgusunun yayıncıya “vatandaş şu anda şu kurumda” bilgisini vermesi engellenmelidir.

Operasyonel dayanıklılık

Üretim cüzdanı yalnızca normal akışta değil, hata ve kriz anında da güvenilir olmalıdır:

• Cihaz kaybolduğunda eski wallet unit nasıl askıya alınacak?
• Telefonu olmayan vatandaş hangi alternatif kanalı kullanacak?
• Issuer veya status servisi kesildiğinde düşük riskli çevrimdışı doğrulama yapılabilecek mi?
• Anahtar sızıntısı şüphesinde hangi credential’lar ve güven listeleri yenilenecek?
• Yanlış kuruma veri gönderildiğinde kullanıcı ve denetim birimleri nasıl bilgilendirilecek?
• Erişilebilirlik gereksinimleri ve vekâlet/temsil senaryoları nasıl ele alınacak?

Aile bilgisi neden ayrı analiz gerektiriyor?

Demo, hane özeti ve ayrıntılı aile üyeleri senaryolarını da içeriyor. Bu alanlar yalnızca cüzdan sahibini değil, üçüncü kişileri de ilgilendirir. Kullanıcının teknik olarak bir alanı seçebilmesi, o bilgiyi hukuken paylaşmaya yetkili olduğu anlamına gelmez.

Gerçek uygulamada velayet, vesayet, temsil yetkisi, işlem amacı ve veri sahibinin hakları ayrı politika katmanları gerektirir. Ayrıca sosyal yardım gibi yüksek etkili kararlarda cüzdan verisi otomatik ve itiraz edilemez karar mekanizmasına dönüştürülmemelidir.

Önerilen geliştirme aşamaları

1. Protokol profili: Kullanılacak VC/mdoc formatını, OpenID4VCI ve OpenID4VP profilini belirle.
2. Sentetik sandbox: Issuer, wallet ve verifier’ı ayrı servislerde çalıştır; test PKI ve güven kaydı kur.
3. Cihaz kaydı: Güçlü onboarding, attestation, Secure Enclave/StrongBox anahtarı ve yeniden kayıt süreçlerini ekle.
4. Yaşam döngüsü: Yayınlama, yenileme, askıya alma, iptal, anahtar rotasyonu ve kayıp cihaz senaryolarını uygula.
5. Mahremiyet değerlendirmesi: Bağlanabilirlik, telemetri, loglar, status sorguları ve üçüncü kişi verileri için DPIA yap.
6. Negatif testler: Replay, yanlış audience, yanlış nonce, QR değişimi, kötü niyetli verifier ve bozuk credential testlerini genişlet.
7. Bağımsız inceleme: Kriptografi, mobil güvenlik, backend, HSM politikaları ve erişilebilirlik için harici değerlendirme yap.
8. Sınırlı pilot: Fiziksel alternatifi koruyan, düşük riskli ve ölçülebilir bir kullanım senaryosuyla başla.

Son doğrulama: 22 test ve çalışan güvenlik sınırları

20 Ekim 2026 sürümünde node --test ile çalışan 22 testin tamamı yerelde ve gerçek SoftHSM’ye bağlı izole Docker ortamında geçti. Canlı HTTPS üzerinde ayrıca kurum girişleri, iki QR akışı, iPhone biçiminde P-256 cihaz imzası ve SoftHSM ES256 sonuç imzası denendi; sonuç imzası API’nin döndürdüğü bayraktan bağımsız olarak açık anahtarla doğrulandı.

• Kurum izolasyonu — Hastane eşleştirmesini, sonucunu veya kanıtını market hesabı kullanamaz.
• Onay zorunluluğu — Yeni kurum ve onaysız şablon bilgi talebi gönderemez; kurum kendi yetkisini onaylayamaz.
• Alan sınırı — Katalog dışı, kurum türü dışı veya verilmiş yetkiyi aşan alanlar reddedilir.
• Sürüm sabitleme — Yeni sürüm onaylansa da açık eski talebin alanları ve zorunlulukları değişmez.
• Kalıcılık — Kurum hesabı, alan yetkileri ve şablon geçmişi yeniden başlatma sonrası korunur.
• Parola saklama — Kurum parolası SQLite’a açık yazılmaz; tuzlanmış scrypt özeti tutulur.
• Signer kesintisi — İmzalama ve sağlık kontrolü başarısız olur; yazılım anahtarına fallback yapılmaz.

Token anahtarının restart sonrası aynı kalması ve özel anahtar okuma girişiminin reddedilmesi de kurulum doğrulamasında test edildi. Bunlar belirli bir sürümün davranış kanıtlarıdır; güvenlik sertifikası veya bağımsız penetrasyon testi değildir.

Ne kalıcı, ne hâlâ geçici?

• İhraççı özel anahtarı — SoftHSM token volume’ü; uygulama konteynerine mount edilmez.
• Kurumlar, hesap özetleri, yetkiler, şablon sürümleri — Kalıcı SQLite veritabanı
• Pairwise HMAC sırrı — API’nin eriştiği kalıcı dosya; henüz HSM içinde değil
• Talepler, oturumlar, cihaz kayıtları, makbuzlar — API belleği; restart sonrası sıfırlanır
• İmzalama olayları — Metadata günlüğü; WORM veya host yöneticisine karşı değiştirilemez değil

Üretime geçişte kalan işler

• SoftHSM yerine uygun donanımsal HSM; anahtar rotasyonu, çift kontrol, yedekleme ve felaket kurtarma tasarımı.
• Gerçek kişi ve tüzel kişi kaydı, kurumsal SSO/MFA, cihaz kaybı ve güvenli yeniden kayıt.
• Native iPhone akışında bulunan cihaz imzası kontrolünü üretim paylaşım API’sinin her uygun kanalında zorunlu kılmak. Mevcut web demo uyumluluğu nedeniyle cihaz imzası API’de evrensel olarak zorunlu değildir.
• Talep, cihaz, iptal ve denetim kayıtlarını kalıcılaştırmak; çoklu API örneği için veritabanı ve eşzamanlılık tasarımı.
• Standart credential/presentation profilleri, bağımsız verifier doğrulaması ve mahremiyet korumalı durum hizmeti.
• İmzalama yetkisini iş politikalarıyla daha sıkı sınırlamak; dışa aktarılamayan anahtar, yetkili servisin kötüye kullanımını tek başına engellemez.

TestFlight dağıtımı özel davet yaklaşımıyla hazırlanmıştır; uygulama açıkken yerel bildirim vardır, APNs üzerinden uygulama kapalıyken bildirim henüz yoktur. AI ile talep açıklama ve fazla alan tespiti ise konuşulan sonraki geliştirme fikridir; mevcut çalışan bir modül olarak sunulmamalıdır.

Sonuç

Bu demo, “dijital kimlik cüzdanı nasıl görünür?” sorusundan çok “hangi taraf neye güveniyor?” sorusuna cevap arıyor. İki QR ile cüzdan keşfi ve işlem bağlama ayrılıyor; kullanıcı alan bazında karar veriyor; cihaz seçimi imzalıyor; sunum verifier ve nonce’a bağlanıyor; kurumlar arasında ortak kimlik numarası yerine pairwise tanımlayıcı kullanılıyor.

Üretime giden yol ise özel demo API’lerini standart protokollerle değiştirmekten, güven alanlarını ayırmaktan, anahtarları HSM ve cihaz güvenliğine bağlamaktan, güçlü kayıt/kurtarma süreçlerinden ve bağımsız güvenlik değerlendirmesinden geçiyor.

Kaynaklar

• W3C — Verifiable Credentials Data Model v2.0
• OpenID Foundation — OpenID for Verifiable Credential Issuance 1.0
• OpenID Foundation — OpenID for Verifiable Presentations 1.0
• European Commission — EUDI Wallet Architecture and Reference Framework