Hi Nathan/Kishen,
I suspect that my clear requirement has not been checked yet because there
hasn't been no comment over my previous email. (Let me write again below)
Favorite security support is num#1 below. Secure resource and non-secure
resource are co-exist by distinguish from /oic/res payload with p property.
Second use case model is alternative solution if the first is not feasible due
to some reason.
However, some concerns over this option I have, as below. Moreover, Switching
between secure/non-secure may requires additional adaptation layer.
Clearly, let's think how to put the IoTivity binary into Windows as platform
component.
///// Quoted from the last Friday response. //////
You separate iotivity library(binary) as three classes, (dual security mode,
normal security mode with security enabled and normal security mode with
security disabled.)
SDK deployment perspective, only dual security mode will be required which is
little bit different my dual security definition.
As a API usage two possible cases I can imagine as follows.
1. Start IoTivity instance and create Resources, some of them are secure
resources and the others non-secure resources. And Client side can be also same
scenario.
Anyway, this scenario requires two socket ports in IoTivity.
2. Start IoTivity instance with the secure mode selection as parameter,
but this will not requires the IoTivity stack build. This is more similar
matching to your Dual Security mode definition.
Some security related API usage in the Security disabled mode, can pass the
logic execution or return the error. This kind of logic could be applied in 1)
Certification will be verified on the protocol communication level not by API,
so that any of this logic change will be independent from internal ioTivity
logic and API change, I think.
///// ------------------------------------ //////
BR, Uze Choi
-----Original Message-----
From: Heldt-Sheller, Nathan [mailto:[email protected]]
Sent: Tuesday, June 07, 2016 12:13 PM
To: Maloor, Kishen; 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 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: <[email protected]> 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:[email protected]]
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:[email protected]]
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:[email protected]]
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
