Outline Public-key crypto basics Public key encryption and signatures CSci 5271 Introduction to Computer Security Announcements Day 16: Cryptographic protocols and failures Cryptographic protocols Stephen McCamant HW1 debrief University of Minnesota, Computer Science & Engineering More causes of crypto failure Pre-history of public-key crypto Box and locks analogy Alice wants to send Bob a gift in a First invented in secret at GCHQ locked box Proposed by Ralph Merkle for UC They don’t share a key Can’t send key separately, don’t trust UPS Berkeley grad. security class project Box locked by Alice can’t be opened by First attempt only barely practical Bob, or vice-versa Professor didn’t like it Merkle then found more sympathetic Stanford collaborators named Diffie and Hellman Box and locks analogy Public key primitives Alice wants to send Bob a gift in a locked box Public-key encryption (generalizes They don’t share a key block cipher) Can’t send key separately, don’t trust UPS Separate encryption key EK (public) and Box locked by Alice can’t be opened by decryption key DK (secret) Bob, or vice-versa Signature scheme (generalizes MAC) Math perspective: physical locks Separate signing key SK (secret) and commute verification key VK (public)
Modular arithmetic Generators and discrete log Fix modulus ♥ , keep only remainders Modulo a prime ♣ , non-zero values and mod ♥ ✂ have a nice (“group”) structure mod 12: clock face; mod ✷ ✸✷ : ✐♥t ❣ is a generator if ❣ ✵ ❀ ❣❀ ❣ ✷ ❀ ❣ ✸ ❀ ✿ ✿ ✿ ✰ , ✲ , and ✂ work mostly the same cover all elements Division: see Exercise Set 1 Easy to compute ① ✼ ✦ ❣ ① Exponentiation: efficient by square and Inverse, discrete logarithm , hard for multiply large ♣ Diffie-Hellman key exchange Relationship to a hard problem Goal: anonymous key exchange We’re not sure discrete log is hard Public parameters ♣ , ❣ ; Alice and Bob (likely not even NP-complete), but it’s have resp. secrets ❛ , ❜ been unsolved for a long time Alice ✦ Bob: ❆ ❂ ❣ ❛ ✭ mod ♣ ✮ If discrete log is easy (e.g., in P), DH is Bob ✦ Alice: ❇ ❂ ❣ ❜ ✭ mod ♣ ✮ insecure Alice computes ❇ ❛ ❂ ❣ ❜❛ ❂ ❦ Converse might not be true: DH might Bob computes ❆ ❜ ❂ ❣ ❛❜ ❂ ❦ have other problems Categorizing assumptions Key size, elliptic curves Need key sizes ✘ 10 times larger then Math assumptions unavoidable, but can security level categorize Attacks shown up to about 768 bits E.g., build more complex scheme, Elliptic curves: objects from higher math shows it’s “as secure” as DH because it with analogous group structure has the same underlying assumption (Only tenuously connected to ellipses) Commonly “decisional” (DDH) and Elliptic curve algorithms have smaller “computational” (CDH) variants keys, about 2 ✂ security level
Outline General description Public-key crypto basics Public-key encryption (generalizes Public key encryption and signatures block cipher) Announcements Separate encryption key EK (public) and decryption key DK (secret) Cryptographic protocols Signature scheme (generalizes MAC) Separate signing key SK (secret) and HW1 debrief verification key VK (public) More causes of crypto failure RSA setup RSA encryption Choose ♥ ❂ ♣q , product of two large Public key is ✭ ♥❀ ❡ ✮ primes, as modulus Encryption of ▼ is ❈ ❂ ▼ ❡ ✭ mod ♥ ✮ ♥ is public, but ♣ and q are secret Secret key is ✭ ♥❀ ❞ ✮ Compute encryption and decryption Decryption of ❈ is ❈ ❞ ❂ ▼ ❡❞ ❂ ▼ exponents ❡ and ❞ such that ✭ mod ♥ ✮ ▼ ❡❞ ❂ ▼ ✭ mod ♥ ✮ RSA signature RSA and factoring Signing key is ✭ ♥❀ ❞ ✮ We’re not sure factoring is hard (likely Signature of ▼ is ❙ ❂ ▼ ❞ ✭ mod ♥ ✮ not even NP-complete), but it’s been unsolved for a long time Verification key is ✭ ♥❀ ❡ ✮ Check signature by ❙ ❡ ❂ ▼ ❞❡ ❂ ▼ If factoring is easy (e.g., in P), RSA is insecure ✭ mod ♥ ✮ Converse might not be true: RSA might Note: symmetry is a nice feature of have other problems RSA, not shared by other systems
Aside: stronger reduction Homomorphism Public-key algorithms actually Multiply RSA ciphertexts ✮ multiply equivalent to factoring and discrete log plaintexts exist This homomorphism is useful for some But not widely used because of speed or interesting applications other efficiency issues Even symmetric-key algorithms with Even more powerful: fully homomorphic such security encryption (e.g., both ✰ and ✂ ) But they’re much less efficient than AES First demonstrated in 2009; still very et al. inefficient Problems with vanilla RSA Hybrid encryption Homomorphism leads to Public-key operations are slow chosen-ciphertext attacks In practice, use them just to set up If message and ❡ are both small symmetric session keys compared to ♥ , can compute ▼ ✶❂❡ ✰ Only pay RSA costs at setup time over the integers ✲ Breaks at either level are fatal Many more complex attacks too Padding, try #1 Modern “padding” Need to expand message (e.g., AES Much more complicated encoding key) size to match modulus schemes using hashing, random salts, Feistel-like structures, etc. PKCS#1 v. 1.5 scheme: prepend 00 01 FF FF .. FF Common examples: OAEP for encryption, PSS for signing Surprising discovery (Bleichenbacher’98): allows adaptive Progress driven largely by improvement chosen ciphertext attacks on SSL in random oracle proofs
Simpler padding alternative Box and locks revisited “Key encapsulation mechanism” (KEM) Alice and Bob’s box scheme fails if an For common case of public-key crypto intermediary can set up two sets of used for symmetric-key setup boxes Also applies to DH Real world analogue: challenges of Choose RSA message r at random protocol design and public key mod ♥ , symmetric key is ❍ ✭ r ✮ distribution ✲ Hard to retrofit, RSA-KEM insecure if ❡ and r reused with different ♥ Outline Upcoming assignments Public-key crypto basics Public key encryption and signatures Exercise set 3 due Thursday night Announcements Project meetings continue this week Cryptographic protocols Progress report: due Monday 11/4 HW1 debrief More causes of crypto failure Grades on Moodle Crypto textbook show and tell 4/5 Ex 1, HW1, midterm all posted Schneier, Applied Cryptography Note HW1 split 8 + 92 Historically important, fun, not up to Current estimate of weighted average date and letter grade Arguably led to many insecure systems Formula by hand, syllabus is authoritative
Outline A couple more security goals Public-key crypto basics Non-repudiation: principal cannot later Public key encryption and signatures deny having made a commitment I.e., considers proving fact to a third party Announcements Forward secrecy: recovering later Cryptographic protocols information does not reveal past information HW1 debrief Motivates using Diffie-Hellman to generate fresh keys for each session 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 Example: simple authentication Nonce ❆ ✦ ❇ ✿ ❆❀ ❢ ❆❀ ◆ ❣ ❑ ❆ ❆ ✦ ❇ ✿ ❆❀ ❢ ❆❀ ◆ ❣ ❑ ❆ E.g., Alice is key fob, Bob is garage door ◆ is a nonce : a value chosen to make Alice proves she possesses the a message unique pre-shared key ❑ ❆ Best practice: pseudorandom Without revealing it directly In constrained systems, might be a Using encryption for authenticity and counter or device-unique serial number binding, not secrecy
Replay attacks Man-in-the-middle attacks A nonce is needed to prevent a Gender neutral: middleperson attack verbatim replay of a previous message Adversary impersonates Alice to Bob Garage door difficulty: remembering and vice-versa, relays messages previous nonces Powerful position for both Particularly: lunchtime/roommate/valet eavesdropping and modification scenario No easy fix if Alice and Bob aren’t Or, door chooses the nonce: already related challenge-response authentication Chess grandmaster problem Needham-Schroeder Variant or dual of MITM Authenticated key exchange assuming Adversary forwards messages to public keys (core): simulate capabilities with his own ❆ ✦ ❇ ✿ ❢ ◆ ❆ ❀ ❆ ❣ ❑ ❇ identity ❇ ✦ ❆ ✿ ❢ ◆ ❆ ❀ ◆ ❇ ❣ ❑ ❆ How to win at correspondence chess ❆ ✦ ❇ ✿ ❢ ◆ ❇ ❣ ❑ ❇ Anderson’s MiG-in-the-middle Needham-Schroeder MITM Certificates, Denning-Sacco A certificate signed by a trusted ❆ ✦ ❈ ✿ ❢ ◆ ❆ ❀ ❆ ❣ ❑ ❈ third-party ❙ binds an identity to a public key ❈ ✦ ❇ ✿ ❢ ◆ ❆ ❀ ❆ ❣ ❑ ❇ ❈ ❆ ❂ Sign ❙ ✭ ❆❀ ❑ ❆ ✮ ❇ ✦ ❈ ✿ ❢ ◆ ❆ ❀ ◆ ❇ ❣ ❑ ❆ Suppose we want to use S in ❈ ✦ ❆ ✿ ❢ ◆ ❆ ❀ ◆ ❇ ❣ ❑ ❆ establishing a session key ❑ ❆❇ : ❆ ✦ ❈ ✿ ❢ ◆ ❇ ❣ ❑ ❈ ❆ ✦ ❙ ✿ ❆❀ ❇ ❈ ✦ ❇ ✿ ❢ ◆ ❇ ❣ ❑ ❇ ❙ ✦ ❆ ✿ ❈ ❆ ❀ ❈ ❇ ❆ ✦ ❇ ✿ ❈ ❆ ❀ ❈ ❇ ❀ ❢ Sign ❆ ✭ ❑ ❆❇ ✮ ❣ ❑ ❇
Recommend
More recommend
