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 
Chapter 2 Revision: Security model
email: authors@cdk2.net
This material is made 
available for private study 
Chapter 7:
and for direct use by 
individual teachers. 7.2 Overview of security techniques
It may not be included in any 
product or employed in any 
service without the written 
7.3 Cryptographic algorithms
permission of the authors.
7.4 Digital signatures
Viewing: These slides 
must be viewed in  7.5 Cryptography pragmatics
slide show mode.
7.6 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
result Server

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
m’
Process p 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 Cryptography

Principal A The enemy Principal B

Processp Secure channel Processq

Ownership of secrets:
 Properties
Cryptographic concealment is based on:
Conventional shared crypto keys
 Each process is sure of the identity of the other
Confusion and diffusion
 Data is private and protected against tampering
Public/private key pair
 Protection against repetition 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
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?
  9
*
Scenario 2:
Authenticated communication with a server

Bob is a file server; Sara is an authentication service. Sara shares secret key K A 
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. 
A ticket is an encrypted item containing the identity of the principal 
2. Sara sends a response to Alice. {{Ticket}KB, KAB}KA. It is encrypted in KA 
to whom it is issued and a shared key for a communication session.
and consists of a ticket (to be sent to Bob with each request for file access) 
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…
  10
*
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.
  11
*
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
  12
*
Birthday attack

Birthday paradox
1. Alice prepares two versions M and M' of a contract for Bob. M is favourable 
to Bob and M' is not.
Statistical result: if there are 23 people in a room, the chances are 
2. Alice makes several subtly different versions of both M and M' that are 
even that 2 of them will have the same birthday. 
visually indistinguishable from each other by methods such as adding spaces 
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).
3. 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 2 32 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.
  13
*
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 dates, so that certificates can be revoked.
4. Certifying authority : Bob’s Bank
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
5. Signature: {Digest(field 2 + field 3)} KFpriv
  14
*
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

  15
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: Account number
2. Name: Alice
3. Account: 6262626
4. Certifying authority: Bob’s Bank
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
  16
5. Signature: {Digest(field 2 + 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 
 For more complex object types and user communities, ACLs can become
drwxr­xr­x  gfc22  staff       264 Oct 30 16:57 Acrobat User Data
­rw­r­­r­­  gfc22  unknown       0 Nov  1 09:34 Eudora Folder
very complex
­rw­r­­r­­  gfc22  staff    163945 Oct 24 00:16 Preview of xx.pdf
– Capabilities associated with principals
drwxr­xr­x  gfc22  staff       264 Oct 31 13:09 iTunes
 Like a key
­rw­r­­r­­  gfc22  staff       325 Oct 22 22:59 list of broken apps.rtf
 Format: <resource id, permitted operations, authentication code>
 Must be unforgeable
 Problems: eavesdropping, difficulty of cancellation

  17
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.

  18
*
Delegation

 Consider a server that prints files:

– wasteful to copy the files, should access users' files in situ
– 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.

  19
*
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.

  20
*
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)

plaintext blocks n+3 n+2 n+1 XOR

E(K, M)

ciphertext blocks n-3 n-2 n-1 n

Figure 7.7 Stream cipher

keystream
number E(K, M) buffer
generator n+3 n+2 n+1
XOR

ciphertext
plaintext
stream
stream
  21
*
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.
  22
*
TEA encryption function
Figure 7.8 key 4 x 32 bits
void encrypt(unsigned long k[], unsigned long text[]) { plaintext
unsigned long y = text[0], z = text[1]; and result 2 x 32
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]); 5
z += ((y << 4) + k[2]) ^ (y+sum) ^ ((y >> 5) + k[3]); 6
}
text[0] = y;  text[1] = z; 
}
Exclusive OR
logical shift
 Lines 5 & 6 perform confusion (XOR of shifted text)
and diffusion (shifting and swapping)
  23
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; 
}

  24
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 */
}
}
  25
*
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 kbytes/sec.
A trapdoor provides a (350 MHz PII processor)
secret way into a room. If
Elliptic you're
curve: A recently-developed
inside, the way out method, shorter keys and faster.
is obvious, if you're
Asymmetric
outside,algorithms
you need to are
know~1000 x slower and are therefore not practical for
bulkaencryption, but their other properties make them ideal for key
secret to get in.
distribution and for authentication uses.

See Section 7.3.2 for a description and example of the RSA algorithm.

  26
*
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)

  29
*
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)
  30
*
Digital signatures with public keys
Figure 7.11
M signed doc

H(M) h E(Kpri, h) {h}Kpri

Signing
128 bits M

{h}Kpri D(Kpub,{h}) h'

M
Verifying h = h'?authentic:forged

H(doc) h

  31
 MACs: Low-cost signatures with a shared secret key
