Transcript Security in Networks - Part 2 - Computer Science

CS 5950/6030 –
Computer Security and Information Assurance
Section 7/2: Security in Networks – Part 2
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.
Security in Networks – Part 1 – Outline (1)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
SKIPPING two textbook chapters:
5. Designing Trusted OSs (not covered)
6. Database Security (maybe covered later)
7. Security in Networks
7.1. Network Concepts
a) Introduction
b) The network
c) Media
d) Protocols
e) Types of networks
f) Topologies
g) Distributed systems
h) APIs
i) Advantages of computing networks
7.2. Threats in Networks
a) Introduction
b) Network vulnerabilities
c) Who attacks networks?
d) Threat precursors
e) Threats in transit: eavesdropping and wiretapping
f) Protocol flaws
2
Security in Networks – Part 1 – Outline (2)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
7.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
Security in Networks – Part 2 – Outline (1)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
7.3. Network Security Controls
a) Introduction
b) Security threat analysis
c) Impact of network architecture/design and implementation on
security
d) Encryption
i. Link encryption vs. end-to-end (e2e) 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
e) Message content integrity controls
i. Error correcting codes
ii. Cryptographic checksum
f) Strong authentication
i. One-time passwords
ii. Challenge-response systems
iii. Digital distributed authentication
iv. Kerberos authentication system
4
Security in Networks – Part 2 – Outline (2)
7.3. Network Security Controls—ctd.
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
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
7.4. Network Security Tools
7.4.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
Security in Networks – Part 2 – Outline (3)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
7.4. Network Security Tools—ctd.
7.4.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
7.4.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
7.3. Networks Security Controls
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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
7
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
a. Introduction

We have seen many security controls:
 In Section on Program Security (incl. s/w engineering
issues)
 In Section on OS Security

Many of these strategies are useful for network security
8
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
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

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)
9
Security threat analysis (2)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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




Attack enablers:
 Size / anonymity / ignorance / misunderstanding
 Complexity / motivation / programming skills
10
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
c. Impact of network architecture/
design & implement. on security (1)


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
11
Impact of network architecture/ design & implement. on security (2)
1)
Segmentation
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


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
12
Impact of network architecture/ design & implement. on security (3)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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
13
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
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

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
14
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
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

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
15
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
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
16
d. Encryption
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Arguably most important/versatile tool for network security

We have seen that it can be used for:
 Confidentiality/Privacy
 Authentication
 Integrity
 Limiting data access

Kinds of encryption in networks:
i. Link encryption vs. end-to-end (e2e) 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
17
(i) Link vs. end-to-end encryption (1)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
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)


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
18
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
Link vs. end-to-end encryption (2)

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)

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)
19
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
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 e2e 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
20
Link vs. end-to-end encryption (4)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

E2e encryption is visible either to users or their apps
 Encryption service provided by app or OS
Possibly provided only upon explicit user’s request => visible to
user


Encryption by s/w
Message under e2e 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)
E2e encryption is useful when transmission lines and
intemediate hosts are insecure
21
Link vs. end-to-end encryption (5)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Comparison of link vs. e2e encryption
 Encryption of msgs/packets (whether link or e2e
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

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
22
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
Link vs. end-to-end encryption (6)
2) End-to-end (e2e) 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



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)
23
Link vs. end-to-end encryption (7)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Comparison conclusions
 Link encryption:
 Faster
 Easier to use
 Uses fewer keys (1 K pair per host pair vs. 1 K pair per app pair)


End-to-end (e2e) encryption:
 More flexible
 More selective (can select only some msgs for encryption)
 User-level, can be integrated with app
Optimize whether link or e2e encryption better for you
If needed for higher security, use link and e2e encryption
together
 E.g., user not trusting network link encryption can use
app with e2e encryption
24
(ii) Virtual private network (VPN) (1)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


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 e2e 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)
Firewall
Internal
Server
Physically Protected Network Perimeter

Firewall protects network against external traffic (more later)
25
Virtual private network (VPN) (2)

1
© by Leszek T. Lilien, 2006
Section 8 – Computer Security and Information Assurance – Spring 2006
Example VPN connection scenario
User’s
Workstation
(Client)
2
3
Firewall
Internal
Server
Physically Protected Network Perimeter
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
26
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
(iii) PKI and certificates (1)

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


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
27
PKI and certificates (2)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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
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
28
PKI and certificates (3)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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


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
29
PKI and certificates (4)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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


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
30
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
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


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
31
PKI and certificates (6)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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 X9.45, Simple Public Key
Infrastructure (SPKI)
32
PKI and certificates (7)

