Bugünün planı (3 saat)

Öğrenme çıktıları: ÖÇ.2 (şifreleme, güvenli iletişim) · ÖÇ.4 (güvenli kanal)

Önceki haftalardan gelenler

• Beyaz kutu saldırgan modeli — cihazın/sunucunun sahibi aynı zamanda olası saldırgandır; belleği okuyabilir, hata ayıklayıcı bağlayabilir (Hafta 1)
• Bellekten güvenli silme — bir sırrı explicit_bzero/OPENSSL_cleanse ile, derleyicinin kaldıramayacağı biçimde silmek (Hafta 1)
• Entropi ölçümü — bir dosyanın baytlarındaki düzensizliği ölçüp şifreli/paketli içeriği ayırt etmek (Hafta 2)

Bu hafta: beyaz kutu modeli → kullanımda veri ve whitebox; entropi → rastgele üretecin girdisi.

Demolar nasıl çalışıyor?

• Tek kaynak, iki platform: Windows (Visual Studio 2022) ve WSL/Linux (GCC)
• Kripto ortak başlıktan: Linux → OpenSSL, Windows → BCrypt (CNG) — OpenSSL kurmaya gerek yok
• Derle: Windows .\build.ps1 · WSL ./build.sh
• Çalıştır: Windows .\demo.ps1 · WSL sh demo.sh
• Binary dosyalar her demonun bin\windows / bin/linux klasöründe

⚠️ Etik: ağ yalnız localhost; sertifikalar bizim; teknikleri yalnız kendi
bilgisayarınızda deneyin.

Neden veriye odaklanıyoruz?

• İlk iki hafta "hata → saldırı → düzeltme" ile programın kendisini koruduk.
• Bu hafta odak veriye kayıyor: parola, ödeme anahtarı, kişisel bilgi.
• Bir sır, yaşam döngüsü boyunca üç ayrı hâlde bulunur.
• Her hâlin tehdidi de savunması da farklıdır.

Bir sırrın üç hâli

Her hâlin tehdidi de savunması da farklı. Hepsini birden düşünmek gerekir.

Üç hâl — tek bakışta

Örnek mimari: telefon ↔ sunucu

• Telefon: güvenilmez ortam — kullanıcı (yani olası saldırgan) cihazın sahibi; root/hata ayıklayıcı olabilir.
• Sunucu: güvenilir taraf.
• Her arayüzde sorulur: hangi veri, hangi hâlde, kimlik nasıl doğrulanıyor, gizlilik mi bütünlük mü?

Kriptografinin dört ailesi — şema

Kriptografi tek şey değildir

• Şifreleme, kısaca: açık metni bir anahtarla okunamaz şifreli metne çevirmek; çözme aynı/eşleşen anahtarla tersine çevirir; güvenlik anahtarın gizliliğine dayanır.
• Farklı hedefler için farklı araçlar vardır.
• En sık karıştırılan dört aile: şifreleme, özet, MAC, imza.
• Hangisi gizlilik, hangisi bütünlük, hangisi ikisi birden verir?

En sık yapılan iki hata

1. Yalnız şifrelemek, bütünlüğü unutmak. Şifreli metin (ör. AES-CTR) saldırganın fark edilmeden bit değiştirmesini engellemez.
2. Kendi şifreni/kipini yazmak. Kerckhoffs ilkesi: güvenlik algoritmanın değil anahtarın gizliliğine dayanır.

Standart, denenmiş yapıları kullanın; ev yapımı kripto neredeyse her zaman kırılır.

Simetrik neden tek başına yetmez?

• Simetrik (AES): çok hızlı.
• Ama iki tarafın aynı gizli anahtarı bilmesi gerekir.
• Bu anahtarı güvensiz bir ağdan nasıl paylaşırsınız?

Cevap bir sonraki slaytta.

Asimetrik neyi çözer, neye mal olur?

• Asimetrik (RSA/EC): herkesin bir açık (dağıtılır) ve bir özel (gizli) anahtarı var.
• Anahtar dağıtımı sorununu çözer.
• Ama işlemler yavaştır; büyük veriye uygun değil (100–1000× yavaş).

Hibrit: ikisi birlikte

• Hibrit: asimetrik ile küçük bir simetrik anahtar taşınır; veri onunla AEAD'le şifrelenir.
• Gerçek sistemler hep böyle çalışır.

TLS tam olarak budur: ECDHE ile oturum anahtarı → trafik AES-GCM ile.

Blok şifre nedir?

• Blok şifre: veriyi sabit boyutlu bloklar halinde şifreleyen algoritma.
• AES: tek seferde 16 baytlık bir bloğu şifreler.
• Bloktan uzun veri için bir kip (mode of operation) gerekir.

Blok mü, akış mı? Kip önemli

AES bir blok şifresidir (16 bayt). Uzun veri için kip gerekir:

ChaCha20: akış şifre

• Akış şifresi: blok kavramı yok; veriyle aynı uzunlukta bir anahtar akışı üretip XOR'lar.
• ChaCha20 zaten akış şifresidir.
• + Poly1305 MAC = AEAD (ChaCha20-Poly1305, RFC 8439).

Sonuç aynı: gizlilik + bütünlük tek pakette.

Özet (hash): tek yönlü parmak izi

