 Tänään olen fokusinut IoT-sekkuretiin johon smart-citys- ja case-studioon, maailman biotopeilta, jossa olen käynyt aikaan vielä. Joten, presentaation vaikuttaa, johon biotopeilta, ja use-kase on kehitettyä, johon vaikuttaa, biotopeilta, ja Touch unexpectedly and presenting in what way we are dealing with IoT security, also based on the standards that we're developing with the open group, and finally conclusions. Ok, so the Biotope project and煌i stands for building and IoT open innovation ecosystem for connected smart objects. So there will be a few slides to explain että näin yhdistelmät on parempi. Tämä biotoprojekt on yksi asia, jota olen sanoit, että Euroopan IOTEPI on Euroopan Unions Horizon 2020-programma. Se on vihoja 9,5 miljoonaa. Sitten jälkeen 2016, ja vihoja 2019. Joten biotoprojekt on, en tiedä, miten menevät, EU-projektin ja miten se yksinkertainen. Mutta olen tullut paljon näitä projektia, ja mitä olen aina aioita, on, että no matter how good the results and the systems were, that you developed at the end of the project, the company just disappeared and plugged out all the systems, and it didn't leave much as sustainable afterwards. In biotoprojekt, what we, well it was actually my decision, that this time we will not see this happening. So what we started off doing was to collect real requirements of citizens, cities and so on, so that we would build use cases and systems that really address real problems and challenges. And then of course, well people who know me know that I'm pretty geeky guy, so I like the second part of building this secure, open and standardised systems or systems platforms for IOT. But then especially deployed these systems, systems in real cities for real users. And then ensure that these systems will also operate afterwards once the biotopends. The consortium looks like this. So yesterday you heard a presentation by Florian Maya from BMW, which I found very interesting, obviously, lucky enough. And in the consortium, as Florian was saying, we have three European cities, Helsinki, Brussels and Lyon, but we do also have St. Petersburg as one of the pilot cities, as well as Melbourne in Australia. So this slide was also shown by Florian yesterday. So these are not actually the final use cases that we, or the list of all the use cases that we developed in biotop. We, after this initial sort of requirements around with the cities, we understood that well the initial ideas that we had there were not always the best ones. So we replaced some of these use cases with other ones. But the big point here to notices that just about all these use cases do involve and require information coming from many different information systems. So you need to combine loads of data coming from different systems, representing different domains, using different vocabularies. And then there was a blackout. Oh yeah, and it's not just about data. It's also that we speak a lot about open data, but actually we are focusing more in biotop and in our standards on enabling sort of open APIs so that you don't necessarily have to move the open all the data. You can just open the services that then provide you with what you need without having to reveal confidential information. Okay, then I have been using this slide since the beginning of the project more or less, but I think it's still quite useful to show because it does illustrate some of the challenges that we have with the systems that we want to implement. So what Florian was speaking about yesterday from BMW was very much about this, that you have some car arriving into, this happens to be a DBMWI8. We are using I3s, but okay, it could be any car arriving to any city in the world. This happens to be Helsinki here, but the point is that no matter what car arrives to what city in the future, you should be able to do this kind of things. So the car would agree to provide some information to systems in the city that it trusts for some reason. So if I just drove into a pothole or if I just noticed that it's a slippery, which modern cars will notice because they have these ESP systems. ESP, did I say traction control systems? So if this happens and then they could and should transmit this kind of information to the city infrastructure so that the city infrastructure could then provide back information such as this so that if nine cars already went into this pothole, then there's no point in you being the tenth car driving into the same pothole. So then you should normally, or you should receive a notification in advance saying that well 100 meters ahead you will have a pothole. So then either you could react to this or your car, autonomous car could react to it somehow and avoid it. And what we have implemented was this finding parking places in different cities. Now of course when we are speaking about this kind of scenarios and use cases, there's a lot about security involved. So you would need to know or be sure that okay, the car that arrives, is it a real car? So if it's sending information saying that you have a pothole in this place, do you really have a pothole there or not? Because otherwise you could, well somebody who wants to attack the city infrastructure could send in, I know, 100 virtual cars that would claim that there is a pothole in this place of 10 meters of death and actually stop the whole city circulation in the city. Okay, so this is what we would like to achieve. Then the way in which the world looks for the moment, we have this challenge of closed systems or vertical silos in cities. So what you tend to have in practice is that you have a set of different parking operators who have their own back end systems and then if you want to use them, you need to install their app on your phone. Same thing at least in Finland for electrical vehicle charging operators. If you want to charge at the pole of a certain charging pole operator, then well you need to download their app and at least connect to their website and then deal with it over there. So in order to achieve our vision, well of course we would need all these systems to be somehow interoperable and that means that they should all use a common set of open standards. Now I think this picture here it's, well, the reason why I'm using this time glass here in this picture is that I sometimes have the impression that standardization organizations want to create new vertical silos with their stack of standards. That is not what we want to do here with the open group. What we want to do just as you said for OPAS actually, it's that we want to identify the gaps where you don't have existing standards but if you do have existing standards there's no point in reinventing them. So we try to reuse standards from no matter what standardization organizations. So in all our systems that we have developed we have used actually all of these different protocols and standards on the low level because the best protocol to use there actually depends on the available hardware and on what you actually want to do with the data. So how rapidly do you need to get access to it and so on? Oh, I have to watch out not to fall down there speaking about security. Okay, and then here on the upper level you actually have loads and loads of different vocabularies for different domains specified by well-known organizations such as the UN, GS1 and so on and so on. So all these vocabularies they actually provide data models for different kinds of data, standardized data models for different kinds of data and how you access them. But what we would like to, or we would like to have sort of a quite a limited set of standards, it's really on this here at the waist so the standards that we are using of course in all the systems that you will be seeing we are using HTTP, HTTPS web so gets a secure web so gets XMLJs and so on. But the smaller block, building blocks that we are adding here from the open group it's these standards here. So we have OMI, the open messaging interface which provides you with a lightweight way of subscribing to different kinds of events such as well do I have a pothole in front of me or similar things. ODF that provides you with a standardized structure for representing information about different things, services and so on. And then we have ODF which is an open data framework which is a way of expressing semantics that are using existing standards of all kinds. Okay, so then to the actual use cases. So the use cases are all using some subset of these standards while they are all using OMI and ODF and then a subset of the other standards depending on what you want to do. Now I won't spend too much time on this slide, it actually comes from Florian from BMW so this was about the smart mobility use case where we want to have smart houses discussing with the smart cars and smart cars discussing with the parking place operators as well as charging operators and all this needs to be done in a secure way. So what we have done here is that we have this set of existing services in Helsinki or in other towns or cities but in this case Helsinki where we have done this mapping of their existing APIs and systems using this in this case vocabulary called mobivok that is based on schema.org. So this is a standardized, well actually a semi-stannadized way of describing parking places, electrical, vehicle, charging poles and so on. And then we publish all these using ODF, the open data format which gives us a hierarchical structure that looks like this, you'll see more of it later on and that means that all these different information sources can be published, represented and accessed in the same way no matter what is the kind of services that they are actually providing you. So I'll give it to this slide because then at least we have some information there. Now I was expecting Florian to show this video yesterday but he wasn't sure if it's already officially, well, usable or not. So you might be wondering okay, how is this related to IoT security? Well actually if you think about what we have done here, so everything that you saw here actually all interoperability between the different systems is done using OMI and ODF plus these semantic standards that we were mentioning here. So that's one part of it, you have to have all these systems actually understanding each other in a well tested, documented, verified way. So what we were doing this week in Helsinki was actually to test that all the different systems, so I think there's five or six of them at least made by different companies actually interoperate successfully. So that means that from an internet of things security point of view, the building that speaks with Robert's car, they have to know and be sure who they are speaking with. And also since the house actually shares the information about when and if Robert is leaving his home, you don't want anybody else or some external people to actually be able to access that kind of information. It's not good neither if somebody would get access to your BMW and start telling it to heat or cool down or whatever it would be. It's a plus 50 when you get into the car, that would be pretty embarrassing. And same thing for parking place operators, you do want to be sure that all the information that you are accessing and showing and using is indeed provided by the right company, organization. Okay, so this time I'm really focusing on these requirements based on these use cases. Okay, European Union. So then one other use case, Florian, he was actually showing some of these yesterday also, but not quite the same ones. The main use case that we are doing in Brussels, it's improving the safety around schools. So in order to do this, we have an app that has been developed for the school children. So they are using this on their phones and they have actually allowed us to follow where they are. So the location information, which is something pretty sensitive, we are actually getting the same information also from the operators in Brussels. And they have this possibility of clicking and saying if they feel safe or unsafe when they come to a crossroad, for instance, or traffic light. So if you have loads of traffic or something else, then they can indicate through this that this is, if it's a good place or a bad place to use at this time of the day. So then once we get this kind of events, we combine that with information that we access from Waze. Okay, and this was actually the location information coming from the operator. So from Waze, from which we get information about the traffic flows at that place. And some other information too, we can analyze then what are the reasons why certain places in the city are felt or perceived as being safe or not. But again, here we have the same case, especially for this location information of the children, we do not want the other children to be able to follow where, well, one child to follow where the other one is going and this kind of things. So we do have this information collected into a central place somewhere, but then what we really need to be careful about is that we make sure that only the right systems get access to that and that different systems only get read or write or the appropriate level of access to that data. Okay, I think that's all that I have to say about this one. Another use case that is implemented in Brussels actually, so I don't think you will be able to use it quite yet if you go to Brussels, it's still in pilot use. So they have these water buses that you can take in Brussels to go to different places and what they are publishing there, it's the location of these water buses in real time using ODIF. They do also update the schedules not only to the OMI, but they do also update this schedule information to the Google Maps, in the Google Maps format so that this information gets published or accessible there. So the point here is that we are not limiting ourselves neither to only OMI and ODIF if we have, as I was saying, since there are some GTFS, I think that's the Google format for publishing time or schedules since it's a useful system so why not use it even though it's provided by Google. But the point here is that, okay, we don't again want anybody to start pushing any fake data about the position of the water bus or something similar. Now in classical systems this kind of information would come, so to say, from the downward part, but here in biotope since we have many different organizations developing these systems or providing information also over the internet, that actually gives us some pretty, well, new and tougher requirements on security. Okay, then one more example. In Leon we have this heat wave mitigation system which is, well, heat wave mitigation. So what they are doing is that if it's really hot in Leon, they know that you can cool down certain places quite efficiently if you provide more water to the trees there. So they have equipped some trees in their parks with sensors that indicate how much water you actually have in the trees so you can measure that. And then based on the outside temperature on how much water you have in the trees already and other things and they decide if they give more water to the trees or not in order to cool down the climate there. And okay, all these data it's again annotated and published using over my and over the F and some other and some semantic standards. So I guess I can go on from this slide to the next one. So this is what it looks like for instance for this use case when you are publishing this kind of information in ODF format. So actually for all these use cases you can still access somewhere what we call the OMI nodes and see what the data looks like. So this is not very human readable but the main purpose here is that it should be machine readable. So what you see here it's reference implementation that we have developed for OMI and ODF. And you can see here that okay you have for instance an actuator for irrigation here and you have a procedure called start or stop by which you can start it or stop it. You also have these coordinates where it is located and this whole structure is presumably and hopefully based on some existing standard or recommendation for this kind of system. For this Leon case I'm not completely sure but what is interesting to notice here also is that they have combined several different semantic standards. So for instance for this moisture measurement that you have here they have specified the type of that element as a source has a simple result but to be honest I don't know what this source is here. I don't think it's the same as the open group one. Not sure. But the point here is that okay you do in principle anybody could access this method of starting or stopping the irrigation which you obviously do not want everyone to be able to do. Okay. There's a lot of enterprise architects here so you of course know that it's very much a question of how do you actually configure the systems where do you install them where do you with firewalls and so on. But when you start creating this kind of open systems you don't necessarily have quite as much liberty of choice as you used to have in the past. In this system that they have installed in Leon they actually have quite a lot of different actors and networks interacting. So for instance these air temperature sensors and irrigation valve control are using Laura for getting the measurements and doing the control but they also do have a SIG focus infrastructure and servers for the tree activity sensor and soil moisture sensor and then they have water tank actuators and other things which are using some other protocols. Now again the point here is that these are provided by different organizations and using of course different protocols which happen to be appropriate there but still all this information is published and accessible through My and ODF somewhere. So again point here you really need to be sure who gets access to what information and especially when you do some actuation. We are developing quite a few other use cases also but I think this illustrates the level of challenge that we have for implementing these systems but even more the challenge that we get for making them safe. So then to the more general topic of IoT security I wonder how much time did I use but then again we had some. Okay so I was very happy when Bob was showing more details about this example here. One question that came into my mind in both of the presentations this morning is that well actually the safest way to not getting hacked is that you don't connect anything to the web. Actually this is quite a generic and interesting question because most of the systems connected to the Internet or things currently they were not meant for being connected anywhere. So the old car from 1976 that you showed it didn't have any of this security issues and the Jeep Cherokee shouldn't have or wouldn't have had initially neither unless they connected it to the Internet and made it accessible even over there. So okay there are many challenges. Firewall configuration is not easy to get right and it's quite rare that you would see any cryptographical identities for your things on the Internet of Things because most of them were made before all these things were interesting. So okay how do you deal with these security specifics of IoT? So actually most security basics or security mechanisms can be applied more or less as such but then the big challenge is once you start going for these secure connections, crypt identities and so on it's how do you actually distribute these identities to your different systems? And what we haven't come up with the best solution for yet is actually should you identify these devices as well using unique identifiers for different sensors and so on or would you like to use some kind of synchronization specific identity but then depending on what identity you are using it also means that you can only come down to a certain level of trust. So the more fine-grained identity you are using for your things the more challenging it becomes to manage all those identities but then you also have more flexibility. One practical thing for those who have been playing around with these systems is how do you update these certificates before they expire, that's a nightmare because then you would need to do that update over there or something like this and then you mentioned also these software updates and that some system, the card identity will verify the checksum of the update. We would never do anything like that in control things or the open group. Okay, so you can find some baseline security recommendations for IoT there are more and more people working on this topic. If you go and check this link I think there was a 12 or 15 pages or whatever of things that we of course conform with but I was quite surprised but in a way happy because I didn't find anything about role-based access control different parts of the information there. So I was unhappy about not seeing it there for one reason but at least then we still have something to tackle. So okay, authorization access control and so on, it's really about when you have different actors using a system in different roles you would normally want to give different access rights to these different users. So coming, well backing off the smart city aspect I'm quite often using this example of our home so I of course need to have access as the administrator to all systems in our home so that I can do any update and control anything and so on but I would not like to share the same level of access to my wife and children and so on because they would mess up the whole thing presumably and actually as you know for most systems for most of the users you would like to have just a user role even for your own home so that you don't go under or I don't go and mess up with anything. So this is very much the same thing as we have for any computer system going back to UNIX and even Windows and so on. Okay, so how do you develop this kind of fine-grade access control and in this case based on the standards by the open group? Well to begin with rapidly what are the internal things standards of the open group? So okay, first we have this open messaging interface and open data format that were developed by the Internet of Things a workgroup we started off in 2010 so I would say that we were among the first ones tackling this kind of things based on earlier EU products that we have had and then there's the open data element framework which was published in May 2016. So a quick look at what you already saw some a little bit of what these look like So the Internet of Things with OMI, ODF and ODF standards now I started working with the Internet of Things in 2001 we made our first implementation in 2002 and at that time nobody spoke about cloud and not to even mention fog and edge so what we went off doing was to develop systems that are sort of pair to pair enabled Now what that means in practice also for these standards is that we are not just sending data to the cloud or something like this you can actually have machines and devices things communicating directly with each other over different clouds and so on as well as taking the control down to what is nowadays called the edge So there was a discussion yesterday with Open Process Automation Forum on the fact that you need to have different kinds of software depending on what device you are installing it in Well, I very much agreed with what was said there but it's really about how you interoperate between these different devices So if that's dealt with properly then you can have different implementations for different use cases to conform with different requirements So that's really the philosophy that we have been using So OMI, ODF and ODF relationships are simplified this is very much simplified and I think I'm using up a little bit too much time so I'll jump rapidly use the examples of these in just a moment So the Open Data format is a generic format that is representing sort of anything in the Internet of Things Same structure used for publishing, discovering, querying and retrieving information and it's also extensible and most of all it's open for using external standards for defining what is the meaning of these different objects and info items as we call them in ODF So this is what a simple ODF structure would look like Yeah, it's only ODF, we don't have any OMI here Okay, so this is a structure that we're using for instance for air handling units in my home that's the usual demo that I'm showing So ODF allows you to have these object hierarchies which has certain advantages when you start sending this data you don't have to repeat the same data all over and this type field that we have here So what you see here is an example Oh, there was one going quite the right way Oh, they are there Okay, interesting So in this example we are using ODF for specifying what kind of machine this is and what kind of measurement we have here So this code here actually says that this or using the sort of plug-in standard by United Nations, UNS-PSC version 18 and this says that this is an air handling unit using this language agnostic code which is pretty useful also in the Bioto project when we have these cars moving around in the world and going to any kinds of cities It's not always that you would like to have a vocabulary that are using only English and these are already existing and established well-used standards Then what we also have is a code saying that okay, this is a measurement fresh air that's in degrees Celsius Now, this is one degree of security also that as I was saying for the Helsinki use case what we were doing during that week was to make sure that all the different organizations and the software understood each other in the right way Now, if you don't have this kind of information well, everyone knows about here I guess some example of where you got some catastrophic results from mixing up between degrees Celsius and far and height or centimeters and inches So that's the first level Then this fine-grained access controller for those at least to have some well, everyone has some background from file systems so you know how you specify access rules in Unix systems and similar Well, once you have this kind of hierarchical structure as in ODF, you can of course apply similar rules as on the Unix system so that you specify exactly which users will have what kind of access to what pieces of information so what objects and all the information under it or what information or even actuator So this is something that we have been working on quite heavily also during this year and it's used in all these use cases in Biotop now Okay, then to the conclusions So I think we have all said more or less the same thing that IoT security has implications on safety even on the safety of citizens So it's really something that we have to deal with properly Well, standards are essential to the success of smart cities Okay, smart cities, you don't want I think it was also mentioned in some presentations here earlier at this conference Well, for smart cities, most of them many of them tend to be one of installations by one single system provider and that's not interesting for the citizens and the cities because they rapidly end up in a lock-in situation and it wouldn't help us for this case of the BMW arriving to Helsinki-Leon and so on you have to have some kind of standardised standardised and open APIs So then to the bold claim we are developing standards for the IoT that the open group has, I think, became clear for everyone but these are also standards where security and safety are built in from the beginning, so to say So, okay, that was the point of the previous slide So these access rules and how you specify that Of course we are using, well, certificates username passwords were appropriate, ACTPS and SSL and all this stuff when needed Okay, I think that was all from me and also with the support of Ron Schulte for the ODF part Okay, thank you