CS 5950 Computer Security and Information Assurance

CS 5950 – Computer Security and Information Assurance Section 5: Security in Networks – Part 2 This version of Section 5 includes OPTIONAL slides that you may SKIP Dr. Leszek Lilien Department of Computer Science Western Michigan University Slides based on Security in Computing. Third Edition by Pfleeger and Pfleeger. Using some slides courtesy of: Prof. Aaron Striegel — course taught at U. of Notre Dame Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke (U. Idaho) — taught at U. Washington Prof. Jussipekka Leiwo — taught at Vrije Universiteit (Free U. ), Amsterdam, The Netherlands Slides not created by the above authors are © 2006 by Leszek T. Lilien Requests to use original slides for non-profit purposes will be gladly granted upon a written request.

© 2006 -2007 by Leszek T. Lilien Section 5 – Computer Security and Information Assurance Covered earlier (in Section 2): Security in Networks – Part 1 – Outline (1) Outline of Part 1 of Security in Networks (covered in Section 2) 2. 1. Network Concepts a) b) c) d) e) f) g) h) i) Introduction The network Media Protocols Types of networks Topologies Distributed systems APIs Advantages of computing networks 2. 2. Threats in Networks a) b) c) d) e) f) Introduction Network vulnerabilities Who attacks networks? Threat precursors Threats in transit: eavesdropping and wiretapping Protocol flaws 2

© 2006 -2007 by Leszek T. Lilien Section 5 – Computer Security and Information Assurance Covered earlier (in Section 2): Security in Networks – Part 1 – Outline (2) 2. 2. Threats in Networks - ctd g) Types of attacks g-1) Impersonation g-2) Spoofing g-3) Message confidentiality threats g-4) Message integrity threats g-5) Web site attacks g-6) Denial of service g-7) Distributed denial of service g-8) Threats to active or mobile code g-9) Scripted and complex attacks h) Summary of network vulnerabilities 3

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien Security in Networks – Part 2 – Outline of Part 2 of Security in Networks (covered here) 5. 1. Network Security Controls a) b) c) d) e) f) (1) Introduction Security threat analysis Impact of network architecture/design and implementation on security Encryption i. Link encryption vs. end-to-end (e 2 e) encryption ii. Virtual private network (VPN) iii. PKI and certificates iv. SSH protocol v. SSL protocol (a. k. a. TLS protocol) vi. IPsec protocol suite vii. Signed code viii. Encrypted e-mail Message content integrity controls i. Error correcting codes ii. Cryptographic checksum Strong authentication i. One-time passwords ii. Challenge-response systems iii. Digital distributed authentication iv. Kerberos authentication system 4

© 2006 -2007 by Leszek T. Lilien Security in Networks – Part 2 – Outline (2) 5. 1. Network Security Controls—ctd. g) Access controls i. ACLs on routers ii. Firewalls h) Intrusion Detection Systems: alarms and alerts i) Honeypots j) Traffic flow security k) Review of network security controls Section 5 – Computer Security and Information Assurance 5. 2. Network Security Tools 5. 2. 1. Firewalls a) b) c) d) Introduction What is a firewall Firewall design Types of firewalls i. Packet filters (i-1) Simple packet filters (i-2) Stateful packet filters ii. Application proxies (ii-1) Guards (“top model” subcategory) iii. Personal firewalls e) Comparison of firewall types f) Example firewall configurations g) What firewalls can—and can’t—block 5

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien Security in Networks – Part 2 – Outline (3) 5. 2. Network Security Tools—ctd. 5. 2. 2. Intrusion Detection Systems a) Introduction b) Types of IDSs i. Signature-based IDSs ii. Anomaly-based IDSs iii. Other IDSs c) Goals for IDSs d) IDS strengths and limitations 5. 2. 3. Secure E-Mail a) b) c) d) Introduction Security for e-mail Design of PEM (Privacy-enhanced Electronic Mail) Example secure e-mail systems i. PGP ii. S/MIME 6

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien 5. Network Security – Part 2 § Part 1 of Security in Networks was covered in lecture Section 2 § Part 2 of Security in Networks is covered in this lecture Section 5, as follows: 5. 1. Network Security Controls 5. 2. Network Security Tools 7

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien 5. 1. Networks Security Controls § Outline a) Introduction b) Security threat analysis c) Impact of network architecture/design and implementation on security d) Encryption e) Content integrity f) Strong authentication g) Access controls h) Alarms and alerts i) Honeypots j) Traffic flow security k) Controls review 8

© 2006 -2007 by Leszek T. Lilien a. Introduction § We will see many security controls: § In Section 6 on Program Security (incl. s/w engineering issues) § (OPTIONALLY: In Section on OS Security) § Many of these strategies are useful for network security as well We will now look for security controls designed specifically for computer networks Section 5 – Computer Security and Information Assurance § 9

© 2006 -2007 by Leszek T. Lilien b. Security threat analysis (1) Threat analysis steps : 1) Analyze system components and their interactions 2) Analyze possible damage to C-I-A 3) Hypothesize possible kinds of attacks § Section 5 – Computer Security and Information Assurance § Network elements to be considered: § Local elements § § Nodes / comm links / data storage / processes / devices / LANs Non-local elements § Gateways / comm links / control resources / routers / network resources (e. g. , databases) 10

© 2006 -2007 by Leszek T. Lilien Security threat analysis (2) § Network threats: § Accessing pgms or data at remote host § Modifying pgms or data at remote host § Running a pgm at a remote host § Interception of data in transit Modifying data in transit Insertion of data into communication traffic § Incl. replaying previous communication Blocking selected/all traffic § Impersonation of entities Section 5 – Computer Security and Information Assurance § § Attack enablers: § Size / anonymity / ignorance / misunderstanding § Complexity / motivation / programming skills 11

© 2006 -2007 by Leszek T. Lilien c. Impact of network architecture/ design & implement. on security (1) § Section 5 – Computer Security and Information Assurance § Security principles for good analysis, design, implementation, and maintenance (as discussed in sections on Pgm Security and OS Security) apply to networks Architecture can improve security by: 1) Segmentation 2) Redundancy 3) Single points of failure 4) Other means 12

© 2006 -2007 by Leszek T. Lilien Impact of network architecture/ design & implement. on security (2) 1) Segmentation § Section 5 – Computer Security and Information Assurance § Architecture should use segmentation to limit scope of damage caused by network penetration by: § Reducing number of threats § Limiting amount of damage caused by single exploit § Enforces least privilege and encapsulation Example 1: component segmentation § Placing different components of e-commerce system on different hosts § Esp. put on separate host most vulnerable system components § § E. g. , separate host for web server (w/ public access) Exploit of one host does not disable entire system 13

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien Impact of network architecture/ design & implement. on security (3) § Example 2: access separation § Separating from each other: § Production system § Testing system § Development system § E. g. , no developer has access to production system and no customer has access to development system 14

© 2006 -2007 by Leszek T. Lilien Impact of network architecture/ design & implement. on security (4) 2) Redundancy § Architecture should use redundancy to prevent losing availability due to exploit/failure of a single network entity § Example: having a redundant web server (WS) in a company Section 5 – Computer Security and Information Assurance § Types of redundancy include: § Cold spare – e. g. , when WS fails, replace it manually with spare WS § Warm spare – e. g. , failover mode = redundant WSs periodically check each other § Hot spare – e. g. , 3 WSs configured to perform majority voting 15

© 2006 -2007 by Leszek T. Lilien Impact of network architecture/ design & implement. on security (5) 3) Single points of failure (SPF) § Architecture should eliminate SPFs to prevent losing availability due to exploit/failure of a single network entity § Using redundancy is a special case of avoiding SPFs Section 5 – Computer Security and Information Assurance § Network designers must analyze network to eliminate all SPFs § Example of avoiding SPF (without using redundancy) § Distribute 20 pieces of database on 20 different hosts (so called partitioned database) § Even if one host fails, 95% of database contents (19/20=95%) still available § Elimination of SPFs (whether using redundancy or not) adds cost 16

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien Impact of network architecture/ design & implement. on security (6) 4) Other architectural means for improving security § Will be mentioned below as we discuss more network security controls 17

© 2006 -2007 by Leszek T. Lilien d. Encryption § Arguably most important/versatile tool for network security We have seen that it can be used for: § Confidentiality/Privacy § Authentication § Integrity § Limiting data access § Section 5 – Computer Security and Information Assurance § Kinds of encryption in networks: i. Link encryption vs. end-to-end (e 2 e) encryption ii. Virtual private network (VPN) iii. PKI and certificates iv. SSH protocol v. SSL protocol (a. k. a. TLS protocol) vi. IPsec protocol suite vii. Signed code viii. Encrypted e-mail 18

© 2006 -2007 by Leszek T. Lilien (i) Link vs. end-to-end encryption 1) Link encryption = between 2 hosts § Data encrypted just before they are placed on physical communication links § At OSI Layer 1 (or, perhaps, Layer 2) § § Section 5 – Computer Security and Information Assurance (1) Fig. 7 -21, p. 431 Properties of link encryption (cf. Fig. 7 -21) § Msgs/pkts unprotected inside S’s/R’s host § I. e. , unprotected at OSI layers 2 -7 of S’s/R’s host (in plaintext) § § Packets protected in transit between all hosts Pkts unprotected inside intermediate hosts § I. e. , unprotected at OSI layers 2 -3 of interm. hosts => unprotected at data link and network layers at intermediate hosts (if link encryption at Layer 1) § Layers 2 -3 provide addressing and routing 19

