Identities for the Internet of Things

1. Aalto University February 1, 2011 Robert Moskowitz Verizon Identities for the Internet of Things

2. A Opening thought “Cockroaches have made the evolutionary jump from carbon-based to silicon-based lifeforms. They will be everywhere and are going to eat up all of our bandwidth.” Michael O'Dell CTO UUNET, 1998 We were warned....

3. RFC 1925The Twelve Truths of Networking 5) It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea. 6) It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it. 8) It is more complicated than you think.

4. Topics Introduction – A survey of Identities Trust in Identities Working with Constrained Systems Balancing Risks and Costs A set of Proposals

5. Introduction – A Survey of Identities Names Strings and Things Symmetric Keyed Agreement between two Parties Asymmetric Keyed Unique for you Biometrics Uniquely you

6. Names as IdentitiesStrings and Things Names can be Unique RFID, FQDN Names may require context Given Name, UserID Names are easy to create Even global names Names are easy to loose Hare today, Goon tomorrow

7. Symmetric KeyedAgreement between two Parties Symmetric keys by themselves cannot be Identities Passwords, AES keys At least two parties are equal owners of the key Any can repudiate another Symmetric keys can only facilitate Identities

8. Asymmetric KeyedUnique for You Public keys are uniquely paired to their private key Ownership can be proven Only HIP implements Public key Identity Represented in the HIT (Host Identity Tag)

9. BiometricUniquely You A uniquely generate name How generated? Why trust them? Does silicon have a biometric?

10. Trust in Identities Bindings The power of two or more Lists Enclaves

11. BindingsThe power of two or more Leveraging one Identity with another A friend of a friend can be a friend Letter of Credit Practically all Identities use bindings No Identity out of context DNS, X.509, LDAP, SSH keys

12. ListsEnclaves Part of human interaction “I remember that face, can I remember the name?” Intrinsic to digital Identities UserID/password, RHOSTs, SSH known hosts Browser Trusted roots and Trusted sites RADIUS DOCSIS registered user certs

13. Working with Constrained Systems Memory, CPU, Power – Chose one! Engineering trade offs Cryptographic components What is essential and what is not

14. Memory, CPU, PowerChoose just one! Very constrained, means very constrained Names for Identities are relatively cheap Memory only Keys for Identities become increasingly costly Ephemeral Diffie-Hellman CPU and power hungry Key hierarchies can be a lot of keys, costing memory What is minimal and what extras can be afforded New developments all the time, MIT running flash at 1.8v

15. Cryptographic ComponentsWhat is essential and what is not Diffie-Hellman derived keys cannot be used directly Not 'Uniformly distributed' Must be hashed to needed key length and preserve all entropy – What hash function? Public Keys (RSA or ECC) cannot directly sign a string Existential Forgeries String must be cryptographically hashed

16. Cryptographic ComponentsWhat is essential and what is not What hashes? SHA-1 end of life SHA-256 & others just more of the same? Where is SHA-3 and will it suit IoT? Used in HMAC What about CMAC How to key See HIP DEX for 1st attempt to use CMAC properly for D-H key compression

17. Cryptographic ComponentsWhat is essential and what is not Digital Certificates require RSA or ECC Cryptographic hashes Diffie-Hellman exchange requires Discrete Log or EC Cryptographic hashes, or possibly CMAC We are in a serious tight spot with hashes Will SHA-3 work for IoT? What of Matyas-Meyer-Oseas hash?

18. Balancing Risks and Costs Names or Asymmetric Keys Bindings or Lists

19. Names or Asymmetric Keys Names (or strings) are cheap So cheap that their duplication is assumed,even if 'global'. Meaning they are totally attackable Require some method of proof, e.g. symmetric keys Asymmetric keys have associated costs Use cost Generation cost

20. Bindings or Lists Bindings cost in data transfer or cryptography or both DNS lookup Certificate validation Lists vary by size Memory or remote retrieval Even Bindings devolve to Lists, that is you rarely implement a Binding solution without having a List solution in there somewhere

21. A Set of Proposals Leveraging Asymmetric Keys Identities within domains and hierarchy of Identities

22. Leveraging Asymmetric Keys Asymmetric keys are intrinsically Identities if we would use them RSA or ECDSA mandates to use of Cryptographic hashes, which MAY not be so bad Diffie-Hellman mandates Static, and how is that different from RSA or ECDSA? Manage in Lists with weak bindings Registration process

23. Identities within DomainsAnd Hierarchy of Identities An Identity is only as good as its trust. A global Identity needs a global trust which has major costs DNS, PKI Create methods of trust in Hierarchies Me, my sensors Company, building, sensors If I trust a hierarchy, I trust what it owns