Hafta 11 — Whitebox Kriptografi¶

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.

# Windows (PowerShell)
.\build.ps1
cd week-11\01-toy-table
.\bin\windows\toy_table.exe
cd ..\02-embedded-key
.\bin\windows\embedded_key.exe --scan

# WSL / Linux
./build.sh
cd week-11/01-toy-table && ./bin/linux/toy_table
cd ../02-embedded-key && ./bin/linux/embedded_key --scan

0. Başlamadan önce¶

Bu bölüm, bu haftayı hangi temeller üzerine kurduğumuzu gösterir: önce önceki haftalardan getirdiğimiz kavramları kısaca hatırlatır, sonra yalnız bu haftaya özgü yeni terimleri (S-box'tan GF(2)'ye) sıfırdan tanımlar; gövdedeki bölümler bu terimleri artık bildiğinizi varsayarak ilerler.

Önceki haftalardan gelenler¶

• Şifreleme, anahtar ve simetrik/asimetrik şifreleme — açık metni bir anahtarla okunamaz şifreli metne dönüştürmek şifrelemedir; simetrik şifreleme (ör. AES) aynı anahtarı kullanıp hızlı çalışır, asimetrik (ör. RSA) açık/gizli anahtar çiftiyle yavaş ama anahtar dağıtımı kolay çalışır; güvenlik anahtarın gizliliğine dayanır, algoritmanın gizliliğine değil (Kerckhoffs ilkesi) (Hafta 3, §2). Bu hafta bu ilkeyi beyaz kutu ortamına taşıyoruz: burada algoritma da anahtar da saldırganın elindedir (§1).
• AES ve bit güvenlik düzeyi — AES en yaygın simetrik şifreleme algoritmasıdır; 16 baytlık bloklar üzerinde, turlar hâlinde bayt değiştirme, satır/sütun karıştırma ve anahtar ekleme adımlarıyla çalışır (ayrıntı bu hafta sınavda sorulmayacak, whitebox için gereken fikir düzeyi yeterlidir). "n-bit güvenlik", bir anahtarı kırmak için kabaca 2ⁿ deneme gerektiği anlamına gelir; AES-128, 128 bit güvenlik sağlar (Hafta 10, §1). Bu hafta ağırlıklı AES üstünden gideceğiz; bit-güvenlik ölçüsünü ise anahtarın kendisi için değil, whitebox tablolarının boyut/hız maliyetini tahmin etmek için yeniden kullanacağız (§3).
• XOR — bitler farklıysa 1, aynıysa 0 veren işlem; a XOR b XOR b == a olduğu için geri alınabilirdir (Hafta 5, §12; 9. haftada dize gizlemede de kullanılmıştı). AES'te "anahtar ekleme" adımı bir XOR'dur (durum XOR anahtar); bu hafta hem Chow AES'in kurulumunda (§3) hem de "yalnız XOR ile karıştırmanın neden işe yaramadığını" gösteren sayısal örnekte (§2) merkezî rol oynar.
• Entropi — bir veri bloğunun ne kadar rastgele/öngörülemez göründüğünün ölçüsü; yüksek entropili bloklar genelde şifreli/rastgele veri, düşük entropili bloklar sıradan metin/veridir (Hafta 2, §6; 9. haftada binary dosya analizinde de görmüştük). Bu hafta entropi taraması, sabit bir diziye gömülmüş bir anahtarı saniyeler içinde bulan statik analiz tekniği olarak karşımıza çıkıyor (§1, §2).
• Hata ayıklayıcı (debugger) — bir programı adım adım çalıştırmanıza, o an bellekte olan her değeri ve işlemci kayıtlarını okumanıza izin veren araç (ör. gdb, x64dbg) (Hafta 6, §4). Bu hafta beyaz kutu saldırganın "çalışmayı gözlemleme" ve "yalnız bir turu çalıştırma" yeteneğinin somut karşılığı tam olarak budur (§1).
• Statik ve dinamik analiz — statik analiz programı çalıştırmadan, dinamik analiz çalıştırarak yapılan incelemedir (Hafta 4, §9). Bu hafta bu ayrımı saldırıları sınıflamak için kullanıyoruz: entropi taraması ve BGE statiktir (§2, §4), DCA ve DFA dinamiktir (§3, §4).
• Enstrümantasyon ve emülatör — enstrümantasyon bir programı çalışırken belirli noktalarda neyin işlendiğini otomatik kaydedecek şekilde donatmaktır; emülatör gerçek işlemciyi yazılımla taklit eden bir araçtır (Hafta 6, §5–§6). Bu hafta bir saldırganın whitebox rutinini binlerce kez otomatik çalıştırıp her arama tablosu erişimini kaydetmesinin — yani DCA'nın ön koşulunun — aracı bu ikisidir (§1, §3–§4).
• HSM ve SoftHSM — HSM, anahtarları saklayıp işleyen, anahtarın hiç dışarı çıkmadığı özel donanımdır; SoftHSM aynı arayüzü (PKCS#11) yazılımla taklit eder ama donanım koruması sağlamaz (Hafta 10, §11). Bu hafta bunları whitebox'ın sunucu tarafı karşılığı olarak, anahtar koruma seçeneklerinin en güçlü ucunda yeniden ele alıyoruz (§5).

Ön bilgi: S-box ve arama tablosu¶

Bir arama tablosu (lookup table), her girdiye karşılık önceden hesaplanmış bir çıktı veren bir dizidir: T[x] biçiminde hesap yapmak yerine doğrudan tablodan okursunuz, bu da işlemi hızlandırır. AES'in "bayt değiştirme" adımında kullanılan S-box (substitution box) böyle bir tablodur: her baytı sabit bir kurala göre başka bir baytla değiştirir — ör. S-box[0x53] = 0xED gibi 256 girişli bir eşleme. Bu tabloyu aklınızda tutun; whitebox'ın kalbi budur.

Ön bilgi: yan kanal ve DPA¶

Bir yan kanal (side channel), algoritmanın matematiğini değil, çalışırken sızdırdığı fiziksel/dolaylı bilgiyi (harcanan zaman, güç tüketimi, elektromanyetik yayım) kullanan bir saldırı türüdür; akıllı kartlara karşı klasik bir tekniktir. DPA (Differential Power Analysis) bunun somut bir örneğidir: bir cihazın güç tüketimi ölçümlerine istatistik uygulayarak, cihazın içine hiç bakmadan anahtarı çıkarır. Bu fikri aklınızda tutun; whitebox'ın en güçlü saldırısı (DCA, §4) DPA'nın yazılım hâlidir.

Ön bilgi: bijeksiyon ve permütasyon¶

Bir bijeksiyon (birebir-örten eşleme), her girdiyi tam bir çıktıya eşleyen ve tersi alınabilen bir dönüşümdür; ör. f(x) = x ^ 0x5A bir bijeksiyondur (tersi yine kendisidir). Bir permütasyon, sonlu bir kümenin elemanlarını yeniden sıralayan özel bir bijeksiyondur: her eleman tam olarak bir kez, başka bir elemanın yerine geçer — ör. {0,1,2,3} kümesi üzerinde 0→2, 1→0, 2→3, 3→1 bir permütasyondur, hiçbir değer atlanmamış ya da tekrar edilmemiştir. S-box, sabit boyutlu bayt değerleri kümesinin bir permütasyonudur; §3'te kuracağımız oyuncak S-box da aynı fikrin küçük (4 elemanlı) bir örneğidir. Whitebox, tabloları tam olarak bu tür gizli bijeksiyonlarla sarar.

Ön bilgi: TEE ve güvenli öğe (SE)¶

TEE (Trusted Execution Environment), telefon işlemcisinin işletim sisteminden yalıtılmış güvenli bölgesidir; güvenli öğe (SE) ise anahtarları saklayan, ayrı ve kurcalamaya dirençli bir donanım çipidir. İkisi de anahtar için en güçlü korumadır; whitebox kriptografi tam olarak bunların bulunmadığı durumlar için geliştirilmiştir (§5).

Ön bilgi: yürütme izi ve korelasyon¶

Bir yürütme izi (execution trace), bir çalıştırma boyunca kaydedilen ara değerler dizisidir — hangi bellek adresi okundu, hangi değer yazıldı, hangi komut çalıştı. Kara kutuda saldırgan yalnız son çıktıyı görürken, beyaz kutuda isterse tüm izi kaydedebilir. Korelasyon, iki değişkenin (ör. gözlenen bir değer ile bir anahtar hipoteziyle hesaplanan tahmini değer) birlikte, tutarlı biçimde değişip değişmediğinin ölçüsüdür; yüksek korelasyon iki değişkenin birbirine bağlı olduğunu gösterir. DPA ve onun yazılım hâli DCA (§1, §3–§4), doğru anahtar hipotezini yanlışlarından ayırmak için tam olarak bu ikisini birlikte kullanır: çok sayıda yürütme izi toplanır, sonra her hipotez için gözlenenle tahmin edilen arasındaki korelasyon ölçülür.

Ön bilgi: GF(2) ve matris¶

Bir sonlu cisim (finite field), üzerinde toplama ve çarpma tanımlı, sınırlı sayıda elemanı olan bir sayı sistemidir. GF(2), yalnız {0, 1} elemanlarından oluşan en küçük sonlu cisimdir; bu cisimde toplama tam olarak XOR, çarpma ise AND işlemidir. Bir matris, sayıların (burada yalnız 0 ve 1'lerin) dikdörtgen bir düzende dizilişidir; girdinin bitlerini böyle bir matrisle "çarpmak" aslında seçili bitleri XOR'lamaktır (doğrusal dönüşüm). Bir matris tekil değilse (non-singular), yani tersi varsa, uyguladığı dönüşüm geri alınabilirdir — bilgi kaybolmaz, yalnız karışır; bir matrisin kaç bağımsız satır/sütuna sahip olduğunun ölçüsüne rank denir, "tam rank" bir matrisin tekil olmadığı anlamına gelir. Whitebox'ın §3'te (Adım 4) göreceğimiz karıştırıcı matrisleri her zaman tekil olmayan seçilir; aksi hâlde şifre çözülemez hale gelirdi. Ayrıntılı sonlu cisim aritmetiği sınav kapsamı dışıdır; GF(2)'yi yalnız "XOR'larla çalışan, geri alınabilir bir doğrusal işlem dünyası" olarak hatırlamanız yeterlidir.

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

Bu terimler hafta boyunca tek başlarına değil, birbirine bağlı zincirler halinde kullanılacak. Üç ana zinciri şimdiden görelim, çünkü bölümler ilerledikçe bu zincirlerin her halkasına döneceğiz:

• Kurma zinciri: anahtar → S-box → arama tablosu (kısmi değerlendirme) → bijeksiyon (iç/dış kodlama) → GF(2) matrisi (karıştırma). Bu zincir Bölüm 3'te, oyuncak S-box'ımızla elle kurulacak.
• Saldırı zinciri: statik/dinamik analiz → entropi taraması / hata ayıklayıcı → yürütme izi → korelasyon. Bu zincir Bölüm 1, 3 ve 4'te, önce beyaz kutu saldırganın oturumunda, sonra DCA örneğinde somutlaşacak.
• Savunma zinciri: TEE/SE/HSM → WBC (kurma zincirinin ürünü) → anahtar yenileme + cihaz bağlama + sunucu denetimi. Bu zincir Bölüm 5 ve 6'da bir araya gelecek.

Bir terimi tek başına ezberlemek yerine, hangi zincirin hangi halkasında olduğunu hatırlamaya çalışın; bu, dersin sonundaki (Bölüm 8) terimler sözlüğünde de aynı mantıkla düzenlenmiştir.

Şimdi asıl soruya: anahtar saldırganın elindeyken ne yaparız?

1. Üç saldırgan modeli: kara, gri, beyaz kutu¶

Kriptografiyi 3. ve 10. haftalarda kara kutu varsayımıyla ele aldık: saldırgan yalnız girdiyi ve çıktıyı görür, anahtarı ve algoritmanın iç durumunu göremez. AES, RSA, HMAC gibi standart algoritmaların güvenlik kanıtları bu varsayıma dayanır. Ama bu varsayım, kodu kullanıcıya teslim ettiğimizde çöker.

Görünürlük soldan sağa artar; WBC en zor (beyaz kutu) modelde anahtar çıkarmayı geciktirmeye çalışır.

Whitebox kriptografi (WBC), beyaz kutu ortamda çalışan bir şifreleme algoritmasının güvenlik sorunlarını inceler. Kaynağın diliyle: WBC saldırgan modeli Chow ve arkadaşları tarafından 2002'de tanımlanmıştır ve saldırganın şu yetenekleri vardır (bunları savunmanın karşı koyması gerekenler olarak okuyun):

• Çalışmayı gözlemleme: o an işlenen komutlara erişim, algoritma akışını izleme, kullanılan belleği görme.
• Ortamı denetleme / çalışma anında değiştirme: program belleğini kurcalama, algoritmanın yalnız bir parçasını (ör. şifrenin bir turunu) çalıştırma, if koşullarını değiştirme, döngü sayaçlarını değiştirme, hata enjekte etme.

Yukarıdaki tabloyu kendiniz deneyin: aşağıda 10-16 senaryo, tek tek hangi saldırgan modeline girdiğini ve o modelin hangi beş yeteneğe (IO, SC, MEM, COD, MOD) sahip olduğunu gösteriyor.

Normal (12 karışık senaryo), Zor (16 senaryo) ve uç durum (hepsi beyaz kutu / hepsi kara kutu) örneklerini deneyin, ya da 🎲 ile kendi rastgele senaryo listenizi üretin.

Somut örnek: bir beyaz kutu saldırganın bir oturumu (adım adım anlatı)¶

Yukarıdaki yetenek listesi soyut kalmasın; bir saldırganın gerçekte ne yaptığını, baştan sona, tek tek izleyelim. Senaryo tamamen kavramsal ve sentetiktir; hiçbir gerçek araç komutu ya da gerçek uygulama adı kullanılmaz — amaç adımların sırasını ve mantığını görmektir.

1. Edinme. Saldırgan, hedef mobil uygulamanın kurulum dosyasını (ör. bir .apk/.ipa) kendi bilgisayarına indirir. Bu, beyaz kutu modelinin başlangıç koşuludur: kod artık saldırganın kendi cihazındadır, sunucuda değil.
2. Statik analiz. Saldırgan önce programı çalıştırmadan inceler: paketi açar, bir ayrıştırıcıyla fonksiyonları listeler, strings benzeri bir araçla metin sabitlerini tarar. Az önce Bölüm 0'da tanımladığımız entropi taraması da burada devreye girer: yüksek entropili bloklar (olası anahtarlar/sabitler) işaretlenir.
3. Dinamik analiz — hata ayıklayıcıya bağlanma. Saldırgan uygulamayı kendi cihazında çalıştırır ve bir hata ayıklayıcıya bağlar. Şifreleme fonksiyonunun çağrıldığı noktaya bir kesme noktası (breakpoint) koyar. Bu, saldırgan modelindeki "çalışmayı gözlemleme" yeteneğinin somut karşılığıdır.
4. Ara durumu okuma. Program kesme noktasında durduğunda, saldırgan o anki kayıtları (register) ve belleği okur. Eğer anahtar düz bir değişkende duruyorsa, burada doğrudan görünür. Bu, "belleği okuma" yeteneğinin somut karşılığıdır.
5. Kısmi çalıştırma / kurcalama. Saldırgan isterse şifrelemenin yalnız bir turunu çalıştırıp durdurabilir, bir koşulu (if) atlayabilir ya da bir değeri elle değiştirip devam ettirebilir (hata enjeksiyonu). Bu, 4. bölümde göreceğimiz DFA saldırısının ön koşuludur.
6. Tekrar ve otomasyon. Saldırgan bu adımları binlerce farklı girdi için otomatikleştirir (Bölüm 0'daki enstrümantasyon/emülatör), her seferinde ara değerleri bir yürütme izi olarak kaydeder. Bu, 4. bölümdeki DCA saldırısının ön koşuludur.

Kritik gözlem: Bu altı adımın hiçbirinde saldırgan ağdan bir şey dinlemedi; hepsi kendi cihazında, kendi kopyasında oldu. Kara kutu modelinin varsaydığı "saldırgan yalnız girdi/çıktı görür" varsayımı burada baştan geçersizdir — çünkü saldırgan aynı zamanda kullanıcıdır.

Karşılaştırma için: bir gri kutu saldırganın oturumu neye benzer?¶

Beyaz kutu saldırganın altı adımını gri kutuyla karşılaştırmak, aradaki farkı netleştirir. Gri kutu saldırgan, akıllı kart ya da gömülü cihaz gibi bir ortamda çalışır — kod onun elinde değildir, ama cihaz onun elinin altındadır:

1. Erişim. Saldırgan, hedef cihazın (ör. bir ödeme kartının) fiziksel bir kopyasını edinir. Kodu okuyamaz, belleğe giremez (kara kutuya benzer bu yönüyle) — ama cihazı çalıştırabilir ve dışarıdan gözlemleyebilir.
2. Ölçüm düzeneği kurma. Saldırgan, kart çalışırken çektiği gücü (ya da yaydığı elektromanyetik sinyali) ölçen bir düzenek kurar. Bu, Bölüm 0'daki yan kanal tanımının fiziksel karşılığıdır.
3. Çok sayıda çalıştırma. Saldırgan karta farklı girdiler (ör. farklı açık metinler) vererek, her biri için şifreleme işlemini tetikler ve her çalıştırmanın güç izini kaydeder — beyaz kutudaki "yürütme izi"nin fiziksel karşılığı, ama saldırgan kodu değil cihazın dışarıdan ölçülebilir davranışını kaydeder.
4. İstatistiksel analiz (DPA). Toplanan izler, farklı anahtar hipotezleriyle karşılaştırılır; doğru hipotez, izlerdeki bir örüntüyle istatistiksel olarak korele çıkar (Bölüm 0'daki korelasyon tanımı). Bu, klasik DPA'dır.

Fark nerede? Beyaz kutu saldırgan koda ve belleğe doğrudan erişir (adım 3–4'te hata ayıklayıcıyla); gri kutu saldırgan hiçbir zaman kodu görmez, yalnız cihazın fiziksel yan etkilerini (güç, zaman, elektromanyetik yayım) ölçer. Ortak nokta ise adım 3–4'ün mantığıdır: çok sayıda çalıştırma + istatistiksel karşılaştırma. Bu ortak mantık, Bölüm 3 ve 4'te göreceğimiz DCA'nın (DPA'nın yazılım hâli) neden "whitebox'ın DPA'sı" olarak anıldığını açıklar — DCA, gri kutunun bu istatistiksel fikrini, beyaz kutunun doğrudan gözlemlenebilen yürütme izlerine uygular; fiziksel bir ölçüm düzeneğine hiç ihtiyaç duymaz.

Bu üç model önceki haftalarla nasıl bağlanıyor?¶

Bu ayrım havadan gelmiyor; 3., 9. ve 10. haftalarda kurduğumuz kuralların doğal devamıdır:

• 3. hafta — Kerckhoffs ilkesi. "Güvenlik anahtarın gizliliğine dayanmalı, algoritmanın gizliliğine değil" ilkesini öğrenmiştik. Beyaz kutu modeli bunu bir adım öteye taşır: burada algoritma da anahtar da saldırganın elindedir; geriye yalnız "anahtarı çıkarmayı ne kadar pahalılaştırabilirim" sorusu kalır.
• 9. hafta — gizleme kuralları (K-01…K-08). O hafta kontrol akışını (K-04), sabitleri (K-02, K-07) ve boole değerlerini (K-08) gizleyen kuralları görmüştük; hepsi kod sağlamlaştırma**ydı, yani beyaz kutu saldırganın **statik analizini zorlaştırıyordu. WBC bunun kriptografiye özel, çok daha güçlü bir türüdür: yalnız kodu değil, anahtarı kodun matematiğine gömer.
• 10. hafta — algoritmalar ve anahtar yönetimi. Standart AES/RSA/HMAC'ın güvenlik kanıtları kara kutu modelinde yazılır. Bu hafta öğreneceğimiz şey, aynı AES algoritmasının beyaz kutu bir ortamda çalıştırılması gerektiğinde, o kara kutu güvenlik kanıtının artık geçerli olmadığıdır — WBC, bu boşluğu (kısmen ve pahalı bir şekilde) kapatmaya çalışır.

2. Problem neden bu kadar zor?¶

Beyaz kutuda temel gerilim şudur: program şifrelemeyi yapabilmek için anahtara erişebilmek zorundadır; ama saldırgan da programın gördüğü her şeyi görür. Yani anahtar, bir noktada, saldırganın da görebildiği bir yerdedir. WBC'nin fikri, anahtarı hiçbir zaman açıkça var olmayacak biçimde algoritmanın içine "pişirmektir": anahtar, önceden hesaplanmış arama tablolarının içine gömülür, böylece bellekte "işte anahtar bu" diyebileceğiniz bir bayt dizisi bulunmaz.

Bu, gizliliği kriptografiden gizlemeye taşımaz; matematiksel bir dönüşümle anahtarı tablolara dağıtmaya çalışır. Amaç yine bir maliyet kuralıdır (9. haftadaki gibi): anahtarı tablolardan geri çıkarmayı, onu düz saklamaktan çok daha pahalı hale getirmek.

Naif çözümlerin neden çöktüğü (kurallar)¶

WBC'ye neden ihtiyaç olduğunu görmek için, işe yaramayan "kolay" çözümleri ve onları kıran saldırıları bilmek gerekir. Her biri bir güvenli programlama kuralına dönüşür:

• Kural — Anahtarı sabit diziye gömme. En naif çözüm anahtarı bir static const uint8_t key[16] dizisine koymaktır. Bu, strings ve entropi taraması (Shamir–van Someren'in gözlemi: kriptografik anahtarlar yüksek entropili bloklardır ve binary dosyada öyle görünürler) ile saniyeler içinde bulunur; bir hata ayıklayıcıyla doğrulanır. Sonuç: düz gömülü anahtar bir anahtar koruması değildir.
• Kural — Anahtarı yalnız XOR/whitening ile "karıştırma". Anahtarı bir maskeyle XOR'layıp saklamak da işe yaramaz: maske de binary dosyadadır, program onu çözebiliyorsa saldırgan da çözer.
• Kod sökme (code lifting) tehdidi. WBC anahtarı tablolara gömse bile, saldırgan anahtarı çıkarmadan şifreleme/çözme yapan kod parçasını (tablolar + yorumlayıcı) olduğu gibi kopyalayıp kendi programında kullanabilir. Anahtarı hiç bilmeden onun işlevini çalar. Sonuç: WBC'nin tek başına "anahtarı gizledim" demesi yetmez; kod sökmeye karşı cihaz/sürüm bağlama (bölüm 4) gerekir.
• Kural — "Test/hata ayıklama anahtarını" unutmak. Çok yaygın bir gerçek dünya hatası: geliştirici test aşamasında kolaylık olsun diye gerçek anahtarın yerine sabit bir "test anahtarı" koyar (static const uint8_t k[16] = {0x00, 0x01, ...} gibi, ya da bir yapılandırma dosyasında düz metin) ve bunu üretime taşımayı unutur ya da "zaten geçici" diye önemsemez. Sonuç: Bu, Bölüm 2'nin ilk kuralıyla (düz gömülü anahtar) birebir aynı zafiyettir — yalnız "test amaçlı" etiketi, gerçek riskini azaltmaz. Bir değerlendirici (12. hafta) test/hata ayıklama yollarını da üretim koduyla aynı ciddiyette tarar.

İlk kuralı (sabit diziye gömülü anahtar) soyut bırakmayalım. code/week-11/02-embedded-key demosunun search_bytes() fonksiyonu, tam olarak entropi taramasının yaptığı gibi, 16 baytlık bir pencereyi ikili dosyanın üzerinde kaydırıp anahtar örüntüsüyle karşılaştırır. Aşağıdaki animasyon bu taramayı adım adım gösteriyor.

Normal (anahtar erken bulunur), Zor (anahtar sona yakın) ve uç durum (anahtar hiç yok, tarama -1 döner) örneklerini deneyin, ya da 🎲 ile kendi ikili dosya boyutunuzu ve anahtar konumunuzu üretin.

Sayısal mikro-örnek: "yalnız XOR ile karıştırma" neden işe yaramaz?¶

Yukarıdaki ikinci kuralı ("anahtarı yalnız XOR/whitening ile karıştırmak işe yaramaz") havada bırakmayalım; küçük ama gerçek baytlarla, tek tek görelim.

Kurulum. Bir geliştirici, gizli anahtar baytı k = 0x3C'yi binary'de düz tutmak yerine, rastgele bir maskeyle XOR'layıp saklamaya karar verir. Maske m = 0x5A olsun. Kodda saklanan değer:

kodlanmis_k = k XOR m = 0x3C XOR 0x5A

Adım 1 — XOR'u bit bit hesaplayalım.

0x3C = 0011 1100
0x5A = 0101 1010
      ----------- XOR
      = 0110 0110 = 0x66

Yani binary'de kodlanmis_k = 0x66 olarak duruyor. Geliştirici "anahtar artık düz görünmüyor, gizlendi" diye düşünür.

Adım 2 — Programın kendisi maskeyi de içermek zorunda. Program, şifreleme anında gerçek anahtara ihtiyaç duyar; yani bir yerde şu hesabı yapmak zorundadır:

uint8_t k_gercek = kodlanmis_k ^ m;   /* m de ikilide bir yerde olmalı! */

m = 0x5A sabiti de binary'nin içinde, kodlanmis_k = 0x66 sabitinin yanı başında durur (ikisi de statik verilerdir).

Adım 3 — Saldırganın yaptığı işlem. Saldırgan binary'den iki baytı da okur (0x66 ve 0x5A) ve aynı XOR'u kendisi yapar:

k = kodlanmis_k XOR m = 0x66 XOR 0x5A
  = 0110 0110
  ^ 0101 1010
  -----------
  = 0011 1100 = 0x3C        ← ANAHTAR YİNE BULUNDU

Sonuç. Maskeleme, anahtarın binary'deki bit örüntüsünü değiştirir ama korumayı değiştirmez: program maskeyi çözebiliyorsa, aynı hesabı okuyabilen saldırgan da çözer. Bu, tam olarak 9. haftanın K-07 (statik dize (string)/sabit kodlama) kuralının sınırıyla aynı derstir — kodlama tek başına, çözme anahtarı da yanında duruyorsa, hiçbir şey kazandırmaz.

Kod sökme (code lifting) — biraz daha derin¶

Yukarıda kod sökmeyi tanımladık: saldırganın anahtarı hiç çıkarmadan, tabloları ve onları çalıştıran yorumlayıcıyı olduğu gibi kopyalayıp başka bir programda kullanması. Bunun neden ciddi bir tehdit olduğunu bir örnekle somutlaştıralım:

Bunun WBC'ye özgü olmasının nedeni şudur: normal bir programda (anahtar apaçık bir değişkende) saldırgan zaten anahtarı çıkarıp istediği yerde kullanabilir; kod sökmeye gerek yoktur. WBC'de ise anahtar çıkarılamıyor olabilir (dış kodlamalar güçlüyse), ama tablolar yine de çalışan bir makine oluşturur — ve çalışan bir makineyi kopyalamak, onun matematiğini çözmekten çoğu zaman çok daha kolaydır. 9. haftanın K-06 (çağrı ve bağımlılık gizleme) kuralı burada kısmen yardımcı olur (rutini bulmayı zorlaştırır) ama tek başına yetmez — rutin bulunduktan sonra kopyalanması hâlâ mümkündür. Asıl çözüm Bölüm 5'te göreceğimiz cihaz/sürüm bağlamadır: tablolar yalnız belirli bir bağlamda (ör. cihaz kimliğiyle karıştırılmış girdi/çıktıyla) anlamlı sonuç verir.

WBC ile 9. haftanın "kod sağlamlaştırması" aynı şey mi?¶

Bu ikisi sık karıştırılır, çünkü ikisi de "saldırganı zorlaştırma" hedefiyle çalışır. Ama neyi zorlaştırdıkları farklıdır:

Neden birlikte kullanılıyorlar? Çünkü birbirini tamamlarlar: WBC anahtarı tablolara gömer, kod sağlamlaştırma da bu tabloları çağıran kodun nasıl çalıştığını okumayı zorlaştırır (ör. K-06 whitebox rutinini bulmayı, K-04 hangi tablonun ne zaman çağrıldığını takip etmeyi zorlaştırır). Kaynak kılavuzun Bölüm 1'de alıntıladığımız cümlesi tam olarak bunu söylüyor: WBC'yi koruyan şey kod sağlamlaştırma ve RASP ile birlikte olmasıdır.

Maliyet dengesi: saldırgan ucuza kazanırken savunmacı pahalı öder¶

Bu bölümü bir maliyet gözlemiyle kapatalım, çünkü bu haftanın her bölümünde tekrar edecek bir örüntüdür:

Bu asimetri (savunmacı ucuz önlem alırsa saldırgan da ucuza kırar) whitebox kriptografinin var olma nedenidir: amaç, saldırganın maliyetini savunmacının kabul edebileceği bir maliyetle olabildiğince yükseltmektir — hiçbir zaman sıfıra indirmek değil.

3. Tablo tabanlı WBC nasıl çalışır? (Chow AES, kavram)¶

WBC'nin klasik fikri, Chow ve arkadaşlarının 2002'deki AES gerçekleştirimidir. Ayrıntılı matematiği (sonlu cisim işlemleri, matris kurulumları) bu dersin sınavında sorulmayacak; ama fikri ve özellikle maliyetini ve sınırını anlamanız gerekir. Adım adım ve kavramsal gidiyoruz.

Önce AES'in bir turu: sıfırdan, adım adım¶

Tabloya "pişirmekten" söz etmeden önce, neyi pişirdiğimizi görelim. AES 16 baytlık bloğu sütun sütun bir 4×4 "durum" matrisine yerleştirir (FIPS-197); bir tur sırasıyla SubBytes (her bayt sabit bir tablodan geçer), ShiftRows (satır r sola r bayt kayar), MixColumns (sütunlar karışır — gerçek AES burada GF(2⁸) matrisi kullanır, sınav kapsamı dışı, bkz. Bölüm 0) ve AddRoundKey (tur anahtarıyla XOR) adımlarından oluşur. Aşağıdaki animasyon bunu, gerçek AES S-box'ı yerine bu haftanın (aşağıda kuracağımız) toy S-box'ıyla, adım adım kurar.

Normal (ardışık bayt değerleri), Zor (karışık bayt değerleri) ve uç durum (durum ve anahtar tamamen sıfır) örneklerini deneyin, ya da 🎲 ile kendi 16 baytlık blok ve anahtarınızı üretin.

Adım 1 — Kısmi değerlendirme: anahtarı tabloya "pişir"¶

AES bir turda önce durum baytını tur anahtarıyla XOR'lar, sonra S-box'tan geçirir. Bu iki işlem, sabit bir anahtar için tek bir arama tablosuna birleştirilebilir:

Normal:   çıktı = S-box[ x XOR k ]     (k tur anahtarının baytı)
WBC:      T[x] = S-box[ x XOR k ]      → 256 girişli bir tablo, k tablonun İÇİNDE

Artık kodda k diye bir değişken yoktur; k tablonun içeriğine gömülmüştür. Ama bu tek başına güvensizdir: saldırgan tabloyu S-box ile karşılaştırıp k'yı geri çıkarabilir (tablo, S-box'ın x XOR k ile ötelenmiş halidir). O yüzden tablolar kodlanır.

Sayısal mikro-örnek: anahtar tablodan nasıl sızıyor? (uçtan uca)¶

Yukarıdaki cümle ("saldırgan k'yı geri çıkarabilir") havada kalmasın; gerçek sayılarla, tek tek yapalım. Elimizde yalnız şunlar var: herkesin bildiği AES S-box'ı ve saldırganın binary dosyadan okuduğu tablo.

Kurulum. Gizli anahtar baytı k = 0x3C olsun (saldırgan bunu bilmiyor). Geliştirici Adım 1'i uygulayıp şu tabloyu üretmiş: T[x] = S-box[x XOR k].

Adım 1 — Tablodan tek bir değer oku. Saldırgan x = 0x00 girişine bakar:

T[0x00] = S-box[0x00 XOR 0x3C] = S-box[0x3C] = 0xEB

Yani binary dosyada okuduğu değer: T[0x00] = 0xEB.

Adım 2 — S-box'ı tersine çevir. S-box herkese açık ve birebirdir; tersi de bilinir:

S-box⁻¹[0xEB] = 0x3C        (çünkü S-box[0x3C] = 0xEB)

Adım 3 — Anahtarı çöz. Tanım gereği S-box⁻¹[T[x]] = x XOR k olduğundan:

x XOR k = 0x3C
0x00 XOR k = 0x3C
k = 0x3C XOR 0x00 = 0x3C        ← ANAHTAR BULUNDU

Sonuç. Saldırgan tek bir tablo girdisiyle, 256 deneme bile yapmadan anahtarı buldu. "Anahtar kodda görünmüyor" demek, "anahtar korunuyor" demek değildir.

Peki kodlama ne değiştirir? Tabloyu gizli bir bijeksiyon G ile sararsak: T'[x] = G( S-box[x XOR k] ). Saldırgan artık S-box⁻¹[T'[x]] hesaplayamaz, çünkü önce G'yi kaldırması gerekir ama G'yi bilmiyor. Adım 2 kırılır, dolayısıyla Adım 3 de çalışmaz.

Aşağıdaki animasyon toy_table.c'nin kendi kodunu (build_tables, naive_table, encoded_table) adım adım çalıştırır: anahtar önce naif tabloya, sonra kodlanmış tabloya nasıl "pişiyor" görün.

Normal (gerçek demo anahtarı 0x3C), Zor (başka bir anahtar, 16 girdi) ve uç durum (sıfır anahtar) örneklerini deneyin, ya da 🎲 ile kendi anahtarınızı ve girdi sayınızı üretin.

Peki bu iki tablo arasındaki fark neden bu kadar önemli? Aşağıdaki animasyon, toy_table.c'nin naive_recover() fonksiyonunu adım adım çalıştırarak, naif tablodan anahtarın nasıl doğrudan okunduğunu ve kodlanmış tabloda bu okumanın neden ilk adımda çöktüğünü gösteriyor.

Normal, Zor ve uç durum (sıfır anahtar) örneklerini deneyin; her ikisinde de aynı naive_recover mantığının naif tabloda nasıl başarılı, kodlanmış tabloda nasıl başarısız olduğunu izleyin.

Elle bütünüyle kurulan örnek: 4 elemanlı bir "oyuncak S-box"¶

Gerçek AES S-box'ı 256 girdilidir; elle tamamını taramak pratik değildir (yukarıda tek bir girdiyle yetindik). Şimdi görevi 4 elemanlı bir oyuncak S-box'a küçültüp, tabloyu baştan sona, dört girdinin de elle hesaplandığı tam bir saldırı yürütelim. Fikir birebir aynıdır; yalnız elle takip edilebilir küçüklüktedir.

Kurulum. Girdilerimiz 2 bitliktir: x ∈ {0, 1, 2, 3} (ikilik: 00, 01, 10, 11). Oyuncak S-box'ımız, bu dört değeri birebir-örten biçimde (bir permütasyon, Bölüm 0) karıştıran sabit bir tablodur:

Kontrol: çıktılar {3,1,0,2} — yani {0,1,2,3} kümesinin tamamı, her biri tam bir kez. Demek ki S bir bijeksiyondur (Bölüm 0), tıpkı gerçek AES S-box'ı gibi.

Gizli anahtarımız (saldırganın bilmediği) k = 2 (ikilik: 10) olsun.

Adım A — T[x] = S[x XOR k] tablosunu dört girdi için de elle kuralım.

x=0:  0 XOR 2 = 10 (2)   →  S[2] = 0     →  T[0] = 0
x=1:  1 XOR 2 = 11 (3)   →  S[3] = 2     →  T[1] = 2
x=2:  2 XOR 2 = 00 (0)   →  S[0] = 3     →  T[2] = 3
x=3:  3 XOR 2 = 01 (1)   →  S[1] = 1     →  T[3] = 1

Sonuç: saldırganın binary'de okuduğu tam tablo T = [0, 2, 3, 1] (yani T[0]=0, T[1]=2, T[2]=3, T[3]=1).

Adım B — S-box'ın tersini çıkaralım. S herkese açık olduğu için tersi de hesaplanabilir: "hangi girdi hangi çıktıyı üretti?" sorusunu S tablosundan tersine okuruz (S[0]=3 demek S⁻¹[3]=0 demektir, vb.):

Adım C — Saldırgan anahtarı DÖRT girdinin de üzerinden doğrulasın. Kural, gerçek AES örneğindeki Adım 3 ile birebir aynıdır: S⁻¹[T[x]] = x XOR k, dolayısıyla k = x XOR S⁻¹[T[x]].

x=0:  T[0]=0  →  S⁻¹[0]=2   →  k = 0 XOR 2 = 2
x=1:  T[1]=2  →  S⁻¹[2]=3   →  k = 1 XOR 3 = 2      (01 XOR 11 = 10)
x=2:  T[2]=3  →  S⁻¹[3]=0   →  k = 2 XOR 0 = 2
x=3:  T[3]=1  →  S⁻¹[1]=1   →  k = 3 XOR 1 = 2      (11 XOR 01 = 10)

Dört girdinin de tamamı aynı anahtarda (k = 2) birleşiyor. Bu, gerçek AES'te 256 girdinin tamamını taramanın küçük ölçekli birebir karşılığıdır: saldırgan tek bir girdiyle bile yetinebilirdi (yukarıdaki gerçek AES örneğinde öyle yaptık), ama tutarlılık (bütün girdilerin aynı k'de birleşmesi) sonucu ayrıca doğrular.

İç kodlama eklenince: aynı saldırı neden çöküyor?¶

Şimdi Adım 3'te (bir sonraki alt bölüm değil, birazdan geleceğiz) sözünü ettiğimiz iç kodlamayı aynı oyuncak örnek üzerinde, yine elle uygulayalım. Tabloyu bilinmeyen bir bijeksiyon G ile sarıyoruz: T'[x] = G(T[x]).

G'yi tanımlayalım (saldırgan bunu bilmiyor):

Kontrol: çıktılar {1,3,0,2} — yine {0,1,2,3}'ün tamamı, G de bir bijeksiyon.

T'[x] = G(T[x]) tablosunu kuralım (bir önceki T = [0, 2, 3, 1] tablosunun üzerine G uygulanır):

T'[0] = G(T[0]) = G(0) = 1
T'[1] = G(T[1]) = G(2) = 0
T'[2] = G(T[2]) = G(3) = 2
T'[3] = G(T[3]) = G(1) = 3

Sonuç: T' = [1, 0, 2, 3]. Saldırganın binary'de gördüğü tablo artık bu; T değil.

Saldırgan aynı üç adımı (A–C) tekrar dener — hâlâ G'nin var olduğunu bilmiyor, bu yüzden gene S⁻¹[T'[x]] = x XOR k varsayımıyla ilerliyor:

x=0:  T'[0]=1  →  S⁻¹[1]=1   →  k_tahmin = 0 XOR 1 = 1
x=1:  T'[1]=0  →  S⁻¹[0]=2   →  k_tahmin = 1 XOR 2 = 3      (01 XOR 10 = 11)
x=2:  T'[2]=2  →  S⁻¹[2]=3   →  k_tahmin = 2 XOR 3 = 1      (10 XOR 11 = 01)
x=3:  T'[3]=3  →  S⁻¹[3]=0   →  k_tahmin = 3 XOR 0 = 3

Sonuç: 1, 3, 1, 3 — dört girdi DÖRT AYRI (ve birbiriyle çelişen) "anahtar" veriyor, üstelik hiçbiri gerçek anahtar olan 2'ye bile eşit değil. Adım C'deki "tüm girdiler aynı anahtarda birleşir" tutarlılık testi burada açıkça başarısız oluyor — saldırgan, elindeki tablonun artık basit S[x XOR k] biçiminde olmadığını anlar, ama G'yi bilmediği için k'yi bu yoldan çıkaramaz.

DCA'nın izlerini nasıl topladığını küçük bir tabloyla görelim¶

Bölüm 0'da yürütme izi, enstrümantasyon ve korelasyon terimlerini tanımlamıştık; Bölüm 4'te tam olarak işleyeceğimiz DCA (Differential Computation Analysis) saldırısı bunları birleştirir. Burada saldırının veri toplama mekanizmasını, aynı oyuncak tablo üzerinde, küçük bir izleme tablosuyla görelim. Amaç saldırıyı uygulamak değil, neden algebrik Adım A–C'den farklı bir strateji gerektiğini göstermektir.

Önce kodlama olmasaydı ne olurdu? (temel fikir) DCA'nın mantığı şudur: bir anahtar hipotezi (k_h) seçilir, her açık metin baytı p için gerçek hesabın ne üreteceği tahmin edilir (S[p XOR k_h]), sonra bu tahmin, gerçekten gözlenen ara değerle karşılaştırılır. Kodlama yokken (yani T tablosu doğrudan görünür durumdayken) bu karşılaştırma birebir eşleşme ile yapılabilir:

Doğru hipotez (k_h=2) 4/4 eşleşir (tanım gereği — çünkü T[p] zaten S[p⊕2]'nin ta kendisidir); yanlış hipotez (k_h=0) 0/4 eşleşir. Kodlama yokken, doğru anahtarı yanlışlardan ayırmak bu kadar kolaydır.

Şimdi kodlamayı (T') geri koyalım — aynı iki hipotezi sınayalım:

Çarpıcı sonuç: kodlama devredeyken doğru hipotez de 0/4, yanlış hipotez de 0/4 — birebir eşleşme testi, gizli G yüzünden artık doğruyu yanlıştan ayırt edemiyor. Bu, "iç kodlama saldırıyı durdurur" cümlesinin neden doğru olduğunun aynı zamanda DCA'nın neden basit bir eşleşme testi olmadığının da kanıtıdır.

Adım 2 — Tabloları birleştir ve genişlet (T-box + MixColumns)¶

Tek bir bayt eşlemesi yerine, S-box ile AES'in doğrusal karıştırma adımı (MixColumns) birleştirilir; 8 bitlik girdiden 32 bitlik çıktı üreten daha büyük tablolar (T-box'lar) elde edilir. Baytlar arası XOR işlemleri de küçük XOR tabloları (4 bitlik) haline getirilir. Böylece bütün tur, bir arama tabloları ağına dönüşür; hiçbir yerde açık bir aritmetik anahtar işlemi görünmez.

Fikri oyuncak ölçekte görelim: iki işlemi tek tabloya birleştirmek¶

Gerçek T-box'lar (S-box + MixColumns) 8 bit girdi, 32 bit çıktı taşır; elle takip etmek pratik değildir. Ama "iki ayrı işlemi tek bir tabloda birleştirme" fikrini, oyuncak S-box'ımız üzerinde küçük bir uzantıyla gösterebiliriz.

Normalde whitebox olmayan bir uygulamada, x girdisi için iki ayrı adım çalışır:

Adım 1: y = S[x XOR k]        (bizim oyuncak S-box'ımız, anahtarla)
Adım 2: z = y XOR c            (c: sonraki turdan gelen sabit bir "karıştırma" değeri, ör. c = 1)

Bu iki adım iki ayrı komut olarak çalışırsa, saldırgan aradaki y değerini (ara sonucu) hata ayıklayıcıda ayrıca gözlemleyebilir — her adım kendi başına bir gözlem noktasıdır. T-box fikri, bu iki adımı tek bir tabloya önceden pişirmektir:

Birleşik tablo: U[x] = S[x XOR k] XOR c

k = 2, c = 1 alalım ve U[x]'i dört girdi için kuralım (önceki T[x] = S[x XOR k] tablomuzu, [0,2,3,1], hatırlayın — yalnız sonuna XOR 1 ekliyoruz):

U[0] = T[0] XOR 1 = 0 XOR 1 = 1
U[1] = T[1] XOR 1 = 2 XOR 1 = 3      (10 XOR 01 = 11)
U[2] = T[2] XOR 1 = 3 XOR 1 = 2      (11 XOR 01 = 10)
U[3] = T[3] XOR 1 = 1 XOR 1 = 0

Sonuç: U = [1, 3, 2, 0]. Artık kodda ne S[...] çağrısı ne de ayrı bir XOR c komutu görünür — ikisi de tek bir tablo okumasına (U[x]) indirgenmiştir. Saldırganın hata ayıklayıcıda görebileceği ara adım sayısı azalır: eskiden iki gözlem noktası varken (Adım 1 sonrası y, Adım 2 sonrası z), şimdi yalnız bir tane vardır (U[x]).

Gerçek AES'te bu fikir çok daha büyük ölçekte uygulanır: bir turun tamamı (16 bayt S-box + MixColumns + turanahtarı ekleme) birbirine bağlı T-box'lar ağına dönüşür; saldırganın ara adımları tek tek izleyebileceği nokta sayısı, açık kodda onlarca iken tabloya pişirilince çok azalır — ama sıfıra inmez, çünkü tablolar arası geçişler yine gözlemlenebilir. Tam koruma, Adım 3–5'in kodlamalarıyla gelir.

Adım 3 — İç kodlamalar (internal encodings)¶

Her tablonun çıkışına gizli bir bijeksiyon (birebir-örten eşleme) uygulanır ve bir sonraki tablonun girişinde onun tersi uygulanır. Ardışık tabloların kodlamaları birbirini götürür; sonuç doğrudur ama ara değerler karışıktır. Bu, bir tabloyu tek başına inceleyen saldırganı durdurmayı amaçlar.

"Sonuç doğrudur" iddiasını elle doğrulayalım¶

Yukarıdaki cümle ("kodlamalar birbirini götürür, sonuç doğrudur") bir iddiadan ibaret kalmasın; oyuncak örneğimizle kanıtlayalım. Daha önce kurduğumuz T = [0, 2, 3, 1] (gerçek ara değerler) ve T' = G(T) = [1, 0, 2, 3] (Tablo 1'in kodlanmış çıktısı, saldırganın gördüğü) tablolarını hatırlayın.

Zincirdeki bir sonraki tablo (Tablo 2), girdisi olarak T'[x]'i alır. Doğru sonucu üretebilmesi için önce kodlamayı geri almalı, yani G⁻¹ uygulamalıdır. G⁻¹'i çıkaralım (G'nin tersi — hangi çıktı hangi girdiden geldi):

Dört girdinin de tamamı için G⁻¹(T'[x])'i hesaplayıp T[x] ile karşılaştıralım:

x=0:  G⁻¹(T'[0]) = G⁻¹(1) = 0   ==  T[0] = 0   ✓
x=1:  G⁻¹(T'[1]) = G⁻¹(0) = 2   ==  T[1] = 2   ✓
x=2:  G⁻¹(T'[2]) = G⁻¹(2) = 3   ==  T[2] = 3   ✓
x=3:  G⁻¹(T'[3]) = G⁻¹(3) = 1   ==  T[3] = 1   ✓

Dört girdinin dördünde de G⁻¹(G(T[x])) = T[x] doğrulandı. Bu, Adım 3'ün iddiasının tam kanıtıdır: Tablo 2, girdisini alır almaz G⁻¹'i uygulayarak gerçek ara değeri (T[x]) geri kazanır ve hesaba doğru yerden devam eder — sonuç, sanki kodlama hiç yokmuş gibi doğru çıkar. Ama bu geri kazanım Tablo 2'nin içinde, saklı biçimde olur; saldırgan yalnızca T'[x]'i (Tablo 1 çıkışını) tek başına görürse, G'yi bilmediği için bu geri kazanımı yapamaz — tıpkı Bölüm 3'ün başındaki "İç kodlama eklenince" örneğinde gördüğümüz gibi.

Adım 4 — Karıştırıcı bijeksiyonlar (mixing bijections)¶

İç kodlamalara ek olarak, GF(2) üzerinde doğrusal karıştırıcı matrisler (ör. 8×8 ve 32×32) eklenir; bunlar bilgiyi tablolar arasında yayar, böylece bir tablodan sızan bilgi tek başına anlamlı olmaz. Chow'un tablo tipleri (literatürde I–IV) bu kodlanmış ve karıştırılmış tabloların türleridir.

Elle çözülebilir minik bir GF(2) matris örneği¶

Bölüm 0'da tanımladığımız doğrusal dönüşüm ve tekil olmayan matris fikirlerini somutlaştıralım. 2 bitlik bir değeri (v₁, v₀) (ör. v₁v₀ = 11 ikilik gösterimi 3 sayısıdır) karıştıran şu minik matrisi ele alalım:

M = | 1 1 |     yeni_v1 = v1 XOR v0
    | 0 1 |     yeni_v0 = v0

Bu, GF(2) üzerinde doğrusal bir dönüşümdür: her yeni bit, eski bitlerin seçili bir XOR'udur (Bölüm 0'daki GF(2) tanımını hatırlayın: toplama = XOR).

Örnek girdi: v = 11 (yani v₁=1, v₀=1, ondalık 3).

yeni_v1 = v1 XOR v0 = 1 XOR 1 = 0
yeni_v0 = v0        = 1

Sonuç: M·v = 01 (ondalık 1). Tek başına bakan biri, "3 sayısı 1'e dönüştü" der ama hangi matrisle olduğunu bilmeden bunu tersine çeviremez.

Bu dönüşüm gerçekten tersinir mi (tekil değil mi)? M'yi aynı girdiye ikinci kez uygulayarak sınayalım — eğer özgün değere dönersek, M'nin kendi kendinin tersi (bir involüsyon) olduğunu doğrularız:

girdi: 01  (yeni_v1=0, yeni_v0=1)
yeni_v1' = 0 XOR 1 = 1
yeni_v0' = 1
sonuç: 11  ← özgün değere (3) geri döndük

Doğrulandı: M tekil olmayan bir matristir (tersi vardır — burada tesadüfen kendisidir), yani bilgi kaybolmaz, yalnız karışır. Chow AES'teki gerçek karıştırıcı matrisler 8×8 ve 32×32 boyutundadır ve rastgele seçilir, ama fikir birebir aynıdır: her biri tekil olmayan seçilir ki şifre çözme sırasında tam olarak geri alınabilsin; saldırgan içinse tek bir tablodaki değerlerin gerçek AES ara değerleriyle doğrudan ilişkisi görünmez hale gelir, çünkü değerler birçok bitin XOR'una yayılmıştır.

Adım 5 — Dış kodlamalar (external encodings): F ve G¶

En dış katmanda, tüm şifre iki gizli bijeksiyonla sarılır. Kaynak kılavuzun anlattığı gibi, whitebox AES işlemi F ve G adlı iki rastgele tekil-olmayan matrisle kapsüllenir (128 rank, "rastgele bijeksiyon"). Yani ağ artık saf AES değil, G ∘ AES ∘ F⁻¹ hesaplar:

Girdi --F⁻¹--> [ kodlanmış AES tabloları ağı ] --G--> Çıktı

Bu adım hem en güçlü korumadır hem de en büyük sınırdır:

• Güç: Dış kodlama, tek başına tablolara bakarak yapılan pek çok cebirsel/istatistiksel saldırıyı (BGE, DCA türevleri) çok zorlaştırır; çünkü saldırganın gördüğü giriş/çıkış standart AES'in giriş/çıkışı değildir.
• Sınır: G ∘ AES ∘ F⁻¹ standart AES değildir. Karşı tarafın (sunucu ya da başka bir uç) F ve G'yi bilip geri almadan sonuç anlamsızdır. Bu yüzden dış kodlamalı WBC, ancak iki ucu da sizin kontrolünüzde olan bir protokolde kullanılabilir; EMV gibi standart AES bekleyen bir protokolde kullanılamayabilir.

Oyuncak örnekte dış kodlama: neden code lifting'i zorlaştırır?¶

Bölüm 2'de tanımladığımız kod sökme tehdidiyle dış kodlamayı birbirine bağlayalım. Oyuncak whitebox'ımıza bir girdi dış kodlaması F ekleyelim; saldırgan artık fonksiyona doğrudan x değil, F(x) besler:

Tam ağ artık çıktı = G(T[F⁻¹(girdi)]) biçiminde çalışır (girdi önce F⁻¹ ile "çözülür", tablo uygulanır, çıktı G ile "kodlanır"). Bunu çağıran uygulama, girdiyi göndermeden önce kendi F kodlamasını uygulamak, çıktıyı aldıktan sonra da kendi G⁻¹ kodlamasını çözmek zorundadır — yani rutin artık yalnız bu uygulamanın bildiği bir sözleşmeyle çalışır.

Şimdi Bölüm 2/6'daki saldırganın gözünden bakalım: saldırgan whitebox tablo ağını (T, G, dolaylı olarak F⁻¹'in etkisini) olduğu gibi kopyalayıp kendi programına yapıştırsa bile, kendi programı girdiyi F ile kodlamıyorsa ve çıktıyı G⁻¹ ile çözmüyorsa, elde ettiği sonuç anlamsız bayt dizileridir — orijinal uygulamanın beklediği biçimde bir şifreli metin/belirteç değildir. Saldırgan işlevi çalabilir ama doğru kullanamaz, çünkü F ve G'nin ne olduğunu bilmeden onları da kopyalaması ve kendi programına doğru sırayla uygulaması gerekir — ki bunlar genelde uygulamanın geri kalanına (Bölüm ⅘'teki cihaz/sürüm bağlamayla) sıkı sıkıya örülüdür.

Maliyet: WBC bedava değildir¶

Kavramı bir kural olarak bitirelim: WBC'nin maliyeti yüksektir. Chow AES'in tipik büyüklük mertebesi (literatürden):

Alıştırma: kendi mertebe tahmininizi yapın¶

Ölçü hissini pekiştirmek için, aynı fikri kendi elinizle bir kez daha hesaplayalım — bu sefer farklı, basit sayılarla. Diyelim ki bir geliştirici, bir whitebox AES gerçekleştiriminde toplam 160 tablo kullanıyor ve her tablo ortalama 900 bayt yer kaplıyor:

Toplam boyut ≈ 160 tablo × 900 bayt/tablo = 144.000 bayt ≈ 140,6 KB

Karşılaştırma: standart (whitebox olmayan) bir AES gerçekleştiriminde saklanması gereken tek şey 16–32 baytlık bir anahtardır. Yani bu örnekte whitebox tabloları, düz anahtara göre kabaca 4.500–9.000 kat daha fazla yer kaplıyor (144.000 ÷ 32 = 4.500, 144.000 ÷ 16 = 9.000).

Bölüm 3'ü kapatırken: beş adımı tek cümlede toplayalım¶

Oyuncak S-box'ımızla kurduğumuz beş adımı bir kez daha, tek bir zincir halinde sıralayalım: anahtarı tabloya pişir (Adım 1) → tabloları birleştirip gözlem noktalarını azalt (Adım 2) → her tablo çiftini gizli bir bijeksiyonla sar (Adım 3, elle kanıtladık: G⁻¹(G(T[x])) = T[x]) → bilgiyi matrislerle yay (Adım 4, GF(2) örneğiyle gördük) → bütün rutini uygulamaya bağlayan bir dış zarfla kapat (Adım 5). Her adım, kendinden önceki adımın tek başına yetersiz kaldığı noktayı kapatır — bu yüzden beşi de birlikte kullanılır, hiçbiri tek başına "WBC" değildir.

4. Saldırı geçmişi: neden "hepsi kırıldı" bir kuraldır¶

WBC'yi doğru konumlandırmak için en dürüst yol, tarihine bakmaktır. Aşağıdaki kronolojiyi saldırı öğretmek için değil, "bu korumaya ne kadar güvenebilirim?" sorusunu yanıtlamak için veriyoruz. Her satır, savunmacı için bir karşı önlem çıkarımıdır.

2007 satırı neden önemli? İlk bakışta "DES kırıldı, biz zaten AES kullanıyoruz" diye geçiştirilebilir. Ama asıl ders farklıdır: 2004'te AES tabanlı whitebox kırılınca, alanın bir kısmı "belki sorun AES'in kendi yapısındadır, başka bir şifreyle (DES) dener miyiz" diye düşündü. 2007'de DES tabanlı tasarımların (ve harici kodlama eklenmiş türevlerinin) de kırılması gösterdi ki: sorun AES'e özgü değildi. Zayıflık, kullanılan şifrenin kimliğinde değil, iç kodlamaların matematiksel yapısındaydı — tıpkı Karroumi'nin "daha çok tablo" denemesinde olduğu gibi, şifreyi değiştirmek de kök nedeni düzeltmedi.

"Daha çok tablo, daha çok güvenlik" neden yanlıştır? Karroumi'nin satırındaki çıkarımı biraz açalım, çünkü sezgiye aykırı görünebilir. "Çift AES" fikri, iki bağımsız AES hesaplamasını art arda ya da yan yana çalıştırıp whitebox tablolarını ikiye katlamaktı — mantık şuydu: "saldırgan artık iki kat tabloyu çözmek zorunda, demek ki iki kat zor." Ama güvenlik, tablo sayısıyla değil, kodlamaların matematiksel yapısıyla ilgilidir. Eğer ek tablolar da aynı türden (afin) kodlamalar kullanıyorsa, BGE benzeri bir algoritma onları da aynı yöntemle çözer — yalnız biraz daha fazla hesaplama gerekir (~2²²), tasarımı kırılmaz yapmaz. Bu, Bölüm 3'ün maliyet tartışmasına ters bir örnektir: burada maliyeti artırmak (daha çok tablo) güvenliği artırmadı, çünkü artırılan şey saldırganın gerçek zorlandığı nokta (kodlamanın yapısı) değildi.

DCA ve DFA neden önemli? Çünkü bunlar tasarımın gizli matematiğini çözmeye çalışmaz. DCA, çalışırken üretilen ara değerlerin izini toplar ve tıpkı bir donanım güç analizinde (DPA) olduğu gibi istatistiksel korelasyonla anahtarı çıkarır; iç kodlamalar bu istatistiği çoğu zaman bozmaz. DFA ise çalışma anında bir değere hata enjekte edip bozulan çıktıdan anahtarı geri hesaplar. İkisi de "kutuyu açmadan" çalışır — bu yüzden yeni tasarımları da vurur.

BGE saldırısı: ilk kırılma nasıl oldu? (kavramsal)¶

Chow'un 2002 tasarımı bugün bakınca "sağlam" görünebilir: her tablo gizli bir bijeksiyonla (Bölüm 3'teki G gibi) sarılıdır, saldırgan tabloları tek tek incelerken rastgele görünen değerler bulur. BGE'nin (2004) fikri şuydu: Chow'un kullandığı iç kodlamalar rastgele bijeksiyonlar değil, matematiksel olarak daha yapılı (doğrusal + sabit, yani afin) dönüşümlerdi. Bir dönüşüm afin olduğunda, komşu tablolar arasındaki cebirsel ilişkiler yapılandırılabilir bir denklem sistemine dönüşür; BGE bu sistemi çözen bir algoritmayla (literatürde "afin eşdeğerlik algoritması") kodlamaları tek tek geri kazandı — bizim Bölüm 3'te "saldırgan G'yi bilmediği için Adım B çöker" dediğimiz noktayı, G'nin özel (afin) yapısını kullanarak aştı.

DFA: hata enjeksiyonu nasıl bir saldırıya dönüşür? (kavramsal, klasik DFA'nın yazılım hâli)¶

Bölüm 1'deki saldırgan oturumunun 5. adımını hatırlayın: beyaz kutu saldırgan, çalışma anında bir ara değeri değiştirebilir. Klasik (donanım) DFA, AES'te uzun süredir bilinen bir teknik ailesidir; whitebox bağlamındaki 2015 çalışması ("Unboxing the White-Box") aynı fikri yazılıma taşır. Adım adım mantığı:

1. Referans çalıştırma. Saldırgan seçtiği bir açık metni şifreletir, doğru şifreli metni kaydeder (hata yok).
2. Hatalı çalıştırma. Aynı açık metni tekrar şifreletir, ama bu kez çalışma anında (Bölüm 1'deki "kısmi çalıştırma/kurcalama" yeteneğiyle) belirli bir turdaki bir ara değere kasıtlı bir hata enjekte eder (ör. bir baytı çevirir). Hatalı şifreli metni kaydeder.
3. Fark alma. Doğru ve hatalı şifreli metinler karşılaştırılır. Aradaki fark, hatanın enjekte edildiği noktadaki ara değere ve dolayısıyla o noktada kullanılan anahtar malzemesine bağlıdır — hatanın etkisi rastgele değil, AES'in son turlarının doğrusal olmayan yapısı yüzünden anahtar hakkında bilgi taşıyan bir farktır.
4. Tekrarla ve daralt. Farklı hata noktaları/değerleriyle adım 1–3 tekrarlanır; her tekrar olası anahtar adaylarını daraltır, sonunda tek bir anahtara iner.

Neden whitebox'a özel bir sorun? Çünkü DFA, tasarımın iç kodlamalarını (G, F, karıştırıcı matrisler) hiç umursamaz — yalnız girdi/çıktı çiftlerindeki farkla ilgilenir. Bölüm 3'teki bütün emeğimiz (iç kodlama, karıştırıcı matris, dış kodlama) DFA'nın 3. adımındaki "fark, anahtar hakkında bilgi taşır" ilişkisini ortadan kaldırmaz — çünkü kodlamalar sabit kalsa da AES'in kendi matematiği (S-box'ın doğrusal olmayışı) hâlâ oradadır.

Fark/hata karşılaştırması fikrini oyuncak ölçekte görelim: aynı girdi için doğru ve hataya uğratılmış iki çalıştırmayı karşılaştırıp, farkın ne zaman bilgi taşıdığını izleyin. Bu, çalışan bir saldırı aracı değildir — gerçek DFA/DCA, bunun gibi yüzlerce-binlerce karşılaştırmayı istatistiksel olarak birleştirir.

Normal (bit 0 hatası), Zor (bit 7 hatası, 16 girdi) ve uç durum (hata maskesi sıfır — fark her zaman sıfır) örneklerini deneyin, ya da 🎲 ile kendi anahtarınızı ve hata konumunuzu üretin.

WhibOx: bağımsız bir sınav neden önemli?¶

WhibOx, akademisyenlerin ve şirketlerin kendi WB-AES tasarımlarını herkese açık olarak gönderip, dünyanın her yerinden araştırmacının bunları kırmaya çalıştığı bir yarışma dizisidir. Bunun önemi şudur: bir şirketin kendi iç ekibiyle test ettiği bir tasarımın "kırılmadı" demesiyle, bağımsız, çok sayıda ve motivasyonlu saldırganın önüne konmuş bir tasarımın "kırılmadı" demesi aynı güven düzeyinde değildir. WhibOx ikincisini sağlar. 12. haftada göreceğimiz "bağımsız değerlendirme" fikrinin whitebox'taki karşılığı budur.

Sıkça karıştırılan üç kısaltma: BGE, DCA, DFA¶

Zayıf ön bilgiyle bu üç kısaltmayı birbirine karıştırmak çok kolaydır — üçü de "whitebox'ı kırma" başlığı altında anılır. Aşağıdaki tablo onları birbirinden ayıran tek soruyu verir:

Karşı önlemler (savunma kuralları)¶

Araştırma durmadı; DCA/DFA'ye karşı önlemler geliştirildi. Ama hiçbiri "artık güvenli" demez; hepsi maliyeti artırır:

• Statik rastgelelik ve doğrusal olmayan maskeleme (ör. Biryukov–Udovenko 2018): DCA'nın dayandığı doğrusal korelasyonu bozmaya çalışır.
• Dış kodlama (F, G): DCA/DFA/BGE'yi zorlaştırır — ama gördüğümüz sınırla: standart AES uyumluluğunu kırar.
• Katmanlı savunma: WBC'nin çevresine 9. haftanın gizleme kuralları, 6. haftanın RASP'ı (anti-debug, kurcalama ve bütünlük denetimi) konur; amaç, saldırganın izleri toplamasını (DCA) ve hata enjekte etmesini (DFA) zorlaştırmaktır.
• Anahtar yenileme ve kısa ömür: Anahtar sık yenilenirse, bir anahtarı çıkarmanın değeri düşer (10. hafta, kripto-periyot).
• Cihaz/sürüm bağlama: Kod sökmeye (code lifting) karşı; tablolar yalnız belirli bir cihazda/sürümde anlamlı olur.
• Sunucu tarafı risk denetimi: Uçtaki koruma ne olursa olsun, işlemin sunucuda ayrıca değerlendirilmesi (hız sınırı, anomali, ATC/sayaç denetimi) son ve en güvenilir savunmadır.
• Donanım köküne taşıma: Mümkünse anahtarı hiç yazılıma koymamak — TEE, güvenli öğe (SE), HSM (bölüm 5).

Hangi karşı önlem hangi saldırıyı zorlaştırır? (özet tablo)¶

Yukarıdaki listeyi saldırılarla eşleştirelim — bir karşı önlem "her şeyi" durdurmaz, belirli bir saldırı sınıfını zorlaştırır:

Saldırının maliyeti saldırgan açısından: hangi teknik ne gerektirir?¶

Bölüm 2'de savunmacının maliyetinden söz etmiştik; şimdi aynı tabloyu saldırgan tarafından kuralım. Bir karşı önlemin "ne kadar işe yaradığını" değerlendirirken, saldırının gerektirdiği erişim ve beceri düzeyini de hesaba katmak gerekir — çünkü bir savunmanın amacı saldırıyı imkânsız kılmak değil, onu gereken beceri ve çabayı yükselterek çoğu saldırgan için karlı olmaktan çıkarmaktır.

5. WBC'nin katmanlı savunmadaki yeri¶

Bir güvenli programlama kuralı olarak WBC'yi nereye koyacağımızı netleştirelim. Aşağıdaki tablo, bir anahtarı korumak için seçeneklerin güç/maliyet sırasını verir:

Tablonun her satırını tek tek açalım, çünkü sınavda "hangi seçenek ne zaman doğrudur" sorusu gerekçesiyle sorulabilir:

• Sabit dizide düz anahtar. Bölüm 2'de gördük: entropi taraması ve doğrudan okuma ile saniyeler içinde bulunur. Hiçbir üretim sisteminde kabul edilebilir değildir.
• Gizlenmiş/parçalanmış anahtar. Bölüm 2'deki "yalnız XOR ile karıştırma" örneği gibi teknikler; çözme bilgisi anahtarla aynı binary'de olduğu için güç eklemez. Yalnız çok düşük değerli, çok kısa ömürlü sırlar için (ör. saniyeler süren bir geçici belirteç) kabul edilebilir, çünkü saldırganın kazancı zaten sınırlıdır.
• WBC + katmanlı savunma. Bölüm 3–4'te gördüğümüz gibi anahtarı matematiksel olarak tablolara dağıtır; tek başına değil, anahtar yenileme + cihaz bağlama + sunucu denetimiyle birlikte kullanılınca orta düzeyde bir gecikme sağlar. Donanım kökü yokken en iyi seçenektir.
• TEE / Güvenli Öğe (SE). Anahtar hiçbir zaman normal işletim sistemi belleğine açık biçimde çıkmaz; bu yüzden yazılım tabanlı bütün saldırılara (entropi taraması, cebirsel çözüm, DCA, DFA, code lifting) karşı yapısal olarak dirençlidir. Cihaz destekliyorsa tercih nedeni budur.
• HSM / SoftHSM. Bölüm 5'in az önceki alt bölümünde gördüğümüz gibi, sunucu tarafı için aynı fikrin karşılığıdır; gerçek HSM'de anahtar donanımdan hiç çıkmaz, SoftHSM'de ise yalnız arayüz aynıdır, güvence düzeyi düşüktür (geliştirme/test dışında kullanılmamalı).

İşlenmiş örnek: karar kuralını üç varlığa uygulayalım¶

Kuralı soyut bırakmayalım; hayali (sentetik) bir mobil uygulamanın üç farklı varlığı için, sırayla karar verelim. Her varlık için üç soru soracağız: (1) Varlığın değeri ne kadar yüksek? (2) Cihazda bir donanım kökü (TEE/SE) var mı/güvenilir mi? (3) Varlık ne kadar sık/uzun süre kullanılacak?

Gözlenen örüntü: WBC, tablo sadece 2. satırda ortaya çıkıyor — yani "donanım kökü güvenilir biçimde yok" ve "değer düşük değil" kesişiminde. 1. satırda WBC gereksiz maliyet; 3. satırda WBC gereksiz risk (madem anahtarı hiç istemciye koymaya gerek yok, koymamak her zaman daha güvenlidir).

Aynı kararı üç değil, 12-16 varlığa uygulayalım. Aşağıdaki animasyon her varlık için altı katmanı (OBF, WBC, ROTATE, BIND, AUDIT, HWROOT) tek tek sorar; wbc kararının her zaman dört katmanı birlikte etkinleştirdiğini, plain kararının ise hiçbirini etkinleştirmediğini (bu yüzden "asla") izleyin.

Normal (12 varlık, dört karar da temsil ediliyor), Zor (16 varlık) ve uç durum (hepsi WBC / hepsi donanım kökü) örneklerini deneyin, ya da 🎲 ile kendi varlık listenizi üretin.

"Donanım kökü var ama güvenilir değil" ne demek?¶

Yukarıdaki tablonun ikinci satırındaki "TEE varsa TEE; yoksa WBC" kararının içinde gizli bir varsayım var: TEE'nin varlığı, ona güvenilebileceği anlamına gelmez. Bunu açalım:

• Cihaz kök erişimine (root/jailbreak) sahipse: işletim sistemi seviyesindeki birçok koruma devre dışı bırakılabilir. TEE, işlemcinin ayrı bir güvenlik sınırı olduğu için genelde yine de dirençlidir — ama TEE'ye erişimi yöneten arabirimler güvenilmeyen işletim sisteminden çağrıldığı için, uygulamanın "TEE'yi doğru kullandığından" ekstra emin olunması gerekir.
• Eski/düşük maliyetli cihaz modelleri: TEE desteği iddia etseler bile, üretici tarafından yeterince test edilmemiş ya da güncel olmayan bir TEE gerçekleştirimi sunabilirler.
• Uygulamanın kontrol edemediği bir değişken: bir mobil uygulama, çalıştığı binlerce farklı cihaz modelini tek tek doğrulayamaz; bu yüzden "TEE var" bilgisini koşulsuz güvenilir kabul etmek risklidir.

Pratik sonuç: Gerçekçi bir tasarım, "TEE varsa kesin güvenli" demez; TEE'yi tercih eder ama Bölüm 5'in geri kalan katmanlarını (anahtar yenileme, sunucu risk denetimi) TEE olsa bile tamamen bırakmaz — yalnız saf yazılım (WBC) durumundaki kadar ağır uygulamayabilir. Bu, "tek katman = kırılgan katman" kuralının (Bölüm 6) donanım köküne bile uygulanmasıdır.

SoftHSM ve PKCS#11 (sunucu tarafı köprü, 10. haftadan)¶

Onuncu haftada anahtar saklama için PKCS#11 ve SoftHSM'den söz etmiştik. Sunucu tarafında anahtar, standart bir PKCS#11 arayüzü ardında tutulur; uygulama anahtarın değerini hiç görmez, yalnız "şunu imzala/şifrele" der. SoftHSM, gerçek bir HSM'in yazılım benzetimidir; aynı arayüzü sunar, bu yüzden geliştirme ve test için kullanılır ama gerçek donanım koruması sağlamaz. WBC'nin uçtaki (istemci) problemine karşılık, bu sunucudaki anahtar problemine yanıttır.

Bir imzalama isteği PKCS#11 ardında adım adım nasıl işlenir?¶

Fikri somutlaştırmak için, sunucu tarafındaki bir uygulamanın bir işlemi imzalattığı anı adım adım izleyelim (kavramsal akış; gerçek bir API çağrısı dizisi değil):

1. Uygulama bir istek hazırlar. "Şu 32 baytlık özet değerini, anahtar-kimliği=7 ile imzala" der. Uygulama anahtarın değerini hiçbir zaman görmez, yalnız bir kimlik (ID) ile referans verir.
2. PKCS#11 katmanı isteği modüle iletir. İstek, standart PKCS#11 arayüzü üzerinden ya gerçek bir HSM'e ya da (geliştirme/test ortamında) SoftHSM'e gider.
3. Modül anahtarı kendi sınırları içinde kullanır. Modül (HSM ya da SoftHSM), anahtar-kimliği=7'ye karşılık gelen özel anahtarla imzalama işlemini kendi içinde yapar; özel anahtar modülün dışına hiçbir zaman çıkmaz.
4. Yalnız sonuç döner. Uygulamaya yalnızca imza (sonuç) döner; anahtarın kendisi asla ağ üzerinden ya da bellek arasında düz biçimde dolaşmaz.

Gerçek HSM ile SoftHSM arasındaki fark tam olarak burada devreye girer: gerçek bir HSM'de 3. adım, kurcalamaya dirençli, dışarıdan erişilemeyen bir donanım çip içinde olur — işletim sistemi seviyesinde bir saldırgan bile anahtarı çıkaramaz. SoftHSM'de ise aynı 3. adım, sunucunun kendi belleğinde, normal bir işlem olarak çalışır; arayüz (API) aynıdır ama altındaki güvence düzeyi tamamen farklıdır — sunucuyu ele geçiren bir saldırgan, SoftHSM'in bellek alanına da erişebilir.

6. Hatalı → saldırı → koruma (özet senaryo)¶

Bu haftanın kurallarını tek bir hikâyede toplayalım (sentetik, savunma amaçlı):

1. Hatalı tasarım: İstemci uygulaması bir veri şifreleme anahtarını static const uint8_t k[16] olarak gömer.
2. Saldırı (kavramsal): strings ve entropi taraması yüksek entropili 16 baytlık bloğu bulur; bir hata ayıklayıcı, şifreleme çağrısında bu bloğun anahtar olarak kullanıldığını doğrular. Anahtar dakikalar içinde çıkar.
3. Koruma (katmanlı):
4. Anahtarı mümkünse TEE/SE'ye taşı; değilse WBC tablolarına göm (düz bayt dizisi kalmasın).
5. WBC'yi 9. haftanın gizleme kurallarıyla ve 6. haftanın RASP'ıyla (anti-debug, kurcalama tespiti) sar; böylece DCA izleri toplamak ve DFA hata enjekte etmek zorlaşır.
6. Cihaz/sürüm bağla: tablolar başka cihaza kopyalanınca (code lifting) işe yaramasın.
7. Anahtarı sık yenile (kısa kripto-periyot) ve sunucuda risk denetimi uygula.
8. Dürüst kalan risk: Yeterince kararlı bir saldırgan tek bir cihazda anahtarı yine de çıkarabilir; ama artık bir kopyayı kırmak bütün sistemi açmaz ve çıkarılan anahtarın ömrü kısadır.

İkinci senaryo: kod sökmeye (code lifting) karşı katmanlar (sentetik)¶

Aynı yapıyı, bu kez Bölüm 2'de tanımladığımız kod sökme tehdidine karşı işleyelim — çünkü bu tehdit, "anahtarı düz gömme" hatasından farklı bir hata sınıfına karşılık gelir ve farklı katmanlar gerektirir.

1. Hatalı tasarım. Bir dijital içerik uygulaması (sentetik: bir "lisans doğrulama" bileşeni), whitebox AES rutinini dış kodlama olmadan (yalnız Bölüm 3'teki iç kodlama + karıştırıcı matrislerle) kurar. Rutin, herhangi bir uygulamadan çağrılabilecek bağımsız bir fonksiyon gibi tasarlanmıştır: girdi/çıktı standart AES girdi/çıktısıyla aynı biçimdedir (Bölüm 3, Adım 5'teki "dış kodlama olmadan AES işlevini birebir hesaplar" durumu).
2. Saldırı (kavramsal). Saldırgan anahtarı hiç çıkarmaya çalışmaz (BGE/DCA/DFA gerekmez). Bunun yerine, whitebox tablolarını ve onları çağıran kodu olduğu gibi kopyalar, kendi sahte uygulamasına yapıştırır. Sahte uygulama artık geçerli lisans yanıtları üretebilir — anahtarı hiç bilmeden, yalnızca işlevi çalarak.
3. Koruma (katmanlı).
4. Dış kodlama (F, G) ekle (Bölüm 3, Adım 5): rutinin girdi/çıktısını uygulamaya özgü bir biçime bağla; artık rutin "genel AES" hesaplamaz, yalnız bu uygulamanın beklediği kodlanmış girdi/çıktıyla anlamlı sonuç verir.
5. Cihaz/sürüm bağlama ekle (Bölüm ⅘): dış kodlamanın parametreleri, cihaz kimliği ya da sürüm bilgisiyle türetilsin; tablolar başka bir cihaza kopyalanınca farklı (yanlış) sonuç üretsin.
6. Sunucu tarafı doğrulama ekle: lisans yanıtı, sunucuda ayrıca denetlensin (ör. beklenmedik cihaz sayısından aynı lisansın kullanılması, anomali olarak işaretlensin).
7. Dürüst kalan risk. Dış kodlama ve cihaz bağlama, kod sökmeyi o cihaza özgü hale getirerek zorlaştırır; ama saldırgan o cihazın kendisini ele geçirirse (ör. cihazın tamamını kopyalarsa), yine de çalışan bir kopya elde edebilir. Bu yüzden 3. adımdaki sunucu tarafı denetim, son savunma hattı olarak kalır — tıpkı ilk senaryodaki gibi.

Her iki senaryo için kaba bir zaman çizelgesi¶

Sayısal bir kesinlik iddia etmeden, "hangi adım ne kadar sürer" konusunda mertebe hissi vermek faydalıdır — Bölüm 4'teki "saldırının maliyeti" tablosuyla aynı ruhta:

İki senaryonun ortak dersi¶

Önce iki senaryoyu yan yana koyup farklarını görelim:

İki senaryo da farklı hatalarla başlıyor (düz gömülü anahtar vs. dış kodlamasız rutin) ve farklı ilk saldırılarla ilerliyor (entropi taraması/cebirsel çözüm vs. doğrudan kopyalama) ama aynı yerde bitiyor: tek bir teknik katman (yalnız WBC, yalnız cihaz bağlama, yalnız sunucu denetimi) hiçbirinde tek başına yetmiyor. Bu, dersin baştan beri işlediği örüntüyü doğrular:

• 3. hafta: "Gizlilik kriptografinin işidir, algoritmanın gizliliğine güvenmeyin" (Kerckhoffs).
• 9. hafta: "Tek bir gizleme kuralı yetmez, K-01…K-08'i katmanlayın."
• 11. hafta (bu hafta): "Tek bir whitebox tasarımı yetmez; anahtar yenileme + cihaz bağlama + sunucu denetimi + (mümkünse) donanım köküyle katmanlayın."

Üç haftanın da ortak cümlesi: "tek katman = kırılgan katman."

Bu haftanın büyük resmi: baştan sona tek bir bakış¶

Proje bölümünüzü yazmadan önce, bu haftanın yedi bölümünün (0–6) nasıl tek bir hikâye oluşturduğunu, baştan sona, kısaca gözden geçirelim. Amaç yeni bir şey öğretmek değil, öğrendiklerinizin birbirine nasıl bağlandığını bir kez daha görmenizdir.

1. Bölüm 0 — Temel kavramlar. Sıfırdan başladık: şifreleme, anahtar, S-box, arama tablosu, XOR, bijeksiyon, entropi, iz, korelasyon, GF(2)... Bunların hiçbiri whitebox'a özel değildi; hepsi araçlarımızdı. Bölüm 1'den itibaren bu araçları kullandık.
2. Bölüm 1 — Üç saldırgan modeli. 3. haftadaki kara kutu varsayımının, istemci tarafı kodda çöktüğünü gördük. Beyaz kutu saldırganın altı adımlık oturumunu (edinme → statik analiz → hata ayıklayıcı → bellek okuma → kurcalama → otomasyon) izledik. Bu altı adım, Bölüm 4'teki bütün saldırıların (BGE=statik, DCA/DFA=dinamik) ön koşuluydu.
3. Bölüm 2 — Problem neden zor? Naif çözümlerin (düz anahtar, yalnız XOR) neden çöktüğünü elle hesapladık (0x3C XOR 0x5A örneği). Kod sökme tehdidini tanıdık. WBC'nin, "9. haftanın gizleme kurallarının kriptografiye uygulanmış hâli" olduğunu gördük.
4. Bölüm 3 — Chow AES, adım adım. Beş adımı (kısmi değerlendirme → T-box birleştirme → iç kodlama → karıştırıcı matris → dış kodlama) oyuncak bir S-box üzerinde tamamen elle kurduk: önce anahtarı 4 girdiden de tutarlı biçimde çıkardık (Adım A–C), sonra iç kodlama G ekleyince aynı saldırının çelişkili ve yanlış sonuçlar verdiğini gördük, sonra DCA'nın bunu neden basit bir eşleşme testiyle değil istatistikle aştığını bir tabloyla izledik. Bölümü, boyut/hız maliyetinin mertebesini hesaplayarak kapattık.
5. Bölüm 4 — Saldırı geçmişi. BGE (matematik), DCA (istatistik) ve DFA (sabotaj) saldırılarını birbirinden ayırt etmeyi öğrendik; WhibOx'un neden bağımsız bir sınav olduğunu gördük; her karşı önlemin yalnız belirli saldırıları zorlaştırdığını bir tabloyla doğruladık.
6. Bölüm 5 — Katmanlı savunmadaki yer. Üç somut varlık (oturum belirteci, yerel DB anahtarı, ödeme imzalama anahtarı) üzerinden, WBC'nin ne zaman doğru seçim olduğuna karar verdik. SoftHSM'in yalnız arayüz sağladığını, gerçek güvenceyi sağlamadığını gördük.
7. Bölüm 6 — İki senaryo. Aynı "hatalı → saldırı → koruma" iskeletini, iki farklı hataya (düz anahtar, dış kodlamasız rutin) uyguladık; ikisi de aynı derste bitti: tek katman yetmez.

Sonraki adım (Bölüm 7): şimdi bu bilgiyi kendi projenize uygulayacaksınız — bir anahtar seçip, onun için aynı zinciri (varlık değeri → tehdit modeli → seçilen katmanlar → dürüst kalan risk) kendi cümlelerinizle yazacaksınız.

7. Dönem projesi: bu hafta (S8 — anahtar koruma gerekçesi)¶

Projenizin S8 (kripto ve anahtarlar) bölümüne en az bir hassas anahtar için bir koruma kararı ve gerekçesi ekleyin:

1. Anahtarın nerede durduğu, nasıl korunduğu (düz saklanmıyorsa: TEE/SE, WBC, gizleme — hangisi ve neden).
2. Koruma yeterli değilse (ör. saf yazılımdaysanız) bunu açıkça yazın ve telafi eden katmanları belirtin: anahtar yenileme periyodu, cihaz/sürüm bağlama, sunucu risk denetimi.
3. Kullanmıyorsanız (ör. WBC uygulamadıysanız) neden kullanmadığınızın gerekçesi (maliyet, donanım kökü var, varlık değeri düşük). Gerekçeli bir "kullanmadık" tam bir yanıttır.

İşlenmiş örnek: doldurulmuş bir S8 gerekçe metni¶

Ne yazacağınızı somutlaştırmak için, sentetik bir örnek proje üzerinden S8 bölümünün nasıl doldurulacağını adım adım gösterelim (bu metni birebir kopyalamayın; kendi projenizin varlıklarına göre yazın):

Bu örnekte neyin doğru yapıldığına dikkat edin: metin hiçbir yerde "whitebox kullandık, güvenliyiz" demiyor; her cümle hangi tehdide karşı hangi katmanın konduğunu ve neden yeterli/yetersiz olduğunu söylüyor. Bir değerlendirici için asıl önemli olan budur.

Kendi kendinize kontrol: S8 taslağınız hazır mı?¶

Projenizin S8 bölümünü yazmadan/teslim etmeden önce şu kısa listeyi işaretleyin:

• En az bir hassas anahtar adı ve neyi koruduğu açıkça yazılı mı?
• Anahtarın nerede durduğu (TEE/SE, WBC, gizlenmiş, düz — hangisi) belirtilmiş mi?
• Saf yazılım koruma (WBC ya da gizleme) kullanılıyorsa, en az iki telafi edici katman (yenileme, cihaz bağlama, sunucu denetimi, RASP) adı geçiyor mu?
• Bir koruma kullanılmadıysa, gerekçe (maliyet/donanım yok/değer düşük) açıkça yazılmış mı — yoksa sessizce mi geçilmiş?
• Metinde hiçbir yerde "WBC = güvenli" gibi bu haftanın ana kuralıyla çelişen bir cümle yok mu?
• Depoda/örneklerde gerçek bir anahtar, parola ya da sır yok mu (aşağıdaki uyarı)?

Zayıf ve güçlü bir S8 gerekçesi yan yana¶

Bu haftaki en sık geri bildirim, gerekçelerin çok kısa ve genel yazılmasıdır. Aynı varlık için zayıf ve güçlü bir yanıtı yan yana koyalım, aradaki farkı görün:

Kısa formül: varlık adı + nerede korunuyor + hangi tehdide karşı + sınırı ne + telafi eden katmanlar. Beş öğeden biri eksikse, gerekçe muhtemelen zayıf kategoridedir.

Sık sorulan sorular (S8 hakkında)¶

8. Kendini sınama¶

Sınavdan önce hızlı tekrar: terimler sözlüğü¶

Kendini sınama sorularını çözmeden ya da sınava girmeden önce, bu haftanın bütün terimlerini tek bakışta gözden geçirmek için aşağıdaki tabloyu kullanın. Her terim, ilk tanımlandığı bölüme işaret eder — takıldığınız bir terim olursa o bölüme dönüp bağlamıyla birlikte okuyun.

9. Kaynaklar ve ileri okuma¶

• Güvenli programlama teknik kılavuzu (ders kaynağı) — WBC saldırgan modeli ve whitebox AES'in bir üründe konumu; "anahtarlar güvence altına alınmalı ve/veya gizlenmelidir" gereksinimi.
• S. Chow, P. Eisen, H. Johnson, P. van Oorschot — "White-Box Cryptography and an AES Implementation" (SAC 2002) ve WB-DES (DRM 2002) — tablo tabanlı WBC'nin temeli.
• B. Wyseur — "White-Box Cryptography: Hiding Keys in Software" (kısa giriş) — öğrenciye uygun genel bakış.
• Billet, Gilbert, Ech-Chatbi — BGE saldırısı (SAC 2004).
• Bos, Hubain, Michiels, Teuwen — "Differential Computation Analysis" (CHES 2016).
• Sanfelix, Mune, de Haas — "Unboxing the White-Box" (Black Hat EU 2015) — DFA/DPA.
• WhibOx yarışması sonuçları (2017–2024) — yayımlanmış tasarımların durumu.