Thanks Sachin, I don?t want to derail the main questions Sachin posed, regarding fallback behavior and integration plan. However I?d like to elaborate a little more on the highlighted section below, since we have already discussed several ways to implement this platform-specific persistent storage functionality.
We had a few objectives that I?ll try to enumerate from memory (in no particular order): ? Keep the IoTivity stack code platform-independent o This implies (as Sachin?s email states) that the application code deals with platform specific aspects such as storage ? Perturb application development as little as possible o To this end we?re planning to supply Example implementations of the Persistent Storage callbacks for key platforms ? Allow applications to override the Example behavior o For example, a vendor may wish to utilize HW key ladders or SmartCard storage for credentials? this would require HW-specific code and is beyond the scope of ?Linux? ?Arduino? etc Example platform support ? Keep unused code out of the app o We don?t want the Example code to be linked in if the App is overriding the Example behavior With these goals in mind, we are leaning toward providing Example application code (included by the app) with a simple way to override (e.g. a #define USE_CUSTOM_STORAGE_BEHAVIOR macro). Other alternatives would be a plugin model, or a library which implements the Example behavior (e.g. ?platform-support.lib?) and application APIs to override the platform-support.lib behavior. Note that, as described below, if the Example code didn?t include support for a particular platform, we?d still have the same fallback behavior (at the device-behavior level) as in the corrupt storage case. Any comments/suggestions on this particular aspect also welcome ? Thanks, Nathan From: iotivity-dev-bounces at lists.iotivity.org [mailto:[email protected]] On Behalf Of Agrawal, Sachin Sent: Monday, June 1, 2015 1:51 PM To: iotivity-dev at lists.iotivity.org Subject: Re: [dev] security-M3 merge to master 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<mailto: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: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<mailto: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/6fbc314a/attachment.html>
