Network security CIS534 l4

• Demonstrate how basic cryptographic mechanisms can be used to build entity authentication and key distribution protocols suited to insecure networks.. Strong Authentication• In strong

Network Security

Lecture 4 Introduction to Secure Protocols

Objectives of Lecture

• Introduce the concept of a secure protocol.

• Model the principals involved in secure protocols, and their capabilities.

• Demonstrate how basic cryptographic mechanisms can

be used to build entity authentication and key distribution protocols suited to insecure networks.

• Appreciate how key distribution and entity

authentication can be enabled using trusted third parties.

• Describe the main features of the Kerberos protocol

suite and outline its application in Windows 2000.

4.1 Secure Protocols

• A protocol is a set of rules for exchanging

messages between 2 (or more) principals over

a network

• The word ‘protocol’ in the OSI model is

reserved and refers to rules governing

communication between a pair of peer entities.

• We’ll use it here in a more general way

• In this lecture, we largely leave unspecified the OSI layer at which our protocols operate

– Lectures 5 and 6 will look at protocols for specific layers.

Secure Protocols

So what is a secure protocol?

• When acting honestly, principals (participants)

achieve the stated aim of the protocol (e.g A successfully authenticates to B, or A and B

establish a key)

• Neither passive eavesdropper nor malicious, active adversary can defeat this aim (e.g by successfully impersonating A in an

authentication protocol with B)

• This all pre-supposes that the stated aim is

actually clearly stated!

The Principals – 1

another or to share a key

• In more complex protocols, Trent, a trusted

third party who is trusted by both Alice and Bob– aka (depending on application) TTP, key distribution centre (KDC), certification authority (CA),….

– What Trent is trusted to do (and not do) depends on the protocol and application.

The Principals – 2

Two kinds of adversary:

• Eve, a passive eavesdropper (‘sniffs’ messages at will).

• Mallory, an active adversary, who can view, alter,

delete, replay and inject messages into the network.

Warning 1: Often, secure protocols do not involve real

people, or do so only indirectly Writing ‘Alice’, ‘Bob’, etc, is just for convenience.

Warning 2: We’ll freely mix up A and Alice; B and Bob,

etc In practice, entities might be ‘named’ by IP

addresses, domain names, user names, etc.

The Principals – 3

Mallory is not all-powerful:

• He cannot guess a random number chosen by another

principal from a sufficiently large set of possibilities.

• He cannot invert a one-way hash function.

• Without the correct key, he cannot obtain the plaintext for a given ciphertext Nor can he compose ciphertexts for plaintexts of his choice.

• He cannot sign messages without having the

appropriate private key.

• He cannot correctly compute a MAC on a message

without knowing the correct secret key.

• In summary: Mallory cannot break strong

cryptographic mechanisms.

Summary So Far

• So we equip Alice, Bob, Trent with strong

cryptographic mechanisms to use on an

untrusted network

• The question then is:

How do we use these cryptographic

mechanisms (signatures, public-key and

symmetric key encryption, hash functions, MACs) to design secure protocols (providing

security services for our principals)?

• We distinguish between (data) origin

authentication (verifying the origin of received data) and entity authentication (verification of a

claimed identity)

• An origin authentication service can be built

from a data integrity mechanism, e.g a MAC (more details in IC2)

• Here we consider entity authentication, a basic

security service in networks

• Typically achieved by exchange of messages

called an authentication protocol (called an

authentication exchange in ISO 7498-2).

4.2 Entity Authentication

• We are interested in controlling access to

communication and information resources over

potentially insecure networks.

• Entity authentication provides a fundamental service:

– It allows one host or user on the network to check with which other host or user it is communicating.

• Successful entity authentication can be a precursor to (or part of) the use of more complex security services.

• Now I know which host I’m talking to:

– To which network services should it be given access?

– To which data should it be given access?

– How can secure communications with that host be established and maintained?

Why Entity Authentication?

Why Entity Authentication?

• Entity authentication:

– the corroboration that an entity is the one claimed at

a particular point in time (but not necessarily any

guarantees after that time).

• Unilateral authentication:

– entity authentication which provides one entity with assurance of the other’s identity but not vice versa.

– entity authentication which provides both entities

with assurance of each other’s identity.

Definitions

Basis for Authentication

authenticates A to B Is the following secure?

A B: ‘Hi B, I’m A’

• No – Mallory can easily impersonate A.

• So we need something stronger

• Authentication protocols can be built from a number of

different assumptions:

• A and B share a secret (e.g a password, a PIN,

biometric information, a symmetric key).

