Courses/Computer Science/CPSC 526.W2015/Lecture Notes/Scribe1

From wiki.ucalgary.ca
Jump to: navigation, search

Week 1

January 14

CryptoPro asks "What is the most practical way to protect a network?"

  • Protecting a network requires a combination of people, technologies, and practices. There is no single technology we can apply to a network to achieve security.
  • When considering practicality, we need to determine:
    • the cost benefit ratio of securing the network
    • what we are most concerned about in terms of C-I-A
    • how we define a network
      • the network elements themselves, that makeup the fabric of the network (hubs, switches, routers, wires, etc.)
      • the data travelling on the network
      • the end points of the network

Security considerations:

  • It is important to consider how the traditional C-I-A translates from the physical world to a networked environment.
  • Security mechanisms involving isolation do not translate to networks.
    • There are no user IDs on the network, as IP and MAC addresses cannot be considered user IDs.
  • Random failures of networks is accounted for by redundancy; however, malicious attacks need a different kind of protection mechanism, instead of a resiliency mechanism for accidental failures.
  • Other considerations include:
    • location of adversary
    • evaluating the cost/benefit ratio (it is difficult to put a value on a network)
    • the inherent lack of trust that network presents.
  • Determining the threat is a large part of determining security.
    • Is the threat 5, 50, 5000 mathematicians, bribery, blackmail, brute force attack, etc.?
  • The primary protection problems of a network are isolation and reliability and how to ensure C-I-A of the network fabric, data within the network, and the data at the edges.

January 16

Beenz asks: "Networks are distributed. Then how do organizations such as NSA or China's censorship agency monitor these distributed networks in a centralized fashion?

  • The short answer is that it is costly.
  • It is possible, since the legal climate allows it and it is physically possible.
  • As shown in the submarine cables diagram from lecture, there are bottlenecks in the US which present lots of opportunity to tap traffic.


Types of Adversaries and Threats in Networks:

  • Alice, Bob
    • main characters trying to communicate over the network
  • Charlie
    • benign third party
  • Eve
    • passive adversary eavesdropping (sniffing packets)
  • Trudy
    • intruder who has compromised Alice or Bob’s machine with some type of malware (e.g. virus, worm, trojan)
  • Mallory
    • adversary in between Alice and Bob, intercepting packets to/from Alice/Bob
    • Mallory’s attack is not necessarily malicious (e.g proxy)
  • Trent(s)
    • at least one attacker trying to saturate the link Alice has to her ISP


Diagrams illustrating our mental image of network communication and potential threats:


Alice and Bob communicating: Alice and Bob communicating


Alice and Bob communicating: Alice and Bob communicating again


Alice and Bob communicating with Charlie: Alice and Bob with benign third party Charlie


Eavesdropping by Eve: Passive eavesdropping by Eve


Bob compromised by Trudy: Bob has been compromised by Trudy


Man-in-the-Middle attack by Mallory: Man-in-the-middle attack by Mallory


Denial of Service by single Trent: Denial of Service attack by Trent


Distributed DoS by multiple Trents: Distributed Denial of Service attack by Trents

  • Notice that there isn’t a big difference between a flash crowd i.e. lots of Bobs trying to connect to Alice and a DoS attack; too much traffic, from Bob or Trent, is too much traffic.
  • It is hard to tell the difference between legitimate and malicious traffic, so there is a problem with packet filtering based on IP addresses. And, blocking a subnet can result in blocking lots of legitimate users.
  • A problem is that the link between Alice and ISP is too small. Possible solutions include asking ISPs to rate limit a Trent or asking all traffic to do some work before connecting (e.g. TCP handshake or brute force a task). Problems again occur because not all ISPs are friendly with each other.


In class demo: demonstrating the ease of being Eve and impersonating Alice and Bob

Week 2

January 19

Cosmonaut asks: "What is NAT? What do the different types mean?"

NAT

  • NAT provides some security, as traffic cannot directly address the private IP. Routers will drop packets with non-routable IP addresses. This allows users to have a "hidden IP".
  • The real solution to running out of IPv4 address is IPv6, NAT is a placeholder.

Network Protocol Stack

  • Layer 2 - Link Layer
    • Broadcast medium semantics
    • Hub, switch, Ethernet
    • Allows for broadcasting to other users on the physical network
  • Layer 3 - Network Layer
    • "Best effort" end to end semantics between sub-networks/namespaces
    • Transfers a packet hop by hop through routers that only know the next hop
  • How fungible is the information at these layers?
    • With certain equipment and privilege, pretty much everything can be changed or controlled.

Demo: Seeing who is on airuc, packet sniffing with tcpdump, and trying to flood Prof. Locasto's machine with pings

Switches

  • Have a minor improvement in intelligence
  • Remembers the devices connected to each port to avoid collisions from flooding all ports with traffic only meant for a single device
  • If a switch is behaving properly, we shouldn't be able to view traffic from other devices connected to it
  • When we change our MAC address to look like someone else, the switch can:
    • fall over and die
    • use FCFS and deny the user
    • update the table, removing the information of the first user
    • update the table, keeping both users' information
  • When the switch table is full the switch can:
    • fall over and die
    • flush the table and start over, and in the meantime act as a hub


Demo: Build your own network


January 21

Class Activity: Labeling IP header and decoding tcpdump output of ping to 8.8.8.8 with payload 0xdeadbeef

  • Most IP packets with start with 0x45 - indicating IPv4 and a 20 byte header
  • IP ID field group fragments by giving each fragment in a set the same ID
  • ICMP is protocol 1
  • Ethernet frame header has MAC address dst (6), MAC address src (6), frame type (2)

IP Header

Important Point:

  • We don't know that the DHCP server that gives us an IP address is legitimate
  • The link layer works by plug and play and at the low level of the network, cryptography gets in the way and slows things down
  • Crypto at this level might not be necessary, if it is being used in upper layers

Demo: Continuing from January 19 - building a network and getting Alice and Bob to communicate.

  • Commands used can be found at http://pages.cpsc.ucalgary.ca/~locasto/teaching/2015/CPSC526/Winter/files/bash-history
  • Started by killing Network Manager and similar processes
  • After connecting Alice and Bob to the switch we asked ourselves:
    • How do we begin to talk to the network? Who am I? Where am I? Who is near me? How do I know?
  • Set each of Alice's and Bob's IP addresses and found that the hosts were still unreachable
    • Hosts were unreachable because the link layer dst addresses were unknown.
    • Found out Bob's MAC address by asking for it
  • The ARP table has the IP/MAC address listings.
  • Before our ICMP message was sent to Bob, a broadcast message was sent asking "Who has x IP?"
    • Bob replied with his MAC address so we could send him the ICMP
  • If the switch is behaving properly, Alice shouldn't be able to see traffic generated by Bob.
  • As seen in the routing table, there was no network gateway, so we had to specify a default gateway to connect to the network (i.e. specify the next hop)
    • This changes the dst MAC address in link layer frame headers - the dst MAC becomes the MAC address of the gateway
    • When the gateway sees that the dst IP address and its IP address don't match, the gateway forwards the packet on the gateway it thinks will get it closer to the dst.
  • Proceeded to convince the switch that Alice had Bob's MAC address
    • Nothing died after doing so, and Alice was able to ping the switch
    • The switch learned that Alice's port has the same MAC address as Bob's port
  • Convinced Bob that Alice had the same MAC address as him
    • Sent an ICMP to Bob and received a reply.
  • The switch was not confused enough for Alice to see Bob's traffic.