• Anahtarsızdır. Yalnız verinin değişip değişmediğini gösterir.
• Saldırgan veriyi değiştirip özeti de yeniden hesaplayabilir.
• Bu yüzden özet tek başına bütünlük kanıtı değildir.
• Eski MD5/SHA-1 çakışmaya açık; SHA-256/SHA-3 kullanın.

MAC: paylaşılan anahtarla bütünlük

• MAC (ör. HMAC-SHA-256): paylaşılan gizli anahtar ister.
• "Bu mesajı, anahtarı bilen biri gönderdi ve değişmedi" der.
• İki taraf da anahtarı bildiği için MAC inkâr edilemezlik sağlamaz.
• MAC karşılaştırması sabit zamanlı olmalı (CRYPTO_memcmp), düz memcmp değil.

İmza: inkâr edilemezlik

• Dijital imza (Ed25519, RSA-PSS): açık/özel anahtar çiftiyle çalışır.
• Yalnız özel anahtar sahibi imza üretebilir; herkes açık anahtarla doğrular.
• Bu yüzden inkâr edilemezlik sağlar.
• Sertifikalar ve sürüm imzalama (Hafta 10) bununla çalışır.

Özet / MAC / İmza: hangisi ne zaman?

⚠️ Özet tek başına bütünlük kanıtı değildir (saldırgan özeti de yeniler).

AEAD çoğu zaman doğru cevaptır

• Ayrı ayrı "şifrele + MAC ekle" kurmak yerine AEAD kullanın.
• İki işi tek çağrıda, doğru sırada (encrypt-then-MAC) ve daha az hatayla yapar.
• Ayrı MAC yalnız şifrelenmeyecek ama bütünlüğü gereken veriler için (ya da AEAD'nin AAD alanıyla) gerekir.

Demo 1 nedir?

• Demo 1 · code/week-03/01-aes-gcm-file — AEAD, NIST SP 800-38D.
• Bir dosyayı AES-256-GCM ile şifreler.
• Çıktı biçimi: [12 bayt nonce][şifreli metin][16 bayt etiket].
• Sonra şifreli metnin ve yalnız etiketin bir baytını bozup çözmenin reddedildiğini görüyoruz.

Demo 1 — kod

crypto_random(nonce, 12);                /* her mesaja YENI nonce */
crypto_gcm_encrypt(key, nonce, 12, NULL, 0,
                   plain, plain_len, ct+12, tag);
int ok = crypto_gcm_decrypt(key, nonce, 12, NULL, 0, ct, ct_len, tag, plain);
if (!ok) { /* REDDET */ }

Demo 1 — gerçek çıktı

STEP 3  Decrypted and VERIFIED (54 bytes)
STEP 4  ciphertext byte changed -> VERIFICATION FAILED, REJECTED
STEP 5  only the tag changed -> REJECTED

Demo 1 — ADIM 2 ve 3: nonce, doğru çözme

• ADIM 2: Rastgele 12 baytlık bir nonce üretildi, dosyanın başına yazıldı.
• Nonce gizli değildir (dosyada açık durur); yalnız benzersiz olması gerekir.
• ADIM 3: Aynı anahtar ve nonce ile çözüldü, etiket tuttu, düz metin geri geldi.

Tuz, IV, nonce — şema

Demo 1 — ADIM 4 ve 5: kurcalama → red

• ADIM 4: Şifreli metnin 20. baytı XOR ile değiştirildi. GCM etiketi bütün şifreli metin üzerinde hesaplandığı için tek bayt bile etiketi bozar → çözme reddedildi.
• ADIM 5: Bu kez yalnız etikete dokunuldu; yine reddedildi.
• Etiket, veriyle ve anahtarla birlikte hesaplanır; saldırgan onu anahtarsız üretemez.

Demo 1 — kural

✅ Bir şey şifreliyorsan AEAD kullan (AES-GCM / ChaCha20-Poly1305)
✅ Her mesaja benzersiz nonce
✅ Etiketi her zaman doğrula; başarısızsa hiçbir çıktı üretme (fail-closed)
✅ Bütünlüğü ayrı adıma bırakma

AES-GCM: şifreleme ve etiket doğrulama (animasyon)

AES-GCM — uç durum: şifreli metin kurcalandı

Üç tür rastgelelik — şema

Neden rastgelelik bu kadar önemli?

• Anahtar, IV, nonce, tuz, oturum kimliği — hepsi tek bir varsayıma dayanır: tahmin edilemezlik.
• Dünyanın en iyi şifreleme algoritması, anahtarı tahmin edilebilir bir üreteçle oluşturulmuşsa hiçbir şey korumaz.
• Bu bölümde önce yanlış yollara, sonra doğru yola bakacağız.

Hata 1 — zamanla tohumlamak

srand(time(NULL));
unsigned char key[16];
for (int i = 0; i < 16; i++)
    key[i] = rand() & 0xFF;

Saldırgan anahtarın hangi gün üretildiğini biliyorsa, olası tohum sayısı bir günde yalnız 86.400. Bir dizüstü bilgisayar hepsini saniyeler içinde dener.

Hata 2 — entropiyi yanlışlıkla silmek

Debian OpenSSL felaketi (2008): bir paketleyici, bir uyarıyı susturmak için OpenSSL'in rastgele sayı havuzuna entropi ekleyen iki satırı kaldırdı.

• İki yıl boyunca tek entropi kaynağı süreç kimliği (≤ 32.768 değer) oldu.
• Saldırganlar bütün olası anahtarları önceden üretip listeledi (CVE-2008-0166).

Dört yaygın yanlış anlama — şema

Hata 2 — çıkarım

➡️ Kriptografik koda anlamadan dokunmayın.

➡️ Rastgele üretecin çıktısını istatistiksel olarak test etmek, tahmin edilemezliğini kanıtlamaz.

Hata 3 — aralığa indirgerken sapma

r % 6 masum görünür. r 0–255 tekdüze ise:

256 = 42*6 + 4

• 0–3 değerleri 43'er kez, 4–5 değerleri 42'şer kez çıkar.
• Zar için önemsiz; parola/OTP üretirken tahmin edilebilirliği artırır.
• Doğru yöntem: reddetme (rejection sampling) — sonraki slaytta.

Dönüş değerini neden denetlemeli?

• Rastgele üreteç başarısız olabilir.
• Denetlenmezse tampon ilklendirilmemiş (ya da sıfır) kalır.
• Program "rastgele" sandığı sabit bir anahtarla çalışmaya devam eder.
• Hata durumunda tek doğru davranış: işlemi durdurmak.

Reddetme yöntemiyle sapmasız aralık

uint32_t random_in_range(uint32_t upper) {        /* Tarif 11.11 */
    uint32_t threshold = (uint32_t)(-upper) % upper, r;   /* 2^32 mod upper */
    do random_bytes(&r, sizeof r); while (r < threshold);
    return r % upper;
}

Fikir: 2³² değerin, upper'a tam bölünen en büyük kısmını kullan, kalanı at.

AEAD: dört girdi, iki çıktı

AAD: şifrelenmez ama değiştirilirse etiket tutmaz — dosya başlığı, sürüm, kayıt kimliği

1. haftadaki "Kasa": türetme parametreleri AAD → yineleme sayısı değiştirilemez

Şimdi kripto API'sinin içini açıyoruz

• Demo 1'de işi hazır yardımcı fonksiyonlara bıraktık.
• Şimdi OpenSSL'in EVP arayüzünü satır satır yazıyoruz.
• Amaç: kütüphaneyi kullanırken nerede hata yapılabileceğini görmek.
• Kural hâlâ geçerli: kendi algoritmanı yazmazsın, ama hazır algoritmayı doğru çağırmak da bir beceridir.

EVP şifreleme — Adım 1: algoritmayı seç

EVP_EncryptInit_ex(ctx, EVP_aes_256_gcm(), NULL, NULL, NULL);

• Algoritmayı seç (AES-256-GCM).
• Anahtarı ve nonce'u henüz verme — sıradaki adımda.

EVP şifreleme — Adım 2: nonce boyu

EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, 12, NULL);

