The HIP Diet Exchange
HIP DEX
Robert Moskowitz
ICSA labs
an Independent Division of
Verizon Business
July 26, 2010
rgm@labs.htt-consult.com
1
Purpose of this presentation
•
Present work on a new HIP Exchange specifically
architected for resource limited devices by
– Explain why HIP BEX is not suited for these
devices
– Explain the new HIP Diet Exchange (HIP DEX)
• And using it to key 802.15 MACsec
– Possible directions for HIP
– Next steps
2
Why not HIP BEX?
•
Characteristics of 802.15.4 (Low Rate
Wireless Personal Area Networks)
– Over-the-air data rates of 250 kb/s, 100kb/s,
40 kb/s, and 20 kb/s
– Low power consumption
•
•
Small Processors with minimum memory
Typically battery operated
3
Putting HIP on a Diet
Basic premise
•
•
•
The HIP Diet Exchange – HIP DEX
Use static ECDH as Host Identities
With ECDH derived key only used for session
key protection
–
–
Master Key in 802.11 terminology
Randomly generated a key and encrypted with
DH derived key
•
•
•
•
CMAC function now defined for Diffie-Hellman key
as the the Master Key
Key derivation from random key can use CMAC
We do not need a hash function!
We can 'manage' without Digital Signatures
4
HIP Diet Exchange (DEX)
•
•
–
–
–
–
–
–
–
–
Parties are
I ::= Initiator
R ::= Responder
MR ::= Malicious Responder
MI ::= Malicious Initiator
Functions are
ECR ::= AES encrypt
MAC ::= CMAC
| ::= concatenation
EX ::= Key expansion
5
HIP Diet Exchange (DEX)
•
–
–
–
–
–
–
–
Values are
PK ::= Public key of
• e.g. Pki is Public key of I
DHk ::= Derived Diffie-Hellman key compressed
via CMAC with nonce as key
DHlist ::= List of ECDH key sizes supported
n ::= nonce
Pn ::= Puzzle based on and containing nonce n
Sn ::= Puzzle solution based on nonce n
x,y ::= random secrets
6
HIP Diet Exchange (DEX)
• The HIP DEX, rather than a BEX, exchange is
identified by a DEX HIT
–
I & R HITs included in exchange headers
I or MI
R or MR
I1 ::=
R1 ::=
I2 ::=
(DHlist)
<---
------>
Pn, Pkr, DHlist
Sn, PKi, ECR(DHk,x|n), MAC(DHk,(Sn, PKi, ECR(DHk,x|n))) ------>
I or MI
R2 ::=
R
<---
DHlist, ECR(DHk,y|n), MAC(DHk, (DHlist, ECR(DHk,y|n)))
I
R
<---
Data, MAC(EX(x,y), Data) ------>
Note be end of exchange, parties can ONLY be R and I.
7
Putting HIP on a Diet
Summary of Crypto Components
•
A 'Dietetic' HIP exchange CAN be achieved
with
–
AES-CBC (and CMAC)
•
–
AES-CCM used by ESP or MACsec
Static ECDH
•
•
I2 and R2 MACs prove private key ownership
Can be installed by manufacturer
–
ECDH key derivation typically only occurs for initial
join
8
HIP Diet Exchange (DEX)
Dealing with a lossful network
•
HIP BEX can be slow with packet loss
–
•
DEX MUST deal with high packet loss
Implement a repeated send until ACK
–
Alternative to 802.15 immediate ACK
•
–
–
–
–
Which is not effective on multihop or off PAN
I aggressively sends I1 and continues send it
until it receives R1
R sends R1 for every I1 received
I aggressively sends I2 and continues send it
until it receives R2, then it transitions to
connected state
R sends R2 for every I2 received, it transitions
to connected state when it starts receiving
datagrams
9
HIP Diet Exchange (DEX)
Adding Password Authentication
•
Password Augmented Authentication
–
–
Provides bootstrap mechanism to add a node to
a controller
Supports emergency adHoc access
•
•
•
EMT access to a Pacemaker
Utility field technician to a substation controller
Controller implicitly invites password Auth
–
R1 ALWAYS contains a challenge
•
–
The Puzzle values
Initiator MACs challenge with password and
encrypts that in the DH derived key
10
HIP Diet Exchange (DEX)
Adding Password Authentication
•
Challenge Encryption
–
Use password as CMAC key
•
•
MAC nonce from R1 puzzle
–
Encrypting a challenge from R1 prevents replay
attacks
–
–
R1 cannot be reused if password response is
accepted
'Rogue' Responder attack
•
–
RFC 4615 (AES-CMAC-PRF-128) is starting point
Initiator cannot tell if R1 came from Responder or
attacker unless PKr from another source
Need zero knowledge alternative
•
•
As in IEEE 802.11s SAE
And draft-harkins-ipsecme-spsk-auth
11
Using HIP DEX for MACsec
•
Use 6lowpan for HIP directly over MAC layer
–
•
Sec 5 for fragmentation
Develop pair-wise and broadcast/multicast key
distribution
–
–
HIP DEX has implicit concept of Master and
Pair-wise keys
Use 802.11 Group key model
•
•
Or 802.1AE?
ICMP error messages
–
Remove IP header and run directly over
6lowpan
12
HIP DEX exchanges
•
DEX provides Master and Pair-wise Keys
–
–
On initial joining of PAN and whenever new MK
needed (e.g. lost of state)
Accelerated Group key setup within exchange
•
Only if Responder is owner of key
13
HIP DEX exchanges
•
Pair-wise Key Updates
–
–
Via HIP UPDATE exchange
Frequency determined by local policy
•
–
•
Lost state or key exhausted
Only AES-CBC and CMAC functions needed
Group Key
–
–
–
Via HIP UPDATE exchange
Sent by key owner
Frequency determined by local policy
•
–
Lost state, membership change, key exhausted
Only AES-CBC and CMAC functions needed
14
The Evolution of HIP
•
First there was the Base Exchange
–
–
•
Then HIP for RFID
–
•
This already implied there would something not
'Base'
Well constructed for P2P applications
VERY lightweight exchange for Active 'tags'
Now HIP DEX
–
Designed for constrained sensors
15
The Evolution of HIP
•
•
•
Host Identity Namespace and HITs will be
available for any Object on the Internet
We need attention to implementation
commonality for systems that will support 2 or
all three exchanges
We need to think out how best to leverage this
development
16
Next Steps
•
HIP DEX will be worked on in
–
•
Refine processes
–
–
•
•
IETF and IEEE 802.15 HIP Interest Group
HIP DEX
MACsec key hierarchies management
Present progress at IEEE 802.15 Interim in
September
November IEEE 802 and IETF same week
–
I will be attending IEEE 802
17
Questions?
18