Connect, right now with #sensors you care about.

MySensor switch provides security and privacy in IoT applications. With help of MySensors, IoT devices can communicate each other with guaranteeing end to end security. MySensor supports IoT devices such as Smartphones(android) and Raspberry-pi.

What is Senz ?

SenZ is a new kind of query language that can be used to communicate with IoT Devices . It is easily integrable , Ultimately fast and is in the Highest end of security integration. Also it is lively developed accordingly. As it is said earlier this uses a #twitter like massaging syntax which has made this language a usable , more powerful and understandable. The communication between each of these devices are done via the My sensors switch which was developed using python, A high-end application switch which works as a massage broker. Once client devices are registered in the switch they should share their data to specific people(Other client devices). Then the. Then they are capable of sharing massages accordingly.

Currently MySensors switch is implemented on two languages one is Python and the other one is Scala. In either case it doesn't matter in which language your clients are built on. You can use either of the implementations to suit your product. currently there are two implementation which works on UDP packet connection and TCP packet connections.

What is senz Switch ??

senz switch is the core working body of this amazing system. This exhibits its outstanding features that can beat the systems that is available on the market. It is a compound collection of several features in to one and is the key to its multithreaded high speed massage passing system, it is also integrated with its security features that beats any of the available systems in the market. High availability and Higher bandwidth is achieved through python Twisted. senz switch is integrated with a MongoDB database to keep its user registration data ,public and private keys stored, timely information etc. but the interesting thing here is that it does not keep any of the passed data or even read those data when passing.
So you don't need to worry about using your private devices connected with SENZ to have second though that your data is revealed and passed through unknown servers. Because you are 100% that when the data is encrypted and it can only be decrypted in to the massage only by the intended end device and the device only.

what's for you Developers....... ?

It is obvious that you might have the idea that will it be possible for us to integrate it in to our system. Or How could we use it in our systems. Sure its the very reason why we have build this in the way it is.
You developers can develop your applications on top of this platform. There is a senZ switch written on python. So you will have to install it in a separate server . Then you can use the developed senz client service written to multiple platforms both mobile and android on which you can develop applications to communicate using Internet securely with authentication, integrity, confidentiality and non-repudiation of data together with the access control. .

Internal Working (massaging Structure)

As it was said earlier senZ follows a #twitter like massage structure which has made it unique compared to the ones out there.

                  <type> #<attribute name> <attribute value> #time <current timestamp> @<receiver> ^<sender> <digital signature>


                  <type> $<attribute name> <attribute value> #time <current timestamp> @<receiver> ^<sender> <digital signature>
<type> Here, type refers to the type of the massage to be sent currently it has 5 types of massages. They are SHARE,UNSHARE,GET,PUT,DATA. Each of these massage types are used for different purposes which will be discussed later.
#<attribute name> Attribute name depends up on your purpose. If its a attribute value from a thermometer it might be #temp and if its a water level #water_level and so on. It's yours to define the attributes you are using and sharing.
$<attribute name> This is not much different from the previous but it simply says that the value referred to this attribute is encrypted.
<attribute value> This is the value of the attribute you are sharing/sending. It could just be an integer,string or what ever you wish according to the attribute you are using. This field is ignored in some massage types and they will be discussed detailed below.
#time This is also a attribute but since time is a default attribute it has to be sent always.
<current timestamp> This is the value of the time attribute
@<receiver> This is the user name of the receiver of the massage.
^<sender> This is the user name of the sender of the massage.
<digital signature> This is the digital signature for which the sensZ-switch uses to verify that the intended user has sent the massage.

SenZ types

There are five types of SenZ. These types are SHARE, UNSHARE, GET, PUT and DATA.

SHARE This massage type is used when you need to share some attributes to some client/device.
UNSHARE This does the opposite of the SHARE
GET This massage type is used when you are requesting a SHARES attribute from a client/device.
PUT This massage type is used when you need to do some alternation to the device. When you need to control some device/application/client.
DATA This massage type is used when replying to a GET,PUT or a SHARE. To send the reply with the requested data.

Message attributes

Attributes are custom defined key/value pairs (values can be empty). Attributes comes with “#” sign. For an example #time #lat #lon etc. Different types of attributes can be defined according to the application scenarios. Other than custom defined attributes we have defined special attribute such as #pubkey, #key #time and #msg. #pubkey is corresponding with a public key of a device and #key is corresponding with a session key (AES 256).For an instance, when device is registering with switch called senz, we need to share the public key to the switch by sending the following Senz.

                     SHARE #pubkey <base64 encoded pubkey> #time <current timestamp> @senz ^username <digital signature>

Let's Take an Example scenario

Let's assume a Bank b1 would like to share balance transaction securely to a user u1.

  • The bank (b1) should send the following Senze and obtain the public key of the user u1.
    GET #pubkey @u1 #time t1 ^b1 Signature
  • Senze switch delivers the public key as follows(If u1 is not exists, public key will not be sent).
    DATA #pubkey PublicKeyOfu1 #time t2 ^mysensors Signature
  • The bank(b1) should share the balance transaction and a AES key (k1) to the user u1. The key k1 is encrypted with the public key of the user u1.
    SHARE #balance $key E(k1) @u1 #time t3 ^b1 Signature
  • The user (u1) should reply to it as follows.
    SHARE #msg OK @b1 #time t4 ^u1 Signature

  • The bank and the user can keep this AES key for encrypting the balance transactions. The bank can refresh the key by repeating the third step

  • The user(u1) should request the balance by sending the following SENZE.
    GET #balance accountNumber @b1 #time t5 ^u1 Signature
  • The bank b1 should response to it as follows. Account balance is encrypted by using the AES key(k1).(Upon received this DATA SENZE, user should decrypt it and display it on the application.)
    DATA $balance E(x) @u1 #time t6 ^b1 Signature

Sustianable Computing Research Laboratory  

35,Reid Avenue, Colombo 7, Sri Lanka
Phone : +94112581124