Outline Public-key crypto basics Public key encryption and signatures CSci 5271 Announcements intermission Introduction to Computer Security Day 16: Crypto protocols and “S” protocols Cryptographic protocols, pt. 1 Stephen McCamant Key distribution and PKI University of Minnesota, Computer Science & Engineering SSL/TLS SSH 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 intermission Separate encryption key EK (public) and Cryptographic protocols, pt. 1 decryption key DK (secret) Signature scheme (generalizes MAC) Key distribution and PKI Separate signing key SK (secret) and SSL/TLS verification key VK (public) SSH 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 Private 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
Homomorphism Problems with vanilla RSA Multiply RSA ciphertexts ✮ multiply Homomorphism leads to plaintexts chosen-ciphertext attacks This homomorphism is useful for some If message and ❡ are both small interesting applications compared to ♥ , can compute ▼ ✶❂❡ Even more powerful: fully homomorphic over the integers encryption (e.g., both ✰ and ✂ ) Many more complex attacks too First demonstrated in 2009; still very inefficient Hybrid encryption Padding, try #1 Need to expand message (e.g., AES Public-key operations are slow key) size to match modulus In practice, use them just to set up PKCS#1 v. 1.5 scheme: prepend 00 01 symmetric session keys FF FF .. FF ✰ Only pay RSA costs at setup time Surprising discovery ✲ Breaks at either level are fatal (Bleichenbacher’98): allows adaptive chosen ciphertext attacks on SSL Modern “padding” Simpler padding alternative “Key encapsulation mechanism” (KEM) Much more complicated encoding For common case of public-key crypto schemes using hashing, random salts, used for symmetric-key setup Feistel-like structures, etc. Also applies to DH Common examples: OAEP for Choose RSA message r at random encryption, PSS for signing mod ♥ , symmetric key is ❍ ✭ r ✮ Progress driven largely by improvement ✲ Hard to retrofit, RSA-KEM insecure if ❡ in random oracle proofs and r reused with different ♥
Box and locks revisited Outline Public-key crypto basics Alice and Bob’s box scheme fails if an Public key encryption and signatures intermediary can set up two sets of boxes Announcements intermission Man-in-the-middle (or middleperson) Cryptographic protocols, pt. 1 attack Real world analogue: challenges of Key distribution and PKI protocol design and public key SSL/TLS distribution SSH Schedule changes this week HA2 available soon Performing some final testing now My Tuesday office hour is canceled Register groups with Se Eun as for HA1 Wednesday will be a guest lecture on SFI Delete your HA1 VM first Receive group number and host info by Real topic, with reading and exam email coverage Also coming up next week Outline Public-key crypto basics Public key encryption and signatures Exercise set 3 on crypto Announcements intermission Posted Sunday, due Thursday 11/9 Cryptographic protocols, pt. 1 Second project progress reports due Wednesday 11/8 Key distribution and PKI SSL/TLS SSH
A couple more security goals Abstract protocols Outline of what information is Non-repudiation: principal cannot later communicated in messages deny having made a commitment Omit most details of encoding, naming, I.e., consider proving fact to a third party sizes, choice of ciphers, etc. Forward secrecy: recovering later Describes honest operation information does not reveal past But must be secure against adversarial information participants Motivates using Diffie-Hellman to generate Seemingly simple, but many subtle fresh keys for each session problems Protocol notation Example: simple authentication ❆ ✦ ❇ ✿ ❆❀ ❢ ❆❀ ◆ ❣ ❑ ❆ ❆ ✦ ❇ ✿ ◆ ❇ ❀ ❢ ❚ ✵ ❀ ❇❀ ◆ ❇ ❣ ❑ ❇ E.g., Alice is key fob, Bob is garage door ❆ ✦ ❇ : message sent from Alice Alice proves she possesses the intended for Bob 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 previous message ◆ is a nonce : a value chosen to make Garage door difficulty: remembering a message unique previous nonces Best practice: pseudorandom Particularly: lunchtime/roommate/valet In constrained systems, might be a scenario counter or device-unique serial number Or, door chooses the nonce: challenge-response authentication
Man-in-the-middle attacks Chess grandmaster problem Gender neutral: middleperson attack Variant or dual of MITM Adversary impersonates Alice to Bob Adversary forwards messages to and vice-versa, relays messages simulate capabilities with his own Powerful position for both identity eavesdropping and modification How to win at correspondence chess No easy fix if Alice and Bob aren’t Anderson’s MiG-in-the-middle already related Outline Public key authenticity Public-key crypto basics Public key encryption and signatures Public keys don’t need to be secret, but Announcements intermission they must be right Wrong key ✦ can’t stop MITM Cryptographic protocols, pt. 1 So we still have a pretty hard Key distribution and PKI distribution problem SSL/TLS SSH Symmetric key servers Certificates Users share keys with server, server A name and a public key, signed by someone else distributes session keys ❈ ❆ ❂ Sign ❙ ✭ ❆❀ ❑ ❆ ✮ 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 Public-key crypto basics How can we make certs “go away” Public key encryption and signatures when needed? Announcements intermission Impossible without being online Cryptographic protocols, pt. 1 somehow 1. Short expiration times Key distribution and PKI 2. Certificate revocation lists SSL/TLS 3. Certificate status checking SSH
Recommend
More recommend
