Week 3 — Data Security: In Transit, At Rest, In Use¶

Click inside the slides and use the arrow keys; use the button at the bottom right of the slides or the link above for full screen.

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

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

0. Before we start¶

This section prepares you for the week. It first briefly recalls the earlier topics this week builds on; it then defines each of this week's concepts in one sentence and links it to the section where it is explained in full.

What we bring from earlier weeks¶

• The white-box attacker model — the user who owns the device or server is also a potential attacker; they can read memory and attach a debugger (Week 1, §3). This week we reuse this model for data in use (Section 13) and the whitebox cryptography motivation (Section 15).
• Secure erasure from memory — wiping a secret with a function the compiler can't remove (explicit_bzero, OPENSSL_cleanse) (Week 1, §17). This week Section 13 adds blocking dumps, memory locking, and device binding on top of this.
• Entropy measurement — measuring the disorder in a file's bytes to tell encrypted/packed content apart (Week 2, §6). Section 3 uses the same idea, this time for the disorder (entropy) feeding a random generator.

This week's concept map¶

1. The three states of data and the security shell¶

Over the past two weeks we protected the program itself with "bug → attack → fix." This week we shift the focus to data. A secret — a password, a payment key, personal information — exists in three separate states across its lifecycle, and each state has a different threat and a different defence:

Recall the example architecture we use throughout the term (a mobile payment app plus a security library that handles its critical work). This week we fill in the three interfaces in that architecture: phone ↔ server (in transit), the encrypted database on the phone (at rest), and the key opened in memory at the moment of payment (in use).

In this architecture the phone is an untrusted environment (the user — i.e., a potential attacker — owns the device; it may be rooted, a debugger may be attached). The server side is trusted. For every interface in between we ask: which data crosses it, in which state (transit/storage/use), how is identity verified, and is confidentiality needed, integrity, or both? This week's demos build exactly the answers to these questions:

• Phone ↔ server (in transit): TLS 1.3 + certificate validation + pinning, plus message-level AEAD on top (Demo 6, 1, 5).
• Local database (at rest): sensitive fields with AES-GCM under a device-bound key (Demo 7, 4).
• Memory during payment (in use): the key is open for the shortest possible time, securely erased after use, device-bound (Demo 8, 9).

All example values are synthetic (made up); no real key, card number, device ID, or IP address is used.

2. Encryption fundamentals: which tool protects what?¶

Encryption turns readable data (plaintext) into unreadable data (ciphertext) using a key; decryption reverses this with the same (or a matching) key. Security rests on the secrecy of the key, not the algorithm. But cryptography isn't one single thing; there are different tools for different goals. Let's clarify the four families that get confused most often.

2.1 Authenticated encryption (AEAD): confidentiality + integrity in one call¶

The right answer is almost always AEAD (Authenticated Encryption with Associated Data). AEAD does two things in a single operation: it encrypts the data (confidentiality) and produces a tag that proves the ciphertext (and optionally the additional "associated data") hasn't changed (integrity + identity). On decryption the tag is verified: if even a single bit was tampered with, decryption is rejected.

Two modern AEADs:

• AES-GCM — very fast on processors with hardware AES acceleration (most desktops/servers). NIST SP 800-38D.
• ChaCha20-Poly1305 — faster and more side-channel-resistant on devices without AES hardware (some mobile/embedded platforms). RFC 8439.

2.2 Symmetric or asymmetric? Answer: both (hybrid)¶

Symmetric encryption (AES) is fast but requires both sides to know the same secret key; how do you share that key over an insecure network? Asymmetric encryption (RSA, elliptic curve) solves this: everyone has a public key (distributed) and a private key (kept secret). But asymmetric operations are slow and unsuited to large data.

Real systems therefore run in hybrid mode: asymmetric crypto is used only to securely carry (or agree on) a small symmetric key; the actual data is then encrypted with that symmetric key using AEAD. This is exactly what TLS does: during the handshake, elliptic-curve Diffie-Hellman agrees on a session key, and then all traffic is encrypted with AES-GCM or ChaCha20-Poly1305.

2.3 Block or stream? Why the mode matters¶

AES is a block cipher: it encrypts a 16-byte block at a time. Encrypting data longer than one block needs a mode of operation, and the choice of mode decides security:

• ECB — encrypts every block independently; leaks patterns (Demo 3). Don't use it.
• CBC — each block is chained to the previous one; needs a random IV, doesn't provide integrity on its own, and is vulnerable to padding oracles.
• CTR — turns the block cipher into a stream cipher (keystream ⊕ data); very sensitive to nonce reuse (Demo 2).
• GCM — CTR + a Galois MAC; AEAD. The modern default.

ChaCha20 is already a stream cipher (no block concept); combined with the Poly1305 MAC it becomes an AEAD. Same result: confidentiality + integrity in a single package.

2.4 Hash, MAC, and signature: which one, when?¶

These three belong to the integrity family but prove different things; mixing them up is a common mistake:

• A hash is a fixed-size, one-way fingerprint computed from data, and it's keyless. It only shows whether the data has changed. But an attacker can change the data and recompute the hash too; so a hash alone is not proof of integrity. Hashes are building blocks for constructions like HMAC and HKDF, and are used for fingerprinting/comparison. Old MD5/SHA-1 are vulnerable to collisions; use SHA-256/SHA-3.
• A MAC (e.g., HMAC-SHA-256) requires a shared secret key. It says "someone who knows the key sent this message and it hasn't changed." Because both sides know the key, a MAC does not provide non-repudiation (you can't tell which side produced it). When comparing secrets against a MAC, use a constant-time comparison (CRYPTO_memcmp); plain memcmp leaks timing.
• A digital signature (e.g., Ed25519, RSA-PSS) works with a public/private key pair. Only the private-key holder can produce a signature, and anyone can verify it with the public key; hence it provides non-repudiation. Certificates and release signing (Week 10) rely on this.

Demo 1 — Encrypting and tamper-detecting a file with AES-256-GCM¶

The essence of encryption and decryption (the crypto calls come from the shared cen429_kripto.h header; OpenSSL EVP on Linux, BCrypt on Windows):

/* Şifrele: cik = [nonce][şifreli metin][etiket] */
kripto_rastgele(nonce, 12);                 /* her mesaja yeni nonce */
memcpy(cik, nonce, 12);
kripto_gcm_sifrele(anahtar, nonce, 12, NULL, 0,
                   duz, duz_boy, cik + 12, etiket);
memcpy(cik + 12 + duz_boy, etiket, 16);

/* Çöz: etiket doğrulanır; tutmazsa ok == 0 */
int ok = kripto_gcm_coz(anahtar, nonce, 12, NULL, 0,
                        sc, sc_boy, etiket, duz);
if (!ok) { /* REDDET: veri kurcalanmış ya da yanlış anahtar */ }

Run it (.\demo.ps1 on Windows):

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

Actual output captured on WSL (shortened):

ADIM 2 - Sifrele
Sifrelendi: cikti/gizli.txt -> cikti/gizli.enc
   (53 bayt sifreli metin + 12 nonce + 16 etiket)
Sifreli dosyanin ilk baytlari (nonce + sifreli metin):
   000000 74 15 41 da 38 0b 86 1e 92 2f 42 eb 1c ac 49 54
   000010 07 2b 38 e2 3a e4 cd bb fb 7f fb 1c e5 ec a5 36

ADIM 3 - Dogru sekilde coz (etiket tutar)
Cozuldu ve DOGRULANDI: ... -> cikti/cozulen.txt (53 bayt)
   IBAN: TR00 0000 0000 0000 0000 0000 00
   Bakiye: 12345

ADIM 4 - Saldiri: sifreli metnin 20. baytini degistir
DOGRULAMA BASARISIZ: etiket tutmadi, veri kurcalanmis ya da
yanlis anahtar. Cozme REDDEDILDI.   (cikis kodu 2)

ADIM 5 - Saldiri: yalniz ETIKETin son baytini degistir
DOGRULAMA BASARISIZ: ... Cozme REDDEDILDI.   (cikis kodu 2)

What happened, line by line:

• Step 2: A random 12-byte nonce was generated and written to the start of the file. The nonce is not secret (it sits in the clear in the file); it only needs to be unique.
• Step 3: Decrypted with the same key and nonce; the tag held, and the plaintext came back.
• Step 4: We flipped one byte of the ciphertext with an XOR. Because the GCM tag is computed over the whole ciphertext, even a single byte breaks the tag; decryption is rejected (exit code 2).
• Step 5: This time we touched only the tag, not the data; it was rejected again. The tag is a function of both the data and the key; an attacker cannot produce the right tag without the key.

3. Random numbers: the invisible foundation of cryptography¶

Everything we've discussed so far (key, IV, nonce, salt, session ID) rests on a single assumption: these values are unpredictable. The world's best encryption algorithm protects nothing if its key was generated with a predictable generator. The textbook devotes its entire Chapter 11 to this topic; here we'll work through the part of it that still applies today, step by step.

Three kinds of "random"¶

The rule is simple: every security-relevant random value comes from a CSPRNG. rand() and mt19937 "look random" in a statistical sense, but from a security standpoint they are completely predictable. Anyone who sees 624 consecutive outputs of a Mersenne Twister can compute every output that follows.

This unpredictability is the other side of the entropy idea we saw in Week 2: there we measured the disorder in a file's bytes to tell encrypted/packed content apart; here we need enough disorder feeding the generator to produce unpredictable output. If the generator's pool hasn't been seeded enough (as we'll see in Mistake 2 below), its output becomes predictable too.

