 My name is Johan Hedberg. I work for Intel's Open Source Technology Centre. I've been doing Bluetooth stuff for about 15 years now. Most of that time has been on Linux. I'm one of the maintainers of the Linux kernel Bluetooth subsystem and the Bluezy Bluetooth stack. But for the past two or three years, I've been mostly focusing on Zephy and spending time there. In this talk, I'll be talking about Bluetooth mesh. It's something I've been involved in implementing now for the past year or so. I'll go through the main details of the Bluetooth mesh specification. Going a little bit in detail on some of the technical aspects of it. And then I'll be also going through what our current implementation status of Bluetooth mesh is for Zephy and for Linux and a little bit also on what our plans are for the foreseeable future. So Bluetooth mesh is a new specification that came out from the Bluetooth SIG this year. It came out in the middle of July. And for the first time, it extends Bluetooth connections to a true mesh like many to many multi-hop topology. It doesn't have any new demands on Bluetooth hardware. So any Bluetooth hardware, which is capable of running Bluetooth low energy, that is Bluetooth 4.0, will be able to do Bluetooth mesh. It's worth mentioning, though, that in most cases it does require some operating system updates. So for example, current iOS and Android versions, they're not able to do mesh natively. Yet I would expect them to get some updates at some point to that. There's a fundamental aspect of mesh, which is broadcasting messages, relaying them. And it's basically kind of a managed flooding of messages, the way that the messages go through a mesh network. You don't get super high data transfer speeds with Bluetooth mesh. So it's most suited for simple signaling, small signaling packets. You can of course do large data transfer with it, but the transfer speed won't be that great. Message publication and subscription is a fundamental aspect also of mesh, and it is something I'll go into a little bit more detail. It's a way of kind of organizing who's sending messages and who's receiving messages in a Bluetooth mesh network. And security is something that's built into the core of Bluetooth mesh, and you'll find that at many different levels and layers in the mesh specification, but I'll have some more on that also later in the presentation. And one of the biggest benefits of course of mesh is that you get way more range than you get with traditional Bluetooth, which in most circumstances is around 10 meters or so, whereas with Bluetooth mesh, when you have the multiple hops, you can get kilometers of range for a single message. A little bit about how mesh fits into what's already there for Bluetooth. The concept of pairing might be familiar to many of you, and that's something that's existed from the very beginning with Bluetooth. It exists for Bluetooth Classic and it exists for Bluetooth Low Energy, and that's basically, as the name implies, pairing up two devices for one-to-one connection. And that's the kind of way that you use most Bluetooth devices today. Bluetooth Low Energy also brings the possibility of doing broadcasting from one device to many devices, so you could have something typically called Beacons, where you have one device broadcasting and many devices who are then able to receive that. And mesh now fills in the missing piece there, basically enabling many-to-many communication. And typical use cases you will see this with will be building automation, sensor networks in your home, common use case that we actually already see devices in the market, even though it's just a few months since the specification went public, is smart lightning, where you have light switches and lights talking to each other through mesh network. Then a little bit how mesh fits into the traditional roles that you have specified for Bluetooth Low Energy. On a very high level you can categorize Bluetooth Low Energy roles into connection-oriented and connection-less. The connection-oriented roles are the central and peripheral, where the central is the one initiating a connection to one or more peripheral devices. A PC or phone would be your typical central, whereas sensors, heart rate monitor, something like that would be the peripheral. But these are always one-to-one connections. And then you have the connection-less roles in LE, which is the observer and the broadcaster. And as the names imply, the observer is just sitting there passively, waiting for packets to come. And a broadcaster is broadcasting packets to anybody who might be interested. And because of this feature of the observer-broadcaster pair, it's well suited for mesh, and that's actually what Bluetooth mesh uses. So every node in a Bluetooth mesh network is both an observer and a broadcaster in that sense. A little overview of the kind of nodes that you will find in Bluetooth mesh network. This is a completely imaginary example, just for the purpose of highlighting all the different kinds of nodes that you can have participating in a mesh network. At the root of a mesh network you have something called a provisioner. And the provisioner is responsible for managing the address space of the mesh network. And it's more responsible for taking any new mesh device into use and making it a functional node in the mesh network. It will hand out the assigned address or addresses to the nodes, give the initial network key and so on. If you start going through this from the left there, the gut client and the gut proxy, let me first clarify, gut stands for generic attribute profile and it's the protocol that essentially all existing Bluetooth low energy devices use to communicate with each other. These features exist in Bluetooth mesh to enable compatibility with existing legacy devices that cannot talk the mesh advertising and scanning-based protocol natively. So that would be the current situation with your mobile phone OSS since you cannot actually, with their current APIs, do the kind of advertising and scanning that's needed by mesh. So you would have, for example, an older phone acting as the gut client and then you would have a device called the gut proxy responsible for bridging this one-to-one connection to the actual mesh network and proxy messages back and forth there. Then you have one more devices. Let me see if this one actually works. Nope. One more device is acting as a relay in the network responsible for forwarding messages. And then you will often have pairs of devices called friends and low power nodes. I'll get into this in a bit more detail later. But the general idea is that you have friend nodes which are caching messages for low power nodes which then ask the friend node at intervals like if there are any messages destined for the low power node. Then a little bit about the various stages that the mesh node goes through. When you buy a new device, it will be unprovisioned. It will be completely unusable in a mesh network until you go ahead and use provisioner to provision it. And during the provisioning, you basically give the initial network key to the node. You assign it an address. There's one thing missing here actually which is the device key which is a special pair-wise application key only between the provisioner and that one node which is then used for configuring and some other things. Once you provision it, it's still not fully usable in the mesh network. You need to assign it additional application keys you need to configure the publication and the subscription addresses and so on. And the configuration is done using this device key that was given during the provisioning phase. And once you complete doing the configuration, then the node is kind of a full mesh network node and it's able to participate and do anything that you need to do with it. Now, later on, maybe you sell your device, maybe you lose it, something like that. There's a feature in the Bluetooth Mesh called blacklisting which operates through functionality called key refresh. So what the provisioner can then do is that it can hand out new keys to the nodes in the network. It will do those using the pair-wise device key but it can then selectively leave out specific nodes that it doesn't want to give the new keys to and that way it essentially excludes those devices from the mesh network. And once you do that to a mesh node, it becomes unusable, it cannot participate in the network until you go ahead and reset it and then it comes back into the unprovisioned state again, so basically full cycle. Now let's look a little bit at the kind of logical composition of nodes in a mesh network. Each node that's participating in a mesh network has one or more so-called elements and an element in a mesh network, that's the smallest addressable entity that you can have. So each element has a network address that you can send messages to it with. And each element in turn consists of one or more so-called models. Now what the model essentially is, is just a collection of messages and states relating to those messages and the messages are identified using opcodes and that's basically it. On a high level you could categorize the models to client models and server models where client models are those that typically initiate sending messages, requests, and on the receiving side you have a server model that's receiving it and then responding typically with some kind of response message to the request. About the various protocol layers, so it's not super simple specification and there are several layers in the mesh specification. If you start there from the bottom, it might be simpler to go from bottom up instead of top down, there's the transport layer or the bearer layer. And for native mesh operation all you have is the advertising bearer, that's kind of the native mesh transport. But then if you have these legacy devices like you would have to do with your existing phone, you have the option of using the gut bearer there instead of the advertising bearer to be able to talk to mesh networks with legacy devices. On top of that you have the network layer which takes care of the network layer addressing of devices so that's how you talk to specific elements in the mesh network. You have the network layer encryption that's taken care of there and the authentication. And there's some other details there which I'll go into later also which are part of the network layer. Then you have the upper and the lower transport layer. There are some kind of generic functionalities that are taken care of there that are needed for the mesh network. Segmentation and reassembly is something the lower transport layer is responsible for. And in the upper transport layer there's things like heartbeat and friendship which I'll get into later. The application layer encryption is also taken care of on the upper transport layer. On top of that you have the multiplexing of messages into the specific models that implement those messages. So the access layer will be looking at the opcode containing the message and then forwarding it to the relevant model in question that's supposed to handle that message. And then at the very top you have the actual models that define the various states and messages and behavior related to those. The mesh specification itself actually comes with a couple of so-called foundation models which are used, they are mandatory for every single node in a mesh network to implement. They are used for example for configuring the mesh node, giving it keys, configuring the various addresses and so on. And then there's a separate specification called the mesh model specification that was released at the same time and that one then has a bit more specialized models that not every node will be interested in implementing. If you look at the main fields in a mesh network PDU it looks like this. There is inherent replay protection in the mesh network where you have an ever increasing index number combined with something called the IV index and the first bit there is actually just the least significant bit of the IV index that's used for the receiving device to know whether it's the current IV index or the previous one that should be used to decrypt. Then you have a seven-bit network ID. Essentially all this is kind of hash of the network key to allow for early filtering out of uninteresting mesh packets. So when a node is receiving mesh messages it would first look at those seven bits and if they don't match any of the known network keys to the node it can just discard the message immediately. It doesn't have to go through the process of trying to decrypt it and so on which would be consuming quite a lot of power. Then there's a bit for indicating whether it's like a signaling packet for generic network control like an acknowledgement of segments or something like that. There's a time to live value that's used to make sure that the message eventually dies out when it gets relayed through the network. There's the sequence number which gets incremented for every message when a node sends those out which is important for protecting replay attacks. When receiving the message the sequence number is combined with the IV index which each node is aware of and the first bit there the IVI bit is a hint of which of two possible IV indexes should be combined with the sequence number to decrypt and verify against the replay protection. Then you've got the actual addresses so who's sending the message and who's the recipient of the message and after that you have the actual transport payload the application payload and at the very end of the message you have the network layer message integrity check which can be either 4 bytes or 8 bytes. Usually the way this is done is that if you have an application payload that has its own message integrity check then that one will be 4 bytes and then in such a case the network message integrity check is also 4 bytes so you always have either 8 bytes so either 4 plus 4 or then 8. You would use 8 in the case of having a so called network control packet where you don't have an actual application layer encryption in that case the CTL bit will be set to 1. Little bit about the kinds of addresses so as you saw mesh addresses are 16 bits and they can be subcategorized into a couple of different types you have address 0 which is not used for anything else except to say that this is unassigned this is not used for anything it's never, actually that's not true it is sent over the air but mainly to indicate that this is like an invalid field or something like that in a message then you have an address that's unique for every element in the mesh network it's called a unicast address and that's the address handed over by the provisioner to the nodes that is provisioning and then you have the group and the virtual addresses I'll start with the group address so that's basically an address that a node can either publish to or subscribe to and enables sending a message to multiple devices a virtual address is a special kind of group address it's in reality a 128 bit so called virtual labeled UUID that's only known internally by the node it's never sent over the air and the virtual address, the 16 bit is kind of hash of that one and there's like extra authentication information passed when you're doing the encryption of the message where you will include the full 128 bits there so the recipient can then verify that yes this was actually this 128 bits that matches this virtual address that is not a collision of another virtual label UUID relaying which is fundamental to bluetooth mesh basically the way it works is that you have the time to live value when a node receives a packet it will, first of all it will decrypt the packet with its network key that way it gets access to all of these most important network layer headers one of which is the time to live it will decrypt it if the value is still greater than zero it will go ahead and reencrypt it with the new value and then broadcast it back out to the mesh network an important thing to notice here is that the application payload stays untouched when you're doing relaying so a relay device in a mesh network doesn't need to have any kind of knowledge of any application keys whatsoever which is a nice thing to have if you have some security sensitive messages you're sending between two nodes if your relay or many relays get compromised they will never get access to the actual payload there because they don't have the application key in that case message publication and subscription I mentioned a little bit earlier it's also a core feature of bluetooth mesh I've used here as an example the smart lightning case so on the left there you will have your light switches and on the right you have actual lights and the way we group them here is based on what room the lights are in so the way you would go about configuring the lights is that you configure a subscription address to them a group address that's assigned to that specific room where the light is in and the switches in turn are configured to publish to specific group addresses and that's how you can reach the right room from the right switches and the convenient thing with this is if you at some point get a new light you don't need to go and reconfigure your light switches to make them talk to the new light instead all you need to do is configure the new light to subscribe to the appropriate group address that's assigned to the room that they put the light in and it should work after that without touching the switches okay then a little bit more detail about the security features that Bluetooth mesh has so starting with the provisioning when you take a new device into use into a mesh network this is actually the mesh provisioning protocol is modeled based on the Bluetooth pairing protocol so it uses the same security mechanisms this involves elliptic curve where you receive the remote public key combine that with your own private key to generate a DH key and then that one is used to have a secure relationship there there are mechanisms for passing information over out of band so you can get the public key out of band or you can get some other piece of information like a pin code or something like that out of band during the actual provisioning same thing as you get with Bluetooth pairing as well then once you know this provision and it's part of a mesh network you have two layers of encryption going on there you have the network layer and you have the application layer as I mentioned this is useful for example for the relay use case where you don't need to give application keys to every single node in the network and since mesh uses broadcasting of messages anybody can receive it's extremely simple if there wasn't some kind of protection mechanisms for it to implement a replay attack on a mesh network because you don't need to know what the packet is you just hold on to it for some time and then you send it back out let's say you have a door lock and there's no replay protection so somebody unlocks the door your neighbor hears the packet and they don't do anything with it for hours or for a day and then the next day they go ahead and just send the packet back out and the door unlocks again so to protect against this there's a continuously incrementing number called a sequence number which is combined with the IB index in total these are 56 bits long so it will take I think it's millions of years like that with your typical sending out the packets before they loop around and would actually cause a compromise so in practice that should never happen and the IB index never goes over the air itself there's only the one bit of it that you saw earlier instead each node has an idea what the current IB index is and then there's a whole procedure called the IB index update procedure using which every node in the mesh network now they switch to the next IB index to use that and every node is always able to receive with the current one and the previous one in case they're a little bit out of sync somebody's using the new one somebody's using the old one but everything should still keep working all the time and then this thing if somebody steals your device to get access to the keys or you sell it or something like that you can do the key refresh procedure to exclude them from the network that way not be compromised the advertising packets that Bluetooth mesh uses they are small before Bluetooth 5 which is what mesh relies on it builds on top of Bluetooth 4 you can have 31 bytes of advertising packet data and that means that packets that get sent they are small and it causes interesting challenges if you want to send any bigger chunks of data so there's the concept of segmentation and reassembly so if you have a message that's more than 15 bytes 15 bytes is the biggest amount of payload that you can fit in an unsegmented message then you can go ahead and split it up into segments and Bluetooth mesh allows messages to be split up until 32 segments 32 comes from the fact that there's a bit field of acknowledged segments that you keep track of and that then gives you of 384 bytes of maximum segmented message payload size unsegmented messages they're unreliable so you never get any kind of acknowledgement on these the way you can work around this is you can have a response message another unsegmented message from the server model a simpler way to do this which doesn't require any changes on the higher layers is that if you have a payload that can fit into an unsegmented message you go ahead and encode it anyway into a single segmented message and that way you force the receiving side to send you a segment acknowledgement that it has received the packet so this is a common trick to do if you want to have a reliable sending of a small message then about friendship so every mesh node in principle needs to be listening for mesh packets all the time in the mesh network and this can consume quite a lot of power so luckily there's a solution for this in the mesh specification to cover for those devices which have very limited power supply the general idea is that you pair up your low power nodes the ones with the limited power supply with something called friend nodes friend nodes are those that would have persistent power supply and the basic idea is that when you establish the friendship the low power node says that I'm going to wake up using this period and the friend then caches up messages for it and whenever the low power node pulls the friend node will replay those messages to it and that way you can achieve really really small receive windows for the low power node it can wake up for just a couple of milliseconds every few days or something like that so you can really extend the battery life if you think about the smart lightning use case I mentioned earlier this would be a perfect fit for that because your lights they will have a stable power source so they are the perfect friend nodes whereas your light switches would typically have a small battery in them also the light switches they don't need to really receive messages that often mostly they are just sending messages when you flick the switch so it's a perfect combination for the friendship you would make the lights be the friends and the switches be the low power nodes so how far are we then with implementing support for this the zebra implementation it's something we were working on before the specification actually went public and we sent it for upstream inclusion as soon as the mesh specification was released in July and it's part of the latest zephy 1.9 release it has all the features that are mandatory in the mesh specification there are a couple of optional ones that we are still working on we've been testing that against tens of other implementations both before the spec went public as well as after it and actually another project minuut project ported it over to them as well and they've been doing fixes there and sending back over to Zephy so we've benefited from that quite a lot we also have demos of the implementation on various boards we have a demo here at the conference if you come to the Zephy booth we have micro bit devices there showing the basic functionality of Zephy Bluetooth mesh and in particular because of the micro bit the BBC micro bit devices they only have 16 kilobytes of RAM that has forced us to really optimize the memory footprint of Zephy mesh so the simplest configuration that you can have with it is about 12 kilobytes of RAM that it fits the entire Bluetooth stack the OS and the mesh support there on the Linux side we are a little bit behind but we are working on it the latest bluesy release already contains initial pieces of mesh support in terms of the mesh control tool this one however only implements the gut functionality so it has a gut client with which you can configure other nodes and it can act as a gut provisioner do provisioning over a gut and we're hoping for all you're going to see the patches still on this year's side but we're working on implementing a proper solution for the native mesh where the Linux kernel will be responsible basically for the advertising and scanning and user space will be responsible for the rest we're going to have a new daemon there called meshd that then takes care of this we're working on doing some optimizations that standard host controller interface of Bluetooth doesn't allow particularly for friendship using standard HCI from Bluetooth 5 you cannot actually get the smallest possible timings that the friendship negotiation would allow for so we are going to be implementing these extensions in the Zephy controller to be able to do this and we're going to have support for them both in the Zephy Bluetooth host as well as the Bluezy on Linux side and I'm currently quite busy implementing the French support that's one of the missing pieces in Zephy so hopefully for the next Zephy release we're going to have French support and then we also are starting to look at the mesh model specification to see if there's anything interesting there that could be implemented as part of Zephy most of them I would expect to be on a kind of per application basis and we're also trying to come up with various demos to show off the mesh the one thing that we have here is the one using the micro bit so if you're interested just come to the Zephy booth it's there across from the reception and with that I'm actually done are there any questions? Yes? Okay so the question was is it possible to send custom data to nodes? Yes so we expose a completely generic model mesh model interface and you can do any kind of custom model that you want with that to send anything, receive anything Yes? Yeah? No they are kind of leaf nodes so no they cannot so the question was about legacy devices legacy devices which talk to God so they can only send or receive but they cannot relay any information in the network there's some more yes? Multiple multiple provisioners so there's currently as far as I know there's no public specification for this how multiple provisioners would be able to share knowledge of the address space of what addresses have been assigned what keys have been assigned so at the moment if you want to do it you need to have some custom solution for it I know that there's work in progress to come out with a standard format for sharing provisioning information and that way you can have multiple provisioners to do that so it's technically it's perfectly doable right now but there's no open standard for that at the moment Yes? Well the provisioner is only needed to be around to provision initially the devices after that it can go away and the devices will keep operating in the mesh network until you need to reconfigure something or hand out new keys it's only then when you need the provisioner Did that answer the question? No, no you need the other provisioner so in that sense it might be good to have some redundancy to share the provisioning information with other potential provisioners Yes? So there's I mean the specification is public you can find it first of all or for the mesh model specification you can find it on bluetooth.org it has got things concepts like time synchronization across the mesh network it has a concept of scenes where you can kind of save the current state of like how bright the lights are at the moment and then you can restore it later all the smart lighting models are part of the mesh model specification I think it has maybe 20 different models at the moment and they're going to be creating more of them Yes? No, not really path discovery there's a way to discover how many hops away nodes are from each other that's done using the heartbeat where the message contains the initial TTL value and then you compare that with the received TTL and then you know how far it is but the actual path it took there's no kind of mark made on the package as they go through the network so no, you would have to do that using some higher level protocol if you want that so the question is how isn't there too much back and forth bouncing of messages or something like that well the replay protection list is one way that prevents it the time to leave is another way so it eventually dies out but what happens if you have two relays broadcasting or relaying the same packet twice when it relays it's still the same packet with the same sequence number so when another node sees those both relayed packets they will see the same sequence number in them and the way that the replay protection list works is that if you see the same sequence number that you've seen before or you see an older sequence number you discard the message, you don't process it so that's basically what happens when the same message is around so there's a feature called secure network beacons in the mesh specification that most nodes will broadcast periodically and that beacon actually contains the current index number so if you've lost sync with the current IV index you listen for those beacons and you can have a guess at what the current index number is IV index number is like that well it uses packet flooding somebody is saturating the well the replay protection list is supposed to protect against that I mean since everything has the message integrated check codes and you've got the replay protection list you can't just send random data it will be discarded immediately because it will not match any of the keys in the network and so on and you cannot replay the same packet again either because of the sequence number and the replay protection list that's true so if you have a rogue node that has ownership of the network key it can do bad things to the network it's limited, it's not as bad as having all of the application keys and can do everything but basically you need to do you can have multiple network keys first of all you can do a little bit distribution of what functionalities are available for what nodes so you can limit the impact if a node gets compromised and it's important also to do the provisioning procedure in a secure manner that you don't get many in the middle attacks there at that point so every mesh packet goes out on all three advertising channels there's some work in progress to potentially do some improvements on this but at the moment you're scanning on all three advertising channels and you're sending each packet on all three advertising channels is there still? yes? it's a standard, I'm not sure what you mean there's a standard Bluetooth mesh specification that was released as a Bluetooth standard in July that's what this presentation is about yes? you don't need controller updates you need the host OS updates to get the host stack updates to get the native mesh support for Linux, for iOS, for Android and these things the actual Bluetooth controller in those that doesn't really need updates so the question was about legacy devices why it's using gut well first of all gut is the API that's available with existing OSes so that's why gut is the chosen legacy support method and you don't get fine enough granularity access to the scanning and advertising to be able to do native mesh you need some updates from the OS for that all right, we're starting to be out of time here but okay, take one more yes, there was still you're asking can mesh take advantage of 2MegFi so that's a connection oriented thing and since mesh uses advertising and scanning it cannot take advantage of that it will be able to take advantage of advertising extensions where you get more payload but the current mesh specification it just uses booted 4.0 so it doesn't use that I think I'm going to cut the questions there if you're interested to ask more questions just come to me I'll be happy to answer them but we are out of time right now but thank you for listening