Link vs. end-to-end encryption (2) © 2006 -2007 by Leszek T. Lilien Link encryption is transparent (invisible) to users, their applications, and their OSs § Encryption service provided by physical (or data) layer § Can use encryption h/w (link encryption device) § Section 5 – Computer Security and Information Assurance § Message under link encryption § Fig. 7 -22, p. 432 § See which portions encrypted, which exposed § § Only part of data link header & trailer created after encryption is exposed Link encryption is useful when transmission line is most vulnerable in a network § I. e. , when S’s host, intermediate hosts, R’s host are reasonably secure (so msgs/pkts at their Layers 2 -7 can be exposed) 20

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien Link vs. end-to-end encryption (3) 2) End-to-end encryption = between 2 user applications § Data encrypted as „close” to app as possible § At OSI Layer 7 (or, perhaps, Layer 6) § § Fig. 7 -23, p. 433 Properties of e 2 e encryption (cf. Fig. 7 -21) § Msgs/pkts protected all the way once they „exit” S’s app & before they enter R’s app § Msgs/pkts protected (in ciphertext) inside S’s/R’s host § Packets protected in transit between S’s & R’s hosts Including protection inside intermediate hosts § I. e. , protected at OSI layers 1 -3 of interm. hosts Layers 1 -3 provide physical connectivity, addressing and routing for packets 21

© 2006 -2007 by Leszek T. Lilien Link vs. end-to-end encryption (4) § Possibly provided only upon explicit user’s request => visible to user § § Section 5 – Computer Security and Information Assurance E 2 e encryption is visible either to users or their apps § Encryption service provided by app or OS Encryption by s/w Message under e 2 e encryption § Fig. 7 -24, p. 433 § See which portions encrypted, which exposed § § § Only user’s msg (user’s data) encrypted All headers & trailers exposed (all created after encryption) E 2 e encryption is useful when transmission lines and intemediate hosts are insecure 22

© 2006 -2007 by Leszek T. Lilien Link vs. end-to-end encryption (5) § Comparison of link vs. e 2 e encryption § Encryption of msgs/packets (whether link or e 2 e encryption) is no silver bullet § No guarantees of msg/packet security 1) Link encryption — encrypts all traffic over physical link § Typically host H has one link into network => link encryption encrypts all H’s traffic Section 5 – Computer Security and Information Assurance § Every H —incl. intermediate hosts— receiving traffic via link encryption must have decryption capabilities § Either (pairs of) hosts share symmetric key OR § Hosts use asymmetric keys § All hosts along a path from S to R must provide link encryption to prevent („partial”) packet exposure => usu. link encryption provided on all network links 23

© 2006 -2007 by Leszek T. Lilien Link vs. end-to-end encryption (6) 2) End-to-end (e 2 e) encryption — encrypts traffic only between 2 apps („virtual crypto channel between 2 apps”) § Interm. hosts don’t need to decrypt-encrypt pkts => interm. hosts don’t need encryption facilities § § Encrypts only some msgs between 2 apps Section 5 – Computer Security and Information Assurance § § § All interm. hosts save time/processing If no need to encrypt all msgs => even S’s and R’s hosts save time/processing If needed, can encrypt all msgs Using asymmetric keys requires fewer keys than using symmetric keys (n key pairs vs. n*(n-1)/2 keys) 24

© 2006 -2007 by Leszek T. Lilien Link vs. end-to-end encryption (7) § Comparison conclusions § Link encryption: § Faster § Easier to use § Uses fewer keys (1 K pair per host pair vs. 1 K pair per app pair) Section 5 – Computer Security and Information Assurance § § End-to-end (e 2 e) encryption: § More flexible § More selective (can select only some msgs for encryption) § User-level, can be integrated with app Optimize whether link or e 2 e encryption better for you If needed for higher security, use link and e 2 e encryption together § E. g. , user not trusting network link encryption can use app with e 2 e encryption 25

© 2006 -2007 by Leszek T. Lilien (ii) Virtual private network (VPN) § Section 5 – Computer Security and Information Assurance § Virtual private network (VPN) = connection over public network giving its user impression of being on private network § It could be viewed as „logical link” encryption Could be viewed as e 2 e encr. between client & server § Protecting remote user’s connection with her network Greatest risk for remote connection via public network: § Between user’s workstation (client) and perimeter of „home” network (with server) User’s Workstation (Client) § (1) Firewall protects Firewall Internal Server Physically Protected Network Perimeter network against external traffic (more later) 26

© 2006 -2007 by Leszek T. Lilien Virtual private network (VPN) (2) § Example VPN connection scenario 1 User’s Workstation (Client) 2 3 Firewall Internal Server Physically Protected Network Perimeter Section 5 – Computer Security and Information Assurance 1 – C authenticates to firewall (firewall passes user’s authentic. data to authentic. server [not shown], which decides whether authentication is OK) 2 – Firewall replies with encryption key (after negotiating with C a session encryption key) 3 – C and S communicate via encrypted tunnel § VPN restricts filters access to „home” server/network § Only „private” accesses allowed => public network access feels like private network 27

© 2006 -2007 by Leszek T. Lilien (iii) PKI and certificates § Public key infrastructure (PKI) = enables use of public key cryptography (asymmetric cryptography) § Usually in large & distributed environment § Elements of PKI: 1) Policies (higher level than procedures) § Define rules of operation § § Section 5 – Computer Security and Information Assurance (1) E. g. , how to handle keys and sensitive info E. g. , how to match control level to risk level 2) Procedures (lower level than policies) § Dictate how keys should be generated, managed, used 3) Products § Implement policies and procedures § Generate, store, manage keys 28

© 2006 -2007 by Leszek T. Lilien PKI and certificates (2) § PKI services: 1) PKI creates certificates § Certificate binds entity’s identity to entity’s public key § Entity = user or system or applicationor. . . 2) PKI gives out certificates from its database 3) PKI signs certificates § Adding its credibility to certificate’s authenticity § When queried about it Section 5 – Computer Security and Information Assurance 4) PKI confirms/denies validity of a certificate 5) PKI invalidates certificates § For entities that are no longer certified by PKI OR § For entities whose private key has been exposed 29

© 2006 -2007 by Leszek T. Lilien PKI and certificates (3) § PKI sets up: 1) Certificate authorities (CAs) 2) Registration authority 1) Certificate authority (CA) § CA can be in-house or external (commercial TTP = trusted third party) § CA is trusted Section 5 – Computer Security and Information Assurance § § Entities delegate to CA creation, issuance, acceptance, and revocation of their certificates CA actions: § Managing public key certificates (whole life cycle) § Issuing certificates by binding entity’s identity to its public key § § § Binding is done via CA’s digital signature § By publishing revocation lists Determining expiration dates for certificates Revoking certificates when necessary 30

© 2006 -2007 by Leszek T. Lilien PKI and certificates (4) § Example of CA analog: credit card company (CCC) Certificate analog: credit card (binds identity to account) Revocation list analog: lists of invalid credit cards § CCC is trusted § Section 5 – Computer Security and Information Assurance § Customers delegate to CCC creation, issuance, acceptance, and revocation of their credit cards CCC actions: § Managing credit cards (whole life cycle) § Issuing credit cards by binding customer’s identity to customer’s account § Binding is done via CCC’s protected databases § By checking list of invalid credit cards (before computer-verification transaction era, CCC published booklets of invalidated credit cards) § Determining expiration dates for credit cards § Revoking credit cards when necessary 31

© 2006 -2007 by Leszek T. Lilien PKI and certificates (5) 2) Registration authority (RA) = interface between user and CA § Duties: § Capture and authenticate user’s identity § Submit certificate requests to appropriate CA § Analog: U. S. Citizen applying for passport and U. S. Postal Service (USPS) Passport (official U. S. authentication) <-> certificate Section 5 – Computer Security and Information Assurance § USPS authenticates citizen § § § By verifies citizen’s driver license + other proofs of identity Passport office <-> CA USPS submits passport request forms to appropriate passport office of the U. S. Gov’t § USPS brings passport to customer’s home § Note: Trustworthiness of USPS authentication determines level of trust that can be placed in passports 32

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien PKI and certificates (6) § PKI efforts stateside and overseas § Building PKI for various purposes § E. g. , Federal PKI Initiative – to provide secure communication to U. S. gov’t agencies § It also specifies how commercial s/w using PKI should operate (so gov’t can use off-the-shelf products) § Major PKI product vendors in the U. S. : § § Baltimore Technologies Northern Telecom/Entrust Identrus Certificates can bind: § Identity to public key – classic, most common § Other bindings under research § E. g. , binding financial status to key (credit card companies) § Draft standards: ANSI X 9. 45, Simple Public Key Infrastructure (SPKI) 33

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien PKI and certificates (7) § PKI is not yet mature § Many outstanding issues § Cf. Table 7 -6, p. 439 Still, many points are clear: § CA should be approved/verfied by independent body § CA’s private keys must be stored in tamper-resistant security module (maybe with h/w support) § Access to CAs and RAs should be tightly controlled § Using strong authentication (e. g. , 2 FA or 3 FA with smart cards) 34

