AES-256 ve Çalışma Modları

Yazılım geliştirme süreçlerinde şifreleme genellikle kütüphane çağırmaktan ibaret görülür. Çoğu geliştirici sisteme bir metin gönderir geriye anlamsız karakterler döner ve işin bittiğini düşünür. Ancak büyük ölçekli mimariler tasarladığınızda, ödeme sistemleri entegre ettiğinizde veya sunucu seviyesinde veritabanı taşıdığınızda o kütüphanenin arka planda ne yaptığını bilmemek, sisteminizi geri dönüşü olmayan güvenlik zafiyetlerine sürükler.

Gündelik hayatta kullandığımız “Çelik Kasa” metaforundan yola çıkarak, AES-256'nın nasıl çalıştığını ve çalışma modlarının gerçek dünyadaki mimari karşılıklarını mühendislik perspektifiyle inceleyeceğiz.

AES-256 Aslında Nasıl Çalışır?

AES (Advanced Encryption Standard), simetrik bir şifreleme algoritmasıdır. Yani kasanın kapağını kilitleyen anahtar ile açan anahtar birebir aynıdır. 256 bitlik bir anahtarın kaba kuvvet (brute-force) ile kırılması evrenin yaşından daha uzun süreceği için bugün askeri ve finansal sistemlerin belkemiğidir. (2²⁵⁶ yani yaklaşık 1,16 × 1⁰⁷⁷)

Ancak AES, verinizi harf harf şifrelemez. Sabit 16 byte’lık bloklar halinde, ardışık matematiksel turlarla çalışan bir “şifreleme fırınıdır”. İşin en çarpıcı yanı şudur: Modern şifrelemede orijinal veriniz o fırının içine asla girmez.

Diyelim ki şifrelemek istediğiniz kelime “KASA”. Algoritma şu adımları izler:

1. Anahtarın Çoğaltılması (Key Expansion): Fırın çalışmadan önce, elinizdeki tek bir 256 bitlik ana anahtardan, sürecin farklı aşamalarında kullanılmak üzere 15 farklı alt anahtar yontulur.

2. Sayacın (IV) Hazırlanması: Algoritma “KASA” kelimesini kenarda bekletir. Onun yerine rastgele sayılardan ve artan bir numaradan oluşan 16 byte’lık bir “Sayaç Bloğu” (IV) oluşturur. Fırına girecek olan malzeme orijinal metniniz değil, bu sayaçtır.

3. Fırın Çalışıyor (14 Tur): Sayaç fırına girer girmez birinci alt anahtarınızla kilitlenir. Ardından tam 14 kez tekrarlanan bir kaos başlar:

• SubBytes: Sayaçtaki sayılar, standart bir sözlük (S-Box) kullanılarak tamamen başka sayılarla değiştirilir.

• Blender (ShiftRows & MixColumns): Matrislere bölünen sayılar satır satır kaydırılır ve sütunlar karmaşık bir matematikle birbirine karıştırılır. Başlangıçtaki tek bir bitlik fark, bu aşamada çığ etkisi yaratarak tüm bloğu değiştirir.

• AddRoundKey: Her turun büyük finalinde, o tur için üretilmiş yeni alt anahtarınız bu çorbaya XOR işlemiyle eklenir. Bu, sistemin herkesçe bilinen matematiğini sadece sizin anahtarınızla çözülebilir hale getiren o gizli sostur. 4. Şifre Akışı ve Büyük Buluşma: 14 turun sonunda fırına giren o sayaç, tamamen kaotik ve kırılmaz bir “Şifre Akışına” (Keystream) dönüşerek dışarı çıkar. Kenarda bekleyen orijinal “KASA” kelimeniz, dijital bir kapıda bu şifre akışıyla XOR’lanarak (çarpıştırılarak) üst üste bindirilir.

Çıktı dışarıya gönderilecek olan, orijinal veriyle hiçbir bağı kalmamış, tamamen anlamsız bir şifreli metindir (Ciphertext).

Çözerken ise sistem fırını yine aynı sayaç ve anahtarla baştan çalıştırır, aynı şifre akışını yeniden üretir ve gelen şifreli metinle tekrar XOR’layarak orijinal veriyi pırıl pırıl geri çıkartır.

Dikkat: Anahtar yoksa veride yok!

Güven Yanılgısı

Buraya kadar her şey kusursuz görünüyor. Biz karıştırdık ettik accayip kriptografik bir veri oluştu. Kasanın anahtarı olmadan kimse içindeki mesajı okuyamaz. Tamam. Ancak kriptografideki en ölümcül hata şudur: Şifreleme verinin okunmasını engeller, kurcalanmasını değil.

