802.16e

1
802.16e

• Vijay Chauhan
• Srinivas Inguva

2
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
• Traffic Encryption Key (TEK) Management

3
Authentication Protocol

• Goals
• Authentication using X.509 certificates and/or
  EAP
• Establish a shared secret, called the
  Authorization Key (AK)
• AK is used to generate various other keys
• Structure of a certificate based Authentication
  exchange
• MS ? BS Cert(Manufacturer(MS))
• MS ? BS Cert(MS), Capabilities, SAID
• BS ? MS AKKms, Lifetime, SeqNum, SAIDList

4
TEK Management

• After 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 MS
• Structure of the 3-way handshake
• Challenge BS ? MS NBS, SeqNum, AKID,
  HMAC/CMAC
• Request MS ? BS NBS, NMS, SeqNum, AKID,
  Capabilities, Parameters, Settings, HMAC/CMAC
• Response MS ? BS NBS, NMS, SeqNum, AKID,
  SAID, E_KEKTEK, Parameters, HMAC/CMAC

5
Vulnerabilties

• Similar Security architecture to 802.11i
• Vulnerable to similar DoS attacks?

6
MOBIKE Summary
CS 259

• Faisal Memon
• Erik Weathers

7
MOBIKE

• IKEv2 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.

8
MOBIKE Init Exchange

• KEi, Ni

KEr, Nr
I
R
IDi, MOBIKEKIR
IDr, MOBIKEKIR
Typical IKEv2 init exchange, with notify
declaring support for MOBIKE.
9
MOBIKE Address Change Exchange

• UpdateSA_AddressKIR

ACKKIR
I2
R
CookieKIR
CookieKIR
Initiator IP address changed to I2. Cookie
exchange is for optional return routability
verification.
10
Scotts Protocol

• Scott Lulovics

11
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)

12
Efficient-Short-Password Key-Exchange (ESP-KE)
protocol

• Global values
• p prime number
• q prime divisor
• a and ß unrelated generators of the prime order
  sub-group of order q
• Password P known to Alice and Bob. (P ltlt q)
• Alice and Bob choose random numbers a and b,
  respectively, such that 1 a,b lt q.

13
ESP-KE

• A aa / ßP mod p A ?
• k Ba mod p
• If H(0, k, P) ? Mb Abort
• Ma H(1, k, P) Ma ?

• B ab mod p
• ? B
• If A 0Abort
• k (A ßP)b mod p
• Mb H(0, k, P)
• ? Mb
• If H(1, k, P) ? Ma Abort

14
Slicing the Onion Anonymous Routing without PKI
CS 259
http//nms.lcs.mit.edu/sachin/slicing.html

• Saurabh Shrivastava

15
What is Onion Routing

• - 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

16
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?

17
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 authors
  analysis of entropy, unlinkability,
  source/destination anonymity
• Any other suggestions?

18
OTR

• Joseph Bonneau
• Andrew Morrison

19
OTR Goals

• 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.

20
OTR Protocol
B
A
21
PGPfone

• Jeremy Robin
• Andrew Schwartz

22
PGPFone

• Philip Zimmermanns protocol for secure VOIP
• Designed to withstand online attacks
• attacks on the physical premises

23
The Protocol Itself

• Hello Packet
• DHHash Packet
• DHPublic Packet
• Info Packet

24
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 secret
• This relies on the human voice not being easily
  duplicated

25
Diameter

• Ryan Wisnesky
• Taral Joglekar

26
Diameter Overview

• The 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.

27
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 arent sure what exactly a
  policy can or cant do yet.)
• (Not unlike a hub vs. NATd router)
• Diameter messages are processed at the
  application layer at each agent. Therefore, an
  alternative mechanism (i.e. hop-to-hop security
  isnt going to work) is required to protect
  portions of the message at the application layer,
  to make sure that the proxies cant 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

28
Idea 2 Accounting

• Diameter 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?
• Wed be interested in results of the form the
  statistics can be modified in this way as
  opposed to the statistics can be modified

29
Analysis of GODI (Group Domain of Interpretation)
protocol
CS259 Project Proposal

• Ju-Yi Kuo

2 / 2 / 2006
30
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.

31
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.

32
GDOI Security Association
Server Kas, Kbs, KEK
Alice Kas, KEK, TEK
Bob Kbs, KEK, TEK

• 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.

33
Group Key Pull excahnge
S
A
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 exchange
• ID 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.

34
Group Key Pull excahnge (cont.)
S
A
M-ID , HASH(1) , Ni , ID Kas
M-ID , HASH(2) , Nr , SA Kas

• S responds without sending any key material,
  because S is not sure of As 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 )

35
Group Key Pull excahnge (cont.)
S
A
M-ID , HASH(1) , Ni , ID Kas
M-ID , HASH(2) , Nr , SA Kas
M-ID , HASH(3) , KE_I , CERT Kas

• KE_I is the initiators half of the
  Diffie-Hellman key exchange, which will become
  the KEK.
• CERT is the optional initiators certificate
• HASH(3) hash( SKEYID_a , M-ID , Ni , Nr , KE_I )

36
Group Key Pull excahnge (cont.)
S
A
M-ID , HASH(1) , Ni , ID Kas
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

• KE_R is the responders half of the
  Diffie-Hellman key exchange
• SEQ is a sequence number, which the server
  increments after each Group Key Pull and Group
  Key Push exchange.
• KD key download, which can be TEK
• HASH(4) hash( SKEYID_a , M-ID , Ni , Nr , KE_R
  , SEQ , KD )

37
Group Key Push excahnge
S
A
M-ID , SEQ , SA , KD , CERT , SIG KEK

• 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
  parameters
• KD new key download, include new KEK and TEK
• CERT optional server certificate
• SIG signature of the entire message, signed by
  the server

38
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.

39
SIP

• Greg Nelson
• Duc Pham

40
Basic Protocol

• Call Setup

Proxy
Proxy
INVITE
INVITE
INVITE
B
A
OK
OK
OK
ACK
Call Session
Blah blah blah
B
A
Yadda yadda yadda
Call Termination
BYE
B
A
OK
41
Vulnerabilities

• Proxy Impersonation
• Message Tampering
• Session Teardown
• Spoofed BYEs
• Denial of Service
• Malformed packets
• REGISTER and INVITE flooding
• Registration Hijacking

42
SIP Security

• Registration hijacking
• Authenticate originators of requests
• Proxy impersonation
• Authenticate servers
• Message tampering
• Secure body and certain headers end-to-end
• Session teardown
• Authenticate sender of BYE
• Confidentiality so attacker cant learn To, From
  tags
• Denial of Service
• Authenticate and authorize registrations

43
What We Will Do

• Model basic protocol without security (Murphi or
  Avispa)
• Some security mechanisms arent a MUST in the
  RFC, so theyre often left out in many
  implementations on the market!
• Incrementally add security mechanisms (rational
  reconstruction)
• Authentication
• Message Integrity
• DoS Protection
• What are the consequences?
• All vulnerabilities get fixed?
• Introduces new unforeseen problems?
• Some problems cannot be fixed?

44
Formalizing the Health Insurance Portability and
Accountability Act (HIPAA)
Simon Berring, Navya Rehani, and Dina
Thomas 2nd Feb 2006
45
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

46
Formalization in Temporal Logic

• 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

• 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) ? (t?phi)

47
Goals and Challenges
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)