1. Robert Moskowitz, Verizon
July 2012
Project: IEEE P Working Group for Wireless Personal Area Networks (WPANs)
Submission Title: Secure Device Identities
Date Submitted: July 18, 2012
Source: Robert Moskowitz, Verizon
Address 1000 Bent Creek Blvd, MechanicsBurg, PA, USA
Voice:+1 (248) ,
Re: Secure Device Identities
Abstract: Secure Device Identities
Purpose: Discuss device identities for LED ID
Notice: This document has been prepared to assist the IEEE P It is offered as a basis for discussion and is not binding on the contributing individual(s) or organization(s). The material in this document is subject to change in form and content after further study. The contributor(s) reserve(s) the right to add, amend or withdraw material contained herein.
Release: The contributor acknowledges and accepts that this contribution becomes the property of IEEE and may be made publicly available by P
Robert Moskowitz, Verizon

2. Secure Device Identities
July 2012
Secure Device Identities
Robert Moskowitz
San Diego, CA
July 18, 2012
Robert Moskowitz, Verizon

3. Abstract Classes of Identities Value case for Secure Identities
July 2012
Abstract
Classes of Identities
Textual and Secure
Value case for Secure Identities
Trust in Secure Identities
Formats for Secure Identities
Secure Identities in Authentication and Key Establishment
Robert Moskowitz, Verizon

4. Classes of Identities Textual Secure
July 2012
Classes of Identities
Textual
A string of bits organized in some manner
URN, RFID, IP address
JPEG, MP3, biometric-data
No assertion (spoofable) outside of origin
Secure
A string of bits that can be proved as coming from a source
Robert Moskowitz, Verizon

5. Value Case for Secure Identities
July 2012
Value Case for Secure Identities
The value for Secure Identities comes for the device's ability to assert its identity and no other device to spoof that identity
A Secure Identity does not require special hardware for proof
Nor does it require a 3rd party for assertion
It is self establishing
Robert Moskowitz, Verizon

6. Trust in Secure Identities
July 2012
Trust in Secure Identities
Secure Identities are self-asserting
But who/what is doing the asserting?
You don't know who/what I am but you know you are talking to me.
Types of trust assertion
Geo-location
3rd party proofs
Side channel
But you don't always need such proofs
Robert Moskowitz, Verizon

7. Format for Secure Identities
July 2012
Format for Secure Identities
Secure Identities today are asymmetric cryptographically based
The public key is the identity and operation using the private key provides the proof
Differing representation for various asymmetric cryptography makes public keys as poor identities
Simple hash the public key into an agreed, common, format
Robert Moskowitz, Verizon

8. Format for Secure Identities
July 2012
Format for Secure Identities
Thus the HASH of the public key IS the secure Identity!
E.G. Host Identity Tag in the HIP protocol
Robert Moskowitz, Verizon

9. Secure Identities in Authentication and Key Establishment
July 2012
Secure Identities in Authentication and Key Establishment
A peer that has a Secure Identity proof can directly request authentication of said identity from a trusted Authentication Service
E.G. RADIUS req/resp of hash
Asymmetric crypto protocols exist for key establishment
Some very lightweight
E.G. HIP DEX
Robert Moskowitz, Verizon

10. Applications for LED ID
July 2012
Applications for LED ID
Passive LED ID (Transmit only)
ECDSA Secure Identity
Sends timestamped signed data object including ID hash
Reader uses hash to acquire public key to validate signature
Robert Moskowitz, Verizon

11. Applications for LED ID
July 2012
Applications for LED ID
Active LED ID
ECDH Secure Identity
Use protocol like HIP DEX for Identity proofing
Can include encrypted data content within exchange
Robert Moskowitz, Verizon

12. July 2012
Open Discussion
Robert Moskowitz, Verizon