Figure 7.12
M
MAC: Message Authentication Code
signed doc
H(M+K) h
Signing

M
K

Signer and verifier

share a secret key K

M
h

H(M+K)
Verifying h = h'?authentic:forged
h'
K
  32
*
Performance of encryption and secure digest algorithms
Figure 7.14 speeds are for a Pentium II processor at 330 MHZ

Algorithm Key size/hash size Extrapolated PRB optimized

(bits) speed  speed
(kbytes/sec.) (kbytes/s)
TEA 128 700 ­
Secret  DES 56 350 7746
key
Triple­DES 112 120 2842
IDEA 128 700 4469

Public RSA 512   7 ­

key RSA 2048  1 ­

Digest MD5 128 1740 62425

SHA 160 750 25162

  33 PRB = Preneel, Rijmen and Bosselaers [Preneel 1998] 
*
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.

  34
*
The Needham–Schroeder secret-key authentication protocol
Weakness: Message 3 might not be fresh ­ and K
Figure 7.15 AB could have been 
compromised in the store of A's computer. Kerberos (next case 
Header Message Notes
study) addresses this by adding a timestamp or a nonce to message 3.
1. A­>S: A, B, NA A requests S to supply a key for communication
with B.
2. S­>A: {NA , B, KAB,  S returns a message encrypted in A’s secret key,
NA is a nonce. Nonces are integers that are added to messages to 
containing a newly generated key KAB and a
{KAB, A}KB}KA ‘ticket’ encrypted in B’s secret key. The nonce NA 
demonstrate the freshness of the transaction. They are generated 
Ticket
demonstrates that the message was sent in response
by the sending process when required, for example by 
to the preceding one. A believes that S sent the
message because only S knows A’s secret key.  
incrementing a counter or by reading the (microsecond resolution) 
A sends the ‘ticket’ to B.
system clock.
3. A­>B: {KAB, A}KB
4. B­>A: {N }K B decrypts the ticket and uses the new key KAB to
B AB encrypt another nonce NB.
5. A­>B: {NB ­ 1}KAB A demonstrates to B that it was the sender of the
previous message by returning an agreed
transformation of NB.
  35
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
  36
*
 System architecture of Kerberos
Figure 7.16 Needham - Schroeder
Kerberos Key Distribution Centre protocol
TGS: Ticket-
granting
service Authentication 1. A­>S: A, B, NA
database
Step A Authen- Ticket-
granting
2. S­>A: {NA , B, KAB, 
tication
1. Request for service T
TGS ticket
service A
{KAB, A}KB}KA
2. TGS 3. A­>B: {KAB, A}KB
ticket
Step B 4. B­>A: {N }K
B AB
3. Request for
server ticket 5. A­>B: {NB ­ 1}KAB
Login Step C
session setup 4. Server ticket
5. Service
Server request
session setup Service
function
Request encrypted with session key
DoOperation
Step A once per login session
Reply encrypted with session key
Step B once per server session

Server Step C once per server transaction

Client

  37
*
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

  38
*
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
  39
 SSL protocol stack
Figure 7.17
changes the
secure channel
to a new spec

negotiates cipher
SSL
suite, exchanges SSL Change SSL Alert
certificates and key Handshake HTTP Telnet
Cipher Spec Protocol
masters protocol

implements the
SSL Record Protocol
secure channel

Transport layer (usually TCP)

Network layer (usually IP)

SSL protocols: Other protocols:

  40
*
 SSL handshake protocol
Figure 7.18
Establish protocol version, session ID,
ClientHello
cipher suite, compression method,
ServerHello exchange random start values

Certificate
Cipher suite Optionally send server certificate and
Certificate Request
request client certificate
Component Description
ServerHelloDone
Example
Key exchange
Client
the method to be used for
Certificate Server
RSA with public­key
Send client certificate response if
method A exchange of a session key
Certificate Verify B certificates
requested
Cipher for data the block or stream cipher to be IDEA
transfer used for data
Change Cipher Spec
Change cipher suite and finish
Message digest for creating message
Finished
SHA
handshake
function authentication codes (MACs)
Change Cipher Spec Includes key master exchange.
Key master is used by both A and B
Finished to generate:
2 session keys 2 MAC keys
KAB MAB
  41 KBA MBA

*
SSL handshake configuration options
Figure 7.19

Component Description Example

Key exchange the method to be used for RSA with public­key
method exchange of a session key certificates
Cipher for data the block or stream cipher to be IDEA
transfer used for data
Message digest for creating message SHA
function authentication codes (MACs)

  42
*
SSL record protocol
Figure 7.20
abcdefghi
Application data
Fragment/combine

Record protocol units abc def ghi

Compress
Compressed units

Hash
MAC
Encrypt

Encrypted
Transmit

TCP packet
  43
*
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.

  44
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

  45