Hi Nathan/Kishen, My requirement looks far abstracted so that I need to elaborate it by understanding security operation. Currently OC_SECURE flag operation in SECURE BUILD is definitely bug which looks very old one from the last year December. However, I'm still not clear that this bug fix will remove the non-secure build need completely.
Let's think a little bit more, individual resource is configurable as secure and non-secure one on the SECURE BUILD IoTivity. Does non-secure resource guarantee that client side we don't need prior secure provisioning step? How about the common resources? Multicast receiving resources such as /oic/d, oic/res are set as non-secure resource? and always accessible without secure channeling? What about the oic/p and security related resource? My requirement is from the consideration to put the binary library into OS/platform such as Tizen and Windows where developer can test IoTivity feature with non-secure way. Could this bug(OC_SECURE flag operation in SECURE BUILD) meet it? BR, Uze Choi -----Original Message----- From: Heldt-Sheller, Nathan [mailto:[email protected]] Sent: Wednesday, June 15, 2016 2:45 AM To: uzchoi at samsung.com; Maloor, Kishen; 'Clark, Steve'; Smith, Ned Cc: 'Ih, Ronald'; 'RANDEEP SINGH'; 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 Uze, If I'm understanding correctly, you are saying that in a build created with SECURED=1, when you create a Resource and do not flag OC_SECURE, then the Resource is somehow not created correctly? If so, this is a bug which should be reported in JIRA and should be assigned to Dongik Lee, who can then assign it to the right person to fix. Make sure after creating the bug to mark it "fix in 1.1.1" and send email to Markus to make sure he adds it to the Certification tracking list. I'm not the person to do it, because I have too many Test Spec, development, and Spec CR tasks to finish already before I leave at the start of July for 2 month sabbatical... sorry, but I need to not take on new tasks with only 2 weeks to go unless there is nobody else who can do it :) In this case, Dongik will be better able to fix it than I will! Thanks, Nathan -----Original Message----- From: ???(Uze Choi) [mailto:[email protected]] Sent: Tuesday, June 14, 2016 5:53 AM To: Maloor, Kishen <kishen.maloor at intel.com>; Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com>; 'Clark, Steve' <Steve.Clark at atmel.com>; Smith, Ned <ned.smith at intel.com> Cc: 'Ih, Ronald' <Ronald.Ih at atmel.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, When we choose to not flag with OC_SECURE in secure build, IoTivity does not act as non-secure resource, which requires secure connection and presumably requires secure provisioning step. If you fix it, then we only need the secure build. Nathan, are you person who receive this requirement? BR, Uze Choi -----Original Message----- From: Maloor, Kishen [mailto:[email protected]] Sent: Tuesday, June 07, 2016 1:11 PM To: Heldt-Sheller, Nathan; Clark, Steve; Smith, Ned Cc: Ih, Ronald; uzchoi at samsung.com; RANDEEP SINGH; 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, 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 >
