Compare commits
2 Commits
6225809bf6
...
51c64ac563
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
51c64ac563 | ||
|
|
eb476b26ce |
404
content/CSE4303/CSE4303_E1.md
Normal file
404
content/CSE4303/CSE4303_E1.md
Normal file
@@ -0,0 +1,404 @@
|
||||
# CSE4303 Introduction to Computer Security (Exam Review)
|
||||
|
||||
## Details
|
||||
|
||||
Time and location
|
||||
|
||||
– In class exam – Thursday, 3/5 at 11:30 AM
|
||||
– What is allowed:
|
||||
- One 8.5” X 11” paper of notes, single-sided only, typed or hand-written
|
||||
|
||||
Topics covered:
|
||||
|
||||
– Security fundamentals
|
||||
– TCP/IP network stack
|
||||
– Crypto fundamentals
|
||||
– Symmetric key cryptography
|
||||
– Hash functions
|
||||
– Asymmetric key cryptography
|
||||
|
||||
## Security fundamentals
|
||||
|
||||
### Defining security
|
||||
|
||||
- Understand principles of security analysis
|
||||
- The security of a system, application, or protocol is always relative to
|
||||
- A set of desired properties
|
||||
- An adversary with specific capabilities ("threat model")
|
||||
|
||||
### Key security concepts
|
||||
|
||||
C.I.A. triad:
|
||||
|
||||
- Integrity: Prevent unauthorized modification of data, and/or detect if modification occurred.
|
||||
- ARP poisoning (ARP spoofing)
|
||||
- Authentication codes
|
||||
- Confidentiality: Prevent unauthorized parties from learning the contents of data (in transit or at rest).
|
||||
- Packet sniffing / eavesdropping
|
||||
- Data encryption
|
||||
- Availability: Ensure systems and data are accessible to authorized users when needed.
|
||||
- Denial-of-Service (DoS) / Distributed DoS (DDoS)
|
||||
- Rate limiting + traffic filtering (often with DDoS protection/CDN)
|
||||
|
||||
Other security goals:
|
||||
|
||||
- Authenticity: identity of an entity (issuer of info/message) is verified
|
||||
- Anonymity: identity of an entity remains unknown
|
||||
- Non-repudiation: messages can't be denied or taken back (e.g. online transaction commitments)
|
||||
|
||||
### Modeling attacks
|
||||
|
||||
Common components:
|
||||
|
||||
- System being attacked (usually a model, with assumptions and abstractions)
|
||||
- Threat model
|
||||
- Attack surface: what can be attacked
|
||||
- Open ports and exposed services
|
||||
- Public APIs and their parameters
|
||||
- Web endpoints, forms, cookies
|
||||
- File system permissions
|
||||
- Hardware interfaces (USB, JTAG)
|
||||
- User roles and privilege boundaries
|
||||
- Attack vector: how the attacker attacks
|
||||
- SQL injection via POST /login
|
||||
- Phishing to steal credentials, then SSH login
|
||||
- Buffer overflow in a network daemon
|
||||
- Cross-site scripting through a comment field
|
||||
- Supply-chain poisoning of a dependency
|
||||
- Vulnerability: what the attacker can do
|
||||
- Exploit: how the attacker exploits the vulnerability
|
||||
- Damage: what the attacker can do
|
||||
- Mitigation: mitigate vulnerability
|
||||
- Defense: close vulnerability gap
|
||||
|
||||
Importance of correct modeling
|
||||
|
||||
- Attack-surface awareness guides defenses
|
||||
- E.g. pre-Covid-19 vs. post-Covid attack surface of company servers
|
||||
- Match resources to expected threat actors
|
||||
- "Script kiddie": individual or group running off-the-shelf attacks
|
||||
- Caveat: off-the-shelf attacks can still be quite powerful! Metasploit, Shodan, dark web market.
|
||||
- "Insider attack": employee with access to internal machines/networks
|
||||
- "Advanced Persistent Threat (APT)": nation-state level resources and patience
|
||||
- All these threats have different motivations, require different defenses/responses!
|
||||
- Reevaluate often
|
||||
- Threat capabilities change over time
|
||||
|
||||
## TCP/IP network stack
|
||||
|
||||
Local and interdomain routing
|
||||
|
||||
- TCP/IP for routing and messaging
|
||||
- BGP for routing announcements
|
||||
|
||||
Domain Name System
|
||||
|
||||
- Find IP address from symbolic name (cse.wustl.edu)
|
||||
|
||||
### Layer Summary
|
||||
|
||||
Application: the actual sending message
|
||||
Transport (TCP, UDP): segment
|
||||
Network (IP): packet
|
||||
Data Link (Ethernet): frame
|
||||
|
||||
### Types of Addresses in Internet
|
||||
|
||||
- Media Access Control (MAC) addresses in the network access layer
|
||||
- Associated w/ network interface card (NIC)
|
||||
- 00-50-56-C0-00-01
|
||||
- IP addresses for the network layer
|
||||
- IPv4 (32 bit) vs IPv6 (128 bit)
|
||||
- 128.1.1.3 vs fe80::fc38:6673:f04d:b37b%4
|
||||
- IP addresses + ports for the transport layer
|
||||
- E.g., 10.0.0.2:8080
|
||||
- Domain names for the application/human layer
|
||||
- E.g., www.wustl.edu
|
||||
|
||||
#### Routing and Translation of Addresses
|
||||
|
||||
(All of them are attack surfaces)
|
||||
|
||||
- Translation between IP addresses and MAC addresses
|
||||
- Address Resolution Protocol (ARP) for IPv4
|
||||
- Neighbor Discovery Protocol (NDP) for IPv6
|
||||
- Routing with IP addresses
|
||||
- TCP, UDP for connections, IP for routing packets
|
||||
- Border Gateway Protocol for routing table updates
|
||||
- Translation between IP addresses and domain names
|
||||
- Domain Name System (DNS)
|
||||
|
||||
### Summary for security
|
||||
|
||||
- Confidentiality
|
||||
- Packet sniffing
|
||||
- Integrity
|
||||
- ARP poisoning
|
||||
- Availability
|
||||
- Denial of service attacks
|
||||
- Common
|
||||
- Address translation poisoning attacks (DNS, ARP)
|
||||
- Packet spoofing
|
||||
- Core protocols not designed for security
|
||||
- Eavesdropping, packet injection, route stealing, DNS poisoning
|
||||
- Patched over time to prevent basic attacks
|
||||
- More secure variants exist:
|
||||
- IP $\to$ IPsec (IPsec is )
|
||||
- DNS $\to$ DNSsec
|
||||
- BGP $\to$ sBGP
|
||||
|
||||
## Crypto fundamentals
|
||||
|
||||
- Well-defined statement about difficulty of compromising a system
|
||||
- ...with clear implicit or explicit assumptions about:
|
||||
- Parameters of the system
|
||||
- Threat model
|
||||
- Attack surfaces
|
||||
- Example: "A one-time pad cipher is secure against any cryptanalysis, including a brute-force attack, assuming:
|
||||
- the key is the same length as the plaintext,
|
||||
- the key is truly random, and
|
||||
- the key is never re-used."
|
||||
|
||||
### Common roles in cryptography
|
||||
|
||||
Alice and Bob: Sender and receiver
|
||||
|
||||
Eve: Adversary that can see but not create any packets
|
||||
|
||||
Mallory: Man in the middle, can create and modify packets
|
||||
|
||||
The message M is called the **plaintext**.
|
||||
|
||||
Alice will convert plaintext M to an encrypted form using an
|
||||
encryption algorithm E that outputs a **ciphertext*- C for M.
|
||||
|
||||
#### Cryptography goals
|
||||
|
||||
Confidentiality:
|
||||
|
||||
- Mallory and Eve cannot recover original message from ciphertext
|
||||
|
||||
Integrity:
|
||||
|
||||
- Mallory cannot modify message from Alice to Bob without detection by Bob
|
||||
|
||||
#### Threat models
|
||||
|
||||
- Attacker may have (with increasing power):
|
||||
- a) collection of ciphertexts (ciphertext-only attack)
|
||||
- b) collection of plaintext/ciphertext pairs (known plaintext attack: KPA)
|
||||
- c) collection of plaintext/ciphertext pairs for plaintexts selected by the attacker (chosen plaintext attack: CPA)
|
||||
- d) collection of plaintext/ciphertext pairs for ciphertexts selected by the attacker (chosen ciphertext attack: CCA/CCA2)
|
||||
|
||||
## Symmetric key cryptography
|
||||
|
||||
### Classical cryptography
|
||||
|
||||
Techniques: substitution and transposition
|
||||
|
||||
- Substitution: 1:1 mapping of alphabet onto itself
|
||||
- Transposition: permutation of elements (i.e. rearrange letters)
|
||||
|
||||
- Caesar cipher: rotate each letter by k positions (k is fixed)
|
||||
- Vigenère cipher: If length of key is known, split letters into groups based on index within key and do frequency analysis within groups
|
||||
|
||||
> The three steps in cryptography:
|
||||
>
|
||||
> - Precisely specify threat model
|
||||
> - Propose a construction
|
||||
> - Prove that breaking construction under threat mode will solve an underlying hard problem
|
||||
|
||||
#### Perfect secrecy
|
||||
|
||||
Ciphertext attack reveal no "info" about plaintext under ciphertext only attack
|
||||
|
||||
Def: A cipher $(E, D)$ over $(K, M, C)$ has perfect secrecy if
|
||||
|
||||
- $\forall m_0, m_1 \in M$ $(|m_0| = |m_1|)$ and $\forall c \in C$,
|
||||
- $\Pr[E(k, m_0) = c] = \Pr[E(k, m_1) = c]$ where $k \leftarrow K$
|
||||
|
||||
#### XOR One-time pad (perfect secrecy)
|
||||
|
||||
Assumptions:
|
||||
|
||||
- Key is as long as message
|
||||
- Key is random
|
||||
- Key is never re-used
|
||||
|
||||
In practice, relax this assumption gets "Stream ciphers"
|
||||
|
||||
### Stream cipher
|
||||
|
||||
- Use pseudorandom generator as keystream for xore encryption (security is guaranteed by pseudorandom generator)
|
||||
|
||||
Security abstraction:
|
||||
|
||||
1. XOR transfers randomness of keystream to randomness of CT regardless of PT’s content
|
||||
2. Security depends on G being “practically” indistinguishable from random string and “practically” unpredictable
|
||||
3. Idea: shouldn’t be able to predict next bit of generator given all bits seen so far
|
||||
|
||||
#### Semantic security
|
||||
|
||||
- $(E, D)$ has semantic secrecy if $\forall m_0, m_1 \in M$ $(|m_0| = |m_1|)$,
|
||||
- $\{E(k, m_0)\} \approx_p \{E(k, m_1)\}$ where $k \leftarrow K$
|
||||
- ...and the adversary exhibits $m_0, m_1 \in M$ explicitly
|
||||
|
||||
The advantage of adversary is defined as the probability of distinguishing $E(k, m_0)$ from $E(k, m_1)$.
|
||||
|
||||
#### Weakness for stream ciphers
|
||||
|
||||
- Week pseudorandom generator
|
||||
- Key re-use
|
||||
- Predicable effect of modifying ciphertext or decrypted plaintext.
|
||||
|
||||
### Block cipher
|
||||
|
||||
View cipher as a Pseudo-Random Permutation (PRP)
|
||||
|
||||
#### Pseudorandom permutation
|
||||
|
||||
- PRP defined over $(K, X)$:
|
||||
- $E: K \times X \to X$
|
||||
- such that:
|
||||
1. There exists an "efficient" deterministic algorithm to evaluate $E(k, x)$.
|
||||
2. The function $E(k, \cdot)$ is one-to-one.
|
||||
3. There exists an "efficient" inversion algorithm $D(k, y)$.
|
||||
|
||||
- i.e. a PRF that is an invertible one-to-one mapping from message space to message space
|
||||
|
||||
#### Security of block ciphers
|
||||
|
||||
Intuition: a PRP is secure if: a random function in $Perms[X]$ is indistinguishable from a random function in $SF$ (real random permutation function)
|
||||
|
||||
The adversarial game is to let adversary decide $x$, then we choose random key $k$ and give $E(k,x)$ and real random permutation $Perm(X)$ to let adversary decide which is which.
|
||||
|
||||
#### Block cipher constructions: Feistel network
|
||||
|
||||
Forward network:
|
||||
|
||||

