Teaching material
based on Distributed
Systems: Concepts
and Design, Edition 3,
Addison-Wesley 2001.
Distributed Systems Course
Security
Copyright © George
Coulouris, Jean Dollimore,
Tim Kindberg 2001
email: [email protected]
This material is made
available for private study
and for direct use by
individual teachers.
It may not be included in any
product or employed in any
service without the written
permission of the authors.
Viewing: These slides
must be viewed in
slide show mode.
Chapter 2 Revision: Security model
Chapter 7:
7.2
7.3
7.4
7.5
7.6
Overview of security techniques
Cryptographic algorithms
Digital signatures
Cryptography pragmatics
Case studies
Learning objectives
 Security model
– Types of threat
 Basic techniques
– Cryptographic techniques




Secrecy
Authentication
Certificates and credentials
Access control
– Audit trails
 Symmetric and asymmetric encryption algorithms
 Digital signatures
 Approaches to secure system design
 Pragmatics and case studies
2
Chapter 2 Revision: Objects and principals
Figure 2.13
Access rights
Object
invocation
Client
Server
result
Principal (user)
Network
Principal (server)
 Object (or resource)
– Mailbox, system file, part of a commercial web site
 Principal
– User or process that has authority (rights) to perform actions
– Identity of principal is important
3
Chapter 2 Revision: The enemy
Figure 2.14
Copy of m
The enemy
Process p
m’
m
Process q
Communication channel
 Attacks
– On applications that handle financial transactions or other information
whose secrecy or integrity is crucial
 Enemy (or adversary)
 Threats
– To processes, to communication channels, denial of service
4
Chapter 2 Revision: Secure channels
Figure 2.15
PrincipalA
Processp
Cryptography
The enemy
Secure channel
Principal B
Processq
Ownership
of secrets:
 Properties
Cryptographic
concealment is based on:
 Each process is sure of the identity of the other
Conventional
crypto keys
Confusion
andshared
diffusion
 Data is private
and
protected against tampering
 Protection against
Public/private
keyrepetition
pair and reordering of data
 Employs cryptography
 Secrecy based on cryptographic concealment
 Authentication based on proof of ownership of secrets
5
Threats and forms of attack
 Eavesdropping
– obtaining private or secret information
 Masquerading
– assuming the identity of another user/principal
 Message tampering
– altering the content of messages in transit
 man in the middle attack (tampers with the secure channel mechanism)
 Replaying
– storing secure messages and sending them at a later date
 Denial of service
– flooding a channel or other resource, denying access to others
6
Threats not defeated by secure channels
or other cryptographic techniques
 Denial of service attacks
– Deliberately excessive use of resources to the extent that they are not
available to legitimate users
 E.g. the Internet 'IP spoofing' attack, February 2000
 Trojan horses and other viruses
– Viruses can only enter computers when program code is imported.
– But users often require new programs, for example:
 New software installation
 Mobile code downloaded dynamically by existing software (e.g. Java
applets)
 Accidental execution of programs transmitted surreptitiously
