CRYPTOGRAPHic Protocols and Diffie-Hellman-Merkle Key Exchange Dr. Suzanne Buchele (A lot of content borrowed from Ed Crowley at The University of Houston)

Symmetric Cryptography Overview Classic cryptography Shared secrete key encrypts and decrypts Fast Ideal for bulk encryption 1000 to 10,000 times faster than public key cryptography. Problematic Key Management Both parties must already have the shared secret key Does not scale well A system with N users requires N(N-1)/2 keys Can provide confidentiality, with other protocols also integrity, and authentication

Asymmetric Key Overview Relatively new cryptographic technology Utilizes two different, but mathematically related, keys. Normally, public key is widely distributed Only one person possesses private key (bound to identity) A message encrypted with one key can only be decrypted with the other. In most cases, utilizes a relatively large key Solves classic cryptography key management problem Only 2N keys needed for N entities Relatively slow Depending on how employed, may provide confidentiality, integrity, authentication, and/or non-repudiation though, not all at the same time

Asymmetric Cryptography Algorithms RSA Used for encryption and digital signatures El Gamal Used in DSA, for digital signatures Diffie-Hellman Allows two parties that have no prior knowledge of each other to jointly establish a shared secret key over an insecure communications channel. Elliptic Curve Uses algebraic system defined on points of elliptic curve to provide public-key algorithms Of all public key systems, highest strength per bit Requires less computational and memory requirements

Hybrid Cryptosystems Typical hybrid systems use public key cryptography to distribute symmetric keys. Asymmetric key for key distribution of symmetric keys Symmetric key for bulk data encryption Symmetric keys typically temporary session keys Limited lifespan, so that quantity of data encrypted with any one key is limited So cryptanalysis is hampered Recall we don’t use previous symmetric keys to encrypt the next symmetric key, since compromise of any one key would compromise them all

Diffie-Hellman-Merkle Key Exchange Subjects exchange secret keys over an insecure communications channel without exposing the keys Introduced the notion of public key cryptography Actually predates RSA Used for symmetric key distribution Not used to encrypt and decrypt messages. Is a practical method for public exchange of a secret key Used by IKE (Internet Key Exchange Protocol), a standard protocol used for secure communications in the IPsec protocol suite

Diffie-Hellman-Merkle Key Exchange (cont) Used for two parties with no prior knowledge of each other or shared information to establish a common, shared key Although communication between them is insecure, resultant shared key is secure Seems like magic… Based on principles similar to RSA cryptography Exponentiation modulo a prime Security relies on the difficulty of computing discrete logarithms Given m, n, and y, can’t determine x such that mx mod n = y

Diffie-Hellman-Merkle Summary All users agree on global parameters: Often proposed by entity initiating the key exchange Large prime integer (or polynomial ) q Also select g, a “primitive root” mod q Each user (eg. Alice, Bob) generates their keys Chooses a secret key (number): x < q Computes their public key: y = gx mod q Shared session key for users Alice & Bob is KAB: KAB = gxA.xB mod q = (gxA)xB mod q = (gxB)xA mod q

Primitive Roots Recall Euler’s theorem: m(p-1)(q-1)mod p*q = 1 Consider: mk mod n = 1 for m, n such that GCD(m,n)=1 Know it works for k = (p-1)(q-1), but could be one smaller If smallest is k = (p-1)(q-1) then m is called a primitive root of n Has the property that successive powers of m (mod n) are all distinct (mod n) E.g. m mod n, m2 mod n, m3 mod n, m4 mod n, ..., mk-1 mod n are all different and in the range 0...n-1 (by def of mod) By using m, a primitive root of n, then it is hardest for someone to guess x such that mx mod n = y This is the heart of the security of the Diffie-Hellman- Merkle algorithm

Diffie-Hellman-Merkle Algorithm Users Alice and Bob want to agree on a shared key Alice chooses s large prime integer q Example: q = 353 Alice also selects g, (preferrably) a primitive root mod q Example: g = 3 Alice sends q and g insecurely to Bob Alice and Bob each generate their keys Alice chooses her secret key: xA < q Example: xA = 97 Bob chooses his secret key: xB < q Example: xB = 233

