Outline Cryptographic protocols, pt. 1 Key distribution and PKI - PDF document

Outline Cryptographic protocols, pt. 1 Key distribution and PKI CSci 5271 Introduction to Computer Security Announcements intermission Day 17: Crypto protocols and “S” protocols SSH Stephen McCamant University of Minnesota, Computer Science & Engineering SSL/TLS DNSSEC A couple more security goals Abstract protocols Outline of what information is communicated in Non-repudiation: principal cannot later deny having messages made a commitment Omit most details of encoding, naming, sizes, choice of I.e., consider proving fact to a third party ciphers, etc. Forward secrecy: recovering later information does Describes honest operation not reveal past information But must be secure against adversarial participants Motivates using Diffie-Hellman to generate fresh keys for Seemingly simple, but many subtle problems each session Protocol notation Example: simple authentication ❆ ✦ ❇ ✿ ❆❀ ❢ ❆❀ ◆ ❣ ❑ ❆ ❆ ✦ ❇ ✿ ◆ ❇ ❀ ❢ ❚ ✵ ❀ ❇❀ ◆ ❇ ❣ ❑ ❇ E.g., Alice is key fob, Bob is garage door ❆ ✦ ❇ : message sent from Alice intended for Bob Alice proves she possesses the pre-shared key ❑ ❆ ❇ (after :): Bob’s name Without revealing it directly ❢ ✁ ✁ ✁ ❣ ❑ : encryption with key ❑ Using encryption for authenticity and binding, not secrecy Nonce Replay attacks ❆ ✦ ❇ ✿ ❆❀ ❢ ❆❀ ◆ ❣ ❑ ❆ A nonce is needed to prevent a verbatim replay of a ◆ is a nonce : a value chosen to make a message previous message unique Garage door difficulty: remembering previous nonces Best practice: pseudorandom Particularly: lunchtime/roommate/valet scenario In constrained systems, might be a counter or Or, door chooses the nonce: challenge-response device-unique serial number authentication

Man-in-the-middle attacks Chess grandmaster problem Gender neutral: middleperson attack Variant or dual of MITM Adversary impersonates Alice to Bob and Adversary forwards messages to simulate vice-versa, relays messages capabilities with his own identity Powerful position for both eavesdropping and How to win at correspondence chess modification Anderson’s MiG-in-the-middle No easy fix if Alice and Bob aren’t already related Anti-pattern: “oracle” Outline Cryptographic protocols, pt. 1 Any way a legitimate protocol service can give a Key distribution and PKI capability to an adversary Announcements intermission Can exist whenever a party decrypts, signs, etc. SSH “Padding oracle” was an instance of this at the SSL/TLS implementation level DNSSEC Public key authenticity Symmetric key servers Users share keys with server, server distributes Public keys don’t need to be secret, but they must session keys be right Symmetric key-exchange protocols, or channels Wrong key ✦ can’t stop MITM Standard: Kerberos So we still have a pretty hard distribution problem Drawback: central point of trust Certificates Certificate authorities A name and a public key, signed by someone else “CA” for short: entities who sign certificates ❈ ❆ ❂ Sign ❙ ✭ ❆❀ ❑ ❆ ✮ Simplest model: one central CA Basic unit of transitive trust Works for a single organization, not the whole world Commonly use a complex standard “X.509”

Web of trust CA hierarchies Organize CAs in a tree Pioneered in PGP for email encryption Distributed, but centralized (like DNS) Everyone is potentially a CA: trust people you know Check by follow a path to the root Works best with security-motivated users Best practice: sub CAs are limited in what they Ever attended a key signing party? certify PKI for authorization The revocation problem Enterprise PKI can link up with permissions How can we make certs “go away” when needed? One approach: PKI maps key to name, ACL maps Impossible without being online somehow name to permissions 1. Short expiration times Often better: link key with permissions directly, name 2. Certificate revocation lists is a comment 3. Certificate status checking More like capabilities Outline Note to early readers Cryptographic protocols, pt. 1 Key distribution and PKI This is the section of the slides most likely to change Announcements intermission in the final version If class has already happened, make sure you have SSH the latest slides for announcements SSL/TLS DNSSEC Outline Short history of SSH Cryptographic protocols, pt. 1 Key distribution and PKI Started out as freeware by Tatu Yl¨ onen in 1995 Announcements intermission Original version commercialized Fully open-source OpenSSH from OpenBSD SSH Protocol redesigned and standardized for “SSH 2” SSL/TLS DNSSEC