Commands for Alice: http://pages.cpsc.ucalgary.ca/~locasto/teaching/2015/CPSC526/Winter/files/bash-history

January 23

The lonely host asks:

  • who is near me?
  • where am I?
  • who am I? (what is my IP?)
  • who is my gateway?
  • who wants to talk to me?
  • who has Bob's name (i.e. IP address)?

Important points:

  • The user and other hosts do not have to tell the truth
  • Things that go "right" require sniffing, spoofing, and flooding
  • Hosts need to be told the above information, and it is learned from the network itself
  • All these "bad" things (sniffing, spoofing, flooding) are necessary to get the network to work:
    • Acquiring an IP address and sending ARP requests requires spoofing and flooding
    • Switches sniff in order to act differently than a hub
    • It is crucial that network elements/protocols rely on these

DHCP

  • is not meant to be secure; it is meant to have no configuration for ease of use
  • Our IP, gateway, and DHCP server come from responses to DHCP discovery messages


Demo: Turning a switch into a hub

  • Set up Alice and Bob as done in previous demo - commands to do so can be found at: http://pages.cpsc.ucalgary.ca/~locasto/teaching/2015/CPSC526/Winter/files/bash-history
  • Gave Alice Bob's MAC address and found the switch to be behaving normally (i.e. Alice couldn't see Bob ping the switch)
  • As mentioned in the last demo, the gateway is the machine we think will get us closer to the internet - we need one in order to ping Google.
  • Nothing nefarious happened after assigning Alice Bob's MAC address, and the switch was still behaving properly, preventing Alice from seeing Bob's traffic
  • We convinced the switch to fail by overloading the port, effectively turning the switch into a hub
  • After entering the command to poison the switch, there was a lot of traffic - ARP replies to non-requests (i.e. "random IP has random MAC")
  • The ARP table was cleared for both Alice and Both and Alice and Bob were then able to see each other's traffic


Week 3

January 26

Demo: Convincing Bob that Alice is his gateway

  • Started by configuring both Alice's and Bob's interfaces
    • Alice can see/connect to the web
    • Alice has two interfaces: eth1, eth0
    • Bob's packets go on eth0 and his ARP table is empty.
    • Bob cannot "get out"- the network is unreachable because he has no default roue to the internet.
      • To fix this, we defined a default gateway to convince Bob that Alice is his gateway
  • We created an ARP packet and sent it out forever to convince Bob that the gateway has a certain MAC address.
    • Both Alice and Bob can see the packets
    • The packet has the src MAC of Alice and says that Alice has the switch IP (192.168.1.1)
    • In the ARP request - src Alice MAC dst Bob MAC saying "who has 192.168.1.51 > tell 192.168.1.1"
  • Now Bob is convinced that Alice is his gateway
  • Bob got an error when he tried to ping 8.8.8.8 from 192.168.1.50 (Alice) saying "Dst Host Prohibited"
    • Alice can't be Bob's gateway unless she is prepared to act like a gateway
    • In Alice's routing table, Alice knows the next hop, but would normally only use this for her own purposes
    • We changed it so that if she receives packets on eth0, she forwards them to eth1
    • Bob is still unable to ping 8.8.8.8
  • Alice's firewall is stopping Bob's packets from flowing, so in order to act like a gateway Alice needs to change the firewall rules
  • Finally, Bob is able to ping google without error.

Important Points

  • This is not about sniffing packets - each of Bob's packets is going through Alice, so she is able to modify the contents (assuming the packets are not encrypted)
  • Cryptography is a possible solution to this problem.
  • When there is a legitimate DHCP server, it is a race between Alice and the server.
    • Bob will pick one of them. His ARP table, DHCP address will eventually time out and he'll need to ask for another address
    • Alice could convince the gateway to be quiet or route through her to solve this problem.
    • Some RFCs say that the first legitimate reply you receive is the one you should believe.


A brief look at DHCP

  • Link to tcpdump output: http://pages.cpsc.ucalgary.ca/~locasto/teaching/2015/CPSC526/Winter/files/dhcp-log
  • Standard DHCP ports:
    • Server: 67
    • Client: 68
  • We use DHCP to acquire an IP address, so the src IP of a request is 0.0.0.0
  • DHCP requests are broadcasted since we don't know the MAC/IP of the DHCP server
  • As seen in the output, when a requested IP is unavailable, the DHCP server sends to broadcast that the requested IP is unavailable and gives an available IP address.
  • When there is no request made for an IP, the DHCP server replies to the IP that is available and assigned to the user.
  • If a requested IP was available, the DHCP server would have replied to that IP and instead of broadcast.

January 28

Demo: Accessing airuc without authenticating

  • Started with standard setup for both Alice and Bob
  • After opening a browser, Alice authenticated on airuc
  • Bob is associated with some access point, but has not authenticated, so he does not have internet connectivity.
    • Bob is associated with a different access point than Alice, and is on a different subnet
    • We asked ourselves "What sort of authentication is happening? What condition is it enforcing?". It is examining something about Alice's packets to determine if she is allowed to connect to the network.
    • After changing Bob's MAC address to Alice's, he is still unable to connect. His packets are not even reaching the gateway.
    • After assuming Alice's MAC and IP addresses, Bob is able to connect.
    • Alice will receive a lot of Bob's packets and her connection will periodically reset.

Important Points

  • As noted previously, the services we think work properly, can be manipulated.
    • Assumptions are made about usage (only valid machines reply to ARP requests, no one can take my MAC/IP, etc.) that do not actually hold.
  • Calling something a security mechanism does not mean it provides security.
    • It is important to ask questions and investigate how things do and do not work - questions like "What happens when I change my IP/MAC address?"
  • Many of the basic security mechanisms rely on the integrity of identifiers (MAC, IP, binding between MAC/IP, username/password, etc.)
    • Can we trust that the the network fabric is continuously verifying the correctness of this information? Not really.
    • Security mechanisms based on string equality are easy to sidestep - e.g. firewalls.
      • Asking "Is this address within an acceptable range?" does not provide security
  • All the protocols are designed to do a specific task; they do not have the mechanisms to prevent things like spoofing

DNS

  • Machines have other names besides IP and MAC addresses.
  • DNS (Domain Name System) lets the network map names to addresses; it is another binding of information between layers
  • These bindings are stored in servers around the world; there are other servers too - it is robust in terms of availability

January 30

Important Points

  • Activities like probing a network and scanning are not inherently bad or good. They can be used by "good" and "bad" guys for various purposes.
  • Sniffing is a form of scanning - it is the same activity.
  • As a professional, we'll be asked to evaluate the quality of tools. In order to do so, we need to know the strengths and limitations of the tools and have a deep understanding of what it does.
    • For today's class we'll trying to gain that understanding about nmap
    • We ask "What does nmap do when X and why?"
  • We also need to know how vulnerable we are to the outside world. We can do this via nmap.
  • Other questions we should ask can be found in lecture notes: [1]