|
||||
|
||||
- Forward (round $i$): given $(L_{i-1}, R_{i-1}) \in \{0,1\}^n \times \{0,1\}^n$,
|
||||
- $L_i = R_{i-1}$
|
||||
- $R_i = L_{i-1} \oplus f_i(R_{i-1})$
|
||||
|
||||
- Proof (construct the inverse):
|
||||
- Suppose we are given the output of round $i$, namely $(L_i, R_i)$.
|
||||
- Recover the previous right half immediately:
|
||||
- $R_{i-1} = L_i$
|
||||
- Then recover the previous left half by undoing the XOR:
|
||||
- $L_{i-1} = R_i \oplus f_i(R_{i-1}) = R_i \oplus f_i(L_i)$
|
||||
- Therefore each round map is invertible, with inverse transformation:
|
||||
- $R_{i-1} = L_i$
|
||||
- $L_{i-1} = f_i(L_i) \oplus R_i$
|
||||
- Applying this inverse for $i=d,d-1,\ldots,1$ recovers $(L_0,R_0)$ from $(L_d,R_d)$, so the whole Feistel network $F$ is invertible.
|
||||
|
||||
- Notation sketch (each wire is $n$ bits):
|
||||
- Input: $(L_0, R_0)$
|
||||
- Rounds:
|
||||
- $L_1 = R_0,\ \ R_1 = L_0 \oplus f_1(R_0)$
|
||||
- $L_2 = R_1,\ \ R_2 = L_1 \oplus f_2(R_1)$
|
||||
- $\cdots$
|
||||
- $L_d = R_{d-1},\ \ R_d = L_{d-1} \oplus f_d(R_{d-1})$
|
||||
- Output: $(L_d, R_d)$
|
||||
|
||||
## Hash functions
|
||||
|
||||
## Asymmetric key cryptography
|
||||
|
||||
## Appendix for additional algorithms and methods
|
||||
|
||||
### Feistel network (used by several items below)
|
||||
|
||||
A **Feistel network*- splits a block into left/right halves and iterates rounds of the form $(L_{i+1},R_{i+1})=(R_i, L_i\oplus F(R_i,K_i))$, so decryption reuses the same structure with subkeys in reverse order.
|
||||
|
||||
Feistel-based here: **DES, 3DES, CAMELLIA, SEED, GOST 28147-89 (and thus GOST89MAC uses a Feistel block cipher internally).**
|
||||
|
||||
### A) Cipherlist *filters / set operations- (not crypto primitives)
|
||||
|
||||
These don’t implement encryption or authentication; they just include/exclude suites.
|
||||
|
||||
- **COMPLEMENTOFDEFAULT*- — (selection) picks suites in `ALL` that are not enabled by default (notably RC4/anonymous, depending on build).
|
||||
- **ALL*- — (selection) all suites except `eNULL`, in a default preference order (OpenSSL-defined ordering).
|
||||
- **COMPLEMENTOFALL*- — (selection) suites excluded from `ALL` (currently `eNULL`).
|
||||
- **HIGH / MEDIUM / LOW*- — (selection) groups suites by effective key strength class (OpenSSL policy buckets).
|
||||
- **TLSv1.2 / TLSv1.0 / SSLv3*- — (selection) restricts to suites whose *minimum supported protocol version- is at least that value.
|
||||
- **SUITEB128 / SUITEB128ONLY / SUITEB192*- — (selection) enforces “Suite B”-style constraints: only very specific ECDHE-ECDSA-AES-GCM suites and curves/hashes.
|
||||
- **CBC*- — (mode selector) selects suites using **CBC mode*- for symmetric encryption (confidentiality only unless paired with a MAC).
|
||||
|
||||
---
|
||||
|
||||
### B) “No encryption” / “no authentication” flags
|
||||
|
||||
- **eNULL, NULL*- — **encryption/decryption: none**; **cipher method: N/A**; core idea: the record payload is not encrypted at all (plaintext).
|
||||
- **aNULL*- — **authentication: none*- (no peer authentication); **cipher method: N/A**; core idea: uses anonymous key agreement (no cert/signature), enabling MITM.
|
||||
- **ADH / AECDH*- — **authentication: none**; **cipher method: N/A**; core idea: anonymous (EC)DH establishes a shared secret but without identity binding → MITM-friendly.
|
||||
|
||||
---
|
||||
|
||||
### C) Key exchange and authentication selectors (not symmetric encryption, not MAC)
|
||||
|
||||
These describe *how keys are negotiated- and/or *how the peer is authenticated*, not whether payload is a block/stream cipher.
|
||||
|
||||
#### RSA / DH / ECDH families
|
||||
|
||||
- **kRSA, RSA*- — (key exchange) the premaster secret is sent encrypted under the server’s RSA public key (classic TLS RSA KX).
|
||||
- **aRSA, aECDSA, aDSS, aGOST, aGOST01*- — (authentication) the server identity is proven via a certificate signature scheme (RSA / ECDSA / DSA / GOST).
|
||||
- **kDHr, kDHd, kDH*- — (key exchange) *static- DH key agreement using DH certificates (obsolete/removed in newer OpenSSL).
|
||||
- **kDHE, kEDH, DH / DHE, EDH / ECDHE, EECDH / kEECDH, kECDHE, ECDH*- — (key exchange) *ephemeral- (EC)DH derives a fresh shared secret each handshake; “authenticated” variants bind it to a cert/signature.
|
||||
- **aDH*- — (authentication selector) indicates DH-authenticated suites (DH certs; also removed in newer OpenSSL).
|
||||
|
||||
#### PSK family
|
||||
|
||||
- **PSK*- — (keying model) uses a pre-shared secret as the authentication/secret basis.
|
||||
- **kPSK, kECDHEPSK, kDHEPSK, kRSAPSK*- — (key exchange) PSK combined with (EC)DHE or RSA to derive/transport session keys.
|
||||
- **aPSK*- — (authentication) PSK itself authenticates endpoints (except RSA_PSK where cert auth may be involved).
|
||||
|
||||
---
|
||||
|
||||
### D) Symmetric encryption / AEAD (this is where “block vs stream” applies)
|
||||
|
||||
#### AES family
|
||||
|
||||
- **AES128 / AES256 / AES*- — **encryption/decryption**; **block cipher**; core algorithm: AES is an SPN (substitution–permutation network) of repeated SubBytes/ShiftRows/MixColumns/AddRoundKey rounds.
|
||||
- **AESGCM*- — **both encryption + message authentication (AEAD)**; **both*- (AES block cipher used in counter mode + auth); core algorithm: encrypt with AES-CTR and authenticate with GHASH over ciphertext/AAD to produce a tag.
|
||||
- **AESCCM / AESCCM8*- — **both encryption + message authentication (AEAD)**; **both**; core algorithm: compute CBC-MAC then encrypt with CTR mode, with 16-byte vs 8-byte tag length variants.
|
||||
|
||||
#### ARIA family
|
||||
|
||||
- **ARIA128 / ARIA256 / ARIA*- — **encryption/decryption**; **block cipher**; core algorithm: ARIA is an SPN-style block cipher with byte-wise substitutions and diffusion layers across rounds.
|
||||
|
||||
#### CAMELLIA family
|
||||
|
||||
- **CAMELLIA128 / CAMELLIA256 / CAMELLIA*- — **encryption/decryption**; **block cipher**; core algorithm: Camellia is a **Feistel network*- with round functions plus extra FL/FL$^{-1}$ layers for nonlinearity and diffusion. *(Feistel: yes)*
|
||||
|
||||
#### ChaCha20
|
||||
|
||||
- **CHACHA20*- — **encryption/decryption**; **stream cipher**; core algorithm: ChaCha20 generates a keystream via repeated ARX (add-rotate-xor) quarter-rounds on a 512-bit state and XORs it with plaintext.
|
||||
|
||||
#### DES / 3DES
|
||||
|
||||
- **DES*- — **encryption/decryption**; **block cipher**; core algorithm: DES is a 16-round **Feistel network*- using expansion, S-boxes, and permutations. *(Feistel: yes)*
|
||||
- **3DES*- — **encryption/decryption**; **block cipher**; core algorithm: applies DES three times (EDE or EEE) to increase effective security while retaining the **Feistel*- DES core. *(Feistel: yes)*
|
||||
|
||||
#### RC4
|
||||
|
||||
- **RC4*- — **encryption/decryption**; **stream cipher**; core algorithm: maintains a 256-byte permutation and produces a keystream byte-by-byte that is XORed with plaintext.
|
||||
|
||||
#### RC2 / IDEA / SEED
|
||||
|
||||
- **RC2*- — **encryption/decryption**; **block cipher**; core algorithm: mixes key-dependent operations (adds, XORs, rotates) across rounds with “mix” and “mash” steps (not Feistel).
|
||||
- **IDEA*- — **encryption/decryption**; **block cipher**; core algorithm: combines modular addition, modular multiplication, and XOR in a Lai–Massey-like structure to achieve diffusion/nonlinearity (not Feistel).
|
||||
- **SEED*- — **encryption/decryption**; **block cipher**; core algorithm: a 16-round **Feistel network*- with nonlinear S-box-based round functions. *(Feistel: yes)*
|
||||
|
||||
---
|
||||
|
||||
### E) Hash / MAC / digest selectors (message authentication side)
|
||||
|
||||
These are not “ciphers” but are used for integrity/authentication (often as HMAC, PRF, signatures).
|
||||
|
||||
- **MD5*- — **message authentication component*- (typically via HMAC, historically); **cipher method: N/A**; core algorithm: iterated Merkle–Damgård hash compressing 512-bit blocks into a 128-bit digest (now considered broken for collision resistance).
|
||||
- **SHA1, SHA*- — **message authentication component*- (typically HMAC-SHA1 historically); **N/A**; core algorithm: Merkle–Damgård hash producing 160-bit output via 80-step compression (collisions known).
|
||||
- **SHA256 / SHA384*- — **message authentication component*- (HMAC / TLS PRF / signatures); **N/A**; core algorithm: SHA-2 family Merkle–Damgård hashes with different word sizes/output lengths (256-bit vs 384-bit).
|
||||
- **GOST94*- — **message authentication component*- (HMAC based on GOST R 34.11-94); **N/A**; core algorithm: builds an HMAC tag by hashing inner/outer padded key with the message using the GOST hash.
|
||||
- **GOST89MAC*- — **message authentication**; **block-cipher-based MAC (so “block” internally)**; core algorithm: computes a MAC using the GOST 28147-89 block cipher in a MAC mode (cipher-based chaining). *(Feistel internally via GOST 28147-89)*
|
||||
@@ -3,6 +3,7 @@ export default {
|
||||
"---":{
|
||||
type: 'separator'
|
||||
},
|
||||
CSE4303_E1: "Exam review",
|
||||
CSE4303_L1: "Introduction to Computer Security (Lecture 1)",
|
||||
CSE4303_L2: "Introduction to Computer Security (Lecture 2)",
|
||||
CSE4303_L3: "Introduction to Computer Security (Lecture 3)",
|
||||
|
||||
BIN
public/CSE4303/Feistel_network.png
Normal file
BIN
public/CSE4303/Feistel_network.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 38 KiB |
Reference in New Issue
Block a user