© 2006 -2007 by Leszek T. Lilien (iv) SSH protocol (newer: v. 2) – provides authenticated and encrypted communication with shell/OS command interpreter § § Originally defined for Unix Replaced insecure utilities for remote access § § Such as Telnet / rlogin / rsh Protects against spoofing attacks (falsifying one end of § Section 5 – Computer Security and Information Assurance (SSH = Secure SHell) communication, incl. masquerading, sesssion hijacking, MITM) message modification / falsification § & Involves negotiation between local and remote sites § Negotiate which encryption algorithm to use § E. g. , DES? IDEA? AES? Negotiate which authentication technique to use § § E. g. , public key? Kerberos? 35

© 2006 -2007 by Leszek T. Lilien (v) SSL protocol (a. k. a. TLS prot. ) (1) SSL protocol (v 3) = (approx. ) TLS protocol - interfaces betwen app (on client C) and TCP/IP protocols to provide server S authentication, optional C authentication, and encrypted communication channel between C and S for session between C and S § SSL = Secure Sockets Layer / TLS = Transport Layer Security Section 5 – Computer Security and Information Assurance § Simple but effective – most widely used secure communication protocol on Internet (incl. WWW browsers/servers) § § Originally defined by Netscape to protect browser-to-server communication Involves negotiation between C and S § Negotiate which encryption suite to use for session § § § E. g. , DES? RC 4 w/ 128 -bit/40 -bit key? RC 2? Fortezza? [Bishop] Negotiate which hashing technique to use for session E. g. , SHA 1 or MD 5? 36

© 2006 -2007 by Leszek T. Lilien SSL protocol (a. k. a. TLS protocol) (2) § SSL use scenario (handshake protocol) § C requests an SSL session by sending: Hello-C, Rand-C (random nr), list of cipher (encryption) algorithms & hash algorithms known to C § S responds with msgs including: Hello-S, Rand-S, cipher & hash algorithm selected by S (from C’s list) , S’s certificate, KPUB-S, [SKIP: request for cert. fr. C] § Section 5 – Computer Security and Information Assurance Hash used to checksum messages § C can use S’s certificate (X. 509 v 3 cert. ) to verify S’s authenticity [SKIP: C replies with: C’s certificate] C returns „pre-master secret” encrypted under KPUB-S § § § Pre-master secret - e. g. , 48 random B if selected cipher is RSA [Bishop. Comp. Sec-A&S, p. 296] . . . continued. . . 37

© 2006 -2007 by Leszek T. Lilien SSL protocol (a. k. a. TLS protocol) (3) . . . continued. . . § § „Pre-master secret” Constant strings ‘A’, ‘BB’ and ‘CCC’ Rand-C and Rand-S, SHA hashing algorithm [ibid, p. 294] § C and S switch to encrypted communication using „master secret” as session key C and S exchange application data for session duration § TLS is potentially vulnerable to MITM attacks § Section 5 – Computer Security and Information Assurance C and S calculate „master secret” using: § (i. e. , for as long as they stay connected) [Conklin eta al. , p. 163] 38

© 2006 -2007 by Leszek T. Lilien (vi) IPsec protocol suite (1) IPsec (IP Security Protocol Suite) = standard for securing § IP communications by encrypting and/or authenticating all IP packets IPsec is public (published / scrutinized) § Section 5 – Computer Security and Information Assurance § By design, protects against threats including: spoofing (incl. session hijacking) / eavesdropping § Choice of ciphers/hash protocols § Communicating parties negotiate which ones to use § IPsec defines some ciphers/hash as required in every IPsec implementaion 39

© 2006 -2007 by Leszek T. Lilien IPsec protocol suite (2) § IPsec provides security at IP layer in IPv 6 or IPv 4[Stall. p. 499] § IP versions: § IPv 4 = v. 4 — older IP protocol version (still in use) § IPv 6 = v. 6 — newer IP protocol version § IPv 6 — larger address space Section 5 – Computer Security and Information Assurance § IPv 6 — also other functional enhancements § § Developed (1992 -1998) since IPv 4 runs out of address space — IPv 4 has 32 -bit source/destination addresses — IPv 6 has 128 -bit source/destination addresses To accommodate faster networks To accommodate mix of multimedia data streams IPsec protects all layers above IP layer (where it „resides”) § In particular, protects TCP or UDP protocols § Protects „automatically” § Protects transparently (no modifications to TCP, UDP needed) 40

© 2006 -2007 by Leszek T. Lilien IPsec protocol suite (3) Basis of IPsec: security association (SA) = set of security parameters for a secured 1 -way communication channel § § § 2 SAs needed for 2 -way communication Components of SA: 1) Encryption algorithm and „mode” § Section 5 – Computer Security and Information Assurance [St, 487] 2) 3) 4) 5) E. g. , for DES, mode = CDC – cipher bloc chaining Encryption key Encryption params (e. g. , initialization vector for encryption) Authentication protocol and key SA lifespan § Allows long-running sessions to select new crypto key 6) Address of opposite end of SA (source <---> destination) 7) Sensitivity level of protected data § (e. g. , unclassified / restricted / confidential / secret / top secret) 41

© 2006 -2007 by Leszek T. Lilien IPsec protocol suite (4) Resides on each host H running IPsec Used to select 1 of n SAs that exist on H § § Section 5 – Computer Security and Information Assurance Security parameter index (SPI) data structure § Different SAs for concurrent communications with different remote Hs Fundamental IPsec data structures / protocols 1) AH = authentication header / AH protocol § For authentication-only IPsec service: § Authenticates S (sender ) 2) ESP = encapsulated security payload / ESP protocol § For encryption-only IPsec service OR § For combined encryption/authentication IPsec service 42

IPsec protocol suite (5) © 2006 -2007 by Leszek T. Lilien IPsec can be used for various crypto sessions: § VPN § e 2 e (incl. app 2 app) § For network mgmt (e. g. , for routing) § Section 5 – Computer Security and Information Assurance § IPsec scenario § TCP layer passes conventional TCP Header & Data down to IP layer § IP layer calls upon IPsec to encapsulate conventional TCP Header & Data into ESP (encapsulated security payload) § Fig. 7 -28, p. 441 § IP layer adds IP Header § IP layer passes packet down to physical layer § Physical layer adds Physical Header & Physical Trailer 43

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien [---SKIP---] IPsec protocol suite (6) § ESP structure – includes more than just TCP Header & Data § Fig. 7 -29, p. 441 § „authenticated” — portion authenticated by IPsec with Authentication Data (Auth. Data = kind of signature) § „encrypted” — portion encrypted by IPsec § Fields within ESP: 1) SPI (unencrypted) – index for security association to be used for this pkt 2) Sequence Number (unencrypted) – sequential number, prevents pkt replay attacks 3) Payload Data – (part of) data passed fr. TCP Layer 4) Padding / Padding Length – padding necessary to inflate pkt to required fixed size (e. g. , size required by block cipher used for encryption) 5) Next Header – type of data in Payload Data field 6) SKIP: Authentication Data (unencrypted) – authenticates all above fields 44

© 2006 -2007 by Leszek T. Lilien IPsec protocol suite (7) ISAKMP (Internet Security Association Key Management Protocol) = key mgmt protocol for IPsec § § In IPsec, ISAKMP implemented via IKE (ISAKMP Key Exchange) § Section 5 – Computer Security and Information Assurance ISAKMP is simple, flexible, scalable Distinct key for each IPsec security association (SA) § § § Key mgmt is always a critical element in crypto apps IKE properties § Provides ways to agree on protocols, cipher and authentication algorithms, keys § § § E. g. , agree as follows: protocol = EPS, cipher = triple DES; authentication alg. = SHA-1; key used for session Provides ways to manage protocols, cipher and authentication algorithms, keys Uses key exchange protocol based on Diffie. Hellman scheme 45

© 2006 -2007 by Leszek T. Lilien [---SKIP---] IPsec protocol suite (8) § IKE key exchange scenario (using Diffie-Hellman scheme) § X and Y know number g § X and Y choose large primes x and y, respectively § X send gx to Y / Y send gy to X § X calculates (gy)x / Y calculates (gx)y Since (gy)x = (gx)y => X and Y share secret § X and Y exchange identities & certificates Section 5 – Computer Security and Information Assurance § § Actual calculation is mod(n) — a bit more complex Certificates authenticate identities X and Y derive shared crypto key X and Y enter security association => they establish session IKE key exchange is very efficient § § § Can be done in 2 messages if w/o authentication Can be done in 4 messages if w/ authentication 46

© 2006 -2007 by Leszek T. Lilien vii. Signed code Problem: malicious active code § E. g. , malicious code on a web site for downloads § Partial solution: code signed by TTP (trusted third party) § TTP appends digital signature to piece of code § PKI can be used by prospective code users to validate signature § Section 5 – Computer Security and Information Assurance § Still code security not guaranteed § E. g. , March 2001 mistake of Verisign (CA) § Erronously issued two code-signing certificates to impostors masquerading as Microsoft employees § Verisign detected mistake after almost 2 months § Customers who didn’t validate certificate (by checking Verisign’s certificate revocation list) could still trust bad certificates 47