PKI is not yet mature
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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., 2FA or 3FA with smart cards)
33
(iv) SSH protocol
SSH protocol (newer: v.2) – provides authenticated and
encrypted communication with shell/OS command
interpreter
© by Leszek T. Lilien, 2006

Section 8 – Computer Security and Information Assurance – Spring 2006
(SSH = Secure SHell)

Originally defined for Unix
Replaced insecure utilities for remote access


Such as Telnet / rlogin / rsh
Protects against spoofing attacks (falsifying one end of

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?
34
(v) SSL protocol (a.k.a. TLS prot.) (1)
SSL protocol (v3) = (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
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

SSL = Secure Sockets Layer / TLS = Transport Layer Security

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? RC4 w/ 128-bit/40-bit key? RC2? Fortezza? [Bishop]
Negotiate which hashing technique to use for session
E.g., SHA1 or MD5?
35
SSL protocol (a.k.a. TLS protocol) (2)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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

Hash used to checksum messages
S responds with msgs including: Hello-S, Rand-S,
cipher & hash algorithm selected by S (from C’s list) , S’s
certificate, KPUB-S, [OPTIONAL: request for cert. fr. C]


C can use S’s certificate
(X.509v3 cert.)
to verify S’s authenticity
[OPTIONAL: 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 [BishopCompSec-A&S, p.296]
...continued...
36
SSL protocol (a.k.a. TLS protocol) (3)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
...continued...
C and S calculate „master secret” using:





„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

(i.e., for as long as they stay connected)
[Conklin eta al., p.163]
37
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
(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)

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
38
IPsec protocol suite (2)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

IPsec provides security at IP layer in IPv6 or IPv4[Stall.p.499]
 IP versions:
 IPv4 = v.4 — older IP protocol version (still in use)
 IPv6 = v.6 — newer IP protocol version
 IPv6 — larger address space

IPv6 — also other functional enhancements




Developed (1992-1998) since IPv4 runs out of address space
— IPv4 has 32-bit source/destination addresses
— IPv6 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)
39
IPsec protocol suite (3)
Basis of IPsec: security association (SA) = set of security
parameters for a secured 1-way communication channel
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006



2 SAs needed for 2-way communication [St,487]
Components of SA:
1) Encryption algorithm and „mode”

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)
40
IPsec protocol suite (4)
Security parameter index (SPI) data structure

© by Leszek T. Lilien, 2006
Section 8 – Computer Security and Information Assurance – Spring 2006
Resides on each host H running IPsec
Used to select 1 of n SAs that exist on H




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
41
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
IPsec protocol suite (5)

IPsec can be used for various crypto sessions:
 VPN
 e2e (incl. app 2 app)
 For network mgmt (e.g., for routing)

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
42
[---SKIP---] IPsec protocol suite (6)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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) OPTIONAL: Authentication Data (unencrypted) –
authenticates all above fields
43
IPsec protocol suite (7)
ISAKMP (Internet Security Association Key Management
Protocol) = key mgmt protocol for IPsec
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


ISAKMP is simple, flexible, scalable
Distinct key for each IPsec security association (SA)


In IPsec, ISAKMP implemented via IKE (ISAKMP Key
Exchange)


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 DiffieHellman scheme
44
[---SKIP---] IPsec protocol suite (8)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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




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
45
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
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

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
46
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
[---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

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
47
e) Msg content integrity
controls (1)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
[---SKIP---]
Content integrity verification provided „for free” with
encryption


Since can’t perform meaningful data modification w/o decrypting it
But attacker can modify encrypted data to make it useless



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
48
[---SKIP---]
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Msg content integrity controls (2)
Msg content integrity controls #1: DETECT
Error detection and error correction codes
 As discussed before („Intro to Cryptology” section)



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
49
[---SKIP---]
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


Msg content integrity controls (3)
[OPTIONAL] 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
50
f) Strong authentication
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


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
51
[---SKIP---] i.
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

One-time passwords (1)
One-time password (OTP) method
 Controls wiretapping and spoofing



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., SecureID device from Security Dynamics – random # every
minute
52
[---SKIP---] One-time passwords (2)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


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
53
[---SKIP---] ii.
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
systems

