Outline More crypto protocols CSci 5271 Introduction to Computer - PDF document

Outline More crypto protocols CSci 5271 Introduction to Computer Security Announcements intermission More crypto protocols and failures Stephen McCamant More causes of crypto failure University of Minnesota, Computer Science & Engineering Abstract protocols Protocol notation Outline of what information is communicated in messages ❆ ✦ ❇ ✿ ◆ ❇ ❀ ❢ ❚ ✵ ❀ ❇❀ ◆ ❇ ❣ ❑ ❇ Omit most details of encoding, naming, ❆ ✦ ❇ : message sent from Alice sizes, choice of ciphers, etc. intended for Bob Describes honest operation ❇ (after :): Bob’s name But must be secure against adversarial participants ❢ ✁ ✁ ✁ ❣ ❑ : encryption with key ❑ Seemingly simple, but many subtle problems Needham-Schroeder Needham-Schroeder MITM ❆ ✦ ❈ ✿ ❢ ◆ ❆ ❀ ❆ ❣ ❊ ❈ Mutual authentication via nonce exchange, ❈ ✦ ❇ ✿ ❢ ◆ ❆ ❀ ❆ ❣ ❊ ❇ assuming public keys (core): ❇ ✦ ❈ ✿ ❢ ◆ ❆ ❀ ◆ ❇ ❣ ❊ ❆ ❆ ✦ ❇ ✿ ❢ ◆ ❆ ❀ ❆ ❣ ❊ ❇ ❈ ✦ ❆ ✿ ❢ ◆ ❆ ❀ ◆ ❇ ❣ ❊ ❆ ❇ ✦ ❆ ✿ ❢ ◆ ❆ ❀ ◆ ❇ ❣ ❊ ❆ ❆ ✦ ❈ ✿ ❢ ◆ ❇ ❣ ❊ ❈ ❆ ✦ ❇ ✿ ❢ ◆ ❇ ❣ ❊ ❇ ❈ ✦ ❇ ✿ ❢ ◆ ❇ ❣ ❊ ❇

Certificates, Denning-Sacco Attack against Denning-Sacco A certificate signed by a trusted ❆ ✦ ❙ ✿ ❆❀ ❇ third-party ❙ binds an identity to a ❙ ✦ ❆ ✿ ❈ ❆ ❀ ❈ ❇ public key ❆ ✦ ❇ ✿ ❈ ❆ ❀ ❈ ❇ ❀ ❢ Sign ❆ ✭ ❑ ❆❇ ✮ ❣ ❑ ❇ ❈ ❆ ❂ Sign ❙ ✭ ❆❀ ❑ ❆ ✮ ❇ ✦ ❙ ✿ ❇❀ ❈ Suppose we want to use S in ❙ ✦ ❇ ✿ ❈ ❇ ❀ ❈ ❈ establishing a session key ❑ ❆❇ : ❇ ✦ ❈ ✿ ❈ ❆ ❀ ❈ ❈ ❀ ❢ Sign ❆ ✭ ❑ ❆❇ ✮ ❣ ❑ ❈ ❆ ✦ ❙ ✿ ❆❀ ❇ By re-encrypting the signed key, Bob can ❙ ✦ ❆ ✿ ❈ ❆ ❀ ❈ ❇ pretend to be Alice to Charlie ❆ ✦ ❇ ✿ ❈ ❆ ❀ ❈ ❇ ❀ ❢ Sign ❆ ✭ ❑ ❆❇ ✮ ❣ ❑ ❇ Envelopes analogy Design robustness principles Use timestamps or nonces for Encrypt then sign, or vice-versa? freshness On paper, we usually sign inside an Be explicit about the context envelope, not outside. Two reasons: Don’t trust the secrecy of others’ Attacker gets letter, puts in his own secrets envelope (c.f. attack against X.509) Whenever you sign or decrypt, beware Signer claims “didn’t know what was in the envelope” (failure of non-repudiation) of being an oracle Distinguish runs of a protocol Implementation principles Outline Ensure unique message types and More crypto protocols parsing Design for ciphers and key sizes to Announcements intermission change Limit information in outbound error More causes of crypto failure messages Be careful with out-of-order messages

