1. Ana Sayfa
  2.  / 
  3. Blog
  4.  / 
  5. Ev Araması Olmayan Doğrulama: Geleceğin Dijital Uluslararası Sürücü Belgesinin Her Kullanımda İhraç Edene Neden Başvurmaması Gerekir
Ev Araması Olmayan Doğrulama: Geleceğin Dijital Uluslararası Sürücü Belgesinin Her Kullanımda İhraç Edene Neden Başvurmaması Gerekir

Ev Araması Olmayan Doğrulama: Geleceğin Dijital Uluslararası Sürücü Belgesinin Her Kullanımda İhraç Edene Neden Başvurmaması Gerekir

İptal, gelecekteki herhangi bir dijital Uluslararası Sürücü Belgesinin (USB) en zor sorunudur. Bu sorunu çözmenin en kolay yolu aynı zamanda en tehlikeli olanıdır: ihraç edeni her tek sunumda sürece dahil etmek. Modern bir sınır ötesi sürücü kimlik bilgisi bu kısayolu varsayılan olarak reddetmelidir.

Neredeyse her dijital kimlik önerisinde aynı güven verici cümle yer almaktadır:

“Kimlik bilgisi anında doğrulanabilir.”

Bu cümle bazen gerçek bir ilerlemeyi tanımlar. Bazen ise daha kullanıcı dostu bir arayüzle sunulan gözetimi.

Bugün yayımlanan standartlar, bir doğrulayıcının kimlik bilgisi her sunulduğunda ihraç edene başvurmasının gerekmediğini zaten açıkça ortaya koymaktadır:

  • NIST’in mevcut mDL mimarisi, bir doğrulayıcının ihraç edenin imzasına ve açık anahtarlarına güvenerek özgünlük ve bütünlüğü doğrulayabileceğini belirtir; ihraç edenle doğrudan iletişim kurmak gerekmez.
  • AAMVA, ISO/IEC 18013-5’in cihaz alımını zorunlu kıldığını ve yalnızca isteğe bağlı olarak sunucu alımına izin verdiğini doğrulamaktadır.
  • AAMVA ayrıca uyarıyor ki sunucu alımında ihraç eden kurum her kullanımda gerçek zamanlı olarak sürece dahil olur; bu da teknik olarak kimlik bilgisinin ne zaman kullanıldığını, hangi verilerin paylaşıldığını ve hatta IP analizi yoluyla konumu çıkarsamayı mümkün kılar.

Bu küçük bir dipnot değildir. Sınır ötesi sürücü kimlik bilgilerinin yeni nesli için merkezi tasarım sorusudur.

Tehlikeli Kısayol: Dört Soruyu Tek Bir Ağ Çağrısında Birleştirmek

Kötü mimariler birbirinden çok farklı dört soruyu ihraç edene yapılan tek bir canlı çağrıda bir araya getirir:

  1. Bu kimlik bilgisi özgün mü?
  2. Sunan kişi meşru sahibi mi?
  3. Kimlik belgesinin kendisi hâlâ geçerli mi?
  4. Temel alınan ulusal sürüş hakkı hâlâ yürürlükte mi?

Kötü tasarlanmış bir sistem bu dördünü de gerçek zamanlı ev araması yaparak yanıtlar. İyi tasarlanmış bir sistem bunları birbirinden ayırır; çünkü bunlar aynı sorun değildir ve aynı mekanizmayı paylaşmamalıdır.

Özgünlük Ağ Üzerinden Değil, Yerel Olarak Doğrulanmalıdır

Bir kimlik bilgisi, ihraç eden işlemi hiç gözlemlemeden kriptografik olarak özgün olabilir.

  • NIST’in mDL güven modeli, özgünlük ve bütünlüğün ihraç edenin imzası ve açık anahtarlarından doğrulandığını belirtir; canlı ihraç eden teması gerekmez.
  • AAMVA’nın Dijital Güven Hizmeti, işlem başına geri çağrı olmaksızın doğrulayıcılara geçerli ihraç eden açık anahtarlarına erişim sağlamak için tam da bu amaçla oluşturulmuştur.

