Ürünlere dön

PKCS Akıllı Kart Sistemleri

Fiziksel akıllı kartları sıradan kurumsal uygulamalardan kullanılabilir kılan PKCS#11 ara katmanı ve istemci platformu — donanım destekli kimlik doğrulama, dijital imza ve sertifika yönetimi.

MicroFrame tabanlı Kamu ve Güvenlik
PKCS#11 .NET PKI Akıllı Kart Dijital İmza

Sorun

Bir dijital işlemin yasal geçerliliği olması gerekiyorsa imza anahtarının donanımda kalması gerekir — donanım ise uygulama geliştiricilerinin durduğu yerdir. PKCS#11 okuyucuları, sürücüleri ve kart form faktörleri üreticiden üreticiye değişir; bunları bir iş uygulamasına, bir tarayıcı akışına ya da mevcut bir PKI'ya bağlamak, çoğu ürün ekibinin donanımlı olmadığı bir uzmanlık işidir.

Yaklaşımımız

Bu köprü, açık bir entegrasyon yüzeyine sahip bir ara katman olarak bir kez kuruldu. Uygulamalar imzalama, sertifika ve doğrulama işlemleri için sabit bir arayüzü çağırıyor; okuyucular ile kart üreticileri arasındaki farkları ara katman üstleniyor ve mevcut IAM ile PKI altyapısıyla konuşuyor. Böylece donanım destekli kimlik, bir uygulamanın uzmanlaşmak zorunda olduğu bir alan olmaktan çıkıp devralabileceği bir yetenek haline geliyor.

Platform ne yapıyor?

Platform, PKCS#11 standardı üzerine kurulu akıllı kart tabanlı kimlik doğrulama ve dijital imza yeteneği sunuyor; fiziksel akıllı kart donanımını yazılım katmanına bağlayarak yüksek güvenlik gerektiren kurumsal ve kamu uygulamalarına donanım destekli kimlik sağlıyor.

Dijital imzalama, sertifika yönetimi, şifreli iletişim ve güvenli belge doğrulama süreçlerini kapsıyor. Mimarisi, mevcut kurumsal uygulamalar ve IAM/PKI sistemleriyle entegrasyona bilinçli olarak açık bırakıldı; e-Devlet, fintech ve hukuki belge süreçlerindeki imza akışları için kuruldu. İmzanın hukuki geçerliliği yalnız ara katmana değil, kullanılan sertifikaya ve elektronik sertifika hizmet sağlayıcısına bağlıdır.

Yetenekler

  • PKCS#11 arayüzü: donanım tabanlı kriptografik işlemler
  • Dijital belge imzalama — yasal geçerliliği olan elektronik imzalar
  • Sertifika yönetimi — oluşturma, yenileme ve iptal iş akışları
  • Şifreli iletişim — taraflar arası güvenli veri alışverişi
  • Güvenli belge doğrulama — tahrifatı açığa çıkaran doğrulama
  • IAM/PKI entegrasyonu — mevcut kimlik altyapısıyla
  • Çoklu kart okuyucu desteği — farklı donanım üreticileri ve form faktörleri
  • e-Devlet ve fintech akışları için: imzanın düzenlemeye tabi olduğu senaryolar

Nasıl inşa edildi?

  • PKCS#11 donanımını uygulama katmanına bağlayan .NET tabanlı ara katman
  • Birden fazla akıllı kart okuyucu üreticisi ve form faktörü desteği
  • Sertifika zinciri doğrulaması ve OCSP/CRL kontrolü
  • Tarayıcı uzantısı desteğiyle çapraz platform masaüstü istemcisi

Ara katman neyi gizlemek için var

PKCS#11 bir standart ve bu, insanı tekdüzelik beklemeye itiyor. Üreticiler arasında fiilen değişen şey ise bir uygulamanın başa çıkmak zorunda kalacağı hemen her şey:

  • Modülün nerede olduğu ve adı. Kütüphane adı ve kurulum yolu üreticiye ve işletim sistemine göre değişiyor; dolayısıyla modül bulma işi bir sabit olamıyor.
  • Slot ve token anlamları. “Okuyucu bağlı”, “kart takılı” ve “token hazır” birbirinden farklı üç durum ve modüller bunları farklı biçimlerde bildiriyor. Üstelik kart, uygulamanın tek bir işlem saydığı iki çağrı arasında çıkarılabiliyor.
  • Kartın gerçekte hangi mekanizmaları desteklediği. Özetlemenin kartta mı ana makinede mi yapıldığı, hangi dolgu şemalarının desteklendiği, hangi anahtar boyu ve algoritmaların kabul edildiği yalnızca üreticiye göre değil kart bazında değişiyor. Tek bir mekanizmanın her yerde çalıştığını varsayan bir uygulama tek bir kartla çalışır.
  • PIN yönetimi. Bazı okuyucular PIN’i ana makineden alıyor, bazılarının kendi tuş takımı var ve PIN’i ana makine hiç görmeden doğrudan alıyor. Bunlar farklı akışlar ve aynı fonksiyon çağrısının altına süpürülemiyor.
  • Eşzamanlılık. Her modül thread-safe değil ve oturumlar giriş durumunu taşıyor; dolayısıyla bir token’a erişimin, uygulama bunu bilsin ya da bilmesin, sıraya sokulması gerekiyor.
  • Hata bildirimi. Asıl hasarın olduğu yer burası. Yanlış PIN, kilitli kart, çıkarılmış kart ve gerçekten başarısız olmuş bir işlem modüller arasında tutarlı biçimde ayırt edilemiyor; bunları tek sınıf sayıp yeniden deneyen bir uygulama PIN deneme sayacını tüketip kullanıcının kartını kilitliyor.