© 2006 -2007 by Leszek T. Lilien [---SKIP---] viii. Encrypted e-mail E-mail msgs – like a postard that everybody who handles it between S and R can read People use envelopes for confidentiality (C in C-I-A) We can „envelope” e-mail msgs by encrypting them § Encryption protects C and can protect I § Section 5 – Computer Security and Information Assurance § Encryption is easy, establishing good key mgmt is difficult § 2 basic key mgmt approaches: 1) Hierarchical certificate-based PKI solution § E. g. , S/MIME 2) Use of flat, individual-to-individual key exchange § § E. g. , PGP E-mail security (incl. PGP and S/MIME) will be discussed soon 48

e) Msg content integrity controls (1) © 2006 -2007 by Leszek T. Lilien [---SKIP---] Content integrity verification provided „for free” with encryption § § But attacker can modify encrypted data to make it useless § § Section 5 – Computer Security and Information Assurance Since can’t perform meaningful data modification w/o decrypting it § E. g. , changing a bit of data in packet Threats to msg content integrity 1) Malicious modification that changes content EASIER TO in a meaningful way 2) Nonmalicious modification that changes content PREVENT OR in a way that is not necessarily meaningful DETECT 3) Malicious modification that changes content in a way that is not meaningful NOTE: Different cases than in text! Encryption can solve the toughest case: Case (1) above 49

© 2006 -2007 by Leszek T. Lilien [---SKIP---] § Msg content integrity controls #1: DETECT Error detection and error correction codes § As discussed before („Intro to Cryptology” section) § § § Section 5 – Computer Security and Information Assurance Msg content integrity controls (2) Simplest error detection code: even/odd parity check More complex error detection codes: § Hash codes or Huffman codes Some detect multiple bit errors Some also pinpoint which bits are incorrect § For detecting/correcting nonmalicious changes § Can also stop some malicious attacks § Does not matter whether accidentally „meaningful” or not Again does not matter whether msg changes „meaningful” or not § E. g. , attackers not knowing which code used => can’t fool it § E. g. , attacker manipulating 2 bits & thinking that we have 2– bit correction code fails if we have 3 -bit correction code More complex error detection codes can stop tougher attackers 50

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien [---SKIP---] § § Msg content integrity controls (3) [SKIP] Msg content integrity controls #2: PREVENT or DETECT Cryptographic checksum / msg digest / hash § To prevent or malicious attacks on data — As discussed before („Intro to Cryptology” section) Can also detect malicious errors Can also detect nonmalicious errors Note that attacker can modify: § Modify only data bits § Modify error prevention/detection mechanism 51

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien f) Strong authentication § § Networked environments as well as both ends of communication need authentication Strong authentication controls include: i. One-time passwords ii. Challenge-response systems iii. Digital distributed authentication iv. Kerberos authentication system 52

© 2006 -2007 by Leszek T. Lilien [---SKIP---] i. § One-time password (OTP) method § Controls wiretapping and spoofing § § § Section 5 – Computer Security and Information Assurance One-time passwords (1) Prevents reuse of pwd captured by wiretapper Strong authentication prevents spoofing (incl. masquerading, session hijacking, MITM) Each password used only once § „Thrown away” after use § OTP uses secretly maintained pwd list OR § User has password token (PT) = device to randomly generate new pwd (e. g. ) every minute E. g. , Secure. ID device from Security Dynamics – random # every minute 53

[---SKIP---] One-time passwords (2) Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien § § Pwd generation for user U is based on time synchronization with PT of this particular user U § Pwd changed in sync by both U’s PT and system authenticating U § PTs of different users produce different pwd sequences Problems with OTP 1) Attacker can steal/find PT (device) 2) One-minute window of vulnerability § Wiretapper can reuse password for one minute § If PT generates new pwd once per minute 54

© 2006 -2007 by Leszek T. Lilien [---SKIP---] ii. systems § Challenge-response systems solve OTP problems 1) Solve problem of stolen/lost password tokens (PTs) § Solution: PT requires a PIN § Even if stolen by attacker, PIN protects „responses” Section 5 – Computer Security and Information Assurance 2) Solve problem of window of vulnerability § Solution: New challenge for each use § Does not matter whether new use within one minute window or not § Challenge-response systems can be viewed as more sophisticated version of OTP § Problem: Neither OTP or C-RS protect user from rogue system 55

iii. Digital distributed authentication (1) © 2006 -2007 by Leszek T. Lilien [---SKIP---] „Digital” from „Digital Equipment Corporation” (DEC) § Once a powerful computer company § § § Acquired (1998) by Compaq, which subsequently merged with Hewlett. Packard (2002) [Wikipedia] As of 2004 their product lines were still produced under HP name Section 5 – Computer Security and Information Assurance § In 1980 s DEC recognized need for authentication of nonhuman entities in distributed environment § E. g. , mutual authentication of user query processor and DB manager (process) § Goals of Digital distributed authentication: § Prevent server impersonation (e. g. , DB mgr impersonation) § Prevent interception/modific. of msgs between entities § Prevent replay of previous authentication 56

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien [---SKIP---] § Digital distributed authentication (2) Architecture of Digital distributed authentication (1989): § Each server S has KPRIV-S Corresponding KPUB-S available to any process that might need authenticated channel to S § A to B communication uses KPUB-B B to A communication uses KPUB-A § A and B use sequence #s to msg replay § B can establish secret (symmetric) session key K for communication with A by: § Selecting key K § Sending E(K, KPUB-A) to A § From now on, A and B can exchange data encrypted with K 57

© 2006 -2007 by Leszek T. Lilien iv. Kerberos authentication system (1) § Kerberos – system for authentication between intelligent processes in distributed systems (incl. C-S authentication) [K. = guard dog in Hades (Greek mythology)] § Developed at MIT (1988+) Section 5 – Computer Security and Information Assurance § Design goal: § Enable systems to withstand attacks in distributed systems § Basic idea of Kerberos: Central server provides tickets to requesting app § Ticket is authenticated, non-forgeable, non-replayable token => Implemented as encrypted data structure naming user U and service for which U has access permission (also contains time value, control info) 58

© 2006 -2007 by Leszek T. Lilien Kerberos authentication system (2) § User’s Step 1: Establishing session w/ Kerberos — Fig. 730, p. 448 § U’s workstat’n sends U’s identity to Kerberos server (KS) § KS verifies that U is authorized § KS sends 2 msgs: U U 1) Msg to U, which contains: E(ST-GS + TT-GS , pwd) U § ST-GS — U’s session key for session with T-GS U § TT-GS — U’s ticket for T-GS Enables U to request service from T-GS pwd — user’s pwd (Note: used as encryption key by KS) Section 5 – Computer Security and Information Assurance § § U 2) Msg to T-GS, which contains: ST-GS and U’s identity (encrypted under key shared by KS and T-GS) U § ST-GS — T-GS’s session key for session with U (same as U’s session key for session with T-GS) § U U If U’s workstation can decrypt E(ST-GS + TT-GS , pwd) using its pwd, then U’s authentication succeeds 59

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien Kerberos authentication system (3) § Note: KS stores users’ pwds => no need to pass pwds over network between U’s workstation and KS § Security advantage! § User’s Step 2: Access services of distributed system — e. g. , access file F — Fig. 7 -31, p. 448 § Using U’s ticket for T-GS (received fr. KS in Step 1), U sends to T-GS: U E(„request R for U’s ticket for accessing F” , ST-GS) U Note: ST-GS (U’s session key for session with T-GS obtained fr. KS in Step 1) is used to encrypt R § T-GS verifies U’s access permission. . . continued. . . 60

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien Kerberos authentication system (4). . . continued. . . § If verified OK, T-GS returns to U message encrypted U under ST-GS, which contains: 1) U’s session key for session with F (really: with F’s file U server) = SF 2) U’s ticket for accessing F § Ticket is encrypted under secret key („T-GS—F key”) known only to T-GS and F’s file server § Ticket contains: U § U’s authenticated identity (T-GS knows that ST-GS is U’s key —and nobody else’s— because KS sent to T-GS U ST-GS and U’s identity tied together in Step 1) § Identification of file F § Access rights (e. g. , read permission) U § F’s session key for F’s session with U = SF (same as U’s session key for session with F) § Ticket expiration date 61

© 2006 -2007 by Leszek T. Lilien Kerberos authentication system (5) § Strengths of Kerberos: 1) No pwds communicated over network § Pwd sent by user to Kerberos server only once & sent outside the network (e. g. , in a letter) § § User’s pwd is not sent from user’s workstation when it initiates a session User’s pwd stored only at Kerberos server Section 5 – Computer Security and Information Assurance 2) Provides crypto protection against spoofing (e. g. , masquearding, session hijacking, MITM) § § Each access request mediated by a ticket-granting service (T-GS) T-GS knows user’s identity based on authentication performed initially by the server 62

© 2006 -2007 by Leszek T. Lilien Kerberos authentication system (6) § Strengths of Kerberos – cont. 1 3) Limits period of ticket validity (this disables some long-term attacks—e. g. , brute force cryptanalysis) § Section 5 – Computer Security and Information Assurance § Tickets contain timestamps used by servers to determine ticket’s validity Ticket validity period limits duration of „window of opportunity” for attacker 4) Prevents replay attacks § Each user’s request stamped with time of request § Servers compare timestamps of requests w/ current time, accept requests only if they are close enough to current time § Time-checking prevents most replay attacks § Since presentation of tickets by attackers will be delayed more than presentation of tickets by legitimate users 63

