CS 843 - Distributed Computing Systems

Chapter 7: SecurityChin-Chih Chang, chang@cs.twsu.edu

From Coulouris, Dollimore and Kindberg

Distributed Systems: Concepts and Design

Edition 3, © Addison-Wesley 2001

Learning Objectives

• Security model Types of threat – eavesdropping, masquerading, tampering, and

denial of service

• Security techniques Cryptographic techniques

o Secrecy and integrityo Authentication

Certificates and credentials Access control

• Symmetric and asymmetric encryption algorithms• Digital signatures• Approaches to secure system design• Pragmatics and case studies

Introduction

• Why do we need Security? The need to protect the integrity and privacy of

information and other resources belonging to individuals and organizations is pervasive in both the physical and the digital world.

Figure 7.1 summarize the evolution of security needs.• Some Common Terms

Security Policies provide for the sharing of resources within specified limits. For example, access policy.

Security Mechanisms enforce security policies. For example, security guard.

• Security Policy and Security Mechanism are used to determine the security of a system. For example, lock -mechanism and rules of using lock - policy.

Figure 7.1 Historical context: the evolution of security needs

1965-75 1975-89 1990-99 Current

Platforms Multi-usertimesharingcomputers

Distributed systemsbased on localnetworks

The Internet, wide-area services

The Internet + mobiledevices

Sharedresources

Memory, files Local services (e.g.NFS), local networks

Email, web sites,Internet commerce

Distributed objects,mobile code

Securityrequirements

User identification andauthentication

Protection of services Strong security forcommercialtransactions

Access control forindividual objects,secure mobile code

Securitymanagementenvironment

Single authority,single authorizationdatabase (e.g. /etc/passwd)

Single authority,delegation, repli-cated authorizationdatabases (e.g. NIS)

Many authorities,no network-wideauthorities

Per-activityauthorities, groupswith sharedresponsibilities

Security Model (Ch 2)

• Protecting objects• Securing processes and their interactions• The enemy• Defeating security threats• Uses of this model

Principal (user) Principal (server)

Chapter 2: Objects and Principals

Access rights

Network

invocation

resultClient

Server

Object

• 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

Figure 2.13

Protecting Objects

• Server: Collection of objects on behalf of some users.

• Clients send invocations and Server replies• Access rights to users• Associate each invocation and each result the

authority on which it is issued.• Authority: principal• Server verifies identity of each principal.

Securing Processes & Interactions, Enemy

• Processes interact by sending messages• Messages are exposed to attack because of open networks• Integrity of messages threatened by security violations and

communication failures• Model to analyze these threats• An enemy is capable of Sending any message to any

process and reading or copying any message between a pair of processes.

• Example: Computers on a network running a program to read network messages or make false requests to processes.

Chapter 2: The enemy

Communication channel

Process p Process q

The enemym’

Copy of m

m

• 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

Figure 2.14

Chapter 2: Secure channels

• Properties Each process is sure of the identity of the other Data is private and protected against tampering Protection against repetition and reordering of data

• Employs cryptography Secrecy based on cryptographic concealment Authentication based on proof of ownership of secrets

Figure 2.15Principal A

Secure channelProcess p Process q

Principal BThe enemyCryptography

The Emergence of Cryptography

• Cryptography provides the basis for most computer security mechanisms.

• The names shown in Figure 7.2 are used extensively in the security literature.

Figure 7.2 Familiar names for the protagonists in security protocols

Alice First participant

Bob Second participant

Carol Participant in three- and four-party protocols

Dave Participant in four-party protocols

Eve Eavesdropper

Mallory Malicious attacker

Sara A server

Defeating Security Threats

• Defeating Security Threats Cryptography Authentication Secure Channels

• Uses Of Security Model: Provides basis for analysis and design of secure systems

keeping costs at a minimum.

Threats & Attacks

• Types of Security Threats generally fall into three board classes: Leakage: Acquisition of information by unauthorized

recipients. Tampering: Unauthorized alteration of information. Vandalism: Interference with proper operation of system

without gain to the perpetrator

Threats and Forms of Attack on a Communication Channel

• Eavesdropping obtaining private or secret information

• Masquerading assuming the identity of another user/principal

