Hafta 3 — Veri Güvenliği: Aktarımda, Beklemede, Kullanımda¶

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.

cd code
.\build.ps1
cd week-03\01-aes-gcm-file
.\demo.ps1        # ya da demo.cmd dosyasına çift tıklayın

cd code
./build.sh
cd week-03/01-aes-gcm-file
sh demo.sh

0. Başlamadan önce¶

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¶

• Beyaz kutu saldırgan modeli — cihazın ya da sunucunun sahibi olan kullanıcı aynı zamanda potansiyel saldırgandır; belleği okuyabilir, hata ayıklayıcı bağlayabilir (Hafta 1, §3). Bu hafta bu modeli kullanımda veri (§13) ve **whitebox kriptografi motivasyonu**nda (§15) yeniden kullanıyoruz.
• Bellekten güvenli silme — bir sırrı, derleyicinin kaldıramayacağı bir işlevle (explicit_bzero, OPENSSL_cleanse) üzerine yazarak silmek (Hafta 1, §17). Bu hafta §13'te buna döküm engelleme, bellek kilitleme ve cihaz bağlamayı ekliyoruz.
• Entropi ölçümü — bir dosyanın baytlarındaki düzensizliği ölçüp şifreli/paketli içeriği ayırt etme fikri (Hafta 2, §6). §3'te aynı fikri, bu kez rastgele üretecin girdisindeki düzensizlik (entropi) açısından kullanıyoruz.

Bu haftanın kavram haritası¶

1. Verinin üç hâli ve güvenlik kabuğu¶

Geçen iki hafta "hata → saldırı → düzeltme" ile programın kendisini koruduk. Bu hafta odağı veriye çeviriyoruz. Bir sır — parola, ödeme anahtarı, kişisel bilgi — yaşam döngüsü boyunca üç ayrı hâlde bulunur ve her hâlin tehdidi de savunması da farklıdır:

Dönem boyunca kullandığımız örnek mimariyi (bir mobil ödeme uygulaması + onun kritik işlerini yapan bir güvenlik kütüphanesi) hatırlayın. Bu hafta o mimarideki üç arayüzü dolduruyoruz: telefon ↔ sunucu (aktarımda), telefondaki şifreli veritabanı (beklemede) ve ödeme anında bellekte açılan anahtar (kullanımda).

Bu mimaride telefon güvenilmez ortamdır (kullanıcı — yani potansiyel saldırgan — cihazın sahibidir; root alınmış, hata ayıklayıcı bağlanmış olabilir). Sunucu tarafı güvenilirdir. Aradaki her arayüz için şu soruları sorarız: hangi veri geçiyor, hangi hâlde (aktarım/depolama/kullanım), kimlik nasıl doğrulanıyor, gizlilik mi bütünlük mü yoksa ikisi birden mi gerekiyor? Bu haftanın demoları tam olarak bu soruların cevaplarını kurar:

• Telefon ↔ sunucu (aktarımda): TLS 1.3 + sertifika doğrulama + sabitleme, üstüne mesaj düzeyi AEAD (Demo 6, 1, 5).
• Yerel veritabanı (beklemede): hassas alanlar cihaza bağlı bir anahtarla AES-GCM (Demo 7, 4).
• Ödeme anında bellek (kullanımda): anahtar en kısa süre açık, kullanınca güvenli silme, cihaz bağlama (Demo 8, 9).

Bütün örnek değerler sentetiktir (uydurma); gerçek anahtar, kart numarası, cihaz kimliği ya da IP kullanılmaz.

2. Şifreleme temelleri: hangi araç neyi korur?¶

Şifreleme (encryption), okunur veriyi (açık metin) bir anahtar kullanarak okunamaz hale (şifreli metin) getirme işlemidir; çözme (decryption) aynı (ya da eşleşen) anahtarla bunu tersine çevirir. Güvenlik, algoritmanın değil anahtarın gizliliğine dayanır. Ama kriptografi tek bir şey değildir; farklı hedefler için farklı araçlar vardır. En sık karıştırılan dört aileyi netleştirelim.

2.1 Kimlik doğrulamalı şifreleme (AEAD): tek çağrıda gizlilik + bütünlük¶

Doğru cevap neredeyse her zaman AEAD'dir (Authenticated Encryption with Associated Data). AEAD tek bir işlemle iki şey yapar: veriyi şifreler (gizlilik) ve şifreli metnin (isteğe bağlı olarak ek "ilişkili veri"nin) değişmediğini kanıtlayan bir etiket (tag) üretir (bütünlük + kimlik). Çözerken etiket doğrulanır: tek bir bit bile oynadıysa çözme reddedilir.

İki modern AEAD:

• AES-GCM — donanım AES hızlandırması olan işlemcilerde (çoğu masaüstü/sunucu) çok hızlı. NIST SP 800-38D.
• ChaCha20-Poly1305 — AES donanımı olmayan cihazlarda (bazı mobil/gömülü) daha hızlı ve yan kanala dirençli. RFC 8439.

2.2 Simetrik mi, asimetrik mi? Cevap: ikisi birden (hibrit)¶

Simetrik şifreleme (AES) hızlıdır ama iki tarafın aynı gizli anahtarı bilmesini gerektirir; bu anahtarı güvensiz bir ağdan nasıl paylaşırsınız? Asimetrik şifreleme (RSA, eliptik eğri) bu sorunu çözer: herkesin bir açık anahtarı (dağıtılır) ve bir özel anahtarı (gizli kalır) vardır. Ama asimetrik işlemler yavaştır ve büyük veriye uygun değildir.

Gerçek sistemler bu yüzden hibrit çalışır: asimetrik kripto yalnız küçük bir simetrik anahtarı güvenle taşımak (ya da anlaşmak) için kullanılır; asıl veri o simetrik anahtarla AEAD ile şifrelenir. TLS tam olarak budur: el sıkışmada eliptik eğri Diffie-Hellman ile bir oturum anahtarı üzerinde anlaşılır, sonra bütün trafik AES-GCM ya da ChaCha20-Poly1305 ile şifrelenir.

2.3 Blok mü, akış mı? Kip (mode) neden önemli?¶

AES bir blok şifresidir: tek seferde 16 baytlık bir bloğu şifreler. Bloktan uzun veriyi şifrelemek için bir kip (mode of operation) gerekir ve kip seçimi güvenliği belirler:

• ECB — her bloğu bağımsız şifreler; desen sızdırır (Demo 3). Kullanmayın.
• CBC — her blok bir öncekine zincirlenir; rastgele IV ister, tek başına bütünlük vermez, padding oracle'a açık.
• CTR — bloğu bir akış şifresine çevirir (anahtar akışı ⊕ veri); nonce tekrarına çok hassas (Demo 2).
• GCM — CTR + Galois MAC; AEAD. Modern varsayılan.

ChaCha20 zaten bir akış şifresidir (blok kavramı yoktur); Poly1305 MAC'iyle birleşince AEAD olur. Sonuç aynı: gizlilik + bütünlük tek pakette.

2.4 Özet, MAC ve imza: hangisi ne zaman?¶

Bu üçü bütünlük ailesindendir ama farklı şeyler kanıtlarlar; karıştırmak yaygın bir hatadır:

• Özet (hash), veriden hesaplanan sabit boyutlu, tek yönlü bir parmak izidir ve anahtarsızdır. Yalnız verinin değişip değişmediğini gösterir. Ama 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. Özet, HMAC ve HKDF gibi yapıların yapıtaşıdır ve parmak izi/karşılaştırma için kullanılır. Eski MD5/SHA-1 çakışmaya açıktır; SHA-256/SHA-3 kullanın.
• 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 (hangi taraf ürettiği ayırt edilemez). Sırları MAC ile karşılaştırırken sabit zamanlı karşılaştırma kullanın (CRYPTO_memcmp), düz memcmp zamanlama sızdırır.
• Dijital imza (ör. 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.

Demo 1 — AES-256-GCM ile dosya şifreleme ve kurcalama tespiti¶

Şifreleme ve çözmenin özü (kripto çağrıları ortak cen429_crypto.h başlığından gelir; Linux'ta OpenSSL EVP, Windows'ta BCrypt):

/* Encrypt: out = [nonce][ciphertext][tag] */
crypto_random(nonce, 12);                    /* a fresh nonce per message */
memcpy(out, nonce, 12);
crypto_gcm_encrypt(key, nonce, 12, NULL, 0,
                   plain, plain_len, out + 12, tag);
memcpy(out + 12 + plain_len, tag, 16);

/* Decrypt: the tag is verified; ok == 0 if it does not match */
int ok = crypto_gcm_decrypt(key, nonce, 12, NULL, 0,
                            ct, ct_len, tag, plain);
if (!ok) { /* REJECT: the data was tampered with, or the key is wrong */ }

Çalıştırın (Windows'ta .\demo.ps1):

cd code/week-03/01-aes-gcm-file
sh demo.sh

Gerçek çıktı (Windows .\demo.ps1, kısaltılmış):

STEP 2 - Encrypt
Encrypted: output\secret.txt -> output\secret.enc (54 bytes of ciphertext + 12 nonce + 16 tag)
First 32 bytes of the ciphertext file (nonce + ciphertext):
   df 05 81 06 c9 4a c6 75 da 63 ed ad f3 8a b9 1a 21 8c 81 aa 55 5e 3f 8e e7 27 9e e7 1c c8 b1 08

STEP 3 - Decrypt correctly (the tag matches)
Decrypted and VERIFIED: output\secret.enc -> output\decrypted.txt (54 bytes)
   IBAN: TR00 0000 0000 0000 0000 0000 00
   Balance: 12345

STEP 4 - Attack: change byte 20 of the ciphertext
VERIFICATION FAILED: the tag did not match, the data was tampered with, or the key is wrong. Decryption REJECTED.
   (exit code 2 - decryption rejected)

STEP 5 - Attack: change only the last byte of the TAG
VERIFICATION FAILED: the tag did not match, the data was tampered with, or the key is wrong. Decryption REJECTED.
   (exit code 2 - the tag did not match)

Satır satır ne oldu:

• ADIM 2: Rastgele bir 12 baytlık nonce üretildi ve 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.
• ADIM 4: Şifreli metnin 20. baytını bir XOR ile değiştirdik. GCM etiketi bütün şifreli metnin üzerinde hesaplandığı için tek bayt bile etiketi bozar; çözme reddedildi (çıkış kodu 2).
• ADIM 5: Bu kez veriye değil yalnız etikete dokunduk; yine reddedildi. Etiket, veriyle birlikte anahtarın da fonksiyonudur; saldırgan doğru etiketi anahtar olmadan üretemez.

Aşağıdaki animasyonda şifreleme, dosya biçimi [nonce][şifreli metin][etiket] ve etiket doğrulamasının adım adım nasıl işlediğini — hem başarılı çözmeyi hem de kurcalanmış bir baytın nasıl reddedildiğini — izleyin.

Örnek seçiciden doğru çözme (uyar/zor) ile şifreli metin kurcalandı ve yalnız etiket kurcalandı (uç durumlar) senaryolarını deneyin — ya da 🎲 ile rastgele bir mesaj üretin, ya da kendi metninizi yazın.

3. Rastgele sayılar: kriptografinin görünmez temeli¶

Şimdiye kadar konuştuğumuz her şey (anahtar, IV, nonce, tuz, oturum kimliği) tek bir varsayıma dayanır: bu değerler tahmin edilemez. Dünyanın en iyi şifreleme algoritması, anahtarı tahmin edilebilir bir üreteçle oluşturulmuşsa hiçbir şey korumaz. Kitabın 11. bölümü baştan sona bu konuya ayrılmıştır; burada bugün geçerli olan kısmını adım adım işleyeceğiz.

Üç tür "rastgele"¶

Kural basittir: güvenlikle ilgili her rastgele değer CSPRNG'den gelir. rand() ve mt19937 istatistiksel olarak "rastgele görünür", ama güvenlik açısından tamamen tahmin edilebilirdir. Mersenne Twister'ın 624 ardışık çıktısını gören biri, sonraki bütün çıktıları hesaplayabilir.

Bu tahmin edilemezlik, Hafta 2'de gördüğümüz entropi fikrinin diğer yüzüdür: orada bir dosyanın baytlarındaki düzensizliği ölçüp şifreli/paketli içeriği ayırt ediyorduk; burada üretecin girdisindeki düzensizliğin (entropinin) yeterli olmasını isteyip tahmin edilemez çıktı üretmeye çalışıyoruz. Üretecin havuzu yeterince tohumlanmamışsa (aşağıdaki Hata 2'de göreceğimiz gibi) çıktı da tahmin edilebilir hale gelir.

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'dür. Bir dizüstü bilgisayar bunların hepsini saniyeler içinde dener. rand()'ın kendi iç durumu da küçüktür; tohum bilinirse bütün dizi bilinir.

Hata 2: entropiyi yanlışlıkla silmek¶

Doğru yol: işletim sisteminin üreteci¶

#include <sys/random.h>
#include <errno.h>

int random_bytes(void *buffer, size_t n)
{
    unsigned char *p = buffer;
    while (n > 0) {
        ssize_t r = getrandom(p, n, 0);    /* blocks until the pool is ready */
        if (r < 0) {
            if (errno == EINTR) continue;
            return -1;
        }
        p += r; n -= (size_t)r;
    }
    return 0;
}

#include <windows.h>
#include <bcrypt.h>
#pragma comment(lib, "bcrypt.lib")

int random_bytes(void *buffer, size_t n)
{
    NTSTATUS s = BCryptGenRandom(NULL, (PUCHAR)buffer, (ULONG)n,
                                 BCRYPT_USE_SYSTEM_PREFERRED_RNG);
    return BCRYPT_SUCCESS(s) ? 0 : -1;
}

#include <openssl/rand.h>
if (RAND_bytes(buffer, (int)n) != 1) { /* error: NEVER continue */ }

Hata 3: aralığa indirgerken sapma (modulo bias)¶

Bir zar atmak için r % 6 yazmak masum görünür. Ama r 0–255 arasında tekdüze ise, 256 sayısı 6'ya tam bölünmediği için 0–3 değerleri 43'er kez, 4–5 değerleri 42'şer kez çıkar. Zar için önemsiz; ama rastgele bir parola ya da tek kullanımlık kod üretirken bazı karakterlerin daha sık çıkması tahmin edilebilirliği artırır. Doğru yöntem reddetmedir (Tarif 11.11):

#include <stdint.h>

uint32_t random_in_range(uint32_t upper)
{
    uint32_t threshold = (uint32_t)(-upper) % upper;   /* 2^32 mod upper: this many values are "extra" */
    uint32_t r;
    do {
        random_bytes(&r, sizeof r);
    } while (r < threshold);                    /* discard the extra, draw again */
    return r % upper;
}

Fikir: 2³² değerin, ust'e tam bölünen en büyük kısmını kullanıp kalanı atmak. Böylece her sonuç tam olarak aynı sayıda girdiden gelir.

Rastgele değerleri nerede kullanıyoruz? Bir kontrol listesi¶

4. Kripto API'lerini doğru kullanmak: adım adım AES-GCM¶

Demo 1'de AES-256-GCM ile bir dosyayı şifreledik ve kurcalamayı yakaladık. Demo, işi code/common/cen429_crypto.h içindeki yardımcı fonksiyonlara bıraktı. Bu bölümde o fonksiyonların içini açıyoruz: OpenSSL'in EVP arayüzü ve Windows'un CNG (BCrypt) arayüzüyle AES-GCM'yi adım adım yazacağız. Amaç, bir kripto kütüphanesini kullanırken nerede hata yapılabileceğini görmektir. Kural hâlâ geçerlidir: kendi algoritmanızı yazmazsınız, ama hazır algoritmayı doğru çağırmak da bir beceridir.

AEAD'in dört girdisi ve iki çıktısı¶

AAD (ek doğrulanmış veri), şifrelenmeyen ama değiştirilirse fark edilmesi gereken bilgidir: dosya başlığı, sürüm numarası, kayıt kimliği. 1. haftadaki parola kasası örneğinde türetme parametrelerini AAD yapmıştık; biri yineleme sayısını değiştirirse etiket tutmaz.

OpenSSL EVP ile şifreleme¶

#include <openssl/evp.h>

/* Returns the ciphertext length on success, -1 on error. */
int aes_gcm_encrypt_example(const unsigned char key[32], const unsigned char nonce[12],
                    const unsigned char *aad, int aad_n,
                    const unsigned char *plain, int n,
                    unsigned char *ciphertext, unsigned char tag[16])
{
    EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
    int written, total = -1;
    if (ctx == NULL) return -1;

    if (EVP_EncryptInit_ex(ctx, EVP_aes_256_gcm(), NULL, NULL, NULL) != 1) goto done;   /* 1 */
    if (EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, 12, NULL) != 1) goto done;     /* 2 */
    if (EVP_EncryptInit_ex(ctx, NULL, NULL, key, nonce) != 1) goto done;                /* 3 */
    if (aad_n > 0 && EVP_EncryptUpdate(ctx, NULL, &written, aad, aad_n) != 1) goto done; /* 4 */
    if (EVP_EncryptUpdate(ctx, ciphertext, &written, plain, n) != 1) goto done;         /* 5 */
    total = written;
    if (EVP_EncryptFinal_ex(ctx, ciphertext + total, &written) != 1) { total = -1; goto done; } /* 6 */
    total += written;
    if (EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG, 16, tag) != 1) total = -1; /* 7 */
done:
    EVP_CIPHER_CTX_free(ctx);     /* also clears the key material inside the context */
    return total;
}

Adımlar sırasıyla:

1. Algoritmayı seç; anahtarı ve nonce'u henüz verme.
2. Nonce uzunluğunu ayarla (GCM için önerilen 12 bayt; varsayılan da budur ama açık yazmak iyidir).
3. Anahtarı ve nonce'u ver.
4. AAD'yi ver: çıktı tamponu NULL'dır, çünkü AAD şifrelenmez, yalnız etikete katılır.
5. Açık metni şifrele. Büyük veride bu adım parça parça tekrarlanabilir.
6. Bitir. GCM akış kipinde çalıştığı için dolgu yoktur; bu çağrı genellikle 0 bayt yazar, ama çağrılması zorunludur: etiket burada hesaplanır.
7. Etiketi al ve şifreli metinle birlikte sakla.

Her çağrının dönüş değeri denetleniyor ve tek bir çıkış noktasında (done:) bağlam serbest bırakılıyor. C'de kaynak sızıntısını önlemenin en okunaklı yolu bu goto kalıbıdır.

Çözme: etiket doğrulanmadan açık metne dokunma¶

/* Returns the plaintext length on success, -1 if the tag doesn't hold or on error. */
int aes_gcm_decrypt_example(const unsigned char key[32], const unsigned char nonce[12],
                const unsigned char *aad, int aad_n,
                const unsigned char *ciphertext, int n,
                const unsigned char tag[16], unsigned char *plain)
{
    EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
    int written, total = -1;
    if (ctx == NULL) return -1;

    if (EVP_DecryptInit_ex(ctx, EVP_aes_256_gcm(), NULL, NULL, NULL) != 1) goto done;
    if (EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, 12, NULL) != 1) goto done;
    if (EVP_DecryptInit_ex(ctx, NULL, NULL, key, nonce) != 1) goto done;
    if (aad_n > 0 && EVP_DecryptUpdate(ctx, NULL, &written, aad, aad_n) != 1) goto done;
    if (EVP_DecryptUpdate(ctx, plain, &written, ciphertext, n) != 1) goto done;
    total = written;
    /* Give the expected tag BEFORE Final */
    if (EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_TAG, 16, (void *)tag) != 1) { total = -1; goto done; }
    if (EVP_DecryptFinal_ex(ctx, plain + total, &written) != 1) {
        OPENSSL_cleanse(plain, (size_t)n);     /* tag did not hold: wipe the half-decrypted data */
        total = -1;
        goto done;
    }
    total += written;
done:
    EVP_CIPHER_CTX_free(ctx);
    return total;
}

Windows CNG ile aynı iş¶

#include <windows.h>
#include <bcrypt.h>

