Introducing the SAFEthing Framework: Secure Access For Everything

[goindeep]

Network Architecture

Network Security

Any thoughts on this @bochaco ?

[bochaco]

From what I can get from that documentation, it sounds really cool in terms of trying to make it easy for devs to create apps and integrate them into an IoT network, a network which in turn integrates itself to LoRaWAN.
So if you need to be able to connect thru radio seems to be a nice thing, it seems you just buy one of those gateways and you are good to go.
I can imagine having LoRaWAN gateways which can connect devices to the SAFE Network as well, just one of the options as meshnets will be, I presume…?

However, I still see the same problems as with other existing IoT networks/protocols, e.g.:

• “user accounts are stored in the account server. These accounts are identified by a username or e-mail address and protected by a password.”: a server for auth/accounts and permissions to apps, we know what that means. It’s mentioned that there is e2e encryption, will that be affected if I can hack one of the servers holding users/accounts/permissions info?

• “The preferred option is to connect to the public community network hosted by The Things Network Foundation or its partners. In this case the Application connects to a Public Community Network Handler, usually using the MQTT API.”: more servers, the network seems to be simply a network of servers with some personas/agents (Broker, Handler, etc.), they mention you can have a private network as well and we can imagine the costs for such a thing to maintain and secure it. I suppose such a network can be sensored or even shut-down quite easily as well, right?

• I don’t see how you can have full anonimity, I don’t see how I can have a device which I plug into that network and which can connect to any other device on the planet without needing to expose my devices’ IPs, or even exact location (it sounds that to be able to receive downlink messages in LoRa you may have to be exposing the device’s exact location to the rest of the network, not sure though).

• The same concern of anonimity for applications, I don’t see how you can deploy aplications totally anonymously, from what I get you’ll have to have a server to host it, and the network needs to be aware of the devices that are linked/associated to the app/s…?

I’m not sure also about the costs, perhaps it’s not a big deal for companies, but how much money I’ll need for hosting my app and having access to the network? what if I want to use it once a year only…

@goindeep, I’m not an expert on this, but that’s what comes up to my head when reading those docs, so just thinking out loud here. I do like they are abstracting devs from the network topology and complexity of the comm though.

BTW, it’ll be really good to get other people’s analysis here as well.

[mav]

@bochaco

receive early feedback and thoughts about it from all of you. This documentation explains the technical aspects of it, but more importantly the goals of the project which I really would like to highlight and I will be looking for support for.

Very cool idea.

The goal “Allow the SAFE Network community to participate in a project” is one I’m currently trying to do! I want to use this to put a temperature sensor up on alpha 2 and am looking at this library.

The printer example seems to outline an rpc scheme for the printer, but I can’t see how to log data to the network, eg saveMeasurement(temperature); - this is supposed to be done with dynamic attributes but I couldn’t grasp how to use that.

Maybe the printer example could include some code to log the ink level periodically.

@tfa

the blocking problem is the Pay for Post

My suggestion here is the library should automatically keep data locally until it’s 1MB and then bulk upload to immutable data + add a pointer to an MD.

Anything needing recent data can directly request it from the device rather than from the historical IDs.

So recent data is direct p2p with the device, historical data doesn’t touch the device and is pure SAFE network requests.

It’s not ideal but it’s a start.

Another way to improve the compromise of PUT consumption vs recency of history might be to aggregate multiple sensors into a single ID/MD data structure so it fills up faster and can be published sooner…?

@edapa

they could use the SafeNET as a coordination/metadata layer to use in order to find one another (by appending their ip addresses to an AppendableData for example), then communicating directly using standard protocols like TCP.

I really like this idea.

But I guess it needs some careful thought regarding security so it’s not vulnerable to direct DOS attacks.

I suppose there’s two main ways IOT operates: 1) data logging, ie device outputs 2) remote control, ie device inputs. Logging is similar to a frequently-updating-website, remote control is similar to a chat room or email system. Will be interesting to see how data distribution ends up, how much is p2p and how much is SAFE.

@neo

I would expect the IoT devices have to be shielded from the internet by a gateway, minimum NAT

A good alternative is to have the device be ‘dumb’ and only write data onto the network for others to read. The device might have an inbox which it can read and maybe do stuff based on the content of messages. This way SAFE is the shield. An attacker can spam the inbox with nonsense but it’ll cost them much more than a direct attack.

@edapa

what advantages does the SafeNET provide over current IoT security best practices