• Message tampering• altering the content of messages in transit

o 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

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 userso 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:

o New software installationo Mobile code downloaded dynamically by existing software (e.g.

Java applets)o Accidental execution of programs transmitted surreptitiously

Defences: code authentication (signed code), code validation (type checking, proof), sandboxing.

Threats From Mobile Code

• Programs can be loaded into a process from a remote server and then executed locally.

• What is the danger?

Internal interfaces and objects within an executing process exposed to attacks.

• E.g. Java Virtual Machine employs security manager.

Java Virtual Machine (JVM)

• Measures in JVM to protect local environment Downloaded classes are stored separately from local

classes Code-validation: Bytecodes are checked for validity. Type-checking: Valid java bytecode is composed of JVM

instructions from a specified set. These instructions are checked to ensure they will not produce certain errors when the program runs.

• Information leakage If the transmission of a message between two processes

can be observed, some information can be gathered just by observation.

Securing Electronic Transactions

• Email: authenticate an auction bid by email• Purchase of Goods• Banking Transactions• Micro-transactions

Businesses are looking for ways to charge for access to Web pages, which may for example hold stock market quotes or give access to interactive games. The cost of processing such small sums, called micro-transactions (or sometimes micro-payments)

One slightly-cynical provider has commented that the true meaning of micro-transaction is any transaction whose value is currently too small to be worth bothering with - about one US dollar at the moment.

Securing Web Purchase

• Authenticate the vendor to the buyer.• Keep the buyer’s credit card number and other

payment details from falling into the hands of the third party and ensure that they are sent unaltered.

• If the goods are in a form suitable for downloading, ensure that their contents is delivered without alteration.

• Authenticate the identity of the account holder to bank before giving them access to their account.

Designing Secure Systems

• Designing Secure Systems is difficult. The design goal is to exclude all possible attacks and loopholes. This is analogous to that of programmer whose aim is to exclude all bugs from his program.

• Worst Case Assumptions (The box on page 260): Interfaces are exposed – an attacker can send a

message to any interface. Networks are insecure Limit the lifetime and scope of each secret - password Algorithms and code are available to attackers Attackers may have access to large resources Minimize the trusted base – The system for security

implementation should be kept small.

Security Techniques

• Familiar names for the main players in security protocols are introduced in Figure 7.2 and the notations for encrypted and signed items in Figure 7.3.

• Cryptography: Encryption: Process of encoding a message to hide its

contents Cryptography includes several encryption/decryption

algorithms based on use of secrets called Keys. Cryptographic key: Parameter used in an encryption

algorithm in such a way that the encryption cannot be reversed without the knowledge of the key

Figure 7.3 Cryptography 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

• Two main classes: Shared Secret keys: Both use secret keys Public/Private keys: Sender uses public key

• Comparison Public key encryption requires 100/1000 times more

processing power

• Cryptography is used in: Secrecy and integrity Authentication Digital signatures

Security Techniques

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.

Scenario 1: Secret communication with a shared secret key

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?

Authentication: Authenticated Communication With Server

• Scenario: Alice wishes to access files held by Bob, a file server on the LAN she works. Sara is an authentication server that is securely managed. Sara issues users with passwords and holds secret keys for all principals in the system (KA & KB).

• Ticket: Encrypted item issued by authentication server, containing the identity of the principal to whom it is issued and a shared key that has been generated for the current communication session.

• Pros and Cons: Pros: Useful in small organizations Cons: Inappropriate for Electronic Commerce

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.

2. Sara sends a response to Alice. {{Ticket}KB, KAB}KA. It is encrypted in KA 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.

Scenario 2: Authenticated communication with a server

• 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…

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

Scenario 3: Authenticated communication with public keys

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

Digital Signatures

• Can be achieved by encrypting a compressed form of message (digest) using a key known only to signer.

• This encrypted digest acts as a signature that accompanies the message.

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.

Scenario 4: Digital signatures with a secure digest function

The digest function must be secure against the birthday attack

Certificates

• Certificate: a statement signed by an appropriate authority.• Certificates require: An agreed standard format• Agreement on the construction of chains of trust (see

Section 7.4.4).• Expiry dates, so that certificates can be revoked.