© 2006 -2007 by Leszek T. Lilien Kerberos authentication system (7) § Strengths of Kerberos – cont. 2 5) Provides mutual authentication § Service user can be assured of any server’s authenticity by requesting an authenticating response from S Section 5 – Computer Security and Information Assurance 6) Uses public key technology for key exchange 64

© 2006 -2007 by Leszek T. Lilien Kerberos authentication system (8) § Weaknesses of Kerberos system 1) Requires continuous availability of trusted ticketgranting server (T-GS) 2) Server S’ authenticity requires trust between T-GS & S 3) Requires timely transactions (too quick ticket expiration will result in rejecting legitimate requests) Section 5 – Computer Security and Information Assurance 4) Subverted workstation can replay user pwds 5) Pwd guessing works (attacker can send initial —Step 1— 6) authentication request to Kerberos server, receive response, try to decrypt response by guessing at pwd) Kerberos does not scale well (due to system size might need > 1 KS and/or T-GS server; coordination and security problems if more than one KS and/or more than one T-GS is needed; cf. Fig. 7 -32, p. 450) 7) Use of Kerberos requires compatibility of all apps in a given computing environment (to date few apps are compatible with Kerberos; modifying apps to make them compatible is not feasible) 65

© 2006 -2007 by Leszek T. Lilien g) Access controls (1) n Section 5 – Computer Security and Information Assurance n Before user is allowed access to network resources, must know: n Who needs access => authentication n What and how will be accessed => access controls Access controls include: 1) ACLs (Access Control Lists) on router 2) Firewalls 66

© 2006 -2007 by Leszek T. Lilien Access controls (2) 1) ACLs on routers (ACL = Access Control List) n Router directs traffic: n To subnetworks it controls OR n To other routers (for delivery to other subnetworks) n Routers convert external (network-wide)IP address to internal (subnetwork-wide) MAC address Section 5 – Computer Security and Information Assurance n n n Recall that MAC address is unique physical address of device’s NIC —network interface card Can put ACL on a router to deny access to particular host D from particular host S n E. g. , to prevent spam (flooding) of D with packets from S, router can delete all packets from S to D It’s OK if router uses ACLs in a limiteded way n Use sparingly: only for specific & known threats BUT. . . 67

© 2006 -2007 by Leszek T. Lilien Access controls (3) n . . . Problems with putting too many ACLs on routers: (i) Packet-checking overhead for router n Router must check each packet against each ACL – a lot of work => degraded performance n Section 5 – Computer Security and Information Assurance n More ACLs on router => more work Routers are already busy just routing all packets ingoing/outgoing to/from their subnets (ii) Logging overhead for router n To be able to detect spam, router must log source addresses of packets n n Then can analyze to see which source addresses produce floods Routers are designed to do only essential work — anything else is inefficient => logging on router is inefficient => adds workload 68

© 2006 -2007 by Leszek T. Lilien Access controls (4) n . . . Problems with putting too many ACLs on routers-CONT. (iii) Inability of router to detect all spams n Because source addresses in datagrams (UDP packets) can be easily forged (by attacker using UDP protocol) Section 5 – Computer Security and Information Assurance n If attacker sends many datagrams with the same (repeated) forged address, router with ACL can detect & block them Otherwise (i. e. , if attacker sends datagrams with few repeated forged addresses), router with ACL will not even detect being flooded => can not block flooding datagrams 69

© 2006 -2007 by Leszek T. Lilien Access controls (5) 2) Firewalls n Designed to do screening that routers can’t do efficiently n Because routers designed for routing (of course!) n Firewalls designed for access filtering AND auditing AND examining whole packets (not only source/destination Section 5 – Computer Security and Information Assurance IP/ MAC addresses—which is what routers do) n Firewalls will be discussed in detail later (but very soon) 70

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien h) Intrusion Detection Systems: Alarms & Alerts n Example of 2 -layer network protection n Provided by router (Layer 1) AND firewall (Layer 2) n Fig. 7 -33, p. 452 We can add one more layer of protection: intrusion detection systems (IDS) = device placed within protected network for monitoring for illegitimate actions in order to detect attacks in progress (beginning, advanced) or after they have occurred n n OR n n n Can detect that attack has already occurred & raise alarm, starting system recovery actions IDS is a. k. a. IPS = intrusion protection system n n E. g. : Can detect reconaissance & alert sysadmin or secadmin, raise alarm, thus preventing „real” attack A marketing gimmick? IDS can be Layer 3 of layered network protection To be discussed in detail soon 71

© 2006 -2007 by Leszek T. Lilien i) Honeypots n Honeypot – system built as a bait attracting attackers n Once attackers take the bait: n They are observed to learn how they behave/operate n n They are traced to catch them or scare them off Section 5 – Computer Security and Information Assurance n n Or at least trace enough to be able to threaten them with identifying them if they don’t stop They are diverted from really valuable attack targets n n New attacks / Prefered targets /. . . E. g. , diverted to phony credit card database while real credit card database remains obscure to them User lessons learned (thanks to honeypots) to build better countermeasures 72

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien j) Traffic flow security (1) n Threat: attacker infering occurrence/location of some event / structure from intensity of encrypted network traffic (If not encrypted, no need to infer – attacker can simply read all) n Example 1: Inference that traffic between Thinges Corp. and bankruptcy lawyer precedes declaration of bankruptcy by Thinges n Example 2 (old): Battlefield network: Busiest network node is at enemy’s HQs § Solution 1: Masking by steady traffic volume § X and Y always send the same volume of encrypted traffic between them § If X has nothing to communicate to Y, X sends meaningless padding packets to Y (Y behaves analogously) 73

© 2006 -2007 by Leszek T. Lilien Traffic flow security (2) § Solution 2: Masking by onion routing § Example: W wants to send packet to Z in a hidden way § W wraps „real” packet to Z into packet addressed to Y, which asks Y to send it to. Z § W wraps packet to Y into packet addressed to X, which asks X to send it to Y Section 5 – Computer Security and Information Assurance Onion-like packet sent by W to X Send packet to Y Send packet to Z § Full route: W X Y Z § W sends green packet to X § X unwraps it, gets red packet X sends red packet to Y § Y unwraps it, gets blue packet Y sends blue packet to z § Z unwraps it, gets blue packet 74

© 2006 -2007 by Leszek T. Lilien Traffic flow security (3) § Why „onion” routing? Layers of wraps around „real” packet to Y– like layers of an onion § Note: (Recall the full route: W X Y Z ) § X knows that packet came from W & should be forwarded to Y § Section 5 – Computer Security and Information Assurance § Y knows that packet came from X & should be forwarded to Z § § But X does not know if W is source or intermediate host, does not know if Y is destination or intermediate host But Y does not know if X is source or intermediate host, does not know if Z is destination or intermediate host Z knows that packet came directly from Y & knows that W is its source § Z knows that Y is just an intermediate host => Intermediate nodes do not know source/destination They only know host that forwarded packet to them & know host to which they should forward packet 75

© 2006 -2007 by Leszek T. Lilien k) Review of network security controls § § Table 7 -4, p. 426 provided classification of network vulnerabilities (during our earlier discussion of threats) Table 7 -7, p. 454 lists controls for each of these classes of network vulnerabilities — it shows that: § There are many great network security controls § Most are used also in environments other than networks (including applications and OSs) Section 5 – Computer Security and Information Assurance § § Three of these controls are specific to networks: § Firewalls / IDSs / encrypted e-mail We shall discuss them in some detail next Table 7 -7 is a great reference for network security controls! § Use it often § § If you can get copyright permission from publisher, I’d advise you to copy it and post above your desk Otherwise, make your own notes based on it 76

© 2006 -2007 by Leszek T. Lilien 5. 2. Network Security Tools Section 5 – Computer Security and Information Assurance [Fig: B. Endicott-Popovsky] § Network security tools 5. 2. 1. Firewalls 5. 2. 2. Intrusion Detection Systems 5. 2. 3. Secure E-Mail 77

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien 5. 2. 1. Firewalls § --SKIP-- Outline a) Introduction b) What is a firewall c) Firewall design d) Types of firewalls i. Packet filters (i-1) Simple packet filters (i-2) Stateful packet filters ii. Application proxies (ii-1) Guards (“top model” subcategory) iii. Personal firewalls e) Comparison of firewall types f) Example firewall configurations g) What firewalls can—and can’t—block 78

© 2006 -2007 by Leszek T. Lilien --SKIP-§ Firewalls n Invented in the early 1990’s n But idea related to reference monitors from 1970’s n Section 5 – Computer Security and Information Assurance a. Introduction What is reference monitor? n OS includes kernel / core / nucleous – responsible for lowestlevel functions n Incl. synchronization, inter-process communication, msg passing, interrupt handling n Security kernel – provides security mechanisms for entire OS n Incl. security interfaces among h/w, OS, other parts of computing system n Typically, security kernel is a part of OS kernel n Reference monitor is portion of security kernel that controls access to objects (controls „references” to objects) 79

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien b. What is a firewall (1 a) n Firewall = device (h/w), or software, or combination of both designed: 1) to prevent unauthorized outside users from accessing network and/or single workstation 2) to prevent inside users from xmitting sensitive information or accessing insecure resources It is a wall between protected local (sub)net & outside global net n Inspect each individual inbound or outbound packet of data sent to / from protected system n Check if it should be blocked or allowed to enter 80

