CMSC 414 Computer and Network Security Lecture 8

1. CMSC 414Computer and Network SecurityLecture 8 Jonathan Katz

2. “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

3. One system ATM Bank #, PIN Account # ok PIN If FK(#) = PIN: return “ok” This is similar, but not identical, to how ATMs work today

4. 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?)

5. Another system Account # c=EncK(PIN) ATM Bank #, c, PIN ok PIN If DK(c) = PIN: debit account #, return “ok” No binding between account # and PIN!

6. Another system encrypted Account # ATM Bank PIN # balance withdraw amt If amt ≤ balance, dispense cash If FK(#) = PIN: “authenticated” Do you see an attack?

7. “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)

8. “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

9. “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 • Allows TCP “reaction” attacks • Look at whether TCP checksum is valid Chosen-ciphertext attacks!

10. “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

11. 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

12. “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

13. “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