Challenge-response
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”
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
54
iii. Digital distributed
authentication (1)
[---SKIP---]
© by Leszek T. Lilien, 2006
Section 8 – Computer Security and Information Assurance – Spring 2006
„Digital” from „Digital Equipment Corporation” (DEC)


In 1980s 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
Once a powerful computer company



Acquired (1998) by Compaq, which subsequently merged with HewlettPackard (2002)
[Wikipedia]
As of 2004 their product lines were still produced under HP name
55
[---SKIP---]
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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
56
iv. Kerberos authentication system (1)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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+)

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)
57
Kerberos authentication system (2)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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)


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
T
+ T-GS , pwd) using
its pwd, then U’s authentication succeeds
58
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
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...
59
Kerberos authentication system (4)
...continued...
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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 is
 U’s authenticated identity (T-GS knows that ST-GS
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)
 F’s session key for F’s session with U = SFU (same
as U’s session key for session with F)
 Ticket expiration date
60
Kerberos authentication system (5)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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
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
61
Kerberos authentication system (6)

Strengths of Kerberos – cont.1
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
3) Limits period of ticket validity (this disables some long-term
attacks—e.g., brute force cryptanalysis)


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
62
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
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
6) Uses public key technology for key exchange
63
Kerberos authentication system (8)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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)
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)
64
g) Access controls (1)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


Before user is allowed access to network resources, must
know:

Who needs access => authentication

What and how will be accessed => access controls
Access controls include:
1) ACLs (Access Control Lists) on router
2) Firewalls
65
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
Access controls (2)
1) ACLs on routers (ACL = Access Control List)

Router directs traffic:

To subnetworks it controls
OR

To other routers (for delivery to other subnetworks)

Routers convert external (network-wide)IP address to
internal (subnetwork-wide) MAC address



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

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

Use sparingly: only for specific & known threats
BUT...
66
Access controls (3)
© by Leszek T. Lilien, 2006

... Problems with putting too many ACLs on routers:
(i) Packet-checking overhead for router

Router must check each packet against each ACL –
a lot of work
=> degraded performance

Section 8 – Computer Security and Information Assurance – Spring 2006

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

To be able to detect spam, router must log source
addresses of packets


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
67
Access controls (4)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

... Problems with putting too many ACLs on routers-CONT.
(iii) Inability of router to detect all spams

Because source addresses in datagrams (UDP
packets) can be easily forged (by attacker using UDP
protocol)

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
68
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
Access controls (5)
2) Firewalls

Designed to do screening that routers can’t do efficiently

Because routers designed for routing (of course!)

Firewalls designed for access filtering
AND auditing
AND examining whole packets (not only source/destination
IP/ MAC addresses—which is what routers do)

Firewalls will be discussed in detail later (but very soon)
69
h) Intrusion Detection Systems: alarms & alerts
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Example of 2-layer network protection

Provided by router (Layer 1) AND firewall (Layer 2)

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


OR



Can detect that attack has already occurred & raise alarm,
starting system recovery actions
IDS is a.k.a. IPS = intrusion protection system


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
70
i) Honeypots
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Honeypot – system built as a bait attracting attackers

Once attackers take the bait:

They are observed to learn how they behave/operate


They are traced to catch them or scare them off


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


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
71
j) Traffic flow security (1)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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)

Example 1: Inference that traffic between Thinges Corp. and
bankruptcy lawyer precedes declaration of bankruptcy by Thinges

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)
72
Traffic flow security (2)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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 toZ
 W wraps packet to Y into packet addressed to X,
which asks X to send it to Y
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
73
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
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


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
74
k) Review of network security controls
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


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)


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
75
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
7.4. Network Security Tools
[Fig: B. Endicott-Popovsky]

Network security tools
7.4.1. Firewalls
7.4.2. Intrusion Detection Systems
7.4.3. Secure E-Mail
76
7.4.1. Firewalls
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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
77
--[OPTIONAL]--
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

a. Introduction
Firewalls

Invented in the early 1990’s

But idea related to reference monitors from 1970’s

What is reference monitor?

OS includes kernel / core / nucleous – responsible for lowestlevel functions

Incl. synchronization, inter-process communication,
msg passing, interrupt handling

Security kernel – provides security mechanisms for entire OS

Incl. security interfaces among h/w, OS, other parts of
computing system

Typically, security kernel is a part of OS kernel

