Protocol analysis, wireless networking, and mobility John Mitchell Stanford University
Many security Protocols u. Challenge-response • ISO 9798 -1, 2, 3; Needham-Schroeder, … u. Authentication • Kerberos u. Key Exchange • SSL handshake, IKE, JFK, IKEv 2, u. Wireless and mobile computing • Mobile IP, WEP, 802. 11 i u. Electronic commerce • Contract signing, SET, electronic cash, …
Mobile IPv 6 Architecture Mobile Node (MN) IPv 6 Direct connection via binding update Corresponding Node (CN) Home Agent (HA) u Authentication is a requirement u Early proposals weak
802. 11 i Wireless Authentication
TLS protocol layer over TCP/IP http telnet ftp Application SSL/TLS Transport Internet (TCP) (IP) Network interface Physical layer nntp
![SSL/TLS Client. Hello Server. Hello, [Certificate], [Server. Key. Exchange], [Certificate. Request], Server. Hello. Done](https://present5.com/presentation/d947271b70f75b8cd2a868d5d37b39f8/image-6.jpg "SSL/TLS Client. Hello Server. Hello, [Certificate], [Server. Key. Exchange], [Certificate. Request], Server. Hello. Done")
SSL/TLS Client. Hello Server. Hello, [Certificate], [Server. Key. Exchange], [Certificate. Request], Server. Hello. Done C [Certificate], Client. Key. Exchange, [Certificate. Verify] switch to negotiated cipher Finished S
Handshake Protocol Client. Hello C S C, Ver. C, Suite. C, NC Server. Hello S C Ver. S, Suite. S, NS, sign. CA{ S, KS } Client. Verify C S sign. CA{ C, VC } { Ver. C, Secret. C } KS S sign. C { Hash( Master(NC, NS, Secret. C) + Pad 2 + Hash(Msgs + C + Master(NC, NS, Secret. C) + Pad 1)) } (Change to negotiated cipher) Server. Finished S C { Hash( Master(NC, NS, Secret. C) + Pad 2 + Hash( Msgs + S + Master(NC, NS, Secret. C) + Pad 1)) } Master(NC, NS, Secret. C) Client. Finished C S { Hash( Master(NC, NS, Secret. C) + Pad 2 + Hash( Msgs + C + Master(NC, NS, Secret. C) + Pad 1)) } Master(N , Secret ) C S C
IKE subprotocol from IPSEC m 1 A, (ga mod p) A B, (gb mod p), sign. B(m 1, m 2) m 2 sign. A(m 1, m 2) Result: A and B share secret gab mod p Analysis involves probability, modular exponentiation, complexity, digital signatures, communication networks B
Explicit Intruder Method Informal Protocol Description Formal Protocol Find error Intruder Model Analysis Tool
Run of protocol Initiate A Respond B Attacker C D Correct if no security violation in any run
Automated Finite-State Analysis u. Define finite-state system • Bound on number of steps • Finite number of participants • Nondeterministic adversary with finite options u. Pose correctness condition • Can be simple: authentication and secrecy • Can be complex: contract signing u. Exhaustive search using “verification” tool • Error in finite approximation Error in protocol • No error in finite approximation ? ? ?
![Murj [Dill et al. ] u. Describe finite-state system • State variables with initial](https://present5.com/presentation/d947271b70f75b8cd2a868d5d37b39f8/image-12.jpg "Murj [Dill et al. ] u. Describe finite-state system • State variables with initial")
Murj [Dill et al. ] u. Describe finite-state system • State variables with initial values • Transition rules • Communication by shared variables u. Scalable: choose system size parameters u. Automatic exhaustive state enumeration • Space limit: hash table to avoid repeating states u. Research and industrial protocol verification
Applying Murj to security protocols u. Formulate protocol • Assume finite participants – Example: 2 clients, 2 servers • Assume finite message space – Represent random numbers by r 1, r 2, r 3, … – Do not allow unbounded encrypt(encrypt(…))) u. Add adversary • Control over “network” • Possible actions (shared variables) – Intercept any message – Remember parts of messages – Generate new messages, using observed data and initial knowledge (e. g. public keys)
Needham-Schroeder in Murj const Num. Initiators: 1; Num. Responders: 1; Num. Intruders: 1; Network. Size: 1; Max. Knowledge: 10; type Initiator. Id: Responder. Id: Intruder. Id: Agent. Id: ------ (1) number of initiators number of responders number of intruders max. outstanding msgs in network number msgs intruder can remember scalarset (Num. Initiators); scalarset (Num. Responders); scalarset (Num. Intruders); union {Initiator. Id, Responder. Id, Intruder. Id};
Needham-Schroeder in Murj Message. Type : enum { M_Nonce. Address, M_Nonce, M_Nonce }; Message : record source: Agent. Id; dest: Agent. Id; key: Agent. Id; m. Type: Message. Type; nonce 1: Agent. Id; nonce 2: Agent. Id; end; (2) -- types of messages -- {Na, A}Kb nonce and addr -- {Na, Nb}Ka two nonces -- {Nb}Kb one nonce ------- source of message intended destination of msg key used for encryption type of message nonce 1 nonce 2 OR sender id OR empty
Needham-Schroeder in Murj (3) -- intruder i sends recorded message ruleset i: Intruder. Id do -- arbitrary choice of choose j: int[i]. messages do -- recorded message ruleset k: Agent. Id do -- destination rule "intruder sends recorded message" !ismember(k, Intruder. Id) & -- not to intruders multisetcount (l: net, true) < Network. Size ==> var out. M: Message; begin out. M : = int[i]. messages[j]; out. M. source : = i; out. M. dest : = k; multisetadd (out. M, net); end;
Run of Needham-Schroeder u. Find error after 1. 7 seconds exploration u. Output: trace leading to error state u. Murj times after correcting error:
State Reduction on N-S Protocol
Security Protocols in Mur u. Standard “benchmark” protocols • Needham-Schroeder, TMN, … • Kerberos u. Study of Secure Sockets Layer (SSL) • Versions 2. 0 and 3. 0 of handshake protocol • Include protocol resumption u. Tool optimization u. Additional protocols • Contract-signing • Wireless networking … ADD YOUR PRODUCT HERE …
CS 259 Term Projects i. KP protocol family Electronic voting IEEE 802. 11 i wireless Onion Routing handshake protocol Secure Ad-Hoc Distance Vector Routing An Anonymous Fair Exchange E-commerce Protocol Secure Internet Live Conferencing Windows file-sharing protocols XML Security Electronic Voting Key Infrastructure
Wireless Threats Changhua He u Passive Eavesdropping/Traffic Analysis • Easy, most wireless NICs have promiscuous mode u Message Injection/Active Eavesdropping • Easy, some techniques to gen. any packet with common NIC u Message Deletion and Interception • Possible, interfere packet reception with directional antennas u Masquerading and Malicious AP • Easy, MAC address forgeable and s/w available (Host. AP) u Session Hijacking u Man-in-the-Middle u Denial-of-Service: cost related evaluation
Wireless Security Evolution u 802. 11 (Wired Equivalent Protocol) • • Authentication: Open system (SSID) and Shared Key Authorization: some vendor use MAC address filtering Confidentiality/Integrity: RC 4 + CRC Completely insecure u WPA: Wi-Fi Protected Access • Authentication: 802. 1 X • Confidentiality/Integrity: TKIP • Reuse the legacy hardware, still problematic u IEEE 802. 11 i (Ratified on June 24, 2004 ) • • Mutual authentication Data confidentiality and integrity: CCMP Key management Availability
RSNA Conversations Supplicant Un. Auth/Un. Asso Auth/Assoc c 802. 1 X Blocked Un. Blocked PMK MSK No Key New GTK PTK/GTK Authenticator Auth/Assoc Un. Auth/Un. Asso 802. 1 X Blocked c Un. Blocked PMK No Key 802. 1 X Blocked New GTK PTK/GTK No Key 802. 11 Association EAP/802. 1 X/RADIUS Authentication 4 -Way Handshake Group Key Handshake Data Communication Authentic a-tion Server (RADIUS) MSK No Key MS K
Security Level Rollback Attack Supplicant RSNA enabled Pre-RSNA enabled Authenticator RSNA enabled Pre-RSNA enabled Bogus Beacon (Pre-RSNA only) Beacon + AA RSN IE Probe Request Bogus Probe Response (Pre-RSNA only) Probe Response + AA RSN IE 802. 11 Authentication Request 802. 11 Authentication Response Bogus Association Request (Pre-RSNA only) Association Request + SPA RSN 802. 11 Association Response IE Pre-RSNA Connections
Solutions u. Security Level Rollback Attack • Similar to general version rollback attack • Destroy security since WEP is insecure • Not vulnerability of 802. 11 i standard, but an implementation problem u. Solutions • Allow only RSNA connections: secure, but too strict for common networks, where Transient Security Network is more convenient • Deploy both, but – Supplicant manually choose to deny or accept – Authenticator limit pre-RSNA connections to only insensitive data
Reflection Attack Adversary Impersonates Communicating Peers Legitimate Devices Authenticator and {A 1, Nonce 1, sn, Supplicant msg 1} {A 2, Nonce 1, sn, msg 1} {A 1, Nonce 2, RSN IE, sn, msg 2, MIC} {A 2, Nonce 2, RSN IE, sn, msg 2, MIC} {A 1, Nonce 1, RSN IE, GTK, sn+1, msg 3, MIC} {A 2, Nonce 1, RSN IE, GTK, sn+1, msg 3, MIC} {A 1, sn+1, msg 4, MIC}{SPA, sn+1, msg 4, MIC} Peers Bogus Authenticated Authentication
Reflection Solutions u. Possible in ad hoc networks u. Violates mutual authentication u. Solutions: • Restrict each entity to single role – Access point is not wireless station • Allow one entity to have two roles – But require different pairwise master keys (PMK)
802. 11 i Availability u Not an original design objective u Physical Layer Do. S attacks • Inevitable but detectable, not our focus u Network and upper Layer Do. S attack • Depend on protocols, not our focus u Link Layer attack • • • Flooding attack: Lots of traffic and power req’d Some Known Do. S attacks in 802. 11 networks Do. S attack on Michael algorithm in TKIP RSN IE Poisoning/Spoofing 4 -Way Handshake Blocking Failure Recovery
4 -Way Handshake Blocking Supplicant Auth/Assoc 802. 1 X Blocked PMK PTK Derived Authenticator Auth/Assoc 802. 1 X Blocked PMK AA, ANonce, sn, msg 1 SPA, SNonce, SPA RSN IE, sn, msg 2, MIC PTK Derived AA, ANonce, sn, Random GTK msg 1 AA, ANonce, AA RSN IE, GTK, sn+1, msg 3, MIC SPA, sn+1, msg 4, MIC AA, ANonce, sn, msg 1 PTK and GTK 802. 1 X Unblocked
Countermeasures u Random-Drop Queue • Randomly drop a stored entry if the queue is full • Not so effective u Authenticate Message 1 • Use the share PMK; must modify the packet format u Reuse supplicant nonce • Reuse SNonce, derive correct PTK from Message 3 • Performance degradation, more computation in supplicant u 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 Do. S, only minor change to algorithm Adopted by TGi
Failure Recovery u Failure recovery is important • Can reduce but not eliminate Do. S vulnerabilities u Current 802. 11 i method • When failure, restart everything: inefficient u A better failure approach • If 802. 1 X does not finish, restart everything • Otherwise restart from nearest completed subprotocol • Channel scanning time is significantly larger than the protocol execution time
Improved 802. 11 i Stage 1: Network and Security Capability Discovery Stage 2: 802. 1 X authentication (mutual authentication, shared secret, cipher suite) 802. 1 X Failure Stage 3: Secure Association (management frames protected) Association Failure Stage 4: 4 -Way Handshake (PMK confirmation, PTK derivation, and GTK distribution) 4 -Way Handshake Timout Stage 5: Group Key Handshake Timout Stage 6: Secure Data Communications Michael MIC Failure or Other Security Failures
Summary of larger study ATTACKS SOLUTIONS security rollback supplicant manually choose security; authenticator restrict pre-RSNA to only insensitive data. reflection attack each participant plays the role of either authenticator or supplicant; if both, use different PMKs. attack on Michael countermeasures cease connections for a specific time instead of re-key and 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 blocking adopt random-drop queue, not so effective; authenticate Message 1, packet format modified; re-use supplicant nonce, eliminate memory Do. S.
802. 11 i correctness proof in PCL u EAP-TLS • Between Supplicant and Authentication Server • Authorizes supplicant and establishes access key (PMK) u 4 -Way Handshake • Between Access Point and Supplicant • Checks authorization, establish key (PTK) for data transfer u Group Key Protocol • AP distributes group key (GTK) using KEK to supplicants u AES based data protection using established keys Our proof covers subprotocols 1, 2, 3 alone and in various combinations
![SSL/TLS Client. Hello Server. Hello, [Certificate], [Server. Key. Exchange], [Certificate. Request], Server. Hello. Done](https://present5.com/presentation/d947271b70f75b8cd2a868d5d37b39f8/image-36.jpg "SSL/TLS Client. Hello Server. Hello, [Certificate], [Server. Key. Exchange], [Certificate. Request], Server. Hello. Done")
SSL/TLS Client. Hello Server. Hello, [Certificate], [Server. Key. Exchange], [Certificate. Request], Server. Hello. Done C [Certificate], Client. Key. Exchange, [Certificate. Verify] switch to negotiated cipher Finished S
TLS Protocol: Client The TLS Server actions also defined by a straight-line sequential process (cord)
TLS Properties u. Authentication: client and the server agree on • • Master secret Protocol version and crypto suite Each other’s identities Protocol completion status u. Secrecy • The master secret must not be known to any other principal
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
Invariants required by TLS Server Side Recommendation: If the server reuses Public Key in a protocol different from TLS, then it should not send decryptions of incoming messages
4 -Way handshake: Authenticator Supplicant actions also defined by a straight-line sequential process (cord)
4 -Way Handshake properties u. The pairwise key (PTK) is fresh and correctly generated from the PMK u. Messages 2 and 4 assure authenticator that supplicant messages are current (not replay) u. Message 3 assures supplicant that authenticator messages are current (not replay) u. Pairwise key PTK derivation produces shared secret between supplicant and authenticator
4 -way Handshake Properties Similar specification for server
4 -Way : Relating invariants to deployment Recommendation: One Principal should not act as both authenticator and supplicant ! Otherwise, reflection attack. Consider careful deployment in Sensor Network scenarios
Group-Key Protocol
Group key handshake u Authenticator guarantee: If principal has the group key, then it must have a shared PTK with the authenticator u. Supplicant guarantee: the GTK received was transmitted by the Access Point, and correctly supersedes any GTK from earlier handshakes (4 -Way or Group Key) Observation: For assurance of GTK freshness, important that the first handshake uses 4 -Way protocol; one principal should not be authenticator and supplicant, as in the 4 -way handshake.
Composition u All necessary invariants are satisfied by basic blocks of all the subprotocols u The postconditions of TLS imply the preconditions of the 4 -Way handshake u. The postconditions of 4 -Way handshake imply the preconditions of the Group Key protocol
Complex Control Flows Simple Flow Complex Flow
And what about mobility … ? Arnab Roy u. IPv 4: Triangle routing • All traffic routed through home agent u. IPv 6: Binding update • Mobile node sends new “care-of address” • Many risks – Attacker can subvert existing connection • Announce false care-of address – Also, can send lots of packets to target • Announce that target is new care-of address for many connections
Representative protocol Corresponding node X, Y, H 2 Y, X, n 4 X, Y, hash(m, n, H, X) Y 1 1 X 2 2 2 Y, H, m, X 4 Mobile node 3 3 H, X, m, Y H Home agent
Current situation u. Under strong assumptions • Assume limited read access to messages • Can prove that CN receives a good address u. Under more realistic assumptions • Have found many attacks
Conclusions u. Protocol analysis methods • Model checking is fairly easy to apply • Ready for industrial use u. Wireless 802. 11 i • Automated study led to improved standard • Deployment recommendations also u. Mobile networking • Partial analysis so far • No clear guarantees without key infrastructure
Скачать презентацию Protocol analysis wireless networking and mobility John Mitchell
d947271b70f75b8cd2a868d5d37b39f8.ppt