Demo: Using nmap

  • Have Alice and Bob connected through the hub
  • Distance between Alice and Bob: 1 hop away
  • We can ping Bob and he responds, but we don't know much else.
  • using command ">nmap -sS -sV -0 -n --reason --traceroute <IP>"
    • S is syn scan, meaning that we don't need to wait for the whole TCP handshake, we just want the SYNACK
    • Report: the host is up
      • 999 filtered ports
        • nmap scanned the most popular ports to save time; we can tell nmap to probe all ports, but that can take a while.
      • 1 result saying "I believe port 22 is open" - port 22 is usually ssh
    • nmap connects to the port and sends it some traffic to figure out the version - called "banner sniffing"
      • OSscan allows us to learn about the OS - it is not very effective when only one port replied
  • After connecting to Bob, we see all the traffic nmap generated
  • From netstat we can see that more than port 22 is active (using command ">netstat -lptun")
    • Other programs, running on localhost, will not send traffic back to Alice
    • Other ports that did not respond might not be popular ports
    • It is possible that the firewall didn't allow a response
      • By flushing the iptables on Bob's machine and rescanning, Alice gets new results
  • We were able to gain root access to Bob's machine through port 22, as older versions of SSH permit root login

Class Activity: see today's lecture notes, linked above

Week 4

February 2

Class Activity: Decode a message

Cryptography Introduction

  • Cryptography can help us accomplish
    • Confidentiality - keeping a message secret
    • Integrity - keeping a message intact
    • Authentication - verifying identity of a principal
  • Plaintext - a message in its original form
  • Ciphertext - an encoded message
  • Encode/decode, encipher/decipher - manipulating and translating information from one set of symbols to another
  • There are a few different types of attacks:
    • Ciphertext only attack
      • The adversary only has the ciphertext.
      • They can enumerate all the keys and try and decrypt the ciphertext, but they must be able to recognize the correct plaintext
    • Known plaintext attack
      • The adversary knows some <plaintext,ciphertext> pairs
      • They can try and analyze the pairs and determine what the pairs say about the key
    • Chosen plaintext attack
      • The adversary treats the system as an oracle
      • The goal is to decrypt Alice's previous ciphertext by supplying what Eve hopes is similar content
      • This attack is easier with a smaller message space

Important Points

  • Cryptography allows participants to encode information and the only people who can decode the information are those privy to the encoding mechanism
  • There are lots of bad approaches to adding cryptography to a system
    • The purpose of cryptography is to prevent someone from understanding your transformation and recovering this information. This is difficult, even more so if the adversary has a computer.
    • We should not develop our own algorithms, as there is only a narrow set of algorithms capable of the above.
  • The security of the transformation shouldn't rely on the secrecy of the algorithm, but instead a private key
  • Algorithms should be public so they can be scrutinized
  • Algorithms should be easy to compute, but difficult to reverse
  • The adversary is assumed to have the ciphertext; it is important to remember that the adversary can always attempt to recover the key by brute force.

February 4

Reading: Chapters 2 - 4

Class Activity: Decode a message

  • UTYNCXOPADECDSQ
    • Ciphertext generated using one time pad
    • Plaintext is XOR'd with a one time key of equal length
  • Monday's ciphertext was susceptible to analysis, whereas this ciphertext is difficult (impossible) to analyze.
    • The difference in difficulty brings up design questions:
      • What is fundamentally different between the two encryption algorithms?
      • How can we design encryption techniques we can believe in?
      • Is there a principled/structured approach to crypto algorithm design?

Algorithm Design

  • As discussed last class, it is better to design a few strong public algorithms than many secret ones
  • OTP seems like the perfect encryption scheme; it is simple and fast to encrypt and decrypt text.
    • However, it is difficult to do i the sense of synchronization and keystream distribution/protection.

Block Cipher Design

  • Block ciphers operate on a fixed size set of bits (blocks)
  • Input is a block of plaintext (e.g. 64 bit) and a fixed length key (e.g. 56 bit)
  • Output is a block of ciphertext
  • Conceptually, it is a one to one mapping from plaintext to ciphertext for decryption.
  • The key size has some intuitive relationship to the difficulty of brute force attacks.
  • Blocks that are too short are subject to translation table attacks.
  • Keys that are too short are subject to easy brute for attacks.

Important Points

  • We probably don't need 512 bit keys
  • We can't use space to solve the problem, so we need to write a procedure for the plaintext/ciphertext mapping.
  • The procedure is deterministic, but appears random and is driven by the key.
  • Given <plaintext,ciphertext> pairs, the adversary should not be able to gain information about the key
  • If we change the input by 1 bit, we should get an entirely different output (half the output has been affected)
  • Confusion, Diffusion, Substitution, Permutation
    • Confusion: The bits that are flipped should be uncorrelated
    • Diffusion: Effect of a single bit flip in the output
    • Substitution: Substitutes bits according to a table
    • Permutation: Permutes/transposes bits
  • Feistel Networks use substitution and permutation in each of the rounds
    • Distorts the output enough so it is hard to say that the Xth output bit is dependent upon the Yth input bit

February 6

Class activity: Perform 1 round of Feistel network

  • f(): +1, bitwise AND with subkey
  • plaintext: 0xF5 (11110101)
  • key: 0x1A (00011010)
  • subkey: if (i % 2 == 0) right nibble, else left nibble
    • i starts at 1
  • Question: Where do bits 3 and 6 of the plaintext wind up? What are their values?

Feistel Network


Motivation for lecture: What happens if we have a plaintext larger than a single block?

Cipher Modes

  • ECB - Electronic Code Book
    • Pads last block; encrypts each block individually; concatenates ciphertext blocks together
    • Duplicate plaintext blocks results in duplicate ciphertext blocks.
    • Integrity is not preserved. Blocks can be rearranged, modified, and snipped and decryption won't detect the change
  • CBC - Cipher Block Chaining
    • Breaks mapping between identical blocks
    • Conceptually, it introduces randomness to each ciphertext block
    • Takes previous ciphertext block and XORs with next plaintext
    • A random number, called initialization vector, is used for first operation
    • The IV is transmitted along with data
    • An attacker can still modify messages
    • Requires a random IV for each message and you cannot start decryption in the middle of a message
  • OFB - Output Feedback Mode
    • Produces an OTP
      • Uses random IV that is the same length as the block size
      • Encrypts the IV with the secret key b0
      • Repeat bi+1 = Enc(bi,K)
      • OTP = b0|b1|b2|...|bn
    • Encrypts message by XOR
    • IV/OTP generate can occur offline
    • Encryption and decryption are simple/fast
    • Bit level garbling instead of block level
    • If an adversary has some <plaintext, ciphertext> pairs, they can easily produce a new message
  • CFB - Cipher Feedback Mode
    • Constructs OTP with plaintext consideration
    • Pg 103 of textbook
  • CTR - Counter Mode
    • OTP is produced by incrementing IV
    • Decryption can start at any offset

Week 5

February 9

UNIX Passwords

  • passwords are stored in etc/passwd and etc/shadow
  • format: <username>:<encrypted password>
    • At the beginning of the encrypted password, the salt and hash alg are given
    • Salt is a character string chosen to perturb the hash algorithm in many ways


Hash Functions

  • Even though some cipherblock modes garble plaintext, the machine doesn't recognize when some bit has been flipped.
    • How do we protect against this manipulation?
  • We care about integrity, with or without confidentiality
  • Problems (non-adversarial) with storage, processing, and transmission occur because hardware isn't perfect
  • Adversary can also intelligently flip bits, along with the benign world.
  • Alice creates [message|summary] and Bob can strip off the summary and recalculate the summary from the message to see if integrity has been preserverd.
    • Can do this with a single parity bit
    • Can have the summary be a character checksum
    • Can make summary = message
    • We need a way to shorten the message and have a one-way function i.e. it is easy to compute, but difficult to reverse.
  • Using hash functions alone does not solve our integrity problem.

Hash Function Design

  • Can use symmetric key cryptography, but the block size is too small
  • Hash is entirely input driven, even when given a "key"
  • Chapter 5 in the textbook gives common hash algs implementation/design
  • A digest is not a signature (signature is a transformation of something likely to be a digest)

