Telefon tabanlı dijital sürücü belgesini (mDL) entegre etmenin zorluğu, kimlik doğrulamak için bir API çağırmakta değil, bu arayüzün arkasında neler olduğunu anlamaktadır: kimlik bilgileri nerede saklanır, cihaz anahtarlarını kim korur, güven sertifikaları nasıl yönetilir ve ağ kesildiğinde veya hizmet sağlayıcı devre dışı kaldığında ne çalışmaya devam eder? InfoQ’ta yayımlanan makale, ISO/IEC 18013-5 standardına göre oluşturulan mDL sistemleri için, bir sağlayıcı, SDK, cüzdan platformu veya doğrulama hizmeti seçen kurumlara yönelik bir mimari yaklaşım sunuyor.
Kimlik kanıtlaması ile kimlik bilgisinin düzenlenmesini birbirinden ayırmak
Önerilen çerçeve, kimlik yaşam döngüsündeki iki farklı aşamanın birbirinden ayrılmasıyla başlıyor. Kimlik kanıtlama aşamasında kullanıcı fiziksel sürücü belgesinin fotoğraflarını ve canlılık doğrulaması için bir video çeker; ardından kanıtlar ve çıkarılan veriler doğrulama sistemine gönderilir. Motorlu taşıtlar idaresi gibi yetkili kurum, kabul veya ret kararı vermeden önce bu kanıtları otomatik ya da manuel olarak inceler.
Onayın ardından tedarik aşaması başlar. Cihaz, Secure Enclave veya güvenli bir unsur içinde asimetrik anahtarlar oluşturur ve açık anahtarı, tasdik sertifikalarını ve kanıtlama işleminin referansını düzenleyici kuruma gönderir. Kurum, sürücü belgesi verilerini imzalı bir Mobile Security Object içinde anahtarla ilişkilendirir; ardından kimlik bilgisi paketini şifreleyerek donanım destekli bir alanda saklanması için cüzdana gönderir.
Kurumun bu adımları kendisinin uygulaması şart değildir; ancak her adımdan hangi tarafın sorumlu olduğunu ve bunun sonucunda oluşan güven kararına kimin sahip olduğunu belirlemesi gerekir.
Sağlayıcının arayüzünün arkasında neler incelenmeli?
Makale, verifyCredential() veya requestPresentation() gibi işlevleri çağıran bir pilot uygulamanın başarılı olmasının sağlayıcıyı değerlendirmek için yeterli olmadığını belirtiyor. İnceleme, birbiriyle bağlantılı altı alanı kapsamalıdır:
- Kriptografik mimari: Anahtarların oluşturulması ve korunması, cihaz tasdiki, algoritmalar ve anahtar yaşam döngüsü.
- Güven ve açık anahtar altyapısı: Güven kökleri, Document Signer sertifikaları, güven ve iptal listeleri.
- Gizlilik ve veri minimizasyonu: Seçmeli açıklama, telemetri, sunum verilerinin saklanması ve işlemler arasındaki ilişkilendirme riskleri.
- Çevrimdışı çalışma: Önbelleğe alınan materyaller, eski iptal durumu ve ağ kesintisi sırasında sistem davranışı.
- Birlikte çalışabilirlik: ISO/IEC 18013-5’e uyum ve bağımsız cüzdanlar ile doğrulayıcılarla etkileşim kurabilme.
- Operasyonel dayanıklılık: Sağlayıcının devre dışı kalmasının etkisi, kimlik bilgisinin sürekliliği, kurtarma mekanizmaları ve hataların ele alınması.
Kriptografi ve sertifikalar uygulama ayrıntıları değildir
Makale, internet üzerinden gerçekleştirilen aktarım işlemlerini ve API alışverişlerini korumak için RFC 9180 uyarınca Hybrid Public Key Encryption kullanılmasını; DHKEM(P-256, HKDF-SHA256), HKDF-SHA256 ve AES-128-GCM dâhil parametrelerin belirlenmesini öneriyor. Ancak ortaya konan çerçeveye göre kriptografi, güven modelinden ayrı bir özellik olarak ele alınmamalıdır. Şifrelemenin nerede başlayıp nerede sona erdiği, anahtarları kimin oluşturup koruduğu, anahtarların nasıl döndürüldüğü ve hangi bileşenlerin sağlayıcının güven sınırları içinde yer aldığı bilinmelidir.
Cüzdan sunucuları, düzenleme platformları ve doğrulama sistemleri arasındaki iletişimler de açık bir sertifika altyapısı üzerinden karşılıklı TLS kimlik doğrulaması gerektirir. Makale, çevrimdışı bir donanım güvenlik modülünde saklanan güven kökünden kısa ömürlü Document Signer sertifikalarına, mTLS sertifikalarına ve cihaz anahtarı tasdik sertifikalarına kadar farklı sertifika rollerini ele alıyor. Kritik konu ise sorumlulukların dağılımıdır: Hangi altyapıyı sağlayıcı yönetir, hangisi kurumun kontrolündedir ve hangi güven ilişkileri düzenleyici kurumun elinde kalır?
Hizmet kesildiğinde pratikte ne değişir?
Tasarım, doğrulama sırasında gerçekleşen NFC üzerinden veri alışverişi veya doğrudan API üzerinden doğrulama gibi eşzamanlı işlemler ile kimlik kanıtlamasının incelenmesi, kimlik bilgisinin tedarik edilmesi, anahtarların döndürülmesi ve güven listelerinin senkronize edilmesi gibi arka planda gerçekleştirilebilen eşzamansız işlemleri birbirinden ayırır.
Bu ayrım, politikalar izin verdiğinde mevcut bir kimlik bilgisinin çevrimdışı olarak sunulmasına ve doğrulanmasına devam edilmesini, güven listelerinin veya iptal güncellemelerinin senkronizasyonunun ise ertelenebilmesini sağlar. Makale; ağ olmadan sunum ve doğrulama, süresi dolmuş kimlik bilgileri, eski iptal listeleri, cihaz saatindeki sapma, bağlantının yeniden kurulması ve sağlayıcının devre dışı kalması sırasında sistem davranışının test edilmesini öneriyor. Yüksek erişilebilirliğe sahip bir sağlayıcıya bağımlılık, her doğrulamanın arka uç hizmetlerine bağlantı gerektirmesi durumunda yine de tek bir arıza noktası oluşturabilir.
Seçmeli açıklama ve sağlayıcıya bağımlılığın önlenmesi
Gerekli veriler duruma göre değişir. Bir havalimanındaki kontrol noktası ad, fotoğraf, doğum tarihi, belge numarası ve düzenleyen makamı gerektirebilirken bir mağaza, ad, adres veya belge numarası olmadan, kullanıcının yaşının 21’i aştığını kanıtlayan mantıksal bir ifade ile fotoğrafla yetinebilir. Bu nedenle sağlayıcıyı tek bir senaryo üzerinden test etmek yeterli değildir; sağlayıcı kurumun politikalarına ve gerçek işlem kategorilerine göre ölçülmelidir.
Makale, iş mantığının sağlayıcının altyapısından bağımsız tutulmasını öneriyor. Böylece uygulamalar, sistemin her yerine sağlayıcıya özgü veri yapılarını yaymak yerine 21 yaşın aşıldığının kanıtlanmasını isteme gibi politikaları ifade edebilir. CBOR dizilimi, APDU mesajlarının oluşturulması ve kriptografi kitaplıklarının çağrılması gibi ayrıntılar gizlenebilir; ancak güven kökleri, düzenleyen kurumun kimliği, açıklanan öznitelikler, sertifika ve iptal durumu, sağlayıcıya bağımlılık ve çevrimdışı çalışma yetenekleri kurum tarafından görülebilir olmalıdır.
certi.news değerlendirmesi
Makalenin odaklandığı gerçek değişim, mDL değerlendirmesini bir SDK işlevinin test edilmesinden tam bir güven sisteminin incelenmesine taşımaktır. Bu yaklaşım güvenlik, kimlik ve satın alma ekipleri için yararlıdır; çünkü neyin satın alınabileceğini ve neyin kurumun yönetişimi altında kalması gerektiğini belirler: Cüzdan uygulaması, NFC protokolleri ve kriptografi kitaplıkları satın alınabilir; ancak açıklama, yetkilendirme ve denetim politikaları ile anahtar, sertifika, gizlilik, erişilebilirlik ve birlikte çalışabilirlik yönetimi oluşturulmalıdır.
Ancak çerçeve, yerel uyumluluk gereklilikleri veya düzenleyici kurumlar ile doğrulayıcılar arasındaki yönetişim modelleri gibi konuları tek başına çözmez. Ayrıca imzanın geçerli olduğunun güvence altına alınması, sistemler gereğinden fazla kayıt tutar veya sunum işlemlerini kullanıcılarla ilişkilendirirse gizliliği garanti etmez. Bu nedenle izlenebilirlik, gizliliği koruyan iptal mekanizmaları ve sağlayıcının başarısızlığı durumundaki sorumlulukla ilgili sorular, üretime geçmeden önce kurumsal ve düzenleyici kararlar gerektiren noktalar olmaya devam eder.