equal to parent's

ebp
● eip: return instruction pointer
○ like ra from RISC-V, MIPS
○ saved from previous frame
● sfp: stack frame pointer
○ saved ebp from parent's frame
■ ebp: base pointer
● by setting the value of eip register to
point to the payload, we can execute
our malicious code!
● Alternatively, we can set the value of
the sfp to change where the return
frame will be

Memory Layout Buffer Overflow

Stack Canary Limitations

● Canaries only protect against stack Instead of this standard
smashing attacks, not against heap layout, the location of each
section is randomized
overflows.
● Local variables, such as function Must specify a flag to
pointers and authentication flags, can randomize the text segment
but most implementations do
still be overwritten. not randomize text by default
● If the attack occurs before the end of
the function, the canary validation
does not even take place.

Address Space Layout Randomization

ASLR Executable Space Protection

● True: Even with ASLR enabled, a return-oriented programming (ROP) attack
can take advantage of existing ”gadgets”, which can often be found in the
code segment of memory. This is the definition of ROP. Albeit harder if ASLR
also randomizes the location of the code segment ● Mark certain portions of memory as
non-executable (NX)
● Entropy reduction attacks can significantly lower the efficacy of ASLR. For example, ○ For example, the stack
reducing factors are page alignment requirements (stack: 16 bytes, heap: 4096 bytes).
● Now the user can’t place shellcode
● Address space information disclosure techniques can force applications to leak known inside a buffer and execute this
addresses. ● Synonyms: W^X (Write XOR Execute),
● Like the canary defense, ASLR also does not defend against local data manipulation.
DEP (Data Execution Prevention)
● Not all applications work properly with ASLR. In Windows, some opt out via the
/DYNAMICBAS linker flag. ● False: Enabling the NX bit on stack
and heap memory pages would
prevent buffer overflow attacks.

Software Security Preconditions and Postconditions

The attacker performs a return to libc (ret2libc) by overwriting the saved return
address to execute code from libc. These protect it individually.
● StackGuard (StackCanary)
● Address Space Layout Randomization (ASLR)
● Precondition: what needs to hold for the function to operate correctly
● Postcondition: what the function promises will hold upon its return.
○ These must be expressed in a way that the person writing the code to call the function knows
how to evaluate
○ Should not involve things about the implementation of the function

● Bounds Checking ● Invariants: statements which hold at some point through the function.
○ Sort of like partial postconditions.
○ Should be able to prove the postconditions
Security Principles
● Know your threat model: What type of attacks are you scared of?
● Security is economics: Good security saves you money.
● Don't rely on security through obscurity: "they won't know" is not security.
○ Shannon's Maxim: The attacker knows the system.
○ Kerckhoff's Principle: A cryptosystem should be secure even if the attacker knows everything
except the key.
● Least privilege: Don't give more power than necessary.
● Defense in Depth: More combined defenses are stronger: two factor auth
More Security Principles
● Consider human factors: security systems must be usable (otherwise you
get tech gooblygook)
● Design in security from the start: adding security on later is harder.
● Trusted computing base: what you must trust to be secure
● Ensure complete mediation: check every access to every object,
assumptions might change later on.
● Division of trust: no single person should have all the power.
● More in slides & notes, but these are the more important ones.

IND-CPA CBC

Adversary Challenge
M r

polynomially many Ek(M)

M0, M1 IND-KPA is just

this subgame:
Ek(Mb) Choose bit b two plaintexts,
False: It is safe (IND-CPA-secure) to encrypt multiple messages in CBC mode
one ciphertext
back with a constant IV of 0, using the same encryption key each time.
M
polynomially many True or False: It is safe (IND-CPA-secure) to encrypt multiple messages in
Ek(M)
CBC mode with a constant IV of 0, as long as the encryption key is different for
Guess bit b with chance >> ½ each message sent.

CTR CTR