Hash Functions for Authentication

  • Using a pre-established secret, Alice and Bob can authenticate to each other
    • Alice sends random number Ra to Bob
    • Bob calculates MD1 = hash(key|Ra) and sends MD1 and a random number Rb to Alice
    • Alice checks MD1 and sends MD2 = hash(key|Rb) to Bob
    • Bob checks MD2
  • An adversary cannot derive the key from the hash values and the key never goes over the wire.

Message Authentication Codes (MAC)

  • For integrity
  • MAC = hash(key|msg) and Alice sends [msg|MAC] to Bob
    • This is vulnerable to length extension
    • The hash is likely splitting input into chunks, so the output is a summary of the message up to that point.
    • Someone can add onto the message by msg|padding|newmessage because the initial state of the hash is already known (output of hash)
  • Instead we can use HMAC (hash based MAC)

February 11

Guest speaker: Doug Madory

February 13

Readings: section 4.3 and chapter 5

Salamander asks: "How useful is the so-called "Christmas Tree" scan?"

  • It is an nmap scan option and sets the FIN, URG, and PSH flags so that the packet is lit up light a Christmas tree.
  • It is used to determine if a port is open/closed.
  • Can easily be detected
  • Since not all systems follow the RFC, there can be a false assertion that a port is closed because it did not return a RST.
  • See for more information: http://nmap.org/book/man-port-scanning-techniques.html

Class Activity

  • How can Alice and Bob confirm they have the same information without divulging the information?
  • Alice and Bob both think they know who is getting fired. How can they confirm they are thinking of the same person?
    • One way is for Alice to change her UNIX password to her guess and have Bob attempt to log in.
    • If Bob is able to log in, then they have confirmed they are talking about the same person
    • If Bob is unable to log in, they know they are talking about different people without saying who each person is talking about.

Properties and Uses of Hashes

  • We can use a hash algorithm to check the integrity of programs and/or data on a hard disk.
    • We take the hash of sensitive text to ensure that sensitive configuration hasn't been changed
  • Pre-image resistance
  • Second pre-image resistance

Hashcash

  • Hashcash is used to fight email spam
  • Non-interactive - clients can safely precompute messages
  • Publicly auditable - anyone can verify
  • The goal of hashcash is to ensure the message recipient that the sender has spent a certain number of CPU cycles generating the message
    • Emails are cheap to produce, but expensive to process (by humans)
    • We want to force spammers to do work before sending emails
  • Uses the fact that hashes are costly to brute force and easy to check
  • The sender is asked to find a value X such that (e.g.) H(x) results in the first 10 bits being 0

Week 6 - Reading Week

Week 7

February 23

Reading: chapter 6

Public Key Cryptography

  • Thus far, protected communication has required a shared secret
  • Hash algorithms have this notion of a one-way transformation of information
  • Public key encryption allows for encryption, decryption, signing and verifying signatures, establishing shared secrets
  • Can we communicate without a shared secret? Why would we want to?
    • Yes. The main challenge of secret key cryptography is key distribution, especially when using a OTP. Public key cryptography allows for protected communication without the problem of secret key distribution.
  • Public key cryptography has two keys that form a key pair - a shared public key and a confidential private key.
  • Diffie-Hellman key exchange has no authentication; Mallory can be in the middle of Alice and Bob doing the protocol with each Alice and Bob.
  • Key pairs can be generated using java keytool, openssl(1), ssh-keygen
  • With the introduction of modular arithmetic and additive/multiplicative inverses, we can see how public key cryptography is possible.


February 25

RSA and Public Key Cryptography

  • Main takeaway from lecture: public key cryptography is a significant shift in the cryptographic manipulation of data; it gives new functionality.

RSA

  • RSA is ubiquitous; it is seen in a lot of pieces of security ecosystem
  • an example of a public key cryptosystem
  • used for encryption, decryption, signing and verifying signatures
  • straightforward to understand
  • RSA and public key cryptosystems give new capabilities like key distribution and digital signatures

PKC

  • Public key cryptography represents a significant shift in how cryptosystems are designed.
  • Symmetric key cryptography and some hash algorithms (DES, MD2-5,SHA) are just substitutions and permutations - it is not math, but instead an arbitrary mapping relation.
  • Public key crypto represents a transition from subs/perms to math
    • Encoding is based on hard mathematical problems (discrete log problem, integer factorization)
    • This allows for more analysis and confidence in the security of the system
  • Symmetric key crypto is not made obsolete by public key crypto
    • Symmetric key is faster and both symmetric and public key crypto require systems
    • We cannot make the argument that public key is more secure than symmetric key; neither approach is inherently more secure than the other

Diffie-Hellman and Properties of a PKC system

  • Protocol and properties:
    • Bob generates a key pair
    • Alice encrypts a message with key1 and sends it to Bob
    • Bob decrypts Alice's message with key2
    • An adversary knowing key1 cannot derive key2
    • An adversary knowing key1 and ciphertext cannot recover plaintext
  • Asymmetric key cryptography has related keys and given knowledge of algorithm and encryption key does not make it computationally feasible to find decryption key
  • This is possible because of modular arithmetic - we're restricted to a domain of numbers
    • E.g. E3(8) = 8+3 mod 10 = 1
    • D7(1) = 1+7 mod 10 = 8
    • 3 and 7 are additive inverses mod 10

RSA Algorithm

  • Key pair: [public key: <e,n>, private key: <d,n>]
  • Plaintext and ciphertext are integers between 0 and n-1
  • C = M^e mod n and M = C^d = M^ed mod n
  • e and d are multiplicative inverses mod phi(n), where phi(n) is Euler's totient function
    • phi(n) = count of numbers relatively prime to n
    • given n = p * q, with p and q being prime numbers, phi(n) = phi(p)*phi(q) = (p-1)(q-1)
  • e and n are public
  • p, q, d are private
  • n and d are calculated, e, p, and q are chosen
  • e is chosen such that 1 < e < phi(n) and gcd(phi(n),e) = 1 i.e. they are relatively prime


February 27

Class Activity: breaking an instance of RSA

  • public key <e,n> = <7,187>
  • private key <d,n> = <?,187>
  • ciphertext = 153
  • Task: decrypt ciphertext and find the private key
    • Can find prime factors of n = 17 * 11
    • calculate phi(n) = phi(17) * phi(11) = (17-1)(11-1) = 160
    • d = 23
    • plaintext = 153
  • We don't need the private key to break the plaintext - we can always use brute force

Challenges with RSA

  • computers have trouble when the numbers used are very large (slow to calculate, extremely slow to brute force)
  • certain operations are slow, so we can choose e to be small so encryption is quicker
    • decryption and signing certificates is quite slow
  • RSA is not a replacement for symmetric key cryptography.
  • cannot establish a shared secret with RSA

Diffie-Hellman

  • Allows use to establish a shared secret/key that can be used in symmetric key cryptography
    • DH and RSA are very useful, so they are used in our real-life secure network communications
  • Preestablishes p and g, where g is a primitive root of p, and random numbers for each Alice and Bob


Week 8

March 2

