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<mailto: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> [mailto:[email protected]] On Behalf Of Heldt-Sheller, Nathan Sent: Friday, June 3, 2016 6:22 PM To: Smith, Ned <ned.smith at intel.com<mailto:ned.smith at intel.com>>; Ih, Ronald <Ronald.Ih at atmel.com<mailto:Ronald.Ih at atmel.com>>; uzchoi at samsung.com<mailto:uzchoi at samsung.com>; 'RANDEEP SINGH' <randeep.s at samsung.com<mailto:randeep.s at samsung.com>> Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>; security_wg at openconnectivity.org<mailto: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 :) Thanks, Nathan From: Smith, Ned Sent: Friday, June 3, 2016 5:09 PM To: Ih, Ronald <Ronald.Ih at atmel.com<mailto:Ronald.Ih at atmel.com>>; Heldt-Sheller, Nathan <nathan.heldt-sheller at intel.com<mailto:nathan.heldt-sheller at intel.com>>; uzchoi at samsung.com<mailto:uzchoi at samsung.com>; 'RANDEEP SINGH' <randeep.s at samsung.com<mailto:randeep.s at samsung.com>> Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>; security_wg at openconnectivity.org<mailto: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<mailto:Ned.smith at intel.com> +1.503.712.3695 From: "Ih, Ronald" <Ronald.Ih at atmel.com<mailto:[email protected]>> Date: Friday, June 3, 2016 at 10:21 AM To: Nathan Heldt-Sheller <nathan.heldt-sheller at intel.com<mailto:nathan.heldt-sheller at intel.com>>, Ned Smith <ned.smith at intel.com<mailto:ned.smith at intel.com>>, "uzchoi at samsung.com<mailto:uzchoi at samsung.com>" <uzchoi at samsung.com<mailto:uzchoi at samsung.com>>, ??? <randeep.s at samsung.com<mailto:randeep.s at samsung.com>> Cc: "iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>" <iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>>, "security_wg at openconnectivity.org<mailto:security_wg at openconnectivity.org>" <security_wg at openconnectivity.org<mailto: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> [mailto:[email protected]] On Behalf Of Heldt-Sheller, Nathan Sent: Thursday, June 02, 2016 11:02 PM To: Smith, Ned <ned.smith at intel.com<mailto:ned.smith at intel.com>>; uzchoi at samsung.com<mailto:uzchoi at samsung.com>; 'RANDEEP SINGH' <randeep.s at samsung.com<mailto:randeep.s at samsung.com>> Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>; security_wg at openconnectivity.org<mailto: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<mailto:nathan.heldt-sheller at intel.com>>; uzchoi at samsung.com<mailto:uzchoi at samsung.com>; 'RANDEEP SINGH' <randeep.s at samsung.com<mailto:randeep.s at samsung.com>> Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>; security_wg at openconnectivity.org<mailto: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<mailto:Ned.smith at intel.com> +1.503.712.3695 From: <security_wg at openconnectivity.org<mailto:security_wg at openconnectivity.org>> on behalf of Nathan Heldt-Sheller <nathan.heldt-sheller at intel.com<mailto:[email protected]>> Date: Thursday, June 2, 2016 at 10:18 PM To: "uzchoi at samsung.com<mailto:uzchoi at samsung.com>" <uzchoi at samsung.com<mailto:uzchoi at samsung.com>>, ??? <randeep.s at samsung.com<mailto:randeep.s at samsung.com>> Cc: "iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>" <iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>>, "security_wg at openconnectivity.org<mailto:security_wg at openconnectivity.org>" <security_wg at openconnectivity.org<mailto: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<mailto:nathan.heldt-sheller at intel.com>>; 'RANDEEP SINGH' <randeep.s at samsung.com<mailto:randeep.s at samsung.com>> Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>; security_wg at openconnectivity.org<mailto: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:[email protected]] Sent: Friday, June 03, 2016 4:04 AM To: uzchoi at samsung.com<mailto:uzchoi at samsung.com>; 'RANDEEP SINGH' Cc: iotivity-dev at lists.iotivity.org<mailto:iotivity-dev at lists.iotivity.org>; security_wg at openconnectivity.org<mailto: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<mailto:nathan.heldt-sheller at intel.com>>; 'RANDEEP SINGH' <randeep.s at samsung.com<mailto:randeep.s at samsung.com>> Cc: iotivity-dev at lists.iotivity.org<mailto: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:[email protected]] Sent: Thursday, May 26, 2016 4:13 PM To: uzchoi at samsung.com<mailto:uzchoi at samsung.com>; RANDEEP SINGH Cc: iotivity-dev at lists.iotivity.org<mailto: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> [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<mailto:randeep.s at samsung.com>> Cc: iotivity-dev at lists.iotivity.org<mailto: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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160605/d1c485ee/attachment.html>
