Is it possible to enable security?

[alexander-larsson]

Hello, I'm trying out IoTivity and as part of this I built a simple web GUI using Angular and Node (and this package). I did this without using any security and now I want to enable security on my devices and the client (the GUI). I have some C++ devices which can be secured but I cannot find the same option in this JS implementation. It is not implemented yet? I am using the high level API if that matters.

[gabrielschulhof]

Well, TBH I haven't really tested it in secure mode. You can certainly set secure: true on a resource when you register it, i.e.,

device.registerResource( {
    ...
    secure: true,
    ...
} );

though like I said, it's not very well tested. I'll try to look into writing some tests for secure resources as well.

[alexander-larsson]

Thank you for very fast response! Anyway, I tried that and it doesn't do anything. WireShark can read those packages as an open book so they don't seem to be encrypted.

Is that flag just something that enables the possibility of security or how does it work?

[gabrielschulhof]

I'll have to work my way through from the C API all the way through the bindings to the high level API and make sure the flag has an effect. Then there's that whole configuration JSON file that I need to figure out ...

[alexander-larsson]

Is setting that flag the only thing I'm supposed to do then? I have been trying to read the OFC/OIC spec and it seems like quite a bit of stuff is involved in the security. Does IoTivity abstract all of that to just setting one flag?

[gabrielschulhof]

Well, that and the JSON configuration file, AFAIK. I haven't really looked into it yet, but now's as good a time as any.

I'll start by writing a client/server pair in plain C, and then modifying them until they communicate with each other securely. After that, I can build the node.js bindings on top of that.

[gabrielschulhof]

Oh, and you have to build iotivity with SECURED=1, which iotivity-node doesn't currently do. Still, if you build iotivity yourself and point the iotivity-node build process at the external library via OCTBSTACK_CFLAGS and OCTBSTACK_LIBS (like the README.md says) then you can get it running against a version that is "secured". All the tests fail, needless to say, because they're designed to run plain text. Still, once I get the plain C pair going, maybe I can modify the tests to get them to run in secured mode.

[alexander-larsson]

Thank you so much. What is this JSON configuration file your talking about? Is it like the "Secure Virtual Resource (SVR) database" mentioned here?

[gabrielschulhof]

Yes.

[gabrielschulhof]

I've looked into getting secure mode to work, but I'm prevented from turning on SECURED=1 for iotivity-node by https://jira.iotivity.org/browse/IOT-920. I need all the non-secured resources to keep working even when iotivity is built with SECURED=1 before I can switch to using it in that mode.

[gabrielschulhof]

The problem is that in the absence of a configuration JSON file there is no way that resources can be created, even insecure ones.

[gabrielschulhof]

I've pushed https://github.com/otcshare/iotivity-node/tree/secure/, which enables security.

It contains a client/server pair js/high-level-client-example.secure.js resp. js/high-level-server-example.secure.js.

So, if you install iotivity-node from that branch, you can then play with the example client/server pair as follows:

1. rm -rf ~/.iotivity-node

   NB: This will reset all your old iotivity-node device IDs!

2. Run js/high-level-server-example.secure.js
3. ls -l ~/.iotivity-node and remember the long number. Let's call it x.
4. Run js/high-level-client-example.secure.js. This will fail to perform the retrieve request. That's OK.
5. ls -l ~/.iotivity-node and you should see a second long number, different from x. Let's call it y.
6. Edit ~/.iotivity-node/x/oic_svr_db.json
7. Add "/a/high-level-example" to the list named "rsrc" under "acl"
8. Edit ~/.iotivity-node/y/oic_svr_db.json
9. Copy the base64-encoded device ID of the client from the "deviceid" property of the "doxm" entry. Let's call the copied value clientDeviceId
10. Add "ownrs": [ "clientDeviceId" ] to the "acl" entry of ~/.iotivity-node/x/oic_svr_db.json
11. Save ~/.iotivity-node/x/oic_svr_db.json and exit both editors
12. Run js/high-level-server-example.secure.js
13. Run js/high-level-client-example.secure.js

The client should now successfully perform a retrieve request on the server. If you remove the item "/a/high-level-example" from the list name "rsrc" under "acl" in file ~/.iotivity-node/x/oic_svr_db.json, then the retrieve request will fail with ACCESS_DENIED.

So, you can play with iotivity-node security by manipulating these two files.

If you need help setting this up, I can make you a screencast that shows you how to do it.

[alexander-larsson]

Thanks, I will try this out tomorrow.

[alexander-larsson]

I tried this but I don't quite get what is going on. Just as you say, removing "/a/high-level-example" from rsrc will cause the client to report an error (it doesn't print ACCESS_DENIED but a number instead, I think "Error 63") when retrieving.

I have recorded the traffic with Wireshark and it is not encrypted, you can read it in cleartext. Somehow, the server responds with 4.01 Unauthorized when performing GET on /a/high-level-example when the string is removed from rsrc.

What is going on here, why is it denied with "/a/high-level-example" removed, how does it make that decision? Shouldn't the traffic be encrypted with DTLS?

[gabrielschulhof]

You're right. Unfortunately, I don't know much about how iotivity actually works. I just made sure that whatever it provides for people writing C it also provides for people writing Javascript. AFAICT there is no C API for explicitly turning on encryption.

You might be able to get more help from the mailing list iotivity-dev@iotivity.org. Of course, the scope of their work is limited to the C, C++, and Java APIs, so there might be a bit of a disconnect between what they tell you, and what you see in the Javascript APIs. Still, that mailing list is the main place for such discussion.

The good news is that it seems they're working on https://jira.iotivity.org/browse/IOT-920, so that may actually remove a barrier from my including a secured version of iotivity in the next release of iotivity-node.

Another approach you might want to take is to install the secure branch with npm install --debug, which causes iotivity to be built in debug mode, in which case you get a flood of debugging information to the console from iotivity whenever you run it. That might tell you more about what's going on.

BTW, I really appreciate that you're taking the time to familiarize yourself with iotivity and with iotivity-node, and I'll try to help you whereever I can.

[treadingwell]

Seems this was fixed in late June. Any chance of updating the fixes and including it in a future release?

[gabrielschulhof]

@Zone-Ghost it's on my radar. The key is that I must make the build pass in secured mode. To do that, I need to precede each client/server test with a prologue in which I make the server completely trust the client so that the client may have unhindered access to the server.

So far I've been trying to accomplish this the "canonical" way, that is, by transferring ownership of the server to the client using the provisioning manager. Unfortunately iotivity hasn't yet made that work. In fact, if you build the provisioning samples from the latest iotivity master with SECURED=1, and run the provisioning sample server and client, you will find that the client isn't able to discover unowned devices (which the server should be a member of), and is thus unable to initiate ownership transfer.

So, the fallback is to create the access control lists manually as described in my earlier comment, except that iotivity has changed the expected format of the acl files from JSON to cbor, which makes me have to convert the JSON to cbor before the file can be read by iotivity.

I will pick this issue up again as soon as I can. Please bear with me :)

[gabrielschulhof]

@Zone-Ghost IOT-920 has not really been fixed, which is why I've reopened it. Nevertheless, I've been able to get the build to pass in SECURED=1 mode lately, so I'll mark this issue as fixed as soon as I release that.