SoftHSM ile Token ve Anahtar Oluşturma: XCA ve PKCS11 Araçlarıyla Entegrasyon
SoftHSM token’ında P-256 anahtarı üretme, izole ES256 imzalama servisi, sunucuda yönetim ve Mac XCA bağlantısının sınırları; çalışan dijital kimlik demosundan örneklerle.
SoftHSM token’ında P-256 anahtarı üretme, izole ES256 imzalama servisi, sunucuda yönetim ve Mac XCA bağlantısının sınırları; çalışan dijital kimlik demosundan örneklerle.
SoftHSM, PKCS#11 üzerinden kullanılan yazılımsal bir kriptografik depodur. Projemizde ihraççının imza anahtarını ana API’den ayırmak ve HSM benzeri anahtar kullanım politikasını test etmek için kullanılıyor. Belge ve paylaşım sonuçları, ayrı imzalama servisinin SoftHSM token’ında ürettiği P-256 anahtarıyla ES256 olarak imzalanıyor.
Bu, donanımsal HSM kurulduğu veya sertifikalı fiziksel anahtar koruması sağlandığı anlamına gelmez. Token dosyaları, PIN’ler, yedekler ve host erişimi hâlâ korunmalıdır. SoftHSM’nin resmî projesi, PKCS#11 arayüzü üzerinden yazılımsal kriptografik cihaz yaklaşımını açıklar.
Aşağıdaki örnek Linux/Debian ailesinde ayrı bir deneme deposu içindir. Canlı token yolunu kullanmayın. Paket yöneticisi ve modül yolu dağıtıma göre değişebilir.
sudo apt-get update
sudo apt-get install softhsm2 opensc
mkdir -p "$PWD/softhsm-lab/tokens"
cat > "$PWD/softhsm-lab/softhsm2.conf" <<EOF
directories.tokendir = $PWD/softhsm-lab/tokens
objectstore.backend = file
log.level = ERROR
EOF
export SOFTHSM2_CONF="$PWD/softhsm-lab/softhsm2.conf"
softhsm2-util --show-slots
softhsm2-util --init-token --free --label lab-issuerBaşlatma komutu PIN’leri etkileşimli ister. Bunları komut satırına --pin veya --so-pin değeri olarak yazmak süreç listesine ya da geçmişe sızdırabilir. Canlı token’ı yeniden başlatmak/sıfırlamak bir inceleme işlemi değildir ve mevcut anahtarları tehlikeye atabilir.
OpenSC’nin pkcs11-tool aracı yüklüyse aşağıdaki örnek kullanılabilir. Modül yolunu kendi kurulumunuza göre doğrulayın:
PKCS11_MODULE=/usr/lib/softhsm/libsofthsm2.so
pkcs11-tool --module "$PKCS11_MODULE" --list-slots
pkcs11-tool --module "$PKCS11_MODULE" \
--token-label lab-issuer --login \
--keypairgen --key-type EC:prime256v1 \
--id 01 --label issuer-lab-v1 \
--usage-sign --sensitive
pkcs11-tool --module "$PKCS11_MODULE" \
--token-label lab-issuer --login --list-objectsÖrnekte --extractable verilmez. Üretim benzeri uygulama entegrasyonunda özellikleri açıkça CKA_SENSITIVE=true, CKA_EXTRACTABLE=false ve CKA_SIGN=true olarak tanımlayıp doğrulamak gerekir. Bizim signer başlangıçta bu politikayı kontrol eder, özel anahtar değerini okuma girişiminin reddedildiğini sınar ve imzayı açık anahtarla doğrular. OpenSC’nin resmî araç örnekleri kurulum ve mekanizma ayrıntıları için başvuru kaynağıdır.
Cihaz imzası ve ihraççı imzası farklı anahtarlarla, farklı güven alanlarında üretilir.
Signer’a dış port açılmaz. Token volume’ü yalnızca imzalama servisine bağlıdır. Ana API token PIN’lerini veya özel anahtarı almaz. İmzalama servisi kapalıysa işlem durur; yerel geliştirme anahtarına otomatik dönüş yapılmaz. Bu özel JSON sözleşmesi, yalnızca ES256 kullanıldığı için standart JWS/VC formatı sayılmaz.
XCA sertifika ve anahtar yönetir; uygun PKCS#11 modülünün erişebildiği token’larla çalışabilir. Ancak SoftHSM kendi başına uzak ağ bağlantısı sunmaz. Mac’e SoftHSM kurup XCA’ya tanıtmak, sunucudakinden ayrı yerel bir token oluşturur. Linux için derlenmiş .so dosyası da macOS’ta doğrudan yüklenemez.
SSH tüneli tek başına bir PKCS#11 modülünü uzak servise dönüştürmez. Uyumlu uzak PKCS#11 katmanı veya sağlayıcının ağ HSM istemcisi ayrı bir mimari tercihidir. Bizim mevcut signer API’miz XCA’nın yükleyebileceği genel bir PKCS#11 sağlayıcısı değildir. XCA’nın anahtar belgeleri token yetenekleri ve sağlayıcı modülü ilişkisini açıklar.
Yetkili SSH oturumunda token ve slot’ları görüntülemek için mevcut konteynerde şu komut kullanılabilir:
docker exec kimlik-signer-1 softhsm2-util --show-slots
docker logs kimlik-signer-1 --tail 50pkcs11-tool ayrı OpenSC paketindedir; signer imajında kurulu olduğunu varsaymayın. İleri yönetim için aracı içeren kontrollü bir yönetim ortamı hazırlayın. Canlı token’ı sıfırlama, anahtar silme, PIN değiştirme veya anahtar rotasyonu; uygulama yapılandırması, yedekleme ve eski imzaların doğrulanmasıyla birlikte planlanmalıdır.
Kalıcı token seçimi ve yedekleme önemlidir; fakat dosyaları kopyalamak donanımsal HSM yedeğiyle aynı güvenceyi vermez. Donanımsal HSM’ye geçişte yeni anahtar üretimi, algoritma ve imza kodlama uyumu, erişim rolleri, rotasyon ve kurtarma doğrulanmalıdır. HSM özel anahtarın kullanımını korur; hangi kurumun hangi kişisel alanı istemeye yetkili olduğuna uygulamanın politika katmanı karar verir.
Üretim sistemlerinde güncel sürümleri ve kurumunuzun onaylı politikalarını esas alın.
Bu makaleyi nasıl değerlendirirsin?
Geri bildirimin sonraki içerikleri geliştirmeme yardımcı olur.
PKI, HSM VE AKILLI KARTLAR
Luna PCIe HSM mimarisini; anahtar yaşam döngüsü, partition ve rol modeli, PKCS#11 entegrasyonu, HA, yedekleme, FIPS/PCI DSS ayrımı ve güvenli belge imzalama örneğiyle inceliyoruz.
PKI, HSM VE AKILLI KARTLAR
EF.SOD içindeki Document Signer sertifikasının güvenilir CSCA ile eşleştirilmesini, PKIX zincir doğrulamasını, SOD imzasını ve Data Group hash sonuçlarını Java ve jMRTD örnekleriyle adım adım ele alıyoruz.
DİJİTAL KİMLİK VE CÜZDANLAR
Registra'nın kimlik kartı ve pasaport çipinden doğrulanmış veriyi web'de hazırlanan şablonlarla birleştirip PDF'i telefonda üretme akışını; biyometrik giriş, ekranlar, kullanım senaryoları ve teknik sınırlarıyla inceliyoruz.