 I'm Ned Smith, and I work for Intel. As you can tell from the slide, I'm working in the Open Technology Center for Intel. And my background is in security. I've been spending most of my time working with the Open Connectivity Foundation defining the security model and the set of an object model for OCF there. And what I wanted to talk about today was gateways and some of the challenges that gateways present in the context of doing software update. If you are not familiar with OCF, they're defining an IoT framework. I'm going to go into more detail about what a framework is and so forth. So don't worry about that. But to get started here, I just wanted to introduce some sort of the big picture in terms of the software update process. Just so that we're all on the same page. And then I'll go into more detail in terms of how the IoT frameworks fit in the context of software update. So just to introduce some of the ideas here, in terms of this process, you can consider that many of the products that are delivered today in IoT and other spaces are essentially built from contributions from a variety of different suppliers. Those suppliers provide functionality that is fed usually to a vendor or an OEM who is responsible for that product. So presenting the entire solution to a user community. And in that context, they're going to provide some additional support in terms of building the product, testing it, and then producing a manifest or something that is signed for secure reasons, which then is put into some sort of a package given to some sort of software update distributor. In other words, some way for that update image to be communicated to the end device. Then there's the notion of an update installer. This is something that is going to be able to unpackage that image and present it to the target platforms. There may be multiple platforms that that installer is targeting. So in this context, there's manual update. There's over-the-air update. There is a variety of different ways to do update. I'm not trying to focus on any one particular way to do that, just really to talk about it more generally, so that we have some context for update process. Now as the topic alludes to, the idea here of this talk is to help understand, well, what are the complexities of software update in the context of a gateway? And so to better understand that, we need to understand what's the complexity of it, just doing an update in the first place. When we talk about a target platform, there's updates that can happen at various levels. Even at the lowest levels in the CPU level, there's microcode updates that typically have to go out. We don't often see that. Many vendors don't see that because it's sometimes taken care of by the BIOS or the OEMs who are providing firmware updates. And the microcode updates essentially get bundled in with the firmware updates. But then on top of that, there's system software updates. Those are sometimes there can be framework updates and application on top of those frameworks that also need to be updated. And the reality here is that there may not be one update mechanism that satisfies all of those needs for the different types of software update. So what you end up with is multiple kinds of containers for packaging up the update, multiple types of distributors, whether it's an app store model, or whether it's the update mechanism that's provided by the operating system vendor or the OEM. These tend to be different. And then of course, there's the installers. There's a variety of different technologies for installers. And if anybody's been following any of the update path for this conference, there's been a variety of different installer technology that's been discussed. And of course, at the very end are the devices that are the targets of the update. So the point here is that every single platform build is going to have a target that's potentially is going to have multiple update infrastructures that it has to address in order for that update to be applied properly. So another focus of this talk is around interoperability through standards. And there are several standards that are driving an IoT framework. So you may be familiar with some of these. There's the Open Connectivity Foundation. There's OMA. UPNP has been around for a while. But it still fits in this category of a IoT or IoT-like framework. All Seen Alliance is another one. One M2M is another one you may be familiar with. And there are others. This is just a few. There are a lot of these out there. And if we are trying to get to the nirvana of IoT interoperability, then we need to talk about translation gateways because all these protocols need to be translated, at least at the semantic layer. So we're going to talk a little bit more about that. But at the end of the day, translation is essential to interoperability. And there's really no way around that. So the focus of this talk primarily is at the IoT framework layer. There's all these other layers we could talk about and have been talked about in other parts of the conference. This talk is going to focus more on the IoT framework layer. And so this is above the operating system, below the application level. So I also want to point out this notion that there's a single image. Many of the constrained devices are built around the notion of just creating a single image. So in that scenario, there are still an IoT framework component that's embedded in that image. But the image itself has the need to go through this translation layer. And so that, I think, becomes an interesting aspect for update as well. I'll talk about it a little bit more. I'll talk about it more a little later. But the takeaway here is that the IoT framework layer is really rich in semantics. And so when we're doing translation, translation is all about gaining access to that semantic layer and doing a semantic mapping. And that has to be done in the clear. So there's really no opportunity for end-to-end security, for example. And so the translation gateway becomes a trusted third party or a trusted entity in the whole end-to-end security model. So let's take a closer look at the object model for interoperability for many of these IoT frameworks. Just to introduce the notion of an object model, if you're not familiar with the lightweight end-to-end model, they basically define this notion of clients and servers. And they communicate to one another through interfaces. The server has its own object model where they define these things called objects. And those objects have attributes. And then the interfaces define how to interact with those objects by the client. This is typically done over co-app. In the OCF model, Iotivity has sort of a similar but different approach to an object model. They also define clients and servers and interfaces for interaction. But they have the notion of resources. And then resources have properties. But otherwise, there's quite a few similarities between the two object models other than sort of this naming difference. There's also the all-join object model. There, they refer to consumers and producers. And they interact with one another through routers. They define interfaces that are essentially logically similar to objects or resources in the other models. And then they define methods, signals, and properties as the type of data that interfaces expose. The whole idea behind these frameworks is to get interoperability between the clients and the servers. So the idea is that there should be different vendors producing clients from those vendors that are producing servers. And if everybody adopts one object model or one IoT framework, then we have ubiquitous interoperability. But the reality is we have multiple of these frameworks. And so in order to get interoperability, we have to introduce the notion of translation. Translation happens at the semantic level or the information model level. And so we need something that performs that translation. And often that comes in the form of a gateway or a bridge or some other device that sits between these networks. All right, so here's another view of where the translation gateway fits. You can see there's a network A that is built around one IoT framework approach, a network B, which is built around another IoT framework approach. And then you have this notion of clients and servers within the network. And they're able to communicate with clients and servers in the opposing network through the gateway. And the gateway essentially introduces this notion of a virtual server or virtual client that connects to sort of its opposing virtual components. So a virtual client talks to a virtual server. A virtual server talks to a virtual client. And the translation happens in between while on the gateway. So at the end of the day, you can get an end to end interoperability solution where an application using a client on one network and network B is able to talk to a server in network A as if it was talking to one of its own devices. So the whole idea here is to provide this illusion that the clients and servers in network B are sort of magically populated in network A and vice versa. Now the interesting thing about what's introduced by this translation gateway is that from a vendor perspective, vendors not only have to update their device, which in this case is the server or the client, they also need to update the virtual component that's represented in the gateway. So there's really two targets of update when we're talking about translation gateways. And of course, if there's a second vendor for each one of these virtual devices, then there may be other vendors for other clients and servers and other networks also have to perform an update. So from the perspective here of the gateway provider, there's a dependency on the vendors from both network A and the vendors of network B are both depending on the gateway to provide this translation for hosting this translation of the virtual devices. Now there's another aspect I think about here in terms of update, and that is if the virtual device on one network is updated to provide say new functionality, then that might imply that the virtual device in the other network that's trying to talk to it might also need to be updated in order to take advantage of that new functionality as well. And so there may need to be some coordination between vendors A and vendors B in order to get their new functionality realized in this model. So the whole point here is to help illustrate that there's some additional complexity when we have to work through gateways. All right, so a gateway is not limited to a single network that can translate between multiple networks. And so when I say network, I'm referring to a network that's built around an IoT framework. So think OCF, All Seen Alliance, 1M to M, et cetera, et cetera. So for every IoT framework, there is potentially another target for the application in one network to talk to the server in the other network. So you can sort of think through some of the accommodatorics here. So let's talk about updates. So there could be vendors that are providing the application component, while other vendors are providing the framework component. And so each of those components need to be updated. There can be a large number of devices. So think different vendors of different types of devices, whether they're lights or thermostats or switches or pumps or whatever they are. They may all have different vendors. And so the gateway is essentially instantiating a virtual instance of every one of those kinds of devices. So think about the complexity of your IoT networks and how many devices there are. And then map that onto a gateway. There's potentially lots of virtual devices on a gateway. Now the other point here to note is the impact of update on the gateway becomes really important in terms of the latencies that are introduced through the update mechanism. Start counting up the numbers of things there that there's potential for all of the accommodatorics to add up. OK. So I think what this means is that gateways need to be designed for availability. That should be a primary design objective. If you sort of try to calculate what the mean time to failure is, essentially what you're saying is the rate of failure of devices in network A is going to be a function of the rate of failure in network B and network C. And if there's D, E, and F, whatever, all of those add to the MTBF of the entire system because this gateway is providing this fundamental translation function between all the networks. So the question here then is, what if an update requires a reboot of the gateway? It essentially means that the gateway becomes this central point of failure. And so the overall network, the combination of all these networks, becomes really the point of failure for the entire network. And that becomes a main concern from an availability perspective. So the question is, do updates require the server to reboot? Now, if you're familiar with any of the existing update mechanisms, they tend to rely on a reboot. So that could be a challenge. And it gets worse. So let's consider also the case where there may be different versions of the IoT framework. And the gateway may need to host multiple versions. So there may be in this example, there is version one of the blue class of framework. And then an update happens and introduces version two. And so now the translator has to be versioned. So we get a second version of the translator in order to map the different versions between the different IoT frameworks. And of course, if you add another network, then that also potentially updates the translator. So you have translator code that's sort of fundamental part of the gateway. That also needs to be updated. And so you add to our equation here that the availability of the gateway itself is now another dimension of our MTVF function. So you might say, well, hey, I can fix that problem by introducing new gateways. And certainly you can do that. But just keep in mind that for each one of those gateways, there's the complexity that the single gateway has. Now we multiply that complexity by three. And now we're really complicated in terms of update. So now as a device vendor, I have my physical device that I have to update. I also have to update the virtual device on all the gateways that are in deployment. And if the gateway is unreliable, and the solution to unreliability is that we introduce more gateways, now as a vendor I have to somehow make sure that my virtual device image gets properly updated on all of those instances of the gateway. So this seems like complexity that's difficult to manage. So what are some of the solutions? I think there are lots of potential solutions. But certainly solutions for the gateway where you can do some sort of dynamic update of the gateway such that it doesn't have to ever reboot is a great opportunity here. I know that in the academic community there's some discussion around dynamics offer update and some interesting tools and techniques that basically do stack modification and other things that essentially allow updates to happen in real time. So the kernel doesn't ever reboot. But this talk isn't about that. I think that's a whole other talk maybe for another day. But just to point that out, this really is what is going to be the kind of technology that we're going to need in order for these gateways to be successful. All right, so another aspect of update has to do with securing the updates and managing the keys that are associated with that update. So I'm going to kind of dive into that a little bit right now. So just to understand the terminology here, I'm using k to the minus 1 to represent an asymmetric private key. The k is essentially representing the public key, an asymmetric public key. And then square brackets denote signing. So when you look at kind of what we have here, the left-hand side of the screen is trying to represent essentially the existing solution in terms of how we manage security for update. And it's fairly simple in the sense that a vendor has a private key and he uses that private key to sign his update package. So there's some signature and whether it's in a package or whether it's streamed, it sort of doesn't matter. The point is he has his key that he uses to sign that package and then his key is also embedded in the device in some sort of secure storage so that when the package arrives, it can be validated. Now, this works because the vendor controls the manufacturer of the device and has access to the device during manufacturing and can embed his key in the device in some secure storage. There's a variety of different ways to do that and every vendor, many vendors have their own proprietary ways of embedding keys in hardware. Okay? On the left-hand side, we have the gateway and the point here is when the vendor is now trying to update the gateway, he has to produce an update package. Only this update package is a virtual image, not the device image. This is particularly appropriate for the scenario where you have a single image device, a constrained device that has a single image. You can't use that image to update the gateway because the gateway can only deal with the virtual sort of these virtual devices, okay? So there's something that sort of represents the device at the IoT framework object level and ignores everything underneath it, okay? Because it's not running on that constrained environment when it's on the gateway. So that's essentially a different image that needs to be signed and packaged and installed. Now, the installer has to essentially provide the verification key to the gateway in order for this verification to work. And what that implies is that somehow the installer is able to provision his public key into the secure storage of the gateway, but the gateway has to approve it. In other words, somehow the gateway's key has to sign the vendor's key in order for that trust relationship to be established properly. And so that's a separate, think of that as a separate installation step where the vendor not only has to install the package, he also has to install the key that verifies the package, okay? And so that gets into the next sort of question of how do we do that efficiently? Now, from a gateway vendor perspective, if you're happy to be a gateway vendor, the problem is essentially that you need to establish a trust relationship with every vendor, okay? So, and again, this is not just every vendor in your favorite IoT framework, it's every vendor for every IoT framework for which you intend to provide translation. So this potentially could be all devices, okay? So as a gateway vendor, you want to maximize your value, you want to be able to translate from all possible IoT frameworks, you're going to need to have trust relationships with all possible device vendors, okay? And keeping in mind that vendors change their keys and also vendors change, they come and go, they go out of business, there's a lot of dynamism in the whole vendor community. So as a gateway provider, you have to deal with all of that. Okay, so let's kind of review here what are some of the essential features or capabilities for some sort of scalable update mechanism that involves gateways. So first of all, automation, this should be obvious. There needs to be some sort of notification that an update is available. So you can imagine all the vendors are working feverishly to update their products. And so as a gateway provider, you want to know when those updates are available. There should be some sort of install package customization so that the image, you can tell the difference between an image that's targeting a physical device versus one that's targeting a virtual device. And there should be some mechanism for rollback that should be automated. So if for example, the installation fails, you can respond to it appropriately. I think in terms of the complexity for rollback when you're trying to coordinate excuse me, when you're trying to coordinate the installation of both the physical device and the virtual device, if one of those fails, then you got to roll back the other one, okay? And vice versa. That's an added level of complexity. We should be concerned about in terms of security, images need to be signed. It doesn't make sense from a gateway vendor's perspective to install a virtual device that potentially is going to introduce some kind of security malware into their gateway and bring it down. So they're going to require signed images. There needs to be a root of trust in the devices. This is, and so this applies both to physical devices but also to the virtual devices that has to be there. And then there's this notion of a trusted image repository. There needs to be someplace to store the images that the gateway needs to install. And again, the installers themselves need to be trusted. So whatever solution that the vendor is providing to the gateway to install the virtual devices, the gateway vendor needs to trust that. Testing and validation is also an important component. If you think about vendors typically test their devices, they're going to have the added responsibility of testing the virtual device as well and making sure that interoperability is the interoperability promise of working through a gateway that does translation is a supported capability. We also need to establish some open source technology for doing things like having common images. So bundles, packages, manifests, whatever that is, we really need to have, we need to reduce the number of choices that are out there so that we don't introduce unnecessary complexity just in the way that we create update images. And I know that's, everybody has an opinion which package and package manager that they like but every time we have a different one, that just adds some complexity that makes it more difficult to ensure that you've addressed all of the corner cases. And messaging at the framework layer is also another area where we could look at having open source technologies address the need here. In other words, when you look at many of the update mechanisms, they introduce their own framework layer for messaging. And so in the context of IoT frameworks, they're defining essentially messaging framework for achieving that connectivity. And so it doesn't seem to me, it doesn't make sense to have multiple different types of messaging frameworks, especially ones that are focused narrowly on, hey, here's how I'm gonna do over the air updates using this new type of messaging framework when the whole gold industry for interoperability is to standardize around a few IoT frameworks. And then another component here is essentially an image repository. And I'm gonna go into more detail about that in future slides, was there a question? Okay, if you have a question, just raise your hand. I'll call on you. Okay, all right, so suggestions for update scalability So I think a cloud, the assertion here is that a cloud repository is essential in order to scale the complexity. We need to find some way to reduce the apparent complexity from the perspective of the gateway and from the perspective of the vendors. So a great way to do that is introduce a cloud service and hide a lot of that complexity. So here's a suggestion for how we might do that. If we have a cloud repository that's built around the published subscribe model, essentially you can have the vendors be represented as publishers into the cloud. They publish their images and then the installers are the subscribers. They then consult the cloud when there's a new version of a vendor's virtual device or physical device is available. They then get notified through public subscribe and they can react then by installing the appropriate sort of updated image to the appropriate device, whether it's a physical device or a virtual device on a gateway. So you see here on this slide is just sort of an example is vendors one and three are publishing to version 1.1 of a particular framework and the installer one is the one that's installing and it's installing both the device A and device B and it's installing into both the virtual device as well as the physical device and they all happen to be sort of the blue flavor of the IoT framework. Vendor two on the other hand is building a device that can speak on all three different IoT frameworks and so it has a little bit tougher job and then it needs to provide, it needs to publish to each of those topics for each of the flavors and then the installer that needs to be able to install each of the flavors on both the virtual and the physical devices. So you get a sense for what this slide is trying to represent here. Now keep in mind this diagram doesn't deal with what happens if there's installation failure and how rollback works. That's added complexity that needs to be considered. All right, so now let's talk about key management of the cloud repository. So on the far left, you'll see essentially how things work today. This is sort of simplified version of how update works today. You have a vendor provides his updates to some sort of repository that then gets applied to the device and the device has this public key for which it is able to verify the update. Now some vendors go out of business and that leaves their devices that are out in deployment and someone really have to update them. Some of the ways that they deal with that is they license their updates to another outsourcer and so they essentially delegate through key signing, they delegate to the outsourcer. And so essentially what that means is the outsourcer key is signed by the vendor key and then the updates are provided by the outsourcer but can be signed by the vendor key. So essentially the device doesn't have to change in terms of its trust anchor. It can still verify the outsourcer's provided update. So it's an accommodation but as an accommodation it really doesn't scale much better than the current model where vendors provide their own private keys and embed their trust anchors in their own devices. So in terms of a cloud update model essentially what we're suggesting is that the cloud repository provider has its key and that certainly the gateway device will embed the cloud repository public key as a trust anchor in its secure storage and when the updates are provided to the cloud repository they are signed by the cloud and so the cloud then becomes a trusted entity in delivering those updates. But what this does is it really simplifies this notion of root of trust. So every device has this one repository trust anchor then there's some simplification that happens there. So let's take a look at key management scalability. There's actually a couple of approaches that we can look at. There's the PKI approach which many of you may be familiar with. The idea of PKI is there's a hierarchy of CAs and that there's a root CA that everybody sort of knows and trusts and you basically embed the root CA key on the device and then you build a certificate chain and at the very bottom layer of that certificate chain this is the vendor CA if you will. He's going to create a key that is his signing key for his update and then the vendor's update key which is highlighted in purple here. That's signed by the vendor's CA which is this lower layer. There may be multiple intermediate CAs but then you get to the sort of the first level and the root level CA. So this is just a bunch of signatures over keys until you get to the key that signs the update. That's typically how PKI works. Some things to note here. The verification essentially requires all keys so there could be four or more verify operations. For each update the root CA has to be trusted by everybody. This is interesting because it means that there is some outside entity that's providing a key that a vendor is putting into their device and they have no control over that vendor. They have no control over this CA provider. So if something went wrong, say their keys got compromised or whatever they're taking risk, they're sharing risk of their product line with this other vendor. So from a business risk perspective you have to think about whether or not that CA provider is putting as much investment in protecting those keys as you're putting into your investment in your product line and in your product, okay? So if we compare that with the cloud repository approach essentially the cloud repository has an update that's signed by the vendor. The vendor, the cloud then countersigns the update with the cloud repository key. So you see this again highlighted in purple, the counter signing of the cloud key of the update that's also signed by the vendor. What this means is when you install, the verifier could just verify with one key. Either they verify with the cloud repository key or they verify with their own vendor key. Either one can work and you only need to do one. There's only one verify as needed. You just have to pick which key is appropriate. And many vendors are going to include their vendor key anyway because the other types of updates for example, firmware updates or kernel updates may be something that they use a different update infrastructure for which they control so their vendor key is gonna be there anyway. So the expectation here is that each vendor is going to establish some trust in the cloud repository. So it's similar in that sense with the PKI approach but it's the cloud repository as an entity that's focusing on sort of being a meaningful participant in updates. And so the business conditions may suggest that the cloud repository provider is going to make the appropriate investment, okay? And of course the question is, do we really need to be the PKI root key in this scenario? And that's an open question, I don't know. So let's take a look at, do these IoT framework repositories exist today? This isn't a complete list but there's a couple of them that are interesting. There's one called OpenTDT. So this is, I think this is, the T is for translator to things. And the idea here is that from OpenTDT perspective, there are these schemas that are created by industry providers. So vendors of devices will create virtual devices that are built around the schema and then they'll contribute that schema to the OpenTDT repository. And it's mostly driven by standards organizations. So I think of things like OCF, All Seen Alliance and so forth, they're providing, they're essentially defining these schemas that are contributed to the OpenTDT repository. Developers can create their own translators and schemas as well, that's okay too. Translators can run on devices, cloud connected things, gateways, they sort of run on anything. Assuming, given that you have the IoT framework component underneath them. Okay, another interesting one is the Oscar Bundle repository. This is essentially bundles of OSGI objects. The OSGI, it's sort of an OSGI defined manifest that goes with that. It offers programmatic access to a web repository. However, developers can submit bundles to the repository but there's no sort of automated way to do that. It's all sort of manually put together. So there's still work to be done to make it automated. But this seems to be the type of choices that are available today. One of the challenges with OpenTDT is that schemas need to be standardized. So maybe there isn't the promise of vendor differentiation maybe more difficult to get to. In the case of OSGI, essentially it sort of lacks this developer automation that's needed to make it scale. Okay, so the other sort of mean from the perspective of security, there's still a bit of key management that's ignored by any of them. All right, so let's talk conclusions. Essentially reliance on IoT frameworks implies the need for translation. This sort of seems to be where the industry is going and given that gateway architectures need to add some sort of support for dealing with the complexities of that update brings and put update automation. It's needed to ensure scalability. There are a lot of challenges that are facing us in terms of achieving that scalability. But certainly one of the ways that hardware vendors can help out is to provide some support for embedding of trust anchors and keys and protecting those keys. It seems to be one of the fundamental components to all of this. So with that, open to questions or comments others may have. Yes. Yeah. It's a great observation. And I'm not trying to advocate one sort of business model over another. But certainly there is the possibility that vendors can go out of business and they don't support their products any longer. And the question to the industry is what do we do about that? One possible solution is that presents a business opportunity for somebody to go and support them. But in the absence of that, then what is the industry? You know, what's the right thing for the industry to do? From a gateway vendor perspective, it's sort of one of the options for the gateway vendors to say, oh, well, I can't support this translation device any longer because the vendor's not supporting it. That creates essentially maybe a useful control point for preventing that device from creating a problem because they can just remove the virtual device from their gateway and now that connectivity is not allowed, sort of a way of turning off the physical device. But ideally, that's not the best answer. Ideally, there's some way for those devices to be updated by somebody who wants to pick up support for it. Other questions? Thoughts? This talk was intended to get you thinking. It's not trying to provide an absolute solution, but really it's something that as an industry we have to be aware of and try and work through it and figure out what's the best way to address this. I think we're making great progress with over-the-air updates and so forth, but everything I've seen so far at this conference in terms of updates is focusing on update just the physical device and there should be some thought given to updating the virtual devices and working with gateways and helping them scale. Okay? Comments, questions? If not, thank you very much.