© 2006 -2007 by Leszek T. Lilien --SKIP-- b. What is a firewall (1 b) § Firewalls keep „bad things” out, keep sensitive info in n Security policy specifies what are „bad things” n n Section 5 – Computer Security and Information Assurance n E. g. , requires that traceroute & ping -o can't see internal hosts F. protect against security threats from external network F. are effective in protecting local subnet incl. its sensitive info 81

© 2006 -2007 by Leszek T. Lilien What is a firewall (2) n Examples of security policy requirements w. r. t. firewalls: § Block any access from the outside, allow all accesses to the outside § Allow”from” accesses only for certain activities OR only to/from certain subnets/hosts/apps/users § Section 5 – Computer Security and Information Assurance n E. g. , prevent outside access to subnet hosts except for mail server accesses Choice of default firewall behavior 1) Default permit n „That which is not expressly forbidden is allowed” 2) Default deny n n „That which is not expressly allowed is forbidden” Users prefer default permit, security experts prefer default deny n Sysadmin must make the choice 82

© 2006 -2007 by Leszek T. Lilien --SKIP-- c. Firewall design (1) § Firewall design principles: § Small / simple enough for rigorous analysis § KISS principle (= „Keep It Simple, Stupid”) § Simple firewall functionality § Tamperproof § Typically well isolated (=> highly immune to modifications) Section 5 – Computer Security and Information Assurance § § § On a separate computer With direct connections only to the outside networks and to the inside network Designed to be always invoked § Efficient enough not too be a bottleneck § Placed strategically § All network accesses that we want to control pass through it 83

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien --SKIP-- Firewall design (2) § General firewall techniques: 1) Service control n Type of service: inbound or outbound 2) Traffic filtering — based on IP address & TCP port nr n Provide proxy software to receive or interpret service request before passing it on n Could also host server software (e. g. Web or mail service) n Not recommended n Complicates it (more code => more vulnerabilities) 3) User Control n Control access to service using ACLs 4) Behavior Control n E. g. filter e-mail for spam 84

© 2006 -2007 by Leszek T. Lilien --SKIP-- Firewall design (3) n Basic firewall characteristics n All traffic (incoming / outgoing) must pass thru firewall n Only authorized traffic allowed to pass n Firewall itself must be immune to penetration n n I. e. must use trusted system w/ secure OS (min. size/complexity) Usually implemented on dedicated device n n Section 5 – Computer Security and Information Assurance n Dedicated = only firewall functions performed on this device Firewall code must be very well protected Basic kinds of firewalls: n Hardware firewalls n More common n Implemented on router level n More expensive / more difficult to configure n Software firewalls n Used in single workstations n Less expensive / Easier to configure 85

© 2006 -2007 by Leszek T. Lilien d. Types of firewalls (1) § Types of firewalls i. Packet filters / packet filtering firewalls Control packets based on packet’s IP adresses and port #s (i-1) Simple packet filters / (simple, stateless) packet filtering gateways / screening routers (stateless = ignore history) (i-2) Stateful packet filters / stateful inspection firewalls Section 5 – Computer Security and Information Assurance ii. Application proxies / proxy firewalls / application-level gateways More sophisticated than packet filters. Control packets based on any data within a packet (not only based on packet’s IP adresses and port # as packet filetres do) => => can detect/derail more sophisticated attacks (e. g. , can filter out harmful commands in pkt stream) (ii-1) Guards (a special case of app proxies) iii. Personal firewalls (not subnetworks R like regular firewalls do) For small business / home office / home Protect single hosts 86

© 2006 -2007 by Leszek T. Lilien --SKIP-- Types of firewalls (2) n Firewall properties: n Packet filter properties: n Transparent n Does not change traffic, only passes it Section 5 – Computer Security and Information Assurance n (or blocks some) Proxy properties: n Active n Intercepts traffic & acts as an intermediary Different firewall types needed for different needs n n n „Different strokes for different floks” — e. g. : Simple packet filters / screening routers – implement simplistic security policies n Simple is best if sufficient to counter exisiting threats well App proxies – much richer capabilities 87

© 2006 -2007 by Leszek T. Lilien --SKIP-- Types of firewalls (3) Firewall is a type of host n Even some routers are host-based To have better tools available (editors, programming tools) n n Programmable Minimal functionality n Reduces vulnerabilities n Section 5 – Computer Security and Information Assurance n Small = > less complex => fewer vulnerabilities Reduces motivation for attacks n No password files to steal, etc. 88

© 2006 -2007 by Leszek T. Lilien --SKIP-- (i) Packet filters (1) n n Packet filters — a. k. a. packet filtering firewalls (i-1) Simple packet filters („memoryless”) (i-2) Stateful packet filters (with „memory”) Basis for packet filtering 1) Packet IP addresses Section 5 – Computer Security and Information Assurance n Filtering based on both source/destination addresses 2) Port number determines TCP transport protocol type n n n Recall “port protocol” mapping in TCP: 21 FTP, 23 Telnet, 25 SMTP, 80 HTTP, 110 POP, 161 SNMP, etc. Filtering based on port nr Packet filtering firewalls do not „see” other packet fields n n See only IP address ‘ transport protocol type E. g. , can not allow only some Telnet commands OR exclude only some other Telnet commands 89

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien --SKIP-- (i) Packet filters (2) n Examples of packet filtering – see text 1 a) Packet address filtering (cf. Fig. 7 -35, p. 459) Can block traffic from specific subnets and/or allow traffic from specific subnets 1 b) Packet address filtering (cf. Fig. 7 -36, p. 460) Can block traffic from specific IP addresses and/or allow traffic from specific IP addresses 2) Filtering based on transport protocol (cf. Fig. 7 -35, p. 459) Can block traffic using Telnet protocol (port 23) but allow HTTP traffic (port 80) n To avoid overburdening router, firewall can run on device behind router (on subnet side) 90

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien --SKIP-- (i-1) Simple packet filters / (simple) packet filtering gateways / screening routers — simplest firewall type n § (1) Simple packet filters (PFs) are memoryless => can not perform attack detections that require remembering state (history/context) of ≥ N last pkts § E. g. , can not see that prev. & curr. pkt indicate attack § “Attack signature” (i. e. , attack pattern) would be clearly visible if both pkts were put together § n Example: Certain attack script known to use Telnet (port 23) and then SNMP (port 161) The same source address in previous pkt, using port 23, and in current packet, using port 161, constitutes attack signature Why need to remember ≥ N last pkts? n TCP pkts arrive in order different than sending order => remembering ≤ N last pkts is not enough 91

© 2006 -2007 by Leszek T. Lilien --SKIP-- (i-1) Simple packet filters (2) § Cheating simple (memoryless) PF: § Attacker divides pkt (including attack signature) into many v. short pkts § Attack signature (pattern) would be visible in original long pkt § Even memoryless simple PF would detect it Section 5 – Computer Security and Information Assurance § Pattern of attack is completely invisible in any single short pkt § n => memoryless simple PF is unable to detect attack Additionally, TCP pkts arrive in order different than their sending order => remembering just last packet would not be enough – must remember N last packets 92

© 2006 -2007 by Leszek T. Lilien --SKIP-- (i-1) Simple packet filters (3) n One very important task for simple packet filtering gateways: Validating inside IP addresses n Inside hosts trust more other inside host n Simple filtering assures that no external source can masquerade as internal source Section 5 – Computer Security and Information Assurance n Blocks any packet coming from outside network that claims to be sent by internal host n Cf. Fig. 7 -37, p. 460 93

© 2006 -2007 by Leszek T. Lilien --SKIP-- (i-1) Simple packet filters (4) n Simplicity of inspection is both disadvantage & advantage n Disadvantage because of high granularity n E. g. , can block all Telnet coomands, but can not block only selected telnet commands n Advantage beacuse reduces complexity Section 5 – Computer Security and Information Assurance n Filtering rules to block, e. g. , only selected Telnet traffic would have to be much more detailed => more complex => more vulnerable 94

© 2006 -2007 by Leszek T. Lilien --SKIP-- (i-2) Stateful packet filters — a. k. a. stateful inspection firewalls § § => stateful packet filters have memory § § Section 5 – Computer Security and Information Assurance Keep state/history/context of N previously seen pkts This allows detection of some attacks that simple PFs can not detect Still limited to detection based on IP address & TCP transport protocol type (port nr) 95