– Defences: code authentication (signed code), code validation (type
checking, proof), sandboxing.
7
Security notations
KA
Alice’s secret key
KB
Bob’s secret key
KAB
Secret key shared between Alice and Bob
KApriv
Alice’s private key (known only to Alice)
KApub
Alice’s public key (published by Alice for all to read)
{M}K
Message M encrypted with key K
[M]K
Message M signed with key K
Alice
Bob
Carol
Dave
Eve
Mallory
Sara
First participant
Second participant
Participant in three- and four-party protocols
Participant in four-party protocols
Eavesdropper
Malicious attacker
A server
9
Scenario 1:
Secret communication with a shared secret key
Alice and Bob share a secret key KAB.
1. Alice uses KAB and an agreed encryption function E(KAB, M) to
encrypt and send any number of messages {Mi}KAB to Bob.
2. Bob reads the encrypted messages using the corresponding
decryption function D(KAB, M).
Alice and Bob can go on using KAB as long as it is safe to assume that KAB has not been
compromised.
Issues:
Key distribution: How can Alice send a shared key KAB to Bob securely?
Freshness of communication: How does Bob know that any {Mi} isn’t a copy of
an earlier encrypted message from Alice that was captured by Mallory and
replayed later?
10
*
Scenario 2:
Authenticated communication with a server
Bob is a file server; Sara is an authentication service. Sara shares secret key KA
with Alice and secret key KB with Bob.
1.
Alice sends an (unencrypted) message to Sara stating her identity and
requesting a ticket for access to Bob. 
Sarais
sends
a response toitem
Alice.
{{Ticket}KBthe
, KAB
}KA. It isof
encrypted
in KA to
A2.ticket
an encrypted
containing
identity
the principal
and consists of a ticket (to be sent to Bob with each request for file access)
whom
it is issued and a shared key for a communication session.
encrypted in KB and a new secret key KAB.
3.
Alice uses KA to decrypt the response.
4.
Alice sends Bob a request R to access a file: {Ticket}KB, Alice, R.
5.
The ticket is actually {KAB, Alice}KB. Bob uses KB to decrypt it, checks
that Alice's name matches and then uses KAB to encrypt responses to Alice.

This is a simplified version of the Needham and Schroeder (and Kerberos) protocol.

Timing and replay issues – addressed in N-S and Kerberos.

Not suitable for e-commerce because authentication service doesn't scale…
11
*
Scenario 3:
Authenticated communication with public keys
Bob has a public/private key pair <KBpub, KBpriv>
1. Alice obtains a certificate that was signed by a trusted authority
stating Bob's public key KBpub
2. Alice creates a new shared key KAB , encrypts it using KBpub using a
public-key algorithm and sends the result to Bob.
3. Bob uses the corresponding private key KBpriv to decrypt it.
(If they want to be sure that the message hasn't been tampered with, Alice can add an
agreed value to it and Bob can check it.)
 Mallory might intercept Alice’s initial request to a key
distribution service for Bob’s public-key certificate and send a
response containing his own public key. He can then
intercept all the subsequent messages.
12
*
Scenario 4:
Digital signatures with a secure digest function
Alice wants to publish a document M in such a way that anyone can
verify that it is from her.
1. Alice computes a fixed-length digest of the document Digest(M).
2. Alice encrypts the digest in her private key, appends it to M and
makes the resulting signed document (M, {Digest(M)}KApriv)
available to the intended users.
3. Bob obtains the signed document, extracts M and computes
Digest(M).
4. Bob uses Alice's public key to decrypt {Digest(M)}KApriv and
compares it with his computed digest. If they match, Alice's
signature is verified.
The digest function must be secure against the birthday attack
13
*
Birthday attack
1. Alice prepares
two versions M and M' of a contract for Bob. M is favourable
Birthday
paradox
to Bob result:
and M' isifnot.
Statistical
there are 23 people in a room, the chances are
2. Alice makes several subtly different versions of both M and M' that are
evenvisually
that 2 of
them will have the same birthday.
indistinguishable from each other by methods such as adding spaces
3.
at the ends of lines. She compares the hashes of all the versions of M with all
the versions of M'. (She is likely to find a match because of the Birthday
Paradox).
When she has a pair of documents M and M' that hash to the same value, she
gives the favourable document M to Bob for him to sign with a digital
signature using his private key. When he returns it, she substitutes the
matching unfavourable version M', retaining the signature from M.
– If our hash values are 64 bits long, we require only 232 versions of M
and M’ on average.
– This is too small for comfort. We need to make our hash values at
least 128 bits long to guard against this attack.
14
*
Certificates
Certificate:
a statement
signed
by an appropriate authority.
Figure 7.4 Alice’s
bank account
certificate
Certificates require:
1. Certificate type:
Account number
• An agreed standard format
2. Name:
Alice
• Agreement on the construction
of chains of trust (see Section 7.4.4).
3. Account:
6262626
• Expiry authority
dates, so
certificates
4. Certifying
: thatBob’s
Bank can be revoked.
5. Signature:
{Digest(field 2 + field 3)} KBpriv
Figure 7.5 Public-key certificate for Bob's Bank
1. Certificate type:
Public key
2. Name:
Bob’s Bank
3. Public key:
KBpub
4. Certifying authority:
Fred – The Bankers Federation
{Digest(field 2 + field 3)} KFpriv
5. Signature:
15
*
X509 Certificate format
Figure 7.13
Subject
Distinguished Name, Public Key
Issuer
Distinguished Name, Signature
Period of validity
Not Before Date, Not After Date
Administrative information
Version, Serial Number
Extended Information
16
Certificates as credentials
 Certificates can act as credentials
