Introducing the SAFEthing Framework: Secure Access For Everything

Apps
1

Several months ago when I decided to get more involved with the SAFE network project I decided to start learning Rust, not only because I was curious to understand why the whole project was moved to this programming language, but also because I wanted to be able to understand the SAFE network core library’s code. So I started exploring it and I started to think of what project I could use as a driver and excuse to learn about different aspects of the language.

All these shy thoughts and desires about learning the Rust language and the SAFE network Rust libraries led me to think that developing a small application on a Raspberry Pi would be cool and fun to do, so I started digging into how current IoT protocols work, specially what was their communication protocol, since I heard a lot of buzz about it but wasn’t sure what was the big deal with it.

I found out that there are several frameworks and protocols out there (e.g. MQTT and CoAP) but they are all pretty much having similar issues, and their challenge seems to be mainly related to security and NAT (to connect to the devices in different networks). Then I found out that the way they all seem to solve it is by having servers/brokers in the network, which not just adds complexity to the development of the devices’ software, but it also brings in security concerns about who you are sharing the information with when your IoT things need to communicate using these servers, you are forced again to trust third parties.

At this point, it wasn’t so difficult for me to realise that the SAFE network was an excellent fit for it as it solves all these issues without me needing to worry about them, or to learn about them in the first place, I could just focus on developing the logic of my device!. And soon after, I realised that it would be really nice if this could be taken even a step forward: what if I don’t even need to understand much of the SAFE network and be able to integrate my IoT device easily?, and that was when having an IoT framework for the SAFE network was a trivial thing to imagine for me!

So that’s how, since then, I ended up working on this project and I’m really excited about sharing this idea with all of you today.

I’ve been working on the design and implementation of it, and even that the code is still not ready to share and I prefer to wait a bit longer before publishing it (since one of the goals is to be easy to understand), I didn’t want to wait any longer before sharing details of the project with you, as you will see what’s the whole purpose of it and the way I’m personally looking at it.

I therefore put some documentation together to share so I can 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.

More to come in the next few weeks, stay tuned! :slight_smile:

73 Likes
2

Never cease to amaze @bochaco and I like the reuse/rebrand of the SAFE acronym :slight_smile: I’m sure @neo could provide good feedback he is quite interested in IOT security I believe.

12 Likes
3

Thanks a lot @Nigel

I just fixed a reference to a diagram which is actually a nice overview of the framework.

6 Likes
4

That’s seriously impressive stuff! I know MaidSafe have been looking at the IoT for some time as a logical use case for SAFE - and as if by magic here is the first step :slight_smile: So this means that in theory you shouldn’t need any sort of gateway between the IoT device and the network, each device can connect up completely independently of the others? How do you see multiple devices being co-ordinated, for example sensor networks?

9 Likes
5

Impressive, @bochaco! If you ever start a company and need financing pm me lol :wink:

Seriously, though. You’ve hit the nail again. Remember the Mirai IoT slave-network that shut down half the internet? IoT security is THE thing! And the safenet a logical next step. Great to see you having fun working on it!

I find the the goals to be on spot, I can’t judge the technical details.

6 Likes
6

Yes, we could do fabulous things in a secure way with IoT on safe network but the blocking problem is the Pay for Post.

IMO, it’s OK to pay once to create a MD the first time a device is connect to the network but having to pay each time an information is received from a sensor or a command is sent to an actuator is prohibitive.

I know this has been added to limit spam on POST requests but I am afraid this is also a critical flaw that greatly limits IoT use case.

1 Like
7

@bochaco wow man, this is a great initiative, opens up a whole new area :slight_smile:

@tfa how about each device is assigned an account and this has a PUT balance that is topped up by an app whenever it drops below a certain level? Not perfect, but good enough for the time being, until perhaps IoT devices can farmvfor their usage.

4 Likes
8

Great and impressive work @bochaco :clap:

From the quick viewing of it, I gather it runs on a device that provides the interface between the Devices and SAFE? Rather like a interface/converter/gateway?

Yes that is an issue for updating (SD became) MDs. When I was considering the implications for IoT devices it was more the sensors talking over SAFE to the controller (that could be anywhere in the world) and that would be more messages rather than updating (SDs became) MDs and they would be paying regularly.

My thought on the matter was that there would have to be at least one account anyhow and that would have its own supply of SAFEcoins and relying on the (mentioned a few times in the past but not recently) feature of a “purse” which the network could take a coin to pay for next batch of PUTs.