Mistake 1: seeding with the time¶

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

If an attacker knows which day the key was generated, there are only 86,400 possible seeds for that day. A laptop tries all of them in seconds. rand()'s own internal state is also small; once the seed is known, the whole sequence is known.

Mistake 2: accidentally deleting entropy¶

The right way: the operating system's generator¶

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

int rastgele_bayt(void *tampon, size_t n)
{
    unsigned char *p = tampon;
    while (n > 0) {
        ssize_t r = getrandom(p, n, 0);    /* havuz hazır olana kadar bekler */
        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 rastgele_bayt(void *tampon, size_t n)
{
    NTSTATUS s = BCryptGenRandom(NULL, (PUCHAR)tampon, (ULONG)n,
                                 BCRYPT_USE_SYSTEM_PREFERRED_RNG);
    return BCRYPT_SUCCESS(s) ? 0 : -1;
}

#include <openssl/rand.h>
if (RAND_bytes(tampon, (int)n) != 1) { /* hata: ASLA devam etme */ }

Mistake 3: bias when reducing to a range (modulo bias)¶

Writing r % 6 to roll a die looks innocent. But if r is uniform over 0–255, since 256 doesn't divide evenly by 6, the values 0–3 come up 43 times each while 4–5 come up 42 times each. Irrelevant for a die; but when generating a random password or a one-time code, some characters coming up more often increases predictability. The correct method is rejection sampling (Recipe 11.11):

#include <stdint.h>

uint32_t aralikta_rastgele(uint32_t ust)
{
    uint32_t sinir = (uint32_t)(-ust) % ust;   /* 2^32 mod ust: bu kadar değer "fazla" */
    uint32_t r;
    do {
        rastgele_bayt(&r, sizeof r);
    } while (r < sinir);                        /* fazlalığı at, yeniden çek */
    return r % ust;
}

The idea: use the largest portion of the 2³² values that divides evenly by ust, and discard the remainder. That way every result comes from exactly the same number of inputs.

Where do we use random values? A checklist¶

4. Using crypto APIs correctly: AES-GCM step by step¶

In Demo 1 we encrypted a file with AES-256-GCM and caught tampering. The demo left the work to the helper functions inside code/common/cen429_kripto.h. In this section we open up the inside of those functions: we write AES-GCM step by step with OpenSSL's EVP interface and Windows's CNG (BCrypt) interface. The goal is to see where mistakes can be made while using a crypto library. The rule still holds: you don't write your own algorithm, but calling a ready-made algorithm correctly is also a skill.

AEAD's four inputs and two outputs¶

AAD (additional authenticated data) is information that isn't encrypted but that must be noticed if it's changed: a file header, a version number, a record ID. In the Week 1 password-vault example we made the derivation parameters AAD; if someone changes the iteration count, the tag won't hold.

Encrypting with OpenSSL EVP¶

#include <openssl/evp.h>

/* Başarıda şifreli metin uzunluğunu, hatada -1 döndürür. */
int aes_gcm_sifrele(const unsigned char anahtar[32], const unsigned char nonce[12],
                    const unsigned char *aad, int aad_n,
                    const unsigned char *acik, int n,
                    unsigned char *sifreli, unsigned char etiket[16])
{
    EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
    int yazilan, toplam = -1;
    if (ctx == NULL) return -1;

    if (EVP_EncryptInit_ex(ctx, EVP_aes_256_gcm(), NULL, NULL, NULL) != 1) goto son;   /* 1 */
    if (EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, 12, NULL) != 1) goto son;     /* 2 */
    if (EVP_EncryptInit_ex(ctx, NULL, NULL, anahtar, nonce) != 1) goto son;            /* 3 */
    if (aad_n > 0 && EVP_EncryptUpdate(ctx, NULL, &yazilan, aad, aad_n) != 1) goto son; /* 4 */
    if (EVP_EncryptUpdate(ctx, sifreli, &yazilan, acik, n) != 1) goto son;             /* 5 */
    toplam = yazilan;
    if (EVP_EncryptFinal_ex(ctx, sifreli + toplam, &yazilan) != 1) { toplam = -1; goto son; } /* 6 */
    toplam += yazilan;
    if (EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG, 16, etiket) != 1) toplam = -1; /* 7 */
son:
    EVP_CIPHER_CTX_free(ctx);     /* bağlamdaki anahtar malzemesini de temizler */
    return toplam;
}

The steps, in order:

1. Choose the algorithm; don't give the key and nonce yet.
2. Set the nonce length (12 bytes is recommended for GCM; it's also the default, but writing it explicitly is good practice).
3. Give the key and the nonce.
4. Give the AAD: the output buffer is NULL, because AAD isn't encrypted, only folded into the tag.
5. Encrypt the plaintext. For large data this step can be repeated in chunks.
6. Finish. Since GCM runs in a stream mode there's no padding; this call usually writes 0 bytes, but it must be called: the tag is computed here.
7. Retrieve the tag and store it together with the ciphertext.

Every call's return value is checked, and the context is freed at a single exit point (son:). In C, this goto pattern is the most readable way to avoid resource leaks.

Decrypting: don't touch the plaintext before the tag is verified¶

/* Başarıda açık metin uzunluğunu; etiket tutmazsa ya da hata olursa -1 döndürür. */
int aes_gcm_coz(const unsigned char anahtar[32], const unsigned char nonce[12],
                const unsigned char *aad, int aad_n,
                const unsigned char *sifreli, int n,
                const unsigned char etiket[16], unsigned char *acik)
{
    EVP_CIPHER_CTX *ctx = EVP_CIPHER_CTX_new();
    int yazilan, toplam = -1;
    if (ctx == NULL) return -1;

    if (EVP_DecryptInit_ex(ctx, EVP_aes_256_gcm(), NULL, NULL, NULL) != 1) goto son;
    if (EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, 12, NULL) != 1) goto son;
    if (EVP_DecryptInit_ex(ctx, NULL, NULL, anahtar, nonce) != 1) goto son;
    if (aad_n > 0 && EVP_DecryptUpdate(ctx, NULL, &yazilan, aad, aad_n) != 1) goto son;
    if (EVP_DecryptUpdate(ctx, acik, &yazilan, sifreli, n) != 1) goto son;
    toplam = yazilan;
    /* Beklenen etiketi Final'dan ÖNCE ver */
    if (EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_TAG, 16, (void *)etiket) != 1) { toplam = -1; goto son; }
    if (EVP_DecryptFinal_ex(ctx, acik + toplam, &yazilan) != 1) {
        OPENSSL_cleanse(acik, (size_t)n);     /* etiket tutmadı: yarı çözülmüş veriyi sil */
        toplam = -1;
        goto son;
    }
    toplam += yazilan;
son:
    EVP_CIPHER_CTX_free(ctx);
    return toplam;
}

The same job with Windows CNG¶

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

int aes_gcm_sifrele_cng(const UCHAR anahtar[32], const UCHAR nonce[12],
                        UCHAR *aad, ULONG aad_n, const UCHAR *acik, ULONG n,
                        UCHAR *sifreli, UCHAR etiket[16])
{
    BCRYPT_ALG_HANDLE alg = NULL;
    BCRYPT_KEY_HANDLE key = NULL;
    BCRYPT_AUTHENTICATED_CIPHER_MODE_INFO bilgi;
    ULONG yazilan = 0;
    int sonuc = -1;

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

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

    if (BCRYPT_SUCCESS(BCryptEncrypt(key, (PUCHAR)acik, n, &bilgi, NULL, 0,
                                     sifreli, n, &yazilan, 0)))
        sonuc = (int)yazilan;
son:
    if (key) BCryptDestroyKey(key);
    if (alg) BCryptCloseAlgorithmProvider(alg, 0);
    return sonuc;
}

/* Aynı hazırlık; bilgi.pbTag beklenen etiketi gösterir. */
NTSTATUS s = BCryptDecrypt(key, (PUCHAR)sifreli, n, &bilgi, NULL, 0,
                           acik, n, &yazilan, 0);
if (s == STATUS_AUTH_TAG_MISMATCH) {      /* 0xC000A002: kurcalama */
    SecureZeroMemory(acik, n);
    return -1;
}

Even though the two interfaces look different, the steps are the same: choosing the algorithm and mode, the key object, nonce + AAD + tag, a single call for the operation, and freeing resources. One advantage of CNG is that it reports a tag mismatch with its own separate status code.

Constant-time comparison¶

If you ever need to compare a tag or a MAC by hand (e.g., in a message signed with HMAC), don't use memcmp. memcmp stops at the first differing byte; the comparison's duration leaks how many bytes were correct. An attacker can guess the tag byte by byte by measuring the timing (a timing attack).

int sabit_zamanli_esit(const unsigned char *a, const unsigned char *b, size_t n)
{
    unsigned char fark = 0;
    for (size_t i = 0; i < n; i++)
        fark |= a[i] ^ b[i];         /* her baytı mutlaka dolaş */
    return fark == 0;
}

Ready-made equivalents: OpenSSL's CRYPTO_memcmp, the Linux kernel's crypto_memneq, libsodium's sodium_memcmp.

Checklist for using a crypto library¶

• Every call's return value is checked; the operation stops on failure.
• The nonce is new for every encryption (random or a persistent counter).
• The tag is verified before the plaintext is used; on failure the plaintext is wiped.
• Tag and MAC comparisons are constant-time.
• Key buffers are wiped once the job is done; context objects are freed.
• Error messages don't give an attacker detail: if "tag error" and "padding error" are separate messages, that difference can be used as an oracle (this is exactly how CBC padding-oracle attacks were born).
• No outdated algorithms: DES/3DES, RC4, MD5, SHA-1 (for signing), ECB.

5. IV/nonce and salt: reusing the same key¶

These three concepts are constantly mixed up. All three are not secret, but security depends on using them correctly (textbook Recipe 4.9):

5.1 Why is nonce reuse a disaster?¶

GCM and CTR produce a keystream from the key and the nonce and XOR it with the plaintext: C = P ⊕ KS(key, nonce). If two messages are encrypted with the same key and the same nonce, the same keystream is used for both:

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

The keystream cancels out; the attacker obtains the XOR of the two plaintexts. If they know (or guess) one message, they fully decrypt the other.

Demo 2 — Nonce reuse leaking the XOR of two plaintexts¶

Duz metin 1: "Saldiri safagi 06:00'da baslasin!!"
Duz metin 2: "Toplam bakiye 45000 TL, sifre 1234"
==============================================================
KOTU DURUM - iki mesajda da AYNI nonce:
  C1 xor C2 = 070e1c08081f4942120a0f18024914050 ... 5c1215
  P1 xor P2 = 070e1c08081f4942120a0f18024914050 ... 5c1215
  ==> C1 xor C2 == P1 xor P2 : anahtar akisi SIZDI!
  Saldirgan P1'i biliyorsa P2 = (C1 xor C2) xor P1 =
     "Toplam bakiye 45000 TL, sifre 1234"
==============================================================
IYI DURUM - her mesaja FARKLI nonce:
  C1 xor C2 = 21158fbd64978ae63835b80d1f98c02d2 ... 8385c5af
  P1 xor P2 = 070e1c08081f4942120a0f18024914050 ... 5c1215
  ==> C1 xor C2 != P1 xor P2 : sizinti YOK.

In the bad case, C1 ⊕ C2 and P1 ⊕ P2 come out byte-for-byte identical: the keystream cancelled out. The program also showed that an attacker who knows one message fully recovers the other via (C1 ⊕ C2) ⊕ P1. With different nonces, the relationship disappeared.

5.2 ECB leaks patterns¶

ECB (Electronic Codebook), a mode that uses no nonce/IV, encrypts every 16-byte block independently. The same plaintext block always produces the same ciphertext block; so repeating patterns in the data show up in the ciphertext too.

Demo 3 — The ECB "penguin": pattern leakage¶

Orijinal resim (duz metin):
  ################################
  #  ##    ####    ####    ##    #
  ...  (429 rakamlari)  ...
  ################################
==============================================================
AES-128-ECB ile sifreli (her blok ilk baytina gore):
  ================================
  =##==####====####====####==####=
  ...  ayni sekil hala GORUNUYOR ...
  ================================
  ==> Sekil hala GORUNUYOR: ECB deseni sizdirir.