– Evidence for a principal's right to access a resource
 The two certificates shown in the last slide could act
as credentials
for Alice to operate on her bank account
Figure 7.4 Alice’s bank account certificate
– She would need to add her public key certificate
1. Certificate type:
2. Name:
3. Account:
4. Certifying authority:
5. Signature:
Account number
Alice
6262626
Bob’s Bank
{Digest(field 2 + field 3)} KBpriv
Figure 7.5 Public-key certificate for Bob's Bank
1.
2.
3.
4.
5.
Certificate type:
Name:
Public key:
Certifying authority:
Signature:
Public key
Bob’s Bank
KBpub
Fred – The Bankers Federation
{Digest(field172 + field 3)} KFpriv
*
Access control
 Protection domain
– A set of <resource, rights> pairs
 Two main approaches to implementation:
– Access control list (ACL) associated with each object
 E.g. Unix file access permissions 
drwxr-xr-x
gfc22
staff object264
Oct
30user
16:57
Acrobat User
 For
more complex
types
and
communities,
ACLs Data
can become
-rw-r--r-- very
gfc22
unknown
0 Nov 1 09:34 Eudora Folder
complex
-rw-r--r-- gfc22 staff
163945 Oct 24 00:16 Preview of xx.pdf
–
Capabilities
associated
with
drwxr-xr-x gfc22 staff
264principals
Oct 31 13:09 iTunes
-rw-r--r-gfc22
325 Oct 22 22:59 list of broken apps.rtf
 Like
a keystaff
 Format: <resource id, permitted operations, authentication code>
 Must be unforgeable
 Problems: eavesdropping, difficulty of cancellation
18
Credentials
 Requests to access resources must be
accompanied by credentials:
– Evidence for the requesting principal's right to access the resource
– Simplest case: an identity certificate for the principal, signed by the
principal.
– Credentials can be used in combination. E.g. to send an authenticated
email as a member of Cambridge University, I would need to present a
certificate of membership of CU and a certificate of my email address.
 The “speaks for” idea
– We don't want users to have to give their password every time their
PC accesses a server holding protected resources.
– Instead, the notion that a credential speaks for a principal is
introduced. E.g. a user's PK certificate speaks for that user.
19
*
Delegation
 Consider a server that prints files:
– wasteful to copy the files, should access users' files
– server must be given restricted and temporary rights to access
protected files
 Can use a delegation certificate or a capability
– a delegation certificate is a signed request authorizing another
principal to access a named resource in a restricted manner.
– CORBA Security Service supports delegation certificates.
– a capability is a key allowing the holder to access one or more of the
operations supported by a resource.
– The temporal restriction can be achieved by adding expiry times.
20
*
Cryptographic Algorithms
Message M, key K, published encryption functions E, D
 Symmetric (secret key)
