Outline DNSSEC, cont’d CSci 5271 SSH Introduction to Computer Security Announcements intermission Day 19: Web security, part 2 Stephen McCamant More crypto protocols University of Minnesota, Computer Science & Engineering More causes of crypto failure DNSSEC goals and non-goals Negative answers Also don’t want attackers to spoof non-existence ✰ Authenticity of positive replies Gratuitous denial of service, force fallback, ✰ Authenticity of negative replies etc. ✰ Integrity But don’t want to sign “ ① does not ✲ Confidentiality exist” for all ① ✲ Availability Solution 1, ◆❙❊❈ : “there is no name between ❛❝❛❝✐❛ and ❜❛♦❜❛❜ ” Preventing zone enumeration DANE: linking TLS to DNSSEC Many domains would not like people “DNS-based Authentication of Named enumerating all their entries Entities” DNS is public, but “not that public” DNS contains hash of TLS cert, don’t Unfortunately ◆❙❊❈ makes this trivial need CAs Compromise: ◆❙❊❈✸ uses How is DNSSEC’s tree of certs better password-like salt and repeated hash, than TLS’s? allows opt-out
Signing the root Deployment Political problem: many already distrust Standard deployment problem: all cost US-centered nature of DNS and no benefit to being first mover infrastructure Servers working on it, mostly top-down Practical problem: must be very secure with no single point of failure Clients: still less than 20% Finally accomplished in 2010 Will be probably common: insecure Solution involves ‘key ceremonies’, connection to secure resolver international committees, smart cards, safe deposit boxes, etc. Outline Short history of SSH DNSSEC, cont’d Started out as freeware by Tatu Yl¨ onen in 1995 SSH Original version commercialized Announcements intermission Fully open-source OpenSSH from OpenBSD More crypto protocols Protocol redesigned and standardized More causes of crypto failure for “SSH 2” OpenSSH t-shirt SSH host keys Every SSH server has a public/private keypair Ideally, never changes once SSH is installed Early generation is a classic entropy problem Especially embedded systems, VMs
Authentication methods Old crypto vulnerabilities 1.x had only CRC for integrity Password, encrypted over channel Worst case: when used with RC4 ✳s❤♦sts : like ✳r❤♦sts , but using client Injection attacks still possible with CBC host key CRC compensation attack User-specific keypair For least-insecure 1.x-compatibility, Public half on server, private on client attack detector Plugins for Kerberos, PAM modules, etc. Alas, detector had integer overflow worse than original attack Newer crypto vulnerabilities SSH over SSH IV chaining: IV based on last message SSH to machine 1, from there to ciphertext machine 2 Allows chosen plaintext attacks Common in these days of NATs Better proposal: separate, random IVs Better: have machine 1 forward an Some tricky attacks still left encrypted connection (cf. HW1) Send byte-by-byte, watch for errors 1. No need to trust 1 for secrecy Of arguable exploitability due to abort 2. Timing attacks against password typing Now migrating to CTR mode SSH (non-)PKI Outline When you connect to a host freshly, a DNSSEC, cont’d mild note SSH When the host key has changed, a large warning Announcements intermission ❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅ More crypto protocols ❅ ❲❆❘◆■◆●✿ ❘❊▼❖❚❊ ❍❖❙❚ ■❉❊◆❚■❋■❈❆❚■❖◆ ❍❆❙ ❈❍❆◆●❊❉✦ ❅ ❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅ ■❚ ■❙ P❖❙❙■❇▲❊ ❚❍❆❚ ❙❖▼❊❖◆❊ ■❙ ❉❖■◆● ❙❖▼❊❚❍■◆● ◆❆❙❚❨✦ ❙♦♠❡♦♥❡ ❝♦✉❧❞ ❜❡ ❡❛✈❡s❞r♦♣♣✐♥❣ ♦♥ ②♦✉ r✐❣❤t ♥♦✇ More causes of crypto failure ✭♠❛♥✲✐♥✲t❤❡✲♠✐❞❞❧❡ ❛tt❛❝❦✮✦ ■t ✐s ❛❧s♦ ♣♦ss✐❜❧❡ t❤❛t ❛ ❤♦st ❦❡② ❤❛s ❥✉st ❜❡❡♥ ❝❤❛♥❣❡❞✳
Upcoming assignments Outline DNSSEC, cont’d SSH Hands-on assignment 2 is due Friday For best results, don’t put off until last Announcements intermission minute More crypto protocols More causes of crypto failure 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 DNSSEC, cont’d Ensure unique message types and parsing SSH Design for ciphers and key sizes to Announcements intermission change Limit information in outbound error More crypto protocols messages More causes of crypto failure Be careful with out-of-order messages
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
Recommend
More recommend
