Hi Nathan,
Frankly I haven?t looked into detail security related path yet. Please
understand my understanding or proposal is on top of lots of assumption.
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
From: Heldt-Sheller, Nathan [mailto:[email protected]]
Sent: Friday, June 03, 2016 2:18 PM
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, 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:[email protected]]
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:[email protected]]
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: [email protected] [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
-------------- next part --------------
HTML ?????? ??????????????...
URL:
<http://lists.iotivity.org/pipermail/iotivity-dev/attachments/20160603/25d3a08e/attachment.html>