Reference monitor is portion of security kernel that controls
access to objects (controls „references” to objects)
78
b. What is a firewall (1)
Firewall = device (h/w), or software, or combination of both
designed to prevent unauthorized users from accessing
network and/or single workstation
© by Leszek T. Lilien, 2006

Wall between protected local (sub)net & outside global net
Section 8 – Computer Security and Information Assurance – Spring 2006



Inspect each individual inbound or outbound packet of
data sent to / from protected system
Check if it should be blocked or allowed to enter
Firewalls keep „bad things” out, keep sensitive info in

Security policy specifies what are „bad things”



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
79
What is a firewall (2)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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


E.g., prevent outside access to subnet hosts except for mail
server accesses
Choice of default firewall behavior
1) Default permit

„That which is not expressly forbidden is allowed”
2) Default deny


„That which is not expressly allowed is forbidden”
Users prefer default permit, security experts prefer
default deny

Sysadmin must make the choice
80
c. Firewall design (1)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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)



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
81
--[OPTIONAL]-- Firewall design (2)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

General firewall techniques:
1) Service control

Type of service: inbound or outbound
2) Traffic filtering — based on IP address & TCP port nr

Provide proxy software to receive or interpret service
request before passing it on

Could also host server software (e.g. Web or mail service)

Not recommended

Complicates it (more code => more vulnerabilities)
3) User Control

Control access to service using ACLs
4) Behavior Control

E.g. filter e-mail for spam
82
--[OPTIONAL]-- Firewall design (3)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Basic firewall characteristics

All traffic (incoming / outgoing) must pass thru firewall

Only authorized traffic allowed to pass

Firewall itself must be immune to penetration


I.e. must use trusted system w/ secure OS (min. size/complexity)
Usually implemented on dedicated device



Dedicated = only firewall functions performed on this device
Firewall code must be very well protected
Basic kinds of firewalls:

Hardware firewalls

More common

Implemented on router level

More expensive / more difficult to configure

Software firewalls

Used in single workstations

Less expensive / Easier to configure
83
d. Types of firewalls (1)
Types of firewalls
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

i.
Packet filters / packet filtering firewalls
(i-1) Simple packet filters / (simple) packet filtering gateways
/ screening routers
(i-2) Stateful packet filters / stateful inspection firewalls
ii.
Application proxies
/ proxy firewalls / application-level
gateways
(ii-1) Guards (a special case of app proxies)
iii. Personal firewalls
84
Types of firewalls (2)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Firewall properties:

Packet filter properties:

Transparent

Does not change traffic, only passes it

Proxy properties:

Active

Intercepts traffic & acts as an intermediary
Different firewall types needed for different needs



„Different strokes for different floks” — e.g.:
Simple packet filters / screening routers – implement simplistic
security policies

Simple is best if sufficient to counter exisiting threats well
App proxies – much richer capabilities
85
--[OPTIONAL]-- Types of firewalls (3)
Firewall is a type of host
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Even some routers are host-based
To have better tools available (editors, programming tools)


Programmable
Minimal functionality

Reduces vulnerabilities


Small = > less complex => fewer vulnerabilities
Reduces motivation for attacks

No password files to steal, etc.
86
(i) Packet filters (1)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


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

Filtering based on both source/destination addresses
2) Port number determines TCP transport protocol type



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


See only IP address ‘ transport protocol type
E.g., can not allow only some Telnet commands OR exclude only
some other Telnet commands
87
--[OPTIONAL]-- (i) Packet filters (2)

1a) Packet address filtering (cf. Fig. 7-35, p. 459)
Can block traffic from specific subnets and/or allow traffic from
specific subnets
1b) 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)
© by Leszek T. Lilien, 2006
Section 8 – Computer Security and Information Assurance – Spring 2006
Examples of packet filtering – see text

To avoid overburdening router, firewall can run on device
behind router (on subnet side)
88
(i-1) Simple packet filters (1)
Simple packet filters / (simple) packet filtering gateways /
screening routers — simplest firewall type
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


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


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?

TCP pkts arrive in order different than sending order
=> remembering ≤ N last pkts is not enough
89
--[OPTIONAL]-- (i-1) Simple packet filters (2)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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
 Pattern of attack is completely invisible in any
single short pkt


=> 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
90
--[OPTIONAL]-- (i-1) Simple packet filters (3)
© by Leszek T. Lilien, 2006

One very important task for simple packet filtering
gateways: Validating inside IP addresses

Inside hosts trust more other inside host

