10.

Security

10.1 Overview of security techniques

10.2 Cryptographic algorithms
10.3 Digital signatures
10.4 Cryptography pragmatics
10.5 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
Introduction

 A number of threats to security in distributed

systems exist; all may be addressed by addressing
the following requirements:
– Securing the communication channels
– Empowering servers to verify the identity of clients
– Clients should verify the authenticity of the servers
– Originator of a message should be verifiable

 Security policies must be adopted; to ensure

appropriate levels of security
 Security mechanisms to implement the above
policies
Objects and principals

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
The enemy

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
Secure channels

Cryptography
PrincipalA The enemy Principal B

Processp Secure channel Processq

 Properties
Ownership of secrets:
Cryptographic concealment is based on:
 Each process is sure of the identity of the other
Conventional
Confusion andshared crypto keys
diffusion
 Data is private and protected against tampering
Public/private keyrepetition
 Protection against pair and reordering of data
 Employs cryptography
 Secrecy based on cryptographic concealment
 Authentication based on proof of ownership of secrets
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
Infiltration

 How does the attacker access the system?

– Launched by one of the legitimate users of the system
– Launched by one of the illegitimate users who cracks
passwords
– Other indirect methods:
 Virus – a program that is attached to a legitimate program and
installs itself in the target environment whenever the host program
is run.
 Worm –exploits facilities for running processes remotely in
distributed systems
 Trojan Horse – offered to users as program performing useful
functions but has a hidden negative function hidden in it
What are the differences between a worms and viruses?
Overview of Security Techniques

 Cryptography
– Process of encoding a message in such a way to hide contents
– Uses include:
 Secrecy and Integrity – conceals private information
 Authentication - uses the keys to proof the authenticity of sender/receiver
 Digital signatures – to emulate conventional signatures

 Digital Certificates
– A document containing a statement (usually short) signed by a principal.

 Access Control
– Historically, the protection of resources in distributed system has been largely service-specific
– Request messages to the server <op, principal, resource> - server must authenticate the the request
message and principal’s credentials and the apply access control

 Credentials
– Set of evidence provided by a principal when requesting to access to a resource

 Firewalls
– Introduced to protect intranets, performing filtering actions on incoming and outgoing
communications
Authentication Mechanisms for Distributed Systems

Sender A Secure Communication with Secret-Key encryption

 Takes the form of authentication 1. Acquire K
Reciver B
1. Acquire K
service that relies on the use of 2. f(K,M)->{M}K
2. Receive{M}K
3. Send {M}K
3. f-1(K, {M}K)->M
encryption to guarantee security
 Key distribution service is
required to generate, store and
distribute the encryption keysSender A Secure Communication with Public-Key encryption
Reciver B
 Computer encryption 1. Acquire Ke
1. Compute Ke, Kd
techniques: 2. E(Ke,M)->{M}Ke
3. Send {M}Ke 2. Publish Ke
1. Public key encryption 3. Receive{M}Ke
{M}Ke 4. D(Kd, {M}Ke)->M
2. Secret key encryption
In both, plain text is transformed into Ke

cipher text; the receive deciphers Request Ke Ke

this back to the plain text

Public Key
Database
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?

*
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. 
A2.ticket
Sarais
sends a response toitem
an encrypted Alice. {{Ticket}KBthe
containing , KAB}KA. It isof
identity encrypted in KA to
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.

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

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

*
Certificates

Certificate: a statement
Figure 7.4 Alice’s signed
bank account by an appropriate authority.
certificate
Certificates require:
1. Certificate type: Account number
• An agreed standard format
2. Name: Alice
• Agreement
3. Account : on the construction
6262626 of chains of trust (see Section 7.4.4).
• Expiry authority
4. Certifying dates, so
: thatBob’s
certificates
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
5. Signature: {Digest(field 2 + field 3)} KFpriv

*
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
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
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
very complex
– Capabilities associated with principals
 Like a key
 Format: <resource id, permitted operations, authentication code>
 Must be unforgeable
 Problems: eavesdropping, difficulty of cancellation
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.

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

 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 Transmission Layer Security)

