cs 5950/6030 network security class 32 (m, 11/14/05) leszek lilien department of computer science...
Post on 19-Dec-2015
215 views
TRANSCRIPT
CS 5950/6030 Network SecurityClass 32 (M, 11/14/05)
Leszek LilienDepartment of Computer Science
Western Michigan University
Based on Security in Computing. Third Edition by Pfleeger and Pfleeger.Using some slides (as indicated) courtesy of:Prof. Aaron Striegel — at U. of Notre Dame
Prof. Barbara Endicott-Popovsky and Prof. Deborah Frincke — at U. WashingtonProf. Jussipekka Leiwo — at Vrije Universiteit (Free U.), Amsterdam, The
Netherlands
Slides not created by the above authors are © by Leszek T. Lilien, 2005Requests to use original slides for non-profit purposes will be gladly granted upon a written
request.
2
7. Security in Networks...
7.2. Threats in Networks...
7.3. Networks Security Controls...
c) Encryptioni. Link encryption vs. end-to-end (e2e) encryptionii. Virtual private network (VPN)iii. PKI and certificates—PART 1
iii. PKI and certificates—PART 2iv. SSH protocolv. SSL protocol (a.k.a. TLS protocol)vi. IPsec protocol suite—PART 1
Class 31
© by Leszek T. Lilien, 2005
3
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
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
Determining expiration dates for certificates Revoking certificates when necessary
By publishing revocation lists© by Leszek T. Lilien, 2005
4
iv. SSH protocol (SSH = Secure SHell)
SSH protocol v.1 and 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 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?© by Leszek T. Lilien, 2005
5
v. SSL protocol (a.k.a. TLS prot.) (1) SSL protocol (v3) = 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 a session between C and S
SSL = Secure Sockets Layer / TLS = Transport Layer Security Originally defined by Netscape to protect browser-to-
server communication Simple but effective – most widely used secure
commu-nication protocol on Internet (incl. WWW browsers/servers)
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?
© by Leszek T. Lilien, 2005
6
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
© by Leszek T. Lilien, 2005
7
IPsec protocol suite (4)
Security parameter index (SPI) data structure 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 / protocols1) AH = authentication header / AH protocol
For authentication-only IPsec service: Authenticates S (sender )
2) ESP = encapsulated security payload / ESP protocol
For encryption-only IPsec serviceOR For combined encryption/authentication
IPsec service© by Leszek T. Lilien, 2005
8
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© by Leszek T. Lilien, 2005
9
End of Class 31
© by Leszek T. Lilien, 2005
10
7. Security in Networks...
7.2. Threats in Networks...
7.3. Networks Security Controls...
c) Encryptioni. Link encryption vs. end-to-end (e2e) encryptionii. Virtual private network (VPN)iii. PKI and certificates—PART 1
iii. PKI and certificates—PART 2iv. SSH protocolv. SSL protocol (a.k.a. TLS protocol)vi. IPsec protocol suite—PART 1
vi. IPsec protocol suite—PART 2iii. Signed codeiv. Encrypted e-mail
d) Message content integrity controlsi. Error correcting codesii. Cryptographic checksum
e) Strong authenticationi. One-time passwordsii. Challenge-response systemsiii. Digital distributed authenticationiv. Kerberos
Class 31
© by Leszek T. Lilien, 2005
Class 32
11
[---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 Layer4) 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 field6) OPTIONAL: Authentication Data (unencrypted) –
authenticates all above fields
© by Leszek T. Lilien, 2005
12
IPsec protocol suite (7) ISAKMP (Internet Security Association Key
Management Protocol) = key mgmt protocol for IPsec Key mgmt is always a critical element in crypto apps
ISAKMP is simple, flexible, scalable Distinct key for each IPsec security association (SA)
In IPsec, ISAKMP implemented via IKE (ISAKMP Key Exchange)
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
© by Leszek T. Lilien, 2005
13
[---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 Actual calculation is mod(n) — a bit more complex
X and Y exchange identities & certificates 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
© by Leszek T. Lilien, 2005
14
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
© by Leszek T. Lilien, 2005
15
[---SKIP---] viii. Encrypted e-mail E-mail msgs – like a postard that everybody who
handles it between S and R can readPeople 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
© by Leszek T. Lilien, 2005
16
[---SKIP---] e) Msg content integrity controls (1)
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 integrity1) Malicious modification that changes content
in a meaningful way2) Nonmalicious modification that changes content
in a way that is not necessarily meaningful 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
© by Leszek T. Lilien, 2005
EASIERTO PREVENTOR DETECT
17
[---SKIP---] Msg content integrity controls (2)
Msg content integrity controls #1: DETECTError 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
Does not matter whether accidentally „meaningful” or not Can also stop some malicious attacks
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
© by Leszek T. Lilien, 2005
18
[---SKIP---] Msg content integrity controls (3)
[OPTIONAL] Msg content integrity controls #2: PREVENT or DETECTCryptographic checksum / msg digest / hash
To prevent or malicious attacks on data — As discussed before („Intro to Cryptology” section)
Can also detect malicious errorsCan also detect nonmalicious errors
Note that attacker can modify: Modify only data bits Modify error prevention/detection mechanism
© by Leszek T. Lilien, 2005
19
f) Strong authentication Networked environments as well as both ends of
communication need authentication
Strong authentication controls include:i. One-time passwordsii. Challenge-response systemsiii. Digital distributed authenticationiv. Kerberos authentication system
© by Leszek T. Lilien, 2005
20
[---SKIP---] i. 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 listOR User has password token (PT)
= device to randomly generate new pwd (e.g.) every minuteE.g., SecureID device from Security Dynamics – random # every minute © by Leszek T. Lilien, 2005
21
[---SKIP---] One-time passwords (2)
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 OTP1) 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
© by Leszek T. Lilien, 2005
22
[---SKIP---] ii. Challenge-response systems
Challenge-response systems solve OTP problems1) 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
© by Leszek T. Lilien, 2005
23
[---SKIP---] iii. Digital distributed authentication (1)
„Digital” from „Digital Equipment Corporation” (DEC) Once a powerful computer company
Acquired (1998) by Compaq, which subsequently merged with Hewlett-Packard (2002)
As of 2004 their product lines were still produced under HP name
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
© by Leszek T. Lilien, 2005
[Wikipedia]
24
[---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© by Leszek T. Lilien, 2005
25
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+)
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)
© by Leszek T. Lilien, 2005
26
Kerberos authentication system (2) User’s Step 1: Establishing session w/ Kerberos — Fig. 7-
30, p. 448 U’s workstat’n sends U’s identity to Kerberos server
(KS) KS verifies that U is authorized KS sends 2 msgs:
1) Msg to U, which contains: E(ST-GS + TT-GS , pwd) ST-GS — U’s session key for session with T-GS 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)
2) Msg to T-GS, which contains: ST-GS and U’s identity (encrypted under key shared by KS and T-GS) ST-GS — T-GS’s session key for session with U (same
as U’s session key for session with T-GS)
If U’s workstation can decrypt E(ST-GS + TT-GS , pwd) using its pwd, then U’s authentication succeeds
© by Leszek T. Lilien, 2005
U
U
U
U
U U
U U
27
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:
E(„request R for U’s ticket for accessing F” , ST-GS)
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...© by Leszek T. Lilien, 2005
U
U
28
Kerberos authentication system (4)...continued...
If verified OK, T-GS returns to U message encrypted under ST-GS, which contains:
1) U’s session key for session with F (really: with F’s file 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’s authenticated identity (T-GS knows that ST-
GS is U’s key —and nobody else’s— because KS sent to T-GS 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 = SF
(same as U’s session key for session with F) Ticket expiration date
© by Leszek T. Lilien, 2005
U
U
U
U
U
29
Kerberos authentication system (5)
Strenghts of Kerberos system No pwds communicated over network (sent only
once by user to Kerberos server & sent outside the network, e.g., in letter)
Crypto protection against spoofing (each access request mediated by T-GS, which knows requester’s identity; this identity known based on authentication performed initiallly by Kerb. server)
Limited period of ticket validity (disables some long-term attacks—e.g., brute force cryptanalysis)
Prevents replay attacks (each user’s request stamped with time of request; unreasonably old requests rejected by request servers)
Mutual authentication (user can be assured of server’s authenticity by requesting server’s authenticating response)
© by Leszek T. Lilien, 2005
30
Kerberos authentication system (6)
Weaknesses of Kerberos system Requires continuous availability of trusted ticket-
granting server (T-GS) Server S’ authenticity requires trust between T-GS
& S Requires timely transactions (too quick ticket
expiration will result in rejecting legitimate requests) Subverted workstation can replay user pwds Pwd guessing works (attacker can send initial —Step 1—
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)
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)
© by Leszek T. Lilien, 2005
31
End of Class 32
© by Leszek T. Lilien, 2005