E(K, M) = {M}K
D(K, E(K, M)) = M
Same key for E and D
M must be hard (infeasible) to compute if K is not known.
Usual form of attack is brute-force: try all possible key values for a known pair
M, {M}K. Resisted by making K sufficiently large ~ 128 bits
 Asymmetric (public key)
Separate encryption and decryption keys: Ke, Kd
D(Kd. E(Ke, M)) = M
depends on the use of a trap-door function to make the keys. E has high
computational cost. Very large keys > 512 bits
 Hybrid protocols - used in SSL (now called TLS)
Uses asymmetric crypto to transmit the symmetric key that is then used to
encrypt a session.
21
*
Cipher blocks, chaining and stream ciphers
Most algorithms work on 64-bit blocks.
Weakness of simple block cipher:- repeated patterns can be detected.
Figure 7.6 Cipher block chaining (CBC)
n+3
plaintext blocks
n+2
n+1
XOR
E(K, M)
n-3
ciphertext blocks
n-2
n-1
n
Figure 7.7 Stream cipher
keystream
number
generator
n+3
n+2
n+1
E(K, M)
buffer
XOR
ciphertext
stream
plaintext
stream
22
*
Symmetric encryption algorithms
These are all programs that perform confusion and diffusion operations on blocks of
binary data
TEA: a simple but effective algorithm developed at Cambridge U (1994) for teaching
and explanation. 128-bit key, 700 kbytes/sec
DES: The US Data Encryption Standard (1977). No longer strong in its original form.
56-bit key, 350 kbytes/sec.
Triple-DES: applies DES three times with two different keys. 112-bit key, 120
Kbytes/sec
IDEA: International Data Encryption Algorithm (1990). Resembles TEA. 128-bit key,
700 kbytes/sec
AES: A proposed US Advanced Encryption Standard (1997). 128/256-bit key.
There are many other effective algorithms. See Schneier [1996].
The above speeds are for a Pentium II processor at 330 MHZ. Today's PC's (January 2002)
should achieve a 5 x speedup.
23
*
TEA encryption function
Figure 7.8
void encrypt(unsigned long k[], unsigned long text[]) {
unsigned long y = text[0], z = text[1];
unsigned long delta = 0x9e3779b9, sum = 0; int n;
for (n= 0; n < 32; n++) {
sum += delta;
y += ((z << 4) + k[0]) ^ (z+sum) ^ ((z >> 5) + k[1]);
z += ((y << 4) + k[2]) ^ (y+sum) ^ ((y >> 5) + k[3]);
}
text[0] = y; text[1] = z;
}
Exclusive OR
key 4 x 32 bits
plaintext
and result 2 x 32
5
6
logical shift
 Lines 5 & 6 perform confusion (XOR of shifted text)