Uses asymmetric crypto to transmit the symmetric key that is then used to
encrypt a session.

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

*
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)
*
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;
}
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 */
}
}

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

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

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

*
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

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. (A nonce is an
integer value that is added to a message to demonstrate its freshness)

*
The Needham–Schroeder secret-key authentication protocol
Weakness:
Figure Message 3 might not be fresh - and KAB could have been
7.15
compromised in the store of A's computer. Kerberos (next case study)
addresses
Header this by adding a timestamp
Message Notes 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 containing
integersathatnewlyare addedkey
generated toKmessages
AB and a
to
{KAB, A}KB}KA ‘ticket’ encrypted in B’s secret key. The nonce N
demonstrate
Ticket the freshness of the transaction. They are generated A
demonstrates that the message was sent in response
by the sending process when to therequired, for Aexample
preceding one. byS sent the
believes that
incrementing a counter or message
by reading the
because only(microsecond resolution)
S knows A’s secret key.
system
3. A->B: clock.
{KAB, A}KB A sends the ‘ticket’ to B.

4. B->A: {NB}KAB B decrypts the ticket and uses the new key KAB to
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.
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 Distributed Computing Enrinment
– BSD UNIX, Linux, Windows 2000, NT, XP, etc.
– Source code available at web.mit.edu I

 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

*
Case study: Kerberos authentication and key distribution service

 Deals with 3 kinds of security objects

– Ticket – a token issued by the Kerberos ticket –granting
service for presentation to a particular server, verifying that
the sender has recently been authenticated by Kerberos.
Has expiry time and newly generated key for use by the
client and the server
– Authentication -a token constructed by a client and sent
to a server to prove the identity of the user and the
currency of any communication with a server. Used only
once and contains the client’s name and timestamp.
– Session key – a secret key randomly generated by
Kerberos and issued to client for use when communicating
with a particular server

*
Case study: Kerberos authentication and key distribution service

 Key Distribution Centre (KDC) – a Kerberos server

 KDC offers an Authentication Servers (AS) and TGS
 On log in, users are authenticated by the A, using a
network-secure variation of the password method
 Client process is supplied with a ticket-granting
ticket and a session key for communicating with the
TGS

*
 System architecture of Kerberos
Figure 7.16
Kerberos Key Distribution Centre
TGS: Ticket-
granting
service Authentication
database
Step A Authen- Ticket-
tication granting
1. Request for service A service T
TGS ticket
2. TGS
ticket
Step B
3. Request for
server ticket
Login Step C
session setup
4. Server ticket
5. Service
Server request
session setup Service
function
Request encrypted with session key
DoOperation
Reply encrypted with session key Step A once per login session

Step B once per server session

Client Server Step C once per server transaction

*
Case study: Obtaining a Ticket and a Session Key

 Ticket format:
– {C,S,t1,t2,KCS}KS - with a fixed period from t1 to t2 for client C to access
server S: denoted by {ticket(C,S)}KS

 Communication format:
1. C->A: C,T,n – Clients C requests the Kerberos authentication server A
to supply a ticket for communication with the ticket granting service
2. A->C: {KCT,n}KC {ticket(C,T)}KT A returns a message containing a ticket
encrypted in its secret Key and a session Key for C to use with T.
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 file stores must be mounted each time a user logs in

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

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

implements the
secure channel SSL Record Protocol

Transport layer (usually TCP)

Network layer (usually IP)

SSL protocols: Other protocols:

*
 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
ServerHelloDone
Component Description Example
Key exchange
Client
the method to be usedServer
Certificate for RSA with public-key
Send client certificate response if
method A exchange ofVerify
Certificate a session key
B certificates
requested
Cipher for data the block or stream cipher to be IDEA
transfer used for Cipher
Change data Spec
Change cipher suite and finish
Finished
Message digest for creating message SHA
handshake
function authentication codes (MACs)Includes
Change Cipher Spec key master exchange.
Key master is used by both A and B
Finished to generate:
2 session keys 2 MAC keys
KAB MAB
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)

*
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

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

*
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