==============================================================
AES-256-GCM (CTR tabanli) ile sifreli, ayni resim:
  : -..--+%%*-:**% . #*#+*.:+* :..
  *.#*##:*%+###:#-*%==*#-+=%:.=***
  ...  desen kayboldu, gurultu ...
  ==> Desen kayboldu: GCM/CTR her blogu farkli sifreler.

The ECB output only has two characters (a background block → one ciphertext block, a shape block → another ciphertext block); the shape is still exactly readable. This is the ASCII version of the famous "ECB penguin" example. In GCM, since every block is encrypted with a different, position-dependent keystream, the output is noise.

6. Key derivation from a password¶

A password can't be a key directly: it's short, has low entropy, and is predictable. A password-based key derivation function (KDF) does two things:

1. Salt: A random salt is added per user/record. The same password gives a different key with a different salt; this way precomputed (rainbow) tables don't work, and it's not obvious when two users share a password.
2. Slowness (cost): The KDF deliberately runs hundreds of thousands of rounds; trying one password becomes expensive, which slows down brute force.

Demo 4 — Round count, timing, and the importance of salt¶

1) TUZUN ONEMI (tur = 100000)
   tuz A -> anahtar = e1d9214abdcfa793...cad33a816
   tuz A -> anahtar = e1d9214abdcfa793...cad33a816   (ayni)
   tuz B -> anahtar = 89cc5979affa2a62...972e020e   (farkli)
==============================================================
2) TUR SAYISI vs SURE (ayni parola, ayni tuz)
   tur =     1000  ->      0.37 ms
   tur =    10000  ->      3.82 ms
   tur =   100000  ->     39.05 ms
   tur =   600000  ->    209.55 ms
   tur =  2000000  ->    628.42 ms
==============================================================
3) Argon2id ile karsilastirma (argon2 araci varsa)
   $argon2id$v=19$m=65536,t=3,p=1$...   0.112 seconds

• Salt: The same password + the same salt gave the same key every time (which is why, if the salt were fixed, an attacker could build one table and search everyone). The same password + a different salt gave a completely different key.
• Cost: As the round count went from 1,000 to 2,000,000, the time went from ~0.4 ms to ~628 ms. This is a direct multiplier: every attempt an attacker makes gets just as much more expensive. "200 ms at user login" is acceptable; for an attacker it means thousands of attempts per second instead of billions.
• Argon2id: It additionally requires memory (64 MiB here); this makes parallel brute force with a GPU/ASIC much harder than with PBKDF2.

7. Deriving keys from a master secret, session keys, and forward secrecy¶

A long-lived "master secret" is never used directly. Separate keys are derived from it for every purpose and every session. The tool: HKDF (RFC 5869), a two-stage KDF:

• Extract: master secret + salt → a uniform intermediate key (PRK).
• Expand: PRK + an "info" label → a key of the desired length. A different info → a different key.

7.1 Forward secrecy¶

If we derive keys as a one-way chain — K0 = master secret, Kᵢ = HKDF(Kᵢ₋₁) — and delete Kᵢ₋₁ after each session, then even if an attacker obtains today's Kₙ, they cannot compute the old K1..Kₙ₋₁ (and those sessions' data) backward. TLS 1.3 provides this guarantee with an ephemeral Diffie-Hellman for every session (textbook Recipes 8.20–8.21).

Demo 5 — Session keys and a forward-secrecy chain with HKDF¶

Tek ana sirdan amaca gore ayri anahtarlar:
  info='...sifreleme...' -> 2b8b46840fa2d1b1...0e577a55
  info='...MAC...'       -> 30a302d19ec9ab8e...c55dfa84
  ^ Ayni sir, farkli info -> farkli anahtar.
==============================================================
ILERI GIZLILIK zinciri: Ki = HKDF(Ki-1), Ki-1 silinir
  K1 (oturum 1) = 0630f63f015d003e
  K2 (oturum 2) = def84847df4d9461
  K3 (oturum 3) = 54b13f0ff3a486ca
  K4 (oturum 4) = 55524a8f5c09652f
  ^ Elimizde yalniz K4 var; zincir tek yonlu oldugu icin
    K4'ten K3, K2, K1 geri hesaplanamaz.

Different info labels from the same master secret produced different keys; a key generated for one purpose can't be used for another. In the forward-secrecy chain, the old key was wiped at every step with kripto_temizle (OPENSSL_cleanse/SecureZeroMemory); only the last key remained, and one-wayness preserved the history.

8. Dynamic key management: lifecycle, hierarchy, and renewal¶

Only a very small fraction of incidents reported as "the algorithm was broken" are actually algorithm breaks. The overwhelming majority are key management mistakes: a key embedded in the source code, a key that never changes, a single key run for every job, an old key that's never deleted. The textbook covers securely managing key material briefly in Recipe 4.13; in this section we expand the topic to how it's actually handled in the field.

The life of a key¶

NIST SP 800-57 defines a key's lifecycle in terms of states. In simple form:

The crypto-period is the length of time a key is allowed to be used. Once it expires, the key is no longer used to encrypt new data, but it may be kept a while longer to decrypt old data. What determines the crypto-period: how much data the key protects, how long that data needs to stay confidential, and how exposed the key is. A key sitting on a client device should have a much shorter lifetime than one sitting in an HSM.

Key hierarchy: a separate key for every job¶

Instead of doing everything with a single key, keys are organised into a tree. Keys near the top are used rarely and sit in the best-protected place; keys near the bottom are used often, are short-lived, and cause little damage if lost.

Two core ideas:

1. Key separation: different keys for different purposes. An encryption key is never used for signing, a MAC key never for encryption. HKDF's info label makes this separation easy (previous section).
2. Bounding the damage: compromise of a lower-level key affects only that branch. If a single-use payment key is stolen, the loss is a single transaction.

Envelope encryption¶

Encrypting a large amount of data directly with the master key creates two problems: the master key gets used often (increasing its exposure time), and when the key changes all the data must be re-encrypted. Envelope encryption solves both:

1. A random data encryption key (DEK) is generated for every file or record; the data is encrypted with it.
2. The DEK is wrapped (encrypted) with a key encryption key (KEK) and written into the header of the encrypted data.
3. The KEK sits in a secure place: the operating system's key store, a TPM, an HSM, or a cloud key management service.
4. When the KEK is rotated, only the small wrapped DEKs need to be re-wrapped.

Cloud providers' key management services (KMS) and disk-encryption systems use this method.

Key version: the small field that makes renewal possible¶

To be able to rotate a key, you need to know which key encrypted a given piece of encrypted data. That's why a key ID / version field is placed in the header of the encrypted data:

The reader looks at the version first, finds that version's key, and decrypts. New writes always use the newest key; old records get re-encrypted with the new key as they're read (or in the background). Because the header is AAD, an attacker can't change the version field to redirect the app toward an old, weak key.

Where should a key be stored?¶

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

int anahtari_sar(const BYTE *anahtar, DWORD n, DATA_BLOB *cikti)
{
    DATA_BLOB giris = { n, (BYTE *)anahtar };
    /* cikti->pbData, iş bitince LocalFree ile serbest bırakılır */
    return CryptProtectData(&giris, L"kasa-anahtari", NULL, NULL, NULL,
                            CRYPTPROTECT_UI_FORBIDDEN, cikti) ? 0 : -1;
}