• No servers for data logging, just a config file on the device. This means it really does ‘just work’. If it doesn’t work the problem must be fixed on the device, less possible things to debug.
• Private and secure operation is the default.
• Network uptime is presumably much higher than a server-based provider.
• Scaling is built in.
• Backups are built in.
• Hopefully the SAFE IOT library will promote a standard data format so interoperability and GUIs/dashboards are built in and not locked to the data format. I think RDF could improve this too with linked data.

@bochaco

many of the current IoT protocols use the publish-subscribe pattern

Yeah I think the publish-subscribe pattern is a natural way to do IOT on SAFE. From the wikipedia “senders of messages, called publishers, do not program the messages to be sent directly to specific receivers”. This means a device can publish to millions of listeners with zero overhead.

“publishers post messages to an intermediary message broker or event bus, and subscribers register subscriptions with that broker” - I guess in this case a broker is a mutabledata object.

---

It’s interesting to look at existing companies in the IOT space and consider how they might benefit from SAFE, eg thingspeak.com, sense-iot.com, sitewhere.com, aws iot, google cloud iot etc… most of what they do is not data storage!

[neo]

@mav

A good alternative is to have the device be ‘dumb’ and only write data onto the network for others to read. The device might have an inbox which it can read and maybe do stuff based on the content of messages. This way SAFE is the shield. An attacker can spam the inbox with nonsense but it’ll cost them much more than a direct attack.

The issue I see here is that there still needs to be software to talk the basic tcp/ip or udp and that maybe vulnerable to attack. EG you mentioned (D)DOS. Or there maybe a bug that causes the stack to accept a packet. (eg the stack implementer wanted to be able to rewrite PROM on the fly for some reason unknown to us). The IoT device still relies on a bug free implementation of the base level protocol stack.

Or have I misread things and the low level safe protocols replace it.

[bochaco]

@mav

The goal “Allow the SAFE Network community to participate in a project” is one I’m currently trying to do! I want to use this to put a temperature sensor up on alpha 2 and am looking at this library.

This sounds like a dream @mav! let’s work together on making that happen, I’m sure we’ll get more people on board very soon if we showcase something.

@mav

The printer example seems to outline an rpc scheme for the printer, but I can’t see how to log data to the network, eg saveMeasurement(temperature); - this is supposed to be done with dynamic attributes but I couldn’t grasp how to use that.

Maybe the printer example could include some code to log the ink level periodically.

Absolutely, the example code is very incomplete yet as you pointed out.

Last set of changes I pushed a few days back was my initial draft code for supporting notifications, i.e. notifications for when a device receives an action request from another device, or when a device has subscribed to any other device’s topics and an event is to be notified.

Let me try to add some snippet code to the printer code to show the use case you say, It’s probably already possible, e.g. by publishing a topic temperatureChanges which other devices can subscribe to, but let me work on it and add such an example to the printer example code to make it clear for everyone.

I was right now trying to finalise the notifications code and associated API, so this is a good timing, just bear with me and I’ll share an update here whenever I have it ready for you to take a look and have it a go, hopefully in the next couple of weeks. I honestly didn’t expect anyone would yet want to use the framework, so it’s really good news there is someone already!

@mav

“publishers post messages to an intermediary message broker or event bus, and subscribers register subscriptions with that broker” - I guess in this case a broker is a mutabledata object.

This is the approach I am taking at least now to begin with, and that’s how I’m implementing the notifications logic, just an inbox and the framework takes care of polling it and call back the client device’s registered function. I’ll hopefully get this cleaner in the printer example, and docs in the near future too, since I’m also trying to write some API usage documentation.

@mav

It’s interesting to look at existing companies in the IOT space and consider how they might benefit from SAFE

Totally agreed, I really appreciate you, like others here, are sharing all those links and info about other projects, there is a lot to learn here to make this very appealing to dev users and something that eventually companies would also consider for their IoT products.
The way I see this evolving is trying to have something that geeks can easily use to create some personal projects with to be able to communicate with devices without needing those centralised IoT cloud services. If that goal is achieved, I’m sure we can keep evolving this framework to provide interoperability with other standard protocols and assuring it’s good enough for mainstream IoT products.

[happybeing]

Woo hoo a dream team forms @bochaco and @mav, I can’t wait to see this.

[Nigel]

It feeeels like things are heating up but I’d like to actually gauge the temp…

[bochaco]

I think I have a nice update here to share with the stuff I’ve been working on in the last month or so (cc: @mav this will hopefully answer some of your previous questions including the one about authorising the SAFEthing app).

As I mentioned before, I was trying to finalise a basic version of the API which supports the publish/subscribe pattern for dynamic attributes, topics, as well as for sending action requests to other SAFEthings registered on the network.