Midterm Review/Information

  • Some multiple choice and short answer questions
  • Preparation should include looking at review questions from textbook
  • Possible topics
    • Basic network protocols (IP, TCP, ICMP)
    • Symmetric key cryptography
      • DES structure and operation
      • Design principles, core operation, properties, possible generic attacks
        • Significance of block and key size
      • Know fiestel network and be able to compute some rounds of it
      • Block ciphers
        • Modes (CBC, ECB, CFB, OFB, CTR)
          • Error propagation in each
    • Public key cryptography
      • Properties, new things we can accomplish with PKC,
      • RSA
        • Elements of breaking RSA
        • Know double digit prime numbers
    • Network utilities and tools and what they're used for
    • Packet analysis knowledge, scanning
      • Given some hex, identify field(s) in packet header (TCP, ICMP, IP)
    • Authentication concepts
      • Processes like UNIX password system
      • Given an authentication system, answer questions about security guarantees and how security is established
    • Firewalls
      • General knowledge, chapter 23 in textbook
      • Given firewall rules, what happens to a certain packet

March 4

Guest Speaker: Calgary Police Service

March 6

Internet Worms

  • Appreciation of how worms spread
    • Theoretical vs actual spreading
  • Networks are not just the connection between machines
    • It is also the shared state distributed throughout the network
  • Focus on control of nodes and threats to availability of worms

Worms

  • Worms are a program
    • They spread through a network by exploiting vulnerabilities in services on host machine
  • Threat is that you don’t have complete control over resources - loss of control infrastructure
  • Can be so aggressive there is an availability concern - the network connection can be easily overwhelmed by attempting to spread to new hosts
    • This can occur within the core of a network or at the edges
  • Payload can threaten confidentiality and integrity

History

  • Morris worm in 1988
    • First real security instance
    • There was a great deal of trust up until this point - little bug elimination before the Morris worm
    • Multiple infection vectors, hiding itself, maintained privileges, priority scheduling, cracked passwords
    • Complex piece of code/malware
    • Spread by buffer overflow in finger daemon and by a backdoor in sendmail (setting debug flag)
      • Finger command allows you to learn about UNIX users either locally or remotely
    • Spawned many processes
      • Had a noticeable effect on the stability of the internet
    • Drove home that passwords need to be better protected, authentication needs to be a thing for remote login, and no more plaintext transmission
    • CERT was formed
    • Discussion of keeping worm code secret
    • Discussion of terminology (worm vs virus) - back then they had to decide what it was, as worms were used in distributed computing without malicious intent
  • Code Red in 2000
    • Machines on network can attack each other in unsupervised fashion
    • Targeted Microsoft IIS (webserver) with vulnerability
    • 359,000 hosts infected
    • Interesting: Code Red was so prevalent it became a good way to check for a server on port 80
    • Network services attacked based on vulnerabilities
    • Only 60% of susceptible hosts were infected
  • Nimbda - email
  • Sasser - file sharing and name lookup from Microsoft
  • Witty - security products are no exception - suite of products had a bug that was exploited
  • SQL Slammer - no malicious payload
    • Only took 10 minutes to infect susceptible population
    • Targeted service that shouldn't have been open to the world (port 1434)
    • Within 30 minutes, it started interfering with its own propagation
    • No malicious payload - could be interpreted as a warning

Worm Propagation

  • Sequential, randomized, spreading evenly, provided initial hit list?
  • Can reverse engineer worms to blame people once we learn how they spread
  • Can we block suspected worm traffic based on spreading characteristics

Two factor worm model

  • Factors affecting worm speed
    • Dynamic human countermeasure
      • Firewall updates, antivirus scanning, machine is shut down/disconnected
    • Interference due to aggressive scanning
    • The rate of infection is not constant
  • Explains exponential start and end drop off


Week 9

March 9

Midterm Exam

March 11

Midterm Review and mid-semester check-in

Web Security

  • The web is complex - many components of something as simple as a web page
  • Different web servers for different purposes - requests, back end, load balancing
    • Retrieving and storing data is complex
  • HTTP is a static request/response protocol
    • It is a complex task to write code to accept all valid machine names given the many ways we can encode these names
    • Browser is executing code someone else gave it
    • Should be a concerning exchange from a security perspective
  • Nothing stopping a client from specifying a negative content length which might be interpreted as a large unsigned number by the server - servers can detect this and reject the request
  • We know HTTP is broken, so we sprinkle random security dust on it, like password based authentication
    • E.g. A2 Web server authentication
    • It is not encrypted, as it is using port 80, and the "authentication" is encoded in Base64

Other Concerns

  • Confidentiality and integrity of web transactions
  • Privacy concerns
  • Uniqueness of browser - without cookies and tracking, websites can fingerprint you (screen size, time zone, color depth, plug-ins)

Web App Threats

  • OWASP fights against these threats
  • Web development is hard to learn, easy to practice, and tough to secure
  • The top threats don’t change that much because people consistently get it wrong


March 13

Guest lecture: Govind

XSS

  • Cross-site scripting
  • Is an "html injection" and exploits a user input field
  • Injection of arbitrary javascript
  • One attack is to redirect user to a phishing site
  • Attacker can get the cookies of logged in users
  • Can be defended against by preventing back-end from interpreting input as html

CSRF

  • Cross-site request forgery
  • A malicious website posts to another
  • While a user is logged into one website, if a user logs into another, the latter site can post the first site to gain information about the user
  • Possible solution is to add a session hash for all users and have a hidden form value that requires that hash.
    • Can't store in cookies, as cookies can be obtained from this attack