Which of the following are properties of CTR mode? properties of CTR mode
1. encryption can be parallelized 1. encryption can be parallelized
2. decryption can be parallelized 2. decryption can be parallelized
3. it turns a block cipher into a stream cipher 3. it turns a block cipher into a stream cipher
4. it is more secure than CBC mode
5. it provides integrity and authentication for the message

Confidentiality Diffie-Hellman
● Confidentiality: preventing adversaries from learning our private data 1. Agree on g and p in advance (can be public)
○ Data = message or document 2. Alice randomly generates a, sends ga.
● How can we achieve this? 3. Bob randomly generates b, sends gb.
○ Encryption!
4. Alice and Bob can both calculate K = gab = (ga)b = (gb)a.
○ Be careful not to leak information by sending encrypted data
5. Now they have agreed on a key K!
● Diffie-Hellman does nothing to stop man-in-the-middle.
○ Definition: man-in-the-middle is an attacker who sees all of the communication between Bob
Alice and Bob and can change the messages between Alice and Bob.
ElGamal Schemes
● Semantically secure: Like IND-CPA except for public key crypto ● H(m) is a cryptographic hash function:
● Again g and p are public. ○ one-way, second pre-image resistant, collision resistant

● KeyGen: ● E(K, M) and D(K, M) are symmetric encryption schemes

○ Generate SK randomly. ● SIGNd(M) and VERIFYn(M, S) use RSA signature algorithm with n as the
○ Calculate PK = gSK mod p. public key of the sender and d as the private key. VERIFY checks that the
● Enc(m): received signature M’ matches M when using the public key n of the sender
○ C = (gr mod p, m PKr mod p) = (c1, c2)
● MAC(K, M) is a secure MAC generation function
● Dec(C):
○ m = c1-SK c2 = (gr)-SK m PKr = (g-SK r) m (gSK r) = m

Message Authentication Codes Message Authentication Codes

● A MAC is a type of crypto object, and not a crypto object in itself ● Cryptographically secure MACs ensure the following:
○ There are various implementations ○ If a malicious party tampers with the message, the tag should be invalid
■ HMACs (Nick’s favorite) ○ Given a tag, T, that’s valid for some message M, a malicious party should be unable to find
■ UMAC another message, M’, for which T is a valid tag
■ AES-CBC-MAC ○ Should work even if a malicious party is allowed to choose messages (similar to IND-CPA)
● Using a private symmetric key, a tag is computed on a message and ● MACs provide integrity and authentication
appended to it. ○ Since an attacker is unable to forge a tag, any tampering would be noticed by the message’s
○ This tag is impossible to compute without knowing the private key recipient
● When the recipient gets the message, they recompute the tag and compare it ○ Since the computation of the tag requires the use of a private symmetric key, it’s easy to tell
who constructed a message (assuming the key doesn’t leak)
to the received tag
● MACs do not provide non-repudiation
● If the tags don’t match, the message has been tampered with
○ Providing proof to a third party is difficult, since that would necessitate sharing the private key

RSA Signatures RSA Signatures

● The RSA signature is MAC’s asymmetric counterpart
○ Messages are signed with a private key and verified with a public key
● Generating Signature
○ 2 large primes, p and q, are chosen and their product, n, is computed. n is the public key
○ From p and q, a private key, d, is derived
○ The message, M, is hashed to produce H(M)
○ The signature, S, is produced as follows: S = H(M)d mod n
● Verifying Signature
○ Received message is decrypted (if encrypted) and hashed to produce H(M)
○ If H(M) == S3 mod n, signature is correct
● RSA signatures ensure the following:
○ Even if a malicious party is allowed to choose messages to be signed, they are unable to
guess what the signature would be on a never before seen message
● RSA signatures provide integrity
○ Verifiable signatures are impossible to produce without the private key. As a result, attackers
cannot tamper with message and produce new, valid signature.
● RSA signatures provide authentication
○ Only the owner of the private key can produce verifiable signatures.
● RSA signatures provide non-repudiation
○ Proof is easy to provide to a third party, since anyone can verify a signature with the signer’s
public key