Note to early readers Outline More crypto protocols This is the section of the slides most likely to change in the final version Announcements intermission If class has already happened, make sure you have the latest slides for More causes of crypto failure announcements Random numbers and entropy Netscape RNG failure Early versions of Netscape SSL Cryptographic RNGs use cipher-like (1994-1995) seeded with: techniques to provide indistinguishability Time of day But rely on truly random seeding to Process ID stop brute force Parent process ID Extreme case: no entropy ✦ always Best case entropy only 64 bits same “randomness” (Not out of step with using 40-bit Modern best practice: seed pool with encryption) 256 bits of entropy But worse because many bits Suitable for security levels up to ✷ ✷✺✻ guessable Debian/OpenSSL RNG failure (1) Debian/OpenSSL RNG failure (2) Debian maintainer commented out OpenSSL has pretty good scheme some lines to fix a Valgrind warning using ✴❞❡✈✴✉r❛♥❞♦♠ “Potential use of uninitialized value” Also mixed in some uninitialized Accidentally disabled most entropy (all variable values but 16 bits) “Extra variation can’t hurt” From modern perspective, this was the Brief mailing list discussion didn’t lead original sin to understanding Remember undefined behavior discussion? Broken library used for ✘ 2 years before But had no immediate ill effects discovery

Detected RSA/DSA collisions New factoring problem (CCS’17) 2012: around 1% of the SSL keys on the public net are breakable An Infineon RSA library used primes of Some sites share complete keypairs the form ♣ ❂ ❦ ✁ ▼ ✰ ✭ ✻✺✺✸✼ ❛ mod ▼ ✮ RSA keys with one prime in common (detected by large-scale GCD) Smaller problems: fingerprintable, less One likely culprit: insufficient entropy in entropy key generation Major problem: can factor with a Embedded devices, Linux ✴❞❡✈✴✉r❛♥❞♦♠ variant of Coppersmith’s algoritm vs. ✴❞❡✈✴r❛♥❞♦♠ E.g., 3 CPU months for a 1024-bit key DSA signature algorithm also very vulnerable Side-channel attacks WEP “privacy” Timing analysis: First WiFi encryption standard: Wired Number of 1 bits in modular exponentiation Equivalent Privacy (WEP) Unpadding, MAC checking, error handling Probe cache state of AES table entries F&S: designed by a committee that Power analysis contained no cryptographers Especially useful against smartcards Problem 1: note “privacy”: what about Fault injection integrity? Nope: stream cipher + CRC = easy bit Data non-erasure flipping Hard disks, “cold boot” on RAM WEP shared key WEP key size and IV size Original sizes: 40-bit shared key Single key known by all parties on (export restrictions) plus 24-bit IV = network 64-bit RC4 key Both too small Easy to compromise 128-bit upgrade kept 24-bit IV Hard to change Vague about how to choose IVs Also often disabled by default Least bad: sequential, collision takes Example: a previous employer hours Worse: random or everyone starts at zero

WEP RC4 related key attacks New problem with WPA (CCS’17) Session key set up in a 4-message Only true crypto weakness handshake Key reinstallation attack: replay #3 RC4 “key schedule” vulnerable when: Causes most implementations to reset RC4 keys very similar (e.g., same key, nonce and replay counter similar IV) In turn allowing many other attacks First stream bytes used One especially bad case: reset key to 0 Not a practical problem for other RC4 Protocol state machine behavior poorly users like SSL described in spec Key from a hash, skip first output bytes Outside the scope of previous security proofs Trustworthiness of primitives Dual EC DRBG (1) Pseudorandom generator in NIST Classic worry: DES S-boxes standard, based on elliptic curve Obviously in trouble if cipher chosen by Looks like provable (slow enough!) but your adversary strangely no proof In a public spec, most worrying are Specification includes long unexplained unexplained elements constants Best practice: choose constants from Academic researchers find: well-known math, like digits of ✙ Some EC parts look good But outputs are statistically distinguishable Dual EC DRBG (2) Found 2007: special choice of constants allows prediction attacks Big red flag for paranoid academics Significant adoption in products sold to US govt. FIPS-140 standards Semi-plausible rationale from RSA (EMC) NSA scenario basically confirmed by Snowden leaks NIST and RSA immediately recommend withdrawal