SQL Injections

  • Insert SQL commands into input fields in a database application (e.g. inputting username as ' OR 1=1)
    • A solution is to escape quoting characters from the input string
      • Filters are band-aids over an inherently bad approach.
      • The task of safely recognizing a string of the language is challenging
  • A field requesting an integer can still be violated, since the input is interpreted as a string
    • A possible solution is to enforce the data type of the field
      • Problems with this arise as it is relying on the developer to be perfect
  • Question: Why is type checking left to the developer?
    • Parsing is hard and parsers are usually riddled with bugs. It is less secure to have a variety of (most likely buggy) parsers than just one (hopefully less buggy ) parser interpreting everything as a string

Week 10

March 16

Readings: chapter 9 and 10

Authentication

  • Goal is to order content of messages to convince each party the channel is protected by integrity preserving mechanisms and that the involved parties are who they claim to be
  • Motivating question: "Halt who goes there"
    • We want a system that allows parties to ask each other this
  • Authentication and authorization are two separate ideas
    • Authenticated users should not automatically become authorized users
  • Network security is not just about the pipes - it is about the logic at the network end points
    • There is a lot more complexity added and a lot more room for error with added guarantee/security

Definitions

  • Authentication
    • Primary means of providing mediated access to a resource
  • Principal
    • Offers some credential to a authenticating process (some entity in a system)
  • Credential
    • Includes some identifier and some secret token - not necessarily a username and password

Consideration

  • Authentication is establishment of a fact
  • It does not mean that once you're authenticated, the system is secure (recall that authentication =/= authorization)
  • The design principle - mediated access - ensures that an action a principal is about to take is a safe action
  • Is authentication continuous?
    • Short answer: Probably not.
    • A server, Bob, is not continuously asking for a user's, Alice's, password.
    • There is a one-time authentication combined with the notion of a session, where the user is authenticated for the duration of the session
    • An intruder can hijack the connection without a password
    • The guarantee from authentication is assumed to last for some period of time
    • TOCTTOU - Time of Check to Time of Use
  • Is authentication complete? (i.e. what is proof of identity)
    • Is the information offered to prove identity sufficient?
    • This is a separate question from "Is this user allowed to action X; what are they allowed to do?"
  • Who are you?
    • The answers to this, in the security community are often:
      • Something you have
        • Token or dongle
      • Something you know
        • PIN or password
      • Something you are
        • Biometrics e.g. fingerprints
    • None of these are the answer to the question though; they are simply a stand-in
    • An attacker can beat the password out of Alice, mug Alice, or obtain her fingers/fingerprints and then "become" Alice
    • A possible solution is two-factor authentication, where a combination of the above methods are used for authentication

Approaches

  • Simple (no security guarantees) to very complex (high security guarantees)
    • Identity based (IP address) --> Password based --> Challenge response --> Multiparty authentication and authorization
  • HTTP basic authentication
    • Username and password supplied in plaintext http response
    • No integrity and the transformation of credentials is reversible
    • Subject to recording, replay attacks, and modification
    • It is basic and provides the least amount of security (no security guarantee)
    • Is it better to authenticate with a shared secret?

Challenge-Response Authentication

  • A shared secret can be established by key distribution, offline exchange, or Diffie-Hellman
  • Threats
    • Guessing the shared secret
      • An adversary should not be able to use challenge and response to derive the secret
    • Eavesdropping (on the wire - online attack, on the master password database -offline)
  • Exchange E.g.
    • Alice: "Hello Bob - this is Alice and I'm logging in"
    • Bob: "Prove it using this random number R"
    • Alice: " x = sign(Alice(private key), R) "
    • Bob: " x' = verify(Alice(public key), x); verified if x = x' "
  • Problems arise with the above exchange if R is not random - as it reveals information for an attacker to reply to future challenges
  • In the above exchange, Bob did not authenticate to Alice
  • Basic Challenge-Response E.g. where Alice and Bob have shared secret K
    • Alice: "Hello"
    • Bob: "Challenge: R"
    • Alice: "f(K,R)"

More Considerations

  • Key establishment
  • Eaves dropping
  • Stealing K from either Alice or Bob
  • Guessing K
  • Session keys and nonces
  • Sources of randomness
    • Computers are not good at producing truly random data
  • CAs and PKIs
  • Function f
    • If using symmetric key crypto, adversary can obtain K(R) easily
    • Need symmetric key capability
    • If R includes timestamp, then Alice knows "Bob" is Bob
      • Issues arise with clock synchronization and message reuse/replay
    • Only one way authentication


March 18

Readings: chapter 9, 10, 11

Remarks

  • Lab 1
    • Just because the hashes match and the bytes made it across the internet safely, does not mean the bytes are benign
  • Lab 2
    • Private communication over the Internet is possible

Q(s)otD:

  • 1. Short answer: No. It is a best effort delivery mechanism based on trust. There is no guarantee of anything. The goal is to provide a resilient communication fabric; if we want secure communication, we'll have to do it ourselves.
  • 2. NSF is trying with a project that provides a safer more secure version of the internet with end-to-end encryption. That internet probably won't get off the ground, so those ideas will have to be integrated into the existing internet.
  • 3. Setting up a VPN is a possible solution.
  • 4.

Motivation

  • We are seeking to understand the kind of security we can get out of the current internet
  • Operating under the assumption that attackers are ubiquitous, the design requirements for authentication protocols are:
    • Initiator/repsonder identity verification
    • Resistance to replay attacks
    • (Re)establishment of a session key
    • Protect the confidentiality and integrity of the exchange
    • Resistance to hijacking and DOS
    • Perfect forward secrecy
    • Deals with human inability to memorize large numbers

Protocol

  • Sample authentication:
    • Alice: telnet bob.com, uname = Alice
    • Bob: Password?
    • Alice: 123456
    • Bob: Welcome back, MotD, $
    • Alice: ls
    • Alice: ...
    • Alice: exit
  • Threat: everything is in plaintext; there is no confidentiality
  • Threat: connection is subject to hijacking
  • A more complicated authentication protocol is likely needed
    • One that not only authenticates Alice and Bob, but has a session key

Session Keys

  • Protect Confidentiality and Integrity of communication
  • Public key cryptography is slower than symmetric key cryptography
    • Public key cryptography keys are being "exposed" by constantly using them
    • They are high value secrets that should be kept hidden
  • Problems arise with long term shared secrets
    • Adversary can build up a large amount of ciphertext over a period of time
    • Someone listening has many valid prior messages
    • Disclosure of secret would result in the decryption of all prior messages
  • Session keys can be given to untrusted system components
  • Keys are easy/not taxing to generate

Protocol 11.2 of Textbook

  • We analyse the protocol by asking "Who knows What When?"
  • There is a lot of computation; it is easy to intentionally or unintentionally result in DOS
  • Both protocols result in additional, and most likely unintended, functionality
    • In the first protocol, Bob can get Alice to sign any message R
    • In the second protocol, Alice is acting like a decryption service

March 20

Reading: chapter 10, 11, 12

QotD: What is scapyhunt?

  • It is a network treasure hunt
  • The goal is to find and extract a file from an FTP server by traversing the network infrastructure, using tools we have learned about in class

Replay attacks

  • Anything put on the wire can be used later; just because it is encrypted, does not make the bytes exempt from being replayed
  • As such, we need to be thoughtful about what we put on the wire - the format and structure of the data (ensuring it has some non-replayable value)

Textbook pg 64 11.2:1

Password Based Authentication

  • Authentication is hard to get right
  • We disclose passwords to the server, which can be susceptible to offline dictionary attacks
  • As passwords have hit a design sweet spot, they will not be disappearing anytime soon, so we must thing of ways to improve them
  • Password breaches are very common
  • "Better" password authentication
    • Lamport's Hash
      • Protecting against server database reading and replay attacks
      • Lamport's hash supports a finite number of one time passwords
        • Assumes the existence of a strong hash
        • User has a secret X
        • The host calculates F^1000(X)
        • User authenticates with F^999(X)
        • Server does verification by hashing F^999(X) to get F^1000(X) and stores F^999(X) as the new password
      • A salt would be important here so that users do not have the same F^1000(X)
      • There is no mutual authentication
      • Subject to small n attack

Bellovin-Merritt

  • Provides encrypted key exchange

Establishing Authentication and Session Keys

  • Key Distribution Centre
    • Concept: Trusted intermediary (Trust Third Party - TTP)
    • Sharing symmetric keys is a n^2 proposition
    • Wide-mouth frog or KDC store and generate key pairs, so Alice and Bob only need one shared secret with the KDC
    • For an exchange between Alice and Bob, the KDC will invent a session key
    • The KDC will give a ticket to Alice to convince Bob that Alice is legitimate

Week 11

March 23

Key signing party

March 25

Readings: chapter 20, 21, 22

QotD: How do we alter someone's email

Motivation

  • We ask: “Where do we put security?”
    • That is, where do we place security in the system and network stack
  • Given the variety of threats where, in the system, is the right place to put crypto code or security such that the user doesn't have to think about it
  • We can put it in the different layers of the network stack so the OS does not need to worry about it
    • Network layer – IPsec
    • Transport layer – SSL/TTS
    • Application layer – SSH
  • There is no right answer, as there are tradeoffs with every solution

SMTP

  • Stands for “Simple Mail Transfer Protocol”
    • Store and forward model
  • Alice hands off an email to some number of SMTP machines for it to reach Bob
    • Mail client/user agent sends the message to a series of MTAs (Message Transfer Agent)
  • Multiple servers are involved, which are out of the control of Alice and Bob – we really don't know the full path between peers
  • Typically runs on port 25 for localhost for local mail delivery
  • The email headers are evidence that the mail servers have played with the content of your mail messages
    • There is no guarantee they didn't change anything else other than adding routing information to the header

Considerations

  • Confidentiality, Integrity, Authentication
  • DoS
  • Rewriting message
  • Snooping/sniffing messages in transit/at rest
  • Authentication of senders? Recipients?
  • Sender anonymity
  • Traffic analysis (did it send a message to Bob)
  • “Business” concerns: recall, return receipt

End-to-End Content Security

  • Either we can throw out the insecure SMTP and start new, or we can work with the existing implementations and deployments
  • PEM
    • Privacy Enhanced Email
    • Confidentialilty, source authentication, and text integrity
    • Symmetric or asymmentric
    • Uses rigid heirarchy of CAs for key distribution
    • Offers different security options
      • Cleartext
      • Integrity-protected cleartext
      • Integrity-protected encoded data
      • Encrypted, integrity protected data, encoded
  • S/MIME
    • Secure MIME
    • Adapted from PEM and used for MIME regime
    • Assumes disconnected set of federated CAs for key distribution
  • PGP
    • Pretty good privacy
    • Web of trust, public key cryptography
    • Uses web-of-trust for key distribution
  • Base 64 Encoding
    • Maps arbitrary data into a small set of characters
    • A way to get around servers playing with the message content

March 27

Motivation

  • Email security – infrastructure and anti-spam
  • How can servers know to drop ilegitimate messages?
  • Is therea better way to filter out messages from people hijacking a domain or inserting the message in transit?

Countermeasures

  • There are ways to label messages – DKIM and SPF – where the receiving domain (not MTA) verified the label
    • Aids in filtering spam or unauthorized use, but not a direct label of “spam”
  • SPF
    • Sender Policy Framework
    • The point: if another machine was asked to send the email and was not in the whitelist for a particular domain, the recipient could mark it, delay it, or do something else with it
    • How does it know a permitted address?
      • A SPF record is a type of Domain Name, whose purpose is to combat people spoofing addresses
  • DKIM
    • Domain Keys Identified Mail
    • Similar insight to SPF – asks “Is there a way to validate the content of the mail without PGP or a way to see if the content has been mangled in transit?”
    • The content is signed
    • Allows for verification from recipient of sending organization
    • Abusing DNS much the same way by storing public keys
    • Authentication results header includes results for DKIM and SPF

Week 12

March 30

QotD

  • Essentially, no, unless you can you can talk to your system administrator or PKI

Motivation

  • Question: Where is the correct place to put security mehcanisms in the system and network stack?
    • We can conceive of putting RSA, AES, SHA into the network stack, but we have to consider the tradeoffs when gaining confidentiality
  • Is putting PGP on everything the answer? Removing bugs from SSL, or putting security in Layer 3, or in the OS kernel?
  • Application Layer: PEM, S/MIME, PGP, SSH
  • Transport Layer: SSL and TLS
  • Network Layer: IPsec
  • PGP guarantees end-to-end security, but that comes with increased user difficulty
    • Users are exposed to the difficulties of crypto, where as, if security is placed in the kernel, the user is fairly unaware of the process

SSH

  • It is potentially the way to do things
  • We have a pile of software that no one wants to rewrite which has no security, but is still very useful. The amount of effort required to add security is high
  • We can provide security by tunneling the software through another process – such as SSH
  • We can rely on one piece of software and don't have to worry about the quality of developers for other software
  • SSH is at the user level, so there is not an invasive change to the system
  • Provides authentication, encryption, integrity, mutual authentication, and some authorization
  • Not subject to standard set of attacks
  • Comes from the fact that before SSH, there was no secure means of authenticating to remote services
    • Replaces tools like telnet and r-toolst that have no encryption and weak authentication

SSH History

  • Developed after passwords were sniffed on the network (1995)
  • OpenBSD tookk over an early version and created openssh

Services

  • SSH – Secure replacement for telnet
  • SFTP – Secure FTP, a protocol on top of SSH for file transfer
  • SCP – syntax close to cp with no session

Tunneling

  • Alice and Bob want to communicate via an application that doesn't have encryption – SSH forwarding is an option
  • We have protected a protocol, without cryptography, by using SSH as a blackbox

SSH-2

  • Three sub protocols: SSH transport layer protocol, SSH authentication protocol, SSH connection protocol
  • Authentication and connection are at the same “level”
  • Layered on SSH TRANS
    • port forwarding, X11 forwarding, compression, multiple sessions over 1 connection
  • Use SSH AUTH over SSH TRANS to authenticate (using public key, password, or host based)
    • Two major forms of authentication – password based and public key based
    • A really nice way of breaking into machines via SSH is guessing username/password combinations
      • This can be avoided by disabling password based authentication
    • Host based authentication still uses public key authentication

SSH attacks and bugs

  • SSH-1 CRC attack
    • Active insertion attack – can insert arbitrary commands to the server
    • CRC is not a cryptographically strong integrity check
  • SSH runs over TCP/IP
    • Vulnerable to DoS
    • Bogus control/routing packets can be injected
    • Password guessing (common attack)
    • Does not address traffic analysis (traffic/communication patterns and can discern who someone is talking to)
    • Not a panacea, as it does not fix all security problems

Important point

  • Protecting your private key is very important, as anyone with your private key can be you
  • We need to be thoughtful of where we keep our private key, how we generate it, and where we copy it to, etc.

April 1

Class warm up: Find the bug

  • First example: Possible integer overflow
  • Second example: Not random when x = 0

Snake oil

  • Anyone can create crypto that they cannot break
  • Snake oil was marketed as a panacea - it promised results it couldn't deliver

Warning signs of poor crypto

  • Claims to use "new" math
    • Crypto that is based on a breakthrough in math
  • Proprietary cryptography
    • Claims to have great secret sauce
    • There is no legitimate reason not to examine implementation
  • Extreme cluelessness
    • Claims that new implementation is better than everything else
  • Ridiculous key length
    • We don't need a keylength of 1,000,000,000 bits
  • One time pads
  • Unsubstantiated warning signs
  • Security proofs
  • Cracking contests

Aimencrypt

  • Says that they can generate a certificate for you; you can get the aimencrypt certificate and communicate privately with your friends
  • Everyone gets the same certificate and is using the same credentials, so there is no security provided

Debain Openssl PRNG

  • Commenting out two lines of code destroyed source of entropy, so there were only 32767 choices for output of PRNG
  • Code was commented out to try and fix a memory leak bug

Heartbleed

  • Allows a client to grab arbitrary memory contents from the server
  • Caused by implementation error not weakness in SSL
  • RFC is correct, but implementation is easy to get wrong
    • Instead of responding to with random junk, the server replied with legitimate data

OpenBSD IPsec backdoor

  • Allegations saying FBI paid to put in a backdoor in IPsec stack
  • Since it was the first public implementation, it was copied
    • OpenBSD is also prevalent in embedded systems
  • The code was audited and bugs, unrelated to a backdoor, were found

Important points

  • We can look at code, but security bugs tend to be very subtle
  • After finding some bugs, how do you know your job is done?
  • Wrting secure software requires ongoing peer review

April 3

No lecture: Good Friday

Week 13

April 6

Class activity: Looking at broken security example

Protocol 1

  • Anyone can encrypt a widely known number with Bob's public key
  • Totally useless as it does not provide authentication


Protocol 2

  • Subject to eavesdropping and replay attack
  • Easy to collect legitimate responses
  • Alice is potentially signing illegitimate messages


Protocol 3

  • Password is sent over the wire in plaintext
  • Subject to replay attacks
  • No mutual authentication
  • Concerns with Bob's security - i.e. how is he storing the passwords
    • Not storing with a salt so some other person Charlie can have the same password as Alice in /etc/secrets


Protocol 4

  • Any M-i-t-M attack can get an arbitrary message encrypted
  • MD is not an HMAC
    • MD should be concatenated to message and encrypted - there are issues with the packaging
    • When Alice sends the message to Bob, it is possible for an active attack to mess with the MD
    • We don't want to unencrypt malformed messages to check MD
  • No session key, and instead Alice and Bob are using long term secret; this same secret is being used for hashing and encryption


Protocol 5

  • The IV is the same as the key and the IV is a public quantity


Protocol 6

  • Standard reflection attack


Protocol 7

  • Random is the PRNG, so it is not producing true random numbers
  • 32 bits is not a great key size
  • The size of the return value is 16 bits, further shortening the key


Protocol 8

  • Standard Wide-mouth frog


Protocol 9

  • Needham-Schroeder

April 8

Intrusion Recovery

  • It is difficult to detect intrusion, and once we manage to, the question becomes how do we recover from it?
  • Detecting network intrusion is more difficult than system intrusion because it involves examining packets, applying arbitrary computation, and detecting intrusion at line speed.
  • Intrusion detection also presents a tough design challenge for usability
    • There is a gap between the systems made and the people who use them
    • The developed mechanisms need to be usable by sys admins who are not security experts
  • What happens if infrastructure is infiltrated on a massive scale?
    • Damage control is easier when the damage is known
      • The first task is to find out how wide spread the damage is
    • The technical solutions are difficult and there is no science that governs how to recover from intrusion
      • Significant difficulty arises from the fact that intrusion happens in many different contexts and institutions, so there is no one-size-fits-all solution
      • We can't simply install one piece of software to fix all problems
      • There is also a lack of good data on these intrusions that completely describe how networks are compromised
    • Detection and repair is an ongoing process
      • There is no state of being "done"; it is necessary to consistently check if an infrastructure has been compromised

April 10

Reading: chapter 26

Cryptography Design

  • Don't Do Encryption Only
    • If an adversary flips bits in a ciphertext, the receiver can detect the change (TRUE/FALSE)
      • FALSE
      • An algorithm simply does what it does on input - there is no checking to see if output makes sense
      • Encryption =/= integrity
  • Compress, then Encrypt
    • Encrypted data is harder to compress
      • C)
      • Compression encodes redundancy; plaintext is likely to be redundant, but decently encrypted data (not ECB) should not have much redundancy
      • Compressed data has itself some encoding so it can be recognized, like any other type (i.e. "Harder to recognize decrypted data by bad guys" is incorrect for this reason) and does not provide security
  • HMAC rather than MD
    • C)
    • True - it makes Hash Lengthening attacks impossible
  • Use Different Key in Different Directions
    • That is, avoid reflection attacks by:
      • D) All of the Above
      • Using two shared secrets, one for each direction
      • Initiator generates even challenges, responder generates odd challenges
      • Include the challengee's name in the challenge hash (key, name, R)
  • Have Both Sides Contribute to Master Key
    • D) A and C
    • Even if only one side has good randomness, the result will be a good random number
    • An eavesdropper must learn secrets from both sides to learn the key
  • Start of Plaintext Content
    • Don't let encrypted data begin with a constant or predictable value (TRUE/FALSE)
      • True - with certain cipher modes and short keys, and attacker can build a table
      • True - because ciphertext only attacks can recognize predictable values
  • Use of Nonces in Protocols
    • Know what it is
    • Doe snot necessarily need to be random, just unique
    • Chapter 26.20 - minimal vs redundant designs
  • Using Different Keys for Signing and Encryption
    • Signing is essentially encryption, especially with RSA - same as decryption and verification are the same operation
    • Use different keys for different purposes
    • The consequences of losing your signing key are smaller than losing your encryption key
  • Perfect Forward Secrecy
    • Adversary cannot decrypt even if she has seen everything and knows the long term secret
    • Diffie-Hellman
    • Ephemeral public/private key pair
  • Hardware RNG
    • It is important where the randomness comes from, as the security of a system can be dependent on it
    • Computers are not very good at generating random numbers
    • It is hard and a lot of the solutions are broken
    • True randomness comes from hardware
    • /dev/urandom

