1 / 18

The HIP Diet Exchange HIP DEX

Robert Moskowitz ICSA labs an Independent Division of Verizon Business July 26, 2010 rgm@labs.htt-consult.com. The HIP Diet Exchange HIP DEX. Purpose of this presentation. Present work on a new HIP Exchange specifically architected for resource limited devices by

jerrod
Download Presentation

The HIP Diet Exchange HIP DEX

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Robert Moskowitz ICSA labs an Independent Division of Verizon Business July 26, 2010 rgm@labs.htt-consult.com The HIP Diet ExchangeHIP DEX

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

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

  4. Putting HIP on a DietBasic 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

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

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

  7. 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 ::= (DHlist) ------> R1 ::= <--- Pn, Pkr, DHlist I2 ::= Sn, PKi, ECR(DHk,x|n), MAC(DHk,(Sn, PKi, ECR(DHk,x|n))) ------> I or MI R R2 ::= <--- 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.

  8. Putting HIP on a DietSummary 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

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

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

  11. HIP Diet Exchange (DEX)Adding Password Authentication • Challenge Encryption • Use password as CMAC key • MAC nonce from R1 puzzle • RFC 4615 (AES-CMAC-PRF-128) is starting point • Encrypting a challenge from R1 prevents replay attacks • R1 cannot be reused if password response is accepted • 'Rogue' Responder attack • 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

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

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

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

  15. The Evolution of HIP • First there was the Base Exchange • This already implied there would something not 'Base' • Well constructed for P2P applications • Then HIP for RFID • VERY lightweight exchange for Active 'tags' • Now HIP DEX • Designed for constrained sensors

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

  17. Next Steps • HIP DEX will be worked on in • IETF and IEEE 802.15 HIP Interest Group • Refine processes • 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

  18. Questions?

More Related