int aes_gcm_encrypt_cng_example(const UCHAR key[32], const UCHAR nonce[12],
                        UCHAR *aad, ULONG aad_n, const UCHAR *plain, ULONG n,
                        UCHAR *ciphertext, UCHAR tag[16])
{
    BCRYPT_ALG_HANDLE alg = NULL;
    BCRYPT_KEY_HANDLE keyHandle = NULL;
    BCRYPT_AUTHENTICATED_CIPHER_MODE_INFO info;
    ULONG written = 0;
    int result = -1;

    if (!BCRYPT_SUCCESS(BCryptOpenAlgorithmProvider(&alg, BCRYPT_AES_ALGORITHM, NULL, 0))) goto done;
    if (!BCRYPT_SUCCESS(BCryptSetProperty(alg, BCRYPT_CHAINING_MODE,
            (PUCHAR)BCRYPT_CHAIN_MODE_GCM, sizeof(BCRYPT_CHAIN_MODE_GCM), 0))) goto done;
    if (!BCRYPT_SUCCESS(BCryptGenerateSymmetricKey(alg, &keyHandle, NULL, 0,
            (PUCHAR)key, 32, 0))) goto done;

    BCRYPT_INIT_AUTH_MODE_INFO(info);
    info.pbNonce = (PUCHAR)nonce; info.cbNonce = 12;
    info.pbAuthData = aad;        info.cbAuthData = aad_n;
    info.pbTag = tag;             info.cbTag = 16;

    if (BCRYPT_SUCCESS(BCryptEncrypt(keyHandle, (PUCHAR)plain, n, &info, NULL, 0,
                                     ciphertext, n, &written, 0)))
        result = (int)written;
done:
    if (keyHandle) BCryptDestroyKey(keyHandle);
    if (alg) BCryptCloseAlgorithmProvider(alg, 0);
    return result;
}

/* Aynı hazırlık; info.pbTag beklenen etiketi gösterir. */
NTSTATUS s = BCryptDecrypt(keyHandle, (PUCHAR)ciphertext, n, &info, NULL, 0,
                           plain, n, &written, 0);
if (s == STATUS_AUTH_TAG_MISMATCH) {      /* 0xC000A002: kurcalama */
    SecureZeroMemory(plain, n);
    return -1;
}

İki arayüz farklı görünse de adımlar aynıdır: algoritma ve kip seçimi, anahtar nesnesi, nonce + AAD + etiket, tek çağrıda işlem, kaynakların serbest bırakılması. CNG'nin bir avantajı, etiketin uyuşmamasını ayrı bir durum koduyla bildirmesidir.

Sabit zamanlı karşılaştırma¶

Etiketi ya da bir MAC'i elle karşılaştırmanız gerekirse (ör. HMAC ile imzalanmış bir mesajda), memcmp kullanmayın. memcmp ilk farklı baytta durur; karşılaştırmanın süresi, kaç baytın doğru olduğunu sızdırır. Saldırgan etiketi bayt bayt tahmin edip süreyi ölçerek doğru değere ulaşabilir (zamanlama saldırısı).

int constant_time_equal(const unsigned char *a, const unsigned char *b, size_t n)
{
    unsigned char diff = 0;
    for (size_t i = 0; i < n; i++)
        diff |= a[i] ^ b[i];         /* always walk every byte */
    return diff == 0;
}

Hazır karşılıkları: OpenSSL CRYPTO_memcmp, Linux çekirdeğinde crypto_memneq, libsodium sodium_memcmp.

Kripto kütüphanesi kullanırken kontrol listesi¶

• Her çağrının dönüş değeri denetleniyor; hata durumunda işlem durduruluyor.
• Nonce her şifrelemede yeni (rastgele ya da kalıcı sayaç).
• Etiket, açık metin kullanılmadan önce doğrulanıyor; başarısızlıkta açık metin siliniyor.
• Etiket ve MAC karşılaştırmaları sabit zamanlı.
• Anahtar tamponları iş bitince siliniyor; bağlam nesneleri serbest bırakılıyor.
• Hata iletileri saldırgana ayrıntı vermiyor: "etiket hatası" ile "dolgu hatası" ayrı iletiler olursa, bu fark bir kâhin olarak kullanılabilir (CBC dolgu kâhini (padding oracle) saldırıları buradan doğmuştur).
• Eskimiş algoritmalar yok: DES/3DES, RC4, MD5, SHA-1 (imzada), ECB.

5. IV/nonce ve tuz: aynı anahtarı tekrar kullanmak¶

Üç kavram sürekli karıştırılır. Üçü de gizli değildir, ama güvenlik doğru kullanımlarına bağlıdır (kitap tarif 4.9):

5.1 Nonce yeniden kullanımı neden felakettir?¶

GCM ve CTR, anahtardan ve nonce'dan bir anahtar akışı üretip düz metinle XOR'lar: C = P ⊕ AA(anahtar, nonce). Aynı anahtar ve aynı nonce ile iki mesaj şifrelenirse iki mesajda da aynı anahtar akışı kullanılır:

C1 = P1 ⊕ AA        C2 = P2 ⊕ AA
C1 ⊕ C2 = (P1 ⊕ AA) ⊕ (P2 ⊕ AA) = P1 ⊕ P2

Anahtar akışı yok olur; saldırgan iki düz metnin XOR'unu ele geçirir. Bir mesajı biliyorsa (ya da tahmin ederse) diğerini tamamen çözer.

Demo 2 — Nonce tekrarının iki düz metnin XOR'unu sızdırması¶

Plaintext 1: "Attack begins at dawn, 06:00 hours!"
Plaintext 2: "Total balance is 45000, PIN is 1234"
==============================================================
BAD CASE - the SAME nonce for both messages:
  C1 xor C2 = 151b00000f4b42030906070d16000807 ... 44404015
  P1 xor P2 = 151b00000f4b42030906070d16000807 ... 44404015
  ==> C1 xor C2 == P1 xor P2 : the keystream LEAKED!
  If the attacker knows P1, P2 = (C1 xor C2) xor P1 =
     "Total balance is 45000, PIN is 1234"
==============================================================
GOOD CASE - a DIFFERENT nonce for each message:
  C1 xor C2 = 330093b563c381a72339b0180bd1dc2f ... d97fab3
  P1 xor P2 = 151b00000f4b42030906070d16000807 ... 44404015
  ==> C1 xor C2 != P1 xor P2 : no leak.

Kötü durumda C1 ⊕ C2 ile P1 ⊕ P2 birebir aynı çıktı: anahtar akışı iptal oldu. Program bir mesajı bilen saldırganın diğerini (C1 ⊕ C2) ⊕ P1 ile tamamen çözdüğünü de gösterdi. Farklı nonce'ta ilişki kayboldu.

Aşağıdaki animasyonda aynı nonce'un iki mesajı nasıl aynı anahtar akışıyla şifrelediğini, C1 xor C2'nin P1 xor P2'ye nasıl eşit çıktığını ve saldırganın bilinen bir düz metinle diğerini nasıl kurtardığını izleyin.

Örnek seçiciden aynı nonce ile sızıntı (uyar/zor) ile farklı nonce, sızıntı yok ve iki mesaj da aynı (uç durumlar) senaryolarını deneyin — ya da kendi iki eş uzunluklu mesajınızı yazın.

5.2 ECB deseni sızdırır¶

Nonce/IV kullanmayan bir kip olan ECB (Electronic Codebook), her 16 baytlık bloğu bağımsız şifreler. Aynı düz metin bloğu her zaman aynı şifreli bloğu verir; bu yüzden verideki tekrar eden desenler şifreli metinde de görünür.

Demo 3 — ECB "pengueni": desen sızıntısı¶

Original picture (plaintext):
  ################################
  #  ##    ####    ####    ##    #
  ...  (429 rakamlari)  ...
  ################################
==============================================================
Encrypted with AES-128-ECB (each block by its first byte):
  ================================
  =##==####====####====####==####=
  ...  ayni sekil hala GORUNUYOR ...
  ================================
  ==> The shape is still VISIBLE: ECB leaks the pattern. DO NOT USE IT.
==============================================================
Encrypted with AES-256-GCM (CTR-based), same picture:
  : -..--+%%*-:**% . #*#+*.:+* :..
  *.#*##:*%+###:#-*%==*#-+=%:.=***
  ...  desen kayboldu, gurultu ...
  ==> The pattern is gone: GCM/CTR encrypts every block differently.

ECB çıktısında yalnız iki karakter var (arka plan bloğu → bir şifreli blok, şekil bloğu → başka bir şifreli blok); şekil aynen okunuyor. Bu, ünlü "ECB pengueni" örneğinin ASCII hâlidir. GCM'de her blok konuma bağlı farklı bir anahtar akışıyla şifrelendiği için çıktı gürültüdür.

Aşağıdaki animasyonda küçük bir resmi hem ECB hem GCM ile şifreleyip desenin ECB'de nasıl okunur kaldığını, GCM'de nasıl kaybolduğunu izleyin.

Örnek seçiciden küçük bir şekil (uyar/zor) ile tamamı arka plan ve dama tahtası (uç durumlar) desenlerini deneyin — ya da kendi 0/1 desenli küçük resminizi yazın.

6. Paroladan anahtar türetme¶

Parola doğrudan anahtar olamaz: kısa, düşük entropili ve tahmin edilebilir. Paroladan anahtar türetme fonksiyonu (KDF) iki iş yapar:

1. Tuz (salt): Her kullanıcıya/kayda rastgele tuz eklenir. Aynı parola farklı tuzlarla farklı anahtar verir; böylece önhesaplı tablolar (rainbow table) işe yaramaz ve iki kullanıcının aynı parolası fark edilmez.
2. Yavaşlık (maliyet): KDF bilerek yüzbinlerce tur çalışır; bir parolayı denemek pahalı olur, kaba kuvvet yavaşlar.

Demo 4 — Tur sayısı, süre ve tuzun önemi¶

Password: "dog123"
==============================================================
1) WHY THE SALT MATTERS (rounds = 100000)
   salt A -> key = 8b3d1913b0a104fa643f2b7b36863c65d1deda204e9f6bf6c1b21443930ec892
   salt A -> key = 8b3d1913b0a104fa643f2b7b36863c65d1deda204e9f6bf6c1b21443930ec892
   ^ Same password + the SAME salt -> the SAME key (a table lookup would work)
   salt B -> key = e9a8193a675ec5dd2366aad2a54d253c655f2c914043858b5a4c8d8b53691290
   ^ Same password + a DIFFERENT salt -> a DIFFERENT key (the salt does its job)
==============================================================
2) ROUND COUNT vs TIME (same password, same salt)
   rounds =     1000  ->      1.24 ms
   rounds =    10000  ->     12.55 ms
   rounds =   100000  ->    126.75 ms
   rounds =   600000  ->    824.96 ms
   rounds =  2000000  ->   2808.32 ms
   ^ As the round count grows, every password guess gets more expensive.