• Nonce (IV) uzunluğunu ayarla.
• GCM için önerilen 12 bayt; varsayılan da budur ama açık yazmak iyi bir alışkanlıktır.

EVP şifreleme — Adım 3: anahtar + nonce

EVP_EncryptInit_ex(ctx, NULL, NULL, key, nonce);

• Anahtarı ve nonce'u şimdi ver.
• İlk Init çağrısında NULL bırakılan yerler burada doldu.

EVP şifreleme — Adım 4: AAD

EVP_EncryptUpdate(ctx, NULL, &n, aad, aad_n);

• AAD'yi ver: çıktı tamponu NULL.
• AAD şifrelenmez, yalnız etikete katılır (dosya başlığı, sürüm, kayıt kimliği).

EVP şifreleme — Adım 5: veriyi şifrele

EVP_EncryptUpdate(ctx, ciphertext, &n, plain, plain_n);

• Açık metni şifrele.
• Büyük veride bu adım parça parça tekrarlanabilir.

EVP şifreleme — Adım 6: bitir (ZORUNLU)

EVP_EncryptFinal_ex(ctx, ciphertext + n, &n);

• GCM akış kipinde çalıştığı için dolgu yoktur; bu çağrı genelde 0 bayt yazar.
• Ama çağrılması zorunludur: etiket burada hesaplanır.

EVP şifreleme — Adım 7: etiketi al

EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG, 16, tag);

• Etiketi al ve şifreli metinle birlikte sakla.

Çözme — adım 1-2: aç, etiketi ayarla

EVP_DecryptUpdate(ctx, plain, &n, ciphertext, ciphertext_n);  /* WRITES the plaintext... */
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_TAG, 16, tag);  /* BEFORE Final */

• DecryptUpdate açık metni hemen tampona yazar — henüz doğrulanmadı!
• Beklenen etiket Final'dan önce verilir.

Sabit zamanlı karşılaştırma

unsigned char diff = 0;
for (size_t i = 0; i < n; i++) diff |= a[i] ^ b[i];   /* always walk every byte */
return diff == 0;                                     /* ≈ CRYPTO_memcmp */

memcmp ilk farklı baytta durur; süre kaç baytın doğru olduğunu sızdırır. Hazır karşılıklar: CRYPTO_memcmp, sodium_memcmp.

Sahada: algoritma envanteri

• Gerçek ürün kılavuzlarında bir algoritma envanteri bulunur: her algoritma, hangi amaçla, hangi anahtar boyuyla.
• İyi bir eleştirel okuma malzemesi: eski envanterlerde SHA-1 ya da ayrı MAC'li CBC görülür.
• Bugün yazılan bir envanterde yerini SHA-256 ve AEAD almalı.