Week 14

April 13

Readings: chapter 17 and 18

Motivation

  • Again we ask, "Where is the right place to put security in order to achieve end-to-end, gateway-to-gateway, etc security guarantees?"
  • IPsec is an answer
    • There are different expectations placed on the user in different layer solutions; IPsec is mostly invisible to the user
  • Many software applications do not include confidentiality and integrity measures:
    • It is hard to adopt, if they do
    • Rely on ignorance or on other parts of the system to do so
    • There is a lack of developer expertise
  • The network layer is the sweet spot
    • Applications don't need to worry about it; you can still do SSL or PGP through IPsec
    • It is the deception layer (weeks 1 - 3)
    • IPv6 can be "better"
    • Transparency to link/application layer
    • OS is providing a service
  • IPsec solves source authentication (sec arch, roadmap), data integrity (ESP, AH), and data confidentiality (IKEv2)

IPsec

  • IPsec is a collection of protocols and mechanisms for securing traffic at layer 3
  • There are two protocols (AH, ESP) with two modes (transport, tunnel)
  • IPsec defines protocols such that there is meaningful security guarantees for packets/datagrams
    • It adds enough state so that meaningful policy (firewall) can be applied to IP level traffic
      • It is a better basis for firewall filtering
  • Use Cases
    • Host-to-host (End-to-end)
    • Tunnel gateway-gateway (firewall-firewall)
    • "Road warrior" mobile user (host-to-firewall)
  • Benefits
    • Enable physically distributed corporate "WAN"/VPN
    • Traffic can be internally unencrypted, so internal network traffic doesn't suffer
    • "Smarter" firewall policy
    • Key management transparent to users
  • Elements of IPsec
    • Wire protocols: ESP and AH
    • Policy: SAs and SPDs
    • Key management: manual, automatic, Photuris, SKIP, IKEv1, IKEv2, JFK, ISAKMP