Diffie-Hellman-Merkle Algorithm (cont) Global parameters: q = 353, g = 3 Alice’s secret key: xA = 97, Bob’s secret key: xB = 233 Alice computes her public key: yA = gxA mod q Example: 397 mod 353 = 40 Bob computes his public key: yB = gxB mod q Example: 3233 mod 353 = 248 So, public parameters: q = 353, g = 3, yA = 40, yB = 248 Shared session key for users Alice & Bob is KAB: KAB = gxA.xB mod q = (gxA)xB mod q = (yA)xB mod q (which Bob can compute) (gxB)xA mod q = (yB)xA mod q (which Alice can compute)

Diffie-Hellman-Merkle Algorithm (cont) Public parameters: q = 353, g = 3, yA = 40, yB = 248 Alice’s secret key is xA = 97 Alice computes the shared secret key: (gxB)xA mod q = (yB)xA mod q = 24897 mod 353 = 160 Bob’s secret key is xB = 233 Bob computes the shared secret key: (gxA)xB mod q = (yA)xB mod q = 40233 mod 353 = 160 So, both Alice and Bob arrive at the same shared secret key (160) with all communication between them done insecurely!

Diffie-Hellman-Merkle Uses and Security Shared secret key is then the session key for symmetric encryption for one session of communication between Alice and Bob For the next session, Alice and Bob need to choose new public keys Or they will end up with the same session key Public keys (prime number and exponents) are typically 1024 bits in length (≈300 decimal digits) Attacker needs to be able to solve for x, given m, q, and y, where (discrete log problem): y = gx mod q No known algorithm to do this other than brute-force search

Cryptographic Protocols A protocol is an agreed-upon sequence of actions performed by two or more entities Cryptographic protocols make use of cryptography to accomplish some task (usually securely) Example: How can Alice and Bob agree on a shared session key to protect a conversation? Answer: use a key-exchange cryptographic protocol E.g. Diffie-Hellman-Merkle Key Exchange Protocol There are others (some we have seen before…)

Key Exchange Using Only Symmetric Cryptography Assume Alice and Bob each share a key with a Key Distribution Center (KDC) KA is the key shared by Alice and the KDC KB is the key shared by Bob and the KDC To agree on a session key: Alice requests a session key for Bob and her from the KDC KDC generates a random session key, encrypts it with both KA and KB, and sends to Alice Alice decrypts part of the message encrypted with KA and learns the session key Alice sends part of the message encrypted with KB to Bob Bob receives Alice’s message, decrypts it to learn session key Alice and Bob communicate securely using the session key

Key Exchange Using Only Symmetric Cryptography The key-exchange protocol: A: => KDC (A,B) KDC: => A (Encrypt(KAB,KA) || E(KAB,KB)) A: => B (Encrypt(KAB,KB)) Problems? Replay attack: An intruder, Eve, watches them do this and stores the KDC’s message to Alice and all the subsequent messages between Alice Bob encrypted with KAB Eve cryptanalyzes the session and eventually recovers KAB The next time Alice and Bob want to talk Eve intercepts the KDC’s reply and replays the old message containing KAB Alice and Bob conduct a “secure” conversation which is protected by KAB which is known to Eve

Simple Symmetric Cryptography Key Exchange Problems Alice and Bob need to be able to distinguish between a current (or fresh) response from the KDC and an old one Solutions: Alice and Bob could keep track of all previously-used session keys and never accept an old session key KDC could include freshness information in its messages Nonces Timestamps Alice and Bob’s clocks must both synchronized with the KDC’s Alice and Bob both check the KDC’s message to make sure it was generated recently

Key Exchange Using Only Symmetric Cryptography N’s here could be Nonces or Timestamps

Key Exchange Using Public Key Cryptography (Simple Protocol) Alice learns Bob’s public key (by either asking Bob or some third party) Alice generates a random session key, KAB Alice encrypts the session key with Bob’s public key Alice sends Encrypt(KAB,BPublic) to Bob Bob receives Alice’s message and decrypts it with his private key Alice and Bob now share the secret key KAB and encrypt their subsequent communications with KAB