and diffusion (shifting and swapping)
24
*
TEA decryption function
Figure 7.9
void decrypt(unsigned long k[], unsigned long text[]) {
unsigned long y = text[0], z = text[1];
unsigned long delta = 0x9e3779b9, sum = delta << 5; int n;
for (n= 0; n < 32; n++) {
z -= ((y << 4) + k[2]) ^ (y + sum) ^ ((y >> 5) + k[3]);
y -= ((z << 4) + k[0]) ^ (z + sum) ^ ((z >> 5) + k[1]);
sum -= delta;
}
text[0] = y; text[1] = z;
}
25
TEA in use
Figure 7.10
void tea(char mode, FILE *infile, FILE *outfile, unsigned long k[]) {
/* mode is ’e’ for encrypt, ’d’ for decrypt, k[] is the key.*/
char ch, Text[8]; int i;
while(!feof(infile)) {
i = fread(Text, 1, 8, infile);
/* read 8 bytes from infile into Text */
if (i <= 0) break;
while (i < 8) { Text[i++] = ' ';}
/* pad last block with spaces */
switch (mode) {
case 'e':
encrypt(k, (unsigned long*) Text); break;
case 'd':
decrypt(k, (unsigned long*) Text); break;
}
fwrite(Text, 1, 8, outfile);
/* write 8 bytes from Text to outfile */
}
}
26
*
Asymmetric encryption algorithms
They all depend on the use of trap-door functions
A trap-door function is a one-way function with a secret exit - e.g. product of two large
numbers; easy to multiply, very hard (infeasible) to factorize.
RSA: The first practical algorithm (Rivest, Shamir and Adelman 1978) and
still the most frequently used. Key length is variable, 512-2048 bits. Speed
1-7 Akbytes/sec.
(350aMHz PII processor)
trapdoor provides
secret way into a room. If
Elliptic you're
curve:inside,
A recently-developed
method, shorter keys and faster.
the way out
is obvious, if you're
Asymmetric
algorithms are ~1000 x slower and are therefore not practical for
outside, you need to know
bulkaencryption,
but their other properties make them ideal for key
secret to get in.
distribution and for authentication uses.
27
*
RSA Encryption - 1
To find a key pair e, d:
1. Choose two large prime numbers, P and Q (each greater than 10100), and form:
N=PxQ
Z = (P–1) x (Q–1)
2. For d choose any number that is relatively prime with Z (that is, such that d has no
common factors with Z).
We illustrate the computations involved using small integer values for P and Q:
P = 13, Q = 17 –> N = 221, Z = 192
d=5
3. To find e solve the equation:
e x d = 1 mod Z
That is, e x d is the smallest element divisible by d in the series Z+1, 2Z+1, 3Z+1, ... .
e x d = 1 mod 192 = 1, 193, 385, ...
385 is divisible by d
e = 385/5 = 77
28
RSA Encryption - 2
To encrypt text using the RSA method, the plaintext is divided into equal blocks of length k
bits where 2k < N (that is, such that the numerical value of a block is always less than N; in
practical applications, k is usually in the range 512 to 1024).
k = 7, since 27 = 128
The function for encrypting a single block of plaintext M is:
E'(e,N,M) = Me mod N
for a message M, the ciphertext is M77 mod 221
The function for decrypting a block of encrypted text c to produce the original plaintext block
is:
D'(d,N,c) = cd mod N
Rivest, Shamir and Adelman proved that E' and D' are mutual inverses
(that is, E'(D'(x)) = D'(E'(x)) = x) for all values of P in the range 0 ≤ P ≤ N.
The two parameters e,N can be regarded as a key for the encryption function, and similarly
d,N represent a key for the decryption function.
So we can write Ke = <e,N> and Kd = <d,N>, and we get the encryption function:
E(Ke, M) ={M}K (the notation here indicating that the encrypted message can be decrypted
only by the holder of the private key Kd) and D(Kd, {M}K ) = M.
29
Digital signatures
Requirement:
– To authenticate stored document files as well as messages
– To protect against forgery
– To prevent the signer from repudiating a signed document (denying their
responsibility)
Encryption of a document in a secret key constitutes a signature
-
impossible for others to perform without knowledge of the key
strong authentication of document
strong protection against forgery
weak against repudiation (signer could claim key was compromised)
30
*
Secure digest functions
- Encrypted text of document makes an impractically long signature
- so we encrypt a secure digest instead
- A secure digest function computes a fixed-length hash H(M) that characterizes
the document M
- H(M) should be:
- fast to compute
- hard to invert - hard to compute M given H(M)
- hard to defeat in any variant of the Birthday Attack
-
MD5: Developed by Rivest (1992). Computes a 128-bit digest. Speed 1740
kbytes/sec.
 SHA: (1995) based on Rivest's MD4 but made more secure by producing a
