Computer Networks Security
ReSIST NoE Courseware
Author: Paulo Veríssimo
Editor: Miguel Correia
Univ. of Lisboa Faculty of Sciences
Lisboa – Portugal
http://www.navigators.di.fc.ul.pt
© 2008 Paulo Veríssimo
1
Contents of the course
1. Fundamental Security Concepts
2. Paradigms for Secure Computing and
Communication
3. Models for Secure Computing
4. Secure Systems and Platforms
© 2008 Paulo Veríssimo
2
Fundamental Security Concepts
Chapter 1
© 2008 Paulo Veríssimo
3
Insecurity, People and Computers
• the causes of insecurity failure are faults (attacks)
maliciously made by hackers (humans)
• very often made possible by unintentional faults
(vulnerabilities) made by designers or operators (who
are also humans...)
• it is difficult to characterize this process accurately
(humans are largely unpredictable…)
© 2008 Paulo Veríssimo
4
Insecurity, People and Computers
• Insecurity is as concerned with technical deficiencies
as with people's attitudes
• Insecurity is quantitatively caused to a great extent
by the actions of people who must be educated about
the seriousness of their deeds
• It is better to invest than to spend
• Cryptocracy (a form of technocracy) is enemy of good
systems practice
© 2008 Paulo Veríssimo
5
A systematic view of system failure
sequence fault error failure
interaction
fault
error
Designer/
Operator
failure
design/
operation
fault
© 2008 Paulo Veríssimo
6
A systematic view of security failure
sequence Attack-Vulnerability-Intrusion
In
t
r
u
d
e
r
a
t
t
a
c
k
(
f
a
u
l
t
)
error
Intruder/
Designer/
Operator
vulnerability
(fault)
f
a
ilu
r
e
in
tru
sio
n
(fau
lt)
AVI sequence : attack + vulnerability intrusion  error  failure
© 2008 Paulo Veríssimo
7
What measures the risk of intrusion?
• RISK is a combined measure of the level of threat (of
attack) to which a computing or communication system
is exposed, and its degree of vulnerability:
RISK = VULNERABILITY X THREAT
• The correct measure of how potentially insecure a
system can be (in other words, of how hard it will be to
make it secure) depends:
– on the number and severity of the flaws of the system
(vulnerabilities)
– on the potential of threat it may be subjected to (attacks)
© 2008 Paulo Veríssimo
Security Properties
• Confidentiality
– the measure in which a service or piece of information is
protected from unauthorized disclosure
• Integrity
– the measure in which a service or piece of information is
protected from illegitimate and/or undetected modification
• Authenticity
– the measure in which a service or piece of information is
genuine, and thus protected from personification or forgery
• Availability
– the measure in which a service or piece of information is
protected from denial of authorized provision or access
© 2008 Paulo Veríssimo
9
Confidenciality
•
Objectives/Targets:
– protect private or critical computing and communication
services from the eyes of intruders
– different degrees (citizens, enterprises, government, military)
– privacy is default form of confidentiality
– problems faced: organized crime, national security may lead
govs into restricting rights to confidentiality legally
• Enforcing w.r.t. comunication:
•
– prevent listening: physical isolation, making tapping difficult
– in case not possible: making it unintelligible (cipher)
Enforcing w.r.t. information:
– prevent reading: physical isolation, disconnection
– in case not possible: making it unintelligible (cipher,
fragmentation)
© 2008 Paulo Veríssimo
10
Integrity
• Objectives/Targets:
•
– avoiding or detecting the modification of information or
messages, including service interactions, with malicious intent
– conversely, checking whether something is intact
Enforcing w.r.t. comunication:
– use some form of checksum with cryptographic resilience, to
detect modification of messages (unavoidable in transit)
– prevent undetected forgery of messages (implying violation of
authenticity)
• Enforcing w.r.t. information:
– likewise, detect modification of data in repositories
– prevention of modification, if we fear a radical attack trying
to erase our whole information system
– techniques vary for the latter: protection by access control;
fault tolerance by redundancy
© 2008 Paulo Veríssimo
11
Autenticity
• Objectives/Targets:
– guaranteeing the origin of a service request, the identity of
the creator of a piece of data or a message, or of a service
provider
– actions are attributed to the genuine origin (non-repudiation)
– problems faced: attempts at impersonation or forgery;
denying some action (“it wasn’t me!”); violation of authenticity
may lead to violation of confidentiality or integrity
– enforced by authentication
• Enforcing w.r.t. comunication:
•
– is the peer who it says it is?
– the sender cannot deny it sent
– the recipient cannot deny it received
Enforcing w.r.t. information:
– recognizing a creator's signature, even if he denies
© 2008 Paulo Veríssimo
12
Availability
• Objectives/Targets:
– ensuring that information and computing or communication
services remain accessible to authorized users, despite
malicious actions, called denial-of-service attacks
– problems faced: blocking of sensitive services of critical
infrastructures may happen in crisis situations (sabotage,
vandalism, terrorism and politics); there is a shallow boundary
with accidental overloads
• Enforcing w.r.t. comunication:
– prevent actions attempting at blocking comm’s or damaging
packets
– in case not possible: neutralize effect (redundancy or
reconfigur.)
• Enforcing w.r.t. information:
– prevent actions attempting at blocking servers
– in case not possible: neutralize effect (server/data
redundancy)
© 2008 Paulo Veríssimo
13
the source of our problems:
The track of a hacker
© 2008 Paulo Veríssimo
Motivations of hackers/phreakers
• curiosity;
• collecting trophies;
• free access to computational and communication
resources;
• bridging to other machines in a distributed system;
• damaging or sabotaging systems, for criminal,
mercenary or political reasons;
• stealing information for own use or for sale, such as
software, commercial or industrial secrets,
pedagogical information
© 2008 Paulo Veríssimo
Usual steps of a hacker
• Exploration of vulnerabilities
–
–
–
–
Finding weak points in the computer system e.g.,
accounts without password;
vulnerable configurations or drivers;
accessible password file
–
–
–
–
Making a plan of attack, e.g.,
matching dictionary words to password file entries;
attack system driver with malicious program to get an account;
eavesdrop on login/password pairs on the network
• Access to the system
• Control of the system
– Controlling all system resources, by becoming root user after
attacking the system's security mechanisms, e.g.
– with malicious programs like malicious script securing root
access;
– racing a penetration program against a legitimate system call
© 2008 Paulo Veríssimo
Usual steps of a hacker (contd.)
• Deletion of traces
– Concealing activity during intrusion campaign e.g.,
– disguising himself while logged in,
– erasing system logs after logout
• Continued stealth access
– Perpetuating access to the machine in a stealthy manner e.g.,
– Trojan horses or backdoor programs that can be activated by
special codes or sequences,
– abandoned or inactive accounts
• Exploration of new targets
–
–
–
–
Looking for new trophies e.g.,
channels leading to other machines;
access information in personal files;
eavesdropping from the intruded machine
© 2008 Paulo Veríssimo
© 2008 Paulo Veríssimo
18
Paradigms for
Secure
Computing and Communication
Chapter 2
© 2008 Paulo Veríssimo
19
TCB
Trusted Computing Base
© 2008 Paulo Veríssimo
20
TCB - Trusted Computing Base
• subset or module of a system that is assumed to be
inherently secure (immune to intrusions)
• a TCB normally serves to host the execution of
critical security mechanisms
• normally comprising hardware, firmware and software,
supports security policies and mechanisms
© 2008 Paulo Veríssimo
21
TCB - Trusted Computing Base
(contd.)
• Desirable TCB design properties:
• Interposition
– the TCB position is such that no direct access to protected
resources can be made bypassing the TCB, i.e. nothing can
detour the TCB’s access control
• Shielding
– the TCB construction is such that it itself is protected from
unauthorized access to its own structures, i.e. nothing should
intrude the TCB
• Validation
– TCB functionality is such that it allows the implementation of
verifiable security policies
– normally implies that TCB functionality should be simple
enough
© 2008 Paulo Veríssimo
22
Usefulness of TCB: Example
Principal
Request
Reference
Monitor
Object
TCB
• The Reference Monitor (RM)
– is interposed between users and resources,
– runs the critical routines that ensure access only to
authorized users
• Obviously, the RM must be intrusion-proof
– else these mechanisms are bound to fail
© 2008 Paulo Veríssimo
23
Revision on Basic Cryptography
Symmetric and Asymmetric
© 2008 Paulo Veríssimo
24
Terminology
• encryption / decryption
– EKau(M) or Ea(M) : encrypt with public key of A
– DKar(M) or Da(M) : decrypt with private key of A
– when cipher is symmetric, only one (secret) key Ka exists
• signature / verification
– SKar(M) or Sa(M) : sign with private key of A
– VKau(M) or Va(M) : verify with public key of A
•
NB- if same protocol is used (ex. RSA): Va = Ea e Sa = Da
• digest
– Hmd(M) ou H(M) : get hash with algorithm MD
• usual characters:
– Alice and Bob: usually the good guys
– Mallory and Eve: usually the bad guys
– Trent: usually the common friend
© 2008 Paulo Veríssimo
25
Computational Cryptography
• MECHANISM:
– given a pair of encryption/decryption keys resp. K1 / K2 , and
functions encrypt (E) and decrypt (D):
– if E(K1,m)=c , then D(K2,c)=m and thus D(K2,E(K1,m))=m
– if K1 and K2 are different, we say an asymmetric cipher
– if K1 = K2 = K we say a symmetric cipher
•
ATTRIBUTES:
– given E(K1,m), without K2 it is infeasible to recover M
– given M and E(K1,m), it is infeasible to recover K1
– given K1 , it is infeasible to recover K2 and vice-versa
– if keys are equal, K1 = K2 = K , first two statements still apply
© 2008 Paulo Veríssimo
26
Symmetric Cryptography
• also called shared or secret key cipher
– encrypt and decrypt key is the same
– fairly fast
• PROPERTIES: D(K2,E(K1,m))=m
• Examples: Data Encryption Standard (DES) (1977);
Triple-DES; IDEA; Advanced Encryption Standard
(AES) 2000
• Types: block cipher, and stream cipher
© 2008 Paulo Veríssimo
27
Block ciphers – AES
(Advanced Encryption Standard )
• BACKGROUND:
– New NIST standard to replace DES
– public design and selection process, based on Rijndael
• PRINCIPLES:
– an iterative rather than feistel cipher
• treats data in 4 groups of 4 bytes
• operates an entire block in every round, rather than feistel (operate on
halves at a time)
– operate 128bit blocks of plaintext with 128, 192, 256 bit key
K
– produces 128bit blocks of cyphertext
– designed to be resistant against known attacks
– speed and code compactness on small and large CPUs
© 2008 Paulo Veríssimo
28
Stream Ciphers - One Time Pads
Shared
Secret Key
KAB
A
Ki
Keystream
Generator
Keystream
Mi
cleartext
•
•
•
B
+
Keystream
Generator
Ki
Keystream
ciphertext
+
Mi
cleartext
PRINCIPLE :
– processes one bit/byte at a time
– infinite sequence of random bits combined with the cleartext stream
– this keystream, also called pad, is used only once, thus unbreakable
ENCRYPTION :
– pad is XORed with running cleartext stream, bit by bit (or byte by byte)
DECRYPTION :
– encrypted cyphertext stream is XORed with the same key sequence,
yielding the original cleartext stream
© 2008 Paulo Veríssimo
29
Asymmetric Cryptography
•
also called public-key cipher
•
PRINCIPLE:
•
PROPERTIES: D(Kr,E(Ku,m))=m and also E(Ku,D(Kr,m)=m) ]
•
Examples:
– encrypt public key Ku and decrypt private key Kr
– not so fast, considerably slower than symmetric crypto
– relies on the difficulty of determining the number of numbers relatively prime
to a large integer n
– E e D are equivalent functions, one can at will combine encrypt/decrypt with
public/private key, the meaning of that will be explored soon
– Diffie-Helmann, to compute a shared secret number (1976); Rivest-ShamirAdleman (RSA) (1978)
© 2008 Paulo Veríssimo
30
Secure Hashes or Message digests
Message (previously padded)
512b
128 bits
Initial
Vector
Digest
Digest
Digest
Message
Digest
• OBJECTIVE:
– function to generate a set of fixed length k bits from a set of variable
length n bits (where usually k << n),
– similar to LAN CRC, but much more robust w.r.t. collisions
– much faster than symmetric encryption
• EXAMPLES: MD4, MD5, SHA-1
© 2008 Paulo Veríssimo
31
Secure Hashes or Message digests
Message (previously padded)
512b
128 bits
Initial
Vector
Digest
Digest
Digest
Message
Digest
• ATTRIBUTES: Given secure hash function h: AB
– For any m  A, h(m) is easy to compute
– For any h(m)  B, it is computationally infeasible to find m  A
– It is computationally infeasible to find two inputs m, m  A such that m
≠ m and h(m) = h(m)
– Given any m  A, it is computationally infeasible to find a different m 
A such that h(m) = h(m), even if m ~= m’
© 2008 Paulo Veríssimo
32
Cryptographic Checksums
• MAC - Message authentication code
• MIC - Message integrity check
•
•
•
•
•
•
•
Non-forgeable digests (secure
hashes) protected with symmetric
key K: HK(M)
K known only to communication
endpoints ensures integrity and/or
authenticity of messages
K used in encryption or mingling
appropriate when confidentiality not
needed
content verified by re-hashing/rekeying
remember definition of secure
channel with symmetric crypto
EXAMPLES: HMAC
Message
Digest
MESSAGE DIGEST
K
Encrypt
EK
MAC/Signature
Message
© 2008 Paulo Veríssimo
33
Signing with asymmetric crypto
Public Key of A
Kua
Private Key of A
Kra
B
A
M
plaintext
Signature
(or encryption)
Algorithm
S
signed text
Verification
(or decryption)
Algorithm
M
plaintext
• PROTOCOL:
– Alice signs with private key, Sa(M) and sends Bob
– Bob verifies with public key, Va(M’) = Va ( Sa(M) ) = M
• PROPERTIES:
– Authenticity, Unforgeability, Integrity, Non-repudiation
– Non-reutilization: entire document can be re-utilized
© 2008 Paulo Veríssimo
34
Authentication
and
Key Distribution
© 2008 Paulo Veríssimo
35
Basics of Authentication
• the process of binding an identity to a subject :
– identity is external representation of entity (Alice, etc.)
– subject is computer representation (process, Ceethreepeeo,
etc.)
• the process of proving :
– the identity of a principal A
– that B acts on behalf of A
• proving identity:
–
–
–
–
what entity knows (e.g. password)
what entity has (e.g. badge, smart card)
what entity is (e.g. fingerprints, retinal characteristics)
where entity is (e.g. in front of a given notebook)
© 2008 Paulo Veríssimo
36
Examples of Authentication
• examples of one-way authentication :
– Alice proves her identity as creator of a document by signing it
– or proves to be an authorized user of a service through a password
– PC CeeThreepeeo proves identity to another machine by its IP address
• what if Alice does not trust the server? Server should also
authenticate itself to Alice: mutual authentication.
• when Alice sits on CeeThreepeeo, she delegates authentication
process on it (e.g. to execute the login)
– what happens if CeeThreepeeo has been tampered with?
– or if someone stole Alice's password?
– or if some other machine impersonates CeeThreepeeo 's address?
© 2008 Paulo Veríssimo
37
Examples of Authentication
• how can Alice or CeeThreepeeo unequivocally prove their
identity in these cases?
– Alice could use her digital signature for authentication
– Alice could have her personal tamperproof smart card
Artoodeetoo prove its identity and indirectly that of Alice
• relationships above between Alice and CeeThreepeeo or
Artoodeetoo are delegation
– however, what if Alice lends Artoodeetoo to someone, or loses
it together with the PIN?
– or else, she lets her private key be stolen?
• have you heard of iris or retina scanning?
© 2008 Paulo Veríssimo
38
Types of Authentication
I'm Alice,
here are my credentials
• Unilateral
– authentication is based on
principal A authenticating
itself to principal B
• Mutual
 
