Chapter7. Security 7.1 Introduction 7.2 Overview of security - - PowerPoint PPT Presentation

• 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 policies that 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 result Client 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 enemy

m’

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

Principal

A

Secure channel Process

p

Process

q

Principal B

The enemy Cryptography

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

–

• btaining 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 – 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 channels

• r other cryptographic techniques
• Denial of service attacks

– Deliberately excessive use of resources to the extent that they are not available to legitimate users

• Large scale Distributed Denial-of-Service (DDoS) attacks
• e.g. the Internet 'IP spoofing' attack, February 2000, brought down some
• f the largest sites on the Internet including Yahoo! and eBay for hours
• 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.

• One of the most difficult challenges in defending against DDoS and many
• ther 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 intranets Firewall

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 channels

• r 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:

• 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. – Java designers paid considerable attention to the mechanisms for remote loading in an effort to restrict the exposure

• sandbox model, providing protection against mobile code
• 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 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

• 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 selected people 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: 23 And, if 60, > 99%

10/11/2005 20

Certificates

• 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

Alice’s bank account certificate 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 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 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

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

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

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

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

• perations supported by a resource.

– The temporal restriction can be achieved by adding expiry times.