Why This Section?

This week terms such as "encryption," "nonce," and "key derivation" will come up.

We assume you know none of them.

Let's first define them one by one.

The Three States of Data

• In transit: moving across the network (TLS).
• At rest: sitting on disk (file encryption).
• In use: being processed in memory (the hardest).

Each state needs different protection.

What Is Encryption?

• Encryption: turning readable data (plaintext) into unreadable data (ciphertext) with a key.
• Decryption: opening it back up with the key.
• Security depends on the key's secrecy.

Symmetric vs. Asymmetric

• Symmetric: a single key (AES). Fast.
• Asymmetric: a public + private pair (RSA/ECC). Easy key distribution.
• In practice, used together (hybrid).

Hash (Digest)

• Digest: a fixed-size fingerprint computed from data (SHA-256).
• One-way; if the data changes, the digest changes.
• The foundation of integrity and signatures.

MAC and Signature

• MAC: symmetric; the message hasn't changed + it came from the right party.
• Signature: asymmetric; who signed it (non-repudiation).
• Both provide integrity.

AEAD

• AEAD: confidentiality and integrity together (AES-GCM).
• Provides both without a separate MAC.
• The modern choice.

IV / Nonce / Salt

• IV/nonce: a unique starting value for every encryption.
• Salt: a random value added when deriving a key from a password.
• None of the three are secret, but all must be non-repeating/unique.

Randomness and CSPRNG

• CSPRNG: a cryptographically secure random generator (the operating system's getrandom/BCryptGenRandom).
• rand() is insecure.
• Keys/nonces/salts are generated from it.

Key Derivation (KDF)

• KDF: generating a key from a secret (a password or a master key).
• PBKDF2/Argon2: from a password (slow, salted).
• HKDF: many keys from a master secret.

Key Hierarchy

• A single key isn't used for every job.
• Master key → derived keys (data, session).
• Crypto-period: each key's lifetime.

Forward Secrecy

• Forward secrecy: a new key for every session.
• Even if the long-term key leaks, old sessions can't be decrypted.
• Modern TLS provides it.

TLS (Briefly)

• TLS: the protocol for secure communication on the network (underneath HTTPS).
• Key agreement + AEAD + certificate validation.
• We'll see it in Section 8.

Now We're Ready

Terms:

the three states of data · encryption · symmetric/asymmetric · digest · MAC/signature · AEAD · IV/nonce/salt · CSPRNG · KDF/HKDF · key hierarchy · forward secrecy · TLS

Now: the three states of data and the security shell.

Today's Plan (3 Hours)

Learning outcomes: LO.2 (encryption, secure communication) · LO.4 (secure channel)

How Do the Demos Work?

• One source, two platforms: Windows (Visual Studio 2022) and WSL/Linux (GCC)
• Crypto from a common header: Linux → OpenSSL, Windows → BCrypt (CNG) — no need to install OpenSSL
• Build: Windows .\build.ps1 · WSL ./build.sh
• Run: Windows .\demo.ps1 · WSL sh demo.sh
• Binaries live in each demo's bin\windows / bin/linux folder

⚠️ Ethics: the network is localhost only; the certificates are ours; try these
techniques only on your own computer.

Why Are We Focusing on Data?

• In the first two weeks, we protected the program itself with "bug → attack → fix."
• This week the focus shifts to the data: passwords, payment keys, personal information.
• A secret exists in three separate states throughout its lifecycle.
• Each state has a different threat and a different defence.

A Secret's Three States

Each state's threat and defence are different. You have to think about all of them together.

The Three States — At a Glance

Example Architecture: Phone ↔ Server

• Phone: an untrusted environment — the user (i.e., a possible attacker) owns the device; it may be rooted/debugged.
• Server: the trusted party.
• At every interface, ask: which data, which state, how is identity verified, confidentiality or integrity?

The Four Families of Cryptography — Diagram

Cryptography Isn't One Thing

• Different tools exist for different goals.
• The four most commonly confused families: encryption, hash, MAC, signature.
• Which gives confidentiality, which gives integrity, which gives both?

The Two Most Common Mistakes

1. Encrypting alone, forgetting integrity. Ciphertext (e.g., AES-CTR) doesn't stop an attacker from flipping bits undetected.
2. Writing your own cipher/mode. Kerckhoffs's principle: security rests on the key's secrecy, not the algorithm's.

Use standard, proven constructions; homemade crypto is broken almost every time.

Why Isn't Symmetric Enough On Its Own?

• Symmetric (AES): very fast.
• But both parties need to know the same secret key.
• How do you share that key over an insecure network?

The answer is on the next slide.

What Does Asymmetric Solve, What Does It Cost?

• Asymmetric (RSA/EC): everyone has a public (distributed) and a private (secret) key.
• It solves the key-distribution problem.
• But operations are slow; not suitable for large data (100–1000× slower).

Hybrid: Both Together

• Hybrid: asymmetric crypto carries a small symmetric key; the data is then encrypted with it using AEAD.
• Real systems always work this way.

This is exactly what TLS does: a session key via ECDHE → traffic with AES-GCM.

What Is a Block Cipher?

• Block cipher: an algorithm that encrypts data in fixed-size blocks.
• AES: encrypts one 16-byte block at a time.
• Data longer than a block needs a mode (mode of operation).

Block or Stream? The Mode Matters

AES is a block cipher (16 bytes). Longer data needs a mode:

ChaCha20: A Stream Cipher

• Stream cipher: no block concept; generates a keystream the same length as the data and XORs it.
• ChaCha20 is already a stream cipher.
• + Poly1305 MAC = AEAD (ChaCha20-Poly1305, RFC 8439).

Same result: confidentiality + integrity in one package.

Hash (Digest): A One-Way Fingerprint

• Keyless. Only shows whether the data has changed.
• An attacker can change the data and recompute the digest too.
• So a digest alone is not proof of integrity.
• Old MD5/SHA-1 are collision-prone; use SHA-256/SHA-3.

MAC: Integrity with a Shared Key

• 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."
• Since both parties know the key, a MAC does not provide non-repudiation.
• MAC comparison must be constant-time (CRYPTO_memcmp), not plain memcmp.

Signature: Non-Repudiation

• Digital signature (Ed25519, RSA-PSS): works with a public/private key pair.
• Only the private-key holder can produce a signature; anyone can verify it with the public key.
• That's why it provides non-repudiation.
• Certificates and release signing (Week 10) rely on this.

Hash / MAC / Signature: Which One, When?

⚠️ A digest alone is not proof of integrity (the attacker can recompute it too).

AEAD Is Usually the Right Answer

• Instead of wiring up "encrypt + add a MAC" separately, use AEAD.
• It does both jobs in one call, in the right order (encrypt-then-MAC), with fewer chances for error.
• A separate MAC is needed only for data that won't be encrypted but still needs integrity (or via AEAD's AAD field).