Simple filtering assures that no external source can
masquerade as internal source
Section 8 – Computer Security and Information Assurance – Spring 2006

Blocks any packet coming from outside network that claims to
be sent by internal host

Cf. Fig. 7-37, p. 460
91
--[OPTIONAL]-- (i-1) Simple packet filters (4)
© by Leszek T. Lilien, 2006

Simplicity of inspection is both disadvantage & advantage

Disadvantage because of high granularity

E.g., can block all Telnet coomands, but can not block
only selected telnet commands

Advantage beacuse reduces complexity
Section 8 – Computer Security and Information Assurance – Spring 2006

Filtering rules to block, e.g., only selected Telnet traffic would
have to be much more detailed
=> more complex
=> more vulnerable
92
(i-2) Stateful packet filters
Stateful packet filters — a.k.a. stateful inspection firewalls
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


Keep state/history/context of  N previously seen pkts
=> stateful packet filters have memory


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)
93
(ii) Application proxies (1)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Application proxies / proxy firewalls / application-level
gateways / application proxy gateways
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].


Application proxies include — as a special case
(ii-1) Guards
App proxy firewalls fix basic problem with packet filtering
firewalls because they:

See all pkt data (not just IP adresses and port #s)

(In addition, they are stateful => can analyze multiple pkts)
=> can detect/derail more sophisticated attacks

Can filter out harmful commands in pkt stream
94
--[OPTIONAL]-- (ii) Application proxies (2)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

For example, app proxies can prevent:

Use of back door open to pkts inbound to SMTP port
(Port 25)

Flawed application run by user U (e.g., an e-mail agent) has
all U’s privileges => can cause damage
95
(ii) Application proxies (3)
Act as mediators/censors (!) of app-level traffic – like
benevolent „woman-in-the middle”  (not an official term!)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006




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]

Extern. user U tries to Telnet to host H protected by G

G intercepts U’s packets

G acts as H would: asks U for id+pwd

U replies w/ id+pwd

G logs in into H on behalf of U

G relays H’s msgs to U

Etc., etc.
96
--[OPTIONAL]-- (ii) Application proxies (4)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006



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

Unsupported features are considered too risky
=> not available
97
--[OPTIONAL]-- (ii) Application proxies (5)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

App proxies provide higher level of security than packet
filters (PFs)

PFs try to deal with all potentially deployable applications
that could use TCP/IP (default permit philosophy)

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.

transport level for PFs)

Prime disadvantage of app proxies: Processing overhead for
each app-level connection

1 connection split into 2 logical connections


With “woman-in-the-middle” 
Circuit-level gateways (another proxy subcategory) splits
1 TCP connection into 2 TCP connections
98
(ii) Application proxies (6)
(ii-1) Guards = most sophisticated category of app proxies (“top
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
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
--------[OPTIONAL]------->

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
99
(iii) Personal firewalls
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Regular firewalls protects subnetworks
Personal firewalls protect single hosts

For small business / home office / home

Can be used to complement conventional firewall

Next line of defense

Customized to user(s) of particular host

Firewall capabilities at a lower price
Personal firewall is application program


Products include: Norton Personal Firewall (Symantec), McAfee
Personal Firewall, Zone Alarm (Zone Labs)
Personal firewall also enforces certain security policy



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
100
--[OPTIONAL]--
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
types

e. Comparison of firewall
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
101
f. Example firewall configurations
Example firewall configurations
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


Subnet with screening router (simple packet filtering)
— Fig. 7-39, p. 466

Subnet with proxy gateway (app proxy)
— Fig. 7-40, p. 467

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)
102
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
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
103
7.4.2. Intrusion Detection Systems
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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
104
a. Introduction (1)
It is better to prevent attack than to detect it after it
succeeds
Unfortunately, not all attacks can be prevented
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006




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
computer) monitoring system activities to detect malicious /

suspicious events
IDSs attempt to detect

Outsiders breaking into a system
OR

Insiders (legitimate users) performing illegitimate
actions

Accidentally OR deliberately
105
Introduction (2)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

IDS runs constantly in the background

Alarms when it detects something suspicious
We’ll be talking only about real-time IDSs



Ignoring off-line IDSs (early IDSs reviewed logs after th fact)
IDS should operate in stealth mode — be invisible to
outside world

IDS interfaces (cf. Fig. 7-43, p.471)
1) Alarm interface through which raises alarm