OpenSSH t-shirt SSH host keys Every SSH server has a public/private keypair Ideally, never changes once SSH is installed Early generation 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 host key Injection attacks still possible with CBC User-specific keypair CRC compensation attack Public half on server, private on client For least-insecure 1.x-compatibility, 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 ciphertext SSH to machine 1, from there to machine 2 Allows chosen plaintext attacks Common in these days of NATs Better proposal: separate, random IVs Better: have machine 1 forward an encrypted Some tricky attacks still left connection (cf. HA1) 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 Cryptographic protocols, pt. 1 When you connect to a host freshly, a mild note Key distribution and PKI When the host key has changed, a large warning Announcements intermission ❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅ ❅ ❲❆❘◆■◆●✿ ❘❊▼❖❚❊ ❍❖❙❚ ■❉❊◆❚■❋■❈❆❚■❖◆ ❍❆❙ ❈❍❆◆●❊❉✦ ❅ SSH ❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅❅ ■❚ ■❙ P❖❙❙■❇▲❊ ❚❍❆❚ ❙❖▼❊❖◆❊ ■❙ ❉❖■◆● ❙❖▼❊❚❍■◆● ◆❆❙❚❨✦ ❙♦♠❡♦♥❡ ❝♦✉❧❞ ❜❡ ❡❛✈❡s❞r♦♣♣✐♥❣ ♦♥ ②♦✉ r✐❣❤t ♥♦✇ SSL/TLS ✭♠❛♥✲✐♥✲t❤❡✲♠✐❞❞❧❡ ❛tt❛❝❦✮✦ ■t ✐s ❛❧s♦ ♣♦ss✐❜❧❡ t❤❛t ❛ ❤♦st ❦❡② ❤❛s ❥✉st ❜❡❡♥ ❝❤❛♥❣❡❞✳ DNSSEC

SSL/TLS IV chaining vulnerability Developed at Netscape in early days of the public web TLS 1.0 uses previous ciphertext for CBC IV Usable with other protocols too, e.g. IMAP But, easier to attack in TLS: SSL 1.0 pre-public, 2.0 lasted only one year, 3.0 More opportunities to control plaintext much better Can automatically repeat connection Renamed to TLS with RFC process “BEAST” automated attack in 2011: TLS 1.1 wakeup TLS 1.0 improves SSL 3.0 call TLS 1.1 and 1.2 in 2006 and 2008, only gradual adoption Compression oracle vuln. But wait, there’s more! Compr ✭ ❙ ❦ ❆ ✮ , where ❙ should be secret and ❆ is Too many vulnerabilities to mention them all in attacker-controlled lecture Kaloper-Merˇ Attacker observes ciphertext length sinjak et al. have longer list “Lessons learned” are variable, though If ❆ is similar to ❙ , combination compresses better Meta-message: don’t try this at home Compression exists separately in HTTP and TLS HTTPS hierarchical PKI Hierarchical trust? No. Any CA can sign a cert for any domain Browser has order of 100 root certs A couple of CA compromises recently Not same set in every browser Most major governments, and many companies Standards for selection not always clear you’ve never heard of, could probably make a Many of these in turn have sub-CAs ❣♦♦❣❧❡✳❝♦♠ cert Also, “wildcard” certs for individual domains Still working on: make browser more picky, compare notes CA vs. leaf checking bug MD5 certificate collisions MD5 collisions allow forging CA certs Certs have a bit that says if they’re a CA Create innocuous cert and CA cert with same hash All but last entry in chain should have it set Requires some guessing what CA will do, like sequential Browser authors repeatedly fail to check this bit serial numbers Also 200 PS3s Allows any cert to sign any other cert Oh, should we stop using that hash function?