What Is Demo 1?

• Demo 1 · code/week-03/01-aes-gcm-dosya — AEAD, NIST SP 800-38D.
• Encrypts a file with AES-256-GCM.
• Output format: [12-byte nonce][ciphertext][16-byte tag].
• Then we see that flipping one byte of the ciphertext, and of the tag alone, causes decryption to be rejected.

Demo 1 — Code

kripto_rastgele(nonce, 12);              // her mesaja YENI nonce
kripto_gcm_sifrele(anahtar, nonce, 12, NULL, 0,
                   duz, duz_boy, cik+12, etiket);
int ok = kripto_gcm_coz(...);            // etiket dogrulanir
if (!ok) { /* REDDET */ }

Demo 1 — Real Output

ADIM 3  Cozuldu ve DOGRULANDI (53 bayt)
ADIM 4  1 bayt degistir -> DOGRULAMA BASARISIZ, REDDEDILDI
ADIM 5  yalniz etiketi degistir -> yine REDDEDILDI

Demo 1 — Steps 2 and 3: Nonce, Correct Decryption

• 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.

Salt, IV, Nonce — Diagram

Demo 1 — Steps 4 and 5: Tampering → Rejection

• Step 4: Byte 20 of the ciphertext was XORed with a change. Since the GCM tag is computed over the whole ciphertext, even a single byte breaks the tag → decryption rejected.
• Step 5: This time only the tag was touched; also rejected.
• The tag is computed together with the data and the key; an attacker can't produce it without the key.

Demo 1 — Rule

✅ If you're encrypting something, use AEAD (AES-GCM / ChaCha20-Poly1305)
✅ A unique nonce for every message
✅ Always verify the tag; produce no output at all on failure (fail-closed)
✅ Don't leave integrity to a separate step

Three Kinds of Randomness — Diagram

Why Does Randomness Matter So Much?