Tasarım İlkesi 1: İmzaların zaten çözdüğü bir sorunu çözmek için canlı bağlantı kullanmayın.

Bir doğrulayıcı güvenilir ihraç eden anahtarlarına sahipse ve standartlara uygun bir sunum alıyorsa, özgünlük yerel bir kriptografik kontroldür; ağ bağımlılığı değildir.

Sahip Bağlaması Yerel Olarak Kanıtlanmalı, Küresel Olarak Raporlanmamalıdır

İkinci soru — bu meşru sahip mi? — aynı zamanda ağ dışı bir yanıta da sahiptir.

Mevcut EUDI mimarisi, PID’ler ve ISO/IEC 18013-5 onayları için cihaz bağlamasını zorunlu kılmaktadır. Doğrulayıcı, cüzdanın kimlik bilgisine gömülü açık anahtara karşılık gelen özel anahtarı kullanarak taze bir sorguyu imzalamasını ister:

  • ISO/IEC 18013-5’te buna mdoc kimlik doğrulaması denir.
  • SD-JWT VC’de ise buna anahtar bağlama denir.

Her iki durumda da sahiplik yerel ve kriptografik olarak kanıtlanır. Hiçbir kişisel verinin ihraç edene ulaşması gerekmez.

Tasarım İlkesi 2: Sahipliği yerel olarak kanıtlayın. Kimliği küresel olarak kanıtlamayın.

Gelecekteki bir USB, ihraç eden taraflı herhangi bir mekanizmayı değerlendirmeden önce cihaz bağlamasını, yerel sahip kimlik doğrulamasını ve doğrulayıcı sorgu-yanıt mekanizmasını tüketmelidir.

Kimlik Bilgisi Durumu ve Sürüş Hakkı Durumu İki Farklı Şeydir

Pek çok dijital kimlik tasarımı bu ayrımı bulanıklaştırır ve işte tam bu noktada hata yaparlar.

W3C’nin Bit Dizisi Durum Listesi spesifikasyonu bu noktayı açıkça ortaya koymaktadır: doğrulanabilir bir kimlik bilgisine eklenen durum bilgisi doğrulanabilir kimlik belgesinin kendisine uygulanır; temel alınan gerçek dünya hakkına değil. Bir dijital kimlik belgesi imzalama mekanizması tehlikeye girdiği için iptal edilebilirken, temel alınan sürüş hakkı tamamen geçerliliğini koruyabilir.

Gelecekteki bir USB’nin bu nedenle iki ayrı durum katmanına ihtiyacı vardır:

  • Kimlik bilgisi durum katmanı — dijital kimlik belgesi veya sunum kanalının kendisi için.
  • Sürüş hakkı katmanı — sürmeye ilişkin temel ulusal hak için.

Bazen bu ikisi birlikte değişir. Çoğunlukla değişmez. Bunları birbirine karıştıran bir sistem aşırı tepki verir, gereğinden fazla veri açığa çıkarır ya da her ikisini de yapar.

Cüzdan Ele Geçirilmesi Durum Katmanından Yayılmalı — Doğrulayıcı Geri Çağrılarını Tetiklememeli

Gelecekteki bir USB’nin, bir cüzdan ele geçirildiğinde ne olacağına dair de net bir yanıta ihtiyacı vardır.

EUDI mimarisi bu yanıtı sunmaktadır:

  • Cüzdan sağlayıcısı, iptal bilgisi içeren Cüzdan Birimi Onayları yayımlar.
  • Cüzdan bütünlüğü zaman içinde yeniden doğrulanır; bir cüzdan artık güvenli değilse onayı iptal edilir.
  • PID sağlayıcıları, cüzdanın iptal edilip edilmediğini düzenli aralıklarla kontrol etmek zorundadır. İptal edilmişse PID’i de iptal ederler.
  • Bağımlı taraf, PID durumunu doğrulayarak cüzdan durumunu dolaylı olarak da doğrulamış olur.