© 2006 -2007 by Leszek T. Lilien --SKIP-- (ii) Application proxies (1) § Note: The term bastion host (used in text) should not be used as a synonym. Bastion host is a host that serves as a platform for app proxy or circuit-level proxy [Stallings, Crypto&Net. Sec, p. 625]. n n Section 5 – Computer Security and Information Assurance Application proxies / proxy firewalls / application-level gateways / application proxy gateways Application proxies include — as a special case (ii-1) Guards App proxy firewalls fix basic problem with packet filtering firewalls because they: n See all pkt data (not just IP adresses and port #s) n (In addition, they are stateful => can analyze multiple pkts) => can detect/derail more sophisticated attacks n Can filter out harmful commands in pkt stream 96

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien --SKIP-- (ii) Application proxies (2) n For example, app proxies can prevent: n Use of back door open to pkts inbound to SMTP port (Port 25) n Flawed application run by user U (e. g. , an e-mail agent) has all U’s privileges => can cause damage 97

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien --SKIP-- (ii) Application proxies (3) Act as mediators/censors (!) of app-level traffic – like benevolent „woman-in-the middle” (not an official term!) n n They “censor” insecure actions Maybe a rare case of a truly benevolent censor Ex. scenario of using app proxy gateway G: [cf. ibid, p. 624] n Extern. user U tries to Telnet to host H protected by G n G intercepts U’s packets n G acts as H would: asks U for id+pwd n U replies w/ id+pwd n G logs in into H on behalf of U n G relays H’s msgs to U n Etc. , etc. 98

© 2006 -2007 by Leszek T. Lilien --SKIP-- (ii) Application proxies (4) § n Section 5 – Computer Security and Information Assurance n Examples of app proxy activities § Preventing outsiders from modifying company’s online price list § More - see bulleted list on p. 462 App proxy must implement code for given app (e. g. , for Telnet) to be able to perform service to this app Netadmin can configure app proxy to support only selected features of an app n Unsupported features are considered too risky => not available 99

© 2006 -2007 by Leszek T. Lilien --SKIP-- (ii) Application proxies (5) n App proxies provide higher level of security than packet filters (PFs) n PFs try to deal with all potentially deployable applications that could use TCP/IP (default permit philosophy) n App proxy considers only few allowable apps among ones actually deployed in a given system (default deny philosophy) App proxy can easily log/audit traffic at app level (vs. Section 5 – Computer Security and Information Assurance n transport level for PFs) n Prime disadvantage of app proxies: Processing overhead for each app-level connection n 1 connection split into 2 logical connections n n With “woman-in-the-middle” Circuit-level gateways (another proxy subcategory) splits 1 TCP connection into 2 TCP connections 100

© 2006 -2007 by Leszek T. Lilien --SKIP-- (ii) Application proxies (6) (ii-1) Guards = most sophisticated category of app proxies (“top model”) Limited only by what is computable (& by human creativity) No sharp boundary between app proxies and guards § § § At some point of upgrading app proxy, it becomes a guard --SKIP-- ----> Section 5 – Computer Security and Information Assurance § Examples of guard activities § Limiting nr of msgs (or nr of msg characters) that a student may e-mail per week § Easiest if done by gurad monitoring mail transfer protocol § More - see bulleted list on p. 464 101

© 2006 -2007 by Leszek T. Lilien --SKIP-- (iii) Personal firewalls n Regular firewalls protects subnetworks Personal firewalls protect single hosts n For small business / home office / home n Can be used to complement conventional firewall n Next line of defense n Customized to user(s) of particular host n Firewall capabilities at a lower price Personal firewall is application program Section 5 – Computer Security and Information Assurance n n Products include: Norton Personal Firewall (Symantec), Mc. Afee Personal Firewall, Zone Alarm (Zone Labs) Personal firewall also enforces certain security policy n n n E. g. , if you’re using default personal firewall’s policy on your computer, see its rules Combine it with antivirus software for more effective protection & with automatic (or very frequent manual) OS and antivirus s/w updates 102

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien --SKIP-- e. Comparison of firewall types § See Table 7 -8, p. 465 § Criteria: § Complexity § Part of packets visible to firewall § Difficulty of auditing § Basis for screening § Difficulty of configuring 103

© 2006 -2007 by Leszek T. Lilien f. Example firewall configurations § Subnet with screening router (simple packet filtering) — Fig. 7 -39, p. 466 § Subnet with proxy gateway (app proxy) — Fig. 7 -40, p. 467 § Section 5 – Computer Security and Information Assurance § Subnet with simple PF & app proxy — Fig. 7 -41, p. 467 § Note: The LAN between outer firewall (“screening router” in the fig) and the inner firewall (“proxy firewall” in the fig) constitutes DMZ (demilitarized zone) 104

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien g. What firewalls can—and can’t—block § Firewalls are not a panacea - only a perimeter protection § Points 2 remember about firewalls — see text, p. 466 -467 § § § Can protect environment only if control its whole perimeter Do not protect data outside the perimeter Are most visible subnet component – attractive attack targets Must be correctly configured, & config must be periodically updated Firewall platforms should not have any s/w that could help attacker who penetrates firewall in subsequent exploits Firewalls exercise very limited control over content they let in § Other means of verifying/enforcing accuracy/correctness must be used inside perimeter 105

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien 5. 2. 2. Intrusion Detection Systems § --SKIP-- Outline a) Introduction b) Types of IDSs i. Signature-based IDSs ii. Anomaly-based IDSs iii. Other IDSs c) Goals for IDSs d) IDS strengths and limitations 106

© 2006 -2007 by Leszek T. Lilien a. Introduction (1) n n n Section 5 – Computer Security and Information Assurance It is better to prevent attack than to detect it after it succeeds Unfortunately, not all attacks can be prevented § Some attackers become intruders — succeed in breaking defenses Intrusion prevention — first line of defense Intrusion detection — second line of defense Intrusion detection system (IDS) - a device (typically a seprate monitoring system activities to detect malicious / suspicious events IDSs attempt to detect n Outsiders breaking into a system OR n Insiders (legitimate users) attempting illegitimate actions computer) n n Accidentally OR deliberately 107

© 2006 -2007 by Leszek T. Lilien --SKIP-- Introduction (2) n We’ll be talking only about real-time IDSs n n n Section 5 – Computer Security and Information Assurance IDS runs constantly in the background n Alarms when it detects something suspicious Ignoring off-line IDSs (early IDSs reviewed logs after th fact) IDS should operate in stealth mode — be invisible to outside world n IDS interfaces (cf. Fig. 7 -43, p. 471) 1) Alarm interface through which raises alarm n On a completely separate control network 2) Monitoring interface to protected (sub)network n Never sends msgs on this interface! n Preferably, IDS has no published address through the monitored => router does not even know IDS platform exists => router can not send anything to IDS directly 108

© 2006 -2007 by Leszek T. Lilien Introduction (3) § IDS terminology n Anomaly — abnormal behavior n n — activity that violates the security policy (subset of “anomaly” – anomaly that is illegitimate) n n Section 5 – Computer Security and Information Assurance Misuse Might either be still legitimate OR illegitimate n Intrusion — misuse by outsiders and insiders Audit — activity of looking at user/system behavior, Profiling its effects, or collected data — looking at users or systems to determine what they usually do 109

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien ---[SKIP]--- Introduction (4) n Superset of IDS functions n Monitoring users and system activity n Auditing system configuration for vulnerabilities & misconfigurations n Assessing integrity of critical system and app files n Recognizing known attack patterns n Identifying abnormal activities through statistical analysis n Managing audit trails (logs) and highlighting misuses or anomalies in user activities n Correcting system config errors n Installing & operating traps (honeypots) to learn about intruders 110

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien b. Types of IDSs (1 a) § IDS types w. r. t. scope: n Host-based n Runs on a host n Monitors activities on this host only n Network-based n Stand–alone device n Monitors entire (sub)network 111

© 2006 -2007 by Leszek T. Lilien b. Types of IDSs (1 b) § IDS types w. r. t. their operation i. Signature-based IDSs n n n (“block only ‘blacklisted’ behavior”) Models & looks for unacceptable system activities (= an attack) n Each known attack characterized by its „signature” (pattern) To detect attack, matches current activities to known attack signatures Problem: Unable to detect new attacks (unknown signatures!) Section 5 – Computer Security and Information Assurance ii. Anomaly-based (heuristic) IDSs n n Solves the above problem (but might generate more false alarms) Uses model of acceptable user activities n n (“allow only permitted behavior”) Not models (signatures) of unacceptable system activities Raises alarm upon detection of deviation form model behavior iii. Other IDS types n E. g. , hybrid IDSs (combining signature- and anomaly-based IDSs), immune-system-based IDSs 112

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien --SKIP-- Types of IDSs (2) i. Signature-based IDS n Looks for unacceptable system activities (considered an attack) n Each known attack characterized by its „signature” (pattern) n To detect attack, matches current activities to known attack signatures n Even attack with signature „similar” to signature of a known attack can be detected n Example signature for port scan attack n n Syn to port 80 Syn to port 25 Syn to port 161. . . 113

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien --SKIP-- Types of IDSs (3) n n Problems with signature-based IDSs (1) Can not detect attack with unknown signature n Must know (exact or very similar) attack signature to detect attack (2) Attacker can „pad” attack with packets that break known signature into unknown patterns (3) False alarms occur n When legitimate data accidentally match attack signature Solution to (1) and (2): anomaly-based IDSs 114

© 2006 -2007 by Leszek T. Lilien --SKIP-- Types of IDSs (4) ii. Anomaly-based IDS (heuristic IDS) n Uses model of acceptable user behavior n n Section 5 – Computer Security and Information Assurance n Recall that signature-based IDS uses models (signatures) of unacceptable system activities (system behavior) Watches user activities n Watches for deviations from model behavior Raises alarm upon detection of suspicious behavior n If false alarm, admin can „teach” IDS to accept such behavior in the future 115