Certificates

1. Certificate type: Account number2. Name: Alice3. Account: 62626264. Certifying authority: Bob’s Bank5. Signature: {Digest(field 2 + field 3)} KBpriv

Figure 7.4 Alice’s bank account certificate

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

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 She would need to add her public key certificate

Figure 7.5 Public-key certificate for Bob's Bank

1. Certificate type: Public key2. Name: Bob’s Bank3. Public key: KBpub

4. Certifying authority: Fred – The Bankers Federation5. Signature: {Digest(field 2 + field 3)} KFpriv

1. Certificate type: Account number2. Name: Alice3. Account: 62626264. Certifying authority: Bob’s Bank5. Signature: {Digest(field 2 + field 3)} KBpriv

Figure 7.4 Alice’s bank account certificate

Access control

• Protection domain A set of <resource, rights> pairs

• Two main approaches to implementation: Access control list (ACL) associated with each object

o E.g. Unix file access permissions o For more complex object types and user communities, ACLs can become

very complex

Capabilities associated with principalso Like a key

o Format: <resource id, permitted operations, authentication code>

o Must be unforgeable

o Problems: eavesdropping, difficulty of cancellation

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-rw-r--r-- gfc22 staff 163945 Oct 24 00:16 Preview of xx.pdfdrwxr-xr-x gfc22 staff 264 Oct 31 13:09 iTunes-rw-r--r-- gfc22 staff 325 Oct 22 22:59 list of broken apps.rtf

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.

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.

Firewalls

• Protect intranets, performing filtering operations on incoming, outgoing communications.

• All external communication is intercepted• No protection from attacks from inside• Not affective against denial of service attacks

Summary

• Security Model• Threats and Attacks• Designing Secure Systems• Security Techniques: Cryptography• Secret/ Public Keys• Digital Signatures• Certificates• Firewalls

Content

• Cryptographic algorithms : Symmetric algorithms Asymmetric algorithms Block ciphers Stream ciphers

• Digital signatures:

Digital signatures with public keys Digital signatures with private keys Secure digest functions

Cryptographic algorithms

• A message is encrypted by the sender applying some rule to transform the plaintext message (any sequence of bits) to a ciphertext (a different sequence of bits).

• The recipient must know the inverse rule in order to transform the ciphertext into the original plaintext.

• The encryption transformation is defined with two parts, a function E and a key K.

• The resulting message is written {M}.• Decryption is carried out using an inverse function

D, which also takes a key as a parameter.• Symmetric vs. Asymmetric:

For secret-key cryptography, the key used for decryption is the same as that used for encryption.

For public-key cryptography, the key used for encryption and decryption are different.

Cryptographic algorithms

Cryptographic Algorithms

• Symmetric (secret key)E(K, M) = {M}K D(K, E(K, M)) = M

Same key for E and DM 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.

Message M, key K, published encryption functions E, D

• Most algorithms work on 64-bit blocks.• For some applications, such as the encryption of

telephone conversations, encryption in blocks is inappropriate because the data streams are produced in real time in small chunks.

• A keystream is an arbitrary-length sequence of bits that can be used to obscure the contents of a data stream by XOR-ing the keystream with the data stream.

Cryptographic algorithms

Cipher blocks, chaining and stream ciphers

n

n+3 n+2 n+1 XOR

E(K, M)

n-1n-2n-3

plaintext blocks

ciphertext blocks

Figure 7.6 Cipher block chaining (CBC)

XOR

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

plaintext stream

ciphertext stream

buffer

keystream

Figure 7.7 Stream cipher

Most algorithms work on 64-bit blocks.Weakness of simple block cipher:- repeated patterns can be detected.

• Shannon’s principles of confusion and diffusion is to conceal the content of a ciphertext block M, combing it with a key to protect against brute-force attacks.

• Non-destructive operations such as XOR and circular shifting are used to combine each block of plaintext with the key, producing a new bit pattern that obscures the relationship between the blocks in M and {M}.

• There is usually repetition and redundancy in the plaintext. Diffusion dissipates the regular patterns that result by transposing portions of each plaintext block.

Design of Cryptographic Algorithms

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

Symmetric encryption algorithms

