CMSC 414
Computer (and Network) Security
Lecture 2
Jonathan Katz
Two papers linked from webpage
 “Reflections on trusting trust”
 “Managed security monitoring”
 Both leave a fairly negative impression of
security…
 …at the very least, they show that security
is not easy, and cannot just be applied as a
“magic bullet”
“Managed security monitoring”
 (Summarize article)
– Is the state of network security really this bad?
(Arguably, yes)
– Although network monitoring and risk
management are important, security is too
– Security is not an ends unto itself
• If you really want to be secure, disconnect yourself
from the Internet
An Overview of Computer
Security
Basic components
 Confidentiality
 Integrity
 Availability
Policy vs. mechanism
 Security policy
– Statement of what is and is not allowed
 Security mechanism
– Method for enforcing a security policy
 One is meaningless without the other…
 Problems when combining security policies
of multiple organizations
Security goals
 Prevention
 Detection
 Response/recovery
Assumptions and trust
 Example: assume that all employees are
trustworthy, and do not represent a threat
 Assumptions underlie any security
mechanism
– Important to recognize and evaluate these
assumptions
Example
 Assumption: locks cannot be picked
– What if a locksmith is around?
– What if this locksmith is trustworthy?
– Why do we assume that she is trustworthy?
More assumptions
 Two assumptions are (almost) always made:
– Policy defines the intended level of security
– Mechanism correctly implements policy
System development
 Determine threats; develop policy
 Give specification of the system
– Desired functionality of the system
– If specification is ambiguous, vulnerabilities can result
– An imprecise specification is useless…
 Design the system
– Design system satisfying the specification
– Difficult (but not impossible) to verify
System development, cont’d…
 Implementation
– Create a system satisfying the design
– Impossible to fully verify correctness
• Software complexity
• Unknown inputs
• Unverified tools
– “Testing” after the fact
• Subject to limitations of the tests
System development (summary)
1. Threat analysis
2. Policy
3. Specification
4. Design
5. Implementation
6. (Operation/maintenance/monitoring?)
Cost-benefit analysis
 Important to evaluate what level of security
is necessary/appropriate
– Cost of mounting a particular attack vs. value
of attack to an adversary
– Cost of damages from an attack vs. cost of
defending against the attack
– Likelihood of a particular attack
Human factors
 E.g., passwords…
 Outsider vs. insider attacks
 Software misconfiguration
 Not applying security patches
 Social engineering
Everything you wanted to know
*
about cryptography
*But perhaps were afraid to ask…
Caveat
 Everything I present will be (relatively)
informal
– But I will try not to say anything that is an
outright lie…
 Cryptography is about precise definitions,
formal models, and rigorous proofs of
security (which we will not cover here)
– If you want more details, take CMSC 456!
Attacks
 Crypto deals primarily with three goals:
– Confidentiality
– Integrity (of data)
– Authentication (of resources, people, systems)
 Other goals also considered
– E.g., non-repudiation
– E-cash (e.g., double spending)
– General secure multi-party computation
Private- vs. public-key
 For many security goals, there are two types
of cryptographic algorithms
– Private-key / shared-key / symmetric-key /
secret-key
– Public-key
Private-key cryptography
 The parties communicating share a
completely random and secret key
– Main point: key is not known to an attacker
– This key must be shared (somehow) before they
communicate
 All “classical” cryptosystems are private-
key based
 Can also be used for secure storage
Private-key cryptography
 For confidentiality:
– Private-key (symmetric-key) encryption
 For data integrity:
– Message authentication codes
– (sometimes called cryptographic checksums)
Public-key cryptography
 One party (Alice) generates both a public key and
a private key (or secret key)
 The public key is published; the private key is
kept secret
– An attacker knows the public key!
 The other communicating party (Bob) need not
have any key of his own; knows Alice’s key
 Techniques for this first developed in the 70’s
Public-key cryptography
 For confidentiality:
– Public-key encryption
 For data integrity:
– Digital signatures
To review…
 Confidentiality:
– Private-key encryption (schemes)
– Public-key encryption (schemes)
 Integrity:
– Message authentication (codes)
– Digital signature (schemes)
 We will discuss authentication later
Private- vs. public-key I
 Disadvantages of private-key
– Need to securely share a key
• If you can share a key securely, why not just share
the message itself?
• What if not possible?
• Need to know who you want to communicate with
in advance!
– O(n2) blowup in storage
Private- vs. public-key II
 Why study private-key at all?
– Private-key is much more efficient (3 orders of
magnitude)
– Public-key crypto is “harder” to get right
• Needs stronger assumptions, more math
– Can combine private-key with public-key to get
the best of both worlds (for encryption)
Private- vs. public-key III
 More disadvantages of public-key crypto
– Public-key crypto still requires secure
distribution and binding of public keys (PKI)
• May (sometimes) be just as hard as sharing a key
– Not clear who you are communicating with (for
public-key encryption)
Confidentiality
Overview
 Private-key encryption
– Attack model
– “Trivial” systems
• Show why the problem is hard
• Show methods of attack
• Convince you not to use “home-brewed” techniques
– What do we mean by security?
– Block ciphers and modern-day techniques
Overview, continued…
 Public-key cryptography
– A word about security
– Some basic number theory
– RSA and El Gamal
– Some attacks…and some fixes
Bob
Alice
K
shared info
K
Bob
Alice
C1
K
m
C = EK(m)
K
m = DK(C)
In more detail…
 Alice and Bob share a key K
– Must be shared securely
– Must be completely random
– Must be kept completely secret from attacker
– We don’t discuss (for now) how they do this
 Plaintext - encryption - ciphertext -
decryption
 Decryption must recover the message!