© 2006 -2007 by Leszek T. Lilien --SKIP-- Types of IDSs (5) Example model of acceptable user’s behavior n n n Logs in Reads e-mail User word processor. . . Section 5 – Computer Security and Information Assurance Note: Use of sensitive system management utilities would be a deviation from the model of acceptable user’s behavior 116

© 2006 -2007 by Leszek T. Lilien --SKIP-- Types of IDSs (6) (ii-1) Misuse IDS — can be considered a subset of anomaly detection (since misuse is a subset of anomaly – see above) n Uses model of unacceptable user behavior n Section 5 – Computer Security and Information Assurance n Recall that „regular” anomaly-based IDS uses models of acceptable user behavior Recall that signature-based IDS uses models (signatures) of unacceptable system activities (system behavior) n Could misuse IDS be considered a variation of signaturebased IDS? Example model of unacceptable user’s behavior n n Attempt to copy pwd file Attempt to open pwd file. . . 117

© 2006 -2007 by Leszek T. Lilien --SKIP-- Types of IDSs (7) iii. Other IDSs n E. g. , hybrid IDSs (combining signature- and anomalybased IDSs), immune-system-based IDSs Section 5 – Computer Security and Information Assurance n Under more liberal definiton of IDS, the following are called IDSs: n Tripwire program — cf. p. 471 n n Produces hash value for each file when installed, values saved in secure place Later can be called to verify that file was not compromised Vulnerability scanners Honeypots 118

© 2006 -2007 by Leszek T. Lilien c. Goals for IDSs § (1) IDS goals 1) Detect all attacks correctly n Avoid false positives (false alarms) n False alarms annoy sysadmins, users, . . . Avoid false negatives (not recognizing attacks) 2) Little overhead / performance impacts Section 5 – Computer Security and Information Assurance n § --SKIP-- Range of IDS alarms n Write a record to audit log Urgency n. . . n Page security administrator 119

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien --SKIP-- Goals for IDSs (2) § Categories of IDS responses 1) Monitor, collect data, collect more data n For attacks with modest impact n Invisible to attacker n Can be used to study attacker’s actions (like honeypot) 2) Protect, reduce exposure n E. g. , making certain files unavailable to any access n May be very visible to attacker 3) Call a human n For attacks with highest impact potential n Calling a human preceded by some automatic actions n § Since humans take very long time (compared to computer time) to respond Any combination of (1), (2) , (3) into single response is possible 120

© 2006 -2007 by Leszek T. Lilien --SKIP-- d. IDS strengths and limitations § Section 5 – Computer Security and Information Assurance n IDS strengths § Becoming more effective (e. g. , DBs of attack signatures grow) § Becoming cheaper § Becoming easier to administer IDS limitations n Attackers use avoidance strategies to avoid detection by IDS n IDS sensitivity is difficult to measure and adjust n n Must strike a balance false alarms and missing attacks Only as good as the process/people using it 121

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien 5. 2. 3. Secure E-Mail § --SKIP-- Outline a) Introduction b) Security for e-mail c) Design of PEM (Privacy-enhanced Electronic Mail) d) Example secure e-mail systems i. PGP ii. S/MIME 122

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien a. Introduction E-mail is the most heavily used network-based application Yet, ordinary email is very public, exposed It has no C / I (confid. /integ) § n Unencrypted message contents can be peeked at either in transit or by privileged users at destination host 123

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien --SKIP-- b. Security for e-mail Threats to e-mail § interception (confidentiality) interception (blocked delivery) interception+replay content modification origin modification (1) Controls § § § Msg Msg Msg encryption no S/R controls encryption (+seq. nr) encryption § § Msg content forgery by outsider Msg origin forgery by outsider encryption § § Msg content forgery by recipient (R) Msg origin forgery by recipient publ. key encr. § Repudiation (denial) by sender (S) publ. key encr. 124

© 2006 -2007 by Leszek T. Lilien Security for e-mail (2) n Section 5 – Computer Security and Information Assurance § Secure e-mail requirements: n Msg confidentiality (protection from disclosure) n Msg integrity (protection from modification) n Sender authentication n Non-repudiation (preventing denial by sender) Not every msg requires all 4 capabilities but all 4 needed to cover requirements of all kinds of msgs 125

© 2006 -2007 by Leszek T. Lilien c. Design of PEM (1) n n n Section 5 – Computer Security and Information Assurance Standard for encrypted e-mail: n Privacy-enhanced Electronic Mail (PEM) n [Bishop-CS-A&S, p. 286] Developed by Internet Society (1985 -1993) A design goal: n Allowing PEM msgs travel as ordinary mail msgs n For legacy reasons n Protection occurs within msg body We’ll look in turn at: 1) Confidentiality in PEM 2) Other security features in PEM 126

© 2006 -2007 by Leszek T. Lilien Design of PEM (2) 1) Confidentiality in PEM n Scenario: S sends msg M to R (using PEM) n S picks random symm. encr. key K (corr. to session key) n S creates new cleartext header [a] n S encrypts K with KPUB-R: E(K, KPUB-R) [b] n Additionally, unprintable characters are converted into „regular” characters Section 5 – Computer Security and Information Assurance n n Since unprintable characters used as control signals by e-mail handlers S encrypts M with K: E(M, K) [c] n Entire M, with original header is encrypted => Summarizing, „enveloping” msg sent by S to R is: [a] = new „external” header (plaintext) [b] = encrypted symm. key K [c] = encrypted msg M (cf. Fig. 7 -44, p. 475) 127

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien ---SKIP--- Design of PEM (3) n Example of subfields within field [b]: (M = original msg) n Proc-Type: indicates applied privacy-enhancement services (e. g. , „ENCRYPTED”) n DEK-Info: (DEK=data encipherment key, corr. to session key) includes symmetric key K (used to encr. M) AND indicates kind of corresponding symmetric key encr. alg. (e. g. , DES-CBC) Actually not just K but whole field [b] (including K) is encrypted under KPUB-R, that is, E([b], KPUB-R ) n Variant of PEM standard: n Using only symmetric key encryption n Requires establishing common secret before sending e-mail 128

© 2006 -2007 by Leszek T. Lilien --SKIP-- Design of PEM (4) 2) Other security features in PEM msgs always carry a digital signature in [b] n Provide S’s authentication & non-repudiation n Hash within digital signature assures msg integrity n S can be anonymous in external header [a] n S’s identity encrypted in [c] Section 5 – Computer Security and Information Assurance n n Multiple encryption algorithms are supported by PEM „Unenhanced” & and PEM msgs can be mixed by sender at will 129

© 2006 -2007 by Leszek T. Lilien Design of PEM (5) n Problems with PEM n Problem 1: key mgmt (as always with public key exchange) n Solution 1 a: Using certificate scheme n Solution 1 b: Using PGP (to be discussed next) Section 5 – Computer Security and Information Assurance n Problem 2: endpoint vulnerability (S and R ends) n Attacker penetrating S’s or R’s host can subvert PEM code or install Trojan for leaking keys 130

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien --SKIP-- d. Example secure e-mail systems § § (1) Many encrypted e-mail systems exist (both academic and commercial) Two popular encrypted e-mail systems: i. PGP (Pretty Good Privacy) ii. S/MIME 131

© 2006 -2007 by Leszek T. Lilien --SKIP-- Example secure e-mail systems (2) i. PGP (Pretty Good Privacy) n Widely used, de facto secure email standard n Available on most operating systems n Originally free n Commercial versions available n Confidentiality — IDEA encryption (IDEA = International Data Encryption Algorithm; popular in Europe) Section 5 – Computer Security and Information Assurance n Integrity – RSA-encrypted MIC (Message Integrity Check/hash, MD 5) n n Authentication & non-repudiation – RSA-encrypted MIC Uses common key distribution channels n Trusted „introducers” used to validate keys n No CA (certification authority) hierarchy needed 132

© 2006 -2007 by Leszek T. Lilien Example secure e-mail systems (3) n PGP in practice n The application must be integrated into existing email n Each user exchanging keys with all potential recipients n Establishing a keyring - a ring of trusted recipients n User’s keyring of known keys n Containing public and private keys (protected by a Section 5 – Computer Security and Information Assurance password) Public keys given to you directly by a friend n Public keys signed by trusted introducers Keys used for signing or encrypting messages to be sent and validate messages received n n 133

Section 5 – Computer Security and Information Assurance © 2006 -2007 by Leszek T. Lilien --SKIP-- Example secure e-mail systems (4) ii. S/MIME n Internet standard for secure e-mail attachments n Very much like PGP n Principal difference: method of key exchange n PGP: user exchanging keys with all potential recipients n Establishing ring of trusted recipients n S/MIME: uses hierarchically validated certificates for key exchange n Usually in X. 509 format => S and R do not have to exchange keys in advance if have a common trusted certifier n Supports many ciphers, incl. DES, AES, RC 2 n Integrated into many commercial e-mail packages => likely to dominate the secure e-mail market 134

The End of Section 5 (Ch. 7 - Part 2): Network Security (incl. OPTIONAL details that you may SKIP)