Simple Key Exchange Using Public Key Cryptography – Problem Recall the man-in-the-middle attack: If Eve can trick Alice into thinking that EPublic is Bob’s public key, then Eve can decrypt Alice’s first message to Bob: Encrypt(KAB,EPublic) Eve learns the proposed session key KAB Eve can send Bob: Encrypt(KAB,BPublic) Alice and Bob will encrypt their subsequent communications with KAB thinking that it is secure This can be a very serious problem because it’s sometimes difficult to be sure you know somebody’s public key

The Interlock Protocol, aka Bit Commitment (Not in Readings) Combating the man-in-the-middle attack: Alice and Bob exchange public keys Alice encrypts her message using Bob’s public key. Alice sends half the encrypted message to Bob (e.g. every other bit) Bob encrypts his message using Alice’s public key. Bob sends half the encrypted message to Alice (e.g. every other bit) Alice sends the other half of her encrypted message to Bob. Bob puts the two halves together and decrypts them using his private key Bob sends the other half of his encrypted message to Alice. Alice puts the two halves together and decrypts them using her private key

Why the Interlock Protocol Works Assume Eve can trick Alice into using EPublic instead of BPublic When Eve receives the first half of Alice’s message she won’t be able to decrypt it and re-encrypt it with Bpublic because it is only half of the encrypted message You can’t decrypt half a message! Eve must invent a completely new message, encrypt it and send half of it to Bob When the second half of Alice’s message arrives, Eve can put the two halves together, decrypt, and learn what Alice’s original message was… However, Eve has already committed to the first and second halves of the message and sent it to Bob, it is too late to change Therefore Alice and Bob will be able to figure out that there is an intruder between them

Interlock Protocol and Public Key Crypto Key Exchange Protocol The Interlock Protocol can be used with key exchange using public key cryptography to ensure that the information being sent back and forth is not subject to a Man-in-the-Middle attack: When Alice sends the session key to Bob, encrypted with Bob’s public key, she first sends only ½ the bits Bob sends an acknowledgement including a nonce, encrypted with Alice’s public key, but sends only ½ the bits Then Alice sends the other ½ of the bits of the session key Then Bob sends the other ½ of the bits of the acknowledgement and nonce They should now share a secret key, Alice can send Bob’s nonce back to him using their newly shared secret key

Interlock Protocol Security Bob won’t send the first half of his acknowledgement (encrypted with APublic) until Alice sends first half of proposed key (encrypted with BPublic). If Eve tries to get in the middle, she won’t know how to decrypt ½ a message, and if she tries to make a message up, it won’t match the 2nd half of the messages that come later. Alice doesn’t send the 2nd half of the proposed key until she receives the acknowledgement from Bob If later 2nd half of acknowledegement, when put together with 1st half, doesn’t make sense, she knows there was a problem