Değerlendirici nasıl test eder?

• Algoritma envanterini kaynak kodla karşılaştırır.
• Nonce üretimini ve tekrarını inceler.
• Şifreli veriyi bir bit değiştirerek geri verir; uygulamanın reddettiğini ve ayrıntılı hata vermediğini doğrular.
• MAC karşılaştırmasında memcmp arar.

Üçü de gizli DEĞİL, ama...

Gizli olan tek şey anahtardır.

Demo 2 — nonce tekrarı sızdırır

BAD CASE (same nonce):
  C1 xor C2 = 151b00000f4b42030906070d16000807 ... 44404015
  P1 xor P2 = 151b00000f4b42030906070d16000807 ... 44404015     <-- SAME = leaked
  P2 = (C1 xor C2) xor P1 = "Total balance is 45000, PIN is 1234"

GOOD CASE (different nonce):
  C1 xor C2 != P1 xor P2            <-- no leak

✅ Nonce'u rastgele ya da kalıcı sayaç olarak üret; asla tekrar etme.

Demo 2 — kural (devamı)

• Rastgele nonce pratiktir; ama aynı anahtarla çok mesaj varsa (NIST önerisi: ≤ 2³²) doğum günü olasılığı devreye girer.
• Alternatif: nonce'u sayaç yap — ama sayaç kalıcı saklanmalı (cihaz yeniden başlayınca sıfırlanmamalı).
• Gerçek olaylar: WEP kısa IV, Sony PS3 ECDSA'da tekrar eden rastgele değer (özel anahtar çıkarıldı).

Nonce tekrarının tehlikesi (animasyon)

Nonce tekrarı — uç durum: farklı nonce, sızıntı yok

Demo 3 — ECB deseni sızdırır ("penguen")

Original        AES-128-ECB          AES-256-GCM
########        ================     : -..--+%%*-:*
#  ##  ##       =##==####====##      *.#*##:*%+###:
#  #####        =##=====##==###      :+ .- .% +.#%=
########        ================     =%+## #:###%+%

❌ ECB: aynı blok → aynı şifreli blok, şekil okunur kalır
✅ GCM/CTR: her blok farklı → gürültü

ECB — kural

✅ ECB kullanmayın. Şifreleme için AEAD (GCM, ChaCha20-Poly1305); disk için XTS-AES.

Kod incelemesinde ecb geçen her yer bir bulgudur. Değerlendirici aynı düz metnin tekrar eden 16 baytlık bloklarını arayarak ECB'yi otomatik yakalayabilir.

Bu bölümün kuralı

• Tuz, IV, nonce: hiçbiri gizli değil, ama her biri farklı bir tekrarsızlık ister.
• Nonce asla aynı anahtarla tekrar etmesin.
• ECB yasak. Kip seçimi = güvenlik kararı.

ECB deseni sızdırır, GCM sızdırmaz (animasyon)

ECB — uç durum: dama tahtası

Paroladan anahtar türetme — şema

Parola neden doğrudan anahtar olamaz?

• Parola kısa, düşük entropili ve tahmin edilebilir.
• Doğrudan anahtar yapılırsa kaba kuvvet ucuzlaşır.
• Çözüm: paroladan anahtar türetme fonksiyonu (KDF).
• Genel olarak KDF: yalnız paroladan değil, bir ana sırdan da anahtar türetilebilir — bunu 6. bölümde (HKDF) görüyoruz.

KDF iki iş yapar

1. Tuz: rastgele → rainbow tablo işe yaramaz, aynı parola fark edilmez
2. Yavaşlık: yüzbinlerce tur → her deneme pahalı, kaba kuvvet yavaşlar

Demo 4 — tur sayısı, süre, tuz

1) SALT: same password + same salt -> SAME key
         same password + DIFFERENT salt -> DIFFERENT key
2) ROUNDS vs TIME (WSL):
   rounds =   1000  ->    0.37 ms
   rounds = 100000  ->   39.05 ms
   rounds = 600000  ->  209.55 ms   <-- OWASP 2023 minimum
   rounds =2000000  ->  628.42 ms

Demo 4 — tuzun etkisi

• Aynı parola + aynı tuz → her seferinde aynı anahtar.
• Tuz sabitse saldırgan bir kez tablo kurup herkesi arayabilir.
• Aynı parola + farklı tuz → tamamen farklı anahtar.

➡️ Tuz her kayıt için rastgele ve benzersiz olmalı.

Demo 4 — maliyetin etkisi

• Tur sayısı 1.000 → 2.000.000 olunca süre ~0,4 ms → ~628 ms'ye çıktı.
• Bu doğrudan çarpandır: saldırganın her denemesi de o kadar pahalılaşır.
• "Kullanıcı girişinde 200 ms" kabul edilebilir; saldırgana milyarlarca deneme yerine binlerce deneme demektir.

Demo 4 — kural

✅ Rastgele tuz + Argon2id (ya da yüksek turlu PBKDF2). ❌ Düz/tuzsuz SHA-256.

İleri: biber (pepper)

• Tuza ek olarak, veritabanında saklanmayan, yapılandırmada ya da HSM'de tutulan gizli bir biber eklenebilir.
• DB çalınırsa (biber sızmadıkça) özetler bir kat daha korunur.
• Tuz gizli değildir; biber gizlidir.

Bu bölümün kuralı