• A and B have authentic copies of each other’s public

Strong Authentication

• In strong authentication, one entity ‘proves’ its identity

to another by demonstrating knowledge of a secret

known to be associated with that entity, without

revealing that secret itself during the protocol.

• Also called ‘challenge-response’ authentication.

• Typically use cryptographic mechanisms to protect the messages in the protocol:

– Encryption.

– Integrity mechanism (e.g MAC).

– Digital signature.

Example: Passwords Over a Network

• Alice has a user ID and password allowing her to

remotely access a computer B over a network

– Alice sends the user ID and password over the network – B uses Alice’s ID to find an entry in a password file, and compares the password received with the password

stored.

– B authenticates Alice if the passwords match

• An example of user authentication based on

something known.

– a special case of entity authentication.

• Is this a strong authentication protocol or not?

Example (continued)

have what might be termed weak authentication.

network.

– Depending on the network type and attacker capabilities,

networks.

– But still very commonly used in such situations, e.g SNMPv1, ftp, telnet, Outlook, webmail, …

– May well be appropriate when authenticating to a local machine

passwords.

– Still vulnerable to dictionary attacks and replay attacks.

User Authentication

(and possibly vice-versa).

– Something you know (password, PIN).

– Something you have (a smartcard or token,…)

– Something you are (a biometric)

remember, carry or be.

– And the problem may be harder when user and system are

remote, because credentials/data may need to be protected in transit.

– Can’t expect users to remember long cryptographic keys or carry unwieldy equipment.

machine) is not generally limited in this way.

Encryption-based Unilateral

Authentication

• Alice sends an initiating message.

• Bob sends Alice a challenge message R.

• Alice responds with {R || B}K , message R concatenated with B, encrypted using shared key K.

• Bob checks that the message he received decrypts to give message R || B.

• If it does, then Alice is authenticated to Bob (or Bob

authenticates Alice).

The Protocol

(Here, {X}K means string X encrypted under

key K, and || means concatenation of

strings.)

Security of the Protocol – 1

1. Why can Bob be sure that message 3 in the

protocol came from Alice?

2. Why can Bob be sure that message 3 in the

protocol is not a replay of a message from an earlier run of the protocol between himself and Alice?

1. Only Alice (and Bob) know secret key K

2. Bob chose R at random just before sending

message 2 This R should never have been

used before This means that message 3,

which includes R in encrypted form, has never been produced before

Security of the Protocol – 2

1. Why can Bob be sure that message 3 in the

protocol is intended for him?

2. Can an attacker learn the value of secret key

K by observing multiple runs of the protocol?

1. Alice includes Bob’s identity ‘B’ in the

encrypted message This prevents Mallory taking a message intended for someone else and sending it to Bob

2. No, not if the encryption algorithm is strong

Security of the Protocol – 3

1. Is Alice authenticated to Bob in this protocol?

2. Is Bob authenticated to Alice in this protocol?

3. Does the protocol provide mutual or unilateral

authentication?

1. Yes

2. No (In fact Mallory could impersonate Bob in

the protocol, but our design goal was a

protocol in which Alice is authenticated, not Bob, so this is not a problem.)

3. Unilateral: authentication of Alice

• Now Mallory can’t prepare the correct response {R||

B}K to Bob’s challenge because he doesn’t know the secret key K and R has not been previously used.

• But what if Mallory could predict R? Then we can find

a serious replay attack….

A Replay Attack

1. A M(B): ‘Hi Bob, I’m Alice’

2. M(B) A: R (M predicts which R will be used later by B)

3. A M(B): {R || B}K

1. M(A) B: ‘Hi Bob, I’m Alice’

2. B M(A): R (M predicted this R would be used by B)

3. M(A) B: {R || B}K

Mallory keeps hold of {R || B}K: it’s going to come in

handy later:

Mallory firstly impersonates Bob to Alice in a

protocol run initiated by Alice:

Liveness and Freshness

• The replay attack shows that it is vital that the protocol

contains a means of checking liveness of principals.

within an acceptably recent timeframe.

• Liveness of principals usually ensured via freshness of

messages.

used previously and originated within an acceptably recent timeframe

• Two main methods for providing freshness:

– Nonce (Number used once).