Argon2id karşılaştırması yalnız WSL/Linux'ta, argon2 aracı kuruluysa çalışır (demo.sh'ın 3. adımı); Windows demosu (.\demo.ps1) yalnız açıklamayı yazdırır (bkz. aşağıdaki not).

• Tuz: Aynı parola + aynı tuz her seferinde aynı anahtarı verdi (bu yüzden tuz sabitse saldırgan bir kez tablo kurup herkesi arar). Aynı parola + farklı tuz tamamen farklı anahtar verdi.
• Maliyet: Tur sayısı 1.000'den 2.000.000'a çıkınca süre ~1,2 ms'den ~2,8 saniyeye çıktı. Bu doğrudan çarpandır: saldırganın her parola denemesi de o kadar pahalılaşır. "Kullanıcı girişinde 200 ms" kabul edilebilir; saldırgan için saniyede milyarlarca deneme yerine binlerce deneme demektir.
• Argon2id: Ek olarak bellek (burada 64 MiB) ister; GPU/ASIC ile paralel kaba kuvveti PBKDF2'den daha çok zorlaştırır.

Aşağıdaki animasyonda küçük bir tur zincirinin (U1 -> U2 -> ... -> Uₙ) nasıl işlediğini ve aynı parolanın farklı tuzlarla nasıl tamamen farklı anahtarlar verdiğini izleyin; gerçek demodan ölçülen tur-süre tablosu da gösterilir.

Örnek seçiciden 4 turluk zincir (uyar) ile 6 turluk zincir (zor) ve uç durumlardaki tek tur ile **çok kısa parola**yı deneyin — ya da kendi parola:tur çiftinizi yazın (gösterim için tur sayısı 1-6 ile sınırlıdır; gerçek demo 100.000+ tur kullanır).

7. Ana sırdan anahtar türetme, oturum anahtarları ve ileri gizlilik¶

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:

• Extract: ana sır + tuz → tekdüze bir ara anahtar (PRK).
• Expand: PRK + "info" etiketi → istenen boyda anahtar. Farklı info → farklı anahtar.

7.1 İleri gizlilik (forward secrecy)¶

Anahtarları bir tek yönlü zincir olarak türetirsek — K0 = ana sır, Kᵢ = HKDF(Kᵢ₋₁) — ve her oturumdan sonra Kᵢ₋₁'i silersek, saldırgan bugünkü Kₙ'i ele geçirse bile geriye gidip eski K1..Kₙ₋₁'i (ve o oturumların verisini) hesaplayamaz. TLS 1.3 bu güvenceyi her oturumda geçici Diffie-Hellman ile sağlar (kitap tarif 8.20–8.21).

Demo 5 — HKDF ile oturum anahtarları ve ileri gizlilik zinciri¶

Separate keys per purpose, from one master secret:
  info='...encryption...' -> 5a5ed417c87e3566...0d37002cb
  info='...MAC...'        -> 4c63a348654a076c...0ce1750e6
  ^ Same secret, different info -> different key.
==============================================================
FORWARD SECRECY chain: Ki = HKDF(Ki-1), Ki-1 is wiped
  K1 (session 1) = cbbe8fdd0b6ca8be
  K2 (session 2) = 1113abf7352881e0
  K3 (session 3) = a99c7ad8e0e6fb6b
  K4 (session 4) = 4974f0e86d9dcb37
  ^ We now only have K4. Because the chain is ONE-WAY, K3, K2, K1
    cannot be recomputed backwards from K4.

Aynı ana sırdan farklı info etiketleriyle farklı anahtarlar çıktı; bir amaç için üretilen anahtar başka amaca kullanılamaz. İleri gizlilik zincirinde her adımda eski anahtar crypto_wipe (OPENSSL_cleanse/SecureZeroMemory) ile silindi; elde yalnız son anahtar kaldı ve tek yönlülük geçmişi korudu.

Aşağıdaki animasyonda Extract ve Expand'in ana sırdan nasıl amaca özel anahtarlar ürettiğini, sonra ileri gizlilik zincirinin her adımda eski anahtarı nasıl sildiğini izleyin.

Örnek seçiciden 4 adımlık zincir (uyar, gerçek demoyla aynı) ile 6 adımlık zincir (zor) ve uç durumlardaki tek adım ile **hiç ilerlemeyen zincir**i deneyin — ya da kendi ana_sır:adım çiftinizi yazın.

8. Dinamik anahtar yönetimi: yaşam döngüsü, hiyerarşi ve yenileme¶

"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: kaynak koda gömülmüş anahtar, hiç değişmeyen anahtar, her işe koşulan tek anahtar, silinmeyen eski anahtar. Kitap anahtar malzemesinin güvenli yönetimini Tarif 4.13'te kısaca işler; bu bölümde konuyu sahada kullanılan biçimiyle genişletiyoruz.

Bir anahtarın hayatı¶

NIST SP 800-57, bir anahtarın yaşam döngüsünü durumlarla tanımlar. Sade haliyle:

Kripto-periyot, bir anahtarın kullanılmasına izin verilen süredir. Süre dolduğunda anahtar yeni veriyi şifrelemek için kullanılmaz, ama eski veriyi çözmek için bir süre daha tutulabilir. Kripto-periyodu belirleyen etkenler: anahtarla korunan verinin miktarı, verinin ne kadar süre gizli kalması gerektiği, anahtarın ne kadar açıkta durduğu. İstemci cihazında duran bir anahtar, HSM'de duran bir anahtardan çok daha kısa ömürlü olmalıdır.

Anahtar hiyerarşisi: her işe ayrı anahtar¶

Tek bir anahtarla her şeyi yapmak yerine, anahtarlar bir ağaç halinde düzenlenir. Üstteki anahtarlar az kullanılır ve en iyi korunan yerde durur; alttakiler sık kullanılır, kısa ömürlüdür ve kaybedildiklerinde zarar küçüktür.

İki temel fikir:

1. Anahtar ayrımı: Farklı amaçlar için farklı anahtarlar. Şifreleme anahtarı imzalamada, MAC anahtarı şifrelemede kullanılmaz. HKDF'nin info etiketi bu ayrımı kolaylaştırır (önceki bölüm).
2. Zararın sınırlanması: Alt düzeydeki bir anahtarın ele geçirilmesi yalnız o dalı etkiler. Tek kullanımlık bir ödeme anahtarı çalınırsa kaybedilen tek bir işlemdir.

Zarflama (envelope encryption)¶

Büyük miktarda veriyi doğrudan ana anahtarla şifrelemek iki sorun yaratır: ana anahtar sık kullanılır (açıkta kalma süresi artar) ve anahtar değiştiğinde bütün veri yeniden şifrelenmelidir. Zarflama bu iki sorunu çözer:

1. Her dosya ya da kayıt için rastgele bir veri anahtarı (DEK) üretilir; veri bununla şifrelenir.
2. DEK, bir anahtar şifreleme anahtarıyla (KEK) sarılır (şifrelenir) ve şifreli verinin başlığına yazılır.
3. KEK güvenli bir yerde durur: işletim sisteminin anahtar deposu, TPM, HSM ya da bulut anahtar yönetim hizmeti.
4. KEK yenilendiğinde yalnız küçük DEK'ler yeniden sarılır.

Bulut sağlayıcılarının anahtar yönetim hizmetleri (KMS) ve disk şifreleme sistemleri bu yöntemi kullanır.

Anahtar sürümü: yenilemeyi mümkün kılan küçük alan¶

Bir anahtarı yenileyebilmek için, şifreli verinin hangi anahtarla şifrelendiğini bilmek gerekir. Bu yüzden şifreli verinin başlığına bir anahtar kimliği / sürüm alanı konur:

Okuyucu önce sürüme bakar, o sürümün anahtarını bulur ve çözer. Yeni yazmalar hep en yeni anahtarla yapılır; eski kayıtlar okundukça (ya da arka planda) yeni anahtarla yeniden şifrelenir. Başlık AAD olduğu için saldırgan sürüm alanını değiştirip uygulamayı eski, zayıf bir anahtara yönlendiremez.

Anahtarı nerede saklamalı?¶

#include <windows.h>
#include <dpapi.h>
#pragma comment(lib, "crypt32.lib")

int wrap_key(const BYTE *key, DWORD n, DATA_BLOB *out)
{
    DATA_BLOB in = { n, (BYTE *)key };
    /* out->pbData is freed with LocalFree once you're done with it */
    return CryptProtectData(&in, L"vault-key", NULL, NULL, NULL,
                            CRYPTPROTECT_UI_FORBIDDEN, out) ? 0 : -1;
}

Sahadan: kart şeması gereksinimleri ve bir anahtar envanteri¶

Mobil ödeme uygulamalarının uyması gereken kart şeması güvenlik gereksinimleri, bu bölümde anlattıklarımızı madde madde ister. İki şemanın (burada Şema-A ve Şema-B) kripto ve anahtar gereksinimlerinin özeti:

Bu gereksinimleri karşılayan bir kütüphanenin kılavuzu, anahtarları dört gruba ayırır:

Aynı kılavuz iki önemli olumsuz beyanda da bulunur: kütüphane hesap parametreleri için anahtar üretmez ve ödeme için istemcide rastgele sayı üretmez. Bir değerlendirici için "yapmıyoruz" demek de "yapıyoruz" demek kadar değerlidir; saldırı yüzeyini daraltır.

Oturum anahtarları: sahadan bir örnek ve eleştirel okuma¶

İstemci ile sunucu arasında TLS'in üstüne ikinci bir koruma katmanı kurulduğunda, bu katmanın anahtarları oturum başına türetilir. Sahadan bir tasarımın ana hatları (adlar genelleştirilmiştir):

1. Sunucu 32 baytlık bir oturum kimliği üretir, bunu istemciye özgü yapılandırma anahtarıyla şifreler ve anlık bildirim kanalıyla (ya da istemcinin yeni oturum isteğine yanıt olarak) gönderir.
2. İstemci oturum kimliğini korunan anahtarla (whitebox AES, 11. hafta) çözer.
3. Kimlik doğrulama kodu: çözülmüş oturum kimliğinin bir kısmı, cüzdan kimliği ve cihaz parmak izi birlikte SHA-256'dan geçirilir. Sunucu aynı değeri kendisi hesaplar; iki taraf da karşısındakinin gerçek olduğunu doğrulamış olur.
4. Oturum anahtarı: yapılandırma anahtarının özeti bir ana anahtar olarak kullanılır; çözülmüş oturum kimliği ile bu özetten HMAC yoluyla 16 baytlık bir AES oturum anahtarı türetilir.
5. Mesajlar bu anahtarla AES-CTR kipinde şifrelenir ve her mesaja ayrıca 256 bitlik bir MAC eklenir; alıcı MAC'i doğrulamadan mesajı kullanmaz.