But then there was also talk of simple messages being free (pay for outbox SD only), but now with MD updates being paid for it seems even simple messages will be charged a “PUT”

I guess like @happybeing says the IoT gateway will have to farm as well to pay for the SAFE transactions it does.

4 Likes
9

Perfect timing @bochaco

I wonder if this is our beloved @janitor up to mischief :stuck_out_tongue:

6 Likes
10

How central to the SAFE network is the payment mechanism? Could it avoid being DDoS’d and spammed in an IoT scenario without having the Safecoin market as a constraint? Currently the IoT is a very different beast to the regular Internet, connection to which is only really required to allow for human interaction with the things. In other words could there eventually be a separate SAFE-IoT for machine-to-machine use cases that doesn’t need Safecoin?

3 Likes
11

Messaging was going to be that mechanism and very efficient. But now that is in doubt. There has been no word from the devs and I’d say they are not sure either till these things are fully examined. Maybe like safecoin transactions messaging could be essentially be free too. Who knows, but it is likely if MD updates are charged then so will be messaging which currently needs SD updating.

3 Likes
12

Thanks guys for the comments! really appreciated!

This is really up to the developer or design of the application, you can integrate your device directly to the network (as @JPL says) if it’s capable of having a client which interacts with any of the non-REST interfaces like Rust, FFI, JS binding, etc.
If the device is otherwise very limited, or you prefer to only make it communicate with a REST interface (e.g. I understand that ESP8266 provides you with both options), then you can use the REST interface and have a second device which can act as the gateway for it.

So you can have different type of combinations really, a device could act as a gateway for tiny sensors, and at the same time contain its own functionality exposed as a separate SAFEthing. One case I imagined was that perhaps web consoles/portals would be developed which are used to manage your devices (this is described in the register & publish sequence diagram), e.g. provisioning them with the auth URI, so a device registers when you plug it in, but it may then need to be published by an admin/owner thru a console.portal. The console could be the one requesting access to the SAFE authenticator thru the SAFEthing frameowork, and then provisioning the sensor with the auth-URI.

6 Likes
13

That’s awesome! I think there is a lot of potential here because the IoT market is still very much emerging, and there is room for the SafeNET to make a name for itself. It is very much in contrast with the traditional clearnet space where the SafeNET will have its work cut out for it to provide a compelling case to switch to people who don’t buy into the philosophy.

3 Likes
14

IMO, it’s OK to pay once to create a MD the first time a device is connect to the network but having to pay each time an information is received from a sensor or a command is sent to an actuator is prohibitive.

I agree, but fortunately I don’t think IoT devices would have to (or should) send all data though the SafeNET. It seems like a much more reasonable design that 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 have not done much work in the IoT space, but it seems like network coordination is the hard problem that the SafeNET could solve without causing an undue financial burden.

3 Likes
15

SAFE can give you a history of data, similar to what thingspeak or equivalent currently does. I guess an MD per sensor could be used as a ring buffer to track x amount of historical data.

16

Very interesting project!
You’re saying you think a Rust SAFE client could run on the ESP8266 directly? That would be cool. When I was talking to @neo about this before we thought it would probably need to use a more powerful proxy device to access SAFE.

2 Likes
17

This is actually how many IoT devices work today by establishing the IP addresses by a trusted method (you suggest SAFE in the future) and are also hacked too much. Port scanners find these otherwise unsecured devices too quickly and then use a library of protocols to find one that the device recognises and then the hacker has a field day. That is one of the big problems today that the IoT sector fails to implement or are only just realising it is needed and that is that the IoT devices need to be secured, have secured communications and so forth. In the past it was ignored because of many factors with the available processing-power/memory/code-space/price being the major ones and needless to say many programmers thought their little device was not going to be found/hacked.

I would expect the IoT devices have to be shielded from the internet by a gateway, minimum NAT, or this suggestion by @bochaco (in native or gateway mode). This way each and every communications can be verified and requires little effort in programming for the downstream device to know its communications/commands are source verified.

4 Likes
18

I did a very small research and I think you have a tcp stack available apparently, but I am not sure at all that a SAFE client could run there, I haven’t researched that deep. I was just trying to point out that it could be a design decision and not necessarily a restriction that leads you to use a REST interface.

1 Like
19

Well people are running applications over WiFi talking to PCs so it must have

20

That’s interesting. As I said, I’ve never done anything in the IoT space. How would you envision devices communicating via the SafeNET. Put more directly: what advantages does the SafeNET provide over current IoT security best practices (such as they are and what there are of them)?

2 Likes