One-way Authentication Protocol Using Symmetric-Key Cryptography Assume that Alice and Bob share a secret symmetric key, KAB One-way authentication protocol (Challenge and Response: Alice creates a nonce, NA, and sends it to Bob as a challenge Bob encrypts Alice’s nonce with their secret key and returns the result, Encrypt(NA, KAB), to Alice Alice can decrypt Bob’s response and verify that the result is her nonce A: => B(NA); B: => A(Encrypt(NA, KAB));

Two-way Authentication Protocol Using Symmetric-Key Cryptography Two-way authentication protocol (Challenge and Response: Alice creates a nonce, NA, and sends it to Bob as a challenge Bob encrypts Alice’s nonce with their secret key and appends his own nonce, NB, and returns the result, NB || Encrypt(NA, KAB), to Alice Alice can decrypt Bob’s response and verify that the result is her nonce, and send back to Bob Bob’s nonce encrypted with their shared secret key A: => B(NA) B: => A(NB||Encrypt(NA, KAB)) A: => B(Encrypt(NB, KAB))

Two-way Authentication Protocol – Problem #1 Eve tricks Bob into creating the correct response to the nonce for her: A: => E(NA) (here Eve is impersonating Bob) E: => B(NA) (here Eve is impersonating Alice) B: => E(NB||Encrypt(NA, KAB)) E: => A(E(NB||Encrypt(NA, KAB)) A: => E(Encrypt(NB, KAB)) E: => B(Encrypt(NB, KAB)) This is the classic Man-in-the-Middle attack Note that Eve still doesn’t know KAB, but, Eve is authenticated to both Alice and Bob impersonating Alice to Bob and Bob to Alice

Two-way Authentication Protocol – Problem #2 Eve puts Alice on “hold” and then gets Alice to authenticate herself using the same Nonce Alice used! thus getting Alice to create her own correct response for Eve! A: => E(NA) (here Eve is again impersonating Bob) E: => A(NA) (Eve turns is back to Alice!) A: => E(Encrypt(NA, KAB)) E: => A(Encrypt(NA, KAB)) So, Eve is now authenticated to Alice as Bob Note that again, Eve doesn’t know KAB, but, Eve is authenticated to Alice as Bob Solutions?

Authentication Protocol Using Public-Key Cryptography Could do the same one-way or two-way authentication using public-key cryptography: Alice sends a nonce to Bob Bob responds to the nonce by encrypting it with his private key and sending it back to Alice Alice knows the response came from Bob, since only Bob could have encrypted with Bob’s private key, if it is successfully decrypted with Bob’s public key

Authentication Using Public-Key Cryptography - Drawback Note that digital signatures are sometimes a public message encrypted using the signer’s private key anyone can decrypt with signer’s public key and validate the signature By using the previous public key authentication, Bob is essentially blindly signing something that he thinks is a nonce from Alice, but he really doesn’t know what it is or who it is coming from someone could trick Bob into responding to a nonce that is really text that says, “Bob owes Eve USD $1 million”.

Authentication Using Public-Key Cryptography – Another Protocol Another challenge-and-response authentication protocol: Alice performs a computation based on some random numbers (chosen by Alice) and her private key and sends the result to Bob Bob sends Alice a random number (chosen by Bob) Alice makes some computation based on her private key, her random numbers, and the random number received from Bob and sends the result to Bob Bob performs some computations on the various numbers and Alice’s public key to verify that Alice knows her private key Advantage: Alice never encrypts a message chosen by someone else

Authentication AND Key Exchange Protocols Combine authentication and key-exchange Assume Carla and Diane are on opposite ends of a network and want to talk securely Want to agree on a new session key securely Want to each be sure that they are talking to the other and not an intruder

Authentication AND Key Exchange Protocol – Wide Mouth Frog Assumes a trusted third-party, Sam, who shares a secret keys, KCS and KDS, respectively, with Carla and Diane Carla generates a shared secret key, encrypts together with a timestamp, and sends to Sam Sam decrypts and re-encrypts, updates timestamp, sends to Diane C: => S(C,Encrypt((D,KCD,TC),KCS)); S: => D(Encrypt((C, KCD, TS), KDS)); Observations: Reliance on synchronized clocks for timestamps Depends on a third-party that both participants trust, may be a bottleneck Initiator is trusted to generate good session keys

Authentication AND Key Exchange Protocol – Yahalom Yahalom Protocol: Uses nonces Carla contacts Diane Diane is the first one to contact Sam Sam generates the session key and sends to Carla Carla sends to Diane the information forwarded from Sam C: => D (C,NC); D: => S (D,Encrypt((C,NC,ND),KDS)); S: => C (Encrypt((D,NC,ND,KCD),KCS),Encrypt((C,KCD),KDS)); C: => D(Encrypt((C,KCD),KDS),Encrypt(ND,KCD)); Observations: reply and man-in-the-middle attacks are all avoided

Authentication AND Key Exchange Protocol – Denning-Sacco Denning-Sacco Protocol: First three messages assure both parties have each others’ correct public keys (authentication) Key exchange accomplished with last message Including session key generated by Carla, and a timestamp C: => S(C,D); S: => C(Encrypt((C,CPublic,TS),SPrivate),Encrypt((D,DPublic,TS),SPrivate)); C: => D(Encrypt((C,CPublic,TS),SPrivate),Encrypt((D,DPublic,TS),SPrivate)); C: => D(Encrypt(Encrypt((D, KCD ,TC),CPrivate),DPublic)); Observations: Addition of D in last message makes it secure against a spoof attack someone with a valid session key with Carla claiming to be Carla to Diane

Next… 5 minute break, then Lab