– Time-stamps (clock-based or `logical’ time-stamps).

• Main property is ‘one-time’ property: nonce should not have been used before.

– So could in theory use a counter.

• But many protocols need nonces to be unpredictable to Mallory, rather than simply previously unused.

– For example, our protocol needs this property for R to prevent the replay attack

– Could form R by generating a long string of bits at random.

– But how long is long enough?

– And how can we ensure R is sufficiently random?

• Notice that in our protocol, R, the nonce is

unpredictable but not secret.

Time-stamps – 1

• Inclusion of date/time-stamp in message allows recipient to check it for freshness (as long as time-stamp protected by cryptographic means)

• A B: ‘I’m Alice’, {T || B}K

– a single message instead of three.

– Bob decrypts and checks that T is recent and that his identity is included.

– Only Alice (and Bob) knows K, so only Alice could have prepared this message It’s fresh, so Alice is live.

• But now we require securely synchronised

clocks to prevent replay – non-trivial!

Time-stamps – 2

• Typical clock drift is 1s per day on work station

• So need a window of acceptance for Alice’s

messages either side of Bob’s current clock

time (clock drift + variable network propagation time)

• Also need a log of recently received messages

to prevent Mallory from exploiting window with replay attack

– Mallory eavesdrops authentication message {T || B}K from Alice and replays it during B’s acceptable time period for T.

Time-stamps – 3

• This is (approximately) the method used by

RSA’s SecurID token system

– Time T and key K used by token to generate an

authentication message, displayed on token’s screen.

– User reads message from screen and enters it into computer.

– Message transmitted to remote host and compared with expected message (also computed using T and K).

– Typical acceptance window: 60s.

– Product can also add PIN entry for 2-factor

authentication.

‘Logical’ Time-stamps

• Alternative to clocks: Alice and Bob could use pair of sequence numbers NAB and NBA in their communications

value NAB, and increments it Likewise for B

• Needs pair of sequence numbers for every pair

Using MACs for Entity Authentication

Replace encryption mechanism with a MAC:

1 A B: ‘Hi Bob, I’m Alice’

Can argue security as for encryption-based

protocol: Only Alice can prepare correct

response for Bob;freshness of R guarantees

liveness of Alice.

What properties of the MAC did we use?

Signature-based Entity Authentication

• Instead of challenge/response, now

challenge/signature

• Use nonces or time-stamps for freshness.

• Rather than a shared secret key, Bob needs to

have authenticated version of Alice’s public key (and vice-versa for mutual authentication)

• Here, SA{X} denotes A’s signature on string X.

• Protocol achieves mutual authentication (via

two signatures and two nonces)

to ensure their correctness

• Alice and Bob have to be sure that they are

verifying each other’s signatures

• Hence need for trust in authenticity of public

keys instead of shared secrets

• Public keys can be certified by applying the

digital signature of a Trusted Third Party (TTP) called a Certificate Authority (CA)

• Result (public key + entity name + expiry date +

CA signature on three items) called a

certificate.

Using Digital Signatures

• To check a certificate signed by a CA requires

an authentic copy of the CA’s public key

• Leads to notion of certification paths and

public-key infrastructures (PKIs).

– PKI discussed in more detail in IC2.

• Related protocols are used in SSL and IPSec

(see Lectures 5 and 6)

Using Certificates

• Entity authentication only achieved for an instant in

time, typically provided at start of a connection/session.

• Mallory might be able to hijack the connection after that point.

• What if a secure session is needed?

– A combination of confidentiality, integrity, and data origin

authenticity for remainder of a communications session.

• Solution: securely agree session keys as part of the

authentication protocol.

• Then use those session keys in encryption and MAC mechanisms to build a secure session.

• Bind the session keys to the authentication to get an

authenticated key establishment (AKE) protocol

Authenticated Key Establishment – 1

Authenticated Key Establishment – 2

• As a simple example, we can adapt our one message time-stamp based protocol:

A B: {T || B}K simply by adding a session key SK in Alice’s message:

• So Bob can be sure that only Alice knows SK.

• Alice can be sure that only Bob could know SK: only

Bob could decrypt the message to extract SK.

Authenticated Key Establishment – 3

Public-key encryption can also be used to create authenticated session keys:

• Alice checks the authenticity of Bob’s public

encryption key PKB using a certificate

• A B: {SK}PKB

• Bob can obtain the session key SK by

decrypting using his private key

• Alice and Bob both use SK to derive encryption and MAC keys to protect their session

• Alice can be sure that only Bob could know the

session key

Authenticated Key Establishment – 4

• In this protocol, Alice is not authenticated

(anyone can encrypt messages for Bob)

• B is only implicitly authenticated to A:

– A is only assured she’s talking to B if messages in the subsequent session make sense (e.g MACs compute correctly with SK).

• A (much) more complicated version of this

protocol is an option in SSL (see Lecture 6)