AH and ESP

  • AH (Authentication Header) does not ensure confidentiality, only integrity
  • ESP (Encapsulating Security Payloads) has both (optional) confidentiality and integrity
  • AH explicitly protects source IP; ESP implicitly protects it

Modes

  • Transport mode is for end-to-end communication
    • The payload of the packet is protected
  • Tunnel mode is for gateway-to-gateway
    • The entire packet is encrypted/protected and encapsulated in a new IP packet with a new header
  • Both AH and ESP can be used in either modes

SA

  • Security Association (SA) is a connection or flow protected by cryptography
  • There are two SAs, each describing a direction of the connection
  • Each host maintains a database of SAs

SPI and SPD

  • Security Parameters Index indicates which part of the SPD (Security Policy Database) applies to a particular SA
  • The SPD handles inbound and outbound traffic flows
  • The SPD, at a high level, is a firewall, it can determine what to accept/reject/ignore

Key Management (IKEv1, IKEv2, JFK)

  • Requirements:
    • Needs to derive session key
    • Negotiate SA parameters (key length, algorithm)
    • Provides strong security
    • Minimal or no configuration
  • Why not just use Diffie-Hellman?
    • DH gives some security, but it does not deal with the identities of the parties/authentication, perfect forward secrecy, or DoS attacks; it is also computationally expensive and subject to M-i-t-M attacks

April 15

Guest Speaker