Analysis of Security Protocols (I) John C. Mitchell Stanford University.
-
date post
19-Dec-2015 -
Category
Documents
-
view
216 -
download
1
Transcript of Analysis of Security Protocols (I) John C. Mitchell Stanford 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
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]
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?