• Key, IV, nonce, salt, session ID — all rest on a single assumption: unpredictability.
• If the world's best encryption algorithm gets its key from a predictable generator, it protects nothing.
• In this section we'll look at the wrong ways first, then the right way.

Mistake 1 — Seeding with 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 them all in seconds.

Mistake 2 — Accidentally Wiping Out Entropy

The Debian OpenSSL disaster (2008): a packager removed two lines that added entropy to OpenSSL's random pool, to silence a warning.

• For two years, the only entropy source was the process ID (≤ 32,768 values).
• Attackers pre-generated and listed every possible key (CVE-2008-0166).

Four Common Misconceptions — Diagram

Mistake 2 — Takeaway

➡️ Don't touch cryptographic code without understanding it.

➡️ Statistically testing a random generator's output does not prove its unpredictability.

Mistake 3 — Bias When Reducing to a Range

r % 6 looks harmless. If r is uniform over 0–255:

256 = 42*6 + 4

• Values 0–3 come out 43 times each, values 4–5 come out 42 times each.
• Irrelevant for a die roll; increases predictability when generating a password/OTP.
• The correct method is rejection sampling — next slide.

Why Should You Check the Return Value?

• The random generator can fail.
• If unchecked, the buffer stays uninitialized (or zero).
• The program keeps running with what it thinks is a "random" but is actually a fixed key.
• The only correct behaviour on failure: stop the process.

Unbiased Range with Rejection Sampling

uint32_t aralikta_rastgele(uint32_t ust) {        /* Tarif 11.11 */
    uint32_t sinir = (uint32_t)(-ust) % ust, r;   /* 2^32 mod ust */
    do rastgele_bayt(&r, sizeof r); while (r < sinir);
    return r % ust;
}

Idea: use the largest part of the 2³² values that divides evenly by ust, and discard the remainder.

AEAD: Four Inputs, Two Outputs

AAD: not encrypted, but if it's changed the tag won't hold — file header, version, record ID

Week 1's "Vault": derivation parameters as AAD → the iteration count can't be changed

Now Let's Open Up the Crypto API

• In Demo 1 we left the work to ready-made helper functions.
• Now we'll write OpenSSL's EVP interface line by line.
• Goal: see where mistakes can happen when using the library.
• The rule still applies: you don't write your own algorithm, but calling a ready-made algorithm correctly is also a skill.

EVP Encryption — Step 1: Choose the Algorithm

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

• Choose the algorithm (AES-256-GCM).
• Don't give the key and nonce yet — that's the next step.

EVP Encryption — Step 2: Nonce Length

EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_IVLEN, 12, NULL);

• Set the nonce (IV) length.
• The recommended value for GCM is 12 bytes; that's also the default, but writing it explicitly is good practice.

EVP Encryption — Step 3: Key + Nonce

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

• Give the key and the nonce now.
• The spots left NULL in the first Init call are filled in here.

EVP Encryption — Step 4: AAD

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

• Give the AAD: the output buffer is NULL.
• The AAD is not encrypted, it only goes into the tag (file header, version, record ID).

EVP Encryption — Step 5: Encrypt the Data

EVP_EncryptUpdate(ctx, sifreli, &n, acik, acik_n);

• Encrypt the plaintext.
• For large data, this step can be repeated in chunks.

EVP Encryption — Step 6: Finalize (MANDATORY)

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

• Because GCM runs in stream mode, there is no padding; this call usually writes 0 bytes.
• But calling it is mandatory: the tag is computed here.

EVP Encryption — Step 7: Get the Tag

EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_GET_TAG, 16, etiket);

• Get the tag and store it along with the ciphertext.

Decryption — Steps 1–2: Open, Set the Tag

EVP_DecryptUpdate(ctx, acik, &n, sifreli, sifreli_n);  /* açık metni YAZAR... */
EVP_CIPHER_CTX_ctrl(ctx, EVP_CTRL_GCM_SET_TAG, 16, etiket);  /* Final'dan ÖNCE */

• DecryptUpdate writes the plaintext to the buffer immediately — it isn't verified yet!
• The expected tag is given before Final.

Constant-Time Comparison

unsigned char fark = 0;
for (size_t i = 0; i < n; i++) fark |= a[i] ^ b[i];   /* her baytı dolaş */
return fark == 0;                                     /* ≈ CRYPTO_memcmp */

