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<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:[email protected]] 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/20160602/df5fb819/attachment.html>