160-bit digest, speed 750 kbytes/second
 Any symmetric encryption algorithm can be used in CBC (cipher block
chaining) mode. The last block in the chain is H(M)
31
*
Digital signatures with public keys
Figure 7.11
M
signed doc
H(M)
Signing
{h}Kpri
h E(Kpri, h)
M
128 bits
{h}Kpri
Verifying
D(Kpub,{h})
h'
M
h = h'?authentic:forged
H(doc)
32
h
*
MACs: Low-cost signatures with a shared secret key
Figure 7.12
M
MAC: Message Authentication Code
signed doc
h
H(M+K)
Signing
M
K
Signer and verifier
share a secret key K
M
h
H(M+K)
Verifying
h = h'?authentic:forged
h'
K
33
*
Performance of encryption and secure digest algorithms
Figure 7.14
Algorithm
speeds are for a Pentium II processor at 330 MHZ
Key size/hash size
(bits)
Extrapolated PRB optimized
speed
speed
(kbytes/sec.)
(kbytes/s)
TEA
128
700
-
DES
56
350
7746
Triple-DES
112
120
2842
IDEA
128
700
4469
Public
key
RSA
512
7
-
RSA
2048
1
-
Digest
MD5
128
1740
62425
SHA
160
750
25162
Secret
key
PRB = Preneel, Rijmen and Bosselaers [Preneel 1998]
34
*
Case study: Needham - Schroeder protocol
In early distributed systems (1974-84) it was difficult to protect
the servers
– E.g. against masquerading attacks on a file server
– because there was no mechanism for authenticating the origins of requests
– public-key cryptography was not yet available or practical
 computers too slow for trap-door calculations
 RSA algorithm not available until 1978