Gelecekteki bir USB’nin benimsemesi gereken katmanlama budur. Her doğrulayıcının cüzdan sağlayıcısını bağımsız olarak kontrol etmesini beklemeyin. Cüzdan ele geçirilmesinin mevcut kimlik bilgisi durum hattı üzerinden yayılmasına izin verin ve doğrulayıcıların o tek gizlilik koruyan kanalı kullanmasını sağlayın.

Üç Uygulanabilir İptal Modeli (Geri Çağrı Gerekmez)

EUDI, sağlayıcıların üç iptal yönteminden birini kullanmasını zorunlu kılmaktadır:

  • Kısa ömürlü onaylar — 24 saat veya daha az geçerlidir, dolayısıyla iptal gereksiz hale gelir.
  • Onay Durum Listesi — doğrulayıcıların başvurabileceği yayımlanmış bir liste.
  • Onay İptal Listesi — iptal edilen kimlik bilgilerinin açık listesi.

24 saatten uzun geçerli onaylar için EUDI, aşağıdakileri içeren iptal bilgisinin gömülmesini zorunlu kılmaktadır:

  • Bağımlı tarafların durum listesini alabileceği bir URL.
  • Kimlik belgesini söz konusu listede konumlandıran bir tanımlayıcı.

Güvenilir iptal bilgisi mevcut değilse — örneğin bağımlı taraf çevrimdışıysa — EUDI, bağımlı tarafı kimlik bilgesini kabul etmeden ya da reddetmeden önce bir risk analizi yapmaya yönlendirmektedir.

Çıkarım: iptal tek bir mekanizma değildir ve kesinlikle zorunlu ihraç eden geri çağrılarını meşrulaştırmaz.

Varsayılan Olarak Kısa Ömürlü, Yalnızca Gerektiğinde Uzun Ömürlü

Tüm yığındaki en etkili gizlilik önlemlerinden biri aynı zamanda en basiti: sunulanı kısa ömürlü tutun.

  • EUDI, 24 saat veya daha az geçerli onayların iptal altyapısı gerektirmediğini belirtir; iptal önem kazanmadan önce süresi dolar.
  • W3C, doğrulanabilir sunumların genellikle kısa ömürlü olduğunu ve uzun vadeli depolama için tasarlanmadığını belirtmektedir.
  • NIST, günlük kullanım için yeniden kullanılabilir tanımlayıcıların tekrar tekrar iletilmemesi konusunda açıkça uyarmaktadır. Günlük kimlik doğrulama, kimlik bilgisi yüklü bir belgenin tekrar tekrar sunulmasına değil, bu amaçla oluşturulmuş teknolojilere — örneğin geçiş anahtarlarına — dayanmalıdır.
  • NIST ayrıca özellikle yerel kimlik doğrulamanın gizliliği koruması ve operasyonel açıdan daha verimli olması nedeniyle sunucu taraflı biyometrik eşleştirme yerine yerel cihaz kimlik doğrulamasını tercih etmiştir.

Tasarım İlkesi 3: Temel kimlik belgesi orta vadeli bir geçerlilik süresine sahip olabilir; ancak sunumun kendisi kısa ömürlü, doğrulayıcıya özgü ve yeniden kullanılamaz olmalıdır.

Durum Listeleri Doğru Varsayılan Mekanizmadır

Her şeyi kısa ömürlü kılamazsanız durum altyapısına ihtiyacınız vardır — ve durum listesi doğru varsayılandır.