Bu tasarım derinlemesine savunmanın iyi bir örneğidir: TLS kırılsa bile mesajlar ayrıca şifreli ve bütünlük korumalıdır; oturum anahtarı her oturumda değişir; kimlik doğrulama kodu cihaza bağlıdır. Bugün aynı tasarım yeniden yapılsaydı şu iyileştirmeler önerilirdi:

9. Aktarımda veri: TLS 1.3, sertifika doğrulama ve sabitleme¶

TLS (Transport Layer Security), iki uç arasında anahtar anlaşmasını, AEAD ile şifrelemeyi ve sertifika doğrulamasını birleştirip ağ üzerinde güvenli iletişim sağlayan protokoldür — HTTPS'in altındaki katmandır (eski adıyla SSL). Aktarımdaki veriyi koruyan standart budur. Bugün TLS 1.3 kullanılır; SSLv2/SSLv3 ve TLS 1.0/1.1 kırık kabul edilir ve bırakılmıştır (POODLE, BEAST gibi saldırılar).

9.1 TLS 1.3 el sıkışması¶

TLS 1.3'ün iki kilit özelliği: (1) el sıkışma tek gidiş-dönüşte biter (hızlı); (2) anahtar değişimi her zaman geçici (ephemeral) ECDHE ile yapılır, yani ileri gizlilik varsayılan olarak açıktır (RFC 8446).

Aşağıdaki animasyonda el sıkışma mesajlarının sırasını iki yaşam çizgisi (İstemci/Sunucu) üzerinde adım adım izleyin: normal el sıkışma, karşılıklı TLS (mTLS), sertifika reddiyle yarıda kesilen el sıkışma ve doğrulamasız (güvensiz) bir istemcinin yine de tamamlanan ama korunmasız el sıkışması.

Örnek seçiciden normal el sıkışma (uyar) ile karşılıklı TLS (zor) ve uç durumlardaki yarıda kesilen ile doğrulamasız senaryoları deneyin.

9.2 Doğrulamanın üç katmanı — ve en tehlikeli tuzak¶

Bir TLS bağlantısı, karşı tarafın sunduğu sertifikayı doğrulamazsa hiçbir şey ifade etmez. Doğrulama üç sorudan oluşur:

Zincir doğrulama şöyle işler: sunucu bir uç (leaf) sertifika sunar; bu sertifikayı bir ara CA, onu da güvenilir bir kök CA imzalamıştır. İstemci, elindeki güvenilir kök listesine (trust store) ulaşana kadar imzaları yukarı doğru doğrular; ayrıca her sertifikanın süresini ve iptal durumunu (CRL/OCSP) kontrol eder. Demo 6'da bu güven kökünü kendi ürettiğimiz küçük bir CA ile kuruyoruz: "gerçek" sunucu sertifikası bu CA tarafından imzalıdır, "saldırgan" sertifikası ise kendi imzalıdır (kök listesinde yoktur), bu yüzden zincir doğrulaması onu reddeder. PKI, sertifika zincirleri, CRL ve OCSP'yi Hafta 10'da ayrıntılı işleyeceğiz.

9.3 Sabitleme (pinning) ve TOFU¶

• Sertifika sabitleme: İstemci, sunucunun beklenen açık anahtarının (SPKI) SHA-256 özetini gömer. Zincir geçerli olsa bile (ör. saldırgan sahte ama "geçerli" bir sertifika elde etmiş) anahtar tutmuyorsa bağlantı reddedilir. Mobil uygulamalarda yaygındır (OWASP MASVS-NETWORK). Kitap tarif 10.9 buna "beyaz liste ile doğrulama" der.
• TOFU (Trust On First Use): PKI yoksa, ilk bağlantıdaki anahtar hatırlanır; sonraki bağlantılarda değişirse uyarılır. SSH'ın yaptığı budur (kitap tarif 8.19). PKI kadar güçlü değildir ama ilk bağlantıdan sonra araya girmeyi zorlaştırır.

Aşağıdaki animasyonda uygulamaya gömülü birincil ve yedek pin ile sunucunun sunduğu pinin nasıl karşılaştırıldığını izleyin: eşleşme, planlı anahtar rotasyonuyla yedeğe düşme ve hiçbir pinle eşleşmeyen bir saldırı denemesi.

Örnek seçiciden birincil pinle eşleşme (uyar) ile yedek pine düşme (zor) ve uç durumlardaki hiçbir pinle eşleşmeme ile **çok kısa sunucu adı**nı deneyin.

9.4 TLS 1.2'den 1.3'e ne değişti?¶

TLS 1.3 yalnız bir sürüm artışı değil, temiz bir sadeleşmedir. Eski sürümlerde onlarca "şifre takımı" (cipher suite) vardı ve birçoğu zayıftı; yanlış yapılandırma yaygın bir açıktı. TLS 1.3 bunu köklü biçimde temizledi:

Demo 6 — Doğrulamasız istemci → localhost MITM → hostname + SPKI pinning¶

İstemcinin özü:

SSL_CTX_set_min_proto_version(ctx, TLS1_2_VERSION);   /* at least TLS 1.2 */
if (verify) {
    SSL_CTX_load_verify_locations(ctx, ca_pem, NULL);  /* the trusted CA */
    SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL);
    SSL_set1_host(ssl, host);                           /* the hostname! */
}
/* in pin mode: the server's PUBLIC KEY's (SPKI) SHA-256 must match */
i2d_X509_PUBKEY(X509_get_X509_PUBKEY(cert), &der);
EVP_Digest(der, len, actual, NULL, EVP_sha256(), NULL);
if (memcmp(actual, expected_pin, 32) != 0) { /* REJECT */ }

The real server's SPKI pin (SHA-256): 1dabd67747366675...ac36b3f7c
==============================================================
SCENARIO 1 - Insecure client to the ATTACKER's server (port 14444):
[insecure] no verification - ACCEPTS whatever it gets (DANGEROUS).
   ^ The fake certificate was accepted. A MITM would have succeeded.
SCENARIO 2 - Verifying client to the REAL server (port 14443):
[verify] chain + hostname VERIFIED - ACCEPTED.
SCENARIO 3 - Verifying client to the ATTACKER's server (port 14444):
[verify] HANDSHAKE FAILED - connection REJECTED.
   Reason: certificate verification error (18: self signed certificate)
SCENARIO 4 - Pinning client to the REAL server, with the CORRECT pin:
[pin] the SPKI pin MATCHED - connection ACCEPTED.
SCENARIO 5 - Pinning client to the ATTACKER's server, with the REAL pin:
[pin] the SPKI pin did NOT match - connection REJECTED.
   ^ The key did not match: pinning stopped the MITM.

Beş senaryo tek bir hikâye anlatır: doğrulamasız istemci saldırganın sahte sertifikasını sorgusuz kabul eder (MITM başarılı olurdu). Zincir + hostname doğrulaması saldırganın kendi imzalı sertifikasını reddeder. SPKI sabitleme ise saldırgan zincir açısından "geçerli" bir sertifika bulsa bile, beklenen anahtar tutmadığı için bağlantıyı keser.

10. TLS'i kodda doğru kurmak: adım adım istemci, sabitleme ve sık hatalar¶

Önceki bölüm TLS 1.3'ün ne yaptığını ve Demo 6 doğrulamasız bir istemcinin nasıl kandırıldığını gösterdi. Bu bölümde bir TLS istemcisini satır satır doğru kurmayı, sabitlemeyi sahada sürdürülebilir biçimde uygulamayı ve gerçek uygulamalarda en sık görülen hataları işliyoruz. Kitap bu konuyu Tarif 9.1 (SSL istemcisi), 10.7 (karşı tarafın sertifikasını doğrulama), 10.8 (ana makine adı denetimi) ve 10.9 (beyaz listeyle doğrulama) ile anlatır; aşağıdaki kod bu tariflerin OpenSSL 1.1.⅓.x'e güncellenmiş halidir.

OpenSSL ile doğru bir istemci: yedi adım¶

#include <openssl/ssl.h>
#include <openssl/err.h>

/* Returns a BIO that can be read/written on success; call BIO_free_all + SSL_CTX_free when done. */
BIO *tls_connect(SSL_CTX **ctx_out, const char *host, const char *port)
{
    BIO *bio = NULL;
    SSL *ssl = NULL;
    SSL_CTX *ctx = SSL_CTX_new(TLS_client_method());                 /* 1 */
    if (!ctx) return NULL;
    SSL_CTX_set_min_proto_version(ctx, TLS1_2_VERSION);             /* 2 */
    SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL);                  /* 3 */
    if (SSL_CTX_set_default_verify_paths(ctx) != 1) goto fail;       /* 4 */

    if ((bio = BIO_new_ssl_connect(ctx)) == NULL) goto fail;
    BIO_get_ssl(bio, &ssl);
    SSL_set_tlsext_host_name(ssl, host);                             /* 5: SNI */
    if (SSL_set1_host(ssl, host) != 1) goto fail;                    /* 6: hostname check */
    BIO_set_conn_hostname(bio, host);
    BIO_set_conn_port(bio, port);

    if (BIO_do_connect(bio) <= 0 || BIO_do_handshake(bio) <= 0) goto fail;
    if (SSL_get_verify_result(ssl) != X509_V_OK) goto fail;          /* 7 */

    *ctx_out = ctx;
    return bio;
fail:
    ERR_print_errors_fp(stderr);
    BIO_free_all(bio);
    SSL_CTX_free(ctx);
    return NULL;
}

Sabitlemeyi eklemek: SPKI özeti¶

Doğrulama başarılı olduktan sonra sunucunun açık anahtarının özeti, uygulamaya gömülü listeyle karşılaştırılır. Sertifikanın kendisi yerine açık anahtar bilgisinin (SPKI) sabitlenmesi, sertifika aynı anahtarla yenilendiğinde uygulamanın çalışmaya devam etmesini sağlar.

#include <openssl/x509.h>
#include <openssl/sha.h>

static const unsigned char TRUSTED_PINS[][32] = {
    { /* the primary key's SPKI SHA-256 digest (32 bytes) */ },
    { /* the BACKUP key's digest: generated offline, not yet in use */ },
};