Needham and Schroeder therefore developed an authentication
and key-distribution protocol for use in a local network
– An early example of the care required to design a safe security protocol
– Introduced several design ideas including the use of nonces.
35
*
The Needham–Schroeder secret-key authentication protocol
Weakness:
Figure
7.15
Message 3 might not be fresh - and KAB could have been
compromised in the store of A's computer. Kerberos (next case study)
Header this
Message
Notes
addresses
by adding a timestamp
or a nonce to message 3.
A requests S to supply a key for communication
with B. that are added to messages to
NA is a nonce. Nonces are integers
returns a message encrypted in A’s secret key,
2. S->A:
{Nthe
KAB,
A , B,freshness
demonstrate
ofScontaining
the transaction.
They are generated
a newly generated key KAB and a
KA ‘ticket’
AB, A}KB}when
byTicket
the sending{Kprocess
required,
forin example
by The nonce NA
encrypted
B’s secret key.
demonstrates
that the
message was sent
in response
incrementing a counter or by
reading
the
(microsecond
resolution)
to the preceding one. A believes that S sent the
system clock.
message because only S knows A’s secret key.
1. A->S:
A, B, NA
3. A->B:
{KAB, A}KB
A sends the ‘ticket’ to B.
4. B->A:
{NB}KAB
5. A->B:
{NB - 1}KAB
B decrypts the ticket and uses the new key KAB to
encrypt another nonce NB.
A demonstrates to B that it was the sender of the
previous message by returning an agreed
transformation of NB.
36
*
Case study: Kerberos authentication and key distribution service
 Secures communication with servers on a local network
– Developed at MIT in the 1980s to provide security across a large
campus network > 5000 users
– based on Needham - Schroeder protocol
 Standardized and now included in many operating systems
– Internet RFC 1510, OSF DCE
– BSD UNIX, Linux, Windows 2000, NT, XP, etc.
– Available from MIT
 Kerberos server creates a shared secret key for any required
server and sends it (encrypted) to the user's computer
 User's password is the initial secret shared with Kerberos
37
*
System architecture of Kerberos
Figure 7.16
TGS: Ticketgranting
service
Needham - Schroeder
protocol
Kerberos Key Distribution Centre
Step A
1. Request for
TGS ticket
Authentication
database
Authentication
service A
1. A->S: A, B, NA
2. S->A: {NA , B, KAB,
{KAB, A}KB}KA
Ticketgranting
service T
3. A->B: {KAB, A}KB
2. TGS
ticket
Login
session setup
Server
session setup
DoOperation
Step B
3. Request for
server ticket
4. Server ticket
4. B->A: {NB}KAB
5. A->B: {NB - 1}KAB
Step C
5. Service
request
Service
function
Request encrypted with session key
Step A once per login session
Reply encrypted with session key
Step B once per server session
Server
Client
38
Step C once per server transaction
*
Kerberized NFS
 Kerberos protocol is too costly to apply on each NFS operation
 Kerberos is used in the mount service:
– to authenticate the user's identity
– User's UserID and GroupID are stored at the server with the client's IP address
 For each file request:
– UserID and GroupID are sent encrypted in the shared session key
– The UserID and GroupID must match those stored at the server
– IP addresses must also match
 This approach has some problems
– can't accommodate multiple users sharing the same client computer
– all remote filestores must be mounted each time a user logs in
39
*
Case study: The Secure Socket Layer (SSL)
 Key distribution and secure channels for internet
commerce
– Hybrid protocol; depends on public-key cryptography
– Originally developed by Netscape Corporation (1994)
– Extended and adopted as an Internet standard with the name Transport
Level Security (TLS)
– Provides the security in all web servers and browsers and in secure
versions of Telnet, FTP and other network applications
 Design requirements
– Secure communication without prior negotation or help from 3rd parties
– Free choice of crypto algorithms by client and server
– communication in each direction can be authenticated, encrypted or both
40
SSL protocol stack
Figure 7.17
changes the
secure channel
to a new spec
negotiates cipher
suite, exchanges
certificates and key
masters
SSL
Handshake
protocol
SSL Change
Cipher Spec
implements the
secure channel
SSL Alert
Protocol
HTTP
Telnet
SSL Record Protocol
Transport layer (usually TCP)
Network layer (usually IP)
SSL protocols:
Other protocols:
41
*
SSL handshake protocol
Figure 7.18
Establish protocol version, session ID,
cipher suite, compression method,
exchange random start values
ClientHello
ServerHello
Cipher suite
Component
Certificate
Optionally send server certificate and
request client certificate
Certificate Request
ServerHelloDone
Description
Example
Key exchange
the method
to be usedServer
for
Certificate
Client
method
exchange
ofVerify
a session key
A
B
Certificate
Cipher for data
transfer
Message digest
function
RSA with public-key
Send client certificate response if
certificates
requested
the block or stream cipher to be
Change
used
for Cipher
data Spec
IDEA
Change cipher suite and finish
handshake
SHA
Finished
for creating message
key master exchange.
Change Cipher Spec
authentication
codes (MACs) Includes
Key master is used by both A and B
to generate:
2 session keys
KAB
KBA
Finished
42
2 MAC keys
MAB
MBA
*
SSL handshake configuration options
Figure 7.19
Component
Description
Example
Key exchange
method
the method to be used for
exchange of a session key
RSA with public-key
certificates
Cipher for data
transfer
the block or stream cipher to be
used for data
IDEA
Message digest
function
for creating message
authentication codes (MACs)
SHA
43
*
SSL record protocol
Figure 7.20
abcdefghi
Application data
Fragment/combine
abc
Record protocol units
def
ghi
Compress
Compressed units
Hash
MAC
Encrypt
Encrypted
Transmit
TCP packet
44
*
Summary
 It is essential to protect the resources, communication
channels and interfaces of distributed systems and
applications against attacks.
 This is achieved by the use of access control mechanisms
and secure channels.
 Public-key and secret-key cryptography provide the basis for
authentication and for secure communication.
 Kerberos and SSL are widely-used system components that
support secure and authenticated communication.
45
*
Worst case assumptions and design guidelines
[p. 260]
 Interfaces are exposed
 Networks are insecure
 Limit the lifetime and scope of each secret
 Algorithms and program code are available to attackers
 Attackers may have access to large resources
 Minimize the trusted base
46