CMSC 414 Computer and Network Security Lecture 8

1. CMSC 414Computer and Network SecurityLecture 8 Jonathan Katz

2. Limitations of Cryptography • Crypto can be difficult to get right • Need expertise; “a little knowledge can be a dangerous thing…” • Should be integrated from the beginning • Crypto will not solve all security problems • Must be implemented correctly • Key mgmt; social engineering; insider attacks • Develop (appropriate) attack/trust models • Need to analyze weak link in the chain…

3. Continued… • Human factors • Crypto needs to be easy to use both for end-users and administrators • Educate users • Generally, crypto isn’t just “plug-and-play” --- need to know what you are doing • Need for detection, audit, and recovery • In addition to other security measures

4. Specific themes • No “security through obscurity” • Security as a process, not a product • Manage risk • Encryption does not provide authentication • Need good sources of randomness • Side channels and other unexpected avenues of attack

5. Also… • The papers demonstrate the importance of security in real-world applications! • Hope you found them fun to read, also… • Hacking can be fun! 

6. “Why Cryptosystems Fail” • Limited disclosure of crypto failures… • Insider attacks • By bank clerks, maintenance engineers, … • Poor prevention/detection mechanisms • Poor key management • Bad modeling • Failure to take into account chosen-plaintext attacks; live/test systems using same key • Bad trust models • Constantly changing threat model

7. “Why Cryptosystems Fail” • Poor cryptography • No cryptographic redundancy on ATM card • Unauthenticated authorization response! • No authentication of ATM machine to card • PIN not tied to account number • Bad “randomness” • Remote PIN verification • Incorrect key lengths • “Home-brewed” encryption algorithms

8. “Insecurity of 802.11” • WEP encryption protocol: IV, RC4(IV, k)  (M, c(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

9. “Insecurity of 802.11” • Known-plaintext attacks • Based on header information… • Chosen-plaintext attacks • Send IP traffic/e-mail to the mobile host • Transmit broadcast messages to access point • Authentication spoofing

10. “Insecurity of 802.11” • No cryptographic integrity protection • Encryption does not provide authentication! • Adding redundancy does not help… • Especially when a linear checksum is used • And when the checksum is key-independent • Encryption used to provide authentication • Allows easy spoofing after eavesdropping • Allows IP redirection attack • Allows TCP “reaction” attacks --- chosen-ciphertext attacks!

11. “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… • Morals • Security through obscurity does not help • In this case, code was leaked

12. “Analysis of E-Voting System” • Poor cryptography • Smartcards have no cryptographic function • No cryptographic protection against multiple voting; improper audit mechanism for detecting overvoting • No cryptographic protection for admin cards • Only a weak PIN…if any • Possible to shut down the election!

13. “Analysis of E-Voting System” • Poor cryptography… • Most data stored without any integrity • Easy to modify ballot… • Hard-coded, non-random DES key! • Used for multiple versions!! • CBC mode with IV set to 0! • Problems with deterministic encryption… • Linking voters to votes • No cryptographic integrity mechanism • Poor audit trail