CMSC 414
Computer and Network Security
Lecture 8
Jonathan Katz
“Why Cryptosystems Fail”
 Limited disclosure of crypto failures…
 Insider attacks
– By bank clerks, maintenance engineers, …
– Poor prevention/detection mechanisms
– Poor key management
– Insecure delivery of ATM cards/PINs
 Reduced entropy of PINs
 Use of “home-brewed” encryption schemes
One system
#, PIN
Account #
ATM
PIN
Bank
ok
If FK(#) = PIN:
return “ok”
This is similar, but not identical, to how ATMs work today
Attacks
 Sniff PIN; get account # from discarded receipt
– Solution: don’t print full account # on receipt
 Replay “ok” message!
– Solution: use authentication with replay protection
 Impersonate an ATM to a customer
– Can this be prevented without implementing crypto on
the ATM card? (Hint: how can the bank authenticate
directly to the user?)
Another system
Account #
c=EncK(PIN)
#, c, PIN
ATM
PIN
Bank
ok
If DK(c) = PIN:
debit account #,
return “ok”
No binding between account # and PIN!
Another system
encrypted
Account #
PIN
ATM
#
balance
withdraw amt
IfIfamt
≤ balance,
FK(#)
= PIN:
dispense cash
“authenticated”
Do you see an attack?
Bank
“Insecurity of 802.11”
 WEP encryption:
IV, RC4(IV, k)  (M, checksum(M))
 Is this secure against chosen-plaintext attacks?
– It is randomized…
– But how is the IV chosen?
• Only 24 bits long
• Reset to 0 upon re-initialization
• Some implementations increment the IV as a counter
– IV repetitions are a problem!
 40-bit key (in early version)
“Insecurity of 802.11”
 Known-plaintext attacks
– Based on header information, known message blocks,
etc.
 Chosen-plaintext attacks
– Send IP traffic/e-mail to the mobile host
– Transmit broadcast messages to access point
– Authentication spoofing
“Insecurity of 802.11”
 No cryptographic integrity protection
– The checksum is linear (i.e., c(xy) = c(x)c(y)) and
unkeyed, and therefore easy to attack
 Encryption used to provide authentication
– Allows easy spoofing after eavesdropping
– Allows IP redirection attack
Chosen-ciphertext
attacks!
– Allows TCP “reaction” attacks
• Look at whether TCP checksum is valid
“Analysis of E-Voting System”
 This paper should scare you…
– Magnitude of possible attacks by voters
– Not just the security flaws, but also the reaction of
Diebold and govt. officials…
 Vulnerable to attacks by voters, as well as attacks
by insiders
 Security through obscurity did not help
– In this case, code was leaked
Overview
 Voting terminals initialized; ballots installed
 On voting day, voters given voting card
– Voter inserts card, gets ballot, makes choices
– After confirmation, voting card is “cancelled”
 Election is closed by inserting an admin card
– Results can be uploaded for tabulation
“Analysis of E-Voting System”
 Poor cryptography
– Smartcards have no cryptographic functionality
• Possible to create home-made voting cards!
– No cryptographic protection for admin cards
• Only a weak PIN…if any
• Possible to shut down the election!
– No cryptographic protection against multiple voting
• Disable “cancellation”, or overwrite card
– Improper audit mechanism for detecting over-voting
“Analysis of E-Voting System”
 Poor/missing cryptography…
– Most data stored without any integrity
• Potentially possible to modify ballot or even the software
– No authentication of data sent to back-end server
– Hard-coded, non-random DES key!
• Used for multiple versions!!
– CBC mode with IV = 0!
• Problems with deterministic encryption…
• Linking voters to votes (encrypted votes stored sequentially)
– CRC used instead of a MAC
– Poor random number generation