memcmp stops at the first differing byte; the timing leaks how many bytes were correct. Ready-made alternatives: CRYPTO_memcmp, sodium_memcmp.

In the Field: The Algorithm Inventory

• Real product guides include an algorithm inventory: every algorithm, its purpose, its key size.
• A good critical-reading exercise: old inventories show SHA-1 or CBC with a separate MAC.
• An inventory written today should show SHA-256 and AEAD instead.

How Does an Evaluator Test This?

• Compares the algorithm inventory against the source code.
• Examines nonce generation and repetition.
• Feeds back tampered ciphertext with one bit changed; confirms the application rejects it without a detailed error.
• Looks for memcmp in MAC comparisons.

All Three Are NOT Secret, But...

The only thing that's secret is the key.

Demo 2 — Nonce Reuse Leaks Data

KOTU (ayni nonce):
  C1 xor C2 = 070e1c08...5c1215
  P1 xor P2 = 070e1c08...5c1215     <-- AYNI = sizdi
  P2 = (C1 xor C2) xor P1 = "Toplam bakiye 45000 TL..."

IYI (farkli nonce):
  C1 xor C2 != P1 xor P2            <-- sizinti YOK

✅ Generate the nonce randomly or as a persistent counter; never repeat it.

Demo 2 — Rule (Continued)

• A random nonce is practical; but with many messages under the same key (NIST recommendation: ≤ 2³²), the birthday-bound probability kicks in.
• Alternative: make the nonce a counter — but the counter must be stored persistently (not reset when the device restarts).
• Real incidents: WEP's short IV, Sony PS3's repeated random value in ECDSA (the private key was extracted).

Demo 3 — ECB Leaks a Pattern ("the Penguin")

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

❌ ECB: the same block → the same ciphertext block, the shape stays readable
✅ GCM/CTR: every block differs → noise

ECB — Rule

✅ Don't use ECB. For encryption, use AEAD (GCM, ChaCha20-Poly1305); for disk, use XTS-AES.

Every occurrence of ecb in code review is a finding. An evaluator can catch ECB automatically by looking for repeated 16-byte blocks in the same plaintext.

This Section's Rule

• Salt, IV, nonce: none of them is secret, but each requires a different kind of non-repetition.
• A nonce must never repeat with the same key.
• ECB is forbidden. Choosing a mode is a security decision.

Deriving a Key from a Password — Diagram

Why Can't a Password Be a Key Directly?

• A password is short, low-entropy, and predictable.
• Made directly into a key, brute force becomes cheap.
• Solution: a key derivation function from a password (KDF).

A KDF Does Two Jobs

1. Salt: random → rainbow tables are useless, matching passwords aren't obvious
2. Slowness: hundreds of thousands of rounds → every attempt is expensive, brute force slows down

Demo 4 — Round Count, Timing, Salt

1) TUZ: ayni parola + ayni tuz -> AYNI anahtar
        ayni parola + FARKLI tuz -> FARKLI anahtar
2) TUR vs SURE (WSL):
   tur =   1000  ->    0.37 ms
   tur = 100000  ->   39.05 ms
   tur = 600000  ->  209.55 ms   <-- OWASP 2023 asgari
   tur =2000000  ->  628.42 ms

Demo 4 — The Effect of the Salt

• Same password + same salt → the same key every time.
• If the salt is fixed, an attacker can build one table and search everyone.
• Same password + different salt → a completely different key.

➡️ The salt must be random and unique for every record.

Demo 4 — The Effect of 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 by the attacker gets that much more expensive too.
• "200 ms at user login" is acceptable; for an attacker, it means thousands of attempts instead of billions.

Demo 4 — Rule

✅ Random salt + Argon2id (or high-round PBKDF2). ❌ Plain/unsalted SHA-256.

Going Further: Pepper