W3C’nin Bit Dizisi Durum Listesi v1.0, askıya alma veya iptal gibi durum verilerini yayımlamak için gizliliği koruyan, alan açısından verimli ve yüksek performanslı bir mekanizma tanımlamaktadır. Temel özellikler şunlardır:

  • Her ihraç eden, yayımladığı kimlik bilgileri için bir liste yönetir.
  • Kimlik bilgilerinin büyük çoğunluğu iptal edilmediğinden format iyi sıkıştırılır.
  • Varsayılan liste boyutu 131.072 girdidir; W3C bu boyutun ortalama durumda yeterli grup gizliliği sağladığını belirtmektedir.
  • Daha güçlü grup gizliliğinin gerektiği durumlarda daha büyük listeler kullanılabilir.
Güveni bant dışında yenileyin, kişi başına değil

Bu soruyu şuradan:

“Bu kullanıcı hakkında şu an ihraç edene sorabilir miyim?”

şuraya taşır:

“Yerel olarak karar verebilmek için yeterince güncel, gizliliği koruyan bir durum listem var mı?”

Bu çok daha iyi bir sorudur; hem teknik hem de siyasi açıdan.

“Ev Araması Yok” Bir Slogan Değil, Bir İndirme Modelidir

EUDI’nin gizlilik kılavuzundaki en önemli kural felsefi değil, prosedüreldir.

Bağımlı taraflar, bir kimlik bilgisi her sunulduğunda durum listesini talep etmemelidir. Bunun yerine şunları yapmalıdırlar:

  • Listenin her yeni sürümünü bir kez indirin.
  • Bunu, herhangi bir kullanıcı sunumuyla ilgisiz bir zamanda ve konumdan yapın.
  • Listeyi bağımlı taraf kuruluşu içinde dahili olarak dağıtın.
  • Listeyi bağımlı tarafın kimliğini doğrulamadan anonim olarak alın.

Ev aramasız doğrulamanın operasyonel özü budur: durumu kullanıcı sunumlarından bağımsız olarak yenileyin — ne kişi başına, ne işlem başına.

Bu tek tasarım seçimi, ihraç edenin veya durum sağlayıcısının hangi doğrulayıcının hangi kimlik belgesini hangi anda kontrol ettiğini öğrenmesini engeller.

Grup Gizliliği: Çoğu Tasarımın Unuttuğu Gereksinim

Pek çok sistem sunumun kendi içindeki seçici açıklamayı övünçle duyururken durum sorgularının gizliliğini sessizce görmezden gelir. Bu ciddi bir eksikliktir.

EUDI’nin gizlilik gereksinimleri şunları belirtir:

  • Durum listelerindeki indeksler rastgele atanmalıdır; böylece indeksin kendisi hiçbir zaman bir izleme sinyaline dönüşmez.
  • Her liste, grup gizliliğini sağlamak için yeterince büyük sayıda kimlik bilgesini kapsamalıdır.
  • Bir liste gereğinden küçük olacaksa, sağlayıcılar gerçek kimlik bilgisi sayısını gizlemek için kullanılmayan girdi eklemelidir.

Gelecekteki bir USB, yalnızca seçici açıklama gerekçesiyle gizliliği koruduğunu iddia edemez. İptal mekanizması sunum olayını açığa çıkarıyorsa gizlilik tasarımı eksik demektir.

Çevrimdışı Çalışma Bir Kenar Durum Değil — Temel Bir Gereksinimdir

Mükemmel bağlantı varsayan herhangi bir seyahat sistemi kötü tasarlanmıştır.

  • AAMVA, cihaz alımının hem sahip cihazı hem de okuyucu için dış bağlantı olmaksızın çalıştığını doğrulamakta ve ISO/IEC 18013-5’in mDL’lerin cihaz alımını desteklemesini zorunlu kıldığını belirtmektedir.
  • EUDI, bağımlı tarafların çevrimdışı olabileceğini ve önbelleğe alınmış bir durum listesine sahip olmayabileceğini kabul etmekte; bu durumda karar vermeden önce bir risk analizi yapılmasını önermektedir.

Bu değiş tokuşu erkenden kabul edin:

Mükemmel çevrimdışı çalışmaya ve mükemmel gerçek zamanlı güncelliğe aynı anda sahip olamazsınız.

