Network Security Protocols: Analysis methods and standards John - PowerPoint PPT Presentation

Network Security Protocols: Analysis methods and standards John Mitchell Stanford University Joint work with many students, postdocs, collaborators

TRUST : Team for Research in Ubiquitous Secure Technologies NSF Science and Technology Center Multi-university multi-year effort Research, education, outreach http://trust.eecs.berkeley.edu/

TRUST Research Vision Societal Challenges Privacy TRUST will address Computer and social, economic and Critical Infrastructure Network Security legal challenges Integrative Efforts Identity Theft Project Specific systems that represent these social Secure Networked Electronic Medical challenges. Embedded Systems Records Component Technologies Software Complex Inter - Security Dependency mod. Secure Info Mgt. Software Tools Trusted Secure Network Econ., Public Pol. Soc. Component technologies Platforms Embedded Sys Chall. that will provide solutions Applied Crypto - Model -based Forensic and Privacy graphic Protocols Security Integration. HCI and Secure Compo - Network Security Security nent platforms 3

Network security protocols Primarily key management � Cryptography reduces many problems to key management � Also denial-of-service, other issues Hard to design and get right � People can do an acceptable job, eventually � Systematic methods improve results Practical case for software verification � Even for standards that are widely used and carefully reviewed, automated tools find flaws 4

Recent and ongoing protocol efforts Wireless networking authentication 802.11i – improved auth for access point � 802.16e – metropolitan area networks � Simple config – setting up access point � Mobility Mobile IPv6 – update IP addr to avoid triangle routing � VoIP SIP – call referral feature, other issues � Kerberos PKINIT – public-key method for cross-domain authentication � IPSec IKEv1, JFK, IKEv2 – improved key management � 5

Mobile IPv6 Architecture Mobile Node (MN) Direct connection via binding update Corresponding Node (CN) Authentication is a requirement Home Agent (HA) Early proposals weak 6

Wireless Authentication 7

802.11i Protocol Supplicant Supplicant UnAuth/UnAssoc Auth/Assoc 802.1X Blocked 802.1X UnBlocked No Key PTK/GTK 802.11 Association EAP/802.1X/RADIUS Authentication MSK 4-Way Handshake Group Key Handshake Data Communication 8

Needham-Schroeder Protocol { A, NonceA } Kb A B { NonceA, NonceB } Ka { NonceB} Kb Result: A and B share two private numbers not known to any observer without Ka -1 , Kb -1 9

Anomaly in Needham-Schroeder [Lowe] { A, Na } Ke A E { Na, Nb } Ka { Nb } Ke { A, Na } { Na, Nb } Evil agent E tricks Kb Ka honest A into revealing private key Nb from B. B Evil E can then fool B. 10

Needham-Schroeder Lowe { A, NonceA } Kb { NonceA, B, NonceB } A B Ka { NonceB} Kb Authentication? Secrecy? Replay attack Forward secrecy? Denial of service? Identity protection? 11

Explicit Intruder Method Informal Formal Intruder Protocol Protocol Model Description Analysis Find error Tool 12

Run of protocol Initiate B Respond A Attacker C D Correct if no security violation in any run 13

Automated Finite-State Analysis Define finite-state system � Bound on number of steps � Finite number of participants � Nondeterministic adversary with finite options Pose correctness condition � Can be simple: authentication and secrecy � Can be complex: contract signing Exhaustive search using “verification” tool � Error in finite approximation ⇒ Error in protocol � No error in finite approximation ⇒ ??? 14

State Reduction on N-S Protocol Base: hand 1000000 514550 optimization 100000 155709 of model 10000 17277 6981 3263 1000 1706 CSFW: 980 222 eliminate 100 58 net, max 10 knowledge 1 Merge intrud send, 1 init 2 init 2 init princ reply 1 resp 1 resp 2 resp 15

CS259 Term Projects - 2006 Security Analysis of Formalization of Security analysis of SIP OTRv2 HIPAA MOBIKE - IKEv2 Onion Routing Analysis of ZRTP Mobility and Multihoming Protocol 802.16e Multicast- Analysis of the IEEE Short-Password Key Broadcast Key 802.16e 3-way Exchange Protocol handshake Distribution Protocols Analysis of Octopus and Related Protocols http://www.stanford.edu/class/cs259/ 16

