 Okay, hello everyone. I'm Devin. I've been a peer-to-peer insecurity researcher for the past five to six years. And I've also done a lot of DevOps and sysadmin work as my day job. So, this talk is about IoT. This nice amazing name that everybody agrees on and likes, the Internet of Things, which describes a series of devices that are networked. Oftentimes they're sensors, but really it's turning into the Internet of Things kind of encompasses anything that somebody can plug in to the network. So, what I see IoT actually as today are these devices that people are putting in their houses. So, my father, for instance, has replaced almost all the light bulbs in his house with light bulbs that are LEDs. And they have ESP microcontrollers on them that connect to his WLAN. And they expose an API which he can talk to to control his lights, change the colors, this type of thing. Though, even though they're connected to the local network, it's typically the way that you access and control these devices is through a crowd-based access, so a third-party authentication system. And this also allows for nice features like being able to control and access your devices from outside the house, which I can't think of too many use cases for controlling your light bulbs when you're not at the house. But things like cameras or maybe remotely unlocking your front door to let somebody in the house. That could be a useful thing. And what IoT, I think, has become, even with all of these interesting features, is kind of an inefficient system, which obviously is designed in a way that makes data surveillance very palpable and useful for the third parties which are controlling these systems, basically being gateways for these devices which are in our house. So this is, I say it as a data sovereignty problem, but it also has further social implications, which I'm going to get into a bit. First of all, it's a user experience problem in the sense that if you want to access a device that's right next to you and you have to go through a third-party app on your phone, which goes to servers probably in California or who knows where, if there's anything in the route towards these servers or a problem with the servers themselves, then you're not going to be able to turn on and off your lights or unlock your front door or something like this, which is kind of a terrible usability experience compared to non-IoT devices. We also have kind of the more obvious one, lock-in. You end up in these scenarios where you have multiple devices that span multiple generations and they're incompatible with each other and the applications in which to access them are completely incompatible due to vendor lock-in and as well as completely different protocols that they're running. Yeah, there have been some interesting cases where you spend several hundred or several thousands of dollars putting automation in your home and then the company goes under or they completely change their system for whatever reason and you have to either buy new stuff or, best case scenario, at least upgrade all of your software before you can use it again. So that's another terrible user experience, especially for the non-technically-minded. And yeah, so the social implications are the, I think all the stuff that I was just mentioning is kind of obvious. You know, data surveillance, surveillance capitalism driving this, these aren't good things. I think most people here probably agree with that. They're also pretty obvious and that's probably why a lot of people here opt not to have a Google Assistant device in their house, that type of thing. But I think almost, to me, a more serious problem are these subtle ethical implications on the social dynamics, which is that most people aren't even aware that they're not talking directly to these devices in their house or to the extent in which they're controlled from third parties. And I think that creates an environment where you have an unwanted guest in your house and you don't even know they're there. And then another aspect to that is people, because of the way that we design these systems to be cloud-based, it doesn't allow for a very humanistic and social collaboration between people. Like if my father, for instance, with all the lights in his house when I go to visit him, I can obviously use the switch to turn off and on the lights, but if I want to dim or change the color of anything, I can't do it. There's no way to add authentication to another person. It's not thinking about the social aspects. So it's not, I think anytime we're designing systems that people are using heavily, especially for people who are not technical users first, we need to think about how we're affecting them socially and then how their social dynamics are going to affect the system designed back. So I'm working on this project to alleviate some of these concerns and I think we can use peer-to-peer systems to do that. I think it's the best way of moving forward instead of... I really appreciate these projects like OpenHAB and some other ones where you're running a server inside of your house that controls all of these devices and I think these are a great interim solution. But I think moving towards peer-to-peer, key-based, authenticated systems is the way to go forward. So Martin did a good job if anybody was in here for the previous talk about GNUNET explaining that. I'm not going to go into it in nearly as much detail as he did. I decided to use this system because I highlighted general purpose because the privacy preserving and peer-to-peer networking, that's kind of implicit. There's a lot of systems that do this but what I like about GNUNET is that it's very general purpose and it's modular and you can pick and choose pieces. There's something that Martin didn't have. He had kind of an OSI model on the left and then where GNUNET matches in but this was created by Carl Leven-Links from the SecuShare and Ubrook the Internet project and this is a little bit of a different modeling. It's coming from more of a perspective of not exact one-to-one how we replace the OSI model but looking at more of a paradigm shift on how we can think about designing applications in a different way. You'll see that GNUNET, CADET and R5-IN are both options to replace BGP and you have some things that go up the stack. They're low level on the GNUNET side but they actually end up matching up the stack on the traditional model. What's useful particularly for our project is that GNUNET provides a low level framework for authentication it has cryptographic primitives built into the routing and core networking layers so if you're building an application on top you can kind of take that stuff for granted so it becomes easier. You don't have to think about doing key exchanges yourself. You kind of can, built into your routing if you can route to another device then you can be sure that that device is the one that you're trying to access based off of the public key. Some of the aspects about GNUNET that I think are important for this project are its portability because obviously with IoT we're going to be targeting embedded devices or even microcontrollers. For this project we're using OpenWRT and the work of Daniel Gollay, an OpenWRT maintainer he ported GNUNET to OpenWRT and you can run it even on commodity routers. It's a C code base, it's very portable, it's modular so you don't have to run everything. You don't have to run the more CPU intensive peer-to-peer protocols and nobody's ported it to a microcontroller yet but it seems like it could be possible for something like the ESP32. Also with the researchers on GNUNET they focused on scalability and just as an aside I think abstraction level is an important thing to look at when you're talking about peer-to-peer systems. Some of the most popular peer-to-peer systems right now are web based, like Secure Scuttlebyte, DAT, IPFS, these things that probably a lot of people have heard of. I think these are great projects, I have friends in all three of those projects and more but they kind of start on a much higher abstraction level in my opinion, partially in the language choice on a lot of these but then also in what they're targeting and I think for IoT we have to keep the abstraction level low. So then Income Secure Share which Martin also mentioned in the previous talk. That's been a research group for some years in scalable social interaction models. SecureShare.org you can look into that more. There's been a little bit of implementation but it's mostly been a lot of research and documentation. It actually started out as a meta-project and then eventually about five years ago it kind of decided to focus on building this on top of or modeling on top of GNUNET. So it's kind of a general social interaction model based around the concepts of a social graph, a distributed PubSub system and multicast distribution. And there's not really any implementation of this. Like I said, it's mostly a research project at this point at least. And yeah, core point is no central authority in that design. So with SecureShare box, that's the name of the IoT project. As a sub-project of SecureShare taking some of these research models and trying to apply it to IoT, we kind of ended up with two components. One is the IoT device side which runs GNUNET and a daemon which listens to messaging through a PubSub system. So it can create PubSub channels which you can subscribe to and then it sends messages which could be sensor data or control messages, this type of thing, and vice versa. And then the second component is a command line, right now it's a command line interface for the people interacting with it, but it's, sorry, interacting with these IoT devices. And the properties that are important that we found are making it offline first, so which sounds kind of strange for IoT, but the idea that you can interact with your database of known devices and your latest information about these devices, even if you're offline, you could even send control messages like, I want to turn on this light at 6 p.m., but I'm offline right now. And then when you get online, it syncs via a PubSub distribution system. And so the CLI, it's called Boxon, kind of looks like this. It's a work in progress right now and some of the stuff's being refactored, so not all of these commands work as of right now if you were to clone the get. But the concept here is that everything you're seeing is effectively local and kept into a database modeled with social graphing. So you're thinking about your relationships to the devices and the services on the devices. So you see here at the top, you're listing your devices that you know about and these might not all be your devices. These could be devices of other people. And then you list your services on a specific device which is called Toaster. And then you see here web server and then in the parentheses it's web.toaster. So I'm going to get into this a little bit further on the next slides, but the concept is to have pet names that are hyper-local to you, which then are aliases for GNS names. So the GNU name system, which is a part of GNUNET, which is a key-based distributed naming system. So we can have human-readable names without DNS that are directly correlated with the public keys of devices. So you have kind of like a X509 authentication built into that system as well. And then a big component of it is at the bottom is this idea of giving access control to other people because that's one thing that I really saw missing, not from all IoT implementations, but I think it really should be a core aspect. And this CLI ends up just being kind of a wrapper to the existing GNUNET modules in the sense that your friend Alice is represented by a cryptographic key, which we call an ego in GNUNET, rather. And you're saying I'm going to allow access via this public key to this device, which is also represented by a public key. And what happens there is you push out a message containing Alice's public key to the Kitchen Lightbulb device. And since you're already authenticated with it, it accepts that as saying, okay, this is a public key, I'm going to now allow access to this service control panel. And then when Alice tries to connect, it kind of works automatically. So here's a little bit of a graph to go a bit further into it. It looks pretty complicated because it kind of is, but if you start down here in the left corner with user ID 2, they're friends with user ID 0. And all these are, all entities on here, the lighter gray color are represented by keys. The darker grayish beige color is the relationship between the entities. So user 2 is friends with user 0 and vice versa, user 0 is friends with user 2. They, if you look over in the kind of the middle top left, you have a device called toaster represented by a public key ego. And the relationship between user 0 and the device is that they have access to the administration and they are the owner. And because of this, they can provide authorization to other entities. And there are some entities that know about devices, but they don't have authorization, this type of thing. So it ends up kind of being like a distributed key value store. GNS uses a distributed hash table. And so we're really just bootstrapping on top of all that stuff. And what's interesting is what I found after designing some of this and implementing it, is that really none of this is super particular to IoT. It's definitely useful for that and you have to think about some of the resource implications. But this is also a really good sysadmin tool. And that's what I've been using it for a lot. So I have like a list of my servers that I connect to for like web servers, different things. And I've added them as devices and they have different services. And then I can connect to them and send operations to them. And then you don't even need things like SSH necessarily. Yeah, so some core components are that it keeps the state local with meaning of your information about devices, services, who owns what, who your friends are, what authorization they have. That all remains local and it pushes it out opportunistically to the devices that need to know. So it's a need to know basis system. And some future advancements on that would be syncing between your devices. So let's say you have a laptop and a phone. Right now there's no concept of syncing the state between them, but that would be something I'd like to implement. And as a key base system, I think I've already covered that. That's about it. You can look more into it on the website that QR code goes to the top URL. And yeah, so there we have it. Do you allow for multiple ownership of devices? Some things are inherently shared. Yes. One to one. Because there's a risk with things like this that you end up doing the things you said at the beginning. You end up coding new social norms into this world. So are you thinking about those at all? Yes. Yes, there are scenarios where there is dual ownership. And I think that that's a reasonable thing to model socially. And yeah, so I am thinking about implications like this. And one, for example, maybe this kind of answers it. Like one thing that I'm specifically avoiding is a trustless system. Because I know that some projects, peer-to-peer projects, are trying to create systems that are completely trustless. And I don't think that that models very well. And I don't think that's how humans interact. So you can have a, with this scenario, you could have a device that's owned by two people and one person kicks the other person off, even if it's in their own home. Of course, you could then unplug the device or something like this. But I think that becomes a social matter and we don't need to solve that in the technology. Hi. Where? Up. Thanks for the presentation. When using GNU NETs on IoT devices like sensors and such, which are quite low-powered, have you looked into the implications for performance and whether those little devices can run GNU NET? Yes. So like I said, I would love to see GNU NET ported to, at least see if we could port it to a microcontroller. OpenWRT is where we've done the most testing. There are some components that you can run with GNU NET, like network size estimation, which is useful for having very random routes to avoid censorship and stuff like this. But they're very resource-intensive. So we disable those things in the images that we have produced, like the OpenWRT images that we have produced. And what we've seen is that just running GNU NET for link layer encryption and the GNS system with DHT, that's reasonable for systems the size of commodity routers, it seems. We haven't done extensive testing. And then definitely things like Raspberry Pi, is there anything in that area? It seems like it's totally fine. It's not super resource-intensive. Yeah. Hi, thanks for your talk. I can't hear you. Hello. Ah, okay. Hey, thanks for your talk. Just to clarify, the public subscribe that you talked about, that is part of Secure Share. Sorry, it's still too hard. Can you just speak up a little? Okay. The public subscribe that you mentioned, that is part of Secure Share, not a GNU NET subsystem part. Are you asking if it's a part of GNU NET already? Okay. Yeah, the public subscribe system is not a part of GNU NET and it's not even fully implemented in our system yet. So, yeah, I don't know if I was totally clear about that. Everything that I talked about is not fully implemented yet. Basically just the base stuff. And we don't have a public subscribe messaging mechanism. I'm working with a group called P2P CoLab. You can see them at P2P CoLab.net. I forgot to put the URL up here. TG is actually giving a talk about that I think next. And he's implemented, and some other researchers have implemented a distributed privacy preserving PubSub implementation called Poldercast, which I'm hoping to plug into this, yeah. Any further questions? Then thank you for your talk. Thank you. Thanks, everyone.