int check_pin(SSL *ssl)
{
    X509 *cert = SSL_get_peer_certificate(ssl);    /* 3.x: SSL_get1_peer_certificate */
    if (!cert) return 0;
    X509_PUBKEY *pk = X509_get_X509_PUBKEY(cert);
    int n = i2d_X509_PUBKEY(pk, NULL);
    unsigned char *der = OPENSSL_malloc((size_t)n), *p = der;
    i2d_X509_PUBKEY(pk, &p);                        /* p advances; der stays at the start */
    unsigned char digest[32];
    SHA256(der, (size_t)n, digest);
    OPENSSL_free(der);
    X509_free(cert);

    for (size_t i = 0; i < sizeof TRUSTED_PINS / sizeof TRUSTED_PINS[0]; i++)
        if (CRYPTO_memcmp(digest, TRUSTED_PINS[i], 32) == 0)
            return 1;
    return 0;                                       /* no match: CUT the connection */
}

Bir sunucunun SPKI özetini komut satırından hesaplamak:

openssl s_client -connect server.example:443 -servername server.example </dev/null 2>/dev/null \
  | openssl x509 -pubkey -noout \
  | openssl pkey -pubin -outform der \
  | openssl dgst -sha256 -binary | base64

Sabitlemeyi sahada sürdürmek¶

Sabitleme güçlü ama kırılgan bir önlemdir: sunucunun anahtarı değiştiğinde, eski sürümdeki bütün uygulamalar bağlanamaz hale gelir. Tarayıcılar bu yüzden HTTP üzerinden dinamik sabitlemeyi (HPKP) 2018'de bıraktı; mobil ve masaüstü uygulamalarda ise sabitleme hâlâ yaygındır (OWASP MASVS-NETWORK). Sürdürülebilir bir sabitleme için:

Windows'ta TLS: WinHTTP ve Schannel¶

Windows'un yerleşik TLS yığını Schannel'dır; uygulamalar çoğunlukla onu WinHTTP ya da WinINet üzerinden kullanır (kitabın Tarif 9.4'te anlattığı WinInet'in güncel karşılığı). OpenSSL'in tersine WinHTTP, sertifikayı ve ana makine adını varsayılan olarak doğrular. Tehlike, bu doğrulamayı kapatan bayraklardadır:

DWORD flags = SECURITY_FLAG_IGNORE_UNKNOWN_CA |
                  SECURITY_FLAG_IGNORE_CERT_CN_INVALID |
                  SECURITY_FLAG_IGNORE_CERT_DATE_INVALID;
WinHttpSetOption(request, WINHTTP_OPTION_SECURITY_FLAGS, &flags, sizeof flags);

Bu satır genellikle geliştirme sırasında kendi imzalı bir test sunucusuna bağlanmak için eklenir ve unutulur. Doğrusu, test sunucusunun CA'sını geliştirme makinesinin güven deposuna eklemektir; kod aynı kalır. WinHTTP'de sabitleme için, istek gönderildikten sonra WinHttpQueryOption(..., WINHTTP_OPTION_SERVER_CERT_CONTEXT, ...) ile sunucu sertifikası alınır ve açık anahtar bilgisinin özeti yukarıdaki gibi karşılaştırılır.

Eleştirel okuma: sessizce açılan kapı (fail-open)¶

Sahada kullanılmış bir sabitleme gerçekleştiriminin sadeleştirilmiş ve yeniden yazılmış hali aşağıdadır. Kod ilk bakışta doğru görünür: önce zinciri doğruluyor, sonra sunucunun açık anahtarını uygulamada saklanan anahtarla karşılaştırıyor. Hatayı bulabilir misiniz?

public void checkServerTrusted(X509Certificate[] chain, String authType) throws CertificateException {
    defaultValidator.checkServerTrusted(chain, authType);          // 1. chain validation
    try {
        PublicKey expected = keyStore.getCertificate("ca").getPublicKey();
        if (!Arrays.equals(expected.getEncoded(), chain[0].getPublicKey().getEncoded()))
            throw new CertificateException("pin did not match");    // 2. pinning
    } catch (KeyStoreException e) {
        e.printStackTrace();                                         // 3. ???
    }
}

3 numaralı satır, anahtar deposundan okuma başarısız olursa hatayı yazdırıp metodu normal biçimde bitirir. Metot istisna fırlatmadan döndüğü için bağlantı kabul edilir: sabitleme hiç yapılmamış olur. Bir güvenlik denetiminin hata durumunda "geçti" sonucuna düşmesine fail-open (açık kalarak başarısız olma) denir. Aynı kod tabanında dikkat çeken başka noktalar da vardı:

• Zincir doğrulaması başarısız olduğunda, uygulamaya gömülü depo ile ikinci bir doğrulama yapılıyor ve bu ikinci doğrulamada iptal denetimi kapatılıyordu.
• Sertifika dosyası ya da onun bütünlük belirteci bulunamazsa, yalnız bir günlük satırı yazılıp bağlantı kurulmaya devam ediliyordu.
• Tek bir pin vardı; yedek pin yoktu.

Doğrusu fail-closed (kapalı kalarak başarısız olma) tasarımdır: bir güvenlik denetiminin sonucunu belirleyemiyorsanız, sonuç "reddet"tir.

    } catch (KeyStoreException | RuntimeException e) {
        throw new CertificateException("pin check could not be performed", e);   // ambiguity = reject
    }

Gerçek uygulamalarda en sık TLS hataları¶

Kendi bağlantınızı test etmek¶

# Sürüm, şifre takımı ve sertifika zincirini göster; doğrulama hatasında dur
openssl s_client -connect server.example:443 -servername server.example \
                 -verify_return_error -brief </dev/null

# TLS 1.1'i dene: sunucu reddetmeli
openssl s_client -connect server.example:443 -tls1_1 </dev/null

11. Beklemede veri: dosya ve veritabanı şifreleme¶

Diskteki dosya ya da veritabanı çalınabilir (kayıp telefon, çalınan yedek, ele geçirilen sunucu). Beklemede veriyi korumanın iki düzeyi vardır:

• Tüm disk/dosya şifreleme: İşletim sistemi düzeyinde (LUKS, BitLocker, XTS-AES) ya da uygulama düzeyinde tüm dosyayı AEAD ile şifreleme (bkz. Demo 1). Kitap tarif 5.15 disk şifrelemeyi işler; sabit IV tuzağına dikkat çeker.
• Alan/sütun şifreleme: Yalnız hassas alanları (kart no, TC kimlik, sağlık verisi) uygulama katmanında şifreleyip veritabanına şifreli yazma. Veritabanı çalınsa bile o alanlar okunamaz.

Veri maskeleme ayrı bir tekniktir: veriyi geri döndürülemez ya da kısmi biçimde gösterme. Şifreleme değildir (anahtarla geri açılmaz); amacı, verinin gereksiz yere maruz kalmasını azaltmaktır. Başlıca biçimleri:

• Kısmi maskeleme: yalnız bir kısmını gösterme, ör. kart no **** **** **** 4242, e-posta a***@ornek.com. Kullanıcı arayüzünde ve müşteri hizmetleri ekranlarında kullanılır.
• Loglama maskesi: loglara hassas alan hiç yazılmaz ya da maskeli yazılır. (Hafta 1'de gördüğümüz "sırrı loglama" hatasının veri tarafı.)
• Tokenizasyon: gerçek değeri anlamsız bir "token" ile değiştirip gerçek değeri ayrı, güvenli bir kasada tutma. Ödeme sistemlerinde kart numarası yerine token dolaşır; asıl numara yalnız gerekince kasadan çözülür.
• Test verisi maskeleme: üretim verisini test/geliştirme ortamına kopyalarken gerçek kişisel veriyi sahte ama gerçekçi değerlerle değiştirme.

Maskeleme şifrelemenin yerine geçmez; onu tamamlar. Veri diskte AEAD ile şifreli durur (gizlilik), ekrana/loga giderken maskelenir (maruz kalmayı azaltma). İkisi farklı tehditlere karşıdır: biri dosyanın çalınmasına, diğeri "yanlış kişinin ekranda/logda görmesine".

Demo 7 — SQLite'ta hassas alanı AES-GCM ile şifreleme¶

STEP 1 - Set up the database (the sensitive field is encrypted)
Database created: output\customers.db (2 records)
STEP 2 - An attacker stole the raw DB file and is searching it:
   'Jane' (name) in the raw DB      : FOUND (the name field is plain)
   '4242-4242' (card) in the raw DB : NOT THERE - encrypted
STEP 3 - The application reads with the correct key (decrypt and verify):
    1 | Jane Doe      | 4242-4242-4242-4242
    2 | John Smith    | 5555-4444-3333-2222
STEP 4 - A read attempt with the WRONG key (the GCM tag will not match):
    1 | Jane Doe      | (COULD NOT DECRYPT - wrong key?)
    2 | John Smith    | (COULD NOT DECRYPT - wrong key?)

Saldırgan sqlite3 ile DB'yi açsa bile name alanını görür ama card_encrypted alanı yalnız şifreli bayttır. Doğru anahtarla uygulama açıp doğrular; yanlış anahtarla GCM etiketi tutmadığı için çözme reddedilir (sessizce çöp döndürmez). Windows demosu (.\demo.ps1) sqlite3 aracı yerine ham DB dosyasında arama yaparak aynı noktayı gösterir: Jane (açık ad) bulunur, 4242-4242 (kart) bulunmaz çünkü şifrelidir.

Aşağıdaki animasyonda iki müşteri satırının card_encrypted alanını doğru ve yanlış anahtarla okuma denemesini izleyin: doğru anahtarla her satır çözülür, yanlış anahtarla HER satır reddedilir.

Örnek seçiciden gerçek demonun kayıtları, doğru anahtar (uyar) ile farklı kayıtlar (zor) ve uç durumlardaki yanlış anahtar ile **çok kısa kart alanları**nı deneyin — ya da kendi ad:kart çiftlerinizi yazın.

12. Veri maskeleme teknikleri: veriyi göstermeden kullanmak¶

Şifreleme, veriyi anahtarı olmayan herkesten saklar. Ama birçok durumda veriyi anahtarı olan sistemlerin ve kişilerin bile tam olarak görmesi gerekmez: çağrı merkezi çalışanı müşterinin kart numarasının tamamını değil son dört hanesini görmelidir; test ortamındaki veritabanı gerçek kişilerin kimlik numaralarını içermemelidir; günlük dosyası parolayı hiç görmemelidir. Veri maskeleme, verinin kullanım amacına yetecek kadarını gösterip gerisini gizleme teknikleri ailesidir. Kişisel verilerin korunması mevzuatı (KVKK, GDPR) ve ödeme kartı standardı (PCI DSS), bu teknikleri açıkça ister.

Dört temel teknik¶

Aralarındaki fark hukuken de önemlidir: takma adlandırılmış veri hâlâ kişisel veridir (anahtarı olan kişiyi bulabilir); gerçekten anonimleştirilmiş veri ise kişisel veri sayılmaz. Birçok "anonim" veri kümesinin, başka verilerle birleştirilerek kişilere geri bağlanabildiği gösterilmiştir. Bu yüzden "anonimleştirdik" demek, "takma ad verdik" demekten çok daha güçlü bir iddiadır.

1. Gösterimde maskeleme¶

Kart numarası (PAN) için PCI DSS kuralı nettir: numara görüntülendiğinde en fazla ilk altı (ya da standardın yeni sürümlerinde kart türüne göre sekiz) ve son dört hane gösterilebilir; işi gereği tam numarayı görmesi gereken roller ayrıca tanımlanır.

#include <string.h>

/* "1234567812345678" -> "************5678"; out must be at least n+1 bytes */
void mask_pan(const char *pan, char *out, size_t out_size)
{
    size_t n = strnlen(pan, 19);
    if (out_size < n + 1) { if (out_size) out[0] = '\0'; return; }
    for (size_t i = 0; i < n; i++)
        out[i] = (i + 4 < n) ? '*' : pan[i];
    out[n] = '\0';
}

Maskeleme kaynağa yakın yapılmalıdır: tam değer sunucudan istemciye gönderilip ekranda maskelenirse, ağ trafiğini ya da istemci belleğini inceleyen biri tam değeri görür. Doğrusu, istemciye zaten maskelenmiş değeri göndermektir.

2. Tokenizasyon¶

Tokenizasyonun gücü, gerçek verinin tek bir küçük ve çok iyi korunan sistemde toplanmasıdır. Uygulamanın geri kalanı, veritabanları, raporlar ve günlükler yalnız belirteci görür; bunlar ele geçirilse bile kart verisi sızmaz. Bu, 1. haftadaki "tehdidi aktarma" yanıtının teknik karşılığıdır: kart verisini hiç saklamayıp ödeme sağlayıcısının belirteç hizmetini kullanmak, uygulamanın PCI DSS kapsamını büyük ölçüde küçültür. Mobil ödemede telefona indirilen kart bilgisi de gerçek kart numarası değil, cihaza özgü bir belirteç numarasıdır.

Belirtecin biçimi korunabilir: 16 haneli bir kart numarası yerine yine 16 haneli ama anlamsız bir sayı. Bu, eski sistemlerin (alan uzunluğu, doğrulama kuralları) değiştirilmeden kullanılmasını sağlar. Biçimi koruyan şifreleme (format-preserving encryption, NIST SP 800-38G'deki FF1 algoritması) aynı işi bir anahtar ve kasa olmadan yapar.

3. Takma adlandırma: anahtarlı özet¶

Analiz ya da test için "aynı kişinin kayıtlarını bir araya getirebilmek ama kim olduğunu bilmemek" gerekir. Kimlik numarasını düz bir özetten (SHA-256) geçirmek yetmez: 11 haneli bir kimlik numarasının olası değer sayısı küçüktür ve saldırgan hepsinin özetini hesaplayıp karşılaştırabilir. Doğrusu, gizli bir anahtarla HMAC kullanmaktır:

/* code/common/cen429_crypto.h */
unsigned char pseudonym[32];
crypto_hmac_sha256(pseudonym_key, 32, id_number, strlen(id_number), pseudonym);
/* the data set stores the first 16 bytes of hex(pseudonym) instead of id_number */

Anahtar veri kümesinden ayrı tutulur. Anahtarı olmayan için takma addan kimlik numarasına dönmek, olası bütün kimlik numaralarını denemek anlamına gelir ve anahtar bilinmeden bu mümkün değildir. Anahtar kaybolursa ya da imha edilirse, veri fiilen anonimleşir.

4. Test ve geliştirme verisi¶

Gerçek üretim verisinin test ortamına kopyalanması, en sık görülen veri sızıntısı nedenlerinden biridir: test ortamları daha az korunur, daha çok kişi erişir. Test verisi için sırasıyla tercih edilecekler:

1. Tamamen sentetik veri: Gerçek kayıtlardan hiç türetilmemiş, üretilmiş veri. En güvenli seçenek.
2. Statik maskeleme: Üretim verisinin bir kopyası alınır, kopyadaki hassas alanlar kalıcı olarak değiştirilir (takma ad, karıştırma, genelleme) ve ancak ondan sonra test ortamına taşınır.
3. Dinamik maskeleme: Veri değiştirilmez; veritabanı sorgu sonucunu kullanıcının rolüne göre maskeleyerek döndürür. Kullanışlıdır ama veri tabanında tam haliyle durmaya devam eder.

5. Günlüklerde ve hata iletilerinde maskeleme¶

İkinci haftada denetim kaydının "asla kaydetme" listesini görmüştük: parola, PIN, belirteç, anahtar, tam kart numarası. Kural bir şeydir, onu garanti etmek başka. İki yaklaşım birlikte kullanılır:

• Kaynakta önleme: Hassas veriler özel bir türde tutulur ve bu türün yazdırma fonksiyonu her zaman maskeli çıktı verir. Programcı yanlışlıkla günlüğe yazsa bile tam değer çıkmaz.
• Çıkışta süzme: Günlük kütüphanesinin son adımında, kart numarasına benzeyen (13–19 haneli, Luhn denetimini geçen) diziler ve password=, token= gibi anahtarlardan sonra gelen değerler otomatik olarak maskelenir.

#include <string.h>
#include <ctype.h>

void log_filter(char *line)
{
    static const char *keys[] = { "password=", "pin=", "token=" };
    for (size_t k = 0; k < sizeof keys / sizeof keys[0]; k++) {
        char *p = line;
        while ((p = strstr(p, keys[k])) != NULL) {
            p += strlen(keys[k]);
            while (*p && !isspace((unsigned char)*p))
                *p++ = '*';                    /* mask the value in place */
        }
    }
}

Hangi tekniği ne zaman?¶

Aşağıdaki animasyonda aynı değerin üç farklı teknikle nasıl işlendiğini izleyin: kısmi maskeleme (yalnız ilk/son karakterler kalır), tokenizasyon (anlamsız bir simge + korumalı kasa) ve takma adlandırma (anahtarlı özet).

Örnek seçiciden kısmi maskeleme (uyar) ile tokenizasyon (zor) ve uç durumlardaki takma adlandırma ile **çok kısa bir değer**i deneyin — ya da kendi değer|teknik çiftinizi yazın.

13. Kullanımda veri: bellekte güvenli silme ve cihaz bağlama¶

Bir sır kullanılmak için eninde sonunda bellekte açılır. O anda risk altındadır: bellek dökümü, hata ayıklayıcı, takas alanı (swap), aynı belleği sonra kullanan başka kod. Hafta 1, §17'de explicit_bzero ile "ölü yazma giderme"yi ve sırrı bellekten silmeyi (Tarif 13.2), ayrıca belleğin diske yazılmasını önlemeyi (Tarif 13.3) görmüştük; bu hafta kullanımda veri için döküm engelleme, bellek kilitleme ve cihaz bağlama katmanlarını ekliyoruz.

Demo 8 — mlock + güvenli silme¶

Layer 1 - crash dump turned off (RLIMIT_CORE=0): OK
Layer 2 - mlock blocked writing to swap: OK
Secret in use: length = 23, non-zero bytes = 23
Layer 3 - non-zero bytes after secure wipe = 0
   ==> the secret was cleared from memory.
--------------------------------------------------------------
OPENSSL_cleanse call count -> 2

Windows'ta (.\demo.ps1) aynı üç katman SetErrorMode + VirtualLock + SecureZeroMemory ile kurulur; çıktı da "TAMAM"dır. memset'in aksine OPENSSL_cleanse/SecureZeroMemory çağrısı derleyici tarafından "ölü yazma" olarak kaldırılamaz — makine kodunda gerçek bir çağrı olarak kalır (demo bunu objdump ile sayar).

13.1 Cihaz bağlama¶

Kullanımda korumanın bir parçası da anahtarın belirli bir cihaza/sürüme bağlanmasıdır. Anahtarı, cihazın parmak izinden (üretici, model, cihaz kimliği, sürüm dizesi) türetilen bir değerle sararsak, dosyalar başka bir cihaza kopyalansa bile orada açılamaz. Doğru yol: XOR ya da tuzsuz özet değil, HKDF ile tuzlanmış türetme ve AEAD ile sarma. Bölüm 14'daki güvenlik kabuğunun en iç katmanı tam olarak budur; bunu Hafta 6'da RASP ile birleştireceğiz.

Aşağıdaki animasyonda üç katmanın (döküm engelleme, bellek kilitleme, güvenli silme) bir sırrı bellekte adım adım nasıl koruduğunu ve silme sonrası her baytın gerçekten sıfırlandığını izleyin.

Örnek seçiciden orta uzunlukta bir sır (uyar) ile demonun gerçek sırrına yakın, uzun bir sır (zor) ve uç durumlardaki tek karakterlik sır ile **özel karakterler**i deneyin — ya da kendi sır metninizi yazın.

14. Güvenlik kabukları: derinlemesine savunmanın somut hâli¶

Şimdi bu haftanın bütün parçalarını tek bir fikirde birleştiriyoruz. Hassas bir varlığı tek bir korumaya bırakmayız; onu, yaşam döngüsünün her aşamasına karşılık gelen iç içe kabuklarla sararız:

Saldırganın sırra ulaşması için dört kabuğu da sırayla açması gerekir: TLS'i kır, mesaj şifrelemesini kır, depolama şifrelemesini kır ve doğru cihazda ol. Bu, "aktarımda yalnız TLS'e güvenmeme", "beklemede alan şifreleme" ve "kullanımda cihaz bağlama" ilkelerinin tek tabloda birleşmiş hâlidir.

Demo 9 — Bir anahtarı dört kabukla sarıp açmak¶

WRAPPING (outward): secret -> K1 -> K2 -> K3 -> K4
  Layer 1 (device binding)     :  44 bytes
  Layer 4 (channel/TLS-like)   : 128 bytes  <- transmitted packet
UNWRAPPING (inward): K4 -> K3 -> K2 -> K1 -> secret
  Layer 4 opened: OK
  Layer 3 opened: OK
  Layer 2 opened: OK
  Layer 1 opened: OK
  Recovered SECRET : deadbeef0123456789abcdeffedcba98  -> secret CORRECT
==============================================================
ATTACK 1 - if one bit of the packet is tampered with (Layer 4):
  Layer 4 opened: REJECTED  (the GCM tag did not match)
==============================================================
ATTACK 2 - if the packet is copied to ANOTHER device (wrong fingerprint):
  Outer 3 layers opened: OK
  Layer 1 (device binding) opened on the OTHER device: REJECTED
  ^ Even with the keys copied, the secret CANNOT be opened on another device.

Normal akışta dört kabuk sırayla açıldı ve sır doğru geri geldi. Tek bir bit kurcalanınca en dış GCM etiketi tuttu ve o katmanda reddedildi. Paket başka bir cihaza taşındığında dış üç kabuk (anahtarları taşınabilir) açıldı ama cihaza bağlı en iç kabuk açılamadı — sır ele geçmedi. Gerçek ürünlerde bu en iç kabuk çoğu zaman whitebox kripto olur (Hafta 11).

Bu kabuk yaklaşımı dönemin geri kalanına köprüdür: native kod sağlamlaştırma (hardening) ve RASP (Hafta 4, 6, 9) kabukları çalışma zamanında korur; kripto ve anahtar hiyerarşisi (Hafta 10) kabukların anahtarlarını doğru üretir ve yönetir; whitebox (Hafta 11) en iç kabuğu güçlendirir; sertifikasyon (Hafta 12–13) bütün bu katmanların kanıtını ister. Yani bu haftanın veri güvenliği bölümü, güvenlik kılavuzunuzun (S5, S7) omurgasıdır ve ilerideki her hafta bir kabuğu daha somutlaştırır.

Sahadaki kabuk matrisi: bir varlık, beş aşama¶

Demo 9, fikri sade tutmak için dört kabuğun hepsini AES-GCM ile kurdu. Bağımsız bir laboratuvarın sertifikasyonundan geçmiş bir mobil ödeme kütüphanesinde ise kabuklar şöyle tanımlanmıştı (adlar genelleştirilmiştir):

Asıl öğretici olan, aynı varlığın yaşam döngüsündeki her aşamada hangi kabukların bulunduğunu gösteren matristir:

Matrisin okunuşu:

• Varlık dışarıdan içeriye, yani kullanım anına yaklaştıkça kabuklar birer birer açılır. Ama en içteki aşamada bile (native tarafta ödeme hesabı) bir kabuk kalır: anahtar, whitebox biçimiyle kullanılır ve hiçbir zaman açık hale gelmez.
• Kabuklar yalnız hassas varlıklar için dört katlıdır. Daha az hassas ("normal") varlıklar beklemede tek bir kabukla, aktarımda yalnız dış iki kabukla korunur. Her varlığa en güçlü korumayı uygulamak performans ve bakım maliyetini gereksiz yere artırır; varlık tablosundaki C/I sınıflandırması bu kararın dayanağıdır.
• Kullanımda kalan açıklığı (bellekteki işlem anı) kabuklar değil, RASP ve kod sağlamlaştırma korur (4, 6 ve 9. haftalar).
• Kütüphane yerel veritabanında (SQLite) kart profillerini, sınırlı kullanım anahtarlarını, kalan anahtar sayısını, kart durumunu, işlem kayıtlarını ve cihaz parmak izini tutar. Kayıt silindiğinde ya da bir saldırı algılandığında bu tabloların tamamı silinir.

Aşağıdaki animasyonda bir sırrın dört kabukla nasıl sarılıp açıldığını, kurcalanan bir paketin en dış katmanda nasıl reddedildiğini ve başka bir cihaza kopyalanan paketin neden en iç katmanda takılıp kaldığını izleyin.

Örnek seçiciden dört katman da başarıyla açılıyor (uyar/zor) ile uç durumlardaki paket kurcalandı ve başka cihaz senaryolarını deneyin — ya da kendi sır|senaryo çiftinizi yazın.

15. Whitebox kriptografiye giriş (motivasyon)¶

Bütün bu haftanın gizli varsayımı şudur: anahtar kullanıldığı an bellekte açık durur. "Cihazın sahibi saldırgan" (Hafta 1, beyaz kutu) senaryosunda saldırgan belleği okuyabilir, hata ayıklayıcı bağlayabilir; o anı yakalayıp anahtarı çalabilir. Güvenli silme ve bellek kilitleme bu pencereyi daraltır ama kapatmaz.

Whitebox kriptografi bu soruna radikal bir cevaptır: algoritmayı (ör. AES) öyle bir tabloya gömer ki, çalışırken bile ham anahtar hiçbir zaman bellekte açık görünmez; anahtar tabloların içine "pişirilmiştir". Böylece saldırgan belleği tamamen görse bile anahtarı doğrudan okuyamaz. Bu, Bölüm 14'daki güvenlik kabuğunun en iç katmanının gerçek dünyadaki hâlidir.

16. Yaygın yanlış anlamalar¶

17. Dönem projesi: bu hafta¶

Bu hafta güvenlik kılavuzunuzun veri güvenliği bölümlerini yazacaksınız. Vize teslimi için:

• S5 — Varlık listesi (taslak): Projenizdeki her hassas varlığı tabloya dökün. Her varlık için: nerede durur (dosya/DB/bellek), ne zaman oluşur/silinir, gizlilik (C) mi bütünlük (I) mi (ya da I+) gerekir, hangi mekanizmayla korunur.
• S7 — Veri güvenliği + güvenlik kabuğu matrisi: Her varlık için üç durumu (aktarımda/beklemede/kullanımda) ve her durumda hangi kabuğun sarıldığını gösterin. Güvenli silme politikanızı yazın.

| Varlik              | Konum        | C/I | Koruma mekanizmasi           |
| ------------------- | ------------ | --- | ---------------------------- |
| Oturum anahtari     | bellek       | C,I | HKDF + AES-GCM, kullaninca sil |
| Yerel veri anahtari | bellek       | C,I | KDF(parola,tuz) + cihaz baglama |
| Kart no (ornek)     | DB (sifreli) | C,I | AES-256-GCM alan sifreleme   |

| Varlik          | Asama    | Ic kabuk  -> ...  -> Dis kabuk   |
| --------------- | -------- | -------------------------------- |
| Oturum anahtari | aktarim  | cihaz -> depo -> mesaj -> TLS+pin |
| Oturum anahtari | depolama | cihaz -> AES-GCM                 |
| Oturum anahtari | kullanim | kisa omur + guvenli silme        |

18. Sınıf etkinlikleri¶

19. Kod okuma alıştırmaları¶

SSL_CTX *ctx = SSL_CTX_new(TLS_client_method());
SSL *ssl = SSL_new(ctx);
SSL_set_fd(ssl, sock);
if (SSL_connect(ssl) == 1)
    printf("Connection secure!\n");

EVP_DecryptUpdate(c, plain, &len, ct, ct_len);
EVP_DecryptFinal_ex(c, plain + len, &len);   /* dönüş değeri okunmuyor */
use(plain);

unsigned char key[32];
SHA256((unsigned char*)password, strlen(password), key);

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

Bu alıştırmalar not verilmez; pekiştirme içindir. Hepsi kendi bilgisayarınızda, code/week-03 demoları üzerinde yapılır.

21. Kendini sınama¶

22. Quiz-1 tarzı örnek sorular¶

23. Kaynaklar ve ileri okuma¶

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

• Tarif 4.9 (tuz/nonce/IV), 4.10 (paroladan anahtar — PBKDF2), 4.11 (ana sırdan anahtar), 4.13 (anahtar malzemesi yönetimi)
• Tarif 5.15 (dosya/disk şifreleme), 6.18 (şifreleme + bütünlük birlikte)
• Tarif 8.19 (PKI'siz doğrulama / TOFU), 8.20–8.21 (ileri gizlilik)
• Tarif 9.1–9.3 (SSL istemci/sunucu), 10.7–10.9 (sertifika doğrulama, ana makine adı, beyaz liste = pinning)
• Tarif 13.2–13.3 (bellekten güvenli silme, belleğin diske yazılmasını önleme)
• Tarif 11.1–11.4 (rastgele sayı türleri, Unix ve Windows altyapısı), 11.11 (aralıkta sapmasız rastgele tamsayı)
• Tarif 9.4 (Windows'ta WinInet ile güvenli iletişim — bugün WinHTTP/Schannel)

Açık standartlar ve kaynaklar

• NIST SP 800-57 Part 1 (anahtar yönetimi, kripto-periyot), SP 800-90A (rastgele bit üreteçleri), SP 800-38G (FF1, biçimi koruyan şifreleme), SP 800-38C (CCM).
• PCI DSS v4.0 (kart numarasının gösterimde maskelenmesi, tokenizasyon); KVKK ve GDPR'da takma adlandırma ve anonimleştirme.
• M. Georgiev ve diğ., "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software", ACM CCS 2012.

• MITRE CWE: CWE-330 (yetersiz rastgelelik), CWE-338 (zayıf PRNG), CWE-208 (zamanlama farkıyla bilgi sızması), CWE-297 (ana makine adı denetimi eksik), CWE-636 (fail-open: güvenli olmayan başarısızlık), CWE-359 (kişisel veri ifşası), CWE-532 (günlüğe hassas veri yazma).

• NIST SP 800-38D (AES-GCM), SP 800-132 (PBKDF2), SP 800-108 / RFC 5869 (HKDF), RFC 8439 (ChaCha20-Poly1305), RFC 9106 (Argon2), RFC 7914 (scrypt), RFC 8446 (TLS 1.3).

• OWASP: Password Storage Cheat Sheet, Transport Layer Security Cheat Sheet, Certificate and Public Key Pinning, MASVS-CRYPTO / MASVS-NETWORK.
• MITRE CWE: CWE-295 (yanlış sertifika doğrulama), CWE-323 (nonce/IV yeniden kullanımı), CWE-327 (zayıf kripto), CWE-916 (yetersiz maliyetli parola özeti), CWE-311 (şifrelemenin eksikliği).