Her ikisini de uzlaşı olmaksızın vaat eden herhangi bir mimari ya belirsizdir ya da gözetimi sessizce yeniden devreye sokuyordur. Doğru yanıt, güncelliği evrensel bir ağ bağımlılığı değil, bir politika girdisi haline getirmektir.

Günlükler Gizliliğin Sessizce Çöktüğü Yerdir

Mükemmel bir durum mimarisi bile dikkatsiz günlük tutma nedeniyle çökebilir.

  • EUDI, bağımlı taraf örneklerinin benzersiz ögeleri ve zaman damgalarını artık ihtiyaç kalmadığında silmesini ve bunları iletmemesini zorunlu kılmaktadır.
  • AAMVA, paydaşların yasal olarak zorunlu olmadıkça mDL sahiplerini veya mDL kullanımını izlemesini yasaklamakta, ihraç eden otoritelerden statik veya uzun ömürlü meta veri paylaşımını en aza indirmelerini talep etmekte ve faaliyet günlüklerine erişimi yalnızca sahibiyle kısıtlamaktadır.
  • AAMVA ayrıca cihaz üzerindeki silme işleminin, kullanım geçmişini ortaya çıkarabilecek günlük bilgilerini ve meta verileri kaldırmasını — ve bu silmenin çevrimdışı olarak da mümkün olmasını — zorunlu kılmaktadır.

Bu protokol davranışıdır, idari bir düzenleme değil. Gelecekteki bir USB, açıkça aksi kanıtlanmadığı sürece uzun ömürlü tanımlayıcıları, zaman damgalarını ve günlükleri potansiyel izleme araçları olarak ele almalıdır.

Gelecekteki USB İçin Somut Bir Ev Aramasız Mimari

İlkeleri bir araya getirdiğimizde, sistemin gerçekte yapması gerekenler şunlardır:

  1. Cihaza bağlı bir temel kimlik bilgisi yayımlayın. Kimlik belgesini cüzdanın güvenli ortamında korunan anahtarlara bağlayın — EUDI kapsamında PID’ler ve ISO/IEC 18013-5 onayları için zorunludur.
  2. Yalnızca gerekli olanı talep edin ve taze bir sorgu ile birlikte yapın. Bir OpenID4VP işleminde, DCQL sorgusu cüzdanın hangi niteliklerin talep edildiğini sahibine göstermesini sağlar ve doğrulayıcı yeniden oynatmayı önlemek için bir sorgu yayımlar (NIST’in mevcut mDL mimarisine göre).
  3. Yeniden kullanılabilir bir tanımlayıcı değil, kısa ömürlü bir sunum oluşturun. Her sunum, doğrulayıcıya, talebe ve ana özgü olmalıdır.
  4. Özgünlüğü yerel olarak doğrulayın. İhraç eden imzalarını ve açık anahtarları çevrimdışı olarak doğrulayın; AAMVA’nın güven hizmeti tam da bunun için tasarlanmıştır.
  5. Durumu önbelleğe alınmış, ayrıca yenilenen listelerden kontrol edin. Kimlik belgeleri iptali atlamak için çok uzun ömürlüyse, kullanıcı sunumlarıyla ilgisiz bir takvimde yenilenen yerel önbelleğe alınmış durum listelerini kullanın.
  6. Güncellik mevcut olmadığında bir risk politikası uygulayın. Çevrimdışı kararları yapılandırılmamış bir tahmin oyunu olarak değil, açık doğrulayıcı politikası olarak ele alın.
  7. İzleme verilerini agresif biçimde silin. İşleme özgü unsurları ve zaman damgalarını artık ihtiyaç kalmadığında atın; hareket geçmişini yeniden oluşturabilecek günlükleri saklamayın.

Ciddi bir ev aramasız mimarinin görünümü budur — katmanlı, gizliliği koruyan, kriptografik olarak yerel ve çevrimdışı gerçekliği konusunda operasyonel açıdan dürüst.

