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
cEK(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