• Parolayı asla doğrudan anahtar yapma.
• Rastgele tuz + yeterli maliyetli bir KDF (Argon2id öncelikli).
• Maliyeti donanıma göre ayarla, yıllar içinde artır.

Paroladan anahtar türetme: tuz ve tur (animasyon)

PBKDF2 — uç durum: tek tur

Neden ana sırdan direkt kullanmıyoruz?

• Uzun ömürlü bir "ana sır" doğrudan kullanılmaz.
• Ondan, her amaç ve her oturum için ayrı anahtarlar türetilir.
• Araç: HKDF (RFC 5869) — iki aşamalı bir KDF.

HKDF Adım 1: Extract

• Girdi: ana sır + tuz.
• Çıktı: tekdüze bir ara anahtar (PRK).
• Amaç: ham sırdaki düzensizliği tek biçim bir anahtara sıkıştırmak.

HKDF Adım 2: Expand

• Girdi: PRK + info etiketi.
• Çıktı: istenen boyda anahtar.
• Farklı info → farklı anahtar. Aynı PRK'dan şifreleme anahtarı, MAC anahtarı, oturum anahtarı ayrı ayrı çıkar.

İleri gizlilik (forward secrecy) nedir?

• İleri gizlilik: bugünkü anahtar sızsa bile eski oturumlar çözülemez.
• Tek yönlü zincir: K0 = ana sır, Kᵢ = HKDF(Kᵢ₋₁).
• Her adımda eskisini sil.

İleri gizlilik — şema

Bugünkü anahtar sızsa bile eski oturumlar güvende. TLS 1.3'te varsayılan (geçici ECDHE ile).

Demo 5 — HKDF çıktısı

info='...encryption...' -> 5a5ed417c87e3566...0d37002cb
info='...MAC...'        -> 4c63a348654a076c...0ce1750e6   (different)

FORWARD SECRECY chain:
  K1=cbbe8fdd0b6ca8be  K2=1113abf7352881e0
  K3=a99c7ad8e0e6fb6b  K4=4974f0e86d9dcb37
  ^ the old key is wiped at every step

Demo 5 — açıklama

• Aynı ana sırdan farklı info ile farklı anahtarlar çıktı; bir amacın anahtarı başka amaca kullanılamaz.
• İleri gizlilik zincirinde her adımda eski anahtar silindi.
• Elde yalnız K4 var; zincir tek yönlü olduğu için K4'ten K3, K2, K1 geri hesaplanamaz.

Demo 5 — kural

✅ Amaca/oturuma göre ayrı anahtar · her türetmeye benzersiz info · kullanınca sil.

Bu bölümün kuralı

• Ana sırdan amaca ve oturuma göre ayrı anahtarlar türetin.
• Her türetmeye benzersiz bir info/label koyun.
• Kısa ömürlü oturum anahtarlarını kullanınca silin.

HKDF: Extract/Expand ve ileri gizlilik (animasyon)

HKDF — uç durum: tek adımlık zincir

Algoritma mı kırıldı, anahtar mı kötü yönetildi?

• "Algoritma kırıldı" diye haber yapılan olayların çok küçük bir kısmı gerçekten algoritmanın kırılmasıdır.
• Büyük çoğunluk anahtar yönetimi hatasıdır: koda gömülü anahtar, hiç değişmeyen anahtar, tek anahtarla her iş.
• Bu bölüm bu hataları önlemek için var.

Kripto-periyot nedir?

• Bir anahtarın kullanılmasına izin verilen süre.
• Süre dolunca anahtar yeni veriyi şifrelemek için kullanılmaz.
• Eski veriyi çözmek için bir süre daha tutulabilir.
• Etkenler: korunan verinin miktarı, gizli kalması gereken süre, anahtarın ne kadar açıkta durduğu.

Anahtarın hayatı — şema

Anahtar hiyerarşisi: iki temel fikir

1. Anahtar ayrımı: farklı amaçlar için farklı anahtarlar (HKDF info ile).
2. Zararın sınırlanması: alt düzeydeki bir anahtarın ele geçirilmesi yalnız o dalı etkiler.

Anahtar hiyerarşisi

• Anahtar ayrımı: her amaca ayrı anahtar (HKDF info)
• Zarar sınırlama: tek kullanımlık anahtar çalınırsa kaybedilen = tek işlem

Ödemede hiyerarşi ve anahtar yenileme

EMV tarzı zincir:

Kurum ana anahtarı (HSM) → kart ana anahtarı (kart no + sıra no) → oturum anahtarı (işlem sayacı) → tek kullanımlık anahtar

• Telefona yalnız en alttaki sınırlı kullanım anahtarları iner
• Tükenince sunucudan yenileri istenir (replenishment)
• Telefon ele geçse bile: birkaç işlemlik anahtar, sunucuda kolayca iptal

Zarflama (envelope encryption) — neden?

Büyük veriyi doğrudan ana anahtarla şifrelemek iki sorun yaratır:

• Ana anahtar sık kullanılır → açıkta kalma süresi artar.
• Anahtar değişince bütün veri yeniden şifrelenmelidir.

Zarflama — dört adım

1. Her kayıt için rastgele bir veri anahtarı (DEK) üretilir; veri onunla şifrelenir.
2. DEK, bir anahtar şifreleme anahtarıyla (KEK) sarılır.
3. KEK güvenli bir yerde durur: TPM, HSM, bulut KMS.
4. KEK yenilendiğinde yalnız küçük DEK'ler yeniden sarılır — veri değil.