AES: A proposed US Advanced Encryption Standard (1997). 128/256-bit key.

• The above speeds are for a Pentium II processor at 330 MHZ. Today's PC's (May 2002) should achieve a 5 x speedup.

• There are many other effective algorithms. Schneier [1996] describes more than 25 symmetric algorithms, many of which are identified as secure against known attacks. (Schneier, B. (1996). Applied Cryptography, 2nd Ed. New York: John Wiley.)

TEA (Tiny Encryption Algorithm)

• The TEA algorithm uses rounds of integer addition, XOR (the ^ operator) and bitwise logical shifts (<< and >>) to achieve diffusion and confusion of the bit patterns in the plaintext.

• The plaintext is a 64-bit block represented as two 32-bit integers in the vector text[]. The key is 128bits long, represented as four 32-bit integer.

TEA encryption function

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]); 5z += ((y << 4) + k[2]) ^ (y+sum) ^ ((y >> 5) + k[3]); 6

}text[0] = y; text[1] = z;

}

• Lines 5 & 6 perform confusion (XOR of shifted text)and diffusion (shifting and swapping)

Figure 7.8 key 4 x 32 bitsplaintextand result 2 x 32

Exclusive OR

logical shift

TEA: TEA decryption function

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: TEA in use

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

}}

DES (Data Encryption Standard)

• Data Encryption Standard (DES) was developed by IBM and adopted as a US national standard.

• The encryption function maps a 64-bit plaintext input into a 64-bit encrypted output using a 56-bit key.

• The algorithm has 16 key-dependent stages known as rounds and was time-consuming.

• In June 1997, it was successfully cracked. Only used for the protection of low-value information.

• Triple-DES: apply DES three times with two keys k1, k2. Give strength against brute-force attacks.

IDEA (International Data Encryption Algorithm)

• IDEA was developed in the early 1990s as a successor to DES.

• Use a 128-bit key to encrypt 64-bit blocks.• For both DES and IDEA, the same function is used

for encryption and decryption.• No significant weakness have been found.• It performs encryption and decryption at about 3

times the speed of DES.

AES (Advanced Encryption Standard)

• 1997, the US NIST issued an invitation.• NIST is pleased to announce the approval of the

Federal Information Processing Standard (FIPS) for the Advanced Encryption Standard, FIPS-197.

• This standard specifies Rijndael as a FIPS-approved symmetric encryption algorithm that may be used by U.S. Government organizations (and others) to protect sensitive information.

AES (Advanced Encryption Standard)

• The two researchers who developed and submitted Rijndael for the AES are both cryptographers from Belgium: Dr. Joan Daemen (Yo'-ahn Dah'-mun) of Proton World International and Dr. Vincent Rijmen (Rye'-mun), a postdoctoral researcher in the Electrical Engineering Department (ESAT) of Katholieke Universiteit Leuven.

• http://csrc.nist.gov/encryption/aes/• http://csrc.nist.gov/encryption/aes/round2/aesfact

.html

Asymmetric (public-key) algorithm

• Only a few practical public-key schemes have been developed to date.

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

• 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. (350 MHz PII processor)

Asymmetric (public-key) algorithm

• RSA – The Rivest, Shamir, Adelman (RSA) design for a public-key cipher is based on the use of the product of two very large prime numbers, relying on the fact that the determination of the prime factors of such large numbers is so computationally difficult as to be effectively impossible to compute.

• Elliptic curve: A recently-developed method, shorter keys and faster. Asymmetric algorithms are ~1000 x slower and are therefore not practical for bulk encryption, but their other properties make them ideal for key distribution and for authentication uses.

RSA Encryption

To find a key pair e, d: 1. Choose two large prime numbers, P and Q (each greater than 10100), and form:

N = P x Q 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 de = 385/5 = 77

RSA Encryption

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 Nfor 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 NRivest, 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.

RSA

1. choose 2 large primes, p and q > 10^100.2. compute n=pq and phi(n)=(p-1)(q-1).3. choose a number relatively prime to phi(n) and call it d.4. find e s.t. e.d mod phi(n) = 1.• Group P into blocks s.t. C=P^e (mod n) and P=C^d(mod n),

0 <= P < n• E.g. (pedagogical): P=3 q=11 => n=33 phi(n) = 20. | let d=7 <--| 7.e = 1 (mod 20) => e=3 ---- C = P^3 (mod 33), P = C^7 (mod 33)

Digital Signatures

• Strong digital signatures are an essential requirement for secure systems.

• Handwritten signatures are used to verify that document is: Authentic Unforgettable Non-repudiable

• What is needed is a means to irrevocably bind a signer’s identity to the entire sequence of bits representing a document.

• Two techniques: Digital signing Digest functions

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:

o fast to computeo hard to invert - hard to compute M given H(M)o 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)