‘Yaani kardeş maaşı 300.000 yen olan ceo’nun maaşını kendi hücreme kopyalamama engel bir durum var mı?’

Diyelim ki veritabanına şifrelenmiş bir ödeme emri kaydettiniz: “Tutar: 100”.

Bir saldırgan sisteme sızdı, şifreli veriyi okuyamıyor ama metnin ortasındaki şifreli bir bloğu sildi, yerine rastgele sayılar yazdı. Eğer sisteminizde sadece standart AES çalışıyorsa, şifre çözücü bu bozuk veriyi alır, fırına atar ve körlemesine çözer. Ortaya “Tutar: 900” gibi manipüle edilmiş geçerli bir komut çıkabilir ve sistem bunu sessizce onaylar.

Saldırgan mesajı okuyamamış ama yapısını bozarak sistemi manipüle etmiştir. (Bit-Flipping Attack). İşte AES Çalışma Modları, veriyi bu senaryolara, çalışacağı fiziksel ortama ve mimariye göre korumak için geliştirilmiştir.

1. AES-GCM (Galois/Counter Mode): Sihirli Mühür

Modern yazılım mimarilerinde, API haberleşmelerinde ve dış entegrasyonlarda endüstri standardı GCM’dir. GCM, sadece veriyi şifrelemekle kalmaz, üzerine bir de “Doğrulama Etiketi” (Auth Tag) adını verdiğimiz matematiksel bir mühür vurur.

**Nasıl Çalışır?**GCM, yukarıda anlattığımız şifreleme işlemi bittikten hemen sonra şifreli metni paketlere böler. Özel bir kar topu matematiğiyle (GHASH) her paketi gizli anahtarınızla zincirleme olarak çarparak 16 byte’lık bir dijital parmak izi (Auth Tag) çıkartır.

Gateway SSO ve Webhook Entegrasyonları

Kurumsal bir Gateway uygulamasında dışarıdan bir ödeme webhook’u alıyorsunuz. Saldırgan araya girdi ve şifreli payload üzerindeki tek bir sayıyı değiştirdi. Sisteminiz veriyi çözmek için aldığında önce Auth Tag’i hesaplar. Metindeki tek bir bitin bile değişmiş olması, kar topu reaksiyonunu tamamen saptırır ve yeni hesaplanan etiket, gelen etiketle uyuşmaz. Sistem, kasanın anahtar deliğine anahtarı sokmaya bile tenezzül etmeden “Veri tahrif edilmiş! tevkiftir o” diyerek işlemi anında durdurur.

2. AES-XTS (XEX-based Tweaked-Codebook): Disklerin Fiziksel Bekçisi

GCM mükemmeldir ama her yere sığmaz. Büyük bir PostgreSQL veritabanını fiziksel disk seviyesinde şifrelerken (TDE) GCM kullanamazsınız. Disk sektörleri tam 4096 byte’tır. Şifrelenen veriye 16 byte’lık bir Auth Tag eklerseniz, veri 4112 byte olur ve yuvaya sığmaz. Taşma, dosya sistemini çökertir. Auth Tag kullanamayacağınız bu ortamlarda XTS modu devreye girer.

**Nasıl Çalışır?**XTS, iki farklı gizli anahtar kullanır. Birinci anahtar veriyi fırında şifrelerken, ikinci anahtar verinin diskin hangi numaralı sektörüne yazıldığını (Tweak) şifreler.

Senaryo: Veritabanı Taşıma ve Sunucu GüvenliğiEğer bir saldırgan veritabanı dosyasının içine girip, 50. sektördeki şifreli bir maaş verisini kopyalayıp 100. sektöre yapıştırırsa sistem bunu yutmaz. Veritabanı motoru 100. sektörü okurken fiziksel konumu “100” olarak hesaplar ancak verinin içine “50” konumunun şifresi gömülüdür. Uyuşmazlık nedeniyle veri fırından tamamen bozuk, anlamsız çöp karakterler halinde çıkar. Veritabanı bu formatı tanıyamadığı için “Veri Sayfası Bozulması” (Data Page Corruption) hatası verir ve okumayı reddeder. XTS, alarm vermese bile veriyi kullanılamaz hale getirerek manipülasyonu engeller.

3. AES-CCM: IoT’nin Kısıtlı Dünyası

Elinizde sahada çalışan, işlem gücü çok zayıf sensörler veya donanımsal AES çipi olmayan IoT cihazları varsa, GCM’in matematiği bu cihazları kilitler. CCM, tıpkı GCM gibi hem şifreleme hem de doğrulama mührü sağlar ancak matematiği donanımı yormayacak şekilde tasarlanmıştır. Akıllı fabrika otomasyonlarında veya veri toplayan düşük profilli uç noktalarda, güvenliği performansa feda etmemek için standart olarak CCM tercih edilir.

