CS470, A.SelcukReal-Time Communication Issues1 Real-Time Communication Security IPsec & SSL Issues CS 470 Introduction to Applied Cryptography Instructor: Ali Aydin Selcuk

CS470, A.SelcukReal-Time Communication Issues2 The Internet A packet-switched network: Data to be transmitted is divided into “packets” Each packet is forwarded by “routers” towards the destination...

CS470, A.SelcukReal-Time Communication Issues3 Security of TCP/IP Communications The TCP/IP reference model: IP: delivery of packets to the destination TCP: reliability of the communication –ordering the packets –error detection & recovery –congestion control UDP: basic transport protocol Application Layer (HTTP, FTP, SMTP, etc.) Transport Layer (TCP, UDP) Network Layer (IP) Data Link Layer (PPP, Ethernet, etc.) Physical Layer

CS470, A.SelcukReal-Time Communication Issues4 Securing TCP/IP Layer 3: –can secure all IP comm., transparent to applications –must be built into the OS Layer 4: –doesn’t require OS modification; deployment easy Application L. Transport L. Network L. Data Link L. Physical L. Layer 4 (SSL/TLS) Layer 3 (IPsec)

CS470, A.SelcukReal-Time Communication Issues5 Real-Time Protocol Issues Interactive session security (unlike ) End-to-end security (encryption/authentication) requires layer 3 or 4 (or, layer 3.5 & 4.5) protection

CS470, A.SelcukReal-Time Communication Issues6 IPv4 Header |Version| IHL |Type of Service| Total Length | | Identification |Flags| Fragment Offset | | Time to Live | Protocol | Header Checksum | | Source Address | | Destination Address | | Options | Padding |

CS470, A.SelcukReal-Time Communication Issues7 TCP Header | Source Port | Destination Port | | Sequence Number | | Acknowledgment Number | | Data | |U|A|P|R|S|F| | | Offset| Reserved |R|C|S|S|Y|I| Window | | | |G|K|H|T|N|N| | | Checksum | Urgent Pointer | | Options | Padding | | data |

CS470, A.SelcukReal-Time Communication Issues8 UDP Header | Source Port | Destination Port | | Length | Checksum |

CS470, A.SelcukReal-Time Communication Issues9 Layer 4 (SSL) Implemented on top of layer 4, between TCP & application Doesn’t require any modifications to OS (deployment made easy!)

CS470, A.SelcukReal-Time Communication Issues10 Layer 3 (IPsec) Implemented between IP & TCP Each IP packet authenticated separately Built in the OS Can secure all IP communication Host-to-host and network-to-network application is common; process-to-process also possible

CS470, A.SelcukReal-Time Communication Issues11 Session Key Establishment Message authentication with a session key is needed against connection hijacking Sequence numbers needed against packet replays (different from TCP seq.no.) Session key reset before seq.no. wraps around For freshness guarantee, both parties should contribute to the session key

CS470, A.SelcukReal-Time Communication Issues12 Perfect Forward Secrecy PFS: Compromise of long-term secrets doesn’t compromise session keys Example: DH with RSA authentication Non-PFS examples: –Kerberos –Session key transport with RSA encryption By-product: Escrow prevention Conversations can’t be decrypted by authorities holding copies of long-term private keys

CS470, A.SelcukReal-Time Communication Issues13 DoS Protection If attacker can make server do DH exponentiation by just initiating a session, DoS is made easy Protection: –cookies –puzzles

CS470, A.SelcukReal-Time Communication Issues14 DoS Protection – Cookie Solution Server responds to session requests with a random number (cookie). Initiator has to respond back with that cookie to continue Attacker would either –reveal its address –or, abort the attack Stateless cookies: cookie is H(IP address, secret); server doesn’t remember it.

CS470, A.SelcukReal-Time Communication Issues15 DoS Protection – Puzzle Solution Server requires initiator to solve a puzzle E.g., MD5(x) = …, x = ?, for an n-bit x. Solving is slow, verification fast. Can be made adaptive to increasing load. (how?) Can be made stateless. (how?) Can be used against spam as well

CS470, A.SelcukReal-Time Communication Issues16 Identity Hiding Hiding the parties’ identities from eavesdroppers Do DH without authentication. Then send the authentication info encrypted under the session key. Passive attacker can’t learn identities

CS470, A.SelcukReal-Time Communication Issues17 Live Partner Assurance Against replays, different DH exponents must be used in different sessions DH exponentiation is expensive; problem for servers, low-end clients Solution: Constant DH exponents, different nonces. Incorporate nonces into the session key. E.g., K = H(g ab mod p, nonces)

CS470, A.SelcukReal-Time Communication Issues18 Other Issues Session resumption: Use previously established session keys to bypass public-key authentication Deniability: Don’t use signatures for authentication. Use encryption with public keys. (e.g., the SKEME protocol) Crypto negotiations: Key exchange protocols negotiate the algorithms to be used as well