On a completely separate control network
2) Monitoring interface to protected (sub)network

Never sends msgs on this interface!

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
106
Introduction (3)
© by Leszek T. Lilien, 2006

IDS terminology

Anomaly — abnormal behavior

Misuse
— activity that violates the security policy
(subset of “anomaly”)

Section 8 – Computer Security and Information Assurance – Spring 2006


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
107
---[OPTIONAL]--- Introduction (4)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Superset of IDS functions

Monitoring users and system activity

Auditing system configuration for vulnerabilities &
misconfigurations

Assessing integrity of critical system and app files

Recognizing known attack patterns

Identifying abnormal activities through statistical
analysis

Managing audit trails (logs) and highlighting misuses or
anomalies in user activities

Correcting system config errors

Installing & operating traps (honeypots) to learn about
intruders
108
b. Types of IDSs (1)
IDS types w.r.t. scope:

Host-based

Runs on a host

Monitors activities on this host only

Network-based

Stand–alone device

Monitors entire (sub)network

IDS types w.r.t. operation
i. Signature-based IDSs
ii. Anomaly-based IDSs (heuristic IDSs)
(ii-1) Misuse intrusion detection
iii. Other IDS types
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

109
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
Types of IDSs (2)
i. Signature-based IDS

Looks for unacceptable system activities (attack)

Each known attack characterized by its „signature”
(pattern)

To detect attack, matches current activities to known
attack signatures

Even attack with signature „similar” to signature of a
known attack can be detected

Example signature for port scan attack




Syn to port 80
Syn to port 25
Syn to port 161
...
110
Types of IDSs (3)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


Problems with signature-based IDSs
(1) Can not detect attack with unknown signature

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

When legitimate data accidentally match attack
signature
Solution to (1) and (2): anomaly-based IDSs
111
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
Types of IDSs (4)
ii. Anomaly-based IDS (heuristic IDS)

Uses model of acceptable user behavior



Recall that signature-based IDS uses models (signatures) of
unacceptable system activities (system behavior)
Watches user activities

Watches for deviations from model behavior
Raises alarm upon detection of suspicious behavior

If false alarm, admin can „teach” IDS to accept such
behavior in the future
112
Types of IDSs (5)
Example model of acceptable user’s behavior

Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006




Logs in
Reads e-mail
User word processor
...
Note:
Use of sensitive system management utilities
would be a deviation from the model of
acceptable user’s behavior
113
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
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)

Uses model of unacceptable user behavior


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)

Could misuse IDS be considered a variation of signaturebased IDS?
Example model of unacceptable user’s behavior




Attempt to copy pwd file
Attempt to open pwd file
...
114
Types of IDSs (7)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
iii.
Other IDSs

E.g., hybrid IDSs (combining signature- and anomalybased IDSs), immune-system-based IDSs

---[OPTIONAL]--- Under more liberal definiton of IDS,
the following are called IDSs:

Tripwire program — cf. p. 471




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
115
c. Goals for IDSs (1)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

IDS goals
1) Detect all attacks correctly

Avoid false positives (false alarms)

False alarms annoy sysadmins, users, ...
Avoid false negatives (not recognizing attacks)
2) Little overhead / performance impacts


Range of IDS alarms

Write a record to audit log
Urgency

...

Page security administrator
116
Goals for IDSs (2)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Categories of IDS responses
1) Monitor, collect data, collect more data

For attacks with modest impact

Invisible to attacker

Can be used to study attacker’s actions (like honeypot)
2) Protect, reduce exposure

E.g., making certain files unavailable to any access

May be very visible to attacker
3) Call a human

For attacks with highest impact potential

Calling a human preceded by some automatic actions


Since humans take very long time (compared to computer time)
to respond
Any combination of (1), (2) , (3) into single response is
possible
117
d. IDS strengths and limitations
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


IDS strengths
 Becoming more effective (e.g., DBs of attack signatures grow)
 Becoming cheaper
 Becoming easier to administer
IDS limitations

Attackers use avoidance strategies to avoid detection by
IDS

IDS sensitivity is difficult to measure and adjust


Must strike a balance false alarms and missing attacks
Only as good as the process/people using it
118
7.4.3. Secure E-Mail
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

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
119
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)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


Unencrypted message contents can be peeked at either in transit or
by privileged users at destination host
120
b. Security for e-mail (1)
Threats to e-mail
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Controls