I managed to have something functional along these lines and a couple of much nicer and complete example SAFEthings implementations. I won’t put all the details here as they are in the repo and the code itself, but I created a couple of SAFEthing applications which showcase how the SAFEthing API can be used to implement a gardening system, having one SAFEthing which manages a soil moisture sensor and a water valve (core/examples/gardening_device.rs), and a second SAFEthing which acts as a monitoring and controller device for the gardening system (core/examples/gardening_controller.rs).

Also I added support for authorising the SAFEthings using the SAFE Authenticator CLI running locally.

Please look at the instructions I put in the README for full details of what these SAFEthings do and how to run them with Mock network and the safe_auth CLI.

I now have to work on several things in the implementation behind the API, but this shows a bit better what’s the goal I’m after in terms of the API and capabilities of it. I already started looking at Futures, Tokio, async/await to better understand how I can enhance the API to make it fully async, e.g. to allow to have subscriptions and action request handler functions to all run asynchrounously and in parallel, among other things I have to refactor to make it really scalable to more complex use cases.

As always, if any of you give it a try or look at the code of these new examples, I’ll be happy to receive feedback, specially around the API I’m trying to expose.

[Toivo]

@bochaco

basic version of the API

Hey cool, finally a programming language I have actually used for coding! Now I can do something actually useful and start developing SAFE for Amstrad CPC464…

Ok, carry on…

(Edit: Oh, with a bit of googling I found out that BASIC is actually still around. Difficult to make jokes with a jargon you actually know nothing about. Doesn’t prevent from trying, though )

[drehb]

Looking good! The readme states the project goals and issues with current IoT designs very clearly, so I’d encourage everybody to take a quick peek at that. It’s great that you’ll be able to provide bindings for all languages through FFI too.

[intrz]

What kind of soil moisture sensor and water valve might be used with this?

[bochaco]

@Toivo

Hey cool, finally a programming language I have actually used for coding!

…like many I started coding with BASIC, strictly speaking I think it was QuickBASIC.

[drehb]

Fyi - I see Mozilla has been working on an IoT solution too.

[bochaco]

That looks really cool, the WebThings Gateway UI/dashboard is exactly how I imagined we could authorise the SAFEthings, you basically have a portal/dashboard where you enter or scan the device’s serial number and then it is able to provisiong it with the credentials to connect from there on without the authenticator or gateway. I’ll definitely be looking at this to see if there is a possibility of making the SAFEthing framework compatible with their gateway.
From what I read they basically provide you with a free subdomain and a tunneling service so you can access the gateway (and the managed devices data I guess?) remotely/from other network. Thanks @drehb!

[intrz]

In addition to the Gateway there’s the Web Things API. Maybe it could be useful to support this API in SAFETHINGS.

[draw]

Anyone here experience with gRPC as an alternative to Rest (uses Protocol Buffers)?

[bochaco]

@intrz

In addition to the Gateway there’s the Web Things API . Maybe it could be useful to support this API in SAFETHINGS.

Yes, their webthings framework is an implementation of that spec/standard they are proposing, and the gateway also follows that same spec so you can manage things using that API, the gateway is in itself a webthings since it has its own data but stored locally (e.g. the devices you monitor and rules you can define). Thus anything supporting that API spec should be compatible in terms of communications to send actions, subscribe and receive notifications, etc.

From what I was reading the model proposed there is very close to what I am already exposing in the API, which is basically:

• topics to subscribe to and get notifications, they call it events
• static and dynamic attributes (to which you can also subcribe to), they call it properties
• action requests can be sent to devices and the change of action’s state is notified back to the caller, they also call them actions

I find the gateway very interesting because it could save me/us a lot of effort in terms of having a nice UI for the SAFEthings (and anything related to administer them, e.g. authorising them with an Authenticator as I said before), so I might give it a try creating what they call an adapter or addon for their gateway and see how that could evolve.

@draw

Anyone here experience with gRPC as an alternative to Rest

I don’t, but I do agree with some of the main incentives behind it: “In my time using REST API’s I have encountered many discussions about status codes (which do not map very well onto your application errors), API versioning, PUT vs PATCH, how to deal with optional fields, when to include things as query parameters etc. This can lead to inconsistent API’s and requires clear documentation.”
I did work a bit with WSDL in the past, and SOAP which was quite annoying and bloated.

[happybeing]

FYI there is some interest in IoT and discussion of WebThings in the Solid chat. Maybe another opportunity for collaboration at some point;

solid/chat

[draw]

gRPC in Rust

Edit: made link work

[tfa]

I get " 404 Not Found". Am i missing something?