Mimari Karar

Kriptografi, veriyi karmaşık karakterlere çeviren sihirli bir kutu değildir. Geliştirdiğiniz yazılımın üzerinde koştuğu donanım, verinin ağ üzerinde mi yoksa diskte mi durduğu, iletişim kurduğunuz sistemin kaynak sınırları; hangi AES modunu seçeceğinizi belirler. Doğru modu seçmek, sistemi çalışır kılmakla kalmaz, onu ayakta tutar.

Dikkat! AES-256 Bir Güvenlik Sistemi Değildir!

Burada kritik bir ayrımı yapmak gerekiyor: AES-256 bir şifreleme algoritmasıdır; güvenlik mimarisinin tamamı değildir.

AES-256 kullanıyor olmanız sisteminizin otomatik olarak güvenli olduğu anlamına gelmez.

Anahtar kötü yönetiliyorsa AES-256'nın matematiksel güvenliği hiçbir anlam ifade etmez. Anahtarı kaynak koduna yazmak, Git reposuna commit etmek, .env dosyasını yanlışlıkla public hale getirmek veya bütün servislerde aynı anahtarı kullanmak, 256 bitlik anahtarı pratikte değersiz hale getirebilir.

‘Anahtar herkeste varsa ortada güvenlik yoktur’

Gerçek dünyada saldırganların çoğu AES’in kendisini kırmaya çalışmaz. Anahtarı bulmaya, bellekte yakalamaya, loglarda görmeye veya anahtarın kullanıldığı sistemi ele geçirmeye çalışır.

Bu nedenle gerçek güvenlik zinciri:

Algoritma → Mod → IV/Nonce → Anahtar Yönetimi → Yetkilendirme → Bütünlük → Anahtar Rotasyonu

AES-256'nın gücü, bu zincirin yalnızca bir halkasıdır.

Nonce’dan Bahsetmedik: IV/Nonce Yönetimi

AES-GCM kullanırken anahtar kadar önemli olan ikinci değer nonce’tur.

GCM’de aynı anahtarla aynı nonce’un tekrar kullanılması güvenliği ciddi şekilde tehlikeye atabilir. Bu nedenle “her şifrelemede yeni IV üretelim” yaklaşımı tek başına yeterli değildir; kullanılan yöntemin nonce tekrarını gerçekten engellediğinden emin olmak gerekir.

Örneğin iki farklı mesaj:

M1 → AES-GCM(Key, Nonce)

M2 → AES-GCM(Key, Aynı Nonce)

şeklinde şifrelenirse sistemin güvenlik varsayımları bozulur.

Bu nedenle üretim sistemlerinde nonce üretimi rastgelelik, sayaç veya güvenli bir benzersizlik mekanizması üzerinden tasarlanmalıdır.

AES-GCM’de anahtarın gizli olması kadar nonce’un tekrar etmemesi de kritiktir.

Nonce = Number used once, yani “bir kez kullanılan sayı/değer”.

Şifreleme yaparken aynı veriyi aynı anahtarla şifrelediğinde her seferinde farklı sonuç elde etmek isteriz. İşte nonce bunun için kullanılır.

Basit bir örnek düşün:

Mesaj: "KASA" Anahtar: ABC123

Nonce kullanmazsak:

KASA + ABC123 → X7F91A KASA + ABC123 → X7F91A

Aynı mesaj → aynı şifreli çıktı.

Nonce eklersek:

KASA + ABC123 + Nonce: 001 → X7F91A KASA + ABC123 + Nonce: 002 → P3K82Z KASA + ABC123 + Nonce: 003 → Q9L44B

Aynı mesajı ve aynı anahtarı kullansak bile nonce değiştiği için ciphertext değişir.

Dostlar bu konu bitmez takipte kalın.

Daha Fazlası

Ben Fikret Sefa Çakır, 2017 yılından bu yana yazılım geliştirme süreçlerinin tüm aşamalarında — analiz, tasarım, geliştirme, test ve canlıya alma — aktif olarak görev alıyorum.

Kurumsal .NET projeleri, mikroservis mimarileri, güvenli yazılım geliştirme, API tasarımı ve modern frontend teknolojileri üzerine çalışıyor; edindiğim deneyimleri teknik makaleler ve açık kaynak projeleriyle paylaşmaya devam ediyorum.

Daha fazla bilgi almak, danışmak ya da birlikte çalışmak için benimle iletişime geçebilirsin.

Daha fazla teknik içerik için;

• GitHub: github.com/fikretsefa

• LinkedIn: linkedin.com/in/fikretsefa/