Hi All,
Security in Iotivity is enforced using ?device credentials? and ?access control lists?. -Device Credentials allows two Iotivity end-points to communicate ?securely?. -Access Control Lists allows Iotivity resource Server to enforce policies such as: John can switch on/off lights whereas Jane can only retrieve the current state of a light. ?Device credentials? and ?access control lists? are encapsulated within Iotivity Security as ?Secure Virtual Resources? (SVR?s). These SVR?s are persisted on the device (in hard-disk, flash storage, EEPROM etc) and are provided to Iotivity stack by Iotivity application at start-up. If Iotivity application does not provide these SVR?s to Iotivity stack at startup (or SVR?s are corrupted or any other glitches), Iotivity stack falls back to an un-owned/un-provisioned state. In this state, Iotivity stack will ONLY respond to discovery requests and can undergo device provisioning/ownership process. Any other GET/PUT/POST/DEL requests to resources hosted on the Iotivity device will be ?rejected? by Secure Resource Manager. As this is a new change in Iotivity stack behavior and affects the execution of all existing Iotivity Client/Server sample applications, we intend to introduce security in a phased approach and try to avoid major disruption to existing Iotivity users. Therefore our current plan is: 1. Merge ?security-M3? changeset <https://gerrit.iotivity.org/gerrit/#/c/1071/> to master branch. By default, Iotivity stack will be compiled in un-secured mode using scons scripts (SECURED=0). (This is also the current behavior of scons scripts in master.) Iotivity Security team will than work with respective owners of sample applications to enable SVR support in existing sample applications. 2. Once all the existing apps are updated to accommodate Secure Virtual Resource logic, we should switch the default behavior of Iotivity scons scripts to compile Iotivity stack in ?secured? mode (SECURED=1). We would prefer this time-period to be of short duration (2-3 weeks) so that we can get rid of running devices without security. Above approach would apply for Ubuntu, Android, Tizen and OSX operating systems. Irrespective of above proposal, below will be the behavior for Arduino and BLE configurations: 1. Arduino : Sample apps currently do not have code to perform Read/Write operations on EEPROM. Also, tinyDTLS has not been yet completely ported for Arduino. Therefore, Arduino builds will continue to be compiled with SECURED=0. 2. Since we do not support security over BLE currently, this should not have any impact on BLE. The only difference will be that BLE Iotivity Server will have a SVR which will contain an entry such as ?Grant ALL access to Everybody?. Alternatively, there is always the option using SECURED=0 mode when compiling Iotivity stack for BLE transport. If you see any issues with above approach, please let us know your concerns. Thanks Sachin From: Agrawal, Sachin Sent: Wednesday, May 27, 2015 9:30 AM To: iotivity-dev at lists.iotivity.org Subject: RE: security-M3 merge to master Hi All, Security features for BeachHead are open for review here: https://gerrit.iotivity.org/gerrit/#/c/1071/ This mainly contains following items: 1. Onboarding a new device and provisioning it with credentials and ACL?s: a. ?Just works? Provisioning mechanism and Provisioning tool 2. Resource Access Control via SRM Here is a link to Iotivity Wiki site with information about SRM and Provisioning design: https://wiki.iotivity.org/iotivity_security SRM Design specification contains a section which lists the detail info about the features implemented in this change set. Thanks Sachin From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Agrawal, Sachin Sent: Thursday, May 21, 2015 10:36 AM To: iotivity-dev at lists.iotivity.org Subject: [dev] security-M3 merge to master Hi All, Security team has finished features committed for BeachHead delivery. We are now initiating security-M3 merge to master. Our plan is to initially synch security-M3 branch with master and push a changeset for Iotivity community to review. In the meanwhile, if there are any major check-ins in master (such as IPV6 etc), we will synch security-M3 changeset with master. Barring any major surprises, we intend to finish this merge within next two weeks. Thanks Sachin -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150601/cfda0804/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 7768 bytes Desc: not available URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20150601/cfda0804/attachment.p7s>
