Cryptography

IS820 Computer Security

Lecture # 2
  In practice, we do have trust (unlike Thompson’s article)
 We have made great strides in computer security over the past
decades
Why things are  As security improvements are made, ever more functionality is
desired
not quite so  People unwilling to trade off openness for security
bad…  (Arguably) many of the most significant problems are no longer
technical
 User education
 Policy issues
  “Inside the Twisted Mind of the Security Professional”
 Security mindset…
Assigned
 “We are All Security Customers”
readings --  Cost-benefit analysis
discussion  “Information Security and Externalities”
 Security as an economics problem; liability
  Confidentiality/secrecy
 Restrictions on information access and disclosure, including personal
privacy
CIA Triad  Integrity
 Guarding against improper modification or destruction of
[FIPS PUB 199] information; ensuring non-repudiation and (source) authenticity
 Availability
 Ensuring timely and reliable access to information and resources
  Improper resource usage
Other?
 Entity authentication
A high-level survey of
cryptography
  Everything I present will be (relatively) informal
 I may simplify, but I will not say anything that is an outright lie…
 Cryptography offers formal definitions and rigorous proofs of
Caveats security (neither of which we will cover here)
 For more details, refer IS842 Advanced Cryptography 1
 If you think you already know cryptography from somewhere else
(CISSP, your job), you are probably mistaken
  Crypto deals primarily with three goals:
 Confidentiality
 Integrity (of data)
 Authentication (of resources, people, systems)

Goals of
 Other goals also considered
cryptography  E.g., non-repudiation
 E-cash (e.g., double spending)
 Secure distributed computation
 Anonymity
 …
  There are two settings for cryptography:
 Private-key / shared-key / symmetric-key / secret-key
Private- vs.  Public-key
public-key  The private-key setting is the “classical” one (thousands of years
settings old)
 The public-key setting dates to the 1970s
  The communicating parties share some information that is
random and secret
 This shared information is called a key
 Key is completely unknown to an attacker
Private-key  Key is uniformly random

cryptography
 The key k must be shared in advance
 We don’t discuss (for now) how they do this
 You can imagine they meet on a dark street corner and Alice hands a
USB device (with a key on it) to Bob
  Two (or more) distinct parties communicating over an insecure
network
Canonical  E.g., secure communication

applications
 A single party who is communicating “with itself” over time
 E.g., secure storage
 Bob
Alice

K shared info K

Bob
Alice

K K
Bob

K
  Two complementary goals:
 Secrecy and integrity

Private-key  For secrecy:

 Private-key encryption
cryptography
 For integrity:
 Message authentication codes
  Passive eavesdropping vs. active interference

Attacker types  Secrecy is a concern for passive or active adversaries

 Integrity is a concern for active adversaries

Private-key encryption
  Encryption algorithm:
 Takes a key and a message (plaintext), and outputs a ciphertext
 c  Ek(m), possibly randomized!
 Decryption algorithm:
Functional  Takes a key and a ciphertext, and outputs a message (or perhaps an
definition error)
 m = Dk(c)

 Correctness: for all k, we have Dk(Ek(m)) = m

 We have not yet said anything about security…
 Bob
Alice

K shared info K

Bob
Alice
c
K K

cEK(m) m=DK(c)
  Want secrecy against a passive eavesdropper who observed the
Secrecy ciphertext
 This adversary does not know the key
  Always assume that the full details of crypto protocols and
algorithms are public
Security  Known as Kerckhoffs’s principle
 The only secret information is the key
through  “Security through obscurity” is a bad idea…
obscurity?  True in general; even more true in the case of cryptography
 Home-brewed solutions are BAD!
 Standardized, widely-accepted solutions are GOOD!
  Why not?
 Easier to maintain secrecy of a key than an algorithm
Security  Reverse engineering
 Social engineering
through  Insider attacks
obscurity?  Easier to change the key than the algorithm
 In general setting, much easier to share an algorithm than for
everyone to use their own
  Assume the English uppercase alphabet (no lowercase,
punctuation, etc.)
 View letters as numbers in {0, …, 25}
A classic  The key is a random letter of the alphabet
example: shift  Encryption done by addition modulo 26

cipher
 Is this secure?
 Exhaustive key search
 Automated determination of the key
  The key is a random permutation of the alphabet
 Note: key space is huge!
Another
 Encryption done in the natural way
example:
substitution  Is this secure?
cipher  Frequency analysis
 A large key space is necessary, but not sufficient, for security
  More complicated version of shift cipher
Another
example:  Believed to be secure for over 100 years
Vigenere
cipher  Is it secure?
  Let pi (for i=0, …, 25) denote the frequency of letter i in English-
language text
 Known that Σ pi2 ≈ 0.065
Attacking the  For each candidate period t, compute frequencies {qi} of letters in
Vigenere the sequence c0, ct, c2t, …
 For the correct value of t, we expect Σ qi2 ≈ 0.065
cipher  For incorrect values of t, we expect Σ qi2 ≈ 1/26
 Once we have the period, can use frequency analysis as in the case
of the shift cipher
Crypto pitfalls
and recommendations
  Crypto deceptively simple
 Why does it so often fail?

 Important to distinguish various issues:

 Bad cryptography, bad implementations, bad design, etc.
 Even good cryptography can often be ‘circumvented’ by adversaries
Crypto pitfalls? operating ‘outside the model’
 Even the best cryptography only shifts the weakest point of failure
to elsewhere in your system
 Systems are complex
 Avoid the first; be aware of 2-4
  Crypto alone cannot solve all security problems
 Key management; social engineering; insider attacks
 Need to develop an appropriate threat model for the system as a
whole
Systems are
complex  Defense in depth
 Need for review, detection, and recovery
 Security as a process, not a product
  Crypto is difficult to get right
Cryptography  Must be implemented correctly
 Must be integrated from the beginning, not added on “after the
is not a “magic fact”
 Need expertise; “a little knowledge can be a dangerous thing…”
bullet”  Can’t be secured by Q/A, only (at best) through penetration testing
and dedicated review of the code by security experts
  Use only standardized algorithms and protocols
 No security through obscurity!
 Use primitives for their intended purpose
 Don’t implement your own crypto
General  If your system cannot use “off-the-shelf” crypto components, re-
recommendati think your system
 If you really need something new, have it designed and/or evaluated
ons by an expert

 Don’t use the same key for multiple purposes

 E.g., encryption/MAC, or RSA encryption/signatures

 Use good random-number generation

  Use existing, high-level crypto libraries
 cryptlib
 NaCl
 Keyczar
Crypto libraries  These provide an appropriate interface to crypto algorithms
 Avoid low-level libraries (like JCE) – too much possibility of mis-
use
 Avoid writing your own low-level crypto
  Do not use “standard” PRNGs; use cryptographic PRNGs instead
 E.g., srand/rand in C:
 srand(seed) sets state=seed (where |seed| = 32 bits)
Random-  rand():
number  state = f(state), where f is some linear function
 return state
generation  Generating a 128-bit key using 4 calls to rand() results in a key with
only 32 bits of entropy!
 Related issues led to exploit in Netscape v1.1
  Crypto PRNGs have different requirements
 Indistinguishable from random by any efficient algorithm
 Constantly re-seeded with new entropy to ensure forward security
 Should be impossible to guess or perturb internal state
PRNGs  E.g., if entropy comes from file timestamps

 “Cold boot” issues

 Server just rebooted and needs randomness….is there enough
entropy after being up just a few seconds?
  (These are crypto-specific; and do not include general issues such
as preventing buffer overflows, etc. that we will cover later)
Implementatio  Must implement crypto exactly as specified!
n flaws  if (0 == strncmp(userHash, myHash, 20)) allow;
 strncmp compares up to the first null character
 What if my userHash starts with a 0 byte??
  Must implement crypto exactly as specified!
 PKCS#1 pads data as follows:
00 01 FF … FF 00 H(m)
Implementatio  Bad implementation of signature verification?
n flaws  Exponentiate, strip off padding, and compare to H(m)

 Makes forgery easier!

 Every bit of padding must be checked
  E.g., Amazon Web Services v1
 Split query at & and = ; concatenate and apply MAC
 The following are then equivalent:
…?GoodKey1=GoodValue1BadKey2BadValue2
Delimiting …?GoodKey1=GoodValue1&BadKey2=BadValue2

 Wordpress cookie flaw

tokens  token: HMAC(username.expirytime)
 Create account for username=‘admin0’ and go…
 Using timestamps to prevent replay
 Is MAC(withdraw $101,1/23/09) = MAC(withdraw $10,11/23/09)?
Case studies
  Limited disclosure of crypto failures…
 Insider attacks
“Why 

By bank clerks, maintenance engineers, …
Poor prevention/detection/auditing mechanisms
Cryptosystems  Poor key management

Fail” Insecure delivery of ATM cards/PINs
 Reduced entropy of PINs
 Use of “home-brewed” encryption schemes
  A user should need both their ATM card and their PIN in order to
withdraw money
System goals  “Two-factor authentication”

and
 Assumptions:
assumptions  PIN must be short
 ATM card cannot perform cryptographic operations
  Attacker can
 Read discarded receipts…
Threat model  Eavesdrop on channel from ATM to bank
 Inject messages on channel from ATM to bank
 Impersonate the ATM to a user
  If an attacker does not have a user’s ATM card, should be
infeasible to withdraw money from that user’s account (even if the
PIN is known)
Desired
security  If an attacker has a user’s ATM card, but not their PIN, the best it
can do is guess the PIN repeatedly
 1/10000 chance each time
 Prevent unlimited guessing
 #, PIN
Account #
ATM Bank
ok
One system PIN

If FK(#) = PIN:
return “ok”

This is similar, but not identical, to how ATMs work today

  Eavesdrop on PIN and account # ; manufacture rogue ATM card
 Replay “ok” message!
 Solution: use authentication with replay protection
Attacks
 Impersonate an ATM to a customer
 Can this be prevented without implementing crypto on the ATM
card? (How could the bank authenticate directly to the user?)
 Account # #, c, PIN
c=EncK(PIN)
ATM Bank
Another PIN ok
system
If DK(c) = PIN:
debit account #,
return “ok”

No binding between account # and PIN!

 encrypted

Account #
PIN
#
Bank
Another ATM balance
withdraw amt
system
If FK(#) = PIN:
“authenticated”

If amt ≤ balance,
dispense cash

Do you see an attack?

References