Transcript Document 7858388

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
Traffic Encryption Key (TEK) Management
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: {AK}Kms, Lifetime, SeqNum, SAIDList
TEK Management
After initial authentication, BS initiates a 3way 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_KEK{TEK}, Parameters, HMAC/CMAC
Vulnerabilties
Similar Security architecture to 802.11i
Vulnerable to similar DoS attacks?
CS 259
MOBIKE Summary
Faisal Memon
Erik Weathers
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.
MOBIKE Init Exchange
I
KEi, Ni
KEr, Nr
{IDi, MOBIKE}KIR
{IDr, MOBIKE}KIR
Typical IKEv2 init exchange, with
notify declaring support for MOBIKE.
R
MOBIKE Address Change Exchange
I2
{UpdateSA_Address}KIR
{ACK}KIR
{Cookie}KIR
{Cookie}KIR
Initiator IP address changed to I2.
Cookie exchange is for optional return
routability verification.
R
Scott’s Protocol
Scott Lulovics
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)
Efficient-Short-Password KeyExchange (ESP-KE) protocol
Global 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.
ESP-KE
A = αa / βP mod p
A→
←B
k = Ba mod p
← Mb
If H(0, k, P) ≠ Mb: Abort
Ma = H(1, k, P)
Ma →
B = αb mod p
If A = 0:Abort
k = (A · βP)b mod p
Mb = H(0, k, P)
If H(1, k, P) ≠ Ma:
Abort
CS 259
Slicing the Onion: Anonymous
Routing without PKI
http://nms.lcs.mit.edu/~sachin/slicing.html
Saurabh Shrivastava
What is Onion Routing
Na
Bob
Nb
Nc
Nd
Alice
-
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
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?
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?
OTR
Joseph Bonneau
Andrew Morrison
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.
OTR Protocol
A
B
PGPfone
Jeremy Robin
Andrew Schwartz
PGPFone
Philip Zimmermann’s protocol for secure
VOIP
Designed to withstand online attacks
attacks on the physical premises
The Protocol Itself
Hello Packet
DHHash Packet
DHPublic Packet
Info Packet
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
Diameter
Ryan Wisnesky
Taral Joglekar
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.
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
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?
 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’
Analysis of GODI (Group Domain
of Interpretation) protocol
CS259 Project Proposal
Ju-Yi Kuo
2 / 2 / 2006
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-ondemand
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.
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.
GDOI Security Association
Server
Kas, Kbs, KEK
Alice
Bob
Kas, KEK, TEK
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.
Group Key Pull excahnge
M-ID , { HASH(1) , Ni , ID } Kas
A
S
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.
Group Key Pull excahnge (cont.)
M-ID , { HASH(1) , Ni , ID } Kas
M-ID , { HASH(2) , Nr , SA } Kas
A
S
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 )
Group Key Pull excahnge (cont.)
M-ID , { HASH(1) , Ni , ID } Kas
M-ID ,{ HASH(2) , Nr , SA } Kas
A
S
M-ID ,{ HASH(3) , KE_I [, CERT] } 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 certificate
HASH(3) = hash( SKEYID_a , M-ID , Ni , Nr , KE_I )
Group Key Pull excahnge (cont.)
M-ID , { HASH(1) , Ni , ID } Kas
M-ID ,{ HASH(2) , Nr , SA } Kas
A
S
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 responder’s 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 )
Group Key Push excahnge
M-ID , { SEQ , SA , KD , [CERT ,] SIG } KEK
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 parameters
KD: new key download, include new KEK and TEK
CERT: optional server certificate
SIG: signature of the entire message, signed by the server
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.
SIP
Greg Nelson
Duc Pham
Basic Protocol
Call Setup:
INVITE
A
INVITE
Proxy
OK
OK
INVITE
Proxy
OK
B
ACK
Call Session:
“Blah blah blah…”
A
B
“Yadda yadda yadda…”
Call Termination:
BYE
A
OK
B
Vulnerabilities
Proxy Impersonation
Message Tampering
Session Teardown

Spoofed BYEs
Denial of Service


Malformed packets
REGISTER and INVITE flooding
Registration Hijacking
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 can’t learn To, From
tags
Denial of Service

Authenticate and authorize registrations
What We Will Do
Model basic protocol without security (Murphi or
Avispa)

Some security mechanisms aren’t a “MUST” in the RFC, so
they’re 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?
Formalizing the Health Insurance Portability
and Accountability Act (HIPAA)
Simon Berring, Navya Rehani, and Dina Thomas
2nd Feb 2006
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
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.):
(tphi)
inrole(p1, covered-entity)  inrole(p2, individual)  (q = p2) 
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)