Ara katman bunların tamamını küçük ve açık bir sonuç kümesine indirgiyor ve PIN denemesi tüketebilecek her durumu, kararı çağırana bırakmak yerine politika gereği yeniden denenemez sayıyor. Kilitli kartlarla dolu bir destek kuyruğu ile olmayan bir kuyruk arasındaki fark tek başına bu kural.

Anahtar hiç çıkmıyor ve bu, API’nin biçimini belirliyor

Donanımda tutulan özel anahtar tasarımı gereği dışarı çıkarılamıyor; yani “anahtarı al, yerelde imzala” diye bir yol yok. Her imza, yazılımla yapılan kriptografiye göre yavaş olan ve işlem ortasında fiziksel olarak çıkarılabilen bir karta gidip gelmek demek. Bu yüzden API asenkron ve iptal edilebilir; kart, önceden hesaplanmış bir özeti imzalamayı destekliyorsa özetleme ana makinede yapılıyor ve okuyucu arayüzünden geçen şey belge değil özet oluyor. Uzun bir belge karta hiçbir zaman akıtılmıyor ve imza, bir arayüz thread’ini öngörülemeyen bir süre bloke eden bir fonksiyon olmaktan çıkıyor.

Belge imzalamak ile bayt imzalamak aynı şey değil

Hukuken anlamlı bir imza, ham bir dosyanın değil tanımlı bir yapının üzerine atılıyor: neyin, hangi sertifikayla imzalandığı ve bunlara eşlik eden imzalı öznitelikler. Ara katman bu yapıyı ana makinede kuruyor ve karttan yalnızca ortaya çıkan özet üzerindeki ham kriptografik işlemi istiyor. Formatın ana makine tarafında kalması, kartlar arasındaki farkların imzanın neyi kapsadığını değiştirememesi ve imza formatının donanım katmanına dokunmadan uyarlanabilmesi demek.

İptal kontrolü bir tazelik sorunu, bu yüzden iki mekanizma da kullanılıyor

Zincir doğrulaması işin kolay yarısı. Zor yarısı, iptal durumunun zamana bağlı olması ve kontrol etmenin iki yolunun zıt zaafları bulunması: OCSP taze cevap veriyor ama yavaşlayabilen ya da erişilemeyen bir yanıtlayıcıya canlı ağ bağımlılığı ekliyor; CRL ağ gerektirmiyor ama yalnızca yayım aralığı kadar güncel. İstemci ikisini birden kullanıyor — OCSP, düşerse CRL — çünkü tek başına her biri, diğerinin kapattığı bir yerden kırılıyor.

Doğrulama sonucu, dayandığı kanıtla birlikte kaydediliyor. Sonradan yeniden üretilemeyen bir doğrulama, doğrulama değildir; bunun asıl önemi fiilen karşılaşılan durumda ortaya çıkıyor: sertifika geçerliyken atılmış bir imzanın, o sertifikanın süresi dolduktan sonra da doğrulanabilmesi gerekiyor. Yani doğrulama şimdiki zamanda sorulmuyor, her zaman bir ana çıpalanıyor.

Tarayıcı akışı ve içindeki güven kararı

Sayfa içindeki betik bir PKCS#11 modülüyle konuşamıyor ve bunu ne kadar istediğinizin bir önemi yok. Dolayısıyla tarayıcı yolu şöyle kuruluyor: sayfa bir imza talep ediyor, uzantı talebi aktarıyor, modüle ve okuyucuya sahip olan yerel bir bileşen işi yapıyor. Bu dolaylılık, atlanması kolay bir kararı zorunlu kılıyor: yerel bileşenin, talebi yapan kaynağı doğrulaması ve kullanıcıya neyin imzalanmak üzere olduğunu göstermesi gerekiyor. İkisi birden olmazsa, tarayıcıda açık herhangi bir sayfa okuyucuda duran bir karta kullanıcının hiç görmediği bir şeyi imzalatabilir — kart aradaki farkı ayırt edemiyor, dolayısıyla ana makinenin ayırt etmesi gerekiyor.

Alttaki akıllı kart arayüzü ortak olsa bile okuyucu ve sürücü yığınları işletim sistemine göre değişiyor; bu yüzden modül yükleme ve cihaz erişimi tek bir iç arayüzün arkasına alınıyor ve masaüstü istemcisinin geri kalanı her platformda aynı kod. Kart tabanlı kimlik doğrulama da paralel bir giriş akışı olarak çalışmak yerine kimlik katmanına tamamlanmış bir kanıt olarak veriliyor; böylece kart oturumu ile parola oturumu aynı oturum modelinde ve aynı ömür kurallarıyla sonlanıyor.

Başlamaya hazır mısınız?

Projenize başlamaya hazır mısınız?

Fikirlerinizi hayata geçirmek için size nasıl yardımcı olabileceğimizi konuşalım.