Kayıt biçimi ve AAD — şema

Oturum anahtarı: bugünkü öneri

Bu bölümün kuralı

• Anahtarları bir hiyerarşi içinde düzenleyin; her anahtarın tek amacı ve bir kripto-periyodu olsun.
• Veriyi zarflayın; anahtar sürümünü AAD ile koruyun.
• İstemci cihazına yalnız zararı sınırlı, kısa ömürlü anahtarlar indirin.

TLS 1.3 el sıkışması: mesaj sırası (animasyon)

El sıkışma — uç durum: yarıda kesilen

Doğrulamanın üç katmanı

⚠️ OpenSSL varsayılanı: doğrulamaz! SSL_VERIFY_PEER + SSL_set1_host şart.

Sabitleme (pinning) ve TOFU

• Pinning: sunucunun açık anahtarının (SPKI) SHA-256'sını göm. Zincir
  geçerli olsa bile anahtar tutmuyorsa REDDET. (Mobilde yaygın.)
• TOFU: PKI yoksa ilk anahtarı hatırla, değişirse uyar (SSH modeli).

TLS 1.2 → 1.3: tek RTT · yalnız güçlü AEAD takımları · zayıf özellikler kaldırıldı
· downgrade'e karşı minimum sürüm zorla.

Sertifika sabitleme: birincil, yedek, uyuşmazlık (animasyon)

Sabitleme — uç durum: hiçbir pinle eşleşme yok

Demo 6 — MITM → hostname + pinning

1 Insecure  -> ATTACKER: ACCEPTED (DANGEROUS, MITM would work)
2 Verify    -> REAL     : VERIFIED, ACCEPTED
3 Verify    -> ATTACKER : REJECTED (self-signed)
4 Pin       -> REAL     : pin MATCHED, ACCEPTED
5 Pin       -> ATTACKER : pin did NOT match, REJECTED