From the field: card scheme requirements and a key inventory¶

The card-scheme security requirements that mobile payment apps must meet ask, point by point, for exactly what this section describes. A summary of two schemes' (here Scheme-A and Scheme-B) crypto and key requirements:

The guide for a library that meets these requirements splits keys into four groups:

The same guide also makes two important negative statements: the library does not generate keys for account parameters, and it does not generate random numbers on the client for payment. For an evaluator, saying "we don't do this" is just as valuable as saying "we do this" — it narrows the attack surface.

Session keys: an example from the field and a critical read¶

When a second protection layer is built on top of TLS between client and server, that layer's keys are derived per session. The outline of a design from the field (names generalized):

1. The server generates a 32-byte session ID, encrypts it with a configuration key specific to the client, and sends it over a push-notification channel (or in response to the client's request for a new session).
2. The client decrypts the session ID with the protected key (whitebox AES, Week 11).
3. Authentication code: part of the decrypted session ID, the wallet ID, and the device fingerprint are run together through SHA-256. The server computes the same value itself; both sides thereby confirm the other is genuine.
4. Session key: a digest of the configuration key is used as a master key; a 16-byte AES session key is derived from that digest via HMAC, together with the decrypted session ID.
5. Messages are encrypted with this key in AES-CTR mode, and a 256-bit MAC is additionally attached to every message; the receiver doesn't use a message without verifying the MAC.

This design is a good example of defence in depth: even if TLS is broken, messages are separately encrypted and integrity-protected; the session key changes every session; the authentication code is device-bound. If the same design were built today, the following improvements would be recommended:

9. Data in transit: TLS 1.3, certificate validation, and pinning¶

TLS (Transport Layer Security) is the protocol that combines key agreement, AEAD encryption, and certificate validation to provide secure communication over the network — the layer under HTTPS (formerly called SSL). It's the standard that protects data in transit. Today TLS 1.3 is used; SSLv2/SSLv3 and TLS 1.0/1.1 are considered broken and have been retired (attacks like POODLE, BEAST).

9.1 The TLS 1.3 handshake¶

TLS 1.3's two key features: (1) the handshake finishes in a single round trip (fast); (2) the key exchange is always done with ephemeral ECDHE, meaning forward secrecy is on by default (RFC 8446).

9.2 The three layers of validation — and the most dangerous trap¶

A TLS connection means nothing if it doesn't validate the certificate the other party presents. Validation consists of three questions:

Chain validation works like this: the server presents a leaf certificate; that certificate was signed by an intermediate CA, which was in turn signed by a trusted root CA. The client validates the signatures upward until it reaches its list of trusted roots (the trust store); it also checks every certificate's expiration and revocation status (CRL/OCSP). In Demo 6 we build this root of trust with a small CA we generate ourselves: the "real" server certificate is signed by this CA, while the "attacker" certificate is self-signed (not in the root list), so chain validation rejects it. We'll cover PKI, certificate chains, CRL, and OCSP in detail in Week 10.

9.3 Pinning and TOFU¶

• Certificate pinning: The client embeds the SHA-256 digest of the server's expected public key (SPKI). Even if the chain is valid (e.g., an attacker obtained a fake but "valid" certificate), the connection is rejected if the key doesn't match. Common in mobile apps (OWASP MASVS-NETWORK). The textbook's Recipe 10.9 calls this "whitelist validation."
• TOFU (Trust On First Use): without a PKI, the key from the first connection is remembered; if it changes on a later connection, a warning is raised. This is what SSH does (textbook Recipe 8.19). It's not as strong as a PKI, but it makes interception harder after the first connection.

9.4 What changed from TLS 1.2 to 1.3?¶

TLS 1.3 isn't just a version bump; it's a clean simplification. Older versions had dozens of "cipher suites," many of them weak; misconfiguration was a common vulnerability. TLS 1.3 cleaned this up thoroughly:

Demo 6 — A non-validating client → localhost MITM → hostname + SPKI pinning¶

The essence of the client:

SSL_CTX_set_min_proto_version(ctx, TLS1_2_VERSION);   /* en az TLS 1.2 */
if (dogrula) {
    SSL_CTX_load_verify_locations(ctx, ca_pem, NULL);  /* güvenilen CA */
    SSL_CTX_set_verify(ctx, SSL_VERIFY_PEER, NULL);
    SSL_set1_host(ssl, host);                           /* ana makine adı! */
}
/* pin modunda: sunucu ACIK ANAHTARININ (SPKI) SHA-256'si eslesmeli */
i2d_X509_PUBKEY(X509_get_X509_PUBKEY(cert), &der);
EVP_Digest(der, len, ozet, NULL, EVP_sha256(), NULL);
if (memcmp(ozet, beklenen_pin, 32) != 0) { /* REDDET */ }

Gercek sunucu SPKI pini (SHA-256): 1dabd67747366675...ac36b3f7c
==============================================================
SENARYO 1 - Guvensiz istemci SALDIRGAN sunucuya:
[guvensiz] Dogrulama YOK - ne gelirse KABUL (TEHLIKELI).
   ^ Sahte sertifika kabul edildi. MITM basarili olurdu.
SENARYO 2 - Dogrulayan istemci GERCEK sunucuya:
[dogrula] Zincir + hostname DOGRULANDI - KABUL.
SENARYO 3 - Dogrulayan istemci SALDIRGAN sunucuya:
[dogrula] EL SIKISMA BASARISIZ - baglanti REDDEDILDI.
   Sebep: (18: self signed certificate)
SENARYO 4 - Pinleyen istemci GERCEK sunucuya, DOGRU pin:
[pin] SPKI pin TUTTU - baglanti KABUL.
SENARYO 5 - Pinleyen istemci SALDIRGAN sunucuya, GERCEK pin ile:
[pin] SPKI pin TUTMADI - baglanti REDDEDILDI.
   ^ Anahtar tutmadi: pinning MITM'i durdurdu.

The five scenarios tell a single story: an unvalidating client accepts the attacker's fake certificate without question (MITM would have succeeded). Chain + hostname validation rejects the attacker's self-signed certificate. SPKI pinning, meanwhile, cuts the connection even if the attacker manages to obtain a chain-wise "valid" certificate, because the expected key doesn't match.

10. Wiring up TLS correctly in code: a step-by-step client, pinning, and common mistakes¶

The previous section showed what TLS 1.3 does, and how Demo 6's non-validating client was fooled. In this section we cover wiring up a TLS client correctly, line by line, applying pinning in a way that's sustainable in the field, and the most common mistakes seen in real applications. The textbook covers this topic in Recipe 9.1 (an SSL client), 10.7 (validating the peer's certificate), 10.8 (hostname checking), and 10.9 (whitelist validation); the code below is these recipes updated to OpenSSL 1.1.⅓.x.

A correct client with OpenSSL: seven steps¶

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

/* Başarıda okunup yazılabilen bir BIO döndürür; iş bitince BIO_free_all + SSL_CTX_free. */
BIO *tls_baglan(SSL_CTX **ctx_cikti, const char *ana_makine, 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 hata;       /* 4 */

    if ((bio = BIO_new_ssl_connect(ctx)) == NULL) goto hata;
    BIO_get_ssl(bio, &ssl);
    SSL_set_tlsext_host_name(ssl, ana_makine);                       /* 5: SNI */
    if (SSL_set1_host(ssl, ana_makine) != 1) goto hata;              /* 6: ad denetimi */
    BIO_set_conn_hostname(bio, ana_makine);
    BIO_set_conn_port(bio, port);

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

    *ctx_cikti = ctx;
    return bio;
hata:
    ERR_print_errors_fp(stderr);
    BIO_free_all(bio);
    SSL_CTX_free(ctx);
    return NULL;
}

Adding pinning: the SPKI digest¶

Once validation succeeds, the digest of the server's public key is compared against a list embedded in the app. Pinning the public-key info (SPKI) instead of the certificate itself lets the app keep working when the certificate is renewed with the same key.

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

static const unsigned char PINLER[][32] = {
    { /* birincil anahtarın SPKI SHA-256 özeti (32 bayt) */ },
    { /* YEDEK anahtarın özeti: çevrimdışı üretilmiş, henüz kullanılmayan */ },
};

int pin_denetle(SSL *ssl)
{
    X509 *sert = SSL_get_peer_certificate(ssl);    /* 3.x: SSL_get1_peer_certificate */
    if (!sert) return 0;
    X509_PUBKEY *pk = X509_get_X509_PUBKEY(sert);
    int n = i2d_X509_PUBKEY(pk, NULL);
    unsigned char *der = OPENSSL_malloc((size_t)n), *p = der;
    i2d_X509_PUBKEY(pk, &p);                        /* p ilerler; der başta kalır */
    unsigned char ozet[32];
    SHA256(der, (size_t)n, ozet);
    OPENSSL_free(der);
    X509_free(sert);

    for (size_t i = 0; i < sizeof PINLER / sizeof PINLER[0]; i++)
        if (CRYPTO_memcmp(ozet, PINLER[i], 32) == 0)
            return 1;
    return 0;                                       /* tutmadı: bağlantıyı KES */
}

Computing a server's SPKI digest from the command line:

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

Keeping pinning sustainable in the field¶

Pinning is a strong but fragile control: when the server's key changes, every app on the old version becomes unable to connect. That's why browsers dropped dynamic HTTP-based pinning (HPKP) in 2018; pinning is still common in mobile and desktop apps, though (OWASP MASVS-NETWORK). For sustainable pinning:

TLS on Windows: WinHTTP and Schannel¶

Windows's built-in TLS stack is Schannel; apps mostly use it through WinHTTP or WinINet (the current counterpart of the WinInet the textbook covers in Recipe 9.4). Unlike OpenSSL, WinHTTP validates the certificate and the hostname by default. The danger lies in the flags that turn this validation off:

DWORD bayraklar = SECURITY_FLAG_IGNORE_UNKNOWN_CA |
                  SECURITY_FLAG_IGNORE_CERT_CN_INVALID |
                  SECURITY_FLAG_IGNORE_CERT_DATE_INVALID;
WinHttpSetOption(istek, WINHTTP_OPTION_SECURITY_FLAGS, &bayraklar, sizeof bayraklar);

This line is usually added during development to connect to a self-signed test server, and then forgotten. The correct approach is to add the test server's CA to the development machine's trust store; the code stays the same. For pinning in WinHTTP, after the request is sent, the server certificate is retrieved with WinHttpQueryOption(..., WINHTTP_OPTION_SERVER_CERT_CONTEXT, ...) and the public-key digest is compared as above.

Critical reading: the door that opens silently (fail-open)¶

Below is a simplified, rewritten version of a pinning implementation used in the field. At first glance the code looks correct: it validates the chain first, then compares the server's public key against the key stored in the app. Can you spot the bug?

public void checkServerTrusted(X509Certificate[] zincir, String tur) throws CertificateException {
    varsayilanDogrulayici.checkServerTrusted(zincir, tur);          // 1. zincir doğrulaması
    try {
        PublicKey beklenen = depo.getCertificate("ca").getPublicKey();
        if (!Arrays.equals(beklenen.getEncoded(), zincir[0].getPublicKey().getEncoded()))
            throw new CertificateException("pin tutmadi");           // 2. sabitleme
    } catch (KeyStoreException e) {
        e.printStackTrace();                                         // 3. ???
    }
}

Line 3: if reading from the key store fails, it prints the error and returns from the method normally. Because the method returns without throwing an exception, the connection is accepted: pinning effectively never happened. When a security check falls back to a "pass" result on error, it's called fail-open. Other notable points stood out in the same codebase:

• When chain validation failed, a second validation was performed against a store embedded in the app, and in that second validation, revocation checking was turned off.
• If the certificate file, or its integrity marker, couldn't be found, only a log line was written and the connection was allowed to proceed.
• There was a single pin; there was no backup pin.

The correct design is fail-closed: if you can't determine a security check's outcome, the outcome is "reject."

    } catch (KeyStoreException | RuntimeException e) {
        throw new CertificateException("pin denetimi yapilamadi", e);   // belirsizlik = ret
    }

The most common TLS mistakes in real applications¶

Testing your own connection¶

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

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

11. Data at rest: file and database encryption¶

A file or database on disk can be stolen (a lost phone, a stolen backup, a compromised server). There are two levels for protecting data at rest:

• Whole-disk/file encryption: at the OS level (LUKS, BitLocker, XTS-AES) or at the app level, encrypting the whole file with AEAD (see Demo 1). The textbook covers disk encryption in Recipe 5.15; it warns about the fixed-IV trap.
• Field/column encryption: encrypting only the sensitive fields (card number, national ID, health data) at the application layer and writing them encrypted into the database. Even if the database is stolen, those fields can't be read.

Data masking is a separate technique: showing data in an irreversible or partial form. It's not encryption (it can't be reopened with a key); its purpose is reducing data's unnecessary exposure. Its main forms:

• Partial masking: showing only part of a value, e.g., card number **** **** **** 4242, email a***@ornek.com. Used in the UI and on customer-service screens.
• Logging masks: a sensitive field is never written to logs, or is written masked. (The data-side counterpart of the "logging a secret" mistake we saw in Week 1.)
• Tokenization: replacing the real value with a meaningless "token," keeping the real value in a separate, secure vault. In payment systems a token travels in place of the card number; the actual number is decrypted from the vault only when needed.
• Test-data masking: replacing real personal data with fake but realistic values when copying production data into a test/development environment.

Masking does not replace encryption; it complements it. The data sits encrypted on disk with AEAD (confidentiality), and it's masked on its way to a screen/log (reducing exposure). The two counter different threats: one counters a file being stolen, the other counters "the wrong person seeing it on a screen/in a log."

Demo 7 — Encrypting a sensitive field in SQLite with AES-GCM¶

ADIM 1 - Veritabanini kur (hassas alan sifreli)
Veritabani kuruldu: cikti/musteri.db (2 kayit)
ADIM 2 - Saldirgan DB dosyasini caldi ve sqlite3 ile aciyor:
  1|Ayse Yilmaz|D1ED7A3624E0F7C6...A64B373F...  (sifreli)
  2|Mehmet Kaya|C362F7A33BDEE736...F924DF9F...  (sifreli)
   ^ Kart alani yalniz sifreli bayt yigini; anahtar yok.
