Upload
vuongthien
View
238
Download
2
Embed Size (px)
Citation preview
Network Security Protocols:Analysis methods and standards
John MitchellStanford University
Joint work with many students, postdocs, collaborators
TRUST: Team for Research in Ubiquitous Secure Technologies
NSF Science and Technology CenterMulti-university multi-year effortResearch, education, outreach
http://trust.eecs.berkeley.edu/
3
TRUST Research Vision
Privacy
Computer andNetwork Security
Electronic MedicalRecords
Identity TheftProject
Secure NetworkedEmbedded Systems
Software Security
Trusted Platforms
Applied Crypto -graphic Protocols
NetworkSecurity
Secure NetworkEmbedded Sys
Forensic and Privacy
Complex Inter -Dependency mod.
Model -basedSecurity Integration.
Econ., Public Pol. Soc. Chall.
Secure Compo -nent platforms
HCI andSecurity
Secure Info Mgt.Software Tools
Component Technologies
Societal Challenges
Integrative Efforts
TRUST will address social, economic and legal challenges
Specific systems thatrepresent these socialchallenges.
Component technologiesthat will provide solutions
CriticalInfrastructure
4
Network security protocols
Primarily key managementCryptography reduces many problems to key managementAlso denial-of-service, other issues
Hard to design and get rightPeople can do an acceptable job, eventuallySystematic methods improve results
Practical case for software verificationEven for standards that are widely used and carefully reviewed, automated tools find flaws
5
Recent and ongoing protocol efforts
Wireless networking authentication802.11i – improved auth for access point802.16e – metropolitan area networksSimple config – setting up access point
MobilityMobile IPv6 – update IP addr to avoid triangle routing
VoIPSIP – call referral feature, other issues
KerberosPKINIT – public-key method for cross-domain authentication
IPSecIKEv1, JFK, IKEv2 – improved key management
6
Mobile IPv6 Architecture
Mobile Node (MN)
Corresponding Node (CN)
Home Agent (HA)
Direct connection via binding update
Authentication is a requirementEarly proposals weak
7
Wireless Authentication
8
SupplicantUnAuth/UnAssoc802.1X BlockedNo Key
802.11 Association
802.11i Protocol
MSKEAP/802.1X/RADIUS Authentication
4-Way Handshake
Group Key Handshake
Data Communication
SupplicantAuth/Assoc802.1X UnBlockedPTK/GTK
9
Needham-Schroeder Protocol
{ 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 BKb
10
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]
11
Needham-Schroeder Lowe
{ A, NonceA }
{ NonceA, B, NonceB }
{ NonceB}
Ka
Kb
A BKb
Authentication?Secrecy?Replay attackForward secrecy?Denial of service?Identity protection?
12
Explicit Intruder Method
Intruder Model
AnalysisTool
Formal Protocol
Informal Protocol
Description
Find error
13
Run of protocol
AB
Initiate
Respond
C
D
Correct if no security violation in any run
Attacker
14
Automated Finite-State Analysis
Define finite-state systemBound on number of stepsFinite number of participantsNondeterministic adversary with finite options
Pose correctness conditionCan be simple: authentication and secrecyCan be complex: contract signing
Exhaustive search using “verification” toolError in finite approximation ⇒ Error in protocolNo error in finite approximation ⇒ ???
15
State Reduction on N-S Protocol
1706
17277
514550
980
6981
155709
58222
3263
1
10
100
1000
10000
100000
1000000
1 init 1 resp
2 init 1 resp
2 init 2 resp
Base: handoptimizationof model
CSFW:eliminatenet, maxknowledgeMergeintrud send,princ reply
16
CS259 Term Projects - 2006
Analysis of Octopus and Related Protocols
Analysis of the IEEE 802.16e 3-way handshake
Short-Password Key Exchange Protocol
802.16e Multicast-Broadcast Key Distribution Protocols
MOBIKE - IKEv2 Mobility and MultihomingProtocol
Analysis of ZRTPOnion Routing
Security analysis of SIPFormalization of HIPAA
Security Analysis of OTRv2
http://www.stanford.edu/class/cs259/
17
CS259 Term Projects - 2004
Windows file-sharing protocols
Secure Internet Live Conferencing
Key Infrastructure
An Anonymous Fair ExchangeE-commerce Protocol
Secure Ad-Hoc Distance Vector Routing
Electronic VotingOnion RoutingIEEE 802.11i wireless handshake protocol
XML SecurityElectronic votingiKP protocol family
http://www.stanford.edu/class/cs259/WWW04/
18
SupplicantUnAuth/UnAssoc802.1X BlockedNo Key
802.11 Association
802.11i Protocol
MSKEAP/802.1X/RADIUS Authentication
4-Way Handshake
Group Key Handshake
Data Communication
SupplicantAuth/Assoc802.1X UnBlockedPTK/GTK
19
Wireless Threats
Passive Eavesdropping/Traffic AnalysisEasy, most wireless NICs have promiscuous mode
Message Injection/Active Eavesdropping Easy, some techniques to gen. any packet with common NIC
Message Deletion and InterceptionPossible, interfere packet reception with directional antennas
Masquerading and Malicious AP Easy, MAC address forgeable and s/w available (HostAP)
Session HijackingMan-in-the-MiddleDenial-of-Service: cost related evaluation
Changhua He
20
4-Way Handshake Blocking
AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MICSPA, sn+1, msg4, MIC
PTK Derived
PTK Derived
PTK confirmed802.1X Unblocked
PTK confirmed 802.1X Unblocked
AA, ANonce, sn, msg1
SPA, SNonce, SPA RSN IE, sn, msg2, MIC
AA, ANonce, sn, msg1
21
Countermeasures
Random-Drop QueueRandomly drop a stored entry if the queue is fullNot so effective
Authenticate Message 1Use the share PMK; must modify the packet format
Reuse supplicant nonceReuse SNonce, derive correct PTK from Message 3Performance degradation, more computation in supplicant
Combined solutionSupplicant reuses SNonceStore one entry of ANonce and PTK for the first Message 1If nonce in Message 3 matches the entry, use PTK directlyEliminate memory DoS, only minor change to algorithmAdopted by TGi
22
Summary of larger study
adopt random-drop queue, not so effective; authenticate Message 1, packet format modified; re-use supplicant nonce, eliminate memory DoS.
4-way handshake blocking
Authenticate Beacon and Probe Response frame; Confirm RSN IE in an earlier stage; Relax the condition of RSN IE confirmation.
RSN IE poisoning
cease connections for a specific time instead of re-key and deauthentication; update TSC before MIC and after FCS, ICV are validated.
attack on Michael countermeasures
each participant plays the role of either authenti-cator or supplicant; if both, use different PMKs.
reflection attack
supplicant manually choose security; authenticator restrict pre-RSNA to only insensitive data.
security rollback
SOLUTIONSATTACK
23
Model checking vs proof
Finite-state analysisAttacks on model ⇒ Attack on protocol
Formal proofProof in model ⇒ No attack using only these
attacker capabilities
Finite state analysis assumes small number of principals, formal proofs do not need these assumptions
24
Protocol composition logic
Alice’s informationProtocolPrivate dataSends and receives
Honest Principals,Attacker
Send
Receive
Protocol
Private Data
Logic has symbolic andcomputational
semantics
25
802.11i correctness proof in PCL
EAP-TLSBetween Supplicant and Authentication ServerAuthorizes supplicant and establishes access key (PMK)
4-Way HandshakeBetween Access Point and SupplicantChecks authorization, establish key (PTK) for data transfer
Group Key ProtocolAP distributes group key (GTK) using KEK to supplicants
AES based data protection using established keys
Formal proof covers subprotocols 1, 2, 3 alone and in various combinations
26
SSL/TLS
C
ClientHello
ServerHello, [Certificate],[ServerKeyExchange],[CertificateRequest],ServerHelloDone
S[Certificate],ClientKeyExchange,[CertificateVerify]
Finished
switch to negotiated cipher
Finishedswitch to negotiated cipher
27
Theorems: Agreement and Secrecy
Client is guaranteed:
• there exists a session of the intended server
• this server session agrees on the values of all messages
• all actions viewed in same order by client and server
• there exists exactly one such server session
Similar specification for server
28
Composition
All necessary invariants are satisfied by basic blocks of all the sub-protocolsThe postconditions of TLS imply the preconditions of the 4-Way handshake The postconditions of 4-Way handshake imply the preconditions of the Group Key protocol
29
Complex Control Flows
Simple Flow Complex Flow
30
Study results802.11i provides
Satisfactory data confidentiality & integrity with CCMPSatisfactory mutual authentication & key management
Some implementation mistakesSecurity Level Rollback Attack in TSNReflection Attack on the 4-Way Handshake
Availability is a problemSimple policies can make 802.11i robust to some known DoSPossible attack on Michael Countermeasures in TKIPRSN IE Poisoning/Spoofing4-Way Handshake BlockingInefficient failure recovery scheme
Improved 802.11i
31
Some other case studiesWireless networking
802.11i – wireless access point auth802.16e – metropolitan area networkingSimple config – access point configuration
SSLFound version rollback attack in resumption protocol
KerberosPKINIT – public-key method for cross-domain authentication
IPSecIKEv1, JFK, IKEv2 – improved key management Kerberos
MobilityMobile IPv6 – update IP addr to avoid triangle rte
VoIPSIP – issues with call referral, currently under study
OTRv2Student project in CS259 this winter
32
Ticket 2
Ticket 2
Ticket 1
Ticket 1
Kerberos Protocol
Client
KDC
Service
TGS
{Kt}Kc
C TGS
{Ks}Kt
{C}Kt S
{C}Ks
Ktgs
Kc
Kv
{C, Ks}Kv
{C, Kt}Ktgs
{C, Ks}Kv
{C, Kt}Ktgs
33
Microsoft Security Bulletin MS05-042Vulnerabilities in Kerberos Could Allow Denial of Service, Information Disclosure, and Spoofing (899587)Published: August 9, 2005
Affected Software: • Microsoft Windows 2000 Service Pack 4 • Microsoft Windows XP Service Pack 1 and
Microsoft Windows XP Service Pack 2• Microsoft Windows XP Professional x64 Edition• Microsoft Windows Server 2003 and
Microsoft Windows Server 2003 Service Pack 1• Microsoft Windows Server 2003 for Itanium-based Systems and
Microsoft Windows Server 2003 with SP1 for Itanium-based Systems • Microsoft Windows Server 2003 x64 Edition
34
Kerberos Project
Formal analysis of Kerberos 5Several steps
Detailed core protocolCross-realm authenticationPublic-key extensions to Kerberos
Attack on PKINITBreaks association of client request and the responsePrevents full authentication and confidentiality
Formal verification of fixes preventing attackClose, ongoing interactions with IETF WG
I. Cervesato, A. D. Jaggard, A. Scedrov, J.-K. Tsay, and C. Walstad
35
Public-Key Kerberos
Extend basic Kerberos 5 to use PKIChange first round to avoid long-term shared keysOriginally motivated by security
If KDC is compromised, don’t need to regenerate shared keysAvoid use of password-derived keys
Current emphasis on administrative convenienceAvoid the need to register in advance of using Kerberizedservices
This extension is called PKINITCurrent version is PKINIT-29Attack found in -25; fixed in -27Included in Windows and Linux (called Heimdal)Implementation developed by CableLabs (for cable boxes)
36
C
C
I
I K
K
CertC, [tC, n2]skC, C, T, n1
CertI, [tC, n2]skI, I, T, n1
{[k, n2]skK}pkC, C, TGT, {AK, …}k
•Principal P has secret key skP, public key pkP•{msg}key is encryption of msg with key•[msg]key is signature over msg with key
{[k, n2]skK}pkI, I, TGT, {AK, …}k
At time tC, client C requests a ticket for ticket server T (using nonces n1 and n2):
The attacker I intercepts this, puts her name/signature in place of C’s:
I
Kerberos server K replies with credentials for I, including: fresh keys k and AK, a ticket-granting ticket TGT, and K’s signature over k,n2:
I decrypts, re-encrypts with C’s public key, and replaces her name with C’s:
I•I knows fresh keys k and AK•C receives K’s signature over k,n2 and assumes k, AK, etc., were generated for C (not I)
(Ignore most of enc-part)
The Attack
37
Fix Adopted in pk-init-27
The KDC signs k, cksum (place of k, n2)k is replyKeycksum is checksum over AS-REQEasier to implement than signing C, k, n2
Formal proof: this guarantees authenticationAssume checksum is preimage resistantAssume KDC’s signature keys are secret
Published proof uses simplified symbolic modelCryptographically sound proofs now exist
38
Recent and ongoing protocol efforts
Wireless networking authentication802.11i – improved auth for access point802.16e – metropolitan area networksSimple config – setting up access pointBluetooth simple pairing protocols
MobilityMobile IPv6 – update IP addr to avoid triangle routing
VoIPSIP – call referral feature, other issues
KerberosPKINIT – public-key method for cross-domain authenticationFull cryptographically sound proof recently developed
IPSecIKEv1, JFK, IKEv2 – improved key management
OTRv2student project in CS259 this winterZPhone ??
39
Conclusions
Protocol analysis methodsModel checking is fairly easy to applyReady for industrial useLogical proofs are feasible, can be made easier
Example: Wireless 802.11iAutomated study led to improved standardDeployment recommendations, more flexible error recovery
Many ongoing effortsExamples: Wireless networking, VoIP, mobilityTypical standardization effort takes a couple of years
Achievable goal: systematic methods that can be used by practicing engineers to improve network, system security
40