Yalnız 127.0.0.1, kendi ürettiğimiz sertifikalar. (Windows: WSL'de çalıştırın.)

"Yalnız TLS'e güvenmeme"

• TLS kanalı korur ama uç noktalar güvenilmez olabilir (kök alınmış telefon,
  hatalı pinning)
• Yüksek güvenlikte TLS'in içine bir kat daha: mesaj düzeyi AEAD + MAC
• Böylece TLS aşılsa bile gövde hâlâ şifreli → güvenlik kabuğunun en dış 2 katmanı

✅ Sertifika hatasını yutma, güven deposuna düşme (fail-closed).

TLS istemcisinin adımları — şema

Adım 6 neden hayati?

• Zincir doğrulaması yalnız "güvenilir CA mı imzaladı?" diye sorar
• Saldırgan kendi alan adı için tamamen geçerli bir sertifika alabilir
• Ad denetimi yoksa bank.example yerine attacker.example sertifikası kabul edilir

➡️ 2012 "dünyanın en tehlikeli kodu" çalışması: çok sayıda uygulama ve kütüphane bu adımı atlıyordu

Windows: WinHTTP / Schannel

• WinHTTP sertifikayı ve adı varsayılan olarak doğrular
• Tehlike: doğrulamayı kapatan bayraklar

DWORD flags = SECURITY_FLAG_IGNORE_UNKNOWN_CA |
          SECURITY_FLAG_IGNORE_CERT_CN_INVALID |
          SECURITY_FLAG_IGNORE_CERT_DATE_INVALID;   /* NEVER in a release build */
WinHttpSetOption(request, WINHTTP_OPTION_SECURITY_FLAGS, &flags, sizeof flags);

✅ Test sunucusunun CA'sını geliştirme makinesinin güven deposuna ekle; kod aynı kalsın

Kendi bağlantını test et

openssl s_client -connect server.example:443 -servername server.example -verify_return_error -brief
openssl s_client -connect server.example:443 -tls1_1      # should be rejected

1. Kendi imzalı sertifika → reddet (Demo 6)
2. Başka ad için geçerli sertifika → reddet
3. Cihaza kendi CA'nı kur + proxy → sabitleme yapan uygulama reddetmeli
4. Pin hatası raporlanıyor mu?

Bu bölümün kuralı

• İstemcide doğrulamayı elle açın: CA deposu + SSL_VERIFY_PEER + SSL_set1_host + min. TLS 1.2.
• Yüksek riskte SPKI sabitleme ekleyin, her zaman yedek pin bulundurun.
• Hata durumunda kapalı kalın (fail-closed): istisnayı yutup güven deposuna düşmeyin.

Kullanımda veri katmanları — şema

Beklemede veri: iki düzey — şema

Beklemede veri: dosya/alan şifreleme

• Tüm disk/dosya: LUKS, BitLocker, XTS-AES ya da uygulama AEAD
• Alan/sütun: yalnız hassas alanları uygulama katmanında AEAD ile şifrele
• Maskeleme: **** **** **** 4242 — şifreleme DEĞİL, maruz kalmayı azaltır
  (log, ekran, test, tokenizasyon)

Maskeleme şifrelemenin yerine geçmez, tamamlar (farklı tehditler).

Demo 7 — SQLite'ta alanı AES-GCM ile şifrele

Attacker opens the DB:
  1|Jane Doe|C6EA7420...   <- card field ENCRYPTED
Correct key:
  1|Jane Doe|4242-4242-4242-4242
Wrong key:
  1|Jane Doe|(COULD NOT DECRYPT - wrong key?)

name açık, card_encrypted şifreli. Anahtar koda gömülü değil (cihaza bağlı KDF).
Linux sqlite3, Windows yerleşik winsqlite3.

SQLite alan şifreleme: doğru ve yanlış anahtar (animasyon)

SQLite alan şifreleme — uç durum: yanlış anahtar

Tokenizasyon

• Veritabanı, raporlar, günlükler çalınsa bile kart numarası yok
• PCI DSS kapsamı küçülür = 1. haftadaki "aktar" yanıtı
• Mobil ödemede telefona inen = cihaza özgü belirteç numarası
• Biçim korunabilir: FF1 (NIST SP 800-38G)

Takma ad ve test verisi

crypto_hmac_sha256(pseudonym_key, 32, id_number, strlen(id_number), pseudonym);

• ❌ Düz SHA-256: 11 haneli kimlik no → hepsi denenebilir
• ✅ Anahtarlı HMAC; anahtar veri kümesinden ayrı · anahtar imha = fiilen anonim

Test verisi tercihi: 1. sentetik → 2. statik maskeleme → 3. dinamik maskeleme

Veri maskeleme: 3 teknik bir arada (animasyon)

Maskeleme — uç durum: çok kısa bir değer

Kullanımda veri: 3 katman

+ kısa ömür, kopyalama. memset -O2'de silinebilir; cleanse silinemez.

Demo 8 — mlock + güvenli silme

Layer 1 - crash dump turned off: OK
Layer 2 - mlock blocked writing to swap: OK
Secret in use: non-zero bytes = 23
Layer 3 - non-zero bytes after secure wipe = 0
OPENSSL_cleanse call stays in machine code (unlike memset, cannot be removed)

Cihaz bağlama: anahtarı cihaz parmak izinden HKDF + AEAD ile sar → başka
cihazda açılamaz (Demo 9).

Bu bölümün kuralı

• Beklemede: hassas alanları AEAD ile şifrele, anahtarı koda gömme.
• Maskeleme şifrelemenin yerine geçmez, tamamlar (log, ekran, test).
• Kullanımda: sırrı en son anda aç, en kısa süre tut, kaldırılamaz biçimde sil.

Bellekte güvenli silme (animasyon)

Bellek silme — uç durum: özel karakterler

Demo 9 — 4 kabukla sar, ters sırada aç

WRAP:   secret -> K1(device) -> K2(storage) -> K3(session) -> K4(channel)
   Layer 4 = 128 bytes  <- transmitted packet
UNWRAP: K4 -> K3 -> K2 -> K1 -> secret   (all OK, secret CORRECT)

Attack 1: tamper 1 bit -> Layer 4 REJECTED (tag did not hold)
Attack 2: copy to another device -> outer 3 layers open,
          Layer 1 (device) REJECTED -> secret CANNOT be opened

✅ "Hangi tek önlem?" değil, "hangi katmanlar?" · bağımsız anahtarlar.

Bu bölümün kuralı

• Kritik bir varlığı korurken "hangi tek önlem?" değil, "hangi katmanlar?" diye sorun.
• Her aşamaya (taşıma, depolama, kullanım) bir kabuk koyun.
• Kabukları birbirinden bağımsız anahtarlarla kurun; birinin kırılması diğerini vermesin.

Güvenlik kabukları: dört katmanlı savunma (animasyon)

Güvenlik kabukları — uç durum: başka cihaz

Whitebox'a giden yol — şema

Neden whitebox?

• Bu haftanın gizli varsayımı: anahtar kullanılırken bellekte açık durur
• "Cihazın sahibi saldırgan" belleği okuyabilir → o anı yakalar
• Güvenli silme pencereyi daraltır, kapatmaz
• Whitebox: anahtarı tablolara gömer, ham hâli hiç bellekte görünmez

⚠️ Sihirli değnek değil: oracle/code-lifting'e açık → diğer kabuklarla birlikte.
Ayrıntı: Hafta 11.

Uçtan uca: bir notu üç hâlde de korumak

Bir uygulama kullanıcının "notunu" korur: sunucudan gelir (aktarımda), diskte durur (beklemede), ekranda gösterilir (kullanımda).

Anahtar zinciri: parola → KDF → ana anahtar → HKDF → veri/oturum anahtarı; her aşamada AEAD bütünlüğü de gelir.

Proje: bu hafta (S5, S7)

• S5 — Varlık listesi (taslak): her hassas varlık; konum, ömür, C/I/I+, koruma
• S7 — Veri güvenliği + kabuk matrisi: her varlık × üç hâl × kabuklar; güvenli
  silme politikası

Gereksinim aileleri: CEN429-DT/DR/DU (aktarım/beklemede/kullanımda), AS, CR

S17 uyum matrisine her gereksinim için satır ekleyin.

Sınıf etkinlikleri

1. MITM'i durdur: Demo 6'da SSL_set1_host'u kapat → hangi saldırgan kaçar?
2. Nonce'u tekrarlat: Demo 1'de sabit nonce → iki şifreli metni XOR'la
3. Üç veri hâli haritası: sağlık uygulaması için tehdit/önlem tablosu
4. KDF maliyeti: 100 ms veren tur sayısını bul

Kendini sınama (örnek)

1. AEAD ile AES-CTR farkı?
2. Nonce tekrarı neden felaket?
3. ECB neden kullanılmaz?
4. OpenSSL istemcisinin en tehlikeli varsayılanı?
5. Pinning neyi, hostname doğrulama neyi yakalar?
6. Güvenlik kabuğu nedir, bir örnek?

Tam liste (20 soru) ve cevaplar ders sitesinde. Quiz-1 bu tarz + kod okuma.

Kendini sınama — cevaplar (örnek 1–6)

1. AES-CTR yalnız gizlilik verir; AEAD (AES-GCM) gizlilik + bütünlük/kimlik doğrulamayı bir etiketle birlikte verir. CTR'de değişiklik fark edilmez.
2. Aynı anahtar+nonce anahtar akışını tekrarlar; iki şifreli metnin XOR'u açık metni sızdırır, GCM'de kimlik anahtarı riske girer.
3. ECB aynı bloğu aynı şifreli bloğa çevirir → desenler görünür; anlamsal güvenlik yok.
4. İstemcinin sertifika/hostname doğrulamasını kendiliğinden yapmaması; elle açılmazsa MITM.
5. Pinning: beklenen sunucu anahtarını (SPKI) sabitler → sahte-ama-"geçerli" sertifikayı yakalar. Hostname doğrulama: sertifikanın doğru alan adına ait olduğunu yakalar.
6. Güvenlik kabuğu: varlığı saran koruma (C=gizlilik, I=bütünlük). Örn. anahtar dosyası = AES-GCM (C) + etiket/HMAC (I).

Kendini sınama (devam)

7. rand() neden güvenlik için kullanılamaz? Yerine?
8. EVP_DecryptFinal_ex başarısız döndü; tampondaki açık metne ne yaparsınız?
9. MAC karşılaştırmasında memcmp neden sakıncalı?
10. Kripto-periyodu dolan anahtar hemen silinir mi?
11. Zarflamada KEK yenilenince neden veri yeniden şifrelenmez?

Kendini sınama — cevaplar (7–11)

7. rand() istatistikseldir, tahmin edilebilir → CSPRNG kullanın (RAND_bytes / getrandom).
8. Çözme başarısızsa tampondaki açık metni güvenli silin (memset_s) ve reddedin — bütünlük doğrulanmadı, kullanmayın.
9. memcmp erken çıkar → zamanlama sızıntısı; CRYPTO_memcmp / sabit zamanlı karşılaştırma kullanın.
10. Hayır. Yeni şifrelemede kullanılmaz ama eski veri yeniden şifrelenene dek yalnız çözmede tutulur.
11. Veri DEK ile şifrelidir; KEK yenilenince yalnızca DEK'ler yeniden sarılır (rewrap), veri değil.

Kendini sınama (devam)

12. SSL_set1_host çağrılmazsa ne olur?
13. Sabitlemede neden SPKI ve neden yedek pin?
14. "Fail-open" nedir? Bir örnek
15. Kimlik numarasının düz SHA-256'sı neden takma ad olamaz?
16. Tokenizasyon PCI DSS kapsamını neden küçültür?

Kendini sınama — cevaplar (12–16)

12. SSL_set1_host yoksa hostname doğrulanmaz; başka ada ait geçerli sertifika kabul edilir → MITM.
13. SPKI sertifika yenilense de (anahtar aynıysa) değişmez; yedek pin anahtar değişiminde uygulamanın "tuğlalaşmasını" önler.
14. Fail-open: hata durumunda "geçti/izin ver" sayılması; örn. yutulan KeyStoreException ile doğrulamanın atlanması.
15. Kimlik no'nun değer uzayı küçük/tahmin edilebilir → düz SHA-256 kaba kuvvetle geri döner; anahtarlı HMAC gerekir.
16. Tokenizasyon: gerçek PAN yalnız kasada kalır; sistemin kalanı token tutar → PCI DSS denetim kapsamı daralır.

Kendini sınama (devam)

17. Verinin üç hâli ve her birinin koruması?
18. Parola neden doğrudan anahtar olamaz?
19. AEAD ne sağlar, hangi ayrı adımların yerine geçer?
20. İleri gizlilik ne demek?
21. IV/nonce/tuz gizli mi? Kuralı ne?
22. CSPRNG neden gerekli?
23. Anahtar hiyerarşisi neden var?

Kendini sınama — cevaplar (17–23)

17. Aktarımda (TLS), beklemede (AEAD şifreleme), kullanımda (kısa ömür + silme).
18. Düşük entropili ve tahmin edilebilir; KDF (PBKDF2/Argon2) ile tuzlu, yavaş türetilir.
19. Gizlilik + bütünlüğü birlikte verir; ayrı şifreleme + MAC adımlarının yerine geçer.
20. Her oturum için yeni anahtar; uzun vadeli anahtar sızsa bile eski oturumlar çözülemez.
21. Gizli değildir ama benzersiz/tekrarsız olmalı; nonce tekrarı ve sabit tuz tehlikelidir.
22. rand() tahmin edilebilir; anahtar/nonce/tuz için CSPRNG (OS) gerekir.
23. Tek anahtar her işte kullanılmaz; ana anahtardan türev anahtarlar gelir, her birinin ayrı görevi ve ömrü olur.