Analysis of Security Protocols (I) John C. Mitchell Stanford University.

Analysis of Security Protocols (I)

John C. MitchellStanford University

Computer Security

Protect information Store user passwords in a form that prevents anyone

from reading them Transmit information like credit card numbers in a

way that prevents others from intercepting them Protect system integrity

Keep others from deleting your files Keep downloaded code (such as Java applets) from

modifying important data Reject mail messages that contain viruses

Maintain privacy

Correctness vs Security

Program or System Correctness Program satisfies specification

For reasonable input, get reasonable output

Program or System Security Program resists attack

For unreasonable input, output not completely disastrous

Secure system might not be correct Main technical differences

Active interference from environment Refinement techniques may fail

Outline of these lectures

Introduction to security protocols Issues in security, protocol examples and flaws

Overview of cryptography Formal presentation of protocols and

intruder Automated finite-state analysis A probabilistic, poly-time framework

Tractable program analysis

Goal: tools and techniques to solve useful problems Caveat: need to be realistic

programcomplexity

complexity of property to verify

May be possible

Intractable

Security Protocols

Transmit information across network Keep important information secret Communicate with those you know and trust

Typical handshake protocols 3-7 steps 2-5 parties

client, server, key distribution service, …

lead to shared secret key for data transfer

Example: Secure Sockets Layer

Establishing Secure Communication

Parties use SSL protocol to Choose encryption scheme, e.g.

40-bit international encryption with 2 keys 120-bit domestic encryption with 2 keys choose among versions of specific scheme

Agree on shared secret key Secret key more efficient than public key

• Avoid known-plaintext attack Minimize reuse of hard-to-establish public key

40

120

Some security objectives

Secrecy Info not revealed

Authentication Know identity of

individual or site Data integrity

Msg not altered Message

Authentication Know source of msg

Receipt Know msg received

Access control Revocation Anonymity Non-repudiation

Example Protocols

Challenge response Mechanism for freshness

Needham-Schroeder Public Key Use public-key crypto to generate shared secret

Kerberos Simplified version w/o timestamps or nonces Idea of sending encrypted “tickets”

SSL (briefly) Diffie-Hellman key exchange

Timeliness in Communication

Assume Alice and Bob share a private encryption key K

Alice wants to know if Bob is on network Possible protocol:

Alice Bob: { “Hi Bob. Still there?” }K

Bob Alice: { “I am here?” }K

What’s wrong with this?

Challenge-Response

Alice wants to know if Bob is still there Send “fresh” number n, Bob returns f(n)

nonce = number used once

This avoids reply by malicious 3rd party Protocol

Alice Bob: { nonce }K

Bob Alice: { nonce+1 }K

Does this work?

Needham-Schroeder Key Exchange

{ A, Noncea }

{ Noncea, Nonceb }

{ Nonceb}

Ka

Kb

Result: A and B share two private numbers not known to any observer without Ka

-1, Kb

-1

A B

Kb

Anomaly in Needham-Schroeder

A E

B

{ A, Na }

{ A, Na }{ Na, Nb }

{ Na, Nb }

{ Nb }

Ke

KbKa

Ka

Ke

Evil agent E trickshonest A into revealingprivate key Nb from B.

Evil E can then fool B.

[Lowe]

TMN Cell Phone Protocol

a

Nab b K

Ks

s

S

BA

B, {N } A

B{N }

A{N }

TMN Replay Attack

S BAB, {Na}Ks A

A, {Nb}KsB, {Nb}Na

S DCD, {Nc}Ks C

C, {Nb}KsD, {Nb}Nc

REPLAY

Kerberos Client requests key from KDC

C KDC : C, TGS KDC returns private key and ticket

KDC C : {Ks1 }Kc {C, Ks1 }Ktgs

Client sends name and ticket to TGS C TGS : {C}Ks1, {C, Ks1 }Ktgs, S

TCS returns private key and ticket TGS C : {Ks2 }Kc {C, Ks2 }Ks

Client contacts server C S : {C}Ks1, {C, Ks1 }Ks

Secure Socket Layer (SSL)

Three goals Negotiate specific encryption scheme

Possible “version attack”

Authenticate client and server Appeal to “signature authority”

Use public key to transmit secret key

Several underlying primitives: public key, signature scheme, hash function, private key

Handshake Protocol Description

ClientHello CS C, VerC, SuiteC, NC

ServerHello S S C Ver C VerSS, Suite, SuiteSS, N, NSS, , signCA{ S, K S, KSS++ }

ClientVerify C S signCA{C, VC } { VerC, SecretC } ++

signC { Hash( Master(NC, NNSS, SecretC) + Pad2 + Hash(Msgs + C + Master(NC, NNSS, SecretC) + Pad1)) }

(Change to negotiated cipher)

ServerFinished S C { Hash( Master(NC, NNSS, SecretC) + Pad2 + Hash( Msgs + S + Master(NC, NNSS, SecretC) + Pad1)) }

ClientFinished C S { Hash( Master(NC, NNSS, SecretC) + Pad2 + Hash( Msgs + C + Master(NC, NNSS, SecretC) + Pad1)) }

KSS

Master(NC, NSS, SecretC)

Master(NC, NSS, SecretC)

Diffie-Hellman Key Exchange

Number-theoretic assumption Given three numbers p, g, ga mod p, no efficient

algorithm for computing a Belief: adversary cannot find a until “too late”

Protocol (assumes public prime p, generator g) Alice Bob: ga mod p Bob Alice: gb mod p

Consequence Alice and Bob know gab mod p, no one else does Works on telephone, not general network. Why?