Msg interception (confidentiality)
Msg interception (blocked delivery)
Msg interception+replay
Msg content modification
Msg origin modification
encryption
no S/R controls
encryption (+seq.nr)
encryption
encryption


Msg content forgery by outsider
Msg origin forgery by outsider
encryption
encryption


Msg content forgery by recipient (R)
Msg origin forgery by recipient
publ.key encr.
publ.key encr.

Repudiation (denial) by sender (S)
publ.key encr.
121
Security for e-mail (2)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


Secure e-mail requirements:

Msg confidentiality (protection from disclosure)

Msg integrity (protection from modification)

Sender authentication

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
122
c. Design of PEM (1)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Standard for encrypted e-mail

Privacy-enhanced Electronic Mail (PEM)



[Bishop-CS-A&S, p.286]
Developed by Internet Society (1985-1993)
One of design goals:

Allowing PEM msgs travel as ordinary mail msgs

For legacy reasons

Protection occurs within msg body
We’ll look in turn at:
1) Confidentiality in PEM
2) Other security features in PEM
123
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
Design of PEM (2)
1) Confidentiality in PEM

Scenario: S sends msg M to R (using PEM)

S picks random symm.encr. key K (corr. to session key)

S creates new cleartext header [a]

S encrypts K with KPUB-R: E(K, KPUB-R) [b]

Additionally, unprintable characters are converted into
„regular” characters


Since unprintable characters used as control signals by e-mail
handlers
S encrypts M with K: E(M, K) [c]

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)
124
---[OPTIONAL]--- Design of PEM (3)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Example of subfields within field [b]:
(M = original msg)

Proc-Type:
indicates applied privacy-enhancement services
(e.g., „ENCRYPTED”)

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 )

Variant of PEM standard:

Using only symmetric key encryption

Requires establishing common secret before sending e-mail
125
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
Design of PEM(4)
2) Other security features in PEM

PEM msgs always carry a digital signature in [b]

Provide S’s authentication & non-repudiation

Hash within digital signature assures msg integrity

S can be anonymous in external header [a]

S’s identity encrypted in [c]


Multiple encryption algorithms are supported by PEM
„Unenhanced” & and PEM msgs can be mixed by sender at
will
126
Design of PEM(5)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

Problems with PEM

Problem 1: key mgmt (as always with public key exchange)

Solution 1a: Using certificate scheme

Solution 1b: Using PGP (to be discussed next)

Problem 2: endpoint vulnerability (S and R ends)

Attacker penetrating S’s or R’s host can subvert PEM
code or install Trojan for leaking keys
127
d. Example secure e-mail systems (1)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006


Many encrypted e-mail systems exist (both academic and
commercial)
Two popular encrypted e-mail systems:
i. PGP (Pretty Good Privacy)
ii. S/MIME
128
Example secure e-mail systems (2)
© by Leszek T. Lilien, 2006
i.
PGP (Pretty Good Privacy)

Widely used, de facto secure email standard

Available on most operating systems

Originally free

Commercial versions available
Section 8 – Computer Security and Information Assurance – Spring 2006

Confidentiality — IDEA encryption (IDEA = International
Data Encryption Algorithm; popular in Europe)

Integrity – RSA-encrypted MIC (Message Integrity
Check/hash, MD5)


Authentication & non-repudiation – RSA-encrypted MIC
Uses common key distribution

Trusted „introducers” used to validate keys

No certification authority hierarchy needed
129
Example secure e-mail systems (3)
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006

PGP in practice

The application must be integrated into existing email

Each user has a keyring of known keys

Containing their own public and private keys
(protected by a password)

Public keys given to you directly by a person

Public keys signed by trusted introducers

Keys used for signing or encrypting messages to be
sent and validate messages received
130
Section 8 – Computer Security and Information Assurance – Spring 2006
© by Leszek T. Lilien, 2006
Example secure e-mail systems (4)
ii. S/MIME

Internet standard for secure e-mail attachments

Very much like PGP

Principal difference: method of key exchange

PGP: user exchanging keys with all potential
recipients

Establishing ring of trusted recipients

S/MIME: uses hierarchically validated certificates for
key exchange

Usually in X.509 format
=> S and R do not have to exchange keys in
advance if have a common trusted certifier

Supports many ciphers, incl. DES, AES, RC2

Integrated into many commercial e-mail packages
=> likely to dominate the secure e-mail market
131
End of Section 7 (and 7/2):
Network Security