1 / 17

Conclusions, anyone?

Conclusions, anyone?. The Problem Definition. How to prevent Cullen from p0wning all the lightbulbs in the city?. What We Need to Keep Cullen from Doing This. 1) Introduce devices to each other 2) Authorize each participant for allowable actions 3) Secure the communications

magee
Télécharger la présentation

Conclusions, anyone?

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. Conclusions, anyone?

  2. The Problem Definition • How to prevent Cullen from p0wning all the lightbulbs in the city?

  3. What We Need to KeepCullen from Doing This 1) Introduce devices to each other 2) Authorize each participant for allowable actions 3) Secure the communications 4) Enforce that all actions are authorized 5) Implement in a set of nodes (some small) … while making sure that re-configuration is possible, user interfaces are usable, you can switch any participant or operator to another, crypto agility can be provided, minimize IPR cost, on widest range of HW, ...

  4. Requirements for each application differ Installation by regular people Need to add devices, change owners, etc. Threats are not just from neighbor's kids Also, e.g., taking-the-grid-down attacks Individual vs. 1 million device users Must worry about business models and partners Open interfaces, few regulations are good Possible Conclusions from the Requirements & Economics Discussion

  5. We think we can use the existing algorithms We probably can use the existing protocols Data formats, DTLS, TLS, L2 security, (U)SIM, ikev2, … etc but pick just one per category... but hard to do for L2+some other security Hard for other designs to improve significantly Some areas may need further clarification E.g., using COAP and TLS together Network access security not looked at in the WS Look at the code size of the entire system Including provisioning, authorization, config Focus on the system! Unwanted traffic Energy matters more than code size or time Wireless reception the most expensive task Possible Conclusions from the Implementation Experiences

  6. Important to decide how authorization is decided And how it flows to the PEPs All the above might be application-specific Good to separate capabilities from users E.g. Oauth OAuth is quite browser focused, attribute certs etc were never deployed Possible IETF action? (But how to deploy it?) If you wish to restrict the complexity of your implementation, you will need to restrict your deployment environment (e.g. number of peers) User interface matters Often, devices have no user interface, and all interaction is in the backend Work on introduction models! If we had a taxonomy of introduction, we could provide generic patterns to how you can do authorization under those introduction models Possible IETF activity? Possible Conclusions from the Authorization Discussion

  7. There is a limited set of solutions Based on whether you assume buttons vs. labels vs. LEDs, multicast discovery, online network availability, ... Important to separate vendor and user CAs Labels given to humans should use a checksum A fun area to design protocols in Possible Conclusions from the Imprinting Discussion

  8. Protocol-related: Clarifying how to use DTLS with COAP Complete the JOSE work LWIG-like guidance on security protocol impls.? Pairing/imprinting protocols? Is this something IETF can provide additional value in? Is the scenario that Cullen proposed interesting & something that the industry needs? Certificate compression mechanisms? Compression of DTLS over 6Lowpan? (already in RFC?) Making 6lowpan hc recognize ESP Recommendations on how to use network access protocols Security for ROLL/RPL/MANET Higher-level issues: Guidance for introduction models? Question marks: Do we need Oauth-for-IOT? Deployable? The model may be usable outside browsers, but the protocol design does not seem optimized for constrained devices Rene: not all crypto supported by all protocols? Binary curves? (possibly already in DTLS RFC?) Possible IETF Actions

  9. What about middleboxes Questions That We Didn't Get To...

  10. Detailed Notes... unprocessed

  11. Paul Chilton, Lighting Has to be installed by the average person Initially no internet access, purely local control, get people familiar with the concept Add a gateway, enable applications, web, … Challenges: ease of commissioning, discovery, ease of re-configuration, device authentication, cost, sleeping and energy harvesting, privacy, … Questions: Then again, these lightbulbs do more than usual ones, so maybe then can be more complex to use. But that would only give us the techie users, not general public... and there is no margin for running a helpdesk Subir: Why connect e2e to each lightbulb, why not to a switch that controls a group of lightbulbs. Cullen thinks that its just more practical to replace lighbulbs than central power equipment Ekr: there are global attacks, e.g., turning on all devices on at the same time, what does that do the grid? Randy: focus on identity, trust, and authorization, not just the lights example. Fred baker thinks that it is useful to think about the example to make something really foolproof but also simple Ekr: I want to understand the threat model. I only want myself to be able to access my devices, unless I explicitly configure additional people. Mark Townsley: iTunes Cullen thinks that we are going to live in a world where if there is no enrollment attackers can do bad things. Ekr thinks that not acceptable. Detailed Notes 1

  12. Rudolf van Berg, economics & competition The one million device user Lots of discussion about whether sim cards are a good model Voip experience said that operators do not want to open up Detailed Notes 2

  13. Implementation experience Carsten: Moore's law not going to fix it Discover – imprint – configure DTLS making COAP more complex, more messages, etc. Many ways to use DTLS Ekr questions the choice to run DTLS on top of COAP Minimal DTLS implementation 13K with symmetric crypto only, AES in hw State machine dominates the implementation Hannes: Communication relationships more important than protocols, crypto Lower footprint => fewer functions (PKs, resumption, etc) Mohit: Public key crypto doable at least in some cases on 8-bit CPUs Joules are more important than time or code/time Detailed Notes 3

  14. Authorization Richard Barnes: Is imprinting all we need? Principals in home: owner, guest, child, neighbor, alarm co, TV, HVAC, smart meter, … From simple models to the next generation. E.g., from passwords to Oauth OAuth allows separating capabilities from users, e.g., give your TV access to netflix Questions: Where does identity come from? Hashes and bar codes? Who makes authorization decisions? Where is authorization checked? Is any of this general, or all application-specific Cullen: What do the user interfaces look like? Michael: configuration and authorship happens in ”home depot” web site Michael: need to get on first to ”guest” network so that it can call home depot Carsten: very important to design for choice Jan Open questions: what protocol to use for attribute-based AC? Mapping of credentials to COAP/HTTP requests Standardized authorization policy formats have not been deployed Other Is typing in serial numbers feasible, or are there better approaches? Detailed Notes 4

  15. Challenges We need solutions that can be installed by the average person Interoperability in a multi-vendor environment The 1 million device users There are significant grid & local damage attacks that we have to worry about Make it simple and secure. The challenge. Implementation sizes: DTLS from 13K up Useless to discussion protocols alone, have to understand what the whole system needs to do, incl. provisioning, etc. Then we know code sizes, ease of use, etc. Roundtrips vs. Memory size vs. Message sizes; message sizes are important Sam worries about combining large scale deployments and claims about knowing how we can restrict to constrained devices. Suggests that restricting the number of parties that devices need to talk to is going to be useful. What We Learned

  16. Provisioning & authorization A box of lightbulbs, configured to work together at the factory (Paul) ”Things” tied to the owner upon purchase time at iTunes shop etc (Mark) Restricting nodes that devices need to talk to (Sam) Protocols DTLS, TLS Data-object security OAuth Hard to see other designs that would be significantly better Crypto Standard crypto operations PK operations, even on 8-bit CPUs (infrequently, with ECC, etc) Working Solutions

  17. What is an acceptable level of security? How do I add new devices to an existing network? How do I authorize an Android device to control a home automation setup? Can I build a system for my house that does not require a third party? Security and middleboxes? Questions to Answer &Problems to Solve

More Related