Outline Cryptographic protocols, cont’d More causes of crypto failure CSci 5271 Key distribution and PKI Introduction to Computer Security HW1 debrief Day 17: PKI and ‘S’ protocols Stephen McCamant SSH University of Minnesota, Computer Science & Engineering SSL/TLS DNSSEC Robot-in-the-middle attacks Envelopes analogy Adversary impersonates Alice to Bob Encrypt then sign, or vice-versa? and vice-versa, relays messages On paper, we usually sign inside an Powerful position for both envelope, not outside. Two reasons: eavesdropping and modification Attacker gets letter, puts in his own envelope (c.f. attack against X.509) No easy fix if Alice and Bob aren’t Signer claims “didn’t know what was in already related the envelope” (failure of non-repudiation) Design robustness principles Implementation principles Use timestamps or nonces for Ensure unique message types and freshness parsing Be explicit about the context Design for ciphers and key sizes to Don’t trust the secrecy of others’ change secrets Limit information in outbound error Whenever you sign or decrypt, beware messages of being an oracle Be careful with out-of-order messages Distinguish runs of a protocol
Outline Random numbers and entropy Cryptographic protocols, cont’d Cryptographic RNGs use cipher-like More causes of crypto failure techniques to provide indistinguishability But rely on truly random seeding to Key distribution and PKI stop brute force HW1 debrief Extreme case: no entropy ✦ always same “randomness” SSH Modern best practice: seed pool with SSL/TLS 256 bits of entropy Suitable for security levels up to ✷ ✷✺✻ DNSSEC Netscape RNG failure Debian/OpenSSL RNG failure (1) Early versions of Netscape SSL OpenSSL has pretty good scheme (1994-1995) seeded with: using ✴❞❡✈✴✉r❛♥❞♦♠ Time of day Also mixed in some uninitialized Process ID variable values Parent process ID “Extra variation can’t hurt” Best case entropy only 64 bits From modern perspective, this was the (Not out of step with using 40-bit original sin encryption) Remember undefined behavior discussion? But worse because many bits But had no immediate ill effects guessable Debian/OpenSSL RNG failure (2) Detected RSA/DSA collisions Up to about 1% of the SSL and SSH Debian maintainer commented out keys on the public net are breakable some lines to fix a Valgrind warning Some sites share complete keypairs “Potential use of uninitialized value” RSA keys with one prime in common Accidentally disabled most entropy (all (detected by large-scale GCD) One likely culprit: insufficient entropy in but 16 bits) key generation Brief mailing list discussion didn’t lead Embedded devices, Linux ✴❞❡✈✴✉r❛♥❞♦♠ to understanding vs. ✴❞❡✈✴r❛♥❞♦♠ Broken library used for ✘ 2 years before DSA signature algorithm also very discovery 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 Trustworthiness of primitives Only true crypto weakness Classic worry: DES S-boxes RC4 “key schedule” vulnerable when: Obviously in trouble if cipher chosen by RC4 keys very similar (e.g., same key, your adversary similar IV) In a public spec, most worrying are First stream bytes used unexplained elements Not a practical problem for other RC4 Best practice: choose constants from users like SSL well-known math, like digits of ✙ Key from a hash, skip first output bytes
Dual EC DRBG (1) Dual EC DRBG (2) Found 2007: special choice of Pseudorandom generator in NIST constants allows prediction attacks standard, based on elliptic curve Big red flag for paranoid academics Looks like provable (slow enough!) but Significant adoption in products sold to strangely no proof US govt. FIPS-140 standards Specification includes long unexplained Semi-plausible rationale from RSA (EMC) constants NSA scenario basically confirmed Academic researchers find: recently by Snowden leaks Some EC parts look good NIST and RSA immediately recommend But outputs are statistically distinguishable withdrawal Outline Public key authenticity Cryptographic protocols, cont’d More causes of crypto failure Public keys don’t need to be secret, but Key distribution and PKI they must be right Wrong key ✦ can’t stop MITM HW1 debrief So we still have a pretty hard SSH distribution problem SSL/TLS DNSSEC Symmetric key servers Certificates Users share keys with server, server A name and a public key, signed by distributes session keys someone else Symmetric key-exchange protocols, or Basic unit of transitive trust channels Commonly use a complex standard Standard: Kerberos “X.509” Drawback: central point of trust
Certificate authorities Web of trust Pioneered in PGP for email encryption “CA” for short: entities who sign Everyone is potentially a CA: trust certificates people you know Simplest model: one central CA Works best with security-motivated Works for a single organization, not the users whole world Ever attended a key signing party? CA hierarchies PKI for authorization Enterprise PKI can link up with Organize CAs in a tree permissions Distributed, but centralized (like DNS) One approach: PKI maps key to name, Check by follow a path to the root ACL maps name to permissions Best practice: sub CAs are limited in Often better: link key with permissions what they certify directly, name is a comment More like capabilities The revocation problem Outline Cryptographic protocols, cont’d How can we make certs “go away” More causes of crypto failure when needed? Key distribution and PKI Impossible without being online HW1 debrief somehow 1. Short expiration times SSH 2. Certificate revocation lists SSL/TLS 3. Certificate status checking DNSSEC
BCVS vulnerabilities BCVS exploiting overflows Make sure control flow reaches the Type 1: Buffer overflows and similar return Some easy to spot, but hard to exploit Type 2: Logic errors in running Compensate for collateral damage programs, file accesses, etc. Find your shellcode Usually easier to exploit once found Writing shellcode BCVS design changes Final crypto textbook show and tell Avoid unnecessary changes to benign Paar and Pelzl, Understanding functionality Cryptography Restricting length or character sets of arguments A real textbook, but pretty practical Though, what is the benign functionality? Gives full details of DES and AES, for Not a great candidate for privilege instance separation Outline Short history of SSH Cryptographic protocols, cont’d Started out as freeware by Tatu Yl¨ onen More causes of crypto failure in 1995 Key distribution and PKI Original version commercialized HW1 debrief Fully open-source OpenSSH from SSH OpenBSD Protocol redesigned and standardized SSL/TLS for “SSH 2” 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 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
Recommend
More recommend
