802.16e
DESCRIPTION
802.16e. Vijay Chauhan Srinivas Inguva. 802.16 Overview. Basic Idea: Metropolitan area wireless broadband service. Main roles involved in 802.16: Base Station (BS) Mobile Station (MS) / Subscriber Station (SS) Two security protocols of interest: Authentication/Authorization protocol - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/1.jpg)
802.16eVijay ChauhanSrinivas Inguva
![Page 2: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/2.jpg)
802.16 OverviewBasic Idea: Metropolitan area wireless broadband service.Main roles involved in 802.16: Base Station (BS) Mobile Station (MS) / Subscriber Station (SS)
Two security protocols of interest: Authentication/Authorization protocol Traffic Encryption Key (TEK) Management
![Page 3: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/3.jpg)
Authentication ProtocolGoals: Authentication using X.509 certificates and/or
EAP Establish a shared secret, called the
Authorization Key (AK)AK is used to generate various other keysStructure of a certificate based Authentication exchange:MS → BS: Cert(Manufacturer(MS))MS → BS: Cert(MS), Capabilities, SAIDBS → MS: {AK}Kms, Lifetime, SeqNum, SAIDList
![Page 4: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/4.jpg)
TEK ManagementAfter initial authentication, BS initiates a 3-way handshake to transfer TEKs to MS TEKs generated by BS Have a specified lifetime, after which new
TEK is requested by MSStructure of the 3-way handshake:Challenge: BS → MS: NBS, SeqNum, AKID, HMAC/CMACRequest: MS → BS: NBS, NMS, SeqNum, AKID, Capabilities, Parameters, Settings, HMAC/CMACResponse: MS → BS: NBS, NMS, SeqNum, AKID, SAID, E_KEK{TEK}, Parameters, HMAC/CMAC
![Page 5: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/5.jpg)
Vulnerabilties
Similar Security architecture to 802.11iVulnerable to similar DoS attacks?
![Page 6: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/6.jpg)
MOBIKE Summary
Faisal MemonErik Weathers
CS 259
![Page 7: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/7.jpg)
MOBIKEIKEv2 Mobility and Multihoming Protocol As defined in draft-ietf-mobike-protocol-07.txt Main purpose
For roaming devices (devices which move and hence have changing IP addresses), that want to keep the existing IKE and IPsec SAs in place despite the IP address changing, and without requiring a full rekey.
Secondary purpose Multihomed (multiple interface) device which
decides to change its IKE endpoint IP. Could be a result of link failure or other conditions.
![Page 8: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/8.jpg)
MOBIKE Init Exchange
KEi, Ni
I R KEr, Nr
{IDi, MOBIKE}KIR
{IDr, MOBIKE}KIR
Typical IKEv2 init exchange, with notify declaring support for
MOBIKE.
![Page 9: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/9.jpg)
{Cookie}KIR
MOBIKE Address Change Exchange
{UpdateSA_Address}KIR
I2 R {ACK}KIR
{Cookie}KIR
Initiator IP address changed to I2.Cookie exchange is for optional return routability verification.
![Page 10: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/10.jpg)
Scott’s ProtocolScott Lulovics
![Page 11: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/11.jpg)
Scott's Password-based Protocol
● “Efficient Short-Password key exchange and Log-in Protocols” - Michael Scott, September 2001
● Based on the Diffie-Hellman key exchange and El Gamal public key encryption algorithms
● Faster than existing techniques (the password is short)
![Page 12: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/12.jpg)
Efficient-Short-Password Key-Exchange (ESP-KE) protocolGlobal values
p – prime number q – prime divisor α and β – unrelated generators of the
prime order sub-group of order q
Password P known to Alice and Bob. (P << q)
Alice and Bob choose random numbers a and b, respectively, such that 1≤ a,b < q.
![Page 13: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/13.jpg)
ESP-KEA = αa / βP mod p
A →
k = Ba mod p
If H(0, k, P) ≠ Mb: Abort
Ma = H(1, k, P)
Ma →
B = αb mod p← B
If A = 0:Abortk = (A · βP)b mod pMb = H(0, k, P)
← Mb
If H(1, k, P) ≠ Ma: Abort
![Page 14: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/14.jpg)
Slicing the Onion: Anonymous Routing without
PKI
Saurabh Shrivastava
CS 259
http://nms.lcs.mit.edu/~sachin/slicing.html
![Page 15: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/15.jpg)
What is Onion Routing
Bob
Alice
Na NbNc Nd
- packets are encrypted in layers- each node decrypts the packet using its key, figures out the next hop- usually public/private key pairs used, but here symmetric keys will be used - how to distribute the keys to nodes? use information slicing: split the key into
lots of pieces, send them on disjoint paths to the respective target nodes
![Page 16: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/16.jpg)
Anonymity Degree of Anonymity
- Measured as entropy of the system Unlinkability
- … of different actions by a single user Source/Destination anonymity
- Source is hidden from all nodes including destination, (same argument for destination)
Implementing Anonymity- Which Key Exchange mechanism?- Which nodes chosen?- Node failures?
![Page 17: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/17.jpg)
Project
Authors acknowledge that an “omni present” adversary can break this scheme, so how strong an adversary can this scheme defend against?
Are there any weaknesses in the symmetric key distribution scheme?
How does a PRISM model compare with the author’s analysis of entropy, unlinkability, source/destination anonymity
Any other suggestions?
![Page 18: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/18.jpg)
OTR Joseph Bonneau Andrew Morrison
![Page 19: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/19.jpg)
Authentication Public Key Authentication.
Secrecy AES Encryption of messages using symmetric
keys.Perfect Forward Secrecy
Short lived keys, discarded after use. Long lived keys are used to authenticate and generate new keys.
Repudiation Use keyed MAC, and give out MAC values once
used so that old messages are forgable.
OTR Goals
![Page 20: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/20.jpg)
OTR Protocol
A B
![Page 21: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/21.jpg)
DiameterRyan WisneskyTaral Joglekar
![Page 22: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/22.jpg)
Diameter OverviewThe primary goal of the Diameter is to provide a
way for application specific attribute-value pairs to travel, while enforcing basic authorization and accounting. Messages are sets of arbitrary attribute value pairs
and Diameter related bookkeeping fields. Therefore, security services must be provided by
other protocols. (It also means diameter messages can be used to implement other protocols…)
It does provide state machines for session management, routing, accounting, etc.
![Page 23: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/23.jpg)
Idea 1: End-to-End Security
Diameter provides a way for messages to be routed. Passive: message contents do not change, aside from routing info. Active: message contents do change, according to a given policy.
(We aren’t sure what exactly a policy can or can’t do yet.) (Not unlike a hub vs. NAT’d router)
Diameter messages are processed at the application layer at each agent. Therefore, an alternative mechanism (i.e. hop-to-hop security isn’t going to work) is required to protect portions of the message at the application layer, to make sure that the proxies can’t mess with the session.
Allowing for a security association to be established through Diameter relays allows the participants to detect whether protected AVPs have been modified en-route, and hides sensitive data from intermediate agents.
What can a malicious proxy do? Interesting because proxy has access to everything
![Page 24: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/24.jpg)
Idea 2: AccountingDiameter provides a set of messages and state machine for keeping track of interesting events in a session. e.g. user service termination
A security mechanism must be previously established before accounting can start. Given a mechanism and intruder model, what
can an intruder do to the statistics? We’d be interested in results of the form ‘the
statistics can be modified in this way’ as opposed to ‘the statistics can be modified’
![Page 25: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/25.jpg)
Analysis of GODI (Group Domain of Interpretation)
protocol
Ju-Yi KuoCS259 Project
Proposal
2 / 2 / 2006
![Page 26: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/26.jpg)
GODI Protocol GODI (RFC 3547) protocol provides key
management for a group of principals Such protocol can be used to secure multicasting of
voice or video among a group, or video-on-demand Terminology:
GCKS: Group controller and key server. Responsible for distributing the group key to the group. It also adds new member to the group if requested, as well as deletes member from a group.
Sender, receiver: any principal in the group can securely send or receive traffic to the group.
![Page 27: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/27.jpg)
GODI Protocol (cont.) GODI requires a “phase 1” sub-protocol to
first establish authentication & pair-wise key between GCKS and a principal. A shared secret SKEYID_a is also established. Then in phase 2, GODI performs group related operations.
The protocol defines 2 types of exchanges: Group-Key Pull exchange
When a principal wants to join a group, it performs a 4-message exchange with the GCKS
Group-Key Push exchange
GCKS sends this message to distribute new key to the group. This can be performed when a member leaves the group.
![Page 28: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/28.jpg)
GDOI Security Association
Kas and Kbs are pre-established pairwise keys established in phase 1, which secure the traffic between server and each principal.KEK is Key-Encryption-Key. When Server wants to push down fresh TEK to members, it will be encrypted by the KEK.TEK is Traffic-Encryption-Key between group members. It protects the communications between group member A and B.
ServerKas, Kbs, KEK
AliceKas, KEK, TEK
BobKbs, KEK, TEK
![Page 29: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/29.jpg)
Group Key Pull excahnge
A S
M-ID , { HASH(1) , Ni , ID } Kas
A is the initializer who wants to join the group and pull down group keys, and S is the responding GCKS server.
M-ID: a message ID that label this particular round of exchangeID: this is the ID of the group that A wants to join.Ni is the nonce from the initiator A.HASH(1) is defined as: hash( SKEYID_a, M-ID , Ni , ID ) , where SKEYID_a is a shared secret established in phase 1 between A and S.
![Page 30: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/30.jpg)
Group Key Pull excahnge (cont.)
A S
M-ID , { HASH(1) , Ni , ID } Kas
S responds without sending any key material, because S is not sure of A’s liveliness yet.
Nr is the nonce from the responder S.SA: security association policy & parameters (crypto suite, key length, key lifetime, etc)HASH(2) = hash( SKEYID_a , M-ID , Ni , Nr , SA )
M-ID , { HASH(2) , Nr , SA } Kas
![Page 31: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/31.jpg)
Group Key Pull excahnge (cont.)
A S
M-ID , { HASH(1) , Ni , ID } Kas
KE_I is the initiator’s half of the Diffie-Hellman key exchange, which will become the KEK.CERT is the optional initiator’s certificateHASH(3) = hash( SKEYID_a , M-ID , Ni , Nr , KE_I )
M-ID ,{ HASH(2) , Nr , SA } Kas
M-ID ,{ HASH(3) , KE_I [, CERT] } Kas
![Page 32: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/32.jpg)
Group Key Pull excahnge (cont.)
A S
M-ID , { HASH(1) , Ni , ID } Kas
KE_R is the responder’s half of the Diffie-Hellman key exchangeSEQ is a sequence number, which the server increments after each Group Key Pull and Group Key Push exchange.KD: key download, which can be TEKHASH(4) = hash( SKEYID_a , M-ID , Ni , Nr , KE_R , SEQ , KD )
M-ID ,{ HASH(2) , Nr , SA } Kas
M-ID ,{ HASH(3) , KE_I , CERT, POP_I } Kas
M-ID ,{ HASH(4) , KE_R , SEQ , KD , CERT , POP_R } Kas
![Page 33: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/33.jpg)
Group Key Push excahnge
A S
When a member leaves or when key lifetime expires, the server will push down new key materials to all members.
SEQ is the sequence number.SA: the new security association policy and parametersKD: new key download, include new KEK and TEKCERT: optional server certificateSIG: signature of the entire message, signed by the server
M-ID , { SEQ , SA , KD , [CERT ,] SIG } KEK
![Page 34: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/34.jpg)
Security Goals The secrecy of the keys. Perfect forward secrecy: if any member is
compromised (pair-wise key leaked), the intruder cannot know the traffic that happens before that.
Authentication & integrity of the GCKS push messages
Freshness of keys. Old keys may not be re-used. Security parameters (key length, lifetime, etc) are
not altered.The Analysis Phase 1 is assumed to be secure. It will not be
analyzed here. The RFC defines certain payloads to be optional.
They will be included in the analysis. Analysis tool : using either Murphi or Avispa.
![Page 35: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/35.jpg)
SIP
Greg NelsonDuc Pham
![Page 36: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/36.jpg)
Basic ProtocolCall Setup:
BA Proxy ProxyINVITEINVITE INVITE
OK OK OK
Call Teardown:
BA Proxy ProxyBYEBYE BYE
OK OK OK
![Page 37: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/37.jpg)
VulnerabilitiesProxy ImpersonationMessage TamperingSession Teardown (Spoofed BYEs)Denial of Service Malformed packets INVITE floodingRegistration Hijacking
![Page 38: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/38.jpg)
What We Will DoModel basic protocol without security Like many implementations on the market!Incrementally add security mechanisms Authentication Message Integrity DoS ProtectionSee what problems get solved, introduced
![Page 39: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/39.jpg)
Formalizing the Health Insurance Portability and Accountability Act (HIPAA)
Simon Berring, Navya Rehani, and Dina Thomas
2nd Feb 2006
![Page 40: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/40.jpg)
What is the HIPAA Privacy Law?Providers and insurers must comply with your right to: Ask and see a copy of your health records Have corrections added to your health information Receive a notice that tells you how your health information is used and shared Decide whether to give your permission before your information can be used or shared for certain purpose Ask to be reached somewhere outside your home File complaints
![Page 41: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/41.jpg)
We use typed, first order, linear temporal logic. with types: = Agent |Message | Property | Context
with grammar:
with invariants:
with norms (e.g.): inrole(p1, covered-entity) inrole(p2, individual) (q = p2) (tphi)
We interpret the standard (or a subset thereof) as a set of guarantees We formalize the guarantees as security invariants We use LTL tools (STep, SPIN) to verify the invariants for an implementation
Formalization in Temporal Logic
![Page 42: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/42.jpg)
PGPFoneAndrew SchwartzJeremy Robin
![Page 43: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/43.jpg)
PGPFonePhilip Zimmermann’s protocol for secure VOIPDesigned to withstand online attacksattacks on the physical premises
![Page 44: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/44.jpg)
The Protocol ItselfHello PacketDHHash PacketDHPublic PacketInfo Packet
![Page 45: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/45.jpg)
Protocol, cont.Users of the protocol are instructed to use a biometric word list to exchange the first few bytes of a hash of the shared secretThis relies on the human voice not being easily duplicated
![Page 46: 802.16e](https://reader034.vdocuments.mx/reader034/viewer/2022042617/56814cff550346895dba25a0/html5/thumbnails/46.jpg)
Rules - Permitted disclosures of PHI - Authorized use and disclosure - Notice and Individual Rights - Others....Goals - Does a HCP's implementation of HIPAA violate protection of PHI? - What parts of these rules are essential for achieving protection? Challenges - Very little to no prior work - No unique mathematical interpretation to some textual rules - Very vast (to counter this we plan to use abstraction and/or concentration on a small part of the system)
Goals and Challenges