371 -1 -0291 An Introduction to Computer Networks

371 -1 -0291: An Introduction to Computer Networks Homepage http: //help. cse. bgu. ac. il/cse/Courses/list. asp Handout #17: Network Security 1

Network Security Outline v Application Layer Security v Transport Layer Security v Link Layer Security v Firewalls & Intrusion Detection Lect-13: Network Security Computer Networks 2

Network Security Systems The systems can be categorized by the protocol layer they operate: v Network layer Ø IPSEC (IP Security) v Transport layer Ø SSL (Secure Socket Layer Security) Ø HTTPS (HTTP Secure) Ø TLS (Transport Layer Security) – IETF standard based on SSL v Application layer Ø PEM (Privacy Enhanced Mail) Ø PGP (Privacy Good Privacy) Lect-13: Network Security Computer Networks 3

Application Layer Security Systems Lect-13: Network Security Computer Networks 4

Email Security Challenges v Most email system expect ASCII chars while crypto alg generate binary data v Email messages pass through systems assuming line format v length, EOL ( or ) v Breaking lines may cause signed messages appear invalid v Making sure that mail to multiple recipients (via mailing list “machines”) are secure Lect-13: Network Security Computer Networks 5

Email Security Requirements Main requirements • Confidentiality • Authentication • Integrity Other requirements • Non-repudiation • Proof of submission • Proof of delivery • Anonymity • Revocability • Resistance to traffic analysis Many of these are difficult or impossible to achieve Lect-13: Network Security Computer Networks 6

Security Mechanisms Detached signature • Leaves original message untouched • Signature can be transmitted/stored separately • Message can still be used without the security software Signed message • Signature is always included with the data Encrypted Message • Usually encrypted by recipient(s) public key(s) Lect-13: Network Security Computer Networks 7

Security Mechanisms Counter signed Encrypted and signed message • Sign first then encrypt Lect-13: Network Security Computer Networks 8

PEM A suite of 4 IETF RFCs (1993) specifying: v Message format for PEM users v Certification Authority (CA) hierarchy v Cryptographic algorithms v Message format 4 requesting and re-invoking certificates v Encodes 3 binary bytes as 4 ASCII characters Lect-13: Network Security Computer Networks 9

PEM (cont. ) Uses RSA public keys for encryption and authentication v Needs a CA from which A can obtain B’s PK v Since a centralized CA doesn’t scale, PEM specifies a tree Internet Policy Registration Authority Policy Certification PCA 3 Authority IPRA PCA 1 CA PCA 2 CA CA user Lect-13: Network Security user CA CA user CA Certification user CA Authority CA user Computer Networks user 10

PEM (cont. ) v Each CA level can delegate its authority to a lower level v Example: Ø CA 1 may sign CA 2 certificates Ø If user A trust CA 2 and knows its PK, it can get CA 2’s PK and learn user B PK from CA 2 Ø A user can learn the PKs of all users in its CA sub-tree v The PCA certifies CA – a PCA per CA type v Each PCA publishes it requirements PCA 1 CA CA 2 v The IPRA certifies the PCAs v PEM certificates follow X. 509 standard Lect-13: Network Security Computer Networks CA 1 A B 11

PEM (cont. ) Sending an authenticated message v A conveys its PK to B with a CA A trusts – it may go up to IPRA v A sends an authenticated message M to B in the form of: M+E(MD 5(M), Private. Key[A]) v To authenticate M, B needs only A’s PK Lect-13: Network Security Computer Networks 12

PEM (cont. ) Sending an encrypted message v A learns B’s PK via CA or via Email from B and then: M Gen a random secret key K E(M) = DES(M, K) M = DES(E(M), K) E(K) = RSA(K, Public. Key[B]) K = RSA(K, Private. Key[B]) ASCII_encode(E(K), E(M)) ASCII_decode(E(K), E(M)) transmit Lect-13: Network Security Computer Networks 13

Why PEM Failed? v PEM has only moderate deployment v The main shortcoming: Ø A full-fledged certification hierarchy tree is required Ø Requires X. 500 names for CA but Email uses Email addresses Ø CA’s for commercial organizations and universities can’t meet the same requirements as government defense contractors for high-assurance CA’s Lect-13: Network Security Computer Networks 14

