Hafta 10 — Sertifikalar ve Kriptografik Yöntemler¶

Sunumun içine tıklayıp ok tuşlarıyla ilerleyin; tam ekran için sunumun sağ altındaki düğmeyi ya da yukarıdaki "Sunumu tam ekran aç" bağlantısını kullanın.

# WSL / Linux / Git Bash
cd week-10/01-pki-chain
sh demo.sh            # kök CA -> ara CA -> sunucu sertifikası üretir ve zinciri dokuz farklı senaryoda doğrular

cd ../02-signature-verification
sh demo.sh            # ECDSA (P-256) ile imzala -> doğrula -> tek bayt kurcala -> doğrulama reddetsin

cd ../03-block-cipher-modes
python block_modes.py     # ECB/CBC/CTR/bir GCM benzeri kip: zincirleme, IV, tek bit çevirmenin etkisi

openssl version
mkdir C:\Dersler\h10; cd C:\Dersler\h10

sudo apt install -y openssl softhsm2 opensc
openssl version
mkdir -p ~/h10 && cd ~/h10

0. Temel kavramlar (sıfırdan)¶

Bu bölüm haftaya hazırlık içindir. Önce bu haftanın dayandığı önceki konuları kısaca hatırlatır; sonra bu haftanın kavramlarını birer cümleyle tanımlayıp her birini ayrıntılı anlatıldığı bölüme bağlar.

Önceki haftalardan gelenler¶

• Simetrik ve asimetrik şifreleme — simetrik şifreleme iki tarafın paylaştığı tek bir anahtarla hızlı çalışır; asimetrik şifreleme açık ve özel anahtar çiftiyle anahtar dağıtımını kolaylaştırır ama yavaştır (Hafta 3, §2.2). Bu hafta asimetrik tarafın matematiğini (RSA, ECC — §4) ve simetrik tarafın doğru kip/dolgu seçimini (§2) derinleştiriyoruz.
• AEAD — kimlik doğrulamalı şifreleme, veriyi tek bir çağrıda hem şifreleyip hem de değişmediğini kanıtlayan bir etiket üreterek gizlilik ve bütünlüğü birlikte sağlar (Hafta 3, §2.1). Bu hafta AEAD'in içindeki kip (GCM) ile ondan uzak durulması gereken alternatiflerin (ECB, CBC) neden farklı güvenlik verdiğini gösteriyoruz (§2).
• Özet (hash), MAC ve dijital imza — özet veriden hesaplanan tek yönlü bir parmak izidir; MAC paylaşılan bir anahtarla, dijital imza ise açık/özel anahtar çiftiyle mesajın değişmediğini kanıtlar (Hafta 3, §2.4). Bu hafta HMAC'in iç yapısını ve şifrelemeyle doğru birleştirme sırasını (§3), imza doğrulamasının pratikteki tuzaklarını (§5) işliyoruz.
• İleri gizlilik (forward secrecy) — oturum için türetilen anahtarın kullanımdan sonra silinmesiyle, bugünkü anahtar sızsa bile geçmiş oturumların çözülememesidir (Hafta 3, §7.1). Bu hafta bunun temelindeki Diffie–Hellman anahtar değişimini ve kimlik doğrulamasını sıfırdan kuruyoruz (§6).
• TLS sertifika doğrulama — istemcinin bir sunucu sertifikasını zincir, geçerlilik tarihi, kullanım amacı ve ad açısından denetlemesidir (Hafta 3, §9.2). Bu hafta bu doğrulamanın dayandığı PKI, X.509 ve iptal (CRL/OCSP) mekanizmalarını baştan kuruyoruz (§7–10).

Bu haftanın kavram haritası¶

Kavramlar birbirine nasıl bağlanır?¶

Yukarıdaki terimler rastgele bir liste değildir; her biri bir öncekinin üstüne oturur. Aşağıdaki tablo "bunu anlamak için önce şunu bilmem gerekir" ilişkisini gösterir — bir terimi unutursanız tablodaki "önkoşul" sütununa geri dönün.

Bu tablonun okunuş yönü önemlidir: satır başındaki terimi anlamak için önce "önkoşulu" sütunundaki terimi bilmelisiniz. Örneğin "sertifika iptali" (CRL/OCSP) bölümünü okumadan önce "sertifika" ve "CA" kavramlarının oturmuş olması gerekir; aksi hâlde "CA neden iptal listesini imzalıyor?" sorusu havada kalır.

1. Kriptografinin haritası ve algoritma seçimi¶

Dokuzuncu haftayı bir uyarıyla bitirmiştik: kod gizleme bir anahtarı saklamaz, yalnız çevresini zorlaştırır (Hafta 9, §3). Bu hafta tam da bunun çözümüne geçiyoruz — anahtarları gizlemek yerine, doğru algoritma seçimi, doğru protokol ve gerektiğinde donanım destekli saklama (PKI, HSM) ile gerçekten koruyoruz. Üçüncü haftada veriyi aktarımda, beklemede ve kullanımda korumak için kriptografiyi bir araç olarak kullanmıştık (Hafta 3, §1); bu hafta aynı araçların içine bakıyoruz: hangi algoritma hangi işi yapar, neden bazıları terk edildi, nasıl seçilir ve bir sertifika otoritesi (CA) bu yapıya nasıl oturur. Kitabın 4–8. ve 10–11. bölümleri, 55'ten fazla tarifle bu konuları işler; 2003'ten beri algoritmaların çoğu değiştiği için her birini güncel karşılığıyla veriyoruz.

Beş temel iş, beş araç ailesi¶

Anahtar uzunluğu: güvenlik düzeyi¶

Farklı algoritmaların anahtar uzunlukları doğrudan karşılaştırılamaz. NIST SP 800-57, bunları eşdeğer güvenlik düzeyinde (bit cinsinden) karşılaştırır:

Bugün yeni bir tasarım için alt sınır 128 bit güvenlik düzeyidir. Bu, RSA'da 3072 bit, eliptik eğride 256 bit demektir; 2048 bitlik RSA, NIST'in geçiş planında 2030'dan sonra yeni kullanım için yeterli sayılmaz. Tablonun en önemli dersi, eliptik eğrilerin aynı güvenliği çok daha kısa anahtarlarla sağlamasıdır; mobil ve gömülü sistemlerde tercih edilmelerinin nedeni budur.

En zayıf halka kuralı¶

Bir sistem birden çok kriptografik katman kullanır: anahtar değişimi bir algoritmayla, veri şifreleme başka biriyle yapılır. Sistemin güvenlik düzeyi bu katmanların en düşüğüne eşittir — en güçlüsüne değil. RSA-2048 ile anahtar taşıyıp veriyi AES-256 ile şifrelerseniz, saldırgan 256 bitlik AES'i kırmaya çalışmaz; ≈112 bitlik RSA katmanını hedef alır. Bu yüzden katmanları tek tek değil, birlikte ve en düşük seviyeye göre değerlendirin.

Bir kural: kendi kriptonuzu yazmayın, kendi protokolünüzü de¶

Algoritmaların hepsi doğru olsa bile, onları birleştirmek (hangi sırayla şifreleyip MAC'leyeceğinizi, nonce'u nereden alacağınızı, anahtarları nasıl ayıracağınızı seçmek) ayrı bir uzmanlık ister. Bu haftanın bütün örnekleri, sahadaki hataların neredeyse hepsinin algoritmada değil, birleştirmede olduğunu gösterecek. Mümkün olan her yerde hazır, kanıtlanmış yapıları (TLS 1.3, AEAD, HPKE, Noise) kullanın.

Sayısal örnek: "128 bit" ile "112 bit" arasındaki fark ne kadar büyük?¶

Tablodaki bit sayıları soyut kalabilir; somutlaştıralım. Bir güvenlik düzeyi "n bit" demek, saldırganın ortalama 2ⁿ⁻¹ işlem denemesi gerektiği anlamına gelir (üst sınır olarak 2ⁿ kullanılır). RSA-2048 (112 bit) ile AES-128 (128 bit) arasındaki fark, sanıldığından çok daha büyüktür:

