 Okay, we're off. Good morning, everyone. My name is Bercht Uthier. I'm going to talk to you about accessing your embed device using PageKite. So, a little bit about me. I'm Bercht Uthier, as I mentioned. I'm an embedded software engineer currently working at Mind, which is a division of Essensium. We are located in Leuven. And we're doing mainly embedded and open source projects. You can contact us using our email address like that. And of course, our clients are always working with some kind of embedded products and an embedded system. In this example, it was a client who was in the home automation sector. And a typical situation that you find there is that you have some kind of home automation bus with all devices connected to it, whether it's Philips Hue or KNX or whatever. There's always some proprietary bus system with some devices connected to it. But then if you want to control it with your mobile application, for example, you need some sort of gateway device which translates the IP network on one side towards your proprietary bus. So this is what you get when you're on a local network. But usually your gateway is connected to your home router or firewall and then connected to the internet. So the main problem most of the time is how do we access our gateway from outside of our home network, so over the internet. And for that, of course, we need some sort of tunneling. There are different solutions for that. Most of you think about SSH or VPN maybe. But usually it's not possible to implement a VPN client or an SSH client on an embed device which is a low-level microcontroller. So you can do as Leon and use MQTT maybe. But that requires us to change the protocol that you're using to talk to the gateway. So the protocol that you use to talk to the gateway on your local network might be different than when you connect to it over the internet. You can use PubNup which is also requiring you to change your protocol. And it's also quite expensive. I don't think it's open source as well. And one of the main requirements from our client was that it should be open source, scalable. And of course doesn't require us to change the protocol so that it's transparent for the mobile app whether he's on the local network or on the internet to talk to the device. And of course it should be no problem to get through most of the firewall settings of routers, the typical routers in your home. So that's why we chose to use PageKite. So what does PageKite do? It has a library that we created on your Ambit device running on the gateway. So in our specific use case at our client the gateway was an Ambit device. So we needed to create a backend library for PageKite for Ambit. And of course Ambit also needs a front-end server running somewhere on the public internet. And it's a PageKite backend library that will connect to the front-end and create a tunnel. And then your mobile app will talk to the PageKite front-end server transparently like it would talk to the gateway immediately on your local network. So how does it work, PageKite? You have your backend, you have your front-end. The reference link is there so if you want to read more about it you start off with setting up a normal TCP TLS connection. If you want a encryption of course you need TLS. Then you send a connect message towards the front-end which consists of a similar way as HTTP connect. So you have some sort of fields that you need to fill in. So you have PageKite saying okay we need a raw protocol. The port indicates the public port where your clients will connect to on the front-end. And then you have the kite name which is usually the DNS of the front-end server and then a random string. The front-end answers with a sign this message which consists of mainly the same things that you send to it plus a token. So also a random number and a session ID. And then you send back a sign message which is of course includes a signature which is based on the random number that you got from the server, from the front-end server in a hash of course together with a shared secret. So the front-end and the embed device have a shared secret. You create a hash and that's your signature. Then of course the front-end replies whether your signature was okay or not. So with a normal okay or invalid. And after that your connection is set up so the handshake is done. When a client connects to your front-end, then the communication that is sent to the front-end is sent over the tunnel in chunks. So how does a chunk look like? A chunk is actually just a length indicator and some data. And what's in the data? The data indicates okay for which session ID is this data, from which host is it coming towards which service on your gateway. So you have your remote IP and your remote port from where is the communication coming and towards where port do you want it to be sent. And then of course the data itself. So this is how you can know on your back-end side where does the communication need to go, where does the data need to go. So what options do we have to implement pagekites on an embed device? We looked at lib pagekite which is provided by the pagekite community, which is a C library. But it was not really usable on an embed device because it depends on things like open SSL, libEV, normal sockets, which is all not present in embed. So we needed to implement our own library with all the back-end functions that we needed. So what is embed really? Embed is a platform and operating system for IoT devices based on the Cortex-M microcontroller. So it's owned by ARM. It's open source. It includes core OS, some security libraries like embed TLS, and also networking and communication technologies. I think you have different TCP IP stacks that you can choose from or you can even provide your own. And it has a developer community of course. I like to see it as an Arduino on steroids. So what did we use to develop this library? We used the development platform, which is located here. And of course the gateway of our client was also based on this microcontroller, the NXP LPC1768, which is a Cortex-M3 32-bit microcontroller. It's 96 megahertz and only 32 kilobytes of RAM. So the memory is actually quite a constraint. The 32 kilobytes RAM, actually it's 64 kilobytes of RAM, but 32 is reserved for functions for the TCP IP stack, things like USB functionality and con functionality. So you cannot use a full RAM that is available. But you can tweak it so you can tweak the linker a little bit so you can use some parts of the 32 kilobytes that is reserved for other functions. Up until now it's not necessary for us to do that, but probably we will need to do it in order to implement embed TLS. There's also no random number generator on the microcontroller, so we need to do other tricks like using the analog inputs as a random source. There are discussions about that if that's a really true random number, but for now it's enough. You can use external hardware as well to create a true random number. Another challenge that we had is that the PageKite protocol documentation wasn't really as thorough as we would like. I needed to do some wire sharking in order to really understand how the protocol was working, but probably they're working on that. So what are the limitations up until now that we have with our library? So it's still in its early stages. We have no encryption yet. We're working on that. There's also no compression. You can use compression with PageKite. We didn't need to because the protocol that we need to communicate with the gateway actually consists of only very short messages, so compression was really an overkill for us. But it can be a challenge to implement compression on an embed device. And currently it's also limited to only one connection at a time, so there's only one app that can connect over the internet towards your gateway at the same time. We need to implement some sort of parallelism for that to allow multiple connections at the same time. So what's the API? How did we design it? We tried to make it as similar as possible towards setting up a TCP socket connection in an embed. So maybe let's look at some code. Yeah, here it is. So what do we need? We need some variables, of course. PageKite name is the... Here I used an IP address, but usually it's the DNS name of your front-end server. Then the port towards which the clients will connect on your front-end server, so the public port on the internet, and then your shared secret. Then what do you do? You create a PageKite backend object with those parameters. You set up your TCP-IP connection, and then you do a PageKite connect. So you do a connect first. After that, you do a PageKite accept on that connection. And when a client connects towards your front-end, you will go through that function and you can start receiving what your client is sending you. This is actually a sample application that we provide, which is actually just receiving whatever you're sending towards your embed device over the PageKite connection and replying to it by just sending it back. So here we do a PageKite send here, connection send, with just the same data. Let's do a demo for that. So maybe pull up some terminals here. So this is my embed device connected over the UART. Then we have here, I'm going to set up a local front-end server on my laptop. So my laptop is acting as both front-end server as a router. So my embed device is connected to my laptop and my laptop is connected to the Wi-Fi here. So I'm going to run my PageKite front-end. So now it is running and accepting connections from back-ends, PageKite back-ends and also accepting connections from clients. So now if I reboot my embed device, it will start connecting to the front-end server. Now it's setting up its network connection, connection success. So now everything is set up. You can see here there's a device connected on the front-end, a back-end device. So now we can start sending over the public network. So everybody who is connected to, I think I'm connected to the FOSDEM dual stack network, everybody connected there can run these commands in order to open a connection to the front-end server that I'm running now. When I'm sending tests, I get a test reply from my embed device and you see here. So what happens? A new stream with ID 5 opens, we receive tests from some client over the internet and we reply it and we close the connection again. So that is what happens on the back-end side and on the client side. Back to the presentation. So these are the links. The embed library is located on our AscensionMind public Git repository. So anybody can access it. It's an MIT license. There's of course getting started in the README. And we also provide an example application, the one that you just saw, which just does an echo of the communication that you do towards the front-end. So I still have some time left for some questions. Anybody has some questions about this? Yes? How many connections can you support at the same time? Currently, I'm going to repeat your question. How many connections can we support at the same time? Currently, it's only one. So currently, we're only limited to one connection. We still need to implement some sort of parallelism to accept multiple connections at the same time. Yeah, that's the limitation. Yes? Then, a term in back for the cockpit job on the link, please. Yes? So this one? Yes. Okay. Maybe that's a more interesting slide than the last one. Other questions? Yes? How do you, when you deploy the system, distribute the secret key? Having it hard-coded is not really practical and not really secure. So you have to distribute it between the front-end and the back-end. How do you solve the problem? That's a good question. Actually, I don't know how our client usually does this, because our client is using PageKite for many purposes. Can you repeat the question? Oh, yes. Sorry. So the question was we have a shared secret between a back-end device and a front-end server. How do you distribute that shared secret across your devices and your servers? That's a very good question. Actually, I don't know how our client is doing it at this moment, because he's using PageKite for different purposes. Also, he's using PageKite to connect to a web server running on another local device. Actually, I don't have a good answer for that yet. Now it's of course hard-coded in the software, but maybe there's better options to do this. Why do you even need a shared key if you're using TLS and TLS can already authenticate both sides of the connection? Because then anyone could... So why are we using a shared secret between the server and the back-end? We do that because otherwise anyone could connect towards your PageKite front-end server and use it as a front-end for its own purposes, so you need some sort of shared secret in order to do the handshaking with trusted devices, of course, so that only your back-end devices can connect to your front-end server. You can have a client side certificate from TLS? Yes, you can do that as well. But TLS is not needed in most cases. You can also do an unencrypted connection, and then of course it's better to have a shared secret. Other questions? Okay, thank you very much.