PGP (Pretty Good Privacy) v Released in June 1991 v MD 4 + RSA signatures and key exchange v Encryption alg IDEA (PGP 2. 0) v MD 4, MD 5 v LZH data compression (PGP 1. 0) Info. Zip (PGP 2. 0) v uuencoding ASCII (PGP 1. 0) base 64 (PGP 2. 0) v PGP was immediately distributed worldwide via a Usenet post Lect-13: Network Security Computer Networks 15

PGP v PGP differs from PEM mainly by allowing CAs to be arbitrarily meshed v Each user may decide how much trust s/he wishes to place in the certificate and what cryptographic algorithms to use PGP Key Ring file v PGP signing parties exchange/sign/certify PKs from parties and individuals they know (mainly in IETF meetings) v PGP store the certificates having various degree of trust in a file called Key Ring v To verify/obtain a public key, a user uses PGP s/w to search the Key Ring file and get the level of trust (based on # of certificates and trustworthiness who signed the certificates) Lect-13: Network Security Computer Networks 16

PGP Key Ring file (cont. ) v Keys in the Key Ring file is looked up by • user. ID (free-form name) • key. ID (64 -bit value derived from the public key) PGP Key Problems v One can construct keys with arbitrary ID’s v Allows signature spoofing v Key fingerprints can also be spoofed Lect-13: Network Security Computer Networks 17

Transport Layer Security Systems Lect-13: Network Security Computer Networks 18

Secure Socket Layer (SSL) Security Hazards v Information in transit could be intercepted (=> Privacy) Ø unauthorized use of credit card number Ø purchase private details (what, how much) v Information in transit could be modified intercepted (=> Integrity) Ø get the wrong order, pay more v E-commerce site authentication (=> Authentication) SSL v The 1 st widely solution to the problems above v IETF TLS standard evolves from SSLv 3 Lect-13: Network Security Computer Networks 19

SSL Services TCP/IP socket encryption v Usually authenticates server using digital signature v Can authenticate client, but rarely used v Confidentiality protection via encryption v Integrity protection via MAC’s v Provides end-to-end protection of sessions Application (e. g. , HTTP) Secure Transport (e. g. , SSL) TCP IP Subnet Lect-13: Network Security Computer Networks 20

SSL History v SSLv 1 designed by Netscape, broken by members of the audience while it was being presented v SSLv 2 shipped with Navigator 1. 0 v Microsoft proposed PCT: PCT != SSL v SSLv 3 was peer-reviewed, proposed as an IETF standard Lect-13: Network Security Computer Networks 21

SSL Protocols v SSL is two phase protocol: Ø Handshake protocol Ø Data transfer protocol Handshake protocol 1. Negotiate the cipher suite 2. Establish a shared session key 3. Authenticate the server (optional) 4. Authenticate the client (optional) 5. Authenticate previously exchanged data Lect-13: Network Security Computer Networks 22

Handshake protocol Client Server Hello + optional certificate Client key exchange Change cipher + MAC of prev. fields [finish] Secure session Lect-13: Network Security Secure session Computer Networks 23

Client hello: • Client nonce • Available cipher suites (e. g. , RSA + RC 4/40 + MD 5) Server hello: • Server nonce • Selected cipher suite • Server adapts to client capabilities • Optional certificate exchange to authenticate server/client. In practice only server authentication is used Lect-13: Network Security Computer Networks 24

Client shared-key exchange: • RSA-encrypt( pre-master secret ) Both sides computes: • 48 -byte master-secret = hash(pre-master + client-nonce + server-nonce ) Client/server change cipher spec: • Switch to selected cipher suite and key Client/server finished: • MAC of previously exchanged parameters (authenticates data from previous exchanges) – Uses an early version of HMAC Lect-13: Network Security Computer Networks 25

SSL Extra Features Must be immune to “man-in-the-middle” attack v Before the agreement on the crypto suite, a man in the middle may alter the choice into a weaker suite v A good SSL design must be selective and not settle for any suite Session Resumption v Optimizes handshake in case of session breakdown or in case where client-server have shaken hands before v The client includes a session ID he got before in its first Hello v The server may answer if it still has the session state v The client will continue with the record protocol v Fallback to standard handshake if miss-match Lect-13: Network Security Computer Networks 26

Data Transfer (Record) protocol v Procedure and formats specifying the appl messages passed to SSL Ø Message fragmentation Ø Message compression Ø Integrity protected (e. g. , MD 5) Ø Encrypted Lect-13: Network Security Computer Networks 27

SSL Characteristics v Protects the session only v Designed for multiple protocols (HTTP, SMTP, NNTP, POP 3, FTP) but only really used with HTTP v Compute-intensive: Ø 3 CPU seconds on Sparc 10 with 1024 bit RSA key Ø 200 MHz NT allows about a dozen concurrent SSL handshakes – Use multiple servers – Use hardware SSL accelerators v Crippled crypto predominates Ø Strong servers freely available (Apache), but most browsers US-sourced and crippled Lect-13: Network Security Computer Networks 28

v When HTTP is used this way it is called HTTPS (default port 443) v Not as with PEM/PGP, there is a real-time negotiation for crypto algs Lect-13: Network Security Computer Networks 29

Strong SSL Encryption v Most implementations based on SSLeay http: //www. ssleay. org/ v Servers Ø Some variation of Apache + SSLeay Ø Mostly Unix-only, some NT ports in progress Ø SSL portion is somewhat painful to configure Lect-13: Network Security Computer Networks 30

Strong SSL Browsers v Fortify, http: //www. fortify. net/ v Patches Netscape (any version) to do strong encryption v Opera, http: //www. operasoftware. com/ Ø Norwegian browser, uses SSLeay v Cryptozilla, http: //www. cryptozilla. org/ Ø Based on open-source Netscape Ø Strong crypto added within one day of release from the US v Exported US-only versions, ftp: //ftp. replay. com/pub/replay/pub/ Contains copies of most non-exportable software Lect-13: Network Security Computer Networks 31

Strong SSL Proxies Tunnel weak or no SSL over strong SSL Lect-13: Network Security Computer Networks 32

CA with SSL v SSL enables Web commerce via a commercialized CAs v CA’s Public keys are included with the Web Browsers v E-commerce companies wishing to accept credit card payment simply obtain certificates from those CAs v Server verification by browsers are then straightforward v Example: Credit card purchase Ø Only server is authenticated Ø Client encrypts/sign with server Public Key Ø Server encrypts/sign with its Private Key Lect-13: Network Security Computer Networks 33

TLS (“SSL 3. 1”) Main objective: To secure a purchase transaction using a credit card v A general purpose protocol evolved from SSLv 3 Ø Non-patented technology Ø Non-crippled crypto Ø Updated for newer algorithms v Sits between Appl layer (e. g. , HTTP) and Transport layer (e. g. , TCP) Lect-13: Network Security Computer Networks 34

Secure Shell (SSH) v Originally developed in 1995 as a secure replacement for rsh, rlogin, et al (ssh = secure shell), http: //www. cs. hut. fi/ssh/ v Allows tunneling over SSH v Built-in support for proxies/firewalls v Includes Zip-style compression v Originally implemented in Finland, available worldwide v SSH v 2 submitted to IETF for standardization v Can be up and running in minutes Lect-13: Network Security Computer Networks 35

SSH Protocol Server uses two keys: • Long-term server identification key • Short-term encryption key, changed every hour Client Server Long-term + short-term keys Double-encrypted session key Encrypted confirmation Encrypted data Long-term server key binds the connection to the server Short-term encryption key makes later recovery impossible • Short-term keys regenerated as a background task Lect-13: Network Security Computer Networks 36

SSH Authentication v Multiple authentication mechanisms Ø Straight passwords (protected by SSH encryption) Ø RSA-based authentication (client decrypts challenge from Ø server, returns hash to server) Ø Plug-in authentication mechanisms v Developed outside US - crippled crypto not even considered: Ø 1024 bit RSA long-term key Ø 768 bit RSA short-term key (has to fit inside long-term key for double encryption) Ø 3 DES session encryption (other ciphers available) Lect-13: Network Security Computer Networks 37

Link Layer Security System Lect-13: Network Security Computer Networks 38

IP Security (IPSEC) v IP security — security built into the IP layer v Provides host-to-host (or firewall-to-firewall) encryption, authentication, integrity and anti-reply v Required for IPv 6, optional for IPv 4 v Comprise two parts: Ø IPSEC proper (authentication and encryption) Ø IPSEC key management v The SPI (Security Parameter Index) defines the precise details in one-way connection between IPSEC hosts pair Lect-13: Network Security Computer Networks 39

v Users may Ø select from various crypto suites Ø various security services Ø control the scope to which security service will apply (packets from a specific TCP connections, all packets between tow set of addresses, etc. ) v All above are identified by the SPI Lect-13: Network Security Computer Networks 40

IP High Level Structure Security Services Key Management Authentication Header (AH) IS Association and Key Management protocols (ISAKMP) Encapsulating Security Payload (ESP) v AH services: connectionless message integrity, Security Association (SA) authentication, Binds between the two set of protocols per oneway connection between two hosts anti-reply protection v ESP Services: as above + encryption Lect-13: Network Security Computer Networks 41

v SA is assigned a Security Parameter Index (SPI) by the receiving host v The SPI is part of the AH and ESP packet headers v The receiving host learns from the SPI field to which SA the incoming packet belongs to ISAKMP Role v Defines the procedures and packet formats to establish, negotiate, modify and delete SAs v Defines packet formats for key exchange and authenticated data Lect-13: Network Security Computer Networks 42

Authentication Header (AH) v Provides connectionless message integrity, data origin authentication and optionally anti-reply v The AH header follows the IPv 4 header or is an IPv 6 extension header 0 31 Next. Hdr Payload length reserved SPI sequence number Authentication data Next. Hdr: identifies the next payload type (e. g. , TCP) Payload Length: AH length in 32 -bits units Sequence number: Monotonically increasing sequence to protect against reply Lect-13: Network Security Computer Networks 43

Authentication Header (AH) – cont. Anti-reply protection § Connection parties initialize Sequence number to 0 when SA is setup § When ant-reply is enabled, sequence numbers must never cycle § After 2^32 packets a new SA must be established § Receiver tracks packets within a 64 -entry sliding window Authentication Data: - Contains a variable length message integrity code for this packet - Multiple of 32 bits - Specifies the message digest length, comparison rules and processing steps to validate Mutable fields (time-to-live, IP checksums) are zeroed before AH is added Lect-13: Network Security Computer Networks 44

Encapsulating Security Payload (ESP) v Provides connectionless message integrity, data origin authentication, optionally anti-reply and encryption v The ESP header follows the IPv 4 header or is an IPv 6 extension header 0 31 SPI sequence number Payload data Padding (0 -255 bytes) Pad length Next. Hdr Authentication data Lect-13: Network Security Computer Networks 45

w/o encryption with encryption § Encryption protects payload § Authentication protects header and encryption Lect-13: Network Security Computer Networks 46

ESP – cont. v The set of services depend on the SA pointed by the SPI v If encryption is selected, the payload data is encrypted by the alg associated with the SA (described by the Next. Hdr field) Ø Padding is required since encryption requires a specified multiple number of plaintext bytes or to ensure that ciphertext terminates on a 4 -byte boundary v The most popular use of ESP is to setup a tunnel between 2 routers Ø e. g. , a secure Internet path between two offices can be configured in both pf their LAN’s gateways Lect-13: Network Security Computer Networks 47

IPSEC Processing v IPSEC node must implement protocols and configure SA Data Base v Receiving host uses SPI to look up SA in its DB v Performs authentication using SA v Performs decryption of authenticated data using SA v Operates in two modes Ø Transport mode (secure IP) - protects only payload Ø Tunneling mode (secure IP inside standard IP) - protects entire payload + IP header – Popular in routers - Communicating hosts don’t have to implement IPSEC Lect-13: Network Security Computer Networks 48

Firewalls Intrusion Detection Lect-13: Network Security Computer Networks 49

The Best Firewall to network power Lect-13: Network Security Functionality is Bad Computer Networks 50

Lesser Firewall to network firewall (p: packet) { if (allow (p)) forward (p); else drop (p); } Lect-13: Network Security Computer Networks 51

A Simple Packet Filter boolean allow (packet) { if ( match (packet. source, “ 132. 72. 105. *”) ) return false; // No packets from CS machines. else if (match (packet. source, “ 132. 68. *. *”)) return false; // Technion else return true; } Lect-13: Network Security Computer Networks 52

Typical Packet Filtering Rules Inbound packets: permit [from: ] 0. 0 [to: ] 128. 143. 137. 19 TCP src >= 1024 dst = 25 permit [from: ] 0. 0 [to: ] 128. 143. 137. 19 TCP src = 25 dst >= 1024 Outbound packets: permit [from: ] 128. 143. 137. 19 [to: ] 0. 0 TCP src = 25 dst >= 1024 permit [from: ] 128. 143. 137. 19 [to: ] 0. 0 TCP src >= 1024 dst = 25 Lect-13: Network Security Computer Networks 53

Packet Filter Layers Application Presentation FTP SMTP HTTP Real. Player . . . Session TCP Transport IP Network Data Link Ethernet FDDI Physical Lect-13: Network Security UDP Computer Networks CDMA Smoke Signals Other 54

Application-Layer Proxies Sits between clients and server v Analyze communication at application layer v All communication must go through a proxy that knows about application (http proxy, Email proxy, etc. ) v v Poor scalability, performance Lect-13: Network Security Computer Networks 55

Why Check. Point’s Firewall is Successful ? v Statefull Inspection Ø Ø Intercept packets at network layer, but analyze at all communications layers Maintain application-specific state • e. g. , Save PORT command of outgoing FTP session, compare with incoming FTP data Ø Ø Programmable filters and manipulators Provide a graphical front end for programming filters and monitoring activity Lect-13: Network Security Computer Networks 56

Intrusion Detection Lect-13: Network Security Computer Networks 57

Why Detect Intruders? v Catch them before they cause damage and plug holes v Identify damage v Collect evidence for prosecution v Deterrent Lect-13: Network Security Computer Networks 58

Processing Profile Obviously Normal Lect-13: Network Security Obviously Malicious Computer Networks 59

Theoretical Graph Probability density function Authorized user profile Intruder profile Measurable behavior parameter Lect-13: Network Security Computer Networks 60

More Realistic Graph Probability density function Authorized user profile Intruder profile Measurable behavior parameter Lect-13: Network Security Computer Networks 61

False Positives Dilemma v v v Doctor invents a new, inexpensive test for a deadly disease that is 95% accurate Assume 1 in 1000 people have deadly disease (but don’t know it yet) Should everyone get the test? Ø Ø 1000 people tested Expect. 95 + (999 *. 05) positives 50 people will be told they have disease If you test positive, there is a 1/50 chance you have disease Lect-13: Network Security Computer Networks 62

Intrusion Detection Approaches v Statistical Anomaly Detection Ø Ø v Produce a profile of the normal behavior of each user (or independent of user) Notice statistical deviations from that behavior Rule-based Detection Ø Ø Think really hard and make up rules that describe intruder behavior. Hope intruders can’t read and figure out the rules also. Lect-13: Network Security Computer Networks 63

When Detecting an Intrusion Do nothing v Email system administrator v Page system administrator v Shut down system v Lect-13: Network Security Computer Networks 64

Network Intrusion Detection Monitor activity on many hosts v Aggregate audit records to detect anomalous behavior v v Managed Security Monitoring Counterpane Inc. ) Ø $12, 000/month Lect-13: Network Security Computer Networks 65

Challenges in Intrusion Detection v The first thing a smart intruder will do is tamper with the Intrusion Detection system! v Few activities are either obviously normal or obviously malicious v False positives dilemma Lect-13: Network Security Computer Networks 66