Alice
Bob
Unilateral Authentication
I'm Alice,
here are my credentials.
And who are you?
– authentication is based on
principals A and B mutually Alice
authenticating themselves
 
I'm Bob,
and here are my
credentials too.
 
Bob
Bob
Mutual Authentication
© 2008 Paulo Veríssimo
39
Types of Authentication
Hi Trent.
I want Bob
Hi Bob.
Alice will contact you.
Here are her credentials
Hi Alice. Here
are Bob's
credentials





Trent
(Mediator)
Alice




Bob
Mediated Authentication
• Mediated
– authentication is based on principal A being authenticated to
principal B by a mediator T, whom they both trust
© 2008 Paulo Veríssimo
40
Key Distribution or Exchange
• Long-term keys
– keys used to initiate any operations or protocols concerned
with a given principal
– obtained directly from alternative channels (e.g. mail) or
through certification authorities (CA)
• Short-term or session keys
– keys used to perform operations or protocols concerned with
a given principal
– obtained automatically, directly or through a mediator like a
Key Distribution Center (KDC)
© 2008 Paulo Veríssimo
41
Classical Key Exchange
• Harder than it looks…
• Goal: Alice, Bob to get shared session key kss
• Bootstrap: how do Alice, Bob begin?
– Key cannot be sent in clear
• Assume trusted third party, Trent
– Alice and Trent share secret key kA
– Bob and Trent share secret key kB
• use Trent to exchange shared key kss
– Alice sends EkA{request kss , Bob} to Trent
– Trent sends Alice EkA {kss} ; EkB{kss}
– Alice sends EkB {kss} to Bob
© 2008 Paulo Veríssimo
42
Key Exchange Problems
• How does Bob know he is talking to Alice?
– Replay attack: Eve records message from Alice to Bob, later
replays it; Bob may think he’s talking to Alice, but he isn’t
– Session key reuse: Eve replays message from Alice to Bob, so
Bob re-uses session key
• key exchange protocols must provide authentication
and defense against replay
• as we will see in the next chapter
© 2008 Paulo Veríssimo
43
Access Control
© 2008 Paulo Veríssimo
44
Overview of access control
• protection domain
– set of resources that lie under the realm of an access control
mechanism
• protection state
– describes current settings, values of system relevant to
protection
• Access Control Matrix
– Describes protection state precisely
– Matrix describing rights of subjects over objects
– State transitions change elements of matrix
• can be simplified:
– Access Control List (ACL)
– Capabilities list (C-list)
© 2008 Paulo Veríssimo
45
Access Control Matrix (ACM)
• The ACM mechanism is defined by the following:
– each subject has a list of the objects of a protection domain
which it may access;
– each object of a protection domain has a list of subjects that
may access it;
– these two lists form a matrix where each entry is a triple
<subject, object, rights>
– subject is an Id of a user or a process;
– object is the Id of a resource;
– rights is the enumeration of the access rights granted to this
subject on that object
– the ACM is protected by the system against unauthorized
modication
© 2008 Paulo Veríssimo
46
Access Control Matrix
objects
subjects
o1 … om s1 … sn
s1
s2
…
sn
• subjects S = { s1,…,sn } and objects O = { o1,…,om }
• entries A[si, oj]  R define rights R = { r1,…,rk }
• A[si, oj] = { rx, …, ry } means subject si has rights rx, …, ry over
object oj , rights usually combinations of rwd.. etc.
• rights may apply to subjects as well, e.g., A[si, sk] defines access
of subj. si to subj. sk (e.g. a process to another process)
© 2008 Paulo Veríssimo
47
Example Access Control Matrix
Finance
Person.
Product.
General Mgr
r
r
r
Finance Mgr
rwcd
---
r
Product Mgr
---
---
rw
• Some design rules for info protection:
• least privilege rule: general manager only has read access to all
files; she does not need to have greater rights in order to
perform her function.
• need-to-know rule: managers only have rights over the objects
related to their functions; subject should only be given access to
the information needed to perform his work.
• a subject should be given the least amount of rights to the least
number of objects possible in order to perform her job
© 2008 Paulo Veríssimo
48
Other Access Control mechanisms
• Access Control List
• Capacities List
© 2008 Paulo Veríssimo
49
Access Control List or ACL
• popular access control mechanism, used by many O.S.
• ACL mechanism is defined by the following:
–
–
–
–
each object has a list (ACL) of the subjects that may access it;
each element of the list is a pair <subject,rights>
subject is an Id of a user, a process, or a group;
rights is the enumeration of the access rights granted to this
subject on that object, usually a bit mask
• (e.g., xrwd for UNIX, i.e. execute, read, write, delete);
– ACL is protected against unauthorized modification
– subjects with similar rights on an object may be grouped (e.g.,
world in UNIX)
– grouping can present a vulnerability: hides access rights of
individual subjects; prone to granting access rights to the
wrong subject
© 2008 Paulo Veríssimo
50
Example Access Control List
Finance
Person.
Product.
General Mgr
r
r
r
Finance Mgr
rwcd
---
r
Product Mgr
---
---
rw
• ACLs are the columns of access control matrix
ACLs (define which subjects access each object , and how):
• Finance: { (General Mgr, r) (Finance Mgr, rwcd) }
• Personnel: { (General Mgr, r) }
• Production: { (General Mgr, r) (Finance Mgr, r) (Production Mgr, rw) }
© 2008 Paulo Veríssimo
51
Capabilities List (C-list)
• C-list mechanism is defined by the following:
– each subject has a list (C-list) of the objects that it may
access;
– each element of the list is a capability, a pair <object,rights>
– object is an Id of a resource;
– rights is the enumeration of the access rights granted to that
subject on this object, usually a bit mask
– C-list is protected against unauthorized modification or
forging
• done cryptographically to prevent subject tampering with it
© 2008 Paulo Veríssimo
52
Example Capability List
Finance
Person.
Product.
General Mgr
r
r
r
Finance Mgr
rwcd
---
r
Product Mgr
---
---
rw
• Capabilities are the rows of access control matrix
C-Lists (define which objects each subject accesses, and how):
General Mgr : { (Finance, r) (Personnel, r) (Production, r) }
Finance Mgr : { (Finance, rwcd) (Production, r) }
Product Mgr : { (Production, rw) }
© 2008 Paulo Veríssimo
53
Types of access control policies
• consider the rules to fill in the access control tables
– they define which objects subjects or groups of subjects may access,
and in what manner
– the set of these rules is called the access control policy
• types of access control policies:
• Discretionary Access Control (DACC)
– individual user sets access control mechanism to allow or deny access
to an object
• Mandatory Access Control (MACC)
– system mechanism controls access to object, and individual cannot
alter that access
• Originator Controlled Access Control (ORCON)
– originator (creator) of information controls who can access
information
© 2008 Paulo Veríssimo
54
Secure Communication
© 2008 Paulo Veríssimo
55
Secure Channels
• Secure Channels
– form of immediate communication
– traditional forms of computer communication or telecom
– links, such as local area network protocols
– like a pipe that goes directly from A's mouth to B's ear,
completely opaque, and impenetrable
© 2008 Paulo Veríssimo
56
Secure Envelopes
• Secure Envelopes
– form of deferred communication
– messages whose delivery is sporadic and deferred in time,
electronic mail
– messages must have standalone security, wrapped in a secure
envelope enjoying: authenticity; confidentiality; integrity
– like a message that is signed, put inside an opaque envelope,
and the envelope is sealed
© 2008 Paulo Veríssimo
57
What is a secure channel?
• authenticity
– what B receives was sent by A, who cannot deny
– to verify, one must know what one expects (format, partial
content)
– A can only deny if key was compromised
• confidentiality
– only B reads what A sent
– A must be sure that: only B knows shared key; used key is
really B’s pub-key
• integrity
– what A sent cannot be altered without detection
– decryption must yield verifiable content
© 2008 Paulo Veríssimo
58
Implementing secure channels
• with symmetric crypto
– there is key exchange problem; full authentication requires
trusted third parties
– past that, given shared key, it provides confidentiality and
authenticity
• with asymmetric crypto
– Confidentiality:
• sender A encrypts with B’s public key and sends: E Kbu(M);
• recipient B decrypts with his private key: D Kbr( E Kbu(M))
– Authenticity:
• sender A signs with his private key and sends: S Kar(M);
• B verifies with A’s public key: V Kau( S Kar(M))
© 2008 Paulo Veríssimo
59
Implementing secure channels
• with asymmetric crypto (contd.)
– Confidentiality and Authenticity :
• sender A signs with his private key, encrypts with B’s public key and sends: E
Kbu(S Kar(M) );
• recipient B decrypts with his private key, and verifies with A’s public key : V
Kau(D Kbr(E Kbu(S Kar(M) ));
– Integrity:
• comes with algorithms used: modifications in transit yield
undecipherable/unverifiable messages
© 2008 Paulo Veríssimo
60
© 2008 Paulo Veríssimo
61
Models
for
Secure Computing
Chapter 3
© 2008 Paulo Veríssimo
62
Misuse of computers
[Abrams et al., 95]
• Human error
– Accidental human mistake of an authorized user causing a
vulnerability that may lead to intrusion.
– E.g., giving world read/write permissions to a confidential file, or
creating an account without password
• Abuse of authority
– Intentional action of an authorized user abusing the authority
granted by his activity.
– For example, a bank teller setting-up schemes of bogus transactions
that leak a few cents each time to his personal account
• Direct probing
– Attack made by an unauthorized user by means of passively exploiting
existing vulnerabilities with the aim of intrusion.
– E.g., entering through a forgotten account with default password, or
using a stolen or guessed password
© 2008 Paulo Veríssimo
Misuse of computers
(contd.)
• Software probing
– Attack made by an unauthorized user passively exploiting existing
vulnerabilities with malicious software, with the aim of intrusion.
– E.g., use of a Trojan horse that pretends to be the login program,
logging inadvertent users while it steals all their passwords
• Penetration
– Attack made by an unauthorized user actively exploiting existing
vulnerabilities normally with malicious SW, with the aim of intrusion.
– E.g., sending a malicious HTTP request that confuses HTTP server,
leading it into giving an anonymous intruder total (root) control
• Subversion
– Attack made to a system, either at design or runtime, by designers
or users, covert and methodically undermining protection mechanisms,
with the aim of continued intrusion.
– E.g., by modifying operating system programs in order to introduce
trapdoor that covertly perpetuate the intrusion
© 2008 Paulo Veríssimo
Design Principles
[Saltzer, Schroeder 75]
for Computer Security
• eight principles for the design and implementation of
security mechanisms
• principles draw on ideas of simplicity and interaction
restriction
• Principles
–
–
–
–
–
–
–
–
Least Privilege
Fail-Safe Defaults
Economy of Mechanism
Complete Mediation
Open Design
Separation of Privilege
Least Common Mechanism
Psychological Acceptability
© 2008 Paulo Veríssimo
65
Design Principles
• Least Privilege - A subject should be given only those
privileges necessary to complete its task
– function of subject (not identity) determines which privileges
– rights added as needed, discarded after use
– e.g., subject should relinquish any higher privileges it got to
complete a task, upon completion of the task
• Fail-Safe Defaults - Unless a subject is given explicit
access to an object, it should be denied access
– i.e., default control is no access
– if an action fails, partial results should be undone
– even if the program fails, the system is still safe
© 2008 Paulo Veríssimo
66
Design Principles
(contd.)
• Economy of Mechanism - Security mechanisms should be as simple
as possible
– …but no simpler!
– simplifies verification and proofs of security
– simpler means less can go wrong, errors easier to understand/ fix
• Complete Mediation - Every access to objects should be checked
to ensure it is are allowed
– OS should mediate any request to an object
– after open, should continue checking subsequent requests
– if permissions change after, may get unauthorized access
• Open Design - Security should not depend on secrecy of design or
implementation
– no “security through obscurity”
– secret keys do not violate this principle
© 2008 Paulo Veríssimo
67
Design Principles
(contd.)
• Separation of Privilege - A system should not grant a permission
based on a single condition
– e.g., require more than one sys admin to issue a critical command
– akin to separation of duty (developer of a program should not test it)
• Least Common Mechanism - Mechanisms used to access resources
should not be shared
– minimize mechanisms many users depend upon
– shared mechanisms are a potential information leakage path
• Psychological Acceptability - Security mechanisms should not
make access to resources more difficult
– too complex mechanisms will be circumvented or used incorrectly
– hide complexity introduced by security mechanisms
© 2008 Paulo Veríssimo
68
Types of Attacks and Intrusions
© 2008 Paulo Veríssimo
Passive attacks
• Probing
– exploring a network or system looking for vulnerabilities (ex.
portscan, doorknob rattling)
• Sniffing
– listening to and recording passing traffic on a network
• Snooping
– methodically inspecting system internals or data repositories
• N.B.- Less destructive than active attacks in appearance, passive
attacks are much more difficult to trace
© 2008 Paulo Veríssimo
70
Sniffing
Sniffer
Alice
Bob
Filter
• sniffer machine's LAN adapter configured to promiscuous
reception
• information received is filtered
• then stored in disk, to be used later
•
N.B.- very hard to trace a sniffer, since it is absolutely passive
© 2008 Paulo Veríssimo
Active attacks
• aggressive attempts to penetrate the system, disrupt its
operation, and/or steal, modify or destroy data
• Penetration attacks
– directed at internal networks, machines, protocols, by defrauding its
access control mechanisms
– e.g., spoofing
• Disruption attacks
– addressed at resources, processing or communications, jamming or
bringing them down, may also be directed at specific services
– e.g., denial-of-service
• Other active attacks
– Viruses, Worms, Bombs
– Trojan Horses and Zombies
– Trapdoors and Covert channels
© 2008 Paulo Veríssimo
72
Spoofing
Spoofer
Alice
Malicious
Code
Bob
• malicious host intercepts communications between two
participants, reading and/or changing its contents dynamically
• e.g., insertion/deletion or replay of whole messages
• on-the-fly modification of message content
• appending malicious code to downloads or messages
© 2008 Paulo Veríssimo
Computer Virus
• program that inserts itself into one or more files and
performs some action
– both propagates itself & triggers some execution
• piece of self-replicating code with some other code
attached
– carries code to make copies of itself
– as well as code to perform some covert task
• virus phases:
–
–
–
–
dormant
propagation
insertion
execution
– waiting on trigger event
– replicating to new files
– inserting itself into file
– of payload, triggered by some event
© 2008 Paulo Veríssimo
74
Computer Worm
• program that copies itself from one computer to
another
• replicating, resource-consuming, but typically not
infecting program, spreading over a network
• worm phases:
– dormant
– waiting on trigger event
– propagation – replicating to new systems
– insertion
– inserting itself into system
– execution
– of the worm code
© 2008 Paulo Veríssimo
75
Logic Bomb
• program that performs an action entailing a security
failure when some external event occurs
– e.g.: program that deletes an organisation’s database when
some trigger condition happens, e.g. a anniversary date
• code is embedded in legitimate program
• typically causes damage
• trigger conditions can vary:
– action on a database, time/date, message received, user login,
etc.
© 2008 Paulo Veríssimo
76
Trojan Horse
• program with an overt purpose (known to user) and a
covert purpose (unknown to user
• e.g., login Trojan:
– overt purpose: log a user in, by accepting his password
– covert purpose: store password in hidden file for later
recovery
• program with hidden side-effects which on the
surface is useful or attractive
•
N.B.- often used to propagate a virus/worm or install a backdoor
or simply to destroy data
© 2008 Paulo Veríssimo
77
Zombie
• program which secretly takes over a networked
computer
– e.g., by exploiting flaws in networked systems
• remains dormant until activated
– e.g., by message, or remote access connection
• then uses victim to indirectly launch attacks
• N.B.- collections of zombies, part of what are called BotNets,
often used to launch distributed denial of service (DDoS) attacks
© 2008 Paulo Veríssimo
78
Attacking a secure channel
• Attacking ALGORITHMS
– best protection is making it public, tested by many
• Attacking MESSAGES
– shows that a channel does not live only on good ciphers
• Attacking KEYS
– best protection is use good quality keys (long, random)
• Attacking PROTOCOL EXECUTION
– protocols need robust design (exception handling, bounds
check)
© 2008 Paulo Veríssimo
79
Security Strategies
• fundamental tradeoffs to be considered by
the systems architect:
–
–
–
–
–
–
–
–
–
cost vs. effectiveness
performance vs. security
robustness vs. lifetime
degree of vulnerability vs. level of threat
cost of securing vs. cost of intruding
prevention vs. tolerance of attacks
prevention vs. detection of modification
detection/recovery vs. prevention of fraud
cost of security vs. cost of breaking
© 2008 Paulo Veríssimo
80
Figures of merit of several cryptosystems
© 2008 Paulo Veríssimo
81
Figures of merit of several cryptosystems
• robustness of DES:
– depends on exhaustive search on space of 256 values, or
O(1015)
• robustness of RSA:
– depends on exhaustive search on variable space, e.g. for
500bit key, of 2500 values, or O(10150)
• typical speed ratios suggest:
– asymmetric: key management, digital signature
– symmetric: payload traffic
– digest: signature compression; MIC/MAC
© 2008 Paulo Veríssimo
82
Security Strategies
(cont.)
• Keys and Passwords
– should not be the weak link
• Vulnerabilities versus Attacks
– the balance between both
• Open System Security Policies
– from promiscuous to paranoid
• Trusted Computing Bases (TCB)
– can they really be implemented?
• Preventing Attacks
– blocking the intruder’s path
• Preventing Intrusions
– avoiding errors that may lead to security failure
• Detecting and Reacting to Intrusions
– attack and/or intrusion detection or masking; diagnosis
• Avoiding Disruption
– prevent success of denial-of-service attacks
© 2008 Paulo Veríssimo
83
On keys and passwords
• Brute-force attack:
– number of processors needed to break 56bit key in 1 month, at 256
Meps (encrypt. per second): 100
– likewise, for 128bit key: 5x1023
• Dictionary attack:
– weak keys – e.g. when you only use “nice” letters, search space shrinks
(DES can go from 1016 possibilities to 1012 if you only use lower caps
and digits)
• Pass phrase:
–
–
–
–
–
"My dear friends, who on earth would believe this is my pass phrase?"
after hashing, yields a 64-bit hexadecimal quantity:
E6C1 0A9B 894E 03AF
a good albeit hard to memorize password
practical length rule: one letter of phrase per each key bit
© 2008 Paulo Veríssimo
On Vulnerabilities and Attacks
• seen previously:
• correct measure of how potentially insecure a system
can be (in other words, of how hard it will be to make it
secure) depends:
– on the number and severity of the flaws of the system
(vulnerabilities)
– on the potential of threat it may be subjected to (attacks)
• both concur to define the risk of intrusion
• a balance between the two is mandatory in a good
architecture design
© 2008 Paulo Veríssimo
85
Main security problems in open systems
• Networks:
–
–
–
–
bugs of communication protocols
broadcast or wireless nature of networks
openness to anonymous access
the human element (administrator and user)
• Hosts:
– bugs of the O.S. and widespread application software
– wrong configurations (backdoors)
– human element (administrator and user)
© 2008 Paulo Veríssimo
Security Policies
• Policies try to define as precisely as possible :
– which system states are authorized or secure
• the system can transition between these states
– which system states are unauthorized or not secure
• the system cannot enter these states
• if that happens, a security failure occurs
• necessary condition for a secure system:
• programs should ensure that
– system starts in an authorized state
– system never enters unauthorized state
• is this a sufficient condition?
© 2008 Paulo Veríssimo
87
Example confidentiality policy
• X set of entities, I information
• POLICY:
• I has confidentiality property with respect to X and only X
• CONDITIONS:
– no x  X can obtain information from I
– I can be disclosed to others
• EXAMPLE:
– X set of students
– I final exam answer key
– I is confidential with respect to X if students cannot obtain
exam answer key
© 2008 Paulo Veríssimo
88
Example ambiguous policy
• school, where all assignments are done on computer
• POLICY:
• Students cannot read or write each other’s files
• SCENARIO:
– Alice forgets to read-protect her homework file
– Bob copies it
• Who violated policy? Alice, Bob, or both?
• Bob cheated - violated policy
– Policy forbids copying homework assignment
– System entered unauthorized state - Bob having copy of
Alice’s HW
• Alice didn’t protect homework – did not violate policy
– Not required by security policy!
– policy would have to state
– “users must read-protect their files”
© 2008 Paulo Veríssimo
89
Types of Security Policies
• Military (governmental) security policy
– Policy primarily protecting confidentiality
• Commercial security policy
– Policy primarily protecting integrity
• Confidentiality policy
– Policy protecting only confidentiality
• Integrity policy
– Policy protecting only integrity
© 2008 Paulo Veríssimo
90
From policy to mechanism
•
•
•
•
Policies describe what is allowed/forbidden
Mechanisms control how policies are enforced
Trust underlies everything
Mechanisms and computers, not only policies, must be
trusted
© 2008 Paulo Veríssimo
91
Access control policies and mechanisms
• Access Control Policy
– defines what kinds of access are allowed to which objects by
which subjects
– technical implementation of at least part of a security policy
– < s, o, m > : subject s, can access object o, in mode m (ex. rd)
• Access Control Mechanisms
– implement access control policy
– examples already studied: Access Ctrl Matrix, Access Ctrl List,
Capabilities
• Access Control Policy Classes
– define the rules for setting-up the policy
– examples already studied: mandatory and discretionary access
control
© 2008 Paulo Veríssimo
92
Network security policies (4PP)
• Paranoid
– all is forbidden
– no connection to/from the network
• Prudent
– all that is not explicitly allowed is forbidden
– all is blocked by default, connections to/from the network are allowed
on a case-by-case basis
• Permissive
– all that is not explicitly forbidden is allowed
– all is open by default, connections to/from the network are disallowed
on a case-by-case basis
• Promiscuous
– all is allowed
– any connection to/from the network can be made
© 2008 Paulo Veríssimo
93
Using Cryptographic Protocols
•
•
•
•
•
protocol types
block cipher modes
double and triple encryption
signing and encrypting
hybrid cryptrography
© 2008 Paulo Veríssimo
94
Self-enforcing protocols
Self-Enforcing Protocol
Alice
Bob
• Correct behaviour achieved by protocol participants alone
• They must build trust during protocol execution without trusting
each other initially, and some maybe being malicious (e.g., by
voting, k-out-of-n)
Paul
Self-Enforcing Protocol
Alice
Bob
Luisa
© 2008 Paulo Veríssimo
95
Trusted-Third-Party protocols
• Based on an apriori trusted
component (TTP)
• adjudicated
– Acting a posteriori if necessary to
recover from errors
• arbitrated
– Correct behaviour guaranteed
during execution, errors prevented
by arbiter
• certified
– Correct behaviour guaranteed
prior to execution through
credentials supplied which limit
participants misbehaviour during
execution (errors prevented)
• TTP may be single point of failure
© 2008 Paulo Veríssimo
96
Practical encryption
• block ciphers encrypt fixed small-size blocks
– need to handle arbitrary length of cleartext
– already saw possible attacks to block-by-block encryption
– similar problems may happen with stream ciphers
• such study first made for DES, but applicable to others
– four encryption modes defined for DES
– ANSI standard ANSI X3.106-1983 Modes of Use
– defined block and stream modes
© 2008 Paulo Veríssimo
97
Signing and encrypting
• protocol implementing signature with digest and encryption
• should avoid, in order of importance:
– use same keys for signing and encrypting
– use same protocol for signing and encrypting
– make participant sign something it does not know
© 2008 Paulo Veríssimo
98
Hybrid Cryptography
(hybrid cryptographic channel)
• simple protocol for set-up of secure channel with hybrid crypto
© 2008 Paulo Veríssimo
99
Hybrid Cryptography
(hybrid cryptographic envelope)
Message
Randomize
Kss
Kss
Symmetric
Encrypt
recipient's
public key
Kp
Asymmetric
Encrypt
Encrypted Kss
Message
• protocol implementing secure envelope with hybrid crypto
© 2008 Paulo Veríssimo
100
Authentication Models
•
•
•
•
•
•
Password-based Authentication
Shared-Secret Authentication
Signature-based Authentication
Mutual Authentication
Mediated Authentication
Distributed Authentication
© 2008 Paulo Veríssimo
101
Authentication Mechanisms
• Password
– authentication is based on A submitting to B a unique pair
<username,password>
– B checks against password database or file
• Shared Secret
– authentication is based on A proving to B that A knows a
secret K
– only A and B and no one else share K
– must take place without showing the secret
• Signature
– authentication is based on A proving to B to have signed
something using its digital signature S, that no one else can
produce
© 2008 Paulo Veríssimo
102
Password-based Authentication
• Local Authentication
– vulnerable if adversary gets access to machine and then to
password file
– password file should be protected:
• one-way encryption: obscuring contents, e.g. replacing password with nonreversible hash or cryptographic checksum
• shadowing : making it difficult for the intruder to read the password file
– there is always the possibility of a direct attack:
• on-line password guessing
• off-line password guessing
© 2008 Paulo Veríssimo
103
Password-based Authentication
• Remote Authentication
– vulnerable if adversary gets read access to network traffic
(sniffer)
• possible solutions?
– one-time passwords
– encrypting the remote authentication interaction
© 2008 Paulo Veríssimo
104
Password storage
• cleartext
– not a good solution
• hash of password
– not bullet-proof
– but makes adversary’s job harder
– the better the password, the better the protection one gets
• hash of password with salt
– Makes bulk dictionary attacks harder, but no harder to attack
a particular password
• centralized server stores password
© 2008 Paulo Veríssimo
105
Centralized password storage
• Authentication storage node (aka security server)
– central server stores password
– servers request the password to authenticate user
• Authentication facilitator node
–
–
–
–
central server stores password
servers send information from user to central server
authentication always performed by the central server
password never leaves central server
• Notes:
– central server must be authenticated
– central server is single point of failure
© 2008 Paulo Veríssimo
106
Basic password authentication methods
• server stores H(passwd)
• user sends passwd
– secure against server compromise
– attackable by guessing, eavesdropping, replay
• server stores passwd
• server sends X
• user replies H(passwd,X)
– secure against eavesdropping, but not compromise or guessing
• can we achieve security against both?
– alternative authentication methods
© 2008 Paulo Veríssimo
107
One-Time Passwords
• Password that can be used exactly once
– after use, it is immediately invalidated
• Challenge-response mechanism
– challenge is ordinal number of authentications (e.g. 3rd) using
a same seed (number that starts a series of passwords)
– response is password for that particular number
• Problems
– synchronization of user and system
– generation of good random passwords
– seed or password list distribution problem
© 2008 Paulo Veríssimo
108
Dictionary attacks on passwords
• Trial-and-error from a list of potential passwords
• Off-line
– knows hashed password and authentication function
– repeatedly try different guesses until list done or password
guessed
– can be automated, example programs: crack
• On-line
–
–
–
–
have access to authentication interface
try logon guesses until some login succeeds
can be automated, but much slower than off-line
defences:
• backoff (increasing delay)
• disconnection (after x failures, connection breaks, must be reestablished)
• disabling (after x failures, account is disabled, must be re-enabled by sysadm)
© 2008 Paulo Veríssimo
109
Biometrics
• automated measurement of biological, behavioural
features that identify a person
• fingerprints
– optical or electrical techniques
– maps fingerprint into a graph, then compares with database
– measurements imprecise, so approximate matching algorithms
used
• voice
– speaker verification or recognition
– verification: uses statistical techniques to test hypothesis
that speaker is who is claimed (speaker dependent)
– recognition: checks content of answers (speaker independent)
© 2008 Paulo Veríssimo
110
Other techniques for human auth.
• tokens
– Magnetic stripe cards
– Smartcards
– “Standalone” tokens:
• still need a secure authentication protocol to go along
© 2008 Paulo Veríssimo
111
Hardware tokens
• number-based:
–
–
–
–
server sends challenge
user enters challenge into token
token displays reply to be sent to server
reply may be combined with user PIN requested by token to user
(validates use of token as well)
• time-based:
– every minute a new challenge is displayed on token, randomly chosen
from n-digit space
– user sends login, server requests password
– user enters his password + token number at time of login
– both user and server have similar tokens, so server knows what
number to expect at that time
– token numbers are one-time use
© 2008 Paulo Veríssimo
112
Pluggable Authentication Modules
• PAM - Pluggable Authentication Modules:
– techniques using multiple methods assign one or more authentication
methods to each entity
• Idea:
– when program needs to authenticate, it checks a library in security
server for methods to use
• Library call: pam_authenticate
– UNIX: accesses file with name of program in /etc/pam.d
• Modules needed to do authentication are selected as:
– sufficient: succeed if module succeeds
– required: fail if module fails, but all required modules are executed
before reporting failure
– requisite: like required, but fail immediately, don’t check all modules
– optional: invoke only if all previous modules fail
© 2008 Paulo Veríssimo
113
Basic public-key authentication methods
(unilateral)
• by signing or encrypting
• setting and objective:
– B knows A’s public key Kua
– after some exchanges, B must believe that its peer knows a
private key Kra, counterpart of Kua
– as such, it must be A
• signing example
– 1) A-->B : I am A; 2) B-->A : if you are A, sign X; 3) A-->B :
Sa(X)
• encryption example
– 1) A-->B : I am A; 2) B-->A : if you are A, decrypt Ea(X); 3) A->B : X
© 2008 Paulo Veríssimo
114
Basic public-key authentication methods
(mutual)
• objective:
– mutual authentication by asymmetric crypto between A and B
– a generalization of the unilateral asymmetric protocol
• notation :
– A has private/ public key pair Kra and Kua, generates random nonce Xa
– B also has private/ public key pair Krb e Kub, and generates Xb
• protocol:
•
•
•
•
•
1. A requests connection to B, sends Xa,Id
encrypted with Kub
2. B returns Xa, sends Xb, encrypted with
Kua
then, A trusts it is B who replies, since it
brings Xa, which A sent under Kub
3. A returns Xb, under Kub
then, B trusts it is A who initiated session,
since Xb had gone under Kua
Known public Kua, Kub
1.
AB
E Kub(Xa,A)
2.
BA
E Kua(Xa, Xb)
3.
AB
E Kub(Xb)
© 2008 Paulo Veríssimo
115
Basic public-key authentication methods
(mutual, signature-based)
• objective :
– mutual authentication by signatures between A and B
– a generalization of the unilateral asymmetric protocol
• notation :
– A has private/ public key pair Kra and Kua, generates random nonce Xa
– B also has private/ public key pair Krb e Kub, and generates Xb
protocol :
•
•
•
•
•
1. A requests connection to B, sends nonce
Xa and Id in clear
2. B returns Xa signed with Krb, sends Xb
3. A returns Xb, signed with Kra
then, B trusts it was A who returned B’s
original nonce Xb
4. A,B believe they are talking to each other
Known public Kua, Kub
1.
A B
A, Xa
2.
B A
Xb, Sb(Xa)
3.
A B
Sa(Xb)
4.
A, B
Believe they’re
talking to each other
© 2008 Paulo Veríssimo
116
Basic shared-secret authentic. methods
(unilateral)
• by shared secret
• setting and objective:
– A and B share a secret, and are the only one
– after some exchanges, B must believe that its peer knows a
secret key K, also known by B
– as such, it must be A
• example 1 :
– 1) A-->B : I am A; 2) B-->A : if you are A, encrypt X; 3) A-->B :
Ek(X)
• example 2 :
– 1) A-->B : I am A; 2) B-->A : if you are A, decrypt Ek(X); 3) A->B : X
© 2008 Paulo Veríssimo
117
Basic shared-secret authentic. methods
(mutual, nonce-based)
• a generalization of the unilateral asymmetric method
© 2008 Paulo Veríssimo
118
Basic shared-secret authentic. methods
(mutual, timestamp-based)
• replacing time-free nonces by global time-stamps from
synchronised clocks
© 2008 Paulo Veríssimo
119
Key Distribution approaches
• Certification Authorities (CA)
• Key Distribution Centers (KDC)
• Short-term Key Exchange
© 2008 Paulo Veríssimo
120
Session key establishment
• There are very few applications for which
authentication alone is sufficient!
– What do you do once you are authenticated?
• Generally, need to establish a session key
– Efficiency advantages to using symmetric-key techniques if
public-key authentication is used
– Advantages even if a symmetric key is already shared…
• Often, the process of key distribution is combined
with that of authentication:
– besides practical, it limits impersonation and forgery attacks
– some authentication protocols just seen do perform key
distribution
© 2008 Paulo Veríssimo
121
Key distribution
• long-term keys
– puts in place all the keys necessary for system bootstrap and
long-term use
– used in the initialisation of protocols
– from a master key one can get several secondary ones
– can be obtained directly, through parallel channels secure and
external to the cryptographic system used for payload, or online through Certification Authorities (CA)
– long-term key distribution is a key point in any cryptosystem
• example long-term keys:
– public/ private key pair of a principal
– long-term shared secret key
© 2008 Paulo Veríssimo
122
Key distribution
• short-term or session keys
– exchanges the keys necessary for temporary use, such as
message or email deliveries, or interactive sessions
– obtained automatically, by agreement amongst peers, or through
a mediator, also called Key Distribution Center (KDC)
– for short sessions, or else changed frequently (so many
interactions, so many minutes, etc.)
– short-term key exchange must be robust, often done under
protection of long-term keys
• example short-term or session keys
– temporary shared secret key to encrypt email or a comm’s
stream
© 2008 Paulo Veríssimo
123
Certification and
Public-Key Infrastructures (PKI)
• Keys are a crucial aspect of credibility of and confidence on a
cryptographic system by users
– that they cannot be forged and users impersonated
– that the repositories and distribution methods are secure
– key databases are tamperproof
• Public-Key Infrastructures (PKI)
– this is specially true of long-term keys, which are normally
asymmetric
– trusted infrastructures are needed for this, normally called PKI
• Digital Certificates
– digitally signed digital documents containing information needed to
attest the identity of a principal (keys, signatures, data, etc.)
– certification signature must be trusted
– e.g., electronic notary: document and transaction validation
© 2008 Paulo Veríssimo
124
What does identity mean?
• Identifiers correspond to principals
– Must uniquely identify the principal
– (Real) names alone are not enough!
• Ultimately, identity is proved using physical means
– identity card or passport, biometrics, etc.
• If these can be compromised, then certificates are
irrelevant
– Certificate is just a binding between external identity and
computer representation (Name, PublicKey)
© 2008 Paulo Veríssimo
125
Certification Authorities (CAs)
© 2008 Paulo Veríssimo
126
Certification Authorities (CAs)
• Based on public-key or asymmetric cryptograpy and on
notion of digital certificate
• certificate contains proof of identity of a principal,
e.g. <Name,PublicKey> and is certified (signed) by a
certification authority
• each CA has a well-known public key, used by all to
verify certificates
• certificates have stand-alone security, they can travel
and be stored by anyone and remain secure/correct,
cannot be tampered with without detection
© 2008 Paulo Veríssimo
127
Certification Authorities (CAs)
• CA authentication policy determines the level of
authentication needed to identify the principal before
the certificate is issued
• CA issuance policy describes the classes of principals
that may be issued certificates by the CA
• a single CA can have multiple policies, which in essence
is akin to it being several virtual CAs, each with its own
policies
• to address scalability and heterogeneity, CAs can be
structured according to several trust models, the most
common being hierarchical
© 2008 Paulo Veríssimo
128
Certification Authority functions
• Certificate Issuing
– user submits certificate prototype signed by itself
– CA checks, approves, signs and stamps, returns and/or
publishes
• Certificate Revocation
– for several reasons, some bad some normal, a certificate can
cease to be valid (bad: stolen key, black-listed user; normal:
change of status or data, user left an organisation, etc.)
– CA issues a special certificate (which is signed ans stamped as
any other) stating the revocation of certificate X,
• Issuing of Certificate Revocation List (CRL)
– now all users need to know about this
– CRL is a list that is published and widely disseminated
© 2008 Paulo Veríssimo
129
Certification model and terminology
• Issuer –
– whoever signs a certificate on behalf of an entity
• Subject –
– whoever requests and/or gets a certificate
• Verifier –
– whoever looks-up some entity’s certificate
• Target –
– the owner of a certificate in look-up process
• Trust Anchor –
– top-most CA/public-key trusted by the verifier to sign the
head of the verified certificate chain
© 2008 Paulo Veríssimo
130
Conflicts
• What if a CA issues a certificate tied to an email
address, but the owner of this address changes?
– revocation, replacement (like in credit cards)
• What if two CAs have the same dist. name?
– before a PCA may issue a certificate to a CA, it checks for a
conflict in the database; but only ensures uniqueness of (DN,
PK) pairs
– anyway, CAs should have different public keys
• What if a single CA issues certificates under
different policies?
– CA will use different public keys for each policy realm
• What if two different CAs issue certificates for the
same distinguished name (to different principals)?
– prevented by incorporating CA name into distinguished name
© 2008 Paulo Veríssimo
131
Key Distribution Centers (KDCs)
© 2008 Paulo Veríssimo
132
Key Distribution Centers (KDCs)
• symmetric crypto requires the distribution of one key
per pair of participants, i.e. (n(n-1)/2) keys are need
• not scalable, not workable in open systems
• KDC- a mediator which all trust
– shares a long-term key with every participant (n keys only)
– helped by the long term keys, KDC establishes a protocol with
each pair of participants wishing to interact, and supplies them
with a secret shared session key, under the protection of a
credential
– KDCs, contrary to CAs, must always be on-line
• vulnerabilities:
– a single point of failure and/or intrusion
– a potential performance bottleneck
© 2008 Paulo Veríssimo
133
Basic asymmetric key distribution methods
• Example 1:
– Alice and Bob exchange their public keys and then start
session
– using asymmetric crypto, or exchanging a session key with
methods seen
• Example 2:
– Alice and Bob execute Diffie-Hellman , get Kss, and then start
session
Can you see problems?
Man-in-the-middle attack
© 2008 Paulo Veríssimo
134
Basic asymmetric key distribution methods
(naive protocols)
• SOLUTIONS
– certify each other’s public keys in some means (e.g.,
certificates)
– sign crucial interactions, like DH numbers
© 2008 Paulo Veríssimo
135
Asymmetric key distribution
(Signed Diffie-Hellman - SDH)
• OBJECTIVE:
– distribute secret session key Kss with DH, between A and B
– signed interactions prevent M-in-M attack!
• notation :
– A has private/ public key pair Kra and Kua, generates DH number Ya
– B also has private/ public key pair Krb e Kub, generates DH number
Yb
© 2008 Paulo Veríssimo
136
Asymmetric key distribution
(Needham-Schroeder Public-key - NSPK)
• OBJECTIVE:
– distribute secret session key Kss with pub-key crypto, between A and B
– encrypted interactions prevent M-in-M attack!
• notation :
– A has private/ public key pair Kra and Kua, generates random nonce Xa
– B also has private/ public key pair Krb e Kub, generates random nonce Xb
1.
AB
Eb(A,Xa)
2.
BA
Ea(B, Xa, Xb)
3.
AB
Eb(Xb)
4.
A, B
mutually trust
5.
A, B
Kss = XOR (Xa,Xb)
AB
E Kss(msg)
AB
E Kss(msg)
© 2008 Paulo Veríssimo
137
Architectural Protection
• topology (bridges, switches, placement)
• firewalls
• intrusion detection systems
© 2008 Paulo Veríssimo
Protection by Network Topology
flat vs. subnetting
Outside
Network
(e.g. Internet)
Server
Server
Router
Server
FLAT
Inside Network
• exposes whole infrastructure to an intruder that penetrates past
the organization's entry router
© 2008 Paulo Veríssimo
139
Protection by Network Topology
flat vs. subnetting
External
Network
(e.g. Internet)
SUBNET
Dept .
Server
Faculty
Server
Internal Network 1
Router
Laboratory
Server
Internal Network 2
• traffic is diverted at the router to the appropriate subnet
• division should be made according to risk analysis, e.g.:
– notion of a more exposed laboratory environment (Internal Network
2)
– versus the rest of the system (Internal Network 1)
© 2008 Paulo Veríssimo
140
Protection by Network Topology
flat vs. subnetting
• subnetting is a primary form of error containment:
– intrusion in one subnet does not imply immediate intrusion in
whole system
• subnetting also provides for primary countermeasures:
– traffic may be easily blocked to/from specific networks,
without affecting the operation of the whole organization
© 2008 Paulo Veríssimo
141
Protection by Network Topology
bridging and switching
Dept .
Server
Admin
WS
External
Network
(e.g. Internet)
Faculty
Server
switch (VLAN)
Laboratory
Server
Critical Network
BRIDGE
or link-level
Router
Bridge
Internal Network 1
Internal Network 2
• by placing sensitive services and system admin. workstations in
the Critical Network past the bridge, we neutralized sniffing
attacks
• structured cabling such as switched Ethernet further renders
sniffing ineffective, since it restricts the broadcasting ability of
the medium
© 2008 Paulo Veríssimo
142
Protection by Firewall
filters and proxies
• Firewall is a set of components located between two
physical or virtual networks
• firewalls must obey the following fundamental design
principles:
– all in- and out-bound traffic must go through the firewall
– only authorised traffic must be able to go through
– firewall hosts are trusted computing bases
filters
External
Network
filters
Firewall
Internal
Network
© 2008 Paulo Veríssimo
143
Firewall architectures
single-level or screened-host
External
Network
single-level firewall, ou
screened-host firewall
(e.g. Internet)
Server
Server
Firewall Server
Internal Network
• the firewall comprises router and bastion in a dual-homed host
• all traffic is inspected by the bastion
© 2008 Paulo Veríssimo
144
Firewall architectures
single-level or screened-host
• variation: bastion stands single-homed in internal
network and acts as IP gateway:
– Internet -> router -> bastion -> internal host, and vice-versa
• one problem with single-level firewall :
– places all hosts in the internal network at the same level of
threat.
– organization have services operating under different exposure
scenarios
© 2008 Paulo Veríssimo
145
Firewall architectures
two-level or screened subnet
External
Network
Server
Inner
Firewall
(e.g. Internet)
Proxies
two-level firewall, ou
screened-subnet firewall
Outer
Firewall
Router
Server
Packet
Filter
System
(PFS)
Internal Network
•
Server
De-militarized Zone (DMZ)
outer firewall normally also outside router of organization
– normally performs simple filtering functions
•
inner firewall is a dual-homed host
– more elaborate functions, e.g. proxying internal protocols or applications.
•
de-militarized zone (DMZ) between inner and outer firewalls
– subnet providing intermediate protection zone
© 2008 Paulo Veríssimo
146
Firewall architectures
two-level or screened subnet
• de-militarized zone (DMZ) is a subnet between inner
and outer firewalls
– DMZ is the place to locate hosts necessarily subjected to high
levels of threat, with service proxies
– e.g., anonymous public FTP, Web, directory or commerce
services
– DMZ services can still enjoy some protection from the firewall
system
© 2008 Paulo Veríssimo
147
Firewall architectures
two-level or screened subnet
• outer firewall also useful for dynamic countermeasures:
– can be instructed in real-time by the inner firewall to disable
certain flows considered suspicious or that are attacking
either the inner network hosts, or the DMZ hosts
• variation: bastion stands in the DMZ, as gateway for
all traffic between external and internal networks
© 2008 Paulo Veríssimo
148
Packet Filter System
Packet Filters
the traffic flow passes through the firewall to end services in the
internal network, content being inspected by filters on go-no-go basis
origin,dest,type,dir,subnet
– use examples:
• blocking packets originating in
suspicious machine
• blocking telnet connections coming
from the outside
• enumerate precisely which
machines are authorised to get
email form outside
• blocking of ports directly used by
X11 sessions (e.g., only allow
forwarding)
Packet Filter
System
Network
Protocol
Network
Protocol
(e.g.TCP/IP)
(e.g.TCP/IP)
External Network
Internal Network
© 2008 Paulo Veríssimo
149
Packet Filter System
• a list of rules allow or block packets through the filter
in either direction:
– <action, origin, destination, type, direction, interface >
• where:
– action is either allow or block/deny;
– origin is a complete source Id, for example TCP/IP
address/port, or a subnet address/mask;
– destination is the same, for a destination Id;
– type when available is the type of packet, which often
corresponds to a given protocol;
– direction is one of inbound or outbound;
– interface is the network card, represents the subnet from/to
which the packet comes/goes
© 2008 Paulo Veríssimo
150
Packet Filter System
• OPERATION:
• the headers of all incoming and outgoing packets are
scrutinized against the contents of the list
• the rules are applied in order
• a packet is accepted immediately an “allow“ rule
becomes true
• or rejected if a “block" rule becomes true
• direction and interface parameters foil address
spoofing attacks, such as a packet arriving from
external interface, with an internal network address
© 2008 Paulo Veríssimo
151
Packet Filter System
• implementing a prudent network security policy:
– using allow statements to specifically permit the desired
traffic flows
– blocking everything by default as the last rule
• implementing a permissive security network policy:
– using block statements to prevent undesired flows
– allowing everything by default in the end
• remember:
– no policy is good or bad
– depends on how it matches both the threat model and the
user requirements
– the more strict, the less user friendly
© 2008 Paulo Veríssimo
152
Packet Filter System
example rule set
• filter out the offending packets as soon as possible
• we are letting outsiders call us for email (SMTP)
• we let our replies to SMTP go out
© 2008 Paulo Veríssimo
153
Proxies
circuit gateway
Proxies
the traffic flow ends or starts in the firewall, being intercepted and
processed by representatives of end services in the internal network
• reside on the firewall
• also called circuit gateway
• represent applications and protocol
deamons (e.g., ftp or http server),
located deeper in internal network
• proxies interception ability limits
intruder action on the internal network
• since they work at higher abstraction
levels, their semantics can be more
precise and richer
Protocol Proxy (e.g. FTP)
PROXYsrv
PROXYcli
Network
Protocol
Network
Protocol
(e.g.TCP/IP)
(e.g.TCP/IP)
External Network
Internal Network
© 2008 Paulo Veríssimo
154
Proxies
circuit gateway
• proxy filtering mechanism is defined by a set of rules
which may comprise:
– <Id and origin; service and server; access control;
authentication; restrictions; monitoring and audit trail …>
• where:
– Id and origin identify user/invoker;
– service and server identify protocol/appl. service and host;
– access control specifies type of protection (e.g., ACM, ACL);
– authentication specifies auth. method (e.g., password,
signature);
– restrictions specifies optional restrictions (e.g., from IDS);
– monitoring and audit trail specifies optional event logging
© 2008 Paulo Veríssimo
155
Proxies
circuit gateway
• OPERATION:
• users wishing to access such a service are connected to
the proxy server as if it was the server
• proxy client side performs dialogue with real server
• client and server extremities of proxies relay all
traffic back and forth between real client and protocol
server in the internal network
• proxy mechanism is defined by a set of rules
• requests arriving at the proxy are tested against the
rules, and serviced if “allowed" or blocked if “denied"
• state is checked during execution, to ensure it is
carried on correctly
© 2008 Paulo Veríssimo
156
Proxies
application gateway
• application gateways are
application proxy servers which
become the interface to the
clients
• a front-end of an application,
works at a higher level of
abstraction than circuit gateways
• only APPprxycli accesses internal
application server
Application Gateway
APPprxysrv
APPprxycli
Comm's
Protocols
Comm's
Protocols
(e.g. TCP/IP,
HTTP,Telnet)
(e.g. TCP/IP,
HTTP,Telnet)
APPcli
APPsrv
External Network
Internal Network
© 2008 Paulo Veríssimo
157
Proxies
example
• OPERATION:
• can perform logging, validation and filtering functions,
• forward client's request to real application server in
the internal network
• receive reply back and forward to client
• performance benefits besides security:
– application activity is split between the proxy and the real
server
– proxy may even cache data for read-only operation, such as
done by some HTTP proxy servers
© 2008 Paulo Veríssimo
158
Comparison between filters and proxies
FILTERS
PROXIES
inspection
interception
stateless
stateful
data based
data+state based
poor semantics
rich semantics
packet level
protocol/user/service level
content oriented rules
action oriented rules
faster
slower
© 2008 Paulo Veríssimo
159
Network Address Translation
External
Network
Valid network 194.117.21.0
(e.g. Internet)
192.168.1.36
A
194.117.21.02
192.168.1.01
Invalid network 192.168.1.0
•
•
•
•
organization announces valid Internet network– 194.117.21.0
uses invalid network addresses internally – 192.168.1.0/64
ex. host A is given invalid address 192.168.1.36
router between both multiplexes and performs NAT
© 2008 Paulo Veríssimo
160
Network Address Translation
• OPERATION:
• NAT complements filtering to ensure logical separation
and thus introduce some security/privacy
• consists of assigning invalid addresses to the internal
network hosts
• any traffic going in or out has to undergo a translation
of the destination or source address, respectively, at
the firewall router
– controls access of legitimate users to the external network
– and hides the composition of the internal network to intruders
© 2008 Paulo Veríssimo
161
Principles of Intrusion Detection
© 2008 Paulo Veríssimo
Rationale for Intrusion Detection
• a system working correctly has important
characteristics:
– activity of users and processes conform to statistically
predictable patterns
– actions of users and processes do not try to subvert the
security policy or make the system fail
– process executions obeys their specification
• a system not working correctly misses one or more of
the characteristics above
• that abnormal behaviour can be detected: intrusion
detection
© 2008 Paulo Veríssimo
163
Denning’s Model
• Hypothesis: exploiting vulnerabilities requires
abnormal use of normal commands or instructions
• recall the sequence attack – vulnerability - intrusion
– deviation from usual actions
– execution of attack actions
– actions inconsistent with specifications of programs
© 2008 Paulo Veríssimo
164
Goals of IDS
• detect wide variety of intrusions
– related to previously known attacks
– related to previously unknown attacks
• besides requiring knowing about all possible attacks,
requires need to learn/adapt to new attacks
• detect intrusions in timely fashion
– if immediate response is desired, this requires real-time
detection
– otherwise, may suffice to report intrusion minutes or hours
later
© 2008 Paulo Veríssimo
165
Models of Intrusion Detection
• Anomaly detection
– What is usual, is known (“normal behaviour” patterns)
– What is unusual, is bad
• Misuse detection
– What is bad, is known (“attack” patterns or signatures)
– What is not bad, is good
© 2008 Paulo Veríssimo
166
Anomaly Detection
• learns about and builds statistical patterns of the
normal behaviour
• in run time, analyses a set of indicators, and compares
with the expected values;
• reports when computed statistics do not match
expected statistics
• depends on coverage of the “normal behaviour”
definition
• prone to false alarms (irregular behaviour may be
detected as intrusion)
© 2008 Paulo Veríssimo
167
Misuse Modelling
• starts by building a database of attacks, i.e.
– sequences of instructions known to violate the site security
policy or the process specification
– i.e. descriptions of known/potential exploits, grouped into rule
sets
• in run time, determines whether a
– execution profile data matches against any of the rule sets
– if so, a potential attack is found
• depends on coverage of the attack database
• prone to omitted alarms (new exploits will not be
detected)
© 2008 Paulo Veríssimo
168
IDS Architecture
CIDF (Common Intrusion Detection Framework)
•
reference architecture of
intrusion-detection systems:
•
e-box (event generator) gathers
event information for analysis
•
a-box (analysis box) analyses
event information, according to
defined detection rules
•
d-box (database) saves persistent
information for the IDS
•
r-box (response box) acts upon
the results of analysis, e.g., notify
security officer, reconfigure
collection or analysis criteria,
activate response mechanism
Target
Activity
Sensor
Sensor
Sensor
e-box
Event
Event
Event
Analyzer
Analyzer
Analyser
a-box
Event
Event
Event
Database
Database
Database
d-box
r-box
© 2008 Paulo Veríssimo
169
Secure Communication and Distributed
Processing
•
•
•
•
secure modem access
establishing secure channels
secure tunnels
distributed authentication and
authorisation
• secure remote session
• secure client-server with RPC
• secure envelopes and e-mail
© 2008 Paulo Veríssimo
Secure modem access
(techniques)
• protocols supporting modem dial-up connection over
telephone line (leased or switched):
– virtual terminal: not very powerful, interactive terminal session
and little more, but because of that, quite secure for
infrastructure
– serial IP: SLIP (serial line IP) or PPP (point-to-point protocol)
and the secure VPN equivalents Point-to-Point Tunneling
Protocol (PPTP), to be replaced by standard Layer 2 Tunneling
Protocol (L2TP) or IPSec
– serial IP emulates an IP connection over the telephone line,
allowing virtually all services available on an Internet
connection (NFS, WWW, FTP, etc.)
© 2008 Paulo Veríssimo
171
Secure modem access
(security)
• dial-up offers a feeling of security because of being
PSTN line
– in open systems we need an authentication front-end anyway
(who’s calling?)
– phreakers can phone from a compromised PPCA, stealing
identity and possible privilege if you do address (phone nr.)
based authentication
• some techniques:
– dial-up authentication (password, strong)
– call-back
© 2008 Paulo Veríssimo
172
Secure modem access
(authentication)
• dial-up connection process
– user dials remote service, and connects with modem front-end
– front-end server has authentication daemon that requests the
authentication, client replies, server validates
– if OK, front-end server establishes IP connection
– normally, the IP related login (telnet, ftp, domain, etc.) follows
• authentication
– user ; password; phone number?
– password or strong authentication (challenge-based, cryptographic)
– e.g. password sent encrypted over the line, by a shared secret key
• call-back
– validates phone number: front-end requests user phone number
– server hangs-up, then redials to phone number given or stored
© 2008 Paulo Veríssimo
173
On establishing secure channels
• Authenticity
– principals should start by authenticating themselves
– mutual authentication should be mandatory if the channel is
bi-directional
– if asymmetric cryptography is available, one has the power of
signature-based authentication
– if exchanging a large number of messages with low latency, use
short-term key exchange protocols embedded with
authentication, and get session key Kss for free
– ensure that the recipient knows something about the partial
content (e.g., headers) or about the structure of messages
© 2008 Paulo Veríssimo
174
On establishing secure channels
• Confidentiality
– channel using exclusively asymmetric cryptography is not
recommended for immediate communication, since it is very
slow
– practical secure channels use: purely symmetric cryptography;
hybrid cryptography
– with hybrid cryptography, principals start with using their
public/private key pairs to protect exchange of a session key
© 2008 Paulo Veríssimo
175
On establishing secure channels
• Integrity
– messages must be cryptographically protected in a way that
any modification whatsoever (accidental or intentional) is
detected
– integrity protection can be achieved in one of two ways:
message integrity check (MIC); digital signature
– the recipient has to know what it expects after decryption or
verification
– integrity might be protected by encryption, but the method is
not general, since it requires a modified message to always
decrypt to garbage, and this is not always achievable
© 2008 Paulo Veríssimo
176
Secure tunnels
• Secure packet
– data are encrypted and
encapsulated
Header t
• IP-over-IP (tunnel)
– an IP packet (payload) is
encapsulated inside another
(carrier) IP packet
Data p
Payload Data
"#$%43543fg88==?"!|*+ªºfdgº657kji
Encrypted
Payload Data
Data t
Packet
(a)
Header p
Data p
Payload Packet
Header t
Data t
Carrier Packet
(b)
• Secure Tunnel
Header p
– by combining both
techniques
Header t
Data p
Payload Packet
"#$%43543fg88==?"!|*+ªºfdgº657kji
Encrypted
Payload Packet
Data t
Carrier Packet
(c)
© 2008 Paulo Veríssimo
177
Secure tunnels
• Tunnel (between A and C through B):
– whole payload packet circulating in network A, encapsulated in
a carrier packet sent through network B until network C
– at C carrier packet is de-capsulated and payload packet
circulates again in C until the final destination
– usual technique, IP-over-IP: encapsulating a full IP datagram
as data, in another IP datagram
© 2008 Paulo Veríssimo
178
Secure tunnels
• Secure packet
– data are encrypted and
encapsulated
Header t
• IP-over-IP (tunnel)
– an IP packet (payload) is
encapsulated inside another
(carrier) IP packet
Data p
Payload Data
"#$%43543fg88==?"!|*+ªºfdgº657kji
Encrypted
Payload Data
Data t
Packet
(a)
Header p
Data p
Payload Packet
Header t
Data t
Carrier Packet
(b)
• Secure Tunnel
Header p
– by combining both
techniques
Header t
Data p
Payload Packet
"#$%43543fg88==?"!|*+ªºfdgº657kji
Encrypted
Payload Packet
Data t
Carrier Packet
(c)
© 2008 Paulo Veríssimo
179
Secure tunnels
• Secure Tunnel:
– a tunnel that guarantees the properties of a secure channel
– usual technique:
– payload packet treated as a block of data, encrypted and/or
integrity protected;
– result treated as data and encapsulated in the carrier packet;
– at destination, operations repeated in reverse order
© 2008 Paulo Veríssimo
180
Secure tunnels
• Secure packet
– data are encrypted and
encapsulated
Header t
• IP-over-IP (tunnel)
– an IP packet (payload) is
encapsulated inside another
(carrier) IP packet
Data p
Payload Data
"#$%43543fg88==?"!|*+ªºfdgº657kji
Encrypted
Payload Data
Data t
Packet
(a)
Header p
Data p
Payload Packet
Header t
Data t
Carrier Packet
(b)
• Secure Tunnel
Header p
– by combining both
techniques
Header t
Data p
Payload Packet
"#$%43543fg88==?"!|*+ªºfdgº657kji
Encrypted
Payload Packet
Data t
Carrier Packet
(c)
© 2008 Paulo Veríssimo
181
Distributed Authentication and Authorisation
© 2008 Paulo Veríssimo
182
Distributed Authentication and Authorisation
(a protocol)
• AT authentication service, AC authorization or access control
service, often co-located in the same server
© 2008 Paulo Veríssimo
183
Insecure vs. Secure Remote Session
Cleartext remote session
– 1. bind to remote host socket
– 2. establish low level network
connection between hosts
– 3. communication starts
– 4. perform cleartext remote
login authentication with
traditional mechanisms
(password)
– 5. start session, also in cleartext
Encrypted remote session
– 1. bind and authenticate to
remote socket
– 2. establish low level secure
channel between hosts
– 3. encrypted communication
starts
– 4. perform remote login
authentication, either with
traditional mechanisms
(password) protected by secure
channel, or cryptographic
– 5. start session, either in
cleartext or encrypted
© 2008 Paulo Veríssimo
184
Secure Remote Session
Session
Server
(deamon)
Remote
Session
Client
@#%*§
??????
3- session communication
2- session authentication
1- inter-host secure channel
Host A
Sniffer
Host B
• 1. bind and authenticate to remote socket, establish low
level inter-host secure channel
• 2. perform remote login authentication
• 3. start session, either in cleartext or encrypted
© 2008 Paulo Veríssimo
185
Secure client-server with RPC
(preparing for a secure RPC)
Client side:
– 1. client binds to the desired
service/server as usual
– 2. client makes a call to RPC
runtime instructing this is a
secure RPC and specifying
the desired security options:
• type of authentication;
• level of security;
Server side:
– 1. server exports name and
registers security capabilities
with RPC runtime
– 2. server initiates activity,
normally with a login to the
security service
– 3. server checks the security
attributes of each call, and:
• authenticates according to the
chosen type;
• performs access control based on
client's privil. for invoked service
(e.g. ACL)
– 4. if all is OK, service executed
with required security level
© 2008 Paulo Veríssimo
186
Secure client-server with RPC
(RPC Security and Authentication Options)
secure RPC: strong authentication, encryption and protection
server acts as a RM for the secure RPCs by clients, authenticating
and authorizing invoked operation according to security options
Parameter
Options
• Authentication
•
•
•
•
none
name-based (UNIX-like)
shared-secret
signature
• Security
• none
• integrity only
• integrity and confidentiality
© 2008 Paulo Veríssimo
187
Secure Envelopes
• Authenticity
– authenticity of a message in a secure envelope is achieved by
signature with the sender's private key (sign a digest of message)
• Confidentiality
–
–
–
–
when confidentiality is desired, the message must be encrypted
though envelope is deferred comm’s, no point in being inefficient
only use asymmetric encryption for special cases e.g. small msgs
otherwise, hybrid cryptography with symmetric encryption
• Integrity
– digital signature for authenticity or encryption for confidentiality
may guarantee message integrity
– keep in mind the general remarks made earlier concerning this issue
© 2008 Paulo Veríssimo
188
Secure E-mail
• Non-repudiation of sending
– the recipient can prove that a message came from a given
sender, who cannot deny
• Non-repudiation of delivery
– the sender can prove that a message was delivered to a given
recipient, who cannot deny
• Anonymity
– the ability to deliver a message without revealing the identity
of the sender
• Time-stamping
– delivered messages can be totally ordered, even if a posteriori
© 2008 Paulo Veríssimo
189
© 2008 Paulo Veríssimo
190
Secure Systems
And
Platforms
Chapter 4
© 2008 Paulo Veríssimo
191
SSL - Secure Sockets Layer
© 2008 Paulo Veríssimo
192
Secure Remote Access:
SSL - Secure Sockets Layer
© 2008 Paulo Veríssimo
193
SSL - Secure Sockets Layer
(A brief history…)
• SSLv2 deployed by Netscape (1995)
• Microsoft made improvements and created an
incompatible version, PCT (Private Comm’s Tech.)
• Netscape deployed SSLv3
– Most commonly deployed today!!!
– E.g., Netscape Navigator and MS Internet Explorer
• IETF introduced TLS, Transport Layer Security
– RFC 2246, uses stuff unemcumbered by patent restrictions
– Similar to SSLv2 and PCT, but incompatible…
• freeware effort by OpenSSL
– started by SSLeay implementation of SSL 3.0
– Currently incorporated in the Apache HTTP server
• we are going to provide a generic introduction of SSL
© 2008 Paulo Veríssimo
194
SSL - Secure Sockets Layer
(functionality)
• anonymous, unilateral or mutual client/server
authentication, with digital certificates if supported
• data compression
• communication encryption via symmetric crypto
• message integrity via authentication codes (MAC)
© 2008 Paulo Veríssimo
195
Encryption mechanisms
• functionalities:
– communication -- runs on top of TCP, in user-level process
– authentication -- RSA, supports CAs
– confidentiality -- DES or RC4 128bit (40bit dur. crypto export
laws)
– integrity, MACs -- SHA, MD5
• some supported algorithms
– block ciphers (in CBC mode)
• RC2_40, DES_40, DES_56, 3DES_168, IDEA_128, Fortezza_80
– stream ciphers
• RC4_40, RC4_128
• if a block cipher is used, padding is applied
– last byte of the padding is the padding length
© 2008 Paulo Veríssimo
196
SSL components
• SSL Handshake Protocol
– negotiation of security algorithms and parameters
– can support digital certificates
– performs key exchange
– performs authentication: server and optionally client
(anonymous, unilateral or mutual)
© 2008 Paulo Veríssimo
197
SSL components
• SSL Record Protocol
– performs the secure communication
– fragmentation, compression, and encryption
– message authentication and integrity protection
– encapsulates upper layer protocols, ex. HTTP, Telnet, FTP
– runs over TCP/IP or other transport
– establishes low-level (socket) inter-host channel
© 2008 Paulo Veríssimo
198
SSL components
• SSL Alert Protocol
– error messages (fatal alerts and warnings)
• SSL Change Cipher Spec Protocol
– a single message that indicates the end of the SSL handshake
© 2008 Paulo Veríssimo
199
SSL architecture
SSL
Handshake
Protocol
SSL Change
Cipher Spec
Protocol
SSL
Alert
Protocol
applications
(e.g., HTTP)
SSL Record Protocol
TCP
IP
© 2008 Paulo Veríssimo
200
Basic protocol flow
• client A sends “hello”, supported crypto, and nonce RA
• server B sends a certificate, selects crypto, and sends
nonce RB
• A chooses a random S, pre-master-secret, and
encrypts S with B’s public key
• A/B derive key(s) from RA, RB, S
© 2008 Paulo Veríssimo
201
Basic flow, continued…
• they each authenticate the initial handshake using the
shared key(s)
• the keys are used to encrypt/authenticate all
subsequent communication
– Separate keys shared for encryption and authentication in
each direction
– Also for IVs… (but this is a flaw!)
– Sequence numbers used to prevent replay
© 2008 Paulo Veríssimo
202
SSL – Handshake Protocol
© 2008 Paulo Veríssimo
Handshake Protocol in action
• HP initiates a session, performing negotiation,
authentication and session key exchange
• negotiation (10-11):
• client and server exchange nonces (C-Random, SRandom),
• negotiate SSL version, session Id,
• and type of cryptography and compression
© 2008 Paulo Veríssimo
204
Handshake Protocol in action
• authentication and key exchange take place (20-22):
• server normally sends its public key certificate (20a)
• alternatively, can send key exchange message (20b)
– happens if it has no certificate, or has a signature-only RSA
certificate, or is doing a plain D-H key exchange
– server then sends additional data to make an ad hoc key exchange
– a set of random bytes or the server's D-H public number
• server may also request a client certificate, if mutual
authentication is desired (21-22)
– client must reply with its certificate, or a no_certificate alert
– in the latter case, server decides whether to continue or abort
• otherwise (21-22 skipped) it is unilateral, only the server
authenticates to the client
© 2008 Paulo Veríssimo
205
Handshake Protocol in action
• at this point, Hello is terminated (23):
– server sends HelloDone
• set up of initial cryptography (30-33):
• client sends a client key exchange message (30)
• depends on previous interactions, can include:
– encrypted pre-master-secret
– client's D-H public number, possibly signed (signed D-H)
– server's RSA signed parameters
• both exchange ChangeCipherSpec messages specifying
type of crypto selected (32)
• finish by exchanging Finished messages (33)
– with all previous handshakes signed to confirm new key
material
© 2008 Paulo Veríssimo
206
Details on
authentication and key exchange
© 2008 Paulo Veríssimo
207
Authentication and key exchange
• specific key exchange depends on which of the supported
key exchange methods is used:
– the authentication mode: anonymous, unilateral or mutual
– the cryptography suite, which may be RSA or Diffie-Hellman
– and whether the previous are either plain or signed
• objective: client and server both obtain pre-master-secret
• client and server compute master-secret, as a function of:
C-Random, S-Random, pre-master-secret
• client and server further compute MAC keys, encryption
keys and Init vectors, as a function of: master-secret, CRandom, S-Random
© 2008 Paulo Veríssimo
Supported key exchange methods
• RSA based
– the secret key (pre-master secret) is generated by client and sent
encrypted with the server’s public RSA key
• fixed Diffie-Hellman
– the server has fixed D-H parameters (public nrs) contained in a
certificate signed by a CA, sent to client
• ephemeral Diffie-Hellman
– both the server and the client generate one-time D-H parameters
– the server signs its DH parameters with its private RSA or DSS key
• anonymous Diffie-Hellman
– both S and C generate one-time D-H parameters, w/o authentication
– prone to man-in-the-middle attacks
• Fortezza
– Fortezza proprietary key exchange scheme
© 2008 Paulo Veríssimo
209
SSL H-S – key exchange detail
(RSA)
client
server
client_hello
-- with C-random
server_hello
-- with S-random
sender_certificate
server_key_exchange
-- with server RSA or DSS public signature key
-- not sent
certificate_request
server_hello_done
client_certificate
client_key_exchange
certificate_verify
CRYPTO COMPUTATIONS
change_cipher_spec
finished
change_cipher_spec
finished
-- not sent
-- with client-generated encrypted pre-master-secret
-- not sent
-- master secret, encryption keys, MAC secrets, IVs
-- confirming crypto to be used
-- with all previous handshakes signed with new keys
-- confirming crypto to be used
-- with all previous handshakes signed with new keys
© 2008 Paulo Veríssimo
210
SSL H-S – key exchange detail
(ephemeral DH / no client authentication)
client
server
client_hello
-- with C-random
server_hello
-- with S-random
sender_certificate
-- with server RSA or DSS public signature key
server_key_exchange
-- with signed one-time DH parameters: m, n, ys
certificate_request
server_hello_done
client_certificate
client_key_exchange
certificate_verify
CRYPTO COMPUTATIONS
change_cipher_spec
finished
change_cipher_spec
finished
-- not sent
-- with client one-time DH public value, yc
-- not sent
-- master secret, encryption keys, MAC secrets, IVs
-- confirming crypto to be used
-- with all previous handshakes signed with new keys
-- confirming crypto to be used
-- with all previous handshakes signed with new keys
© 2008 Paulo Veríssimo
211
Cryptographic computations
• pre-master-secret (48 octets)
– if key exchange is RSA based
• generated by the client, pre_master_secret = 48octet random, 384 bits
• sent to the server encrypted with the server’s public RSA key
– if key exchange is D-H based
• computed in parallel by C, S, pre_master_secret = mxaxb MOD n
• master secret (48 octets)
– combined MD5/SHA hash of C-random, S-random, pre-master-secret
– repeated 3 times with modifiers and concatenated (128bitx3)
• key block - keys, MAC secrets, IVs (384 bits)
– combined MD5/SHA hash of C-random, S-random, master-secret
– repeated 3 times with modifiers and concatenated
– 6 keys/secrets: client and server write MAC secrets, client and server
write (encryption) keys, client and server initialization vectors
© 2008 Paulo Veríssimo
212
SSL Handshake Protocol – timeline
client
server
client_hello
server_hello
Phase 1: Negotiation of the session ID, key exchange
algorithm, MAC algorithm, encryption algorithm, and
exchange of initial random numbers
certificate
server_key_exchange
certificate_request
Phase 2: Server may send its certificate and key
exchange message, and it may request the client
to send a certificate. Server signals end of hello
phase.
server_hello_done
certificate
client_key_exchange
certificate_verify
Phase 3: Client sends certificate if requested and may
send an explicit certificate verification message.
Client always sends its key exchange message.
change_cipher_spec
finished
Phase 4: Change cipher spec and finish handshake
change_cipher_spec
finished
© 2008 Paulo Veríssimo
213
SSL Record protocol
© 2008 Paulo Veríssimo
Sessions and connections
• SSL session - association between client and a server
• sessions are stateful; the session state includes
security algorithms and parameters
• a session may include multiple secure connections
between the same client and server
• connections of the same session share the session
state
• sessions are used to avoid expensive negotiation of
new security parameters for each connection
– there may be multiple simultaneous sessions between the same
two parties, but this feature is not used in practice
© 2008 Paulo Veríssimo
215
SSL Record Protocol – processing
application data
fragmentation
SSLPlaintext
type
version
length
compression
SSLCompressed
type
version
length
msg MAC authentication and
encryption (with padding if necessary)
SSLCiphertext
type
version
length
MAC padding
© 2008 Paulo Veríssimo
216
SSL Alert Protocol
• each alert message consists of 2 fields (bytes)
• first field (byte): “warning” or “fatal”
• second field (byte):
– fatal alerts
• unexpected_message, bad_record_MAC, decompression_failure,
handshake_failure, illegal_parameter
– warning alerts
• close_notify, no_certificate, bad_certificate, unsupported_certificate,
certificate_revoked, certificate_expired, certificate_unknown
• in case of a fatal alert
– connection is terminated
– session ID is invalidated  no new connection can be
established within this session
© 2008 Paulo Veríssimo
217
Session resumption
• Because it was designed with http traffic in mind, one
“session” can be used to derive many secure
“connections”
– Server assigns a session_id and stores that along with the
master secret key; sends session_id to client during
handshake protocol
– “Connection keys” can be derived from the master key
(assumes the client remembers it) and fresh nonces
– Can always re-derive a master key (expensive!)
© 2008 Paulo Veríssimo
218
Secure Remote Access:
SSH
© 2008 Paulo Veríssimo
219
What is SSH?
• SSH – Secure Shell
• SSH is a protocol for secure remote sessions and
other secure network services over an insecure
network
• developed by SSH Communications Security Corp.,
Finland
• two distributions are available:
– commercial version
– freeware (www.openssh.com)
• specified in a set of Internet drafts
© 2008 Paulo Veríssimo
220
SSH - Secure Shell
(overview)
• main characteristics:
–
–
–
–
plugs classical holes in Internet/UNIX based protocols
supports several encryption and authentication mechanisms
protects login and authentication
integrity protects, compresses and encrypts session (e.g.,
DES, 3DES, AES, IDEA, MD5)
• authentication is modular:
– server (host), service (application) and client authentication
• supports three authentication styles:
– traditional address-based (.rhosts, /etc/hosts.equiv)
– UNIX password protected by the secure channel
– traditional enhanced with RSA or pure RSA
© 2008 Paulo Veríssimo
SSH - Secure Shell
(overview)
• key distribution is also versatile:
– manual, automatic or administrator based
– a client-side user authentication agent keeps RSA keys, in
case RSA authent. used
• typical services protected by this package:
– secure remote session (e.g., rlogin or telnet)
– secure remote execution (e.g., rsh)
– secure remote copy (e.g., rcp)
• additional services protected:
– bi-directional TCP/IP port forwarding over the secure
channel, implementing tunneling
– X11 connection tunneling, to secure remote X terminal sessions
© 2008 Paulo Veríssimo
SSH - Secure Shell
(main components)
• SSH Transport Layer Protocol (TLP)
– server authentication, confidentiality
– compression and integrity services
– runs on top of any reliable transport layer (e.g., TCP)
• SSH User Authentication Protocol (UAP)
– provides client-side user authentication
– runs on top of the SSH Transport Layer Protocol
• SSH Connection Protocol
– multiplexes basic secure tunnel provided by TLP and UAP into
several logical channels
– logical channels used for the other services
• secure interactive remote shell sessions (rlogin, rsh, rcp)
• TCP port forwarding
• carrying X11 connections
© 2008 Paulo Veríssimo
223
SSH security features
• strong algorithms
– uses well established strong algorithms for encryption,
integrity, key exchange, and public key management
• large key size
– requires encryption to be used with at least 128 bit keys
– supports larger keys too
• algorithm negotiation for best deal
– encryption, integrity, key exchange, and public key algorithms
are negotiated
– it is easy to switch to some other algorithm without modifying
the base protocol (e.g. evolution to AES)
© 2008 Paulo Veríssimo
224
SSH TLP – Overview
client
server
TCP connection setup
SSH version string exchange
SSH key exchange
(includes algorithm negotiation)
SSH data exchange
termination of the TCP connection
© 2008 Paulo Veríssimo
225
SSH - Secure Shell
(session establishment protocol)
© 2008 Paulo Veríssimo
226
Packet Structure
– packet length:
•
packet length (4)
padding length (1)
payload
(may be compressed)
length of the packet not including the MAC and
the packet length field
– padding length:
•
length of padding
•
•
•
useful contents
might be compressed
max payload size is 32768
•
•
4 – 255 bytes
total length of packet not including the MAC must
be multiple of max(8, cipher block size)
even if a stream cipher is used
– payload:
– random padding:
•
– MAC:
•
•
random padding
MAC
message authentication code
computed over the clear packet and an implicit
sequence number
encryption
compression
© 2008 Paulo Veríssimo
227
SSH – User Authentication Protocol
• the protocol assumes that the underlying transport
protocol provides integrity and confidentiality (e.g., SSH
Transport Layer Protocol)
• the protocol has access to the session ID
• the server should have a timeout for authentication and
disconnect if the authentication has not been accepted
within the timeout period
– recommended value is 10 minutes
• server should limit number of failed authentication
attempts a client may perform in a single session
– recommended value is 20 attempts
• three authentication methods are supported
– publickey, password, hostbased
© 2008 Paulo Veríssimo
228
SSH – Connection Protocol
• provides
–
–
–
–
interactive login sessions
remote execution of commands
forwarded TCP/IP connections
forwarded X11 connections
• all these applications are implemented as “channels”
• all channels are multiplexed into the single encrypted
tunnel provided by the SSH Transport Layer Protocol
• channels are identified by channel numbers at both
ends of the connection
• channel numbers for the same channel at the client
and server sides may differ
© 2008 Paulo Veríssimo
229
SSH – Secure Channels
(e.g. secure remote sessions)
Remote
session
client
Server
(deamons)
© 2008 Paulo Veríssimo
230
SSH – Secure Tunnel (VPN)
Client
applic.
(ex. RPC)
TCP/IP
forward.
Server
applic.
TCP/IP
forward.
© 2008 Paulo Veríssimo
231
SSH – Secure X.11 Terminal
•
•
•
X11 protected by forwarding X11 connections through a tunnel
applications should not be modified: a fake X server is created on the
SSH server side, such that all connections are locally addressed to this
fake server
they are then tunneled and delivered to the real remote X server
Xterm
Xserver
Server
(deamons)
Fake
Xserver
© 2008 Paulo Veríssimo
232
Network Layer Security:
IPSec
© 2008 Paulo Veríssimo
233
IPsec -- IP Security Architecture
• IPSec is an Internet standard for network layer
security
• IPsec (RFC2401/02/06) provides cryptographic
security for the IP protocol
• features: connectionless integrity, data origin
authentication, protection against replays,
confidentiality, and limited traffic flow confidentiality
• Nodes: hosts, IPsec-enabled routers or firewalls
(security gateways)
© 2008 Paulo Veríssimo
234
IPsec overview
• components:
– Authentication Header (AH) - an authentication protocol
– Encapsulated Security Payload (ESP) - a combined encryption
and authentication protocol
– security association
– key management
• IPsec properties are secured for armoured data
blocks, defined by security headers (AH, ESP) that
encapsulate the attached data
• IPSec is mandatory for IPv6 and optional for IPv4
© 2008 Paulo Veríssimo
235
IPsec Headers
• IPsec security functions are implemented around two
extension headers and respective protocols:
• Authentication Header (AH)
– provides connectionless integrity, data origin authentication,
and protection against replays
• Encapsulating Security Payload (ESP)
– provides confidentiality by encryption, and limited traffic flow
confidentiality
– may also provide the functions of AH
• IPsec headers can be combined with one another and
with regular IP headers.
© 2008 Paulo Veríssimo
236
Authentication Header (AH)
• AH protects the integrity of a block of data, except
for the fields to be changed en-route
• AH includes:
– Security Parameter Index (SPI)- field with security
information for the receiver
– Authentication field, has arbitrary length and depends on the
algorithm being used (essentially the cryptographic checksum
signature)
© 2008 Paulo Veríssimo
237
Encapsulating Security Payload (ESP)
• ESP protects the confidentiality of a block of data
• optionally, ESP can protect the integrity of the block
of data
• ESP includes the SPI and the transformed data,
according to the algorithm used
© 2008 Paulo Veríssimo
238
IPsec modes
• IPsec (AH or ESP) can be used in two modes:
– transport-mode, corresponds to the secure channel concept
– tunnel-mode, corresponds to the tunnel concept
• Transport-mode
– the protected data are upper layer service data units
– encapsulates data from the layer above (>TCP) with one of the IPsec
headers, and then encapsulates it again in a normal IP datagram,
achieving end-to-end security
• Tunnel-mode
– protects full IP datagrams
– builds a complete IPsec datagram, and then encapsulates it in a
normal IP datagram
– this IPsec-over-IP mode is useful for building tunnels, and for
bypassing network areas that do not implement IPsec, achieving link
security
© 2008 Paulo Veríssimo
239
IPsec modes
(contd.)
• transport mode
– provides essentially end-to-end protection, usually between
end-systems (hosts)
– protection is applied to the payload of the IP packet
– AH in transport mode authenticates the IP payload and
selected fields of the IP header
– ESP in transport mode encrypts and optionally authenticates
the IP payload but not the IP header
© 2008 Paulo Veríssimo
240
IPsec modes
(contd.)
• tunnel mode
– provides protection to the entire flow of data between
facilities, usually between security gateways (routers,
firewalls), or from host to gateway
– the entire IP packet is considered as payload and encapsulated
in another IP packet (with potentially different source and
destination addresses)
– AH in transport mode authenticates the entire inner IP
packet and selected fields of the outer IP header
– ESP in tunnel mode encrypts and optionally authenticates the
entire inner IP packet
© 2008 Paulo Veríssimo
241
IPsec ancillary characteristics
• checksums or signatures in AH ensure datagram
integrity
• spoofing and replay attacks are also avoided by
cryptographic AH checksums by providing reliable
source address and sequencing info on a sliding window
• although IPsec is algorithm-independent, the default
ESP protocol is DES-CBC
• data flow confidentiality can be enforced to a certain
extent with tunnelling, since content of traffic, such
as addresses, is hidden
© 2008 Paulo Veríssimo
242
IPsec service composition
– Headers combined to achieve further protection
• Transport adjacency:
• in transport mode, by applying ESP encryption for
confidentiality of upper layer data, and then
encapsulating again with AH for MAC-based integrity
and authentication of the final IP packet
• this does authentication after encryption
• Comments?
• “signing after encrypting has its risks...”
• encryption after authentication can be done by
combining an inner AH transport with an outer ESP
tunnel
© 2008 Paulo Veríssimo
243
IPsec service composition
(contd.)
– Headers combined to achieve further protection
• Iterated tunnelling:
• concerns building tunnels inside tunnels
• example: specific tunnels, say ESP protected, are built
from host to host to serve different applications in an
organisation
• when these tunnels connect different intranets they
go, AH protected, through an outer, main tunnel,
carrying all the traffic from one intranet to the other
intranet across the Internet
© 2008 Paulo Veríssimo
244
IPsec bootstrap functions
• IPsec must bootstrap through two crucial functions:
• Security association
– negotiation of protocols, ciphers and keys to be used
• Key distribution
– exchange of the keys needed for communication
© 2008 Paulo Veríssimo
245
IPsec Security Association (SA)
• an SA is a crypto-protected connection
• the security association negotiation produces a number
of parameters characterising the SA:
– authentication and encryption algorithms;
– authentication and encryption keys;
– key and association lifetime
• and the Security Parameter Index (SPI), which allows
to look-up a given SA at the receiver end
• an SA is a one-way relationship between a sender and a
receiver system
– One SA in each direction…
• an SA is used either for AH or for ESP but never for
both
© 2008 Paulo Veríssimo
246
IPsec Security Association (SA)
• a security association is uniquely identified by a triple
consisting of:
– Security Parameters Index (SPI)
• a bit string assigned to the SA
• carried in AH and ESP headers to allow the receiver to look up the SA
parameters which must be used to process the packet
– IP destination address
• address of a host or a network component (e.g., router)
– security option (AH or ESP) identifier
• indicates whether the SA is AH or ESP
© 2008 Paulo Veríssimo
247
Authentication Header (AH)
• provides support for data integrity & authentication of
IP packets
– end system/router can authenticate user/app
– prevents replay attack by tracking sequence numbers
• based on use of a MAC
– HMAC-MD5-96 or HMAC-SHA-1-96
• parties must share a secret key
© 2008 Paulo Veríssimo
248
Authentication Header
© 2008 Paulo Veríssimo
249
AH - transport and tunnel mode
original IPv4 packet
original
IP header
TCP/UDP
header
data
AH in transport mode
original
IP header
AH
TCP/UDP
header
data
authenticated except for mutable fields in the IP header
AH in tunnel mode
new
IP header
AH
original
IP header
TCP/UDP
header
data
authenticated except for mutable fields in the outer IP header
© 2008 Paulo Veríssimo
250
Encapsulating Security Payload (ESP)
• provides message content confidentiality
• can optionally provide the same authentication services
as AH
• supports range of ciphers, modes, padding
– incl. DES, Triple-DES, RC5, IDEA, CAST etc
– CBC most common
• for authentication:
– implementations must support HMAC-MD5-96 and HMACSHA1-96
© 2008 Paulo Veríssimo
251
Encapsulating Security Payload
© 2008 Paulo Veríssimo
252
ESP in transport and tunnel mode
original IPv4 packet
original
IP header
TCP/UDP
header
data
ESP in transport mode
original
IP header
ESP
header
TCP/UDP
header
ESP
trailer
data
ESP
MAC
encrypted
authenticated
ESP in tunnel mode
new
IP header
ESP
header
original
IP header
TCP/UDP
header
data
ESP
trailer
ESP
MAC
encrypted
authenticated
© 2008 Paulo Veríssimo
253
© 2008 Paulo Veríssimo
254
Bibliography
Books:
• P. Verissimo and L. Rodrigues: Distributed Systems
for System Architects, Kluwer, 2001.
• C. Kaufman, R. Perlman, and M. Speciner: Network
Security: Private Communication in a Public World,
Second Edition, Prentice Hall
• W. Stallings: Cryptography and Network Security,
(4th Edition), Prentice Hall
• W. R. Cheswick, S. M. Bellovin, and A. D. Rubi: Firewalls
and Internet Security: Repelling the Wily Hacker,
Second Edition, Addison Wesley
© 2008 Paulo Veríssimo
255