ADIM 3 - Dogru anahtarla uygulama okuyor (coz ve dogrula):
   1 | Ayse Yilmaz   | 4242-4242-4242-4242
   2 | Mehmet Kaya   | 5555-4444-3333-2222
ADIM 4 - YANLIS anahtarla okuma (GCM etiketi tutmaz):
   1 | Ayse Yilmaz   | (COZULEMEDI - anahtar yanlis?)

Even if the attacker opens the DB with sqlite3, they see the ad field, but the kart_sifreli field is nothing but encrypted bytes. The app opens and verifies it correctly with the right key; with the wrong key the GCM tag doesn't hold, so decryption is rejected (it never silently returns garbage). The Windows demo (.\demo.ps1) makes the same point by searching the raw DB file instead of using the sqlite3 tool: Ayse (the plain name) is found, but 4242-4242 (the card) is not found, because it's encrypted.

12. Data masking techniques: using data without showing it¶

Encryption hides data from anyone without the key. But in many cases, even systems and people who do have the key don't need to see all of it: a call-centre employee should see the last four digits of a customer's card number, not the whole thing; a test-environment database shouldn't contain real people's national ID numbers; a log file should never see a password at all. Data masking is a family of techniques that shows only as much of the data as its purpose requires and hides the rest. Personal-data-protection regulation (KVKK, GDPR) and the payment-card standard (PCI DSS) explicitly require these techniques.

Four basic techniques¶

The difference matters legally too: pseudonymized data is still personal data (whoever holds the key can find the person); truly anonymized data, on the other hand, is not considered personal data. Many "anonymous" data sets have been shown to be re-linkable to individuals when combined with other data. So saying "we anonymized it" is a much stronger claim than saying "we pseudonymized it."

1. Masking at display¶

The PCI DSS rule for card numbers (PAN) is clear: when a number is displayed, at most the first six (or, in newer versions of the standard, eight, depending on card type) and the last four digits may be shown; roles that need to see the full number for their job are separately defined.

#include <string.h>

/* "1234567812345678" -> "************5678"; çıktı tamponu en az n+1 bayt */
void pan_maskele(const char *pan, char *cikti, size_t cikti_boyut)
{
    size_t n = strnlen(pan, 19);
    if (cikti_boyut < n + 1) { if (cikti_boyut) cikti[0] = '\0'; return; }
    for (size_t i = 0; i < n; i++)
        cikti[i] = (i + 4 < n) ? '*' : pan[i];
    cikti[n] = '\0';
}

Masking should be done close to the source: if the full value is sent from the server to the client and masked on screen, anyone inspecting the network traffic or the client's memory sees the full value. The correct approach is to send the client an already-masked value.

2. Tokenization¶

The power of tokenization is that the real data is concentrated in a single small, very well protected system. The rest of the application, the databases, reports, and logs see only the token; even if these are compromised, the card data doesn't leak. This is the technical counterpart of Week 1's "transfer the threat" response: never storing card data at all and using the payment provider's tokenization service dramatically shrinks the app's PCI DSS scope. In mobile payments, the card information downloaded to the phone also isn't the real card number, but a device-specific token number.

The token's format can be preserved: a meaningless but still 16-digit number in place of a 16-digit card number. This lets legacy systems (field length, validation rules) keep working unchanged. Format-preserving encryption (the FF1 algorithm in NIST SP 800-38G) does the same job without a key and a vault.

3. Pseudonymization: a keyed digest¶

For analysis or testing you often need to "bring together the same person's records without knowing who they are." Running the ID number through a plain digest (SHA-256) isn't enough: an 11-digit ID number has a small number of possible values, and an attacker can compute and compare the digest of all of them. The correct approach is to use HMAC with a secret key:

/* code/common/cen429_kripto.h */
unsigned char takma_ad[32];
kripto_hmac_sha256(takma_anahtari, 32, kimlik_no, strlen(kimlik_no), takma_ad);
/* Veri kümesinde kimlik_no yerine hex(takma_ad)'ın ilk 16 baytı saklanır */

The key is kept separate from the data set. For someone without the key, going from the pseudonym back to the ID number means trying every possible ID number, which is infeasible without knowing the key. If the key is lost or destroyed, the data becomes effectively anonymous.

4. Test and development data¶

Copying real production data into a test environment is one of the most common causes of data leaks: test environments are less protected and accessed by more people. In order of preference for test data:

1. Fully synthetic data: data generated from scratch, never derived from real records. The safest. Every example in this course follows this path: the card numbers, keys, and IDs are synthetic.
2. Static masking: a copy of the production data is taken, the sensitive fields in the copy are permanently altered (pseudonym, shuffling, generalization), and only then is it moved into the test environment.
3. Dynamic masking: the data itself isn't changed; the database returns query results masked according to the user's role. Convenient, but the data still sits in the database in full.

5. Masking in logs and error messages¶

In Week 2 we saw the audit log's "never log" list: password, PIN, token, key, full card number. A rule is one thing; guaranteeing it is another. Two approaches are used together:

• Prevention at the source: sensitive values are kept in a special type, and that type's print function always produces masked output. Even if a programmer accidentally logs it, the full value never comes out.
• Filtering at the output: as a final step in the logging library, card-number-like sequences (13–19 digits, passing the Luhn check) and values that follow keys like parola=, token= are automatically masked.

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

void gunluk_suz(char *satir)
{
    static const char *anahtarlar[] = { "parola=", "pin=", "token=" };
    for (size_t k = 0; k < sizeof anahtarlar / sizeof anahtarlar[0]; k++) {
        char *p = satir;
        while ((p = strstr(p, anahtarlar[k])) != NULL) {
            p += strlen(anahtarlar[k]);
            while (*p && !isspace((unsigned char)*p))
                *p++ = '*';                    /* değeri yerinde maskele */
        }
    }
}

Which technique, when?¶

13. Data in use: secure erasure in memory and device binding¶

A secret eventually gets opened up in memory in order to be used. At that moment it's at risk: a memory dump, a debugger, swap space, other code that later reuses the same memory. In Week 1, §17 we saw "dead-store elimination" with explicit_bzero and wiping a secret from memory (Recipe 13.2), plus preventing memory from being written to disk (Recipe 13.3); this week we build the additional layers — blocking dumps, memory locking, and device binding — for data in use.

Demo 8 — mlock + secure erasure¶

Katman 1 - cokme dokumu kapatildi (RLIMIT_CORE=0): TAMAM
Katman 2 - mlock ile takasa (swap) yazma engellendi: TAMAM
Sir kullaniliyor: uzunluk = 20, dolu bayt = 20
Katman 3 - guvenli silme sonrasi dolu bayt = 0
   ==> sir bellekten temizlendi.
--------------------------------------------------------------
OPENSSL_cleanse cagrisi sayisi -> 2

On Windows (.\demo.ps1) the same three layers are set up with SetErrorMode + VirtualLock + SecureZeroMemory; the output is also "TAMAM" (OK). Unlike memset, a call to OPENSSL_cleanse/ SecureZeroMemory cannot be removed by the compiler as a "dead store" — it stays a real call in the machine code (the demo counts this with objdump).

13.1 Device binding¶

