Thank Kishen, I got the confidence from you answer, my requirement could simply be resolved by fixing the bug. Let me contact to Dongik for this issue resolve.
BR, Uze Choi -----Original Message----- From: Maloor, Kishen [mailto:[email protected]] Sent: Wednesday, June 15, 2016 12:10 PM To: ???(Uze Choi); Heldt-Sheller, Nathan; '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, The point was that it shouldn?t require shipping a SECURED=0 build to expose an application resource on a coap:// endpoint. If an application is unable to willfully expose such a resource on a SECURED=1 build, then there is likely a bug either in the design, or the logic, or both. Only those developers familiar with the code can investigate this. However the basic working logic is simple: a resource in the discovery response without sec=true should be accessed at the server?s DTLS port in a DTLS session, and a resource without sec=true should be accessed directly at the server?s ?unsecure? port. With such a design, its easy to see how provisioning states of both the client and the server become irrelevant while accessing a resource at the coap:// endpoint. Hope that answers your question. Using some build flag (OC_SECURE as an example) to indicate if a resource should be at coap:// or coaps:// was merely a suggestion as one way to achieve the outcome. Do keep in mind though that some now hold the view that a production grade OCF build shouldn?t permit a server application to define a coap:// resource, i.e. they?d prefer if all application resources were at coaps://. That?s however an opinion, and a probably separate discussion. -Kishen. - Kishen Maloor Intel Open Source Technology Center On 6/14/16, 6:26 PM, "???(Uze Choi)" <uzchoi at samsung.com> wrote: >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:nathan.heldt-sheller at intel.com] >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:uzchoi at samsung.com] >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:kishen.maloor at intel.com] >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 >> > > >
