Winners of the Open IoT Challenge 4.0

We are very happy to announce that we have been selected as the runners-up of the Eclipse Open IoT Challenge 4.0. Yesterday we received the official notification and today we are even happier once we have assimilated the news.

As a result of this state of euphoria, we are celebrating our runner-up prize, with a complete redesign of the website 🙂

The challenge has been a very enriching experience for us, and an excellent opportunity to learn, experiment and validate our ideas. The employing of this wide range of technologies has been tremendously inspiring, allowing us to conceive new ideas that we will gradually post on the website.

As competitors, we would like to congratulate the rest of the winners Martín Álvarez (first place), and Domenico F. Bruscino (third place), as well as all the participants, who have been working very hard during last months.

Finally, we would like to thank the Eclipse IoT Working Group for making possible this experience.

Next year more and better. See you at the Open Challenge IoT 5.0 😉

Final report

I recently discovered this painting by Paul Gauguin and it fascinates me since that moment. The painting, seen from right to left, is an allegory of human life passing through birth, D’ou Venons Nous – Where do we come from?, the present, Que Sommes Nous – What are we?, and death, Où Allons Nous – Where are we going?.

In this post, we make a similar journey through our participation in the Eclipse Open IoT Challenge 4.0 with the project trusted indoor positioning system for nursing homes. First of all, we start with our proposal. Then, it is shown what we have achieved and what we have learned. Finally, the post concludes with our eyes on the future.

Before we start, we would like to issue a warning. This is our seventeenth post (listed at the end) and we are not going to paraphrase what we have already written in the sixteen previous posts. It would be a waste of time for us and unfair to anyone who has read the previous ones. Therefore, when we use recycled material, we will warn you about it, providing the link to the original source, just in case you want to go deeper.

Having that said, let’s start.

Executive Summary

• Where do we come from? Motivation and proposal

  • A system which provides you with a proof that you can use as an evidence of a fact.
  • Our proposal is focused on nursing homes.
    • Guaranteeing an appropriate care of the elderly in these centres.

• What we are. Results and lessons

  • How we compete
    • To gain experience, improve ourselves and try to win.
  • What we are
    • Computer engineers focused on research.
    • We have a bit knowledge about Eclipse IoT stack tools.
  • Approach
    • We focus on an interesting, useful and realizable idea.
    • We have always prioritized what we considered most necessary, to validate our PoC.
  • Technological Stack
    • Our proposal is built using Kura.
    • Besides Kura: MQTT, React, Java Servlets, Websockets, IOTA, Android….
  •  Community
    • We know very well the importance of disseminating the obtained results.
    • We have posted seventeen times, sometimes about the proposal, sometimes about technology and others about parts of the system.
  • Results
    • Jura: “It swears”; a set of Kura’s components to deploy trusted indoor positioning systems.
    • Mide: “It measures”; A repository in which we have generalized some of the experiments that we have carried out as analysis tools.
    • Mira: “It looks”; Android app focused on the relatives of nursing home’s residents and built using the Anonymous Trusted IPS of Jura.
  • Lessons learned
    • If we had not competed in the challenge trying to give the best of us, we would never have done anything of what we have done. Looking back we are proud of what we have achieved.
    • We think that this is a wonderful opportunity for many professional profiles. Students, recent graduates, entrepreneurs, curious, or like us, researchers looking to gain experience in the field.
    • We are so convinced of the advantages of blockchain technologies that we have a stack of blockchain’s books that we will study eagerly during the next weeks.

• Where we go. Future works

  • We have an overflow of ideas.
  • The results are good enough to propose more ambitious goals, but we do not know yet what will be our next step.

Where do we come from? Motivation and proposal

You do not really understand something unless you can explain it to your grandmother – unknown and wrongly attributed to Albert Einstein.

Perhaps, the closest concept to describe our initial idea is a notary system. It is not the best definition, but it is what we would say to our grandmas. A system which provides you with a proof that you can use as an evidence of a fact.

Could you think more than 5 situations in which the reading of a sensor would serve to prove something? We are pretty sure that you can think much more than 5 situations. In our case, there are dozens of situations which come to mind.

Often the events are used to prove something, but they lack any probative value to a third party since for this we must guarantee some properties in the events such as authentication, non-repudiation or integrity (anyone else thinking about keeping them in a blockchain?). However, it is not enough to store an event with those properties, but we should also guarantee that the event is real.

For us, guaranteeing the latter is much more complicated than the former, and now that the challenge comes to the end, we must say that the difficulty to find a solution which satisfied us, almost made us renounce. In the end, we found a solution that convinced us, so we should focus on win-win situations.

This led us to make a proposal focused on nursing homes.

We firmly believe that a system which allows guaranteeing an appropriate care of the elderly in these centres, is good for everyone:

• It is positive for our loved ones to have a guarantee that they will receive the best care by the staff of the nursing home.
• It is excellent for relatives, to be informed of any incident and to have mechanisms that enforce their rights.
• It is the best transparency policy for a nursing home.

We had several ideas about what kind of information to guarantee and finally, we decided to develop an Indoor Positioning System (IPS) using Bluetooth Low Energy beacons (BLE beacons or simply beacons) that would allow us to guarantee the location of people.

[16] When we speak of an IPS, the image of a plan with moving points, quickly comes to mind. This is not what we want. We want to use the locations in a way that allows us to say something similar to: X certifies that Y was in place Z at time T.

To do that, we believe that, currently, there is no better technology than blockchain. Storing the locations in a blockchain allows us guaranteeing that [9]:

1. The locations are stored in a distributed ledger and it is not possible to block their access.
2. A message cannot be repudiated.
3. It is not possible to modify or remove registered locations.
4. It is not possible to add past information that can be trusted. The timestamp of the location and the timestamp of the transaction will determine if the message should be trusted or not.

We do not want to cheat you, we would have liked to develop a visualization tool too. At the beginning of the challenge, we even started to develop a tool for it (among other things) [12]. A picture is worth a thousand words.

Why did we abandon the development of this tool? The main reason was that we had to prioritize and focus our efforts on the certification processes instead of the visualization.

To make it even clearer, we finished with the IPS in mid-February, and we had a full version of our proposal by the end of that month. We could have finished this visualization tool. Instead, we preferred to use the available time on what we considered most necessary, validating our Proof of Concept (PoC), the scalability [10,13,14] and the usability [12,15,16].

This is the general idea of our proposal. We have tried to explain it in a simple way, but since it never rains to everyone’s taste, for some of you it might have been too long and for others too short. For the latter, we refer you to these posts [2,13] in which we try to explain in more detail what is the approach that we propose.

What we are. Results and lessons

How we compete

Since the challenge began, we have had an idea in mind, we are competing. Our goal is to gain experience, but if we are competing, we will try to win, and because of that, we have tried to do our best 😉

And we want to highlight the above because it is probably one of the greatest personal lessons we have learned during the challenge. If we had not competed in the challenge trying to give the best of us, we would never have done anything of what we have done. Looking back we are proud of what we have achieved. We do not want to encourage anyone to become a psychopath obsessed with victory, but to set goals and give the best of themselves to achieve them. It’s great to compete, even against oneself.

We summarize below those things which we believe that are important to analyze in order to know how we have competed: i) what we are, ii) our approach, iii) our technological stack and iv) our relationship with the community. Due to its importance, we will show the results in a separate section.

What we are

We present ourselves. So you can get an idea of our background, we quote from [4]:

Our team consists of three computer engineers; all of us from different fields, with great interest and curiosity about IoT but inexperienced in it. Because we work with some Eclipse tools we knew about the challenge, which we thought was a great opportunity to gain experience and (why not?) get some cool gadgets for free!

We knew some Eclipse IoT stack tools, but we had worked only a little with them (Kura, Mosquitto, Paho and maybe some other). For this reason, and based on the limited knowledge we had, we started looking for an (i) interesting, (ii) useful and (iii) realizable idea.

Although we are computer engineers, so far we have dedicated more time to research than to development. Francisco J. Quesada is a PhD student, Francisco Moya is also a PhD student (he also works as Android developer), and Fco Javier Estrella is a PhD in Computer Sciences since 2015 (he recently has focused on software development).

Now, that the end of the challenge is near, we can say that this is the first time that we have participated in this kind of projects, and it has been a fantastic and enriching experience for us. We think that this is a wonderful opportunity for many professional profiles. Students, recent graduates, entrepreneurs, curious, or like us, researchers looking to gain experience in the field.

Approach

Despite being computer engineers, we have dedicated much more time on research than on development. This has conditioned us both when making the proposal and when developing it. In what way?

We believe that our strengths lie in proposing solutions and verifying their viability.  Because of that [4] we focus on an (i) interesting, (ii) useful and (iii) realizable idea and [9] we did not want to propose anything that seemed like a good idea, but in practice would not be feasible. As it is indicated in the proposal, we have always prioritized what we considered most necessary, to validate our PoC.

We do not believe that our approach is better than others. We think that it is the best one for our profiles. As we said before, in our opinion, the challenge is a great chance because it allows the participation of professionals of various types of profiles.

Technological Stack

In the past years we had developed some Eclipse RCP applications, so we knew OSGi. For us [5] OSGi is ideal for managing IoT gateways and we believe that it is a wise movement that Kura has been developed using it. It is difficult to explain OSGi in a simple way and it may be even more difficult to explain its benefits (http://tuhrig.de/when-modularity-comes-down-to-osgi/). For us, Kura is one of the best examples to prove the suitability of OSGi in certain scenarios.

Our proposal is built using Kura, being its versatility vital for our proposal. [4] Something that makes us feel especially happy is that everything works in Kura. We know that for some parts of the system there are better alternatives, but deploying everything in the same tool will help in its deployment, management and maintenance.

Obviously, we use other things besides Kura:

1. MQTT. Kura provides an MQTT broker, Artemis, and a MQTT client, Paho. Is not it great? 🙂
2. React. We have developed two websites [7,11] as Kura components that use this library.
3. Java servlets and WebSockets. We use them in Kura to provide the backend of the websites and the Android app. Moreover, we had to patch some Jetty packages in order to be able to use WebSockets in Kura.
4. The Apache Commons Mathematics Library. We had integrated this library in Kura to execute least squares methods.
5. The Legion of the Bouncy Castle Libraries. These libraries were also integrated into Kura. In this case, they are used to sign an encrypt locations.
6. IOTA. A blockless distributed ledger. We have integrated in Kura a patched version of JOTA that allows us to communicate with an IOTA node to make and read transactions.
7. Android.

We would like to highlight that [12] in our proposal we do not use the official version of Kura, but a fork in which we solved an iBeacon’s bug in the Raspberry 2. Notice that once we certainly figure out if this is a failure of Kura or an incompatibility with our system, we will carry out a pull-request.

By the way, we are pleased to tell you that we have already made a small contribution to Kura and that makes us extremely happy 🙂

Community

Due to our professional background, we know very well the importance of disseminating the obtained results. We know that this can be extremely boring, but the effort is worthy.

In our case, we started this blog when we applied for the challenge [1]. Since then, we have posted seventeen times. Sometimes with articles in which we explain the proposal [2,4,9], sometimes with more technical articles explaining the parts of our solution in detail  [6,7,8,11,14,16] and other times with more general articles [1,3,5,10,12,13,15].

In addition to the dissemination of the results in the blog, we have also created the twitter account @trustiot in which we have been tweeting our results.

Thanks to this, and to the members of Eclipse IoT who have helped us to spread our work, we have obtained quite acceptable levels of dissemination:

• Our newly created blog has received 3165 visits.
• Our newly created twitter account has 33 followers. Ok, only with us there are already three followers…, but you will not take away our happiness :). For a newly created account that specifies that it is for a challenge, we think this number of followers reflects that there are people interested in what we propose.
• We were surprised to find that we received some visits from Reddit (#1, #2, #3, #4).
• We were even more surprised to realize that in the #ict channel of Discord community of IOTA some users were analyzing if what we published in one of our last posts [14] could be useful for this project. After analyzing the ICT project we believe that what we do is not valid for that project, but who knows, maybe something of we do might help them to see something clearer (perhaps communicating IOTA nodes using MQTT to create a cluster is not a bad idea).

At the beginning of this section, it is said that all this work is boring, and we have not changed our opinion, but in view of the results, we think that all this effort was well spent.

We want to end the section indicating that everything we have developed is open source. There are three repositories at your disposal:

• JURA (https://github.com/trustingiot/jura) [6,7,8,11,14]: Trusted Indoor Positioning System for Kura.
• MIDE (https://github.com/trustingiot/mide) [10,12,13,15]: A set of experiments conducted for the challenge.
• MIRA (https://github.com/trustingiot/mira) [16]: An Android app for nursing homes.

Results

Our most tangible results can be seen just before the title of this section, three software repositories. If someone is curious about the origin of the names, clarify that we (almost) always use the third person singular of a Spanish verb (jura=it swears, mide=it measures, mira=it looks, …).

Do you want to know what you can find in each repository? We tell you.

Jura

[11] Jura is not a monolithic tool, it is a Kura’s components based tool:

• Jura: “It swears”; a set of Kura’s components to deploy trusted indoor positioning systems.
  • Faro [6]: “Lighthouse”; a multimodal beacon.
  • Graba [7]: “It records”; a recording system.
  • Ubica [8]: “It locates”; an indoor positioning system.
  • Firma [11]: “It signs”; a signer, encrypter and validator of locations.
  • IOTA’s worker [14]: A node to make IOTA’s transactions in a distributed way.

What does the above mean? It means that in each particular device it is only deployed what is necessary.

We said earlier that we have tried to do our best and we think that the parts of Jura are an example of this. We have not only implemented the basic functionality, but everything we think is useful (different beacons protocols, different positioning algorithms, different systems for the certification of locations, …).

We invite you to review the different post to discover all the functionality. Some of them even include gifs that show what the system can do [7,11].

Mide

Usually, when we develop a PoC we spend more time performing tests than building the final solution. Our case has not been an exception.

When we made the proposal we decided to use some tools that we had never used before. Due to this, we spent the first months of the challenge doing all kinds of tests and it was not until the end of January when we were able to connect all the pieces [4].

What is Mide? A repository in which we have generalized some of the experiments that we have carried out as analysis tools.

Mira

Our PoC has two parts. The main one is Jura, the other part is Mira.

Mira is an Android app focused on the relatives of nursing home’s residents and built using the Anonymous Trusted IPS of Jura.

Mira allows access to the records of resident’s locations from an Android phone. Since it uses the [11] Anonymous Trusted IPS of Jura it can guarantee that all locations are encrypted independently and that it is not possible (or at least it is not easy) to apply heuristic methods to associate transactions with a user.

Mira not only allows to check the resident’s locations by decrypting the transactions and validating its digital signature but also allows to share them with other Mira’s users using MQTT. As each location is sent to a unique address and is encrypted using a unique key, sharing an event does not compromise the resident’s security and anonymity.

Does the nursing home had some careless attitude with your relative and you have an event that proves it? Share it with who you need (your brother, your lawyer, your insurance company, …) and enforce your rights.

Do you want to know more about Mira? In its post, we show you what it does with a use case full of videos [16].

Where we go. Future works

We are very happy with our experience in the challenge as well as with the results obtained. It is said that when you are happy, it shows.

At this moment, we might say that we have something like an overflow of ideas 🙂

A proof of concept is only a proof, but we believe that the results are good enough to propose more ambitious goals. We do not know yet what will be our next step. Perhaps we will propose a more general solution or maybe we will contact nursing homes in the area to obtain their feedback, or even carry out an experimental trial. If you found interesting our proposal, we encourage you to add our blog to your bookmarks. We have the feeling that in the future we will post much more interesting things 😉

Regarding IOTA, in our opinion, it is the future. Well, maybe not IOTA, but it will be very similar. When the challenge began we had a general notion of blockchain technologies. At this moment, we are so convinced of the advantages of those technologies, but we are not experts yet. For this reason,  during the next months, we are going to eagerly study a stack of blockchain’s books with the aim of understanding these technologies in depth.

Throughout the challenge, we have realized that there is room for a huge number of solutions in this area. Some, as in the case of our proposal, will use these technologies whereas others will improve the way in which we interact with them. We believe that this is the biggest cake to be shared in the coming years and that all of us can take our part. As before, we are still unclear about the next step to take in this area. However, we are calmed because we know that while we read the books, we will have time to think about it 🙂

As a curiosity about the latter, in the last days, we have started to be interested in IOTA nodes, especially thinking about permanodes. Who knows? Maybe in a few weeks you will find a new IOTA public node powered by Up Squared 🙂

Posts

1. Kick-off (Nov 13, 2107).
2. Our Approach. Part I. Indoor Positioning System (Dec 3, 2017).
3. In the top 12 proposals!!! (Jan 25, 2018).
4. Preliminary results (Jan 28, 2018).
5. Building Deployment Packages for Kura (Feb 2, 2018).
6. Faro: A Multimodal BLE Beacon (Feb 7, 2018).
7. Graba: A BLE Beacons Recording System (Feb 12, 2018).
8. Ubica: An Indoor Positioning System (Feb 21, 2018).
9. Our Approach. Part II. Trusted IPS (Mar 1, 2018).
10. The Race to the Tangle (Mar 1, 2018).
11. Firma: In IOTA We Trust (Mar 2, 2018).
12. Testing: One, two, three (Mar 4, 2018).
13. The Race to the Tangle II. Teamwork (Mar 7, 2018).
14. Parallelizing IOTA transactions in Kura (Mar 10, 2018).
15. Testing: Four, five, six (Mar 14, 2018).
16. Mira: To Enforce your Rights (Mar 15, 2018).
17. Final report (Mar 15, 2018).

Mira: To Enforce your Rights

We are very happy to write this post, which is the last ‘thematic’ one that we are going to publish for the Eclipse Open IoT Challenge 4.0.

In this entry, we are going to talk about Mira, our Android app. It is focused on nursing homes and it is the culmination of our proposal. “Mirar” is the Spanish word of the verb “to look“; the translation of mira in English is “it looks“. You can download the code here.

It is necessary to understand our proposal as a whole in order to understand what Mira is. In a nutshell, we are participating in the challenge with the proposal trusted indoor positioning system for nursing homes:

1. An IPS is a system to position elements indoors. When we speak of an IPS, the image of a plane with moving points quickly comes to our minds. This is not what we want. We want to use the locations in a way that allows us to say something similar to: X certifies that Y was in place Z at time T.
2. To do the above, we believe that, currently, there is no better technology than distributed ledgers. Storing locations in a distributed ledger allow us guaranteeing that they can be trusted.
3. Why do we focus on nursing homes? We believe that there are big problems to address in the generalization of the use of Trusted IPS. The only cases in which it can be applied reasonably today are those in which there are win-win situations. For us, there is a clear win-win situation in nursing homes, and this is the main reason that leads us to focus on these scenarios. It is a case in which our technological proposal is useful. If you want to go deeper into our approach, we refer you to this post.

Our Proof of Concept (PoC) has two parts. The main one is Jura, a Trusted IPS developed as Kura components which is able to store locations in a distributed ledger like IOTA. Jura implements two trusted IPS systems, (i) a public system in which locations are signed and transferred to a specific address and (ii) an anonymous system in which each location is signed, encrypted with a unique key and transferred to a unique address.

The other part of the PoC is Mira, our Android app focused on the relatives of nursing home’s residents and it is built using the Anonymous Trusted IPS of Jura.

Use Case

Let us tell you a story.

It is not a funny story, but we think it is illustrative.

Let’s suppose a nursing home in which Jura has been deployed and in which all residents carry a personal and non-transferable beacon.

For each beacon, there is a unique identifier called DIW (Device Identification Word). The DIW can only be obtained by authorized staff. Notice that it is necessary to know the administration password and have access to Firma Website in order to get it. If both requirements are met and we also know the MAC of the beacon we can obtain the beacon’s DIW.

Stephen is a new resident of the nursing home. When he goes to check-in for the first time, nurse Mel assigns him a beacon. Mel provides the identifier and DIW of the beacon to Stephen and to his son Tod.

Mel explains Stephen and Tod that this is a new service that offers the nursing home to residents and relatives. A service that allows them keeping track of Stephen’s locations at all times.

This causes father and son to move from a state of curiosity to one of concern. They think: ‘anyone can monitor Stephen‘.

In order to calm them, Mel explains that the system does not work as they think. Each time the nursing home register a location of Stephen, it saves it in a different place and using a different password. Only those who know the identifier of Stephen and his DIW can know the places where the locations have been saved and the passwords that have been used.

Once the above is clarified, they ask Mel about the benefits of the service. Mel explains that:

1. It is an optional service. The nursing home has a fixed schedule for catering services, family visits, doctor visits, recreational activities and late arrivals. The staff try to take care of all residents in the best way, but like all humans, they make mistakes. Younger residents are reluctant to use the service, but those with mobility problems, dementia or Alzheimer’s disease feel safer using the service. They believe that the staff take better care of them.
2. If Stephen uses the service, all his locations will be digitally signed by the nursing home and it will not be able to remove or modify them. Stephen or Tod may use the locations to prove any negligence in the nursing home and the nursing home cannot deny the authenticity of the locations.
3. Currently, the service is in its early stages. In the future, it will offer a wide range of functionalities such as early detections of diseases, optimisation of emergency evacuations, personalized care or guaranteed attention among others.

Although Stephen and Tod are not fully convinced to use the service since they have never used anything like that, they decide to use it.

Mel explains to them that they will be able to use the service from their phones and provides them with a link to download Mira.

When they open Mira, they find two options, (i) relatives and (ii) shared locations.

Mel explains to them that they must select ‘relatives’ in order to enter the identifier as well as the DIW of Stephen’s device (beacon). Since the identifier is hard to remember, Mira allows them entering a name for the device.

# Click on ‘add relative’ and that’s it.

# Once added, to see his/her location records, simply click on his/her name.

Mel explains them that:

• The icon with the label ‘Verified‘ is the guarantee which shows that it is signed by the nursing home.
• The icon on the right allows them to share the location.

Before explaining how to share the locations, he asks them to click the label ‘Verified‘ on a particular location. They do it and Mira shows them a website.

Mel explains them that this is the place where the location of Stephen is stored, and lets them know that there are hundreds of copies in computers around the world.

He tells them to go back to Mira to explains them how to share a location.

#  The locations are shared from Mira to Mira, and to do this you only have to click on the icon on the right and enter the phone number of the other person. – Mel tells them. – But do not worry about SMS costs, we use our own communication service, something called MQTT. When you share a location with another person, you are telling them where it is stored and its password, so it is no longer anonymous. Anyway, as each location is stored in a different place and with a different password you are only revealing the location you want to reveal, the rest remain anonymous to others. Therefore, if you need to share a location with a relative, a social assistant, a lawyer or any other person, you can rest assured that they will only be able to see what you want to share.

Stephen and Tod carry out a small test between them and see how everything works as Mel has told them.

And this is Mira. We hope you find it useful 🙂

We know that there are still many problems to solve before these tools can be used with full guarantees, but we believe that in a few years they will be omnipresent. We focus on nursing homes, but the main idea can be applied directly in other contexts (kindergartens, hospitals, animal residences, …) and with some modifications in many more (check-in/check-out, supply chain management, emergency response, pay per use, …).

Testing: Four, five, six

We commented on Testing: One, two, three, that we would like to develop a software tool which would allow anyone to fine-tune his/her installation to a position as accurately as possible. This tool is ready and available in mide repository.

It is a Java command-line tool developed using Ubica code. To use it, it is only necessary to consider that:

• The name of each dataset indicates in which coordinates it has been created (x1000y2000.txt = {“X”:1000,”Y”:2000}).
• The configuration is defined in the config.properties file.

When we wrote the first Testing post we captured five datasets placing a beacon in different coordinates (the datasets are also available in the repository):

{"X":1800,"Y":1000}
{"X":3400,"Y":1000}
{"X":3400,"Y":1900}
{"X":5300,"Y":1900}
{"X":6300,"Y":1900}

We have tested the tool with those datasets and the results have been better than we expected. To put you in context, in the first Testing post we indicated the following:

At the beginning of the challenge, we carried out several tests until we achieved a maximum error of two meters when positioning. This is enough for us because it allows knowing the rough position of each beacon. In a nursing home, we could know the room in which each resident is located. If it is a medium-size room, we could also know the area in which the resident is located.

After trying different configurations we have obtained the best results with the following values:

dataset=dataset
distance.algorithm=Accuracy
least.squares.algorithm=NonLinear
retention.time=60
publication.rate=1000
delay=5
scanning.window=10000
attenuation=0.5
cutoff.rate=0.9

With this configuration the results have been as follows:

{"X":1800,"Y":1000}: 1,137 m.
{"X":3400,"Y":1000}: 0,736 m.
{"X":3400,"Y":1900}: 0,570 m.
{"X":5300,"Y":1900}: 1,084 m.
{"X":6300,"Y":1900}: 1,277 m.
Mean error: 0,961 m.

An error of less than one meter. Far beyond our expectations 🙂

Parallelizing IOTA transactions in Kura

This post is shorter than the others, but no less interesting :). We could even say that for us it may be the most important one so far.

What’s the fuss about? From now on, Jura is scalable in terms of locations stored in the tangle. How? Using IOTA’s workers.

For us, our proposal is nothing more than a proof of concept. Aspects such as health or privacy should not be treated lightly and we are not experts in any of those areas. Therefore, we focus on checking whether what we want to do is possible to validate our idea.

Something critical is the storage of locations in the tangle, because although it is ‘free’, it is not as fast as we need it. In our last post, we published experiments on how we try to make IOTA transactions more quickly. We are proud of having implemented this funcionality in Jura.

From now on, Jura has a new feature, iot.challenge.jura.worker.iota.feature. With this, we can create a cluster of IOTA’s workers that are coordinated using MQTT. We want to highlight that it is not the same to send as many transactions as possible to the tangle with random data than with data which follow a given pattern that must be maintained. Our approach, almost identical to the one used in the collaborative approach, is as follows:

• Each cluster’s node uses the worker.iota service.
• The service adds itself to the list of IOTA’s workers of the cluster, publishing a message in topic /jura/cluster/iota/worker/<worker-id>.
• The IotaService assigns jobs to each worker by publishing them in the topic /jura/cluster/iota/todo/<worker-id>.
• The workers publish the results of the jobs in the topic /jura/cluster/iota/done/<work-id>.

At this stage, the question is whether is it necessary to store 10, 100 or 1000 locations per minute? Now we can. For example, as a result of two simulations using the FIRMA address, we have obtained:

• Using an Up Squared: 11 transactions. 40.9 seconds each transaction.
• Using our LCSBC’s cluster: 35 transactions. 12.86 seconds each transaction.

Obviously, the next question would be, how many computers are necessary to make X transactions? We do not know, but now it is possible to check it 😉

The Race to the Tangle II. Teamwork

This post is a continuation of the race to the tangle in which we discuss how we try to increase the number of transactions we make to the tangle with the hardware we have.

For those who are not sure about what we are doing, we would like to remark that we are developing an IPS and storing locations in the IOTA. So we are not developing an IPS on the IOTA.

Why do we store locations in the tangle? Because our goal is to use the locations as evidence of facts, and we believe that having them stored and signed in the tangle is ideal for our purpose. You can review the last part of this post to see an example of what we do with the locations which are stored in the tangle (notice that the images of the web are gifs).

For us, the locations that we store in the tangle are like a snapshot of the current state of the installation. Obviously, the more locations we store, the more representative the snapshot will be. Therefore, the underlying issue to be addressed is to increase the number of locations stored in the tangle with the hardware we have. We do not talk about using cloud solutions or better hardware, but to optimize the performance of the hardware that we are using.

After these considerations, it is time to move on to the interesting part.

First of all, the code. Keep in mind that it is a code to carry out tests (not for production). Before using it, you should analyse it in order to understand how it works.

We have the following Low-Cost Single Board Computers (LCSBC):

• 1 x Up Squared.
• 1 x Raspberry Pi 2 Model B + Micro SD 32 Class 10.
• 3 x Raspberry Pi 3 Model B + Micro SD 8 Class 4.

We use Eclipse Kura in all the LCSBC so they can easily communicate with each other by MQTT. Using the MQTT connection we can create a cluster of LCSBCs (hereinafter nodes). Our approach is as follows:

• Each node uses the worker service.
• The service adds itself to the list of workers of the cluster, publishing a message in topic /mide/iota/workers/<worker-id>.
• The node which starts an execution uses the manager service. Speaking properly, the execution uses the service (there is no public manager service).
• The POW is not parallelized, but the transactions. Why? Because: i) it is a complex task, and ii) without a fast connection between nodes it does not make sense (this would even slow down the system).
• The manager assigns jobs to each worker by publishing them in the topic /mide/iota/todo/<worker-id>.
• The workers publish the results of the jobs in the topic /mide/iota/done/<work-id>.

Analysing our previous results we realised that the deviation in the average transaction time per LCSBC is high. Therefore, we follow two approaches:

• Collaborative: Each transaction is assigned to a free worker. It should be most efficient.
• Competitive: The workers compete with each other to be the fastest in each transaction (like blockchain mining). It should be more stable.

We have conducted two experiments in which we have sent 300 transactions to the following addresses:

• https://thetangle.org/address/99999999999999999999999999999999999999999999999999999999999999COMPETITIVEAPPROACH
• https://thetangle.org/address/999999999999999999999999999999999999999999999999999999999999COLLABORATIVEAPPROACH

Unfortunately, there is a bug in the IOTA library which provokes that sometimes an exception occurs in the POW. In our implementation, we discard these transactions, and therefore we do not consider them in the results. It is important to note that the error occurs during the POW, so the results would be better without this bug.

The bug also affects the execution in a different way depending on the configured mode. While in the competitive mode the nodes work until the end of the execution because these nodes are called for each particular work, in the collaborative mode this does not happen. Our solution to analyse the results has been keeping only the valid data of the competitive mode and all the data until the first bug in the collaborative mode. In the collaborative mode we have done several tests until we achieved a case in the bug appear late (after many transactions).

The results are:

Competitive

• Transactions: 232.
• Time: 4708 seconds.
• Time per transaction: 20.29 seconds.
• Transactions per hour: 177.4
• Variance: 237.51
• Standard deviation: 15.41
• Maximum transaction time: 86 seconds.

Collaborative

• Transactions: 203.
• Time: 3107 seconds.
• Time per transaction: 15.6 seconds.
• Transactions per hour: 230.75.
• Variance: 9984.75.
• Standard deviation: 99.92.
• Maximum transaction time: 679 seconds.

Here you can find the comparison with the previous ones:

Testing: One, two, three

This weekend we have met up in order to perform some experiments, and taking advantage of this meeting we are going to show you how to install Jura.

First of all, we want to highlight the purpose of our meeting. The main goal is to discuss a tool that we want to develop in order to improve the experience with Jura. If you are not interested in it you can skip it and go to the next section.

Our proposal focuses on indoor positioning using BLE beacons. If you do not know how this is done you can review a previous post or even better this Degree’s Thesis. Usually, each beacon is located at a given point and they are scanned by devices that are in motion. As we explain here, we use the opposite scheme in order to be able to trust the scannings.

A common problem in indoor positioning using beacons is the noise (interferences in the environment, collisions in waves, surfaces with different reflection indexes, …). You can review the previous Degree’s Thesis for more information about that.

At the beginning of the challenge, we carried out several tests until we achieved a maximum error of two meters when positioning. This is enough for us because it allows knowing the rough position of each beacon. In a nursing home we could know the room in which each resident is located. If it is a medium-size room, we could also know the area in which area the resident is located.

How can we say that we are positioning with an error smaller than two meters? Because we did the following:

1. We recorded datasets by placing a beacon at a given point. This evolved into Graba’s recording service.
2. The scannings of the datasets were sent to the positioning service. This evolved into Graba’s player service.
3. We computed the positioning error as the arithmetic means of the Euclidean distance between the real position and the one calculated by the service.

We think that it would be great to generalize this functionality because doing that anyone can test different scanners’ locations in order to fine-tune his/her installation and obtain better results. Today we have recorded some datasets using Graba. We will use them in order to test the tool that we want to develop.

Deployment of Kura

We have used the following hardware:

• 3 x Raspberry Pi 3 Model B.
• 1 x Raspberry Pi 2 Model B.
• 1 x Up Squared.
• 1 x Kindle fire.

The installation was configured as follows:

• Four scanners of iBeacons (the four Rasps using Faro).
• One Up Squared as a MQTT broker and Graba’s service.
• One Kindle fire as an iBeacon.

First of all, it was necessary to install Kura (‘Raspbian (Model 2 or 3, No Net)’ for UP Squared), but not the official version, a fork in which we solved an iBeacon’s bug in the Raspberry 2. Notice that once we certainly figure out that this is a failure of Kura or an incompatibility with our system we will carry out a pull-request.

By the way, we are pleased to tell you that we have already made a small contribution to Kura and that makes us extremely happy :).

After installing Kura we activated the MQTT broker in the Up Squared and later we connected all MQTT clients (Up Squared included) to the broker. This took a few minutes.

Deployment of Jura

First of all, we installed Faro in the four Raspberries, configuring them as iBeacon’s scanners.

From now on, Faro will publish any iBeacon that it detects, using MQTT.

As we explained in Faro’s post, in order to avoid the saturation of the MQTT broker, it sends messages periodically but including a chunk of all the detections obtained in the payload’s body. By doing this it is possible to get all transactions in return for a small delay, which is totally fine for our purpose.

At this point, the iBeacon’s scanners are ready. Let’s prepare Graba. In this case, we only install it in the Up Squared. As we indicated in Graba’s post, we have developed a React’s website in order to manage Graba’s services, so the creation of the iBeacon’s locations datasets is a very simple task.

Prior to showing an example of the process, it is necessary to indicate that the dataset only records the detections. Before creating the dataset it is necessary to manually measure the points where the scanners and the beacons are located. We know that it is a boring task, but there is no other option… Why do you think we are all together today? 🙂

On the positive side, creating a dataset using Graba’s web is as simple as this:

Deployment of Ubica

Although it is not necessary to use Ubica to create the datasets, we would like to show you how a Jura’s installation is defined using Ubica in order to give you a big picture of Jura.

As we said before, we have met in one of our homes, so be welcomed.

We made a plan of the room measuring tape in hand (for those worried about the details, it’s just for tests!) .

Next step, let’s install and configure Ubica in Up Squared.

Once we have installed it, we must define the installation. For this, it is necessary to indicate the points of the plan (in millimetres) and the locations of the scanners (also in millimetres). You can use ‘hcitool dev’ to get the bluetooth address of each device if you do not know it.

Where do we place the scanners? For our tests, there were located close to the power sockets. Ideally, they would be equally distributed around the room, close to the ceiling, away from possible sources of noise, …

This is our installation.

This is our plan (scanners’ locations are approximate).

And this is our configuration for Ubica’s installation service (scanners’ locations are accurate).

 {
  "id":"home",
  "points":[
   {"X":1200,"Y":0},
   {"X":8400,"Y":0},
   {"X":8400,"Y":3700},
   {"X":3600,"Y":3700},
   {"X":3600,"Y":5700},
   {"X":0,"Y":5700},
   {"X":0,"Y":1200},
   {"X":1200,"Y":0}
  ],
  "scanners":[
   {"addr":"B8:27:EB:C8:E8:ED","position":{"X":5700,"Y":400}},
   {"addr":"B8:27:EB:1F:82:3C","position":{"X":6400,"Y":2800}},
   {"addr":"B8:27:EB:23:CD:49","position":{"X":3500,"Y":3200}},
   {"addr":"5C:F3:70:66:23:97","position":{"X":1200,"Y":2000}}
  ]
 }

After that, the installation is ready (it’s simple, right?) and we finish this post. We will publish the results of the tests soon.

To conclude, we would like to tell you that, if you want to use Jura but this seems hard and unfriendly, you might be happy knowing the following. We have some experience developing Eclipse RCP and RAP applications and when the challenge began we started developing a RAP application to define plans, see positions, etc.

A picture is worth a thousand words.

Unfortunately, we have had to prioritise other parts, so we do not know if we will finish it someday or not. Who knows? Maybe for the Open IoT Challenge 5.0 😉

Firma: In IOTA We Trust

We are pleased to present Firma, the last part of Jura. “Firmar” is the Spanish word of the verb “to sign” and the translation of firma in English is “it signs“. In order to understand how Firma works, first of all, it is necessary to understand how all the parts of Jura (Faro, Graba, Ubica and of course Firma) fit together.

Jura’s architecture

Jura is not a monolithic tool, it is a Kura’s components based tool:

• Jura: “It swears”; a set of Kura’s components to deploy trusted indoor positioning systems.
  • Faro: “Lighthouse”; a multimodal beacon.
  • Graba: “It records”; a recording system.
  • Ubica: “It locates”; an indoor positioning system.
  • Firma: “It signs”; a signer, encrypter and validator of locations.

What does the above mean? It means that in each particular device it is only deployed what is necessary. For example, in our tests, we use four Raspberry Pi with Faro and one Up Squared with Ubica and Firma. In the Up Squared, we activate the MQTT broker that Kura provides, Artemis. The Rasps use the MQTT client provided by Kura, Paho, which is used to send Faro’s detections to Ubica (properly speaking, Faro does not send anything to Ubica. It publishes in a MQTT topic to which Ubica is subscribed. Indeed, it is almost such as the whiteboard pattern). And where is Graba? Nowhere. It is used to analyze and improve the system, but it is not used in production.

Firma

Let’s go step by step. Firma is a feature composed by four Kura’s plug-ins:

• iot.challenge.jura.firma: Firma’s core.
• iot.challenge.jura.firma.web: Website for Firma with several tools.
• iot.challenge.jura.pgp: Adaptation of The Legion of the Bouncy Castle libraries for Kura.
• iot.challenge.jura.jota: Adaptation of the Jota library for Kura.

Note that we say adapted. The libraries are not only downloaded using Maven Tycho, but also their dependencies are established, their packages are exposed, their source code are patched (in the case of Jota) and they are compiled and added to Firma when the Kura’s deployment package is built.

The core of Firma

First of all, we would like to leave a message for novices and experts. These are our first advances in this area, so please, do not assume as a fact anything before investigating on your own.

As we indicated in our last post, making transactions to the tangle is computationally expensive, so unless you have a supercomputer at home it is not a good idea to use IOTA as a backend to deploy an IPS.

If you are looking for an IPS which offers the locations remotely and safely, why not considering what Benjamin Cabé proposes here? Moreover, you might design it, making the computational resources destined to each device to be positioned, proportional to the payment in IOTAs made to the address assigned to it. The more money you pay, the more accurate the location of this device will be.

The main question is, what do you want to do? Depending on that, you will need to use the data in one way or another. It is also crucial to understand that if we use an IOTA’s transaction to send data, we do it using the part of the transaction’s message used to prove the sender’s identity. Clearly speaking, anyone could generate the transaction, and it is obvious that in order to trust the messages we must trust the sender.

Thinking about everything discussed so far, it is possible to propose many ways to use the tangle to store information:

• To prove the sender’s identity:
  • Signing the message.
  • Signing transactions’ addresses.
  • Encrypting the message (signed or not).
• To know the locations of each device:
  • Specifying the device in the location.
  • Associating an address to each device.
  • Including all possible locations in each message (by the device or not).
• To protect anonymity:
  • Encrypting the message.
  • Using MAM.

For our proof of concept we have developed two systems:

• Public system: The locations are signed using the public key of the installation. Each location is sent to a specific IOTA address.
• Anonymous system: Each location is signed with the public key of the installation and encrypted with a unique AES key. Each location is sent to a different address.

Public system

Do you want to publicly expose the locations, and anonymity is not a problem? Great! Use this. It obtains the locations generated by Ubica and tries to send to the IOTA as many locations as possible.

As we indicated here, we focus on positioning in nursing homes. So, what is the use of this system in our proposal? Publicly expose staff locations. Our main goal is to provide a tool which provides an unequivocal answer to questions such as, is a resident treated by the staff? Who is taking care of a given resident at a given time? Did the staff act diligently when an emergency occurred? Obviously, it is necessary to carry out an in-depth research work in order to give an objective answer to the previous questions, but we hope that our PoC will help to advance in this line of work.

Considering the bottleneck that the POW supposes, the system implements a selection algorithm to select the most appropriate location to send (is it a new device? Has not been sent information about it for a long time? …). In addition, the system can be configured as a Kura’s service, which makes it possible to fine-tune its behavior when the locations are selected.

In general terms, it can be said that the system tries to send representative locations.

Selected the locations, the next step consists of signing them. To do this, Firma provides a service to sign any message using PGP keys.

The service can use an existing key or create its own. In this second case, it will publish it on a Public Key Server so that anyone can validate the signatures (this is cool, isn’t it? 🙂 ).

For example, this is one of the keys that we have created in our tests.

Using the private key the location is signed to generate a message like the following:

{
  "body":{
    "timestamp":1518773478473,
    "location":{
      "app":"jura",
      "installation":"installation",
      "device":"BE:AC:01:00:00:00",
      "point":{"X":8721,"Y":6405}
    }
  },
  "sign":{
    "hash":"SHA1",
    "value":"iLoEAQECACQFAlqGpQIdHEp1cmE6Ok9wZW4gSW9UIENoYWxsZW5nZSA0LjAACgkQ\ntjU5WSUA18xfCAP8D7qQ4m7Zyl8hSsrWF/E0tZd61oowCWoyQ+NDbuhwCBFZkpC9\n7FLgxAyC2bS52xiR9TMDpKx8AKRq6g4/W0LCUah1BvocSC/6/HGNyW8L2mGXDOgp\nUCqEAxyeO+nZ/bcbUC3LwDsi80Q5lEf2TQCUDPsm4vRuawMF6xEmTFEkmis=\n=kQyC\n-",
    "key":"b63539592500d7cc"
  }
}

Anyone can check that sign.value is a valid signature for body using the key 0xb63539592500d7cc that we have published in the PKS.

You may ask yourselves, how can I verify it? You will see it later ;). Now the important question is, what is done with the signed message? The signed message is sent to the IOTA public address using the IOTA Transfer Service provided by Firma (Important: NEVER show your seed).

The system uses one of the addresses derived from the seed as IOTA public address so the public address will not be known until a location is transmitted.

After each transaction, an entry, similar to the following, will be added to kura.log:

2018-02-16 10:34:15,334 [pool-68-thread-1] INFO i.c.j.f.s.p.t.TransferServiceProvider - Transaction https://thetangle.org/transaction/SVZDF9IEQCIZBBLNRX9PZKBOUQZGCPJBQINOVMNLSLWNW9FGGLGCATURHUNDLDADMUEGBZNLQJBCA9999 completed (148 seconds)

Following the transaction link, it is possible to verify that it is an IOTA transaction with the signed message.

If you click on the IOTA’s address you will get the list with all the messages signed by Firma and sent to this address.

Maybe you are wondering, why so many pending transactions? In IOTA you decide how much POW to do, the more you do, the faster your transaction will be validated. At the beginning of our tests, we did not think that it would be necessary to increase the value in the short term… If you want to use Firma, you can modify ‘weight’ in the code to do more POW (or you can add a ‘weight’ parameter to the service).

Anonymous system

Do you want to store information anonymously? Being able to show it to a third party, and all of the above without risking the anonymity of the rest of your information? If so, perhaps you might be more interested in this part.

We have designed this system keeping in mind the families and the relatives of the nursing home residents. We believe that for ethical reasons (and possibly also for legal reasons) the location of nursing home’s residents should not be publicly exposed. To protect the privacy of a message that can be consulted by anyone, the only solution we conceived is the encryption of it.

A simple solution could be:

• A unique PGP key is generated for each resident’s device.
• The key is provided securely to relatives.
• The locations of this device are encrypted with the PGP public key.
• Only relatives can decrypt the location’s messages.

This approach is valid, but for us, it is not enough. It is due to a simple reason, how can a family member use a transaction as an evidence of a fact?

1. Showing his/her private key.
2. Downloading the message of the transaction and decrypting it.

We believe that the second option is much better than the first one. Currently, the second option is completely secure as long as private keys are not compromised. But when we say that it is not enough for us, we are not saying it from a security perspective, but from the user’s experience. We think that the user’s experience improves by doing the following:

• A unique Device Identification Word (DIW) is generated for each resident’s device.
• The DIW is provided securely to relatives.
• For each message, a unique IOTA address and encryption key are generated deterministically. Since each key is unique, it is not necessary to use asymmetric cryptography. Instead, we use AES.
• Using the DIW, relatives can generate the same addresses and encryption keys, being able to decrypt the location’s messages.

We believe that this approach improves the user experience without compromising security. Relatives can do the same as before (download and decrypt), but now they can directly use the IOTA transaction as evidence of a fact, with the benefits that this entails.

For the rest, the system works in the same way as the public system does, and its configuration is similar too.

But, are you able to find the relationship between these two transactions?

• https://thetangle.org/transaction/FILPVVALEAQWFPSAPBRBAQHEKLLEPS9YOQZQAALVFGAVWNMRIKLWYGABDIRCKFIH9NVHMWKYFDNC99999
• https://thetangle.org/transaction/IHEUQUNZRVRSNQTIWWQUZWWZFOPAXADMGPDLLAAYPGL9ZZDPANHAHZUQPTYSQDZIYFOQBIAAZPDWA9999

Firma web

This is the most beautiful part :).

Starting from Graba’s website, we have developed a website that allows us to test all the previous functionality.

We must clarify that the web is not designed to be used for an end user. However, it would be very easy to adapt it for that purpose. It is also not adapted for a Nursing Home, BUT doing that is only a matter of changing the terms used (Publicly -> Staff, Device -> Resident, and so on).

Functionality

It has four sections, Publicly, Admin, Device and Anonymously.

Publicly

Are you using the public system? Then you can validate the signature of a transaction in this section.

Admin

Are you using the anonymous system? Then you need to know the DIW of the device. Using the password set in the web’s configuration service you can calculate the DIW of any device using this section.

Device

Do you have the DIW of a device and do you want to know its anonymous locations? You can do it in this sections.

Anonymously

Do you have the data of an anonymous transaction and do you want to validate it? You can do it here.

The Race to the Tangle

These days we are using the starter kit that we got for our proposal for the Eclipse Open IoT Challenge 4.0 to carry out different tests. With the kit we got three Raspberry Pi 3 and one Up Squared* Grove* IoT Development Kit. All this costs about 400$, a great reward.

In our proposal, we use IOTA to store information, being the search for the nonce for the proof of work in each IOTA’s transaction the most computationally expensive part. You can send everything you want to the Tangle without spending IOTAs, but unless you have free electricity, the transaction will not be free. However, what worries us is not the marginal cost of electric power, but the ratio of transactions we can achieve using low-cost single board computers.

We have decided to carry out some experiments and we share the results with you. We have proceeded as follows.

We have the following hardware:

• Raspberry Pi 2 Model B.
• Raspberry Pi 3 Model B.
• UP Squared.
• 1 Micro SD Class 10 32GB.
• 1 Micro SD Class 10 16GB.
• 1 Micro SD Class 4 8GB.

Using this hardware we have prepared four configurations:

1. UP Squared.
2. Raspberry Pi 3 Model B + Micro SD Class 10 16 GB.
3. Raspberry Pi 3 Model B + Micro SD Class 4 8GB.
4. Raspberry Pi 2 Model B + Micro SD Class 10 32 GB.

For all configurations we have installed the latest version of Kura (‘Raspbian (Model 2 or 3, No Net)’ for UP Squared).

Using Jura code we have developed a Kura’s package to test the efficiency of a device making transactions to the IOTA’s tangle. You can download the code here. If you want to try it, we warn you that (in our case) the latest version of Kura’s web does not show the service’s configuration menu the first time we deploy it. The solution is simple, install, uninstall and reinstall…

We have sent in each experiment 50 transactions to the following addresses:

1. https://thetangle.org/address/999999999999999999999999999999999999999999999999999999999999999999999999UPSQUARED
2. https://thetangle.org/address/99999999999999999999999999999999999999999999999999999999999999999999PITHREEGOODSD
3. https://thetangle.org/address/99999999999999999999999999999999999999999999999999999999999999999999999999PITHREE
4. https://thetangle.org/address/9999999999999999999999999999999999999999999999999999999999999999999999999999PITWO

And the results are:

1. UP Squared: 31.17 seconds each transaction (115.51 per hour)
2. Pi 3 Model B + SD Class 10: 103.25 seconds each transaction (34.87 per hour)
3. Pi 2 Model B + SD Class 10: 154.4 seconds each transaction (23.32 per hour)
4. Pi 3 Model B + SD Class 4: 196.52 seconds each transaction (18.32 per hour)

Obviously, the result after 50 transactions using a Kura’s package should never be used as a measure of the efficiency of the device, but it allows us to intuit the approximate performance of each one.

