Hi Nathan, Thanks. The reason I chimed in was because it seemed like the discussion had veered off course, keeping most of the focus on Uze?s initial comment ?merging the non-secure binary and secure binary into single one.?.
That comment however in reality has nothing to do with the legitimate feature request raised in the rest of his e-mail (supporting secure and public resources at the same time), for which I suggested one solution. With such a solution in place, you would always build a secure binary. If you wanted to ?disable? security for a resource to test, you would choose to not flag it with OC_SECURE. As such there shouldn?t ever be a reason to ship a non-secure binary, at least to support the requirements in question. Thanks, -Kishen. - Kishen Maloor Intel Open Source Technology Center On 6/6/16, 8:13 PM, "Heldt-Sheller, Nathan" <nathan.heldt-sheller at intel.com> wrote: >Hi Kishen, > >I agree with you regarding "public" resource requirement part, but I >think there are two features being raised: one is to be able to expose >"public" and "secure" resources simultaneously, and the other is to have >a single binary for testing purposes which can have the security layer >disabled. > >The first (public and secure resources on the same Server) can be done in >a few ways in IoTivity. The simplest is to declare a "public" resource >without "OC_SECURE" which results in it being hosted on CoAP (UDP) port. >The other way to create a "public" resource while still enforcing access >control in the security layer is to create the resource with OC_SECURE >(so it is hosted on CoAPS DTLS port), *and* also create an ACL with "R" >permissions and a "*" (wildcard) subject. This allows anyone who can >connect (i.e. any endpoint which can successfully complete DTLS handshake >with the server) to Read the resource. > >The second use model/requirement (dual-mode binary) is a bit more complex >in that we definitely do not want to certify such a binary. Of course >vendors would still sign a statement asserting that the binary being >certified does not have a way to disable the security layer, but this >still doesn't address accidental inclusion, which is difficult to test >for with the CTT and thus poses a risk. > >So yes as you suggest the IoTivity implementation currently offers >OC_SECURE as a way to control which port (UDP or DTLS) a resource is >exposed on, and IoTivity also offers ACL with "*" wildcard subject to >allow public access to OC_SECURE resource if that is the desire. What it >cannot do right now is the "dual-mode" feature in a single binary; as you >know, it must be compiled with SECURED=1 or 0. > >Thanks, >Nathan > >-----Original Message----- >From: Maloor, Kishen >Sent: Sunday, June 5, 2016 10:13 PM >To: Clark, Steve <Steve.Clark at atmel.com>; Smith, Ned <ned.smith at >intel.com> >Cc: Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com>; Ih, Ronald ><Ronald.Ih at atmel.com>; uzchoi at samsung.com; RANDEEP SINGH ><randeep.s at samsung.com>; iotivity-dev at lists.iotivity.org; >security_wg at openconnectivity.org >Subject: Re: [security_wg] RE: [dev] [feature request] merging >secure/non-secure IoTivity build binaries > >Hi Nathan, > >Just my 2 cents, but I feel like this discussion may have gotten more >complex than it needs to be. >In my opinion, it isn't really about secure vs non-secure binaries. > >I think the essence of Uze?s request really boils down to supporting >secured and ?public? resources at the same time (and on the same build, >which would be SECURED=1 builds). >A public resource would be accessed through CoAP directly over UDP >bypassing DTLS. It would further be assumed to have wildcard access. > >One use case I just made up is a ?gym server? that exposes a public >resource for number of treadmills not in use, and a secured resource for >remotely disabling a treadmill. > >The fact that Uze raised this question >makes me think that perhaps IoTivity doesn?t currently support this sort >of definition. > >Regarding implementation, I haven?t looked inside IoTivity recently, but >there used to be a OC_SECURE policy flag for resources (alongside >OC_DISCOVERABLE etc.) That might be a way for a server application >developer to indicate a secured resource. In that case, for its discovery >response, only those resources marked with OC_SECURE would have sec=true >and DTLS port information provided. As a consequence, a client would know >when to (and when not to) establish a DTLS session. Just cleaning up the >design/implementation to do the above should satisfy Uze?s request. > >Thanks, >-Kishen. > > > > >- >Kishen Maloor >Intel Open Source Technology Center > > > > >From: <security_wg at openconnectivity.org> on behalf of "Clark, Steve" ><Steve.Clark at atmel.com> >Date: Sunday, June 5, 2016 at 8:22 PM >To: "Smith, Ned" <ned.smith at intel.com> >Cc: "Heldt-Sheller, Nathan" <nathan.heldt-sheller at intel.com>, "Ih, >Ronald" <Ronald.Ih at atmel.com>, "uzchoi at samsung.com" <uzchoi at >samsung.com>, >RANDEEP SINGH <randeep.s at samsung.com>, "iotivity-dev at lists.iotivity.org" ><iotivity-dev at lists.iotivity.org>, "security_wg at openconnectivity.org" ><security_wg at openconnectivity.org> >Subject: RE: [security_wg] RE: [dev] [feature request] merging >secure/non-secure IoTivity build binaries > > >Hi Ned, > >It looks like we?re in agreement that the ?security features shall not be >disabled?. > >For certification purposes, there are ways to ensure this. The specific >technique will still need to be worked out and specified. > >Regards, >Steve Clark > >From: Smith, Ned [mailto:ned.smith at intel.com] > >Sent: Sunday, June 5, 2016 4:51 PM >To: Clark, Steve <Steve.Clark at atmel.com> >Cc: Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com>; Ih, Ronald ><Ronald.Ih at atmel.com>; uzchoi at samsung.com; RANDEEP SINGH ><randeep.s at samsung.com>; iotivity-dev at lists.iotivity.org; >security_wg at openconnectivity.org >Subject: Re: [security_wg] RE: [dev] [feature request] merging >secure/non-secure IoTivity build binaries > > > >If we defined an attestation requirement the inclusion of a framework >hash would address the hash integrity component. > > > >I would be careful using language that includes 'backdoor' which can have >legal ramifications. Better to say security features cannot be disabled. > >Sent from my iPhone > > >On Jun 5, 2016, at 07:23, Clark, Steve <Steve.Clark at atmel.com> wrote: > > >Hi Ned, Nathan, > >This discussion uncovers an issue? We may want the security specification >to explicitly state something to the effect of ?There shall not be a >back-door mechanism to disable security.? > >We could ensure this by requiring source code and build process as part >of the certification process. Then verifying checksums on the binary >that is produced. > >Regards, >Steve Clark > >From:security_wg at openconnectivity.org >[mailto:security_wg at openconnectivity.org] >On Behalf Of Heldt-Sheller, Nathan >Sent: Friday, June 3, 2016 6:22 PM >To: Smith, Ned <ned.smith at intel.com>; Ih, Ronald <Ronald.Ih at atmel.com>; >uzchoi at samsung.com; 'RANDEEP SINGH' <randeep.s at samsung.com> >Cc: iotivity-dev at lists.iotivity.org; >security_wg at openconnectivity.org >Subject: RE: [security_wg] RE: [dev] [feature request] merging >secure/non-secure IoTivity build binaries > > > >Thanks Ned. > >I think we?re saying the same thing in different ways: that a ?non-secure? >binary wouldn?t meet OIC v1.1 > Security Spec requirements, and a ?dual-mode? binary would, from a >robustness point of view, be equivalent to a ?non-secure? binary. > >However, SWG has no direct control over IoTivity, and IoTivity can >implement what it wants to in the end? the only thing SWG can do is >ensure that such a binary couldn?t pass Certification (which is supposed >to mean ?implementation meets the spec?). > >Thus, I suggested an illustrative example of how the use case suggested >by Uze could be achieved, but hoping to be very clear that this is just >an example. And in this example, the binary with this feature would fail >Certification. > > >Any other implementation that meets the use case requirements is fine, >too, but my hope is that whatever is settled on will be documented so >that we can test for the feature in the CTT. I realize that a better >Certification answer would be to say CTT verifies that the >implementation conforms to the spec, but since I cannot fathom a way to >verify that no possible API for disabling security exists in a given >binary (outside of penetration testing or code analysis, both of which >are outside the scope of our CTT), I proposed a cooperative approach to >ensuring we don?t Certify a non-secure or dual-mode binary. > >Make sense? Even if you disagree that?s fine, I just want to make sure >my explanation follows J > >Thanks, >Nathan > >From: Smith, Ned > >Sent: Friday, June 3, 2016 5:09 PM >To: Ih, Ronald <Ronald.Ih at atmel.com>; Heldt-Sheller, Nathan ><nathan.heldt-sheller at intel.com>; uzchoi at samsung.com; 'RANDEEP SINGH' ><randeep.s at samsung.com> >Cc: iotivity-dev at lists.iotivity.org; >security_wg at openconnectivity.org >Subject: Re: [security_wg] RE: [dev] [feature request] merging >secure/non-secure IoTivity build binaries > > > >The general rule regarding debug switches is if the testing agency can >turn security off, so can the attacker. Hence, this should not be allowed. > > > >There are other ways to solve this kind of problem. I don't think the >'problem' has been sufficiently described and a set of options considered >/ explained. There has only been one option forwarded and the choice is >between either security or compliance. This is a false choice. Security >should not be the trade-off for compliance. The existence of this type of >false choice is an indication that the problem isn't understood well >enough. > > > >Regarding this thread: There shouldn't be a "non-secure binary" hence >there is no need to validate it and no need to consider 'interoperability' >between non-secured > and secured instances. There is nothing in our specs that calls for the >creation of a 'non-secure' binary or mode. So we are being asked to make >decisions about something that isn't supposed to exist. > > > >This type of issue should be considered in the context of a more >formalized security review where specific recommendations are made and >where the decision of the security review board(?) is binding. > > > > > >Ned Smith > >Principal IoT Security Architect > >Intel SSG-OTC > >Ned.smith at intel.com > >+1.503.712.3695 > > > > > > >From: >"Ih, Ronald" <Ronald.Ih at atmel.com> >Date: Friday, June 3, 2016 at 10:21 AM >To: Nathan Heldt-Sheller <nathan.heldt-sheller at intel.com>, Ned Smith ><ned.smith at intel.com>, "uzchoi at samsung.com" <uzchoi at samsung.com>, ??? ><randeep.s at samsung.com> >Cc: "iotivity-dev at lists.iotivity.org" <iotivity-dev at lists.iotivity.org>, >"security_wg at openconnectivity.org" > <security_wg at openconnectivity.org> >Subject: RE: [security_wg] RE: [dev] [feature request] merging >secure/non-secure IoTivity build binaries > > > >I think it is relevant to SecWG in that we should account for the >possibility that OCF adopters will likely have development >implementations that allow you to switch the security on/off to make >debug iterations easier. I can see the value in that from a development >perspective. > >I am not an expert on this, but I think this may affect the Security Spec >because if manufacturers implement their own security switch methods, it >may be difficult to have a test >case(s) that catches all possible implementations where a device can be >put in a debug mode with security disabled. > >If it is not possible to screen out all potential unsecure debug >implementations, we may need to explicitly state in the spec that those >modes are specifically disallowed from production. > > >Ron > > >From:security_wg at openconnectivity.org >[mailto:security_wg at openconnectivity.org] >On Behalf Of Heldt-Sheller, Nathan >Sent: Thursday, June 02, 2016 11:02 PM >To: Smith, Ned <ned.smith at intel.com>; >uzchoi at samsung.com; 'RANDEEP SINGH' <randeep.s at samsung.com> >Cc: iotivity-dev at lists.iotivity.org; >security_wg at openconnectivity.org >Subject: RE: [security_wg] RE: [dev] [feature request] merging >secure/non-secure IoTivity build binaries > > > >Hi Ned, > > >This is not a Security Spec question. This is an implementation-specific >question for IoTivity. However I would like to get SecWG feedback as >security experts on the proposal for this feature from Uze (below). I >too am generally uncomfortable but I will concede that if the build >containing such a feature cannot pass Certification, then I cannot come >up with a good reason to disallow it for developer use. But I?d like to >hear the opinions of the SecWG on this idea, too. > >Thanks, >Nathan > >From: Smith, Ned > >Sent: Thursday, June 2, 2016 10:56 PM >To: Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com>; >uzchoi at samsung.com; 'RANDEEP SINGH' <randeep.s at samsung.com> >Cc: iotivity-dev at lists.iotivity.org; >security_wg at openconnectivity.org >Subject: Re: [security_wg] RE: [dev] [feature request] merging >secure/non-secure IoTivity build binaries > > > >This seems really risky from a security perspective. If the goal is to >provide a convenient way to turn off security in a development or even a >production environment. > That should be a vendor specific choice. I don't see why it should >impact the specification. > > > >There is no reason why a vendor can't make changes to their OCF approved >code base in ways that don't affect the standard (such as compile time >switches and config file options ). > > > >I just don't understand why it is even being brought up in the context of >SecWG. > > > >-Ned > > > >Ned Smith > >Principal IoT Security Architect > >Intel SSG-OTC > >Ned.smith at intel.com > >+1.503.712.3695 > > > > > > >From: ><security_wg at openconnectivity.org> on behalf of Nathan Heldt-Sheller ><nathan.heldt-sheller at intel.com> >Date: Thursday, June 2, 2016 at 10:18 PM >To: "uzchoi at samsung.com" <uzchoi at samsung.com>, ??? <randeep.s at >samsung.com> >Cc: "iotivity-dev at lists.iotivity.org" <iotivity-dev at lists.iotivity.org>, >"security_wg at openconnectivity.org" > <security_wg at openconnectivity.org> >Subject: [security_wg] RE: [dev] [feature request] merging >secure/non-secure IoTivity build binaries > > > >Thanks Uze, sorry if my proposal for compile-time feature wasn?t clear. >To clarify, I think your requested > feature (a single binary with both modes, which I am calling ?Dual >Security Mode?) is okay, so long as it is done in the following way: > >1) >?Dual Security Mode? version of IoTivity would have a ?Disable Security? >API (e.g. config file read at boot time, or similar) to disable >security-related code, and bypass Security Layer. This would allow dev >to test with Security turned off by changing a file and rebooting the >device. If a network API is required, a dev could provide an application >resource that would change the file (e.g. a PUT to a resource >?SecurityModeSwitch?) etc., then reboot. >Whatever your use case is can be supported, I think. >2) >?Dual Security Mode? version is *not* the default version of IoTivity, >and must be intentionally built using a compile-time switch (e.g. >?DUAL_SECURITY_MODE=1?) >3) >?Normal Security Mode? version does not have the API in 1), and *cannot* >have Security disabled (e.g. because the ?Disable Security? API is >#ifdef removed when ?DUAL_SECURITY_MODE=0?) >4) >?Dual-Security-Mode? version cannot be certified and will fail a CTT test >that checks for the ?Disable Security? API, etc > >Does this make sense? My primary concern is not the API or mechanism, >those were just to illustrate. >My primary concern is that if such a feature is added to IoTivity, that >the dual-mode binary is optional, not built by default, and not >certifiable. > >Please share your thoughts and let me know if this is clear, > >Thanks, >Nathan > > > >From:???(Uze > Choi) [mailto:uzchoi at samsung.com] >Sent: Thursday, June 2, 2016 6:41 PM >To: Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com>; 'RANDEEP >SINGH' <randeep.s at samsung.com> >Cc: iotivity-dev at lists.iotivity.org; >security_wg at openconnectivity.org >Subject: RE: [dev] [feature request] merging secure/non-secure IoTivity >build binaries > > > >Hi Nathan, > >Thank you your kind response and proposal. >Your approach looks a little different from mine focusing on the >developer instead of product. Please understand my position. >Mostly agree, however, the point that >?developer should not be confused by accidental inclusion? is somewhat >not understandable. >Whether they take the mistake or not, this is developer?s responsibility, >product company should take care. >Anyway, could you propose how developer can set the mode from your >proposal? >Compile time mean ifdef statement? I cannot imagine further. > >BR, Uze Choi >From: Heldt-Sheller, Nathan [mailto:nathan.heldt-sheller at intel.com] > >Sent: Friday, June 03, 2016 4:04 AM >To: uzchoi at samsung.com; 'RANDEEP SINGH' >Cc: iotivity-dev at lists.iotivity.org; >security_wg at openconnectivity.org >Subject: RE: [dev] [feature request] merging secure/non-secure IoTivity >build binaries > > > >Thanks Uze, > >This idea of ?run-time mode switch? >for developer testing only seems useful, but this is different from the >first requirement (for ?public? resources) in the original email. So I >wanted to be clear that ?public? resources can (and should) be >implemented using SECURED=1 build, and a wildcard-read-access > Access Control List entry. If we are agreed on this point, then let?s >discuss the dev/testing run-time mode switch idea. > >A run-time switchable binary is a very useful thing, but also very >dangerous from a security perspective. > If there is an application-level API, or even a run-time configurable >library (e.g. via a config file, etc.) then there is a built-in attack >vector that can circumvent all the security measures on the device. This >kind of binary should never be certified in my opinion, and therefore we >would need to add Certification Tests to verify that the binary doesn?t >expose a SECURED=0 mode switch. > >If this is acceptable (meaning, if it is okay to use this kind of >dual-mode binary for dev, but NOT for Certification) then I suppose it >is okay to create such a thing, but I would *not* want this mode-switch >feature enabled by default. >A dual-mode binary must be a compile-time choice, that is disabled by >default, so that there is no confusion and accidental inclusion of a the >SECURED=0 mode in a device intended for Certification. > >Does this make sense and do you agree? > >Thanks, >Nathan > >CC: security_wg to give them opportunity to comment > > > >From:???(Uze > Choi) [mailto:uzchoi at samsung.com] >Sent: Wednesday, June 1, 2016 9:37 PM >To: Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com>; 'RANDEEP >SINGH' <randeep.s at samsung.com> >Cc: iotivity-dev at lists.iotivity.org >Subject: RE: [dev] [feature request] merging secure/non-secure IoTivity >build binaries > > > >Hi Nathan, > >I?m sorry I missed you mail. Anyway thank you for your answer. > >Beside the discussion which mode will be deployed in real world, > >Let?s think about the SDK binary distribution or embedding into some >platform. > >Developer may start the development first with non-secure SDK library. >And after functions are implemented, developer may enable the secure >setting, which requires to replace SDK library by secure SDK library. > >Let?s think about the platform. >Some platform such as Tizen, may embed the library by default. >Platform should decide one of them as embedded library. If secure binary >is selected, then non-secure mode testing and so on cannot be executed. > >BR, Uze Choi >From: Heldt-Sheller, Nathan [mailto:nathan.heldt-sheller at intel.com] > >Sent: Thursday, May 26, 2016 4:13 PM >To: uzchoi at samsung.com; RANDEEP SINGH >Cc: iotivity-dev at lists.iotivity.org >Subject: RE: [dev] [feature request] merging secure/non-secure IoTivity >build binaries > > > >Hi Uze, > >I may be misinterpreting your below email, but I am concerned there may >be some confusion regarding the ?secure build? vs ?non-secure build?. > >I believe SECURED=0 build should be purely for development and testing, >and should not be expected to function with a SECURED=1 ?real-world? >build. There are basic functions (e.g. Device ID persistent across >reboots) that require SECURED=1 build, regardless of whether there are >?public? resources on the device (resources which do not need Access >Control). > >To be clear, resources can be effectively made ?public? using a SECURED=1 >build. >If a resource doesn?t need access control at all, then (still using a >SECURED=1 build) the Device will have an Access Control Entry that allows >all requests from any requester (even from anonymous endpoint). >Effectively, the resource is ?non-secure?, even though the *build* is >still SECURED=1, and the resource is hosted on a CoAPS port. > >In short, I would not expect a SECURED=0 Client to be able to access any >real-world Server, and a SECURED=0 Server would never be deployed in a >real-world product. Therefore the SECURED=1 configuration should be >expected for proper functioning, and SECURED=0 just kept for >dev/testing/debug use. > >Thanks, >Nathan > >From:iotivity-dev-bounces at lists.iotivity.org > [mailto:iotivity-dev-bounces at lists.iotivity.org] >On Behalf Of ???(Uze Choi) >Sent: Wednesday, May 25, 2016 8:46 PM >To: RANDEEP SINGH <randeep.s at samsung.com> >Cc: iotivity-dev at lists.iotivity.org >Subject: [dev] [feature request] merging secure/non-secure IoTivity build >binaries > > > >Hi Randeep, > >As a member Developer Ecosystem Build TG, I have the requirement merging >the non-secure binary and secure binary into single one. >Currently, secure mode build does not provide the communication with >non-secure resource. >If this is configurable by API or both support by default, it will be >very easy to distribute iotivity binary. >Moreover, current separate build scheme cannot support the use case that >connects both resources one is secure resource and the other is >non-secure resource. >e.g) An application read the temperature resource (public resource) and >personal information storage resource together. >Please evaluate this requirement from maintainer perspective. >If feasible, I?ll issue the jira ticket for this thing. > >BR, Uze Choi >
