Selected Topics CIS 400
Popular in Course
Popular in Computer & Information Science
This 17 page Class Notes was uploaded by Lindsay Bergstrom Sr. on Wednesday October 21, 2015. The Class Notes belongs to CIS 400 at Syracuse University taught by Staff in Fall. Since its upload, it has received 28 views. For similar materials see /class/225601/cis-400-syracuse-university in Computer & Information Science at Syracuse University.
Reviews for Selected Topics
Report this Material
What is Karma?
Karma is the currency of StudySoup.
Date Created: 10/21/15
CRYPTOGRAPHIC PROTOCOLS CIS 400628 Spring 2005 Introduction to Cryptography This is based on Chapters 14 and 15 of Practical Cryptography by Niels Ferguson and Bruce Schneier THE SECURE CHANNEL l A secure channel a secure connnection between two parties A basic tool in crypto protocols Roles Alice Bob Eve Key Alice and Bob share a secret key K Requirements gt K is known only to Alice and Bob gt Every time the secure channel is initialized a new value is generated for K Messages A sequence of discrete messages Assumption gt The transport layer is not reliable Eg TCPIP is reliable against random events but not an active and clever attacker More THE SECURE CHANNEL ll Security Properties Secrecy Eve does not learn anything about the messages sent except their timing and size No Junk If Alice sends m1 m2 Bob receives a subsequence m3 m 2 le dropping some maybe none messages from m1 m2 produces m l m 2 Bob can always request a resend of missing info Authentication amp encryption Which first For details See Chapter 8 of F5 but 2 THE SECURE CHANNEL OUTLINE Message Numbering gt Why gt Number 1 through 232 1 After 232 1 messages refresh the key Authentication gt Use a standard MAC HMACSHA256 gt For message 72 az 2 ac context data for Bob the length in bytes of ac Encryption gt Use AES in CTR mode gt Messages no larger than 16 232 bytes Frame Format 72 coded as a 32bit integer least significant byte first followed by the encrypted mi and Li 3 PRACTICAL PARANOIA gt The function of a crypto protocol is to minimize the amount of trust required in a transaction This involves o minimizing the number of agents involved 0 minimizing the need of these agents to trust each other gt The paranoia model all other agents are out to cheat you perhaps in collusion gt In a protocol any point of deviation from this model must be documented The SSL example gt Each point of required trust implies a risk to be dealt with LAYERS OF PROTOCOLS the high level description protocol execution states message encoding and parsing protocol and message ids the transport layer The Transport layer gt Eg TCPIP gt Should be able to send arbitrary sized messages gt A secure channel makes everything easier but we don t always have one LAYERS OF PROTOCOLS ll Protocol and Message IDs gt A message needs to contain a what protocol it belongs to and a what part of the protocol it is gt These are not secure gt They help detect and protect against accidental errors Message Encoding and Parsing gt The encoding has to be flexible enough to handle variable length messages gt Fixed length fields are simple but they seldom survive version changes Protocol Execution States gt Eventdriven A statemachine is a good idea PROTOCOL PLUMBING ERRORS Dealing with errors gt Given the dirty environment they are operating in there are many possible errors in a protocol gt However errors are a potential way to attack a system gt Give as little away as possible as to what the problem was In a cypto context There was an error is info enough gt The time it takes to detect and reply to an error can also give away information Timing attacks gt The smart card PIN example PROTOCOL PLUMBING REPLAYS AND RETRIES A replay attack Eve records a message and later sends that message again A retry Alice didn t get an acknowledgement from Bob about the last mes sages so she sends it again How is Bob to securely handle repeated messages Upon receiving a message gt If it is the one expected do the normal things gt If it is a message from the future eg expecting 8 receiving 23 ignore it gt If it is a message from the past 0 If it is identical to one previous received then send the identical reply 0 If it has the same message ID as a previous one but has different contents treat as a protocol error 0 If it is a really old message the safe thing is to ignore it A DH PROTOCOL Goal Alice and Bob want to agree on a secret session key for a secure channel Assumption We assume AampB can authenticate messages to one another AampB may have a shared secret key for authentication Question If they already share a secret key why bother with another Answer gt Compartmentalization just like in spy networks gt If the session key is compromised the longterm key is safe gt If the longterm key is compromised and Eve hasn t recorded yester day s key negociation then yesterday s exchanges are safe A FIRST TRY Setup Alice and Bob know p qg where p 2 2q 1 and q are primes g 75 1 but 9 1 E 1 mod p Alice Chooses as E Z2 and sends X gwmodp to Bob Bob Chooses y 1 Z3 sends Y gymodp to Alice and computes k Xymodp Alice Computes k Ya3modp and sends AuthAk to Bob Bob Sends AuthBk to Alice Henceforth we drop the modp s PROBLEMS WITH THE FIRST TRY gt Using constants for p qg is a bad idea gt It can be done with fewer messages gt Using It in the authentication messages is a bad idea Use one secret for one purpose only Eg If the authentication method is weak a few bits of It could leak gt The authentication messages are too similar Eg If AuthX is based on a symmetric cyrptosystem then AuthAk AuthBk Why should Alice beleive the message is really from Bob gt We have to be sure that It isn t used until the authentications check out NOTES Protocols last forever gt So they need to be designed to be future proof gt Eg that is why having p qg is a bad idea gt A protocol switchrollback is a point of attack Authentication conventions gt At any point in the protocol the authentication data consists of all data exchanged so far Eg In try 1 Alice s authentication data we consist of X and Y and Bob s would be X Y and AuthA gt This is reasonably cheap and stops lots of attacks gt Henceforth AuthA Alice s authentication message at this point of the protocol AuthB Bob s authentication message at this point of the protocol A SECOND TRY Alice Chooses p qg and an E Z and computes X 9 Sends p q 9 X AuthA to Bob Bob Checks p q 9 X AuthA chooses y 1 Z3 and computes Y gy Sends Y AuthB to Alice Computes k Xy Alice Checks Y AuthB Computes k 2 Y5 PROBLEMS gt What if Bob is fussier than Alice and wants bigger primes gt How can Bob tell his is really talking to Alice and not a replay ghost 17 A THIRD TRY Alice Chooses s min size ofp and NA 6 0 2256 1 Sends sNA to Bob NA is a nonce Bob Chooses p qg and an 1 Z3 Computes X 9 Sends p q 9 X AuthB to Alice Alice Checks p qg X AuthB Chooses y 6 ZS Computes Y 93 Sends Y AuthA to Bob Computes k Xy Bob Checks Y AuthA and computes k 2 Y5 PROBLEMS gt k is of variable size gt k has algebraic structure FOURTH TRY Alice Chooses s min size ofp and NA 6 0 2256 1 Sends sNA to Bob NA is a nonce Bob ran Chooses p qg and an 6 ZS Computes X 9 Sends p q 9 X AuthB to Alice Alice Checks p qg X AuthB Chooses y 6 ZS Computes Y gy Sends Y AuthA to Bob Computes k SHAd256Xy Bob Checks Y AuthA Computes k SHAd256Y 3 See page 270 of F345 for the long form KEY COMPROMISE Alice loses her authentication key without the knowledge of Eve She can t run the protocol but can use already established session keys If Alice loses her session key without the knowledge of Eve She reruns the protocol to get a new session key Eve steals Alice s authentication key Eve can impersonate Alice until Bob finds out the problem However previous AliceBob communications are still secure Forward secrecy Eve steals Alice s session key k k provides no info about other session keys or about Alice and Bob s authentication keys