Skip to content
This repository has been archived by the owner on Jun 2, 2023. It is now read-only.

security models #2

Open
earlence opened this issue Apr 8, 2016 · 3 comments
Open

security models #2

earlence opened this issue Apr 8, 2016 · 3 comments

Comments

@earlence
Copy link

earlence commented Apr 8, 2016

What you forget to mention is the clashing of various security models. The security model of philips hue might be different from ZWave schlage locks. How does this project address this heterogeneity in sec models? Is there a plan to do this?

@tjaffri
Copy link
Contributor

tjaffri commented Apr 8, 2016

Please check out the onboarding repo: https://github.com/openT2T/onboarding. We are hoping to start a discussion around common security models (e.g. auth/pairing/etc) for similar things, e.g. all Bluetooth LE devices have similar onboarding requirements. In the translators repo https://github.com/openT2T/translators you will find examples of Things that implement the same schema, but have different onboarding types (e.g. check out the different types of Window Shades). What do you think? We are hoping to start a discussion here with the community, and we would love your feedback. Thanks!

@earlence
Copy link
Author

earlence commented Apr 8, 2016

It seems to me that there are two sides to this. First is the aspect of getting the IoT devices connected to the translator itself. That would be the most common definition of onboarding for me. Suppose a user is running the translators on a raspi. The user will have to configure these devices to communicate securely with the raspi first (e.g. exchanging wifi credentials, etc). It seems we might have less control over the specifics of this process, as it is upto the device manufacturer, and the specific low level protocol (wifi, zigbee, ble, etc) to decide how this happens. A translator for that device would have to account for such variation. The more interesting aspect is what kind of security model is exposed to the app side. This model has to be uniform, and correct enough so as to properly guard access to device operations, events, and data to ensure least privilege etc. I think this security model "schema" should be worked into the current schemas (like, define a privilege that a caller app needs before it can invoke an operation from a schema).

@jeanpa
Copy link

jeanpa commented Apr 11, 2016

100% agree with you. For now, we started working on the first side of what you described to see how much of the second side we need practically. We also started this exact conversation in the IAB workshop I attended a few weeks ago (https://www.iab.org/activities/workshops/iotsi/, they will be publishing the report soon) so I am looking forward to continue the conversation.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants