 Welcome to our first talk in the afternoon slot. This is Zivian. He's a researcher at the University of Rostock, and he'll be talking about IT security in network buildings, what's left to rescue when building the basic concepts of security, and he'll be speaking about the weaknesses of building automation and the standard KNX. Hi, great to see that you all made it here. I would like to give a talk about IT security in network building to give some attention to the topic. I'll try to ensure that it's friendly to beginners. You shouldn't need a lot of advanced knowledge. I hope that those who know things about network buildings will be able to find interesting things in this talk. We're going to have a look at how network buildings were based on the KNX field bus. Then I'll be speaking about the security issues of these concepts, and I won't stop there. I will also speak about what we can do if the situation is the way it is, and if there's time I will also speak about tools that could be interesting for people who are interested in researching this further. How do network buildings work? I'll be using the example of the KNX field bus because that's the infrastructure we're using in our research institute. What is a field bus anyway? It's a bus that's designed to connect sensors and actors via a variety of media. That could be a copper wire, it could be an internet or power line or ethernet, and even if you look closely, you can see a wireless connection and we could have a light switch or a switch for the blinds and use it to trigger various actors. If there are several participants speaking on the same bus, then we have the challenge that we have to decide and control who can speak to whom at which point in time, and that's what we need a protocol. The combination of this is what makes a field bus system. Why do we do that? It's got several advantages. The first is an increase in comfort if you have a large public building, for example a university building. You can press one switch in the evening and all the lights would turn off so the electricity isn't on all night. You have more flexibility in rearranging rooms so that you can use a switch for different things. It's easier to reconfigure because you have a network. It can also help reduce running costs, of course just running costs, because the upfront costs for insulation will be higher, but it allows to reduce costs for energy management and it also decreases the amount of material you need. It doesn't matter for a building so much, but for instance in a car, you can save a lot by saving a few kilos of wire. The downsides are that the whole thing is getting more complex and more expensive to install. There's a lack of security. There's a higher potential for attacks. Why do I speak about KNX? It's not one small thing we have in our back room. It's the successor to the European installation bus. It's an open standard specified in 2002. It was normed and standardized both in Europe and internationally, and it's a vendor-independent consortium. And if somebody builds a device, they can get a KNX certificate and that will allow them to connect several KNX devices in a network. You need software for this, or you need to configure this, and that's what the engineering tool software is used for. Let's have a look at how KNX works. There is a physical address space that's divided into three parts. There's the area, which is for bits. These can be, for example, separate floors of a building or perhaps even separate buildings. Then there are separate lines. These two might be used for one floor of a building. That is for bits as well. And then there are several devices. There are devices with an 8-bit address, and the number of the bit length determines how many devices and lines and areas you can have. And we have these devices that are connected through the connection medium. They are coupled by these LK couplers and these again are coupled in an area. There's this address, but there's also the logical address space. There are two ways of using this. There's a two-step or three-step address space, and for each project you have to decide up front which you want to use, and you have either two or three groups that are separated by a slash. Now we can assign several devices to a group. For example, the one that's highlighted in orange here, that might be a light switch. It's in a group with a lot of other devices. Let's say all of them are lamps. So if this light switch wants to toggle all of these lamps, it will send a program to the communication medium that will be forwarded by all the couplers to ensure that all the devices in this group receive the telegram, not program, sorry. It won't get much more technical than this. The package structure of this KNX, there are some steering flags, there's a source address or some control flags, and there are source and destination addresses. They may either be physical or logical. And to determine which one is, there's a separate bit for that. Then there's routing information. Six hops will get you anywhere in the network. So if this is set to seven, then the packets will be discarded. Then a length specified how much data is in the payload and a parity bit. Now we look at the security problems that turn up. We're talking about IT security, Schutzziele, I'm talking about different goals, different requirements, protection goals. For example, confidentiality, confidentiality is the property of a message that it's only intended for a limited circle of recipients. That's a definition from Wikipedia. For example, lights on is the message. The message is intended for the lamp. If somebody unrelated listens on the bus and that other device shouldn't be able to read what's in the telegram, what's in the message. The protection goal, authenticity, is, well, the property of a lamp with an originality and accountability and trust. If somebody uses a different light switch or adds a light switch, it shouldn't work. The lamp shouldn't accept messages from a rogue light switch. If we add accessories for our Kainix system like a fingerprint sensor, when I add my fingerprint to get into the garage, only I should get into the garage. We have now talked about the different notions in security. We have no encryption so that we have no confidentiality. We have no authorization. These are fundamental problems that everyone can talk and read on that bus. Now it would be nice to have some kind of gateway that you can do remote management and attach to the network. Networking increases not just inside of buildings. You want a network, multiple buildings and all this increases the attack surface and the reach of breaches. For example, there are automated search machines, search engines that can automatically hunt for vulnerabilities in such networks. The security people that are good enough are going to get in. One example would be Shodan. When a building stands there and everything works, no one gets the idea to patch these buildings, their systems, for security enhancements. Concerning the gateways, if we add a gateway, the gateway has been secured. There was a talk from Thomas Roth at 34C3. He showed that these gateways are wide open. What kinds of attacks are possible on KNX? Let's use the extension execute. You can listen to any messages on that bus. The field bus was installed. My boss had the idea to look at the light switch and locked the messages running on that bus and the installing service company, the service provider tried to roll it off to liability. The administration forbade access to the bus. If we measure the voltage on the bus, we get zeroes and ones and can see what's going on on the bus. You can run the service attacks by doing anything on the bus, random stuff. You can cut it, which is not very interesting. If I'm able to control air conditioning of large buildings, I can do a lot of damage. My boss, for example, instructed the beamer to flip the image. The most interesting part of the project was showing that these data are personal. On the left-hand side you can see our institute's building. In the middle there's a movement sensor that you want to make sense. You want to ensure that there's always lights on in the corridor if you need them. But, of course, they can also be used to track people. If we carry on the idea of Daniel Kreisler at 33C3 mining Spiegel, we can think about what kind of information we can get from this data. If we're creative, we have a floor plan of the building. It's an office building. These are individual employees' offices. These are auditoriums and the thing on the top left, that's the bathrooms, and the things in red are the movement sensors. Our toilets have a small room where the taps are. And through the washroom, every time somebody has visited the bathroom, they have to go through the room where the taps are and the sinks are. And if they spent less than three seconds in that room, they likely didn't wash their hands. And if we then see which sensors they've passed on the way in the corridor, we can suddenly tell whose hands we no longer want to shake. Of course, this experiment wasn't very popular. And, of course, your employer may not be interested in who didn't wash their hands, but it's still possible to gather this data and we have to deal with that. And this, I hope, leads me to the most interesting part of the talk. The situation is the way it is. We have these buildings, we go in and out, and we can't really do anything about it. Of course, we can decide not to go to the lectures, but in case it's my employer we're talking about, then it's already more difficult to not show up. And, of course, this technology exists in all kinds of public buildings. So what can we do about the situation? How can we react? A colleague of mine said, right, let's start by quantifying the risk by raising awareness of what is a problem and what might not be a problem. I mean, if I can trigger the light switches in the office next door, of course, that's fun for two days, but it gets boring after that. And we thought we'd classify these attack vectors and check how much knowledge is necessary for them. Do you need special knowledge? Do you need simply basic knowledge, or do you need no knowledge at all, like cutting a wire and suddenly the building is no longer able to be used? And the less knowledge you acquire, the more likely an attack is. And we can also look at where an attack can happen, can it happen inside the building, can it only happen in the vicinity of the building, or can it maybe happen anywhere in the world? Then we should look at the potential damage. Is it perhaps negligible, or is it a personal damage? Maybe even, is it financial damage? And how visible is the attack finally? If somebody is only reading, for example, in a power station and your competition can read along on the bus system, that might be very valuable to them, but you may not immediately notice. And if you have buses where people communicate normally, it might get lost in normal traffic, but if you're doing a lot with new or unusual addresses, you might notice the attack. And that's simply to quantify the kinds of attacks that are possible and the potential for damage in order to make this more tangible instead of simply saying everything is terrible and you can be attacked at any time. The next thing my colleague did was to try and quantify it, to sum it up in a number. And he said, let's look at static and dynamic factors. If you have a device and install it, you can say device X that I'm adding to the network now, what kind of device is it? Is it a simple voltage supply that can't even speak on the bus? Because that's another thing that KNX can do. It sends voltage to devices, and for each line there may be a power source, and that might be less relevant than devices that can talk on their own. Next, how physically accessible is the device? Is it a light switch in the bathroom of a public building? Then anybody is able to access it? Or is it a device that's in a locked area of the building, for example a server room where only a very few people have access? Then you can look at how physically accessible the bus medium is. Let's say we have an access control system that's linked to the bus system, then we definitely don't want to have the bus running along the exterior wall because that would make it a lot easier to access for attackers. And then we can look at how far we can reach, how many other devices can we reach in this space. And that depends a bit on the way the network is built and whether or not it has filters. All this can be considered during installation. And if you bear this in mind during installation, you can create a heat map or an installation help that says if you add the device at this place in the network, you will increase risk by this or that amount. And this would take work of the shoulders of the people installing devices in this network because they may not be able to think about these things at all times. Dynamic factors could be the number of telegrams that are running on the network at any point in time and then what kind of telegrams those are. And this brings us neatly to the next idea. The bus itself has the basic concept of as few cables as possible and as many devices as possible. That's great. We have a few cables. We don't need to spend a lot of money. But the attack surface has increased a lot. If we don't have any filtering, then we can access anything from anywhere and talk to any devices and do silly things. In an automotive situation, we might quickly realize that it's a bad idea to connect the ABS and the entertainment system without any protection mechanisms so we could create separate zones for them. One of them that contains the light system and another that connects the air conditioning. And now we can no longer use a light switch to trigger to make sure that no windows can be opened anymore because we've sucked all the air out of the auditorium. Of course that means we need more cables but it also means more security. If we have to be considerate in what we're doing, we can't do this blindly. One thing is filtering and package inspection. So we can use these couplers and check who is speaking to whom and is that plausible? Is it a plausible context? Do we want to allow this message or should we discard it? And in the top right here you see the basic package structure of a KNX telegram. And we can prevent implausible forwardings but it doesn't prevent spoofing because we can use any source address that looks plausible and suddenly we've manipulated the context. And this only works across broadcasts. So when in doubt we have to decrease the broadcast domains. And of course we can, instead of saying we discard everything that's implausible we can use a whitelist and say we'll only accept that which is plausible and things we don't know we simply ignore. Because we have to do a kind of project definition in this KNX because we know who's going to be part of this network. We know who is able to speak to whom. We were supposed to be able to speak to whom. We know what a message looks like and we know logical places in the network and then any filter mechanisms could swallow anything that's not on our whitelist. It's got the same advantages and drawbacks as earlier. We're protecting against implausible forwardings but it doesn't protect against spoofing and it only works across broadcasts and only in certain frameworks because if your average sender sends an average message to an average recipient then it doesn't mean that we've narrowed down the message format successfully. If we continuously switch the heating off and on then these might be normal telegrams that can still destroy the device. Another thing is NetFlow analysis and looking at the traffic happening in various areas of the networks how many telegrams in how much time with how much of a gap between them and now we add an agent to each broadcast area. These tend to be called sensors but I don't use that term because it means something different in the context of field buses. So these agents ask what you can see in these blue and green areas and you can always these always hear all the telegrams running over the bus and then they can use the bus medium itself to send a statistic aggregation to a controller and it has an overview of the network and can decide for example if it notices that a lot of unusual packages are running over the bus in a certain area you could maybe attach it to a warning system and say if there's too much traffic we trigger an alarm. This scales really really well. We only need one collector and one agent per domain. We can use the existing communication infrastructure so it's in-band. We can install it live and it works robustly whenever a device might go out of service as long as it's not an agent but even if an agent fails then the rest of the network can continue and it allows us to use very little technical hardware while still surveilling a large part of the network. We're still not protected from people listening in and we have the problem that a denial of service attack that causes a lot of traffic. We're increasing the problem because we too are causing traffic on the network. On the other hand somebody else might already have access to the bus and might already be reasing along and they would probably be interested in the security analysis information. This might be critical, we'd have to consider that. And in building automation we have the problem that we need to distinguish rare occasions or rare messages and attacks. For example, if nobody ever turns on the lights in the broom closet but we, because we spilled some coffee, need to access some cleaning supplies then that might trigger a false alarm and if we have too many false alarms then people will no longer trust the alarms. If we use machine learning to distinguish between what's normal and abnormal we must take into account the fact that usage of buildings can change. But if we do this we open the door for some more complex attacks that gradually modify what counts as normal for a building and another idea that we've been taking up, a colleague wants to look at what happens if we look at the voltage on these wires and see that if, notice that there's always been a certain length of the wire and if this length suddenly changes and the voltage might change a bit too you can see in this graph there's a zero and a one on the buzz and if that suddenly changes then that might be suspicious. We hope this protects against adding things to the network in between devices. We hope we might even be able to fingerprint devices in the same way that it's often done in RF devices. We're probably very vulnerable to electromagnetic interference and it's probably a very difficult solution that's very difficult to install and that has to be adapted anytime something changes in the building and something is reconfigured The part of this is why we're using these systems in the first place because we want to have an ease of configurability. We have all these nice ideas. We need test data. Who can provide us with test data from puzzles that have been attacked? And there's also the problem that this data is sensitive. For example, as a private person you also want to protect your reputation and you're not keen on giving out this data usually. If I give data to someone I don't know exactly what they are going to do with the data. Still, even if we don't have real test data, we need test data. So we tried ourselves to generate some test data. So please, we have these test data. We have made these public. And if you want to, you can contribute. How did we do that? We logged all data in our building at a time where we were still allowed to do that. We got, we asked everyone concerned and had them allow us to do that. Any data that points to attacks, we're going to look at that. The possible messages we classify them and we sort them by time. We have this original telegram stream, this message stream. We manipulate it, remove some messages. We add messages, modify them and remove some others. In an office building you have a weekly rhythm. At Saturday and Sunday there are different patterns. In the morning, in the evening, at night, the patterns are different. You can see on the bus whether the weather is warm or cold. Messages that are usually, that are always coming at the same time. All the messages that are triggered by the users of the building. You can see all kinds of stuff on this bus. In the artificial test, you have to consider these properties, these patterns. What are you going to find behind this QR code? How long the packet is going to be transmitted before it's dropped? We added timing attacks, we moved messages. We added some replay attacks, I mean, we duplicated messages. A colleague switches on the light and right after that I send another message. That switches the light back on, back off. That's a denial of service attack. And the colleague is not going to have any idea why the light switch doesn't work. That's not going to mean that those who built field buses didn't do a good thing. It's quite difficult to retrofit security in a bus system like that. There are a lot of problems. Why is it difficult to retrofit security? We have an increase in complexity in systems of this type. We have somewhat well-documented wiring cabinets, but sometimes people become ill. A guy who wrote the documentation became ill. No one has a 100% complete documentation. All these devices even had key material. You would have to distribute the key material. You would have to manage the keys. You have to make them more powerful devices so that they are more capable of stronger encryption. We have the issue of personal data, of data that can be associated to persons. We have the issue that you don't know exactly what kind of message patterns are normal. The patterns that are normal change. Attacks could also try to replicate this gradual change of patterns. Not everyone is an IT expert. In my opinion, IT security should be part of the request for proposal. The service providers sell systems like that. The proposals need to ask for baked-in security. These buses have been designed and all the buildings were built. The security technologies didn't exist in part. In other areas like power stations, hospitals, manufacturing plants, ports, ships, cars. We need to get people on board to have a look at the security issues. This may be a bit small, the font, so you can't read it exactly. There is KNX virtual, where you can configure your own virtual devices. The devices on the top right are lamps and dimmers. You can then configure these with engineering tool software ETS. You can use that software to watch messages on the bus. You can look at the logical and physical addresses. The next tool is net node, which allows you to configure analysis and let it run. All these tools I have linked here on this slide. Not all the gateways are able to process all messages. If you want to take everything with you, it may not work. For example, the wine seal gateway. You have also done experience with NetFlow. Thank you to all my colleagues, Thomas Mundt, Johan Scholls, Johan Bauer, Andreas Soljas, Martin Peters and other colleagues at the Lehrstuhl for information and communication services of the University of Rostock. What did we talk about? How do network buildings work? We had a look at the security issues. We have talked a bit about ways to solve these problems. In our building, we still have many of these issues that we talked about. We have no identity checking. We still have personally associated data. We talked a bit about statistical analysis. I have a question whether it's possible to see if someone is listening and about the test approach. I'm coming to an end. I don't know if we have time for questions. Thank you. Thank you, Simeon. If you have questions, please go to the microphones. There seem to be no questions. My address is there on the slides. If you want to contact me, please do so. I'm going to be on the conference until tonight. One question. Why do you think that we didn't see the air gap? Have you considered, did you test Phillips U? We looked at some other buses. Next is what I've looked at personally the most. If you're interested, let's exchange contact data. I'll show you some people who can tell you more about that system. How does KNX secure work? How did they weigh the advantages and disadvantages? You need new devices. Not just the couplers. You really have to exchange the light switches. You have to exchange the lamps, replace the lamps and switches. If you can convince someone that in a building where everything works, lights can be switched on and off, that it's a good idea to actually replace everything. Next question comes up. How good is that crypto? How long is it going to last? The biggest problem is what's the availability. You have to look at what are others doing. When we showed people that there are problems, people became angry with the owners that there are problems and that we have to take care of these problems. The question is, can you actually buy solutions? We are still in the situation where we are right now. Thank you. Please give him a big round of applause for keeping us in a good shape.