Part of protecting data in use is binding the key to a specific device/version. If we wrap the key with a value derived from the device's fingerprint (manufacturer, model, device ID, version string), the files can't be opened even if they're copied to another device. The correct approach: not XOR or an unsalted digest, but salted derivation with HKDF and wrapping with AEAD. This is exactly the innermost layer of the security shell in Section 14; we'll combine it with RASP in Week 6.

14. Security shells: defence in depth made concrete¶

Now we bring together every piece of this week into a single idea. We never leave a sensitive asset to a single protection; we wrap it in nested shells that correspond to every stage of its lifecycle:

To reach the secret, the attacker must open all four shells, in order: break TLS, break the message encryption, break the storage encryption, and be on the right device. This is the "don't rely on TLS alone in transit," "field encryption at rest," and "device binding in use" principles combined into a single table.

Demo 9 — Wrapping and unwrapping a key with four shells¶

SARMA (dis dunyaya dogru): sir -> K1 -> K2 -> K3 -> K4
  Kabuk 1 (cihaz baglama)     :  44 bayt
  Kabuk 4 (kanal/TLS benzeri) : 128 bayt  <- aktarilan paket
ACMA (ice dogru): K4 -> K3 -> K2 -> K1 -> sir
  Kabuk 4/3/2/1 acildi: TAMAM
  Cozulen SIR : deadbeef...ba98  -> sir DOGRU
==============================================================
SALDIRI 1 - Paketin bir biti kurcalanirsa (Kabuk 4):
  Kabuk 4 acildi: RED  (GCM etiketi tutmadi)
SALDIRI 2 - Paket BASKA cihaza kopyalanirsa (yanlis parmak izi):
  Dis 3 kabuk acildi: TAMAM
  Kabuk 1 (cihaz baglama) BASKA cihazda acildi: RED
  ^ Anahtarlar kopyalansa bile sir baska cihazda ACILAMAZ.

In the normal flow, the four shells opened in sequence and the secret came back correctly. When a single bit was tampered with, the outermost GCM tag held and was rejected at that layer. When the packet was moved to another device, the outer three shells (whose keys are portable) opened, but the device-bound innermost shell could not — the secret was never obtained. In real products this innermost shell is most often whitebox crypto (Week 11).

This shell approach is a bridge to the rest of the term: native code hardening and RASP (Weeks 4, 6, 9) protect the shells at runtime; crypto and key hierarchy (Week 10) correctly generate and manage the shells' keys; whitebox (Week 11) strengthens the innermost shell; certification (Weeks 12–13) demands proof of all these layers. In other words, this week's data-security section is the backbone of your security guide (S5, S7), and every week ahead makes one more shell concrete.

The shell matrix in the field: one asset, five stages¶

To keep the idea simple, Demo 9 built all four shells with AES-GCM. In a mobile payment library that passed an independent lab's certification, the shells were defined as follows (names generalized):

What's really instructive is the matrix showing which shells are present at every stage of the same asset's lifecycle:

How to read the matrix:

• Shells open one by one as the asset moves from outside toward the moment of use. But even at the innermost stage (the payment computation on the native side), one shell remains: the key is used in its whitebox form and never becomes exposed in the clear.
• The shells are four layers deep only for sensitive assets. Less sensitive ("normal") assets are protected by a single shell at rest and only the outer two shells in transit. Applying the strongest protection to every asset unnecessarily raises performance and maintenance cost; the C/I classification in the asset table is the basis for this decision.
• The exposure that remains in use (the moment of processing in memory) is protected not by the shells but by RASP and code hardening (Weeks 4, 6, and 9).
• The library keeps card profiles, limited-use keys, the remaining key count, card status, transaction records, and the device fingerprint in the local database (SQLite). When a record is deleted, or an attack is detected, all of these tables are wiped.

15. Introduction to whitebox cryptography (motivation)¶

The hidden assumption behind this entire week is: the key sits in the clear in memory the moment it's used. In the "the device's owner is the attacker" scenario (Week 1, white box), the attacker can read memory and attach a debugger; they can catch that moment and steal the key. Secure erasure and memory locking narrow this window but don't close it.

Whitebox cryptography is a radical answer to this problem: it embeds the algorithm (e.g., AES) into a set of tables such that, even while running, the raw key never appears in the clear in memory; the key is "baked" into the tables. This way, even if the attacker sees all of memory, they can't read the key directly. This is the real-world form of the innermost layer of the security shell from Section 14.

16. Common misunderstandings¶

17. Term project: this week¶

This week you will write the data security sections of your security guide. For the midterm submission:

• S5 — Asset list (draft): List every sensitive asset in your project in a table. For each asset: where it sits (file/DB/memory), when it's created/deleted, whether it needs confidentiality (C), integrity (I) (or I+), and by what mechanism it's protected.
• S7 — Data security + security shell matrix: For every asset, show the three states (in transit/at rest/in use) and which shell is wrapped around it in each state. Write down your secure-erasure policy.

| 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. Class activities¶

19. Code-reading exercises¶

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("Baglanti guvenli!\n");

EVP_DecryptUpdate(c, duz, &len, sc, sc_boy);
EVP_DecryptFinal_ex(c, duz + len, &len);   /* dönüş değeri okunmuyor */
kullan(duz);

unsigned char anahtar[32];
SHA256((unsigned char*)parola, strlen(parola), anahtar);

20. On your own¶

These exercises aren't graded; they're for reinforcement. All of them are done on your own computer, using the code/week-03 demos.

21. Self-check¶

22. Quiz-1-style sample questions¶

23. Resources and further reading¶

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

• Recipe 4.9 (salt/nonce/IV), 4.10 (key from a password — PBKDF2), 4.11 (key from a master secret), 4.13 (managing key material)
• Recipe 5.15 (file/disk encryption), 6.18 (encryption + integrity together)
• Recipe 8.19 (validation without a PKI / TOFU), 8.20–8.21 (forward secrecy)
• Recipe 9.1–9.3 (SSL client/server), 10.7–10.9 (certificate validation, hostname, whitelist = pinning)
• Recipe 13.2–13.3 (secure erasure from memory, preventing memory from being written to disk)
• Recipe 11.1–11.4 (types of random numbers, Unix and Windows infrastructure), 11.11 (unbiased random integer in a range)
• Recipe 9.4 (secure communication with WinInet on Windows — today's counterpart is WinHTTP/Schannel)

Open standards and resources

• NIST SP 800-57 Part 1 (key management, crypto-period), SP 800-90A (random bit generators), SP 800-38G (FF1, format-preserving encryption), SP 800-38C (CCM).
• PCI DSS v4.0 (masking card numbers at display, tokenization); pseudonymization and anonymization under KVKK and GDPR.
• M. Georgiev et al., "The Most Dangerous Code in the World: Validating SSL Certificates in Non-Browser Software," ACM CCS 2012.

• MITRE CWE: CWE-330 (insufficient randomness), CWE-338 (weak PRNG), CWE-208 (information leak via timing discrepancy), CWE-297 (missing hostname validation), CWE-636 (fail-open: not failing securely), CWE-359 (exposure of private personal information), CWE-532 (insertion of sensitive information into a log file).

• 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 (improper certificate validation), CWE-323 (reusing a nonce/IV), CWE-327 (use of a broken crypto algorithm), CWE-916 (use of a password hash with insufficient computational effort), CWE-311 (missing encryption of sensitive data).