Secure digest functions

• h=H(M) should have the following properties:• 1. Given M, it is hard to compute h.• 2. Given h, it is hard to compute M.• 3. Given M, it is hard to find another message M’, • such that H(M) = H(M’).

• Two widely used digest functions:• MD5, SHA

Digital signatures with public keys

Signing

hH(doc)

D(Kpub,{h}) h'

h = h'?authentic:forged

Figure 7.11

Verifying

M

H(M)

128 bits

h E(Kpri, h){h}Kpri

M

signed doc

M

{h}Kpri

MACs: Low-cost signatures with a shared secret key

Signing

Verifying

M

K

Figure 7.12M

K

h = h'?authentic:forged

h

M

signed doc

H(M+K) h

h'

H(M+K)

Signer and verifier share a secret key K

MAC: Message Authentication Code

Certificate standards

• X.509 is the most widely standard format as shown in Figure 7.13.

X509 Certificate format

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

Figure 7.13

Cryptography pragmatics

• Performance of cryptographic algorithms.• comparison of various algorithms.• 330 Mhz PII systems used

Performance of encryption and secure digest algorithms

Key size/hash size(bits)

Extrapolatedspeed

(kbytes/sec.)

PRB optimized speed

(kbytes/s)

TEA 128 700 -

DES 56 350 7746

Triple-DES 112 120 2842

IDEA 128 700 4469

RSA 512 7 -

RSA 2048 1 -

MD5 128 1740 62425

SHA 160 750 25162

PRB = Preneel, Rijmen and Bosselaers [Preneel 1998]

Algorithm

Publickey

Secret key

Digest

speeds are for a Pentium II processor at 330 MHZFigure 7.14

Applications & obstacles

• Political obstacles:o The resistance had two sources: NSA and FBIo In January 2000, the US government introduced a new

policy to allow US software vendors to export software that incorporates strong encryption.

• Applications: PGP (Pretty Good Privacy) www.pgp.com

o Developed by Philip Zimmermanno It uses RSA public-key encryption for authentication

and to transmit secret keys to the intended partyo It uses the IDEA or 3 DES secret-key encryption

algorithms to encrypt mail messages

Case studies

• Needham-Schroeder• Kerberos• SSL• Millicent

Case study: Needham and Schroeder

• 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

o computers too slow for trap-door calculationso RSA algorithm not available until 1978

• An authentication protocol in response to the need for a secure means of managing keys and passwords in a network.

Case study: Needham - Schroeder protocol

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

• The solution to authentication and key distribution is based on an authentication server to supply keys to the clients.

Figure 7.15 The Needham–Schroeder secret-key authentication protocol

Header Message Notes

1. A->S: A, B, NAA requests S to supply a key for communicationwith B.

2. S->A: {NA , B, KAB,

{KAB, A}KB}KA

S returns a message encrypted in A’s secret key,containing a newly generated key KAB and a‘ticket’ encrypted in B’s secret key. The nonce NA demonstrates that the message was sent in responseto the preceding one. A believes that S sent themessage because only S knows A’s secret key.

3. A->B: A sends the ‘ticket’ to B.

4. B->A: B decrypts the ticket and uses the new key KAB toencrypt another nonce NB.

5. A->B: A demonstrates to B that it was the sender of theprevious message by returning an agreedtransformation of NB.

{KAB, A}KB

{NB}KAB

{NB - 1}KAB

Case study: Needham - Schroeder protocol

• NA is a nonce. Nonces are integers that are added to messages to demonstrate the freshness of the transaction. They are generated by the sending process when required, for example by incrementing a counter or by reading the (microsecond resolution) system clock.

