 Hi everybody. Can you all hear me okay? I apologize for the delay with having some technical problems and you've been experiencing one of the rare blue screens that wasn't Microsoft's fault. We'll get this going. There's been some audio-video issues this morning so I'll try and get into this as quickly as possible so that we can get through all of my stuff and still hopefully leave some time for some questions and any follow-up discussion. So I'm Jeff Thoppe. I'm from NXP. I'm here to talk about, I don't know if they're my two favorite topics but they're certainly the two that keep me awake the most hours per day. Zephyr and in particular IoT security topics and how these two interact with each other. I think you're going to be hearing a lot about the Zephyr project at this conference. We've got another talk coming up this afternoon by Anas and Ben who are two of the technical leads in the project. So if you want to get into more detail that I'm going to be covering here then definitely go and check them out. You're going to have a really good opportunity to get into the bounds of the code and find out just how this thing ticks. Similarly, we have a booth upstairs. If after this you want some more information about that we have Kate from the Linux Foundation and other people involved with the project in a variety of capacities. So this is where I'm coming from. This is not my CV. This is really just more my prejudice, if you will. I work in the... I head up security in the R&D group at the microcontrollers business unit of NXP, formerly FreeScore. So this is the iDotimax and Kinetis product families that this is generally what I work with. And I'm coming from a hardware, well largely a hardware background. So though I do have a software background our approach to IoT security thus far has been fairly hardware centric. Nonetheless, I'm very interested in this Zephyr topic because of what I think this is going to allow us to do and because of what I think needs to be done going forward into IoT based on what we see happening so far. I'll get into that in some more detail. But first off, the topics I want to cover I want to give you a quick overview of Zephyr the project itself just give you a couple of high-level items on what it is, why it's there, how long it's been around and those sorts of general things. Again, there's going to be ample opportunity for people who want to find out more. And then I'm going to dig into my topic, the IoT security subject in general which is a... I'll get to just how vague a term that is but try and get through some of the things that I think matter most there and hopefully tie that in why I think Zephyr has a role to play. So, what is Zephyr? Well, for those who haven't been seeing some of the high-level items this really is sort of a 50,000-foot view of the project. So this is a small footprint art auspher intended for IoT but IoT microcontrollers, I mean the two terms are becoming increasingly difficult to distinguish. One of the characteristics of Zephyr is the fact that the way it builds and the way you construct it relies as much as possible on fixed static allocations so it's very good for building constrained low footprint images. That's not to say dynamic memory allocation isn't possible but we harness wherever possible the fact that if you know upfront what you're going to need you can build even smaller, faster images. The open-source project is following the Apache 2 license and this is being run in the context of a Linux Foundation project. They helped us put this together. In particular this came out of Intel WinRiver. They somewhat courageously I think realized that the best future for this code base and what it could do was to get it out into the open-source community and increase and improve its cross-architectural support. So we, NXP and I know a number of the other ARM-based semis were pretty enthralled by this and Lonaro has just created a new IoT group called Light for those who are involved in the Lonaro ecosystem and all you've probably heard about that. We're really excited. So there's a critical mass building around this project and as I'll get to in a second there's sort of a transparent development model so we're trying to have a cat can eat it too in the sense that yes we are. There are corporations forming behind this to try and give it the necessary, the mass and the solidity but we're trying as best as possible to ensure that the open-source fundamentals are respected. There's a meritocratic system around the community and anyone can get involved and the ability to write checks has nothing to do with your ability to get involved in the coding process. Right now we cover these architectures but there's a lot of squirreling away going on. Various people are getting involved in MIPS and DSP and RISC-5 and a few other things in terms of potential targets. But right now this is roughly what we look like. And as the Linux Foundation was looking at what it wanted to do about IoT and microcontroller form factors where as was pointed out in the fireside chat earlier there's a limit to how far down you can go with Linux and that's not just in terms of footprint it's also in terms of latency for certain kinds of tasks and use cases. So when you look at the RTOS and IoT microcontroller software ecosystem there is a... I mean everyone and their uncle has written an RTOS it would seem. So there's a lot of fragmentation. A lot of these bear the footprints of their specialist origins. Everyone has come at the RTOS problem from boutique angles. So we have an awful lot of different things out there but not really anything that could proclaim to be sort of generic and yet have all of the open source model attributes that we would like to have seen. This was I think Linux Foundation's interest in ramping up this new project. And as it so happens WinRiver and what they've been doing for many years now with their RTOS this worked out quite well. So hence some of the motivations for putting the project together but as I will get to in the last point I think security brings another angle to all of this. That sounds like an empty phrase and many people use it in an empty way so I will try to get back to putting some substance to that in a second. As to why you might get into Zephyr I've pinched this marketing slide so you'll forgive me for not dwelling too much on it. I'm not a marketing person but this is obviously aspirational I don't think anyone would pretend to objectively to claim to be best of breed of anything but we hope that the critical mass that's forming around Zephyr and the fact that it provides an environment where anyone can lean in and try to do what it is they think they need to get done and not face too many obstacles means that it will evolve to potentially be best of breed and the permissive licensing and modularity and these other attributes I think they deserve. And as things stand today I expect this list to increase but right now the Platinum members in the project who are sort of backing it and are putting in resources of all shapes and sizes are NXP Intel obviously were the ones that kicked it off first Synopsis have also joined and most recently in Naro created their IoT group have also jumped on board and are looking to build their IoT platform around Zephyr and to utilize what we're trying to do here. So just drilling in one level a simplistic view of the there is a charter Linux foundation tends to run its projects in a fairly consistent way and we're following that so in terms of the governance model if you want to call it that there is a governance committee there a government board that's where I'm involved I'm not on the technical side of things for this project at least not enough so you can park me in one of these orange boxes but the true technical activity is happening here in the technical steering committee and that's where as I said earlier we're trying to have our cake and eat it too this is a community model it's an open source model which is as best as we can decoupled from the governance questions about you know what conferences are going to to the extent that we have budget what are we pointing that budget towards anyone can get involved in the technical activity of the project and that is enshrined in the way the charter works so we are trying to leverage what seems to be working elsewhere in particular in the apps process of spaces so servers, networking and so forth as I will get to in more detail there's some I think fairly unique possibilities on the security side of things and so and that is something being largely at least for now driven by the companies who have jumped in so that's why I've coloured these things in orange to try and capture that distinction the community model really is there in the TSC and all the contributors that join the mail list start submitting patches, code reviews and so forth the participation so the project the code is not new as I alluded to earlier this code in various forms has evolved over the last 20 years in fact Wind River and I think I'm not sure entirely of what predates Wind River in terms of the code activity but this has been deployed in various critical environments like aerospace and so over a long long time the project is new but the code within it is not and so it's interesting there's a lot of rethinking going on a lot of the formative discussions for the project itself are happening right now we're talking about what we're doing with the IP stack talking about the different connectivity options what we have, where we're going, what would work best and so forth even to the extent of determining what makes most sense in terms of scope for the project where would you draw a line as to what's in versus what would be considered accessory for anyone who cares about this and is interested in getting involved there's something to be gained by getting involved at this point because a lot of those formative discussions are happening now and so we invite anyone who cares and anyone who has an opinion to come and share and I think there's plenty of room for people to scratch their itches I showed the slide a week ago and it was only at that point as I was showing it that it occurred to me that open source developers already have an unfortunate reputation as being hairy and poor bodily hygiene so that was certainly not the intention of the slide we do hope that people will find that there is the what's already there and where we're going and how this project works will allow you to there's a lot of weird applications and use cases for microcontrollers and so we expect that this there's sort of an inflection if you will and what's going on in that industry far more so than mature markets like servers where if you look at the Linux kernel right now and all the subsystems and the driver models and so forth things are fairly mature, things are fairly stable you see a lot of incremental changes but people are not ripping it apart and reconstructing it from zero that's not true in microcontrollers right now so we're aware of that we're hoping that ourselves and anyone who wants to join will be able to lean in and actually have fundamental influence on what we can do so if you have itches scratch them and of course if that fails we'll then get some treatment for some fleas the IoT security topic so I always get a little bit vertiginous when I talk about IoT security because it seems everybody is already trying to talk about IoT security and the air is kind of thick with nonsense on the topic everyone is saying all sorts of things of various degrees of ludicrousness so I'm going to try and drill in a little bit to what I think we mean by IoT security and what I think matters and then tie that back to Zephyr and so first of all I guess the question to be begged is well what do we mean and we should start with the first term so one de facto is IoT the experience I've had working within my employer and indeed working in the ecosystem going to various conferences working with partners just talking and more than anything listening is that if you ask 10 people what IoT is you're going to get 10 answers and probably none of them is terribly satisfactory most of the time the dialogue around IoT is dominated by a product centric view so you find people describing IoT in terms of markets, verticals standards, form factors, use cases and so forth but ultimately that is a very business and product centric view of IoT and what you do find is if you then drill into the software detail you find that those become fairly artificial distinctions what you would by any of those criteria call IoT versus what you would call not IoT are more or less in software they're the same problem so I think those distinctions are somewhat unless you're on the business side or you're trying to explain something to an executive I don't think that kind of phrasing and that kind of nomenclature is the right way to talk about IoT for us at least in the engineering world, programming world, software world I think it makes more sense to just make the obvious it's almost a banal observation which is that IoT really is whatever was previously offline coming online it's it's reductionist perhaps but I think what's interesting, particularly in security stems from this observation and that this is the one that matters there are many things online there have been online for a cell phone most people don't think of, I've not seen a single slide deck on IoT that doesn't include automotive for example but I haven't seen a slide deck that includes cell phones so I think the point there is that cell phones and that kind of software activity has already been online there's nothing terribly new about that the fact that your shoes are coming online that's what's new I think this is the key distinction and then the other part so what do we mean by security this is what's even more problematic because it's difficult to find because it gets abused quite heavily and of course I feel this most security is my role let's start off by looking for a few examples these are the kinds of I'm not trying to look for too much pity but these are the kinds of sentences I hear every day and I don't know if you find yourself saying these sorts of things or if you see this sort of thing going on unnecessarily often I don't have words to express the scorn for this sort of thing in fact I suggested to my boss at one point that these sorts of things should be a firing offense he pointed out to me that if that was indeed the criteria for a pink slip then I would have been fired five times by now so I don't need to be too cynical we I do this too I find myself doing it and I find myself not paying too much attention when others do it but I think there's a sort of discipline required these all beg that question what on earth are you talking about integrated security what do you mean integrated security what is security in that sense so here's just I picked these examples I could pick an awful lot more but the reason I've written these down is because these are the kinds of things where I've actually seen people within the same company sometimes within the same teams talk entirely past each other we need to we need to have a product with more security right that sort of nonsensical sentence where one of them meant one of these lines and the other one was thinking the other and they sailed past each other without realizing the disconnect right these are all fundamentally security topics and in many contexts this is what you mean when you're talking about security but without context do you mean all of them do you mean some of them do you mean any of them in particular this last one I'll get to this in a second but the complexity in software often gets to a point and we've discovered this increasingly over the years that the quality of the code is often the difference in security it's not necessarily about cryptography and confidentiality and privacy and protocols and so forth but you're often just talking about you know how buggy is it so that's to try and motivate a little bit where I'm going and if I was to dig one level deeper and this is still not a complete list but these two are security topics important ones I think and I hope you can get an appreciation of just how vast the topic area can become when you don't constrain it I get shivers down my spine looking at my own slide that's I mean these are all subject meta-expertises in themselves and I dare say I'll get to this in a second but these all apply if you're talking IoT there's not one of these that doesn't imply it to some extent some of them less and some of them more and some of them increasingly certification for example so I still haven't answered the question what is security I've just tried to point out that most of the usages of it are undefined I think the point here is that security can mean anything so therefore it means nothing okay so it's a useful mental exercise I encourage you all to try this to go into a talk where anyone's talking about something vaguely related to some security topic and just ask yourself how often this word goes past how often they're saying something where in fact they could mean any one of a number of different things it's usually implied by the context but unfortunately not always and what it means if you have a context varies dramatically and I've often used this last point when dealing with you know high level managers and so forth to try and just clue them into this point that if you want to get an understanding of just how broad and vague the security term is to turn it on its head to find it upside down and say okay well it's the absence of insecurity or the attempt to eliminate insecurity which then begs the question what is insecurity but it's much easier to imagine how many different forms how many different ways in which you can be insecure it's much easier to gloss over the fact that if you're trying to be secure oh okay people assume that's well defined try and figure out what you might mean by insecurity and then you understand just how vast that is so coming back to the first question so what do we mean by IoT security sorry I'm doing trying to bring those two topics together I was reminded by the way of that cliche that an image is worth a thousand words I think phrases like this is the other way around this is everyone has an IoT security apocalypse story I'm going to give you mine but you've probably seen a few already part of the problem is in fact that it means an awful lot of things but I think going back to that previous definition of IoT about the fact that it is the onlining of what you would traditionally expect to be offline we find that IoT security really is about the kind of fault line between these two types of security domain I'm being a little hand wavy still with my terms but perhaps a little less now that I've broken it in half arguably network and logical security could also be split out as we've learned over the years in the I'm I forgot to mention earlier I'm on the for the sins of my youth I'm in a team called OpenSSL you've probably heard of that project back in those early days when projects like that were starting out you know we assumed what we meant by functional security if you want to call this second item functional then functional security was assumed to be man in the middle of tax and things like that you were worried about the network so we invented all sorts of protocols and mechanisms and ideas and so forth and best practice to protect ourselves against network security issues only to discover that in doing so we got ourselves a gigantic mountain of buggy code and we were then caught up in logical security problems we were so busy protecting the network link that we had given ourselves an attack surface at the edge so I'm aware of that distinction but I don't want to get caught up on it too much right now so I've grouped those together the key point I wanted to get to is that because these are traditionally offline form factors markets and so forth we're coming from a world of device security which is to say the microcontroller world is largely hinged on a device security mentality by bringing these things online a fairly banal observation we are now confronted with a very different world of security activity which is the network and logical security so this all those items I had before on an earlier slide I've just tried to kind of break them out into two and this is an inherently um wishy washy activity because there are many items that should be on both sides of this table so don't take it too literally but as a general sort of attempt to gravitate them to where they feel most natural I think you can see that there's a lot of topics here that are far more common in the device security world where you're dealing with you know logistics infrastructure and so forth and secure elements in particular um a very painfully difficult world that I'm all too familiar with and then you know the network side and by network security I'm also talking obviously servers and just apps, processes and the far more mountain software stacks that you might think of you know with around Linux and so forth and trying to make that distinction here things like for example emergency response best practice and so forth um this is what worries me most um but before I try and break this slide down there was a statistic that was put out by Gartner I think a couple years ago and I'm not sure if that's if their predictions are proving true to what extent but in any case what they had to say I think was at least indicative of what we're up against which is that they were claiming I think by 2017 or 18 50% or more of the IoT edge nodes would be produced by start-ups that were less than three years old that to what extent that statistic is born out is I think a secondary the point there is that these um there is a proliferation going on you've all seen the numbers it's astronomical and it's growing something close to exponentially right now um and so this proliferation is going on precisely when the companies involved are fragmenting down in terms of the scale we're no longer talking about gigantic multinationals that have battalions of security experts that they can throw at any given problem they no longer have long NPI processes in which to get everything right and ready and on which they can always be late in the worst case we're talking about mum and pop shops and start-ups of all flavours that um you know the engineers quite often have the idea they're raising the VC funding they're doing the pitch they're doing the demos they're cleaning the toilets who knows they're doing more or less everything and so with that observation that again is my IOT IOT apocalypse story is um I've tried to break them out as what I call risk multipliers and defence demultipliers this is really about the attack surface and the ability to bring resources and engineering weight to bear on the challenges we are we're talking about a kind of wide deployment that would make most server vendors salivate I mean the number of nodes people are talking about is just just just crazy and these are all physically and network accessible my point here being that a $200,000 server sitting in a rack behind you know multiple layers of network load balancing and defence and what have you has a lower attack surface than the $3 item you can buy at the hardware store but it's coming online it's going to have an address and that attack surface is it was a way easy target and it's in much larger numbers so it's a larger attack surface and with that comes the high attack incentive conversely this commodity pricing on these items means that those those kinds of vendors and those kinds of products um a far more difficult defined room in the budget we want to do a code review want to do some more auditing we want to go out to a third party just to get a bit of intrusion testing or whatever just bring your eyes to bear on security challenges in your engineering is much harder when you're trying to scrape sense off your margins rather adds sense to your margins so idea safe finding fixing the bugs will be hard of course we're also seeing RTOS fragmentation as part of the problem but it's not the entire thing I think the specialization of all of these device types means that you have so many different versions of everything you don't have 5 or 6 major Linux distros and maybe 3 or 4 popular web servers or mail servers or whatever you're talking about a huge amount of modification and customization and you have a very um a very deep tree of different code variants so finding and fixing bugs particularly when they're being coded by people who are trying to find time to do so many other things as well is going to be worse than it was perhaps in some of these other computing spaces the minimization of engineering investment as I mentioned and my real fear here is that the reactive security which what I mean by reactive security if that's not clear is the observation that when something is online unlike the device security world when something is online things only start to get fun when you deploy whereas in a device security world the job is usually done when you deploy so reactive security what do you do do you have processes and praise can you handle vulnerabilities are you involved with the various research communities and so forth for handling these sorts of problems that's likely to drop down precisely as the devices proliferate and therefore we may be inadvertently proliferating as on the network so again an apocalypse story but it sets the scene what I wanted to capture here is what I've observed in the device security world microcontrollers especially is these types of industrial medical automotive there's all sorts of different niche verticals but these are all where microcontrollers are fundamental they're non-networked and a huge amount of engineering goes into them relative for example to if you look at a metric on footprint or lines of code or something like that you would think of these things as being small and simple but it's staggering how much effort goes into them and but it's all based on a deadline you get to a certain point you have certain kinds of QA and certification and other checks and balances that you have to go through because ultimately you're done and you ship the device is offline if it's reached a certification in any case well there's very little you could do to change it so the whole question of keeping that thing up to date has never really been a concern in the device security world and I think that's reflected in all the kind of engineering and how you do the engineering all the way up to that point you don't see the same level of rigor for example in many hugely elaborate Linux systems but that's because as soon as something's found you know app get yum whatever your system is you're going to be pulling down updates and you're off and running that's a foreign concept to a large piece of the microcontroller community however certainly in the higher end microcontrollers which I would generally prefer to call apps processors the complexity threshold has long since been crossed same threshold that you know microprocessors crossed in the 90s you know you see them in your cars now in your coffee machine these kind of graphics rich Linux running systems large SOCs a running software which is every bit as complicated as what you have on your cell phone what you have on your desktop but we're even finding that in what people are trying to do on microcontrollers that this is also becoming the case the complexity of the protocols and the you know for example the behavioral things people are trying to do behavioral security ideas analytics they're trying to push stuff because of scalability problems closer to the edge the complexity there has far outstripped the ability for people to get something provably secure very few people even talk about trying so there is an inherent problem here which is that we're engineering in a world that comes from the idea that you get something basically secure and it's done but we've crossed a complexity threshold where we learned in the 90s that that just doesn't work it's a it's illusory and of course they come online now so this is more than just theoretical nicety online and in all likelihood vulnerable so I spent a bit of time asking myself this question talking with a few people you know a few months back particularly with Kate and others who have been looking at all sorts of other kind of software procedural questions obviously things will go wrong I don't need to prove that point the media have already done it for me you've seen numerous cases I'm sure and you won't that's not going to drop anytime soon all sorts of things are already going wrong you have baby monitors blasting metallica songs at three in the morning people running devices off the road and filling the gaps I mean insulin monitors heart pacemakers everything I don't need to spell that out but the question then is given that this reality has already been confronted and we've been out dealing with it for decades in the apps process of spaces research happens fuzzing all sorts of things progress in advance you're able to find out the things that are wrong that you're able to discover about software in those spaces they come to grapple with that problem you see organizations like the different certs first.org there are all sorts of processes and standards for how you embargo vulnerability information coordinate fixes release information all that sort of thing well established in the apps process of spaces so of course you see it in the Linux kernel and every user space package that you could care to deploy can we bring that over right is that applicable to the IOT RTOS microcontroller arena it would be nice if it was hang on if I missed a slide sorry it would be nice if it was I deleted a slide earlier because of the audio visual stuff the problem is that I'll come back to this first of all DLM if you've been to a security conference in the last couple of years you will have noticed that there is hardly a square foot of a trade show floor without a DLM solution on it there are all sorts of small and large companies trying to pitch different DLM solutions I wrote this slide in a slightly more cynical moment I don't mean to be too condescending here DLM is an important piece of the puzzle but it certainly is not the answer and I think there is this kind of if you'll excuse the pun there is a false sense of security and thinking that DLM is in some way the solution to this kind of problem in the microcontroller IoT world because all it really is is about patch management how do I get the patches out what's the error mechanism how do you update the flash how do you do integrity checks and for many of these DLM solutions the rush of blood they have is to try and build a revenue stream off the fact that they are signing your images for you so they are trying to embed roots of trust therefore they help you by having you pay on some basis for how many images they sign and how wide they deploy however if you want to use a network metaphor this is really the last mile of the problem in networking we talk about the last mile being essentially your house or the condominium block you're in whatever but the question is what's happening upstream where does that code come from through how many different hands of the supply chain does that code go and get modified who's doing the work to analyze it and try and find problems with it as the static code analysis and other things advance what is being discovered and what do you do this really is just about once you know you have a problem you have your fixes you've cued them you've dealt with your supply chain you've dealt with all the jurisdictional complications this is just how do we sign an update which I dare say is to put it mildly is not really a complete solution many people think it is and the trade show floor is littered with these solutions so you kind of left with the impression that it might be so again reactive security is well understood over in these areas and can we adopt them well there are some significant complications as it turns out for those of you are familiar with with this topic if you think of a conventional Linux distribution you've probably seen with things like wireless firmware as just one example where you're talking about a product which may be a server or whatever but you're talking about a system with a host operating system Linux being an obvious example there's a kernel and then there's a kernel package obviously or perhaps a few kernel packages handling headers and whatever else but you have a horizontal array of packages you have a package management system that coordinates them and anything weird about your system any kind of intelligent subsystems any embedded microcontrollers anything smart down under the hood that sits below that operating system level tends to just get representative as an opaque package so you would have a firmware package and your package management system however what we find is this phenomenon which is sometimes described as systems of systems I think you can flip it on your head and think of it as subsystems of subsystems the other way around which is that in many cases those subsystems are themselves fully fledged operating systems SOCs and sometimes there's a hierarchy there that goes more than one level deep so if you're trying to track responsibly software and software updates in a system where the product is hierarchical rather than flat this whole CVE-CPE scheme falls apart and yet the reactive security community of the world is built around CVEs and CPEs so there is I'm pointing this out this is an unsolved problem and I'm certainly not meaning to imply that Zephyr has the solution I will get to what I think Zephyr ought to be doing but to sort of motivate a kind of view of the problem here and in particular what we see for example with our product line we have very small product microcontrollers all the way up to very elaborate SOCs is that what is one product operating system small cortex M for example is in another product is a subsystem of a subsystem so we are trying to talk about the fact that there is an RTOS there that we need to track and provide reactive security for and yet CVE is the CPE notion there which is the common platform enumeration the platform is essentially a product so you're trying to track what products are affected by what we're pointing out here well what is one product's operating system is another product's subsystem we're doing similar software what do you do about that how do you track it it starts to fall apart and so I think if you go back to the Linux example you start to see that we were surviving with the scheme we're starting to show some cracks but it was still okay and the closed source OS is used as well I mean Apple and Microsoft and all those others are involved in the CVE community but they've been getting by I don't think we will and finally a non-trivial complication is that whereas in those apps processors and larger operating systems the supply chain I think is much easier to handle because the supply chain generally tends to be additive in the sense that if you go from some raw generic upstream distro all the way through the different specializations of the supply chain you're typically adding packages or you're adding configuration you're making tweaks that can be represented as packages so the whole question of saying who's affected by a given problem is an easier question to ask and it's an easier question to answer than it is in the microcontroller world where things tend to be transformative the supply chain is not about adding packages that do configuration and tweaks it's about fundamentally transforming the software as you go down the line the software tends to get ripped apart put back together different components get bundled in with each other the configurations are often inseparable from the code and so when you look at a supply chain all the way down through regional local office type things and all sorts of specialization occurs between provider and edge node that the relationship between downstream and upstream has become much less clear than we're used to in the apps processor space so all of these mean that we can't just drag and drop what we've been doing in Linux and in the larger operating systems and expect that we suddenly have a solution for IoT and I don't have a good following slide for that by the way that's the end of that topic I just wanted to lay a little bit of the groundwork certification is another topic that's coming up again you've all seen the hacks you've all seen the nastiness you're probably suspicious of what your next shoe is going to do that is not going to be tolerated for long I mean the signs are already there that sooner or later people who may not understand this they're still going to want something better to be done and what has always been done when people want something better is certification so and by certification I'm not talking X509 certs and things I'm talking certification and the kind of common criteria tips and procedural stuff like that so there are a few different tentative attempts by various groups to propose certification standards for IoT they are undoubtedly valiant attempts but I think they all suffer from essentially the same problem which is that they're still anchored in their old device security world it's a different mentality to get out of which is that they are certifying the certifying IP the certifying hardware and the certifying software as it is and what that means is you have a standard which doesn't take into account how you built the software nor do you take into account what you're going to do with it once you deploy it's not about the maturity of software development and continuous development it's really just a static picture and that means that it's allergic to change all the certification standards are allergic to change they're fundamentally based in the notion that you have to get it right and once you get it certified that's your badge that you don't need to change anything and indeed you can't change anything of course once we come online most of you from the Linux world if you are from the Linux world we'll know that's in fact a surefire guarantee for insecurity if you give me something that you think is secure and walk away it's insecure because you've walked away if you're not going to keep it up to date and you're going to put it online I don't want to know about it so certification has never had much traction in servers networking switches and all of these things because they know it's much more secure to keep the thing up to date than to get some kind of false sense of security from a badge so the something about the solution to this I think we'll have at least this attribute which is that we would be certifying not necessarily the software but we would be certifying some aspect of how it is that you build the software and how it is you intend to maintain it going forward questions of provenance questions of escrow of keys or any other kind of things like that that would prevent responsible maintenance ought to be part of an IoT certification scheme now we have a bunch of certification people who have more familiarity with that old world but they'll start to look at this and there are a few discussions going on again, unsolved problem I won't go any further with this because there is nowhere further yet to go but I just wanted to point out this is another pain point that I think people aren't paying enough attention to they're too caught up in building software and trying to call it secure and then pretending that it is so where does Zephyr fit? well this really is my hobby horse is I think what we're trying to do with Zephyr is get into it well actually first let me just and I'm running short of time because of our technical issues so you'll forgive me for sailing through this but this is a picture of a typical certification workflow you have an upstream codebase it's trucking along some mainline development whatever and someone downstream with the money and the reason to do it is trying to have a certified version of this I'm using certified in the most general possible sense what I really mean is hardened so whether you're talking about certifiable versus certified, whether you're talking audited or auditable, whether you're talking about safety standards, compliance there's a whole picture term but the point here is a slower moving because it is necessarily slower moving development which is hinged on meeting certain harder requirements this is done downstream which means that the upstream development model has absolutely no kind of feedback loop to constrain it to encourage this delta to be small so whatever work it takes you to get that thing certified or audited or whatever is going to presumably be repeated and it's not necessarily going to get any better with time and of course the merge complications that stem from that mean that you're going to do this very infrequently which comes back to my other point about the fact you're on the contrary very frequently so that's why we in the ZIF project are trying to work on something along these lines which is we're trying to bake the hardening process or at least a subset of it into the tree itself rather into the project, not into the tree we see it necessary nonetheless if we're going to have a vibrant open source development community to keep that upstream mainline truck along at full speed as much as possible we need to find ways not to slow that down into place obstacles in its path but the feedback loop from whoever is doing the hardening and whoever understands certification and these other issues to inform them of what they can change with impunity versus what's going to cause us a world of pain is going to be our attempt to constrain that difference so that the upstream is itself inherently hardened to some extent and requiring less delta and this be something that we can because it be into the development process itself is therefore something that will be more continuous and less periodic that's the aspirational thing the idea here is that that's what the security group is looking at and we're going to try and find a way of working with the upstream community in the project to make that happen if I was to summarize quickly the idea here is to try to keep that upstream production worthy and this I think is one of the key distinctions between what we're doing and the millions of other RTOS's out there is that they are largely still working on a throw it over the wall model whatever their merits to a large extent you're taking it and then you run off and you do your product, you do your application and you and the upstream have ceased to be coupled so whatever's going on upstream and whatever's going on upstream into that product is much more difficult to reconcile with time this is something we're trying to tackle head on and whatever these other things emerge I talked about certification challenges I talked about the network security challenges the vulnerability handling challenges whatever needs to happen there in IoT we want Zepha to be a living breathing example of what we think the best practices are so we're going to try and engage in these activities directly rather than just as an afterthought right thank you very much for your time and don't forget to scratch