CS259 Term Projects - 2004 i KP protocol family Electronic voting XML Security IEEE 802.11i wireless Onion Routing Electronic Voting handshake protocol Secure Ad-Hoc An Anonymous Fair Distance Vector Exchange Key Infrastructure Routing E-commerce Protocol Secure Internet Live Windows file-sharing Conferencing protocols http://www.stanford.edu/class/cs259/WWW04/ 17

802.11i Protocol Supplicant Supplicant UnAuth/UnAssoc Auth/Assoc 802.1X Blocked 802.1X UnBlocked No Key PTK/GTK 802.11 Association EAP/802.1X/RADIUS Authentication MSK 4-Way Handshake Group Key Handshake Data Communication 18

Changhua He Wireless Threats Passive Eavesdropping/Traffic Analysis Easy, most wireless NICs have promiscuous mode � Message Injection/Active Eavesdropping Easy, some techniques to gen. any packet with common NIC � Message Deletion and Interception Possible, interfere packet reception with directional antennas � Masquerading and Malicious AP Easy, MAC address forgeable and s/w available (HostAP) � Session Hijacking Man-in-the-Middle Denial-of-Service: cost related evaluation 19

4-Way Handshake Blocking AA, ANonce, sn, msg1 PTK Derived SPA, SNonce, SPA RSN IE, sn, msg2, MIC PTK Derived AA, ANonce, AA RSN IE, GTK, sn+1, msg3, MIC SPA, sn+1, msg4, MIC AA, ANonce, sn, msg1 PTK confirmed PTK confirmed 802.1X Unblocked 802.1X Unblocked 20

Countermeasures Random-Drop Queue Randomly drop a stored entry if the queue is full � Not so effective � Authenticate Message 1 Use the share PMK; must modify the packet format � Reuse supplicant nonce Reuse SNonce, derive correct PTK from Message 3 � Performance degradation, more computation in supplicant � Combined solution Supplicant reuses SNonce � Store one entry of ANonce and PTK for the first Message 1 � If nonce in Message 3 matches the entry, use PTK directly � Eliminate memory DoS, only minor change to algorithm � Adopted by TGi � 21

Summary of larger study ATTACK SOLUTIONS security rollback supplicant manually choose security; authenticator restrict pre-RSNA to only insensitive data. reflection attack each participant plays the role of either authenti-cator or supplicant; if both, use different PMKs. attack on Michael cease connections for a specific time instead of re-key and countermeasures deauthentication; update TSC before MIC and after FCS, ICV are validated. RSN IE poisoning Authenticate Beacon and Probe Response frame; Confirm RSN IE in an earlier stage; Relax the condition of RSN IE confirmation. 4-way handshake adopt random-drop queue, not so effective; blocking authenticate Message 1, packet format modified; re-use supplicant nonce, eliminate memory DoS. 22

Model checking vs proof Finite-state analysis Attacks on model ⇒ Attack on protocol Formal proof Proof in model ⇒ No attack using only these attacker capabilities Finite state analysis assumes small number of principals, formal proofs do not need these assumptions 23

Protocol composition logic Protocol Honest Principals, Attacker Private Send Data Receive Alice’s information Protocol � Private data � Logic has Sends and receives � symbolic and computational semantics 24

802.11i correctness proof in PCL EAP-TLS Between Supplicant and Authentication Server � Authorizes supplicant and establishes access key (PMK) � 4-Way Handshake Between Access Point and Supplicant � Checks authorization, establish key (PTK) for data transfer � Group Key Protocol AP 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 25

SSL/TLS ClientHello ServerHello, [Certificate], [ServerKeyExchange], [CertificateRequest], ServerHelloDone S C [Certificate], ClientKeyExchange, [CertificateVerify] switch to negotiated cipher Finished switch to negotiated cipher Finished 26

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 27

Composition All necessary invariants are satisfied by basic blocks of all the sub-protocols The 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 28

Complex Flow Complex Control Flows Simple Flow 29