• Weakness: Message 3 might not be fresh - and KAB could have been compromised in the store of A's computer. Kerberos (next case study) addresses this by adding a timestamp or a nonce to message 3.

Kerberos – 1980s

• 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. Time stamp is

used as nonces.

• Introduced for authentication and security facilities in campus and other intranets.

Case study: Kerberos authentication and key distribution service

• Standardized and now included in many operating systems Internet RFC 1510, OSF DCE BSD UNIX, Linux, Windows 2000, NT, XP, etc. Available from MIT

• Three kinds of security objects: ticket authentication session key

• 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

ServerClient

DoOperation

Authenticationdatabase

Loginsession setup

Ticket-granting

service T

Kerberos Key Distribution Centre

Serversession setup

Authen-tication

service A

Servicefunction

Figure 7.16 System architecture of Kerberos

3. Request forserver ticket

4. Server ticket

Step B

5. Service request

Request encrypted with session key

Reply encrypted with session key

Step C

1. A->S: A, B, NA

2. S->A: {NA , B, KAB,

{KAB, A}KB}KA

3. A->B:

4. B->A:

{KAB, A}KB

{NB}KAB

Needham - Schroeder protocol

5. A->B: {NB - 1}KAB

Step B once per server session

Step C once per server transaction

Step A once per login session

1. Request forTGS ticket

2. TGSticket

Step A

TGS: Ticket-granting service

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

E-transactions with Secure Sockets (SSL)

• Developed by Netscape and adopted as standard with name Transport Layer Security.

• Features: Negotiable encryption and authentication algorithms. Bootstrapped secure communication

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

Figure 7.17 SSL protocol stack

SSLHandshake

protocol

SSL ChangeCipher Spec

SSL AlertProtocol

Transport layer (usually TCP)

Network layer (usually IP)

SSL Record Protocol

HTTP Telnet

SSL protocols: Other protocols:

negotiates cipher suite, exchanges certificates and key masters

changes thesecure channel to a new spec

implements the secure channel

ClientA

ServerB

ClientHello

ServerHello

Figure 7.18 SSL handshake protocol

Establish protocol version, session ID, cipher suite, compression method, exchange random start values

Certificate

Certificate Request

ServerHelloDone

Optionally send server certificate and request client certificate

Certificate

Certificate VerifySend client certificate response if requested

Change Cipher Spec

Finished

Change Cipher Spec

Finished

Change cipher suite and finish handshakeIncludes key master exchange.Key master is used by both A and Bto generate:2 session keys 2 MAC keys

KAB MAB

KBA MBA

Figure 7.19 SSL handshake configuration options

Component Description Example

Key exchangemethod

the method to be used forexchange of a session key

RSA with public-keycertificates

Cipher for datatransfer

the block or stream cipher to beused for data

IDEA

Message digestfunction

for creating messageauthentication codes (MACs)

SHA

*

Figure 7.20 SSL record protocol

Application data abcdefghi

abc def ghiRecord protocol units

Fragment/combine

Compressed units

Compress

MAC

Hash

Encrypted

Encrypt

TCP packet

Transmit

Milicent protocol

• Used for low level(low priced) electronic transactions.

• Drawbacks of Existing systems: Credit cards – high cost Online accounts – the initial overhead Digital cash – double spending because of undetectable

copies

The Millicent Scheme

• Developed scrip - specialized digital cash for low level transactions.

• Scrip is valid for a particular vendor only. • Format of scrip:

vendor Value Scrip ID Customer ID Expiry Date Properties Certificate

Figure 7.21 Millicent architecture

Vendor

Masterscripsecrets

Purchase(item name,Customer

Scripstore

Validator BrowserCompletion(item,

payment)

Optional secure channel based on customer secret

Mastercustomersecrets

Customersecret

Spentscriplist

scrip

scrip

scrip change)

Summary

• Introduction - Threats, e-transactions, designing secure systems

• Overview of security techniques - cryptography, access control, firewalls

• Cryptographic algorithms - asymmetric algorithms, secret-key/symmetric algorithms, hybrid algorithms, digital signatures

• Case-studies - Needham-Schroeder, kerberos, SSL, Millicent

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.