Our Approach. Part II. Trusted IPS

We have been waiting to post this for weeks. It is not because we are playing hard to get, we just wanted to see how far we could go 🙂

Let’s contextualize. When we conceive our proposal we made the following reasoning:

1. In several situations, the reading of a sensor can be enough evidence to prove something. Thinking about location examples, the above could be useful if:
   • A person wants to prove that he/she was in a certain place at a given time.
   • A delivery person must bring a package to an address.
   • A worker who must be in an area for a period of time.
   • …
2. If someone wants to use a reading as evidence of a fact, he/she should be the one detected. The reason is very simple, false readings can be generated:
   • A child who plays truant from school.
   • A delivery person who sets a fake GPS location.
   • A worker who wants to pretend that he/she works more than he/she actually did.
3. For the same reason, detections should not be used as accusatory evidence:
   • A person can simulate that another person was in a restricted area.
   • A person can simulate that another person was in a place to deny that he/she could be elsewhere.
   • A person could use a stolen device to commit any felony.
   • A person could use a modified device to impersonate another person.
4. In addition, the absence of detections should not be used as accusatory evidence either, since the readings could be deliberately omitted.
   • A person does not want to register the delivery person who goes to his/her home.
   • A company does not register an action of its clients to cancel any of their rights.
5. To be able to use a reading as an evidence to a thrid party, it should be recorded in a way that ensures that:
   • The authentication of the sender of the message can be checked.
   • The message is registered when it occurs.
   • The message can not be modified.
   • The message can not be repudiated.

Before explaining our approach we would like to make a small point. Our starting point was: let’s use IoT as evidence to prove facts. We believe that extreme generalizations are extremely bad, and we are convinced that the reader can come up with several solutions to the above problems. We did not want to propose anything that seemed like a good idea but in practice would not work at all. Why our proposal is a Trusted IPS for Nursing Homes? Because we believe it is useful and we can deal with the above problems in this area.

Our proposal

We believe that the best scenarios to deploy a proposal are those in which the following requirements are maximized:

1. The detected one obtains benefits:
   • Direct: He/she can prove a fact.
   • Indirect: The processing of data provides some benefits (emergency attention, customized care, …).
2. The detector obtains benefits:
   • Direct: Location of workers, logistics optimization, sale of data, …
   • Indirect: Transparency policies, analytics, …
3. The detected one should not be interested in cheating the system.
4. The detector should not be interested in cheating the system.

How do these requirements fit with a nursing home?

Detected benefits

Residents and their relatives can obtain great benefits:

• Guarantee of adequate attention.
• Help in emergency situations.
• Behavioral study for the early detection of diseases (degree of mobility, level of physical exercise, sociability, dementia, Alzheimer, …).

Detector benefits

The owners and staff of the nursing home can also obtain great benefits:

• If one of your loved ones must be admitted to a nursing home and you must choose one. How would you rate one that offers you a guarantee of the care of its residents and that gives you mechanism to enforce your rights?
• Location of residents.
• Location of staff.
• Processes automation.

Interest in cheating by the detected

This requirement is the most complex to maximize because necessity is the mother of invention, and we know that some people may try to cheat the system to obtain other benefits (better care, financial compensation, etc).

However, we must understand that the value of the data is proportional to the security policies implemented. The reading of an isolated detection sensor should not have the same value as that of a set of them following a sequence, plus a NFC reading, plus … . To clarify, we do not encourage to use 20 different types of sensors, we encourage to establish the necessary mechanisms to avoid fraudulent use of the system.

We know that our proposal suffers from not addressing this point with the necessary depth. This is due to two reasons: i) only the analysis of the necessary security policies could take months and ii) without analyzing the day-to-day in a nursing home we are not qualified to do so. For our proposal we ‘only’ use BLE Beacons for the reasons mentioned here.

On the other hand, we would like to highlight that we think it would be relatively easy to convince residents to carry a beacon with them because many of them already carry a device of similar size to call emergency services (or why not, improve the current devices).

Interest in cheating by the detector

Here the question to be asked should be: What is better for the nursing home? That it can modify the data or that it can guarantee that it can not modify the data? For us there is no doubt that the second is much more beneficial both from the ethical and from the economic point of view. And how can they give this guarantee? We can think of two ways to do it:

1. Using an intermediary. An outside company hired by the nursing home (could be you 🙂 ) would be responsible for recording the readings and ensure they are real.
2. Storing the data in a blockchain.

Trusted IoT

This part has given us more headaches than any other since the technology used is more complex and abstract. When the challenge began, our knowledge of the blockchain was basic. After a few months experimenting with this technology we feel that we still know very little, but at least we have unlearned some misconceptions.  Our vision of the blockchain is that:

1. Forget the money! The most outstanding feature of the blockchain is that it allows us to decentralize trust. Obviously this is ideal for monetary operations so we believe that the association Blockchain=Money will prevail for a long time.
2. Integrity and non-repudiation is guaranteed by design.
3. IoT and blockchain combine perfectly.
4. There is a lot of misinformation. Many people still underestimate the blockchain and many others overestimate what can be done in its current phase.
5. The smart contracts will be the trigger for the use of the blockchain in all areas, but we believe that not in the current conception of the smart contracts.

When you start to study the blockchain, the first thing you should do is not to think about it as a whole, since there are multiple proposals that experiment with multiple concepts. There are public, private and hybrid blockchains, with support for smart contract or not, for general use or for niches, based on mining, preminated, … .

In our case, after analyzing several blockchains we decided to use IOTA since it allows us to i) store data, ii) with no fees iii) quickly. We are not going to talk much about the IOTA since the only thing we would do would be to paraphrase its website. But we would like to encourage you to investigate about it since for us, it is the blockchain with better future prospects.

We only use IOTA to store locations, in which we will delve into our next post. To understand how we do it, we must understand that:

1. We talk about IOTA as blockchain, but IOTA is blockless and it is based on tangle.
2. A transaction validates two previous transactions. Thanks to this, the miners have no place. Neither the fees. It is possible to make transactions with zero value.
3. If a transaction has no value, it is not necessary to prove that we own the private key corresponding to the address that generates the transaction.
4. If it is not necessary to prove that you own the private key, you can use the field for the signature of the message to store any other data, in our case messages with the location that we have previously signed with PGP and, if necessary, encrypted with AES.

The way in which we use the IOTA to store locations allows us to guarantee that:

1. The locations are stored in a distributed ledger and it is not possible to block their access.
2. A message can not be repudiated.
3. It is not possible to modify or remove registered locations.
4. It is not possible to add past information that can be trusted. The timestamp of the location and the timestamp of the IOTA’s transaction will determine if the message should be trusted or not.

As we have anticipated, in the next post we will present the last feature of Jura and we will explain exactly how we do the above.

We would like to finish this post highlighting that in our proposal we only use a minimum part of what IOTA offers. Once we have the data in the tangle, i) why not sell them?, ii) why not offer a better service on demand?, iii) why not use them to build an oracle for a smart contract?, iv) thinking about IOTA snapshots, why not deploy a permanode that allows access to the data under a freemium model?