• In addition to the salt, a secret pepper can be added — not stored in the database, but kept in configuration or an HSM.
• If the DB is stolen (as long as the pepper doesn't leak), the digests get one more layer of protection.
• The salt is not secret; the pepper is.

This Section's Rule

• Never make a password a key directly.
• A random salt + a KDF with enough cost (Argon2id preferred).
• Tune the cost to the hardware, and increase it over the years.

Why Not Use the Master Secret Directly?

• 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.

HKDF Step 1: Extract

• Input: master secret + salt.
• Output: a uniform pseudorandom key (PRK).
• Goal: compress the irregularity in the raw secret into a uniform key.

HKDF Step 2: Expand

• Input: PRK + an info label.
• Output: a key of the requested length.
• Different info → different key. From the same PRK, an encryption key, a MAC key, and a session key each come out separately.

What Is Forward Secrecy?

• Forward secrecy: even if today's key leaks, old sessions can't be decrypted.
• A one-way chain: K0 = master secret, Kᵢ = HKDF(Kᵢ₋₁).
• Delete the previous one at every step.

Forward Secrecy — Diagram

Even if today's key leaks, old sessions stay safe. Default in TLS 1.3 (with ephemeral ECDHE).

Demo 5 — HKDF Output

info='...sifreleme...' -> 2b8b4684...0e577a55
info='...MAC...'       -> 30a302d1...c55dfa84   (farkli)

ILERI GIZLILIK zinciri:
  K1=0630f63f...  K2=def84847...
  K3=54b13f0f...  K4=55524a8f...
  ^ her adimda eski anahtar silindi

Demo 5 — Explanation

• From the same master secret, different keys came out with different info values; one purpose's key can't be used for another.
• In the forward-secrecy chain, the previous key was deleted at every step.
• Only K4 remains; since the chain is one-way, K3, K2, K1 can't be recomputed from K4.

Demo 5 — Rule

✅ A separate key per purpose/session · a unique info for every derivation · delete after use.

This Section's Rule

• Derive separate keys from the master secret for each purpose and session.
• Give every derivation a unique info/label.
• Delete short-lived session keys after use.

Was the Algorithm Broken, or Was the Key Mismanaged?

• Of the incidents reported as "the algorithm was broken," only a tiny fraction are actually the algorithm breaking.
• The vast majority are key-management mistakes: a key embedded in code, a key that never changes, one key for every job.
• This section exists to prevent these mistakes.

What Is a Crypto-Period?

• The length of time a key is allowed to be used.
• Once it expires, the key is no longer used to encrypt new data.
• It may be kept a while longer to decrypt old data.
• Factors: how much data is protected, how long it must stay confidential, how exposed the key is.

A Key's Life — Diagram

Key Hierarchy: Two Basic Ideas

1. Key separation: different keys for different purposes (via HKDF info).
2. Limiting the damage: compromising a lower-level key affects only that branch.

Key Hierarchy

• Key separation: a separate key for each purpose (HKDF info)
• Limiting damage: if a single-use key is stolen, what's lost = one transaction

Hierarchy and Key Renewal in Payments

An EMV-style chain:

Issuer master key (HSM) → card master key (card no. + sequence no.) → session key (transaction counter) → single-use key

• Only the limited-use keys at the bottom reach the phone
• New ones are requested from the server when they run out (replenishment)
• Even if the phone is compromised: a few transactions' worth of key, easily revoked server-side

Envelope Encryption — Why?

Encrypting large data directly with the master key creates two problems:

• The master key is used often → more exposure time.
• When the key changes, all the data must be re-encrypted.

Envelope Encryption — Four Steps

1. A random data encryption key (DEK) is generated per record; the data is encrypted with it.
2. The DEK is wrapped with a key encryption key (KEK).
3. The KEK sits somewhere secure: a TPM, an HSM, a cloud KMS.
4. When the KEK is renewed, only the small DEKs are rewrapped — not the data.

Record Format and AAD — Diagram

Session Key: Today's Recommendation

This Section's Rule

• Organise keys within a hierarchy; give every key a single purpose and a crypto-period.
• Envelope-encrypt the data; protect the key version with AAD.
• Only download keys with limited damage, short lifetime to the client device.

Three Layers of Validation

⚠️ OpenSSL's default: doesn't validate! SSL_VERIFY_PEER + SSL_set1_host are required.

Pinning and TOFU

• Pinning: embed the SHA-256 of the server's public key (SPKI). Even if the chain
  is valid, REJECT if the key doesn't match. (Common on mobile.)
• TOFU: without a PKI, remember the first key, warn if it changes (the SSH model).

TLS 1.2 → 1.3: a single RTT · only strong AEAD suites · weak features removed
· enforce a minimum version against downgrade.

Demo 6 — MITM → Hostname + Pinning

1 Guvensiz  -> SALDIRGAN: KABUL (TEHLIKELI, MITM olurdu)
2 Dogrula   -> GERCEK   : DOGRULANDI, KABUL
3 Dogrula   -> SALDIRGAN: REDDEDILDI (kendi imzali)
4 Pin       -> GERCEK   : pin TUTTU, KABUL
5 Pin       -> SALDIRGAN: pin TUTMADI, REDDEDILDI

Only 127.0.0.1, certificates we generated ourselves. (Windows: run it under WSL.)

"Don't Rely on TLS Alone"

• The TLS channel protects the connection, but the endpoints can be untrusted (a rooted
  phone, faulty pinning)
• In high-security settings, add one more layer inside TLS: message-level AEAD + MAC
• This way, even if TLS is bypassed, the body is still encrypted → the outermost 2 layers of the security shell

✅ Don't swallow a certificate error, don't fall back to the trust store (fail-closed).

The TLS Client's Steps — Diagram

Why Is Step 6 Critical?

• Chain validation only asks, "did a trusted CA sign it?"
• An attacker can get a completely valid certificate for their own domain
• Without a name check, a certificate for attacker.example gets accepted in place of bank.example

➡️ The 2012 "world's most dangerous code" study: a large number of applications and libraries skipped this step

Windows: WinHTTP / Schannel

• WinHTTP validates the certificate and name by default
• Danger: flags that turn validation off

DWORD b = SECURITY_FLAG_IGNORE_UNKNOWN_CA |
          SECURITY_FLAG_IGNORE_CERT_CN_INVALID |
          SECURITY_FLAG_IGNORE_CERT_DATE_INVALID;   /* ASLA sürümde */
WinHttpSetOption(istek, WINHTTP_OPTION_SECURITY_FLAGS, &b, sizeof b);

✅ Add the test server's CA to the development machine's trust store; keep the code the same

Test Your Own Connection

openssl s_client -connect s.ornek:443 -servername s.ornek -verify_return_error -brief
openssl s_client -connect s.ornek:443 -tls1_1      # reddedilmeli

1. A self-signed certificate → reject (Demo 6)
2. A valid certificate for another name → reject
3. Install your own CA on the device + a proxy → a pinning app should reject
4. Is a pin failure reported?

This Section's Rule

• Manually turn on validation on the client: CA store + SSL_VERIFY_PEER + SSL_set1_host + min. TLS 1.2.
• Add SPKI pinning for high risk, always keep a backup pin.
• Stay closed on error (fail-closed): don't swallow the exception and fall back to the trust store.

Layers of Data in Use — Diagram

Data at Rest: Two Levels — Diagram

Data at Rest: File/Field Encryption

• Full disk/file: LUKS, BitLocker, XTS-AES, or application-level AEAD
• Field/column: encrypt only sensitive fields at the application layer with AEAD
• Masking: **** **** **** 4242 — this is not encryption, it reduces exposure
  (logs, screen, testing, tokenization)

Masking doesn't replace encryption, it complements it (different threats).

Demo 7 — Encrypt a Field in SQLite with AES-GCM

Saldirgan DB'yi acti:
  1|Ayse Yilmaz|D1ED7A36...   <- kart alani SIFRELI
Dogru anahtarla uygulama:
  1|Ayse Yilmaz|4242-4242-4242-4242
Yanlis anahtar:
  1|Ayse Yilmaz|(COZULEMEDI - etiket tutmadi)

ad is in the clear, kart is encrypted. The key isn't embedded in the code (device-bound KDF).
Linux sqlite3, Windows built-in winsqlite3.

Tokenization

• Even if the database, reports, or logs are stolen, there's no card number
• PCI DSS scope shrinks = Week 1's "transfer" answer
• What reaches the phone in mobile payment = a device-specific token number
• Format can be preserved: FF1 (NIST SP 800-38G)

Pseudonym and Test Data

kripto_hmac_sha256(takma_anahtari, 32, kimlik_no, strlen(kimlik_no), takma_ad);

• ❌ Plain SHA-256: an 11-digit ID number → all of them can be tried
• ✅ Keyed HMAC; key separate from the dataset · destroying the key = effectively anonymous

Preferred test data: 1. synthetic → 2. static masking → 3. dynamic masking

Data in Use: 3 Layers

+ short lifetime, no copying. memset can be optimised away at -O2; cleanse cannot be removed.

Demo 8 — mlock + Secure Erasure

Katman 1 - cokme dokumu kapatildi: TAMAM
Katman 2 - mlock ile takasa yazma engellendi: TAMAM
Sir kullaniliyor: dolu bayt = 20
Katman 3 - guvenli silme sonrasi dolu bayt = 0
OPENSSL_cleanse cagrisi makine kodunda kaldi (memset gibi silinmez)

Device binding: wrap the key from the device fingerprint with HKDF + AEAD → can't be
opened on another device (Demo 9).

This Section's Rule

• At rest: encrypt sensitive fields with AEAD, don't embed the key in code.
• Masking doesn't replace encryption, it complements it (log, screen, testing).
• In use: open the secret at the last moment, keep it as briefly as possible, and erase it irrecoverably.

Demo 9 — Wrap with 4 Shells, Open in Reverse Order

SARMA: sir -> K1(cihaz) -> K2(depo) -> K3(oturum) -> K4(kanal)
   Kabuk 4 = 128 bayt  <- aktarilan paket
ACMA : K4 -> K3 -> K2 -> K1 -> sir   (hepsi TAMAM, sir DOGRU)

Saldiri 1: 1 bit kurcala -> Kabuk 4 RED (etiket tutmadi)
Saldiri 2: baska cihaza kopyala -> dis 3 kabuk acilir,
           Kabuk 1 (cihaz) RED -> sir ACILAMAZ

✅ Not "which single measure?" but "which layers?" · independent keys.

This Section's Rule

• When protecting a critical asset, don't ask "which single measure?" — ask "which layers?"
• Put a shell on every stage (transport, storage, use).
• Build the shells with independent keys from one another; breaking one shouldn't give up another.

The Road to Whitebox — Diagram

Why Whitebox?

• This week's hidden assumption: the key sits in the clear in memory while it's in use
• "The device owner is the attacker" can read memory → catches that moment
• Secure erasure narrows the window, it doesn't close it
• Whitebox: embeds the key into tables, its raw form never appears in memory

⚠️ Not a magic wand: still open to oracle/code-lifting attacks → needs the other shells too.
Details: Week 11.

Project: This Week (S5, S7)

• S5 — Asset list (draft): every sensitive asset; location, lifetime, C/I/I+, protection
• S7 — Data security + shell matrix: every asset × three states × shells; secure
  erasure policy

Requirement families: CEN429-DT/DR/DU (in transit/at rest/in use), AS, CR

Add a row to the S17 compliance matrix for every requirement.

Class Activities

1. Stop the MITM: disable SSL_set1_host in Demo 6 → which attacker slips through?
2. Repeat a nonce: a fixed nonce in Demo 1 → XOR two ciphertexts
3. Map the three data states: a threat/countermeasure table for a health app
4. KDF cost: find the round count that gives 100 ms

Self-Check (Sample)

1. The difference between AEAD and AES-CTR?
2. Why is nonce reuse a disaster?
3. Why isn't ECB used?
4. The OpenSSL client's most dangerous default?
5. What does pinning catch, what does hostname validation catch?
6. What is a security shell, give an example?

Full list (20 questions) and answers on the course site. Quiz-1 is in this style + code reading.

Self-Check — Answers (Sample 1–6)

1. AES-CTR provides confidentiality only; AEAD (AES-GCM) provides confidentiality + integrity/identity together with a tag. Changes go unnoticed in CTR.
2. The same key+nonce repeats the keystream; the XOR of two ciphertexts leaks the plaintext, and in GCM the authentication key is at risk.
3. ECB turns the same block into the same ciphertext block → patterns are visible; no semantic security.
4. The client doesn't validate the certificate/hostname on its own; without turning it on manually, MITM is possible.
5. Pinning: pins the expected server key (SPKI) → catches a fake-but-"valid" certificate. Hostname validation: catches whether the certificate belongs to the correct domain.
6. Security shell: protection wrapped around an asset (C=confidentiality, I=integrity). E.g., a key file = AES-GCM (C) + tag/HMAC (I).

Self-Check (Continued)

1. Why can't rand() be used for security? What instead?
2. EVP_DecryptFinal_ex returned failure; what do you do with the plaintext in the buffer?
3. Why is memcmp risky for MAC comparison?
4. Is a key whose crypto-period has expired deleted immediately?
5. Why isn't the data re-encrypted when the KEK is renewed in envelope encryption?

Self-Check — Answers (1–5)

1. rand() is statistical and predictable → use a CSPRNG (RAND_bytes / getrandom).
2. If decryption fails, securely erase the plaintext in the buffer (memset_s) and reject it — integrity wasn't verified, don't use it.
3. memcmp exits early → a timing leak; use CRYPTO_memcmp / a constant-time comparison.
4. No. It's not used for new encryption, but it's kept for decryption only until the old data is re-encrypted.
5. The data is encrypted with the DEK; when the KEK is renewed, only the DEKs are rewrapped, not the data.

Self-Check (Continued)

6. What happens if SSL_set1_host isn't called?
7. Why SPKI for pinning, and why a backup pin?
8. What is "fail-open"? An example
9. Why can't a plain SHA-256 of an ID number be a pseudonym?
10. Why does tokenization shrink PCI DSS scope?

Self-Check — Answers (6–10)

6. Without SSL_set1_host, the hostname isn't validated; a valid certificate for another name gets accepted → MITM.
7. The SPKI stays the same even if the certificate is renewed (as long as the key is the same); a backup pin prevents the app from "bricking" when the key changes.
8. Fail-open: treating an error as "passed/allow"; e.g., a swallowed KeyStoreException skipping validation.
9. An ID number's value space is small/predictable → plain SHA-256 can be brute-forced back; a keyed HMAC is needed.
10. Tokenization: the real PAN stays only in the vault; the rest of the system holds tokens → the PCI DSS audit scope shrinks.

Scenario

An application must protect a user's "note":

• it comes from the server (in transit)
• it sits on disk (at rest)
• it's shown on screen (in use)

Let's protect all three states.

In Transit · Step

• Transport with TLS 1.3.
• Certificate chain + SAN validation.
• SPKI pin + backup pin, where applicable.

At Rest · Step

• Encrypt with AES-256-GCM (AEAD).
• A unique nonce.
• Key from a TEE/HSM or a KDF from a password.

In Use · Step

• Keep it in memory for as short a time as possible.
• Erase it when done (memset-like).
• RASP + short lifetime.

Where Does the Key Come From?

• Master password → PBKDF2/Argon2 (salted, slow) → master key.
• Master key → HKDF → data key, session key.
• Each key has a separate job.

Integrity

• AEAD already provides integrity.
• TLS in transit, the GCM tag at rest.
• Tampering → decryption is rejected.

Scenario · Summary

Mistake · Nonce Reuse

• Same nonce twice in GCM → disaster (key/data can leak).
• Use a counter or a sufficiently random nonce.

Mistake · Weak Randomness

• Key/nonce with rand() → predictable.
• Use a CSPRNG (getrandom, BCryptGenRandom).

Mistake · Making the Password the Key Directly

• A password has low entropy; a direct key is weak.
• Derive it with a KDF (salted, slow).

Mistake · ECB Mode

• Leaks patterns (the "penguin").
• Use AEAD.

Mistake · Encryption Without Integrity

• Confidentiality alone isn't enough; it can be tampered with.
• AEAD or encrypt-then-MAC.

Mistake · A Non-Constant-Time Comparison

• If MAC/password comparison exits early, it leaks timing.
• Compare in constant time.

Question 1

The three states of data and each one's protection?

Answer: In transit (TLS), at rest (AEAD encryption), in use (short lifetime + erasure).

Question 2

Why is nonce reuse a disaster in GCM?

Answer: Under the same key+nonce, confidentiality and integrity both collapse; the keystream and data can leak. The nonce must be unique.

Question 3

Why can't a password be a key directly?

Answer: It has low entropy and is predictable. It's derived, salted and slow, with a KDF (PBKDF2/Argon2).

Question 4

What does AEAD provide, which separate steps does it replace?

Answer: Confidentiality + integrity together; it replaces separate encryption + MAC steps.

Question 5

What does forward secrecy mean?

Answer: A new key every session; even if the long-term key leaks, old sessions can't be decrypted.

Question 6

Is IV/nonce/salt secret? What's the rule?

Answer: Not secret, but must be unique/non-repeating; nonce reuse and a fixed salt are dangerous.

Question 7

Why is a CSPRNG needed?

Answer: rand() is predictable; a cryptographically secure generator (the OS) is needed for keys/nonces/salts.

Question 8

Why does a key hierarchy exist?

Answer: A single key isn't used for every job; derived keys come from a master key, each with its own job and lifetime.

Final Word (Week 3)

Protect data in all three states: the right mode (AEAD), secure randomness, a key from a KDF, a unique nonce, and a well
managed key hierarchy.

We'll go deeper into PKI and certificates in Week 10.