CMSC 414 Computer and Network Security Lecture 8

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 ok Bank 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=Enc. K(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 If. Ifamt ≤ balance, FK(#) = PIN: dispense cash “authenticated” Do you see an attack? Bank

“Insecurity of 802. 11” ¨ WEP encryption: IV, RC 4(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