Chapter7. Security

7.1 Introduction

7.2 Overview of security techniques

7.3 Cryptographic algorithms

7.4 Digital signatures

7.5 Cryptography pragmatics

10/11/2005 2

7.1. Introduction

� Why need security mechanisms in DS?– Share of resources– Otherwise, can always be protected by isolation

� In the physical world, organizations adopt security policiesthat provide for the sharing of resources within specified limits– Security policies are enforced with the help of security mechanisms

� Focus and concern of the chapter:– Provision of security mechanisms to protect data in DS while allowing

interactions between computers implied by security policies

10/11/2005 3

Principal (user) Principal (server)

Chapter 2 Revision: 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

10/11/2005 4

Chapter 2 Revision: 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

10/11/2005 5

Chapter 2 Revision: Secure channels

� Propertiesw Each process is sure of the identity of the otherw Data is private and protected against tamperingw Protection against repetition and reordering of data

� Employs cryptographyw Secrecy based on cryptographic concealmentw Authentication based on proof of ownership of secrets

Figure 2.15Principal A

Secure channelProcess p Process q

Principal BThe enemyCryptography

10/11/2005 6

The role of cryptography

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

Common Terminologies:

Familiar names (principles) used in security protocols

§ Cryptography: art of encoding info. in a format only the intended recipients can access

§ Alice and Bob: introduced by Rivest et al. 1978, seminar paper public-key cryptosystem

§ So the sender, Alice, is trying to message Bob...

§ Over the years, the Alice and Bob story line has become more complicated, something of a high-tech reality show. Not only are Alice and Bob trying to share a secret, say a Valentine's Day poem, but Carol and Dave want in and Eve is trying to eavesdrop

10/11/2005 7

The story of Alice and Bob

§ Cryptography is the one area of mathematics where there are people, not just numbers§ says Bruce Schneier, CTO of Counterpane Internet Security and author of

Applied Cryptography, milestone book opening up knowledge in the field

� Ask those in the know about Alice and Bob and you'll inevitably be pointed to an after-dinner speech delivered at a technology seminar in Zurich, Switzerland in 1984 by data security expert John Gordon. In his "Story of Alice and Bob," Gordon refers to the speech as perhaps "the first time a definitive biography of Alice and Bob has been given."

� From the speech we learn that "Bob is a subversive stockbroker and Alice is a two-timing speculator" and that they've never actually met one another. Gordon, who runs a consultancy in the U.K., sums up their story like this: "Against all odds, over a noisy telephone line, tapped by the tax authorities and the secret police, Alice will happily attempt, with someone she doesn't trust, whom she cannot hear clearly, and who is probably someone else, to fiddle [with] her tax returns and to organize a coup d'état, while at the same time minimizing the cost of the phone call."

10/11/2005 8

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

w man in the middle attack (tampers with the secure channel mechanism)

� Replaying– storing secure messages and sending them at a later date– maybe effective even with authenticated and encrypted messages

� Denial of service– flooding a channel or other resource, denying access to others

10/11/2005 9

Threats not defeated by secure channelsor other cryptographic techniques

� Denial of service attacks– Deliberately excessive use of resources to the extent that they are not

available to legitimate usersw Large scale Distributed Denial-of-Service (DDoS) attacksw e.g. the Internet 'IP spoofing' attack, February 2000, brought down some

of the largest sites on the Internet including Yahoo! and eBay for hoursw In October 2002, a DDoS attack flooded the root DNS servers with traffic

aiming to deprive the Internet of the DNS name lookup service (which would have paralyzed the majority of Internet applications). The attack brought down eight out of thirteen root servers, and a slightly longer attack would have had devastating effects on Internet connectivity.

w One of the most difficult challenges in defending against DDoS and many other attacks is that attackers often spoof the source IP address of their packets and thus evade traditional packet filters. Unfortunately, the current routing infrastructure cannot detect that a packet’s source IP address has been spoofed or from where in the Internet a spoofed IP packet has originated from.

10/11/2005 10

Echo request | source = x.x.x.x | destination = n.n.n.i

Echo reply | source = n.n.n.i | destination = x.x.x.x

Untrue!Compromised host on each local network

sends repeatedly (for all i):

resulting in:

Internet

Campus intranetsFirewall

amazon.com

yahoo.com

IP = x.x.x.x

IP = y.y.y.y

IP = n.n.n.i

The February 2000 IP Spoofing DDoS attack

10/11/2005 11

Threats not defeated by secure channelsor other cryptographic techniques

� Trojan horses and other viruses– Viruses can only enter computers when program code is imported.– But users often require new programs, for example:w New software installationw Mobile code downloaded dynamically by existing software (e.g. Java

applets)w Accidental execution of programs transmitted surreptitiously

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

– Java designers paid considerable attention to the mechanisms forremote loading in an effort to restrict the exposurew sandbox model, providing protection against mobile codew Gives each application its own environment, each with a security

manager that determines which resources are available to the application

10/11/2005 12

7.2. Overview of security techniques

� Introducing some more important techniques and mechanisms for securing DS and applications

� Modern cryptography includes several secure algorithms for encrypting and decryping messages, all based on the use of secrets called keys.

� Cryptographic key: parameter used in an encryption algorithm such that the encryption cannot be reversed without a knowledge of the key

� Two main classes of usage:– Shared secret keys: sender and recipient must share a knowledge of the key

– Public/private key pairs: sender uses a public key, recipient uses a corresponding private key to decrypt the message

10/11/2005 13

Uses of cryptography: 4 scenerioes

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

� Shall use the familiar names for principles

� and the following cryptography notations

10/11/2005 14

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. i.e., disclosed

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? Note Mallory doesn’t need KAB to do so

10/11/2005 15

Alice wishes to access file server Bob; Sara is an authentication server. Sara holds secret key KA of Alice and secret key KB of 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 to whom it

is issued and a shared key for a communication session.

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

� Important aspect: user’s password not have to be submitted to authentication service– Instead, using a challenge, i.e., step 2. Note KA is derived from Alice’s password

� Not suitable for e-commerce because authentication service doesn't scale…

Why KB?

10/11/2005 16

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

� Man-in-the-middle attack: 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.

� Solution: requiring Bob’s certificate signed by a well-known authority

10/11/2005 17

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).• Similar to checksum, very unlikely two different messages having similar digest

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

Why “match”?

10/11/2005 18

1. Alice prepares two versions M and M' of a contract for Bob. M is favourable to Bob and M' is not.

2. Alice makes several subtly different versions of both M and M' that are 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.

Birthday attack

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

10/11/2005 19

Birthday attack

Birthday paradox: a favorite problem in elementary probability and statistics courses.What is the probability that at least two of N randomly selectedpeople have the same birthday? (Same month and day, but not necessarily the same year.) A second part of the problem: How large must N be so that the probability is greater than 50 percent?

Answer: 23And, if 60, > 99%

10/11/2005 20

Certificates

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

Alice’s bank account certificate

Public-key certificate for Bob's Bank1. 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

Certificate: a digital 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.

10/11/2005 21

Certificates as credentials (self-read)

� 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 : KBpub4. 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

10/11/2005 22

Access control (self-read)

� Protection domain– A set of <resource, rights> pairs

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

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

– Capabilities associated with principalsw Like a keyw Format: <resource id, permitted operations, authentication code>w Must be unforgeablew 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

10/11/2005 23

Credentials (self-read)

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

10/11/2005 24

Delegation (self-read)

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