2^112 ≈ 5,19 × 10^33   (RSA-2048'in eşdeğer zorluğu)
2^128 ≈ 3,40 × 10^38   (AES-128'in anahtar uzayı)
2^128 / 2^112 = 2^16 = 65.536   → AES-128'i kırmak, RSA-2048'i "eşdeğer" zorlukta kırmaktan 65.536 KAT daha zor

Bunu zamana çevirelim. Bugünkü en hızlı süper bilgisayarların saniyede yapabileceği işlem sayısını iyimser bir üst sınırla 10¹⁸ (kentilyon; exaölçek süper bilgisayar) olarak alalım — gerçek saldırılarda bu sayı çok daha düşüktür, çünkü şifre kırma tek bir aritmetik işlem değil, çok daha pahalı bir işlemdir. Yine de üst sınırla hesaplayalım:

2^112 işlem ÷ 10^18 işlem/saniye ≈ 1,6 × 10^8 yıl  (≈ 165 milyon yıl)
Karşılaştırma: yazılı insanlık tarihi ≈ 5.000 yıl → 165 milyon yıl, bunun ~33.000 katı
2^128 işlem ÷ 10^18 işlem/saniye ≈ 1,08 × 10^13 yıl
Karşılaştırma: evrenin yaşı ≈ 1,38 × 10^10 yıl → 2^128, evrenin yaşının ~780 katı kadar sürer

Çıkarılacak ders iki yönlüdür. Birincisi, 112 bit bile bugün için pratikte kaba kuvvetle kırılamaz; RSA-2048'in 2030 sonrası için "yetersiz" sayılmasının nedeni kaba kuvvet değil, (a) donanımın zamanla ucuzlaması, (b) uzun süre saklanması gereken verilerin gelecekteki saldırılara karşı pay bırakılarak korunması gerekliliği ve © kuantum bilgisayarların RSA'yı kaba kuvvetten çok daha hızlı kırabilecek olmasıdır (bkz. Bölüm 12). İkincisi, 112 bit ile 128 bit arasındaki görünüşte küçük fark (16 bit), saldırganın işini 65 binde bir**e indirger — bit sayılarını doğrusal değil, **üstel okumalısınız.

Üçüncü haftada bu haritanın yalnız "hangi aracı ne zaman kullanırım" kısmını gördük (AEAD, hibrit şema, rastgele sayı). Bu hafta aynı haritanın neden böyle çizildiğini — hangi matematiksel problem hangi güvenliği veriyor, hangi algoritma neden terk edildi — görüyoruz. Sıradaki iki bölüm simetrik araçların (kip, dolgu, MAC) içine; 4–6. bölümler asimetrik araçların (RSA, ECC, DH) içine; 7–10. bölümler bunların PKI'da nasıl bir araya geldiğine bakacak.

2. Blok şifre kipleri ve dolgu (Tarif 5.4, 5.11)¶

AES bir blok şifredir: tam olarak 16 baytlık bir bloğu, 16 baytlık başka bir bloğa çevirir. Daha uzun bir mesajı şifrelemek için blokları birbirine bağlayan bir kip (mode of operation) gerekir. Kip seçimi, algoritma seçimi kadar önemlidir; 3. haftadaki ECB penguenini hatırlayın.

Dolgu ve dolgu kâhini¶

ECB ve CBC, mesaj uzunluğunun blok boyutunun katı olmasını ister; eksik kısım dolgu ile tamamlanır. En yaygın dolgu PKCS#7'dir: eksik bayt sayısı n ise, n adet n değerli bayt eklenir (ör. 3 bayt eksikse 03 03 03). Çözen taraf son baytı okuyup o kadar baytı atar; ama önce dolgunun geçerli olup olmadığını denetler.

Sorun burada başlar: çözme hatası "dolgu geçersiz" ve "MAC geçersiz" olarak ayırt edilebiliyorsa (farklı hata iletisi, farklı yanıt süresi), saldırgan şifreli metnin baytlarını değiştirip sunucunun tepkisini gözleyerek mesajı bayt bayt çözebilir. Buna dolgu kâhini (padding oracle) saldırısı denir; Serge Vaudenay 2002'de tanımladı, sonraki yıllarda web çerçevelerinde ve TLS'te (POODLE, Lucky Thirteen) tekrar tekrar karşımıza çıktı.

Savunmalar:

1. AEAD kullanın (GCM, ChaCha20-Poly1305): dolgu yoktur, etiket tutmazsa hiçbir şey çözülmez.
2. CBC zorunluysa önce şifrele, sonra MAC'le (bir sonraki bölüm) ve MAC'i dolguyu denetlemeden önce doğrulayın.
3. Bütün çözme hatalarını tek ve aynı hata olarak, aynı sürede döndürün.

İşlenmiş örnek: PKCS#7 dolgusunu elle izlemek¶

"3 bayt eksikse 03 03 03 eklenir" kuralını soyut bırakmayalım; gerçek bir OpenSSL çalıştırmasıyla adım adım izleyelim. 16 baytlık sabit bir anahtar ve sıfırdan artan bir IV (yalnız bu örnek için; gerçek sistemde IV her mesajda rastgele üretilir) ile 13 baytlık "MERHABA DUNYA" metnini AES-128-CBC ile şifreleyelim:

K=00112233445566778899aabbccddeeff   # 16 bayt (32 hex karakter) — yalnız gösterim için sabit
IV=000102030405060708090a0b0c0d0e0f  # 16 bayt — yalnız gösterim için sabit
printf 'MERHABA DUNYA' | openssl enc -aes-128-cbc -K "$K" -iv "$IV" -out cikti.bin
xxd -p cikti.bin

Çıktı (gerçekten üretilen değer):

4b354371f98acde5bed95d59a8135538

Girdi 13 bayttı; AES'in blok boyu 16 bayttır; çıktı da tam 16 bayt (32 hex karakter) — demek ki 3 baytlık bir dolgu eklenmiş. Dolgunun içeriğini görmek için -nopad ile çözelim (normalde bunu hiç yapmayız; burada yalnız öğretici amaçla):

openssl enc -d -aes-128-cbc -K "$K" -iv "$IV" -in cikti.bin -nopad | xxd

00000000: 4d45 5248 4142 4120 4455 4e59 4103 0303  MERHABA DUNYA...

Son üç bayt 03 03 03 — tam olarak PKCS#7 kuralının söylediği gibi: eksik bayt sayısı (16 − 13 = 3) kadar, o sayı değerinde bayt eklenmiş. Normal openssl enc -d (dolgusuz bayrak olmadan) bu üç baytı otomatik okuyup atar ve size tam olarak "MERHABA DUNYA" döndürür — bunu da doğrulayın:

openssl enc -d -aes-128-cbc -K "$K" -iv "$IV" -in cikti.bin

MERHABA DUNYA

Dolgu kâhini saldırısı tam bu noktada devreye girer: saldırgan şifreli metnin son baytlarını değiştirip sunucuya gönderir; sunucu "dolgu geçersiz" (ör. son bayt 07 ama önceki 7 bayt 07 değil) ile "dolgu geçerli ama MAC geçersiz" hatalarını farklı döndürüyorsa, saldırgan bu iki durumu ayırt ederek düz metni bayt bayt yeniden kurabilir — anahtara hiç ihtiyaç duymadan.

Dolgunun eklenmesini ve üç denetimin (uzunluk, son bayt aralığı, her dolgu baytının değeri) sırayla nasıl çalıştığını, hangisinin hangi bozulmada başarısız olduğunu görerek izleyin:

Uyar: dolgu doğru, Zor: son bayt bozuldu ve Uç durum: uzunluk artık blok katı değil / Uç durum: bir dolgu baytı bozuldu örneklerinin hepsini deneyip hangi kontrolün nerede durduğunu karşılaştırın.

İşlenmiş örnek: ECB'nin deseni neden sızdırdığını görmek¶

ECB'de her 16 baytlık blok bağımsız şifrelenir; aynı düz metin bloğu her zaman aynı şifreli metin bloğunu üretir. 48 bayt boyunca tekrar eden bir düz metni ("AAAAAAAAAAAAAAAA" üç kez) AES-128-ECB ile şifreleyelim:

K2=$(openssl rand -hex 16)
printf 'AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA' | head -c 48 > duz.txt   # 48 bayt = 3 blok, hepsi ayni
openssl enc -aes-128-ecb -K "$K2" -in duz.txt -out cikti_ecb.bin -nopad
xxd cikti_ecb.bin

Örnek bir çalıştırmanın çıktısı (anahtar rastgele olduğu için siz farklı bayt değerleri göreceksiniz, ama örüntü aynı kalacak):

00000000: f5cf 4879 d8fe 9c90 1975 2de6 eb9f 59a1  ..Hy.....u-...Y.
00000010: f5cf 4879 d8fe 9c90 1975 2de6 eb9f 59a1  ..Hy.....u-...Y.
00000020: f5cf 4879 d8fe 9c90 1975 2de6 eb9f 59a1  ..Hy.....u-...Y.

Üç blok da birebir aynı. Anahtarı bilmeyen bir gözlemci bile "bu üç blok aynı düz metni içeriyor" bilgisini elde eder — ki bu genelde başlı başına bir sızıntıdır (ör. bir resmin arka planı, bir formun sabit alanları, tekrarlanan bir kayıt yapısı). AES-128-CBC ile aynı deneyi tekrarlarsanız (rastgele IV ile), üç blok da farklı çıkar; çünkü her blok bir öncekiyle XOR'lanarak zincirlenir.

Dört kipin (ECB, CBC, CTR, GCM benzeri) hepsini aynı küçük mesaj üzerinde, bayt bayt, bir kurcalamanın her kipte neye yol açtığını görerek karşılaştırın:

Örnek seçiciden Uyar: ECB, tekrar eden desen sızar, Zor: CBC, şifreli metin kurcalandı ve Uç durum: GCM benzeri, kurcalama REDDEDİLİR örneklerini deneyin; 🎲 ile rastgele bir mesaj/kip de üretebilirsiniz.

İkinci haftadaki tehdit modellemesinde "bütünlük" bir varlık koruma hedefiydi; bu bölüm o hedefin neden yalnız şifrelemekle sağlanamadığını somutlaştırdı. Sıradaki bölüm, bütünlüğü doğru sağlayan aracı — MAC/HMAC'i ve doğru birleştirme sırasını — işliyor.

3. MAC, HMAC ve şifreleme ile bütünlüğün birleştirilmesi (Tarif 6.4, 6.10, 6.18, 6.21)¶

HMAC nasıl çalışır?¶

Encrypt-then-MAC: alıcı geçersiz metni hiç çözmediği için dolgu kâhini (padding oracle) için gereken "hata sızıntısı" oluşmaz. AES-GCM bu iki adımı tek işlemde yapar.

MAC (mesaj kimlik doğrulama kodu), gizli bir anahtar ve bir mesajdan kısa bir etiket üretir; anahtarı bilmeyen biri geçerli bir etiket üretemez. HMAC'i Bellare, Canetti ve Krawczyk 1996'da tanımladı; 1997'de RFC 2104 olarak standartlaştı. Bir özet fonksiyonundan (SHA-256) MAC üretmenin standart yoludur:

HMAC(K, m) = H( (K ⊕ opad) ‖ H( (K ⊕ ipad) ‖ m ) )

İç içe iki özet, düz H(K ‖ m) yapısının uzunluk uzatma zayıflığını ortadan kaldırır: SHA-256 gibi Merkle–Damgård yapısındaki özetlerde H(K ‖ m) biliniyorsa, anahtarı bilmeden H(K ‖ m ‖ ek) hesaplanabilir. Bu yüzden kendi MAC'inizi özetten türetmeyin; HMAC kullanın (Tarif 6.19'un uyarısı).

İç (ipad) ve dış (opad) özetin anahtarı nasıl iki farklı sabitle karıştırdığını, anahtar bloktan uzun/kısa olduğunda ne olduğunu adım adım izleyin:

Uyar: kısa anahtar, Zor: uzun anahtar, önce hashlenir ve Uç durum: anahtar tam blok boyunda örneklerini karşılaştırın.

printf 'tutar=100;alici=TR00' | openssl dgst -sha256 -mac HMAC -macopt hexkey:$(openssl rand -hex 32)

Şifreleme ile MAC'i birleştirmenin üç yolu¶

AEAD kipleri bu seçimi sizin yerinize doğru yapar. Kendi birleştirmenizi yapmak zorundaysanız (Tarif 6.18): iki ayrı anahtar kullanın (biri şifreleme, biri MAC için; HKDF ile tek sırdan türetilebilir), önce şifrele, sonra MAC sırasını izleyin, MAC'e IV'yi ve bağlam bilgisini de katın, karşılaştırmayı sabit zamanlı yapın.

Aynı mesajı iki sırayla da koruyup AYNI kurcalamayı uygulayın: önce-şifrele-sonra-MAC tek bir nedenle (MAC uyuşmuyor) hemen reddeder; MAC-sonra-şifrele önce çözer/dolguyu denetler, bu yüzden bozulmanın türüne göre İKİ FARKLI hata verebilir:

Zor: dolguyu bozmayan kurcalama ile Uç durum: dolguyu bozan kurcalama örneklerini yan yana çalıştırıp hangi hattın hangi noktada durduğunu karşılaştırın.

Yeniden oynatma: geçerli ama eski mesaj¶

Bir MAC mesajın değiştirilmediğini kanıtlar, ama yeni olduğunu kanıtlamaz. Saldırgan geçerli bir "100 TL gönder" iletisini kaydedip on kez yeniden gönderebilir; her seferinde MAC geçerlidir. Kitabın Tarif 6.21'de anlattığı savunmalar:

İşlenmiş örnek: HMAC'i elle hesaplamak ve çığ etkisini görmek¶

Kuralları soyut bırakmadan, gerçek bir HMAC-SHA-256 hesabını uçtan uca izleyelim. Sabit (yalnız bu örnek için) 32 baytlık bir anahtar kullanıp bir ödeme talimatının HMAC'ini hesaplayalım:

ANAHTAR=0000000000000000000000000000000000000000000000000000000000000001   # 32 bayt, yalniz gosterim icin sabit
printf 'tutar=100;alici=TR00' | openssl dgst -sha256 -mac HMAC -macopt hexkey:$ANAHTAR

SHA2-256(stdin)= a08fb1159871e3b8110dedf3e3524cab7bea06f4795f2119394e11c42ac5f9a1

Şimdi saldırgan tutarı 100'den 900'e değiştirsin; gerçek anahtarla asıl mesajın HMAC'i şu şekilde değişir:

printf 'tutar=900;alici=TR00' | openssl dgst -sha256 -mac HMAC -macopt hexkey:$ANAHTAR

SHA2-256(stdin)= 8a786eacbef7863d44533b9ebcbcf288e5136204080258e838e283f1f91a46be

Tek bir karakterlik değişiklik (1→9), etiketin tamamen farklı 32 baytını üretti — bu, iyi bir özet fonksiyonunun "çığ etkisi"dir (avalanche effect): girdideki tek bitlik değişiklik, çıktının yaklaşık yarısını değiştirir. Saldırgan anahtarı bilmediği için mesajı değiştirip geçerli bir yeni etiket üretemez; alıcı etiketleri karşılaştırıp uyuşmazlığı yakalar.

Sabit zamanlı karşılaştırma: neden memcmp yetmez¶

Alıcı tarafta HMAC doğrulaması, hesaplanan etiketle gelen etiketi karşılaştırmayı gerektirir. Sıradan bir memcmp(a, b, 32) baytları soldan sağa karşılaştırır ve ilk farklı baytta durur; bu, fonksiyonun çalışma süresinin kaç baytın eşleştiğine bağlı olarak değiştiği anlamına gelir. Bir ağ üzerinden yeterince çok deneme yapabilen bir saldırgan, yanıt sürelerindeki mikrosaniyelik farklardan doğru etiketi bayt bayt tahmin edebilir (zamanlama saldırısı, timing attack).

/* YANLIS: erken cikis sure farki yaratir */
if (memcmp(hesaplanan, gelen, 32) == 0) { /* kabul */ }

/* DOGRU: sabit zamanli, her zaman 32 baytin tamamini gezer */
if (CRYPTO_memcmp(hesaplanan, gelen, 32) == 0) { /* kabul */ }   /* OpenSSL */
/* ya da: sodium_memcmp (libsodium), hmac.compare_digest (Python) */

Üçüncü haftada AEAD'i "gizlilik + bütünlüğü tek pakette veren araç" olarak tanıttık; bu bölüm bütünlüğü ayrı sağlamak zorunda kaldığınızda (AEAD kullanamadığınız eski bir protokol, donanım kısıtı, vb.) doğru sırayı ve doğru karşılaştırmayı gösterdi. Sıradaki bölüm, MAC'in veremediği şeyi — inkâr edilemezliği — veren asimetrik araçlara geçiyor.

4. Asimetrik kriptografi: RSA ve eliptik eğriler (Tarif 7.1–7.3)¶

Simetrik kriptografinin tek zorluğu, iki tarafın aynı anahtarı önceden paylaşmasıdır. Asimetrik (açık anahtarlı) kriptografide her tarafın bir anahtar çifti vardır: herkese verilen açık anahtar ve yalnız sahibinin bildiği özel anahtar. Açık anahtarla şifrelenen yalnız özel anahtarla çözülür; özel anahtarla imzalanan herkesçe açık anahtarla doğrulanır.

Asimetrik işlemler simetrik olanlardan yüzlerce, binlerce kat yavaştır. Bu yüzden asimetrik kriptografi yalnız iki iş için kullanılır (Tarif 7.1): kısa bir simetrik anahtarı taşımak ya da anlaşmak ve imzalamak. Verinin kendisi her zaman simetrik şifreyle korunur (3. haftadaki hibrit şema).

RSA: doğru dolguyla¶

RSA'yı Rivest, Shamir ve Adleman 1977'de yayımladı. Matematiği yalın haliyle ("ders kitabı RSA") güvensizdir: aynı mesaj her zaman aynı şifreli metni verir ve matematiksel yapısı saldırılara açıktır. Güvenli kullanım, doğru dolgu şemasına bağlıdır — PKCS#1 (v1.5) dolgu şeması 1991'de RSA Laboratories tarafından yayımlandı; Daniel Bleichenbacher 1998'de v1.5 şifrelemesine karşı pratik bir dolgu kâhini saldırısı yayımladı:

Kitabın Tarif 7.10–7.13'teki "ham" RSA işlemleri, dolgusuz RSA'nın nasıl çalıştığını anlamak içindir; üretimde kullanılmaz. Tarif 7.14'teki uyarı ise hâlâ önemlidir: imzala-ve-şifrele birleştirmesi dikkat ister; imza, şifrelenen içeriğin alıcısına ve bağlamına bağlanmazsa, alıcı imzalı mesajı başka birine yeniden şifreleyip iletebilir.

openssl genpkey -algorithm RSA -pkeyopt rsa_keygen_bits:3072 -out rsa_ozel.pem
openssl pkey -in rsa_ozel.pem -pubout -out rsa_acik.pem

# OAEP (SHA-256) ile kısa bir oturum anahtarını şifrele
openssl rand -out oturum.key 32
openssl pkeyutl -encrypt -pubin -inkey rsa_acik.pem -in oturum.key -out oturum.enc \
    -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256

# PSS ile imzala ve doğrula
openssl dgst -sha256 -sign rsa_ozel.pem -sigopt rsa_padding_mode:pss -out belge.sig belge.txt
openssl dgst -sha256 -verify rsa_acik.pem -sigopt rsa_padding_mode:pss -signature belge.sig belge.txt

3072 bitlik gerçek bir anahtarın matematiği elle izlenemez; aynı işlemleri (üretim, şifreleme, çözme, imzalama, doğrulama) oyuncak asallarla (Wikipedia'nın klasik p=61, q=53 örneği) uçtan uca izleyin:

Uyar: klasik örnek ile başlayıp Uç durum: imza kurcalandı ve Uç durum: yanlış açık anahtarla doğrulama örneklerinde doğrulamanın neden başarısız olduğunu izleyin.

Eliptik eğriler: aynı güvenlik, daha kısa anahtar¶

Eliptik eğri kriptografisi (ECC), birbirinden bağımsız olarak Neal Koblitz (1987) ve Victor Miller (1985) tarafından önerildi. 256 bitlik anahtarla 3072 bitlik RSA'nın güvenlik düzeyini sağlar; işlemleri daha hızlı, anahtarları ve imzaları çok daha kısadır.

openssl genpkey -algorithm ED25519 -out ed_ozel.pem
openssl pkey -in ed_ozel.pem -pubout -out ed_acik.pem
openssl pkeyutl -sign   -inkey ed_ozel.pem -rawin -in belge.txt -out belge.ed.sig
openssl pkeyutl -verify -pubin -inkey ed_acik.pem -rawin -in belge.txt -sigfile belge.ed.sig

X25519/Ed25519'un içindeki işlem, eğri üzerinde nokta toplamadır — modüler üs alma yerine. Aynı Diffie–Hellman fikrini (Bölüm 6), aynı oyuncak ölçekte, küçük bir eğri üzerindeki nokta toplamayla görün:

Zor: büyük özel değerler örneğinde adım sayısının nasıl arttığını, Uç durum: Mallory araya giriyor örneğinde ise kimliksiz bir eğri değişiminin de Bölüm 6'daki zayıflığı aynen taşıdığını görün.

İşlenmiş örnek: RSA-3072 ile Ed25519'u ölçmek¶

"ECC aynı güvenliği daha küçük anahtarla verir" cümlesini gerçek baytlarla doğrulayalım. Her ikisi de ~128 bit güvenlik düzeyindedir (bkz. Bölüm 1 tablosu):

wc -c rsa_acik.pem ed_acik.pem
openssl dgst -sha256 -sign rsa_ozel.pem -sigopt rsa_padding_mode:pss -out belge.rsa.sig belge.txt
openssl pkeyutl -sign -inkey ed_ozel.pem -rawin -in belge.txt -out belge.ed.sig
wc -c belge.rsa.sig belge.ed.sig

  636 rsa_acik.pem
  116 ed_acik.pem
  384 belge.rsa.sig
   64 belge.ed.sig

Açık anahtar dosyası (PEM, Base64 kodlu) RSA'da 636 bayt, Ed25519'da 116 bayt — yaklaşık 5,5 kat küçük. İmza RSA'da 384 bayt (3072 bit = 384 bayt, RSA imzası tam olarak modül boyutu kadardır), Ed25519'da 64 bayt — 6 kat küçük. Bir IoT cihazının her el sıkışmada gönderdiği veri, gömülü bir sistemin flash'ta sakladığı sertifika sayısı ya da bir blok zincirinde her işlemin taşıdığı imza sayısı düşünüldüğünde, bu fark birikerek büyür; ECC'nin mobil/gömülü sistemlerde ve yeni protokollerde (TLS 1.3, SSH, Signal) varsayılan olmasının nedeni budur.

İşlenmiş örnek: OAEP'in rastgeleliği neden gerekli?¶

Bölüm 2'de ECB'nin aynı düz metin bloğu için aynı şifreli metni ürettiğini ve bunun bir desen sızıntısı olduğunu gördük. "Ders kitabı RSA" (ham, dolgusuz) da aynı hastalığı taşır: aynı mesaj her zaman aynı şifreli metni verir. OAEP bunu, şifrelemeden önce mesaja rastgele bir değer karıştırarak çözer. Aynı mesajı iki kez OAEP ile şifreleyelim:

echo MERHABA > kisa.txt
openssl pkeyutl -encrypt -pubin -inkey rsa_acik.pem -in kisa.txt -out c1.bin \
    -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256
openssl pkeyutl -encrypt -pubin -inkey rsa_acik.pem -in kisa.txt -out c2.bin \
    -pkeyopt rsa_padding_mode:oaep -pkeyopt rsa_oaep_md:sha256
cmp c1.bin c2.bin && echo "AYNI" || echo "FARKLI"

c1.bin c2.bin differ: char 1, line 1
FARKLI

Aynı açık anahtar, aynı düz metin, ama farklı şifreli metin — çünkü OAEP her şifrelemede yeni bir rastgele değer kullanır (Bölüm 1'deki "rastgele sayılar kriptografinin görünmez temelidir" ilkesinin RSA'daki karşılığı). Dolgusuz ("ham") RSA ile aynı deneyi yaparsanız iki çıktı birebir aynı olur; matematiksel olarak c = m^e mod n deterministik bir işlemdir. Bu yüzden ham RSA hiçbir zaman doğrudan şifreleme için kullanılmaz.

Üçüncü haftada TLS'in anahtar kurulumunda asimetrik kriptografiyi (o zaman RSA ya da ECDHE) bir kara kutu gibi kullanmıştık. Bu bölüm o kara kutunun içini açtı: hangi dolgu, hangi eğri, hangi boyut. Sıradaki bölüm bu araçların imza ayağını derinleştiriyor; sonra Bölüm 6'da anahtar değişimi ayağına geçiyoruz.

5. Dijital imza: oluşturma, doğrulama ve kullanım yerleri¶

Dijital imza, bir mesajın (1) belirli bir özel anahtarın sahibi tarafından oluşturulduğunu ve (2) sonradan değiştirilmediğini kanıtlar. MAC'ten farkı, doğrulamanın açık anahtarla yapılmasıdır: herkes doğrulayabilir ama yalnız özel anahtarın sahibi imzalayabilir. Bu yüzden imza inkâr edilemezlik sağlar (STRIDE'daki R), MAC sağlamaz.

İmza nerelerde kullanılır?¶

Kodda imza doğrulama: OpenSSL EVP¶

#include <openssl/evp.h>
#include <openssl/pem.h>

/* 1: geçerli, 0: geçersiz, -1: hata. Güncelleme paketini ÇALIŞTIRMADAN önce çağrılır. */
int imza_dogrula(EVP_PKEY *acik, const unsigned char *veri, size_t n,
                 const unsigned char *imza, size_t imza_n)
{
    EVP_MD_CTX *ctx = EVP_MD_CTX_new();
    int sonuc = -1;
    if (ctx == NULL) return -1;
    if (EVP_DigestVerifyInit(ctx, NULL, NULL, NULL, acik) == 1)   /* Ed25519: özet NULL */
        sonuc = EVP_DigestVerify(ctx, imza, imza_n, veri, n);      /* 1 ya da 0 */
    EVP_MD_CTX_free(ctx);
    return sonuc == 1 ? 1 : (sonuc == 0 ? 0 : -1);
}

İşlenmiş örnek: imza doğrulamasını üç durumda komut satırından izlemek¶

Yukarıdaki C kodunun mantığını, derlemeye gerek kalmadan openssl pkeyutl -verify ile de görebilirsiniz — CLI da aynı üç sonucu (geçerli / geçersiz / hata) üretir:

openssl pkeyutl -verify -pubin -inkey ed_acik.pem -rawin -in belge.txt -sigfile belge.ed.sig
echo "cikis kodu: $?"

Signature Verified Successfully
cikis kodu: 0

echo "MERHABA DEGISTI" > belge2.txt
openssl pkeyutl -verify -pubin -inkey ed_acik.pem -rawin -in belge2.txt -sigfile belge.ed.sig
echo "cikis kodu: $?"

Signature Verification Failure
cikis kodu: 1

Belgenin tek bir baytı bile değişince doğrulama başarısız oldu ve çıkış kodu 0'dan 1'e döndü — güncelleme mekanizmanız bu kodu denetlemiyorsa (ya da C kodunda EVP_DigestVerify'ın dönüşünü if (sonuc) ile yorumluyorsa), kurcalanmış bir paketi çalıştırılabilir hâle getirmiş olursunuz.

Aynı mantığı, gerçek bir imza üzerinde altı senaryoda (doğru imza, kurcalanmış belge, yanlış anahtarla imzalanmış bir mesaj) izleyin:

Uyar: doğru imza, doğru anahtar, Zor: belge imzadan sonra kurcalandı ve Uç durum: saldırganın kendi anahtarıyla imzalanmış örneklerini karşılaştırın.

Sürüm geri alma: imza geçerli ama içerik eski¶

"İmzanın kapsamı" tuzağını somutlaştıralım. Diyelim ki bir uygulama güncelleme sunucusu her sürümü ayrı ayrı imzalar:

Sunucu v2.0'ı yayımladıktan sonra v1.0'ın imzası iptal edilmez — imzalar CRL/OCSP gibi bir iptal mekanizmasına sahip değildir (bu, Bölüm 10'da sertifikalar için göreceğimiz mekanizmadır). Saldırgan, ele geçirdiği v1.0 paketini ve imza_v1'i istemciye sunarsa, istemci yalnız "imza geçerli mi?" diye sorup evet cevabını alır ve zafiyetli sürümü kurar. Bu yüzden imzalanan veri yalnız dosya içeriği değil, sürüm numarası + hedef ürün adı olmalı ve istemci ayrıca "gördüğüm en yüksek sürümden daha eski bir sürümü kabul etme" kuralını kendi başına uygulamalıdır — imza bunu sizin yerinize yapmaz.

Birinci haftadaki "Kasa" örneğinde bir güncelleme paketinin imzasız kabul edilmesinin T6 tehdidine yol açtığını görmüştük; bu bölüm imzanın var olmasının bile tek başına yetmediğini, kapsamının da doğru tasarlanması gerektiğini gösterdi. Sıradaki bölüm, imza ve asimetrik kriptografiyi anahtar değişiminde nasıl kullandığımızı — ve kullanmazsak neyin ters gideceğini — işliyor.

6. Anahtar değişimi: Diffie–Hellman ve araya girme (Tarif 8.16–8.18)¶

Diffie–Hellman (DH), iki tarafın güvensiz bir kanal üzerinden, hiç önceden paylaşılmış sır olmadan ortak bir sır üzerinde anlaşmasını sağlar. Her taraf bir özel değer seçer, bundan türettiği açık değeri gönderir; iki taraf da karşısındakinin açık değeri ve kendi özel değeriyle aynı ortak sırrı hesaplar. Dinleyen biri açık değerleri görür ama ortak sırrı hesaplayamaz. Bugün kullanılan biçimi eliptik eğri üzerindeki ECDH'dir (X25519).

Kimliksiz DH'nin zayıflığı: araya girme¶

DH kimin ile anlaşıldığını söylemez. Kanalın ortasındaki bir saldırgan, iki tarafla ayrı ayrı DH yapar:

İki taraf da "güvenli bir kanalım var" sanır; aslında her mesaj saldırganın elinden geçer. Aşağıda aynı saldırıyı küçük sayılarla (klasik p=23, g=5 örneği) uçtan uca izleyin — Alice ve Bob'un normal değişimiyle, sonra Mallory araya girince iki tarafın farklı anahtarlara ulaştığını görün:

Uyar: klasik örnek ile dürüst değişimi, Uç durum: Mallory araya giriyor ile saldırıyı karşılaştırın.

Çözüm: kimliği doğrulanmış anahtar değişimi¶

Açık değerler, kimliği önceden bilinen bir anahtarla imzalanır (Tarif 8.18'deki "DH ve DSA birlikte" fikrinin güncel hali: ECDHE + Ed25519/ECDSA/RSA-PSS). TLS 1.3'te sunucu, geçici (ephemeral) ECDHE açık değerini de içeren el sıkışma özetini sertifikasındaki özel anahtarla imzalar (CertificateVerify); istemci sertifikayı zincir ve ad açısından doğrular (3. hafta). Böylece:

• Kimlik: İmza, açık değeri gönderenin gerçekten sertifikanın sahibi olduğunu kanıtlar.
• İleri gizlilik: DH değerleri her oturum için yeniden üretilir ve silinir; uzun ömürlü imza anahtarı ileride çalınsa bile geçmiş oturumların anahtarları hesaplanamaz (3. hafta).

İşlenmiş örnek: X25519 ile iki tarafın aynı sırra ulaşması¶

Diffie–Hellman'ın "iki taraf, önceden paylaşılmış sır olmadan aynı ortak değere ulaşır" cümlesini gerçek anahtarlarla doğrulayalım. Alice ve Bob birbirinden bağımsız birer X25519 anahtar çifti üretir, yalnız açık anahtarlarını değiş tokuş eder:

openssl genpkey -algorithm X25519 -out alice.key
openssl genpkey -algorithm X25519 -out bob.key
openssl pkey -in alice.key -pubout -out alice.pub
openssl pkey -in bob.key -pubout -out bob.pub

# Alice: kendi ozel anahtari + Bob'un acik anahtari
openssl pkeyutl -derive -inkey alice.key -peerkey bob.pub -out alice_sir.bin
# Bob: kendi ozel anahtari + Alice'in acik anahtari
openssl pkeyutl -derive -inkey bob.key -peerkey alice.pub -out bob_sir.bin

xxd -p alice_sir.bin
xxd -p bob_sir.bin
cmp alice_sir.bin bob_sir.bin && echo "AYNI" || echo "FARKLI"

8c53744a000c1a6ffc2183a0c134c2cf8167110314e8a06dd3d453080bbc1376
8c53744a000c1a6ffc2183a0c134c2cf8167110314e8a06dd3d453080bbc1376
AYNI

İki taraf, birbirinin hiç görmediği özel anahtarını bilmeden, ağdan yalnız açık anahtarları geçirerek aynı 32 baytlık ortak sırra ulaştı. Bu ortak sır, doğrudan veri şifrelemede kullanılmaz; bir KDF'den (HKDF, 3. haftadaki anahtar türetme konusu) geçirilip oturum anahtarları buradan türetilir. Dinleyen bir üçüncü taraf yalnız alice.pub ve bob.pub'ı görür; bunlardan ortak sırrı hesaplamak (eliptik eğri ayrık logaritma problemini çözmeden) mümkün değildir.

Sayısal örnek: araya girme kaç adımda kurulur?¶

Kimliksiz DH'de araya girme saldırısı iki ayrı DH anlaşması gerektirir — saldırganın hesap yükü kurbanlarınkinden farklı değildir, yalnız iki kat işlem yapar:

1. Saldırgan (M) Alice'e bağlanır, kendi açık değerini pub_M1 olarak gönderir; Alice bunu Bob'un açık değeri sanır.
2. M, Bob'a bağlanır, pub_M2 gönderir; Bob bunu Alice'in açık değeri sanır.
3. M, Alice ile sir_A = DH(özel_M1, pub_Alice), Bob ile sir_B = DH(özel_M2, pub_Bob) hesaplar — iki farklı ortak sır elde eder.
4. Alice "Bob"a (aslında M'ye) sir_A ile şifreli mesaj gönderir; M bunu çözer, okur, sir_B ile yeniden şifreleyip gerçek Bob'a iletir. Her iki taraf da kendi hesapladığı sırrın doğru karşı tarafla paylaşıldığını sanır.

Saldırganın ek maliyeti yalnız iki kat X25519 işlemi (mikrosaniyeler mertebesinde) — kimlik doğrulaması olmadığında bu saldırı hesaplama açısından neredeyse bedavadır. Bu yüzden imzasız DH, TLS 1.3 gibi hiçbir modern protokolde tek başına kullanılmaz.

Üçüncü haftada TLS 1.3 el sıkışmasında "eğer aradaki biri anahtarları değiştirebilseydi ne olurdu" sorusunu sormuştuk; bu bölüm o soruyu somut adımlarla cevapladı. Sıradaki üç bölüm (7–9), imzalı DH'nin dayandığı kimlik doğrulama altyapısını — PKI'yı — sıfırdan kuruyor.

7. Açık anahtar altyapısı (PKI): kim kime güvenir? (Tarif 10.1)¶

Önceki bölüm açık anahtarların imzayla kimliğe bağlanması gerektiğini gösterdi. Ama bu bir soru doğurur: sunucunun açık anahtarının gerçekten o sunucuya ait olduğunu nereden bileceğiz? Açık anahtar altyapısı (PKI), bu soruya güvenilen üçüncü taraflar aracılığıyla cevap veren kurallar, roller ve belgeler bütünüdür.

Bileşenler¶

Neden ara CA? Kök CA'nın özel anahtarı ele geçirilirse bütün zincir güvenilmez olur ve kökü dünyadaki bütün güven depolarından çıkarmak yıllar sürer. Bu yüzden kök anahtar bir HSM'de, çevrimdışı ve fiziksel olarak korunan bir yerde durur; yalnız ara CA sertifikalarını imzalamak için, tören (key ceremony) denen denetimli toplantılarda kullanılır. Günlük işi ara CA yapar; ele geçirilirse yalnız o ara CA iptal edilir.

Sertifika doğrulama: dört soru (Tarif 10.4)¶

Bir istemci bir sertifikayı kabul etmeden önce şunları sorar:

1. Zincir: Uç sertifikadan başlayarak her sertifikanın imzası, bir üsttekinin açık anahtarıyla doğrulanıyor mu ve zincir güven deposundaki bir köke ulaşıyor mu?
2. Geçerlilik: Zincirdeki her sertifikanın geçerlilik tarihleri içinde miyiz?
3. Kullanım: Sertifika bu iş için mi çıkarılmış? (Anahtar kullanımı ve genişletilmiş anahtar kullanımı alanları; ara CA'da CA:TRUE temel kısıtı.)
4. Ad ve iptal: Sertifika bu sunucu için mi (SAN)? İptal edilmiş mi?

Üçüncü haftada ilk ve dördüncü sorunun kodda nasıl sorulduğunu gördük (SSL_CTX_set_verify, SSL_set1_host). Bu bölümde aynı zinciri kendimiz kuruyoruz.

İşlenmiş örnek: "dört soru"yu komut satırında sormak¶

Bölüm 9'da kuracağımız kök → ara → sunucu zincirini kullanarak, bir istemcinin "dört soru"yu nasıl somut olarak sorduğunu görelim (bu üç dosya henüz elinizde değilse, Bölüm 9'u önce çalıştırın; burada yalnız aynı dosyaları farklı açılardan okuyoruz).

Soru 1 — Zincir: her sertifikanın issuer alanı, bir üsttekinin subject alanıyla birebir eşleşmeli:

openssl x509 -in sunucu.crt -noout -issuer -subject
openssl x509 -in ara.crt    -noout -issuer -subject
openssl x509 -in kok.crt    -noout -issuer -subject

issuer=CN=CEN429 Lab Ara CA     subject=CN=localhost
issuer=CN=CEN429 Lab Kok CA     subject=CN=CEN429 Lab Ara CA
issuer=CN=CEN429 Lab Kok CA     subject=CN=CEN429 Lab Kok CA

Zincir okunur: sunucu'nun issuer'ı = ara'nın subject'i; ara'nın issuer'ı = kok'un subject'i; kok'un issuer'ı kendisi (kök, kendi kendini imzalar — bu yüzden zincir burada durur).

Soru 2 — Geçerlilik:

openssl x509 -in sunucu.crt -noout -dates
openssl x509 -in sunucu.crt -noout -checkend 0

notBefore=Sep 23 06:01:46 2026 GMT
notAfter=Dec 22 06:01:46 2026 GMT
Certificate will not expire

-checkend 0, "şu andan itibaren 0 saniye içinde süresi dolacak mı?" diye sorar; TLS istemcileri bu denetimi her bağlantıda otomatik yapar.

Soru 3 — Kullanım:

openssl x509 -in sunucu.crt -noout -ext basicConstraints,keyUsage,extendedKeyUsage
openssl x509 -in ara.crt    -noout -ext basicConstraints,keyUsage

X509v3 Basic Constraints: CA:FALSE
X509v3 Key Usage: critical / Digital Signature
X509v3 Extended Key Usage: TLS Web Server Authentication
---
X509v3 Basic Constraints: critical / CA:TRUE, pathlen:0
X509v3 Key Usage: critical / Certificate Sign, CRL Sign

sunucu.crt'nin CA:FALSE olması, bu sertifikanın başka sertifika imzalayamayacağını garanti eder — bir saldırgan bu sertifikanın özel anahtarını ele geçirse bile, onunla yeni bir sertifika üretip imzalayamaz. ara.crt ise tam tersi: CA:TRUE ve pathlen:0 (altında başka bir ara CA olamaz, yalnız uç sertifika imzalayabilir).

Soru 4 — Ad: SAN alanı -ext subjectAltName ile yukarıda zaten görüldü (DNS:localhost, IP Address:127.0.0.1); istemci bağlandığı adı bu listeyle karşılaştırır (Bölüm 8'de ayrıntılı işleniyor).

Bir istemci kütüphanesi (OpenSSL, Windows CryptoAPI, Java'nın X509TrustManager'ı) bu dört soruyu sizin yerinize sorar; verify fonksiyonlarını (3. haftadaki SSL_CTX_set_verify) devre dışı bırakmak ya da hataları yutmak, bu dört sorunun hiç sorulmaması anlamına gelir.

Bir önceki bölümde imzalı DH'nin "kimin ile konuştuğumu" imza ile kanıtladığını gördük; bu bölüm o imzanın kimin imzası olduğuna nasıl güvendiğimizi (PKI, CA hiyerarşisi) açıkladı. Sıradaki iki bölüm, bu güveni taşıyan belgenin kendisine (X.509 sertifikası) ve onu elle kurmaya bakıyor.

8. X.509 sertifikasının yapısı¶

Bir X.509 v3 sertifikası, imzalanan kısım (TBSCertificate) ile CA'nın bu kısım üzerindeki imzasından oluşur:

Sertifikalar binary DER kodlamasıyla ya da onun Base64 ile sarılmış metin biçimi olan PEM ile saklanır (Tarif 7.16, 7.17): -----BEGIN CERTIFICATE----- ile başlayan dosyalar PEM'dir.

İşlenmiş örnek: gerçek bir sertifikayı alan alan okumak¶

Bölüm 9'da üreteceğimiz sunucu.crt'nin openssl x509 -text çıktısını, yukarıdaki tablodaki her alanla eşleştirerek okuyalım (bu tam olarak openssl x509 -in sunucu.crt -noout -text komutunun gerçek çıktısıdır):

Certificate:
    Data:
        Version: 3 (0x2)
        Serial Number:
            35:e2:f6:8d:d2:e3:90:f3:74:ff:16:a9:ec:5f:07:e9:21:69:76:e7
        Signature Algorithm: ecdsa-with-SHA256
        Issuer: CN=CEN429 Lab Ara CA
        Validity
            Not Before: Sep 23 06:01:46 2026 GMT
            Not After : Dec 22 06:01:46 2026 GMT
        Subject: CN=localhost
        Subject Public Key Info:
            Public Key Algorithm: id-ecPublicKey
                Public-Key: (256 bit)
                ASN1 OID: prime256v1
                NIST CURVE: P-256
        X509v3 extensions:
            X509v3 Basic Constraints:
                CA:FALSE
            X509v3 Key Usage: critical
                Digital Signature
            X509v3 Extended Key Usage:
                TLS Web Server Authentication
            X509v3 Subject Alternative Name:
                DNS:localhost, IP Address:127.0.0.1
            X509v3 Subject Key Identifier:
                EA:59:FF:05:1B:BA:D2:ED:D3:B8:2D:CF:12:32:F6:52:27:CD:98:87
            X509v3 Authority Key Identifier:
                F5:BA:39:86:1F:A1:D0:79:C8:DA:83:7D:AE:2C:87:9D:56:45:CE:25
    Signature Algorithm: ecdsa-with-SHA256
    Signature Value:
        30:46:02:21:00:8e:a3:91:48:0a:d5:8a:9d:a7:ee:08:ae:27:...

Satır satır: Version 3, uzantı alanlarını (X509v3 bloğu) kullanabildiğimizi gösterir. Serial Number, bu CA'nın çıkardığı sertifikalar arasında benzersizdir — bir sertifika iptal edildiğinde CRL'de (Bölüm 10) bu numara listelenir. Issuer (CN=CEN429 Lab Ara CA), bu sertifikayı kimin imzaladığını söyler — Bölüm 7'deki "Soru 1"in cevabı burada yazar. Validity, Bölüm 7'deki "Soru 2". Subject (CN=localhost), sertifikanın kime ait olduğunu iddia ettiği kimlik — ama bu iddiaya güvenmeden önce SAN'a bakmalısınız (aşağıda). Subject Public Key Info, bu sertifikanın doğruladığı açık anahtarın kendisi (256 bit P-256 eğrisi üzerinde bir nokta). Basic Constraints: CA:FALSE, Bölüm 7'deki "Soru 3"ün cevabı: bu sertifika başka sertifika imzalayamaz. Subject Alternative Name, Bölüm 7'deki "Soru 4"ün cevabı. Authority Key Identifier, bu sertifikayı imzalayan CA'nın açık anahtarının parmak izidir; istemci zinciri kurarken "issuer adı aynı olan ama farklı bir anahtarla imzalanmış sahte bir ara sertifika" karışıklığını bununla önler. En altta Signature Value, bütün bu alanların (TBSCertificate) üzerinde, CA'nın özel anahtarıyla üretilmiş imzadır — Bölüm 5'te öğrendiğimiz imza mekanizmasının birebir kendisi.

Sayısal örnek: sertifika kaç bayt?¶

openssl x509 -in sunucu.crt -outform DER | wc -c
wc -c sunucu.crt

DER (binary) biçim genelde 500–900 bayt civarındadır (eğri tabanlı anahtarlar RSA'dan küçük olduğu için); PEM biçimi Base64 kodlaması yüzünden bundan yaklaşık %33 daha büyüktür (Base64, her 3 binary baytı 4 metin karakterine çevirir). Bir TLS el sıkışmasında sunucunun gönderdiği sertifika zinciri (uç + ara), bu boyutların toplamıdır; RSA-3072 sertifikaları kullanan bir zincirin ECC (P-256/Ed25519) zincirinden kat kat büyük olmasının nedeni budur — Bölüm 4'teki boyut karşılaştırmasının PKI'daki yansıması.

Bölüm 7 sertifikanın taşıdığı güveni anlattı; bu bölüm o güvenin hangi baytlarda kodlandığını gösterdi. Sıradaki bölüm bu belgeyi CA rolüne geçip elle üretiyoruz.

9. OpenSSL ile sertifika zinciri kurmak¶

Aşağıdaki adımlar, kendi laboratuvarınızda üç katmanlı bir zincir kurar. Bütün dosyalar çalışma klasöründe oluşur; kök sertifikayı hiçbir güven deposuna eklemeyin.

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out kok.key
openssl req -x509 -new -key kok.key -sha256 -days 3650 -out kok.crt \
  -subj "/CN=CEN429 Lab Kok CA" \
  -addext "basicConstraints=critical,CA:TRUE" \
  -addext "keyUsage=critical,keyCertSign,cRLSign"

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out ara.key
openssl req -new -key ara.key -out ara.csr -subj "/CN=CEN429 Lab Ara CA"
openssl x509 -req -in ara.csr -CA kok.crt -CAkey kok.key -CAcreateserial -days 1825 -sha256 \
  -out ara.crt -extfile <(printf "basicConstraints=critical,CA:TRUE,pathlen:0\nkeyUsage=critical,keyCertSign,cRLSign")

openssl genpkey -algorithm EC -pkeyopt ec_paramgen_curve:P-256 -out sunucu.key
openssl req -new -key sunucu.key -out sunucu.csr -subj "/CN=localhost"
openssl x509 -req -in sunucu.csr -CA ara.crt -CAkey ara.key -CAcreateserial -days 90 -sha256 \
  -out sunucu.crt -extfile <(printf "basicConstraints=CA:FALSE\nkeyUsage=critical,digitalSignature\nextendedKeyUsage=serverAuth\nsubjectAltName=DNS:localhost,IP:127.0.0.1")

openssl verify -CAfile kok.crt -untrusted ara.crt sunucu.crt      # sunucu.crt: OK
openssl x509 -in sunucu.crt -noout -text | less                    # alanları inceleyin
openssl verify -CAfile kok.crt sunucu.crt                          # ara olmadan: HATA (zincir eksik)

Son komutun hata vermesi öğreticidir: istemci zinciri ancak ara sertifika da sunulursa kurabilir. Sunucuların yalnız uç sertifikayı gönderip ara sertifikayı unutması, sahada sık görülen bir yapılandırma hatasıdır.

Sınıf etkinliği: zinciri bozmak¶

Her adımda openssl verify çıktısını not edin:

1. Sunucu sertifikasını kök ile imzalayın ama ara CA'yı zincirde bırakın. Ne değişir?
2. Ara CA'yı CA:FALSE ile üretip sunucu sertifikasını onunla imzalayın. Doğrulama ne der?
3. -days 0 ile süresi hemen dolan bir sertifika üretin.
4. SAN'ı DNS:baska.ornek yapıp openssl s_client -verify_hostname localhost ile deneyin.

Dört sorunun (imza? köke ulaşıyor mu? süresi geçerli mi? ad uyuyor mu?) altısını — eksik ara, süresi dolmuş, yanlış kök, CA:FALSE imzalayıcı, yanlış ad ve tam zincir — aynı animasyonda deneyip 3. ve 4. senaryoyu kendiniz çözmeden önce fikir edinin:

Örnek seçicide Uç durum: sertifikanın süresi dolmuş ve Uç durum: istenen ad SAN listesinde yok yukarıdaki 3. ve 4. sorulara karşılık gelir.

İşlenmiş örnek: sınıf etkinliğinin iki senaryosunu baştan sona çözmek¶

Yukarıdaki dört senaryonun ilk ikisini birlikte çözelim; 3. ve 4. senaryoyu siz tamamlayacaksınız.

Senaryo 1 — Sunucu sertifikasını doğrudan kök ile imzalamak (ara CA'yı atlamak):

openssl x509 -req -in sunucu.csr -CA kok.crt -CAkey kok.key -CAcreateserial -days 90 -sha256 \
  -out sunucu_kok.crt -extfile sunucu.ext
openssl verify -CAfile kok.crt -untrusted ara.crt sunucu_kok.crt

sunucu_kok.crt: OK

Şaşırtıcı gelebilir: ara.crt'yi de verdiğimiz hâlde doğrulama geçti, çünkü OpenSSL zinciri sunucu_kok.crt'den doğrudan kok.crt'ye kurabildi; ara.crt bu yolda hiç kullanılmadı, sadece kullanılabilecek bir aday olarak havuzda durdu. Buradaki ders kriptografik değil operasyoneldir: matematiksel olarak kök CA, istediği her sertifikayı doğrudan imzalayabilir. Ama bunu yapmamalıyız, çünkü kök CA'nın özel anahtarı her gün kullanılan bir sistemde bulunursa (Bölüm 7'deki "neden ara CA" açıklaması), ele geçirilme riski artar ve bütün zincir çöker.

Senaryo 2 — Ara CA'yı CA:FALSE ile üretmek:

printf "basicConstraints=critical,CA:FALSE\nkeyUsage=critical,keyCertSign,cRLSign\n" > ara_yanlis.ext
openssl x509 -req -in ara.csr -CA kok.crt -CAkey kok.key -CAcreateserial -days 1825 -sha256 \
  -out ara_yanlis.crt -extfile ara_yanlis.ext

openssl x509 -req -in sunucu.csr -CA ara_yanlis.crt -CAkey ara.key -CAcreateserial -days 90 -sha256 \
  -out sunucu_yanlis.crt -extfile sunucu.ext

openssl verify -CAfile kok.crt -untrusted ara_yanlis.crt sunucu_yanlis.crt

CN=CEN429 Lab Ara CA
error 79 at 1 depth lookup: invalid CA certificate
error sunucu_yanlis.crt: verification failed

Bu kez doğrulama reddedildi — ara_yanlis.crt'nin basicConstraints'i CA:FALSE olduğu için, matematiksel imza doğru olsa bile OpenSSL bu sertifikanın başka bir sertifika imzalama yetkisi olmadığını görüyor ve zinciri "depth 1"de (aradaki katmanda) geçersiz sayıyor. Bu, Bölüm 8'deki Basic Constraints alanının davranışı fiilen değiştiren bir uzantı olduğunun kanıtıdır — süslü bir metin alanı değildir.

Senaryo 1 ile 2'yi karşılaştırın: ikisi de "yanlış" bir zincir kurar, ama biri (kök ile doğrudan imzalama) kriptografik olarak geçerlidir ve yalnız operasyonel bir hatadır; diğeri (CA:FALSE ile imzalama) protokol düzeyinde reddedilir. Bir değerlendirici PKI kurulumunuzu incelerken bu ayrımı tam olarak arar: "zincir teknik olarak çalışıyor mu" ve "zincir tasarım kurallarına uyuyor mu" iki ayrı sorudur.

10. Sertifika iptali: CRL, OCSP ve yanıt iliştirme (Tarif 10.10–10.12)¶

Bir sertifikanın özel anahtarı çalınırsa ya da sertifika hatalı çıkarılmışsa, geçerlilik süresi dolmadan iptal edilmesi gerekir. İstemcinin bunu öğrenmesinin üç yolu vardır:

# ara CA ile bir CRL üretmek için 'openssl ca' yapılandırması gerekir; sonra:
openssl ca -config ara.cnf -revoke sunucu.crt
openssl ca -config ara.cnf -gencrl -out ara.crl
openssl verify -crl_check -CAfile kok.crt -untrusted ara.crt -CRLfile ara.crl sunucu.crt   # "certificate revoked"

İşlenmiş örnek: bir sertifikayı iptal edip CRL ile doğrulamak (uçtan uca)¶

Yukarıdaki "özet" komutların tam hâlini, gerçekten çalıştırılmış olarak adım adım izleyelim. Önce openssl ca'nın ihtiyaç duyduğu minimal bir veritabanı ve yapılandırma dosyası kurulur (bu, gerçek bir CA'nın çok küçültülmüş hâlidir):

mkdir -p demoCA/newcerts
touch demoCA/index.txt          # her cikarilan/iptal edilen sertifikanin kaydedildigi "defter"
echo 1000 > demoCA/crlnumber    # bir sonraki CRL'in surum numarasi
echo 1000 > demoCA/serial       # bir sonraki sertifikanin seri numarasi

[ ca ]
default_ca = ara_ca

[ ara_ca ]
dir              = demoCA
database         = $dir/index.txt
new_certs_dir    = $dir/newcerts
certificate      = ara.crt
private_key      = ara.key
serial           = $dir/serial
crlnumber        = $dir/crlnumber
default_md       = sha256
default_days     = 90
default_crl_days = 30
policy           = policy_any
email_in_dn      = no

[ policy_any ]
commonName = supplied

openssl ca -config ara.cnf -revoke sunucu.crt

Using configuration from ara.cnf
Adding Entry with serial number 35E2F68D...76E7 to DB for /CN=localhost
Revoking Certificate 35E2F68D...76E7.
Database updated

openssl ca -config ara.cnf -gencrl -out ara.crl
openssl verify -crl_check -CAfile kok.crt -untrusted ara.crt -CRLfile ara.crl sunucu.crt

CN=localhost
error 23 at 0 depth lookup: certificate revoked
error sunucu.crt: verification failed

Adım adım ne oldu: (1) -revoke, sertifikanın seri numarasını (Bölüm 8'deki Serial Number alanı — burada 35E2F68D...76E7) index.txt defterine "iptal edildi" olarak işledi; sertifikanın kendisi hiçbir şekilde değişmedi, silinmedi — yalnız bir kayıt eklendi. (2) -gencrl, bu defterdeki bütün iptal kayıtlarını toplayıp ara CA'nın kendi özel anahtarıyla imzaladığı bir liste (ara.crl) üretti — CRL'in kendisi de bir imzalı belgedir, sahteciliğe karşı Bölüm 5'teki mekanizmayla korunur. (3) -crl_check ile doğrulama artık yalnız zinciri değil, CRL'i de kontrol etti ve seri numarasının listede olduğunu görüp "certificate revoked" hatasıyla reddetti — sertifikanın geçerlilik tarihi hâlâ dolmamış olsa bile.

Bu, Alıştırma 6'nın tam çözümüdür; kendi laboratuvarınızda aynı adımları tekrarlayıp index.txt dosyasının içeriğini (cat demoCA/index.txt) inceleyin — her satır bir sertifikanın kaydını taşır (durum, tarih, seri numarası, konu adı).

CRL'in neden bayat olabileceğini (kendi nextUpdate'i geçmişse, "iyi" demek yerine "bayat" demesi gerektiğini) ve OCSP'nin neden her zaman anlık kaldığını, aynı sertifika üzerinde iki yöntemi yan yana çalıştırarak görün:

Zor: sertifika iptal edilmiş ile Uç durum: CRL bayat — iptal görülmüyor örneklerini karşılaştırıp CRL'in önbelleklenebilirlik kazancının bedelini görün.

Sayısal örnek: CRL ne kadar büyür?¶

Bir CA yılda 10.000 sertifika çıkarıyor ve bunların %1'i (100 tanesi) iptal ediliyorsa, CRL her girişte ~40-60 bayt (seri numarası + iptal tarihi + sebep kodu) taşıdığından, CRL boyutu ~4-6 KB olur — küçük görünür. Ama büyük bir kamu CA'sı (milyonlarca sertifika, yüz binlerce iptal) için CRL onlarca megabayta ulaşabilir; her istemcinin bunu periyodik indirmesi pratik değildir. OCSP bu ölçeklenme sorununu "listenin tamamını indirme" yerine "tek bir soru sor" ile çözer — ama bu kez de yukarıdaki gizlilik ve kullanılabilirlik ödünleşimi ortaya çıkar.

Bölüm 9'da bir zincir kurmayı, bu bölümde bir zincirdeki bir halkayı geçersiz kılmayı öğrendik. Sıradaki bölüm, bu zincirin en değerli parçasını — özel anahtarların kendisini — nasıl koruduğumuzu işliyor.

11. Anahtarı donanımda saklamak: HSM, PKCS#11 ve SoftHSM¶

Özel anahtarın çalınması PKI'nin bütün güvencesini yok eder. Bu yüzden değerli anahtarlar (CA anahtarları, ödeme anahtarları, kod imzalama anahtarları) donanım güvenlik modüllerinde (HSM) üretilir ve oradan hiç çıkmaz. Uygulama anahtarı hiç görmez; HSM'e "şu anahtarla şunu imzala" der.

export SOFTHSM2_CONF=$PWD/softhsm2.conf
mkdir -p belirtecler && echo "directories.tokendir = $PWD/belirtecler" > softhsm2.conf
softhsm2-util --init-token --free --label "cen429" --pin 1234 --so-pin 5678
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so --login --pin 1234 \
            --keypairgen --key-type EC:prime256v1 --label imza-anahtari
pkcs11-tool --module /usr/lib/softhsm/libsofthsm2.so --login --pin 1234 --list-objects

Uçtan uca: bir imzalama isteği HSM içinde nasıl işlenir?¶

"Anahtar hiç çıkmaz" cümlesini somutlaştıralım. PKCS#11 standardı (OASIS Cryptoki v3), uygulamanın bir HSM'e asla ham anahtar baytı göndermeden ya da almadan imza attırmasını şu adımlarla tanımlar:

1. Oturum aç: Uygulama C_OpenSession ile HSM'deki bir "yuvaya" (slot) bağlanır.
2. Kimlik doğrula: C_Login ile PIN gönderilir; PIN yanlışsa HSM belirli bir deneme sayısından sonra kendini kilitler (kaba kuvvete karşı donanım düzeyinde koruma — yazılımda unutulması kolay bir önlem).
3. Anahtarı bul: C_FindObjectsInit / C_FindObjects ile önceden üretilmiş anahtar nesnesinin tutamacı (handle — anahtarın kendisi değil, HSM içindeki bir referans numarası) alınır.
4. İmzala: C_SignInit + C_Sign(tutamaç, veri, …) çağrısı, veriyi HSM'e gönderir; HSM veriyi kendi içinde anahtarla işler ve yalnız imzayı döndürür. Uygulama kodunun hiçbir noktasında özel anahtarın baytları belleğe hiç girmez.
5. Oturumu kapat: C_Logout / C_CloseSession.

CK_RV C_Sign(
    CK_SESSION_HANDLE hSession,   /* acik oturum */
    CK_BYTE_PTR       pData,      /* imzalanacak veri */
    CK_ULONG          ulDataLen,
    CK_BYTE_PTR       pSignature, /* HSM'in doldurdugu cikti tamponu: yalniz imza, anahtar degil */
    CK_ULONG_PTR      pulSignatureLen
);

Bu akışı normal bir OpenSSL çağrısıyla (EVP_DigestSign, Bölüm 5) karşılaştırın: ikisinin de arayüzü aynı fikri taşır ("veriyi ver, imzayı al"), ama OpenSSL'de anahtar (dosyadan okunmuşsa) süreç belleğindedir; PKCS#11'de anahtar hiçbir zaman uygulamanın adres alanına girmez. Bölüm 5'teki imza_dogrula fonksiyonunu bir HSM'e taşımak, yalnız imzalama tarafını C_Sign çağrısına yönlendirmek anlamına gelir — doğrulama tarafı zaten yalnız açık anahtar kullandığı için HSM'e ihtiyaç duymaz.

Aynı fikri küçük bir simülasyonda görün: generate_keypair() yalnız bir tutamaç döndürür, sign(tutamaç, veri) imzayı HSM'in İÇİNDE hesaplar, bilinmeyen ya da yok edilmiş bir tutamaçla imzalama reddedilir:

Zor: imza bir kulpla, doğrulama BAŞKA kulpla ile Uç durum: hiç üretilmemiş kulp örneklerini deneyin.

Neden CKA_EXTRACTABLE en kritik öznitelik?¶

Bir PKCS#11 anahtar nesnesi üretilirken (C_GenerateKeyPair), CKA_EXTRACTABLE=false ve CKA_SENSITIVE=true öznitelikleri anahtar üretilirken verilir ve sonradan değiştirilemez. Bu iki bayrak, C_WrapKey gibi bir fonksiyon çağrılsa bile HSM'in anahtarı düz metin olarak dışarı vermesini donanım düzeyinde engeller.

Yazılım tabanlı güvenlik modüllerine (mobil cihazlardaki Secure Enclave/TEE benzeri yapılar) 11. haftada bu bölümün PKCS#11 mantığıyla yeniden bakacağız; burada öğrendiğiniz "tutamaç üzerinden çalış, ham anahtarı asla taşıma" prensibi oradaki bütün tartışmanın temelidir. Sıradaki ve son teknik bölüm, bugün güvenli saydığımız RSA/ECC'nin gelecekte neden değişmesi gerektiğine bakıyor.

12. Kuantum sonrası kriptografiye bakış¶

Yeterince büyük bir kuantum bilgisayar, RSA'nın ve eliptik eğrilerin dayandığı matematiksel problemleri (çarpanlara ayırma, ayrık logaritma) verimli biçimde çözebilir. Böyle bir bilgisayar henüz yoktur; ama bugün kaydedilen şifreli trafiğin yıllar sonra çözülebileceği ("şimdi topla, sonra çöz") düşüncesi, geçişi bugünden gündeme getirir.

Bu dersin projesi için pratik sonucu tek cümledir: kripto çevikliği (crypto agility). Algoritma adlarını kodun her yerine gömmeyin; anahtar sürümü ve algoritma kimliği taşıyan biçimler (3. haftadaki anahtar sürümü alanı) kullanın ki algoritma değiştiğinde yalnız yapılandırma ve yeniden şifreleme gereksin.

İşlenmiş örnek: kuantum sonrası anahtarları bugünden üretmek¶

OpenSSL 3.5, standartlaşan kuantum sonrası algoritmaları doğrudan destekler; bunları bugün, kendi makinenizde üretip boyutlarını klasik algoritmalarla karşılaştırabilirsiniz:

openssl genpkey -algorithm ML-KEM-768 -out mlkem.pem
openssl pkey -in mlkem.pem -pubout -out mlkem_pub.pem
wc -c mlkem_pub.pem

openssl genpkey -algorithm ML-DSA-65 -out mldsa.pem
openssl pkey -in mldsa.pem -pubout -out mldsa_pub.pem
echo hello > belge.txt
openssl pkeyutl -sign -inkey mldsa.pem -rawin -in belge.txt -out belge.mldsa.sig
wc -c mldsa_pub.pem belge.mldsa.sig
openssl pkeyutl -verify -pubin -inkey mldsa_pub.pem -rawin -in belge.txt -sigfile belge.mldsa.sig

1714 mlkem_pub.pem
2770 mldsa_pub.pem
3309 belge.mldsa.sig
Signature Verified Successfully

Bölüm 4'teki tabloyla karşılaştırın:

Fark çarpıcıdır: ML-DSA-65'in açık anahtarı Ed25519'unkinden ~24 kat, imzası ~52 kat büyüktür. Bu, PQC'ye geçişin yalnız "algoritma adını değiştirmek" olmadığını gösterir — TLS el sıkışması, sertifika boyutu, ağ paket sayısı gibi pek çok yer bu büyümeyi hesaba katmalıdır. NIST'in TLS için önerdiği karma (hybrid) yaklaşım (X25519MLKEM768 gibi, Bölüm 6'daki X25519 anlaşmasının PQC ile birlikte çalıştırılan hâli) tam olarak bu geçiş maliyetini yönetmek içindir: klasik ve PQC anahtarları aynı anda kullanılır; klasik taraf kırılırsa PQC, PQC tarafı (henüz kanıtlanmamış yeni matematik) kırılırsa klasik taraf korumayı sürdürür.

Neden kafes problemleri? Kısa bir sezgi¶

RSA'nın güvenliği "büyük bir sayıyı çarpanlarına ayırmanın zorluğuna", ECC'nin güvenliği "bir eğri üzerinde ayrık logaritma almanın zorluğuna" dayanır — Shor algoritması, yeterince büyük bir kuantum bilgisayarda her ikisini de verimli çözer. ML-KEM ve ML-DSA, bunun yerine kafes (lattice) problemlerine dayanır: çok boyutlu bir uzayda, düzenli aralıklarla dizilmiş noktalardan (kafes) oluşan bir yapıda, "verilen bir noktaya en yakın kafes noktasını bulmak" ya da "bir denklem sistemini küçük hata terimleriyle çözmek" (Learning With Errors, LWE) yüksek boyutlarda hesaplama açısından çok zordur ve bugüne kadar ne klasik ne kuantum bilgisayarlar için verimli bir çözüm bulunmuştur. "Bugüne kadar bulunamamış olması", "asla bulunamayacağı" anlamına gelmez — bu yüzden karma yaklaşım öneriliyor.

Bu bölüm, Bölüm 1'de çizdiğimiz haritanın son durağıydı: hangi algoritma, hangi problem, ne kadar güvenli, ne zamana kadar. 13. bölümden itibaren bu bilgiyi kendi projenizin algoritma envanterine döküyorsunuz.

13. Dönem projesi: bu hafta¶

Final kontrolünde beklenen S8 ve S11 bölümlerinin taslağını yazın:

• S8 — Algoritma envanteri: projenizde kullanılan her algoritma için amaç, anahtar uzunluğu, kip, dayandığı standart ve kütüphane. Tabloda eskimiş bir algoritma varsa gerekçesi ve geçiş planı.
• S8 — Anahtar yaşam döngüsü tablosu: her anahtar için üretildiği yer, saklandığı yer, kripto-periyot, yenileme ve imha (3. hafta).
• S11 — Güvenli iletişim: TLS sürümü ve doğrulama; sabitleme varsa SPKI ve yedek pin; mesaj düzeyi koruma.
• Projenizde bir güncelleme ya da yapılandırma dosyası varsa, imza doğrulamasını ekleyin (Ed25519 önerilir) ve sürüm geri almayı reddedin.
• İsteğe bağlı: projenizin test sertifikaları için bu haftanın kök → ara → uç zincirini kullanın; kök anahtarı depoya koymayın.

İşlenmiş örnek: S8 tablosunu bir örnek bileşen için doldurmak¶

Boş bir tablo karşısında ne yazılacağı belirsiz kalabilir; örnek bir proje bileşeni ("kullanıcı oturum belirteci üretimi") için S8'in nasıl doldurulacağını görelim — kendi projenizde satırları kendi bileşenlerinizle değiştirin:

Anahtar yaşam döngüsü tablosu (3. haftadaki anahtar yönetimi konusunun bu haftaki karşılığı) aynı bileşen için:

Bu iki tablo, bu haftanın 1–12. bölümlerinde gördüğünüz her kavramı ("hangi kip", "hangi standart", "nerede saklanır", "ne zaman yenilenir") tek bir yerde toplar — final kontrolünde değerlendirici tam olarak bu iki tabloyu arar.

14. Kendi başına çalış¶

15. Kendini sınama¶

16. Kaynaklar ve ileri okuma¶

Ders kitabı — J. Viega, M. Messier, Secure Programming Cookbook for C and C++, O'Reilly, 2003:

• Tarif 5.2–5.4 (algoritma, anahtar uzunluğu ve kip seçimi), 5.11 (dolgu), 5.16 (hata yapmaya dirençli API)
• Tarif 6.3–6.4 (özet ve MAC seçimi), 6.10 (HMAC), 6.18 (şifreleme ve bütünlüğün birleştirilmesi), 6.19 (kendi MAC'ini yapma — uyarı), 6.21 (yeniden oynatmaya karşı MAC)
• Tarif 7.1–7.3 (açık anahtar kullanımı ve seçimi), 7.10–7.14 (RSA şifreleme, imza ve güvenli birleştirme), 7.16–7.17 (DER ve PEM)
• Tarif 8.15–8.19 (parola tabanlı anahtar değişimi, RSA ile kimlikli anahtar değişimi, Diffie–Hellman, DH + imza, PKI'siz doğrulama)
• Tarif 10.1, 10.4–10.5 (PKI ve X.509 doğrulama), 10.10–10.12 (CRL ve OCSP)

Açık standartlar ve kaynaklar

• NIST SP 800-57 Part 1 (anahtar yönetimi ve güvenlik düzeyleri), SP 800-131A (algoritma geçişleri), SP 800-38A/D (kipler, GCM), FIPS 186-5 (dijital imza), FIPS 203/204/205 (kuantum sonrası).
• RFC 2104 (HMAC), RFC 8017 (PKCS#1 v2.2: OAEP, PSS), RFC 8032 (Ed25519), RFC 7748 (X25519), RFC 5280 (X.509 ve CRL), RFC 6960 (OCSP), RFC 6979 (deterministik ECDSA), RFC 8446 (TLS 1.3).
• OASIS PKCS#11 v3; SoftHSM belgeleri; OpenSSL 3 kılavuz sayfaları (genpkey, req, x509, verify, ca, pkeyutl).
• MITRE CWE: CWE-327 (kırık algoritma), CWE-326 (yetersiz anahtar uzunluğu), CWE-295 (yanlış sertifika doğrulama), CWE-299 (iptal denetimi eksik), CWE-347 (imzanın yanlış doğrulanması), CWE-294 (yeniden oynatmayla kimlik atlatma).