Tasarım Gereği Yasaklanması Gereken Üç Model

Olgun bir gelecek USB ekosistemi bunları optimizasyon tercihleri olarak değil, mimari başarısızlıklar olarak ele almalıdır:

  • Her sunumda zorunlu ihraç eden geri çağrıları. AAMVA’nın kendi gizlilik kılavuzu bunun neden zararlı olduğunu açıklamaktadır.
  • Sürücü belgesini rutin bir giriş aracı olarak kullanmak. NIST, kimlik bilgisi yüklü belgelerin günlük kimlik doğrulama için tekrar tekrar sunulmaması gerektiği konusunda açıkça uyarmaktadır.
  • Sunum geçmişini yeniden oluşturabilecek tanımlayıcıları, zaman damgalarını ve günlükleri saklamak. Hem EUDI hem de AAMVA tam tersini zorunlu kılmaktadır.

Temel Argüman Tek Bir Cümlede

Anlık doğrulama, ihraç eden taraflı gözetim için izne dönüşmemelidir.

Gelecekteki bir USB şunları yapabilmelidir:

  • Özgünlüğü yerel olarak kanıtlamak.
  • Sahipliği yerel olarak kanıtlamak.
  • Güncelliği gizli biçimde kontrol etmek.
  • Çevrimdışı gerçekliğe tolerans göstermek.
  • Mükemmel bilgi mevcut olmadığında düzgün biçimde çalışmak.

Bunların hiçbiri sistemi daha zayıf kılmaz. Ölçekte kullanıma değer hale getirir.

Bir sürücü belgesinin kimin ne gösterdiğini, nerede ve ne zaman gösterdiğini kaydetme aracına dönüştüğü an, kâğıdın daha güvenli bir sürümü olmaktan çıkar. Gözlem altyapısına dönüşür.

Geleceğin USB’sinin tam olarak reddetmesi gereken şey budur.

Sıkça Sorulan Sorular

“Ev araması doğrulaması” nedir?
Bir doğrulayıcının kimlik belgesini onaylamak için ihraç edene gerçek zamanlı olarak başvurduğu her türlü tasarımdır. Özgünlük ve iptali aynı anda çözse de ihraç edenin her sunum olayını gözlemlemesine olanak tanır.

ISO/IEC 18013-5 çevrimiçi ihraç eden teması gerektiriyor mu?
Hayır. AAMVA, ISO/IEC 18013-5’in cihaz alımı desteğini zorunlu kıldığını ve yalnızca isteğe bağlı olarak sunucu alımına izin verdiğini doğrulamaktadır.

İhraç edene başvurmadan iptal nasıl çalışabilir?
Kısa ömürlü kimlik belgeleri, onay durum listeleri veya onay iptal listeleri aracılığıyla — ideal olarak bağımlı tarafın durum verilerini kullanıcı sunumlarından bağımsız olarak indirmesiyle.

Durum listeleri için “grup gizliliği” neden önemlidir?
Bir durum listesi çok küçükse veya indeksleri öngörülebilirse, bir durum sorgusu hangi kimlik belgesinin az önce sunulduğunu açığa çıkarabilir. Rastgele indeksler ve büyük listeler bunu engeller.

Çevrimdışı doğrulama gerçekten pratik midir?
Evet — ve AAMVA ile EUDI de dahil olmak üzere standart kuruluşları bunu açıkça zorunlu kılmaktadır. Değiş tokuş, mükemmel gerçek zamanlı güncelliğin mükemmel çevrimdışı çalışmayla bağdaşmamasıdır; bu nedenle güncellik katı bir bağımlılık değil, bir politika kararı haline gelmelidir.

Başvur
Lütfen aşağıdaki alana e-postanızı yazın ve "Abone Ol"a tıklayın
Abone olun ve Uluslararası Sürücü Belgesi'nin edinilmesi ve kullanımı hakkında ayrıntılı talimatlar ile yurt dışındaki sürücüler için öneriler alın.